Implementing Service Quality in IP Networks

Implementing Service Quality in IP Networks Vilho Räisänen Nokia Networks OY, Finland Copyright  2003 John Wiley ...

Author: Vilho Räisänen

48 downloads 1476 Views 1MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Implementing Service Quality in IP Networks Vilho Räisänen Nokia Networks OY, Finland

Copyright  2003

John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England Telephone (+44) 1243 779777

Email (for orders and customer service enquiries): [email protected] Visit our Home Page on www.wileyeurope.com or www.wiley.com All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except under the terms of the Copyright, Designs and Patents Act 1988 or under the terms of a licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1T 4LP, UK, without the permission in writing of the Publisher. Requests to the Publisher should be addressed to the Permissions Department, John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England, or emailed to [email protected], or faxed to (+44) 1243 770620. This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold on the understanding that the Publisher is not engaged in rendering professional services. If professional advice or other expert assistance is required, the services of a competent professional should be sought. Other Wiley Editorial Offices John Wiley & Sons Inc., 111 River Street, Hoboken, NJ 07030, USA Jossey-Bass, 989 Market Street, San Francisco, CA 94103-1741, USA Wiley-VCH Verlag GmbH, Boschstr. 12, D-69469 Weinheim, Germany John Wiley & Sons Australia Ltd, 33 Park Road, Milton, Queensland 4064, Australia John Wiley & Sons (Asia) Pte Ltd, 2 Clementi Loop # 02-01, Jin Xing Distripark, Singapore 129809 John Wiley & Sons Canada Ltd, 22 Worcester Road, Etobicoke, Ontario, Canada M9W 1L1 Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. Library of Congress Cataloging-in-Publication Data Räisänen, Vilho. Implementing service quality in IP networks / Vilho Räisänen. p. cm. Includes bibliographical references and index. ISBN 0-470-84793-X (alk. paper) 1. Computer networks – Quality control. 2. Telecommunication – Quality control. 3. TCP/IP (Computer network protocol) I. Title. TK5105.5 .R345 2003 044.6 6 – dc21

2002191078

British Library Cataloguing in Publication Data A catalogue record for this book is available from the British Library ISBN 0-470-84793-X Typeset in 11/13pt Palatino by Laserwords Private Limited, Chennai, India Printed and bound in Great Britain by TJ International, Padstow, Cornwall This book is printed on acid-free paper responsibly manufactured from sustainable forestry in which at least two trees are planted for each one used for paper production.

Contents Preface

xi

Acknowledgements

xv

List of Figures

xvii

List of Tables

xxi

Abbreviations

xxiii

1 Drivers for the Adoption of Multi-service Networks 1.1 Customer Perspective 1.2 Network Operator Perspective 1.3 Service Provider Perspective 1.4 Summary 2 Service Quality Requirements 2.1 Services on the Internet 2.2 Definition of a Service 2.2.1 End user service versus provider-level services 2.2.2 About service instances and service events 2.2.3 Reference model for this section 2.3 Service Quality Estimation 2.3.1 Measures of end user experienced service quality 2.3.2 Recency effect 2.3.3 Psychological factors 2.3.4 Summary 2.4 Service Implementation Aspects 2.4.1 Choice of transport protocols 2.4.2 Throughput adaptability of services 2.5 Inherent Service Quality Requirements 2.5.1 Service quality characterizations in standards 2.5.2 Availability of service

Implementing Service Quality in IP Networks Vilho Räisänen  2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X

1 2 4 6 7 9 12 16 18 20 22 23 24 26 27 28 28 28 29 30 30 33

vi

CONTENTS

2.5.3 Continuity of service 2.5.4 Delivery time end-to-end 2.5.5 Throughput 2.5.6 Support for continuous service data unit transmission 2.5.7 Reliability of service delivery 2.5.8 Support for variable transfer rate 2.5.9 Generic considerations related to service requirements 2.6 Service Quality Descriptors 2.6.1 Measurement-based determination of traffic profile 2.7 Summary 3 Network Mechanisms for Multi-service Quality Support 3.1 Introduction to Network Quality Support 3.2 Policing of Traffic at Ingress 3.3 About Layers 3.4 Types of Network Support for Service Quality 3.4.1 Capacity reservation 3.4.2 Differentiated treatment 3.4.3 Differentiation of service quality instantiation 3.4.4 Summary of generic network service quality support mechanisms 3.5 Service Support in ATM 3.5.1 ATM service models 3.5.2 Summary of ATM service support 3.6 Service Support Models in Internet Protocol 3.6.1 Best effort service model 3.6.2 Controlled-load service support 3.6.3 Guaranteed QoS support 3.6.4 RSVP 3.6.5 Statistical QoS: DiffServ model 3.6.5.1 EF PHB 3.6.5.2 AF PHB group 3.6.5.3 Other PHBs 3.6.5.4 Functions of a DiffServ router 3.6.5.5 Summary of DiffServ 3.6.6 Summary of IP QoS service models 3.7 Routing in IP Networks 3.7.1 On addressing 3.7.2 IP routing protocol-based methods 3.7.3 ATM overlays 3.7.4 Lower layer tunnels: MPLS 3.8 Link Layer Issues 3.8.1 Performance 3.8.2 A note on scheduling 3.9 Summary

34 35 38 39 42 44 45 47 49 50 53 54 58 61 62 64 65 67 68 69 70 70 71 72 74 75 76 77 79 81 82 82 83 83 85 86 87 88 89 90 92 93 94

CONTENTS

4 Traffic Engineering for Multi-service IP Networks 4.1 Traffic Engineering 4.1.1 Context of traffic engineering 4.1.2 The traffic engineering process 4.1.3 Obtaining performance data from the network and analysing it 4.1.3.1 Traffic aggregate performance measurements 4.1.3.2 Obtaining data relevant for routing control 4.1.4 Performance enhancement 4.1.5 Scope of network optimization 4.2 IP Routing Control and Traffic Engineering 4.2.1 Optimizing routing based on service quality characteristics 4.2.2 Traffic engineering using MPLS 4.2.2.1 DiffServ over MPLS 4.2.3 Traffic engineering using IP routing protocols 4.2.4 Summary 4.3 Configuration 4.3.1 Policy-based management 4.3.2 Policy-based management of DiffServ 4.3.2.1 Case study of policy-based management of DiffServ 4.4 Summary 5 Mapping Service Requirements to Network Resources 5.1 Scope of this Chapter 5.2 ETSI EP TIPHON Reference Model 5.2.1 Architecture 5.2.2 QoS model 5.2.3 Summary 5.3 QBONE 5.3.1 Service support models 5.3.2 Summary 5.4 3GPP QoS Model 5.4.1 QoS model 5.4.2 Summary 5.5 Other Models 5.6 Utility-based Allocation of Resources 5.6.1 Summary 5.7 Generic Resource Allocation Framework 5.7.1 Signalling 5.7.2 Mapping of services onto network resources 5.7.3 Network quality support configuration for DiffServ 5.7.4 End-to-end service quality budgets

vii

97 98 100 102 104 105 110 113 116 117 119 120 121 123 124 125 126 129 130 132 133 135 137 137 140 141 142 143 144 145 146 148 148 149 152 152 154 156 160 163

viii

CONTENTS

5.7.4.1 Delay 5.7.4.2 Delay variation 5.7.4.3 Packet loss rate 5.7.4.4 Packet loss correlation 5.7.4.5 Throughput 5.7.5 Optimization of resource allocation 5.8 Summary

164 168 171 172 173 174 176

6 Service Level Management Techniques 6.1 Models for Service Level Management 6.1.1 Areas of service level management 6.1.2 Layers of service level management 6.1.3 Models for managed data 6.2 Service Planning and Creation Process 6.2.1 Interests of the customer 6.2.2 Network operator viewpoint 6.2.3 Service definition 6.2.4 Reporting 6.3 Service Level Agreements 6.3.1 SLA and DiffServ 6.3.2 SLA contents 6.3.3 End user SLAs 6.4 End-to-end Services 6.4.1 Assumptions about connection endpoints 6.4.2 Assumptions about per-domain service management 6.4.3 Requirements for end-to-end service management 6.5 Service Brokers and Charging 6.6 Summary

179 179 180 181 183 184 184 187 188 190 191 193 196 197 198 200 204 206 207 209

7 Measurements 7.1 Traffic Characterization 7.2 Network Monitoring 7.2.1 Troubleshooting measurements for services 7.3 Traffic Control 7.4 Definition of Measured Characteristics 7.5 Sources of Measurement Data 7.5.1 Measurement interfaces 7.5.2 Measured characteristics 7.6 Measurement Methods 7.6.1 Obtaining performance data from network elements 7.6.2 Monitoring a link 7.6.3 Monitoring a route or node pair 7.7 Traffic Engineering Measurement Infrastructure 7.7.1 Measuring entity 7.7.2 Interface to measuring entity 7.7.3 Measurement control and analysis function 7.8 Internet Service Quality Measurement Architectures

211 213 216 217 219 220 222 222 223 225 225 227 228 230 230 231 232 235

CONTENTS

ix

7.8.1 QBone measurement architecture 7.8.1.1 Discussion 7.8.2 Nokia Research Center measurement architecture demonstrator 7.8.2.1 Discussion 7.9 Summary

235 241

8 Mechanisms for Dynamic Service Quality Control 8.1 Previous Studies 8.1.1 Two-bit DiffServ architecture 8.1.2 Bandwidth broker in QBone architecture 8.1.2.1 Phase 0 Bandwidth Broker 8.1.2.2 Phase 1 Bandwidth Broker 8.1.3 QoS Agents 8.2 Generic Model 8.2.1 Service quality support instantiation control 8.2.1.1 Signalling interface 8.2.1.2 Internal bandwidth broker operation 8.2.2 Domain control 8.2.2.1 Link to traffic engineering 8.2.2.2 Means of maintaining information about resource availability 8.2.3 Inter-domain signalling 8.2.4 Link to service admission control 8.3 Summary

251 254 255 256 259 259 261 263 265 266 267 268 269

9 Case Study: Service Quality Support in an IP-based Cellular RAN 9.1 Motivation for Using IP-based Transport in Cellular RAN 9.2 IP RAN Transport Architecture 9.2.1 PLMN transport architecture 9.2.2 IP RAN transport architecture 9.2.3 Handover traffic 9.2.4 Service mapping in IP RAN 9.3 Traffic Engineering in All-IP RAN 9.3.1 Capacity planning 9.3.2 Capacity management 9.3.3 Traffic management 9.4 Enabling Technologies for Traffic Engineering in IP RAN 9.4.1 Policy-based management 9.4.2 Measurements 9.5 Inter-operation with IP-based Backbones and Roaming Networks 9.6 Summary

275 276 279 279 281 282 283 285 286 289 291 292 292 294

10 Conclusion 10.1 IP as the Convergence Network 10.2 DiffServ 10.2.1 Complementary technologies for DiffServ

241 247 248

270 271 273 274

295 296 299 300 301 302

x

CONTENTS

10.3 Service Level Management 10.4 Traffic Engineering 10.5 Potential Future Development Directions

303 304 305

References

307

Index

323

Preface Development of packet-switched data communication networking technologies has been rapid in recent years, a phenomenon made possible by the open standardization process and the potential new territories for intellectual property creation. As a consequence, new ways of creating services have been devised, bringing more flexibility as compared to traditional telecommunications schemes. Such possibilities bring certain consequences with them – since services as such are no longer necessarily standardized and can be created rapidly, tailoring them to different access technologies is less feasible. New service creation models also allow for the existence of sole service providers making use of separate network transport operators’ facilities. Interworking of different players of end-to-end service delivery requires advanced Service Level Agreement (SLA) handling capabilities between the parties involved. This brings us to another major theme of this book, namely that of building a platform for converged service access. Internet Protocol (IP) has emerged as a tried-and-tested unifying endto-end communication layer that can be run over multiple link layer technologies. Subsequently, using IP networks as a basis for providing end-to-end services makes perfect sense. The challenge to present-day IP networks comes from advanced realtime services such as streaming and voice/video conferencing, which are demanding applications from the viewpoint of network technology. This book addresses the service quality support technologies needed to deliver different types of content over IP network. The economic environment of network operators has changed in the past years, becoming a very competitive business area. Price Implementing Service Quality in IP Networks Vilho Räisänen  2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X

xii

PREFACE

competition among players is at worst fierce, leading to the target of reduced operating costs for production networks. At the same time, the network operator must be able to provide service quality support to new services with as short time-to-market delays as possible. This situation calls for advanced management techniques and models for managing the resources of the multi-service network as effectively as possible. A set of technologies and techniques known as traffic engineering addresses this need, providing for processes and frameworks to accommodate performance management of a network. The technologies belonging to this area, including measurements, multiprotocol label switching, and routing control in general, complement the capabilities of the IP protocol suite. The new, open Internet standardization process defines effective and scalable means of configuring the novel protocols complementing IP as the building blocks of multi-service networks. An example of such endeavours is the policy-based management work, bringing automated network configuration and management while at the same time raising the abstraction level of management. In the chapters that follow, the steps needed to be taken to create and manage services in a multi-service IP network are presented. The vision of multi-service, multi-access networks with flexible service creation is presented first. A framework is developed for describing service quality, and the generic steps of service creation to service level specification are covered. The protocol tools available for managing service quality in IP environment are described within a service support framework. The managed technologies considered in this book include Internet Protocol versions 4 and 6 and Differentiated Services (DiffServ). The statistical service quality support model of DiffServ is compared with Integrated Services (IntServ) and Asynchronous Transfer Mode (ATM). Advanced IP service quality management techniques such as Multi-Protocol Label Switching (MPLS) and policy-based management are covered. Finally, the role of measurements and Service Level Agreements (SLAs) within the framework is described, and novel ideas such as the use of bandwidth broker and utility-based allocation of resources are discussed.

PREFACE

xiii

The approach of this book could perhaps be best described as a system level solution viewpoint, not going very deep into individual technologies while attempting to provide an overview of the relevant technologies. This book represents the author’s attempt to best capture the multi-faceted area of service quality in IP environment of today. Due to commercial factors and novel innovations, the reader is strongly encouraged to take heed of J.W. Goethe’s advice: Gray, my friend, is all theory; Green only the tree of life.

ORGANIZATION OF MATERIAL IN THIS BOOK Chapter 1 describes the technological and business scenario for multi-service networks. Chapter 2 describes the service quality requirements of IP service types in the network. Chapter 3 describes service quality support mechanisms that can be used in an IP-based access or transit network. Chapter 4 describes how traffic engineering processes can be used in optimizing the performance of a multi-service IP network domain, and technologies that can be used by policy management. Chapter 5 describes how services can be mapped to network resources in an IP domain as a part of an end-to-end service quality support chain. Chapter 6 describes technologies for service quality management and service level agreements (SLAs). Chapter 7 describes measurement technologies that can be used by service management and traffic engineering processes. Chapter 8 describes means of managing dynamic service quality within a DiffServ domain, and between Internet domains in general. Chapter 9 describes the implementation of service quality in IP RAN as a case study of the technologies discussed in the book. Chapter 10 summarizes the central themes of the book, and discusses potential emerging technologies relevant to the topic of the book. Major interdependencies between chapters with respect to each other are illustrated by the matrix below.

xiv

PREFACE

2 1 2 3 4 5 6 7 8 9

3

4

5

6

7

X

X

X

X X X

X

8

X X X X

9

10

X X X X X X X X

X X X X X X X X X

Figure 0-1 Interdependence between chapters of the book

TRADEMARKS 3GPP specifications are copyrighted by the European Telecommunications Standardization Institute. All RFCs and IETF drafts are copyrighted by the Internet Society. Internet2 is a trademark of the University Corporation for Advanced Internet Development. Java is a trademark of Sun Microsystems. Linux is a registered trademark of Linus Torvalds. Nokia is a trademark of Nokia Corporation Oyj. Napster is a trademark of Bertelsmann. Netscape is a trademark of Netscape, Inc.

DISCLAIMER Although the author has based part of the material in this book on his experiences at Nokia, this book does not represent the official view of Nokia Corporation or Nokia Networks.

FEEDBACK Feedback from the book is welcome. It can be sent by e-mail to the publisher’s address at [email protected].

Acknowledgements The author would like to thank Markku Hollstrom ¨ of Nokia Networks for supporting the writing of this book. The author’s technical understanding has greatly benefited from cooperation and discussions with Zhi-Chun Honkasalo. They both deserve special thanks for the opportunity to work on interesting QoS issues. Other deserving special thanks go to Man Li, Jani Lakkakorpi, and Outi Hiironniemi. Nokia has been a stimulating working environment providing ample opportunities to work with interesting topics. Face-to-face and e-mail discussions with the following persons have helped the author to better understand the relation of different technologies with respect to each other. The list is in alphabetical order. Deciding who to include is not an easy task, and the author apologizes for any unintentional omissions. Mika Aalto, Erkka Ala-Tauriala, Heikki Almay, Gerald Berghoff, Alan Clark, Jan-Erik Ekberg, Philip Ginzboorg, Marc Greis, Glenn Grotefeld, Andreas Heiner, Markus Isomäki, Kalevi Kilkki, Al Morton, Abbas Moslemie, Pekka Pessi, Jari Rosti, Jussi Ruutu, Erik Salo, Marko Suoknuuti, Jaakko Teinilä, Janne Torsti, Martti Tuulos, Kari-Matti Varanki, and Haihong Zheng. Thanks to Birgit Gruber and Zoë Pinnock from John Wiley & Sons, Ltd. for their help in making this book happen. The author gratefully acknowledges the right to use QBone material in this book. The following people have contributed to the QBone material in question: Andy Adamson, Philip Cimento, Larry Dunn, Ruediger Geib, Sue Hares, Haci Mantar, Volker Sander, and Ben Teitelbaum.


List of Figures 0.1 1.1 1.2 2.1

2.2 2.3

2.4

2.5

2.6 2.7 2.8

2.9

Interdependence between chapters of the book Service delivery via multiple access channels An example of multi-service, multi-access technology scenario made possibly by IP Factors of end-to-end service quality include cognitive and psychological factors (end user), implementation of service support in terminal, implementation of service quality support in network, and implementation of service by the service provider Client–server and connectivity/service paradigms illustrated The relation of concepts “aggregate service”, “service instance”, “service event” and “service quality requirement type” as used in this book Example of recency effect for quality reduction of 20 units, with α = 1. Time and quality are measured in arbitrary units Service involving two service events: fetching a HTTP page from bank server (1) and fetching stock exchange indices from a stockbroker’s server (2) The difference in measuring one-way service and two-way service Delay-centric view of interrelation of some important service quality characteristics Service event loss correlation with three loss sequences (LS1, 2 and 3) consisting of 1, 2 and 3 lost events, respectively A leaky bucket and token bucket


xviii

3.1 3.2 3.3 3.4

LIST OF FIGURES

The benefits of prioritization Reference model for this section An illustration of NBR and PBR An illustration of mismatch of protocols with respect to ISO/OSI protocol reference model using example protocol stacks 3.5 The structure of IPv6 headers with DS field composed of DSCP and currently unused bits (CU) highlighted 3.6 Recommended DSCPs for AF PHB group 3.7 Logical functions of a DiffServ router 3.8 IP service quality support schemes 4.1 Traffic engineering process of [RFC3272] 4.2 The relations between performance measures 4.3 Different types of source/destination combinations: access link to access link; access link to/from peer domain; peer domain to peer domain 4.4 Possible scope for applying traffic engineering 4.5 An optimization hierarchy 4.6 An example of a policy rule 4.7 Reference architecture for policy-based management 4.8 TCBs inside a router 4.9 Topology of the DiffServ-MPLS policy management example 5.1 SLA reference model for the present 5.2 ETSI EP TIPHON reference model 5.3 QoS characterization of user, application, and transport levels in the TIPHON reference model 5.4 Release 99 UMTS architecture protocol stacks 5.5 Utility curves for VoIP and WWW browsing 5.6 Possible signalling interfaces for requesting service quality support 5.7 The role of SLAs in inter-domain resource quality management 5.8 Relation of ETSI TIPHON’s QoS classes to end-to-end delay and overall R-value (OVR) 5.9 The convolution effect for summing one, two and three even distributions 5.10 The effect of dejittering buffer adjustment algorithm on packet loss percentage 5.11 The relation between delay and packet loss in a dejittering buffer

LIST OF FIGURES

xix

5.12 99.9% delay variation quantile as a function of link load level and the number of hops 5.13 Illustration of summing of loss correlation for independent losses case 6.1 Conceptual relation of management plane to service and transport layers 6.2 Layers of management in the TMN model 6.3 Combined framework 6.4 A simplified illustration of the service definition process. The iteration based on feedback from SLA negotiation also leads back to a phase below service composition definition 6.5 Reference figure for end-to-end service management 6.6 Variation of delay for two simultaneous emulated VoIP media streams in a non-switched Ethernet segment with bursty background load 6.7 The service provider side SLA as a part of the customer service of an access network provider 6.8 Example scenario for auction model. Routing between the service providers is selected using the market price for service support 7.1 Modelling both incoming services at the network edge and loads of service quality support bearers in the network core 7.2 Traffic engineering measurements and different types of troubleshooting-type measurements 7.3 The location of measurement points (M) in QBone architecture 7.4 The concepts used in QBone bandwidth measurements 7.5 An example set-up of measurements in the connection of a boundary router in QBone 7.6 An illustration of measuring all the routes terminating at ingress/egress routers of a neighbouring QBone domain 7.7 Service quality demonstrator architecture 8.1 An example of end-to-end provisioning on service layer 8.2 An example of end-to-end provisioning performed by per-domain bandwidth brokers (BB) 8.3 The interfaces and internal structure of a QBone bandwidth broker 8.4 The use of aggregated reservations 8.5 Funnels in Schelén’s scheme 8.6 Interfaces of the generic bandwidth broker

xx

8.7

LIST OF FIGURES

Supplying non-next hop information between bandwidth brokers 9.1 A High-level view of an All-IP network 9.2 Transport domains in a GPRS/3GPP network 9.3 An illustration of RAN transport hierarchy 9.4 IP RAN architecture protocol stacks for user layer traffic 9.5 Principle of soft handover 9.6 Service mapping for user layer traffic in IP RAN 9.7 Schematic representation of end-to-end service quality computation 9.8 Schematic of the configuration half of traffic engineering in IP RAN 10.1 Technologies associated with the layers of SLA management and implementation 10.2 The timescales of traffic engineering

List of Tables 2.1 Draft IP QoS classes 2.2 Summary of some of the most common Internet service content types 2.3 Some Internet services and service event types 2.4 Factors affecting service quality for telephony and Internet services in general 2.5 Availability 2.6 ITU-T’s draft recommendation for delay classes for Internet services U = unspecified 2.7 ITU-T’s draft recommendation for delay variation classes for Internet services U = unspecified 2.8 Draft reliability-related ITU-T recommendations for Internet services 2.9 A comparison of service event statistics 3.1 QoS support mechanisms for ITU-T’s draft QoS classes 3.2 Summary of scopes of network service quality support mechanisms 3.3 Summary of service quality support in ATM 3.4 Summary of IP service support mechanisms 4.1 A comparison of network monitoring levels 4.2 Comparison of aggregate measurement methods 4.3 Rough timescales associated with traffic engineering subtasks 5.1 Functional elements of the TIPHON QoS control model 5.2 QoS profile parameters in 3GPP framework 5.3 An example utility table for services 6.1 Example SLA contents for DiffServ domain 6.2 Example TCS parameters for a SLA consisting of three service types Implementing Service Quality in IP Networks Vilho Räisänen  2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X

xxii

LIST OF TABLES

6.3 Example PDB characteristics for VoIP, browsing, and data traffic 6.4 Examples of factors affecting end-to-end service quality 7.1 Relation of measured characteristics and measured objects 7.2 Examples of active measurement types 7.3 Canonical names and units for QBone measurement reporting 7.4 Required QBone measurement reports 9.1 Traffic types in IP RAN 9.2 IETF classification of traffic engineering functions and their related timescales

Abbreviations 3GPP AAL ABE ABR ADSL AMR AF API

ARIMA

ARP ASP ATM BA BB BBC BE BER BGP

Third Generation Partnership Project ATM Adaptation Layer Alternative Best Effort Available Bit Rate Asymmetric Digital Subscriber Line Adaptive Multi-Rate codec Assured Forwarding Application Programming Interface Autoregressive Integrated Moving Average Address Resolution Protocol Application Service Provider Asynchronous Transfer Mode Behavioural Aggregate Bandwidth Broker British Broadcasting Corporation Best Effort Bit Error Rate Border Gateway Protocol

BSD BTS CAPEX CBR CBWFQ CGI CIDR CIM CLP CLT Codec COPS COPS-PR CP CPE CPS CPU CR-LDP CS


Berkeley System Distribution Base Transceiver Station Capital Expenditure Constant Bit Rate Class-Based Weighted Fair Queuing Common Gateway Interface Classless Inter-Domain Routing Common Information Model Cell Loss Priority Central Limit Theorem Coder/decoder Common Open Policy Service COPS for provisioning Control Point Customer Premise Equipment Call Processing Server Central Processing Unit Constraint-based Routing LDP Circuit-Switched

xxiv

CSMA/CD Carrier Sense Multiple Access/Collision Detection DBW Dedicated bandwidth transfer capability DiffServ Differentiated Services DMTF Distributed Management Task Force DNS Domain Name Server DSCP DiffServ Code Point DSLAM Digital Subscriber Line Access Module DSP Digital Signal Processor DV Distance Vector (protocol) ECN Explicit Congestion Notification EF Expedited Forwarding EGP Exterior Gateway Protocol E-LSP EXP-Inferred-PSC-LSP ETSI European Telecommunication Standardization Institute EXP Experimental (bits in MPLS shim header) FEC Forwarding Equivalence Class FR Frame Relay FTP File Transfer Protocol GBRA Generic Byte Rate Algorithm GGSN Gateway GPRS Support Node GMPLS Generalized Multiprotocol Label Switching GoS Grade of Service GPRS General Packet Radio Service

ABBREVIATIONS

GRE, GRX GSM GTP HTML HTTP ICMP IETF IGP IN IntServ IP IPDV

IPER IPLR IPPM

IPTD ISDN IS-IS

ISO

ISP ISSLL

IT

GPRS Roaming Exchange Groupe Spécial Mobile GPRS Tunneling Protocol Hypertext Mark-up Language Hypertext Transfer Protocol Internet Control Message Protocol Internet Engineering Task Force Interior Gateway Protocol Intelligent Networks Integrated Services Internet Protocol Instantaneous Packet Delay Variation/IP delay variation IP Error Rate IP Loss Rate IP Performance Metrics (working group) IP Transfer Delay Integrated Services Digital Network Intermediate System – Intermediate System International Standardization Organization Internet Service Provider Integrated Services over Specific Link Layers (working group) Information Technology

ABBREVIATIONS

ITU

LAN LDAP LDP LEO LIS L-LSP LPDP LS LSP LSR MAAC MAC MBAC MBS MCR MIB MIPv6 MMS MOS MP3 MPEG MPLS MPS MTBF MTPS MTTR

International Telecommunication Union Local Area Network Lightweight Directory Access Protocol Label Distribution Protocol Low Earth Orbit Logical IP Subnet Label-only-inferredPSC-LSP Local Policy Decision Point Link State (protocol) Label-Switched Path Label Switching Router Measurement-Aided Admission Control Medium Access Control Measurement-Based Admission Control Maximum Burst Size Minimum Cell Rate Management Information Base Mobile IP version six Multimedia Message Service Mean Opinion Score MPEG audio layer 3 Moving Picture Experts Group Multi-Protocol Label Switching MPLS over WDM Mean Time Before Failure Mean Time to Provide Service Mean Time to Repair

xxv

MTU

Maximum Transfer Unit MWIF Mobile Wireless Internet Forum NAT Network Address Translator NAT-PT Network Address Translator/Protocol Translator NBR Nominal Bit Rate NGTRANS Next Generation Transition (working group) NIC Network Interface Card NMS Network Management System NNI Network-Network Interface Node B WCDMA BTS NRT-VBR Non-Real-Time Variable Bit Rate NSIS Next Steps in Signalling NTP Network Time Protocol OPEX Operating Expenditure OS Operating System OSI Open Systems Interconnection OSPF Open Shortest Path First PBR Peak Bit Rate PC Personal Computer PCR Peak Cell Rate PDB Per-Domain Behaviour PDP Policy Decision Point/Packet Data Protocol PDU Protocol Data Unit PEP Policy Enforcement Point

xxvi

PESQ PHB PIA PIB PIU PoP POTS PQ PS PSC PSQM PVC QA QMA QoS QPS RAA RAB RAN RAR RB RED

RFC RIP RMON RNC RSpec

ABBREVIATIONS

Perceptual Evaluation of Speech Quality Per-Hop Behaviour Percent IP Service Availability Policy Information Base Percent IP Service Unavailability Point of Presence Plain Old Telephone System Priority Queuing Packet-Switched PHB Scheduling Class Perceived Speech Quality Measure Permanent Virtual Circuit QoS Agent QBone Measurement Architecture Quality of Service QBone Premium Service Resource Allocation Answer Radio Access Bearer Radio Access Network Resource Allocation Request Radio Bearer Random Early Detection/Random Early Drop Request For Comments Routing Information Protocol Remote Monitoring Radio Network Controller Requirement Specification

RSVP RTCP RTP RTT RT-VBR SAP SBM SBW SCR SCTP SDH SDP SDSL SGSN SDU SIMA SIP SLA SLM SLS SME SMS SMTP SNMP

Resource Reservation Protocol Real-Time Control Protocol Real-time Transport Protocol Round-Trip Time Real-Time Variable Bit Rate Service Access Point Subnet Bandwidth Manager Statistical bandwidth transfer capability Sustainable Cell Rate Signalling Common Transport Protocol Synchronous Digital Hierarchy Service Description Protocol Symmetric Data Subscriber Line Serving GPRS Support Node Service Data Unit Simple Integrated Media Access Session Initiation Protocol Service Level Agreement Service Level Management Service Level Specification Small or Medium Enterprise Short Message Service Simple Mail Transfer Protocol Simple Network Management Protocol

ABBREVIATIONS

SVC TCA TCB TCP TCS TDM Telco THP TMN

ToS TRM TSpec UBR UDP UMTS

Switched Virtual Circuit Traffic Conditioning Agreement Traffic Conditioning Block Transfer Control Protocol Traffic Conditioning Specification Time-Division Multiplexing Telephone company Traffic Handling Priority Telecommunications Management Network Type of Service Transport Resource Manager Traffic Specification Unspecified Bit Rate User Datagram Protocol Universal Mobile Telecommunications System

xxvii

UTRAN UNI UTC VAD VC VLAN VLL VoIP VTC WAP WCDMA

WDM WFQ WLAN WRED XML

UMTS Terrestrial RAN User-Network Interface Universal Coordinated Time Voice Activation Detection Virtual Circuit Virtual LAN Virtual Leased Line Voice over IP Video Telephony Conferencing Wireless Application Protocol Wideband Code Division Multiple Access Wavelength Division Multiplexing Weighted Fair Queuing Wireless LAN Weighted Random Early Drop Extensible Mark-up Language

1 Drivers for the Adoption of Multi-service Networks Digitalization of entertainment and other consumer content makes it possible to use available transmission media resources more efficiently, to use universal storage solutions for the content while providing end user quality experience equal to or better than analogue media. This leads to the need for speech, music, pictures and streamed content to be delivered to homes and mobile users in digital form. Content delivery channels of this type exist or are becoming available in the form of digital telephone networks, digital mobile network systems and digital television. These technologies are examples of mostly single-service networks at the moment, although so-called “2.5 generation networks” (2.5G) can already be used for transmitting pictorial and data content. The challenge of the near future is to provide all kinds of services over single delivery channels in a cost-efficient manner. Facing this challenge in Internet Protocol (IP) based networks is the topic of this book. Conceptually, there are three parties involved in such a delivery chain. The digital content is produced by a service provider, delivered to the end user by the network operator, and used by a customer. Let us next study the implications of the situation referred to above from the point of view of these three parties.


2

DRIVERS FOR THE ADOPTION OF MULTI-SERVICE NETWORKS

In this section, only the access network operator viewpoint is considered. We shall return to the interrelations of access and backbone network operators later in this book.

1.1

CUSTOMER PERSPECTIVE

Currently, a home user is typically using multiple access technologies for communication. Wireline telephony (“Plain Old Telephony System, POTS”) and cellular phones are used for two-way speech delivery. Digital cellular phones also support text and picture form messaging. Broadcast TV and radio are used for receiving audio and video content such as news and entertainment. Usage may be associated with a “flat-rate” subscription for the service or be free of charge. Cable TV infrastructure may be used as a transmission medium for paid audio and video content, in addition to being used for the distribution of broadcast programs. Paid content may be billed based on flat-rate subscription or usage-based. Internet access can be handled via POTS local loop, Integrated Subscriber Digital Network (ISDN) over POTS, some variant of Digital Subscriber Line (xDSL), or a cable modem. Recent additions to the repertoire include wireless broadband access using meshed wireless routers or Wireless Local Area Networks (WLAN). Each of these technologies is associated with a delivery channel, as illustrated in Figure 1.1.

TV set

Broadcast content

Internet PC

PSTN Telephone

Figure 1.1 Service delivery via multiple access channels

1.1 CUSTOMER PERSPECTIVE

3

A noteworthy aspect of this situation is that the reception of different service types is based on different kinds of technology: POTS telephony and broadcast TV/radio are based on analogue technology, whereas Internet access and cellular telephony (in Europe and increasingly in other continents as well) is based on digital technologies. Thus, the home user currently needs a POTS telephone, radio receiver, TV receiver, radio receiver, cable TV settop box, personal computer (PC), and xDSL Customer Premise Equipment (CPE). The mere existence of different kinds of equipment is no bad thing as such; it is often good to use equipment specifically designed for one service to have optimal usage experience. What is not optimal is the inability to receive all types of content in a single type of device, say, PC, if need be. Second, with the exception of telephony and Internet use, the services are typically one-way “broadcast” type of services with an associated usage fee. This arrangement is rather inflexible; a subscriber of such a service pays for all types of content and not only the types the subscriber is interested in. Also, the selection of the content “on-demand” basis is highly desirable. Digital TV is now taking its first steps in Europe. Digital TV technologies allow for interactivity to complement the distribution of the content over the digital TV channel. This is a step in the right direction. Third, the traditional arrangement ties the end user to a single “access network” provider who is also the service provider. Competition for the local loop access has not always succeeded optimally. Thus, for each of the access technologies, the customer has to pay a price that is not determined by competition in a free market. Fourth, messaging-type services have become popular recently, allowing users to send notices to other users in near-instant fashion. In addition to “traditional” e-mail, other examples of messaging include the Short Message Service (SMS) and the Multimedia Message Service (MMS) of GSM/GPRS (Groupé Spécial Mobile/General Packet Radio Service) networks, and messaging on the Internet. Such messaging requires that users are “on-line” in order to receive messages addressed to them. In addition to telephone networks, this is possible for Internet messaging using xDSL and with the communication endpoint (PC) switched on. Collecting some of the observations made so far, a wish list of the customer for information access technology would look as follows.

4


• Communication endpoints (e.g. PC, mobile terminals) should support accessing of different kinds of services. Dedicated terminals such as TV sets can be used when optimal usage experience or storing of received content is important. • Converged access network systems should support the delivery of all kinds of services. The same network should support delivery of messaging, data, and streamed content as well as being suitable for supporting conferencing-type applications. • The end-to-end delivery chain should make it possible to separate provision of services from provision of access to services. This allows the choice of the most adequate access technology according to the usage situation. Specific details of the access medium should be as invisible to the user of the service as possible. • Interactivity should be possible, in addition to receiving broadcast or downloaded content. Specifically, support for nearinstant messaging is highly desirable.

1.2

NETWORK OPERATOR PERSPECTIVE

The business need fulfilled by the network operator is to provide access to service types for the customer. Depending on access technology, the competition is more or less fierce. In copper local loops, for example, incumbent network providers are challenged by new entrants, cable modems, and wireless access technologies. In cellular networks, to take another example, most countries have multiple operators. Due to competition, operators need to consider both capital expenditure (CAPEX) and operating expenditures (OPEX) of their network technology platform. In brief, CAPEX considerations lead to the goal of utilizing built capacity as efficiently as possible, whereas OPEX aspects boil down to streamlining and automatization of technological solutions in use. Both of these aspects will be discussed in this book. The progress of content digitalization, the advent of new services, and expectations of interactivity and converged technology platforms pose further challenges to the access network operators. It is in the interest of operators to develop technological platform support for advanced service types.

1.2 NETWORK OPERATOR PERSPECTIVE

5

The convergence of the multi-service network has been a technological goal of the telecommunications industry for a long time. One of the first attempts was narrowband ISDN (Integrated Services Digital Network), supporting up to eight ISDN terminals within the customer’s premises and providing two simultaneous circuit-switched connections from a single ISDN CPE using ISDN’s 2D + B channel technology. Alas, business adoption of ISDN occurred fairly late, in Europe during the latter half of the 1990s. In ISDN, the bit rate of a single channel was limited to 64 or 56 kbit/s because of the (Analogue/Digital) A/D conversion used in digital POTS network. The next attempt was broadband ISDN, also known as Asynchronous Transfer Mode (ATM). ATM has advanced multi-service capabilities and can support high bit rates. As a result of a longdrawn standardization effort, the final ATM standard is fairly complex, and failed to be implemented end-to-end. An issue that became evident after taking ATM into production use, the management of ATM networks is complicated. In addition to managing the ATM network as such, the operator also needs to manage the protocol layers below (for example, Synchronous Digital Hierarchy, SDH) and above (for example, Internet Protocol, IP) ATM. Subsequently, in the Internet domain ATM is mostly used in backbone networks where the configuration is often static. In the late 1990s, it turned out that the winning convergence layer was IP. The main reasons for it being victorious stem from existing wide-scale adoption of the technology in the Internet and IP not being “owned” by a only a handful of vendors. In Internet design philosophy, the state is maintained at the communication endpoints and not in the network, allowing for cost-efficient design of networking equipment. IP is a good convergence layer in the sense that it can be run over multiple link layer technologies, including ATM. On the applications side, the Internet Engineering Task force has developed – and keeps on developing – a rich set of protocols for interfacing different kinds of service applications to IP using “Layer four” (L4) protocols such as Transfer Control Protocol (TCP) and User Datagram Protocol (UDP). In particular, the standard socket programming interface towards IP and multiplexing protocols such as TCP and UDP is well known. The adoption of IP in different Internet access networks together with the rapid growth of Internet usage has brought with it very rapid growth of traffic volumes in the network. At the time of

6


writing, this growth has slowed down due to economic factors, but growth is expected to continue once a new wave of services becomes available. This fast growth has led network operators and other involved parties to pursue the goal of optimizing the protocol stack. A protocol stack of IP over ATM over SDH over Wavelength Division Multiplexing (WDM) is not optimal, neither from CAPEX nor from an OPEX point of view – at worst, all the protocol layers require software and hardware support as well as trained maintenance personnel. Light protocol stacks such as IP over 802.X in copper-based networks or Internet Protocol/Multi-Protocol Label Switching (IP/MPLS) over WDM have received lots of deserved attention on the commercial side as well in research and standardization. In brief, network operators are looking to light protocols stacks with IP as the unifying end-to-end layer as a multi-service support platform of the future. To accomplish this goal, management of multi-service Internet needs to be made more streamlined than that of ATM.

1.3

SERVICE PROVIDER PERSPECTIVE

Service providers compete in their ability to provide best service selection to the customer at the best price. This goal can be pursued by different strategies: providing a set of services and network access in “bundled” packages, or by providing innovative services with shortest time-to-market delay, for example. It is in the interest of service providers to be able to provide services to as wide an audience as possible with as small an overhead as possible. The former goal leads to the ability of accessing the services with multiple technologies being desirable, with market mechanisms ensuring the interests of both the customer and the service provider. The latter goal means in practice that the service provider should be able to provide services for different access methods with as little tailoring as possible. The tailoring cannot always be fully avoided, as is the case with saving streamed content in the server in multiple encoding formats, but the per-access technology tailoring (conversion) can be made as automated as possible. The service provider wants to have a flexible mechanism towards the network operator in providing services with

1.4 SUMMARY

7

appropriate service-specific parameters specified as simply as possible. The contractual interface between the service provider and the network provider should be flexible to allow for the quick implementation of novel service types. Eventually, the time-to-market consideration ultimately comes down to the abstract multi-service network interface being as streamlined as possible. With such an interface, service creation efforts can be concentrated on the construction of the new service, instead of having to manage a multitude of access-technology specific parameters.

1.4

SUMMARY

Having a single end-to-end convergence layer is in the interests of all parties, namely customers, network operators and service providers. The Internet Protocol (IP) emerged from the period of rapid technological development during the late 1990s as the winning candidate. Converged IP-based delivery of content service allows IP to be used as the common denominator for services above it, as well as different access technologies beneath it. Architecture of this type is illustrated in Figure 1.2.

Mobile access

A/V content service Internet

TV set

Internet service

Home access

PC

Communications hub

Telephony service

Telephone

Figure 1.2 An example of multi-service, multi-access technology scenario made possibly by IP

8


Different technologies can be used beneath the IP layer to support delivery of services to the customers. The link layer access network technology can be chosen according to the customer’s momentary needs. From the operator viewpoint, the transport network connecting to the end user link should advantageously be implemented with as few protocols as possible for flexibility, and should make as good use of the installed capacity as possible. The latter requirement, typically specific to access network operators, leads to the need to implement service quality support mechanisms in the network. Such mechanisms need to be implemented either on the link layer, or in the IP layer. This is the main topic of the present book. Having a well-defined interface to specify the requirements of services is important for service providers. A central theme in service definition is service quality specification. In the following chapters, we shall study the generic requirements of different service types, network-sides service quality mechanisms in Internet Protocol networks. Another major area of interest in this book is the management of services within a network domain, as well as between different parties of the end-to-end delivery chain. Technologies and the techniques for implementing this constitute a major part of this book.

2 Service Quality Requirements In this chapter, means of assessing and specifying service quality requirements are described. To lay the foundation for discussion, the following questions need to be answered: • What is a service? • What kind of services are there? • What does it mean to provide quality support for a particular service type? • Which form of representation of service quality requirements is the best one? Background for answering the first question will be sought by first studying a few typical Internet services, and then proceeding to define suitable concepts for service definition. The second and third questions will be answered by studying the factors affecting service quality, as well as the means of measuring service quality. Finally, the means of specifying service quality requirements are reviewed. First, it is in order to discuss the relation of service quality support to the commonly used term “Quality of Service” (QoS). QoS is an overarching term, which different schools of thought relate to Implementing Service Quality in IP Networks Vilho Räisänen  2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X

10

SERVICE QUALITY REQUIREMENTS

different parts of end-to-end service quality, including user experience and service quality support mechanisms. International Telecommunication Union’s Telecommunications branch’s (ITU-T’s) related definitions [G.1000] are as follows: • Quality is the totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs. • Quality of service is the collective effect of service performances, which determine the degree of satisfaction of a user of service. Different viewing angles on Quality of Service are listed as following: • QoS requirements of user or customer are a statement of the level of quality required by the applications of customers/users of a service, which may be expressed non-technically. • QoS offered or planned by provider is a statement of the level of quality expected to be offered to the customer by the service provider. • QoS delivered or achieved by provider is a statement of the level of the actual quality achieved and delivered to customer. • QoS perceived by user or customer is a statement expressing the level of quality that customers believe they have experienced. The term “QoS” is deliberately avoided in this book, except when it has a specific, well-established usage such as “IP QoS mechanism X” or “QoS framework of standard body Y”. The author’s use of the terms relevant for this discussion is as follows: • End-to-end service quality: end result of everything that affects the end user’s experience of service. The factors affecting this will be discussed in more detail below, but an overview is provided in Figure 2.1. End-to-end quality is not purely subjective, albeit affected by psychological factors related to the particular use of service [BSD00]. Depending on the context, this may mean either service quality planned by the provider, or service quality experienced by the end user. In this book, the viewpoint of inherent service quality requirements falls into this category. • Service quality support mechanisms: means of supporting service quality along the route assumed by the service instance. This includes, broadly speaking, service quality signalling schemes


End user

Terminal

11

Network

Service provider

Figure 2.1 Factors of end-to-end service quality include cognitive and psychological factors (end user), implementation of service support in terminal, implementation of service quality support in network, and implementation of service by the service provider

such as Resource Reservation Protocol (RSVP) and service quality support mechanisms such as Differentiated Services (DiffServ). As a result of using service quality support mechanisms, one obtains QoS delivered by the provider on the service level [G.1000], which can also be characterized by network performance level on network level [I.350]. End-to-end service quality can be thought of being composed of service quality support domains (see below). The breakdown of end-to-end service quality into constituent parts is used, for example, in ITU-T’s recommendation telephony planning model, “E-model” [G.107, G.108] and the European Telecommunication Standardization Institute’s (ETSI’s) IP telephony project QoS model [TIPHON-1]. Such a division is often referred to by the term “QoS budgets”. This book attempts to be neutral with respect to Internet access technologies. The attitude towards technologies can be characterized as “forward-looking” in the sense that the service quality support potential of different technologies is in some cases evaluated beyond currently used deployments. Due to the affiliation of the author, issues specific to wireless issues are considered where the author has assessed them to bring added value to the reader. IP-based Radio Access Network (RAN) is used as a case study for the concepts developed in this book since the author has participated in the work in this area.

12


2.1

SERVICES ON THE INTERNET

To develop a conceptual definition of services, let us next take a look at what kind of services are known to be in use on the Internet. Examples of well-known services on the wireline Internet at the moment include: • • • • • •

sending and receiving E-mail; accessing news content with a browser; e-banking; e-trading; whiteboard applications; chatting.

E-mail is “the original service” of the Internet (a short summary of Internet history can be found, for example, in [Kap99]). Developed from a simple means of conveying text messages, modern e-mail clients can deliver attachments and support multiple content types. Most of the services in the above list typically make use of Hypertext Transfer Protocol (HTTP). Whiteboard and chat applications, on the other hand, can be implemented as point-to-point applications between communication endpoints (computers). In their original form, the HTTP-type examples listed above were classical examples of the client–server type interaction on the wireline Internet. For example, when I start up my PC, launch a web browser and click the British Broadcasting Corporation (BBC) link on my Netscape browser, a HTTP request is sent to the server whose IP address results from the Domain Name Server (DNS) resolution of “news.bbc.co.uk”. As a response to the request by the client (Netscape browser), a web server of BBC sends the news homepage back to my browser in Hypertext Mark-up Language (HTML) format. A single HTML page may include components from multiple servers, which is often the case with commercial HTML pages with embedded advertisement content. In addition to text and figures, the content provided by an HTTP server can also contain streamed audio or video such as news footage and downloadable files, for example, Moving Pictures Expert Group (MPEG) audio layer coding 3 (MP3) files. An HTTP page can be interactive with menus, type-in fields, and buttons invoking further reply/request interactions, while still conforming to the client–server paradigm.

2.1 SERVICES ON THE INTERNET

13

Common Gateway Interface (CGI) scripts can be invoked during HTML page access in the HTTP server, making it possible to implement actions such as database searches and on-request HTML page creation based on results. Downloading of Java applets into the browser allows for local processing in the client. A variant of the client–server paradigm spontaneously came into being after the free on-line MP3 repository Napster was charged of infringing copyright of the publishers and of the music artists. Distributed versions of the service were developed, consisting of a central server containing pointers to the location of the actual music files on other Internet hosts. From the point of view of interactions, the distributed scheme is still of client–server type, the only substantial difference being distributed storage of the content and related redirections. A trend in the making is that of allowing greater freedom to select the time and place of accessing the Internet content. We are not referring to 200-metre modem cable here, but to wireless access. Many airports and hotels already provide 802.11 standard WLAN access to the Internet – all that customer needs is an 802.11 Network Interface Card (NIC) in the PC. WLAN speeds provided by the 802.11 family of standard operating at 2.4 GHz frequency band extend at the moment up to 11 Mbit/s. Similarly, high-end mobile phones have evolved into wireless terminals supporting browsing (with Wireless Access Protocol, WAP) and e-mail delivery. For cellular access, protocols have been developed with better support for Internet content, including General Packet Radio Service (GPRS) and Universal Mobile Terrestrial System (UMTS). Again, the basic scheme for browsing the Internet is of client/server type for WLAN access, GPRS, and UMTS. Because of increased support for user mobility, services dedicated to reaching the mobile user are becoming increasingly important. An example of this type, the client–server paradigm can be used for implementing instant messaging service, differing from email by the requirement of rapid delivery of message. One of the first such services was the SMS of GSM, recently extended to MMS supporting also pictorial content. Same kind of services have been developed also for the general purpose Internet. Extending this idea beyond pairwise person-to-person messaging leads to multiparty communication such as online chatting (web chat). It is

14


useful to note that often also the person-to-person services make use of a server in the network, which takes care of distribution of the actual messages. A new class of services, different from the traditional client–server paradigm and related to mobile users, is emerging, called push-type services. To provide an example of this, a research engineer reading his e-mails in the airport using 802.11 WLAN access could receive on his display an unsolicited advertisement for a perfume far too expensive for his income level on offer at the nearby tax-free store. Push-type services require a way of identifying the target mobile host. Push-type services are possible also in GSM networks. An equally novel type of service, made possible by the Internet, is point-to-point real-time communication over the Internet. Voice over IP (VoIP) clients for PCs can be downloaded from the Internet that contain audio and/or video coding/decoding function as well as protocols for sending audio/video samples in packetswitched networks. This makes it possible for two such clients to contact each other directly, if they know each other’s DNS names or IP addresses. This kind of solution is not very scalable, however, since the end user is left with the task of maintaining a “telephone directory” of callees. A Call Processing Server (CPS) such as a Session Initiation Protocol (SIP) proxy is typically used for interfacing to terminal availability information. Also, the Internet of today does not automatically provide good enough quality for a VoIP call without signalled quality support. Thus, a practical solution typically involves a directory server as well as some means of providing service quality support for the connection. These examples only scratch the surface of possible Internet services. The ones described above are among the most well-known ones. As is evident from the examples, the Internet is a good platform for creating new kinds of innovative services, provided that the inherent quality requirements of services can be satisfied. The ITU-T provides a long list of Internet service types in [G.1010]. In [Y.1541], the following summary classification for Internet services is given in Table 2.1: The following types of Internet communications have been identified so far: • Delivery of real-time content such as audio or video. This includes both conferencing and streamed content. • Delivery of data-type content such as e-mail.

2.1 SERVICES ON THE INTERNET Table 2.1

15

Draft IP QoS classes  International Telecommunication Union

QoS Class

Applications

0 1 2 3 4 5

Real-time, jitter-sensitive, high interaction (VoIP, VTC) Real-time, jitter-sensitive, interactive (VoIP, VTC) Transaction data, highly interactive (signalling) Transaction data, interactive Low loss only (short transactions, bulk data, video streaming) Traditional applications of default IP networks

Source: From [Y.1541].

• Interactive client–server applications. This category includes browsing and messaging involving a network server. There may be multiple degrees of urgency within this category, ranging from web browsing to real-time remote control of machinery. • Server-initiated services. This category includes “unsolicited” services such as receiving of advertisements. Although the actual content may fall within data-type or real-time type content discussed above, this is a separate category for the reason of not being requested by the terminal. Let us next take a closer look at the diverse types of content can be delivered over the Internet. A crude summary of some of the most common types is given in Table 2.2, and more elaborate discussion will follow later in this chapter. The diverse nature of the types of services sets certain requirements of the service quality support on the Internet. Definition of the conceptual framework, as well as a description of the mechanisms needed, form the fact matter of this book and are shown in Table 2.2. The mobility aspects of Table 2.2 types

Summary of some of the most common Internet service content

Internet service E-mail HTTP page Streamed content Instant messaging/ web chat Music file download Push-type advertisement Multimedia call

Request/reply?

Content delivery time

Continuous content?

No Yes Yes Yes

Not critical Interactivity required Medium Interactivity required

No No Yes No

Yes No No

Not critical Not applicable Short

No No Yes

16


service quality support are not a central topic in this book, but will be referred to where appropriate.

2.2

DEFINITION OF A SERVICE

On the Internet, the definition of service in general is a difficult issue [RFC3052]. The open standards environment characteristic of the Internet makes it possible to devise services with much greater freedom than in the Intelligence Networks (IN) environment. The SIP framework of the Internet Engineering Task Force (IETF), for example, provides for building blocks for reachability and identity services, and – together with the Session Description Protocol (SDP) – makes it possible to signal application requirements between two ends of the communication. A practical consequence of the preceding facts is that the idea of standardizing services is no longer valid [RFC3052]. Thus, we shall adopt a broad view here based on classification of services. There is a long body of experience of implementing services within the telecommunications industry. The basic reason for this is that in the communications model of telephony the services assurance is provided by the network, whereas terminals (telephones) are relatively simple. Subsequently, precise service definitions are required to provide service quality end-to-end also in the presence of multiple commercial operators. In addition, especially the service implementation of mobile telephony requires a sophisticated service quality requirement definition. For this reason, telecommunication services are used as a framework and point of comparison in the following. The original telecommunications service, voice telephony, has been complemented with services such as call forwarding, voice mailboxes, and A subscriber (caller) number display for the B subscriber (callee). The paradigm for supporting this in the POTS environment is called Intelligent Networks (IN), making possible the creation of new services in the world of circuit-switched telephony. The TeleManagement Forum defines service from a telecommunications point of view as follows [SMH01]: Service – a telecommunication service is a set of independent functions that are an integral part of one or more business processes. This functional set consists of the hardware and

2.2 DEFINITION OF A SERVICE

17

software components as well as the underlying communications medium. The above definition is a fairly high-level one. Another approach is adopted by the 3rd generation partnership project (3GPP), viewing services from a technical support perspective. The 3GPP QoS framework provides the following set of definitions related to services [22.105]: Bearer service: A type of telecommunication service that provides the capability of transmission of signals between access points. Service Capabilities: Bearers defined by parameters, and/or mechanisms needed to realize services. These are within networks and under network control. Service Capability Feature: Function offered by service capabilities that are accessible via the standardized application interface. Services: Services are made up of different service capability features. For the present purposes, it is sufficient to know that the concept of “bearer” is an abstraction for service quality support class provided by the network. Comparing the two definitions above, services can be viewed as being a part of business processes from above (by “the suits” in Internet terminology), and being made possible with service quality support mechanisms from below (by the engineers). In telecommunications, the management of services has been an important issue. According to [ECN02], standardization of service management framework in telecommunications industry has not been successful in the sense that all aspects of service management conform to a standard. On the other hand, standards have been created for relevant interfaces for the purpose of interoperator service management. In this book, the viewpoint is not that of standardized services, but of management and other protocol interfaces that can be used for constructing services. When the interfaces are based on open standards and the concepts used in specifying service support across business parties are involved, the lack of standardized services can be turned into an advantage for all parties involved: the customer, the network provider, and the service provider.

18

2.2.1


End user service versus provider-level services

A useful conceptual division for bringing structure into the discussion about services is that between end user services and providerlevel services. End user service means the service as experienced by an end user (single instance of a service), whereas provider-level service definition is typically concerned with an aggregated view of individual sessions. An example of studying services at end user level is a study to what extent of user experience of e-commerce is satisfactory. As will be discussed in Section 2.3, this requires the definition of suitable metrics, and a controlled means of performing the measurement. Continuing the e-commerce example, the provider-level service would view e-commerce sessions en masse, on an aggregated level. The e-commerce service provider would probably look at the overall average number of transactions per hour, broken down according to time of day, taking an example. Another example, an Internet Service Provider (ISP) providing connectivity for home customers is likely to be able to look at history data of average load in different parts of the network, including Digital Subscriber Line Access Module (DSLAM) and the link towards a Point of Presence (PoP) in backbone network. A connectivity provider for service operators would likely look at the loading level on leased lines towards service providers and towards the backbone network. Now let us assume that Mary Ann, the owner of a corner shop grocery buying her fruits in Internet auctions, wants to get an Internet connection to take care of her bidding and other financial matters of her business using Asymmetric Digital Subscriber Line (ADSL) access to the Internet. What is she to do? Mary Ann will have an agreement with her ISP saying, for example, that her access line maximum throughput is 1024 kbit/s downlink and 256 kbit/s uplink. Having experienced problems with congestion before, Mary Ann may not be satisfied with the theoretical access line maximum throughput only, but require guarantees about average throughput available between the Internet (PoP) and DSLAM also during peak hours, for example. Capacity-wise, this throughput requirement would be a component of an end user service level agreement (SLA) between the ISP and Mary Ann. The

2.2 DEFINITION OF A SERVICE

19

SLA brings with it the question of how the fulfilment of the agreement can be verified by the customer. It is possible that the bank Mary Ann is a customer of is using a service provider, let’s say an Internet fruit auction site, which does not belong to the domain of the ISP the bank is using for Internet access. The presence or absence of direct peering agreement between these two can affect the end user service quality experienced by Mary Ann. If Mary Ann were to expand her business (and presumably increase traffic as well), she might inquire about the inter-provider service level agreement in deciding which ISP to use, especially if more than one critical service were at a stake. Please note that at this stage the agreement between Mary Ann and the service provider becomes less of one between end user and an ISP and more like a peering agreement. It is also possible that the fruit auctioning site does not connect directly to the ISP domain, but that there’s a separate long-haul backbone operator involved. In this case, all inter-operator SLAs potentially affect the service quality. So far, the example has concentrated on throughput. The next step in enhancing service quality is being able to ask for and receive guarantees for different kinds of services. In addition to auctioning and e-commerce transactions, the ever energetic and technically savvy Mary Ann has decided to switch her telephone traffic from POTS to VoIP. She decides that this means that VoIP calls must receive priority delivery, e-commerce and auctioning transactions must receive high quality treatment, and e-mail and other web browsing use the remaining capacity of the agreement between the ISP and Mary Ann’s enterprise. In order to be able to promise this, the ISP requires Mary Ann to characterize the flows for each transaction types. As we shall see in the next chapter, operator needs this information to implement service quality cost-efficiently. Collecting the essential content of the above little fable, the following phases related to service quality can be identified: 1. Inherent service quality requirements need to be understood. For example, a VoIP call has strict limits on allowable delay but can tolerate some packet loss. TCP-based services such as browsing will adapt to available bandwidth, but throughput of individual sessions is enhanced by minimizing variations in Round-Trip Time (RTT) and available bandwidth. 2. The volume of each service needs to be estimated. What is the peak-hour usage of each service and when does it occur?

20


3. Acceptable end user service level for each service type must be definable. For services such as VoIP, there is not much freedom in selecting service quality except for choice of coding scheme. For browsing, on the other hand, the average throughput of non-critical sessions can possibly be throttled down during peak hours. 4. Service flow characteristics need to be defined. How large is the volume of traffic for each service type resulting from the previous steps? 5. A SLA is made between end user and connectivity provider. 6. Operator and service provider use appropriate mechanisms for fulfilling the promised service level (provider-level SLA). The operator may send reports of the measured SLA level, and the service provider makes his/her own measurements to doublecheck the situation. 7. The end user may wish to have means of verifying the conformance of service to SLA. The emphasis in this section is on defining characterizations of service quality characterizations, that is, end user SLA-related issues. The inter-provider SLA issues are discussed in Chapter 6. Some means of SLA verification by the end user are referred to in Chapters 4 and 7.

2.2.2

About service instances and service events

Considering a single service type such as a HTTP browsing, the aggregate service – provision of HTML content – is used via service instances, or user browsing sessions to the server. A single service instance, on the other hand, can often be considered to consist of a number of service events. For example, the service instance comprising of browsing the BBC website would consist of service events that are HTTP query/reply pairs. For client–server type interaction, the service event roughly corresponds to the application transaction in [SMJ00]. Generalizing, for the purposes of the present book, service event is a distinct, measurable part of a service instance that can be clearly defined. See Table 2.3 for examples of service event types. For the client–server case, the definition of a service event is relatively clear. In the case of telephony, on the other hand, such

2.2 DEFINITION OF A SERVICE Table 2.3

21

Some Internet services and service event types

Service

Service event type

Note

News summary WWW home page

HTTP request + HTTP reply

Two-way service event (client-serverclient).

IP telephony

Call set-up signalling message

Uses TCP (for example), may have service quality requirements.

Transmission of voice sample from sender to receiver

One-way service event.

Authentication

Request/reply.

Multiple encrypted HTTP requests using forms

A variable number of two-way service events.

HTTP interface to client’s bank account

a definition is not equally easy. The service event could equally justifiably be defined to be any of the following alternatives: • end-to-end delivery of a voice sample; • end-to-end delivery of a talkspurt (a sequence of voice samples bounded by absence of voice signal); • end-to-end delivery of entire voice content of a telephone call. Luckily, no overarching definition for service event is necessary for this book. A service event is a definition to uniquely describe service requirements, and can be used flexibly according to need. It is important to separate the parts of service instance having different characteristics and service quality requirements. In the case of a VoIP call with application sharing, for example, the following distinct service event types can be enumerated: • connection set-up signalling (e.g., H.323 or SIP); • transmission of VoIP media stream (e.g., G.723.1 or Adaptive Multi-Rate codec, AMR) or a part thereof; • transmission of application data (most likely TCP). Each of these service event types has specific quality requirements, some coming from standards, and some from less official design targets. Some examples of service events are provided in Table 2.3.

22

2.2.3


Reference model for this section

For the purposes of the present section, a simple reference model is described here. More advanced reference models are discussed in Chapter 5, after appropriate network QoS mechanisms have been described. To start with, let us first list the different types of services on the Internet there are. As illustrated by examples in Section 2.1, the most familiar one is the client–server type service based on requests and replies (see Figure 2.2). However, services exist where the endpoint is another user. Examples of this connectivity/service type paradigm include messaging, presence and telephony/conferencing services. The latter paradigm is used as a high-level reference model for this book, as it includes the single-endpoint client/server model as a special case. SLAs can be used between the service provider and connectivity provider, between connectivity providers, and between connectivity provider and end user. When a connectivity provider supports

End user SLA

Access provider

Service provider

Client Server Inter-provider SLA

Service provider Server Inter-provider SLA End user SLA Client

Connectivity provider

End user SLA Client

Figure 2.2 Client–server (upper figure) and connectivity/service (lower figure) paradigms illustrated

2.3 SERVICE QUALITY ESTIMATION

23

Aggregate service

Service instance

Service event

Service event

Service instance

...

Service instance

Service event

Service event

Type A

Type B

Type C

Figure 2.3 The relation of concepts ‘‘aggregate service’’, ‘‘service instance’’, ‘‘service event’’ and ‘‘service quality requirement type’’ as used in this book

service quality, the SLAs between different parties must be able to express service quality requirements. Service, as seen by an end user, consists of an instantiation of the service, in turn comprised of one or more service events. A single service instance can contain multiple classes of service events, a major aspect of classification being related to the need for particular service quality requirement type. This is illustrated in Figure 2.3. As will be discussed later, the network typically handles services in terms of service quality classes. Service Level Agreements and related technologies will be discussed in more detail in Chapter 6.

2.3

SERVICE QUALITY ESTIMATION

The desirability of a customer having the means to verify service quality was referred to before. In addition to verification aspects,

24


a meaningful definition of service quality in a SLA must be based on an understanding of how service quality is measured. Thus, let us next consider how service quality can be estimated. Various individual aspects pertaining to serving the customer can be measured. For the Internet, measurements of objective characteristics such as delays and packet loss percentages have been made since wide-scale deployment of the Internet [Bol93, Pax97]. This is a very important topic for this book, and examples of measurable quantities are discussed in Section 2.3 below. Standardized means of making the measurements and utilizing the information will be discussed in Chapters 4 and 7. The numerical measures of individual characteristics are not enough for formulating a framework for service quality assessment. The corner shop grocer – very justifiably – doesn’t necessarily want to how many milliseconds it takes for the sentence “bag of carrots” to traverse from Edinburgh to Glasgow or how many audio samples were lost during the telephone call. Mary Ann – the grocer – wants the order to be placed and understood correctly by Pierre, the wholesale retailer. What needs to be measured is the effect of objectively definable and measurable events of perception process. Especially for the purposes of end user communication of service quality characteristics, they often need to be presented to the end user in a “palatable” form. One approach is to express service quality in terms of perservice concepts. Due to the potentially large number of services, this leads to an unnecessary diversification of terminology. The approach in this book is to attempt to formulate a set of service quality-related characteristics that span the range of different services, while attempting to be concrete enough to be understood by non-technical people. Services can then be conceptually be made to correspond to a subset of each characteristic. Before delving into discussion about these characteristics, we shall study the means of assessing service quality for individual services for the purposes of technical concreteness.

2.3.1

Measures of end user experienced service quality

Table 2.4 lists some factors affecting the end user experience for telephony, and a corresponding generalization for Internet services. For telephony, a mathematical model called the E-model


25

Table 2.4 Factors affecting service quality for telephony and Internet services in general Telephony

Internet services

Psychological factors – importance of communication

Psychological factors – importance of communication

Availability of service


Call set-up time

Service invocation time

Constancy of service quality

Constancy of service quality

Surroundings/background noise

Surroundings

Terminal audio setup: microphone/loudspeaker/headset

User interface for service client

Audio coding scheme

Protocol representation of service instance

TCP/IP protocol stack implementation

TCP/IP protocol stack implementation

Operating system – scheduling

Operating system – scheduling

Service quality support on the Internet

Service quality support on the Internet

[G.107] has been developed by ITU-T for the purposes of end-to-end planning. The model takes into account mostly technical factors along the telephone connection between the “A subscriber” and “B subscriber”, to use the telephony jargon. Similarly, the factors contributing to user experience in IP telephony have been divided into ones originating from the terminals (hosts), and the transport network in between [TIPHON2]. The measurement of end user service quality experience, however, is not fully captured with mathematical modelling only. These issues will be discussed in more detail below. In the case of telephony, the need for measuring end user service quality experience was recognized early on. The effect of a lost voice sample is perceived very differently depending on which kind of phoneme it coincides, with what kind of audio coding scheme is used, and how large a share of the audio samples are lost. The Mean Opinion Score (MOS) [P.800] is a scheme for performing controlled evaluation of subjective voice quality

26


using listening tests with untrained subjects. The result of a MOS test, a MOS number, establishes the relative average ranking of the voice sample among the entire set of voice samples the test consists of. This ranking is obtained through pairwise comparisons of voice samples, some of which are reference – that is, noncoded – samples. In the rest of the samples, different voice coding schemes may have been used; and some have been subjected to deliberate quality degradations such as packet losses. Obviously, the samples used in the listening test, as well as the nationality of listeners, as well as other cultural aspects, affect the result. Nevertheless, given the environmental factors, listening tests are the most reliable measures of real end user experience at the moment. Subjective tests yield reliable results, but require some effort and investment – most listeners expect at least a cola drink and a slice or two of pizza as a compensation for their investment of time into the experiment. (The author wonders how the results would be affected if finer beverages and cuisine were served instead of junk food.) The analysis of the results can be automated to some degree, but requires an analysis of the applicability of the results by trained personnel, due to technical as well as cultural context aspects referred to earlier. Not surprisingly, so-called objective methods have been developed for automated measurement of MOS values. These methods analyse the difference between an undistorted reference signal and a signal that has passed through the system to be measured. The analysis models the functioning of human cognitive processes. Some common objective methods are Perceived Speech Quality Measure (PSQM) [P.861] and Perceptual Evaluation of Speech Quality (PESQ) [P.862]. There is no need to limit the principle of subjective testing and establishment of average ordering scale for quality to voice telephony only. Indeed, the MOS principle has been applied to gaming on the Internet, for example. Most likely, there is room for research and development in this area in the future.

2.3.2

Recency effect

The user experience of quality is not constant with time when quality varies [TIPHON-5; Cla01]. Rather, there is a recency effect, which – simply put – means that the memory of momentary poor quality with fades with time. According to the sources cited, the


27

Recency effect 100 Quality

80 60 40 20 0 −10

−8

−6

−4

−2

0

2

4

6

8

10

Time

Figure 2.4 Example of recency effect for quality reduction of 20 units, with α = 1. Time and quality are measured in arbitrary units

recency effect for MOS can be modelled by an exponential recovery curve. If the long-term average of experienced quality level is N and the momentary poor experienced quality level is M (M < N ), this modelling of the recency effect yields the qualitative behaviour for experienced quality Q according to the equation Q ≈ N − (N − M ) e−αt

(2.1)

where α is a measure of the strength of the recency effect: the larger the α, the quicker the memory of poor quality fades. Figure 2.4 shows by way of an example the temporal development of the recency effect for a quality dip of 20 units according to equation (2.1). The recency effect is useful in illustrating the effect of momentary poor quality: if the “quality dip” in Figure 2.4 does not coincide with important piece of communication, the end user will probably forget and forgive it, unless further quality dips occur in too short a time.

2.3.3

Psychological factors

To put the service quality assessment into wider context, the viewpoint of Bouch et al. is illuminating [BSD00]. At the end of the day, service quality is the human perception of what happened. Using telephony as an example, obviously the objective quality characteristics are paramount to the caller’s experience, and their impact on reproducible quality perception can be modelled with varying degrees of success. However, the degree to which poor experienced quality matters to the caller depends on the psychological context

28


of the telephone conversation. If the subject of telephone conversation is of high importance, the impact of poor quality is greater than would be the case for mere casual conversation. The effect of psychological factors is also accommodated in the ITU-T recommendation cited earlier [G.1000], by differentiating QoS perceived by the end user from QoS required by the end user. A practical conclusion from the above is the desirability of having a high-quality communication medium at users’ disposal when the situation calls for it. The user might be willing to pay more than the usual subscription price in such situations.

2.3.4

Summary

The telecommunications industry has long experience of assessment of end-to-end service quality, including different technical factors in the delivery chain. One of the tools is a subjective enduser test based on pairwise comparisons of service quality of manipulated samples. Many of the factors can be generalized into other kinds of services within the Internet domain. Research in speech telephony user experience suggests that the memory of a momentary poor quality fades with time. On the other hand, the work of Bouch et al. indicates that in usage scenarios perceived as important by the user, even momentary service quality may be important. Thus, in applying MOS type techniques, it may be useful to add some kind of “safety margin” to the results of subjective evaluations performed in the atmosphere of cola drinks and pizza slices.

2.4

SERVICE IMPLEMENTATION ASPECTS

The implementation of services and the platform they are run on affect the end-to-end service quality experience. Two issues of importance are discussed in this section: the choice of transport protocols, and adaptability of the service itself.

2.4.1

Choice of transport protocols

When port-based multiplexing on top of IP is desirable, at present either TCP or UDP is typically used for this purpose.

2.4 SERVICE IMPLEMENTATION ASPECTS

29

Signalling Common Transport Protocol (SCTP) is in test use at the moment, but not widely deployed outside special applications. The two layer 4 protocols – using International Standardization Organization/Open Systems Interconnect (ISO/OSI) parlance – have different properties. TCP provides congestion control and adaptability to available bandwidth based on acknowledgments of received packets to the sender by the remote end. TCP also provides for applications reliability towards packet loss in the form of retransmissions of lost Protocol Data Units (PDUs). The precise functioning of TCP depends on the variant of TCP algorithm in use. UDP provides neither congestion control nor adaptability. Only an error detection scheme is provided. Reliability and/or adaptability need to be implemented in the actual application. For realtime content, Real-Time Transport Protocol (RTP) and Real-Time Control Protocol (RTCP) have been specified for this [RFC1889]. The service quality implications of TCP and UDP are analysed further in Section 2.5.

2.4.2

Throughput adaptability of services

Adaptive services can help alleviate the effects of congestion, whether it is caused by either reason listed above. Different kinds of strategies are possible to implement the adaptation. The TCP provides adaptation to available capacity on the transport layer, but this does not guarantee adaptation of the service itself. Some video codecs such as H.263 are able to change frame rate when packet loss occurs. The Adaptive Multi-Rate Codec (AMR) is an example of audio coding scheme that keeps the audio frame rate constant, but can adjust capacity in the range [4.75, 12.2] kbit/s. The G.723.1 codec can use two different bit rates. In general, services can be classified according to their ability to adapt to changing throughput as follows. • Constant bit rate (CBR) or almost-CBR services. A Voice over IP call using CBR codec such as G.711 falls into this class. There is a single class of end user experience, which can be degraded to a certain degree before turning into non-usable. • Adaptive applications that can do limited amount of adaptation to throughput. A Voice over IP call using AMR or G.723.1 codec

30


is able to adapt the output rate within certain bit rate ranges. The choices reflect different degrees of end user experience that can be predefined. • Elastic applications that can adapt to available bandwidth on a wide scale. File Transfer Protocol (FTP) download is an example of this. It should be noted that the end user may be unhappy for a download time of four hours of latest Linux distribution package, even though the FTP protocol is extremely flexible with respect to available bandwidth.

2.5

INHERENT SERVICE QUALITY REQUIREMENTS

Certain services have requirements stemming from their very nature. Telephony necessitates an audio signal to be delivered quickly enough to maintain interactive communication between the participants of the conversation. On the other hand, an e-mail message does not need to traverse the network equally quickly. In an e-mail message, flipping of individual bits due to bit error in transmission cannot be tolerated if the meaning of the message is to be kept identical to that devised by the author of the message. In VoIP telephony session or a GSM call from a mobile phone to another, for example, a limited amount of bit errors – and audio frame loss – can be tolerated without losing the intelligibility of the spoken word.

2.5.1

Service quality characterizations in standards

In the present book, the requirements that impact on the service quality mechanism configuration of the network are of particular interest. Depending on the source, different set of service quality characteristics are listed. ITU-T lists the following key parameters impacting on user experience [G.1010]: delay, delay variation, and information loss. In addition, [Y.1541] also includes rate of errored packets. 3GPP defines the following characteristics for information quality definition [22.105]:

2.5 INHERENT SERVICE QUALITY REQUIREMENTS

31

Maximum transfer delay Transfer delay is the time between the request to transfer the information at one access point to its delivery at the other access point. In clause 5.5 requirements on maximum transfer delay is defined. Delay variation The delay variation of the information received information over the bearer has to be controlled to support real-time services. The possible values for delay variation are not a limited set, but a continuous range of values. Bit error ratio The ratio between incorrect and total transferred information bits. The possible values for Bit error ratio are not a limited set, but a continuous range of values. Data rate The data rate is the amount of data transferred between the two access points in a given period of time. The 3GPP specification 22.105 goes on to define end user expectations for different kinds of services such as multimedia calls, streamed multimedia, Internet browsing and data transfer. The service quality support is grouped into four traffic classes: conversational, streaming, interactive, and background. The specification 22.105 also defines levels of Bit Error Rates (BER) and Transfer Delays that will be supported in environments of varying degrees of mobility. We shall discuss the 3GPP QoS model in more detail in Chapter 5. Another example of service quality requirement definition is provided by ETSI’s IP telephony project TIPHON. Currently they cover only telephony. The end-to-end service quality characterizations used by TIPHON are as follow [TIPHON-2]: • overall transmission quality rating (R); • listener speech quality (one-way non-interactive end-to-end speech quality); • end-to-end (mean one-way) delay. This trio is a result of analysis of information provided by available characterizations.

32


The R-value is given a mathematical model designed by ITUT for planning purposes, and is computed using the previously mentioned E-model [G.107]. The R-value is a scalar with a maximum value of one hundred. The higher the value, the better the end user experience is according to the model. Listener speech quality is given in relation to well-known speech codecs. Listener speech quality can be measured using the methods described in Section 2.3.1. End-to-end delay is expressed in milliseconds. Four TIPHON Speech QoS classes are defined: “Best”, “High”, “Medium”, and “Best Effort”, and are given definitions addressing different codecs, terminal service quality support mechanisms, and the aforementioned end-to-end service quality characteristics. Based on the 3GPP and TIPHON service quality requirement definitions as well as others, a brief list for individual service instances can be attempted. On a high abstraction level, the requirements of an individual end user is service events fall into three categories: • Timeliness of service delivery. This is a measure of the completion of an entire service instance. • Sufficient throughput for service. Measured over an extended period of time, this characteristic can be used to estimate the capacity available for an adaptive or elastic service. Measured over short intervals, it may be connected with PDU loss. • Reliability of service delivery. Some service event types require reliable delivery, whereas others can either tolerate missing PDUs or implement reliability on the service level. While the above list is in principle exhaustive, it turns out that a different kind of categorization is useful to properly address the needs of service level specifications for entire services. These are listed in the following. An important addition to “obvious” characteristics such as timeliness are availability requirements. While studying the categories, the reader is invited to consider what kind of issues may arise when specific services are implemented in multi-provider environment. This is a topic to be discussed in more detail later. In what follows, topics relevant to different requirement categories are discussed first, and then the findings are summarized in the form of generic guideline for service definition.


2.5.2

33


Taking care of personal bills with one’s home computer has been popular in some parts of the Europe for more than a decade. Persuading home users to pay their bill using computers instead of queueing for the service counter necessitates that getting access to the computer of the bank rarely fails. Having to re-enter multiple 10-odd-digit numbers into an HTTP form gives rise to sharply heightened risk of physical violence towards computer equipment at hand. Implementing e-banking service at times of high user load needs planning on the aggregate service level. This becomes an important issue especially when the service is composed of service events of different type (see Figure 2.5). Availability of service is typically measured in percents of “service uptime”. To measure service uptime, a definition is needed for successful service instance. Availability is meaningful for aggregate service, not individual service instances. In case of service instance consisting of multiple critical components (service event types), the lack of availability of service is a sum total of periods of lack of availability of one or more of the critical components. For example, let us assume that a service S requires that components A, B, and C are in place and the statistics for unavailability of these are as follows in Table 2.5. Then the availability for the whole service S would be 100% − (0.1% + 0.2% + 0.1% − 0.05%) = 99.65%. 1

WWW server of a bank Client

2

WWW server of a stockbroker

Figure 2.5 Service involving two service events: fetching a HTTP page from bank server (1) and fetching stock exchange indices from a stockbroker’s server (2)

34

SERVICE QUALITY REQUIREMENTS Table 2.5 Component

Availability Unavailability %

A

0.1

B

0.2

C

0.1

A and B

0

A and C

0.05

B and C

0

An important issue to be noted here is the need to be able to compute the overlap of per-element unavailability figures. As we shall see later, per-element data polling in general is not sufficient, but a way of correlating single-element data is needed for efficient and accurate reporting. ITU-T has defined related parameters as IP Service Availability (PIA) and IP Service Unavailability (PIU) [I.380].

2.5.3

Continuity of service

Service continuity is of importance in invocation of a service event A, being part of service instance S leads to invocation of another service event A’ in other location, and the user’s service including A’ instead of A thereon. This could be viewed as a “service handover”. Since A’ may be implemented in another server than A, end user experience of service quality provided by A’ may differ from that provided by A. If A fulfils the criteria for a successful service event invocation but A’ does not, service S is not continuous during the switch-over. An example of this is HTTP redirection. For some service providers, the user may be redirected from an US-based server to a European one, the latter “mirroring” the content of the former one. This is one form of load balancing and makes sense also from the point of view of traffic volumes in long-haul backbones. If the European mirror site or its network connections are congested, however, the HTTP redirection may lower userexperienced service quality.


35

If the user is mobile, continuity will be affected by network connectivity support mechanisms. Handovers between WLAN access points are an example of a connectivity service being provided at multiple locations. Cellular mobile networks have advanced signalling schemes for handling service continuity during handovers. Analogously, going beyond simple best-effort implementation of Internet access using WLAN access points requires special support mechanisms. This is true even if terminal mobility itself would be solved protocol-wise, for example, using Mobile IPv6 (MIPv6). Thus, in the case of mobile terminals, the service support mechanisms of the mobility mechanism are important. Further, the performance of applications is affected by the degree to which they have been tailored for the mobile environment. Continuity of service may be included in service availability, or provided separately. A potentially useful form of presenting service continuity is the percentage of successful “service handovers”, classified according to the parties of the handover. Time-of-day information may be useful as well to identify possible connections to diurnal loading variations.

2.5.4

Delivery time end-to-end

Delay, also known as latency, is an oft-quoted service quality metric. Here, to be consistent with the chosen definitions as well as with different kinds of service contents, a generalization of endto-end delivery time is used instead. Delivery time is applicable to service events or smaller entities, the smallest such entity in the Internet being an IP packet. Since we are interested in delivery time end-to-end, delivery times of possible link-layer fragmented PDUs are not of interest to us. In addition to telephony as mentioned previously, many services require some degree of interactivity to function properly. For example, the home user paying a bill expects something to happen within a few seconds of clicking on the “pay” button. For a client–server type Internet application, a service instance consists of multiple service events, and – to give an example – it is short response time for individual service events that is desirable. In this case, it is the delivery time of service event that counts. The delivery time of a single service event or its part may be limited by the available bandwidth. We will discuss such cases in

36


Section 2.5.5. When throughput is not a bottleneck with respect to the average amount of data, the service instantiation time on the Internet is affected by many factors. A few potential reasons for increasing or varying service delivery time are listed below: • The detailed implementation of application in the user terminal may be inefficient. • The server application may experience insufficient Central Processing Unit (CPU) resources, possibly due to inefficient socket programming. • Transport layer protocol – TCP or UDP. • TCP/IP stack at either end may be sub-optimal performancewise. • Some routers or links of the IP network may be misconfigured. • In long-range communications, route flapping may take place. • Some parts of the IP networks connecting the two communicating hosts may be congested. A full account of all the factors is beyond the scope of the present book. Service delivery time is measured in milliseconds. A distinction needs to be made between one-way services and two-way service response time. Delay for one-way service events are typically measured from service source to destination. An example of this could be the telephone conversation where one of the participants utters a word into the telephone receiver. In such a case, the end-to-end delay would be measured as time length of the period of time between the speaker making the first waveforms of the first word to the time that same sound issues from the telephone receiver at the other end of the communication (see Figure 2.6). ITU-T limits for mouth-to-ear delay in telephony are as follows: • 0–150 ms: acceptable for most user applications. • 150–400 ms: acceptable provided that administrators are aware of transmission time impact to transmission quality of user application. • More than 400 ms: unacceptable for general network planning purposes.


Speaker

Listener

Time

Listener

Time

Speaker

37

Figure 2.6 The difference in measuring one-way service (left) and two-way service (right)

Table 2.6 ITU-T’s draft recommendation for delay classes for Internet services U = unspecified QoS Classes Network Nature of Class 0 Class 1 Class 2 Class 3 Class 4 Class 5 performance network unparameter performance specified objective IPTD Upper bound 100 ms 400 ms 100 ms 400 ms 1 s U on the mean IPTD (Note 1) Note: The class numbers refer to Table 2.1. Source: From [Y.1541].

The draft ITU-T recommendation for transfer delay (IPTD) for general Internet services is as shown in Table 2.6. Two-way services are typical of the client–server model of the Internet. A client sends a message requesting a service, and the remote end sends back a reply that makes up the server part of the service event. The delay in this case would be measured from the time the request was issued to the time that all packets of the server response have been successfully received and processed by the client. As can be observed in Figure 2.6, the service time may include processing either cerebral or numerical at the remote end. In the general case, the delay for the server can be different from the delay from the server. For telephony, examples of delay contributions can be found in [G.114] and [TIPHON-6]. Often a statistical estimator is used instead of delivery time for a single service event. Commonly used estimators include the average delivery time, standard deviation, and percentiles of the delivery time distribution. For more complete description, the delivery

38


Average capacity

Reliability

Latency

Support for continuous PDU transmission

Figure 2.7 Delay-centric view of interrelation of some important service quality characteristics

time distribution can be used. The characterization of delay will be discussed more in Chapter 5. When service delivery time is not critical, service instantiation – or part thereof – can be displaced in time, making it possible to provide better throughput and packet loss treatment for it. Conversely, requiring guaranteed average capacity, reliability and/or support for periodic transmission may have an effect on end-to-end delay. The interrelation of different service quality characterizations for delay-critical applications such as multimedia conferencing is illustrated in Figure 2.7. It is useful to note that a different kind of a picture could result from studying other types of services.

2.5.5

Throughput

For simple data transfer type services such as downloading a large piece of Internet content in the form of a digital photograph or MP3 file, it is the overall throughput during the delivery that counts. For service events, which include transfer of non-trivial amount of content, service delivery time is linked to the volume of data transferred, and to the throughput of the transfer medium accessible for the service instantiation. For a customer downloading a MP3 file, the service delivery time is determined by the average


39

throughput during the file download. For this type of service, the properties of the communications protocols are important. TCP congestion control algorithm is affected by round-trip time (RTT) and throughput impacts of all components of the end-to-end delivery path. Downloading time may be reduced by using accessoptimized versions of protocols used to transfer the content. Throughput of TCP-based services, in general, can be related to end-to-end delay bound and packet loss bound. An example of the first of these, what counts for FTP transfer is the total volume of data transferred, not possible variable queueing delay during the transfer. It should be noted, though, that the overall throughput for TCP-based services is usually optimized when variability in RTT and throughput is minimized [PFT + 98].

2.5.6

Support for continuous service data unit transmission

Telephony is a prime example of a service that requires service data units (SDUs) to be transmitted periodically. Taking the G.711 coder/decoder (codec) with oft-used audio frame size as an example, an audio sample of 160 bytes would be transmitted every 20 milliseconds. Transport protocol headers add further to the total IP packet size. Let us assume that the Voice over IP (VoIP) paradigm is used, and that the voice samples are transmitted to the receiver over the Internet, with RTP [RFC1889] being used to aid endpoint processing by providing time stamps and sequence numbers for individual audio samples. The codec in the source terminal outputs a string of voice samples during a talkspurt, that is, period of audio signal being above a Voice Activation Detection (VAD) threshold level. Examples of sampling rates supported by normal PC audio cards include 8 kHz, 16 kHz, and 44.1 kHz. When an audio signal is below the VAD level, within a silence period that is, no samples are generated. One or more audio samples are transported in a single IP packet. Attaching RTP data to each VoIP packet, the receiver knows in which order and how long apart the samples are to be played out. Delay variations arise along the end-to-end path for reasons discussed in Section 2.5.4. The receiver is able to deal with a limited amount of delay variation and out-of-order delivery of packets

40


by delaying the playout of voice samples. This technique, dejitter buffering, amounts to waiting for packets that have been delayed more than the average in the network. In the case of VoIP, the allowable end-to-end delay limits the size of the dejittering buffer, and hence acceptable delay variation and reordering. Typically dejittering buffer length is constant during talkspurts to avoid deforming the signal to be played out. Streamed audio and video are useful examples of inherently periodic services. Streamed content can be transported using both UDP and TCP. UDP is in general better suited to the needs of a service that involves periodic transmission and is to some extent robust, as loss of a packet does not create retransmission. Despite delay variations caused by mostly unnecessary reliability in transport protocol level, HTTP/TCP/IP has been used for transporting streaming. The reason for this is traversing firewalls at the edge of corporate domains, as typically separate “gates” need to be provided for UDP flows which are by default rejected by domain firewalls. As mentioned previously, packet loss and delay are interrelated for periodic real-time streams. Thus, it is possible to trade end-to-end delay and jitter for packet loss. Even the G.711 codec without any error correction schemes can tolerate some amount of packet loss without losing intelligibility of the message. The better the content coding, the more packet loss can be tolerated. Subsequently, the available bandwidth does not have to support the nominal bit rate of the codec at all times. The basic measure for evenness of periodic PDU transmission is delay variation. The “atomic” delay variation between two adjacent packets ri −1 and ri is defined as t = ri − ti − (ri −1 − ti −1 )

(2.2)

where r and t signify the reception and transmission times of a packet, respectively. The subscript refers to the index (sequence number) of a packet. When RTP is used, also the sending timestamp is known by the receiver and missing packets can be identified. We shall return to definitions and methodology related to measurements later in Chapters 4 and 7. Draft ITU-T recommendation for delay variation (IPDV) of Internet services is summarized in Table 2.7. As with delay, average delay variation and distribution of delay variations can be used.


41

Table 2.7 ITU-T’s draft recommendation for delay variation classes for Internet services  International Telecommunication Union U = unspecified QoS Classes Network performance parameter IPDV

Nature of Class 0 Class 1 Class 2 Class 3 Class 4 Class 5 network unperformance specified objective Upper bound 50 ms 50 ms U U U U on the 1–10−3 quantile of IPTD minus the minimum IPTD


Typically delay variation is expressed in the form of an estimator, of which two are commonly used. Moving average: E (i ) = αd + (1 − α)E (i − 1)

(2.3)

where E is an estimator, d is the latest delay measurement, i refers to the index of a packet and α is an averaging parameter. For the first estimate, E (0) = d . This method is used in the RTP specification [RFC1889], for example. The practical scheme needs to take into account lost packets. Standard deviation of delay time series. As with end-to-end delay, more information of delay variation can be achieved with a delay variation distribution than individual quantiles. It is important to note that the information of delay variation distribution is not fully contained in delay distribution. Delay distribution shows the distribution of individual delays, but does not provide information about temporal correlations between delays. Delay variation distribution yields information about the statistical distribution of delay differences of adjacent packets, but not about longer temporal structures [Rai02b]. The most rich set of information is contained in a measured delay time series. Packet reordering is another measure for evenness of PDU transmission. At the time of writing of this book, IETF is in the process of developing a metric for reordering [MCR + 02]. Reordering takes place when delay variation exceeds the temporal inter-PDU spacing. For non-periodic streams, the temporal inter-PDU spacing may be variable. It could be argued that the use of reordering

42


measure does not bring added information on service quality as compared to atomic delay variation. This is true in case delay variation data are stored as a time series. There are cases in which reordering may be the convenient metric. For example, reordering may be useful for detecting what is happening on lower protocol layers. One of these is end-to-end path involving transmission over links in which link layer transmission technology may cause reordering of PDUs. An example of this is wireless links with reliability enabled using link layer retransmissions. Finally, as noted earlier, certain services have inherent requirement for throughput. A CBR VoIP call is a prime example of this. For other services, the throughput requirement is not an equally black-and-white affair. The concept of utility to be discussed in Chapter 5 reflects this. Some means of estimating throughput for typical applications are discussed in Chapter 4. For the present purposes it is sufficient to note that a full description of support for continuous data transmission is typically related to variations in available throughput. CBR-type applications have a limit above which variations do not affect service quality, given that throughput measurement takes into account end-to-end delay limits, including dejitter buffering.

2.5.7

Reliability of service delivery

The reliability of service delivery relates to individual service events. The decisive questions for reliability are as follows: Is it necessary that all service events be transmitted totally errorless? Is it acceptable that a service event be lost altogether? Can it be corrupted partially and still be considered as acceptable? Loss of service events is not acceptable for a remote user paying his or her bills with a home computer via an HTTP interface. To accommodate this requirement, reliable transport protocol TCP is used. TCP performs end-to-end retransmissions when TCP packets are lost. It is useful to note that PDUs may be lost at layers below the one served by TCP. On the service level, PDU losses beneath TCP do not show up as losses in the sense that an application PDU would be missed altogether. For services involving periodic packet streams such as VoIP or streaming, some degree of robustness is typically built into the service application (codec). The signal form contained


43

in a lost frame can be interpolated from the preceding and following frames using dedicated error-concealment algorithms. Subsequently, packet losses can be tolerated up to a degree that is determined by the coding scheme used. Some other services using UDP transport may implement retransmissions above the UDP layer. The first measure of reliability is the service event loss percentage. To use this measure, the criterion for service event loss must be defined. Beneficially, a measurement period must be defined; and second, a period of time should be defined per event, within which the service or service event must be completed. Please note that due to this definition, service event loss can also occur at L4 with TCP as the transport protocol. For real-time streams, service delivery time and service event loss are typically correlated due to dejitter buffering. Draft ITU-T recommendations for loss rate (IPLR) and errored packet rate (IPER) can be found in Table 2.8. The second measure is service event loss correlation, that is, the number of adjacent service events that were lost during a measurement period (see Figure 2.8). Correlated loss can occur in shared-media of access networks, either due to truly lost PDUs or due to large delay variation. The relation of loss correlation to average loss percentage is not dissimilar to the relation of average delay to average delay variation. Loss correlation as a concept is most useful for services with periodic PDU transmission, as otherwise the arrival process of service events affects the outcome. For VoIP applications, also the length of inter-loss burst packet sequences may be of importance. In such a case, the next more detailed description consists of recording the frequencies of pairs Table 2.8 Draft reliability-related ITU-T recommendations for Internet services  International Telecommunication Union U = unspecified QoS Classes Network Nature of Class 0 Class 1 Class 2 Class 3 Class 4 Class 5 performance network unparameter performance specified objective IPLR Upper bound 1 ∗ 10−3 1 ∗ 10−3 1 ∗ 10−3 1 ∗ 10−3 1 ∗ 10−3 U on the packet loss probability IPER Upper bound 1 ∗ 10−4 U Source: From [Y.1541].

44


LS 1

0

1

2

3

4

LS 2

5

6

7

LS 3

8

9

10

11

12

13

14

Figure 2.8 Service event loss correlation with three loss sequences (LS1, 2 and 3) consisting of 1, 2 and 3 lost events, respectively

of (Lloss , Lseq ), where the variables stand for length of loss bursts and inter-loss burst packet sequences, respectively [Rai02]. Two further measures, the percentage of erroneous service events and the average corruption measure, relate to services that can tolerate corrupted PDUs. For example, typically a Voice over IP codec can cope with degraded voice samples having bit errors in them. Normally UDP rejects packets with bit errors in them, but a version of UDP suitable for bit error-tolerant applications called UDPLite has been proposed, performing error detection only for a specified number of highest-order bits in the voice sample [LDP02].

2.5.8

Support for variable transfer rate

Certain flows are inherently variable in throughput requirements. Examples of these include Voice over IP with silence suppression, where the application flow in the network consists of talkspurts and silence periods. Thus, even for a CBR codec, the bandwidth varies because of talkspurt/silence period variation. Another example is packet video using differential coding, where full picture is sent to receiver on regular basis, and in between these, only differences to the full picture are transmitted. This clearly saves transmission capacity, but introduces burstiness into the encoded flow. A third example is web browsing, where the momentary nominal capacity requirement of a user flow can span multiple orders of magnitude. The three bursty service types listed above are useful in highlighting the relation between the inherent burstiness of a stream and expected quality support for bursty streams. At one end of the scale is VoIP, where also the bursts (mostly) need to reach the received in a timely manner, since they are the actual voice signal. At the other end of the scale is web browsing, where the


45

user often is willing to accept that the capacity available does not adapt to the momentary transfer of a large picture or audio file. Video coding is in between the extremes, even though also for video all content that is played out needs to fit within the jitter buffer. The reason for packet video being classified as having less stringent requirements than voice is that, in the former, the frame rate can be lowered and the picture can be “frozen” for a period of time – something that is not possible in audio. Support for variable transfer rate, in general, requires a way of characterizing the allowed bandwidth variability (burstiness) of the flows. The burstiness characterizations take into account recent history of bandwidth as a function of time. Burstiness characterization methods will be discussed in Section 2.6. When the network is able to support the requested amount of burstiness, the “inprofile” bandwidth variations (bandwidth within allowance) part of the flows become a subset of the support for continuous PDU delivery discussed in Section 2.5.6.

2.5.9

Generic considerations related to service requirements

The issues discussed in this section lead to some observations related to the implementation of general services in a diverse access technology environment. Some of these issues, like the acceptance criteria, will be discussed further later in this book. • Which access methods are considered central for the service? If users with low bit rate access, for example, 56 kbit/s home modem or GPRS access is considered to be an important market segment, multiple types of instantiations of the service may be needed. For example, there can be a high-capacity service instantiation type with more detailed content, as well as a “light” version for low-bandwidth access. Sometimes the end user is able to affect the level of detail of the service, for example, by disabling automatic fetching of pictures in Netscape browser. Sometimes access provider is able to perform translation between formats, such as HTTP-to-Wireless Application Protocol (WAP) translator used by some cellular operators. The best option is to have a service that can detect available capacity and adjust to it. This is

46


especially useful with wireless devices, where the capacity available for Internet access may change upon entering a crowded radio network access cell. Most auto-adapting services such as audio or video streaming and VoIP have mechanisms for detecting the capacity. Whether this is the case or not, it is useful to consider whether the application benefit from QoS situation changes notification from the application interface. A second issue to consider is whether it is useful to deploy applications protocols tailored for the access methods in question. • Service event to be measured needs to be defined well enough. To be able to measure services, the beginning and end of a service event should be clearly defined, including the protocol layer on which the measurement is made. For example, a timing function call A could be executed by a HTTP client immediately before sending the request using a function call to a HTTP implementation library. Timing function B could be executed immediately after the reply is received from another function call. This arrangement would translate to making the measurement on top of a HTTP/TCP/IP stack, starting with the first bit of the request being transmitted by the application, and ending with the last bit of the reply being received by the application. • Acceptance criteria for a service instance must be defined. The service instance may only be considered acceptable if it is completed within certain period of time. • Sampling methodology. Representativeness of sampling and confidence intervals are important issues in all applications of statistics. The basic techniques for these can be found in any good university-level statistics textbook, for example [Kre88]. The application of statistics to Internet technologies specifically will be discussed in the context of traffic engineering in Chapter 4. • Arrival process for service events. The arrival process is affected by three factors: regularity of service event generation by a single user; IP network between user and the server; and number of users supported on a single server. – Are service events from a single user transmitted in a random fashion, or are they perhaps transmitted periodically? If the service events are random, is the inter-event interval distribution known?

2.6 SERVICE QUALITY DESCRIPTORS

47

– How much can the IP network between the user and the server affect the temporal pattern of service events? – How many users does a single server cater for? The higher the number, the closer to Gaussian distribution is the length of the inter-event period. • Capacity requirement. If low-throughput links are included in the targeted service access methods, a trade-off may need to be made between traffic volume and service access time. • Reliability. Is TCP needed? If this is the case and there is packet loss on the IP layer or below, reliability gives rise to variable transmission delays for TCP applications. • Importance of burstiness. Is traffic bursty? Are bursts also important to be delivered quickly or can they be shaped or marked as less important in case there is momentary shortage of resources?

2.6

SERVICE QUALITY DESCRIPTORS

The need to specify the properties of an application flow was motivated above in the context of burstiness. Let us next review service quality descriptors that can be used for this purpose. Another related topic is descriptors used in requesting service quality support. The Internet Engineering Task Force (IETF) has standardized multiple alternative approaches for implementing service quality support in IP networks, which will be described in the next chapter. A part of a service quality framework called Integrated Services (IntServ) is the RSVP including QoS signalling. In RSVP, two kinds of traffic descriptors are defined: • Traffic Specification (TSpec) describing the traffic properties. • Requirement Specification (RSpec) describing the expected quality. Expected quality characteristics in general describe the service quality support requirements such as end-to-end delay, delay jitter and packet loss bounds. In RSpec, service rate and allowed deviation from it are used. A characteristic of the TSpec type, describing the properties of a flow itself, deserves more detailed comments here. This characteristic is description of burstiness of a flow.

48


The two most obvious measures for capacity requirement of a bursty stream are maximum nominal capacity and average nominal capacity. Effective network capacity planning in the presence of variable-bandwidth flows is put on a quantitative footing by the introduction of a third parameter, namely volume of a bandwidth burst. The volume tells how much data there is, at maximum, in a burst. Formal measures for burstiness have been measured using two paradigms, which are leaky bucket and token bucket. These paradigms are explained briefly in the following, being not only useful as concepts but also as ways of measuring burstiness, and defining precisely when means need to be applied to non-conforming traffic. Leaky bucket is used in ATM for specifying burstiness. A leaky bucket is defined by two parameters, the output rate and the bucket depth. The output rate corresponds to the Nominal Bit Rate (NBR) allocated to the flow, and bucket depth tells what is the allowable momentary deviation from NBR. Heuristically, the bucket can contain up to N bytes, where N is the depth of the bucket, and traffic “leaks out” of the bucket at output rate. Thus, when there are already bytes in the “bucket” (user has sent more flow than the nominal bit rate), smaller variation from NBR is allowed than if the bucket were empty. A more formal definition of leaky bucket in the form of an algorithm can be found in [UNI]. Token bucket is the paradigm used in RSVP [RFC2215] to specify burstiness of flows. Conceptually, a token is required of a packet to pass the token bucket. Tokens are generated at a generation rate, and are put into a bucket of depth bucket depth. Further, a correspondence needs to be defined between the token and a byte count in a packet. If an arriving packet finds enough tokens in the bucket to correspond to the size of packets, the respective amount of tokens is removed from the bucket and the packet can be defined to be within traffic profile. In addition to the above token bucket parameters, also maximum packet size and minimum policed unit together make up a Traffic Specification (TSpec) for a flow. The maximum packet size is relevant to delay variation, especially on small-capacity links [RE00]. In ITU-T terminology, token bucket is known as the Generic Byte Rate Algorithm (GBRA) [Y.1221]. The difference between the two paradigms is that in leaky bucket, incoming packets outside of NBR are conceptually put into the bucket, whereas in token bucket, tokens are collected into the bucket when traffic requires capacity below NBR (see Figure 2.9).

2.6 SERVICE QUALITY DESCRIPTORS

49

Maximum generation rate = r

Maximum output rate = r

Figure 2.9 A leaky bucket (left) and token bucket (right). Note: White squares depict packets and dotted ones, tokens

Thus, it could be said that the leaky bucket is more oriented towards remembering the past sins, whereas the token bucket also remembers past good behaviour – up to a limit. The parameters of the two paradigms can be mapped into each other [RFC2381]. The effect of leaky bucket and token bucket regulators is to establish a traffic envelope, or an arrival curve limiting the volume of traffic that is the “legal” part of the flow, as specified in a SLA. Traffic envelopes can be used in network calculus for QoS dimensioning purposes, as will be discussed in Chapter 5.

2.6.1

Measurement-based determination of traffic profile

How are traffic profile parameters obtained in the first place? For CBR voice, the traffic profile is easy to establish. For some other kinds of applications, this may be difficult for several reasons: traffic may be highly bursty, or the application itself may be adaptive. In the latter case, what counts is the application traffic profile in realistic conditions – including the access network technology, the operating system, and the application implementation details. In such a case, measurement of the application traffic descriptor from production streams may be helpful. It can be used either to find out the traffic descriptor, or to update it later. In this approach, the SLA contents need not be fully determined beforehand. Another situation in which measurement-based traffic descriptor can be useful is token bucket parameter redefinition. Measurement-based leaky

50


bucket parameter determination methods have been reviewed in [HRS02].

2.7

SUMMARY

Different types of Internet services were reviewed to gain a better understanding of what kind of quality support needs there are for the services of today and those of near future. Telecommunications service quality procedures were reviewed where appropriate to identify concepts that can be generalized to Internet use. A formal description of service was given in an attempt to cover also emerging services. The central conceptual tool for end user service quality is service instance composed of one or more service events, being an end user view of an aggregated service. End user experienced quality is tied to the intrinsic requirements of a service, as well as subjective factors. A quantitative understanding of the effects of subjective factors can be achieved by arranging controlled tests for service quality assessment, involving a large enough group of non-trained test subjects and pairwise comparisons of well-defined service quality instantiations. End user service quality experience is also affected by the service use situation. Service quality requirements from an end user viewpoint were reviewed, ranging from aggregate service characteristics such as service availability to flow-oriented measures including service event delivery time (delay), delay variation (jitter), and packet loss. All services are not equally amenable to per packet characterization. For Voice over IP, per packet characteristics are valid since VoIP is typically run over UDP. For TCP-based applications, on the other hand, constancy of throughput and delay are most important due to the operation of the congestion-control mechanism of TCP [PFT + 98]. Access network-specific protocol optimizations, the behaviour of different TCP versions, and user experience of effect of varying bandwidth on application make it difficult to make sweeping generalizations of elastic applications. For the flow-oriented quality characteristics, there is an important distinction between non-structured statistics and correlated statistics illustrated in Table 2.9. The distinction also applies to statistical estimators derived from the distributions such as averages. The difference between types of service quality is of

2.7 SUMMARY

51

Table 2.9 A comparison of service event statistics  International Telecommunication Union Characteristic

Description

Non-structured or correlated?

Delay distribution

Relative frequency of service event delays

Non-structured

Delay variation distribution

Relative frequency of delay differences for adjacent service events

Temporally correlated (packet scale)

Delay time series

A record of (sequence number, delay) pairs.

Full temporal structure of delays

Packet loss percentage

Overall probability of packet loss

Non-structured

Packet loss correlation distribution

Relative frequency of packet loss sequences according to their length

Non-structured for sequences of arrived packets, locally structured for loss bursts

Packet loss pattern

E.g., a bit vector showing whether a packet was lost (0) or not (1)

Full temporal structure of packet losses.

Throughput distribution

Relative frequency of throughput measurement results

Non-structured

Throughput time series

A record of (sequence number, throughput) pairs.

Full structure of measurement results.

Note: A defined measurement period is assumed for each of the characteristics.

importance for end-to-end service quality calculations, as will be discussed in Chapter 5. In the general case, to receive adequate service quality support – where applicable – the application needs to be able to tell the network the service quality requirement and the properties of the application flow (e.g., maximum bandwidth, burstiness). This can be performed either via signalling, or based on a Service Level Agreement between the network operator and the end user. In the former case, the RSVP signalling uses the TSpec and RSpec

52


characterization for conveying the quality requirement and traffic flow specification. When the service quality support towards the network is based solely on a SLA, the application type is detected at the network edge, and application type dependent defaults for service quality requirement and flow description information are used. Signalling interface for conveying the service requirements will be discussed in Chapters 3 and 5. The full set of generic service quality support requirement types is summarized in the following list: • Aggregate-level characteristics (service availability, continuity). • Service instance-level characteristics: – PDU delivery time; – throughput; – support for continuous PDU transmission; – support for reliable PDU delivery; – support for variable transfer rate.

3 Network Mechanisms for Multi-service Quality Support This chapter deals with service quality support mechanisms in the network. Of particular interest are mechanisms inside an Internet Protocol domain, including edge treatment and service quality support mechanisms in the network core. Requirements for signalling between the endpoint and the network edge will be discussed in Chapter 5. The Internet today is based on the Best Effort (BE) service paradigm in which all IP traffic on a network link is treated alike, or in other words, no service quality support is provided when momentary traffic volume exceeds link capacity. Subsequently, to offer true multi-service support for critical traffic types such as VoIP in an IP-based network, the technical tasks to be carried out by an IP service provider seem challenging at first sight. Not only must mechanisms be provided for implementing the network support for different service types, but also mechanisms are needed to map service requirements onto network resources. To make best use of network resources, the service mapping scheme may need to be revisited when resources or distribution of services change. The whole service quality support system should be manageable in a scalable way. Implementing Service Quality in IP Networks Vilho Räisänen  2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X

54

NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT

It turns out that implementation of multi-service quality support in an IP domain is possible and manageable. Moreover, this support can be provided with a mechanism allowing the network element in the core of the network to be kept simple. Despite technical feasibility, multi-service support in IP network is not likely to be immediately adopted by all ISPs and other network operators. However, the ability to provide better-than-best effort service will become an important business proposition due to the progress of content digitalization to include also non-data type services. In implementating such support cost-efficiently, IPbased service quality support mechanisms are a viable alternative, as we shall see. In what follows, we shall discuss the basic multiservice quality support mechanisms and ways of implementing them with present-day technology in a cost-efficient way. Further, service level description mechanisms needed at the boundaries of operators’ domains are accounted for in this and subsequent chapters. In this chapter, we shall first briefly review issues relevant to network multi-service quality support, and discuss policing at the edge of the network and the effect of different protocol layers to service quality. Next, the generic ways of supporting service quality are reviewed, followed by a summary of service quality support means in ATM and IP. Routing control in IP networks and link layer service quality issues are discussed next, and the present chapter concludes with a summary. This chapter attempts to demonstrate that the building blocks for service quality support mostly exists already today without ATM. ATM-based service quality support is used as a point of reference in this chapter. Management of IP-based service quality will be discussed further in the next chapter, and the provision of network resources in Chapter 5. Routing control beyond the basic operation of IP routing protocols will be discussed in this chapter, and further in next chapter.

3.1

INTRODUCTION TO NETWORK QUALITY SUPPORT

The adoption of dedicated multi-service quality support mechanisms in the network is only necessary when the following two conditions are met:

3.1 INTRODUCTION TO NETWORK QUALITY SUPPORT

55

1. Over-dimensioning of the network is not a feasible solution. 2. Providing of engineered service quality level for some service traffic types transported in the multi-service network such as low delay and/or packet loss rate is desirable. Above, over-dimensioning means designing the network in such a way that the network is at all times capable of transmitting the momentary traffic volumes so that the service quality requirements of transported streams are satisfied. The latter condition amounts to delay requirement of all traffic being determined by the most delay-critical and loss-intolerant service type. An application example is in a corporate access network carrying Voice over IP, sharing the access network capacity with bursty HTTP traffic and Simple Mail Transfer Protocol (SMTP) traffic. It may not be economically feasible to dimension the network to handle the largest possible bandwidth bursts. This would necessitate providing the same delay to transport of HTTP and SMTP than VoIP. If over-provisioning is not a feasible alternative, either a separate capacity is provided for VoIP, or a prioritization mechanism needs to be built into the actual network transport to provide differentiated handling for distinct service quality classes. These main alternatives benefit from further support mechanisms, the most important of which are discussed below. Before that, however, let us note that service quality support may be needed even with a single service quality type. An example of this could be providing pre-defined performance for browsing traffic. In such a case, a suitable subset of the service quality support machinery reviewed below could be used. Let us now discuss service quality support on a more general level. Discussing the bandwidth of a single link for concreteness, there are basically two alternatives to over-dimensioning in providing service quality support in the presence of multiple service types: capacity reservation and differentiated treatment. Capacity reservation means that a part of the total capacity of a link is reserved solely for one or more traffic types. The remaining capacity can be used for implementing other reservations, or be shared by services on a best effort basis. Differentiated treatment, on the other hand, means not reserving any fixed capacity, but prioritizing service types with respect to each other when momentary

56


6

Capacity

5

Urgent traffic Non-urgent traffic Reservation Differentiation Sum

4 3 2 1 0 1

6 11 16 21 26 31 36 41 46 Time

Figure 3.1 The benefits of prioritization Note: Unit in the vertical axis is the maximum required capacity of urgent traffic

offered traffic exceeds link capacity. In the prioritization approach, less traffic can be displaced in time to make room for momentary variations in the volume of more urgent traffic. Let us next compare the over-dimensioning approach against capacity reservation and differentiated treatment using a case study. Figure 3.1 below shows a case in which the average volume of non-urgent traffic is fivefold as compared to the volume of urgent traffic. Over-dimensioning according to the peak value would require capacity C of 6 units. Capacity reservation for urgent traffic would mean putting aside 1 unit of capacity, and dimensioning separate capacity according to the average volume of non-urgent traffic, leading to total capacity requirement C of 1 + 2.5 = 3.5 units. Finally, implementing prioritization mechanism in the network leads to dimensioning being based on the average volume of all traffic, i.e., approximately capacity of 3 units. In this case, differentiation based on urgency brings capacity-saving benefits of 50% compared to over-dimensioning, and more than 14% based on capacity reservation for non-urgent traffic. This requires that non-urgent traffic can be delayed. The above simple calculation was based on a “fluid flow” approximation, not taking into account discreteness of data. An exact analysis of the process requires application of queueing theory, potentially yielding corrections to the simple case when the size of largest packets is not insignificant with respect to total link capacity. The fact that packet length can vary gives rise to variation in the service time of a packet, causing variable amount of delay to the subsequent packets.

3.1 INTRODUCTION TO NETWORK QUALITY SUPPORT

57

A further advantage of multiplexing is that the relative burstiness of a traffic aggregates is considered to decrease with the number of flows, reducing the effects due to fractal traffic phenomena, for example [CCL + 02]. As will be discussed in Section 3.2, engineering of network for bursty flows benefits from edge mechanisms. In general, the saving calculation figures will depend on the percentage of traffic types, which need priority treatment. If all of the traffic needs priority treatment and is delay-sensitive, overdimensioning is the only alternative. As mentioned above, application of some service quality control means may be beneficial also in this case from the point of view of end user experienced quality. At the other end of the spectrum, when priority traffic with variable bandwidth is sharing the link with bursty non-urgent traffic and the maximum volume of priority traffic is less than half of the link capacity, savings can be considerable. In what follows, it is assumed that when service quality support is feasible, purely prioritization-based service quality support scheme is used to maximize utilization of installed capacity. The dimensioning of capacity reservations is a well-established discipline, and more information about that can be found in [McD00], for example. The above analysis calls our attention to the following important issues in considering the usefulness of differentiated treatment in the network: • Are savings from implementation of differentiated treatment high enough? Implementing support for differentiated treatment in the network makes the elements more complex and poses requirements for management system. • Can differences in service delivery time requirements be leveraged to implement differentiation? If the delay requirements of traffic aggregates are too close to each other, delay differentiation may not be practical. • Are relative volume shares of services known? Traffic volumes need to be known or limits need to be imposed to maintain per-node differentiation. It should be noted that relative volumes need to be computable in all routers which implement prioritization. • Are absolute volumes of traffic aggregates predictable? Even with differentiation, range of variation of different traffic types needs to be known.

58


Mathematically, feasibility of prioritization-based multiplexing in a multi-service network is determined by whether service requirement specification for a service allows for service instantiations of that type to be displaced in time, or their total throughput limited. Some analysis techniques for this will be discussed in Chapter 5. What has been discussed above are de facto preconditions for using differentiation. More generally, the reasons for choosing prioritization-based mechanisms over other alternatives may not be related solely to the mathematics of dimensioning. The multiservice multiplexing paradigm based on service differentiation in the network has the following benefits according to Kilkki [Kil99]: • • • •

fairness; robustness; versatility; cost efficiency.

A detailed analysis of these factors is beyond the scope of this book, and the interested reader is referred to Kilkki’s book. Suffice it to say here by way of an example that fairness can be thought to relate to the end user’s perception of the value for the price the user has paid for the service, taking into account other users’ investments into same service. Robustness refers to the sensitivity of service quality support mechanism towards actions of malevolent users, and versatility relates to the selection of tools at the network provider’s disposal in providing service quality support for a multiplicity of needs. Cost efficiency is a measure of the required monetary investment for implementing the service quality goals. A related topic, we shall discuss utility-based service allocation in Chapter 5.

3.2

POLICING OF TRAFFIC AT INGRESS

To put the service quality management methods presented later in a general context, the reference model shown in Figure 3.2 is used for this chapter. On the network side, a service instantiation can be thought of as being conceptually associated with a service quality support instance. The service quality support instance defines the quality support provided to the service instance by the network domain.

3.2 POLICING OF TRAFFIC AT INGRESS

59

Service instance Quality requirements: - xxx - yyy Network NE Client

NE

NE NE

Client or server

NE

NE

Figure 3.2 Reference model for this section Note: A service instance is invoked between two hosts, routed through a number of network elements (NE) and having a set of quality requirements

Capacity

PBR

NBR

Time

Figure 3.3 An illustration of NBR and PBR

Further, it is assumed that a NBR and a Peak Bit Rate (PBR) can be defined for service events, for example by using TSpec-type traffic descriptor. The significance of these characteristics is that a service instance needs capacity of NBR to function properly, and may at times benefit from a capacity of PBR (see Figure 3.3). Further, a Maximum Burst Size (MBS) is assumed to be known, specifying the maximum allowed amount of data in a burst. A burst here means a period during which the momentary bit rate exceeds MBR. In ATM, Sustainable Cell Rate (SCR) roughly corresponds to NBR and Peak Cell Rate (PCR) to PBR. The flow descriptor parameters are assumed to be specified as a part of a SLA between the client and the network operator, more or less explicitly. For networks with appropriate function in place, the conformance of service instance to a traffic descriptor – for example, the triplet (NBR, PBR, MBS) – can be verified and imposed by policing the service flows at network ingress point. Performing policing at

60


ingress is beneficial, as accumulation of burstiness in the network is best prevented by applying the “traffic contract” between operator and end user as soon as possible. The traffic contract can be considered to be a form of a SLA. If ignored, accumulation of burstiness would make service quality support management in network core difficult. Performing policing at the network edge instead of network core elements is useful due to traffic volumes being smaller at the network edge than in network core and subsequently less processing is needed. Depending on service types, traffic conditioning can be of help in all service quality support mechanism scenarios described above. Specifically, applying traffic conditioning to non-urgent traffic in the scenario of Figure 3.1 reduces the need for maximum bandwidth in over-provisioning scenario. This is also true when there is only non-urgent traffic in the network. Also in a differentiation-based scenario, traffic conditioning is useful through a smoothing effect in the core network. The SLA, in general, can be defined per service event type, or by having parts addressing different service event types. The applicable service type is assumed to be detected either based on signalled state, or on protocol data such as IP address and/or port number. When signalled instalment of policing is used, for example, RSVP can be used for that purpose. Protocol data filter can be a fixed one, or vary with operator-defined conditions. A single service instance consisting of service events of different types may map to multiple SLA service type components. For example, a teleconferencing service instance could include VoIP service event type with stringent service quality, and a data application sharing service event type with different SLA service quality profile. A practical device for verifying conformance to SLA is typically either leaky bucket or token bucket regulator controlling regulator function. The conformance check can be assumed to be of leaky bucket type for ATM and token bucket for IP traffic. After conformance of a flow or aggregate to traffic descriptor has been checked, a controlling means is usually applied for limiting out-of-profile burstiness of traffic at network ingress. In ATM parlance, policing is typically an operation applied in the User-Network Interface (UNI), or upon user flows entering the network. It is also possible that the user performs policing prior to sending traffic to the network. In addition to being better able to control the quality of one’s own services, policing one’s own outgoing traffic allows the user to better understand the properties of one’s own traffic.

3.3 ABOUT LAYERS

61

In general, the following actions can be applied to out-of-profile traffic: • Traffic shaping. Burstiness is smoothened out by buffering outof-profile traffic. Due to finite buffer size or maximum allowable delay per network element, traffic shaping may need to be combined with the following method. • Discard out-of-profile traffic. • Assign out-of-profile traffic to a lower treatment class. This method allows the out-of-profile traffic to utilize unused capacity in the network. • Do nothing. Statistics of out-of-profile traffic volumes may still be recorded. Means of configuring policing will be discussed in the next chapter. The importance of conditioning will be referred to later in the context of end-to-end service quality dimensioning in Chapter 5. Here, suffice it to say that conditioning at the network edge alleviates the possibility of worst-case effects of slow convergence to Gaussian (well-behaved) aggregates with the number of flows in the network core [NZA99]. Such problems may arise due to bursty end-user traffic flows, technically described as being fractal or having long-range correlations. A classic example of this is fractality in Ethernet-based LAN [LTW + 94]. With increasing flow aggregation level, the arrival process on a link tends towards Poisson process, and the adverse effects of burstiness are reduced [CCL + 02].

3.3

ABOUT LAYERS

The ISO/OSI reference model enumerates no less than seven layers of interconnectivity. The lowest three or four of these layers are often referred to in practical engineering. A well-known generic property of layered reference models, fitting of real-world protocols neatly exactly within one OSI protocol layer is often problematic. TCP and UDP can be accommodated relatively nicely into Transport Layer (layer four) of OSI model, but ATM and MPLS are both partly layer 2 and partly layer 3. This is because they include routing functions like layer 3 protocols, but are still “link layer” protocols from the viewpoint of IP applications. For the purposes of concreteness, the four lowest layers of OSI reference models are

62


Transport layer

TCP

UDP

Network layer

IP

Link layer

802.3

AAL

IP AAL ATM

MPLS

Physical layer

Figure 3.4 An illustration of mismatch of protocols with respect to ISO/OSI protocol reference model using example protocol stacks

nevertheless often used. Figure 3.4 shows examples of approximate relations of often-used Internet protocol stacks with respect to ISO/OSI model. The link layer also includes the Medium Access Control (MAC) layer in Figure 3.4. The protocols used in the layered structure can be of importance to service quality support in IP networks, depending on what kind of service quality support there is on each layer. The significance of TCP and UDP for service quality has been discussed in the previous chapter, being an issue the endpoint application can partially affect by choosing either TCP or UDP when instantiating a service. On the network side, the overall service quality support capability is affected also by link layer service quality support and the physical set-up of the network, for example. These issues will be elaborated in Section 3.8 and in Chapter 5. An issue of practical importance is the amount of configuration and operations support required on different network layers. Performing service quality support configuration on as few network layers as possible and in as automated a way as possible is perceived to be an important goal. Such an approach can bring considerable benefits to the network operator, in the form of lowered operability costs, and also to the end user, in the form of increased network reliability. This is one of the drivers in studying light protocol stacks such as IP/MPLS over WDM.

3.4

TYPES OF NETWORK SUPPORT FOR SERVICE QUALITY

The ITU-T draft recommendation [Y.1541] lists the network service quality support mechanisms for different QoS classes in Table 3.1.

3.4 TYPES OF NETWORK SUPPORT FOR SERVICE QUALITY

63

Table 3.1 QoS support mechanisms for ITU-T’s draft QoS classes  International Telecommunication Union QoS class

Node mechanisms

Network techniques

0

Separate queue with preferential

Constrained routing and distance

1

Servicing, traffic grooming

Less constrained routing and distances

2

Constrained routing and distance

3

Separate queue, drop priority

Less constrained routing and distance

4

Long queue, drop priority

Any route/path

5

Separate queue (lowest priority)

Any route/path


[Y.1221] lists the following traffic control functions: network resource management, admission control, parameter control (corresponding to policing), packet marking, traffic shaping, and packet scheduling. In what follows, different service quality support technologies are put into a generic context to structure different ways of service quality support. Assuming that protocol stacks and network topology have been selected, the following classification of generic ways of a network to provide support for services is used in this book: 1. Reserve capacity for service events in transport elements. 2. Provide support for differentiating treatment for service events in transport elements. 3. Provide means of differentiating service instantiation. An example, best effort treatment with over-dimensioning is a special case of the first option. In the above list, all the means seek to address the same issue, namely that of providing sufficient network capacity for selected service type or types. The three issues listed address this from different – but not necessarily mutually exclusive – viewing angles. For example, option 2 indicates that some service types are to be prioritized with

64


respect to others at times of congestion, not ruling out options 1 and 3. Please note that the third category speaks of differentiation in service instantiation, that is, invocation of the service in the first place. The optimization of network utilization will be discussed later in Chapter 5. In this chapter, the emphasis is mostly on technical service quality support means.

3.4.1

Capacity reservation

Capacity reservation for a service means that a quota of network capacity is allocated to a service support class. Network-wide, this means that capacity is reserved along the route of a service event in applicable network elements. The set of elements in which this support is implemented for a particular service may be predefined or not. Reservation may be mathematically strict or more statistical in nature. Capacity reservation can be either predefined or signalled. In the latter case, the signalling does not necessarily take place per service instantiation, as can be seen below. Routing of a capacity reservation is clearly important. When the capacity reservation is interpreted literally, capacity needs to be put aside in the network on a semi-permanent basis, or some form of service quality support negotiation must be implemented. In both cases, the service instances entitled to the associated service quality support type need to be routed along the reservation. In case of signalled reservation, the reservation state may further need to be transferable between network elements if routing of service instances changes. In general, a service instance may be composed of service events having different routes across the network. In this case, separate, possibly homogeneous capacity reservations for service event types may need to be applied. Capacity reservation, in general, can be of the following types: 1. Physical. Part of the network capacity on physical layer is allocated to a service. For instance, in a fibre-based optical network using WDM, one wavelength could be reserved for circuitswitched telephone calls between two switching centres. 2. Signalled semi-permanent. “Permanent” reservations for service classes can be set up with appropriate protocols using signalling. The ATM Permanent Virtual Circuit (PVC) is an example of this.


65

3. Signalled on demand. Reservation is set up on demand for one or more service instances. Examples of this include the ATM Switched Virtual Circuit (SVC) and IETF’s IntServ framework using RSVP signalling for capacity reservation along paths applied to individual flows. 4. Statistical reservation. Reservation is interpreted using predefined statistical terms, for example, as being available 95% of the time. In the first and the second case, the routing for a service can be performed as a part of network planning. In the third case, routing of the reservation is based on existing reservations in the network and the requested service quality support for the new flow. All the capacity reservation methods described either implement service quality support instantiation limitation/differentiation – that is, admission control – or would benefit from it. Service quality instantiation control can be based on request accepted/request denied, or can also include service quality support-type renegotiation. Statistical reservations are relevant for multiplexing-oriented solutions, and allow for less formal types of instantiation control to be exercised if need be.

3.4.2

Differentiated treatment

Another kind of support that a network can provide is differentiated treatment according to service type. The following possibilities exist: 1. Differentiation with respect to reliability. What kinds of guarantees on reliable PDU delivery are provided to a service instance? The following alternatives can be provided: a Guaranteed reliability for a service instance. b No guarantees about reliable PDU delivery. This is the plain Internet Protocol model. c Guaranteed reliability up to a limit (e.g., NBR), reliability beyond that subject to availability of resources. This model is used, for example, in Frame Relay (FR) and ATM’s concept of SCR and PCR. The PDUs exceeding NBR can be marked as lower priority ones, and per-PDU prioritization can be applied to them.

66


Differentiation with respect to reliability can be obtained by providing, for example, the first alternative to some service types, and the second to others. Alternatively, no absolute guarantees are provided to any of the service types, but reliability differentiation is implemented on PDU level within the limits of momentary loading levels. This is explained in more detail below. 2. Prioritization with respect to SDU loss. If PDU loss can occur at times of network congestion, can different service events be prioritized with respect to PDU loss? The alternatives are: a Yes. This is the approach used in IETF’s Differentiated Services’ (DiffServ) drop precedence classification and ATM Cell Loss Priority (CLP) bit. b No. This is the traditional Best Effort model of IP networks. Prioritization with respect to PDU loss provides a statistical performance profile. Such differentiation tools can be used for differentiating the importance of traffic exceeding agreed-upon NBR from the importance of within-profile traffic, on the one hand, or between traffic types, on the other. 3. Prioritization with respect to PDU forwarding. Can a store-andforward type network element prioritize PDUs belonging to different service event types with respect to forwarding rapidity? The answers are: a Yes. Implemented by DiffServ’s forwarding priority classes. b No. This is the traditional Best Effort model. It should be noted that capacity reservation, too, is one form of prioritization with respect to PDU forwarding. The two, however, are not conceptually equivalent. 4. Differentiation with respect to routing. Is differentiated routing per service event type supported? a Yes. This is the approach of ATM PVCs and SVCs, and can also be implemented with Label-Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS). b No. This is the approach of traditional IP routing protocols, where routing is performed per packet. A note about packet switching and routing is in order here. Differentiated routing benefits from routing of a service event being


67

controllable. In the classical IP thinking based on robustness of networks, each packet is – in principle – routed independently, whereby route flapping between two or more routes for packets belonging to a single flow is possible [Pax97, Pax97b]. The first step towards differentiated routing would be to divert some service event types to a path with something else as lowest cost, while other traffic types would be routed along the lowest cost path. In this Type-of-Service (ToS) routing, the routing of individual service events could still be done per packet, following the basic philosophy of packet switching. Alternatively, all PDUs belonging to a service event type can be routed in a connectionoriented way using a predefined path. This property, which could be implemented with ATM or MPLS, for example, may be desirable in order to avoid switching back and forth between routes of different length. Routing differentiation can be provided for some traffic types only, if both IP routing and connection-oriented routing can be mixed in the same network elements. What sets routing differentiation apart from capacity reservation is that the former does not necessitate hard reservations. Routing differentiation can be applied to packets, flows or traffic aggregates.

3.4.3

Differentiation of service quality instantiation

The network can secure service quality for selected services by limiting access to network quality support resources on per-service type basis. The options are: 1. Service quality instantiation control can be linked to the quality requirements of service event types. This is the approach used in RSVP, ATM, as well as GPRS and 3GPP cellular networks. a. A subtype of this is admission control applied on coarser service classification granularity. For example, real-time service events vs. non-real time service events. 2. Service quality instantiation control is based on user type. 3. Service quality instantiation control is applied to all services equally. Upon a predefined condition being met, all further connections are blocked, irrespective of service event type. 4. No formal service quality instantiation control is used. This is the default behaviour of IP networks. Severe enough congestion

68


can lead to service instance invocation being interrupted by the user, or by protocols. The different methods listed above can be combined. It should also be noted that the actual service instantiation decision may be different from service quality support instantiation decision; in plain English, the service may be started even when the network turns down the request for enhanced service quality. Not having a service quality instantiation mechanism in a network domain means that in case of congestion, services within a single capacity reservation will have to establish the division of the bandwidth among themselves. In such a case, the properties of application protocols become important: TCP-based applications will “back off” when congestion occurs, which may lead to UDPbased applications benefiting from the congestion.

3.4.4

Summary of generic network service quality support mechanisms

Different network techniques for supporting service quality were discussed above, including capacity reservations, differentiated treatment, and differentiated service quality instantiation. Different kinds of network service quality support mechanisms can in general coexist, even though capacity reservations and differentiation-based methods are often considered to belong to different paradigms. The scope of network service quality support mechanisms is summarized in Table 3.2. All the mechanisms listed in Table 3.2 have the potential to affect the quality of the whole service event, and of applying to an entire network domain. However, some mechanisms are clearly more directly related to deterministic control of certain scope. Thus, for example, loss and forwarding prioritization are applied in individual network element, depending on the statistically varying loading situation within the element in question. Routing differentiation, on the other hand, has a direct deterministic impact on other network elements. The possibility of having multiple service event types within a single service instance may need to be taken into account in designing network-side service quality support. The reason for this is that if instantiation of a service requires that all the service event

3.5 SERVICE SUPPORT IN ATM

69

Table 3.2 Summary of scopes of network service quality support mechanisms Mechanism

Network scope

Service scope


Network element or network domain

Service type

Reliability differentiation

Endpoint

Service instance or service event

SDU loss differentiation

Network element

Service event

SDU forwarding differentiation

Network element

Service event

Routing differentiation

Network domain

Service type or service instance

Service quality instantiation differentiation

Network domain

Service instance

types are provided with appropriate service quality instantiation, failure of the latter for any of the service event types leads to failure of the entire service instantiation. Next, we shall study how these apply to service models of Internet Protocol QoS support mechanisms, using ATM as a comparison. Let us first take a look at ATM first.

3.5

SERVICE SUPPORT IN ATM

ATM is an extension of ISDN into broadband domain. Whereas narrowband ISDN was based on Time-Division Multiplexing (TDM), ATM is based on 53-byte (octet) cells that are transmitted asynchronously between switches. (The somewhat strange cell size of 53 bytes – 53 is an indivisible number, for starters – was a standardization compromise between competing cell size proposals.) Several ATM Adaptation Layers (AALs) have been defined for interfacing towards different service types, the most important being • AAL1: circuit emulation service for delay-critical traffic; • AAL2: for delay-sensitive Variable Bit-Rate streams;

70


• AAL5: frame or packet-oriented services. Suitable for transporting TCP/IP. Thus, IP-based services can interface to ATM using suitable AALs, or can use TCP/IP over AAL5. The latter has been de facto alternative, since ATM is not available end-to-end. Also other adaptation layers have been used for trunking purposes, for example.

3.5.1

ATM service models

The ATM forum has defined the following service categories [ATM]: 1. CBR (Constant Bit Rate). Capacity equal to PCR is provided for the service event type or service instance. 2. RT-VBR (Real-Time Variable Bit Rate). The network guarantees capacity SCR to service instantiation on the average, and supports bursts with maximum capacity requirement 0

(3.1)

where fj is defined iteratively by f0 = 0, d0 = 0 fj = max(aj , min(dj −1 , fj −1 )) +

(3.2) lj , ∀j > 0 R

(3.3)

In this definition: dj is the time that the last bit of the j -th EF packet to depart actually leaves the node from the interface I . fj is the target departure time for the j -th EF packet to depart from I , the “ideal” time at or before which the last bit of that packet should leave the node. aj is the time that the last bit of the j -th EF packet destined to the output I actually arrives at the node. lj is the size (bits) of the j -th EF packet to depart from I . lj is measured on the IP datagram (IP header plus payload) and does not include any lower layer (e.g. MAC layer) overhead. R is the EF configured rate at output I (in bits/second). Ea is the error term for the treatment of the EF aggregate. Note that Ea represents the worst case deviation between the actual departure time of an EF packet and the ideal departure time of the same packet, i.e. Ea provides an upper bound on (dj − fj ) for all j . d0 and f0 do not refer to a real packet departure but are used purely for the purposes of the recursion. The time origin should be chosen such that no EF packets are in the system at time 0. for the definitions of aj and dj , the “last bit” of the packet includes the layer 2 trailer if present, because a packet cannot generally be considered available for forwarding until such a trailer has been received. In essence, equations (3.1) – (3.3) provide a mathematical definition for allowable deviation from a nominal rate of the output

3.6 SERVICE SUPPORT MODELS IN INTERNET PROTOCOL

81

interface. The DSCP 101110 is recommended to be used for EF PHB.

3.6.5.2 AF PHB group Assured Forwarding (AF) PHB group provides for four AF classes (AF1–AF4), with three drop precedences for each class. Thus, the total number of per-hop behaviours making up the AF PHB group is twelve. Each AF class corresponds to a minimum allocation of forwarding resources such as buffer space and bandwidth. An AF class may be implemented with a single queue with Weighted Random Early Drop (WRED) thresholds for the different drop precedences. Multiple AF classes in a router interface can be implemented with Weighted Fair Queuing (WFQ), for example. AF class is an example of a PHB Scheduling Class (PSC) in DiffServ. [RFC2597] defines that more than the minimum amount of forwarding resources may be provided to the AF class. The exact meaning of an AF class depends on the resources allocated to it, the details of the mechanism used for implementing it, and the characteristics of the traffic mapped to that PHB class. Thus, there is no a priori specified forwarding priority ordering among AF1–AF4 PHB classes. Drop precedences within each AF class provide prioritization in the case of congestion; packets with high drop precedence being more likely to be discarded to protect more important (low drop precedence) packets. An example of this is assigning a lower WRED threshold for high drop precedence packets than for packets with low drop precedence. Traffic conditioning is not obligatory for AF PHB group. The recommended DSCPs for AF PHB group are shown in Figure 3.6. Simultaneous deployment of expedited forwarding-like (premium) and assured forwarding-like service are described in [RFC2638], with the conclusion that it may bring benefits to the Class 1 Class 2 Class 3 Class 4 +----------+----------+----------+----------+ Low Drop Prec | 001010 | 010010 | 011010 | 100010 | Medium Drop Prec | 001100 | 010100 | 011100 | 100100 | High Drop Prec | 001110 | 010110 | 011110 | 100110 | +----------+----------+----------+----------+

Figure 3.6 Recommended DSCPs for AF PHB group Source: From [RFC2597]

82


network operator, if admission control to the traffic aggregates can be performed effectively.

3.6.5.3 Other PHBs There are further per-hop behaviours that are currently not standardized. One of them is called Simple Integrated Medium Access (SIMA) [KR98] also known as Dynamic Realtime/Non-Realtime (RT/NRT) PHB group [Kil99], implementing dynamic PHB marking at the network edge. The PHB marking is done for forwarding priority and drop precedence using six levels for the former, and three for the latter. Packets transmitted at the nominal bit rate specified in the Service Level Agreement between the user and the operator are marked with the default forwarding priority. Packets, for which the momentary bit rate is different from the nominal one, are marked with a drop precedence that is logarithmically proportional to the ratio of the momentary bit rate and the agreed-upon bit rate. According to [Kil99], the dynamic PHB scheme can also be implemented in a manner that is interoperable with EF and AF. DSCP allocation scenarios for such interoperability scenarios can be found in Kilkki’s book.

3.6.5.4 Functions of a DiffServ router Figure 3.7 shows the full set of logical functions of one network interface of a DiffServ router. The functions are useful in policybased management of DiffServ (cf. Chapter 4). The set of the functions is called the Traffic Conditioning Block (TCB). Logically, a DiffServ router has one TCB per network interface. The functions

Classification

Algorithmic drop

Metering

Queueing

Action

Scheduling

Figure 3.7 Logical functions of a DiffServ router

3.6 SERVICE SUPPORT MODELS IN INTERNET PROTOCOL

83

are generic and common to both DiffServ edge and core routers, as explained below. The structure of a DiffServ router is discussed in more detail in connection of policy-based management in Chapter 4. A DiffServ edge router can perform classification of packets for further action. The classification is performed based on data in the IP and transport protocol headers. Taking an example, classification could be made based on socket connection – that is (source IP address, port) pair – for identifying users, possibly combined with classification based on protocol number and other data for further differentiation. Next, a flow of packets thus identified can be subjected to metering, where the bit rate of the flow is compared to configured parameters. The metering is based on token bucket model. Following metering, an action is applied to both in-profile and out-of-profile packets. The action can be one of the following: shaping, dropping, multiplexing, marking, or null action. In addition to the last three functions of a TCB, also the first three functions of Figure 3.7 are logically present in a DiffServ core router, even though no per-flow operations are performed there. The reason for need of classification is that the scheduling differentiation of a packet requires that the queue needs to be known into which the packet is (at least logically) inserted. The metering and action functions can be used, for example, to control rate limiters for EF traffic in core routers.

3.6.5.5 Summary of DiffServ Summarizing, the DiffServ framework provides support for service quality using prioritization mechanisms in the core, and provisioned service quality support at the network edge. The implementation of service quality support mechanisms in individual routers is not defined, only the “macroscopic” effect (PHB). Static admission control to traffic aggregates is based on SLAs between end users and the network provider at network edge, with associated policing mechanisms. Dynamic admission control requires an extra function, an example of which is provided in Chapter 8.

3.6.6

Summary of IP QoS service models

The service quality support provided by IP service quality support models is summarized in Table 3.4. Basic best effort only provides

84

NETWORK MECHANISMS FOR MULTI-SERVICE QUALITY SUPPORT Table 3.4

Summary of IP service support mechanisms


IntServ/guaranteed QoS: yes, DiffServ: implicit and statistical

Reliability differentiation

DiffServ: yes. IntServ/guaranteed QoS: implicit

SDU loss differentiation


SDU forwarding prioritization



IntServ/guaranteed QoS: yes. DiffServ: requires extra mechanisms

Service quality instantiation differentiation

IntServ: through QoS requirements. DiffServ: requires extra mechanisms

service quality support for an over-dimensioned network. From the point of view of individual service event, the support from IntServ controlled load service is similar to that of best effort support with over-dimensioned network. Practical implementation of IntServ with guaranteed QoS scheme using RSVP signalling is based on the connection-oriented resource reservation paradigm, including dynamic admission control and routing. DiffServ uses service differentiation based on provisioning of service support at the network edge with no inherent routing control for services and no dynamic service quality support signalling. Routing-based service quality control is not part of basic DiffServ, which is why we shall next take a look at routing control means for IP. Dynamic admission control to service quality resources, too, is outside of the scope of basic DiffServ framework, and will be discussed in Chapter 8. As mentioned above, also RSVP relies on existing IP routing mechanisms, even though it performs path-based reservations. IP service quality support frameworks and possible service quality support extensions to them are summarized in Figure 3.8. Control of service event routing is part of neither best effort nor basic DiffServ service models. Implementations of IntServ framework support service event routing control, making use of existing routing mechanisms. Let us next take a look at routing in IP networks using basic IP routing protocols, and link layer control means including ATM and MPLS.

3.7 ROUTING IN IP NETWORKS

Best Effort

- Pure best effort - BE + edge conditioning - BE + admission control

85

DiffServ framework

- EF PHB - AF PHB group - Other PHBs - Routing control - Admission control

IntServ framework

- Controlled load - Guaranteed QoS

Figure 3.8 IP service quality support schemes

3.7

ROUTING IN IP NETWORKS

Routing is the function of the network determining which path is taken by the PDUs en route from source to destination. Routing in classical IP is selected – in principle – per hop and per packet in each router. While this approach yields good robustness properties for the routing, it is not always optimal from the transmission latency consistency point of view. As demonstrated in Paxson’s thesis [Pax97], this approach can lead to route flapping, or periodic switching of the route used by a flow between multiple alternatives. The default operating mode of IP routing protocols is automatic updating of routing tables. This mode provides limited tools for domain-level routing control. The classical way of overriding default IP routing is based on using link layer tunnels in such a way that the logical adjacency of routers on IP layer is controlled by the tunnel set-up. For example, IPv6 test network domains can be joined into a logical IPv6 backbone by tunnelling traffic between IPv6 domains through IPv4 networks. The tunnelling approach allows one to use non-modified IP routing protocols, but requires separate mechanism for setting up and managing the link layer topology. An example of tunnelling technology is IP network topology built on top of ATM, called the overlay technique. An automated way of setting up the controlled routes is based on label switching. MPLS is based on label switching. A good discussion about MPLS can be found, for example, in [Wang01]. The use of link layer in routing control will be discussed more below, and routing control as a tool for traffic engineering is discussed in Section 4. For link

86


state type routing protocols listed below, routing can be affected also via the selection of metrics to be computed for each link. Typeof-Service (TOS) routing, that is: differentiated routing of traffic types, is not widely used at the moment. In what follows, addressing is discussed first, followed the routing control support in IP routing protocols and routing based on lower layer tunnelling.

3.7.1

On addressing

The IPv4 address space has 32 bits, and that of IPv6, 128 bits. The Internet today is based on IPv4, and without special measures would quickly run out of IP addresses. This is basically due to the well-known problem of lowered average utilization of number space due to partitioning, but has been made worse by an uneven geographical distribution of IPv4 addresses. The situation has been improved in classifying network domains according to the prefix length (Classless Inter-Domain Routing, CIDR) instead of according to the number of 8-bit blocks of the address field (classes). Thus, instead of allocating network prefixes as either Class B (16-bit prefix, 16 bits for the domain) or Class C (24-bit prefix, 8 bits for the domain), for example, a 20-bit prefix could be given for a network domain. Nevertheless, the use of a Network Address Translator (NAT) has become a necessity for managing the IPv4 address spaces in individual network domains. Due to NATs and uneven geopolitical allocation of IPv4 address space, the IPv4 address space is not optimally coupled to the anticipated number of IPv4 addresses in different parts of the world. It is expected that the need for IP addresses in emerging markets such as Asia will make the use of IPv4/NAT combination impossible in the not-so-distant future. As a consequence of sub-optimal address allocation, the routing table sizes in Internet core routers have increased dramatically. The IP address shortage is not limited to emerging markets only: the problem will be made worse by the ever-increasing number of IP-addressable devices. My GPRS phone has an IP address – what will happen when there are hundreds of millions or billions of such devices in use? An evolution version of IPv4, IPv6 has a larger address space, but is not yet widely deployed. IPv6-based research network 6Bone has been operating for many years now, and IPv6 has also been


87

taken into production use in Japan. The European Union has expressed support for IPv6, the consequences of the statement to be seen. IPv6 is supported in 3GPP mobile networks (GPRS and UMTS), being one of the first large-scale networks with IPv6 capability. From a routing point of view, the larger address space makes possible address allocation according to geography. The delivery IPv6 packets require IPv6-capable routers using routing protocols, which can handle IPv6. It is obvious that the whole Internet will not be upgraded into IPv6 overnight. Subsequently, IPv4/IPv6 transition strategies have been developed within the Next Generation Transition (NGTRANS) working group of IETF. The transition to IPv6 is an issue, the details of which are beyond the scope of this book. Suffice it to say here that NGTRANS is working on transition mechanisms such as routers with dual IP stacks, IP-in-IP tunnelling, and Network Address Translator/Protocol Translator (NAT-PT). Further details can be found in [NGTRANS]. IPv6 also opens up new scenarios that have not been possible with IPv4. These will be briefly mentioned in Chapter 11.

3.7.2

IP routing protocol-based methods

IP routing uses shortest path routing between source and destination, with “shortest” meaning “lowest cost” according to a predefined metric. Examples of metrics are number of hops and latency. Two types of routing IP protocols are in use: Interior Gateway Protocols (IGP) and Exterior Gateway Protocols (EGP). The former type is used within an Autonomous Domain (AD), whereas the latter is used between ADs. The IGP protocols are either of Distance Vector (DV) or Link State (LS) type. As the name implies, DV protocols convey information between routers about distances to networks. Link state protocols, on the other hand, disseminate information about link status in the domain running the protocol in question. The two types have differences in complexity and routing topology convergence – LS protocols are more complex to implement but converge to a loop-free state quicker after link status changes. A few of the most widely used IP routing protocols are listed here: • Routing Information Protocol (RIP) in an IGP of distance-vector type;

88


• Open Shortest Path First (OSPF) is an IGP of link-state type; • Intermediate System – Intermediate System (IS-IS) is an IGP of link-state type; • Border Gateway Protocol (BGP) is an EGP of type path vector protocol, amending the scalar distance in DV protocols with information about autonomous domains through which the path passes. The OSPF is a widely used protocol, and is used here as an example of the routing control provided by a standard IP routing protocol. OSPF defines mechanisms for discovering and maintaining information about neighbouring routers, where “neighbouring” is naturally to be understood in terms of logical IP connectivity. OSPF routers also flood link status information to neighbours using reliable delivery to ensure that information reaches the neighbouring routers. The link weights in OSPF routing tables determine the cost of a given route, and can be used for purposes of load sharing between multiple routes. The weights are updated automatically by flooding up-to-date cost to all routers. OSPF includes equal-cost load sharing so that a router can distribute outgoing traffic between two routes, when costs associated with these routes are identical. Possible extensions to advertised link state information [Wang01] allow for limited level of routing control through the selection of the criterion to be used as a weight used for path selection. OSPF, as other IP routing protocols, by default operates on packet level and not on flow level. A recent overview of routing protocols can be found in [Arm00]. More detailed information can be found in routing area working group documents on the IETF web server. In addition to fixed Internet routing protocols mentioned above, the ad hoc routing working group “MANET” exists for the purpose of standardizing routing between mobile hosts without permanent infrastructure between them. The Mobile IPv6 working group under Internet area standardizes mobility-optimized version of IPv6 (Mobile IPv6) that can be used with a permanent infrastructure but with mobile hosts. Mobile IPv6 traffic can be routed in the permanent network using the same routing protocols as normal IPv6 traffic.

3.7.3

ATM overlays

Due to common deployment of ATM in backbone networks, the solution to transporting IP over ATM has been needed. IETF has


89

specified a solution to this [RFC1932], in which an ATM network domain can be divided into logical IP subnets (LISs). The hosts in a LIS share the subnet prefix, and have the same Maximum Transfer Unit (MTU) size. The scheme has no link layer broadcast. Subsequently, a separate ATM Address Resolution Protocol (ARP) server is needed for address resolution purposes. Further, a separate next hop resolution protocol is needed for forwarding packets between LISs. This, in turn, requires an additional server. The overlay model has certain generic problems, some of which are listed here. If full point-to-point connectivity is built between ATM switches, this requires N (N − 1) Virtual Circuits (VCs) for a LIS consisting of N elements. The IP overlay solution does not use ATM switching connectivity optimally. Finally, IP QoS support is missing in the overlay approach. The biggest problem with ATM overlays is that VC set-up is completely separate from IP routing. Thus, VC set-up is at worst a tedious management task, which still does not necessarily solve IP routing management.

3.7.4

Lower layer tunnels: MPLS

Multi-Protocol Label Switching (MPLS) provides for switched paths called LSPs (Label Switched Paths). A label switched path is created by appending an MPLS shim header containing a label to the PDU. LSPs can be nested and aggregated by inserting MPLS PDUs into the ingress of new LSPs. MPLS switches route incoming PDUs based on the label in the shim header. The switches perform routing based on label switching tables, the structure of which can be set up two ways: • automatically based on IP routing tables, or • fully signalled set-up. In the second of these methods, the routing of LSP can be affected during the set-up, whereas in the former, the IP routing table information is utilized in each router when building up the LSPs. Also hybrid forms are possible. Traffic in the switched MPLS network is classified into Forwarding Equivalence Classes (FECs), which are assigned to LSPs at the

90


edge of the network. Traffic destined for the same network node receiving identical treatment makes up one or more FECs. FEC classification can be made on multiple levels ranging from flows to the IP subnet of the destination MPLS edge Label Switched Router (LSR). MPLS allows for label stacking, that is, encapsulation of MPLS PDUs inside a MPLS PDU. This feature makes it possible to build multiple levels of aggregation, at the cost of shim header overhead per aggregation. The size of the MPLS header is bytes. Compared to the IP/ATM overlay solution, MPLS allows for more streamlined solutions. IP routing and MPLS LSP routing can be enmeshed instead of having to replicate the function. No meshed point-to-point connection set-up is needed. Being connection-oriented, MPLS allows for routing optimization for traffic engineering purposes, as will be discussed in the next chapter. DiffServ support in MPLS is being defined [RFC3270], a topic to be probed deeper in Chapter 4. Finally, a strength of MPLS is indicated with the “M” in the abbreviation, that is: multiprotocol support. MPLS run in an IPv4 network can be used to transport IPv6 packets, for example, assuming that edge LSRs understand IPv6 routing. MPLS makes it possible to build networks with light protocol stacks. For example, the LSP can be used to select a wavelength in WDM network, a technique known by the names of Generalized MPLS (GMPLS) and MPλS (of course, the consistent form would be MPS, but this detail seems to transcend marketing departments’ command of the Greek alphabet).

3.8

LINK LAYER ISSUES

The most basic service quality issue on link layer is whether a link layer protocol PDU delivery is reliable or not. If the link layer protocol is reliable, it performs retransmissions when PDU loss is noticed. This means – from the application layer point of view – that link layer PDU losses are seen mostly as variable delays in delivery. When link layer PDU retransmissions are not successful, packet loss occurs also on IP layer. IP layer QoS mechanisms cannot affect variable delays due to link layer retransmissions, unless special mechanisms for this are implemented per link.

3.8 LINK LAYER ISSUES

91

Thus, for delay-critical traffic, an unreliable link layer is typically better than a reliable one when PDU loss is to be anticipated in the network domain using that technology. Let us discuss the case of an unreliable link layer protocol. The IP layer itself is not connection-oriented, and does not provide reliable delivery nor does it give rise to variable delays. On the transport layer, the choice between TCP and UDP again comes back to delay the sensitivity of service. For delay-critical services, TCP retransmissions may cause delays that cannot be tolerated. It should be noted that the effects giving rise to retransmissions accumulate as one goes up the protocol stack; on the transport layer, not only PDU losses on link layer are seen, but packet loss can be also caused by corrupted PDUs on the network layer or transport layer. Furthermore, congestion in IP routers can give rise to packet loss. TCP operates, in the form originally conceived, endto-end between the sender and the receiver. Thus, retransmissions can by caused by any forwarding component or link along the end-to-end path. For interactive real-time content transmission over the Internet such as multimedia conferencing, delay requirements are strict, whereby the best currently available protocol stack up to transport layer consists of UDP/IP over unreliable link layer. Naturally, the link layer along the end-to-end path cannot always be selected or affected. In any case, the end-to-end path may contain unreliable link layers, whereby a mechanism such as RTP/RTCP is needed to provide timing and sequence numbering information for real-time content. In link layers with high BER, a variant of UDP capable of handling partially corrupted payloads may bring additional benefits. For streaming, UDP/IP as the protocol stack is optimal from the jitter point of view. Content in the Internet is often streamed over TCP due to the reason that UDP traffic is often discarded by default by domain firewalls. The IEEE 802.1Q standard (also known as Virtual LAN, VLAN) provides for QoS support in the link layer. The standard defines three priority bits in the 802.11 link layer frame header, based on which mapping to different queues and differentiated forwarding treatment is possible. Examples of the use of the three 802.1Q bits – called user priority bits – in the 802.1D standard for different traffic types in the LAN are provided in [Fin02]. These bits

92


have been proposed to be used for implementing IntServ in 802 networks [RFC2815]. As defined by the Integrated Services over Specific Link Layers (ISSLL) working group of IETF, 802.1Q bits and 802.1D traffic classes can be used in the LAN under the control of RSVP [RFC2814]. This concept is known as the Subnet Bandwidth Manager (SBM). One challenge with multi-service networks having prioritization on the link layer is managing the consistency of IP layer and link layer service quality support configuration.

3.8.1

Performance

If there is separate buffering on the link layer “below” DiffServ queueing and scheduling, end-to-end performance on capacitylimited links is best when SDU prioritization is supported also on the link layer. On such links, the maximum link layer PDU size (called Maximum Transfer Unit, MTU) affects delay performance. Even with prioritization on the link layer, a link layer PDU of higher importance may have to wait for a PDU of lower priority to be served first. For two priorities on the link layer and Poissonian arrivals and service times (i.e., the M/M/1 model), the average residual waiting time is given by R = 12 (λ1 S12 + λ2 S22 )

(3.4)

where λk is the arrival rate of SDUs of type k and Sk is the second moment of service times in queue k . The service time distribution is determined by PDU length distribution, and is thus in general a function of maximum PDU size. The average waiting time for high priority traffic on link layer is then given by the equation W1 =

R 1 − ρ1

(3.5)

where ρ1 is the load in queue 1 (urgent traffic). Hence, the size of MTU potentially affects both average delay and delay variation. It should be noted that the prediction given by M/M/1 is a worst-case scenario, as the service time distribution of IP packets is not exponential. due to the existence of MTU limit.

3.8 LINK LAYER ISSUES

93

When link layer fragmentation is used, it can have an effect on end-to-end performance in two ways. First, the loss of one link layer fragment on link layer can lead to either delay in the transmission of the entire IP packet due to retransmission of a fragment, or discarding of the packet, depending on whether reliable or unreliable link layer is in use. Second, if a prioritization mechanism is in use on the link layer, a higher-priority fragment may get scheduled in the “middle” of a lower-priority IP packet. The link layer may give rise to reordering due to lost PDUs, if in-order delivery is not guaranteed by the link layer. If in-order delivery is guaranteed, at worst a loss of link-layer PDU may cause delay to several packets. Readers interested in further discussion on the effect of link layers on service quality, see [Arm00].

3.8.2

A note on scheduling

Practical implementation of any service quality support scheme in IP network requires scheduling mechanisms in routers to decide which PDU is transmitted on the link next. On the domain level, the details of scheduling implementation are not important, but rather the macroscopic effect obtained with it. This is also the philosophy behind the Per-Hop Behaviours in DiffServ. For the purposes of this book, the following generic buffer management and scheduling technologies are considered together, being sufficient to implement the IETF standard EF and AF PHBs: • rate limiter; • algorithmic dropper; • strict priority scheduler entry; • weight-based scheduler entry; • best effort scheduler entry. Rate limiter is used for limiting the traffic entering one particular queue. Algorithmic dropper is used for managing the buffer space during momentary congestion. A strict priority entry in the scheduler provides for prioritized forwarding with respect to one

94


or more queues. Using multiple weight-based scheduler entries, bandwidth can be statistically divided among them. A strict best effort scheduler entry does not provide for any service quality support guarantees.

3.9

SUMMARY

Network mechanisms suitable for providing multi-service quality support in the Internet were reviewed. The potential importance of IP’s multiplexing model for network utilization was pointed out. Conditioning at the edge is important for reducing bandwidth variability of traffic. This is especially important for TCP traffic, which often exhibits high burstiness ratios and converges to Gaussian distribution only slowly as the number of flows increases. Multi-service quality support mechanisms are useful especially in access networks, where percentual traffic variability is high due to lower flow aggregation level compared with backbone transport. In long-haul backbone networks, simple over-provisioning is often sufficient. Generic means of affecting service quality inside the network are capacity reservation, treatment differentiation, and service quality instantiation differentiation. IP service quality support mechanisms cover these means to varying degrees, the full repertoire of the service quality control means having adverse effects on scalability of the IP service quality support mechanism. Good scalability properties can be achieved with DiffServ-based PDU prioritization, requiring in-advance set-up of service quality configuration. As will be seen later, complementary techniques can be used to bring selected aspects of capacity reservation and service instantiation differentiation to DiffServ networks. PDU delay prioritization makes it possible to obtain multiplexing gains in a multi-service network when the composition of traffic is such that the following conditions are met: • Sensitive traffic is carried, for which delay and/or packet loss performance is of importance. • Aggregate traffic is bursty. This condition is usually not difficult to fulfil in IP networks. • PDUs of some traffic types can be delayed.

3.9 SUMMARY

95

• Delaying of non-urgent traffic types decreases burstiness sufficiently. Packet discard prioritization brings most value for adaptive services. In cases of congestion, discard prioritization distributes the available bandwidth for a number of behavioural aggregates according to the assigned relative importance of the individual aggregates. Such prioritization works best with TCP-based applications and is useful in connection with weight-based bandwidth sharing approaches. Service quality support in DiffServ is based on the consistent configuration of network edge and core routers. The role of edge routers is especially important, as these take care of the most complex tasks. To achieve versatile support for varying service types that is responsive to changing business needs, DiffServ service quality support in general can benefit from routing control and automated means of network configuration. These are discussed next in Chapter 4. Routing control at the level of explicit route definition is not inherently part of IP routing protocols. A limited amount of control is possible in OSPF by control of the cost metric. Routing control means based on MPLS complement the capabilities of DiffServ. ATM overlays also provide routing control capability, but are difficult to manage and are not integrated with IP routing. Traffic engineering techniques in Chapter 4 can be used to raise the network multiplexing gain for DiffServ-based multi-service network up to a point. The higher the targeted utilization level, the more advanced solutions and mechanisms are needed to implement multi-service QoS in IP networks. State-of-the art technologies for this are discussed in Chapter 4. DiffServ is explicitly based statistical quality guarantees. Admission control in the sense of service instantiation is not part of the basic DiffServ scheme; once the classification rule is in place at the network edge, flows are inspected on per-packet basis. In certain QoS-critical uses basic DiffServ capability is amended with admission control. Service quality architectures with varying degrees of admission control are reviewed in Chapter 5. A specific application of DiffServ in Third-Generation (3G) network, IP-based Radio Access Network (RAN) will be described in Chapter 9. Combining DiffServ-based IP QoS mechanisms with routing control provided by either enhanced IP routing or MPLS makes it

96


possible to use light protocol stacks for implementing service quality in the network. In the most optimized form they consist of IP, MPLS, and WDM layers with MPLS LSPs mapping to WDM wavelengths. When automated label distribution protocol can be used to set up the label switching tables in MPLS switches, the protocol stack is simple both platform-wise and from a network management point of view, reflected in reduced capital and operating expenditures, respectively.

4 Traffic Engineering for Multi-service IP Networks Traffic engineering is a set of techniques and tools that can be used to optimize the performance of an operational IP network. An overarching concept, traffic engineering, broadly interpreted, includes other topics discussed in this chapter: routing control mechanisms such as MPLS, and an advanced configuration in the form of policy-based management. These techniques can also be used without deploying the complete traffic engineering framework, but their optimal use benefits from it. For example, we shall see that most efficient use of routing control is possible with proper measurement technologies in the network. Traffic engineering is also a cornerstone for the management of a multi-service IP network in a cost-efficient manner. Supporting services in the network in a commercial environment requires that the status of the network is monitored, optimized and controlled. The traffic engineering framework uses service level management and monitoring techniques explained later in Chapters 6 and 7. Especially in the presence of growing traffic volumes, the effectiveness of traffic engineering also has implications on network planning and – when used – admission control decisions, which is why it can be said that traffic engineering also lays the foundation for the application of techniques in Chapter 5 and Chapter 8. Finally, traffic engineering typically makes use of the service


98

TRAFFIC ENGINEERING FOR MULTI-SERVICE IP NETWORKS

quality support mechanisms described in Chapter 3. The relation to end user service quality discussed in Chapter 2 is that ideally traffic engineering is a set of network-side techniques providing engineered quality support level for individual services, as the name of the concept implies.

4.1

TRAFFIC ENGINEERING

The traffic engineering (TE) overview [RFC3272] of IETF’s Traffic Engineering working group (tewg) is a good description of the typical traffic engineering tasks, even though true multi-service support is only finding its way to the Internet. IETF’s traffic engineering overview is used as a frame of reference for the rest of the topics in this chapter. The TE overview draft defines traffic engineering as the part of network engineering concerned with performance evaluation and performance optimization issues. Further, traffic engineering is defined [RFC3272] to include the application of technology and scientific principles to the measurement, characterization, modelling, and control of Internet traffic. An important area is the enhancement of performance of operational networks, both in terms of resource usage and from the viewpoint of traffic requirements. The obvious goal is to implement the service quality support with as small an amount of valuable network resources as possible. Examples of the resources involved include leased link bandwidth, CPU usage, and buffer space. Routing control is singled out as a means of controlling resource use over-multiple hops. Compared with traditional IP routing protocol-based methods, the target of traffic engineeringoriented routing control can be network-wide traffic distribution. Traffic requirements, manifested to the end user in the form of “emergent properties” of network performance, are to be optimized subject to the constraints of the economic realm. Emergent properties presumably correspond roughly to the end user quality experienced discussed in Chapter 2. Further, traffic engineering is intended to help in identifying and structuring goals and priorities in enhancing the end user service experience. Reformulated,

4.1 TRAFFIC ENGINEERING

99

traffic engineering is a systematic means of analysing the network state, drawing conclusions from it, and potentially performing a network configuration. As is often the case with complex realtime systems, creation of proper procedures to cope with data acquisition and control procedures is at least half the work. Traffic engineering is perceived as important already in the present-day best-effort Internet, and it is even more so in the multi-service Internet of tomorrow that is in the making at the moment. Some reasons leading to the need for parameter optimization are: • change in local traffic volume, such as addition of a new major customer in a PoP; • change in the resourcing situation, such as change in provider for leased line capacity; • change in traffic aggregate distribution (locally or globally), for example, due to adoption of a new service type; • exceptional conditions such as malfunctioning of a router. Other focuses areas of traffic engineering are improvement and maintenance of reliable network operations in the face of exceptional situations, for example, resulting from equipment failure. This requires the ability to detect network fault conditions and the ability to act based on this information. In the case of a multiservice network, fault conditions pertain to a service quality support mechanism in the network. Related definitions and procedures for the former will be discussed in Chapter 7. Fallback to back-up route for a traffic aggregate in case of detected link failure is an example of an action taken as a result of detecting an exceptional condition in a network. In what follows, we shall take a look at the context of traffic engineering, the traffic engineering process, acquiring information from the network, analysing this information, and means of enhancing performance in a DiffServ network. The discussion is loosely based on a recent RFC on traffic engineering [RFC3272], but is amended for application in a multi-service network as appropriate. A summary of service quality support aggregate level measurement methods has been added.

100

4.1.1


Context of traffic engineering

The appropriate methodology used by traffic engineering can be derived from the context of traffic engineering [RFC3272]. The entire context of Internet traffic engineering is defined to include the following four sub-contexts: • Network context defining the different situations in which traffic engineering needs to be applied. The network context includes network structure, network policies, network characteristics, network constraints, network quality attributes, and network optimization criteria. In a multi-service IP network, the additional task of creating and managing adequate set of service quality support classes is needed. • Problem context defines the concrete issues traffic engineering is applied to. Problem context includes the identification, abstraction of relevant features, representation, formulation, specification of solution requirements, and specification of desirable features for the solutions. Congestion is named as an example of a typical problem to be solved on the traditional Internet; in a multi-service IP network, sub-optimal performance of a service quality support class could be a further problem. • Solution context defines how issues defined by problem context are addressed. Solution context includes analysis, evaluation of alternatives, prescription, and resolution. Examples of solving the congestion problem at different timescales, reactive/proactive as well as supply/demand alternatives are provided. In principle this phase is similar for best-effort Internet and multi-service IP network, being only more complex in the latter case. • Implementation and operational context defines the methodological application of solution context, including planning, organization, and execution. The network context must be able to express the essential factors of traffic engineering in such a way that the problem context can be applied to it. A multi-service network with heterogeneous service quality support requirements can be represented as an aggregation of network resources, traffic distribution offered, and the service quality support mechanisms. Network resources include network elements and the capacity and topology of the interconnecting


101

network. The properties and configurability of network resources are important. Service quality support mechanisms in a DiffServ network include edge router functions, core router functions, and optionally also routing control and admission control means. The inter-operation of different service quality support mechanisms is part of the network context, too. Specific to a DiffServ-based multi-service network, the effectiveness of network utilization can be taken to be part of the network context. Problem context addresses abstraction, representation, and measurement of network status in a manner that is relevant for traffic engineering. The problem to be solved needs to be explicitly defined, some kind of acceptance criteria must be defined for good solutions, and requirements for solution context should be defined. The requirements, in general, can relate to the following: • service quality support aggregates; • measurement methods; • analysis methods; • network reconfiguration means. The different factors in the above list are often interdependent. For example, unless there is an efficient means of reconfiguring the network, there is less benefit in making detailed analyses of the network state. The network status measurement may encompass multiple levels of abstraction, ranging from individual resources to Autonomous Domain (AD)-wide representations. We shall return to this issue in Chapters 6 and 7. The development of suitable performance optimization means is an important issue. For a multi-service network in general, service quality support aggregate characteristics such as delays and packet loss measures are important. On the network level, the utilization level of the network is vital. Examples of solution context include specific policies, techniques and methodologies, parameters, and guidelines that are implemented to perform the task specified within the problem context. The application of measurement tools and methodologies, as well as routing control, are listed as typical important solution context components. Implementation and operative context are more administrative, organizational, and executive in nature than the previous steps. This

102


aspect of traffic engineering is not central to this book, but some related aspects will pop up sporadically in the following chapters. The authors of [RFC3272] further note that the application of the traffic engineering context – especially with congestion – can be anticipatory or corrective. In the former case, the choice of good measurement, analysis, and performance optimization tools is especially important.

4.1.2

The traffic engineering process

The traffic engineering process is defined [RFC3272] as consisting of the following parts: • Definition of relevant control policies. This can be considered as being outside of the actual traffic engineering loop, controlling its progress. Naturally control policies can be and are adjusted based on observed network performance. • Feedback mechanisms for acquiring measurement data from production network. • Analysis of network state and characterization of traffic workload. • Performance optimization of the network. The traffic engineering process is iterative, as illustrated in Figure 4.1. For readers familiar with the philosophy of science, the picture is reminiscent of the idealized depiction of the induction/deduction sequence in science [Old86]. An example of application of traffic engineering in a large-scale production network can be found in [FGL + 00]. The first phase is the definition of the control policies. Inputs used for devising these may include the required service quality support of different traffic types – related to business models of the network operator – and optimization algorithms. For example, the network may have a busy hour configuration as well as an off-peak hour configuration, which are different from each other. Some service quality support aggregates can be defined as more important than others when the triggering and execution of corrective actions are being considered. According to [RFC3272], feedback from the network – the second stage in traffic engineering process – does not have to be limited to data obtained from the network only, but can also


Definition of control policies

Feedback from network

103

Analyse

Optimize

Configure Measure

Network

Figure 4.1 Traffic engineering process of [RFC3272]  International Telecommunication Union

use synthetic workloads in case immediate measurement results are not available. Synthetization of measurement results can be based on extrapolation from earlier data, for instance. In the case of a multi-service network, synthetization of performance data is often more challenging than for a single-service network, but this scheme may be necessary to better understand the status of the network. We shall discuss measurement means briefly in Section 4.1.3 and on a more general level in Chapter 7. Analysis can be either reactive or proactive. In reactive mode, analysis attempts to identify possible locations in the network having sub-optimal performance, to trace the root cause, and may also test different ways of solving the problem. In proactive mode, the goal is to identify optimization targets to prevent future performance problems. The proactive mode is often important in understanding and anticipating the effect of traffic volume growth and changing traffic mix to the configuration of a multi-service IP network. Possible tools for performing analysis include modelling, simulation, and traffic matrices. Traffic analysis does not have to produce the actual solution, but can also be limited to a descriptive mode. The optimization phase includes the means of selecting the actual method to be used for optimizing network performance. In this phase, the network operator can greatly benefit from using a proactive network performance analysis mode, if the analysis means are good enough. Optimally, the analysis machinery

104


can be used for benchmarking potential network configurations in advance. Automation of the above process is a challenge in the general case. It requires finding the correct optimization tasks to be automated, and defining a correct interface for human supervision and intervention. At the same time, instabilities due to control mechanisms must be avoided.

4.1.3

Obtaining performance data from the network and analysing it

Feedback from the network can be obtained from multiple sources and on different levels of abstraction (see Figure 4.2). Starting with the most detailed method, individual network elements can be queried for information. Network elements may also provide notification mechanisms for informing the network management system of predefined conditions transpiring in the network. In some cases, individual network elements may have information about a larger part of the network than the network element itself. An example of this is the routing table of a router running a Link State type routing protocol such as OSPF. For most characteristics, obtaining information on higher abstraction level than that of individual network elements is made possible by a Network Management System (NMS). Forming of higher-level characteristics can be achieved, for example, by applying thresholding to information collected from individual network elements, as will be discussed in Chapter 7. To give an example, with such a method one can see the most heavily loaded routers in a network domain. The management system can typically provide averages and tendency analyses in addition to an abstracted momentary network status. For a multi-service network, the performance of the network can be monitored on the level of traffic aggregates for a network domain. Finally, the feedback can be in the form of service quality. This requires a way of estimating service level performance. The abstraction levels are compared in Table 4.1. The subject of performance measurements will be covered more thoroughly in Chapter 7. Typically, network elements such as routers provide a set of counters accessible through a management interface, for


105

Service performance Aggregate performance

AD

AD

Endpoint NE

NE

Endpoint

NE

Figure 4.2 The relations between performance measures Note: The management system provides information about performance of individual network elements within an AD, whereas aggregate performance and service performance relate to measurements spanning multiple elements. An AD may have multiple aggregate performance measures, for example, relating to different DSCPs Table 4.1

A comparison of network monitoring levels

Monitoring level

Typical measured characteristics

Per network element

Overall load and per- traffic aggregate statistics.

IP management system

Network-wide data, averages, trend analysis.

Aggregate performance

Delay, jitter, packet loss, and available bandwidth in a network domain.

Service level

Service Level Specification components (see Chapter 6).

example, Simple Network Management Protocol (SNMP). The contents of the accessible information are defined in Management Information Bases (MIBs). Some routers may use vendor-specific, non-standard interfaces. Two types of measurements relevant to traffic engineering will be discussed in this chapter for purposes of concreteness. Traffic aggregate performance measurements (Section 4.1.3.1) data is relevant for optimizing the parameters of a DiffServ network domain. They can also be used as an input for routing control. Traffic load measurements are typically used for routing control and capacity expansion need evaluation purposes.

4.1.3.1 Traffic aggregate performance measurements Aggregate level performance here means network performance of a service quality support aggregate, such as the behavioural aggregate of DiffServ, over multiple IP hops. Thus, they include

106


the effect of multiple network elements as a part of the measurement definition. In view of performance data relating to a particular service quality support aggregate, aggregate level performance measurement means may also require less processing than performance estimation obtained by combining data from individual network elements. Generally, three different types of methods can be used for aggregate level performance assessment: 1. passive (non-intrusive) measurements; 2. active (intrusive) measurements; 3. piggybacking measurements. The measurement data obtained by one or more of these mechanisms can be processed in different ways to obtain relevant characteristics. One example of such processed characteristics is packet loss correlation modelling [Cla01, TIPHON-5] which can be used to estimate the quality of traffic aggregate used for transporting VoIP or multimedia streaming. More generally, ITU-T’s recommendation [I.380] lists the following measurable quantities: packet transfer delay, delay variation, packet error ratio, and packet loss ratio. Availability is characterized by the PIA and PIU parameters discussed in Chapter 2. A generic issue related to measurements, proper measurement methodology, including adequate sampling, is very important in obtaining meaningful results [RFC2330, RFC3432]. Measurement results must form a representative sample of network behaviour in order for optimization techniques to be applicable. To this end, the measurement point placement scenarios need to be defined carefully [I.380]. Likewise, the treatment of error conditions such as packets with bit errors need to be defined. Let us take a look at the aggregate performance measurement methods next. 4.1.3.1.1

Passive measurements

Passive measurements do not require additional traffic to be injected into the operational network. Instead, the normal traffic in an operational network can be monitored. One or more measurement points can be used in a single network domain per monitored traffic type. With one measurement point, traffic load and protocol statistics can be monitored. In the case the monitored streams include timestamping and sequence numbering information, which is the case for the RTP, also delay jitter and packet loss measurements can be made,


107

but it must be noted that the results may include the effects of such elements as TCP/IP stack implementation of the sending host operating system scheduling, and access network [RFC3432]. One way of circumventing this is to combine passive and active measurements by measuring a test stream such that the properties of the test stream generator are well known. With two measurement points, delay measurements are possible without timestamps, provided that a sufficiently high degree of synchronization can be implemented between the measurement points. Two-point delay variation measurements are described in [I.380]. Controlled delay measurements with only a single measurement point are in principle possible when a timestamped measurement stream is sent by the endpoint. In addition to suffering from the sending terminal-related problems listed above, it is also required that the host clock of the sending terminal is correctly synchronized with the measuring point, and that timestamp marking can be trusted. Passive measurements have been subject to standardization at least in IETF [RFC1757, RFC2021, RFC3432] and ETSI’s IP telephony project TIPHON [TIPHON-5]. Passive measurements do not add further traffic into the network, but require more processing than active measurements, for example. They may also require transfitting of large amounts of data. Passive measurements in the network core require highperformance probes. Privacy and possible effects of encryption are important issues for passive measurements [CDF + 00]. 4.1.3.1.2 Active measurements Active measurements are based on controlled transmission test traffic streams through the measured network. Such measurements can be implemented relatively straightforwardly, and have thus been used relatively early to assess the suitability of the Internet for transporting real-time streams [BCG95]. The measurement packets typically carry timestamps and sequence numbers to accommodate latency and loss measurements. The obvious downside of the method is the network capacity consumed by measurement streams. Active measurements are typically most useful in high-capacity parts of a network domain in monitoring service quality levels there, but can also be used for troubleshooting purposes [RR00]. At best, active measurements can provide for controlled measurements, when the operating system and TCP/IP stack-related

108


properties of the measuring hosts are well known. Active measurements have been subject to standardization in IETF’s IP Performance Metrics working group (IPPM WG), ITU-T [I380], and ETSI [TIPHON-5]. To give an example of IETF work, the IPPM working group has defined measurement metrics for delay measurements using packets sent at Poisson-distributed intervals for one-way [RFC2679] and round-trip [RFC2681] measurements. An alternative approach suitable for measuring network performance for periodic streams is described in [RFC3432]. The real difference between the Poisson sampling measurement and the periodic stream measurement is only in sampling methodology. With proper measurement packet format, delay, delay jitter, packet loss and packet loss correlation performance for a traffic aggregate can be directly measured with active measurements [TIPHON-5]. Further, the IPPM working group is in the process of defining a reordering metric. Furthermore, available bottleneck bandwidth for the traffic aggregate in question can be estimated using the packet pair method (see, for example, [LB99, HCY + 01]). With active measurement, the type of measurement packets – population of interest – needs to be defined [I.380, RFC3432]. Spurious outcomes, or reception of packets matching the filter of measurement packets which, however, are not part of the measurement stream, need to be defined as well. 4.1.3.1.3 Piggybacking Piggybacking is at the moment mostly a research-oriented approach, where timestamping and sequence numbering information are attached to traffic payload [JH00]. Overheads from the measurement as well as required processing in the elements inserting and removing measurement fields to payload data packets need to be taken into account. 4.1.3.1.4

Comparison of aggregate performance measurement methods A comparison of aggregate performance measurement technologies is provided in Table 4.2. In summary, active measurements generate more traffic in the network, but require less processing than passive measurements. Passive measurements require more processing, and are most suitable for access networks. Active measurements can be used for service level monitoring. Active and passive measurements can


109

Table 4.2 Comparison of aggregate measurement methods Method

Delay

Delay variation

Packet loss

Throughput


(1)

(2)

(2)

X

Active measurements

X

X

X

(3)

Piggybacking

X

(4)

X

(3)

Notes: (1) reliable measurement possible for two measurement points; (2) possible with a single measurement point for streams with timestamps and sequence numbers, see text for other factors; (3) indirectly possible, see text for details; (4) see text for details.

be combined by applying passive monitoring to the streams used for active measurements. 4.1.3.1.5

Relation of aggregate measurement to end-to-end service level performance Service level measurements, in general, can be implemented in the following ways: • using endpoint feedback; • estimating from aggregate measurements; • estimating from per-network element data. A communication endpoint may be able to give feedback relating to service quality. An example of this is the transmission of RTCP messages for real-time streams between endpoints using RTP, with RTCP messages yielding information about delay jitter and packet loss. Another example of endpoint could be SDP renegotiation of multi-speed codec bitrate in SIP environment. These examples show that the endpoint feedback or use of per-element data does not necessarily provide service level performance information directly. Furthermore, the endpoint performance is affected by other factors, including those of the endpoint itself. Subsequently, it may be difficult to map endpoint performance to optimization actions in the network. Aggregate performance measurement yield information that is network-specific, yet relates to end-to-end service performance is shown in Figure 4.2. According to ITU-T’s definition [I.350], service performance is measured at service access points, whereas network performance is measured at connection element boundaries. What this definition boils down to is that domain-internal

110


network performance measurements often have different scope than service level measurements. Drawing conclusions of performance optimization actions based on aggregate performance results requires the link between end-toend service performance and aggregate performances to be known. One tool for this is the use of QoS budgets [TIPHON-3]. A simple application of QoS budgets to providing the aforementioned link can be found in [LRR01]. In general, the link between network domain-level performance and end-to-end performance can be considered to be defined within a SLA between network operator and the provider and/or the user of the service. QoS budgets for different service quality characteristics can be considered to be a part of the SLA, as will be discussed in Chapter 5.

4.1.3.2 Obtaining data relevant for routing control The data most important for routing control are load levels on individual links and traffic aggregate performance characteristics. Obtaining accurate information about traffic load in IP networks where routing is based purely on IP routing protocols is important mainly because of two factors: the non-connection-oriented nature of the Internet Protocol, and the distributed nature of IP routing protocols. As a result of these two factors, traffic volumes on a particular link in an AD may vary as a result of the interplay of BGPs and IGPs [FGL + 00b]. Further potential reasons for traffic volume variability include burstiness of traffic sources, the operation of load-sharing schemes, and routing fallback to resiliency routes. Obtaining load information is also important as a basis for performing MPLS-based traffic engineering. Traffic load level on a link not only affects the mean queueing delay, but may also increase the variability of queueing delays. The properties of the flows transported in a particular traffic aggregate as well as the implementation of scheduling in individual network elements affect the functional form of the dependence between link loading level, average queueing delay, and variability of queueing. Queueing theory can be used to estimate delay and delay variation effects in an individual router when the distributions for arrival process (offered traffic) and service time (packet lengths) are known. The distributions, in general, can depend according to the time of day of longer temporal cycles. In a multi-service network such as a DiffServ domain, the load estimation methods used should be applicable to the estimation


111

load of individual Per-Hop Behaviours (PHBs) on a link. In a DiffServ domain in which there are bursty prioritized traffic aggregates, applying a traffic matrix estimation may yield only average behaviour. Thus, the relevant traffic matrix averaging period for a prioritized traffic aggregate is determined by the timescale of its burstiness. The averaging timescales of non-prioritized traffic aggregates may be longer still. This is a further reason for paying attention to traffic conditioning at the network edge. As with aggregate performance measurements, the location of measurement points is important for obtaining useful results [DG01]. If measurements are only performed at the edge of the network, inferring loads on the links inside the network domain requires that up-to-date information about routing of traffic aggregates is available. This is the approach in [FGL + 00b], where information obtained by monitoring flows in the ingress interfaces is combined with reachability information about egress links. Determining the ingress link for a flow measured on an egress link is in general difficult. At worst, inferring per-link loading levels from information obtained at network edge only requires not only IP level routing table information, but also up-to-date information about link layer connectivity and possible load-sharing schemes. The information obtained by indirect methods may have uncertain value, due to factors such as load-sharing schemes used in OSPF not being standardized. On the general purpose Internet, monitoring is made more challenging still by the variability of typical IP traffic patterns [BR02]. In a multi-service DiffServ domain, this problem can be greatly alleviated by traffic conditioning at the network edge. According to [FGL + 00b], gathering flow-level statistics in the interfaces of high-end routers used for peering interfaces between is technically feasible. On the other hand, collecting statistics on access link access links can be important. In general, the measurement system needs to handle four kinds of flows: 1. 2. 3. 4.

Access link to access link. Access link to peering link. Peering link to peering link. Peering link to access link.

Different kinds of source/destination pairs for flows are illustrated in Figure 4.3.

112


Peer domain

Peer domain

Peering link

Peering link

Access link

Router Router

Access link

Router

Router

Router

Router

Access link

Access link

Router Router Peering link

Peer domain

Figure 4.3 Different types of source/destination combinations: access link to access link (solid line); access link to/from peer domain (dashed line); peer domain to peer domain (dotted line)

In alternative 3, also the case of ingress router being identical to egress router needs to be handled properly. In all the methods, the identification of the contribution of highvolume flows is important [FGL + 00b]. Such flows could be traffic aggregates using the domain as a trunk, for example. Traffic matrix-based methods can be used to infer loading volumes on particular links, given that sources and destinations of traffic aggregates and routing of traffic are known. Alternatively, traffic matrix can – in principle – be used to reconstruct the patterns of offered traffic from measured per-link loads. In such an inference, the equation R

arl xr = yl

(4.1)

r=1

is used, with arl indicating which share of the traffic on route r is using link l , xr indicating the amount of traffic on route r, and yl the volume of traffic on link l . When equation (4.1) is used to deduce offered traffic on routes from link loads, the set of equations is often undetermined i.e., does not yield a unique solution. In such a case, history data can


113

possibly be used as a starting point to reduce ambiguity of the results [BR02]. An alternative method for obtaining per-route loads from perlink data is based on assuming a model for the loading patterns and performing a fitting of the parameters into the model based on measurement results. In this case, the results reflect the structure of the model used. Monitoring the routing tables of routers is a possible way of obtaining routing information about IP domains using LS-type routing protocols. Since the link loads are updated dynamically, the information thus obtained is a snapshot of the routing behaviour of the network. Since OSFP is able to perform load sharing, the information is not deterministic even interpreted as a snapshot of the network situation. Trajectory sampling is one way of optimizing the volume of information obtained from monitoring the routing of packets in a generic IP network [DG01]. In the scheme, all routers in an IP domain sample packets use the same hash function, whereby the route used by the packets matching the hash function can be reconstructed. Of course, this requires that each router within the domain supports this scheme. According to [DG01], performances higher than OC-192 can be achieved implementing the scheme in the ingress interfaces of routers using commercial Digital Signal Processors (DSPs).

4.1.4

Performance enhancement

The performance enhancement of networks is viewed by the authors of [RFC3272] as an optimization challenge, consisting of two parts: capacity management and traffic management. Logically, these operate at different scopes and different timescales of network behaviour. Capacity management is about engineering the performance using capacity allocation in parts of the network domain or the whole domain. Traffic management deals with service support means within individual nodes. Network performance optimization is viewed as a continuous process, not something that is performed only once. The goals of optimization may change with time. Automation of the control problem that is the optimization of network performance is singled out as a particular challenge. If deployed, automated network selfoptimization must not lead to instabilities in network behaviour.

114


With reference to the discussion about multiplexing gains in the preceding chapter, one goal of traffic engineering in a multi-service network is to maintain the optimal utilization level of network, given the composition of offered traffic in the network. The generic target is network-wide optimality while taking into account the loading levels of individual links. Capacity management consists of the following tasks: • capacity planning; • routing control; • resource management, resources including; – link capacities; – buffer spaces; – computational resources. Capacity planning involves planning for the required resources in the network, including required throughput of routers, and capacity of links. In a multi-service network, capacity planning also involves computing initial values for service quality aggregate specific per-element parameters, such as the setting of traffic conditioners at the edge; and buffer sizes, scheduling weights, rate limiter settings in the core routers. The possible configuration of link layer service quality support technologies also falls under this category. When link-layer service quality support mechanisms are used, maintaining consistent multi-service support on the IP layer and link layer is very important. Depending on the topology, routing control is a tool for affecting distribution of traffic in the network. For OSPF routing, adjustment of OSPF metrics is a means of controlling routing [FT00]. Link layer tunnelling such as MPLS can be used for more advanced tunnelling, multi-protocol support (e.g., IPv4 and IPv6) being possible with MPLS. Traffic engineering uses of MPLS will be discussed further below. Routing control, in general, can be applied at the granularity of packets, flows, or service quality support aggregates. As discussed in previous chapters, most service types benefit from as small a delay jitter as possible. This leads to either performing routing control on quality support aggregate level, or on flow level. The latter requires extra function in the IP routers, such as hash table-based methods described in [Wang01]. Routing control will be discussed further in Section 4.2.


115

Traffic management, in turn, consists of the following tasks: • per-node traffic control functions including: – traffic conditioning; – queue management; – scheduling. • other traffic flow control means in the network. Traffic management tasks are concerned with the parameters of flow and packet handling. For example, the scheduling weight corresponding to a WFQ queue may need to be adjusted in response to observed increase of traffic in the respective AF class, or RED trigger levels for drop precedences may need to be adjusted as a consequence of changed traffic distribution. Conditioning at the network edge can be used to control allowable burstiness of flows, as well as available per-user bandwidth. Other means of flow control include admission control to service quality support resources (called differentiated service quality instantiation in the preceding chapter). When admission control is exercised on the level of service quality support classes, applying traffic engineering procedures could result in modification to the service quality support instantiation algorithms. An example of an admission control element capable of performing this for a DiffServ network domain is a bandwidth broker. The subtasks of traffic engineering relate to different timescales. The actual timescales depend on the tools in use, but an example is given in Table 4.3. In [RFC3272], the scope of application is AD-internal, but the generic goals have wider applicability. Also, the result of resource optimization within an Autonomous Domain (AD) could be linked Table 4.3 Rough timescales associated with traffic engineering subtasks Subtask

Timescale

Capacity planning

Years

Capacity supplementing

Months to years

Routing control

Days to months

Resource management

Hours to months

Traffic management

Timescale of flows or packets

116


to inter-domain resource management by triggering renegotiation of SLAs with other network transport providers.

4.1.5

Scope of network optimization

The scope of IP transport network optimization means is important. The target of IP target network optimization mechanism can be, for example, an interface within a router, an individual network element, routing area, or an IP domain, as illustrated in Figure 4.4. Traffic engineering, at its most general, is concerned with optimizing IP transport on the network domain level. Traffic engineering can also be applied to routing domains or individual network elements, as necessary. Limited amount of optimization capability can be allowed to subsystems within a domain, for example, for an individual IP router. Such a local optimization is typically based on a limited amount of information. The optimizations performed in network elements should be in line with the goals of traffic engineering on broader scopes. For example, a change in scheduling weights in a DiffServ router has potentially system-wide effects. Thus, in the presence of local optimizations, one part of traffic engineering is controlling these in such a way that the traffic engineering at the scope of the entire domain is possible. This can lead to a hierarchy of network optimization mechanisms, partly residing within the traffic engineering machinery, partly in network elements, as shown in Figure 4.5. IP domain

Routing area

NE i/f

Routing area

Routing area

Routing area

Routing area

Figure 4.4 Possible scope for applying traffic engineering Notes : NE = network element and i/f = network interface.

4.2 IP ROUTING CONTROL AND TRAFFIC ENGINEERING

117

Domain-level traffic engineering

Sub-system-level traffic engineering

NE level optimization







Figure 4.5 An optimization hierarchy

4.2

IP ROUTING CONTROL AND TRAFFIC ENGINEERING

Traffic engineering is concerned with optimizing network-wide performance. This can be contrasted with prioritization-based mechanisms, for example, which are designed to solve momentary overloading situations in an individual network element. Thus, traffic engineering can make use of tools, which span multiple network elements, a network domain, or part thereof, to optimize network behaviour. Aggregate-level service quality measurement methods were reviewed above in Section 4.1.3.1 and will be discussed further in Chapter 7. Means of obtaining a configuration to be put into network elements for a particular service configuration will be discussed in the next chapter. In this chapter, we shall concentrate on means of controlling routing in IP networks. Before going into specific traffic engineering technologies, let us revisit the generic service quality support mechanisms from the last chapter to assess their relevance to traffic engineering. Capacity reservation is a traffic engineering mechanism, when applied network domain-wide. Possible practical implementations of capacity reservations for traffic engineering purposes in IP networks include the following: • perform hard capacity reservation; • map traffic into prioritized forwarding behavioural aggregate;

118


• map traffic into behavioural aggregate with predefined scheduling quota and buffer space allocation in network elements; • apply differentiated routing for service quality support aggregates; • use multiple paths for one traffic aggregate. Hard capacity reservation is generally non-optimal from the capacity usage point of view, but may be necessary with certain service combinations and network configurations. Differentiated routing can be used to utilize network capacity more effectively, for example, by routing most delay-critical traffic types via the shortest path and less urgent traffic types via a longer route. Routing of a single service quality support aggregate via multiple paths can be used for achieving optimal use of network resources. Delay jitter considerations lead to the conclusion that controlling of routing in such a multiple-path approach should be performed on flow granularity for real-time streams, not on packet granularity. As discussed previously, also TCP-based applications benefit from as constant a transmission delay as possible. Routing control will be discussed in more detail below. In DiffServ networks using standard IETF PHBs, the traffic engineering tools are related to the use of prioritized (EF) and statistically allocated (AF) behavioural aggregates. Traffic mapped to EF receives priority treatment, provided that it is conditioned properly and that the percentage share of EF traffic on an individual link with respect to total capacity is not too high. The latter fact is a boundary condition for traffic aggregate-based routing control in a DiffServ domain. Network element specific parameter control oriented traffic engineering is useful for controlling resources reserved for AF classes, in the form of adjusting scheduling weights, buffer size allocations, drop precedences, and dropping thresholds to reflect the observed service aggregate distribution. For both EF and AF, traffic engineering can be applied to edge configuration, too. When admission control to network resources can be exercised, the results of traffic engineering optimization process can be used to adjust the admission control policy, as mentioned in the previous chapter. In case of impending resource shortage, admission control limitation threshold can be lowered for all services, or for some services only. Multiplexing gain needs to be taken into account in implementing such policy changes into a DiffServ network.


4.2.1

119

Optimizing routing based on service quality characteristics

The feasibility of changing the routing of a traffic aggregate is affected by boundary conditions from inherent service quality requirements of a service making use of the service quality support aggregate in question. A possible target for traffic engineering in a network domain could be a minimization of latency. A possible strategy to achieve latency optimization is the minimization of network-wide delay cost function. An example of overall delay optimization within a domain can be found in [SBD + 01]: S Bl (4.2) C (γ ) = γ Cl − B l l ∈E

Above, S is the average packet size, γ is the average total offered traffic, E is the set of links in the network, Cl are link capacities, and Bl are average link loads. The above form has the limitation of not taking into account the relation between packet size and link capacity on individual links. A possible correction to address this question is: Bl S . (4.3) C (γ ) = avg{Ci }i ∈E Cl − B l l ∈E

This amendment could be seen as a step in the direction of taking per-link characteristics into account. Problem remains: per-traffic aggregate measures. Equation (4.3) could be applied to EF traffic in a multi-service network domain, interpreting Cl as rate limiter setting. In [FT00], a piecewise linear, “artificial” per-link cost function was used, having a form increasing quickly with the per-link loading level approaching link capacity. The network-wide cost function is computed over all per-link cost functions. Decreasing aggregation granularity typically increases the variability of aggregates. The larger the momentary burstiness, the further the short-term routing set-up is from the long-term optimal configuration [SBD + 01]. In a multi-service network domain, delay optimization can be more challenging than what equations (4.2) and (4.3) above imply, since in that case, there may be multiple cost functions involved simultaneously.

120

4.2.2


Traffic engineering using MPLS

As discussed in the previous chapter, MPLS is based on the establishment of LSPs onto which incoming traffic is mapped using the abstraction of Forwarding Equivalence Classes (FECs). LSPs can be used for routing control purposes, and the traffic mapping at edge LSRs can be used for implementing differentiated routing. With proper mechanisms in place in edge LSRs, also multi-path routing for a single traffic aggregate is possible. In what follows, we shall first study how LSPs can be set up for traffic engineering purposes. In general, LSP establishment can be control-driven or data-driven. In the first of these approaches, LSP establishment is controlled explicitly, whereas in the second alternative, LSP set-up is triggered dynamically by the arrival of data packets. LSP establishment using data-driven method gives rise to delay and signalling traffic during the LSP set-up phase. In what follows, a controldriven approach is assumed. It should be noted that also in the control-driven approach, reacting to a changed loading situation in the network is possible, based on the traffic engineering loop and suitable configuration means. The difference from data-driven method in such a case is that the LSP establishment is controlled by a network-level traffic engineering process and thus the LSP mapping decision is made by the traffic engineering means. It is assumed that LSPs already exist at the time traffic is mapped onto them. While this may not be an always applicable solution, this assumption is made in the rest of the book to structure the following discussion more clearly. It is also assumed that multiple LSPs with desired properties may be set up between two edge LSRs. This can be achieved by providing a list of switches through which the LSP must be routed to the edge LSR performing the LSP set-up. The list needs not cover all the switches along the path. Alternatively or in addition to list of “must” switches, a list of switches to be excluded from the LSP routing can be provided. Individual LSPs may be thought to be “pinned down” to a specific route, with a back-up LSP possibly existing for resiliency purposes. This is an enabling technology for what is often referred to as traffic engineering extensions to MPLS. To make use of traffic engineered paths, FECs may need to be routed along nonshortest paths, in the SPF sense with respect to physical IP topology [RFC2702].


121

In addition to controlling routing with zero-bandwidth LSPs, capacity reservations are possible via traffic engineering extensions to LSP set-up signalling both with Constraint-Based Routing Label Distribution Protocol (CR-LDP) and Traffic Engineering extensions to RSVP-based LSP set-up (RSVP-TE). CR-LDP makes it possible to perform resource reservation using token bucket-style parameters. Pre-emption of existing LSPs by later high-priority LSPs is possible both in CR-LDP and in traffic engineering variant of RSVP, RSVPTE. From a traffic engineering viewpoint, the RSVP-TE set-up of LSPs also has the possibility of performing a shared resource reservation for multiple LSPs. A tentative technology at the moment, constraint-based routing of LSPs is supposed to be able to take into account the load of individual switches and existing resource reservations roughly in the same way as SVC set-up procedures in ATM. Traffic engineering extensions to OSPF have been proposed as an enabling technology for this [KYK02]. The full treatment of routing of LSPs in the case of reservations is beyond the scope of this book, and pointers to further information can be found, for example, in [Wang01]. Aggregation of FECs is possible in MPLS with label stacking. Due to this, the granularity of traffic engineering can be made coarser where applicable. Note that this means in practice the establishment of a new MPLS domain inside an existing MPLS domain. Summarizing, MPLS supports or interworks with all the generic methods of traffic engineering listed at the beginning of Section 4.2, with the exception of admission control for service instances. Specifically, the controlled definition of backup routes is possible, e.g. by setting up back-up LSPs in advance. Key technologies of MPLS making advanced traffic engineering possible are the capability of setting up LSPs, and mapping of traffic onto adequate LSPs in edge LSRs. Thus, the consistent management of LSP set-up and edge mapping is important for MPLS-based traffic engineering. The differentiated treatment of DiffServ behavioural aggregates within a LSP is standardized within IETF [RFC3270]. This is our next topic.

4.2.2.1 DiffServ over MPLS Behavioural aggregates may need to be prioritized in a multi-service network using MPLS. This may be the case in an access network

122


domain where the individual links are not over-dimensioned, and the service requirements of the behavioural aggregates are sufficiently distinct from each other. In this book, it is assumed that DiffServ is used for service quality support purposes in such scenarios. When only standard IP routing protocols are used for traffic engineering, joint management of DiffServ and routing protocols is not necessary or even possible. The need for common management in the case of DiffServ over MPLS arises from the fact that both LSRs and DiffServ routers perform mapping from traffic aggregates to other traffic aggregates. In the case of a DiffServ-capable MPLS switch, the switch needs to be able to accept SDUs from an input interface, route/switch them to an egress interface, and map traffic into a proper queue at the egress interface of the switch. After queueing and scheduling, the SDU needs to have been relabelled based on MPLS switching tables. DiffServ-based prioritization can be used in MPLS-based traffic engineering either with or without resource reservations. In resource reservation mode, reservations can be performed as a part of the LSP set-up using suitable traffic engineering extensions. When resource reservations are not used, on the other hand, LSPs can be used purely for routing control. What is needed is a way to map traffic from LSPs to PSCs (scheduling entries and algorithmic dropping treatments) in DiffServ-capable MPLS switches. PSCs correspond to a PHB class, such as EF, AF1, AF2, AF3, AF4, or BE. There are two possibilities for achieving this goal: 1. The mapping is the same in all of the MPLS switches. This means that the information based on which the mapping is done is contained within the MPLS shim header. 2. The mapping may vary from switch to switch. In this alternative, the mappings need to be configured for each switch. Two framework schemes for DiffServ/MPLS interworking have been subject to standardization in IETF, called EXP-inferred PSC LSP (E-LSP) and Label-only-inferred PSC LSP (L-LSP). In the ELSP paradigm, up to eight behavioural aggregates are mapped to a single LSP, and mapping to a scheduling entry at an egress interface within a DiffServ-capable MPLS switch is made based on the three experimental (EXP) bits in the MPLS shim header. The limitation of eight BAs comes from the three EXP bits in MPLS shim header. The mapping from EXP bits to DiffServ PSC/algorithmic


123

dropper configuration is not in principle constrained, although some real-world DiffServ/MPLS switches by default allocate some of the bits for PSC and others for drop precedence. With E-LSP, one or more LSPs may be set up between two switches, depending on the number of traffic aggregates that need to be supported. In the L-LSP paradigm, on the other hand, each traffic aggregate (Behavioural Aggregate, BA) is mapped to a separate LSP. Within the MPLS domain, each LSP corresponds to one PSC. When multiple PSCs are used, the number of LSPs in a domain may grow quickly with this scheme, and the management system must be able to cope with this challenge. For a single E-LSP between each pair of switches, the mapping from LSPs to queues can be identical in all the switches for an individual LSP, although the actual label associated with the LSP is of course different in each switch. If more than one E-LSPs is used between two switches, the situation can be more complex. For L-LSP, on the other hand, the LSP/PSC mapping tables inside the network elements can be set up at the same time as the LSPs as a part of the LSP set-up signalling. IETF standardization for management of DiffServ/MPLS interworking is ongoing at the moment [RFC3270]. Irrespective of LSP/PSC mode, the mapping from LSP to PSC can be configured in individual switches as a part of signalled LSP set-up. The shared mode of RSVP-TE can be used to perform a joint capacity reservation for multiple LSPs. The IETF requirements draft for DiffServ over MPLS [LFT + 02] includes more details about issues such as trunking, and mapping of traffic into LSPs. For the purposes of the present chapter, it is sufficient to know that operating DiffServ over MPLS is possible, and can be achieved with or without reservations.

4.2.3

Traffic engineering using IP routing protocols

The management interface for individual IP routing protocols provides somewhat limited possibilities for traffic engineering, as compared with MPLS. Due to the distributed nature of IP routing protocols, route pinning is only possible via definition of static routes within an AD. On the other hand, reconfiguration of routing is performed automatically in the case of link or router failure. Controlled routing behaviour in case of back-up routes requires extensions to standard IP routing. In OSPF, for example, affecting

124


routing directly requires a management system interface towards the link state table. Using multiple routes for a traffic aggregate is possible with link state protocols such as OSPF, if multiple-path routing is supported by the routing protocol instances running in individual routers. In such a case, multi-path routing for a traffic aggregate can be controlled by modifying the link weights in OSPF. The choice of metric used for computing the weights is one of the control means. As with MPLS, delay variations of real-time flows are an issue for multi-path routing. Techniques such as hashing [Wang01] may be necessary to maintain constant routing for individual flows. Limited amount of route pinning can be defined by overriding default IP routing by installing static routes. Implementation of differentiated routing requires that individual routers maintain multiple routing tables, one for each separately routed traffic aggregate. Such schemes, having been called ToS routing or QoS routing, among other names, have been researched for a long time but have not been deployed widely. Traffic engineering in this case could be based on affecting the metrics used in computing each of the routing tables.

4.2.4

Summary

In general, desirable properties for the routing control aspect of traffic engineering include the capability of controlling routing, the possibility of differentiated routing of traffic aggregates, and the routing of single traffic aggregate using multiple paths. The concept of resource reservation as a part of traffic engineering can be utilized in configuring the DiffServ rate limiters for EF along the selected path, for example. MPLS provides advanced traffic engineering capabilities for precise routing control and optional resource reservations in IP networks. MPLS can be made compatible with DiffServ by combining the configuration tasks of LSP switching, on the one hand, and mapping to proper PSC/algorithmic dropper treatment, on the other. Depending on the number of supported traffic aggregates, selected DiffServ/MPLS inter-operation mode, and desired routing treatment, more than one LSP may be needed between two switches. As with DiffServ, MPLS requires consistent configuration. IP routing protocols provide a limited means of performing traffic engineering. Hash table based methods make it possible to use

4.3 CONFIGURATION

125

multiple paths for routing a single traffic aggregate when link state protocols such as OSPF is used. Pinning down a route requires definition of static routes. Affecting the route cost metric is one of the means of controlling routing with LS protocols such as OSPF. Future traffic engineering extensions to IP routing protocols may provide more control over routing.

4.3

CONFIGURATION

The mere existence of enabling traffic engineering technologies such as DiffServ and MPLS is not enough. Deployment of network reconfigurations must be feasible from the point of view of network management complexity. This issue has been referred to both in the context of DiffServ and MPLS. Let us take a look at an enabling technology next, starting with a historical perspective. The Internet of old was built around a small number of computers in academic institutions. Computers were managed separately. In the Internet today, and operators’ IP networks in general, the number of network elements is often large. Business environment is becoming ever fiercer – at least until recent years, corporations have outsourced IT functions to obtain better value for the buck (or quid). The implementation of multi-service support in IP networks makes configuration management more challenging still. The number of network configuration sets that need to be managed has grown quickly – to name but one example in addition to service quality, security is an issue that needs to be dealt with consistently across an AD. A further tendency is that of raising the abstraction level of network management [Kos01]: the management system of the future is able to present the network operator with a view to user groups and services in the network instead of individual network elements. Some further issues are reducing the number of management interfaces that staff needs to be trained to use; and reducing the risk of failures due to accidental manual misconfiguration. The situation calls for more efficient solutions for managing network elements. The management interface should preferably be standardized, scalable, and automated. A fashionable trend in network management research has been that of intelligent agents, briefly summarized as the capability of delegating control to network elements. A special case of this, mobile management agents

126


with limited autonomous configuration power can be sent to traverse a network to optimize its behaviour. An example of such a system can be found in [PPT + 02]. In this book, a tad more conservative approach is assumed, where a limited amount of configuration autonomy can be enabled in network elements, but the capability of performing certain network configuration functions always resides within a network element. This kind of scheme is easier to manage from a security viewpoint. Policy management has emerged as a practically deployable paradigm for automating the task of network configuration, as well as potentially allowing a limited degree of controlling capability to network elements. A good aspect of policy-based management is that it can be used both for automating a “traditional” network configuration as well as implementing the limited delegation of configuration power to network elements. It should be noted that policy management is an enabling technology from the viewpoint of performing the configuration part of traffic engineering process. Policy management, however, can be viewed from other viewpoints where its role is not equally subservient.

4.3.1

Policy-based management

Policy management is being standardized in two organizations: IETF and Distributed Management Task Force (DMTF). The policy management information of IETF [RFC3060] is an extension to the DMTF Core Information Model (CIM). Central themes in policy management are raising the abstraction level in management tasks, having structured management information bases, and the ability to provide means of delegating decision-making capability to the network elements themselves. For example, a border element of an AD belonging to an ISP could be instructed to implement different filters during business hours than during off-peak hours. In general, the simplest rules are of the form shown in Figure 4.6. The basic reference architecture for policy-based management is shown in Figure 4.7. The policies are stored in a policy repository, and the policy to be deployed is chosen by a Policy Decision Point (PDP). Policies are implemented in Policy Enforcement Points (PEPs). Inside a PEP, the implementation of a policy is reflected as a configuration. Not shown in the figure, network

4.3 CONFIGURATION

127

If (condition 1 then Action 1 Else if (condition 2) then Action 2 … Else if (condition N) then Action N Else Default action End if

Figure 4.6 An example of a policy rule

PR PDP

PEP IP network PEP

PEP

Figure 4.7 Reference architecture for policy-based management Note: Provisioned mode shown

elements can also contain local policy decision points (LPDPs) capable of policy deployment decision making. The policy-based management can operate in two modes, namely the outsourced mode (also called pull mode) where the PDP makes policy decisions at the request of PEPs; and the provisioned mode (or push mode) where the PEP executes the policies configured by the PDP also in situations in which the instalment of a new policy by the PDP does not take place in response to a request from the PEP. The provisioned mode can be used to perform network-wide configurations, as well as configurations of individual elements. For scalability reasons, outsourced mode is more useful for individual network elements. Outsourced mode can be used, for example, in the case in which the network element cannot store all the policies it needs of its operation. Another example is the occurrence of entirely new conditions in the network, the generation of policies which requires capabilities beyond the processing power of a router, for example. Also, the existence of such new conditions may have network-wide consequences.

128


Obviously, the architecture shown above is not enough for the task of policy-based management. There needs to be a device to define the policies and store them in the policy repository. To provide real value for the network operator, there should be a policy creation tool, which makes it possible to define the policies at a sufficiently high, an abstraction level. Using an example, let us define DiffServ edge routers as a grouping of individual elements, in policy-based management called a role. The VoIP marking rule is applied to this role, and then applied to elements belonging to that role. Using these definitions, the policy creation tool could let the operator apply the following rule domain-wide, affecting all DiffServ edge routers: For all (DiffServ edge routers): If (Voice-over-IP call) Then mark as Expedited Forwarding. There are some further requirements for policy management, which are mentioned here to provide some degree of concreteness in the high-level description. There must be a means of detecting and resolving policy conflicts so that no conflicting policies are applied to the same router. Such situations may arise unless the policy management system is designed carefully. A conversion must be available from generic policies into device-specific policies or configurations. Such a conversion can be built into the actual devices, or implemented by a middle component. The data model used for storing policies must be structural, extensible, and able to express policies at different levels of abstraction. The Extensible Mark-up Language (XML) is one example of a language in which such data model can be written. The interested reader is referred to [Kos01] for more examples on policy structures. Many protocol interfaces can be used between PDP and PEP, including Simple Network Management Protocol (SNMP) and Common Open Policy Service (COPS). SNMP is commonly used for network status monitoring. COPS was developed within IETF for the outsourcing mode of policy management operation described above. For the provisioning mode, a separate variant of the protocol called “COPS for provisioning” (COPS-PR) has been developed. In the COPS-PR paradigm, MIBs are replaced by Policy Information Bases (PIBs), providing structured information

4.3 CONFIGURATION

129

models. Between the policy repository and PDP, the Lightweight Directory Access Protocol (LDAP) has been used as an example in the standardization. In a recent article, authors suggest using COPS also as a protocol for admission control both in the “UNI” interface and between edge routers and the resource admission control agent within a domain [SV02]. As an application of policy-based management, we shall take a look at automated configuration of DiffServ routers next.

4.3.2

Policy-based management of DiffServ

The DiffServ PIB [FM + 02] encompasses the functions of a generic DiffServ router, being composed of Traffic Conditioning Blocks (TCBs) corresponding to the interfaces of the router. The TCB functions can be used to control both DiffServ edge and core routers. The functions of a single TCB were listed in the previous chapter, consisting of: • Classification. How incoming packets are grouped into behavioural aggregates for further DiffServ functions. • Metering. Which token bucket parameters – if any – are applied in policing incoming flows. • Action. What is done for out-of-profile packets? Action can be “none”, “remark”, “shape”, “drop”, or “multiplex”. • Algorithmic drop. What kind of algorithmic drop – for example, Random Early Detection (RED) is applied to behavioural aggregate? • Queueing. Queue-specific parameters. • Scheduling. Details of scheduling algorithm. The TCBs are used for configuring both ingress and egress interfaces of a router, as shown in Figure 4.8. Logically, routing takes place between an ingress interface and an egress interface. Not all the functions inside a TCB have to be present for all interfaces. Thus, for example, there need not be queueing or scheduling methods available in the ingress interface. The same action may have different meaning in ingress and egress interfaces. For example, classification can be performed per flow at the ingress interface of

130


Ingress

Switching matrix

TCB1 classifier

meter

classifier

action alg. drop

queue

meter

meter

action

scheduler

alg. drop

TCB2 classifier

Egress TCB3 queue

scheduler

queue

scheduler

TCB4 classifier

action alg. drop

queue

meter

scheduler

action alg. drop

Figure 4.8 TCBs inside a router

a DiffServ edge router, but a core router may perform classification per behavioural aggregate in the egress interface only.

4.3.2.1 Case study of policy-based management of DiffServ Next, let us study an example of policy-based management in the case of DiffServ in a domain where it is used together with MPLS. The topology for the example is shown in Figure 4.9, consisting of a pure DiffServ domain with a neighbouring MPLS domain. Let us assume that the ingress edge routers of the DiffServ domain are fed with traffic from Small or Medium Enterprise (SME) customers. In the example, the traffic from the customers consists of VoIP traffic, HTTP traffic and SMTP traffic. Let us further assume that the customers have SLAs with the ISP running the DiffServ domain, specifying traffic profiles for each of the traffic types. The ISP of the operator is assumed to connect to a MPLS backbone in a Point of Presence (PoP), and the MPLS backbone supports DiffServ over MPLS using the E-LSP scheme (i.e., prioritizing the MPLS PDUs based on the three EXP bits in the shim header).

Edge router

Core LSR MPLS domain

DiffServ domain Edge router

Core router

Edge LSR

Edge LSR Core LSR

Edge router

Figure 4.9 Topology of the DiffServ-MPLS policy management example

4.3 CONFIGURATION

131

The configuration of the DiffServ domain proceeds in the example as follows: 1. The operators make separately network dimensioning based on SLAs made with customers, business strategy and traffic forecasts. Also the required PoP capacity is computed. 2. The ISP agrees with the backbone operators which behavioural aggregates (BAs) are to be used in the backbone to transport the three traffic types. 3. Operator selects DiffServ PHBs based on backbone BAs and traffic type requirements. Let us say that the following mapping is used: a VoIP is mapped to EF PHB. b Web browsing is mapped to AF21, AF22 and AF23 based on the price paid by different SME customers. c SMTP traffic is mapped to AF31. 4. DiffServ/MPLS interworking in PoP is configured to correspond to steps 2 and 3. If the PoP edge LSR supports policy-based management of DiffServ/MPLS interworking, DiffServ/MPLS interworking PIB can be used for this purpose. 5. DiffServ core routers are configured to reflect the result of network dimensioning. This means the following aspects: a Mapping from DSCP to queue. b Setting for rate limiter for EF traffic. c Scheduling weights for Class-Based Weighted Fair Queueing (CBWFQ) queues. d WRED parameter settings for CBFWQ queues. 6. DiffServ edge routers are configured to reflect the SLAs for individual customers, meaning the following: a DiffServ classifiers are configured to recognize traffic from different SME customers. b Policers are configured according to SLAs. c Traffic mapping is made according to the allocation in step 3. After the aforementioned steps, the initial QoS configuration is carried out. The network can be put into operational use, and the traffic engineering process of Section 4.1.2 can be used to optimize the network behaviour.

132


Clearly, proper dimensioning of the network is an important step for QoS-critical services such as VoIP. Performing this endto-end is a non-trivial task. Architectures and reference models for this are discussed in Chapter 5, and the case study in Chapter 9 includes an example of QoS dimensioning.

4.4

SUMMARY

Traffic engineering tools for IP networks have been reviewed, using the IETF traffic engineering concepts as a framework. The traffic engineering process thus consists of configuration, monitoring, and optimization of network resources using a management system. The sub-tasks of IETF traffic engineering are capacity planning, routing control and resource management. Traffic engineering was also reviewed process-wise. Capacity planning in a multi-service network makes the first configuration of service quality support, which can then be optimized using the traffic engineering process. Capacity planning will be discussed in the next chapter, and an example provided in Chapter 9. From the viewpoint of traffic engineering, policy-based management is an enabling technique for flexible configuration of the IP network domain, making possible not only the initial configuration of a multi-service network, but also the implementation of optimized network configurations. Policy-based management also makes it possible to delegate decision-making capability in network elements in a controlled manner. An example of using policy management to configure an IP network using DiffServ and MPLS network was presented. Feedback of network status can be obtained on multiple scopes, including individual network elements and network domains. This subject will be discussed further in Chapters 6 and 7. Central to the optimization of a multi-service network for service quality support purposes is obtaining feedback on a service level. Technologies for performing this task were reviewed, and will be discussed further in Chapter 7.

5 Mapping Service Requirements to Network Resources The ability to properly map services to network resources in a multi-service network is highly important both for making the initial configuration of a network domain, and also as a basis for performing network configuration optimization. The basic task in both cases is the same, although in the latter case there is an initial configuration to start with, as well as potentially a larger number of existing boundary conditions for the new configuration. Resource allocation is an optimization problem where the available network resources, SLAs for different parties, and requirements of service types are examples of boundary conditions. The SLA interfaces relevant to resource allocation are illustrated with an example configuration in Figure 5.1. The responsibility of endto-end service quality can be thought to be by default with service providers, who use SLAs towards network transport providers to implement the service quality. Alternatively, an access network operator may provide a set of services from outsourced Application Service Providers (ASPs), such that the access network operator is responsible for end-to-end service quality. There may be more than one service provider involved, for example, in using IP telephony services in such a way that the Implementing Service Quality in IP Networks Vilho Räisänen  2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X

134

MAPPING SERVICE REQUIREMENTS TO NETWORK RESOURCES

SLA Service subscriber

Service operator

SLA

SLA Transport operator

Service operator SLA Transport operator

SLA Service subscriber

SLA

Figure 5.1 SLA reference model for the present chapter

caller and callee use different IP telephony service providers. In the general case, there may be also transit operators involved. As to services, both external service operator/transport operator and operator-internal service/transport interfaces are illustrated in Figure 5.1. In general, there is no need to have a one-to-one relationship between service and transport operators. Available network resources are the most limiting factor when service mapping in multi-service access networks is considered. This is true not only when the network infrastructure already exists, but also when a new network is being built. In backbone networks, on the other hand, more conservative network dimensioning is typically possible due to higher flow aggregation levels. The generic traffic engineering process described in the last chapter can be used to optimize the use of the available resources in both access and backbone networks, but the starting point for this optimization is the initial resource allocation. When traffic engineering process can be applied, requirements for the accuracy of the initial configuration become smaller. When the traffic volumes transported in the network domain are anticipated to grow with time, dimensioning of a new network infrastructure usually takes into account future growth in traffic volumes. Also in this case, the initial configuration is not as critical as for a fully loaded multi-service access network. The goal should nevertheless be as precise as possible a resource allocation, starting from the anticipated shares of traffic types. SLAs for direct end user customers can provide flexibility for resource allocation, if SLAs include traffic types that can be used for this purpose. The SLAs for different customer segments and services may be different with respect to degree of details of service quality support provided. As discussed in Chapter 2, for services with stringent quality support requirements such as

5.1 SCOPE OF THIS CHAPTER

135

multimedia conferencing, absolute guarantees may be necessary. On the other hand, for data type services, statistical guarantees may be sufficient. A change of admission control policy to demand service quality types is a tool that can be used to control the resource allocation in access networks when the service quality invocation procedures allow for this. Towards the service and network providers, the SLAs are typically more static. The resource allocation optimization and application of the traffic engineering process may result in a need to modify the SLAs, but this typically takes place at longer timescales than one associated with resource management for the operator’s own end user services. Thus, it could be said that the traffic engineering process should also yield an indication of its means becoming exhausted, being indicative of a need to modify SLAs or by other means restore the operational efficiency of traffic engineering.

5.1

SCOPE OF THIS CHAPTER

Chapter 2 described the intrinsic requirements of services and their characterization. Chapters 3 and 4 described mechanisms for providing service quality support in the network. This chapter deals with the link between service requirements and IP network service quality support. The concepts in this chapter are used in discussing service management in the next chapter. Let us next define the reference model for this chapter. For the purposes of the present chapter, the end-to-end delivery path for service instances is assumed to consist of multiple transport operators, each capable of providing support for service quality for a set of services, either statistically on the level of behavioural aggregates or per flow (cf. Figure 5.1). It is further assumed that each transport operator is capable of providing multi-service support. Each transport operator is assumed to be using a per-domain service quality support mechanisms independently of each other. The actual mechanisms can be circuit-switched guaranteed QoS for telephony, over-dimensioning, or DiffServ, to name but a few alternatives. The resource allocation discussion in this chapter pertains to a multi-service DiffServ domain specifically, and thus is most directly related to access networks. Services are assumed to be managed by service operators by having Service Level Agreements (SLAs) with end users, with

136


transport operators and between each other, as necessary. A transport operator may also be a service operator, in which case the service operator/transport operator interface is an operator-internal one. Referring back to the client/server and connectivity/service paradigms used in Chapter 2, the model of Figure 5.1 is of latter type, allowing for signalled interoperation of service providers for a single service instance. The client/server application of Figure 5.1 could only involve single service subscriber, single service operator, and one or more transport operators. For the service provider, service quality provision is at best related to the intrinsic quality requirements of individual service event types. Depending on the SLA type, the service provider may also need to understand service quality support mechanisms of the transport operators. For the transport operator, on the other hand, one part of the optimization problem is allocation of services to proper service quality support classes. This is a part that the service provider may need to understand, unless the SLA between the service provider and transport operator is sufficiently detailed for the service operator not to need worry about technical details of the service quality support details. A second aspect of the transport operator optimization relates to using resources effectively to implement multi-service SLAs for different parties involved. Efficient resource usage includes selecting an optimal set of supported service quality aggregates, and using network resources to implement SLAs using the aggregates. Here, it is assumed that the service provider and the transport provider are able to negotiate the behavioural aggregate used for service quality support. In the discussion below, the SLAs for service providers are conceptually seen as boundary conditions for the resource allocation of the transport operators’ own end user services, the basic process and target of resource allocation being the same for both types of traffic aggregates. For operators’ own services, there is no need to take into account an external negotiation interface towards different business party, which is why they are used for simplicity in the discussion below. Next we shall review service quality support-related resource allocation models from ETSI EP TIPHON, Third Generation Partnership Project (3GPP), and QoS Forum. Two further DiffServrelated examples are provided due to their relation to policing, one

5.2 ETSI EP TIPHON REFERENCE MODEL

137

of them being draft ITU-T model. After that, the concept of utilitybased resource allocation is reviewed. The TIPHON reference model is relevant to IP telephony, that of 3GPP to mobile services, while the QoS Forum and ITU-T models and utility-based resource allocation reference models are generic in nature. The concepts from these models are used in formulating a generic framework for resource allocation for multi-service IP network.

5.2

ETSI EP TIPHON REFERENCE MODEL

The European Telecommunications Standardization (ETSI) is an organization making international telecommunications standards. The best-known ETSI standards are probably GSM and UMTS. During the latter half of the 1990’s, ETSI founded the IP telephony project TIPHON, which has devised a reference models for IP telephony, in which service providers can be separated from transport operators [TIPHON-3]. The model pertains to IP telephony specifically, but is sufficiently generic to be used here. While somewhat abstract, it illustrates the logically necessary functions and interfaces of a separated service/transport paradigm. Particularly valuable for the present purposes, the ETSI TIPHON reference model also includes a QoS reference model.

5.2.1

Architecture

The reference model consists of separated service and transport layers, and is illustrated in Figure 5.2. The two-tier model allows for telephony providers, using Session Initiation Protocol (SIP), for example, to operate without having to build own transport networks. When a VoIP call is set up between the communicating parties, the IP telephony service provider for the calling party sets up the call by communicating with the service provider of the called party, as necessary. The respective service operators at each end set up necessary transport resources. As a result of the resource set-up, the communicating hosts may be provided with a QoS tokens to authorize the access to appropriate transport resources [TIPHON-3].

138


Service provider 1

Service provider 2

Telephone

Telephone TRM Transport operator 1

TRM Transport operator 2

TRM Transport operator 3

Figure 5.2 ETSI EP TIPHON reference model Note: Solid lines denote the transport layer, dotted lines the service layer, and dashed lines the link between service and transport layers

The reference model has been targeted to be “agnostic” with respect to QoS mechanism used on the transport layer, and should therefore work with ATM, IP QoS mechanisms including Diffserv and IntServ, and over-provisioning, for example. End-to-end QoS requirements of services are dealt with by using QoS budgets, so that the end-to-end service quality requirements are known, broken down into per-service provider allocations and further to transport level allocations. For example, the service provider 1 in Figure 5.2 is supposed to be able to calculate how much delay and packet loss is allowable in transport operator 1’s domain. Service provider 1 would then communicate this requirement to Transport Resource Manager (TRM) within transport operator 1’s domain to check whether the necessary service quality support can be implemented by the transport operator. The per-domain allocation does not have to be statically allocated for a particular path, but can also be dynamically negotiated. The QoS resource allocation may be iterative and affect call routing. As has been seen in previous chapters, the properties of the terminals potentially affect end-toend service quality. In the TIPHON work, this has been taken into account by classifying the terminals according to their impact to end-to-end service quality. There is no need to have one-to-one correspondence between service and transport operators in TIPHON’s model. In Figure 5.2, Service Provider 2 has service quality support signalling interface to two transport operators along the end-to-end path. In fact, there need not be QoS interface from a service operator to each transport operator at all, but service quality support signalling can take place between transport operators. The QoS reference model [TIPHON3] also contains exemplary signalling charts for different interworking scenarios. One signalling mode shown therein performs

5.2 ETSI EP TIPHON REFERENCE MODEL Table 5.1

139

Functional elements of the TIPHON QoS control model

Element

Layer

Description

QoS Service Manager (QoSM)

Service layer

Mediates requests for end-to-end QoS based on policies stored in QoSPEs, communicating with other QoSMs and TRMs.

QoS Policy Element (QoSPE)

Service layer

Manages service QoS policies and authorization.

Transport Resource Manager (TRM)

Transport layer

Applies set of policies and mechanisms to transport resources to provide QoS guarantees across the domain controlled by the TRM.

Transport Policy Entity (TPE)

Transport layer

Functional entity maintaining the policies of a transport domain.

Transport Function (TF)

Transport layer

Logical entity representing the transport resources in the domain.

Interconnect Function (ICF)

Transport layer

Entity for interconnecting transport domains; typically AD boundary with optional flow authorization policies.

the end-to-end resource allocation set-up signalling entirely on the transport layer, initiated by communication endpoints (terminals). All told, TIPHON’s QoS model includes the elements listed in Table 5.1. QoS Service Managers handle the end-to-end service quality including QoS budget negotiations and interfacing to the transport layer, based on service layer policies. Instantiation of service quality on transport layer is controlled by Transport Resource Manager, which can operate on aggregate level or flow level. When IntServ is used end-to-end, service quality signalling takes place between TRMs and terminals. In TIPHON’s QoS control model, the service and transport layers are logically separated from each other. Due to this, they have sets of policies that operate on different conceptual levels. The

140


policies of the service domain relate to authorization of service instantiations, whereas the policies of transport domain pertain to authorization of flows to classes of resources. The TIPHON QoS reference model lists three ways of allocating QoS budgets across transport domains: • Dynamic signalling of transport QoS parameters during call set-up. • Static SLAs between service domains. • Aggregation of transport domain resources and caching information of QoS resource availability. Per-call signalling is akin to per-flow RSVP reservations, and has similar kinds of scalability concerns associated with it. Particularly in IP telephony, the delay due to resource set-up is also important. Static SLAs between different parties is the simplest model. An elaboration of this allowing for more flexibility is the third model, in which admission control is performed to available resources between operators.

5.2.2

QoS model

The TIPHON QoS model is illustrated in Figure 5.3, consisting of QoS characterizations on the user layer, application layer, and

TIPHON Voice QoS Class

Codec, Frames per Packet, Frame Size, Jitter Buffer Delay, FEC (Redundancy), Overall One-Way Delay, Packet Loss

Packet Loss, Mean Delay, Delay Variation

USER

APPLICATION

TRANSPORT

Figure 5.3 QoS characterization of user, application, and transport levels in the TIPHON reference model Source: From [TIPHON-3]

5.2 ETSI EP TIPHON REFERENCE MODEL

141

transport layer. QoS characterization on user layer consists of the TIPHON voice QoS class, having five possible values: wideband, narrowband high, narrowband medium, narrowband acceptable, and best effort. Subscribers can choose between these classes based on associated pricing and quality attributes. The voice QoS class can also be a part of the subscription profile. Mapping of user layer QoS characterization to application layer characterization is performed by interpreting the voice QoS class in technical terms. The actual parameters involved depend on the outcome of end-to-end codec negotiation. In SIP, this is performed using the Session Description Protocol (SDP) during call set-up. For example, the negotiated parameters could include the codec to be used (for example, AMR, GSM FR, G.723.1, G.711) and the bit rate for the codec (ranging from 4.75 to 12 kbit/s for AMR). QoS characterization on the transport layer, that is, the service quality support that a transport operator needs to be able to provide, are derived from two sources: 1. Application quality characterization. 2. End-to-end QoS budget. The two are not independent, as the end-to-end QoS budget may be used in negotiating the application parameters (codec). The choice of codec and audio sample size affect the end-to-end delay. The relation between end-to-end delay and end user experience used by TIPHON is shown in Figure 5.8 in Section 5.7.4.

5.2.3

Summary

In ETSI TIPHON IP telephony reference model, the end-to-end negotiation is performed under control of service layer operators, and involves one or more transport operators. The service operator performs the mapping from service quality to transport resource requirements. The TIPHON QoS model consists of a subscription, codec, and transport levels, addressing the different abstraction levels that can be used in telephony. The transport operator uses a logical transport resource management element to perform admission control to available resources. The weakness of the original TIPHON QoS model is the amount of per-flow signalling associated in admission control of a new

142


flow: at least one of the service operators was supposed to signal to one or more transport operators to ensure appropriate service quality support for the flow. When more than one service provider is involved in the end-to-end set-up, handling all scenarios arising from each operator using service quality support signalling with the transport operator or operators, call set-up delay can quickly become prohibitively large in such cases. The concept of performing admission control to traffic aggregates was incorporated into the TIPHON model as a further mode, having better scalability properties. We shall return to the topic of admission control to aggregates in Chapter 8.

5.3

QBONE

Internet2 project is a partnership to develop inter-domain service quality support for the Internet, led by US universities and participated in by a number of corporations and other organizations [THD + 99]. Distance learning, remote instrument access and control, advanced scientific visualization and networked collaboration are listed as potential uses for service quality support in the future Internet. Internet2 addresses the following areas: applications, middleware, advanced networks, engineering, and partnerships. QBone is the QoS testbed of Internet2 to address the needs such as those listed above, and has been attended to by a number of network service providers. To quote the Internet2 website (http://www.internet2.org): The goal of the QBone is to provide an inter-domain test bed for differentiated services (DiffServ), where the engineering, behaviour, and policy consequences of new IP services can be explored. The goal of QBone is to use IETF standards to implement interdomain architecture. More precisely, each QBone node is required to support Virtual Leased Line (VLL) emulation using Expedited Forwarding (EF). This service support mode is called QBone Premium Service (QPS), and will be described in Section 5.3.1. Network elements are required to support the configuration that makes VLL service possible. Inter-domain interworking for DiffServ in QBone paradigm can be implemented by SLAs and Service Level Specifications (SLSs),

5.3 QBONE

143

the latter being the technical part of the SLAs. The inter-relation of SLAs and SLSs will be discussed in more depth in the next chapter, and for present purposes it is sufficient to know that since SLAs/SLSs exist at the boundaries of the domains, they can at their simplest be based on bilateral agreements between network operators. The QBone architecture aims to provide added value to end-to-end DiffServ + SLA/SLS architecture with enhanced support for dynamic inter-domain operations. The goal is to specify a common set of operational practices and procedures to be followed by network operators. Bandwidth Brokers (BBs) are viewed as tools for making automated admission control decisions, network device configurations, and dynamic interdomain SLAs. Bandwidth brokers will be discussed further in Chapter 8. For present purposes it is sufficient to know that static SLAs can be viewed as a special case of dynamic bandwidth broker paradigm, and that neither SLA negotiation between domains nor admission control towards end system necessarily have to be automatic. Thus, the bandwidth broker – at most general – is a conceptual device in discussing resource management. A further requirement is an integrated measurement infrastructure with hooks provided for supporting end-to-end debugging and auditing by users, network operators, and implementers. Both active and passive measurement data may be collected for this purpose and preferably shared openly among participants.

5.3.1

Service support models

Within the QBone, each participating network is a DiffServ Domain that inter-operates with other QBone networks to provide the end-to-end QBone services. Two separate “service models” have been devised, the first of which must be supported by all QBone domains. Within the terminology of the present book, the two models would be better termed service support models. 1. QBone Premium Service (QPS): QPS is a low-delay, low-jitter, and low-loss service based on the DiffServ EF model. Token bucket profiler on the network edge configured with token bucket parameters including peak rate, and bucket depth of MTU bytes. The following definition is from the Internet2 website:

144


QPS is based on reservations for token bucket parameters in DiffServ network. A QPS reservation makes a simplex, peaklimited bandwidth assurance. The extent of a QPS reservation may be entirely within a QBone domain, from one edge of a QBone domain to another edge of the same domain, or through multiple QBone domains and is defined by a service source and service destination, each of which is, in general, defined by a network prefix. A QBone reservation consists of the following data [THD + 99]: source, destination, route, starting time, ending time, peak rate, MTU, and jitter. Requirements for QBone SLS are listed, including SLS components such as the Traffic Conditioning Specification (TCS). 2. Alternative Best Effort (ABE): ABE provides a low bounded queueing delay service in the Internet, while still being best-effort, and requiring no additional charging or usage control. To quote the Internet2 website, [G]oal [of ABE] is to help applications with stringent real time constraints, such as interactive audio. With ABE, it is not required to police how much traffic uses the low delay capability, the service being designed to operate equally well in all traffic scenarios. Applications choose between receiving a lower end-to-end delay and receiving more overall throughput. Every best effort packet is tagged as either “green” or “blue”. “Green” packets receive a low, bounded queueing delay. To ensure [that] “blue” packets do not suffer as a result, “green” flows receive less throughput [than blue flows] during bouts of congestion. Green versus blue marking differentiates between traffic types, which are affected by per-packet latency values and those, affected only by the overall throughput. Examples of applications using the green and blue markings are IP telephony and web browsing, respectively. The two service types of ABE do not map directly to standardized AF or EF Per-Hop Behaviours.

5.3.2

Summary

The QBone reference model is an end-to-end model for transport network service quality support means for single-domain as well

5.4 3GPP QOS MODEL

145

as multi-domain case. The model addresses network service quality support modes and mechanisms, and service mapping is not addressed, apart from the service quality support models provided. Two such service models are provided: obligatory QPS, and tentative ABE. QPS provides low-delay, low-jitter, and low-loss service quality support. QPS requires policing, and is based on one-way reservations of capacity using the token bucket paradigm within one or more domains. QPS can be implemented with the EF PHB of DiffServ. ABE provides the possibility of trading overall throughput for low delay service. ABE does not require policing at the network edge. ABE does not map directly to standard DiffServ PHBs. In its simplest form, the end-to-end QBone model can be implemented with DiffServ within each domain with bilateral SLA/SLS agreements between operators. QBone is studying bandwidth brokers as a tool for admission control to network resources, as well as for dynamic inter-domain SLAs.

5.4

3GPP QOS MODEL

General Packet Radio Service (GPRS) was designed to make accessing of packet-oriented services better integrated with the cellular network than is the case in circuit data of GSM. The first GPRS standard version (release 97) supports circuit-switched (CS) telephony, CS data as well as packet-switched (PS) data traffic. The communication between a GPRS terminal and another IPaddressable device (another mobile terminal or an Internet server, for example) takes place using a Packet Data Protocol (PDP) context, having QoS parameters associated with it. From the point of view of end user IP communication, GPRS Gateway Support Node (GGSN) at the edge is the access router used by the mobile terminal, and PDP context hides most mobility-related functions from endpoints of end user IP communication. The GPRS R 97 QoS profile defines the following requirements for the service: delay, service precedence, reliability, mean throughput, and peak throughput [KP01]. Of these parameters, delay means end-to-end delay, service precedence means roughly drop precedence, and reliability defines which degree of loss the service can tolerate. The QoS parameters are used in the GPRS

146


radio interface to select a the radio priority, and in the GPRS core network to select adequate core network QoS parameters. The Universal Mobile Telephone System (UMTS) specification of ETSI’s Third Generation Partnership Program (3GPP) is an extension of the GPRS paradigm to support Wideband Code Division Multiple Access (WCDMA) radio interface, including a more advanced QoS model. The 3GPP QoS model provides support for service quality differentiation for generic real-time and interactive services, in addition to voice and data. This is accomplished by defining UMTS bearers for radio access and core network, which support not only the specification of priority and bandwidth type of parameters, but provide for a richer set of service quality support requirement specifications. PDP context is the unifying link for QoS across different bearers. In the terminal, a sufficient Application Program Interface (API) between applications and the operating system is assumed to exist to request service quality support. A simplified overview of protocol stacks of 3GPP architecture is shown in Figure 5.4. Note that radio access bearer and IP bearer provide service quality support for user layer traffic (end user IP flows) “from below”, whereas service quality interworking towards external Internet takes logically place on user layer.

5.4.1

QoS model

The interested reader can find a longer account of 3GPP QoS model in [KP01], only a short description being given here. Network architecture for UMTS is shown in Figure 5.4. As with GPRS, each user flow is mapped in to a PDP context. One of the properties of the PDP context is traffic class, being one of the following four types: Application User IP layer Radio tunnelling RAB Link Terminal

GTP Radio tunnelling ATM RAB Link Link Base transceiver station & radio network controller

GTP ATM Link

GTP IP Link

User IP layer User IP layer GTP IP Link Link

Serving GPRS support node

Figure 5.4 Release 99 UMTS architecture protocol stacks Note: The protocol architecture has been simplified

Gateway GPRS support node

5.4 3GPP QOS MODEL

147

1. Conversational class. This service class has been designed for interactive real-time communications such as voice or multimedia telephony, which has strict limits for end-to-end delay. 2. Streaming class. This service class is suitable for non-urgent real-time services that can tolerate longer delay than conversational class applications. 3. Interactive class is suitable for interactive data-type services such as browsing the Internet. Interactive class traffic is typically prioritized with respect to background class. 4. Background class. In addition to the traffic class, the QoS profile associated with a PDP context includes the parameters listed below in Table 5.2. Not all of them are applicable to all traffic classes. The QoS profile parameters of the PDP context are used in mapping to bearers. The Radio Bearer (RB) is used in the radio interface, and the bearer between mobile and SGSN is called upwards is called Radio Access Bearer (RAB). In the transport network, user layer traffic is transported by GPRS Tunnelling Protocol (GTP) tunnelling using either ATM or IP transport. The corresponding bearer is called core network (CN) bearer. Protocol stacks relating to different bearers are illustrated in Figure 5.4. While the protocol stacks in the radio access and transport networks seem a bit complicated, they provide the end user flows with the abstraction layer of bearer to implement the PDP context service quality requirements and hide mobility from communication endpoints. Table 5.2 QoS profile parameters in 3GPP framework Maximum bit rate Guaranteed bit rate Maximum service data unit SDU size SDU format information SDU error ratio Residual bit error ratio Delivery of erroneous SDU Delivery order Transfer delay Traffic handling priority Admission/retention Priority

148


The QoS requirements of the PDP context are signalled end-toend inside the mobile network and mapped to appropriate bearer parameters. The desired QoS properties are then implemented using appropriate bearer mechanisms in radio and mobile network domains. The full 3GPP QoS architecture involves multiple levels of bearers which are omitted here. For Interactive class, Traffic Handing Priority (THP) provides finer granularity, having three possible values. The significance of this parameter is as follows: as measured end-to-end, an interactive traffic class flow with THP1 receives, on average, lower end-to-end delay than interactive traffic class flow with THP2. A similar relation exists between THP2 and THP3. Traffic handling priorities can be thought of as roughly corresponding to delay classes in the GPRS QoS model.

5.4.2

Summary

The 3GPP architecture is designed to support telephony and packet-based services for wide-area cellular access. The architecture uses IP transport in packet core between mobility servers, and service quality interworking on the Internet can be implemented by SLA-type mapping from CN bearer to external mechanism at the edge of the mobile network. The 3GPP QoS model encompasses four traffic classes, providing quality support for basic service categories, including telephony, streaming, browsing, and background data transfer. An extension of basic 3GPP architecture is reviewed briefly above, Chapter 9 will use IP-based RAN as a case study to apply the conceptual framework developed in this book.

5.5

OTHER MODELS

The authors of [MNV02] consider a DiffServ-based architecture with the following service quality support classes: premium constant bit rate, premium variable bit rate, premium multimedia, premium mission critical, and best effort. The first two for the service quality support classes are meant for UDP, and the next two for TCP. The service quality support classes have been designed with interoperability of 3GPP traffic classes in mind,

5.6 UTILITY-BASED ALLOCATION OF RESOURCES

149

and the authors present an example mapping between the two service quality support models. According to the authors, the service model can be implemented with a combination of priority queueing (PQ) and WFQ, with tail-drop, RED and WRED as possible mechanisms for buffer management. Token bucket is used for peak rate policing in premium constant bit rate model, and in premium variable bit rate model, two token buckets are used for policing both sustainable and peak rate. For TCP traffic, policing is done with a single token bucket with “downgraded” DSCP marking for out-of-profile traffic. In ITU-T’s draft specification [Y.1221], three service quality support models called IP transfer capabilities are defined. • Dedicated bandwidth transfer capability (DBW) is suitable for services with stringent delay requirements. Parameters to be controlled are peak rate, token bucket size, and maximum allowed packet size. Out-of-profile packets may be discarded. • Statistical bandwidth transfer capability (SBW) is intended for applications with no stringent delay requirements. Control parameters are peak rate, peak rate bucket size, sustainable rate, sustainable rate bucket size, and maximum allowed packet size. Traffic above sustainable bit rate but within peak bucket traffic will be delivered. • Best Effort transfer capability (BE): no guarantees provided. In [Y.1221], congestion and overloading control are performed with packet discarding control as well as potentially using Explicit Congestion Notification (ECN).

5.6

UTILITY-BASED ALLOCATION OF RESOURCES

The previously reviewed schemes for provisioning of service quality support with network resources have stemmed mainly from a service quality requirement viewpoint, without directly taking into account the operator’s business objectives. Next, we shall discuss the concept of resource allocation performed based on utility, where such objectives can be expressed by interpreting utility as revenue. For the purposes of this topic, let us assume a network transport/service provider with a selection of supported services provided for customers, as well as SLAs for other operators. This

150


scenario is suitable for illustrating the benefit of utility-based allocation. The subject matter of this chapter, however, is also useful for pure network transport operators, especially when dynamic SLA mechanisms are used. Dynamic SLAs will be discussed further in Chapter 8. A generic formulation of utility-based allocation of resources is as follows: maximize utility of service resource allocation subject to service quality requirements and total amount of resources available in the network (see, for example, [PB01]). The variables to adjust are the set of supported service types, {Si }, and the allocated resources for each service type, {Ri }. An oft-used example for evaluating utilities of individual services is the utility curve, assumed to be available for each service type. The utility curve is often shown for bandwidth, whereby the curves for CBR VoIP and WWW browsing – for example – could look like the example in Figure 5.5. Utility for CBR VoIP deteriorates quickly below a critical bandwidth limit, whereas the utility for browsing in theory is a smoother function of the available bandwidth. From the curve, one can immediately see that it is no use to provide a bandwidth below the “step” threshold for a VoIP stream. The utility of a browsing session, on the other hand, behaves more smoothly as a function of the bandwidth. The utility for a particular service type of Figure 5.5 is a function of bandwidth, i.e.: U = U (b),

(5.1)

Utility

1 / Bandwidth

Figure 5.5 Utility curves for VoIP (dotted line) and WWW browsing (dashed line)

5.6 UTILITY-BASED ALLOCATION OF RESOURCES

151

where b is an estimator for bandwidth available to the service instance. A classical reference using utility functions of this type for managing bandwidth allocation for elastic traffic is [Kel97]. In this kind of scheme, the goal is to maximize the aggregate utility computed over all streams given that utility functions of users are known. From the discussion in Chapter 2, it is evident that available bandwidth is not sufficient for analyzing multi-service case but the utility in general should be a function of availability, delay, delay variation and packet loss, too, to mention but a few characteristics. A step in this direction, use of delay utility in controlling scheduling has been addressed in [SB02]. Taking into account the characteristics that can be evaluated per network element, an amended utility function for a service class could read: U = U (b, d , d , l ),

(5.2)

where d , d , and l denote estimators for delay, delay variation, and packet loss rate, respectively. Compared to using only bandwidth in utility computation, adding more variables makes the utility optimization much more complex. The utility of service types obviously needs to be evaluated in order to be maximized. The utility function of a service can then be defined in a contract between the customer and the network/service operator. Utility may be defined according to customer class, for example, differentiating business users and economy users for services. In such a case, the utility function for a particular service type could have the same generic form, but the utility function of a business user could be scaled with a factor larger than unity with respect to the utility function of the economy user, for example. Thus, the overall utility could be summarized in the form of a matrix, a generic imaginary example of which is shown in Table 5.3. Table 5.3 An example utility table for services. Each entry represents a utility function Service Multimedia conferencing Streamed multimedia Browsing Data transfer

Business

Economy

Mc1 Sm1 Br1 Dt1

Mc2 Sm2 Br2 Dt2

152


The network resource allocation problem can then be expressed mathematically as the following kind of optimization problem:   Utot ! = max  U (Ri , {qk }) (5.3) i ∈{Sj }

subject to:

Ri = C ,

(5.4)

i

where Utot represents revenue, Ri resources allocated for, qk the set of utility variables, {Si } the set of services (where the set can be variable in the general case), and C is the total amount of available resources.

5.6.1

Summary

Utility-based allocation of network resources aims at maximizing the utility of the network, based on defined per-service utility functions, which need to be known. In general, the utility function for a service type in a multi-service network can be a function of average available bandwidth, variation in available bandwidth, delay, delay variation, and packet loss. With utility functions, resource allocation is turned into an optimization problem, with the set of supported services and resources allocated to them as variables. This scheme requires that the utility of the services be known. Translation of the services into monetary – or some other type of – utility can be done, but users may have implicit “secondorder” utility functions related to continuity of services, and of available service selection. Thus, simple-minded application of utility-based resource allocation methods may be dangerous. In an environment based on SLAs, utility is a useful concept in assessing the value of different sets of SLA configurations, and thus can be viewed as an advanced “meta-level tool” in enhancing revenue from a network on a long term.

5.7

GENERIC RESOURCE ALLOCATION FRAMEWORK

Let us next collect the knowledge from previous resource allocation models in the form of a generic model to perform the resource

5.7 GENERIC RESOURCE ALLOCATION FRAMEWORK

153

allocation in a single multi-service IP network domain as a part of end-to-end service quality support chain. All told, this exercise includes signalling, mapping of traffic onto network resources, evaluating and configuring service quality performance inside a domain, and computing end-to-end service quality budgets. Useful concepts from previously reviewed service quality support architectures include the following: • Separation of service and transport layers. This is an enabling concept for access technology independent of service usage. In the long run, it can also be expected to be in the interests of the end user and service provider, as discussed in Chapter 1. • Interface for mapping of services to service quality support classes. This kind of interface is a must in non-over-dimensioned multiservice network. • End-to-end service quality model, translatable into per-domain allocations. Having an end-to-end model allows structuring of endto-end service performance. • Admission control to traffic aggregates. On the network service quality support side, aggregated treatment of service quality requests improves scalability. • Policing of traffic at network ingress. Policing makes service quality support in the network easier. Further, as seen earlier in this chapter, policing can be coupled with service quality support models. • Service quality support models for structuring service quality mapping. • Static or dynamic inter-domain SLAs. SLAs help to structure the responsibilities of operators and providers, as will be seen in the next chapter. • Utility-based evaluation of resource allocation. This is a promising concept. • Pricing of service quality support categories. This is a practical tool for controlling the number of service instances making use of each category. Next, a resource allocation framework is presented, based on a combination of these concepts.

154

5.7.1


Signalling

For per-flow, terminal-controlled service quality, a signalling scheme is needed for the transport network for requesting service quality support in the network. This signalling can be performed by a communication endpoint, by a service provider, or both. Two different schemes are possible here: 1. A full set of service quality support parameters is requested. 2. A small number of service quality support classes is used between the end user and the network With IP-based applications, the first option requires that the socket interface for the application supports request of the appropriate parameters. Obviously, it also requires that the application knows which parameter values to request and – if service quality renegotiation is implemented – which parameter values are acceptable. The link between application in the endpoint and the operating system can be implemented using an API with service quality descriptors, or with predefined service quality support classes as in the TIPHON model. Additionally, the TCP/IP implementation of the operating system of the end user IP host must support the service quality support signalling between the IP host and the network. The signalling scheme can be, for example, RSVP, SIP/SDP parameters for IP telephony, UMTS terrestrial RAN (UTRAN) signalling in 3rd generation mobile networks, or some future signalling protocol (see Figure 5.6). As mentioned in the previous Communication endpoint

Service signalling interface

Service operator

Application Network signalling interface

Application API

O/S

Network signalling interface

Transport operator

Figure 5.6 Possible signalling interfaces for requesting service quality support


155

chapter, also the use of COPS has been proposed for this interface. The choice of signalling protocol partially depends on whether the access network domain understands application-level signalling. A VoIP access domain may understand SDP parameters, but generic DiffServ domain not. The alternative of having only a small number of service quality support classes is conceptually simpler, as not all applications need to understand the full set of parameters. This approach requires that a small number classes are predefined for service support, and that mapping to service quality support parameters can be performed in the operating system, in service quality middleware, or by service provider or network transport operator. The TIPHON user voice quality class is an example of such predefined service support classes for telephony, and the traffic classes within the 3GPP QoS model for a multi-service case. It is not necessary that all the details of service quality support mechanism parameters are visible to the end user, but the exact meaning of the service class could be defined in an “end user SLA” between the network or service operator and the user, depending on the price paid by the customer. An example with two types of end user SLAs could be as follows: “Economy SLA”: • Voice over IP with low delay, delay variation, and packet loss rate, using predefined codec with associated pricing scheme and token bucket parameters. • All the rest is best effort data with flat rate up to a predefined cumulative traffic volume per month. “Super SLA”: • Voice over IP or video telephony with low delay, delay variation, and packet loss rate; different codecs possible with associated pricing scheme and token bucket parameters. • Streaming support with predefined pricing scheme and token bucket parameters. • Browsing support with flat rate up to a predefined cumulative traffic volume per month. Token bucket parameters are defined for browsing.

156


• All the rest is best effort data with flat rate up to a predefined volume of traffic per month. Token bucket parameters may be defined. In the case of predefined service quality classes, the interface between the application and the operating system must support the request of certain service support class. Alternatively, the application type can be detected by the operating system of the endpoint, or by the network edge. Automated detection of required service quality support either by suitable middleware in the terminal or the network is easier for the application, but requires advanced technical solutions to operate reliably. Differentiated pricing for individual services is possible in multiple scenarios. In the fully signalled service quality support scenario, more fine-grained charging is possible than in the SLAbased scheme, but the end user bill can also become complex and perhaps difficult to understand in such a case. Thus, also from the viewpoint of ease of understanding of end user charging, aggregation of service quality support into a small number of end user perceived entities is desirable. If instantiation of service quality support, that is, admission control to service quality support resources, is performed for individual service types in question, the interface between the application and the operating system, as well the interface between the communication endpoint and the network, will support the delivery of admission control decisions. If service quality renegotiation is supported, it sets further demands on the interface.

5.7.2

Mapping of services onto network resources

The network is assumed to know the service quality requirements for a new service instance, either as a result of per-application signalling, or of invoking a service class defined in the SLA between the user and the network or service operator. As discussed earlier, the mapping of service requests to the network can be done by the service operator (based on the SLA it has with the network operator), or by the network operator. The mapping can also be affected by end-to-end aspects such as SLAs for other network operators as will be discussed in Section 5.7.4.


157

Boundary conditions of the resource mapping include: • “utility” of the service instantiation policy within a single service; • service quality support requirements of service classes; • service quality support mechanisms available in the network side; • SLAs with end users; • SLAs with service providers; • SLAs with other network providers. As was described above, the utility functions of individual services can be used in assessing the goodness of the set of SLAs used in the network, when combined with the inherent requirements of services in a meaningful way. Application of pure utility-based resource allocation in service quality instantiation process could yield results very different from allocation based on inherent service quality requirements. For example, it could lead to some services getting unnecessarily good service quality in the network, whereas other services would be left lacking the support for very basic operation. We shall return to this topic in the next chapter. The most important service quality characteristics for mapping of services onto network support mechanisms are: • • • • •

delivery time; allowed variability in delivery time; throughput requirement; packet loss; reliability.

The network-level service quality support mechanisms have been discussed in Chapter 3. Next, we shall discuss the link between the service quality requirements and the mechanisms on a generic level. First, however, it should be noted that not all the mechanisms discussed below are applicable in all cases. For example, per-service routing control and service instantiation require special support mechanisms in an IP network domain. It should be noted that if service instantiation control is not available, PDU

158


forwarding and PDU loss prioritization may vary. In the list below, it is assumed that the network is highly utilized so that momentary periods of congestion can arise. • Delivery time affects the PDU forwarding prioritization of traffic, and may have effects on routing and service instantiation as well. The routing should be kept constant for service types for which delay needs to be minimized. • The allowed variability in delivery time may affect PDU forwarding prioritization, routing, and service instantiation. When multiple routes are used for a single service quality support aggregate, allowed variability in delivery time can also affect routing decisions within the aggregate. • Throughput requirement may affect forwarding and PDU loss prioritization, routing and service instantiation. It should be noted that also the constancy of throughput may be important for some service types, notably TCP. • Packet loss requirement affects PDU loss prioritization and may affect service instantiation. • Reliability requirement affects SDU loss prioritization and may affect service instantiation and forwarding prioritization as well. As can be seen in the above list, service instantiations appear in multiple locations. This is because in certain cases, especially with prioritized traffic aggregates, service instantiation control is one of the few control means available for traffic aggregates with strict service quality requirements. Another control means for prioritized traffic is the use of multiple routes for a single service quality support aggregate. This tool can be used when multiple routes are available, one possible route is under-utilized and service quality requirement allows for diversification of routing. In the network, services may need to be mapped on to aggregate service quality support schemes such as DiffServ Behavioural Aggregates. In this case, the end-to-end service quality is provided by the aggregated end-to-end support chain in the same way as the QoS profile of a PDP context in a 3GPP mobile network is provided by different bearers. A supplemented DiffServ-capable IP network service quality support configuration, in general, can have three tools at its disposal:


159

1. Determine admission control policy for different service quality support types. 2. Determine the routing of service instantiations. 3. Determine the service quality support inside network elements (e.g., routers). End-to-end delay requirements may affect the routing of a service type in the network, in addition to selection of the appropriate PHB for the service type. Routing, in turn, determines the amount of service instantiations going through an individual network element. The relative volumes of different service types affect the service quality support configuration of individual network elements. Routing and per-element service quality support configuration are not always available simultaneously. It may not be possible to affect routing, whereby only per-element control is available. In other words, the loading of the network may affect the routing of new service instantiations. Both the routing selection and per-element service quality support configurations depend on whether resources are reserved for services or service classes. In what follows, it is assumed that no hard resource reservations are made, although the maximum amount of a service can be limited per network element and the relative average capacities provided to different kinds of services can be controlled statistically. Thus, for example, the scenario roughly corresponds to DiffServ and MPLS, the latter with zerobandwidth LSP mode. The evaluation of a particular mapping of services to the resources listed above can be evaluated analytically or numerically. Both analytical and numerical methods require that the shares of individual service types can be estimated. These methods can be applied to obtain a detailed information of a performance of a multi-service networks, making it possible to achieve of high utilization levels of the network and engineered per-service quality simultaneously. Analytical methods based on queueing theory may be timeconsuming at worst, and require resorting to approximations, but can produce results of general applicability. Introduction to queueing theory can be found in [McD00, PS00]. End-to-end modelling may require that the transport layer and possibly also the application layer protocol stacks be modelled in case they have an effect on service quality. Typically the behaviour of different protocol

160


layers can be partially captured with mathematical models, but realistic modelling of user-experienced quality is challenging especially if it is affected by interactions between different protocol layers. The mathematical modelling of TCP in itself is a small industry in universities, the performance of TCP being affected by the variant of the congestion control algorithm used, for example. Queueing theory is nevertheless an excellent tool to be used for engineering the necessary IP service quality support resources in a domain, as a part of an end-to-end calculation. Numerical methods such as computer simulations typically need fewer simplifications and approximations, but the results are often representative of the simulated parameter combination configuration only. Further, if simulation is performed on packet level, the size of simulated systems is limited. An advantage of per-packet simulations is that one can run actual protocol stacks as part of the simulation, if necessary. Ns2 [ns2] is a widely used discrete event simulator for networking research. In general, the allocation of traffic types to network resources can be considered to be an iterative optimization process, where obtaining a satisfactory solution may require several iterations. Analytical methods may be applied to get the first configuration, and numerical simulations can be used to verify the result. This is especially true when building a new multi-service IP networks, where also the amount of network resources is a set of variables in the optimization. Next, we shall take a closer look at how the network quality support configuration can be performed with practical mechanisms for a DiffServ network domain.

5.7.3

Network quality support configuration for DiffServ

In this section, service quality support for DiffServ is studied in more depth. It is assumed that individual network elements support prioritization using DiffServ as well as advanced routing control (capability of defining routing for flows). Further, it is assumed that edge and core parameters can be adjusted – for example – with policy-based management so that a mapping of service types to quality support classes in the network as well as the quality support mechanism configuration can be flexibly adjusted.


161

Let us study an example with full network quality support mechanism repertoire in use. Let us further assume that supported service classes include VoIP, streaming, browsing, and data transfer. The resource mapping in an access network domain could proceed as follows, assuming that the operator already has an operational network. The configurations in steps 3 and below are assumed to result from the two first steps. 1. Take into account service support requirements from SLAs for other operators and service providers. Determine their mapping and effect on network resource use. 2. If direct SLAs for end users exist, use business utility/inherent service quality requirement-based means as well as end user SLA information to determine which instances within each service class need to be supported, and whether user class differentiation would bring value. Map VoIP into the highest forwarding priority class (EF). 3. Are network resources everywhere sufficient for VoIP transport in the highest class for the most direct route? If not, service instances mapped to the highest class can be redistributed among different paths with routing control means. Service quality support instantiation policy change can be used if topological redistribution of EF load is not possible. Note that this is reflected on availability. 4. Map streaming to a behavioural aggregate with statistical resource allocation (AF1). 5. Redo step 3 for streaming, considering resource allocation for VoIP as a given boundary condition. 6. Map browsing to a behavioural aggregate with statistical resource allocation (AF2). 7. Map data transfer to lowest non-best-effort forwarding class with statistical resource allocation (AF3). 8. If necessary, implement end-user class prioritization using AF drop precedences. 9. If direct SLAs for end users exist, determine selective admission control procedures for coping with congestion situations. In step 2 above, the utility can include service quality support specific parameters, as demonstrated in equation (5.2). The utility evaluation procedure can also be applied on longer timescales to

162


assess the optimality of the contents of SLAs for service providers and other network operators. The outcome of the above example procedure is that three types of service quality allocations exist in the network: 1. Strict resource allocations for VoIP. Service quality support resources are provided with high probability P1 . Service quality support is low delay, low jitter, and low packet loss. 2. Strict resource allocation for streaming. Parameters can be downgraded. 3. Statistical resource allocation for other traffic types. Service quality support resources provided on average availability basis, and make use of the network capacity remaining from VoIP and streaming. It is possible that the above process is not linear. For example, one may need to go back to phase 2 to redesign the set of supported services. At the edge of the network, policing of traffic is performed according to the SLAs for appropriate parties. There will be more discussion about this in Chapter 6. Inside the DiffServ network elements, the following resources can be configured per interface queue: • amount of buffer space; • limitation of maximum aggregate rate for prioritized aggregates; • buffer space maintenance algorithm; • scheduling algorithm and associated parameters. The amount of buffer space affects the magnitude of variations in end-to-end delivery time and PDU loss of services, and can also affect indirectly other service classes. The latter is true when the buffer for prioritized traffic is long, allowing for large variations in momentary traffic volume of the prioritized aggregate to be reflected in queueing delays of lower-priority aggregates. The maximum rate allowed for an aggregate can be used to prevent one traffic type from becoming too dominant at any point in time. This feature is useful with priority-based scheduling, and is mandatory for EF PHB.


163

Buffer space maintenance algorithms allow for SDU loss prioritization within a PSC in case of lack of resources for the corresponding BA. Well-known mechanisms of this type in IP routers are tail drop, head drop, Random Early Drop (RED) and Weighted Random Early Drop (WRED). The allocation of SDU dropping thresholds for different PHBs within a PSC should be done based on per-service PDU loss percentage requirements. This mechanism is integral part of the AF PHB group. Algorithmic dropping can be used for two purposes: 1. To control the behaviour of congestion control algorithms in TCP stacks of the endpoints in such a way that the throughputs of different PHBs within a PSC have desired properties. 2. As the practical mechanism used for disposing of the packets that need to be dropped, also for UDP-based flows. Scheduling means are prioritized scheduling of queues, and division of scheduling time between queues in weight-based scheduling mode. When the “two-bit architecture” [RFC2638] having both EF and AFx PSCs is implemented, the allocation of scheduling weights for AF classes needs to take into account also EF traffic variability and rate limiter settings.

5.7.4

End-to-end service quality budgets

Implementation of service quality for paths spanning multiple domains requires a way of breaking down the end-to-end requirements into per-domain allocations. This is our current topic. In the TIPHON model, QoS budget related signalling can take place between individual network domains. In such a scheme, the QoS budget for a particular flow can be negotiated between the domains. In the resource management framework developed in this chapter, a simpler solution is assumed. Resources are mapped to a service quality support aggregate based on the end-to-end service quality requirements of service types, but no service quality support-related negotiation is assumed to take place. At a minimum, a DiffServ domain can be expected to be aware of static SLAs with neighbouring domains. This being the case, with proper service quality instantiation control the domain is able to reject service quality support for service instances for which endto-end requirements cannot be fulfilled (see Figure 5.7). In this

164


Information used in service instantiation

AD1

"SLA pipe"

AD2

Figure 5.7 The role of SLAs in inter-domain resource quality management

approach, the end-to-end partitioning of service quality is not negotiated, but based on SLAs. Equally, the mapping between service quality support mechanisms in neighbouring domains is assumed to be based on SLAs. This static scheme can be complemented by dynamic SLAs using bandwidth brokers, as will be described in Chapter 8. The ETSI EP TIPHON approach to end-to-end service quality for IP telephony was described in Section 5.2. Taking delay as an example, part of the end-to-end delay quota in TIPHON model is assigned for the terminal, and the remaining part is divided among the transport domains. TIPHON’s deliverable [TIPHON-7] provides a planning guide for IP telephony. In the same kind of analysis for circuit-switched POTS, telephony can be performed using the ITU-T’s E-model [G.107], having a number of mouth-toear path parameters reflecting different aspects of network, terminal, and circumstances of telephony. Examples of application of the E-model in different planning scenarios are given in [G.108]. In what follows, the end-to-end service quality calculations are considered from the point of view of the “elementary” service quality requirements: delay, delay variation, packet loss rate, packet loss correlation, and throughput. As was discussed in Chapter 2, quality statistics for these characteristics of service instances fall into two classes, unstructured distributions and temporally correlated ones. This division is also valid when applied to traffic aggregates. The end-to-end analysis for the two types of characteristics is slightly different, as we shall see.

5.7.4.1 Delay Delay is one of the most important end-to-end characteristics when voice or multimedia conferencing is among the supported applications. Excessive end-to-end delays lower the efficiency


165

OVR=50

OVR=80 OVR=70 90

LSQ/R

80 70 60 50 40 0

100

200

300

400

500

600

Delay/ms

Figure 5.8 Relation of ETSI TIPHON’s QoS classes (dark grey = narrowband high; light grey = narrowband medium; lightest grey = narrowband acceptable; white = best effort/not recommended) to end-to-end delay and overall R-value (OVR). R-value on the Y-axis is the listener speech quality.  ETSI 2002. Further use, modification, redestribution is strictly prohibited. ETSI standards available from http://pda.etsi.org/pda/ and http://www.etsi.org/eds/ Source: From [TIPHON-7]

of TCP, too. Reflecting this fact, delay is listed as a separate QoS characteristic – in addition to the R-value given by the E model – in ETSI TIPHON’s end-to-end model. Figure 5.8 shows the relation between speech quality and end-to-end delay used by TIPHON for IP telephony. Various sources of delay were already discussed in Chapter 2. From the point of view of end-to-end analysis, the role of communication endpoints must be taken into account. A widely used PC operating system is known to give rise to large delay variations (70–150 ms), presumably because of process scheduling or the internal implementation of the TCP/IP stack. ETSI TIPHON handles the effect of communication endpoint with a classification of the terminals according to their effects on end-to-end service quality. Second, shared-segment type LANs or other network links of the same nature can give rise to delay variations which are drastic in timescales relevant to VoIP when loading levels are high [RR00].

166


The simplest way of allocating per-domain delays in QoS budget thinking is to use the sum of averages of the delay distributions, i.e. N d e2e = di (5.5) i =1

In this calculation, also the communication endpoint sources of delay need to be accounted for. Typically average values are not enough for SLA purposes, since variations of delay are non-negligible. Thus, the average delay must be complemented by other descriptors. Typically higher percentiles of the per-domain delay distributions, such as 90%, 95%, or 99% limits are used in SLAs for real-time traffic. Such high quantiles also cover mostly the variation of delay for a single domain. In such a case, estimates for end-to-end delays can be based on the quantiles. For example, if the delay corresponding to the 99% quantile in the i th domain is denoted by d99 (i ) and there are N domains in total, the following estimate can be established, given that the delay variations in the individual domains can be assumed to be non-correlated: d99 (i ) ≈ (1 − 0.99)N = 0.01N (5.6) P d≥ i

Using also other quantiles of the delay distribution, a hierarchy of delay limits can be established in the similar manner, starting from the same assumptions. A worst-case limiting case for completely correlated delay variations across network domains is given by d99 (i ) ≈ 1 − 0.99 = 0.01 (5.7) P d ≥ i

Thus, given the quantiles of the delay distribution, the probability of end-to-end delay being larger than the sum of per-domain d99 s is roughly within the range [P , P ]. As discussed below, the probability can often be expected to be closer to the lower limit of the range than the upper one, when multiple domains are involved and the flows involve large number of packets within short period of time. This is especially true for high percentiles of the delay distribution, which are often an example of extreme statistics, displaying large variations.


167

The most information-rich description of delay within a domain makes use of the actual forms of the delay distributions. For independent distributions, the sum of two distributions is given by a convolution of the two distributions: ∞ S (s) = D1 (d )D2 (s − d ) dx (5.8) 0

The convolution method can be extended to multiple domains. The delay distribution resulting from convolution analysis can be used to obtain end-to-end delay distribution quantiles, when the form of the delay distribution is well enough known. Constant form for the distribution is obtainable when the aggregation level of flows is sufficiently high. However, due to various factors discussed below, a single distribution does not typically provide the whole truth. A practical approach in such a situation is to use the worst-case distribution resulting from busy-hour traffic. Assuming that the variation inside individual distributions is bounded, the sum of N distributions converges to a Gaussian distribution according to the Central Limit Theorem (CLT). This convergence is illustrated below for a homogeneous distribution P (x ) = 1/10 for x ∈ [0, 10]. The independence assumption may be expected to hold on the timescales corresponding to temporal separation of two adjacent packets [Rai02b]. Obviously, this is not true if it is the traffic from one domain, which saturates the transport capacity of two or 0.03

0.12 0.1

0.025

0.08

0.02

0.06

0.015

Series1

0.04

Series1

0.01 0.005

0.02

0

0 1 2 3 4 5 6 7 8 9 10

1

0.016 0.014 0.012 0.01 0.008 0.006 0.004 0.002 0

4

7

10 13 16 19

Series1

1

5

9 13 17 21 25

Figure 5.9 The convolution effect for summing one (upper left), two (upper right) and three (lower left) even distributions

168


more domains. This is normally not the case, since the capacity of core network domains is typically higher than that of access network domains. Care must be taken in using the delay distribution so that not too much is read into it. The form of the delay distribution may depend on the overall loading level of the network, and – importantly – on the aggregation level of streams. The more percentual variation a single stream can cause in an aggregate, the less reliable the distribution in general is. Thus, delay distributions are typically more stable in the core network than in access domains. Furthermore, especially in access networks, longer-term variations such as loading variations at the scale of minutes and diurnal cycles may change the shape of the delay distribution. In such a case, different delay distributions may be used at different times of day for covering all the different loading situations. For practical purposes, however, the worst-case distribution is often enough. Multiple loading distributions can be used to control long-haul connection routing that is dependent on the time of day. Such schemes make it possible to utilize very large area networks efficiently, and have been used by telecommunications providers in the past.

5.7.4.2 Delay variation Delay variation is important for periodic real-time streams such as voice-over IP or streamed multimedia. For dimensioning purposes, average delay variation as well as variance are useful, whereby the above equations (5.1) and (5.2) can be applied to delay variation, too. Using delay distributions only is not enough for all purposes, as these do not include information about temporal correlations of delays on packet timescales. The most complete information is given by the time series of delays, providing the delay for each individual PDU. From such a time series, one can compute correlations between delays at arbitrary packet separations. A condensed representation of this is the probability distribution of delay variations. Such a distribution only provides information about correlations of PDU delays at distances of one packet (adjacent packets). For streamed or interactive multimedia content, the high percentiles of delay variation distribution are of importance because of dejittering buffer dimensioning. The actual functional


169

Maximum loss comparison static - dynamic jitter buffer

Maximum loss (%)

6.0% 5.0% 4.0% Dynamic JB delay (ms) Static JB delay (ms)

3.0% 2.0% 1.0% 0.0% 0

10

20

30

40

50

Jitter buffer size (ms)

Figure 5.10 The effect of dejittering buffer adjustment algorithm on packet loss percentage  ETSI 2002. Further use, modification, redestribution is strictly prohibited. ETSI standards available from http://pda.etsi.org/pda/ and http://www.etsi.org/eds/ Source: From [TIPHON-6]

dependence between delay variation and packet loss depends on the dejittering buffer algorithm used. Some of the most well known ones can be found in [RKT + 94]. Results on the efficiency of dejittering buffer adjustment algorithms can be found in [TIPHON-6], an example of the results being shown in Figure 5.10. Optimally, dejitter buffer control algorithm can be selected according to codec-specific properties such as tolerance of packet loss. For optimizing the network service quality support configuration for streaming and VoIP, the delay variation distribution and application of equation (5.3) are useful if the full delay time series cannot be used. Having information on longer timescales than one packet separation is possible, since typically dejittering buffer length and playback time for VoIP can only be adjusted during talkspurts. The length of a talkspurt in VoIP depends on the voice activation scheme, background noise and other factors, but is typically exponentially distributed with an average close to one second. With a 20-ms frame size of AMR and assuming one audio frame per RTP packet, one talkspurt would thus typically correspond to a train of 50 packets (see Figure 5.11). A simple estimator for delay variability, end-to-end delay variance can be obtained with the normal statistical means, allowing also for covariance between domains: 2 σe2e =

N i =1

σi2 + 2

N −1 i =1

σi2,j −1

(5.9)

170


Delay

"Packet loss domain"

Jitter buffer can handle this.

Sequence number

Figure 5.11 The relation between delay and packet loss in a dejittering buffer

Link load of delay-sensitive flows [%]

100 (1-1E-3) quantile of queuing delay (all links STM-1) 10 ms 7 ms 5 ms 4 ms 3 ms

90 80 70 60

2 ms 50

1.5 ms

40 1 ms

30 20 10

0

5

10

15

20

25

30

Number of hops

Figure 5.12 99.9% delay variation quantile as a function of link load level and the number of hops Source: From [Y.1541]

Variance is of limited value for per-packet jitter calculations for the same reasons as the delay distribution. Also, for the VoIP, covariance can be expected to be small at short timescales. Figure 5.12 shows an example of estimating the effect of delay variation over multiple links. It should be noted that for a realworld analysis encompassing multiple domains, the set of service quality support aggregates and their relative volumes may differ from domain to domain and also from router to router within


171

a domain. Subsequently, the delay variation distribution is location dependent. Delay time series provides the most complete information about delay variations, and all statistical characteristics relating to delay and delay variation, and pertaining to the characteristics that the measurement addresses [RGM02], can be derived from it. Delay time series are easiest to measure end-to-end, since aligning perdomain time series is difficult. Delay time series can be used to evaluate performance of dejittering buffers and TCP algorithms. Delay time series can also be used as a source of data for other purposes, such as assessing correlation timescales in network behaviour [Rai02b]. A “zeroth-degree approximation” of the effect of delay variations on the functioning of a dejittering buffer can be done by studying the relation between different delay budget limits and packet loss patterns resulting from exceeding those levels [LRR01].

5.7.4.3 Packet loss rate Packet loss rate, considered end-to-end, is different from delay in two respects. In contrast to delay, packet loss rate is not a defined on per-packet level, but is associated with an inherent “correlation length” for averaging. A more elaborate point is that the effect of overlapping packet losses in different domains along the end-toend path does not increase the overall loss rate. On end-to-end analysis of packet loss, to appear in Computer Communications. Persistent packet losses may result from a variety of reasons, including mismatch between duplexity configurations of Ethernet equipment in a segment. Bursty packet loss may be caused by variable loading in shared segment type LANs [LRR01]. UDP packets can be discarded due to bit errors in link layers with high Bit Error Rate (BER) and no link layer reliability mechanisms implemented. In backbone transport, packets can be lost in routers due to congestion in IP routers, or due to cell loss in IP over ATM solutions. Effective packet loss can also arise in a communication endpoint. For example, an RTP subsystem in the terminal may reject an audio sample that arrived too late. When losses in different domains are non-correlated, the rule for summing up the packet loss rates is 1 − ptot = (1 − pi ) (5.10) i

172


70000

6000

60000

5000

50000

4000

40000

Series 1 Series 2

30000 20000

3000

Series 1 Series 2

2000 1000

10000

0

0 1

2

3

4

1

400 350 300 250 200 150 100 50 0

2

3

4

Series 1 Series 2

1

2

3

4

Figure 5.13 Note: Summing of loss correlation for independent losses case. Different charts depict the numbers of consecutive losses; upper left – single packet lost, upper right – two consecutive packets lost, lower left – three consecutive packets lost. ‘‘Series 1’’ is for loss probability 0.01 and ‘‘Series 2’’ for loss probability of 0.02. The numbers in the horizontal axis refer to the number of domains used in the analysis

where ptot is the total packet loss rate and {pi } are individual packet loss rates in the domains. For small values of ps, the linear approximation of rtot ∼ pi is close to the above formula. For applications using dejitter buffering, delay and packet loss rate are often correlated in a certain range of values – packet loss rate can be decreased at the cost of increasing end-to-end delay. Figure 5.13 shows an example of the relation. As with delay, packet loss behaviour may be a function of the time of day.

5.7.4.4 Packet loss correlation Computing packet loss correlation over multiple domains is a bit more complicated. Assuming homogeneous loss probability in a single domain, the probability of exactly N consecutive packets lost is (5.11) P (N ) = p N (1 − p)2 where p is the probability of packet loss in that domain.


173

When the packet losses are non-correlated both temporally (within each domain) and spatially (across domains), the probability of exactly N packets being lost when M domains are traversed is P (N ) = 1 −

M

N (1 − pi )

i =1

M

(1 − pi )2

(5.12)

i =1

where now {pi } are the loss probabilities in each of the M domains. The result follows directly from the assumption of independence and equation (5.3). For correlated packet loss, discussion of packet loss correlation analysis can be found in [Rai02]. Consecutive packet losses in the multi-domain case can result from packet loss in one domain only on the end-to-end path, or of concatenation or overlapping of shorter packet loss events. Figure 5.12 a illustrates packet loss for simulated packet loss correlation probabilities in a run of one million packets over one, two, three or four packet loss domains, each with identical, noncorrelated and uniform packet loss rate r taking place randomly. The most complete description of packet loss for a particular flow is a bit string indicating which packets were received and which ones were lost. Such a characteristic can be obtained with a measurement. Short of that, loss patterns formed by different combinations of (length of packet loss sequence, length of the train of arrived packets) can be used to assess the effect of packet losses to periodic streams [RL02, Rai02]. The general guidelines for defining when packets are lost need to be observed. In the target situation for end-to-end multi-service support across multiple domains, traffic variations in the backbone transit domains are percentually small compared to link capacities. Thus, packet loss can be expected to arise mostly in access domains.

5.7.4.5 Throughput Throughput, measured end-to-end, is the instantaneous minimum of per-domain throughputs, i.e. te2e = min ti i

where i is the index of the domains.

(5.13)

174


Throughput, in general, is a characteristic separate from delay and packet loss. This is partly due to endpoint functions, and partly to possibly varying packet size. Depending on the supported applications, throughput distribution may be of interest, in addition to average throughput. For more accurate analysis involving assessment of TCP efficiency, time series of throughput can be used as a complementary tool. Such an analysis can be used in troubleshooting purposes. Again, throughput test needs to be designed carefully.

5.7.5

Optimization of resource allocation

Optimization of network resource allocation can use the same methods and principles as the service mapping. Optimization can be performed using changes to the existing configuration that is based on installed network infrastructure, existing service or service support provision, and contracts or SLAs towards other network operators, service providers, and end users. The optimization has two goals: • making best use of existing network capacity for implementing the existing SLAs; • identifying need for modifying existing SLAs. Thus, it could be rightly said that finding out the limitations of the applicability of the methods used is part of the optimization procedures. Network infrastructure for a multi-service network needs to be built on forecast user base development, traffic volume predictions and anticipated service palette. Once built, network infrastructure constrains the set of services and the ways in which they can be combined. The total capacity of network links is obviously a major limitation, but the efficiency of sharing existing bandwidth can be better used using prioritization-based schemes such as DiffServ, service mix allowing (see Chapter 3). The existing service repertoire may limit the operations affecting the relative shares of services. It is clearly not a good idea to kill profitable businesses, but on top of that, certain services may be of strategical importance. Contracts with customers are a major


175

issue; attempting to drastically redefine the quality standards for central services is potentially perilous. Contracts with other operators often are made for longer timescales. The contracts typically apply to traffic aggregates, whereby they restrict changes made to treatment of aggregates. Let us next take a look at means of affecting an existing service quality support aggregate traffic distribution. Some of the most important means are selective service quality support instantiation, selective throughput differentiation, selective importance differentiation, and selective forwarding differentiation. • Selective service quality support instantiation can mean that customers with higher operator-perceived utility get priority treatment for service quality support invocation in congestion situations. Alternatively, services with higher utility can be prioritized over ones with low priority. In both cases, services for which the requested service quality level is rejected can possibly be invoked at a lower service quality support level. Application of this method requires a signalling method to perform differentiated service quality support instantiation. • Selective throughput differentiation means that throughput can be limited in situations of impending resource scarcity. DiffServ supports this for AF classes, and optimization can then make use of the drop precedence level configuration in individual DiffServ routers. For EF aggregates, the settings of rate limiters can be used to control the maximum amount of EF aggregate in individual routers. The change in policy of the allowed volume of prioritized aggregates should be done mostly on the network edge, or as a part of the service quality support instantiation process. Adjustment of scheduling weights of WFQ-type queues in individual routers can be used to affect the amount of statistical resources available for AF-type PSCs. In addition to this, the traffic conditioning treatment of flows may be changed at the edge of the network, for example, changing the treatment of out-of-profile packets. • Selective importance differentiation can be applied to affect the relative importance of services within an AF class. A service may be demoted to higher drop precedence level, or promoted to lower drop precedence level. Thus, the mapping of service types onto DiffServ aggregates is a tool that can be used in the optimization.

176


• Similarly, selective forwarding treatment differentiation for service classes can be changed as a result of the optimization process. Changing of forwarding differentiation cannot always be used due to inherent requirements of services. It should be noted that the two last utility control means are not always independent of each other. Depending on the scheduling in the routers, changing the forwarding priority may also affect queue lengths and thus indirectly also packet discarding behaviour. A means of solving this, the dropping decision can be performed based on lengths of multiple queues [KR98].

5.8

SUMMARY

There are multiple timescales relating to use of network resources. A network needs to be designed based on anticipated usage, and the investment in the infrastructure is made on a timescale of years. SLAs and agreements with other network operators and service providers are a way of utilizing the investment on a long-term basis. Direct “SLAs” for end users is another form of structuring the use of the investment in network capacity. Initial resource allocation attempts to maximize the utility of network, given the set of supported services. For the network operator, the set of service support aggregates is a variable in this optimization, in addition to mapping of services onto aggregates. Resource optimization can be used to fine-tune the resource allocation, as a part of the traffic engineering process. The means of mapping services onto network resources is important for cost-efficient operation of a multi-service IP network. ETSI EP TIPHON, Internet2/QBone, and ETSI 3GPP service quality support models were reviewed, as well as the concept of utilitybased allocation of resources. TIPHON’s service quality framework allows for separation of service and transport layers, and has an end-to-end QoS model for mapping applications onto per-domain allocations. The QBone architecture addresses transport layer service quality support only, and does not include service mapping. Dynamic inter-domain SLA signalling is part of the QBone concept.

5.8 SUMMARY

177

3GPP has advanced QoS models, as well as the concept of mapping of QoS model parameters onto bearers in radio network and the backbone. Utility-based allocation makes it possible to optimize the revenue from network investment, given that the per-service utility functions are known. Per-service utilities may not be enough to assess human factors relating to the continuity of services and the expectations of supported service selection, but the utility-based allocation of resources can be utilized when comparing SLA alternatives. The properties of communication endpoints such as terminals and servers need to be taken into account in making end-to-end service quality analyses. The end-to-end service quality, in general, is affected by the application software, the operating system, and the hardware of the endpoints. Separation of the service layer from the transport layer makes possible obtaining end user benefits from more effective competition between different parties involved. Practical implementation of such division requires Service Level Agreements between the two layers and for end systems. The Application Programming Interface (API) for service quality requirement specification at hosts is beneficially based on the simplification of service quality support parameter space into a small number of relevant alternatives, for example: • • • •

delay-critical services (VoIP); real-time services; interactive services; bulk data transfer services.

The existence of such classification makes the API and interface between end system and the access network simpler, and also clarifies the charging for multi-service quality support. This kind of multi-service support will be put into practice when 3G networks will be put into use. An example of mapping a small number of service quality support classes to IP QoS is IP-based Radio Access Network (RAN), which will be discussed in Chapter 9. Making use of end-to-end service quality support calculations can be based on SLAs and traffic aggregates, avoiding the need

178


for per-service instance end-to-end service quality support related signalling. Issues relevant to making such analyses for delay, delay variation, packet loss rate, packet loss correlation, and throughput were discussed. Worst-case analyses based on busy hour traffic can be used for basic analysis. Multiple traffic profiles based on time-of-day loading situations allow network resource utilization policies to be made dependent on the time of day. In general, the high-capacity transit domains can be expected to have relatively stable traffic distributions. Thus, the role of access network domains becomes important. Especially relevant for the end-to-end analyses is conditioning at network edge.

6 Service Level Management Techniques Service Level Management (SLM) techniques are applicable to a network transport operator – in the parlance of the previous chapter – providing service assurances either to another network transport operator, for a service provider, or an end user. Service level techniques pertain to aggregates of services, and are contractual in nature. The processes and terminology related to this subject are dealt with in this chapter. As in the previous chapters of this book, the terminology and concepts from telecommunications world are when they can be generalized to the multi-service Internet. In this chapter, the context of service level management is discussed first, followed by a description of service planning and creation process.

6.1

MODELS FOR SERVICE LEVEL MANAGEMENT

A network domain, in general, can include both transport network elements such as routers and service-related ones, streaming servers being examples of the latter. Both types can be present not only when a transport network operator is also providing services such as streaming, but also because a service provider may Implementing Service Quality in IP Networks Vilho Räisänen  2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X

180

SERVICE LEVEL MANAGEMENT TECHNIQUES

Service layer Mgmt plane Transport layer

Figure 6.1 Conceptual relation of management plane to service and transport layers

have some kind of managed network of its own. The management system of a domain, conceptually, manages both transport and service-related resources in such a case. For this reason, the management plane is often drawn as shown in Figure 6.1. In reality, the service and transport layer management is not always very integrated. Taking a service provider as an example, the management system for services may be advanced, but the transport level management may be based on tools provided by the router vendor. By default, there is no link between the two management sub-systems, apart from the human operator. In what follows, we shall concentrate on service level management, which leads to a general view on management hierarchy, as we shall see.

6.1.1

Areas of service level management

An account of relation of service level management to general network management can be found in [Kos01], for example. The ITU-originated Telecommunications Management Network (TMN) framework cited therein consists of five functional areas, namely fault management, configuration management, accounting management, performance management, and security management. Fault management, as the name indicates, is concerned with the tasks related to error conditions in the network, including identification, correction, and reporting of faults. Configuration management includes provisioning of services in servers and network elements, including configuration of the transport network elements in the case of an IP-based multi-service network. The “downward branch” of the IETF traffic engineering loop discussed in Chapter 4 is part of configuration management.

6.1 MODELS FOR SERVICE LEVEL MANAGEMENT

181

Accounting management relates to the collection of data of network and service usage, providing input for charging. As such, it is mostly related to the management of services, but must be related to configuration of the transport network resources, too. Performance management encompasses obtaining of data relating to the performance of network elements and services. For practical purposes, this is the “upward branch” of the IETF traffic engineering loop. Performance management issues will be discussed in more detail in Chapter 7. Security management addresses the mechanisms of providing security, as well as detection of security breaches. This issue is not within the scope of the present book, and is best left to dedicated studies on the subject.

6.1.2

Layers of service level management

Management within each of the five areas listed above, in turn, is conceptually separated into four layers. In the order of increasing degree of abstraction, these are: 1. Element management layer. 2. Network management layer. 3. Service management layer. 4. Business management layer. The layers are illustrated in Figure 6.2. The element management layer is the interface between the management system and individual network elements. The element management layer typically has an element-proprietary interface towards the individual network elements, and an abstracted interface towards the management system. The element management layer not only provides abstraction of the configurations of individual elements, but also provides information about the capabilities of the network elements. A higher level of abstraction, the network management layer provides the user of a network management system with an overview on the network level of the services and network elements. Such an overview provides a summary of the status of multiple network elements, for example, for a routing domain

182


Business management

Service management

Network mgmt

Element mgmt

Network element

Element mgmt

Network element

Element mgmt

Network element

Figure 6.2 Layers of management in the TMN model

or an entire AD. The overview of the network status must provide two kinds of information: (a) information about the operational status of individual network elements within the scope of the overview. Such information can be used for spotting individual network elements not performing according to the specification. (b) Computation of performance indicators spanning multiple elements. Such indicators can be used for identifying performance problems due to sub-optimal configuration of multiple network elements. Thresholding based on the definition of triggering conditions can be used to define multiple levels of abstraction in the network. Thus, for example, upon notification of a fault on AD level, the routing area granularity view can be invoked to look for the cause or causes of the malfunction. If multiple elements are simultaneously in need of attention, the overview summary can be used to decide the order of handling the fault conditions. The service management layer handles the technical part of the contracts towards customers and peer operators by managing the network management layer. The precise functions depend on the type of the service in question, being rather different for content downloading services and conferencing, for example. Usually the service management system has to provide possibilities for creating,

6.1 MODELS FOR SERVICE LEVEL MANAGEMENT

Service layer

183

Business service Mgmt plane

Transport layer

Network element

Figure 6.3 Combined framework

modifying the composure of, and deleting services. Services that are not provided for free have a charging policy associated with them, and service invocation rights need to be managed. When services require resources from neighbouring domains, the management of the technical content of SLAs for neighbours is one of its tasks. The business management layer is responsible for the business aspects of the agreements towards different parties involved. As will be discussed below, business information is part of the SLAs in general. This topic will be mostly outside of the scope of this book. From this classification, it can be seen that service management is a device for implementing business objectives using network level tools. Comparing this hierarchy to that of Figure 6.1, it can be observed that this classification addresses the management plane only and the four layers of the above list are interfaces of the management plane towards the network and management layers (see Figure 6.3).

6.1.3

Models for managed data

The TMN model reviewed above is concerned with the management processes on different abstraction levels. A more data-oriented view, the Service Level Agreement (SLA) working group of Distributed Management Task Force (DMTF) defines an object-oriented information model called the Common Information Model (CIM) consisting of the following layers [CIM99] Common Information Model (CIM) Specification, version 2.2, DMTF, June 1999. • Core models span applications, networks, devices, and users.

184


• Common models span the technologies within a particular management domain. • Extension models are technology-specific extensions to the common models. From this viewpoint, service level management makes use of the core and common models, being dependent on both service requirements and operator processes. More discussion about CIM and its relation to other standards efforts can be found in [Kos01] and [SMJ00], for instance. Finally, service performance is also part of an IETF Application Management Information Base (MIB), specified in [RFC2564]. This RFC is mostly concerned with the application level performance measurement methods.

6.2

SERVICE PLANNING AND CREATION PROCESS

To achieve accountability in service provision for the customer, service level quality needs to be defined in a contract, usually called a Service Level Agreement (SLA). Due to its bilateral contractual nature, the contents of a SLA are defined by the parties of the agreement, for example, the service provider and the transport operator, or the service provider and the end user. To understand what usually goes into a SLA and why, let us first take a look at the interests of a customer before proceeding to service definition processes.

6.2.1

Interests of the customer

It is in the interests of SLA parties to be able to define received service quality as accurately as possible. This is in principle true for inter-operator, operator/service provider, and operator/end user contracts. Naturally, long-term contracts involving large traffic aggregates tend to be more elaborate. The most important reasons for defining service quality precisely in an agreement are: • Common understanding of what constitutes an acceptable service quality support. When the transport operator understands the quality requirements of services end-to-end, future development of

6.2 SERVICE PLANNING AND CREATION PROCESS

• • •

•

185

network transport resources can take service aspects better into account. On the other hand, the service providers and customers benefit from understanding of the issues related to transport. Transparency of charging. The customer typically wants to pay for clearly defined service performance. Accountability. The means of assessing performance need to be agreed upon. Definition of customers’ and operator’s liabilities in case of sub-optimal service performance. This is often important when service forms a part of the customers’ own business processes. Exceptional situations have a cost associated with them, and the responsibility for financial consequences needs to be known in advance. Security. It is important to agree in advance which information need to be divulged to sustain normal operation of the service. Also, reporting of security breaches is increasingly important [Sch00].

These main goals can be mapped to more fine-grained needs related to reporting of exceptional conditions, for example. The SLA contents are discussed in more detail in Section 6.3 below. It is useful to list next a few typical characteristics a customer of a multi-service transport network is interested in. The second and the third items in the list have been dealt with in the service quality requirement section already, and the building blocks for addressing the fourth one have been provided there. • • • •

Service implementation time. Service availability. Service continuity. Service-specific quality parameters.

Service implementation time relates to the competitive edge of customers of a transport network operator. In the case of creating “hot” and “new” ad hoc services by a service provider, or coping with the need to implement quickly a modification into the composition of a service, timeliness can be important. Service availability and continuity relate to the quality of the service provided, as seen on an aggregate level. Service specific quality parameters, on the other hand, relate to the requirements of individual service instances, as discussed in Chapter 2.

186


Means of estimating these characteristics need to be defined. Some commonly used estimators are: • Mean Time Before Failure (MTBF). The average time between failures. • Mean Time to Provide Service (MTPS). The average time from finalizing agreement between the service operator and the customer to having the service in operational use. This can be considered to be a formalization of the service implementation time mentioned above. • Mean Time to Restore Service (MTRS). Average time from reporting a fault to service being restored. Failure is used in the above list generically to indicate a state of insufficient service quality support in the network. To define the abnormal conditions more precisely, the TeleManagement Forum (TMForum) defines different levels of deviations from the normal operation of the service support in the network [SMH01]. In what follows, the terms have been interpreted from a service quality support viewpoint. The following definitions assume that the desired service quality support has already been defined. • Anomaly is a discrepancy between the desired and actual performance. • Defect is a limited interruption in the capability of network element or network to perform required function. • Impairment is a condition giving rise to anomalies and defects without causing a failure. • Failure is the termination of the ability of a network element or network to provide the required function. • Fault is the inability of a network or network element to provide service quality support, excluding maintenance reasons, external causes, or planned actions. Fault is often the result of a failure, but may also exist without a failure. It is important to note the role of service definition in fault management according to these definitions. Unless sub-optimal performance can be clearly defined, fault correction procedure defined within SLA cannot be applied according to the terms of the agreement.


187

Note that in applying the above definitions to a multi-service network, the required function means support for all service quality aggregate types.

6.2.2

Network operator viewpoint

The set of service quality support mechanisms at the network operator’s disposal may vary. A particular level of service quality support for the customer can be provided with different combinations of the network-side service quality support mechanisms discussed in Chapter 3. The service performance obtained with the tools needed by service level management are identical in each case, although the actual tools on the network level may be different from each other. The mechanisms a network operator uses for configuring the service quality support typically vary with network technology. The same is typically true for measurement results based on element-level information and quality characteristics obtained from combining these. The operator must be able to provide a means of service level quality monitoring irrespective of the QoS technology used. The technologies that can be used for this purpose will be discussed at length in the next chapter. A special form of measurement is the definition of triggers for exceptional conditions that the network operator is notified of. Sub-optimal operation of the network or network elements can be communicated to the network management system in various ways. • A notification is an indication that a predefined condition has transpired in the network. Obtaining notifications requires a way of defining the conditions, a mechanism for detecting that the condition has occurred, and means of communicating the condition. Preferably also a means of detecting the malfunctioning of the notification mechanism should exist. • An alarm is an indication of a condition that has negative impact on the service quality support level. An alarm can be related to a network element, a part of the network, or service level, for example. From the above definition it is clear that an alarm is

188


a special form of a notification, and thus has basically the same kinds of requirements associated with it. The notifications and alarms in the transport network element management system that are visible to the transport operator may not have one-to-one correspondence with failures and faults defined in SLAs for service providers or end users. A simple reason for this is that the same traffic aggregate in the transport operator’s network may be shared by multiple internal or external parties, each potentially associated with their own dedicated SLA definitions. In such a case, a mapping function between the notification conditions in the network and possible external communication defined in individual SLAs may be needed. Such a mapping may involve correlating multiple networkdefined conditions. From the business perspective, a service level agreement defines that the service provider will sell a certain item (service quality support) at a defined price. In this sense, the SLA is no different from any other business contract from a network operator point of view – risks have to be evaluated and a price tag assigned to them. If the network operator provides services itself, a SLA may still be used for accounting and service quality supervision purposes. In this case, the business risk associated with an operator-internal SLA may be of different type than for an external SLA, a difference which is typically reflected in the contents of the respective SLA types when it exists.

6.2.3

Service definition

In order to define service quality support needed, the customer of a network provider must first define the services themselves. The customer responsible for service definition is service provider. The different ways of carrying out this task are mostly beyond the scope of this book, but an “archetypical service engineering process” is outlined for the purposes of understanding the impact on SLA definition. The service creation process starts by defining the need that the service addresses. Next, the composition of the solution to the perceived need is defined in the form of the service. Multiple


189

variants of the service may be planned, for example a “business” variant and an “economy” one. Having defined the service on aggregate level, one can next proceed to defining what constitutes an individual service instance. If different variants such as the business and economy variants exist, different types of service instances are analysed this way. Next, the service instance is broken down into service events. From the definition of service events, one can derive the service quality support needed, using the analysis principles outlined in Chapter 2. Once the technical part is completed, a marketing strategy can be drafted, yielding the expected service deployment forecast. At this stage, the traffic volumes and service quality needs are known and the starting point for SLA negotiation has been reached. The composition of the final SLA may be affected by the SLA terms provided by the network operator. The process is illustrated in Figure 6.4. As noted in [SMJ00], the contents of the SLA need not be fixed even when a SLA is finalized, but its contents can be iteratively enhanced. The Telecommunications Management Network terminology for the operator-guaranteed Quality of Service level is “Grade of Service” (GoS). In [SMH01], GoS is contrasted with delivered or measured service quality level as being an engineered service quality level. This is akin to the ITU-T differentiation between planned Definition of need for service Definition of service composition Definition of service events Definition of service quality need Marketing strategy definition

Repeat until result acceptable or process abandoned

Service deployment forecast SLA negotiation

Figure 6.4 A simplified illustration of the service definition process. The iteration based on feedback from SLA negotiation also leads back to a phase below service composition definition

190


and offered QoS [G.1000] discussed in Chapter 2. If multiple variants of a service are provided, they may have different GoS characteristics associated with them. The time-to-market factor in service creation is increasingly important, which is reflected both in the SLA creation process and the contents of the actual SLAs.

6.2.4

Reporting

Reporting means the definition of an agreed-upon process of conveying information to the customer by the other party of the agreement, network operator or a service provider. Reporting is used to convey information relevant to service performance, and is usually part of SLAs for service providers, peer transport operators, and at least selected end users such as institutions and corporate customers. The customer may have their own means of assessing service performance, against which operator reporting can be compared. According to [SMH01], the definition reporting includes the following parts: • • • •

scheduling of customer reports; receiving of performance data; compiling of customer reports; delivering of customer reports.

The scheduling and contents of customer reports are defined in an agreement between the service/network provider and the customer. The measured characteristics in the scheduled report can relate to service quality performance, service availability, or to operation of the network in general. For a multi-service network, the measured characteristics may be different for each quality support aggregate. It is also possible for the customer to request a measurement of not only the service quality aggregate, but also the entire per-domain treatment, including edge functions. In addition to what is measured, also the measurement methodology as well as the frequency of measurements is specified in the agreement on reporting. Different kinds of reports may be compiled based on the targeted readership as well as for purposes of covering different reporting periods. For example, there may be separate customer

6.3 SERVICE LEVEL AGREEMENTS

191

reports for executive level, tailored reports addressing specific needs of different business units, and technical reports for the engineers. The content and detail of the reports typically depend on the reporting period. A weekly report probably has by default more content than a daily report, and a monthly report has wider coverage than a weekly report. The precise composition of each report type depends on the type of services covered by the SLA between the parties of the agreement. Ad hoc reports outside of the agreed reporting process can be compiled in exceptional situations, either specified in advance or according to the need. The reasons for sending ad hoc reports may be related to defects and failures. For the latter, the customer is typically interested in seeing MTTR-type metrics, in addition to MTBF-type ones. Security breaches are special situations that a customer wants and needs to be aware of.

6.3

SERVICE LEVEL AGREEMENTS

Let us next study the typical contents of Service Level Agreements (SLAs). SLA is a tool for documenting precisely the level of service between the customer and a service provider [SMH01]. To quote an example, SLA prevents the customer from requiring ever better service levels [SMJ00]. From another viewpoint, the technical contents of a SLA provide a device for well-defined and structured communications between the service provider and the customer, as well as internally by the service provider and the customer. From the business viewpoint, SLA is a contract between the customer and the provider, defining the terms of reference and responsibilities of the different parties. The degree of detail in the SLA typically depends on the business scope of the services covered. What is described below is a general framework, not all of which necessarily is covered in SLAs for small end users. The benefits of using SLAs have been discussed in [SMH01] and [SMJ00], for example, from the viewpoints of customers, operators, and equipment vendors. The following lists are loosely based on the sources, and complemented with respect to multi-service support where appropriate.

192


• Customer benefits – definition of service support models; – definition of parameters; – definition of measurements; – definition of reporting; – definition of exception handling; – providing of high-level, technology independent definitions for service performance. These factors have already been mostly covered in Section 6.2.1 in the context of the general interests of the customer. The technology-independent definition of service performance is important in comparing the offerings of multiple service providers or network operators. • Operator/service provider benefits – provides better internal definition of service quality support, measurements and reporting; – provides for terminology for service quality specification in customer/operator interface; – provides tools for defining service quality across technology boundaries. Briefly put, the network or service operator benefits consist of abstracting service quality definitions into a technologyindependent form, and of expressing them using concepts that are relevant to customer communications. • Vendor benefits – basis for development of standardized service quality technologies and interfaces within the industry; – helps operators to understand customer and provider SLA requirements; – helps in defining the mapping between service-specific parameters and measurement methods, on the one hand, and technology-specific parameters and measurement methods, on the other. The vendor benefits listed above relate to the assessment of performance of equipment purchased from a vendor by an operator. Between the network operator and vendor, too, a common vocabulary and conceptual framework are important.


193

Thus, the usability of SLA is not limited to formalization of the business responsibilities of a service provider/network operator and a customer, but it is also useful as a conceptual vehicle for efficient communication more generally. Examples listed included communications between business units of a network operator, and between network operator and equipment vendor. It is important to understand that the SLA definition does not have to be a strait-jacket. For example, not all information in the customer-reporting interface needs to be specified in the SLA. Further, as noted previously, the contents of the SLA need not be carved in stone, either. The actual process of revisioning of SLAs later can be part of the SLA definition. Let us next take a look at applying SLAs in DiffServ environment as a small case study of the technical SLA contents. After that, we shall take a look at an example SLA contents including the technical part.

6.3.1

SLA and DiffServ

According to the proposed terminology of the DiffServ WG [RFC3260], it is useful to differentiate the technical part of a SLA, called the Service Level Specification (SLS), from the broader context of SLAs. The reason for this is that, properly defined, SLS can be said to be the technical content or appendix of a SLA, the latter being mostly contractual and business-oriented in nature. Similar reasoning is proposed to be applied to Traffic Conditioning Agreements (TCAs) and Traffic Conditioning Specifications (TCSs). The definitions of these terms in [RFC2475, RFC3260] are as follows: • Service Level Agreement (SLA). A service contract between a customer and a service provider that specifies the forwarding service a customer should receive. A customer may be a user organization (source domain) or another DiffServ domain (upstream domain). A SLA may include traffic conditioning rules, which constitute a TCA in whole or in part. • Traffic Conditioning Agreement (TCA). An agreement specifying classifier rules and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply to the traffic streams selected by the classifier. A TCA

194


encompasses all of the traffic conditioning rules explicitly specified within a SLA along with all of the rules implicit from the relevant service requirements and/or from a DS domain’s service provisioning policy. • Service Level Specification (SLS). The set of parameters and their values, which together define the service offered to a traffic stream by a DS domain. • Traffic Conditioning Specification (TCS). The set of parameters and their values, which together specify a set of classifier rules and a traffic profile. A TCS is an integral element of an SLS. Thus, the Service Level Specification is part of a Service Level Agreement, and the Traffic Conditioning Specification is part of a Service Level Specification. A Traffic Conditioning Agreement, on the other hand, does not need to be fully defined within the associated Service Level Agreement. [RFC3086] contains the following definition for a SLS: A Service Level Specification (SLS) is a set of parameters and their values, which together define the service offered to a traffic stream by a DS domain. It is expected to include specific values or bounds for PDB [Per-Domain Behaviour] parameters. The SLS for a DiffServ domain consists of a set of measurable service quality characteristics. Since the DiffServ reference architecture consists of traffic conditioning, classification and marking at the network edge, and Per-Hop Behaviours for behavioural aggregates in the core of the network, the measurable characteristics are a product of all of these actions. For service quality implementation and supervision purposes, domain-wide characteristics applicable to quality of behavioural aggregates must be defined. The concept of Per-Domain Behaviours (PDBs) have been proposed in the IETF DiffServ working group [RFC3086], a PDB being defined as follows: Per-Domain Behaviour: the expected treatment that an identifiable or target group of packets will receive from “edge-toedge” of a DS [DiffServ] domain. (Also PDB.) A particular PHB (or, if applicable, list of PHBs) and traffic conditioning requirements are associated with each PDB.


195

In plain language, a PDB must be able to provide measurable attributes describing the treatment a class of packets experiences as a result of classification, conditioning and forwarding in one or more PHBs inside a DiffServ domain. A PDB may depend on certain conditions such as the loading level of a network domain. The attributes are not enumerated in full, but it is rather stated that a wide range of them is possible, as long they are network domain-specific. Drop rate, throughput, and delay bounds as measured over a defined period of time are cited as examples. Due to the statistical nature of DiffServ, the attributes are suggested to be statistical rather than absolute. The PDB draft goes on to discuss usual service definition-related issues, the following example being cited: PDB attributes may be absolute or statistical and they may be parameterized by network properties. For example, a loss attribute might be expressed as “no more than 0.1% of packets will be dropped when measured over any time period larger than T”, a delay attribute might be expressed as “50% of delivered packets will see less than a delay of d milliseconds, 30% will see a delay less than 2d ms, 20% will see a delay of less than 3d ms.” The PDB draft suggests that PDBs should not be used as such but as parts of service specifications. This is well in line in using them as part of SLSs. A Best Effort PDB is provided in [RFC3086] by way of an example. The DiffServ framework draft [RFC2475] defines the Traffic Conditioning Agreement as follows: [TCA is] an agreement specifying classifier rules and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply to the traffic streams selected by the classifier. A TCA encompasses all of the traffic conditioning rules explicitly specified within a SLA along with all of the rules implicit from the relevant service requirements and/or from a DS domain’s service provisioning policy. The TCS defines the parameters used in metering the traffic, that is – classifying packets as conformant or non-conformant to the TCA – as well as actions (remark/drop/shape/null action)

196


applied to non-conformant traffic. Note that the TCS limits the traffic control means available to the traffic engineering process.

6.3.2

SLA contents

The contents of a SLA are outlined below in view of concreteness of discussion. In line with the orientation of the previous chapters, the SLA is studied from a DiffServ viewpoint, including the TCA, SLS, and TCS parts. The contents have been drafted based on the TMForum SLA model [SMH01], the DiffServ framework model [RFC 2475], the proposed terminology for DiffServ [RFC3260], and the discussion in Sturm et al. [SMJ00]. Table 6.1 provides an example of SLA contents for a DiffServ domain. All aspects of the example SLA contents must be clearly defined, measurable, and agreed upon by both parties. The example contents for a SLS consist of TCS parameters and PDB characteristics corresponding to a SLA covering VoIP, browsing, and data traffic. TCS parameters are given in the Table 6.2, and examples of PDB characteristics for the appropriate services are listed in Table 6.3. The delivery of service statistics mentioned in Table 6.2 can be agreed upon to help network operator to better Table 6.1

Example SLA contents for DiffServ domain

Terms of applicability Definition of exceptions Definition of service support Relevant part of the Traffic Conditioning Agreement Necessary technical definitions: SLS, TCS (see below) Definition of service coverage time Measurable quality metrics that can be guaranteed by the service provider under specified conditions Service performance measurement method, measurement period, reporting period, and reporting frequency Agreement about delivering service statistics to the network operator by service operator Customer and service provider responsibilities Procedures relating to violation of SLA Definition of conditions of applicability of SLA Definition of reporting Acceptance procedures Review procedures Revision procedures

6.3 SERVICE LEVEL AGREEMENTS Table 6.2 types

197

Example TCS parameters for a SLA consisting of three service

Token bucket parameters used for VoIP, treatment of out-of-profile traffic. Token bucket parameters used for browsing, treatment of out-of-profile traffic. Token bucket parameters used for data traffic, treatment of out-of-profile traffic.

Table 6.3

Example PDB characteristics for VoIP, browsing, and data traffic

Service PDB VoIP

Browsing Data traffic

Characteristics Maximal allowed 90%, 95% and 99% delay distribution percentiles between any pairs transport operator PoP’s. Maximum packet loss percentage. 95% and average delay characteristics. Minimum throughput. Average throughput.

Note: The characteristics are defined pertaining to a specific measurement arrangement.

optimize network configuration to the needs of the customer. This topic will be discussed further in next chapter. As was noted in Chapter 5, it may be necessary to define PDBtype characteristics time-dependently, for example, separately for different times of day, or separately for weekdays and weekends.

6.3.3

End user SLAs

The contract of connectivity provided for the end users is a special case of a SLA. The charging model between the end user and the operator is a central part of the contract, which is why it is briefly discussed here. The pricing of service quality support can be implicit or explicit. The contract can be flat rate, cost being independent of the number of service invocations. Other options include volume-based and time-based charging. Also combinations of these can be used. For example, the SLA can be flat rate up to a specified traffic volume, and volume-based thereafter. When charging is not flat rate, having a small set of service quality support classes makes charging information more easily understandable for the end user. It is also desirable not to receive bills from different parties of the end-to-end chain, which is why e.g. the QoS support for VoIP in the access network should preferably be charged as part of the service provider bill.

198


Service support can be of best effort type, or true multi-service support. In the latter case, the operator will most likely define traffic conditioning specification as a part of the end user SLA. Typically the network operator will police end user traffic according to the TCS, but the end user may also police traffic at a network egress node interfacing to the transport operator’s network. The latter arrangement makes it possible for the end user to apply their own policies to out-of-profile traffic without having to disclose them to the network operator, or having to redefine the SLA contents merely to modify the TCA part thereof. Simple examples of service specifications for end user SLAs were provided in the previous chapter.

6.4

END-TO-END SERVICES

Above, service level management inside a domain has been discussed. The SLA in this mode of use is an interface between the customer and the service provider. In the general case, however, this is not enough, as there may be one or more intermediate transport or service providers between the end user and the actual service provider. Next, we shall discuss what is needed to provide service management end-to-end. The conceptual figure is shown in Figure 6.5, consisting of an access network as well as zero or more transport domains in between them. Each domain is assumed to be managed independently, and to apply traffic engineering methods as necessary. An access network domain can perform per-flow operations, such as policing, conditioning and admission control. In between the domains, at least aggregate properties are of significance. For best effort networks, one aggregate may be enough, Per-flow operations

Properties of aggregate

Access network

Transport domain 1

...

Access network 2

Host

Figure 6.5 Reference figure for end-to-end service management

6.4 END-TO-END SERVICES

199

but for multi-service networks, typically more than one aggregate are needed. It should be noted that with an over-dimensioned backbone, differentiation of traffic aggregates may not be needed for service quality support purposes, but access network aggregates may still be visible if DSCP markings are carried transparently through the backbone. Depending on the application control model, interworking between transport domains may take place directly (as depicted above), or under the control of service layer as discussed in Chapter 5. In the former case, there are service support interfaces between the transport operators. In the latter case, interfaces exist both between the service operators and the transport operators, on the one hand, and between transport operators, on the other. There are multiple approaches to interfaces applicable to end-toend services, the most important categories being the following: 1. SLA-based interworking. 2. Interworking based on traffic aggregates, supplemented by signalling. 3. Per-flow signalling end-to-end. The above options can be used both between service operator and a transport operator as well as between two transport operators. Let us compare these alternatives briefly. For concreteness, IP telephony spanning multiple transport domains is used as an example. SLA-based interworking means that the transport operators have mutual SLAs for IP transport support for necessary service types. The SLAs can in this case be thought of being static, defining the service quality support given that input traffic volume in each traffic aggregate stays within predefined bounds. It is the responsibility of each operator to make sure that the volume limit is satisfied. This is the default mode for today’s best effort Internet. Traffic aggregate-based interworking can be part of a SLA, but traffic aggregate interworking can also be used without a SLA. For example, there can be a rule for performing a fixed mapping from a DSCP marking in one DiffServ domain to the DSCP marking in another DiffServ domain. Interworking based on aggregates can also be supplemented by signalling. If interworking is operated on service layer the conceptual entities intermediating signalling could be termed service brokers, which are discussed briefly later

200


in this chapter. If the signalling concerns only transport parameters, the mediating entity is termed here a bandwidth broker, a topic that is discussed in more detail in Chapter 8. Such an entity is similar to TIPHON’s Transport Resource Manager (TRM). Sometimes bandwidth broker is understood as operating on the service layer, too. Both service quality-based interworking and service quality support aggregate capacity-based interworking are valid models for service operator/transport operator interface. Finally, the end-to-end service requirements can be signalled end-to-end for each flow. This is an end-to-end application of the approach used in the original IntServ approach. This approach is considered to have scalability problems if applied Internetwide. A further implication is that the signalling mechanism needs to be supported in each domain. One viewpoint on bandwidth brokers is that they provide per-flow service quality instantiation support beyond static SLAs, without having to resort to perflow signalling. We shall use the SLA-based approach in the present chapter, and analyse the signalling-enhanced aggregate-based dynamic approach in Chapter 8. The end-to-end analysis includes communication endpoints, for example, a server and IP host of the end user. We shall start by defining what is assumed about connection endpoints. Next, the assumptions about per-domain service support are reviewed, and then we shall proceed to discuss the end-to-end picture.

6.4.1

Assumptions about connection endpoints

From the transport network operator’s responsibility point of view, the effect of endpoints of communication is contained in the flow descriptor (cf. chapter 2), be it implicit or explicit. If the load sharing arrangement implementation of a server farm – for example – is such that it increases burstiness of streams, the means of handling burstiness is defined in the SLA between the service provider and the transport network operator. From the information sharing and customer orientation point of view, however, it is useful to understand and to have a means of classifying the effect of endpoints to end-to-end service quality. The benefits to the service providers and end users utilizing this kind of knowledge are rather more obvious.


201

The endpoint pairs depend on the service type, common examples being: • Host and server. This is relevant for typical Internet client/server applications, as well as streaming. • Host and host. This is relevant to point-to-point services, such as IP telephony or messaging. • Group of hosts. Multicast conferencing falls within this category. • Server and server. Example of this could be machine-to-machine communications. Obviously, “host” above can mean different kinds of IP hosts, including tabletop PCs, laptops, and GPRS/3G terminals. “Server” is a generic term for an information system hosting a data service such as streaming or HTTP server. In IP telephony, the properties of terminals (hosts) are extremely important because of the tight end-to-end service quality requirements. Audio encoding/decoding routines require nontrivial data processing capacity on general-purpose processors, operating systems may give rise to delay variations. Finally, the audio hardware may cause unpleasant surprises with respect to audio quality on normal PC hardware. The ETSI EP TIPHON VoIP terminal classification, taking into account the effects of terminal hardware, is one way of handling this issue, but an assessment of its applicability to Internet services in general would require more study. A possible approach would be the classification of the operating systems and TCP/IP stacks according to their delay and delay variation effects. However, this would be a major undertaking. In the following discussion, it is assumed that the endpoint environment also includes a LAN in the general case. Examples of such environments could be home LANs, or the LANs of service providers. In addition, a service provider may have a service support set-up with potential end-to-end service quality effects from software and hardware set-up. In general, the service quality support in endpoints is affected by many factors, some of which are listed in Table 6.4. Some of the issues mentioned in the above list have been discussed before. Here, a few complementary points are made. The loading level and the mechanism of the access network of the endpoint are important, as often shared media such as 802.3 are used

202

SERVICE LEVEL MANAGEMENT TECHNIQUES Table 6.4 Examples of factors affecting end-to-end service quality

Implementation of application Multi-service support API between operating system and applications Degree of real-time process scheduling and process prioritization support in operating system CPU loading level of endpoint TCP/IP stack implementation in the operating system Link layer protocols run in the endpoint Traffic shaping/conditioning in the server Service quality support in the network the endpoint is attached to Loading levels in LAN Load sharing solutions (for servers) Implementation of border gateways and firewalls Network interfacing towards ISP

450 d1 d2

400 350

Delay (ms)

300 250 200 150 100 50 0

0

500

1000

1500 Seq #

2000

2500

3000

Figure 6.6 Variation of delay for two simultaneous emulated VoIP media streams in a non-switched Ethernet segment with bursty background load. Note: X-axis represents the sequence number of RTP packets including a single 20-ms G.711 voice sample each. The second trace is shifted vertically by 200 ms for the purposes of legibility. Source: From [RR00]

in office/small office (SO) environment. Since the Ethernet measurements of Leland et al., it has been known that Carrier Sense Multiple Access/Collision Detection (CSMA/CD) in shared media may cause fractal traffic profiles [LTW + 94]. An intentionally dramatic example can be seen in Figure 6.6. Switched Ethernet helps with this problem, but may not be enough. Data traffic is typically inherently bursty, and it has been speculated that the very


203

behaviour of TCP/IP can give rise to similar traffic profiles. Traffic conditioning at the network edge alleviates these effects. When the amount of real-time traffic can be controlled, VLAN or some other method may be useful in ensuring QoS as a part of the end-to-end service support chain for delay-critical date types [Fin02]. Support for real-time services in the operating system and network drivers is paramount for VoIP, covering the areas of Operating System (OS) process scheduling, interrupt handling, TCP/IP stack implementation, and device driver support. Applications need an interface for using these mechanisms. When the OS supports process prioritization deterministically and in a timely manner, the loading level of CPU is not as critical an issue. Proper implementation in link level communications device driver can go a long way towards helping real-time streams by prioritizing link-level PDUs. On the server side, CPU load is more important issue, as typically a large number of similar service instances are executed simultaneously. Especially for streaming, traffic conditioning and shaping in the originating server may be beneficial. The loadsharing scheme used in a server farm may have effects on service quality depending on the degree of traffic variability caused by it. A major service provider may implement traffic engineering means for its own network even if it is not providing transport services for other parties. This is useful when the access operator has made a contract with the service provider for content (see Figure 6.7). Summarizing, the endpoint environment including the hardware and software set-up of the actual communication endpoint host, as well as network set-ups and loading levels, need to be taken into account in making SLA analyses. Depending on usage scenarios, services, and loading levels, it may be necessary to implement some sort of service quality support mechanisms

Access network

Transport domain 1

...

Service provider network

Server

Host

Figure 6.7 The service provider side SLA as a part of the customer service of an access network provider

204


also in the communication endpoints and LANs. Priority scheduling and traffic shapers are examples of the former, whereas 802.1q – type prioritization can be used in the Ethernet, and prioritization-type techniques such as multiclass PPP over other link layers.

6.4.2

Assumptions about per-domain service management

The SLAs can be issued by transport service operators for service providers, other transport service providers, or end user customers. The network operator may provide services itself, or to merely provide transport with service quality support for third party service providers, or both. Similarly, a transport operator may provide inter-PoP transport for traffic aggregates, access for individuals or corporations, or both. The mechanisms used by transport operators to provide service quality support can vary from domain to domain, depending on operator business goals, the legacy of the installed base and the spectrum of supported services. The mechanisms can include, but need not be limited to, the following: • DiffServ. This is the main topic of this book, although the service level management techniques also apply to the other technologies. • IPoATM. With IPoATM, separate capacity can be reserved for some of the aggregates, or alternatively common capacity reservation can be made for all traffic aggregates. • Reserved capacity for service quality support aggregates. For example, traffic engineering MPLS or MPλS/WDM could be used for this purpose. • IntServ. This approach is possible at least in access networks with a relatively small number of flows. • Best effort. As long as there is enough capacity, this is the simplest solution, but not necessarily a future fail-proof one, in the face of traffic growth. The degree of multi-service support depends on the service quality mechanism if the network is not over-provisioned.


205

Over-provisioning is a valid model for backbone transport, where the total traffic volumes are predictable due to high flow aggregation levels. When the network has necessary mechanisms for multi-service quality support, also the capability to provide the mechanisms to support necessary services is assumed. The burstiness properties of both individual flows and traffic aggregates depend on whether some form of conditioning has been applied to traffic. Conditioning can be performed for flows in access network domains, or to traffic aggregates between network domains. Similarly, the admission control mechanism in the access network domain affects the service quality. The admission control can be performed on the level of service instances, or in the form of generic service quality support instantiation control. The domain is also assumed to have necessary service quality supervision methods. Transport operators providing access to end users – either per connection or on aggregated levels – will most likely need a means of proving to the customer that its part of the end-to-end chain is not to blame for faults. Measurement means applicable to other parts of the end-to-end chain – endpoint service quality and/or other transport operators – may be helpful in this task. The customer of an access transport provider may want to get notifications of customer-side SLA violations. For a transport operator with a geographically large network, a capability of providing SLAs related to pairs of PoPs is needed. The vacuum velocity of light is roughly 300 000 km/sec, or 300 km per millisecond. In fibre optic cables, the typical velocity is roughly two thirds of that. The propagation delay over long distances is important for protocols that perform end-to-end flow control, such as TCP. For long-haul connections, the transmission method may be important. In some cases, cable-based transmission is not possible, and satellite connections are used instead. Geostationary satellites orbit the earth at the distance of 38 000 km, yielding up to 2 × 125 for one leg of the communication, or up to 500 ms for one roundtrip time involving four ground stations – satellite hops. Low Earth Orbit (LEO) satellites could provide much shorter delays, but a sustainable business model for their wide-scale deployment is yet to be found. The different means used to implement the actual SLA commitments do not need to be visible to the external agreement parties, unless specifically agreed.

206

6.4.3


Requirements for end-to-end service management

To fulfil the end-to-end services, per-operator SLAs need to be combined in a way to meet the service quality requirements. The mathematical aspects of this have been discussed in Chapters 2 and 5. In practice, the end-to-end service quality support can be achieved in different ways: • Knowledge of peering agreements between the transport operators. • Peering agreements between service providers + agreements between service operators and transport providers. • Using an inter-domain service broker. The first of these is the simplest one, necessitating no inter-domain signalling. At the minimum, service quality interworking between two operators can be based on SLAs concerning traffic aggregates. As mentioned above, the SLA between peering operators may depend on the PoPs through which the traffic aggregates passes. Thus, the SLA may be affected by routing, which has to be taken into account in computing the end-to-end service quality. When service providers are responsible for the end-to-end services spanning multiple transport domains, they may also be responsible for routing of the service instances, at least on the high level. Routing considerations are usually a part of IP telephony-related service quality scenarios, for example. When there are more than one service operators involved, the service operators need to have a means of dividing the end-to-end service quality budget among them. Such a case arises in person-toperson communications when the endpoints are using services from different providers. Depending on the type of the service in question, a variety of mechanisms can be used to manage the end-to-end service quality allocations. When a service operator has SLAs for more than one transport operators at its disposal, it has more operating freedom. A transport service broker is an idea that has been put forth in research literature. Assuming such entities are used, the end-toend path for service instances – or aggregations thereof – could at least partly be based on buying capacity from the “free market” based on the actual loading situations of operators in the Internet.

6.5 SERVICE BROKERS AND CHARGING

207

Conversely, a transport operator could sell unused capacity in such free markets. The practical usefulness of this concept is yet to be proved.

6.5

SERVICE BROKERS AND CHARGING

The Internet today is based on receiver of the service paying – at least partly for services. Drawing an analogy with the development of international postal system, Semret et al [SLC + 00] argue that also the Internet is developing towards “sender pays” model. Obviously, such a model is applicable to person-toperson services. Indeed, this model is used in the popular SMS services. In addition, the model could be used for accommodating advertising content, for example. In such a model, the pricing of service transport becomes increasingly important. Further justification for this conclusion from the anticipated “sender pays” scenario is provided by referring to the rapid creation of novel services in the Internet. Arguing that model-based demand prediction may be difficult in the general case, the authors discuss the use of an auctioning model for pricing differentiated Internet services. This model is illustrated in Figure 6.8. The reference model of [SLC + 00] consists of users, raw bandwidth sellers (corresponding roughly to transport operators in the preceding discussion), and service providers. Despite the name “raw bandwidth”, the capacity “sold” does not have to be best effort only. Auctioning takes place via bids for bandwidth, sellers being able to provide three kinds of SLAs: expected capacity, worst-case capacity, and domain-local SLAs. The first two of these can be used for providing statistical services to external parties, that is, to other domains participating in the auctioning of bandwidth. The result of the authors’ distributed game-theoretic analyses show that in certain stable simulated scenarios, market mechanisms work well, auctioning mechanisms making possible stable differentiated quality and pricing in a flexible manner. Alas, there are situations, which yield unstable situations. Further, some combinations yield zero peering as the only stable solution. A stability condition is derived in [SLC + 00]. The authors suggest feedback control and routing control as potential ways of enhancing the stability of the service brokers.

208


Service provider Transport provider

End user

Transport provider

Transport provider

Transport provider

Service provider End user

Figure 6.8 Example scenario for auction model. Routing between the service providers is selected using the market price for service support

Comparing the auction model to the reference models used in this book, the auction model does not contradict of the previous discussion. SLAs are an estimate of the development of market pricing for the duration of the contract period, whereas in the auction model, pricing is set based on shorter timescale estimates. It would be interesting to see auction models enhanced in service quality support respects, that is, adding delay and packet loss, for example, to bandwidth as the attributes of goods traded. In such a situation, the bandwidth brokers discussed in Chapter 8 could be used as a component in implementing a service brokertype system. The adoption of auction model is linked to the efficient utilization of the installed transport network capacity. For example, long-haul transport operators could sell part of their off-peak network capacity to external parties using short-term contracts, or use the capacity that has been built for accommodating future growth for this purpose. Multi-service support might be a driver for taking steps in this direction, since more revenue can be expected from transporting demanding traffic types, and it is therefore desirable to include as many high-revenue traffic types in the traffic mix as possible.

6.6 SUMMARY

6.6

209

SUMMARY

Implementation of advanced Internet services most likely will benefit from the body of knowledge associated with service definition in telecommunication networks. This may not have been the case in best effort Internet until now, but the situation can be expected to change with tightening competition and smaller profit margins. Another driver towards this is the requirement to support critical service types such as telephony, for which the quality requirements are well known. The practical tool for achieving service quality support endto-end is the Service Level Agreement (SLA). SLAs can be used between the end user and access network operator, between network operators, between network operator and service provider, and between service providers. In the case of a DiffServ network domain, the SLA includes Service Level Specification (SLS) and Traffic Conditioning Specification (TCS) per-service type as components. The SLA is basically a contract with business goals and a period of validity associated with it. From the viewpoint of the network operator, the technical components of SLAs for different parties represent boundary conditions in utilizing the network resources, and in performing traffic engineering optimization for the resources. Thus, the SLA management process within the network operator needs to have an assessment of the validity of the SLA contents as an important component. It is important to define individual services well enough to be able to make best use of SLAs. The variants of service available need to be decided upon, and the service quality requirements and the characteristics of individual service events making up a service instance need to be analysed. The properties of service events need to be reflected in TCSs for the end user at the edge of the access network domain, and the quality requirements of service events are reflected in the mapping of services to service quality support aggregates in the network. Per-Domain Behaviours (PDBs) are conceptual devices that can be used as part of perdomain SLAs in DiffServ domains. Service quality support mechanisms in both the endpoint itself and the local area network connecting the endpoint to the first transport domain are important for the end-to-end service quality. Such endpoint effects relate both to end users and service

210


providers. They affect the ability of the endpoint to fulfil its part of the SLA, the other party of which is the transport operator, and may also cause effects that are adverse to end-to-end service quality even though not affecting the SLA. From the transport operator’s point of view, the sub-optimal performance of the endpoint is absorbed within the endpoint operator or customer commitment in the SLA. implementing service quality in ip networks An auction model is a possible scenario for the future for making effective use of built transport capacity. The validity of this model in the face of usual diurnal traffic variations is to be confirmed. It is possible that it could be used at least for some service classes.

7 Measurements NO IAYTON (Know thyself; Inscription on the fa¸cade of Apollo’s temple in Delphi)

The traffic engineering process for IP networks includes obtaining feedback from the network as the basis of assessing the need to modify transport network parameters and to optimize its behaviour. Obtaining information in precise and meaningful form is imperative for being able to make the right adjustments to improve the network performance. This chapter deals with the means of monitoring service quality, the analysis methods applied to measurement data, and examples of network performance optimization based on processed measurement information. A formulation of the goals and methods of traffic engineering measurements in IP networks has been given in a recent Internet draft [LCT + 02]. This draft will be used as an introduction to the topic in this chapter, quoting other sources and adding issues specific to multi-service networks as necessary. In the draft, ISPs are singled out as one likely user for the methods presented. The scope of the conceptual framework development therein is intra-domain operations, but the definitions are intended to be transferable also across operator domain boundaries. As such,


212

MEASUREMENTS

they should be applicable to different per-domain technologies as well. The need for consistency, precision and effectiveness of traffic engineering methods is cited as the reason for applying an overarching framework for traffic engineering. The ultimate goal of measurements is to serve the needs of the traffic engineering process, including forecasting, planning, dimensioning, control, and performance monitoring. The major tasks of traffic engineering measurements are defined in [LCT + 02] as • traffic characterization; • network monitoring; • traffic control. These will be discussed in more detail later in this chapter. Let us note in passing again that in multi-service networks, the characterization, monitoring, and traffic control tasks may need to be applied to multiple traffic aggregates on individual links. Three approximate timescales pertaining to the use of data obtained with measurements are identified in [LCT + 02], namely: • Months or longer. This timescale relates to network planning and upgrading. Forecast traffic volumes per service class are important here. • Hours to days. Capacity management is the primary use of measurement data at these timescales. Measurement data could be used to control default routing of traffic aggregates and resource allocation in network nodes. • Minutes or less. This timescale belongs to real-time control of the network. In [LCT + 02], the example of temporary rerouting of traffic aggregates to circumvent congestion is cited. As we shall see later, measurements dealing with different timescales have different requirements and analyses associated with them. Some general requirements for measurements are: • Accuracy in capturing important phenomena at different timescales. The shortest timescale of relevance to network performance on the timescale of interest must be known and the measurement methods should be chosen accordingly. In a multiservice network, the required accuracy may be different for

7.1 TRAFFIC CHARACTERIZATION

213

different traffic aggregates. For example, millisecond-accuracy measurements for delay may be desirable for VoIP, but not necessary for best-effort traffic. • Network performance should not be degraded by measurements. This applies both to the elements being measured as well as the effect of measurements and transferring of measurement data to the normal operation of a production network. Interestingly, this is an issue not only for active measurements but passive ones as well. • The amount of data generated should be moderate. Regarding the last two points, these issues are typically more challenging in a multi-service network than in a best-effort network, since there may be multiple quality support aggregates involved for each link. Subsequently, both performing the actual measurements and transmitting measurement data in such a way as not to interfere with the normal network operation need to be carefully planned. Next, we shall take a look at the three tasks of traffic engineering measurements as defined by our IETF framework [LCT + 02], and then will discuss the definition of measured characteristics, sources of information, measurement methods, and the required measurement infrastructure in general. The present chapter will be concluded with case studies.

7.1

TRAFFIC CHARACTERIZATION

Traffic characterization is the first task of traffic engineering measurements as defined by [LCT + 02], having the following goals: • Identifying variations in traffic patterns using statistical analysis, including development of traffic profiles to capture daily, weekly, or seasonal variations. • Determining traffic distributions in the network on the basis of flows, interfaces, links, nodes, node-pairs, paths, or destinations. • Estimation of the traffic load according to service classes in different routers and the network. • Observing trends for traffic growth and forecasting of traffic demands.

214

MEASUREMENTS

The determination of traffic distributions in the network is partly related to the estimation of traffic matrix discussed in Chapter 4. In other words, direct measurement can be used to obtain the topological distribution of traffic in the network. However, perlink volumes need to be linked to traffic aggregates entering and exiting the network domain in order to influence the distribution with routing control. For a best-effort IP network domain, traffic pattern variations may relate to changes in the composition of protocol types in the totality of traffic, as well as information about traffic volumes in topological context. In multi-service networks, such information should be available per service quality support aggregate. In a multi-service network with service mapping onto service quality support aggregates on the network edge, traffic engineering benefits from the ability to compare characterizations of both incoming service types and service quality support aggregates, side by side. Such a comparison makes it possible to effectively evaluate the suitability of both the service/aggregate mapping at the network edge, and the service quality support for aggregates in the network core (see Figure 7.1). Depending on the measurement methods, discussed in more detail below, modelling of data may be needed to interpret the results in a context relevant for traffic engineering. For modelling, the alternatives are fitting of measurement results into an existing model and providing generic modelling for measurement results without reference to the use context. In certain situations modelling has a risk associated with it, since it makes assumptions about what the results should look like. Thus, when modelling is used, consistency checks should be constructed to check that the situation in the measured network Traffic load for service support aggregates

Service distribution

ER

Figure 7.1 Modelling both incoming services at the network edge and loads of service quality support bearers in the network core

7.1 TRAFFIC CHARACTERIZATION

215

is consistent with the assumptions made in the model. Another useful technique is computation of the same characteristics using multiple different methods. According to [LCT + 02], Internet traffic is bandwidth-limited but non-stationary; traffic can be heavy-tailed and have strong correlations at short timescales. This is often the case in besteffort Internet with no per-flow policing. The suggestion of the Internet draft is to use decomposition of measurement results into stationary and trend parts. Obviously the stationary part also needs to account for diurnal variations in traffic intensity. Regarding the scope of this book, this breakdown should be possible per service quality support aggregate. A more finegrained temporal classification of the problem area of traffic decomposition could be as follows: • trend prediction (days or longer periods of time). This timescale is relevant for capacity management in traffic engineering. • busy-hour traffic characterization; • statistics and correlation at the timescale of seconds. The reported measurement data should be associated with information on the scale of applicability, partly stemming from the details of the actual measurement. This requirement is valid irrespective of the possible use of modelling as a part of the measurement. An example used in the cited draft, modelling of flow burstiness can be performed by fitting measurement results into a token bucket model as the probability that a flow can be accommodated by the token bucket, as estimated from a measurement. The result, in general, can be dependent on the length of the measurement period. Thus, a full description of measurements in this case is as follows: • token bucket rate; • token bucket depth; • probability; • timescale of applicability. The timescale is of importance especially when dealing with selfsimilar traffic patterns, where the average magnitude of variations ranges with the length of the observation period.

216

7.2

MEASUREMENTS

NETWORK MONITORING

The goals of network monitoring, the second traffic engineering measurement task, are: • Determining the operational state of the network, including fault detection. • Monitoring the continuity and quality of network services, to ensure that service quality objectives are met for traffic aggregates. Further, goals include verification of the performance of delivered services. • Evaluating the effectiveness of traffic engineering policies, or triggering certain policy-based actions (such as alarm generation, or path pre-emption) upon threshold crossing; this may make use of past performance data, in addition to latest measurement results. • Verifying peering agreements (SLAs) between service providers by monitoring/measuring the traffic flows over interconnecting links at border routers. This includes the estimation of interand intra-network traffic, as well as originating, terminating, and transit traffic that are being exchanged between peers. Performance monitoring, meaning continuous monitoring of the performance of network elements to ensure that they are performing correctly, is a central part of performance management. Possible reasons for suboptimal service performance include route flapping, congestion, hardware or software failures, and element misconfiguration. In a multi-service network domain, the above goals need to be implemented for the different service quality support aggregates. This sets higher requirements for the measurement infrastructure. For example, one needs to be able to detect the malfunctioning at the granularity of individual service quality support classes. Similarly, the triggering of traffic engineering actions needs to work reliably in the multi-service case. Obtaining data for various subtasks of network monitoring is a trade-off between the number of different measurement types and accuracy for individual monitoring purposes. It is clearly desirable to derive multiple levels of performance characteristics from a single set of measurement data, if the methods for performing this are known and sufficient processing power for this is available. Alas, both conditions are not always found. Especially for new

7.2 NETWORK MONITORING

217

types of services, the analysis methods for obtaining service quality description may not yet be available. If services need to be created quickly for commercial reasons, the very act of configuring measurements using low-level data sources may be too timeconsuming and it may be easier to perform using separate servicelevel measurements. Later, when the behaviour of the network is understood better and on more quantitative level, the servicespecific performance data can possibly be extracted from a smaller number of measurements. The scheduling of measurements is part of the network monitoring task. One important concept here is the temporal distance between successive measurements, known as the readout period. The length of the read-out period should be sufficiently short to prevent momentary variations from being averaged out, but long enough to avoid disturbing the router. In a multiservice network, the measurement scheduling periods need to take into account different service quality support types. For measurements directly addressing the service level performance of a particular service support aggregate, the actual lengths of readout periods may be different from each other. For measurements, the results of which are used for assessing the performance of multiple types of services, on the other hand, the length of the read-out period may be determined by the strictest reporting requirement. An important part of network monitoring is presenting the measurement data within the right context. Taking the load as an example, in a simple routed IP network, load levels might be collected per link, out of which a meaningful traffic matrix needs to be constructed. If MPLS is in use, however, also load levels per LSP are of interest. If a single LSP is shared by multiple traffic aggregates, load levels per DSCP/LSP combination would be useful information for traffic engineering purposes. A router can belong to multiple such contexts. As an example, an MPLScapable DiffServ router could perform monitoring both per LSP, as well as per network interface.

7.2.1

Troubleshooting measurements for services

Troubleshooting-type measurements for service quality can be used as necessary to complement data from normal “traffic

218

MEASUREMENTS

engineering” type measurements. Troubleshooting measurements can be based on testing the actual service performance either using realistic protocols is an emulation of application stream, or otherwise measuring the quality of a traffic aggregate used as a bearer for applications. Application emulation – type troubleshooting measurements can be performed end-to-end, perdomain, or narrowed down on smaller areas to identify potential problem locations. For non-end-to-end measurements, one needs to be careful in interpreting the measurement results in terms of impact on end-to-end performance, as has been discussed in Chapter 5. Making an ICMP PING test for a route or for a LSP is an example of a simple test of the ability of an aggregate to transfer any data. Such tests could be carried out periodically to verify the operational status of routes or LSPs. An example of an application emulation troubleshooting measurement is transmission of emulated VoIP stream between two laptops, and measuring delay time series and packet loss characteristics from the stream. The emulation produces correct stream metrics (packet sizes and transmission intervals can be chosen to correspond to a realistic codec) and uses the same four lowest OSI layers for the measurement stream as a VoIP application (UDP/IP/LL/PHY). As with active measurements in general, ICMP PING and traceroute may not yield correct delays due to possibly different PDU treatment in routers for ICMP and L3+ traffic. Keeping in mind the related discussion in previous chapters, all measurements also take into account the possible effects of measurement endpoints. An example of an end-to-end test is verifying the signalling performance of a SIP proxy by using a SIP client, which is able to time the individual signalling events. In this case, provided that the endpoints (client and SIP proxy) are operating correctly, such a test shows an example of the effect of network performance to end-toend application performance. Similarly, assessing end-to-end VoIP performance could be based on transmission of reference samples over the network using actual VoIP terminal applications having hooks to provide application-level performance characteristics. A possible set-up and its relation to traffic engineering measurements in a domain are illustrated in Figure 7.2. The service flow emulation measurements can be made on the same route as the traffic engineering measurements, but may be expressly

7.3 TRAFFIC CONTROL

219

Testing of voice quality Traffic engineering measurements

Testing of signalling performance

IP domain ER

ER

Terminal

ER

IP domain SIP proxy

ER

Terminal

Testing of aggregate performance

Figure 7.2 Traffic engineering measurements (left) and different types of troubleshooting-type measurements (right)

designed to test the performance relevant to the tested application. An example of this is performing active measurements with 20 ms inter-packet separation to probe timescales of performance, which are relevant for the AMR codec.

7.3

TRAFFIC CONTROL

The third task of traffic engineering measurements, traffic control, is related to interfacing of the control part of traffic engineering to measurements. According to [LCT + 02], some of the relevant subtasks are: • Adaptively optimizing network performance in response to network events. Rerouting around points of congestion or failure in the network is given as example of this. • Providing a feedback mechanism in the reverse flow messaging of RSVP-TE or CR-LDP signalling in MPLS to report on actual topology state information such as link bandwidth availability. • Support of measurement-based admission control, i.e., by predicting the future demands of the aggregate of existing flows so that admission decisions can be made on new flows. The examples listed above relate to routing control and admission control means of service quality control. More generally, the examples are partly overlapping with activities in the traffic engineering process, which take measurements as input. Routing control above is an example of this. Another example could be using measurements for triggering configuration optimization and

220

MEASUREMENTS

reconfiguration of DiffServ parameters in the network elements using policy management. Other aspects of traffic control, as exemplified by the list above, fall within shorter timescales than what is relevant for the entire measure-model-reconfigure loop. Direct measurement-based feedback to admission control is an example of such shorter timescale processes. Further examples of traffic control include: • Triggering of reconfiguration of policing at the network edge. • Adjustments of link costs in link-state routing protocols based on measurements. This requires a management interface to link cost computation in routers. The first of these two examples is more clearly within the application of the traffic engineering loop, requiring configuration of multiple network elements. The reaction to a certain set of measurement results could still be preconfigured, avoiding the need to perform a full modelling step. Some aspects of dynamic traffic control falling within the concept of bandwidth brokers are discussed in the following chapter. It should be noted that in traffic control, modelling of system level behaviour is needed. The means for this have been discussed in Chapter 5. Modelling of system behaviour should be contrasted with modelling of data in the traffic characterization task, the latter providing input for the former.

7.4

DEFINITION OF MEASURED CHARACTERISTICS

The measured characteristics, in all, span multiple scopes. A general goal of Service Level Agreements, the characteristics should be to use system-level characteristics that are independent of protocols and platforms, and be uniform across operator boundaries [LCT + 02]. This goal is rather similar to the PerDomain Behaviours [RFC3086] mentioned in the last chapter. More fine-grained characteristics are needed for detailed performance information. The classification used in this chapter is as follows: characteristics can be measured at service level, packet or traffic aggregate level, or with network element granularity. Examples of characteristics at each of these levels are given below.

7.4 DEFINITION OF MEASURED CHARACTERISTICS

221

• Service level: – Service availability and continuity. – Average holding time. Typically computed for a flow at the network edge. Holding time of certain types of long-lived service instances may also reflect network reliability. – Service response time. This is also relevant for individual service instances. The above service level characteristics can be measured directly, when passive monitoring of production streams is feasible and technically possible. Service-specific data can also be obtained from appropriate service elements. An example of the latter could be querying SIP proxy for information about call statistics. When the SIP proxy is outside of the network operator’s domain, delivery of such information could be part of the Service Level Agreement. Service response time can also be estimated with application-level measurement, in which case modelling may be necessary. • Packet/aggregate level: – Bandwidth availability. Can be used for traffic control using multiple routes for a single traffic aggregate, measurement-based admission control (MBAC), or adjusting admission control or service quality support instantiation policy, for example. – Throughput. [LCT + 02] defines throughput as the maximum sustainable rate of packet transfer with which the service quality support objectives are met with. – Delay. One-way or two-way measurements are possible for active measurements, two-point sampling using passive monitoring for non-encrypted flows with sequence numbers possible. – Delay variation. Different measurements possible (one-point vs. two-point) [RFC3432, I.380]. – Packet loss. Depends on the protocol layer. Some of the loss for non-SLA-conformant packets may arise at network edge. – Statistics on erroneous PDUs. Model-based measurements may be useful in this category in minimizing measurement overhead, provided that the effect of fitting the results into a model on the results is properly understood.

222

MEASUREMENTS

• Network element/link level – Traffic volume. The share of offered traffic for the measured entity minus the effect of network condition, congestion, and other effects. – Resource usage. Link utilization, buffer occupancy, CPU load, and memory usage. – Traffic aggregate level statistics. Measurement results in this category are obtained by direct polling of elements or by a reporting interface to the measuring device (network element or probe). In multi-service environment, results for multiple traffic aggregates per network interface are typically needed. Measured characteristics are called entities in the terminology of [LCT + 02]. Above, the list of entities has been complemented by service-level characteristics. Characteristics being statistical in nature, only estimates can be obtained, as discussed in [SMH01]. When the dynamics and the characteristics of the associated phenomena are well enough known, model-based measurements can enhance the accuracy of the estimators.

7.5

SOURCES OF MEASUREMENT DATA

Physically, measurement data can be obtained from network elements and measurement probes. Network elements, in turn, can be IP or link layer devices such as routers, or service elements such as HTTP servers or SIP proxies. For a transport network operator, direct access to all service elements is not always possible, but service usage information could be included into a SLA.

7.5.1

Measurement interfaces

Let us next attempt to make overview of the measurement interfaces. The interfaces will be discussed in more depth in Section 7.6. From the network elements, data can be fetched using a vendorproprietary interface (for example, command line interface), or a standardized interface such as Simple Network Management Protocol (SNMP). The data available in the network element can be in

7.5 SOURCES OF MEASUREMENT DATA

223

the form of proprietary counters, or standard MIBs. The communication between the management system and network element can be based on polling of the elements by the management systems, and on elements sending SNMP trap messages to the management system in predefined conditions. Probes can be of an active or passive type, the former monitoring production traffic in the network, the latter transmitting probe streams in the network. The Remote Monitoring (RMON) MIB [RFC2819] is a possible interface with regard to passive probes, not requiring constant connection between the probe and the management system. IETF is also currently in the process of standardizing the IP flow information exporting protocol that could be useful for this purpose. For active probes and two-point passive measurements, standardization work is ongoing.

7.5.2

Measured characteristics

Typical examples of measured characteristics are given below: • Element-specific. For example, CPU loads. • Packet statistics. Lengths of packets, number of packets, corrupted packets. For passive monitoring, also the time the packet was received. • Flow. Source and destination addresses, port numbers, protocols, time of start and end of a flow, packet count, IP version (IPv4/IPv6). When the application flows are encrypted, obtaining of some of the information may be limited. • Traffic aggregate. Example characteristics are per-aggregate buffer occupancy levels, offered traffic and goodput, and packet loss statistics. • Service event. Example characteristics include end availability, user identity, invocation time, and service-specific parameters. • Per link. Relevant characteristics include overall link utilization statistics and packet loss rate. • Per node pair. Delay, delay variation, packet loss, packet loss correlation. The measured objects are called bases in [LCT + 02]. Table 7.1 relating measured characteristics (entities) and measured objects (bases) is given there. Some of the measurement types require information that is obtained by combining per-element or per-probe measurement data.

224 Table 7.1

MEASUREMENTS Relation of measured characteristics and measured objects

Bases Entities Traffic Volume Average Holding Time Available Bandwidth

Flow (Passive)

Interface, node (Passive)

Node pair (Active & passive)

Path (Active & passive)

X(1)

X

X(3)

X(3)

X

X(3) X

Throughput

X(3) X(4)

X(4)

Delay

X(2)

X(4)

X(4)

Delay Variation

X(2)

X(4)

X(4)

X

X(5)

X(5)

Packet Loss

Note: See p. 000 for an explanation of terminology and numbered notes Source: From [LCT + 02]. The following notes, indicated by the appropriate number in parentheses, apply to Table 7.1: (1) This measurement type can be used to derive flow size statistics. (2) These are one-point measurements. (3) As a starting point, statistics collected by passive measurement through the MPLS traffic engineering MIBs may be used. (4) Active measurements based on IPPM metrics are currently in use for node-pairs; they may be also applied to paths, but without means of controlling the routing no one-toone correspondence necessarily exists. (5) Besides active measurements based on IPPM methodologies, path loss may possibly be inferred from the difference between ingress and egress traffic statistics at the two endpoints of a path. However, such inference for the cumulative losses between a given node pair over multiple routes may be less useful, since different routes may have different loss characteristics. Also, loss of even one source (network element) of packet loss information along the measured path results in incorrect statistics on the domain level.

In service level elements, relevant counters depend on the service in question. Typical generally interesting characteristics are • total number of service requests per measurement period; • number of successful service requests per measurement period; • number of non-successful service requests per measurement period; • CPU load of the service element. MIB support for service depends on service details. Some aspects of application performance measurements have been specified in [RFC2564].

7.6 MEASUREMENT METHODS

225

Service level measurements can be performed per service type, or per service quality support aggregate. In the latter case, the measurement with a selected service type probes the performance of the service quality support aggregate. Measuring per service type end-to-end provides results, which are easiest to relate to end user experience. When the network operator is providing service quality support in the form of aggregates, most likely aggregate level measurements are used.

7.6

MEASUREMENT METHODS

Different measurement methods were enumerated in the context of traffic engineering earlier. Let us take another look at them now, from the point of view of what is being measured. Higher-level performance characterizations can be obtained by combining perelement data, possibly using some sort of system modelling in the process.

7.6.1

Obtaining performance data from network elements

There are two basic ways of obtaining performance data from network elements: 1. Reading performance counters in the devices, also known as polling. 2. Devices reporting predefined conditions being transpired. This can include both periodic reporting, and notifications. Related to the first method, first – and obviously – the relevant counters must be in place for monitoring. They may also need to be explicitly enabled. The data to be monitored can relate to packet statistics, traffic aggregates, flows, links, and service events. The four first items listed are IP or link level characteristics, whereas the last one is service-level characteristic. A subset of IP-level characteristics can be available in any IP device such as a router, depending on the set of counters available. The palette of available characteristics (and counters) may depend on the operating environment of the device – indeed, it is the basic idea of DiffServ to keep complex per-flow operations at the edge of the network.

226

MEASUREMENTS

Service-level characteristics, on the other hand, may be available from service support elements such as HTTP servers or SIP proxies, provided that the element has suitable counters and measurement interfaces. The second method, devices reporting predefined conditions being met in the network elements, again requires adequate counters to be present in the network elements, in addition to the ability to locally monitor the status of these counters and detecting when the predefined condition has been met. The condition can be related to the measured characteristics, or to clock reading, for example. In addition to counters relating to the monitored characteristics, a representation of measurement information (information model) is required. The representation can be vendor-specific, or standard such as a MIB developed for that purpose. Obviously, an open standard interface reduces dependency from a single vendor. There may be special circumstances where it is not meaningful to develop a standard MIB or PIB, however. Second, an interface between the performance monitoring entity and the network element is required. The polling interface can be vendor-specific, or standards-based, the latter including SNMP and COPS. The notification interface can be based on SNMP traps, COPS, or vendor-specific protocol interface. The assumptions behind the SNMP notification model may not always be valid. The counters possibly need to be activated by a management system, and may have parameters to be configured, such as constants used in computing a moving average. The management interface for configuring normal counters can be vendor-specific CLI, SNMP or COPS, for example. In the case of notifications, also conditions need to be configured, which can be expressed in the form of rules. Finally, a schedule for reading out the counters from network elements is needed for the polling scheme. The scheduling of counter read-outs may depend on diurnal and weekly variations of traffic. Traffic volumes and element loading due to polling need to be checked, especially when multiple performance monitoring entities are polling the routers for information. In the case of notifications, a configuration interface is needed, for defining the condition triggering the notification, and for specifying the receiver of the notification. Resiliency considerations may lead to specifying back-up receivers if the primary target is unavailable.


227

It should be possible to verify all configured measurement values via a management interface.

7.6.2

Monitoring a link

Monitoring a link in an IP network domain relates not only to packet level characteristics, but can also be used for obtaining flow and service level information, and link layer information. For services, link monitoring is different from querying an actual service element in that the service-level information must be indirectly inferred from what is observed on the link. The complexity and feasibility of performing this task depend on the service in question and on the aggregation level. The capability of performing such an inference may be limited due to factors such as encryption, and may be ethically and/or legally problematic from privacy viewpoint. The actual monitoring can be performed in two basic ways: 1. Using link interface device counters in a network element such as an IP router. 2. Using a separate device for monitoring link status. In some cases, the device can be as simple as a FreeBSD or Linux host running suitable analysis application using raw socket interface towards the link. Again, both polling and notification interfaces are in general possible, depending on the link layer hardware. The central issues relating to being able to use counters of network elements have been dealt with in Section 7.6.1. If flow or service-based monitoring needs to be performed on an IP device, additional processing capacity as well as the relevant data storage and data export capabilities and interfaces may be needed. When separate devices are used for monitoring a link, the hardware performance of the network interface device may need to be non-trivially high in case it is used for operations concerning individual flows in links of high capacity. When flow and service-based monitoring is performed, the information models and configuration system must be suitable for using this kind of information, and need to be able to cope with potentially large amounts of data per time unit. Link monitoring may not be always active. In this case, scheduling of monitoring and the means of activating and deactivating

228

MEASUREMENTS

measurements need to be defined. Activation of measurements can be performed in a centralized way, or by defining the measurement schedule in actual network elements. The explicit activation of a particular measurement type may be triggered by other measurements, or be performed because of other traffic engineering reasons. The configuration of scheduled measurements could be performed using a suitable interface towards elements that have the necessary capability.

7.6.3

Monitoring a route or node pair

Monitoring of a route can relate to packet, flow, traffic aggregate, or service level characteristics. At least the following methods are possible here: • Querying service elements. Certain kinds of service elements know the endpoints of the service events, and may have information about routing of individual service instances and service events. If this does not uniquely pin down the routing, routing table monitoring information can be used to supplement the data. • Performing two-point link or element monitoring and combining the results. • Performing one-point monitoring supplemented with routing information. • Active measurements on the route. For actual service instantiation on a route, using data obtained with querying service elements probably yields the best results. For monitoring traffic using a traffic aggregate two-point monitoring is probably the most reliable method. The data obtainable with this method are subject to the potential limitations mentioned in Section 7.6.2. Also the single-point + routing information can be used, depending on the stability of routing. For monitoring service quality support of traffic aggregates, active measurements are a viable option. These are especially useful for measuring delay, delay variation, and packet loss statistics relating to a traffic aggregate. The use of two-point link monitoring


229

for these purposes requires that there is at least one stream in the monitored traffic aggregate which has sequence numbers stamped onto its packets. This is the case for non-encrypted RTP streams, for example. Measurement of delay is technically challenging with two-point monitoring only, as the arrival times of packets in the two points need to be recorded very accurately. Additionally, the properties of the measurement stream can usually be defined more precisely for active measurements than for a randomly monitored stream. Active measurements can be used to test whether a route or an LSP is operational. Active measurements can be measurements of statistics of the traffic aggregate (delays, packet losses, etc.), or can emulate the actual service instances, including at least a part of the protocol stack used by real applications. A few examples are provided in Table 7.2. The management tasks related to monitoring of a route include selection of endpoints for the measurement, and possible scheduling of measurements. For active and two-point link monitoring, route selection involves two actual measurement entities. The entities can be “measurement agents”, that is, pieces of software in network elements. For service element querying, and one-point measurement schemes, the endpoint selection may be more akin to data mining. As with link monitoring, the scheduling can be done by the measuring entities themselves or by the centralized performance monitoring system. Table 7.2

Examples of active measurement types

Type

Example

Notes

Service quality support aggregate performance

Poisson-distributed transmission of packets.

Defined by IPPM working group.

Periodic streams

Defined by IPPM working group.

ICMP ping

Results may differ from application performance.

Service emulation

HTTP query Emulation of VoIP media stream

230

7.7

MEASUREMENTS

TRAFFIC ENGINEERING MEASUREMENT INFRASTRUCTURE

Next, let us take a look at the infrastructure needed to accomplish the task of traffic engineering measurements. In what follows, the goal is to describe equipment that is able to achieve most of the tasks discussed in this chapter. Not all of the functions may be always applicable. In general, the infrastructure consists of a number of measuring entities, interfaces to the measuring entities, measurement control and analysis functions. Here, it is assumed that a separate configuration system such as policy-based management exists to perform the actual configuration changes resulting from optimization task.

7.7.1

Measuring entity

A measuring entity is the source of measurement data. It may be a network element with suitable counters, or a dedicated entity such as a measurement probe. In both cases, the identity (IP address), location (in a connectivity hierarchy), and capabilities of the measuring entity need to be known by the measurement control system. The location depends on which layer the measurement is performed: if the measured characteristics related to link layer properties, it is possible that information about link layer connectivity is needed in addition to IP level connectivity. Examples of capabilities of a measurement entity are the counters implemented, the measurement type (active measurement/passive monitoring), and the possible ability to act independently. The independent operation will be described below. When the measuring entity is a piece of software that can be in dormant mode, the means of activating and deactivating it must be defined. When the measurement involves configuration of parameters defining the measurement, procedures and interfaces for configuring those must exist. Depending on the implementation, the measurement system may need to make sure that the measuring entity is operating correctly. This can be implemented, for example, by maintaining a soft state for measurement points, refreshed with periodic messages from the measurement points, or by periodic polling of the elements.

7.7 TRAFFIC ENGINEERING MEASUREMENT INFRASTRUCTURE

231

For measurement based on counters, the ability to store the values of counters in suitable data structures inside network elements is needed. The act of saving the measurement results may involve the computation of estimates such as moving averages. When the measuring entity is capable of issuing notification or alarms to measurement control/analysis system and/or to other network elements, the receivers of these as well as the conditions triggering them need to be defined. In the general case, the triggering levels or conditions may vary according to the element. If the measuring entity is a part two-point measurement arrangement, it may need to export non-insignificant amounts of data to be processed. Active measurements also increase the network load. The effect of the chosen measurement method to loading level of an operational network domain must be analysed. Additionally, the measuring entity may be capable of activating measurements based on values of predefined conditions being fulfilled in the measurement element – or environment thereof. For example, the measurement point could be instructed to perform a measurement with particular parameters at predefined times. In addition, the measurement point may be able to operate semiindependently so that it activates the measurements according to a predefined schedule, and sends only the relevant part of the measurement data to higher-level measurement control entities. An example of such a system will be provided in Section 7.8.2.

7.7.2

Interface to measuring entity

Important aspects of the interface between the measuring entities and the rest of the traffic engineering measurement infrastructure include the following: • Can the interface export sufficient data volumes? • Are they standard? If yes, the same interfaces may be used to measurement equipment from many vendors. On the other hand, some measurement needs may be specialized, having no standardized solution to them. • Is the protocol used for transporting measurement results reliable? If yes, reliability needs not be implemented on the measurement application level. The other side of the coin is that

232

• • • •

MEASUREMENTS

packet loss or corruption (where applicable) may give rise to retransmissions and subsequent variable delays. Can measurement results or notifications be sent to multiple receivers simultaneously? What is the prioritization of measurement messages with respect to other traffic in a production network (relevant for DiffServ)? Is there an alternative plan for a case in which the primary report receiving element is unable to receive the measurement results? How much configuration is needed to set up the measurement infrastructure? Can some sort of auto-configuration be used, for example using anycast mode of IPv6?

The interface to the measurement point itself may depend on the actual measurement details. From the point of view of performance monitoring for traffic engineering reasons, the raising of abstraction level is desirable. This is especially true for service quality level monitoring. The goal then is to obtain the same kind of performance data, or different aspects of the data, with different methods, whether they are active measurements, passive measurements or per-element counters. This can be achieved through modelling in the analysis system, or with an abstraction layer isolating the measurement analysis from the actual measurement method. An example of this will be given in Section 7.8.2. The abstraction layer, when used, can be used to schedule measurements, so that the performance measurement function above it only sees the results of combined measurements.

7.7.3

Measurement control and analysis function

The entity controlling the traffic engineering measurements, analysing the results, and providing input for network optimization is called the measurement control and analysis function here. The generic functions are listed below. Measurement control is in charge of configuration of measurement entities. The identities and capabilities of the individual measurement entities need to be known. The measurement control entity must know which measurement entities need to be activated – and when – to obtain particular performance data. Measurement control entity must also know which measurement entities are functioning correctly. Using

7.7 TRAFFIC ENGINEERING MEASUREMENT INFRASTRUCTURE

233

modelling function, it can make decisions on what to do if a particular measurement entity is dysfunctional; could the particular measurement type relating to the measurement entity be replaced with another kind of measurement for example. Measurement control is also responsible for overall scheduling the measurement, although the individual measurements may be scheduled in an abstraction layer, or in the measurement entities themselves. The measurement analysis function must be able to receive measurement results and to know their abstraction level (protocolspecific counters, flow statistics, traffic aggregate measurements, or service-level measurements) and the object they pertain to. The measurement results may be in the form of data structures resulting from “normal” operation of measurements, or notifications of predefined conditions being met in the network. In the latter case, a dedicated function may be needed to process the results more quickly than in the former case. As was previously mentioned, in the case of two-point passive measurements, the amount of data transferred from the measurement points is an issue to be checked. The measurement analysis includes a processing entity that is able to do some amount of data modelling and/or thresholding. With data modelling, abstraction of service level performance is possible from results obtained with different measurement methods. Data modelling is necessary for the traffic characterization task. Some examples of data modelling are: • Monitoring link utilization variations. These can be derived – for example – from queuing theory using anticipated service deployment scenarios. • Monitoring burstiness of flows or aggregates. This could be useful to study accumulation of burstiness in the network. Conformance to token bucket regulator can be used here. • Monitoring metrics of periodic real-time flows such as multimedia conformance or streaming. The amount of jitter has relevance to end user experience and can be modelled using queueing theory. • Monitoring the properties of traffic aggregates. Measured protocol distribution can be compared to the expected one, and measured throughput can be contrasted with planned values.

234

MEASUREMENTS

• Service quality can be compared with the values used in endto-end planning. Thus, the model used for benchmarking the result can be the same as was used in planning. The storage of measurement results can be important, especially when there are many uses for the measurement results (e.g., multiple analysing elements). As discussed in [LCT + 02], polling network elements for data using SNMP may fail at times of congestion. A possible partial solution to this problem is a Lightweight Directory Access Protocol (LDAP)-based centralized measurement data repository for making the results that have already been fetched from the measurement entities available for subsequent analyses. In case measurement control and analysis system is separate from element management system, an interface to the management system is needed. It is possible that notifications and alarms need to be conveyed over this interface. The remaining part of the list of traffic engineering measurement tasks is the performance optimization. This can be viewed as taking measurement results as input, and providing information about the way – if any – the system configuration should be changed as output. Thus, to carry out the performance optimization, the appropriate entity needs to know the expected performance of the system. The system level modelling can be part of the network planning and optimization function, and should be able to provide data modelling level criteria for triggering network optimization. Possible events leading to network optimization are: • Service quality targets are not met. As discussed in the previous chapter, the performance criteria may be specified in SLA for customers, SLA for other network or service operators, or SLA for internal use of the network operator. • The business goals of the network operator are not met. This conclusion can be reached by obtaining network measurement data with revenue models and other relevant business data. A tuning of network parameter may lead to an increase in the utilization level of the network while maintaining the service quality levels specified in SLAs. As was discussed previously, performance optimization may partly overlap with the traffic engineering process.

7.8 INTERNET SERVICE QUALITY MEASUREMENT ARCHITECTURES

7.8

235

INTERNET SERVICE QUALITY MEASUREMENT ARCHITECTURES

Internet service quality measurement architectures have been developed on a conceptual level, for example, as a part of the QBone exercise, and several demonstration systems have been cited in the research literature [MBB00, MC00, CDF + 00, Rai01]. An example of performance measurement architecture in use has been reported in [FGL + 00]. Here, the measurement part of the QBone system and a measurement demonstrator developed at Nokia Research Center are reviewed by way of examples.

7.8.1

QBone measurement architecture

As defined on the QBone website, QoS measurements are an integral part of the QBone architecture. Measurements in QBone terminology mean metrics collected at the ingress and egress points of QBone domains (Figure 7.3). In addition to this required function, measurements can be performed inside domains as well as endto-end as necessary. An architecture called QBone Measurement Architecture (QMA) is proposed for the purposes of verifying the service goals of QBone Premium Service (QPS) as well as aiding provision, and having loss and delay variation as central characteristics of interest. For provision purposes, instantaneous EF load on egress links is compared to reserved load. Both active and passive measurements can be used.

QBone domain 2 M M QBone domain 1

M M QBone domain 3

Figure 7.3 The location of measurement points (M) in QBone architecture  Internet2 QBone Source: From [QBA02]

236

MEASUREMENTS

Link bandwidth

EF commitments (contracted capacity)

EF reservation load

EF load

Figure 7.4 The concepts used in QBone bandwidth measurements  Internet2 QBone Source: From [QBA02]

The following explanation is quoted from [QBA02]. [Figure 7.4] shows the definitions used to measure the capacity and bandwidth of a link. The link bandwidth is the total bandwidth of a given link, in bits per second. The contracted (EF) capacity or EF commitment is the total fraction of link bandwidth contracted to Premium service in bits per second. Reservation load is the current bandwidth of the link reserved for EF. This ultimately will be dynamic. The reservation load is the result of reservations made through bandwidth brokers, and is less than or equal to the EF commitment. For the initial phase of the QBone, the reservation load should be static and equal to the EF commitment. Finally, the EF load is the link bandwidth actually used by EF-marked packets, in bits per second. This will always be less than or equal to the reservation load. QMA divides measurement metrics into three classes: required, suggested, and future ones. Each domain must implement required metrics, whereas implementation of suggested metrics is


237

desirable. The details of the measurement concept for metrics belonging to the “future” may not be known yet, or the need for them may not be fully clear. The present suggested categories are given below. Items may be moved from suggested to required metrics and from future to suggested metrics as the understanding of required function evolves. Required metrics include: • • • • • • •

one-way packet loss one-way delay variation routing information link utilization link bandwidth per-interface EF commitments EF reservation load.

Active measurements, passive measurements, and SNMP polling are listed as ways of measuring required metrics. It is suggested that packet loss and delay variation measurements be made for supervision purposes continuously, using low bit-rate active measurement streams. Routing information is suggested to be obtained using traceroute, with smaller frequency as compared with active measurements. Suggested metrics include: • EF and BE interface packet discards • one-way packet delay • burst throughput for EF and BE. The last item in the list is said to be useful for verifying that policing works as expected. Future metrics include: • routing metrics • application-specific metrics. The explanation below is cited from the QBone website: Routing metrics may be derived from routing protocols themselves, such as autonomous system (AS) path stability,

238

MEASUREMENTS

and may be useful for understanding the sensitivity of inter-domain QoS reservations to routing and for designing signaling protocols and resource allocation algorithms to cope with route changes. Application-specific metrics are metrics that indicate how well applications would perform over specific paths. The application-specific metrics envisioned so far fall into two types: derived and active end-toend. In the first case, application-specific metrics could be derived from “network base metrics”, such as loss and delay variation. Thus, they would take the base metrics and produce some indication of a benchmark application’s performance (e.g. MPEG-1 picture quality). In the second case, application-specific metrics could consist of minimal applications themselves: something that one runs, perhaps at two endpoints, and that gives an indication of how well the application of interest would perform. The QBone website text then goes on to discuss practical arrangement of measurements. It is suggested that active measurement points (probes) – acting both as sources (senders) and sinks (receivers) – have direct interfaces to boundary routers. Passive measurement probes operate on traffic on interdomain links. Agents providing SNMP polling interface can be used anywhere in the network. Figure 7.5 shows an example measurement arrangement. Active measurements AM probe Intra-domain premium path

PM probe


MIB-based statistics Boundary router Inter-domain premium path

PM probe


Figure 7.5 An example set-up of measurements in the connection of a boundary router in QBone  Internet2 QBone Source: From QBone website and [QBA02]


239

Next, measurement paths are discussed. The measurement points participating to performance evaluation of paths are required to perform measurements for all paths ending at ingress or egress nodes of the neighbouring domain. Thus, for path measurements, measuring domains is part of the required QBone function (see Figure 7.6). The QBone website provides more discussion on the metrics, related to which only a few notes are made here. It is suggested, but not required, that measurement points be synchronized to a Universal Coordinated Time (UTC) clock. “Small EF aggregates” should be reserved for active measurement streams, to which active measurements shall conform. Active measurements for delay and packet loss are derived from IPPM working group documents. The time-out of waiting for a packet in a delay or loss measurement is specified to be two minutes ore more. For Poisson-type measurements, the parameter value λ = 2 times/second is specified. EF and BE loss measurements should be done simultaneously to obtain data of the interrelation of the two characteristics. DSCP of the packet shall be set in accordance to the measured aggregate. Instantaneous packet delay variation (IPDV) is based on the definitions of the IPPM working group, and on the ITU-T specification [I380]. Measuring IPDV does not require synchronized clocks. It is specified that packets should not be fragmented. The time-out for IPDV is specified to be two minutes, as for delay and loss measurements.

QBone domain 2 M M QBone domain 1

M M QBone domain 3

Figure 7.6 An illustration of measuring all the routes terminating at ingress/ egress routers of a neighbouring QBone domain  Internet2 QBone Note: The border router of QBone domain 1 is required to perform active measurements to both the closer and the further border routers of QBone domain 2 Source: From [QBA02]

240

MEASUREMENTS

Traceroute measurements for EF and BE should be taken along the same paths which were used for active measurements. The capability of traceroute to set DSCP is required. Traceroute should be run on hosts directly connected to the border routers of each QBone domain. The recommended frequency of performing traceroute is once per ten minutes or less often. Possibly lack of support for DiffServ-specific measurements in MIBs is recorded as a potential problem for passive measurements. Load measurement for EF and BE should be performed at least once a minute, and to provide information on offered traffic, in bytes, in each class during the measurement period. The measurement periods for EF and BE should be simultaneous. Link overheads are ignored in the measurements. Either counter-polling or an external device can be used for load measurement. The following required provision metrics are listed:

• Link bandwidth. • EF commitment. This is the maximum EF reservation load at QBone domain ingress, measured in IP bits per second. • EF reservation load. This is a dynamic version of the EF commitment, and can be adjusted by a bandwidth broker, for example. It is noted that these characteristics will probably be configured manually, but could be automated later, for example, using bandwidth brokers. The provision metrics are measured upon the startup of the network element in question, upon start-up of the measurement system, or upon upgrading of the network element. An example of another type, an EF commitment is measured when the relevant QPS SLS changes. The measurements should be timestamped. EF and BE loss may be measured per interface. Per-DSCP loss measurement may require extending basic MIBs. The measurements should be performed simultaneously with other measurements to the greatest extent possible, to obtain as complete information as possible, and to reduce polling load. Burst measurements at 50%, 100%, and 150% of the reserved peak rate are proposed for EF. It is proposed that such tests are performed at least once a week to check the coordination of border routers. A proposal for the measurement result presentation format is provided for the purpose of making measurement result reporting uniform. It is specified that each QBone domain must have a


241

website presenting the results of measurements made within the domain. The text then defines canonical names, types and units for reporting purposes (Table 7.3). Further, the parameters of the measurement are specified, consisting of duration, summary interval, and summary function (e.g., mean). All reporting periods start at midnight UTC, and measurement reporting must be accurate to within 100 ms to the UTC clock. Three types of reports are listed: • image report; • HTML report; • text-format report. The required reports, as well as the summary intervals and summary functions are listed in Table 7.4.

7.8.1.1 Discussion The QBone measurement architecture includes useful concepts for implementing a multiservice infrastructure for measurements across domain boundaries. Due to the selected basic QBone service quality support scheme, useful concepts relate to the measurement of DiffServ particularly. The requirement to maintain a publicly available repository of per-domain measurement results is against the current mindset of inter-domain operations. It will be interesting to see whether this kind of thinking will find its way to mainstream commercial networking.

7.8.2

Nokia Research Center measurement architecture demonstrator

An Internet measurement architecture developed at Nokia Research Center [Rai01] is shown in Figure 7.7, consisting of a QoS Agent (QA), measurement control points (CPs) and actual measurement points. One of original goals for devising the architecture was to study the connection between measurementbased network quality supervision, and admission control. Traffic engineering was not within the original scope of the project. In this sense, the demonstrator architecture belongs squarely to the traffic engineering measurement category, including “traffic control” aspects.

242

MEASUREMENTS

Table 7.3 Canonical names and units for QBone measurement reporting  Internet2 QBone Canonical name

Metric

Data type

Units

efPathLoss

EF Path Loss

Comma-delimited unsigned integer tuple (e.g. “100, 92”)

EF (packets sent, packets received) per 1 minute

bePathLoss

BE Path Loss

Comma-delimited unsigned integer tuple

BE (packets sent, packets received) per 1 minute

efInterfaceLoss

EF Interface Loss

Comma-delimited unsigned integer 4-tuple

EF (packets sent, packets received, bytes sent, bytes received) per 1 minute

beInterfaceLoss

BE Interface Loss

Comma-delimited unsigned integer 4-tuple

BE (packets sent, packets received, bytes sent, bytes received) per 1 minute

EfDV

EF Delay Variation

unsigned integer

Microseconds

EfLoad

EF Load

unsigned integer pair

bits per second, packets per second

BeLoad

BE Load

unsigned integer pair

bits per second, packets per second

EfTrace

EF Traceroute

string of dot-notated, comma-delimited IP addresses (e.g. “a1.b1.c1.d1, a2.b2.c2.d2, . . .”)

NA

BeTrace

BE Traceroute

string of dot-notated, comma-delimited IP addresses (e.g. “a1.b1.c1.d1, a2.b2.c2.d2, . . .”)

NA

LinkBW

Link Bandwidth

unsigned integer ordered pair

bits per second, timestamp

EfCom

EF Commitment



EfRes

EF Reservation Load



Source: From [QBA02].

5 minutes

5 minutes

5 minutes

5 minutes

bePathLoss

efInterfaceLoss

beInterfaceLoss

Summary interval

of EF packets lost

(continued overleaf )

timestamped beInterfaceLoss 4-tuples

None

percentage of BE packets lost percentage of BE bytes lost

5 minutes 5 minutes

timestamped efInterfaceLoss 4-tuples

None

percentage of BE bytes lost

percentage of EF bytes lost

5 minutes

percentage of EF packets lost

timestamped bePathLoss tuples

None

5 minutes

summed bePathLoss tuples

timestamped efPathLoss tuples

None

5 minutes

summed efPathLoss tuples

Summary function

5 minutes

Summary interval

percentage of BE packets lost

percentage of EF bytes lost

percentage

percentage of BE packets lost

percentage of EF packets lost

Summary function

File reports (*.txt)

Required QBone measurement reports  Internet2 QBone

Image report (*.gif)/Page reports (*.html)

efPathLoss

Metric

Table 7.4

7.8 INTERNET SERVICE QUALITY MEASUREMENT ARCHITECTURES 243

5 minutes

optional

optional

24 hour

24 hour

24 hour

beLoad

efTrace

beTrace

linkBW

efCom

efRes

Source: From [QBA02].

5 minutes

mean EF reservation in bps

mean EF commitment in bps

link bandwidth in bps

sum of BE bps

24 hours

24 hours

24 hours

timestamped raw traceroutes

mean EF reservation in bps

mean EF commitment in bps

link bandwidth in bps

raw 1 minute BE load measurements (no timestamps needed)

None

timestamped raw traceroutes

sum of BE bps

raw 1 minute EF load measurements (no timestamps needed)

None

5 minutes

sum of EF bps

Summary function

File reports (*.Txt)

5 minutes

5 minutes

milliseconds of IPDV at the 99.5th percentile

5 minutes

sum of EF bps

5 minutes

milliseconds of IPDV at the 90th percentile

5

minutes

5 minutes

milliseconds of IPDV at the 50th percentile

Summary interval

(continued )

5 minutes

Summary function

Image report (*.Gif)/page reports (*.Html)

Summary interval

efLoad

efDV

Metric

Table 7.4

244 MEASUREMENTS


245

CPS Network / route / AN status

Policy store QA

Route QoS reports QA2

CP1

CP2

CP3

Raw QoS data

Figure 7.7 Service quality demonstrator architecture Source: From [Rai01]

The CPs provide an abstraction layer between QA and the measurement infrastructure, making it possible to isolate actual measurement methods from the measurement control and analysis function (QA). QA configures measurement parameters into CPs, which then schedule the actual measurements autonomously. After performing the measurements, CPs communicate per-route measurement data to QA, which carries out data modelling as explained below. Based on the reports, QA can then provide alarms and warnings to other network elements as necessary. In Figure 7.7, communication of QA with a call processing server (CPS) is shown. The demonstrator does not address traffic characterization directly. The parameters configured by QA into CPs include the frequency of measurements and parameters to be used in a single measurement. Once a CP has been configured with the parameters, it schedules measurements automatically and reports the results back to QA. QA may also suspend measurements in a CP, activate or reactivate suspended CPs. Robustness has been implemented in the form of back-up QA, into which all reports are automatically redirected if primary QA cannot be contacted. QA maintains soft state for CPs: if reports have not been received for a predefined period of time, CP is marked as temporarily unavailable. The QoS agent implements the following functions: • Management of measurement infrastructure (add/delete measurement points, suspend/continue measurements in a CP). • Configuring measurement parameters in CPs.

246

• • • •

MEASUREMENTS

Receiving reports from CPs. Performing modelling based on reports. Communicating results to other network elements. Reading QA configuration from a policy store.

The details of measurement parameter configuration depend on the measurement method used; a case study specific to active measurements is described below. Information common to all methods is the frequency of measurement and the location of measurements. CP needs not be co-located with actual measurement entities. The form of reported QoS data may also be configured. For instance, QA may configure a number of QoS classes into CPs, with CP transmitting only QoS classification to save bandwidth. In this case, QoS class limits are defined for delay, delay jitter, packet loss percentage, and loss correlation. After a measurement, a CP returns a classification for each of the four quantities. Alternatively, a “full” QoS report may be transmitted, consisting of numerical estimators for delay, delay variation, packet loss, and packet loss correlation. QoS modelling used in the demonstrator is based on computing per-route QoS averages. In computing the averages, discrete time exponential moving average is used, i.e.: Et = αXt + (1 − α)Et−1 ,

(7.1)

where Et is the value of the estimate at time t, Xt is an estimator for value of the observable at time t and α is a coefficient that sets the time scale of moving average. By computing estimators with multiple values of α, averages at different timescales can be used for simple trend analysis. Note that the functional form of exponential averaging is formally similar to that of the “recency effect” mentioned in Chapter 2. There are many ways of representing QA data, depending on the format of reports transmitted from CPs to QA. When only a classification of characteristics is reported to QA, a graphical history view of performance class is provided to a monitoring user. Another – not necessarily mutually exclusive – possible user interface, delay quintiles can be saved and plotted to study delay variations. In its communication with other network element (if present), QA can operate in several modes. Three examples are shown below:


247

• “Intelligent filter”. QA passes per-route data averages to a network element performing previously configured filtering for the incoming data. • “Baywatch”. Provides warning and alerts to another network element based on configured profile. • “TRM ”. Provides authoritative information relating to admission control. In this mode, the TRM can be viewed as a “bearer manager”. The configuration of QA is based on a local policy store. An external network element, such as a CPS or network management system (NMS) can configure QA by modifying the policy store contents and instructing QA to reread its configuration file. This in turn causes the eventual reconfiguration of CPs and is subsequently reflected as changed parameters in the measurements. The demonstrator measurement architecture was based on active application-level measurements for VoIP. In practical terms this means that QA configures to CPs, parameters corresponding to some realistic codec such as AMR, GSM, G.723.1, or G.711. Other parameters include the duration of the measurement and the temporal separation of the measurements. Off-the-shelf i686 PCs and NICs were used as measurement hosts. A measurement host may participate in measurements on several routes. For each route, a measuring process is created in the host. In our tests, even a low-end 100 MHz Pentium PC could handle up to 30 simultaneous measurement streams. The number of streams handled by a single measurement point can be expected to be much smaller than this. The measurement program used by us performs one-way delay measurements for hosts running Network Time Protocol (NTP or other suitable synchronization mechanism). The IP protocol version is automatically detected, and IPv4 is used if IPv6 is not supported at both ends. The measurement program also supports setting of flow label and traffic class in IPv6. The latter is useful for verifying DiffServ performance.

7.8.2.1 Discussion The Nokia Research Center demonstrator was a simple set-up to test the basic ideas. The implementation of the demonstrator in IPv4/IPv6 environment was straightforward, consisting of a few

248

MEASUREMENTS

thousands of lines of socket programming C code in standard Linux environment. The implementation of measurement points as Linux processes that could be activated in any Linux network server was found to be a promising idea. The second good aspect of the chosen architecture is the possibility of reducing the amount of measurement data sent between measurement points and QA. The management of the measurement points and CPs by the QA in a real-world deployment would require careful planning, and was not properly addressed in the simple demonstrator. The demonstrator was designed for a specific purpose – measurement-based admission control using active measurement – but could also be used for service level monitoring more generally, including traffic engineering purposes. The intermediate “control points” in the architecture can be used to isolate the actual measurement scheme, and to remove the need of high-level measurement control to expressly schedule measurements.

7.9

SUMMARY

The main uses for measurements are traffic characterization, network monitoring, and traffic control. Traffic characterization is needed for traffic engineering purposes to understand what kind of traffic is transported in the network. Similarly, network monitoring is required by traffic engineering process to verify the service levels in a production network, as well as for detecting faults. Traffic control, on the other hand, can include components that are part of the full traffic engineering loop – including network reconfiguration of multiple network elements – as well as tasks that are more directly related measurements, such as providing information to measurement-based admission control. The “full” traffic engineering loop typically requires network modelling, whereas the other part of traffic control can be based on pre-programmed responses to measurement results. Measured characteristics, sources of measurement data, measurement methods and the necessary measurement infrastructure were discussed. Two examples of measurement architectures were quoted: QBone measurement architecture and a demonstrator from Nokia Research Center.

7.9 SUMMARY

249

The QBone measurement infrastructure implements multiservice inter-domain measurements relating to QBone service support classes. The Nokia Research Center demonstrator was made originally for studying MBAC for active measurements, targeting VoIP applications. It can be generalized to other measurement methods, too. The architecture addresses automated scheduling of measurements, and optimization of measurement result traffic volumes.

8 Mechanisms for Dynamic Service Quality Control The means of dynamically controlling service quality in IP networks is our next topic. There are two primary uses for such methods: dynamic control of resources within an IP domain, and implementation of dynamic SLAs between domains. The generic element handling both of these tasks is often called the “bandwidth broker” (BB), and this convention is followed also within this book. Admission control or service quality instantiation control is not part of the basic DiffServ framework [RFC2475]. Subsequently, the need for IP service quality support mechanisms for DiffServ networks other than edge provisioning and per-hop prioritization mechanisms in core networks has been widely acknowledged [RFC2638, Sch98, THD + 99, TAP + 01, JC01, SAF + 01, TIPHON-3]. The basic reason for the need of dynamic perdomain service quality control mechanism is the following: up to a limit, service quality for critical service types can be provided by mapping them to a proper service quality support aggregate such as EF. This works because of the prioritization mechanism of DiffServ. Alas, when there is too much traffic within the EF PSC, the flows sharing the PHB begin to suffer. The effect of EF PHB to other PSCs within the router can be controlled by using rate limiters, but basic DiffServ framework does not provide tools for


252

MECHANISMS FOR DYNAMIC SERVICE QUALITY CONTROL

dynamic control within the aggregate. Similarly, the quality in AF PSCs suffers from too many service instances trying to share them. The end-user SLAs at the edge of the network are imposed by policing of traffic at the edge of the DiffServ domain. As we saw in Chapter 3, policing requires that adequate DiffServ classifier be placed at the edge of the network. With statically configured DiffServ classifiers only, it is not possible to perform dynamical resource control. Basically, two techniques can be used to improve on this: • Admission control to existing classifiers. In this case, the classifier can be per endpoint IP address, per prefix, or per traffic aggregate. This requires that there is an extra-DiffServ means of blocking flows. • Installment of Diffserv classifiers on demand. For the latter alternative, using of outsourced policy model is an enabling technology from the control architecture point of view [LV02]. Obviously, in addition to the machinery to distribute the classifiers, there has to be a policy existing as to when to limit service quality instantiation and intelligence to create the actual DiffServ classifiers. Per-domain Bandwidth Broker (BB) is a potential tool for taking care of the former task, and for providing the data for the second task. Recent examples of application of bandwidth broker to manage the network resources in multi-service IP network domain can be found in [Lak02] and [MNV02]. In the former, the emphasis is on the algorithms used for controlling resources, whereas in the latter, also an architecture for management is needed. Between the domains, being limited solely to static SLAs limits the level of efficiency of network use that can be reached. This is basically due to statistical multiplexing of flows in traffic aggregates. If the SLA between two operator specifies that the delays and packet losses have to be within certain range, it may be beneficial for a transit network operator to make dimensioning based slightly on conservative multiplexing calculation. If the operator could indicate to the business parties of momentarily available extra capacity, this capacity could be utilized. This can be viewed as an enabling technology for the brokertype market models discussed shortly in Chapter 5. Another potential use of automated inter-domain communication between


253

bandwidth brokers is implementing a transport transit service, which performs admission control in the access domain solely based on inter-domain bandwidth availability information. This is one of the models discussed in end-to-end ETSI EP TIPHON service quality support model [TIPHON-3], and has been analysed in detail by Schelén [Sch98]. A bandwidth broker controlled DiffServ domain can also interface to a 3GPP domain with suitable interworking arrangements, as discussed in [MNV02]. The basic DiffServ framework is based on the edge provisioning principle, where policing and marking of traffic at the network edge are the determining components for per-flow quality support. Using bandwidth brokers, per-flow service quality in DiffServ can be made more closely integrated with the resource availability situation in the network domains relevant for the transport of individual service instances. The means that can be used to maintain up-to-date information about service quality support are discussed in Section 8.2.2. Policy-based management is one way of implementing control of service quality instantiation, others being discussed further below. On an architectural level, at least the following schemes are possible to implement end-to-end support for service quality when multiple transport domains (ADs) are involved: • One or more service providers take care of providing transport resources for their own services, where transport resources may be under control of separate transport operators. The transport operators may obviously be used by other parties as well. The provision can be SLA-based. This is one of the scenarios analysed in the ETSI EP TIPHON QoS control reference model [TIPHON-3]. • Separate per-element entities handle dynamic service quality control based on transport service quality support resource availability. This is the bandwidth broker model analysed in [RFC2638, Sch98, THD99], to name but a few sources. • Hybrid model. In this approach, bandwidth brokers are used by providing up-to-date service quality support resource availability information to service providers. The two first models are illustrated in Figure 8.1 and Figure 8.2. Note that in the first case, the correspondence between service providers and transport domain does not need to be one-to-many.

254


Service domain

Transport domain 1

Transport domain 2

End system

End system

Figure 8.1 An example of end-to-end provisioning on service layer Note: The media stream requiring service quality support is drawn in the thick line, signalling of end systems with service domain in the thin solid line, and interaction of service provider with transport domains in the dotted thin line

BB

Transport domain 1 End system

BB

Transport domain 2 End system

Figure 8.2 An example of end-to-end provisioning performed by per-domain bandwidth brokers (BB) Note: The communication to bandwidth broker and between bandwidth brokers is drawn in solid thin lines, communication of BBs with transport domains in dotted thin lines, and user traffic in the thick black line

Regarding the two basic scenarios, the present chapter is primarily concerned with service-independent resource management. As was mentioned in the previous chapter, it is also possible to make a link between bandwidth broker-type entity and service admission control. We shall discuss this topic further in Section 8.2.4. Let us next have a look at existing studies on bandwidth brokers, and then formulate a generic framework for application of bandwidth broker in the context of multi-service DiffServ network domains. The present chapter will be concluded with a summary.

8.1

PREVIOUS STUDIES

Other bandwidth broker architecture models have been studied in the TEQUILA project [TAP + 01], the AQUILA project [MNV02],

8.1 PREVIOUS STUDIES

255

the GARA Application Programming Interface (API) model [SAF + 01] and other sources [JC01], to give examples. The technology repertoire analysed in these studies includes SLS negotiation, DiffServ, and MPLS. For the purposes of the present book, we will concentrate on intra-domain and inter-domain resource management in DiffServ specifically. MPLS is considered to be a traffic engineering technique that is used by the policy management to optimize the resource usage within a network domain, and as such is not directly related to bandwidth brokers. The information supplied by the bandwidth broker, of course, can be used by the policy management system as input in optimizing the domain resources. In what follows, the IETF two-bit DiffServ architecture, the QBone bandwidth broker architecture, and Schelén’s funnel concept are discussed.

8.1.1

Two-bit DiffServ architecture

The “two-bit” DiffServ architecture described in [RFC2638] has been designed to support two service models, namely the “assured service” and “premium service”. The two-bit architecture basically accommodates both EF PHB and AF PHB groups within the same DiffServ network domain. The assured service, akin to the AF PHB group, provides statistical guarantees for in-profile traffic. The second service model, EF-like, is based on prioritization of “premium” flows with respect to other traffic in the network. In accord with the DiffServ framework, both service models make use of traffic conditioning at the edge of the domain. Thus, the two services are not in contrast with the AF and EF PHBs reviewed in earlier chapters. Implementing both services requires configuration of appropriate filters at the edge of the network to correspond to the required services. Referring to a case of a company with multiple users, the authors of [RFC2638] propose a bandwidth broker as an entity into which organizational policies can be configured, and which can use these – together with the knowledge of existing connections – to make classification decisions for service instantiations. The reference model is based on requesting the decision for new flows from the bandwidth broker. The function of a bandwidth broker – as defined in [RFC2638] – is twofold:

256


• Keep track of traffic allocations in the domain the resources of which it is responsible for; and configure edge routers accordingly. • Manage resource allocation messages sent to other domains. Related to the first of these tasks, a bandwidth broker is responsible for receiving and authenticating resource allocation requests, each consisting of service type, target rate, maximum burst size, and of time period for the service. For admitted requests, network elements may need to be configured in the domain the bandwidth broker is responsible for, or a bandwidth broker in another domain may need to be contacted. In [RFC2638], it is suggested that perflow configurations in edge routers be of soft-state type – that is, they need to be refreshed periodically in order to stay valid. The bandwidth broker concept of [RFC2638] has been used in the QBone bandwidth broker architecture, which is our next topic.

8.1.2

Bandwidth broker in QBone architecture

The QBone architecture [THD99, QBA02], aimed at being a basis for bringing service quality support to the Internet, has been discussed several times in the previous chapters. The architecture is based on DiffServ, and subsequently the following goals and constraints for intra- and inter inter-domain QBone resource management solution have been put forth: • Aggregation of flows into aggregates (basic DiffServ principle). • The minimum requirement for interoperation between operators is capability of making bilateral SLAs. • The flexibility for per-domain resource management should be maximized. The target has been to make the inter-domain resource management scheme of QBone consistent with the DiffServ approach. The QBone bandwidth broker, in general, can interface to different types of network elements, including other bandwidth brokers, routers, application servers, end systems, and network operators [QBB02]. The interfaces are illustrated in Figure 8.3. The second boundary condition for the QBone inter-domain solution is the set of services provided. The flagship service is the QBone Premium Service (QPS). An instantiation of QPS requires a number


257

Adjacent BB

Adjacent BB

Inter-domain Application server

User/host

Network operator

PM iface

User/App iface

‘‘Simple’’ policy services

Data store

NMS iface

Routing info Intra-domain

Edge router(s)

Edge router(s)

Figure 8.3 The interfaces and internal structure of a QBone bandwidth broker  Internet2 QBone Source: From [QBB02]

of parameters to be specified between the service providers and the customers. The parameters are: • • • •

start and end times; source and destination; MTU size; peak rate.

The following unidirectional guarantees are provided to service instances using QPS service quality support: • No loss due to congestion. • No latency guarantees. • Worst-case jitter bounds (IPDV) except in the case of IP routing changes. The above guarantees can be implemented by providing sufficient resources for all momentary QPS aggregate loading situations on all links, but allowing for queueing in routers. In the QBone parlance, a bandwidth broker is a recommended entity (“oracle”), responding to admission requests for network

258


resources in a QBone domain. These requests, called Resource Allocation Requests (RARs), may be made by an element from the domain under the control of the bandwidth broker in question, or by a peer bandwidth broker. The bandwidth broker responds to RARs with a Resource Allocation Answer (RAA), constituting either a confirmation or denial of the request. Specifically, it is the task of a QBone bandwidth broker to make sure that the SLSs with peering QBone domains are fulfilled. Tracking the admitted connections and SLSs established with peering domains are identified as means of accomplishing this task. The possibility of involving policy decision and enforcing points in the process is mentioned. An admitted service instance may lead to a need to reconfigure policing rules in boundary routers of neighbouring domains. An example of allowing temporarily 10 Mbit/s of traffic instead of 1 Mbit/s is given. Further, the possibility of making traffic conditioning dependent on routing is mentioned. Presumably bandwidth broker is a seen of a technology enabler for dynamic policing in this context. Three protocol interface classes are discussed: • User/application protocol. This interface carries the RAR and RAA messages. Requests can be performed by humans, or are carried between automatic systems using a protocol such as RSVP. • Intra-domain protocol. This is used for element configuration. COPS, Diameter, SNMP, and vendor-proprietary interfaces are listed as examples of protocols for this interface. • Inter-domain protocol. Bandwidth broker peering makes use of this interface. Relevant data interfaces include: • Interface to routing tables. The bandwidth broker needs to know the up-to-date routing topology of the DiffServ domain to be able to handle resource management. Routing may change for the reasons discussed in Chapter 4 and Chapter 5. • Interface to data repository. Data stored in the repository include SLS information, reservations, router configurations, service/service quality support aggregate mappings, NMS information, monitoring information, and other policy interface. In the draft QBone bandwidth broker architecture outline [QBB02], two implementation phases of bandwidth broker have been


259

described: phase 0 and phase 1. These will be described in the following.

8.1.2.1 Phase 0 bandwidth broker End-to-end service level assurance in the architecture corresponding to Phase 0 is based on static SLSs between neighbouring QBone domains. A phase 0 bandwidth broker does not perform signalling to peer brokers in other QBone domains. Between the network elements and the bandwidth brokers of the source and destination domain, a protocol for performing RAR/RAA signalling is assumed. This protocol can also be of non-automated form, for example, a telephone call to a human responsible for resource allocation of the domain. The end-to-end resource management is proposed to be handled by a Bandwidth Czar, to which/whom traffic demand matrix is communicated by per-domain bandwidth brokers – by their operating system running on carbon or silicon hardware. The Czar makes appropriate requests for resources in transit domains. At minimum, phase 0 bandwidth broker does not differ very much from “statically” provisioned network domain with SLAs towards the end users and peer domains. Resource management can be taken care of with the basic assumption of static SLAs, and handling momentary bandwidth needs as special requests. There may be a direct protocol such as RSVP used between the communication endpoints, but it is not assumed to affect the transit domain along the path of the service instance.

8.1.2.2 Phase 1 bandwidth broker Phase 1 bandwidth broker addresses two new questions: that of automated communication between peer bandwidth brokers on the one hand, and that of performing automated end-to-end reservation set-up. The latter also includes the task of setting up adequate service quality support in access networks. In Phase 1, SLSs are assumed to be already established – pairwise – between DiffServ domains that are participating in the phase 1 bandwidth broker scheme. Dynamic SLS negotiation was defined to be outside of the description of the functions of basic bandwidth broker. Bandwidth brokers are assumed to be able to

260


signal directly also to peer brokers in non-neighbouring domains. Further, globally known service types are assumed. The mapping of services to DSCP markings is defined separately for each domain. DiffServ interworking on DSCP marking level is not part of the QBone phase 1 scheme. Three different cases are analysed: 1. An end system requests service to a fully specified address. 2. End system or bandwidth broker requests service to a destination prefix (domain). 3. Bandwidth broker receives a request for fully specified destination and uses an aggregate for satisfying the request. In the first case, end-to-end signalling is implemented by pairwise exchange of messages between logically adjacent entities. The actions taken by the bandwidth broker in the originating, transit, and destination domains is analysed in the QBone bandwidth broker document. The full details are not reproduced here, and can be found in [QBB02]. The second case is essentially a request to establish a one-way tunnel between the originating and destination domains. Such an aggregate is called a core tunnel. Tunnels can be requested by end systems capable of aggregating their requests, or by a bandwidth broker. In both cases, intelligent aggregation policy can reduce resource reservation signalling considerably. This kind of aggregation is especially useful when there are many flows to a non-adjacent domain. By aggregating the flows in the transit domain, the need to perform per-flow resource reservation in transit domains is avoided (see Figure 8.4). Only the bandwidth brokers at the end of the tunnels need to be concerned with the actual aggregation of flows. The bandwidth brokers of the intermediate transit domains only deal with aggregated service requests. The mechanism for triggering the establishment of a tunnel is excluded from the discussion in the QBone document. The third case is actually a special use case of scenario 2. In this case, the bandwidth broker handles a fully specified endpoint request internally by performing admission control to an established core tunnel. The difference between doing admission to core tunnel and to an inter-domain SLS is that core tunnels can be set up according to need. The reason for a bandwidth broker setting up


261

Domain D

Domain A

Domain B

Domain C

Figure 8.4 The use of aggregated reservations Note: Between domains A and D, there is a single flow. Between A and C, there are three flows which are aggregated into a joint reservation in domain B

a core tunnel could be simplification of reservation-related bookkeeping both in the originating domain, and in transit domains.

8.1.3

QoS Agents

A specific instantiation of bandwidth brokers called QoS agents have been discussed in O. Schelén’s PhD thesis [Sch98]. Schelén’s scheme uses marking of packets admitted by elements called QoS agents, but DiffServ as such is not required. Ingress policing is part of Schelén’s reference model. A QoS agent is aware of resource availability in the domain under its control, as well towards other domains. For the domain under its own control, the QoS agent is aware of IP topology. A QoS agent can also delegate requests to other QoS agents as necessary. A QoS agent learns the topology for its domain of control by querying the routing table from the routers within that domain. The task is earlier when link-state routing protocols such as OSPF are in use, as querying a single router is then sufficient – naturally assuming that the routing topology is in a stable state. The QoS agent also learns the properties of individual links, such as bandwidths, by querying routers [SP98]. For example, a SNMP interface can be used for this purpose. End systems communicate with QoS agents, requesting either open (undefined duration) or closed (starting and ending time defined) resource reservations. All requests include the bandwidth requested, as well as source and destination address. The requests can be made in a scheduled or immediate manner. Immediate

262


reservations correspond to the normal operation of cellular network, for example, where resources are requested when the connection is initiated. Scheduled, or advance, reservations on the other hand, are akin to reserving Virtual Leased Lines (VLLs) for the communication, where a part of network resources in the domains through which the service instance is routed, is put aside for communications between communicating parties (hosts or network prefixes). Advance resource reservations in Schelén’s thesis are more dynamic than leased lines, however, allowing for reservations to be requested – in advance – for a period of time defined by starting and ending time. QoS agents can aggregate reservations between destinations to minimize signalling. The destinations of the aggregations are network domains, each controlled by a QoS agent. Aggregated reservations between adjacent domains are called funnels in Schelén’s terminology. An end-to-end capacity request consists of a series of funnels. All traffic controlled by a QoS agent destined to the endpoint of the reservation is routed to the funnel, irrespective of the type of the traffic. Admission control is necessary to ensure that the volume of traffic entering the funnel does not exceed its capacity. The traffic from multiple “incoming” funnels can be merged into an outgoing funnel. An example of end-to-end path consisting of funnels is shown in Figure 8.5. Traffic is assumed to be policed at least in the ingress of the network domains. Per-flow policing can be performed in the access domain, and egress policing, when used, can be based on network destination.

QA IP domain Endpoint

QA IP domain

QA IP domain

IP domain IP domain QA

´ Figure 8.5 Funnels in Schelen’s scheme

Endpoint

8.2 GENERIC MODEL

8.2

263

GENERIC MODEL

The bandwidth broker examples discussed above provide building blocks for formulating a common framework for using dynamic service quality control mechanisms both within a domain, and between domains. The bandwidth broker of the two-bit DiffServ architecture processes resource allocation requests within a domain – from end systems – and between domains. To be able to do this, it needs to perform bookkeeping of per-domain resources. Bandwidth broker is also responsible for configuring proper edge treatment for user flows, according to the policy assigned for the user. In the QBone model, the bandwidth broker is responsible for performing service quality support instantiation control into the resources of the domain it is responsible for. A specific focus in the QBone bandwidth broker scheme is providing statistical guarantees for the QPS service quality support class. Additionally, the QBone bandwidth broker is responsible for maintaining SLS commitments towards neighbouring domains. Two deployment scenarios have been defined for QBone bandwidth broker, providing progressively more advanced function. In Phase 0 model, bandwidth broker – not necessarily an automated one – can provide service quality support based on simple admission control to resources within the domain, and to SLA capacity between the domains. Phase 1 bandwidth broker, on the other hand, brings with it the possibility of performing end-to-end service quality instantiation control based on momentary loading situation along the end-to-end path. Schelén’s QoS agent model, the third case analysed, is based on aggregation of service quality support classes between domains. The QoS agents in individual domains can perform admission control to the service quality support aggregates. QoS requests made to end systems are made for particular bandwidth between defined communication endpoints. The requests can be made for certain period of time, or have an undefined duration. The requests can be made in advance, or immediately prior to service quality support is needed. One technical detail relating to resource management under QoS agent’s “own” domain, the QoS agent can listen to OSPF routing messages to have up-to-date knowledge of logical IP topology. Schelén’s model does not require all the elements of the DiffServ framework to be in place, but

264


includes policing of traffic at the edge of the network, as well as marking of packets for which the QoS agent has provided service quality support. The reviewed models include useful components, and are addressing the issues in adding basic service quality instantiation support to DiffServ. There are some additional issues, however, that are desirable for obtaining an end-to-end service quality support of the type that is interesting for the purposes of this book. The most important of these is the inclusion of multiple service quality support classes into the bandwidth broker concept. Second, the link between traffic engineering and bandwidth broker should be made clearer. Related to traffic engineering, two issues are of particular interest: • What is the link between policy management and bandwidth broker? • How can service quality measurements be used by bandwidth broker? In the research literature, several other questions relating to bandwidth brokers have been studied, some of which are heterogeneity of service quality support policies in different domains, individual users not being visible for non-access domains, inter-domain policy dependencies, and issues of scalability [SAF + 01]. Regarding these, the approach adopted in this chapter is as follows: service quality support mechanisms and the way in which policy management is used for resource control are both domain-internal issues. This rids us of the need to discuss the first and third of the items. Regarding the rest, the scalability of admission control or service quality instantiation control is an important issue in all relevant systems, including bandwidth brokers. The scheme adopted in this chapter is based on aggregation of service quality support from the edge router upwards, whereby there is no need to be aware of the properties of individual flows in transit domains. Next, a generic model for dynamic service quality control in an IP domain is presented as an attempt to generalize the models reviewed above. For brevity, the controlling element is called bandwidth broker, and it may be implemented either as a distributed or centralized element. Our generic model consists of the following constituent tasks:

8.2 GENERIC MODEL

265

• Service quality support instantiation control. This task includes only connection admission control related functions. • Domain control. This task includes connecting of traffic engineering type optimizations of IP transport with the data available to the bandwidth broker. • Inter-domain signalling. Communication with peer bandwidth brokers in other domains is a further task of the generic bandwidth broker. These tasks are discussed in more detail below. Additionally, the relations of the presented bandwidth broker concept to service level admission control and traffic engineering are discussed. The generic bandwidth broker discussed below is a logical function, and its function can be distributed into multiple actual network elements within a network domain. Such distributed architectures can be made in many different ways. In the next chapter, we shall encounter a specific example of a bandwidth broker responsible for resources under its own domain.

8.2.1

Service quality support instantiation control

The bandwidth broker of our generic scheme is responsible for service quality support instantiation control. The bandwidth broker is responsible for resources within a DiffServ domain, resources being visible to the bandwidth broker as service quality support aggregates on individual links and on the domain level. The bandwidth broker is aware of IP routing topology consisting of links between routers. A link of the routing topology may actually a link layer tunnel spanning multiple routers. In addition, the bandwidth broker is assumed to be aware of factors affecting service quality support capacity on individual links, such as physical link capacity, and scheduling system configuration in router interfaces. The more details the bandwidth broker has about scheduling in the routers, the better it can utilize the resources of a router. It is not absolutely imperative, however, to have full knowledge or router details. Instead, the bandwidth broker may only know the volume of each traffic type that the router can handle. For example, the bandwidth broker could be aware of the parameters of the EF PHB definition [RFC3246]. Service quality support is requested from the bandwidth broker either by end systems, by service domain control elements,

266


or by peer bandwidth brokers. Listing service domain as one possible user of bandwidth broker services makes it possible to implement the logical separation between service and transport domains [TIPHON-3]. The request mechanism in the bandwidth broker supports at least immediate reservations made as part of service instantiation, but may also advance reservations [FG95, Sch98, LCH01]. The latter function may be useful in implementing dynamic core tunnel/funnel-like temporary reservations between domains.

8.2.1.1 Signalling interface Service quality instantiation request by an end system is of a Request Allocation Request (RAR) type, transferred using a suitable protocol. In the general case, RARs include service quality support requested, flow descriptor, and endpoint identity information (IP addresses). In addition, the bandwidth broker may support the specification of an advance request starting and ending times. From the viewpoint of signalling, service quality support includes the following tasks: • receiving of RARs; • processing of RARs; • communication decision (Resource Allocation Answer, RAA) back to end system. In general, an RAA can be one of the following types: • • • •

accept RAR as requested; accept RAR with downgraded service quality; accept advance RAR for modified period of time; unconditional RAR reject.

The second alternative may not always be implemented. The third alternative is only relevant to requesting service quality support for a particular period of time. The bandwidth broker may propose alternative starting and ending times for the reservations. Also a combination of the second and the third alternative is possible. For service quality support instantiation control, a protocol interface between the end system and bandwidth broker is needed. The interface needs to be able to convey RAR parameters and RAA

8.2 GENERIC MODEL

267

messages. In general, a RAR can include flow specification and QoS requirement specification. For advance reservations, the capability of specifying periods of time is required. If QoS downgrading is implemented, it will be possible to specify the altered QoS parameters and/or periods of time, the latter in case of advance request. RSVP with TSpec and RSpec is an example of such an interface. At the time of writing, the Next Steps in Signalling (NSIS) working group of IETF is in the process of defining a nextgeneration QoS signalling interface. In the end system, an API capable of initiating RARs and receiving RAAs is needed between the operating system and the application. The functions required in the API depend on the range of QoS requests the end system is allowed to make. If most of the parameters are specified by a default SLA, the API can be simple. One example of an API for contacting bandwidth broker is discussed in [SFA + 01]. Inter-bandwidth broker signalling is discussed in Section 8.2.3.

8.2.1.2 Internal bandwidth broker operation The bandwidth broker must have a means of evaluating whether a RAR can be admitted in the requested form, in modified form, or rejected completely. The decision may depend on connection type, as defined in an admission control policy. For this, an interface to the suitable policy store is required. If QoS renegotiation is implemented, the required function in the bandwidth broker is more complicated than for the simple accept/reject case. The basis for making service quality instantiation decisions is up-to-date information about service quality support resources within its own domain, and in domains en route to the requested communication endpoint. The information about resources in its own domain can be obtained by suitable means, including bookkeeping [FG95, Sch98, LCH01] and measurement of link utilization [Lak02] or a suitable characteristic of a service quality support aggregate. As to measurements, the favourite approach of the author of this book can be described rather as “MeasurementAided Admission Control (MAAC)” than as “MeasurementBased Admission Control (MBAC)”. It seems that an intelligent combination of measurements and bookkeeping provides the best overall results in potentially diverse usage scenarios. The measured network status can be used to choose the service quality support instantiation policy that best suits the observed

268


Service element

Network configuration Peer bandwidth broker

Bandwidth broker End system Policy repository Network element

Network element

Figure 8.6 Interfaces of the generic bandwidth broker Note: Service instantiation control interfaces are drawn in solid lines

resource use situation in the network. In [Lak02], a combination of bookkeeping and measurements is used to control the number of VoIP instantiations admitted to an access network. As a part of an admitted service quality support request, an edge treatment state for a flow may be installed in a network edge element. The installation of the edge treatment state may be performed by a bandwidth broker, or by other network elements. In the latter case, the instalment of the edge treatment is authorized and triggered by the bandwidth broker using a suitable interface. This requires a suitable interface towards the configuration elements such as policy-based management servers. The edge treatment filters may be based on soft state. The interfaces of the generic bandwidth broker are illustrated in Figure 8.6. The direct interfaces to individual network elements are measurement interfaces. The network configuration element can be a generic traffic engineering element, or an element responsible for configuration of edge behaviour as discussed above.

8.2.2

Domain control

In the model chosen for this book, the bandwidth broker’s main responsibility is controlling service quality support instantiation for a multi-service domain. Another possible task of the

8.2 GENERIC MODEL

269

bandwidth broker is to participate in configuring proper edge treatment for flows entering an access domain. This task can be handled by the bandwidth broker, or be dealt with by existing network configuration means. In the former case, the bandwidth broker needs to – directly or indirectly – store and configure adequate DiffServ filters in edge routers. When the bandwidth broker does not perform the actual configurations itself, policy-based management can be used for this purpose. Policy management can be used either in push mode or pull mode for configuring the edge routers. In this case, the bandwidth broker does not need a direct configuration interface to network elements. Instead, an interface is needed between the configuration element and bandwidth brokers. There are different alternatives for the implementation of this interface, including the following: • Configuration element has a default set of filters, and the bandwidth broker informs the configuration element when defaults need to be overridden. For example, in the case of particularly severe congestion, the bandwidth broker could instruct the control element to use smaller token rate and token depth parameters for new incoming data flows. • The bandwidth broker can send actual values to be used in the filters to the configuration element. In both cases, the filters are assumed to exist per service quality support class, and can be defined separately for different end user types as well.

8.2.2.1 Link to traffic engineering When the bandwidth broker makes measurements of actual service quality in the domain under its control, it is beneficial to have an interface from the bandwidth broker to the traffic engineering machinery, as shown in Figure 8.6. In this interface, information about the present admission control policy can be conveyed to the traffic engineering machinery, in addition to loading status. This approach has the advantage of providing traffic engineering process with as much of the information of the factors affecting service quality in the domain as possible,

270


and not leaving service quality support instantiation out of the picture. Thus, the traffic engineering process is able to take into account also the result of measurement-based traffic control in optimizing the network resources. Traffic engineering functionality may also ask the bandwidth broker to change the service quality instantiation policy. The interface may also be used to convey data from the traffic engineering subsystem to the bandwidth broker. If automatic configuration of transport resources according to resource availability in the domain with traffic engineering means is desirable, the data obtained by the bandwidth broker can be used for that purpose. In such a case, the automatic control of domain transport resources would be conceptually a shorter-term loop within the “full” traffic engineering loop of Chapter 4. To maintain consistency and to avoid instabilities, the behaviour of this “tighter” loop should be controlled with the “full” loop. For example, the traffic engineering loop could define limits within which the short-term loop is allowed to make automated adjustments to transport network parameters.

8.2.2.2 Means of maintaining information about resource availability To be properly able to perform service instantiation control of the resources of the domain under its control, the bandwidth broker needs to have up-to-date information about the load within each service quality support aggregate. The basic means of obtaining this information is bookkeeping of resource usage of admitted service quality instances, and the use of measurements. Bookkeeping is used in Schelén’s model to control the number and properties of service instances in each inter-domain funnel [Sch98]. Bookkeeping, in general, can use information relating to the per-flow properties granted to the service instance when the service quality instantiation was accepted. These parameters can be supplied by the endpoint within a RSVP TSpec, or be known from the parameters used for policing the flow in question at the edge of the network. When advance reservations or service instantiation durations are known, temporal information from these can be used in projecting resource availability situation into the future. Some kind of bookkeeping related to the service quality support classes is a mandatory function for a bandwidth broker to be able to provide service quality support guarantees. When

8.2 GENERIC MODEL

271

the bandwidth of individual flows is highly variable, or when the share of an individual flow can constitute a large part of the total capacity of an individual link, achieving higher multiplexing gain may necessitate the use of measurements to complement bookkeeping. This is more typical of access networks than of backbone networks, which is why any possible bandwidth brokers in transit backbone domains can be expected to mostly rely on bookkeeping. Different kind of measurements can be used to obtain information about loading in the network. In view of the target of maximizing multiplexing gain, the loading level of individual network links is often important. Depending on the set of service quality support types, loading information pertaining to some service quality support types may be more important than others. In [Lak02], per-link loads or EF PHB used for transporting VoIP and AF4 PHB class used for transporting streaming are used to control service quality instantiation. In addition, statistics from the transport network elements can be used as source of information in making service quality instantiation decisions. Further potential sources of information are path-oriented or twopoint measurements of service quality [Rai01].

8.2.3

Inter-domain signalling

When one endpoint of the service quality support request is outside of the domain under bandwidth broker’s control, resource availability from other domains is needed for service quality support instantiation decision. Necessary information may not be limited to the closest domain only: if, for example, the end-toend path consists of two access domains and a backbone transit domain, resource usage information from each of these is needed (see Figure 8.7). The loading information is provided per service quality support class. If the service quality support classes in each domain differ from each other, the mapping between these is defined in the appropriate inter-operator SLA. Four different modes of inter-domain signalling are possible: 1. No information exchanged. 2. Per-flow requests exchanged between domains.

272


Load in domain 2 = x Load in domain 3 = y

BB

BB

Access domain (1)

Transit domain (2)

Load in domain 3 = y

BB Access domain (3)

Endpoint Endpoint

Figure 8.7 Supplying width brokers

non-next

hop

information

between

band-

3. Resource availability information provided to neighbouring domains. 4. Periodic reporting to neighbouring domains. The first mode corresponds to using a bandwidth broker for performing admission control to static SLAs between operators. This is close to the Phase 0 of QBone bandwidth broker scenario. Another scenario in which no direct inter-domain bandwidth broker signalling is needed is the ETSI EP TIPHON model in which end-to-end service quality allocation is performed on the service level [TIPHON-3]. In this case, there would be end-to-end per-flow signalling “above” bandwidth brokers. Per-flow requests between BBs correspond to the fully signalled scenario of Phase 1 QBone bandwidth broker scenario, where per-flow service quality requests are signalled to the bandwidth brokers of all domains on the end-to-end path. This scenario has potential scalability problems due to the amount of service quality instantiation signalling events. The third option means that within certain limits, a bandwidth broker can admit new service quality support instances to the inter-domain connections, unless informed of resource scarcity by a peer bandwidth broker. As noted above, also information about non-neighbouring domains needs to be conveyed. To ensure robustness of this scheme, some kind of soft state or heartbeat mechanism should be implemented between bandwidth brokers

8.2 GENERIC MODEL

273

to prevent failure of one bandwidth broker from wreaking interdomain havoc in resource allocation. Another point to consider is the inter-domain signalling load; resource unavailability triggering threshold should not be too low. The fourth option boils down to periodically reporting perservice quality support class load status to neighbours. As with the third option, information about domains further than one “domain step” away from the receiver of the report should be disseminated. Note that soft state mechanism between bandwidth brokers needs to be a part of this scheme. Dynamic signalling makes possible the limited application of a market model between network domains [SLC + 00]. According to the opinion of the author, the most useful mode of application of such a scheme would be complementing traditional SLAs so that the most could be made out of network resources.

8.2.4

Link to service admission control

The information of the bandwidth broker of service quality support resources can be used in the service layer in service instantiation process. In this mode, an endpoint does not request service quality support, but requests service instantiation from a service element such as a VoIP Call Processing Server (CPS). In making admission control decisions, the service element makes use of bandwidth broker information about availability of service quality support resources. Two basic modes are possible [Rai01]: 1. The bandwidth broker is consulted separately for each admission control decision. 2. The bandwidth broker informs service element of the amount of per-quality support class resources and does not directly participate in admission control. The first option may have scalability problems. In the second mode, soft state needs to be maintained between the bandwidth broker and service element. There are different detailed ways of a bandwidth broker providing resource information to the service element, being basically similar to the ones listed for interbandwidth broker alternatives in Section 8.2.3. The service element can use bandwidth broker-supplied information in changing admission control policy, or to reject certain types of service instances altogether.

274

8.3


SUMMARY

Bandwidth brokers can be used for two purposes: dynamic service quality instantiation within a domain, and to implement dynamic SLAs between autonomous domains. Dynamic service quality instantiation support is particularly important for DiffServbased access networks, since per-flow service quality instantiation control is not part of the DiffServ framework. In between domains, bandwidth brokers can be used to convey service quality support resource availability information between domains. Optimally, bandwidth brokers are used for both intra-domain and interdomain resource management. Bandwidth brokers can be used as part of policy-based management, coupling resource usage information with organizational or service policies. This links makes it possible to create a flexible multi-service network for a variety of loading situations. In the next chapter, we shall study 3GPP radio network control in a DiffServ-based transport as an example of bandwidth broker within its domain of control, IP-based Radio Access Network of a 3G PLMN.

9 Case Study: Service Quality Support in an IP-based Cellular RAN In this chapter, we shall study an IP-based Radio Access Network (RAN) as an example of applying the technologies of the preceding chapters. In the framework of preceding chapters, an IP RAN can be considered to be a multi-service Internet access domain supporting endpoint mobility. From the viewpoint of DiffServ, mobility is handled on the link layer. The traffic engineering framework of IETF is used to structure the example. In what follows, we shall first study the motivation for using IP-based transport in cellular radio access network. Next, IP RAN transport architecture is explained. After that, an implementation of service quality support in IP-based RAN is accounted for using IETF’s traffic engineering framework. The technologies listed here are generic to use of DiffServ-based transport in IP based RAN. DiffServ transport will be used in cellular backbones as well. Concentrating on IP-based RAN in this chapter has the advantage of providing a relatively well-defined case study of a multi-service access network. The same principles can be applied in the backbone network, too, but QoS management there is easier due to higher aggregation level of flows.


276

SERVICE QUALITY SUPPORT IN AN IP-BASED CELLULAR RAN

Further optimizations for service quality support in IP-based RANs are possible, but are not discussed here. The goal of the present chapter is to provide a case study showing how traffic engineering and other advanced IP technologies reviewed in previous chapters can be put together to implement service quality in an IP-based RAN.

9.1

MOTIVATION FOR USING IP-BASED TRANSPORT IN CELLULAR RAN

The primary aim of QoS mechanisms in any cellular RAN transport is providing of quality support for services mapped to the four 3GPP traffic classes described in Chapter 5. Additionally, the QoS mechanisms used must also provide an adequate quality support control layer and management layer traffic. The easiest way of supporting services with varying quality requirements is to reserve capacity in the network according to the sum total of all traffic classes during peak hour. Traditionally, Radio Access Networks of GSM, GPRS, and 3G networks have been built using Time Division Multiplexing (TDM) links, based on an Erlang calculation for the peak hour traffic. This has been an adequate solution for networks in which the end user traffic consists almost solely of circuit-switched voice telephony. Interactive voice has strict delay requirements, whereby the network needs to be dimensioned to accommodate bursty data traffic demand during peak hours. The dimensioning of telephony networks for aggregated speech traffic, taking into account Poisson process-like arrival of connections in individual servers (base stations) is an established discipline within traditional telephony (cf., e.g., [McD00]). The problem with applying this approach to a multi-service network domain is that it does not make best use of the operator’s investment in transport capacity, especially concerning the variety of services that need to be supported by third generation mobile networks. For this reason, new alternatives have been evaluated. In a study made by the Mobile Wireless Internet Forum (MWIF), using IP-based transport in the RAN of different third generation networks was found to be a viable option [IRT01]. Data-type applications have been adopted in the mobile network, including browsing the Internet using Wireless Application

9.1 MOTIVATION FOR USING IP-BASED TRANSPORT IN CELLULAR RAN

277

Protocol (WAP). With my GPRS phone, I can initiate a connection and start browsing the news titles from Financial Times or Helsingin Sanomat, latter being the largest daily newspaper in Finland, within a few seconds. I have ample time to check for latest news headlines during a 5-minute bus trip to work from home. Other traffic types, which are made possible by the 3GPP QoS framework for mobile networks, are streaming and data transfer, such as uploading or downloading of digital photographs. Adding pictures to text using Multimedia Messaging Standard (MMS) is possible already with the “2.5G” GPRS networks. The set of supported end user services for 3G will consist of not only speech and short message service (SMS), but to include also MMS, data, and real-time content. As discussed in Chapter 3, the differences in service quality requirements in a heterogeneous traffic mix can be used in network dimensioning. An IP-based transport network in the RAN still has to be dimensioned to support delay-critical traffic during peak hours, in the same way as with traditional telephony. For the less urgent traffic types, however, no fixed capacity needs to be reserved, but instead the multiplexing gain of packet switching can be leveraged to obtain high utilization level in the network. The enabling technology here is DiffServ, which makes possible sharing a single capacity “pipe” by diverse class of applications with varying service quality support requirements. Implementation of service quality with IP and differentiated treatment is advantageous when compared to the traditional concept of reserving capacity for different services in the network. The exact benefits from using DiffServbased transport vary according to the precise combination of end users’ services in the mobile network, as well as the access network topology, but analyses indicate that savings can be up to tens of percent as compared to traditional network dimensioning. Radio access network being a major factor in cellular network CAPEX, this fact translates to monetary savings for the operator. In general, a Radio Access Network transport based on IP brings with it several benefits: • Less transport capacity is needed in the RAN. • There are fewer protocol layers to be managed. • Same type of transport hardware can be used in RAN as in Internet backbone.

278


Leveraging the benefits of IP in a best possible manner requires further technologies, which are not within the scope of this chapter. Discussion about some of the related issues can be found in [IRT01]. An IP-based RAN also has the benefit of allowing the natural incorporation of other access technologies apart from cellular radio into a single multi-service, multi-access network. In such a network, IP is the protocol tying different access technologies together. This concept, sometimes called the All-IP network, is illustrated in Figure 9.1. In addition to the WLAN access shown in Figure 9.1, other possible access methods include ADSL/SDSL and wireline Ethernet. The usability of IP-based RAN is not limited to 3GPP networks, but can be used in other mobility networks as well. Indeed, the analysis of MWIF referred to previously covers both 3GPP and 3GPP2 networks, the latter being CDMA2000 variant of the International Mobile Telecommunications 2000 (IMT2000) third generation mobile framework. In the MWIF study, also IntServ has been included as a potential IP service quality support technology in the RAN. More generically, service quality support in mobile networks has been discussed recently in [CZ02]. In that scheme, bandwidth brokers in radio network access network border routers perform admission control to SLAs in a DiffServ network, based on effective bandwidth approximation. Adaptive applications have been found to make it possible to raise the utilization level of an access network [CZ02], and indeed the adaptive bit rate AMR codec that is used in the 3GPP systems is able to adjust to available bit rate. Irrespective of the radio access technology used, having a proper

Public internet

Operator backbone WLAN access

IP-based RAN

Figure 9.1 A High-level view of an All-IP network

9.2 IP RAN TRANSPORT ARCHITECTURE

279

service quality support model is important for providing proper service quality support in a multi-service environment [GC02].

9.2

IP RAN TRANSPORT ARCHITECTURE

We shall next take a brief look at 3GPP IP RAN transport architecture for WCDMA radio access. The architecture will be extended to cover evolution versions of GPRS radio technologies as well, but these are not covered here. Before taking a look at architectures, let us make a short excursion to the world of generic transport architecture of a mobile network.

9.2.1

PLMN transport architecture

A generic cellular network, called Public Land Mobile Network (PLMN) in GSM parlance, consists of three distinct transport parts: • long-haul backbone; • medium-capacity fibre transport; • bandwidth-limited access links. The high-level transport architecture domains are shown in Figure 9.2. The long-haul backbone is typically a general-purpose transport network having traffic engineering capabilities adequate for high traffic aggregation levels. The backbone connects the mediumcapacity access part of the mobile network to mobility servers Cellular network

Bandwidth-limited access links BTS/ Node B

Mobility servers

Medium-capacity fibre transport

Internet domain

High-capacity backbone GGSN

BTS/ Node B

SGSN Other PLMN

GPRS roaming exchange

Figure 9.2 Transport domains in a GPRS/3GPP network

280


(including SGSN and GGSN), to other cellular networks via GPRS Roaming Exchange (GRE) network via SGSN, and to non-cellular Internet domains via GGSN. As the name implies, GRE network facilitates roaming between operators by providing service quality enhanced connectivity between mobility servers in different PLMNs. We shall return later in this chapter to the topic of service quality support towards Internet domains. Medium-capacity fibre transport network delivers the traffic between access links to the long-haul backbone. (Node B is the canonical name for base station in WCDMA.) The mediumcapacity fibre transport can often be dimensioned with sufficient capacity so that it will not be congested. Bandwidth-limited access links connect BTSs and Node B’s to fibre-based transport. The link layer technology used in this part of the transport architecture depends on the environment. Typical technologies include, leased fibre links and microwave links. The bandwidth-limited part of RAN transport can be hierarchical in nature, resembling a tree with Node Bs as leaves, and DiffServ-capable routers making up the branches of the tree trunk (see Figure 9.3). For resiliency purposes, also loops may be used. As the name implies, the bandwidth-limited links are typically of limited capacity, and interface to the medium-capacity fibre links. A single PLMN may encompass thousands or tens of thousands of Node Bs, and an accordingly large number of narrow-bandwidth links in RAN branches. The cost of entire RAN equipment makes up the largest part of the cost of an entire PLMN, part of that

Node B DiffServ router Node B

Fibre transport DiffServ router

Node B

Node B

DiffServ router

Figure 9.3 An illustration of RAN transport hierarchy Note: Frame combiner not shown


281

being attributable to the transport used. Even though the cost of the actual transport may not be percentually the largest part of the total cost, transport capacity can be limited by the availability of leased capacity or licences for the microwave transport. Thus, transport capacity savings of tens of per cents are made possible multiplexing gain using differentiation-based transport inside RAN branches instead of per-aggregate capacity reservations translates significant transport cost savings for the mobile network operator.

9.2.2

IP RAN transport architecture

IP-based RAN is an evolution of the 3GPP mobile network architecture, extending the scope of use of IP transport (Figure 9.4). In GPRS and Release 99 3GPP architectures, the “core network” interfaces between GGSN and SGSN (including GRE interface) have been based on IP. In Release 4, a 3GPP standardization successor of Release 99, IP transport option up to Radio Network Controller (RNC) was made possible. In the IP option of Release 4, the basic R99 architecture is not modified, the only change being the transport technology used beneath the GTP tunnel between the Node B’s and RNC. An IP RAN is a logical next step in this evolution, integrating the IP-based transport more closely into the RAN architecture. It turns out that for overall efficiency, it is beneficial to redesign the radio network control layer, replacing a single RNC with distributed radio resource control architecture. The explanation of the entire IP RAN radio resource control architecture is not within the scope of the book. For the purposes of this chapter it is sufficient to know that from the viewpoint of mobile terminals, the 3GPP service quality support control provides the same service quality support Application User IP layer Radio tunneling RAB Link Terminal

Radio tunneling RAB Link

GTP IP Link

IP base transceiver station & radio network gateway

GTP IP Link

GTP IP Link

Serving GPRS support node

User IP layer User IP layer GTP Link IP Link Gateway GPRS support node

Figure 9.4 IP RAN architecture protocol stacks for user layer traffic Note: The architecture has been simplified to make the role of bearers clearer

282


as the preceding 3GPP network variants. An overview of the IP RAN protocol stacks on a logical level is shown in Figure 9.4. From the viewpoint of protocol stacks, the only difference in the actual stacks is that the GTP tunnel uses IP-based bearer up to basis station. Please note that in Figure 9.4, only user layer traffic protocol stack is shown.

9.2.3

Handover traffic

Mobile networks based on Code Division Multiple Access (CDMA), of which Wideband CDMA (WCDMA) used in 3GPP networks is a subspecies, use the so-called soft handover for handling terminal mobility. This means that a terminal may communicate with the mobile network through more than one base station (called “Node B” in CDMA) at a time. A mobile terminal does not have to detach from the previous Node B before commencing communication with the next one. This arrangement is necessary due to CDMA power control. Due to this, traffic to a particular mobile participating to soft handover is being transmitted via multiple Node Bs in both uplink and downlink directions. A practical implementation of soft handover requires the function of a frame selector function in the network, which – for uplink direction – receives radio frames from different soft handover “legs”, and combines the signals arrived via different routes into a single PDU stream towards the core network (see Figure 9.5). The frame selector is also known as a macrodiversity combiner, with the term “microdiversity” being reserved for mobility handled by individual Node Bs. For downlink direction, the signal is split into different paths and frame combining is performed in the terminal. In 3GPP

Core network Terminal

Node B Frame selector

Node B

Figure 9.5 Principle of soft handover Note: Transport of radio frames is shown by dashed lines, and normal GTP tunnelled traffic by a solid line


283

Release 99 networks, frame combining for uplink and frame splitting for downlink is done in RNCs. The importance of the soft handover concept for the present discussion is that in addition to 3GPP user layer and signalling traffic, radio frames being part of soft handover traffic need to be transported in the links of bandwidth-limited RAN. Soft handover traffic has typically high forwarding priority, the frame-combining algorithm having limitations for the allowed delay difference on the different paths. In addition to soft handover traffic, WCDMA networks in general can also carry so-called drift traffic, consisting of non-processed radio frames. In the case of 3GPP R99 network, drift traffic can be transported between a drift RNC and a serving RNC. In this case, the drift RNC forwards non-processed radio frames to the serving RNC. Drift traffic, too, has high priority. In what follows, generic references to handover traffic are made, covering both soft handover and drift traffic.

9.2.4

Service mapping in IP RAN

The 3GPP QoS model, reviewed in Chapter 5, applies independently of the transport technology used in the RAN. Thus, the user layer QoS model used in IP RAN is the same as in Release 99 networks. What is different between IP RAN and R99 UTRAN is the implementation of the transport part of the radio access bearer. The implementation of service quality support in IP RAN transport is described below on a generic level. As in 3GPP R99, each application flow is associated with a PDP context describing the negotiated QoS support for the flow. The QoS attributes of a PDP context have been described in more detail in Chapter 5, and for the present purposes we are interested in the QoS attributes of the PDP context which may affect IP RAN transport. These include: • Traffic class (conversational, streaming, interactive, or background); • Traffic Handling Priority (THP); • Allocation/Retention Priority (ARP). These QoS attributes are used in mapping the PDP context associated with the application flow onto a Radio Bearer (RB) for the

284


Application

PDP context Managed mapping Radio access bearer

IP transport bearer

Figure 9.6 Service mapping for user layer traffic in IP RAN

radio interface, and a Radio Access Bearer (RAB) in RAN transport. Service quality support in the backbone transport can be based on RAB used in the RAN (Figure 9.6). Thus, as in R99, the PDP context is a service quality abstraction layer between the application, and the different link-layer technologies (radio interface, IP transport). Seen from end-to-end viewpoint, service quality support in an All-IP network for a terminal communicating with a host in the Internet includes the following steps: 1. Terminal maps application flow requirements into PDP context QoS attributes. 2. PDP context of appropriate type is initiated. a The QoS parameters of the PDP context map onto a suitable RAB and CN bearer. b RAB maps to specific WCDMA radio interface parameters. c RAB in the RAN maps onto suitable IP transport parameters (PHB). d QoS treatment for packets belonging to the PDP context is based on the RB service quality support in the radio interface, and DSCP marking in the RAN and backbone transport. 3. Between GGSN and external network, possible QoS interworking is based on PDP context QoS profile. a In uplink direction, mapping to QoS mechanism beyond GGSN is based on PDP context properties.

9.3 TRAFFIC ENGINEERING IN ALL-IP RAN Table 9.1 Traffic aggregate

285

Traffic types in IP RAN

Tunnelling

Forwarding priority

Tolerance to delay jitter

Soft handover traffic Drift traffic 3GPP conversational 3GPP streaming 3GPP interactive 3GPP background Control traffic

Radio frames Radio frames GTP GTP GTP GTP No tunnelling

High Typically high High Medium Depends on THP Low Depends on traffic

Little Typically little Little A little Not applicable Not applicable Not applicable

Management traffic

No tunnelling

Depends on traffic

Not applicable

b In downlink direction, a Traffic Flow Template (TFT) is created within GGSN, mapping incoming flow into appropriate PDP context. Mapping of traffic onto 3GPP traffic classes is controlled by the terminal, and mapping of traffic classes onto QoS support schemes in radio interface and IP transport is controlled by the mobile network. The latter mapping can be implemented in many different ways. In what follows, the simple solution of predefined mapping onto RAB and further from RAB to IP QoS parameters in the transport is assumed. All told, IP RAN transport needs to be able to deal with the traffic types listed in Table 9.1. It is useful to note that different kinds of tunnelling are involved, including radio framing, GTP tunnelling, and no tunnelling at all. The scheme that has been accounted for above constitutes the basic implementation of service quality mapping aspects in IP RAN. Further enhancements are possible, but are not central to the current discussion.

9.3

TRAFFIC ENGINEERING IN ALL-IP RAN

In this chapter the technologies used in IP-based RAN transport are presented within the framework of IETF traffic engineering. The “full loop” of traffic engineering process in IP RAN includes policy-based management for the configuration of the network elements, as well as technologies for measuring service quality in the network. There is also a shorter timescale process involved,

286


Table 9.2 IETF classification of traffic engineering functions and their related timescales Functions

Time scale

Capacity planning

Days to years

Capacity management

Hours to days

Traffic management: 1. Resource management. 2. Packet-level processing functions.

Seconds to hour Less than a second.

Methods • Upgrading network elements and link capacities. • Adding new elements and links. • Configuration of service mappings. • Network level optimization. • Routing control. • Admission control • Flow conditioning • Differentiated packet treatment

consisting of the service quality support instantiation performed by the 3GPP radio network. At packet/SDU timescales, service quality support is divided between DiffServ and radio network. These topics will be discussed further below. The traffic engineering techniques presented next are “domaininternal”, and can be applied separately to RAN and backbone domains. Service quality interworking issues will be discussed further in Section 9.5. An overview of IP RAN technologies within the IETF traffic engineering framework is shown in Table 9.2. The contents will be explained in more detail in Sections 9.3.1, 9.3.2, and 9.3.3.

9.3.1

Capacity planning

Capacity planning in IP RAN is needed when the access domain of the mobile network is built, or major additions or changes are made. Capacity planning operates on long timescales, typically years or tens of years. When the network is built for the first time, the planning process has to take into account physical, commercial, and regulatory issues such as locations of base stations, frequency allocations,

9.3 TRAFFIC ENGINEERING IN ALL-IP RAN

287

and physical layout of the transport network. The planning decisions made during the initial planning may set the stage for the future for long time to come because of the physical transport infrastructure (microwave links, BTS site selection). Once the network has been built, it can be extended both geographically (new RAN branches) and capacity-wise (more base station capacity for the coverage area). Also in this case, capacity planning needs to be done. Link capacities may need to be upgraded, or new links may need to be added. In the case of capacity extension, the boundary conditions mentioned above become increasingly important. As to transport capacity in the bandwidthlimited access part, the network operator will benefit from efficient capacity utilization in transport links. Capacity planning requires predictions on geographical subscriber base as well as anticipated service usage patterns as inputs to the process. The basic task of capacity planning in IP RAN is multi-service IP network dimensioning using the above inputs, and based on the techniques discussed in Chapter 5. The basic planning tool is based on information about subscriber count growth predictions, anticipated set of service types supported, and technical details of the transport technologies used in the network. Examples of the latter include supported link capacities in each technology and the regulatory constraints. The actual transport design process is often iterative in nature, having link technology parameters and possibly locations of base stations as variables. During one iteration step of the planning process of the IP RAN transport, the set of supported services as well as network topology and expected geographical distribution of service usage is fed into a planning model. In the case of 3GPP IP RAN with WCDMA air interface, the tight delay targets for handover traffic need to be fulfilled, and the service quality support specified in 3GPP QoS model provided to the user layer traffic. In providing service quality support for handover traffic, the challenge of traffic volume variability due to user mobility needs to be taken into account. In addition to modifying network topology and link layer technology specific parameters, also IP transport bearer parameters such as mapping of services to PHBs and drop precedence levels can be used in optimizing the transport configuration. The planning process must allocate service quality support resources for each supported service type for the different parts of

288


the PLMN. Service quality in different domains of a PLMN can be implemented with different variants of IP transport technologies, reflected in the configurations in the respective network parts. In the access network, because of the target of high utilization level, tailoring of the service quality support to supported service types is most important. Particularly, it is beneficial to optimize the DiffServ in the IP RAN access to cellular traffic types. In the backbone network, on the other hand, the transport is more of general-purpose type. This means that the actual parameters configured into DiffServ routers in the access network and backbone network of a PLMN can be very different, although service quality support level representation sees both of them as abstract parts of an end-to-end calculation (Figure 9.7). The configuration of both access and backbone domains can be done separately and at different schedules. Nevertheless, policy-based management is an enabling technology in facilitating diversity in service quality support platforms. The use of policy-based management can be expected to be useful especially in the RAN domain, since achieving high utilization levels in the low-capacity parts of the network can be expected to particularly benefit from traffic engineering process. The service quality requirements of 3GPP traffic classes and other transported service types are used in mapping the PDP contexts onto DiffServ Per-Hop Behaviors (PHBs). The most important mapping decisions relate to how different traffic types are prioritized with respect to each other and which drop precedence End-to-end service quality PLMN service quality Access service quality

Backbone service quality

DiffServ parameters in access

DiffServ parameters in backbone

Access network

Operator backbone

External domain

Figure 9.7 Schematic representation of end-to-end service quality computation


289

levels are allocated for each type of flows. When this information is combined with network topology and geographical distribution of services, per-element DiffServ behavioural aggregate properties can be computed. When traffic aggregate level characteristics on each link are known, they can be translated into initial values of per-router parameters such as DiffServ rate limiter settings, scheduling weights, and so on. Transport planning, in general, also includes planning routing of service aggregates as well as designing of recovery strategy for link failures. The methods that can be deployed depend on the link layer technology in use. In the backbone, for example, MPLS can be used for routing control as well as for resiliency purposes. If necessary, the mapping from DiffServ BAs in IP RAN access to backbone LSPs can make use of BA mapping of services in the former.

9.3.2

Capacity management

Capacity management in IP RAN means making the most out of the built capacity. In what follows, the traffic engineering process of Chapter 4 is assumed, that is, optimization of the behaviour of the network based on feedback from the network. In the case of IP RAN, capacity management can be viewed as an optimization problem with the goal of maximizing revenue from the network, given the boundary conditions of service quality (as defined in 3GPP QoS framework and specification of the control traffic), variations in traffic volume and distribution, and the ease of network reconfiguration. Because of the boundary conditions, capacity management cannot be performed solely using utilitybased methods referred to in Chapter 5. Reasons for performing the reconfiguration aspect of capacity management in an IP RAN domain may be changed resource usage situation in a part of the network, or adoption of new services in the mobile network. Transport parameters may also be optimized based on measured network state or traffic properties in order to be able to implement the selected high-level service quality support targets. Feedback from the network is obtained from the network elements on different levels, ranging from per-element counters through network domain level abstractions to service level

290


characteristics. The network domain level abstraction uses perelement data as input. Service level characteristics can be obtained using passive probes and active measurements, as explained in Chapter 7. We shall return to this topic in Section 9.4. The controls that can be used in capacity management of DiffServ-based transport network include: • mapping of traffic to suitable service quality support aggregates; • control of DiffServ transport network parameters. Of these two, adjustment of traffic mapping is a tool with potentially bigger impact, whereas control of DiffServ parameters is basically an optimization of the transport network parameters for supporting the selected service mapping. As will be discussed below, some of the functions of the DiffServ framework are performed on the radio network control layer. Mapping of 3GPP traffic classes – as well as other IP RAN traffic types of Table 9.1 – is one of the controls specific for transport. This includes the following subtasks: • allocation of 3GPP traffic classes and other types to DiffServ PHBs; • setting of PHB group specific parameters for AF, such as AF class (1–4) and drop precedence level (1–3). For user-layer traffic, flows are mapped by the cellular network to PDP contexts with appropriate 3GPP QoS class (conversational, streaming, interactive or background) and QoS profile parameters (traffic handling priority, etc.). Using the scheme of Figure 9.6, the QoS profile parameters of PDP contexts are then mapped to IP transport parameters via the concept of RAB. Control traffic between 3GPP and IP transport network elements, management traffic, measurement traffic and handover traffic may need to be mapped to DSCPs using different kind of heuristics which is not important here. Delay requirements of urgent traffic types pose most important limitations to traffic mapping, being reflected in relative forwarding prioritization of traffic aggregates in the IP transport. The drop precedences of AF classes operate most efficiently with service instances utilizing closed-loop end-to-end transport quality control such as TCP. IP transport parameters that can be controlled include


291

• per-PHB parameters in DiffServ routers, such as rate limiters, scheduling weights, queue lengths, and algorithmic dropper parameters; • routing control. The aim with DiffServ router parameter adjustment is to optimize the transport network for the selected service mapping. Routing control can be used for congestion control purposes and in enhancing service quality support for critical traffic types.

9.3.3

Traffic management

Admission control to services provided by the cellular network is handled by the UMTS network. In the case of an IP RAN, also service quality support instantiation is controlled by the 3GPP network. Because of the latter, it could be rightly be said that the 3GPP network connection admission control constitutes a bandwidth broker for the transport network [Rai02c]. In the case of traffic transmitted from one terminal to another, the bandwidth broker is of end-to-end type. This is even true for inter-cellular operator connections, if adequate service quality can be provided in the GRE network. In the Internet services, on the other hand, the 3GPP network does not typically have an actual “peer bandwidth broker” to negotiate service quality with. No interface for such negotiation has been defined either. Service quality can be provided using SLAs at the network edge, as will be described below. Per-flow traffic conditioning that is part of the standard 3GPP QoS framework limits the burstiness of individual streams, thus preventing the build-up of burstiness and making it possible to achieve well-behaving traffic aggregates in the core of the network. In a 3GPP network, per-flow conditioning is performed on PDP context level (see Figure 9.6) at network edge, that is: within Node B for uplink direction, and within GGSN for downlink direction. Traffic management in the bandwidth-limited part of IP RAN benefits from DiffServ transport implementation, tailored to support 3GPP traffic classes. The tailoring refers both to structure of queueing system in view of the supported traffic types, and the complexity of management interface used in applying traffic engineering to the routers of IP RAN. Management of

292


service quality support is easier when the service quality support mechanisms of the transport network reflect the properties of the traffic. As bandwidth-limited transport in the access network needs to interface towards backbone network, it is beneficially PHB compliant with standard EF/AF DiffServ routers. Service mapping in the IP RAN access domain can be made configurable. The “lower part” of traffic mapping, mapping RAB parameters to DSCP, can be accommodated by policy management. Being based on traffic aggregates, the IP level mapping is not overly complex to be managed and optimized. An example of such a mapping, one aspect of service quality requirements of 3GPP traffic classes can be supported in IP RAN by mapping delay-critical traffic, such as 3GPP conversational class traffic and soft handover traffic, into DiffServ queues supporting prioritized forwarding. In general, the combination of policy management and DiffServbased transport provides a multitude of differentiation tools for optimizing transport network for services in IP RAN. In addition to prioritization, algorithmic dropping policies can be applied to achieve prioritization between data flows in cases of temporary congestion. The transport solution based on traffic aggregates also easily accommodates non-cellular traffic in the same transport network.

9.4

ENABLING TECHNOLOGIES FOR TRAFFIC ENGINEERING IN IP RAN

Below, technologies used in practical implementing traffic engineering in IP RAN are reviewed, including policy-based management, network measurements and optimization.

9.4.1

Policy-based management

Policy-based management of DiffServ transport network parameters is an important enabling technology in many of the traffic engineering tasks discussed above. Policy management can be used as the final major stage in performing the initial configuration of IP RAN (Figure 9.8), as well as a tool in optimizing the service quality support configurations of network elements. In the

9.4 ENABLING TECHNOLOGIES FOR TRAFFIC ENGINEERING IN IP RAN

Network design parameters

293

Modelling of network state Network planning module

Policy repository

Policy manager

NE

NE

NE

NE

NE

Figure 9.8 Schematic of the configuration half of traffic engineering in IP RAN

former role, policy management machinery distributes network element specific configurations into the network. The second use for policy management is nevertheless perhaps more important than the first one. Only when the actual task of reconfiguring of network elements is technically feasible via automation of the process, the application of entire traffic engineering process to a multi-service IP network such as IP RAN becomes feasible. To give but a glimpse of the size of the problem area, a single PLMN may encompass thousands or tens of thousands of Node Bs, each interfacing to the transport network. Reconfiguration of such an array of network elements via CLI or a number of proprietary management system interfaces would be a major undertaking and would defeat the purpose of the traffic engineering process. The policy-based management machinery makes it possible to configure all the network elements using an abstracted interface allowing operator to operate on service level in configuring the network. The configuration is preferably translated into appropriate per-element parameters and conveyed to network elements using standardized, open interfaces. The abstracted management

294


interface does not need to show the details of the transport network, but concepts relevant to the supported service quality support types such as 3GPP traffic classes can be used instead. In the case of transport resources in the bandwidth-limited access, the management interface should be minimal in the number of controlled parameters to optimize the amount of control traffic.

9.4.2

Measurements

Feedback can be collected from the network from two sources: network elements and service quality measurement agents. In the backbone network, feedback from routers can be based on standard IP router counters and management system interfaces. This is because the traffic aggregation level is high enough to make fluctuations in traffic volume predictable. In the bandwidth-limited access network, on the other hand, built network capacity can be best utilized by tailoring also management interface to the service quality model of 3GPP. In practice, this means that the management system provides information in a form that is relevant to optimization and control of the transport network for the service types transported therein. Likewise, an important consideration in IP RAN is the amount of measurement related traffic. Optimization of traffic volume in the measurement interface is especially important in saving transport resources in the bandwidth-limited access of an IP RAN domain. Another type of feedback from the network, service quality measurements can be used to probe directly service quality levels in the mobile network. In the backbone network, service quality support for traffic aggregates can be measured using the active measurement methods described in Chapters 4 and 7. In the bandwidth-limited access, again, the capacity constraints limit the methods that can be used. Passive measurements can be used to probe service quality there, and direct feedback from 3GPP network servers can be utilized. In IP RAN domain where efficient bandwidth utilization is the target, one important metric to be measured is the utilization level of individual links. In addition to providing feedback to DiffServ-based transport network resource optimization, measurements can also be used in trend prediction. In recent years, cellular networks have experienced a huge growth of traffic. It is expected that adoption

9.5 INTER-OPERATION WITH IP-BASED BACKBONES

295

of mobile data-based services such as pictorial messaging and browsing will lead to a further period of rapid growth in traffic transported in mobile networks. In such a situation, trend prediction of per-service traffic volumes provide basis for decisions of capacity upgrades. Per-element information about potential service quality support bottlenecks can be used to make best use of the network capacity for the selected traffic mapping. The same information can also be used to decide when it is time to use more radical means such as changing the traffic mapping and upgrading network transport capacity. Finally, the transport network can be optimized for supporting new service types.

9.5

INTER-OPERATION WITH IP-BASED BACKBONES AND ROAMING NETWORKS

Service quality support interoperation between autonomous network domains can be most easily implemented using SLAs, including SLSs defining the relevant technical parameters. This is a valid approach in different situations, for example: • between the bandwidth-limited access domain and the backbone of a PLMN; • between a PLMNs (and GRE); • between a PLMN and an external network. This kind of scheme can be used both when the domains are managed by different operators, and also for internal accounting purposes between different business units within an operator. With SLA/SLS based approach, the external operator can use any QoS support mechanism it desires to implement the SLS parameters. Irrespective of the technology used, traffic engineering techniques are useful in optimizing per-domain service quality support subject to boundary conditions defined by SLAs. There is no standard interface for performing service quality support negotiation between a 3GPP PLMN and Internet domains. SLAs can be used as a basis for service quality interworking. Thus, the 3GPP connection admission control machinery can be viewed as a bandwidth broker of “Phase 1” type for mobile-to-mobile

296


traffic, but of “Phase 0” type for PLMN-to-Internet or Internet-toPLMN traffic. At the edge of a 3GPP PLMN, traffic can be mapped to Label-Switched Paths (LSPs) of a Multi-Protocol Label Switching (MPLS) domain or to DiffServ Behavioural Aggregates in a DiffServ domain in the uplink direction, using configured mapping from 3GPP traffic classes to the aggregates of the external network. A conceptual scheme for interworking of a 3GPP domain with a DiffServ domain controlled by a bandwidth broker has been outlined in [MNV02].

9.6

SUMMARY

IP-based Radio Access Networks have the potential for allowing more efficient utilization of transport capacity for multi-service support, as well as using IP-based network technologies across different access network technologies. In addition to monetary benefits, also the management interface to IP-based networks can be made simpler due to lighter protocol stacks. All-IP RAN is an evolution of the 3GPP network, using the same QoS framework as the first “Release 99” network. In addition to basing of RAN transport on IP, also radio network architecture is tailored specifically to IP environment. In the model described here, service quality in the actual transport is based on DiffServ framework and traffic aggregates. The total set of service quality support functions related to IP transport is divided between radio network control (“3GPP layer”) and IP network functions (“IETF layer”). Service instantiation control, service quality support instantiation control and perflow traffic conditioning at the edge of the transport network are handled by the 3GPP layer. Because of the first two tasks, the 3GPP layer can be viewed as a special case of a bandwidth broker. The 3GPP layer also provides transparent mobility for the end user, with user IP address staying the same. Aside from the functions performed by the 3GPP layer, IP RAN elements are purely IP devices, an as such can be managed using the IETF traffic engineering process. The DiffServ transport in the IP RAN is beneficially optimized for the properties of the mobile network traffic types, making the application of traffic engineering to transport parameter optimization easier. Policy management is an important tool for making scalable reconfiguration possible in

9.6 SUMMARY

297

a RAN consisting of thousands of Node Bs. The parameters that can be adjusted in optimizing IP RAN transport include service mapping to PHBs, and DiffServ router parameters. Measurements of utilization levels of links, load levels in different traffic aggregates, and service quality in different aggregates provide input for optimization of the transport resources. In the backbone networks, the configuration tuning can be expected to be less critical, and traditional traffic engineering tools such as MPLS-based routing control and service level measurements being most important technologies to be utilized there. SLAs can be used for service quality both between the RAN and a general-purpose backbone, and between the PLMN and external Internet domains. On the transport level, service quality support interworking can be expected to be based on interfacing of MPLS and DiffServ domains.

10 Summary It is time to summarize the topics discussed in previous chapters. End users want to have access to different kind of information access and entertainment-related services with as simple technical means as possible and with as understandable a billing as possible. Such a goal not only brings economical benefits, but also means that the customer has smaller number devices and interfaces to master and to maintain. Beneficially, all kinds of services should be available to the end user using a single communication channel only for each context of use. One such context of use is home or corporate use, where high-bandwidth access is possible. Another context is mobile use, where the services are provided via a handheld terminal or via a laptop. Communication media with per-user throughput allowing the delivery of also real-time content is becoming widely available, examples being fibre access to home or SOHO environments, xDSL, IEEE 802.11, and 2.5G/3G radio interface technologies such as GPRS and WCDMA. The mere existence of suitable medium is not sufficient, but the interface to the applications should be made such that achieving adequate service quality support for each service type is possible. Equally, the service quality support interface from the applications should be easy to use, easy to understand for the end user, and as standard as possible across platforms. The services differ with respect to their delivery requirements according to their composition, containing at most general multiple components with differing requirements. Data-type services such Implementing Service Quality in IP Networks Vilho Räisänen  2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X

300

SUMMARY

as e-mail only require reliable delivery, whereas more interactive services such as Internet browsing pose further limitations on the underlying technical solution. Most demanding service types are real-time services, with each service instance being made up of a stream of data in the network. Streamed multimedia is an example of this. Multimedia conferencing and remote control applications have the strictest service quality support requirements. Due to the dynamic nature of service creation made possible with IP-based networks, it is not possible to enumerate the service quality support requirements of all possible services, but it is possible to construct a framework classifying the required service quality support. The easiest way of providing service quality support in a packetswitched environment is to over-dimension the network. This is not always economically feasible. Especially in the access networks, it is highly desirable to utilize the network capacity as well as possible. End-to-end service quality is also affected by other factors, which have been discussed in Chapter 2. In what follows, we shall concentrate on network-side support for service quality.

10.1

IP AS THE CONVERGENCE NETWORK

During 1990s, Asynchronous Transfer Mode (ATM) held the promise of providing multi-service support to homes and offices. Despite the advanced service quality support modes, ATM did not reach the home user, except as link layer technology used in ADSL. ATM was perceived as complex and expensive. The common denominator turned out to be Internet Protocol (IP). IP-based applications have been in wide-scale use since the development of Transfer Control Protocol (TCP) in the 1980s. The application programming interface (API) of TCP/IP has been tested for a long time, and has a wide user base. IP was originally developed for packet-switched services such as data transfer and e-mail. TCP/IP has demonstrated its validity for these purposes via worldwide deployment as the basis technology for the Internet. All the basis protocol suites in IP have been designed for packet-switched environment, being exemplified by routing protocols such as Open Shortest Path First (OSPF). Making IP the protocol basis also for real-time services requires that new technologies be added to basic IP. The most demanding services such as Voice over IP (VoIP) and streamed multimedia typically

10.2 DIFFSERV

301

consist of a periodic transmission of Protocol Data Units (PDUs) in the network, and need low end-to-end delivery latency and bounded PDU loss in the network. These needs are addressed by service quality support extensions to basic IP, and traffic engineering extensions. Two service quality support frameworks have been defined for IP, namely Integrated Services (IntServ) and Differentiated Services (DiffServ). IntServ is a framework providing two service models, one approximating to lightly loaded network and another one providing actual service quality guarantees. Current practical implementation of the IntServ framework make use of the Resource Reservations Protocol (RSVP) between network elements, and are perceived as having poor scalability properties with network size. DiffServ, the alternative IP service quality support framework, provides two standardized service models, namely a low latency/low loss one and a statistical allocation of services. Since DiffServ is based on prioritization of PDUs and not requiring maintenance of per-flow state in the network, it is considered to be scalable to large networks. At the moment, DiffServ-based IP service quality control means for single domains have reached a mature phase, and are being deployed in the transport infrastructure of packet-based mobile networks. The use of DiffServ as the basis of future generalpurpose multi-service network is being studied in multiple fora, such as the QBone/Internet2. The other part of the story is interface between services and the service quality support-enabled transport network. The interface can be based on Service Level Agreements (SLAs), and can also use dynamical means of service quality control. Let us next take a brief look at the capabilities of a DiffServ-based multi-service network.

10.2

DIFFSERV

One of the reasons for the favoured position of DiffServ in this book is the combination of reference architecture and service quality support model, the latter consisting of a small number of service quality support classes, the Per-Hop Behaviours. Core network routers handle only IP packets marked with a DiffServ Code Point (DSCP) corresponding to one of the PHBs. Two classes of

302

SUMMARY

PHBs are standardized at the moment, namely Expedited Forwarding (EF) PHB and the Assured Forwarding (AF) PHB group. Domain-wide, the service quality support level provided by traffic aggregates in a DiffServ network can be defined using the concept of Per-Domain Behaviours (PDBs), detailing characteristics such as delays between reference points in the network. Since DiffServ is based on traffic aggregates, it has the potential to achieve high multiplexing gains, depending on the combination of services transported within the domain. Another part of the service quality support framework in DiffServ is traffic conditioning at the edge of the network. Incoming packets are classified and marked with a DSCP. The allowable bandwidth and burstiness of incoming flows or traffic aggregates can be defined in a SLA between the network operator and the customer. Based on the SLA, incoming traffic can be policed to avoid degradation of the service quality support in the respective traffic aggregate. Because per-flow operations are performed at the edge of the network, DiffServ is sometimes known as the edge provisioning model. Basic DiffServ does not include means of limiting the number of service instances within one traffic aggregate in a domain, which is why DiffServ needs to be supplanted by a service quality instantiation control in order that high network utilization levels can be reached. A protocol interface between the end systems and service quality instantiation is needed to achieve this. For this purpose, the service quality signalling part of RSVP can be used. Alternatively, a suitable protocol interface based on service quality support aggregates can be used. In addition, service quality support instantiation functionality is needed. Another area not addressed by the basic DiffServ framework is routing control. For this purpose, suitable link layer technology or IP routing protocol based means can be used. Such routing control means are seen to be part of the traffic engineering framework discussed in Section 10.4 below.

10.2.1

Complementary technologies for DiffServ

Basic service quality support instantiation control of a DiffServ domain can be complemented by a service quality instantiation controller handling admission requests from end systems and other

10.3 SERVICE LEVEL MANAGEMENT

303

domains. In DiffServ environment, this element is called bandwidth broker. A bandwidth broker can perform admission control to network resources based on bookkeeping, measurements, or a combination of both. Use of measurements is advantageous in making service quality instantiation coupled with the actual resource usage status. Using measurements in service quality instantiation control is especially useful in a multi-service environment with the goal of high network utilization levels. Bandwidth brokers can also be used in end-to-end service quality control across domain boundaries. In this mode, a single bandwidth broker may be responsible for a single IP domain and the bandwidth brokers in different domains can exchange information about resource availability. Different scenarios for inter-domain bandwidth broker communication have been discussed in Chapter 8. Dynamic inter-domain resource signalling can be used as a supplementary technology in interdomain SLA agreements. In addition, it has the potential to be an enabling technology for market-oriented service broker models.

10.3

SERVICE LEVEL MANAGEMENT

Service Level Agreements (SLAs) are used in telecommunications and datacommunications for defining the responsibilities and rights of operators when they are using each other’s services. In general, SLAs can also be used between operators and end users, between service providers and network operators, and between service providers. A SLA makes it possible to achieve engineered end-to-end performance without end-to-end signalling. Traditionally, SLAs have been used in a single-service environment such as telephony or data delivery in the Internet. Extending the area of applicability of SLAs to multi-service networks brings with it new challenges. SLA management can be viewed as a higher layer making use of per-domain resources (see Figure 10.1). Individual SLAs, concerning either actual services, or service quality support for external parties, can be processed on a SLA management layer by each operator or service provider. Inputs to the SLA management come from the business goals of the operator, as well as from the per-domain resource availability and existing SLA base. Potential new technologies that can be used for evaluating SLA

304

SUMMARY

Utility-based resource allocation assessment SLA management SLA

SLA

SLA

SLA

SLA

Traffic engineering NE

NE

NE

NE

Implementation of SLAs NE

Figure 10.1 Technologies associated with the layers of SLA management and implementation

allocations include utility-based methods. Such schemes can be used in assessing different SLA assignment alternatives. Bandwidth brokers can be used with inter-domain SLAs in two ways: complementing the content of static SLAs with up-to-date resource availability on inter-domain links, and in implementing new inter-domain resource management models that assume the availability of dynamic resource information across domain boundaries. On the network level, SLA management process has a conceptual counterpart, namely traffic engineering process, which is used to manage the service level support in a multi-service IP domain. This is our next topic.

10.4

TRAFFIC ENGINEERING

Traffic engineering in a multi-service domain is a process which optimizes the network resources for the service quality support configuration resulting from the SLA management process. One aspect of traffic engineering is making the initial service quality support configuration of a network domain, and another one is the optimization of the use of resources in an operational network. To perform the first task, traffic engineering process takes SLA assignments and network service quality support resources as an input, and computes the required network element configuration in the domain.

10.5 POTENTIAL FUTURE DEVELOPMENT DIRECTIONS

305

Service instantiation control policy adjustment

DiffServ parameter optimization

Modification of service mapping

SLA adjustment

Building of new transport capacity

Timescale

Figure 10.2 The timescales of traffic engineering

For the optimization task, feedback from the network is needed. Feedback can be obtained from the network in multiple different formats, including element level, domain level and service support aggregate level information. An important measure from a multiservice aggregate network is the utilization level of links. Service quality support aggregate measurements are typically also needed by the SLA management process. From the viewpoint of SLA management, the traffic engineering process must also be able to provide an indication of its means of optimization of the network behaviour becoming exhausted. In such a situation, SLA-level actions are needed. Examples of possible actions include revision of the contents of SLAs towards end users, other network operators, or service providers. Another possible consequence is updating of network capacity. The timescales associated with SLA management and traffic engineering are illustrated in Figure 10.2

10.5

POTENTIAL FUTURE DEVELOPMENT DIRECTIONS

IP-based Radio Access Network (RAN) was shown as a case study of applying the concepts discussed earlier within this book. It was a suitable topic for this, since the service quality support classes are well defined, and the role of DiffServ and traffic engineering

306

SUMMARY

can be readily outlined. According to the aim of providing same services over any access technology, the need to apply the same techniques to other access networks can be expected to emerge in the near future. From the viewpoint of DiffServ, the basic deployment scenario, management and application of traffic engineering in such multi-access networks can be expected to be not unlike corresponding tasks in IP-based RAN. The differences will most likely arise from user mobility, service quality instantiation control, management and optimization of access technology specific details according to the needs of specific service usage. The application of novel end-to-end technologies such as signalled inter-bandwidth broker service quality instantiation control and service auctioning technologies is likely to be an interesting research area for the future. The adoption of such technologies would allow for interesting new scenarios, for example, facilitating competition between service providers using the same transport provider. One of the most interesting areas of research is access networks without static infrastructure, known as ad hoc networks. The implementation of basic service quality support in such networks can be expected to be topical in the coming years, and interfacing ad hoc networks to engineered transport network will likely give rise to interesting interoperability scenarios.

References Below, RFC means IETF Request For Comments, and draft refers to IETF Internet draft. Both are available from http : //www .jetf .org/, subject to the 6-month existence period of single version of an Internet draft. ETSI standards are available electronically from http : //www .etsi .org. [22.105]

3rd Generation Partnership Project, Technical Specification Group Services and System Aspects; Service Aspects; Services and Service Capabilities (Release 5), Technical report 3G TS 22.105, version 5.0.0, October 2001.

[Arm00]

Grenville Armitage, Quality of Service in IP Networks, Indianapolis, MacMillan Technical Publishing, 2000.

[ATM]

ATM Forum Traffic Management Specification, version 4.0, af-tm-0056.000, April 1996, ATM Forum.

[BCG95]

J-C. Bolot, H. Crépin and A. Vega Garcia, “Analysis of Audio Packet Loss in the Internet” in Proc. NOSSDAV’95 , p. 154–ff., 1995.

[Bol93]

J-C. Bolot, “End-to-end packet delay and loss behavior in the Internet”, in Proc. SIGCOMM’93 , p. 289–ff., ACM, 1993.

[BR02]

N. Benameur and J.W. Roberts, Traffic Matrix Inference in IP Networks Networks 2002-Topic 2A, Networks 2002, Munich, Germany, June 2002.


308

REFERENCES

[BSD00]

A. Bouch, M.A. Sasse and H. DeMeer, “Of Packets and People: A user-centered approach to Quality of Service”, in Proc. IWQoS’00 , Pittsburgh, IEEE., June 2000.

[CDF + 00]

R. Caceres, N. Duffield, A. Feldmann, J.D. Friedmann, A. Greenberg, R. Greer, T. Johnson, C.R. Kalmanek, B. Krishnamurthy, D. Lavelle, P.P. Mishra, J. Rexford, K.K. Ramakrishnan, F.D. True and J.E. van der Memle, “Measurement and analysis of IP network usage and behavior”, IEEE Communications Magazine 38, p. 144–ff., 2000.

[CCL + 02]

J. Cao, W. Cleveland, D. Lin and D. Sun “Internet traffic tends toward Poisson and independent as the load increases”, to appear in D. Dennison, M. Hansen, C. Holmes, B. Mallick, and B. Yu (eds). Nonlinear Estimation and Classification, New York, Springer, 2003.

[CIM99]

Common Information Model (CIM) Specification, version 2.2, DMTF, June 1999.

[Cla01]

A.D. Clark, Modeling the Effects of Burst Packet Loss on Recency of Subjective Voice Quality, IPTel 2001, available from http://www.fokus.gmd.de/events/iptel2001/ pg/final program/21.pdf.

[Cru91a]

R.L. Cruz, “A calculus for network delay, Part I: Network elements in isolation”, IEEE Transactions on Information Theory, 37, 1991, p. 114–ff.

[Cru91b]

R.L. Cruz, “A calculus for network delay, Part II: Network analysis”, IEEE Transactions on Information Theory, 37, 1991, p. 132–ff.

[CZ02]

Y. Cheng and W. Zhuang, “DiffServ resource allocation for fast handoff in wireless mobile Internet” IEEE Communications Magazine, May 2002 p. 130–ff.

[DG01]

N.G. Duffield and M. Grossglauser, “Trajectory sampling for direct traffic observation”

REFERENCES

309

IEEE/ACM Transactions on Networking 9, 3, June 2001, pp. 280–292. [ECN02]

M. Eder, H. Chaskar and S. Nag, “IP Service management in the QoS network”, draft-irtf-smrg-ipsmf-03.txt, July 2002 (work in progress).

[FG95]

D. Ferrari and A. Gupta “Admission control for advance reserved real-time connections”, in Proc. 3rd IEEE Workshop on the Architecture and Implementation of High-performance Communication Subsystem, IEEE. p. 52–ff., 1995.

[FGL + 00]

A. Feldmann, A. Greenberg, C. Lund, N. Reingold and J. Rexford, “NetScope: traffic engineering for IP networks”, IEEE Network , March/April 2001, p. 11–ff.

[FGL + 00b]

A. Feldmann, A. Greenberg, C. Lund, N. Reingold, J. Rexford and F. True, “Deriving traffic demands for operational IP networks: methodology and experience, in Proc. ACM SIGCOMM’00 , Stockholm, Sweden, 2000.

[Fin02]

V. Fincberg, “A practical architecture for implementing end-to-end QoS in an IP network”, IEEE Communications Magazine, January 2002, p. 122–ff.

[FMS + 02]

M. Fine, K. McCloghric, J. Seligson, K. Chan, S. Hahn, C. Bell, A. Smith and F. Reichmeyer, “Differentiated Services Quality of Service Policy Information Base”, draft-ietf-diffserv-pib-09.txt (work in progress).

[FT00]

B. Fortz and M. Thorup “Internet traffic engineering by optimizing OSPF weights”, in Proc. Infocom 2000 , Tel Aviv, Israel, 2000.

[G.107]

The E-Model: A Computational Model for Use in Transmission Planning, ITU-T Recommendation G.107, May 2000.

[G.108]

Application of the E-model: A Planning Guide, ITU-T recommendation G.108, September 1999.

310

[G.109]

[G.114]

REFERENCES

Definition of Categories of Speech Transmission Quality, ITU-T recommendation G.109, September 1999. One-way Transmission Time, ITU-T recommendation G.114, February 1996.

[G.1000]

Communications Quality of Service: A framework and Definitions, ITU-T recommendation G.1000, November 2001.

[G.1010]

End-user Multimedia QoS Categories, ITU-T Recommendation G.1010, November 2001.

[GC02]

Y. Guo and H. Chaskar “Class-Based Quality of Service over Air Interfaces in 4G Mobile Networks” IEEE Communications Magazine, March 2002, p. 132–ff.

[GCK + 01]

P. Gevros, J. Crowcroft, P. Kirstein and S. Bhatti, “Congestion control mechanisms and the best effort service model”, IEEE Network , May/June 2001, p. 16–ff.

[HCY + 01]

J. He, C.E. Chow, J. Yang and T. Chujo, “An algorithm for available bandwidth measurement”, in Proc. ICN’01, Colmar, France, July 2001; part 1, p. 753–ff., Lecture Notes in Computer Science 2094, Springer Verlag, 2001.

[HRS02]

O. Heckmann, F. Rohmer and J. Schnitt, The Token Bucket Allocation and Reallocation Problem, submitted to NOSSDAV 2002. Available on the Internet at http://www.kom.e-technik.tudarmstadt.de/publications/abstracts/HRS011.html.

[HT00]

H. Holma and A. Toskala (eds), WCDMA for UMTS , Chichester, John Wiley & Sons, 2000.

[I.350]

General Aspects of Quality of Service and Network Performance in Digital Networks, Including ISDN, ITU-T recommendation 1.350, March 1993.

[I.380]

Internet Protocol Data Communication Service: IP Packet Transfer and Availability Performance Parameters, ITU-T recommendation 1.380, February 1999.

REFERENCES

311

[IRT01]

IP in the RAN as a Transport Option in 3rd Generation Mobile Systems, technical report MTR-006, v2.0.0, June 2001, Mobile Wireless Internet Forum.

[JC01]

Y. Jia and M. Chen, “A novel architecture of providing guaranteed services for differentiated services network”, in Proc. EUROCON’01, 2001, p. 492, IEEE.

[JH00]

J. Jormakka and K. Heikkinen, “Qos/GOS parameter definitions and measurement in IP/ATM networks” in Proc. “Quality of future Internet Services”, Lecture Notes in Computer Science 1922, Berlin, Springer Verlag, 2000.

[Kap99]

D.A. Kaplan, The Silicon Boys, New York, William Morrow and Company, 1999.

[Kel97]

E. Kelly, “Charging and rate control for elastic traffic”, European Transactions on Telecommunications 8, p. 33–ff., 1997.

[Kil99]

K. Kilkki, Differentiated Services for the Internet , Indianapolis, MacMillan Technical Publishing, 1999.

[Kos01]

D. Kosiur, Understanding Policy-Based Networking, New York, John Wiley & Sons, Inc., 2001.

[KP01]

R. Koodli and M. Puuskari, “Supporting packet-data QoS in next-generation cellular networks” , IEEE Communications Magazine, February 2001, p. 180–ff.

[KR98]

K. Kilkki and J. Ruutu, “Simple integrated media access: an Internet service based on priorities”, in Proc. 6th International Conference on Telecommunication Systems, March 1998, Nashville, TN.

[Kre88]

E. Kreysig, Advanced Engineering Mathematics, New York, John Wiley & Sons, Inc., 1988.

[KYK02]

D. Katz, D. Yeung, and K. Kompella, Traffic Engineering Extensions to OSPF, draft-katz-

312

REFERENCES

yeung-ospf-traffic-06.txt, April 2002 (work in progress). [Lak02]

J. Lakkakorpi, “Simple measurement-based admission control for DiffServ access networks”, in Proc. ITCom 2002, July 2002, Boston, SPIE.

[LB99]

K. Lai and M. Baker, “Measuring bandwidth”, in Proc. Infocom’99, p. 235–ff, New York, IEEE, 1999.

[LCH01]

Y-D. Lin, C-H. Chang and Y-C. Hsu “Bandwidth brokers and book-ahead requests for differentiated services networks”, in Proc. GLOBECOM’01, p. 2285–ff., IEEE, 2001.

[LCT + 02]

W. Sum Lai, B. Christian, R.W. Tibbs and S. Van der Berghe, A Framework for Internet Traffic Engineering Measurement, draft-ietf-tewg-measure-03.txt, September 2002 (work in progress).

[LDP02]

L-A. Larzon, M. Degermark and S. Pink, The UDPLite protocol, draft-ietf-tsvwg-udp-lite-00.txt, January 2002 (work in progress).

[LFT + 02]

F. Le Faucheur, T. Nadeau, M. Tatham, T. Telkamp, D. Cooper, J. Boyle, W. Lai, L. Fang, J. Ash, P. Hicks, A. Chiu, W. Townsend and D. Skalecki, Requirements for Support of DiffServ-Aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-reqts-04.txt, April 2002 (work in progress).

[LRR01]

A. Lakaniemi, J. Rosti and V. Räisänen, “Subjective VoIP speech quality evaluation based on network measurements”, in Proc. ICC’01, IEEE. Helsinki, Finland, June 2001.

[LTW + 94]

W.E. Lcland, M.S. Taqqu, W. Willinger and D.V. Wilson, “On the self-similar nature of Ethernet traffic”, IEEE/ACM Transactions on Networking 2, 1994, p. 1–ff.

[MBB00]

T. McGregor, H-W. Braun and J. Brown, “The NLANR network analysis infrastructure”, IEEE

REFERENCES

313

Communications Magazine 38, May 2000, p. 122–ff. [MC00]

W. Matthews and L. Cottrell, “The PingER project: active Internet performance monitoring for the HENP community”, IEEE Communications Magazine 38, May 2000, p. 130–ff.

[McD00]

D. McDysan, QoS and Traffic Management in IP and ATM Networks, New York, McGraw-Hill, 2000.

[MCR + 02]

A. Morton, L. Ciavattone, G. Ramachandran, S. Shalunov and J. Perser, Reordering Metric for IPPM, draft-ietf-ippm-reordering-00.txt, June 2002 (work in progress).

[MNV02]

S.I. Maniatis, E.G. Nikolouzou and I.S. Venieris, “QoS issues in the converged 3G wireless and wired network”, IEEE Communications Magazine, August 2002, p. 44–ff.

[NC01]

K. Nichols and B. Carpenter, Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification, draft-ietf-diffserv-pdb-def-03 (work in progress).

[NGTRANS]

See NGTRANS home page at http://www.ietf.org/html.charters/ngtranscharter.html.

[ns2]

M. Greis, Tutorial for the UCB/LBNL/VINT network simulator “ns” http://www.isi.edu/nsnam/ns/tutorial/index. homepage at http://www.isi.edu/nsnam/ns/ns2.

[NZA99]

T.D. Ncamc, M. Zukerman and R.G. Addie “Modeling Broadband Traffic Streams” in Proc. Globecom 1999, Rio de Janeiro, Brazil, IEEE, 1999.

[Old86]

D. Oldroyd, The Arch of Knowledge: An Introductory Study of the History of the Philosophy and Methodology of Science, London, Routledge, 1986.

314

REFERENCES

[P800]

Methods for Subjective Determination of Transmission Quality, ITU-T recommendation p. 800, August 1996.

[P861]

Objective Quality Measurement of Telephone-band (300-3400 Hz) Speech Codecs, ITU-T recommendation 861, January 1998.

[P862]

Perceptual Evaluation of Speech Quality (PESQ): An Objective Method for End-to-end Speech Quality Assessment of Narrowband Telephone Networks and Speech Codecs, ITU-T recommendation 862, January 2001.

[Pax97]

V. Paxson, “Measurements and analysis of end-to-end Internet dynamics”, PhD thesis, UCB/LaNL, 1997.

[Pax97b]

V. Paxson, “End-to-end routing behaviour in the Internet”, IEEE/ACM Transactions on Networking 5, 1997, p. 601–ff.

[PB01]

J-T. Park and J-W Back, “Management of service level agreements for multimedia Internet service using a utility model”, IEEE Communications Magazine, May 2001, p. 100–ff.

[PFT + 98]

J. Padhye, V. Firoiu, D. Towsley and J. Kurose, “Modeling TCP throughput: a simple model and its empirical validation”, in Proc. SIGOMM’98 . Vancouver, ACM 1998.

[PPT + 02]

S. Papavassiliou, A. Pulifito, O. Tomarchio and J. Ye, “Mobile agent based approach for efficient network management and resource allocation: framework and applications”, IEEE Journal on Selected Areas in Communications, 20, 2002, p. 858–ff.

[PS00]

J.M. Pitts and J.A. Schormans, Introduction to IP and ATM Design and Performance, Chichester, John Wiley & Sons, Ltd., 2000.

[QBA02]

B. Teitelbaum and P. Cimento (eds), QBone Bandwidth Broker Architecture, available from QBone home page http://qbone:internet2.edu/bb/bboutline2.html.

REFERENCES

315

[QBB02]

B. Teitelbaum (ed.), OBone Architecture vl. 0, available from QBone home page http://www.internet2.edu/wg/documentsinformational/draft-i2-qbone-arch-1.0.html.

[Rai01]

V. Räisänen, “Measurement-Based IP Transport Resource Manager Demonstrator”, in Proc. ICN’01, Colmar, France, part 2, p. 127–ff., Lecture Notes in Computer Science 2094, Berlin. Springer Verlag, July 2001.

[Rai02]

V. Räisänen, “On end-to-end analysis of packet loss”, to appear in Computer Communications.

[Rai02b]

V. Räisänen, “On analysis of delay”, 2002, submitted.

[Rai02c]

V. Räisänen, “Bandwidth brokers and DiffServ in 3rd generation cellular networks”, 2002, submitted.

[RCC + 02]

J. Rajahalme, A. Conta, B. Carpenter and S. Deering, “IPv6 Flow Label Specification”, draft-ietf-ipv6-flow-label-01.txt, March 2002 (work in progress).

[RE00]

V. Räisänen and J-E. Ekberg, “network traffic police and shaper: algorithm and QoS properties”, in Proc. NetWord + InterOp 2000 Engineers’ Conference”, Las Vegas, IEEE, May 2000.

[RFC1633]

R. Braden, D. Clark and S. Shenker, “Integrated Services in the Internet Architecture: An Overview”, RFC 1633, June 1994, IETF.

[RFC1757]

S. Waldbusser, “Remote Network Monitoring Management Information Base”, RFC 1757, February 1995, IETF.

[RFC1889]

H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications”, RFC 1889, January 1996, IETF.

[RFC1932]

A. Conta, D. Shur and C. Villamizar, “IP over ATM: A Framework Document”, RFC 1932, April 1996, IETF.

316

REFERENCES

[RFC2021]

S. Waldbusser, “Remote Network Monitoring Management Information Base - version 2 using SMIv2”, RFC 1757, January 1997, IETF.

[RFC2205]

R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, “Resource ReserVation Protocol - Version 1 Functional Specification”, RFC 2205, September 1997, IETF.

[RFC2211]

J. Wroclawski, “Specification of the Controlled-Load Network Element Service”, RFC 2211, September 1997, IETF.

[RFC2212]

S. Shenker, C. Partridge and R. Guerin, “Specification of Guaranteed Quality of Service”, RFC 2212, September 1997, IETF.

[RFC2215]

S. Shenker and J. Wroclawski, “General Characterization Parameters for Integrated Service Network Elements”, RFC 2215, September 1997, IETF.

[RFC2330]

V. Paxson, G. Almes, J. Mahdavi and M. Mathis, “Framework for IP Performance Metrics”, RFC 2330, 1998, IETF.

[RFC2381]

M. Garrett and M. Borden, “Interoperation of Controlled-load Service and Guaranteed Service with ATM”, RFC 2381, August 1998, IETF.

[RFC2460]

S. Deering and R. Hinden, “Internet Protocol, Version 6, Specification”, RFC 2460, December 1998, IETF.

[RFC2475]

D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang and W. Weiss, “An Architecture for Differentiated Services”, RFC 2475, December 1998, IETF.

[RFC2564]

C. Kalbfleisch, C. Krupczak, R. Presuhn and J. Saperia, “Application Management MIB”, RFC 2564, May 1999, IETF.

[RFC2597]

J. Heinänen, F. Baker, W. Weiss and J. Wroclawski, “Assured Forwarding PHB group”, RFC 2597, June 1999, IETF.

REFERENCES

317

[RFC2598]

V. Jacobson, K. Nichols and K. Poduri, “An Expedited Forwarding PHB”, RFC 2598, June 1999, IETF.

[RFC2638]

K. Nichols, V. Jacobson and L. Zhang, “A Two-Bit Differentiated Services Architecture for the Internet”, RFC 2638, July 1999, IETF.

[RFC2679]

G. Almes, S. Kalidindi and M. Zekauskas, “A One-way Delay Metric for IPPM”, RFC 2679, September 1999, IETF.

[RFC2680]

G. Almes, S. Kalidindi and M. Zekauskas, “A One-way Packet Loss Metric for IPPM”, RFC 2680, September 1999, IETF.

[RFC2681]

G. Almes, S. Kalidindi and M. Zekauskas, “A Round-trip Delay Metric for IPPM”, RFC 2681, September 1999, IETF.

[RFC2702]

D. Awduche, J. Malcolm, J. Agogbua, M. O’Dell, and J. McManus, “Requirements for Traffic Engineering over MPLS”, RFC 2702, September 1999, IETF.

[RFC2814]

R. Yavatkar et al., “SBM (Subnet Bandwidth Manager): A Protocol for RSVP-Based Admission Control over IEEE 802-style Networks”, RFC 2814, May 2000, IETF.

[RFC2815]

M. Seaman, A. Smith, E. Crawley and J. Wroclawski, “Integrated Service Mappings on IEEE 802 Networks”, RFC 2815, May 2000, IETF.

[RFC2819]

S. Waldbusser, “Remote Network Monitoring Management Information Base”, RFC 2819, May 2000, IETF.

[RFC3052]

M. Eder and S. Nag, “Service Management Architectures Issues and Review”, RFC 3052, January 2001, IETF.

[RFC3060]

B. Moore, E. Ellesson, J. Strassner and A. Westerinen, “Policy Core Information Model – Version 1 Specification”, February 2001, RFC 3060, IETF.

318

REFERENCES

[RFC3086]

K. Nichols and B. Carpenter, “Definition of Differentiated Services Per-Domain Behaviours and Rules for their Specification”, RFC 3086, April 2001, IETF.

[RFC3140]

D. Black, S. Brim, B. Carpenter and F. Le Faucher, “Per Hop Behaviour Identification Codes”, RFC 3140, June 2001, IETF.

[RFC3175]

F. Baker, C. Iturralde, F. LeFaucheur and B. Davie, “Aggregation of RSVP for IPv4 and IPv6 reservations”, RFC 3175, September 2001, IETF.

[RFC3246]

B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu and D. Stiliadis, “An Expedited Forwarding PHB”, RFC 3246, March 2002, IETF.

[RFC3260]

D. Grossman, “New Terminology and Clarifications for Diffserv”, RFC 3260, April 2002, JETF.

[RFC3261]

J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley and E. Schooler, “SIP: Session Initiation Protocol”, RFC 3261, June 2002, IETF.

[RFC3270]

F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, and J. Heinanen, “MPLS Support of Differentiated Services”, RFC 3270, May 2002, IETF.

[RFC3272]

D.O. Awduche, A. Chiu, A. Elwalid, I. Widjaja and X. Xiao, “Overview and Principles of Internet Traffic Engineering”, draft-ietf-tewg-principles0.2.txt, November 2001, IETF (work in progress).

[RFC3289]

F. Baker, K. Chan and A. Smith, “Management Information Base for the Differentiated Services Architecture”, RFC 3289, May 2002, IETF.

[RFC3290]

Y. Bernet, S. Blake, D. Grossman and A. Smith, “An Informal Management Model for DiffServ Routers”, RFC 3290, May 2002, IETF.

[RFC3432]

V. Räisänen, G. Grotefeld, and A. Morton, “Network Performance Measurement for

REFERENCES

319

Periodic Streams”, RFC 3432, November 2002, IETF. [RKT + 94]

R. Ramjee, J. Kurose, D. Towsley and H. Schulzrinne, “Adaptive playout mechanisms for packetized audio applications in wide-area networks”, in Proc. INFOCOM’94”, 1994, p. 680–ff.

[RL02]

V. Räisänen and A. Lakaniemi, “A General Method for Analyzing and Generating Packet Loss patterns”, in Proc. ICC’02”, New York, IEEE, 2002.

[RR00]

V. Räisänen and J. Rosti, “Application-level IP measurements for multimedia”, in Proc. IWQoS’00”, p. 170–ff, Pittsburgh, IEEE, June 2000.

[SAF + 01]

V. Sander, W.A. Adamson, L. Foster and A. Roy, “End-to-end provision of policy information for network QoS”, in Proc. High Performance Distributed Computing”, 2001, p. 115–ff.

[SB02]

R.M. Salles, “Utility-based scheduling disciplines for adaptive applications over the Internet”, IEEE Communications Letters 6, 2002, p. 217–ff.

[SBD + 01]

A. Sridharan, S. Bhattacharyya, C. Diot, R. Guerin, J. Jetcheva and N. Taft, On The Impact of Aggregation on the Performance of Traffic Aware routing, Technical Report, University of Pennsylvania, June 2000 (shortened version presented at ITC’17, Salvador da Bahia, Brazil, 24–28, September 2001).

[Sch98]

O. Schelen, “Quality of Service Agents in the Internet”, Lule˚a University of Technology, Department of Computer Science and Electrical Engineering, Sweden, August 1998.

[Sch00]

Bruce Schneier, Secrets and Lies, New York, John Wiley & Sons, Inc., 2000.

320

REFERENCES

[SLC + 00]

N. Semret, R.R-F. Liao, A.T. Campbell and A.A. Lazar, “Pricing provisioning, and peering dynamic markets for differentiated internet services and implications for network interconnections”, in IEEE Journal on Selected Areas in Communications, 18, 2000, p. 2499–ff.

[SMH01]

“SLA Management Handbook”, public evaluation version 1.5, TeleManagement Forum, June 2001.

[SMJ00]

R. Sturm, W. Morris and M. Jander, “Foundations of Service Level Management”, Indianapolis, SAMS, 2000.

[SP98]

O. Schelén and S. Pink, “Resource reservation agents in the Internet”, in Proc. NOSSDAV’98”, p. 153–ff., Cambridge, July 1998.

[St98]

R. Stevens, Unix Network Programming vol 1 – Networking APIs: Sockets and XII , Upper Saddle River, NJ, Prentice-Hall, 1998.

[SV02]

S. Salsano and L. Veltri, “Qos control by means of COPS to support SIP-based applications”, IEEE Network”, March/April 2002, p. 27–ff.

[SZ99]

I. Stoica and H. Zhang, “Providing guaranteed services without per-flow management”, in Proc. SIGCOMM’99”, ACM, 1999.

[TAP + 01]

P. Trimintzios, I. Andrikopoulos, G. Pavlou et al., “A management and control architecture for providing IP differentiated services in MPLS-based networks, IEEE Communications Magazine, May 2001 issue, p. 80–ff.”

[THD + 99]

B. Teitelbaum, S. Hares, L. Dunn, R. Neilson, V. Narayan and F. Reichmayer, “Internet2 OBone: building a testbed for differentiated services, IEEE Network”, September/October 1999, p. 8–ff.

[TIPHON-1]

“End-to-end Quality of Service in TIPHON Systems, Part 1: General Aspects of Quality of Service (QoS)”, TR/TIPHON 101 329-1.

REFERENCES

[TIPHON-2]

[TIPHON-3]

[TIPHON-5]

[TIPHON-6]

[TIPHON-7]

[UDPL]

[UNI]

[Wang01]

[Y.1221]

[Y.1541]

321

“End-to-end Quality of Service in TIPHON Systems, Part 2: Definition of Speech Quality of Service (QoS) Classes”, TS/TIPHON 101329-2. “End-to-end Quality of Service in TIPHON Systems, Part 3: The Signalling and Control of End-to-end Quality of Service in TIPHON Systems”, TS/TIPHON 101 329-3. “End-to-end Quality of Service in TIPHON Systems, Part 5: Quality of Service (QoS) Measurement Methodologies”, TS/TIPHON 101 329–5. “End-to-end Quality of Service in TIPHON Systems, Part 6: Actual Measurement of Network and Terminal Characteristics and Performance Parameters in TIPHON Networks and Their Influence on Voice Quality”, TR/TIPHON 101 329–6. “End-to-end Quality of Service in TIPHON Systems, Part 7: Design Guide for Elements of a TIPHON Connection from an End-to-end Speech Transmission Performance Point of View”, TR/TIPHON 101 329-7. UDPLite was defined in IETF draft “larzon-udplite-03”, which has now expired. It can be found, for example, on http://alternic.net/drafts/drafts-l-m/draftlarzon-udplite-03.html. “User-Network Interface Signalling Specification”, version 3.2, af-uni-0010.002, ATM Forum, September 1994. Z. Wang, Internet QoS: Architectures and Mechanisms for Quality of Service, San Diego, Morgan Kaufmann Publishers, 2001. “Traffic Control and Congestion Control in IP-based Networks”, ITU-T recommendation, March 2002 (prepublished). “Network Performance Objectives for IP-based Services”, ITU-T recommendation Y.1541, May 2002 (prepublished).

Index 2.5G networks 2 3GPP QoS model 17, 145 Aggregate performance measurements 105 Assured Forwarding (AF) 78, 81 ATM overlays 85, 88 ATM service quality support 69 Availability 33 Bandwidth broker 252 Generic model for 263 QBone 256 QoS agent 261 Two-bit architecture 255 Best Effort (BE) 53, 72 Capacity planning 114, 286 Capacity reservation 55, 63, 64 Capacity savings 56, 277 CIM model 183 Conditioning 61 Configuration 125 Converged networks 4–5, 300 Continuity 34

Continuous service data unit Transmission 39 Controlled-load service 74 Customer perspective 2, 184

Decoupling of access and services 4 Delay 164 Time series 170 variation 40, 168 Delivery time 35 Differentiated service instantiation 63, 67 Differentiated treatment 55, 57, 63, 65 DiffServ 77, 300 Complementary technologies 302 D. Code Point (DSCP) 78 Over MPLS 121 DMTF model 183 Drivers for multi-service IP networks 1 Dynamic service admission control 273


324

Endpoints 200 End-to-end service quality 10, 198 Expedited Forwarding (EF) 78, 79 Guaranteed QoS 75 Intelligent Networks 16 Inter-domain signalling 271 IP-based RAN 275 Handover traffic 282 Inter-operation 295 Measurements 294 Policy-based management 292 Service mapping 283 Traffic engineering 285 Transport architecture 281 IPv6 86 IP routing 85 IP service quality support models 71, 83 Link layer service quality support 90 Measured characteristics 220, 223 Measurement Architectures 235, 241 Infrastructure 230 In IP-based RAN 294 interfaces 222 methods 225 Messaging 3, 13 Mean Opinion Score (MOS) 25 Multi-Protocol Label Switching (MPLS) 89 Traffic engineering using 120 Multi-service quality support 53 Network monitoring 216 Network optimisation 116 Operators Service 134 Transport 134

INDEX

Operator perspective 4, 187 Optimisation 174 Overdimensioning 55 Packet loss Correlation 171 Rate 171 Per-Domain Behaviour (PDB) 78, 194 Performance Analysis 104 End-to-end service level p. 109 Enhancement 113 Measurement 104 Per-Hop Behaviour (PHB) 78 Per-node traffic control 115 Policing 58 Actions based on Policy-based management 126 In IP-based RAN 292 Of DiffServ 129 Protocol optimisation 6 QBone 142 Measurements 235 Service support model 143 QoS Definition of 9 QoS budgets 11, 163 Recency effect 26 Reliability 42 Reporting 190 Resource Management 114 Resource Reservation Protocol (RSVP) 76 Routing control 110, 114, 117 Optimisation 119 Sampling methodology 46 Scheduling 93 Service Adaptive services 29 Aggregated service 18 Brokers 207

INDEX

Client/server services 12 Connectivity service 22 Definition of 12, 16 Service definition 188 Service event 20 Service instance 20 End user service 18 Point-to-point service 14 Psychological factors 27 Push-type services 14 Service provider perspective 6 Service Level Agreement (SLA) 18, 22, 133, 191 Contents 196 End-user SLA 155, 156, 197 For DiffServ 193 Service provider 156 Other providers 157 Service Level Management 179, 303 Service Level Specification (SLS) 193 Service provider 134 Service quality Budget 163 characterizations 30 Descriptors 47 Effect of L4 protocols on 28, 61 Planning 184 service quality estimation 23 service quality measures 24 service quality requirement 19, 22, 24, 32 support, dynamic 252 support instance 58

325

support instantiation control 265 support mechanisms 10 Signalling 154 Support for variable transfer rate 44 Temporal correlation of characteristics 50 Throughput 38, 173 TIPHON QoS classes 32, 140 QoS model 137 Token bucket 48 Traffic characterization 213 Traffic Conditioning Agreement (TCA) 193 Traffic Conditioning Block (TCB) 82 Traffic Conditioning Specification 193 Traffic control 219 Traffic Engineering Context of 100 Definition of 97–98 Process 102 Role ˆ of 304 Using MPLS 120 Using IP routing protocols 123 Traffic Matrix 112 Troubleshooting measurements 217 Two-bit architecture 255 Utility-based allocation

235

Implementing Service Quality in IP Networks

Voice over IP Networks: Quality of Service, Pricing and Security

Programmable Networks for IP Service Deployment

IP in Wireless Networks

Implementing Voice over IP

Implementing voice over IP

Computer Networks: Performance and Quality of Service

Voice over IP Networks: Quality of Service, Pricing and Security (Lecture Notes in Electrical Engineering)

Understanding and Implementing Quality

Quality of Service in Wireless Networks Over Unlicensed Spectrum

Quality of Service Control in High-Speed Networks

Cisco Catalyst(R) QoS: Quality of Service in Campus Networks

Quality of Service Control in High-Speed Networks

Implementing virtual private networks

Building Resilient IP Networks

Developing IP multicast networks

Developing IP multicast networks

Building Service Provider Networks

End-to-End Quality of Service Over Heterogeneous Networks

Administering Cisco QoS in IP Networks

End-to-End Quality of Service over Cellular Networks

Building service provider networks

Building Service Provider Networks

Delivering Voice over Ip Networks

All IP in 3G CDMA Networks: The UMTS Infrastructure and Service Platforms for Future Mobile Systems

All IP in 3G CDMA Networks: The UMTS Infrastructure and Service Platforms for Future Mobile Systems

Implementing Service Quality in IP Networks

Voice over IP Networks: Quality of Service, Pricing and Security

Programmable Networks for IP Service Deployment

IP in Wireless Networks

Implementing Voice over IP

Implementing voice over IP

Computer Networks: Performance and Quality of Service

Voice over IP Networks: Quality of Service, Pricing and Security (Lecture Notes in Electrical Engineering)

Understanding and Implementing Quality

Quality of Service in Wireless Networks Over Unlicensed Spectrum

Quality of Service Control in High-Speed Networks

Cisco Catalyst(R) QoS: Quality of Service in Campus Networks

Quality of Service Control in High-Speed Networks

Implementing virtual private networks

Building Resilient IP Networks

Developing IP multicast networks

Developing IP multicast networks

Building Service Provider Networks

End-to-End Quality of Service Over Heterogeneous Networks

Administering Cisco QoS in IP Networks

End-to-End Quality of Service over Cellular Networks

Building service provider networks

Building Service Provider Networks

Delivering Voice over Ip Networks

All IP in 3G CDMA Networks: The UMTS Infrastructure and Service Platforms for Future Mobile Systems

All IP in 3G CDMA Networks: The UMTS Infrastructure and Service Platforms for Future Mobile Systems

Recommend Documents