◆

VoIP Network Architectures and QoS Strategy Bharat T. Doshi, Dominik Eggenschwiler, Aswath Rao, Behrokh Samadi, Y. T. Wang, and James Wolfson Voice over IP (VoIP) has received much attention in recent years with the promise of lower costs, as well as new revenue-generating services. Cost and services advantages of carrying voice over IP compared to over the current circuit network are made possible by a common high-capacity packet infrastructure for voice, data, and multimedia services. An important requirement of such a packet infrastructure is the ability to provide publicswitched telephone network (PSTN) grade quality without excessive overprovisioning. In this paper, we describe an approach to offer AbsoluteQoSTM to voice and other demanding applications over a general-purpose packet network. AbsoluteQoS is defined as the ability to provide an engineered bound on call-blocking and quantitative QoS guarantee that calls-in-progress will receive. The proposed strategy is based on key innovations in architectures and protocols, as well as business models of PSTN and packet networks. © 2003 Lucent Technologies Inc.

Introduction There has been great interest in voice over Internet Protocol (VoIP) over the last decade. The key value proposition has been the low price that the consumer would pay because of the expected major reduction in capital and operations cost afforded by a common high-capacity packet infrastructure for data and voice. Another promise is rapid creation of new services possible by a common infrastructure and an extensive set of service creation mechanisms Internet Protocol (IP) enables. Aside from business reasons, a few critical technical issues have, however, prevented large-scale deployment of higher revenue generating VoIP services as well as new services. The most notable technical issues are: • Lack of end-to-end quality of service (QoS) mechanisms and operation/control structure precludes

public switched telephone network (PSTN) quality without excessive over-provisioning of the packet network. • Poor hardware and software reliability/availability. • Effort needed to duplicate a large embedded base of software for management, call control, signaling, supplemental services, and intelligent networks (INs), perfected over many years in PSTN. • Lack of support for different business models common in PSTN, particularly lack of servicelevel guarantees across multiple administrative domains and vertically between layers. In this paper, we propose an architecture for VoIP services that provides the mechanisms to support QoS. Although we focus on the first issue above, our proposed architecture enables effective solutions to

Bell Labs Technical Journal 7(4), 41–59 (2003) © 2003 Lucent Technologies Inc. Published by Wiley Periodicals, Inc. Published online in Wiley InterScience (www.interscience.wiley.com). • DOI: 10.1002/bltj.10033

Panel 1. Abbreviations, Acronyms, and Terms AD—administrative domain A-MSW—access MSW ATM—asynchronous transfer mode BGP—border gateway protocol B-MSW—border MSW BW—bandwidth CAC—call admission control CC—call control C-MSW—core MSW CMTS—cable modem termination system CR-LDP—constraint-based routing–label distribution protocol CRM—connection resource manager DiffServ—differentiated services DS0—digital signal 0 DSALM—digital subscriber line access multiplexer DSCP—DiffServ code point DSL—digital subscriber line E1—European signal rate of 2.048 Mb/s E3—European signal rate of 34.368 Mb/s HFC—hybrid fiber coax ID—identification IN—intelligent network IntServ—integrated services IP—Internet protocol IPDC—IP device control protocol ISDN—integrated services digital network LSP—label-switched path MGW—media gateway

the remaining issues as well. In particular, to achieve a PSTN grade of service in VoIP networks the following requirements are critical: 1. Global reach of PSTN and VoIP endpoints via multiple administrative domains (ADs). 2. Signaling mechanisms that support rich and flexible services. 3. Guarantee of PSTN-grade voice quality as measured by mean opinion score (MOS). 4. Mechanisms to make sure the calls in progress are not adversely affected by new calls. 5. Traffic/resource engineering to provide a bound on the fraction of call setup requests denied at busy hour load. 6. Hardware and software architecture of network elements, routing and alternate routing

42

Bell Labs Technical Journal

MOS—mean opinion score MPLS—multiprotocol label switching MS—media server MSW—media switch OCn—optical carrier n OSPF—open shortest path first PBX—private branch exchange PNNI—private network-to-network interface PSTN—public-switched telephone network QoS—quality of service RSVP—resource reservation protocol SDH—synchronous digital hierarchy SIP—session initiation protocol SLA—service-level agreement SONET—synchronous optical network SS7—Signaling System 7 STM—synchronous transfer mode STM-1—synchronous transport module, level 1 T1—digital transmission carrier 1 T3—digital transmission carrier 3 TBC—transport bandwidth control TDM—time division multiplexing TE—traffic engineering ToS—type of service VCI—virtual circuit identifier VoIP—voice over IP VPI—virtual path identifier VPN—virtual private network VTG—virtual trunk group

mechanisms, and network management to enable high service availability. Given good codecs, requirement 3 above is met if the packet delay, jitter, and losses are kept sufficiently small. The ability to meet requirements 4 and 5 above and deliver packets with small delay and loss will be called AbsoluteQoSTM capability and is the focus of this paper. Note that a traditional IP network, represented by the public Internet, lacks the tools and methods to provide anything close to AbsoluteQoS. The paper describes an approach to offer AbsoluteQoS in VoIP networks. We illustrate how recent and emerging standards provide some of the components that allow our approach to be implemented and share the packet infrastructure with other services, thereby reducing further the cost for service

providers. The particular standards of interest for IP networks include integrated services (IntServ), differentiated services (DiffServ), resource reservation protocol (RSVP), IP tunnels, virtual private networks (VPNs), and traffic engineering (TE) extensions of routing and signaling protocols. Furthermore, multiprotocol label switching (MPLS) technology, with support for constraint-based routing and TE, makes it easier to offer end-to-end QoS. Finally, emerging MPLS standards support very fast restoration of LSPs in the event of network failures, which is critical in meeting the availability and reliability requirements stated above. The basic idea of the proposed architecture is based on the observation that the packet network can provide a set of virtual trunk groups (VTGs) with specific bandwidths and other service-level assurances to the voice service network the same way that the layer 1 private networks of T1/E1s, T3/E3s, OC3s and STM-1s are provided to the circuit-switched voice networks as sets of trunk groups. Furthermore a resource accounting mechanism in the voice service network keeps track of the number of calls in progress and resource allocated on a VTG. Knowing the capacity and the current usage of VTGs, this accounting process enables the network to allow or deny a new call set-up request depending on whether or not all VTGs in its path can accommodate a new call without causing a QoS violation. The bandwidth allocated for VTGs are such that the fraction of calls denied (blocking probability) during busy hour is below some specified number (typically 0.1% to 1%). Since some packet networks can offer bandwidth on demand, VTGs can be made much more dynamic compared to the traditional trunk groups in circuit-switched voice networks where transport networks offer bandwidth through static provisioning. This dynamic reprovisioning capability also implies that the traffic engineering needed to size the VTGs could be simple and could be fine-tuned more frequently with performance measurements. The architecture proposed in this paper has evolved from some earlier work in [3, 7], where the ideas of using guaranteed bandwidth paths and using accounting-based call admission control (CAC) were

first developed. The current work develops the ideas fully and also addresses the mechanisms to scale the architecture.

VoIP Network and Service Architectures In this section, we outline a layered architecture where we delineate the voice/multimedia call and connection service from the underlying packet transport network to ensure the extensibility and flexibility of the proposed architecture. Although we mainly discuss voice applications, it should become clear that the proposed architecture extends to the support of future applications with well-defined QoS requirements and traffic profiles, including multimedia applications. VoIP networks may have to interwork with existing time division multiplexed (TDM)-based voice networks. From the point of view of interworking, there are basically three distinct scenarios as shown in Figure 1. • Network interworking, where the packet network is deployed in between TDM networks such as PSTN and the end hosts/devices are traditional voice devices, such as analog or integrated services digital network (ISDN) phones. • Service interworking, where an IP endpoint communicates with traditional voice devices over a packet and TDM network. • Native VoIP service, where IP endpoints communicate with each other over a packet network. Components and Definitions The component planes of a network include user, control, and management, and are discussed next. User plane. The following network elements are key user plane components of VoIP networks: • VoIP endpoints/hosts. Along with media gateways, these are the end systems where the VoIP application resides and is associated with a particular public or private IP address. • Media gateway (MGW). An element used for interworking with TDM networks that performs media conversion between asynchronous VoIP packets and synchronous TDM byte streams. • Media server (MS). Provides additional services such as text-to-speech, audio-announcement, and transcoding to the media stream.

Bell Labs Technical Journal

43

Circuit-switched network

Packet-switched network

Circuit-switched network

Network Interworking

Circuit-switched network

Packet-switched network

Service Interworking

Packet-switched network

Native Service

Figure 1. VoIP service scenarios.

•

•

44

Media switch (MSW). A logical entity that performs multiplexing/demultiplexing and switching of incoming to outgoing connections, using locally stored packet label mapping rules. Packet networks provide these functions as core services but media service intelligence helps set the mapping tables. Packet Transport Network. The underlying IP network that provides bearer transport for voice packets. We adopt the following commonly used terminology for the packet transport network: – Administrative domain (AD). This is the entity that is operated and controlled by a single authority, which could be a network operator. Typically, services provided by an AD are subject to various formal or informal service-level agreement (SLA) in between its authority and the ADs or other users. – Packet technology domain. Within an AD, it is possible that one or more technologies such as IP, asynchronous transfer mode (ATM) or MPLS are employed with appropriate interworking functions. The packet technology domain,

Bell Labs Technical Journal

especially at the access, may be differentiated by layer 2 technologies such as Ethernet, digital subscriber line (DSL), cable, and wireless. – Routing Areas. Within each packet technology domain, there could be one or more routing areas depending on the underlying routing technology. For example, two level open shortest path first (OSPF) routing areas in IP/MPLS networks and hierarchical private network-tonetwork interface (PNNI) in ATM networks. Control plane. The main functions of the control plane are to set up the bearer connection, maintain the context and state of calls and connections in the network, and apply controls to the user plane. A number of crucial functional entities in the network are needed for such purposes. They include: • Call control (CC). CC is the entity that establishes and maintains the call context and state. • Connection server and resource manager (CRM). For each call, there might be one or more connections that need to be established to carry the bearers. The logical entity that manages these connections, including maintaining the connection state and

routing, is called connection server. Connection server communicates with the resource management module that is responsible for accepting/ rejecting the connection setup requests and for allocating/de-allocating resources to connections. For convenience, we will label CRM as the composite entity made up of connection server and the resource manager. • Signaling server. As the name suggests, signaling server implements the signaling protocols and interfaces to provide signaling service functions. • Signaling gateway. This device provides interworking of signaling protocols. For example, Signaling System 7 (SS7) is the commonly used signaling protocols in PSTN while session initiation protocol (SIP) is a newly emerging IP signaling protocol. To set up a call across PSTN and a SIP-enabled IP network, a signaling gateway is needed to translate the messages between these two technologies. • MGW controller. The MGW controller controls the MGW during the connection setup phase using protocols such as Internet protocol device control (IPDC) and H.248. • Softswitch. Softswitch has been used in different ways in the literature. We define softswitch as the logical entity made of call control, signaling server, signaling gateway, and MGW controller. • Application server and IN. Intelligent services are provided through application servers and packet IN entities that support the service creation and management. Protocols and application interfaces are required between the call controls and the application servers for the request/response. Management plane. No network is complete without good support of operations and management. Typical functions include provisioning, traffic engineering, capacity planning, policy management, fault management, service and subscriber management, performance/QoS/SLA management, monitoring, reporting, auditing, and billing. Although we will not address the details of the management plane functions in this paper, it is useful to keep in mind when designing a QoS architecture, that the time scale of the management plane is usually

in minutes or longer, and it is much slower than that of the control plane. VoIP QoS Considerations From the user’s point of view, the perceived QoS encompasses a number of objective and subjective measures of service as one traces through the sequence of events from the setup until the completion and teardown of the call. Each such measure has an objective. It is important for any VoIP service to recognize the QoS objectives and make sure they are met. Call and connection QoS. PSTN voice users today expect dial tone delay within a fraction of a second and connection establishment (post dial tone delay) within a few seconds after dialing all digits. Similar delay requirements, depending on the interfaces and human factors, can be derived for VoIP applications [4]. There are requirements on limiting connection denial and call blocking in PSTNs. The call blocking probability is typically expected to be on the order of 0.1% to 1%. Similar to the mobile telephony environment, dial tone delay may not be applicable to VoIP calls. Thus, the primary measures of the QoS at call or connection level are blocking probability and the setup delay. Bearer Service QoS. It is critical that required QoS is maintained for the bearer so that the users will have satisfactory experience with the service during conversation. Although the measure of the ultimate user experience can be somewhat subjective, it is also recognized that a few quantitative metrics can be used to infer the subjective QoS, and thus to design and engineer the services. The main metrics for bearer QoS in packet networks include: • Loss. This is the loss characteristic of the bearer between the transmitter and the receiver of the media stream. Packet losses may result in clipping of media at the receiver. Thus, the fraction of packets lost needs to be low. • Delay. This is sometimes referred to as “mouth to ear” latency for voice application. The packet infrastructure contributes to the delay of voice samples due to packetization, packet forwarding, and buffering/queuing delay experienced through the links and switches/routers in the packet network.

Bell Labs Technical Journal

45

For interactive voice, one-way delay under 150 ms is considered highly desirable [6]. • Delay jitter. This is the measure of delay variation of the application data units. It can be expressed as the distribution of the variable part of the delay. As the TDM network and constant bit rate voice decoders expect receiving samples periodically, delay jitter can cause underrun or overrun of the receiver and a playout buffer is often used to mitigate such effect. These contribute to the delay and/or packet loss. Hence, there is a need to control the delay jitter. The quantitative requirements of these bearer QoS depend on a number factors, such as the type of codec and particular applications. For further discussions, one can refer to [3]. Note that for conferencing and multimedia applications, additional requirements such as synchronization of packet deliveries over multiple connections may be needed, as discussed in [3]. Supplemental Services QoS. These include QoS 4 services like call forwarding and three-way calling. To provide such services, in-band or out-of-band signaling is typically used to communicate to the network and request service. Frequent use of database queries, are required to provide these services, adding new requirements on QoS. Factors Affecting Bearer QoS For the rest of the paper, we will focus primarily on the bearer QoS and propose an architecture and strategy that provides AbsoluteQoS. It is important to keep in mind that any scheme provided must allow the service providers to plan, engineer, and manage the QoS so that the blocking remains below a required level. The factors affecting bearer QoS can be put into the following two categories: • Traffic profile, resource contention, and management. As application data units in the bearer plane traverse through end-systems, various network elements, and the links connecting them, they experience and accumulate delay, loss, and delay jitters. Collectively, total load, traffic profile of the applications, resources such as buffers and

46

Bell Labs Technical Journal

•

transmission links, and resource management schemes determine the level of QoS received by each bearer channel. Proactive and reactive controls. There are two approaches to controlling load, and hence to delivering QoS in packet networks, i.e., proactive versus reactive. Reactive controls call for the network to monitor the congestion of resources and upon detection of impending problems, react, and take necessary corrective action. In contrast, proactive control calls for a priori determination of admission or denial of the service when a service request is made. The decision is based on the resources and QoS required by the application as well as on the current resource usage in the network. The intent is to ensure that the accepted calls will get the required QoS. Note that while proactive control requires more a priori information and the conformance of the application traffic, the reactive control poses a significant risk to the QoS received for all users when the speed of congestion build-up and damage spread is much faster than the reaction time designed in the control.

Level of QoS and Why AbsoluteQoS Advances in IP technology have been associated with the development of Internet, where easy connectivity with minimal intervention from network has been a major driver. It is not surprising that more delicate QoS requirements such as delay, jitter, and loss have not been a primary driver. Some early proposals of VoIP application and QoS strategy suggest the use of type of service (ToS) bit and marking of voice packets such that they will receive high priority service as long as routers support priority scheduling. Such approaches would deliver adequate bearer QoS to voice applications in the following limited environment: • There are no failures in the network, • The link transmission time of the interfering data packet is sufficiently small, • The total high-priority traffic load is not too high compared to the link bandwidth, and

•

There is adequate buffer management that maintains sufficiently small losses for high-priority traffic. However, a quick examination will show that it is difficult for a network operator to ensure that these assumptions would not be violated without additional mechanisms. In particular, many networks may have a large fraction of traffic with demanding QoS requirements, so that absence of congestion for highpriority traffic cannot be guaranteed. To overcome the lack of QoS guarantees from the network, there are edge-based QoS approaches that propose use of measurement-based reactive methods to predict the QoS and implement CAC to admit or reject a connection setup request [7]. This approach can provide a reasonable improvement on bearer QoS in a simple priority-aware network. In fact, when sending traffic over uncontrolled Internet, this may be the only viable option to provide a degree of control. However, it does not meet the objectives of AbsoluteQoS with a target blocking level. It is also vulnerable to rapid changes in traffic volumes. The fundamental issue is clear. PSTN users have come to expect a high level of service quality. In order for a VoIP service to be attractive to such users, the service provider must guarantee a high level of service availability and predictability similar to PSTN. This implies that the AbsoluteQoS requirements stated earlier are critical.

Basic Concepts in AbsoluteQoS In this section, we describe the proposed strategy to provide required delay, jitter, and loss for the packets, while bounding the call blocking probability. As mentioned earlier, this strategy is based on a few key observations of PSTN and packet networks. We begin with a summary of these key observations about PSTN and packet networks. Key Ideas in the Proposed Strategy In circuit-switched voice networks, two switches are connected by one or more circuits. These circuits, at T1/E1/DS3/STS1/STM-1 rates, are provided by the intervening transmission network consisting of digital cross connects and SONET/SDH rings or dense

wavelength division multiplexing systems. These circuits can be divided into multiple digital signals level 0 (DS0s), where each DS0 provides 64 kb/s transmission capacity. Voice service providers create trunk groups from these circuits. Each DS0 can carry one voice call and is called a trunk. During the call setup, adjacent switches in the path of a new call assign a trunk from a trunk group between those switches, if a trunk is available. If no trunk is available on one or more segments in the selected path, the call gets blocked (denied) or alternately routed over a different path. Consequently, an admitted TDM voice connection is made up of concatenated trunks with TDM switches connecting these trunks. Note that the trunk assignment serves two purposes as follows: (a) It makes sure resources are available to carry voice samples throughout the conversation. (b) It allows intermediate switches to cross connect and switch the voice samples from an incoming trunk (port and time slot) to an outgoing trunk (port and time slot). In contrast, in packet-switched networks, each packet carries a label containing information needed to perform (b) above. The information may be source and destination addresses as in IP packets or Ethernet frames. In this case, no signaling is required to allow (b). The information may also be a virtual connection identifier, e.g., virtual circuit identifier/virtual path identifier in ATM, digital link connection identifier in frame relay, and LSP label in MPLS. In this case, provisioning or signaling is used to assign the identifiers to new connection and setting up cross connect and forwarding tables in switches en route. Property (a) may or may not be supported in packet networks. However, standards activities for IP and MPLS provide tools that move in that direction. We exploit these capabilities as follows: • If we have N simultaneous voice calls (with specific coder characteristic and encapsulation protocols) between two label-based switches with other label-based switches en route, we can compute the equivalent bandwidth number, BW (N) [5, 9], needed to keep the delay, jitter, and losses within budget along that path. Label-based

Bell Labs Technical Journal

47

switches may be MGWs, edge routers, core routers, and MPLS label edge routers. Thus, effectively a guaranteed bandwidth path with capacity, BW (N), is equivalent to a trunk group of size N. This can be considered a VTG. • If we reserve bandwidth equal to BW (N) for a VTG and have a CAC that limits the number of voice calls on this VTG to below N, we will meet bearer level performance requirements in the absence of a failure. Thus, a simple accounting method used in the circuit-switched world can be used in the label-switched world as well. Whenever a new call is admitted in a VTG, we increment a counter by 1. We decrement that counter by 1 whenever a call completes and is torn down. If a new call request arrives when N calls are already active on that VTG, the call is denied. We can go one step further and create virtual trunks (VTs) in a VTG. That is, VTs in a VTG of size N are numbered from 1 to N and a call is assigned a number (ID) in that VTG. Unlike in the circuitswitched network, VT ID does not have a physical significance in the bearer plane. However, this will allow the control plane to work almost exactly as in the circuit-switched networks. It will also allow easier interworking between circuit- and label-switched voice networks, e.g., at MGWs and at signaling gateways. It will also help auditing the status so bandwidth does not get stranded due to poor accounting. A VoIP service provider may have its own packet network from which it can create the needed VTGs or it can obtain VTGs from one or more packet network operators. The set of VTGs provided by one packet network operator could be considered a VPN with a particular service-level assurance. As VPN technology matures in IP and MPLS, VTG concepts can be implemented easily in an environment with multiple owners for different layers of networking and for multiple domains even within a layer. The decisions to accept or reject a call can be made in one or more places depending on the VoIP network topology and the control architecture. As defined earlier, CAC decisions are made at the CRMs. We describe various network architectures and possible implementation options of CAC and CRMs below.

48

Bell Labs Technical Journal

Architectures for Single Domain in a Network-Interworking Scenario We start with a set of simple network architectures. The VoIP service here is to provide a packet backbone with PSTN circuit-switched access. MGWs provide the bearer connections and conversions. This architecture has one AD for VoIP service and the network is small enough to be managed as one (voice) routing area. A number of options that can be used to provide AbsoluteQoS for VoIP services in this network with the proposed QoS architecture and strategy are discussed below. Flat network: VTGs between pairs of MGWs. VTGs can be created between all pairs of communicating MGWs to carry the packet voice streams. If there are N MGWs, this arrangement would create N (N ⫺ 1) half-duplex VTGs. Thus, this solution is viable and efficient when the number of MGWs is modest and there is sufficient traffic between any pair of MGWs. Another requirement is that MGWs participate in the bandwidth reservation and CAC activities, and would only forward packets that belong to voice connections that have been admitted into the half-duplex VTGs that originated from it. The simplest arrangement is to have the MGWs in one routing area and implement one CRM for the area, as shown in Figure 2. This CRM gets the call setup request from the call servers for calls originating from a PSTN device. Knowing which VTG can be used to route the call, CRM will perform CAC, select the VTG, increment the count of active calls or used bandwidth on that VTG, and decrement the count when this connection is torn down. In situations where a centralized realization of CRM could become limiting, we can divide the MGWs into groups and have a CRM for each group. This CRM will account for all VTGs terminating at the MGWs in its control. Figure 3 shows the extreme case of distributed CRM realization where a CRM is associated with each MGW. With this arrangement, each CRM only needs to maintain the states of N ⫺ 1 half-duplex VTGs at the expense of additional signaling between the CRMs. Path aggregation: MSWs and inter-MSW VTGs. In a flat network made up of MGWs and meshed VTGs, the number of VTGs grows quadratically with the

MGW5

CRM MGW1 Packet Transport Network

VTG: 1-5 Edge Router A

Core Router VTG: 2-3

MGW2

VTG: 5-6 Core Router

Edge Router B

Core Router MGW6 Edge Router C

MGW3

MGW4

CRM—Connection resource manager MGW—Media gateway VTG—Virtual trunk group

Figure 2. Flat network, single CRM in the area.

CRM5 MGW1 MGW5

Packet Transport Network CRM1 CRM2

Edge Router A

Core Router

Core Router Core Router

MGW2

MGW3 CRM3

Edge Router C

Edge Router B

MGW6

CRM6

MGW4

CRM4

CRM—Connection resource manager MGW—Media gateway VTG—Virtual trunk group

Figure 3. Flat network, CRM with each media gateway.

Bell Labs Technical Journal

49

number of MGWs. Furthermore, the traffic on some VTGs may be small and the utilization of the VTGs is inefficient. The aggregation through edge routers buys a much higher efficiency, a much smaller number of VTGs, and easier operations. There is a related side benefit. Each inter-edge router VTG now carries traffic between many pairs of MGWs that allow extremely high efficiency due to statistical multiplexing, as stated above. Further, since the busy periods between different pairs of MGWs may not coincide, one can reduce the sizes of inter-edge router VTGs by taking advantage of the non-coincidence of busy periods. The concept described above requires the edge router to perform some functions per call based on the information communicated at the connection setup time. The function depends on the underlying packet technology. Routers provide these capabilities, but the interfaces to CRMs to activate these capabilities are part of the voice service. It is convenient to represent these interfaces as separate logical entities called MSWs. Thus, we have the VTGs between MSW pairs that pass through edge routers. We also have a VTG between each MGW and the MSW to which it homes. This allows logical separation of packet transport and voice services. In some situations, business models may suggest physically separate equipment to act as the MSW and sit between the MGW and edge routers. In others, MSW functions can be incorporated in the edge router. With aggregation, there are a number of possible arrangements for the CRM function as follows: • For small networks, all the MGWs and MSWs can be organized into one area. A single CRM is implemented for the whole area that manages all VTGs in the area between MSW pairs. This case is shown in Figure 4. Note that a high availability and reliability CRM solution would be needed to meet the required service availability and reliability. However, we will not discuss those aspects in this paper. • If the VTGs between MGW and MSW have congestion possibility and the number of MGWs is large, it is possible to have a more scalable solution by giving each MGW a CRM that accounts for the VTG between that MGW and the MSW to

50

Bell Labs Technical Journal

which it homes. Inter-MSW VTGs are managed by another CRM. This case is shown in Figure 5. Hierarchy of areas: architecture and CRM implementation. The solution involving direct VTGs between all pairs of MGW/MSW do not scale if the number of pairs of gateways/switches becomes large and each pair carries little traffic. In particular, efficiency drops dramatically as the VTG size reduces, especially when it is below 10 Erlangs. In addition, we cannot take advantage of the time-of-day variation in traffic distribution (non-coincidence of busy periods on different VTGs). Finally, operations become complex as the number of VTGs becomes large. The solution is to create one or more levels of routing hierarchy. In fact, MSWs can be considered as edge devices of a higher level network in the hierarchy to aggregate traffic between MGWs. When the number of MSWs becomes large, we can create another level of hierarchy. If VoIP deployment starts from the core (e.g., replacement of class 4 switches), we do not see a need for another level of hierarchy in the near future. Only when VoIP moves to the edge and has the potential of using several thousand small gateways, we may find that the number of MSWs is too large for full mesh connectivity. Another level of hierarchy is desirable in such a case. To introduce hierarchy, we divide MSWs into clusters and each cluster forming an area is managed by one CRM. These level 1 areas are connected by a level 2 area. Core MSWs (C-MSWs) in level 2 areas play roles similar to that of MSWs in the sense that they connect to the edge routers and use the packet transport network SLAs to create VTGs in between them. The difference is that the C-MSWs are connected by VTGs in level 2 area. Each C-MSW also provides a connectivity point for all MSWs in level 1 area to all other level 1 areas. Thus, every MSW in level 1 area has a VTG with a C-MSW in that area. Any connection between two MSWs in two different level 1 areas goes over three VTGs: a VTG between one end MSW and its C-MSW, a VTG between two C-MSWs and a VTG between the second C-MSW and the MSW at the other end. Our discussion now focuses on the network of MSWs and C-MSWs along with VTGs. We can have

CRM MGW1

MGW5

VTG AB

Packet Transport Network

Edge Router A, MSWA

Core Router

Core Router

Edge Router B, MSWB

Core Router MGW6

MGW2 VTG AC

Edge Router C, MSWC

MGW3 CRM—Connection resource manager MGW—Media gateway

VTG BC

MGW4 MSW—Media switch VTG—Virtual trunk group

Figure 4. Aggregation via MSW, single CRM.

one CRM for the entire network (all level 1 areas and the level 2 area). All new connection setup requests and connection tear down requests go through this CRM. In addition, this CRM knows about all VTGs and their capacities. Thus, this CRM can keep the status of all VTGs in the network and decide if a given connection request should be accepted or denied. Note that we may have more than one physical CRM for reliability reasons in this case, and they need to operate as one and meet the usual high availability requirements. Alternatively, we can have one CRM for each level 1 area and one CRM for each level 2 area. The CRM in a level 1 area keeps the status of VTGs between MSWs and the C-MSW in that area. The CRM in the level 2 area keeps the status of VTGs between

C-MSWs. Now, a connection request with MSWs in different areas involves three CRMs and associated CAC functions. Again, we can have a CRM for each MSW and C-MSW, as it is the case in PSTNs today. In fact, that was the norm in PSTNs since call processing and fabric were tightly coupled. The ability to separate the control plane from the bearer plane creates the architectural flexibility in our proposed strategy. Services/Applications Interface Most intelligent services in PSTN use profiles and logic in databases and servers before connections are set up and do not interface with bearer traffic directly. Since signaling and control logic for the proposed network architecture described here are virtually identical to those in the PSTN, the northbound interfaces from the call/connection server to the IN and similar

Bell Labs Technical Journal

51

CRM MGW1

MGW5 VTG AB

CRM-1

CRM-5

Packet Transport Network

Edge Router A

Core Router

Edge Router B

Core Router Core Router

MSW-C

MSW-A

Edge Router C

MGW2

MGW6

CRM-2 VTG AC

VTG BC

MSW-B

MGW3 CRM-3 CRM—Connection resource manager MGW—Media gateway

CRM-6

MGW4 CRM-4 MSW—Media switch VTG—Virtual trunk group

Figure 5. Aggregation, distributed, and centralized CRMs.

future services can be migrated easily from the ones in PSTNs. Once again, lower layer protocols for communications between call/connection server and IN entities can be changed to support the newer and more attractive alternatives available. Traffic Engineering of VTG Note that the scheme proposed here, similar to almost all schemes designed to provide bearer-level QoS guarantees and bound the blocking probability, relies on the following mechanisms: • The estimate of the bandwidth for N calls, BW (N), is accurate enough so that a VTG can support N calls without violating any of the bearer QoS (loss, delay, jitter) requirements. • The VTG sizing is accurate enough to keep blocking probability below the specified value. Note that the voice service providers typically obtain performance measurements and use them to fine tune the above. Furthermore, packet networks

52

Bell Labs Technical Journal

can support dynamic changes in the VTG bandwidth allocation, making it possible for the voice service providers to implement traffic engineering methods using measurement-based control of VTG size and of the number of trunks for a given bandwidth. Of course, the same measurements can be used to adapt VTG sizes as the traffic grows/shrinks. If voice calls use constant bit rate coding without silence suppression (most likely scenario for highquality PSTN backbone applications), BW (N) simply involves adding protocol overhead to the TDM bit rate to get BW (N) as the bandwidth used continuously by N calls. Thus, accuracy is achievable and we do not need any fine tuning. For voice applications involving vocoders with silence suppression and variable bit rate coding, there is a natural statistical variation in bandwidth used by N active calls. As in ATM networks, BW (N) is then the equivalent bandwidth required to carry N simultaneous

calls and meet some specific QoS requirements. A large body of research [5, 9], focused on estimating BW (N), is available and applicable here. However, measurements of utilization with N active calls as well as the measurements of loss, delay, and jitter may highlight possible variations from the assumptions used in calculating the equivalent BW function. If such a variation is systematic, CAC can be tuned to reduce or increase the number N for a given VTG size. On the other hand, these variations may be short term, lasting a few minutes. Similar to most dynamic controls, one should be careful in reacting to such short-term variations. Otherwise, oscillations may either violate the QoS guarantees, or oversize VTGs, or both. Multiple ADs So far, we have considered VoIP networks with one AD and one or more VoIP routing areas. Similar to PSTNs, there could be more than one VoIP service operator involved in completing the call/connection over multiple VoIP ADs. Each domain may have a flat or hierarchical structure. Fundamentally, the structure is similar to that with multiple areas described above, especially when the domains match the hierarchy. An example of this is today’s hierarchy of remote voice switches, class 5 switches, tandem, and toll (class 4) switches. Each local area can be considered one area at level 1 and all class 4 switches can be considered one area at level 2. Of course, we may have multiple ADs without going to a higher layer of hierarchy. Even this is fundamentally not different from the concepts discussed for hierarchy. Effectively, networks of MSWs and C-MSWs are organized in multiple clusters such that each cluster is managed by one administrative entity. Each one negotiates with its packet transport network to provide the VTGs required within its domain. By mutual agreement, these ADs select the MSWs used to interconnect different domains. Although interconnection can be done in many different ways, we represent this using logical entities called border MSWs (B-MSWs). Border CRM of an AD It is usually necessary for separate ADs to have separate CRMs. Border CRM is the CRM that manages the B-MSWs and interacts with the peer border CRM

in a different domain. The rest of the description follows easily. All VTGs within a domain are managed by one or more CRMs within that domain. These CRMs thus implement the necessary accounting function and CAC for VTGs in that domain. Border CRMs also manage the interconnection of B-MSWs and treat them as VTGs. At this level, the functioning is similar to the case of multiple areas although terminology is deliberately kept somewhat different. In fact, B-MSW and B-CRM are logical entities. They may be, and typically are, functions added to the MSW and CRM, respectively. A key functional difference may be because we may not have strict hierarchy that allows simple routing of calls among CRMs for controls and among MSWs for bearer traffic. Given the possibility of peering, we need to have additional inter-domain routing intelligence similar to that in PSTNs and in the Internet. Connection Level SLAs Between Domains An important consideration in networking across multiple domains is the end-to-end SLA for QoS guarantees. From the discussions above, it is clear that each voice service provider (AD) can use the tools available from packet networks to guarantee any specified SLA on voice bearer and to bound blocking probability. In a multi-domain environment, we have two additional important issues as follows: • Guarantee bearer QoS for end-to-end connection traversing multiple domains. • Assure that VTGs in each domain are engineered to bound blocking probability. The first one is critical because the weakest performing domain will dominate end-to-end quality of voice. The second one is critical because rejecting a connection request after a domain has accepted it results in waste of call processing capacity and possible crankbacks. It also wastes some bearer capacity because resources may be reserved for some duration before denial from one domain frees up resources. Finally, as we have seen in PSTN, high blocking probability in one domain may cause retries affecting all domains and risking a serious control plane overload. The only real solution is bi- and multi-lateral agreements about the requirements from each domain and measurement mechanism to make sure that

Bell Labs Technical Journal

53

these requirements are met. Once again, the new bearer and control plane capabilities in packet networks, as well as control plane measurement and engineering lessons from the PSTN, provide tools to define and monitor SLAs across domains. Architectures for Single Domain in ServiceInterworking and Native VoIP Scenarios Discussions above focus on the network interworking scenarios where VoIP flows originate and terminate at MGWs. For the service-interworking and native VoIP scenarios, at least one of the endpoints of the VoIP flow is an IP host. Conceptually, the notion of MSW and VTG carries over to these scenarios directly. VoIP service providers can implement access MSW (A-MSW) through which subscriber’s VoIP flows are admitted into the service network by the responsible CRM. An A-MSW may be attached to a digital subscriber line access multiplexer (DSALM), or a cable modem termination system (CMTS), or may aggregate traffic from many such devices. It may also aggregate traffic from many IP private branch exchange (PBX) systems. VTGs can be implemented exactly the same way as before in between A-MSWs and other MSWs, possibly with multiple levels of aggregations and hierarchies. In fact, the hierarchy concept discussed earlier is most needed when we expand the VoIP network out from the backbone to such access aggregation points. Recall that MGWs contain A-MSWs as logical entities. There are cases where we may want to expand the VoIP network out even further into access networks with multiaccess technologies (e.g., hybrid fiber coax [HFC] and wireless). VTGs pose more challenges in some of these cases. However, most multiaccess technologies offer tools to create VTGs in some form. We will discuss some of them below.

Virtual Trunking Technologies: VTGs in Packet Transport Networks Control and management systems in the packet network need mechanisms to provide VTGs with desired service-level assurance. The key requirements for a VTG are as follows: • Guaranteed bandwidth along the entire path and other service-level assurances (delay, jitter, and losses) if the traffic is within specified bounds, and

54

Bell Labs Technical Journal

•

In-sequence delivery of packets. Traditional IP networks have limited mechanisms to provide this level of service guarantees. In fact, the main approach has been using separate ports and links and gross over provisioning so that voice service has hopefully more than adequate bandwidth. Recent developments in IP (e.g., DiffServ, IntServ, and RSVP) can be used to support VTG requirements while also allowing resource sharing with less demanding applications. The most recent development in MPLS along with traffic engineering extensions in MPLS, OSPF, and RSVP provides even better tools to support VTGs along with many other applications. We discuss these possibilities below. All (or a subset) may be used to implement the VTGs for a given VoIP network. VTG Support in IP Networks Legacy IP networks routes are simple and destination-based, and use OSPF within domains, and border gateway protocol (BGP) between domains. While the ToS field is available to indicate priority, little of that has been used in the legacy IP network. Without the use of ToS to indicate priority, the best way to provide VTGs is to dedicate ports and links for voice services, and size those links and ports to match VTG bandwidth requirements. If routers can act on the ToS field to create simple priority to voice over all other traffic (treated as the best-effort traffic), then the principle is the same except that the capacity remaining on the links and ports (after satisfying the need for voice VTGs) can be used for best-effort traffic. Since IP routing is connectionless in theory, it raises a question as to how do we decide which links and ports to size for which sets of VTGs. In the real world, legacy IP networks use OSPF and other link state advertisements only to notify up-down status rather than detailed congestion information. Thus, all packets from a given flow are routed over the same path in the absence of a failure. Moreover, such a path can be calculated a priori based on weight settings and topology information. This is one way to identify the routes of calls between two MSWs and identify loading on each link and port. In turn, this will allow sizing of links and ports to meet

the needs of VTGs. Note that this is equivalent to off-line design of a network based on traffic estimates, and then implicitly creating VTGs by providing capacities on imputed paths. A natural question is what happens in the event of a failure. OSPF and other link state advertisement mechanisms allow detection of failure and alternate routing of packets. One approach to handling failures is to calculate alternate routes for different failures and size the links and ports to have the capacity to handle alternate route traffic as well as primary routed traffic. Methods are available to design networks of this type, while allowing a high degree of resource sharing for different failures. Another approach is to have a mechanism that provides the failure information to the CRM so it reduces the bandwidth available for affected VTGs and changes CAC parameters. The method above assumes the simple destinationbased routing is used in IP networks and that the routes are calculated based on the shortest path. If, at a given time, more capacity is available in some parts of the network and other parts are heavily loaded, the simple OSPF will not allow routing based on where extra capacity is available. There are also a number of methods available to establish a path in a more controlled fashion. They do involve overheads, and hence reduced efficiency. Some possibilities are as follows: • Tunneling where IP-in-IP tunnels can be set up in between the MSW or between an MSW and a core router and then between that core router and destination MSW. • Static routing where the path can be specified by bypassing the normal IP forwarding table. • Source routing where the path can be specified as a sequence of IP addresses, one for each hop in the path in the header of every packet. Clearly, source routing incurs significant packet overhead when considering the small payload of VoIP packets. A static routing approach requires special manual operations and management to bypass the normal forwarding table in the routers. Further, some routers process such traffic on their “slow path,” and thus incur more processing overhead and delay in

the user plane. IP tunneling adds to the protocol overhead on the packets as well. However, it provides the capability for creating simple routing segments and directs the traffic along the desired path. This is very useful in creating the hierarchy discussed earlier. We recommend its use be limited for such special cases. IP Network Supporting IntServ and DiffServ Two most notable efforts in developing QoS support in IETF during the last decade have been IntServ [2] and DiffServ [1]. The IntServ model includes RSVP, a soft-state-based receiver-initiated resource reservation signaling protocol to support QoS services called guaranteed bandwidth and control load. IntServ, with RSVP, guarantees bandwidth along the VTG path and makes the VTG bandwidth allocation more formal than the implicit mechanism used previously. It still relies on OSPF-type protocols to find the paths and cannot use idle capacities on alternate routes. Note that RSVP used here is for the VTG bandwidth reservation, not per call RSVP. The latter has serious scalability issues. The former allows dynamic allocation of bandwidth to a VTG. More recently, the DiffServ model has been proposed. In this model, edge routers classify and mark the DiffServ field of each packet with the desired DiffServ code point (DSCP) that specifies the per hop forwarding behavior of the core routers. One of the main motivations for DiffServ was to address the scalability problem of core routers in supporting IntServ by removing the requirement of the soft state. Since we propose the use of IntServ only for large aggregates (VTGs), the scalability issue goes away. The key benefit of DiffServ in this context is that it can provide a simple mechanism to inform interior routers of the priority assigned to a packet. Thus, we may allow traffic with low priority to enter the network with DiffServ field marked so that these packets do not interfere with voice packets for which bandwidth is reserved. In other words, DiffServ and RSVP together allow a simple implementation of VTG bandwidth guarantee. In summary, IP networks supporting IntServ or DiffServ can implement VTGs with more control than the legacy IP networks do. However, destination-based

Bell Labs Technical Journal

55

hop-by-hop route selection following traditional IP protocols is rather restrictive and does not allow more efficient routing and use of the network resources. MPLS and Traffic Engineering Extensions MPLS technology has been developed over the last five years, adopting the layer 3 IP routing protocols and layer 2 ATM connection-oriented forwarding and switching techniques. Some important capabilities provided by MPLS and its traffic engineering extensions are as follows: • Ability to set up a virtual connection in the form of an LSP with forwarding mechanisms similar to those in frame relay and ATM. This provides an explicit guarantee that all packets in an LSP will follow the path selected at the time of an LSP setup (or alternate route selection after an LSP failure, if specified). In particular, LSPs provide natural realizations of VTGs in MPLS networks. • Ability to specify the route of an LSP through the MPLS network explicitly. Thus, LSPs (VTGs) can be routed based on the capacities available in various parts of the network rather than based on capacity-blind OSPF protocol. Explicit routing such as constraint based routing allows better use of available network capacity. • Traffic engineering extensions to OSPF (OSPF-TE) and other link state advertisement to communicate topology as well as capacity information to all nodes. • Signaling extensions such as constraint-based routing–label distribution protocol (CR-LDP) and RSVP-TE allow the use of capacity information to request explicit routed paths with bandwidth guarantees. Thus, distributed mechanisms are available to set up explicitly routed LSPs based on network-wide capacity information. Alternatively, management-based provisioning can be used to set up explicitly routed LSPs based on centralized capacity information. • Dynamic distributed LSP establishment and bandwidth reservation capability mentioned above also allow dynamic changes in bandwidth reserved for an LSP.

56

Bell Labs Technical Journal

•

Ability to provide QoS differentiations through mapping the experimental field and label assignments to forwarding equivalence classes for delay and loss, respectively. • Ability to provide protection and fast restoration of LSP services. Many types of protection and restoration services are possible that can support fast recovery upon failure ranging from instantaneous recovery through tens to hundreds of milliseconds to several seconds. See [8] for details. • Ability to nest LSPs so that many smaller LSPs can be bundled into a larger LSP in the segment where they share the route. This is also useful in creating hierarchies. It is clear from the above that the LSP concept, along with the other capabilities and extensions in RSVP and OSPF, provide a natural vehicle for implementing VTGs in MPLS-based networks. Although the required bandwidth on a VTG can be estimated by a mix of planning and measurement-based techniques, some communication is needed between the voice service provider and packet network operator to make sure that the dynamic requests are satisfied. The endpoints of LSPs (VTGs) are the natural places for the voice service and packet transport to provide the interface. MSWs provide the logical entities where this interaction occurs. CRMs provide the needed information to the MSWs at connection setup time. MSWs then use this information to help route the voice packets along the right LSPs. Interactions Between Voice Service Layer and Packet Transport Layer: Transport Bandwidth Control Function As mentioned earlier, the proposed strategy defines a layered architecture where the voice services are packet networking technology agnostic. The key requirement for the underlying packet transport network is to provide VTGs with the requested properties and observe and deliver the required QoS to the voice service. For the packet transport network to support AbsoluteQoS VoIP services, we thus define a transport bandwidth control (TBC) function. TBC interfaces with a voice service provider to get input on the VTGs required, associated bandwidth, and bandwidth

changes, and then uses the capabilities in the packet transport network to provide the needed VTGs (or changes in VTGs). TBC may be implemented in policy servers and thus act through policy specifications that then activate controls (e.g., RSVP-TE and CR-LDP) or management systems to realize the agreed upon actions. Alternatively, the interface between voice service and packet transport may be purely in the signaling and control planes that further exploits the ability of packet-switched networks to dynamically allocate required resources. The two are conceptually similar for this purpose if policy servers can act fast enough to act as a signaling server. Note that from the voice service network perspective, CRM is the entity that requires the knowledge of the maximum capacity available by a VTG in its area. This data needs to be provided to CRM at the time of establishment of VTG and subsequently updated through a network management interface or signaling/control interface. Of course, CRMs also collect measurements that may suggest a need for changes in VTG bandwidth, and create and communicate such information to TBC.

Discussions In this section, the accuracy and reliability issue with the proposed architecture are discussed. Accuracy Note that all bandwidth reservation schemes need to maintain an accurate status of free bandwidth so that a decision can be made about acceptance/denial of a new request. The accounting involves subtracting from an available pool the bandwidth allocated to a new request and adding it back when a connection is torn down. Generally, accounting involves updating the free bandwidth status whenever changes occur due to new allocations, removal of existing allocations, and modifications in existing allocations. Note that accounting is needed and has been used for common services today including private line services, SONET/SDH circuits, wavelengths in a fiber link, the circuit-switched voice networks, and cell-based ATM networks. It has been recognized that if this accounting is not accurate, we may encounter situations where the commitment exceeds

the capacity (when the accounting fails to subtract some allocation) or when some capacity is lost (when the accounting fails to add freed up capacity back in the pool). Note that the problem can be encountered in slow and less frequent provisioning (management plane) and in fast connection setup using signaling (control plane). Auditing techniques have been developed to audit the status and minimize the frequency and duration of errors. VoIP CAC based on accounting should have similar support audits. Earlier, we discussed the concept of a virtual trunk in a VTG. This showed that bandwidth was allocated for a specific call. Although the packet network bearer does not worry about which call was allocated to which bandwidth (as long as the total is matched with available capacity), having tables of virtual trunks associated with call IDs or start time can be very useful in audits. Reliability The AbsoluteQoS approach to provide QoS assumes a network of available resources, i.e., softswitch, MGW, edge and core routers, and virtual trunk groups. Clearly, failure of any of these resources could disrupt the support of the required QoS for some connections and users. There should be strategies for detection and recovery from various failure scenarios at the voice service as well as packet transport layer. Some recent advances in resilient MPLS services are particularly attractive, as mentioned earlier. Disjoint MPLS LSP tunnels can be created to support various level of resiliency and recovery speed matching application reliability requirements. Further, there is a need for the packet transport network to feedback failures of the VTG to the CRM. This could be done through an interface to the packet network management system, which should be aware of the packet transport network failures.

Conclusion We have presented a VoIP architecture and QoS strategy that enables AbsoluteQoS supporting highquality end-to-end QoS comparable to that provided in PSTNs. The architecture delineates the functions of the voice service layer and the underlying packet

Bell Labs Technical Journal

57

network transport. It defines CRM in the service layer that performs the CAC function for given virtual trunk groups that can be implemented and provided by the packet network using various mechanisms depending on the particular technology and architecture. The proposed architecture supports VoIP services over various interworking scenarios between PSTN and packet networks. It is scalable and supports different business models of operators. Work is ongoing in creating appropriate protocols between the service layer elements and the edge packet network elements. Highly automated, low cost, efficient, and reliable VoIP services can then be realized through dynamic VTG management that fully exploits the benefits offered by the IP technology. Acknowledgments The authors would like to thank Christian Brennan, Donald Coffield, Scott Kutac, Eileen Miller, and Krishna Murti for their interest, comments, and support of this work. References [1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “An Architecture for Differentiated Services,” Internet Engineering Task Force, RFC 2475, Dec. 1998, . [2] R. Braden, D. Clark, and S. Shenker, “Integrated Services in the Internet Architecture: An Overview,” Internet Engineering Task Force, RFC 1633, June 1994, . [3] B. T. Doshi, E. Hernandez-Valencia, K. Sriram, Y. T. Wang, and O. Yue, “Protocols, Performance and Controls for Voice Over Wide Area Packet Networks,” Bell Labs Tech. J., 3:4 (1998), 13–32. [4] B. Douskalis, IP Telephony, Prentice-Hall, Upper Saddle River, NJ, 2000. [5] A. Elwalid, and D. Mitra, “Effective Bandwidth of General Markovian Traffic Sources and Admission Control of High Speed Networks,” IEEE/ACM Trans. on Networking, 1:3 (1992), 329–343. [6] International Telecommunication Union, Telecommunication Sector, “One-Way Transmission Time,” ITU-T Rec. G.114, May 2000,

58

Bell Labs Technical Journal

. [7] D. R. Jeske, B. Samadi, K. Sohraby, Y.T. Wang, and Q. Zhang, “An Edge-based Call Admission Control Technique in IP Networks,” Proc. of the 2nd IFIP Networking Conference (Pisa, It., May 2002), 178–189. [8] R. Nagarajan, M. A. Qureshi, B. Ramanna, C. Hunt, R. Chandwani, B. Das, and A. Shritriya, “A Fault-Tolerant MPLS-Based Control and Communication Network for the Lucent LambdaRouter,” Bell Labs Tech. J., 6:2 (2001), 153–169. [9] K. M. Rege, “Equivalent Bandwidth and Related Admission Criteria for ATM Networks—A Performance Study,” Internat. J. Commun. Systems, (1994), 181–194. (Manuscript approved December 2002) BHARAT T. DOSHI is a senior director in the Advanced Communications Technology Center at Bell Labs in Holmdel, New Jersey. He manages forward-looking work and applications in the areas of communication protocols, network architecture, performance/ reliability engineering, network routing, and network designs for advanced networking technologies. His recent work has focused on frame relay, ATM, SONET/SDH, optical networks, wireless networks, Internet/intranets, and DSPs for echo cancellers and vocoders. With a B. Tech. degree in mechanical engineering from the Indian Institute of Technology (IIT) in Bombay and M.S. and Ph.D. degrees in operations research from Cornell University in Ithaca, New York, Dr. Doshi has authored more than 110 technical papers and submitted more than 50 patent applications. A Bell Labs Fellow and an IEEE Fellow, he has been associate editor of three technical journals and has given many keynote talks at professional conferences. He has also participated in advisory panels for universities and government agencies and acted as a United Nations Development Program consultant to the Engineering and Research NETwork (ERNET) program in India. Dr. Doshi recently received the Distinguished Alumnus Award from IIT, Bombay. DOMINIK EGGENSCHWILER was formerly a member of technical staff in the INS Offer Definition organization at Lucent Technologies in Holmdel, New Jersey.

ASWATH RAO was formerly a technical manager in the INS Offer Definition organization at Lucent Technologies in Holmdel, New Jersey. BEHROKH SAMADI is a technical manager in the Communications Technology and Performance Department at Bell Labs Advanced Technologies in Holmdel, NJ. She holds a B.S. degree in mathematics from University College in London, England. She also holds an M.S. degree from Stanford University in California and a Ph.D. from the University of California in Los Angeles, both in computer science. Dr. Samadi is working on architecture design and performance of various products and networks including softswitch, wireless 3G1xEV-DO, and enterprise network architecture. Y. T. WANG is the director of the Networking Technologies and Performance Department at Bell Labs in Holmdel, New Jersey. He holds a B.S. degree in electrical engineering from National Taiwan University, and M.S. and Ph.D. degrees in electrical engineering and computer sciences from the University of California, Berkeley, respectively. Dr. Wang is responsible for advancing the architecture, protocols and design of data, wireless, optical and converged networks with high performance and reliability. He has published over 40 papers and holds 10 patents, with 15 others pending. JAMES WOLFSON was formerly a member of technical staff in the Architecture and Systems Engineering Department, OpenNet Business Unit at Lucent Technologies in Naperville, Illinois. He holds a B.A. degree in physics from Grinnell College in Iowa and a Ph.D. from the Massachusetts Institute of Technology in Cambridge. Dr. Wolfson was responsible for developing a strategy and identifying the features necessary to reliably and efficiently provide high quality voice communications across a converged packet network using the Lucent Softswitch. ◆

Bell Labs Technical Journal

59