MULTIMEDIA REALTIME TRANSPORT
`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
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 001
`
`
`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
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 001
`
`
`
`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
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 002
`
`
`
`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.
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 003
`
`
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 004
`
`
`
`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
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 005
`
`
`
`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.
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 006
`
`
`
`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
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 007
`
`
`
`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
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 008
`
`
`
`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
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 009
`
`
`
`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
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 010
`
`
`
`D Vita
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 011
`
`
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 012
`
`
`
`List of Tables
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 013
`
`
`
`xii
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 014
`
`
`
`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
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 015
`
`
`
`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 . . . . - . . . . . . . . . . . -
`-
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 016
`
`
`
`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.
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 017
`
`
`
`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.
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 018
`
`
`
`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.
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 019
`
`
`
`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
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 020
`
`
`
`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).
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 021
`
`
`
`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.
`
`- - - - - - - -
`
`-
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 022
`
`
`
`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
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 023
`
`
`
`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.
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 024
`
`
`
`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.
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 025
`
`
`
`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
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 026
`
`
`
`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-
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 027
`
`
`
`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.
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 028
`
`
`
`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
`
`CAVIUM-1070
`Cavium, Inc. v. Alacritech, Inc.
`Page 029
`
`
`
`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
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
