Vo IP

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/234800763
Voice over IP Networks
Article · January 1999
CITATIONS READS
15 608
1 author:
Marcus Goncalves
Boston University
208 PUBLICATIONS 252 CITATIONS
SEE PROFILE
All content following this page was uploaded by Marcus Goncalves on 06 December 2018.
The user has requested enhancement of the downloaded file.

1 M. Goncalves – An Overview of IPv4 and IPv6 – May 25, 1998 - Chapter 01
VOICE OVER IP:
THE INTERNET-BASED TELEPHONY
Table of Contents
Table of Contents 1
PREFACE 8
Overview 9
Who Should Read This Book 12
About the Author 12
CHAPTER 1 14
An Overview of IPv4 and IPv6 14

A Basic Overview of IPv4 15
The Addressing System of IPv4 16
The Address Management Issues 17
The Need for IPv6 18
Some of IPv6 Advantages 19
IPv6 Address Enhancements 20
Auto-configuration 22
IPv6 Header 23
2 An Overview of IPv4 and IPv6 – May 25, 1998 - Chapter 2
IPv6 Extensions 24
Security Enhancements 25
Transitioning to IPv6 26
The 6bone initiative 29
Addressing and Routing 31
IPv6 for Businesses 35
Relevance of IPv6 40
IPv6 Multicasting 42
The Conversion Challenge 43
Business Opportunities for IPv6 44
IPv6’s Unicast, Multicast and Anycast Addressing 46
Address Resolution and Neighbor Discovery 49
IPv6’s Multimedia Features 54
IPv6’s Multicasting 54
Bandwidth Reservations 55
Packet Prioritizing 55
Jumbograms 55
IPv6’s Plug-and-Play Features 56
Address Discovery 56
Network Information Discovery 56
Automated Address Changes 57
Support for Mobile Hosts 57
Dead Neighbor Detection 57
Control Over Routing 58
Configurability of features 58
IPv6 Performance Considerations 58
Using Virtual LANs with IPv6 60
Router-based LANs 61
Switched-based LANs 62
Understanding Virtual LANs 63
What’s Next 69
CHAPTER 2 71
Understanding RSVP, IP Multicasting and ATMs 71

Understanding RSVP 73
IP Multicasting 77
IP Multicast Benefits 80
Using IP Multicast 81
An Overview of Asynchronous Transfer Mode Technology 84
ATM Technical Specifications 87
ATM’s Mission: the Delivery of Multimedia Services 89
ATM Network Design and Solutions 91
ATM Network Client Models 92
ATM’s VLAN Model 94
ATM’s Routed Model 96
Part I. The Technology – May 25, 1998 - 3
ATM’s Connection-Oriented 99
Basic Understanding of ATM Networks 102
What’s Next 109
CHAPTER 3 112
IP Superhighway 112
Voice over IP 112
Carrying Voice Over Data Channels 113
Multiprotocol Support is Key 115
Providing for Scalability and Management Tools 116
The H.323 Standard 120
DataBeam H.323 Toolkit Series 124
IP over ATM 125
Encapsulating IP 127
TCP over ATM 128
Voice Over ATM 130
IP over SONET 131
SONET Benefits 133
Synchronous Multiplexing 135
Voice over SONET 136
SONET and Other Data Streams and Protocols 137
IP over Frame Relay 140
Voice over Frame Relay 142
Voice Over Frame Relay and Cost Benefits 143
Comparing Dial Voice Costs with Frame Relay 146
Voice over Private Frame Relay 146
Is Voice Over Frame Relay a Viable Option? 148
Frame Relay vs. Leased Lines 148
Frame Relay vs. ATM 149
Frame Relay vs. the Internet 150
Equipment for Voice Over Frame Relay 151
Technical Challenges for Transporting Voice Over Frame Relay 153
Controlling Delay 154
Equipment for Voice Over Frame Relay 162
Network Design Considerations 164
Committed Information Rate (CIR) 164
CIR with Mixed Voice/Data Submultiplexing 166
High Speed Flooding and Traffic Shaping 168
Delay and Priority 169
Congestion Indication 171
Efficiency 172
Echo Cancellation 173
Dialing Plan 174
Understanding Layer 3 Switching 175
Why Layer 3 Switching? 177
But What is Layer 3 Switching? 180

Introduction to Gigabit Ethernet 183
Fundamentals of Gigabit Ethernet? 184
Gigabit Ethernet Benefits 185
How Gigabit Ethernet Measures Up Against Other High-speed Solutions 187
What’s Next 190
CHAPTER 4 192
More on IP Multicasting 192

An Overview 194
Types of Transmission 195
Multicast Address Translation 197
Multicasting and Routing 199
IP Multicasting Uses and Benefits 200
Network Load Reduction 201
VoIP and Video Conferencing 202
A Word About the Multicast Backbone 204
The Capabilities of Multicasting 207
Multicast Routing with IP 211
IP Multicast Enabled Multimedia Applications 214
IP Multicast Enabled Information Distribution Applications 215
IPv4 versus IPv6: The Multicast Addressing Issues 218
What’s Next 220
CHAPTER 5 222
More on ATM Technologies 222

Describing ATM Services and Support 223
Connection-Oriented Support 225
Integrated Services Support 226
Voice Support 226
Video Support 227
Data Support 228
Quality of Service Support 230
Summary 233
ATM Networking 234
The End-to-end ATM Model 235
The ATM Desktop Model 236
The Campus Backbone Model 237
The WAN Model 238
ATM Carrier Model 239
IP Over ATM Requirements 241
ATM Network Services 243
ATM Client/Server Accessibility 245
ATM Classical IP Services 247
The Next Hop Resolution Protocol (NHRP) 249

ATM Forum Multiprotocol Over ATM (MPOA) 253
IP Switching and Multiprotocol Label Switching (MPLS) 255
Summary 258
What’s Next 258
CHAPTER 6 260
Broadband Packet Networks and Voice Communication 260

Broadband Packet Networks 263
The Evolution to Workstation-Based Systems 265
Broadband Packet for LANs 267
Internetworking LANs 268
Packetized LAN Interconnection 270
Understanding Fractional T1 272
Time Fractional T1/T3 273
Multiplexers and Framing 275
Circuit Multiplexing 276
Packet Multiplexing 279
Packet Switching 284
Understanding Broadband Packet 286
Frames and Cells 290
Interface standards 295
Broadband Packet & the OSI Model 297
What’s Next 298
CHAPTER 7 300
Codecs Methods 300

Video Codecs Review 300
Audio Codecs 302
Waveform Codecs 303
Defining Pulse Code Modulation (PCM) 303
Defining Compacting/Expanding (Companding) Codecs 304
Defining Adaptive Differential PCM (ADPCM) -- 305
Source Codecs 305
Hybrid Codecs 307
Installing Audio Codecs on Windows 95/NT 4.0 307
What’s Next 309
CHAPTER 8 311
Voice Over IP: Can We Talk? 311

VOIP Applicability 312
Computer Telephony Integration (CTI) 314
Videoconferencing 315
Document-sharing 319
Web-Based Call Center Applications 320
VOIP Challenges 321
Getting Telcos up to speed 321
Setting standards 322
H.323 322
H.100/H.110 324
MVIP 326
CompactPCI 327
What’s Next 328
CHAPTER 9 329
What to Expect: The Innovators 329

Some of VoIP Major Players 330
3Com’s Total Control HiPer Access System 331
3Com’s Total Control System: Maximizing Internet Technologies. 331
3Com and eFusion: Enhancing VoIP 334
Sound Design’s SoundWare 334
Natural MicroSystems’ Fusion 336
Fusion 337
Features 338
Fusion Hardware 340
Fusion Software 341
Packet Network Integration 342
Broadest Selection of Vocoders 342
H.323 Protocol 343
RTP/RTCP Library 344
User Datagram Protocol 344
Programmable Jitter Buffer 345
Vocoders Supported 345
Protocols Supported 346
Motorola’s VIPR 346
Nuera Communication’s Access Plus Series 349
The Access Plus F200 350
The Access Plus F120 351
Advanced Voice Compression 351
Call Routing 352
Call Processing 353
Data Frad and Switch 353
Digital Interfaces 354
Access Plus F200ip 354
A High Performance System 354
An Advanced Voice Compression 355
High Bandwidth Efficiency 356
Call Routing 356

Flexible Voice Interfaces and SNMP Network Management 357
A Brief Overview of NueraView 357
Increased Network Uptime 358
Easier Operations 358
Portable Voice Module 360
Access Plus 100 and Access Plus 200 360
Clarity Series CS8000 – Voice/Data Multiplexing 361
Voice Compression 361
Qwest Communications’ Macro Capacity Fiber Network 362
Qwest’s Macro Capacity Fiber Network 364
NetSpeak Corporation’s WebPhone 368
WebPhone 369
NetPhone’s PBX Servers 374
Vocaltec’s Internet Phone and Telephony Gateway Server 377
The VocalTec Ensemble Architecture 379
The Internet Phone 380
The VocalTec Telephony Gateway Server 380
Vienna Systems’ Vienna.way 381
Vienna.way 382
Lucent Technologies’ Internet Telephony Server-E (ITS-E) 386
The Internet Telephony Server - E (ITS-E) 387
MultiMedia Communications eXchange Server (MMCX 2.1) 388
Internet Telephony Server for Service Providers (ITS-SP) 390
Northern Telecom’s Webtone 391
Internet Voice Button 393
How It Works 394
What’s Next 395
CHAPTER 10 397
The Real Time Streaming Protocol 397

The Real Time Streaming Protocol 398
Properties of RTSP 401
Next Step 402
APPENDIX A 404
List of Suppliers 404
APPENDIX B 413
Glossary of terms 413

Preface
“Voice Over IP: The Internet-based Telephony,” thoroughly explores the potential, and
increasing demand, of delivering Internet-based telephony as the next technological and
profitable frontier for every company running a TCP/IP stack network. Up to now, the Internet
run over the phone lines, but voice over IP technologies reverses this trend, by providing
telephony services over the Internet.
This book was developed with IPv6 in mind, exploring and explaining how these two cutting
edge technologies will merge together to deliver powerful telephony-based services and
applications. But of course it does take IPv4 in consideration and argues about the complexity
of deploying this technology, due to the connectionless nature of IP networks and the
engineering challenges it brings.
This book also thoroughly explores the potential investment in terms of both money and
technology. It provides in-depth discussion of the main practical implementation and solutions
being advocated by leading vendors and their products, such as 3Com’s VoIP implementation
Total Control™ HiPer™ Access System, Motorola’s VIPR, Nuera Communication’s Access
Plus F200ip Voice FRAD/VoIP and others.
By the end of this book the reader should be able to have a full understanding of how VoIP
(Voice Over Internet Protocol) works, what are the main challenges in implementing it and
what are the main vendors and their products. The reader will also have a reasonable
knowledge of the main products and implementation solutions being proposed.
Overview
The book is divided in three parts.
Part I – “The Technology,” provides basic technical grounds for understanding IP and the
voice transferring process over it.
Chapter 1, “An Overview of IPv4 and IPv6,” provides information about the IPv4’s strenght
and weaknesses of a successful protocol, as well as coverage of IPv6 and its enhanced
internetworking capabilities.
Chapter 2, “Understanding RSVP, IP Multicast and ATMs,” provides you with the
fundamentals of RSVP, IP Multicast and an overview of ATM, which are important
technologies in carrying voice over IP.
Chapter 3, “IP Superhighway,” introduces the basic concepts of voice over IP, and its most
used H.323 standard. It also discusses other standards and technologies such as audio codecs,
IP over ATM, voice over ATM, the emulation of traditional T1/E1 Trunks, IP over SONET
and voice over SONET, and IP and voice over frame relay. Further, this chapter discusses
Layer 3 switching and gigabit Ethernet as well as their role in VoIP.
Chapter 4, “More on IP Multicasting,” discusses multicasting in workgroups, some of its
capabilities on hosts and routers, as well as usage and implementation, especially with VoIP.
Chapter 5, “More on ATM Technologies, “ discusses the ATM data model, its network
services, data protocols and LAN emulation, as well as ATM MPOA services.
Chapter 6, “Broadband Packet Networks and Voice Communication,” discusses broadband
packet networks and its role in voice communication and applications.
Part II, “Hands-on VoIP: Standards and Implementations,” is a practical section, where
implementation issues are discussed, as well as proposed scenarios are presented.

Chapter 7, “Codecs Methods,” covers the technology and standard employed in voice
digitization, as well as a video codecs review and audio codecs.
Chapter 8, “Voice Over IP: Can We Talk?,” focus on the applicability of VoIP, such as in
computer telephony integration (CTI), videoconferencing, document-sharing, web-based call
center applications, etc. It also discusses the challenges VoIP faces, both with getting telcos up
to speed, as well as setting standards. It goes on listing the major VoIP players, including
3Com, Motorola, Nuera Communication and others.
Chapter 9, “What to Expect: The Innovators,” assesses what is being offered by VoIP
inovators such as NetSpeak, NetPhone, Vocaltec, TeleVideo Conversions, Inc., Vienna
Systems, Lucent Technologies, and few others.
Part III, “Advanced VoIP,” outlines the major players of the industry, their products, technical
characteristics and specification.
Chapter 10, “The RTSP Protocol,” assesses the Real Time Streaming Protocol (RTSP).
At the end of the book, you will find two appendixes. Appendix A, provides a list of VoIP
Vendors, and Appendix B provides a comprehensive glossary of terms related to VoIP.

Who Should Read This Book
This book is designed for systems managers, network administrators, systems integrators,
Internet managers and even Chief Information Officers implementing or planning to
implement VoIP in their businesses. It provides a brief general review of basic concepts of
IPv4, IPv6 and VoIP, for those not too familiar with IP. It also provides advanced
configuration and troubleshooting information for those professionals heavily involved with
VoIP projects and a outline of the main products available on the market..
About the Author
Marcus Goncalves, holds an MS in CIS, several years of internetworking consulting in the
IS&T arena. He’s a Sr. IT Analyst for Automation Research Corporation, advising
manufacturers on IT, industry automation and Internetworking security. He has thought
several workshops and seminars on IS and Internet security in U.S. and internationally. Has
published several books related to the subject such as Firewalls Complete, with McGraw-Hill;
Protecting Your Web Site With Firewalls, with PTR/Prentice Hall, Internet Privacy Kit, with
Que, Windows NT Server Security, with PTR, IPv6 Networks with McGraw-Hill, and few
others. He’s also a regular contributor for several magazines such as BackOffice, Developer’s
and WEBster. He’s a member of the Internet Society, International Computer Security
Association (ICSA), the Association for Information Systems (AIS) and the New York
Academy of Sciences. Goncalves is the Chief editor of the Journal for Internet Security (JSec).
Chapter 1
An Overview of IPv4 and IPv6
IPv4 was developed awhile ago, in 1975, and provides for approximately 4.2 billion possible
combinations. Although this sounds like more than enough addresses, the truth is that every
machine as well as every interface on every machine requires a unique address. We therefore
find ourselves in our current position, lacking enough capacity in addresses to cover the
impending supply of users.
By the beginning of the new century, the Internet community will need enough IP addresses
for the billions upon billions of new customers that it attracts as well as the possible new host
being setup and connected to the Internet. IPv4, does have the capability for more than 4
billion addresses, but still, it is not adequate to handle the demand, not much for the number of
addresses it can handle, but the way it groups bits for its network/host numbering system. The
problem here is that IPv4’s numbering system wastes address assignments and suffers from
excessive routing overhead.
A Basic Overview of IPv4
IPv4 supports a fixed 32-bit field for addressing, which is no longer sufficient for the number
of users on the Internet. Routing tables are growing exponentially and this has been causing a
great deal of difficulty for many organizations as well. In addition to these items, auto-
configuration and scaleable multicast are in need. Furthermore, there is a need to develop
real-time flow for video conferencing, as we will be discussing throughout this book. These
remain the key issues associated with the move toward a new protocol format.
IPv4 addresses are categorized according to the size of a network (number of IP addresses
used). These categories are known as address classes. The first three categories are those that
we are concerned with and they maintain a different amount of bits for the networkID portion
of their addresses. Class B for example, has 14 bits for the networkID and 16 for the hostID
combining to form 16,384 outcomes and each of these outcomes can accommodate 65,534
hosts.
The major problem with this scheme is that the networks that are most numerous in number
are those in the middle of this class structure. The number of addresses has remained static
and the distribution of networks has been evolving to lump around the intermediate networks.
Subnettting and supernetting has been developed in part to help fix this problem.
The Addressing System of IPv4
IP addressing is based on network number assignment and host number assignment. In IPv4,
these numbers are organized as 32-bit addresses, with host numbers and network numbers
embedded in the addresses. These numbers identify the network or host connection and not
the actual network or computer. IPv4 divides its address assignment into three main classes:
A, B, and C.
• Class A addresses assign the first 7 bits (or 1 byte) to a network and the last 24
bits (or 3 bytes) to a host. These addresses are reserved for organizations that have
up to 16 777 216 hosts, and there can be at most 128 of these networks.
• Class B addresses assigns the first 14 bits (or 2 bytes) to a network and the last 16
bits (or 2 bytes) to a host. These addresses are reserved for organizations that have
up to 65 536 hosts, and there can be at most 16 384 networks.

• Class C addresses assign the first 21 bits (or 3 bytes) to a network and the last 7
bits (or 1 byte) to a host. These addresses are reserved for organizations that have
less than 256 hosts, and there can be at most 2 097 152 networks.
The address class determines the network mask of the address. A network mask is a 32-bit
Internet address that has all the bits in the network number set to one and all the bits in the host
number set to zero. Hosts and routers use the network mask to route Internet packets.
The Address Management Issues
Although the amount of possible addresses seem enough to suit the world needs for IP
address, the way IPv4 handles the addresses within each of these classes prevents from it.
Take for example an organization seeking 300 host addresses. The amount of IP addresses the
organization seeks puts them into the Class B category. However, if the company is assigned a
Class B address, then they would have 65 536 hosts, which is significantly more than what is
needed, which waists about 65 000 addresses!
To avoid this type of situation, the Classless Inter-Domain Routing (CIDR) scheme was
introduced a few years ago. CIDR essentially eliminates the class structure of addressing and,
instead, allows the assignment of network numbers at any bit boundary. In this way network
numbers can be created, for example, by aggregating several contiguous class C addresses.
CIDR requires that network masks be explicitly specified when needed, rather than allowing
them to be implicitly derived from the address (as in the class system).
Another problem attributed to IPv4’s address classes is the Internet backbone router table size
explosion. CIDR also addresses this by allowing for address aggregation. Furthermore, a
negative aspect to CIDR is that with an arbitrary address, you cannot determine the network
and host numbers unless you know the network mask. But the limitations of IPv4 have
quickly been realized and measures, such as CIDR, have extended its life slightly. Worldwide
network demand, however, is making the need for IPv6 immediate.
The Need for IPv6
It is anticipated that in the early XXI century, just around the corner, the Internet will be
routinely used in ways just as unfathomable to us, today. Its usage is expected to extend to
multimedia notebook computers, cellular modems, and even appliances at home, such as your
TV, your toaster and coffee maker (remember that IBM’s latest desktop PC model already
comes with some of these remote functionality to control your appliances at home!).
Virtually all the devices with which we interact, at home, at work, and at play, will be
connected to the Internet – the possibilities are endless, and the implications staggering,
especially as far as security and privacy goes.

The advent of the IPv6 initiative doesn’t mean that the technologies will exhaust the
capabilities of IPv4, our Internet technology. However, as you might expect, there are still
compelling reasons to begin adopting IPv6 as soon as possible. However, this process has its
challenges, and as essential to any evolution of Internet technology, there are requirements for
seamless compatibility with IPv4, especially with regards to a manageable migration, which
would allow us to take advantage of the power of IPv6, without forcing the entire Internet to
upgrade simultaneously.
Thus, IPv6 becomes a central point, the cornerstone for the Internet and its viability to serve
corporate networks, IP multicasting, the global e-commerce and telephony applications such
as voce over IP and more.
Some of IPv6 Advantages
It is important to note the intent behind the IPv6 design. It was not designed to be a huge leap
away from what has worked in IPv4. This would be catastrophic, as backward compatibility
would not be assured. This version of the protocol is designed to be growths move out of
something that works but no longer fits the requirements of the user community.
IPv6 Address Enhancements
IPv6 kept all the working functionality of IPv4 and integrated into the new version of the
protocol. Along the same lines, things that did not work so well in IPv4 were intentionally left
out of the new version. Below is a summary list of the main changes that have been
implemented on IPv6:
• Expanded Routing and Addressing Capabilities,
• IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels
of addressing hierarchy and a much greater number of addressable nodes, and
simpler auto-configuration of addresses,
• The scalability of multicast routing is improved by adding a "scope" field to
multicast addresses,
• A new type of address called a "anycast address" is defined, to identify sets of
nodes where a packet sent to an anycast address is delivered to one of the nodes.
The use of anycast addresses in the IPv6 source route allows nodes to control the
path which their traffic flows,
• Header Format Simplification,

• Some IPv4 header fields have been dropped or made optional, to reduce the
common-case processing cost of packet handling and to keep the bandwidth cost of
the IPv6 header as low as possible despite the increased size of the addresses.
Even though the IPv6 addresses are four time longer than the IPv4 addresses, the
IPv6 header is only twice the size of the IPv4 header,
• Improved Support for Options,
• Changes in the way IP header options are encoded allows for more efficient
forwarding, less stringent limits on the length of options, and greater flexibility for
introducing new options in the future,
• Quality-of-Service Capabilities,
• A new capability is added to enable the labeling of packets belonging to particular
traffic "flows" for which the sender requests special handling, such as non-default
quality of service or "real- time" service,
• Authentication and Privacy Capabilities, and
• IPv6 includes the definition of extensions, which provide support for
authentication, data integrity, and confidentiality. This is included as a basic
element of IPv6 and will be included in all implementations.

Auto-configuration
Auto-configuration, or plug-and-play, has been introduced as a concept in IPv6. Under this
concept, a host who has been established as a resource on the Internet will be not be required
to re-establish itself as a host again. This host will be able to connect as a node on the network
with a minimal amount of configuration. This will reduce a great deal the time LAN
administrators spend configuring and maintaining IP addresses lease. In a broader context,
individuals who travel will not be required to reconfigure in order to gain connectivity to the
Internet.
This aspect of IPv6 has an added benefit in that it does not require DHCP. It is interesting to
note the way in which this has been proposed. A ‘local link IP address’ will be developed
upon the initialization of a physical layer device such as a NIC. As part of the Ethernet
standard for example, such addresses are unique from one another. Building on these
addresses and creating a unique IP address as a derivation of the Ethernet address will ensure
successful addressing of the NIC. This is the IP address that can be established in auto-
configuration. This approach is similar to that of IPX, which has been quite successful.
IPv6 Header
The IPv6 header, as shown on figure 1.1, consists of eight discreet items, many of them being
quite innovative and obviously directly targeted at some of the shortcomings of IPv4. These
items are:
• Version,
• Prior(ity) Flow Label,
• Payload Length,
• Next Header,
• Hop Limit,
• Source Address and
• Destination Address.
Figure 1.1
IPv6 header, broken down in eight discreet items.

IPv6 Extensions
IPv6 includes an improved option mechanism over IPv4. IPv6 options are placed in separate
extension headers that are located between the IPv6 header and the transport-layer header in a
packet. All IPv6 extension headers are not examined or processed by any router along a
packet's delivery path until it arrives at its final destination. This facilitates a major
improvement in router performance for packets containing options. In IPv4 the presence of
any options requires the router to examine all options.
The other improvement is that unlike IPv4 options, IPv6 extension headers can be of arbitrary
length and the total amount of options carried in a packet is not limited to 40 bytes. This
feature plus the manner in which they are processed, permits IPv6 options to be used for
functions which were not practical in IPv4. A good example of this is the IPv6 Authentication
and Security Encapsulation options.
In order to improve the performance when handling subsequent option headers and the
transport protocol which follows, IPv6 options are always an integer multiple of 8 octets long,
in order to retain this alignment for subsequent headers. The IPv6 extension headers, which
are currently defined, are:
• Routing - Extended Routing (like IPv4 loose source route),
• Fragmentation - Fragmentation and Reassembly,

• Authentication - Integrity and Authentication,
• Security Encapsulation - Confidentiality,
• Hop-by-Hop Option - Special options which require hop by hop processing, and
• Destination Options - Optional information to be examined by the destination
node.
Security Enhancements
IPv4 has a number of security problems and lacks effective privacy and authentication
mechanisms below the application layer. IPv6 remedies these shortcomings by having two
integrated options that provide security services. These two options may be used singly or
together to provide differing levels of security to different users. This is very important
because different user communities have different security needs.
The first mechanism, called the "IPv6 Authentication Header", is an extension header which
provides authentication and integrity (without confidentiality) to IPv6 datagrams. While the
extension is algorithm- independent and will support many different authentication
techniques, the use of keyed MD5 is specified as the default algorithm to help ensure
interoperability within the worldwide Internet. This can be used to eliminate a significant
class of network attacks, including host masquerading attacks.

The use of the IPv6 Authentication Header is particularly important when source routing is
used with IPv6 because of the known risks in IP source routing. Its placement at the Internet
layer can help provide host origin authentication to those upper layer protocols and services
that currently lack meaningful protections. This mechanism should be exportable by vendors
in the United States and other countries with similar export restrictions because it only
provides authentication and integrity, and specifically does not provide confidentiality. The
exportability of the IPv6 Authentication Header encourages its widespread deployment and
use.
The second security extension header provided with IPv6 is the "IPv6 Encapsulating Security
Header". This mechanism provides integrity and confidentiality to IPv6 datagrams. It is
simpler than some similar security protocols (e.g., SP3D, ISO NLSP) but remains flexible and
algorithm-independent. To achieve interoperability within the global Internet, the use of DES
CBC is being used as the standard default algorithm for use with the IPv6 Encapsulating
Security Header.
Transitioning to IPv6
The key transition objective is to allow IPv6 and IPv4 hosts to interoperate. A second
objective is to allow IPv6 hosts and routers to be deployed in the Internet in a highly diffuse
and incremental fashion, with few interdependencies. A third objective is that the transition
should be as easy as possible for end-users, system administrators and network operators to
understand and carry out.
The IPv6 transition mechanisms are a set of protocol mechanisms implemented in hosts and
routers, along with some operational guidelines for addressing and deployment, designed to
make transition the Internet to IPv6 work with as little disruption as possible. The IPv6
transition mechanisms provides a number of features, including:
• Incremental upgrade and deployment. Individual IPv4 hosts and routers may be
upgraded to IPv6 one at a time without requiring any other hosts or routers to be
upgraded at the same time. New IPv6 hosts and routers can be installed one by
one,
• Minimal upgrade dependencies. The only prerequisite to upgrading hosts to
IPv6 is that the DNS server must first be upgraded to handle IPv6 address records.
There are no pre-requisites to upgrading routers,
• Easy Addressing. When existing installed IPv4 hosts or routers are upgraded to
IPv6, they may continue to use their existing address. They do not need to be
assigned new addresses. Administrators do not need to draft new addressing
plans, and
• Low start-up costs. Little or no preparation work is needed in order to upgrade
existing IPv4 systems to IPv6, or to deploy new IPv6 systems. The mechanisms
employed by the IPv6 transition mechanisms include:
• An IPv6 addressing structure that embeds IPv4 addresses within IPv6 addresses,
and encodes other information used by the transition mechanisms,
• A model of deployment where all hosts and routers upgraded to IPv6 in the early
transition phase are "dual" capable (i.e. implement complete IPv4 and IPv6
protocol stacks),
• The technique of encapsulating IPv6 packets within IPv4 headers to carry them
over segments of the end-to-end path where the routers have not yet been upgraded
to IPv6,
• The header translation technique to allow the eventual introduction of routing
topologies that route only IPv6 traffic, and the deployment of hosts that support
only IPv6. Use of this technique is optional, and would be used in the later phase
of transition if it is used at all.
The IPv6 transition mechanisms ensures that IPv6 hosts can interoperate with IPv4 hosts
anywhere in the Internet up until the time when IPv4 addresses run out, and allows IPv6 and
IPv4 hosts within a limited scope to interoperate indefinitely after that. This feature protects
the huge investment users have made in IPv4 and ensures that IPv6 does not render IPv4
obsolete. Hosts that need only a limited connectivity range (e.g., printers) need never be
upgraded to IPv6.
The 6bone initiative
This project is actually much more important than one would think from its name, however. It
is essentially a practice ground to learn more about the use of IPv6 as well as the foster the
implementation of the new standard.
The project is a close relative of the IETF and currently spans three continents. One of the
main purposes of the project is to develop and implement a backbone (thus the name, we
suppose) that is able to support IPv6. A new protocol is not worth much if support is
unavailable. The eventual thinking is that the backbone will mimic the structure that exists
today in that it will consist of ISPs as well as other networks combined to provide a great deal
more functionality and power to the Internet.
The problem that 6bone is answering is an important one: how can we test new functionality
without placing the existing functionality at risk? The answer is that this project involves
placing a virtual network layer that exists on top of physical IPv4 network layers. The
particulars of this setup can be found at the 6bone Web site below as they are beyond the
scope of this book. It is important to note however, that as IPv6 is readily adopted and
implemented, 6bone would be eventually phased out.
6bone is interested in developing policy and procedures for the next stage of IP integration. It
is not designed to develop new network architectures or infringe upon the way in which
networking is accomplished by major players in the Internet. The project is attempting to
include as many large players as possible in order to develop policies and procedures that can
be adopted by many organizations.
It is logical to move from the RAS section to a more detailed discussion of TCP/IP. As we
have learned, there are a number of changes in store for the protocol suite that are important to
understand and be prepared for as well. These changes are not designed to make a huge lead
away from what has worked to-date. Rather these enhancements are designed to build upon
the aspects of IP that have worked and move away from those that have not.
IPv4 is a solid, routable protocol. In order for larger network environments to use this
product, they require some sort of connectivity that is usually filled by a DHCP and DNS
server. IPv6 has the potential to circumvent many of these requirements and provides the
opportunity to create a more efficient, secure networking environment.

IPv6 has been designed to enable high-performance, scalable internetworks to remain viable
well into the next century, and for that, many inadequacies of IPv4 were corrected (see figure
1.2 for an IPv6 sample of its packet). But in order to fully take advantage of IPv6
improvements you must be ready to dive into its full spectrum of benefits. Some of the
qualities of IPv6 are found in obviously enhanced features, others are less tangible and relate
to the fresh start that IPv6 provides to LAN and Internet administrators.
Figure 1.2
Sample of IPv6 packet
Addressing and Routing
IPv6 provides a framework for solving some critical problems that currently exist inside and
between enterprises, as shown on figure 1.3. IPv6 will allow Internet backbone designers to
create a highly flexible and open-ended global routing hierarchy. At the level of the Internet
backbone where major enterprises and Internet Service Provider (ISP) networks come
together, it is necessary to maintain a hierarchical addressing system, much like that of the
national and international telephone systems. Large central-office phone switches, for
instance, only need a three-digit national area code prefix to route a long-distance telephone
call to the correct local exchange. Likewise, the current IPv4 system uses a (somewhat
haphazard) form of address hierarchy to move traffic between networks attached to the
Internet backbone.
Figure 1.3
IPv6 addressing enhancements
Without an address hierarchy, backbone routers would be forced to store routing table
information on the reachability of every network in the world. Given the current number of IP
subnets in the world and the growth of the Internet, this is not feasible. With a hierarchy,
backbone routers can use IP address prefixes to determine how traffic should be routed
through the backbone. IPv4 uses a technique called Classless InterDomain Routing (CIDR),
which allows flexible use of variable-length network prefixes. With this flexible use of
prefixes, CIDR permits considerable "route aggregation" at various levels of the Internet
hierarchy, which means backbone routers can store a single routing table entry that provides
reachability to many lower-level networks.

But the availability of CIDR routing does not guarantee an efficient and scalable hierarchy. In
many cases, legacy IPv4 address assignments that originated before CIDR do not facilitate
summarization. These issues affect high-level service providers and individual end users in all
types of businesses. Figure 1.4 and 1.5 outlines some of the main features of IPv6 routing.
Figure 1.4
IPv6 addressing routing features
Figure 1.5
IPv6 routing resembles IPv4
Gateways and network address translators typically limit users in private address spaces with
non-unique addresses in their connectivity to the outside world. NAT services are meant to
allow an enterprise to have whatever internal address structure it desires, without concern for
integrating internal addresses with the global Internet. The NAT device sits on the border
between the enterprise and the Internet, converting private internal addresses to a smaller pool
of globally unique addresses that are passed to the backbone and vice.
NAT may be appropriate in some organizations, particularly if full connectivity with the
outside world is not desired. Figure 1.6 gives an example of the NAT layout. But for
enterprises that require robust interaction with the Internet, NAT devices are not always
desirable. The NAT technique of substituting address fields in each and every packet that
leaves and enters the enterprise is very demanding, and can lead to a bottleneck between the
enterprise and the Internet.
Figure 1.6
NAT allows interoperation with IPv4
A NAT may keep up with address conversion in a small network, but as Internet accesses
increases, the NAT's performance must increase in a parallel fashion. The bottleneck effect is
exacerbated by the difficulty of integrating and synchronizing multiple NAT devices within a
single enterprise. It is highly unlikely that an enterprise will achieve the reliable high-
performance Internet connectivity with NAT that is common today with multiple routers
attached to an ISP backbone in an arbitrary mesh fashion.
Another limitation of IPv4 relates to the ongoing need in many organizations to renumber
stations. When an enterprise change ISPs, it may have to either renumber all addresses to
match the new ISP-assigned prefix, or implement address translation devices. Renumbering is
also a reality for many corporations that undergo a merger or an acquisition that entails
network consolidation. Also, address shortages and routing hierarchy problems increasingly
are a threat to the network operations of larger (and to some extend small) enterprises. Smaller
networks can be completely dropped from Internet backbone routing tables if they do not
adhere to the address hierarchy. In the current system, ISPs with individual dial-in clients
cannot allocate IP numbers as freely as they wish. Consequently, many dial-in users must use
an address allocated from a pool on a temporary basis. In other cases, small dial-in sites are
forced to share a single IP address among multiple end systems.
IPv6 for Businesses
There are plenty of business issues today pushing IPv6, from protocol basics to industry
realities and demands. For once, if we look at the increasing business requirements for
interactive multimedia (IP multicasting and voice over IP included!), and high-bandwidth
network applications, IPv6 is critical to the continued viability of enterprise internetworks and
the public Internet at large. Thus, to say that IPv6 is driven by a need to expand Internet
addresses are not only simplistic, but miss all the potential behind the whole IPv6 initiative.
Figure1.7 lists some of the main reasons driving the development of IPv6, but it is not all.
Figure 1.7
Some of the main reasons driving the development of IPv6
For many, IPv6 is a proposed solution for preventing IPv4’s obsolete 32-bits address space to
run out of Network Layer addresses, as we discussed earlier in this chapter. But the Internet
Network Information Center (InterNIC), the authority that assigns blocks of IP addresses to
large network service providers and network operators, predicts that IPv4’s address format
should exhaust only around halfway into the next decade.
The fact is that IPv6 has great advantages, and impact over Ipv4. Consider this: IPv6’s space
address is jumping from Ipv4’s 32-bit format to a huge 128-bit address space. Figure 1.8 and
1.9 outlines some of the main changes in IPv6 from IPv4. This new capability alone should be
more than enough to grant unique addresses for every conceivable variety of network device
in the world for many decades to come. More precisely, its 16 bytes addressing capability can
handle a massive number of IP addresses, up to
340,282,366,920,938,463,463,374,607,431,768,211,456 addresses to be more exact.Although
a major achievement, IPv6 is also bringing many other features, as well as addressing several
issue, for good, and for bad. Thus, it’s important to be aware and understand both, advantages
and disadvantages and better understand how it impacts our business and the internetworking
environment.
Figure 1.8
Some of the main changes on IPv6 from IPv4
Figure 1.9
Additional changes on IPv6 from IPv4
The expanded IP addressing of IPv6 gets a lot of attention but it is only one of many important
features it provides. Figure 1.10 list some other new features of IPv6, but as mentioned earlier,
IPv6 also addresses important critical business requirements, as follows:
• Increased scaleability for network architectures,
• Improved security,
• Improved data integrity,
• Integrated quality-of-service (QoS),
• Autoconfiguration,
• Mobile computing features,
• Data multicasting, and
• More efficient network route aggregation at the global backbone level.
Figure 1.10
Some of IPv6 new features
Again, don’t be deceived by the long list of features outlined above. Just like everything has a
price in this world, this many benefits of IPv6 also have a price, which can be view as a
disadvantage, even though a temporary one, as it will not come without a transition effort.
Such is the challenge it presents that many in the industry defend the idea of extending the life
of IPv4 indefinitely with changes to the protocol standards and various proprietary techniques.
For instance, figure 1.11 outlines couple main challenges facing those migrating onto IPv6:
lack of a finished product and not being PnP (Plug-and-Play). Another issue is in the case of
the network address translators (NAT), which does preserves IPv4 address space by
intercepting traffic and converting private intra-enterprise addresses into globally unique
Internet addresses. The many quality-of-service and security enhancements to IPv4 also are
being extended.
Figure 1.11
Couple main challenges for early IPv6 migrators
Some professionals believe that the diversification of large applicability for IPv6 support is not
something to involve and concern business and end-users in general. But you can count on the
fact that IPv6 will connect more than computers and networks. IPv6 will make it possible to
connect many other devices, such as palmtop personal data assistants (PDA), hybrid mobile
phone embedded network components, as well as other devices and equipment that will range
from a coffee maker at your kitchen to a sprinkler at a golf course.
These factors as shown on figure 1.12, justifies and contributes to some of the main challenges
faced by IPv6 during its earlier implementation phase. Furthermore, as new devices make their
way onto the Internet, they will strain the existing network fabric in ways the early IP protocol
designers could hardly have imagined. IPv6's 128-bit address space will allow new markets to
deploy an enormous array of new applications and devices for desktop, mobile, and embedded
network with very high return of investment (ROI). Moreover, be confident that these new
trends will be lead and pushed by end-user applications. Heavily competitively networked
business environment of the new century will have to exploit all the capabilities of IPv6, not
only to create a highly scalable address space, but also to take advantage of its strong
capability of autoconfiguration services, capital for large networks.
Figure 1.12
Few causes responsible for the challenges presented to IPv6
during its earlier implementation.
Relevance of IPv6
Very soon we'll be able to use our car's on-board computer to take dictation while we're stuck
in traffic, update our schedule so that family and colleagues know where we are, and to
instruct our house to turn up the heat, and switch on the lights. That same car will
automatically run diagnostics and download the results, so when we get to the shop the needed
parts are ready and waiting. Virtually all the devices with which we interact, at home, at work,
and at play, will be connected to the Internet – the possibilities are endless, and the
implications staggering. IPv6 will make all this possible.

IPv6 is already promoting major advantages to backbone routers, enabling efficient multitiered
routing hierarchies that limit the uncontrolled growth of backbone router tables. It is also
benefiting end-users, as it enables them to run more secure Intranet environments as IPv6
offers encryption and authentication services as integral part of its IP stack. The advantages are
even greater for mobile users, always moving from one location to another with their notebook
computers (and Palmtops). It also brings major advantages for other dynamic departmental
staffs, such as team of auditors and inspectors conducting due diligence outside of their offices
as IPv6 enables the use of automatic configuration in the assignment of IP addresses. The
frustration of manually administration of IP addresses is over with IPv6, so it is the time-
consuming and costs associated with its administration.
Although the explosive growth of the World Wide Web and other, more futuristic,
technologies won't totally exhaust the capabilities of our current generation of Internet
technology until early in the next decade, there are still compelling reasons to begin adopting
IPv6 now. Essential to any evolution of Internet technology are the requirements for seamless
compatibility with current technology (IPv4), and manageable migration. Thus, it will be
possible to take advantage of the power of IPv6 now, where needed, without forcing the entire
Internet to upgrade simultaneously.
There is a misconception when considering IPv6 with reference to Asynchronous Transfer
Mode (ATM) cell switching, and other switching methods, as possible replacements for
packet routing, that needs to be clarified. I believe ATM has its place in the internetworking
industry, but cannot replace packet routing by itself. Thus, it’s not a matter of choice to have
ATM or IPv6 because the two protocols not only complement each other, but also serve
entirely different roles in corporate networking. As a matter of fact, why not use ATM as a
transmission medium for high-speed IPv6 backbone networks? This is a question that has
triggered, many standard and development work aimed on the integration of ATM and IPv6.
As discussed in more details in the chapters to come, especially on chapter 3, “IP
Superhighway,” IPv6, just like IPv4, provides Network Layer services over all major link
types, including ATM, Ethernet, Token Ring, ISDN, Frame Relay, and T1.
IPv6 Multicasting
The designs of current network technologies were based on the premise of one-to-one, or one-
to-all communications. This means that applications that are distributing information to a large
number of users must build a separate network connection from the server to each client. IPv6
provides the opportunity to build applications that make much better use of server and
network resources through its "multicasting" option. This allows an application to "broadcast"
data over the network, where only those clients receive it properly authorized to do so.
Multicast technology opens up a whole new range of potential applications, from efficient
news and financial data distribution, to video and audio distribution, etc. The possibilities are
endless!
The Conversion Challenge
While a primary design goal of IPv6 is to ease the transition from and co-existence with IPv4,
converting today's tens of millions of IPv4 based systems to IPv6 will be a major challenge.
However, IPv6's built in compatibility features will ease the pain, and options like tunneling
IPv4 packets over IPv6, and tunneling IPv6 packets over IPv4, and translation gateways will
help to make the job easier.
Many organizations are working on IPv6 drivers for the popular UNIX BSD operating
environment. Network software vendors have announced a wide range of support for IPv6 in
network applications and communication software products.
Changes to protocol systems can have profound effects on existing applications and must be
carefully implemented to minimize risk. Thus, migrating from IPv4 to IPv6 in existing
applications, or implementing IPv6 in new applications, requires considerable expertise to
ensure a smooth transition and trouble-free implementation.

Business Opportunities for IPv6
Vendors operating in the IP industry should be attentive for new opportunities in the IPv6
market, as we already anticipate market dynamics, which will lead to universal IPv6 adoption,
as discussed earlier in this chapter. In order to be successful, vendors should be looking for
product concepts, which leverage these market dynamics.
One market to tap on is the fact that IPv6 stack is incompatible with IPv4 stack. The IETF is
formalizing two approaches to the migration process: tunneling and dual stacks, which are
discussed later in this book.
Tunneling, as shown on figure 1.13, is an alternative, as it addresses the incompatibility of the
infrastructure – by enabling two IPv6 nodes to communicate over an IPv4 backbone (or vice
versa), but it does not enable an IPv4 node to communicate with an IPv6 node. But what if a
node with a dual IPv6/v4 stack, which could communicate with either IPv6 or IPv4 nodes
were available? Would dual stacks resolve the migration issues?
Figure 1.13
The transmission of IPv6 packets can be made of IPv4 via
tunneling
If so, would you install a dual stack instead of IPv4 only? Clearly this would require a
considerable investment, especially at a large site, and coordination of stacks from different
vendors would be necessary. Also, upper level protocols would need to be replaced, and a
“separate but equal” addressing and configuration scheme would need to be implemented and
supported. The question is why would you incur in these costs and risks? The possible
answers could be:
1. You may want to have some target nodes only accessible via IPv6. But why would
you do that when such a choice so severely constrains communicating nodes in your
organization?
2. Surely, many are the compelling features of IPv6. You may decide to endure the
challenges brought by IPv6 just like any Microsoft users endures the beta versions of
Windows 98 and NT 5.0: you may do it for the attributes of IPv6, such as quality-of-
service, automatic configuration, security and large address space. All to be also
available via IPv4 or have adequate IPv4 workarounds for the next decade.
This is an IPv6 constraint. I’m not sure that the advantages of dual stack installation warrant
the costs and risks,. It does, however, poses a “chicken or egg” conundrum for early IPv6
adopters.
But there is an alternative approach that may mitigate this problem. What about a device (or
scheme) that translates between IPv4 and IPv6 protocols, as shown on figure 1.14? IPv4
nodes, which need to communicate with IPv6 nodes, would not require any stack upgrades.
New sites might consider IPv6 installations without fear of incompatibility with the installed
base. IPv6 migration could proceed based on its larger address space.
Figure 1.14
Using a translation scheme to bridge IPv6 and IPv4 packets.
IPv6’s Unicast, Multicast and Anycast Addressing
IPv6’s unicast addresses identify a single interface. Packets sent to a unicast address are
delivered to the interface identified by that address. There are four types of unicast addresses:
• Provider-based, which provides global addressing to all connected hosts

• Local use, which includes link-local for addressing on a single link (physical
network) or subnetwork, and site-local designed for local use that can later be
integrated into global addressing
• IPv4 compatible, which provides compatibility between IPv4 and IPv6 until a
complete transition is attained
• Loopback, which sends an IPv6 packet to itself. These packets are not sent outside
a single node.
Multicast addresses identify a set of interfaces that usually belong to different nodes. Packets
sent to a multicast address are delivered to all interfaces identified by that address. This is
useful in several ways, such as sending discovery messages to only the machines that are
registered to receive them. A particular multicast address can be confined to a single system,
restricted to a specific site, associated with a particular network link, or distributed worldwide.
Note that IPv6 has no broadcast addresses and uses multicasting instead, as shown on Table
1.1.
Table 1.1
A multicast address allows multiple configurations, being
part of a single system, restricted to a specific site,
associated to a network link or distributed worldwide.
Bits 8 4 4 112
11111111 Flags Scope Group ID
Anycast addresses is a new introduction to IP technology with the IPv6 protocol. This kind of
address identifies a set of interfaces, usually belonging to different nodes. A packet sent to an
anycast address is delivered to one of the interfaces identified by the address. This is usually
the nearest interface, and is determined by how the router measures distance.
This makes routing more efficient, as shown on Table 1.2) because the address itself can
specify intermediate hops en route to a destination, rather than having the router determine the
route.
Table 1.2
Anycast addresses enables more efficient routing by
specifying intermediate hops en route to a destination.
Bits N 128-n
Subnet prefix 0000 0000
Address Resolution and Neighbor Discovery
In order for Internet packets to be transferred in a particular subnet on a particular media, the
notes need to know the subnet address or the media address of the target station. IPv4 relies on
the Address Resolution Protocol (ARP), but IPv6 uses what is called neighbor discovery,
which provides the same resources of ARP but also adds router discovery.
With IPv6, neighbor discovery is described in generic terms as part of IPv6 ICMP. Christian
Huitema, in his book “IPv6, The New Internet Protocol,” describes very well how IPv6 uses
multicast transmission to identify the media address of their destination. The message will
always be sent to multicast address every time the media address of the destination is
unknown. Thus, for IEEE-802, Ethernet of FDDI, the 48-bit multicast address is obtained by
concatenating a fixed 16-bit prefix, 3333, and the last 32 bits of the IPv6 multicast address.
Xerox reserved this prefix for use with IPv6, as shown on figure 1.15.
Figure 1.15
Mapping of a multicast address in IEEE-802 networks.
RFC 1970, “Neighbor Discovery for IP Version 6 (IPv6),” specifies the standards track
protocol for the Internet community. As mentioned earlier, nodes and hosts do need a
mechanism to determine the address of a target note or host. Neighbor Discovery enables it by
a link-layer address process, for neighbors known to reside on attached links. Neighbor
Discovery is also used by hosts to find neighboring routers that are willing to forward packets
on their behalf. It also actively keep track of which neighbors are reachable and which are not,
and to detect changed link-layer addresses. When a router or the path to a router fails, a host
actively searches for functioning alternates.
*****Start TIP*****
For more details about the parameters of this specification check the RFC 1970 at
http://playground.sun.com/pub/ipng/html/ipng-main.html .
*****End TIP*****
Besides solving many problems related to the interaction of nodes attached to a same link it
also defines mechanisms for resolving few other specific problems:
• Router Discovery, resolving how hosts locate routers residing on attached links.
• Prefix Discovery, resolving how hosts discover the set of address prefixes that
define which destinations are on-link for an attached link.
• Parameter Discovery, solving how a node learns the necessary link parameters,
such as the link MTU or Internet parameters, such as the hop limit value to place in
outgoing packets.
• Address Autoconfiguration, solving how nodes automatically configure an address
for an interface.
• Address resolution, resolves how nodes determine the link-layer address of an on-
link destination, such as a neighbor, given only the destination's IP address.

• Next-hop determination, is the algorithm used for mapping an IP destination
address into the IP address of the neighbor to which traffic for the destination
should be sent. The next-hop can be a router or the destination itself.
• Neighbor Unreachability Detection, defines how nodes will determine if a
neighbor is no longer reachable. If neighbors nodes are used as routers, alternate
default routers can be tried, but in the case of both routers and hosts, address
resolution can be performed again.
• Duplicate Address Detection resolves how a node determines if the address it
wants to use is already in use by another node or not.
• Redirect, defines how a router informs a host of a better first-hop node to reach a
particular destination.
• Neighbor Discovery defines five different ICMP packet types:
• A pair of Router Solicitation and
• Router Advertisement messages,
• A pair of Neighbor Solicitation and
• Neighbor Advertisements messages,
• A Redirect message.
The messages serve the following purpose:
• Router Solicitation: When an interface becomes enabled, hosts may send out
Router Solicitations that request routers to generate Router Advertisements
immediately rather than at their next scheduled time.
• Router Advertisement: Routers advertise their presence together with various link
and Internet parameters either periodically, or in response to a Router Solicitation
message. Router Advertisements contain prefixes that are used for on-link
determination and/or address configuration, a suggested hop limit value, etc.
• Neighbor Solicitation: Sent by a node to determine the link-layer address of a
neighbor, or to verify that a neighbor is still reachable via a cached link-layer
address. Neighbor Solicitations are also used for Duplicate Address Detection.
• Neighbor Advertisement: A response to a Neighbor Solicitation message. A node
may also send unsolicited Neighbor Advertisements to announce a link-layer
address change.
• Redirect: Used by routers to inform hosts of a better first hop for a destination.
On multicast-capable links, each router is capable to periodically multicast a Router
Advertisement packet to announce its availability. In order to keep track of available routers, a
host receives Router Advertisements from all routers, building a list of default routers. These
Router Advertisements are frequently generated, so those hosts can always be updated about
their presence every few minute. However, hosts don’t receive enough announcements from
the routers to the point of relying on an absence of advertisements to detect router failure. For
that, a separate Neighbor Unreachability Detection algorithm provides failure detection.
IPv6’s Multimedia Features
IPv6 incorporates a variety of functions that make it possible to use the Internet to deliver
video and other real-time data that require guaranteed bandwidth and latency to insure that
packets arrive on a regular basis.
IPv6’s Multicasting
IPv6 mandates support for multicast, a function that delivers messages to all hosts that register
to receive it. This function makes it possible to deliver data simultaneously to large numbers
of users for public or private consumption without wasting bandwidth broadcasting to the
entire network. IPv6 also includes facilities to limit the scope of multicast message distribution
to a specific location, region, company or other criteria, thereby reducing bandwidth usage and
providing security.
Bandwidth Reservations
Using the mandated RSVP functionality, users can reserve bandwidth along the route from
source to destination. This makes it possible to provide video or other real-time data with a
guaranteed quality of service.
Packet Prioritizing
Packets will be assigned a priority level, insuring that lower priority packets do not interrupt
real-time data flow.
Jumbograms
IPv6 will support packet sizes of up to 4 billion bytes. This will make the transmission of large
packets easier and insure that IPv6 will be able to make the best use of all available bandwidth
over any transmission media.

IPv6’s Plug-and-Play Features
Currently, users or network managers must manually configure each machine with its address
and other network information. This is a confusing, error-prone task for many individual users
and a time consuming chore for network managers. It also requires that to change network
addresses, every machine must be manually reconfigured. IPv6 solves these problems by
including mechanisms to allow hosts to discover their own addresses and to automate address
changes.
Address Discovery
IPv6 allows hosts to learn their own address from a local router during boot-up, eliminating
the need to manually configure addresses on each host. IPv6 also specifies procedures for a
host to allocate an address for local site communications and for small sites without routers.
Network Information Discovery
IPv6 mandates support for Dynamic Host Configuration Protocol (DHCP) which allows the
host to obtain all relevant network information from a local router during boot-up.
Automated Address Changes
Because the router in IPv6 distributes network addresses, changing the address of the network
requires only updating the router. In addition, all addresses include lifetimes, enabling the
router to specify a time to switch addresses, insuring a smooth, error-free transition to a new
address.
Support for Mobile Hosts
IPv6 will incorporate algorithms to automatically forward packets from a base address to any
other address. This will allow users connected to the Internet from any location, even mobile
phones, to seamlessly receive their messages.
Dead Neighbor Detection
IPv6 specifies dead neighbor and dead gateway detection algorithms insuring that all
implementations of IPv6 are able to efficiently detect problems and reroute packets when
necessary.
IPv6 also enables applications to specify how to treat unknown options. This provides IPv6
with the flexibility to add new options in the future without necessitating those existing
implementations all be updated to conform.

Control Over Routing
As opposed to the capability to choose only loose (automatically determined) or strict (user
specified) routing for the entire path in IPv4, in IPv6 users can specify loose or strict routing
for each hop along the path. IPv6 also includes the flexibility to include additional routing
methods in the future.
Configurability of features
The IPv6 protocol for hosts and routers to discover neighboring machines is called neighbor
discovery. IPv6 allows all the features of neighbor discovery such as retries and time-out
parameters to be locally configured. This provides increased flexibility as well as the
capability to optimize neighbor discovery for the needs and constraints of each individual
network.
IPv6 Performance Considerations
Network performance is directly related to routing. The amount of traffic that leaves the local
network (external traffic) compared to the amount of traffic that occurs on the network is
constantly increasing. This is due in part to the demand for more services, especially graphics
based services. Speeds for LANs and WANs have also increased to hundreds of megabits per
second, with gigabit networks not far in the future. Routers need to perform their functions of
processing and forwarding IP datagrams much quicker than before.
There are fewer fields in an IPv6 packet header than in IPv4. To increase the speed, at which a
packet travels past a router, separate optional headers are placed between the IPv6 header and
the transport layer header. Most of these are not examined or processed by routers along the
packet’s path, which simplifies and speeds up router processing. Additional optional headers
are also easier to add, making IPv6 more flexible than IPv4. Because the IPv6 packet header
has a fixed length, processing is also simplified.
IPv6 does not fragment packets as they are routed as IPv4 does. Instead, packet fragmentation
and reassembly will be done exclusively in the communicating hosts, thus reducing the
workload for intermediate routers. When the transition to IPv6 is complete, the Internet will
consist of only networks with Maximum Transmission Units (MTUs) equal to or larger than
576 bytes.
Performance with IPv6 will be optimized by the use of flow labels. The flow source specifies
in the label any special service requirements from routers along a path, such as priority, delay,
or bandwidth. All packets in the sequence carry the same details of this information in the
flow label to reserve the type of service they need from intermediate routers. Such a need
would be for transmitting video, or limiting traffic a specific computer or application sends to
avoid congestion.
With IPv6, a flow can be one or multiple TCP connections, and a single application could
generate a single flow or multiple flows. An example of a single flow would be a text page,
and an example of a multiple flow would be an audio/visual conference.
Packets that share a flow label also share path, resource allocation, discard requirements,
accounting, and security attributes. The flow label is defined before transmission.
Using Virtual LANs with IPv6
Virtual LAN (VLAN) is an integral feature of switched LANs. To understand and define
VLANs, think of it as a group of workstations on multiple LAN segments communicating
with each other as if they were on a single LAN. An example of it is Microsoft’s technical
support. Part of Microsoft’s technical support is outsourced to other companies all over the
country. For security and confidentially issues, these company’s technicians are part of
individual domains, trusted by Microsoft’s primary domain so they can access the technical
support database at Microsoft. Although being based on different cities all over the world,
these ‘foreign’ domains and users all become part on a single network.
But let’s take a look at what kind of LANs we have available and how VLANs and IPv6 can
bring value-added benefits to the corporation

Router-based LANs
As router-based LANs are being replaced by switched LANs, Virtual LANs (VLANs) are
becoming an important network management tool. VLANs are being deployed for traffic and
bandwidth management in layer 2 switched networks.
The problem with router based LANs, as shown on figure 1.16, is that they suffer from
bandwidth and latency problems, thus being replaced by switched LANs. But simple switches
leave a vacuum regarding network control and traffic management functionality, which is
necessary to operate our networks. Virtual LANs (VLANs) provide efficient tools for
controlling traffic and network management, which are making them an important component
ad solution for today’s complex and faster networks.
Figure 1.16
Typical problem faced by “real LANs: collisions.
Typical problems with router based LANs are few. On a 802-type LAN, for example, a shared
medium network always requires all nodes to share the bandwidth of the physical link,
limiting effective utilization of the physical link. Thus, it is common for a Ethernet-based
LAN to achieve only 30%-40% efficiency, since all nodes were in a single collision domain.
Switched-based LANs
In a switching-based architecture (Packet Buffering Memory), a switched port is dedicated to
every node on the LAN. Each node has it’s own wire and all bandwidth is dedicated to the
node, which eliminate the need for sharing it with all other nodes on the same LAN, is with
the router-based model. Since each node is in it’s own collision domain, as shown on figure
1.17, Ethernet efficiencies can achieve more than 95%, promoting almost a collision-free
LAN.
Figure 1.17
Switched-based LANs promote a almost collision free network.
This Ethernet efficiency is possible because a usable bandwidth within a switched LAN is
determined. A switched port is only allowed to receive:
• Unicast traffic addressed to the node
• Broadcast traffic within the LAN, and
• Multicast traffic within the LAN

Therefore, the volume of unnecessary broadcasts and multicasts the node receives limits this
usable bandwidth to a node in a switched port.
Understanding Virtual LANs
Virtual LANs (VLANS), as exemplified on the Microsoft’s example above, are flexible,
location/topology independent group of stations communicating as if on a common physical
LAN, as shown on figure 1.18.
Figure 1.18
A VLAN connects LANs and nodes independently of their
location and/or topology.
The network fabric makes sure that all nodes within the VLAN are communicating within a
common broadcast domain transparently without node’a awareness. Figure 1.19 shows the list
of components of a VLAN.
Figure 1.19
VLAN’s components.
VLANs provide a series of benefits to a switched environment, including:
• Walks away of the typical Ethernets LANs, characterized by a single collision and
broadcast domain
• Resolves the problem of eliminating one broadcast domain, which bridges were
not able to resolve when breaking up Ethernet LANs into multiple collision
domains
• Allowed for a cheap, inexpensive and fast solution for the job routers do in
breaking up Ethernet into multiple collision domains, and containing broadcasts
within each domain
• Enabled switches to break Ethernet into multiple collision domains and use it
(VLANs) to contain broadcasts within each domain in a fast, cheap and simple
way.
The VLAN Bridge, which implements Virtual LAN, provides the following benefits.
• Broadcast containment
• Security
• Easy administration
When using VLANs for broadcast containment, as depicted by figure 1.20, you can limit
broadcast domain sizes:
• IP-based up to 1000 nodes per VLAN
• IPX-based up to 500 nodes per VLAN
• AppleTalk-based up to 200 nodes per VLAN, and
• Isolation of chatty protocols
Figure 1.20
Using VLAN to contain broadcasts.
IP Multicast traffic, as shown on figure 1.21, can easily flood switched networks and VLANs
can be a the best, if not the only effective solution for resolving the ever increasing demand on
multicasting applications such as:

• Video training
• Video conferencing
• Stock ticker & news feeds
• Medical critical care, etc.
Figure 1.21
VLAN addresses the ever-increasing traffic of IP
multicasting.
VLANs can also resolve uncontrolled proliferating IP multicasting traffic, as shown on figure
1.22, by containing it:
• Having switches using IGMP to snoop and determine which systems want to see a
multicast
• Automatically creating a Autocast VLAN based upon the IGMP snooping
• Allowing multicast to only go to ports that joined the multicast group/VLAN

Figure 1.22
VLAN can be effective use to contain the proliferation of IP
multicasting.
There are many different kinds of Virtual LANs, as listed below:
• Port based VLAN, as shown on figure 1.23
• MAC address based VLAN, as shown on figure 1.24
• Protocol based VLAN, as shown on figure 1.25 and 1.26
• IP Subnet based VLAN
• IP Multicast based VLAN
• ELAN based VLAN
• Policy based VLAN
Figure 1.23
A typical example of a Port-based VLANs: Source: 3Com, Steve
Jumonville presentation.
Figure 1.24
A typical example of a MAC address-based VLANs: Source:
3Com, Steve Jumonville presentation.
Figure 1.25
A typical example of a Protocol-based VLANs: Source: 3Com,
Steve Jumonville presentation.
Figure 1.26
A Protocol-based VLAN enables different protocols to be
grouped together, eliminating broadcasted packets not
addressed to other protocols to circulate to all machines.

What’s Next
This chapter discussed some of the main limitations of IPv4 as well as a brief comparison
between IPv4 and IPv6 addressing. Next chapter, “Understanding RSVP, IP Multicast and
ATMs,” provides you with the fundamentals of RSVP, IP Multicast and an overview of ATM,
which are important technologies in carrying voice over IP.

Chapter 2
Understanding RSVP, IP Multicasting
and ATMs
The Resource Reservation Protocol (RSVP) is the reservation protocol of choice on the
Internet. Multicast applications, such as high-speed video transmission, which will definitely
depend on a protocol like RSVP in order to guarantee high levels of what is called "Quality of
Service" (QoS), voice over IP (VoIP) and many other multimedia applications all rely on
RSVP. Many of these new applications require a different approach to routing and resource
allocation than do generic data applications. RSVP is different from many IP protocols
because it is a receiver-driven protocol. Thus, it is up to the receiver to select which source

they want to receive as well as the amount of bandwidth they are prepared to reserve or pay
for, assuming they are in a commercial network.
Following the trend, Quality of Service (QoS) requirements has increased considerable with
the advent of multimedia applications. The reason for it is that multimedia applications require
reliable and fast transmissions, otherwise, what the recipient will get can be a bunch of
“chopped” and delayed set of packets, caused by the way lower level protocols, such as
Ethernet, ATM and Token Ring, handle packets to IP, forwarding them to their destinations,
which are prone for delays or “bursts” in the packet delivered. This can happen to all routed
IP network, because every router in the data path examines each packet of information.
Usually you will find several intermediate routers between the source and the destination,
joining the different networks. As the packet "hops" from one router to another, the IP
protocol in each router decides which is the fast path for that packet to go next, which can
easily delay the arrival of a packet at its destination, and many times the packet will never
make it.
For most data applications, this "bursty" delivery is acceptable and lends itself to high
performance and high availability, but for multimedia applications, involving both voice
and/or video, the traffic must have to be "streamed" or transmitted continuously, and not in
bursts. The challenge for the networking community is to accommodate these different
requirements while continuing to maintain high network performance and availability.

It was to meet this challenge that IETF developed the Resource ReserVation Protocol (RSVP).
RSVP is an end-to-end protocol compatible with current TCP/IP based networks, capable to
provide the means to support a special Quality of Service for multimedia applications and
others that needs it, while maintaining current internetworking methods, preserving, therefore,
the existing network infrastructures.
Understanding RSVP
The RSVP protocol operates on top of IP, in the transport layer. It is a control protocol
comparable to ICMP (Internet Control Message Protocol) or IGMP (Internet Gateway
Message Protocol) designed to operate with the current and future unicast and multicast
routing protocols. Some applications are suited for one Receiver while it is desirable with
other applications to have the potential to send to more than one Receiver without having to
broadcast to the entire network.
The components of RSVP are:
• Sender – responsible for letting the Receiver know there is data to be sent and
what Quality of Service is needed.
• Receiver – responsible for sending out a notice to Hosts or Routers so they can
prepare for the upcoming data

• Hosts or Routers – responsible for setting aside all the proper resources.
Once all the above steps are completed, the Sender can successfully send the data.
RSVP, if completely implemented, is intended to provide QoS over any media, even if the
media itself provides none. But RSVP allows only a much less granular, more generic QoS
guarantee. The present definition of RSVP includes a number of stations, all connected to a
switch that handles local traffic, which in turn is connected to a router, which provides WAN
access. The RSVP definition is concerned primarily with the router, which means that when
one router wants to talk to another, RSVP can request a certain quantity of bandwidth. But the
Internet allows connections over various types of routers, most of which don’t support RSVP.
Further, RSVP does not yet apply to the station or the switch, meaning that an Ethernet card
doesn’t know anything about QoS, or limiting packet release to assure that it doesn’t go over
its allocation. These things have to be done in software via packet schedulers. There is no plan
or infrastructure for putting RSVP on the switch. With ATM, every component in the line is
ATM-based, so it can provide absolute guarantees. Besides, RSVP doesn’t provide a
mechanism for tracking and billing for quality of service either, which is a major concern for
carriers. Tracking and billing are easily done using ATM.

With RSVP, the application is able to provide advanced notification about the network
resources it will need. By granting the reservation, the affected hosts and routers commit to
providing these resources. If the router is not capable of providing them, or the resources are
not available, the host or router can refuse the reservation. The application is notified right
away that the network cannot support it, thereby avoiding the time and cost of a trial and error
approach.
The two main concepts of the RSVP protocol are:
• Flows, characterized by the traffic streams from a Sender to one or more
Receivers, are identified in the IPv6 header by a "flow label." Prior to sending out a
flow, the Sender transmits a "path message" destined for the Receiver. The
message contains the source IP address, destination IP address and a flowspec. The
flowspec, made up of the rate and delay bounds for the flow, is the Quality of
Service that the flow requires. The path message is routed to the Receiver by the
hosts and routers along the flow's path.
• Reservations - The Receiver is provided with the path message and is then
responsible for making the actual reservation. With the Receiver making the
reservation, there is greater flexibility in handling multicast flows. This Receiver-

based model allows for a distributed solution enabling heterogeneous Receivers to
make reservations tailored to their needs.
Receiver-based protocol is more effective for heterogeneous networking environments. Also,
in order to assure reservations are still in place and that any "moves or changes" on the
network are aware of the reservation, RSVP incorporates an approach called "soft state." This
term is used because RSVP paths and reservations are considered tentative. Resources are put
aside when a router accepts a reservation, but if a flow is not received, it will time out and free
up its resources. With the soft state approach, the Sender periodically sends its path message
and the Receiver continues to send its reservation request in order to refresh any time-outs or
changes that may have occurred.
In summary, below is a list of RSVP features:
• RSVP makes resource reservations for unicast and multicast Receivers using a soft
state approach for keeping the reservations up-to-date.
• RSVP is uni-directional.
• Receivers in RSVP initiate and maintain the resource reservation for a flow.
• RSVP is not a routing protocol, but relies upon routing protocols for delivering
flows.
• RSVP supports IPV4 and IPV6.
The RSVP area is developing very quickly, counting with efforts making on the standards.
Cisco is at the moment the major player promoting RSVP, working very closely with the IETF
to resolve its known limitations. You can count on RSVP becoming a requirement for
multimedia applications and router manufacturers in 1998.
IP Multicasting
Traditional Internet applications usually operate between a sender and a receiver. But
emerging technologies enables a sender to communicate to a group of receivers
simultaneously, such as audio/visual broadcasted messages sent to a group of users, live
transmission of multimedia training, transmission over networks of live TV or radio news and
so forth.
Such applications unfortunately very often generate bottlenecks on the network, as it
tremendously increases the traffic and the overhead on the network, as illustrated on figure
2.1. The proposed solution for this problem has been IP Multicast, which is an extension of IP
standard-based solution with broad industry support. IP Multicast, which has been under
development since the early 90’s, represents an important advance in IP networking.
Figure 2.1
Broadcast messages sent over a network generates bottlenecks and poor performance
In the IP multicast scheme, each individual multicast group can be identified by a particular
class D IP address, as shown on Table 2.1. Each host can register itself as a member of
selected multicast groups through use of the Internet Group Management Protocol (IGMP).
Thus, a whole group of recipients, members of this multicast group session, are able to receive
the message, which is only broadcasted to the members of the group. Thus, only this group
will benefit from this message and be affected by the traffic it generates on the network.
The remain users on the network won’t even take a notice of it as IP multicast technologies
address the needed mechanisms at different levels in the network and internetworking
infrastructure to efficiently handle group communications. This scenario can be visualized by
figure 2.2, where only one copy of the same data (D) is “multicasted” to Receivers 1, 2, and 3
in a shared conferencing application. If you compare figure 2.1 with 2.2 you will note the
bandwidth savings, both locally and across the networks.

The set of hosts listening to a particular IP multicast address is called a host group. A host
group can span multiple networks. Membership in a group is dynamic - hosts may join and
leave host groups, as shown on Table 2.1
Table 2.1 - List of common multicast addresses
Well-Known Purpose
Class D Address
224.0.0.1 All hosts on a subnet
224.0.0.2 All routers on a subnet
224.0.0.4 All DVMRP routers
224.0.0.5 All MOSPF routers
224.0.0.9 RIP Version 2
224.0.1.1 Network Time Protocol
(NTP)
224.0.1.2 SGI Dogfight
224.0.1.7 Audio news
224.0.1.11 IETF audio
224.0.1.12 IETF video

Figure 2.2
IP multicasting only delivers its contents to members of multicast session
IP Multicast Benefits
One of the immediate benefits of IP multicast is the cost saving in network and server
resources. But the technology also enables a large amount of new applications that were not
available for unicasting transport.
Also, with IP multicasting, network administrators can manage network growth and control
costs much more efficiently, as IP multicast is much more cost-effective than the other
alternatives usually deployed for increasing LAN and WAN capabilities and bandwidth. Thus,
IP multicast can readily help you increment network response time, as it can immediately help
alleviate network congestion caused by existing applications that are inefficiently transmitting
to groups of recipients, and take advantage of the many applications already in place.
Another great attribute of IP multicast is its scaleabiltiy, which enables it to be scaled as the
number of participants and collaborations expand. Adding one or few more users will not
amount to adding a corresponding amount of bandwidth. Multicasting also results in a greatly
reduced load on the sending server, which no longer has to support many sequential or
concurrent unicast sessions, and it’s fully compatible with new IP protocols and services, such
as Quality of Service requests to support real-time multimedia.
Using IP Multicast
According to Stardust Forums (http://www.stardust.com), which manage the IP Multicast
initiative, Intel Corp. deployed IP Multicast on a 4,000-node Oregon site in early 1996. Intel
employees regularly use IP Multicast conferencing software to follow events such as
conferences or executive presentations and product launches from their desktops. Toys R Us
Inc. is another example giving by Stardust, indicating their use of IP Multicast file transfer
software to send software updates to 900 store locations. Before using IP Multicast, the files
had to be sent over its VSAT (very small aperture terminal) nationwide network one file at a
time. Because this used up so much bandwidth, it had to be performed at night. The IP
Multicast-based software is designed to improve product availability in the stores. A Toys R
Us representative believes the system paid for itself immediately.
IP multicast technology is very important for the growth of voice over IP (VoIP) applications,
as the demand for audio, video and data streams over a network is growing very fast.
Applications such as desktop video and audio conferencing, collaborative engineering, shared
white boards, transmission of university lectures to a remote audience, and animated
simulations are becoming a necessity in some industries and environments. In a very near
future, the transmission of a corporate presentation via computer to thousands of workers
seating at their desks within a company will become reality, through the use of IP multicast.
Unicast transmission would never be able to perform such a task.
Stored data streams, such as for the updates of kiosks and web caches, video server to video
server updates, corporate announcements to employees, etc., also will depend upon IP
Multicast to be successfully deployed and delivered.
Multicast routers to keep track of group membership on each of the router’s physically
attached networks use IGMP (Internet Group Management Protocol) messages. The following
rules apply:
0 A host sends an IGMP report when the first process joins a group. If multiple
processes on a given host join the same group, only one report is sent, the first time a
process joins the group. This report is sent out on the same interface on which the
process joined the group.
1 A host does not send a report when processes leave a group, even when the last
process leaves a group. The host knows that there are no members in a given group,
so when it receives the next query, it won't report the group.
2 A multicast router sends an IGMP query at regular intervals to see if any hosts still
have processes belonging to any groups. The router must send one query out on each
interface. The group address in the query is 0 since the router expects one response
from a host for every group that contains one or more members on the host.
3 A host responds to an IGMP query by sending one IGMP report for each group that
still contains at least one process.
Using these queries and reports, multicast router keeps a table of which of its interfaces have
one or more hosts in a multicast group. When the router receives a multicast datagram to
forward, it forwards the datagram (using the corresponding multicast link layer address) out
only the interfaces that still have hosts with processes belonging to that group.
*****Start TIP*****
For additional, and more in-depth information about IP multicasting, please refer to my book
co-authored with Kitty Niles, entitled “IP Multicasting: Concepts and Applications,” also
published by McGraw-Hill.
*****End TIP*****
An Overview of Asynchronous Transfer Mode
Technology
Asynchronous Transfer Mode (ATM) technology is playing a major role in the development
of Workgroups applications, as well as university and enterprise networks, by providing
scalable bandwidths, higher performance and Quality of Service (QoS) to LAN and WAN
networks, enabling multimedia applications, such as voice and video over IP. But, as figure
2.3 describes, first-things-first.
Figure 2.3
ATM Fundamentals
ATM is the transport protocol selected for the broadband integrated services digital network
(B-ISDN). ATM combines characteristics of circuit switched networks (e.g., the telephone
network) and packet switched networks (e.g., the Internet) to yield a network capable of
supporting digital data, voice, and video for synchronous and asynchronous delivery.
International standards bodies, technology groups, and Fora are defining B-ISDN and ATM.
Contributors to the definition of B-ISDN and ATM include equipment manufacturers, service
providers, government agencies, universities, and user entities.
The ATM Forum is generally perceived as the core technical body with respect to ATM
standards and technical definition, as outlined on figure 2.4. It is more appropriate to define
the ATM Forum as the body, which coordinates the interoperability and adoption of ATM
between existing standards bodies and Fora. In fact the ATM Forum does NOT produce
ATM standards - the ITU-T is the organization, which produces international standards
(recommendations), as depicted on figure 2.5. The ATM Forum works closely with groups
such as the Frame Relay Forum and the Digital Audio Video Council, to promote
interoperation with accepted and emerging digital communications technologies.
Figure 2.4
ATM standard bodies and Fora
Figure 2.5
The ITU-T Standards

Since the ATM Forum is in place to accelerate the implementation and acceptance of ATM, it
does not generate international standards. Standards related to broadband ISDN and ATM (B-
ISDN’s transport method) are defined in the international telecommunications union - namely,
the ITU-T group (formerly the CCITT). Digital transmission standards are included in the G-
series recommendations - SDH specifications are included here (SONET is the ANSI standard
defined in the US). ISDN and B-ISDN standards are included in the I-series
recommendations - these include the ATM and AAL specifications. The Q-series
recommendations comprise ISDN and B-ISDN signaling standards.
*****Start TIP*****
The recently overhauled ATM Forum web site, as shown on figure 2.6, gives all interested in
ATM the opportunity to track progress of ATM standards and activities. In addition, all
COMPLETED technical specifications may be downloaded from this site - FREE of charge.
Point your browser to http://www.atmforum.com.
*****End TIP*****
Figure 2.6
The ATM Forum website.

The current technical working groups in the ATM Forum are listed in figure 2.7. The status of
specification development in these groups is included at the ATM Forum web site under
technical specifications.
Figure 2.7
Current technical working groups in the ATM Forum
ATM Technical Specifications
The ATM forum technical working groups create technical specifications in the general areas
specified in figure 2.8. Physical layer specifications include 25.6 Mbps over UTP, 155 Mbps
over multimode fiber, 51 Mbps over plastic optical fiber, and others. Testing specifications
are generally in the form of Pics Proforma - giving equipment providers a guideline for testing
their implementations. Management specification address network management issues for
private network, public network, and public-private network interfaces.

Figure 2.8
ATM technical specifications
Private and public network interface specifications include the user to network interface
(UNI), the private network-to-network interface, and the broadband inter-carrier interface.
ATM service specifications include LAN emulation, multi-protocol over ATM, voice
telephony over ATM, ATM application programming interfaces, and others.
ATM is compatible with existing physical networks such as twisted pair, coax and fiber
optics, because it isn’t design-limited to a specific type of physical transport. To its advantage,
unlike conventional LANs, ATM has no inherent speed limit. In contrast, when Ethernet
speed was increased from ten to 100 megabits per second, its architecture required a reduction
in the length of Ethernet segments from 2,500 meters to 250 meters. Similarly, Token Ring
has gating factors on its speed. But with ATM, there’s nothing in the architecture that limits
speed. An ATM network can operate as fast as a physical layer can be made to run.
Furthermore, while 100-megabit Ethernet and other high speed networks can provide
comparable bandwidth, only ATM can provide the QoS guarantees required for confidently
deploying real-time telephony, video streaming, smooth videoconferencing, and other no-
delay voice and video applications. QoS is so vital to the deployment of multimedia
applications over IP that a number of initiatives are underway to provide QoS support for
TCP/IP based networks, including the RSVP protocol specification discussed earlier in this
chapter.
Private and public interface specifications include public and private UNI, P-NNI, and B-ICI,
as shown on figure 2.9. The user to network (UNI) document specifies how a user maintains
connections to a private of public ATM network. The private network-to-network (P-NNI)
document specifies how a private ATM network node signals connections through the
network and maintains a routing hierarchy between ATM network nodes. The broadband
inter-carrier interface (B-ICI) document specifies how public network edge node signal and
share information with other public networks.
Figure 2.9
ATM’s interface specifications
ATM’s Mission: the Delivery of Multimedia Services
ATM is simply the transport mechanism chosen for the broadband ISDN network. The goal is
to offer data, voice, and video services. Services imply end-to-end application connections,
which transfer digital information, namely IP data, voice, and video, as depicted on figure
2.10.
Figure 2.10
ATM’s service specifications
For example, the LAN emulation and multiprotocol over ATM services enable transfer of data
traffic over an ATM infrastructure. Voice and telephony over ATM enable use of an ATM
infrastructure for transmitting real-time voice. The MPEG over ATM function allows for
transfer if encoded digital video over the ATM network.
*****Start NOTE*****
Have you heard about the Anchorage Accord? This is an attempt to ease fears that ATM
specifications and addenda were preventing vendors from reasonably building interoperable,
and backward compatible ATM solutions, as shown on figure 2.11. To that end, The ATM
Forum penned an agreement, which includes a large set of specifications, which together
constitute the foundation guidelines for building an ATM system.

*****End NOTE*****
ATM Network Design and Solutions
ATM network design and solution requires you to address few important components, as
shown on figure 2.11:
0 Review of the ATM Data Model
1 Mapping your solutions to hardware and software
2 Introduce legacy network designs
3 Migration and upgrade strategies to ATM solutions
Figure 2.11
ATM’s network design and solutions

ATM Network Client Models
Figure 2.12 provides a list of ATM network client devices. But note that this is not an
exhaustive list of client devices. There are other ATM attached devices that perform
adaptation such as the cells in frames attachment device (CIF-AD), which works in concert
with Ethernet clients to provide an ATM over Ethernet function, which will be discussed in
more details later on this chapter. An ATM concentrator is an example of an ATM-attached
device that performs no adaptation (ATM WG switches are used in place of these devices
today).
Figure 2.12
ATM network client devices
Figure 2.13 indicates the types of devices that support client and server software function
associated with ATM data protocols. Figure 2.14 is a rundown of the many protocols
supported by ATM technologies, which includes but are not limited to:
0 ARIS aggregate route-based IP switching (IBM)
1 ARP address resolution protocol
2 BUS broadcast and unknown server

3 CIP classical IP
4 GSMP general switch management protocol (Ipsilon)
5 IFMP Ipsilon Flow Management Protocol
6 LEC LAN emulation client
7 LECS LAN emulation configuration server
8 LES LAN emulation server
9 MARS multicast address resolution server
10 MPOA multi-protocol over ATM
11 NHRP next hop resolution protocol
12 TDP tag distribution protocol (Cisco)
13 UNI user to network interface
Note that CIP, LANE, and MPOA follow a client server model where the ATM network
provides ARP, multicast, and routing services. RFC 1483 is not a protocol - but an
encapsulation method. ATM network provides only signaling (via GSMP) for IP switching
clients.
Figure 2.13
Mapping solutions to products
Figure 2.14
ATM’s protocol support
ATM’s VLAN Model
In the VLAN model, as depicted on figure 2.15 and outlined on figure 2.16, clients are
members of VLANs.
Figure 2.15
ATM’s network model: VLAN
Figure 2.16
Characteristics of a VLAN model

The VLAN model, as depicted on figure 2.16, topologically is simpler than a routed model
because there are no intermediate devices between the LAN access and the backbone.
VLANs allow for building non-geographically dependent LANs.
ATM LANE is an ATM-based VLAN solution. This is a good solution for networks, which
are currently, bridged networks. LANE may prove to be inefficient if there is too much inter-
VLAN (emulated LAN) communications - since all inter-VLAN traffic must travel through a
router. A future LANE version is slated to incorporate cut-through, inter-VLAN
communications.
ATM MPOA is another ATM-based VLAN solution. Actually, LANE is a subset of MPOA -
MPOA with no routing services is LANE. MPOA adds cut-through routing between LANE
VLANs. Cut-through in this case means that the MPOA clients can establish connections
with other clients on different emulated LANs (by learning the route from the MPOA route
service).
In a VLAN model, members of the same VLAN (emulated LAN) can establish connections
amongst themselves directly by the very nature of the LANE protocol (members of the same
ELAN are associated with the same LANE servers), as shown on figure 2.17.
Communication between VLANs requires routing services. Routing services are either
provided by an one-armed router (LANE) or by MPOA route services. Basically, MPOA
route services provides cut-through relief for LANE inter-VLAN traffic by forwarding routing
information to clients. With this routing information clients are able to establish direct
connections with other clients associated with different VLANs.
Figure 2.17
Cut-through in a VLAN model
An interesting note is that even though LAN Emulation requires an one-armed router for inter-
ELAN communications, if such traffic is limited a single one-armed router is sufficient. The
implication is that one could guarantee a single (1) router hop for inter-ELAN communication
- so why bother with cut-through if you are only avoiding a single router hop for minimal
traffic.
ATM’s Routed Model
In the routed model, as shown on figure 2.18 and outlined on figure 2.19, clients are members
of subnets. Routed models use layer 3 networking concepts to build multicast domains - that
is, subnets. RFC1483 encapsulation allows for adding capacity to an existing routed network
by adding ATM links between routers and establishing (a mesh of) PVC’s over these links.
Figure 2.18
ATM’s routed model
Figure 2.19
Characteristics of ATM’s routed model
IP switching adds ATM switching to a routed backbone and also brings dynamic cut-through.
Dynamic cut-through in a routed backbone means that the IP switching protocol automatically
establishes a path through the ATM switching cloud and between the ingress and egress
routers - avoiding hopping through intermediate routers
In figure 2.20, a hop-by-hop routing path has been established through routing configuration
(say an OSPF path). This path is associated with communications between subnet x and
subnet y. IP switching (or MPLS) establishes another more direct path which bypasses
intermediate routers - a cut-through path.
Figure 2.20
Cut-through in a routed model

IP switching protocols differ mainly in how and when the decision is made to establish a cut-
through path. Ipsilon and many partners currently ship a solution like this. Other proposed
solutions include Cisco’s Tag switching and IBM’s Aggregate route-based IP switching
(ARIS).
In summary, LANE, MPOA, and IP switching all include methods for establishing edge-to-
edge connections through the ATM network. Since this is the case, the performance through
the ATM network is identical regardless of the protocol (once a cut-through path is
established). Thus, one can implement the edge strategy that most well suits the desired
network behavior whether that is router-based or VLAN-based (and get the same benefits of
cut-through). Figure 2.21 provides a summary of ATM’s network services characteristics and
figure 2.22 a brief outline of ATM switch testing procedures..
Figure 2.21
ATM network services summary
Figure 2.22
ATM testing procedures

ATM’s Connection-Oriented
To better appreciate connection-oriented ATM, it is helpful to review connectionless systems.
LAN architecture, whether Ethernet, token ring, or FDDI, share certain characteristics. Each
station is connected to the network via an adapter card, which has a driver, above which is a
protocol driver, such as TCP/IP. In traditional LANs, such as Ethernet, the driver protocol is
connectionless, meaning that the protocol driver simply provides a packet with a source
address and a destination address and sends it on its way. Being joined by a common medium,
each station will see the packets of data put on the wire by each of the others, regardless of
whether the packet is passed sequentially, as in a ring topology, or broadcast, as with Ethernet.
The primitive from the station to the wire, or from the protocol to the adapter, is simply “send
packet.”
Once the packet has been sent, according to the specifications of whatever LAN is being used,
the adapter knows that the packet is visible to all stations on the network. Each station has an
adapter card, which processes the packet and examines the destination address. If the address
applies to that machine, the adapter does a hardware interrupt and accepts the packet. If not,
the adapter parses it. Again, this is called connectionless because no logical connection to the
recipient address was made, the packets were simply addressed and put onto the network.
A LAN network such as Ethernet offers very few services, because all an Ethernet card can do
is take a packet and send it. Being connectionless, it can provide no guarantees or similar
features. For example, it can’t determine the status of the target machine. This is why
developers rarely write applications directly to Ethernet. Rather, protocol drivers are used to
enter sequence numbers, verify packet arrival (retransmitting, if necessary), partitioning big
messages into smaller ones, and such—with all of these services adding time to the
transmission, and with none of them able to provide end-to-end quality of service guarantees.
However, ATM is complex. Even though ATM cells and cell switching make easier for the
development of hardware intensive, high performance ATM switches, its deployment requires
a very complex and intensive integration of software and protocol infrastructure. This still
specially when linking individual ATM switches into a network, as well as internetworking it
with the vast installed base of existing local and wide area networks.
*****Start TIP*****
ATM cells have a fixed length of 53 bytes. By using fixed-length cells, the information can be
transported in a predictable manner. This predictability accommodates different traffic types
on the same network—for example, voice, data, and video.

The ATM cell is broken into two main sections, the header and the payload, as shown on
figure 2.23. The header (5 bytes) is the addressing mechanism and is significant for
networking purposes as it defines how the cell is to be delivered. The payload (48 bytes) is the
portion that carries the actual information—either voice, data, or video. (The payload is also
referred to as the user information field.) An ATM cell is shown below.
*****End TIP*****
Figure 2.23
ATM cell is broken into two main sections, the header and the payload.
This section does not cover all the aspects of ATM technology, as there are already great
books available on the market covering the subject. For more information, check the
bibliographic reference at the end of this book. I am assuming you have at least a basic
knowledge about ATM layer protocols and cell formats, as well as the operation of ATM
switching systems. ATM is discussed here in the context of carrying IP transmissions, more
specifically voice over ATM, as it’s discussed in more details on chapter 3, “IP
Superhighway.”
Basic Understanding of ATM Networks
An ATM network consists of a set of ATM switches interconnected by point-to-point ATM
links or interfaces. These ATM switches support two kinds of interfaces: user-network
interfaces (UNI), which connects ATMs end-systems such as hosts, routers, etc., to an ATM
switch, and network-node interfaces (NNI), which is any physical or logical link across which
two ATM switches exchange the NNI protocol, as shown on figure 2.24.
Figure 2.24
ATM network interfaces
Fundamentally, ATM networks are connection oriented, requiring virtual circuits to be set up
across the ATM network before any data can be transferred. There are two types of ATM
circuits:
0 Virtual paths, which are identified by virtual path identifiers (VPI), is a bundle of
virtual channels, switched transparently across the ATM network on the basis of the
common VPI.
1 Virtual channel, which are identified by the combination of a VPI and a virtual
channel identifier (VCI), have only local significance across a particular link, and are
remapped, as appropriate, at each switch.

Although ATM switch implementations are complex, its basic operation is very simple, as
0 It receives a cell across a link through a known VCI or VPI value
1 It looks up the connection value in a local translation table to determine the outgoing
ports of the connection and the new VPI/VCI value of the connection on that link
2 It then retransmits the cell on that outgoing link with the appropriate connection
identifiers.
Figure 2.25
ATM Switch Operations
The switch operation is again very simple, as you can see on figure 2.26. External mechanisms
are responsible for the set up of the local translation tables prior to the transmittal of any data.
The manner in which these tables are set up determine the two fundamental types of ATM
connections:
0 Permanent Virtual Connections (PVC): A PVC is a connection set up by some
external mechanism, typically network management, in which a set of switches
between an ATM source and destination ATM system are programmed with the
appropriate VPI/VCI values.
1 Switched Virtual Connections (SVC): An SVC is a connection that is set up
automatically through a signaling protocol. SVCs do not require the manual
interaction needed to set up PVCs and, as such, are likely to be much more widely
used. All higher layer protocols operating over ATM primarily use SVCs, and it is
these that are primarily considered in this paper.
Figure 2.26
A diagram of ATMs two types of connections: Virtual Circuit and Virtual patch switch
ATM signaling is initiated by an ATM end-system that desires to set up a connection through
an ATM network, as shown on figure 2.27. Signaling packets are sent on a virtual channel,
VPI=0, VCI=5. The signaling is then routed through the network, from switch to switch,
setting up the connection identifiers as it moves along, until it reaches the destination end
system. The latter can either accept or confirm the connection request, or reject it, causing the
clearance of the connection.

Figure 2.27
Setting up a connection through ATM signaling
There are two fundamental types of ATM connections, as illustrated on figure 2.28:
0 Point-to-point connections, which connect two ATM end-systems. Such connections
can be unidirectional or bi-directional.
1 Point-to-multipoint connections, which connects a single source end-system to
multiple destination end-systems. The ATM does cell replication within the network
switches at which the connection splits into two or more branches.
Figure 2.28
Types of ATM connections
These types of ATM connections do not have any analog to multicasting or broadcasting
capabilities so common in many shared medium LAN technologies such as Ethernet or Token
Ring. In such technologies, multicasting allows multiple end systems to both receive data from
other multiple systems, and to transmit data to these multiple systems. Such capabilities are
easy to implement in shared media technologies such as LANs, where all nodes on a single
LAN segment must necessarily process all packets sent on that segment. In an ATM to
multicast LAN group, the only analog would be a bi-directional multipoint-to-multipoint
connection. However, this alternative cannot be implemented if you are using the ATM
Adaptation Layer (AAL) 5, one of the most common, used to transmit data across ATM
networks.
Unlike AAL 3/4, with its Message Identifier (MID) field, AAL 5 does not provide for the
interleaving of cells from different AAL5 packets on a single connection within its cell format.
Thus, all AAL5 packets sent to a particular destination across a particular connection must be
received in sequence, with no interleaving between the cells of different packets on the same
connection. Otherwise, the destination reassemble process would not be able to reconstruct the
packets.
This is why ATM AAL 5 point-to-multipoint connections can only be unidirectional. If a leaf
node were to transmit an AAL 5 packet onto the connection, both the root node and all other
leaf nodes would receive it. However, at these nodes, the packet sent by the leaf could well be
interleaved with packets sent by the root, and possibly other leaf nodes; this would preclude
the reassemble of any of the interleaved packets. Clearly, this is not acceptable.
Nevertheless, ATM does require some form of multicast capability, since most existing
protocols, being developed initially for LAN technologies, rely upon the existence of a low-
level multicast/broadcast facility. Therefore, three methods have been proposed for solving
this problem:
0 VP-Multicasting, where a multipoint-to-multipoint VP links all nodes in the
multicast group, and each node is given a unique VCI value within the VP, allowing
interleaved packets to be identified by the unique VCI value of the source. However,
this mechanism requires a protocol to uniquely allocate VCI values to nodes, but this
mechanism does not currently exist.
1 Multicast Server, where all nodes wishing to transmit onto a multicast group set up a
point-to-point connection with an external device, known as a multicast server, as
illustrated on figure 2.29. This multicast server is then connected to all nodes wishing
to receive the multicast packets through a point-to-multipoint connection, receiving
the packets, confirming they are serialized, and retransmiting them across the point-
to-multipoint connection
Figure 2.29
Typical example of a multicast server operation

0 Overlaid Point-to-Multipoint Connections, where all nodes in the multicast group
establish a point-to-multipoint connection with each other node in the group, as
shown on figure 2.30, becoming a leaf in the equivalent connections of all other
nodes, enabling all of them to both transmit to and receive from all other nodes.
Figure 2.30
Multicast through overlay of point-to-multipoint connections
Overlaid Point-to-Multipoint mechanism requires each node to maintain N connections for
each group, where N is the total number of transmitting nodes within the group, while the
multicast server mechanism requires only two connections. It also requires a registration
process for telling nodes that join a group what the other nodes in the group are, so that it can
form its own point-to-multipoint connection.
In light of all, as I write this chapter, we don’t have a recommended solution for the use of
ATM for multicast, which affects its ability to carry voice over IP successfully. But higher
layer protocols within ATM networks use both the latter two solutions for multicast, as it’s
discussed in more details on chapter three, “IP Superhighway.” This is one example of why
internetworking existing protocols with ATM is so complex. Most current protocols,
particularly those developed for LANs, implicitly assume a network infrastructure of a shared
medium and connectionless technology with implicit broadcast mechanisms. ATM
technology violates all of these assumptions!
*****Start TIP*****
Since this book proposes to discuss Voice Over IP, I decided not to cover ATMs any more
than the necessary to understand how IP Multicasting and VoIP rely on it. To further discuss it
would be out of the scope of this book. Thus, for additional information on ATMs, such as
ATM signaling and addressing, I recommend Cisco’s Website, where you will find a variety
of resources and documents on ATM and other IP technologies. Cisco’s URL is
http://cio.cisco.com/
*****End TIP*****
What’s Next
This chapter introduced the fundamentals of the RSVP protocol, IP Multicasting and ATM
technologies, as these technologies are key on the development and deployment of voice over
IP technologies and services. Next chapter, “IP Superhighway,” introduces the basic concepts
of voice over IP, and its most used H.323 standard. It also discusses other standards and
technologies such as audio codecs, IP over ATM, voice over ATM, the emulation of
traditional T1/E1 Trunks, IP over SONET and voice over SONET, and IP and voice over
frame relay. Further, this chapter discusses Layer 3 switching and gigabit Ethernet as well as
their role in VoIP.

Chapter 3
IP Superhighway
Voice over IP
Not so long ago the Internet used to run on phone systems, but now, phone systems are
running on the Internet. Voice and data consolidation can bring tremendous savings in
communications expenses, up to 90 percent. If the implementation of voice over IP
technology is down right, the savings can be very significant, amounting up to 90 percent, and
many times enabling a full return of investment (ROI) in less than a year. Furthermore, the
savings do not stop here, as the on-going costs to maintain voice over IP is much less than the
one paid on regular phone systems.
Since 1980s companies are carrying data traffic on the excess bandwidth associated with the
time division multiplexed (TDM) voice networks that were implemented as a lower cost
alternative to the public switched telephone network (PSTN). Thus, this concept is not new,
but with the emergence of client/server networking and the Internet, this voice-based
communications paradigm began to change as data traffic started to consume a far greater
percentage of network bandwidth. At first, Frame Relay circuits for data communications
were proliferating, as they were much cheaper than leased lines. However, Frame Relay at
that time was not well suitable for voice communication, so dedicated T1 remained the
channel of choice for telephony.
Carrying Voice Over Data Channels
During the mid-90’s data and voice began to merge, propelled by the advances in compression
technology, but this time on Frame Relay networks. The ubiquitousness of routed IP
networks, and the desires to trim telephony costs are the major driving forces for the
deployment of voice over IP (VoIP). One of the major advantages of VoIP technologies is
that they provide a way to leverage existing network resources and to dramatically reduce, or
even eliminate, telephony costs.

For instance, if you were to have an IP network in your company and branches throughout the
country and overseas, you could place a voice gateway between the network routers and the
PBXs at each of these sites, and than piggyback voice traffic on the Frame Relay WAN link
between these cities. The immediate advantages here are huge, as you would start paying local
call rates for long distance and international calls! Even if you didn’t have a WAN link
available, as long as each of your company’s site had a local point of presence (POP) for
router-based Internet connectivity, the voice call could still go out over the Internet. Your
phone charges here, just like with Internet connections, would be only for the monthly service
charge for the POP, that’s all.
Of course, the advantages of deploying VoIP are evident. The issues on rather deploy VoIP or
not relays mostly on the technical implementation issues and quality of the service than on
return of investment and cost benefit analysis. Thus, the goal when implementing VoIP is to
find a technology that supports telephony -- including both voice and fax -- over a variety of
infrastructures including Frame Relay, ATM, IP, and the Internet.
Again, when conducting your needs assessments, make sure to include both voice and fax
services, as fax is still a major business medium, regardless of e-mail. This can be a little trick,
as gateways need to be able to identify a call as voice or fax on the fly to eliminate the need for
separate ports for each medium.

Multiprotocol Support is Key
When deciding on the protocol supported, think ahead. Data communication technologies are
changing very rapidly. Also, some companies may adopt one technology versus another, based
upon their own needs, vendor’s influence or even carrier’s support. Therefore, your gateway
solution should support all the main communication links, such as Frame Relay, ATM, IP, and
the Internet, as they may exist between any two sites. With the flexibility to carry voice over
all of these links, investments can be protected, even while all resources are leveraged. This
approach also empowers you to selectively allocate differing communications networks for
various needs, selecting the one for each application that makes the most sense on a cost and
quality basis.
For example, for voice calls between sites A and B that have both Frame Relay and IP
network links, the Frame Relay channel could be selected for voice because with compression
12 voice channels can be carried in a 64 Kbps circuit. IP would be able to carry only 10 voice
channels on this same circuit. However, between sites B and C that have IP and Internet
channels available, the IP would be favored for voice because quality tends to be higher. But
you might chose to send faxes over the Internet, since they have better integrity in this media
than voice does, and you can also optimize bandwidth of the IP link. To ensure optimal
communications between all sites, the gateway should also feature any-to-any linking so that a
voice call can come into one site via IP, be switched out over Frame Relay, and reach a final
destination via the Internet.
Providing for Scalability and Management Tools
Configuring and maintaining a voice gateway requires a tightly integrated network
management system that features a graphical user interface (GUI). This GUI should not only
be easy to use, but should also have the intelligence to prevent invalid configurations from
being established. Check chapter 7, “What to Expect: The Innovators,” where some of the
major vendors and their products and services are outlined and discussed.
Make sure your VoIP implementation has large bandwidth capacity. Also, support for a direct
PBX connection via a T1 or E1 should be a requirement. As for gateways, they should be
capable to support multiple digital interfaces, and able to yield as many as 180 ports, on a
single gateway platform, so future growth can be ensured with the ability to link multiple
platforms. Also, make sure that all features and functionality, including support for Frame
Relay, IP, and Internet, voice/fax transparency, billing, and management should be available to
all platforms—no matter how large, or small.
Vienna Systems Corp. has been playing on the VoIP market since September of 1997, when
they announced they first multipoint gateway to be used as a translation mechanism for
sending voice traffic over corporate IP networks. The gateway could also be used to send
voice over the Internet or corporate Intranet. Today, Vienna Systems offers a state-of-art
solution, as shown on figure 3.1, called Vienna.way, which architecture has been designed to
be fully distributed and flexible, making it simple to build new VoIP applications and services.
Figure 3.1
The Vienna.Way architecture
Micom Communications Corp, a division of Nortel, leads the worldwide Frame Relay Access
Device (FRAD), with 83 percent of voice ports in that category deployed, as of the fourth
quarter of 1997. Micom’s Marathon I-FRAD product integrates data, voice, fax and local area
network (LAN) traffic over a single public frame relay permanent virtual circuit (PVC) and/or
private leased line from 9.6 to 1.544 Mbps or 2.048 Mbps. Intracompany phone/fax calls
bypass the Public Switched Telephone Network (PSTN), eliminating long-distance toll
charges and the need for multiple wide-area connections. Figure 3.2 is a screenshot of
Micom’s site.
Figure 3.2
Micom’s web site: one of the leaders in voice over networks
The example of these two vendors gives you an idea of how demanding the VoIP industry is
right now. The driven forces here is the savings companies can save money by consolidating
different types of traffic over a single IP WAN connection. At the same time, they can prepare
for new Internet-based voice applications that are expected to become very popular over the
next two to three years.
Because companies' IP-based WANs often have extra bandwidth, the tendency is for Intranets
to start carrying the multimedia traffic at first. By employing products like Vienna.way, users
can make voice calls to and from multimedia-capable PCs, as well as route IP-based voice
traffic to and from standard telephones over the PSTN. By the same token, products such as
Micom’s VoIP gateway can take care of fax transmissions over the Internet, as the fax
transmissions can accommodate seconds-long delays, but voice traffic, which is more delay-
sensitive, should stay with the company's standard 56Kbps and 1.5Mbps leased lines.
Another concept gaining momentum is cable-based VoIP, which are expected to follow the
lead of copper-based Internet telephony by focusing on niche services. But there are still a
number of issues to be resolved. These issues include perfecting gateways between the
Internet and the public switched telephone network, developing techniques to allow Internet
phone devices to ring like conventional phones, and integrating billing and management
systems with those users already in the operators' system.
On the higher end, cable operators have also been consolidating ownership of systems in
metropolitan areas under ever fewer companies and deploying Synchronous Optical Network
(Sonet) and other technologies to tie headends together. This could form the basis of large-
scale telephone networks in which cable operators provide local access through Internet
telephony and cities are connected via a combination of IP and interexchange carrier networks.
In summary, the adoption and implementation of VoIP can be justified by:
0 Increasing voice/data convergence
1 IP now the “common protocol”
2 Packetized compressed voice proven cost effective solutions
3 Rapid growth of intranets and extranets
4 Voice over Frame Relay - successfully deployed in major corporate networks
5 Voice over IP - rapidly emerging

The H.323 Standard
The H.323 standard is an extension of H.320, which addresses videoconferencing over ISDN
and other circuit switched networks and services. H.323 is a logical and necessary extension of
the H.320 standard to include corporate Intranets and packet-switched networks. Because it is
based on the Real-Time Protocol (RTP/RTCP) from the IETF, H.323 can also be applied to
video over the Internet.
The International Multimedia Teleconferencing Consortium, Inc. (IMTC) is the organization
dedicated to promoting and facilitating the ongoing development and implementation of an
open, standards-based and interoperable products and services for Multimedia
Teleconferencing, specifically the ITU T.120, H.320, H.323, and H.324 suites. The H.323
specification was adopted by the International Telecommunications Union (ITU) as the
standard for voice and video communications over packet switched networks such as the
Internet and corporate local area networks (LANs). It applies to multipoint and point-to-point
sessions, in accordance with other ITU multimedia teleconferencing standard. The
components of the standard are summarized in Table 3.1.
Table 3.1: Components of H.323

Recom Description Status(as of
mendati Oct. `96)
on
H.225 Specifies messages for call control including signaling, registration and Ratified
admissions, and packetization/ synchronization of media streams
H.245 Specifies messages for opening and closing channels for media streams, and Ratified
other commands, requests and indications.
H.261 Video codec for audiovisual services at P x 64 Kbps. Ratified
H.263 Specifies a new video codec for video over POTS. Ratified
G.711 Audio codec,3.1 KHz at 48, 56, and 64 Kbps (normal telephony). Ratified
G.722 Audio Codec, 7 KHz at 48, 56, and 64 Kbps. Ratified
G.728 Audio Codec, 3.1 KHz at 16 Kbps. Ratified
G.723 Audio Codec, for 5.3 and 6.3 Kbps modes Ratified
G.729 Audio Codec Ratified

For more informaiton about IMTC, visit their Website at http://www.imtc.org/u/u_search.htm
*****End NOTE*****
The range of networks H.323 can be applied, as well as the ratification of its core components
is very significant, which has been promoting a lot of growth in products and services based
on H.323. Interoperability is also becoming critically important, as more and more H.323
developments are announced.
Lucent Technologies, for instance, through Bell Laboratories, contributed significantly to the
development of the H.323 standard, and have been licensing the H.323 protocol to software
developers since January of 1997. Lucent’s objective is to help developers to accelerate the
deployment of standards-based multimedia communication products on the Internet and
Intranets. The company is strongly committed to the widespread adoption of H.323, providing
the source code and object code licenses on a variety of platforms for client and server
applications.
*****Start TIP*****
For additional technical information and sound samples, check elemedia’s Website, at URL
http://www.lucent.com/elemedia/.
*****End TIP*****
Vocaltec Ltd. Is another vendor supporting H.323 standard. Around the fall of 1997 Vocaltec
was already demonstrating its Internet Phone interoperability with Microsoft and Intel’s
telephony products. Vocaltec’s acclaimed Internet Phone software now comes with H.323
embeded and it can be fully integrated with Microsoft’s NetMeeting and Intel's Internet Phone
software.
*****Start TIP*****
For more information on the VocalTec product line, visit the company’s Website at URL
http://www.vocaltec.com or e-mail to info@vocaltec.com.
*****End TIP*****
DataBeam H.323 Toolkit Series
DataBeam's H.323 toolkits provide third-party developers with the components and
capabilities required to rapidly building robust standards-compliant products. The toolkits are
structured to provide developers with the functionality they need for their own product plans.
The DataBeam H.323 Toolkit Series includes the following toolkit offerings:
0 H.323 Core Toolkit - a standards-compliant code base that manages Call Control and
RTP/RTCP functionality
1 H.323 Value Pack - a robust set of added value components for H.323 development
on the Windows platform
2 H.323 Gatekeeper Toolkit - a portable, standards-based solution for H.323
Gatekeeper functionality
*****Start TIP*****
For more information about the H.323 toolkit, check Databeam’s Website at the URL
http://www.databeam.com/h323/info.html
*****End TIP*****
IP over ATM
This section was based in part on RFC 1577, authored by Mark Laubach, from Hewlett-
Packard Laboratories. RFC 1577 is a Standard Track, which defines Classical IP and ARP
over ATM.
For further information about this RFC or IP over ATM, Mark Laubach can be reached at
Hewlett-Packard Laboratories, 1501 Page Mill Road, Palo Alto, CA 94304. Or via e-mail at
EMail: laubach@hpl.hp.com
*****End NOTE*****
You should refer to the current edition of the "Internet Official Protocol Standards" (STD 1)
for the standardization state and status of this standard. Also, as this section introduces general
ATM technology and nomenclature, I suggest you to review the ATM Forum and ITU-TS
references for more detailed information about ATM implementation agreements and
standards, as well as chapter 2 “Understanding RSVP, IP Multicasting and ATMs,” which
provides an overview of ATMs.
***** End NOTE*****
The deployment of IP over ATM into the Internet is still new and will take some time before it
catches up and gets completed. However, already you can see traditional IP subnet boundaries
being deployed over ATM. The reason for such strategy is outlined below:
0 Systems administrator and IT professionals usually tend to be conservative about new
technologies, following the same familiar models they’ve earlier deployed. Until
ATM builds credibility, these professionals will always hold back, for obvious
reasons, as they wouldn’t do anything that could compromise their corporation’s
ability to conduct businesses in an effective way.
1 Corporate security policies often rely on the security, access, routing, and filtering
capability of IP Internet gateways via routers or firewalls. However, ATMs are not
allowed to "back-door" around these mechanisms, as it would jeopardize the security
of the corporation. Thus, ATMs need to provide a better management capability than
the existing services and practices.

2 Although RFC 1577 is almost four years old, standards for global IP over ATM will
take some time to complete and be deployed.
Encapsulating IP
The ATM Adaptation Layer (AAL) segments datagrams into cells, passes them to the ATM
network for transmission, and reassembles the cells into datagrams at the destination. It is
roughly equivalent to the data link layer in the OSI 7-layer model. Five different AALs have
been defined; the industry standard for data transmission over ATM is ATM Adaptation Layer
5 (AAL5).
AAL5 encapsulates a higher-layer datagram (such as IP) in an AAL5 datagram, as shown on
figure 3.3. AAL5 datagrams are variable length, from 1 to 65,535 octets, plus an 8-octet
trailer. ATM packages one IP datagram into one AAL5 datagram, segments the datagram into
cells, and sets the AUU (ATM-layer-user-to-user) parameter in the last cell of the datagram to
mark the end of the AAL5 datagram. Although AAL5 accepts up to 64k-sized datagrams,
TCP/IP restricts this MTU to 9180 octet datagrams--IP will fragment any larger datagrams
when passing them to AAL5 for encapsulation.
Figure 3.3
The trailer is always placed in the last 8 octets of the final cell
The trailer is always placed in the last 8 octets of the final cell. It has 4 fields, only two of
which are currently used--the length and frame checksum fields. The User-to-User Indication
field (UU) and the Common Part Indicator field (CPI) were added after the initial AAL5
proposal and are currently unused.
TCP over ATM
TCP over plain ATM doesn’t have a good performance. Actually it can be significantly worse
than standard "packet TCP". This is caused by segmentation of TCP/IP packets at the ATM
layer, since TCP packets are segmented into many 53 byte cells by the AAL5 layer. Any loss
of a single cell causes the effective loss of the whole TCP packet! Also, unlike the traditional
packet-switched networks, when the TCP packet is corrupted by the loss of a single cell, the
rest of the cells are still forwarded to the destination, clogging the congested link with useless
data. This situation can get even worse if any of the factors listed below contributes to the
increase of the number of cells dropped at the switch, such as:
0 small buffers
1 large TCP packets

2 inefficient TCP window size
3 increased number of active connections
Buffer sizes usually range from 256 to 8000 cells (per port) and a buffer size of 1000 to 2000
cells for a small switch (16-32 ports) is common. The use of larger packet or window sizes
increase the number of wasted cells that the congested link transmits when the switch drops a
single cell from one packet.
Thanks to partial packet discard (PPD), which is also known as selective cell discarding
(SCD), if there is a congestion caused by a drop of a cell, the PPD will attempt a traffic control
mechanism by dropping all subsequent cells the packet in question. Once the switch drops a
cell from a VC (Virtual Connection), the switch continues dropping cells from the same VC
until the switch sees the AUU parameter set in the ATM cell header, indicating the end of the
AAL packet.
This type of congestion control can be established on a per-VC basis (for AAL5). PPD
requires the switch to keep additional per-VC information in order to recognize which VCs
are using AAL5 and want to use PPD. It must also maintain a record of which VCs a re
currently having cells dropped.

PPD offer limited improvement, however, because the switch begins to drop cells only when
the buffer overflows. The first cell dropped might belong to a packet in which the majority of
cells have already been forwarded. Also, when the switch first drops a cell, the switch does not
look in the buffer for earlier cells that belong to the same packet. Thus cells from the corrupt
packet may be forwarded from the switch even though PPD is in effect.
TCP's default clock granularities represents another limitation of TCP over ATM, as they are
inappropriate for a high-speed ATM network. When a TCP packet is dropped due to
congestion, the retransmit timer gets set to a relatively large value, compared to the actual
RTT. According to simulations done by Romanow and Floyd, a TCP clock granularity of .1
milliseconds works well for TCP over ATM. However, newer versions of TCP like TCP
Reno and Vegas have improved congestion control algorithms that reduce reliance on the
retransmit timer. .
Voice Over ATM
IT professionals, more specifically systems managers directly involved with ATM carrying
voice and data over the same network are very disappointed. After all, the general expectation
portrayed in the ATM industry is that the technology exists, is proven and works. But in
reality, voice over ATM has turned out in a more expensive and inefficient way to carry voice
than time-division multiplexing (TDM) over leased lines.

According to the ATM Forum, voice should be transmitted as CBR (constant bit rate) traffic.
CBR is a method that force customers to reserve bandwidth for voice even when they're not
actually sending it. If you were to send voice as VBR (variable bit rate), even though it may
sound as an obvious alternative, as it permits you to allocate voice bandwidth on an as-needed
basis, reducing your costs with voice calls, you are setting yourself up for trouble.
VBR for voice isn't standard yet, even though the ATM Forum is currently evaluating ways to
write it into a revised ATM specification. Thus, be careful with this so called pre-standard
VBR equipment you may find around. The problem the industry is facing with voice over
ATM is more of a specification issue than anything else. Further, any pre-standard
specification is proprietary, and that leaves you in a voice-over-ATM double bind, as it forces
you to invest in standards-based but inefficient CBR products, or sacrifice interoperability for
savings by going with VBR offerings.
IP over SONET
If you look at the carrier and the ISP industry, you find that many carriers are looking for ways
to leverage their existing investments in Synchronous Optical Network (SONET) set ups by
offering IP services directly over them and avoiding the bandwidth overhead normally
associated with ATM.

The market of IP over SONET is growing, so it is the market of IP over ATM, especially
overseas. To me, this fact means that IP traffic is poised to become the ubiquitous dialtone for
a host of services that extend beyond the transport of HyperText Transport Markup Language
(HTML) traffic and flat image files. I believe that the volume of IP traffic will easily take over
voice on carrier networks within the next couple years, and the nature of that traffic is
currently shifting to multimedia applications such as electronic commerce and those delivered
by publish and subscribe technologies.
SONET has turned out to be one of the greatest surprises in communications technology of the
80’s. Conceived in 1984 as an optical network standard that would allow disparate network
elements to interface, SONET was addressing a specific concern local carriers had: a
fundamental, mid-span cable meets. If we look at SONET four years ago, we wouldn’t ever
imagined that it would become the big hit it’s becoming today with its huge bandwidth
capacity. Actually, SONET broaden the bandwidth concept so much that the distinctions
between transmission, switching, and CPE become blurred. Further, SONET has the capacity
to combine separate voice, data, and video networks into one broadband, multimedia network,
by encapsulating in fixed-length, variable position cells transported by super high-speed
synchronized frames over the SONET network.
Don’t be surprise if the gigabit transmission rates of SONET begin to rival the internal bus
speed of many mainframe computers, which will turn SONET networks into a wide-area bus
for the computer, assuming the role of a full-function server in the ideal distributed-computing
environment.
Many industry analysts believe Asynchronous Transfer Mode (ATM) based switching,
combined with SONET-based transport, to be the network solution that will eventually
dominate. Local and interexchange carriers for network expansion in favor of SONET are
abandoning T-3. In times of such a data communication technology blur, make sure you stick
with industry standards when designing broadband networks.
SONET Benefits
SONET offers tremendous benefits to both telephone carriers and end users. It was conceived
and created as a network, not simply a transmission path or piece of network gear.
Consequently, SONET is an end-to-end service designed to satisfy the following
communication needs:
0 Automated Maintenance and Testing
0 Bandwidth Administration
0 Real-Time Rerouting
0 SONET Digital Cross-Connecting

0 Standard Optical Interface
0 Synchronous Multiplexing
0 World-Wide Connectivity
SONET synchronous transmission offers the ability to directly access individual DS-0 and
DS-1 channels. This provides a simple and effective means to achieve automated control over
individual voice channels. What's more, this control can take place in "real time", providing
true "bandwidth-on-demand" type capability.
SONET enables carriers to tailor the width of information highway. This tailoring can be done
from a remote location, allowing carriers to expediently respond to the specific needs of their
customers. This characteristic of remote provisioning can result in the ability of carriers to
provide new services, such as network reconfiguration.
SONET has also the ability to support real-time rerouting, allowing customers to bypass
congested nodes or points of failure by reconfiguring the routes of affected circuits. The
reroutes would be predetermined and stored in Automatic-Call-Routing (ACR) programs to
provide immediate network recovery. Its automated maintenance and testing capability
through embedded control channels enables carriers to track end-to-end performance of every
transmission. This capability allows carriers to guarantee transmission performance, and users
can readily verify compliance through on-premise management terminals.
Synchronous Multiplexing
SONET supports transmission rates from 51.84 Mb/s through 2.488 Gb/s. Synchronous
multiplexing allows the high- speed transmission element within the multiplexer to observe
and extract the lower-speed digital signals. This mode of operation enables add/drop time slot
interchange multiplexing without bringing all the signals down to the DS-1 level, which
enables the elimination of mid-level network elements, such as back-to-back M13
multiplexers.
Today's T-3 transmission equipment lacks a universal protocol standard and therefore DS-3
signals are proprietary, and vary among vendors. Accordingly, none of these DS-3 schemes
are compatible. Hence a user is required to employ a particular manufacturer's equipment at
both ends of a link. SONET, however, alleviates all this and allows mid-span meet, which is
the ability to interconnect equipment from different vendors.
SONET promises true interconnectivity between fiber transmission equipment vendors. With
true interconnectivity, users as well as carriers will have more choice in product selection,
making it far easier to implement solutions. Carriers and users will be able to purchase
equipment based on price and performance, and mix and match hardware from multiple
vendors as needs warrant.
SONET heralds a fundamental change in the network from basic physical connectivity to
integrated end-to-end administration and maintenance. It will be a catalyst for the
modernization of the network, both private and public. SONET, along with ATM, will
transform the network from a circuit switched, to a high- speed cell-switched, dynamically
robust infrastructure.
How soon SONET deployment evolves will depend more on politics than technology. The
FCC's aggressive tactics to promote competition and deregulation may be the key impetus.
Increasing "local loop" competition from Competitive Access Providers (CAPs) and cable
television providers is driving the deployment of SONET equipment in LEC operating
territories. Already faced with competition, the IXCs are rapidly deploying SONET equipment
as well.
Voice over SONET
The Cirrus product family is the industry's first series of products to use a Thin Layer of ATM
over SONET/SDH fiber to merge transmission, access and termination into one integrated
access system. The Thin Layer of ATM multiplexing ensures that the network efficiently
delivers traditional voice services and can support advanced services such as Voice over IP
(VoIP), symmetric and asymmetric Digital Subscriber Line (DSL), and packet over SONET
(POS). About Atmosphere Networks.
But if you recall, ten years ago, ISDN was going to spark a revolution in which users could
speak and transmit data simultaneously over the telephone. SONET and ATM, were already
in-the pipeline back there, promising highly integrated voice, video and data transmission
rates. But today, even though ATM and SONET are pitted against each other in the race to
deliver ever-higher network bandwidth, ATM and SONET technology are more frequently
teamed. Aside from data rates starting at OC-1, or 51 megabits/sec, and scaling to OC-192, or
9.9 gigabits/sec, SONET brings its self-healing ring architecture, which provides unparalleled
survivability in the event of a fiber cut or node failure. If such a break occurs, SONET is able
to automatically reroute data in the other direction around the ring.
SONET and Other Data Streams and Protocols
The design of the frame and signaling for SONET makes it compatible with the traditional,
existing networks. Most prominent of such networks is the telephone network. The frame
format described above for STS-1 was chosen such that the 125 microseconds to transmit
matches the standard telephony 64 kilobytes per second circuit. A single STS-1 payload is
capable of carrying 672 voice channels. Table 3.2 shows a comparison of SONET with the
existing digital signals and voice channels.
Table 3.2 - SONET verus existing digital signals and voice channels
SONET Data DS-0s DS-1s DS-3s Voice Channels
Rate (64 (1.54 (2.048
(Mbps) kbps) Mbps) Mbps)
STS-1 51.84 672 28 1 672
STS-3 155.52 2016 84 3 2016
STS-9 466.56 6048 252 9 6048
STS-12 622.08 8064 336 12 8064
STS-18 933.12 12,096 504 18 12,096
STS-24 1244.16 16,128 672 24 16,128
STS-36 1866.24 24,192 1008 36 24,192

STS-48 2488.32 32,256 1344 48 32,256
Ideally, you should have ATM over a SONET infrastructure, as shown on figure 3.4. You can
have DS3-based (45 megabits/sec) ATM networks, but there's a lot of overhead with ATM,
and the efficiency of those networks is not as good as the higher-speed SONET. ATM and
SONET's proven combination of speed, reliability and flexibility also has enabled early
adopters within the government to tackle a host of applications that were stymied by the
bandwidth limitations of previous network setups. Those applications typically rely on
multimedia capabilities ranging from compute-intensive imaging applications to distance
learning, videoconferencing and even ultra-high-speed Internet access.
Figure 3.4
Stacking up ATM over SONET
But there are problems when you try to marry voice over ATM/SONET. On the ATM’s front,
installation can be a bit complicated, and you won’t find much for managing your network
there. ATM’s technology is still pretty new, so you won’t find much experience here, as the
pioneers are still building their learning curve and the “dos” and “don’ts" list. SONET has its
hurdles too, as scaling it up is a very expensive process.
Yet, there are many vendors climbing the SONET technology, making tremendous progress
there, and making sure that soon it will be ready for prime time. Fore, for example, is building
SONET-like restoral into its ATM switches via the Private Network to Network Interface
(PNNI), a standard to dynamically reroute traffic, and via SONET Automatic Port Switching.
IP over Frame Relay
Recent technologies have enabled packetized voice, or the transmission of voice and fax over
IP and Frame Relay networks, into the mainstream. An understanding of the key technologies
is essential for effective, high-quality implementation of enterprise solutions.
Early packet networks were based on X.25 and other proprietary statistical multiplexing
protocols running over modem or low-speed digital circuits, which had to cope with
substantial overhead and delay.
It was only in the early 1990 that frame relay became more common and started to threaten the
position of X.25. Frame relay takes advantage of the higher reliability of modern digital
networks to carry packet data with reduced error checking and retransmission, over higher
bandwidths.
The growth in frame relay since that time has exceeded all expectations, with thousands of
companies turning to this efficient, cost-effective service to fulfill data communication
requirements. Frame relay now plays a significant part in many networks infrastructure, and
companies are beginning to migrate its voice and facsimile applications over their frame relay
networks. By migrating to frame relay, companies have further consolidated their networks,
gaining the cost advantage of fewer WAN links without compromising their ability to
effectively transport voice, fax and data traffic.
The Internet Protocol, or IP, is not mutually exclusive to frame relay. In fact IP runs over
frame relay, PSTN and many other types of networks. Like frame relay, however, IP networks
are packet-based. Therefore the advantages and limitations inherent in IP voice are part of the
overall packetized voice discussion.
IP introduces even more performance challenges than does frame relay for voice applications.
These will be discussed later in the paper. However, IP has become ubiquitous as a result of
the Internet/Intranet explosion. And, beyond its ubiquity IP offers a new dimension of value in
terms of voice-data application integration.

Voice over Frame Relay
Every so often, the advantages of implementing voice over a frame relay network, especially
for those corporations already having voice available on virtual private networks (VPNs), are
not easily identified, inducing IT to base its decision on the economics.
This section was based on Nuera Communication’s whitepaper, authored by Steven A. Taylor.
Nuera is one of the major players in VoIP. For additional or more detailed information, or for
products that support it, check Nuera’s site at http://www.nuera.com.
*****End NOTE*****
True, voice over frame relay can save you money, being as inexpensive as half a cent per
minute. Actually, even if we were to assume that voice over the public networks costs as little
as five cents, voice over frame relay can often pay for itself in less than a year. Nonetheless
there are many other alternatives to transport voice, including leased lines, ATM and the
Internet. Thus, even though these are all viable technologies for packetized voice transport,
there are a number of factors that make frame relay an excellent choice today.
Specialized "Voice FRADs" are readily available both for voice transport and for transporting
other data along with the voice. This other data could include both LAN internetworking via
routers and more traditional FRAD functions for serial protocols like SNA and X.25. The
main challenge in adopting voice over frame relay is technical, a often you will go through
few technical hurdles in order to tune your implementation and ensure good voice quality.
Voice Over Frame Relay and Cost Benefits
Voice over frame relay can be the right solution for controlled environments where all of the
voice can be considered to be on the protected network (LAN/WAN). Thus, it is most easily
justified for intracorporation communications between sites on the corporate enterprise
network, using the same facilities that are already in place for the corporate data infrastructure.
Similarly, a carrier who wishes to provide voice services for users connecting over its internal
network can reasonable justify it.
As security technologies, including encryption schemes becomes available, packet voice, over
the Internet, frame relay, or ATM, may also be a reasonable alternative for applications outside
the boundaries of an Intranet, whether both parties are using the packet service or not. Until
then, the primary application for voice over frame relay will still be the same as the one for
which we've been using internal voice communication for over ten years, with multiplexers
providing virtual tie lines between PBXs attached to the network. The voice capabilities are
then used both for communications between LAN/WAN connected sites and for remote
dialing, as shown on figure 3.5
Figure 3.5
Intra-company Voice Networks
As you can see on figure 3.5, the network is used to connect to a site in a remote location.
Then, at the remote location, a secondary dial tone is provided by the remote PBX to enable
dialing a local call, as opposed to using the public network across the country or even around
the world. This strategy alone can save a corporation a lot of money. You could be at your
company’s head quarter in California, calling London as a local call, and the frame relay voice
could even take care of doing the local dialing at the remote location so that you wouldn’t
never even hears the second dial tone.
Now, using voice over frame relay involves the use of some fundamental assumptions. First,
frame relay voice uses an advanced compression algorithm, such as Code Excited Linear
Prediction (CELP). Advanced algorithms are making possible by the extremely high
processing power toll quality, with voice available at 8 to 16 kbps, as opposed to the 64 kbps
required by Pulse Code Modulation (PCM).

Further, it is assumed that Voice Activity Detection (VAD) is used. VAD takes advantage of
the fact that normal conversations are half-duplex. That is, the transmission is taking place in
only one direction at a time, with silence in the other direction. As a rule of thumb, it's not a
bad assumption that 50% of the time there is silence on the line. In reality, even more is
usually silence, especially if we consider pauses between words and sentences. However, the
packetization process adds a little overhead, so the silence greater than 50% is roughly
canceled out by the additional overhead.
Consequently, the combination of these factors represents a compression ratio of at least eight-
to-one compared with traditional voice. This is calculated by assuming the use of 16 kbps for
the voice itself, providing for four-to-one compression. This is doubled, though, by using
VAD for an additional two-to-one compression - hence the ballpark ratio of at least eight-to-
one.
The eight-to-one ratio, a conservative one, is used here simply to be conservative when
evaluating financial considerations.
*****End NOTE*****
Comparing Dial Voice Costs with Frame Relay
Voice over frame relay is fairly well accepted as being economical when used in international
and non-US applications. With international call prices sometimes approaching $1 per minute,
the payback period for voice over frame, even with the higher international rates for frame
relay, are very dramatic.
One way of looking at the economic justification for voice over frame relay involves the
dollars per month based on the cost of dial voice. For instance, if you assume that you're using
only one hour each business day for each of eight lines at $1 per minute, the monthly cost is
almost $10,000 a month. When you're dealing with this type of cost to start with, voice over
frame relay is cost justified very quickly.
But the economic justification is much more of a challenge in domestic networks. For
instance, if you assume that you're using 3 hours on each of eight lines at 5 cents per minute
for 20 days a month, the cost is $1440 per month for all eight lines - significantly less than
international phone bills.
Voice over Private Frame Relay
Even though voice over public frame relay services makes a lot of sense for international
applications, frame relay services are not universally available. Thus for international locations
where frame relay is not available, your best solution is to use private frame relay services
running over leased lines. Further, installations using public and private frame relay should be
totally interoperable with appropriate voice over frame relay equipment.
Now, in order for you to use voice over private frame relay networks within the US, you must
have bandwidth available., so all of the bandwidth considerations mentioned above still apply
here. However, it's more likely that the private frame relay network rather than the public
network will have "free" bandwidth available, as public frame relay service tends to be quite
granular already. Since you can buy services in DS0 (64 kbps) increments, and even finer
granularity below 64 kbps, you can then fine-tune the bandwidth utilization to a more precise
degree than you would to determine bandwidth needs. Consequently, the "excess bandwidth"
that tended to be hanging around in T1/E1 multiplexer networks should not exist, although
these limits do not exist for private frame relay networks.
One could argue that private frame relay networks can be fine-tuned to the same extent as
public services since fractional T1 is likewise available on a "by-the-DS0" basis. But the
interesting part comes with the tariffs. Fractional T1 prices tend to increase fairly linearly
through about half a T1. However, once the 768 kbps threshold is reached, the price increase
drops drastically. In fact, the price for a full T1, without discounts, is generally only about 20%
greater than the price for half the bandwidth. Furthermore, since carriers tend to discount full
T1 circuits much more heavily than fractional T1 circuits, we often find that a full T1 is
actually less expensive than half a T1.
When this is the case, and if the private frame relay network has internodal connectivity needs
in the range of 512 kbps to 768 kbps, it could very well turn out that full T1s are as
inexpensive as any other option for connecting the nodes. The result is that there is indeed
"free" bandwidth available for the frame relay voice traffic. Regardless of the price per minute
offered, it's really tough to beat "free" in any economic analysis.
The bottom line is that the use of frame relay voice can be justified easily on an economic
basis. Further, rather than hindering communications in any way, the availability of low costs
due to the advanced compression techniques can actually enhance business communications.
This is true for both U.S. domestic and international applications for both public and private
frame relay. It's hard to beat.
Is Voice Over Frame Relay a Viable Option?
Packetized voice can be transported by a wide variety of options from traditional leased lines
to ATM. The main strengths of frame relay lie in its availability, its pricing, the target speed
range, and the reliability of the technology. But is voice over frame relay a viable option?
Frame Relay vs. Leased Lines

There are circumstances where the use of leased lines is a much superior solution than frame
relay. For instance, leased lines are a better solution when requisite data transport speeds fall in
the range between 512 kbps and a full T1. In these cases, the equipment used to support voice
over frame relay still works. It just becomes a special case of frame relay being run in a point-
to-point environment (without the frame relay network in the middle). However, since frame
relay is pretty much available in the whole U.S., its pricing is much more attractive than leased
lines. This becomes especially important when the network topology involves either meshed
or star connectivity among a number of sites.
Frame Relay vs. ATM
ATM is another option for transporting packetized, compressed voice. As a sister technology
to frame relay - with the only meaningful difference being that fixed-length rather than
variable length packets are used - most of the reasons that frame relay is good for packet voice
apply equally well to ATM.
The main disadvantage of using ATM, is that it’s not as readily available as frame relay.
While ATM services are rolling out and availability will continue to increase over the next
several years, there are not yet enough ATM services available at T1/E1 speeds. ATM also has
some bandwidth inefficiencies, as inherently ATMs have and overhead of at least 10 percent,
based on the 5 octet header for every 48 octets of payload. Thus, for highly compressed voice,
this disadvantage can be highly noticeable, especially since packet voice packets tend to be
quite short, on the order of 10 to 15 bytes per packet (due to the need to provide samples on a
regular basis in order to control delay). Therefore, if we assume one voice packet per cell, well
over half of the cell has to be stuffed with electronic plastic peanuts to fill out the 48 octets of
payload. The result: over 200% overhead.
ATMs were developed for speeds of T3/E3 and above, they never worked well for T1/E1. The
cell overhead is almost insignificant when considering speeds of T3 to OC3, 45 Mbps to 155
Mbps. But the minimum of eight-to-one compression provided by advanced voice algorithms
makes the number of channels supported at these speeds much higher than any but the largest
users need. For instance, since a T3 normally carries 672 DS0s, a T3 would easily carry over
5,000 calls at eight-to-one compression. By contrast a T1 supports almost 200 simultaneous
calls, which for the most cased, is still a reasonable number for most companies.
The net result is that for cell-based ATM, the technology is readily available for carrying
packet voice, but it is overkill by the time ATM's target speed range is reached.
Frame Relay vs. the Internet
Needless to say, TCP/IP via the Internet is widely adopted. In fact, the idea of voice over the
Internet is drawing considerable attention, and this book is an indication of it! But there are
major drawbacks for Internet voice, which is essentially the same as those of X.25: the
robustness of the protocol with its requisite delay and delay variability. While these are
problems that can be addressed with frame relay, they are more difficult to address with
TCP/IP. For most applications, using the same transport layer that's already carrying TCP/IP
traffic, to carry voice will result in a more robust implementation since issues like queuing
traffic can be addressed directly.
Equipment for Voice Over Frame Relay
The utilization of voice over a frame relay infrastructure requires some equipment at your site.
The most common one is usually called Voice Frame Relay Access Device (FRAD), as shown
in Figure 3.6.
Figure 3.6
Typical Frame Relay Voice Implementations
A voice FRAD is very similar to a normal FRAD in functionality, but it is specialized in that it
handles the voice packetization and compression process. Of course, FRADs also have other
features, such as support for SNA and possibly some other serial protocols, as well as router
support, which are provided either integrally or via external routers.

The voice FRAD will typically be a point-to-point type of device with a single frame relay
interface, but it can usually support multiple logical connections to a number of sites on the
frame relay network by routing voice calls over several different virtual circuits. But the voice
FRAD may also support at least one additional frame relay interface, which is very important
when utilizing existing routers in conjunction with the voice FRAD, allowing the voice FRAD
to perform frame switching. Further, data connections for existing routers and other frame
relay accepting direct attachments can also support devices. Whether these capabilities are
external or integral, the voice FRAD must use priority and "fairness" algorithms to ensure that
appropriate access to the network is available for all traffic types.
The voice FRAD typically supports a variety of voice interfaces. The most common is an
analog interface, in which case there is a direct conversion within the voice FRAD from
analog voice to compressed digital voice, with the compressed voice transported via frame
relay. Voice trunks from the local PBX (or telephone) are attached directly to the voice FRAD.
The voice FRAD supports the most common analog voice functions, including support for a
wide variety of 2-wire and 4-wire interfaces. A voice FRAD also supports digital T1/E1
interfaces for headquarters and regional sites requiring a higher density of voice connections.
Technical Challenges for Transporting Voice Over Frame Relay
Transporting voice over frame relay has its challenges. Historically, frame relay has been
developed and sold primarily as a data transport technology and service solution, not voice.
But it doesn’t mean that frame relay has a fundamental technical limitation, and all of the
technical challenges of using frame relay to transport voice can be met.
You may run into carriers who will discourage you from using voice over frame relay.
Conversely, there are carriers that actually welcome voice traffic. The reason for some
discouragement is that some carriers have a larger installed base of voice to protect from
possible erosion by frame relay. In some cases these carriers may also be adhering to corporate
policy rather than legitimate technical concerns regarding the transmission capabilities.
From the technical side, not every carrier is technically prepared to support voice over frame
relay, as their chosen switching system may not provide the capabilities and types of technical
support needed by frame relay voice. The frame relay specifications are a User-to-Network
Interface (UNI) specification only. The actual network transport is not specified. Thus, various
switching architectures and network implementations will provide different levels of support
for voice over frame relay.
An alternative to be considered is to transport voice over your private frame relay network,
which is intrinsically easier, since the network infrastructure is under your direct control. In
this case, it is up to you to make sure that the various characteristics of the networking
architecture are sufficient to provide the desired level of voice support. But the challenges will
still be there, and regardless of using main carriers or private frame relays, they must be
resolved. Let’s take a look at some of the most important ones.
Controlling Delay
The major challenge in transporting voice over frame relay is the use of frames itself, which
generates delays. These delays, also know as absolute delays, must be controlled in order to
avoid interfering with the normal human communications process. If there is more that about
500 msec total (round trip) delay, carrying on a "normal" conversation is difficult. The first
level of delay is based on the "freeze-out" phenomenon. During the time that a given frame or
cell is occupying the transmission facility, other traffic may not be transported.
This concern has some basis so long as the data frames are quite long and the speeds are low.
The actual freeze-out time per node or link is:
time = maximum frame length / transmission link speed.
Therefore, the maximum frame size can also have a major impact. If one limits the frame size
to roughly 500 octets, the maximum freeze-out time is only 12.5% of the time with a 4,000
octet maximum. At the same time, frame relay still represents almost a ten-fold increase in
efficiency vs. ATM. Further, the "frame vs. cell" arguments really apply only at the UNI. The
intranetwork architecture is not subject to the standards, so the transport may indeed be over
an ATM infrastructure. This challenge is further met by the capabilities of some voice FRADs
to perform sub-segmentation of data frames. If data comes into the voice FRAD via a frame
relay interface from a router, the maximum frame size may be too long for guaranteed
excellent performance.
Consequently, the voice FRAD will segment the frame into multiple frames with a shorter
maximum frame length. The receiving voice FRAD will then reassemble the frames. This
process is analogous to the need for frame segmentation when transporting very long frames
from protocols like IP over Ethernet, which has a maximum frame length of about 1500 bytes.
But worse than an absolute delay is what is known as delay variability. When a frame relay
replays your voice at the receiving end, you expect your receiver to hear a continuous and
smooth talk spurt. However, packet systems are inherently prone to variable delay. However,
not always the voice packets get through quickly enough, as many times they may be delayed
a bit more.
To resolve this problem, one alternative is by buffering the end device, smoothing out minor
variations. A nominal delay is intentionally introduced so that there is a high probability that
all of the packets from your talk spurt will be there in time to be played out smoothly.
Another alternative is to limit the maximum size of the frames and using cells within the
transport network helps. In addition to minimizing the freeze-out, yet another delay factor, the
fill time, the time that it actually takes to fill a frame or cell with voice, is limited significantly
by use of short frames. Advanced algorithms like CELP pack a lot of information into a few
bytes. Consequently, in order not to induce unacceptable delay, the frame sizes for the voice
frames in addition to the data frames must be kept relatively short. Typical compressed voice
frames are usually in the order of 10 to 15 octets per frame. Also, or data applications, a FIFO
(First In, First Out) scheme is often considered optimal and most fair. Voice, however, is
much less tolerant of delay than data. Consequently, some form of priority queuing, both in
the access devices and within the switching network, will greatly enhance the probability of
successfully implementing voice over frame relay.
A further delay and queuing issue one must consider is the impact of "lost" frames. For data,
"late" is indeed better than "never" so far as delivery is concerned. The same is not necessarily
true for voice. First, there is some voice algorithms that first send the "basic" voice
information. Then, if additional bandwidth is available, "enhancement" packets are added.
These "enhancement packets" can be sent as "discard eligible," and their loss degrades the
voice quality but does not make the call unintelligible. Further, whether the voice packets are
being transported over frame relay, ATM, or dedicated transmission services, there is a
possibility that packets will be "lost" due to link errors and other factors. Consequently,
processes have been built into the advanced algorithms to compensate for a certain degree of
packet loss. Parenthetically, the short frame sizes that are an advantage for controlling delay
also help minimize the impact of lost frames since there is less information per frame.
The bottom line for queuing algorithms is that unlike data frames that should be delivered
whenever possible, there comes a point when it is better to lose a voice frame than to deliver it
too late. Consequently, it is both possible and necessary to consider the use of voice when
looking at various intranetwork-buffering schemes.
Fax and Modem traffic present a much larger technical challenge. They are treated together
here since faxes tend to use off-the-shelf modem technology for the actual fax transmission.
The good news about fax machines and modems is that they're incredibly inexpensive and
virtually everybody has them. Similarly, the bad news about fax machines and modems is that
they're incredibly inexpensive and virtually everybody has them. Further, within the corporate
environment, the purchase and utilization of these devices is often not under the control of the
corporate information-processing department, so even knowing when and where these devices
might exist on the intracorporate network may be impossible.
Usually, fax and modem traffic is normally transmitted over "telephone" lines. The
modulation schemes used for these devices assume the nominal bandwidth and other
characteristics of "real" uncompressed phone lines using traditional 64 kbps PCM voice
modulation schemes. Highly compressed voice, while sounding very good for speech, uses
different algorithms that do not necessarily support the data modulation algorithms. For
instance, most advanced modem modulation schemes include "phase shifts" as a part of the
scheme. This is supported by traditional high bandwidth (and analog) voice techniques.
However, the human ear cannot detect phase shifts, so preserving phase shift information does
not add to the quality of highly compressed voice. Consequently, most highly compressed
voice algorithms do not support modem traffic at speeds over 4.8 kbps. In order to support
higher speed modem and fax traffic, which is quickly becoming the norm, one of several
approaches must be taken.
The first and simplest approach is to declare that modems and fax machines should not be
used over the private, intracorporate voice network. However, this requirement is likely to be
politically unappealing. After all, shouldn't an "advanced" voice network be able to support all
of the "legacy" applications, whether they're literally "voice" or not? Further, this approach
would require that the "voice" network still have some lines for on-net traffic for
intracorporate fax and modem traffic. This bifurcated corporate voice network then tends to
start losing many of the advantages that we hope to gain by using voice over frame relay.
Beyond this segregated approach, there are two additional approaches that offer technical
solutions to this historically difficult problem. The technically simpler of these two approaches
is to turn off the compression whenever fax or modem traffic is detected. Basically, the
equipment listens for fax and modem tones, and whenever they are detected a full 64 kbps is
dedicated to the voice call rather than the compressed bandwidth. The advantage of this
approach is that it works. And it's simple. This disadvantage is that it is a "brute force"
approach that uses more bandwidth rather than less.
Another approach, as shown in Figure 3.7, is to terminate the analog portion of the fax or
modem traffic at the voice FRAD, transport the information as data at the appropriate rate,
then remodulate as an analog call at the remote voice FRAD. This way, the call takes only the
amount of data that is really needed to transport the digital information. Note that there is very
little traffic sent by the receiving fax.
Figure 3.7
One Fax & Modem Solution Remodulation
Another challenge for highly compressed voice is avoiding multiple tandems. As depicted in
Figure 3.8, it is fairly common for calls to be passed through multiple switches. However,
highly compressed voice doesn't fare particularly well through multiple compression/
decompression cycles, so whenever possible the calls should be limited to a single
compression.
Figure 3.8
Multiple Tandems
Figure 3.9 shows one solution to this problem, performing frame switching within the voice
FRAD. In this situation, the voice FRAD has sufficient frame switching capacity to recognize
that some calls may not physically terminate at a given site, so the frames are "bypassed" to
their ultimate destination. The obvious advantage of this solution is that the voice stays in the
compressed digital format throughout the network with a single compression/decompression.
Further, the requisite number of PVCs for the entire network is smaller since direct
connectivity among all sites is not needed. Nevertheless, it has the drawback that the traffic
must traverse the frame relay interface twice (into the voice FRAD and back out) at the
intermediate site, adding delay.
Figure 3.9
Switching in FRADs
An alternative solution, shown in Figure 3.10, avoids multiple passes over frame relay
interfaces by using full network connectivity for PVCs between each of the sites. Each call is
"routed" to the appropriate destination by interpreting the DTMF "dialing" tones as the call is
established, and, based on the "phone number," the call is placed on a particular PVC. Once
again, the advantage is that multiple compression decompression cycles are avoided. Staying
within the network minimizes delay. Nevertheless, this configuration usually requires more
PVCs than the method in Figure 3.14. Also, this requires that the voice FRAD must be more
sophisticated to handle all of the dialing interpretation functions.
Figure 3.10
Call Processing
Multiple tandems should be avoided whenever possible regardless of the transport technology
used. Both switching within the voice FRAD and call processing can help alleviate some of
the problems, and having both of these options available will let the network designer fine
tune the performance.

Equipment for Voice Over Frame Relay
The utilization of voice over a frame relay infrastructure obviously involves some equipment
on the customer site, typically Voice FRAD as shown on figure 3.11
Figure 3.11
A typical Voice FRAD topology
A voice FRAD is similar in function to a normal FRAD (Frame Relay Access Device), but it
is specialized in that it handles – at a minimum – the voice packetization and compression
process. Of course, some usual FRAD features are also included, like support for SNA and
possibly some other serial protocols. Router support is provided either integrally or via
external routers.
The voice FRAD will typically be a point-to-point type of device with a single frame relay
interface. Nevertheless, when used in a networking environment, this single interface can
support multiple logical connections to a number of sites on the frame relay network by
routing voice calls over several different virtual circuits. But the voice FRAD may also
support at least one additional frame relay interface. This is especially important for utilizing
existing routers in conjunction with the voice FRAD, allowing the voice FRAD to perform
frame switching. This additional interface could also allow for the connection of the voice
FRAD to a frame relay network via two separate circuits and access points for additional
reliability.
Data connections for existing routers and other frame relay accepting direct attachments can
also support devices. Whether these capabilities are external or integral, the voice FRAD must
use priority and "fairness" algorithms to ensure that appropriate access to the network is
available for all traffic types. This critical function is discussed in more detail in the next
section.
The voice FRAD typically supports a variety of voice interfaces. The most common is an
analog interface, in which case there is a direct conversion within the voice FRAD from
analog voice to compressed digital voice, with the compressed voice transported via frame
relay. In this case, the voice trunks from the local PBX (or telephone) are attached directly to
the voice FRAD. The voice FRAD, then, should support the most common analog voice
functions, including support for a wide variety of 2-wire and 4-wire interfaces. If a telephone
is directly attached the voice FRAD must supply battery and ringing functions.
A voice FRAD also should support digital T1/E1 interfaces for headquarters and regional sites
requiring a higher density of voice connections. These interfaces, typically from a PBX or
PSTN, multiplex multiple conversations onto a single physical interface. This has the effect
both of simplifying multiple connections and of reducing the requisite number of physical
cables. It’s also important to know how many conversations can be supported by the voice
FRAD since a T1/E1 interface can support 24/30 conversations.
Network Design Considerations
Frame relay provides statistically multiplexed access to many destinations over a single
physical connection to the frame relay network, as shown on figure 3.12. To obtain the
expected end-to-end performance, one must take into consideration several important factors
when designing the network.
Figure 3.12
Committed Information Rate (CIR)
Committed Information Rate (CIR) is the frame relay parameter that defines the minimum
throughput that should be expected on a given virtual circuit. When designing time division
multiplexer (TDM) networks, you should consider what portion of the bandwidth to allocate
to each end-to-end connection. In a frame relay network, you should consider how much CIR
to allocate to each permanent virtual circuit (PVC). When the network is heavily loaded, each
PVC will be able to carry at least the CIR allocated. When the network is lightly loaded,
PVCs can carry substantially more than the allocated CIR.
*****Start TIP*****
TDM and PVC? What are we talking about?
Time Division Multiplexer is a device that allows multiple conversations to share a single
transmission facility, with each channel having access to a dedicated portion of the bandwidth.
Permanent Virtual Circuit is a virtual path through a network characterized by fixed
endpoints defined by the network operator at service subscription. A single physical path may
support multiple PVCs and SVCs. Compare with Switched Virtual Circuit
*****End TIP*****
Some public networks offer PVCs with Zero CIR and provide very good performance because
they design the network with enough capacity to prevent congestion except in case of a failure
in the network. Others offer low CIRs and are so heavily loaded that very little traffic above
the CIR can get through during peak periods. When traffic in excess of the subscribed CIR is
sent into the network, the network tags the traffic as discard eligible. The network during
severe congestion will discard discard eligible traffic, while CIR traffic is only discarded due
to a failure in the network. Figure 3.13 provides a graphic view of it.
Figure 3.13
Data traffic is likely to perform well when traffic is occasionally discarded, even if the traffic
discarded is a long burst of traffic. To recover, the user equipment re-sends the data traffic.
Voice traffic can tolerate random discards of traffic (typically up to 10% can be discarded and
still maintain good voice quality). However, if voice traffic were to be discarded in long
bursts, entire spoken words can be missing from a conversation and this is not acceptable. To
ensure long burst discards do not occur, one should buy enough CIR to ensure that voice
traffic is not marked discard eligible by the network.
CIR with Mixed Voice/Data Submultiplexing
To reduce recurring PVC costs, most VFRADs support submultiplexing. Submultiplexing
allows many channels of voice and data traffic to be carried between two endpoints over
single PVC as shown on figure 3.14. So if two 8Kbps voice channels are sharing one PVC,
simply buy 16K of CIR for that PVC from the frame relay service provider.
Figure 3.14
VFRADs support of submultiplexing
But what happens when data is mixed with voice on one PVC? How much more CIR is
needed? The answer to this can be quite complex.
If the source of the data is a high-speed router on a high-speed interface into the VFRAD, then
it can quickly consume all of the CIR on the PVC, which is being shared with the voice traffic,
and this is quite undesirable. To prevent this, the VFRAD must permit the network manager
to configure CIR individually for each user of the PVC. When the data user (router) tries to
consume more than the allotted CIR, the additional traffic is marked discard eligible by the
VFRAD and the network retains the remaining CIR for the voice users.
High Speed Flooding and Traffic Shaping
While the VFRAD can enforce the rate at which CIR is consumed, it can also prevent an
attached router from flooding it with excess frames over a high-speed interface, as shown on
figure 3.15. By configuring a restraining excess burst, the VFRAD can discard frames, which
exceed this limit. But discarding traffic does not lead to optimum network performance.
Figure 3.15
VFRAD not only enforce the rate of CIR consumed but prevents routers from flooding it.
Bit what about traffic, which is flooding in from a distant router attached directly to the frame
relay network? This excess flooding is an issue because the local frame relay switch can get
backed up with large amounts of traffic which prevents voice frames from getting through in a
timely fashion. The only good solution to the flooding issue is to configure the routers to pace
their traffic per PVC at a rate which is compatible with the speed of the interfaces and relative
to the peak load on the destination frame relay UNI.
*****Start TIP*****
A good example of routers configured to pace their traffic per PVC at compatible rates of
speed and peak load of a destination frame relay UNI is the traffic shaping feature described in
the Cisco IOS Software Release 11.2 Product Bulletin #487, section 3.2.2.
*****End TIP*****
Another cause of flooding is very long data frames. VFRADs can control the effect of long
data frames sent from attached routers by segmenting the frames into smaller pieces, sending
them through the network, and then re-assembling them at the destination VFRAD before
delivering them to the destination router. But when the destination is a router directly
connected to the frame relay network the only solution is to configure the router to a
maximum packet size which is compatible with the speed of the interfaces (slower interfaces
require a smaller packet). In the near future there will be a Frame Relay Forum Data
Fragmentation Implementation Agreement which will specify VFRAD to router
fragmentation procedures. This will allow large packets to span multiple frames and will be
configured per PVC.
Delay and Priority
Delay is critically important in voice applications and delay objectives can be easily obtained
with a good network design. The end-to-end delay must be less than 250 milliseconds in each
direction or else users will notice it. To obtain this objective, the end-to-end delay through the
VFRADs should be less than 100 milliseconds and the frame relay network should deliver the
traffic end-to-end in less than 150 milliseconds, as shown on figure 3.16.
Figure 3.16
Configuring delay and priorities for VFRADs
Delay through the network can vary from one moment to the next depending on network
traffic load. VFRADs can compensate for normal delay variations. But under very heavy load
conditions, with data users sending very long frames, delay variation can increase. Most
frame relay network switches offer PVC priority, which will allow traffic on one PVC to be
sent while holding the lower priority traffic for a short time. By configuring voice PVCs with
a higher priority than data PVCs, delay variation can be substantially reduced. When PVC
priority is not available, the other solutions are to place delay sensitive traffic on a separate
route through the network, or increase the network bandwidth so that it is not so heavily
loaded.
Congestion Indication
The frame relay congestion indicators, FECN and BECN, are sent from the network to the
VFRAD when the traffic on a particular PVC encounters congestion. The VFRAD will
respond in a variety of ways depending on where the traffic originated. Figure 3.17 depicted a
layout of FECN and BECN indicators.
Figure 3.17
FECN and BECN frame relay congestion indicators
If the data traffic was sent to the VFRAD from an attached router, the FECN and BECN will
be passed to the router so that it can respond appropriately. If the data traffic originated from a
VFRAD data port, the VFRAD will assert the appropriate flow control. When the CIR
settings are configured as described above, voice traffic should never be a cause of congestion
and therefore no action is taken to reduce voice traffic.
*****Start TIP*****
What is Forward Explicit Congestion Notification (FECN)? – FECN is a bit in the frame relay
header that indicates that congestion may be present in the network for traffic traveling in the
direction opposite to the direction of travel for the frame in which the bit is set.
What is Backwards Explicit Congestion Notification (BECN)? – BECN is a bit in the frame
relay header that indicates that congestion may be present in the network for traffic traveling in
the direction opposite to the direction of travel for the frame in which the bit is set
*****End TIP*****
Efficiency
Frames vary in length but the length of the header and trailer plus flag (the frame delimiter) is
always five octets. Therefore, very long frames are very efficient and very short frames can be
very inefficient. To reduce delay, voice frames are sent frequently and they have a low
average bit rate. As a result, voice frames can be quite short (typically 15 octets plus the five
overhead octets at 8 Kbps) and inefficient. Figure 3.18 illustrates this concept.
Figure 3.18
Very long frames are very efficient and very short frames can be very inefficient
Also, short frames place a burden on frame relay switches, which have a limit, on how many
frames they can switch per second, regardless of the frame length. To improve efficiency
while slightly increasing delay, some VFRADs allow the network manager to configure (per
user) multiple voice samples to be collected before placing them in a frame. This can
dramatically add to the efficient use of the network bandwidth. Typically, each additional
voice sample collected before sending a frame adds 15 milliseconds of delay. With three
voice samples per frame, the end-to-end delay through the VFRAD should be around 100
milliseconds.
Echo Cancellation
Due to termination impedance mismatches between analog 2-wire circuits and 2- to 4-wire
interface circuits at the called end of a network, voiceband echoes can be reflected back
towards the calling end of the network, as shown on figure 3.19. The voice port echo
cancellation feature, when enabled, can minimize these echo effects.
Figure 3.19
Voice port echo cancellation features can minimize echo effects

Dialing Plan
Frame relay PVCs interconnect PBXs in the same way they are used to interconnect LANs, as
shown on figure 3.20. By replacing leased lines with frame relay PVCs, monthly costs are
reduced and one PBX can connect to many other PBXs over one frame relay network access
line. But how does the VFRAD know which PVC to use to get the voice call to the correct
destination? It does it the same way that the PBX would do it over multiple leased lines - it
looks at the dialed digits and routes the call. The network manager configures the VFRAD
with a dialing plan exactly as would be done for a PBX. This can be as simple as indicating
the country code or area code for each destination, or can be more detailed if desired.
Figure 3.20
Frame relay PVCs interconnect PBXs in the same way they are used to interconnect LANs
The VFRAD can also perform custom dial digit manipulation. For example, it can route a call
based on a 10 digit number, and then outpulse only the last three digits of the number at the
destination so that the destination PBX can ring the correct extension in an office. The dial
digit matching and substitution configuration is configured by the network manager and can
be as simple or robust as desired.

Understanding Layer 3 Switching
Layer 3 refers to the Network Layer of the seven-level Open Systems Interconnect (OSI)
model of networking. The Network Layer determines how data is transferred between
computers, and address routing within and between individual networks. Conventional
Ethernet switches work at the Layer 2 (Link Level) of the OSI model. This requires external
routers to transfer data among subnets. Integrating the routing function into the switch means
users can implement switched networks without buying more routers. This helps reduce the
cost of implementing a switched network, and reduces the overall cost of network ownership.
Routers cause bottlenecks in switched networks, because they typically cannot transport more
than 10,000 packets per second. Ethernet switches operate at up to 600,000 packets per
second. Even though Layer 3 switching inherently alleviates router-caused bottlenecks, the
actual improvement depends on how the routing is implemented. If it uses an off-the-shelf
CPU, the same bottlenecks are likely to reappear because the switching speed will be limited
by the CPU's processing time. That's because this approach requires the entire frame to go
through the CPU.
Therefore, the pressure on networks is steadily increasing. Users are demanding more
information faster and from increasingly distributed locations. At the same time, demanding
new applications and skyrocketing Internet use are not only changing bandwidth requirements,
they’re also altering traditional traffic patterns.
A successful solution requires technologies that address performance issues at every level of
the network, from the desktop to the telecommunications infrastructure. Fast Ethernet and
emerging Gigabit Ethernet products, for example, offer high-bandwidth pipelines within the
corporate Intranet to move data far more rapidly. Switching technology has also evolved to
segment the traditional shared topology LAN, providing dedicated bandwidth where it’s most
needed.
Such developments have dramatically improved user access to information, but the resulting
increase in data flow is creating new pressures at other levels of the network infrastructure. In
particular, traditional backbone routers are being swamped as they try to direct traffic among
high-bandwidth, switched networks.
Layer 3 switching offers a solution to this critical bottleneck. By integrating router
functionality into the silicon within a switch, Layer 3 switching such as Intel’s illustrated on
figure 3.21, provides LAN-based routing at near-switching speeds. It’s a significant innovation
that can increase performance, while helping to reduce costs and complexity.
Figure 3.21
An Intel Layer 3 switch provides high-performance switching, plus LAN routing at near-switching speeds. (Source: Intel Corp.).
The hardware-based routing of a Layer 3 switch is much faster than traditional, software-based
routing. Also, packets that need routing can travel across the backplane of the switch,
providing yet another boost in performance. With the LAN router bottleneck removed,
switched networks can take better advantage of available bandwidth. Desktop users get the
high-speed network response they need, and the network is more stable and reliable.
A great feature of Intel’s Layer 3 switching strategy outlined on figure 3.21 is that it works to
protect existing investments in network infrastructure, helping to ensure compatibility with
current network components by using routing protocols that are well established as industry
standards, unlike proprietary Layer 3 implementations. Even your current routers remain
useful, as they just move to the periphery of the network, where they can continue to handle
WAN communications.
Why Layer 3 Switching?
Not so long ago, networks were small and flat, with simple peer-to-peer connections on a
shared-media cable. Then these networks expanded and bridges were introduced to connect all
the smaller networks into larger ones. However, as networks became busier and more
complex, routers became the favored interconnection devices, because of their ability to
provide segmentation and logical structure to the network. The result was the fully routed,
hierarchical network, as shown on figure 3.22, which is still a very common structure of
intranetworks.
Figure 3.22
Traditional LAN routers segment the network and provide logical structure, but they are slow, complicated and expensive. (Source:
Intel Corp.
As these interconnected networks expanded and got busier, performance demands led to the
development of switches (Layer 2 switches), as a fast, simple and cost-effective alternative to
creating more routing layers within the Intranet, as shown on figure 3.23. Corporate intranets
became flatter again, and much faster — but they also became harder to control and less
stable, because of their vulnerability to broadcast storms and redundant traffic.
Figure 3.23
Standard switches are much faster than routers and provide dedicated bandwidth where needed. (Source: Intel Corp.)
As the volume of Internet and Intranet communications increased geometrically, more than 20
percent of network traffic crossing the boundaries of a local network became very common.
Actually, in many intranets, the amount of traffic directed across the limits of the local
network is much greater than the local one, as more users are connected to virtual private
networks, Extranets and so on. Non-local traffic is increasing beyond the capacity of LAN
routers, and is putting huge pressure on wide-area networks, resulting in decreased network
reliability and slower response times.
The countermeasure is usually a segmentation of the existing network into more and more
switched segments. But the pressure on backbone routers has continued to rise, and a better
solution was on demand. Layer 3 switching was the answer. These “super-fast-packet-
forwarders-with-some-routing-added” (that’s what it is!) are aimed at relieving congestion in
busy networks, such as the ones found in campus/building LANs, by off-loading or replacing
backbone routers that can no longer keep up. So Layer 3 switches must work faster, scale
better and be reasonably easy to deploy and manage. Layer 3 offers:
0 Enhanced Performance - LAN routing at near-switching speeds eliminates router
bottlenecks, while helping to improve support for high-bandwidth, multimedia
applications (i.e., IP Multicast, VoIP).

0 Simplified Management - Interoperates with existing networks equipment and
protocols, and is far easier than a router to install, configure and manage.
0 Lower Cost - Both acquisition and support costs are greatly reduced when a Layer 3
switch is used in place of a complicated and expensive router.
But What is Layer 3 Switching?
Layer 3 refers to the network layer in OSI’s seven-layer model of networking, as shown on
figure 3.24. Layer 3 controls the routing of messages across different networks, as well as
network flow and traffic management, and is the conventional dominion of routers.
Figure 3.24
Unlike a standard switch, which operates in the Data Link Layer of the OSI reference model, a Layer 3 switch also operates in the
network layer to perform high-speed routing functions.
A typical switch operates at Level 2, called the Data Link Layer, which controls the flow of
data between nodes. At this level, data transmits in topology-specific frames such as Ethernet.
Layer 3 switches, in essence, operate at both levels, integrating the functionality usually
associated with routers into the mechanism of a switch. Layer 3 switches is also known by
other jazzy names such as ASCI-assisted routing, zero hop routing, IP Switching, NetFlow,
tag switching, Fast IP, multiprotocol over ATM (MPOA) routing, route servers, and so on.
But in all, Layer 3 switching products fall into one of two basic types of implementation
categories:
0 Packet-by-packet layer 3 switches - These full-blown routers examine every packet
just like a router does and forward them to their destinations. They run routing
protocols such as OSPF, cache routing tables and understand the local network
topology. In function, there is little difference between routers and packet-by-packet
layer 3 switches. The contrast comes in price/performance. Packet- by-packet layer 3
switches claim throughputs of over one million packets per second (Mpps).
0 Cut-through layer 3 switches - Cut-through describes a short cut method of packet
processing. Cut-through layer 3 switches generally investigate the first packet or
series of packets to determine destination. Once destination is understood, a
connection is made and the flow is switched at layer 2 -- delivering the low delay and
high throughputs inherent in layer 2 switching.

Both techniques deliver the high throughput benefits of a flat network without broadcast and
security exposures. But each has pros and cons that should be considered:
0 Proven technology - Packet-by-packet layer 3 switches implement a known approach
to internetworking, as opposed to cut-through techniques, which is very new.
0 Performance – Since packet-by-packet technique looks at every packet, it inherently
suffers from more latency or delay in forwarding packets. But connection set-up times
and limitations of layer 2 switch forwarding technology can slow cut-through
switches as well.
0 Distributed vs. centralized - The packet-by-packet model is distributed, which
means multiple layer 3 switches in a large network. But the centralized, minimized
cut-through routing approach can become a bottleneck or single point of failure.
0 Interoperability vs. proprietary - Cut-through technology lies somewhere between
half-baked standards and quasi-open proprietary inventions, resulting in very little
interoperability among vendors. Packet-by-packet layer 3 switches can talk with any
existing router in the network -- and with other vendors' packet-by-packet switches.
*****Start TIP*****
For more information on Layer 3 switching, in particular Intel’s products, check the
company’s URL at www.intel.com/network/.
*****End TIP*****
In summary, as networking devices have gotten more complicated, the marketing language
used to describe their capabilities has gotten more fuzzy and general. No two switches are
identical, and there are many technologies to chose from that can deliver fast network
connectivity, essential to VoIP applications. Gigabit Ethernet is another concept worth to
check it out. If not for the understanding of the technology, at least so that you can
differentiate it from the resources offered by Layer 3 switches.
Introduction to Gigabit Ethernet
As PCs become more powerful, applications demand more bandwidth, and users access new
media formats such as multimedia, video, intranets and the Internet, the ability of current
network bandwidth to handle growing user needs becomes a central issue, as figure 3.25
shows.
Figure 3.25
Existing and emerging applications are driving the need for more bandwidth. (Source: Infonetics March 1996)
At the same time, new higher bandwidth solutions must be backward compatible with existing
technologies, to protect the large investments in network infrastructure. For this reason, and
others, Gigabit Ethernet is emerging as an industry standard solution for high-speed local area
networking. Intel is committed to high-performance networking with a very customer
focuses. Intel wants to provide users with better, faster, more affordable access to computing
power and information.
Intel, which plays a leadership role in network technology, brings unique strengths to the
networking arena, as it has an in-depth knowledge and expertise in the PC system, including
CPU development, PCI bus design, system architecture, and LAN connectivity hardware and
management software. Also, as a founding member of the Fast Ethernet Alliance, which
expanded the capacity of Ethernet tenfold, Intel also has the design and manufacturing
infrastructure necessary to deliver top performing products and value.
Fundamentals of Gigabit Ethernet?
Gigabit Ethernet is an extension of the 10Mbps (10BASE-T) Ethernet and 100Mbps
(100BASE-T) Fast Ethernet standards for network connectivity, as depicted on figure 3.26.
IEEE has given approval to the Gigabit Ethernet project as the IEEE 802.3z Task Force, and
the specification is expected to be complete in early 1998. There have been more than 200
individuals representing more than 50 companies involved in the specification activities to
date.
Figure3.26
Fundamentals of the Gigabit Ethernet technology.
Fully compatible with the huge installed base of Ethernet and Fast Ethernet nodes, Gigabit
Ethernet will employ all of these same specifications as to the original Ethernet specification
(defined by the frame format and support for Carrier Sense Multiple Access with Collision
Detection protocol, full duplex, flow control, and management objects as defined by the IEEE
802.3 standard). Thus, Gigabit Ethernet uses the same Ethernet technology readily in use, but
10 times faster than Fast Ethernet and 100 times faster than Ethernet.
Gigabit Ethernet Benefits
Gigabit Ethernet offers enhanced benefits that enables fast optical fiber connection at the
physical layer of the network. It provides a tenfold increase in MAC (Media Access Control)
layer data rates to support video conferencing (and VoIP), complex imaging and other data-
intensive applications. Also, as just mentioned, Gigabit Ethernet has the advantage of being
compatible with the most popular networking architecture, Ethernet. Since its introduction in
the early 1980s, Ethernet deployment has been rapid, quickly overshadowing networking
connection choices such as Token Ring and ATM.
There is no need to purchase additional protocol stacks or invest in new middleware when
deploying Gigabit Ethernet. According to IDC research projections, more than 80 percent of
installed connections were Ethernet back in 1996. IDC predicts that Ethernet will continue to
prevail, and it’s expected to continue its growth beyond 1998, particularly as this compatible
and scalable standard move to gigabit speeds. Figure 3.27 show the increased number of faster
network interface cards (NIC) sold versus standard 10Mbps.
Figure 3.27
Ethernet and Fast Ethernet NICs have shown steady cost reductions over time. Similar trends are anticipated for Gigabit Ethernet
products. (Source: Dell Oro Group)
As Information Technology (IT) departments adopt Fast Ethernet, and eventually Gigabit
Ethernet to enhance network performance to support robust desktop needs, they will see:
0 Increased network performance levels, including traffic localization and high-speed
cross segment movement
0 Increased network scaleability — it will be easier to add and manage more users and
"hungrier" applications
0 Decreased overall costs over time
The proliferation of Intel Pentium, Pentium Pro and Pentium II processor-based desktops in
corporate networks, combined with new bandwidth-intensive operating systems and
applications, has already influenced many LAN decision makers to migrate to Fast Ethernet.
This anticipated growth is based on the fact that, unlike FDDI (Fiber Distributed Data
Interface) and ATM (Asynchronous Transfer Mode), Gigabit Ethernet addresses the
bandwidth dilemma without requiring costly protocol changes.
How Gigabit Ethernet Measures Up Against Other High-speed Solutions
ATM is among some of the alternatives to enhance Ethernet performance. Although adoption
of Gigabit Ethernet does not exclude ATM as a solution within an overall LAN/WAN
architecture, according to IDC #12382, Gigabit Ethernet is rapidly emerging as the preferred
solution, as shown on figure 3.28.

Figure 3.28
Predicted growth of Gigabit Ethernet products. (Source: IDC #12382, Nov. 96)
The Gigabit Ethernet Alliance conducted a recent study and found out that the majority of
respondents plan to evaluate or deploy Gigabit Ethernet technology within the next six months
to a year, and that Gigabit Ethernet is the preferred solution for switch-to-switch connections,
catching up to ATM as the technology of choice for LAN backbones. Figure 3.29 illustrates
the criteria for this result.
Figure 3.29
Gigabit Ethernet has large preference, catching up with ATM while offering a more comprehensive solution.
Gigabit Ethernet's wider bandwidths help improve QoS, regulating the timing of latency
periods to minimize jittery video and audio delays. In the past, ATM was the only reliable way
to achieve any kind of QoS. But today, Gigabit Ethernet is rapidly closing the gap, and with
considerably more economy, backward compatibility and interoperability with other
technologies. Thus, very likely, ATM will remain at the WAN level of interconnectivity. It is
unlikely that ATM will ever move down to the workgroup or desktop, because it would
require a complete change of network interface hardware, software and management

protocols. Further, if you look at figure 3.30, Gigabit Ethernet delivers many of the benefits
originally expected from ATM, but it is much easier to be implemented, as well as cost
effective.
Figure 3.30
Gigabit Ethernet can deliver many of the ATM features, but at a fraction of the cost, and easier integration.
When comes to Gigabit Ethernet, watch Intel! Intel has established itself as a leader in the
transition to Fast Ethernet, with its family of Fast Ethernet desktop, server and mobile
adapters, print servers, hubs and switches. The PCI bus for Intel architecture PCs and servers
is tailor-made for today's power users. A 32-bit PCI implementation already pumps out data in
the multi-hundred megabits range. In the future, a 64-bit PCI bus will easily handle Gigabit
Ethernet throughput at the desktop.
Also, Intel’s ongoing relationships with key industry leaders, such as Cisco and Microsoft,
positions Intel's commitment to extending and supporting industry standards, as this
cooperation will assure compatibility with Gigabit Ethernet products that emerge from other
vendors.
What’s Next
This chapter introduced you to the basic concepts of voice over IP (VoIP) and the technologies
surrounding it. It discussed the H.323 standard as well as other standards and technologies
such as audio codecs, IP over ATM, voice over ATM, the emulation of traditional T1/E1
Trunks, IP over SONET and voice over SONET, and IP and voice over frame relay. This
chapter also introduced you to the concepts of Layer 3 switching and Gigabit Ethernet and
their role in VoIP.
The next chapter, “More on IP Multicasting,” deepens the discussion of IP multicasting by
discussing multicasting in workgroups, some of its capabilities on hosts and routers, as well as
usage and implementation, especially with VoIP.

Chapter 4
More on IP Multicasting
Multicast techniques span many areas of networking, including video and teleconferencing,
multimedia presentations, news distribution, and remote live broadcasts such as those from
space. IP multicast can run over just about any network infrastructure including Ethernet,
ATM, Frame Relay, SMDS, and satellite. For multicasting to work, multicast aware TCP/IP
stacks need to install on all the participating machines.
As discussed on chapter 2, “Understanding RSVP, IP Multicasting and ATMs,” multicasting
is connectionless, which means that a multicast datagram is neither guaranteed to reach all
members of the group nor guaranteed to arrive in the same order as it was sent. The protocol
delivers a multicast datagram to the destination group members on a best effort basis.
A best-effort basis can introduce latency and variability of delay in end-to-end paths.
However, multicast, applications require control over the quality of service (QoS) they
receive. The level of security, bandwidth, delay, jitter, error rates, cost, and compression are
some of the parameters that differentiate the network services that QoS provides. The
Resource Reservation Protocol (RSVP) is a key protocol that makes QoS possible.
The protocols and algorithms used by multicasting applications are diverse and complex.
Multicasting can be implemented at several layers of the OSI model, on different media, and
with different protocols.
*****Start TIP*****
Fore more information on IP Multicasting, please check my book, co-authored with Kitty
Niles, entitled “IP Multicasting: Concepts and Applications,” also published by McGraw-Hill.
*****End TIP*****
IP Multicast is an extension of IP. The Internet Engineering Task Force (IETF) recommended
standard, RFC 1112, defines extensions to the Internet Protocol (IP). A relatively new feature
of the Internet Protocol, IP Multicast is a protocol for transmitting IP datagrams from one
source to many destinations in a local or wide-area network. Groups of receivers participate in
multicast sessions. With IP Multicast, applications send one copy of the information to a
group address. The information reaches all the recipients who want to receive it. Multicast
technology addresses packets to a group of receivers rather than to a single receiver; it depends
on the network to forward the packets to only the networks that need to receive them.
Multicast enabled nodes that run the TCP/IP suite of protocols can receive multicast messages.
An Overview
Multicasting, as shown on figure 4.1, is a push technology where a server sends data to a client
without the client requesting it. In pull technology a client requests data from a server or from
another computer. E-mail and PointCast are both examples of push technology while the Web
is based on pull technology.
Figure 4.1
An example of mMulticasting to Multiple hosts on the Internet

Standards-based IP multicasting supports thousands of users simultaneously without
substantially affecting bandwidth requirements. In addition, IP Multicast routing protocols
provides efficient delivery of datagrams from one source to any number of destinations
throughout a large, heterogeneous network such as the Internet. If the network hardware
supports multicast, then packet destined for multiple recipients can be sent as a single packet.
There are three fundamental types of IPv4 addresses: unicast, broadcast, and multicast. A
unicast address is designed to transmit a packet to a single destination. A broadcast address is
used to send a datagram to an entire subnetwork. A multicast address is designed to enable the
delivery of datagrams to a set of hosts that have been configured as members of a multicast
group in various scattered subnetworks.
Types of Transmission
Traditional transmission methods, unicasting and broadcasting differ quite a lot from IP
multicasting. Mapping IP multicasting to LAN multicasting methods involves three separate
operations: multicast address resolution to LAN multicast addresses, copying and forwarding
of messages, and group membership registration.
A unicast address is designed to transmit a packet to a single destination. A unicast
transmission is inherently point-to-point, as shown on figure 4.2.

Figure 4.2
A basic Unicast Point-to-Point Transmission
If a node wants to send the same information to many destinations, it must send copies of the
same data to each recipient in turn. The same information must be either carried over the
network multiple times. Unicast avoids sending the data to networks where there are no
stations that need it but it does use up network bandwidth and resources. In addition, the node
needs to generate separate identical data streams for each recipient. This is very inefficient and
uses up processing power and memory.
A broadcast allows one station on the network to simultaneously talk to all devices contained
in the same broadcast domain, or subnet. Routers and switches forward broadcast but in doing
so they use bandwidth and have no way of knowing if any of the nodes on the other network
want the broadcast data. Broadcasting does not consume the sender’s resources any more than
single unicasting. However, broadcasting inefficiently consumes network resources.
Some protocols use broadcasting to discover resources from the network. To prevent
broadcast messages from flooding the network, system administrator may configure routers to
just pass or block broadcast on any particular route. Many data communication networks
restrict broadcasting to one physical or logical segment of the network.

A multicast address enables the delivery of a singe data stream to a set of hosts that have been
configured as members of a multicast group in various scattered subnetworks. Therefore,
multicasting is a method to reach several recipients by one transmission, as shown on figure
4.3. Other nodes filter out multicast packets at the hardware level. Multicasting is the process
of sending to a self-selected group of recipients that is often substantially less than the full
population of recipients. Each recipient must be defined separately and it must be possible to
control which recipients receive data. Multicast dynamic groups of recipients can be created
and removed very quickly.
Figure 4.3
Example of a Multicast Transmission
Multicast Address Translation
A multicast address enables the delivery of datagrams to a set of hosts that have been
configured as members of a multicast group in various scattered subnetworks. A class D
address is a multicast address and identifies the group of machines or interfaces that represent
a multicast group. For example, a class D address could identify all the interfaces attached to
IP network routers. All logical holders of a particular class D addresses receive packets sent to
that address
The destination address field of the IP header in a multicast IP packet contains a Class D group
address instead of a class A, B, or C IP address. A class D address is an IP address and has the
format 224.0.0.0 - 239.255.255.255.
In Class D addressing the lower 256 entries of the address range is reserved for administrative
functions and system-level routing chores. The middle range is for use by multicast end-user
applications within groups, Intranets, and the Internet. The upper range of the Class D address
set is reserved for locally administered or site-specific multicast applications, as shown on
figure 4.4.
Figure 4.4
Class D Multicast Addressing
When a local router on a subnet receives a Layer 3 multicast packet, it can map the IP
multicast address to a Layer 2 multicast address, such as an Ethernet MAC address. The
receiving host’s LAN interface hardware can efficiently read this Layer 2 address. Layer 2
LAN protocols typically reserve portions of their address space for broadcast and multicast
frames, for example, the Ethernet broadcast address FF-FF-FF-FF-FF-FF.
Address translation from the IP (layer 3) address to the layer 2 address occurs by directly
mapping the IP address into an Ethernet MAC address. This is accomplished by dropping the
low-order 23 bits of the IP multicast address into the low-order 23 bits of the Ethernet
multicast address.
Multicasting and Routing
Sending the information just once to multiple users can have large savings in bandwidth.
Copies of the message are made only when paths diverge at a router such as when the message
is supposed to be passed on to another router as well as to a workstation attached to the current
router.
Multicast enabled routers forward a multicast to a network only if there are multicast receivers
on that network. Host machines use the Internet Group Management Protocol (IGMP) to
dynamically inform a multicast aware router of any multicast sessions in which they want to
participate. If all members of a multicast group on a particular network segment leave the
group, the router ceases to froward multicast data to that segment.

IP Multicasting Uses and Benefits
In toady’s business environment large amounts of information or products need to be
delivered to multiple sites in real time. At the same time business and research needs to
retrieve large amounts of passive or static data on a daily basis. New data communication
networks have created a whole lot more capacity. The increased capacity has created new
possibilities to develop innovative services. These new services have created a need for new
transmission methods including the underlying communications infrastructure.
Currently the majority of Internet applications rely on point-to-point transmission that
traditionally has been limited to local area network applications. But business is now very
frequently, a global affair.
IP multicasting forces the network to do packet replication, which conserves bandwidth. IP
multicast is a good alternative to unicast transmissions when a company needs to deliver
applications to multiple hosts at the same time. It is important to note that the applications for
IP Multicast are not solely limited to the Internet. Multicast IP can also play an important role
in large distributed commercial networks.

Network Load Reduction
IP multicast can reduce the load on the network. If, for instance, an application needs to
periodically transmit packets to several hundred hosts within the company, IP multicasting can
be the solution. Periodic unicast transmission of these packets would require many of the
packets to traverse the same links. Multicast transmission of those same packets would require
only a single packet transmission by the source. This transmission is then replicated at forks in
the multicast delivery tree.
Broadcast transmission is not an effective solution for this type of application since it affects
the CPU performance of each and every end station that sees the packet and it wastes
bandwidth.
Internet multicasting is the only standards-based solution that can support thousands of users
simultaneously without affecting bandwidth requirements. In response to business needs
some, but not all if today’s ISPs support IP multicasting. The following list describes some but
certainty not all of the many uses for IP multicasting:
Also, IP multicasting enables the distribution of internal corporate data to large numbers of
users. A company with a chain of stores could use multicast to pricing information to cash
registers Company wide. This preserves bandwidth locally and across the network.
Multicasting multimedia data across the Internet and Intranets to multiple users is an excellent
way to preserve bandwidth. For example, providers of live real-time information feeds can use
from Internet multicasting to deliver their content. Some such providers in the United States
include CNN, ESPN, and Home Shopping Network.
VoIP and Video Conferencing
Interactive video conferencing and other VoIP applications using multicasting though the
Internet, Intranet or extranet are becoming a very economic alternative to expensive ISDN-
based solutions. IP multicasting is providing:
0 Productivity by the decreased travel time
1 Large cost benefits from saving in travel expenses
2 A large percentage of the employees rather than just a few could “stay current” by
attend video conferences
Rather than using expensive ISDN-based equipment or services, companies could use
multicast capable computers connected through the Internet, Intranet, or extranet to address
their video conferencing needs

Another important part of toady’s business computing environment is the sharing of
information through databases rather than just traditional e-mail. This can be accomplished
through Groupware applications such Lotus Notes, Microsoft Exchange, and Corel
GroupWise. The information can be in databases scattered throughout the company or the
world. Keeping the databases synchronized in all locations and updated with the most recent
information is very important. All groupware users must have the same information at the
same time.
The use of IP multicasting in this instance makes it possible to use one transmission to send
changes instantly to all the databases. All databases would instantly contain the same
information. As Niles and I examplify on our book “IP Multicasting: Concepts and
Applications,” mentioned earlier, a corporate user in Brazil, another in Finland, and yet
another in the United States could all read the same information at the same time as shown in
figure 4.5
Figure 4.5
Sharing Information Though a Groupware Network

A Word About the Multicast Backbone
The use of IP multicasting, even though its specification was published in 1989, has been
somewhat limited. A limited number of routers that support multicasting has been available on
the Internet, however, this is changing slowly. Routers in the Internet tend to be replaced by
multicast capable ones only when a new router is required to replace an old one.
In the meantime, researchers wanted a resource and test bed for testing multicasting protocols
and applications. They also wanted a way to enable the deployment of multicast applications
without having to wait for multicast enabled devices to be installed through the Internet. And
so they developed the Internet Multicast Backbone (MBONE). The MBONE supports routing
multicast packets without disturbing or altering other Internet traffic and has been in existence
for about 6 years.
The MBONE is an experimental, cooperative volunteer effort spanning several continents. It
is an interconnected set of subnetworks and routers that support the delivery of IP multicast
traffic. A virtual network layered on top of the Internet the purpose of the MBONE is to
bypass multicast unaware routers in the Internet using tunnels. To this end, the Distance
Vector Multicast Routing Protocol (DVMRP), described in RFC 1075, has been used to build
the MBONE by building tunnels between DVMRP-capable machines. The endpoints of the
tunnels are entered manually in routing tables and administrated in the MBone. Figure 4.6
describes tunneling.
Figure 4.6
MBONE Tunneling
Simply put, MBone is constructed with tunnels across networks that do not support multicast
routing. The tunnels allow multicast traffic to pass through the non-multicast-capable parts of
the Internet. The MBONE mostly uses encapsulated tunnels between multicast-capable islands
of the Internet to move multicast data. An IP multicast packet traversing an encapsulated
tunnel is characterized by its IP source and destination addresses being the IP addresses of the
tunnel endpoint multicast routers. Figure 4.7 is a simplified representation of the MBONE
showing the concept of multicast-capable islands.
Figure 4.7
Internet MBone
Since the MBONE and the Internet have different topologies, multicast routers execute a
separate routing protocol to decide how to forward multicast packets. Most of the MBONE
routers currently use DVMRP. There are some portion of the MBONE however, that execute
either Multicast OSPF (MOSPF) or the Protocol-Independent Multicast (PIM) routing
protocols.
DVMRP is a protocol for routing multicast datagrams through an Internet and implements its
own unicast routing protocol in order to determine which interface leads back to the source of
the data stream. This unicast routing protocol is based purely on hop counts. Because of this,
the path that the multicast traffic follows may not be the same as the path that the unicast
traffic follows.
Nowadays the IEETF, NASA, and research groups world wide use the Mbone for research
and testing of multicast protocols and services, for multicast multimedia recordings of
meetings and live space events across the Internet, and for desktop conferencing. Even live
concert performances have been multicast over the MBONE. The number of sites
participating in the MBONE has grown rapidly. As an experimental and volunteer effort, the
MBONE has limited its use in commercial environments.

The Capabilities of Multicasting
IP multicast capable network forwards multicast packets according to group address of the
packet. Network routers that support multicast keep track of which parts of the network have
multicast hosts joined to particular groups. Routers forward multicast packets only to
subnetworks that have IP multicast capable hosts joined to the particular group. Multicast
capable hosts and routes have certain requirements.
RFC 1112 describes the IP multicast extensions to the standard IP protocol. Three levels of
conformance to this standard exist. A level 0 host has no support for IP multicasting and
multicast activity has no affect on them.
To provide level 1 multicasting, a host IP implementation must support the transmission of
multicast IP datagrams. At level 1, hosts can only send multicast datagrams. Level 1 allows a
host to partake of some multicast-based services, such as resource location or status reporting.
A level 1 host cannot receive multicast datagrams.
To provide level 2 multicasting, a host must also support the reception of multicast IP
datagrams. At level 2 host have full support for IP multicasting. Hosts can join and leave
multicast groups and receive multicast datagrams sent to group addresses. Level 2 requires
implementation of IGMP and extension of the IP and local network service interfaces within
the host.
The most important part of host IP multicast support implementation is Internet Group
Management Protocol (IGMP). Both IGMP and ICMP reside in the IP layer. IGMP's function
is to keep neighboring multicast routers informed of the host group memberships present on a
particular local network and to provide the mechanisms by which hosts and routers can join
and leave IP multicast groups. The mapping of IP addresses to local network addresses is
considered to be the responsibility of local network modules.
IGMP1 uses the reserved multicast group address 224.0.0.1 to communicate with local routers.
Called the “all hosts group”, this multicast group addresses all hosts in the local LAN. It is
through this channel that IP multicast routers learn if any hosts are joined to a multicast group
in this particular LAN. Routers send IGMP queries to this address at the local LAN and hosts
respond by telling, which groups they want to join.
The mapping between a Class D IP address and Ethernet MAC-layer multicast address is
obtained by placing the low- order 23 bits of the Class D address into the low-order 23 bits of
IANA's reserved MAC-layer multicast address block. Mapping from class D group address to
MAC address is not one to one, because high 5 bits of class D group address are discarded.
IP multicasting is an extension of Link Layer multicast to IP Internets. Using IP multicasts, a
single datagram can be addressed to multiple hosts without sending it to all. An IP datagram
1
The IGMP protocol has been updated and is available in RFC 2236 by W. Fenner, “Internet Group
Management Protocol, Version 2”, November 1997
sent to the group is delivered to each group member with the same best-effort delivery as that
provided for unicast IP traffic.
Forwarding of IP multicast datagrams is accomplished either through static routing
information or through a multicast routing protocol. Devices that forward IP multicast
datagrams are called multicast routers. They may or may not also forward IP unicasts. Routers
forward multicast datagrams on the basis of both their source and destination addresses. An IP
multicast packet traversing an encapsulated tunnel such as in the MBONE is characterized by
its IP source and destination addresses being the IP addresses of the tunnel endpoint multicast
routers.
In response to the growing need for multimedia applications and real-time data distribution,
network layer multicast services are being built into today's high-end routers, routing hubs,
and network switches. Some new routers have native multicast packet routing. Multicast
capable routers communicate with neighboring multicast routers and exchange information
about group membership and network topology. However, there are lots of routers that cannot
route multicast packets correctly.
A host sends a multicast message out onto a host network where multicast enabled routers
picked it up and forwards the message to the appropriate group. Routers keep track of
multicast groups dynamically and build distribution "trees" that chart paths from each sender
to all receivers. Multicast routers need to be able to execute a multicast routing protocol that
defines delivery paths that enable the forwarding of multicast datagrams across an
internetwork.
Routers refer to the specific tree that it built for a sender when it receives traffic from that
sender for a multicast group. The IP standards bodies have designed several routing protocols
that can build the distribution trees for multicast traffic and multicast routers must support one
or several of these protocols.
The current routing protocols for multicast include the:
0 Distance Vector Multicast Routing Protocol (DVMRP) which is an interior gateway
protocol,
1 Multicast Open Shortest Path First (MOSPF) protocol which is an extension to the
OSPF link-state unicast routing protocol
2 Protocol Independent Multicast (PIM) protocol that enables networks running any
unicast routing protocol to support IP multicast. PIM has two modes dense and
sparse.
Usually multicast protocols can be layered on top of existing multiprotocol backbones with a
software upgrade to existing routing devices. Ideally, network routing devices should provide
all of these standards: IGMP, DVMRP, MOSPF, and PIM thereby allowing the widest range
of multicast operations and interoperability.

The most common multicast routing protocol is DVMRP, which works by first broadcasting
to all reachable multicast routers. When no members are connected to a branch, the branch is
pruned from the tree as shown in.figure 4.8 The broadcast from the source can reach a router
from several directions. The multicast router selects the shortest of the routes to the group
members.
Figure 4.8
Pruning a Multicast Delivery Tree
Multicast Routing with IP
The multicast capable network shown in figure 4.9 consists of LANs with native multicast
support connected by IP multicast capable routers.
Figure 4.9
IP Multicast Internet Routing

In figure 4.9 example, Host A can address the host group by addressing the host group's Class
D address. When Host A sends the message out onto its network, the multicast routers pick up
the message and forward the multicast transmission to the appropriate subnets.
Each physical network can have several multicast capable routers. Network protocols select
one of them as the designated router for the network. The designated router then
communicates with other designated routers in neighboring networks to construct a spanning
tree for each multicast source. This procedure is called Reverse Path Multicasting (RPM).)
Datagrams from the source host to other group members travel over this spanning tree. A
spanning tree is loopless and guarantees the shortest possible route to the receiver.
The copying of the message is done by the multicast method of the LANs involved. In this
case all LANs support native multicasting and the multicast transmission takes the same
bandwidth on host A's network as a single copy, regardless of how many clients are members
of the host group on the other side of the internet. Even if not all LANs have native multicast
support, the added cost of transmitting copies will be limited to a single LAN.
When IP multicasting support is added to the IP layer several potential problems need to be
resolved. The major issues include resolving IP multicast address to LAN (multicast)
addresses, copying and forwarding of messages, and registering host group membership.
Older TCP/IP implementations are apt to have no support for sending or receiving multicast
transmissions. Such an implementation discards packets addressed to multicast address as
being corrupt or invalid.
For a host to be able to send to a multicast address the IP protocol implementation must
support a mapping from the host group address to the corresponding multicast LAN address.
This mapping is analogous to Address Resolution Protocol (ARP) mappings ARP where host
group addresses are resolved to LAN addresses.
IGMP needs to be implemented so hosts who want to can join host groups and listen to
multicast messages. IGMP informs local multicast routers that a host is a member of a
particular multicast group. You should note that:
0 Hosts on an Internet capable of sending to a multicast address can send packets
addressed to a host group address.
1 Processes running on hosts capable of receiving multicast packets can join host
groups, after which the process receives all transmissions sent to that host group
address.
2 The routing of IP multicast packets requires special functions that are absent in
unicast IP-routers.
Multicast router functions can be located on an IP-host. Multicast routers forward multicast
transmissions for hosts outside the LAN to the next IP multicast capable router using a unicast
tunneling method. Tunneling is the encapsulation of multicast packets using a unicast IP-
header between two multicast routers.
IP Multicast Enabled Multimedia Applications
Multimedia applications are capable of streaming full-motion video, audio, and animated
graphical content to the desktop. Other multimedia applications are real-time interactive
applications, such as desktop video, collaborative engineering, and shared white boards.
Multimedia applications and real-time interactive applications such a video conferencing use
lots of bandwidth. The importance of clear picture and hi-fi quality voice should not be
underestimated even in standard every day videoconferences.
Sometimes there is a need to transmit stored data streams to very large numbers of recipients.
Examples here could include updates of Web caches or corporate announcements to
employees. In this case, using IP multicast enabled applications would be beneficial and cost
effective.
IP multicast can unite collaborative workgroups and help in the realization of the full potential
of these new applications to the workplace.

IP Multicast Enabled Information Distribution Applications
Information distribution applications benefit from the use of IP multicasting. This category of
application can provide real time news and financial services to the desktop users who
subscribe to them.
Non-multimedia applications that involve the transfer of large databases of information can
benefit from IP multicast. Sometimes there is a need to transmit stored data streams to very
large numbers of recipients. Examples here could include updates of Web caches or corporate
announcements to employees. In this case, using IP multicast enabled applications would be
beneficial and cost effective.
**** Start TIP ****
The IP Multicast Initiative also can provide information about IP multicast technologies,
product, and services. Don’t hesitate to visit their Web page at http://www.ipmulticast.com or
to contact them at: Stardust Technologies, Inc., 1901 S. Bascom Ave, #333, Campbell, CA
95008 USA - Tel: 408-879-8080 - Fax: 408-879-8081
****End TIP ****

IP Multicast Initiative recommends:
0 A phased approach to evaluating and deploying IP multicast including deploying IP
multicast on the Intranet before deploying it on the WAN.
1 A network analysis and user profile to determine the benefits and cost of
implementing IP multicasting for the company
2 Examination of several alternative plans for the deployment of multicast-based
applications over a WAN and the use of transitional approaches such as tunneling.
3 The use of a test-bed evaluation of both LAN and WAN implementations in house or
at a vendors site
4 Staff training in IP multicast network administration and diagnosis
5 The choice of IETF standards-based products designed for native IP multicast.
The IP Multicast Initiative web site has a technical resource center that provides more
background and in-depth information.
When deployeing IP Multicasting; make sure that:

0 The sending and receiving node’s operating system and TCP/IP stack support
multicast and the Internet Group Management Protocol (IGMP). The latest versions
of Unix, Windows NT, and Windows 95 accommodate the TCP/IP stack, IP
multicasting, and IGMP.
1 Each node’s network adapter driver implements multicasting. Newer adapters and
network drivers have built in support for IP multicast.
2 Routers, bridges, and switches in the network support multicasting at the IP layer.
Many new routers already support IP multicast; others may require an upgrade. Wide
ranges of network equipment vendors have IP Multicast ready products available.
3 Choose protocols carefully. Depending on the underlying routing protocol different
protocols may apply.
4 Applications to be used must be multicast-enabled. Standards are being developed
and incorporated into applications for enhanced services, like reliable and real-time
delivery of IP multicasting traffic.Use IP multicast upgrade and enhanced application
program interfaces (APIs) available on the market to add IP multicast to applications.
IP multicasting APIs include Berkeley sockets multicast API and the Winsock API for
Windows applications.
IPv4 versus IPv6: The Multicast Addressing
Issues
The IPv6 protocol fully supports IP multicast. As IPv6 becomes implemented in more and
more nodes connected to the Internet, multicasting will be integrated. Its use will no longer be
limited to local networks and experimental Internet implementations.
*****Start TIP*****
For more information on IPv6, please check my book, co-authored with Kitty Niles “IPv6
Networks,” also published by McGraw-Hill.
*****End TIP*****
IPv6 Multicast addresses have the format shown in figure 4.10. A multicast address can be
assigned to a single system, restricted to a specific site, associated with a particular network
link, or distributed worldwide. Multicast addresses must not be used as source addresses in
IPv6 datagrams or appear in any routing header. A value of FF (11111111) identifies an

address as a multicast address. The IPv6 multicast address has three other fields, the Flgs field,
Scop field, and Group ID field.
Figure 4.10
Multicast Address Format
Low order bit of flags indicates permanently or non-permanently-assigned multicast address.
Other flag bits are zero. The Scope field limits the scope of the multicast group. Possible scope
values include node-local, link-local, site-local, organization-local, and global scope. Non-
permanently-assigned multicast addresses are meaningful only within a given scope.2
Mapping of IPv6 multicast addresses to Ethernet MAC addresses is similar to IPv4 mapping,
but the low order 32 bits of group addresses are mapped to MAC address instead of low order
23 bits in the IPv4 specification.
2
For more information about IPv6 addressing, see RFC 1884, S. Deering, and R. Hinden, “IP
Version 6 Addressing Architecture”, December 1995
What’s Next
This chapter discussed multicasting in workgroups, some of its capabilities on hosts and
routers, as well as usage and implementation, especially with VoIP. The next chapter, “IP
Superhighway,” introduces the basic concepts of voice over IP, and its most used H.323
standard. It also discusses other standards and technologies such as audio codecs, IP over
ATM, voice over ATM, the emulation of traditional T1/E1 Trunks, IP over SONET and voice
over SONET, and IP and voice over frame relay. Further, this chapter discusses Layer 3
switching and gigabit Ethernet as well as their role in VoIP.

Chapter 5
More on ATM Technologies
This chapter provides you with a more in-depth discussion of ATM technologies and the IP
protocols supporting ATM. This topic is very important so that you can understand the
features (and limitations!) of using IP over ATM, and more specifically, voice over IP (VoIP).
This chapter is based on a contribution made by Phillip Emer, the Associate Director
Advanced Technology Development from North Carolina State University. I thank him for his
contribution and deep knowledge on the subject of ATMs and its applications.
For more information on this subject, or if you would like to contact Phil, please do so by e-
mail at phil@ncstate.net.
*****End NOTE*****
Describing ATM Services and Support
The layered approach to describing ATM, as shown on figure 5.1, stresses the interactions
between the many layers and sublayers and the passing of service data units up and down the
layered stack. This kind of approach explains how ATM software and hardware components
come together to form an ATM node.
Figure 5.1
Describing an ATM
The peer approach to describing ATM addresses the peer-to-peer operations between ATM
devices. This approach stresses the functions provided by ATM hardware and software and
how these functions interact to support an ATM network. As shown on figure 5.2, the main
characteristics of ATMs relevant to ATM network designers and to the peer approach to ATM
in general are:
0 Connection-oriented, point-to-point
0 Integrated services - voice, video, data
0 Supports quality of service (QOS)
0 Scales to gigabit speeds
0 Uses 20-byte addressing.
Figure 5.2
Relevant ATM characteristics
Let’s take a look in those characteristics.

Connection-Oriented Support
Connection-oriented systems (e.g., POTS, ISDN, X.25, TCP, and ATM), as shown on figure
5.3, establish connections between a pair of communicating systems. In the phone system a
connection is associated with a physical dedicated link. In ATM, a connection is a virtual link
(circuit) which is characterized by a Class of Service that it must deliver to the users of the
circuit (e.g., a constant bit rate service for uncompressed voice over ATM).
Figure 5.3
A layout of connection-Oriented ATM systems
Connection oriented systems support a set of protocols for transmission of data and another set
of protocols for establishing connections (e.g., SS7, Q2931). End systems request that the
network establishes a connection by sending messages to the network over a pre-defined
control channel (circuit). Once the network has established a data channel (circuit) per the
request, data is forwarded over that channel. Connections may be established by a network
manager as Permanent Virtual Circuits (PVCs) or may be dynamically established by system
software as Switched Virtual Circuits (SVCs).

Integrated Services Support
As ATM is the outgrowth of broadband ISDN (Integrated Services Digital Network),
integrated services support was a design consideration from the start. It is worth noting
though that many technical compromises were necessary to support three very different
network traffic categories. The result of these compromises, as listed on figure 5.4, is that
ATM supports the combination of voice, video and data optimally - not necessarily the
individual services.
Figure 5.4
ATMs support integrated services
Voice Support
Voice is supported in an ATM network via circuit emulation, via circuit switching, or as data.
Circuit emulation is a migration path supporting emulation of T1-style WAN circuits, as
shown on figure 5.5. In general many voice circuits are mapped to single ATM PVC. Voice
compression, network echo cancellation, and silence suppression mechanisms may be added
as enhancements for bandwidth efficiency. Optimal support of voice would map traditional 64
kbps voice circuits dynamically to ATM circuits (SVC’s).
Figure 5.5
ATM’s voice support via circuit emulation
Also, voice is supported on IP platforms as data. Some of the same coding, compression, and
echo cancellation techniques are applied here as in the circuit emulation case.
Video Support
Video is supported, as shown on figure 5.6, as real-time, non-real-time, and as data. Real-time
video applications include video conferencing and live video broadcasts. Support of real-time
video levies strict delay requirements on the ATM network (actually strict delay variation - or
jitters - requirements).
Figure 5.6
ATMs support video as real-time and non-real-time

Non-real-time video applications such as video-on-demand use application level techniques -
namely buffering - to account for inconsistent delays encountered during transit through the
ATM network. Thus, the ATM network need not be responsible for ensuring low delay
variation requirements (at least not as strictly as in the real-time case.
Nonetheless, video over ATM is a bit more complicated discussion than voice, since video
terminals are actually audio/visual terminals, that is, voice and video are related and must be
kept synchronized. Figure 5.7 illustrates a simple representation of a broadband (ATM) video
terminal (H.310 in ITU jargon).
Figure 5.7
A simple representation of a broadband (ATM) video terminal (H.310 in ITU jargon).
Data Support
Data can be supported, as shown on figure 5.8, at various level:
0 LAN
0 IP
0 Multi-protocol
0 Native
Figure 5.8
Data support on ATMs
The idea of supporting data over ATM is that you need a migration path since data
applications are tied very much to platforms, operating systems (OS’s), application
programming interfaces (API’s), and protocol stacks (e.g., IP, IPX, Appletalk), as shown on
figure 5.9:
1. First, software shims are added around low layer API’s (close to device drivers - the
effect is hiding ATM from existing applications and protocols (users).
2. Then, low layer and higher layer API’s are enhanced to incorporate software shim
function and to expose ATM features to existing stacks.
3. Finally, a new stack and new data applications emerge - all of which are ATM-aware.
Figure 5.9
ATM’s data support requires a migration path since data applications are very tied to platforms..
Quality of Service Support
As figure 5.10 outlines, ATM supports Quality of Services (QoS), enabling end-to-end
integrated service support, guaranteeing performance to connections and service classes
(queues), including:
0 constant bit rate (CBR)
0 variable bit rate (VBR) - real-time and non-real-time
0 unspecified bit rate (UBR)
0 available bit rate (ABR)
Figure 5.10
ATMs Quality of Service (QoS) support
ATM technology is also scalable to gigabit speeds (as figures 5.11 and 5.12 outlines). ATMs
also use 20-bits addressing, as shown on figure 5.13:

0 Network Service Access Point (NSAP) prefix identifies an ATM network
0 End System Identifier (ESI) identifies a device on an ATM network
0 Selector (Sel) allows a device with a single ATM interface to have multiple ATM
addresses
Figure 5.11
ATM support scaled to gigabit speeds
Figure 5.12
ATMs Quality of Service (QoS) support
Figure 5.13
ATM address format
ATM network addressing is similar to Novell Netware network addressing in that the end
system has an address with two distinct pieces - a network piece and a local piece, as shown
on figure 5.14. It turns out this is a nice feature especially when analyzing and troubleshooting
a network. Since ATM addresses are made up of a network part and a local part, a
misbehaving client can be tracked down easily based on its ATM address.
Figure 5.14
ATM network addressing is similar to Novell Netware network addressing
Try to contrast this to a misbehaving IP network host. The IP addressing scheme is totally
distinct from the local (LAN) addressing scheme - so knowing an IP address is not enough to
isolate a misbehaving client in this case (you need to know the local address of the client).
Figure 5.15 shows that an ATM address can be represented in a naming format much like an
IP address. Note that ATM device names will use the same domain name services (DNS) that
IP hosts use - with an extension that maps 20-byte local addresses to a name.
Figure 5.15
An example of a hierarchical addressing structure
As is the case for IP addresses, there is a process in place for network managers to acquire
unique network name and address space. In the case of ATM there are several registration
authorities from which one can acquire ATM code points (in the US) - namely, the National
Institute of Standards and Technology (NIST) and the American National Standards Institute
(ANSI). Basically, ANSI or NIST assigns a 3-octet organization identifier (ORG) code point.
This ORG field follows 4 octets of identification bits, which identify the country and
registration authority (e.g., ANSI). Thus, once an organization obtains and ORG value, the 7
most significant octets of the ATM address uniquely identifies the ATM network of that
organization. The owning organization is then responsible for the encoding of the remaining 6
octets in the ATM network part of the ATM address. Recall that the least significant 7 octets
of the ATM address are locally (client) significant and associated with the ATM client device.
Summary
In summary, as figure 5.16 wraps it up,
0 ATM is flexible – provides integrated services
0 ATM is scaleable – enables SONET transmission, 20-byte addressing
0 ATM is available!
Figure 5.16
Summary of benefits of ATM technologies
ATM Networking
When comes to deploying ATM networks, there are several models you can adopt. Figure
5.17 outlines the main models:
0 The End-to-end ATM model
0 ATM Desktop Model
0 ATM Campus Model
0 ATM WAN Model
0 ATM Carrier Model
Figure 5.17
ATM networking: a list of the main models
Let’s discuss a little more about each model

The End-to-end ATM Model
If you remember, from earlier in this chapter, one of the relevant characteristics of ATM is that
it supports integrated services. ATM can support voice, video, and data in the campus, in the
WAN, in the carrier network, and in residential access networks, as figure 5.18 and 5.19
portraits.
Figure 5.18
The End-to-end ATM model.
Figure 5.19
An outline of the applications of End-to-end ATM model.
At the moment ATM is implemented in Campus, WAN, and Internet backbones, as depicted
on figure 5.20. Figure 5.21 provides the status End-to-end ATM at glance. There have been
some ATM-based trials in residential access environments (cable modems and ADSL) -
commercial services are likely to roll out over the next year mainly for Internet access.
Figure 5.20
At the moment, ATM is being implemented in Campus, WAN, and Internet backbones.
Figure 5.21
Status of ATM End-to-end deployment to date
The ATM Desktop Model
In the ATM desktop model, as depicted on figure 5.22, workgroup switches are replacing
Ethernet hubs. Category 3/5 cabling are being used for the LAN emulation in providing
migration path. Also, old applications are being re-written to take advantage of QoS, thus
enabling high quality video and voice to join data. Figure 5.23 provides a status of ATM
desktop model implementations.
Figure 5.22
The ATM desktop model
Figure 5.23
Status of implementations of ATM desktop model

The Campus Backbone Model
Campus backbone models are using ATM switching to replace FDDI in the backbone. Video
and voice networks are migrating to ATM as data network is flattened. We also see that
VLANs obviate the need for routing, as switched virtual circuits dominate. Figure 5.24
provides an outline of these applications and figure 5.25 provides a status of their
implementation.
Figure 5.24
The ATM campus backbone model
Figure 5.25
Status of implementations of ATM campus backbone model

The WAN Model
In the WAN model, as shown on figure 5.26, the idea is to replace TDM type multiplexors
with ATM edge switches. These Edge switches support adaptation of LAN data traffic and
PBX voice traffic to ATM.
Figure 5.26
The ATM WAN model
Also, the idea here is to use the same WAN links to carry voice and data - ATM will allow for
running these links at much higher utilization due to the QoS and backbone WAN (BW)
management capabilities inherent in ATM. The ATM adaptation for voice in this case comes
in two flavors: uncompressed constant bit rate, and compressed (e.g., ADPCM, CELP)
variable bit rate.
WAN network managers are accustomed to the “over-subscription” method of BW
management. Moving to ATM in this arena requires a departure from this inefficient method
of BW management, as depicted on figure 5.27, like any paradigm shift it will take time.
Figure 5.27
Status of ATM WAN deployment
ATM Carrier Model
Voice in the carrier model means switching voice circuits as ATM circuits, unlike the WAN
ATM voice scenario, as depicted on figure 5.27, which may switch many voice circuits over a
single ATM circuit.
Figure 5.28
ATM carrier model
Figure 5.29 shows the status of implementations over ATM carrier models. Time Warner
implemented an ATM-based, interactive, video-on-demand service, as a trial, in Orlando,
Florida. In that trial ATM circuits terminated in a set-top box - ATM transported MPEG2
video to the set-top. Time Warner found that it is better to use ATM switching in the carrier
network and use MPEG2 as the transport for video. Another perhaps more important finding
was that users are not willing to pay enough money for interactive television to justify large-
scale implementation of such systems. Instead, carriers, telcos, and cable companies are
focusing on offering Internet-based interactive services to the home. Much of the work in this
area employs ATM switching and in some cases ATM connections to the home. The Remote
Broadband working group in the ATM Forum writes specifications for ATM-based residential
networking (e.g., atm-based cable modems and ADSL).
Figure 5.29
ATM carrier model implementation status
In summary, as figure 5.30 wraps up:
0 Ethernet dominates desktop access
0 IP dominates as data transport
0 IP transports voice and video as data
0 ATM switches IP
0 Adaptation devices at the edge of ATM networks “adapt” voice, video, and data
individually to optimally flow across ATM networks

Figure 5.30
Summary of ATM carrier model deployment
IP Over ATM Requirements
As IP is the dominant network layer data protocol - ATM network designers are clearly
interested in the requirements associated with using ATM as a transport for IP data. More
specifically, we are interested in how IP uses the services of ATM (or perhaps more correctly -
how to hide the characteristics of ATM from IP).
In general, as shown on figure 5.31, emerging “IP Over ATM” (IPoATM) protocols must
address:
0 Encapsulation (and multiplexing),
0 Emulating point-to-point links (no more shared media),
0 Establishing connections (since IP is connectionless),
0 Integration with legacy networking, and
0 Internetworking (routing issues).

Figure 5.31
IP over ATM requirements
Encapsulation issues include how packets are mapped to cells and how the IPoATM protocol
recognizes a stream of ATM encapsulated packets. Emulating a pt-to-pt link means treating a
virtual circuit as a dedicated link. Establishing connections involves resolving IP
characteristics into ATM connections in support of unicast and multicast operation.
Integration with legacy networking involves bridging and gateway strategies. Finally,
internetworking in the IPoATM context involves defining “a network” and providing a
mechanism for communications between these networks (i.e., routing).
The Internet Engineering Task Force (IETF) and the ATM Forum, as discussed on chapter 3,
“IP Superhighway,” are contribution-driven groups dedicated to the promotion of openness
and interoperability in the IP and ATM marketplaces, respectively. On figure 5.32 and 5.33 it
is easy to note that both the IETF and the ATM Forum create interoperability specifications,
although both groups argue that they do not write standards.
Figure 5.32
IP over ATM specifications

Figure 5.33
The data protocols
Figure 5.34 provides a layered model to illustrate the similarities and differences between the
pot-luck of IPoATM protocols.
Figure 5.34
The ATM data model
ATM Network Services
An ATM backbone network must at minimum support a signaling service, as shown on figure
5.53. Such a signaling service allows for clients (users) to establish connections across the
connection-oriented ATM “cloud”. At present there are two signaling services available for
campus ATM backbones - the ATM Forum defined UNI signaling and the IETF (Ipsilon)
defined general switch management protocol. All switches support UNI signaling and many
(not all) support GSMP signaling as well.

The ATM network may also support address resolution services, multicast services, routing
services, etc. - in general, services necessary to support legacy LAN applications (e.g., IP
applications like ftp and Telnet).
Figure 5.35
ATM network services
In an ATM environment virtual circuits emulate links, as shown o figure 5.36. Virtual circuits
then act as virtual links, which implies virtual ports and logical networks. At the IP layer the
logical view of the network may be quite different from the physical topology.
Figure 5.36
ATM routing functions
As we deploy fast LAN switching at the access point of the network and fast ATM switching
at the core of the network, the software intensive IP functions performed by routers is clearly
the bottleneck. Recognizing that IP routing function is required, we look to avoid forwarding
packets through routers while benefiting from routing services.

ATM Client/Server Accessibility
Figure 5.37 describes ATM’s client/server accessibility. Note that this is not an exhaustive list
of client devices. There are other ATM attached devices that perform adaptation such as the
cells in frames attachment device (CIF-AD), which works in concert with Ethernet clients to
provide an ATM over Ethernet function. An ATM concentrator is an example of an ATM-
attached device that performs no adaptation (ATM WG switches are used in place of these
devices today).
Figure 5.37
ATM’s client/server accessibility
Other interesting access devices include cable modems, xDSL modems, and inverse
multiplexing access devices. But if we take a look at the list of interoperability data protocols
of figure 5.38, and pin down the RFC 1483, Multiprotocol Encapsulation, notice that routers
are the only ATM-attached devices in this model, as illustrated on figure 5.39
Figure 5.38
RFC 1483, Multiprotocol encapsulation

Figure 5.39
Diagram of RFC 1483
Also notice on figure 5.40 that, RFC 1483 defines an encapsulation method for supporting
multi-protocol encapsulation over ATM AAL5. RFC 1483 provides two methods for
supporting this encapsulation. First, LLC/SNAP encapsulation, which uses IEEE 802.2 SAP
headers for multiplexing, protocols over a single ATM circuit. The second method proposes
distinct virtual circuits for each protocol.
Figure 5.40
RFC 1483 especification
If we look at RFC 1577 (see figure 5.41), Classical IP (CIP), notice that the ATM backbone
supports several services in addition to signaling, as described on figure 5.42. CIP relies on an
one-armed router for routing services. CIP also requires a router for communication with
legacy LAN devices, which makes sense since CIP supports only IP. Thus, LAN clients, such
as servers and workstations, communicate with CIP clients through a router. Also keep in
mind that CIP is a mechanism supporting unicast IP over ATM which requires one-armed
router function for communication between CIP subnets.
Figure 5.41
RFC 1577, Classical IP
Figure 5.42
A diagram of a Classical IP (CIP)
ATM Classical IP Services
Classical IP services provide a means of mapping connectionless protocols, namely the IP
protocol, in to a connection-oriented backbone environment. To this end CIP provides an
ATM service for resolving IP addresses into ATM addresses - thus allowing CIP clients to
establish a connection to a destination IP host by using the ATM network’s signaling service.
For IP multicast support over ATM, RFC 2022 provides a mechanism for mapping IP
multicast addresses to ATM multipoint circuits, as shown on figure 5.43.

Figure 5.43
An overview of ATM CIP services
An one-armed router provides routing services for the ATM backbone, as described on figure
5.44. An one-armed router can also provide routing services between CIP logical IP subnets
by becoming a member of each logical IP subnet (LIS). Note that a logical IP subnet is defined
by a set of hosts registered with the same ARP server.
Now, an one-armed router is so-named because it attaches to the ATM backbone via a single
ATM physical link. The router then associates logical ports with the lone ATM interface by
joining logical IP subnets. There is then a virtual link associated with each logical port.
Figure 5.44
Classical IP routing services
Legacy IP subnets and hosts, as shown on figure 5.45, communicate with CIP subnets through
an ATM-attached router by emulating a point-to-point link using RFC 1483 encapsulation.
Figure 5.45
Classical IP clients
Remember that the classification of RFC 1577 given here applies to RFC 1577 alone. By
adding functions specified in new RFC’s and Internet drafts into RFC 1577 networks, one can
build a more complete system - though other protocols, specially MPOA, integrate all of these
functions into a single specification.
The Next Hop Resolution Protocol (NHRP)
The ATM backbone supports several services in addition to signaling the Next Hop
Resolution Protocol (figure 5.46) is one of them. NHRP adds cut-through routing as an ATM
service. LAN clients communicate with NHRP clients through a router, as diagrammed on
figure 5.47.
Figure 5.46
ATM backbone supports the Next Hop Resolution Protocol
Figure 5.47
NHRP adds cut-through routing as an ATM service

NHRP enhances CIP function by adding “shortcuts” as outlined on figure 5.48. That is, the NHRP
routing function is provided as a function of the ATM backbone. This routing function allows NHRP
clients which are members of different LIS’s to establish a “shortcut” path through the ATM cloud -
recall that with CIP a one-armed router must forward packets between LIS’s.
Figure 5.48
ATM’s NHRP services
Additionally, NHRP can be deployed in an ATM-based IP backbone, as shown on figure 5.49.
In this situation, NHRP provides a short-cut path from one edge of the IP cloud to the other -
avoiding interior routing hops. NHRP requires the same address registration function as CIP,
as shown on figure 5.50, and adds distribution of address resolution across LIS boundaries
Figure 5.49
NHRP routing services
Figure 5.50
NHRP clients
ATM Forum LAN Emulation
The ATM backbone supports several services in addition to signaling. The ATM Forum LAN
emulation (figure 5.51), also know as LANE, is another one. LANE relies on a one-armed
router for routing services. It employs a router for communication with the Internet, as
described on figure 5.52. LANE clients can be LAN switches and ATM-attached stations.
Figure 5.51
LAN emulation (LANE)
Figure 5.52
Diagram of a typical LANE
ATM LANE services, as shown on figure 5.53, provide the means of mapping a
connectionless, multicast-capable LAN in to a connection-oriented backbone environment.
Thus, LANE provides an ATM service for resolving LAN MAC addresses into ATM
addresses - thus allowing LANE clients to establish a connection to a destination LAN station
by using the ATM network’s signaling service. Additionally, LANE provides a mechanism
for mapping LAN multicast (address-based) into ATM multicast (tree-based) - the broadcast
and unknown server (BUS).

Figure 5.53
ATM LANE services
As for LANE routing services, as described on figure 5.54, is an one-armed router that
provides routing services for the ATM backbone. An one-armed router can provide routing
services between LANE emulated LANs (ELANs) by becoming a member of each ELAN.
Note that an ELAN is defined as the set of hosts, which register their MAC and ATM address-
pair with the same LANE server.
Figure 5.54
LANE routing services
As for LANE clients, LANE was designed as migration protocol, allowing ATM-attached
stations to communicate with each other using applications written for connectionless
environments, as shown on figure 5.55. Additionally, LANE was designed to support bridged
communications between legacy stations over an ATM backbone. The intent truly was that
this be a migration technology - employed only to allow for graceful switch over to an ATM
desktop solution with LAN applications re-written to the native ATM API. The fact is, there
are still no native ATM applications (well other than LANE itself). LANE is now being re-
marketed (and re-designed) as an ATM-based, bridged VLAN solution.
Figure 5.55
LANE clients
ATM Forum Multiprotocol Over ATM (MPOA)
The ATM Forum Multiprotocol over ATM (see figure 5.56) is identical to LANE, with the
addition of cut-through routing service added as an ATM network function, as shown on
figure 5.57.
Figure 5.56
ATM Forum Multiprotocol Over ATM (MPOA)
Figure 5.57
MPOA’s diagram
ATM MPOA services, as shown on figure 5.58, provide a means of mapping connectionless,
multicast-capable LAN environments, and Intranets into connection-oriented backbone
environments. Thus, MPOA provides ATM services for resolving LAN MAC addresses and
network addresses into ATM addresses, allowing MPOA clients to establish a connection to a
destination station or host by using the ATM network’s signaling service. Additionally,
MPOA provides mechanisms for mapping LAN multicast into ATM multicast (tree-based).
Figure 5.58
ATM MPOA services
MPOA adds NHRP to the LANE one-armed router. In addition, there is a mechanism for
distributing and caching shortcut (cut-through) addressing information to MPOA clients.
MPOA clients then can perform layer 3 packet forwarding functions and cut-through the
ATM network - avoiding router hops along the way.
In LANE, as shown on figure 5.59, the one-armed router acts just as a traditional router
performing packet forwarding and route processing, but only with logical ports, instead of
physical ports. MPOA adds NHRP function to these one-armed routers. By adding NHRP,
the one-armed router sheds the responsibility of steady-state packet forwarding, which is now
handled by clients directly since NHRP allows for the establishment of shortcuts between
MPOA clients. Thus, MPOA defines a distributed routing solution, separating routing
function from packet forwarding function.
Figure 5.59
MPOA routing services
As for MPOA clients, just as NHRP enhances, actually replaces, CIP with shortcut routing,
MPOA is LANE enhanced with short cut routing, as shown on figure 5.60.
Figure 5.60
MPOA clients
IP Switching and Multiprotocol Label Switching (MPLS)
IP Switching and Multiprotocol Label Switching (see figure 5.61) requires a single signaling
service in the ATM backbone, as shown on figure 5.62. Routers, LAN switches, servers, and
workstations may be ATM-attached in this model as well.

Figure 5.61
IP Switching and Multiprotocol Label Switching
Figure 5.62
IP switching and Multiprotocol Label Switching
In Classic IP, LAN Emulation, and Multiprotocol over ATM, MAC and IP addresses are
mapped to ATM addresses, so that ATM signaling can be used. Due to that mapping, ARP
services are required to resolve legacy addresses into ATM addresses (see figure 5.63). In IP
switching protocols, IP flows or topology are mapped to ATM virtual circuits directly. This
obviates the mapping of legacy addresses to ATM addresses.
Figure 5.63
ATM IP switching services
The purpose of IP switching is to avoiding replication (see figure 5.64). ATM provides new
complex mechanisms in support of multicast, routing, and addressing. There are already
protocols (and more importantly applications) supporting these functions for IP. IP switching
marries IP functionality with the hardware benefits of ATM switching. The result is that IP
routing function is applied at the edge of the ATM network and ATM switching becomes the
high-speed packet-forwarding core.
Figure 5.64
IP switching routing services
As for IP switching client, much like NHRP and MPOA, the concept of IP switching is to
avoid processing packets in routers in the middle of the ATM network - where possible router
hops are avoided (check figure 5.65).
Figure 5.65
IP switching client
Summary
In summary, LANE, MPOA and IP switching provide solutions, which allow for building a
robust backbone network based on an ATM switching core. Figure 5.66 provides an outline
of the features it offers.
Figure 5.66
Itemized list of features and standards of IP over ATM
What’s Next
This chapter discussed the ATM data model, its network services, data protocols and LAN
emulation, as well as ATM MPOA services. The next chapter, “Packet Voice Communication
Strategies,” discusses digitization methods and packet-based voice applications.

Chapter 6
Broadband Packet Networks and
Voice Communication
Communications systems evolve to meet the needs of the computing environment. As you’ve
seen throughout this book, we are in the midst of a major IT evolution, actually the second
revolution in the computing environment, in that we are moving from the "time-shared" host-
based network to an internetwork of high-powered workstations.
*****Start TIP*****
If you’re wondering what the first revolution of computing was, it was the evolution from
batch to interactive processing, prompted by a dramatic decrease in the price of computing
equipment. Thus, the mode of scheduling the work of the user around the computer (batch)
evolved to scheduling the work of the computer around the user (interactive).
*****End TIP*****
This move to internetworked workstations, however, has not removed the need for
communications, although it has vastly altered the fundamental characteristics of these
communications. The traditional host-based system is based on the transfer of information in
relatively small units. In this mode, no more information is normally transferred than the
amount of information that will fit on a single screen - about 1920 characters (24 lines of 80
characters each).
This interactive processing has become our dominant mode of computing over the past ten to
fifteen years. Consequently, our current data communications networks have been designed to
support this particular type of networking environment, as shown on figure 6.1.
Figure 6.1
Traditional Host-based Network

This chapter discusses the traditional host-based network model and its evolution to
broadband packet networks. One of the major players in the broadband packet networks is
Nuera Communications, which has a significant presence in the VoIP industry. Nuera
Communications is a market leader in advanced voice communications equipment. Founded
to provide technology and products that are unmatched in the areas of telephony, call
processing, and voice compression.
******Start NOTE******
This section was based on a whitepaper written by Steven Taylor, from Nuera
Communications. For a full version of this paper or for additional information about Nuera’s
VoIP technology and products, please check chapter 8, “Voice Over IP: Can We Talk?” or
visit Nuera’s Website at URL http://www.nuera.com.
*****End NOTE*****
Broadband Packet Networks
Looking at figure 6.1, traditional host computers, from minicomputer to mainframe to
supercomputers, were linked directly to other computers or terminals, even though the actual
line may first go into a front-end processor, typical for a minicomputer. The typical speed for
the communications interfaces is 64 kbps or less.
The most typical type of connection is the local connection, a terminal directly connected to
the host represented on figure 6.1 as the terminal/computer directly connected to the host.
Data communications techniques were developed to allow remote terminals to operate as if
they were locally attached. The data transmission speed needs for each terminal is limited in
reality by the "screen-based" mode of communications. That is, the user digests the contents
of one screen of information before requesting another screen. Increasing the speed of the
transmission line increases the speed with which the screen is repainted, but provides few
other operational advantages. Thus, there is little to be gained once the screen is repainted
very quickly.
The terminal/computer connected through the squared box, on figure 6.1 have a link to the
host computer. This link represents a link to a single remote device. This usually is a link over
an analog telephone line, with typical speeds up to 19.2 kbps. If a faster link is needed, this
may also be accomplished at a typical speed of 64 kbps via ISDN. In the case of analog
telephone lines, the squared boxes represent modems, but if in the case of ISDN, they would
represent terminal adapters. This type of connection is usually a switched connection. That is,
the connection is established for each session, and connectivity is possible to a number of
points via some form of "dialing."
Now, if you need to connect a number of terminals using a single communications link, than
you would need a multiplexer. The trapezes representations in figure 6.1 represent
multiplexers perform the same basic function, allowing multiple conversations to share a
single transmission facility, whether the transmission line is as simple as 9.6 kbps modems
with an analog phone line or as complex as a 45 Mbps T3 service. The multiplexers come in
two basic flavors:
0 Time Division Multiplexers
0 Statistical Multiplexers.
Notice the terminals in the remote clusters, attached to the multiplexer. The speed for each
interface is usually the same speed as the computer interface. The type of multiplexer used and
the traffic characteristics will determine the maximum data throughput per terminal. The data
transmission speed requirement for each terminal is limited in reality by the "screen-based"
mode of communications. That is, the user digests the contents of one screen of information
before requesting another screen. Increasing the speed of the transmission line increases the
speed with which the screen is repainted, but provides few other operational advantages.
Thus, there is little to be gained once the screen is repainted very quickly.
The Evolution to Workstation-Based Systems
The move to workstation-based computing has evolved as the power of the personal computer
has risen exponentially. Many users now have more computing power on their desktops than
the mainframe computers had just a few years ago. This vast increase in power has moved
many of the computing tasks from the mainframe to the personal workstation. This has not,
however, resulted, in a decreased need for communications.
Nevertheless, it has resulted in vast changes in the mode of communications. Now, rather
than sending information in a screen-by-screen fashion based on terminal-host
communications, we send information in a file-by-file mode, as shown on figure 6.2. Also,
while this information is in vast quantities, the rate of the transmissions is much more
sporadic. In some cases, as many transmissions per minute would be needed as in terminal-
host communications. This might be the case if the application used high-resolution graphics
with a supercomputer acting as the host and the high-performance workstation acting as the
terminal. In other cases, a database may be downloaded, massaged for minutes to hours, then
uploaded to another system.

Figure 6.2
Workstation-based computing generates file-by-file-based communications
The term file used as base for workstation-based communication is used here in a context of a
large amount of information consisting of many more than 1,920 characters. Depending on the
actual application, this file may constitute an actual data file, such as a part of a database; a
video image; or any other collection of data to be shared.
*****End NOTE*****
These applications have been under development for several years using intensive data sharing
on the LAN. In this case literally several million bits per second of information throughput are
available between workstations at a relatively low cost. In the wide area network, though, this
is not the case. While multimegabit per second throughput is available, it is still quite
expensive. Thus, the challenge is to provide connectivity across the wide area network for
highly bursty high bandwidth applications to support this change in the norm for the
computing environment. Meeting this challenge is the goal of broadband packet networking.
Broadband Packet for LANs
When any of the broadband packet technologies are discussed, the first and foremost
application that is discussed is the local area network (LAN) internetworking - the
interconnection of remote LANs. Although this discussion is partially a true, the genuine need
is not directly related to the fact that there are LANs that need to be interconnected. Rather,
the needs are generated by the type of traffic that is typical for LANs, and the fact that this type
of traffic now needs to be carried across the wide area network.
As discussed earlier in this chapter, file-based, as opposed to screen based, communications
tend to be quite bursty. Due to the nature of these applications, varying from file servers
through shared graphic images, they are already becoming commonplace in LANs. Now,
demand is growing to be able to perform these same tasks across the wide area. Thus, we are
faced with supporting bursty, high bandwidth applications across the wide area while being
constrained by relatively expensive bandwidth across the wide area.
We must be careful to remember, though, that even though LAN interconnection is discussed
in that and in other contexts as the killer application, this is true only because the type of traffic
that severely needs broadband packet technology is usually associated with LANs. Host-to-
host traffic may generate this type of traffic as well, depending on the application, and the
presence or absence of actual LANs is inconsequential. Conversely, LAN-to-LAN traffic, as

shown in figure 6.3 doesn't really need broadband packet if the traffic is terminal-to-host
traffic that just happens to be using a LAN as the local transport mechanism.
Figure 6.3
A typical LAN-to-LAN traffic doesn’t need broadband packet if traffic is based on terminal-to-host.
Internetworking LANs
Internetworking or the interconnection of LANs via bridges and routers has become standard
practice and is one of the fastest growing areas of the networking marketplace. The challenge
of interconnecting LANs using bridges and routers comes in choosing appropriate
transmission facilities in the wide area portion of the network. LANs typically run at several
megabits per second. Thus, information is transferred among devices connected to the LAN at
very high rates.
When LAN internetworking is implemented, the intent is to allow geographically dispersed
devices to perform as if they were all connected to a single LAN. While this is possible insofar
as providing physical connectivity and the potential for information transfer, the actual rate of
information transfer is usually vastly inferior to that on the LAN itself. Hence, the
connectivity is there, but the performance may not be there, especially for file-based
interactions.
The reason for this lack of performance is that LANs with megabits per second of
transmission speed are interconnected via WAN transmission facilities with tens of kilobits
per second. This model works fine for transaction-based communications based on a
terminal-host communications model. However, the vast mismatch of speeds makes it
insufficient for the emerging file-based communications applications.
When file-based transactions are needed, there are two choices. Either use traditional speeds
in the 56 kbps range with relatively poor performance but good utilization of the facilities, or
move to T1 which provide excellent performance but only actually use the available
bandwidth a small percentage of the time. It is exactly this dilemma that broadband packet
networks address.
Figure 6.4 illustrates a typical internetworking of LANs. The larger shaded squares on the
figure are bridges or routers used to provide connectivity among LANs via wide area
transmission facilities. In this case, the transmission facilities are dedicated. Every LAN (A, B
and C) can have their own physical topology, varying from Token Ring LAN to Ethernet,
either coax or twisted pair, or even an FDDI ring. The only key is support by the bridge or
router.
Figure 6.4
Typical LAN internetworking
The smaller rectangles connecting the terminal/computer to the LAN represents the media
access device. It may be an external device, such as a terminal server, or it may be internal to
the computer, workstation, or other computing device. If this is a Token Ring network, the
media access device may be called a MAU (Media Access Unit), for example.
Packetized LAN Interconnection
When LANs are interconnected via some form of packetized network, network bandwidth is
allocated only when it is actually needed. These networks become especially appropriate for
interconnecting file-based LAN-to-LAN communications when the network is a Broadband
Packet network, as show on figure 6.5.
The term "Broadband Packet" is used to indicate that the speeds supported by the packet
networks are in the range of megabits per second and higher. Thus, several megabits per
second may be allocated to a particular file transfer for the seconds that the bandwidth is
needed. For instance, rather than allocating tens of kilobits per second (e.g. 56 kbps) on a
constant basis, a much larger amount of bandwidth (e.g. 1.544 Mbps) may be allocated, but
only for the amount of time that it is actually needed. At any other time, other users may vie
for this pool of dynamically assigned bandwidth. Indeed, this may be considered a form of
fractional T1, as discussed later on this chapter.
Figure 6.5
Packetized LAN interconnection
Looking at figure 6.5, the larger squares, representing bridges or routers are used to provide
connectivity among LANs via wide area transmission facilities. But in this case, the
bridge/router supports an interface that is designed for use with a Broadband Packet network
of some type: represented by the little circles.
These little circles, connecting the larger squares to the Internet cloud are interfaces for the
type of Broadband Packet network being used. This may be an interface for Frame Relay,
SMDS, or ATM. The specifics for each of these interfaces will be discussed in detail in later
in this chapter. This interface guarantees that the data is packetized in an appropriate format to
be transported by the network.

The physical interface will typically be a standard serial interface of some form. At speeds up
to a few megabits per second, this will typically be a V.35 interface. At higher speeds, the
HSSI interface will typically be found. The type of service (Frame Relay, SMDS, or ATM)
and the nature of the service (public or private network) will determine the details of the
connections here.
The broadband packet network is the heart of the system. It is a network that is designed to
carry traffic in a packetized (statistically multiplexed) format and to deliver it to a similar
interface at a remote location. Depending on whether a private network is implemented or a
public network service is used, the actual packet switching equipment may be within the
carrier network or it may be located on the customer's premises.
The key to the packet network is LOTS OF TRAFFIC from LOTS OF SOURCES. This
allows the bandwidth that might otherwise be dedicated to individual point-to-point dedicated
connections to be aggregated and parceled out to the different connections on an as-needed,
dynamic basis.
Understanding Fractional T1
Fractional services, by definition, are services in which one purchases a portion of a whole.
Currently, when we hear of services like fractional T1, we usually think of the service as a
dedicated bandwidth portion of a larger dedicated bandwidth service. For instance, as
depicted in figure 6.6, one may buy 256 kbps or 512 kbps instead of the entire T1 (1.544
Mbps). In most cases, the bandwidth purchased will be an integral multiple of either 56 kbps
or 64 kbps.
Figure 6.6
Traditional bandwidth fractional T1
When the bandwidth is purchased in this fashion, we call it "bandwidth fractional" because we
are buying a fraction of the full bandwidth over a relatively long period of time, weeks to
months to years.
Time Fractional T1/T3
It is also possible to purchase transmission capabilities by a method by which one buys all of
the bandwidth, but only for a packet-time. Of course, no carriers really charge for the packet-
time in those exact terms, but that is exactly what you are paying for whenever you use a
packetized service.
In fact, the same principle applies when using any packetized service, whether it is on a public
or a private network. Since one has access to all of the bandwidth for a fraction of the time, we
use here the term "time fractional" to make a distinction between the two possible types of
fractional services, see figure 6.7.
Figure 6.7
Time Fractional T1
Time fractional services, such as those provided by the broadband packet technologies, are an
excellent fit for the evolving needs for file-based communications. If a file of several
megabytes of information needs to be transmitted, all of the available bandwidth is needed for
the duration of the transmission. Once the file transmission is finished, no bandwidth is
needed. Thus, the time fractional model provides an excellent complement to the current and
emerging needs for wide area communications, especially multimedia application, such as
VoIP.
Multiplexers and Framing
The concept of bandwidth fractional and time fractional services is really just another way of
looking at multiplexing. If a single organization has access to the entire transmission facility,
such as a T1 circuit, and it subdivides the transmission facility among several tasks, this is the
classical use of multiplexers in the private network. Carriers have used similar techniques for
years for allocating bandwidth to multiple users.
Any type of digital multiplexer requires some form of framing. The signal coming from the
transmission facilities is nothing more than a series of ones and zeros. There is nothing about
these ones and zeros that inherently separate the one conversation from another. Thus, there is
a need for some form of structure to identify, which ones (sheep) and zeros (cows) belong to
which of the multiple conversations being transported, as shown on figure 6.8.
Figure 6.8
Multiplexer and frames: identifying different types of data.
*****Start TIP*****
What’s in a name. What’s a digital multiplexer?

A digital multiplexer is a multiplexer used to combine various types of traffic to be transported
via digital facilities, such as 56 kbps or T1 facilities.
*****End TIP*****
There are two fundamental types of multiplexers:
0 Circuit, or time division, multiplexers
0 Packet, or statistical, multiplexers.
Circuit Multiplexing
Circuit multiplexing, or time division multiplexing, is the most basic form of digital
multiplexing. The basic time division multiplexer simply divides the available bandwidth
among the different applications on a dedicated basis. Each applications has its share, and
other application may not "borrow" from any other applications based on whether the
bandwidth is active (in use) or not, as shown on figure 6.9.
Figure 6.9
Time division multiplexing

The dedicated nature of the bandwidth forms several key characteristics:
0 Circuit multiplexers tend to be relatively fast and relatively inexpensive. Since they
are conceptually quite simple, circuit multiplexers are the first multiplexers to be
introduced as transmission speeds go higher and higher.
0 The dedicated bandwidth guarantees transparent transmission of data. The
multiplexer ships bits from one end to the other without regard for protocol. Thus, by
definition, virtually any type of traffic may be transported by a circuit multiplexer.
0 There is virtually no variation in the delay from one set of bits to the next3. This is
likewise a function of the transparent nature of the device. Variations in delay usually
result from delays due to traffic congestion and retransmission. These delays are
found in packet multiplexers. The consistency in delay obviates the problems caused
by variable delays when transporting synchronous protocols like SNA and X.25.
0 Circuit multiplexers only require minimal framing overhead4. Most implementations
of circuit multiplexers require less than one percent of the total bandwidth for this
3
There is indeed some variation in the speeds, commonly referred to as "jitter" and "wander." However,
the variations from these factors, as well as from other factors like doppler shifts in satellite systems, are
microscopic and insignificant for the discussions in this section.
4
The framing overhead is the amount of overhead that is required to perform the framing functions. That
is, the overhead used to keep track of which bits belong to which conversation.
type of overhead. For instance, the standard channel bank5 uses only 1 out of 193 bits
in the frame for framing in the standard super frame6 (SF) format. In the extended
super frame7 (ESF) format for channel banks, the framing actually used to identify
channels consists of 1 out of 772 bits.
If you look at the figure 6.9, the numbers lined-up vertically on the left and right sides of the
figure represent the various inputs to the multiplexer. The channels may carry any type of
traffic. Also, the speeds for the channels are arbitrary. They may be any mix, but, since the
bandwidth is dedicated, the sum of the speeds must not exceed 9600. In fact, they sum of the
speeds must be slightly less than 9600, so the figure actually does not provide an accurate
account of this process. However, the framing overhead for time division multiplexers is so
minimal that this is not a bad assumption.
The triangles represent the multiplexer hardware. The multiple channel side is the
input/output for the various channels, and the single connection side represents the connection
5
A type of digital multiplexer that has become a commodity product within the telephone companies. The
channel bank transforms 24 analog voice conversations to 64 kbps digital voice (per conversation) and
formats the digital conversations for transport across a single 1.544 Mbps transmission facility (T1 line).
6
SuperFrame is a framing format used in "D3" and "D4" multiplexers. It consists of a "superframe" of 12
frames. Each of the 12 frames contains a single 8-bit sample from each of the 24 channels, plus one
framing bit.
7
Generally viewed as an enhancement for SF framing, the ESF (Extended SuperFrame) format reassigns
the use of the single framing bit in each 193-bit frame. One fourth of the "framing bits" are used for
identifying the channels, one-fourth are used to provide error detection (for diagnostic purposes only; not
for retransmission), and one-half are used for supervisory communications and control.
to the transmission facilities. For simplicity, all of the multiplexers shown on figure 6.9 are
point-to-point single transmission link applications. In reality, many multiplexers, both circuit
and packet, support switching capabilities and multiple links for more complexes network
applications.
In the figure 6.9, the amount “9600” represents the transmission facilities between the two
multiplexers. The use of the speed "9600" is for demonstrative purposes only. In this case, it
may be thought of as a 9600 bps modem link. It may equally as well have been a 1.544 Mbps
(T1) link connecting two channel banks. In that case, the link would have supported twenty-
four 64 kbps circuits.
The numbered portions of the frame diagram represent the "payload" of the frame. This is the
information that is transported for each individual channel. Note that these are fixed
information payloads for each channel, resulting in the dedicated bandwidth for each channel.
Packet Multiplexing
Packet multiplexers, often called statistical multiplexers, are an alternative means for
transporting data from one point to the next. The packet multiplexer derives its power from
transporting the data in packets, or message units, rather than as a continuous flow of
information.
Most data is not continuous. Rather, is usually occurs in bursts of some form. When there is a
burst of data, bandwidth is assigned to transport that data across the wide area network. When
there is no data to be transmitted, no wide area bandwidth is assigned. Thus, the packet
multiplexer differs from the circuit multiplexer in that there is no pre-assigned dedicated
bandwidth for any of the channels. Rather, bandwidth is assigned on-demand as it is needed,
as shown on figure 6.10.
Figure 6.10
Characteristics of packet multiplexers
This capability lends distinct characteristics to the packet multiplexer, as shown on figure
6.10:
0 Protocol sensitivity is a requirement for any type of packet multiplexer. Since the
multiplexer only transmits data when there is "real" data to be transmitted, the
multiplexer must be able to determine the difference between "real" data and traffic
that may appear on the line as fill. It is the removal of the "fill" traffic prior to
transmission and reinsertion on the opposite end that provides the vast majority of the
efficiency found in packet multiplexers. Still, the multiplexer must have some
knowledge of what the protocol is in order to recognize and remove the fill characters.
0 Packet multiplexers can provide extremely efficient use of the bandwidth available on
the transmission facilities. Since no channels have any bandwidth dedicated for their
exclusive use, the bandwidth is available for channels that need bandwidth on an as-
needed basis. Thus, if the total traffic pattern has lots of channels with each channel
needing the bandwidth on a "bursty" basis, the aggregate transmission bandwidth may
be shared.
0 Since the aggregate transmission bandwidth is shared among the channels, the delays
in the packet system will be much more variable than in the circuit multiplexer. If
there are only a few channels contending for the bandwidth, the amount of bandwidth
available to each channel is fairly high. On the other hand, as more and more
channels contend for a fixed amount of bandwidth, the percentage of the total
available to each channel is lower, thus increasing the overall delay. (The
transmission bandwidth between the two packet multiplexers is still limited to the
speed of the physical facilities.)
0 By necessity, packet multiplexers have higher framing overhead than circuit
multiplexers have. This is because the data in each "packet" of information must be
explicitly addressed or labeled. In the circuit multiplexer, the channels are identified
by their position in the frame relative to the framing bits. In the packet multiplexer,
there are not predefined framing bits. This requires a label on each packet of
information identifying its channel.
0 Sometimes packet multiplexers have a protocol of their own used between
multiplexers to guarantee accurate delivery of data. This is especially a hallmark of
packet switches and statistical multiplexers, devices that were developed primarily to
transport asynchronous ASCII data that has no inherent protocol. While the
retransmission of erred packets guarantees accurate delivery, it also increases the
delay variability because packets that are not retransmitted are delivered more quickly
than packets that require retransmission. The addition of this layer of protocol also
adds to the processing power needed in the multiplexer.
If you look at figure 6.10, the column of numbers 4800 on the left represent the input/output
channels for the packet multiplexer. Note that the sum of the channel speeds can exceed the
speed of the transmission links. It is not possible, however, for the channels to operate
continuously and simultaneously at these speeds. Rather, there are the speeds at which the
data is communicated to and from the multiplexer. The actual throughput rate will depend on
the traffic at the time.

The rate at which the various channels submit data to the multiplexer may actually exceed the
transmission rate for a short period of time. The excess data will be stored temporarily in
buffers in the multiplexers until the traffic has dropped off sufficiently to empty the buffers.
The actual throughput for an individual channel will never exceed the rate of the transmission
facilities. In fact, it will always be somewhat less due to overhead, even if the channel has sole
access to the facilities.
The list of channels across the figure 6.10 represents the data that will be specific to the data
from a given channel. For simplicity, the area shown here includes both the "packet" and the
"frame" portion of protocols like X.25, so the use of the term "packet" here indicates the
generalized use of the term to indicate that the data is transmitted in discrete bundles or
message units. It does not refer explicitly to the packet level of the X.25 protocol.
The hashed area in the beginning is the header. This will contain information that identifies
the contents as belonging to one particular channel. The solid area in the center will contain
the actual data from a specific channel. If the packet multiplexer is "frame oriented," the
actual length (number of bytes) in the payload will be variable. If the packet multiplexer is
"cell oriented", there will be a fixed number of bytes in the payload. The differences between
frames and cells will be explored later in more detail. The hashed area at the end represents
any "trailer" information that might be present - depending on the actual format used. In many
cases, the trailer information will contain a 16-bit error detection code (CRC - or Cyclic
Redundancy Check) that is used to determine whether an error occurred during transmission.
Packet Switching
Packet switching is a logical extension of packet multiplexing. Each message unit (frame or
cell) in the packet multiplexed data stream has a unique address identifying which channel
"owns" that particular information. The packet switch can accept this information and route it
to an appropriate next destination based on the information identifying the "owner."
As depicted in the figure 6.11, each message unit entering the switch will have a message unit
identifier - in this case either an "A" or a "B" - identifying the owner of the information.
Assuming that "A" and "B" are located at separate locations, the switch then sends that
information along an appropriate path to either the "A" destination or the "B" destination.
Figure 6.11
Packet switching
Be careful not to take the "A" and "B" designations too literally in this example. Depending
on the design of the system, the "A" or "B" identifier may actually stay with the message
throughout the transmission path (as depicted here), in which case the "A" or "B" is a form of
global address, much like the address on a letter. This is a major characteristic of a
connectionless architecture.
Conversely, the switch may keep track of the connections and use the "A" or "B" as a circuit
number for only a singular transmission facility. In this case, a single message may actually
have several different "message identifiers" as it traverses the network. This method allows
the addresses to be reused on every link, consequently supporting a larger network for the
same length address. This type of network is said to be connection-oriented.
Neither connection-oriented nor connectionless architectures are inherently better than the
other. Each has its own strengths and weaknesses, so don't be misled by claims that one is
"good" and the other is "bad." In fact, many of the advantages and disadvantages of each are
more important to equipment designers and network providers than to end-users.
In the broadband packet technologies two of the technologies - frame relay and ATM - are
connection-oriented. The third - SMDS - is connectionless.

Understanding Broadband Packet
Broadband packet switching is a specialized form of packet switching and multiplexing. The
use of the word "broadband" implies that the technologies are appropriate to be used at
"broadband speeds," that is, at T1 (1.544 Mbps) and above.
Broadband packets are fundamentally the same as any other type of packets. They consist of a
header, a payload, and, optionally, a "trailer." All three8 types of broadband packet networks
have two fundamental assumptions in common, as shown on figure 6.12:
0 Broadband packet networks are optimized for transporting protocol-oriented9 traffic.
The inherent protocol in the traffic will guarantee delivery, so the network need not
perform that task. This assumption allows the network to bypass processing tasks that
guarantee delivery, thus accelerating the throughput possible with a given amount of
processing power.
0 Broadband packet networks assume relatively clean10 transmission facilities. The
clean transmission facilities greatly reduce the chances of encountering a transmission
8
Frame Relay, SMDS, and ATM are the three technologies usually included under the "broadband packet"
umbrella.
9
Traffic being transported that already has a protocol in the traffic, like SNA/SDLC, X.25, and most LAN
protocols. In contrast, traditional asynchronous ASCII communications have no protocol, so the network,
typically X.25 or statistical multiplexers, must protect against transmission errors.
10
Transmission facilities with low error rates, particularly typical of fiber optic transmission facilities.
error. This makes the error detection on an end-to-end basis performed inherently in
the transported protocol feasible.
Figure 6.12
Generic packet format
In the figure 6.12,
0 The flag or delimiter identifies the beginning of a message unit. This separates one
message unit from another. In frame oriented technologies, the flag will usually be an
eight-bit character with the hexadecimal value of 7E. Flags are also used to provide
fill between frames. In cell oriented systems, the function of the flag may be
accomplished with a fixed format, much like the framing bit in the circuit (time
division) multiplexer.
0 The header portion of the message unit provides the identification of the owner of the
information. In frame relay and ATM, the header is used to identify the circuit
number on the individual link. The switches then provide connections among "circuit
numbers" to route message units to their appropriate destinations. In SMDS, there are
actually two forms of "message units." In one of the formats, circuit numbers are
used just like in frame relay and SMDS. In another type of message unit, the header
actually contains the global address for the message unit.
The header may also contain information to be used for congestion management and
for error detection for control messages. Having the error detection in the header is
usually found in cell headers. Frames usually use the "trailer" for error detection.
0 The payload is the "information" portion of the message unit. The payload consists
of the traffic being transported in its native format. A single payload may contain an
entire native-mode message unit or a portion of a native-mode message unit. While
the payload has no error detection functions within the broadband packet network, the
payload will often contain error detection information as a part of the upper layer
protocol being transported.
0 Notice that trailers is optional. Some broadband packet formats use trailer
information; others do not. When a trailer is used, its primary function is to provide
error detection for the header and the payload. When a trailer is used to provide error
detection for the entire payload, this is usually done due to the convenience of using
readily available hardware when building equipment, not to provide retransmission on
error. This task is still left to the higher protocol layers.
The critical task of error control in a broadband packet system is to insure the
integrity of control messages and to make sure that the header was not corrupted.
This may be accomplished by placing error control either in the header itself or in the
trailer.
The result of these assumptions is that all three implementations are much more similar than
they are different, especially when compared with traditional technologies like T1
multiplexers and packet switches, offering:
0 Bandwidth on demand (packet multiplexing or Time Fractional Service Review?);
0 Support for speeds of T1 and above, with ATM technology approaching the Gbps11
range;
0 Connectivity to a large number of users with dynamic bandwidth assignment to all
points (packet multiplexing): resulting in
0 Excellent transmission characteristics for bursty, high-bandwidth data, such as is
typically found in LAN internetworking applications.
These characteristics that result in the performance of broadband packet systems at high
speeds lead to the term that is sometimes applied to the technologies: "Fast Packet." At the
11
Gigabits per second, or a BILLION bits per second.
same time, none of the technology offer guaranteed delivery of data, including retransmission
on error. This is left to the higher level protocols that are implemented in the DTE (This may
be the LAN protocol or the protocol in the computer, such as SNA).
Since broadband packets come in various forms, such as frames and cells - the next topic, it is
convenient to have a term to use when referring to a generic packet. One of the most useful
terms in this context is the PDU, or Protocol Data Unit.
Frames and Cells
The basic difference between frames and cells is incredibly simple:
0 Frames have variable length payloads.
0 Cells have fixed length payloads.
Among the broadband packet technologies, frame relay and one level of the SMDS interface
protocols are based on frames. ATM and the other level of the SMDS interface protocol are
based on cells.
The fixed versus variable lengths for frames and cells result in some distinguishing features, as

0 The delimiter between frames is a character (7E), and this character is recognized as a
distinct portion of the data stream. By contrast, since cells are of a fixed length, the
delimiter may be quite similar to the framing bit in the circuit multiplexer format.
0 Frames generally have a "trailing" error control field. Cells generally include error
control in the header. This is a function of convenience for equipment builders more
than a fundamental indication of the usefulness of technology.
0 Due to their simplicity, cell-oriented systems are generally viewed as more
appropriate for higher speeds.
0 The delay for cells is generally less in duration and is more predictable than for
frames, making cells generally more appropriate for voice and video. (This only
matters if you are going to be carrying voice and/or video in the network.)
Figure 6.13
Cells have a fixed payload length while frames don’t
The structure of a cell comprise:

 Optional delimiter used to separate cells. It will normally be provided from a fixed
framing structure, similar to - or even identical to - the framing bits in the circuit
multiplexer.
0 5 octets, is the header portion of the message unit provides the identification of the
owner of the information. In frame relay and ATM, the header is used to identify the
circuit number on the individual link. The switches then provide connections among
"circuit numbers" to route message units to their appropriate destinations. In SMDS,
there are actually two forms of "message units." In one of the formats, circuit
numbers are used just like in frame relay and SMDS. In another type of message unit,
the header actually contains the global address for the message unit. The header may
also contain information to be used for congestion management and for error
detection for control messages.
Unlike frame structures, multiple framing bits or characters are NOT used to provide
fill between cells when there is no data to transmit. Instead, entire empty (or null)
cells are transmitted.
0 Payload, is the "information" portion of the cell. The most fundamental
characteristic of a cell is the fixed size of the payload. In the case of ATM, the size of
the payload is 48 octets (8-bit bytes). The payload consists of the traffic being
transported in its native format. However, since the native format will seldom be the
exact same size as the cell, it usually must be segmented into several cells.
The structure of a frame comprise:
0 Frame flag, used to separate one message unit from another. In frame oriented
technologies, the flag will usually be an eight-bit character with the hexadecimal
value of 7E. There is generally a minimum of one flag between frames. Multiple flag
characters are used to provide fill between frames when there is no data to transmit.
0 The header portion of the message unit provides the identification of the owner of the
information. In frame relay and ATM, the header is used to identify the circuit
number on the individual link. The switches then provide connections among "circuit
numbers" to route message units to their appropriate destinations. In SMDS, there are
actually two forms of "message units." In one of the formats, circuit numbers are
used just like in frame relay and SMDS. In another type of message unit, the header
actually contains the global address for the message unit. The header may also
contain information to be used for congestion management and for error detection for
control messages.
0 The payload is the "information" portion of the frame. The most fundamental
characteristic of a frame is the ability of the payload to be variable in size. The
minimum payload size is typically a single character. There is a maximum size, and
this is often negotiated at call set-up. The typical maximum sizes range from about
2,000 to about 8,000 characters.
The payload consists of the traffic being transported in its native format. A single
payload may contain an entire native-mode message unit if the message unit will fit
within the maximum size constraints. If the native-mode payload is larger than the
maximum size for the payload, it must be segmented into several frames.
0 The CRC, or critical task of error control in a broadband packet system is to insure the
integrity of CONTROL messages and to make sure that the HEADER was not
corrupted. This may be accomplished by placing error control either in the header
itself or in the trailer.
Once again, though, remember that these characteristics hold in general, but not always.
Neither frames nor cells are inherently better for all applications. In fact, even for an
application that is generally served better by one of the technologies, the exact performance
will be affected severely by the actual implementation.

Interface standards
An often-recurring concern with all of the broadband packet technologies is whether there are
any standards. There are full suites of standards in place and/or in definition for each of the
technologies. None are being developed as proprietary, vendor specific technologies.
Most of the standards in place are User-to-Network Interface (UNI) standards. As such, they
define the rules for passing information from a piece of "Data Terminal Equipment" (DTE),
such as a bridge, router, broadband packet "PAD", broadband packet concentrator, or front-
end processor, to a packet transporting network. This network may be a carrier network or a
private network owned and operated by the user. Its function is to transport broadband packet
of some type from the entry point to the destination by whatever means it deems appropriate.
The internal structure of the network, often called the "network architecture," is generally not
subject to the standards. Each individual network may transport the information among the
network nodes in any manner the network designers choose. In fact, most networks will use a
proprietary internodal transport mechanism to provide a "better mousetrap" to the industry.
While this may appear on the surface to be a severe limitation, it really is no different from
most other standards. In fact, it's exactly like the granddaddy of all standards, X.25, in that
X.25 is also a UNI specification. Each individual packet network uses it own internodal
transport mechanisms, as shown on figure 6.14.

Figure 6.14
Broadband transport network standard interfaces
If the entire network architecture were standardized, there would be little or no incentive for
the equipment manufacturers to build products that are better, just cheaper. Thus, the
proprietary nature of the network architectures allows the competitive factors in the market to
continue to advance the technology.
Data transfers between disparate X.25 networks are accomplished via X.75, the Network-to-
Network Interface (NNI) specification. Similarly, NNIs developed and/or are being
developed for each of the broadband packet technologies.
The standards work is not over, though, and there are several areas in which the work is
continuing. The most important point to remember is that many broadband packet standards
are here, they're real, and they're functional. Standards are living documents, though, so the
standards will continue to evolve.

Broadband Packet & the OSI Model
One must also realize that the broadband packet standards are not designed to accomplish all
of the tasks in the network. In reality, the standards only address a very narrow subset of the
OSI seven-layer protocol stack, as you can see on figure 6.15.
Figure 6.15
Positioning of broadband packet
Rather than a complete protocol, the broadband packet technologies may perhaps be best
thought of as the WAN equivalent of a "MAC layer" (media access control layer) protocol in
the LAN world. The standards define how multiple applications may share the transmission
bandwidth in a common, packetized format. However, the conformance to any particular
higher layer protocols and protocol translation is not part of broadband packet's task set.
Thus, as indicated on figure 6.15, broadband packet accomplishes some of the traditional level
2 and level 3 tasks. These are all that is needed to fulfill the mission. Also, while some of the
technologies are designed for, or at least recommend, a particular physical level
implementation, the fundamental transport tasks for broadband packet can generally be
accomplished with a variety of physical level implementations.

What’s Next
This chapter discussed broadband packet networks and voice communication. The next
chapter, “Low Bit Rate Vocoding Methods,” discusses the digitization of voice, both the
technology and standard, as well as implementation issues.

Chapter 7
Codecs Methods
This chapter provides you with a more in-depth discussion of codecs technology as well as
vocoding methods.
Video Codecs Review
The basic functionality of a video codec is to enable the transmission of various audio, video
and data signals over digital telephone networks. In general terms, an audio/video codec
embodies the functionality depicted on figure 7.1

Figure 7.1
Audio/video codec functionality
A codec is comprised of two basic processing elements:
0 a compressor (or encoder)
0 a decompressor (or decoder).
Let's look at the compressor side. A standard video signal coming from cameras or tape
players is first digitized into a 135 Mbps feed. Since this rather high bandwidth is difficult to
transport economically, one must first compress it down to a more manageable bit rate. While
many compression techniques exist, most codecs on the market rely on either Delta Pulse
Code Modulation (DPCM) or Discrete-Cosine-Transform (DCT) algorithms. Some
compressors achieve very high compression ratios, up to 200:1. Others compress as little as
5:1, but maintain very high picture quality.
The same process is applied to audio signals, which are first digitized, and compressed as
well. The compressed digital video data is then multiplexed with the compressed audio data
and, in some cases, external digital data. The resulting data stream is then formatted according
to a given network interface standard, and connected to the network.
The decompressor side reverses the process. It demultiplexes the original, compressed digital
video, audio and data streams, and feeds the resulting signals to the respective decompressors.
The decompressed signals are then converted back to their original, analog form.
Audio Codecs
An audio codec (COder/DECoder) is a software scheme that takes analog audio data and
encodes it into some sort of binary format for digital storage and/or processing. It then decodes
the data and attempts to reproduce the original sound. Due to the massive size of digital audio
data, codecs usually involve some sort of compression. Audio codecs can be broadly divided
into three classes:
0 Waveform codecs
0 Source codecs,
0 Hybrid codecs.
Waveform Codecs
Waveform codecs tries to save enough data about the original sound wave to enable it to be
reconstructed upon playback, by reproducing the sound wave itself, which has several
advantages over the other two types of audio codecs, as they try to synthesize sound.
Another advantage of waveform codecs is that they are device independent, which in theory
enable them to reproduce all sorts of sounds, regardless of its source. You don’t need high-end
computers to run this type of codecs, as its software to encode and decode is not as complex as
the others. Thus, a 486 Intel box can be plentiful. Of course, with the price of computers
getting cheaper, you might consider using a Pentium-based (RISC? Why not!) computers, as
the audio codecs can be run quickly and easily, resulting in almost instantaneous playback.
The only disadvantage I see on waveform codecs is that they files tend to be large. Windows
95 and NT offer several types of waveform codec, including PCM, companding and ADPCM
codecs.
Defining Pulse Code Modulation (PCM)
Pulse Code Modulation (PCM) is the simplest form of audio codec. PCM is also the method
used by Microsoft Windows when automatically saving a WAV file. PCM files don’t use any
form of compression. Thus, a music clip digitalized at 22,050 Hz 8-bit mono (radio quality)
will require more than 22 KB of file size per second of audio when saved in this format. CD-
quality sound files in this format are eight times larger. However, PCM-format WAV files are
natively supported by virtually every sound card on every platform.
If you’re interested to learn more about the method in which the PCM codec digitalizes audio,
check SK Web Construction Website at URL
http://www.skwc.com/WebClass/SoundProcessing.html#pcm where you find a very
comprehensive description on the subject.
*****End NOTE*****
Defining Compacting/Expanding (Companding) Codecs
Companding codecs, based upon the A-Law and µ-Law standards, were developed to address
accurate reproduction of sounds for humans. Companding codecs have been around since the
1960's and are still in widespread use today. They are not really compression codecs per se.
Although similar to PCM, which are not compressed either, the main difference here is that
the companded file will have an apparent amplitude range not far below that of a 16-bit file.
Thus, companding codecs are most useful for reducing 16-bit audio files to 8-bit, cutting their
size in half without sacrificing as much quality. Windows 95 and NT offer both an A-Law and
µ-Law version of these codecs.

Defining Adaptive Differential PCM (ADPCM) --
You can very much predict, in the short term, a waveform produced by human speech. Thus,
one of the most common techniques used in coding speech samples uses this fact and attempts
to predict the value of the next sample from the values of the previous samples. If the
predictions are accurate, charting the difference between the predictions and the actual
samples will produce a much flatter graph than charting the wave itself.
This technique of charting the differences is known as Differential Pulse Code Modulation
(DPCM (. These differences can be made even smaller if the predictor can be made adaptive,
so that it will adapt and change its predictions to match individual characteristics of the speech
being coded. This is the concept behind Adaptive Differential PCM codecs. But since these
codecs are built to predict the patterns of human speech, they do not produce very high quality
music reproduction. Also, this is a very complex process, especially if compared to a sound
wave. Thus, decoding and (especially) encoding requires more work by your computer's CPU
and usually results in some delay.
Source Codecs
Source codecs attempt to create a model of how a sound was generated and then tries to
reconstruct it based upon that model, discarding the waveform data completely. Vocoders, are
the most typical source codecs you can find, probably the only one you will even see around,
as they are constructed upon a basic model of how the human voice is produced. They save a
few parameters -- guidelines -- based upon the individual characteristics of the particular
voice, which they will attempt to reproduce. Since Vocoders save a very small set of
characteristic traits and completely discarding the waveform data, they produce very small file
sizes.
The limitation with source codecs is that they can only save human speech data, at only one
voice speaking at a time, and the synthesized output tends to be very artificial, especially if
compared to other methods. They are not recommended for reproducing any other sounds.
*****Start TIP*****
AT&T’s Bell Laboratories has a site where you can type a word into an online form, click a
button, and hear the word spoken by an artificial voice as a man, a woman, a child, or a gnat.
If you want to try it out, their URL is http://portal.research.bell-labs.com/cgi-bin/voices.form.
*****End TIP*****
Hybrid Codecs
Hybrid codecs usually produce smaller files than waveform codecs. However, they are more
complex and sound reproduction quality is not as good. Still, hybrid codecs are less complex
and produce better quality sound than vocoders. They are called hybrids because they utilize
elements of each of the other two approaches.
The most successful hybrid codecs are the Analysis-by-Synthesis (AbS) codecs. Like
vocoders, they begin with a synthetic model of the human vocal tract -- vocal chords, throat,
mouth, teeth, tongue, lips... -- and attempt to reproduce the human voice. AbS codecs differ
from vocoders in that they use data from the actual sound waves to select an excitation signal
from a number of built-in options.
Installing Audio Codecs on Windows 95/NT 4.0
If you are running Windows 95, make sure you have the Microsoft Audio Compression
Manager installed. Go to Control Panel and double-click on the Multimedia icon. Then select
the Advanced tab, as shown on figure 7.2.
Figure 7.2
Installing audio codecs on Windows 95/NT 4.0.

Once in the advanced tab, chose Audio Compression Codecs, click on the plus mark (+) to its
left, and it should open up to reveal a number of options, as shown on figure 7.2. If you don’t
have all of those shown on figure 7.2 you can always add it by clicking over the icon
Add/Remove programs, as shown on figure 7.4, and then clicking on Windows setup, which
should bring you to a tab just like the one on figure 7.5. Once there, select the Audio
Compression option, as illustrated on figure 7.6.
Figure 7.4
Adding audio codecs options on Windows 95/NT 4.0
Figure 7.5
Selecting additional audio codes in multimedia setup on Windows 95/NT 4.0
Figure 7.6
Choosing Audio Compression options on Windows 95/NT 4.0

What’s Next
In the next chapter, “Voice Over IP: Can We Talk?” we’ll focus on the applicability of VoIP,
such as in computer telephony integration (CTI), videoconferencing, document-sharing, web-
based call center applications, etc. It also discusses the challenges VoIP faces, both with
getting telcos up to speed, as well as setting standards. It goes on listing the major VoIP
players, including 3Com, Motorola, Nuera Communication and others.

Chapter 8
Voice Over IP: Can We Talk?
VoIP is transforming the trillion-dollar global communications industry. Give it few more
years and you will see at least 70 percent of all voice traffic becoming packet based, traveling
over the Internet. Thus, if you watched the movie “Deep Impact” this last spring of 1998, you
have an idea of what is going to happen to many of the existing telcos sharing the voice traffic.
My assessment is that the tides of VoIP are becoming so high, so attractive, that its impact
against the telcos will dramatically sweep many of them. Until they can reengineer they way of
business, and most importantly, the way they carry voice, to become what the VoIP Investor’s
Page (http://home1.gte.net/denunzio/) call “NextGen Communications Companies,” this
companies will experience many changes and “after impact” effects.

Therefore, let’s take a look on VoIP applications and what some of the main players are up to.
VOIP Applicability
Most implementations of VoIP are focusing on the first two benefit areas: cost-
savings/simplification, and extending the corporate telephone infrastructure to small sites. The
computer-telephony applications will certainly emerge, but adoption will be slower because
these applications require changes in workplace processes and possibly in computing
infrastructure.
There are, for example, several applications using Motorola's Vanguard Voice, as well as
many other vendors, as outlined later in this chapter. The following are some of Motorola’s
examples:
0 Small Office/Home Office Connectivity: Small branch offices and home-based
employees are taking advantage of inexpensive ISP connections and VoIP technology
to gain transparent access to large-site computing and telephone functions.
1 Intranet Telephony: A large nationwide bank in Latin America is using VoIP to carry
telephone calls between headquarters and some 800 branch offices.

2 DTMF Tone-Based Security: Many regionally-dispersed companies (in this case a
savings bank) use DTMF tones ("touch-tones") as a way for security monitoring
personnel to enter status codes as they patrol from site to site. Traditionally, these
systems require expensive leased lines, or they generate numerous PSTN calls. With
VoIP, the bank now routes the code-entry over the IP network that already reaches all
the necessary locations.
3 Next-Generation Telecommunication Service Providers: The advantages of VoIP
have not been lost on telecommunications carriers. One example is Net
Communications Inc., a "next-generation" telco providing international voice services
over its high-bandwidth IP backbone. Another is a satellite network operator,
providing IP telephony connections between Latin American companies and their
U.S. sales offices.
Some other areas of applicability for VoIP include computer telephony integration,
videoconferencing, document sharing and more.

Computer Telephony Integration (CTI)
One of the best examples of computer telephony integration (CTI) is SoundWare’s Telephony
Operating System (TOS), which is the original telephony on audio software platform and one
of the leaders in the industry. It enables high level PC telephony to be implemented without
costly, complex hardware and software. TOS is a TAPI compliant Windows extension for
managing host based signal processing/communication algorithms (hardware replacements)
running on x86 and Pentium Pro processors (MMX). TOS also supports all major audio chip
sets and is expected to play an important role in the migration to digital audio/processing
solutions.
TOS enables telephony applications to be migrated to the SoundWare TOS environment.
Developers can continue using standard Windows APIs. TOS supports MMX based SPMs for
computation intensive algorithms such as, modem data pump, digital mixing, and on the fly
sample rate conversions. TOS manages all aspects of call processing, providing a simple,
flexible, and open telephony platform for developers of signal processing and communication
algorithms.
But SoundWare is not alone, and many other suppliers offer similar products and services.
Some of them are featured in this chapter and chapter 9, “What to Expect: The Innovators.”
For now, lets continue to assess some of the other applicability of VoIP.
Videoconferencing
Video conferencing is becoming more available and affordable every day. It’s relatively easy
to use and of high quality, however, there are some factors that you should be aware. Video
conferencing is about bandwidth, or how much information can you get through the pipeline.
How much information can you compress, push through the pipeline, decompress it and how
fast you can do it. Below are few ways that Vivid Communications
(http://www.vividcommunications.com/Web_store/web_store.cgi) describes as meanings of
pushing videoconferencing to recipients:
0 POTS (Plain Old Telephone System) - Great for face to face - Can't fit data and
video at the same time.
1 ISDN -BRI (Basic Rate) up to 128 Kbps -(Two 64Kbs lines that can be banded
together) Best for the small business owner and telecommuters - decent frame rates
and data sharing capabilities.
2 ISDN -PRI (Primary Rate) up to 356 Kbps - More expensive, if you need the best
picture, this is the way to go.
3 Internet - Always depends on how many people are on the web and how good your
connection is at the time..

4 LAN / Wan - New multiplexers help push data through so as not to slow LAN
systems down. Excellent frame rates can be accomplished over LAN systems.
The smaller the bandwidth of the pipeline more compression/decompression and speed will be
needed. Some systems accomplish this with software and some with software and hardware.
Computers with a Pentium chip and at least a 28,800 modem are your best bets. The faster the
Pentium chip the faster compression/decompression can be accomplished. Systems that take
advantage of MMX technology will improve the frame rate as well.
Video capture cards usually work as a buffer. They will watch the picture and only work with
parts of the picture that have changed. In this way the computer does not have to reread an
entire picture over and over, but only the parts that have changed. Thereby speeding up the
capability of the system to read the parts of the picture that has changed. There is less
information for it to decompress and is not working with redundant parts of the picture.
The size of the picture will effect frame rate as well. The smaller the picture, the less pixels the
system will have to read, the better the picture. Another factor is the camera. CCD cameras are
digital cameras developed to deliver voice with picture (lip sinc). CCD cameras require a
video capture card. Some less expensive digital cameras plug into your parallel port and are
fine for Internet - family fun, but are less precise about getting the voice and the picture
together.
Currently, the best business video conferencing if you don't have a LAN system is through
ISDN lines. Data sharing and white boarding (plain white board that can be written on by both
ends) are possible over the ISDN bandwidth, while video conferencing. More bandwidth is
available by binding two or more ISDN lines. Some products do not have this ability.
Standards have been set by the ITU for video conferencing industry. Standards allow different
product brands to work together. Although the standards have been set some systems are still
proprietary (you need the same software on both ends to communicate). The standards based
systems are POTS H.324, ISDN H.320, LAN and Internet H.323 standards have been set for
voice and data sharing as well.
Turning a laptop computer or a desktop computer into a complete board room setup can be
easy and economical. Try displaying the conference over one of the Proxima or In Focus
overhead projectors. These projectors can be used for presentations of all kinds.
*****Start TIP*****
Vivid Communications has a very comprehensive book on video conferencing, by Even
Rosen's, entitled "Personal Videoconferencing." This book is very user friendly and gives an
in depth look at the current trends and the future of video conferencing.
*****End TIP*****
PicturePhone is another leading vendors supplying videoconferencing products and services,
providing:
0 ISDN video conferencing
1 LAN?WAN and Internet video conferencing
2 Analog video conferencing
3 Switched 56, 384 and T1 video conferencing
*****Start TIP*****
For more information on PicturePhone products and solutions, check their Website at URL
http://www.picturephone.com.
*****End TIP*****
Document-sharing
Document sharing, through technologies such as Compound Document framework, provides
support for synchronous collaboration between multiple users of a document. Several users
can edit a document in real time--each seeing the other's changes as they occur.
Netopia’s Virtual Office is a great example of it. The product allows you to collaborate to a
document in real time, while remotely connected to the Internet via Integrated Services Digital
Network (ISDN) routers and LAN/WAN office networks.
According to Netopia, to make NVO work, you will need a decent Internet connection. They
recommend at least a 56K-bit/ sec. connection and a recent browser, able to run Java applets
because NVO relies on them for its controls.
*****Start TIP*****
For more information on Netopia’s Virtual Office you can go to Geocities (www.
geocities.com) and set up a free Netopia account for the first year. (The second year costs less
than $20.)
*****End TIP*****
Web-Based Call Center Applications
Web-based call centers are one of the fast growing VoIP-derived applications. Micron
Electronics, have already implemented their Web-based call center since spring of 1998, and
they are not alone. The convergence of call centers and the Internet is taking place in the space
defined by the use of VoIP technologies, interactive Web browsing, and the integration of
existing call-center technologies such as automated call distribution modules and PBX
switches with IP gateways.
Some early products only use the Web to initiate a callback by an agent, but the majority of the
latest Internet call centers solutions are integrating the Web with the back office of a call
center, where the Internet becomes truly an extension of a call center.
Lucent Technologies, NetSpeak and eFusion are some of the companies offering Web-based
call-center products and solution, with starting prices at $100,000. Most of the applications
work along this paradigm: A customer navigating through sales or technical support
information wants more detail. A button on the page connects this customer to an agent via
voice over IP or text-based chat. In the most fully integrated Web-based call center, user
information is retrieved at the time of the call; this can come from v-cards, cookies, log-on
information, or forms.
But don’t think IP technologies are going to overrun existing call centers. I believe the existing
PBXs are going to stick around and VoIP will just complement it, providing a powerful
combination of IP and PBX in the same server environment.
VOIP Challenges
Not surprisingly, VoIP has some challenges ahead. From getting telcos investing on it through
setting and agreeing on a standard, it will take some time until we see major developments in
this area. Let’s take a look at some of these challenges.
Getting Telcos up to speed
During the fall of last year, Qwest Communications, a Denver-CO telco company, began
offering long distance phone services to consumers at 7.5 cents-per-minute! But the most
surprising news to the telecommunication industry was not the fact that Qwest had undercut
the competition by 50 percent, but the keen company was using voice over IP (VoIP)
technology.
Qwest’s move got telcos talking. AT&T, Sprint and even WorldCom were arguing that VoIP
was not ready for prime time. To this date, Spring of 1998, no one is using VoIP yet, so the
company is gaining a lot of momentum with this new technology. Qwest is planning to offer
not only long distance phone services, but also virtual private networks (VPN) and concurrent
engineering, where engineers collaborate over the network using high-bandwidth CAD
images, especially since bandwidth is not a problem.
Telcos will have to get up to speed, not only with the technology, but also convincing their
board of directors and stockholders that VoIP is here to stay. Meanwhile, as I write this
chapter, some of them are trying to stall Qwest (and the technology!) through lawsuits!
Setting standards
The following are the main protocol standards used with VoIP technologies, instrumental in
the development of Open Telecommunications.
H.323
The International Telecommunications Union (ITU) recommendation H.323, issued May 28,
1996, describes how terminals and equipment can carry any combination of real-time voice,
data, and video, including video telephony, over a local area network.
0 H.323 is sometimes referred to as an "umbrella" recommendation, since it contains
references to most of the other recommendations, including

1 H.225.0 packet and synchronization
2 H.245 control
3 H.261
4 H.263 video codecs
5 G.711, G.722, G.728, G.729, and G.723 vocoders
6 T.120 series of multimedia communications protocols.
Together, these specifications define a number of new network components (H.323 terminal,
H.323 Multipoint Control Unit (MCU), H.323 gatekeeper and H.323 gateway), all of which
interoperate with other standards-compliant end points and networks by virtue of an H.323
gateway.
The H.323 specification includes a list of vocoders allowed in H.323 compliant clients and
gateways. The G.723.1 vocoder has been specified as the default vocoder for H.323; all clients
and gateways must support G.723.1. This guarantees interoperability at the vocoder level.
Once two entities have established that they both support G.723.1 during the call setup, they
can negotiate to find a mutually preferred vocoder and can use that instead.
Virtually every company in the IP telephony market has announced plans to be H.323-
compliant. This list of companies includes Microsoft, Netscape, and Intel, providers of the
most widely deployed client software in the market. Natural MicroSystems supports H.323 in
the Fusion IP telephony development platform (see chapter 9, “What to Expect: The
Innovators,” for more information on Natural MicroSystems.)
H.100/H.110
H.100, approved on May 23, 1997 by the Enterprise Computer Telephony Forum (ECTF), is a
standard designed to further spur the growth of the CT. H.100 provides for a single telecom
bus superseding all existing bus architectures including MVIP and SCbus.
The H.100 bus is interoperable with the current industry telecom buses, allowing developers to
integrate newer H.100-based products with existing products. It is the telecom bus standard to
use in conjunction with the PCI bus standard for personal computers but easily interconnects
with telecom buses on ISA/EISA boards.
H.100 supports an 8-Mbps data rate and 128 channels per stream for greater bandwidth than
that provided by previous telecom buses. H.100 provides a total of 4,096 bi-directional 64-
kbps timeslots, permitting up to 2,048 full-duplex calls. This compares to 512 timeslots for
MVIP-90, 1,024 for the SCbus in PCs, 2,048 for SCbus on VME, and 3,072 for H-MVIP.
The increased number of timeslots provides greater communications capacity, due to the
introduction of a 68-pin fine-pitch ribbon cable which is physically smaller than the existing
40-pin regular-pitch MVIP cable. H.100-based boards can be interconnected with MVIP or
SCbus boards via a passive transition device, commonly called a "swizzle stick," that allows
the connection of the different ribbon cables.
In systems comprised of a combination of boards, the master clock must be an H.100 board.
H.100 master clock circuits also include compatibility clocks for driving existing MVIP and
SCbus boards that operate in clock slave mode. To facilitate operation with MVIP and SCbus
boards, H.100 allows individual data lines to be programmed in groups of four to operate at 2,
4 or 8 Mbps, allowing direct connection to existing boards at their native operating speeds.
The H.100 specification incorporates technology from GO-MVIP such as the programmable
operating speeds technique of H-MVIP and redundant clocks from MC1 Multi-Chassis
MVIP. As mentioned, programmable operating speeds provide support for the interoperation
with MVIP and SCbus boards. The redundant clock eliminates a single point of failure. If any
telecom board fails, including the H.100 master clock, the system will continue to operate.
H.100 offers developers and integrators extensive new capabilities. It brings more capacity
than any existing bus, enabling developers to deliver larger and lower-cost applications.
H.110 is the CompactPCI version of the H.100 standard. This standard allows hot-swapping
of boards in CompactPCI chassis from the PCI Industrial Computer Manufacturer's Group
(PICMG), offering customers the option of a CT system with virtually no down-time. This
enables automated call centers, IP gateways, and voice messaging systems to remain up and
running until there is a convenient time to replace a failed board.
MVIP
Multi-Vendor Integration Protocol (MVIP) is the de facto industry standard hardware and
software architecture for platform interoperability and telephone switching among ISA and
PCI-based computer systems. Natural MicroSystems and six other companies developed the
original MVIP standard in 1990. The most widely deployed standard for interoperability
among computer telephony vendors, MVIP is now maintained by the Global Organization for
MVIP (GO-MVIP), an independent organization.
The MVIP family of standards addresses both configurations of networked PCs and single
computer chassis configurations. Several hundered companies support MVIP’s open scalable,
switching architecture. Over 200 MVIP-compatible products are available on the market.
CompactPCI
CompactPCI, initiated in 1994 by Ziatech Corporation under the auspices of the PCI Industrial
Computer Manufacturers Group (PICMG), is the newest specification for PCI-based industrial
computers and defines many features that make a PC more available.
CompactPCI offers a host of telecom features required for network applications including:
0 A standard telecom bus (32 streams and 4096 time slots) for communications
between cards in a chassis rack
1 A telecom form factor (6U card heights with rear panel I/O)
2 Hot swap capability with staged pins and system notifications with card tab release,
allowing systems to be upgraded or expanded, or cards replaced without taking
servers off-line
3 No interruption of system operation if a subsystem module fails
4 Redundant chassis and board configurations for highly available resource
requirements
5 Redundant power management, CPUs, disks
6 Software compatible with mass market PCI systems

7 Telecom power bus (- 48 V DC) and provision for ringing voltage
8 Transition cards and cabling assemblies to simplify installation
The principal benefits of CompactPCI include:
0 An open, industry-accepted specification eliminating the proprietary nature of
previous high-availability systems
1 Compatibility of software from standard PC (PCI) systems to CompactPCI systems -
existing PC software can run unchanged on CompactPCI systems
2 Delivery of hot-swappable telecom features required for
3 Higher reliability through hot swapping of components
What’s Next
Next chapter, “What to Expect: The Innovators,” assesses what is being offered by VoIP
innovators such as NetSpeak, NetPhone, Vocaltec, TeleVideo Conversions, Inc., Vienna
Systems, Lucent Technologies, and few others.

Chapter 9
What to Expect: The Innovators
This chapter provides you with a brief profile of the major players in VoIP technology, and
technical overview of their main VoIP products available on the market as of spring of 1998. I
made sure to include a vast and extensive selection of all the major players and their products
so you can have a chance to evaluate each one of them before deciding which product best
suite your needs.
This selection includes many different VoIP technologies and products, from 3Com’s Total
Control Hyper Access system and Motorola’s VIPR, to Nuera Communication Access Plus
lines and a series of Internet phones.

Of course, I’m not in the position of recommending any of these products as the requirements
and features of VoIP products change depending of your environment. Although I may have
my preferences, it probably would be a biased one, which would be directly related to the
environment I work with and my own preferences. Thus, all the information you find in this
section was totally provided by the respective vendors outlined here. Some provided more
information than others. By no means you should opt for any of these products based on the
amount of pages or details here provided. Most of the vendors listed here also provided demo
and/or evaluation copies of their products in the CD that accompanies this book. Make sure to
refer to it for additional information.
Some of VoIP Major Players
In order to make an informative decision when selecting a VoIP product or service that best
suites your needs, I strongly encourage you to carefully read this chapter, and summarize on a
table all the features you are looking for, or need, for your organization. Then, I suggest you to
check the CD and products you selected and run a complete “dry-run” on them before you can
really make a decision. Also, don’t forget to contact the vendor directly, as these products are
always being upgraded and new features incorporated to them, which could make a difference
in your decision. Contact information and a brief background about the vendor is provided at
the beginning of every section of the product covered.
3Com’s Total Control HiPer Access System
3Com provides a single platform that combines multiple services for real-time interactive
communications to VoIP using standard telephones all the way to VPN, multimedia and more.
The Total Control multi-service access system leverages the inherent strengths of the 3Com’s
Total Control platform’s HiPer DSP technology and EdgeServer Pro module to offer a
powerful integration of Internet and voice technologies.
3Com’s Total Control System: Maximizing Internet Technologies.
3Com’s Total Control System provides simultaneous voice and Internet access over the same
connection for the ultimate in collaborative computing, customer support, increased
productivity and cost savings.
One of the main strengths of the Total Control chassis is the ability to add custom features to
the powerful DSPs on the HiPer DSP card. Each HiPer DSP card can handle 24 phone lines
(30 in Europe), and the EdgeServer VoIP system can handle 13 HiPer DSP cards. On each
DSP card, the 12 Texas Instrument TMS320C548 DSPs process data at 100 MHz each.
These large compute engines allow for preprocessing of most of the bit-intensive work on the
DSP. The preprocessing allows the Total Control chassis to forward packets quickly and to
handle large numbers of ports since the work for each channel is handled in parallel. When all
CPUs involved in a fully configured EdgeServer Total Control chassis are lumped together,
nearly 34 billion instructions per second (34,000 MIPS) are used.
This massively parallel approach has been used in the past by 3Com to allow the Total Control
remote access servers to pre-process PPP packets to achieve high packet rates. These DSPs
can be programmed on a per call basis to handle an incoming call as a modem or ISDN call
for remote access, a FAX call, a VoIP call or a Video conferencing call. This flexibility to add
new functionality to an open programmable DSP provides investment protection for the user.
It also enables system operators to provide multiple revenue generating services on a common
access platform. Because VoIP and Video use the existing HiPer DSP cards that are used in
the Total Control Remote Access Concentrator, the incremental cost to add these features can
be kept low.
3Com shines with it's carrier class VoIP/Video solution, the EdgeServer
(www.edgeserver.com). The EdgeServer is a complete PC server that runs open operating
systems and fits in the Total Control chassis. Currently only Windows NT 4.0 supports full
connectivity to the HiPer DSP cards on the EdgeServer.

Windows NT 4.0 provides a full-featured and stable platform with the standard telephony
interface TAPI. TAPI is a connection layer that allows telephony applications like call control
to interact with telephony-enabled devices like our HiPer DSP drivers. TAPI version 3.0
enables very large telephone systems to be built via master/slave TAPI. The slave TAPI
process would run on the EdgeServer driving the HiPer DSP cards in each Total Control
chassis. The master TAPI process could reside on a local stand-alone PC and act as the overall
call control agent for the entire slave TAPI chassis. The master TAPI agent could also be in a
remote location providing a single point of control for geographically dispersed chassis.
In addition to providing the industry standard TAPI interface for customer customization,
EdgeServer has a wide variety of useful development tools such as Visual C++, Visual Basic
and Borland's Delphi.
*****Start TIP*****
For more information about 3Com’s VoIP Products, check the URL http://www.3com.com.
*****End TIP*****
3Com and eFusion: Enhancing VoIP
Enhanced VoIP features, such as call forwarding, call waiting and other business-oriented
capabilities are becoming reality already. As I write this section 3Com engages in a
partnership with eFusion Inc. to develop a series of VoIP applications based on Total Control
remote access concentrator.
Although this book will be released before the scheduled release of the product, which is
scheduled for the fourth quarter of 1998, make sure to seek more information about it, as
3Com plans to support a variety of eFusion applications, including those tailored to enhanced
Internet telephony services, as well as E-commerce applications such as its Push-to-Talk voice
and Internet browsing product. All of the applications are still H.323-compatible, ensuring
operability across product lines.
Sound Design’s SoundWare
The Telephony Operating System (TOS), is a patented TAPI compliant Windows extension
for managing host based signal processing/communication algorithms (hardware
replacements) running on x86 and Pentium Pro processors (MMX). TOS supports all major
audio chip sets and is expected to play an important role in the migration to digital
audio/processing solutions.
Telephony applications can be migrated easily to the SoundWare TOS environment.
Developers can continue using standard Windows APIs. TOS supports MMX based SPMs for
computation intensive algorithms such as, modem data pump, digital mixing, and on the fly
sample rate conversions. TOS manages all aspects of call processing, providing a simple,
flexible, and open telephony platform for developers of signal processing and communication
algorithms.
SoundWare runs on any standard PC sound subsystem without requiring a modem, enabling a
SoundWare "phone ready" multimedia PC or sound card to add telephony and communication
functions as mainstream features. SoundWare provides PC bus independence, scalability via
host-based algorithms, full hardware and software integration with the standard PC audio
channel, and complete software integration with the Windows multimedia, telephony, and
communication APIs. In order to make SoundWare Ready offerings, PC OEMs and audio
vendors are adding a simple, low-cost Universal Audio Link header to their existing mother
boards, sound cards, and combo cards without making any architectural changes
*****Start TIP*****
For more information on Sound Designs’s Soundware product, check their URL at
http://www.soundesigns.com.
*****End TIP*****
Natural MicroSystems’ Fusion
Natural MicroSystems (http://www.nmss.com/nmss/nmsweb.nsf/nmshomeview/nmshome ) is
one of the leading suppliers of Open Telecommunications enabling technologies for
developers of high value telecommunications systems and applications built on standard
computing platforms.
Open Telecommunications is about moving the telecommunications equipment business to
open, mass-market computing platforms. Natural MicroSystems builds hardware and software
component products that enable developers of telecommunications equipment to build their
applications and systems using these open platforms. Their solutions are based on open
standards that make it possible for their partners to quickly develop high-performance, high-
capacity multimedia communications systems and applications. We help our partners create
new markets, new value for their customers, and new opportunities to grow.
The value of Open Telecommunications is the ability it gives developers to take advantage of
standards-based building blocks, reducing time to market when creating complex applications.
The Natural MicroSystems family of products provides fundamental functions that adhere to
widely accepted standards for easy integration into communications networks around the
world. Their solutions are based on standard computing platforms, such as PCs, so that
developers can take full advantage of the wealth of products, tools, and support that open
systems provide while also offering truly global communications products.
For more information about the Natural MicroSystems, please check their Website at URL
http://www.nmss.com/nmss/Nmsweb.nsf?OpenDatabase, or contact them at: 100 Crossing
Blvd., Framingham, MA 01702-5406 - Tel: +1 800 533 6120, Tel: +1 508 620 9300, Fax: +1
508 620 9313 .
*****End NOTE*****
Fusion
Fusion is the industry's most scalable, highest-performance PC development platform for
standards-based IP Telephony gateways. Fusion is compliant with both the International
Telecommunications Union's (ITU's) H.323 specification and the International Multimedia
Telecommunications Consortium's (IMTC's) Voice over IP (VoIP) Implementation
Agreement. Fusion enables developers to create gateways with configurations from 8 ports to
multiple T1s/E1s with no increase in latency or decrease in performance. Building on its basic
configuration of a full T1 of IP Telephony in only two ISA slots, Fusion's scalable architecture
supports the highest port capacity of any solution on the market.

Fusion uses an intelligent hardware and software architecture that integrates Public Switched
Telephone Network (PSTN) interfaces, telephony protocols, speech encoding, LAN interfaces
and data protocols into a cohesive, flexible package. Incorporating a series of highly accessible
Application Programming Interfaces (APIs) and a group of dedicated boards that
communicate with each other via the industry-standard Multi-Vendor Integration Protocol
(MVIP), Fusion offloads key processes from the host CPU and memory.
Features
Here is a summary of Fusion’s main features:
0 Supports the highest capacity (multiple T1s/E1s) of any standards-based H.323
development platform.
1 Offloads processing from host CPU and memory to minimize latency, maximize
scalability, and free resources to run higher level applications.
2 Supports ITU's H.323 specification and IMTC's VoIP recommendation, enabling
interoperability with other H.323-compliant clients and gateways.
3 Supports Gatekeeper functions for address translation, control access and bandwidth
management.
4 High performance/low latency does not degrade as system scales from 8 ports to
multiple T1s/E1s.
5 Supports the broadest choice of standard vocoding algorithms, including G.723.1,
G.729A, MS GSM, and VoxWare MetaVoice RT24.
6 Embeds standard Internet protocols on a dedicated board for maximum performance,
including Transmission Control Protocol / Internet Protocol (TCP/IP), User Datagram
Protocol (UDP), RealTime Protocol/RealTime Control Protocol (RTP/RTCP).
7 Compact footprint, supporting T1/E1 of IP Telephony capability in only 2 ISA slots.
8 Utilizes MVIP, an industry-standard, dedicated TDM bus that acts as a switching
fabric among the DSP resources, PSTN interfaces, and LAN ports, easing integration
with other MVIP-compliant products.
9 Supports a broad range of industry-standard clients, including Microsoft NetMeeting,
NetScape Conference, VoxWare VoxPhone, Netspeak WebPhone, and VocalTec.
10 Ideal for toll bypass, voice and fax messaging, LAN telephony, web-enabled call
centers, interactive voice response (IVR), and remote teleworking applications.
Fusion integrates hardware and software within a standard PC, greatly simplifying
development and deployment of IP Telephony gateways. Fusion's field-proven hardware

components and industry leading APIs minimize programming requirements and maximize
flexibility.
Fusion Hardware
Fusion consists of three hardware components that occupy two ISA slots in a standard PC: an
Alliance Generation T1 or E1 (AG-T1 or AG-E1), an AG Realtime daughterboard, and a TX
Series board.
The AG-T1/E1 provides 24/30 ports of processing for voice and fax plus a full T1/E1 digital
PSTN network interface (including PRI ISDN). An 8 port AG-8 can be used in lower-capacity
configurations.
The AG Realtime/2 daughterboard, which attaches to the AG-T1/E1, provides real-time
vocoding for ports on the baseboard. Using the MVIP bus, the combination of the AG-T1/E1
and AG-Realtime/2 pass traffic to Fusion's third hardware component, a TX2000 or TX3000
board.
The TX Series boards support integration of encoded speech with an Ethernet LAN, which
can be an Internet or Intranet connection. The TX Series board converts encoded speech to IP
packets and supports IP routing and data protocols. The TX boards are available with a wide
variety of common data communications interfaces, including 10Base-T and 10Base2
Ethernet.
These three boards, applied within two ISA bus slots, support a full T1/E1 of IP Telephony
capability without taxing the host CPU. Because the processing takes place on the boards,
multiple Fusion board-sets can be installed in a single chassis, supporting up to four T-spans
or E-spans of IP telephony with no degradation of performance and no increase in latency.
This allows OEMs, systems integrators, and VARs to create the highest capacity in the
industry for a standards-based IP Telephony gateway.
Fusion Software
The Fusion software development kit consists of multiple APIs:
0 Telephony API (CT Access) for gateway call control and voice processing
1 Switch Service API (CT Access) for interconnection of telephony and IP network
resources
2 Vocoder API (CT Access) for control of speech encoding
3 Packet Network API (TX Series Libraries) for control of IP network protocols
4 H.323 API for IP Telephony call control

When Fusion applications receive incoming calls, they spawn caller threads and use CT
Access to perform the following tasks: application initialization, port initialization, calls
control, event processing and error handling, and parameter management. Additionally, CT
Access's Switch Service provides a way of making, breaking, and controlling the MVIP
connections between Fusion boards. Developers can use the Switch Service to permanently, or
dynamically create data pathways between the telephone line interface and the AG Real-time
daughterboard and TX Series Ethernet interface.
Packet Network Integration
The TX control interface is composed of six APIs and a Communication Processor Interface
(CPI) library. The CPI library provides a conduit for communicating with the TX series board.
The APIs provide functions that simplify control of TX features, such as Virtual Port
communication, RTP/RTCP, and embedded UDP routing.
Broadest Selection of Vocoders
Fusion supports the broadest range of vocoders for maximum flexibility of gateway
deployment. In addition to the ITU G.723.1 and G.729A algorithms, Fusion also supports
Microsoft-GSM and the widely deployed VoxWare MetaVoice RT24 algorithm, which is
utilized by Microsoft in the popular NetMeeting client software and by NetScape in the
Conference client software. Fusion also provides an open vocoder platform for easy porting of
other algorithms as they gain market share or are approved as standards. A CT Access
Realtime TRAU () library provides a way to start and stop vocoders and a way to manage AG
Realtime processes at the board level. The vocoders are combined with integrated tail-end
echo cancellers on the AG Realtime board.
H.323 Protocol
H.323 is a broad standard from the ITU that sets specifications for audio, video and data
communications over IP-based networks that do not provide guaranteed quality of service
(QoS). Additionally, H.323 specifies a series of vocoders to guarantee interoperability among
gateways and clients from different vendors. The IMTC has chosen H.323 as the basis for the
Interoperability Agreement V1.0 for IP Telephony gateways.
Fusion's H.323 support includes H.225 and H.245. H.225 specifies the syntax and semantics
for negotiation at the start and/or during communication. H.245 specifies media packetization
and call setup. For applications that have unique protocol requirements, other stacks may be
substituted into Fusion's software architecture. Fusion's software architecture embeds
RTP/RTCP on the TX Series board and keeps the remaining H.323 functionality on the host.
This partition enables low end-to-end latency and relieves the host from processing real-time
audio packets.
RTP/RTCP Library
RTP and RTCP are the accepted H.323 standards for passing real-time data streams over an IP
network. Fusion's RTP API provides applications with low-level control over connections that
pass real-time data between a circuit-switched network and an IP-based packet network. All
RTP connections are initiated, monitored, and eventually terminated via the RTP API.
The RTCP API allows an application to receive RTCP-related information. An RTCP monitor
task may be developed for collecting RTCP statistical information on the host. This will allow
for QoS monitoring during a session and provide a mechanism for collecting session-specific
billing information.
User Datagram Protocol
Within the IP stack, the User Datagram Protocol (UDP) provides “unreliable services”. Fusion
supports UDP on the TX Series board. In addition, a host can view the TX Series board as a
simplistic NDIS Ethernet board, enabling simultaneous use of the TX board as an intelligent
UDP/RTP device and as a host-controlled network interface board. This means that host-
based TCP-UDP protocol stacks can be used for command and control events for gateway call
session establishment.
Programmable Jitter Buffer
A unique feature of Fusion is its programmable jitters buffer. As voice packets are transferred
across a network without guaranteed QoS, voice packets may be lost or arrive out of sequence.
A jitters buffer collects incoming packets and enables Fusion to rearrange the packets into the
correct order or to smooth over lost packets. The size of the jitters buffer is configurable on a
per channel/session basis, offering a unique feature to control latency for real-time, interactive
voice conversations.
Vocoders Supported
The following is a list of vocoders supported by Fusion:
0 G.723.1
1 G.729A
2 Microsoft GSM 6.10
3 VoxWare MetaVoice RT24

Protocols Supported
The following are the protocols supported by Fusion:
0 TX 2000/3000
1 UDP (on TX board)
2 RTP/RTCP
Motorola’s VIPR
Motorola VIPR is a powerful line of IP telephony products that enable real-time voice and fax
communications over the Internet or private Intranets. VIPR is a new part of the standards
based MPRouter and Vanguard, Motorola's market-leading family of network accesses
devices.
VIPR enables voice and fax traffic to move off the telephony infrastructure and onto the IP
data network. By combining data, voice and fax, expensive long distance toll charges or the
need for dedicated voice circuits are eliminated, reducing or even eliminating unnecessary
charges for data, voice and fax.

The possibilities for implementing value added service for your network users are great.
Motorola’s VIPR technology enables an easy move to VoIP, being totally transparent to
network users. Applications of Motorola's VIPR include:
0 Cost savings on long distance calls, as they can be placed over the Internet or Intranet,
eliminates long distance charges
1 Network access for traveling and telecommuting employees who can dial into the
network to check voice mail, dial another location, or call an extension for the cost of
a local connection.
2 Optimal bandwidth use by minimizing networks traffic and maximizing performance.
Together the MPRouter and Vanguard families provide the industry's most advanced voice
and fax support. These versatile network access devices also offer comprehensive support of
Frame Relay, ISDN, LAN routing, legacy data protocols, WAN bandwidth optimization and
worldwide support for either digital or analog PBX/PABX features. Since all VIPR products
are remotely upgradeable and based on a high performance DSP platform, they're ready for
future technologies such as RSVP and RTSP, when they become available. In addition,
Motorola's VIPR line is also H.323 compliant and interoperates with Microsoft NetMeeting as
well. These advanced features and our commitment to standards-based implementation makes
Motorola VIPR the smartest way of bringing voice and fax to IP data networks.
Below is a summarized list of features and benefits of Motorola’s VIPR:
0 Real-time voice and fax over IP networks
1 Motorola Optimized 8K and 16K CVSELP voice compression provides high quality
voice
2 Utilizes Digital Speech Interpolation (DSI) to minimize wasted bandwidth
3 Voice Switching using DTMF digits
4 Built-in echo cancellation eliminates the need for expensive external hardware
5 Cost effective concentration for T1/E1 PBX trunks
6 Fax demodulation at 9,600 or 4,800 bps
7 Integrated fax/voice on same port
8 Dedicated DSP hardware ensures maximum compression
9 Lowest price per port
(FXS, E&M, server card)
10 Easy to install and upgrade into existing units

Nuera Communication’s Access Plus Series
Nuera Communications is one the leading provider of high-quality packet voice
communications equipment and technology for voice/data/image networking over TDM,
frame relay and IP networks. Nuera is also a member of the Frame Relay Forum and a co-
founder of the VoIP Forum, with great expertise on voice coder development and standards
implementation, packet-network optimization, call processing, and network design,
installation and support. Nuera also delivers industry-leading DSP-based solutions that
optimize bandwidth utilization while maintaining the highest standards of quality for voice
traffic and maximum transparency for other applications including fax, signaling, voice-band
data and video. Figure 9.1 is a screenshot of Nuera’s Website at URL http://www.nuera.com.
Figure 9.1
Nuera Communications’ Website
Nuera serves carrier, corporate and OEM customers requiring superior voice quality and
advanced call-processing capabilities. Nuera is known for its high-quality voice compression
at any given rate, as well as its systems for voice/data/fax integration between remote sites.
Over 25,000 Nuera systems with over 200,000 voice fax channels are in operation worldwide.
In addition, Nuera offers voice compression algorithms including the latest industry standards
as well as enhanced, proprietary technology delivering even better quality at very low bit rates.
Nuera's voice technology provides high-quality communication at rates from 4.8 to 32 kbps.
For more information, contact Nuera Communications, Inc.’ 10445 Pacific Center Court, San
Diengo, CA 92121. You can also reach Nuera via telephone at 619-625-2400 or fax at 619-
625-2422. You can also check their Website at URL http://www.nuera.com.
*****End NOTE*****
The Access Plus F200
According to Nuera’s specifications, the Access Plus F200 is the highest performance voice
over Frame Relay access device (FRAD) featuring the industry's best voice quality with
Enhanced-CELP (E-CELP) and ITU-standard voice compression. The F200 offers integral
switching capabilities and advanced traffic management features, and delivers full T1/E1
throughput on multiple high-speed trunks or data ports. The unit includes analog and digital
(T1/E1) interfaces to PBXs or PSTNs and offers capacity for up to 30 voice/fax channels per
unit.
The Access Plus F120
The Access Plus F120 provides voice over Frame Relay system, outperforming all eight other
systems in audio quality, delay and bandwidth utilization in independent National Software
Test Labs testing completed September 1996. The F120 provides analog and digital (T1/E1)
interfaces to PBXs or PSTNs and offers capacity for up to 30 voice/fax channels per unit. The
product uses award-winning Nuera Enhanced-CELP (E-CELP) voice compression and packet
optimization, plus ITU-standard compression algorithms.
Advanced Voice Compression
The Access Plus F120 Frame Relay Access Device provides the highest quality voice
compression technology in the industry, with complete selection of ITU standard algorithms
including G.726, G.728 and G.729 E-CELP algorithms operating at 4.8, 9.47 and 9.6 kbps
provide industry-leading quality at each rate. Its adaptive silence suppression substantially
minimizes bandwidth usage during speech breaks and maintains natural-sounding

conversation, while its integral echo canceller adapts from 0-49 millisecond to ensure
consistent voice quality for all calls.
Access Plus has a unique voice frame packing feature that optimizes bandwidth over cell-
based backbones or low-speed access lines and low-delay voice encoding and adaptive jitter
buffer minimize end-to-end speech delay while asymmetric fax channels minimize return path
bandwidth usage. The product is compliant FRF.11 Voice over Frame Relay Implementation
Agreement.
Call Routing
The F120 provides complete call processing and switches each call independently. Some of
its features are:
0 Minimizes implementation and recurring operations costs
1 Reduces the number of ports needed
2 Eliminates tandem calls on the network
3 Calls can be routed through F120s so the voice network can be fully meshed at
minimum cost
4 Call routing can control the bandwidth used by voice calls to guarantee data
performance
5 Uses clear channel CCS mode for ISDN
Call Processing
The F120 builds on the voice switching capability by providing complete call processing and
digit translation, as shown on figure 9.2:
0 Complete end-to-end flexibility independent of voice interfaces
1 E&M analog interface ports can connect to digital FXO interface ports directly
without conversion equipment
2 Digit translation provides a unified dialing scheme capable of 20 digit translation and
40 digit outpulsing
Figure 9.2
Nuera’s F120 is built on voice switching technologies
Data Frad and Switch
The F120 is both a data/voice FRAD and a frame relay switch, very easy to integrate into
existing data networks, and supporting both the DTE and DCE sides of the UNI interface. It
functions as a frame relay network to attached devices including routers and front-end
processors.
Digital Interfaces
The F120 makes installation and expansion easy by providing direct T1/E1 interfaces for
voice ports. It also eliminates unnecessary digital-to-analog conversions and subsequent
distortion, and simplifies tuning of the voice ports so that the volume levels are more
consistent across all ports
Access Plus F200ip
The Access Plus F200ip is an integrated voice over Internet/voice over Frame phone-to-phone
gateway, bringing voice quality to Internet applications by delivering IP voice via Ethernet and
Frame voice via high-speed serial trunks.
A High Performance System
The F200ip provides flexibility in network protocols for optimizing quality/cost
tradeoffs:
0 Runs both voice over IP and voice over frame relay concurrently
1 Can switch voice calls from any port to any port over any protocol
2 Simple LAN installation and provisioning when using IP
An Advanced Voice Compression
The Access Plus F200ip provides the highest quality and widest range of voice compression
technology in the industry:
0 ITU G.728 LD-CELP, G.729 CSA-CELP, and G.726 ADPCM standard algorithms
from 8 kbps to 32 kbps
1 E-CELP advanced proprietary algorithms operating at 4.8, 9.47 and 9.6 kbps provide
industry-leading quality at each rate
2 Low-delay voice encoding and adaptive jitter buffer minimizes end-to-end speech
delay
3 Integral echo canceller adapts from 0-49 millisecond to ensure consistent voice
quality over long tail circuits
4 Sophisticated lost packet recovery methods help maintain consistent quality in harsh
environments
5 Voice compression rates negotiated to provide configuration flexibility

6 Modem transparency over voice channels
High Bandwidth Efficiency
Another unique feature of the F200ip is its incorporated technology, designed to minimize
WAN bandwidth. Features include:
0 Programmable voice packeting improves bandwidth efficiency
1 Adaptive silence suppression minimizes bandwidth usage during speech breaks and
maintains natural-sounding conversation
2 Asymmetric fax channels minimize return path bandwidth usage
3 Data fragmentation configurable on a DLCI basis to minimize delay of voice traffic
over low-speed interfaces
Call Routing
The F200ip provides complete call processing by switching each call independently with full
digit and interface translation. Below are some of its characteristics:
0 Minimizes the number of ports needed
1 Eliminates tandem calls on the network

2 Call switching allows the voice network to be fully meshed at minimum cost
3 Digit translation provides a unified dialing scheme capable of 20 digit translation and
40 digit outpulsing
4 Complete any-to-any connectivity, independent of voice interfaces
5 Generates call detail records for per-call billing
Flexible Voice Interfaces and SNMP Network Management
The F200ip provides direct T1/E1 interfaces for voice ports, up to 24/30 channels. The T1/E1s
eliminate digital-to-analog conversions and subsequent distortion. Also, F200ip has analog
interfaces programmable with a wide range of options -- FXO, FXS, E&M.
A Brief Overview of NueraView
Through NueraView, you have a robust configuration, statistics, diagnostics, and alarm
management. Its database assures that configuration information is safely backed up. The
NueraView SNMP network management system (NMS) is a powerful system, which allows
the network operations, staff to manage networks with minimum effort. The graphic user
interface provides advanced NMS functions such as configuration, monitoring, diagnostics,
statistics collection, and alarm collection.

NueraView simplifies network management while boosting performance across multi-node
networks with voice/fax/data/video traffic, as shown on figure 9.3.
Figure 9.3
Network management is simplified through Nuera’s NueraView
Increased Network Uptime
By providing instantaneous alarms graphically displayed on a network map, NueraView helps
isolate faults quickly, such as:
0 Faster fault resolution – graphical alerts highlight problems as they occur
1 Easier restoral – configuration database use for system replacements
2 Fewer configuration errors – pull down menus make typing unnecessary
3 Remote dial access – full control of network from remote NMS possible
4 Consolidated/central management – monitor all devices on single map
Easier Operations
NueraView enables configuration time for systems to be minimized (see figures 9.4, 9.5 and
9.6 for screenshots of its GUI interface):

0 Point and click to change configuration and to view status and trap logs – faster and
more accurate than typing
1 Hierarchical graphic network map – arrange your network items logically while
maintaining full monitoring capability
2 Offline node configuration and staging – preconfigure nodes using templates
3 Configuration templates – all parameter options readily viewable
4 Online help and documentation – point and click through user guide
5 Remote dial access into NMS console – you can monitor your network from
anywhere
6 Code and configuration downloads – upgrade code or configurations from your
central site
Figure 9.4
NueraView’s Easy to use configuration utility
Figure 9.5
NueraView leverages the extensive software control provided by the Access Plus F-Series
Figure 9.6
Dial plans are simple to design and maintain
Portable Voice Module
Portable Voice Module is a OEM package, delivering top-rated voice support to customers'
FRADs, routers or other data devices connecting to TDM, Frame Relay, IP or ATM networks.
It also features Nuera's Enhanced-CELP and ITU-standard voice compression algorithms plus
Nuera's packet-network quality enhancements and call processing features package. It includes
DSP modules, telco interface modules and a host interface for the target platform, plus
software APIs to facilitate development and expedite time to market.
Access Plus 100 and Access Plus 200
Access Plus 100 and Access Plus 200 are both TDM-based voice compression and
voice/fax/data integration and bandwidth management systems. They feature Nuera's
Enhanced-CELP compression plus ITU standard algorithms, analog and digital voice
interfaces and capacity for up to 30 voice/fax channels per system as well as point-to-point and
point-to-multipoint capabilities.
Clarity Series CS8000 – Voice/Data Multiplexing
Clarity Series CS8000 is a TDM-based voice compression and voice/fax/data integration for
up to eight analog voice/fax channels, and engineered to enhance network performance by (see
figure 9.10):
Integrating multiple channels of voice, fax and data onto a low-cost digital circuit
Offering advanced voice card hardware features completely programmable interfaces
Easy configuration and proven system reliability produces “install-and-forget” wide area
networking
Low-delay data transmission rates (9.6 kbps to T1) support a wide range of devices including
bridges, routers, and video conferencing equipment
Voice Compression
The CS8000 provides delivery of consistent high-quality communication across a broad
selection of compression algorithms.
0 CELP algorithms operating at 5.3, 8, and 9.6 kbps provide outstanding voice quality
at each rate
1 Adaptive Transform Coding (ATC) compression rates are completely variable
between 7.47 kbps and 32 kbps
2 Integral echo cancellation (G.165 compatible) in excess of 32 msecs ensures voice
quality for off-net calls
3 Fax relay support provides transparent fax operation at 2.4, 4.8, 7.2, and 9.6 kbps
A wide range of connectivity solutions allows each location to be tailored for the lowest cost
configuration. Flexible allocation of bandwidth provides for numerous voice, data, and video
services on a T1 local loop interface. Also, advanced functionality over satellite, sub-rate or
T1 circuits allows users to build optimum network designs.
Qwest Communications’ Macro Capacity Fiber Network
Qwest Communications International, Inc. is a digital age communications company building
a high capacity, fiber optic network. With its cutting-edge technology, the Qwest Network is
able to provide high-quality data, video and voice connectivity with uncompromised security
and reliability to businesses, consumers and other communications service providers.
Qwest constructs and installs fiber optic communications systems for interchange carriers and
other communications entities, as well as for its own use. Qwest is expanding its existing long
distance network into an approximately 16,000 route-mile coast-to-coast technologically
advanced, fiber optic telecommunications network. The network will connect approximately
125 metropolitan areas that represent about 80% of all long distance traffic in the United
States.
Through a combination of the Qwest Network and leased facilities, the company will continue
to offer interstate services in all 48 contiguous states. The Network will connect to
international cable heads for transatlantic and transpacific transmission to Canada and Mexico.
Qwest recently extended its network to the United Kingdom through an exchange of capacity
for two 155-megabit circuits that will carry international data and voice traffic between
London and New York. The company also is extending its network approximately 1,400 route
miles into Mexico through dark fiber to be owned by Qwest on the fiber optic system of a
third party.
As the demand from interchange carriers and other communications entities for advanced,
high bandwidth voice, data and video transmission capacity increases, due to regulatory and
technical changes and other industry developments, Qwest strategically positions itself to
provide the products and service this high bandwidth demands. The company is also
committed to address the changes it generates. These anticipated changes and developments
include:
0 Continued growth in capacity requirements for high-speed data transmission
1 ATM and Frame Relay services
2 Internet and multi-media services and other new technologies and applications
3 Continued growth in demand for existing long distance services
4 Entry into the market of new communications providers
5 Reform in the regulation of domestic access charges and international settlement
rates, which Qwest expects, will lower long distance rates.
Qwest’s Macro Capacity Fiber Network
The Qwest Macro Capacity Fiber Network is designed to be the highest-capacity digital
infrastructure in the world. With wave-division multiplexing and advanced optical
transmission technology, it transmits with unprecedented speed, reliability and affordability.
By making available the following advantages, Qwest’s state-of-the-art infrastructure can very
likely become the communications backbone of digital America:

0 Quantum capacity - Designed with a transmit capacity of up to two terabits per
second, the Qwest Macro Capacity Fiber Network can carry more information than
any other United States communications network.
1 Hyper speed - Video, images and data (including VoIP applications!) can be sent
from coast to coast in the blink of an eye. At full capacity, the Qwest Macro Capacity
Fiber Network will transmit two trillion bits of multimedia content per second-or the
entire Library of Congress across the country in 20 seconds.
2 Absolute data integrity - The Qwest Macro Capacity Fiber Network is designed to
provide and offer unprecedented protection against data loss. Its Absolute Data
Integrity is the new world standard for error-free transmission. The network's non-
zero, dispersion-shifted glass, pure OC-192 transmission technology and advanced
SONET ring architecture ensure less than one bit of error in every quadrillion bits.
Actually, that's the equivalent of one grain of sand out of place on a 20-mile stretch of
beach. Consequently, this advantage of the Qwest Network sets a new world-standard
precedence of reliability and accuracy in data transmission.
3 Superior service reliability - The sophisticated fiber optics of the Qwest Macro
Capacity Fiber Network are encased in a thick plastic protective conduit buried in a
highly secure environment, principally along railroad lines. Moreover, the fiber is laid
out in an advanced SONET ring architecture that provides automatic, instant re-
routing should disruption of any kind occur.
4 Low cost position - The Qwest Macro Capacity Fiber Network's advanced fiber and
transmission electronics provide the company with lower installation, operating and
maintenance costs than older fiber systems that are typical in commercial use today.
In addition, Qwest has entered into construction contracts for the sale of dark fiber
along the route of the Qwest Network which will reduce Qwest's net cost per fiber
mile with respect to the fiber it retains for its own use. As a result of the cost
advantages, Qwest's low cost position will enable the capture of market share and take
advantage of the rapidly growing demand for data transmission, multimedia and long
haul voice capacity.
The Qwest Macro Capacity Fiber Network is paving the way for 21st century
communications. Through secure, reliable and affordable data, image and multimedia content
transmission, Qwest will accelerate the expansion of the digital age in America.
Already, Internet service providers and other telecommunications companies are using the
capacity, speed, affordability and flexibility of the Qwest Network to upgrade and expand their
offerings. Businesses of all sizes are turning to Qwest to help them unlock their future
potential through Qwest's provision of long distance, IP and data transmission services. As
Qwest expands across the nation, people and businesses everywhere will discover digital
shopping, digital entertainment, digital education and digital communication as a result of
Qwest's superior Macro Capacity Fiber Network.
The Qwest Network enables advanced digital communications to seem as simple as a
telephone call. Our services are easy to use, easy to change and easy to upgrade. Qwest even
provides capacity on demand-customers can expand or shrink capacity on their own in an
instant-as well as a broad portfolio of voice and data services that give all customers the
choices they need to bring them into the 21st century.
By early 1999, the Qwest Network will be operating in more than 125 United States cities,
with extensions into Mexico, connections to the United Kingdom and other international
networks yet to be determined.
*****Start TIP*****
For more information on Qwest and their products, contact their corporate headquarters:
Qwest Communications International Inc., Qwest Tower, 555 Seventeenth Street Denver, CO
80202. Telephone: 303-291-1400 or 800-899-7780Fax: 303-291-1724, or on the Web at
http://www.qwest.net.
*****End TIP*****
NetSpeak Corporation’s WebPhone
NetSpeak Corporation is one of the leading developers and marketers of IP telephony
technology providing business solutions for concurrent, real-time interactive voice, video and
data communications over packetized data networks such as the Internet, Local Area
Networks (LANs) and Wide Area Networks (WANs). NetSpeak Solutions allow
organizations to build new voice and video-enabled communications networks or to add these
communications capabilities to their existing enterprise.
With VoIP picking up, IP telephony is receiving increasing attention from the
telecommunications, networking, software and investment communities. It is estimated that
US companies spent $83 billion on long distance calls last year. According to researchers, IP
telephony has the potential to enable companies to drastically reduce their telecommunications
costs. But more importantly, IP telephony offers the ability for multimedia communications--
voice, fax, data and video over a single channel. Although cost savings is currently generating
the demand for IP telephony, ultimately the ability to provide multimedia communications and
enhanced user services will likely be the key growth drivers of the IP telephony industry.
NetSpeak provides a complete suite of reliable, real-time, high performance multimedia
communications systems over packetized data networks for service providers, businesses, call
centers and consumers. All NetSpeak solutions utilize its patent-pending virtual circuit-
switching technology to dramatically enhance the multimedia capabilities of both private and
public IP-based networks, and drastically reduce the cost of providing advanced services over
these networks.
WebPhone
NetSpeak’s WebPhone 4.0 is the latest version of its Internet telephony software. The product
gives users the ability to have voice, video and data communications over the Internet and
other TCP/IP-based networks through an IP telephony software package. WebPhone extends
communication into the realm of multimedia by combining audio, video and text capabilities--
without the cost of long distance phone calls.
NetSpeak has licensed elemedia, Lucent Technologies' G.723.1 speech coder implementation
for use in all NetSpeak client applications including WebPhone 4.0. NetSpeak has also
licensed DSP Group, Inc.'s patent rights for G.723.1, elemedia and DSP Group both represent
separate sets of intellectual property ownerships.

The G.723.1 speech technology standard is part of the H.323 specification adopted by the
International Telecommunications Union (ITU) as the international standard for voice over
packet-switched networks such as the Internet and local area networks (LANs). G.723.1 is
also selected by the VoIP Activity Group, part of the International Multimedia
Teleconferencing Consortium (IMTC), as the preferred speech coder for Internet telephony
over modem connections.
*****End NOTE*****
By complying with H.323, multimedia products and applications from multiple vendors can
interoperate, allowing users to communicate without concern for compatibility. The
incorporation of the G.723.1 technology will give WebPhone users the highest quality
industry-compliant capabilities while providing critical standard components for
interoperability.
WebPhone 4.0 is a full-featured IP telephony software package, extending PC-to-PC
communications into the realm of multimedia by combining voice, video and text capabilities.
In addition to interoperability support, WebPhone 4.0 offers Audio Setup Wizard for
configuring speakers and microphone, being also very easy and fast to install. It also provides
inbound and outbound Activity logging of calls, an enhanced User Guide and recall for the last
five parties called.
Here are the features provided by WebPhone:
0 Point-to-point voice and video over the Internet or any TCP/IP-based network
1 Real-time, full-duplex voice communications
2 State-of-the-art cellular phone interface for ease-of-use
3 H.323 support; communicate with any H.323-compliant Internet telephone
4 Audio Setup Wizard for configuring speakers and microphone
5 Voice Auto Detection which automatically detects and adjusts to your voice,
improving audio quality
6 Online/offline integrated voice mail system
7 Four lines with call holding, muting, do not disturb and blocking options
8 Complete Caller ID information
9 Speed dial, redial, call conferencing and call transferring
10 Recall for last five parties

11 Video phone support using the H.263 standard
12 Fast video frame delivery for low and high bandwidth connections
13 Large video display area with self and remote views
14 Interactive party-specific TextChat
15 Inbound and outbound Activity logging
16 Integrated real-time information assistance
17 Personal directory to store frequently called parties
18 Audio quality enhanced with TrueSpeechTM, G.723.1 and GSM voice compression
19 Account information and dialing parameters for use with NetSpeak Gateway Products
Here are the systems requirements:
0 Hardware
1 90 MHz Intel Pentium
2 16 MB RAM
3 10 MB available (free) hard disk space

4 MCI-compliant sound card that supports 8 kHz or 11 kHz sampling
5 VGA card capable of displaying 256 colors
6 Hardware for Video
7 120 MHz Intel Pentium
8 28.8 Kbps connection
9 Camera or other input source
10 Capture card if required by camera or other input source
11 Operating System
12 Microsoft Windows 95 or Windows NT
13 Network Connection
14 28.8 Kbps connection
15 Windows Sockets version 1.1 or later
16 TCP/IP network connection (LAN, WAN, or Internet)
*****Start TIP*****
Download WebPhone for free before you buy it at the URL below.
For more information on NetSpeak, contact them at 902 Clint Moore Road, Suite 104
Boca Raton, Florida 33487-2846, or call (561) 998-8700, or fax (561) 997-2401. You can also
contact them on the Web at http://www.netspeak.com/.
*****End TIP*****
NetPhone’s PBX Servers
NetPhone, Inc. is a privately held company headquartered in Marlborough, MA. NetPhone
designs manufactures and markets intelligent telephone systems and telephony applications
for medium and small size offices. NetPhone PBX Servers are a new generation of telephone
systems that integrate the power, ease-of-use, and economics of PC servers with the familiarity
and reliability of the telephone. These open, reliable telephone systems allow organizations to
easily and affordably deploy a wide variety of computer telephony applications to increase
sales, enhance customer service, reduce telephone costs, and boost staff productivity.
As large corporations have adopted Computer Telephony (CT) as a strategic communications
technology, CT unfortunately have not been an option for smaller companies, simply because
they were either unavailable from their telephone system provider or prohibitively expensive.
NetPhone PBX Servers, enables CT solution into smaller business by making computer
telephony enabled PBX systems cost effective by incorporating all components of a complete
PBX, and server software that implements all standard computer telephony APIs. The PBX
boards simply plug into standard PC servers running Windows NT or NetWare. Telephony
applications supplied by NetPhone and third parties execute on the PBX Servers and PC
clients. NetPhone PBX Servers and applications deliver the productivity enhancements of PC-
based visual phone control with caller-ID, database screen-pops, phone management, visual
voice mail, and more.
NetPhone PBX boards are compatible with industry standard application interfaces including
Microsoft's TAPI and Novell's TSAPI, and provide a series of benefits, as itemized below:
0 Advanced PBX Call Processing — that provides call waiting, call hold, call transfer,
call conferencing, call forwarding, call pick-up, call group covering, call group
hunting, and call queuing telephony services for office and call center environments.
1 PhoneMaster — a Windows-based desktop call control application that features
caller-ID handling, ‘screen-pops’ of desktop applications, control and status of
inbound and outbound calls, and a graphical interface to voice mail.

2 VoiceMaster — a comprehensive voice mail manager that allows users to record,
access, manipulate, and forward messages from their telephone by use of standard
DTMF touch-tone commands.
3 Flexible Auto Attendant — that supports customized greeting messages for incoming
callers.
4 Customizable Application Templates -- Templates for horizontal and vertical market
telephony applications such as ACD, advanced call filtering, account/order status and
inquiry, and many additional IVR applications.
5 High Availability Design — a patent pending PBX switch architecture that eliminates
dependency on host-resident switch call control software, ensuring the telephone
system continues to operate even when the host PC server is taken off-line.
6 Scaleable Capacity of User Extensions and Trunks — enabling an organization’s
phone system to easily expand as their business grows.
7 Support for Standard Phone Sets and Speaker Phones — eliminating the need for
businesses to spend money on proprietary, highly expensive telephones.
8 Simplified Telephone System Administration — featuring a Microsoft Windows GUI
that provides local and remote administrators a point-and-click interface to handle
telephone moves, adds and changes.

NetPhone PBX servers are based entirely on industry standards and are a member of the
Voice-Over-IP Forum. As a result they are supported by a wide-range of third-party computer-
telephony applications, including those from Microsoft, CallWare, CoreSoft, Brooktrout,
Tobit Software, Decisif, SoftLinx and many others.
For additional information about NetPhone or their products, contact them at 313 Boston Post
Road, West Marlborough, Massachusetts 01752. Tel: 508-787-1000, or Fax: 508-787-1030.
You can also e-mail them at info@netphone.com.
*****End NOTE*****
Vocaltec’s Internet Phone and Telephony Gateway Server
VocalTec Communications Ltd is another Internet Telephony Company. An Israeli based
firm, VocalTec develops and markets award-winning software that enables voice, fax and
multi-media communications over packetized (IP) networks, the Internet and corporate
intranets. The Company also develops open systems to bridge the Internet/intranets to the
public switched telephone network (PSTN).
VocalTec pioneered the Internet telephony market with the introduction of Internet Phone in
1995. For the first time, anyone who owned a multimedia PC could make or receive a call
from a computer anywhere in the world with no long distance charges.
VocalTec continues to drive Internet telephony’s evolution into the mainstream by being first-
to-market with customized client/server solutions for the corporate and carrier markets. These
products offer corporations increased productivity and cost savings and enable traditional and
new generation telcos, such as Internet telephony service providers (ITSPs), to provide more
affordable and powerful communications services to customers.
Vocaltec plays a central role in the development of interoperability standards. During 1996,
the company demonstrated its commitment to the standards process by working closely with
Microsoft and Intel to achieve interoperability between VocalTec Communications' Internet
Phone software and Microsoft NetMeeting and Intel's Internet Phone software by announcing
their support of the International Telecommunications Union H.323 open standard. The
Company has also announced its founding membership in the VoIP Forum. VocalTec was
also the first company to ship a product using the UDP/IP protocol (one of the building blocks
of Internet connectivity) for real-time voice communication.

VocalTec and Cisco co-founded the VoIP Forum of the International Multimedia
Teleconferencing Consortium (IMTC) in May 1996 to ensure and promote industry-wide
interoperability of Internet voice communications products. Within the VoIP forum, VocalTec
Communications has been developing its Call Management Agent (CMA) technology, a
technology expected to be extremely important to the development of truly rich and useful IP-
based telephone products.
VocalTec Communications has also been very active in the development of the emerging
International Telecommunication Union (ITU) H.323 system. Recognizing that the real
promise of IP-based telephony lies in the added functionality of new extra features, including
integration with Web-based voicemail, multi-party collaboration, and multimedia
supplementary services (call waiting, call transfer, etc.), the company places a high level of
importance on enabling all of these new features in a standard way so that the customer can be
certain that his system works as a whole.
The VocalTec Ensemble Architecture
The VocalTec Ensemble Architecture (VocalTec EA) is an open standards-based software
platform, which forms the foundation for IP Communications solutions from VocalTec. The
design and architecture of VocalTec EA relies on years of VocalTec field experience in IP
Communications and their active role in Internet Telephony standards organizations.

VocalTec EA is a third generation architecture capable of sustaining widescale deployment of
IP Communications in the corporate and service provider environments.
The Internet Phone
The Internet Phone is Vocaltec’s client software, that enables users to simultaneously talk and
see each other in real-time for the cost of an Internet connection. Internet Phone Release 5 has
many new and improved features including enhanced audio and video, support for
international standards, PC-to-standard phone calling and a new Community Browser. In
addition to being a stand-alone product, Internet Phone is a key component of VocalTec’s
corporate and carrier Internet telephony client/server solutions.
The VocalTec Telephony Gateway Server
The VocalTec Telephony Gateway Server bridges the gap between the traditional telephone
network and the Internet/intranets to enable unlimited long-distance calling and faxing. It
allows users to connect over the Internet or Intranet from telephone-to-telephone, PC-to-
telephone, telephone-to-PC, fax-to-fax, and Web browser-to-telephone. The Telephony
Gateway uses the power of the Internet protocol standard to improve the flexibility and
performance of business communications systems while reducing long-distance phone
charges.
For a full list of Vocaltec’s products and specifications, check their Website at URL
http://www.vocaltec.com/about/aboutus.htm, or contact them at:
In Israel: 1 Maskit Street, Herzliya 46733, Tel.: +972-9-970-7777, Fax: +972-9-9561-867.
In United States, 35 Industrial Parkway, Northvale, NJ 07647, Tel.: 201-768-9400 or Fax:
201-768-8893.
*****End NOTE*****
Vienna Systems’ Vienna.way
Vienna Systems Corporation designs and manufactures server-based hardware and software
products to distribute voice, data and video calls across IP networks, both corporate (Intranet)
and public (Internet). Vienna.way is Vienna's flagship product.

Vienna.way
TheVienna.way products enable customers to build networks for voice, data and video calls
over an IP network. It is a client/server application that enables you to make a call over the IP
network to another client, as shown on figure 9.7, or use the Gateway to call someone on the
Public Telephone Network or call into the Vienna.way network using the Gateway.
Figure 9.7
The Vienna.way platform
Vienna.way enables corporations to:
0 Reduces infrastructure and administration costs as it. No more need for complex adds
/ moves and changes for both data connections as well as voice connections.
1 Optimizes network utilization. Now all calls, whether they are voice, data or video,
can be routed over the same network.
2 Improves productivity. Multimedia applications such as data collaboration and video
provide a more productive environment for people to work together. Enable remote
workers and road warriors to have their communications as if they were at the office.
3 Enhances customer contact. Build new and exciting applications such as telephony-
enabled web pages.
A key component of Vienna.way is the Call Processing Server that extends the traditional
PBX voice communication features to voice, data and video traffic. To provide access to this
environment, Vienna has a Gateway product, which provides the interface between the Public
Telephone Network and the IP network. The client interface, my.way, provides multi-line
PBX functionality on the desktop.
Vienna.way's product family consists of:
0 Vienna.way Call Processing Server: The Server provides traditional PBX features
across the network and delivers multimedia calls across private (Intranet) and public
(Internet) networks. In addition to providing call-processing features, the Server is
also responsible for maintaining all configuration and user data.
1 Vienna.way Gateway: The Gateway serves as a network interface between an IP
network and the public telephone network.
2 Vienna.wayDesktop Applications
3 my.way:A desktop application extending a wide range of multimedia
applications to the end user. It resides on the user's desktop, as shown on figure
9.8, providing multi-line phone and PBX functionality. Up to eight lines
appearances are available at the desktop, and users can rely on the corporate-
wide telephone directory or create their own for speed dialing. IP address
resolution allows users to dial by name or extension number. Users can perform
standard functions like answer/hang-up, hold, retrieve, transfer, call forward,
DND, mute, pick-up, conferencing and more. Data collaboration is easily
launched within the application and editing rights can be shared. my.way is
compatible with standard data conferencing, application sharing, and data
collaboration applications such as Microsoft's NetMeeting.
Figure 9.8
My.way desktop application, by Vienna Systems
0 SerialSet: A serial telephone connecting directly to the PC, as showing on figure
9.9, allowing callers to connect directly through their computer for voice
communication using the my.way application. It features familiar functionality
like flash, re-dial and mute. As an alternative to sound cards and microphones, it
provides for increased privacy and improved IP voice quality for users on the
network. At the office, a single connection for voice and data at the desktop
makes moves, adds and changes easier for the network administrator. Its
portability means remote workers can connect SerialSet to their laptops to place
and receive IP voice calls through dial-up access to the network when away from
the office.
Figure 9.9
Serial.Set is a serial; telephone to be connected to the PC, by Vienna Systems.
0 phone.way: A serial telephone adapter, as shown on figure 9.10, connecting a
standard phone to the PC. Vienna's serial telephone adapter connects existing
standard phones to the PC through the PC's serial port, eliminating the need for a
sound card and microphone. Operating with the my.way desktop application,
phone.way allows callers the choice of dialing and accessing call-processing
features from their PC keyboard or from the telephone keypad. If the PC is
powered off or the network is unavailable, phone.way will automatically switch
calls to bypass the PC. The desktop telephone will then connect through a second
RJ-11 jacks to an attached PBX.

Figure 9.10
Phone.way seral telephone adapter, by Vienna Systems
The Vienna.way, architecture has been designed to be fully distributed and flexible, making it
simple for customers to build new applications and services.
Lucent Technologies’ Internet Telephony Server-E (ITS-E)
Lucent Technologies, headquartered in Murray Hill, N.J., designs, builds and delivers a wide
range of public and private networks, communications systems and software, data networking
systems, business telephone systems and microelectronics components. Bell Laboratories is
the research and development arm of the company. For more information about Lucent
Technologies, visit its web site at http://www.lucent.com.
Lucent is investing heavily in VoIP technology, as the market expands rapidly. At
NetWorld+Interop, in May of 1998, Lucent announced a portfolio of enhanced VoIP products,
including a mixed-media application server and an Internet telephony gateway, that enable
enterprises and service providers to create new IP-based applications, effectively scale and
migrate their IP-based networks and improve business productivity.

Lucent is also bringing new capabilities to the ADSL market, with its new ADSL access
solutions that reside on the customer premises and in the service providers' networks as well as
in chip sets for computers.
*****End NOTE*****
The Internet Telephony Server - E (ITS-E)
Lucent Technologies offers a Microsoft Windows NT server-based solution that places voice
and fax calls over IP networks using voice compression software developed by Bell Labs' new
division, elemedia. The solution, know as the Internet Telephony Server-E (ITS-E) works with
the DEFINITY ECS and most existing telephone systems and is connected to the PBX via a
T1/E1 Tie Line or analog line interface. On the IP network side, the ITS-E is connected via a
standard 10/100BaseT Ethernet interface. ITS-E supports calling between two standard
telephone sets or two fax machines. ITS-E also supports calls between a telephone and an
H.323 standard Voice over IP PC program, such as Microsoft's NetMeeting.
The quality of voice over IP using ITS-E is near toll quality. The SX7300 algorithm has been
evaluated as having a Mean Opinion Score (MOS) of 3.5 (based on tests performed by
COMSAT Laboratories, Clarksburg, Maryland in August 1995.).

MultiMedia Communications eXchange Server (MMCX 2.1)
Lucent's MultiMedia Communications eXchange Server is leading the industry as the first
fully standards-compliant H.323 conference server, by extending multi-party media
conferencing to a broad array of network connections, including ATM, wireless LANs, remote
access and H.320 and H.323 endpoints.
Positioned as an IP-based tool for improving real-time communications in business networks,
MMCX 2.1 also adds improved audio and video quality and increased interoperability by
enabling UNIXTM workstations and PC endpoints to be co-resident on the same server.
The MMCX 2.1 support's RADVision's new OnLAN L2W - 323 Multimedia H.323 Gateway,
making it possible for MMCX, H.323 and other H.320 clients, such as PictureTel Corp. room
systems, to communicate over the same LAN. The gateway also enables MMCX users to tie
their existing ISDN-based PC and room videoconferencing systems into the LAN in a cost-
effective way.
To help network administrators reduce the amount of multimedia traffic on the WAN, the
MMCX 2.1 now supports IP multicasting. In addition, for the first time, enterprises deploying
large networks of MMCX servers can use sophisticated network management tools such as
Hewlett-Packard Co.'s HP OpenView.

The H.323-compliant MMCX client and server software now supports Microsoft®
WindowsTM PCs, UNIX workstations and telephony-based endpoints, enabling customers to
establish spontaneous point-to-point or multi-party calls using a variety of voice, video and
data.
Company’s such as Lockheed Martin Tactical Aircraft Systems of Fort Worth, Texas, has
begun rolling out the latest version of the MMCX to more than 100 engineers, designers and
partners around the world by the end of this year.
Another example of Lucent’s solutions using VoIP is achieved through mixed media
conferencing, which will allow virtual meetings to be held, as well as group reviews of
avionics software code as they begin developing the Joint Strike Fighter.
The Joint Strike Fighter, due in 2008, is a multirole aircraft for the U.S. Air Force, U.S. Navy,
U.S. Marines and British Royal Navy. Lockheed Martin is teaming up with British Aerospace,
Northrop Grumman and others to produce the first demonstration planes. Lucent’s MMCX
VoIP solution will enable Lockheed Martin to resolve many of their business issues without
having to travel as sharing of data and plan activities can be delivered via MMCX.
Internet Telephony Server for Service Providers (ITS-SP)
The Internet Telephony Server for Service Providers (ITS-SP) allows service providers to
route voice and fax communications over the Internet with near toll-grade reliability and
quality. Release 2.0 includes a new network architecture that is designed to offer key features
today, while providing a path for service providers to increase the scalability of their networks,
reduce their per port prices, increase their overall manageability and provide plug-and-play
applications.
One of these new architectural enhancements is the ITS-Service Access Manager (ITS-SAM)
which allows service providers to create zones for managing multiple gateways. The ITS-
SAM allows service providers to set up separate zones-a collection of endpoints, PC clients
and gateways-for delivering services such as authentication control, security and call routing.
For example, zones for up to 25 gateways and 500 PC clients can be set up per ITS-SAM.
Another component of the ITS-SP 2.0 is the ITS-Administration Manager (ITS-AM). The
ITS-AM is a secure Web-based network management tool that allows service providers to
manage multiple gateways from a central location.
The ITS-SP 2.0 also includes features that enable service providers to tailor their level of
service with customers through service level agreements. For example, service providers can
choose to route calls to an alternative data network or Public Switched Telephone Network
when the network is congested and Dynamic Jitter Buffering can be used to offer customers
better voice quality. The ITS-SP 2.0 also includes a custom application development tool that
enables service providers to offer new voice over data applications in their existing networks.
By the time this book is published the MMCX 2.1 should be already released, as I write this
section its release was scheduled for the end of May of 1998. For more information about
MMCX 2.1, please visit the Lucent website at http://www.lucent.com/dns. You can also
contact Lucent's Multimedia Applications Customer Support center at 800-821-8204.
*****End NOTE*****
Northern Telecom’s Webtone
Today the telecom industry is making a historic evolution toward Webtone -- a shift that will
enable data networks to deliver the same kind of reliability, integrity, security and capacity
found in voice networks.
Nortel is meeting these challenges by striving to make next-generation Webtone networks a
reality. The Internet Voice Button is its flagship product: Imagine turning on one of a variety
of intelligent information devices at work, home or on the road and being within easy reach of
an interactive, multidimensional world of sound, video, text and images. This is Nortel’s
Webtone opportunity.
A Webtone announces the immediate, instant availability of Web pages, email,
teleconferencing, voice conversations, text files, faxes, videos, home shopping and banking,
interactive games, and every other type of digital information.
The evolution toward Webtone will change everything. By transforming how people
communicate, it will transform the way businesses operate, governments define the public
interest, and knowledge is created and shared. The Webtone opportunity will afford
individuals the power to access a variety of media through a variety of devices. A Webtone
network will have the intelligence to deliver information that will help make our lives more
enjoyable, productive and effective.
Nortel is committed to building Webtone networks that carry the Internet and data traffic with
the same kind of reliability, integrity, security and capacity that we take for granted in the
familiar world of dialtone. Follow the links below to further explore the Webtone opportunity
and learn more about Nortel's Webtone initiatives:
*****Start TIP*****
You should know that MICOM, also mentioned in this book for its developments and
contribution in the VoIP industry, is Nortel wholly-owned subsidiary, providing leading-edge
solutions that integrate data, voice, fax and local area network (LAN) communications over a
wide-area link connecting company-wide locations.
*****End TIP*****
Internet Voice Button
With the press of a button on a Web page, customers visiting a business Web site can call the
business to place an order, request service or ask for more information - they never have to
dial a number or leave their Internet session! The call won't cost them a penny!
For their convenience, customers can:
0 Call the business using either:
1 A regular telephone, if they have two or more telephone lines; or
2 An Internet phone, if they are using a single line to connect to the Internet.
3 Use popular VoIP phone clients such as Microsoft NetMeeting, supporting the the
H.323 protocol for Vo IP.
4 Use text chat to exchange additional information with the business representative.
How It Works
When a customer clicks on Voice Button on a business Web page, information is sent to the
Voice Button server. This information includes the business telephone number to be called
and the customer's calling preferences. These preferences are set when a customer uses Voice
Button for the first time. A user-friendly configuration screen collects information including
the customer's preference for using a regular phone or an Internet phone.
Voice Button initiates a call to the customer using the method selected during the
configuration. When the customer answers this call, Voice Button initiates a second call to the
business representative. While this call is being established, a customized announcement may
be played for the customer. The business representative answers the call and is connected with
the customer. A text chat facility is also supported to facilitate the exchange of information.
For more information about Voice Button, please contact Nortel by e-mail at
vbutton@nortel.com, or call them using Voice Button technology by accessing their Website
at http://www.northerntelecom.com/. You can also call them at 1-613-765-7354 or 1-800-
4NORTEL.
*****End NOTE*****
What’s Next
This chapter outlined some of the main vendors actively pursuing VoIP solutions and
development of products. As discussed, many of them already offers products and services,
while many others are catching up with the waive. I believe most of the big telcos will join the
effort, but for know, they have a lot on their plate trying to convince their stock holder and
board of directors about the need to completely change the way they do business in order to
adopt VoIP’s technologies at full force.
Of course, I could have ad an endless list of vendors and suppliers of VoIp technology and
products, but that would had been almost impossible. Thus, I do recognize the selection above
is incomplete, and to update it is virtually impossible as well, as more and more companies
join the VoIP market. I hope you were able to have an overall picture of where VoIP’s market
is and what some of its major players are doing. This was the objective of this chapter. Make
sure to check the company’s websites and the latest updates of their developments.
The next chapter, “The RTSP Protocol,” discusses the Real Time Streaming Protocol (RTSP)
and the potential affect it will have in VoIP, wants fully available.
Chapter 10
The Real Time Streaming Protocol
This chapter provides you with a brief review of the Real Time Streaming Protocol (RTSP), as
described on RFC 2326 as Standards Track, of April 1998, proposed by H. Schulzrinne, from
Columbia University, A. Rao of Netscape, and R. Lanphier from RealNetworks12.
12
Copyright (C) The Internet Society (1998). All Rights Reserved. - This document and translations of it may be copied and
furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
It’s important to review RFC 2326, as it specifies the RTSP, an application-level protocol for
control over the delivery of data with real-time properties. RTSP provides an extensible
framework to enable controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored clips. This protocol is
intended to control multiple data delivery sessions, provide a means for choosing delivery
channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 1889).
The Real Time Streaming Protocol
The Real Time Streaming Protocol (RTSP) establishes and controls either a single or several
time-synchronized streams of continuous media such as audio and video. It does not typically
deliver the continuous streams itself, although interleaving of the continuous media stream
with the control stream is possible. Thus, RTSP acts as a "network remote control" for
multimedia servers.
There is no notion of an RTSP connection; instead, a server maintains a session labeled by an
identifier. An RTSP session is in no way tied to a transport-level connection such as a TCP
connection. During an RTSP session, an RTSP client may open and close many reliable
transport connections to the server to issue RTSP requests. Alternatively, it may use a
connectionless transport protocol such as UDP.
The streams controlled by RTSP may use RTP, but the operation of RTSP does not depend on
the transport mechanism used to carry continuous media. The protocol is intentionally similar
in syntax and operation to HTTP/1.1. This enables the extension mechanisms to HTTP to be
added, in most cases, to RTSP. But RTSP is not like HTTP, it differs in many ways, as
outlined below:
0 An RTSP server needs to maintain state by default in almost all cases, as opposed to
the stateless nature of HTTP.
0 Both an RTSP server and client can issue requests.
0 Data is carried out-of-band by a different protocol, although there is an exception to
it, which is discussed later on this chapter.
0 RTSP introduces a number of new methods and has a different protocol identifier.
0 RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1, which is
consistent with current HTML internationalization efforts.
0 The Request-URI always contains the absolute URI. Also, HTTP/1.1 carries only the
absolute path in the request and puts the host name in a separate header field, so that it
can continue to be backward compatible with a historical blunder, which makes
virtual hosting easier, where a single host with one IP address hosts several document
trees.
RTSP supports the following operations:
0 Retrieval of media from media server - The client can request a presentation
description via HTTP or some other method. If the presentation is being multicast, the
presentation description contains the multicast addresses and ports to be used for the
continuous media. If the presentation is to be sent only to the client via unicast, the
client provides the destination for security reasons.
0 Invitation of a media server to a conference - A media server can be invited to join an
existing conference, either to play back media into the presentation or to record all or
a subset of the media in a presentation. This mode is useful for distributed teaching
applications. Several parties in the conference may take turns pushing the remote
control buttons.
0 Addition of media to an existing presentation - Particularly for live presentations, it is
useful if the server can tell the client about additional media becoming available.
0 Proxies, tunnels and caches as in HTTP/1.1 may handle RTSP requests.

Properties of RTSP
RTSP is an extendable protocol, as new methods and parameters can be easily added to it.
RTSP is also very easy to parse both by standard HTTP or MIME parsers. Since RTSP re-uses
web security mechanisms, it is fairly secure. All HTTP authentication mechanisms such as
basic and digest authentication are directly applicable.
Another characteristic of RTSP is its transport-independence. It can either use an unreliable
datagram protocol, such as UDP, a reliable datagram protocol, such as RDP, or a reliable
stream protocol such as TCP as it implements application-level reliability.
RTSP is multi-server capable. Thus, each media stream within a presentation can reside on a
different server. The client automatically establishes several concurrent control sessions with
the different media servers. Media synchronization is performed at the transport level.
Control of recording devices can be executed with RTSP, which is able to control both
recording and playback devices, as well as devices that can alternate between the two modes,
such as VCRs.
Further, RTSP is suitable for professional applications, as it supports frame-level accuracy
through SMPTE time stamps to allow remote digital editing. Also, it is presentation
description neutral, hence not imposing a particular presentation description or metafile format
and can convey the type of format to be used. However, the presentation description must
contain at least one RTSP URI.
One of the main characteristics of this protocol is its proxy and firewall friendliness. For that,
both application and transport-layer firewalls such as SOCKS should readily handle the
protocol. A firewall may need to understand the setup method to open a hole for the UDP
media stream.
Another major characteristic of RTSP is its HTTP-friendliness. Where sensible, RTSP reuses
HTTP concepts, so that the existing infrastructure can be reused. This infrastructure includes
Platform for Internet Content Selection (PICS), for associating labels with content. However,
RTSP does not just add methods to HTTP since the controlling continuous media requires
Server State in most cases. For additional information of RTSP characteristics, check the RFC
2326 for full information.
Next Step
Appendix A, provides a list of VoIP Vendors, and Appendix B provides a comprehensive
glossary of terms related to VoIP.

Appendix A
List of Suppliers
A Sampling of Sonet/SDH Suppliers
Availabi Descri
Provider Service lity ption Coverage Bandwidth Guarantees
AmeritechUnnamed 1994 Rings 90% of Ameritech155, 6221 month free if failure is

Corp. and region Mbit/s; 2.4greater than 1 minute
Hoffman point- Gbit/s per month
Estates, Ill. to-point
708-248-
2000
AT&T Accunet 1994 Point- 8 cities tariffed;155, 622Outages from 1 minute to 1

Contact T.155 to-pointservice available inMbit/s hour, 5% refund of monthly
local sales 160 locations fee; 9 hours or more, 50%
office refund of monthly fee
Bellsouth Smart 1991 Rings Bellsouth region 155, 6221 month credit for 2.5-
Corp. Ring Mbit/s second failure or greater
Atlanta
404-982-
7000
British Megastrea 1994 Point- Trial service in2 Mbit/s Not yet determined
Telecomm m Genus to-pointManchester and
unications London
PLC (BT)
London
44-171-
932-7894
Colt Coltlink, London, Point- London, Frankfurt 300 bits/s toNone

Telecomm Coltline 1992; to-point 155 Mbit/s
unications Frankfurt
Ltd. ,
London Germany
44-171- ,
390-3900 early
1996
Energis SDH 1994 Rings Nationwide 2, 34, 140,None

Communi Premium and Mbit/s
cations and SDH point-
Ltd. Core to-point
London
44-171-
206-5800
LDDS Unnamed 1994 Point- Nationwide 155, 622Case-by-case

Worldco to-point Mbit/s credit for outages
m
Tulsa,
Okla.
918-494-
8999
MFS High- 1992 Rings 36 U.S. cities,155 Mbit/s None

Datanet Speed London, Paris,
Inc. LAN Frankfurt, Germany,
San Jose,Interconne and Stockholm,
Calif. ct Sweden
408-975-
2200
Nippon Super 1995 Rings Nationwide 51 and 155None

TelephoneHigh- Mbit/s
and Speed
Telegraph Leased
Corp. Circuit
(NTT) Service
Tokyo
81-3-3509-
8694
Nynex Sonet 1995 Rings Nynex region 155, 622Monthly charge refunded for
Corp. and Mbit/s; 2.41-minute outage
White point- Gbit/s per month
Plains, to-point
N.Y.
914-644-
7600
Pacific Fastrak 1995 Rings San Francisco Bay1.544 Entire monthly service
Bell Sonet Ring and and Los AngelesMbit/s- charge credited for outages
San and Access point- areas 2.488 Gbit/sof 2 hours or more hours
Francisco Service to-point
510-867-
7258
Sprint Clearline 1995 Point- 36 U.S. cities 155, 622Case-by-case basis

Corp. to-point Mbit/s; 2.4
Kansas 155 leased Gbit/s

City, Mo. lines
703-318-
7740
Teleport Omnilink 1994 Rings 40 U.S. cities 155, 622None

Communi Services and Mbit/s; 2.4
cations point- Gbit/s
Group to-point
Staten
Island,
N.Y.
718-983-
2000
US WestSynchrono 1993 Point- US West 14-state1.544, 45,Case-by-case credit

Advanced us Service to-pointregion 155, 622
Communi Transport Mbit/s; 1.2,
cations (SST) 2.4 Gbit/s
Services
Denver
303-793-
6500
ATM Around the World
Ava Fra
ilab me
Provider Service ility Coverage Description Bandwidth relay
/SM
DS
Ameritech Ameritech 199 Chicago, Cleveland,CBR/VBR 45 and 155 Mbit/s 1996

Corp. ATM Service 4 Columbus, Ohio, Dayton, /No
Hoffman Ohio, Detroit, and
Estates, Ill. Milwaukee
708-248-
2000
AT&T AT&T 199 Nationwide CBR/VBR with45 and 155 Mbit/s Late
Contact Interspan 4 SNMP 1995
local sales management /No
office
Bellsouth Fast Packet199 North Carolina CBR/VBR 1.544-45 Mbit/sYes/

Corp. Transport 3 (access); 155Yes
Atlanta Services Mbit/s (backbone)
404-982-
7000
Deutsche ATM Service 199 20 cities VBR 2, 3, 155 Mbit/s No/Y

Telecom 5 es
AG
Bonn,
Germany
49-228-181-
0
France Transrel ATM 199 11 French cities ATM-based LAN2-25 Mbit/s No/P
Telecom 4 interconnect for lanne
Paris IP traffic only d
33-1-44-44-
53-14
IBM IBM Business199 U.S., Canada, Europe ATM 8 Mbit/ sYes/

Global Port 5 infrastructure for(backbone); 64-No
Network multiprotocol 256 kbit/ s
Paris routing, SNA,(access)
33-1-41-88- voice
60-00
LDDS Channel 199 Nationwide Mainframe to host1.54 and 45Late

Worldcom Networking &3 and Mbit/s (access);1995
Tulsa, Okla.LAN LAN interconnect;45 Mbit/s/No
918-561- Connection VBR (backbone)
6098
MCI Hyperstream 199 Nationwide CBR/VBR/UBR 45 and 155 Mbit/sEarly

Communic ATM Service 4 (access); 1551996
ations Mbit/s (backbone) /
Corp. Early
Washington, 1996
D.C.
202-872-
1600
MFS MFS Datanet199 18 U.S. cities CBR/VBR 45 and 155 Mbit/sYes/

Datanet ATM Service 3 (access); 155No
Inc. Mbit/s (backbone)
San Jose,
Calif.
408-975-
2200
Pacific BellPacific Bell199 Los Angeles, Monterey,CBR/VBR 45 and 155 Mbit/sNo/N

San Fastrak 3 Calif., Sacramento, Calif., (access); 155o
Francisco Atm/Cell San Diego, and San Mbit/s (backbone)
510-823- Relay Service Francisco
2558
SBC Southwestern 199 Metropolitan areas inCBR/VBR 45 and 155 Mbit/s Yes/
Communic Bell ATM6 Arkansas, Kansas, Yes
ations Cell Relay Missouri, Oklahoma, and
Corp. Service Texas
St. Louis
314-235-
9800
Sprint Sprint ATM199 Nationwide CBR/VBR 1.544, 45 Mbit/sLate

Corp. Service 3 (access); 45 and1995
Kansas City, 155 Mbit/s/No
Mo. (backbone)
703-318-
7740
Stentor Depends upon199 All major metropolitanLAN interconnect10 Mbit/s (access) N/A
Alliance operator 3 areas in 10 provinces andfor Ethernet for
Ottawa territories and token ring; both
613-781- videoconferencing
8798
Swiss SwissWAN 199 Basel, Bern, Geneva,LAN interconnect;155 Mbit/s Yes/

Telecom 5 Lausanne (late 1995),CBR/VBR Yes
PTT Lugano, Zurich
Bern
41-31-338-
7393
Telecom Datanet ATM 199 15 Finnish cities LAN interconnect 64 kbit/ s to 155Yes/
Finland 4 Mbit/ s No
Ltd.
Helsinki
358-2040-
2964
Telia ABTelia City199 Stockholm, Gothenburg,ATM bearer155 Mbit/s No/N

Stockholm, Services 5 Malmo services; o
Sweden CBR/VBR;
46-8-713- permanent and
1975 temporary
connections
Unitel Canarie Lat Major Canadian cities VBR 45 Mbit/s No/N

Communic Network e o
ations Inc. 199
Toronto 5
416-345-
2000
US WestInterprise 199 Oregon ABR/VBR 45 and 155 Mbit/sEarly

Interprise Networking 5 (access); 1551996
NetworkingATM Service Mbit/s (backbone) /
Services Late
Denver 1996,
303-965- early
9286 1997
ABR =
N/A = Not
Available SVC = Switched virtual circuit VBR = Variable bit rate
applicable
bit rate
CBR =
UBR = Unspecified bit
Constant bitSMDS = Switched Multimegabit Data Service
rate
rate
Appendix B
Glossary of terms
Adjacency - A relationship formed between neighboring routers formed for the purpose of
exchanging routing information.
Aggregate control - The control of the multiple streams using a single timeline by the server.
For audio/video feeds, this means that the client may issue a single play or pause message to
control both the audio and video feeds.
American National Standards Institute (ANSI) - The principal standards development body in
the United States. It consists of voluntary members that represent the U.S. in the International
Standards Organization (ISO). Membership includes manufacturers, common carriers, and
other national standards organizations, such as the Institute of Electrical and Electronic
Engineers (IEEE).
American Wire Gauge (AWG) - A wire diameter specification. The lower the AWG number,
the larger the wire diameter.
Amplitude - The maximum value of varying wave forms.
Anycast, anycast address - An identifier for a set of interfaces that typically belongs to
different nodes. A method developed for IPv6, of sending a datagram or packet to a single
address with more than one interface. The packet is usually sent to the “nearest” node in a
group of nodes, as determined by the routing protocols' measure of distance. Compare to
multicast and unicast.
application layer gateway (ALG) - In modern usage, the term application gateway refers to
systems that do translation from some native format to another; for example, a gateway that
permits communication between TCP/IP systems and OSI systems. An application-layer
gateway converts protocol data units (PDU) from one stack's application protocol to the other
stacks application protocol. Application layer gateways act as origination and termination
points for communications between realms.
application programming interface (API) - A set of tools, routines, and protocols used as
building blocks by programmers to develop programs. Using APIs helps to keep applications
consistent with the operating environment.
ASIC - application-specific integrated circuit

asymmetric digital subscriber line (ADSL) - An xDSL technology in which modems attached
to twisted-pair copper wires transmit from 1.5 to 8 Mbps downstream (to the subscriber) and
from 16 to 640 Kbps upstream, depending on the line distance.
Asynchronous Transfer Mode (ATM) - A cell-switching and multiplexing technology that
provides high-speed backbone support defined at 155 Mb/s and 622 Mb/s and having a 53-
byte fixed-length cell consisting of a 5 byte header for routing information and 48 bytes of
data.
Attachment unit interface (AUI) - A 15-pin shielded, twisted pair Ethernet cable used
(optionally) to connect between network devices and a MAU
Authentication - The process of knowing that the data received is the same as the data that was
sent and that the sender is the actual sender. Usually verified by a password; however, since
passwords can be guessed or discovered, a system that requires an encrypted password and a
key to decrypt it are becoming popular.
autonomous system - A collection of CIDR IP address prefixes under common management.
You can also think of an autonomous system as set of routers under a single technical
administration. An AS uses one or more interior gateway protocol and common metrics to
route packets within the AS. An autonomous system uses an exterior gateway protocol to
route packets to other autonomous systems. The administration of an AS appears to other

autonomous systems to have a single coherent interior routing plan and presents a consistent
picture of what networks are reachable through it.
backbone network - The major transmission path for network interconnection.
Bandwidth - The signaling rate of a LAN or WAN circuit or the number of bits or bytes that
can be transmitted over the channel each second and measured by electrical engineers in Hertz
(Hz). See also latency.
BNC Connector - Bayonet Neill-Concelman connector that is a type of connector used for
attaching coax cable to electronic equipment and that can be attach or detach quicker than
connectors that screw. ThinWire Ethernet (IEEE 802.3 10BASE2) uses BNC connectors.
Broadband - A data transmission technique allowing multiple high-speed signals to share the
bandwidth of a single cable via frequency division multiplexing
Broadcast - A type of data communication where a source sends one copy of a message to all
the nodes on the network even if the node does not want to receive such messages. See also
anycast, unicast, multicast, and IP multicasting.
broadcast domain - The part of a network that receives the same broadcasts
broadcast network - A network that supports more than two attached routers, and has the
capability to address a single physical message to all of the attached routers.

building backbone subsystem - Provides the link between the building and campus backbone
campus backbone subsystem - Provides the link between buildings and contains the cabling
and crossconnects between cluster of building within a site.
carrier sense multiple access with collision detection (CSMD/CD) - The channel access
method used by the Ethernet and ISO 8802-3 LANs. Each station waits for an idle channel
before transmitting and detects overlapping transmissions by other stations.
carrierless amplitude phase (CAP) modulation - A version of quadrature amplitude
modulation (QAM) that stores parts of a modulated message signal in memory and then
reassembles the parts in the modulated wave. The carrier signal is suppressed before
transmission because it contains no information and is reassembled at the receiving modem
(hence the word "carrierless" in CAP).
central office (CO) - A facility that contains the lowest node in the hierarchy of switches that
comprise the public telephone network.
Channel - The data path between two nodes
Class A IP address - A type of unicast IP address that segments the address space into many
network addresses and few host addresses.

Class B IP address - A type of unicast IP address that segments the address space into a
medium number of network and host addresses.
Class C IP address - A type of unicast IP address that segments the address space into many
host addresses and few network addresses.
Class D IP addresses - Specifies multicast host groups in IPv4 based networks. The Internet
standard in "dotted decimal" notation, assigns this host group addresses range from 224.0.0.0
to 239.255.255.255.
Client - The client requests continuous media data from the media server.
client/server architecture - A network architecture in which the protocols in use govern the
behavior of workstations so each one works either as a client or a server. Users run
applications on client machines while server machines manage network resources.
CLNP - OSI connectionless network protocol
Conference - a multiparty, multimedia presentation, where "multi" implies greater than or
equal to one.
Connection - A transport layer virtual circuit established between two programs for the
purpose of communication.
connectionless protocol - A type of network protocol where a host can send a message without
establishing a connection with the recipient. The host puts the message onto the network,
provides the destination address and hopes that the message arrives at its destination.
connection-oriented protocol - A protocol that requires the establishment of a channel between
the sender and receiver before transmitting any data. The telephone, TCP, and HyperText
Transmission Protocol (HTTP) are all examples of connection-oriented protocols.
Consumer - Defined in the Multicast Transport Protocol to be a transport that is capable only
of receiving user data. It can transmit control packets, such as negative acknowledgements, but
can never transmit any requests for the transmit token or any form of data or empty messages.
Container file - A file that may contain multiple media streams, which often comprise a
presentation when, played together. RTSP servers may offer aggregate control on these files,
though the concept of a container file is not embedded in the protocol.
Continuous media - Data where there is a timing relationship between source and sink; that is,
the sink must reproduce the timing relationship that existed at the source. The most common
examples of continuous media are audio and motion video. Continuous media can be real-
time (interactive), where there is a "tight" timing relationship between source and sink, or
streaming (playback), where the relationship is less strict.

Convergence - The amount of time it takes for a change to a routing topology to propagate
throughout the network.
Core Based Trees (CBT) Routing Protocol - - The CBT routing protocol is characterized a
single tree that is shared by all members of the group. All members of the group receive
multicast traffic over this shared tree regardless of the source of the message. A small number
of core routers construct the tree and routers can join the tree by sending a join message to the
core.
core network - A combination of switching offices and transmission plant that connects
switching offices together. In the U.S. local exchange, core networks are linked by several
competing interexchange networks. In the rest of the world, core networks extend to national
boundaries.
counter-rotating Ring - A method of using two ring networks going in opposite directions
(such as in FDDI) to provide redundancy. The network interfaces can change the path of the
ring that the data flows around. This preserves the ring and the operation of the LAN even if
some of the cable is unplugged or cut, or if a device on the ring fails in such a way that it
cannot transmit data around the ring.
CPE - Customer premises equipment.

Data circuit terminating equipment (DCE) - An interface typically found in modems or similar
devices that provide clocking as well as switching services between DTE.
Data Link Connection Identifier (DLCI) - A 10-bit value included in the address field of a
frame relay packet that uniquely identifies each virtual circuit at each Frame Relay
Data terminal equipment (DTE) - An interface typically embodied in computers, terminals, or
routers that act as terminating equipment for a given network.
Datagram - Term used in IPv4. The format for a packet of data sent on the Internet to a
specific destination address. Specifies standards for the header information. In IPv6,
datagrams are known as packets.
Dense-mode multicast routing protocols - A category of routing protocol that assumes that
multicast group members are densely distributed throughout the network. The basic
assumption is that almost all the hosts on the network belong to the group. Dense-mode
routing protocols included the Distance Vector Multicast Routing Protocol (DVMRP),
Multicast Open Shortest Path First (MOSPF), and Protocol-Independent Multicast - Dense
Mode (PIM-DM) protocols. See also sparse-mode Routing Protocols.
dial up - A type of communications that is established by a switched circuit connection using
the public telephone network.

digital loop carrier (DLC) - The carrier's local loop infrastructure that connects end users
located more than 18,000 feet or 3.5 miles away from the central office. DLC systems consist
of physical pedestals containing line cards that concentrate residential links onto digital
circuits.
digital subscriber line (DSL) - A local loop access technology that calls for modems on either
end of copper twisted-pair wire to deliver data, voice, and video information over a dedicated
digital network.
digital subscriber line access multiplexer (DSLAM) - Multiplexing equipment that contains a
high concentration of central office splitters, xDSL modems, and other electronics to connect
traffic to the wide area network (WAN).
discrete multi-tone (DMT) modulation - A wave modulation scheme that discretely divides
the available frequencies into 256 sub-channels or tones to avoid high-frequency signal loss
caused by noise on copper lines.
discrete wavelet multi-tone (DWMT) - A variant of DMT modulation. DWMT goes a step
further in complexity and performance by creating even more isolation between sub-channels.
Distance Vector Multicast Routing Protocol (DVMRP) - The first protocol developed to
support multicast routing and used widely on the MBONE. RFC 1075 describes this Distance
Vector Multicast Routing Protocol. DVMRP assume that every host on the network belongs
to the multicast group. Multicast messages pass over all router interfaces as they pass over the
network and form a spanning tree to all members of the multicast group. DVMRP uses a
distance-vector protocol such as the Routing Information Protocol (RIP) to maintain a current
image of the network topology. Both DVMRP and RIP use the number of hops in the path as
the distance metric.
Domain Name Service (DNS) - The name service of the TCP/IP protocol family, which
provides information about computers on local and remote networks. DNS is an Internet-wide
hierarchical database.
DPP - distributed packet pipelining
DTE/DCE - The interface between data terminal equipment (DTE) and data circuit-
terminating equipment (DCE); one of the most common in networking
E1 - The European basic multiplex rate that carries 30 voice channels in a 256-bit frame
transmitted at 2.048 Mbps.
echo cancellation - A technique used by ADSL, V.32, and V.34 modems that isolates and
filters unwanted signal energy from echoes caused by the main transmitted signal.
Entity - The information transferred as the payload of a request or response. An entity consists
of metainformation in the form of entity-header fields and content in the form of an entity.
European Telecom Standards Institute (ETSI) - A consortium of manufacturers, service
carriers, and others responsible for setting technical standards in the European
telecommunications industry.
Fanout - The degree of replication in a multicast tree or the number of copies of a call in a
switch and associated with IP multicasting and ATM
Fast Ethernet - A nickname for the 100Mbps version of IEEE 802.3
fast packet - A data transmission technique where the packet is transmitted without any error
checking at points along the route. The end-points have the responsibility of performing any
error checking.
Fiber Distributed Data Interface (FDDI) - A set of ANSI/ISO standards that define a high-
bandwidth (100 Mbps) general purpose LAN. FDDI primarily runs over optical fiber but can
all run over copper. FDDI provides synchronous and asynchronous services between
computers and peripheral equipment in a time-token passing dual ring configuration.
FIRE - Flexible Intelligent Routing Engine
Flow-based - - A proprietary implementation of Layer 3 switching that investigates only the
first packet of data, switching the remaining packets at Layer 2

fragment - A portion of a packet/frame and often means a part of an Ethernet frame left over
from a collision. In IP terminology, fragment means a packet that is the result of splitting a
larger packet into smaller ones.
Frame - In telecommunications, a unit of data that is transmitted between network points
complete with addressing and necessary protocol control information.
Frame relay network - - A network consisting of frame relay switches, offering a bare-bones
link-layer service for fast bulk packet transmission.
Frequency - The rate of signal oscillation in hertz (Hz).
frequency division multiplexing (FDM) - A technique that divides the available bandwidth of
a channel into a number of separate channels.
full-duplex - The property of a data-communications line that provides Independent,
simultaneous two-way transmission in both directions, as opposed to half-duplex
transmission. The alternatives are half duplex and simplex.
Gateway - An intermediate destination by which packets are delivered to their ultimate
destination. A host address of another router that is directly reachable through an attached
network. As with any host address it can be specified symbolically.

geostationary satellite (GSAT) - A satellite that orbits the orbits the earth directly over the
equator, approximately 22,000 miles up. A complete rotation around the earth takes 24 hours.
Weather satellites are examples of this type.
Gigabit Ethernet - High-speed version of Ethernet (a billion bits per second) under
development by the IEEE.
half duplex - A possible property of a data-communications line: that data can be transferred
in either direction, but only in one direction at a time. If the line is sufficiently high-speed, then
to a human, it may appear that data transfer is simultaneous in both directions if the two ends
quickly take turns transferring. The alternatives are full duplex and simplex.
Heartbeat - An interval of time nominally measured in milliseconds and a key parameter in the
transport's state. It can be adapted to the requirements of the transport's client to provide the
desired quality of service. Also Ethernet defined SQE signal quality test function.
Hertz - A frequency unit equal to one cycle per second.
high bit-rate digital subscriber line (HDSL) - An xDSL technology in which modems on either
end of two or more twisted-pair lines deliver symmetric T1 or E1 speeds. Currently, T1
requires two lines and E1 requires three.

high-definition television (HDTV) - A system of transmitting television signals at 24 Mbps,
which increases the horizontal lines of resolution from 480 to 560 lines per display.
Host Group - - All hosts belonging to a multicast session. The membership of a host group is
dynamic where: hosts can join and leave the group at any time. There can be any number of
members in a host group and the members can be located anywhere on the local network or on
the Internet. A host can be a member of more than one group at a time.
HTTP - Hypertext Transfer Protocol
ICMP destination unreachable indication - An error indication returned to the original sender
of a packet that cannot be delivered for the reasons outlined in ICMP protocol. If the error
occurs on a node other than the node originating the packet, an ICMP error message is
generated. If the error occurs on the originating node, an implementation is not required to
actually create and send an ICMP error packet to the source, as long as the upper-layer sender
is notified through an appropriate mechanism; for example, the return value from a procedure
call. Note, however, that an implementation may find it convenient in some cases to return
errors to the sender by taking the offending packet, generating an ICMP error message, and
then delivering it locally through the generic error handling routines.
IEEE - Institute of Electrical and Electronic Engineers

Integrated Services Digital Network (ISDN) - All digital service provided by telephone
companies. Provides 144 Kbps over a single phone line (divided in two 64 Kbps "B" channels
and one 16 Kbps "D" channel).
interexchange carrier (IEC) - A long-distance service provider.
Interface - A system's attachment point to a link. It is possible for a system to have more than
one interface to the same link. Interfaces are uniquely identified by IP unicast addresses; a
single interface may have more than one such address. An interface can be connection
between a router and one of its attached networks. A single IP address, domain name, or
interface name can specify a physical interface (unless the network is an unnumbered point-to-
point network).
Internet Assigned Numbers Authority (IANA) - The central coordinator for the assignment of
unique parameter values for Internet protocols. The Internet Society (ISOC) and the Federal
Network Council (FNC) charter the IANA to act as the clearinghouse to assign and coordinate
the use of numerous Internet protocol parameters.
internet datagram - The unit of data exchanged between an Internet module and the higher
level protocol together with the internet header.
Internet Engineering Task Force (IETF) - An international group of network designers,
operators, vendors, and researchers, closely aligned to the Internet Architecture Board and
chartered to work on the design and engineering of TCP/IP and the global Internet. The IETF
is divided into groups or areas, each with a manager. Open to any interested individual.
Internet Group Management Protocol (IGMP) - Multicast routers use this protocol to learn the
existence of host group members on their directly attached subnets. IP hosts use IGMP to
report their host group memberships to any immediately neighboring multicast routers. IGMP
messages are encapsulated in IP datagrams, with an IP protocol number of 2. RFC1112
describes IGMP, which is considered as an extension to ICMP and occupies the same place in
the IP protocol stack.
Internet Protocol (IP) - The protocol or standard at the network level of the Internet that
defines the packets of information and routing them to remote nodes, and the method of
addressing remote computers and routing packets to remote hosts.
Internet Service Provider (ISP) - Businesses that provide subscription services, such as online
information retrieval software, bulletin boards, electronic mail, and so on to users for a fee.
ISPs are domains under the control of a single administration that share their resources with
other domains.
Internetwork Packet Exchange protocol (IPX) - A datagram protocol found in Novel NetWare
networks. This datagram protocol is similar to UDP and together with SPX, provides
connectionless services similar to UDP/IP.

InterNIC - A collaborative project between AT&T and Network Solutions, Inc. (NSI)
supported by the National Science Foundation. The project currently offers the following four
services to users of the Internet.
IP Multicast - A one-to-many transmission and described in RFC 1112, “Extensions for IP
Multicasting”, by Steve Deering in 1989. The RFC describes IP Multicasting as: "the
transmission of an IP datagram to a ‘host group’, a set of zero or more hosts identified by a
single IP destination address. A multicast datagram is delivered to all members of its
destination host group with the same ‘best-efforts’ reliability as regular unicast IP datagrams.
The membership of a host group is dynamic; that is, hosts may join and leave groups at any
time. There is no restriction on the location or number of members in a host group. A host
may be a member of more than one group at a time."
IP Multicast Datagram - A datagram delivered to all members of the multicast host group.
Such datagrams are delivered with the same best-efforts reliability as regular unicast IP
datagrams.
IP Multicast Router - A router supporting IGMP and one or more of the multicast routing
protocols, including Distance DVMRP, MOSPF, PIM-DM, CBT, and PIM-SM.
IPX - See Internetwork Packet Exchange protocol
ISE - Intelligent Switching Engine

ISO - International Organization for Standardization, a special agency of the United Nations
that is charged with the development of communication standards for computers. Membership
in the ISO consists of representatives from international standards organizations throughout
the world.
ISP - Internet service provider.
ITU - International Telecommunication Union
Kbps - Kilobits per second
LAN - A LAN is a local area network and is a communication network that spans a limited
geographical area. LANs can differ from one another by topology or arrangement of devices
on the network, the protocols they use, and the media, such as twisted-pair wire, coaxial
cables, or fiber optic cables used to connect the devices on the network.
Latency - The transmission delay of the network or the minimum amount of time it takes for
any one of those bits or bytes to travel across the network. See also bandwidth.
LEO system - A low-earth-orbit satellite system consisting of a number of small satellites
orbiting in a circular orbit at over, or nearly over, the geographic poles and flying at an altitude
of a few hundred miles. Wireless access to the Internet is dependent upon this type of satellite.
LLC - Logical Link Control

local loop - The line from a subscriber to the telephone company central office.
logical link - A temporary connection between source and destination nodes, or between two
processes on the same node
Logical Link Control (LLC) - Part of the Data Link layer of the OSI model and the link layer
control specification for the IEEE 802.x series of standards. It defines the services for the
transmission of data between two stations with no intermediate switching stations. There are
three versions; LLC1 is connectionless, LLC2 is connection oriented, and LLC3 is
connectionless with acknowledgment.
logical topologies - Describe the view of the network as seen by the networks components
access methods or rules of operation.
MAC address - The unique media access control 6-byte address that is associated with the
network adapter card and uniquely identifies the machine on a particular network. A MAC
address is also known as an Ethernet address, hardware address, station address, or physical
address.
Mask - A means of subdividing networks using address modification. A mask is a dotted quad
specifying which bits of the destination are significant. Except when used in a route filter,
GateD only supports contiguous masks.

Maximum Transmission Units (MTU) - The largest amount of data that can be transferred
across a network; size is determined by the network hardware.
MBONE - A virtual multicast backbone network layered on top of the physical Internet. In
existence for about five years, the MBONE supports routing of IP Multicast packets.
Mbps - Abbreviation for megabits per second.
Mbps - Megabits per second
Media initialization - Datatype/codec specific initialization. This includes such things as clock
rates, color tables, etc. Any transport-independent information, which is required by a client
for playback of a media stream, occurs in the media initialization phase of stream setup.
Media parameter - Parameter specific to a media type that may be changed before or during
stream playback.
Media server - The server providing playback or recording services for one or more media
streams. Different media streams within a presentation may originate from different media
servers. A media server may reside on the same or a different host as the web server the
presentation is invoked from.
Media server indirection - Redirection of a media client to a different media server.

Media stream - A single media instance, e.g., an audio stream or a video stream as well as a
single whiteboard or shared application group. When using RTP, a stream consists of all RTP
and RTCP packets created by a source within an RTP session. This is equivalent to the
definition of a DSM-CC stream.
medium attachment unit (MAU) - A device used to convert signals from one Ethernet
medium to another.
MIB - management information base
Midband - A communication channel with a bandwidth range of 28.8 to 56 Kbps.
Modem - Contraction for modulator/demodulator. A modem converts the serial digital data
from a transmitting device into a form suitable for transmission over the analog telephone
channel.
Modulation - The process in which the characteristics of one wave or signal are varied in
accordance with another wave or signal. Modulation can alter frequency, phase, or amplitude
characteristics.
multiaccess network - A physical network that supports the attachment of more than two
routers. Each pair of routers on such a network can communicate directly.

multicast - Method of transmitting messages from a host using a singe transmission to a
selected subset of all the hosts that can receive the messages; also a message that is sent out to
multiple devices on the network by a host. See also anycast, unicast, broadcast, and IP
multicasting. A
multicast group - A group set up to receive messages from a source. These groups can be set
up based on frame relay or IP in the TCP/IP protocol suite, as well as in other networks.
multicast interface - An interface to a to a link over which IP multicast or IP broadcast service
is supported.
multicast link - A link over which IP multicast or IP broadcast service is supported. This
includes broadcast media such as LANs and satellite channels, single point-to-point links, and
some store-and-forward networks such as SMDS networks.
Multicast Open Shortest Path First (MOSPF) - RFC 1584 defines MOSPF that is an extension
to the OSPF link-state unicast routing protocol that provides the ability to route IP multicast
traffic. Some portions of the MBONE support MOSPF. MOSPF uses the OSPF link-state
metric to determine the least-cost path and calculates a spanning tree for routing multicast
traffic with the multicast source at the root and the group members as leaves.
Multicast Transport Protocol (MTP) - This protocol gives application programs guarantees of
reliability. The MTP protocol could be useful when developing some types of applications.
For example MTP could be useful with distributed databases that need to be certain that all
members of a multicast group agree on which packets have been received.
Multimode Fiber - A type of fiber mostly used for short distances such as those found in a
campus LAN. It can carry 100 megabits/second for typical campus distances, the actual
maximum speed (given the right electronics) depending upon the actual distance. It is easier to
connect to than Single Mode Fiber, but its limit on speed x distance is lower.
Multiplex - Combining signals of multiple channels into one channel. This process provides
multiple users with access to a single conductor or medium by transmitting in multiple distinct
frequency bands (frequency division multiplexing, or FDM) or by assigning the same channel
to different users at different times (time division multiplexing, or TDM).
Multiplexer - A device that allows several users to share a single circuit and funnels different
data streams into a single stream. At the other end of the communications link, another
multiplexer reverses the process by splitting the data stream back into the original streams.
Multiplexing - A repeater, either standalone or connected to standard Ethernet cable, for
interconnecting up to eight ThinWire Ethernet segments.
Narrowband - A communication channel with a bandwidth of less than 28.8 Kbps.

NetBEUI - A enhanced version of the NetBIOS protocol and used by Windows based
operating systems such as Windows 95 and Windows NT.
NetBIOS - The Network Basic Input Output System, an API that has special functions for
local-area networks and used with the DOS BIOS.
network access point (NAP) - An Internet hub where national and international ISPs connect
with one another. A NAP router has to know about every network on the Internet
network address - See IP address - network service access point (NSAP) - The network
address, or the node address of the machine, where a service is available.
Network Information Center (NIC) - Central organization of a network of a network with the
authority to create network names and addresses. NIC.DDN.MIL is the specific Internet NIC
that holds the authority to create root servers.
Network Information Service - Referred to as NIS and formerly known as Sun Yellow Pages,
NIS is used for the administration of network-wide databases. NIS has two services, one for
finding a NIS server, the other for access the NIS databases. NIS permits dynamic updates of
the database files. NIS is a non-hierarchical, replicated database which is the property of Sun
Microsystems. network mask

Node - Any intelligent device connected to the network. This includes terminal servers, host
computers, and any other devices (such as printers and terminals) that are directly connected to
the network. A node can be thought of as any device that has a hardware address.
NSP - Network service provider.
Open System Interconnection (OSI) - The title for a set layered standards developed by the
ISO to allow communication between the computer systems of different vendors.
OSPF - Open Shortest Path First
Packet - A package of data with a header that may or may not be logically complete. A series
of bits containing data and control information, including source and destination node
addresses, formatted for transmission from one node to another. A packet is more often a
physical packaging than a logical packaging of data.
Packet-by-packet - An implementation of Layer 3 switching that uses industry-wide, standard
routing protocols to examine all packets and forward them to their destination entirely in Layer
Participant - Member of a conference. A participant may be a machine, e.g., a media record or
playback server.
Peer-to-peer architecture - The arrangement of communication functions and services in layers
so that data transmission between logical groups or layers in a network architecture occurs
between entities in the same layer of the model. With a peer-to-peer architecture all
workstation in this type of network have the equivalent capabilities. See also client/server
architecture.
Permanent Virtual Circuit (PVCP) - A permanent logical connection set up with packet data
networks such as frame relay.
phase modulation - A technique that changes the characteristics of a generated sine wave or
signal so that it will carry information.
Physical layer - The physical channel implements layer 1, the bottom layer of the OSI model.
The Physical layer insulates Layer 2 (the Data Link layer) from medium-dependent physical
characteristics such as baseband, broadband or fiber-optic transmission. Layer 1 defines the
protocols that govern transmission media and signals.
physical topologies - Define the arrangement of devices and the layout of the wiring.
PIM- Dense Mode (PIM-DM) Routing Protocol - Protocol Independent Multicast – Dense
Mode is a protocol operates in an environment where group members are relatively densely
packed. PIM Dense Mode (PIM-DM) is similar to DVMRP in that it employs the Reverse
Path Multicasting (RPM) algorithm. PIM-DM control message processing and data packet
forwarding is integrated with PIM-SM operation so that a single router can run different
modes for different groups.
PIM- Sparse Mode (PIM-SM) Routing Protocol - PIM-SM is a protocol that is optimized for
environments where group members are distributed across many regions of the Internet. The
multicast group members could be distributed across many regions of the Internet. To receive
multicast traffic addressed to the group, routers with directly attached or downstream members
are required to join a sparse mode distribution tree by transmitting explicit join messages. To
eliminate potential scaling issues, PIM-SM limits multicast traffic so that only those routers
interested in receiving traffic for a particular group see it.
Point-to-point network - A network joining a single pair of routers; for example, a 56Kb
serial-line network.
Point-to-point protocol (PPP) - The successor to SLIP, PPP provides router-to-router and host-
to-network connections over both synchronous and asynchronous circuits
POTS - Plain old telephone service.
POTS splitter - A passive filter that separates voice traffic from data traffic.
Presentation - A set of one or more streams presented to the client as a complete media feed,
using a presentation description. In most cases in the RTSP context, this implies aggregate
control of those streams, but does not have to.
Presentation description - A presentation description contains information about one or more
media streams within a presentation, such as the set of encodings, network addresses and
information about the content.
Protocol - The set of rules to send and receiving data and to govern activities within a specific
layer of the network architecture model. Protocols regulate the transfer of data between layers
and across links to other devices and define procedures for handling lost or damaged
transmissions or packets. The protocols also determine whether the network uses peer-to-peer
or client/server architecture.
Protocol-Independent Multicast (PIM) Routing Protocols - Developed by an IETF working
group, PIM provides a standard multicast routing protocol that supports scalable inter-domain
multicast routing across the Internet. This inter-domain multicast routing is not dependent on
the mechanisms provided by any particular unicast routing protocol. . PIM has two modes,
dense and sparse.
public switched telephone network (PSTN) - A telephone system through which users can be
connected by dialing specific telephone numbers.

QoS - quality of service
quadrature amplitude modulation (QAM) - A bandwidth conservation process routinely used
in modems, QAM enables two digital carrier signals to occupy the same transmission
bandwidth.
random delay - The random amount of time a transmission is delayed to prevent multiple
nodes from transmitting at exactly the same time, or to prevent long-range periodic
transmissions from synchronizing with each other.
RAP - Roving Analysis Port
rate-adaptive digital subscriber line (R-ADSL) - An emerging variation of CAP; it divides the
transmission spectrum into discrete subchannels and adjusts each signal transmission
according to line quality.
Reachability - Whether or not the one-way forward path to a neighbor is functioning properly.
For neighboring routers, reachability means that packets sent by a node's IP layer are delivered
to the router's IP layer, and the router is indeed forwarding packets. This means the node is
configured as a router, not a host. For hosts, reachability means that packets sent by a node's IP
layer are delivered to the neighbor host's IP layer.

Real-Time Streaming Protocol (RTSP) - This application-level protocol provides control for
the delivery of data with real-time properties. RTSP enables controlled on-demand delivery of
real-time data, such as audio and video.
Real-Time Transport Protocol (RTP) - RTP provides end-to-end network transport functions
for applications that transmit real-time data over multicast or unicast network services. Such
applications can include audio, video, or simulation data applications.
RED - Random Early Detection
Regional Bell Operating Company (RBOC) - Telecommunication companies formed as a
result of the divestiture of AT&T. RBOCs oversee Bell operating companies.
Relay - A device that interconnects LANs, different kinds of relays include repeaters, bridges,
routers, and gateways.
Reliable multicast protocols - Reliable multicast protocols provide for reliable transmission of
datagrams from a single source host to members of a multicast group. An example of a
reliable multicast protocol is the called Multicast Transport Protocol (MTP). This protocol
gives application programs guarantees of reliability. See also Multicast Transport Protocol
(MTP).
Request - An RTSP request. If an HTTP request is meant, that is indicated explicitly.

Request for Comment (RFC) - An official document used by the IETF to create standards for
use in the Internet.
ReSerVation Protocol (RSVP) - A method developed by the IETF to assist in providing
quality-of-service characteristics to communications over an IP network. The name refers to
the fact that it allows the end-stations to reserve bandwidth on the network. This protocol
supports requests for a specific quality of service (QoS) from the network for particular data
streams or flows.
Response - An RTSP response. If an HTTP response is meant, that is indicated explicitly.
Retention - Defined in the Multicast Transport Protocol to be one of the three fundamental
parameters that make up the transport's state (along with heartbeat and window). Retention is a
number of heartbeats, and though applied in several different circumstances, is primarily used
as the number of heartbeats a producing client must maintain buffered data should it need to
be retransmitted.
Reverse Address Resolution Protocol (RARP) - An Internet protocol that can be used by
diskless hosts to find their Internet address. See RFC 903.
RIP (Routing Information Protocol) - An early BSD UNIX routing protocol that has become
an industry standard
RISC - reduced instruction set computing
RMON - Remote Monitoring
Router - A device that connects two networks at the Network layer (Layer 3) of the OSI
model; operated like a bridge but also can choose routes through a network
Routing - In networking, routing is the process of moving a packet of data from source to
destination. A dedicated device called a router usually performs routing. Routing, a key feature
of the Internet, enables messages to pass from one computer to another and eventually reach
the target machine. Each intermediary computer performs routing by passing along the
message to the next computer. Part of this process involves analyzing a routing table to
determine the best path.
RSVP - Resource Reservation Protocol
RTSP session - A complete RTSP "transaction", e.g., the viewing of a movie. A session
typically consists of a client setting up a transport mechanism for the continuous media stream,
starting the stream with PLAY or RECORD, and closing the stream with TEARDOWN.
Sequenced Packet Exchange (SPX) - A connection-oriented protocol found in Novel NetWare
networks. This transport layer protocol is similar to TCP and together with IPX, provides
connection services similar to TCP/IP.

Shared Ethernet - An Ethernet configuration in which a number of segments are bound
together in a single collision domain; hubs produce this type of configuration where only one
node can transmit at a time.
Simple Network Management Protocol (SNMP) - Allows a TCP/IP host running an SNMP
application to query other nodes for network-related statistics and error conditions. The other
hosts, which provide SNMP agents, respond to these queries and allow a single host to gather
network statistics from many other network nodes.
Single Mode fiber - A type of fiber optic cable used for longer distances and higher speeds
such as long-distance telephone lines. See also multimode fiber.
single-line digital subscriber line (SDSL) - SDSL is HDSL over a single twisted pair.
SLA - service level agreement
SNAP - Subnetwork Access Protocol
SNMP - Simple Network Management Protocol
SONET "Synchronous Optical Network" - A set of standard fiber-optic-based serial standards
planned for use with ATM in North America. Developed by Bellcore. Different types of
SONET run at different speeds, use different types of fiber, and operate over different
distances. There are both single mode and multimode fiber versions.
spanning tree - An algorithm used to create a logical topology that connects all network
segments, and ensures that only one path exists between any two nodes. A spanning tree is
loop-free and is a subset of a network. Multicast routers construct a spanning tree from the
multicast source located at the root of the tree to all the members of the multicast group.
Sparse-mode multicast routing protocols - A category of routing protocol, sparse-mode
routing protocols assume that the multicast group members are sparsely distributed throughout
the network. The multicast group members could be distributed across many regions of the
Internet. There can be just as many multicast group members in sparse mode routing as there
can be in dense mode routing. Sparse-mode routing protocols include the Core Based Trees
(CBT) and Protocol-Independent Multicast - Sparse Mode (PIM-SM) protocols. See also
dense-mode multicast routing protocols
stream-oriented protocol - A type of protocol where data is organized as a stream of bytes and
uses a technique for transferring data such that it can be processed as a steady and continuous
stream. With streaming, a client can start displaying the data before the entire file has been
transmitted. If a client receives the data more quickly than required, saves the excess data in a
buffer. If the data doesn't come quickly enough, however, the presentation of the data is not
smooth.
Switch - A device that connects multiple network segments at the Data Link Layer (Layer 2)
of the OSI model. They operate more simply and at higher speeds than routers
Switched Multimegabit Data Service (SMDS) - High-speed, connectionless, packet-switched,
WAN networking technology.
T1 - A 1.544 Mbps line; it is the same as DS1.
Telco - American jargon for telephone company.
time division multiplexing (TDM) - A digital transmission method that combines signals from
multiple sources on a common path. This common path is divided into a number of time slots
and each signal or channel is assigned its own intermittent time slot, allowing the path to be
shared by multiple channels.
timed-token protocol - The rules defining how the target token rotation time is set, the length
of time a station can hold the token, and how the ring is initialized.
Token - A bit pattern consisting of a unique symbol sequence that circulates around the ring
following frame transmission. The token grants stations the right to transmit.
token passing - A method where each station, in turn, receives and passes on the right to use
the channel. In FDDI, the stations are configured in a logical ring.
Token Ring: - Developed by IBM, this 4 or 16 Mbps network uses a ring topology and a
token-passing access method.

Transmission Control Protocol (TCP) - The protocol at the Internet’s transport layer that
governs the transmission of datagrams or packets by providing reliable, full-duplex, stream
service to application protocols, especially IP. Provides reliable connection-oriented service by
requiring that the sender and receiver exchange control information, or establish a connection
before transmission can occur. Contrast to User Datagram Protocol.
transport service access point (TSAP) - The address that uniquely defines a particular
instantiation of a service and formed by logically concatenating the node's NSAP with a
transport identifier and sometimes a packet/protocol type).
Tunneling - The practice of encapsulating a message from one protocol in another protocol
and using the second protocol to transverse a number of network hops. At the destination, the
encapsulation is stripped off and the original message is reintroduced to the network at its
destination.
twisted-pair - Telephone system cabling that consists of copper wires loosely twisted around
each other to help cancel out any induced noise in balanced circuits.
UDP - User Datagram Protocol
Unicast - The method of sending a packet or datagram to a single address. This type of point-
to-point transmission requires the source to send an individual copy of a message to each
requester. See also anycast, multicast, broadcast, and IP multicasting.

Universal Coordinated Time (UCT) - The number of seconds since 00:00 01/01/1970
Greenwich Mean Time
UTP - Unshielded twisted pair, one or more cable pairs surrounded by insulation. UTP is
commonly used as telephone wire.
variable MTU - A link that does not have a well-defined MTU, such as an IEEE 802.5 token
ring link. Many links; for example Ethernet links, have a standard MTU defined by the link-
layer protocol or by the specific document describing how to run IP over the link layer.
very high bit-rate digital subscriber line (VDSL) - A technology in which modems enable
access and communications over twisted-pair lines at a data rate from 1.54 Mbps to 52 Mbps.
VDSL has a maximum operating range from 1,000 feet to 4,500 feet on 24-gauge wire.
VLAN - virtual local area network
WFQ - weighted fair queuing
wide area network (WAN) - A geographically dispersed network.
Window - One of the fundamental elements of the transport's state that can be controlled to
affect the quality of service provided to the client. It represents the number of user data
carrying packets that may be multicast into the web during a heartbeat by a single member
XDSL - The "x" represents the various forms of digital subscriber line (DSL) technologies:
ADSL, R-ADSL, HDSL, SDSL, or VDSL.
View publication stats

Vo IP

Uploaded by

Copyright:

Available Formats

Vo IP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vo IP

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Voice over IP Networks

Article · January 1999

The user has requested enhancement of the downloaded file.

VOICE OVER IP:

THE INTERNET-BASED TELEPHONY

An Overview of IPv4 and IPv6 14

Understanding RSVP, IP Multicasting and ATMs 71

But What is Layer 3 Switching? 180

More on IP Multicasting 192

More on ATM Technologies 222

The Next Hop Resolution Protocol (NHRP) 249

Broadband Packet Networks and Voice Communication 260

Codecs Methods 300

Voice Over IP: Can We Talk? 311

What to Expect: The Innovators 329

Call Routing 356

The Real Time Streaming Protocol 397

List of Suppliers 404

Glossary of terms 413

increasing demand, of delivering Internet-based telephony as the next technological and

telephony services over the Internet.

engineering challenges it brings.

Plus F200ip Voice FRAD/VoIP and others.

knowledge of the main products and implementation solutions being proposed.

The book is divided in three parts.

voice transferring process over it.

fundamentals of RSVP, IP Multicast and an overview of ATM, which are important

technologies in carrying voice over IP.

Layer 3 switching and gigabit Ethernet as well as their role in VoIP.

Chapter 4, “More on IP Multicasting,” discusses multicasting in workgroups, some of its

Chapter 6, “Broadband Packet Networks and Voice Communication,” discusses broadband

packet networks and its role in voice communication and applications.

implementation issues are discussed, as well as proposed scenarios are presented.

digitization, as well as a video codecs review and audio codecs.

computer telephony integration (CTI), videoconferencing, document-sharing, web-based call

3Com, Motorola, Nuera Communication and others.

inovators such as NetSpeak, NetPhone, Vocaltec, TeleVideo Conversions, Inc., Vienna

Systems, Lucent Technologies, and few others.

characteristics and specification.

Vendors, and Appendix B provides a comprehensive glossary of terms related to VoIP.

Who Should Read This Book

Internet managers and even Chief Information Officers implementing or planning to

About the Author

Marcus Goncalves, holds an MS in CIS, several years of internetworking consulting in the

manufacturers on IT, industry automation and Internetworking security. He has thought

An Overview of IPv4 and IPv6

impending supply of users.

excessive routing overhead.

A Basic Overview of IPv4

The Addressing System of IPv4

up to 65 536 hosts, and there can be at most 16 384 networks.

The Address Management Issues

needed, which waists about 65 000 addresses!

network demand, however, is making the need for IPv6 immediate.

The Need for IPv6

especially as far as security and privacy goes.

as voce over IP and more.

Some of IPv6 Advantages