`PROTOCOL OVER ATM NETWORK
`
`A thesis submitted to the
`
`Department of Computing and Information Science
`
`in conformity with the requirements for
`
`the degree of Master of Sciences
`
`Queen's University
`
`Kingston, Ontario, Canada
`
`December 1996
`
`Copyright @ Zhenjun Zhu, 1395
`
`EX.1103.001
`
`DELL
`
`
`
`National Liirary
`
`BiblioWque nationale
`du Canada
`
`Acquisitions and
`Bibliographic Senhas
`
`Acquisitions et
`services bbliographiques
`
`The author has grrmted a non-
`exclusive licence allowing the
`Natiod Library of Canada to
`reproduce, loan, disttr'bute or sell
`copies of M e r thesis by any means
`and in any form or fo- making
`this thesis available to interested
`persons.
`
`L'auteur a accord6 une licence non
`exclusive permettant a fa
`BibIioth&pe nationale du Canada de
`teproduire, preter, distri'buerou
`vendre des copies de sa t h b de
`quelcpe manike et sous qyelcpe
`forme qoe ce soit pour mettre des
`exernplaires de cette these a la
`disposition des personnes interesshs.
`
`The author retains ownership of the
`copyright in hismer thesis. Neither
`the thesis nor substantial exlracts
`fiom it may be printed or otherwise
`reproduced with the author's
`permission.
`
`la th&e ni des d t s substantiek de
`celle-ci ne doivent &re imprimCs ou
`autrement reproduits saris son
`
`EX.1103.002
`
`DELL
`
`
`
`Abstract
`
`As ATM (Asynchronous Transfer Mode) neimorking switches and access equipment
`
`begin to be deployed on a wider scale, the de~relopment of applications which uti-
`
`lize high-bandwidth transport services is becoming a focus of research. TCP/IP was
`
`not designed to handle the real-time t r a c generated by broadband multi-media
`
`applications so a broadband transport protocol which supports the development of
`
`broadband real-time applications is needed.
`
`We propose a transport protocol middeware which includes broadband-specific
`
`transport senrice functions such as virtual connection setup, bandwidth reservation,
`
`and session synchronization, and which provides a development environment that
`
`integrates real-time delivery, quality of service guarantee, control and management.
`
`This transport service middle-ware is based on RTP (Real-time Transport Protocol)
`
`from IETF (Internet Engineering Task Force). The thesis discusses the design and
`
`implementation of QRTP (Queen's Real-time Transport Protocol) and evaluates the
`
`performance of the software.
`
`EX.1103.003
`
`DELL
`
`
`
`DELL EX.1103.004
`
`EX.1103.004
`
`DELL
`
`
`
`Acknowledgments
`
`I would like to thank Dr. Pat Martin, my supervisor and co-investigator in Queen's
`
`Multimedia Networking project, for his patience, guidance, suggestions, and generous
`conference sponsorship. Without these , I could never have completed this thesis.
`
`I would also like to thank Dr. H.T.MouRah of Department of Electrical and
`
`Computer Engineering, my co-supervisor and investigator of Queen's Multimedia
`
`Networking project, for his support and constant feedbacks into my work.
`
`Thanks also go to Wendy Powley and other members of Database System Labo-
`
`ratory, for their support and kiendship which is a main drive force in my work.
`
`I thank Natural Science and Engineering Research Council of Canada (NSERC)
`
`for awarding me a PGS-A scholarship which enables me to carry out this research. I
`
`therefore also thank Department of Computer Science, University of Western Ontario
`
`from where I applied for this award.
`
`Setting up of Queen's University ATM Multimedia Networking Testbed involved
`
`EX.1103.005
`
`DELL
`
`
`
`effort from other people, including Greg Macleod of Electrical and Computer En-
`
`gineering, Andy Hooper of Information Technology Service, Tom Bradshaw, Gary
`
`Powley, and Dave Dove of Computing and Momation Science department. I would
`
`like to give them m y sincere thanks on all the help I have got from them. New-
`
`bridge is generous enough to provide us with two ATM switches which make our
`
`research practically possible. I also thank heads of both Department of Electrical
`
`and Computer Engineering, and Department of Computing and Information Science,
`
`for providing important equipment funding used in connecting these switches, under
`
`a tight operation budget.
`
`EX.1103.006
`
`DELL
`
`
`
`Contents
`
`1 Introduction
`1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . . . . . . .
`1.2 Goals of the Research
`1.3 OutlineoftheThesis . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`2 Background and Related Work
`
`3
`
`4
`
`6
`
`7
`
`9
`
`. . . . . . . . . . . . . . . . . . . .
`2.1 Terminology and Basic Concepts
`10
`2.1.1 Real-time Tkansport Service . . . . . . . . . . . . . . . . . . . 10
`. . . . . . . . . . . . . . .
`2.1.2 Broadband Applications Over ATM
`. . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . .
`2.1.4 Resource Resenmtion and Scheduling
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`2.1.3 Quality of Service
`
`2.1.5 Session
`
`12
`
`13
`
`15
`
`15
`
`. . . .
`2.2 State of Broadband Multimedia Communication: An Overview
`. . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . .
`2.4 Work in Related Protocol Stacks
`20
`2.5 ATM API and Protocol Development Environments . . . . . . . . . . 22
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`2.3 Work in Broadband Applications
`
`2.6 QoS
`
`2.7 summary
`
`16
`
`19
`
`24
`
`25
`
`EX.1103.007
`
`DELL
`
`
`
`3 QRTP Architecture
`
`3.1 Protocol Data Format
`
`. . . . . . . . . . . . . . . . . . . . . . . . . .
`
`3.3 Protocol Entities
`
`3.3.1 Master Control Agent
`
`. . . . . . . . . . . . . . . . . . . . .
`3.2 ProtocolMiddlewareStructure-
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . .
`.4 daptation Service Agent
`. . . . . . . . . . . . . . . . . . . . .
`
`3.3.2
`
`3.3.3 Transport Service Agent
`
`27
`
`28
`
`30
`
`33
`
`33
`
`37
`
`37
`
`38
`
`39
`
`40
`
`42
`
`43
`
`45
`
`46
`
`48
`
`50
`
`51
`
`52
`
`52
`
`53
`
`3.3.4 Management Agent
`
`. . . . . . . . . . . . . . . . . . . . . . . .
`
`4 Protocol Mechanisms
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`4.1 Addressing
`
`4.2 Multiplexing
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`4.3 Buffering
`
`. . . . . . . . . . . . . .
`4.4 Connection Establishment and Terminat ion
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`4.5 Resequencing
`
`4.7 Multicasting
`
`4.8 Error Control
`
`. . . . . . . . . . . . . . . . . .
`4.6 Synchronization of Different Sessions
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . . . .
`4.9 Quality of Services Control
`. . . . . . . . . . . . . . . . . . . . . . . . . . . .
`4.9.1 Specification
`. . . . . . . . . . . . . . . . . .
`
`4.9.2 Passing Requirements to ATM
`
`4.9.3 Enforcement and Policy: Resource Management and Scheduling 54
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`4.9.4 Example
`
`59
`
`4.9.5 Session Scheduling
`
`. . . . . . . . . . . . . . . . . . . . . . . .
`
`60
`
`EX.1103.008
`
`DELL
`
`
`
`5 QRTP Implementation
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`5.1 overview
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`5.2 Data Structures
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . . . . . .
`
`5 .3.1 Application Interface Functions
`
`5.3.2 Agent Functions
`
`5.3 Modules
`
`63
`
`63
`
`64
`
`67
`
`67
`
`69
`
`5 -4 Implementation Issues
`70
`54.1 ATM Connection Establishment and Usage . . . . . . . . . . . 70
`
`. . . . . . . . . . . . . . . . . . . . . . . . . .
`
`5.4.2 Protocol As Part of Application Process vs . Separate Entities
`71
`5.4.3 TSA only vs . Combination of ASA and TSA . . . . . . . . . . 72
`
`6.1 QRTP Control Utility
`
`6.2 A Live Video Broadcasting Application
`
`6 Application Development Using QRTP
`. . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . .
`. . . . . . . . . . .
`6.3 An Audio Broadcasting Application: audioault i
`. . . . . . . . . . . . . . . .
`
`6.4 An Application Testing Synchronization
`
`7 Performance Evaluation
`
`75
`
`75
`
`77
`
`80
`
`80
`
`81
`
`83
`
`84
`
`84
`
`86
`
`88
`
`88
`
`7.1 Queen's University Multimedia Networking ATM Testbed
`
`. . . . . .
`
`81
`
`7.3 Latency
`
`7.3.1 Methods
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`7.2 General Method
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`7.3.2 Analysis
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`7.4 Throughput
`
`7.5 Loss Rate
`
`EX.1103.009
`
`DELL
`
`
`
`7.6 Comparison of QRTP over IP/ATM and QRTP over Hybrid Addressing 89
`. . . . . . . . . . . . . . . . . . . . . . . . . . .
`7.6.1 Methodology
`89
`7.6.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
`. . . . . . . . . . . . . . . . . . . . . . .
`7.7 Effectiveness of QoS ControI
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`7.8 Conclusion
`
`93
`
`93
`
`8 Conclusion
`95
`8.1 Thesis Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
`8.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
`8.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
`. . . . . . . . . . . . . . . . . . . . . . .
`8.3.1 Performance Tuning
`99
`8.3.2 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
`8.3.3 Transport Management . . . . . . . . . . . . . . . . . . . . . . 100
`8.3.4 QoS Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
`
`8.3.5 Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
`
`Bibliography
`
`102
`
`A QRTP Application Programming Interface
`111
`A.l Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
`A.2 Synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
`A.3 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
`A.4 Return Values and Errors . . . . . . . . . . . . . . . . . . . . . . . . 113
`
`B Protocol Data Unit Formats
`
`C Session Data Structure and Protocol Control Block
`
`115
`
`117
`
`EX.1103.010
`
`DELL
`
`
`
`D Vita
`D Vita
`
`121
`
`DELL EX.1103.011
`
`EX.1103.011
`
`DELL
`
`
`
`DELL EX.1103.012
`
`EX.1103.012
`
`DELL
`
`
`
`List of Tables
`List of Tables
`
`DELL EX.1103.013
`
`EX.1103.013
`
`DELL
`
`
`
`xii xii
`
`DELL EX.1103.014
`
`EX.1103.014
`
`DELL
`
`
`
`List of Figures
`
`2.1 Overd state of broadband application protocol stack . . . . . . . . . 16
`
`3.1 Protocol Data Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
`
`. . . . . . . .
`3.2 Overall structure of QRTP . . . . . . . . . . . . .. ..
`
`31
`
`3.3 MCA behavior when receiving Sessionfit request . . . . . . . . . . . 35
`
`3.4 MCA behavior when receiving SessionJoin and SessionJoinRemote
`request . . . . . . ~ . . . . . . . . . ~ . . . . . . . . . . . . . . . . . .
`36
`
`Hybrid addressing mechanisms . . . . . . . . . . . . . . . . . . . . . . 42
`
`States in session establishment . . . . . . . . . . . . . . . . . . . . . . 45
`
`Sequence Detection Algorithm . . . . . . . . . . . . . . . . . . . . . . 47
`. . . . . . . . . . . . . . . . . . . . .
`
`Sequence Correction Algorithm
`
`47
`
`Algorithm for TPDU resequencing . . . . . . . . . . . . . . . . . . . . 48
`Synchronization of QRTP Sessions . . . . . . . . . . . . . . . . . . . 50
`
`Specification of ATM QoS by QRTP . . . . . . . . . . . . . . . . . . 55
`QoS Operational Monitoring and Control Procedure . . . . . . . . . . 58
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`QoS Scheduling
`
`61
`
`5.1 Main modules
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`64
`
`EX.1103.015
`
`DELL
`
`
`
`5.2 Data structures . . . . . . . - . - - . . . - - - . . . . . . . . . . . . 66
`
`Overview on how APIs are used - . . . . . . . . . . . - - . - . . - - .
`Tk-based Q a P Controller when provisioning a session - . . . - . . -
`Running video broadcasting from source to two destinations.
`
`An interesting experiment is to visually observe playback delay of the
`
`clock image. If exactly 60 seconds elapsed at the sender side image
`
`(hand going exactly one circle), then the receiver side image should
`
`show the hand going exactly one circle in exactly 60 seconds. If it
`
`takes more than 60 seconds, then we may conclude sigrifmnt delay is
`inserted into the transport process. . - . . - . . . - - - . - - . -
`- . .
`
`Queen's ATM Testbed . . . . . . . . . . . . . . . - . . . . . . . . .
`Performance Evaluation hformation Collection Points . . . . . . . .
`Round Trip Delay Under Different T r S c Loads - . - . . . - . -
`- - .
`. . . . . . . . . . . . . . . . . .
`Amval rate when using native ATTM
`.Arrival rate when using TP over ATM . . . . - . . . . . . . . . . . -
`-
`
`EX.1103.016
`
`DELL
`
`
`
`Glossary
`
`AAL ATM Adaptation Layer-
`
`ACK Acknowledgment.
`
`API Application Program Interface.
`
`ASA Adaptation Senrice Agent. The process (thread) performing MAS functions.
`
`ATM .4synchronous Transfer Mode.
`
`ATMARP ATM Address Resolution P rotocoI. This protocol handles the conversion
`
`from IP address to ATM address and reverse.
`
`CTS Common Traosport Sublayer. A sublayer in QRTP layer which performs trans-
`
`port functions for QRTP TPDUs. It is under Media Adaptation Sublayer.
`
`IETF Internet Engineering Task Force-
`
`MCA Master Control Agent in QRTP implementation.
`
`MAS Media Adaptation Sublayer. A sublayer in QRTP layer which performs media
`adaptation to and from QRTP TPDUs.
`
`MIB Management Information Base.
`
`EX.1103.017
`
`DELL
`
`
`
`OC-3 Optical Carrier 3. A SONET standard. Bandwidth is 155 Mbps.
`
`PCB Protocol Control Block-
`
`PVC Permanent Virtual Circuit. As opposed to SVC, PVC is established manually
`
`by using ATM network management tools.
`
`RSVP Resource Reservation Protocol. A standard for IF' layer resource reservation
`
`proposed by IETF.
`
`RTP Real-time Transfer Protocol standard proposed by Audio/Video Work Group
`
`of ZETF.
`
`QRTP Queen's Real-time Tramport Protocol.
`
`SNMP Simple Network Management Protocol.
`
`SONET Synchronous Optical Network. A North America standard on optical trans-
`
`fer of signals. It includes different rates such as 52 Mpbs (OCI), 155 Mbps
`
`(OC-3), 465 Mpbs (OC12). It is in Physical Layer in OSI Reference Model.
`
`SSRC Synchronized Source. See definition in IETF RTP.
`
`SVC Switched Virtual Circuit. SVC, as opposed to PVC (Permanent Virtual Cir-
`
`cuit), is established automatically by programs sending ATM setup messages
`
`to network.
`
`TPDU Transport Protocol Data Unit.
`
`TS A Transport Service Agent. The process (threads) performing CTS functions.
`
`VC VirtuaI circuit at ATM layer.
`
`EX.1103.018
`
`DELL
`
`
`
`Chapter 1
`
`Introduction
`
`This thesis is motivated by the development of ATM (-4synchronous Transfer Mode)
`
`network technology and the demand for multimedia applications. -As a switching
`
`technology, ATM presents enormous advantages over the traditional network tech-
`
`nology such as Synchronous Transfer Mode (STM) and traditional LAN (Local .Area
`
`Network) technology [Hui94]. Great development effort invested in both ATM tech-
`
`nology, and underlying physical layer technologies such as SONET (Synchronous O p
`
`tical NETwork), has secured the reliable and efficient high-speed services offered by
`
`ATM networks.
`
`One of the advantages of ATM is that the single switch architecture can handle
`data celk of different media types. This feature presents a great opportunity for
`
`multimedia application development and deployment. On the other hand, demand
`
`for applications which utilize video, audio, high-definition images, and real-time data
`
`has increased with the growing c o ~ e c t i v i t y of Internet and Intranets.
`
`EX.1103.019
`
`DELL
`
`
`
`4
`
`CHAPTER 1. LNTRODUCTION
`
`The applications which interest us the most are those involving video and audio,
`
`such as video conferencing and video-on-demand (VOD). Traditional network proto-
`
`cols, such as TCP/IP can be used to develop such applications, however inefficiencies
`
`exist. It is yet to be seen whether IP Next Generation (IPng) [DHSG] over .4TM,
`
`which is still under development, wiU be ideal for multimedia application develop
`
`ment over ATM. Our research looks into constructing a real-time transport protocol
`
`which communicates over ATM network and conforms to the Real-time Transport
`
`Protocol (RTP) standard.
`
`1.1 Problem Statement
`
`As ATM becomes widely deployed as a broadband network technology, support for
`
`application development is becoming an important issue, especially for applications
`
`such as video and audio conferencing, which involve real-time data transfer. Devel-
`
`opment of these applications requires a middleware which functions as a transport
`
`protocol, and which provides an easy-to-use application programming interface ( API) .
`
`Such a protocoI was first proposed by the Internet Engineering Task Force (IETF)
`
`[IETF-AVT951 as Real-time Transport Protocol (RTPV2). RTPV2 was implemented
`
`over TCP/UCP/IP as a user-extended transport protocol in various audio and video
`
`tools. However, RTPV2 has not been implemented over ATM. Therefore, one of our
`
`targets is to construct a basic software structure which implements RTPV2 over ATM.
`
`Once RTPV2 has been implemented, the next challenge is to identify the main
`
`elements which control the delivery of real-time services to applications. Quality of
`
`Service (QoS) is a core concept in ATM technology and has been clearly defined in
`
`EX.1103.020
`
`DELL
`
`
`
`1.1. PROBLEM STATEMENT
`
`ATM standard specifications [ATMFORUM-UNI96, ATMFORUM-PNNI961. How-
`
`ever, how to provide QoS from the higher layer is still a research issue. We believe
`
`that resource reservation and dynamic control of senrice entities, including scheduling,
`
`are in most part, sufficient for most real-time applications. The challenge is therefore
`
`to implement certain resource management and dynamic control algorithms and to
`
`evaluate their effectiveness.
`
`Application development is also an important component of the research since it
`
`is vital to the testing of the function of the transport protocol middleware. We have
`
`selected video and audio conferencing tools as our primary test applications. The
`
`method employed to measure the performance of the middleware is also important,
`
`since it must allow us to not only collect performance-related information on a timely
`
`basis, but also analyze the impact of the information collection process on the per-
`
`formance.
`
`Other research issues addressed in the thesis are the following:
`
`Synchronization between different information flows, which is a requirement
`
`presented by some real-time applications such as audio and video conferencing.
`
`Multicasting, which is required in a multi-user environment.
`
`Flow control, which is associated with the performance of the transport protocol.
`
`.4 management protocol, which is required to manage and control the operation
`
`of the tramport protocol. In particular, we look at using a standard protocol
`
`such as Simple Network Management Protocol (SNMP).
`
`EX.1103.021
`
`DELL
`
`
`
`6
`
`CHAPTER 1. INTRODUCTTON
`
`1.2 Goals of the Research
`
`Based on the problems and issues presented above, the goals of the research are the
`
`following:
`
`1. Design and implement a basic set of s o h a r e modules on top of the ATM
`
`network layer which provides real-time transport services to applications.
`
`2. Evaluate the performance of this protocol with respect to meeting the require-
`
`ments of typical real-time applications.
`
`3. Study the other issues involved in real-time broadband application and extend
`
`the transport protocol to provide solutions to these issues.
`
`The underlying assumptions for the research are the following:
`
`The ATM network can provide reliable broadband network communication (so
`
`retransmission can be omitted for real-time purposes).
`
`Development and testing are based on single processor workstations, Sun Sparc
`
`4's, with real-time thread support in the operating systems, for example, Solaris
`
`The network is a simple ATM network, with 2 or 3 Sun Sparc 4 stations con-
`nected to 2 Newbridge 36150 ATM switches via 0G3 interfaces '. 140 Mbps
`connections are used between switches.
`
`Video and audio programming are based on high-level interfaces offered by the
`
`Solaris 2.5 operating system, such as the XIL library, instead of any low level
`
`media manipulation interface.
`' OC-3 is an optical fiber networking standard with bandwidth of 155 Mbps.
`
`- - - - - - - -
`
`-
`
`EX.1103.022
`
`DELL
`
`
`
`Fixed size protocol data units are used-
`
`In this thesis we will present an architecture, called QRTP (Queen's Real-time Trans-
`
`port Protocol), which has the following features:
`
`0 An easy-to-use MI.
`
`0 A hybrid addressing scheme which uses LP addresses to initialize or discover
`
`session endpoints, and uses ATM addresses for sending payload data directly
`
`over the ATM stack.
`
`A standard protocol data unit format for the Internet community, which will
`
`provide future compatibility with other IETF -4VT (Audio Video Transport)
`
`applications.
`
`0 A layered design which provides low protocol data unit loss and maximum
`
`guaranteed processing delay.
`
`0 A multi-entity concurrent processing model which further ensures better QoS
`
`under heavy transport load.
`
`A clearly defined management scheme and management information base (MIB).
`
`0 Flexibility in the use of middleware because it can be tailored for needs of
`
`different applications.
`
`1.3 Outline of the Thesis
`
`The thesis is organized as follows. In Chapter 2 we provide background to the thesis.
`
`It presents terminology and basic concepts and then discusses related work in the
`
`EX.1103.023
`
`DELL
`
`
`
`areas of ATM, IP over ATM, and development support for broadband applications.
`
`We next summarize the functional requirements of a real-time transport protocol,
`
`and its relationships with upper level applications and low level networks, then the
`
`design details in Chapter 3. Chapter 4 describes the protocol mechanisms. Chapter 5
`
`describes the implementation. Implementation of the middleware is done in C, using
`
`Solaris threads. Based on the middleware implementation, two applications which
`
`are used to test the package were also developed. Application development is briefly
`
`described in Chapter 6. In Chapter 7 a performance evaluation of the middleware is
`
`presented. The concluding remarks, a summary of the contribution of this work, and
`
`future research directions are given in Chapter 8.
`
`EX.1103.024
`
`DELL
`
`
`
`Chapter 2
`
`Background and Related Work
`
`Broadband multimedia communication is developing at an unprecedent rate. Both
`
`industry and research institutes are working towards producing more senices by
`
`taking advantages of the bandwidth made available by ATM networks. While the
`
`network architecture has been the focus of standardization, end-point architecture
`
`design has been left to different service providers. As a result, different protocol stacks
`have been developed for merent target domains. Such protocols include HTPNET
`
`[CG94], IR,M (Integrated Reference Model), OPENSIG (Open Signaling) [Laz92], and
`
`the Tenet protocol suite (BFMMVZ941. However, in the long run, these structures
`
`will converge as different computer network services and telecommunication services
`
`converge, because they all use the same underlying network structure. Before we
`
`study the entities related to the real-time transport protocol, it is necessary to paint
`
`an overall picture of the current components of broadband multimedia s e ~ c e s , their
`
`relationships, and where our research fits in.
`
`EX.1103.025
`
`DELL
`
`
`
`10
`
`CHAPTER 2- BACKGROUND AND RELATED WORK
`
`2.1 Terminology and Basic Concepts
`
`This section presents terminology and basic concepts for real-time multimedia appli-
`
`cations over broadband networks-
`
`2.1.1 Real-time Transport Service
`
`we define a real-time transport service as a service provided by the transport layer
`
`(OSI Reference Model Level 4) to distributed multimedia applications. This service
`
`is characterized by (1) fast and time-bounded data dehery; (2) guarantee of event
`
`temporal characteristics during playbacks; (3) synchronization between ditferent data
`
`flows; (4) support of multicasting for a multi-user environment; (5) good buffering
`
`and flow control mechanism to reduce data loss, and (6) QoS monitoring and control
`
`mechanisms-
`
`Fast and Time-bounded Delivery.
`
`ATM technology implemented on the top of SONET can provide high band-
`
`width (155 Mbps in case of OC3) to d o w tr&c fiom multiple applications,
`
`each of which can reserve some bandwidth, to be multiplexed onto the same
`
`connection. ATM supports statistical multiplezing, which means that -4TM ac-
`
`cess equipment can multiplex tr&c onto virtual circuits and statistically, rather
`
`that constantly, guarantee the quality of services to each t r a c source. There-
`
`fore, although an ATM network can provide fast delivery, in order to achieve
`
`time-bounded real-time services, a transport protocol must perform two tasks:
`
`(1) present proper QoS requirements to the ATM networks, and (2) implement
`
`a transport layer QoS control and resource reservation mechanism to ensure
`
`that the delay time within the transport layer is bounded. In our research, for
`
`EX.1103.026
`
`DELL
`
`
`
`2.1. TERMINOLOGY AND BASK CONCEPTS
`
`11
`
` network, we seIect the Constant Bit Rate
`any payload data sent over an A '
`(CBR) class for ATM QoS because it ensures a red circuit-like connection with
`
`dedicated bandwidth [ATMFORUM-Tbf 951.
`
`0 Temporal Characteristics in Playbacks
`
`For real-time applications, it is important to preserve two characteristics of
`
`an information flow, namely, the order of the events, and the time interval
`
`between any neighboring events. For example, in video conferencing, if the
`
`remote participant makes one move followed by another move 10 seconds later.
`
`then in the playback the time interval between these two moves should also be
`
`10 seconds. This requirement means that not only must the data representing
`
`the event be delivered to the remote end point within the time boundary, but
`
`it must be delivered to the application for playback a t the exact time-
`
`Synchronzzatzon
`
`Synchronization means that the events in one data Bow are to be correlated
`
`with those in another. An example of synchronization is lipsync in video-
`
`conferencing, where voice stream flow is synchronized with video stream flow.
`
`In our research we consider synchronization between two data flows.
`
`Buffering and Flow Control
`
`The ATM network layer performs very little flow control for the class of QoS
`
`we have selected. Flow control is left to the transport or application layer. At
`
`the transport layer, flow control ensures that the receiving entity can accept all
`
`the protocol data units transmitted by the sender, and that loss is reduced to
`
`a minimum-
`
`EX.1103.027
`
`DELL
`
`
`
`12
`
`CHAPTER 2. BACKGROUND AND RELATED WORK
`
`QoS monitoring and Control
`
`As defined by Stalling [Stallings93], performance management comprises two
`
`functional categories-monitoring and controlling. In a real-time transport ser-
`
`vices environment, it is important for users to monitor the operational status.
`
`Also, it is ideal if an intelligent management application can automatically moni-
`
`tor the senices and assert control decisions on the services. Performance related
`
`information, mostly equivalent to the QoS information which user applications
`
`are concerned about, should be organized into proper groups and presented by
`
`the management system in a clear format.
`
`2.1.2 Broadband Applications Over ATM
`
`There are a wide range of broadband applications currently being developed in both
`
`industry and academic research institutes which use broadband networks for new ser-
`
`vices. Examples are residential broadband services such as video-on-dernand (VOD)
`
`and video shopping, and business broadband services such as desktop video con-
`
`ferencing, telerobotics applications and telemedicine. Broadband applications can be
`
`broken into two categories based on the communication directions: (1) conversationaI
`
`senn'ces and (2) presentational services.
`
`Conversational services such as video conferencing involve symmetric communi-
`
`cation among the parties. The QoS requirements presented by all applications
`
`endpoints are the same.
`
`Present ationd services such as VOD involve asymmetric communications, with
`
`a large amount of bandwidth from the presenter of the information to the re-
`
`ceiver (downstream) and a small bandwidth being used for upstream.
`
`EX.1103.028
`
`DELL
`
`
`
`2.1. TERMINOLOGY AND BASE CONCEPTS
`
`13
`
`Applications can also be categorized based on the number of participants in the
`
`application operat ion. We can identify two categories: (1) unicast sewices, and (2)
`
`multzcas t senrices.
`
`0 Unicast services involve at most two parties in a point-to-point communication.
`
`0 Multicast services involve multiple endpoints in a point-to-multipoint or rnultipoint-
`t o-multi point communication. This requires the transport services to offer capa-
`
`bilities such as: (1) the ability to allow application endpoints to join, withdraw
`
`from an established information flow, and (2) the abiliw to deliver copies of the
`
`same data to all participants of a session.
`
`In our work we have attempted to construct the transport senrice protocol such that it
`
`can be used to serve all categories of applications but we have only built conversational
`
`multicasting test applications.
`
`2.1.3 Quality of Service
`
`There are many different metrics which can be used to indicate the performance of
`
`different applications. For exampie, Nahrstedt gives a set of audio and video QoS
`
`parameters and values [NAHRS5]. We define transport layer QoS to include metrics
`
`which are common for most applications, namely, end-to-end delay, inter-azrival jitter
`
`and error rate.
`
`1. Bandwidth (B W) is the number of TPDUs (Transport Protocol Data Units)
`
`that transport entities can process per second.
`
`2. End-to-end delay (EED).
`EED is the time between a TPDU entering the QRTP transmitting entity, and
`
`EX.1103.029
`
`DELL
`
`
`
`CHAPTER 2. BACKGROUND AND RELATED WORK
`
`the same TPDU departing the QRTP receiving entity at the remote end. This is
`made up of the following components: (1) queuing delay at the QRTP sending
`entity, (2) processing delay at the QRTP sending entity, (3) transmission delay
`
`from local ATM endpoint to remote ATM endpoint, (4) queuing delay at the
`
`remote QRW receiving entity, and (5) processing delay at the remote QRTP
`
`receiving entity. Since we use a fixed size protocol data unit, (2), (3) and (5) are
`
`constant, and the important Msiables are (1) and (4), which change depending
`
`on traffic load.
`
`3. Inter-am*val jitter is the difference between the smallest inter-amid interval
`
`and the largest one.
`
`This is important because we are considering constant rate media for real-time
`
`applications. If the inter-arrival jitter at the sender is 0, but it is large at
`
`the receiving end then the perceived QoS to the user is degraded. Therefore
`the QRTP receiving entity should perform some buffering and timing when
`
`forwarding received TPDUs to applications.
`
`4. Error rate is the percentage of TPDUs lost or received with error.
`
`For some real-time applications such as audio conferencing and important data
`
`fetching, a high error rate will result in unacceptable results.
`
`For each metric, an application endpoint presents a required value and a bound
`
`relative to the required value which can be translated into ATM layer QoS, traffic
`
`descriptor and bearer descriptor, and presented as part of ATM signaling requests
`
`when setting up the connection for information flow. As well, the metrics will be
`used by QRTP entities for QoS control at the transport level.
`
`EX.1103.030
`
`DELL
`
`
`
`AM3 BASE CONCEPTS
`2.1. ~ ~