Download Converged Networks Case Studies

T e c h n i c a l
Converged Networks
Case Studies
P a p e r
Converged Networks
Case Studies
Contents
Overview of Converged Networks
2
What Is Driving Converged Networks?
3
Cost Reduction
4
Emerging Technologies
5
Greater Flexibility and Functionality
5
Standards
6
Converged Network Architecture
6
Case Studies
7
Case 1: Converged Network Support for Call Centers
7
Phase 1: Single Call Center on a Dedicated LAN
8
Phase 2: Two Call Centers on Dedicated LANs, Interconnected by the PSTN
9
Phase 3: Multiple Call Centers on Dedicated LANs, Interconnected by a WAN
10
Phase 4: Multiple Call Centers on Dedicated LANs, Interconnected by a WAN,
with Customer Access over the Internet
11
Phase 5: Multiple Call Centers on Multi-Application LANs, Connected by a
WAN, with Customer Access over the Internet
12
Case 2: Converged Network Support for Financial Transaction Applications
14
Phase 1: Data Only
15
Phase 2: Voice and Data on Business-Critical Networks
16
Phase 3: Voice, Video, and Data on Business-Critical Networks with
Multiple Data Centers
17
Case 3: Converged Network Support for the Virtual Classroom and Corporate Training
18
Phase 1: Small Number of Dedicated LANs with an ATM Campus Backbone
Supporting ELANs
18
Phase 2: Larger Number of Dedicated LANs with a Packet Switched Backbone
19
Phase 3: Multi-Application LANs with a Packet Switched Backbone and
Supporting Video Return
20
Phase 4: Multiple Campuses Interconnected by a WAN
22
Phase 5: Multiple Campuses and Remote Home Sites Interconnected by a WAN
23
Case 4: Converged Network Support for Toll Reduction
25
Phase 1: Toll Reduction over Existing PSTN
26
Phase 2: Toll Reduction with Redundancy and Sophisticated Call Management
27
Phase 3: Toll Reduction for Enterprise Networks, Small/Medium Businesses,
and Consumers
28
Phase 4: Toll Reduction with Advanced Services and Standardization
31
Conclusion
32
1
Acronyms and
Abbreviations
Converged Networks
Case Studies
ACD
automated call distribution
Converged networking is an emerging technology
thrust that integrates voice, video, and data traffic on a single network. The market drivers for
converged networks are cost reduction; support
for sophisticated, highly integrated applications;
and the provision of greater network flexibility
and functionality.
This white paper presents four case studies
focusing on high-influence market segments and
applications that can benefit from converged networking technology. The selection of these examples is intended to provide a basic understanding
of the technology issues involved in network convergence. For each case study, the analysis includes
a set of required technology capabilities.
ATM
Asynchronous Transfer Mode
BGP4
Border Gateway Protocol
Version 4
CoS
Class of Service
CMTS
cable modem transmission
system
CWE
Collaborative Work
Environment
DHCP
Dynamic Host Configuration
Protocol
Overview of Converged Networks
As networking technology becomes pervasive,
opportunities arise for using it in new and
more creative ways. One example is that of
using data networks, rather than the traditional
circuit switched networks, to carry voice and
video traffic. The generic term for this kind of
use is converged networking. Converged networking offers many benefits, including cost
savings and the enabling of new, tightly integrated, multimedia applications.
The World Wide Web has permanently
changed the nature of networking. Before its
appearance, networking was the province of
specialized applications running in private
corporations and research institutions. Today,
networking is used by millions of people
around the world. The Internet has become
the backbone for small business communications. Networking has permanently changed
the way organizations do business.
Like most revolutionary technologies, the
Web has drawn together previously separate
activities and integrated them under a common framework. Web pages no longer provide
only text and static graphics; they also provide
animated graphics, audio, video, and other
multimedia content. Consequently, the Web
supports the convergence of content delivery
DNS
Domain Name Service
DSLAM
digital subscriber loop
access multiplexer
DVMRP
Distance Vector Multicast
Routing Protocol
ELAN
emulated LAN
IEEE
Institute of Electrical and
Electronics Engineers
IETF
Internet Engineering Task
Force
IGMP
Internet Group Management
Protocol
IP
Internet Protocol
IPsec
IP Security
ISDN
Integrated Services Digital
Network
2
over networks. The Web is to content delivery
what backplane buses are to computer systems.
The Web is one example of a larger trend
in networking. Formerly distinct activities are
undergoing integration into a common framework. Integration is occurring at a number of
different levels, most noticeably at the application level, where users expect ease of use
between different applications (such as Web
browsing, calendaring) as well as applications
that incorporate a diversity of data types (such
as documents that embed spreadsheets, graphics, and voice annotation). The motivation
behind this trend includes ease of use, reduced
cost, and increased functionality. Similarly,
users are showing interest in solutions that
provide a diverse range of functionality in a
single network (voice/data/video integration)
and offer the possibility of reduced cost (less
capital equipment acquisition, less need for a
range of technical experts in different areas).
The concept of convergence describes this
trend toward tighter integration. Converged
networking encompasses several aspects, all of
which are related to the aggregation of networking activity.
• Payload convergence is that aspect of converged networking wherein different data
types are carried in the same communications format. For example, while in the past
audio and video traffic was carried over circuit switched networks as Layer 1 bit
streams, while bursty data traffic was carried
over packet switched networks in Layer 3
datagrams, payload convergence describes
the trend to carry both audio/video and
bursty data traffic in Layer 3 datagrams.
Note, however, that payload convergence
does not prohibit the network from handling packets differently, according to their
service requirements.
• Protocol convergence is the movement
away from multiprotocol to single protocol
(typically IP) networks. While legacy networks are designed to handle many protocols (e.g., IP, IPX, AppleTalk) and one type
of data (so called “best effort”), converged
networks are designed to support one protocol and provide the services necessary for
•
•
•
•
•
multiple types of data (such as voice, oneway video, interactive video, best effort).
Physical convergence occurs when payloads
travel over the same physical network
equipment regardless of their service requirements. Both multimedia and Web traffic
can use the facilities of an edge network,
even though the former has more stringent
bandwidth, delay, and jitter requirements
than the latter. Resource reservation, priority queuing and other Quality of Service
(QOS) or Class of Service (COS) mechanisms within the network are used to differentiate the service requirements of one type
of traffic from another and to deliver the
necessary service to each.
Device convergence describes the trend in
network device architecture to support different networking paradigms in a single system. Thus, a switch may support Ethernet
packet forwarding, IP routing and Asynchronous Transfer Mode (ATM) switching.
Network devices may handle data, carried
by a common network protocol (i.e., IP),
that have separate service requirements (e.g.,
bandwidth guarantees, delay, and jitter constraints). In addition, an end system may
support both Web-based data applications
and packet telephony.
Application convergence represents the
appearance of applications that integrate
formerly separate functions. For example,
Web browsers allow the incorporation of
plug-in applications that allow Web pages
to carry multimedia content such as audio,
video, high-resolution graphics, virtual reality graphics, and interactive voice.
Technology convergence signifies the move
toward common networking technologies
that satisfy both LAN and WAN requirements. For example, ATM can be used to
provide both LAN and WAN services.
Organizational convergence is the centralization of networking, telecommunications,
and computing services under a single
authority, for example, the chief information officer. This provides the necessary
managerial framework for integrating voice,
video, and data on a single network.
These aspects of converged networking
allow the integration of voice, video, and data
services from the edge of the network to the
core. The following sections provides a brief
description of the market drivers for converged
networks and a summary of converged network architecture. The remainder of the paper
presents four application case studies for
converged networks and describes the technologies necessary to support successive
deployment phases for each application.
Acronyms and
Abbreviations
ISP
Internet service provider
ISSLL
Integrated Services over
Specific Link Layers
ISUP
ISDN User Part
ITU
International
Telecommunications Union
What Is Driving Converged Networks?
Several emerging forces are driving market
interest in converged networks:
• Cost reduction, both in capital outlay and
technical support expenditures
• The emergence of sophisticated, highly integrated applications that put new demands
on networks
• Greater network flexibility and functionality
• The emergence of industry standards
Organizations will replace their existing
voice, data, and video infrastructures by a converged network only if they anticipate substantial savings in both capital expenditure
and day-to-day operational costs. At the same
time, a converged network must deliver service at least equivalent to existing facilities.
Achieving the necessary cost/service
objective requires the use of emerging and
anticipated technologies. Organizations are
generally leery of using proprietary technologies when faced with major upgrades to their
networks. Consequently, the fundamental
technologies of converged networks must be
standards-based, and the network deployment
must be incremental.
Certain applications are difficult to support on existing communication infrastructures. For example, coordinating customer
voice calls with database accesses that manipulate customer records currently requires specialized application hardware and software.
Over a converged network, packet voice and
database access use a common network, allowing software applications to provide this service and eliminating the need for specialized
application hardware.
IVR
interactive voice response
L2TP
Layer 2 Tunneling Protocol
LAN
local area network
LDAP
Lightweight Directory
Access Protocol
LRU
line replaceable unit
MAC
Media Access Control
MCU
Multipoint Control Unit
NIC
network interface card
NSP
network service provider
ODBC
Open Database Connectivity
OSPF
Open Shortest Path First
PBX
private branch exchange
PPP
Point-to-Point Protocol
PPTP
Point-to-Point Tunneling
Protocol
3
Another market motivation for converged
networks is indirectly related to integrating
voice, video, and data on a single network.
Many of the characteristics necessary for a
converged network, such as robustness, manageability, availability, and so on, are also
desirable characteristics for legacy networks.
As the features that support these characteristics are developed, organizations without a
pressing need for converged networks will be
attracted to products containing such features
in order to improve their existing legacy
networks.
Acronyms and
Abbreviations
PSTN
public switched telephone
network
QoS
Quality of Service
RIP
Routing Information
Protocol
RMON
Remote Monitoring
RSVP
Resource Reservation
Protocol
Cost Reduction
The potential for cost reduction in converged
networks arises from the elimination of
unnecessary infrastructure duplication. It
must be noted that some duplication is desirable in order to meet reliability objectives.
However, there are unjustifiable costs associated with duplicate equipment acquisition and
maintenance for separate data, voice, and
video networks, duplicate management infrastructure for these networks, duplicate personnel to service these networks, and duplicate
facilities costs (for example, for cabling plant,
wire closet floor space, cooling) to bring the
services of these networks to users.
The University of Oklahoma in the U.S.
is deploying IP-based video conferencing to
Choctaw County high schools. They chose
IP-based video conferencing for several reasons.
Integrated Services Digital Network (ISDN)
availability is limited in Choctaw County. At
$92/month and requiring an expensive multiplexer, ISDN is too expensive. Finally, an IPbased system uses the same cable plant for
video conferencing as is used for Internet access.
Polaroid Corporation (Cambridge, Massachusetts) also sees cost reduction possibilities
in converged networking. “Users can reap
RTP
Real-Time Transport
Protocol
RTSP
Real-Time Streaming
Protocol
SLA
service level agreement
SONET
Synchronous Optical
Network
SS7
Signaling System 7
TCAP
Transaction Capabilities
Application Part
ToS
Type of Service
VC
virtual circuit
VPN
virtual private network
WAN
wide area network
xDSL
digital subscriber line
benefits by running voice over Frame Relay
internationally, as voice rates are far higher
outside the U.S.,” says George Deyett, telecommunications operations manager for Polaroid’s
20-country Frame Relay network. “The savings
pay for the cost of the equipment you need in
a matter of months.”1 The principle is simple.
If an enterprise can run all of its applications
on one network, it will save money.
Increasing economic pressures are forcing
network service providers (NSPs) to consider
technologies that provide the highest level of
service for the least cost. Greg Jacobsen, executive vice president of MCI Systemhouse
(Atlanta, Georgia), says, “Today, customers
have five bidders; they pit them against each
other to drive out the biggest penalties, costs,
and service levels, and they ride them like a
hawk.”2 Under scrutiny of this kind, NSPs
must determine the costs of service level agreements (SLAs) to ensure profitability. They
must also effectively manage their networks to
achieve those SLAs.
In the consumer and small business markets, moving long distance traffic onto packet
switched networks will provide significant
reductions in long-distance telephone bills.
For example, Level 3 Communications, Inc.
(Omaha, Nebraska) will provide an integrated telephony and data service that carries
voice traffic over an IP network. Level 3 has
attracted $2.5 billion from Kiewit Capital,
which they plan to spend building a new
international fiber network. Level 3 CEO
James Crowe says, “Our goal is to make every
fax and phone a terminal to access our IP network.” The cost advantages of IP packet
switching will drive this market. “We’re in the
middle of a fundamental change—the same as
the telegraph to the telephone,” Crowe continues. “IP enjoys a 100-to-one cost advantage
over switched networks.”3
1 “Cisco Plots Voice/Data Integration,” Computerworld, October 27, 1997; http://www.computerworld.com/.
2 Emily Kay, “Sleuthing for Services: Managers Closely Scrutinize Outsourcers as They Rely More on Third Parties to Keep
Their Networks Running,” LAN Times, July 1997.
3 Randy Barrett, “Billion-Dollar Net Telco Born,” Inter@ctive Week, January 19, 1998; http://www.zdnet.com/intweek/
daily/980119a.html.
xMDS
Multipoint Distribution
Service
4
Emerging Technologies
The merger of data, voice, and video traffic in
the home market is on the horizon. Communications technologies such as cable modems,
digital subscriber line (xDSL) services, and
Multipoint Distribution Service (xMDS) provide the necessary bandwidth and multiplexing capabilities to support multiple traffic
classes. Furthermore, there are preexisting distribution facilities (coaxial cable and fiber in
the case of cable modems, twisted pair in the
case of xDSL, and electromagnetic spectrum
in the case of xMDS) that enable the rapid
deployment of these technologies. In addition,
computer and communications equipment
manufacturers are developing low-cost products with the potential to utilize these new
interconnection technologies.
Coupling low-cost devices with low-cost
multimedia applications like Microsoft’s free
NetMeeting application will substantially
increase demand for multimedia applications.
This in turn will further accelerate the convergence of networks. The large number of devices
and media types will also encourage network
convergence. It is not economical to provide a
physically separate device for each media type.
Greater Flexibility and Functionality
Converged networks provide the necessary
infrastructure to support applications integrating voice, video, and data management. This
allows customers to achieve their objectives
more effectively and efficiently. The Gartner
Group writes, “We believe that interactive
media will have as much of an impact on corporate and government computing applications as client/server computing.”4
IT personnel in enterprise networks used
to worry about what power users might do to
their networks. With the availability of audio
and video sound clips on the Web and with
applications like PointCast gaining wide
acceptance, even average users are now a force
for convergence within the enterprise network.
In addition, enterprises are now providing
multimedia content on their own intranets.
Corporations use multimedia on their networks
to invigorate corporate training and more easily convey corporate messages. Guy Baltzelle,
instructional designer for AT&T Wireless
Services in Redmond, Washington, says, “Training on the wireless industry’s standards, protocols, network elements, and mobile switching
might seem static without some entertaining
graphics.”5 Without multimedia, corporate
messages and training would be less effective.
The MITRE Corporation (Bedford,
Massachusetts) is working on a Collaborative
Work Environment (CWE) application, which
incorporates text, audio, and multicast full
motion video. CWE provides users with a rich
set of information management tools, allowing them to carry out their job assignments
more effectively. MITRE intends to use CWE
both as an in-house tool and as a model for its
government customers.
The University of Mississippi also sees
their network converging and seeks the latest
networking technologies. When asked what
motivates the University to move to a converged network, network manager Mike
Myrick replies, “People are starting to experiment with multicast. Desktop video conferencing may be next.”6
Convergence is also an increasingly attractive prospect in the high-end Web site hosting
and collocation industry. Traditional sites provide low-priority transactions incorporating
text and graphics. Today’s sites also provide
audio and video as well as electronic commerce transactions, which require extremely
high priority and security. Dataquest predicts
the total collocation market will grow to $2.6
billion by the year 2001, from $633 million in
1997, with high-end business increasing
exponentially.7
4 Gartner Group, “Interactive Media: Integrative View and Commentary,” March 28, 1997.
5 Kathleen Murphy, “Multimedia Applications on Rise Within Corporate Webs: Shockwave, Other Tools Being More
Widely Deployed,” Webweek, December 6, 1996.
6 Jeff Caruso, “Ole Miss Students Tap VLAN’s Power; Layer 3 Moots Issue of Moves, Adds, Changes,” Techweb, December 1,
1997.
7 Michelle V. Rafter, “Exodus Invests in Data Centers as High-End Outsourcing Market Booms,” Webweek, December 15, 1997.
5
dge
LAN e rk
o
w
t
ne
dge
LAN e rk
o
w
t
ne
core
WAN rk
o
w
t
ne
Figure 1. WAN Core Network with LAN Edge
Networks
Standards
Converged networks depend on the availability of standards to ensure their widespread
deployment. Standards useful in a converged
network, such as International Telecommunications Union (ITU) H.323, Institute of Electrical and Electronics Engineers (IEEE)
802.1p/Q, and Real-Time Transport Protocol
(RTP), to name a few, have been developed
over the last several years and are now being
implemented in products.
ITU standards such as H.323 enable
packet switched networks to carry telephony
traffic. IEEE standards 802.1p and 802.1Q
support prioritization of data traffic at Layer
2, which enables QoS support. Gigabit Ethernet increases bandwidth, allowing converged
networks to carry increased traffic load. Internet Engineering Task Force (IETF) standards
such as RTP, Integrated Services over Specific
Link Layers (ISSLL), and Real-Time Streaming Protocol (RTSP) enable IP networks to
carry multimedia traffic.
dge
LAN e rk
o
w
t
e
n
dge
LAN e rk
o
w
t
ne
AN
lel W
Paral tworks
ne
core
Figure 2. Parallel WAN Core Networks
6
Converged Network
Architecture
There are many ways to implement a converged network. One
might assume a homogeneous infrastructure, either completely packetbased and connectionless (such as shared
and switched LANs, packet-service WANs) or
connection-oriented (such as ATM to the desktop and long-distance ATM clouds). In practice, neither of these architectural options is
viable, due to the different economic and performance requirements for LANs and WANs.
A converged network that spans large distances will have a WAN core network that is
surrounded by LAN edge networks (Figure 1).
In the general case, the edge networks will
be based on different technologies. Thus, one
edge network may be based on a switched
Ethernet fabric (i.e., one without Layer 3
routing), another on routed Ethernet segments, and a third on ATM LAN technology.
The core may be a single technology network, such as Frame Relay, ATM, or the Internet. Alternatively, it may consist of multiple
parallel networks, some connection-oriented
and some packet switched (Figure 2).
While it is possible to solve many QoS
problems in the LAN by radical overprovisioning, this is not economically feasible in a
WAN. Thus, WANs are engineered to optimize
their resource use for a particular class of traffic.
Pure packet-based networks, such as a large
portion of the Internet, provide good service
to bursty, non–time-critical traffic. They do
not deliver good service to traffic with tight
bandwidth, delay, and jitter
requirements. Connection-oriented networks such as ATM,
on the other hand, provide good
service to traffic with tight bandwidth, delay, and jitter requirements. However it is costly to use
these networks for bursty traffic, since
they reserve resources and charge for
them whether or not they are used.
Consequently, a converged network is
likely to use the parallel WAN networks
according to service requirements of the traffic routed to them. LANs will carry voice,
data, and video traffic over a common physical infrastructure. At the LAN/WAN boundary, traffic will be classified and routed over
the most appropriate WAN network. For
example, bursty, non–time-critical traffic will
be routed over a packet switched WAN. Multimedia data, however, will probably be routed
over a connection-oriented network, such as
ATM, that provides QoS guarantees.
Converged networks may be able to optimize application performance by customizing
network devices on an application-by-application basis. Filtering network traffic in a way
that identifies application traffic and then
handling that traffic according to the application’s unique processing requirements is an
example of this approach. The use of active
networking,8 whereby applications download
small programs or configuration data into network devices, is another example. There are
some important issues to address, such as
security, resource management, and interdevice coordination, but there is also an
opportunity to obtain significant competitive
advantage if the network can optimize services
for important applications.
Case Studies
Converged networks require new technology
for their implementation and deployment.
The remainder of this paper presents case
studies that illustrate the phased deployment
of technology to support four key applications
as they grow within a converged network.
Case studies are presented for the following
four applications:
• Call centers
• Financial transaction applications
• Virtual classrooms and corporate training
• Toll reduction
Case 1: Converged Network Support
for Call Centers
Call centers are business units that accept
telephone calls in order to provide customer
service, such as product purchase, product
maintenance, customer relations, and customer support. Centers may be third-party
outsourcing businesses or organizations within
a large corporation.
A call center is staffed by agents who accept
customer calls and then coordinate the provided service. Normally, this requires the agent
to associate the customer with records or other
information held in a database and to update
these records according to the service request.
A service call proceeds as follows. First,
the incoming call is routed to an appropriate
free agent. If no agents are available, the call is
routed to holding equipment that provides the
customer with an appropriate message and
then queues the call for service. When an
agent answers the call, the calling number may
be used to find a customer database record,
which provides the agent with information
necessary to service the call. In some cases the
customer may provide additional information,
such as account or tracking numbers, that is
used to retrieve additional data. Once the service call is complete, the agent releases it and
becomes available for further service requests.
Existing call centers utilize a variety of
proprietary call service equipment, known as
automated call distribution (ACD) servers,
which tie a public switched telephone network
(PSTN) call to a PC. These servers extract
incoming call information, such as the calling
ID, passing it to an application running on
the PC, which performs the necessary database access. They also provide hold-queue,
interactive voice response (IVR), accounting,
and monitoring services. ACD servers are
expensive and not easily customized to meet
customer requirements, and they present significant complexities when deployed in a distributed environment involving multiple call
center sites.
Consequently, there is significant motivation for customers to migrate to a converged
network solution. Converged networks allow
both the telephone call and the caller’s service
information to arrive at the agent over a
8 David L. Tennenhouse and Davide J. Wetherall, “Towards an Active Network Architecture,” Computer Communication
Review, ACM Special Interest Group on Data Communication, April, 1996, pp. 5–18.
7
enter
Call c
per
r
serve
tekee
3 ga
H.32
base
Data
PSTN
r
serve
LAN
mer
Custo
eway
3 gat
H.32
•••
t stat
Agen
Agen
Figure 1-1. Single Call Center on a Dedicated LAN
common communications fabric. The ACD
server is replaced by an ACD application running on a call center server that distributes
packet voice calls and coordinates them with
customer record retrieval. This reduces cost by
using standard, off-the-shelf hardware, provides the foundation for more flexible call center applications, and naturally allows the call
center application to be distributed over multiple call center sites.
The migration of call centers to converged networking is described here in five
phases. In each phase, the solution builds on
functionality made available in the preceding
phases. In addition, the solution provided at
each phase introduces new flexibility in how
the call center is deployed.
Phase 1: Single Call Center on a Dedicated LAN
Perhaps the simplest way to integrate call center voice and data on the same network is to
dedicate a LAN exclusively to call center operations (Figure 1-1).
This configuration is attractive to costconscious customers who have proprietary ACD
server equipment and who want to have more
flexibility in customizing their applications
and to decrease the complexity of multi-site
deployments. The call center server provides
some of the functionality of the ACD server,
including hold queues, IVR, and accounting
8
ion
ion
t stat
functions. To ensure the appropriate level of
service without introducing traffic prioritization, the LAN must be over-provisioned.
The following technologies are required
to implement this configuration:
• H.323 gateway. An H.323 gateway packetizes voice traffic arriving over the PSTN
and forwards it to an agent’s station.
• H.323 client on end system. The end system serving the call center agent must be
able to handle H.323 traffic.
• H.323 gatekeeper. An H.323 gatekeeper
provides basic call management functions
for routing calls coming through the H.323
gateway to an agent station.
• Multipoint Control Unit (MCU). An
MCU provides the functionality to implement teleconferencing, which allows multiple agents to cooperate to service an
incoming call.
• Efficient multicast routing and filtering.
To implement teleconferencing, the dedicated LAN must support efficient multicast
routing and filtering, which reduces the cost
of overprovisioning the LAN.
• Monitoring capabilities. LAN traffic must
be monitored to ensure that it is distributed
according to the policy implemented by the
call center server and that LAN resources
continue to be overprovisioned as the call
center grows. Both RMON2 and distributed RMON can be used for this purpose.
• Reliable Domain Name Service (DNS)/
Dynamic Host Configuration Protocol
s
enter
se
base
Data
erver
Call c
rver
r
eepe
LAN
eway
3 gat
gatek
3
H.32
•••
H.32
te
Priva
link
tion
t sta
Agen
Agen
enter
PSTN
Custo
ion
t stat
bas
Data
mer
Call c
ver
e ser
r
serve
er
LAN
eway
3 gat
3
H.32
eep
gatek
•••
H.32
tion
t sta
Agen
ion
t stat
Agen
Figure 1-2. Call Centers on Dedicated LANs Interconnected by the PSTN
(DHCP). As agents arrive at and leave work,
they must reconnect and disconnect their
machines from the call center application.
This means their PCs must obtain IP address
leases as well as locate various servers implementing the call center functions. Consequently, there must be reliable DNS and
DHCP services to ensure that calls are not
dropped during shift transitions.
• Resilient links and hot-swappable line
replaceable units (LRUs). The underlying
communications fabric must be reliable as
well. When links fail, backup links must automatically take over the new load. Resilient
links provide this capability. When network
devices experience failures in their compo-
nents, the smallest replaceable part that contains the failed component (an LRU) must be
swapped out and a correctly operating part
swapped in. To ensure the reliability necessary
for a call center, LRUs must be hot-swappable; that is, the network device should continue to operate while the LRU is replaced.
Phase 2: Two Call Centers on Dedicated LANs,
Interconnected by the PSTN
One way of generalizing the single dedicated
LAN call center is to allow it to be distributed
across multiple sites. In the simplest case, two
sites can be interconnected by the PSTN with
private link interconnection of the gatekeepers
(Figure 1-2).
9
C
er
p
ekee
3 gat
H.32
erver
nter s
all ce
H.32
erver
nter s
e
c
l
l
Ca
per
ekee
3 gat
ver
ser
base
Data
LAN
ay
ew
3 gat
H.32
base
•••
Data
r
serve
•••
PSTN
3
H.32
n
statio
Call
r
eepe
gatek
Agen
t
Agen
WAN
er
r serv
cente
ion
t stat
ion
t stat
Agen
t
Agen
eway
3 gat
H.32
LAN
n
statio
per
enter
Call c
PSTN
r
serve
Custo
mers
ekee
3 gat
H.32
mers
Custo
base
LAN
ay
ew
3 gat
H.32
Data
r
serve
LAN
ver
r
se se
ba
Data
•••
•••
ion
t stat
ion
t stat
Agen
tion
t sta
Agen
eway
3 gat
H.32
Agen
t
Agen
n
statio
Figure 1-3. Multiple Call Centers on Dedicated LANs Interconnected by a WAN
Using multiple call center sites is attractive
for a number of reasons:
• It allows the placement of call center sites in
different time zones, which increases the
hours during which the call center is operational.
• It allows customers to call a particular site
and still use the spare capacity of a remote
site when the first becomes oversubscribed.
• It decouples call site operations from limitations such as physical plant space, available phone numbers, and trained agent
availability.
• It allows large organizations to distribute
call center operations over a number of
administratively separate suborganizations
without requiring them to share space.
The following additional technologies are
required to support this configuration:
• H.323 gatekeeper coordination. Both sites
must have their own H.323 gatekeepers,
which must to coordinate with one another.
This requires a gatekeeper-to-gatekeeper
protocol supporting basic functionality.
10
• Signaling System 7 (SS7) integration with
H.323. When a call request arrives at an
H.323 gatekeeper that needs to be rerouted
to another call center, the gatekeeper (or
more likely an embedded SS7 gateway)
signals the rerouting information to the
PSTN using SS7, the call signaling protocol
used within the PSTN.
Phase 3: Multiple Call Centers on Dedicated
LANs, Interconnected by a WAN
The next level of generality supports multiple
call center sites by interconnecting them
through an overprovisioned WAN (Figure 1-3).
Call forwarding is achieved by H.323 gateway
support of SS7.
Since customer data may reside on a
remote database server, call center LANs are
interconnected by a WAN. This phase also
eliminates the private link required in phase 2,
since inter-gatekeeper traffic can now travel
over the WAN. These characteristics enable
large customers to build large call centers distributed over many sites.
directly from customer PCs using packet telephony over the Internet (Figure 1-4).
The addition of Internet access allows the
call center to service new customers who want
to receive service from their packet voice-capable PCs. This enlarges the market served by
the call center, thereby increasing potential
revenue.
The Internet currently does not provide
sufficient service guarantees to support business-grade voice traffic. However, the IETF is
working on this problem and may have a solution in a reasonable time frame. In addition,
use of the Internet introduces significant security issues that must be addressed.
The following additional technologies are
required for this configuration:
The following additional technology is
required for this configuration:
• Multicast distribution management and
troubleshooting. Support of an arbitrary
number of call center sites introduces scaling considerations for multicast, which is
required for MCU teleconferencing. In
order to effectively address this issue, the
converged network must support effective
multicast distribution management and
troubleshooting.
Phase 4: Multiple Call Centers on Dedicated
LANs, Interconnected by a WAN, with Customer
Access over the Internet
Another generalization of call centers operating over converged networks allows incoming
calls not only from the PSTN, but also
Call
per
H.32
3
ee
gatek
er
r serv
cente
eper
ateke
g
3
2
H.3
ver
e ser
bas
Data
LAN
ay
ew
3 gat
H.32
r
serve
enter
Call c
ver
e ser
•••
bas
Data
•••
PSTN
n
statio
Agen
per
tekee
23 ga
Call
tion
nt sta
Age
WAN
er
r serv
cente
ion
t stat
n
tatio
ts
Agen
t
Agen
eway
3 gat
H.32
LAN
r
eepe
3
H.32
H.3
PSTN
rver
ter se
Custo
en
Call c
gatek
mers
Custo
LAN
y
ewa
3 gat
H.32
rver
se se
t
Agen
3 ga
H.32
LAN
•••
ba
Data
•••
ion
t stat
Agen
y
tewa
r
serve
base
Data
tion
t sta
Agen
n
statio
t
Agen
n
statio
net
Inter
net
Inter
mers
custo
Figure 1-4. Multiple Call Centers on Dedicated Lans Interconnected by a WAN with Customer Access
over the Internet
11
mers
• IP differentiated services. The use of IP to
carry voice traffic requires support for prioritization. Current work in the IETF is investigating use of the Type of Service (ToS)
field in IP headers to tag traffic according to
its urgency, as well as resource reservation by
means of the Resource Reservation Protocol
(RSVP). RSVP is a signaling protocol used
for reservation, and ToS bits indicate a
desired priority. There must be mechanisms
in Layer 3 switches and routers to implement this priority, such as packet scheduling
algorithms in routers or 802.1p–compliant
priority queuing mechanisms in switches.
Either of these approaches, or another that
provides the necessary IP traffic handling
characteristics, is required to support business-grade packet telephony over the
Internet.
• ISSLL-LOW. In the most common case,
customer PCs will be connected to the
Internet via a dial-up link connected to
remote access equipment. Since voice and
data traffic will share a common link, a link
traffic prioritization scheme must be used to
ensure that voice traffic has precedence over
data traffic. The ISSLL-LOW standard
defines such a scheme.
• Virtual private networks (VPNs). Many
packet voice applications assume that packets sent between the sender and receiver
arrive in order. However, IP may re-order
packets carried over the Internet. Consequently, a VPN tunneling protocol, such as
Point-to-Point Tunneling Protocol (PPTP)
or Layer 2 Tunneling Protocol (L2TP),
must be used for voice traffic to ensure that
packets arrive in order at the receiver when
voice traffic transits the Internet.
• Media protection. Since the Internet does
not provide sufficient reliability for business-grade voice traffic, and since voice traffic is not suited for error correction schemes
based on retransmission, forward error correction techniques are necessary to ensure
the appropriate level of reliability for voice
traffic over the Internet.
• IP Security (IPsec). Traffic over the Internet
is inherently unsecure. Since call center
voice traffic may carry business-sensitive
12
data, it must be protected by a security protocol providing confidentiality, integrity,
and authentication services. IPsec is the
standard protocol for these services.
• Cryptographic policy management. Managing IPsec is an arduous task unless there is
some help in the form of cryptographic policy management. This is required in any
practical, large-scale deployment of IPsec.
• Security policy management. It is likely
that once customers can access call centers
directly over the Internet, new applications
will arise that utilize this direct connectivity.
This will turn call centers into extranets,
whereby customers are allowed access to
previously isolated systems. To control the
security threats this introduces, call centers
will require security policy management systems, such as the Multilayer Firewall and
Network Login, which protect the call center from security threats mounted from
within the call center LAN.
Phase 5: Multiple Call Centers on MultiApplication LANs, Connected by a WAN, with
Customer Access over the Internet
As the market for call centers on converged
networks matures, customers will require even
tighter integration of the center with the rest
of their business. For example, customers will
integrate call center and financial transaction
applications, such as SAP, in order to provide
business-critical services to callers. Thus,
LANs will be shared by call center operations
and other applications (Figure 1-5).
Implementing call center operations on a
multi-application LAN allows businesses to
integrate other applications with call center
activity. For example, call centers used for
product purchase or other business transactions could integrate call center services with
financial transaction services. This would
allow an agent to service an incoming call, use
the identified customer’s records to authorize
purchases, and then use the financial transaction application to execute them.
This is the first phase in which large-scale
converged networks are a factor, introducing
scaling, reliability, and prioritization requirements.
r
Othe erver
s
n
o
i
t
plica
r
Othe erver
ns
o
i
t
a
pplic
ap
a
r
Othe lient
c
o
i
t
a n
pplic
a
r
Othe lient
nc
o
i
t
a
c
appli
Call er
r serv
t
cen e
3
H.32 er
eep
k
e
t
a
g
Call er
r serv
t
n
ce e
3
H.32 er
ep
e
k
e
gat
ver
ser
base
Data
LAN
ay
ew
3 gat
H.32
base
•••
Data
r
serve
•••
PSTN
3
H.32
n
statio
r
eepe
gatek
Call
Agen
tion
nt sta
Age
WAN
rver
r se
cente
ion
t stat
ion
t stat
Agen
t
Agen
eway
3 gat
H.32
LAN
per
enter
Call c
PSTN
r
serve
Custo
mers
tekee
3 ga
H.32
mers
Custo
LAN
3
H.32
ay
gatew
y
tewa
r
serve
base
a
t
a
D
LAN
base
Data
•••
r
serve
•••
n
tatio
ent s
t
Agen
Ag
ion
t stat
Agen
n
tatio
ent s
Ag
on
licati
r app
t
clien
Othe
3 ga
H.32
r
Othe n
tio
a
c
i
l
app er
v
ser
n
o
licati
r app
Othe lient
c
net
Inter
ers
ustom
net c
Inter
Figure 1-5. Multiple Call Centers on Multi-Application LANs Connected by a WAN with Customer Access
over the Internet
The following additional technologies are
required for this configuration:
• Prioritization of LAN traffic. Priority queuing of LAN traffic requires tagging of
MAC-level frames and switch support for
priority queuing. IEEE standard 802.1Q
defines frame tagging, while 802.1p defines
how an 802.1D-compliant switch can
implement priority queuing based on those
tags. LAN equipment such as switches and
network interface cards (NICs) must support these standards (or their relevant parts)
so voice traffic can receive higher priority
than data traffic.
• Policy management of traffic prioritization. It is impractical to manually configure
a large number of switches and NICs in
order to implement a coordinated, high-
13
n
statio
ation
pplic
a
r
e
h
r
Ot
serve
priority service for voice traffic. Consequently, call centers on multi-application
LANs require policy management tools for
configuring priority information in network
devices.
• Bulk configuration of network devices. A
large scale converged network presents significant management problems that cannot
be met by manual device configuration. To
reduce costs and free network management
personnel to work on problems with solutions that cannot be automated, devices
must be managed as groups, rather than as
single systems. This requires network management tools that support coordinated
configuration of devices.
• Rapid, coordinated fault-recovery. When
parts of a large scale converged network fail,
manual methods of recovery are expensive
and time consuming. For call center support,
converged networks must provide rapid,
coordinated, and automated network fault
recovery.
• Enhanced gatekeeper-to-gatekeeper interactions. Basic gatekeeper functionality provides for call hand-off on a per call basis. In
a large scale converged network, more
sophisticated interactions are necessary. For
example, there may be a requirement for
load-balancing or fail-over between gateways
in different call center sites. Furthermore,
-end
Back rk
o
w
t
e
n
prise
Enter rk
o
netw
lients
SAP c
Figure 2-1. SAP Distributed Architecture
14
s
erver
tion s
ca
Appli
migration of agents between sites requires
dynamic distribution of agent location
information between gatekeepers.
Case 2: Converged Network Support for
Financial Transaction Applications
Financial transaction applications have a wide
range of uses within vertical market segments,
such as the financial industry, and within horizontal markets, such as the financial arms of
corporations in all industries. One of the most
common applications of this kind is SAP,
which is used for general ledger, accounts
payable, accounts receivable, manufacturing,
shipping and receiving, and order processing
and fulfillment, among other things.
SAP is a three-tiered application (Figure
2-1). A SAP client makes a request to an
application server, which implements all business logic. This functional distribution results
in a very thin client, which is advantageous
since the number of clients may be very large.
The application server accepts a client request
and accesses data in back-end databases to service the request.
A typical network supporting SAP separates the physical subnetwork holding the
database servers from the rest of the network,
i.e., from those parts holding the clients. The
application server acts as the mediator between
the two. In certain cases, other applications may access the database
servers as well.
Maintaining a separate physical back-end subnetwork for the
database servers is expensive. Not
only must the subnetwork have
dedicated equipment, but management of the enterprise network is incoherent. In effect
there are two networks to
manage, the database subnetwork and the rest of
the enterprise netvers
e ser
s
work. Consequently,
a
b
Data
IT organizations are
motivated to integrate the database subnetwork into the enterprise network.
To accomplish this integration, certain
business-critical requirements must be met.
Traffic between the application servers and the
databases must be high priority, since financial
transactions are the lifeblood of a commercial
company. Communications between the
application servers and the database must be
highly available and reliable. In some deployments (for example, the securities industry),
even a small delay in a transaction can cost
millions of dollars.
Integrating a financial transaction application into an enterprise is further complicated as companies move to converged
networks. In addition to data traffic, transactions must compete in these networks with
high QoS multimedia traffic, such as packet
voice. However, there are compelling reasons
other than cost why financial transaction
applications may need to use the services of a
converged network. An important example is
the use of such applications in call centers to
support product purchase, shipment tracking,
and other customer service objectives.
The migration of financial applications to
converged networks is described in three
phases. In each phase, the solution builds on
functionality made available in preceding
phases. In addition, the solution provided at
each phase generalizes the deployment scenarios for the application.
•
•
•
•
Phase 1: Data Only
Existing applications and network architecture
supporting financial transaction applications
is the baseline for financial transaction application deployment on converged networks.
This phase addresses how financial transaction applications currently operate. The basic
requirement is high availability and reliability
of network services.
The technologies required in this phase
are required in all subsequent phases. These
technologies are:
• Fast, convergent routing. When failures
occur in a large network, the routing protocol must react quickly to restore connectivity. Routing protocols such as Routing
Information Protocol (RIP) do not have this
characteristic, while Open Shortest Path
First (OSPF) does. Consequently, networks
•
•
supporting financial transaction applications should use OSPF.
Routing domain support. Large networks
supporting financial transaction applications
must be partitioned into routing domains;
otherwise it is difficult to contain failures
affecting routing information. Inter-domain
routing protocols such as Border Gateway
Protocol v4 (BGP4) are then necessary to
route between these domains.
Over-provisioned LANs and WANs. Business-critical applications such as SAP must
always have all necessary network resources
available for execution. In phase one, this is
guaranteed by radical overprovisioning of
LANs and WANs.
Monitoring capabilities. Monitoring of
LAN traffic is required to ensure that traffic
on the dedicated database LAN conforms to
site policy, and for capacity planning to
ensure that LAN resources continue to be
overprovisioned. Both RMON2 and distributed RMON can be used for this purpose.
Resilient links and hot-swappable LRUs.
Highly available and highly reliable networks must recover quickly from link and
network device failures. Resilient links allow
the network to continue in service when a
link fails. Hot-swappable LRUs allow network devices to be repaired while online
and in operation.
Reliable DNS/DHCP. The support of mission-critical applications in shared networks
requires stable IP address management.
When a client starts a transaction, it must
locate the appropriate application server,
which is normally identified by DNS name.
Consequently, DNS must provide a reliable
service. Similarly, when PCs running client
code boot, they must be able to obtain an
IP address, which requires a reliable DHCP
service.
Monitoring tools for network management. Rapid response to network failures
requires real-time monitoring tools that recognize and diagnose faults. Network management applications must tie into these
tools so that faults can be repaired quickly
before they become critical.
15
vers
e ser
bas
Data
lients
SAP c
prise
Enter rk
o
w
t
e
n
vers
n ser
catio
Appli
Figure 2-2. Voice and Data Support on a
Business-Critical Network
Phase 2: Voice and Data on Business-Critical
Networks
There are a number of reasons why a customer
might want to deploy a business-critical application on a converged network supporting
both voice and data. For example, in phase 5
of call center evolution described above, financial transaction software is used to service purchase requests made during a customer call
session. Furthermore, it is expensive to maintain a separate back-end network for application server–to-database interactions. Moving
such interactions over a common network
supporting multiple applications types
increases network operation efficiency.
Moving financial transaction applications
to a converged network requires the provision
of priority services. Once these are available,
the IT department can move the database
servers onto the enterprise network, thereby
eliminating the requirement for a separate
back-end subnetwork (Figure 2-2).
It may be that these departments will
migrate the database servers to the enterprise
network before supporting voice. However, the
set of technologies required to give financial
transaction traffic high priority are the same
set required to support both voice and highpriority data on a converged network. Consequently, the technology descriptions given here
apply to both situations. The following additional technologies are required for phase 2:
16
•
•
•
•
• IP differentiated services. The use of IP
to carry financial transaction traffic requires support for prioritization. Current work in the
IETF is investigating use of
the Type of Service (ToS) field
in IP headers to tag traffic
according to its urgency, as well
as resource reservation by means of the
Resource Reservation Protocol (RSVP).
RSVP is a signaling protocol used for
reservation, and ToS bits indicate a
desired priority. To implement this priority, there must be mechanisms in Layer
3 switches and routers such as packet scheduling algorithms in routers or 802.1p-compliant priority queuing mechanisms in
switches.
Prioritization of LAN traffic. Priority queuing of LAN traffic requires tagging of
MAC-level frames and switch support for
priority queuing. IEEE standard 802.1Q
defines frame tagging, while 802.1p defines
how an 802.1D-compliant switch can
implement priority queuing based on those
tags. LAN equipment such as switches and
NICs must support these standards.
Policy management of traffic prioritization. It is impractical to manually configure
a large number of switches and NICs. Consequently, financial transaction applications
require policy management tools for configuring priority information in network
devices.
Bulk configuration of network devices. A
large-scale converged network presents significant management problems that cannot
be met by manual device configuration. To
reduce costs and free network management
personnel to work on problems with solutions that cannot be automated, devices
must be managed as groups, rather than as
single systems. This requires network management tools that support coordinated
configuration of devices.
IPsec. Financial application data is sensitive
and requires protection from unauthorized
access. Moving this data in the clear across
the enterprise network presents a significant
opportunity for unscrupulous employees
•
•
•
•
and contractors to either sabotage businesscritical operations or obtain potentially
valuable information. The use of the confidentiality, integrity, and authentication
services of IPsec, which is the standard protocol for protecting IP traffic, eliminates
many of these security vulnerabilities.
Cryptographic policy management. Managing IPsec is an arduous task unless there is
some help in the form of cryptographic policy management. This is required in any
practical, large-scale deployment of IPsec.
Security policy management. IPsec provides strong security services, but is expensive in terms of both economic cost and
computing resources. It is best to place
IPsec protection across enterprise network
segments that have a high exposure to
attack. Within more isolated segments,
security policy management technologies
such as Multilayer Firewall and Network
Login can provide sufficient protection at a
lower cost.
VPNs. The application server–to-database
traffic of a financial transaction application
currently runs over a protected, dedicated
LAN. When the database servers are moved
to the enterprise, there is no reason why
they must be co-located. Some may be
located in different parts of the enterprise
and communications between them and the
applications servers may move over a WAN.
If the application protocol between the
application servers and databases relies on
certain Layer 2 characteristics, such as packets not being reordered, these characteristics
must be restored for operation across a
routed network. VPN tunnels provide these
reliability features.
ISSLL. In order to provide priority service
across LAN segments, 802.1p/Q tags must
be mapped into IP-differentiated service priorities. ISSLL is an emerging IETF standard
that defines how to perform this mapping.
Phase 3: Voice, Video, and Data on BusinessCritical Networks with Multiple Data Centers
In the final phase of integrating financial
transaction applications onto a converged network, voice, video, and data are carried by the
common network. The introduction of video
services may occur to achieve business-critical
objectives (such as to provide top company
executives with video-teleconferencing capabilities on their desktops) or for non-businesscritical purposes (such as broadcast talks or
business-related news programs to employee
desktops). In either case, video traffic may
stress networking equipment, introducing
more opportunity for network failure.
In this phase, database servers are placed
in multiple data centers, each under the control of a separate administration. Using multiple data centers provides backup of critical
data and allows a large company to organize
its financial work according to its organizational structure (for example, subsidiaries run
their own data centers, which interact with
those of other subsidiaries). The following
additional technologies are required for phase 3:
• Management of failover activity. Multiple
data centers allow auto fail-over when a center becomes unavailable. However, configuration of application servers so they move
their transactions to the appropriate databases in such failure situations may be complex. Consequently, establishing fail-over
policy in terms of high-level objectives is
necessary. This requires a failure policy
management system.
• Capacity planning and better monitoring
tools. To ensure that financial transaction
applications experience adequate service,
network capacity must be sufficient to support all high-priority traffic. Thus, capacity
planning is an important activity. Since converged networks are much more complex
than existing data-only networks, better
simulation and analysis tools are necessary.
In addition, better monitoring tools are
required to provide the data necessary for
simulations and analysis.
• Standardized benchmarking/testing
methodologies. When simulation and
analysis indicate a network upgrade, the IT
department must use network device performance data to determine what equipment is
needed and where it should be placed. Since
converged networks support classes of traffic
not normally observed in currently deployed
17
networks, network device vendors must
establish standard and enhanced benchmarking and testing methodologies so customers can accurately plan their future
equipment acquisitions.
• WAN compression. The use of multiple
data centers will create inter-center traffic
that in general will move over the WAN.
Since some of this traffic may consist of large
data transfers, WAN efficiency becomes an
issue. WAN compression techniques provide
for the most efficient use of WAN resources,
thereby reducing the cost of multiple data
center operations.
• Point-to-Point Protocol (PPP) over Synchronous Optical Network (SONET). In
addition to WAN compression, higher
WAN bandwidth will alleviate inter-center
traffic bottlenecks. PPP over SONET eliminates overhead imposed by technologies
such as ATM, thereby increasing the bandwidth delivered to the WAN customer for
the same cost.
Case 3: Converged Network Support for the
Virtual Classroom and Corporate Training
Customers in the education market include
public and private elementary and secondary
schools, vocational schools, trade schools,
community colleges, four-year colleges, bachelor and graduate degree-granting universities,
and professional graduate schools such as
those for law and medicine. In addition, local,
state, and federal government departments as
well as private industry generally contain organizations that provide educational services
similar to those offered by more traditional
schools.
The virtual classroom, where students
attend classes in locations remote from the
teacher or lecturer, provides an important
application for converged networks. Previously,
virtual classrooms were implemented using
traditional communications facilities over analog carrier equipment. However, there are
several opportunities for enhancing the educational experience by carrying voice, video, and
data traffic between the studio, where a lecture
or other educational content is produced, and
the premises where the students are located.
18
For example, whiteboard data can be used to
share a common drawing space between lecturer and student, allowing both to illustrate
points during a question and answer interaction. Class notes can be distributed electronically during lectures and annotated by the
teacher in real time to correct errors or improve
exposition. Students can hand in homework
electronically using e-mail, and then receive
individual help from a teacher during virtual
office hours. There are some early adopter
virtual classrooms based on digital communications supporting converged networking
features.
The basic architecture for a virtual classroom includes a studio, which may be a dedicated facility or a lecture hall equipped with
audio and camera equipment, and one or
more remote classrooms. The latter may be
halls or rooms with large-screen projection
equipment, rooms with individual desktop
machines dedicated to virtual classroom activity, or individual desktop machines located in
students’ own quarters. There is a requirement
for rendezvous between voice, video, and data
traffic created both at the studio and at the
remote classroom, which is a function of
video-conferencing software.
The migration of virtual classrooms to
fully converged networking solutions is
described in five phases. The first phase represents how a virtual classroom might be built
using existing networking capabilities. Each
succeeding phase builds on the technology of
the previous ones to provide more flexible
deployment options.
Phase 1: Small Number of Dedicated LANs with
an ATM Campus Backbone Supporting ELANs
The first phase of support for virtual classrooms utilizes LANs dedicated to virtual classroom communications interconnected by an
ATM campus backbone (Figure 3-1).
This configuration is attractive to customers who build remote classrooms exclusively for this purpose on a campus. Since the
LANs are dedicated, they carry only virtual
classroom traffic. Configurations in this phase
support voice and video traffic traveling from
the studio to the remote classrooms, but only
us
camp
ATM ne LAN
o
b
back
Dedi
cated
LAN
cated
Dedi
d LAN
io
Stud
cate
Dedi
LAN
•••
te
Remo
•••
class
room
m
ssroo
te cla
Remo
Figure 3-1. Dedicated Edge LANs Connected by
ATM Campus Backbone LAN
voice is returned in the opposite direction.
This eliminates complexities arising from providing and controlling video streams in both
directions.
To ensure an appropriate level of service,
overprovisioned edge LANs are required. Sufficient reserved virtual circuit (VC) bandwidth
is required to guarantee uncongested traffic
flows between the edge LANs. To eliminate
certain control problems, we assume there are
only a small number of edge LANs.
The following technologies are required
to implement this configuration:
• Media encoding. The studio must contain
video/audio encoding equipment, for example, that producing MPEG-1 streams. For
the return audio channels, a proprietary
scheme, such as CUSeeMe is used, or the
return audio may come out-of-band, for
example through PBX or H.323 equipment.
• Layer 2 multicast. Delivery of the outbound (i.e., studio to remote classroom)
video data uses Layer 2 multicast in the
edge LANs. A common emulated LAN
(ELAN) is used to interconnect the edge
LANs with the studio LAN for each session.
If sufficient bandwidth is available in the
edge LANs and ATM backbone, multiple
virtual classroom sessions can be supported
by using different ELANs for each session.
However, restrictions in ATM switching
equipment may limit the number of ELANs
available at any one time.
Optionally, to increase performance,
the ATM backbone may support Layer 2
multicast.
• ATM access devices. The access device
between the ATM network and an edge
LAN must support the specification of
bandwidth, delay, and jitter requirements
for ATM ELANs. This requirement ensures
the appropriate level of service for emulated
Layer 2 multicasting.
• Audio bridge. To mix the outbound and
return audio traffic, the studio must have an
audio bridge. This could be a digital or analog device.
• Resilient ATM switch fabric and hot-swappable LRUs. To provide the reliability necessary for virtual classrooms, the ATM
switch fabric must tolerate single failures of
switches and communication channels.
Edge LANs should use switches with hotswappable LRUs so field personnel can provide quick, online repair of devices.
Phase 2: Larger Number of Dedicated LANs with
a Packet Switched Backbone
The second phase eliminates the requirement
for a campus ATM backbone supporting
ELANs with QoS/CoS provisioning and
replaces it with a campus packet switched
backbone (Figure 3-2 on page 20). The edge
LANs are still dedicated and overprovisioned,
but no longer need be small in number. The
multimedia protocol is H.323.
This configuration is attractive, since
many educational institutions already have
19
cket
us pa
e
Camp backbon
ed
h
c
t
i
sw
cated
AN
ted L
Dedi
ca
Dedi
io
Stud
Dedi
cated
LAN
LAN
•••
sroom
e clas
t
Remo
•••
m
ssroo
te cla
Remo
Figure 3-2. Dedicated Edge LANs Connected by a Campus Packet Switched Backbone
packet switched backbones. Furthermore,
since the convergence protocol is IP, packet
switching is a better match for the traffic generated by virtual classrooms than ATM.
The following additional technologies are
required to support this configuration:
• Prioritization of LAN traffic. The campus
backbone must support 802.1p/Q tagging
and prioritization, so virtual classroom traffic receives the necessary level of service.
The dedicated LANs need not support
802.1p/Q, since they are overprovisioned.
The campus backbone access devices connecting to the edge networks must participate in the packet tagging activity, however.
• RSVP and RSVP proxy. The campus backbone must support RSVP so resources can
be reserved to ensure high-priority handling
of virtual classroom traffic. Since RSVP is
not currently supported on many end systems, an RSVP proxy may be required to
create an RSVP tunnel through the campus
backbone.
• H.323 client on end system. In order for
remote PCs to receive the H.323 broadcast
video, they must have an H.323 client.
• H.323 gatekeeper. Since the number of
edge LANs is no longer small in this configuration, the video-conferencing services must
support a higher level of control. H.323
provides the necessary encoding and transport services. An H.323 gatekeeper provides
the necessary voice/video call management
services.
20
• MCU. An MCU allows remote classrooms/
end systems to coordinate their traffic with
studio traffic and with the traffic of other
remote classrooms/end systems.
• Resilient links in campus backbone. The
ATM backbone in phase 1 provides a resilient fabric. The packet switched backbone
that replaces it must provide similar reliability, which resilient links and hot-swappable
LRUs (from phase 1) provide.
• Efficient multicast routing and filtering at
Layer 3. Distribution of the video and
audio content from the studio to remote
classrooms requires Layer 3 (e.g., IP) multicast services. Routers in the campus backbone must support the Distance Vector
Multicast Routing Protocol (DVMRP),
which is the least common denominator
multicast routing protocol.
Phase 3: Multi-Application LANs with a
Packet Switched Backbone and Supporting
Video Return
A further generalization of the configurations
in previous phases connects remote classrooms
and studios to multi-application LANs (Figure
3-3). Shared networking capabilities allow
each LAN to support more than one studio or
remote classroom. This flexibility introduces a
requirement for QoS/CoS support in the edge
LANs. (Some of the features for this support
are introduced in phase 2 for the core packet
switched backbone and are therefore not
repeated here.)
An interesting capability enabled by
QoS/CoS support in edge LANs is video
return. Thus, each remote classroom can
return to the studio video that is mixed with
the outbound video (e.g., Picture in Picture
display). This would be useful for displaying a
student that asks or answers a question as well
as periodic or random monitoring of student
attendance/body language.
An implied generalization in this phase is
an increased number of multi-application and
studio LANs. Thus, accommodating scale
becomes an issue. Since the edge LANs now
support many applications, end systems must
support QoS/CoS signaling to the network in
order to obtain the services necessary to support real-time video and audio. The confluence
of large-scale and QoS/CoS support introduces
a QoS/CoS policy management requirement
to allow network administrators to control
scarce networking resources according to established institutional policies.
The following additional technologies are
required to support this configuration:
• QoS/CoS in end systems. End systems must
support application-based packet classification and either 802.1p/Q tagging, RSVP, or
IP ToS tagging. This allows them to signal
their packet-handling requirements to the
network, which is necessary when LANs
carry traffic other than real-time video and
audio.
• Policy management of traffic prioritization.
Scaling concerns require network administrators to deal with high-level, business-
•
•
•
•
oriented issues rather than with device-level
commands and configuration data.
Bulk configuration of network devices.
Scaling also introduces device management
issues that require configuration of devices
on an aggregated basis. When a site has
thousands of network devices, each with a
large number of optional or configurable
features, point device management is no
longer effective. Network administrators
require the capability to manage devices
in groups based on their location and capabilities.
Multicast distribution management and
troubleshooting. Support of a large number
of edge LANs introduces scaling considerations for multicast. In order to effectively
address this issue, the converged network
must support effective multicast distribution management and troubleshooting.
Fast, convergent routing. When failures
occur in a large network, the routing protocol must react quickly to restore connectivity. Routing protocols such as RIP do not
have this characteristic, while OSPF does.
Consequently, networks supporting virtual
classrooms should use OSPF.
Rapid, coordinated fault recovery. When
parts of a large-scale converged network fail,
manual methods of recovery are expensive
and time-consuming. For virtual classroom
support, converged networks must provide
••
cket
us pa
e
Camp backbon
hed
c
t
i
w
s
-appl
Multi
Remo
on L
licati
ti-app
ic
Mul
N
on LA
Stud
ati
pplic
ulti-a
io
•••
M
sroom
e clas
t
Remo
•••
tudio
S
te
Remo
class
m
ssroo
te cla
AN
LAN
ation
•
room
Figure 3-3. Multi-Application Edge and Studio LANs Connected by a Campus Packet Switched Backbone
21
te cla
Remo
m
ssroo
•••
m
ssroo
e cla
t
Remo
•••
io
Stud
AN
L
ation
pplic
ulti-a
M
-appl
Multi
io
AN
tion L
tion
plica
Stud
LAN
-ap
ica
Multi
cket
us pa
e
Camp backbon
ed
h
c
t
i
sw
••
•
m
ssroo
te cla
Remo
WAN
••
cket
us pa
e
Camp backbon
d
e
h
c
t
swi
-appl
Multi
n LAN
tio
plica
lti-ap
n LAN
icatio
•
sroom
e clas
t
Remo
Mu
N
on LA
ti
plica
Stud
-ap
Multi
io
•••
te
Remo
•••
Stud
io
om
assro
te cl
Remo
Figure 3-4. Multiple Campuses Interconnected by
a Public WAN
rapid, coordinated, and automated network
fault recovery.
Phase 4: Multiple Campuses Interconnected
by a WAN
In phase 4, multiple campuses are interconnected over a WAN (Figure 3-4). Since much
of the traffic of a virtual classroom will be
multicast, reliable multicast services are
important. In addition, most WANs do not
support multicast, so this traffic must be tunneled. One limitation in this phase is that all
22
room
class
campus networks are
managed as a single administrative domain. This limitation is
removed in the next phase.
This phase supports more sophisticated
interactions between teacher and students,
such as use of a shared whiteboard. Since the
security of communications over a WAN may
be less than that required for educational services requiring payment, this phase also introduces security technology for protecting
communications over the WAN. In addition,
cost recovery for educational content moved
across a WAN requires the provision of
accounting services.
The following additional technologies are
required to support this phase:
• WAN QoS/CoS/ToS support. Moving virtual classroom traffic across the WAN
•
•
•
•
•
•
imposes bandwidth, delay, and jitter requirements on WAN services. An ATM-based
WAN has underlying resource reservation
mechanisms and signaling capabilities on
VC interfaces for QoS. Current Frame
Relay–based WANs do not support QoS/
CoS controls, so using them for virtual
classroom support requires this enhancement. Pure packet-based networks require
something like RSVP tunneling for WAN
QoS/CoS support.
DVMRP tunneling in WANs or Internet
Group Management Protocol (IGMP)
proxying. Current WANs do not support
multicast and such support is unlikely in
the near future. One way to solve this problem is to tunnel multicast traffic across the
WAN using mechanisms such as a DVMRP
tunnel. Another approach is to use a broadcast WAN service, such as that available in
satellite networks, and have the router at the
uplink point act as an IGMP proxy.
Policy-based WAN selection. Since video
classroom traffic will coexist with other traffic moved over the WAN between edge
LANs, there must be a way to select the
appropriate WAN services for each.
T.120 support. Using whiteboards requires
point-to-multipoint services, which are supported by T.120. A T.120 MCU is useful in
coordinating multiple users drawing on the
same whiteboard. T.120 can also support
remote camera control, which provides a
standard way of synchronizing remote video
return data.
IPsec. Traffic over a public WAN is inherently unsecure. Since virtual classrooms are
likely to be a costed service, they must be
protected by a security protocol providing
confidentiality, integrity, and authentication
services. IPsec is the standard protocol for
these services.
Cryptographic policy management. Managing IPsec is an arduous task unless there is
some help in the form of cryptographic policy management. This is required in any
practical, large-scale deployment of IPsec.
Security policy management. Interconnecting campuses with a WAN introduces problems of network and end system access
control. To control the security threats this
introduces, sites supporting cross-WAN virtual classrooms will require security policy
management systems, such as the Multilayer
Firewall and Network Login, which protect
sites against security threats mounted from
remote edge LANs.
• Accounting. Virtual classrooms will be used
for a variety of purposes, but pay-per-view
educational seminars and talks will form a
significant percentage of broadcast content.
To properly charge for these sessions requires
some sort of accounting technology.
Phase 5: Multiple Campuses and Remote Home
Sites Interconnected by a WAN
The last generalization discussed here supports
home access to the virtual classroom over
regional access networks forwarding traffic
through a WAN (Figure 3-5 on page 24). The
addition of home access raises a number of
technology issues. For example, there must be
sufficient bandwidth to the home to deliver
video and audio content as well as optionally
permit video return. Remote access equipment
servicing the access network customers must
support multicast or convert multicast into
point-to-multipoint traffic.
In this phase, multiple administrative
domains become an issue, since customers are
unlikely to allow administration of their computing resources by an educational institution.
Furthermore, a home may use the services of
multiple educational offerings, which would
preclude management by any one institution.
Also, the access networks are managed by the
carrier, not by either the educational institution or the home. Since this phase supports
multiple administrative domains, it allows the
management of multiple campus backbones
by more than one administration.
When campuses and homes are interconnected, the amount of service-sensitive traffic
moving over the converged network is likely
to increase substantially, and reliability of the
network becomes a much more serious issue.
Proactive approaches to ensuring network reliability become attractive in this phase. The
reliability of a WAN is generally much less
23
Remo
te cla
m
ssroo
•••
m
ssroo
e cla
t
Remo
•••
Stud
AN
io
on L
licati
-app
Multi
licati
-app
Multi
••
on LA
N
Multi
n
catio
appli
Stud
LAN
io
-
cket
us pa
e
Camp backbon
hed
c
t
i
w
s
•
ss
Acce
ork
netw
es
Hom
tuden
ts
m
ssroo
te cla
Remo
work
net
WAN
dents
e stu
Hom
twork
ss ne
Acce
••
cket
us pa
e
Camp backbon
ed
h
c
t
i
sw
ppl
ulti-a
icatio
n LAN
Multi
•
m
ssroo
te cla
Remo
n LAN
catio
appli
-
M
i
-appl
Multi
io
Stud
n LAN
catio
•••
oom
te
Remo
•••
te cla
Remo
io
Stud
m
ssroo
Figure 3-5. Multiple Campuses Interconnected by
a Public WAN with Home Student Access
than that of a typical LAN, so improvement
in this area is also critical.
The following additional technologies are
required to support this phase:
• Reliable multicast. To assist in the synchronization of whiteboard modifications so that
teacher and students see the same shared
information, this phase supports reliable
multicast. Such service is especially important when whiteboard traffic moves across
the WAN.
24
r
class
• High bandwidth to the
home. Virtual classroom to the
home requires the provision of high-bandwidth services. This means that access networks such as cable and xDSL facilities
must exist and that the core WAN must
support high-bandwidth service to a large
number of homes.
• Multicast support in remote access equipment. In order for homes to participate in
virtual classroom sessions, which are distributed as multicast streams, the remote access
equipment must support multicast and
either pass the multicast traffic on to the
home system or convert it to point-to-multipoint traffic.
• IGMP over PPP. In order for home systems
to join a multicast session, they must send
•
•
•
•
an IGMP message to their nearest multicastcapable router. Since home systems will generally connect to the access networks by PPP,
network equipment must support IGMP
over PPP.
Video/audio transcoding of virtual classroom content. It is unlikely that studio services will supply virtual classroom video and
audio data in the same format as all end systems are capable of handling. To accommodate this, video and audio transcoders must
run on gateways in the network to perform
the necessary conversions.
IP differentiated services. Since the Internet
will be the WAN in many cases in this
phase, it must support multicast service as
well as some service quality mechanism,
such as IP ToS tagging. This requires the
development of the necessary technology
and the adoption and deployment of that
technology by the ISPs.
QoS/CoS support across multiple administrative domains. In the previous phase, all
networks were under the control of a single
administrative domain. This phase requires
the coordination of QoS/CoS services provided by multiple administrative domains.
Not only must interfacing equipment
understand and implement the QoS/CoS
policies of the domains they interconnect,
managing the cross-administrative domain
QoS/CoS services requires the development
and deployment of a federated policy management system.
Predictive network failure tools. To ensure
a high-reliability network service for virtual
classrooms, it is useful to support technologies such as predictive network failure tools.
Case 4: Converged Network Support for
Toll Reduction
A significant shift in telephony service is on
the horizon. Toll traffic that currently travels
over circuit switched networks will be diverted
over packet-based WANs, thereby reducing
long-distance service costs. This reduction is
possible due to economies of scale that are driving down the cost of packet switching equipment in relation to the cost of circuit switched
devices. For the purposes of this case study, we
use the term toll reduction to describe the
diversion of toll traffic over packet-based
WANs.
The advantages of toll reduction are both
economic and technical. From an economic
perspective, customers receive long-distance
service at lower cost. Competitive pressure on
voice service carriers by data service carriers
will force voice carriers to offer toll reduction
services or risk a significant loss of market
share.
Toll reduction will initially be transparent
to customers, except for its reduced cost. In
later stages of toll reduction, carriers will take
advantage of the converged voice/data network to provide value-added services. For
example, in cooperation with local PSTN service providers, carriers might offer accounting
and billing information to customers over the
Web. They might provide e-mail arrival notification using LEDs or displays on packet voice
handsets. They could provide online white
and yellow pages services. They could provide
more advanced call management services, such
as displaying the phone number of an interrupting call when customers subscribe to call
waiting.
Toll reduction requires voice packetization, which will occur in carrier equipment
connected to the local PSTN. Prior to the
movement of packet voice traffic across the
WAN, the remote termination point for the
packet voice traffic is located. This is accomplished by translating the destination phone
number into an IP address, which identifies
the equipment that will convert the packet
voice into analog form and forward it over the
remote PSTN to the call’s destination. Once
call setup is achieved, the packet voice data is
routed over the intervening WAN, thereby
bypassing the long-distance circuit switched
network.
One advantage carriers enjoy is their
access to the voice circuit switched network. If
the load on their WAN network reaches a
level at which toll service quality becomes
degraded, the carrier can route the call over
the circuit switched network; this is called
backhauling. This allows carriers to manage
25
destination H.323 gateway will then place a
call over the remote PSTN to the destination
(Figure 4-1).
To utilize toll reduction, the customer
dials the H.323 gateway, enters a PIN or other
authentication information to establish his
identity (for authorization and accounting
purposes), and then enters the destination
phone number. The gateway translates the
phone number into the appropriate IP address
and establishes an H.323 session with the
H.323 gateway at that address. The remote
equipment then calls the destination phone
through the local PSTN, thereby establishing
the necessary local circuit switched connection.
Once the call is established, the local
H.323 gateway packetizes the voice traffic and
routes it over the WAN. At the remote gateway the packet voice is decoded and sent over
their capital expenses by growing the WAN
packet network incrementally over time.
Toll reduction is predicated on the capability of WANs to deliver acceptable bandwidth, delay, and jitter characteristics. Most
carriers have extensive experience in capacity
planning and understand their load models
well enough to overprovision their WAN service. In future offerings, packetized voice may
be carried directly from enterprises over direct
links to the WAN and from small/medium
businesses and home premises over broadband
services such as cable modem and xDSL.
Access network providers and enterprise network administrators are not as experienced in
provisioning their data networks to provide
acceptable voice quality. For these providers,
additional access network enhancements may
be necessary for toll-grade service.
Phase 1: Toll Reduction over Existing PSTN
In the first phase of toll reduction, carriers will
intercept toll traffic at an H.323 gateway connected to a local PSTN and move this traffic
over a packet switched WAN, delivering it to
an H.323 gateway near the calling party. The
eway
3 gat
H.32
PSTN
WAN
eway
3 gat
H.32
PSTN
Figure 4-1. Toll Reduction over Existing PSTN Services
26
Carri
er
the PSTN as normal voice data. The remote
end may decode the packet voice into analog
or digital form, using whatever codec standard
is appropriate for the local PSTN.
The following technologies are required
to implement this configuration:
• H.323 gateway. Both the local and remote
PSTN connection points must have an
H.323 gateway that accepts packet voice
data and decodes it into voice traffic suitable for sending and receiving over a PSTN.
The gateway must provide authentication
and accounting services, perhaps by interacting with other services connected to it
either locally or through the WAN. In this
phase, the H.323 gateway will support a
limited number of codecs, such as G.723.
Finally, the gateway must connect to the
PSTN through span lines of sufficient capacity, such as E1/T1, to handle a significant
amount of traffic.
• Directory server. The H.323 gateway must
translate the destination phone number provided by the customer into the IP address of
the remote gateway. This service is provided
by a phone directory server. In this phase, a
proprietary protocol is used for the interactions between the gateway and directory
server.
• Interactive voice response (IVR). In order
to service the customer’s call request, an
IVR system is required to guide the caller
through the appropriate steps (enter PIN,
enter destination phone number, etc.).
Phase 2: Toll Reduction with Redundancy and
Sophisticated Call Management
The next phase of toll reduction adds more
sophisticated call management facilities and
significant redundancy (Figure 4-2 on page 28).
Load management of the WAN benefits
from technology added in phase 2. To protect
the WAN from becoming congested, an
H.323 gatekeeper is added that manages calls
established through the H.323 gateways to
ensure that sufficient WAN resources are
available to service them. If the WAN is overloaded, the gatekeeper can communicate with
an SS7 gateway, rerouting the call to another
H.323 gateway or over circuit switched long-
distance equipment. Finally, Lightweight
Directory Access Protocol (LDAP), a standard
X.500 directory services access protocol, is
used to communicate with phone directory,
authentication, and accounting servers external to the H.323 gateway. In this phase, the
LDAP schemas are proprietary.
Significant redundancy is also added in
this phase with fully redundant H.323 gateways and gatekeepers and redundant SS7
gateways. The local and remote H.323 gateways are supported by a full complement of
gatekeepers, SS7 gateways, and phone directory, authentication, and accounting servers.
The following additional technologies are
required to support this phase:
• H.323 gatekeeper. A fully redundant
H.323 gatekeeper provides basic call management functions for routing calls coming
through an H.323 gateway.
• SS7 integration with H.323. When a call
request arrives at an H.323 gatekeeper that
needs to be rerouted to another gateway, the
gatekeeper signals an SS7 gateway, which
passes on the rerouting information to the
PSTN using the ISDN User Part (ISUP)
protocol.
• Accounting. In order to recover costs associated with toll reduction calls the carrier must
support a billing and accounting service. Two
additional servers are required: an authentication server and an accounting server. Both
utilize existing carrier functionality by interfacing to them through an Open Database
Connectivity (ODBC) interface.
• H.323 gatekeeper coordination. As toll
reduction becomes pervasive, carriers will
deploy multiple fully redundant H.323
gatekeepers, which will coordinate with
those in other parts of the carrier network.
This requires a gatekeeper-to-gatekeeper
protocol supporting basic functionality.
• Improved H.323 gateway. The deployment
of toll reduction access through cable modem
and xDSL access networks is likely to stress
existing H.323 gateway implementations.
Handling the increased load requires a more
robust gateway, supporting a larger number
of ports and providing greater reliability
than the gateway deployed in phase 1.
27
t
ndan
Redu epers
e
gatek
t
ndan
Redu teways
a
3g
H.32
n,
zatio
thori vers
u
a
,
ser
tory
Direc ccounting
and a
PSTN
eway
at
SS7 g
on,
rizati
utho ervers
a
,
y
r
s
to
Direc ccounting
and a
WAN
y
tewa
a
SS7 g
PSTN
t
ndan
Redu teways
3 ga
H.32
t
ndan
Redu epers
e
k
e
gat
er
Carri
Figure 4-2. Toll reduction with Sophisticated Call
Management and Redundancy
• Fax over IP. Traditional long-distance service allows customers to fax information
between local and remote points. Since fax
data is digital in nature, efficiencies are possible if fax analog data are converted to digital form when moved over the toll reduction
WAN.
• Resilient links and hot-swappable LRUs.
Not only must the H.323 gateway be reliable, the underlying communications fabric
must be reliable as well. This requires resilient links and LRUs. When links fail, backup
links must automatically take over the new
load. Resilient links provide this capability.
When network devices experience failures in
their components, the smallest replaceable
part that contains the failed component (an
28
LRU) must be swapped out and a correctly
operating part swapped in. LRUs must be
hot-swappable; that is, the network device
should continue to operate while the LRU
is replaced.
Phase 3: Toll Reduction for Enterprise Networks,
Small/Medium Businesses, and Consumers
In the third phase, carriers provide toll reduction services to small and medium businesses,
enterprises, and consumers (Figure 4-3).
These customers directly access the toll
reduction WAN through cable modem and
xDSL access networks or through direct links
(such as T1 or analog modem). Access control
in H.323 gateways handling inbound calls
from direct links and access networks (not
shown in the figure) protect the toll reduction
WAN from becoming congested by this direct
access traffic.
The following additional technologies are
required to support this phase:
• Broadband access. A cable modem transmission system (CMTS) allows both digital
data and traditional analog cable channels
m
Mode
er
Carri
t
ndan
Redu epers
e
gatek
t
ndan
Redu teways
3 ga
H.32
tion,
oriza rs
h
t
u
a
serve
tory,
Direc ccounting
and a
PSTN
m
Mode r xDSL
o
tion,
oriza rs
h
t
u
a
serve
tory,
Direc ccounting
and a
WAN
SS7
ay
gatew
y
tewa
a
SS7 g
m
Mode L
S
D
x
r
o
•
PSTN
t
ndan
Redu teways
a
g
3
H.32
t
ndan
Redu epers
e
gatek
••
prise
Enter
•••
ased
PC-b one
h
p
e
l
te
Figure 4-3. Toll Reduction Services for Enterprise Networks, Small/Medium Businesses, and Consumers
to coexist in the same system. Similarly, a
digital subscriber loop access multiplexer
(DSLAM) in a PSTN central office separates voice and data, allowing data to be
routed over a packet network, thus relieving
stress on the circuit switched network.
• Header compression. To ensure efficiencies
when voice and data are moved simultaneously over the same access network link,
voice traffic is compressed. Header compression complements voice data compression
in the voice traffic data, making voice pack-
ets compact. This is particularly important
for low-speed lines.
• IPsec. As toll reduction expands from an
exclusively carrier-based service to the small/
medium enterprise and mass market, the
security of voice traffic over the data network
will become an issue. This will require the
confidentiality and integrity services provided by IPsec.
• Cryptographic policy management. Managing IPsec is an arduous task unless there is
some help in the form of cryptographic
29
LAN
•
•
•
•
•
30
policy management. This is required in any
practical, large-scale deployment of IPsec.
IP differentiated services. Support of tollgrade voice service over cable modems,
xDSL, and analog modems requires prioritized handling of packet voice data, which
will require IP differentiated services in
those networks. Current work in the IETF
is investigating use of the Type of Service
(ToS) field in IP headers to tag traffic
according to its urgency, as well as resource
reservation by means of the Resource Reservation Protocol (RSVP). RSVP is a signaling protocol used for reservation, and ToS
bits indicate a desired priority. To implement this priority, there must be mechanisms in Layer 3 switches and routers such
as packet scheduling algorithms in routers
or 802.1p–compliant priority queuing
mechanisms in switches.
Policy management of traffic prioritization. Scaling concerns require network
administrators to deal with high-level business-oriented issues rather than with devicelevel commands and configuration data.
Carriers supporting toll reduction must
manage their QoS/CoS resources carefully
in order to achieve the efficiencies required
in a competitive environment. Policy management is the tool that provides the necessary level of control.
H.323 client on end system. In order for
toll reduction service to extend to the home,
PCs and IP-capable handsets must support
an H.323 client.
H.323 gatekeeper support for bandwidth
control. Toll-quality voice requires gatekeeper functionality that admits and routes
calls based on network load. This requires
interaction between the H.323 gateway and
network management systems.
Enhanced gatekeeper-to-gatekeeper interactions. Basic gatekeeper functionality provides for call handoff on a per-call basis. In
a large-scale deployment of toll reduction,
more sophisticated interactions are necessary.
For example, there may be a requirement
for load balancing or fail-over between gateways in different parts of a carrier’s network.
• Enhanced SS7 support. When calls originate in PCs or IP-capable handsets, the SS7
gateway used to route the outgoing call over
the PSTN must translate certain destinations (such as 800 numbers) using the
Transaction Capabilities Application Part
(TCAP) protocol.
• Capacity planning and better monitoring
tools. To ensure that toll reduction traffic
receives adequate service, WAN and access
network capacity must be sufficient to support it. Thus, capacity planning is an
important activity. Since converged networks are much more complex than existing, data-only networks, better simulation
and analysis tools are necessary. In addition,
better monitoring tools are required to provide the data necessary for simulations and
analysis.
• Home LANs. The provision of toll reduction will stimulate the home LAN market.
Multiple handsets/PCs in the home supporting packet voice will allow multiple,
simultaneous, outbound calls if there is a
home LAN to move the packet voice traffic
from the handsets to the access network
connection point.
• Home LAN QoS/CoS support. To ensure
that voice traffic transiting the home LAN
receives the appropriate level of service,
home LANs must support an appropriate
level of QoS/CoS. Since proposed home
LAN technologies are unswitched, MAC
access layer control algorithms for home
LANs must support QoS/CoS objectives.
• ISSLL-LOW. When toll reduction traffic
moves over analog modems, voice and data
traffic will share a common link. This
requires the use of a link traffic prioritization scheme to ensure voice traffic has
precedence over data traffic. The ISSLLLOW standard defines such a scheme.
• QoS/CoS in end systems. End systems must
support application-based packet classification and RSVP or IP ToS tagging. This allows
them to signal their packet handling
requirements to the carrier and access networks.
Phase 4: Toll Reduction with Advanced Services
and Standardization
As toll reduction services become common,
carriers will begin offering advanced services
to differentiate themselves from their competitors (Figure 4-4). They will offer multi-conferencing services based on IP multicasting and
provide advanced telephony features such as
call waiting and call forwarding. They will
interoperate with one another, which requires
settlement services to account for call
costs. Carriers will implement leastcost routing functions in their
WAN networks to locate the best H.323 gateway for a call or to determine when to backhaul traffic. These routing protocols will use
load, price, and congestion (among other factors) as input to their routing metrics. To
serve customers who connect to the toll reduction WAN through cable modem and xDSL,
carriers will support data created by highfidelity codecs at these customers’ premises.
In addition to these advanced services,
carriers will move away from proprietary
protocols for toll reduction and
move toward international
m
Mode
er
Carri
t
ndan
Redu epers
e
k
gate
t
ndan
Redu teways
a
g
.323
H
on,
rizati
utho ervers
a
,
y
r
s
to
Direc ccounting
and a
PSTN
m
Mode r xDSL
o
on,
rizati
utho ervers
a
,
y
r
s
to
Direc ccounting
and a
WAN
SS7
ay
a
g tew
ay
atew
SS7 g
m
Mode L
S
D
x
or
t
ndan
Redu teways
a
3g
H.32
PSTN
t
ndan
Redu epers
e
gatek
Soft
POTS
prise
Enter
LAN
•••
Figure 4-4. Toll Reduction with Advanced Services and Standardization
31
e
phon
d tele
ase
PC-b
PBX
standards, which should emerge during this
phase. They will migrate to a standard, fullfeatured, gatekeeper-to-gatekeeper protocol,
utilize standardized LDAP directory service
schemas, and install and use standardized
QoS/CoS services in their WAN networks.
The following additional technologies are
required to support this phase:
• Soft PBX. The origination of multiple outbound calls from an enterprise, small/
medium business, or home does not require
additional equipment. Supporting multiple
inbound calls is possible as well, but such
service requires a soft PBX. This can be provided either by access network head-end
equipment, by the carrier, or by equipment
sited within a customer’s premises. The soft
PBX will also handle calls traversing
premises POTS service.
• MCU. Multiconferencing support requires
an MCU, which coordinates separate voice
streams by multiplexing them into a single
aggregated flow. An appropriate MCU is
provided in the T.120 standard.
• Efficient multicast routing and filtering.
To implement multiconferencing, toll
reduction WANs and access networks must
support efficient multicast routing and filtering. This increases their efficiency when
handling multiconferencing traffic.
• Multicast distribution management and
troubleshooting. Support of an arbitrary
number of multiconferencing participants
introduces scaling considerations for multicast. In order to effectively address this
issue, toll reduction must support effective
multicast distribution management and
troubleshooting.
• Standardized LDAP schemas. To maintain
efficiencies, carriers will standardize the
LDAP schemas that are used to manage
32
•
•
•
•
phone directory, authentication, and
accounting services.
Advanced telephony services. Carriers will
implement such advanced telephony services as call waiting and call forwarding for
their toll reduction offerings.
Least-cost routing. To institute efficiencies
necessary to meet increasing competition in
the toll reduction market, carriers will design
and implement least-cost routing mechanisms, which take into account load, price,
and congestion when formulating routes.
Enhanced codecs support. As more customers use high-bandwidth access services
directly connected to the toll reduction
WAN, they will increase the fidelity of their
voice service by employing more advanced
audio codecs. Carriers will improve their
toll reduction services to support this class
of traffic.
Settlement services. Interexchange carriers
will offer settlement services to their carrier
customers so that calls can transit multiple
carrier networks.
Conclusion
The case studies presented in this paper offer a
suggestion of the wide range of applications
and business environments that will benefit
from network convergence in the coming
years. But in order to realize the benefits of
convergence—cost savings, improved network
control, increased flexibility and functionality—new capabilities are required in the network infrastructures. A phased deployment
can deliver benefits at each incremental step.
Whether or not an organization’s immediate
plans include convergence, today’s infrastructure investment should include features and
capabilities that position the network to support these applications in the future.
3Com Corporation
P.O. Box 58145
5400 Bayfront Plaza
Santa Clara, CA
95052-8145
Phone: 1 800 NET 3Com
or 1 408 326 5000
Fax: 1 408 326 5001
World Wide Web:
www.3com.com
Asia Pacific Rim
Sydney, Australia
Phone: 61 2 9937 5000
Fax: 61 2 9956 6247
Melbourne, Australia
Phone: 61 3 9866 8022
Fax: 61 3 9866 8219
Beijing, China
Phone: 86 10 68492 568
Fax: 86 10 68492 789
Shanghai, China
Phone: 86 21 6350 1581
Fax: 86 21 6350 1531
Hong Kong
Phone: 852 2501 1111
Fax: 852 2537 1149
India
Phone: 91 11 644 3974
Fax: 91 11 623 3192
Indonesia
Phone: 62 21 572 2088
Fax: 62 21 572 2089
Osaka, Japan
Phone: 81 6 536 3303
Fax: 81 6 536 3304
Tokyo, Japan
Phone: 81 3 3345 7251
Fax: 81 3 3345 7261
Korea
Phone: 82 2 3455 6300
Fax: 82 2 319 4710
Malaysia
Phone: 60 3 715 1333
Fax: 60 3 715 2333
New Zealand
Phone: 64 9 366 9138
Fax: 64 9 366 9139
Philippines
Phone: 632 892 4476
Fax: 632 811 5493
Singapore
Phone: 65 538 9368
Fax: 65 538 9369
Taiwan
Phone: 886 2 2 377 5850
Fax: 886 2 2 377 5860
Thailand
Phone: 662 231 8151 5
Fax: 662 231 8158
Poland
Phone: 48 22 6451351
Fax: 48 22 6451352
Russia
Phone: 7 095 258 09 40
Fax: 7 095 258 09 41
Peru
Phone: 51 1 221 5399
Fax: 51 1 221 5499
Venezuela
Phone: 58 2 953 8122
Fax: 58 2 953 9686
3Com Austria
Phone: 43 1 580 17 0
Fax: 43 1 580 17 20
3Com France
Phone: 33 1 69 86 68 00
Fax: 33 1 69 07 11 54
Carrier and Client Access
Phone: 33 1 41 97 46 00
Fax: 33 1 49 07 03 43
3Com Benelux B.V.
Belgium
Phone: 32 2 725 0202
Fax: 32 2 720 1211
Netherlands
Phone: 31 346 58 62 11
Fax: 31 346 58 62 22
3Com GmbH
Berlin, Germany
Phone: 49 30 3498790
Fax: 49 30 34987999
Munich, Germany
Phone: 49 89 627320
Fax: 49 89 62732233
3Com Mediterraneo
Milan, Italy
Phone: 39 2 253011
Fax: 39 2 27304244
Rome, Italy
Phone: 39 6 5279941
Fax: 39 6 52799423
3Com Canada
Calgary
Phone: 1 403 265 3266
Fax: 1 403 265 3268
Edmonton
Phone: 1 403 423 3266
Fax: 1 403 423 2368
Montreal
Phone: 1 514 683 3266
Fax: 1 514 683 5122
Ottawa
Phone: 1 613 566 7055
Fax: 1 613 233 9527
Toronto
Phone: 1 416 498 3266
Fax: 1 416 498 1262
Vancouver
Phone: 1 604 434 3266
Fax: 1 604 434 3264
3Com Iberia
Portugal
Phone: 351 1 3404505
Fax: 351 1 3404575
Spain
Phone: 34 1 509 69 00
Fax: 34 1 307 79 82
3Com Eastern Europe/CIS
Bulgaria
Phone: 359 2 962 5222
Fax: 359 2 962 4322
Czech/Slovak Republics
Phone: 420 2 21845 800
Fax: 420 2 21845 811
Hungary
Phone: 36 1 250 8341
Fax: 36 1 250 8347
3Com Latin America
U.S. Headquarters
Phone: 1 408 326 2093
Fax: 1 408 764 5730
Miami, Florida
Phone: 1 305 261 3266
Fax: 1 305 261 4901
Argentina
Phone: 54 1 312 3266
Fax: 54 1 314 3329
Brazil
Phone: 55 11 246 5001
Fax: 55 11 246 3444
Chile (also serving Bolivia and
Peru)
Phone: 56 2 633 9242
Fax: 56 2 633 8935
Colombia
Phone: 57 1 629 4847
Fax: 57 1 629 4503
Mexico
Phone:52 5 520 7841/ 7847
Fax: 52 5 520 7837
3Com Middle East
Phone: 971 4 319533
Fax: 971 4 316766
3Com Nordic AB
Denmark
Phone: 45 48 10 50 00
Fax: 45 48 10 50 50
Finland
Phone: 358 9 435 420 67
Fax: 358 9 455 51 66
Norway
Phone: 47 22 58 47 00
Fax: 47 22 58 47 01
Sweden
Phone: 46 8 587 05 600
Fax: 46 8 587 05 601
3Com Southern Africa
Phone: 27 11 807 4397
Fax: 27 11 803 7405
3Com Switzerland
Phone: 41 844 833 933
Fax: 41 844 833 934
3Com UK Ltd.
Edinburgh
Phone: 44 131 240 2900
Fax: 44 131 240 2903
Ireland
Phone: 353 1 820 7077
Fax: 353 1 820 7101
Manchester
Phone: 44 161 873 7717
Fax: 44 161 873 8053
Marlow
Phone: 44 1628 897000
Fax: 44 1628 897003
To learn more about 3Com products and services, visit our World Wide Web site at www.3com.com. 3Com is a publicly traded corporation (Nasdaq: COMS).
© 1998 3Com Corporation. All rights reserved. 3Com is a registered trademark of 3Com Corporation or its subsidiaries. AppleTalk is a trademark of Apple Computer. IPX is a trademark of Novell. PointCast
is a trademark of PointCast. SAP is a trademark of SAP AG. Other brand and product names may be trademarks or registered trademarks of their respective owners. All specifications are subject to change
without notice.
Printed in U.S.A. on recycled paper
500671-002 7/98