Multicast communication : protocols and applications 9781558606456, 1558606459, 9783920993409, 3920993403

Table of contents :
1. Introduction 2.The Basics of Group Communication 3. Multicast Routing 4. Quality of Service 5. Multicast in ATM Networks 6. Transport Protocols 7. MBone--the Multicast Backbone of the Internet 8. Outlook

Citation preview

Multicast Communication Protocols and Applications

The Morgan Kaufmann Series in Networking Series Editor, David Clark, MIT ■

Multicast Communication: Protocols and Applications Ralph Wittmann and Martina Zitterbart

■

MPLS: Technology and Applications Bruce Davie and Yakov Rekhter

■

High-Performance Communication Networks, Second edition Jean Walrand and Pravin Varaiya

■

Computer Networks: A Systems Approach, Second edition Larry L. Peterson and Bruce S. Davie

■

Internetworking Multimedia Jon Crowcroft, Mark Handley, and Ian Wakeman

■

Understanding Networked Applications: A First Course David G. Messerschmitt

■

Integrated Management of Networked Systems: Concepts, Architectures, and Their Operational Application Heinz-Gerd Hegering, Sebastian Abeck, and Bernhard Neumair

■

Virtual Private Networks: Making the Right Connection Dennis Fowler

■

Networked Applications: A Guide to the New Computing Infrastructure David G. Messerschmitt

■

Modern Cable Television Technology: Video, Voice, and Data Communications Walter Ciciora, James Farmer, and David Large

■

Switching in IP Networks: IP Switching, Tag Switching, and Related Technologies Bruce Davie, Paul Doolan, and Yakov Rekhter

■

Wide Area Network Design: Concepts and Tools for Optimization Robert S. Cahn

■

Optical Networks: A Practical Perspective Rajiv Ramaswami and Kumar N. Sivarajan

■

Practical Computer Network Analysis and Design James D. McCabe

■

Frame Relay Applications: Business and Technology Case Studies James P. Cavanagh

For further information on these and other Morgan Kaufmann books, and for a list of forthcoming titles, please visit our Web site at www.mkp.com.

Multicast Communication Protocols and Applications Ralph Wittmann Martina Zitterbart Technical University of Braunschweig Braunschweig, Germany

Senior Editor: Jennifer Mann Director of Production and Manufacturing: Yonie Overton Senior Production Editor: Robin Demers Editorial Coordinator: Karyn Johnson Cover Design: Ross Carron Design Text Design: Rebecca Evans and Associates Translator: Hedwig Jourdan von Schmöger Copyeditor: Ken DellaPenta Proofreader: Sharilyn Hovind Composition and technical art: Technologies ’N Typography Indexer: Steve Rath Printer: Courier Corporation Cover image: Thermal image of a backbone, © 2001 PhotoDisc, Inc. ACADEMIC PRESS A Harcourt Science and Technology Company 525 B Street, Suite 1900, San Diego, CA 92101–4495, USA http://www.academic press.com Academic Press Harcourt Place, 32 Jamestown Road, London, NW1 7BY, United Kingdom http://www.hbuk.co.uk/ap/ Morgan Kaufmann Publishers 340 Pine Street, Sixth Floor, San Francisco, CA 94104–3205, USA http://www.mkp.com © 1999 dpunct—Verlag für digitale Technologie Title of German original: Multicast: Protok le und Anwendungen ISBN 3-920993-40-3 Translation © 2001 by Academic Press All rights reserved Printed in the United States of America 05 04 03 02 01

5 4 3 2 1

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, or otherwise—without the prior written permission of the publisher. Library of Congress Cataloging-in-Publication Data is available for this book. ISBN 1–55860–645–9 This book is printed on acid-free paper.

To Heike and Judith

This Page Intentionally Left Blank

Contents

List of Acronyms Preface

xi

xv

1

Introduction

1

2

The Basics of Group Communication

7

2.1 Types of Communication 7 2.1.1 Unicast Communication 8 2.1.2 Multicast Communication 9 2.1.3 Concast Communication 10 2.1.4 Multipeer Communication 11 2.1.5 Other Types of Communication 13 2.2 Multicast vs. Unicast 16 2.3 Scalability 18 2.4 Applications of Group Communication 20 2.4.1 Distributed Databases 20 2.4.2 Push Technologies 22 2.4.3 Interactive Multimedia Applications 23 2.5 Characteristics of Groups 26 2.6 Special Aspects of Group Communication 29 2.6.1 Reliability 29 2.6.2 Flow and Congestion Control 36 2.6.3 Group Addressing and Administration 40 2.7 Support within the Communication System 44 2.7.1 Data Link Layer 45 2.7.2 Network Layer 47 2.7.3 Transport Layer 51 2.7.4 Application Layer 52

viii

Contents

3

Multicast Routing

53

3.1 Basic Routing Algorithms 53 3.1.1 Distance-Vector Algorithms 56 3.1.2 Link State Algorithms 60 3.2 Group Dynamics 62 3.3 Scoping and Multicast Address Allocation 67 3.3.1 Scope of Multicast Groups 67 3.3.2 Multicast Address Allocation 72 3.4 Concepts for Multicast Routing 76 3.4.1 Source-Based Routing 80 3.4.2 Steiner Trees 86 3.4.3 Trees with Rendezvous Points 88 3.4.4 Comparison of Basic Techniques 89 3.5 Multicast Routing on the Internet 90 3.5.1 DVMRP 91 3.5.2 Multicast Extensions to OSPF 97 3.5.3 PIM 105 3.5.4 CBT 117 3.5.5 Multicast Routing between Domains 119

4

Quality of Service

123

4.1 Integrated Services 124 4.1.1 Classes of Service Provided by Integrated Services 125 4.1.2 Receiver-Oriented Reservations in RSVP 133 4.1.3 Sender-Oriented Reservations with ST2 149 4.1.4 RSVP vs. ST2 155 4.2 Differentiated Services 156 4.2.1 Basic Concept 157 4.2.2 Proposals for Service Concepts for Differentiated Services 161 4.3 Differences and Integration Options 164 4.3.1 IntServ vs. DiffServ 164 4.3.2 Integration of DiffServ and IntServ 165

5

Multicast in ATM Networks

167

5.1 The Switching Technology ATM 167 5.1.1 ATM Adaption Layer 169 5.1.2 Service Categories in ATM 171

Contents 5.2 ATM Multicast 173 5.2.1 Multicast vs. Multipeer in ATM 5.2.2 LAN Emulation 176 5.2.3 IP Multicast over ATM 178 5.2.4 UNI Signaling 187

6

Transport Protocols

174

197

6.1 UDP 198 6.1.1 A Programming Example 199 6.1.2 Summary 203 6.2 XTP 204 6.2.1 Data Units 205 6.2.2 Connection Control 205 6.2.3 Data Transfer 210 6.2.4 Summary 213 6.3 MTP 214 6.3.1 Structure of a Web 215 6.3.2 Allocation of Transmission Rights 216 6.3.3 Data Transfer 217 6.3.4 Error Control 219 6.3.5 Maintaining Order and Consistency 221 6.3.6 Summary 223 6.4 RMP 224 6.4.1 Data Management 228 6.4.2 Group Management 230 6.4.3 Summary 232 6.5 LBRM 233 6.5.1 Data Transfer and Error Control 233 6.5.2 Summary 238 6.6 SRM 238 6.6.1 Data Transfer and Error Control 239 6.6.2 Summary 242 6.7 RMTP 243 6.7.1 Connection Control 244 6.7.2 Error Recovery 245 6.7.3 Flow and Congestion Control 249 6.7.4 Summary 250 6.8 PGM 251 6.8.1 Protocol Procedures 251 6.8.2 Options 255 6.8.3 Summary 257

ix

x

Contents 6.9 MFTP 257 6.9.1 Group Management 257 6.9.2 Data Transfer and Error Control 6.9.3 Enhancements 262 6.9.4 Summary 263

7

260

MBone—The Multicast Backbone of the Internet 7.1 MBone Architecture 266 7.1.1 The Loose-Source-Record Routing Option 7.1.2 IP-IP Encapsulation 270 7.2 MBone Applications 271 7.2.1 RTP 272 7.2.2 VideoConference 277 7.2.3 Visual Audio Tool 279 7.2.4 Robust Audio Tool 281 7.2.5 Free Phone 282 7.2.6 Whiteboard 284 7.2.7 Network Text Editor 286 7.2.8 Session Directory 286 7.2.9 Session Announcement Protocol 289 7.2.10 Session Description Protocol 291 7.2.11 Session Initiation Protocol 293 7.2.12 Conference Manager 298 7.2.13 Multimedia Conference Control 300 7.2.14 Inria Videoconferencing System 302 7.3 MBone Tools 303 7.3.1 Mrouted 303 7.3.2 Mrinfo 304 7.3.3 Mtrace 305

8

Outlook

268

309

8.1 Multicast Routing and Mobile Systems 310 8.2 Multicast and DiffServ 311 8.3 Active Networks for Supporting Group Communication 311 8.4 Group Management for Large Dynamic Groups

Bibliography 315 Index

265

329

About the Authors

350

313

Acronyms

AAL ABR ABR ABT ACK Adspec ALF ARP AS ATM

ATM Adaptation Layer All Boundary Routers Available Bit Rate ATM Block Transfer Acknowledgment Admission Specification Application Level Framing Address Resolution Protocol Autonomous System Asynchronous Transfer Mode

BGMP BGP BR BUS B-WiN

Border Gateway Multicast Protocol Border Gateway Protocol Border Router Broadcast and Unknown Server Broadband Research Network (Breitband Wissenschaftsnetz)

CBQ CBR CBT CLP CONF CSCW CSRC

Class-Based Queueing Constant Bit Rate Core-Based Trees Cell Loss Priority Confirmation Computer-Supported Cooperative Work Contributing Source

DBR DFN DiffServ DNS DR DVMRP

Deterministic Bit Rate German Research Network (Deutsches Froschungsnetz) Differentiated Services Domain Name Service Designated Router Distance Vector Multicast Routing Protocol

xii

Acronyms FDDI FF FQDN

Fiber Distributed Data Interface Fixed Filter Full Qualified Domain Name

HDVMRP HPIM

Hierarchical DVMRP Hierarchical PIM

ICMP IEEE IETF IGMP IntServ IP IRC ISDN ISO ITU ITU-T IVS

Internet Control Message Protocol Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internet Group Membership Protocol Integrated Services Internet Protocol Internet Relay Chat Integrated Services Digital Network International Organization for Standardization International Telecommunications Union ITU-Telecommunication Inria Videoconferencing System

LAN LANE LBRM LEC LECS LES LIS LRM LSA

Local-Area Network LAN Emulation Log-Based Receiver Multicast LAN Emulation Client LAN Emulation Configuration Server LAN Emulation Server Logical IP Subnet Local Resource Manager Link State Advertisement

MAAS MAC MARS MASC MBone MBone-DE MCS MOSPF MPEG MPOA MSD

Multicast Address Allocation Server Media Access Control Multicast Address Resolution Server Multicast Address Set Claim Protocol Multicast Backbone Multicast Backbone Germany Multicast Server Multicast OSPF Motion Picture Experts Group Multiple Protocols over ATM Multicast Source Distribution Protocol

Acronyms MTP MZAP

Multicast Transport Protocol Multicast-Scope Zone Announcement Protocol

NAK NNI Nrt-VBR NSAP NTP

Negative Acknowledgment Network-Network Interface Non-real-time VBR Network Service Access Point Network Time Protocol

OAM OSI OSPF

Operations and Maintenance Open Systems Interconnection Open Shortest Path First

PCM PERR PHB PIM PT PTEAR

Pulse Code Modulation Path Error Data Unit Per-Hop Behavior Protocol Independent Multicast Payload Type Path-Tear-Down Data Unit

QoS

Quality of Service

RED RERR RESV RFC RIO RIP RM RMP RMTP RP RPB RPF RPM Rspec RSVP RTCP RTEAR RTP RTT Rt-VBR

Random Early Discard Reservation Error Data Unit Reservation Data Unit Request for Comments RED with Input, Output Routing Information Protocol Resource Management Reliable Multicast Protocol Reliable Multicast Transport Protocol Rendezvous Point Reverse Path Broadcasting Reverse Path Forwarding Reverse Path Multicasting Reservation Specification Resource ReSerVation Protocol Real-time Control Protocol Reservation-Tear-Down Data Unit Real-time Transport Protocol Round-Trip Time Real-time VBR

xiii

xiv

Acronyms SAAL SAP SBR SCMP SDP SDR SF SRM SSCF SSCOP SSRC ST2 STM

Signaling AAL Session Announcement Protocol Statistical Bit Rate Stream Control Message Protocol Session Description Protocol Session Directory Shared Filter Scalable Reliable Multicast Service-Specific Convergence Functions Service-Specific Convergence Protocol Synchronization Source Stream Protocol Version 2 Synchronous Transfer Mode

TCP TRPB Tspec TTL

Transmission Control Protocol Truncated RPB Traffic Specification Time-to-Live

UBR UDP UNI URL USD

Unspecified Bit Rate User Datagram Protocol User-Network Interface Uniform Resource Locator User Shared Differentiation

VBR VC VCI VP VPI

Variable Bit Rate Virtual Channel Virtual Channel Identifier Virtual Path Virtual Path Identifier

WB WF WFQ WWW WYSIWIS XTP

Whiteboard Wildcard Filter Weighted First Queueing World Wide Web What You See Is What I See Xpress Transport Protocol

Preface

R

ecent developments in the area of computer-supported communication systems, or, more generally speaking, in information technology, have been enormous. Just think about the tremendous advances made in the global Internet. Five years ago, most development was essentially limited to different areas of research and sectors of industry; today references to Web sites can be found in almost every advertisement. The Internet with its applications, at least as far as the Web is concerned, has impacted the personal lives of people everywhere. In some places ordering goods over the Web is already an ordinary everyday activity, as is the acquisition of news and other information. The communication sector is booming in many ways, leading to a growing number of users and systems (e.g., IP-based embedded systems) attached to the Internet and to an increased commercialization of the Internet. This boom is accompanied by a major expansion of the basic technology of networks and communication systems. This book looks at the impressive changes that have taken place in computer-supported communication, moving from point-to-point communication to group communication, which is often referred to (although slightly inaccurately) as multicasting. We regard multicasting as the communication paradigm of the future. The problem is, however, that the appropriate communication technologies needed for this change are still in their infancy. This book presents the current state of development of these technologies and looks at some of the concepts that are already available today. It also outlines the need for further research and development in the sector of group communication. Many of the approaches that do exist have evolved in conjunction with the Internet. The Internet also already provides a suitable experimental network that gives some support for group communication, the MBone. However, usable solutions do not exist for all the approaches presented. We

xvi

Preface have nevertheless included even currently unused solutions in this book because they represent some trend-setting concepts. This book is aimed at those studying, as well as those teaching, in the area of networking and telecommunications. In addition to computer scientists, its audience includes electrical engineers and computer engineers. The book may also be useful to industry, particularly to the communication sector, where there should be an early involvement in these technologies so that companies can force their introduction into the market and be in a position to participate actively in the development of new concepts. In this respect, the book is suitable for use as a foundation for continuing education courses on the presented topics. Basic knowledge of the area of computer-supported communication is very helpful for understanding the content of this book. Although a detailed knowledge of all Internet protocols is not necessary, you should have a familiarity with the basic principles (such as how networks and protocols work in general), since these are not introduced in explicit detail. References to introductory or advanced literature are provided as an aid at appropriate places in the discussion. It is not our intention for this book to replace standard documents. Instead our objective is to present underlying concepts and procedures. While writing this book we were confronted by the highly dynamic nature of the development of new technologies for the support of group communication on the Internet. Draft documents tend to change at a considerable speed, especially on the Internet. However, certain basic trends are already evident. The German edition of this book represents the state of group communication at the end of 1998. The English translation was updated to include new concepts that have been presented recently, such as PGM and MFTP. But keep in mind that protocols and services for group communication are still very much under development. We would like to express our thanks at this point to Axel Böger and Kai Krasnodembski for their detailed review of the German version of the manuscript. They have both contributed improvements to some important aspects of the book. We are also grateful to Christa Preisendanz of the dpunkt.Verlag, who always showed a total commitment to the German book project and also developed an incredible talent for putting pressure on the authors. We would like to thank all the people at Morgan Kaufmann, especially Jennifer Mann, Karyn Johnson, Yonie Overton, and Robin Demers, for their great support. Many thanks to Hedwig Jourdan von

Preface Schmöger for the difficult translation of the manuscript. The reviewers of the translated manuscript, Jerrold Feigenbaum, Markus Hofmann, and Dave Thaler, helped considerably lot with their valuable and wellpointed comments. We alone are responsible for any remaining errors.

xvii

This Page Intentionally Left Blank

1 Introduction

I

nternet, multimedia, information superhighway—these are some of the key buzzwords today. They are linked to the innovation and incredible technical progress being made in the area of computersupported communication. The main feature that characterizes computer communication is the exchange of data between two computers. This is analogous to the evolution of the telephone: Initially only two participants were able to talk to one another. Today conference calls enable telephone connections to be set up among several participants, and speakerphones are frequently used when groups of people at two different locations wish to communicate with one another. Today the relatively new discipline of computer-supported communication is largely limited to the data exchange between two computers. Considerable technical progress has recently been made in computer-supported communication, enabling groups of computers to communicate with one another. This form of communication is referred to as group communication, and the indicators are that it will play a very important role in the future. The term group communication is a rather general term since a large number of different forms of it exist. The term will be used in a general sense throughout the book. Whenever an exact variant is important to a discussion, it will be explicitly mentioned. Multicast is one of the forms that is discussed in depth. It is also a form that in some cases is already being technically implemented today but in many areas is still a subject of research. Group communication is actually not a new concept, at least in terms of day-to-day interpersonal communication. This kind of communication is inherently based on an exchange of information within a group of people, for example, a few friends gathered together for a meal. They debate and talk about all sorts of things, and ultimately this is nothing more than a form of group communication. It is considerably more efficient to convey information to an entire group than separately to each member of the group. An example

Group communication will play an important role in the future Multicast, a special form of group communication

2

Chapter 1 — Introduction

Working in teams

CSCW

Open distance learning

would be a talk at a conference. The speaker expends significantly less effort giving the talk to all the conference participants at one time than making separate presentations to each member of the audience. There is a further advantage to the attendees in that topics of interest that they may not have previously given any thought to may be raised during the discussion following the talk. The advantages of group communication therefore extend beyond mere efficiency. Even the simple example of a conference lecture illustrates that group communication can provide advantages compared to communication restricted to two partners. One of the advantages is the efficiency achieved by reaching all members of a group at the same time. It therefore makes sense to look at ways of taking group communication as it is frequently performed in a social context and implementing it as computer-supported communication. What makes this particularly significant is that with some applications, computersupported communication provides the basic infrastructure for interpersonal communication or cooperation—for example, in the case of distributed teamwork, which is an increasingly important process. An example of this is an international project group with its members located at different sites (see Figure 1.1). This is often referred to in the literature as computer-supported cooperative work (CSCW), or groupware. In this sense group communication represents a current research area for applications. Examples of applications include videoconferencing with a shared whiteboard and tools designed for coordination between participants. Due to the increasing reduction in the half-life of knowledge, distance learning in the training and continuing education area is taking on an increasingly important role in society. The term open distance learning summarizes the different methods that exist for the support of distance learning. Teleteaching usually refers to a scenario in which a student can be in one place and yet be able to participate in a class that is taking place at the same time somewhere else. For example, a class given by a center for continuing education can be experienced directly at a student’s workplace. This is important for the purpose of lifelong learning. The person taking the course does not even have to leave his or her workplace, which pleases the employer. This situation too requires group communication between those teaching and those learning, since questions have to be asked and solutions discussed. Another conceivable scenario could involve course participants who use the Web to procure the learning materials they need, deliver their completed assignments, and then receive feedback from the instructor. This is also a case that requires group communication, as the

Chapter 1 — Introduction

3

Group i Communication

Figure 1.1 Worldwide group communication.

instructor has to distribute the papers to the virtual class and work assignments have to be collected from the course participants. In this sense the virtual class represents a group. Applications for open distance learning are playing a key role in the development of Internet2 [91], the new generation of the Internet. The aim of Internet2 is to meet the requirements of these applications for communication systems. A large number of research and development projects are currently being carried out in this area internationally. The IEEE has begun a project (IEEE P1484) [62] to standardize these applications. Another field of application involving group communication that is of interest in everyday life can be found in computer-supported information dissemination, or push technologies. An example of this is the distribution by software manufacturers of their products over the Internet [94]. Other examples include the transmission of current stock prices and weather data [15] and the updating of sales information for the dealers of a company (such as General Motors [144]). This technology can also be used to disseminate advertisements based on consumer habits or place of residence.

Virtual class

Push technologies

4

Chapter 1 — Introduction

Applications emulate group communication

Group services

What is common to all the examples mentioned is that more than one addressee is involved. However, the examples differ by the level of interaction involved. Furthermore, in some of the examples presented it is possible for the role of the participant to change—from addressee to sender and vice versa. The examples also differ in terms of the awareness of group members of each other. For example, all the members of a project team are aware of each other, but with push technologies this would rarely be the case. This also would not always apply with open distance learning. In addition to these applications, which are mainly still in the development stage, there are other applications today that are already using a form of group communication, even if no support is being provided by the underlying computer-supported communication system [5]. In these cases, group communication is emulated in the application itself. A familiar example is email, which allows electronic messages to be transmitted to whole groups of recipients who are normally specified through mailing lists. Another example is the distribution of news and chatting on the Internet (Internet Relay Chat, IRC). Not to be overlooked are game servers that allow users to play games like backgammon and chess together on the Internet. In these applications very simple mechanisms for group communication are implemented in the applications themselves but not supported by the communication system. Existing applications could also profit considerably in terms of efficiency from a communication system with group communication support. First steps in this direction can already be observed in the Internet. This book introduces the technologies that would be suitable for providing this support, some of which have already been partly introduced on the Internet. Computer-supported communication today is for the most part designed for data exchange between two computers, but this kind of point-to-point communication is no longer sufficient for a large number of applications. Communication within a group is inherent to many forward-looking applications, especially in distributed systems [45]. A change in the underlying communication paradigm from previous point-to-point communication to group communication is the prerequisite for providing effective and efficient support to these applications. Consequently, a major goal in the design of future communication systems should be to provide group services—services for group communication. Adaptations of existing components will not be sufficient. Nevertheless, for pragmatic reasons some communication protocols are being integrated into current network

Chapter 1 — Introduction environments—for example, in the Internet—in an effort to provide at least some initial support for group communication. Scalability in particular is at the center of interest with group communication. Communication systems are quickly exceeding their performance limits because of the underlying point-to-point communication prevalent today. An example is the screen saver SmartScreens [88, 123]. If this screen saver is activated on a computer connected to the Internet, current news items featuring politics, the economy, and sports are displayed on the screen. The data presented is updated periodically from a server and distributed to interested users. Yet the communication is based on point-to-point communication because of the lack of a suitable infrastructure for group communication. Therefore a separate communication relationship is established with each recipient, and the data is transmitted separately to the individual addressees. This places a heavy load on the network if a large number of recipients are involved. Measurements carried out in [69] show that Web traffic generated on the Internet as a result of this activity represents 18% of the overall traffic. This example highlights the need for suitable communication support that is capable of minimizing traffic. Certain attributes of communication groups are significant when it comes to scalability, including the size of a group (the number of group members) and the group topology (the geographical arrangement of group members). It undoubtedly makes a big difference whether the members of a group are concentrated in one specific geographical area or are widely dispersed. For example, the differences in the physical transfer delay of the data can be clearly noticeable. The logical group structure that determines the communication flow within a group also has to be considered. Group communication—or, more precisely, multicasting—has been at the center of interest in the area of Internet activities and has already contributed to some major successes. The goal of this book is to document current developments in this direction with an emphasis on the Internet. New protocols and services in the area of routing and for transport protocols and applications are also introduced. The book is structured as follows: Chapter 2 introduces the fundamentals of group communication and discusses the principal problems associated with the implementation of computer-supported group communication. The subsequent chapters are each devoted to one specific area and present alternative technical solutions. Chapters 3 and 4 deal with Internet protocols that are already in use now or that represent new developments. The topics covered focus on multicast routing as well as on quality-of-service support for multimedia

5

Scalability plays a key role

Multicasting on the Internet

Structure of this book

6

Chapter 1 — Introduction applications based on group communication. Chapter 5 begins by introducing the background of ATM networks and then looks at multicast support for ATM networks with particular emphasis on signaling at the user-network interface. Protocols for the support of multicast communication on the transport layer are the subject of Chapter 6. This chapter presents various protocols with different multicast services, some of which are currently being used on the Internet. The structure of the MBone, the multicast backbone of the Internet, is discussed in Chapter 7. Some applications that use the MBone are presented, such as systems for videoconferencing. Finally, Chapter 8 provides a perspective on the issues that still have not been addressed in multicast communication and also looks at active networks, currently discussed in conjunction with the Internet, as a technology that could possibly be beneficial to multicast communication.

2 The Basics of Group Communication

T

he aim of this chapter is to introduce the necessary basic concepts before embarking on a detailed discussion of the protocols and mechanisms for group communication. This is necessary because in some areas no uniform terminology is currently used. Examples are the terms “multicast,” “multipeer,” and “scalability.” This chapter then presents some examples of applications and their requirements for group communication. It also discusses key issues that need to be resolved within the context of group communication including reliability, flow control, and group management. Subsequent chapters will present technical solutions for overcoming these problems. This chapter therefore presents the framework for the rest of the book, focusing on current protocols and systems and discussing the current spectrum of available alternatives. Although we assume that you already possess a basic knowledge of computer communication, references are frequently provided to basic as well as to more advanced literature. In the following chapters there are three terms that are used in a general sense when an exact variant is not essential. The term group communication is used for any type of communication within a group. The term data unit refers to the data exchanged between communicating entities. Use of terms such as “packet,” “datagram,” and “message” has been avoided for purposes of uniformity. Network internal systems for forwarding data are generically referred to as intermediate systems if the type of system is not relevant for the problems and concepts being presented.

2.1 Types of Communication Within the context of group communication, various types of communication can be differentiated, depending on the number of senders

8

Chapter 2 — The Basics of Group Communication and receivers involved. Point-to-point communication between two people can be viewed as a special case of group communication. A distinction is made between the following basic types of communication: ■ ■ ■ ■

Unicast (1:1) Multicast (1:n) Concast (m:1) Multipeer/multipoint (m:n)

The notation in the brackets should be interpreted as follows: The first number refers to the number of senders, the second to the number of receivers. The special case of a single sender or receiver is denoted by a 1.

2.1.1 Unicast Communication Point-to-point

Not suitable for group communication

Unicast is equivalent to traditional point-to-point communication (1:1 communication) in which there is exactly one sender and one receiver. As a consequence, user data is exchanged on a unidirectional basis (see Figure 2.1). A bidirectional exchange of user data therefore requires the existence of two unicast communications. Note that although user data flows in only one direction in a unidirectional communication, the control data required for the technical control of a communication can be transmitted in the reverse direction. This means, for example, that the receiver can acknowledge to the sender that the data has been received correctly. The term “unicast” is frequently not used in a very precise way. In the literature the exchange of bidirectional user data between two communication partners is often also referred to as “unicast”. Unicast is restricted to the communication between two communication partners. If unicast is used to support group communication, then two unicast communication relationships would have to be established

Sender Figure 2.1 Unicast communication.

Receiver

2.1 Types of Communication between two group members. With a group size of n, this produces as much as n (n − 1) communication relationships in the case of multipeer, with all group members being allowed to operate a sender, and n ( n2 −1 ) communication relationships in the case of multicast. This is not a feasible option for large groups. In other words there is no scalability with respect to group size. The following types of communication present themselves as more favorable options. Classic correspondence by letter [88] is an example of an application based on unicast communication, involving a unidirectional communication with a sender and a recipient. A new communication relationship is established in the reverse direction if a letter of response is sent. A confirmation of receipt sent to the sender, on the other hand, does not constitute a new communication but corresponds to the control data mentioned earlier. In this sense the use of the telephone is not considered a unicast communication because it takes place in a bidirectional way. In other words, a telephone call consists of two unicast communications in opposite directions.

2.1.2 Multicast Communication In a multicast communication a single data source transmits user data to one or more than one receiver. The case of a single receiver represents the special case of unicast. This therefore constitutes an extension of unicast communication and is referred to as a 1:n communication. Figure 2.2 shows an example in which Barney is sending data to members of the Flintstone project team, specifically to Wilma, Fred,

Wilma

Fred

Barney

Dino Figure 2.2 Multicast communication.

9

10

Chapter 2 — The Basics of Group Communication

Multicast = 1 sender and n receivers

and Dino. However, although these team members are able to receive data, they themselves are not able to send any. This is another case in which the communication is unidirectional. As with unicast, control data can also flow in the opposite direction to ensure that the communication process is smooth. This interpretation of the term “multicast,” in which one sender is involved, is the one that will be used throughout the rest of this book. In the literature the term is frequently applied to scenarios involving more than one sender. For the implementation of a bidirectional group communication within a group with n participants, n multicast communication relationships are required—one per member. A typical application of multicast communication is the transmission of a talk at a conference using computer-supported conference systems. The talk is transmitted to a group of recipients, in this case the conference participants, who may be based at a variety of different locations. Multicast can also be useful for shared teamwork—for example, if one person is making a presentation to the other team members. The push technologies mentioned in Chapter 1 represent another typical field of application for multicast communication and are also a good example of an application with unidirectional data flow. When push technologies are used, data is usually only forwarded from the sender to the recipient or to a group of recipients; no user data flows in the opposite direction, but sometimes control data is transmitted back to the sender.

2.1.3 Concast Communication In a concast communication several senders are able to send user data to a single receiver (see Figure 2.3). This involves an m:1 communication in which data is sent on a unidirectional basis from the senders to the receiver. In the literature the term “concentration” is sometimes also used to refer to concast communication, but this is not a wellestablished term. An example of a concast scenario is one in which simulation results are transmitted from several computers to one receiver, who then evaluates the results. The sending of these results does not have to be synchronized (i.e., the senders operate independently of one another). Other concast scenarios can be found in the area of network management. Taking the scenario presented in Figure 2.3 as an example, the network nodes Wilma, Fred, and Dino could send management data

2.1 Types of Communication

11

Wilma

Barney

Fred

Dino Figure 2.3 Concast communication.

to the network center Barney for evaluation. Concast communication is used in the field of open distance learning when students forward their homework assignments to their teachers or tutors.

2.1.4 Multipeer Communication Multipeer communication takes place when several senders are able to send user data to the same set of receivers (see Figure 2.4). This corresponds to an m:n type of communication and is frequently referred to as multipoint communication. Multipeer is the most diverse form of group communication because it places no restrictions on the number of senders and receivers that can communicate. Taking the Flintstone project team as an example, multipeer communication would be required if the team members located in different places wanted to discuss a particular subject. In this situation each team member must have the opportunity of expressing his or her opinion. Therefore each team member is potentially a sender. Each member is a receiver of all the data sent by the other members of the group. Multipeer communication is very difficult to implement but can be emulated through the simultaneous operation of several multicast communications. To this end, a multicast communication is

Most diverse form

Emulation through multicast

12

Chapter 2 — The Basics of Group Communication Wilma

Multipeer

Barney

Fred

Dino Figure 2.4 Multipeer communication.

established for each sender to all the other members of the group. This technical implementation is frequently selected as an option today. Because different multicasts that are independent of one another are transmitted at the same time, situations can arise in which receivers will receive the data of different senders in a different sequence. One of the reasons for this can be the different network delay. For example, Wilma could conceivably receive data first from Dino and then from Barney, whereas Dino first received the data from Barney and then from Fred. In certain contexts this can cause problems, for example, when a different arrangement of symbols results for users sharing a whiteboard (see Figure 2.5). On the same whiteboard Fred and Barney are independently drawing two different symbols, which are to be forwarded per multipeer to Wilma and Dino. When Dino receives the data the cube appears behind the star, but Wilma receives it with the star positioned behind the cube. Wilma is therefore unable to recognize the star. If situations of this kind are not acceptable for a particular application, then additional mechanisms must be provided inside the communication system to allow the implementation of proper multipeer

2.1 Types of Communication

13

Wilma

Barney

Fred

Dino Figure 2.5 Sequence of exchanges on a whiteboard.

communication. Maintaining a proper order is one of the key concepts that make group communication considerably more complex technically than point-to-point communication. In general, group communication should be seen as the objective in the development of new communication protocols. In this context, it should be clear that no single protocol for group communication will serve all requirements. It is envisioned today that different group communication protocols will be developed for different group services. Most systems today use unicast communication for their basic structure, and if they incorporate multicast or multipeer communication, they add them as extensions. This often leads to nonscalable solutions with respect to group size and the geographic distribution of group members. Figure 2.6 presents an overview of the types of communication introduced so far. Multipeer, as the most general type of communication, appears at the top. The restrictions of the other forms in terms of number of senders and receivers are noted next to the arrows. With these restrictions multicast, concast, and unicast are derived from multipeer communication.

2.1.5 Other Types of Communication The types of communication discussed above all fall under the umbrella of group communication, although unicast can be viewed as an

Ordering is important

Multipeer as the goal

14

Chapter 2 — The Basics of Group Communication

Multipeer Only 1 sender

Only 1 sender and only 1 receiver Only 1 receiver

Multicast

Concast

Unicast

Figure 2.6 Overview of different types of communication.

exception since it does not really involve more than two communication partners. Two other types of communication are also used today: ■ ■

Anycast

Anycast Broadcast

Anycast also makes use of the group concept. However, in this case the group is not used for the actual exchange of data; this takes place with available unicast mechanisms or with new anycast mechanisms. The receiver, however, is selected from a group of potential candidates. A typical application of anycast can be found in the localization of services in distributed systems. The example in Figure 2.7 incorporates a number of servers. A user places a query regarding a travel connection. This query is then forwarded per unicast or per dedicated anycast routing mechanisms to only one of the servers in this group and not to the entire group. The selected server responds with the appropriate information. It should be pointed out that the user actually directs the query to the group of servers. A selection mechanism in the network (e.g., end system, router, anycast server) then selects a single server and forwards the query per unicast to this server. The other servers in the group are not included in the querying process. The communication system selects the receiver from the group of possible receivers available. The user has no influence on this selection and normally will not even necessarily be familiar with the group of available receivers. What the user has to realize is that different

2.1 Types of Communication

15

Request to group Selection of a server

Request to selected server

Response

Group of servers Figure 2.7 Anycast communication.

servers can be selected from the group as target systems for successive anycast calls. Broadcast is another type of communication and is comparable to multicast since only a single sender exists. However, with broadcast there is no restriction with respect to the group of receivers; data is sent to all potential receivers. Anyone who is equipped with the required device is capable of receiving the data, with the only restriction being whether the device is activated (such as a radio being turned on). In this sense broadcast is a simplified version of multicast because it does not require the establishment, addressing, or administration of a group. Television and radio as operated traditionally (not Internet TV and Internet radio) are two everyday examples of broadcast communication. In data communication, broadcast tends to play a less important role, at least for wide-area networks. However, some mechanisms on the Internet are based on the assumption that broadcast is available in local-area networks. An example can be found in the Address Resolution Protocol (ARP) [43, 122]. Ethernet is an example of a widely used network that applies this kind of broadcast in a local area [142].

Broadcast

16

Chapter 2 — The Basics of Group Communication

2.2 Multicast vs. Unicast

Multicast = n * unicast?

Multicast (and multipeer) communication is the focus of this book. The question arises as to why multicast plays such an important role in computer-supported group communication. As has already been indicated, from a pragmatic standpoint it is easy for multicast communication to be implemented through unicast communication—at least at first glance. A multicast communication with n receivers can be emulated through n times the transmission of data through unicast communication; this means that n different unicast communication relationships are established. The following example illustrates this point in more detail. Figure 2.8 illustrates the emulation of a multicast communication using the example of a conversation within the Flintstone project team. Five members of the team are participating in the conversation. One of the members, Barney, is sending video images to the team. If unicast were the underlying type of communication, Barney would be establishing four different unicast communication relationships—one each to Pebbles, Wilma, Fred, and Dino. The video images would then be transmitted separately through each of these communication relationships. The letters used to identify the data units in Figure 2.8 serve to identify the respective receivers. The two intermediate systems I1 Pebbles

P

D

W

Wilma

F I1

I2 Fred

Barney

Dino Figure 2.8 Project meeting using unicast communication.

2.2 Multicast vs. Unicast and I2 are involved in the communication process as network internal systems. The video images are sent four times on the transmission link between Barney and the first intermediate system, I1, and three times on the subsequent link between I1 and I2 (to Wilma, Fred, and Dino). What is evident is that this constitutes a waste of network resources not only in terms of bandwidth but also as far as the processing performance of the sender and intermediate systems is concerned. The problem is that the data has to be received and transmitted more than once. Intermediate system I1 itself receives and transmits four data units each time. Furthermore, the sender is required to maintain several communication relationships simultaneously, thereby leading to an increase in the utilization of resources (for example, bandwidth, buffer, processing time). This kind of approach is not viable for very large groups consisting of several hundred or thousand members. But groups of this size are very probable—for example, when presentations from well-known international conferences are transmitted on the Internet. Other examples include distributed simulations and network-based games. If multicast communication is used as the underlying technology instead of unicast, then Barney would be sending the data to the network only once; that is, only one data unit then appears on the transmission link between Barney and the intermediate system I1. The same applies to the link between intermediate systems I1 and I2. The intermediate systems copy the data units to those output links where group members are located. The amount of traffic on the network is thereby greatly reduced compared to the previous example. The need for the involvement of end and intermediate systems is also minimized. Thus intermediate system I1 is only receiving one data unit and sending two. However, the intermediate system has to be able to copy the data because it is possible that data received at an input interface may have to be forwarded to multiple output interfaces. Moreover, if unicast is used instead of multicast, the data is transmitted with varying time delays to the individual group members because it has to be sent by Barney n times in succession. Let us assume that the size of one of the data units being sent is 2 kbytes and that the underlying network transmits at a data rate of 100 Mbit/s. The sender requires around 16 μs to transmit a data unit. With a given propagation speed of 200,000 km/s it is possible for 3.2 km to be covered in the network during this time. This means that the data could arrive at the first receiver even before it has been sent off to the last receiver. This problem is accentuated when very large groups are involved.

17

Resource waste

Not suitable for large groups

. . . and what is it like with multicast?

Time-delayed transmission

18

Chapter 2 — The Basics of Group Communication

Multicast is a considerable improvement

This kind of time difference can create problems, particularly for interactive group applications (e.g., distributed collaborative teamwork) because of the need for synchronous cooperation; this means that all data should be available to the different group members more or less at the same time. Synchronization problems may occur because of the delays resulting from sending the same data unit to different receivers. It may be necessary for additional delays to be incorporated into the receiver so that a consistent view of data can be provided. An example of an application where this is important can be found in distributed editors in the area of distributed software engineering and development. The different delays can particularly be seen as a disadvantage whenever any interaction is involved. For example, in a worst-case scenario, certain members of a group will not yet have received data that other group members are already discussing. In summary, the examples presented point out that multicast communication constitutes a considerable improvement over unicast. The systems involved have to cope with lower data volumes and require less processing capacity. This advantage is particularly noticeable with large groups. The addressing issue is another fact that is easier in the case of multicast (i.e., group addresses) than in the case of multicast being emulated by unicast communication (i.e., lists of receiver addresses). Furthermore, with multicast, a sender does not need to know all the receivers. This is an issue particularly in the case of applications like Internet radio. In consequence, a unicast emulation of multicast communication can be seen as an acceptable option for small groups only.

2.3 Scalability As highlighted in the discussion on group communication, scalability for large groups is one of the main problems in the technical implementation. Due to the importance of this topic, we will be dealing separately with aspects concerning scalability, including the following: ■ ■ ■ ■

Group size Reliability Group awareness Group topology

2.3 Scalability In this context large groups are those that consist of several hundred or thousand members. This size is not realistic for the distributed project team referred to above but easily applies to a number of other applications. For example, according to [57], networks with up to 100,000 communicating entities are being developed in the area of distributed simulation. Distributed games are another application that can involve very large numbers of users. One of the problems can be seen in the highly dynamic nature of such a group. This places a heavy burden on group management that must be able to keep up with these changes. In some cases group management puts a high burden on a group because of the additional data exchange created within the group, particularly depending on whether it is carried out on a centralized or distributed basis. The aspect of reliability is a very important one that is being given a new definition in the context of group communication. In the case of conventional unicast communication, reliability stands for the proper distribution of all transmitted data units to a single receiver, with no duplication and in the correct sequence. This reliability is ensured through the exchange of control data between the communication partners, signaling, for example, that data units have been received correctly. With group sizes numbering in the hundreds or thousands, the control data can produce an immense amount of additional traffic that can use up a considerable proportion of resources. In this context, “resources” are mainly network bandwidth processing capacity in the communication systems. The sender that receives the control data, in particular, faces having to deal with an extra load. Mechanisms are necessary to avoid this problem. Another factor that comes into play if a group service is to be reliable is that group members must be known. This is not necessarily assured in all situations. Information about the group members must be provided to the sender or to other nodes in the network that provide support for reliability. The aspect of awareness becomes even more complex if group membership is highly dynamic, because any changes must be recorded more or less immediately. In addition to group size, the aspect of group topology in the form of geographical distribution as well as the heterogeneity of the group members must be taken into account for scalability. Heterogeneity relates here to the different technical possibilities that apply to members. For example, they may be connected over high-speed networks or over slow, error-prone wireless connections. Concepts based on a hierarchy of group communication servers [88] have been proposed as a solution to the problem of scalability.

19 Group size

Reliability

Awareness of other group members

Group topology Heterogeneity

20

Chapter 2 — The Basics of Group Communication Other notions for group communication servers used in the literature are, for example, designated receivers and group controllers. For their respective hierarchy level, these systems have the task of increasing reliability by implementing error detection and control and providing flow and congestion control. Consolidated control information is then forwarded to the next higher level of the hierarchy. With some approaches (e.g., [87]), retransmission can take place at a lower hierarchy level with only a certain part of the group and the network being affected. If this initially seems an obvious approach, you have to look at the other side of the coin to see that it also presents a number of new problems. An example is the location of the hierarchy levels and mapping the corresponding components in the communication system. Some pragmatic approaches addressing these issues have already been implemented and evaluated on the Internet. The group topology also has to be considered in this context because of its influence on the placement of the group communication servers. It often makes sense to locate the server close to the subgroup with respect to network distance.

2.4 Applications of Group Communication Many forward-looking applications are based on group communication and therefore can benefit considerably from appropriate communication support. These applications are derived from a large variety of different areas, such as the technical environment (e.g., distributed databases and scientific computing) and personal information and communication (e.g., push technologies and computer-supported teamwork). Some examples, including their requirements for group communication, are introduced below.

2.4.1 Distributed Databases With distributed databases, data can be distributed among a group of database servers. The example in Figure 2.9 shows the Rock-Tours distributed database, which comprises various servers for the fictitious airlines Air Rubble, Dino-Air, and Air Flintstone. Each of these servers contains the database for the respective airline. The search for specific information is made easier if only a single query can be directed to the entire group of Rock-Tours servers—for example, if you are looking for an inexpensive flight to Rock Valley. A

2.4 Applications of Group Communication

21

Database server Air Rubble

Database server Dino-Air Request

Response Barney

Rock-Tours

Database server Air Flintstone

Figure 2.9 Group communication with distributed databases.

user directs the appropriate query to Rock-Tours without the need for each of the involved servers to be addressed separately through subsequent queries. The query is forwarded automatically to the servers belonging to the particular group without any need for intervention by the user. If applicable, the servers respond with an offering of flights. The cheapest flight can be chosen from the selection presented. Without the support of group communication the user would have to send several requests for information one after the other in order to obtain the list of all available flights. To do so, the user would also have to know which servers are involved. This particular example involves several levels of group communication. What is important to the user is that he or she only has to enter one single request for information. The technical implementation is actually not an issue for the user. The only aspect that is important is

Different levels

22

Chapter 2 — The Basics of Group Communication the quality of service experienced at the user interface (e.g., response time). Technically it is possible for the group communication to be emulated by the database system so that, transparently to the user, the database system subsequently queries several servers. Likewise the required support can also be provided in the communication system so that the database sends a single query per multicast. This last aspect, namely, the support of group communication by the communication system itself, is the focus of this book. Aspects such as efficiency and reliability are basic requirements of group communication. As far as reliability is concerned, we have to analyze whether the database query was forwarded to all servers of Rock-Tours. If this was not the case, it is possible that the user was not even informed of the cheapest offer available. This kind of situation can be avoided if the servers are known to the communication system and appropriate mechanisms for error detection and control are implemented. With respect to group dynamics, it can be expected that the group of servers is stable and, therefore, not many changes to group membership are necessary. Consequently, the management of the information concerning group membership is not very demanding.

2.4.2 Push Technologies Push technologies support individually tailored, computer-supported information dissemination across computer networks, for example, the distribution of advertisements to a specific group with certain consumer characteristics. In this case, push technologies can be regarded as an electronic “mail circular” where a dedicated group of users is supplied with advertisements. Other examples of push technology are the distribution of software updates or Web caching. In some applications with push technologies, the target group can be quite large, and the use of a communication infrastructure with support for group communication is desirable. It is also assumed that the target group could change quite frequently, which means that efficient group management is necessary. Although reliability is desirable, it is not that critical for some of the applications of push technology. The distribution of advertisements is an example of an application with relaxed requirements for reliability. On the other hand, the distribution of software updates is an example with high requirements for reliability.

2.4 Applications of Group Communication

23

2.4.3 Interactive Multimedia Applications With interactive multimedia applications it is not only the technical protocols but also the social protocols—those that control interpersonal communication—that play an important role. The interpersonal communication behavior should be transferred to the computersupported platform. In this way, in principle, a communication pattern with which people are familiar—namely, group conversation or discussion—is mapped to networked computers. Computer-supported communication systems are no longer only designed to implement data exchange between computers but also to support interaction between human users located in different places. The requirements for the quality and performance of this kind of computer-supported interactive group communication are very high and must be oriented toward the normal everyday habits of the user. The distributed group work of a project team whose members are located in different places is an example of an interactive multimedia application (see Figure 2.10). In these situations, conferencing systems enable communication and collaboration between team members. A conferencing system in this case is a system that allows the exchange of data, audio, and video beyond computer boundaries. Sometimes these systems are also referred to as “teleconferencing” or “videoconferencing” systems. With conferencing systems, a conversion between the social protocols mentioned above and the technical protocols is required within the communication system. It is not possible to provide an in-depth analysis of social protocols and the technical conversion of these protocols within the context of this book. Instead we refer you to selected literature that deals with computer-supported group work in detail, for example [2, 26, 37, 133, 137]. Figure 2.11 illustrates a typical screen dump of today’s conferencing systems. The video windows of the users are arranged in the upper left-hand part of the screen. The corresponding control windows are placed in the lower part of the screen. The window on the lower righthand side is used to control the video. The window on the lower left is responsible for audio control. Conferencing systems usually also incorporate a whiteboard for data and document exchange purposes. The whiteboard represents a common work area for the development of graphics and text. Some tools support the use of PostScript files, for example, through the use of PostScript interpreters. In Figure 2.11 the whiteboard is located on the right-hand side and takes up most of the screen space. A document has been loaded that is to be discussed by the team members involved. During the discussion the

Interpersonal communication

Social vs. technical protocols

Whiteboard

24

Chapter 2 — The Basics of Group Communication

Wilma Pebbles

Fred

Barney

Dino Figure 2.10 Distributed Flintstone project team.

Group membership

text is annotated with individual comments. The different participants can be identified, for example, by the colors selected for the text and symbols. This approach can only really be used, however, with small disciplined groups. One problem is the difficulty in differentiating amongst so many different colors. Another problem is that destructive participants could constantly change the colors they use if they are not explicitly assigned a color by the system. The latter facility does not exist in most systems because of the lack of mechanisms for conference control [33]. In addition to the basic tools discussed for conferencing systems, some systems include features such as complex distributed editors, notepads, and voting tools. Along with being able to share the use of these tools, users find it desirable to have information on the members who are currently participating in a meeting or distributed teamwork. It is entirely possible for the group membership to change dramatically. Therefore, efficient applications for group management are required. This is particularly

2.4 Applications of Group Communication

25

Video of session participants

Audio control Video control

Whiteboard

Figure 2.11 Components of a conferencing system.

important because interactive multimedia applications, compared to the distributed databases discussed earlier, can be subject to a considerably higher fluctuation in group membership. For example, large fluctuations in group membership can be observed in the use of conferencing tools for the MBone on the Internet, which are frequently used for transmitting talks over the Internet. Typically, individual participants briefly join a group in order to get an impression of the lecture being presented. They leave the group after a short period of time and try the same thing with a different conference. This behavior is similar to people channel surfing while watching TV. Security is also an important factor in connection with conferencing systems. For example, a mechanism should exist to prevent nongroup members from undetected participation in a distributed project meeting where confidential information is being discussed. Thus, authentication and encryption, for example, are needed.

26

Chapter 2 — The Basics of Group Communication These basic examples already clearly demonstrate that a number of requirements exist for group communication. In addition to efficiency, aspects dealing with group management as well as the rights of individual group members are particularly important. Before explaining the technical details relating to these aspects, the following sections will clarify the concept of communication groups as well as their associated characteristics.

2.5 Characteristics of Groups Typical characteristics of a communication group include the following [36]: ■ ■ ■ ■ ■ ■

Openness

Openness Dynamics Lifetime Security Awareness Heterogeneity

In terms of openness, a distinction is made between open and closed groups (see Figure 2.12). Data from any sender can be forwarded to open groups. In other words, it is not necessary for the sender to be a member of a particular group. Of course, the receivers always have to be members of the corresponding group. With closed groups, data can only be exchanged between the members of a No additional sender

Additional senders

Members

Members

(a)

(b)

Figure 2.12 Open (a) vs. closed (b) groups.

2.5 Characteristics of Groups particular group. This means that the sender as well as the receivers of the data must be members of the group. No senders aside from members of the group can be involved. The next characteristic to be considered is the dynamics of a group, with a differentiation made between dynamic and static groups. With static groups, membership of the group is predetermined and does not change during an established communication. With dynamic groups, membership can change during a communication. A typical example is the dynamics observed at a conference when another person is called upon to provide an expert opinion on a particular topic or when one of the participants leaves the conference. An example of a static group could be the short meeting of a project team for the purpose of quickly clarifying certain aspects of a project. If, however, a need arises during the meeting for further in-depth clarification on a particular topic, then the group is transformed into a dynamic one to allow experts to be brought into the discussion, or, alternatively, a new static group could be created. Open groups as well as closed groups can be dynamic; that is, the composition of each of these groups can change over time. As far as lifetime is concerned, a distinction is made between permanent groups and transient groups. The latter exist only as long as a group has members. A permanent group, on the other hand, will continue to exist even if it currently has no active members. A group of all routers in a subnetwork is a typical example of a permanent group. A videoconference is an example of a transient group. In terms of security, clarification of the requirements for each instance of group communication is needed. These security requirements can be static for the entire duration of a communication, or they can change dynamically during an established communication. Furthermore, they can vary for the different data streams involved (e.g., audio, video, whiteboard). It is also possible for the meetings of a project team to move through different phases. During certain phases when confidential information is being discussed, there can be no acceptance of anyone listening in on the discussion without detection by the project team. The issue of the extent to which the mechanisms currently being used for point-to-point communication are also suitable for group communication is likewise raised in the area of security. It turns out that these provisions are not adequate and therefore new mechanisms are required—for example, for the distribution of private keys [57].

27

Dynamics

Lifetime

Security

28

Chapter 2 — The Basics of Group Communication Awareness

Heterogeneity

The awareness of a group relates to the awareness of the identity of the other members in a group. In an anonymous group, group members may not be aware of each other at all times during a communication. For example, when a presentation is multicasted on the network, some listeners may not identify themselves and, thus, are not known to the rest of the group. In the example of the project team discussed earlier, the identity of all members will usually be available to everyone in the group. Thus, this is referred to as a known group and not an anonymous one. Note that in an anonymous group all group members could also be known, but this is not ensured. Group awareness has a major influence on the group services that can be provided. For example, reliability cannot be provided to anonymous groups. It is also possible to differentiate between homogeneous and heterogeneous groups, with the latter undoubtedly showing the greatest potential for the future. In heterogeneous groups, members of a group have different capabilities, for example, in respect to their network connection (e.g., in terms of data rates) or to the alternatives available for video coding (e.g., H.261, MPEG) [102, 129, 145]. Communication costs can also be a reason for heterogeneity in a group, particularly if one member requests a lower transmission quality in order to save costs related to a communication. A communication system must be able to provide mechanisms to deal with this heterogeneity. In homogeneous groups, all participants at a conference have access to the same resources. It would be relatively easy to establish a homogeneous group communication for the earlier example of the project team. However, if, for example, one of the group members is on a business trip while a meeting is taking place, he or she may only be able to participate in the meeting over a wireless connection at a lower data rate. The group then needs to be reclassified as a heterogeneous group because this one member of the group is not able to take advantage of the full quality of the conference. It should be possible for members to be provided individually with a lower quality of service without this having any effect on the quality of service delivered to the other group members. If this kind of service is available, the heterogeneity is transparent for the group members. If this is not the case, the quality of service is usually reduced to the lowest level of quality supported in the overall group, which can be very disappointing to many of the other group members. If heterogeneity is introduced into a group because of systems that are attached through a wireless connection, this not only affects the quality of service but also the reliability. The wireless link can be the reason for temporary interruptions to service during which no data

2.6 Special Aspects of Group Communication

29

can be transmitted or received at all. These circumstances need to be considered if reliable group services are to be provided.

2.6 Special Aspects of Group Communication Because it takes more than two participants to exchange data in a group communication, some of the services and mechanisms familiar from traditional point-to-point communication have to be expanded in their definition or new ones added. These include ■

■ ■

Reliability Ordering Heterogeneity Flow and congestion control Group addressing and management

Sometimes it is far more complex to implement these services and mechanisms for group communication than for unicast communication. It is very difficult for traditional definitions such as reliability (correct receipt of all data in the correct order and without duplication) to be realized in group communication, because groups can become extremely large and geographically widely distributed and heterogeneity can exist within a group. The resulting special aspects of group communication will be discussed below without reference to any particular protocols. Later chapters will focus on current technical implementations and the protocols that have been developed to face these challenges.

2.6.1 Reliability According to the traditional definition, a reliable service is one in which all data is delivered to the receiver in the correct order without any errors and without any duplication. If it is not possible to provide a reliable service—for instance, because of a link failure—the user is usually informed accordingly and the communication is terminated. The mechanisms that have been used to provide reliable services are based on the assumption that not more than one receiver and one sender exist. This interpretation of a reliable service cannot be transferred directly to group communication; it cannot be scaled. As a result, new categories of reliability for group services are introduced

Reliable and unreliable services

30

Chapter 2 — The Basics of Group Communication below. The aspects of ordering and heterogeneity play particularly important roles in this context. Typically it is the transport layer that provides a reliable service for point-to-point communication. TCP (Transmission Control Protocol) [125], an Internet protocol (e.g., [43, 146]) is an example of a transport protocol with a reliable service. In contrast, UDP (Universal Datagram Protocol) [126], which is also used on the Internet, does not offer a reliable service. With an unreliable service there are no provisions to guarantee that the data will be delivered to the receiver. We simply hope that everything will work out well. Despite its shortcomings, UDP is often used in group communication since an extension of TCP for reliable group communication does not currently exist—and is unlikely anytime soon. As with point-to-point communication, applications involving group communication have different requirements for the reliability of group services. The following three basic classes of reliability can be distinguished: ■ ■ ■

Unreliable Semireliable Reliable

“Degrees of reliability” are discussed in [165] in relationship to group communication. However, this term is not widely used today and consequently will not be used in the discussions that follow.

Unreliable Group Services

Audio and video?

Analogous to unreliable point-to-point communication, no guarantee is given for the delivery of data with unreliable group services. It is therefore entirely possible that not a single member of a group will really have received all the data. Mechanisms for error control and recovery can therefore be eliminated. The provision of unreliable group services can be derived directly from point-to-point communication with respect to reliability. The transport of continuous data, such as audio and video, is often given as an example of an application that uses this type of service. With this service a certain proportion of data can be lost (i.e., not received by the user) before any considerable reduction in quality is recognized, because of the redundancy of audio and video streams. However, experiences with the use of such technology have shown that in certain cases loss of audio data can quickly result in a noticeable

2.6 Special Aspects of Group Communication

31

reduction in quality. It is not always possible to retransmit audio data that has been lost in the network or is poorly received because the data must be available at the time of playback. Since considerable fluctuations in delay can occur in large networks when data is retransmitted, it would be necessary for the data to be buffered by the receiver for the appropriate time interval; otherwise no continuous playback of the data would be possible. However, intermediate buffering also increases end-to-end delays significantly, thereby also causing a major increase to interaction times in interactive applications. This can result in a lower acceptance of these services by users. Long delays of this kind are experienced, for example, when satellites instead of cable-based connections are used for telephone calls. Forward error correction (FEC) is an alternative to retransmission in error-prone situations. The trade-off can be seen in the higher data rate and the higher processing requirements, which are not always acceptable.

Semireliable Group Services Semireliable group services can be categorized between unreliable and reliable group services. An example of a semireliable service is the localization of resources in a distributed system. In this case, the user requesting a service is often not interested in knowing which or how many of the systems providing the resources needed will receive and process the request. The service user is merely interested in receiving a response. It is sufficient to have the assurance that at least one receiver will receive the data correctly. Semireliable services pursue this course. Within semireliable group services, different types of semireliable services can be further distinguished: ■ ■ ■

Intermediate stage

Statistically reliable k-reliable Sufficiently reliable

The key difference between statistically reliable and k-reliable lies in the decision criteria indicating at which threshold the assumption can be made that a sufficient number of users have received the data correctly. In the case of statistical reliability, the threshold value is defined as the percentage of group members that has to receive the data. As a result, the sender has to be aware of the size of the group or at least has to have a good estimate of the group size in order to determine when

Statistical reliability

32

Chapter 2 — The Basics of Group Communication

k-reliable group services

the given percentage has been achieved. Statistical reliability, thus, uses a relative measure to derive the threshold value. In order to evaluate the percentage, the sender must be aware of any changes in the size of dynamic groups. The decision whether a sufficient number of acknowledgments has been received is usually made on the basis of a single data unit and not per data stream. Since different receivers can acknowledge the receipt of separate data units or even blocks of data units, it is not possible to derive a definitive statement about the reliability achieved for the overall data stream with respect to individual users. In order to realize this, new mechanisms are needed compared to unicast communication. k-reliable group services are based on the provision of a fixed number k for the threshold and, thus, use an absolute measure. This means that out of n group members, at least k members receive the data correctly. As with statistical reliability, the number of group members should be known in order to guarantee that k is less than or equal to the current group size n. Otherwise, no k-reliable service can be provided. With dynamic groups, where the number of group members can vary during an ongoing communication, each change should be checked to ensure that the above condition (k < n) is still being met. In the case of k = 1, the service is somewhat comparable to an anycast service with the distinction that a 1-reliable service might deliver multiple responses to the user. Furthermore, anycast is unreliable, whereas a 1-reliable service delivers at least one response. A possible realization of a k-reliable group service is as follows: After sending data the sender waits for a certain time interval T for acknowledgments. If the sender does not receive at least k acknowledgments from k different receivers during this period, it is assumed that an error has occurred. The sender then has the option of either terminating the connection and informing the users accordingly, or of retransmitting the data, in which case an upper limit has to be defined for the number of retransmissions. Once this limit has been reached, the connection is terminated and the user informed accordingly. Sufficiently reliable group services are mainly used with receiveroriented protocols that are based on dynamic and unknown groups. Implementations of sufficiently reliable group services do not further consider the group size. Because of unknown groups, the sender cannot know whether all receivers have received all data. Thus, a fully reliable service cannot be provided (e.g., for transaction-based applications). Two basic implementation alternatives are available with respect to buffer management. In the first alternative, they simply buffer the data for a certain time interval at the sender. After timeout

2.6 Special Aspects of Group Communication

33

of a corresponding timer, the data is discarded and no longer available for retransmissions. Thus, receivers that did not receive the data until this point in time cannot be served by a retransmission of the corresponding data. The timeout value is set to a sufficiently large time interval (i.e., the receivers are normally given enough time to recover from data corruption or data losses). The other alternative relies on complete buffering of all data exchanged within a session. However, the sender still has no information as to whether all receivers have received the data completely and, thus, a fully reliable service cannot be provided.

Reliable Group Services With reliable group services all receivers receive all data correctly, in the right order and without any duplication. “Correct order” here means that all receivers receive the sender’s data in the same sequence. A global ordering that ensures that all data of all senders is delivered to all receivers in the same and globally correct sequence represents an important aspect of group communication. It is particularly important when multipeer communication is to be implemented with a reliable group service. This kind of reliable service is necessary, for example, for distributed databases. Queries and update requests must be forwarded to all involved database servers in order to ensure that the consistency of the databases is maintained. There must be a guarantee that these requests are delivered reliably to all receivers. Furthermore, within the scope of distributed databases, it is important that no one receives any data in the case of an error. This is referred to as atomicity, which means that the data is supplied either to all or to none of the receivers. Reliable group services are also partly needed in the area of conferencing applications. As an example, consider the whiteboard that represents a shared workspace for all group members. All changes to the document by individual group members must be delivered to all participants. In some cases a global order is important, for example, in the case of distributed computer-aided software engineering (CASE) editors. Error detection and recovery mechanisms are required in the implementation of reliable group services. These mechanisms must be extended to group communication. Mechanisms used within unicast communication cannot easily be extended. If, for example, reliability were designed so that all members of a group receive all data correctly,

Atomicity

34

Chapter 2 — The Basics of Group Communication in the right order, and with no duplication, then a single error-prone receiver (or transmission link) could prevent communication for the other group members. Furthermore, traditional procedures are not necessarily scalable for large, geographically dispersed groups. In a simple scenario, each receiver would be sending acknowledgments to the sender, which, in the case of a large group, could easily result in performance bottlenecks. This problem is referred to as acknowledgment implosion. Figure 2.13 shows an example of acknowledgments flooding a sender as a result of the transmission of a single data unit. The load on the sender caused by acknowledgments increases proportionally to the number of group members. In addition, the sender would keep retransmitting the data to the entire group until the last member of the group received it. As with semireliable group services, the sender must wait a certain time interval T and collect the acknowledgments. If the sender does not receive acknowledgments from all the group members, he is again faced with the alternative of either terminating the connection or retransmitting the data. It is also possible for the group to be reduced in number through the removal of any member who is not ready to receive data. The protocols introduced in Chapter 6 incorporate

Sender Acknowledgments

Group of receivers Figure 2.13 Acknowledgment implosion.

2.6 Special Aspects of Group Communication

35

different mechanisms for the support of reliability. These protocols are usually specialized for a particular field of application, reflecting an important development. With the advent of group communication, it is no longer possible to support a one-size-fits-all solution for all group services. Instead, dedicated protocols are being developed for different types of group services. With reliable group services, all members of the group have to be known so that it can be determined whether all group members have acknowledged receipt of the data and consequently have received it correctly. Dynamic changes to group membership must be made known directly to the sender. New group members must immediately be made aware of the current group status. If reliable group services are being provided, it is important that the participants registered with a group are available at all times, since a connection can be terminated if one of the group members does not respond. Group members who participate through wireless links become a critical issue in this case because temporary physical interruptions are typical of mobile communication.

Ordered Delivery Various types of ordered delivery can be distinguished for group communication. The previous section introduced global ordering, which ensures that all data of all senders is delivered to all receivers in the same and globally correct sequence. Global ordering is particularly important when multipeer communication is to be implemented with a reliable group service. However, it is inherently difficult to provide global ordering. It would require globally synchronized clocks among the involved systems. Therefore, many practical implementations provide one of the following alternatives to global ordering: ■ ■

Source ordering Total ordering

With source ordering, data units from a source are delivered to the receiver’s application in the same order as they were issued by that source. There is no ordering rule specified between data units being transmitted from different sources. Totally ordered delivery specifies that multiple multicast streams from multiple senders are delivered sequentially to each receiver and are received in the same relative order at each receiver. Thus, total

Source ordering

Total ordering

36

Chapter 2 — The Basics of Group Communication ordering is weaker than global ordering, since total ordering does not require keeping the correct order among multiple senders. It just guarantees that every receiver receives the data in the same order.

2.6.2 Flow and Congestion Control Protocol mechanisms governing flow and congestion control are required to regulate data flow between two communication partners. The mechanisms used today are designed for communication between two participants. It has proven difficult to expand these mechanisms to include group communication, particularly for large, physically dispersed, or heterogeneous groups.

Flow Control

Known group members

Unknown group members

Window-based or rate-based mechanisms that are often based on positive acknowledgments (ACKs) from the receivers are used for flow control [121]. TCP is an example of this combination. Acknowledgments with group communication are processed differently than the mechanisms for point-to-point communication. Basically, the acknowledgments must be collected from a set of receivers and not only from one single receiver. The group members can either be known or not known to the sender. If the group members are known, then the acknowledgments can be assigned to the respective receiver. A separate determination can be made whether each receiver has received the data in its entirety or not. Data can be retransmitted on a dedicated basis to those receivers who have not yet received the data correctly. If the group members are not known, then the acknowledgments can only be allocated to the group itself but not to individual receivers. The possibility of offering a reliable group service is therefore eliminated. The problem in this situation is that no guarantee can be given that any of the receivers has received the data in its entirety. Consequently, no regulation of the flow control window is possible. Flow control is usually directly coupled with error detection and recovery. In the case of large groups, this can place a heavy load on the sender since it can receive, and thus has to process, acknowledgments from all receivers. As a result, some advanced approaches attempt to redirect the load from the sender to the receiver. The mechanisms resulting from this approach are called receiver-based mechanisms in contrast to the original sender-based ones. Receiver-based

2.6 Special Aspects of Group Communication

37

mechanisms lead to the use of negative acknowledgments (NAKs) as opposed to the traditionally used positive acknowledgments. NAKs provide dedicated information about data that has not yet been received correctly. A systematic comparison of the effectiveness of these two approaches can be found in [152]. The studies carried out there indicate that receiver-oriented mechanisms result in a higher throughput than sender-oriented ones. On the other hand, NAKs also produce some disadvantages. For example, it is not possible to determine whether the last data unit transmitted by the sender has been lost in the network (see Figure 2.14). Furthermore, with group communication the reaction of the sender upon receipt of acknowledgments must be reconsidered. In principle, the sender’s reaction to an acknowledgment can be

Negative acknowledgments

■ ■

immediate or delayed.

If the receivers of a group are not known, then a retransmission to the entire group needs to take place. The advantage of an immediate reaction with retransmission is the minimization of the time for error recovery. The disadvantage is that the sender reacts to each acknowledgment separately. This can lead to situations in which the same data unit is retransmitted multiple times because it is being requested by different—not known—group members. Sequence numbers can be used to avoid the problem of multiple reactions to a single data unit to be retransmitted. If the group is a known group, a delayed reaction can also take into account the number of receivers to whom the data Sender Data unit 1 Data unit 2 Data unit 3 Data unit 4 Data unit 5 Data unit 6 Data unit 3 Data unit 7

Receiver

NAK

Data loss not detected Figure 2.14 Critical situation with NAK.

Reaction of the sender

38

Chapter 2 — The Basics of Group Communication

Transmit buffer

Window-based flow control

should be retransmitted. A distinction can therefore be made between a selective retransmission to individual receivers or a retransmission to the entire group. In individual cases, however, a delayed reaction will lead to a delay in error recovery. Error recovery in point-to-point communication is based on the round-trip time of a connection. Receivers within a group will evaluate the connection based on their individual link to the sender. If there is a delay in error recovery, the receiver may end up forwarding the same acknowledgment to the sender multiple times, which may result in the sender issuing multiple retransmissions that may not be necessary. Retransmission is not the only action the sender can undertake with respect to error recovery. Depending on the information contained in the acknowledgments, data should also be deleted from the transmit buffer. With unicast communication, data that has been acknowledged positively is immediately removed from the transmit buffer since it is no longer required for retransmission. This can also apply in the case of group communication if positive acknowledgments are received from all receivers in a known group. This means that the relevant data has been received correctly by everyone and therefore does not need to be retransmitted, hence further buffering of the data is not required. If, on the other hand, the sender does not know the group members, the decision about the removal of the data units in the transmit buffer is linked to a time interval. In this case an implementation of reliable group communication is not possible because a receiver might request data to be retransmitted after that time interval has expired and the relevant data has been automatically removed at the sender. Thus, a trade-off has to be reconciled between the potential reliability of group communication and the buffer requirements in the sender. Increasing the time before data is deleted will increase the buffer requirements of the sender. At the same time, however, there is a higher probability that data that has not been correctly received will be retransmitted by the sender and, subsequently, received by as many receivers as possible. The detailed settings should be selected in conjunction with the application requirements and with the infrastructure characteristics. For this purpose, k-reliable protocols can be used. Window-based procedures for flow control are not directly suitable for group communication. If the membership of a group is not known to the sender, it is not possible to determine whether all members of the group have received the data correctly. Updating the window

2.6 Special Aspects of Group Communication requires a timer-based mechanism that determines the new upper window boundary after the expiration of a specific time interval, which can either cause an overflow in the receive buffers of certain receivers or lead to an unnecessary reduction in throughput. If the group members are known, the fact of whether an acknowledgment has already been received from each receiver can be used as the criteria for an update of the window. The size of the flow control window presents an additional problem. This size traditionally reflects the buffer capacity of a single receiver. For a group communication it would have to be set to the minimum buffer capacity available to receivers within the group. Furthermore, the size needs to be adjusted dynamically as members join or leave the group. Rate-based flow control appears to be a favorable option for group communication because it reduces the problem of processing large numbers of control data units that occurs with window-based mechanisms. Rate-based flow control regulates how much data a sender is allowed to transmit during a specific time interval. This requires the definition of two parameters: burst size and burst rate. The burst size determines the volume of data that can be sent during the time T. The burst rate is determined by the minimal interval t between two consecutive bursts. The burst rate increases as the interval t decreases. An example is illustrated in Figure 2.15. The two burst parameters must orient themselves to the weakest receiver within the group and adapt accordingly when new members join the group or other members leave the group. An alternative handling would be to define a lower bound and automatically remove group members that cannot handle this lower bound.

Time interval T

Burst

Minimal distance t

Time interval T

Data unit

Time Figure 2.15 Bursts for rate-based flow control.

39

Rate-based flow control

40

Chapter 2 — The Basics of Group Communication

Congestion Control In congestion control a differentiation is made between ■ ■

Preventive mechanisms

Reactive mechanisms

preventive mechanisms and reactive mechanisms.

Preventive mechanisms come into play when data is entered into the communication system. They regulate the allowable data rate and consequently the data load produced by a source. These mechanisms require the availability of detailed information on the service quality to be provided for the data stream. Fluctuations in data rates can cause problems, especially if they cannot be estimated accurately in advance. It is extremely difficult to project the required data rate for video streams because it depends on the respective coding procedures used as well as on the content of the video. Dependent on the video codec, data rates cannot be determined in advance for live video. Some video codecs, however, fix the data rate and vary the frame quality or the frame rate instead. Reactive mechanisms for congestion control are able to react to the actual situation in a network. However, this can lead to the problem of feedback implosion if group communication is to be implemented. If receivers are sending feedback information about current network load, this can lead to a situation comparable to an acknowledgment implosion (see Figure 2.13). The number of feedback messages rises in conjunction with the number of receivers, which creates a considerable bottleneck for the sender. In addition, the transmission of feedback messages produces even more traffic where congestion already exists. Another problem with reactive congestion control for group communication is that network load in different network areas can vary considerably. A simple reduction of the data rate of the sender to the least worst within a group surely does not present a viable alternative.

2.6.3 Group Addressing and Administration A new addressing scheme is needed for group communication since a dedicated group of receivers is now being addressed instead of only an individual receiver (unicast communication) or all receivers (broadcast communication). The following two alternatives are available:

2.6 Special Aspects of Group Communication ■ ■

Addressing through lists of receivers Addressing through a special group address

When receiver lists are used, the sender has access to a list of the unicast addresses of all the receivers in a group. The sender (which in this case can be a mail server) can therefore identify all the members in the group and send them the respective data. This is how mailing lists for email are handled, for example. The receiver list must always reflect the current members of the group. The list must be updated whenever a new member joins the group or an existing member leaves it. The data units are then distributed per unicast communication to the individual receivers, which leads to the problems described in Section 2.2. If a special group address is used, the group is identified by a single dedicated address. The sender transmits the data to this group address. An individual identification of the receivers within a group is therefore not required. The advantage of the use of group addresses is that the sender does not have to send the data to more than one receiver. The sender transmits the data unit exactly once, that is, to the group address (not considering retransmissions). The receivers must be able to decide that data with specific group addresses is relevant to them and consequently they must receive this data. The group addresses enable the intermediate systems in the network to decide how the data is to be forwarded. If need be, these systems must be able to copy the data unit and forward it to several output links. The allocation of a group address can be either ■ ■

41

centralized or distributed.

A centralized address allocation is carried out by an authorized institution. An address has to be requested from this authority before a group can be established. This address retains its validity even beyond the duration of an active communication within the group. It is only invalidated after an explicit request has been made to the authority to cancel the address. An alternative mechanism could use a predetermined point in time after which the group address is no longer valid. This type of address allocation is comparable to the allocation of telephone numbers. Centralized address allocation has its advantages if long-term allocations of group addresses are requested. However, it is not advantageous for short-lived groups.

Lists of receivers

Group addresses

Address allocation

42

Chapter 2 — The Basics of Group Communication

Group management

Announcement

With distributed address allocation, a group address is selected locally when a group is established. There must be an assurance that the dynamically allocated address is unique, in other words, not already being used by another group. A dedicated control data unit can be used on the Internet to probe whether the group address is currently being used. Since control data units can be lost in the network and since another address holder is not required to reply, there is no absolute guarantee of the uniqueness of the address selected this way. As an alternative, servers can be established for the provisioning of multicast addresses in the network. Multicast addresses can be requested from a server when needed. In contrast to a centralized allocation, the group address is released again when the communication is terminated. It then can be used by another group. Compared to a centralized allocation scheme, distributed address allocation is advantageous for the short-term use of multicast addresses. Group management is responsible for all tasks related to the management of the members of a group. These tasks can be further divided up between those that are essential before a group communication can take place and those that occur during a group communication. Furthermore, it must be determined whether group management is to be implemented on a centralized or a distributed basis. Local group management is advantageous in terms of scalability. However, disadvantages exist because of the need to provide consistent status information for the entire group, which is generally more complicated to provide in distributed systems than in centralized systems. The distributed group managers have to exchange information for this purpose. An appropriate announcement must be made before a computersupported group communication can take place. For example, the Flintstone project team will clarify certain details in advance, such as the time of their meeting and which members have been invited to participate. The tools to be used (e.g., audio and video) also have to be made known at the time of the announcement. An example of this is shown with the session directory (SDR) and MBone tools in Figure 2.16. In addition to the name of the conference, the announcement also includes a brief description. The type of session and the scope of the conference (limited to site in the example) are also parameters that can be set. Other information that is provided includes the existing data streams and the protocols or formats to be used. In the example an audio stream, a video stream, and a whiteboard are announced. The audio in the example is PCM-coded (Pulse Code Modulation) [145] and is transmitted with the RTP (Realtime Transfer Protocol)

Figure 2.16 Announcement of a group communication.

44

Chapter 2 — The Basics of Group Communication [136]. The corresponding IP address and the UDP port can also be derived from the announcement. No communication can take place without knowledge of these details. Video is also transmitted via RTP with the H.261 [129] coding standard. The whiteboard is set up over UDP and uses its own nonstandardized data format. The announcement must also indicate when the conference will be active, thus, for example, when the project meeting will take place. Once this kind of meeting is active, there has to be agreement on whether the group is static or dynamic, that is, whether members are allowed to join and leave the group. It is therefore necessary for the group administration to be familiar with the characteristics of the respective group.

2.7 Support within the Communication System Dedicated support of group communication can be located in different parts of a communication system. Communication systems are usually defined on the basis of hierarchical layers, in accordance with either the ISO/OSI basic reference model or the Internet model (see Figure 2.17). Support in layers 2 to 4 of the ISO/OSI reference model or the corresponding layers of the Internet model is required for data transfer. These layers have responsibility for regulating data transfer and Application layer (7) Presentation layer (6) Session layer (5) Transport layer (4)

Application

Network layer (3)

TCP/UDP

Link layer (2)

IP

Physical layer (1)

Network access

(a)

(b)

Figure 2.17 ISO/OSI basic reference model (a) and Internet model (b).

2.7 Support within the Communication System

45

providing a corresponding communication service to the applications. The layers involved are as follows: ■ ■ ■

Data link layer Network layer Transport layer

The applications used may also have to be adapted or expanded, for example, for the distribution of keys in the case of secure group communication. A brief discussion of some of the problems that have to be resolved in these layers follows. Various concepts for solutions are presented in detail in the following chapters.

2.7.1 Data Link Layer The data link layer in the ISO/OSI model includes the MAC (Media Access Control) sublayer that is responsible for the control of media access. In the Internet model this sublayer is part of the network access component. There is a significant difference between some of the mechanisms used for media access. Above all, a differentiation is needed between networks with distributed access to a shared medium, such as Ethernet, Token Ring, and Fiber Distributed Data Interface (FDDI) [105, 142], and networks without a shared medium, such as Integrated Services Digital Network (ISDN) [143] and Asynchronous Transfer Mode (ATM) [3, 72, 155]. If a shared medium is used in networks, each data unit sent reaches all computers connected to the medium. No special mechanisms are required. The attached computers decide whether the data unit should be received or not on the basis of the destination address included in the data unit. Three different types of addresses can be distinguished: ■ ■ ■

Unicast addresses Multicast addresses Broadcast addresses

Unicast addresses identify a special end system and can be compared with the address on a letter that normally also identifies a specific recipient. Multicast addresses address a dedicated group of receivers— for example, all the managers of a certain company. Broadcast

Shared medium

46

Chapter 2 — The Basics of Group Communication

1

U/L

Group address

1

1

46

[bit]

U/L: Universal/Local Figure 2.18 Multicast addresses in accordance with IEEE 802.

Ethernet with a shared medium

No shared medium with ISDN or ATM

addresses are used when data is to be delivered to all possible receivers and no specific selection is indicated. Thus, a communication system only has to have a single broadcast address; there is no need for a distinction between different ones. The format for the addresses used in the MAC layer is defined in the IEEE 802 standard (see Figure 2.18) [142]. The leading bit being set to one identifies the address as a multicast address. With unicast addresses, this field is set to zero. The second bit is used to distinguish between universal and local addresses. The address itself is found in the remaining 46 bits. In the case of unicast addresses, this field is subdivided further to include a field with a vendor’s identification and a field that is freely available for the vendor’s use. Figure 2.19 uses an Ethernet example to illustrate the difference between unicast and multicast. With unicast, the sender is required to send a data unit for N receivers N times across the network. One of the N receivers is addressed explicitly each time. Barney therefore has to send the data unit four times—one time each to Wilma (W), Pebbles (P), Dino (D), and Fred (F). With multicast, the data unit only has to be sent once in the Ethernet, indicated with the appropriate group address (PT: Project Team Flintstone). The group members then all have the possibility of receiving the data units over a shared medium. All that is necessary is that a receiver be informed that he or she is a member of the corresponding group. This example shows that the use of group addresses leads to a considerable saving in bandwidth and processing consumption. Thus, networks with a shared medium are suitable for group communication use. However, shared media are usually only found in local-area networks. Switched networks such as ISDN and ATM do not have shared media. Instead they are based on point-to-point communication, which is familiar from the telephone network. Before a data unit is delivered to the addressed receivers, it therefore has to be copied and sent separately to each receiver. However, an attempt can be made to establish a maximum common path in the network without multiple use of

2.7 Support within the Communication System Barney

Pebbles

Wilma

(a) P

D

W

Dino

F

Fred

Barney

Wilma

Pebbles

(b) PT

PT: Group address PT: of project team PT: Flintstone

Dino

Fred

Figure 2.19 Ethernet example: unicast (a) vs. multicast (b).

resources (such as bandwidth). In these networks, multicast support can usually only save bandwidth on certain links of the complete communication path. Figure 2.20 presents a situation showing ATM network behavior when multicast is emulated by unicast. The sender (Barney) must send a dedicated data unit to each member of the project team. On transmission links used by more than one receiver this results in the same data unit being sent more than once. The use of multicast communication enables a reduction in the amount of resources needed on common subpaths (e.g., the transmission link between Barney and the first switch as well as the link between the two switches).

2.7.2 Network Layer The network layer is a central component in communication systems. The main tasks of the network layer are to provide unique

47

48

Chapter 2 — The Basics of Group Communication Pebbles

Wilma

W

P

P

W

F

D

W

F

D

F

Switch

Switch

Fred

Barney D

Dino Figure 2.20 Multicast using ATM as an example.

8 Class A

0

Class B

1 0

Class C

1

1

0

Class D

1

1

1

16

Net ID

IP system Net ID

IP system Net ID

0

32

24

IP system

Multicast address

Figure 2.21 IP address formats.

networkwide addressing and to route data efficiently toward its destinations in the global network. Different types exist for Internet addresses (address classes A, B, and C) based on the size of the network (see Figure 2.21). What varies is the length of the two address components that are allocated to a network or to an IP system. IP addresses of class D are multicast

2.7 Support within the Communication System addresses and contain no further internal structuring. Address class E is being reserved for future applications and currently has no significance. The key concepts that have been introduced for IP multicast are multicast-Internet addresses, communication groups and their administration, and multicast routing. Multicast addresses are required so that data is not transmitted multiple times over the Internet. These are class D addresses. Communication groups on the Internet are open and dynamic groups. Group membership can change during an active or a passive communication. Groups are identified by a multicast-IP address. It is possible for transient as well as permanent groups to be supported. Examples of permanent groups are listed in Table 2.1. Internet addresses are currently 32 bits long. In the new version of IP, IPv6, addresses with a length of 128 bits will be used [32, 34, 44, 52, 58]. However, this version is not yet in use, and it is still not clear whether or when it will become operative as a new version on the Internet. We therefore will not cover IPv6 here. As is the case with unicast addresses, multicast addresses from the network layer have to be mapped to multicast addresses of the data link layer. For example, IP multicast addresses have to be mapped to Ethernet-MAC addresses and vice versa. The problem that arises is that the address space for Ethernet multicast addresses is smaller than the one for IP multicast addresses (see Figure 2.22). In a multicast-IP address, 28 bits are available to identify a group, whereas with Ethernet addresses, there are only 23 bits. The remaining 25 bits of an Ethernet-multicast address are allocated with a fixed value. The Table 2.1 Examples of permanent groups. Class D address

Permanent group

224.0.0.0

Reserved

224.0.0.1

All systems in a subnet

224.0.0.2

All routers in a subnet

224.0.0.3

Not allocated

224.0.0.4

All DVMRP routers in a subnet

224.0.0.9

Routers with RIP (Routing Information Protocol) Version2 in a subnet

224.0.1.1

NTP (Network Time Protocol)

224.0.1.9

MTP (Multicast Transport Protocol)

49

Address mapping

50

Chapter 2 — The Basics of Group Communication

Multicast-IP address

1110 5 bits

23 bits

Multicast-Ethernet address 0000 0001

0000 0000

0101 1110 0

25 common bits of all multicast-Ethernet addresses

0: Individual 1: Group

0: Internet multicast 1: Other applications

Figure 2.22 Mapping between multicast-Ethernet addresses and multicast-IP addresses.

first byte is set at 0000 0001, with the 1 identifying the address as a group address rather than a unicast address. In comparison with Figure 2.18, it should be noted that the bit for identifying the group address is transmitted as a low-order bit of the high-order byte of the MAC address. The use of the following two bytes is specified by the IEEE, as shown in Figure 2.22. A one-to-one mapping between an IP-multicast address and an Ethernet-multicast address is therefore not possible. The solution followed today does not take into account the leading five bits of the group identification of an IP-multicast address. These are, so to speak, simply cut off. The result of this pragmatic process can be seen in the fact that end systems are able to receive multicast data units that are not intended for them. This occurs if their IP-multicast addresses only differ within the five bits that are eliminated during the address mapping process. As a result, no closed groups can be formed at the data link layer. Systems not belonging to a certain group may receive the group data. However, the data are not forwarded to higher layers by IP, since it operates on the IP-multicast address. In addition to group addresses, routing support for groups is required at the network layer. The information required must be provided in routing tables to the network layer. In principle, routing should enable an optimization of resources, which means that as few resources as possible should be used in the network. A further concern is that no loops occur so that an endless circling of data in the network can be avoided. Furthermore, traffic concentration points should be

2.7 Support within the Communication System avoided. The algorithms used to determine the paths through the network must satisfy these requirements, for group communication as well as for unicast communication. Traditional routing algorithms are based on finding an optimal path from the sender of data to the receiver. This involves the use of routing algorithms that basically concentrate on point-to-point communication. However, routing algorithms for multicast and multipoint routing are required for the efficient support of group communication. As with point-to-point communication, the optimization goal is to make minimum use of the resources available in the network. This goal can be achieved if data follows a common path through the network as long as possible. Data copying is thereby avoided and, subsequently, the multiple use of resources as well. New routing algorithms for multipoint communication on the Internet are introduced in Chapter 3. The fact that membership may change if members join and leave a group makes the design of appropriate routing algorithms more complex. In point-to-point routing the communication is simply terminated as soon as a communication partner leaves the group. As a rule, this is not the case with group communication. In this context, support for group members using a wireless link is also important since route changes can occur frequently due to the potential mobility of these receivers. Support for optimal routes in these situations already poses a challenge in the case of point-to-point communication, and it is even more demanding with group communication.

2.7.3 Transport Layer The task of the transport layer is to support data exchange between the communication partners. Typically reliable and unreliable transport services can be distinguished. Current transport protocols, such as TCP on the Internet, are based on pure point-to-point communication. For error control purposes, the receiver sends an acknowledgment to the sender to signal that data has been received correctly. Simply extending this mechanism to a group could mean that with large groups the sender would have to process a very large number of acknowledgments—namely, from all the members of the group. This is likely to create an acknowledgment implosion (see Figure 2.13). It is obvious that this kind of approach is not scalable for large groups since the sender can easily become a bottleneck.

51

52

Chapter 2 — The Basics of Group Communication

Physical distribution

Transport protocols are often responsible for providing reliable services between users. Once again it is important to point out the special problems of group communication that sometimes necessitate the introduction of new reliability classes. The result is that in the future a single transport protocol will no longer be able to accommodate the diverse requirements placed on group services. What is expected is that a pool of multicast transport protocols, each with a specifically dedicated group service, will exist. Other aspects that will play an important role are the degree to which group members are known and the dynamics of a group. Multicast protocols must address these aspects. The protocols of the transport layer introduced in Chapter 6 offer a variety of different alternatives. In addition to the number of group members, the physical distribution of a group is another important factor for the scalability of protocols. For example, if a member of the project team is in the United States and the other ones are located in a city in Germany, then the group member at the remote location can impact the efficiency of communication within the group. Acknowledgments from remote locations require more time to travel through the network. The same applies to any retransmission that may be necessary.

2.7.4 Application Layer With new applications, particularly with applications on the Internet, multicast support is partially provided by the applications themselves. As a result, established transport protocols can continue to be utilized. UDP is used mostly for that purpose. The multicast support required is then implemented in the application itself. The whiteboard [96] is a familiar example of this. It provides a reliable multicast on the basis of UDP, an unreliable protocol of the transport layer. This is certainly a positive development overall, because it enables prototypes to be generated quickly over the existing communication infrastructure. In the long term, it would make sense to improve communication support by offering a flexible framework for multicast support that can be used by a variety of applications, which would greatly simplify the design of distributed applications.

3 Multicast Routing

T

he main tasks of multicast support in the network layer can be found in the following aspects:

■

Route exchange Group dynamics Multicast address allocation

■ ■

Data is not forwarded to individual receivers in a network but to a group of receivers. This requires multicast trees to be set up within the network. New routing algorithms and, consequently, new routing protocols are needed. This chapter will briefly present some basics about routing algorithms using examples from point-to-point communication. Then group dynamics and tree construction on the Internet is introduced, since they serve as the basis for many of the approaches to multicast routing discussed. A discussion of scoping and multicast address allocation follows that introduces the basic problems and concepts. The main part of the chapter focuses on basic concepts related to multicast routing and presents examples of current multicast routing protocols.

3.1 Basic Routing Algorithms Two basic categories of routing algorithms can be distinguished (see Figure 3.1): ■ ■

Static routing algorithms Adaptive routing algorithms

In the case of static routing algorithms, the routing table is initialized during system start-up. The routing table provides information

Static algorithms

54

Chapter 3 — Multicast Routing

Routing algorithms

Static algorithms

Adaptive algorithms

Centralized algorithms

Distributed algorithms

Distance-vector algorithms

Link state algorithms

Figure 3.1 Classification of routing algorithms.

Not relevant in practice

on how data is to be forwarded in a router. With static algorithms, this table does not change during operations. Routing metrics are important for setting up routing tables. Routing metrics can vary greatly and usually differ depending on the routing algorithm used. Examples of routing metrics include the number of transmission links to a destination, data rate, and load on a link. With static routing, only static parameters, such as the number of links, can have an effect on the calculation of the routing table. Static routing algorithms are not particularly suitable for practical use in data networks. The main reason is their inability to adapt automatically to changes in the network. They cannot take any dynamic changes into consideration (e.g., overloaded links or intermediate systems). The same problem applies to changes in group membership. Changes in group membership in addition to changes in the network can result in new paths being established for the routing of data or existing paths being updated. An update of the corresponding entry in the routing table is required before the new path can be provided. The usefulness of static routing algorithms is, therefore, limited to static groups that are known at setup time when used in an environment with static network conditions. In practice, however, dynamic

3.1 Basic Routing Algorithms groups often play a key role—for example, in the case of distributed computer-supported teamwork or in videoconferencing. Adaptive routing algorithms are able to adapt their routing information dynamically to current network characteristics or to group membership. Therefore, they are better suited for practical use than static routing algorithms. Routing metrics are used in order to determine dynamic adaptation. The values in the routing metric can change during the lifetime of the system. For example, the number of links needed to reach a destination system can vary. Furthermore, parameters can be used that provide information about the load of a particular transmission link, such as the length of the corresponding queue. These parameters can also evaluate the delay of data units within an intermediate system. In practice, however, most routing protocols use fairly simple metrics, such as the number of links, to evaluate the distance to a destination system. The routing tables are updated based on the routing metrics and consequently adapted dynamically to reflect current network load and group membership. Adaptive routing algorithms are clearly needed for group communication if support of dynamic groups is required, which is the case with most applications (e.g., with teamwork). Adaptive routing algorithms can be subdivided further into either ■ ■

55

Adaptive algorithms

Suitable for dynamic groups

centralized algorithms or distributed algorithms.

In the case of centralized algorithms, routing decisions are made by a central entity in the network and then distributed to the participating routers. The advantage of centralized algorithms is that the centralized entity has complete knowledge about the entire network. Based on this information, it can make a good routing decision. However, it has to be considered that the information available could be outdated since it is the individual routers that supply it. In a large network, particularly, this information may not necessarily reflect the current state of the entire network. Centralized algorithms can also be a problem for other reasons. The centralized entity represents a single point of failure. In case of a breakdown of the centralized entity or its link, the routing information of the entire network cannot be adapted any more, which can lead to a situation in which some communications cannot be maintained any longer. Fault-tolerant redundant systems should be used to avoid such situations.

Centralized algorithms

Single point of failure

56

Chapter 3 — Multicast Routing Performance bottleneck

Distributed algorithms

Furthermore, the centralized entity can easily become a bottleneck, especially in large networks. All routers in the network have to report the current status of local network connectivity to the centralized entity. The centralized entity then distributes the newly calculated routing information to all routers. The amount of processing in the centralized entity as well as the communication overhead involved nearby are factors that need to be considered carefully. Normally, distributed algorithms are used for routing decisions in today’s networks. With distributed algorithms, each router independently makes a routing decision based on the information available to it. Distributed adaptive routing algorithms are highly relevant in routing within large networks. The following two categories of distributed routing algorithms can be distinguished: ■ ■

Distance-vector algorithms Link state algorithms

The basics of distance-vector and link state algorithms are introduced below. The corresponding explanations relate to unicast communication. Some of the approaches for multicast routing are based on these algorithms and extend them accordingly.

3.1.1 Distance-Vector Algorithms Metric Ⳏ distance

Routing with distance-vector algorithms is based on the Bellman-Ford algorithm [23]. The routing metric used to evaluate different routes is based on the distance between systems, for example, measured in terms of hop counts. The objective of distance-vector algorithms is to determine the shortest distance to a communication partner. Distance-vector algorithms make the assumption that each network node is aware of the distance between the node itself and all other nodes in the network. The overall distance is calculated from the sum of the links to be passed. It is identical to the number of links if each link is weighted with one. An inherent problem of such a simple approach is that link capacity is not taken into account. For example, if the shorter distance uses 64 kbit/s links only and the longer distance, on the other hand, uses links with a data rate of 10 Mbit/s and higher, then the longer distance would usually be prefered because of its higher data rate. As Figure 3.2 illustrates, however, a distance-vector algorithm would always select the shortest path, even if it includes the obviously slower link. In the example shown, the shorter path across

3.1 Basic Routing Algorithms

57

Sender

10 Mbit/s 10 Mbit/s R3

100 Mbit/s

Distance: 3 R1

R4 100 Mbit/s

64 kbit/s R5

Distance: 5

100 Mbit/s

R2 R6 64 kbit/s

100 Mbit/s

Receiver Figure 3.2 Routing selection with distance-vector algorithms.

routers R1 and R2 is given preference over the longer path with the higher data rate across routers R3, R4, R5, and R6. Therefore, each link can be additionally assigned a weight that is included into the calculation of the distance. This weight can reflect the data rate. Responsibility for the calculation of the shortest path is therefore distributed over systems in the network. There is no centralized entity that determines the optimal path through the network. To obtain information about distances in the network, neighboring routers exchange distance vectors with one another. These vectors provide information on which distances all other routers in the network can be reached. The exchange of distance vectors takes place periodically between immediately neighboring systems. The routing tables of distance-vector algorithms contain an entry for each possible destination system in a network or in a domain.

Distance vectors

58

Chapter 3 — Multicast Routing Table 3.1 Example of a routing table.

Structure of a routing table

Slow convergence

Division into domains

Destination

Distance

Next system

Interface

A

3

Router 2

3

B

7

Router 5

3

M

13

Router 2

3

X

3

Router 3

1

Z

4

Router 1

2

Table 3.1 gives an example with five end systems. For each of the end systems A, B, M, X, and Z, the routing table contains the remaining distance to the destination, the next system to be passed, and the interface of the router through which the data unit is to be forwarded. The routing table will initially use the value infinity for all nonneighboring systems. This indicates that the distance to a particular system is not known and that it therefore cannot be reached. When a router receives a distance vector, it adds the remaining distance of the link to the values received with the distance vector. This newly calculated value is compared to the current entry in the routing table. If the new value is better (i.e., lower), it is then used to replace the old value and a new entry in the routing table is constructed. Consequently, the router has determined a shorter path between sender and receiver than previously known. The advantage of distance-vector algorithms can be seen in their simplicity. Routers do not require a global view of an entire network. Instead they obtain their information on the basis of distance vectors exchanged periodically with their neighbors. What is a problem, however, is the fact that changes in network topology are distributed very slowly. A change has to be propagated n times in the network through an exchange of distance vectors, with n representing the number of links on the longest path through the network. The suitability of distance-vector algorithms for large networks is therefore limited. Their convergence times directly depend on the diameter (i.e., the longest path) within the network. Figure 3.3 provides an example. The distance vector must be forwarded and recalculated three times in order to allow router R4 to establish or update its distance vector to router R1. The division of networks into smaller, nonoverlapping domains is an essential step in the management of large networks. Distancevector algorithms can then be used within these domains. This division

3.1 Basic Routing Algorithms Distance vector: DR1 = 0 R1

Distance vector: DR1 = 3

59

Distance vector: DR1 = 5

R2

R3

R4

Distance neighbor R1: 3

Distance neighbor R2: 2

Distance neighbor R3: 1

Figure 3.3 Convergence of routing information with distance vectors.

Destination Distance 2 A ... ...

Next hop

R1

R2

Router 1 ...

Interface 1 ...

A

Destination Distance 3 A ... ...

Next hop Router 2 ...

Interface 1 ... Figure 3.4 Count-to-infinity problem.

into domains improves the convergence time within a domain and consequently the quality of the selected path. Additional routing protocols are used to provide connectivity between these domains. The convergence time can be improved further if changes are sent immediately, even if the corresponding timer determining the periodic exchange of distance vectors has not yet expired. This, however, requires the new distance vector to be recalculated before transmission. A problem inherent in distance-vector algorithms is the “count-toinfinity” problem illustrated in Figure 3.4 [171]. End system A is connected through router R1 to the rest of the network. Router R2 knows its shortest path to this end system with distance D = 2 and that it flows through router R1. Router R1 receives this information with

Count-to-infinity problem

60

RIP as an example on the Internet

Chapter 3 — Multicast Routing the distance vector. However, it is also aware of a shorter path to A, namely, with the distance D = 1. Consequently, it does not revise the routing entry. If the connection between end system A and router R1 fails, then R1 deletes the corresponding entry in its routing table since it has to find a new shortest path to A, if available. Router R2 continues to send its distance vectors periodically, thereby informing router R1 that it can reach end system A. R1 now assumes that it can reach A through router R2 and consequently increments the received distance for A and updates it in the routing table. Thus the new entry corresponds to D = 3 (see Figure 3.4). Then router R1 sends the new distance with its distance vector back to router R2. R2 then increases its distance again, since it assumes that it can reach A through R1, and follows the same procedure. This kind of loop can be avoided if the reverse forwarding of distance vectors is not allowed. This affects the direction R2 to R1 in the example. Further mechanisms are necessary [120] if such a loop spreads over multiple routers. The routing protocol RIP (Routing Information Protocol) [85, 90, 100, 120] used for unicast routing on the Internet is based on a distance-vector algorithm. The distance vectors are transmitted every 30 seconds. The maximum distance for a path through the network is limited to a value of 15. With RIP all links are usually weighted with one. This value also prevents any further restriction to the diameter. Nevertheless, on the Internet it still takes about 7 minutes before it is certain that all systems have received the routing information. This again highlights the convergence problems of distance-vector algorithms with respect to routing information. The multicast routing protocol DVMRP (see Section 3.5.1), which is based on RIP, specifies the diameter at a maximum of 32 links and consequently has an even slower convergence time.

3.1.2 Link State Algorithms

Dijkstra algorithm

Link state algorithms for routing are based on the assumption that each network node has a map of the network [90]. On the basis of this topology information, each node calculates the optimal path to every other system in the network. This calculation is carried out separately in each router. Since all routers receive the same routing information, all routing tables are consistent and loops can be avoided. The Dijkstra algorithm is frequently used in the calculation of routing information. With this algorithm, the network is regarded as a directed graph with the respective node as a root. The calculation of the shortest paths to

3.1 Basic Routing Algorithms all systems in the network is carried out with this model of a directed graph. The Dijkstra algorithm works as follows [120, 171]: First, all nodes (intermediate systems) are marked as temporary and identified with infinitely high costs. The nodes marked as temporary are not part of the directed graph. The first step involves marking the root node as permanent. The root node is the node in which the calculation is carried out. During each step, for each new permanent node the cost is calculated from the root node to the neighboring nodes of this permanent node. The algorithm then identifies the node with the lowest sodetermined costs and marks it as permanent. These steps are repeated until all nodes are marked as permanent. Marking nodes as permanent indicates that these nodes are part of the directed graphs. With link state routing, each system knows its neighbor, that is, those systems that can be reached directly by traversing other routers. Information about neighboring systems is provided by corresponding data units that are transmitted periodically to distribute topology information. This mechanism also determines whether the links to the neighboring nodes are active. Detection of topology changes in the direct neighborhood is possible. If changes to the network topology occur, it is necessary for all systems in the network to be informed accordingly, since new routing tables need to be calculated. Therefore, information about topology changes floods into the network. Time stamps or sequence numbers are added to the data units to enable the detection of old routing information, which ensures that old information will not be used in the calculation of a routing table and consequently create an inconsistent view of the network overall. The latter could result, for example, in the establishment of loops. For the purpose of routing decisions, the status of system network interfaces is also taken into account. For example, the current queue length or the link capacity could be part of the routing metric. These routing metrics enable routes to be adapted appropriately to the current load in a network. The routing metrics in link state algorithms are superior to those in distance-vector routing. Link state algorithms usually converge faster than distance-vector algorithms. With link state routing algorithms, the routing information can be forwarded immediately. This reduces the convergence delay in comparison to distance-vector algorithms, where the complete distance vector has to be recalculated. This increases their suitability for use in large networks. In addition, they support precise routing metrics and allow the use of multiple routing metrics. This means that different paths can be offered to a destination system, a feature that is particularly of interest if these

61

Routing metric

62

Chapter 3 — Multicast Routing

Shortest path first

paths share similar characteristics. Distance-vector algorithms typically choose a dedicated path, although multipath is also possible. The notion of “shortest path first” is well established for link state algorithms. It is derived from the Dijkstra algorithm, which calculates the shortest path between a network node and the other systems in the network.

3.2 Group Dynamics

IGMP

Suitable mechanisms to deal with group dynamics are required for the support of group communication. They should define how to join or leave groups and provide information about existing groups. The Internet Group Management Protocol (IGMP) was introduced for group management within subnetworks or edge networks. The current version is IGMP version 2 (IGMPv2) [64]. Similar to the Internet Control Message Protocol (ICMP) [124] required for error control, IGMP is an integral part of IP. It has to be implemented and provided with IP if IP multicast is to be supported. IGMP provides the following operations for joining and leaving groups on the Internet. It distinguishes between queries and reports: ■ ■ ■ ■ ■

General membership query Group-specific membership query Version 2 membership report Version 1 membership report Leave group

General membership queries are used to obtain information about groups that have members in an attached subnetwork. The operation group-specific membership queries checks whether a specific group has members in a subnetwork. Membership queries are sent periodically from the Querier router (see below) to the group of all end systems (all host groups). Membership reports inform multicast routers of new group memberships. End systems reply with a membership report to a membership query issued by a multicast router. The multicast router then records this information about group membership and sets the group membership timer to the group membership interval. This value corresponds to the time that must pass before a multicast router decides that a group does not have any members left in the subnetwork. The default value for this interval is set to 260 seconds [64]. Note that

3.2 Group Dynamics routers are only interested in whether a group has members or not. They need this information only for the binary decision to forward data belonging to that group into the subnetwork or not. The individual members themselves are not of interest. A membership report should further be sent by an end system immediately after a group has been joined. The version 1 membership report is included in order to provide backward compatibility with version 1 of IGMP. Version 1 membership reports do not carry a field for the maximum response time (see below). Leave group signals that a group membership has been finished. This operation was not available with IGMP version 1. However, it is essential in order to improve the efficiency of group membership termination. As indicated previously, the corresponding timeout value is set to 260 seconds by default. Improving leave efficiency is important for highly dynamic groups. The format of IGMP data units is shown in Figure 3.5. The key components are the group address and the checksum. The type field is used to identify a transmitted IGMP data unit. The following type values are defined: 0x11 for membership queries, 0x16 for version 2 membership reports, 0x12 for version 1 membership reports, and 0x17 for leave group. General and group-specific membership queries are further distinguished by the group address. The field for the maximum response time is only important with membership queries. It controls the time interval that can pass before the membership report is to be sent. After having received a membership query, a timer is associated with either the specific group or each group the end system participates in. The timer value is randomly selected in the interval (0, maximum response time], where maximum response time corresponds to the value received in the query. In [64] a default value of 10 seconds is recommended for the maximum response time. If the timer expires, the end system transmits a membership report. If it receives such a membership report from a different end system in the subnetwork, it 8 bits Type

8 bits Maximum response time

16 bits Checksum

Group address 32 bits Figure 3.5 IGMP data units.

63

64

Chapter 3 — Multicast Routing stops the timer and does not issue a membership report. This avoids duplicate reports on a subnetwork. The use of the maximum response time allows a regulation of the leave latency (i.e., the time between the last member leaving the group and the routing protocol being informed about this fact). It is an improvement of IGMPv2 compared to IGMPv1. Furthermore, the maximum response time can help to reduce the burstiness of IGMP traffic. IGMP data units are encapsulated into IP datagrams during transmission. In this sense, IGMP is logically located above the IP protocol. All IGMP data units are sent with a TTL (time to live) of one, which means they do not leave the local subnetwork. Membership in a group is therefore only available to local IGMP routers. Multicast routing protocols have responsibility for the further distribution of membership information in the network. With IGMP, a multicast router can have two states: ■ ■

Querier

Non-Querier

Querier Non-Querier

Normally, only a single multicast router in the network is in the Querier state. The Querier has the task of periodically querying for group members in the network. During initialization, all multicast routers assume that they are Queriers. Ultimately, the one with the lowest IP address is the one selected as the actual Querier. Therefore, if a multicast router receives a query from a router with a lower IP address, it changes from the state of Querier to the state of non-Querier. If a router is in the non-Querier state, it does not issue periodic queries (see Figure 3.6). However, a non-Querier receives IGMP reports sent on the subnetwork and analyzes them. If the Querier router fails, no further periodic queries are issued on the corresponding subnetwork. This situation is detected by the nonQueriers present on the subnetwork. If a non-Querier did not receive a membership query on the network for a certain time interval (derived from the Querier present time), it sends a general query and changes its state from non-Querier to Querier. A default value of 255 seconds is suggested for that timer [64]. If the Querier receives a response to its query, it keeps the group membership in its database and sets a timer with a calculated default value of 260 seconds. This timer has a great influence on the leave latency. Database entries can be updated by end systems through periodic transmissions of reports. In case of a time-out, the router assumes that no group exists locally and, consequently, deletes the

3.2 Group Dynamics

Router 1 - non-Querier -

65

Router 2 - Querier IGMP query

IGMP response

Figure 3.6 Dynamic querying with IGMP.

entry. It therefore does not forward any multicast data units for this group over the corresponding interface. When they leave a group, end systems can send leave data units to the multicast routers. Before deleting the entry, however, the router should send another query to the network to determine whether any other members are still active. If this is not the case, the entry is deleted and the forwarding of corresponding data units is stopped. Routers send general membership queries relatively infrequently. In RFC 2236 [64], it is recommended that the queries be repeated every 125 seconds. End systems can send reports even if they have not received a direct query, in order to accelerate their acceptance in a group or to signal their entry to a group in the network. The concept for group management used by IGMP cannot guarantee that all group members are known. An end system can receive data that has been sent to a group address without responding to general membership queries if, for example, another end system in the same subnetwork also belongs to this group. The other group members will not be aware that such an end system is receiving the data being sent to the group. Thus no known groups can be implemented with IGMP alone because, in principle, undetected eavesdropping by others is possible. Additional effort is needed at the application level to implement and ensure known groups. Nodes with IGMPv1 and IGMPv2 may operate concurrently within a subnetwork. The following rules need to be applied: IGMPv2 may

Unknown group members

66

Chapter 3 — Multicast Routing run on end systems within a subnetwork, although the Querier router has not yet been updated with IGMPv2 [64]. In this case, the end system with IGMPv2 needs to send version 1 membership reports since version 2 membership reports are not understood by the Querier router. Furthermore, the IGMPv1 router will send general queries with the maximum response time set to zero. This must be interpreted as a value of 10 seconds by the IGMPv2 end system. The end system therefore needs to keep track of whether it is interacting with an IGMPv1 or an IGMPv2 Querier router. If a router in the subnetwork still runs IGMPv1, then the Querier router is obliged to run IGMPv1. This needs to be configured manually. No automatic procedure is available until all end systems in a subnetwork are upgraded to IGMPv2, those end systems that are already upgraded must be able to suppress their membership reports by either a version 1 membership report or a version 2 membership report [64]. Additionally, it can happen that an IGMPv2 router is placed in a subnetwork where there are still end systems with IGMPv1. In this case, the router needs to ignore any group leaves. Following up IGMPv2, a new Internet draft has been published with IGMPv3 [54]. This new version introduces source filtering—the capability for a node to signal that it is interested in receiving data units only from specific source addresses or from all but specific addresses sent to a particular multicast address. Multicast routing protocols can use this information to avoid forwarding data into a subnetwork without interested receivers being available. IGMP version 3 is interoperable with IGMPv1 and IGMPv2. In order to take full advantage of IGMPv3, the IP application programming interface (API) must support the following operation: IPMulticastListen(socket, interface, multicast-address, filter-mode, source-list)

The filter-mode defines whether the addresses given in the sourcelist should be included (i.e., only) or excluded (i.e., all but) in the forwarding to the subnetwork. The source-list is an unordered list of IP unicast addresses. The current IP API must also be extended with respect to join and leave operations [54]. Due to the introduction of source lists, the data formats of reports and queries are extended accordingly. Version 3 membership reports are introduced. In [65] a mechanism is defined that enables the forwarding of multicast data based on IGMP membership information only without

3.3 Scoping and Multicast Address Allocation the use of multicast routing. In certain topologies a multicast routing protocol is not needed and can be avoided with this mechanism. It is assumed that the router has a single upstream interface toward the root of the tree and multiple downstream interfaces. If multicast data are received at the upstream interface, the router forwards them to the downstream interfaces that have a subscription to the corresponding group. If the router receives a membership query at the upstream interface, it reacts with a membership report.

3.3 Scoping and Multicast Address Allocation The dynamic handling of multicast addresses is another important issue when group communication is used on a large scale.

3.3.1 Scope of Multicast Groups The scope of an IP multicast data unit is not unlimited. The term scope refers to the region in which the data unit is forwarded. If the data unit reaches the edge of this region, it is not forwarded any further and is discarded. There are several reasons for using scoping: ■ ■ ■

Limitation of flooded network regions Multiple use of multicast addresses Privacy

If the routing protocol used temporarily floods the network, as is the case with DVMRP, a limitation of scope ensures that it will not unnecessarily overload the entire network. For example, it would be a waste of resources if a videoconference only involving participants from within the United States were also transmitted to other countries. Addresses are generally a scarce resource; the same applies to multicast addresses. Only the range between 224.0.0.0 and 239.255.255.255 is available for multicast addresses. However, a portion of these addresses is already reserved. An example is the group address of all multicast routers. Additional information about reserved addresses can be found in [131]. Because of scope limitation, multicast addresses can be used multiple times as long as the domains of the groups do not overlap. This allows a more efficient use of the address space.

67

68

Chapter 3 — Multicast Routing Lastly, scope limitation is also helpful in guaranteeing a certain degree of privacy. For example, stations outside the domain cannot join the multicast group. Currently two different mechanisms are used for scoping: ■ ■

Scoping based on the TTL value Administrative scoping

TTL Regions TTL scoping

Threshold values for TTL scoping

TTL scoping is currently the most frequently used algorithm. With TTL scoping, the TTL field in the header of the IP data unit is used to limit the scope. The TTL field gives the maximum lifetime of an IP data unit. The value of the field is decremented by each intermediate system that forwards a data unit. If the field reaches zero, the data unit is discarded (i.e., it is not forwarded further). This mechanism prevents a data unit from circling endlessly in the network because of an error in the routing table. The IP protocol also specifies that this field should be decremented if the data unit cannot be forwarded for a certain period of time. However, there are almost no implementations today that follow this recommendation. Instead, the TTL field is interpreted as a pure hop count. This basic TTL mechanism is not sufficient for limiting the scope of multicast data units. Which value should be selected, for example, to limit a multicast group to the United States? The number of intermediate systems to be passed is generally different for two receivers. Any TTL value we select may either be too low and miss some receivers within the United States, or too high and include some receivers outside the United States, or both. With IP-multicast, a comparison is also made between the TTL value and a threshold value in order to solve this problem. If the decremented TTL value is smaller than the threshold value, the data unit is discarded. It is even discarded if the TTL value is higher than zero. During the configuration of an MBone router, the threshold value is established for a tunnel. The threshold values used on the MBone are listed in Table 3.2. The administrators of the MBone have agreed to other threshold values in addition to those listed in this rough breakdown. In many European countries the threshold 48 is used to limit multicast traffic within the respective country.

3.3 Scoping and Multicast Address Allocation Table 3.2 Threshold values for TTL scoping. Threshold value

Scope

0

Restricted to the same host

1

Restricted to the same subnet

15

Restricted to the same site

31

Restricted to the same domain

63

Restricted to the same region

127

Worldwide

255

Unrestricted in scope

Overall, TTL scoping is a fairly easy mechanism to implement. However, it also has its disadvantages. On the one hand, the threshold values offer a rather inflexible option for limiting the scope of multicast groups. In most cases, a domain will have no more than 32 intermediate systems. However, even then it is not easy to make a finer delineation. On the other hand, the use of routing protocols that operate on the principles of flooding and pruning (such as DVMRP) can have an undesirable effect. If a router discards multicast data units because of a low TTL value, then no pruning messages are forwarded. Therefore, the multicast traffic of the group concerned is always forwarded to this particular router. This applies even if no more receivers exist for this group. This effect can be avoided if a router simply transmits pruning messages when data units are discarded. However, various authors are of the view that data units could end up being discarded by mistake. This would happen if some data units reach the router over a different path and the TTL value is then higher than the threshold value. In this case, these data units would be discarded, too. However, the source is free to send data units with higher TTL values. These data units should not be dropped because of TTL-stimulated pruning.

Administrative Regions The introduction of administrative regions [101] resulted in the definition of a second mechanism. This mechanism was introduced because of the disadvantages of TTL scoping described in the previous section. But administrative regions are not yet in wide use.

69

70

Chapter 3 — Multicast Routing Table 3.3 Administrative regions.

Local region

Organizational region

Address range

Scope

239.0.0.0 – 239.255.255.255

Administratively scoped multicast address space

239.255.0.0 – 239.255.255.255

Local scope

239.253.0.0 – 239.254.255.255

Expansion of the local scope

239.192.0.0 – 239.195.255.255

Organizational scope

239.0.0.0 – 239.191.255.255

Expansion of the organizational scope

224.0.0.0 – 224.0.0.255

Link-local scope

224.0.1.0 – 238.255.255.255

Global scope

With this mechanism, the scope of a multicast communication is determined on the basis of the multicast address. In other words, the multicast address is selected according to the scope requested. The administrative regions defined so far are listed in Table 3.3. As can be seen in the table, the administratively scoped multicast address space is restricted to the range from 239.0.0.0 to 239.255.255.255. This concept is being implemented at the network level. Mrouters at domain boundaries only forward or generate IP data units within the respective domain. Therefore, mrouters must be configured correctly because on their own they are unable to determine whether they are located at a domain boundary. This mechanism, therefore, does not use the TTL value for scoping. However, the value is still decremented, and data units are discarded if the TTL value equals zero. This use of the TTL value is specified in general for the IP protocol, even for the new version, IPv6. The local region can correspond to the scope within a company network. For example, an address is selected with local scope if a videoconference is to take place for company employees only. The routers of the local network must be configured so they do not forward any data units from the local network beyond the boundaries of that network. Thus, the configuration of the intermediate systems is restricted to the local area network. The configurations required can normally be handled easily by the network administrator. However, this no longer applies if data units are forwarded to a larger area. Then, multiple subnets and/or network operators are typically involved. As a result, the organizational region was introduced. In this case, an address or an address range is allocated to an organization. The organization is then responsible for the subdivision into

3.3 Scoping and Multicast Address Allocation areas and the configuration of the intermediate systems. The broadband research network B-WIN operated by the German organization German Research Network (Deutsches Forschungsnetz, DFN) is an example of an organizational region. It allows the multicast traffic of the group to be restricted to the users connected to the network. However, all intermediate systems in the network concerned must be configured appropriately. Automatic, dynamic configuration is desirable in this case. The expansions of the multicast address regions for locally and organizationally scoped regions (see Table 3.3) are meant to be used if the allocated ranges are not sufficient. But they are currently not reserved for that purpose, so it is not clear how these ranges will be used in the future. The global scope applies to multicast traffic with group addresses beyond this area. Traffic is basically forwarded without any scope limitation. In practice, however, TTL scoping continues to be active. One exception is the link-local scope, for which the range from 224.0.0.0 to 224.0.0.255 is defined. The advantage of this mechanism is that it limits the scope of multicast groups with finer granularity. As a result, application requirements can be met more favorably. A more precise subdivision of the scope within the areas is also possible. A countrywide network is given as an example. The city council sessions are broadcast on the MBone to each city in the country. Yet interest in these transmissions is certainly limited to the respective district. The same multicast address can be used for transmission in each district if corresponding administrative areas are established in the districts. Sessions of the state legislature could be transmitted countrywide at the same time on another multicast address. In this case, the mrouters would not forward the data units of the groups beyond the state boundaries. TTL scoping is not suitable for implementing such regions. Assume that the state capital is located close to the state boundary. In this case, the number of hops to the nearby state boundary will be much smaller than the number of mrouters that need to be passed to reach the other state boundary. It is not easy to establish a suitable threshold value for TTL scoping. Furthermore, such thresholds apply to the entire multicast traffic. Finally, it is then difficult to determine which threshold value restricts the limitation to a specific region. In summary, the algorithm using administrative regions not only enables a reduction in network load but also allows more effective use of multicast addresses. Moreover, this algorithm does not result in any side effects for the routing protocols.

71

Global region

72

Chapter 3 — Multicast Routing The disadvantage is that no information can be given about the administrative regions that were established unless exact knowledge is available about the regions that apply to a particular sender. This problem can partly be solved with Multicast-Scope Zone Announcement Protocol (MZAP) [78], which makes the administrative zones known. A second problem is that the zones may not overlap and a third is that they may have to use totally different address areas. This makes administration difficult. Moreover, a faulty configuration can cancel out the benefits of scope limitation. For example, an intermediate system at a domain boundary could easily be overlooked during configuration. MZAP could be effective in this instance. However, the protocol is not yet being used in practice. Therefore, network administrators have reacted to some of the serious disadvantages of administrative scopes. They are only used for scope limitation as a supplementary mechanism in individual cases. Otherwise TTL scoping continues to be applied.

3.3.2 Multicast Address Allocation

Address collisions

An important problem in multicast communication is the allocation of multicast addresses. Within the Internet, they are allocated dynamically either on demand or in advance. With the growing number of multicast addresses in use there is also an increase in the probability of address collisions. Therefore, a suitable allocation mechanism is needed in order to decrease or avoid address collisions. The approach outlined in this section decreases address collisions but does not completely avoid them. Other requirements (good address space packing and constant availability) are viewed as more important than complete address collision avoidance. Thus, closed groups as defined in Chapter 2 cannot be provided by this architecture. Good group address space packing is particularly an issue with IPv4 and might not be the dominant factor with IPv6, which provides a larger address space for multicast addresses than IPv4. IPv4 is limited to 270 million multicast addresses. Currently, a multicast address allocation architecture [81] is being developed within the IETF. The use of multicast addresses is limited by a lifetime and a scope. The scope limits the area of the network in which the address is valid. It is assumed that administrative scoping is used. Three different types of multicast address allocations are distinguished:

3.3 Scoping and Multicast Address Allocation ■ ■ ■

73

Static allocation Scope-relative allocation Dynamic allocation

Statically allocated multicast addresses are allocated for specific protocols, for example, for multicast session announcements (multicast address 224.2.127.255). They consist of an offset that is valid in every scope and that typically has a permanent lifetime. Scope-relative allocation of addresses are reserved for infrastructure protocols that need an address in every scope. Dynamic addresses are provided on demand and have a limited lifetime. Most applications will allocate their multicast address through dynamic allocation. Restrictions on lifetime are important in order to ensure that addresses are aggregatable and that multicast routing is close to optimal. The multicast address allocation architecture consists of local multicast address allocation servers (MAASs) and three different protocols: ■ ■ ■

A host-server protocol An intra-domain-server protocol An interdomain protocol

A multicast client that needs a multicast address uses the hostserver protocol to request such an address from the local MAAS. The protocol proposed for this purpose is Multicast Address Dynamic Client Allocation Protocol (MADCAP) [83]. The multicast address allocation protocol (AAP) serves as intra-domain-server protocol [75]. It is used to claim multicast addresses and to inform peer MAASs about used multicast addresses. With the interdomain protocol Multicast Address-Set Claim (MASC) [61], multicast address sets are allocated to domains. An allocation domain as used in the context of the multicast address allocation architecture is an administratively scoped multicast-capable region of the network. Normally it is assumed to be the same as a unicast autonomous system. Each MAAS receives address sets and caches them. The address sets are sent periodically through MASC. Within the corresponding domain, these address sets represent the allowable multicast addresses that can be used until the advertised lifetime. Furthermore, MAASs periodically receive multicast address claims from other MAASs in the domain via AAP. These addresses are also cached since they are currently used in the domain.

MADCAP

74

Chapter 3 — Multicast Routing The three protocols MADCAP, AAP, and MASC are discussed in some detail below. At the time of the writing of this book, all three are proposals being documented as Internet drafts. With MADCAP, a client can request multicast address allocation services from a local MAAS server. MADCAP is located on top of UDP (i.e., an unreliable transport service). The task of a client is to retransmit its request up to a maximum number of retransmissions if it does not receive a response within a certain time interval. It is recommended to issue the first retransmission after 4 seconds and to double this time for each subsequent retransmission. It is also recommended to use a maximum of three retransmissions. Servers must be able to distinguish a retransmission from a new request, since they may already have allocated a multicast address for that request. Therefore, recent responses are cached at the server. Currently, the following MADCAP data units to be issued at the client are proposed: ■ ■ ■ ■ ■

DISCOVER INFORM REQUEST RENEW RELEASE

With DISCOVER, MADCAP servers can be identified that are currently capable of satisfying a request. A DISCOVER data unit is always sent via multicast. An INFORM data unit is issued if the client aims at collecting configuration parameters such as the multicast scope list. An INFORM can be sent as unicast or as multicast. Multicast addresses are requested, renewed, and released with the corresponding REQUEST, RENEW, and RELEASE data units. These data units are sent via unicast from the client to the server. The MADCAP server can respond to client data units with the following data units: ■ ■ ■

ACK NAK OFFER

ACK and NAK are used to respond to REQUEST, RENEW, and RELEASE. The server reacts with OFFER to a DISCOVER data unit and reserves an address. The client collects OFFERs from multiple servers, selects a server, and issues a REQUEST to the same multicast address

3.3 Scoping and Multicast Address Allocation used for the DISCOVER data unit. The selected server commits the address and responds with ACK. The other servers remove the reservation on the address. It is important to associate client and server data units correctly. A transaction identifier has been introduced for that purpose. This identifier, together with the type of the data unit and a lease identifier, are supposed to be unique within a domain for a time interval of 10 minutes. A transaction is, for example, the attempt to allocate a multicast address or the attempt to acquire configuration parameters. AAP is used for address allocation within a domain between multicast address allocation servers. A multicast client requests a multicast address from MAAS through AAP. MAAS selects an address out of the address sets that it owns. In order to avoid address collisions, it does not immediately assign this address. First the MAAS multicasts a claim of the address to all MAASs in the domain using AAP and starts a timer with a default value of 4 seconds. If the MAAS receives a claim from another MAAS with the same address before the timer expires, it selects another address since an address collision occurred. It then sends another claim with the new address. If the timer expires and no other claim for that address has been received, the MAAS assumes the address is unique. Consequently, it returns the address along with its end time to the requesting client. The address allocation outlined above assumes that the MAASs have a good knowledge about the multicast addresses currently used within the domain. This requires that they have listened to previous address claims in the domain. Therefore, an MAAS must wait for at least 150 seconds after startup before it can respond to an address allocation request from a multicast client. Interdomain address allocation can be implemented with MASC. It is typically implemented on a border router. Its task is to claim and allocate one or more address sets to its domain. These address sets are used by MAASs in the domain. A MASC domain is characterized by the fact that it accommodates at least one MASC-capable system. MASC domains are structured in a hierarchical order in a tree corresponding to the hierarchy of domains on the Internet (e.g., campus networks and regional networks). MASC connections are locally configured as for the routing protocol BGP (Border Gateway Protocol) [130]. MASC operates over TCP. According to the hierarchical structure, a MASC router operates in one of the following roles with respect to each peer:

75

Transaction identifier

AAP

MASC

MASC domain

76

Chapter 3 — Multicast Routing ■ ■ ■ ■

Internal peer Child Parent Sibling

It acts as an internal peer if the local and remote MASC router are both in the same domain. A MASC router is in the role of a child if it may obtain address sets from the peer. Thus, a customer relationship exists. The role of parent implies that the MASC router can provide address sets to the corresponding peer; that is, a provider relationship exists. The role of sibling applies if no customer-provider relationship exists. Data units issued by a node will be propagated to its parent, all siblings with the same parent, and its children. The allocation of multicast address sets to the MASC domains is dynamic. The algorithm consists of two steps: ■ ■

Listen Claim

Listen Claim

MASC domain A can request an address set from MASC domain B that is located above it in the hierarchy. First it is informed by the MASC domain queried which address set is available at the higher level. This takes place through the listen step of the algorithm. A part of the address set determined through this step can be claimed. The claim is forwarded to the father and the siblings within the hierarchy, which can then detect collisions with their own claims. The claiming domain waits a certain time interval to see whether collisions are reported. If this is not the case, the domain passes on the information about the selected address area to the MAAS as well as to the other domains. This address set is called a group route. The MAAS of a domain can then assign multicast addresses from the multicast address space that has been allocated through the group route.

3.4 Concepts for Multicast Routing Multicast routing differs from traditional point-to-point routing in two ways: ■ ■

It has to deal with a group of receivers instead of a single receiver. The membership of the group can change frequently.

3.4 Concepts for Multicast Routing Efficient routing in the context of group communication is an important issue. Network load should be minimized, and, as with unicast routing, loops and concentration points of traffic need to be avoided. Special attention should be given to dynamic changes of group membership since the number of changes can be very high depending on the application. Routing algorithms should therefore work in increments and not monolithically. Thus, changes in group membership should not necessitate a complete recalculation of the routing information for an entire group or for an entire network. Instead, it should be possible to deal with these changes on a local basis. In contrast to the single path between sender and receiver in unicast routing, some form of distribution tree is required for multicast routing (see Figure 3.7). Several algorithms are available today for the Sender

R R R R R R

R

R R

Receiver R

Receiver R R

Router in distribution tree Router not in distribution tree

Receiver

Figure 3.7 Example of a distribution tree.

77

Incremental algorithms

Distribution tree is needed

78

Chapter 3 — Multicast Routing

Flooding

Improved flooding

Spanning trees

construction of such distribution trees. These will be discussed before the presentation of relevant multicast routing protocols. The simplest algorithm that can be used to reach all members of a group is called flooding. Upon receipt of the data, the router forwards it to all interfaces with the exception of the interface on which the data was received. No routing tables have to be maintained for the forwarding of the data. This makes the algorithm easy to implement. Furthermore, it guarantees that all group members that are reachable will receive the data. On the other hand, however, it is extremely inefficient because the principle is similar to broadcasting. Flooding can place a high internal load on a network, with many systems receiving data that is not addressed to them. Moreover, closed groups cannot be supported with flooding. With flooding, loops may occur, which means that data units can end up constantly circling in the network. Today, IP deals with this problem by providing a limited lifetime to IP data units. The lifetime is usually indicated as the maximum number of links that the data is allowed to pass. This information is transported in the TTL field of an IP data unit. Each router on the path decrements the TTL value by one. If it reaches the value zero, the data unit is discarded by the next router. An improvement on flooding described in [90] is based on the idea that it should be checked whether the data unit received is the initial receipt or whether it is the receipt of a copy of the data unit. In the latter case, the data unit should not be forwarded, in order to avoid loops. Although this approach will improve flooding, it requires that every router is able to identify recently forwarded data units. This can require a considerable amount of resources for buffering the corresponding information (identification of the data unit and interface of the router). In addition to buffering, the data has to be removed after a certain time. Timers can be used for this purpose. Although this added functionality helps to prevent loops, it cannot completely prevent data from being forwarded multiple times to a subnetwork. It only can avoid this in some cases. In summary, it should be pointed out that flooding is a very inefficient process. Therefore, flooding will not be considered any further as a basic algorithm. It is more or less a broadcast technique and was not designed for multicast support. The special characteristics of groups (such as membership) are not considered. Nevertheless, flooding is applied in some protocol designs, including protocols currently used on the Internet (DVMRP). An alternative algorithm that should be categorized here uses spanning trees (see Figure 3.8). These spanning trees are mostly used

3.4 Concepts for Multicast Routing

Network 5 R5 R4 Network 4 Network 3 R3 R1 R2 Network 2 Network 1

Figure 3.8 Example of a spanning tree.

in conjunction with bridges [171]. The loops mentioned previously are avoided through the creation of an overlay network that eliminates some of the actual links and intermediate systems from the network. The links and bridges build a spanning tree that reaches all systems in the network; that is, it spans the entire network. The example presented in Figure 3.8 shows a spanning tree (thick lines) overlaid on a network. This spanning tree ensures that all networks and end systems can be reached through it. Typically, not all router interfaces and not all routers are involved. For example, router R2 is not a part of the spanning tree. The same applies to the interface of router R3 to network 4. Once the spanning tree has been established, data can reach all destination systems by traveling along this tree, which means that all group members can be reached. However, this again is implemented without specific knowledge about group membership. Broadcasting is

79

80

Chapter 3 — Multicast Routing

High traffic load at root

Multicast tree

used along the spanning tree. Furthermore, traffic is concentrated at the root of the spanning tree as well as close to root, which can easily lead to a considerable performance bottleneck in the case of high traffic volume. In addition, routes are not optimal since they have to pass the root of the spanning tree. The root also presents a single point of failure. In many cases, spanning trees do not lead to optimal paths. As shown in Figure 3.8, for example, no direct communication is possible between networks 1 and 2. Although they are initially interconnected through router R2, it is not part of the spanning tree. Thus, communication between end systems in networks 1 and 2 takes place through network 3 and the routers R1 and R3. Spanning trees can be regarded as an improvement over flooding in that they prevent uncontrolled and, in some cases, multiple forwarding of data in a network. The following discussion presents algorithms that explicitly consider group membership during the setup of a distribution tree. The distribution tree constructed with these algorithms will be referred to as a multicast tree. To set up such a tree, the routing algorithms must be able to decide which systems are group members and which ones are not. The corresponding status information required in the routers should be minimal. As with point-to-point routing, a path should be optimized according to current cost considerations, which means that a routing metric or a combination of multiple metrics is used. Furthermore, traffic concentration as observed with the spanning tree should be avoided. The following three basic techniques specifically address multicast routing and are partially implemented in current protocols: ■ ■ ■

Source-based routing Steiner trees Trees with rendezvous points

3.4.1 Source-Based Routing Source-based routing is based on the premise that the receiver initiates the calculation of routing information. Therefore, a spanning tree is created for each source. Delay is the optimization criteria; that is, the spanning tree is considered optimal with respect to delay. The use of resources is not considered further in spanning trees. The already existing unicast tables provide routing tables for symmetrical links. Special multicast tables are not necessary if the same links and routers are used for unicast and multicast traffic. Loops cannot occur with this

3.4 Concepts for Multicast Routing approach. However, data can end up being sent to individual group members multiple times across different paths—for example, through different routers connected to the subnetwork. Source-based routing was used intensively in the multicast test bed of the Internet, the MBone (Multicast Backbone). The technique used in the Internet incorporates concepts from Dalal and Metcalf as well as enhancements to this technique by Deering [57]. The actual algorithm is referred to as reverse path forwarding (RPF). The refinements by Deering are mainly designed to prevent a duplication of data units in subnetworks. RPF operates as follows: If an involved router receives a multicast data unit, it notes the data source D as well as the interface I of the router at which the data unit was received. If I is located on the shortest path to the data source D (i.e., in the reverse direction), the data unit is sent to all interfaces of the router, except interface I. The router does not require dedicated multicast information, because the unicast routing information is basically sufficient. It should be noted, however, that this information identifies the optimal path from the router to source D, which is the reverse path compared to the user data flow that takes place. These two paths can differ if the links are not symmetric. As a result, multicast routing can be inefficient. If interface I is not located on the shortest path to source D, the received data unit is discarded, as shown in the example in Figure 3.9. The router receives a multicast data unit at interfaces I1 and I2. Since I1 is on the shortest path to D, the data unit is forwarded to all interfaces except I1. In contrast, the receipt of the data unit on interface I2 does not trigger a forwarding of the data unit because I2 is not located on the shortest path to source D. A comparison of RPF and flooding clearly shows that RPF can drastically reduce the overhead involved in forwarding data. If flooding were used, the example in Figure 3.9 would show the data unit received at interface I2 also being forwarded to all other interfaces. With RPF, a separate multicast tree is established for each source, with distance used as the metric. The advantage of using more than one tree is that traffic is spread more evenly over the network compared to the case with a single shared tree. Concentration of traffic is not to be expected. A major disadvantage of the basic version of RPF is that data in the network cannot be directed to a specific destination, because no knowledge of group membership exists. As a result, unnecessary load is created on the network, especially in the parts of the network where no group members are located. Because RPF takes into account the

81

RPF

Disadvantage: no routing to a specific destination

82

Chapter 3 — Multicast Routing

I7 I8

I6

I5

I4 I3

I1

I2

Shortest path to D

Router Ii: Interface i

Source D Figure 3.9 Routing with RPF.

RPB

shortest path in unicast routing and only forwards the corresponding data units, loops cannot occur. This is an improvement over flooding. Another problem with RPF is that it is possible for the same data unit to be transmitted more than once because of the lack of destination orientation in the router. As a result, the receiver can end up receiving the same data unit multiple times. Reverse path broadcasting (RPB) was proposed as a technique to improve RPF. RPB not only evaluates the shortest path in terms of the interface where the data unit is received but also considers the interface to which the data unit is sent. (See the example in Figure 3.10.) The data unit is only forwarded to those interfaces where the transmitting router is located on the shortest path to the data source in the reverse direction. In Figure 3.10, the data unit is only being forwarded to interfaces I3 and I7, that is, to router 3 and router 2, respectively. To implement RPB, the routers must have the necessary information about the shortest path. This is simple with link state routing protocols because each router has access to complete topology information for all domains. Distance-vector protocols can, for example, utilize the Poison-reverse technique (see Section 3.5.1).

3.4 Concepts for Multicast Routing

83

Router 2 I7 I8

I6

I5

I4

Router 3

I3 I1

I2

Shortest path to D

Router Ii: Interface i

Source D Figure 3.10 More specific routing with RPB.

Again, RPF and RPB implement broadcasting and not multicasting algorithms. Group membership is not considered during the setup of the distribution tree. Extensions to the basic RPF and RPB techniques take into account group membership. Truncated RPB (TRPB) is the first simple extension. It can be used to prevent data units for a group reaching a subnetwork in which no current group members are located [57, 116]. Therefore, the routers attached to the subnetwork must be informed whether local group members exist or not. The information is provided to the routers via the IGMP protocol for group management. If no group members are registered in a subnetwork, then the data is not forwarded to that subnetwork. In Figure 3.11 the last member of group G within subnetwork 1 is terminating its membership. Router R2 is being informed of this fact via IGMP and deletes G at the appropriate interface. Henceforth data being transmitted to group G will no longer be forwarded over the interface to subnetwork 1. TRPB thereby provides a mechanism for reducing traffic in subnetworks. The distribution tree is still constructed with the goal to reach all subnetworks irrespective of group membership. It therefore continues to be a distribution tree for broadcasting.

TRPB

84

Chapter 3 — Multicast Routing

Data

R1

R2

R3

Subnetwork 1 Terminates membership in G Member of G Figure 3.11 Scenario with TRPB.

RPM

Pruning

Reverse path multicasting (RPM) is yet another refinement to source-based routing. It works on the basic premise of only forwarding data to network areas if a current group member is located there. However, it first has to know which areas of the network have group members located in them. Furthermore, this information must be constantly updated to reflect changes in group membership so dynamic groups can be supported. The technique of pruning was developed to address this requirement. The first data unit a sender transmits is still flooded to the entire network, as described previously. It functions, so to speak, as a trigger for supplying information about group membership and is used as a mechanism for addressing all potential members throughout the network. Information about group membership is provided in the network as follows: The first data unit transmitted by a sender moves through all routers until it reaches the end systems. In this context, routers that are not followed by any other routers are referred to as leaf routers. In Figure 3.12 these are routers R2 and R3. If a group member of group G happens to be located behind such a leaf router in a subnetwork, then the data units belonging to G must be forwarded to this router. If no group member of G is located behind the leaf router in the

3.4 Concepts for Multicast Routing

Data

R1 Pruning data unit

R2

delete

R3

Terminates membership in G Member of G Figure 3.12 RPM implements pruning.

subnetwork, then this leaf router does not require any data units that have been addressed to group G. In Figure 3.12, within the subnetwork attached through leaf router R2, the last group member terminates its membership in group G. The leaf router consequently issues a pruning data unit to report this situation to router R1, which is located ahead of it in the distribution tree. The pruning data unit is assigned a TTL value of one so that it is not forwarded further in the network. It is therefore sent over exactly one link. Pruning data units are sent per unicast. If a router receives a pruning data unit, it must adapt the routing information accordingly. It subsequently does not forward any data units from sender S over the corresponding interface of the router to group G. Therefore, the router has to keep status information about groups and senders. If a router has received pruning data units for a group G at all its interfaces and it does not have a group member to serve locally, it in turn forwards a pruning data unit to the router located ahead of it in the distribution tree. This gradually results in the setup of a multicast tree that only contains branches that serve current group members. The other branches are successively removed.

85

86

Chapter 3 — Multicast Routing

Regular networkwide forwarding

Pruning must also consider group dynamics. For example, it is possible for a new group member to join a subnetwork that is no longer contained in the current multicast tree. This circumstance must be reflected in the multicast tree. The same applies to changes in network topology. Therefore, status information in the routers is assigned a limited lifetime. If this lifetime expires, the entry with the pruning information is deleted. The result is that, as with TRPB, the next data unit is again flooded in the network so that it reaches all potential receivers in the subnetwork. Such a retransmission of pruning data units enables an updating of the multicast tree. The new group member therefore receives the data that is sent to the group. In contrast to the techniques presented earlier, RPM is a multicasting technique because it takes into account group membership during setup of the distribution tree. It is, however, not particularly suitable for use in large networks. The periodic forwarding of data units to all subnetworks in a network does not scale when a large number of groups is involved. If long intervals are selected for periodic transmission, this increases the delay to join a group that previously had no members in the subnetwork. This also means that a member cannot receive data until its membership to a group has been effected. Short intervals can place a high load on the network, which is also undesirable. To resolve this problem, a new receiver can immediately issue an explicit notification message to inform the router about its presence. The router then forwards data for that group in the corresponding subnetwork. Furthermore, because of pruning, status information about senders and groups must be maintained in the intermediate systems in the network, which can only be implemented efficiently if a small number of groups and senders exist. Otherwise, the resource requirements within routers are very demanding. Table 3.4 contains a summary of all basic techniques for sourcebased routing presented. The gradual refinements from flooding to RPM are highlighted in italic.

3.4.2 Steiner Trees A Steiner tree is used to establish a spanning tree that has the minimum overall cost. The main goal is a global optimization of cost. Other algorithms such as the Dijkstra algorithm optimize cost based on a single source only. With Steiner trees, the overall cost of a spanning tree is always the same or lower than routing based on the shortest path. However, in Steiner trees the cost for a certain pair of nodes

3.4 Concepts for Multicast Routing

87

Table 3.4 Source-based routing. Technique

Broad-/Multicast

Routing

Data units

Network domain

Flooding

Broadcast

All interfaces

All data units

Entire network

RPF

Broadcast

All interfaces

Data units from shortest path

Entire network

RPB

Broadcast

Interfaces on shortest path

Data units from shortest path

Entire network

TRPB

Broadcast

Interfaces on shortest path

Data units from shortest path

Not in subnetworks without group members

RPM

Multicast

Interfaces on shortest path

Data units from shortest path

Only in network domains with members

can be higher. Steiner trees are not only considered in the context of data communication but also, for example, in the design of integrated circuits. Since Steiner trees optimize on a global basis, a recalculation is required whenever a change in topology or group membership occurs. Consequently, Steiner trees are referred to as monolithic algorithms [57]. In addition, the Steiner problem is NP-complete. This statement still applies even if all edges in a network are assigned the same value. The minimum costs are then O (n log n), with n representing the number of nodes in a network [57]. Because of their inefficiency, Steiner trees are not viable for large networks or large groups, or if frequent changes are made to network topology, or if groups are very dynamic [59]. Another limitation of Steiner trees is that they regard links as being symmetrical and cannot be used if this is not the case. Although Steiner trees represent an approach frequently pursued in theory, the complexity of the approach and its reduced suitability for use in realtime environments make it less attractive for practical implementation for routing within data networks. Furthermore, Steiner trees constitute a centralized solution, which is often not practical in large communication systems. Only heuristics can be implemented on a distributed basis. We are not aware of any current applications of Steiner trees in data networks. Because of their limited practical application, Steiner trees will not be dealt with further in this book. The focus instead will be on the presentation of actual approaches currently used for group communication, particularly on the Internet. A variety of heuristics were proposed for the construction of Steiner trees. In many cases, this shows that simple techniques can

NP-complete

Heuristics

88

Chapter 3 — Multicast Routing provide solutions that are just as good [59]. Above all, these techniques often result in trees that show more stability if the potential to be very dynamic exists in networks and groups.

3.4.3 Trees with Rendezvous Points Rendezvous points

Trees with rendezvous points represent a new development in the context of multicast or multipeer communication. In contrast to Steiner trees, these trees consider multiple senders and receivers. Unlike source-based routing, which was described earlier, trees with rendezvous points prevent the initial networkwide flooding of data units. Corresponding algorithms are inherently based on the establishment of rendezvous points in the network. These rendezvous points are familiar with group membership. They receive the required information, for example, they are notified if a new member has joined a group (see Figure 3.13). When this information is forwarded, it passes through all routers located between the new member and the rendezvous point. This allows those routers to extract whatever information

Rendezvous point Leave group 1 Data

Join group 1

Pebbles ... ...

Dino Barney Fred Group 1 Figure 3.13 Group with rendezvous point.

3.4 Concepts for Multicast Routing is relevant to them, such as group membership. A router therefore stores information that provides details about the group membership of subsequent receivers. If no group member is located on that side of the router, the link is inactive. This is in contrast to the broadcasting algorithms described earlier. Compared to Steiner trees, only the selection of an optimal rendezvous point presents an NP-complete problem. Simple heuristics are generally used for the selection of rendezvous points. The basic procedure for these trees initially requires the selection of a rendezvous point for a group. The members of the group issue the appropriate data units in order to register at the rendezvous point. Routers located on the path between group member and rendezvous point forward this register data unit toward the rendezvous point. All they need is information about the group. In contrast, source-based routing requires information not only about the group but also about the sender. Trees with rendezvous points do not require that the data sources (i.e., the senders) are members of the group because they are only concerned with routing aspects (i.e., with the destination of data units). In this sense a spanning tree for each group is established, and not a spanning tree for each sender. The data flow is as follows: The data units are forwarded from the sender to the rendezvous point. From there they are distributed to the receivers of the group. The advantages of algorithms using rendezvous points can be seen in the restriction of data distribution to group members only. The effort involved in maintaining status information in the routers is also relatively small; identification is only required of the groups and not of the pairs of senders and groups. The disadvantage of these trees is clearly the concentration of traffic that can occur at a rendezvous point. In addition, rendezvous points represent a single point of failure, which means fault tolerance is low. Variants offering several rendezvous points per group can reduce this problem. However, they will increase the amount of administration required.

3.4.4 Comparison of Basic Techniques The three basic techniques for multicasting described previously are summarized and compared, along with some of their important characteristics, in Table 3.5. Steiner trees represent the only technique that implements a monolithic approach. This makes them less suitable for dynamic groups since they require a complete recalculation of the multicast

89

90

Chapter 3 — Multicast Routing

Table 3.5 Comparison of techniques. Criteria

Source-based

Steiner trees

Rendezvous points

Approach

Incremental

Monolithic

Incremental

Flooding

Yes, partially restricted

No

No

Centralized/Distributed

Distributed

Centralized

Distributed

Single point of failure

No

No

Yes

Group density

High

—

Low

Traffic concentration

No

No

Yes

Practical

Yes

No

Yes

Overhead

Minimal

Very high

Average

tree with each change in group membership. Source-based techniques use flooding that is partially reduced because the shortest path is considered (see Table 3.4). Source-based techniques are likewise not very suitable for group communication in large networks, but they are promising for smaller networks and are also used in practice. Algorithms with rendezvous points are attractive because they completely eliminate flooding. The problem is that rendezvous points constitute points of concentration for a group’s traffic and represent a single point of failure. The situation can be alleviated if each network has more than one rendezvous point with each one serving a different group. Algorithms with rendezvous points are more suitable for widely distributed groups where group members are not located in each subnetwork, that is, in the case of low group density. Source-based algorithms that use broadcasting are preferable if group members are located in almost every subnetwork and, thus, high group density exists. The additional overhead created with networkwide routing or data unit flooding is not crucial in the case of high group density. Note that Steiner trees currently do not play an important role in data communication, unlike the two other basic techniques presented.

3.5 Multicast Routing on the Internet This section is devoted to multicast routing protocols that are used on the Internet or that have been discussed in the context of the Internet. They are based on source-based routing as well as on trees with rendezvous points.

3.5 Multicast Routing on the Internet What is common to the different protocols is that they use IGMP as the basis for group management. The requirement in network areas with a shared medium (e.g., Ethernet segment) is, therefore, that a designated router is informed of group membership. Any further processing of group membership is specified in the different multicast routing protocols.

91 IGMP

3.5.1 DVMRP The Distance Vector Multicast Routing Protocol (DVMRP) [156] is a multicast extension to the routing concepts used in RIP (see Section 3.1.1). It represents a distance-vector algorithm that determines the shortest path to a data source. In terms of the classification of multicasting algorithms presented previously, DVMRP can be listed in the category of source-based procedures. The DVMRP protocol calculates the previous link back to the source, whereas RIP calculates the next link in the direction of the destination. DVMRP was initially based on the TRPB algorithm [156]. Since version 3, it uses RPM with the advantages and disadvantages already mentioned [128]. A particular advantage of DVMRP is that it offers targeted routing in networks with group members. With DVMRP, a multicast-enabled router typically implements two independent routing protocols, including the corresponding routing tables: ■ ■

Distance-vector algorithm

DVMRP for multicast routing RIP or OSPF, for example, for unicast routing

Starting with version 3, DVMRP includes direct support for tunneling IP multicast data units through routers (see Figure 3.14). DVMRPdata units in DVMRP-enabled routers will be encapsulated into normal unicast IP data units. DVMRP-enabled routers decapsulate the data units and perform the necessary operations. According to the distance-vector algorithm, the first requirement is for DVMRP routers to become acquainted with their neighbors. Therefore, they periodically transmit neighbor probe data units assigned with a TTL value of one. Since neighbor probes contain a list of all neighbors of a system, this process enables a bidirectional neighborhood to be established. Multicast data units are routed using RPM. To calculate the routing tables, the routers exchange distance vectors with their neighbors.

Becoming acquainted with the neighbors

92

Chapter 3 — Multicast Routing Unicast routing

Multicast routing DVMRP router

Multicast routing

Unicast router

MC

DVMRP router MC

Data

MC

UC

MC

UC

MC

DVMRP tunnel UC: Unicast MC: Multicast

Figure 3.14 Tunneling between DVMRP routers.

The resulting routing metric is increased by the value of the interface where the data unit was received. The distance vectors sent by DVMRP are specifically designated for multicasting. Unicast routing uses its own distance vectors and routing tables that are updated via RIP. Unicast data can, therefore, follow a different path through the network than multicast data—if this is appropriate. Two techniques are employed for dynamic control of the multicast tree: ■ ■

Poison-reverse

Poison-reverse Graft data units

With Poison-reverse, the preceding router in the tree is informed that group members are located in this part and, consequently, multicast data has to be forwarded. Therefore, distance vectors are periodically transmitted to neighboring routers. If a router receives a distance vector from a preceding router in the tree, it reflects this vector to prevent it from being disconnected from the multicast tree. It therefore signals to the preceding router in the tree that it is dependent on it. The destination address used is the reserved multicast address AllDVMRP-routers [131]. The reflected distance vector (see Figure 3.15) must be identified, since it cannot be used for revising the distance vector in the preceding router due to the count-to-infinity problem (see Section 3.1.1). The routing metric is the received metric increased by the value infinity. The preceding router recognizes a routing metric with values between infinity and twice infinity and determines from

3.5 Multicast Routing on the Internet

93

Poison-reverse: D1 = 7 + ∞, . . .

...

Sender

Router 1

Router 2

...

Receiver Distance vector: D1 = 7, . . . Figure 3.15 Use of Poison-reverse.

this that a Poison-reverse process is involved. Therefore, the corresponding interface must remain in the multicast tree. If a router has not received a Poison-reverse at an interface for a certain period of time, it assumes that no group members are located behind it. If this applies to all interfaces of a router, a pruning data unit is forwarded in the direction of the sender and the router is removed from the multicast tree (see Figure 3.12). Graft data units are used to reconnect an area that has been uncoupled from a multicast tree through pruning. Reconnection is necessary if new group members have appeared in that area. The router at which the new member appears issues a graft data unit to the preceding router if it had forwarded a pruning data unit to the preceding router before. Figure 3.16 shows an example. Initially no member of group G is located in subnetwork 1. Router R1 therefore does not forward any data units specified for this group to router R2. Router R2 learns from IGMP that a new member has joined the group. It then forwards a graft data unit to router R1 to enable it to be reintegrated into the multicast tree. Data to group G is subsequently routed to the new member over R1 and R2. Graft data units are acknowledged. Acknowledgments are needed in order to determine whether a data unit has been lost in the network or whether the sender has stopped sending. If no acknowledgment is received within a predetermined time interval, the graft data unit is repeated based on an exponential backoff procedure. An acknowledgment only indicates that a graft data unit has been received correctly. It does not confirm that action has been undertaken to integrate the system into the group. It is necessary for a designated forwarder to be selected for each source (see Figure 3.17) to prevent duplicated data units being

Graft data units

Acknowledged graft

Designated forwarder

Data

R1 Graft data unit

Graft acknowledgment

R2

R3

Subnetwork 1 New member of group G Members of G Figure 3.16 Reintegration per graft.

Sender

Becomes designated router

Router 1 (address: 27)

Receiver

Figure 3.17 Determining the designated router.

Router 2 (address: 42)

3.5 Multicast Routing on the Internet

95

forwarded on the network. The designated forwarder is determined as a side effect of route exchange. When two routers exchange source networks, each of the routers learns the metric of the other router. The router with the lowest metric to a source is selected as designated forwarder to this source. If multiple routers have an equally low metric, then the IP address is additionally used as decision criteria. Out of this group of routers, the one with the lowest IP address becomes the designated forwarder.

Hierarchical DVMRP The problems known from distance-vector algorithms also exist with DVMRP. The strong growth of the MBone is the main reason why DVMRP is quickly reaching its limits. DVMRP regards the entire Internet as a flat domain. This is not suitable for a network of this size. The hierarchical DVMRPs (HDVMRP) concept [150] was proposed as an improvement. The concept employs a two-stage hierarchy where, in contrast to the original DVMRP, a distinction is made between nonoverlapping domains, or regions (see Figure 3.18). Each domain is identified by a unique identification. Furthermore, routers within a domain can be distinguished from those located on the boundary of a domain. The latter routers interconnect domains and are called boundary routers. Boundary routers and inner-domain routers each use different routing protocols. The hierarchical extension to DVMRP can be used as

DVMRP domain Boundary router

DVMRP domain

Boundary router

Boundary router HDVMRP routing

Boundary router DVMRP domain

Figure 3.18 Hierarchical DVMRP.

HDVMRP

96

Chapter 3 — Multicast Routing the protocol between the boundary routers. Different protocols, such as DVMRP or MOSPF (described later), can be used within domains. Boundary routers therefore implement two different multicast routing protocols: a protocol for routing within a domain and HDVMRP for routing between domains. This sort of structure also has the advantage that the routing protocols within a domain can be developed and used independently of HDVMRP. The main advantage, however, is that the routing protocols only have to be dimensioned for smaller domains and not for an entire network. There are three steps involved in routing using HDVMRP: ■ ■ ■

Routing in the source domain

Routing between domains

Routing in the destination domain

Routing in the source domain Routing between domains Routing in the destination domain

Within a source domain, a multicast data unit is first transmitted to those subnetworks that contain members of the multicast group. In addition, all boundary routers receive the multicast data units. The boundary routers decide whether the data units should be forwarded to another domain. Pruning is used to reduce the multicast tree within a domain. Routing between nonoverlapping domains is implemented according to the hierarchical DVMRP. It is therefore based on the identity of the domains that are used as addresses and not on subnetwork addresses. The data units to be forwarded are encapsulated in an HDVMRP data unit. The outer header contains the identity of the domain. This identity is retained even if the data unit is sent across multiple domains. The original data unit is not interpreted until the destination domain is reached. There, it is decapsulated from the HDVMRP data unit by a discarding of the outer header. Boundary routers are combined into a dedicated group (ABR: All Boundary Routers). If data units are routed between domains, they are encapsulated as described previously and assigned the multicast destination address of all boundary routers. The receiving boundary routers decapsulate the data unit and check whether it was received over the shortest path. If this is the case, the destination domain is established. Otherwise the data unit is discarded. If the data unit is to be routed to another domain, it has to be encapsulated again. It therefore again runs through the procedure just described. If the data units reach the destination domain, they are forwarded to the destination systems located in this domain. Therefore, it must be signaled beforehand that group members are located in this

3.5 Multicast Routing on the Internet

97

domain. If this is not the case, the data will not be routed to a domain. Typically, DVMRP in its original version will be used within the destination domain. HDVMRP is not currently being used on the Internet and also will not be dealt with further in this book. The reason is the increasing concentration on developments for protocols that replace DVMRP [57]. The problems typically associated with distance-vector algorithms are driving that development.

3.5.2 Multicast Extensions to OSPF Multicast Extensions to OSPF (MOSPF) [109] is another routing protocol for multicasting on the Internet. It is based on OSPF (Open Shortest Path First) [108] and can be categorized as a source-based algorithm for multicast routing. In contrast to those algorithms presented in Section 3.4.1, however, it is not a reverse path algorithm. OSPF and, consequently, MOSPF are based on the link state algorithm.

The Basis: OSPF This section first presents a brief summary of OSPF, which is used as the underlying protocol for MOSPF, followed by a description of MOSPF itself. With OSPF the network is basically viewed as a directed graph. The use of a certain router as the root determines the shortest path to all existing destination systems. The Dijkstra algorithm is used to calculate the shortest paths. OSPF uses the following data units for communication between the involved routers: ■ ■ ■

Hello Database description Link state

Routers learn who their direct neighbors are by sending Hello data units. These data units also allow the operability of the neighboring router to be checked. The routers periodically transmit Hello data units about every 10 to 30 seconds. The Hello data units are only sent per unicast to the neighboring routers. They are not forwarded further in the network. The designated router is selected on the basis of these Hello data units. As selection criteria, the priority field carried within a Hello data unit is used. The router with the highest priority is selected

Hello

98

Chapter 3 — Multicast Routing

Database description

Link states

Metrics

as the designated router. Once selected, a designated router will remain in operation as long as possible. If it can no longer serve its function, the router designated as a replacement will be activated as the new designated router. Once the designated router has been selected, the topology databases between the neighboring routers have to be synchronized. For this purpose, the neighboring routers use data units that transport complete database descriptions. The neighboring routers are configured according to the master-slave principle. The master is selected on the basis of the router identity. It transmits parts of the database in a data unit assigned with a sequence number. The slave acknowledges this data unit using the same sequence number and also forwards information about its database. The master uses a special end bit to indicate that it has transmitted its entire database. If the slave’s database is the larger of the two, the master has to transmit empty data units until the slave has also completed transmission of its database. This initial exchange of databases is followed by a procedure that uses link state data units or link state advertisements (LSAs) to request and send selected routing information (e.g., incremental changes). OSPF operates reliably in the respect that link state data units with update information are sent to all neighboring routers and are acknowledged by them. These messages are transmitted periodically (every 30 minutes) or when changes occur. The OSPF protocol can use different metrics for path selection. The following parameters can, for example, be used [4]: type of service, minimum cost, maximum reliability, and maximum throughput. In IP data units, different metrics can be indicated in the type of service field [127]. In total, eight metrics are supported by OSPF; that is, it allows appropriate paths to be determined through a network for them. The Dijkstra algorithm is applied separately for each type of service. As a result, separate directed graphs are established. OSPF permits load balancing if several paths with the same cost exist to a destination. An equal load distribution between alternative paths is possible, which is not the case with distance-vector algorithms.

Multicast Extensions

MOSPF

The briefly explained unicast routing protocol OSPF was expanded to include the multicasting capabilities discussed below [107]. The extensions are backward compatible so MOSPF-enabled routers can

3.5 Multicast Routing on the Internet operate with routers that implement OSPF only. This of course is limited to unicast traffic. The two main extensions are the following: ■ ■

The local group membership must be known in the routers. A separate multicast tree has to be calculated for each pair consisting of sender S and group G (S, G).

Like OSPF, the protocol MOSPF divides an autonomous system (AS) into different nonoverlapping domains (see Figure 3.19). These domains are linked together through a backbone. Each domain has boundary routers (BR) that are responsible for the interconnection to other domains. Additional routers that interconnect the different domains are placed inside the backbone. AS-boundary routers link together different autonomous systems. Routing based on MOSPF can be subdivided into the following: ■ ■ ■

Routing within domains Routing between the different domains of an autonomous system Routing between autonomous systems

Autonomous system

Domain

Boundary AS router

Backbone

BR

R

Domain

BR R R

BR BR Domain BR: Boundary router AS: Autonomous system Figure 3.19 Composition of an autonomous system with MOSPF.

99

100

Chapter 3 — Multicast Routing

Routing in domains

The following discussion first focuses on routing within domains— when the sender as well as the group of receivers is completely located in the same domain. Special group member LSAs provide information about group membership. All MOSPF routers thus know in which subnetwork of a domain group members are located. With this information it can also be determined whether a group in its entirety is located within a particular domain. This information is stored in each router in a database listing local group membership. Figure 3.20 shows an example of the topology within a domain. Two groups (A and B), whose members are spread over several networks, currently exist in this domain. Table 3.6 shows the database with local group membership that belongs to the topology shown in Figure 3.20. The entries are structured so that they provide the group as well as the network that currently has Network 1

A

R3

R1

R2

Network 2

Network 3

B

R5

R4

A

Network 4

R7

R6 Network 5

B Figure 3.20 Example of a topology in a domain.

Network 6

B

A

3.5 Multicast Routing on the Internet Table 3.6 Local group database. Router

Local group database

R1

(A, N2) (B, N2)

R2

(A, N3)

R3

—

R4

—

R5

—

R6

(B, N5)

R7

(A, N6)

members attached to it. Entry (A, N2) in the first line should be interpreted as follows: Network N2, which is directly attached to router R1, hosts group members of group A. The same applies to group B. Information about group membership is used to identify the subnetworks that have to be reached for a group. It is also used in the special group member LSAs that are periodically sent through the network like other link state information. Since MOSPF uses link state routing, the individual routers are always aware of the network topology—at least within a domain. The local group database supplements this information, adding group membership. The information required to derive the multicast trees in the routers is therefore available, related to a single domain. As mentioned previously, a multicast tree is determined for each pair (S, G). The calculation required for a group size of n is in the order of O(n log n). Because of the high overhead, MOSPF follows the philosophy that multicast trees should only be calculated when necessary. The routing information that has been calculated for the multicast tree is then stored temporarily in a forwarding cache so that it is available to other data units. Table 3.7 shows an example of a forwarding cache. Take the scenario that the data source for group A is a sender connected to network 1 and the cost per link is 1. An entry in the forwarding cache comprises the interface to the sender (upstream), the interfaces to the receivers (downstream), as well as the remaining cost on the way to the receiver. The entry for router R3 indicates, for example, that the sender can be reached over the directly connected network N1 at a distance of 1. Group members can be reached over two downstream interfaces: over N4 with a distance of 2, and over R5 also with the cost of 2. If the underlying network topology changes, the

101

102

Chapter 3 — Multicast Routing Table 3.7 Example of a forwarding cache.

Routing across domain boundaries

Upstream

Downstream

R1

(N1, 1)

(N2, 1)

R2

(N1, 1)

(N3, 1)

R3

(N1, 1)

(N4, 2) (R5, 2)

R4

(N1, 1)

(N4, 2)

R5

(R3, 2)

(N6, 1)

R6

(N4, 2)

(N5, 1)

R7

(N4, 2)

(N6, 1)

entire forwarding cache has to be deleted and a complete new calculation of the paths is required. As is the case with other routing protocols, the concept of a “designated router” is applied if a subnetwork has more than one router. Use of a designated router prevents data units from being routed multiple times into the same subnetwork. Until now the discussion has focused on routing within a domain. However, MOSPF also supports routing across domain boundaries. Some principal issues require clarification in this context—for example, whether link state advertisements are only transmitted within a domain and not across domain boundaries. If this is the case, a complete view of the network topology in the entire autonomous system cannot be provided. This can lead to the use of routes that are not optimal. The following issues need to be resolved for routing across domain boundaries: ■

■ ■

Interarea multicast forwarders

Router

How will information about group membership be made available across domain boundaries? How will multicast trees be established across domain boundaries? How is multicasting implemented across the boundaries of autonomous systems?

In OSPF, boundary routers forward routing information and data between domains. MOSPF handles this similarly. Information about group membership is forwarded from boundary routers to other domains. However, not all boundary routers need to be responsible for this task, only a subset called interarea multicast forwarders (see Figure 3.21). By default, all multicast-enabled boundary routers are

3.5 Multicast Routing on the Internet

Interarea multicast forwarder

103

Summary LSA

All multicast data units of the domain

Boundary router

Boundary router Boundary router Figure 3.21 Multicasting across domain boundaries.

configured as interarea multicast forwarders. They forward summaries about the group membership of their domains to outside domains. This procedure determines which groups have members in a respective domain. For each of these groups, a group membership LSA is sent to the backbone. From this information the backbone then creates its own database that identifies which boundary routers are serving which group members in their domains. Based on this information, data can be routed to the corresponding domains. The summaries on group membership are not forwarded from the backbone into the domains, which would be the case with OSPF, because it would dramatically increase the overhead with MOSPF. The individual domains are therefore only aware of their local group membership. MOSPF introduced a new concept called wildcard multicast receivers to enable multicast data to be routed to other domains. All multicast data for a domain is forwarded to wildcard multicast receivers, irrespective of current group membership. All interarea multicast forwarders are simultaneously wildcard multicast receivers. This guarantees that all multicast data is forwarded to the backbone because an interarea multicast forwarder receives all multicast data sent within a domain. It can therefore forward it to the backbone if required. Once the data has reached the backbone, it can be easily forwarded to all

Wildcard multicast receivers

104

Chapter 3 — Multicast Routing

Attention to pruning

Good solution is approximated

Attention to asymmetrical links Between autonomous systems

respective domains or to their interarea multicast forwarders. As stated before, information about group membership in the individual domains is available in the backbone. Thus, the question of how information about group membership is made available across domain boundaries is clarified. The next issue addresses the construction of the required multicast trees with the incorporation of the backbone. It is often not possible to produce shortest-path trees because routers do not have information about the entire network topology. If all group members are located within one domain, the multicast tree is determined as described previously. However, we must ensure that pruning does not isolate links to other domains. The problem is the lack of information that is available. It cannot be determined whether these links are required for interdomain routing related to other groups. As a result, only those links that do not lead to the group members within a group and do not have wildcard multicast receivers attached to them are eliminated. This guarantees the accessibility to other domains. If the group members are distributed across several domains, the backbone domain has to be incorporated into the multicast tree. Since only a domain’s own topology is known within the domain, a good solution can only be approximated. However, summaries about group membership within the domains, which have been sent by the wildcard multicast receivers to the backbone, exist on the boundaries of the domains. Thus, the receiver first establishes a path in the direction of an interarea multicast forwarder (see Figure 3.22). At this point, the cost to the sender is known. In Figure 3.22, for example, the sender is located in domain 2. Individual links are subsequently removed from the multicast tree through pruning in accordance with the conditions mentioned previously. Note that the reverse cost is used when a multicast tree that reaches across domains is established. In Figure 3.22 the shortest path from receiver A to the interarea multicast forwarder is the one that is established first. However, the user data flows in the opposite direction, namely, from the forwarder to receiver A. The path between forwarder and sender is also established in the opposite direction. In the case of highly asymmetric links, this can easily result in the provision of nonoptimal paths. In addition to the discussion above, clarification is needed on how multicasting is implemented between autonomous systems. A concept similar to the one for multicasting between the domains within an autonomous system is applied. AS boundary routers interconnect several autonomous systems. They are partially configured as inter-AS

3.5 Multicast Routing on the Internet

Backbone

Sender Domain 2

Cost to sender: K

Interarea multicast forwarder

Receiver A

Receiver B Domain 1 Figure 3.22 Multicast tree across domain boundaries.

multicast forwarders that operate as wildcard multicast receivers. The AS boundary routers consequently implement a special routing protocol for multicasting between autonomous systems. This routing protocol is not defined by MOSPF. It is assumed, however, that this protocol uses RPF to forward multicast data. Some analyses plus experiences with MOSPF are summarized in [106]. Explicit reference is made to scalability with respect to the number of systems in a domain. A domain should not comprise more than 200 systems. Because a separate multicast tree is established for each pair (S, G), bottlenecks may even occur with this limited number of systems. Problems can arise in a network that concurrently operates OSPF and MOSPF routers. It is important to ensure that the MOSPF router is the one selected as the designated router. Otherwise, no multicast traffic can be routed to the corresponding subnetwork.

3.5.3 PIM Protocol-Independent Multicasting (PIM) defines two different protocols, both specified in separate documents and designed for different group topologies:

105

106

Chapter 3 — Multicast Routing ■ ■

PIM-sparse and PIM-dense modes

Protocolindependent

PIM-sparse mode [49] PIM-dense mode [50]

PIM-sparse mode (PIM-SM) [48, 49] is based on the assumption that systems are likely to be located far away from each other. The available bandwidth tends to be small. Members are available only in some of the subnetworks involved. For PIM-dense mode (PIM-DM), the distances between members must be short. Moreover, their availability is judged to be high. The density of group members is very high and members can be found in almost every subnetwork. The procedures resulting from these different assumptions are explained in the following. PIM can be considered as being protocol-independent since it has not been defined for use with any particular unicast routing protocol (see Table 3.8). For optimization purposes, the following criteria were established for PIM: ■ ■ ■

Minimize status information in routers. Minimize processing overhead for control and user data in routers. Minimize bandwidth consumption in the network.

PIM-SM can be classified in the category of trees with rendezvous points. The underlying architecture for PIM is presented in [48] and [51]. PIM subdivides networks into PIM domains and non-PIM enabled domains. All routers in a PIM domain use PIM for multicasting. They operate within a common area that has multicast boundary routers (see Figure 3.23) placed at the boundaries to other domains. Multicast boundary routers are responsible for interconnecting PIM domains to the part of the Internet that does not implement PIM. Bootstrap routers that have the task of distributing information about rendezvous points (see below) are also present within PIM domains. Table 3.8 Multicast and unicast routing. Multicast protocol

Unicast protocol

DVMRP

RIP

MOSPF

OSPF

PIM

Can be selected

3.5 Multicast Routing on the Internet

PIM router

107

Multicast border router

PIM router PIM router

Bootstrap router PIM domain

Multicast border router

Multicast border router

Non-PIM enabled domain

Multicast border router

PIM domain PIM domain

Figure 3.23 PIM domains and multicast boundary routers.

PIM-Sparse Mode RFC 2362 [49] describes PIM-sparse mode. It is more efficient for groups with members that are geographically distributed in the network than for groups with high density. Two basic premises exist for operating PIM in sparse mode: ■ ■

Group membership is based on explicit join operations. Rendezvous points are provided.

The requirement for an explicit join to a group is designed to reduce the number of multicast data units produced by a sender at startup. In sparse mode, the data is sent to the rendezvous point only, not through the entire network. The assumption of DVMRP that group members can be found anywhere and that trees are subsequently reduced through pruning is explicitly replaced by this concept. Instead it takes the initial approach that no group members exist. If members are available in a domain, then this domain has to be registered through an explicit join operation to the group. The data is then routed from the rendezvous point to this domain. It is therefore the

Explicit group join

108

Chapter 3 — Multicast Routing

Receiver joins a group

responsibility of the group members to determine whether they receive data. With PIM-sparse mode, rendezvous points are available for the establishment of the multicast tree. PIM-sparse mode therefore appears in the category of trees with rendezvous points introduced previously. These rendezvous points enable group awareness and explicit join operations to a group. Figure 3.24 shows an example clarifying the use of rendezvous points. In addition to three PIM routers, a rendezvous point is available. In actual applications, a number of rendezvous points are distributed over a network. A group utilizes only one rendezvous point. If a receiver in PIM intends to join group G, it uses IGMP for signaling in the local subnetwork. The designated router in this subnetwork is thereby notified of its group membership. In Figure 3.24, this designated router is identical to PIM router 1. First, it is ascertained whether a rendezvous point is already known for group G. To obtain this information about rendezvous points, all routers within a PIM Sender

Data PIM router 3

PIM register data unit PIM join

PIM router 2 PIM router 1

PIM join

IGMP join Receiver Figure 3.24 Rendezvous points with PIM-sparse mode.

PIM join

Rendezvous

3.5 Multicast Routing on the Internet domain collect bootstrap data units. After identifying the rendezvous point, the router periodically sends an explicit join data unit (PIM join) to it. The timer controlling the periodic sending of the join data unit is randomly set to a value between 1 and 60 seconds. Figure 3.25 shows the basic structure of a shared tree in which the rendezvous point represents a central node. All members of a group can be reached through the corresponding shared tree. The senders of a group use tunneling to establish unicast paths to this rendezvous point. A multicast tree exists from the rendezvous point to the group members. This shared tree is not necessarily optimal for the individual combinations of senders in a group. The option of switching to a sender-specific tree is provided, which relieves the overhead for encapsulation and decapsulation for high data rate streams. However, according to a recommendation in RFC 2362 [49], a sender-specific

Senders of group G Unicast

Rendezvous point Multicast

Receivers of group G

Figure 3.25 Shared tree with rendezvous point.

109

Shared tree

110

Multicast routing entries

Chapter 3 — Multicast Routing tree should not be used until a significant number of data units have been received in a certain time interval from a particular source. The thought behind this is to avoid creating a lot of state information for low data rate streams. Furthermore, the appropriate multicast routing entries have to be generated in the routers located between rendezvous point and receiver. Three different situations have to be considered: ■ ■ ■

Sender is active

No entry exists for group G. Entry for group G exists with unspecified source. Entry for group G exists with specific source S.

If no multicast entry for group G exists yet in the router and a join data unit is received, the following wildcard route entry is produced for the group: (*, G). The wildcard stands for any source. Furthermore, the router invokes the hash function specified in [158] to determine a rendezvous point. It then triggers a join data unit toward the rendezvous point. If the group is already known in the router through an entry in the form (*, G), then the shared tree is used for data delivery. No join data unit is triggered toward the rendezvous point. Identification is made through a wildcard entry in the place of the sender. If a special tree exists for sender S, this fact is noted in the router through the entry (S, G), and no join data unit is triggered toward the rendezvous point. Data are forwarded on the special tree. A multicast routing entry is not deleted as long as group members are available and the router is required for routing data units to receivers in other subnetworks; that is, dependent routers exist. An example of this is shown in Figure 3.26, in which two members are operating as receivers for group G. Each one is located behind different routers, R1 and R3. Member 1 leaves the group. Router R1 sends a pruning data unit to router R2 since it is no longer responsible for any group members. Router R2, however, is not allowed to forward the pruning since a dependent router, R3, exists. Router R3 still has to serve an active group member. When a sender starts transmitting data to a group, its designated router (PIM router 3 in the example in Figure 3.24) forwards the data encapsulated in a unicast register data unit to the rendezvous point. There the data is decapsulated and routed as multicast data along the shared tree with the rendezvous point as root. The designated router of a sender encapsulates the data until it receives a register stop data unit from the rendezvous point where the registration took place. This

3.5 Multicast Routing on the Internet

111

Sender

R2 Pruning

R1

R3

Member 1

Member 2

Dependent router

Terminates membership

Figure 3.26 Pruning with dependent routers.

is how the path of the shared tree is established between sender and rendezvous point. First a shared tree incorporating the rendezvous point is used for all senders S in group G (see Figure 3.25). If a specific tree is to be established for a sender, the rendezvous point generates a special multicast routing entry (S, G) for this sender. Only the rendezvous point or routers with local group members can initiate the transition from the shared tree to the specific tree. For example, PIM router 2 in Figure 3.27 can initiate this transition. The new path from sender to receivers can include PIM router 2 without any involvement of the rendezvous point. Therefore, PIM router 2 periodically has to transmit join data units to the sender. Once it has received data from the sender, it locally sets a bit to indicate that from now on it is transmitting on a dedicated tree for this sender. It sends a pruning data unit to the rendezvous point, which then generates an entry in the form (S, G) and sets appropriate bits indicating that the rendezvous point is part of the shared tree but not of the specific tree.

Sender-specific tree

Transition to specific tree

112

Chapter 3 — Multicast Routing

Sender S

PIM router 3 delete

PIM router 2

Rendezvous

PIM router 1

Receiver

PIM join (sender S) Pruning data unit Data

Figure 3.27 Specific tree for sender S.

Bootstrap routers

A routing entry (S, G) is also generated in the routers of the specific tree. This entry is deleted if no data is transmitted over this router during a certain time interval T. Thus the concept of soft state is applied. Since PIM-sparse mode is fundamentally based on a periodic transmission of data units, no mechanisms for acknowledgment are incorporated into the protocols. This simplifies protocol design with respect to control handling. However, it can lead to a high amount of control traffic in a network, especially if large networks are involved. A reference to bootstrap routers that exist in PIM domains already appeared in Figure 3.23. Their task is to send dedicated bootstrap data units that distribute information about rendezvous points within a domain. The dedicated bootstrap data units are routed on a link-to-link basis through the domain. These data units are also used if a new bootstrap router has to be determined dynamically. Within a domain, a small number of routers are configured as candidates for bootstrap routers and as candidates for rendezvous points. Typically, these are the same routers. One of the candidates is selected as a bootstrap router. The candidates for rendezvous points

3.5 Multicast Routing on the Internet

113

periodically contact the bootstrap router per unicast. Through the bootstrap data unit, the bootstrap router identifies the active rendezvous points in the domain. The routers evaluate this information so that, if necessary, a suitable rendezvous point for a group can be established.

PIM-Dense Mode PIM-dense mode for multicast communication of groups whose members are not widely distributed is currently described in an Internet draft document [50]. The assumptions made differ from those of PIM-sparse mode and are comparable to those of DVMRP. PIM-dense mode assumes that at startup, group members in all subnetworks wish to receive data. Therefore, it uses flooding and pruning. As with DVMRP, dedicated graft data units are sent to support an immediate integration of new group members into the multicast tree. PIM-dense mode differs from DVMRP and MOSPF in the sense that it operates independently of the procedures used for exploring the network topology. The advantage is in the minimal complexity of the protocol. A disadvantage is that it can increase traffic in the network. Due to flooding, data can end up being sent unnecessarily to network areas in which no group members are located. However, this is considered acceptable because it is assumed that the density of a group will be very high and consequently the additional overhead will be low. This mode differs from PIM-sparse mode mainly in the mechanisms that are not used: ■ ■

No use of periodically transmitted join data units No rendezvous points

Periodic join data units can be eliminated in PIM-dense mode. Pruning or graft data units are used explicitly to reduce or to enlarge the multicast tree. Routers that operate in PIM-dense mode periodically send Hello data units in order to become acquainted with their neighbors in the network. A multicast tree is established as soon as a sender actively starts sending data. Multicast routing entries of the type (S, G) are then generated in the involved routers, with S representing the sender and G the group. These entries are associated with several timers that trigger

Flooding and pruning graft data units

114

Chapter 3 — Multicast Routing the deletion of the entry upon timeout. Rendezvous points are not used. In summary, PIM-sparse mode and PIM-dense mode are two inherently different multicast routing protocols. They operate efficiently for sparse or dense groups, respectively. PIM-dense mode is therefore envisaged for use within domains, whereas PIM-sparse can deal with larger networks. Interoperation of PIM-sparse mode with dense mode protocols, such as PIM-dense mode or DVMRP, requires proper PIM multicast border routers. All data units within a PIM domain need to be pulled to the PIM multicast border routers [158]. The routers broadcast these data units using DVMRP, for example. Therefore, a PIM multicast border router implements both protocols and further needs some interoperability functions. Externally originated data units must also be forwarded into the PIM domain. The PIM multicast border router encapsulates such data units in register data units and forwards them per unicast to the corresponding rendezvous point.

Hierarchical PIM (HPIM)

New member

The selection of the rendezvous point is important for the quality of multicast trees in PIM-sparse mode. Hierarchical PIM precisely addresses this problem [74, 116]. The main idea consists of organizing candidates for rendezvous points into a hierarchy. Therefore, each candidate is additionally assigned an identification of its level in the hierarchy (see Figure 3.28). In HPIM, groups are joined as follows: As soon as the designated router (DR) is informed about a new group membership, it sends a join data unit to a selected rendezvous point of level 1. Designated routers are understood to be at level 0. The rendezvous point from the higher level acknowledges the join data unit and issues a join data unit to the next higher level. This process is repeated until the highest level allowed for a group has been reached. If a sender from group G starts to send, the designated router receives the data. If no member of G is known locally yet, it forwards the data unit encapsulated in a register data unit to a rendezvous point of the next level. The designated router receives an acknowledgment of this data unit. If this acknowledgment is not received within a certain interval, the designated router retransmits the data. The rendezvous points decapsulate the register data unit and check whether they already have an entry for group G. If this is the case, they do not forward the data unit. If not, the data is encapsulated again and forwarded to

3.5 Multicast Routing on the Internet

PIM router

Level 2

PIM router

Level 1

Level 0

DR

PIM router

PIM router

DR

115

PIM router

DR

DR

DR: Designated router Figure 3.28 Hierarchy of rendezvous points.

the next higher level. The level of the sending rendezvous point is always included in the register data unit to avoid loops. Because of the hierarchy of rendezvous points it can happen that register data units pass the same link multiple times (see Figure 3.29) [74]. Since the register data units are encapsulated, only the next router can be identified. This inefficiency can be avoided for data sent subsequently if the data is routed to the rendezvous point of the highest level involved. The designated router shown in the example in Figure 3.29 is aware of this rendezvous point. The multicast status information created through the register data units remains available in all rendezvous points that the data unit passes (e.g., rendezvous point RP1). It is not deleted explicitly but instead implicitly after the associated timer has expired. This soft-state concept simplifies implementation. A forwarding of register and join data units can result in loops, as illustrated in the example in Figure 3.30 [74]. The router forwards the register data unit to rendezvous point RP1 and from there it is relayed to rendezvous point RP2. To reach rendezvous point RP3, the data unit must again pass through the router. However, the latter already holds

Nonoptimal trees

116

Chapter 3 — Multicast Routing Path of registration data unit

RP4

DR

RP2 Data

RP3

RP1 Registration data unit

DR: Designated router RP: Rendezvous point Figure 3.29 Register data units and data path.

DR: Designated router RP: Rendezvous point

RP2

RP1

delete

DR

Router

RP3

Detects different levels of hierarchy Figure 3.30 Loops from register or join data units.

Avoid loops

Rendezvous point without a member

status information about G. According to this information, data for G is to be routed to RP1. The hierarchy level of the sending rendezvous point is analyzed so that these loops can be avoided. The router is able to recognize that the routing entry for the group has been established on a lower level of the hierarchy and therefore removes the entry. A routing entry pointing to rendezvous point RP3 is then generated. In this sense, rendezvous points of higher levels have higher priority. Due to the hierarchical structure of rendezvous points, a situation is also possible in which no group member is connected to a rendezvous point at a higher level. If this is the case, the data should not take a detour through this rendezvous point. The rendezvous points that

3.5 Multicast Routing on the Internet

117

RP3 Pruning data unit

Data

Router

RP2 Join data unit

RP1

RP: Rendezvous point Figure 3.31 Pruning of rendezvous points.

are not part of an optimal path issue pruning data units to prevent data from being routed through them. Rendezvous point RP2 in Figure 3.31 [74] shows an example of this. It issues a pruning data unit to the router and, consequently, is removed from the multicast tree. The development of HPIM originated with Mark Handley, Jon Crowcroft, and Ian Wakeman, who began their work in 1995. However, their work was neither completed nor published. HPIM is considered a historic protocol today. The development work with BGMP and MASC being carried out today appears to be more promising (see Section 3.5.5).

3.5.4 CBT Core-based trees (CBT) are based on the multicast concept of shared trees with rendezvous points, in this case called cores. CBT generates a shared bidirectional multicast tree that takes into account current group membership when it is being established. In contrast, the multicast tree generated by PIM is unidirectional; it only operates in the direction from the sender to the receivers. Scalability was a major objective in the design of CBT. The aim therefore was (1) to minimize the amount of status information and (2) to reduce the overhead generated in the network due to control data units. The status information can be reduced through the use of a shared multicast tree. The disadvantages this produces are traffic concentrations and nonoptimal paths. Compared to PIM, there is a clear

Bidirectional multicast tree

Goal is scalability

118

Chapter 3 — Multicast Routing reduction in the amount of control data sent since it is not sent on a periodic basic. Instead, control data units are explicitly acknowledged. This requires the appropriate functionality in the protocols, which in turn increases their complexity. Version 2 of the protocol specification for CBT is presented briefly [16, 17]. In certain cases it clearly differs from version 1 [19] and also is not backward compatible with this version. Since CBT was not yet widely used on the Internet when version 2 was introduced, this does not create a problem. However, new improvements have again been introduced in a new Internet draft [18], and these have resulted in a CBT version 3. This version is likewise not backward compatible with its predecessor, version 2. It is also not foreseeable whether version 3 will remain stable. What has been noticed, however, is that not even CBT version 2 has had any success yet on the Internet. It is questionable whether it will be able to compete against PIM-sparse mode. The major differences between version 1 and version 2 of CBT are the following: ■ ■ ■

New members

Multicast routing entry

Simplification of data formats Use of Hello mechanism Restriction to one rendezvous point (core)

The simplification of the format comprises the definition of a common header for control data units. This simplifies the processing in the routers. The Hello mechanism is used to select the designated router and the designated boundary router. In CBT a single core is made available for each multicast group. This core clearly reduces the amount of administration required per group. CBT therefore operates in a similar way as PIM-sparse mode. CBT also uses IGMP for the integration of new group members. This enables the designated router to obtain information about a new member. If a member of the corresponding group is not yet known to it, it issues a unicast join data unit to the core. In contrast with PIM, this join data unit must be explicitly acknowledged. The acknowledgment is either issued by the core router itself or by a router that is located on the path between designated router and core router and is already a member of the group. The transmission of the join data unit to the core router triggers the generation of a transient multicast routing entry in each router on the path. The router stores the group and the associated incoming and outgoing interfaces. A timer is also started for each entry. If the timer

3.5 Multicast Routing on the Internet

119

expires before an acknowledgment is received, the entry is deleted. The acknowledgment is transmitted in the opposite direction of the join data unit. If an acknowledgment is received, the transient multicast entry in the router is converted into a valid (permanent) entry. Note that bidirectional data flow is supported, which means no further distinction is made between incoming and outgoing interfaces. CBT has to provide suitable mechanisms for establishing the rendezvous point. It currently supports two variants: ■ ■

Bootstrap mechanism Manual configuration

The bootstrap mechanism operates the same way as the mechanism used by PIM. Candidates for core routers, called candidate rendezvous points in PIM, need to be configured. The candidates periodically inform the bootstrap router about their existence. The bootstrap router in turn periodically signals a list with candidates to all routers in the domain. Based on this list, the designated router is able to identify the core router responsible for a group. Network administrators carry out the manual configuration of a core router. The new features of version 3 include source-specific join and prune data units that are only generated by CBT boundary routers. Related to the pair (S, G) with sender S and group G, these sourcespecific data units are not forwarded toward the rendezvous point of S. Various granularities are supported for the prune data units: (*, G), (*, core), (S, G). Yet the latter two granularities are only relevant for routers located between the boundary router and the rendezvous point (core). Quit data units to preceding routers have been expanded so that they can be used to refine forwarding information in a router. Overall, the new features increase the efficiency and flexibility for dealing with multicast trees.

Version 3

3.5.5 Multicast Routing between Domains The IETF working group Multicast Source Discovery Protocol (MSDP) has the task of developing a short-term solution that enables domains with different multicast protocols to be linked together without the need for a tree shared by the domains. In [63] a proposal for MSDP is described for interconnecting multiple PIM-sparse mode domains. The PIM-sparse mode domain operates with its own

MSDP

120

Chapter 3 — Multicast Routing

BGMP

rendezvous points only. A rendezvous point of a domain has a MSDP peering relationship with a rendezvous point of a different domain. This is implemented with a TCP connection. Across the TCP connection control data are exchanged between the MSDP peers. If the rendezvous point within a PIM-sparse mode domain receives a PIM register data unit, it will construct a source active data unit and send it to its peers. This data unit contains the source address, of the data source, the group address and the IP address of the rendezvous point. MSDP receives and forwards source active data units. Forwarding is done away from the originating rendezvous point. An MSDP peer can be configured automatically or manually. For automatic configuration, PIM query and Hello data units can be used, for example. The Border Gateway Multicast Protocol (BGMP) reflects the development of a new framework within the IETF [149]. The protocol BGMP is regarded as a long-term solution compared to MSDP, which should provide a short-term solution. The necessity for a long-term solution for interdomain routing stems from the fact that all protocols presented so far (DVMRP, MOSPF, PIM, CBT) have problems with routing between domains. The main problem is data flooding. DVMRP and PIM-dense mode periodically flood data; MOSPF floods information about group affiliation, and CBT and PIM-sparse mode flood information for the configuration of rendezvous points. The extensions such as HDVMRP and HPIM can be viewed as solutions for expanding to larger networks. However, they do not offer alternatives to multicast routing between domains on the global Internet [95]. Like BGP, BGMP also operates on top of TCP. The following basic concepts of BGMP can be noted: ■ ■ ■

BGMP constructs a shared bidirectional tree. BGMP is interoperable with other multicast routing protocols. BGMP selects a root domain depending on the prefix of the multicast address.

BGMP is based on concepts of the protocols CBT and PIM-sparse mode. The main reason is that these two protocols provide rendezvous points, thereby avoiding a networkwide flooding of data units. Flooding is acceptable within domains but not for interconnecting a large number of domains. With BGMP, group members must actively join the shared tree if they want to receive data for the group. Systems that have not joined group G cannot receive any of the data destined for G. Note that with

3.5 Multicast Routing on the Internet

Multicast domain BGMP router BGMP router

BGMP routing

Multicast domain BGMP router Multicast domain

BGMP router

BGMP router Multicast domain

Figure 3.32 BGMP for interconnection of multicast domains.

BGMP, the root involves a complete domain (see Figure 3.32) and not an individual router, as is the case with CBT and PIM-sparse mode. If a new receiver joins a group, the boundary router sends a groupspecific BGMP join data unit. This data unit is then routed from boundary router to boundary router toward the root. BGMP join and prune data units are transmitted over TCP connections. The same applies to periodic keep-alive data units sent to update protocol status information. In BGMP the root domain is selected on the basis of the multicast address. An attempt is made to select a good root, although no claim is made about the optimality of the resulting shared tree. BGMP is based on the assumption that different ranges of IP multicast addresses are associated with different domains. This can, for example, be ensured through the multicast address set claim protocol (MASC) [61]. The domain that is assigned the group address in its multicast allocation automatically becomes the root domain. Since the initiator of a group typically is allocated a multicast address within a domain, this is considered a favorable selection process for the root of the multicast tree.

121

This Page Intentionally Left Blank

4 Quality of Service

M

ultimedia applications require a guaranteed availability of resources (e.g., data rate, processing power) in order to offer a high quality of service to users. For example, an audio stream without silence suppression continuously consumes a certain data rate (e.g., 64 kbit/s). If this data rate cannot be provided, data units have to be dropped. This can easily lead to a noticeable reduction in voice quality. The MBone tools (see Chapter 7) currently being used on the Internet often experience a reduction in quality of service because of the lack of explicit reservations of any resources for applications. Currently efforts are being made toward applications that can adapt their quality dependent on actual network characteristics. An example of a parameter that can be adapted is the data rate. This is especially needed for wireless attached systems because of varying link quality and potential mobility. Nevertheless, it is assumed that a certain level of quality of service needs to be provided over a period in time in order to leave user perception at an acceptable level. The Internet currently only offers a best-effort service. In other networks, such as ISDN, resources are explicitly allocated to individual data streams. In ISDN, for example, a data rate of 64 kbit/s of a B channel is continuously provided to the user. An audio stream can use this service during an entire communication. Thus any data loss and, consequently, reduced voice quality are avoided. Clearly, this can lead to bad resource utilization if the provided link is not actively used. However, it provides guaranteed services. This chapter investigates quality-of-service support for multicast communication on the Internet. Chapter 5 discusses quality-of-service support for group communication in ATM networks. Due to the somewhat negative experience with the current conferencing applications on the Internet, protocols and quality-of-service models have been developed for multimedia applications. Some of the protocols are capable of directly supporting multicast communication. Basically there are two approaches—Integrated Services

124

Chapter 4 — Quality of Service (IntServ) and Differentiated Services (DiffServ)—on the Internet. Both approaches are introduced below with the corresponding quality-ofservice models and the required signaling.

4.1 Integrated Services The philosophy behind Integrated Services is to provide dedicated resources to individual data streams and therefore offer a guaranteed service to those data streams. As a consequence, status information, including information about the resource requirements of each individual data stream, has to be stored and evaluated in the intermediate systems (routers or switches) within the network. A basic advantage of the dedicated reservation mechanism is that resources are explicitly made available for a particular application [134]. However, intermediate systems must incorporate additional functions, such as admission control of resources to individual data streams. This increases the complexity of the implementation of these systems. Integrated Services are defined in the following documents of the IETF: [30, 70, 139, 140, 164, 163]. They employ signaling protocols for the propagation of resource requests. Two different approaches can be distinguished: ■ ■

What triggers resource reservation?

Receiver-oriented resource requests Sender-oriented resource requests

The key difference between these two approaches is in the party that initiates the resource reservation. In the first case it is the receiver; in the second, the sender issues the resource request. In a receiveroriented case, the resource requests directly reflect the receiver requirements. Signaling protocols have been introduced on the Internet for both approaches and will be described later in this chapter. The protocols are ■

■

RSVP: Resource ReSerVation Protocol [31, 169] for receiver-oriented reservations. ST2: Stream Protocol Version 2 [151] for sender-oriented reservations. ST2+ [56] is a variation of ST2, with the same basic features [55].

4.1 Integrated Services

125

The quality-of-service model and the different service categories offered by Integrated Services will be discussed in some detail. This will be followed by an introduction to the corresponding protocols.

4.1.1 Classes of Service Provided by Integrated Services Three different categories of service are offered by the Integrated Services for the support of quality of service: ■ ■ ■

Best effort Controlled-load services [163] Guaranteed services [70]

Best Effort The best-effort service class offers an unreliable service familiar from the protocols IP and UDP on the Internet. No special mechanisms are required in order to provide this kind of service. However, although a best-effort service is not suitable for the support of multimedia communication, it is often used because of the unavailability of more advanced services. Best-effort service works well in lightly loaded networks since no competing traffic is available. Experiences on the current Internet, nevertheless, demonstrate pretty clearly that best effort is not sufficient. The implementation of multicast data transfer as best effort is simple because no guarantees are given at all. Data is merely routed along a multicast tree in the network, and if sufficient resources are not available, data units are simply dropped. Potential receivers therefore experience varying degrees of service quality depending on the current network load. In contrast to point-to-point communication, the routing has to provide a multicast tree through which data is forwarded to the receivers.

Controlled-Load Services Controlled-load services are envisaged for the support of applications that are sensitive to network congestion [163], such as adaptive realtime applications. These applications perform well as long as the network load is not heavy. However, their service quality suffers noticeably if the network is congested. Some applications for audio and video transmission used on the MBone represent typical examples (see Chapter 7).

Unreliable service

126

Chapter 4 — Quality of Service

Same service as in a low-traffic network

Controlled-load services can be described as offering a service comparable to those provided by a lightly loaded network with besteffort service. A lightly loaded network in this sense is one in which queues do not build up within the intermediate systems of the network. Data can therefore flow easily through the intermediate systems. It is not delayed considerably within the intermediate systems nor subjected to any serious delay jitter. The actual transmission time therefore only slightly exceeds the minimum transmission time. As a result, it can be assumed that a high percentage of the transmitted data will reach the receiver correctly—thus within the available time budget. Because of the short queues, no significant delay jitter occurs. For applications such as interactive audio and video communication, it is important that data is received continuously with minimal delays. However, a controlled-load service requires that only a small amount of the network capacity will be using the service, and an overloading of the network can therefore be avoided. An admission control mechanism is required to prevent a situation in which too many applications are given permission to use a controlled-load service at the same time. The admission control checks whether a sufficient quantity of the required resources is available. Typical resources include bandwidth, storage capacity in intermediate systems, and processing capacity for the routing of data units and its associated functionality. What is also assumed with controlled-load services is that data units will not need to be dropped because of congestion in a network. A key reason is the short length of the queues when no congestion exists. Data units are dropped if the length of queues increases substantially and, as a result, sufficient resources are not available for buffering the data. Admission control prevents this situation with controlled-load services. To make use of a controlled-load service, an application must describe its traffic accordingly. The description of this traffic is implemented through a traffic specification (Tspec). The traffic specification contains the parameters needed for characterizing the traffic. Traffic characterization is based on a token-bucket model (see Figure 4.1) that operates with the following two parameters [139]:

Admission control

Tspec for traffic specification Token-bucket model

■ ■

Token rate r Bucket depth b

The basic idea behind the token-bucket model is that the tokens in the bucket control when and how much data is allowed to be transmitted into a network. The token-bucket model enables the data rate or the

4.1 Integrated Services

127

Rate r, for producing tokens Bucket depth b

Time Data stream that consumes token Figure 4.1 Token-bucket model.

burst size to be regulated. Data units that are being sent consume a corresponding number of tokens from the bucket. If a sufficient number of tokens are not available, the data unit has to wait until the bucket provides enough tokens again. If no queue is provided in front of a bucket or if the queue is already full, then the data is discarded or it is marked and forwarded if enough resources are locally available. The bucket is filled according to a token rate r that is defined by the applications and is measured in units of byte/s. For Integrated Services, an acceptable range for the rate is between 1 byte/s and 40 terabyte/s. The high upper limit is designed in order to guarantee that there is enough flexibility to accommodate future increases in performance. The second token-bucket parameter, the bucket depth b, restricts the size of a bucket and consequently the maximum number of tokens available at any given time. With Integrated Services the bucket depth is measured in bytes, with a range of values between 1 byte and 250 gigabytes. In addition to the token-bucket parameters, the following parameters are also used to describe traffic in the case of Integrated Services: ■ ■ ■

Peak rate p for transmission measured in byte/s Maximum size of data units M in bytes Size of minimal policed data units m in bytes

The upper limit of the size of a data unit is limited by a maximum size M. The lower limit of the size of a data unit is not regulated. However,

Rate

Bucket depth

128

Chapter 4 — Quality of Service

Comparison of Tspecs

the size is limited to the minimum considered value m for processing by traffic control. Data units that are smaller are handled the same as those having size m; in other words, they consume the same amount of resources. The value m includes the overhead of IP and the higher layer protocols. Restricting the value to m allows a practical assessment to be made with respect to the resources required per data unit. The Tspec is based on the token-bucket parameters and the additional parameters p, M, and m listed above. It is up to the applications to disclose the Tspec to the communication system. For multicast communication, multicast trees are established on the network layer for the purposes of routing data to receivers (see Chapter 3). The different Tspecs of the receivers are processed at the branching points to the various receivers (see Figure 4.2). The Tspecs are defined based on the individual service requests. They are compared and merged in order to derive the reservations that are required from the branching point toward the sender. Such a comparison can also be important for traffic control. A number of rules exist for the comparison of Tspecs [163]. The following applies to the two Tspecs A and B when the conditions listed below are fulfilled: Tspec A ≥ Tspec B. Otherwise Tspec A ≥ Tspec B is not fulfilled. In this context, ≥ should be interpreted as follows: as good as or better than, or as large as or equal to. ■

■

Rate rA of Tspec A is greater than or equal to rate rB of Tspec B, rA ≥ rB . The bucket depth bA of Tspec A is greater than or equal to that of Tspec B, bA ≥ bB. Receiver 1 (Tspec A)

Data

Sender (Tspec S)

Branching point

Figure 4.2 Receivers with different Tspecs.

Receiver 2 (Tspec B)

4.1 Integrated Services ■ ■

■

129

The peak rate pA of Tspec A is greater than that of Tspec B, pA ≥ pB. The minimum considered size of data units mA of Tspec A is less than or equal to that of Tspec B, mA ≤ mB. The maximum size of data units MA of Tspec A is greater than or equal to that of Tspec B, MA ≥ MB.

On the basis of these rules, however, a linear ordering of all Tspecs is not possible. Those cases in which the five points listed above are not all met cannot be ordered linearly. The standard documents do not specify how these cases should be dealt with. The implementation of these cases is a local matter. Suggestions for comparing or merging Tspecs using RSVP are presented in [31] and [164]. The Tspec is made available to the system. Based on this information, it can control whether applications are behaving in conformance with the specification. If not, penalizing mechanisms may be necessary. These mechanisms can, for example, depend on the class of service that is supported. There are no general rules that should be applied. Conformance testing of the traffic is based on certain observations of traffic being controlled by a token-bucket. Because of the tokenbucket, the amount of data transmitted in time interval T is not allowed to exceed the value W = rT + b, with r and b being the parameters of the token-bucket. W therefore corresponds to the maximum size of bucket b plus the maximum number of newly arriving tokens in time interval T. Data units that are not in compliance with this rule do not conform to the traffic specification. In this context, data units that are smaller than the minimum specified data size m are processed based on this size m. Data units that are larger than the maximum size M of the data units on the outbound link are likewise categorized as being nonconformant. If sufficient resources are available, data units that are categorized as being nonconformant are forwarded as besteffort data. This enables the data units to reach their destination even if they do not comply with the local token-bucket specification. If not enough resources are available locally, these data units are discarded.

Guaranteed Services What characterizes guaranteed services is that they provide a guarantee for maximum transmission delay as well as for data rate [70]. Neither is offered by controlled-load services. Because it is assumed that the network load will be light, controlled-load services are able to maintain these services with a rather high degree of probability.

Nonconformity penalized

130

Chapter 4 — Quality of Service

No reduction of delay jitter

Rspec

Admission control plays a major role in the context of guaranteed services. Interactive audio and video are typical applications that use guaranteed services. For these applications, an increased end-to-end delay caused by congestion in the network can result in data reaching a receiver too late and therefore having to be discarded. Real-time applications generally require guaranteed services with hard guarantees in terms of delay. Note, however, that guaranteed services provide no guarantee with respect to delay jitter, which means that delay jitter can be considerably high. As a way of compensating for the jitter, it may be necessary to buffer data in the receiving end system for a longer period of time so that a continuous playout of data can take place. This can increase the delay until playout and consequently has a considerable effect on interactive applications. It limits the actual suitability of guaranteed services for interactive real-time applications. As with controlled-load services, a Tspec based on the tokenbucket model is used as a basis for the traffic specification of guaranteed services. The parameters of the Tspec are the same as those for controlled-load services. In addition, an Rspec (reservation specification) is defined for guaranteed services. Two parameters are specified for the Rspec: ■ ■

Global availability not necessary

The desired rate R A slack term S

The desired rate R in an Rspec must be greater than or equal to the token rate r in the Tspec. A higher rate will result in a reduction of queues and, consequently, a reduction in delays. The slack S is not allowed to be a negative value. It is measured in microseconds. The slack defines the difference between the desired delay and the delay experienced through the use of the rate R. Based on the slack, network resources may be used more efficiently. The reserved resources can be reduced if necessary. There is no assumption in RFC 2212 [70] that guaranteed services are available throughout the global Internet. Instead it is assumed that the availability of these services in a number of intermediate systems can already considerably improve service quality. Clearly, no guarantees can be given in such cases. If guaranteed services are implemented, the intermediate systems are not allowed to segment the data units. The view is that data units that are too large do not conform to the traffic contract and therefore should be dealt with accordingly.

4.1 Integrated Services Guaranteed services rely on the involved end and intermediate systems behaving in accordance with the fluid model [113, 114], which enables the approximation of a continuous flow of data. The delay of a data flow regulated by a token-bucket is limited to r/R for a connection with a data rate R of the connection and a rate r of the token-bucket. This is based on the assumption that the rate of tokens flowing into the token-bucket can be regulated and that a continuous consumption of tokens exists. Systems that offer a guaranteed service must therefore ensure that this delay is maintained with a specific maximum error. The total delay cannot be greater than b/R + (C/R + D). C and D represent the error terms in the guaranteed services. The error terms indicate the locally acceptable maximum deviation of behavior from the fluid model. The factor C depends on the rate, whereas D is not rate-dependent and indicates the non-rate-dependent delay for each system. For example, with slot-based rings the maximum delay up to the transmission of a complete data unit can be given as D [70]. Both parameters C and D are additive on the path of a data unit through the network. This means that in terms of end-to-end communication, these values add up to the values Ctot and Dtot for the entire data path. The end-to-end delay is therefore not greater than b/R + (Ctot/R + Dtot). The partial values Csum and Dsum provide the partial sums experienced on the path so far. They can be used to dimension the buffer allocation in a system so that no data units are lost. The end-toend delay is therefore limited as follows: ■ ■

131

Error terms

(b − M)/R * (p − R)/(p − r) + (M + Ctot)/R + Dtot, if p > R ≥ r (M + Ctot)/R + Dtot, if r ≤ p ≤ R

To support the guaranteed services, a traffic control that compares the traffic generated in the network with the Tspec and, if necessary, regulates the traffic, is required on the edge of the network. A reshaping of the traffic is necessary within the network at all heterogeneous branching points (routers, switches). This happens, for example, in a multicast tree where it separates into branches with different degrees of quality of service (see Figure 4.3). Reshaping is then only necessary if the Tspec on the outbound link is lower than the current Tspec. The example in Figure 4.3 shows two different Tspecs on the two outbound links. Besides the rate, the Tspecs differ with respect to other parameters. The upper Tspec corresponds to the one for the inbound link, whereas the one below does not. A reshaping at the lower outbound link is therefore necessary in the intermediate system.

Reshaping

132

Chapter 4 — Quality of Service

Tspec (r = 10 Mbyte/s, b = 1000 bytes, p = 15 Mbyte/s, m = 100 bytes, M = 10 Kbyte)

Tspec (r = 10 Mbyte/s, b = 1000 bytes, p = 15 Mbyte/s, m = 100 bytes, M = 10 Kbyte) RS Branching point

RS: Reshaping

Tspec (r = 2 Mbyte/s, b = 100 bytes, p = 6 Mbyte/s, m = 100 bytes, M = 10 Kbyte)

Figure 4.3 Customizing traffic characteristics at branching points.

The outbound link also requires reshaping if different source streams meet at a node (see Figure 4.4). The parameters result from multiplexing of the involved data streams. The Tspec again is the basis for the merging. Tspecs can also be merged if, as explained previously, they cannot be ordered linearly. Signaling protocols, like the ones familiar from the digital telephone network, are needed to implement services such as controlledload services and guaranteed services on a network. Signaling protocols propagate the desired traffic specifications through the network. The Differentiated Services currently being discussed on the Internet offer an alternative that avoids signaling protocols and the complexity associated with them (see Section 4.2). Signaling protocols and traffic specifications are independent of each other to the extent that signaling protocols must be able to transport the necessary parameters. However, they do not have to interpret them. The signaling protocols RSVP and ST2 (described later), which are or were under discussion for the Internet, are examples of such protocols. RSVP, in particular, has been and continues to be the subject of intensive and controversial discussion in terms of its use on the Internet. It could also play a role in the future with the Differentiated Services discussed later. It should be pointed out that ST2 is not currently being considered for the Internet. Some aspects that have attracted criticism are the complexity of ST2, the incompatibility of its implementations, as well as the introduction of a new network layer protocol. The incompatibility problem is primarily due to the fact that

4.1 Integrated Services

133

Sender 1 (Tspec A)

RS Receiver (Tspec E)

RS: Reshaping

Merging point

Sender 2 (Tspec B) Figure 4.4 Reshaping at merging point.

a uniform service definition was not available at the time the ST2 definition was produced. ST2 can easily make use of the Integrated Services defined in the meantime and thereby at least eliminate the problem of interoperability. It is not possible at the time of the writing of this book to predict just what will ultimately be accepted on the Internet. The Differentiated Services introduced in Section 4.2 are currently enjoying a great deal of popularity. However, it is not yet certain whether they will be able to solve the problem of guaranteed services on the Internet. Consequently, we have listed several alternatives in this book, even though there are many in the field who do not think these alternatives have much chance of acceptance in the future.

4.1.2 Receiver-Oriented Reservations in RSVP The signaling protocol RSVP (Resource ReSerVation Protocol) [31, 160, 169] implements a receiver-oriented reservation concept. It is often referred to as a “resource reservation protocol.” However, since the protocol is restricted to signaling requests for quality of service and does not handle the reservations itself, it will be referred to as a “signaling protocol” in the following discussion. RSVP is not involved in the transfer of user data. This requires a separate protocol. The advantage of such a of construction is that for the transfer of user data, RSVP can be run on top of IP, which is used worldwide on the Internet. This

Signaling protocol

134

Chapter 4 — Quality of Service should have made it considerably easier to introduce RSVP on the Internet than ST2, which incorporates a different data transfer protocol than IP on the network layer. RSVP is suitable for unicast communication as well as for multicast communication. It uses the Integrated Services quality-of-service model.

Basic Concept Path data units

Reservation data unit

Soft state

Confirmation data unit

The basic concept is as follows. The sender of a multicast communication starts periodic transmission of path data units (PATH) to a multicast group. Status information based on these path data units is stored in the intermediate systems. This data provides information, for example, about the path back to the sender. The IP address of the preceding intermediate system is stored for this purpose. A receiver that decides to take part in a multicast communication signals this fact to the sender with another special data unit, the reservation data unit (RESV), after it joins the multicast group via IGMP and the multicast tree has been established by the respective routing protocol. The receiver can send a reservation data unit immediately upon receipt of a path data unit. In the reservation data unit, the receiver specifies the quality of service desired. This information is evaluated by the intermediate systems (IP routers or ATM switches) and routed to the sender. In some cases, the reservation requests of different receivers are merged into a single new reservation request that is sent in the direction of the sender. Reservation of all the required resources takes place in the intermediate systems. The receivers usually do not receive acknowledgments of their reservations. They also do not know whether a reservation has been made or has failed. This is due to the soft-state concept pursued by RSVP. It provides soft guarantees. By contrast, ISDN gives hard guarantees for reservations and therefore requires acknowledgments. The soft-state concept does not work with explicit acknowledgments. Instead, timers are allocated to the entries. If the timer expires, the entry (with RSVP, the reservation) is deleted. To prevent the deletion of entries, RSVP periodically transmits path and reservation data units. With RSVP it is also possible to request a dedicated acknowledgment through a confirmation data unit (CONF). But this confirmation only gives an indication that there is a high probability the reservation was established. Furthermore, a confirmation data unit only relates to a single transmission link and not to the entire path. It is therefore in no way comparable to the kind of acknowledgment provided by a

4.1 Integrated Services connection-oriented system such as ISDN and should not be interpreted as such. If a sender has received a reservation data unit, it knows that the required resources are available on the path in the network. It should be noted, however, that the sender typically would already have transmitted data before receipt of this data unit. There is no clear separation between the phases for reservation and data transfer. Both phases usually overlap with RSVP. The RSVP principle in no way demands that the sender in some way or other waits for a reservation. Instead the sender transmits data and if interested receivers exist, they will try to reserve the necessary resources on the path. On the other hand, no guarantees are provided for these reservations due to the soft-state concept that applies. In RSVP, therefore, the sender assumes no responsibility. It simply sends data to the network. The receivers have to decide whether reservations are required. Figure 4.5 illustrates the basic sequence for multicast communication using RSVP. It shows a receiver-oriented reservation along with the requests being merged in intermediate systems. It should be mentioned again that senders could forward user data to a network without reserving resources. The activities of the sender and the receiver should therefore be viewed separately.

Heterogeneous Multicast with RSVP The basic concept described above allows the support of a heterogeneous quality of service for multicast communication because no synchronization takes place between the different requests. Each receiver Receiver 1 Merging of reservations

PATH RSVP router RESV RESV

RSVP router

PATH

Sender Data

Receiver 2

Figure 4.5 RSVP reservation sequence.

135

136

Active networks

Chapter 4 — Quality of Service can therefore individually signal a request for resources. This means that members of a group can experience different quality of service. In this sense heterogeneous multicast communication is supported. It should, however, be taken into account that RSVP purely focuses on signaling. It is not its task to provide heterogeneous data streams. This requires other measures. An alternative solution is discussed in detail in the context of active networks. The aim of active networks is to offer additional or enhanced services in a network on a flexible basis. Service quality experienced by the user should be improved. There are different ways in which this aim can be transformed into reality. A brief description follows of an approach that transforms data streams in intermediate systems of a network per individual requests for quality of service [161]. Simpler approaches are, for example, based on dropping data units irrespective of content, according to the principle “If the queue is full, data is dropped; otherwise it is forwarded.” As a result, the quality of service experienced by different receivers can vary considerably. Another approach is called layered multicast. It is based on the idea that the transmission of, for example, video data is implemented using multiple layers. Each layer is associated with a multicast group. The receivers join only those groups that they wish to receive. As a result, the quality of service of the receiver group can be heterogeneous. However, with layered multicast no service guarantees are provided. Figure 4.6 illustrates a simple heterogeneous multicast scenario. Fred and Pebbles receive a video sent by Barney to the BarneyShow group. This video is coded in MPEG [129] by Barney and transmitted at a rate of 25 frames per second. However, since Fred is not at home and therefore does not have a high-performance connection to the network, he is only able to receive the video at a lower rate, namely, 5 frames per second. RSVP enables both Pebbles and Fred to signal their requests for service quality individually. The required resources are then reserved in the intermediate systems. The Dino router receives both Tspecs and merges them into a new Tspec that is then forwarded toward the sender. Two different versions of the video stream are now requested from the receivers, one for Fred at a rate of 5 frames/s and one for Pebbles at a rate of 25 frames/s. However, only a single request is forwarded to the sender. The original video stream consequently has to be adapted at Dino router. Figure 4.6 shows how this takes place in an intermediate system in the network, the Dino router. The Dino router forwards one data stream with 5 frames per second to Fred and one with 25 frames per second to Pebbles. Therefore, it actively

4.1 Integrated Services

MPEG (5 frames/s) MPEG (25 frames/s)

Transformation of the MPEG streams

Fred

Dino router

Group BarneyShow MPEG (25 frames/s)

Barney

137

Router MPEG (25 frames/s) Pebbles

Figure 4.6 Example of heterogeneous quality of service.

processes the data stream being forwarded and adapts it according to the quality-of-service requirements issued behind it. This conversion of the data stream is not part of RSVP because RSVP is not involved in user data transfer. RSVP is only capable of signaling the necessity for a conversion.

RSVP and Routing With RSVP, resources are reserved on the path specified by the currently routing protocol used. Since IP operates as a connectionless protocol and is used for the transfer of user data in RSVP, route changes can occur during an established communication relationship. They are not addressed explicitly by RSVP, but are not a problem either since RSVP implements soft states. This implicitly solves the problem. RSVP uses a timer-based mechanism that deletes status information after a defined time interval has expired. This allows the use of different routes, although an update delay is involved. In this sense RSVP adapts automatically to routing changes. The periodically transmitted data units automatically follow the new path through the network. The reservation data units that are also being transmitted periodically follow the same path from receiver to sender as the data units. Furthermore, it has to be considered that fewer resources may be available than previously due to routing changes. Consequently, the service quality experienced by users may change due to the soft states used.

Route changes

138

Chapter 4 — Quality of Service Thus, no hard guarantees can be provided. Solutions that deal with the problem of varying quality of service are the subject of current research. This topic is discussed frequently in connection with mobile communication because of the geographical mobility of systems. Consolidated results or procedures are not yet available. Among other things, a need exists for QoS routing methods that can work in close conjunction with the signaling protocol.

RSVP Systems

RSVP daemon

Routing agent

The structure of an RSVP-capable intermediate system is shown in Figure 4.7. The separation between user data transfer and signaling is clearly depicted. The components arranged in the lower part of the figure are involved in the transfer of user data. The components at the top are associated with establishing reservations, and thus with control flow. The RSVP daemon, which is at the heart of an RSVP implementation, is only involved in control flow. It must access a database with entries on traffic control to combine reservation requests of different receivers. In addition, a routing agent participates in the current routing selection. The information is provided in the routing database.

Signaling and control applications

RSVP daemon

Routing agent

Management agent

Admission control Routing database

User data stream

Classifier Input driver

Internet forwarding

Figure 4.7 Structure of an RSVP-capable intermediate system.

Traffic control database

Scheduler

Output driver

4.1 Integrated Services Admission control checks whether new requests for resources can be accommodated. If it is possible, the necessary resources are reserved. The standard does not specify which mechanism is used for the reservation. This is a local implementation decision in the intermediate systems. If the required reservations cannot be accomplished, the reservation is aborted. There is no reliable mechanism for informing the receiver accordingly. The RSVP daemon is not incorporated in the transfer of user data. Instead, modules that regulate the actual traffic are involved in user data transfer. These modules include classifiers and schedulers. A received data unit is first forwarded to a classifier. It decides which queue the data unit should be assigned to. This decision is made according to the quality of service requested by the data unit or by the data stream. The scheduler then takes responsibility for forwarding the data unit to the selected outbound link. The RSVP standard does not include a specification for scheduling mechanisms. A variety of suggested scheduling mechanisms exist, such as Class-Based Queuing (CBQ) and Weighted First Queuing (WFQ) [40, 67]. However, RSVP requires that RSVP-specific components be implemented not only in the intermediate systems (i.e., routers and switches) but also in the end systems. These too must incorporate an RSVP daemon. Figure 4.8 presents a scenario involving RSVP-capable end and intermediate systems. It shows RSVP operating over a multicast tree in which RSVP-capable intermediate systems are arranged. Some users view the necessity of changing end systems for RSVP as a problem. It should be noted, however, that RSVP is supplied with Windows 98 and is therefore potentially available in a large number of end systems. Various implementations of the RSVP daemon exist on Unix platforms. Some of them are freely accessible by the public (public domain). A number of vendors, including CISCO and NEC, offer RSVPbased solutions but are not yet integrating them into their products. CISCO has an RSVP implementation in IP routers. NEC is currently experimenting with an RSVP implementation in ATM switches [1]. At this point it should be stressed that RSVP is not yet being used on the Internet. The use of RSVP is concentrated instead purely in the research area. There are two basic reasons for this: First, general difficulties exist with the introduction of new protocols into the basic infrastructure of the Internet. Second, a certain reluctance is being observed primarily because of the scalability problems of RSVP. One of

139 Admission control

Classifiers and schedulers

RSVP in end systems

140

Chapter 4 — Quality of Service Receiver

RSVP daemon

Sender

Application Routing

Control RSVP interworking unit

Application Routing

Classifier Data

RSVP daemon

Scheduler

Routing

Classifier

Classifier

RSVP daemon

Scheduler

Scheduler

... Data

Figure 4.8 Structure of an RSVP-capable network.

the primary problems is the management and storage in the intermediate system of the possibly large amount of status information that is accumulated. The periodic signaling is generally viewed as a less critical factor.

RSVP Reservations RSVP communication relationships between senders and receivers are called sessions. Reservations can be requested for sessions. RSVP clearly distinguishes between establishing a reservation and using a reservation. This aspect distinguishes RSVP from many other reservation protocols. RSVP provides two different types of specifications: ■ ■

FlowSpec

FlowSpec FilterSpec

A FlowSpec is responsible for the quality-of-service parameters (Rspec, reservation specification) and the description of the traffic characteristics (Tspec, traffic specification). The parameters of Tspec

4.1 Integrated Services

141

Table 4.1 RSVP filter types. Reservations

Sender selection

Explicit Wildcard

Dedicated

Shared

Fixed filters

Shared filters

—

Wildcard filters

and Rspec correspond to those defined for the Integrated Services. A FlowSpec is always associated with a single data stream. The FilterSpec is different. It describes how reservations are distributed to data streams and users. The relationships between the individual data streams of a session also have an effect on this distribution. A distinction is made between the following reservation styles: ■ ■ ■

FilterSpec

Fixed filters Shared filters Wildcard filters

Only filters of the same type can be used within a session. Different types of filters cannot be merged in RSVP-capable intermediate systems. The different reservation styles supported by the FilterSpec reflect whether reservations are explicitly allocated to senders or not. Furthermore, a distinction is made in terms of which senders are allowed to make use of the reservations. Table 4.1 summarizes the defined types of filters. Fixed filters are explicitly allocated; shared filters and wildcard filters are used on a shared basis, while a wildcard filter has no further use restrictions imposed on it. In the case of fixed filters, a reservation is allocated to only a single data stream of a sender. The sender is explicitly selected. Figure 4.9 presents an example of fixed filters. The senders are organized on the left-hand side of the RSVP intermediate system; the receivers on the right. Three different requests for resources arrive at two interfaces of the RSVP intermediate system; each one is requesting a fixed filter. The requests are simplified, with B representing the basic unit for the FlowSpec and the numbers preceding B determining the size of the FlowSpec in terms of B. Basic unit B reflects, so to speak, a simplified ordering criterion. The interfaces are always indicated as inbound (I1 and I2) or outbound (O1 and O2). The meaning of inbound and outbound in this context relates to the flow of user data, which follows the opposite direction of the filter requests shown in the figure.

Fixed filters

142

Chapter 4 — Quality of Service RSVP interworking unit

Toward S1 , S2

Toward S3

FF(S1{4B},S2{3B})

FF(S3{5B})

I1

S1{4B} S2{3B} O1 S3{5B}

S1{3B} I2 S2{2B} O2 S3{4B}

FF(S1{2B},S2{3B}) FF(S1{4B},S3{5B})

FF(S1{3B},S2{2B},S3{4B})

FF: Fixed filter Si: Sender i

Figure 4.9 Example of fixed filters.

Shared filters

Two receivers request fixed filters at outbound link O1. A fixed filter is also requested at outbound link O2. The reservations in the RSVP router are dealt with as follows: If reservations are requested at different outbound links for the same sender, then separate reservations must be provided for each outbound link. If there is more than one request at an outbound link, then the maximum number of requests must be made available. Take sender S1 as an example. Requests for 4B as well as for 2B exist for the sender at outbound link O1, which means 4B must be reserved in the router for the specific outbound link O1. At outbound link O2 there is a request of 3B for sender S1. This also has to be provided there. Multiple senders can jointly use reservations that result from shared filters. These are specially selected senders of a group. The particular advantage of this variation of reservation style is that it can avoid over-reservations that potentially exceed the resources available. Examples of this are scenarios in which the different senders of a group communication are not active at the same time. In most cases this assumption applies to audio channels for videoconferences. There is usually only one speaker, although the speaker can change during the videoconference. With shared filters, the resources in a network are only reserved once for a single speaker but are used alternately by various senders. This means that no over-reservations occur based on separate resource reservations for each sender. To benefit from the use of shared filters, the different senders must share at least a part of the multicast tree. This is not necessarily the case. It strongly

4.1 Integrated Services depends on the technique used for multicasting and on the geographical distribution of the individual group members. An example of resource reservation using shared filters is illustrated in Figure 4.10. Two shared filters are signaled at outbound link O1, each of them for data streams originating at two different sources. Outbound link O2 has only a single shared filter for streams originating at three different sources (S1, S2, S3). In terms of the FlowSpec, the maximum values need to be selected for the reservations. This results in the reservation of 5B for senders S1, S2, S3 at outbound link O1. For the same group of senders, 4B is provided at outbound link O2. On inbound link I1 a shared filter with the FlowSpec 5B is signaled to senders S1 and S2. A shared filter with a resource request of 5B is requested for sender S3 at inbound link I2. Wildcard filters are the third variation of reservation styles with RSVP. Like shared filters, wildcard filters are also based on shared reservations made by different senders. In this case, however, the senders are not distinguished any further; that is, all active senders in a group can use such a reservation. With respect to forwarding the reservation to the next RSVP-capable node, no distinction is made between the involved systems. Instead, the maximum of the reservations is selected and signaled toward the sender. An example is shown in Figure 4.11. The fact that a wildcard filter is being used is indicated through the use of a wildcard * opposed to the specification of a dedicated sender or a group of senders. As before, the reservations are made separately for each outbound link. However, the same requests are forwarded to the sender (for example, to I2). RSVP interworking unit SF((S1,S2){5B}) Toward S1 , S2

I1

SF(S3{5B}) Toward S3

S1,S2,S3{5B} O1

S1,S2,S3{4B} I2

SF((S1,S2){2B}) SF((S1,S3){5B})

SF((S1,S2,S3){4B})

O2

SF: Shared filter Si: Sender i Figure 4.10 Example of shared filters.

143

Wildcard filters

144

Chapter 4 — Quality of Service RSVP interworking unit WF(*{5B}) WF(*{3B})

WF(*{5B}) Toward S1 , S2

I1 *{5B} O1

WF(*{2B})

WF(*{5B}) Toward S3

I2 *{5B} O2

WF:Wildcard filter Si: Sender i Figure 4.11 Example of wildcard filters.

Merging Reservations Merging

The discussion about different filters illustrates that the merging of different requests for reservations in a multicast tree is an important aspect of RSVP. The merging of Tspecs for the controlled-load services and guaranteed services described earlier is defined in the respective standards documents. A number of rules have been defined for merging Tspecs for controlled-load services [31, 164]. The merged Tspec is used as a new Tspec at the merged node and forwarded to the sender in a reservation data unit. The resulting Tspec can be calculated according to the following rules that determine the individual parameters: ■ ■ ■ ■ ■

The largest token-bucket rate r The largest bucket depth b The largest peak rate p The smallest minimum packet size m The smallest maximum packet size M

In the case of shared filters, the sum of the Tspecs is calculated for the merging of the Tspecs. It is calculated according to the following rules: ■ ■

The sum across all rates r The sum across all bucket depths b

4.1 Integrated Services ■ ■ ■

145

The sum across all peak rates p The minimum across all minimum packet sizes m The maximum across all maximum packet sizes M

Tspecs and Rspecs may also have to be merged for guaranteed services. Tspecs are merged the same way as controlled-load services. Rspecs are merged in a similar way as Tspecs. Multiple Rspecs are merged with the following selection of parameters: ■ ■

The highest rate R The smallest slack S

RSVP Data Units RSVP essentially makes a distinction between two basic types of data units: ■ ■

Reservation data units (RESV) Path data units (PATH)

As explained earlier, both types of data units are used to establish reservations. Other versions of data units are also available for reporting errors and for immediate termination of reservations. RSVP data units consist of a common header and a number of variable-length RSVP objects. The common header contains the necessary information for routing and processing data units in the network. Information about reservations and other issues (e.g., Tspec) is transported in the RSVP objects. The use of these objects guarantees that RSVP data units can easily be extended for new services. The common header for RSVP data units is shown in Figure 4.12. The protocol version is signaled in the version field (4 bits). An additional 4 bits are reserved for flags, which have not yet been specified. The RSVP data unit type is coded in the type field (8 bits). This is followed by a 16-bit checksum. The field Send-TTL (8 bits) determines the maximum TTL (time-to-live) for a transmitted data unit. This field is used to detect non-RSVP-capable systems on a path. The detection is carried out through a comparison of the IP-TTL field of the received data unit with the Send-TTL field of the transmitted data unit. If the values differ, the data unit has passed through a non-RSVP-capable intermediate system. However, this kind of comparison is not always sufficient. For example, problems can occur in IP tunneling with non-

Common header

146

Chapter 4 — Quality of Service 32 bits

Version

Flag

Send TTL

Type

Checksum

Reserved

Length

Figure 4.12 Common header of RSVP data units.

RSVP-capable systems. In this case, additional information is required from the routing protocols. If a non-RSVP-capable system is detected, it can no longer be assumed that the reservations were carried out on the entire communications path. Therefore, it has to be accepted that a poorer quality of service may be available than requested. The 8 bits following the Send-TTL field are currently reserved, meaning that they have no significance. Finally, the common header contains a length field that carries the length of the RSVP data unit, including the variable-length RSVP objects measured in bytes. Figure 4.13 shows the format of the variable-length objects carried in an RSVP data unit. Each object is preceded by a header that contains details about the length of the object (16 bits), the class number (8 bits), and the class type (8 bits). This is followed by the content of the object. The overall length of objects is oriented toward 32-bit boundaries. The class number provides information (such as session, timer values, FlowSpec, FilterSpec, sender template, sender Tspec, and Adspec) about the object class. The class type defines a unique object type within a class. In path data units the address of the preceding IP system has to be transported on the path being traversed. The address is required since a reservation data unit must follow this path exactly. A path data unit also contains the following components: ■ ■ ■

Sender template

Sender template Sender Tspec Adspec

The format of the data unit transmitted by the sender is described in a sender template. This is implemented in the form of a FilterSpec. A sender template contains, for example, the IP address of the sender

4.1 Integrated Services

147

32 bits

Object length

Class no.

Class type

Object content

Figure 4.13 Variable objects of RSVP data units.

and an optional TCP or UDP port, as well as a protocol identification assumed for the specified session. A sender Tspec that describes the traffic generated by the sender is transported in the path data unit. This Tspec is used by traffic control to prevent over-reservations being made. It is also evaluated for access control purposes. A path data unit can also contain an Adspec that includes information about the reservations along a path. In RSVP systems, the Adspec is always passed on to the local traffic control and, if necessary, adapted. This adapted Adspec is then entered into the path data unit being forwarded. Thus, the systems that follow know the resource requests that were implemented on the path so far and not just the requests issued by the sender. In addition to the path and reservation data units already introduced, special RSVP data units are available for error situations and for the explicit teardown reservations and path status information: ■ ■ ■ ■

Sender Tspec

Adspec

Error situations and explicit teardown

Path error data units (PERR) Reservation error data units (RERR) Path tear data units (PTEAR) Reservation tear data units (RTEAR)

Path error data units are sent as a reaction to errors caused by a path data unit. They are routed to the sender without causing any changes to the status information in the RSVP systems they have passed. Reservation error data units result from errors in reservations initiated by reservation data units. These data units are forwarded to the

PERR

RERR

148

Chapter 4 — Quality of Service

RSVP and IPv6

Non-RSVP clouds

respective receivers. A reservation data unit is, for example, the subject of merging in RSVP-capable intermediate systems. If, for example, a higher reservation is requested than the one already available, this can lead to a situation in which the requested reservation cannot be implemented because of high utilization of the system. In this case, the existing reservation is retained; the new request, however, cannot be granted. The receiver is notified of the situation through a reservation error data unit. Since RSVP does not implement any error control or repair mechanisms, there is no guarantee that the receiver making the reservation request will receive the error notification. Reservation termination can either be timer-based or issued by special teardown data units. The path tear data unit is transmitted from the sender to the receiver. It ensures that the corresponding path status information in the participating RSVP systems and the corresponding reservations are deleted. It is not absolutely necessary for this data unit to be sent because the soft-state concept ensures that this information is automatically deleted if no periodic data unit has been received for a predetermined time interval. However, the standard highly recommends that this tear data unit be used so that reservations can be released as soon as possible. The reservation tear data unit is initiated by the receiver or by an RSVP-capable intermediate system and forwarded to the sender. This data unit cancels the corresponding reservation on this path. Here, too, reliability is not always a given, but because of the timer-based soft state this is not critical. An interesting aspect of RSVP is the fact that it was originally primarily envisaged for use with the new version of the Internet protocol, IPv6. The flow field that is common to all data units for the identification of data streams was of particular interest. The flow field no doubt simplifies the handling of RSVP in the intermediate systems. However, most systems today are implementing RSVP in conjunction with the current version of the Internet protocol, IPv4. Therefore, the IP addresses as well as the ports for the transport protocol have to be analyzed for classification—in fact, for each data unit passing through an intermediate system. Advanced router technologies provide this functionality today even with very high data rates. Since an immediate Internetwide use of RSVP is not possible, “non-RSVP clouds” are being defined. RSVP should also be operable if multiple intermediate systems that do not implement RSVP are located between two RSVP-capable systems. It is clear that no RSVP reservations can be supported in such a subnetwork. However, the entire path between sender and receiver could possibly benefit from reservations on partial paths. RSVP is designed so that it also operates

4.1 Integrated Services

149

properly over non-RSVP clouds. Path and reservation data units are always forwarded correctly by IP. A non-RSVP flag signals in the RSVP data units that a non-RSVP-capable partial path exists so that later traffic controls are aware of it. As a consequence, the receiver only receives a best-effort service starting from the first non-RSVP-capable intermediate system. This is noted accordingly in the Adspec of the path data unit.

4.1.3 Sender-Oriented Reservations with ST2 Along with RSVP, the protocol ST2 (Internet Stream Protocol version 2) has been heavily debated in terms of its use for reserving resources on the Internet. At the current time it is clear, however, that ST2 is no longer the focus of attention and is not being selected because of its high complexity. Nevertheless, it seems appropriate to provide a brief presentation on ST2 because it pursues a totally different approach than RSVP. It is basically a sender-oriented technique compared to the purely receiver-oriented specification of RSVP. This reflects a similarity with the signaling protocols used in the ATM (Asynchronous Transfer Mode) world that also operate on a sender-oriented basis. It should be emphasized that ST2 is not only a signaling protocol. It is also incorporates a protocol that is used for transmitting user data. But this is where one of the major disadvantages of ST2 becomes obvious: It does not use IP as a network layer protocol. Instead it introduced its own control and forwarding protocol, analogous to IP and its control protocol ICMP (Internet Control Message Protocol). ST2 is therefore also involved in the transfer of user data, whereas RSVP uses the established network layer protocol IP for this function. In order to guarantee quality of service, both ST2 and RSVP require mechanisms for access control and traffic control. The basic communication scheme in ST2 is a stream. It represents the communication relationship between a sender and one or more receivers, with the data flow being unidirectional (see Figure 4.14). This is therefore a form of multicast communication. A multicast tree must be established as the basis for forwarding data. The routing protocols needed to set up the multicast tree are not an integral part of ST2. Systems within a tree can simultaneously function as end systems and intermediate systems. A dedicated quality of service can be allocated to the streams along a multicast tree. In addition, dedicated point-to-point connections exist between directly neighboring ST2 systems. These are used to exchange control

Stream: unidirectional data flow

150

Chapter 4 — Quality of Service Receiver 1

ST2 data unit ST2 router

Sender SCMP data unit

Receiver 2 Figure 4.14 ST2 communication scheme.

information, the SCMP (Stream Control Message Protocol) data units. A reliable exchange of control information exists between neighboring ST2 systems. In comparison, the use of ST2 data units for the transfer of user data is based on an unreliable service. In contrast to RSVP, the communication process takes place in three clearly separate steps: ■ ■ ■

Establishment of an ST2 stream Transfer of user data Termination of an ST2 stream

Different protocols are applied for each of these steps: ■ ■

ST2 offers unreliable service

ST2 (Stream Protocol) for user data transfer SCMP (Stream Control Message Protocol) for the transmission of control data

With respect to the transfer of user data, ST2 can be viewed as a supplement to IP. It is designed for the transmission of real-time data with quality-of-service requests. IP transports data that expects a besteffort service. ST2 is a simple protocol with a small number of protocol functions. It does not incorporate error control. Data delivered to receivers can therefore be erroneous or out of sequence. It is also possible for entire data units to be lost. It should further be noted that different receivers in a multicast tree could receive different parts of the data transmitted by the sender. If error control is required, it has to be implemented in the protocols located on top of ST2 or in the application itself. In contrast to IP, ST2 provides no mechanisms for

4.1 Integrated Services

151

segmentation or reassembly. The main tasks of ST2 are stream identification and the provision of data priorities for dealing with real-time data.

Setting Up and Terminating ST2 Streams The tasks of SCMP are focused on the setup and termination of ST2 streams. The setup is based on a two-way handshake. Requests for desired services are distributed during the setup of a stream. Similar to RSVP, this involves using a FlowSpec. This FlowSpec contains service quality parameters, which are important for the reservation, and traffic specifications. The definition of the FlowSpec itself is not part of the specification for ST2. It therefore also differs with the various implementations of ST2, which accounts for the existing compatibility problem. Although the FlowSpec for Integrated Services was developed after the design of ST2, this FlowSpec can certainly be used with ST2. This would avoid the compatibility problem mentioned and therefore greatly increase the attractiveness of ST2. However, the problem related to the high complexity of SCMP remains. An admission control that decides whether a new ST2 stream can be accepted or, because of a lack of resources, must be rejected is required for setting up an ST2 stream. Each ST2 system has a local resource manager (LRM) (see Figure 4.15) that is always activated in the participating ST2 systems during stream setup. This activation takes place before a connect data unit is transmitted or forwarded. Connect data units signal the establishment of new streams. If an ST2 system receives a correct connect data unit, this is acknowledged

Accept-ACK 8 Sender

7 Accept Connect 1

LRM

Accept-ACK 6 ST2 router

5 Accept Connect 3

LRM

LRM 2 Connect-ACK

Receiver

4 Connect-ACK

ACK: Acknowledgment LRM: Local resource manager Figure 4.15 Stream setup with local resource managers.

Stream setup

Local resource managers

Connect data unit

152

Accept data unit

Chapter 4 — Quality of Service to the next upstream ST2 system through a connect-ACK data unit (see Figure 4.15). The local resource manager is then activated and, if necessary, local resources are reserved and the connect data unit is forwarded toward the receiver. Note that a connect data unit is an end-to-end data unit that has to be acknowledged separately on each transmission link. This requires the corresponding acknowledgments themselves as well as local timers in order to avoid deadlocks. If a receiver has received a connect data unit correctly and is also able to provide resources, it responds with an accept data unit. This too is an end-to-end data unit that has to be acknowledged on each transmission link. Stream setup in ST2 can take place in three different ways: ■ ■ ■

Sender-oriented stream setup

Sender-oriented Receiver-oriented Hybrid

In the sender-oriented stream setup shown in Figure 4.16, the sender is determining the group of receivers. The application provides a complete list of receivers for this purpose. New receivers are added explicitly by the sender to the stream. The list is then expanded accordingly, whereby the sender produces a connect data unit for the Receiver 1 ST2 data unit

Connect 1 Sender

ST2 router

Receiver 2 Connect

4 Accept

2 3

Accept Receiver n

Figure 4.16 Sender-oriented stream setup.

4.1 Integrated Services

153

Receiver 1 ST2 data unit

Sender

4 Notify

ST2 router

Receiver 2 1

Connect 2

Join

3 Accept Receiver n Figure 4.17 Receiver-oriented stream setup.

receiver. The receiver must respond to it with an accept data unit. The receiver is then accepted into the group and receives the user data being transmitted. The procedure used with ST2 is comparable to the one for UNI-3.1 signaling of ATM. When sender-oriented stream setup takes place, all involved ST2 systems receive complete information about the systems participating in the communication. These are therefore known and open groups. Reliable group services can be implemented on this basis. Receiver-oriented stream setup allows individual receivers to join a stream without the involvement of the sender (see Figure 4.17). At the beginning of a group communication, an empty list of receivers is generated. If a receiver wishes to join a group, it sends a join data unit. In a positive case, the first ST2 system on the path toward the sender responds with a connect data unit. The receiver in turn responds with an accept data unit. The ST2 system then notifies the sender with a notify data unit. The sender continues to know who all the receivers are. This imposes a scalability problem for very large groups. With hybrid approaches for stream setup, a list of initial receivers is available at the beginning. Afterwards other receivers can separately join the group. The reserved resources in the end and intermediate systems should be released appropriately during connection termination.

Receiver-oriented stream setup

Hybrid stream setup Connection termination

154

Chapter 4 — Quality of Service

Resource Reservations with ST2

Over-reservations are possible

With ST2, reservations for resources are carried out in two steps. The maximum resources required are reserved on the path to the receiver. They can be reduced on the path to the receiver and by the receiver itself if certain systems do not provide sufficient resources. The previous reservations will then possibly be reduced on the return path from the receiver to the sender. This can initially result in an overprovisioning of resources during stream setup, which means more resources are reserved than are ultimately needed for data transfer. From an overall point of view this is not desirable: A new stream could end up not being accepted because of a lack of resources due to an overprovisioning that will be reduced a short time later. Receiver-oriented reservations are partially able to avoid this problem. Besides setup and termination, SCMP is responsible for error control of control data units and for the implementation of modifications to existing streams. “Modifications” in this context refer to changes to group composition (members joining or leaving). They also refer to changes of the desired quality of service of an established stream. For error control it is necessary that the exchange of control data between neighboring ST2 systems be monitored. It is important that problems arising in routing and in resource reservation are detected. In addition, a check is necessary to determine whether any individual systems have failed. Altogether, SCMP is a considerably more complex protocol than ST2. This complexity is the cause of its initial rejection on the Internet.

ST2 Data Units The control information transported in the header of an ST2 data unit consists of 12 bytes (see Figure 4.18), which is low compared to other Internet protocols. It contains two version numbers: the IP version and the ST2 version. This means that the beginning of a data unit is the same as that of an IP data unit. IP version number 5 is used for ST2. The D bit identifies whether it is an ST2 data unit or an SCMP data unit. The 3-bit priority field enables a differentiation to be made between a total of eight priorities. The subsequent 4 bits are reserved; that is, they are not currently used. The length field contains the total number of bytes for an ST2 data unit, including the header. The checksum is only calculated over the header. A unique identifier together with the IP address of the sender uniquely identifies the ST2 stream.

4.1 Integrated Services 32 bits ST2 Version

IP D Priority Reserve Version Checksum

Length Unique identification

Source IP address Figure 4.18 ST2 data unit.

The sender selects the 16-bit unique identifier that, together with the IP address, makes it unique networkwide. For transport SCMP data units are encapsulated as a user data field in ST2 data units. This is comparable to the transport of ICMP data units within IP data units. For practical experiments, ST2 can initially be implemented on top of IP. As a consequence, ST2 data units are encapsulated into IP data units. The advantage of this approach is that these data units can then flow transparently through non-ST2-capable intermediate systems. This enables the installation of an overlay network on the Internet for use in experiments. As is the case with RSVP, several implementations exist of ST2 (e.g., [115]), but its development was mainly centered in Europe. ST2 in particular was implemented within the framework of the Berkom project that was promoted by German Telekom on different platforms for the support of multimedia applications [20]. Some of the current ST2 implementations have had problems with respect to interoperability mainly because of the use of different FlowSpecs. An integration of the new developments in the Integrated Services area, including the traffic control parameters for the specification of different classes of services, could resolve this problem. Heterogeneous multicast is supported directly by RSVP, whereas only homogeneous multicast is addressed by ST2. Moreover, ST2 does not incorporate any functions for merging reservation requests in network internal ST2 systems.

4.1.4 RSVP vs. ST2 Table 4.2 summarizes a comparison of RSVP and ST2. In terms of functionality, it should be noted that ST2 is not only a signaling protocol but also a protocol for the transfer of real-time data.

155

156

Chapter 4 — Quality of Service Table 4.2 RSVP vs. ST2. ST2

RSVP

Functionality

Signaling protocol and data transfer

Signaling protocol

Connection types

Connection-oriented, multicast, multipeer

Short-lived connections, multicast

Reservations

Sender- or receiveroriented

Receiver-oriented

Modifications

Quality of service and receiver group through explicit messages

Quality of service and receiver group through periodic messages

Error handling

Complex control and correction

Periodic message exchange

Heterogeneity

No

Yes

By contrast, RSVP represents a pure signaling protocol that uses IP for data transfer. ST2 is used to establish dedicated connections with hard-state information. RSVP, on the other hand, is based on soft states and a concept of short-lived connections. No explicit connections are set up and no explicit acknowledgments about reservations are supplied. With ST2, reservations are sender-oriented or receiver-oriented; with RSVP they are receiver-oriented. The receiver-oriented concept avoids a temporary overprovisioning of resources. Because ST2 explicitly establishes streams, changes also take place on an explicit basis through the dedicated transmission of the appropriate ST2 data units. RSVP is based on a process by which path and reservation data units are sent periodically. An adaptation therefore takes place implicitly. RSVP is based solely on periodic data exchange. In contrast to ST2, this does not require a complex error detection and correction protocol. The disadvantage can be seen in the possibly high overhead of signaling traffic if no changes are required.

4.2 Differentiated Services The IETF is currently discussing Differentiated Services (DiffServ), an alternative to the Integrated Services (IntServ) previously described. The need for alternatives has been triggered by the potential

4.2 Differentiated Services

157

disadvantages of RSVP and ST2 that were listed earlier: state holding and management in the intermediate systems, the amount of signaling required, and the potential overprovisioning of resources with ST2 as well as its complexity.

4.2.1 Basic Concept Differentiated Services try to avoid the disadvantages inherent in the Integrated Services. The basic architecture for Differentiated Services is presented in [25]. DiffServ follows two basic approaches: ■

■

■

Aggregated reservations for a number of data streams, which, for example, flow between two Internet providers, instead of individual reservations for each data stream. Implicit signaling for quality of service through the inclusion of the necessary information in the data units. This avoids dedicated signaling with its own independent complex signaling protocol and the status maintenance required in the intermediate system. Provisioning of different service classes.

In principle, aggregated reservations can be compared to the concept of leased lines. See the scenario in Figure 4.19 that uses DiffServ concepts for reservations between Internet providers and between Internet providers and exchange providers. These reservations are

Internet provider B

Internet provider A

Aggregated reservations Exchange provider

Internet provider C

Figure 4.19 Example of aggregated reservations.

Long-term reservations

158

Chapter 4 — Quality of Service

Signaling protocol not yet specified

Quantitative requirements cannot always be considered

maintained over a relatively long period of time; thus they are considered to be static. The DiffServ concept can be compared to ATM and the paths and channels it uses. A path corresponds relatively directly to such an aggregated reservation. ATM uses its own rather complex signaling protocol for signaling ATM paths. A signaling protocol has not yet been introduced for Differentiated Services. RSVP is an example of a signaling protocol that could be used, but this option has not yet been considered further. The hope is that there will not be a repeat of the early days of ATM when the signaling protocol had not yet been definitively standardized and implemented. For years fax and telephone were, and to some extent still are, used to support signaling for the setup of ATM paths. The aggregated reservations of DiffServ are shared among individual data streams. There is no signaling of quality of service related to these data streams. Instead the necessary information is transported in the individual data units themselves. The information about quality of service is evaluated by each of the intermediate systems involved. The advantages of this procedure include a considerable reduction of status management in intermediate systems and the lack of complex signaling. Therefore, this appears to be a better solution in terms of scalability to large networks with many data streams than the approaches of the Integrated Services using RSVP or ST2 protocols discussed previously. However, this solution also has an inherent problem in that no dedicated guarantees can be given for individual data streams. Differentiated Services basically do not provide explicit resource reservations for individual data streams. Resources are always allocated according to the current load conditions. Although this enables different data streams to be treated differently in principle, quantitative information about resources that can be allocated to individual data streams is not possible. Therefore, only a relative quality of service can be implemented. The following example helps to clarify this (see Figure 4.20). Four senders are competing for a transmission link. The transmission link has a capacity of 1 Mbit/s. This is an aggregated reservation. The individual senders each produce data streams with a data rate of 300 kbit/s. If only three of the senders transmit data, the available overall capacity of 1 Mbit/s is sufficient for the 900 kbit/s needed. However, the resources are not sufficient if the fourth sender also starts to transmit data. The individual senders will then only be able to transmit with 250 kbit/s each. Yet relative to one another, the same capacity is available to them. This kind of behavior cannot be

4.2 Differentiated Services

159

Sender 1

300 kbit/s Sender 2

300 kbit/s Differentiated Services (1 Mbit/s)

300 kbit/s

300 kbit/s

Sender 3

Sender 4

Figure 4.20 Example of relative quality of service with DiffServ.

guaranteed, however, because it depends on the strategy used for subdividing the aggregated data rate among four data streams. This strategy is determined by the scheduling mechanisms used in the corresponding router. Another interesting aspect is that the end systems are only involved in a way that the applications can properly formulate their requests for quality of service. This is a task applications must also be equipped to perform with RSVP. However, there is no need for traffic control or signaling functions to be incorporated in the end systems, unlike the situation with RSVP and the RSVP daemon, for example. With the DiffServ concept, a network is divided into domains. A distinction is made between differentiated service domains and domains that are not able to support Differentiated Services. Figure 4.21 shows a scenario with one DiffServ domain and various connected networks. A DiffServ domain is linked to other domains through boundary routers. An edge router connects a non-DiffServ-capable domain to a DiffServ domain. The aggregate quality of service reserved with the DiffServ concept relates to the path between an edge router and a boundary router or between the boundary routers of different

DiffServ domains

160

Chapter 4 — Quality of Service

DiffServ domain

Edge router

Boundary router

First-hop router

Intermediate router

Figure 4.21 Example of a network with DiffServ domains.

Edge routers

Classification

DiffServ domains. This is where aggregated resources for all data streams that flow between the participating domains are provided. The edge routers handle the traffic control for the transmission link carrying the aggregated reservation. A token-bucket can be used for this purpose. If data cannot be serviced with the existing resources, it is dropped in the edge router. Another option is to reclassify the data. In this case the information regarding quality of service is adapted to a lower priority in the data units—for example, into best-effort data. Even with best-effort data, the only viable solution in an overloaded network is to discard data. The first intermediate system following the end system that issued the data is called a first-hop router. It converts the quality-of-service requests for applications to the corresponding data fields in the data units being transmitted. This process is referred to as a classification of data units. Other routers located between intermediate systems are called intermediate routers. These routers are responsible for the correct forwarding of data units, which requires an interpretation of the classification in the data units. The procedure followed in domains that are not DiffServ capable, however, is not based on the conditions

4.2 Differentiated Services

Codepoint 0

1

2

3

161

Reserved 4

5

6

7

Bit Figure 4.22 DiffServ field with codepoint.

of the DiffServ concept. Forwarding in accordance with DiffServ is principally based on a prioritization of data units. Each data unit carries a special field that indicates the priority class of that data unit. It is served within the DiffServ routers according to that priority. The codepoint (see Figure 4.22) specifies the per-hop behavior (PHB) of a data unit and defines how data units in DiffServcapable routers should be processed. Currently different proposals exist for the use of the DiffServ field. One proposal mainly promotes increasing the usefulness of the type-of-service field in IPv4 data units. In principle, DiffServ can be used without a uniform specification for per-hop behavior. However, it cannot be expected that each DiffServ router will then handle data in the same way. It is therefore desirable to have a standard definition of per-hop behavior.

Per-hop behavior

4.2.2 Proposals for Service Concepts for Differentiated Services Until now, the discussion about Differentiated Services has focused on basic concepts. Some of the approaches presented in the literature for service provisioning will be described in the following sections. These include ■ ■ ■

Premium services [112] Assured services [41] User-shared differentiation [157]

Premium Services The aim of premium services is to provide a virtual leased line with a fixed data rate. This allows the servicing of applications that have constant data rates and are particularly sensitive to network congestion. Audio transmission is an example of such an application.

Suitable for audio transmission

162

Chapter 4 — Quality of Service

Only for a small percentage of network capacity

The basic assumption of premium services is that only a very small portion of the overall network capacity will be made available for premium services. Thus there is no chance of the network becoming overloaded and, consequently, no queues build up in the network’s intermediate systems. Data therefore usually experiences an end-to-end delay that almost equals the minimum delay possible. Delay fluctuations caused by queues rarely occur. The premium services concept relies on an overengineering of the network because only a small percentage of it is used for premium services. This must be ensured by admission control. The capacity provided exceeds what is normally required. The basic view of the IETF is that this is a viable approach—a view that could be questioned. Although there has recently been a clear increase in available network capacity, the capacity per user has actually been reduced. This is mainly attributed to the growing number of users on the Internet. The capacity not utilized by premium services is used for besteffort service. With this service, data is merely discarded if the network is overloaded. The same happens to premium services data that cannot be serviced. In the case of premium services, the first-hop router of each domain in the path is responsible for correctly classifying the data units. To do so, the first-hop router sets the appropriate bits in the per-hop behavior of the data units. A shaping of the data stream is also required. The intermediate systems in the network then forward the data units in accordance with the selected priorities. The traffic control takes place in the edge routers, for example, using a token-bucket.

Assured Services Suitable for file transfer

In contrast to premium services, assured services address bursty-type traffic that occurs, for example, with file transfer. An assured service cannot guarantee a particular quality of service. However, it is assumed that loss of data occurs rarely. Although a dedicated quality of service is not guaranteed, it can be assumed that the services available in the device will meet the requirements. The classification of the traffic is carried out in the first-hop router of each domain in the path. The intermediate systems in the network forward the data on the basis of this classification. The edge routers again have to provide traffic control as well as a traffic classification. If data cannot be forwarded in accordance with an assured service, it is reclassified as a best-effort data unit and, if possible, forwarded.

4.2 Differentiated Services

163

Combination of Premium Services and Assured Services Premium and assured services can be combined in order to offer three different services: a service for continuous data streams, a service for bursty-type traffic, and a best-effort service. Figure 4.23 shows the scheme of a first-hop router that supports this combination. The classifier first differentiates data units according to whether they belong to premium or to assured services. The data units are then forwarded to the corresponding queues and pass through the respective token-buckets. Best-effort data is placed directly in the RIO queue on the output link. As soon as they have passed the corresponding token-bucket, data units of an assured service are also relegated to this queue. RIO stands for “RED (Random Early Discard) with input and output.” RED [29] is a queue management service based on the premise that data units will be discarded with a certain probability even though a queue is not yet completely filled. Overall, this leads to shorter queues and to an improved system behavior. RIO relies on the combination of two RED mechanisms, one for an assured service and one for a best-effort service. In addition, it is determined how many data units can be queued for a traffic specification and how long the overall queue is. Based on this information, data units that were not reclassified or that fall into the category of best-effort data are discarded first. Data units for assured services are only discarded if it is unavoidable.

User-Shared Differentiation In contrast to premium and assured services, the user-shared differentiation (USD) approach is based on users only providing information

Token-bucket premium service

Classification

Token-bucket assured service

Best effort

RIO queue Figure 4.23 Diagram of a first-hop router.

RIO queue

164

Chapter 4 — Quality of Service

DiffServ and multicast

about the percentage of the available data rate in the network to be used. No explicit data rates are given, which means that there is no Tspec. The percentage also directly determines the charges to be paid. Each user is then always guaranteed a minimal data rate that is subject to the number of users in the network. Furthermore, the data rate provided is in proportion to the user’s share of bandwidth use. This applies to each transmission link. The intermediate systems in the network must be aware of the traffic contract with the respective user so that they can regulate the traffic accordingly. For example, network management can be used to distribute this information. One of the advantages of USD is that no access control is required. Furthermore, it is very suitable for reverse traffic, such as traffic that flows from the Web to the user making the request. The complete dependence on the current network load for quality of service can certainly be viewed as a disadvantage of USD. It means, for example, that the quality of service could fluctuate considerably during a communications relationship. Multicast services have not yet been explicitly considered in the recent discussions on DiffServ. A simple version of multicast services could in principle also be implemented with DiffServ, based on IP multicast. The data being sent would be provided with an IP multicast address and then dealt with in the respective IP routers. The data could be distributed to a group of users in this way. However, situations could easily arise in which users who are located in different geographical areas of a group would experience a different quality of service because of the relative provisioning of quality of service. The quality of service experienced in practice depends highly on the current load in the individual network areas.

4.3 Differences and Integration Options In this section, differences between IntServ and DiffServ are first discussed, and then approaches to integrate the two models are presented.

4.3.1 IntServ vs. DiffServ IntServ and DiffServ represent two completely different approaches (see Table 4.3) with the same objective of supporting multimedia applications efficiently on the Internet. A key difference between the two

4.3 Differences and Integration Options

165

Table 4.3 Comparison of IntServ and DiffServ. Best effort

Integrated Services

Differentiated Services

Quality-of-service guarantee

None

Per data stream

Aggregated data streams

Configuration

None

Per session end-to-end

Between domains

Type of guarantee

None

Soft individual

Aggregated

Duration of guarantee

None

Short-lived (duration of session)

Long-term

State management

None

Per data stream

Per aggregated reservation

Signaling

None

RSVP

Not yet defined or not required

Multicast

IP-multicast

Receiver-oriented, heterogeneous

IP-multicast, otherwise no special support

is that DiffServ provides quality-of-service guarantees for aggregated data streams. On the other hand, IntServ works with a considerably finer granularity. It makes resources available to individual data streams and operates on soft states. However, this can result in very large tables for status and reservation data in RSVP systems, which can create problems in terms of scalability. Approaches to aggregated RSVP were developed to improve this situation (e.g., [22]). Another basic difference between the two approaches is the DiffServ assumption that reservations do not change over a longer period of time. This status motivates a comparison with leased lines. With RSVP, on the other hand, reservations are made per data stream. Although this increases the amount of signaling and state management required, there is the advantage that the dynamic requests of different data streams can be dealt with individually and quickly. With RSVP a signaling protocol is already defined for IntServ. No special protocols currently exist for DiffServ. This lack of special protocols is the subject of future studies and will be important for the implementation of the overall concept. Because the complexity of these signaling protocols is not yet known and, thus, cannot yet be assessed, a straightforward comparison between IntServ and DiffServ is not easily possible.

4.3.2 Integration of DiffServ and IntServ Now that both approaches, InterServ and DiffServ, have been introduced, an effort is being made to integrate them. One scenario being

166

Chapter 4 — Quality of Service

Stub net

Transitnet work

Stub net IntServ

IntServ DiffServ

Edge router

Boundary router

Figure 4.24 Integration scenario for IntServ and DiffServ.

discussed today is presented in Figure 4.24. The assumption in the scenario is that DiffServ domains are mainly found in transit networks, whereas RSVP is used in “stub networks” in the near vicinity of the user. One reason why this appears realistic is because it would be much easier to install RSVP there than in the transit networks, which would alleviate the scalability problem mentioned earlier. The edge routers in the stub networks should consequently implement RSVP if possible. However, this does not need to be a complete implementation. It essentially should provide a conversion of quality-of-service requests from IntServ to DiffServ. No implementation of RSVP is necessary in the boundary routers of the DiffServ domains. What should be taken into account in this scenario is that the end-to-end semantics of RSVP are eliminated because RSVP only continues to operate in subnetworks. If we look at this scenario from the standpoint that overengineering is more likely in those networks that are in close vicinity to the user than in transit networks, then the situation appears somewhat unrealistic. It would mean that DiffServ could be adequate in the stub networks but not in the transit network. On the other hand, it can be observed currently that bandwidth in backbone networks is growing rather rapidly, whereas bandwidth in access networks will remain somewhat low or moderate.

5 Multicast in ATM Networks

A

TM-based networks and broadband ISDN are still being developed. Yet at the same time they are also being introduced in the market. However, these technologies have not yet managed to succeed in achieving a widespread level of use and are not predicted to do so in the near future. ATM networks are capable of servicing multimedia applications that place high demands on communication infrastructure (e.g., high throughput, short delays). Multimedia applications are frequently based on group communication. Therefore, ATM networks should also offer effective and efficient support for these applications.

5.1 The Switching Technology ATM ATM networks differ in their basic design from the protocols that have been used on the Internet, such as IP, IP-multicast, or RSVP. IP offers a connectionless forwarding service, whereas ATM networks operate on a connection-oriented basis [3, 24, 71, 170]. Furthermore, both networks use different concepts for reserving resources. ATM is based on the hard-state concept—the allocation of resources to connections is fixed. In contrast, current approaches on the Internet (e.g., RSVP) are based on the soft-state concept, which does not provide any hard guarantees in terms of quality of service. However, the assumption is that the use of soft states can accommodate most requirements for resources on the Internet. Moreover, it is helpful in the case of adaptive applications. ATM networks are based on a special switching technology that is a variation of fast packet-switching [3]. Data units with a fixed length, called ATM cells, are used as the basic units for data exchange. ATM cells are composed of a 5-byte cell header and a 48-byte data part (see Figure 5.1). The cell header essentially consists of address information and a checksum calculated over the cell header. The address

ATM vs. IP

ATM cells

168

Chapter 5 — Multicast in ATM Networks 5 bytes

48 bytes

Header

User data

GFC/Virtual path identifier

Virtual path identifier

Virtual path identifier

Virtual channel identifier

Virtual channel identifier Virtual channel identifier

PT

Header error control

CLP GFC: Generic flow control PT: Payload type CLP: Cell loss priority

Figure 5.1 ATM cells.

Virtual connections

information determines a cell’s affiliation to a virtual connection. Depending on the requirements, ATM cells are multiplexed asynchronously on the transmission medium, hence the name of this switching technology. This is in contrast to the synchronous transfer mode STM that is used with ISDN. With STM, resources are committed irrespective of actual need. If there is no data to be transmitted during the current communication, the resources are being wasted. The ATM concept incorporates a connection-oriented design. Therefore, a virtual connection first has to be established before user data is transmitted. A local connection identifier (label) is associated with each individual transmission link and is entered onto tables in the intermediate systems of the network, the ATM switches. Network internal forwarding is based on the principle of label swapping. Locally significant labels always identify the virtual connections in an ATM switch. Therefore, the identity on the inbound transmission link is usually different from the one at the outbound transmission link (see Figure 5.2). ATM switches therefore implement the necessary conversion of the identifier in each ATM cell. This involves changing the address information of the ATM cells. The sequence of all identifiers being passed between source and destination identifies a virtual connection in ATM networks. Virtual connections are mainly established

5.1 The Switching Technology ATM VCI = 27 VPI = 7

VCI = 42 VPI = 13 ATM switch

VCI = 17 VPI = 7 ATM switch

169

VCI = 5 VPI = 11 ATM switch

Figure 5.2 Virtual connections in ATM networks.

for pure point-to-point communication. Different quality-of-service aspects (throughput, delay, and so forth) can be negotiated per transmission direction. Two different types of virtual connections, ordered hierarchically, are distinguished in ATM networks: ■ ■

Virtual channels (VCs) Virtual paths (VPs)

Virtual channels provide unidirectional or bidirectional transport for ATM cells. The desired quality of service can be specified separately for each transmission direction. Virtual paths combine virtual channels with the same end points. The end points of virtual paths can be end systems or ATM switches. The identifiers mentioned previously identify the virtual channels and virtual paths: ■ ■

Virtual channel identifiers (VCIs) Virtual path identifiers (VPIs)

VCIs and VPIs together form the address information in ATM cell headers. An example of virtual connections crossing multiple ATM switches is shown in Figure 5.2. As the figure shows, VPIs and VCIs in this example are converted at each ATM switch. If a virtual channel is carried within a virtual path that crosses several ATM switches, it is only the VCI that changes in these switches; the VPI remains the same.

5.1.1 ATM Adaptation Layer Various ATM services are offered through the ATM adaptation layer (AAL) (see Figure 5.3). These services are based on the transfer mode that is defined in the ATM layer and the physical layer. The task of the

Virtual channels Virtual paths

170

Chapter 5 — Multicast in ATM Networks ATM services

Adaptation layer ATM layer Physical layer

Figure 5.3 Protocol layers in ATM-based networks.

Classes of service

ATM adaptation layer is to expand the services of the ATM layer so they comply with the requirements of the higher layers. Service-specific tasks are implemented by convergence functions. A typical task of the ATM adaptation layer is the segmentation and reassembly of data units of the ATM adaptation layer to ATM cells and the reverse. The services provided by the ATM adaptation layer are divided into four basic classes of service: classes A, B, C, and D. They differ from one another according to the following key characteristics: ■ ■ ■

Class A

Class B

Classes C and D

Bit rate Service category Time relationship between sender and receiver

Service class A is designed for the provision of isochronous services. Examples include voice traffic and video with constant bit rates. Class A is based on a constant bit rate and a connection-oriented concept. It requires a time relationship between sender and receiver (see Table 5.1). Service class B is suitable for the transmission of video with variable bit rates. In contrast to class A, it does not require fixed bit rates. The other characteristics are the same as class A. Service classes C and D are available for traditional data communication. A time relationship between sender and receiver is not necessary. The bit rate is variable. Class C provides a connection-oriented service; class D, a connectionless one. The service of class C is reliable, whereas the service of class D is unreliable. Different types of AALs were designed on the basis of these classes of service (see Table 5.2). AAL type 1 was developed to enable the provision of class A services. It is being used today for the transmission of

5.1 The Switching Technology ATM

171

Table 5.1 ATM service classes. Class of service

Bit rate

Service category

Time relationship

Application

A

Constant

Connection-oriented

Yes

Audio

B

Variable

Connection-oriented

Yes

Compressed video

C

Variable

Connection-oriented

No

File transfer

D

Variable

Connectionless

No

File transfer

Table 5.2 AAL types and service classes. AAL

Class of service

AAL1

A

AAL2

B

AAL3/4

C and D

AAL5

C and D

64 kbit/s voice traffic. So many similarities were established in service classes C and D during the development of AALs that they were combined into a joint AAL type, AAL3/4. AAL3/4 is a rather complex type of AAL that produces a high overhead in data transmission due to its functionality. As a result, the IETF subsequently developed a simpler type of AAL for the services of classes C and D. This is referred to as AAL5 and is the one mainly used today. A key restriction of AAL5 compared to AAL3/4 is the lack of support for data multiplexing. AAL3/4 data units carry an identifier of the data units, called the message identifier, which allows multiplexing. This ability to multiplex data could be particularly helpful in the implementation of group communication over ATM. Current solutions are, however, based on the more popular and efficient AAL5.

5.1.2 Service Categories in ATM ATM supports different service categories because of the dissimilar requirements of applications for guaranteed quality of service and data rates. In some cases the characteristics of data streams can differ considerably. They can range from continuous data streams for uncompressed audio all the way to bursty-type data streams for file transfer or compressed video. To deal with this situation, the ITU-T and the ATM Forum defined different types of connections [12, 71].

AAL5

172

Chapter 5 — Multicast in ATM Networks Traffic contract

During connection setup, a traffic contract defining the characteristics of the communication is agreed upon between the communication partners and the network. This traffic contract specifies, among other things, details about the service category for a connection. In addition, it contains information about the quality of the transmission on the ATM layer, a list of traffic parameters for describing the data source, and an upper limit for delay jitter of the cells. These parameters can be explicitly checked in the end systems and ATM switches to determine for each cell whether it conforms to the traffic contract. The following service categories are supported by the ITU-T: ■ ■ ■ ■ ■

Deterministic bit rate

Statistical bit rate

Deterministic bit rate (DBR) Statistical bit rate (SBR) Available bit rate (ABR) ATM block transfer (ABT) Unspecified bit rate (UBR)

A deterministic bit rate provides a fixed bit rate for the entire duration of a connection. This service category is particularly suitable for continuous data streams such as audio. Therefore, it is used to provide AAL1 services. A similar service category was defined by the ATM Forum under the name constant bit rate (CBR). Table 5.3 presents a comparison of the different service categories as defined by the ITU-T and the ATM Forum. The service category referred to as a statistical bit rate is mainly for bursty-type data streams, including video transmission with varying data rates or traditional data services. This service category is particularly suitable for the use of statistical multiplexing. The average data rate is usually considerably lower than the maximum data rate. In the case of noncorrelated connections, reservation of the maximum data rate is not necessary for all connections. The transmission capacity is Table 5.3 Service categories: ITU-T vs. ATM Forum. ITU-T

ATM Forum

DBR

CBR

SBR

VBR

ABR

ABR

ABT

—

UBR

UBR

5.2 ATM Multicast allocated on a statistical basis. In the ATM Forum, this service category is called a variable bit rate (VBR) service. A further distinction is made between connections with real-time requirements (real-time VBR, rt-VBR) and connections without these requirements (non-realtime VBR, nrt-VBR). The ATM Forum initially specified the service category ABR. ABR allows the use of transmission capacity not currently being used by the service categories with deterministic and statistical bit rates. The utilization of the transmission links and ATM switches is thereby improved. Therefore, no service guarantees can be derived for ABR traffic. However, this offers the option of an economic service for data transmission that has no special quality-of-service requirements. This kind of service is adequate for a large number of traditional data applications. The data rate of ABR traffic must constantly adapt to the current situation on a network. A networkwide operating flow control was defined for this purpose. It is also possible to negotiate a minimum data rate during connection setup. This is then the minimum rate provided for the entire duration of the connection. The service category ABT has also been designed for applications with varying requirements. Blocks of ATM cells are formed, which are bounded by resource management cells (RM cells). If this kind of block is used for transmission, it is serviced in accordance with DBR. Note, however, that the ATM Forum does not support ABT traffic. Therefore, it is assumed that this service category will have a minor role compared to the other service categories. What characterizes the UBR service category is that the network does not have to reserve any resources for it. It directly reflects the best-effort services that are offered on the Internet through UDP and IP. UBR is closely comparable to ABR. However, unlike ABR, it does not incorporate complex flow control or the option for requesting a minimum data rate. Error situations are dealt with by protocols located above an ATM service that uses UBR.

5.2 ATM Multicast Conventional point-to-point communication was initially the main focal point during the design of the ATM concept. Group communication was not explicitly considered at the beginning. Currently, ATM is mostly used for point-to-point communication. The support of group communication will require enhancements to signaling as well as in

173

Available bit rate

Block transmission

Unspecified bit rate

174

Sender-oriented multicast

Chapter 5 — Multicast in ATM Networks Operations and Maintenance (OAM). OAM functions today are purely designed for point-to-point connections. Internal network routing will also have to be extended accordingly. Multicast communication in ATM is based on a sender-oriented model in which the sender establishes a multicast connection to all receivers. A tree is generated with the root representing the sender and the leaves representing the receivers. Data is routed from the sender along the tree to the receivers. The sender must be explicitly aware of all receivers since ATM up to UNI 4.0 does not support ATM multicast addresses, which enable a group to be addressed indirectly. With multicast communication, a connection is first established between the sender and a single receiver. The other receivers are gradually added to the group. All changes to group membership must be made known to the sender. The sender is responsible for explicitly adding or deleting group members. This has some effect on the scalability of ATM multicast. It is not well-suited for use with large and highly dynamic groups. Moreover, its suitability for broadcast applications (e.g., Internet radio) can be questioned. However, it does provide good control over group membership and allows the establishment of closed groups. The ATM cells are copied in the ATM switches and forwarded to different branches of the multicast tree (see Figure 5.4). The cell headers receive different connection information for this purpose (such as different VCIs and VPIs), depending on the path through the multicast tree.

5.2.1 Multicast vs. Multipeer in ATM Group communication in ATM is based on the multicast communication form: data is sent from a single source to multiple receivers. Multipeer communication (sending data from multiple sources to multiple receivers) is not directly possible in ATM on the basis of ATM connections—especially with AAL5. Communication is restricted to multicast connections because adaptation layer AAL5 does not support multiplexing of different data streams. AAL5 data units do not have identifiers, unlike the data units of adaptation layer AAL3/4. When AAL5 is used, the data units sent by different senders in a tree cannot be reassembled correctly there by the receiver. Adaptation layer AAL3/4 would allow multipeer connections since it does use such an identifier, called a message identificator (MID). However, an assurance that the different end systems are using

5.2 ATM Multicast

175

Leaf

Leaf

ATM switch

Leaf

Leaf Sender Leaf

Leaf Leaf Receiver Leaf Figure 5.4 Multicast tree in ATM networks.

different MIDs [7] would be needed. This would require a separate protocol for synchronization and the allocation of MIDs. The maximum allowable number of different MIDs restricts the number of end systems that can be supported. AAL5 is the adaptation layer mainly used today. It allows an efficient use of the transmission media because of the considerably lower overheads caused by the control information in the data units. The following discussion therefore concentrates on ATM multicast on the basis of AAL5. There is another basic reason why ATM cannot provide multipeer communication that is related to the merging of quality-of-service requirements of different communication partners. As is the case with RSVP, a merging of quality-of-service parameters is required.

176

Chapter 5 — Multicast in ATM Networks Expanded signaling may also be necessary. ATM does not offer the corresponding mechanisms. On the other hand, multipeer communication can be emulated in ATM through the use of multiple multicast trees. Each member of a group must then establish a multicast tree to all other group members. For large groups, this results in a considerable increase in the number of virtual connections required. The scalability of the approach is greatly restricted by the increased resource consumption. Different proposals exist for supporting multicast communication over ATM networks. Two popular ones are ■ ■

LAN Emulation (LANE) [104] IP multicast over ATM [7]

The ATM Forum is essentially responsible for the LAN Emulation; the IETF is promoting IP multicast over ATM. Above all, it is the Integrated Services Group (IntServ) of the IETF and the Multiple Protocols over ATM Group (MPOA) [11, 104] of the ATM Forum that are involved in the integration of IP and ATM.

5.2.2 LAN Emulation With the concept of LAN Emulation, an ATM network uses point-topoint connections to emulate a local-area network. This enables the support of services familiar from local networks. Therefore, the possibility exists for sending data units per broadcast to all users of a localarea network (or subnetwork in ATM networks). As was explained in Chapter 2, broadcasting can be interpreted as a simplification of multicasting. The downside is that it can lead to inefficiency in larger networks. However, since a number of communication services in local networks are based on broadcast, it has to be reproduced in ATM networks. A number of server functions are required for LAN Emulation so that the services familiar from local-area networks can be offered (see Figure 5.5): ■ ■ ■

LAN Emulation server (LES) Broadcast-and-unknown server (BUS) LAN Emulation configuration server (LECS)

5.2 ATM Multicast

177

IP Logical link control

UNI LES

LAN emulation Adaptation layer ATM layer

ATM end system

BUS ATM network

Physical layer Router LANE clients

LECS LANE server Figure 5.5 Components of a LAN Emulation.

The end systems that use the LAN Emulation service are referred to as LAN Emulation clients (LECs, not to be confused with LECS above). A LAN Emulation server is needed to handle address resolution. If a LAN Emulation client is not aware of the ATM address of the destination system, it sends a query to the server. The server maps the MAC address to the ATM address and sends the result as a response back to the LEC. The address information is temporarily stored in a cache in the client so that it is available for other communication requests. The LAN Emulation client directly establishes the ATM connection. The server is not involved in this process. As long as this connection is not established, the client can send data via the BUS. After initialization and contact with the LAN Emulation configuration server, each end system must register with the LAN Emulation server so that it can be integrated into the address resolution process. A broadcast-and-unknown server forwards multicast and broadcast data units received by the client over a special connection to all users in a subnetwork. Therefore, the nodes in the subnetwork that are not members of the addressed group also receive the multicast data units. Among other things, this increases the processing load in the attached systems since they have to filter the multicast data units according to their group membership. Furthermore, closed groups cannot be implemented because there is no way of preventing data units

LAN Emulation server

Broadcast-andunknown server

178

Chapter 5 — Multicast in ATM Networks

LAN Emulation configuration server

LANE restrictions

from being delivered to users outside a group. The responsibility for preventing this from happening lies with the local multicast filters in the individual systems. A broadcast-and-unknown server also has the task of forwarding data units with an unknown destination address. The LAN Emulation configuration server is responsible for the management of emulated LANs. New end systems must register with LECS, where they all receive further important information, such as ATM addresses for LAN Emulation servers. A LECS is available within each management domain. The LAN Emulation (LANE) concept has some restrictions associated with it. For example, the maximum length of data units is dependent on those of the underlying LANs (e.g., Ethernet). The maximum length of Ethernet data units is 1,500 bytes. This is considerably less than the length of those of the ATM adaptation layer AAL5 (65,536 bytes). Furthermore, LAN Emulation incorporates some serious disadvantages in terms of quality of service (QoS). The possibilities of ATM with respect to QoS cannot be exploited completely with LAN Emulation. Services with UBR and ABR are the only ones that can be used, because they are similar to the services of traditional local-area networks. Guaranteed services such as CBR for transmitting audio streams and VBR for sending compressed video streams cannot be used. Group communication support offered within the framework of LAN Emulation is embedded on the data link layer. For the most part, it uses broadcast mechanisms. LAN Emulation cannot be scaled for large networks. Therefore, it is not suitable for large ATM networks. The use of LAN Emulation is not limited to IP. It can be used in conjunction with other network layer protocols since the interface to these protocols is not changed compared to traditional LANs.

5.2.3 IP Multicast over ATM

IP unicast

A brief look at the basics of IP unicast over ATM precedes the presentation on proposed solutions for IP multicast over ATM. In the literature the approach is known as classical IP over ATM [73]. Users are connected to an ATM cloud through a user-network interface (UNI). This ATM cloud can in turn consist of different ATM subnetworks (see Figure 5.6). The subnetworks communicate with one another across an internal network interface called network-tonetwork interface (NNI). The end systems attached to the ATM cloud are identified through ATM addresses. In the context of IP over ATM,

5.2 ATM Multicast

UNI

179

UNI

NNI Private ATM

Public ATM WAN

Private ATM

ATM cloud UNI UNI Figure 5.6 ATM cloud.

these ATM addresses are interpreted as MAC layer addresses, thus as access point addresses. IP addresses form the basis for routing data units through the network. For the implementation of IP over ATM, a logical IP network that is independent of the internal physical structure of the ATM network is established on top of the ATM network. As is normally the case in IP networks, logical IP subnets (LIS) can be formed with IP over ATM. End systems that are attached to the same ATM cloud are grouped into these subnets (see Figure 5.7). The IP routers then operate as normal: Data for end systems in the same subnet is delivered directly, and data for systems in other subnets is forwarded across IP routers. This can lead to a situation in which data is forwarded across an IP router although the communicating end systems are connected to the same ATM cloud—but they are located in different logical subnets. Shortcut paths may be established to overcome this problem. In this case, the data takes an unnecessary detour. The end systems Barney and Fred in Figure 5.7 are an example. ARP servers (address resolution servers) implement address resolution between IP addresses and ATM addresses. This ATM-ARP server is essential because ATM networks are point-topoint networks without broadcast capabilities. If an end system requires the ATM address belonging to an IP address, it queries the ARP server. The ARP server responds to the query with the appropriate ATM address if the server knows it. During initialization, each system registers with the ARP server to ensure that it is aware of the mapping between IP and ATM addresses.

Logical IP network

180

Chapter 5 — Multicast in ATM Networks

Logical IP subnet Logical IP subnet IP router

ATM ARP server Fred

Barney

ATM cloud

Figure 5.7 Logical IP subnets over an ATM cloud.

IP multicast

Open groups

IP multicast (introduced in Chapter 3) serves as the basis for solutions regarding IP multicast over ATM. It is being expanded so that it can operate on top of ATM networks. The protocol IGMP for group management and routing protocols such as DVMRP are particularly important in the context of IP multicast. Development is basically guided by the premise that the IP multicast approach should remain as unchanged as possible. Therefore, a convergence layer that offers a traditional service interface [47] to IP, located on top of ATM, was introduced (see Figure 5.8). Multicast groups in IP multicast are open. Thus the sender is not always aware of all members. The IP layer assumes that the layers below it incorporate mechanisms for delivering multicast data. Receivers always join the group required. This is a receiver-oriented concept. By contrast, the point-to-multipoint service provided by the ATM signaling UNI 3.2 operates on the assumption that the sender is always aware of all current group members. A sender-oriented concept is applied. The sender explicitly identifies all receivers of a multicast data unit. A technique implementing IP multicast over ATM networks requires that the receiver-oriented concept of the Internet world be mapped to the sender-oriented concept of the ATM world. There are two approaches that support IP multicast over ATM:

5.2 ATM Multicast

IP Convergence layer Adaptation layer ATM layer Physical layer ATM cloud

Figure 5.8 Protocol structure in IP over ATM. ■ ■

IP multicast routers [35] Multicast Address Resolution Server (MARS) [6, 8]

Both approaches offer solutions for IP multicast over ATM in an intranet, which means that they are restricted to logical subnets. Multicasting approaches that operate across subnets are currently being discussed on the Internet.

IP Multicast Routers The concept of multicast routers is based on an IP router being equipped with additional functions of a multicast server for use in ATM subnets. This multicast router maintains multicast connections for all multicast groups in a subnet. Each system in the subnet has a virtual channel to the multicast IP router (see Figure 5.9). All multicast data from the transmitting end systems is forwarded on this channel to the multicast router. The multicast router is then responsible for distributing the data over the corresponding multicast connection to all group members in the subnet. Note that the sender receives the data again on this path. Therefore, suitable filter mechanisms have to be implemented in the end systems since the data should not be forwarded to the application at the sender.

181

182

Chapter 5 — Multicast in ATM Networks

Multicast forward

Multicast IP router

Local network Multicast send

Figure 5.9 Multicast IP routers.

No additional protocols

Group membership is managed on the basis of IGMP. Each system that wants to become a member of a group sends a corresponding IGMP data unit to the multicast router. This is how the multicast server becomes aware of the IP address of each group member. An address resolution procedure is used to determine the ATM address belonging to the IP address. The concept of IP multicast routers is restricted to usage of the IP protocol. However, there is the advantage that an IP router can become multicast capable for ATM through minor changes. No additional protocols are required in order to implement the concept. An additional node, namely, the multicast router, is introduced for local multicasts; that is, sender and receiver are located in the same subnet. This is considered to be a disadvantage because it increases the delay of the data being delivered to the receiver. Furthermore, a multicast router can easily become a performance bottleneck since all multicast traffic flows through it. It therefore represents a single point of failure, which is generally not desirable in distributed systems.

MARS Model

Address resolution

The concept proposed by the IETF for the implementation of IP multicast over ATM [3, 6, 7, 8] is called the MARS model because it is based on a multicast server for address resolution. It can be viewed as an extension of the ATM-ARP server, although it requires additional data formats and protocols.

5.2 ATM Multicast The MARS server keeps information about the mapping of multicast addresses of the network layer—for example, IP addresses—to a set of ATM addresses that identify the individual group members. The mapping information is temporarily stored in a cache. All IP and ATM end systems managed by a MARS server are combined into a cluster. A cluster initially has no direct relationship to logical subnets. However, the basic assumption is that all end systems located in a cluster belong to a logical subnet because of the routing of IP multicast. This assumption will most probably be relaxed as soon as other routing mechanisms are available. Furthermore, it must be taken into account that this cluster concept is designed for the current version of IP, IPv4. The mapping to the new version IPv6 has not yet been completely clarified. If a member joins a group, it first sends a MARS-JOIN data unit to the MARS server. The MARS-JOIN contains the ATM address of the joining member and the IP address of the group to which membership is requested. If a member leaves a group, it sends a MARS-LEAVE data unit to the MARS server. In both cases, the MARS server revises the information on group membership in its cache and notifies the group members of the changes. A MARS server maintains special control connections for this purpose. The group members must then also revise their locally cached group information. A change in group membership thus involves changes to the databases of group members. This can be a time-consuming task. MARS servers maintain two types of control connections (see Figure 5.10). Bidirectional point-to-point connections between MARS clients and the MARS server are used for requests from clients and the replies sent in response by the MARS server. Therefore, n MARS clients result in n point-to-point connections. The MARS server also maintains multicast connections to all MARS clients. Control data units from the server are sent over this multicast connection, for example, to update the database when a change in group membership takes place. This multicast connection is referred to as ClusterControlVC. If a sender wants to transmit data to a group of receivers, it first sends a request (MARS-REQUEST) to the MARS server to determine the ATM addresses of the group members. These are the ATM addresses that correspond to the IP multicast addresses indicated. A MARS-MULTI data unit is used to inform the sender of the addresses.

183

Address forming

Group join

Group leave

Control connections

Sending data

184

Chapter 5 — Multicast in ATM Networks

Cluster Control VC

MARS server

Local network

Figure 5.10 Connections with the MARS model.

MARS concept independent of IP

The sender stores these addresses in its own cache and establishes a multicast connection to all ATM addresses indicated. If the information requested is not available, the MARS server responds with a MARS-NACK data unit. The known communication services from the Internet world should be retained as far as possible. Therefore, multicast routers must be able to receive all multicast data units, irrespective of whether these data units are destined to the respective router or not. Consequently, routers are listed as members of all multicast groups (based on Class D addresses). They are listed as members even if no end systems in the corresponding subnet are members of the respective group. The multicast routers send a MARS-JOIN data unit that indicates a group of multicast addresses instead of an individual multicast address. In contrast to IP multicast routers, the MARS model is not dependent on the protocol used within the network layer. In principle, protocols other than IP can be used without any changes required to the basic model. A MARS server would then have to relate the addresses on the network layer to the ATM addresses of the group members. An example is the Network Service Access Point (NSAP) addresses from the ISO/OSI reference model [93]. Furthermore, it would be necessary to use the corresponding routing protocols. The rest of this chapter focuses on the network protocol on the Internet, thus on IP.

5.2 ATM Multicast

185

Within the framework of the MARS model, two versions are available for the implementation of multicast: ■ ■

VC mesh (Virtual Channel) Multicast server

VC mesh assumes that a mesh exists among all systems (see Figure 5.11). The sender establishes a direct multicast connection to group members. The information about group membership is provided by the MARS protocol. A direct connection between sender and receiver that enables an efficient delivery of data to receivers is an advantage. The individual paths can be optimized in each case—for example, in terms of delay. However, these direct connections present a major disadvantage of the VC mesh version because of the extensive use of resources needed to establish the connections (in this case, the virtual channels in ATM). For a group consisting of n senders and m receivers, it is necessary to establish and maintain n * m VCs. Keep in mind that ATM multicast connections are unidirectional. It also has to be noted that the signaling required for the ATM signaling protocol and the MARS protocol increases as the number of VCs rises. Furthermore, a change in group membership affects n multicast VCs because each sender has to make this change. Therefore, an adaptation is required to each multicast connection. To summarize, VC mesh is not easily scalable for groups with large numbers of members, but it is an attractive alternative for smaller groups.

Figure 5.11 ATM multicast over VC mesh.

VC mesh

186 Multicast servers

Low resource usage

Chapter 5 — Multicast in ATM Networks The multicast server version relies on the availability of one or several servers to support multicast communication in a network (see Figure 5.12). Multicast data is transmitted from the sender to a multicast server that is responsible for its further handling. The MARS protocol ensures that senders are notified of the address of the existing multicast server, instead of the ATM addresses provided by the VC mesh version. A sender routes the multicast data to a multicast server that forwards it to the group of receivers. If a sender is also a receiver in the group at the same time, it receives its own data again by the multicast server. This behavior is referred to as a reflection of data units. This is a problem for the protocols located in the layers above because they do not expect to receive their own data again. Therefore, special provisions have to be introduced below IP to enable reflected data units to be filtered and prevent them from being forwarded to the higher layers. As is the case with multicast routers, an additional hop is introduced with multicast servers in MARS if sender and receiver are located in the same subnet. This additional hop is necessary since no direct connection exists between them. In terms of resource use, a multicast server is preferable to the VC mesh. With n senders and g groups, only n + g connections are established. The signaling required when changes are made to a group is constant because only one multicast connection has to be changed. However, the problem with the server approach is that the multicast server (MCS) represents a

Multicast server (MCS)

Figure 5.12 ATM multicast per multicast server.

5.2 ATM Multicast

187

Table 5.4 Comparison of VC mesh and multicast servers. VC mesh

Multicast servers

Topology

Meshed

Multicast tree from sender, unicast to server

Reliability

Good

Single point of failure

Traffic concentration

No dedicated system

Multicast server

Data

Unchanged

Encapsulation required

Number of connections

n (multicast)

n (unicast) + 1 (multicast)

Resource requirements with n:n communication

High (n )

Moderate (2 * n) plus one 1:n

Administration required

High with changes to groups

Moderate

2

single point of failure. No multicast communication is possible if the MCS fails. Table 5.4 presents a comparison of VC mesh and multicast servers.

5.2.4 UNI Signaling ATM now offers a mechanism for multicast communication at the user-network interface (UNI). Versions UNI 3.0 and UNI 3.1, currently in use, are pure sender-oriented multicast services [6, 10]. UNI 4.0 [13] will be the first version in which the multicast service has been expanded. Members will be able to join or leave groups on a receiveroriented basis. UNI signaling is implemented at the user-network interface through the use of a well-defined connection: VPI = 0, VCI = 5. The UNI 3.1 specification is based on signaling protocol Q.2931 specified by the ITU-T. The ATM Forum simplified the protocol and expanded it to include options for the signaling of point-to-multipoint communication. These extensions enable the sender first to establish a point-to-point communication and then to add new receivers successively as leaf nodes. This feature is being expanded in UNI 4.0 to enable receiver-initiated join to groups. This new version of UNI signaling also provides multicast addresses as well as anycast addresses. The signaling of ATM networks is embedded in a special signaling AAL (SAAL) above the Service-Specific Convergence Protocol (SSCOP) (see Figure 5.13). SAAL is based on AAL5. SSCOP offers a reliable service with retransmission and window control.

188

Chapter 5 — Multicast in ATM Networks

Signaling protocol Q.2931

SSCF SSCOP Service-specific sublayer

AAL5 Common sublayer Segmentation and reassembly Signaling AAL Figure 5.13 Signaling AAL.

A multicast communication is established in two basic phases: ■ ■

Point-to-point connection

Setup of a point-to-point connection Addition of new members or deletion of members

Thus the sender always first establishes a point-to-point connection to a single receiver. Once this connection is available, other members can successively join the communication. A member may also leave an existing multicast communication. ATM thus supports dynamic groups, which is a function required by many applications. However, it may not scale for large groups since the setup procedure can introduce a considerably high delay. Figure 5.14 shows the setup of a point-to-point connection. At the user-network interface, the initiator sends a SETUP data unit to the network. First, the SETUP data unit is routed in the network to the destination system through the use of signaling protocols. Second, the first intermediate system in the network responds by sending a CALLPROCEEDING data unit back to the initiator. The destination system responds with a CONNECT data unit if it wishes to accept the connection. This data unit is forwarded to the initiator. At the same time the first intermediate system on the path to the initiator responds with a CONNECT-ACK. This means that the connection has been set up to the destination system. The initiator receives the corresponding CONNECT data unit and responds with CONNECT-ACK. This indicates that

5.2 ATM Multicast

ATM

Initiator Setup initiated

Destination

SETUP SETUP

CALL PROCEEDING

CONNECT CONNECT Connection established

189

Setup received

CONNECT ACK Connection established

CONNECT ACK

User-network interface (UNI) Figure 5.14 UNI signaling of a point-to-point connection.

the connection has been established on the side of the initiator. For simplification purposes, the example does not take failures into account (see instead the standards documents [10, 13, 39]). To set up a multicast communication, UNI signaling must incorporate dedicated mechanisms for the provision and maintenance of groups. For this purpose, unicast signaling essentially has been expanded to include the following service primitives at the user-network interface: ■ ■

Structure of a multicast communication

ADD PARTY DROP PARTY

A further distinction can be made between call, acknowledgment (ACK), and reject (REJECT). The same connection is used for multicast UNI signaling as for point-to-point signaling with VPI = 0 and VCI = 5. The options available with UNI 3.1 for multicast signaling are presented below, followed by the extensions introduced with UNI 4.0. ADD PARTY is used to indicate the addition of a new leaf node to an already existing group (see Figure 5.15). The root initiates the addition. This is the sender that set up the initial point-to-point communication. If the network is ready to establish the new connection, it forwards an ADD PARTY to the destination system. The destination

Group join

190

Chapter 5 — Multicast in ATM Networks

ATM

Initiator Setup initiated

Destination

ADD PARTY SETUP CONNECT ADD PARTY ACK

Setup received

CONNECT ACK

Connection established

Connection established

User-network interface (UNI) Figure 5.15 Addition of new group member.

Group leave

system constitutes a leaf node in the multicast tree. If the network cannot set up the connection, it transmits an ADD PARTY REJECT back to the root. The leaf node is not notified further in this case. The destination system receives a SETUP data unit from the network. This is the same procedure followed when a point-to-point communication is established. The SETUP data unit indicates that this is a multicast communication. The destination system responds either with CALL PROCEEDING or with PARTY ALERTING (see Figure 5.16). The latter is forwarded to the root in the network and signaled at the user-network interface so the root is notified. Once the connection has been accepted, the destination system sends a CONNECT to the usernetwork interface. The network acknowledges the CONNECT data unit—the same as if a point-to-point connection is set up. In addition, the CONNECT is forwarded across the network to the root. The root issues an ADD PARTY ACK to acknowledge that the destination system has been added to the group. Thus the addition of the new leaf node to the group has been successful. DROP PARTY indicates a leave from a group (see Figure 5.17a). Under normal circumstances, it is a user that initiates this. Therefore, a LEAVE is issued at the local user-network interface. The multicast communication is thereafter terminated for this user. The LEAVE is forwarded on the network toward the root. It is indicated as a DROP PARTY to the root if the user was not the last member of the group.

ATM

Initiator Setup initiated

Destination

ADD PARTY SETUP

Setup received

ALERTING PARTY ALERTING

CONNECT CONNECT ACK

Connection established

Connection established

ADD PARTY ACK

User-network interface (UNI) Figure 5.16 Group addition with alerting.

ATM

Initiator

Destination

RELEASE

(a) User-initiated leave DROP PARTY

RELEASE Confirm

DROP PARTY ACK (b) Network-initiated leave

DROP PARTY

RELEASE RELEASE Confirm

DROP PARTY ACK (c) Root-initiated leave

DROP PARTY RELEASE DROP PARTY ACK RELEASE Confirm

Figure 5.17 Group leave.

192

Chapter 5 — Multicast in ATM Networks

Group join with UNI 4.0

The root receives a RELEASE if it is the last member of the group. This way the request to leave a group reaches the sender of the call. The sender then acknowledges the user’s leave from the group by sending a DROP PARTY ACK. This also ends the call to this receiver for the sender. The receiver is therefore no longer a member of the corresponding group. The network can also initiate a leave from a group if problems in the network no longer allow communication with the user concerned. To do so, it signals a DROP PARTY to the root and a RELEASE to the receiver (see Figure 5.17b). The latter then terminates the communication relationship and sends an appropriate acknowledgment (RELEASE CONFIRM) to the network. The root acknowledges the interrupted communication to the receiver with a DROP PARTY ACK to the network. This indicates that the call to this receiver has been terminated for the root. If the root initiates the departure of a receiver from a group, it forwards a DROP PARTY to the network. This departure is acknowledged with DROP PARTY ACK at the local interface. The leave is signaled to the receiver with a RELEASE (see Figure 5.17c). With UNI 3.1, joins to a group can only be implemented through the root node, thereby making it a sender-oriented model. UNI 4.0 also allows receiver-based additions to a group without the involvement of the sender. The service it provides is therefore similar to the possibilities offered on the Internet by the RSVP signaling protocol. Two variants of receiver-based joins are available with ATM UNI 4.0 [13]: ■ ■

No notification of root

Join without notification of the root Join with acknowledgment by the root

The root selects the variant during SETUP of a virtual channel. The LEAF-SETUP data unit, which enables a leaf node to signal that it wishes to join a particular group, has been added to the process. Note, however, that a receiver-based join to a group is currently only supported at the user-network interface. There is no provision for it by the network internal protocols. If a leaf node is added to a group without notification of the root, the leaf node can generate a request for the addition per LEAF SETUP at the user-network interface (see Figure 5.18). The network will handle the request accordingly. A SETUP data unit is sent back to the leaf node joining the group. This is followed by a signaling procedure as

5.2 ATM Multicast

ATM

Root

Leaf node LEAF SETUP SETUP CALL PROCEEDING

Setup initiated Setup received

CONNECT CONNECT ACK Connection established

User-network interface (UNI) Figure 5.18 Addition without notification of root.

described previously. The leaf node sends a CALL PROCEEDING or a CONNECT, and the network acknowledges the join through CONNECT ACK. The receiver is therefore accepted into the group and can participate in the multicast communication. However, it cannot be guaranteed that the sender is still aware of all group members. The procedure described takes place if the group with the join request is already active. If the group is passive, the root is incorporated into the join process. In this case the LEAF SETUP is forwarded to the root (see Figure 5.19). The root responds by sending a SETUP data unit. Thus it initiates a process that is already familiar from UNI 3.1 for the integration of new members.

ATM UNI Signaling vs. RSVP The following differences between ATM and Internet protocols have to be taken into account with respect to resource reservations (see Table 5.5). With RSVP, resources are reserved on a receiver-oriented basis, whereas ATM works on a sender-oriented basis. With ATM, the management of a multicast connection is completely under the control of the sender. In a sender-oriented model the sender must always be aware of all current members. By contrast, the Internet uses a receiver-oriented

193

194

Chapter 5 — Multicast in ATM Networks

ATM

Root

Leaf node LEAF SETUP

LEAF SETUP SETUP CALL PROCEEDING

SETUP CALL PROCEEDING CONNECT

CONNECT

CONNECT ACK

CONNECT ACK

Figure 5.19 Receiver-based addition to a passive group.

Table 5.5 RSVP vs. ATM. RSVP

ATM

Connection concept

Connectionless

Connection-oriented

State management

Soft states

Hard states

Group entry

Receiver-oriented

Sender-oriented (receiver-oriented)

Quality-of-service model

Heterogeneous, dynamic

Homogeneous, static

model. This involves anonymous groups since the sender is not informed at all times of the precise membership of a group. The QoS characteristics of an ATM connection are established during connection setup and continue for the entire duration of a call. These reservations are also referred to as hard reservations. With RSVP, the QoS is independent of connection setup and can change dynamically during the course of a call. In contrast to ATM, RSVP offers no hard guarantees and instead works with soft states. These soft states have to be renewed periodically so that they are not deleted.

5.2 ATM Multicast Furthermore, ATM is based on a homogeneous quality of service for all receivers of a multicast group. The RSVP concept is based on a quality of service per receiver. This means that different receivers involved in a multicast connection can negotiate different agreements with respect to quality of service. Therefore, the QoS concept of RSVP supports dynamically changing heterogeneous quality-of-service requests within a group. Furthermore, RSVP is capable of merging resource requests dependent on the filter requirements being signaled. ATM does not provide any similar support in its current status.

195

This Page Intentionally Left Blank

6 Transport Protocols

T

he transport layer is located above the network layer. Whereas the network layer basically handles routing, in multicast communication the transport layer is responsible for tasks very similar to those in point-to-point communication. These tasks mainly include connection management, error detection and recovery, and flow and congestion control. However, group communication places new demands on protocol mechanisms. Therefore, the mechanisms used in unicast cannot always simply be applied to group communication. Moreover, in the context of reliable group communication, the strict protocol layering is loosened more and more. Examples are protocols that use routers to achieve reliability (e.g., PGM) or approaches that follow the ALF design principles [41], where transport functionality is, at least to some extent, realized at the application layer. An example of the latter is SRM. The aspect of reliability takes on a special significance in the context of group communication. This chapter therefore primarily focuses on reliable multicast protocols. What is important to bear in mind when considering multicast protocols is that not one single multicast protocol has yet managed to establish itself and gain acceptance as the standard protocol. There are a couple of reasons for this. First, the tasks requiring the use of group communication differ considerably. A single protocol would not be able to satisfy all the varying requirements. Second, we do not know enough today about the effect of group communication on the different protocol functions. Therefore, generally accepted mechanisms and algorithms needed for a multicast transport protocol are not always available. The background information required for understanding the protocols introduced in this chapter was provided in Chapter 2. Consequently, the only term to be introduced in this chapter is connection context. This comprises all information that is important for the status of a connection. In the context of reliable transport protocols, the

Reliable multicast protocols

One-size-fits-all solution does not exist

Connection context

198

Chapter 6 — Transport Protocols notion of an association is used instead of a connection because many reliable multicast protocols do not incorporate any explicit connection establishment phases. The connection context includes information like source and destination address for the connection, the current sequence number, and user data that has not yet been acknowledged.

6.1 UDP User Datagram Protocol (UDP) [126] is part of the Internet protocol family. It is a connectionless protocol that can be used for unreliable transmission of data units. Therefore, it does not offer the sender a possibility of determining whether the receiver has correctly received the data unit. Flow control or similar mechanisms cannot be implemented either since a connection context does not exist. Nevertheless, the socket interface permits connect() calls for UDP sockets. But these calls only permanently set the destination address for subsequent data units being sent with that socket. However, no connection is established and no other status information is stored on behalf of the connect() call. Group management is also not provided for UDPbased multicast communication. Yet UDP has to be mentioned in this book because many of the multicast protocols presented are based on UDP. The reason for this is the architecture of the data communication systems for which the protocols are being developed. These systems normally do not allow direct access to an IP service. Therefore, the detour of a “double” transport layer is being accepted in the development of new protocols. Moreover, some multicast protocols make use of the multiplexing functionality of UDP instead of reimplementing it. UDP is a very basic protocol that only incorporates a small number of protocol functions. Its most important function is the provisioning of transport layer addresses. In the layer model of the Internet, such an address consists of a port number that is unique within the UDP entity and identifies the communication end point (on Unix machines normally a socket) to deliver the data to. This address, together with the network layer address, enables a unique identification of sender and receiver in the global network. Actually, since TCP also uses port numbers, the next_protocol field of the IP data unit is additionally considered to distinguish between UDP and TCP end points that are bound to the same port number.

6.1 UDP If an IP unicast address is provided with UDP, the communication becomes a point-to-point communication. On the other hand, if an IP multicast address is used as the destination address, the data unit is transmitted per IP multicast. In this sense, UDP is both a unicast as well as a multicast protocol. UDP is suitable for group communication because no modification to protocol functions is necessary. This does not apply to TCP (Transport Control Protocol) [125]. TCP plays an important role in the Internet, where it provides a reliable transport service. However, the protocol functions used by TCP, especially those for connection setup and release, are not designed for group communication. Therefore, TCP is purely a unicast protocol that cannot easily be extended to a multicast protocol.

6.1.1 A Programming Example The following example in programming language C can be run as shown on Unix systems. If it uses a Winsock interface, with some minor modifications it can also operate on Windows NT, Windows 95, and Windows 98. This simple example illustrates how data can be sent and received per IP multicast using UDP. But some requirements must first be met for this example to work. First of all, the participating systems must be multicast enabled. This means that the computer operating systems must be equipped with multicast support for the IP protocol. In addition, a multicast-enabled router is needed if IP multicast data units are to be sent or received outside the local network. A multicast receiver must undertake the following steps: ■ ■

■ ■ ■

Open a UDP socket. Bind the socket to the port number to which the sender transmits data. Join the multicast group. Receive data. Close the socket at the end of the communication. These steps are necessary for the multicast sender:

■ ■ ■

■

Open a UDP socket. Set the TTL value. Send data to the provided group address with the corresponding port number. Close the socket at the end of the communication.

199

200

Chapter 6 — Transport Protocols

Program 6.1 Declarations. #include #include #include #include



#define GROUP_ADDRESS 224.100.100.100 #define GROUP_PORT 8888 #define DATA_LEN 1024 int

struct sockaddr_in struct ip_mreq char

/* Group multicast address */ /* Port number */ /* Buffer length */

s, /* ttl, /* retVal, /* len, /* radrLen; /* adr, radr; /* mreq; /* data[DATA_LEN+1]; /*

Socket descriptor */ TTL value */ Return value */ Received bytes */ Length of address */ Address structure */ Structure for IGMP join request */ Buffer */

The declarations for the program fragments are given in Program 6.1. The multicast group address and the UDP port number, which together identify the communication transmission point, have been selected arbitrarily for this example. Any other nonreserved class D address could be used as the multicast group address. But keep in mind that the address could be associated with an administrative scope (see Chapter 3), or if address allocation is in effect, addresses cannot be freely selected. The program fragment also gives the C header files required for Unix systems and provides declarations of the variables used in the following program fragments. A socket must be opened by the sender and by the receiver (see Program 6.2). It constitutes the communication end point. Only the multicast receiver is required to bind the socket to a port number. In the case of WinSock this is slightly different, since no socket options can be set for an unbound socket. Since UDP supports multipeer communication, the same socket can be used to receive and to send data. However, the steps described above must be taken to bind the socket and to enable a group member to join the multicast. The socket is bound to the group address to enable kernel filtering (see Program 6.3). This prevents the user from receiving unicast UDP datagrams addressed to the host with the same port number. The

6.1 UDP Program 6.2 Opening a socket. s = socket(AF_INET, SOCK_DGRAM, 0); if (s < 0) { fprintf(stderr, “Can’t create socket\n”); exit(1); }

Program 6.3 Binding of a socket. adr.sin_family = AF_INET; /* Protocol family */ adr.sin_addr.s_addr = inet_addr(GROUP_ADDRESS); /* Address to bind the socket to */ adr.sin_port = htonl(GROUP_PORT); /* Port number */ retVal = bind(s, (struct sockaddr*) &adr, sizeof(struct sockaddr_in)); if (retVal < 0) { fprintf(stderr, “Can’t bind socket\n”); exit(1); }

port number that is assigned to the socket also has to be specified. The sender specifies this port number as the destination port when data is sent. The receiver can use the port number to identify the socket where the data is delivered. At this point it is not yet possible to receive multicast data units. The user first has to become a member of a multicast group. The multicast address is entered into the structure mreq. The local IP address of the network interface is also required. In the example shown, the constant INADDR_ANY is used as the interface address. This indicates that the standard interface should be used. An interface from the system could also be indicated explicitly, but this is normally not necessary. The invocation setsockopt causes the system to generate an IGMP data unit in order to join the multicast group (see Program 6.4). Note that for WinSock, the socket must be bound before any options can be set with a call to setsockopt. It is important for the sender to set the TTL value (see Program 6.5), since the standard value for the TTL for IP multicast data units is

201

202

Chapter 6 — Transport Protocols Program 6.4 Joining a multicast group. mreq.imr_multiaddr.s_addr = inet_addr(GROUP_ADDRESS); mreq.imr_interface.s_addr = INADDR_ANY; retVal = setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq)); if (retVal < 0) { fprintf(stderr, “Error in setsockopt\n”); exit(1); }

Program 6.5 Setting the TTL value. ttl = 15; retVal = setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, (char*) &ttl, sizeof(ttl)); if (retVal < 0) { fprintf(stderr, “Can’t set TTL value\n”); exit(1); }

1. If the TTL value were not increased, the data units would not leave the local subnet because of TTL scoping. But again, the choice of the TTL value depends on the application, and the value 15 should be seen as an example only. A sendto invocation that provides the IP multicast address and the number of the destination port is used to transmit data (see Program 6.6). The port number is the one to which the receiver’s sockets are bound. In this example, the data is finally received as the result of a recvfrom invocation (see Program 6.7). The address is not required because the necessary information was already provided when the socket was bound and the multicast group was joined. The invocation close(s) closes the socket when the communication ends. A call to setsockopt with the option IP-DROP-MEMBERSHIP can be used to leave the multicast group explicitly. In version 2 of the IGMP protocol, this invocation triggers the generation of a hostmembership-leave data unit that allows the explicit leaving of a

6.1 UDP Program 6.6 Sending to a multicast group. adr.sin_family = AF_INET; /* Protocol family */ adr.sin_addr.s_addr = inet_addr(GROUP_ADDRESS); /* Address to bind the socket to */ adr.sin_port = htonl(GROUP_PORT); /* Port number */ retVal = sendto(s, data, dataLen, 0, (struct sockaddr *) &adr, sizeof(adr)); if (retVal < 0) { fprintf(stderr, “Can’t send\n”); exit(1); } else { printf(“%d Bytes sent\n”, retVal); }

Program 6.7 Receiving multicast data. len = recvfrom(s, data, DATA_LEN, 0, (struct sockaddr *) &radr, &radrLen); if (len < 0) { fprintf(stderr, “Can’t receive\n”); exit(1); } else { printf(“%d Bytes received\n”, len); }

multicast group. The socket interface provides other options that are especially important in the context of multicast. The options SO_REUSEADDR and SO_REUSEPORT enable binding of more than one socket to the same address or port. This feature is useful, for instance, if two applications running on the same host participate in the same group communication.

6.1.2 Summary UDP is a universal and widely used unreliable transport protocol for both unicast and multipeer communication on the Internet. Its protocol functionality is limited to multiplexing. It does not provide flow control, ordering, or error control as it provides an unreliable service only.

203

204

Chapter 6 — Transport Protocols

6.2 XTP XTP (Xpress Transport Protocol, formerly Xpress Transfer Protocol) was designed by Strayer, Dempsy, and Weaver [147]. XTP was originally developed for high-performance networks. As a result, the protocol mechanisms and data formats were designed so they could easily be implemented into hardware. The developers claimed that a hardware-based implementation of the protocol would provide higher data throughput than a pure software-based version. Other aspects of the implementation were taken into account in order to provide an efficient solution. The formats were defined so that 4-byte fields are aligned on 4-byte boundaries and 8-byte fields are aligned on 8-byte boundaries. Moreover, the lengths of all fields are multiples of four. This protocol deserves attention for a variety of reasons. First of all, XTP is one of the first systematic attempts to trim a protocol for performance enhancement. Second, XTP offers a variety of advanced protocol mechanisms. This aspect is still important today. A particular feature is that many protocol mechanisms can be selected separately. This enables XTP to be adapted easily to meet the requirements of different applications. Furthermore, a strict separation exists between control data and user data flow. Consequently, unlike TCP, user data units do not contain acknowledgments for the receiving direction. In addition to transport layer functions, up to version 3.7 XTP also includes network layer functionality. It had been established that some protocol functions were frequently being implemented in multiple layers. Therefore, the goal was to integrate the network and transport layer functions across layers to prevent this situation from continuing and to improve the efficiency of protocol processing. However, this fundamental approach did not succeed because it would have meant replacing the IP protocol on the Internet, and this would have affected all intermediate systems on the global Internet. An introduction of XTP would have necessitated extensive modifications to the existing Internet infrastructure. Another approach to the deployment of XTP is to use it on top of IP, in which case the network layer functions become superfluous. As a result, no network layer functions have been included in version 4.0 [166], the current version of XTP (and the last, since development for XTP has recently stopped). As of this version, XTP represents a pure transport protocol. A more recent version, 4.0b [167], has addressed the multicast problems of version 4.0 and provides different levels of reliability. A summary of the changes can be found in [14].

6.2 XTP The aim of XTP was to design a protocol that would meet the requirements of new applications. Therefore, XTP was at first a unicast protocol, but multicast functionality has been added to XTP in order to support group communication. The treatment of XTP in this book will be mostly restricted to the mechanisms for group communication. XTP does not support multipeer communication. Instead it implements a reliable multicast service. The XTP multicast service operates on a sender-oriented basis. Hence, the sender mostly controls the protocol functions. This also applies to error control, which includes the risk of acknowledgment implosion. XTP is therefore not suitable for large groups.

6.2.1 Data Units This section provides a brief introduction to the data units that appear in the discussion on protocol mechanisms. With XTP a differentiation is made between information and control data units. The information data units include ■ ■ ■

DATA: user data unit FIRST: connection setup data unit DIAG: data unit for error notification

The control data units since version 4.0 are ■ ■ ■ ■

CNTL: general control data units ECNTL: error control data units TCNTL: traffic control data units JCNTL: control data unit for the join process to a multicast group

6.2.2 Connection Control Connection control is mainly implemented through the use of three flags in the header of each XTP data unit: ■ ■ ■

RCLOSE WCLOSE END

The sender of the data unit uses an RCLOSE flag to indicate that it is not accepting any more user data and that the receiving direction is

205

206

Chapter 6 — Transport Protocols therefore closed. At the same time, the sender of the data unit signals with a WCLOSE flag that it will not be sending any more user data. But it can continue to receive data. Thus, with XTP the transmitting and receiving directions are largely independent of each other. The END flag is only used to signal the setup or the termination of a connection.

Connection Setup

Known and unknown groups

The sender initiates connection setup. It starts by sending a FIRST data unit to the multicast group. In addition to the addresses of the sender and of the multicast group, it contains different traffic parameters that control the protocol functions. In this context the option bits in the header of the data unit are particularly important. By setting a MULTI bit the sender indicates that the connection is a multicast connection. Furthermore, the RCLOSE bit set in the header indicates that the sender is not accepting any user data; thus the receiving direction is closed. XTP supports known and unknown groups. In order to establish a known group, the source sets the SREQ bit in the FIRST data unit, which indicates to joining members to respond to this FIRST data unit. Otherwise, the receivers join silently and the sender does not care about membership. In this case, the purpose of the FIRST data unit is to communicate connection parameters. The following discussion applies to known groups. If a listening host receives a FIRST data unit for connection setup, the XTP entity responds to the host with a JCNTL data unit, thus joining the connection (see Figure 6.1). This data unit is addressed per unicast directly to the multicast sender, thereby reducing the network load. However, this also means that the other group members are not aware of the membership of the group. Like the FIRST data unit, the JCNTL data unit contains traffic parameters in addition to the addresses. These enable a receiver to reduce the traffic parameters associated with the connection if they appear too high or cannot be fulfilled by the receiver. If, on the other hand, the host does not want to accept the connection because the traffic parameters are not acceptable or for some other reason, it responds with a DIAG data unit instead of a JCNTL data unit. It therefore rejects the connection. The data unit contains a reason for the rejection. The sender must now issue a JCTNL data unit to complete the exchange. This data unit is sent directly to the respective receiver. The connection setup procedure described above only allows receivers to join at the beginning of a connection. XTP also supports a

6.2 XTP

Sender

207

Joining receivers

FIRST

JCNTL JCNTL JCNTL JCNTL

JCNTL

JCNTL

DATA

Figure 6.1 Multicast connection setup.

late join (see Figure 6.2). In this case, the respective host sends a JCNTL data unit to the multicast group. If the host is to be added to the connection, the multicast sender responds with a JCNTL data unit per unicast to the receiver.

Connection Release Because the XTP multicast service relies on receiver lists, explicit connection release is required in addition to explicit connection setup. Three possible scenarios exist: ■ ■ ■

A single receiver leaving a group Orderly release by the sender End of connection

Late join

208

Chapter 6 — Transport Protocols

Sender

Receivers

Joining receiver JCNTL

JCNTL

DATA

Figure 6. 2 Late join.

Leaving a connection

Graceful connection release

To leave a group, a receiver issues a CNTL data unit with a special identifier (an END bit set in the header of the data unit). Like all control data units, this data unit is sent per unicast directly to the multicast sender. The multicast sender thereupon removes the receiver from the list of active receivers. For its part, the receiver moves into a waiting state for a certain period of time after the control data unit is sent. When it is in a waiting state, it only responds to the sender’s data units that are directed to the unicast address of the receiver. Therefore, although the receiver is no longer participating in the multicast connection, it must continue to respond to data units from the multicast sender. The reason is that the CNTL data unit could be lost. Therefore, the sender may not have been able to take into account the receiver’s request to leave the connection. The receiver context therefore retransmits the CNTL data unit until the sender has acknowledged its request to leave the group or the number of repeats has exceeded a certain threshold. The aim of XTP is to provide a reliable transport service. This also requires the connection release process to operate in an orderly way. Therefore, before a connection is released, it is essential that each

6.2 XTP

Receivers

Sender WCLOSE, RCLOSE WCLOSE,RCLOSE

WCLOSE,RCLOSE WCLOSE,RCLOSE WCLOSE, RCLOSE, END

Figure 6.3 Sender-initiated connection release.

receiver has correctly received all transmitted data and no retransmission is required. With XTP, connection release is basically controlled through the use of the flags WCLOSE, RCLOSE, and END. The multicast sender initiates connection release (see Figure 6.3) by setting a WCLOSE bit in the header of the data unit. The sender thereby makes it known that it is closing the transmit direction and would like to end the connection. The RCLOSE bit is set already because XTP only supports pure multicast. Therefore, only a single sender and a single transmit direction exists. When it receives the WCLOSE data unit, the receiver checks whether data is still missing to determine if any retransmission should be requested. If this is not the case, the receiver context transmits a CNTL data unit with a set RCLOSE bit. Thus it accepts the request of the multicast sender to release the connection. If the multicast sender has received the corresponding acknowledgments from all active receivers, it issues a data unit with a set END bit. The connection release is thereby completed and the sender context moves into the waiting state for a certain period of time. Incoming data units can still be assigned to the connection and, if necessary, response packets generated during this waiting state.

209

210

Chapter 6 — Transport Protocols

Connection Termination With the orderly connection release described in the previous section, a handshake ensures that data is delivered correctly to all active receivers. Connection termination, on the other hand, cannot provide these same guarantees. It takes place without a handshake and the sender immediately freezes the context. The multicast sender initiates the connection termination by setting an END bit in the option field of the data unit header. It then moves to a waiting state for a specific period of time. The receiver behaves in a similar manner after it receives this data unit. The data unit is not acknowledged and the context is frozen, irrespective of any outstanding data.

6.2.3 Data Transfer XTP provides a number of protocol functions for data transfer. As is the case with the XTP functions discussed previously, the design ensures that the mechanisms can also be used, preferably with no changes, for multicast communication.

Flow and Rate Control

The slowest receiver determines the sender’s credit

XTP uses the sliding window method as a flow control mechanism. With this mechanism, a receiver grants the sender a transmission credit in the form of a flow control window. The values of the window result from the sequence number and the size of the window in bytes. They are transmitted in the rseq and alloc fields. The credit only applies to pure user data. The headers of the data units and control units are not considered. The same applies to retransmissions since buffer space was already reserved for this data with the receiver during the initial transmission. With unicast protocols, window-based flow control is frequently implemented as described. TCP is an example [125]. With unicast communication, however, only a single receiver is involved. Therefore, the credit only applies to the one receiver that has granted the credit and makes no reference to the other receivers. XTP uses a very basic mechanism to determine the transmission credit for an entire group: the slowest member determines the credit granted. The sender determines the volume of data that still may be sent without requiring acknowledgment by collecting the credits from all receivers. The upper edge of the window is assigned to the lowest value of all received credits. Therefore, the receivers are not processed

6.2 XTP individually. Instead, the group as a whole is considered during negotiation of the protocol parameters. This procedure is easy to implement but does have a major disadvantage: a receiver with a small receive buffer and, consequently, a smaller window affects the entire group. The length of transmission delay becomes a problem in this example. This sender will have to stop transmission after a short period of time when the credit from the receiver runs out. The credits from the other receivers, on the other hand, would have allowed transmission to continue. The achievable data throughput is therefore reduced all other receivers. Note that flow control is not necessarily required. A flag in the header of the data unit deactivates flow control. The sender sets this flag to indicate to receivers that it is ignoring flow control. Like flow control, rate control is a mechanism that is designed to prevent overloading at the receiver. Another task of rate control is to prevent congestion in the network. A major difference between the two mechanisms is that rate control can normally manage without direct feedback. This means it does not require any further synchronization between sender and receiver. Therefore, it can also be effective when congestion exists and communication between partner entities is no longer possible; hence, feedback from the receivers is not available. According to the basic principle of rate control mechanisms, the receiver specifies a rate—for example, in data units or bytes per unit of time—that the sender may transmit during this unit of time. If the quota is used up before the end of the interval, the sender is blocked until the end of the interval. Depending on the type, the mechanisms vary in the granularity of the time interval and how the rate is specified or adapted. In XTP the rate is controlled by two parameters—rate and burst. The first parameter gives the maximum data rate in bytes per second; the second one provides the maximum number of bytes that may be sent within a time interval. The length of the time interval results in a quotient of burst and rate. This value is used to initialize a timer, the RTIMER, which monitors the passing of the time interval. Similar to flow control, the sender collects the rate control parameters of all active contexts. It establishes the respective minimum rate based on all burst and rate values. Therefore, it is as easy to implement rate control in multicast as it is flow control. Again it is the weakest members that determine the rate for all others.

211

Deactivation of flow control Rate control

212

Chapter 6 — Transport Protocols

Error Control and Reliability

SREQ

FASTNAK

Spans and gaps

XTP uses checksums and sequence numbers for error control. Faulty transmissions are identified through checksums. If a data unit with an incorrect checksum is received, it is discarded and no further action is taken. The checksum is determined for all data units. A flag in the header of the data unit indicates which part of the data unit is protected by the checksum contained in the data unit. If the flag is set, it means that only the header of the data unit was considered in the calculation of the checksum. Otherwise it was calculated over the entire data unit. The user data in information data units is not protected in the first instance. Receivers can use the sequence number to detect lost packets, misordering, or duplicate packets. However, the sequence numbers only protect user data units. This kind of protection is not afforded to control data units. With XTP, the acknowledgment process is sender-controlled through the use of selective, negative acknowledgments. “Sendercontrolled” means that receivers only send acknowledgments if the sender has requested them to do so. The sender implements this request by setting a flag in the header of the data unit (SREQ). Note, that even if the group is unknown, this does not prevent the sender from setting the SREQ bit. Thus, some level of error detection and recovery is possible, but reliable reception cannot be guaranteed. Moreover, XTP offers another option if a transmission error is detected. A sender can set an additional flag in the header of the data unit (FASTNAK) to signal receivers to send a negative acknowledgment even if no previous request has been received. The acknowledgment consists of an error control data unit sent per unicast to the sender. The data still missing is identified by spans in the data unit. A span consists of pairs of sequence numbers indicating ranges of correctly received data. The first value of each pair indicates the bottom limit of the range; the second one, the top limit, which is one higher than the highest sequence number for that span. Data that has not been received correctly can be determined from the list of spans. This data is identified by the gaps between the spans. An example appears in Figure 6.4. All data with lower sequence numbers has been received correctly up to the value rseq. In the example shown, this data is in the range 0 to 399. The first span begins with sequence number 600 and ends with 800. The data in the sequence number range 600 to 799, inclusively, has consequently been received correctly.

6.2 XTP Gap1

0..............................399

400..599

rseq

213

Gap2

600..799

Span1

800..899

900..1099

Span2 Figure 6.4 Spans and gaps.

The data from 400 to 599, on the other hand, is defective or has not even been received. Therefore, this data creates a gap. The same applies to data in the range 800 to 899; it too creates a gap. The multicast sender collects the acknowledgments and, if necessary, merges the spans from all receivers into one list. The sender then retransmits all requested data per multicast to the group of receivers. The error control mechanism involves the risk of acknowledgment implosion and is not scalable for large groups. To alleviate the problem somewhat the authors suggest a technique called slotting and dumping. Slotting means that receivers do not send acknowledgments immediately upon receipt of the request. Instead it is recommended that receivers first wait a variable number of time slots. Dumping means that receivers listen to NAKs from other receivers and suppress their own NAK if the gap has already been announced. Thus the transmission of acknowledgments is spread out and the load on the network and sender is distributed.

6.2.4 Summary Although the current version of XTP is a unicast transport protocol, it provides support for reliable multicast. A rate control is used to prevent receiver overrun without feedback. XTP can realize a reliable service if group membership is known. Reliability is achieved through cumulative, selective negative acknowledgment and retransmissions. But acknowledgments are triggered by the sender, which involves the imminence of NAK implosion. A technique called “slotting and dumping” is proposed to lower that risk, but the implementation is not mandatory. XTP may incorporate a substantial delay, since every receiver must have received all data correctly. Thus, receivers experiencing a high loss rate can either block the current communication or a very large sending buffer is needed to avoid this. Retransmissions are

Slotting and dumping

214

Chapter 6 — Transport Protocols always sent by multicast; thus, synchronized receivers are bothered with unwanted retransmissions and bandwidth may waste if the number of unsynchronized receivers is small. Hence, in the reliable mode XTP does not scale very well for large and possibly heterogeneous groups.

6.3 MTP

Ordering

Web

MTP (Multicast Transport Protocol) was introduced in [9] and represents a very early proposal for the implementation of group communication on the transport layer. It implements a semireliable multipeer transport service with global ordering. Hence, MTP provides mechanisms for ensuring that all data is delivered to all receivers correctly and in the same sequence. However, there is no guarantee that the entire group will receive the data in every case. MTP was designed for use on the Internet. The protocol for the transport of user data is based on an unreliable multicast or multipeer-enabled network service as provided by IP multicast, but implementation is easier for multipeer network services. To exchange control data units, the protocol also requires a unicast network service. The unicast service can likewise be an unreliable service. An important feature of MTP is ordering, which is implemented through the use of a token determining transmission rights. Only the host with the token has the right to transmit data. Moreover, MTP, like XTP, offers rate-based flow control. With MTP, a communication group is referred to as a web. The members of such a group are not ranked equally and have different tasks depending on their roles. Three roles are differentiated: ■ ■ ■

Master

Producer

Master Producer (sender) Consumer (receiver)

Each web has exactly one master. This master controls the web. It decides whether a user is accepted into a multicast group, grants tokens, monitors the reliable transmission of data, and ensures that ordering is maintained. Moreover, a master can also take part in a connection as a producer. A producer sends data units to a group of receivers and receives control data units from these receivers. It therefore acts as a multicast

6.3 MTP sender. The producer also receives data units from other producers and sends control data units. Since MTP supports multipeer communication, multiple members can incorporate this role within a web. A consumer only receives data units from producers of the multicast group. On its own, the consumer cannot send user data units but only control data units. The role of a participant is constituted during the join procedure, and the roles are fixed for the duration of group membership. To change its role, a participant has to leave and rejoin the group.

215

Consumer

6.3.1 Structure of a Web With MTP, a web first has to be set up before data can be exchanged. The master is responsible for monitoring the web. The first member joining the web assumes the role of master. However, it is important that only one member is actually functioning as the master in the web. To ensure that this is the case, the member sends a control data unit (JOIN-REQUEST) for connection setup to the web. If the member does not receive a response despite multiple attempts at retransmission, it assumes that no other master exists for this web. Thus it becomes the master of the web from that point onwards. It is now ready to operate. There might occur situations where two or more participants regard themselves as a master. This may happen if, for instance, multiple participants join at the same time or if because of network failures two participants cannot receive data units from each other but other participants are able to communicate with both of them. If a member detects such a protocol violation, it may ask the offending process to withdraw from the web by unicasting a QUIT-REQUEST data unit to this process. On receiving a QUIT-REQUEST data unit, a process should respond with a QUIT-CONFIRM data unit and leave the web. However, this mechanism cannot guarantee that only a master will operate in a web. For example the banishment might end up with no operating master at all. Moreover, data consistency might be disturbed because of different acceptance vectors (see below). And, finally, the redundant receivers have to leave and to rejoin the web. The time it takes to complete a leave and rejoin may exceed the retention interval; thus, the participant may miss some data. Other members may join the web at any time. Again, the member sends a JOIN-REQUEST data unit to the multicast address of the web. An indication is given in the data unit of the role the member wants to

Who is the master?

216

Chapter 6 — Transport Protocols assume. The member also specifies which reliability class it is requesting. MTP supports two classes: ■ ■

Unreliable Reliable

An unreliable service does not offer error handling and only provides a best-effort service. In contrast, a reliable service implements error handling, and if this is not successful, ensures that the user is informed accordingly. Another quality-of-service parameter specifies whether the transport service requested should support an n:m communication or only a 1:n communication. In the latter case only a single sender exists in the web. Lastly, the data unit contains information about the minimum requested throughput in kbytes/s and the maximum size of a user data unit. The master responds to this data unit per unicast to the members. A JOIN-CONFIRM data unit signifies the acknowledgment of a request; a JOIN-DENY data unit indicates a rejection. A request to join the web will be rejected if one of the various quality-of-service parameters cannot be in agreement with those of the web. Thus, for example, a join request is rejected if a member wants to join the web as master or a member wants to join an existing web with 1:n communication as another producer.

6.3.2 Allocation of Transmission Rights

MTP messages

The data assigned from an application to MTP for transmission forms a message. If the message is larger than the maximum size of the data units, it has to be divided into multiple data units. However, the message boundaries remain transparent to the receiver, as will be explained later. A producer may only send user data units that are part of a message if it is in possession of the token allocated to this message. Therefore, a message sequence number is assigned to a message. If a producer wants to begin a message, it has to request a token with a TOKEN-REQUEST data unit. As with all control data units, with MTP the request is sent per unicast directly to the master and is repeated periodically until the master has supplied the token. When appropriate, the master grants the token with a TOKEN-CONFIRM data unit

6.3 MTP containing the message sequence number associated with that token. Requests for tokens by different producers can overlap. MTP does not provide an explicit mechanism that ensures a fair allocation of tokens. The master administers a status for each token, with each status capable of assuming three values: ■ ■ ■

IDLE PENDING BUSY

A token is in IDLE status if no token has yet been allocated to the message sequence number and the message sequence number does not fall within the range covered by the status vector. A token is in a PENDING status if it has been allocated but the master has not yet received a user data unit from the respective producer. Hence, the master cannot determine whether the producer has accepted the token or whether the token has been lost. An allocated token is given a BUSY status if the master receives user data units with the corresponding message sequence number. The master responds to token requests according to the token status. A token cannot be allocated if it is in IDLE status. This would necessitate removal of the status of a not-yet-accepted message from the status vector because the status vector can only contain the status of 12 messages. In PENDING status, the master reallocates the token after each request since it is not apparent to the master whether the control data unit used to assign the token was received. In BUSY status, the master rejects each new request for the token because it is likely to be a delayed token request. If a producer ends a message, it releases the token. The token is released with the last data unit of a message, in which case an appropriate flag is set. Alternatively, if the producer does not want to send user data anymore, it releases the token by sending periodic control data units.

6.3.3 Data Transfer With MTP, the key protocol processes are controlled by three qualityof-service parameters that are negotiated or established during web setup. These quality-of-service parameters are important for describing the different protocol mechanisms of MTP. Therefore, they are introduced briefly here:

217

218

Chapter 6 — Transport Protocols ■ ■ ■

Heartbeat

Window Retention

Rate control

End-of-window flag

Heartbeat Window Retention

The heartbeat parameter specifies a time interval in milliseconds. This value is the same for all participants in a communication and is used to monitor rate control as well as error control. The significance of this parameter is explained in more detail below. The window parameter specifies the maximum number of user data units that a producer may issue during a heartbeat interval. Lastly, the retention parameter specifies the number of heartbeat intervals during which a producer must retain buffered data for retransmissions. Therefore, MTP obviously only implements a semireliable service since no response to negative acknowledgments is possible at the end of this interval. The probability of unsuccessful transmission can be reduced to a minimum through a sufficiently high setting of this value. If a host possesses a token, it has the right to send user data per multicast to a group (DATA data units). The data units contain the message sequence number, which is the same for all data units of the message. They also contain a packet sequence number, which is incremented for each new user data unit. The data transfer process is illustrated in Figure 6.5. Rate control is applied during data transfer to protect receivers and the network from overloading. During a heartbeat interval the producer may only transmit as many user data units as are indicated in the window parameter. The window parameter in the preceding example has the value three. Once the producer has sent this number of user data units, it may not send any other user data units until the end of the current heartbeat interval. An End-ofWindow flag (eow) in the header of the data unit indicates one of two possibilities: The producer either has used up the window specified by the window parameter or does not want to send any more user data in the current heartbeat interval. The receivers can use this information for acknowledgments. The current sequence number is important because it alerts receivers to transmission errors. Therefore, all receivers must be notified of the current sequence number as quickly as possible. For this purpose, the producer sends at least one data unit during the heartbeat interval. If no user data is available for transmission, the producer sends a control data unit (EMPTY data unit) containing the current sequence number.

6.3 MTP

Producer Heartbeat

219

Consumer DATA(n) DATA(n + 1) DATA(n + w − 1, eow) DATA(n + w) DATA(n + w + 1) DATA(n + 2w − 1, eow) EMPTY(n + 2w)

Release: n . . n + w − 1

Release: n + w . . n + 2w − 1

DATA(n + 2w, eom)

Window = w = 3 Retention = r =2 Figure 6.5 Data transfer.

Lastly, the producer releases the token if no further data is to be transmitted. The producer sets an End-of-Message flag (eom) in the header of the last data unit to indicate this fact. However, this does not complete the transfer of the message for the sender. The sender has to retain the data for a certain period of time for possible retransmission. This time interval is specified by the retention parameter. In the example in Figure 6.5, the value is two. The sender of the data therefore releases the user data from sequence numbers n + w − 1 after two heartbeat intervals. This reduces the buffer space needed by the producer.

6.3.4 Error Control A receiver detects that a data unit has been lost if the sequence number received is higher than the sequence number expected. Receivers can also make this discovery if the sender has sent no data in the current heartbeat interval or if the sender has already released the token. The first instance is dealt with through empty data units. The second

End-of-message flag

220

Chapter 6 — Transport Protocols instance can be detected if the token sequence number is increased but a data unit with an assigned End-of-Message flag has not been received. Another possibility is that the network is partitioned. An MTP entity recognizes this as the cause if it does not receive any data units during retention heartbeat intervals. In this case, the entity itself terminates the connection. A selective, negative acknowledgment strategy is pursued by MTP for error recovery. This means that the sender is only made aware of data units that are not received correctly. It is not sent acknowledgments for correctly received data. Receivers send the negative acknowledgments (NAK) per unicast to the producer. If a producer receives a negative acknowledgment, it sends the requested data per multicast to the group. Retransmissions are subject to the same rules that apply to user data units that are sent for the first time. In particular, the retransmissions have to comply with the rate control specifications. However, the producer does not have the requested data in each case because the data is overwritten once the period of time specified by the retention parameter has elapsed. In this instance the producer sends back a NAK-DENY data unit per unicast. This means that there is no further chance to retransmit the data. Thus MTP only implements a partially reliable transport service. Therefore, unsuccessful retransmission requests from a receiver are only repeated until the requested data is received correctly or the time interval specified by the retention parameter has elapsed. Any further attempts to transmit data would be ineffective. An example of faulty transmission is illustrated in Figure 6.6. The data unit containing sequence number n = 1 does not reach the receiver shown. When the receiver receives the next data unit, it notices the error and generates a negative acknowledgment for the sender. The NAK data unit contains a list of sequence number pairs indicating missing data units from the respective producer. If data is missing from different senders, multiple NAKs have to be sent. The sender then retransmits the data unit, albeit not until the start of the subsequent heartbeat interval because the credit is exhausted. The retransmitted data units are lost again, which results in the receiver sending a new negative acknowledgment. This acknowledgment does not reach the sender until the next heartbeat interval. However, the data unit will have already been released by then. The producer therefore sends a NAK-DENY data unit to signal to the receiver that retransmission of the data is no longer possible.

6.3 MTP

Producer

Consumer DATA(n) DATA(n + 1)

Heartbeat

DATA(n + w − 1, eow) NAK (n + 1) DATA(n + 1) DATA(n + w ) NAK (n + 1)

Release: n . . n + w − 1

DATA(n + 2w − 2, eow)

DATA(n + 2w − 1) NACK-DENY(n + 1) DATA(n + 3w − 3, eom)

Window = w = 3 Retention = r = 2

Figure 6.6 Error recovery.

Lastly, there is another aspect of the MTP error-handling strategy that should be considered. In comparison to the positive acknowledgment mechanism, the use of negative, selective acknowledgments reduces the load on the sender because of the lower number of acknowledgments. On the other hand, since the acknowledgments are sent per unicast, the risk of acknowledgment implosion still exists if a large number of users experience a loss of data. Furthermore, it is possible that all receivers will send acknowledgments at almost the same time because of the fixed intervals. This in turn will increase the load on the sender and on the network.

6.3.5 Maintaining Order and Consistency Within the context of error control, MTP ensures that all group members receive the same data in the same order. The message sequence

221

222

Chapter 6 — Transport Protocols number determines the sequence in which messages should be delivered. To maintain consistency, the master determines whether a message is delivered to the users. A message is considered valid if the master has received every data unit belonging to that message. It should be pointed out again that total reliability is still not achievable with MTP. If a receiver notices the loss of a data unit and subsequently requests the retransmission of that data unit, then all the requests may be lost. If the retention interval is exceeded, the producer assumes that all consumers have received the data. The producer then releases the corresponding message from the send buffer. The data is then no longer available for retransmission. Even the master is not aware of this situation because negative acknowledgments are sent per unicast to the respective producer. However, a message declared valid by the master cannot be delivered to the respective receiver. This produces an inconsistent view of the data exchange to the group members. On the other hand, if a large enough retention interval is selected, the probability that such a situation will occur is quite small. To determine the validity of a message, the master assigns a status to each message: ■ ■ ■

ACCEPTED

PENDING

REJECTED

ACCEPTED (0) PENDING (1) REJECTED (2)

The master assigns an ACCEPTED status to a message if it has received all data units, including the last one, for the message. A message with this status may be forwarded to the application by all MTP entities. A message has a PENDING status if the master has not yet received all data units for a message. It assumes that the producer of the message can still be reached and is active. The message retains this status until the master has received all data units and assigns an ACCEPTED status to the message. However, if the master assumes that the producer is no longer active and cannot be reached, the message is rejected and given a REJECTED status. This message may not be delivered by any user and must be discarded. This way, MTP realizes a “semiatomic” multipeer service because only complete messages are delivered to the users in the web. The service is not really atomic, since MTP is semireliable. If a producer has freed the send buffer and a receiver can therefore not recover from a transmission error, the message will still be accepted if the master has received all data units. Note

6.3 MTP that a member need not leave the web in the case of a rejected retransmission request. Otherwise, the service would be atomic. A status vector contains the status of a maximum of 12 consecutive messages. Figure 6.7 shows a situation in which messages with the sequence numbers m − 12 and m have the status PENDING, message m − 2 was accepted, and message m − 1 was rejected. The status vector is moved along one place each time a new message is added. The status of the “oldest” message is therefore lost in the vector. This means that a new message may not start until the status of the oldest message in the status vector is no longer PENDING. In other words, the message may not start until a decision has been made to accept or to reject the message. In the previous example, therefore, no new message may be sent. The status vector is part of the message acceptance record. This field is located in the header of all MTP data units (either user or control data units). In addition to the status vector, it contains the current message sequence number of the sender and the sequence number of the data unit within the message. The status vector is used to notify each member of the web of the status of current messages. It also allows each member to initiate error handling, deliver messages to an application, and discard messages. In periods of no activity (i.e., after all messages have either been accepted or rejected and no outstanding transmit tokens exist), the master sends EMPTY-HIBERNATE data units to keep the members synchronized.

6.3.6 Summary MTP provides a semireliable, “semiatomic,” global-ordered multipeer transport service. Reliability is achieved through retransmissions from the sender triggered by cumulative negative acknowledgments. Since user data is maintained only a certain period of time by the sender, full reliability is not realized by MTP. Atomicity is maintained by the master of the communication group. Only messages that the master has ...

1 m - 12

0

2

m-2 m-1

1 m

m . . . m - 12 Message sequence numbers Figure 6.7 MTP status vector.

223

Message acceptance record

224

Chapter 6 — Transport Protocols marked ACCEPTED in the status vector are delivered to the users. Ordering is achieved through the use of transmission tokens granted by the master. Each token is assigned a message number, which is used to order the messages. The master, which is responsible for ordering and consistency, is a single point of failure. If the master is located on a congested link, a message may be rejected although many or all other members of the web have received the message correctly. No mechanism is defined for MTP to handle such situations. Moreover, procedures to handle a failure of the master are not specified. MTP is probably not scalable for large groups since no mechanisms exist to prevent a NAK implosion at a sender. NAK data units are sent per unicast to a producer—this averts NAK suppression. Retransmissions are sent per multicast. Thus, it would be possible to suppress a NAK if the data is retransmitted on behalf of another member. But there is no notion of NAK suppression in the specification. Since retransmissions are always sent per multicast, bandwidth may be wasted and synchronized members may be bothered with unwanted retransmissions if only a few members miss the data. Retransmissions are also rate controlled. This makes MTP vulnerable to the “crying baby” problem: A receiver on a congested or low bandwidth link, and, thus, frequently requesting retransmissions, can substantially drop the achievable throughput. And, finally, request and allocation of tokens may incorporate a substantial delay. Some of the above-mentioned deficiencies of MTP have been addressed in MTP-2 [27]. Among others, the new features of MTP-2 are recovery from failure of the master, procedures for master migration, dynamic adjustment of protocol parameters, like heartbeat and retention, according to network conditions, and fast late join. Other enhancements to MTP (MTP/SO [28]) incorporate local recovery to address the NAK implosion problem. With MTP/SO, each member advertises its reception quality and the member with the best quality is elected as a repeater for the local region.

6.4 RMP RMP (Reliable Multicast Protocol) was introduced by Whetten, Montgomery, and Kaplan [159]. During the development of RMP, particular attention was given to reliable and orderly n:m communication. Complex protocol functions are required to achieve total ordering; yet this ordering is not required in all cases. RMP therefore allows the level of reliability for each data unit to be selected as required. However, the

6.4 RMP

225

specification is sender-oriented, which means that the sender selects the level of reliability. First, the different levels of reliability offered by RMP will be discussed, followed by a description of the basic mechanisms of the protocol. These levels are ■ ■ ■ ■ ■ ■ ■

Unreliable Unordered Source-ordered Totally ordered k-resilient Majority-resilient Totally resilient

With an unreliable RMP service, data units are delivered once, several times, or never, and in any sequence. With an unordered RMP service, data units are delivered at least once to all group members (i.e., user data is delivered completely). The order of the delivery is not guaranteed. A source-ordered RMP service ensures that data units are delivered exactly once to each group member in the order sent by the source. However, an ordering between different sources is not guaranteed. A totally ordered RMP service is an extension of the sender-ordered service. With this service, the order of data units delivered by different senders is the same for all receivers. A k-resilient RMP service offers an even higher level of reliability. The data is totally ordered and delivered atomically to all group members that are still operating and can be reached. Thus the data is delivered to all active members or to none at all. The prerequisite is that not more than k group members have failed or cannot be reached at the same time. A majority-resilient RMP service corresponds to a k-resilient service with k equal to half the maximum number of group members. The totally resilient RMP service offers the highest level of reliability. It corresponds to the k-resilient service with k equal to the number of group members. As often mentioned, total reliability can only be achieved if an awareness of all group members exists. RMP is based on the establishment of a logical ring. The full reliability of the transmission of a data unit is not assured until all members of a group have acknowledged receipt. However, it has to be taken into account that membership can change during a communication. This change could result from the

Unreliable Unordered

Source-ordered

Totally ordered

k-resilient

Majority-resilient Totally resilient

226

Chapter 6 — Transport Protocols

Membership view

addition or removal of group members. It could even be due to an error situation, such as host failure or network partitioning, in which case certain hosts can no longer be reached. RMP deals with this problem by having hosts notify each other about members of a group. The result is a shared view of group membership. If an error situation occurs, the membership view is updated. Therefore, at least the remaining hosts are able to continue the communication. This is of course only feasible if no participation from the eliminated hosts is required (see below). Each host within this ring may transmit data at any time. Strictly speaking, RMP is therefore a multipeer protocol. Data units contain the following information that clearly identifies them: ■ ■ ■

Acknowledgments

Token site

An ID for the sender The sequence number of the data related to the sender The reliability requested for the particular data unit

Many multicast protocols use negative acknowledgments to reduce the problem of acknowledgment implosion. However, the use of negative acknowledgments cannot guarantee that all group members will receive a data unit correctly. In addition to negative acknowledgments to request retransmission, RMP also uses positive acknowledgments. These positive acknowledgments are sent per multicast to the group by a designated receiver, the token site. An acknowledgment contains a global sequence number and a quantity of tuples identifying the data units being confirmed by this acknowledgment. The tuples consist of the information described above about the sender of the data unit, the sequence number for that sender, and the requested reliability class. In addition, an acknowledgment contains the RMP address of the next token site. The global sequence number is used to implement a unique global ordering of the data units. The included sequence number is allocated to the acknowledgment itself. Moreover, the global sequence number of the acknowledged data units is incremented continuously. If the global sequence number is 8 and confirms the acknowledgment of two data units, then sequence number 9 is allocated to the first one and sequence number 10 to the second one. The global sequence number is unique because there is only a single token site in the ring at any given time. Data units are therefore serialized according to the described allocation of data units to global sequence numbers. This forms the basis for the different ordering strategies.

6.4 RMP Figure 6.8 shows a host sending a data unit per RMP to group members. The receiver indicated is the token site at this point in time. The receiver acknowledges receipt of the data unit and sends a positive acknowledgment per multicast to all group members. However, this acknowledgment does not prove that the other group members have also received the acknowledged data units. The token is therefore forwarded with the acknowledgment to the neighboring host in the virtual ring to ensure that the data units are delivered reliably to all group members. If the neighboring host accepts the token, it becomes the new token site. The token may not be accepted, however, until the host has received all data with lower sequence numbers than the acknowledged data. Thus, correct receipt of the data by all group members is guaranteed once the token has been passed on n times. Positive acknowledgments enable a host to determine nonreceipt of data units. If required, it uses a negative acknowledgment to request a retransmission. It is not totally clear to RMP which host has made the retransmission request. It would appear sensible to request the retransmission from the host that acknowledged receipt (i.e., the

Token site

User data ACKs Figure 6.8 Token site acknowledges data unit.

227

228

Chapter 6 — Transport Protocols host that was the token site at that particular point in time). But this is not required. If the token site has not received any data units over a certain period of time, it forwards the token in order to limit the delay in the ring. It is irrelevant whether any data units were actually sent during this time frame or whether the token site has not received them.

6.4.1 Data Management

Data list and ordering list

Two different lists are used to maintain the requested ordering, identify missing data units, and buffer data units for retransmission. Incoming data units and LIST-CHANGE-REQUEST data units without a known global sequence number (i.e., which have not received a positive acknowledgment from a token host) are inserted in a data list. The second list, the ordering list, contains slots. A slot corresponds to a data unit, an ACK data unit, or a NEW-LIST data unit. The slot contains a pointer to the corresponding packet, a pointer to the receive status of the data unit, the identifying tuple for data units, and the global sequence numbers of the data units. Depending on the status, not all fields of a slot have to be occupied. These two lists are shown in Figure 6.9. The identifying tuple corresponds to the information contained in the acknowledgments. The receive status can have the following values: ■ ■ ■ ■

Missing Requested Received Delivered

If a host receives a user data unit or a LIST-CHANGE request, it inserts the data unit in the data list. If, on the other hand, the host receives an ACK data unit, it files the ACK data unit in the ordering list according to its global sequence number. If data units are acknowledged on the basis of these sequence numbers, the RMP process allocates each data unit a slot according to the order of the global sequence numbers. In the case of an incoming data unit, the ordering list is searched to determine whether a suitable slot for this packet already exists. This involves comparing the identifying tuples for the data unit with the tuple allocated to a slot. If a slot already exists, the RMP entity removes

6.4 RMP

ACK,Token site, global sequence number DATA DATA

ID, Sequence number, Reliability

DATA

glob. Sequence number

DATA

Status

ListChangeRequest

DATA

DATA ListChangeRequest

Data list

Ordering list Figure 6.9 Data management.

the data unit from the data list and inserts it at the corresponding location in the ordering list. The data list is also searched if an ACK data unit is received. If the search is successful, the data unit is removed from the data list and inserted in the newly allocated slot. This procedure applies to a normal situation in which a data unit is sent and then received by the RMP entity of the respective receiver. In this case, however, the data unit cannot be filed according to a global ordering since no acknowledgment has yet been received. However, the token site also receives the data unit and acknowledges it. The sequence number is known once the acknowledgment has been received. The data unit can then be inserted in the ordering list. If the acknowledgment establishes the RMP process as the new token site, the RMP process can only accept the token if it correctly received all data units confirmed by the acknowledgment. If this is not the case, the token acceptance cannot be acknowledged. The missing data then has to be requested via a negative acknowledgment. If data is missing, a NAK control data unit is issued per multicast to request the data units. The request is directed to the host addressed in

229

230

Chapter 6 — Transport Protocols the control data unit. Knowledge of the token site acknowledging the data unit is not required. In the first case, therefore, the acknowledgment was received but not the acknowledged data unit. The token site buffered the data and can retransmit it upon request. In the second case, the acknowledgment was not received. This can mean that acknowledgments from this or even from one or more previous token sites were lost. Thus there is no way of knowing from which host the data units should be requested. It has to be pointed out that even positive acknowledgments need to be requested again since they form the basis for the ordering. One proposal for a request strategy states that data units should first be requested from the last known token site. If this request is unsuccessful, the NAK control data units are then sent to another host, and so forth. If no response is received even after numerous attempts, the NAK control data units should be sent to the entire group. In this sense, RMP behavior is not optimal because control data units are not sent to a targeted destination and other group members therefore experience unnecessary additional traffic. Moreover, the delay until the error is recovered is increased.

6.4.2 Group Management A reliable service can only be implemented if an awareness of the group members exists. Therefore, each host maintains a list of group members providing its view of the group structure. Whenever a change to the group structure takes place, a new view of the group structure is produced. Such a change is initiated if a new member wants to join the group, an existing member leaves the group, or a host fails and cannot be reached. To synchronize the view of the group structure between members, a host sends a LIST-CHANGE-REQUEST control data unit to the group. In the first place, an update of the membership view is necessary when a member wants to join or leave the group. Network partitions or host crashes, which affect the membership view, are handled by a fault recovery algorithm (see below). Like data units, this type of control data unit requires a positive acknowledgment. Therefore, it is retransmitted until an acknowledgment is received or a maximum number of retransmissions have taken place. A reconfiguration of the ring is initiated in the latter case because it is obvious that an error exists.

6.4 RMP If the current token site receives a LIST-CHANGE-REQUEST, it treats this control data unit like a user data unit and attaches it to the data list. However, a NEW-LIST data unit is generated as the acknowledgment. This data unit contains the fields of a normal ACK data unit as well as the new member list. The other hosts treat the first part of the NEW-LIST data unit as an acknowledgment; that is, they attach it to the ordering list. The ordering list is then processed as described previously. If a new member list is produced as part of this processing, it is forwarded to the RMP entity and the new group structure is active. Moreover, the change in group structure is indicated to the application. This process ensures that all active group members have the same view of the group structure. The join of a new member to a group also constitutes a change in membership. The acceptance of a member to an RMP multicast connection therefore follows the same procedure as described previously. First the RMP process sends LIST-CHANGE-REQUEST control data units. It repeats this procedure until it receives a NEW-LIST control data unit identifying the process as the new token site. Hence, the process is contained in the list of group members. The same procedure applies when a member leaves a group. Thus the process concerned is removed from the member list contained in the data unit. However, the connection cannot be set up immediately. To guarantee reliability, the RMP entity has to process NAK control data units, and possibly forward the token, until the host no longer needs to keep any data units for retransmissions. The membership view and the state of the ordering queue are crucial for the provisioning of ordering and reliability in RMP. If the network gets partitioned or a host crashes, reformation of the RMP ring normally is necessary. A site assumes that a failure exists if no acknowledgment is received for a set of data units after a predefined number of timeouts and retries. Data units that require some sort of acknowledgment are user data units (acknowledged by ACK data units), ACKs (acknowledged by an ACK from the new token site), LISTCHANGE-REQUEST data units (acknowledged by NEW-LIST data units), and NAKs (acknowledged by retransmitted data units). To start the recovery process, a site repeatedly multicasts RECOVERY-START data units to the group to determine which sites in the group are still active and reachable. An active site responds with a RECOVERY-VOTE data unit containing the highest consecutive global sequence number in its ordering queue and the highest consecutive sequence number it has received from each site in the old membership view. This information constitutes the sync-point. It is the goal of the recovery procedure

231

Error recovery

232

Chapter 6 — Transport Protocols to find a common sync-point for all sites in the newly created ring. That data unit also confirms that the sending site has joined the new ring. If the initiator of the reformation process receives a new syncpoint, a RECOVERY-START data unit is sent per multicast to the group in order to update the status at the other sites. Sites that are still missing data request them individually (note that retransmissions may be performed by other sites than the original sender). This is repeated until the sync-point does not change anymore or all but one of the sites in the old membership view have responded. As the next step, the initiator checks whether the number of sites in the new ring is sufficient. Every site that joins an RMP group has to specify a minimum number of sites that must remain in a partition in the case of a failure. The minimum size for the new group is the maximum of these values for each member of the old ring. If this condition cannot be matched, reformation fails and the connection is closed. If this test is passed, the initiator multicasts a NEW-LIST data unit to all the members of the new ring. If it is acknowledged by all members, the initiator makes itself the new token site and returns to normal operation.

6.4.3 Summary RMP provides unreliable and reliable multipeer communication with various forms of ordering. A shared membership view is maintained to achieve a totally reliable service. The membership view forms a ring in which a token is passed. The token site is responsible for ordering and acknowledgment of data units. An ACK implicitly passes the token to the next site in the ring. Since a site is not allowed to accept a token if data with a global sequence number less than that of the ACK is missing, it is assured that given n members of a ring, once the token has been rotated n times, all messages with a global sequence number at least n smaller than the current have been received by all members. A fault recovery to handle network partitions and host crashes is also defined for RMP. For low error rates, RMP generates low control traffic, since only the token site sends acknowledgments and token rotation is implicit. The use of positive acknowledgments enables the sender to release acknowledged data and, consequently, to save buffer space. The main disadvantages of RMP can be derived from the existence of the token site. In wide-area networks with many receivers, token rotation may

6.5 LBRM

233

take a considerably long time. As a consequence, the time until a data unit becomes stable may be very long, which increases end-to-end delay substantially. Moreover, retransmissions are also performed by the token site without considering the underlying topology. If the roundtrip time to other members is high, latency is increased.

6.5 LBRM The LBRM (Log-Based Receiver-Reliable Multicast) protocol was presented by Holbrook et al. in 1995 [89]. This protocol was also designed for the Internet. It is therefore based on an unreliable multicast network service as offered by IP or UDP. The goal of this protocol is to provide a reliable multicast transport service that can be used for very large groups. The need for scalability for large groups is again in the foreground. LBRM is a receiver-oriented protocol in which the receivers execute error control. It contains no provision for group management. This means that the source is not aware of the group members.

Receiver-oriented

6.5.1 Data Transfer and Error Control With the LBRM protocol, data is transmitted from the source to the receivers over an unreliable multicast service. However, data units are provided with sequence numbers and checksums so receivers can detect any lost data or corruption of data units. If a member of a receiver group notices that it has not received a data unit or a transmission error has occurred, it can request a retransmission of the respective data. A negative acknowledgment is used to request the retransmission. The key disadvantage of negative acknowledgments has already been explained. The problem is that a receiver cannot detect the loss of a data unit until it has received the subsequent data units and a gap is evident in the sequence numbers. This means that the loss of the last data unit in a sequence of data units cannot be detected until a new sequence of data units is sent. This disadvantage of LBRM is treated similarly to the one with MTP: The source sends control data units, which contain the current sequence numbers, at regular intervals, referred to as heartbeat intervals. These data units alert receivers to the fact that data units were not received. The heartbeat interval is increased exponentially to keep the overhead low. Therefore, a timer is started with the duration of the

Heartbeat interval

234

Chapter 6 — Transport Protocols

Logging server

heartbeat interval. If a data unit is sent, the timer is set back. The receivers then receive the current sequence number with the data packet. The expiry of the timer triggers the sending of a control data unit. Thus the selection of the heartbeat interval determines how quickly a data loss can be detected. If the interval is a short one, the control data unit soon follows the last data unit and any loss of data is quickly detected. However, control data units create additional network load, thus contributing to a fairly high overhead. To avoid this situation, the authors of the protocol suggest a mechanism in which the heartbeat intervals are lengthened—for example, doubled—each time the timer expires. The control data units are then issued on a less frequent basis if no user data is transmitted for a long period of time. This is a sensible solution because the probability that all group members will receive a control data unit increases after each heartbeat interval. On the other hand, receivers in a network domain temporarily suffering high data loss also have the chance to detect the loss of data units. Note that it is not mandatory to request retransmission. The application or the respective implementation of the protocol determines whether retransmission is actually required. LBRM was initially designed for distributed simulations in which the behavior of thousands of objects is calculated on a distributed basis. All hosts participating in the simulation are notified of the status of each object at more or less regular intervals. However, hosts are often not interested in the status of all objects. If data is lost for objects that are of no interest to a host, retransmission of this data is not necessary. Of course, the receiver should make this decision. With LBRM, negative acknowledgments are not sent directly to the source. Retransmission is requested instead from a logging server (see Figure 6.10), which either may be colocated with the source or placed on a different host. The logging server is a process that communicates with the data source over a reliable point-to-point connection. The logging server has the task of storing the data sent by the source until it has been received correctly by all receivers. Therefore, the source only has to keep the data in the buffer until the logging server acknowledges correct receipt of the data. From this point onwards, the logging server is responsible for storing the data accordingly. It should be generally noted that retransmissions are carried out over special reliable unicast connections, similar to the mechanism used with MTP. LBRM does not provide any mechanisms for guaranteed ordering since data is only retransmitted in respect to a single receiver. It is the application’s task to provide ordering.

6.5 LBRM Sender

Logging server ACK

P

User data NAK

Retransmissons

Receiver Receiver

Receiver Receiver

Figure 6.10 Basic architecture of LBRM.

With this mechanism, missing data has so far only been requested from a logging server and retransmitted by it. Despite the use of negative acknowledgments, the risk of acknowledgment implosion exists for very large groups. Consequently, the logging server could be overloaded. If, for example, many receivers do not receive a data unit correctly, all these receivers then request this data unit from the logging server. Moreover, it has to be borne in mind that the data units are retransmitted per unicast. Thus they have to be transmitted separately to each receiver. This is precisely the type of situation that a multicast protocol should avoid. Since the logging server is responsible for retransmissions and the sender discards data acknowledged by the logging server, recovery from lost data units is impossible if the logging server fails. In order to provide for better fault tolerance, the logging server may be replicated. With replicated logging servers, the source only frees the send buffer if besides the primary logging server at least one replica has acknowledged the data. If the primary server fails, the source locates the logging server replica holding the most up-to-date data units and transmits any data units held in its buffer. From this point, the replica operates as the new primary logging server.

235

236

Secondary logging servers

Statistical acknowledgments

Chapter 6 — Transport Protocols Two extensions to LBRM have been proposed to overcome the limitations mentioned above. The first extension consists of the use of secondary logging servers—additional logging servers that also record the data. Secondary logging servers are members of the group and receive the data per multicast like any other group member. With this extension, group members do not send their negative acknowledgments to the primary logging server but to a secondary logging server. If this server has the data, it sends it to the host requesting a retransmission. However, if this secondary server also has not received the data correctly, it in turn requests this data from the primary logging server. It should be recalled that the primary logging server has or will have received the data in any event. Secondary logging servers therefore help to distribute the retransmission load to multiple servers. The primary logging server only retransmits data if a secondary server has not received the data correctly. Furthermore, if the installation location of a secondary server is selected carefully, the transmission delay can be kept short compared to the transmission delay between receiver and source. Acceleration of error recovery is also possible. The procedure is clarified in Figure 6.11. However, no specification is provided for the location of the server. The authors of the protocol propose that secondary servers should be sited in the “vicinity” of the receivers, for instance, one per connected LAN. However, this is only feasible if the LAN actually contains many more than just one receiver. Furthermore, the strategy only works if the overloaded network area is between the secondary logging server and the receivers. Otherwise it is highly probable that the secondary logging server will also be affected by the fault. A technique to find a secondary server is the expanded ring search. With this technique, a host uses a series of scoped multicast discovery queries (see Chapter 3 for scoped multicast). But other resource discovery strategies may also be applied. Sophisticated recovery strategies from a failure of a secondary logging server are not specified either. With the described version of LBRM, a participant simply connects to the primary server if the selected secondary server does not respond. The second extension proposed directly concerns retransmissions. If a retransmission is via unicast, network resources could end up being poorly utilized if multiple receivers request the same data unit. The basic idea behind this extension to the protocol is the following: Data that has not been received correctly by multiple receivers should not be sent per unicast to each receiver but per multicast to all receivers simultaneously. Statistical acknowledgments are

6.5 LBRM

237

P S

S

S

P/S

Primary/secondary logging server User data ACKS

Figure 6. 11 LBRM with secondary logging servers.

used to determine whether a retransmission should be multicasted. The sender randomly selects a small number (depending on the estimated group size) of secondary logging servers as representatives. These representatives then positively acknowledge receipt of every data unit. If some acknowledgments do not arrive, this means that some representatives have not received the data unit. This is an indication that a fault has occurred in the network. It is highly probable that receivers not belonging to the group of representatives also have not received the data. Therefore, the source immediately multicasts a retransmission without receiving a retransmission request. This way, NAK implosion may be avoided. The representatives are chosen for a certain period of time only. In the next period of time, other secondary logging servers are selected as representatives. As another enhancement, the primary logging server can decide to multicast a retransmission if the number of negative acknowledgments exceeds a predefined threshold. Obviously, this strategy involves delaying retransmissions,

238

Chapter 6 — Transport Protocols since the server has to wait for additional NAKs. As a result, the average transfer delay increases.

6.5.2 Summary LBRM is a receiver-oriented reliable multicast protocol. User data is cached at a logging server, which buffers all user data while the session exists. Negative acknowledgments are sent by receivers to request retransmissions. Although group management procedures do not exist, LBRM provides reliability, since the user data is kept during the entire session. This is advantageous for late-joining receivers, which may want to request all data sent so far. If neither the logging server fails nor the network partitions, every receiver eventually receives the data. But the sender never knows when a data unit is stable. A single logging server just shifts the burden of NAK implosions from the sender to the logging server. Therefore, secondary logging servers have been introduced to overcome that problem. A subgroup of receivers sends their NAKs to an associated secondary logging server, which retransmits the requested data if available. An open issue is the placement of these servers, which is critical especially for dynamic groups. Statistical acknowledgments are another measure to prevent NAK implosion. A small number of representatives are selected, which acknowledge the receipt of data. If some representative does not acknowledge the data, it is immediately retransmitted per multicast. With statistical acknowledgments, NAK implosions may be reduced, but not eliminated. Moreover, for large groups control traffic may be increased.

6.6 SRM SRM (Scalable Reliable Multicast) [68] provides a semireliable multipeer transport service. In some ways SRM pursues a different track than the other multicast protocols introduced thus far because SRM is heavily oriented toward the Application Level Framing (ALF) concept [42]. This approach is based on the assumption that different applications have very different requirements for a transport service. Therefore, it is not possible for one fixed set of protocol functions to provide adequate support to all types of applications. Instead, protocols should only provide basic functionality. It should then be possible for this functionality to be expanded by an application according to its

6.6 SRM

239

individual requirements. Thus, SRM only offers a partially reliable service. Ordering, in particular, is not guaranteed. According to the ALF concept, the application itself must provide this functionality. An analysis of the protocol also has to consider that it was developed as the basis for the whiteboard used on the MBone (see Chapter 7).

6.6.1 Data Transfer and Error Control SRM is another protocol that was designed for loosely coupled applications. Therefore, no mechanisms are provided for explicit connection setup. SRM is a receiver-oriented protocol in which the receivers themselves are responsible for error detection. As is customary, bit errors are detected through checksums, lost data units through sequence numbers. SRM deals with the problem of lost data units remaining undetected until receipt of the following data units by requiring all group members to send regular status reports, called session reports, to the group. These status reports include the highest sequence number that the member concerned has received from each member of the group. Since these status reports are transmitted per multicast, other group members are able to compare this information with their own. As long as the status reports are not all lost either, this mechanism enables identification of data that has not been received. Regular status reports sent by all group members are a problem for large groups because they contribute to network load, and processing a large number of session reports may overload the members. Therefore, the length of the intervals for sending status reports is selected based on group size in order to provide scalability. Similar mechanisms are used as with RTP (see Section 7.2.1). The larger the group, the longer the intervals selected. Furthermore, status reports contain time stamps that estimate transmission delay between hosts. With SRM the round-trip times are important for error recovery. If, on the basis of the sequence numbers or receipt of a status report, a group member determines that one or more data units have been lost, the host sends a negative acknowledgment to the group. It thereby requests a retransmission of the data units involved. It is not mandatory for the sender of the requested data units to retransmit the data. With SRM all members of a multicast group are potentially involved in retransmission in order to ensure a reliable delivery of data. Negative acknowledgments, however, always incorporate the risk of an

Session reports

Estimation of round-trip times

240

Chapter 6 — Transport Protocols

Repair request

Repair

Hop-scoped error recovery

acknowledgment implosion if multiple receivers have not received data units. Timers are used to solve this problem. If a host detects the loss of data, it waits a random time interval dependent on the distance to the original sender of the data before it sends a negative acknowledgment. This increases the probability that receivers in the vicinity of the original sender will request a retransmission instead of receivers located farther away. But this interval adds to the repair delay if the error occurred near the receiver. Thus, the average repair delay is increased. If a host receives a negative acknowledgment for data that it has not received itself, the timer is stopped and restarted with a doubled value. If a host receives neither the missing data nor a negative acknowledgment during the time interval, it sends a negative acknowledgment when the timer expires. Therefore, in the most favorable case a negative acknowledgment is sufficient for error repair. But in the average case far more NAKs may be necessary. As mentioned above, with SRM the original sender is not the only source for the retransmission of data. Therefore, a mechanism is needed to prevent multiple hosts from sending data when a retransmission request is received. Again timers are used and set in accordance with run-time estimates. Say, for example, host B receives a negative acknowledgment from host A and could respond to this negative acknowledgment with a retransmission. Instead host B sets another timer based on the transmission delay from host B to host A. This value is calculated on the basis of the status reports. If host B receives the data requested before the timer expires, the timer is stopped and the procedure for error repair is ended. If, on the other hand, the timer expires, then host B sends the data in question. Of course, since host B waits a certain time, the average delay before completion of a repair is increased [82]. Moreover, this strategy does not guarantee that only one retransmission is sent. Simulations have shown that multiple repairs are very likely. In addition, performance of SRM may degrade heavily if there is a “crying baby”—a receiver that loses packets frequently, because of a wireless link, for instance. Performance degrades because repair requests are multicasted to the group, and many members may retransmit the repair to the entire group. As a result, the entire group is affected by a single error-prone receiver. As a solution, scoped retransmission was proposed for SRM [98]. With this proposal, the scope of repair requests is limited to a local region in the vicinity of the requester. Two mechanisms are proposed: hop-scoped repair requests

6.6 SRM and separate multicast groups for local regions. With the first mechanism, the TTL value of repair requests is bound to reach a nearby member only. To this end, hop count information is added to session reports. This enables every member to determine a nearby member, but leads to more state information for each member to be maintained. Two cases can be distinguished for error recovery. If a member B within the scope of a member A has received the data but not A, then the repair request will be answered by B. But what happens if B also misses the data? In the example depicted in Figure 6.12, a data unit from the sender may be dropped downstream of C; thus A and B missed the data unit. Since B is located closer to the sender than A, it will most likely send a repair request earlier than A. Since C is in the scope of B’s repair request, it will retransmit the data, enabling B to respond to a subsequent repair request from A. Thus, a requester can rely on an upstream member to request the data, in case the lossy link is not within its scope. Whereas this approach seems to be compromising, it still relies on exact time calculation to suppress duplicate requests and repairs. Moreover, if a loss has occurred close to the sender, local recovery is not appropriate. Fur thermore, simulations have shown that in some topologies, hop-scoped error recovery does not perform better than global error recovery [98].

B’s repair scope

Sender

C B

A

A’s repair scope

Figure 6.12 Hop-scoped retransmissions.

241

242

Chapter 6 — Transport Protocols Local groups

The other scheme uses separate local groups that are dynamically established. A member qualifies as local if its error ratio exceeds a given threshold in its repair request, which is sent globally. A repairer, which has received the requested data, grants the creation of the new local group in its reply, which contains the address of the new group and an error fingerprint. An error fingerprint consists of the sequence numbers of the last n losses, for a given n. A receiver joins the local group announced in the repair if it shares more than a given threshold of the losses with the group. This situation can be determined through the error fingerprint. Note that local groups are established regarding a certain sender; thus, different senders require different local groups. After a local group has been joined, a receiver sends its repair request to the corresponding local group. Thus, the number of members receiving the request is limited to the members of the local group. This scheme, which is only briefly sketched here, imposes considerable overhead on the members to maintain multiple local groups. Moreover, additional overhead is imposed on the underlying multicast routing, since many multicast groups may be established and released dependent on membership dynamics and network conditions. As mentioned previously, the rate in which session reports are sent by each member is adapted according to the group size. Although this keeps the session report overhead low, it can lead to very poor response times. This is particularly important when network topology and session membership dynamically change. Low-frequency session reports result in slow adaptation to network conditions. As a solution for this problem, scoped session reports have been proposed for SRM [138]. With this scheme, only a few members send global session reports; the session reports of other members are limited to a smaller region. Thus, the number of session reports is reduced significantly. The mechanisms proposed to achieve scoped messages are similar to mechanisms proposed for local recovery, that is, TTL scoping or separate multicast groups for each local region.

6.6.2 Summary SRM is a reliable multipeer transport protocol. Each member periodically sends status reports announcing its view of the communication. The status reports are used to detect packet losses. If a data unit is missing, the corresponding participant waits for a random time interval before sending a retransmission request per multicast. The time

6.7 RMTP

243

interval depends on the round-trip time to the sender. Upon receipt of the retransmission request, a member caching the requested data retransmits it per multicast after a random time interval. The length of this interval depends on the round-trip time to the participant missing the data. In both cases the operation is aborted if a similar NAK or a matching retransmission, respectively, is received during the corresponding interval. Thus, in the best case only one NAK and one retransmission is necessary in order to recover from a loss of a data unit. The disadvantage of SRM is that it heavily relies on precise timer calculation. Inaccurate timers can lead to multiple NAKs and multiple retransmissions being sent. A new scheme for time calculation is proposed in [99]. Moreover, NAKs must be processed by every member and timers must be maintained by every member possessing the requested data, which adds to the load of all participants. Even more, the members are meant to cache the data of the entire session for possible retransmissions, which easily may require large buffer spaces. Furthermore, rate limitation of session reports based on group size degrades the adaptivity for large groups. Some enhancements have been proposed to overcome the abovementioned limitations.

6.7 RMTP RMTP (Reliable Multicast Transport Protocol) was presented by Lin and Paul in 1996 [97]. It was mainly developed for the area of distributed services, such as the delivery of new software versions to a company’s customers per multicast or the transmission of stock prices. RMTP therefore uses fixed-length user data units, although the last one can be shorter in length. RMTP also belongs to the group of reliable multicast protocols. During its development, special emphasis was placed on scalability. This protocol therefore uses a hierarchical error correction scheme to avoid acknowledgment implosion at the sender and to reduce endto-end latency in the case of errors. Hence, individual receivers are selected as designated receivers to process acknowledgments for a subtree. For scalability it is also essential that group size does not determine the amount of status information sender and receiver must maintain during a connection. In addition, the protocol contains mechanisms for flow, rate, and congestion control.

Designated receivers

244

Chapter 6 — Transport Protocols Table 6.1 RMTP connection parameters. Parameters

Significance

Wr

Size of receiving window in data units

Ws

Size of send window in data units

Tdally

Monitoring period before connection setup

Tretx

Interval for retransmissions

Tsend

Send interval

Packet_Size

Length of user data units

Cache_Size

Size of cache storage

CONGthresh

Threshold for congestion control

MCASTthresh

Threshold for multicast retransmissions

6.7.1 Connection Control Session manager

RMTP uses a number of connection parameters to monitor the protocol mechanisms. During connection setup a session manager makes these parameters known to the sender and to the receivers. Table 6.1 lists the key connection parameters. Connection setup is implicit. As soon as the sender and the receivers receive the necessary connection parameters, the sender starts sending data units. A receiver considers the connection established when it receives the data unit. A receiver may also join a connection that is already in progress. In this case, the receiver may want to request the data sent so far. The receiver makes this request by sending a negative acknowledgment. Since connection setup takes place on an implicit and unacknowledged basis, the sender is not aware of the individual receivers. Thus a totally reliable multicast transport service cannot be provided. Instead, the developers of RMTP assume that the session manager will deal with the associated tasks. However, the session manger is not further specified. A timer is used to control connection release. The timer is started with the value Tdally after the sender transmits the last data unit. When the timer expires, the sender considers the connection released and deletes all status information concerning the connection. Each acknowledgment received reactivates and restarts the timer. This is necessary for responding to any retransmission requests. The last data unit issued by the sender is a DATA-EOF type. All other user data is of a DATA type. The different data types enable

6.7 RMTP

245

receivers to detect the end of a data transfer. A receiver considers the connection ended when it receives the last data unit and all other data units were also received correctly. In other words, no data is still missing. The designated receiver is also involved in error recovery. Like the sender, it too starts a timer so that it has time to respond to negative acknowledgments. In addition to timer-controlled connection release, RMTP also supports connection termination initiated by a RESET data unit. A connection is terminated, for example, if the sender can no longer be reached even though the data transfer has not yet been completed.

6.7.2 Error Recovery RMTP is also a receiver-oriented protocol in which each receiver has to independently initiate and monitor the repair of transmission errors. Retransmissions are triggered by selective acknowledgments. These acknowledgments (ACK) are sent periodically by the receivers. They essentially contain two items of information: ■

■

The sequence number L, indicating up to which point the receiver correctly received all data with lower sequence numbers A bit vector

The bit vector identifies which data units have not yet been received. A bit set in the bit vector corresponds to a received data unit; a zero refers to a missing data unit. If an acknowledgment contains the value L = 15 and the bit vector BV = 01001111, then the respective receiver is indicating that it has received all data units up to sequence number 14 (inclusive) correctly. Moreover, the receiver requests retransmission of data units with sequence numbers 15, 17, and 18. Data units 16 and 19 through 22, on the other hand, have been received correctly. With RMTP, acknowledgments (ACK data units) are sent periodically by all receivers at interval Tack. Therefore, the number of acknowledgments increases linearly with the number of receivers. To avoid an acknowledgment implosion, receivers do not send their acknowledgments directly to the sender but instead to the designated receiver. The designated receiver is a receiver with the additional tasks of processing acknowledgments and handling retransmission for part of the

Designated receiver

246

Chapter 6 — Transport Protocols

Immediate retransmission

receiver group. The designated receiver accumulates the acknowledgments sent to it per unicast during interval Tretx. It takes note of which receiver has requested which data units. When the interval expires, the designated receiver transmits the requested data. In this instance, the sender does not retransmit the data. If the number of requests for a certain data unit exceeds the threshold (MCASTthresh), it means that many receivers have not received the data unit. The designated receiver then transmits the data unit per multicast. Otherwise the data unit is sent per unicast to the receivers that requested it. If the designated receiver has not received the data unit, it either requests a retransmission from its designated receiver or from the sender. Note that the designated receiver does not ask other members of its local group to retransmit the data, although they might have received the missing data. If the receiver does not want to accept the delay until expiration of interval Tretx because a major proportion of the data has not yet been received due to previous network partitioning, it can request an immediate retransmission. It issues an ACK-TXNOW data unit as an acknowledgment. The designated receiver then immediately starts the retransmission for the respective receiver per unicast. This way, latency can be further reduced. As mentioned previously, in RMTP the session manager selects multiple receivers to assume the designated receiver role. Yet the designated receivers are only assigned to one part of the receiver group. These are the receivers that, figuratively, in the view of the sender are located “below” a designated receiver in the multicast tree. Furthermore, designated receivers can be ordered hierarchically. Thus, a designated receiver can be assigned to another designated receiver. Figure 6.13 presents a multicast tree with hierarchically ordered designated receivers. Each of the outlined groups is the group of receivers allocated to a designated receiver. In this case, each group is a subtree of the multicast tree. The arrows indicate where the receivers send their acknowledgments. As shown in the figure, only the designated receivers and the receivers in the top hierarchy level send their acknowledgments directly to the sender. The load produced by acknowledgment processing and retransmission is therefore distributed among the sender and designated receivers, thereby increasing the scalability of the protocol. As mentioned previously, the designated receiver issues the requested data units per multicast if the number of negative acknowledgments for a data unit exceeds the threshold specified by the session manager during connection setup. The aim is to reduce the

6.7 RMTP

247

Designated receiver

NAK Local groups DR1

Subtree A

Figure 6.13 Multicast tree with designated receivers.

network load caused by retransmission. Therefore, RMTP attempts to limit this retransmission to the subtree of the multicast tree allocated to the respective designated receiver. Say that multiple receivers are requesting the retransmission of a data unit from subtree A in the scenario illustrated in Figure 6.13. As a result of this request, threshold MCASTthresh is exceeded. The data units are sent and forwarded as multicast data units only in the subtree associated with DR1. If these acknowledgments are sent to a designated receiver that is located close to the sender in the multicast tree, or even sent to the sender itself, the area increases accordingly. In the case of the sender, the data units would be issued to the entire group. This retransmission strategy requires subcasting. With subcasting, the router only forwards a data unit on the subtree that, from the standpoint of the original sender, is located below the router. Thus,

Subcasting

248

Chapter 6 — Transport Protocols

Tack calculation

Selection of designated receivers

only a portion of the members of the multicast group is addressed. IP multicast does not provide this functionality, but an implementation is being discussed. RMTP is implementing a tunneling mechanism until a subcasting function is available. Therefore, the designated receiver enters the address of the sender as the source address in the IP data unit. It then encapsulates the data unit into a SUBTREE-MCAST type IP data unit. The authors introduced this data unit specifically for this purpose. The data unit is then sent to the next router. Based on the type of data unit, the router determines that it should be decapsulated and forwards the encapsulated data unit per multicast. Since the data unit contains the address of the sender as the source address, it is only forwarded on the outbound subtree of this router. Of course, an appropriate modification of the routers involved is necessary for this procedure. This means that RMTP currently cannot be used on the Internet this way. Instead, other mechanisms must be used to emulate subcasting. One workaround that is used in a commercial RMTP implementation is to assign a dedicated multicast address to each subgroup. For rapid deployment and testing UDP tunnels between the multicast routers of RMTP receivers are established (see Section 7.1 for tunneling). The round-trip time determines the rate at which a receiver sends acknowledgments. This prevents a situation in which retransmission is requested again, even though the data units being retransmitted could not have reached the receiver in the first place because of the high transfer time in the network. An RTT-MEASURE data unit is used to determine the round-trip time. Each receiver sends this type of data unit with a time stamp at fixed intervals to the associated designated receiver or to the sender. The latter returns it as an RTT-ACK data unit to the receiver. The round-trip time, including the processing time required by the designated receiver, is estimated from the difference between the time stamp and the time of receipt of the RTT-ACK data unit. However, the round-trip time estimation is based on delays experienced for unicast transmissions. If the retransmission is done per multicast, the delay might be quite different, since multicast and unicast routes are not necessarily the same. Moreover, the described RTT estimation does not consider Tretx, the period of time in which a designated receiver accumulates ACKs. Thus, a receiver may repeat its ACK before the designated receiver has had the opportunity to retransmit the requested data units. It is possible that a designated receiver fails or cannot be reached due to network partitioning. RMTP therefore defines a dynamic selection of the designated receiver. However, this does not mean that the

6.7 RMTP

249

selection of receivers that can operate as a designated receiver is dynamic; instead designated receivers are statically selected, possibly at strategic points in the network. Only the association between a receiver and a designated receiver takes place dynamically. The designated receivers and the sender periodically issue SND-ACK-TOME data units to the multicast group. All data units are assigned the same TTL value. The TTL value of a received SND-ACK-TOME data unit allows a receiver to determine the nearest designated receiver since it is the one with the highest residual TTL value. If an SND-ACK-TOME data unit with a higher TTL value is received during a connection, the receiver selects this one as the new designated receiver. The aim of this strategy is to minimize the delay caused by retransmissions. The assumption is that the round-trip times to the selected designated receiver are short. However, the procedure only takes into account the topology of the network or of the multicast tree. It does not consider other values, such as available bandwidth on connection links, in the decision process. Therefore, only a limited response is possible to changes in the network. To achieve a high degree of reliability and to allow receivers to join an ongoing session and still receive all the data, the sender and all designated receivers have to store all data transmitted during a connection. This means that data can be retransmitted at any time. Therefore, a considerable load is generated at the sender and the designated receivers. It is questionable whether a company would be willing to provide the storage required to operate a designated receiver in this way. The parameter Cache_Size determines the number of data units that are cached in memory. The rest is stored on second-level storage, such as disks.

6.7.3 Flow and Congestion Control RMTP allows the send rate to be regulated. The connection parameter Tsend indicates the time interval during which a sender may issue a data unit. A top limit for the send rate is given (Ws × Packet_Size/Tsend) by the window size (see below) together with the maximum size of the data unit that determines the connection parameter Packet_Size. Flow control uses a window-based mechanism. The sender administers a send window, the size of which is given by the session manager during connection setup. The lower limit of the window is moved if the

Rate control

Flow control

250

Chapter 6 — Transport Protocols sender receives an acknowledgment for the corresponding data unit. The sender maintains three variables: ■ ■ ■

Congestion control

swin_lb: the lower limit of window send_next: the sequence number of the next data unit being sent avail_win: the send credit still available

These variables are used as follows: When the sender transmits a data unit, it increases send_next and reduces avail_win. If the sender receives an acknowledgment for the data unit containing the sequence number swin_lb, it increases the variables swin_lb and avail_win. Therefore, the send window moves and the send credit is increased accordingly. To ensure that “slow” receivers—receivers that are still missing a large number of data units—are not overloaded, the sender only considers a minimum of all acknowledgments during a Tsend interval. Thus, flow control is also effective for slow receivers. It cannot be overruled by an individual receiver that is attached to an underloaded network and consequently experiences minimal data loss. The congestion control implemented in RMTP regards the loss of data units as an indicator of increased network load. RMTP therefore follows the practice common on the Internet [92, 93]. The sender administers the variable cong_win, which indicates the size of the congestion control window. The actual usable send window amounts to the minimum of avail_win and cong_win. The sender counts the negative acknowledgments during send interval Tsend. If the total exceeds the threshold CONGthresh, then cong_win is set to one and the sender experiences a slow start [92]. If, on the other hand, the threshold is not reached, the sender increases cong_win by one until the maximum window size Ws is reached.

6.7.4 Summary RMTP is a semireliable, receiver-oriented multicast protocol that incorporates a hierarchical error control scheme to prevent NAK implosion to the sender. Designated receivers organized in a logical tree gather status messages (a combination of ACKs and NAKs) from the receivers of the associated subtree. Thus, it is scalable for large groups. The end-to-end latency is also reduced compared to other approaches because of local recovery. A disadvantage of RMTP is that the designated receivers are selected statically. This is not appropriate for highly dynamic groups.

6.8 PGM

251

Local Group Concept (LGC) represents a similar approach that uses various metrics to dynamically select designated receivers [87]. Moreover, flow control of RMTP adapts to the slowest receiver; thus, throughput may degrade considerably in heterogeneous groups.

6.8 PGM PGM (Pragmatic General Multicast) is a recent proposal made by Cisco Systems and Microsoft. It is currently published as a working document of the IETF (Internet draft) [141]. Again, it provides a semireliable source-ordered or unordered multipeer transport service. “Source-ordered” means that no ordering among multiple senders is provided (see Chapter 2). Although PGM should be regarded as a transport layer protocol, in some sense PGM macerates the strict layering of traditional communication stacks, since routers are involved in NAK suppression in order to sustain scalability. The required router assist is more far-reaching than for RMTP. The latter protocol requires subcasting to provide for local retransmissions, but the routers are not involved in the protocol processing. Subcasting is a general concept, whereas with PGM, routers take an active part in the protocol processing.

6.8.1 Protocol Procedures Again, PGM is implemented over a datagram multicast service such as IP multicast. It has no notion of group membership, and connection establishment is implicit. Therefore, PGM groups are dynamic and unknown. In the normal course of data transfer, a source simply multicasts data units (ODATA) to the group. ODATA data units contain sequence numbers enabling receivers to order the data units. It is the responsibility of the receiver to establish the correct order. If appropriate, unordered delivery is also possible, but only complete application data units should be delivered to the application. As usual, all PGM data units carry a checksum field for detection of bit errors. The checksum is computed the same way as for IP. It is the one’s complement of the one’s complement sum of the entire PGM data unit including the header. A value of zero means the transmitter generated no checksum. For user data units (original data and retransmissions) the checksum is mandatory.

Data transfer

252

Chapter 6 — Transport Protocols

Error Control

Source path state

NAK forwarding

Constrained NAK forwarding

The main part of the protocol processing of PGM is concerned with error control. As mentioned in the introduction to PGM, network elements can also take part in the protocol processing in addition to end systems. Besides ODATA data units the sender regularly sends source path messages (SPM) in order to maintain source path state in the network elements and in the receivers. These SPMs are sent per multicast to the group. A network element that receives an SPM maintains source path state for that source/group pair containing the original sender of the SPM, the group address, and the address of the last PGM hop. Before a SPM data unit is forwarded, a PGM enabled network element replaces the address of the last PGM hop by the address of its own outgoing interface. This way, every network element in the multicast distribution tree knows the address of the previous upstream PGM system. This information is needed for NAK forwarding and suppression. If a receiver detects missing or corrupted data, it issues a negative acknowledgment for the missing data unit per unicast to the previous hop PGM system, which in most cases is a network element. Additionally, the receiver may transmit the NAK per multicast with TTL = 1; thus, the scope of the multicasted NAK is limited to its local network. The receiver repeats a NAK until it receives a confirmation. If no confirmation is received after a predefined number of retries, an unrecoverable error is indicated to the user. The addressed network element confirms a received NAK per multicast to the group but only on the interface that the NAK was received (NCF). The NCF data unit contains the sequence number of the requested data unit and the original source of the data. The network element maintains a repair state for every NAK it receives. This state contains the sequence number of the requested data, the original source of the data, the interface the NAK was received on, and the group address. If no matching repair state for a received NAK exists, it is established and the NAK is forwarded per unicast to the next previous hop according to the source path state. The network element then awaits a confirmation (NCF data unit) from that PGM system. Again, the NAK is repeated until it is confirmed by the previous PGM system. A NAK matches a repair state if source, group address, and sequence number are equal. If a repair state already exists, that means a NAK for the requested data has already been sent to the previous hop and, thus, the NAK is discarded. Note that matching NAKs may be received on different interfaces. The network element records every interface in the repair state, maintaining a list of interfaces on which matching

6.8 PGM NAKs have been received. This way, NAK implosion of the sender is prevented, since only a single NAK for a given data request is forwarded toward the source. All other NAKs are discarded somewhere in the distribution tree, when the NAK is received by a network element that owns a matching repair state. It should be mentioned that NCF data units are not forwarded; the purpose of an NCF data unit is the confirmation of a NAK on a hop-by-hop basis. Upon receipt of a negative acknowledgment, the source immediately multicasts an NCF data unit to confirm the NAK and to multicast the requested data to the group (RDATA). A PGM network element forwards RDATA data units only on those interfaces listed in the repair state for the respective data—that is, only on those interfaces on which a NAK for that respective data has been received. Network elements that do not have a repair state for the data should not forward RDATA data units. Thus, retransmissions are constrained to those subnetworks that host receivers actually missing the data. This protocol feature reduces bandwidth requirements and preserves not directly involved receivers from being bothered with unwanted retransmissions. Why is an NCF multicasted (even limited to the interface on which the corresponding NAK was received) instead of being sent per unicast like the NAK? The reason is to prevent redundant NAKs, that is, NAKs requesting the same data. Before transmitting a NAK, a receiver must wait some random time interval that is selected uniformly over a certain maximum time interval during which it listens for a matching NCF (or a matching NAK that may have been transmitted per multicast by another receiver in the same local network). In that case, NAK transmission is suppressed. Another reason is to allow neighboring downstream network elements to anticipate matching NAKs. When receiving an unsolicited NCF (that is, an NCF for which no NAK was sent by a network element and, thus, no repair state exists at that system from an upstream interface) a network element establishes a repair state according to that NCF. If a subsequent NAK matching that repair state is received, the network element records the interface on which the NAK was received and confirms the NAK by sending an NCF data unit as described above. Instead of forwarding that NAK to the next upstream PGM network element, it is discarded because the upstream PGM system has already confirmed a similar NAK, that is, a NAK that requests the same data. This was the NCF that has established the repair state. Since retransmissions follow the same path as NCFs, the corresponding RDATA data units will also be received by the network element like the

253

Repairs

NAK suppression

NAK anticipation

254

Chapter 6 — Transport Protocols NCF before. Thus, redundant NAKs within a subtree are further reduced. It is essential for PGM that NAK, NCF, ODATA, and RDATA data units are forwarded on the same distribution tree. To make PGM more robust against changes in the distribution tree, source path state must be periodically refreshed by SPM data units. Periodic SPM data units are also needed for error detection. Beside source path information, an SPM data unit carries the highest sequence number sent, enabling receivers to detect losses, even if only the most recent user data unit is missing.

Flow Control For buffer management purposes, PGM defines a transmit window as an instrument for flow control and provides different control schemes for that transmit window. The flow control procedures are completely decoupled from the receivers. Moreover, for bandwidth regulation a rate control scheme is applied. Therefore, a maximum transmit rate is given by the parameter TXW_MAX_RTE. The data units being constrained by the rate control depend on the transmit window control scheme in use. The transmit window is defined as the amount of data that a sender retains for retransmissions. Actually, the size of the transmit window is given as the time a data unit is maintained for retransmission. Together with the maximum transmit rate, the size measured in bytes can be derived. The transmit window is described with a set of parameters: ■ ■ ■

■

■

The maximum transmit rate in kbytes/s (TXW_MAX_RTE) The size of the transmit window in seconds (TXW_SECS) The sequence number defining the trailing edge of the transmit window (TXW_TRAIL), the lowest sequence number retained for retransmission The sequence number defining the leading edge of the transmit window (TXW_LEAD), the sequence number of the data sent most recently The sequence number defining the leading edge of the increment window (TXW_INC)

The range of data that will be the first to be expired from the transmit window is called the increment window. As part of the flow control procedures, the transmit window is advanced across the increment

6.8 PGM

255

window. As a result, the increment window is emptied and the left edge of the transmit window (TXW_TRAIL) becomes the leading edge of the increment window (TXW_IN). The strategy of how the transmit window is advanced across the increment window is not constrained by PGM. Any scheme may be implemented to meet the application requirements. Three basic strategies are described for PGM: ■ ■ ■

Advance with time Advance with data Advance application driven

In the first strategy (advance with time), the transmit window maintains the last TXW_SECS of data in real time, regardless of whether any data was sent in that period or not. The actual number of bytes retained for retransmissions at any instant in time will vary between zero and the maximum size of the transmit window. With this strategy, the rate control is applied to SPM and ODATA data units only. This mode of operation is intended for real-time, streaming applications based on the receipt of timely data at the expense of completeness. The second strategy (advance with data) is intended for non-realtime applications, based on complete data at the expense of delay. With this scheme, the transmit window maintains the maximum amount of data that could be transmitted in the period of time related to TXW_SECS. The transmit window is advanced across the increment window if it is full. Moreover, any NAK received by a sender suspends advancement of the transmit window for a certain interval. Thus, once the transmit window is full, a NAK blocks normal data transmission for this sender. Since this mode of operation aims to control overall bandwidth, rate control is applied to SPM, ODATA, and RDATA units. The third strategy delegates the control of the window to the application. No further details are given.

6.8.2 Options PGM provides a set of options. An option is indicated by the option type field in the header of a PGM data unit. Options allow the provision of additional services for PGM. Among others, the following options are defined:

Advance with time

Advance with data

256

Chapter 6 — Transport Protocols ■

■

■

Redirection

■

Fragmentation: Application protocol data units are fragmented by PGM rather than the network layer protocol. Late Join: This option indicates that receivers that join a transport session may request data as far back in the sequence number as denoted in the options field. The default for receivers is to receive data only from the first ODATA data they receive and onward. Time Stamp: This option is in conjunction with NAK; thus, it is added by receivers. The time stamp indicates the absolute time interval from the time of transmitting the NAK during which the receiver can usefully receive the corresponding data. Network elements should use the time stamp of a NAK to age the associated repair state. Thus, the corresponding RDATA data unit is discarded if it is received after the given time interval. Finally, a source should abandon any attempt to transmit RDATA in response to a timestamped NAK if the repair cannot be completed within the specified interval. The benefit of this option is questionable, since time stamps require synchronized clocks, and thus the time scale has to be coarse. Moreover, it is not specified how a source should determine if a retransmission can be completed within a given interval, without an accurate estimation of the round-trip time. Thus, a reasonable compromise would be to abandon a retransmission if the interval is already discovered as being too tight. When the time stamp is still valid and the time stamps are different, NAK elimination is almost impossible since network elements must forward NAKs with the time stamp option, even if repair state still exists. Thus, the time stamp option may result in a NAK storm if used by many receivers. PGM defines no mechanism to control the use of that option. And it is very likely that in a multicast session a similar application is utilized by the receivers; thus, it is likely that if the time stamp option is applied, it is applied by many receivers. Redirection: This option provides a form of local recovery for PGM and may be used in conjunction with NCFs. A designated local repairer (DLR) responds to normal NCFs with a redirecting NCF advertising its own address as an alternative to the original source. Recipients of redirected NCFs may then direct subsequent NAKs to the DLR rather than to the original source. Moreover, network elements receiving a redirected NCF should record the redirection information for that flow (i.e., for data units from the respective source) and should redirect subsequent NAKs for that flow to the DLR rather than to the next upstream PGM system. It is not specified which host should act as a DLR.

6.9 MFTP

257

6.8.3 Summary PGM is a multipeer transport protocol with unknown groups. It provides a semireliable service with receiver-oriented error control. Receivers send negative acknowledgments to request retransmissions. The major contribution of the protocol can be seen in the integration of network elements into the error control. The network elements provide NAK suppression through constrained NAK forwarding. Thus, in the best case only a single NAK arrives at the sender. Moreover, constrained forwarding of retransmissions limits forwarding of retransmitted data units to subnets with unsynchronized receivers. In addition, options like redirection permit further enhancements to PGM. The novel approach to scalability appears promising, but it goes ahead with an additional load in the network elements. It is still not clear if such protocol processing and bookkeeping are feasible on gigabit routers. Furthermore, congestion control is an open issue in the context of PGM. Rate control is a first step, but since it operates without feedback, it cannot react to network congestion.

6.9 MFTP The Multicast File Transfer Protocol (MFTP) [132] is a multicast transport protocol for the transfer of data files from a server to a group of clients. It aims at file delivery rather than attempting to be a generalized multicast protocol. It is especially not designed to handle realtime streaming data, since the end-to-end delay may become substantial. Typical applications that can benefit from MFTP are electronic software distribution, replication of Web servers, and push applications that provide subscription-based information delivery. MFTP consists of two parts: the Multicast Control Protocol (MCP) and the Multicast Data Protocol (MDP). MCP allows the server to control the operations of clients joining and leaving multicast groups. MDP handles the reliable data transfer to the clients that have joined the multicast group.

6.9.1 Group Management MFTP uses two separate multicast groups, called the public and the private groups. The server announces sessions on its public group,

Announcements

258

Chapter 6 — Transport Protocols whereas the file transfer is sent to the private group. The announcements contain information needed by the clients in order to receive the file. For the private group, MFTP defines three models: ■ ■ ■

Closed groups

Open groups

Open limited groups

Open unlimited groups

Closed groups Open limited groups Open unlimited groups

With closed groups, the server knows in advance which clients are authorized to join the group and, thus, to receive a data transmission. The number of clients should be relatively small to allow the server to tightly control group membership. Authorized clients may either be configured to join the server’s public group or to be invited by the server through MCP to do so. For closed groups, the announcement data unit also contains a list of clients that are authorized to receive the data. Upon reception of an announcement data unit that contains the client’s address in the client list, the client registers itself. Therefore it issues a register data unit to the address provided by the announcement data unit. The server acknowledges receipt of a registration by setting a flag in the corresponding client list entry of subsequent announcements for that session. If the client is not willing to participate in the session, the client indicates that in the register data unit. This prevents the server from unnecessarily repeating the announcement data unit. Otherwise the server cannot differentiate between clients that have not received the announcement data unit and those that are not willing to participate. With open groups, the receiving clients are not known to the server a priori. This means that clients cannot be invited to the session via MCP. The clients must determine the address of the public group by other means, for example, through an MCP QUERY GROUP request. The server responds to this request with a JOIN GROUP data unit containing the address of the public group. The announcement data unit also does not contain a client list, and any client is allowed to request participation in the data delivery. In open limited groups, the server restricts the number of actual participants based on some criteria determined by the application. Therefore, the clients are still required to register for data reception the same way as described above. Thus, at the time of data delivery, the receiver group is known to the server and protocol operation is identical to the closed group model. That does not hold for open unlimited groups. With unlimited groups, any client is allowed to

6.9 MFTP participate in data delivery, and the server does not limit the number of participants. In order to achieve scalability, the clients do not register at the server; they simply join the private group to receive the data. Thus, the group is unknown, and only a semireliable service can be provided in this mode of operation. Besides normal session termination, which is described in conjunction with the data transfer phase, a client may leave the group during data transfer by sending a QUIT data unit to the response address of the sender. Likewise, the server may terminate an ongoing data transfer by sending an ABORT data unit to specific clients of the group. The announcement phase ends if one of the following two cases is valid: ■

■

All clients or the maximum number of clients have registered for closed or open limited groups, respectively. A given timer expires.

Note that the group management procedures described in the specification cannot guarantee that only authorized clients receive the transferred data because a client cannot be prevented from joining a private MFTP group by means of MFTP, even for closed groups. Of course, if a client joins the group even though his registration has not been accepted, the server will not respond to retransmission requests of this client. Therefore, the client is not able to recover from errors and may lose parts of the data.

Multicast Control Protocol The purpose of MCP is to control dynamic join and leave operations of clients to the multicast groups. Thus, it enhances the group management functionality of MFTP if group membership is known. MFTP itself provides group management functions, such as REGISTER to a group. MCP defines the following message types: ■ ■ ■ ■ ■

QUERY GROUP JOIN GROUP LEAVE GROUP ECHO ECHO RESPONSE

259

260

Chapter 6 — Transport Protocols The QUERY GROUP data unit is used by clients that know the IP address of a server in order to obtain the address of the public group. The JOIN GROUP data unit may be sent at any time from a server to one or more clients in order to direct them to join a specified multicast group. The LEAVE GROUP data unit is used to direct one or more clients to leave a specified multicast group. For both JOIN GROUP and LEAVE GROUP data units, no corresponding response data units exist. The following data unit may be used to determine if the specified clients have joined or left the multicast group, respectively. The ECHO data unit is used to determine membership of a multicast group. A client receiving an ECHO data unit responds with an ECHO RESPONSE data unit if it is specified in the client list contained in the ECHO data unit or if no client list is contained in the ECHO data unit.

6.9.2 Data Transfer and Error Control

Blocks

Passes

Rate control

The announcement phase is followed by the data transfer phase. The server transmits the file to the private group. It divides the file into one or more blocks of the same size (the last block may be smaller). These blocks are transmitted in user data units of the same size; once again, the last data unit may contain fewer bytes. The user data units are transmitted in passes. That is, the entire file is sent initially within the first pass. Subsequent passes are needed for retransmissions (see below). The header of each user data unit carries the pass, block, and sequence number to allow for distinction of data units and to enable a client to insert each correctly received data unit into the file regardless of whether it was received in order or out of order or whether data units have been lost in the network. In order to limit bandwidth, a rate control is applied. The transmit rate is a protocol parameter and given by the application; the transmit rate is not adapted to network conditions. Since the size of the file is announced in corresponding announcement messages, flow control is not necessary to support buffer management at the receiver. Nevertheless, a simple congestion control scheme has been specified for MFTP. The goal of this congestion control scheme is to prevent single receivers experiencing high data loss from holding up transmission to the other members of the group. The announcement message optionally contains an error rate threshold, which informs the clients that if they measure a data unit loss ratio higher than the threshold value, they should abort themselves from the group.

6.9 MFTP During transmission of each block, the server issues status request messages to the group at given regular intervals. A status request may contain a client list, in which case only the specified clients are requested to send status messages. Otherwise, all clients are asked. Furthermore, a status request specifies pass, block, and sequence number range for which receive status is requested. A status response data unit contains a bitmap where each bit represents the receive status of an individual user data unit within a block. Therefore, the size of the bitmap in bits equals the number of user data units in each block. Hence, the status of an entire block is contained within a single response data unit. If the receive status of more than one block was requested, several response data units must be sent, one for each requested block. MFTP specifies two types of status responses: ■ ■

261 Error control

NAK responses only All responses

In the first case, only those clients respond that miss data units for the specified criteria, that is, pass, block, and sequence number range. If the server requests the second type of status response data units, a client responds regardless of its reception status. If it has received all data units in the corresponding block, it responds with an ACK data unit, otherwise with an NAK data unit. Since the second type of requests leads to NAK implosion if the number of participants is not very small, the first type is normally used. Neither does the server stop after sending a status request or at the end of each block and wait for ACK or NAKs, respectively, nor does it start retransmissions during a current pass. Rather, the server simply receives and processes the responses in order to schedule which data units need to be resent during the next pass. After the last block of a pass has been transmitted, the server sends a status request data unit for that block and immediately starts the next pass if there are data units that need to be resent. However, if no status response data units have been received for any previous block in the file, the server stops and waits a given time interval for status response data units. If this status request was restricted to specific ranges, the server solicits an unrestricted request. This enables receivers that have missed data outside this range to send a retransmission request. Retransmissions may continue until all clients have received the entire file (for closed and open limited groups) or until the overall delivery time exceeds a given limit or until a given number of status requests has been sent without receiving a response.

NAK implosion

Termination

262

Chapter 6 — Transport Protocols With closed and open limited groups, a client sends a DONE data unit to the server if the complete file has been received. The server confirms the DONE data units with a COMPLETION data unit. This data unit contains a client list indicating from which clients a DONE data unit has been received. The server resends the COMPLETION data unit at regular intervals. However, if the timer expires, the transfer is terminated and the server sends an ABORT data unit to the group. With open unlimited groups, a DONE data unit is not sent; instead, the client simply changes to an idle state. Feedback to the server is not necessary for open unlimited groups since membership is unknown and, therefore, such a feedback would be of no use for the server.

6.9.3 Enhancements

Response suppression

Router support

Aggregation delay

The protocol mechanisms described so far are not scalable with respect to group size, since the number of possible NAKs increases with the group size. However, only one NAK is necessary for a complete block. A number of options have been specified for MFTP in order to improve scalability with respect to large groups. Response data unit suppression is an optional client function that eliminates transmissions of redundant status data units from a single subnet. With that option, clients do not respond immediately to status requests. Rather, a delay timer is started with a randomly chosen value. While waiting for its own timer to expire, each client listens to status responses from other clients. If a matching response is received, the client stops its timer and discards the corresponding response data unit. A further enhancement uses intermediate routers aggregating back-traffic from the receivers to the source. Upon receiving a REGISTRATION, NAK, or DONE data unit, an intermediate router starts a random backoff timer and aggregates the data unit with matching control data units, instead of forwarding the data unit. If a similar data unit is received while the backoff timer is running, the router discards the pending data units. Otherwise, it is sent to the response address of the server. In order to bound the delay caused by the aggregation and suppression scheme, the data units are aged as they progress through the network. Two parameters are used for that purpose. One parameter determines the maximum end-to-end aggregation time, the other parameter the aggregation delay per hop. Each hop calculates the remaining time and adds the result to the aggregated data unit. If the

6.9 MFTP time remaining becomes zero, the data unit is simply forwarded without any further suppression and aggregation.

6.9.4 Summary MFTP is a protocol for multicast file transfer. It supports known and unknown groups, and provides a totally reliable and a semireliable service. Reliability is achieved through selective negative acknowledgments, which are only sent upon request of the source. Because of NAK implosion, MFTP is not well suited for very large groups. The NAKs are triggered by the source, which makes the problem more serious. In order to weaken that problem, enhancements have been proposed that are based on NAK suppression and aggregation. Since aggregation needs router support, this option is not applicable to the Internet offhand. However, data units are still retransmitted to the entire group, thus bothering synchronized receivers with unwanted data units.

263

This Page Intentionally Left Blank

7 MBone—The Multicast Backbone of the Internet

T

he Internet originally provided no support for group communication. Class D addresses were unknown, and a protocol for group management and routing did not exist. The important prerequisites for the provision of a multicast service were therefore not available. However, applications for distributed systems, parallel processing, and videoconferencing soon highlighted the need for a multicast service for the Internet. Deering [53] proposed how group addresses and a form of group management could be integrated into the Internet protocol. His work led to the definition of class D addresses as group addresses on the Internet and the specification of IGMP as the group management protocol. The introduction of a new service such as group communication normally requires that end systems as well as intermediate systems are equipped with the new technology. However, when IP multicast was introduced, the Internet was already so vast that it would have no doubt taken years to convert all systems. Furthermore, the new technology could not be tested on a large scale. But at that time a conversion of many network nodes could not be justified. Nevertheless, it was decided that the new service would be introduced quickly. In order to deploy and test IP multicast, an interim solution involving the creation of an overlay network was selected. This was called the Multicast Backbone (MBone) [60]. Note that the MBone was and still is an experimental network. The MBone was inaugurated in March 1992 through a multicast audio transmission of a session of the IETF [38]. Since then, more than 12,000 subnets have been connected to it all over the world (see Figure 7.1). In some network segments, MBone traffic volume accounts for a considerable proportion of overall Internet traffic.

Overlay network

266

Chapter 7 — MBone—The Multicast Backbone of the Internet 14,000

Subnetworks

12,000 10,000 8,000 6,000 4,000 2,000 0 1992

1993

1994

1995

1996

1997

1998

Year Figure 7.1 Growth of the MBone.

7.1 MBone Architecture Domains and Tunnels

The MBone consists of multicast-enabled subnetworks and links between these subnetworks, called domains and tunnels. In this context, a multicast-enabled subnetwork is created from multicast-enabled end and intermediate systems, also called islands. Multicast-enabled systems are systems that can work with IP multicast addresses, use the group management protocol IGMP, and, in the case of intermediate systems, carry out multicast routing. IP multicast data units can be sent and received within such domains. Still some domains are attached to the Internet via intermediate systems that do not incorporate multicast extensions. Therefore, it is not always possible for multicast data units to be sent and received between domains. This problem is solved by linking the domains on the MBone through manually configured tunnels. Figure 7.2 illustrates two MBone domains with several end systems. The domains are linked together through tunnel T. The end points of the tunnel form the nodes M1 and M2. Assume that end systems A, B, and C are participating in a videoconference that is being transmitted per IP multicast. Data units sent from A are delivered to B within the domain that is multicast enabled. The data units must also reach C. Therefore, they are routed through the tunnel by nodes M1 and M2. What is a tunnel? As mentioned previously, the MBone is an overlay network. Therefore, links within the MBone do not always find a

7.1 MBone Architecture

267

B

M1

Tunnel

M2

C

A

Figure 7.2 Domains and tunnels on the MBone.

direct counterpart in the underlying topology of the Internet. Tunnels are virtual connections between multicast-enabled tunnel end points. Multiple non-multicast-enabled routers can be located between these end points. The systems at the end points of a tunnel are referred to as mrouters. Those that are not multicast enabled are called unicast routers. An mrouter can be a “real” router or a general-purpose workstation/PC running multicast routing software. In the early days, most routers in the MBone were of the latter kind. On this account, the MBone was very unstable because workstations are not optimized for packet forwarding and for seamless operation. An mrouter cannot simply forward multicast data units to the next unicast router of the tunnel. The unicast router can neither deal with class D addresses nor make the necessary routing decisions for forwarding the data units. Thus the problem is how to route the IP multicast data units through the tunnel. Two different mechanisms are used on the MBone to solve this problem: ■ ■

Loose-source-record routing (LSRR) IP-IP encapsulation

Mrouters

268

Chapter 7 — MBone—The Multicast Backbone of the Internet

7.1.1 The Loose-Source-Record Routing Option The loose-source-record routing option is offered by the IP protocol. It allows the route of an IP data unit to be predetermined, either partially or completely. Therefore, a list containing the routers to be passed and the end system to be reached is entered in the options field in the header of the IP data unit. With loose-source-record routing, the path of the data unit determined by this list is not rigidly specified. This option only identifies the intermediate systems the data unit must pass in any event. IP routing continues to determine the path between the routers indicated. Thus, loose-source-record routing can be used to avoid—either partially or completely—normal IP routing. To route an IP multicast data unit through the tunnel to mrouter M2 in the previous example, mrouter M1 enters a loose-source-record routing option with the address of mrouter M2 (see Figure 7.3) in the header of the data unit. It then forwards the data unit to unicast router R1. The address of mrouter M2 is a unicast address (see Figure 7.4). Router R1 does not forward the data unit based on the destination address, which is a group address. Instead, it uses the destination indicated by the address in the source routing options field. Since this is a unicast address, the router is able to forward the data unit using

B

R1

M2

Figure 7.3 Tunneling with LSRR option.

M2

M2

M2

A

M2

Tunnel

M1

R2

Multicast data unit with LSRR option Multicast data unit

C

7.1 MBone Architecture

269

... ...

...

Protocol: UDP Source address: A

Destination address: multicast address Options: LSRR M2

User data

Figure 7.4 IP multicast data unit with LSSR option.

unicast routing. The other routers of the tunnel repeat this same process until the data unit has completely passed the tunnel and reached mrouter M2. This multicast-enabled router can now forward the data unit per multicast routing. The procedure described was actually used on the MBone. However, the fact that the IP option has to be set and evaluated often means that the data unit has to be processed by the regular CPU. The interface card could simply be used to forward the data unit. But IP options often necessitate processing by the CPU because more complex operations are required for the evaluation of the options than for the pure forwarding of data units. The latter case simply requires access to routing tables and the necessary search operations to locate the respective entry. The required algorithms therefore can easily be implemented into hardware. The CPU, on the other hand, represents a bottleneck in a router. As a result, data forwarding is delayed and queues grow longer. The problem is accentuated because an additional copying process is required between the network adapter and the CPU to enable the CPU to process the data. This creates yet a greater delay. When tunneling is used, each multicast data unit has to be processed by the CPU. As a result, IP options can lead to a considerably higher load on the routers. Since routers are not required to consider IP options, routers that do not implement the LSRR option also cause problems. In this case, the routing information in the data unit is ignored and a nonmulticast-enabled router discards the data unit. Consequently, the LSRR option also presents a security problem. Since the sender uses

Disadvantages

270

Chapter 7 — MBone—The Multicast Backbone of the Internet LSRR to determine the path of a data unit, improper use is not ruled out. Therefore, many routers deliberately ignore this option. Many firewalls filter out data units with the LSRR option in order to avoid improper use. For these reasons, today IP-IP encapsulation is the only technique practically used for tunnel establishment.

7.1.2 IP-IP Encapsulation With this mechanism [117], an mrouter encapsulates an IP multicast data unit into a unicast IP data unit. The destination address of the unicast IP data unit is the unicast address of the mrouter at the other end point of the tunnel. Therefore, the unicast routers of the tunnel can forward the encapsulated data unit to the tunnel end point. If the data unit has reached this mrouter, it is decapsulated there. The original IP multicast data unit is then processed further per IP multicast. This mechanism is illustrated in Figure 7.5. Mrouter M1 encapsulates an IP multicast data unit into an IP unicast data unit with the unicast address of mrouter M2 as the destination address (see Figure 7.6). The data unit passes the unicast router of the tunnel and is finally

B

M2

Tunnel

M1

R1

R2

Encapsulated data unit A

Figure 7.5 Tunneling with IP-IP encapsulation.

Multicast data unit

C

7.2 MBone Applications

... ...

...

Protocol: IP-IP Source address: M1 Destination address: M2

Encapsulated IP data unit

... ...

...

Protocol: UDP Source address: A Destination address: multicast address

User data

Figure 7.6 Encapsulated IP multicast data unit.

unpackaged again by M2. Therefore, the data unit can be forwarded per multicast within the multicast-enabled domain. Although the MBone has proven its functionality as an overlay network in recent years, tunnels can only be regarded as an interim solution. Since currently only a few tunnels exist compared to the high number of links in the Internet, multicast routing cannot be optimal. The data units have to be forwarded through the tunnels rather than on the route that would have been established if all routers in the Internet were multicast enabled. Moreover, the failure of a link attached to a tunnel can result in rather ineffective routing due to the following reason: If a link fails, IP data units are, if possible, routed over a different path. This can mean that other tunnel end points might be more effective. However, an adaptation to the changed circumstances cannot take place automatically because the tunnels are administered manually and multicast routing is not effective.

7.2 MBone Applications The MBone provides a working multicast environment. Applications for the new communication form “multicast” were available soon after

271

272

Chapter 7 — MBone—The Multicast Backbone of the Internet the MBone was established. A multitude of applications and systems with communication components based on IP multicast are available today. This section presents a selection of these freely available applications. Information about current versions and sources for applications and general information about the MBone can be found under the following URLs: ■ ■ ■

www.mbone.com/ nic.merit.edu/net-research/mbone/index/titles.html www-mice.cs.ucl.ac.uk/multimedia/software/

7.2.1 RTP

ALF

RTP (Real-Time Transport Protocol) is used by many applications on the MBone and, therefore, is especially relevant in this context. This protocol is also used outside the MBone, even for unicast communication. As such it currently represents a prominent protocol for the support of multimedia communication. RTP [136] was developed to support real-time applications. It offers a common basis, for example, for the transport of video and audio streams. Yet RTP does not incorporate complete protocol functions. Instead, RTP should be regarded as a framework to which an application adds specific functions. Therefore, it follows the Application Level Framing (ALF) [42] concept. ALF operates on the premise that, because of technical developments in this area, potential applications for data communication are so diverse that individual protocols cannot meet their needs. Instead, applications should be more closely meshed with protocols and intervene more actively in the data exchange process. Therefore, RTP is not a transport protocol in the conventional sense. It provides no functions for error control, retransmission, or flow/rate control. RTP also does not offer any quality-of-service guarantees or implement resource reservation. Instead it is limited to the protocol functions frequently required for the transport of real-time data. If necessary, these protocol functions can be expanded to include application-specific functions. In most cases, RTP is integrated directly into an application. RTP consists of two parts: ■

Real-Time Transport Protocol (RTP) for the transmission of realtime data

7.2 MBone Applications

273

Application RTCP

RTP UDP IP

Figure 7.7 RTP protocol stack. ■

Real-Time Control Protocol (RTCP) for the provision of feedback about transmission quality and information about members of a session

RTP is often used on top of UDP/IP (see Figure 7.7). But it is not limited to UDP/IP and can be used, for example, over TCP or even ST2. RTP and RTCP use different transport addresses to allow easy differentiation between the control information transported by RTCP and the user data transported by RTP. For this purpose, the IP addresses are the same for both RTP and RTCP, but the port numbers are different. For RTP an even port number is used, whereas for RTCP the next number (RTP port + 1) is allocated. As a result, RTCP uses odd port numbers.

RTP: Data Transfer Protocol RTP does not recognize explicit connection setup. Instead, users implicitly join a group by sending RTCP data units. Group members are made aware of a new member when they receive this RTCP data unit. The departure of a member from a group is likewise recognized if RTCP data units stop arriving from this member. This means that membership in an RTP group is monitored through a timer. The members of a group are therefore coupled very loosely. Because of the lack of any group management functions, data transfer with RTP is totally unreliable. Furthermore, RTP may be used without RTCP. In that case, no feedback information is available, and group members cannot recognize other group members through RTP. Each RTP data unit (see Figure 7.8) essentially contains the following fields:

Implicit connection setup

274

Chapter 7 — MBone—The Multicast Backbone of the Internet ■ ■ ■ ■

Proiles

Sequence numbers

User data type Sequence number Time stamp Synchronization source identifier

The user data type gives the application an indication of the type of user data involved. However, the significance of this field is not specified by RTP. Instead it is defined in profiles. Application-specific extensions of RTP and the formats of the user data are described in the profiles. The AVT (Audio-Video-Transport) profile is frequently used by videoconferencing applications [135]. It specifies different coding methods for video and audio streams and for sampling rates. The data formats themselves are specified in other documents. Thus, an AVT profile contains data formats for MPEG [86] and H.261-coded [154] video streams. If an application recognizes the profile used, it can determine the type and format of the user data from the user data type field. RTP data units are assigned a sequence number. This sequence number allows the receiver to detect the loss of data units or, if desired, to maintain the ordering. It should be pointed out again that the application is responsible for these tasks. RTP only stipulates that data 8 bits

8 bits

CSRC V P X M count

16 bits

Payload type

Sequence number

Time stamp Synchronization source identifier (SSRC) Contributing source identifier (CSRC)

optional

Header extension

optional

Userdata

Figure 7.8 RTP data unit.

7.2 MBone Applications units should be assigned sequence numbers. However, the sequence numbers are not interpreted by RTP. The time stamp is incremented for each sample. The application can interpret the time stamp to synchronize a stream or between different streams. The synchronization source identifier (SSRC) identifies the source of a data stream and must be unique. Therefore, the sender of a data unit can be determined even without information from the underlying protocols (such as IP). Sequence numbers and time stamps apply to each stream with the same SSRC. Note that a sender must not use the same SSRC for any two streams in a multimedia session. For example, a sender must use different SSRCs for an audio and a video stream. To keep the SSRCs globally unique, they are selected randomly. In this case, the probability for collisions is very low. Nevertheless every participant must be prepared to detect collisions. In case of a collision, a participant must chose another SSRC and send an RTCP message (BYE) to intimate that the colliding SSRC will no longer be used. The CSRC field is used if user data is not delivered directly from the sender. In this case, an intermediate station receives the data, changes it, and forwards it. An example is an audio conference with multiple audio streams that are merged by an intermediate station to create a single stream. In this case, the source of the data stream is the intermediate system making the changes, the mixer (see Figure 7.9). However, the mixer enters the list of SSRCs in the CSRC field so knowledge is available about who originally sent the data. The CSRC count field in the header then indicates the length of the list. The translator (see Figure 7.9) has a similar function as the mixer, which merges multiple streams. This system changes the data, for example, by recoding a data stream to a different coding technique (for example, from PCM to GSM). However, only a single data stream is affected. Moreover, a data unit can contain extensions that are defined in the profile used. The X bit field in the header indicates whether the header of the data unit contains such an extension.

RTCP: Control Protocol RTCP is the control protocol for RTP. However, instead of controlling the protocol, it is mainly used for the exchange of information between users. RTCP provides the following information: ■ ■ ■

Feedback information about receiving quality Information about sent data Information about session participants

275

Time stamps

Synchronization source identifier

Contributing source identifier

Header extension

276

Chapter 7 — MBone—The Multicast Backbone of the Internet

PCM Mixer A

PCM

GSM Translator

B

Audio stream from A (PCM-coded) Audio stream from B (PCM-coded) Mixed audio stream from A and B (PCM-coded) Audio stream from B (GSM-coded) Figure 7.9 Mixer and translator.

Receiver report

The feedback information is sent periodically by each receiver in receiver report (RR) data units. An RR data unit contains the following information for each source: ■ ■ ■ ■ ■ ■

Loss rate Number of lost RTP data units Highest sequence number received Jitter NTP time stamp for last sender report received Time between receipt of the last sender report and transmission of the receiver report

The feedback information contained in receiver reports is mainly envisaged for adaptive applications. High loss rates can equate to a high

7.2 MBone Applications network load. Consequently, the sender should reduce the transmission rate in order to reduce network load. For example, in the case of a video application, the compression ratio could be changed in order to achieve a lower bit rate. However, the transmission interval depends on the group size and the available bandwidth. The larger the group or the lower the bandwidth, the larger the tranmission intervals. This will prevent the proportion of RTCP data units from being too high compared to the overall data volume. Hence, in the case of large groups or low bandwidth (e.g., caused by congestion), only a few reports from a certain participant are received and might be useless. Another problem with the feedback mechanism is a kind of an implosion problem because the sender of a stream receives RTCP data units from all receivers. Although reports are sent less frequently for large groups, the number of reports increases with group size, and the sender might get overloaded. Each source periodically issues a sender report (SR) data unit. It includes a time stamp for the estimation of the round-trip time. This time stamp can be used for synchronization in conjunction with the RTP time stamp. The sender uses the SR data unit to report how many RTP data units and bytes it has sent so far. A sender also receives the RTP data units of other senders. The sender report therefore contains the sender’s receiver report. The source description (SDES) data unit contains information about session participants. It includes details such as the name of the participant, the email address, telephone number, location, and the name of the application used. The canonical name (CNAME), which uniquely identifies the participant, is important information for conference applications. It normally consists of the user name and the name of the domain. The CNAME allows the allocation of a participant’s different data streams, such as a video and an audio stream for a videoconference. Since the SSRC identifies the source of the data (frame grabber and audio device), it is different for both streams. The streams therefore cannot be associated on the basis of the SSRCs.

7.2.2 VideoConference VideoConference (VIC) is a video application that only supports the transmission and representation of video streams. It does not transmit audio data. VIC was developed by McCanne and Jacobson in the Lawrence Berkeley Laboratory at the University of California. It is available

277

Sender report

Source description

278

Chapter 7 — MBone—The Multicast Backbone of the Internet on most Unix platforms and for Windows and is widely used on the MBone. VIC supports a whole range of video codings (H.261, nv, cellb, nvdct, bvc, MJPEG). These codings incorporate different characteristics in respect to achievable compression rate. Therefore, VIC is suitable for use in a variety of different environments, depending on the available bandwidth and the error rate. Small video windows are displayed in the main window of the application, shown on the left in Figure 7.10. In addition to the windows of the individual senders, information about the sender and the receiving quality is displayed (e.g., data and loss rates). Other information can be overlaid if the info button is selected. Moreover, it is possible to freeze the video of a sender. This is an interesting option if processing and displaying the video overloads the computer or more attention should be paid to another sender. It is difficult to recognize details because the video window of the main window is very small. VIC offers the option of displaying a user’s video window in different enlarged formats (see Figure 7.10). The video windows can be selected individually. Furthermore, the enlarged window does not always have to display the video of the same sender. VIC can switch automatically between the videos of different participants. This switchover can be timer-controlled or initiated when a participant begins to talk and, thus, sends audio data. This option is particularly useful for videoconferences with multiple participants. However, you should not forget that VIC offers no audio

Figure 7.10 Live transmission of a shuttle mission using VIC.

7.2 MBone Applications support. It only accesses information from a compatible audio application that must be active at the same time. These applications include Visual Audio Tool and Robust Audio Tool. Like many other MBone applications, VIC runs on top of RTP. Therefore, information about the transmission quality of a stream is obtainable. Quality-of-service guarantees, on the other hand, can only be given when special protocols are used (see Chapter 4). VIC is available at www-nrg.ee.lbl.gov/vic/.

7.2.3 Visual Audio Tool In some respects, Visual Audio Tool (VAT) is the counterpart of VIC. It also was developed in the Lawrence Berkeley Laboratory. VAT allows audioconferences to take place between multiple participants. The name of each participant or a different character string selected by the participant is displayed, which facilitates easy identification of each participant. If the participant is active, an indication is given through the use of different colors in the main window. Misunderstandings are avoided because it is always obvious who the current speaker is. This creates a situation similar to a face-to-face conversation. However, this only applies so long as the number of participants is relatively small. Otherwise this can easily be a confusing way to present the participants. VAT does not offer a possibility for changing the type of display. One option would have been to select fewer participants. When a larger number of participants is involved, this application is more appropriate for pure receiving (such as a talk) than for interactive cooperation. With teamwork, group size normally tends to be small. Therefore, VAT is a good option in this case. Additional information about participants can be obtained through selection of the corresponding field in the main window (see Figure 7.11). The information includes the email address of the participant. In terms of protocols, VAT also runs on top of RTP, and RTCP is used to obtain information about transmission quality through RTCP receiver reports. An audio transmission requires less bandwidth than a video transmission. Nevertheless, this bandwidth is not always available on the MBone. VAT therefore supports different data formats that allow an adaptation to prevailing network conditions (see Table 7.1). The first three formats (PCM, PCM2, and PCM4) listed in the table only differ in the number of audio samples sent in an RTP data unit.

279

280

Chapter 7 — MBone—The Multicast Backbone of the Internet

Figure 7.11 VAT main window.

Table 7.1 VAT data formats. Data format

Data rate

Sample length

Number of samples per RTP data unit

PCM

78 kbit/s

20 ms

160

PCM2

72 kbit/s

40 ms

320

PCM4

68 kbit/s

80 ms

640

DVI

46 kbit/s

20 ms

160

DVI2

39 kbit/s

40 ms

320

DVI4

36 kbit/s

80 ms

640

GSM

17 kbit/s

80 ms

640

LPC4

96 kbit/s

80 ms

640

The recording time per RTP data unit and the resulting number of samples per data unit appear in the third and fourth columns of the table. The different data rates result from the different protocol overheads. The fewer RTP data units issued, the lower is the overhead created by the part added by the protocol. However, as the number of samples in a data unit rises, so too does the tendency toward transmission loss. Loss resulting from long data units can easily have a serious impact on the receiver’s perception level because a larger proportion of user data is lost when data units are too long. VAT is available at www-nrg.ee.lbl.gov/vat/.

7.2 MBone Applications

281

7.2.4 Robust Audio Tool The Robust Audio Tool (RAT) offers functionality similar to VAT. It enables audioconferences to take place between multiple participants. Figure 7.12 presents the main window of the application. The participants of the session are listed in the left-hand area of the window. Two controls for adjusting the volume during playback or recording are on the right. For the transport of audio data, RAT is run on top of RTP. Thus the applications RAT and VAT are compatible. They can be used alongside each other in the same session. In contrast to VAT, however, RAT incorporates an error correction mechanism. This is the origin of the name Robust Audio Tool. However, a very simple method of error correction is currently available. If a data unit is not available at playback time, the last data unit received is played back again. This can have a positive effect on user perception if losses are not too high. Furthermore, RAT enables sessions to be recorded, stored in a file, and played back at a later time. RAT can also be used as an audio gateway. In this operating mode, incoming audio data can be converted to a different data format. The audio data is then sent to a different multicast group. This functionality is useful if some participants are located in a network domain with a higher loss rate. Interference could be reduced through the conversion of PCM4 into PCM-coded data, for instance. RAT is available at mice.ed.ac.uk/mice/.

Figure 7.12 RAT main window.

Error correction

Recording sessions Audio gateway

282

Chapter 7 — MBone—The Multicast Backbone of the Internet

7.2.5 Free Phone Free Phone (fphone) (see Figure 7.13) is another application that permits audioconferences. If certain functions of fphone are ignored, this application is compatible with popular MBone audio applications such as VAT and RAT. The fphone functions referred to are discussed below. This application, however, has a different goal. As the name implies, fphone is mainly designed for Internet telephony. Therefore, it provides an address book function (see Figure 7.14) that allows frequently used addresses to be stored and selected. An entry in the address book enables a connection to be set up to the corresponding user. There is no need to enter the address again. These addresses can be multicast addresses with port numbers and TTL threshold values or they can be addresses of the form Name@Host, similar to an email address. With the latter type of address, a point-to-point connection is established to the participant. If the participant can be reached, they can decide whether they want to accept the call. This option is not available if a multicast address is used, because no specific participant is addressed and explicitly called.

Figure 7.13 Audio conference using fphone.

7.2 MBone Applications

Figure 7.14 Address book for fphone.

Figure 7.15 Configuration of audio codec.

The application offers a range of setting options for the audio codec (see Figure 7.15). Multiple audio compression techniques and formats are available (PCM, ADPCM, VADPCM, GSM). It is also possible to adjust the size of data units between 80 and 800 samples. In addition, fphone offers higher sampling rates than RAT or VAT, which provides better presentation quality. Audio quality can even be increased to CD quality (48 kHz sampling frequency, stereo). VAT and

283

284

Chapter 7 — MBone—The Multicast Backbone of the Internet RAT only offer single-channel telephone quality. Additionally, a redundant audio signal can be sent for error recovery. This would partly compensate for losses. However, the transmission of an additional audio signal increases network load. This could possibly result in higher loss rates, which would then partially or totally cancel out the positive effect. Moreover, fphone offers a semiautomatic mode for coding technique selection. In this mode a coding technique, based on a compression level adjustable to 12 levels, is selected automatically by fphone. Lastly, fphone also offers an automatic mode for an independent selection of the codec parameters. These operating modes allow the use of fphone by users who are less familiar with the characteristics of audio coding. fphone is available at www-sop.inria.fr/rodeo/fphone/.

7.2.6 Whiteboard Interactive conferences often require more than just audio-visual contact between participants. A talk is normally accompanied by overhead transparencies. Sometimes it is also helpful if documents can be processed or even developed by more than one participant. The whiteboard (WB) offers at least some help. A whiteboard implements a distributed fixed-sized drawing tool (see Figure 7.16). The tool can be used to present simple drawings and documents in PostScript format. In this context, “distributed” means that all participants view the same drawing area. Changes made to the drawing area by one participant are also forwarded to the other participants. Thus changes are visible to all participants (WYSIWIS). Only one drawing area can be displayed at any given time. However, it is possible to add new drawing surfaces, called pages, or to switch between pages. The drawing elements supported are lines, arrows, rectangles, ellipses, and text. Drawing elements can also be used in different colors. It is therefore possible to distinguish participants if each one uses a different color. Since the number of colors is limited, this only works if the number of active participants is kept to relatively low. This is normally the case with interactive conferences, anyway. Drawing elements can also be added to loaded PostScript documents—for example, to mark places in a text. They can also be deleted or shifted, albeit only by the participant that drew the element. A simple form of access

7.2 MBone Applications

285

Figure 7.16 Whiteboard (WB).

protection is thereby implemented. Other mechanisms for access control are not provided. Applications for audio and video transmission use unreliable protocols for data transfer. By contrast, WB requires reliable transmission. With unreliable multicast, the pages displayed to participants would no longer be consistent if the data units that propagate page changes were lost. Cooperative work would then not be possible. Therefore,

286

Chapter 7 — MBone—The Multicast Backbone of the Internet a reliable transport protocol was developed in conjunction with the whiteboard. WB runs on top of this protocol, which is called SRM (Scalable Reliable Multicast); (see Section 6.6). To provide for a simple mapping between the sequence numbers of SRM and the pages on WB, the designers of SRM decided to take pages as the sequence number space for SRM. Therefore, an SRM sequence number consists of two parts. The first part identifies the WB page the data belongs to, the second part orders the data units of a single page. WB is available at www-nrg.ee.lbl.gov/wb/.

7.2.7 Network Text Editor Network Text Editor (NTE) was developed by Mark Handley as part of the MICE (www-mice.cs.ucl.ac.uk/multimedia/projects/mice/ ) and MERCI (www-mice.cs.ucl.ac.uk/multimedia/projects/ ) projects at University College in London. NTE allows texts to be worked on by different participants. As with the whiteboard, all conference participants see the same text. Changes made by one participant are played back by the other group members. Thus, NTE likewise pursues the WYSIWIS concept. In contrast to WB, drawing elements are not supported. Instead, NTE is purely a text editor. Furthermore, only one text can be worked on at a time. Unlike WB, NTE does not offer different pages. NTE uses a proprietary protocol on top of UDP [77]. NTE offers different colors that group members can use to distinguish their contributions. NTE also indicates which participant is currently editing the text (see Figure 7.17). The status line shows which participant has added a particular block of text and which participant was the last one to edit the text. This application does not provide access protection. However, participants can select an option that enables them to protect their texts from changes by other participants. Participants must agree on a social protocol to guarantee that an orderly procedure is followed during a session. NTE is available at mice.ed.ac.uk/mice/.

7.2.8 Session Directory So far this chapter has introduced a number of applications for implementing videoconferences or transmitting and receiving audio and video streams. Normally, each medium involved in a session is sent to a separate multicast group.

7.2 MBone Applications

287

Figure 7.17 Network text editor (NTE).

A typical videoconference with video, audio, and whiteboard applications involves three media. Normally, a potential participant in this videoconference must join three multicast groups. This requires knowledge of the group addresses. Furthermore, a port number must be known for each of the streams. These addresses are easy to obtain by telephone or email for a private conference within a company. However, this does not apply, for example, to the transmission worldwide of space shuttle missions, which are frequently multicasted on the MBone. One solution is a reserved multicast group in which periodic transmissions on the MBone are announced. This implements a service that is comparable to an event calendar. The application Session Directory (SDR) is used to display and initiate information on current or future sessions sent in this multicast group.

288

Chapter 7 — MBone—The Multicast Backbone of the Internet The main window (see Figure 7.18) lists the sessions. The click of an entry displays other information, such as the time when a session is active, the media involved, and the addresses of the multicast groups (see Figure 7.19). Moreover, SDR can start the relevant applications using the corresponding parameters. This greatly simplifies the

Figure 7.18 MBone sessions in SDR.

Figure 7.19 Information on a session.

7.2 MBone Applications operation of the different applications. As another feature, SDR enables the user to invite other parties to a session. To this end, SDR uses SIP (see Section 7.2.11). SDR also announces sessions on the MBone, which requires identification of the participating media. Selection of the transmission range is also possible. SDR supports the user through the recommendation of multicast addresses. Figure 7.20 shows the setup of a conference with a video and an audio stream. The audio streams are transmitted with multicast address 239.255.113.90/26252. The video streams are sent to the multicast address with the address 239.255.166.68/50240. Lastly, the address 239.255.54.105/48980 is used for the whiteboard data. (The number after the slash is the port number.) SDR is available at mice.ed.ac.uk/mice/.

7.2.9 Session Announcement Protocol The session directory is based on the Session Announcement Protocol (SAP) [80], which was developed to announce sessions on the MBone. The current version number is 2. SAP uses UDP as a transport service and is based on periodically transmitted announcements. The announcement is sent with the same scope as the session it is announcing, ensuring that the recipients of an announcement can also receive the announced session. Furthermore, by keeping the announcement as local as possible, network load is reduced. To ensure that the announcement is sent with the same scope as the session itself, the following rules apply. IPv4 global scope sessions use multicast addresses in the range 224.2.128.0 to 224.2.255.255, with SAP announcements being sent to 224.2.127.254 (224.2.127.255 is used by the obsolete version 0 of the protocol). For IPv4 administrative scope sessions, the highest multicast address in the relevant administrative scope zone is used. For example, if the scope range is 239.16.32.0 to 239.16.33.255, then 239.16.33.255 is used for SAP announcements. Of course, this assumes that the listener knows which scope zone they are in (e.g., through MZAP). The port for SAP announcements is fixed (9875). For IPv6, other addresses are used; refer to the draft for details. Furthermore, the authors recommend that the interval between sending the announcements should be adapted to the overall number of announcements. The aim of this adaptation is to reduce network load created by announcements.

289

Figure 7.20 Creating a session using SDR.

7.2 MBone Applications The protocol includes data units for the following: ■ ■

Session announcements Cancellation of session announcements

A session announcement essentially comprises a key and a session description. The key, together with the address of the sender, uniquely identifies the announcement. The session description forms the user data of the data unit. SAP does not define the format of the session description. However, it is assumed that SDP (see below) is used for the session descriptions. Furthermore, the data unit can contain additional fields for the authentication of the sender and encryption of the session description. A session announcement remains valid until ■ ■

■

the end time of the session description has been exceeded, no new announcement is received during a period of 10 announcement intervals, or a data unit to cancel the session is received.

A simple way to change an announcement is through transmission of the changed announcement. In this case, the key should also be changed so receivers immediately recognize that a change has been made.

7.2.10 Session Description Protocol SDP (Session Description Protocol) [76] specifies the format of the session descriptions used by SDR. For this purpose it uses a text-based notation. Since the notation is text-based, all information appears as character strings preceded by a key to identify the entry. Some of these keys and their significance are listed in Tables 7.2, 7.3, and 7.4. This is not an exhaustive list of defined keys. In SDP a session description includes the following details: ■ ■ ■

Name and purpose of the session (see Table 7.2) Times when the session is active (see Table 7.3) The media streams used in the session and the information required for receiving the session (see Table 7.4)

291

292

Chapter 7 — MBone—The Multicast Backbone of the Internet Table 7.2 Session description. Key

Significance

Optional

v

SDP protocol version

o

Session initiator and identifier

s

Session name

i

Other information

*

e

Email address

*

p

Telephone number

*

c

Connection information

*

b

Bandwidth requirements

*

Table 7.3 Time description. Key

Significance

t

Session start and end

r

Retransmissions

Optional *

Table 7.4 Media description. Key

Significance

Optional

m

Media designation and transport address

c

Connection information

*

a

Media attributes

*

b

Bandwidth required

*

In addition, the description can include information about the bandwidth of the streams. Example 7.1 represents a session description generated by SDR. The description uses version 0 of SDP. The organizer of the session has the user name wittman, the name of the session is Book discussion. The email address of a contact person is also provided. The start and end times of the session are given as NTP [103] time stamps, indicating the time as seconds from 1 January 1900. This is followed by an attribute indicating the tool used to generate the announcement. The next attribute indicates the type of meeting. Descriptions of the media streams follow. Three media streams are used in the session. The first

7.2 MBone Applications Example 7.1 Session description using SDP. o=wittmann 3123394133 3123394460 IN IP4 134.169.34.116 s=Book discussion i=Discussion about chapter MBone p=Ralph Wittmann (TU Braunschweig) ++49 531 391–7545 e=Ralph Wittmann (TU Braunschweig) t=3123392400 3123399600 a=tool:sdr v2.4a6 a=type:meeting m=audio 30870 RTP/AVP 0 c=IN IP4 239.255.36.26/15 m=video 56114 RTP/AVP 31 c=IN IP4 239.255.27.44/15 m=whiteboard 43843 udp wb c=IN IP4 239.255.105.10/15 a=orient:portrait

one is an audio stream that is sent on port number 30870 with RTP and audio/video profiles. The number that follows gives the format of the audio data. The 0 in the audio/video profile corresponds to the PCM format. The group address is on the next line. In this example, it is Internet address 239.255.36.26. The TTL scope is given after the slash (TTL = 15). The second media stream is a video stream that is also transmitted with RTP and the audio/video profile. Port number 56114 is provided for this stream. This video is sent as an H.261 compressed stream (user data type 31). The description of the third data stream follows the group address details. The data stream consists of data generated by a whiteboard, the WB. The data is transmitted per UDP. The group address and the range of this stream also appear in the example. The last line represents an application-specific attribute and indicates the orientation of the WB pages. This information can be used by SDR at the start of an application.

7.2.11 Session Initiation Protocol The Session Initiation Protocol (SIP) [79] is a protocol for initiation of multimedia sessions and invitation of participants. Like SDP and SAP,

293

294

Chapter 7 — MBone—The Multicast Backbone of the Internet it is part of the work of the MMUSIC working group of the IETF. Today, SIP is used by many conferencing tools for invitation of participants. SIP covers five aspects related to multimedia session establishment and termination: ■

■

■

■

■

SIP transaction

SIP URL

User location: determination of the end systems to be used for communication User capabilities: determination of the media and media parameters to be used User availability: determination of the willingness of the called party to participate in the session Call setup: establishment of call parameters at both called and calling party Call handling: handling of the call including transfer and termination

SIP is an application layer client-server protocol; that is, every SIP operation is initiated by a client requesting a call to a server. In some respects SIP is similar to HTTP [110], but besides TCP SIP can also be used with UDP unicast and multicast as the underlying transport service. Because UDP is unreliable, SIP uses a simple ARQ scheme to provide reliable transfer of SIP requests. If no response is being received within a certain time interval, the request is retransmitted. A request together with its retransmissions in case of packet loss and the response triggered by the request forms a SIP transaction. SIP response messages carry a status code indicating the result of the associated request. A status code consists of a numeric value and a textual phrase. Different groups of status codes are defined for SIP. Final responses complete a transaction: for example, 200 OK indicates success; 404 Not Found indicates that the user does not exist in the specified domain. Informational responses do not complete a transaction and are used to report the temporary status of the request: for example, 180 Ringing indicates that the user is informed of the call; 182 Queued indicates that the call is queued since other calls are currently being processed. Since SIP is a protocol for call control, the entities addressed by SIP are users and hosts, identified by a SIP URL. An SIP URL takes a form similar to a mailto or telnet URL (i.e., user@host). The user part is a user name or telephone number. The latter allows calling PSTN users, provided a telephony gateway is available. The host part is a domain name or a numeric network address. A user’s SIP address can be obtained by any means outside the scope of SIP. For instance, it may be

7.2 MBone Applications

295

guessed from their mail address. Instead of describing the exact syntax of SIP URLs, a few examples are given: sip:[email protected] sip:+49–531–391–[email protected];user=phone sip:[email protected]?subject=project

The first URL is the minimal form of a SIP URL, consisting of the scheme indicator sip and a user address only (see [21] for a general URL syntax description). The second example addresses a telephone subscriber as indicated by the user field. The host part identifies the telephony gateway gateway.com. The last URL includes further header information, in this case a subject description. SIP supports six requests, called methods: ■ ■ ■ ■ ■ ■

INVITE ACK BYE CANCEL OPTIONS REGISTER

The INVITE request indicates that a user or service is being invited to participate in a session. The message body typically contains a description of the session the callee is invited to and should provide the called party with enough information to join the session. The format of the description is out of the scope of SIP. Any description format may be used, for instance, SDP. The host part of the callee’s SIP URL may address a SIP server, which accepts calls and directly rings the called party. This user agent server may run at the host the callee is logged in. Calling the user agent server directly requires that the SIP address of a user change every time a user changes its location. Therefore, a proxy server may be used, which issues an INVITE request on behalf of another server and returns the result of that request. Thus, a proxy server, receiving a call for a user not locally reachable, determines one or more SIP addresses for the callee and issues INVITE requests to contact the callee. Moreover, a SIP server may redirect calls. With this mode of operation, the SIP address is also mapped to one or more addresses. But instead of issuing its own requests, a redirect server returns the obtained addresses. The ACK request confirms that the client has received a final response to an INVITE request. It is only used with INVITE requests.

Methods

296

Chapter 7 — MBone—The Multicast Backbone of the Internet

Example

The client uses a BYE request to indicate to the server that it wishes to release the call. It may be issued by either caller or callee. The CANCEL request cancels the corresponding pending request. A request is considered pending until a final response is received. With the OPTIONS request, a server is being queried with respect to its capabilities. With a REGISTER request, a user is registered at an SIP server. The request contains the address at which a user is reachable. Subsequent calls should be directed to this address. A user may register itself or may be registered by another party. For example, a secretary may register the location of his boss during a business trip. It is possible that a user is registered at different locations. In this case, SIP provides methods to try to contact the user at each registered location. Note that a server may use other location services to locate a callee, like LDAP [168] or WHOIS [84]. Figure 7.21 depicts an example of an SIP invitation involving a proxy server. Martina (sip:[email protected]), currently logged in at idefix.cs.tu-bs.de, invites Joe Doe (sip:[email protected]) to a multimedia conference. Her user agent directs an INVITE request to the SIP server obtained from Joe’s SIP URL. A part of the message header is shown ( 1 ). The message body, which contains the session description, is omitted. The Call-ID field uniquely identifies the invitation and is generated by the initiating client. The CSeq field consists of the name of the request method and a single decimal number chosen by the requesting client, so that the CSeq field is unique for a single value of Call-ID. It is part of every message header and represents a sequence number for SIP messages. The Via field contains a trace of the path followed by the request so far. In this example the Via field contains the domain name of the client host issuing the request and the transport protocol being used. Receiving the request, the SIP proxy server sip.big.com queries a location service (which uses non-SIP protocols) to locate Joe ( 2 , 3 ). The obtained location is used to generate a new invitation request. This message carries the same Call-ID as the already received request, since it is part of the same invitation. A new Via field is added to the header with the server’s own address to indicate the path of the invitation. The request is directed to the obtained server, in this case a user agent server ( 4 ). The user agent server indicates the call and Joe accepts it. Thus, a positive response (status code 200 OK) is returned to the proxy server ( 5 ). Now, the proxy server can send a positive response back to the client indicating that Joe accepts the call ( 6 ).

4

1 INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP idefix.cs.tu-bs.de From: M. Zitterbart To: J. Doe Call-ID: [email protected] CSeq: 1 INVITE SIP/2.0 200 OK 6 Via: SIP/2.0/UDP idefix.cs.tu-bs.de From: M. Zitterbart To: J. Doe Call-ID: [email protected] CSeq: 1 INVITE

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP sip.big.com Via: SIP/2.0/UDP idefix.cs.tu-bs.de From: M. Zitterbart To: J. Doe Call-ID: [email protected] CSeq: 1 INVITE SIP/2.0 200 OK 5 Via: SIP/2.0/UDP sip.big.com Via: SIP/2.0/UDP idefix.cs.tu-bs.de From: M. Zitterbart To: J.Doe Call-ID: [email protected] CSeq: 1 INVITE

2 [email protected]

3 [email protected] SIP request SIP response Non-SIP protocol

Location Service 7

8

ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP idefix.cs.tu-bs.de From: M. Zitterbart To: J. Doe Call-ID: [email protected] CSeq: 1 ACK

ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/UDPsip.big.com From: M. Zitterbart To: J. Doe Call-ID: [email protected] CSeq: 1 ACK

10 SIP/2.0 200 OK Via: SIP/2.0/UDP idefix.cs.tu-bs.de From: M. Zitterbart To: J. Doe Call-ID: [email protected] CSeq: 1 ACK

9 SIP/2.0 200 OK Via: SIP/2.0/UDP sip.big.com From: M. Zitterbart To: J. Doe Call-ID: [email protected] CSeq: 1 ACK Figure 7.21 Example of an SIP Invitation.

298

Chapter 7 — MBone—The Multicast Backbone of the Internet With step 7 the client confirms that it has received a final response to the INVITE request. This triggers the generation of an ACK request from the proxy server to the user agent server ( 8 ). Finally, the user agent server and the proxy server confirm the respective request ( 9 , 10 ).

7.2.12 Conference Manager Conference Manager (CONFMAN) is an application that was developed to manage and run computer-supported conferences. Unlike the session directory, which announces sessions on the MBone, this application explicitly invites participants to a conference. CONFMAN uses SIP as well as its own protocol for invitation. In addition to a main window (see Figure 7.22), the application basically consists of the following modules: ■ ■ ■ ■

Address management

Conference management

Address management Conference management Telephone module Application management

Address management maintains the addresses of potential conference participants. It consists of an address editor, which processes the addresses, and an address book containing the addresses. The information in the address book comprises complete names, Internet addresses, and other selectable fields. The conference management module (see Figure 7.23) initiates conferences. It requires a list of participants, which can be compiled using the address book, plus details about the start time and the conference applications used. The configuration can be changed during

Figure 7.22 Conference Manager.

7.2 MBone Applications

299

Figure 7.23 Conference management.

a running conference. Conference management notifies the participants listed at the start of the conference. If required, the Conference Manager automatically starts the applications needed for the conference. The Conference Manager distinguishes between two types of conferences: ■ ■

Closed conferences Multicast conferences

In closed conferences, data streams are distributed through a conference server over point-to-point connections. Multicasting does not take place. This type of conference is offered if a multicast infrastructure does not exist or if privacy is important. For the privacy of multicast conferences the conference manager supports data encryption through the administration and allocation of keys. Telephone management is a simplified form of conference management. It is designed to initiate conferences between two participants. For this purpose a participant is selected from the address book (see Figure 7.24), and the conference is initiated by CONFMAN. The applications used in such a conference can also be dialed up. Therefore, the communication does not need to be restricted to a single medium.

Telephone management

300

Chapter 7 — MBone—The Multicast Backbone of the Internet

Figure 7.24 Address book.

Application management configures conference applications. The right configuration of an application can be tested using application management. CONFMAN is available at www.rvs.uni-hannover.de/products/ confman/.

7.2.13 Multimedia Conference Control Like some of the applications presented, this application was developed within the framework of the MICE project. Like CONFMAN described above, Multimedia Conference Control (MMCC) is part of the group of applications for conference control. This application too is used to create sessions. An initiator uses MMCC to initiate a session and selects the necessary applications for transmitting and displaying the media for the session. The second step involves establishing the session start time. Clearly the potential participants still have to be named (see Figure 7.25). At the given start time the participants of a session are notified through a window and the selected applications started. MMCC can also be used to leave a session. A graphical user interface is used to carry out these functions and to monitor the conference while it is running. Figure 7.26 shows the main window of the application.

Figure 7.25 Conference setup.

Figure 7.26 MMCC main window.

302

Chapter 7 — MBone—The Multicast Backbone of the Internet MMCC offers no further support. Therefore, it has limited functionality compared to similar applications, such as CONFMAN. For example, it lacks an address book function. MMCC is available at mice.ed.ac.uk/mice/.

7.2.14 Inria Videoconferencing System The Inria Videoconferencing System (IVS) [153] is an application that was developed at INRIA in France. IVS supports the transmission of video and audio streams. It has been used successfully in a number of European research projects. Figure 7.27 shows the main window of the application. In contrast to VIC or VAT, IVS is an integrated application because it allows the transmission of both video and audio data. IVS consists of an audio codec, which supports PCM and ADPCM, and an H.261 codec for video data. Therefore, only one application is started instead of two different ones, which simplifies the handling of the tool. The system is available for a whole range of operating systems and computer architectures and places a minimal demand on hardware. The H.261 codec contains rate control. The codec reacts to growing traffic loads on the network and resulting data loss through a reduction of the exit rate. This adaptation is based on feedback information delivered by RTCP. IVS is available at www-sop.inria.fr/rodeo/ivs/.

Figure 7.27 IVS main window.

7.3 MBone Tools

303

7.3 MBone Tools A wide range of tools and applications is now available for the MBone. A selection of these tools and applications is introduced in this chapter, with the focus on those for Unix systems. The selection presented does not even come close to being comprehensive because the list of new tools and applications is constantly growing. Mrouted, mrinfo and mtrace are available via ftp at ftp:// ftp.parc.xerox.com/pub/net-research/ipmulti/.

7.3.1 Mrouted Connection to the MBone is currently still possible with Mrouted (Multicast Routing Daemon). As described previously, the MBone is a virtual overlay network that encapsulates multicast IP data units into unicast IP data units. However, this encapsulation should only be regarded as an interim solution. It is necessary because intermediate systems on the Internet are not yet all multicast enabled. Mrouted is responsible for the following tasks: ■ ■

Multicast routing Tunnel configuration

Although native connections to the MBone are available in some domains, in many domains an application for a tunnel is still required for connection to the MBone. This means finding a site that is already connected to the MBone and is willing to operate a tunnel to the local mrouter. Normally this application is made to the organization responsible for the administration of the respective MBone subnetwork. Information about the configuration of Mrouted is obtained from this organization. However, the application is less formal that it might appear. An email with information about the local mrouter sent to the other site’s responsible network administrator normally suffices. Additional information about connection to the MBone is available on the Internet under www.mbone.com/mbone/references.html. The configuration of a tunnel comprises the following: ■ ■

How to connect to the MBone

IP addresses of the tunnel start and end points Metric

Tunnel configuration

304

Chapter 7 — MBone—The Multicast Backbone of the Internet ■ ■ ■

Metric

Threshold value Boundaries of administrative domains Rate limitation

The IP address of the interface of the local router is used at the receiving end of the tunnel. The IP address assigned to the interface of the remote router is given as the destination end. The metric indicates the cost of the tunnel. This value affects the multicast routing and influences the path selection by the routing algorithm from different options offered (see Chapter 3). The threshold value provides the TTL value of an IP data unit that must be exceeded before the data unit is forwarded. The administrative zones, the boundaries of which are formed by the tunnel of the mrouter, determine the range restriction. The zone is indicated by the multicast addresses for which it is responsible. The rate parameter provides the maximum bandwidth of a tunnel in order to limit the proportion of multicast traffic compared to overall traffic. Traffic that exceeds this limit cannot be forwarded by the mrouter.

7.3.2 Mrinfo Mrinfo supplies information about the configuration of a multicast router. This information relates to the tunnels connected to the mrouter and the configuration of them, including threshold value and metric. However, the mrouter is not necessarily the local mrouter. Instead it is possible to determine the configuration of most mrouters in the MBone. This may present a security problem, but what should not be overlooked is that the MBone is still in the testing stage. This means that information about the configuration of the MBone takes precedence over security aspects. What is important is that this tool can be used to identify wrongly configured multicast routers. However, some routers are configured to filter out IGMP messages used to obtain the mrouter configuration information. For each tunnel attached to a router, an Mrinfo invocation provides the following: the configuration parameters mentioned in the previous section, the state of the tunnel, and the routing algorithm. Example 7.2 shows the result of a Mrinfo invocation for an mrouter in the broadband research network (B-WIN). This particular router is located in Stuttgart, Germany. The printout shows that the mrouter is connected

7.3 MBone Tools

305

Example 7.2 Mrinfo printout. (orpheus:⬃)mrinfo mr-stuttgart1.win-ip.dfn.de 188.1.200.5 (mr-stuttgart1.win-ip.dfn.de) [version 11.1,prune,mtrace,snmp]: 188.1.200.1 - 188.1.200.2 (mr-koeln1.win-ip.dfn.de) [2/32/tunnel/pim] 188.1.200.5 - 188.1.200.6 (mr-nuernberg1.win-ip.dfn.de) [2/32/tunnel/pim] 188.1.201.1 - 129.143.70.7 (st1-mbone.BelWue.DE) [1/32/tunnel/pim] 193.174.226.254 - 193.174.75.174 (WS-Stu1.WiN-IP.DFN.DE) [1/32/tunnel/ querier] 195.206.64.54 - 0.0.0.0 (local) [1/48/tunnel/pim/disabled/down/leaf] 188.1.201.9 - 188.1.201.10 (188.1.201.10) [1/32/tunnel/pim] 188.1.201.13 - 134.96.100.36 (c70b36.rz.uni-sb.de) [1/32/tunnel/pim] 193.174.226.2 - 193.203.254.34 (de-ws.ten-34.net) [4/48/tunnel] 193.174.226.2 - 193.174.75.154 (WS-Kar1.WiN-IP.DFN.DE) [1/32/tunnel/ querier]

to nine tunnels. The first line gives the mrouter involved, the version of the mrouter, and other settings for the mrouter. The other lines give details about the attached tunnels. The second line states that a tunnel to the router with IP address 188.1.200.2 exists. The notation in parentheses is the full qualified domain name of this address in the DNS. The metric 2 and a TTL threshold value of 32 are allocated to this tunnel. PIM is used as the routing protocol. The remaining lines are set up in a similar way. The entry querier appears in the fifth line. This information indicates that the router is issuing IGMP membership queries on the attached interfaces. Therefore, it is querying whether receivers exist for a certain multicast address. Furthermore, the entry leaf (line 6) indicates that the router is not operating any other tunnels and that the subnets connected to it form the leaf in a multicast tree. Lastly, the entry disabled/down means that the tunnel was switched off and is currently not active.

7.3.3 Mtrace The tool Mtrace is used to obtain statistical data about multicast traffic on the MBone. It allows the path of data units to be traced between two systems. For each link it provides statistical data and information for configuration. Mtrace is particularly useful when it is important to determine where packet losses are occurring on a network. The data provides pointers on locating the errors.

306

Chapter 7 — MBone—The Multicast Backbone of the Internet

Example 7.3 Mtrace printout. (orpheus:⬃)mtrace 131.188.30.42 239.192.139.43 Mtrace from 131.188.30.42 to 134.169.34.21 via group 239.192.139.43 Querying full reverse path . . . 0 orpheus (134.169.34.21) -1 orpheus (134.169.34.21) DVMRP thresh^ 1 -2 ciscobs.rz.tu-bs.de (134.169.246.1) PIM/Special thresh^ 32 -3 mr-hannover1.win-ip.dfn.de (188.1.203.29) PIM/Special thresh^ 32 -4 mr-koeln1.win-ip.dfn.de (188.1.200.9) PIM/Special thresh^ 32 -5 mr-stuttgart1.win-ip.dfn.de (188.1.200.1) PIM thresh^ 32 -6 mr-nuernberg1.win-ip.dfn.de (188.1.200.6) PIM thresh^ 32 Reached RP/ Core Round trip time 548 ms; total ttl of 37 required. Waiting to accumulate statistics . . . Results after 10 seconds: Source Response Dest Overall Packet Statistics For Traffic From * * * 224.0.1.32 Packet 131.188.30.42 To 239.192.139.43 v __/ rtt 335 ms Rate Lost/Sent = Pct Rate 188.1.200.6 mr-nuernberg1.win-ip.dfn.de Reached RP/Core v ^ ttl 33 127 pps 0/0 = —% 0 pps 188.1.200.5 188.1.200.1 mr-stuttgart1.win-ip.dfn.de v ^ ttl 34 550 pps 0/0 = —% 0 pps 188.1.200.2 188.1.200.9 mr-koeln1.win-ip.dfn.de v ^ ttl 35 412 pps 0/0 = —% 0 pps 188.1.200.10 188.1.203.29 mr-hannover1.win-ip.dfn.de v ^ ttl 36 60 pps ?/0 0 pps 134.169.3.130 134.169.246.1 ciscobs.rz.tu-bs.de v ^ ttl 37 60 pps 0/0 = —% 0 pps 134.169.34.21 orpheus v \__ ttl 37 53 pps 134.169.34.21 134.169.34.21 Receiver Query Source

7.3 MBone Tools Mtrace operates in two phases. During the first, phase mrouters from sender to receiver are determined in the reverse sequence. The printout contains the addresses of the mrouters, the routing protocol, and the threshold value of the tunnel. Then the measured packet and loss rates are displayed. Example 7.3 presents an invocation of Mtrace. The program is called up through the address of the multicast sender and the group address. The path of the multicast data units appears in the upper part of the printout. In the example shown, the path runs across routers in Braunschweig, Hannover, Cologne, and Stuttgart to Nuremberg. In addition, the routing protocol and the TTL threshold value (thresh^) are given for each link. The example shows that PIM is being used in the backbone area, whereas DVMRP is used in the subnet of the Technical University of Braunschweig. The time that has expired between when the query was sent to the multicast sender and the receipt of a response from this sender is also indicated. Moreover, according to the printout, a threshold of at least 37 is required in order to reach the multicast sender. Therefore, the data units must be sent with this threshold value at least. Otherwise the local system will not be reached. In some cases this could already be the solution to the problem. This would be the case if no data units whatsoever are received by the respective sender. The path of the data units is shown again in the lower part of the printout. However, this time the IP addresses of all interfaces involved in the transmission are given. The TTL values of the data units on their path from the local system to the multicast sender in the example appear in the second column. The third column gives the rate of the data units achieved on the corresponding link. The numbers of sent and lost data units are provided in the following column. The loss rate shown in the sixth column can be derived from this information.

307

This Page Intentionally Left Blank

8 Outlook

G

roup communication is a broad subject that presents itself as a vital field of research. The issues that arise in this context are diverse and more or less cover the entire spectrum of telecommunications. This makes it difficult to implement and introduce corresponding technologies into global networks. Group communication impressively underlines the argument that a single protocol cannot support the entire spectrum of existing and emerging applications. Until recently the Internet was able to survive with only two different transport protocols, UDP and TCP. This most probably will not be the case in the future. The diverse types of groups and application requirements already make this less likely. Just consider the different reliability classes and the variety of transport protocols discussed in Chapter 6, along with the transport services they offer for groups. Therefore, the future is more apt to be determined by a multitude of protocols with different types of services. This, of course, raises the question of how these are to be provided economically. For example, we could imagine servers from which the required protocols can be downloaded. The concept behind such servers moves somewhat in the direction of programmable and active networks. This research area is currently attracting considerable interest on the Internet. The goal is to increase flexibility in the network and to support rapid service creation. The preceding chapters highlighted some of the problems of group communication for which concepts currently exist or where development is already quite advanced. Particular emphasis has been placed on IP multicast and the associated protocols because they are already used on the Internet. The MBone overlay network has been the subject of extensive development during the last few years. However, it has to be pointed out that multicast communication—even on the Internet—is currently mainly limited to research. It is still playing a

One-size-fits-all no longer applies

Rapid service creation

IP multicast and the MBone

310

Chapter 8 — Outlook minor role, albeit with increasing importance, in the industrial environment and specifically in product development. The problem with group communication is that there is still a whole range of open issues in many areas that have not yet been addressed properly. These include the following: ■ ■ ■ ■

Multicast routing and mobile systems Multicast and DiffServ Active networks to support group communication Group management with large dynamic groups

The list above is by no means complete. Instead its aim is to focus on some of the more interesting aspects involved. The points listed are discussed in some detail below. Aspects not covered specifically include flow and congestion control for multipeer communication [116], allocation and administration of group addresses, and QoS-based multicast routing.

8.1 Multicast Routing and Mobile Systems Mobile-IP provides the Internet with a protocol to support mobile systems at the IP level [118, 119]. Addressing is one inherent problem that has been resolved. In the case of mobile-IP, mobile systems are allocated two IP addresses: a home address and a mobile address, the foreign-IP address. The latter is the valid address in the current subnet being visited. The foreign-IP address is registered with a home agent. The home agent is thus able to forward data being sent to the original IP address of the system in the direction of the subnet just visited. Until now, mobile-IP has been restricted to point-to-point communication of mobile systems. Point-to-multipoint communication requires the addition of multicast routing to the process. Some unresolved issues still exist in this area. For example, if multicast routing is based on the RPF algorithm, it is highly unlikely that the data for a group will be forwarded to the new subnet in which the mobile system is located. The new subnet must be made known explicitly. An assurance is also needed that a multicast-enabled router is available in the new subnet. For mobility it is important that both receivers and senders can be mobile.

8.3 Active Networks for Supporting Group Communication

311

8.2 Multicast and DiffServ The relatively new topic of Differentiated Services, which is currently the subject of intense debate on the Internet, was introduced in Chapter 4. DiffServ can basically provide group communication through the use of IP multicast. Therefore, data is assigned group addresses and delivered to group members accordingly. DiffServ does not offer any other explicit support for group communication. DiffServ supports heterogeneous group communication implicitly, albeit not targeted to individual receiver requests. Heterogeneity occurs because of the dropping of data units at overloaded boundary routers. The dropping decision is based on the aggregated reservations existing between domains and the scheduling mechanisms used in the router. The effects of multicast within a domain that is bounded externally due to aggregated reservations have not yet been discussed. Traffic within a domain can be estimated according to the aggregated reservations for resources. However, in the case of multicast communication, branches of the multicast tree can exist within a domain. Consequently, the traffic volume in the domain can increase because data units are copied in the routers at branching points in the multicast tree, which can create points of traffic concentration. Such situations can lead to overloaded intermediate systems within a domain. No solutions for handling this problem exist. It should be mentioned that the subject of multicast is largely omitted from current discussions about Differentiated Services.

8.3 Active Networks for Supporting Group Communication The basic idea of active networks is that intermediate systems within networks are actively involved in the transfer of user data and support this transfer with improved services. Two basic approaches can be distinguished: ■ ■

Explicit signaling of services Implicit signaling of services

Increased traffic volume

312

Chapter 8 — Outlook

Explicit signaling

Implicit signaling

Heterogeneous quality of service

Dedicated error control

Local group management Subcasting

With an explicit signaling of services, the corresponding functionality is provided in the intermediate systems before the actual transfer of user data starts. This functionality can be applied during user data transfer. In this context we also refer to programmable networks. In the case of implicit signaling, by contrast, the data units explicitly carry the code needed to provide the functionality. These data units are often called capsules [148]. The usage spectrum of active networks is broad and, of course, also includes applications that are not based on group communication. Considering group communication, there could be an advantage to using active networks to provide heterogeneous quality of service. As discussed in Chapter 4, RSVP can be used to signal heterogeneous quality of service but does not provide it. Active networks could be used for this purpose. The functions required in adapting a data stream could be loaded and activated in the intermediate systems (routers or switches) through signaling. The data units flowing through such a node can then use the service provided by these functions. For example, the data rate of a video could be reduced before entering wireless transmission links. This way the video stream can be forwarded to and decoded by a wireless attached system (see Chapter 4). Another example supporting the use of active networks for group communication is the provision of dedicated error control. This is important for the support of heterogeneous multicast communication. Intermediate systems with a wireless outbound link could check their forward-error correction on a data stream forwarded across this link. The probability that data will be received correctly increases with forward-error correction. Active networks can also be used for the individual operation of wireless links through other error control and recovery algorithms (e.g., [66]). Functions for error control and recovery can also be used to implement local group managers, which will dramatically reduce the acknowledgment and feedback implosion at the sender (see Chapter 2). The topic of subcasting should briefly be mentioned in this context. This mechanism enables group administrators to contact subgroups over group addresses. Subcasting helps to improve the efficiency of error control and recovery. Flow and congestion control is another area that could benefit from a solution involving active networks [116]. This particularly applies to adaptive algorithms for response to or avoidance of congestion.

8.4 Group Management for Large Dynamic Groups

313

Since active networks are the subject of very current research, no comprehensive concepts or prototypes are yet available. However, it is easy to see that group communication in particular could derive considerable benefit from active networks. This also relates to the dynamic loadability of dedicated multicast support for certain applications in the network.

Complete solutions not yet available

8.4 Group Management for Large Dynamic Groups Group management is one of the necessary tasks required to support group communication. Current solutions can be viewed as more or less pragmatic approaches. Almost without exception, they are based on IGMP for the protocols currently used on the Internet and on the use of join and prune data units (see Chapter 3). Little attention has been given so far to group management of large groups that are highly dynamic. The challenge is in a scalable support of known groups (i.e., groups where the membership is known). IGMP-based algorithms are not capable of implementing known groups. However, many applications require this capability. Overall, it should be noted that until now most applications have tended to consider group management as a side issue, which could be linked to the fact that these applications are currently mainly used in the research area. However, we expect that efficient group management will soon be recognized as a main issue in the commercial environment.

This Page Intentionally Left Blank

Bibliography

[1]

A. Acharya, F. Ansari, M. Ott, and H. Sanneck. Dynamic QoS for IP switching using RSVP over IPSOFACTO. In Broadband European Networks and Multimedia Services, Syben 98, May 1998.

[2]

B. Aldred. Desktop Conferencing. McGraw-Hill, 1995.

[3]

A. Alles. ATM Internetworking. Technical report, Cisco, May 1995.

[4]

P. Almquist. Type of Service in the Internet Protocol Suite. RFC 1349, Internet Engineering Task Force, July 1992.

[5]

M. Ammar, G. Polyzos, and S. Tripathi. Network support for multimedia communications, guest editorial. IEEE Journal on Selected Areas in Communications (JSAC), 15(3):273–276, April 1997.

[6]

G. Armitage. Support for Multicast over UNI 3.0/3.1 Based ATM Networks. RFC 2022, Bellcore, November 1996.

[7]

G. Armitage. IP multicasting over ATM networks. IEEE Journal on Selected Areas in Communications (JSAC), 15(3):445– 457, April 1997.

[8]

G. Armitage. VENUS—Very Extensive Non-Unicast Service. RFC 2191, Internet Engineering Task Force, September 1997.

[9]

S. Armstrong, A. Freier, and K. Marzullo. Multicast Transport Protocol. RFC 1301, Xerox, Apple, Cornell, February 1992.

[10]

ATM Forum. ATM User-Network-Interface (UNI) Specification Version 3.1. Technical report, ATM Forum, June 1995.

[11]

ATM Forum. Baseline Text for MPOA. Technical report, ATM Forum, January 1996.

[12]

ATM Forum. Traffic Management Specification Version 4.0. Technical report, ATM Forum, April 1996.

316

Bibliography [13]

ATM Forum and Technical Committee. ATM User-Network Interface (UNI) Signalling Specfication, Version 4.0. Internet draft, IETF, August 1998.

[14]

J. Atwood, O. Catrina, J. Fenton, and W. Timothy Strayer. Reliable multicasting in the Xpress Transport Protocol. In Proceedings of the 21st Local Computer Networks Conference, pages 202–211, October 1996.

[15]

BackWeb. BackWeb Enterprise Push. Technical report, 1997. www.backweb.com/.

[16]

A. Ballardie. Core Based Trees (CBT) Multicast Routing Architecture. RFC 2201, September 1997.

[17]

A. Ballardie. Core Based Trees (CBT version 2) Multicast Routing: Protocol Specification. RFC 2189, September 1997.

[18]

A. Ballardie, B. Cain, and Z. Zhang. Core Based Trees (CBT version 3) Multicast Routing Protocol Specification. Internet draft, IETF, August 1998.

[19]

A. Ballardie, P. Francis, and J. Crowcraft. Core Based Trees (CBT): An architecture for scalable inter-domain multicast routing. In Proceedings of ACM SIGCOMM 93, September 1993.

[20]

Berkom Working Group, MMT. The Berkom-II Multimedia Transport System (MMT). Berkom technical report, 1995.

[21]

T. Berners-Lee, R. Fielding, and L. Masinter. RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. Technical report, August 1998.

[22]

S. Berson, and S. Vincent. Aggregation of Internet Integrated Services Model State. Internet draft, August 1998.

[23]

D. Bertsekas, and R. Gallaber. Data Networks. Prentice Hall, 1987.

[24]

U. Black. ATM: Foundation for Broadband Networks. Prentice Hall, 1995.

[25]

S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. An Architecture for Differentiated Services. RFC 2475, Internet Engineering Task Force, December 1998.

[26]

U. Borghoff, and J. Schlichter. Computer Supported Team Work (in German). Springer, 1995.

[27]

C. Bormann, J. Ott, H.-C. Gehrcke, T. Kerschat, and N. Seifert. MTP-2: Towards achieving the S.E.R.O. properties

Bibliography for multicast transport. In International Conference on Computer Communications and Networks (ICCCN 94), 1994. Also available at ftp://ftp.cs.tu-berlin.de/pub/local/kbs/ mtp/doc/sero.ps. [28]

C. Bormann, J. Ott, and N. Seifert. MTP/SO: Self-Organizing Multicast. Internet draft, Internet Engineering Task Force, July 1999. Also available at www.ietf.org/internet-drafts/ draft-bormann-mtp-so-02.txt.

[29]

R. Braden, D. Clark, J. Crowcraft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minsall, C. Patridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wrolawski, and L. Zhang. Recommendations on Queue Management and Congestion Avoidance in the Internet. Internet draft, www.internet2.edu/, March 1997.

[30]

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

[31]

R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin. Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification. RFC 2205, September 1997.

[32]

S. Bradner, and A. Mankin. Ipng Internet Protocol Next Generation. Addison-Wesley, 1996.

[33]

O. Brand, and M. Zitterbart. Control of Conference and Collaborative Applications (in German). PIK, Praxis der Informationsverarbeitung und Kommunikation, December 1997.

[34]

T. Braun. IPnG New Internet Services and Virtual Networks (in German). dpunkt, 1999.

[35]

T. Braun, S. Gumbrich, and H. Stüttgen. Comparison of concepts for IP-multicast over ATM. In Proceedings of ATM 96 Workshop, August 1996.

[36]

T. Braun, and M. Zitterbart. High Performance Communication II: Transport Services and Protocols (in German). Oldenburg, 1996.

[37]

C. Burger. Groupware Support for Distributed Applications (in German). dpunkt, 1997.

[38]

S. Casner, and S. Deering. First IETF Internet audiocast. ACM SIGCOMM Computer Communications Review, 22(3), July 1992.

317

318

Bibliography [39]

R. Cherukuri, and R. Onvural. Signaling in ATM Networks. Artech-House, 1997.

[40]

D. Clark, S. Shenker, and L. Zhang. Supporting real-time applications in an integrated services packet network: Architecture and mechanisms. ACM Computer Communications Review, 22(4), 1992.

[41]

D. Clark, and D. Tennenhouse. Architectural considerations for a new generation of protocols. In SIGCOMM Symposium on Communications Architectures and Protocols, pages 200– 208, September 1990.

[42]

D. Clark, and J. Wroclawski. An Approach to Service Allocation in the Internet. Internet draft, July 1997.

[43]

D. Comer. Internetworking with TCP/IP. Prentice Hall, 1991.

[44]

A. Conta, and S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (ipv6). RFC 1885, Internet Engineering Task Force, January 1996.

[45]

G. Coulouris, J. Dollimore, and T. Kindberg. Distributed Systems Concept and Design. Addison-Wesley, 1994.

[46]

D. Crocker. Standard for the Format of ARPA Internet Text Messages. RFC 822, Internet Engineering Task Force, August 1982.

[47]

S. Deering. Host Extensions for IP Multicasting. RFC 1112, Internet Engineering Task Force, August 1989.

[48]

S. Deering. Multicast Routing in a Datagram Internetwork. PhD thesis, Stanford University, Palo Alto, California, December 1991.

[49]

S. Deering, D. Estrin, D. Farinacci, M. Handley, A. Helmy, V. Jacobson, C. Liu, P. Sharmand, D. Thaler, and L. Wei. Protocol Independent Multicast-Sparse Mode (PIM-SM): Motivation and Architecture. draft-ietf-pim-arch-05.txt, IETF, August 1998.

[50]

S. Deering, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. RFC (Experimental) 2362, Internet Engineering Task Force, June 1998.

[51]

S. Deering, D. Estrin, D. Farinacci, V. Jacobson, A. Helmy, D. Meyer, and L. Wei. Protocol Independent Multicast Version 2

Bibliography Dense Mode Specification. draft-ietf-pim-v2-dm-03.txt, Cisco and USC and LBL, June 1999. [52]

S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L. Wei. The PIM architecture for wide-area multicast routing. IEEE/ACM Transactions on Networking, 4(2):153–162, April 1996.

[53]

S. Deering, and B. Hinden. Internet Protocol, Version 6 (ipv6) Specification. RFC 2460, Internet Engineering Task Force, December 1998.

[54]

S. Deering, and A. Thyagarajan. Internet Group Management Protocol, Version 3. Internet draft, Internet Engineering Task Force, February 1999.

[55]

L. Delgrossi. Design of Reservation Protocols for Multimedia Communication. Kluwer Academic Publishers, 1996.

[56]

L. Delgrossi, and L. Berger. Internet Stream Protocol Version 2 (ST2) Protocol Specification—Version ST2+. RFC 1819, Internet Engineering Task Force, August 1995.

[57]

C. Diot, W. Dabbous, and J. Crowcraft. Multipoint communications: A survey of protocols, functions and mechanisms. IEEE Journal on Selected Areas in Communications (JSAC), 15(3):277–290, April 1997.

[58]

H. Dittler. IPv6 the New Internet Protocol (in German). dpunkt, 1998.

[59]

M. Doar, and I. Leslie. How bad is naive Multicast-Routing? In Proceedings of IEEE Infocom, 1:82–89, September 1993.

[60]

H. Eriksson. MBONE: The Multicast Backbone. Communications of the ACM, 37(8):54–60, August 1994.

[61]

D. Estrin, R. Govindan, M. Handley, S. Kumar, P. Radoslavov, and D. Thaler. The Multicast Address-Set Claim (MASC) Protocol. Internet draft, Internet Engineering Task Force, August 1999.

[62]

F. Farance, and J. Tonkel. LTSA Specification, Learning Technology Systems Architecture. Technical report, www.edutool.com/ltsa.

[63]

D. Farinacci, Y. Rekhter, P. Lothberg, H. Kilmer, and J. Hall. Multicast Source Discovery Protocol (MSDP). Internet draft, Internet Engineering Task Force, June 1998.

[64]

B. Fenner. Internet Group Management Protocol, Version 2. RFC 2236, Internet Engineering Task Force, November 1997.

319

320

Bibliography [65]

W. Fenner. IGMP-based Multicast Forwarding (“IGMP Proxying”). Internet draft, Internet Engineering Task Force, June 1999.

[66]

A. Fieger, and M. Zitterbart. Transport protocols over wireless links. In IEEE Symposium on Computer and Communication, July 1997.

[67]

S. Floyd, and V. Jacobson. Link-sharing and resource management models for packet networks. IEEE/ACM Transactions on Networking, 3(4), 1995.

[68]

S. Floyd, V. Jacobson, C. Liu, S. McCanne, and L. Zhang. A reliable multicast framework for light-weight sessions and application level framing. IEEE/ACM Transactions on Networking, 5(6), 1997.

[69]

J. Graham-Cumming. Hits and misses: A year watching the Web. In Proceedings of 6th International World Wide Web Conference, April 1997.

[70]

R. Guerin, C. Partridge, and S. Shenker. Specification of Guaranteed Quality of Service. RFC 2212, Internet Engineering Task Force, October 1997.

[71]

W. Haaß. Handbook for Computer Networks (in German). Springer-Verlag, 1997.

[72]

R. Haendel, and M. Huber. Integrated Broadband Networks. Addison-Wesley, 1991.

[73]

J. Halpern, and M. Laubach. Classical IP and ARP over ATM. RFC 2225, Internet Engineering Task Force, April 1998.

[74]

M. Handley. SAP: Session Announcement Protocol. Internet draft, Internet Engineering Task Force, November 1996.

[75]

M. Handley. Multicast Address Allocation Protocol (AAP). Internet draft, Internet Engineering Task Force, June 1999.

[76]

M. Handley, and J. Crowcroft. Hierarchical Protocol Independent Multicast (HPIM). north.east.isi.edu/ mjh/hpim.ps, University College, London and University of Sussex, November 1995.

[77]

M. Handley, and J. Crowcroft. Network Text Editor (NTE): A scalable shared text editor for the MBone. In Proceedings of ACM SIGCOMM ’97, 1997.

[78]

M. Handley, and V. Jacobson. SDP: Session Description Protocol. RFC 2327, Internet Engineering Task Force, April 1998.

Bibliography [79]

M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg. SIP: Session Initiation Protocol. RFC 2543, Internet Engineering Task Force, March 1999.

[80]

M. Handley, and D. Thaler. Multicast-Scope Zone Announcement Protocol (MZAP). Internet draft, Internet Engineering Task Force, October 1998.

[81]

M. Handley, D. Thaler, and D. Estrin. The Internet Multicast Address Allocation Architecture. Internet draft, Internet Engineering Task Force, April 1999.

[82]

C. Hänle, and M. Hofmann. A Comparison of reliable multicast protocols using the network simulator ns-2. In Proceedings of IEEE Conference on Local Computer Networks (LCN), October 1998.

[83]

S. Hanna, B. Patel, and M. Shah. Multicast Address Dynamic Client Allocation Protocol (MADCAP). Internet draft, Internet Engineering Task Force, May 1999.

[84]

K. Harrenstien, M. Stahl, and E. Feinler. NICNAME/WHOIS. RFC 954, SRI, October 1985.

[85]

C. Hedrick. Routing Information Protocol. RFC 1058, Internet Engineering Task Force, June 1988.

[86]

D. Hoffman, G. Fernando, V. Goyal, and R. Civanlar. RTP Payload Format for MPEG1/MPEG2 Video. Internet draft, Internet Engineering Task Force, November 1997. (Work in progress.)

[87]

M. Hofmann. A generic concept for large-scale multicast. In B. Plattner, editor, International Zurich Seminar on Digital Communication, Lecture Notes in Computer Science, No. 1044, Zurich, Switzerland, Springer-Verlag, February 1996.

[88]

M. Hofmann. Scalable Multicast Communication (in German). PhD thesis, inox publisher, 1998.

[89]

H. Holbrook, S. Singhal, and D. Cheriton. Log-based receiver-reliable multicast for distributed interactive simulation. In Proceedings of SIGCOMM ’95, August 1995.

[90]

C. Huitema. Routing in the Internet. Prentice Hall, 1995.

[91]

Internet2. www.internet2.edu/, September 1998.

[92]

V. Jacobson. Congestion Avoidance and Control. In Proceedings of SIG-COMM ’88, August 1988.

321

322

Bibliography [93]

R. Jain. Congestion control in computer networks: Trends and issues. IEEE Network, pages 24–30, May 1990.

[94]

C. Kirsch. Program update through the network (in German). iX, 8:96–103, August 1997.

[95]

S. Kumar, P. Radoslavov, D. Thaler, C. Alaettinoglu, D. Estrin, and M. Handley. The MASC/BGMP architecture for interdomain multicast routing. In Proceedings of ACM SIGCOMM 98, September 1998.

[96]

V. Kumar. MBone: Interactive Multimedia on the Internet. New Riders, 1996.

[97]

J. Lin, and S. Paul. Rmtp: A reliable multicast transport protocol. In IEEE INFOCOM ’96, 1996.

[98]

C. Liu, D. Estrin, S. Shenker, and L. Zhang. Local Error Recovery in SRM: Comparison of Two Approaches. Technical report 97–648, University of Southern California, Los Angeles, 1997. Also available at ftp://usc.edu/pub/csinfo/tech-reports/papers/97–648.ps.

[99]

C. Liu, D. Estrin, S. Shenker, and L. Zhang. Timer Adjustment in SRM. Technical report 97–656, University of Southern California, Los Angeles, 1997. Also available at ftp:// usc.edu/pub/csinfo/tech-reports/papers/97–656.ps.

[100]

G. Malkin. RIP Version 2 Carrying Additional Information. RFC 1723, Internet Engineering Task Force, November 1994.

[101]

D. Meyer. Administratively Scoped IP Multicast. RFC 2365, Internet Engineering Task Force, July 1998.

[102]

T. Milde. A Comparison of Video Compression Techniques (in German). dpunkt, 1995.

[103]

D. Mills. Network Time Protocol. RFC 1119, Network Information Center, September 1989.

[104]

D. Minoli, and A. Alles. LAN, ATM and LAN Emulation Technologies. Artech-House, 1996.

[105]

S. Mirchandani, and R. Khanna. FDDI Technologies and Applications. Wiley, 1993.

[106]

J. Moy. MOSPF: Analysis and Experience. RFC 1585, Internet Engineering Task Force, March 1994.

[107]

J. Moy. Multicast routing extensions for OSPF. Communications of the ACM, 37(8):61–66, August 1994.

[108]

J. Moy. OSPF Version 2. RFC 2328, April 1998.

Bibliography [109]

J. Moy. Multicast Extensions to OSPF. Internet draft, Internet Engineering Task Force, August 1998.

[110]

J. Myers. IMAP4 ACL Extension. RFC 2086, Internet Engineering Task Force, January 1997.

[111]

K. Nichols, S. Blake, F. Baker, and D. Black. Definition of the Differentiated Services Field (ds Field) in the ipv4 and ipv6 Headers. RFC 2474, Internet Engineering Task Force, December 1998.

[112]

K. Nichols, V. Jacobson, and L. Zhang. A Two-Bit Differentiated Services Architecture for the Internet. Internet draft, November 1997.

[113]

A. Parekh, and R. Gallagher. A generalized processor sharing approach to flow control: the single node case. IEEE/ACM Transactions on Networking, 1(3):344–357, June 1993.

[114]

A. Parekh, and R. Gallagher. A generalized processor sharing approach to flow control: the multiple node case. IEEE/ACM Transactions on Networking, 2(2):137–150, April 1994.

[115]

G. Patridge, and S. Pink. An implementation of the revised stream protocol (ST2). Journal of Internetworking: Research and Experience, 4(1), March 1992.

[116]

S. Paul. Multicasting on the Internet and Its Applications. Kluwer Academic Publishers, 1998.

[117]

C. Perkins. IP Encapsulation within IP. RFC 2003, Internet Engineering Task Force, October 1996.

[118]

C. Perkins. IP Mobility Support. RFC 2002, Internet Engineering Task Force, October 1996.

[119]

C. Perkins. Mobile IP, Design Principles and Practices. Addison-Wesley, 1998.

[120]

R. Perlman. Interconnections—Bridges and Routers. Addison-Wesley, 1992.

[121]

L. Peterson, and B. Davie. Computer Networks—A Systems Approach. Morgan Kaufman, 1996.

[122]

D. Plummer. Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48 Bit Ethernet Address for Transmission on Ethernet Hardware. RFC 826, Internet Engineering Task Force, November 1982.

[123]

Pointcast. The PointCast Network. www.pointcast.com/, 1997.

323

324

Bibliography [124]

J. Postel. Internet Control Message Protocol. RFC 792, ISI, September 1981.

[125]

J. Postel. Transmission Control Protocol. RFC 793, ISI, September 1981.

[126]

J. Postel. User Datagram Protocol. RFC 768, ISI, August 1980.

[127]

J. Postel. Internet Protocol. RFC 791, ISI, September 1981.

[128]

T. Pusateri. Distance Vector Multicast Routing Protocol. Internet draft, draft-ietf-idmr-dvmrp-v3-09.txt, September 1999.

[129]

K. Rao, and J. Hwang. Techniques and Standards for Image, Video and Audio Coding. Prentice Hall, 1996.

[130]

Y. Rekhter, and T. Li. A Border Gateway Protocol 4 (BGP-4). RFC 1771, Internet Engineering Task Force, March 1995.

[131]

J. Reynolds, and J. Postel. Assigned Numbers. RFC 1700, Internet Engineering Task Force, October 1994.

[132]

K. Robertson, K. Miller, M. White, and A. Tweedly. StarBurst Multicast File Transfer Protocol (MFTP) Specification. Internet draft, Internet Engineering Task Force, April 1998. Also available at www.ietf.org/internet-drafts/draft-millermftp-spec-03.txt and www.starburstcom.com/draft.txt.

[133]

A. Schill. Computer Supported Teamwork in Distributed Systems (in German), Prentice Hall, 1995.

[134]

C. Schmidt, and M. Zitterbart. Reservation of Network Resources (in German). PIK, 1995.

[135]

H. Schulzrinne. RTP Profile for Audio and Video Conferences with Minimal Control. RFC 1890, Internet Engineering Task Force, January 1996.

[136]

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

[137]

J. Shapiro. Collaborative Computing. AP Professional, 1996.

[138]

P. Sharma, D. Estrin, and S. Floyd. Scalable Session Messages in SRM. Technical report 98–670, University of Southern California, Los Angeles, 1998. Also available at ftp:// ftp.usc.edu/pub/csinfo/tech-reports/papers/98–670.ps.Z.

[139]

S. Shenker, and J. Wroclawski. General Characterization Parameters for Integrated Service Network Elements. RFC 2215, Internet Engineering Task Force, October 1997.

Bibliography [140]

S. Shenker, and J. Wroclawski. Network Element Service Specification Template. RFC 2216, Internet Engineering Task Force, October 1997.

[141]

T. Speakman, N. Bhaskar, R. Edmonstone, D. Farinacci, S. Lin, A. Tweedly, L. Vicisano, and J. Gemmell. PGM Reliable Transport Protocol Specification. Internet draft, Internet Engineering Task Force, June 1999. Also available at www.ietf. org/internet-drafts/draft-speakman-pgm-spec-03.txt.

[142]

W. Stallings. Handbook of Computer Communication Standards: Local Area Network Standards. Howard W. Sams and Company, 1990.

[143]

W. Stallings. ISDN and Broadband ISDN. Macmillan Publishing, 1992.

[144]

StarBurst. General Motors revs up its distribution system. Press release of StarBurst Communications. www.starburstcom/ gm.htm, 1997.

[145]

R. Steinmetz, and K. Nahrstedt. Multimedia: Computing, Communications and Applications. Prentice Hall, 1995.

[146]

W. Stevens. TCP/IP Illustrated. Addison-Wesley, 1994.

[147]

W. Strayer, B. Dempsey, and A. Weaver. XTP: The Xpress Transfer Protocol. Addison-Wesley, 1992.

[148]

D. Tennenhouse, J. Smith, W. Sincoskie, D. Wetherall, and G. Minden. A survey of active network research. IEEE Communications Magazine, 35(1):80–86, January 1997.

[149]

D. Thaler, U. Michigan, D. Estrin, D. Meyer, and U. Oregon. Protocol Independent Multicast Version 2 Dense Mode Specification. af-sig-0061.000, ATM Forum, July 1996.

[150]

A. Thyagarajan, and S. Deering. Hierarchical distance vector routing for the MBone. In Proceedings of ACM SIGCOMM ’95, October 1995.

[151]

C. Topolcic. Experimental Internet Stream Protocol, Version 2 (ST-II). RFC 1190, Internet Engineering Task Force, October 1990.

[152]

D. Towsley, J. Kurose, and S. Pingali. A comparison of sender-initiated and receiver-initiated reliable multicast protocols. IEEE Journal on Selected Areas in Communications (JSAC), 15(3):398–406, April 1997.

325

326

Bibliography [153]

T. Turletti. The INRIA Videoconferencing System (IVS). ConneXions—The Interoperability Report Journal, 8(10):20– 24, October 1994.

[154]

T. Turletti and C. Huitema. RTP Payload Format for H.261 Video Streams. Internet draft, Internet Engineering Task Force, July 1995.

[155]

J. Viniotis, and R. Onvural. Asynchronous Transfer Mode Networks. Plenum, 1993.

[156]

D. Waitzman, C. Partridge, and S. Deering. Distance Vector Multicast Routing Protocol. RFC 1075, BBN STC, Stanford University, Palo Alto, California, November 1988.

[157]

Z. Wang. USD: Scalable bandwidth allocation for the Internet. In High Performance Networking, July 1998.

[158]

L. Wei (Ed.). Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. Internet draft, Internet Engineering Task Force, October 1999.

[159]

B. Whetten, S. Kaplan, and T. Montgomery. A high performance totally ordered multicast protocol. In Proceedings of INFOCOMM ’95, April 1995.

[160]

P. White. RSVP and Integrated Services in the Internet: A tutorial. IEEE Communications Magazine, May 1997.

[161]

R. Wittmann, and M. Zitterbart. AMnet: active multicasting network. In Proceedings of ICC ’98, June 1998.

[162]

R. Wittmann, and M. Zitterbart. AMnet: active multicasting network. In Proceedings of ICC ’98, June 1998.

[163]

J. Wroclawski. Specification of the Controlled-Load Network Element Service. RFC (Proposed Standard) 2211, Internet Engineering Task Force, October 1997.

[164]

J. Wroclawski. The Use of RSVP with IETF Integrated Services. RFC 2210, MIT LCS, September 1997.

[165]

D. Wybranietz. Multicast Communication in Distributed Systems (in German). Springer-Verlag, 1987.

[166]

XTP Forum. Xpress Transport Protocol Specification, Revision 4.0. ftp://dancer.ca.sandia.gov/pub/xtp4.0, March 1995.

[167]

XTP Forum. Xpress Transport Protocol Specification, Revision 4.0b. www.mentat.com/xtp/XTP40b.ps, July 1998.

Bibliography [168]

W. Yeong, T. Howes, and S. Kille. Lightweight Directory Access Protocol. RFC 1777, Performance Systems International, ISODE Consortium, March 1995.

[169]

L. Zhang, S. Deering, D. Estrin, S. Shenker, and D. Zappala. RSVP: a new resource ReSerVation protocol. IEEE Network Magazine, (3):18, September 1993.

[170]

M. Zitterbart. High Performance Communication I: Technology and Networks (in German). Oldenbourg, 1995.

[171]

M. Zitterbart, and C. Schmidt. Internetworking—Bridges, Routers and Co. (in German). Thomson Publishing, 1995.

327

This Page Intentionally Left Blank

Index

A acknowledgment implosion, 34 acknowledgments graft data units, 93 known group members and, 36 LBRM, 236, 237 MTP error handling, 220–221 negative (NAKs), 37, 221, 233, 234, 239–240 positive, 38 processing, 36 remote location, 52 RMP, 226, 227, 228, 229, 230 RMTP, 245 unknown group members and, 36 active networks, 136, 311–313 approaches, 311 areas benefiting from, 312 dedicated error control and, 312 defined, 311 explicit signaling, 312 for group communication support, 311–313 implicit signaling, 312 usage spectrum, 312 adaptive routing algorithms, 55–56 centralized, 55–56 defined, 55 distributed, 56 See also routing algorithms address allocation protocol (AAP), 73, 74 MAAS and, 75 uses, 75 address mapping, 49 illustrated, 50 one-to-one, 50

Address Resolution Protocol (ARP), 15, 179 addresses allocation, 41–42 broadcast, 45–46 group, 41 Internet, 48 MAC layer, 46 multicast, 42, 45 NSAP, 184 as scarce resource, 67 unicast, 45, 46 addressing, 40–42 group, 40–42 with lists of receivers, 41 administrative regions, 69–72 global, 71 introduction of, 69 list of, 70 local, 70 organizational, 70–71 See also scoping admission control controlled-load services, 126 guaranteed services, 130 RSVP, 139 aggregated reservations, 157, 158 announcements, 42–44 elements of, 42 example, 42 illustrated, 43 anonymous groups, 28 anycast communication, 14–15 applications, 14 defined, 14

330

Index

anycast communication (continued) illustrated, 15 See also communication application layer, 52 Application Level Framing (ALF), 238 applications anycast communication, 14 broadcast communication, 15 distributed databases, 20–22 group communication, 20–26 group communication emulation, 4 interactive multimedia, 23–26 levels of interaction, 4 MBone, 271–302 multicast communication, 10 push technologies, 22 unicast communication, 9 assured services, 162–163 defined, 162 premium services combined with, 163 uses, 162 See also Differentiated Services (DiffServ) ATM, 167–195 available bit rate (ABR), 173 concept, 168 connection-oriented basis, 167 deterministic bit rate (DBR), 172 IP multicast over, 178–187 LANE, 176–178 multicast, 48, 173–195 multicast emulation and, 47 multicast tree, 175 multicast vs. multipeer in, 174–176 protocol layers, 170 service categories, 171–173 service classes, 171 shared media and, 46 signaling protocol, 158 statistical bit rate (SBR), 172–173 switches, 168, 174 traffic contract, 172 UNI signaling, 187–195 unspecified bit rate (UBR), 173 VCs, 169 virtual connections, 169 VPs, 169 ATM adaptation layer (AAL), 169–171 AAL3/4, 171, 174

AAL5, 171, 174, 175 convergence functions, 170 function of, 170 service classes, 170–171 types and service classes, 171 ATM cells, 174 address information, 169 asynchronous multiplexing, 168 defined, 167 header, 167 identifier conversion, 168 illustrated, 168 ATM cloud, 178, 179 connections, 178 illustrated, 179 logical IP subnets over, 180 ATM Forum, 172, 173, 176 atomicity, 33 defined, 33 MTP, 223 autonomous systems multicast between, 104–105 system composition with MOSPF, 99 available bit rate (ABR), 173 awareness, group, 28

B best effort service, 125 BGP (Border Gateway Protocol), 75 bidirectional multicast trees, 117 bootstrap data units, 109, 112 bootstrap routers, 106, 112 candidates for, 112 task, 112 Border Gateway Multicast Protocol (BGMP), 120 concepts, 120 defined, 120 group members, 120–121 for interconnection of multicast domains, 121 join data units, 121 root domain, 121 boundary routers, 95 forwarding of routing information, 102 protocol implementation, 96

Index broadcast addresses, 45–46 broadcast communication, 15 broadcast-and-unknown server, 177–178

C candidate rendezvous points, 112, 119 capsules, 312 centralized routing algorithms, 55–56 Class-Based Queuing (CBQ), 139 classical IP over ATM, 178 closed groups, 26–27 defined, 26–27 illustrated, 26 MFTP, 258 See also groups; open groups ClusterControlVC, 183 communication anycast, 14–15 broadcast, 15 computer-based, 4, 23 concast, 10–11 group, 1, 2, 5, 7–52 interpersonal, 23 multicast, 9–10, 16–18 multipeer, 11–13 overview, 14 point-to-point, 8, 27, 30, 38, 51 types of, 7–15 unicast, 8–9, 16–18 computer-aided software engineering (CASE) editors, 33 computer-supported cooperative work (CSCW), 2 computer-supported information dissemination. See push technologies concast communication, 10–11 defined, 10 example, 10–11 illustrated, 11 See also communication Conference Manager (CONFMAN), 298–300 address management, 298 application management, 300 availability, 300 conference management, 298–299

defined, 298 illustrated, 298 modules, 298 telephone management, 299 See also MBone applications conferencing systems, 23–25 components of, 25 features, 24 group membership, 24–25 security, 25 whiteboard, 23 conformance testing, 129 conformation data unit (CONF), 134 congestion control, 40 preventative mechanisms, 40 reactive mechanisms, 40 RMTP, 250 connection context, 197–198 connection control RMTP, 244–245 XTP, 205–210 controlled-load services, 125–129 admission control, 126 defined, 125 low-traffic network service, 126 token-bucket model, 126–127 traffic specification, 126 Tspecs comparison, 128–129 See also Integrated Services (IntServ) core-based trees (CBT), 117–119 bidirectional multicast tree, 117 bootstrap mechanism, 119 IGMP and, 118 manual configuration, 119 multicast routing entry, 118–119 new members, 118 rendezvous points, 119 scalability objective, 117–118 version 1 vs. version 2, 118 version 2, 118 version 3, 118, 119 count-to-infinity problem, 59–60

D data copying, 51 data link layer, 45–47

331

332

Index

data transfer LBRM, 233–238 MFTP, 260–262 MTP, 217–219 PGM, 251 SRM, 239–242 XTP, 210–213 data units AAL3/4, 171 ABORT, 259, 262 accept, 152 ACK, 228, 229, 245, 246 bootstrap, 109, 112 CNTL, 208, 209 COMPLETION, 262 conformation (CONF), 134 connect, 151–152 CONNECT, 188, 190 control, 117 DATA, 218 defined, 7 DIAG, 206 DONE, 262 EMPTY, 218 explicit join, 109 FIRST, 206 forwarding of, 86 graft, 93 Hello, 97 IGMP, 63–64 JCNTL, 206, 207 join, 115, 116, 121 LBRM, 234 LIST-CHANGE-REQUEST, 230, 231 MADCAP, 74 MARS, 183–184 MTP, 217, 218, 223 NAK, 220, 224, 230, 261 NCF, 253–254 neighbor probe, 91 NEW-LIST, 232 ODATA, 251 OSPF, 97 path error (PERR), 147 path (PATH), 134, 145 path tear (PTEAR), 148 pruning, 85 QUIT, 259 RDATA, 253, 254

RECOVERY-START, 231, 232 reflection of, 186 register, 115, 116 reservation error (RERR), 147–148 reservation (RESV), 134, 145 reservation tear (RTEAR), 148 RESET, 245 RMP, 228–230 RMTP, 246, 247 RSVP, 145–149 RTP, 273–274 SAP, 291 SCMP, 150 SETUP, 188, 190, 192 source active, 120 ST2, 154–155 XTP, 205 dependent routers, 110, 111 designated forwarder, 93–95 designated local repairer (DLR), 256 designated receivers, 243, 245–246 multicast tree with, 247 not receiving data unit, 246 selection of, 248–249 See also RMTP deterministic bit rate (DBR), 172 Differentiated Services (DiffServ), 156–164 aggregated reservations, 157, 158 as alternative, 156–157 assured services, 162 classification of data units, 160–161 concept, 157–161 domains, 159–160, 166 edge routers, 160 field with codepoint, 161 implicit signaling, 157 IntServ integration, 165–166 IntServ vs., 164–165 long-term reservations, 157–158 multicast and, 164, 311 per-hop behavior, 161 premium services, 161–162 premium/assured services combination, 163 relative quality of service, 158, 159 service concept proposals, 161–164 user-shared differentiation, 163–164 See also quality of service

Index Dijkstra algorithm, 60–61, 86 distance learning, 2 Distance Vector Multicast Routing Protocol. See DVMRP distance-vector algorithms, 56–60 advantages, 58 convergence, 58, 59 count-to-infinity problem, 59–60 defined, 56 distance vectors, 57 routing metric, 56 routing selection illustration, 57 routing tables, 57–58 shortest path selection, 56–57 within domains, 58–59 distributed databases, 20–22 atomicity, 33 group dynamics, 22 illustrated example, 21 quality of service, 22 reliability, 22, 33 Rock-Tours example, 20–21 See also applications distributed routing algorithms, 56 distance-vector, 56–60 link state, 60–62 See also adaptive routing algorithms distributed teamwork, 2 distribution trees, 77–78 illustrated example, 77 need for, 77 setup, 86 domains, 266, 267 DVMRP, 60, 67, 91–97 defined, 91 designated forwarder, 93–95 graft data units, 93 hierarchical (HDVMRP), 95–97 Poison-reverse, 92–93 routers, 91 routers, tunneling between, 92 routing tables, 91 dynamic groups decision, 44 defined, 27 group management for, 313 static routing algorithms and, 54–55 See also groups; static groups dynamic querying, 65

E edge routers, 160 error control dedicated, 312 LBRM, 233–238 MFTP, 261 MTP, 219–221 PGM, 252–254 SRM, 239–242 ST2, 154 XTP, 212–213 error detection flow control and, 36 reliable group services, 33–34 error fingerprints, 242 error recovery, 33–34 flow control and, 38 hop-scope, 240–241 point-to-point communication, 38 RMP, 231–232 RMTP, 245–249 Ethernet example, 47 multicast address, 49, 50 with shared medium, 46 expanded ring search, 236

F feedback implosion, 40 filters fixed, 141–142 shared, 142–143 use of, 141 wildcard, 143–144 first-hop router, 160, 163 fixed filters, 141–142 defined, 141 example, 142 requests, 141, 142 See also filters flooding defined, 78 improved, 78 loops and, 78 RPF vs., 81 flow control, 36–39

333

334

Index

flow control (continued) error detection/recovery and, 36 PGM, 254–255 rate-based, 39 RMTP, 249–250 sliding window, 210 window-based, 38–39 XTP, 210–211 See also congestion control; error control FlowSpec, 140–141 fluid model, 131 forward error correction (FEC), 31 forwarding of data units, 86 NAK, 252 networkwide, 86 reverse path (RPF), 81–82 forwarding cache example of, 102 storage in, 101 Free Phone (fphone), 282–284 address book, 283 addresses, 282 audio codec configuration, 283 audio conference using, 282 automatic mode, 284 availability, 284 defined, 282 goal, 282 semiautomatic mode, 284 See also MBone applications

G global ordering, 33, 35 graft data units, 93 group addressing, 40–42 allocation, 41–42 with group addresses, 41 with lists of receivers, 41 group communication acknowledgments, 36 active network support of, 311–313 advantages, 2 announcements, 42–44 application emulation of, 4 applications, 20–26 attributes, 5

basics, 1, 7–52 as communication protocol objective, 13 congestion control, 40 dedicated support of, 44 defined, 1, 7 flow control, 36–39 group addressing and administration, 40–44 multicast communication and, 10 open issues, 310 order maintenance, 13 ordered delivery, 35–36 outlook, 309–313 rapid service creation, 309 reliability, 29–36 scalability, 5 sender reaction, 37 servers, 19–20 special aspects of, 29–44 unicast communication and, 8–9 worldwide, 3 group dynamics, 62–67, 86 group join PIM-SM, 107–108 UNI signaling, 189–190, 192 group management, 42 IGMP, 65 for large dynamic groups, 313 local, 312 MFTP, 257–260 RMP, 230–233 group members BGMP and, 120–121 RMP, 226 SRM, 239 unknown, 65 XTP, 214 group membership awareness of, 19 conferencing systems, 24–25 dynamic changes in, 77 fluctuations in, 25 local, 100–101 LSA, 103 reliable group services and, 35 summaries, 103 group routes, 76 group services as communication system goal, 4 dedicated protocols for, 35

Index defined, 4 k-reliable, 32 reliability, 19, 29–36 reliable, 29–30, 33–35 semireliable, 31–33 statistically, 31–32 sufficiently, 32–33 unreliable, 30–31 groups anonymous, 28 awareness of, 28 characteristics of, 26–29 closed, 26–27, 258 dynamic, 27, 44 heterogeneity of, 19, 28–29 heterogeneous, 28 homogeneous, 28 known, 28, 37 lifetime of, 27 open, 26, 180, 258–259 openness of, 26–27 permanent, 27, 49 physical distribution of, 52 private, 257–258 public, 257–258 with rendezvous points, 88–89 routing support for, 50 scope of, 67–72 security, 27 size of, 19 static, 27, 44 topology, 19 transient, 27 groupware, 2 guaranteed services, 129–133 admission control, 130 data rate, 129 defined, 129 delay jitter and, 130 error terms, 131 fluid model, 131 global availability, 130 maximum transmission delay, 129 reshaping at merging point, 133 Rspec, 130 signaling protocols, 132–133 traffic reshaping, 131 Tspecs/Rspec merge, 145 See also Integrated Services (IntServ)

335

H hard reservations, 194 heartbeat intervals, 233–234 Hello data units, 97 heterogeneous groups, 28 heterogeneous multicast, 135–137 hierarchical DVMRP (HDVMRP), 95–97 advantages, 96 defined, 95 illustrated, 95 routing between domains, 96 routing in destination domain, 96–97 routing in source domain, 96 routing steps, 96 use of, 95–96 use on Internet and, 97 See also DVMRP hierarchical PIM (HPIM), 114–117 defined, 114 development, 117 hierarchy of rendezvous points, 115 joining groups in, 114 loop avoidance, 116 new members, 114 nonoptimal trees, 115 rendezvous points without members, 116–117 See also PIM homogeneous groups, 28 hybrid stream setup, 153

I increment window, 254–255 Inria Videoconferencing System (IVS), 302 Integrated Services (IntServ), 124–156 best effort service, 125 controlled-load services, 125–129 data unit size parameter, 127 defined, 124 DiffServ integration, 165–166 DiffServ vs., 164–165 guaranteed services, 129–133 parameters, 127 philosophy, 124 receiver-oriented resource requests, 124 sender-oriented resource requests, 124

336

Index

Integrated Services (IntServ) (continued) service classes, 125 signaling protocols, 124 See also quality of service interactive multimedia applications, 23–26 conferencing systems, 23–25 distributed Flintstone project team, 24 interarea multicast forwarders, 102–103 intermediate routers, 160 intermediate systems, 7 Internet2, 3 Internet addresses, 48 best-effort service, 123 model illustration, 44 multicast routing on, 90–121 See also MBone Internet Group Management Protocol (IGMP), 62 CBT use of, 118 data units, 63–64 dynamic querying in, 65 general membership queries, 62 group-specific membership queries, 62 leave group, 63 membership reports, 62–63 multicast routers and, 64 operations, 62 version 1 (IGMPv1), 66 version 2 (IGMPv2), 62, 66 version 3 (IGMPv3), 66 IP address formats, 48 connectionless forwarding service, 167 mobile, 310 multicast routers, 181–182 version 6, 148 IP multicast over ATM, 178–187 implementation, 179, 180 IP multicast routers, 181–182 MARS model, 182–187 open groups, 180 protocol structure, 181 solutions, 180 See also ATM IP-IP encapsulation, 270–271 defined, 270 link failure and, 271 multicast data unit, 271

tunneling with, 270 See also MBone ISDN hard guarantees, 134 quality of service, 123 shared media and, 46 islands, 266 ISO/OSI reference model application layer, 52 data link layer, 45–47 illustrated, 44 network layer, 47–51 transport layer, 51–52

K known groups, 28 delayed reactions and, 37 XTP connection setup and, 206 See also groups k-reliable group services, 32 defined, 32 realization, 32 k-resilient RMP service, 225

L label swapping, 168 LAN Emulation (LANE), 176–178 broadcast-and-unknown server, 177–178 clients, 177 components, 177 configuration server, 177, 178 framework, 178 restrictions, 178 server, 177 server functions, 176 use of, 178 See also ATM LBRM, 233–238 acknowledgments, 236, 237 architecture, 235 control data units, 234 data transfer, 233–238 defined, 233 for distributed simulations, 234

Index error control, 233–238 heartbeat intervals, 233–234 logging server, 234–235 negative acknowledgments, 233, 234, 238 as receiver-oriented protocol, 233, 238 retransmissions, 234, 235, 236, 237 secondary logging servers, 236 statistical acknowledgments, 236–237 summary, 238 See also transport protocols leaf routers, 84 leave group, 63 link state algorithms, 56, 60–62 convergence, 61 defined, 60 Dijkstra algorithm, 60–61 routing metrics, 61 “shortest path first,” 62 time stamps, 61 See also distributed routing algorithms Local Group Concept (LGC), 251 local group management, 312 local resource manager (LRM), 151 Log-Based Receiver-Reliable Multicast) protocol. See LBRM logging servers, 234–235 defined, 234 location for, 236 overloaded, 235 retransmissions and, 235 secondary, 236 See also LBRM logical IP subnets (LIS), 179 loose-source-record routing (LSRR), 267–270 data unit path, 268 defined, 268 disadvantages, 269–270 IP multicast data unit with, 269 security problem, 269–270 tunneling with, 268 See also MBone

M majority-resilient RMP service, 225 MARS model, 182–187 address forming, 183 address resolution, 182

337

clients, 183 ClusterControlVC, 183 control connections, 183 defined, 182 JOIN data unit, 183, 184 LEAVE data unit, 183 MULTI data unit, 183 multicast implementation, 185 multicast server version, 186 protocol independence, 184 servers, 183 VC mesh, 185 See also IP multicast over ATM master defined, 214 response, 216 status administration, 217 token requests and, 217 who functions as, 215 See also MTP; webs MBone, 265–307 architecture, 266–271 connection, 303 connection information, 303 defined, 265 domains, 266, 267 elements, 266 growth, 266 inauguration, 265 information on, 272 IP-IP encapsulation, 270–271 islands, 266 LSRR, 267–270 mrouters, 267 as overlay network, 271 tunnels, 266, 267 See also Internet MBone applications, 271–302 Conference Manager (CONFMAN), 298–300 Free Phone (fphone), 282–284 information on, 272 Inria Videoconferencing System (IVS), 302 Multimedia Conference Control (MMCC), 300–302 Network Text Editor (NTE), 286, 287 Robust Audio Tool (RAT), 281 RTP, 272–277 Session Announcement Protocol (SAP), 289–291

338

Index

MBone applications (continued) Session Description Protocol (SDP), 291–293 Session Directory (SDR), 286–289 Session Initiation Protocol (SIP), 293–298 VideoConference (VIC), 277–279 Visual Audio Tool (VAT), 279–280 whiteboard (WB), 284–286 MBone routers administrators, 68 configuration of, 68 source-based routing and, 81 MBone tools, 123, 303–307 Mrinfo, 304–305 Mrouted, 303–304 Mtrace, 305–307 membership reports, 62–63 message identificators (MID), 174–175 message identifier, 171 MFTP, 257–263 ABORT data unit, 259, 262 aggregation delay, 262–263 announcements, 257–258 blocks, 260 closed groups, 258 COMPLETION data unit, 262 data transfer, 260–262 defined, 257 DONE data unit, 262 enhancements, 262–263 error control, 261 group management, 257–260 multicast control protocol, 259–260 NAK implosion, 261 open groups, 258–259 open limited groups, 258 open unlimited groups, 258–259 passes, 260 private group, 257–258 public group, 257–258 QUIT data unit, 259 rate control, 260 response suppression, 162 retransmissions, 261 router support, 262 summary, 263 termination, 261–262 See also transport protocols mobile-IP, 310

monolithic algorithms, 87 Mrinfo, 304–305 defined, 304 information, 304–305 invocation, 304 printout, 305 See also MBone tools Mrouted, 303–304 configuration information, 303 metric, 304 tasks, 303 tunnel configuration, 303–304 See also MBone tools mrouters, 267 MTP, 214–224 ACCEPTED status, 222 allocation of transmission rights, 216–217 atomicity, 223 consistency, 221–223 consumer, 215 DATA data units, 218 data transfer, 217–219 data units, 217, 218, 223 deficiencies, 224 defined, 214–215 EMPTY data units, 218 end-of-message flag, 219 end-of-window flag, 218 error control, 219–221 error recovery illustration, 221 heartbeat parameter, 218 masters, 214, 215, 217 message acceptance record, 223 message sequence number, 221–222 message status, 222 messages, 216–217 NAK data units, 220, 224 negative selective acknowledgments, 220, 221 ordering, 214, 221–223 PENDING status, 222 producer, 214–215, 220 quality of service parameters, 217–218 rate control, 218 REJECTED status, 222 retention parameter, 218 retransmission, 220 scalability, 224

Index semireliable multipeer service, 223 status vector, 223, 224 summary, 223–224 web structure, 215–216 webs, 214 window parameters, 218 See also transport protocols Mtrace, 305–307 defined, 305 phases, 307 printout, 306 See also MBone tools multicast address allocation, 72–76 architecture, 72, 73 interdomain, 75 problem, 72 static, 73 transactions, 75 multicast address allocation servers (MAASs), 73, 75 address sets and, 75 peer, 73 Multicast Address Dynamic Client Allocation Protocol (MADCAP), 73 data units, 74 location of, 74 servers, 74 multicast addresses, 42, 45 collisions, 72 dynamic handling of, 67 Ethernet, 49, 50 IP, 49, 50 from network layer, 49 regions, 70–71 scope of, 67–72 Multicast Address-Set Claim (MASC), 73, 121 connections, 75 domains, 75, 76 implementation with, 75 routers, 76 Multicast Backbone. See MBone multicast boundary routers, 106 Multicast Communication goal of, 5 organization, 5–6 multicast communication, 9–10 advantages, 18 in ATM, 174–176 defined, 1, 9

339

DiffServ and, 164, 311 across domain boundaries, 102, 103 emulation of, 16 examples, 10 in group communication, 10 illustrated, 9 on the Internet, 5 quality of service, 123–166 receivers and, 18 as underlying technology, 17 UNI, 188 unicast vs., 16–18 uses, 10 See also communication multicast control protocol (MCP), 259–260 message types, 259 purpose, 259 See also MFTP Multicast Extensions to OSPF (MOSPF), 97–105 asymmetric links and, 104 autonomous systems and, 99, 104–105 defined, 99 link state routing, 101 multicast trees and, 101 pruning and, 104 routers, 98–99, 100, 105 routing across domain boundaries, 102, 103 routing in domains, 100–102 routing subdivisions, 99 wildcard multicast receivers, 103–104 multicast IP routers, 181–182 multicast routing, 53–121 algorithms, 53–62 concepts of, 76–90 distribution tree, 77–78 between domains, 119–121 efficiency, 77 flooding and, 78 on the Internet, 90–121 mobile systems and, 310 Non-Querier state, 64 point-to-point routing vs., 76 Querier state, 64 source-based, 80–86 spanning trees and, 78–80 transient, 118

340

Index

multicast servers, 186 defined, 186 illustrated, 186 problem with, 186–187 VC mesh comparison, 187 Multicast Source Discovery Protocol (MSDP), 119–120 defined, 119 peering relationship, 120 source active data unit, 120 Multicast Transport Protocol. See MTP multicast trees, 53 bidirectional, 117 defined, 80 across domain boundaries, 105 dynamic control of, 92 MOSPF philosophy, 101 PIM-dense mode, 113 RPF and, 81 setting up, 80 storage in forwarding cache, 101 Multicast-Scope Zone Announcement Protocol (MZAP), 72 Multimedia Conference Control (MMCC), 300–302 availability, 302 conference setup, 301 defined, 300 functionality, 302 main window, 301 See also MBone applications multipeer communication, 11–13 in ATM, 174–176 defined, 11 example, 11–12 as goal, 13 illustrated, 12 implementation, 11 RMP, 232 XTP and, 205 See also communication multipoint communication. See multipeer communication

N negative acknowledgments (NAKs) critical situation with, 37

defined, 37 LBRM, 233, 234, 238 MTP, 220, 221 PGM, 252–253 SRM, 239–240, 243 See also acknowledgments neighbor probes, 91 network layer, 47–51 IP, 49 multicast addresses from, 49 tasks, 47 See also ISO/OSI reference model Network Service Access Point (NSAP) addresses, 184 Network Text Editor (NTE) availability, 286 defined, 286 illustrated, 287 See also MBone applications network-to-network interface (NNI), 178 non-RSVP clouds, 148–149

O open groups, 26 IP multicast, 180 limited, 258 MFTP, 258–259 unlimited, 258–259 See also closed groups; groups open learning distance, 2 Open Shortest Path First. See OSPF ordered delivery, 35–36 ordering global, 33, 35 MTP, 214, 221–223 RMP, 226, 228–230, 232 source, 35 SRM, 239 total, 35–36 organization, this book, 5–6 OSPF, 97–98 boundary routers, 102 data units, 97 database description, 98 link states, 98 load balancing, 98

Index metrics, 98 See also Multicast Extensions to OSPF (MOSPF)

P path data units (PATH), 134, 145 Adspec, 147 components, 146 sender template, 146–147 sender Tspec, 146 See also RSVP path error data units (PERR), 147 path tear data units (PTEAR), 148 per-hop behavior (PHB), 161 permanent groups, 27 defined, 27 examples of, 49 See also groups; transient groups PGM, 251–257 advance with data, 255 advance with time, 255 data transfer, 251 defined, 251 designated local repairer (DLR), 256 error control, 252–254 flow control, 254–255 Fragmentation option, 256 groups, 251 increment window, 254–255 Late Join option, 256 NAK anticipation, 253–254 NAK forwarding, 252–253 NAK suppression, 253 NCF data units, 253–254 ODATA data units, 251 options, 255–256 protocol procedures, 251–255 RDATA data units, 253, 254 Redirection option, 256 repairs, 253 routers and, 251 scalability, 257 source path state, 252 summary, 257 Time Stamp option, 256 transmit window, 254 See also transport protocols

PIM architecture, 106 hierarchical (HPIM), 114–117 PIM-DM, 106, 113–114 PIM-SM, 106, 107, 113 protocol independence, 106 protocols, 105–106 PIM-dense mode (PIM-DM), 113–114 assumptions, 113 defined, 106, 113–114 DVMRP and MOSPF vs., 113 multicast tree, 113 PIM-sparse mode vs., 113 router operation in, 113 use of, 114 PIM-sparse mode (PIM-SM), 107–113 defined, 106, 107–113 explicit group join, 107–108 interoperation, 114 multicast routing entries, 110 operating premises, 107 receiver joins group, 108–109 rendezvous points, 108 sender is active, 110–111 sender-specific tree, 111 shared tree, 109–110 transition to specific tree, 111–112 use of, 114 point-to-point communication, 8, 27 error recovery, 38 reliable services, 30 routing, 51 transport protocols, 51 unreliable, 30 Poison-reverse, 92–93 defined, 92 illustrated use of, 93 Pragmatic General Multicast. See PGM premium services, 163–164 aim of, 161 assumption, 162 assured services combined with, 163 audio transmission example, 161 capacity not utilized by, 162 first-hop router and, 162 See also Differentiated Services (DiffServ) profiles, 274

341

342

Index

programmable networks, 312 Protocol-Independent Multicasting. See PIM; PIM-dense mode (PIM-DM); PIM-sparse mode (PIM-SM) protocols AAP, 73, 74, 75 BGMP, 120–121 BGP, 75 DVMRP, 60, 67, 91–97 HDVMRP, 95–97 LBRM, 233–238 MADCAP, 73, 74 MASC, 73, 75 MFTP, 257–263 MOSPF, 97–105 MSDP, 119–120 MTP, 214–224 multicast, 52 OSPF, 97–98 PGM, 251–257 PIM, 105–117 RIP, 60 RMP, 224–233 RMTP, 243–251 RSVP, 124, 132, 133–149 RTCP, 273, 275–277 RTP, 272–277 SAP, 289–291 SDP, 291–293 SIP, 293–298 social, 23 SRM, 238–243, 286 SSCOP, 187 ST2, 124, 132–133, 149–155 TCP, 51 technical, 23 transport, 51–52, 197–263 UDP, 52, 198–203 XTP, 204–214 pruning data unit, 85 group dynamics and, 86 MOSPF and, 104 rendezvous points, 117 RPM implementation of, 85 push technologies, 22 defined, 22 examples, 3 reliability, 22

target group, 22 See also applications

Q quality of service, 123–166 Differentiated Services (DiffServ), 156–164 heterogeneous, 137 Integrated Services (IntServ), 124–156 ISDN, 123 relative, 158, 159 routing methods, 138 queries general membership, 62, 63 group-specific membership, 62, 63

R rapid service creation, 309 rate control defined, 211 MFTP, 260 MTP, 218 XTP, 211, 213 rate-based flow control, 39 Real-Time Transport Protocol. See RTP receiver-based mechanisms, 36–37 defined, 36 throughput and, 37 receiver-oriented stream setup, 153 reliability, 29–36 classes of, 30 distributed databases, 22, 33 group service, 19 push technologies, 22 statistical, 31–32 XTP, 212–213 reliable group services, 29–30, 33–35 applications needing, 33 atomicity, 33 defined, 33 error detection, 33–34 group membership and, 35 recovery mechanism, 33–34 See also group services; reliability Reliable Multicast Protocol. See RMP

Index Reliable Multicast Transport Protocol. See RMTP rendezvous points, 88–89 algorithm advantages, 89 candidate, 112, 119 core-based trees (CBT), 119 groups with, 88 hierarchy of, 115 PIM-sparse mode, 108 pruning, 117 technique comparison, 89–90 reservation data unit (RESV), 134, 145 reservation error data units (RERR), 147–148 reservation tear data units (RTEAR), 148 reservations, 140–145 aggregated, 157, 158 establishing, 140 fixed filter, 141–142 hard, 194 long-term, 157–158 merging, 144–145 shared filter, 142–143 styles, 141 using, 140 wildcard filter, 143–144 reshaping, 131 at merging point, 133 necessity, 131 outbound link, 132 Resource ReSerVation Protocol. See RSVP reverse path broadcasting (RPB), 82–84 defined, 82 routing with, 83 truncated (TRPB), 83–84 reverse path forwarding (RPF), 81–82 disadvantages, 81–82 flooding vs., 81 illustrated, 82 multicast tree and, 81 reverse path multicasting (RPM), 84–86 RIO (RED with input and output), 163 RIP (Routing Information Protocol), 60 RMP, 224–233 ACK data units, 228, 229 acknowledgments, 226, 227, 228, 229, 230 data list, 228–230 data management, 228–230 data units, 228–230 defined, 224–225

343

development, 224 disadvantages, 232–233 error recovery, 231–232 global ordering, 226 group management, 230–233 group members, 226 k-resilient, 225 LIST-CHANGE-REQUEST control data units, 230, 231 majority-resilient, 225 members leaving group, 231 multipeer communication, 232 NAK data units, 230 NEW-LIST data unit, 232 ordering, 232 ordering list, 228–230 RECOVERY-START data unit, 231, 232 reliability levels, 225 request strategy, 230 retransmission, 227 source-ordered, 225 summary, 232–233 token site, 226–227 totally ordered, 225 totally resilient, 225 unordered, 225 unreliable, 225 See also transport protocols RMTP, 243–251 ACK data units, 245, 246 acknowledgments, 245 congestion control, 250 connection control, 244–245 connection parameters, 244 connection release, 244, 245 connection setup, 244 data units, 246, 247 defined, 253 designated receiver selection, 248–249 designated receivers, 243, 245–247 disadvantages, 250–251 error recovery, 245–249 flow control, 249–250 intermediate retransmission, 246 Internet and, 248 rate control, 249 as receiver-oriented protocol, 245, 250 reliability, 249

344

Index

RMTP (continued) reliable multicast protocols, 243 RESET data unit, 245 retransmission, 246, 247 round-trip time, 248 RTT-ACK data units, 248 SND-ACK-TOME data units, 249 subcasting, 247–248 summary, 250–251 See also transport protocols Robust Audio Tool (RAT), 281 routers bootstrap, 106, 112 boundary, 95, 96, 102 dependent, 110, 111 DVMRP, 91, 92 edge, 160 first-hop, 160, 163 intermediate, 160 IP multicast, 181–182 leaf, 84 MASC, 76 MBone, 68, 81 MOSPF, 98–99, 100, 105 multicast boundary, 106 PGM and, 251 routing algorithms, 51, 53–62 adaptive, 55–56 centralized, 55–56 classification of, 54 distance-vector, 56–60 distributed, 56 incremental, 77 link state, 56, 60–62 static, 53–55 See also multicast routing routing metrics distance-vector algorithms, 56 link state algorithms, 61 static routing algorithms, 54 routing tables distance vector algorithms, 57–58 DVMRP, 91 example, 58 static algorithm, 53–54 structure, 58 Rspec (reservation specification), 130, 145 RSVP, 132, 133–149 active networks, 136

admission control, 139 in ATM switches, 139 classifiers, 139 concept, 134–135 conformation data unit (CONF), 134 daemon, 138, 139 data stream conversion and, 137 data unit common header, 145–146 data units, 145–149 defined, 124, 133–134 in end systems, 139 filter types, 141 FilterSpec, 141 FlowSpec, 140–141 heterogeneous multicast with, 135–137 IPv6 and, 148 network structure, 140 non-RSVP clouds and, 148–149 objects, 145 path data units (PATH), 134, 145 path error data units (PERR), 147 path tear data units (PTEAR), 148 periodic data exchange, 156 quality of service per receiver, 195 reservation data units (RESV), 134, 145 reservation error data units (RERR), 147–148 reservation sequence, 135 reservation tear data units (RTEAR), 148 reservations, 140–145 routing agent, 138 routing and, 137–138 schedulers, 139 soft state, 134, 135, 137, 194 ST2 vs., 155–156 systems, 138–140 UNI signaling vs., 193–195 uses, 134, 139 See also signaling protocols; ST2 RTCP, 273, 275–277 CNAME, 277 defined, 273 information provided by, 275 receiver report, 276–277 sender report, 277 source description, 277 RTP, 272–277 connection setup, 273 contributing source identifier (CSRC), 275 data units, 273–274

Index defined, 272 header extension, 275 mixer and translater, 276 parts, 272–273 profiles, 274 protocol stack, 273 RTCP part, 275–277 RTP part, 272, 273–275 sequence numbers, 274–275 synchronization source identifier (SSRC), 275 time stamps, 275 use of, 273 See also MBone applications

S scalability, 18–20 CBT and, 117–118 group communication server hierarchy and, 19–20 group size and, 19 MTP, 224 PGM, 257 reliability and, 19 role of, 5 Scalable Reliable Multicast. See SRM SCMP (Stream Control Message Protocol), 150 scoped session reports, 242 scoping, 67–72 administrative, 69–72 limitation, 67–68 mechanisms for, 68 TTL, 68–69 secondary logging servers, 236, 237 finding, 236 function of, 236 illustrated, 237 location of, 236 See also LBRM; logging servers security conferencing systems, 25 group, 27 semireliable group services, 31–33 defined, 31 example, 31 k-reliable, 32 statistically reliable, 31–32

345

sufficiently reliable, 32–33 types of, 31 See also group services; reliability sender-oriented stream setup, 152 sequence numbers, 37 Service-Specific Convergence Protocol (SSCOP), 187 Session Announcement Protocol (SAP), 289–291 announcement validity, 291 announcements, 289 data units, 291 defined, 289 UDP as transport service, 289 See also MBone applications Session Description Protocol (SDP), 291–293 defined, 291 media description, 292, 293 session description, 291–292 session description example, 293 time description, 292–293 See also MBone applications Session Directory (SDR), 286–289 availability, 289 defined, 287 features, 288–289 MBone sessions in, 288 session creation with, 290 session information, 288 See also MBone applications Session Initiation Protocol (SIP), 293–298 ACK request, 295 aspects, 294 BYE request, 296 CANCEL request, 296 defined, 293–294 example, 296–298 INVITE request, 295 methods, 295–296 OPTIONS request, 296 REGISTER request, 296 status codes, 294 transactions, 294 URLs, 294–295 See also MBone applications session reports, 239 shared filters, 142–143 defined, 142

346

Index

shared filters (continued) example, 143 See also filters shared media, 45 Ethernet with, 46 ISDN/ATM and, 46–47 shared tree, 109–110, 111 with rendezvous point, 109 structure, 109 signaling AAL (SAAL), 187, 188 signaling protocols, 124, 132–133 defined, 132 RSVP, 124, 132, 133–149 ST2, 124, 132–133, 149–155 traffic specifications and, 132 See also Integrated Services (IntServ) slotting and dumping, 213 social protocols, 23 source ordering, 35 source-based routing, 80–86 defined, 80 loops and, 80–81 pruning, 84–86 RPB, 82–83 RPF, 81–82 RPM, 84–86 summary, 87 technique comparison, 89–90 TRPB, 83–84 use of, 81 source-ordered RMP service, 225 spanning trees, 78–80 with bridges, 79 illustrated example, 79 traffic concentration at root of, 80 use of, 78–79 SRM, 238–243 ALF, 238 data transfer, 239–242 defined, 238–239 disadvantages, 243 error control, 239–242 error fingerprints, 242 group members, 239 hop-scoped error recovery, 240–241 local groups, 242 negative acknowledgments, 239–240, 243 ordering, 239

partially reliable service, 239 performance degradation, 240 reliability, 242 repair, 240 repair request, 240 retransmissions, 241 round-trip time estimation, 239 scoped session reports, 242 session reports, 239 summary, 242–243 whiteboard running on, 286 See also transport protocols ST2, 132–133, 149–155 accept data units, 152 communication scheme, 149, 150 connect data units, 151–152 connection termination, 153 data units, 154–155 defined, 124, 149 disadvantages, 149 error control, 154 hybrid stream setup, 153 implementations, 155 local resource manager (LRM), 151 receiver-oriented stream setup, 153 resource reservations with, 154 RSVP vs., 155–156 sender-oriented stream setup, 152 stream, 149 stream setup, 151 unreliable service, 150–151 uses, 156 See also RSVP; signaling protocols static groups decision, 44 defined, 27 See also dynamic groups; groups static routing algorithms, 53–55 in data networks, 54 routing metrics, 54 routing table, 53–54 usefulness of, 54–55 See also routing algorithms statistical bit rate (SBR), 172–173 statistical reliability, 31–32 Steiner trees, 86–88 defined, 86–87 heuristics, 87–88 limitations of, 87

Index optimization, 87 technique comparison, 89–90 trees with rendezvous points vs., 88 Stream Protocol Version 2. See ST2 subcasting, 247–248, 312 sufficiently group services, 32–33 synchronization problems, 17–18

T TCP, 51 technical protocols, 23 teleteaching, 2 token site, 226–227 acknowledging data unit, 227, 229 defined, 226 receiving no data units, 228 See also RMP token-bucket model, 126–127 bucket depth, 127 defined, 126–127 illustrated, 127 parameter, 126 token rate, 127 total ordering, 35–36 totally ordered RMP service, 225 totally resilient RMP service, 225 transient groups, 27 transmit window, 254 transport layer, 51–52 location of, 197 task, 51 transport protocols, 51–52, 197–263 LBRM, 233–238 MFTP, 257–263 MTP, 214–224 PGM, 251–257 point-to-point communication, 51 responsibilities, 52 RMP, 224–233 RMTP, 243–251 SRM, 238–243 UDP, 198–203 XTP, 204–214 trees with rendezvous points, 88–89 advantages, 89 data sources, 89 disadvantages, 89

Steiner trees vs., 88 technique comparison, 89–90 truncated RPB (TRPB), 83–84 defined, 83 illustrated, 84 traffic reduction, 83 Tspec (traffic specification), 126, 128–129 comparison of, 128 linear ordering of, 129 merging, 144 receiver, 128 rules, 128–129 sender, 147 signaling protocols and, 132 sum of, 144 TTL scoping, 68–69 defined, 68 disadvantages, 69 implementation, 69 threshold values, 68–69, 71 See also scoping tunnels, 266, 267 defined, 267 with IP-IP encapsulation, 270 with LSRR option, 268 routing through, 267

U UDP, 52, 198–203 defined, 198 IP unicast address with, 199 joining multicast group, 202 multiplexing functionality, 198 program declarations, 200 programming example, 199–203 receiving multicast data, 203 sending to multicast group, 203 setting TTL value, 202 socket binding, 201 socket opening, 201 sockets, 198 summary, 203 See also transport protocols UNI signaling, 178 CONNECT data unit, 188, 190 group join, 189–190 group join with UNI 4.0, 192

347

348

Index

UNI signaling (continued) group leave, 190–191 implementation, 187 leaf node, 192 multicast communication, 188, 189 new group member addition, 190 with no notification of root, 192–193 of point-to-point connection, 188–189 RSVP vs., 193–195 SETUP data unit, 188, 190, 192 UNI versions, 187 See also ATM unicast addresses, 45, 46 unicast communication, 8–9 defined, 8 examples, 9 group communication and, 8–9 illustrated, 8 multicast vs., 16–18 project meeting using, 16 reliability, 19 time-delayed transmission and, 17 See also communication unordered RMP service, 225 unreliable group services, 30–31 defined, 30 example, 30–31 RMP, 225 See also group services; reliability User Datagram Protocol. See UDP user network interface. See UNI signaling user-shared differentiation (USD), 163–164 advantages/disadvantages, 164 defined, 163–164 See also Differentiated Services (DiffServ)

V variable bit rate (VBR), 173 VC mesh, 185 illustrated, 185 multicast servers comparison, 187 uses, 185 VideoConference (VIC), 277–279 audio support and, 278–279 availability, 279 defined, 277–278

live transmission example with, 278 quality-of-service guarantees, 279 video coding support, 278 video window, 278 See also MBone applications virtual channel identifiers (VCIs), 169 virtual channels (VCs), 169 virtual classes, 3 virtual path identifiers (VPIs), 169 virtual paths (VPs), 169 Visual Audio Tool (VAT), 279–280 availability, 280 bandwidth and, 279 data formats, 279, 280 defined, 279 main window, 280 See also MBone applications

W webs defined, 214 masters, 214, 215, 217 structure, 215–216 See also MTP Weighted First Queuing (WFQ), 139 whiteboard (WB), 284–286 availability, 286 defined, 284 drawing elements, 284 illustrated, 285 reliable transmission, 285–286 running on SRM, 286 See also MBone applications wildcard filters, 143–144 defined, 143 example, 144 See also filters wildcard multicast receivers, 103–104 window-based flow control, 38–39

X Xpress Transport Protocol. See XTP XTP, 204–214 CNTL data unit, 208, 209 connection control, 205–210

Index connection release, 207–209 connection setup, 206–207 connection termination, 210 control, 205 data transfer, 210–213 data unit spans and gaps, 212–213 data units, 205 delay, 213 development, 204 DIAG data unit, 206 error control, 212–213 FASTNAK, 212 features, 204 FIRST data unit, 206 flow control, 210–211 goal, 205 information data units, 205

349

JCNTL data unit, 206, 207 late join illustration, 208 multicast connection setup illustration, 207 network layer functionality, 204 on top of IP, 204 rate control, 211, 213 reliability, 212–213 reliable multicast service, 205 retransmissions, 213–214 sender-initiated connection release illustration, 209 sequence numbers, 212 sliding window, 210 slotting and dumping, 213 summary, 213–214 transport layer functions, 204 See also transport protocols

About the Authors

Ralph Wittmann studied computer science at the University of Karlsruhe, Germany. He received the M.Sc. degree in 1995. Since then he has been a research assistant at the research group for High Performance Networking and Multimedia Systems at the Technical University of Braunschweig. His research interests center on multicast and multimedia communications in heterogeneous environments. Martina Zitterbart is a full professor in computer science at the Technical University of Braunschweig, Germany. She received her doctoral degree from the University of Karlsruhe in 1990. From 1987 to 1995 she was a research assistant at the University of Karlsruhe. In 1991 and 1992 she was on a leave of absence as a visiting scientist at the IBM T.J. Watson Research Center, Yorktown Heights, New York. Before joining TU Braunschweig she was a visiting professor at both the University of Magdeburg and the University of Mannheim. Her primary research interests are in the areas of multimedia communication systems, internetworking, and conferencing applications. She is member of IEEE (where she served on the Board of Governors of the Communication Society from 1995 to 1998), ACM, and the German Gesellschaft für Informatik.