T e c h n i c a l

P a p e r

Converged Networks
Case Studies

Converged Networks
Case Studies Contents
Overview of Converged Networks What Is Driving Converged Networks? Cost Reduction Emerging Technologies Greater Flexibility and Functionality Standards Converged Network Architecture Case Studies Case 1: Converged Network Support for Call Centers Phase 1: Single Call Center on a Dedicated LAN Phase 2: Two Call Centers on Dedicated LANs, Interconnected by the PSTN Phase 3: Multiple Call Centers on Dedicated LANs, Interconnected by a WAN Phase 4: Multiple Call Centers on Dedicated LANs, Interconnected by a WAN, with Customer Access over the Internet Phase 5: Multiple Call Centers on Multi-Application LANs, Connected by a WAN, with Customer Access over the Internet Case 2: Converged Network Support for Financial Transaction Applications Phase 1: Data Only Phase 2: Voice and Data on Business-Critical Networks Phase 3: Voice, Video, and Data on Business-Critical Networks with Multiple Data Centers Case 3: Converged Network Support for the Virtual Classroom and Corporate Training Phase 1: Small Number of Dedicated LANs with an ATM Campus Backbone Supporting ELANs Phase 2: Larger Number of Dedicated LANs with a Packet Switched Backbone Phase 3: Multi-Application LANs with a Packet Switched Backbone and Supporting Video Return Phase 4: Multiple Campuses Interconnected by a WAN Phase 5: Multiple Campuses and Remote Home Sites Interconnected by a WAN Case 4: Converged Network Support for Toll Reduction Phase 1: Toll Reduction over Existing PSTN Phase 2: Toll Reduction with Redundancy and Sophisticated Call Management Phase 3: Toll Reduction for Enterprise Networks, Small/Medium Businesses, and Consumers Phase 4: Toll Reduction with Advanced Services and Standardization Conclusion 2 3 4 5 5 6 6 7 7 8 9 10 11 12 14 15 16 17 18 18 19 20 22 23 25 26 27 28 31 32

Acronyms and Abbreviations

ACD automated call distribution 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 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

Converged Networks
Case Studies

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.
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

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.
What Is Driving Converged Networks?

Acronyms and Abbreviations

ISP Internet service provider ISSLL Integrated Services over Specific Link Layers ISUP ISDN User Part ITU International Telecommunications Union 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

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.

Acronyms and Abbreviations

PSTN public switched telephone network QoS Quality of Service RIP Routing Information Protocol RMON Remote Monitoring RSVP Resource Reservation Protocol 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 xMDS Multipoint Distribution Service

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.
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

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 Polaroids 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. Were in the middle of a fundamental changethe 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.

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 Microsofts 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 industrys 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. Todays 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 VLANs 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.

dge LAN e rk o netw dge LAN e rk etwo n core WAN rk o netw

Converged Network Architecture

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 netw dge LAN e rk o netw

AN lel W Paral tworks ne core

Figure 2. Parallel WAN Core Networks

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, nontime-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, nontime-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 applications 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 callers 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. 518.

3 H.32

gatek

r eepe

s enter Call c

erver

PSTN mer Custo 3 gat H.32 eway

se base Data LAN

rver

Agen Agen t stat ion t stat ion

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

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 agents 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

r serve base Data

s enter Call c

erver

LAN

ekee 3 gat H.32

per

H.32

eway 3 gat

t Agen Agen ion t stat e Call c nter s erver statio n te Priva ink l

PSTN Custo mer Data s base

erver

LAN

H.32

3 gat

per ekee

H.32

eway 3 gat

Agen Agen t stat ion ion t stat

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).

H.32

per ekee 3 gat

rver ter se ll cen Ca

3 ga H.32

tekee

per

enter Call c

serve

LAN eway 3 gat H.32

ba Data

rver se se

LAN ver e ser

3 ga H.32

y tewa

t sta Agen t Agen statio n tion

bas Data

ion t stat Agen PSTN Agen t stat ion en Call c rver ter se Custo mers

PSTN

ekee 3 gat H.32 Custo mers

per

r serve enter Call c

WAN 3 H.32

gatek

r eepe

LAN 3 ga H.32 tewa y

ba Data

r se se

ver LAN r se se ver

ew 3 gat H.32

ay

ion t stat Agen t stat Agen ion

ba Data

t sta Agen t Agen n statio tion

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.

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.

10

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

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:

eke 3 gat H.32

eper

erver nter s all ce C 3 H.32

gatek

r eepe

r serve enter Call c

LAN ew 3 gat H.32 ay

Data

base

serve

r LAN r serve H.32

3 gat

eway

t stat Agen t stat Agen ion ente Call c ion

Data

base

ion t stat Agen PSTN ts Agen n tatio enter Call c serve r Custo mers

PSTN

er r serv

WAN

p ekee 3 gat H.32 m Custo ers

er

3 gat H.32

ekee

per

LAN eway 3 gat H.32

ba Data

rver se se ver

LAN r se se

H.32

3 gat

eway

t sta Agen ts Agen tatio n net Inter tion

ba Data

t Agen t Agen n statio n statio

net c Inter

ustom

ers

Figure 1-4. Multiple Call Centers on Dedicated Lans Interconnected by a WAN with Customer Access over the Internet

11

 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.1pcompliant 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

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 customers 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.

12

app Call er serv enter c

r Othe erver on s licati

r Othe erver ns icatio appl Call er r serv cente

r Othe lient nc catio ppli

3 H.32 er p ekee gat

ap

r Othe lient on c licati p

3 H.32 er ep ateke g

LAN 3 gat H.32 eway

ba Data

rver se se

LAN ver e ser

3 ga H.32

y tewa

t sta Agen t Agen statio n er r serv tion

bas Data

ion t stat Agen PSTN Agen ion t stat per en Call c rver ter se Custo mers

PSTN

ekee 3 gat H.32 mer Custo s

per

ente Call c

WAN 3 H.32

ee gatek

LAN ewa 3 gat H.32 y

bas Data

e ser

ver LAN r serve

H.32

3 gat

eway

base Data ion t stat Agen

Agen t stat Agen ion ion t stat Othe on licati r app r serve

io t stat Agen on licati r app Othe lient c

n r Othe n tio plica ap erver s net Inter on licati r app Othe lient c

ne Inter

tom t cus

ers

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

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,

migration of agents between sites requires dynamic distribution of agent location information between gatekeepers.
Case 2: Converged Network Support for Financial Transaction Applications

-end Back rk wo net prise Enter rk two ne

cati Appli SAP c lients

on se

rvers

Figure 2-1. SAP Distributed Architecture

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 netrvers se se work. Consequently, ba 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.

14

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

Data SAP c lients prise Enter rk wo net

s base

erver

ca Appli

tion s

erver

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 serverto-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:

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

16

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 serverto-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.

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

18

us camp ATM ne LAN bo back cate Dedi d LAN Dedi LAN te cla Remo m ssroo cated LAN

io Stud

Dedi

cated

class room

te 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

ket s pac ampu backbone C hed switc cate Dedi d LAN cate Dedi LAN te cla Remo ssroo m d LAN

io Stud

Dedi

cated

e clas sroom

t 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.

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.)

20

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 tched swi -a Multi a pplic AN tion L Multi ti plica on LA N class room -appl ic LAN ation

sroom

t Remo

e clas

Stud

io

-ap Multi

Stud io Remo te cla ssroo m

te Remo

Figure 3-3. Multi-Application Edge and Studio LANs Connected by a Campus Packet Switched Backbone

21

te Remo

class

room

m ssroo te cla Remo -appl ica AN tion L on L licati AN io Stud

Multi ati pplic N on LA

Stud

io

-a Multi

Multi ket s pac ampu backbone C hed switc

-app

sroom e clas

t Remo

WAN

cket us pa e Camp backbon ed witch s icati -appl Multi N on LA on LA N e clas sroom Multi icati -appl Multi -app N on LA licati

room

te Remo

class

io Stud

io Stud Remo te cla s sroom

t 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

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

22

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 Relaybased 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

te cla Remo

ssroo

t Remo e cla m ssroo io

Multi LAN ation ket s pac ampu backbone C hed switc Acce te cla Remo m ssroo WAN netw ork ss ne -appl ic LAN ation n LA catio appli N

Stud

Stud

io

ic -appl Multi

Multi

twork

es Hom

tuden

ts

Hom

dents e stu Acce

ss ne

twork

ket s pac ampu backbone C hed switc ica -appl Multi tion L AN Multi n LAN -

n LAN catio appli

te Remo

class

room

tudio

-app Multi

o licati

te cla Remo m ssroo

room class

Stud

io

te Remo

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.

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

24

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 calls 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

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

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

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

3 H.32

gatew

ay

PSTN WAN

3 H.32 PSTN

gatew

ay

Carri

er

Figure 4-1. Toll Reduction over Existing PSTN Services

26

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 customers 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 teways 3 ga H.32

t ndan Redu epers ke gate

n, zatio thori s ry, au ng server to Direc ccounti and a

PSTN at SS7 g

eway

WAN tewa y

a SS7 g

on, rizati autho servers tory, Direc ccounting nd a a

PSTN

t ndan Redu teways ga 3 H.32

t ndan Redu epers e gatek

e Carri

Figure 4-2. Toll reduction with Sophisticated Call Management and Redundancy

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

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

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

28

Mode

m t ndan Redu epers e gatek

er Carri
t ndan Redu teways a g .323

PSTN m Mode r xDSL o WAN SS7 ay gatew a SS7 g y tewa

n, zatio thori s ry, au ng server to Direc ccounti and a

n, zatio thori s ry, au ng server to Direc ccounti and a

m Mode L S or xD t ndan Redu teways a 3g H.32 t ndan Redu epers ke gate

PSTN

prise Enter

LAN

ased PC-b one ph tele

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

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.1pcompliant 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 carriers 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.

30

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
Mode m t ndan Redu epers eke gat

er Carri
t ndan Redu teways ga 3 H.32

PSTN m Mode r xDSL o WAN SS7 ay gatew SS7 g ay atew

on, rizati s utho r ory, a ting serve t Direc ccoun and a

on, rizati s utho r ory, a ting serve t Direc ccoun and a

m Mode L r xDS o t ndan Redu teways ga 3 H.32 t ndan Redu epers e gatek

PSTN

POTS

Soft

PBX

Enter

prise

LAN

Figure 4-4. Toll Reduction with Advanced Services and Standardization

ased PC-b

telep

hone

31

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 customers 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

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 convergencecost savings, improved network control, increased flexibility and functionalitynew capabilities are required in the network infrastructures. A phased deployment can deliver benefits at each incremental step. Whether or not an organizations immediate plans include convergence, todays infrastructure investment should include features and capabilities that position the network to support these applications in the future.

32

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
3Com Austria Phone: 43 1 580 17 0 Fax: 43 1 580 17 20 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 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 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

Poland Phone: 48 22 6451351 Fax: 48 22 6451352 Russia Phone: 7 095 258 09 40 Fax: 7 095 258 09 41
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 GmbH Berlin, Germany Phone: 49 30 3498790 Fax: 49 30 34987999 Munich, Germany Phone: 49 89 627320 Fax: 49 89 62732233 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 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

Peru Phone: 51 1 221 5399 Fax: 51 1 221 5499 Venezuela Phone: 58 2 953 8122 Fax: 58 2 953 9686
3Com Mediterraneo Milan, Italy Phone: 39 2 253011 Fax: 39 2 27304244 Rome, Italy Phone: 39 6 5279941 Fax: 39 6 52799423 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