signaling and switching for packet telephony

Signaling and Switching forPacket Telephony

For a listing of recent titles in the Artech House Telecommunications Library,turn to the back of this book.

Signaling and Switching forPacket Telephony

Matthew Stafford

Artech House, Inc.Boston • London

www.artechhouse.com

Library of Congress Cataloguing-in-Publication DataStafford, Matthew.

Signaling and switching for packet telephony / Matthew Staffordp. cm.—(Artech House telecommunications library)

Includes bibliographical references and index.ISBN 1-58053-736-7 (alk. paper)1. Internet telephony. 2. Packet switching (Data transmission) I. Title. II. Series.

TK5105.8865.S73 2004621.382'16—dc22 CIP

2004053829

British Library Cataloguing in Publication DataStafford, Matthew

Signaling and switching for packet telephony. —(Artech House telecommunicationslibrary)1. Internet telephony 2. Packet switching (Data transmission)I. Title621.3’85

ISBN 1-58053-736-7

Cover design by Yekaterina Ratner

© 2004 Matthew Stafford and Cingular Wireless. All rights reserved.

Printed and bound in the United States of America. No part of this book may be reproducedor utilized in any form or by any means, electronic or mechanical, including photocopying,recording, or by any information storage and retrieval system, without permission in writingfrom the publisher.

All terms mentioned in this book that are known to be trademarks or service marks havebeen appropriately capitalized. Artech House cannot attest to the accuracy of this informa-tion. Use of a term in this book should not be regarded as affecting the validity of any trade-mark or service mark.

Library of Congress Cataloguing-in-Publication Number: 2004053829International Standard Book Number: 1-58053-736-7

10 9 8 7 6 5 4 3 2 1

Contents

Acknowledgments xiii

CHAPTER 1Introduction 1

1.1 In the Beginning, There was Voice 11.2 Motivation: What Is the Case for Packet Telephony? 2

1.2.1 One Network Versus Two 21.2.2 Services 3

1.3 Switch Design 31.3.1 Separating Bearer and Control Planes 4

1.4 Motive and Opportunity for Carriers 51.5 What Are We Waiting For? 61.6 Motivation for this Book 7

PART ISwitching Architectures for Packet Telephony: An Expository Description 9

CHAPTER 2Essentials of Next Generation Switching 11

2.1 Another Look at the Backhaul Example 122.2 Ability to Enter New Markets 132.3 Switch Components and Terminology 14

2.3.1 Where Does One Switch Component End and2.3.1 Another Component Begin? 14

2.4 A Useful Abstraction 152.5 Defining the Fabric 16

2.5.1 Do Control Messages Between Media Gateways and2.5.1 Their Controller Pass Through the Switch Fabric? 172.5.2 What Is a Packet? 18

CHAPTER 3Motivation for Packet Telephony Revisited 21

3.1 Separation of Bearer and Control 213.1.1 Open Interfaces 223.1.2 Introducing and Maintaining Services 23

v

3.1.3 New Bearer Types 253.2 Packet Fabrics 26

3.2.1 Exploiting Routing Intelligence of Packet Networks 263.2.2 Exploiting Low Bit-Rate Voice Codecs 29

CHAPTER 4Signaling and Services 31

4.1 The Control Plane 314.2 What Is a Service? 32

4.2.1 Vertical Services 324.2.2 Services that Offer Alternative Billing Schemes 334.2.3 Short Message Service 33

4.3 Where Do Services “Live,” and What Do They Entail? 334.3.1 Can You Say “Database?” 34

4.4 Limitations of Circuit-Switched Networks 35

PART IIComponents of Packet Telephony: Technical Descriptions 37

CHAPTER 5Introduction to Part II 39

5.1 Selected Telco Terminology 40

CHAPTER 6Protocols 43

6.1 What Is a Protocol Stack? 436.1.1 Comparison with Last In, First Out Data Structures 44

6.2 Generic Layer Descriptions 446.2.1 Data Link Layer 456.2.2 Network Layer 466.2.3 Transport Layer 466.2.4 A Note on Terminology: Packets and Frames 466.2.5 General Comments 47

6.3 Internet Protocol and Transmission Control Protocol 486.3.1 What Is an Internet Protocol Router? 486.3.2 A Brief Look at TCP 486.3.3 TCP/IP Networking Illustration 516.3.4 Alternatives to TCP at Level 4: UDP and SCTP 52

6.4 What Is a Finite State Machine? 536.4.1 States 546.4.2 State Transitions 546.4.3 Additional Comments 55

6.5 Signaling System 7 in Brief 556.5.1 MTP2 566.5.2 MTP3 576.5.3 SCCP 576.5.4 TCAP 57

vi Contents

6.5.5 MAP 576.5.6 ISUP 58

6.6 Summary 60References 61

CHAPTER 7A Closer Look at Internet Protocol 63

7.1 The IPv4 Header 647.1.1 Fragmentation and Path MTU Discovery 65

7.2 The IPv6 Header 657.2.1 IPv6 Extension Headers 66

7.3 Addressing and Address Resolution 677.3.1 Conserving IPv4 Address Space 677.3.2 The IPv6 Address Space 687.3.3 Uniform Resource Identifiers and Domain Name System 69

7.4 Security and AAA 697.4.1 Security 697.4.2 Authentication, Authorization, and Accounting 70

7.5 Routing 717.5.1 Network Optimization 717.5.2 Internet Routing Protocols 727.5.3 A Link State Protocol: OSPF 727.5.4 Distance Vector Protocols: RIP and BGP 737.5.5 Routing Protocol Convergence 737.5.6 Scalability 757.5.7 Trade-offs 75

7.6 Reachability Information 767.7 Quality of Service and Statistical Multiplexing 76

7.7.1 What Is Statistical Multiplexing? 777.7.2 Differentiated Services 787.7.3 Multiprotocol Label Switching 797.7.4 “DiffServ at the Edge, MPLS in the Core” 807.7.5 Multiservice Networks 80

7.8 Layer 4 Protocols: Suitability to Task 817.8.1 UDP 817.8.2 Carrying SS7 Traffic over an IP Network: SCTP 827.8.3 Comparing and Contrasting TCP with UDP and SCTP 83

7.9 Mobile IP 847.10 Summary 84

7.10.1 Further Reading 85References 85

CHAPTER 8A Closer Look at SS7 89

8.1 SS7 Architecture and Link Types 898.2 SS7 Routing and Addressing 918.3 Review of the SS7 Protocol Stack 92

Contents vii

8.4 Message Transfer Part 938.4.1 MTP2 948.4.2 MTP3 94

8.5 SCCP 958.5.1 General Description and Communication with MTP3 958.5.2 Getting There Is Half the Fun: Global Title Translation 96

8.6 TCAP 988.6.1 Number Portability 99

8.7 MAP 1008.8 Summing Up 103

8.8.1 Additional Weaknesses of SS7 1048.8.2 Strengths of SS7 105References 105

CHAPTER 9The Bearer Plane 107

9.1 Voice Encoding 1079.1.1 G.711 1079.1.2 Why Digital? 1089.1.3 Other Voice-Encoding Schemes 108

9.2 Bearer Interworking 1119.2.1 Transcoding 1119.2.2 Encapsulation of Digitized Sound 1119.2.3 Packetization Delay and Playout Buffers 113

9.3 Voice over IP 1139.3.1 Real-Time Services in IP Networks: RTP over UDP 113References 116

CHAPTER 10Media Gateway Control and Other Softswitch Topics 119

10.1 Requirements 11910.1.1 ID Bindings 121

10.2 SDP in Brief 12210.3 Megaco/H.248 123

10.3.1 Introducing the Megaco Connection Model 12310.3.2 Terminations 12410.3.3 Contexts 12410.3.4 Megaco Commands 12510.3.5 Example Call Flow 12610.3.6 Usage of the Move Command 12910.3.7 Descriptors 13010.3.8 Sample Megaco Messages 13210.3.9 Three Way-Calling Example 13410.3.10 Megaco Miscellanea 136

10.4 MGCP 13710.4.1 Example Call Flow 13710.4.2 Brief Comparison with Megaco 138

viii Contents

10.4.3 Other MGCP Verbs 14010.4.4 Transactions and Provisional Responses 14110.4.5 MGCP Packages 142

10.5 Interworking with Circuit-Switched Networks 14210.5.1 Latency Trade-offs 142

10.6 Inhabiting the Bearer, Service, and Control Planes 14310.7 Signaling Between Two Softswitches 143

10.7.1 BICC 143References 144

CHAPTER 11Session Control 145

11.1 “Generic” Session Control 14511.1.1 Comparison with ISUP Call Flow 14711.1.2 Modularity in Protocol Design 147

11.2 The H.323 Protocol Suite 14811.2.1 Heritage of H.323: ISDN 14811.2.2 H.323 Call Control and Media Control Signaling 14911.2.3 Talking to the Gatekeeper: RAS Signaling 15011.2.4 Evolution of H.323 151

11.3 SIP Basics 15211.3.1 SIP Requests and Responses 154

11.4 SIP Functional Entities 15511.4.1 Proxy Servers and Redirect Servers 15611.4.2 Back-to-Back User Agents 15711.4.3 Registrars 157References 157

CHAPTER 12More on SIP and SDP 159

12.1 A Detailed SDP Example 15912.1.1 Additional Line Types 161

12.2 A Detailed SIP Example 16112.2.1 Registration Procedures 16112.2.2 Making a Call 16412.2.3 The Offer/Answer Model 167

12.3 Forking of SIP Requests 16812.4 SIP for Interswitch Signaling 168

12.4.1 Comparison with BICC 17012.5 Additional SIP Methods 170

12.5.1 UPDATEs and re-INVITEs 17112.6 Resource Reservation and SIP 171

12.6.1 QoS Attributes in SDP 17312.6.2 More on Parameter Negotiation 174

12.7 SIP-T and Beyond 17412.8 Authentication and Security 17612.9 Further Reading 176

Contents ix

References 177

CHAPTER 13Implementing Services 179

13.1 Introduction 17913.2 SS7 Service Architectures: Intelligent Network 180

13.2.1 The Global Functional Plane 18213.2.2 The Distributed Functional Plane 18213.2.3 IN Capability Sets 18313.2.4 Limitations and Trade-offs of IN 184

13.3 CAMEL and WIN 18513.4 Parlay/OSA 18513.5 JAIN 18613.6 SIP and Services 186

13.6.1 SIP and Intelligent Networks: PINT and SPIRITS 18613.7 SIP in Wireless Networks 190

13.7.1 Push To Talk over Cellular 19013.7.2 SIP Header Compression 19113.7.3 IP Multimedia Subsystem 192

13.8 Short Message Service 19513.8.1 SMS in Support of Other Applications 196

13.9 Further Reading 196References 197

CHAPTER 14Properties of Circuit-Switched Networks 199

14.1 Telco Routing and Traffic Engineering 19914.1.1 Truitt’s Model 20014.1.2 Dynamic Nonhierarchical Routing, Metastable States,14.1.2 and Trunk Reservation 20214.1.3 Optional Section: Traffic Intensity and the14.1.3 Erlang B Formula 203

14.2 Comparison with IP Routing and Dimensioning 20514.3 Security 20614.4 Quality of Service 20614.5 Scalability 20714.6 Survivability and Reliability 20714.7 Billing Functionality 20714.8 Emergency Service and other Government Mandates 208

References 208

CHAPTER 15Evolving Toward Carrier-Grade Packet Voice: Recent andOngoing Developments 209

15.1 QoS and Traffic Engineering in IP Networks 20915.1.1 Class-Based Queuing 20915.1.2 DiffServ and IntServ Revisited 210

x Contents

15.1.3 Verifying and Enforcing Traffic Contracts 21215.1.4 ITU-T and 3GPP QoS Standards 212

15.2 Service-Level Agreements and Policy Control 21515.3 SDP and SDPng 21615.4 Sigtran Adaptation Layers 21615.5 Middlebox Traversal 21715.6 Comments and Further Reading 219

15.6.1 More on IP QoS 21915.6.2 IPv6 and ROHC 21915.6.3 Routing for Voice over IP Protocols: iptel Working Group 22115.6.4 ENUM 22115.6.5 Service Architectures 222References 222

CHAPTER 16Conclusion 225

APPENDIX AData Link Layer Protocols 227

A.1 HDLC 227A.2 Frame Relay 227

A.2.1 The Frame Relay Header 228A.2.2 Label Switching and Virtual Circuits 229

A.3 Asynchronous Transfer Mode 230A.3.1 The ATM Header 230A.3.2 ATM Approach to Quality of Service and StatisticalA.3.2 Multiplexing 230A.3.3 The ATM Control Plane 231A.3.4 ATM Adaptation Layers and Options for Voice over ATM 232A.3.5 Virtual Paths 234A.3.6 MPLS over ATM: VC Merge Capability 234A.3.7 Why Not Voice over ATM? 235

A.4 Ethernet 236A.4.1 History of Ethernet 237A.4.2 Ethernet Frame Structure 237A.4.3 CSMA/CD and Its Scalability Limitations 238A.4.4 Hubs, Bridges, and Switches 238A.4.5 Further Reading 240References 240

About the Author 243

Index 245

Contents xi

Acknowledgments

During the development of this book, I had many helpful conversations with col-leagues. I would like to thank the following people in particular: Haifeng Bi, MikeBoeckman, Jasminka Dizdarevic, Steve Frew, Cathleen Harrington, David How-arth, Rich Kobylinski, Si-Jian Lin, Rias Muhamed, Jessie Lee, Steve Partridge,Simon Richardson, Sam Sambasivan, Richard Tam, Randy Wohlert, and MarkWuthnow.

The preparation of this book devoured many evenings and weekends. I wouldlike to thank my wife, Miriam, for her patience.

xiii

C H A P T E R 1

Introduction

1.1 In the Beginning, There was Voice

Voice telephony was arguably the first telecommunications service to achieve trulywidespread deployment. Data services came into their own much later. To be sure,data telecommunication (in the form of smoke signals and other visual semaphoreschemes, for example) has been around for a very long time. Note also that the tele-graph preceded the telephone, and that innumerable messaging schemes of all sortshave been devised and used for military purposes. Morse code telegraphy is an inter-esting example of a data service: this scheme for electrical transmission of text mes-sages was commercially viable before telephony became available.

In scale of deployment, however, telegraph service never came close to the levelsubsequently reached by telephony. The average person in a developed country hasdirect access to telephones at home and at work. Moreover, this has been the casefor many years; nowadays, wireless telephones add mobility to the equation.

Data telecommunication became common in the consumer market only withinthe last 10 to 20 years. Uptake in the academic and business communities camesomewhat earlier (but still much later than voice). Thus voice networks werealready ubiquitous when data networking technologies reached mass-market scale,and it was perfectly natural to ask whether one could also use these networks totransmit large volumes of data between distant sites.

In a nutshell, the question was:

“We have extensive voice networks; are they useful for carrying data as well?”

The answer to this question was definitely “Yes!” The biggest reason for thisresounding affirmative was that, starting in the 1960s, the voice network in theUnited States evolved from analog to digital. In other words, this network wasalready transporting bits.

For years, data networks were islands in a voice-based world. Data networkingtechnologies designed for so-called local area networks (LANs) suffered from severedistance limitations. Long-haul data transmission in the consumer, academic andbusiness markets was achieved using networks initially designed for voice. In fact,telephone carriers’ networks provided the only viable means of interconnecting dis-tant data networks. In many instances, data traffic is still transported in this fashion;fax and dial-up modem transmissions are familiar examples. Widespread access todedicated wide area data networks (such as the Internet) is a relatively recentphenomenon.

1

Dedicated data networks are increasingly common and far-reaching, however.This begs the following question: “We have extensive data networks; are they usefulfor carrying voice traffic?” (Although voice telephony is our primary focus in thisbook, note that the question remains equally pertinent for other real-time servicessuch as videoconferencing.)

Today, telephone networks and data networks are very different beasts,designed according to different philosophies. Here is a crucial distinction to keepin mind:

• In traditional telephone networks, transmission capacity is meted out in a con-tinuous fashion. That is, a fixed amount of capacity is allocated to each calland deallocated when the call ends. Meanwhile, this transmission capacitycannot be shared with any other call (even when the parties on the first call aresilent). We say that traditional telephone networks are circuit-switched; herethe term circuit refers to the end-to-end transmission capacity that is reservedthroughout the life of a call.

• In data networks, transmission capacity is allocated in a discrete fashion. Sup-pose two pairs of users are conducting ongoing sessions that use a sharedtransmission link. When transmission of a packet for one session is completed,the other session can transmit a packet, although neither session has ended.Here a packet is a chunk of digital data (i.e., a sequence of bits); we say thatdata networks are packet-switched.

Note that these are somewhat oversimplified in the interest of brevity.

1.2 Motivation: What Is the Case for Packet Telephony?

1.2.1 One Network Versus Two

To understand why there is a great deal of interest in packet telephony, one needlook no further than the corporate environment. A typical office site has two com-pletely separate in-building networks: a circuit-switched network for telephones anda packet-switched network for computers. The latter is called a local area network.Each of these networks must be provisioned and maintained. Could we combinetelephone and data traffic on one of the two networks (thereby allowing us to reducecost by eliminating the other network)?

Of the two in-building networks, the computer network undoubtedly has muchgreater bandwidth than the phone network. Thus, if we try to interconnect our com-puters via the phone lines (abandoning the local area network), there is essentiallyno hope of a satisfactory result.

Therefore, if we want to dispense with one of the two networks, eliminating thein-building phone network is the only reasonable choice. And this option entailsplacing voice traffic over a packet-based medium.

The situation is substantially different in the consumer market. A local tele-phone company that already has a revenue-producing “legacy” voice network haslittle motivation to invest in voice over packet technologies. However, cable

2 Introduction

companies might become interested in doing just that, so as to compete with localtelephone companies. In recent years, cable companies have upgraded their net-works so they can provide broadband Internet access. In the process, cable hasbecome a bidirectional packet-based medium, suitable for packet voice traffic. Wenote that, as of this writing, cable telephony has not taken off (at least in theUnited States).

1.2.2 Services

Packet telephony solutions must provide some economic benefit (that is, increasedrevenue and/or reduced cost); otherwise, they will not be widely deployed. We havealready begun to address reduced cost with our previous example. We will return tothis topic later, exploring the service provider’s point of view.

Now we look at revenue generation. To increase revenue, a telephone serviceprovider must add new customers (and this is becoming increasingly difficult) ormust come up with new features that customers will want to buy. This brings us tothe development of enhanced services.

As an example, we look at “find me/follow me” services. The basic idea of findme/follow me is a simple one: to offer flexible configuration options for call-forwarding behavior on a per-user basis. Suppose, for example, a traveler wantscertain callers (identified by calling party numbers, say) to be able to reach him/hervia automatic forwarding from his/her landline phone to a wireless phone. All othercalls will be forwarded to voice mail. Such features are offered by today’s PrivateBranch Exchanges, but are not generally available to consumers.

Moreover, it is easy to envision useful “add-on” functionalities that are difficultto implement in today’s networks. For example, it would be nice if one could config-ure out-of-office settings for voice mail and e-mail from the same menu, perhapsemploying a speech-to-text processor to convert the voice mail greeting to a textmessage that is automatically sent in reply to incoming e-mail messages.

Other desirable options include the ability to reconfigure (wireline) forwardingoptions from a wireless phone. This is difficult partly because wireless and wirelinenetworks grew up separately; so-called “Intelligent Network” features in the tworealms are based on different signaling protocols. (We flesh out this topic in Chapter13.) Moreover, with the User Interface limitations of today’s phones, subscribersmay find such features difficult to use. Admittedly, packetized voice does not auto-matically bring about “convergence” between wireless and wireline networks.Well-designed service control schemes that can cross network boundaries, however,may facilitate convergence. Therefore such schemes promise to be an important partof the overall evolution toward packet telephony.

1.3 Switch Design

Packet voice equipment is available and in use today, so packet-based telephony iscertainly feasible. If people only wanted to call others located in the same buildingas themselves, the case for packet telephony in the corporate environment would beoverwhelmingly positive.

1.3 Switch Design 3

In reality, one of the best features of existing telephone networks is that it ispossible to call almost anyone. To maintain this universality, interworking with theoutside world is a must. This boils down to interworking with circuit-switched net-works, since the vast majority of telephones today are connected to circuit switches.In particular, circuit switching is utterly predominant in public telephone networks;packet voice is only just beginning to make inroads in this market.

How should packet voice switches be designed? This is one of the main topicsof discussion in this book. Specifically, we will talk extensively about the telcoenvironment and design principles that are expedient for operating in this environ-ment. In this context, we will draw comparisons with legacy voice switches. Wenote that the design principles discussed here are equally applicable to cable opera-tors, if and when they decide that they want to become large-scale telephone serviceproviders.

1.3.1 Separating Bearer and Control Planes

The separation of bearer and control planes is a fundamental concept in next genera-tion switch design. The bearer plane is the part of the network that carries end-usertraffic (e.g., voice samples, in the case of telephony). As the name suggests, the con-trol plane is the part of the network that carries call-control signaling. In circuitswitches, the bearer and control planes are not clearly separated.

In a nutshell, the reason for separating the bearer and control planes is the prom-ise of increased flexibility. This flexibility can take several forms, notably:

• Distributed architecture. A rich set of options for placement of switch compo-nents: the elements of a switch can be geographically dispersed.

• A rich set of options [based on packet technologies such as Internet Protocol(IP), Asynchronous Transfer Mode (ATM) and Ethernet as well as sophisti-cated vocoders] for representing, encapsulating, routing, and transportingvoice traffic.

• The ability to base the creation and implementation of new services on stan-dardized open interfaces. This is an important step toward the “holy grail” ofservices that combine voice, video, and data in useful ways.

• Flexibility in choosing suppliers. That is, different components can potentiallybe purchased from different equipment vendors.

We will return to these topics in the Section 1.4 (where we argue that theseadvantages make a compelling case for packet telephony) and elsewhere.

At this point, the reader can begin to see that packet telephony is much morethan replacing circuit-switched bearer channels with packet-switched alternatives. Itis possible to build switches that internally employ packet bearers, but for all intentsand purposes act exactly like circuit switches. There is a place for such technology.However, we will see that next generation switching concepts hold the potentialfor much more.

4 Introduction

1.4 Motive and Opportunity for Carriers

Why would a telephone service provider want to invest in voice over packet technol-ogy? We saw one reason in Section 1.2: to enable enhanced services (and therebyrealize new revenue streams). In the following example, the goal is to reduce cost.

We said earlier that separation of bearer and control allows for the componentsof a switch to be geographically dispersed. To see why this is important, we directthe reader’s attention to Figure 1.1. (The fabric of a switch is the conduit throughwhich voice samples flow from the calling party to the called party and vice versa.Each area in the figure might represent a local switch, along with all of the custom-ers that are homed to that switch, or a private branch exchange, etc.) Note thatareas 1 and 2 are not directly connected. Therefore, when a customer in area 1 callsa customer in area 2, the bearer path must include the nearest switch that connectsto both areas (switch A in this example). If areas 1 and 2 are much closer to oneanother than they are to switch A, then we are faced with so-called “backhaul”costs. That is, the voice- encoding bit stream must travel the long way around for theduration of the call.

Suppose that the volume of traffic between areas 1 and 2 is not sufficient to jus-tify either of the following alternatives:

• Reserving dedicated transmission capacity between areas 1 and 2;• Installing an additional switch closer to areas 1 and 2.

Suppose, however, that the volume of traffic is large enough that it grieves us topay for backhaul transmission capacity. If, by shifting to a distributed design, wecould dramatically reduce the cost of adding switching capacity at a nearby loca-tion, then we would have a viable alternative.

In Figure 1.2, we illustrate the notion that the fabric under the command of agiven controller can consist of geographically-dispersed nodes. If these fabric nodesare very inexpensive (relative to the cost of a “legacy” voice switch), and if one con-troller can direct the operation of many fabric nodes, then the cost of introducingswitching capacity to new locations can indeed be reduced a great deal.

Note that a new type of traffic appears in Figure 1.2: control messages betweenthe controller and the fabric component at location B. (The Controller also sendscommands to the colocated fabric component at location A, but these messages donot require interlocation transmission facilities.)

1.4 Motive and Opportunity for Carriers 5

Fabric

Controller

Switch A

Bearer path

Area 2

Area 1

Figure 1.1 Bearer path must traverse closest switch.

We note that the example presented here is oversimplified in a number of ways.In particular, we have glossed over the following matters:

• How are fabric components interconnected?• What kinds of instructions does the controller need to send to the fabric

components?

We will return to these considerations in the main body of the book. Meanwhile,we think that the example of this section offers a useful way (though not the onlyway) to think about next generation switching architectures: one controller com-mands numerous fabric elements. The controller possesses sophisticated call controlfunctionality (and the resident software is likely to be expensive), whereas the fabricelements are not very smart (but are relatively inexpensive). Although we hold thenotion of a distributed fabric as an idea whose time has come, distributed call proc-essing is very difficult—thus the centralized controller.

1.5 What Are We Waiting For?

If it offers such wonderful advantages, why not enter the brave new world of packettelephony right away? In our mind, the reason is that existing voice technologyevolved over a long period of time. As a result of many years of growth and refine-ment, today’s circuit-switched networks:

• Are optimized for voice. Today’s telephone networks are designed to delivervoice samples from origin to destination switch at very regular intervals, andto do so quickly (i.e., utterances are recreated at the listener’s end very soonafter they leave the speaker’s mouth). Moreover, today’s voice networks canset up calls quickly—when placing a call, one does not have to wait very longfor the called party’s phone to ring, or to begin a conversation once the calledparty answers. The capabilities listed in this bullet are often associated withthe blanket term quality of service (QoS).

• Possess a labyrinth of functionality that is difficult to duplicate in a short spaceof time. This ranges from schemes that keep call-control processing capabili-ties from “overheating” when congestion occurs to complex billing systems.

6 Introduction

Controller

Location A

Location B

Control trafficBearer path

Fabriccomponent A

Fabriccomponent B

Area 2

Area 1

Figure 1.2 Distributed fabric.

The list, which also includes integration of a variety of applications withTouch-Tone signaling, literally goes on and on.

• Are successfully deployed on a very large scale. Most things are more difficultto acheive on a large scale than on a small scale—think of coordinating sched-ules of a large number of people or keeping a major airport running smoothly.Telephony is no exception; over the years, telcos and their network infrastruc-ture manufacturers have turned scalability into an art.

• Are extremely reliable.• Represent an enormous investment of capital.

For all of the reasons listed, equipment in existing voice networks will remain inuse for a long, long time. Thus packet voice switches will have to interwork grace-fully with legacy equipment. We will see that this requirement is far from trivial—itis one of the main hurdles that must be crossed before packet telephony can gaina foothold in service providers’ networks. This hurdle is economic as well astechnical.

In fact, collecting voice samples and stuffing them into packets is the easy part.This is not to belittle the development that went into making this possible. Rather, itis meant to indicate that digital signal processing techniques have advanced to thepoint where this “encoding and encapsulating” step is well understood and, moreo-ver, can be accomplished in a cost-effective way. Traditionally, data networking hasnot emphasized quality of service. In recent years, much attention has been devotedto quality of service in packet networks. It is certainly possible to achieve good voicequality and low latency in the packet domain. But the telecommunications industryas a whole is still struggling to find the formula for realizing this goal on a large scaleand at a palatable cost.

To be fair, packet voice deployments are beginning to happen, and we believethat they will eventually happen on a truly large scale. However, widespreaddeployment will take time.

1.6 Motivation for this Book

Off and on since 1998, we have worked on projects investigating packet voice tech-nology. We often wished that we could find an expository introduction to the topic(especially when we were new to the subject). Our first purpose is to set forth suchan exposition, focusing on architectural design of packet voice switches. We take onthis task in Part I, taking care to introduce as little technical terminology as possible(and trying especially hard to avoid acronyms). We hope that this portion of thebook is accessible to readers who do not have engineering backgrounds, as well asthose who do.

In Part I of this book, we will see that the new paradigm draws on manyareas that used to be disparate—at one time, it would have been very surprisingto hear mention of data-network protocol stacks in the “same breath” as newvoice-encoding techniques. This is no longer such an unusual juxtaposition, as thesedevelopments find common cause in next generation switching products.

1.6 Motivation for this Book 7

Our second purpose, which is served in Part II, is to provide information onsome of the disparate technical areas that are such newly-acquainted bedfellows.This book is not encyclopedic and is far from being the last word on the technicaltopics that we cover (many of which merit entire books on their own). Our aim inintroducing these topics is to flesh out the view of packet voice switches that wedevelop in the early part of the book. To this end we highlight essential features ofeach technical topic, and provide pointers to other sources for in-depth coverage.The technically-oriented portion of this book will likely be of greatest interest toreaders who have engineering backgrounds. Our intention is that the “prereq-uisites” for reading this book are nonspecific, however. Many people have goodknowledge of telephony but not of data networking, or extensive knowledge of datanetworking but not of telephony. Others may have had limited exposure to bothtopics, but find that they are interested in the subject of this book because they arestarting to hear about Voice over Internet Protocol. We hope that technicallyinclined people of all stripes will find useful information here.

Last but not least, we hope to give the reader some insight regarding thedifficulty of migrating from circuit-switched telephony to packet telephony. Weemphasize that this difficulty is economic at least as much as it is technical; its scalehas often been underestimated in the past. Throughout the book, our mindset istilted toward large-scale deployments and interworking with existing public tele-phone networks.

When we were first exposed to the arguments of Sections 1.2 and 1.4, we were“rarin’ to go.” That was several years ago, and carriers have been very slow to adoptthe new paradigm in the intervening time. Although there are many compellingplusses for packet telephony (and surely they would win the day if we were buildingnetworks from scratch), there are also many reasons why large telephone serviceproviders’ interest in packet telephony has been tepid.

We touched on some of the barriers to migration in Section 1.5, and will elabo-rate on these barriers as the discussion progresses. We believe that, if we can imparta sense of the sheer enormity of the undertaking, then readers can more accuratelyenvision the new paradigm’s road to economic viability.

8 Introduction

P A R T I

Switching Architectures for PacketTelephony: An Expository Description

C H A P T E R 2

Essentials of Next Generation Switching

This chapter is organized as follows. After introducing a minimum of terminology,we begin with a reexamination of the backhaul example from Chapter 1. This is fol-lowed by a variation on the backhaul example. At that point, it becomes expedientto define a number of industry-standard terms. Then we recast the backhaul exam-ple in the new nomenclature.

Distributed Architecture

In this book, the term distributed architecture refers to the idea that the physicalcomponents of a switch may be geographically dispersed, yet they function in acoordinated way: to the outside world, they are seen collectively as a single logicalentity.

Switches and Switching Fabrics

We normally think of a transmission link (or simply a link) as something that is sub-divided into channels. Our emphasis in the current discussion is on telephony, so achannel can be defined as transmission capacity for one voice call. (In multiservicenetworks, one must think in more general terms, although similar concepts can beapplied.)

For our purposes, a switch is a device with the capacity to dynamically directtraffic from any input link to any output link on a per-channel basis. We canrephrase this as follows: a switch is a device with the ability to dynamically “crossconnect” any input channel with any output channel. The fabric is the conduitthrough which traffic flows between input channel and output channel. (Althoughvoice channels are bidirectional, we can make sense of “input” and “output” byagreeing that the input channel is on the same side of the switching fabric as thecall’s originating party and the output channel is on the destination side.)

Throughout our discussion, we distinguish between bearer traffic and call-con-trol signaling traffic. Recall from the introduction that bearer traffic is the trafficgenerated by end users (we think primarily of voice samples in the case of telephony;for completeness, we also include fax transmissions and other voiceband dataapplications).

11

2.1 Another Look at the Backhaul Example

Recall that, in the backhaul example, the volume of traffic between areas 1 and 2 isnot sufficient to justify dedicated area 1 ↔ area 2 transmission capacity. So thebearer path for each area 1 ↔ area 2 call must traverse a switch that connects toboth areas. In our example, the closest switch (switch A, that is) is far away, relativeto the distance between areas 1 and 2. In Figure 2.1, we have redrawn the originaldiagram (see Figure 1.1) to include transmission facilities. The voice-encoding bitstream must travel to switch A and back throughout the duration of the call. This istrue even if (as shown in the figure) the area 1 ↔ switch A and switch A ↔ area 2portions of the bearer path use the exact same transmission facilities for part of theway. The point is that, in this example, the multiplexing equipment that groomsboth of these segments onto the same transmission facility (labeled “Mux” in Figure2.1) does not have switching capability or intelligence.

Let us suppose that areas 1 and 2 are not the only users of switch A’s capabili-ties, but that many more “areas” residing on the opposite side of switch A also con-nect to it. (These additional areas are not shown so as to keep the diagrams simple.)Thus the transmission capacity that is reserved for traffic between area 1 and switchA may be well-utilized even if calls between area 1 and area 2 are rare (because it car-ries traffic headed for many other final destinations in addition to area 2). The sameholds for reserved capacity connecting area 2 and switch A.

The configuration illustrated in Figure 2.1 is not unreasonable at all: if the vol-ume of traffic between areas 1 and 2 is small, this configuration will be less expen-sive than the alternatives. Two of these alternatives are:

• Reserve dedicated transmission capacity between areas 1 and 2. The problemwith this alternative is that the transmission facilities set aside for this purposewill tend to be poorly utilized if traffic volume between areas 1 and 2 is low.

• Install an additional switch at location B. The problem with this alternative isthat voice switches tend to be very expensive (much more expensive than mul-tiplexers, for example).

We can summarize the statement that backhaul to A is the least-expensiveoption (for low volumes of area 1 ↔ area 2 traffic) via the “inequalities”

cost(xmission to switch A) < cost(dedicated area 1 ↔ area 2 xmission capacity).

12 Essentials of Next Generation Switching

Controller

Switch A

Location B

Mux

Bearer planeconnectivity

Bearer path

Fabric

Area 2

Area 1

Figure 2.1 Backhaul example showing transmission facilities and multiplexing equipment.

and

cost(xmission to switch A) < incrementalCost(additional switch at location B).

If the volume of traffic between areas 1 and 2 increases steadily, then we willeventually reach a “crossover point” beyond which one or both of our inequalitiesare reversed.

One interpretation of the distributed approach is that it attempts to lower thiscrossover point by decreasing the right-hand side of the second inequality above. InFigure 2.2, we move to a geographically-dispersed configuration in which the fabriccomponents at locations A and B are both under the command of the controller atlocation A. We repeat the following observation from the introduction: if the fabricnodes are very inexpensive (relative to the cost of a circuit switch), and if one con-troller can direct the operation of many fabric nodes, then the cost of introducingswitching capacity to new locations can be dramatically reduced.

Figure 2.2 shows that control traffic must flow (over inter-location transmis-sion facilities) between the controller at location A and the fabric component atlocation B. Note that, in contrast to bearer traffic, control traffic does not flow con-tinuously throughout the life of the call.

Before moving on, let us make a few observations about Figure 2.2. In all cases,when a user in area 1 wants to call someone in area 2 (or vice versa), a connectionrequest must be dispatched to the controller at A. Then the Controller at A mustinquire about the availability of the destination user, and so on (for simplicity, thiscall-control signaling traffic is not shown in the figure). So even though the configu-ration of Figure 2.2 eliminates bearer backhaul between location B and location A,signaling traffic must still be transported to a controller. Certainly, we still gainsomething, because signaling traffic is much less voluminous than bearer traffic.

2.2 Ability to Enter New Markets

Here we imagine that Figure 2.2 arises via a different line of reasoning than that ofthe previous section. More specifically, suppose that a service provider initially doesnot offer service to customers in areas 1 and 2. Our service provider wants to enter

2.2 Ability to Enter New Markets 13

Controller

Control traffic

Location B

Location ABearer plane connectivity

Bearer path

Fabriccomponent A

Area 2

Area 1

Fabriccomponent B

Figure 2.2 Distributed fabric revisited.

the new market represented by these areas, but in the past, there has been achicken-and-egg problem. That is, the provider could not afford to install switchingequipment near these locations without the existence of a revenue-producing cus-tomer base, but could not build a customer base without the presence of switchingequipment. (Here we are assuming that the distance between locations A and B is solarge that backhaul is economically impractical.)

Distributed switching could lower the barriers to entering the market repre-sented by areas 1 and 2. As in Section 2.1, this is predicated on the assumption thatfabric components are inexpensive.

2.3 Switch Components and Terminology

Up to this point, we have made a concerted effort to introduce as little terminologyas possible. Now that the reader has had a chance to absorb some of the main con-cepts of next generation switching, we introduce a number of terms that will facili-tate further discussion. Many of the concepts we have covered (especially separationof bearer and control) are often associated with the term “softswitch.” Therefore wefind it convenient to make liberal use of softswitch terminology. In this book, we usethe terms softswitch and next generation switch interchangeably.

In our view, there are four essential softswitch functional components:

1. Media gateway controller. This is the brains of the operation; it directstraffic (but bearer traffic does not actually pass through the media gatewaycontroller—that is, the role of the media gateway).

2. Media gateway. Bearer traffic enters/exits the switch fabric via this device.This device often (but not necessarily always) performs conversion betweenformats (e.g., between circuit-switching and packet-switching formats, orbetween different voice encoding schemes, or both).

3. Signaling gateway. Call control signaling traffic (between the switch and theoutside world) enters/exits the switch via this device.

4. Intergateway switching fabric. Bearer traffic travels from ingress mediagateway to egress media gateway via this fabric.

The first thing to notice about this breakdown is that bearer and control are, infact, separate. Note also that this taxonomy divides the switch into functional com-ponents; the subdivision into physical components need not be the same. For thetime being, we are avoiding detailed discussion of call control signaling. Thus wewill not clarify the motivation for listing the signaling gateway as a separate compo-nent until a subsequent chapter. Meanwhile, the signaling gateway will appearalongside the media gateway controller in our diagrams. For now, the reader maywant to make the simplifying assumption that these two components are colocated.

2.3.1 Where Does One Switch Component End and Another ComponentBegin?

We caution the reader that subtleties are often encountered when one attempts to“draw the boxes” (i.e., map the functions given in the conceptual framework


previously mentioned to a group of network elements). In particular, the followingquestions are difficult to answer cleanly:

• Exactly how should we define the fabric of a next generation switch?• When a media gateway and its controller exchange control messages, do these

messages travel through the switch fabric?

2.4 A Useful Abstraction

We will approach these questions by drawing analogies with traditional circuitswitches. Figure 2.3 is a simplified representation of a circuit switch. The portsshown in the figure are receptors where transmission links can be attached. The fab-ric is marked with a large “X” shape to remind the reader that it has the capacity todynamically connect any pair of channels. These cross-fabric connections are set upand torn down at the behest of the controller.

In a sense, we can view a media gateway as a (set of) port(s) on a distributedswitch. This is a useful abstraction, but one must take care to realize that the anal-ogy only holds up to a point: media gateways may (and often do) incorporate somedegree of switching fabric functionality. On the other hand, ports (or multiport linecards) on circuit switches tend to have minimal functionality; in particular, linecards are often “fabricless.” Remote line frames, which often incorporate small fab-rics, constitute a notable exception.

There is a good reason why media gateways tend to incorporate switching fab-rics- we need look no further than the backhaul example. To emphasize this point,we redraw the picture one more time in Figure 2.4 (see Figure 2.2). The shaded por-tion of each Media Gateway is part of the switch fabric; the figure is drawn so as toremind the reader that the bearer path must always traverse the switching fabric.

In addition to housing a fabric component and ports that connect to the outsideworld, each media gateway also serves as a bearer interworking function. Recallthat media gateways serve as ingress/egress points between two realms: that is, therealm that is external to the switch and the realm that is internal to the switch. Inmany, if not most cases, bearer traffic is represented and handled differently within

2.4 A Useful Abstraction 15

Ports

Fabric

Controller

messagesControl

Figure 2.3 Schematic representation of a circuit switch.

the two realms. The interworking function often involves translation betweenpacket and nonpacket formats (although it can involve translation between two dif-ferent packet formats instead). Another common aspect of the interworking func-tion is translation between voice-encoding schemes. Note that we regard the mediagateway ports facing the external realm as part of the interworking function.

2.5 Defining the Fabric

All of the media gateways in a softswitch must be interconnected. That is, it must bepossible to set up a bearer path connecting any pair of media gateways. (Recall ourdefinition of a switch: a device with the ability to dynamically connect any inputchannel to any output channel.) When its media gateways reside in multiple loca-tions (as is usually the case), the fabric of a softswitch has to be a distributed entity.

We define the fabric of a softswitch (or simply distributed fabric) to be the fabriccomponents of its media gateways together with the interconnections between themedia gateways.

According to the definitions in Section 2.3, the interconnections between themedia gateways are lumped together under the term intergateway switching fabric.The topology of the intergateway switching fabric can be simple or complex. As anexample of the former, we show only two media gateways in Figure 2.4, so theintergateway switching fabric could simply be a single point-to-point connectionbetween the two gateways.

If the number of media gateways is large, a full mesh of point-to-point linksbetween gateways becomes expensive, and it may be expedient to use one or morepacket switches to interconnect the gateways more efficiently. In Figure 2.5, we givean example; this figure is more representative in that it reflects the possibility thatpacket switches may be part of the intergateway switching fabric.

There is a “switch within a switch” aspect at this point in the discussion thatcould become confusing. We will refer to the “big” switch as a softswitch or nextgeneration switch and its fabric as a distributed fabric. This will serve to distinguishthe softswitch from any packet switch that serves as a component of the distributedfabric.


Location A

Media gatewaycontroller

Signalinggateway

Distributed fabricLocation BArea 2

Area 1 Control traffic

Bearer path

Mediagateway A

Mediagateway B

Figure 2.4 Backhaul example with components relabelled.

In any case, devices in the softswitch-external realm (e.g., circuit switches orother softswitches) are unlikely to know or care about the topology of the intergate-way switching fabric. Let us appeal once again to our analogy between softswitchesand circuit switches. In the case of a circuit switch, an external device might knowthat a given input channel (on port A, say) is connected to a particular output chan-nel (on port B). But it knows nothing about how port A and port B are connected tothe switch fabric, whether the switch fabric resides on one or many circuit boards,and so on.

Conversely, packet switches in the intergateway switching fabric may not evenknow that they are part of a larger entity: all of the interworking with external tele-phone network entities is handled by other components of the encompassing nextgeneration switch.

Packet switches in the intergateway switching fabric may come from differentmanufacturers than other parts of the softswitch (e.g., the media gateways and theircontrollers). These packet switches may carry data traffic that the media gatewaycontroller does not know about, and that does not traverse any media gateway. Forsimplicity, however, the packet switches in Figure 2.5 are depicted as fully con-tained within the softswitch’s distributed fabric.

The terms media gateway, media gateway controller and signaling gatewayare all part of the industry-standard parlance. The term inter gateway switchingfabric is one we have not seen before (but we need to refer to this component bysome name).

2.5.1 Do Control Messages Between Media Gateways and Their ControllerPass Through the Switch Fabric?

The answer to this question is a qualified “yes, provided that we are not too doctri-naire about separation of bearer and control.” Each media gateway must talk to itscontroller. This communication could take place via a point-to-point link. How-ever, we have already seen that packet switches can provide a viable alternative tothe assortment of point-to-point links that would otherwise be necessary when thereare many media gateways that share the same controller. It is reasonable to

2.5 Defining the Fabric 17

Packet switchMediagateway

Mediagateway

Mediagateway

Mediagatewaycontroller

Signalinggateway

Distributed fabric

Physicalconnectivity

MediagatewayPacket switch

Figure 2.5 Schematic representation of a next generation switch.

interconnect media gateways and controllers via the same packet switches used forbearer traffic. So, in a sense, control messages do pass through the fabric of our nextgeneration switch. However, there is an important distinction to keep in mind whichwe now explain.

The controller instructs the media gateway regarding allocation and dealloca-tion of bearer channels across the distributed fabric as calls come and go. We canthink of this dialog as taking place on a quasi-continuous, permanent basis. The per-manence of the control association between media gateways and their controllerscontrasts with the dynamic nature of bearer channels. Lastly, note that we maintaina logical separation of bearer and control even when bearer and control traffic sharecapacity on the same packet switches.

With the preceding comments in mind, we have redrawn the schematic switchrepresentation to include control traffic in Figure 2.6 (see Figure 2.5).

2.5.2 What Is a Packet?

A packet is a chunk of digital data with a header. The following types of informationare often included in packet headers:

• Field(s) indicating where the packet is supposed to go and/or who is supposedto receive the packet.

• Field(s) indicating what sort of treatment should be afforded to the packet(e.g., an indicator of whether this is a high-priority or low-priority packet).

• Field(s) indicating how the payload of the packet should be interpreted byhigher-layer protocols. This is a fancy way of saying that the packet mustbe marked so that the end recipient can tell what it contains (e.g., a voicesample, a video streaming sample, a control message) and process the contentsaccordingly.

• A field indicating the size of the packet.


Packet switch

Physical connectivity

Signaling path

Mediagatewaycontroller

Signalinggateway

Distributed fabric

Mediagateway

Mediagateway

Mediagateway

Mediagateway Packet switch

Figure 2.6 Next generation switch with signaling paths.

Although the question “what is a nonpacket?” sounds a bit silly, we include aword here about the distinction between circuit switches and packet switches. Cir-cuit switches determine where to send any given byte of data according to when thatbyte of data arrives. Packet switches determine where to send a given packet of dataaccording to information in the packet header. (Thus the first item in the previouslist of packet header information types is essential.)

2.5 Defining the Fabric 19

C H A P T E R 3

Motivation for Packet TelephonyRevisited

Owing to its flexibility, the potential benefits of next generation switching technol-ogy are wide-ranging. It is a challenge to capture all of the benefits within a coherentand well-organized framework. On the other hand, the main ideas behind the nextgeneration switching philosophy are not very complicated, provided that they areapproached in the right way. Our approach in this chapter revolves around the fol-lowing question: “What can a service provider hope to gain by shifting to the newparadigm?”

Next generation switching architectures are heavily influenced by the softswitchphilosophy. The main features of the softswitch paradigm are:

1. Functional separation of bearer and control;

2. Distributed architecture;

3. Packet fabrics for bearer traffic.

For each of these features, pratical realizability is heavily dependent on the exis-tence of open standards. Without open standards, next generation switches wouldend up being geographically-dispersed “black boxes” and would be very difficult totroubleshoot (for anyone but the equipment manufacturer, that is).

In Table 3.1, we list advantages offered by features 1–3 above. Of course, theseadvantages must translate into economic benefits somewhere along the line: in theabsence of a significant economic incentive, most service providers will stick withfamiliar technology. Although we do not attempt to quantify the potential eco-nomic benefits of next generation switching in this book (and, indeed, particulars ofcost studies will vary from one carrier’s network to the next), we ask the reader tobear these considerations in mind.

In the following discussion, the term “distributed architecture” refers to theability to geographically separate the components of a switch. We have alreadyexpounded on the benefits of distributed architecture in the previous chapter. In thischapter, we therefore devote most of our attention to the other topics in Table 3.1.

3.1 Separation of Bearer and Control

Clearly, separation of bearer and control is a prerequisite for the distributed archi-tecture discussed in Chapter 2. (Recall the “paradigm” example of Figure 2.5: a sin-gle controller controls several geographically dispersed media gateways.) That is,

21

functional separation of bearer and control is necessary if we are to achieve thephysical separation of bearer and control that was crucial to the motivation we pre-sented in Chapter 2. We now argue that functional separation itself promises addi-tional benefits.

Referring to legacy voice switches, we said in the introduction that “bearer andcontrol planes are not separated within the switches themselves.” We may have lieda little bit: like computers, voice switches are modular, and it would be quite naturalto build separate bearer and control modules. The point we are trying to make, how-ever, is that these two modules have essentially always been packaged together. Weare propounding a philosophy that says we want to pry them apart:

• It should be possible to place the control and bearer modules in different geo-graphic locations. (Here we are plugging the concept of distributed architec-ture again.)

• The dialog between the control module and the bearer module should be con-ducted in a message format that is defined by a publicly-available standard.Or, rephrasing this point in the terminology of Section 2.3: The media gatewayand its controller should interwork via an open interface.

3.1.1 Open Interfaces

Many of the interfaces on today’s circuit switches are open (i.e., based on publishedstandards). Here we are referring to interfaces between switch and customer prem-ises (in the signaling and bearer planes) as well as interfaces between two switches(also in both the signaling and bearer planes). This is important to service providers,because it makes multivendor interworking possible. That is, equipment producedby different manufacturers can be interconnected and can cooperate in completingcalls. So it is natural to ask whether an open controller-to-fabric interface wouldyield similar benefits. (Today’s circuit switches do not feature open interfaces here;this is shown schematically in Figure 3.1.)

Let us develop this idea a little further. With open interfaces paving the way formultivendor interworking, a service provider could purchase controller and fabricfrom different suppliers. Most of a switching fabric’s functionality is implemented inhardware. Controllers, on the other hand, are full of software processes that

22 Motivation for Packet Telephony Revisited

Table 3.1 Next Generation Switches: Main Features and Associated Benefits

Feature Description of Benefits

Distributed architecture Transmission bandwidth efficiency (as illustrated by the reducedbackhaul example); ability to enter new markets with reduced ini-tial investments.

Functional separation ofbearer and control

Ability to evolve and maintain bearer and control elements sepa-rately; ability to interwork bearer and control elements from differ-ent suppliers. This feature is a prerequisite for distributedarchitecture.

Packet fabrics forbearer traffic

Ability to exploit routing intelligence of packet netwrks; ability toexploit low bit rate encoding schemes to reduce transmission band-width requirements.

exchange messages with other call-control devices and keep track of each call’sstate. So it would be sensible for software companies to make controllers and hard-ware companies to make fabrics. (The controller software might reside on a com-puter, such as a high-availability workstation, that is resold by the softwarecompany.)

Even if a service provider chooses to buy media gateways and controllers fromthe same manufacturer, open interfaces are desirable for more than simply philo-sophical reasons. First of all, the availability of a standard may make it more palat-able for an equipment vendor to port its controller functionality to a commerciallyavailable workstation, rather than continuing to manufacture dedicated controllerhardware.

Moreover, the process of developing a communication protocol requires clearrole definitions for the elements that will conduct dialogs using that protocol; thisimposes a certain discipline in the developers’ collective thought process that helpsto produce cleanly-executed designs.

In the current context, a standard needs to specify exactly what kinds of things amedia gateway controller can ask a media gateway to do, and to abstract theserequests into a generic set of messages, parameters, and so on. This goes hand inhand with an effort to specify exactly what sorts of things a media gateway shouldbe able to do, both now and in the foreseeable future. The task we are describing isnot a simple one, but if it is done well, the resulting flexibility in creating new serv-ices can be enormously profitable. We discuss the two leading standards for mediagateway control, MGCP and Megaco/H.248, at length in Chapter 10.

3.1.2 Introducing and Maintaining Services

Suppose a service provider wants to change the behavior of a widely-dispersedcollection of switches, and to do so as efficiently as possible. This is exactly what aprovider must do to implement a new revenue-generating service: in almost everycase, enhanced features in the switching network will be required to support thenew service. Therefore, to make sure that a new service quickly becomes profitable,it is important to control the cost of introducing the necessary switching functional-ity. To this end, it would be extremely helpful to “have all of the knobs in one

3.1 Separation of Bearer and Control 23

Open bearer interfaces

Fabric

Controller

Open signalinginterface

interfaceProprietary

Figure 3.1 Interfaces on a legacy voice switch.

place”—that is, to have the power of enhancing the capabilities of an entire collec-tion of switch components by implementing a localized change.

Let us first look at the way new functionality is introduced into circuit-switchednetworks. This has long been a major difficulty for the telecommunications indus-try. To be profitable, a service normally has to be supported by a large number ofswitches, and the functionality needs to be consistent from one switch to another.Only then can the service be marketed to a large population of customers. In whatfollows, we assume that the enhanced features previously mentioned are adminis-tered via upgrades to switch-resident software.

It is very difficult, if not impossible, to perform feature upgrades on manyswitches at once. But whenever an upgraded switch interacts with another switchthat has not been upgraded, the potential for incompatibilities exists. Moreover, if abug is discovered after a new feature is installed on a large number of switches, itmay be necessary to “roll back” each of these switches to an earlier software version.This can be a disastrous outcome.

Because of the difficulties and potential risk associated with such upgrades, serv-ice providers have historically been slow to introduce new services. New featureshave typically been tested thoroughly at a variety of stages on the way to full-scaledeployment. This has meant in turn that services cannot be profitable unless theyhave long useful lifetimes (and/or high adoption rates).

If it were simpler (and less fraught with risk) to deploy new switch features,then:

• In the effort to create new services that customers want, it would be possible toexperiment more freely.

• A given service would not require such a long useful lifetime to be worthwhilefor the carrier.

The next generation approach is promising in this regard: A media gateway’sbehavior is largely determined by its controller, and we have seen that a singlemedia gateway controller can preside over many media gateways. It may seem thatwe are expounding on another benefit of distributed architecture (and that isindeed part of the story here). However, there is more to it than that, as we nowexplain.

The previous paragraph leads naturally to the suggestion that it should be possi-ble to implement a new revenue-generating service via a localized change (that is, asoftware upgrade at a central controller). Moreover, this should be possible evenwhen the new service dictates that a whole collection of media gateways and fabriccomponents act somewhat differently than they did before. This sort of argument isplausible, for instance, if our goal is to implement a new type of call-forwardingbehavior.

The “localized change” in this discussion is really localized in two ways:

• Functional Localization. After the change, the media gateway controllerspeaks to the media gateways in terms of the same primitives that were avail-able before the change. The media gateways operate based on the same set ofcapabilities that they possessed all along.


• Geographical Localization. The software upgrade is only performed in onephysical place.

Although the importance of the former item, Functional Localization, is lessobvious than that of the latter (especially considering the fact that Chapter 2focused on the latter), it is just as crucial to a full appreciation of the next generationswitching philosophy.

Before moving on to the next topic, we note a caveat. The following must betrue if our argument is to hold water, so to speak:

• Assumption: Each media gateway possesses adequate functionality to sup-port a wide variety of potential services.

Conversely, if each new feature requires us to upgrade media gateways as wellas controller software, we are right back where we started. Thus considerable fore-sight must be applied in component design if the promise of the new switching para-digm is to be fully realized.

3.1.3 New Bearer Types

In the last section, the gist of the argument was that we should be able to implementenhanced call-control features in a next generation switch without touching themedia gateways. By the same token we should be able to implement bearer planeenhancements without making major changes to media gateway controllers. Herewe must avoid sweeping statements about the realizability of this goal, however.

When a requirement comes along to support a new type of bearer traffic, itmakes a difference whether it is a new media type, a new bearer protocol, or a newvoice encoding scheme. Suppose, for example, that our softswitch needs to supporta new voice encoding scheme, or codec. This means that bit streams representingvoice signals must be interpreted in a different way at affected interfaces. Let us tryto make the argument that the media gateway controller requires little or no recon-figuration in this case, and see how many assumptions we have to make.

When a new codec is introduced, the switching equipment will require trans-coding capacity—that is, the capacity to convert between the new codec and othercodecs that are already in use. If a switch employs a single codec for all internal traf-fic, then the affected bearer interfaces would be configured to transcode from thenew codec to this common codec (note that this configuration change would belocalized to one or more media gateways). In this case, the amount of capacity percall (within the switch fabric, that is) would remain the same as always. Whereverlinks employing the new codec are connnected to the switch, the media gatewaycontroller presumably must calculate capacity utilization differently than with othercodecs. But the controller would not otherwise have to alter the algorithm it useswhen determining whether to admit each incoming call.

Although the codec employed varies from one interface to another in our exam-ple, we have assumed in the foregoing discussion that any two calls arriving at thesame interface use the same codec. What about call-control messages? They shouldbe essentially the same regardless of whether the new codec is in use in any “leg” of

3.1 Separation of Bearer and Control 25

the bearer channel—each of the switch’s bearer interfaces to the outside world isstatically configured with a codec.

If we make a number of assumptions, as we have done here, we can argue that anew bearer type (in this case a different codec) can be accomodated with limitedimpact on the media gateway controller. If we remove some of these assumptions,however, the argument is harder and harder to make. For instance, if codec selectioncan vary from call to call on the same interface, then added intelligence is required:we have to make decisions about transcoding on a call-by-call basis; determiningwhether to admit calls becomes more complicated because resource utilization cal-culations must now be more sophisticated; and so on.

In later chapters, we will see examples in which the capacity to make transcod-ing decisions on a call-by-call basis would indeed be desirable. For the time being,we will simply remark that we have encountered a fundamental trade-off: the intelli-gence necessary to achieve efficient resource utilization versus the cost of implement-ing that intelligence.

3.2 Packet Fabrics

Here we briefly consider the items that were listed under “Packet fabrics for bearertraffic” in Table 3.1. To do justice to these topics requires some additional back-ground and terminology that we will introduce in Chapters 7 and 9.

3.2.1 Exploiting Routing Intelligence of Packet Networks

Routing in circuit-switched networks is a mixed bag. In local telco networks (at leastin the United States), routing is fixed. That is, the bearer path for any given call ischosen from a preprovisioned list of paths connecting the originating and terminat-ing switches. When a call request comes in, the network checks these paths in a fixedorder, selecting the first one that has available capacity (or responding with a“network busy” signal if it exhausts the list without success). Moreover, the list ofpaths for any given origin-destination pair of switches is usually short (in local net-works, two- and three-item lists are common). From this discussion it is clear thatcalls may sometimes be blocked when there is available capacity in the network, sim-ply because that capacity did not lie along preprovisioned paths for the calls in ques-tion. Administrative intervention is required for networks with fixed routing toadapt to significant changes to traffic patterns.

The big long-distance carriers employ dynamic routing (in proprietary imple-mentations); their routing schemes are altogether more sophisticated than their lan-dline counterparts. We give a brief overview of telco routing (and references toin-depth expository material) in Chapter 14.

Dynamic routing is de rigueur in data networks. Via routing protocol messageexchanges, the elements of a network discover the network’s topology. Suppose forthe sake of discussion that the network elements are Internet Protocol routers (thereare numerous other possibilities). Then we can rephrase this by saying that eachrouter becomes aware of the other routers in the network and of the manner inwhich those routers are interconnected. The idea here is this: if there is unused


capacity in a distributed fabric that could be used to satisfy an incoming call request,the routing protocols should be able to find it.

Today’s data network routing protocols realize this ideal to a limited degree.One major difficulty is load balancing among a multiplicity of desirable routes to agiven destination. Moreover, dynamism can bring on instability. The aforemen-tioned dynamic routing schemes implemented by long-distance telcos incorporatefeatures specifically designed to maintain stability. (The routing algorithms makesure to avoid network states in which an inordinate proportion of traffic is carriedon alternate routes; the reader can consult the description of trunk reservation inSection 14.1.2.) We do not believe that data network routing schemes are as maturein this regard. (We discuss data network routing in Chapter 7 and, to a more limiteddegree, in Appendix A.) In time, packet-switched routing schemes may overcomethese limitations, while being inexpensive to administer.

To underscore the differences between telco routing and data network routing,let us discuss remote line frames for circuit switches. Roughly speaking, one canthink of these devices as small satellite switches. Remote line frames are commonlyused to serve business customers with sizable campuses. In residential markets,remote line frames are also cost effective for serving rural communities thatsurround a sizable metropolitan area. In the second example, one can envisiona full-fledged switch in the metropolitan “hub” area exercising control over“miniswitches” in smaller outlying communities.

Remote line frames incorporate small switching fabrics; the motivation forincluding this functionality can be found in the backhaul example. That is, therationale is exactly the same as for incorporating fabric components in mediagateways. (Here the reader can refer to the discussion in Section 2.4, culminating inFigure 2.4.)

In Figure 3.2, we depict two bearer paths. The significance of the shaded box isthat it encompasses all components of the switching fabric. The first bearer pathconnects a user in area 1 to a user in area 2. Due to the presence of a fabric compo-nent within remote line frame A, the path does not have to traverse the central fabriccomponent.

The second bearer path in Figure 3.2 connects areas 1 and 3. The way we havedrawn our example, this path must go through the central fabric component, even ifthe two remote line frames are much closer to one another than either is to the

3.2 Packet Fabrics 27

Central fabric

Controller

Bearer pathArea 3

Remote lineframe B

Area 2

Remote lineframe A

Area 1

Figure 3.2 Legacy switch with remote line frames.

controller/fabric complex shown in the upper right hand corner of the diagram.While it is not out of the question to offer direct connectivity between line frames Aand B, circuit switches are not usually configured in this way. Such a direct intercon-nection would have to be “nailed up” and manually configured. Typically, the onlysort of bearer connectivity that is supported is that of a hub-and-spoke configura-tion as exemplified in Figure 3.3.

To keep the diagrams simple, we have omitted signaling traffic from Figures 3.2and 3.3. For completeness, however, we note that signaling traffic between a remoteline frame and its controller is carried on a point-to-point link. Thus, switch-internalsignaling traffic hews to the same hub-and-spoke topology as bearer traffic, exceptthat the controller is now the hub component.

Let us contrast the limitation illustrated in Figures 3.2 and 3.3 with the flexibil-ity of a next generation switch. In the latter, the fabric components can be intercon-nected in any fashion, so long as every media gateway is reachable from every othermedia gateway. Routing protocols in the packet domain will automatically discoverthe switch fabric’s topology.

Suppose we are serving the same customer base as in the previous example (seeFigure 3.2), but we choose to deploy a next generation switch instead of a legacyswitch. So media gateways A and B replace line frames A and B; we also replace thecentral fabric component with media gateway C. For purposes of illustration, weassume that the distributed fabric also incorporates two packet switches.

This layout is shown in Figure 3.4. The solid lines depict the topology of theswitch fabric. The dotted line traces a bearer path for a call connecting areas 1 and 3.When the call is attempted, the media gateway controller tells media gateway A toset up a bearer channel to media gateway B. In turn, media gateway A signals topacket switch I that it wishes to make such a connection.

Packet switch I “sees” the gray-shaded portion of Figure 3.4. That is, routingprotocol software running on packet switch I has built (and continually maintains) amodel of the switch fabric’s topology. From this model, packet switch I knows(without being told by the media gateway controller) that it can reach media gate-way B without involving packet switch II.


Remote lineframe Z

Remote lineframe C

Central fabric

Controller

Remote lineframe B

Remote lineframe A

Figure 3.3 Bearer connectivity for a legacy switch with remote line frames.

Before moving on, we need to draw an important comparison between theremote line frame example (Figure 3.2) and its softswitch incarnation (Figure 3.4).Although media gateway C replaced the central fabric component, their roles arenot analogous. In the remote line frame example, every call processed by the switchfalls into one of two categories:

• The calling and called parties are served by the same remote line frame.• The calling and called parties are not served by the same remote line frame.

In the first case, the situation is clearly analogous to that of a next generationswitch, with “media gateway” replacing “remote line frame.” So we have not trou-bled to redraw the bearer path connecting areas 1 and 2 in Figure 3.4. In the secondcase, the call’s bearer path always traverses the central fabric component. Thus thiscomponent has a very special role. There is no comparable component in the nextgeneration incarnation (unless we decide to implement a hub-and-spoke topology).

As with the previous figures in this section, no signaling traffic appears in Figure3.4. Again, this is purely to simplify the diagrams.

3.2.2 Exploiting Low Bit-Rate Voice Codecs

In legacy voice networks, the basic unit of transmission capacity is 64 kilobits persecond (kbit/s). Capacity is allocated in multiples of this basic unit. The reason foradopting this quantum as the fundamental building block is that the predominantvoice encoding scheme operates at 64 kbit/s.

Over the years, a variety of voice-encoding schemes have come into existence.Codec bit rates vary depending on level of sophistication and requirements ofintended usage. But essentially all of the newer codecs, including those employed inwireless networks over the so-called “air interface,” operate at lower bit rates thanthe standard codec. Since landline circuit-switched networks cannot allocate lessthan 64 kbit/s, however, voice-encoding bit streams are usually converted to thestandard codec for transmission through the network. This is true even if both end-points of the call use the same low bit-rate codec.

3.2 Packet Fabrics 29

Bearer path

Physicalconnectivity

MediaGW C

MediaGW controller

Signaling GW

MediaGW B

Packet switch II

Packet switch IMediaGW A

Area 3

Area 2

Area 1

Figure 3.4 Bearer connectivity for a next generation switch.

Clearly, this arrangement is not ideal; it is an inefficient use of transmissionbandwidth. Moreover, converting to and from the standard 64 kbit/s codec entailsdegradation of voice quality. Since packet networks are not hard wired to func-tion in terms of fixed capacity increments, they offer a means of addressing thisshortcoming.


C H A P T E R 4

Signaling and Services

In this chapter, we describe the structure of the control plane. Then we take a cur-sory look at a variety of services and talk about the requirements they place on theserving network. We briefly discuss limitations of today’s telco networks that makeit difficult to create new services.

4.1 The Control Plane

In Chapter 1, we introduced the concept of a circuit-switched network and said thattraditional telephone networks are of this type. In the interest of precision, we nowrephrase that statement as follows: in a typical telco network, a circuit-switchedbearer plane is controlled by a packet-switched control plane. In this brief chapter,we expand on this concept by describing the structure of the control plane.

In today’s telco networks, call-control signaling does not use bearer channelsbut is instead carried on separate, dedicated channels. (There is a caveat: it would bemore correct to say that interswitch call-control signaling uses separate, dedicatedchannels.)

Moreover, switches do not exchange call-control messages directly. This is truealmost universally in the United States, but is somewhat less so in Europe. Here weare talking about signaling between “core” telco switches; our statement is notapplicable to Integrated Services Digital Network (ISDN) deployments. Instead,these message pass through intermediaries known as signaling transfer points(STPs), which are usually drawn as boxes with diagonal slashes (see Figure 4.1).This is the case even when the switches involved are adjacent.

So the bearer and control planes are implemented as separate networks and thelatter is a packet-switched network. Among other things, STPs are responsible forthe routing of call-control messages. Recall that packets have header fields indicat-ing where the payloads are supposed to go. STPs base their routing decisions on thecontents of these destination header fields.

One voice switch may be directly connected to many other voice switches. Thenumber of links to STPs is likely to be much smaller than the number of links toother switches, however; control messages for calls to many destinations can bemultiplexed on the same signaling link. The switch controller only has to listen forcall-control messages on links to STPs.

To summarize, there are three main concepts in this section:

1. Signaling interchanges are conducted on dedicated signaling channels.

2. These signaling channels are packet-based.

31

3. Rather than running directly from switch to switch, signaling channels areconnected to STPs. STPs do not come in contact with bearer traffic. So,unlike voice switches (which straddle the bearer and control planes), STPsreside in the control plane. We can think of STPs as special-purpose packetswitches.

Note that the items in this list represent distinct concepts. In particular, tech-nologies such as ISDN (which is briefly described in Section 11.2.1) embody the firstdesign principle but not the third.

4.2 What Is a Service?

In Section 1.2, we introduced the idea of “find me/follow me” services. Rather thangive a formal definition of the term service, we prefer to offer the following examplesas a sort of operational definition:

1. Telephony itself: the basic ability to complete calls;

2. So called “vertical” services, such as:• Voice mail;• Caller ID/ calling name ID;• (Unconditional) call forwarding;• Call waiting.

3. Services that offer alternative billing schemes, such as:• Toll-free service;• Prepaid service;• Calling card service.

4. Short message service.

4.2.1 Vertical Services

Vertical services are so named because of their place in the telco business model: theyallowed telcos to “stack” additional revenue streams on existing customers. Sincethese customers were already being billed for basic service, the marginal cost of

32 Signaling and Services

Bearer plane

Signalingtransfer point

Control plane

Switch CSwitch BSwitch A

ControllerControllerController

Figure 4.1 Control plane.

collecting the additional revenue was very modest. So, although initial rollout ofthese services was expensive and time consuming, they proved enormously profit-able in the long run. Profitability of vertical services depended on mass-marketacceptance and extended revenue-producing lifetimes.

One only needs to look at the wireless industry to see that times are changing(hence our use of the past tense in the previous paragraph). Services such as voicemail, caller ID and call forwarding are de rigueur in the wireless telephone industry;they do not represent separate revenue streams to wireless carriers. One obviousreason is the wireless industry is much more competitive than the landline localexchange industry (at least in the United States). In the case of caller ID, another rea-son comes to mind: wireless handsets can display text and are more intelligent thantraditional landline telephones. For a host of reasons (including increasing minia-turization), wireless handsets are replaced much more frequently than landline tele-phones. The handsets tend to get smarter at each iteration of the upgrade cycle.

We have listed call forwarding as a vertical service, using the epithet uncondi-tional to refer to a service that, at any given time, is either enabled or disabled (incontrast with a service that forwards calls only if the original called number doesnot answer, or even something as sophisticated as a follow-me service).

Note that call forwarding, even in its most basic form, is different than the othervertical services listed in an essential way. Namely, it involves a higher level of userconfigurability: the user needs to be able to dynamically turn it on and off. Whenturning the service on, the user must also specify the “forward-to” number.

4.2.2 Services that Offer Alternative Billing Schemes

In the case of toll free service, the called party (rather than the calling party) is billed.Some of the services listed under this heading may be more sophisticated than oth-ers. For instance, credit card service typically offers the ability to get a dial tone andmake another call by pressing and holding the “#” key. Prepaid service may offer away for users to check their account balances.

4.2.3 Short Message Service

Short message service is the vehicle by which wireless phones send and receive textmessages. Unlike the other services listed above, short message service does notinvolve voice telephony.

4.3 Where Do Services “Live,” and What Do They Entail?

One can visualize the control plane as a layer that enables services to use the bearerplane. This is often schematically represented by placing the control plane on top ofthe bearer plane. This is a useful, if imperfect, viewpoint (for example, short mes-sage service blurs the separation between control and bearer planes, as we willdescribe in Chapter 13). As the name suggests, basic call-control signaling inhabitsthe control plane.

4.3 Where Do Services “Live,” and What Do They Entail? 33

So we have the control plane stacked atop the bearer plane. In turn, the serviceplane is logically stacked atop the control plane. Again, the notion is imprecise—even though we list basic telephony as a service, it “lives” in the control andbearer planes. Moreover, other services such as call forwarding and caller ID areswitch-based in the sense that they do not require per-call interaction with externalservice plane entities to function properly.

4.3.1 Can You Say “Database?”

The resources required for implementation vary from one service to the next. Forexample, voice mail requires a platform capable of recording, storing, retriev-ing, and replaying messages. A common denominator, however, is that servicesrequire access to subscriber data. So databases play a central role in telco serviceinfrastructures.

Depending on the service in question, the necessary subscriber data might bevery simple. This is the case, for example, with caller ID service: the called party’sserving switch has the calling party number (since it is contained in the call setupmessage) and simply needs to know whether to display it. This switch is the onlydevice that must have this information when the incoming call arrives. Even such arudimentary capability means that a Boolean value (e.g., yes/no or enabled/disabled)must be associated with the called party’s phone number and stored in a table ordatabase. Caller ID subscription information is periodically downloaded from “m-aster” provisioning databases to switches. Processing for incoming calls is based onlocally stored subscription information.

On the surface, calling name ID is similar to caller ID. But the former is more dif-ficult to implement than the latter: unlike the calling party number, the calling partyname is not contained in the call setup message. Therefore it must be fetcheddynamically from the appropriate database on a per-call basis; that database residesin the service plane. (It would not be at all practical to store calling name ID infor-mation for all potential callers on each switch.)

In Figure 4.2, we update our schematic network representation to include theservice plane. We have populated the service plane with two new devices for the sup-port of an unspecified service. Next, we briefly describe these devices.

As we saw in Section 4.1, voice switches rely on signaling transfer points asintermediaries for call control signaling. When a signaling transfer point needs toaccess a database, it relies on another intermediary called a service control point. Wewill draw databases as cylinders, since this shape is suggestive of a computer diskdrive (and thus of the “data store” concept). This is in keeping with common prac-tice. (As an aside, service logic often resides on service control points; we elaboratein Chapter 13.)

We have discussed calling name ID; toll-free service is another pertinent exam-ple. The following description will be in terms of the North American implementa-tion. The caller’s serving switch is statically provisioned to know that prefixes suchas 800, 888, and so on are reserved for toll-free service (unlike area codes, tripletssuch as 800 and 888 have no geographic significance; we say that such numbers arenot routable). So any time it sees a called number with one of these prefixes, theswitch knows that it must query the toll-free database, which resides in the service


plane. This query sets in motion a series of events that eventually yields a routablenumber. One important point is that the procedure is transparent to the callingparty. In particular, the calling party never sees the routable number. We omit thedetails.

One point of clarification may be in order here. In the case of landline caller IDservice, a given switch needs subscription information for a restricted population(namely, those customers who use it as their “home” switch). In contrast, the toll-free database may be quite large, and a switch has no way of knowing in advancewhich records it will need. It would not be practical to replicate the toll-free data-base in local storage at every switch that needs to query this database. Instead, adatabase query will be launched for each toll-free call.

One can make exactly the same argument for calling name ID. Note the follow-ing difference, however: the calling party’s serving switch generates the toll freequery; the called party’s serving switch generates the calling name ID query.

4.4 Limitations of Circuit-Switched Networks

What are the limitations of circuit-switched networks when it comes to providingservices? Can packet telephony ease these limitations? We highlight the followingdifficulties:

1. Circuit switches can ask the service plane for assistance. For example, wehave discussed the capability to obtain subscriber information as needed bylaunching database queries. But the switches themselves have to know whatinformation to request and when to request it; when new services comealong, this is not trivial. Many services are, at least partly, resident in theswitches themselves. Moreover, when a customer subscribes to multipleservices, those services may interact in unpredictable ways. Thus, pro-visioning and maintenance of services has traditionally been anything butstreamlined.

2. As we will see in Chapter 8, the control plane for today’s circuit-switchednetworks is idiosyncratic. In particular, the routing scheme has some un-fortunate limitations.

4.4 Limitations of Circuit-Switched Networks 35

ControllerControllerController

Signaling transfer point

DatabaseServicecontrol point

Bearer plane

Control plane

Service plane

Figure 4.2 Service plane.

3. Landline telephones for the residential market possess minimal intelligenceand signaling capabilities. Moreover, it is difficult to control parametersettings for sophisticated services with a 12-button keypad.

These problems are now widely recognized as such in the telecommunicationsindustry, and there are ongoing efforts to address them. The notion of a service crea-tion environment has been proposed in response to the first problem. In a nutshell,the idea here is to offer a “scripting” capability that makes it easy to develop serv-ices. Scripts would invoke basic call-control functions that are already implementedin the network (and have already been debugged). The service creation environmentconcept also includes ways for switches to autodiscover the services offered. Theseprecepts predate widespread interest in packet telephony, but so far implementa-tions have offered very limited capabilities. As it develops, packet telephony mayprovide the means to make better use of these ideas.

Modern data networking technology can also be used to evolve toward a moreflexible control plane infrastructure. However, Internet protocol routers and otherdata network equipment historically have not been engineered to the same level ofreliability as have signaling transfer points. For this and other reasons, this evolutionwill occur over a long period of time.

Lastly, we briefly discuss the lack of intelligence in the telephone itself. In thelandline residential market, this may be very slow to change. But wireless handsets(a.k.a. cellphones) are already much more sophisticated than residential landlinetelephones; moreover, they continue to evolve. We are entering an era where wire-less handsets are complex enough that they require operating systems. Thus, theyare, in a very real sense, small computers.


P A R T I I

Components of Packet Telephony:Technical Descriptions

C H A P T E R 5

Introduction to Part II

So far, we have tried to introduce an absolute minimum of terminology and avoidacronyms altogether. We are reaching a point of diminishing returns with thisapproach, however. Now we want to take a look at the technical “nuts and bolts”of packet telephony. In large part, this means we will examine the protocols thatdevices use to talk to one another. These are the lingua franca of our chosen topic,and they will pave the way for detailed discussion of some interesting examples. Ourexamples will be chosen to:

• Illustrate themes in the migration to packet telephony;• Give the reader a sense of how a collection of protocols works together to pro-

duce an overall solution.

In Part I, we hope that we have armed the reader with a conceptual frameworkthat helps assemble the forthcoming technical information into a coherent whole.

As we prepare to plunge into technical details, there are several terms and con-cepts from Part I to keep in mind. We highlight the following:

• Quality of service. Circuit-switched networks are engineered to providehigh voice quality. Packet-switched networks, which have traditionally beendesigned to meet different requirements, are less adept at providing quality ofservice suitable for real-time applications (such as bidirectional voice andvideo). The traditional data networking paradigm must be adapted to supportthe same quality of service as that delivered by legacy voice networks.

• Packet-switched control plane. When we say that legacy telephone networksare circuit-switched, we are really referring to the bearer plane. The controlplane is already a packet network.

• Routing. The data networking community has standardized robust dynamicrouting schemes and brought them into widespread use. Today’s data net-work routing protocols offer immediate promise for alleviating difficultieswith traditional telco control plane protocols.

Data network routing schemes also show promise in the bearer plane. But real-istically, delivering on that promise will take more time. Potential benefits includegraceful adaptation to changing traffic conditions with minimal administrativeoversight.

39

• Distributed switching. Voice switches will evolve from centralized devices todistributed devices, and functional components will be clearly separated.Recall that we have identified the following functional components:• Bearer traffic enters and exits the distributed switch fabric via media

gateways.• The actions of media gateways are directed by media gateway controllers.

The former “live” in the bearer plane, whereas the latter inhabit the controlplane.

• Call control signaling traffic enters and exits a distributed switch via a sig-naling gateway.

• The intergateway switching fabric interconnects media gateways belongingto a distributed switch.

How can we evolve a circuit-switched infrastructure toward packet telephony?We will use the wireless industry as a source of examples that shed light on thistopic. Wireless networks are more sophisticated than wireline networks, since wire-less handsets must communicate with towers. The radio technology that is employedfor this purpose is certainly complex. But wireless networks are complicated inanother way: the towers are interconnected by sophisticated “wired” networks.

It is the second type of complexity that interests us in this book. In a nutshell,mobile carriers’ networks have to be smart enough to keep track of mobile subscrib-ers, so their control planes have to manage information in a dynamic fashion thatwould be alien to their landline counterparts. When a customer powers up his or herhandset (or moves to a new location), the switch that serves that customer’s currentlocation must:

• Fetch the appropriate subscriber records from a centralized database.• Make a note of the current location in the centralized database.

The latter is important because, in order to complete an incoming call, the net-work must be able to find the subscriber in question. We elaborate in Section 8.7.

5.1 Selected Telco Terminology

At this point, it is expedient to introduce the following telco vocabulary:

• A line is a connection between a voice switch and a telephone (or other cus-tomer premises equipment).

• A trunk is a voice channel that connects two switches.• Public-switched telephone network (PSTN). This is a generic term for a

telco network. We will use this term to mean circuit-switched network.(This is a reasonably accurate usage: although packet voice is seeping intotraditional telco networks, the vast majority of telco infrastructure is stillcircuit-switched.)

40 Introduction to Part II

• A Class 5 switch directly serves subscribers. Said differently, a Class 5 switchis a switch that terminates lines. “Class 5” is a reference to the PSTN switch-ing hierarchy in the United States. Detailed discussion of the hierarchy isbeyond our scope. Suffice to say that switches in the other layers of the hierar-chy only connect to other switches-not to end users.

• End office switch is a synonym for “Class 5 switch.”• Time division multiplexing (TDM). A scheme in which bits associated with

different channels are distinguished according to when they arrive. This isessentially the multiplexing approach in landline circuit-switched networks.

• Private branch exchange (PBX). Switching equipment that is common inoffice environments, college campuses, and the like. PBXs usually offer abbre-viated dialing plans for internal calls and other convenience features.

• Centrex service is typically hosted at the Class 5 switch; the features are simi-lar to that of a PBX. Telcos offer centrex service as a way to compete withPBX providers.

• Wireless carriers’ base stations are typically interconnected by landline net-works known as public land mobile networks (PLMNs). We note here thatconnectivity may be achieved by other means, such as microwave links, in spe-cial circumstances.

5.1 Selected Telco Terminology 41

C H A P T E R 6

Protocols

In this chapter we introduce the protocol stack concept. We define the following ref-erence terminology: physical layer, data link layer, network layer, transport layerand application layer.

It is easier to understand the main ideas with a few examples in mind. To thisend, we describe Transmission Control Protocol/Internet Protocol (TCP/IP), whichis an important foundation in data networking. Then we look at an example that ismore directly pertinent to telephony: Signaling System 7 (SS7), which is predomi-nant in the control and service planes of today’s telephone networks. In the process,we briefly discuss finite state machines. We will explore voice over IP in Section 9.3.

6.1 What Is a Protocol Stack?

A protocol stack is a bunch of layers of software. Many things have to happen inorder for one user or application to exchange data with another, especially if theexchange occurs across a telecommunication network. The many tasks that must beperformed are grouped into modules. This is in keeping with good programmingpractice, which uses modularity to make large tasks manageable and to pave theway for code reuse. To a degree, implementation details within different layers areindependent.

Since transmission across a network must involve hardware at some point, wehave oversimplified a bit by only mentioning software in the previous paragraph.Moreover, processes that could be implemented in software may be implemented insilicon in the interest of performance. Imagining several layers of software (some ofit taking the form of application-specific integrated circuits) running atop switchingand transmission equipment gives a more accurate picture.

Referring to a collection of protocol modules as a stack is, to our way of think-ing, primarily a visualization aid. In the vertical direction, lower layers providefunctionality to higher layers running on the same device. In the horizontal direc-tion, entities at the same layer (on different devices) talk to each other across anetwork.

Physical transmission capacity always resides at the bottom of the protocolstack. All higher layers ultimately rely on the physical layer to conduct dialogs withtheir counterparts on remote devices.

When an application submits a packet of data for transmission to a remoteentity, that packet must descend the protocol stack to the physical layer. Alongthe way:

43

• Successive encapsulation occurs. That is, each protocol layer adds its ownheader information.

• Fragmentation may occur. Fragmentation is necessary whenever a protocollayer receives a chunk of data that is too big to handle “all in one shot.”

On the receiving end, successive decapsulation takes place: each protocol entitystrips off the header that was added by its same-layer counterpart, processes thatheader, and passes the payload to the layer above it. If fragmentation took place atthe originating device, reassembly is performed at the destination.

Segregating functions into protocol layers makes life easier for humans. One canconcentrate on the details of one protocol layer and think of the other layers as“black boxes,” keeping in mind only a very rough description of their roles.

6.1.1 Comparison with Last In, First Out Data Structures

In computer science, the notion of a last in, first out data structure is prominent.Such a data structure is usually called a stack, but this is clearly not the same as aprotocol stack. However, we note the following similarity: when a packet climbs theprotocol stack at its destination, the encapsulating headers are removed in last in,first out order.

6.2 Generic Layer Descriptions

Each layer in a protocol stack builds on the capabilities of the layer below in order toprovide services to the layer above. How should functionality be subdivided amongthe layers? There is a de facto standard approach. In Table 6.1, we list industry-stan-dard layer names and summarize the functions assigned to each layer.

Table 6.1 is not exactly a protocol stack; instead it is a reference model that sug-gests how a protocol stack ought to be organized. This model is really just a guide-line; technologies and protocols never seem to align cleanly with the boundariesbetween the layers. However, the model can provide useful insight on how individ-ual technologies fit into the bigger picture.

On occasion we will refer to the data link layer as layer 2 and the network layeras layer 3; although it dates back to the 1980s, this nomenclature has remained in

44 Protocols

Table 6.1 Protocol Layer Descriptions

Layer Name Description

Application Defines processes that allow applications to use network services.Transport Ensures reliable communication across a network. The transport layer verifies

the integrity of the data it receives.Network Adds routing and addressing functionality for end-to-end communication.Data link Responsible for reliable point-to-point communication between devices. Pack-

ages data in structured frames that are submitted to the physical layer fortransmission.

Physical Responsible for transporting bits through a physical medium.

the vernacular. The layer numbers (as well as some of the basic ideas) are taken fromthe Open Systems Interconnection (OSI) reference model, which was developed bythe International Organization for Standardization (ISO) in 1982. That referencemodel defined a seven-layer stack, with the application layer at the top. There weretwo additional layers (not shown in Table 6.1) between the transport and applica-tion layers. Implementation of those two layers was problematic from the start, andthe OSI reference model was pretty much abandoned. Some of the terminologystuck around, however. In particular, one may still encounter references to “layer7” as a synonym for the application layer, although this terminology is probablybest avoided. At any rate, the layers of primary interest in this book are the datalink, network, and transport layers; we discuss these layers next. We will notexpand on Table 6.1’s telegraphic descriptions of the other layers.

6.2.1 Data Link Layer

The data link layer provides reliable point-to-point communication betweendevices. Two things are particularly important here:

• The physical layer does not worry about any errors in transmission that mayhappen: it does not notice bit errors, let alone try to correct them.

• The data link layer does not have overall knowledge of the network. The twodevices mentioned previously need to be directly connected from the data linklayer’s point of view (although there might be other physical-layer devicesbetween them).

The data link layer packages data in structured frames that are submitted to thephysical layer for transmission. This layer performs error checking; each frameheader includes data (such as a cyclic redundancy check field) to support errorchecking functionality.

In order to recognize situations in which transmitted data has been lost alto-gether, sequence numbers may also be present in frame headers. In this case, thedestination device sends acknowledgments to the originating device; these acknowl-edgments indicate which frames have been successfully received.

The data link layer may also be responsible for flow control (in response to con-gestion) and for error recovery (e.g., resetting a link) in response to errors at thephysical layer.

Examples

Common protocols at the data link layer include the following. The reader can findmore information in Appendix A.

• High-level data link control (HDLC) was standardized by the ISO. Its basicapproach to framing has been borrowed by many protocols, often with adap-tations to suit specific needs. Point-to-point protocol (PPP), which is heavilyused in dial-up networking, is often deployed with a framing structure similarto that of HDLC.

6.2 Generic Layer Descriptions 45

• Ethernet is the most common LAN technology and is evolving beyond its tra-ditional roots.

• Frame Relay and ATM are widely used to transport data traffic across socalled wide area networks.

6.2.2 Network Layer

Recall that the data link layer does not “see” the topology of the network. The net-work layer is responsible for routing packets: by looking at the destination addressof each packet, it determines which outgoing link to use. In this context, each desti-nation address must have network-wide significance (i.e., it must uniquely identify adestination device).

In some cases, the network layer has some ability to manage quality of service(e.g., priority fields in network layer headers can be used to request preferentialtreatment).

Examples

At the network layer, most of our attention will be devoted to Internet Protocol. Wealso give some coverage to layer 3 functionality in SS7 stacks. For completeness, wenote that other network layer protocols exist (such as Novell’s IPX).

6.2.3 Transport Layer

The transport layer is responsible for ensuring reliable communication across thenetwork. When there are problems with dropped and duplicated packets, it detectsand corrects these problems. This layer performs fragmentation and reassembly.The transport layer is also responsible for flow control; it uses buffering and/or win-dowing as flow control tools.

Examples

Examples include TCP, Stream Control Transmission Protocol (SCTP) and (nom-inally) User Datagram Protocol (UDP). Each of these are covered later in thischapter.

6.2.4 A Note on Terminology: Packets and Frames

Recall our definition of a packet: it is a chunk of digital data with a header. Amongother things, the header contains fields indicating where the data is supposed to go.Many other terms in common use refer to the same basic concept.

When discussing data link layer technologies, chunks of data are often calledframes (e.g., in the case of Ethernet or Frame Relay). One distinction is that framesoften have trailers in addition to headers; packets do not.

No term seems to be universally applicable. In ATM, for instance, all chunks ofdata have the same length; people wanted to use a different term to emphasize thisdifference with other data link layer technologies, and they settled on the term cell.Moreover, ATM cells do not have trailers.

46 Protocols

When referring to layers above the data link layer, we will predominantlyuse the word “packet.” When referring to the data link layer, we will predomin-antly use the word “frame.” In the interest of simplicity, other terms will be usedsparingly.

6.2.5 General Comments

The physical layer provides the fundamental ability to pump bits through a physicalmedium. One can view Table 6.1 as a roster of additional functions that are neces-sary to harness that basic capability. In some cases, capabilities essentially mustappear in the roster exactly where the model places them. As an example, it is com-pulsory that a framing structure be defined between the physical and network lay-ers, because this is the means by which chunks of data arriving on the physical layerare delimited.

In other cases, some capabilities might be arranged differently in different pro-tocol stacks. Note, for example, that the word “reliable” appears at layers 2 and 4.Clearly, there is a major difference in context: layer 2 provides reliability on individ-ual links, whereas layer 4 is responsible for end-to-end reliability.

Bit errors do happen at the physical layer; moreover the physical layer cannotdetect these errors. The word “reliable” suggests error detection and correction.Now the frequency (or rate) of bit errors varies depending on the physical layer—ittends to be higher in wireless transmissions than on fiber-optic cables, for instance.When the physical layer has a high bit error rate, it is common to implement errorcorrection at the data link layer as well as the transport layer. When the physicalmedium has a low error rate, error correction is commonly left to the transportlayer. Note, however, that essentially all data link layer technologies perform errordetection. Rather than implementing sophisticated error correction schemes orrequesting retransmissions themselves, they may simply discard errored frames,leaving it to the transport layer to request retransmission upon discovering thatthere is missing data.

In the case of real-time services (such as voice and video), end-to-end retrans-mission is not a palatable option: by the time a retransmitted packet makes itacross the network, the real-time session has already progressed “downstream” andhas no use for this “stale” packet. We will see that the bearer protocol stacks forpacket voice are therefore different from those employed for traditional datanetworking.

When applications on two host computers communicate, the protocol stacksthey rely on implement essentially all of the functions cataloged in Table 6.1(although there is some variation in how these functions are organized into layers).It is important to understand that intermediate devices implement only a subset ofthe full functionality.

We will describe numerous protocols in this book, starting with IP and TCP inthe next section. In each case, we will indicate (or at least approximate) where theprotocol in question fits in the reference model, and we will talk about the fields inits packet or frame headers.

6.2 Generic Layer Descriptions 47

6.3 Internet Protocol and Transmission Control Protocol

IP operates at the network layer. As with other protocols, IP has gone through aseries of versions as it evolves. Version 4 (which we will abbreviate as IPv4) is pre-dominant in today’s networks. The annointed successor, IPv6, has yet to “establisha beachhead.”

The IP header includes the following fields: IP version number, source address,destination address, and length. There are significant differences in the IPv4 andIPv6 headers, each of which contains a number of other fields not mentioned here.We defer detailed discussion of the IPv4 and IPv6 headers until Chapter 7.

IP has to ride over something at the data link layer, as IP itself has no provisionfor “reaching down” to this layer. IP can be carried by many data link layer tech-nologies (including the examples listed in Section 6.2.1). This independence of thedata link layer is one of IP’s great strengths.

Whenever one makes a call over a circuit-switched network, the bearer channelis bidirectional, and bearer traffic in both directions follows the same route. Beforemoving on, we note that IP is not intrinsically bidirectional. Common applicationssuch as e-mail and instant messaging essentially adhere to a unidirectional para-digm. For applications such as full duplex voice, there is no guarantee that the bearerpaths in the two directions traverse the same nodes.

6.3.1 What Is an Internet Protocol Router?

Our discussion will include many references to IP routers. For our purposes, an IProuter is a switching device that examines the IP header of each incoming packet anduses the contents of that header to make its forwarding decision (i.e., to select theoutgoing interface for the packet).

6.3.2 A Brief Look at TCP

TCP has been a huge factor in the data networking industry’s growth. This is true tosuch a degree that TCP/IP is often thought of as a “package deal.” TCP nominallyoperates at the transport layer, so we could think of TCP/IP as “TCP running overIP.” Many applications in turn run over TCP, including the following:

• Web browsing using HyperText Transfer Protocol (HTTP);• Telnet;• File Transfer Protocol;• E-mail (using Simple Mail Transfer Protocol);• Applications requiring cross-network database access (using Lightweight

Directory Access Protocol).

We briefly discuss the functionality offered by TCP; we will refer to the TCPheader as illustrated in Figure 6.1. (We describe the significance of the shaded fieldsin the paragraphs below; we do not discuss the other fields.) The main responsibilityof the transport layer (see Table 6.1) is to ensure reliable communication across anetwork. The checksum field in the TCP header is used to detect corrupted packets

48 Protocols

(see Figure 6.1). Each TCP header also contains a sequence number field. Sequencenumbers are reckoned in bytes of payload. The TCP protocol entity at the receivingend of a connection acknowledges receipt of packets back to the sender. This is thepurpose of the acknowledgment number field; the receiver fills in the value of thenext sequence number it is expecting from the sender, and sets the ACK bit to 1 toindicate that the contents of the acknowledgment number field are meaningful. Theimplication is that every byte with a smaller sequence number than the acknowledg-ment number has been successfully received. (Let us think of the main directionof data flow as “downstream.” Then we can say that acknowledgments travelupstream.) If the sender does not receive acknowledgments in a timely fashion, itretransmits the packet(s) in question.

So far, we have described a rudimentary mechanism for ensuring reliable com-munication. To a significant degree, TCP owes its success to additional features.TCP provides the following functionality (so protocols running over it do not haveto implement any of this functionality):

• Flow control. TCP tries to make full use of the network capacity that is avail-able to it. If it waited for acknowledgment of each packet sent before sendinganother, this would make for very slow going. Instead, TCP sends a certainnumber of bytes without waiting for acknowledgment. (The number of bytesis governed by the window field in previous acknowledgments.) If no conges-tion is detected (i.e., all packets seem to be getting through) and the destina-tion host is able to keep pace, TCP increases the window. This has the effect ofsending data at a higher rate. If a session has a substantial traffic volume overa long duration, TCP will eventually saturate the available network capacity,and packets will begin to be dropped. TCP will then realize that it has gonetoo far and will back off (i.e., move to a smaller window size). Then the cyclestarts again—the window size slowly inches up, and so on.

• Sequencing and eliminating duplication. Packets may not be received in thesame order that they were transmitted (IP networks make no guarantees

6.3 Internet Protocol and Transmission Control Protocol 49

Source port (16 bits)

Padding (variable length)

GRU

Options (variable length)

Urgent pointer (16 bits)Checksum (16 bits)

Window (16 bits)

Acknowledgment number (32 bits)

Sequence number (32 bits)

Destination port (16 bits)

NIF

NYS

TSR

HSP

KCA

ReservedDataoffset

Figure 6.1 TCP header.

about preserving order). Moreover, a TCP protocol entity may unnecessarilysend duplicate packets because it did not wait long enough for acknowledg-ments (or because acknowledgments got lost in transit). TCP uses theSequence Numbers to correct for these anomalies, so the higher layer proto-cols do not have to worry about them.

• Multiplexing. A single TCP protocol entity may have many applications run-ning over it. The source port and destination port numbers are used to makesure that data gets to and from the right applications.

• Segmentation and reassembly. Applications running over TCP can submitlarge amounts of data to the TCP layer (e.g., large files in the case of file trans-fer protocol) and assume that their data is streamed across the network. TCPdecides how the data should be segmented into chunks at the sending end andreassembles the data at the receiving end.

When the sending host has no more data to transmit, it indicates this by settingthe FIN bit in the TCP header to 1. The data offset header field indicates the lengthof the TCP header (in units of 32-bit words). This is necessary because of the vari-able length of any options fields that may be present. We described the use of each ofthe shaded fields in Figure 6.1; the other fields are beyond our scope.

One curious fact to note is that the TCP header does not contain a length field.When TCP passes a packet to the IP layer, it informs the IP entity as to the length ofthat packet.

TCP’s flow control scheme has been tuned very carefully over the years. Forexample, the protocol entity on the sending host maintains an empirical estimate ofthe round-trip time by noticing how long it takes to receive acknowledgments for itsoutgoing packets. (More precisely, it maintains a moving average.) This is used todecide how long to wait before retransmitting unacknowledged packets. For filetransfers, Web downloads, and the like, TCP works amazingly well. On the otherhand, TCP is not very well suited to real-time voice and video applications.

This is only the briefest of introductions to TCP. There is also much more toknow than is contained in the defining document [1], especially when it comes totuning TCP performance. Further reading is available in abundance, including thewell-known three volume series [2–4] and Wilder’s book [5].

Placing Intelligence at the Edge of the Network

People who are steeped in data networking often say that, for Internet Protocol networks, the intelligence is at the edge. The sophistication of TCP is a big reason whythey say this. When TCP/IP hosts communicate with one another across the net-work, the packets they send may traverse many intermediate devices, and many, ifnot most, of these intermediate devices are oblivious to what is going on at the TCPlayer. TCP knows nothing about the topology of the network, but it is smart enoughto adjust to conditions based on the acknowledgments it does (or, in the event ofcongestion, does not) receive. It is not quite true that all of the intelligence resides inthe TCP layer at the endpoints. For one thing, IP networks have routing intelligence.Also, many Internet Protocol routing devices purposely discard packets as theyapproach congestion, so that hosts participating in TCP sessions that traverse those

50 Protocols

routing devices will see fit to reduce their window sizes. Still and all, the develop-ment of TCP represents a conscious effort to realize useful intelligence in end-userdevices. There is a big difference in the intelligence of a device running a TCP/IPstack and that of a typical consumer landline telephone set.

6.3.3 TCP/IP Networking Illustration

In this section, we describe a simple Web surfing scenario. We do so to cementthe foregoing discussion of TCP/IP in the reader’s mind. Protocol stacks at theend systems and at intermediate network elements are represented schematically inFigure 6.2.

Above the TCP layer on the end systems, the web browser and server softwareare using HTTP. When the server software fetches information in response to adownload request, it hands the data to the HTTP entity, which in turn passes it toTCP for transport across the network to the client PC. TCP segments the data intopalatable chunks and reassembles these chunks after making sure that they reachtheir destination intact. The HTTP entities on the endpoints never see this segmen-tation, nor do they see what goes on at the IP, Ethernet, and physical layers.

The intermediate network elements are an Internet Protocol router (this is rightin the middle of the diagram) and two Ethernet LAN switches (flanking the IProuter). We have not labeled these network elements as such in the diagram; thiskeeps the diagram simple and reinforces the point that TCP does not need to knowwhat the intervening network looks like.

The lower layers on the client PC and Web server are not aware of what is hap-pening at the TCP and HTTP layers; HTTP and TCP headers are just payload tothem. The same holds for the intermediate devices; they can figure out all they needto know by restricting their attention to the lower layer headers and trailers. The fig-ure reflects this at the TCP layer by showing TCP packets “sailing over the heads” ofthe intermediate devices. (By the same token, the Ethernet LAN switches do notconcern themselves with the IP packet headers.)

6.3 Internet Protocol and Transmission Control Protocol 51

Ethernet Ethernet Ethernet EthernetEthernet

IPIP IP

TCP packets (aka “segments”)

IP packets IP packets

Web serverClient PC

Webbrowser

Serversoftware

TCPTCP

HTTPHTTP

Physical Physical Physical Physical Physical

Figure 6.2 Simple TCP/IP networking schematic.

Figure 6.3 describes the flow of packets through an IP router. We have placedpacket headers on the left merely because English is read from left to right. Whenframes are submitted to the physical layer by the data link layer, headers are trans-mitted first. We have chosen to show traffic flowing from right to left in order toreinforce the notion that headers lead the way.

As a frame comes in from the left and rises through the Ethernet layer to the IPlayer, the Ethernet header and trailer are removed. The IP layer selects an outgoinginterface—this is a fancy way of saying that the IP layer determines which of thetransmission links connected to the router will be the egress link for this packet. Ithands the packet to the Ethernet layer on that interface, which adds the Ethernetheader and trailer before handing off to the physical layer. In the course of its proc-essing, the IP layer alters the IP header slightly (although this is not reflected in thepicture—the IP header appears as the same cross-hatched rectangle in each “sn-apshot” of the packet).

Headers at the data link layer may also be changed. This is clearly necessary inany case where a packet enters a router via one data link layer technology and leavesvia another technology. Suppose, for example, that we alter the scenario in Figure6.2 to include two intermediate IP routers with a Frame Relay connection betweenthem. Then there would be traffic entering each router on an Ethernet link and leav-ing on a Frame Relay link (and vice versa). We diagram the left-hand router (i.e., theIP router closer to the client PC) in Figure 6.4. This figure shows a packet flowingtoward the client PC; note that we have used a different hatching pattern for theFrame Relay header/trailer than for the Ethernet header/trailer. (Of course, packetsflow in the other direction as well, although we do not show any of these.)

6.3.4 Alternatives to TCP at Level 4: UDP and SCTP

UDP is much simpler than TCP. Whereas TCP performs every function ascribed tothe transport layer and then some, UDP does nothing to ensure reliable communica-tion (let alone implement flow control).

UDP does offer multiplexing functionality to the higher layers. It manages thistask using source and destination port numbers just as TCP does. Another similaritywith TCP is that UDP uses a checksum to detect corrupted data.

Unlike UDP, SCTP does ensure reliable communication. It is for applicationsthat require reliability from the transport layer, but for which TCP’s flow control

52 Protocols

IP

Physical

Ethernet

IP payload

IP payload

IP payload

IP payload

IP payload

Figure 6.3 Packet flow through an Internet Protocol router.

mechanism is not suitable. As with the other layer 4 protocols mentioned here,SCTP employs source and destination port numbers.

We will discuss UDP and SCTP at greater length in Section 7.8.

6.4 What Is a Finite State Machine?

The best way to introduce the notion of a finite state machine (FSM) is probably viaan example, as formal definitions are often hard to penetrate. For our purposes, afinite state machine is an abstraction used to indicate how a protocol entity behaves.An FSM will typically be represented by a block diagram. The blocks and intercon-necting arrows in the diagram are called states and state transitions, respectively.These items show how a protocol entity is organized. Loosely speaking, one canthink of the states as software modules. A state transition corresponds to an eventthat transfers control from one module to another.

Here is our example. When a telco customer tries to originate a phone call, theserving switch (which we will call the originating switch) keeps track of the state ofthat call. It does so by instantiating (i.e., creating) and maintaining an FSM for thatcall. This FSM often goes by the name call state model.

We present a simplified call state model in Figure 6.5. This state machine “lives”in the originating switch (the destination switch will maintain a different statemachine for the same call). The basic idea is simple enough: to make it from the idle

6.4 What Is a Finite State Machine? 53

IP

Physical Physical

FrameRelay

Ethernet

IP payload

IP payload

IP payload

IP payload

IP payload

Figure 6.4 Flow through an IP router with Ethernet and Frame Relay Interfaces.

Analyzinginformation

Routing and alertingActive

CollectinginformationIdle

Figure 6.5 Simplified version of call state model (originating).

state to the active state (i.e., the state in which a bearer channel has been set up andthe customers are conversing), and back to the idle state when the call is completed.

6.4.1 States

The states in Figure 6.5, whose names are fairly self-explanatory, can be interpretedas follows. In the idle state, the call does not yet exist. Information (such as dialeddigits) is expected by the switch when it is in the collecting information state. In theanalyzing information state, the originating switch has the dialed digits and is con-ducting various checks (e.g., whether the customer has dialed a toll-free number). Inthe routing and alerting state, the switch has requested that a call be set up and iswaiting for the call to be routed, the called party’s phone to ring, and so on. We havealready described the active state.

The five states we have shown are sufficient for our purposes. Let us note, how-ever, that the state machine implemented inside a digital switch is much more granu-lar. In particular, the analyzing information and routing and alerting states shown inthe figure are both aggregates of numerous states in the switch’s internal call statemodel.

6.4.2 State Transitions

Figure 6.5 is simplified in another major way. Even if it is only a high-level model,any self-respecting state machine should include some description of how the statetransitions occur: what circumstances or events trigger these transitions? We havenot said anything thus far about the state transitions except to include a sequence ofarrows stringing together the states. Moreover, the arrows present in the diagramonly depict the sequence for a successful call. The call state machine also needs totake a variety of failure scenarios into account. Thus, in Figure 6.6, we added transi-tions to the idle state from all other states to account for the fact that the caller maychoose to hang up at any time (before or after the call setup is completed), therebyabandoning the call.

We also labeled the transitions. Until the state machine reaches the analyzinginformation state, the switch is interacting only with the caller’s telephone; the restof the network is not yet aware of this call. Let us assume for the sake of discussionthat the calling and called parties are served by different switches. Once it has ana-lyzed the information (e.g., dialed digits), the switch notifies the network of the newcall request; the state machine for this call passes into the routing and alerting state.While in this state, the originating switch is in a somewhat passive role: it is waitingfor its signaling transfer point to contact the destination switch and relay confirma-tion from the destination switch that it can handle the call.

We emphasize that Figure 6.6 is still an incomplete representation of a typicalvoice switch’s call state machine. In fact, the state machine in the switch is very com-plicated, because the number of scenarios is large and the switch must be preparedfor each possibility. Not only does the model presented in this section lack a fullcomplement of states; we also comment here that, in a more faithful representation,the logic associated with the state transitions might also be complex. We mentionone particular type of transition trigger, a so-called timeout that is common in

54 Protocols

protocol entities but is omitted from the high-level description in this section. Whena protocol entity sends a message, it generally will not wait indefinitely for aresponse. Instead, a timer is set when a message is sent. If the timer expires before aresponse is received, the sender assumes that the message was lost and takes appro-priate action (e.g., resending the message).

6.4.3 Additional Comments

State machines residing in different network elements often need to be synchro-nized. Recall that the state machine represented by Figure 6.6 has a partner of sorts:that is, there is a state machine associated with our telephone call in the destinationswitch. For instance, if the originating state machine is in the active state, we wouldcertainly hope that the destination state machine is also in its active state. Many pro-tocols have mechanisms for ensuring that peer entities’ state machines are properlysynchronized. That is, the protocol entities continually check for evidence that theyare “on the same page,” and have defined procedures for re-establishing propercommunication when they determine that something has gone wrong.

The labels “dispatch call setup request” and “receive call setup confirmation”in Figure 6.6 refer to a call-control signaling exchange between SS7 protocol enti-ties; we introduce SS7 in Section 6.5.

6.5 Signaling System 7 in Brief

SS7 is the vehicle for call-control signaling in today’s telephone networks and is alsoan essential ingredient in many telco network services. We will discuss the SS7 layersstarting at the bottom and working our way up the protocol stack. The reader mayfind it instructive to peek ahead to Section 6.5.6, which is relatively self contained,before trying to attack the bigger picture. This is where we touch on ISDN User Part(ISUP), which is the protocol for basic call control.

6.5 Signaling System 7 in Brief 55

Active

Receive callsetup confirmation

Routing and alertingsetup requestDispatch call


Done collecting7 or 10 digits

Collectinginformation

Detect off-hookIdle

Detect on-hookDetect on-hook

Figure 6.6 A more realistic call state model with labeled transitions.

SS7 did not spring, fully formed, from the head of Zeus. Even though we associ-ate it with “legacy” networks, SS7 is itself the outgrowth of a long evolution. Theprevious step in that evolution was Common Channel Signaling 6 (CCS6). Like SS7,CCS6 was packet-based.

Recall that it is possible to perform call-control signaling using bearer channels;another choice is to dedicate certain channels entirely to signaling. In the latter case,one signaling channel would be able to serve the needs of many bearer channels(which would have the same signaling channel in common—hence the name“common channel signaling”). CCS6 codified the common channel approach, but ithad the following limitations:

• It used fixed-length packets (and therefore had limited extensibility).• It lacked an independent transport layer.

SS7 overcomes both of these limitations.The thing to note about SS7 is that it is vast. This is true in terms of the variety

of signaling messages that ride atop SS7 stacks as well as the sheer scale of theSS7 infrastructure that is now deployed worldwide. Moreover, the SS7 footprintis growing in both of these “dimensions” as applications like number portabilityare rolled out, wireless networks evolve toward ever-increasing functionality, andso on.

At the higher layers, many of the SS7 message types are grouped into so calledapplication parts. To give the reader a sense of the vastness of SS7, we hold up theMobile Application Part (MAP [6]) specification as as an example: this specificationis about a thousand pages long, and it is still changing. MAP is the protocol forso-called mobility management functions in wireless networks adhering to the GSMspecifications; we discuss this protocol later in this chapter. Here we note that GSMoriginally stood for Groupe Spéciale Mobile. Nowadays, this acronym is more com-monly expanded as Global System for Mobile Communications.

In an SS7 stack, Message Transfer Part (MTP) is responsible for levels 1, 2, and3. These levels are roughly aligned with layers 1 through 3 (as described in Section6.2), although we will see that MTP level 3 falls short of full-fledged network layerfunctionality. MTP level 1, the SS7 physical layer, operates independently of theother layers; we do not discuss it any further.

6.5.1 MTP2

Message Transfer Part Level 2 (MTP2) provides basic error detection and correctionat the data link layer (as the name suggests, MTP2 operates at this layer). Recall thatan essential function of the data link layer (and a prerequisite for any sort of errordetection and correction capability) is to package data in structured frames that aresubmitted to the physical layer.

MTP2 maintains sequence numbers, but these only have local significance. Thatis, sequence numbers used on a given link have nothing to do with sequence numberson any other link. Note that this is different than TCP, in which the end systemsagree on the semantics of the sequence numbers they employ. The fact that TCP cantake an end-to-end view (and MTP2 cannot) is due to their relative positions in

56 Protocols

protocol stacks: recall that TCP operates at the transport layer, which is above thenetwork layer.

6.5.2 MTP3

Message Transfer Part Level 3 (MTP3) is responsible for network managementfunctions; it is also responsible for the following message handling functions:

• Message discrimination. This function determines whether the current node isthe destination for this message. If so, the message is passed to the message dis-tribution function, described below. If not, the message is passed to the mes-sage routing function, also described below.

• Message routing. This function selects the outgoing link. MTP3 has point-to-point routing capabilities (but we note here that its routing intelligence islimited).

• Message distribution. This function, which is invoked when the current nodeis the destination for this message, passes the message to the correct higherlayer protocol entity.

The use of the term “destination” can be confusing in the context of the messagediscrimination function already described. When an incoming message is passed bythe message distribution function to a higher-layer protocol, that protocol may fur-nish additional information and send the request back down to MTP3 for routing toanother node. Signaling Connection Control Part (SCCP), which commonly per-forms this function, is our next topic of discussion.

6.5.3 SCCP

SS7 is not used exclusively for basic call control. To an increasing degree, SS7 is usedto carry database queries and responses to and from telco network elements. Manyservices require database access (see Section 4.3), with toll free service being theclassic example. Message transfer part alone is not sufficient to support this capabil-ity. SCCP provides the end-to-end routing capability needed to reach a database;this protocol runs directly over MTP3. Note that database queries are not actuallyformulated in SCCP—SCCP just makes sure that those queries reach their destina-tions. We discuss routing in SS7 networks in Chapter 8.

6.5.4 TCAP

Whenever an SS7 node needs to perform a database query, Transaction CapabilitiesApplication Part (TCAP) comes into play. The query and the response are formu-lated as TCAP messages. As indicated in the previous section, MTP3 routing doesnot support database access, so TCAP requires the services of the SCCP layer.

6.5.5 MAP

Wireless networks maintain subscriber profiles, as well as dynamic informationon each active user’s location, in large databases called home location registers.


Incoming calls trigger queries to these databases, as the location information con-tained in the registers is required to successfully route calls to mobile users. Signalingexchanges are also required whenever a mobile user moves to a different portion ofthe serving network. The blanket term mobility management is often used to refer tothe transaction types described in this paragraph.

For wireless networks that are built to the GSM standards, the language ofMobility Management is Mobile Application Part (MAP). MAP runs over TCAP.

GSM is not the only wireless technology. For example, two other wirelessschemes are widely deployed in North America: time division multiple access(TDMA) and code division multiple access (CDMA). Both of these technologiesutliize the ANSI-41 standard for Mobility Management. The functionality is verysimilar to that of MAP, but the details are different.

6.5.6 ISUP

ISDN User Part (ISUP) is used for basic call control signaling. Here ISDN stands forIntegrated Services Digital Network. The ITUT’s ISUP specification is contained inits Q.76x series of recommendations; Q.761 [7], which contains the functionaldescription, is the starting point. The U.S. version [8] is published by the AmericanNational Standards Institute (ANSI); although there are differences in the details,the ANSI and International Telecommunication Union Standardization Sector(ITU-T) versions are conceptually the same.

Let us outline the ISUP messaging exchange for a simple call scenario. In thisexample, the originating switch (i.e., the calling party’s serving switch) has a directbearer connection to the destination switch.

After it collects the dialed digits, the originating switch selects a bearer channelto allocate to this call and sends an Initial Address Message (IAM) towards the desti-nation switch. The IAM specifies the identity of the selected bearer channel.

When it receives the IAM, the destination switch sends an Address CompleteMessage (ACM) towards the originating switch and rings the called party’s phone.When the called party answers the call, the destination switch sends another mes-sage to the originating switch: namely, an Answer message (ANM). For a toll call,this is the signal that the originating switch should commence billing.

Suppose for the sake of discussion that the calling party hangs up first. Then theoriginating switch sends a release message (REL) to the destination switch, whichresponds with a release complete message (RLC).

In Figure 6.7, we have redrawn the call state model (see Figure 6.6) to reflect thatthe ISUP signaling exchange begins with an Initial Address Message, and that theactive state is reached once the Answer message arrives. To keep the diagram unclut-tered, we have used the abbreviations IAM and ANM, respectively. Since the modelis not very granular, the diagram does not offer suitable places for the other mes-sages described above.

For the most part, we will not include finite state machine diagrams in ourprotocol descriptions. Matters would quickly get too complicated. Recall, for exam-ple, that there is a counterpart to the FSM of Figure 6.7 in the destination switch.Suppose we drew versions of the originating and terminating ISUP state machinesthat were sufficiently granular to show all state transitions related to messages in the

58 Protocols

FSMs’ signaling dialog. If we then tried to interpose a schematic of the signalingflow itself, we would end up with a diagram that confused much more than itenlightened. Although complex FSMs are cumbersome to depict, it is important tokeep the FSM concept in mind.

We will often display sample signaling flows in so-called “ping-pong” dia-grams. In our first example, Figure 6.8, we render the ISUP signaling flow describedabove. In this diagram, the vertical “axis” no longer runs up and down the protocollayers. Instead, it represents time, which elapses as we proceed downward.

Before moving on, we note that ISUP runs directly on top of MTP3. Althoughthe standards allow for SCCP to be interposed between ISUP and MTP3, it is notnecessary to do so. To the best of our knowledge, no carrier has implemented ISUPover SCCP.


Active

Receive ANMRouting and alerting

Send IAM


Done collecting7 or 10 digits

Collectinginformation

Detect off-hookIdle

Detect on-hook

Detect on-hook

Figure 6.7 Revised call state model showing ISUP messages.

RLC

REL

...telephone conversation...

ANM

ACM

IAM

Destination switchOriginating switch

Figure 6.8 ISUP call flow diagram.

6.6 Summary

Although the ability to transmit bits across physical media is crucial to telecommu-nication, this capacity is only a part of the functionality that is present in any tele-communication network. One might be tempted to think of the remaining requiredfunctionality as being all of a piece. The complexity of the task is such that it needs tobe subdivided, however, and it is natural to build functionality in a layered fashion.

A protocol stack is a means of realizing all of the capabilities necessary forend-to-end communication. Protocol stacks are modular, and the main modules areusually called layers. As we move up a protocol stack from the physical layer, eachsubsequent layer builds on the functionality of previous layer(s). When network ele-ments talk to each other, they do so at a variety of layers simultaneously.

Let us elaborate on the last point. In a protocol stack running on a given net-work element, each layer is represented by a protocol entity. Protocol entities oper-ating at the same layer, but on different network elements, conduct dialogs byexchanging packets. Each layer has its own packet format that embodies the seman-tics of such a dialog. When a chunk of information is submitted by an upper-layerprotocol for transmission, packet headers are prepended by each layer as the data“descends” towards the physical layer. By the same token, headers are peeled off ofincoming packets (in last in, first out fashion) as those packets “ascend” the protocolstack.

How does one come to understand a given protocol? We know of no protocolthat functions all by itself. Therefore, as a starting point, one can describe how thatprotocol fits into a protocol stack. For such discussions, it is useful to have a point ofreference. In this chapter, we described the functionality associated with the physi-cal, data link, network, and transport layers. We looked at examples of protocolsthat are widely deployed today: namely, TCP/IP and various SS7 protocols. We sawsome of the major differences between the TCP/IP and SS7 protocol suites by relat-ing both to the framework of Table 6.1.

To understand the functionality of a given protocol, it also helps to examine thepacket headers used by that protocol. In Section 6.3.2, we discussed the TCP header.In the process of describing the semantics of several header fields, we outlined TCP’smain functionality.

For a more detailed understanding, one can look at protocol state machines. Weintroduced the notion of an FSM and gave a simplified example of a circuit-switchedcall model. State machine descriptions are useful for capturing the way protocolentities behave. State transitions in protocol state machines are often associated withreceipt or transmission of protocol messages.

Such an association reflects expectations. At each point in a signaling dialog,that is, a given protocol entity expects some types of messages and not others. In anFSM representation, points in the signaling dialog correspond to states. Receipt ofan unexpected message type might trigger a transition to an error-processing state,whereas receipt of a message type that is appropriate at this point in the signalingdialog leads to the next state in the “normal” progression. Protocol state machinestend to be complex. One reason for this is that they must provide for graceful han-dling of a wide variety of error conditions.

60 Protocols

Signaling flow diagrams provide a third way to understand signaling protocolfunctionality. These so-called “ping-pong” diagrams are quite useful; we willencounter a number of them as we proceed.

References

[1] Postel, J., RFC 793, Transmission Control Protocol, IETF, September 1981.[2] Stevens, W. R., TCP/IP Illustrated, Volume 1: The Protocols, Reading MA: Addison-

Wesley, 1994.[3] Wright, G. R., et al., TCP/IP Illustrated, Volume 2: The Implementation, Reading MA:

Addison-Wesley, 1995.[4] Stevens, W. R., TCP/IP Illustrated, Volume 3: HTTP, NNTP, and the Unix Domain Proto-

cols, Reading MA: Addison-Wesley, 1996.[5] Wilder, F., A Guide to the TCP/IP Protocol Suite, Norwood, MA: Artech House, 1998.[6] TS 29.002, Mobile Application Part, 3GPP.[7] Recommendation Q.761, Signaling System No. 7—ISDN User Part—Functional Descrip-

tion, ITU-T, December 1999.[8] T1.113, Signaling System, No. 7 (SS7)—Integrated Services Digital Network (ISDN) User

Part, ANSI, 2000.

6.6 Summary 61

C H A P T E R 7

A Closer Look at Internet Protocol

In this chapter, we will look at IP itself, as well as a number of related topics inIP-based networking. Since we will not be able to do full justice to these topics, wegive numerous references for further reading. Thus portions of this chapter read likean annotated bibliography. For those unfamiliar with the Internet Engineering TaskForce (IETF), it helps to know the following. Internet specifications begin life in theIETF as Internet drafts. Internet drafts that pass muster become requests forcomments (RFCs). There are a number of categories of RFCs (including informa-tional, best current practice, proposed standard, draft standard, and standard). AllRFCs are permanently available at www.ietf.org and www.rfc-editor.org, regard-less of category. By searching the latter URL, one can learn which RFC(s), if any,have obsoleted or updated a given RFC. IETF is organized into working groups;www.ietf.org also serves as a point of access to working groups’ charters and thedocuments they produce.

IPv4, which is currently predominant, appeared as an IETF RFC in 1981 [1].IPv4 has a number of shortcomings; IPv6 ([2] in its first incarnation, later sup-planted by [3]) was designed to overcome these deficiencies. The IPv4 embeddedbase is huge, so migration to IPv6 will take a long time. To facilitate a basic under-standing of IPv4 and IPv6 (and to get a glimpse of the differences between the two),we will examine the packet headers for both protocols.

Why Migrate to IPv6?

If the migration to IPv6 promises to be difficult, why undertake it at all? The maindriver is the size of the IPv4 address space: in a world where all sorts of devices (e.g.,mobile phones, vending machines, appliances) will “speak” Internet Protocol, theIPv4 address space will eventually be exhausted. When this exhaustion will occur isa matter of some debate.

What Happened to the Other Versions?

IPv4 was the first widely deployed version of Internet Protocol. There were two pre-cursor documents to the IPv4 RFC previously cited ([4] and [5], no longer active).But there was no IP version 1, 2, or 3 per se. (The version number indicates thatsome iteration took place before the Internet community settled on IPv4, however).Similarly, there is no IPv5 RFC. However, the Internet Stream Protocol (ST-II) pro-tocol specification [6, 7] stipulated that the “version” field in the IP packet headershould be set to 5.

63

7.1 The IPv4 Header

The IPv4 header format is displayed in Figure 7.1. In the following header fielddescriptions, field values (when specified) are given in hexadecimal. This is indicatedby the prefix 0x.

The value of the 4-bit Version field is, of course, 0x4. The 4-bit Header Lengthfield is reckoned in 32-bit words. With no options, the value of this field is 0x5 (or,in other words, a header with no optional fields is 20 bytes long). Since the maxi-mum expressible value in a 4-bit field is 0xF, we see that the maximum combinedlength of all optional fields is 10 words (which equals 40 bytes). We will discuss theDifferentiated Service/type of service (DiffServ/TOS) field when we look at qualityof service in Section 7.7.2.

Unlike the Header Length field, the 16-bit Packet Length field is reckoned inbytes. The byte count includes the packet header. The maximum value is 0xFFFF(which equals 65,535 decimal). Thus, when a datagram (that is, a chunk of data tobe transmitted) is larger than 64K, it must be fragmented into multiple IP packets.

The IPv4 header has several fields that relate to fragmentation, starting with the16-bit Identification field. This is set by the original sender of data and is copied intoeach fragment during the fragmentation process. The Reserved (RES) bit must be 0.If the Do Not Fragment (DF) bit is set to 1, then this packet may not be fragmented.The More Fragments (MF) bit is set to 0 if and only if this packet is the last fragmentof the datagram. The 13-bit Fragment Offset is reckoned in 8-byte units (unlike theHeader Length and Packet Length fields). It specifies the location of the fragment inthe reassembled datagram (i.e. the distance from the beginning of the datagram tothe beginning of the fragment).

In IP networks, transitory routing loops can arise. To ensure that packets do notgo around in circles for an extended period of time, the 8-bit Time To Live (TTL)field is decremented by 1 each time the packet traverses a router. If TTL reaches 0,

64 A Closer Look at Internet Protocol

Version

Header checksum

Fragment offset

Packet length

Options

Destination address

Source address

ProtocolTTL

Identification

DiffServ/TOSHeaderlength

FM

FD

SER

Figure 7.1 The IPv4 header.

the packet is discarded. So TTL, which is usually set to 0xFF by the packet’s creator,is the maximum number of routing hops. The 8-bit Protocol field specifies how thepayload of the packet should be interpreted (i.e. which protocol it adheres to).Examples include TCP (value 0x6). The 16-bit Header Checksum is used to verifythe integrity of the packet header. The Source and Destination Address fields areeach 32 bits long. As noted earlier, the total header length depends on the optionsselected; we omit details.

7.1.1 Fragmentation and Path MTU Discovery

The maximum transmission unit (MTU) of a path is the size of the largest (unfrag-mented) packet that can be transported across that path. Each link along the pathhas an MTU imposed on it at the data link layer; the path MTU is the minimum ofthe constituent link MTUs.

To determine the path MTU to a given destination [8], an IP node sends apacket whose size is the MTU of the egress link for that destination, setting the DFbit to 1. (Since the path MTU cannot exceed the MTU of the egress link, the nodetakes the latter as its “estimated MTU.”) If some router along the path cannot for-ward the packet because its length exceeds the MTU of the outoing link, that routerdiscards the packet and sends an Internet Control Message Protocol (ICMP [9])error message back to the originating node. The MTU of the outgoing link isincluded in the ICMP message. Upon receipt of this message, the originating nodetherefore has a new estimated MTU; it repeats the process until it stops receivingICMP error messages.

Note that, if the DF bit is not set to 1, intermediate routers will simply fragmentthe packet as necessary and send it on its way. In the process, the correct fragmentoffset must be computed and the MF bit must be set to the appropriate value in eachfragment. Lastly, we note that not all IPv4 endpoints implement path MTUdiscovery.

7.2 The IPv6 Header

The IPv6 header, which has a fixed length of 40 bytes, is displayed in Figure 7.2. Thefirst thing to point out is that the following IPv4 header fields are omitted altogetherfrom the IPv6 header: Header Length; RES, DF, and MF bits; Fragment Offset; andHeader Checksum. These are the shaded fields in Figure 7.1.

The 4-bit Version and the Source and Destination Address fields (which are 128bits each) correspond to the IPv4 header fields of the same names. The 8-bit trafficclass field is analogous to IPv4’s DiffServ/ToS field; see Section 7.7.2. The 20-bitFlow Label field, which has no counterpart in the IPv4 header, is used to identifyindividual traffic streams or aggregates. The use of the Flow Label still seemsill-defined, although a recent RFC [10] gives a basic description. IPv6’s 16-bitPayload Length field is reckoned in bytes. Payloads larger than the nominal limit of65,535 bytes can be accommodated by setting this field to 0 and appending a “jum-bogram” extension header. The 8-bit Next Header field replaces IPv4’s protocolfield and expands its role: the next header can be a higher-layer Protocol header

7.2 The IPv6 Header 65

(e.g., TCP or UDP) or an IPv6 extension header. The 8-bit Hop Limit field serves thesame function as IPv4’s TTL field (and is more aptly named).

Recall that several IPv4 header fields lack counterparts in the IPv6 header. Theabsence of one of those fields, the Header Checksum, indicates that error detection isleft to other layers. Of the six omitted fields, four (Identification, DF, MF, and Frag-ment Offset) are used to manage fragmentation. For reasons of efficiency, IPv6 doesnot support packet fragmentation by routers so clearly there is no need for a DFheader bit. Except for this difference, path MTU discovery in IPv6 [11] usingICMPv6 [12] proceeds as described in Section 7.1.1. All IPv6 interfaces must sup-port MTUs of at least 1,280 bytes (although the standards say that IPv6 nodesshould perform path MTU discovery to take advantage of larger MTUs wheneverpossible).

7.2.1 IPv6 Extension Headers

Although IPv6 routers do not fragment packets, IPv6 endpoints can fragment pack-ets. TCP and SCTP support fragmentation and reassembly, so in many cases frag-mentation at the IP layer is unnecessary. Note, however, that UDP does not have anysuch facility. Whenever an IP source node fragments an IPv6 packet, it needs to tellthe destination node how to reassemble that packet. For this purpose, Identification,MF, and Fragment Offset fields accompany each fragment, just as they do in IPv4.However, these fields are relegated to an IPv6 extension header, which can be safelyignored by intermediate nodes.

In the interest of performance, the IPv6 header is streamlined so that processingat routers is held to a minimum. The fragment header is not the only IPv6 extensionheader; numerous others are defined. Examples include routing, authentication, andtwo kinds of security headers. Like the IPv6 header itself, each extension header hasa Next Header field. So extension headers can be “daisy-chained” between the IPv6header and the transport layer header.


Destination address

Source address

Hop limitNext headerPayload length

Flow labelTraffic classVersion

Figure 7.2 The IPv6 header.

In some cases, additional processing is required at intermediate nodes. In thiscase, a hop-by-hop options extension header is used; when present, this must be thefirst extension header after the IPv6 header itself. When an intermediate nodereceives an IPv6 packet, it can therefore look at the Next Header field to find outwhether a hop-by-hop extension header is present. If not, then all extension headersare ignored. This contrasts with IPv4, in which routers must examine all of theoptions that are present in IPv4 headers. When a packet contains a routing exten-sion header (which is used to explicitly specify nodes to visit en route), the destina-tion address in the IPv6 header may not reflect the packet’s ultimate destination.

7.3 Addressing and Address Resolution

7.3.1 Conserving IPv4 Address Space

In the early 1990s, blocks of IPv4 addresses were being consumed at an alarmingrate. When an organization requested a block of addresses from the central author-ity, it was normally assigned either a so-called “class C” block (each of which con-sisted of 254 host addresses) or a “class B” block (which consisted of 65,534 hostaddresses. For completeness, we note that address classes A, B, and C are defined,alongside IPv4 itself, in RFC 791 [1].) Many an organization that was too large for aclass C block received a class B block, even if it really only needed a few thousand IPaddresses. To stave off exhaustion of the IP address space, classless inter-domainrouting (CIDR [13, 14]) was developed.

People also came to realize that, for hosts to communicate within private IP net-works, globally unique IP addresses were unnecessary. IETF RFC 1918 formally setaside portions of the IPv4 address space for private use [15]. Private addresses canbe (re)used internally by any number of organizations.

Network Address Translation

Suppose we assign a private IP address to a host. How can we connect that host tothe public Internet? This is routinely accomplished using network address transla-tion (NAT, [16]). This is really an umbrella term, since there is more than one kindof NAT. We do not give details; however, the general idea is that an intermediatenode (which is also called a NAT) acts as a gateway to the public Internet. Wheneverit receives a packet from a private host (that is, a host that has been assigned a pri-vate IP address), the NAT replaces the source address with a globally uniqueaddress. At the transport layer, the source port number may also be altered. Forincoming packets destined to the private host, the NAT must perform the reversetranslation on the destination address. Note that NATs are stateful: they must keeptrack of bindings between address/port number pairs on their private and publicinterfaces.

How does this conserve IP addresses? The bindings are established temporarilyon a per session basis. Moreover, many internal hosts can be represented by thesame IP address when they talk to the outside world. That is, many private IPaddresses can be bound to the same external IP address so long as different portnumbers are used.

7.3 Addressing and Address Resolution 67

So NAT promotes efficient use of globally unique IP addresses. It also enhancesprivacy, since the bindings already described are transitory. But NAT also createsproblems, notably in the realm of scalability. Moreover, IP addresses are used inmany higher-layer protocols. These encapsulated IP addresses are not alteredby NATs per se. Instead, the necessary translations are performed by so-called appli-cation level gateways (ALGs). ALGs know where to find IP addresses withinhigher-layer protocol messages. ALGs often reside on NAT devices but are trouble-some for a number of reasons. Among them is the following: when a new applica-tion layer protocol comes along, ALG functionality has to be upgraded to support it.In addition, NAT traversal is a problem for end-to-end security associations.

Dynamic Host Configuration Protocol

Dynamic Host Configuration Protocol (DHCP) is another scheme for conserving IPaddresses through reuse. Servers (e.g., Dial-Up servers) at Internet service providerstypically have pools of IP addresses at their disposal. As part of the sign-on process,such a server will temporarily assign an IP address to the user in question. When theuser logs off, his/her IP address is relinquished and returned to the “available” pool.

DHCP has the added benefit of making networks easier to administer: host IPaddresses are assigned on the fly, without intervention by network managementpersonnel.

7.3.2 The IPv6 Address Space

The IPv6 address space is subdivided into a number of address categories, as speci-fied in RFC 3513 [17]. (We note here that a current Internet draft sets forth a revisedversion of the architecture described in RFC 3513; the reader can keep abreastof the latest developments by visiting the IPv6 working group’s home page atwww.ietf.org.) Address types include unicast, anycast, and multicast. We will notcover anycast or multicast addressing in any detail. However, we offer the followingexamples. To find a nearby subnet router, an IPv6 host can use a well-known any-cast address. Predefined well-known multicast addresses include “all routers.” Notethat IPv6 addresses have well defined scopes, so “all routers” does not mean “allrouters in the entire world.” In this regard, we also note that IPv4 defines broadcastaddresses, but IPv6 does not.

The Unicast address space is further subdivided into Globally Unique addresses,Link-Local addresses and other categories which we do not enumerate. Usage of theformer is defined in [18]. The lower-order 64 bits is typically a globally unique Inter-face ID whose format is defined by the Institute for Electrical and Electronics Engi-neers (IEEE). The higher-order 64 bits are ‘001’ followed by a 45-bit global routingprefix and a 16-bit subnet ID. In the so-called Stateless Autoconfiguration process[19], an IP node supplies the lower-order 64 bits of its IP address and obtains thehigher-order 64 bits from the network. There is precedent for this type of approach.For example, the ATM Forum’s Integrated Local Management Interface (ILMI)specification [20] defines a similar scheme for configuring ATM nodes.

In the interest of privacy, there is a variant of the aforementioned autoconfigura-tion scheme in which the lower-order 64 bits are randomly generated. This variant


requires an additional capability to make sure that no two systems in the samedomain are assigned the same lower-order 64 bits.

In closing, we note that the IETF initially defined IPv6 site-local addresses.Site-local addressing was supposed to be IPv6’s version of IPv4 private addressingbut has recently been deprecated. At the time of this writing, a consensus alternativeto site-local addressing had not yet been defined.

7.3.3 Uniform Resource Identifiers and Domain Name System

When users access resources in IP networks, usually there is a level of indirectioninvolved. For example, although one can enter a “raw” IP address in a Webbrowser, it is far more common to enter a universal resource identifier (URI)instead. URI syntax is defined in IETF RFC 2396 [21], which says that a URI is “acompact string of characters for identifying an abstract or physical resource.”Regarding the distinction between URI and the better-known term UniformResource Locator (URL), RFC 2396 says that a URI can be a locator, a name, orboth. Moreover, “The term ‘uniform resource locator’ (URL) refers to the subset ofURI that identify resources via a representation of their primary access mecha-nism...”[21]. We will use the terms URL and URI interchangeably.

To access a host across an IP network, its IP address must first be obtained.(This is normally transparent to the end user.) Domain name system (DNS [22, 23])resolves URIs (such as http://www.cingular.com) to IP addresses. To access DNS, itis necessary to have the IP address of a DNS server; DNS server addresses are oftenentered manually when computers are configured for network access.

In summary, DNS implements bindings between URIs and IP addresses.URIs have the obvious mnemonic benefit (i.e., that http://www.cingular.com iseasier to remember than an IP address). A less obvious benefit is this: any changesto the IP address of Cingular Wireless’ Web server are transparent to Web users.As long as the appropriate DNS binding is kept up to date, users can reach theWeb site.

7.4 Security and AAA

7.4.1 Security

Security is a multifaceted subject. Within the IETF, there is not a single securityworking group that has the last word on this subject. Rather, there is a security areain which there are some 21 active working groups. Moreover, every new RFC incor-porates a “security considerations” section. We mention only two of the groups inthe security area:

• The Transport Layer Security (TLS) working group has produced RFC 2246[24], which defines the TLS protocol. TLS is widely deployed. For example,URIs that begin with “https:” refer to resources that run HTTP over TLS.(Often, such a URI will appear in a browser window when a secure transac-tion, such as entry of credit card data, takes place.)

7.4 Security and AAA 69

• The IP Security Protocol (IPSec) working group has issued many RFCs, includ-ing a batch consisting of 12 RFCS (numbered 2401–2412) in the fall of 1998.From that batch, we single out two overview documents [25, 26] along withauthentication header [27], encapsulation security payload [28], and twospecifications dealing with encryption keys [29, 30].

7.4.2 Authentication, Authorization, and Accounting

How do users gain access to services in IP networks? How do service providers col-lect information necessary to bill for services and otherwise monitor the use of theirnetworks? These issues are usually lumped together under the heading “authentica-tion, authorization and accounting (AAA).”

The most widely deployed AAA protocol is Remote Authentication Dial-In UserService (RADIUS). As the name suggests, this protocol was developed to fill a void indial-up networking. This usage is well documented in RFC 2865 [31], the baselineRADIUS specification, and numerous other RFCs generated by the RADIUS work-ing group (which is now concluded). RADIUS deployment has gone far beyond itsinitial milieu (it is the de facto AAA protocol for IP networks), but documentation of“extended” use cases is uneven.

In many cases, a host that wants to gain access to an IP network must contacta DHCP server to obtain an IP address and must also successfully complete AAAprocedures. Thus DHCP and RADIUS protocol entities often reside on the sameserver.

RADIUS does what it was designed to do, but it is now deployed in settings thatexpose its limitations. To overcome these limitations, IETF’s AAA working grouphas crafted a successor protocol called Diameter [32], which recently reached RFCstatus after many delays. Diameter has been a contentious issue in the IETF, as manypeople thought it would be better to develop an enhanced version of RADIUS ratherthan a new protocol.

Diameter requires the use of a transport layer security scheme (such as TLS orIPSec), whereas RADIUS does not. RADIUS normally runs over UDP and does notspecify congestion control functionality, whereas Diameter runs over SCTP or TCP(and can therefore benefit from the transport layer protocol’s congestion controlcapabilities). Moreover, Diameter makes explicit provisions for failover scenarios,whereas RADIUS does not. Diameter specifies error message formats (whereasRADIUS does not) and specifies proxy behavior more completely than its predeces-sor. Moreover, Diameter defines three other kinds of “agents” (in addition to proxyagents): relay agents, redirection agents, and translation agents. Diameter maintainsmore state information than RADIUS; in particular, Diameter has notions of sessionstate and transaction state.

Diameter’s additional functionality does not come for free—it generates muchmore overhead than is necessary to run RADIUS. This is a major reason that indus-try support for Diameter has not been unanimous. At this point, RADIUS is still thedominant AAA protocol and it is not clear how soon Diameter will be widelydeployed.


7.5 Routing

Many routing protocols incorporate optimization algorithms. Before discussingInternet routing protocols, it is helpful to look briefly at network optimization ingeneral. In a nutshell, the point we want to make is this: ideally, one would like todetermine routes by solving a multicommodity network flow problem. (We describethis class of problems in the next section.) But the difficulties of doing so in distrib-uted fashion are substantial. In large networks, the difficulties are in fact pro-hibitive. So data network routing protocols are, of necessity, based on simpleroptimization problems. Significant limitations result; we elaborate now.

7.5.1 Network Optimization

Network optimization refers to the family of optimization problems that can beposed in terms of graphs. A graph consists of nodes and interconnecting arcs. In ourcontext, network elements such as voice switches and IP routers are the nodes andtransmission links are the arcs. We will use the terms arc and link interchangeably.

Network optimization is not limited to telecommunications. Transportationauthorities and shipping companies apply optimization techniques to networks ofroads, electric companies apply such techniques to power grids, and so on. As aresult, the literature in this general subject area is vast.

In this section, we introduce three well-known categories of network optimiza-tion problems: shortest path, minimum cost spanning tree, and multicommoditynetwork flow. In each of these categories, a cost of traversal is assigned to each link.

The shortest path problem is the easiest to describe. In it, origin and destinationnodes are given, and the objective is to find a minimum cost path from origin to des-tination. The cost of a path is the sum of the costs of its constituent arcs.

A tree is a graph with the following property: for any pair of nodes, there is oneand only one interconnecting path. The cost of a tree is the sum of the costs of itsarcs. For a general graph a spanning tree is simply a tree that contains all of thenodes in the original graph (and whose arcs are part of the original graph). With thisterminology in hand, the objective of the minimum cost spanning tree problem isself-explanatory.

Shortest path algorithms usually solve simultaneously for shortest paths from agiven originating node to all possible destinations. This can be done efficiently, aswas first demonstrated by Dijkstra [33]. The union of the solution paths is a span-ning tree. (Note, however, that it is generally not a minimum cost spanning tree.)

Network flow problems have additional structure. As a result, they are able tocapture the relationship between demand and the resources necessary to satisfy thatdemand. Each link has a specified capacity. We are also given demand information:a number of units of some commodity that we must transport from origin to desti-nation. This quantity is given separately for each origin-destination pair; commodi-ties associated with different origin-destination pairs are not fungible (hence theterm “multicommodity”). The objective is to satisfy demand at minimal cost. Notethat the cost of traversing a link is a function of the total commodity flowingthrough that link (e.g., in the linear case it is proportional).

7.5 Routing 71

Objectives

The usefulness of an optimization model depends on how well its objective functionreflects what we are trying to do. Objectives vary from problem to problem. A truck-ing firm might seek to minimize total mileage traveled, viewing this as a proxy forfuel consumption. In this case, the arc costs would be intercity mileages. A designerof enterprise data networks might seek to minimize some metric of congestion ordelay. A telco might seek to minimize blocking probability, viewing this as roughlyequivalent to maximizing the total number of calls carried or minutes of use. In thiscase, the objective would be a nonlinear function of the offered load.

Limitations of Optimization Models

Shortest path and minimum cost spanning tree problems are always feasible, so longas the underlying graph is connected (i.e., for any pair of nodes, an interconnectingpath exists).

The first thing to notice about network flow problems is that they are not alwaysfeasible: the demand may outstrip the arc capacities. One can also model congestionin the network flow context (although we must employ nonlinear arc costs to do so).So network flow formulations capture an essential feature that is not reflected at allin shortest path or spanning tree formulations.

In a real-world network, the state of the system evolves dynamically over time.For an airline, weather-induced delays at one airport disrupt the whole system. For atelecommunications carrier, traffic load is constantly changing. Traditional optimi-zation models do not capture the dynamics of time-evolving systems very well.There are various approaches to ameliorating this basic difficulty; each approachhas a different set of strengths and weaknesses.

7.5.2 Internet Routing Protocols

Let us now look at routing in IP networks, with a mind toward understanding thechoices that have been made, the reasons for those choices, and the trade-offs thatresult. Rather than covering the protocols in detail, our intent is to give just enoughinformation to support this goal.

Simply stated, the philosophy behind Internet routing protocols is to adaptdynamically to changing network conditions while making as few assumptions aspossible about traffic patterns. The crux of the problem is this: each IP router mustmake forwarding decisions for the packets it receives on the basis of very limitedinformation regarding the state of the network as a whole.

Multicommodity network flow formulations are not tractable in large net-works. Network flow algorithms do not lend themselves to distributed implementa-tions. Moreover, it is not practical to solve a network flow problem in a centralizedlocation and distribute the pertinent results to a large population of IP routers. Inparticular, updating numerous routing tables in accordance with changing networkconditions becomes very problematic.

7.5.3 A Link State Protocol: OSPF

Most IP routing protocols are based on shortest path formulations. Open ShortestPath First (OSPF, [34]) is widely deployed and probably the best-known example.


OSPF messages carry so-called link state advertisements (LSAs). LSAs are origi-nated by routers adjacent to the links in question and are propagated about anOSPF domain. Of the many types of information that can be carried in an LSA, wemention the following three:

• Adjacency information that allows receiving routers to determine the topolo-gies of the networks they inhabit;

• Information that allows routers to determine whether an incoming LSA isnewer than the current entry in its link state database;

• Link cost information. Link costs are normally inversely proportional to theircapacities.

This description is oversimplified but should serve to get the general idea across.Each OSPF router derives a view of the network topology from the LSAs it

receives. It then runs a Dijkstra algorithm against this topology when it builds itsrouting table. So each OSPF router makes forwarding decisions based on its ownrouting calculations, and we can therefore say that OSPF routing is distributed.Ironically, OSPF’s shortest path calculation is not distributed.

7.5.4 Distance Vector Protocols: RIP and BGP

Shortest path calculations can be done in distributed fashion. Routing InformationProtocol (RIP [35–38]) takes this approach. Each RIP router builds a distance vec-tor; that is, a roster of all other routers in the domain and the shortest-path distancesto each of those routers. Distance vectors are flooded throughout the network. For atime, inaccurate distance vectors are circulating—routers initially only know oftheir immediate neighbors, for instance, and “shortest seen so far” distances arenot truly optimal in general. Each router eventually reaches optimality, however.Distance vector protocol entities do not model network topology: for each destina-tion, each router knows which of its neighbors is the optimal next hop, butnothing more.

In large networks, RIP suffers from two major flaws: routing tables do not con-verge very quickly (see Section 7.5.5 for discussion), and routing informationexchanges consume an immodest amount of transmission bandwidth. RIP predatesOSPF; the latter was developed to overcome the shortcomings of RIP.

RIP and OSPF are known as interior gateway protocols. Exterior gateway pro-tocols provide a means of distributing routing and reachability information amongOSPF domains (as well as domains that run RIP or other IP routing protocols). Bor-der Gateway Protocol (BGP [39]), a distance vector protocol, is most commonlyemployed for this task. Given the fact that operators do not wish to fully divulgetheir network topologies, it makes sense that BGP is not a link state protocol.

7.5.5 Routing Protocol Convergence

Each routing protocol must specify exactly what information is exchanged amongrouters and how that information is propagated. This aspect of protocol design isjust as important as the associated shortest path algorithm itself.

7.5 Routing 73

Dynamic routing requires that routing information be updated (this is done inresponse to detected outages and also in the form of periodic refreshes). It is espe-cially important to realize that full propagation of routing information does nothappen instantaneously, especially in a large network. Thus, when a link outageoccurs, some routers will be acting on outdated topology information longerthan others. This results in transient routing loops. A simple example is depicted inFigure 7.3.

Suppose that the three links drawn with heavy lines have the same transmissioncapacity, and that the Philadelphia-Baltimore link has smaller capacity than thesethree. Then, under normal circumstances, the router in Chicago (or simply“Chicago” in what follows) will route Baltimore-bound traffic via Atlanta. In thefigure, the Atlanta-Baltimore link has just gone down. Atlanta, which becomesaware of the outage before Chicago does, bounces Baltimore-bound packets back toChicago, which in turn sends them to Atlanta, and so on.

The routing loop in our example will go away quickly. Let us suppose that therouters shown inhabit a single OSPF domain. Then Atlanta will tell its remainingneighbors of the outage by sending a link state advertisement (as will Baltimore). Assoon as it becomes aware of the link outage, Chicago:

• Recomputes its routing table by running a Dijkstra algorithm against theupdated topology;

• Forwards the advertisement to its neighbors.

When routers in a network are all acting on correct routing information, we saythat their routing tables have converged. Note that:

• While they exist, routing loops can cause severe congestion on their compo-nent links.

• In large networks, routing information takes time to propagate. So routingloops can persist for long enough to cause trouble.


Philadelphia

Atlanta

Baltimore

Baltimore

Baltimore

Chicago

To other cities...

To other cities...

To othercities...

Figure 7.3 Simple routing loop example.

Why is OSPF generally preferable to RIP? When a link outage occurs, it is moreefficient all the way around to say so explicitly. RIP does not have a good way to dothis (although RIP does at least offer a way to mark a route as invalid).

7.5.6 Scalability

So far, we have assumed that each IP router knows about every other router in thenetwork. But this can only be true in a limited way for reasons of scalability (whenthe number of nodes in a network is very large, every node would otherwise have tomaintain a large routing table) and security (operators do not want to divulge theirnetwork topologies to hackers, or even to each other).

Because of its scalability limitations, RIP is only deployed in private networks ofmodest size. OSPF supports the subdivision of networks into areas. Each router hasfull topology information about its own area but only summary information aboutother areas in the same network. In an OSPF domain, one area is designated as thebackbone area; it is responsible for distributing routing information between areas.Even with the introduction of areas, OSPF has scalability limits. Security andscalability are the main reasons for the existence of exterior gateway protocols suchas BGP.

7.5.7 Trade-offs

Load Balancing and Routing Hot Spots

Often there are equal-cost paths to the same destination. Let us return to theexample of Figure 7.3, but now assume that the four links connecting Chicago,Atlanta, Baltimore, and Philadelphia all have the same capacity. We assume thatlinks of the same capacity have the same cost of traversal. Since this assumptiontypically holds true, minimum cost routing often devolves to minimum hop-countrouting. (The hop count should be roughly proportional to the amount of process-ing required to transmit packets across a given path, and so it is a very reasonablemeasure of cost.)

Since the two paths connecting Chicago and Baltimore have equal costs, how dowe choose between them? Ideally, we would like to balance traffic among these twopaths, but this is not as simple a matter as it might initially seem. One possibleapproach is to subdivide the block of “Baltimore” addresses, sending packets des-tined for one sub-block via Philadelphia and the other sub-block via Atlanta. How-ever, such a scheme would not adapt to variations in sub-block traffic volumes.Note also that traffic bound for various destinations other than Baltimore traversesone or more of the links appearing in Figure 7.3, so concentrating purely on trafficto Baltimore may not yield a satisfactory result for those links.

IP networks tend to have bottleneck links (or routing hot spots). Even if there isdiversity of equal-cost paths between traffic hubs, routing protocols do not tend todistribute traffic evenly among these paths. To be fair, load balancing schemes areused to advantage in IP networks. But we generally think of these schemes as blunttools—they are insufficient for eliminating hot spots altogether.

7.5 Routing 75

Affecting Routing by Adjusting Link Costs

If we adjust link costs, routing will be affected. For example, we might decide thatthe cost of traversal for a congested link should be high. There are two difficultieswith effectively implementing this simple idea. The first is this: how would a routerlearn that a remote link (let us call it link L for definiteness) is congested? The end-point(s) of link L would have to inform the rest of the network. Since congestion is atime-varying phenomenon, and it takes time for link state information to propagatethrough a routing domain, link L may not be overloaded by the time all routingtables have converged.

There is also the question of frequency—how often should link status informa-tion be circulated? If updates are infrequent, routers are acting on outdated informa-tion. But frequent updates consume significant bandwidth that could otherwise beused for bearer traffic. Stability is also a problem: in avoiding link L, routers maycause other link(s) to congest. When link updates describing the new network statepropagate, the pendulum may swing back to the state in which link L was over-loaded (in which case the cycle begins again).

7.6 Reachability Information

In the example of the previous two sections, all of the nodes are IP routers. However,end users want to access hosts (such as Web servers and e-mail servers); routers arejust transit points along the way. To facilitate communication between hosts, rout-ers advertise reachability to blocks of IP addresses. We will not cover this aspect ofrouting protocols in any detail. But to give the reader a rough idea of what we mean,let us pretend for a moment that routing in legacy telephone networks was entirelyanalogous to routing in IP networks (of course, this is not the reality). Then one ormore switches in Chicago would advertise reachability to the 312 area code,switch(es) in Atlanta would advertise reachability to the 404 area code, and so on.Such an advertisement would, in the first case, essentially boil down to saying: “ifyou want to call anyone in the 312 area code, route the call to me and I can handle itfrom there.” Reachability advertisements would be circulated throughout the net-work so that calls could be properly routed regardless of their origination points.

7.7 Quality of Service and Statistical Multiplexing

We believe that quality of service (QoS) in IP networks faces two main implementa-tion hurdles:

• Statistical multiplexing will “take a hit.” We explain this statement in thenext section.

• Increased control-plane complexity will be necessary.

In addition to the technical aspects of these problems, there has been somereluctance from a philosophical point of view. In the IETF, there has traditionallybeen a distaste for complex control-plane signaling. To emphasize this point, we


could use the word “heavyweight”: one might imagine a network that is boggeddown by a ponderous control “superstructure.” Can a robust, scalable QoS imple-mentation be developed with a lightweight approach to control? This question is sogeneral as to be almost rhetorical, but it may be worthwhile to keep in mind as weembark on our discussion of IP QoS.

Let us imagine a conversation between a data-networking expert and a cir-cuit-switching expert. Both have read an article that hypes convergence between thedata networking and voice domains; they are discussing the article. The cir-cuit-switching expert might very well say: “Whatever you do, don’t mess up myquality of service.” The data-networking expert’s retort might be: “It’s fine with meif you want to carry voice on my network, as long as you don’t mess up my statisti-cal multiplexing.”

In our current context, QoS will mean guarantees on bit rate, latency and jitter.Voice is a delay-sensitive application, so the importance of latency is easy to under-stand. Not only do digitized voice samples need to make it across the networkquickly, they also need to arrive at the decoder at very regular intervals (low jitter).Bit rate guarantees are necessary to make sure that voice samples are delivered in thefirst place (rather than dropped at a congestion point somewhere along the way).

Historically, developments in the data networking domain have not been muchconcerned with QoS. This makes sense, as traditional data networking applicationssuch as e-mail and Web access are not particularly delay-sensitive. The “classical”data networking protocol suite (particularly TCP/IP) is, however, designed toexploit statistical multiplexing to the fullest.

We say that traditional data networking employs a best-effort service model.We have seen that TCP tries to make the best use of available transmission capacity;if packets get lost along the way, it resends them and adjusts its flow parametersaccordingly. Thus we could say that reliability (in the form of TCP retransmissions)is implemented at layer 4. The IP QoS framework that we discuss later in this sectionrepresents a real sea change for the Internet community—we will see that QoS isimplemented at layer 3 and below.

7.7.1 What Is Statistical Multiplexing?

Data traffic tends to be bursty. Suppose several computer users are sharing the samelink to the Internet; all are periodically generating bursts of traffic as they downloadweb content. The main idea of statistical multiplexing is this: the users’ traffic burstsare likely to happen at different times and are therefore unlikely to interfere withone another.

Of course, if the number of active users sharing a limited amount of bandwidthis extremely large, congestion will result. But the number of users that can be sup-ported without chronic congestion is surprisingly large. The reason is that bursts areinterspersed with periods of inactivity; during periods of inactivity, users consumeessentially no bandwidth.

Telephone networks allocate a constant bit rate to each call (throughout the lifeof the call); whenever either participant wants to speak, the bandwidth is there.

By now it is probably clear that QoS and statistical multiplexing are competingobjectives. To deliver QoS, one must relinquish a certain amount of statistical

7.7 Quality of Service and Statistical Multiplexing 77

multiplexing. That is, suppose we want to implement packet telephony on a largescale and support carrier-grade voice quality in the bargain. Then it is not possible toachieve the same degree of statistical multiplexing that is now de rigueur inbest-effort data networking.

7.7.2 Differentiated Services

Preliminary note on terminology. The usage of the Type of Service octet in the IPv4header has evolved over time, and the terminology has changed. Along the way,RFC 2474 [40] defined the meaning of this header field, essentially renaming it theDiffServ (or DS) field. RFC 2474 attached the same nomenclature to IPv6’s TrafficClass header field. DiffServ only uses the six most significant bits of the octet inquestion, however; RFC 3260 [41] sets the record straight by formally defining thesebits as the so-called DSField. (Meanwhile, RFC 3168 [42] assigned the remainingtwo bits to Explicit Congestion Notification.)

The DiffServ Architecture. Most discussions of QoS in IP networks mentionDiffServ somewhere along the way. In the DiffServ approach, complex packetclassification and traffic conditioning functions (such as shaping and policing) onlyneed to be implemented at network boundary nodes. In contrast, each intermediatenode along a given traffic stream’s path is only required to perform comparativelysimple functions in handling that traffic. This approach is taken so that scalability isnot compromised; it is also consistent with the general preference, described at thebeginning of our QoS discussion, for lightweight control. DiffServ RFCs include [40,43, 44]; for a complete rundown, one can consult IETF’s DiffServ working group(which is now concluded).

The “comparatively simple functions at intermediate nodes” previously men-tioned are called per-hop forwarding behaviors (PHBs). A PHB defines a means ofallocating buffer and bandwidth resources at each node among the traffic streamsthat compete for these resources. PHBs are selected using the DiffServ Code Point(DSCP). A DSCP is six bits long and is “encoded” in the aforementioned DSField inthe IP header. The DiffServ working group issued standards-track RFCs definingtwo classes of PHBs:

• Expedited Forwarding (EF) provides the ability to configure a bit rate (R, say)and guarantee that high-priority packets (i.e., those with DSCPs indicatingthat they should receive EF treatment) are served at an aggregate rate of atleast R. Details appear in [45–47].

• Assured Forwarding (AF) defines four classes of packets, providing a means ofdividing buffer and bandwidth resources among those four classes. Relativeimportance of packets within the same class can be distinguished by means ofthe so-called “drop precedence” value. See [48] for details.

Although it may not be obvious from the names, Expedited Forwarding is muchmore stringent than Assured Forwarding. The former is oriented towards “hard”QoS guarantees, whereas the latter is not. Of the two, Assured Forwarding is muchmore widely used.


The DiffServ framework allows for other classes of PHBs to be defined in thefuture, and anticipates that service providers may want to tailor the DSCP-to-PHBmapping to fit a wide variety of traffic requirements. This aspect of DiffServ is stillevolving.

Before DiffServ, There Was IntServ

The so-called Integrated Services (IntServ) model emerged from early work on IPQoS. In the IntServ approach, resources (e.g., buffer and bandwidth) can be explic-itly allocated to specific packet streams, or flows. Indeed, one of the stated assump-tions in the architectural overview document [49] is that such explicit resourcemanagement is necessary to meet the requirements of real time applications.The Resource ReSerVation Protocol (RSVP) protocol specification [50] was laterproposed as the resource management mechanism [51]. The mentality of the latterRFC is, at least in part, that individual applications can signal their requirements.To many in the Internet community, this smacked of a heavyweight control plane;as a result, IntServ as specified in the RFCs above has received a lukewarmreception.

7.7.3 Multiprotocol Label Switching

Let us first discuss the original motivation for multiprotocol label switching(MPLS). “Wide area” connections between IP routers usually traverse layer 2switches and are usually static. Such static connections are manually provisionedusing management software that has no awareness of layer 3. (Recall that IP routersbase their forwarding decisions on the contents of IP headers; we say that they oper-ate at layer 3. Note that it would be very expensive to deploy a router in place ofeach intermediate layer 2 switch. Moreover, latency would increase.) This begs thequestion: “is it possible to automate the process of interconnecting routers?”

A wide area connection is necessary whenever the routers to be linked are toodistant to reside on the same local area network (so the “layer 2 interconnect” issuehas come up repeatedly). The question of how to approach the aforementionedautomation, especially for ATM at layer 2, was a topic of intense debate in themid-1990s. The MPLS philosophy is that routing for layer 2 interconnectionsshould be informed by the intelligence already present in IP routing protocols suchas OSPF and BGP. MPLS eventually established itself as the frontrunner amongcompeting “IP over ATM” schemes. It took time for the MPLS specifications to sta-bilize—early in 2001, the IETF formally released a batch of MPLS RFCs. We thinkof [52–54], as the “foundational” RFCs; RFCs [55–59], which were released at thesame time, nail down details (particularly for ATM and Frame Relay). ATM andFrame Relay are today’s predominant layer-2 technologies in wide area networks;they are briefly described in Appendixes A.3 and A.2, respectively. Ethernet is mak-ing inroads into this market, but Ethernet-MPLS interworking is not standardizedas of this writing; see Section A.4 in the appendix.

In summary, MPLS sets up paths at layer 2; these are called label switched paths(LSPs). On the one hand, LSP routes are determined by Internet routing protocols.On the other hand, IP packet headers are examined only at LSP ingress and egress

7.7 Quality of Service and Statistical Multiplexing 79

nodes. (That is, a node in the “interior” of an LSP can forward the associated trafficstream without going to the effort of examining IP headers.)

MPLS and IP QoS

What does all of this have to do to do with QoS in IP networks? First, resources (e.g.,bandwidth) and even routes can be explicitly assigned to LSPs. Two proposedschemes incorporate such functionality into the MPLS framework. One approach[60, 61] is based on RSVP (see the IntServ discussion in Section 7.7.2); the secondapproach [62–64] is quite different.

Second, incoming packet streams can be mapped to LSPs based on their QoSrequirements. As an illustration, different traffic classes headed to the same destina-tion might be assigned to different LSPs. As one might expect, work in this directionseeks to harmonize MPLS with DiffServ [65].

The topics mentioned in this section are quite immature. DiffServ and MPLS areboth relatively young at the time of this writing, so it is natural to expect that their“confluence” is quite early in its maturation cycle.

7.7.4 “DiffServ at the Edge, MPLS in the Core”

To the degree that there is a consensus approach to IP QoS, it can be summed up bythe phrase “DiffServ at the edge, MPLS in the core.” Roughly speaking, we can envi-sion this in the following way:

• DiffServ marking is performed on packets entering a given IP domain. Thismeans that the DiffServ/Traffic Class field in each IP packet header is set to avalue that reflects the application’s QoS requirements.

• On relatively low-capacity links near the edges of the domain, IP routersimplement appropriate per hop behaviors for each class of traffic.

• LSPs will traverse high-capacity links in the core of the network. Such an LSPwill aggregate traffic from many sessions having similar QoS requirements.More specifically, the traffic is aggregated at LSP ingress, transported throughthe core, and deaggregated at LSP egress.

We will return to this topic when we discuss traffic engineering in Section 15.1.

7.7.5 Multiservice Networks

For a number of years, the IP networking faithful (and ATM boosters before them)have touted the promise of voice, video, and data over the same network. It is a wor-thy goal, and the idea of offering a rich variety of revenue-generating services over asingle backbone is a compelling one. In the short and medium terms, however, webelieve it will be very hard to live up to the hype.

Let us qualify this statement. In some settings (e.g., corporate campuses), weexpect to see steady progress toward multiservice ideals. However, we also believethat the “carrier-grade voice” sphere (that is, the realm now inhabited by telcos) will


continue to exist. In telco backbone networks, it will be years before packet voicereaches a comparable scale to that of circuit-switched voice.

So the first point is that telco backbone networks will evolve slowly towardpacket voice. Our second point is that, in the early phases of this evolution, back-bone network elements will be dedicated to packet voice. In our mind, the funda-mental reason for this is that packet voice will be compared with circuit-switchedvoice; if packet voice is implemented in a way that is markedly inferior to its oldersibling, many people will stick with the latter. We believe it is only a slight oversim-plication to say that:

• Network elements and management systems that are able to deliver car-rier-grade voice will be very expensive.

• For a long time, it will not make sense to “throw this kind of money” at tradi-tional data networking applications.

There is another key reason that the promise of full-blown multiservice net-working is a long way off: security. That is, a true multiservice network is a very dif-ferent security environment than a traditional telco network.

7.8 Layer 4 Protocols: Suitability to Task

What sits on top of IP? We have already looked at TCP. But TCP takes a back seat inthe realm of IP telephony. To lay the foundation for our discussion of the bearer andcontrol planes in subsequent chapters, we now introduce layer 4 protocols that playan important role there.

7.8.1 UDP

If TCP is available, why would anyone want to use UDP? As remarkable as its suc-cess has been, TCP is not suited to every task. TCP retransmits packets when it con-cludes that they did not reach their destinations. For a real-time application, there isno point in retransmitting a stale packet; it is just a waste of transmission band-width. Similarly, TCP’s flow control and reordering mechanisms are also of limitedusefulness for real-time applications, which want to deliver packets periodically todestination hosts (rather than achieve bulk data transfers as quickly as possible).

As shown in Figure 7.4 the UDP header is very simple. As is the case with TCP,applications may be multiplexed atop a single UDP protocol entity (think, for exam-ple, of voice and video streams emanating from the same host). The Source and Des-tination Port numbers in the UDP header are used to distinguish the applications.The Length header field is self-explanatory and the Checksum header field is used todetect corrupted packets. There is nothing more to UDP—the defining RFC [66] isonly three pages long. Recall that QoS is managed at layer 3 and below for real-timeservices; UDP is suitable for these services because it adds as little overhead as possi-ble. Note that UDP also has some uses in traditional data networking; for example,it is often used for domain name system queries. In such cases the DNS client (ratherthan TCP) is responsible for repeating queries that go unanswered.

7.8 Layer 4 Protocols: Suitability to Task 81

7.8.2 Carrying SS7 Traffic over an IP Network: SCTP

We have seen that SS7 is a packet technology; as IP networks proliferate, it is quitenatural to think of carrying SS7 messages over IP. This is especially true given thatSS7 traffic volumes are still growing steadily—it is difficult to accommodate thisgrowth with traditional 56 kbit/s SS7 links. However, SS7 places unique require-ments on the underlying IP network. Neither TCP nor UDP is ideal for satisfyingthese requirements, so the IETF’s Signaling Transport (sigtran) working group cameup with SCTP [67] to fill the void. General information about SCTP can be found in[68, 69].

All SCTP packets begin with a common header; see Figure 7.5. The Source andDestination Ports play the same role as for TCP and UDP, as does the Checksumfield. Note, however, that the latter is twice as long as that of TCP and UDP. Moreo-ver, the checksum computation specified in [67] was later replaced by a more robustscheme; see [70]. The receiver of an SCTP packet uses the Verification Tag to certifythe identity of the sender.

Like TCP (but unlike UDP), SCTP is a reliable transport protocol. It can providesequenced delivery of messages within multiple streams and can bundle multiplemessages into a single packet. One of the most important features of SCTP is its sup-port of multihoming: SS7 networks are traditionally held to a very high standard ofreliability, and thus fault tolerance is a must. We will talk about multihoming inChapter 8. Also included in the design of SCTP are congestion avoidance behavior(similar to that of TCP) and measures to resist flooding and “spoofing” attacks. Allof this is achieved by means of SCTP associations. (Readers familiar with TCP sock-ets can think of an SCTP association as a sort of generalized TCP socket.)

The SCTP packet header is followed by a variable number of chunks, each withits own header. (Note the similarity of this concept to the design of IPv6, in which asimple header can be followed by a variety of extension headers, depending on thesituation.) There are several types of chunks, most of which are used to set up, teardown, maintain, and control associations between SCTP entities. Each chunk type


Checksum (16 bits)


Length (16 bits)


Figure 7.4 UDP header.


Checksum (32 bits)

Verification tag (32 bits)


Figure 7.5 SCTP common header.

has its own header format. The SCTP data chunk format is used to encapsulate theuser’s data for transport through the underlying IP network; this is the only formatthat we will examine directly.

The data chunk header format appears in Figure 7.6. The value 0 in the Typefield indicates that this is a data chunk. If the U (unordered) bit is set, then the receiv-ing SCTP entity must pass the packet to the upper layer without any attempt at reor-dering. (Thus, unlike TCP, the SCTP user can selectively choose not to restore theoriginal transmission order of incoming packets.) The B and E bits, if set, indicatethe beginning and ending fragments of a user message, respectively. (In the case ofan unfragmented message, both bits are set.) The Length field is self-explanatory.The remaining header fields are interpreted as follows:

• Transmission sequence number (TSN): SCTP assigns a TSN to each piece ofdata that it transmits (whether it be an entire message or a fragment thereof),independently of the stream sequence number. All TSNs are acknowledged bythe receiving end; if the transmitter does not receive an ACK, it eventuallyretransmits. For a fragment of a segmented user message, TSNs must be instrict sequence.

• Stream identifier: See description of payload.• Stream sequence number: This must be the same for each fragment of a seg-

mented user message.• Payload protocol: This represents the higher-layer application; it is not used

by SCTP itself.

The payload that follows the data chunk header is (all or part of) messagenumber n within stream S, where n is the stream sequence number in the header andS is the stream ID. By keeping track of multiple streams, SCTP implements anotherlayer of multiplexing (above the source and destination port numbers, that is). If onestream is blocked because a packet arrived out of order (i.e., an earlier packet in thestream has not yet arrived) and its U bit is not set (so it is an ordered stream), packetsfrom other streams can still be proferred to the higher-layer protocol.

7.8.3 Comparing and Contrasting TCP with UDP and SCTP

UDP, TCP, and SCTP all multiplex using port numbers; they all employ checksumsto recognize corrupted packets. This is all UDP does. TCP and SCTP offer reliable

7.8 Layer 4 Protocols: Suitability to Task 83

Payload protocol ID (32 bits)

Stream sequence number (16 bits)Stream ID (16 bits)

Transmission sequence number (32 bits)

Length (16 bits)EBUReservedType = 0 (8 bits)

Figure 7.6 SCTP data chunk header.

data transport by retransmitting lost packets, and they implement similar conges-tion avoidance schemes.

TCP maintains strict ordering (i.e., it always delivers packets to the higher layerin the order in which they were transmitted). TCP is aggressive in the followingsense: it increases its flow rate until it detects packet losses. SCTP’s flow controlscheme is a superset of TCP’s flow control scheme. SCTP can be configured so thatit does not seek to saturate the available transmission capacity a la TCP. More-over, SCTP multiplexes streams; strict ordering can be enabled or disabled on astream-by-stream basis.

7.9 Mobile IP

With the advent of third generation wireless networks and wireless LAN, IP hostscan no longer be expected to stay in the same place. Mobile IP [71] provides a meansfor mobile nodes to dynamically change their points of attachments to IP networks.Mobile nodes have two kinds of IP addresses: home and care-of addresses. Care-ofaddresses are registered with so-called home agents. Packets sent to a host’s homeaddress are tunneled (by the host’s home agent) to the appropriate care-of address.

7.10 Summary

For the first several sections of this chapter, we talked about IP networking in gen-eral. Starting with the section on IP QoS and statistical multiplexing, we discussedchanges that are coming about in IP networking to accommodate full duplex voiceand other real-time services. We highlight the following points from that discussion:

1. QoS and statistical multiplexing are conflicting goals. Traditional IPnetworking seeks to maximize the latter without giving much thought tothe former. QoS will “cost” something in terms of reduced statisticalmultiplexing.

2. Reliable transport of packets is traditionally the responsibility of layer 4(embodied in TCP). Moreover, TCP’s flow control mechanism attempts toadjust to the available transmission capacity. But TCP’s capabilities arelimited by the fact that it cannot see or directly harness the resources thatreside below the IP layer. As a result, TCP is not the right tool to provideadequate QoS for real-time services.

3. Therefore, TCP is not a central protocol in packet telephony. Instead, UDP(for bearer traffic) and SCTP (for signaling traffic) are the crucial layer 4protocols.

4. IP QoS initiatives such as DiffServ and MPLS attempt to harness underlyingresources (that is, transmission bandwidth, buffering, and switchingresources) that reside below layer 3.

It is important to note that items 1 and 4 are expensive. It is tempting to measurethe costs associated with “mainline” data networking and compare them with the


costs associated with legacy telephone networks. Such a comparison is ultimatelymisleading, however, for the simple reason that packet telephony will cost morethan traditional data networking.

Telephone equipment manufacturing has traditionally been a specialized,high-margin business. One way or another, that will probably change. The point weare trying to make, however, is that early generations of carrier grade packet teleph-ony “gear” will also be specialized and command premium prices.

7.10.1 Further Reading

Our coverage of IPv6 has been minimal. The list of IETF standards that had to beadapted to work with IPv6 is far too long to present here. Throughout the remain-der of this book, the reader should assume that “IP” means “IPv4” unless explicitlynoted otherwise. Regarding our discussion of (and bibliographic references to) pro-tocols related to IP, the reader should not assume compatibility with IPv6.

There is more discussion of IPv6 in Section 15.6.2. For in-depth coverage, oneneeds to follow the pointers given there and/or consult an expository referencesuch as Hagen’s book [72]. We also found several informative tutorials via sim-ple-minded Web searches.

We mentioned ICMP [9, 12] in the context of path MTU discovery. Althoughwe do not cover them in this book, ICMP is used for numerous other purposes. DNSis another subject area that “got cheated.” Many subsequent RFCs have updatedRFCs 1034 [22] and 1035 [23] (the two documents we referenced in Section 7.3.3).Perhaps the easiest way to obtain the details is to go to www.rfc-editor.org, followthe “RFC search” link, and search on “dns.” Some of the RFCs listed there came outof the DNS Extensions (dnsext) working group, which is still active at the time ofthis writing.

For comprehensive coverage of topics in network optimization, we recommendthe fine book by Ahuja, Magnanti, and Orlin [73]. This is not a telecommunicationsbook, however; the book by Bertsekas [74] is more directly pertinent to telecommu-nications and also adds a control theory flavor.

We have noted that simple-minded distance vector protocols suffer from severescalability limitations; various schemes for enhancing scalability, including thatspecified in [75], are widely deployed. Halabi and McPherson’s book [76] discussesBGP in considerable detail; the authors also give background on CIDR and othertopics. John Moy, the main author of the OSPF specification, has written a book onthe subject [77].

In their data networking book, Bertsekas and Gallager [78] present a useful dis-cussion of traffic modeling.

References

[1] Postel, J., RFC 791, Internet Protocol, IETF, September 1981, Part of IETF STD 5.[2] Deering, S., and R. Hinden, RFC 1883, Internet Protocol, Version 6 (IPv6) Specification,

IETF, December 1995.[3] Deering, S., and R. Hinden, RFC 2460, Internet Protocol, Version 6 (IPv6) Specification,

IETF, December 1998.

7.10 Summary 85

[4] Postel, J., Internetwork Protocol Specification—Version 4, IEN-41, June 1978.[5] Postel, J., DOD Standard Internet Protocol, IEN-41, December 1979.[6] Topolcic, C., RFC1190, Experimental Internet Stream Protocol: Verizon 2, IETF, October

1990.[7] Delgrossi, L., and E. L. Berger, RFC 1819, Internet Stream Protocol Version 2 (ST2) Proto-

col Specification—Version ST2+, IETF, August 1995.[8] Mogul, J., and S. Deering, RFC 1191, Path MTU Discovery, IETF, November 1990.[9] Postel, J., RFC 792, Internet Control Message Protocol, IETF, September 1981, Part of

IEFT STD 5.[10] Rajahalme, J., et al., RFC 3697, IPv6 Flow Label Specification, IETF, March 2004.[11] McCann, J., S. Deering, and J. Mogul, RFC 1981, Path MTU Discovery for IP Version 6,

IETF, August 1996.[12] Conta, A., and S. Deering, RFC 2466, Internet Control Message Protocol (ICMPv6) for the

Internet Protocol Version 6 (IPv6) Specification, IETF, December 1998.[13] Rekhter, Y., and T. Li, RFC 1518, An Architecture for IP Address Allocation with CIDR,

IETF, September 1993.[14] Fuller, V., et al., RFC 1519, Classless Interdomain Routing (CIDR): An Address Assign-

ment and Aggregation Strategy, IETF, September, 1993.[15] Rekhter, Y., et al., RFC 1918, Address Allocation for Private Internets, IETF, February,

1996.[16] Srisuresh, P., and K. Egevang, RFC 3022, Traditional IP Network Address Translator (Tra-

ditional NAT), IETF, January 2001.[17] Hinden, R., and S. Deering, RFC 3513, IP Version 6 Addressing Architecture, IETF, April

2003.[18] Hinden, R., and S. Deering, and E. Nordmark, RFC 3587, IPv6 Global Unicast Address

Format, IETF, August 2003.[19] S. Thomson, and T. Narten, RFC 2462, IPv6 Stateless Address Autoconfiguration, IETF,

December 1998.[20] ATM Forum Technical Committee, af-imli-0065.000, Integrated Local Management Inter-

face (ILMI) Specification Version 4.0, ATM Forum, September 1996.[21] Berners-Lee, T., R. Fielding, and L. Masinter, RFC 2396, Uniform Resource Identifiers

(URI): Generic Syntax, IETF, August 1998.[22] Mockapetris, P. V., RFC 1034, Domain Names—Concepts and Facilities, IETF, November

1987, Part of IEFT STD 13.[23] Mockapetris, P. V., RFC 1035, Domain Names—Implementation and Specification, IETF,

November 1987, Part of IETF STD 13.[24] Dierks, T., and C. Allen, RFC 2246, The TLS Protocol Version 1.0 IETF, January 1999.[25] Kent, S., and R. Atkinson, RFC 2401, Security Architecture for the Internet Protocol, IETF,

November 1998.[26] Thayer, R., N. Doraswamy, and R. Glenn, RFC 2411, IP Security Document Roadmap,

IEFT, November 1998.[27] Kent, S., and R. Atkinson, RFC 2402, IP Authentication Header, IEFT, November 1998.[28] Kent, S., and R. Atkinson, RFC 2406, IP Encapsulating Security Payload, IEFT, November

1998.[29] Maughan, D., et al., RFC 2408, Internet Security Assocation and Key Management Proto-

col (ISAKMP), IETF, November 1998.[30] Harkins, D., and D. Carrel, RFC 2409, The Internet Key Exchange (IKE), IETF, November

1998.[31] Rigney, C., RFC 2865, Remote Authentication Dial-In User Service (RADIUS), IEFT, June

2000.[32] Calhoun, P., et al., RFC 3588, Diameter Base Protocol, IETF, September 2003.


[33] Dijkstra, E., “A Note on Two Problems in Connections With Graphs,” Numeriche Mathe-matics, Vol. 1, 1959, pp. 269–271.

[34] Moy, J., RFC 2178, OSPF Version 2, IEFT, April 1998.[35] Hedrick, C., RFC 1058, Routing Information Protocol, IEFT, Juen 1998.[36] Malkin, G., RFC 1388, RIP Version 2—Carrying Additional Information, IEFT, January

1993.[37] Malkin, G., RFC 1387, RIP Version 2 Protocol Analysis, IETF, January 1993.[38] Malkin, G., and F. Baker, RFC 1389, RIP Version 2 MIB Extension, IETF, January 1993.[39] Rekhter, Y., and T. Li, RFC 1771, A Border Gateway Protocol 4 (BGP), IETF, March

1995.[40] Li, T., and Y. Rekhter, RFC 2474, Definition of the Differentiated Services Field in the IPv4

and IPv6 Headers, IETF, October 1998.[41] Grossman, D., RFC 3260, New Terminology and Clarifications for DiffServ, IETF, April

2002.[42] Ramakrishnan, K., S. Floyd, and D. Black, RFC 3268, The Addition of Explicit Congestion

Notification (ECN) to IP, IETF, September 2001.[43] Blake, S., et al., RFC 2475, An Architecture for Differentiated Services, IETF, December

1998.[44] Black, D., et al., RFC 3140, Per-Hop Behavior Identification Codes, IETF June 2001.[45] Davie, B., et al., RFC 3246, An Expedited Forwarding PHB, IETF, March 2002.[46] Charny, A., et al., RFc 3247, Supplemental Information for the New Definition of the EF

PHB, IETF, March 2002.[47] Armitage, G., et al., RFC 3248, A Delay Bound Alternative Revision of RFC 2598, IETF,

March 2002.[48] Heinane, J., et al., RFC 2597, Assured Forwarding PHB Group, IETF, June 1999.[49] Braden, R., D. Clark, and S. Shenker, RFC 1633, Integrated Services in the Internet Archi-

tecture: An Overview, IETF, June 1994.[50] Braden, R., et al., RFC 2205, Resource ReSerVation Protocol (RSVP)—Version 1 Function

Specification, IETF, September 1997.[51] Wroclawski, J., RFC 2210, The Use of RSVP With IETF Integrated Services, IETF, Septem-

ber 1997.[52] Rosen, E., A. Viswanathan, and R. Callon, RFC 3031, Multiprotocol Label Switching

Architecture, IETF, January 2001.[53] Andersson, L., et al., RFC 3036, LDP Specification, IETF, January 2001.[54] Thomas, B., and E. Gray, RFC 3037, LDP Applicability, IETF, January 2001.[55] Rosen, E., et al., RFC 3032, MPLS Label Stack Encoding, IETF, January 2001.[56] Suzuki, M., RFC 3033, The Assignment of the Information Field and the Protocol Identi-

fier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the InternetProtocol, IEFT January 2001.

[57] Conta, A., P. Doolan, and A. Malis, RFC 3034, Use of Label Switching on Frame RelayNetworks Specification, IETF, January 2001.

[58] Davie, B., et al., RFC 3035, MPLS Using LDP and ATM VC Switching, IETF, January2001.

[59] Nagami, K., et al., RFC 3038, VCID Notification Over ATM Link for LDP, IETF, January2001.

[60] Awduch, D., et al., RFC 3209, RSVP–TE: Extensions to RSVP for LSP Tunnels, IETF,December 2001.

[61] Awduche, D., A. Hannan, and X. Xiao, RFC 3210, Applicability Statement for Extensionsto RSVP for LSP Tunnels, IETF, December 2001.

[62] Jamoussi, B., et al, RFC 3212, Constraint-Based LSP Setup Using LDP, IETF, January2002.

7.10 Summary 87

[63] Ash, J., et al., RFC 3213, Applicability Statement for CR–LDP, IEFT, January 2002.[64] Ash, J., et al., RFC 3214, LSP Modification Using CR–LDP, IETF, January 2002.[65] Faucher, F. L., et al., RFC 3270, Multiprotocol Label Switching (MPLS) Support of Differ-

entiated Services, IETF, May 2002.[66] Postel, J., RFC 768, User Datagram Protocol, IETF, August 1980.[67] Stewart, R., et al., RFC 2960, Stream Control Transmission Protocol, IETF, October 2000.[68] Coene, L., RFC 3257, Stream Control Transmission Protocol Applicability Statement,

IETF, April 2002.[69] Ong, L., and J. Yoakum, RFC 3286, An Introduction to the Stream Control Transmission

Protocol (SCTP), IETF, May 2002.[70] Stone, J., R. Stewart, and D. Otis, RFC 3309, Stream Control Transmission Protocol

(SCTP) Checksum Change, IETF, September 2002.[71] Perkins, C., RFC 3344, IP Mobility Support for IPv4, IETF, August 2002.[72] Hagen, S., IPv6 Essentials, Sebastopol, CA: O’Reilly, July 2002.[73] Ahuja, R. K., T. L. Magnanti, and J. B. Orlin, Network Flows: Theory, Algorithms, and

Applications, Engelwood Cliffs, NJ: Prentice Hall, 1993.[74] Bertsekas, D. P., Network Optimization: Continuous and Discrete Models (Optimization,

Computation, and Control), Belmont, MA: Athena Scientific, 1998.[75] Bates, T., R. Chandra, and E. Chen, RFC 2796, BGP Route Reflections—An Alternative to

Full Mesh IBGP, IETF, April 2000.[76] Halbi, B., and D. McPherson, Internet Routing Architectures, 2nd ed., Indianapolis, IN:

New Riders Publishing (Cisco Press), August 2000.[77] Moy, J. T., OSPF: Anatomy of an Internet Routing Protocol, Reading, MA: Addison-

Wesley, 1998.[78] Bertsekas, D. P., and R. Gallager, Data Networks, 2nd ed., Engelwood Cliffs, NJ: Prentice

Hall, 1991.


C H A P T E R 8

A Closer Look at SS7

In some ways, SS7 is inelegant—for example, its routing scheme has been surpassedby today’s IP routing protocols. This begs the following question: Why is the “fo-otprint” of this technology still expanding? The answer is that SS7 is robust in somevery important ways:

• SS7 networks are built to an extremely high degree of reliability. There is ahigh degree of redundancy built into the SS7 “architecture,” and the SS7 pro-tocol stack fully exploits this redundancy.

• The SS7 protocol stack monitors the health of SS7 links. There are well-estab-lished tools and procedures for troubleshooting SS7 networks; these are basedin part on SS7’s builtin capabilities for health assessment.

• SS7 supports much more than just basic call-control functionality. TCAP isespecially important, because it allows SS7 entities to generate database que-ries (e.g., to look up subscriber data).

The number and cumulative volume of the ITU-T SS7 standards documents istruly enormous. The ITU-T document [1] provides an overview and outlines theother documents in the series. The U.S. versions of the SS7 standards are publishedby ANSI. Details differ between the ITU-T and ANSI versions, but the concepts arethe same.

The standards documents make for difficult reading. They are probably not thebest starting point for readers who are new to the subject. We found good Web tuto-rials on SS7 at http://www.pt.com and http://www.iec.org/online, simply by search-ing against the text “SS7 tutorial.” If these pointers become stale, the reader maystill be able to find resources by repeating the same search. For a detailed treatmentof SS7, one can consult books by Manterfield [2], van Bosse [3] and Russell [4].

8.1 SS7 Architecture and Link Types

In this section, we describe how redundancy is builtin to the SS7 architecture. Thereare three types of SS7 network elements:

• Service control points (SCPs) house service logic (one can think of this as the“flowchart” defining the workings of a given service) and/or supporting data.A subscriber database (such as a home location register in the case of a wire-less network) is a good example.

89

• Voice switches are the “clients” of the SCPs. That is, they look to the SCPs fordata or instructions necessary to provide a given service. Note that voiceswitches are called service switching points in SS7, although we will have littleuse for this terminology.

• Signaling transfer points are packet switches that act as intermediariesbetween pairs of voice switches or voice switches and SCPs.

SS7 links come in different types, which are distinguished by their placementand roles in the SS7 architecture. Voice switches and SCPs connect to STPs via A, or“access,” links. Since one SCP typically serves many switches, SCPs are oftendeployed in redundant pairs. This is shown in Figure 8.1.

Multiple types of links are used to interconnect STPs: B (“bridge”), C (“cross”),and D (“diagonal”). STPs are deployed in redundant pairs called mated pairs; thetwo STPs in a mated pair perform identical functions. Unlike SCPs, the members of amated STP pair are interconnected; such a connection is called a C link. In Figure8.1, note that the voice switch is “dual-homed”: it is connected to STP1 and STP2,which form a mated pair. If connectivity to one of the two STPs fails, the switch isnot isolated from the rest of the SS7 network. The C link connecting STP1 and STP2is used only in the case of failure. Here is an example: suppose that our voice switchhas launched a database query toward the SCP, whose response comes to STP2. Sup-pose also that connectivity between STP2 and the voice switch has failed, but neitherof these network elements is down. (This could be because a line card at one end-point of the link has failed, or because of a failure on some intervening transport net-work element.) Then STP2 will forward the response to STP1 in the hope that STP1still has connectivity to the voice switch. Note the label on the link between STP3and STP4 (which also form a mated pair).

B and D links are used to interconnect mated pairs of STPs. For our purposes,there is no distinction between the two; we will call them B/D links. As illustrated inthe figure, there are four ways to connect a member of the STP1-STP2 mated pair toa member of the STP3-STP4 pair. Thus B/D links come in sets of four. Unlike Clinks, B/D links are used during normal operation—traffic between the STP1-STP2and STP3-STP4 mated pairs will be shared among the four links so that the load isbalanced.

There are two additional SS7 link types (these are not shown in Figure 8.1). F(“fully associated” or “facility”) links connect voice switches directly to SCPs. In the

90 A Closer Look at SS7

SCP 2

SCP 1

STP 4

STP 3

B/DC C

AA

A

A

A

ASTP 2

STP 1

Voice switch

Figure 8.1 SS7 link types.

United States, STPs are almost universally deployed and F links are uncommon. AnE (“extended”) link connects a voice switch to an alternate STP (that is, an STP in analternate mated pair). E links are also uncommon.

Further Description of Service Control Points

To motivate the subsystem number (SSN) concept presented in Section 8.2, we needto offer a truer representation of an SCP than what appears in Figure 8.1. There, dueto space limitations, each SCP is shown as a single database. However, it oftenmakes sense to house multiple services behind the same SS7 interface. Among otherthings, it may be advantageous to multiplex the traffic pertaining to those serviceson common linkset(s). Figure 8.2 positions the SCP as an SS7 “front end” for twodatabase applications (the latter are suggested by the cylinders at the far right). Aswe have drawn the picture, the databases are external to the SCP itself (this was anarbitrary choice); the connecting links are not SS7 links (they are dotted to contrastwith the A links at the far left). Note that the SS7 network does not know or carewhether the databases are part of the SCP. Note also that we do not intend to sug-gest in Figure 8.2 that the upper SS7 interface is associated with Service #1 or thatthe lower SS7 interface is associated with Service #2. The two SS7 interfaces arepresent for redundancy and load sharing; each A link will carry traffic for bothservices.

8.2 SS7 Routing and Addressing

We need some routing and addressing terminology to facilitate our forthcomingdiscussion of SS7 protocol layers. The following four terms will suffice for ourpurposes:

• Linkset. In Figure 8.1, we suppressed one important detail: each of the linescan represent a linkset rather than a single link. For our purposes, the definingcharacteristic of a linkset is this: all members of a linkset terminate at the samepair of nodes and serve the same function. Legacy SS7 links have limited trans-mission capacity (typically 56 kbit/s); this is the reason that the linkset conceptwas devised and implemented.

8.2 SS7 Routing and Addressing 91

SCP

Service#2

SS7interfaces

Service#1

Redundant A linksto SS7 network

Figure 8.2 Representation of a service control point.

• Routeset. Linksets only connect adjacent SS7 nodes. Unlike links, routes cancontain intermediate nodes. More formally, a route is a collection of linksetsthat, when “concatenated,” form a path between two SS7 nodes not directlyconnected. As an example, consider the following collection from Figure 8.1:the linkset connecting the voice switch to STP1, the linkset connecting STP1 toSTP3, and the linkset connecting STP3 to SCP1. A routeset is a collection ofroutes that share the same originating and terminating nodes. The followingcollection is an example routeset:• The route already described;• The route voice switch-STP1-STP4-SCP1;• The route voice switch-STP2-STP3-SCP1;• The route voice switch-STP2-STP4-SCP1.

Routesets typically incorporate route diversity (i.e., multiple paths between theiroriginating and terminating nodes, as illustrated by the example). This exploits theredundancy present in SS7 networks to achieve fault tolerance.

• Point code. SS7 node addresses are called point codes. The details differ fromcountry to country. The United States and China use 24-bit point codes, butthe formats are different. Europe uses 14-bit point codes.

• Subsystem number. Recall that a single SCP may provide more than one serv-ice. SS7 distinguishes between services by assigning subsystem numbers tothem. One can think of a service as a piece of application software running onan SCP; then the application is known to the SS7 protocol stack on that SCP byits subsystem number. Approaching the concept in this way, we see that sub-system numbers in SS7 networks play an analogous role to that of port num-bers in IP networks. Recall from our discussion of IP networking that sourceand destination port numbers appear in the layer 4 header (i.e., the TCP, UDP,or SCTP header).

8.3 Review of the SS7 Protocol Stack

Most of the protocols mentioned in this section were also discussed, albeit briefly, inChapter 6. Using Figure 8.3, we remind the reader of these protocols and show sche-matically how they fit together.

By drawing an imaginary vertical line through Figure 8.3, the reader can glimpsethe stack for a given SS7 protocol. In legacy SS7 deployments, the three layers ofMTP are always present.

Let us look at the example of ISUP. Depending on where we position the verticalline, it may or may not pass through the box labeled “SCCP.” This reflects the factthat ISUP can run over SCCP, or it can run directly over MTP3. ISUP over SCCP isextremely rare, so the pertinent portion of the ISUP box in the diagram is purposelyvery slim. ISUP is the protocol for basic call-control signaling in most networkstoday; this protocol is fairly straightforward and has changed little over the years.


We do not describe ISUP any further in this chapter; instead, we refer the reader tothe overview that appears in Section 6.5.6.

Numerous protocols run over TCAP, which in turn requires SCCP. The past 15or 20 years have seen continual change in this area—new protocols have emergedand existing protocols have evolved enhanced capabilities. MAP and ANSI-41 han-dle mobility management for GSM and CDMA/TDMA wireless networks respec-tively. Intelligent network application part (INAP) is used to support a variety ofintelligent network services, such as prepaid long distance. There are many otherapplication parts. Although we do not discuss those protocols here, their existenceis proof of SS7’s great flexibility.

Packet Formats

We will present less detail about packet headers in this chapter than in Chapter 7.There are several reasons for this. Field lengths and formats differ from place toplace (as we have seen with point codes). There are some also regional differences inpacket formats. Finally, there are numerous options at some protocol layers, andthe interpretation of protocol fields depends on the option settings. The interestedreader will find that SS7 is well documented in the print medium and, to a lesserextent, on the World Wide Web.

SS7 Network Management Traffic

We have seen that redundancy is a built-in feature of the SS7 infrastructure. This isimportant for SS7’s reliability and overall robustness, but is not by itself sufficient.SS7 has complex network management features essential to its robustness.Although we will not discuss them further, network management messages areexchanged at various levels in the SS7 protocol stack; network management trafficis an important part of the mix in today’s SS7 networks.

8.4 Message Transfer Part

Recall that MTP1 is synonymous with the physical layer. Details of the physicallayer are beyond the scope of this book.

8.4 Message Transfer Part 93

SCCPISUP

TCAP

INAPIS41MAP

MTP level 1

MTP level 2

MTP level 3

Figure 8.3 ”Traditional” SS7 stack.

8.4.1 MTP2

MTP2 runs directly over the physical layer. MTP2 protocol entities at either end of alink continually assess the health of that link, reporting this information to theMTP3 layer. MTP2 is responsible for retransmission of packets that are lost or gar-bled. In support of these responsibilities, the MTP2 frame includes sequencing infor-mation and a cyclic redundancy check field used to detect corrupted frames.

MTP2 frames, called signal units in SS7 jargon, come in three varieties, whichwe now describe. MTP2 entities that share an SS7 link talk to each other constantly,transmitting fill in signal units (FISUs) if they do not have anything in particularto say. A FISU can also be used by an MTP2 entity that wants to acknowledgereceipt of a signal unit from the far end but does not have any additional content toconvey. Link status signal units are used for the health assessment functions ofMTP2. All payloads received from the MTP3 layer are encapsulated in messagesignal units.

8.4.2 MTP3

MTP3 receives information from MTP2 about link health and is responsible for act-ing on this information. MTP3 incorporates congestion avoidance procedures.Should a link exhibit severe problems, MTP3 can mark that link as “out of service”and initiate a link reset (that is, it can restart the state machines at either end of thelink and allow them to “sync up”). Once an incoming message signal unit (MSU) hasbeen processed by MTP2, it passes the service information octet (SIO) and signalinginformation field (SIF) to MTP3. The SIO tells MTP3 how the SIF should be inter-preted: it identifies the higher-layer protocol entity for this message (e.g., ISUP orSCCP) and includes priority information.

MTP3 also has routing capabilities; it is responsible for selecting the outgoinglink for each outgoing packet. Although its format is variable, the SIF always beginswith a routing label. The routing label contains the destination point code (DPC),the originating point code (OPC), and the signaling link selection (SLS); see Figure8.4. Note that this drawing is not to scale in the sense that the SIO, DPC, OPC, andSLS fields do not have the same length. In some (but not all) variants, the routinglabel contains “filler” bits in addition to the fields shown.

Whenever a message is ready to be sent to another node, MTP3 makes the out-going link selection using the DPC and SLS as follows. The DPC is used as a key for arouting table lookup; this lookup determines the outgoing linkset. The SLS is thenused to determine which link in the linkset will be used. MTP3 balances the loadamong all links in a linkset. One might imagine that MTP3 would simply cycle theSLS through all possible values, thus distributing packets among the links in around-robin fashion. This gives the general idea, but is a bit oversimplified: packetsvary in length, and some messages must be segmented across multiple packetsbecause of their size. In the case of a multipacket message, all of the fragments mustbe sent on the same link to make certain they do not arrive out of order.

The routing capabilities of MTP3 are limited; in many routing scenarios, MTP3requires the assistance of the SCCP layer.


8.5 SCCP

SCCP provides the routing capabilities that MTP3 lacks. Network layer functional-ity is shared by MTP3 and SCCP.

8.5.1 General Description and Communication with MTP3

SCCP provides four classes of service. Two are connection-oriented, in which a ses-sion must be initiated before data transfer takes place. The two connection-orientedservices are distinguished by whether in-sequence data delivery is assured. The othertwo services are connectionless and are again distinguished by whether in-sequencedelivery is assured. The connectionless services are far more common than theirconnection-oriented counterparts, although SCCP’s name might lead one to guessthe opposite.

When SCCP assures in-sequence delivery, it does so in a rather crude way: ittells MTP3 not to change the SLS. This assurance is necessary whenever a message islong enough to require fragmentation at the MTP3 layer. If fragments arrive out oforder, the receiving end will not be able to reassemble them correctly.

We saw in Section 8.2 that SSNs are used to distinguish applications running onan SCP. For each packet that it receives from MTP3, SCCP uses the SSN field(located in the SCCP header) to determine which higher-layer application willreceive the payload. This handoff occurs at the end node (e.g., the SCP that is theultimate destination for a service request) and is conceptually simple. One couldargue that this is a layer 4 functionality (see the comparison with TCP port numbersin Section 8.2), but the dividing line between the layers is not so clear here, as we willexplain.

Using an SSN to select a higher-layer application at a destination SS7 node is theeasy part. Reaching this ultimate destination is often more complex, and SCCPplays a crucial role here. The relevant SCCP functionality is called global title trans-lation (GTT).

8.5 SCCP 95

Serviceinformationfield (SIF)

...length and interpretationdepends on contents of SIO...

Signaling link selection (SLS)

Originating point code (OPC)

Destination point code (DPC)

Service information octet (SIO)

Routinglabel

Figure 8.4 MTP3 fields.

8.5.2 Getting There Is Half the Fun: Global Title Translation

In many cases, the sender of an SS7 message does not know the point code of thatmessage’s final destination. Toll-free numbers, for instance, are not routable. Whena toll-free number is dialed, the originating switch must therefore obtain routinginformation from the toll free database (which is an SCCP subsystem) before the callsetup can proceed. Moreover, the originating switch usually does not know the loca-tion (that is, Point Code and SSN) of the toll free database. As long as the switch canpass the request to another SS7 node (using MTP3 routing) whose SCCP layerknows where to go next, however, the query can make progress toward the toll-freedatabase.

How does the query make progess toward the database? The SCCP layer at thereceiving node fetches a new DPC from a routing table, using the dialed digits as an“index” into that routing table. The SCCP entity then repopulates the DPC for thenext phase of the query’s journey and forwards again over MTP3. This process iscalled GTT. In Figure 8.5, the GTT procedure is performed by the node in the centerof the diagram. The nodes flanking the GTT node route the service request at theMTP3 layer only; usually these would be STPs. (GTT nodes are not always separate;some STPs implement GTT in addition to their basic functionality.) It is worthwhileto note the similarity between Figure 8.5 and Figure 6.2.

GTT may be invoked multiple times along an SS7 message’s end-to-end path.The overall process looks like this: the dialing customer’s serving switch must knowthe point code of the device (an STP, say) that handles toll-free translations for it.The serving switch inserts this point code in the DPC field of the MTP3 header andforwards it, over MTP3, to that device. The message is formatted so as to indicatethat the switch is requesting GTT.

The receiving STP invokes GTT to fill in a new DPC and forwards again overMTP3. Suppose this STP does not know the final destination of the query. Then itindicates to its “SCCP next hop” that it, too, is requesting GTT. Ultimately, thequery reaches the SCP that hosts the toll-free database application; recall that theSSN identifies the correct application.


MAP MAP

DPC2 at MTP3 layerGTT

DPC1 at MTP3 layer

IP

PhysicalPhysicalPhysicalPhysicalPhysical

MTP2 MTP2 MTP2MTP2 MTP2

MTP3MTP3MTP3MTP3

SCCPSCCP SCCP

TCAPTCAP

Subsystems

Figure 8.5 SS7 routing example.

This is starting to sound complicated, and therefore begs the followingquestion: “Why bother with multiple GTT invocations along the path of a singlemessage?” One reason is that this is almost certainly more cost-effective than popu-lating the DPC and SSN of the toll-free database into the routing table of every STP.One would have a management nightmare if this DPC needed to be changed forsome reason. Moreover, when one incorporates many services into the picture,routing tables would become large and unwieldy.

Clarifying the Bigger Picture

We can enumerate the following steps in processing a toll-free call (note that thisdescription pertains to the U.S. implementation):

1. The calling party’s serving switch looks at the dialed digits and realizes thatthey constitute a special, nonroutable number. Thus it cannot initiate anISUP call flow right away.

2. The switch sends a query to the toll free database. (As a “plug” for thematerial in Section 8.6, we note that the query is encapsulated in a TCAPmessage.)

3. Usually, the toll-free database responds with a carrier code.1

4. Using ISUP signaling, the local switch sets up a trunk to the access switch forthe correct interexchange carrier (as indicated by the carrier code obtainedin step 3).

5. The interexchange carrier’s access switch queries the toll-free database andobtains a routable number.

6. The interexchange carrier’s switch completes the call using the newlyobtained routable number as the called party number.

It is important to understand that GTT takes place in the course of steps 2 and5, not in steps 4 or 6. Indeed, we have noted that ISUP runs directly over MTP3, sowe cannot directly take advantage of SCCP’s global title functionality within ISUPcall-control signaling. The philosophy is that we do not want to reserve any trunksuntil we know where we are going. (Recall that trunk is just a fancy name for a voicebearer channel connecting two switches; the term usually implies that the channeldoes not traverse any intermediate switches.) The process already outlined is trans-parent to the calling party, which never sees the routable number.

Toll-free service predates the widespread deployment of GTT. In earlier incar-nations, not every switch had the capability to perform database queries. In suchcases, the caller’s serving switch did reserve a trunk to a switch that could query thetoll-free database. After obtaining a routing number, the second switch would con-tinue the call-control signaling flow. Note that the trunk from the first switch to thesecond switch remained in the bearer path throughout the life of the call. We still seethe vestiges of this arrangement in the fact that the local exchange carrier trunks to

8.5 SCCP 97

1. If the dialed number is handled by the Local Exchange Carrier, then the query yields a routable numberdirectly. (Local Exchange Carriers in the US are allowed to offer intra-LATA toll-free service.)

the interexchange carrier’s access switch. Usually the distance between the two carri-ers’ switches is small, so the implied loss of efficiency is minimal.

More on GTT

We have only scratched the surface of SCCP and global title translation. We closethis section with a list of comments about additional aspects of the SCCP layer;details on these topics are beyond the scope of this book.

• In Section 8.4, we mentioned routing tables that are consulted by the MTP3layer. As noted in this section, routing tables are also present at the SCCP layer(to support GTT).

• The name of the DPC field in the MTP3 header is potentially misleading. Thisis indeed the final destination from MTP3’s point of view. However, as wehave seen, SCCP/GTT may insert a new value in the DPC field and hand themessage in question back to MTP3 for transport to another SS7 node.

• The address indicator field in the SCCP header indicates whether GTT isrequired. If so, this field also controls the global title options, which arenumerous. Many of these options go hand in hand with the type of addressinformation supplied with the GTT request; the address indicator tells SCCPwhat type of information to expect in the address header field.

• One of the global title options is to consider the SSN in the routing decision.Here is one use of this feature: suppose we have a service that relies on a data-base; for redundancy purposes there are two copies of the database residing atdifferent point codes. SCCP can mark the associated SSN as “subsystem pro-hibited” for one of the two point codes. This feature can be used to route que-ries to the backup copy of the database (e.g., when the primary copy is takendown for scheduled maintenance).

• Recall our statement that SSNs are similar to TCP (or UDP or SCTP) portnumbers in IP networks. However, port numbers are not normally taken intoaccount in IP routing; the separation between layers 3 and 4 is clearer therethan in SS7 networks.

• GTT happens at the SCCP layer. Recall our statement that SCCP uses the SSNfield to make sure it hands off to the correct higher-layer protocol entity. Infact, the appropriate subsystem is invoked when a database query or otherservice invocation request reaches its final destination (so our statement wasaccurate, as far as it went). However, when GTT takes place at intermediatenode(s), there is no handoff to a higher-layer protocol entity (because we havenot yet reached the SCP that provides the desired service).

8.6 TCAP

TCAP is all about invoking operations on remote nodes and reporting the results ofthose operations to the invoking entities. TCAP comes into play when an applica-tion on one node (a user in SS7-speak) asks a peer application on another node to


do something. Usually this “something” is a database lookup (think, for example,of local number portability or of verifying a calling-card personal identificationnumber), but there are other uses. For example, consider a ringback service in whicha caller who receives a busy signal can ask to be connected to the called party when-ever the latter becomes available. The caller’s serving switch asks to be informedwhen this event occurs. The request is encapsulated in a TCAP message to the calledparty’s serving switch. Each TCAP message contains a transaction portion and acomponent portion.

TCAP transactions. Each TCAP message contains an indication whether it is aunidirectional transfer of information (in which no reply is expected), an initiationof a dialog, a continuation of an ongoing dialog, a final response that ends a dialog,or an abort. This indication appears in the transaction portion of the TCAPmessage, along with originating and responding transaction ID fields. TCAP usesthese transaction IDs to match each transaction with the correct applications at theendpoints. To summarize, originating and responding applications talk to eachother within TCAP transactions. A TCAP transaction can be an ongoing dialog or a“one-shot deal.”

TCAP components. Many operations can be conducted under the aegis of a singleTCAP transaction. If two applications talk to one another frequently,many requested operations may be in process simultaneously, in various stages ofcompletion. Individual invocations and responses are called components; multiplecomponents can be bundled inside a single TCAP message provided that they allshare the same originating and responding applications. As a crude example, a nodethat is generating many queries to a single database may “batch” multiple queriesper TCAP message; each query is regarded by TCAP as an invoke component. Thedatabase application may similarly batch responses; each “normal” response is areturn response component. For handling of abnormal conditions, there are alsoreturn error and reject components. Note that when multiple invoke componentsare bundled into a single TCAP message, the responses do not have to be bundled inthe same way. To TCAP, application-specific data (such as the MAP queriesdiscussed in Section 8.7) appear as one or more parameters. TCAP does not try toparse or otherwise examine application-specific data.

We have seen that TCAP uses the transaction portion to match each message tothe correct application. TCAP keeps track of individual operations within a transac-tion at the component layer and can tell certain things (e.g., whether this is aninvoke or some sort of response; whether error-handling is necessary) without anyknowledge of the application-specific data. This information may assist in makingsure that each component is handed to the right module within the receiving appli-cation (e.g., a MAP protocol entity). This suggests a tight coupling between TCAPand the higher-layer application. Such a coupling may blur the boundary betweenthe two layers, but might be expedient for implementation efficiency.

8.6.1 Number Portability

We have seen that toll-free numbers are not routable, and that the dealiasing processis realized via TCAP queries and responses (much as DNS is used to resolve URIs to

8.6 TCAP 99

IP addresses—see Section 7.3.3). TCAP queries are routed to the appropriate hostsusing GTT.

Toll-free numbers are not the only nonroutable telephone numbers. Numberportability uses the same technology and does so in a similar way. Number portabil-ity allows a customer to subscribe to a new carrier without changing his/her tele-phone number. When a number is “ported” to a new carrier, it becomes an alias fora routable number assigned by the new carrier. The binding between the portednumber and its alias is stored in a database. When someone dials the ported number,a TCAP query is launched toward that database; routing of the query (and the subse-quent response) relies on GTT. This sets off a sequence of events that inserts theroutable number at an appropriate point in an ISUP call flow. The whole process istransparent to the calling and called parties, who never see the routable number.

Wireless phone numbers are also aliases rather than true routable numbers. InSection 8.7, we look in detail at the dealiasing process for mobile terminated calls.

8.7 MAP

Wireless networks make heavy use of TCAP, particularly for keeping up with sub-scriber locations; this functionality is called mobility management. Some readersmay not be especially interested in mobility management (or may have reached thesaturation point for details about SS7). Readers who wish to skip this section cansimply keep the following points in mind:

• SS7’s footprint is still growing. Every mobile terminated call and short mes-sage relies on mobility management (we briefly describe Short Message Servicein Section 13.8). So wireless networks are extremely heavy users of SS7. (Num-ber portability is another reason for continued worldwide increases in SS7traffic volume; number portability implementations typically ride on top ofTCAP.)

• SS7 will continue to be important for years to come. As noted, the sheer scaleof SS7 deployments is one factor. Moreover, any would-be replacement forSS7 [e.g., Session Initiation Protocol (SIP)] would have to offer a great deal offunctionality. Moreover, early implementations of a successor protocol willnot be as robust as SS7 is today. Here we note that SIP is covered at length inChapters 11 and 12.

• Because of the aforementioned factors, we believe that sigtran will see wide-spread deployment. We briefly mentioned IETF’s Signaling Transport (sig-tran) working group in connection with SCTP (see Section 7.8.2); furtherdiscussion appears in Section 15.4.

Note that Section 8.8 refers to the material in the current section. The remainderof this book is largely independent of the material contained in the current section.

In wireless networks, voice switches are called mobile switching centers (MSCs).MSCs are similar to landline switches and are key components of the interconnect-ing infrastructure—that is, the infrastructure that:


• Connects radio towers within an operator’s network;• Connects the operator’s network to those of other operators (both landline

and wireless).

When a call comes into a wireless operator’s network (this is known as a mobileterminated call), the network has to know which MSC is currently serving the calledsubscriber. This information is maintained in a subscriber database called a homelocation register (HLR). MAP is the vehicle for maintaining such information inGSM wireless networks. In this section, we give two examples of GSM MAP signal-ing flows. Non-GSM wireless networks have entirely analogous functionality,although the details differ.

When a handset powers on, it must register with the network. The registrationprocess, which we now describe, is illustrated in Figure 8.6. The current servingMSC tells the HLR that it “sees” the handset (i.e., that the handset is talking to oneof the radio towers that said MSC subtends). This takes the form of a MAP UpdateLocation Request. At this point, the MSC knows little or nothing about the sub-scriber but has gleaned unique identifiers from its dialog with the handset and popu-lated the update location request therewith. Upon receipt of this request, the HLRlooks up the subscriber’s data (using the IDs previously mentioned) and returns theresult via a MAP Insert Subscriber Data message. Once the MSC acknowledgesreceipt of the subscriber data, the HLR acknowledges that the Update Locationrequest has been successfully completed. By this time, the HLR has updated the sub-scriber’s record with the identity of the serving MSC.

The Insert Subscriber Data message tells the MSC which services the customerhas subscribed to, among other things. The MSC needs to store this informationsomewhere; it does so in another database called a visiting location register (VLR).(In the abstract, MSC and VLR are functionally separate. However, the two func-tions are usually integrated into a single network element; we assume that this is thecase in our diagrams.)

At the TCAP and MAP layers, only the MSC/VLR and HLR are involved in thelocation updating procedure we have just described. Additional SS7 nodes (such asSTPs) are involved at the MTP and SCCP layers, however. In SCCP terms, the VLRand HLR are subsytems; the SSN is always 7 for VLR and 8 for HLR. Thus the

8.7 MAP 101

Update location ACK

Insert subscriber data ACK

Insert subscriber data

Update location

HLRServingMSC/VLR

GTTnode

SSN = 8SSN = 7

Figure 8.6 GSM location updating procedure.

SCCP headers for the Update Location and Insert Subscriber Data ACK messageswill have their destination SSNs set to 8. The destination SSNs for the other twomessages in Figure 8.6 will, by the same token, be 7. GTT may be required some-where along the way; this is reflected in the figure by the presence of a “GTT node”(perhaps this is an STP). If this is a roaming scenario (i.e., the subscriber is notattached to the network of his/her chosen carrier), then the serving MSC and HLRare in fact in different carriers’ networks. In this case, the serving MSC almost cer-tainly does not know the point code of the subscriber’s HLR but simply knows thepoint code of a GTT node that can correctly forward its MAP messages.

In Figure 8.6, we have omitted certain details in the interest of simplicity. Let usnote here that the HLR validates the subscriber before sending the insert subscriberdata message. Moreover, when a subscriber moves to a new MSC/VLR, there is anadditional step: the HLR must inform the previous MSC/VLR that the subscriberhas left its area. The subscriber data will be purged from the previous MSC/VLR as aresult. (If the subscriber is new or has not connected to the network in a long time,no MSC/VLR will have a copy of the subscriber’s data; essentially, there is no previ-ous MSC/VLR in this case.)

At this point, our subscriber has registered with the network. Now supposea call is placed to this subscriber. We now describe the signaling flow that appearsin Figure 8.7. In the figure, the nodes labeled “Gateway MSC” and “ServingMSC/VLR” inhabit the same carrier’s network. Assume for the moment that theGateway MSC (GMSC) is the originating switch. In keeping with this assumption,let us pretend that the grayed-out ISUP IAM message at the far left is not present.The serving MSC/VLR maintains a bank of routable numbers (numbers that areroutable to itself, that is). In short, this is what happens: the serving MSC/VLRselects a number from the aforementioned bank and temporarily binds that numberto the called subscriber. The serving MSC/VLR informs the gateway MSC of theroutable number it has selected for this call. The gateway MSC then initiates an ISUPcall flow using the number temporarily assigned by the serving MSC/VLR. Note thatthis process is transparent to the calling and called parties: they never see the phonenumber that is temporarily assigned by the MSC.

The complicating factor in all of this is that the HLR must act as intermediarybetween the GMSC and the serving MSC/VLR. (As we have seen, the HLR knowswhich MSC is currently serving the subscriber.) When the call request comes in, theGMSC interrogates the HLR regarding the subscriber’s whereabouts in the form of


GatewayMSC

ISUP IAM

...ISUP call flow continues...

ISUP IAM

Provide roaming number ACK

Provide roaming number

Send routing info ACK

Send routing info

ServingMSC/VLR

HLR

Figure 8.7 Signaling for GSM mobile terminated call.

a MAP Send Routing Info message. Via an interchange with the serving MSC/VLR(MAP Provide Roaming Number and Provide Roaming Number ACK messages),the HLR obtains the aforementioned routable number, which it then forwards tothe GMSC in its MAP Send Routing Info ACK response. Note that the servingMSC/VLR has a limited supply of roaming numbers and therefore does not bind aroaming number to the called subscriber until it receives the Provide RoamingNumber request from the HLR. The GMSC can now send an ISUP IAM with theroaming number as the called party address. The ISUP call flow continues, just aswe saw in Chapter 6 (see Figure 6.8). Note that the IAM and subsequent ISUP mes-sages do not pass through the HLR. Global title translation may take place in therouting of MAP messages. However, we have omitted this detail from the represen-tation in Figure 8.7.

In our description, we essentially assumed that the calling and called parties aresubscribers for the same wireless carrier and are attached to that carrier’s network.Moreover, we assumed that the calling party’s serving switch is capable of interro-gating the HLR. (This capability, which is called gateway functionality, is not uni-versal among GSM MSCs. It is common, however, so the scenario we just describedis a reasonable one.) In this scenario, the GMSC collects dialed digits from thecaller’s handset, which leads to the Send Routing Info message shown in the figure,and so on. Note that all of the signaling depicted in Figure 8.6, along with the MAPdialog that appears in Figure 8.7, must take place before the GMSC and servingMSC/VLR can interchange ISUP call-control messages.

Now suppose that the calling and called parties are attached to different net-works. Then the calling party’s network sends an ISUP IAM to a designated switchin the called party’s network (hence the name gateway MSC). This is the grayed-outIAM that appears at the far left of the figure; receipt of this ISUP message causes thegateway MSC to launch its HLR query. In this case, an ISUP call flow is initiated bya switch in another carrier’s network; when it reaches the called party’s network,the ISUP entity must wait while the MAP entity obtains a roaming number.

In Figures 8.6 and 8.7, we do not show any signaling between the handset andthe MSC. Such signaling does take place but note that it is not SS7 signaling. TheSS7 network does not extend to the telephone (regardless of whether it is a wirelesshandset or a landline telephone).

8.8 Summing Up

SS7 involves much more than basic call control. Much of this chapter is concernedwith the following question: What happens when a switch wants to complete a callbut does not have a routable number? The glib answer is that the switch must querya database. This begs the question: How do we find the appropriate database?

The answer to the second question turned out to be long-winded; along the way,we found that SS7 routing functionality suffers from a lack of uniformity. For manyservices (including toll-free service), GTT is the answer. GTT, which is the responsi-bility of the SCCP layer, is therefore a crucial part of SS7’s routing capability. It isungainly that this routing capability is split between the MTP3 and SCCP layers.For example, we pointed out that routing tables must be maintained at both layers.Moreover, SS7 routing tables must be manually provisioned.

8.8 Summing Up 103

In a sense, MTP3 and SCCP are not the whole story of SS7 routing. More spe-cifically, MTP3 and SCCP are not enough when it comes to mobile terminated calls.In mobile networks, the game of “find the database” often boils down to “find theHLR.” We presented two examples that involved finding the HLR. For the first sam-ple signaling flow (the update location example of Figure 8.6), we said that MTP3,assisted by GTT at the SCCP layer, was adequate. But in the second flow (themobile terminated call of Figure 8.7), it was necessary for the GMSC to query theHLR. This begs the following question: What is the essential difference between thetwo flows?

The obvious difference is that the first flow is composed entirely of MAP mes-sages, whereas the second call flow also includes ISUP call control messages. ForMAP, the protocol stack includes SCCP. ISUP runs directly over MTP3. Thus GTTis possible in the first flow, but the GMSC cannot use GTT to “directly” forward theincoming ISUP message in the second flow. From this point of view, we can think ofthe ensuing MAP signaling flow as a sort of glorified global title translation.

Continuing with this train of thought, one might wonder why the calling party’sserving switch does not query the HLR to obtain a routable number before launch-ing an ISUP IAM toward the called party’s network. This is because switches inexternal networks may not know how to query an HLR. A secondary reason is thata carrier may not want to expose its roaming numbers to the scrutiny of outside par-ties. In both cases, it is a matter of maintaining transparency—switches in externalnetworks do not have to know whether they are calling wireless subscribers. In wire-line networks, switches do not even know that HLRs exist. For a mobile-to-mobilecall, a similar problem exists when the calling and called parties employ differenttechnologies (e.g., a CDMA subscriber cannot query a GSM HLR without some sortof translation because the syntaxes are different).

Another sort of translation goes on, although we have not emphasized it up tothis point. In Figure 8.7, an ISUP IAM enters the GMSC with one called partynumber (the called party’s “permanent phone number”) and is forwarded by theGMSC with a different called party number (namely, the roaming number suppliedby the called party’s serving MSC/VLR). This translation must be reversed by theGMSC when it receives an ISUP ACM and subsequently an ISUP ANM from theserving MSC/VLR. This translation is not a GTT, because ISUP runs directly overMTP3. (Recall that the roaming number is not exposed to external entities. Thereader may want to refer back to the ISUP call flow in Figure 6.8, since the ISUP por-tion is truncated in the diagram for our mobile terminated scenario.) We note herethat network address translation (described in Section 7.3.1) bears a strong resem-blance to the type of translation discussed in this paragraph.

8.8.1 Additional Weaknesses of SS7

SS7’s approach to routing is not ideal—we have “beat that horse to death” over thelast several paragraphs. In addition, SS7 was devised for use with low-speed links(and links with potentially high bit error rates to boot). Much of the complexity ofMTP2 and MTP3 exists because SS7 needed to operate reliably in the presence ofthese limitations. But that complexity may not be warranted in deployments thatenjoy high-speed transmission and low bit error rates.


8.8.2 Strengths of SS7

One SS7 link can carry the signaling traffic for many voice channels. This was one ofthe initial motivations for out-of-band signaling, but it also meant that SS7 link out-ages would have major detrimental effects. Thus the SS7 protocol stack provides forredundancy. Using the protocol stack’s built-in redundancy features, SS7 networksare typically engineered to an extremely high degree of reliability. SS7 is deployed ina physically secure way. That is, the SS7 network extends only to voice switches,STPs, and SCPs; all of these network elements are physically under lock and key.(How can you hack a network that you cannot touch?) Moreover, SS7 is a stableand mature technology (“it works”). Lastly, SS7 is extremely flexible.

References

[1] Recommendation Q.700, Introduction to CCITT Signalling System No. 7, ITU–T, March1993.

[2] Manterfield, R., Telecommunications Signalling, Revised ed., IEE Publications, February1999.

[3] van Bosse, J. G., Signaling in Telecommunication Networks, New York, London: JohnWiley and Sons, January 1997

[4] Russell, T., Signaling System, No. 7, 4th ed., New York: McGraw-Hill, June 2002.

8.8 Summing Up 105

C H A P T E R 9

The Bearer Plane

This chapter features a brief discussion of voice-encoding schemes. A variety ofencoding techniques are available now that did not exist when the design principlesfor circuit-switched networks were formulated. As a result, it is not easy to incorpo-rate voice-encoding innovations into today’s telephone networks. This is one of themotivations for migrating to packet telephony.

Having set the stage, we begin our discussion of Voice over IP in earnest. Thatdiscussion will continue in subsequent chapters.

9.1 Voice Encoding

Today’s voice network is digital. That is, voice signals are not transmitted betweenswitches as continuously varying waveforms. Instead, for each active call, the trans-mitting switch periodically sends a string of 0’s and 1’s. (We confess that this is not,strictly speaking, quite accurate: the 0’s and 1’s themselves are encoded for trans-mission across the physical medium as waveforms. But voice signals are representedby strings of 0’s and 1’s; switches do not attempt to transmit the original voicewaveforms directly.)

A scheme for converting analog waveforms to digital format (and for convert-ing back to analog at the receiving end of the resulting digital transmission) is oftencalled a codec (an elision of the words “coder” and “decoder”). The digitizingprocess necessarily results in some loss of information—the recreated signal at thereceiving end is not exactly the same as the input signal at the transmitting end.

9.1.1 G.711

Let us look at an example. For the G.711 codec [1], the sampling rate is 8,000 Hz.This means that the encoding device “polls” the analog signal 8,000 times per sec-ond and produces a chunk of digital information at each polling epoch. (G.711, anexample of a pulse code modulation scheme, is by far the most common voice-en-coding method. While certainly not the first codec to be developed, G.711 was thefirst to see widespread use outside of military applications.)

To understand why a sampling rate of 8,000 Hz was chosen, one needs to knowthat most of the energy in conversational voice signals falls in the frequency bandbelow 4,000 cycles per second, or Hz. So, for purposes of understanding what theperson on the other end of the phone line is saying, loss of information at frequen-cies above 4,000 Hz is tolerable; we say that voice is (essentially) band-limited. The

107

Nyquist theorem says that all of the information in a band-limited signal can berecovered from samples in discrete time, as long as the sampling rate is at leasttwice the maximum frequency found in the original (continuously varying) signal.Thus in the case of conversational voice, a sampling rate of 2*4,000 = 8,000 Hz issufficient.

The digitizing process entails loss of information in another way. Each sampleinvolves measurement and quantization of a voltage. Returning to the case ofG.711, each sample is represented by an 8-bit field, meaning that there are only 28 =256 possible values; each of these values has a range of voltage measurementsassigned to it. This assignment of a range of measurements to a single value is calledquantization. (Note that 8 bits/sample times 8,000 samples/sec yields 64 kbit/s, thebit rate first mentioned in Section 3.2.2.)

9.1.2 Why Digital?

Given the fact that information is lost in the digitizing process, why bother to digit-ize voice signals in the first place? One answer is that error detection and correctionare possible in the digital realm, whereas they are nearly impossible for analog sig-nals. For error detection and correction, some level of redundancy (in the form ofextra bits) is added to the payload. The particulars vary from one error-handlingscheme to another; cyclic redundancy check is a widespread approach for detectingcorrupted speech frames. Mobile wireless communications typically employ for-ward error correction (e.g., convolutional or block codes) in conjunction with inter-leaving to overcome signal fades.

Digital signals can also be regenerated. Transmission through physical media isimperfect; in particular, the waveforms representing the information being transmit-ted attenuate over distance. Regeneration is the process of taking an input signal thathas begun to degrade (but is still intelligible) and producing a robust copy of the sig-nal. A digital signal is just a bit stream and is therefore intelligible as long as thereceiving device can distinguish 0’s from 1’s. A regenerator that receives a degradedbut still intelligible signal can transmit a “clean” copy of the same bit stream.

Another advantage of digital signals is that they can be encrypted. For example,signals from wireless phones are ciphered to prevent eavesdropping.

9.1.3 Other Voice-Encoding Schemes

In his survey article [2], Cox enumerates the following key attributes of voice-encod-ing schemes: bit rate, delay, implementation complexity, and quality. G.711 pro-vides good voice quality (at least when transmitted over media with low bit errorrates) and is not very complicated. But in this era of cheap and plentiful processingpower and memory, G.711 has a higher bit rate than it needs to; therefore it is notideal for circumstances in which transmission bandwidth is at a premium. Becauseof its high voice quality and widespread use, G.711 is a reference point againstwhich other codecs are compared.

G.711 takes advantage of the fact that voice is band-limited (recall our earliercomments about sampling rate). But this is the only aspect of conversational voicethat G.711 takes into account; for developers of fax machines and modems, this

108 The Bearer Plane

turned out to be an advantage. G.711 performs a straightforward discretization ofthe input waveform. Codecs that operate in this fashion are known as waveformcoding schemes. Can we lower the bit rate and still remain in the relatively simplerealm of waveform coders? To a degree, it is possible to do so while retaining goodvoice quality. The G.721 scheme [3] encodes differences between successive samples(rather than encoding the samples themselves, as in G.711) and employs some quan-tizing tricks to reduce the bit rate to 32 kbit/s. Recommendation G.726 [4] specifiesan enhanced version of G.721’s 32 kbit/s scheme and also introduces 16 kbit/s, 24kbit/s and 40 kbit/s variants.

Waveform codecs do not perform well at low bit rates; 16 kbps is probably “pu-shing the envelope.” Source coding schemes try to exploit the characteristics of thehuman voice (via modeling of the human vocal tract) in search of increased effi-ciency. To emphasize this point, such schemes are often called vocoders (for “voiceencoders”). Some vocoders also exploit certain limitations of the human auditorysystem (for example, phase distortion is not easily detected by the human ear). Out-put from early vocoders sounds artificial (although they can intelligibly reproducespeech at very low bit rates). Hybrid coding schemes, which employ a degree ofwaveform matching in the context of speech production models, were introduced toaddress this shortcoming. There are many vocoders; due to space limitations, wewill only look at a few. (We will use the word “vocoders” as a blanket term encom-passing source and hybrid schemes. Note, however, that there seems to be somevariation in usage.) Vocoders share the following feature: encoder and decoder both“think” in terms of the same mathematical model; the encoder sends parameter val-ues associated with the model to the decoder.

Many of the vocoders in common use today employ code excited linear predic-tive (CELP) schemes. Now we briefly explain the meanings of the terms that makeup this acronym. Such a vocoder uses a linear predictive coding filter to model thevocal tract; the vocal tract is made up of the tongue, the teeth, the oral cavity itself,and so on. The term linear filter has a rigorous mathematical machinery associatedwith it. For our purposes, the filter is simply the thing that converts input (puffs ofair traveling up from the lungs through the larynx) to output (the speech utteranceitself). We say that the input signal excites the linear filter. The mathematical detailsare beyond our scope; suffice to say that filtering is a big part of what digital signalprocessing hardware does. Although much of the requisite mathematics has beenaround for a long time, the digital signal processing “muscle” to implement sophis-ticated codecs has not.

For each sound, the encoder needs to observe (and communicate to the decoder)whether the input to the vocal tract is voiced (i.e., the vocal cords are activelyengaged) or unvoiced. As an example, the initial consonant is voiced in the word“vocal” and is unvoiced in the word “focal.” Actually, source coders distinguishbetween voiced and unvoiced sounds but do not further characterize the filterinput. Researchers realized that this was not enough to reproduce speech in anatural-sounding manner and set about defining a catalog of input signals called acodebook. Each codebook entry is called a code vector because it specifies multiplecharacteristics of the input signal. Since encoder and decoder must each maintaina copy of the codebook, we see that a CELP vocoder has nontrivial memoryrequirements.

9.1 Voice Encoding 109

Like waveform encoders, CELP encoders typically sample speech at 8,000 Hz(or, in other words, sampling is performed at intervals of 125 µsec). A CELPencoder will then group the PCM samples into blocks of fixed length. For eachblock, the encoder determines which code vector (among all of the codebookentries) most closely reproduces the input waveform. The encoder transmits theindex of this code vector, along with a set of linear filter parameters and a gain fac-tor, to the far end. The far end produces an output signal in accordance with theseparameters.

G.728

The key design goal for G.728 [5], an early CELP vocoder, was to minimize delaywhile acheiving a moderately low bit rate (16 kbit/s). G.728 groups samples intoblocks of five. Therefore it only takes 625 µsec to accumulate a block. Moreover,there is no look-ahead. The codebook has 210= 1,024 entries, so a 10-bit field isadequate to uniquely specify a code vector. Although this codec produces goodvoice quality, it is expensive to implement because its processing requirements aredemanding.

G.723.1 and G.729

In the mid-to-late 1990s, numerous codecs were standardized. The G.723.1 vocoder[6] can operate at two rates (5.3 kbit/s or 6.3 kbit/s); the rate can be changed duringa session. Samples are grouped into blocks of 240, and a look-ahead of 7.5 msec isused. So G.723.1 has an inherent delay of 240 * 125 µsec + 7.5 msec = 37.5 msec.The delay inherent in an encoding scheme is known as algorithmic delay.

The G.729 vocoder [7] operates at 8 kbit/s. Samples are grouped into blocks of80 and there is a 5 msec look-ahead, resulting in an algorithmic delay of 15 msec.The complexity of this codec is a major shortcoming. This led to the specification ofG.729 Annex A [8], which introduces some simplifications. The trade-off is thatthere is a slight reduction in voice quality. Further information on these codecs canbe found in [9, 10].

G.723.1 and G.729 have silence suppression features (specified in [11, 12],respectively; see also [13] for information on the latter). Later annexes to the G.729standard introduced vocoders with different bit rates than the original 8 kbit/s.

The GSM Adaptive Multirate Family of Vocoders

The adaptive multirate (AMR) codec (see [14] and references therein) is an intrigu-ing example. For each GSM voice call, a fixed-rate voice channel is allocated; this iseffectively an 11.4 kbit/s channel (the so-called half rate case) or a 22.8 kbit/s chan-nel (the full rate case). Transmission between handset and radio tower chronicallysuffers from high bit error rates; GSM’s error correction scheme compensates forthis. If radio conditions are particularly bad, however, GMS’s default level of errorcorrection is not sufficient to keep the voice signal from “breaking up.” This is themotivation for AMR.


AMR can operate at a variety of bit rates ranging from 4.75 kbit/s to 7.95 kbit/sin the half rate case or 4.75 to 12.2 kbit/s in the full rate case. The AMR source canchange its bit rate at 20-msec intervals. Let us concentrate on the half rate case.When the codec is operating at 7.4 kbit/s, the remainder of the 11.4 kbit/s “chan-nel” is consumed by necessary overhead. When the codec is operating at 4.75 kbit/s,what happens to the extra channel bandwidth? It is used for additional error correc-tion. The idea is this: in poor radio conditions, it is better to use a low bit ratescheme; although its output is less natural-sounding, it is still intelligible. By freeingsome of the channel capacity for error correction, we hope that the encoded voicesignals will consistently make it to the far end intact.

Further Investigation

In this section, we barely touched on a vast subject area. The reader can find muchmore information in speech processing texts (e.g., [15]) and/or filter theory texts(e.g., [16]). We have not talked about evaluation of speech quality—how does onequantify the performance of a vocoder or the perceptual effects of latency? This isanother large subject; Hardy’s recent book [17] gives broad coverage.

9.2 Bearer Interworking

9.2.1 Transcoding

Whenever participants on a call use different codecs, transcoding (that is, transla-tion between codec formats) must be performed somewhere along the bearer path.For example, when a landline telco subscriber is connected to a wireless customer,transcoding must occur between the landline codec (usually G.711) and the wire-less-specific codec.

Even for mobile-to-mobile calls involving more than one MSC, G.711 is almostalways used on the inter-MSC “legs’’ of the bearer paths. This is because today’sMSCs are based on landline circuit switches, whose interswitch trunking is based inturn on the 64 kbit/s “quantum.” Each transcoding instance entails a loss of qualityand incurs some delay. Note, however, that transcoding to and from G.711 simpli-fies things in a way: to connect mobile subscribers using different codecs (e.g.,because their carriers have deployed incompatible wireless technologies), no addi-tional bearer-plane functionality is required. The two MSCs both “speak” G.711(and they already transcode to and from this common codec as a matter of course).In particular, an MSC in one carrier’s network does not have to know which codecsare supported by its counterpart in the other carrier’s network.

9.2.2 Encapsulation of Digitized Sound

Now that we have digitized voice, what happens next? At ingress to the packet voicedomain, the encoded voice is encapsulated and transmitted as a stream of packets.The encapsulation must adhere to a defined format so that the device at the far endwill know how to feed the digitized signal to the voice decoder.

9.2 Bearer Interworking 111

In traditional circuit-switched networking, voiceband transmission is voicebandtransmission. That is, we do not have to afford special treatment to fax signals,modem signals or dual tone multifrequency (DTMF) digits. (For readers familiarwith the marketing term “touch tone” but not DTMF, these are two names for thesame thing.) The developers of fax and modem technology took advantage of thefact that waveform codecs (such as G.711) really are not specific to voice. Data isencoded as an analog signal using voiceband tones (i.e., tones whose frequencies areless than 4,000 Hz). The analog signal is, in turn, passed through a G.711 encoder.The latter has no idea it is digitizing data rather than voice, and the relationshipbetween the bits that are encoded in an analog modem signal and those representingthe resulting G.711 samples is oblique. But to the fax machine or modem at the farend, the reconstituted analog signal emanating from the G.711 decoder is an intelli-gible data stream. Note that the conversion from analog to digital and back to ana-log is a lossy process; therefore it matters how many times this translation takesplace. (This is one reason why modem performance varies from place to place: fortelephone customers who are not served by so-called subscriber loop carriers, thisconversion normally takes place only once; in the presence of a subscriber loop car-rier, it takes place a second time. The second conversion does not perceptibly affectspeech quality, but it has a marked effect on modem performance.)

DTMF transmission is similar to fax and modem transmission, except thatspeed is not an issue. That is, modems and fax machines try to “pump bits” throughvoice channels, and throughput is important. Modems have gotten faster overthe years as modulation schemes have improved. DTMF applications (such asentering PINs for credit card calls) came about because telephone sets have tradi-tionally lacked a more sophisticated signaling capability. These applications neededsome cost effective way to obtain information from subscribers; for example, itwould be enormously expensive to have each PIN verification processed by anoperator. Thus DTMF sensors enable an array of services that otherwise would notbe cost effective.

Special-purpose encapsulation formats for fax, modem, and/or DTMF signalsmay be necessary as vocoders see increasingly widespread deployment. This isironic, given that fax, modem, and DTMF signals would never have been prevalentif it had been easy to send packets in the first place. Now that we are evolving topacket telephony, why do we have to accommodate all of this legacy stuff? The real-ity is that packet telephony will phase in very slowly, and it does not make good eco-nomic sense for carriers to dump workable technology that still generates revenue.Likewise, corporate subscribers may have substantial investments in older technol-ogy (e.g., back-end systems that can be controlled by DTMF signaling) that they arenot ready to write off.

Interactive voice recognition (IVR) systems may also be affected by the emer-gence of new codecs. For complex DTMF-driven applications, navigating throughthe menus can be frustrating, to say the least. Many companies (such as airlines)now employ voice-driven systems. Early generations of IVR technology are notmuch of an improvement on their DTMF forerunners. But this may change substan-tially as the intelligence and accuracy of such systems evolves. Most IVR systemsexpect G.711-encoded voice as input. Of course, one can transcode to G.711, butIVR performance may vary with the “original” codec.


9.2.3 Packetization Delay and Playout Buffers

Two sources of delay associated with packet telephony are worth mentioning here.Bearer traffic must be packetized at ingress to the voice-over-packet domain; thisprocess is the first source of delay. It would be very inefficient to transmit a packetevery time a “quantum” of information was received from the encoder (eitherdirectly or via transmission through the circuit-switched domain). If, for example,each encoded block emanating from a vocoder were to be packetized separately, thepayload would be dwarved by the packet headers.

If the packetizer is willing to wait, more payload will stream in from the encoder(samples in the case of a waveform coder; block encodings in the case of a vocoder)and the payload-to-overhead ratio will improve. Thus there is a fundamentaltrade-off between throughput efficiency and delay. In many situations, it may notbe worthwhile to deploy a vocoder with low algorithmic delay (such as G.728).The packetization delay may be such that one is unable to reap the low-delaybenefits of the vocoder. The number of encoded blocks per packet is often a config-urable parameter; in such cases, we can think of packetization delay as an adjustablething.

The second source of delay resides at egress. Packet-switched networks typicallysuffer from higher jitter than circuit-switched networks: if packets are dispatchedacross a packet-switched domain at regular intervals, they may not reach the far endat regular intervals. Therefore, playout buffers are usually present at egress pointsfrom the packet-switched domain; these buffers “smooth out” jitter but at the costof additional delay. Buffer sizing (as well as the attendant delay) depends on theseverity of jitter. When a PC user streams an audio clip from a Web site, there is asignificant delay before the playout commences. The media player is waiting for itsbuffer occupancy to reach a threshold level; in our experience, this is a fairlyextreme example of playout buffer delay.

9.3 Voice over IP

Voice can be borne by a variety of packet technologies, including ATM and FrameRelay; there is nothing sacrosanct about IP in this regard, and our exposition to thispoint applies to packet telephony in general. Since the clear industry direction forpacket voice is VoIP, we now turn our attention to its particulars.

Note that we do present a limited discussion of Voice over ATM in Section A.3.We point out that, since ATM was designed from the beginning with real-time serv-ices in mind, “how to ‘do’ Voice over ATM” is quite well established. In contrast,carrier grade VoIP is still a work in progress.

9.3.1 Real-Time Services in IP Networks: RTP over UDP

“Voice over IP” is essentially an abbreviation for Voice over Real Time TransportProtocol (RTP) over UDP over IP. That is, encoded voice “frames” are encapsulatedin RTP packets and then handed off to the UDP layer. RTP is not just for voice. Itwas also designed as a transport protocol for real-time video, and care was taken to“leave the door open” for other real-time applications to use RTP in the future.

9.3 Voice over IP 113

RFC 3550

The base RTP specification, RFC 3550 [18], has limited scope. In keeping withmodular design principles, this document defines functionality that is required bymost if not all real-time applications. Details of specific applications are relegated toseparate profile and payload format documents. We discuss a few examples later inthis section.

Along with RTP itself, RFC 3550 defines the RTP Control Protocol (RTCP).With RTCP, the distinction between the control and bearer planes gets a littleblurry: RTCP provides rudimentary control capabilities and a means of identifyingmultimedia session participants. RTCP can also be used to monitor data deliveryperformance. The RTP/RTCP specification does not define any resource reservationfunctionality. Thus RTP/RTCP cannot, by itself, offer QoS guarantees.

By design, RTP and RTCP are independent of the transport and network layers.So it is not necessary that RTP be carried over UDP (or even IP, for that matter). It isexpedient to carry RTP over UDP, however; we have seen that TCP’s retransmissioncapabilities are ill-suited to real-time applications. In some situations, firewall issuesmay dictate the use of TCP (but the extra overhead in the TCP header is simplywasted in this case).

The standard insists that RTP and RTCP packet streams be distinguishable at alower layer (e.g., by assigning different UDP port numbers to the two protocols—thedefault port numbers for audio/videoconferencing applications are 5004 for RTPand 5005 for RTCP).

The RTP header format is displayed in Figure 9.1. Up to and including the syn-chronization source (SSRC) identifier, all of the fields shown must always be pres-ent. The first field, V, indicates that the current protocol version number is 2. The Pbit, if set, indicates that padding octet(s) follow the payload. If the X bit is set, itmeans that exactly one header extension follows the fixed header shown in thefigure. The CC field tells how many contributing source (CSRC) identifiers followthe mandatory header fields. The CC field is 4 bits long and the value zero isallowed. The interpretation of the M, or marker, bit varies depending on the profile;we discuss profiles later.

Since many codecs are in use nowadays, we need a way to identify the codec thatproduced the RTP payload. The 7-bit payload type (PT) field is used for this purpose


PTMCCXPV = 2

...contributing source (CSRC) identifier(s), if any, begin here...

Synchronization source (SSRC) identifier

Timestamp

Sequence number

Figure 9.1 RTP header.

in audio, video, and multimedia applications. The sequence number increments by 1for each packet sent. The contents of the timestamp field can be (but do not have tobe) based on the Network Time Protocol [19] format. We will not cover the SSRCidentifier and CSRC identifier fields, except to say that a session participant’s SSRCID can change during the life of the session. Note that no length field appears in theRTP header; RTP payload length can be deduced from the UDP length field (orother lower-layer header) and other information (e.g., the CC field).

The RTCP packet header is similar to that of RTP. RFC 3550 defines the fol-lowing five RTCP packet types:

1. Sender reports (SRs) are used by session participants to send transmissionand reception statistics.

2. Session participants that “listen” but do not send RTP packets use receiverreports (RRs) to send reception statistics.

3. Source description (SDES) packets can contain various items such as a user’spreferred display NAME or EMAIL address. There is only one mandatorySDES item: this is the canonical name, or CNAME. CNAMEs often take theform user@host and are important because they remain constant; SSRCidentifiers are bound to them. If it becomes necessary to change aparticipant’s SSRC ID during the lifetime of a session, RTCP is used toestablish a binding between the new SSRC ID and the participant’sCNAME.

4. A BYE packet is used to indicate that an entity wants to terminate itsparticipation in a session.

5. APP packets are used for application-specific purposes.

Payload Formats and the RTP/AVP Profile

RFC 3551 [20] specifies the so-called RTP/audio/video profile (AVP) profile, whichis specific to the domain of audio and videoconferencing. Among other things,RTP/AVP includes a default mapping of PT numbers to encoding schemes. Forinstance, the PT number for G.729 is 18. RTP/AVP also defines the RTP payloadformat for G.729: that is, it defines the manner in which the G.729 parametersshould be arranged in encapsulating RTP packets. RTP/AVP provides PT and pay-load format specifications for other common audio and video codecs. (Note thatsome PT values are statically assigned, whereas others are left for the applicationsthemselves to negotiate via signaling.)

Payload formats for many codecs are specified in separate RFCs. Examplesinclude [21] for AMR, [22] for comfort noise, and [23] for DTMF tones (as of thiswriting there is Internet draft activity that seeks to update or obsolete the currentDTMF RFC).

To understand the need for comfort noise, consider the following. Even duringtwo-way conversations (let alone conference calls with many participants), partici-pants do not speak all of the time. Conservative estimates indicate that participantsare silent, on average, at least 60% of the time. Why transmit vocoder frames whenthere is no content? Actually, it is disconcerting for the listener to hear “talk bursts”interspersed with periods of complete silence. Therefore, so-called comfort noise


packets are transmitted during periods of speaker inactivity. This allows the decoderat the far end to produce background noise, which sounds far more natural to the lis-tener. Comfort noise packets consume much less transmission bandwidth thanspeech packets, as fidelity is not important in reproducing background noise. Somevoice codecs provide for discontinuous transmission with comfort noise generationwhereas others do not. The intent of the comfort noise RTP payload format specifi-cation is to standardize this capability for use with codecs that do not offer built-insupport.

References

[1] Recommendation G.711, Pulse Code Modulation of Voice Frequencies, ITU-T, 1972.[2] Cox, R. V., “Three New Speech Coders From the ITU Cover a Range of Applications,”

IEEE Communications Magazine, September 1997, pp. 40–47.[3] Recommendation G.721, 32 kb/s Adaptive Differential Pulse Code Modulation

(AD-PCM), ITU-T, 1988.[4] Recommendation G.726, 40, 32, 24, 16 kb/s Adaptive Differential Pulse Code Modulation

(ADPCM), ITU-T, 1990.[5] Recommendation G.728, Coding of Speech at kbit/s Using Low-Delay Excited Linear Pre-

diction, ITU-T, 1992.[6] Recommendation G.723.1, Dual Rate Speech Coder for Multimedia Communications

Transmitting at 5.3 and 6.3 kbit/s, ITU-T, 1996.[7] Recommendation G.729, Coding of Speech at kbit/s Using Conjugate-Structure Algebraic

Code-Excited Linear Prediction, ITU-T, 1996.[8] Recommendation G.729, Annex A, Reduced Complexity 8 kbit/s CS-ACELP Speech

Codec, ITU-T, 1996.[9] Schroder, G., and M. H. Sherif, “The Road to G.729: ITU 8 kb/s Speech Coding Algorithm

With Wireline Quality,” IEEE Communications Magazine, September, 1997, pp. 48–54.[10] Salami, R., et al., “ITU-T G.729 Annex A: Reduced Complexity 8 kb/s CS-ACELP Code for

Digital Simultaneous Voice and Data,” IEEE Communications Magazine, September1997, pp. 56–63.

[11] Recommendation G.723.1 Annex A, Silence Suppression Scheme, ITU-T, 1996.[12] Recommendation G.729, Annex B, A Silence Compression Scheme for G.729 Optimized

for Terminals Conforming to Recommendation V.70, ITU-T, 1996.[13] Benyassine, A., et al., “ITU-T Recommendation G.729 Annex B: A Silence Compression

Scheme for G. 729 Optimized for Terminals Conforming to Recommendation V.70,” IEEECommunications Magazine, September 1997, pp. 64–70.

[14] TS 26.071, AMR Speech Code; General Description, 3GPP.[15] Rabiner, L., and R. Schafer, Digital Processing of Speech Signal, Engelwood Cliffs, NJ:

Prentice Hall, 1978.[16] Haykin, S., Adaptive Filter Theory, 4th ed., Upper Saddle River, NJ: Pearson Education,

2001.[17] Hardy, W. C., VoIP Service Quality, New York: McGraw-Hill, 2003.[18] Schulzrinne, H., et al., RFC 3550, RTP: A Transport Protocol for Real-Time Applications,

IETF, July 2003.[19] Mills, D., RFC 1305, Network Time Protocol (Version 3) Specification, Implementation

and Analysis, IETF, March 1992.[20] Schulzrinne, H., and S. Casner, RFC 3551, RTP Profile for Audio and Video Conferences

With Minimal Control, IETF, July 2003.


[21] Sjoberg, J., et al., RFC 3267, RTP Payload Format and Storage Fomat for the AdaptiveMultirate (AMR) and Adaptive Multirate Wideband (AMR-WB) Audio Codecs, IETF, June2002.

[22] Zopf, R., RFC 3389, Real-Time Transport Protocol (RTP) Payload for Comfort Noise(CN), IETF, September 2002.

[23] Schulzrinne, H., and S.Petrack, RFC 2833, RTP DTMF Digits, Telephony Tones andTelephony Signals, IETF, May 2000.


C H A P T E R 1 0

Media Gateway Control and OtherSoftswitch Topics

Recall the following softswitch terminology: bearer traffic enters/exits the fabric ofa distributed switch via media gateways (MGs). Often the media gateways belong-ing to a single switch are geographically dispersed.

Media gateway controllers (abbreviated hereafter as MGCs or controllers)direct the operation of media gateways. When a distributed switch receives a callsetup request, it is the media gateway controller that must determine the identities ofthe ingress and egress media gateways. The media gateway controller then instructsthese media gateways to set up a bearer path through the switch fabric. The twobest-known protocols for this purpose are called MGCP and Megaco/H.248.(MGCP and Megaco are both abbreviations for Media Gateway Control Protocol.)

Signaling gateways are the ingress/egress points for call control signaling.Megaco/H.248 [1] and MGCP [2] are the primary topics in this chapter. Before

addressing them, we take a look at generic media gateway control requirements. Wealso cover some preliminaries [notably Session Description Protocol (SDP)]. Thenwe discuss Megaco/H.248 (in considerable detail), followed by MGCP (in lessdetail). We finish the chapter with a few other softswitch topics.

Even though we cover Megaco/H.248 before MGCP, it was historically theother way around: the IETF and ITU-T joined forces to develop a successor toMGCP, and Megaco/H.248 is the result. As part of the process, IETF’s MegacoWorking Group produced a requirements document [3]. Note that early versions ofMGCP (as well as some precursor protocols that were subsumed by the develop-ment of MGCP) predate the requirements RFC. So the authors of the requirementsRFC had the benefit of experience gained in the development of MGCP.

10.1 Requirements

The question “How should MGCs exert control over media gateways?” begs ques-tions about the capabilities of the MGs themselves.

What Is a Media Gateway Supposed to Do?

In broad strokes, the distinctions between softswitch functional elements (mediagateway controllers, media gateways, and signaling gateways) are clear. The detailsare not necessarily so clean-cut, however, and implementations may vary. This pres-ents a challenge: on the one hand, any protocol for media gateway control must

119

make some assumptions about the division of functionality between controllers andmedia gateways. On the other hand, the protocol should not be prejudiced towardany particular implementation approach.

Moreover, the sum of required media gateway functionalities across all plausi-ble deployment scenarios is quite extensive. It would not be cost effective to requirethat every media gateway support every functionality; in many, if not most, situa-tions, a proper subset would be perfectly adequate. The Megaco and MGCP RFCseach impose baseline requirements on media gateways and then relegate optionalfunctionality to so-called packages. Controllers can query media gateways to deter-mine which packages they support.

Lastly, required media gateway functionality might be expected to evolve as newtechnologies and protocols emerge. The flexibility to define new packages affordsa degree of extensibility.

The requirements document assumes that MGs possess the followingcapabilities:

• Support for maintenance functions, including establishment and maintenanceof associations with controllers:• The protocol must be flexible enough to support load sharing among con-

trollers and robustness in the face of failure scenarios (i.e., fail-over capabili-ties). Although we do not discuss it in detail in this book, such functionalityis crucial for achieving carrier-grade reliability.

• Connection management, including:• Capacity to allocate resources to connections (and to later deallocate those

resources). The umbrella term “resources” is meant to include transcoders,voice recognition systems, and the functional components that playannouncements.

• Support for conferences as well as point-to-point connections.• Ability to report status of resources to the MGC.• Ability to detect events and apply signals. The degree to which this is necessary

depends on the bearer types that a given MG terminates.• Ability to recognize inband signaling and act accordingly. The degree to which

this is necessary depends on the bearer types that a given MG terminates. Theability to detect DTMF digits is a very common example.

Events, signals and inband signaling take a variety of forms. Moreover, the dis-tinction between events and inband signaling is sometimes hazy. To clarify the ter-minology, we offer the following examples.

Example events for analog lines are on-hook and off-hook transitions. Causinga phone at the far end of an analog line to ring is an example of applying a signal.Additional examples of signals include applying dial tone and playing announce-ments. Signals are typically generated by the MG.

Unfortunately, the industry standard terminology in this area seems to sufferfrom a substantial degree of built-in ambiguity. When we speak of signaling traffic,we are often talking about messages that “live” in the packet domain (e.g., SS7 orISDN call-control messages). DTMF tones on analog lines exemplify an altogether

120 Media Gateway Control and Other Softswitch Topics

different type of signaling. Where confusion would otherwise be possible, we willinclude the word message when referring to the former type of signaling traffic.

In the case that a media gateway terminates a link carrying signaling messages,there are two choices (assuming that we have not incorporated signaling gatewayfunctionality into our media gateway):

• Backhaul the signaling messages to a signaling gateway;• Report signaling messages to a media gateway controller as events.

Other Protocol Requirements

The requirements document also says that the protocol must:

• Support bearer connections involving arbitrary combinations of TDM,analog, ATM, Frame Relay, and IP. Note that this includes TDM-TDM,TDM-analog and analog-analog connections. Numerous requirements per-tain to specific bearer types; we will not detail such requirements here.

• Allow the MGC to assign varying priorities to different connections• Incorporate a means of specifying QoS parameters on a per-connection basis.• Offer a means for the MGC to specify QoS thresholds and for the MG to

report threshold violations.• Support a mechanism for the MG to report performance statistics and

accounting information.• Support a means for the MGC to specify which performance statistics and

accounting information should be collected and reported by the MG.• Be flexible in allocation of intelligence between MGC and MG.

Note that these are protocol requirements; this does not mean that every MGsupports every aspect of the protocol.

This list is by no means exhaustive. We hope it serves to illustrate the pointthat any robust protocol for media gateway control must support a complex arrayof functions. First of all, today’s circuit switches are sophisticated beasts, andsoftswitches must be capable of duplicating their functionality. (Otherwise, telcoswill stick with existing technology for a long time.) If softswitches are to functiontransparently in telco networks, then MGCs and MGs must conduct dialogs of widescope. This in turn demands a versatile lingua franca. Moreover, softswitches addinterworking between packet-switched and circuit-switched bearers to the mix.

10.1.1 ID Bindings

Softswitches must maintain bindings between identifiers in circuit-switched andpacket-switched domains. The requirements RFC emphasizes this point moreclearly for ATM bearers than for IP bearers (but it is fundamental in all cases).

Suppose we have a softswitch that terminates ISUP trunks and has an IP-basedfabric. ISUP trunks are distinguished by their circuit identification codes (CICs). Inan IP network, an audio stream can be uniquely identified by an IP address and port

10.1 Requirements 121

number. As calls come and go, the softswitch must keep track of bindings betweenCICs and (IP address, port number) pairs. These bindings, which are necessary toestablish end-to-end bearer paths, are created and dissolved by media gateways atthe behest of their controllers. For other softswitch configurations (e.g., an architec-ture that serves ISDN customers in the circuit-switched domain and employs anATM fabric), the details vary but the principle is the same.

10.2 SDP in Brief

As we saw in Chapter 9, a wide variety of voice-encoding schemes is now available.In the world of packet telephony, it is clear that vocoder selection must be negotia-ble; this is a major departure from the “hard-coded” approach of today’s cir-cuit-switched networks. Addresses in the packet domain must also be exchangeddynamically. Thus one needs a standard way to specify session parameters; SDP [4]was created for this purpose. Note that SDP’s scope includes multimedia sessions(although our examples will only involve audio).

Many protocols use SDP to specify session parameters (notably Megaco,MGCP, and Session Initiation Protocol; the latter is discussed at length in Chapters11 and 12). Use of SDP is not always mandated, but it is predominant in currentimplementations.

SDP is a text-based protocol. Some rudimentary “literacy” in SDP is necessaryto understand sample Megaco messages that appear later in this chapter. In this sec-tion, we present just enough content so that the reader can “parse” those messages.To that end, we present sample SDP text below. More information on SDP appearsin Chapter 12.

v=0o=- 2890844526 2890842807 IN IP4 192.168.0.50s=-t= 0 0c=IN IP4 192.168.0.50m=audio 4444 RTP/AVP 18a=ptime:20

We are primarily interested in the last three lines of our SDP sample. The syntaxof the “c=”, or Connection Data, series field is as follows:

c=<network type> <address type> <connection address>

It is easy to (correctly) guess that “IN” means Internet and “IP4” means that thelast field on the line is an IPv4 address.

For the last two lines of the SDP text, the reader may want to refer to supportingmaterial in Chapter 9 and/or consult the AVP specification [5] directly. The syntaxof the “m=”, or Media Description, field is:

m=<media> <port> <transport> <fmt list>

The first two subfields are therefore self explanatory. The next subfield says thatencoded voice will be transported over RTP; moreover, packet contents will beinterpreted according to the audio/video profile specification. Recalling that G.729


is AVP payload type 18, we see that the last subfield on this line specifies the codec.(During a negotiation, a list of codecs may appear on this line. Note also that, fromthe point of view of RTP payloads, G.729 and G.729A are indistinguishable. Soeither codec could be used.)

The last line says that the “ptime”, or packet time, attribute is 20 milliseconds.(Here “a=” stands for “attribute equals.”) Since G.729 groups samples into blocksof 80, a new block comes along every 80 * 125 µsec, or 10 msec. Thus it would bepossible to transmit a new RTP packet every 10 msec, or at any integer multiplethereof. With a ptime attribute of 20 msec, each RTP packet contains two blockencodings. (In fact, this is the default.)

We briefly describe the first four lines. The line “v=0” simply gives the SDP ver-sion number. For some mandatory fields, a “null” value is specified by a dash. Thereare two examples here: the username (the dash in “o=-” at the beginning of the sec-ond line) and the session name (the dash in “s=-” on the third line). The “o=” field isintended to serve as a globally unique session identifier; we omit further details. Hadwe wanted to specify start and stop times for our session, we would have enterednonzero values on the “t=” line.

10.3 Megaco/H.248

IETF and ITU-T have jointly developed a protocol for media gateway control. It iscalled Megaco by IETF and H.248 by ITU-T. Since the name “Megaco” is mne-monic, we will use it in preference to “H.248.” Version 2 of Megaco [1] wasapproved by ITU-T in the spring of 2002 and remains in force at the time of thiswriting. The corresponding IETF document, which is to supplant RFC 3525 [6], hasnot reached RFC status; it seems to be stuck in a “holding pattern” as anInternet-draft.

The requirements document discussed in Section 10.1 was produced by IETF’sMegaco Working Group. Megaco, which came after MGCP, was produced by thesame working group in concert with ITU-T’s Study Group 16. The Megaco specifi-cation is an outgrowth of the requirements process.

IETF and ITU-T have jointly endorsed Megaco/H.248 as the standard for mediagateway control. Thus Megaco is intended to supplant MGCP in the long run. Notethat, since MGCP enjoyed a substantial “deployment head start,” Megaco will notinstantly predominate.

10.3.1 Introducing the Megaco Connection Model

To understand Megaco, one must first understand its connection model. The con-nection model is an abstraction of a media gateway’s resources. When a media gate-way controller makes a request of a gateway (and the gateway answers), bothdevices are “thinking” in terms of the connection model. Of course, when a control-ler is talking to multiple gateways (e.g., in setting up an end-to-end call), it mustmake sure that the information is consistent.

The Megaco connection model’s two central concepts are termination and con-text. Roughly speaking:

10.3 Megaco/H.248 123

• Terminations are the “places”where media streams enter and/or exit mediagateways.

• Contexts describe the bindings between terminations.

10.3.2 Terminations

In Figure 10.1, an end-to-end bearer path has been set up between subscribers inareas 1 and 2 (users 1 and 2, say). For the sake of discussion, let us assume that:

• The shaded area labeled “distributed fabric” is a VoIP domain that uses theG.729A codec.

• There is a circuit switch (although none is shown) between user 1 and mediagateway A. The portion of the bearer path connecting area 1 to media gatewayA is an ISUP trunk. Signaling between area 1 and the softswitch will reach thesignaling gateway via an SS7 network. Voice is encoded on the ISUP trunkusing G.711.

• User 2 accesses the network via a private branch exchange. The portion of thebearer path connecting area 2 to media gateway B is an ISDN line. ISDN sig-naling between Area 2 and the softswitch will enter and exit the softswitch viamedia gateway B. Voice is encoded on the ISDN line using G.711.

There are four terminations along the bearer path: that of the ISUP trunk (T1 inthe figure), that of the ISDN line (termination T4), and two VoIP terminations (T2and T3). Termination T5, an analog line, will come to the fore in Section 10.3.9.

10.3.3 Contexts

In our example, terminations T1 and T2 are associated with one another, as are ter-minations T3 and T4. In Megaco terms, these associations are embodied in contexts.Note that each context is local to a media gateway. Thus, in Figure 10.2, there aretwo contexts:


Area 2

Area 3

Area 1

T5

T4T3T2T1

Media gateway A Media gateway B

Mediagateway controller

Signaling gateway

Bearer path

Termination

Distributed fabric

Figure 10.1 Megaco connection model: Terminations.

1. A context residing in media gateway A that associates termination T1 withtermination T2.

2. A context residing in Media Gateway B that associates terminations T3and T4.

Each context specifies the direction(s) of media flow among its terminations(“who hears/sees whom,” or the topology of the context, in the words of Megaco’sauthors). Media mixing parameters, if necessary, are also part of the context specifi-cation. This may seem trivial for the simple two-way conversation of our example.For a broader perspective, consider an audio/video teleconference in which:

• A small population of “active” participants can speak. All active participantscan see one another.

• A much larger population of “passive” participants can listen but cannotspeak to the other participants.

• Among the passive participants, some have video-capable terminals whereasothers do not.

Megaco’s notion of a context is flexible enough to support a rich variety of con-ferencing scenarios.

10.3.4 Megaco Commands

Most Megaco commands can only be issued by MGCs: the controllers give theinstructions, and the gateways carry them out. The two exceptions are the Notifycommand, which can only be issued by MGs, and the ServiceChange command,which can be issued by either an MG or an MGC. There are eight Megaco com-mands in all; they are listed in Table 10.1.

10.3 Megaco/H.248 125

Area 2

Area 3

Area 1

T5

T4T3T2T1

Media Agateway Media gateway B


Signaling gateway

Bearer path

Context

Termination

Distributed fabric

Figure 10.2 Megaco connection model: Contexts.

The Add, Modify, Subtract, and Notify commands are the “workhorses”;for many call flows, this set of four commands is sufficient. Note the lack ofexplicit commands for creating and destroying contexts. A context is createdwhen the first termination is added and is deleted when the last termination issubtracted.

10.3.5 Example Call Flow

In Figures 10.1 and 10.2, a bearer path is already present. How did it get set up in thefirst place? We display a simplified signaling flow in Figure 10.3.


Table 10.1 Megaco Commands

Command Description

Add Adds a termination to a context.Modify Issued by MGC whenever it wishes to modify the properties, events and/or

signals of a termination.Subtract Removes a termination from its current context; returns statistics on the ter-

mination’s participation in the context.Move Moves a termination to a different context.AuditValue Returns the current state of termination(s). Issued by MGC whenever it

requires information about properties, events, signals and/or statistics of ter-mination(s).

AuditCapabilities Issued by MGC when it wishes to ascertain which termination properties aresupported by an MG.

Notify Issued by the MG whenever it needs to inform the MGC that event(s) haveoccurred (e.g., off-hook for an analog line).

ServiceChange Can be issued by MG or MGC to take termination(s) out of service (orreturn termination(s) to service). This command has other uses; we do notgive a complete list here.

Mediagateway B

Media gatewaycontroller

Mediagateway A

Reply

Subtract; Subtract

...voice packets flow...

Reply

Modify (SendReceive)

Reply

Add; Add (ReceiveOnly)

Reply

Subtract; Subtract

Reply

Add; Add (SendReceive)

Figure 10.3 Simplified Megaco call flow.

Setting Up the Call

Let us suppose that user 1 originates the call. User 1’s serving switch sends an ISUPIAM to the softswitch. (Recall that ISUP is the predominant call-control protocol inSS7 networks. The reader may want to refer to Section 6.5.6’s brief discussion ofISUP.) Receipt of the IAM at the signaling gateway triggers the messaging exchangeof Figure 10.3. (We assume that the signaling gateway, which is not shown in thefigure, has alerted the media gateway controller that a call setup request has arrivedfrom the SS7 domain.)

Let us look at the messages in Figure 10.3 one at a time. The first Add commandimplicitly instructs MG A to create a context and tells MG A to place a specific ISUPtrunk in that context. (That is, the controller will populate the Add command withthe CIC from the incoming IAM.) The second Add command (which is also perchedon the first arrow from the MGC to MG A in the figure) tells MG A to place an RTPtermination in the same context and set its Mode to ReceiveOnly. Other than modeparameters of the Add and Modify commands, we have omitted all commandparameters for simplicity. Typically, the controller would not request a specific (IPaddress, port number) pair, but would instead ask the MG to make the selection; weassume that this is the case here. MG A’s Reply will contain the address and portnumber that it selects.

The controller then conducts a similar signaling interchange with MG B. AnISDN line and an RTP termination are added. (Creation of a context to hold theseterminations is again implicit.) The second Add in this exchange is populated withthe IP address and port number selected by MG A. That is why it is possible to goahead and set the RTP termination’s mode to SendReceive. MG B’s Reply containsthe IP address and port number of the RTP termination that it added; now the con-troller can forward this information to MG A and change that RTP termination’smode to SendReceive. It does so by issuing a Modify command.

Megaco commands are grouped into transactions. In all likelihood, the control-ler would combine the two Add commands to MG A into a single transaction. Thatis why Figure 10.3 only shows one arrow for the two commands. MG A copies thetransaction’s ID into its Reply (so that there will be no confusion if multiple transac-tions are simultaneously in progress). Similarly, the two Adds that are dispatched toMG B would constitute one transaction.

Tearing Down the Call

When the conversation is finished, the controller tells MG A to Subtract both termi-nations from the context that they inhabited throughout the call. The second Sub-tract removes the last termination from the context and therefore implicitly deletesthe context. The Subtracts that are sent to MG B have an entirely analogous effect.

Figure 10.4 reflects the state of the system after the call has been torn down. Thebearer path and the contexts that appeared in Figure 10.2 are gone. Note that theRTP terminations (T2 and T3) are also missing. In the Megaco connection model,terminations in the packet domain are created and destroyed as calls come and go.

TDM terminations (such as T1 and T4) as well as analog line terminations(recall that T5 terminates an analog line) are fundamentally different: they are

10.3 Megaco/H.248 127

created as the result of a provisioning process, and they “live” as long as the configu-rations of the media gateways in question remain the same. Such terminations mustreside somewhere when they are idle; the Megaco connection model defines a specialcontext called the null context expressly for this purpose.

Let us return for a moment to Figure 10.3. Terminations T1 and T4 are shiftedfrom the null context by Add commands and are returned to the null context by Sub-tract commands. Note that Megaco semantics do not allow a move to or from thenull context; the Subtract and Add commands must be used for this purpose. Weassume that termination T5 is “parked” in the null context throughout the call flowof Figure 10.3.

Additional Comments

In Figure 10.3, the gray rectangle labeled “… voice packets flow…” depicts the“lifespan” of a bearer path through the softswitch. In a manner that we nowdescribe, the label on that rectangle may be a bit misleading (but a more accuratelabel would have been a mouthful).

In a real call flow, the Megaco messages of Figure 10.3 would be dovetailedwith:

• ISUP messages going to and from the left-hand side of the diagram.• ISDN call control messages going to and from the right-hand side. (Q.931, the

basic ISDN call-control protocol, is briefly discussed in Section 11.2.1).

The ISUP and ISDN portions of the call setup must be completed before we cansay that a true end-to-end bearer path exists (and it is only at this point in time thatvoice samples begin to flow).

Softswitches tend to be geographically distributed entities (although there is norule saying that the switch components must be in different geographic locations).Note that the latency incurred by the Megaco signaling exchanges depends on thedistances between the media gateways and their controller. If the MGs are far from


Signaling gateway

Area 3

Area 2

Area 1

Termination

T5

T4T1



Distributed fabric Bearer path

Figure 10.4 After teardown: RTP terminations deleted.

the controller, there will be a nontrivial effect on so-called “post dial delay.” This istrue even if the MGs are relatively close to one another, for the simple reason thatthe MGs do not signal one another directly.

10.3.6 Usage of the Move Command

The usefulness of Megaco’s Move command is demonstrated by the followingcall-waiting example. This is a variant of an example presented in the Megacospecification.

As a point of departure for our current example, we refer to Figure 10.2.Suppose that a user at the far end of termination T5 (user 3, say) calls user 2 whilethe user 1-user 2 call is still in progress. Moreover, assume that a call-waiting fea-ture is available to user 2; user 2 chooses to answer the call and place user 1 on hold.

Then the controller will:

• Add termination T5 to a context (implicitly directing that a new contextshould be created in the process);

• Move termination T2 to the new context. Users 2 and 3 can now talk, whereasuser 1 is on hold (the context containing termination T1 still exists, but it tem-porarily contains no other endpoints). The system configuration at this pointis schematically represented in Figure 10.5.

Elevator music (for user 1) is optional. Under the assumption that MG A sup-ports an ElevatorMusic signal (e.g., by supporting a package that defines such athing), the controller could choose to apply that signal by issuing an appropriateModify command to MG A.

We have “grayed out” a bearer path from area 1 to the softswitch to show thatuser 1 is still connected to MG A: the trunk connecting user 1’s serving switch toMG A has not been released. The ElevatorMusic signal, if applied, would reach user1 via this trunk.

When the conversation between users 2 and 3 is over, the controller will:

10.3 Megaco/H.248 129


Signaling gateway

Area 3

Area 2

Area 1

T5

T4T3

T2

T1

Media gateway BMedia gateway A

Bearer path

Context

Termination

Distributed fabric

Figure 10.5 Call waiting example.

• Move termination T2 back to the first context. (And remember to turn off theElevatorMusic signal!)

• Subtract termination T5 from the context that contains it (resulting in the dele-tion of the now-empy context). At this point, we have returned to the configu-ration of Figure 10.2.

Is this example realistic? Here the softswitch is implementing the call waitingfeature; User 2 is not employing a call-waiting feature offered by his/her privatebranch exchange. This example is therefore more realistic if the softswitch hasreplaced user 2’s private branch exchange.

We have omitted many details from our presentation of this example, inwhich our goal was simply to demonstrate the usefulness of Megaco’s Movecommand. Note that signals are covered in Section 10.3.7; we give some examplesin Section 10.3.10.

10.3.7 Descriptors

Megaco protocol entities have to keep track of numerous parameters. Relatedparameters are grouped into descriptors. The Megaco RFC often refers to atomicparameters as properties.

Wherever a set of related parameters is particularly large, a hierarchy of descrip-tors comes into play. The Media descriptor is a case in point. All media streamparameters are specified in Media descriptors, which contain other descriptors. Thehierarchy of media stream properties is as follows:

• Media descriptor:• TerminationState descriptor. This descriptor contains those properties that

are not specific to any one media stream but rather apply to the terminationas a whole. It includes the ServiceStates property (whose allowable valuesare “test,” “out of service,” and “in service”) and the EventBufferControlproperty, which modulates the processing of detected events. (This propertyis applicable when the Events descriptor is nonempty. We cover Eventsdescriptors later in this section.)

• Stream descriptor. This descriptor specifies the properties of a single mediastream. These properties are further categorized as follows:

LocalControl descriptor. Termination properties specific to the stream inquestion reside here. This descriptor includes the Mode property, whoseallowable values are “SendOnly,” “ReceiveOnly,” “SendReceive,” “Inac-tive,” and “Loopback.” (Note that the Megaco RFC is inconsistent in itsnaming of these properties. Sometimes the names are hyphenated, as in“send-only.”)

Local descriptor. This descriptor refers to media received by the MG.When the protocol is encoded in text, SDP is used for this descriptor.

Remote descriptor. This descriptor refers to media transmitted bythe MG. When the protocol is encoded in text, SDP is used for thisdescriptor.


An Events descriptor is essentially a list of events that the MG is commanded todetect and report. For example, an MG may be asked to detect on-hook andoff-hook transitions and fax tones. Typically an MG will send a Notify message toits controller whenever it detects such an event. Each Events descriptor has aRequestIdentifier. When reporting the occurrence of an event, the Notifying MGattaches the appropriate RequestIdentifier to an ObservedEvents descriptor. Addi-tional actions may be appropriate for specific events (e.g., cease to apply ringing orapply dial tone upon detecting off-hook). To efficiently support such behavior, anEvents descriptor can incorporate an embedded Signals descriptor. Events and Sig-nals are defined in packages.

It would be inefficient for an MG to report dialed digits one at a time. That is,when an end user is attempting to place a call, it would be laborious for the MG toNotify its controller of each dialed digit individually. Megaco uses DigitMapdescriptors to specify dialing plans. (In private branch exchange and Centrex envi-ronments, dialing plans typically offer features such as four-digit dialing for internalcalls. Implementation requires some pattern-matching capability on the part of theentity that collects dialed digits. A dialing plan is essentially a specification of thepatterns that need to be matched.)

Via the DigitMap mechanism, controllers can export dialing plans to MGs. AnMG that has received such information can perform pattern matching locally andcan notify its controller only when a string of dialed digits is complete. DigitMapsare particularly useful in deployments where Media Gateways replace privatebranch exchange or Centrex equipment.

Flow directions between terminations in a context are specified via a Topologydescriptor. The Megaco RFC explicitly says that it is not mandatory for MGs tosupport Topology descriptors. A Topology descriptor consists of one or more tri-ples of the form

(T1, T2, <association>)

where T1 and T2 are terminations (or possibly wildcards) and <association>

is one of “isolate,” “oneway,” or “bothway.” (Wildcards are introduced inSection 10.3.8.) In the case of a oneway association, the direction of media flow isT1 → T2. The default is bothway. More specifically, if no Topology descriptor isgiven, then a full mesh of bothway connections among the terminations in thecontext is assumed.

Revisiting the Distinction Between Terminations and Contexts

Contexts describe what goes on inside an MG. Terminations, being an MG’s “touchpoints” to the rest of the network, describe what goes on outside. When trying tosort out the difference between the LocalControl and Topology descriptors, it helpsto keep this distinction in mind.

The Topology descriptor determines the flow of media between terminations inthe same media gateway. The mode property in the LocalControl descriptor deter-mines the flow of media between terminations in different media gateways.

Media, Events, ObservedEvents, Signals, and DigitMap descriptors belong toterminations. Topology descriptors belong to contexts.

10.3 Megaco/H.248 131

10.3.8 Sample Megaco Messages

Armed with a basic knowledge of Megaco descriptors, we are now ready to examinea few Megaco messages in detail. The Megaco RFC specifies text and binaryencodings of the protocol. For both UDP and TCP, the default port number fortext-encoded operation is 2944 and the default port number for binary-encodedoperation is 2945. In our examples, we will employ the text encoding for readability.In many instances, a controller will not know what identifiers to assign when itissues a command (e.g., port numbers for RTP streams). The controller will ask theMG to select values for these identifiers, and to populate its reply with those values.The so-called CHOOSE wildcard is used for this purpose. In our examples, theCHOOSE wildcard is denoted “$”; this is consistent with the examples presented inthe Megaco RFP itself. We remark here that there is also an ALL wildcard, althoughwe will not need it in our examples.

Recall that Megaco uses SDP for the Local and Remote descriptors. For mes-sages traveling controller → media gateway, Local/Remote descriptors are actuallycast in a slightly modified version of SDP. The following departures from the SDPspecification [4] are allowed:

• The “s=”, “t=” and/or “o=” fields may be omitted.• In place of a single parameter value:

• The “$” wildcard may appear.• Alternatives may be specified.

Note that Local/Remote descriptors in messages traveling MG → Controllermust adhere to the SDP specification.

We review the call setup procedure of Figure 10.3. The controller initiates atransaction commanding MG A to add a TDM termination and an RTP terminationto a context. MG A’s reply contains the IP address and port number of the lattertermination.

The controller initiates a transaction commanding MG B to Add a TDM termi-nation and an RTP termination to a context. In its reply, MG B populates the IPaddress and port number of the RTP termination; the controller then communicatesthis information to MG A via a Modify command.

The messages below detail the second transaction and reply (that is, the transac-tion between the controller and MG B; in the interest of brevity, we do not displaythe messages constituting either of the transactions between the controller and MGA). In this example, the participants’ IP addresses are as follows:

• Controller: 192.168.0.51;• MG A: 192.168.0.30;• MG B: 192.168.0.50.

The default port number for text-encoded Megaco is 2944. We assume that theMegaco protocol entities on all three network elements are listening at this portnumber. Although each of the participating network elements has one and only oneaddress in this example, the reader should not assume that this is universally true. In


practice, it is common for MGs to have multiple IP interfaces (each having a differ-ent IP address). In particular, bearer terminations might very well reside at differentIP addresses than Megaco protocol entities. The following transaction request trav-els controller → MG B.

MEGACO/1 [192.168.0.51]:2944 Transaction = 122603 {Context = $ {Add = BT0001,Add = ${Media{Stream = 1{LocalControl Mode = SendReceive},Local v=0 c=IN IP4 $ m=audio $ RTP/AVP 18 a=ptime:20},Remote v=0 c=IN IP4 192.168.0.30 m=audio 2222 RTP/AVP 18a=ptime:20}}

}}

}}

Notes on the Add transaction. The first line contains the IP address and portnumber of the originator (in this case, the controller). The controller is asking MG Bto create a new context and furnish a contextID; this is the first of several uses of $,the CHOOSE wildcard. In the first Add, the controller requests a specific TDMchannel. The Megaco RFC does not specify terminationID semantics; the name“BT001” is totally arbitrary.

The second Add requests an RTP termination (note that RTP/AVP appears in itsLocal and Remote descriptors). This Add features the $ wildcard in three places: forthe terminationID (immediately after the word “Add”) and for the IP address andport number of the RTP termination (in the Local descriptor). We will return to theLocal descriptor in a moment. Although the mode setting is the only content of theLocalControl descriptor in this example, other properties can be specified there(e.g., jitter requirements).

Recall that the Local descriptor refers to media received by the MG, whereas theRemote descriptor refers to media transmitted by the MG. In the Local descriptor,the controller is asking MG B to specify the IP address and port number where itwishes to receive RTP packets. As noted earlier, RTP traffic may arrive at differentIP interface(s) than Megaco messages. So the presence of an IP address field here isnot redundant. (Note that, if the destination IP addresses for RTP and Megaco traf-fic are the same, the port numbers must be different.)

The Remote descriptor specifies the IP address (192.168.0.30) and port number(2222) for RTP traffic emanating from this context on MG B. Note that the IPaddress is that of MG A, and that the port number is not the same as that of theMegaco protocol entity.

We are assuming in this example that the TDM termination BT0001 has beenprovisioned in SendReceive mode.

The following Reply travels MG B → controller.

10.3 Megaco/H.248 133

MEGACO/1 [192.168.0.50]:2944 Reply = 122603{Context = 5050{Add = BT0001,Add = BR0720{Media{Stream = 1{Local v=0 o=- 2890844526 2890842807 IN IP4192.168.0.50 s=- t= 0 0 c=IN IP4 192.168.0.50 m=audio 4444RTP/AVP 18 a=ptime:20}

}}

}}

}

Notes on the Reply transaction. The first line contains the IP address and portnumber of the originating protocol entity. The controller knows that this message isin fact a response to the transaction that appears above because the TransactionIDsmatch.

We see that MG B has filled in all of the wildcards: namely, the ContextID(5050) for the newly created context, as well as the TerminationID (BR0720), IPaddress (192.168.0.50), and port number (4444) for the newly created RTP termi-nation. We remark that MG B has also added “o=”, “s=” and “t=” fields to theLocal descriptor. (These fields are missing from the Local and Remote descriptors inthe earlier Add transaction. As noted earlier, controllers are allowed to bend the SDPsyntax rules, but media gateways are not.)

MG B has omitted the LocalControl and Remote descriptors from its reply.Since the controller did not ask MG B to populate any fields in those descriptors, itwould be redundant to include them.

10.3.9 Three Way-Calling Example

In this section, we present a simple conferencing scenario: suppose that a subscriberin area 3 (user 3, say) has been added to the conversation of our previous example.User 3 accesses the network through an analog line that is terminated by thesoftswitch. That analog line termination is labeled T5 in Figure 10.6 (as well asFigure 10.2).

As suggested by Figure 10.6, Megaco’s connection model handles the three-wayconnection in a simple way: termination T5 is added to the context that alreadycontained terminations T1 and T2.

Let us assume that a two-way conversation (between user 1 in area 1 and user 2in area 2) is in progress; suppose that the participants want to add user 3 to the call.The signaling flow shown in Figure 10.7 accomplishes this goal. We detail the Add,Notify and Modify messages depicted in the figure. The replies do not add content,so we have chosen to omit them. (Note that we circumvent the matter of how cur-rent participant(s) tell the softswitch that they want to add a third participant. Thisis beyond our scope; here we are only interested in the Megaco portion of thecall flow.)

The Add transaction (which travels Controller → MG A) looks like this:


MEGACO/1 [192.168.0.51]:2944 Transaction = 155851{Context = 5643{Add = AA0049{Media{Stream = 1 {LocalControl {Mode = SendReceive}}} ,

Events=4211{a1/of(strict=state)},Signals al/ri}

}}

Note the presence of Events and Signals descriptors for the analog line. Inthose descriptors, “al” refers to the analog line package, “of” denotes off-hook,and “ri” denotes ringing. Thus the controller is telling MG A to ring user 3’sphone and to report off-hook when and if this transition occurs. Since the newly-added termination connects to an analog line, Local and Remote descriptors areunnecessary.

10.3 Megaco/H.248 135

Area 2

Area 3

Area 1

T3T2T1



Signaling gateway

T5

T4

Bearer path

Context

Termination

Distributed fabric

Figure 10.6 Simple conference call example.

...two-way conversation...

Mediacontroller

gateway MediaBgateway

Mediagateway A

Modify/Reply

Notify/Reply

Add/Reply

...three-way conversation...

Figure 10.7 Signaling for three-way call.

When user 3 answers, we have the Notify transaction traveling MG A →controller:

MEGACO/1 [192.168.0.30]:2944 Transaction = 158053{Context = 5643{Notify = AA0049{ObservedEvents = 4211 {20031231T22020002:al/of(init=false)}}

}}

The ContextID, TerminationID and EventsId in the Notify transaction matchthose in the Add transaction that went before. Lastly, we have the Modify transac-tion traveling controller → MG A:

MEGACO/1 [192.168.0.51]:2944 Transaction = 155854{Context = 5643{Modify = AA0049{Events=4212al/on(strict=state),Signals{}}

}}

Here the controller has asked MG A to turn off ringing (as indicated by the nullSignals descriptor) and to detect and report on-hook. Note that the EventsID is dif-ferent than that of the earlier Add transaction; the new Events descriptor replacesthe old Events descriptor for termination AA0049.

In this example, users 1 and 2 do not hear ringing while waiting for user 3 toanswer. For this to happen, we would merely have to apply ringback signals to theappropriate terminations (by modifying them in the course of the first transaction,say). Note that we would need to remove the ringback signals later (as part of thelast transaction).

We assume that users 1, 2, and 3 can all hear one another once the ModifyTransaction above is processed and accepted. Recall that connections have toplo-gies; also that the default topology is a full mesh of bothway connections amongthe terminations in a connection. That is why no Topology descriptor appears ineither of the messages above: none is necessary, since the intended behavior is thedefault.

10.3.10 Megaco Miscellanea

Other Descriptors

We have only covered a handful of the descriptors defined in the Megaco RFC. Herewe briefly mention a few more. The specification defines descriptors for specialtypes of bearer traffic (Modem and Multiplex descriptors). Moreover, we have notcovered error reporting and handling (which involves Error descriptors) or perform-ance and resource usage reporting (which involves Statistics descriptors). Weremark that performance and resource usage reporting is crucial—since controllersdo not encounter bearer traffic directly, they have no other way of knowing whathappens in the bearer plane.


Packages

The Megaco RFC defines some 13 packages. Here are a few highlights (for details,the reader can consult the specification [6] directly): the base root package definesgateway-wide properties, such as the maximum number of terminations per con-text. In Section 10.3.9, we saw an example use of the analog line supervision pack-age. Ringback and dial tone reside in the call progress tones generator package.Echo cancellation can be turned on or off by setting the echo cancellation propertyin the TDM circuit package.

Other packages are defined within ITU-T’s H.248 series of recommendations:fax, text conversation, call discrimination, and other functionalities in [7], userinterface elements and actions in [8], dynamic tones in [9], and announcements in[10]. Packages that assist with switch management include [11–13].

A package is defined by specifying its properties, events, signals, statistics, andprocedures. We remind the reader that, in the interest of extensibility, Megaco’sauthors left the door open for new packages to be defined as needed.

Transport

The “base” Megaco specification covers IP transport of Megaco messages via UDPand TCP. Transport over SCTP and ATM are defined in [14] and [15], respectively.

Revisiting the Call-Waiting Example

We review the following circumstances in the call-waiting example of Section10.3.6. User 2 has a call-waiting service that is administered by a softswitch. Users 1and 2 are in the midst of a conversation when another user attempts to call user 2.User 2 is alerted of the second incoming call by a call-waiting tone.

That tone, which is defined in the call progress tones generator package, isapplied (to user 2’s termination) as a result of a Modify command with an appropri-ate Signals descriptor.

10.4 MGCP

MGCP is defined in RFC 3435 [2]. As noted in Section 10.3, Megaco is the standardsupported by IETF and ITU-T. MGCP is not on the “standards track”: RFC 3435 isan informational RFC. However, MGCP is widely deployed.

Unlike Megaco, MGCP is purely a text-based protocol (recall that Megacooffers binary and text-encoding options).

10.4.1 Example Call Flow

In this section, we recast the call flow of Section 10.3.5 in MGCP terms. In so doing,we introduce some MGCP terminology as a “mapping” of the following Megacoterms. Even though the two protocols aim to solve the same problems, Megaco andMGCP use different vocabularies. Therefore the mappings are loose and should notbe taken as precise equivalances.

10.4 MGCP 137

• Megaco media gateway controller → MGCP call agent.• Megaco context → MGCP connection.• Megaco termination → MGCP endpoint.• Megaco Add command → MGCP CreateConnection command, or “verb.”

The latter is abbreviated CRCX.• Megaco Modify command → MGCP ModifyConnection command. The

abbreviation for this MGCP verb is MDCX.• Megaco Delete command → MGCP DeleteConnection command. The abbre-

viation for this MGCP verb is DLCX.• Megaco mode property → MGCP ConnectionMode parameter. The abbrevia-

tion for this MGCP parameter is “m:”.

With this mapping in mind, we see that Figure 10.8 is entirely analogous to ourearlier call flow (see the Megaco call flow presented in Figure 10.3).

We have seen that, in both the Megaco and MGCP signaling flows, the first con-nection/context must be modified—that is, converted to a bidirectional connectiononce the far end’s session parameters are available. The same capability can be usedto effect mid-call modifications.

10.4.2 Brief Comparison with Megaco

In this section, we discuss conceptual similarities and differences between Megacoand MGCP. The levels of difficulty for implementing the two protocols are beyondthe scope of our discussion.

The differences between MGCP and Megaco start with the differences in theirconnection models. The fundamental notions in the MGCP model are endpoint(which is similar to a Megaco termination) and connection (which is similar to aMegaco context).

MGCP views digital channels (e.g., TDM trunks and ISDN lines) and analoglines as endpoints. In Figure 10.9, endpoint E1 terminates a TDM trunk, endpointE4 terminates an ISDN line, and endpoint E5 terminates an analog line. This is


Call agent Mediagateway B

Mediagateway A

250 OK250 OK

DLCXDLCX


200 OK

200 OK

MDCX (m: sendrecv)

200 OK

CRCX (m: recvonly)

CRCX (m: sendrecv)

Figure 10.8 Simple MGCP signaling flow.

analogous to the Megaco example of Figure 10.2. A few other entities (such asannouncement server and interactive voice response access points) are also catego-rized as endpoints.

So far, the “mapping” of Megaco terminations to MGCP endpoints seems to begoing well. But the correspondence only holds to a limited degree: in Figure 10.9,note that there are no endpoints facing the switch fabric.

In fact, there is no such thing as an RTP endpoint in the MGCP model. The ses-sion description parameters (that is, IP addresses and port numbers for RTPstreams, codec specification, and so on) belong to connections on the media gate-ways. (By way of review: in Megaco, we do have RTP terminations, which are inturn contained in contexts.)

The analogy between MGCP connections and Megaco contexts is a little morerobust—an MGCP connection describes the binding between ingress and egresspoints on a media gateway. Two connections appear in Figure 10.9—one for eachmedia gateway that the bearer path traverses. (The choice of the term connectionhere is perhaps unfortunate, since it might lead to confusion with the notion of anend to end connection. In MGCP, connections are grouped together in calls.Although each call has a unique CallID, this parameter is vestigial; the MGCP RFCsays that the CallID has “little semantic meaning in the protocol,” although it maybe useful for accounting purposes.)

MGCP defines virtual endpoints; the examples cited in the MGCP RFC are digi-tal signal processing resources that belong to announcement servers, interactivevoice response devices, or conference bridge devices.

Conferences

To set up a conference call with MGCP, multiple connections to a single endpointare established. There are two apparent approaches, which are distinguishedaccording to whether that endpoint is a conference bridge endpoint:

• Case I: Endpoint is not a conference bridge endpoint. The specification saysthat some types of endpoints (notably TDM channels and analog lines) should

10.4 MGCP 139

Area 3

Area 2

Area 1

E5

E1 E4

Media gateway BMedia gateway A

Call agent

Signaling gateway

Bearer path

Connection

Endpoint

Distributed fabric

Figure 10.9 MGCP connection model.

support the establishment of multiple simultaneous connections. Referring toFigure 10.9, the media gateway should be able to establish a three-way call byconnecting terminations E5 and E1. This capability would support an ad hocconference like that of the Megaco scenario presented in Section 10.3.9. Theproblem is that, if the user at the far end of E1 hangs up, the other participantson the call are also disconnected.

• Case II: Endpoint is a conference bridge endpoint. In this case, individual par-ticipants can presumably come and go at will without causing the other par-ticipants to disconnect. So this appears more robust than the other approach.This approach requires participant(s) to anticipate the need for conferencebridge resources, however, so ad hoc conferences present a problem.

Regardless of the approach that is chosen, MGCP does allow a degree of controlover “who hears/sees whom”: one of the allowable values for the ConnectionModeparameter is “conference.” The MGCP specification [2] says that a media streamreceived through a connection in this mode is forwarded to:

• The endpoint associated with the connection;• All other conference-mode connections.

Still and all, MGCP’s approach to conference calls is not conceptually as clean asthat of Megaco. MGCP’s connection concept is not as general as Megaco’s notion ofa context. Moreover, in the MGCP connection model, there is nothing as flexible asMegaco’s Topology descriptor. (Recall that the Topology descriptor determines“who hears/sees whom.”)

10.4.3 Other MGCP Verbs

Event notification. The Megaco Notify command maps to an MGCP verb of thesame name. As with Megaco, this is the means by which a media gateway reports theoccurrence of events (e.g., off-hook and on-hook transitions for analog lines). AnMGCP call agent uses the NotificationRequest verb to specify those events that theMedia Gateway should report. Recall that Megaco’s approach is slightly different:rather than using a separate command for this purpose, controllers incorporateEvents descriptors in Add and/or Modify commands.

The MGCP EndpointConfiguration verb is used to specify the bearer encodingscheme for a TDM endpoint. The values “A-law” and “mu-law,” which distinguishbetween the two common variants of G.711, are the only ones defined in the MGCPRFC. In our view, this is a shortcoming; Megaco’s approach is more sensible.Megaco uses Local and Remote descriptors (whose lingua franca is SDP) withinModify commands for this purpose.

The MGCP AuditEndpoint and AuditConnection verbs allow call agents toquery status of terminations and connections. The functionality of the AuditTermi-nation command is quite similar to that of Megaco’s AuditValue command. Audit-Connection has no direct Megaco counterpart. Note, however, that many of theproperties of an MGCP connection (e.g., RTP stream parameters) correspond toproperties of a Megaco termination.


MGCP’s RestartInProgress command, which is similar to Megaco’s Serv-iceChange command, can be used to take endpoints in and out of service.

The Lack of a Move Command

As we saw in the call-waiting example of Section 10.3.6, Megaco’s Move commandis a nice convenience. There is no MGCP equivalent (a MoveConnection verb wasproposed but later abandoned).

Call waiting and other similar features are, of course, possible with MGCP.MGCP signaling to implement such features is somewhat more laborious than withMegaco, however. We regard this as a drawback of MGCP.

10.4.4 Transactions and Provisional Responses

Each MGCP message is either a command, a response, or a response acknowledg-ment. Responses and response acknowledgments have 3-digit return codes, whichcan be categorized as follows:

• 0xx: response acknowledgment;• 1xx: provisional response;• 2xx: final response indicating successful completion;• 4xx, 5xx: final response indicating error condition;• 8xx: package-specific response.

Response acknowledgments are only generated for final responses.Each MGCP command includes one (and only one) verb and a transactionID.

TransactionIDs are used to correlate commands with responses and responseacknowledgments (which also include transaction-IDs). According to the specifica-tion, MGCP is transported over UDP, which does nothing to ensure reliability. Thusa call agent or media gateway may not be able to tell whether a message sent wasreceived. Therefore it is important to recognize and discard duplicates; transac-tion-IDs are essential for this purpose. The “three-way handshake” that is present inthe pattern

<command, final response, response acknowledgment>

is also intended to compensate for the shortcomings of unreliable transport.Provisional responses are useful in situations where commands cannot be exe-

cuted quickly (e.g., when a media gateway’s processing capability is congested dueto a “burst” of call setup requests). Provisional responses can be used to keep timers(e.g., retransmission timers in protocol state machines) from expiring when it isappropriate to do so. The Megaco RFP briefly mentions the need for provisionalresponses, but MGCP does a substantially better job in this area.

We have seen that Megaco supports the incorporation of multiple commandsinto a single transaction. This is an advantage over MGCP, which cannot groupmultiple verbs within the same transaction. However, MGCP does provide for mul-tiple transactions and/or responses to be encapsulated in a single UDP/IP packet:

10.4 MGCP 141

successive messages inhabiting the same packet must be separated by a line consist-ing entirely of a single “.”.

10.4.5 MGCP Packages

RFC 3435 (the “base” MGCP RFC) does not define any packages—this aspect isrelegated to other documents. At the time of this writing, packages that define thefollowing MGCP functionalities exist: channel-associated signaling [16], ATMbearers [17], and Bulk Auditing [18]. Note that RFC 3435 is not a “stand-alone”document, since some of its basic functionality is specified as a package (seereference [19]).

One of the precursors of MGCP was IP Device Control Protocol. This ispresumably the reason that ATM bearers were “tacked on” via a package defini-tion RFC.

10.5 Interworking with Circuit-Switched Networks

The softswitch architecture was motivated by the need to interwork with cir-cuit-switched domains. Physical separation of bearer and control, while not man-dated in the softswitch realm, is clearly a key benefit in many deployment scenarios(think of the backhaul example we explored in earlier chapters).

Although softswitch is arguably the main topic of this book, it is not the onlyuseful approach to packet telephony. We elaborate on this point in later chapters. Inalternative architectures, logical separation of bearer and control remains an impor-tant concept.

10.5.1 Latency Trade-offs

Let us envision a simple call flow in which the called party accesses a softswitch viaan analog line. When does the softswitch apply ringing to that analog line?

Certainly the media gateway controller will attempt to set up a bearer paththrough the softswitch fabric as soon as it realizes the need to do so. That processtakes time to complete, however. The latency involved may be substantial if thesoftswitch is experiencing a high rate of call setup requests. The distance of themedia gateways from their controller, if large, may also be a nontrivial contributingfactor.

Should the controller apply ringing to the analog line immediately, on theassumption that the cross-fabric bearer setup will, in all probability, complete suc-cessfully? The motivation for doing so is that the cross fabric setup can proceedwhile the switch waits for the end user to answer, thereby reducing overall latency.The downside is also clear: if the called party answers immediately, he/she may notinitially be able to hear the caller’s voice (and vice versa). Worse yet, if the cross-fab-ric setup fails, we will have disturbed the called party unnecessarily.

Different implementations may opt for different approaches to this problem.Had we chosen to incorporate end-to-end message flows in our Megaco/MGCPexamples, we would have encountered similar problems. That is, ISUP and ISDN


messaging would be interleaved with Megaco/MGCP messaging. Exactly howwould the interleaved flows be ordered? The choices would again involve latencytrade-offs. The standards do not address these issues; in selecting a preferredapproach, each implementor must evaluate his or her priorities.

10.6 Inhabiting the Bearer, Service, and Control Planes

Try as we might, it is impossible to achieve perfect separation of the bearer planefrom the service and control planes. The need to handle events and signals is akey exemplar. This fact accounts for some of the complexity of media gatewaycontrol. To reinforce this point, which is an important theme of this chapter, werevisit DTMF:

• DTMF tones are ubiquitious in telephony—they are used to navigate menusin a variety of applications (e.g., voice mail and banking systems) and to enterdata (e.g., personal ID numbers for authentication of credit card calls).Softswitches will be expected to support services like those available intoday’s PSTN.

• By definition, DTMF tones and other voiceband bearer signals do not passthrough media gateway controllers. So controllers must rely on media gate-ways for notification of DTMF activity.

10.7 Signaling Between Two Softswitches

For the sake of simplicity, we have so far assumed that the calling and called partiesare served by the same softswitch. Clearly this cannot always be true. When asoftswitch is connected to other switches via the TDM domain, ISUP and/or ISDNsignaling can be used. This is true regardless of whether the other switches aresoftswitches or circuit switches.

If we wish to interconnect two softswitches in the packet domain, however,ISUP and ISDN no longer suffice. We discuss two protocols suited to this purpose:Bearer Independent Call Control (BICC) and Session Initiation Protocol. Theformer is covered briefly in the next section; the latter is covered at length in subse-quent chapters.

10.7.1 BICC

BICC is based on ISUP, which was introduced in Section 6.5.6. Thus it is a telcostyle approach to call control; it basically extends ISUP to handle packet bearers andmultiple codecs. BICC is a relatively modest extension of ISUP. The idea is to repli-cate the features of today’s circuit-switched networks in the realm of packet teleph-ony, thereby enabling softswitches to support the types of services offered now.

The initial BICC specification, which was set forth in [20], was followed by theCapability Set 2 (CS2) specification. ITU-T’s Q.1902.x series of recommendationsdefines BICC CS2; the functional description appears in [21].

10.6 Inhabiting the Bearer, Service, and Control Planes 143

The ISUP specification stretches across multiple documents (ITU-T’s Q.76xseries of recommendations). The BICC specification basically amounts to a set of“delta documents.” That is, the ITU-T recommendations that cover BICC are writ-ten as a set of exceptions to the corresponding ISUP recommendations. Althoughthis arrangement makes for very tough reading, it does make some sense: BICC canbe transported over any protocol stack that supports ISUP (and the array of SS7transport options has widened considerably in recent years).

BICC’s initial capability set supported ATM bearers. IP bearers were coveredlater (see [22]; not surprisingly, that recommendation endorses SDP for IP bearers).So BICC’s order of development reversed that of MGCP and Megaco.

References

[1] Recommendation H.248.1, Media Gateway Control Protocol Version 2, ITU-T, 2002[2] Andreasen, F., and B. Foster, RFC 3435, Media Gateway Control Protocol (MGCP) Ver-

sion 1.0, IETF, January 2003.[3] Greene, N., M. Ramalh, and B. Rosen, RFC 2805, Media Gateway Control Protocol Archi-

tecture and Requirements, IETF, April 2000.[4] Handey, M., and V. Jacobson, RFC 2327, SDP: Session Description Protocol, IETF, April

1998.[5] Schulzrinne, H., and S. Casner, RFC 3551, RTP Profile for Audio and Video Conferences

With Minimal Control, IETF, July 2003.[6] Groves, C., et al., RFC 3525, Gateway Control Protocol Version 1, IETF, June 2003.[7] Recommendation H.248.2, Facsimile, Text Conversation, and Call Discrimination Pack-

ages, ITU-T, 2000.[8] Recommendation H.248.3, User Interface Elements and Actions Package, ITU-T, 2000.[9] Recommendation H.248.6, Dynamic Tone Definition Package, ITU-T, 2000.

[10] Recommendation H.248.7, Generic Announcement Package, ITU-T, 2000.[11] Recommendation H.248.8, Error Codes and Service Change Reason Description, ITU-T,

2000.[12] Recommendation H.248.10, Congestion Handling Package, ITU-T, 2001.[13] Recommendation H.248.11, Media Gateway Overload Control Package, ITU-T, 2002.[14] Recommendation H.248.4, Transport over SCTP, ITU-T, 2000.[15] Recommendation H.248.5, Transport over ATM, ITU-T, 2000.[16] Foster, B., RFC 3064, MGCP CAS Packages, IETF, February 2001.[17] Kumar, R., RFC 3441, Asynchronous Transfer Mode (ATM) Package for the Media Gate-

way Protocol (MGCP), IETF January 2003[18] Foster. B., D. Auerbach, and F. Andreason, RFC 3624, The Media Gateway Control Proto-

col (MGCP) Bulk Audit Package, IETF, November 2003.[19] Foster, B., and F. Adreasen, RFC 3660, Basic Media Gateway Control Protocol (MGCP)

Packages, IETF, December 2003.[20] Recommendation Q.1901, Bearer Independent Call Control Protocol, ITU-T, June 200.[21] Recommendation Q.1902.1, Bearer Independent Call Control Protocol (CS2) Functional

Description, ITU-T, July 2001.[22] Recommendation Q.1970, Bearer Independent Call Control IP Bearer Control Protocol,

ITU-T, July 2001.


C H A P T E R 1 1

Session Control

In this chapter, we discuss various approaches to session control. We will sometimesuse the word session, in preference to call, to connote something more general thana typical bidirectional telephone conversation. Thus a session might be any numberof things, such as a videoconference or a half-duplex voice “conversation” (seeSection 13.7.1). The conferencing theme has many variants (e.g., a conference inwhich some participants transmit and receive voice and video while others partici-pate only via voice, or a conference in which some participants transmit and receivemedia streams while others can only receive). We have seen that the Megaco andMGCP protocol designs incorporate some flexibility along these lines (as evidenced,for example, by Megaco’s Topology descriptor). We will see in this chapter thatmedia gateway control (in the form of Megaco or MGCP) is not “the only game intown” when it comes to flexible session control.

11.1 “Generic” Session Control

Protocol details vary from one session control scheme to another. Later in this chap-ter, we will encounter some differences in basic functionality. As a starting point,however, we will concentrate on the similarities between session control protocols.There is a substantial amount of common functionality due to the fact that variousprotocols are aimed at solving the same or similar problems. Figure 11.1 presents asignaling flow; we have intentionally avoided casting this flow in terms of any spe-cific protocol, using generic names for the messages instead. The flow in the figure issimplified; in particular, no signaling or switching intermediaries are shown and noaddress resolution is depicted.

It is useful to think of the calling and called parties as end users’ terminal equip-ment (or, more precisely, as processes running therein) rather than the end usersthemselves. The steps in our generic signaling flow are as follows: after (1) the call-ing party issues some sort of session setup request, (2) the called party sends a mes-sage acknowledging the request and indicating that it has begun processing for thisrequest. Once its processing is complete, (3) the called party confirms its availabilityand willingness to participate in a session.

It is not a given that the calling and called parties support the same codecs (orhave the same preferences). So (4) the parties enter into a dialog to compare capa-bilities and preferences. Once an agreement has been reached, (5) bearer channel(s)are established. At this point, the interactive session between end users can begin.

145

Note that steps (4) and (5) are shown with bidirectional arrows: at least in principle,either endpoint could initiate the interchange.

The session ends when (6) one endpoint announces its intention to withdrawfrom the session and (7) the other endpoint acknowledges. Of course, we couldreverse the arrows for steps (6) and (7); the main thing is that the two point in oppos-ing directions.

Why are there so many steps, even in a simplified flow? The session’s bandwidthrequirements may not be known until (4) negotiate terminal capabilities is complete.So, at least in networks with explicit bandwidth reservation and connection admis-sion control, step (4) is a prerequisite for (5) establish bearer. Moreover, it does notmake sense to perform step (4) until we know that the called party is available andwilling. Thus (3) session setup confirmation is a prerequisite to step (4).

If calling and called parties are Voice over IP entities on the same LAN, steps (2)and (3) of the signaling flow may occur very close together in time. If interworkingbetween domains is necessary, or even if requests must be authenticated andapproved by a controller (not shown in the figure), then the delay between steps (2)and (3) may well be nontrivial. In this case, step (2) allows the calling party’s proto-col state machine to set its internal timers appropriately1.

Some protocols piggyback the codec negotiation of step (4) on other messages inthe call flow. The primary reason for this is to speed things up. In this case, a sepa-rate step (5) may also be unnecessary. We chose to show the codec negotiation as aseparate step to emphasize that this function has no counterpart in traditional telcosignaling (read Section 11.1.1 for more on this point).

146 Session Control

1. This state machine may have one timer for the gap between its dispatch of the message in step (1) and receiptof the acknowledgment in step (2); if the timer expires, the state machine might reissue the setup request onthe assumption that the original request was lost. Once step (2) has completed, a second timer may governthe state machine’s willingness to wait for step (3); this timer may be set to a higher value than the first timer.

...voice and/or video packets flow...

(7) Acknowledge end of session

(6) End participation in session

(5) Establish bearer

(4) Negotiate terminal capabilities

(3) Session setup confirmation

(2) “I’m working on it”

(1) Session setup request

CalleeCaller

Figure 11.1 Generic signaling flow for session control.

11.1.1 Comparison with ISUP Call Flow

It is worthwhile to compare the signaling flow of the previous section with a basicISUP call flow (see Figure 6.8). The initial session setup request [step (1) in thegeneric signaling flow of Figure 11.1] takes the form of an ISUP IAM. Step (2)“maps” to an ACM. No codec negotiations need to take place, so step (4) has noISUP counterpart. Moreover, steps (3) and (5) coincide. Together, they correspondroughly to an ISUP ANM. Steps (6) and (7) correspond, respectively, to ISUP RELand RLC messages.

The most important distinction between an ISUP call flow and that of Figure11.1 is this: the participants in the ISUP call flow are switches, whereas the partici-pants in the latter are the end users’ terminals. Telephone sets have traditionallypossessed very little intelligence. In the typical legacy deployment, this means thatessentially all of the intelligence (and, perhaps more importantly, the vast majorityof control capabilities) resides in the network.

11.1.2 Modularity in Protocol Design

Just as large-scale software projects are modular, protocol design should be modu-lar. We discussed this concept when we introduced protocol stacks in Chapter 6; agiven module (or layer) relies on the services of the layer below it and provides serv-ices to the layer above it.

In the current context of control and service planes, numerous capabilities arerequired. Modularity is still important: it is expedient to subdivide the necessaryfunctionality into a variety of protocol specifications, even when the protocolsreside in different planes. We need a way for media gateways to talk to their control-lers (the subject of Chapter 10), for end systems to talk to each other and to variousnetwork elements, and so on.

Of course, a significant degree of modularity is already present in the legacycase: ISUP call-control signaling is specified separately from the G.711 codec, forexample. There was an underlying assumption that the two protocols would gotogether, however, embodied in the fact that the switching infrastructure works in64 kbit/s “quanta.” This was entirely reasonable, considering that ISUP had verylimited “competition” and G.711 had essentially none at all. (For completeness, wenote that Telephone User Part preceded ISUP and is still used in some parts of theworld.)

These days, there is an additional question of how constituent protocols shouldfit together in a full-featured network deployment. The pundits keep saying that thecurrent era is one of fundamental change. For the most part, we are inclined toagree, although we fully expect such change to be painfully slow. What is beyonddebate is this: there are many people who think they understand the best way toaffect fundamental change and are driving a variety of standards bodies to formu-late new protocols at a dizzying rate. Many good ideas are being promulgated in thestandards bodies; there is also quite a bit of one-upsmanship.

In the current era of protocol proliferation, modular protocol design is all themore important. Suppose, for example, that we have settled on a particular mediagateway control protocol and now need to select a protocol for media gateway con-trollers to talk to each other. It would be nice if, after making the first selection, we

11.1 “Generic” Session Control 147

still had complete freedom in making the second selection. Ideally, a “clean” designprocess would yield this sort of independence, or at least minimize (and clearly docu-ment) any dependencies. A second goal is to interoperate gracefully with existingprotocols. (Similarity with existing protocols, especially those that enjoy largeembedded bases, eases the learning curve for humans and arguably eases the soft-ware implementation process.) Unfortunately, the second goal usually competeswith rather than complements the first goal.

There are multiple approaches to the question, “What is the best mix of proto-cols?” for a given network deployment. For example, an explicit “umbrella” stan-dard could specify a collection of protocols that interwork to form a coherent whole.At the other end of the spectrum, protocol combinations could be addressed byflexible recommendations or left entirely to the discretion of operators and/or equip-ment vendors. Note that, in either case, agreement on the scope of each candidateprotocol is very important. Otherwise, it would be difficult to avoid overlap in func-tionality while assuring that a given collection of protocols is adequate for the taskat hand.

11.2 The H.323 Protocol Suite

H.323 [1], which was developed by the ITU-T, is an “umbrella” specification of thesort just mentioned. H.323 “intersects” the bearer plane as well as the control plane.In particular, this standard covers codecs; support for G.711 voice is mandatory,whereas support for video is optional. Any H.323 terminal that does have videocapabilities must, at a minimum, support the Quarter Common Interchange Format(QCIF) format specified in [2]. The standard lists other recommended audio andvideo codecs.

Another interesting thing about H.323 is that it incorporates ITU-T standards(e.g., the standards mentioned in the previous paragraph) as well as IETF specifica-tions. In the bearer plane, for example, encoded audio and/or video streams aretransported as RTP payloads. We have RTP (along with RTCP) running overUDP/IP.

H.323 Terminology

In the H.323 lexicon, the end user’s communication device is called a terminal.Wherever an H.323 network is connected to a legacy circuit-switched network, agateway takes care of the necessary interworking (in the bearer plane as well as thecontrol plane). A gatekeeper controls other network elements such as terminals,gateways and multipoint controllers, which in turn exert control over multipartyconferences. Gateways, gatekeepers, and multipoint controllers are not mandatory—it is possible to implement the scenario of Figure 11.1 with two terminals and noother H.323 entities.

11.2.1 Heritage of H.323: ISDN

Intelligent end systems are de rigueur in data networking. Evolution toward intelli-gent terminals is not an entirely new concept when it comes to telephony, either—

148 Session Control

this was the goal of ISDN. ISDN call-control signaling is specified in ITU-T recom-mendation Q.931 [3]. Q.931 signaling is used as a point of departure not only byH.323 but also in ITU-T’s development of its ATM User Network Interface.

The two ISDN phones in Figure 11.2 are served by different telco switches.Between the phones and their serving switches, we have ISDN signaling. The twoswitches signal each other using ISUP messages. To help the reader keep track, welabeled the signaling domains at the top of the diagram.

ISDN and ISUP are not exactly the same, but the ITU-T did make every effort toharmonize these standards. So SETUP is very similar to (and compatible with) IAM.ALERTING and ACM serve much the same purpose, as do CONNECT and ANM,and so on.

Note that the originating phone receives two “progress alerts”: CALL PRO-Ceeding and ALERTING. The originating switch sends the former to let the callingphone know that it has received the SETUP and is trying to contact the far-endswitch. ALERTING, on the other hand, means that the far-end telephone has beencontacted and is processing the SETUP (for example, it may be ringing).

Figure 11.2 looks “asymmetric” in the sense that no RELEASE/REL COMinterchange takes place between the destination switch and the called party’s phone.In the figure, we assume for the sake of discussion that the calling party hangs upfirst. This is what triggers his/her phone to send a DISCONNECT message to theoriginating switch, which in turn RELeases the ISUP trunk, and so on. At the end ofthis example, the called party’s phone is not yet “on hook.”

11.2.2 H.323 Call Control and Media Control Signaling

H.323 signaling is specified in recommendations H.225.0 [4] and H.245 [5]. Thecontent of the former is further subdivided into two major pieces: call-control sig-naling (this is similar to Q.931, on which it is based) and registration, admission,

11.2 The H.323 Protocol Suite 149

Destinationswitch

Originatingswitch

ISDNphone

ISDNphone

ISDNISUPISDN

REL COM

RELEASE

DISCONNECT

CONNECT

ALERTING

CALL PROCSETUP

RLC

REL

...telephone conversation...

ANM

ACM

IAM

DISCONNECT

CONNECT

ALERTING

SETUP

Figure 11.2 ISDN call flow.

and status (RAS) signaling. H.245 is used for tasks like codec negotiation betweenendpoints.

In Figure 11.3 we display an H.323 signaling flow. Since H.225.0 and H.245 areboth present, we identify the pertinent protocol alongside each message name. As inFigure 11.1, we make the simplifying assumption that the terminals signal oneanother directly. Note that no RAS signaling appears in this diagram. The number-ing of the messages is intended to help the reader “map” the H.225.0 messages to thegeneric flow that appears in Figure 11.1. The fact that the calling party receives two“status update” messages (i.e., CALL PROCeeding and ALERTING) comes directlyfrom H.323’s ISDN “roots.” This makes more sense when intermediate switches arepresent in the signaling flow (as in Figure 11.2). Note also that the H.225.0 messagesin Figure 11.3 have the same names as their ISDN counterparts in Figure 11.2. Inthis example, codec negotiation and bearer establishment are the province of H.245.H.323 also defines a mode in which the necessary information about terminal capa-bilities is piggybacked on the H.225.0 call-control messages.

11.2.3 Talking to the Gatekeeper: RAS Signaling

By itself, the functionality reflected in Figure 11.3 is impractical for all but the tiniestdeployments. Large deployments necessitate additional capabilities such as addresstranslation, authorization, and admission control. H.323 gatekeepers are responsi-ble for these functions and a few others:

• Address translation makes it possible to place a call using a phone number,e-mail address, or H.323 URI. The gatekeeper is responsible for resolvingthese IDs to (IP address, port number) pairs.

• Call authorization and admission control are both involved in decidingwhether requests will be granted. The former covers things like basic registra-tion, security, who is allowed to call whom, and so on. Admission control

150 Session Control

(7) H.225.0 RLC

(6) H.245 Session release


(4 and 5) H.245 Session establishment

(3) H.225.0 CONNECT

(2b) H.225.0 ALERTING

(2a) H.225.0 CALL PROC

(1) H.225.0 SETUP

Destinationterminal

Originatingterminal

Figure 11.3 Simplistic H.323 session control flow.

determines whether adequate resources are available to serve a given callrequest.

• By definition, a zone is the set of endpoints managed by a single gatekeeper.Zone management takes care of tasks like adding a new endpoint to a zoneand removing an endpoint from a zone.

• Call management controls things like call-forwarding behavior.

We give an example of H.225.0 RAS signaling in Figure 11.4. In the interest ofbrevity, this figure only shows call authorization (this is the Registration Request/Registration Confirm interchange) and admission control (the Admission Request/Admission Confirm interchange).

The signaling flows of the two figures in this section should actually be dove-tailed as follows. In a network governed by a gatekeeper, both terminals must com-plete the registration shown in Figure 11.4 (and the originating terminal mustobtain permission to place the call in the form of an Admission Confirm message)before the flow of Figure 11.3 can begin. The destination terminal does not send itsAdmission Request until it receives the SETUP message from the originating termi-nal. In effect, the destination terminal is asking for permission to answer the call;once it receives the Admission Confirm from the gatekeeper, the remaining steps inthe call control flow of Figure 11.3 proceed as shown. In particular, the gatekeeperdoes not have to be involved. Note also that the H.225.0 SETUP and CALL PRO-Ceeding messages do not have to traverse the gatekeeper.

Why Is RAS Signaling Necessary?

IP networking is typically a more dynamic environment than that of traditionaltelephony, and RAS signaling is necessary to “fill in the gaps.” Endpoints mightoften be moved from one zone to another, their identifiers might take a variety offorms, and so on. H.323 endpoints must be able to signal their identities to theirgatekeepers, due to the simple fact that “nailed up” connections are atypical.

11.2.4 Evolution of H.323

H.323 version 4, which appeared in 2000, brought major enhancements that madeit more practical for large telco deployments. The security framework is morerobust than in previous versions. Some pragmatic tunneling capabilities were also

11.2 The H.323 Protocol Suite 151

H.225.0 Admission Confirm

H.225.0 Admission Request

H.225.0 Registration Confirm

H.225.0 Registration Request

GatekeeperTerminal

Figure 11.4 H.323 RAS signaling.

added. With this release, H.323 (and the “component” protocols under its aegis)reached a level of relative maturity. At the time of this writing, version 5 is in thefinal stages of approval. Version 5 is being characterized as a maintenance releasethat solidifies the H.323 protocol family’s basic functionality. The interested readercan keep track of the latest developments by consulting www.h323forum.org.

Tunneling

Suppose two circuit-switched telephone subscribers want to talk to each other, andthe optimal bearer path traverses an intermediate H.323 domain. Imagine, forexample, that two PBXs are interconnected via an H.323 network. Early versions ofthe H.323 standard did not address this scenario directly. Version 4 introduced ameans to “tunnel” ISUP messages (i.e., encapsulate entire ISUP messages withinH.225.0 payloads) through an H.323 domain. This makes the presence of theintermediate H.323 domain transparent to ISUP entities that signal each otheracross that domain. Tunneling capabilities are also specified for PBX signalingprotocols.

11.3 SIP Basics

We begin our discussion of SIP by casting our generic signaling flow in terms of SIPmessages. The result appears in Figure 11.5. As in Figures 11.1 and 11.3, this exam-ple’s simplicity is deceptive: it does not reflect the challenges one encounters in largescale deployments. There is also a major contrast: Figure 11.1’s steps (4) negotiateterminal capabilities and (5) establish bearer apparently lack counterparts in the SIPcall flow of the current section. As we will see later, the initial SIP INVITE’s payloadusually contains information about supported codecs. So the terminal capabilitynegotiation is not really missing; in fact, it begins right away. Recall from Section11.2.2 that H.323 offers a similar option (notwithstanding the fact that Figure 11.3shows “dedicated” terminal negotiation messages).

152 Session Control

(7) 200 OK

(6) BYE


ACK

(3) 200 OK

(2) 180 Ringing

(1) INVITE

Useragent 2

Useragent 1

Figure 11.5 Simplistic SIP signaling flow.

The establish bearer step is missing from SIP. In cases where resources areexplicitly allocated to sessions, that process is carried out by other protocols; SIP hasno resource reservation capabilities. User agent 1 does, however, confirm receipt ofthe 200 OK response (to its own INVITE message) with an ACK message. The“INVITE-200 OK-ACK” exchange is called a three-way handshake.

Another thing to take away from Figure 11.5 is that SIP endpoints are calleduser agents (UAs); these are roughly comparable with H.323 terminals. (There does,however, seem to be a difference in mentality: we think of a UA as a collection ofsoftware, whereas the word “terminal” makes us think “hardware.”)

SIP is defined in RFC 3261 [6]; numerous other RFCs define extensions of SIP,make recommendations regarding its use with other protocols, and set forth usecases. Before delving into details, it is worthwhile to give a brief overview of whatSIP is and what it is not. SIP’s design is loosely based on that of HTTP [7]). In RFC3261, the authors subdivide SIP’s functionality into five major categories:

• User location: Which end system(s) will be involved in the session?• User availability: Are the called party(s) willing to communicate?• User capabilities: What media should be employed for this session, and what

are the associated parameter settings?• Session setup: Once the previous questions about the user(s) have been

resolved, this is the function that establishes session parameters for all parties.• Session management: This is a catch-all that covers transfer/termination of

sessions, modification of session parameters, and service invocation.

It is important to note that SIP does not provide these functions all by itself; itworks in concert with other protocols. In particular, SIP per se does not know howto describe media types or set the associated parameters. SDP [8] is the currentfavorite for this task, but the authors of SIP purposely “left the door open” for otherprotocols to play this role.

It bears repeating that SIP does not support resource reservation; in fact, it hasno QoS “hooks” whatsoever. More than anything, SIP is a signaling framework.That is, SIP facilitates exchange of information among session participants. Theexact type and format of that information varies with the intended application andwith the protocols used in concert with SIP.

SIP Identifiers

SIP users are usually “named” by URIs. SIP URIs resemble e-mail addresses pre-pended with the characters sip. Examples include:

sip:antigone@greek_tragedies.comsip:antigone@greek_tragedies.com:5001.

Note from the second example that port numbers can be explicitly specified; ifthese are not present, well-known port numbers are assumed. Telephone numbersalso make nice identifiers: tel:12025551212@washdc_gateway.com is an example(telephone URIs are defined in RFC 2806 [9]). Other types of URIs exist (and can beused with SIP); we do not present an exhaustive list.

11.3 SIP Basics 153

DNS functionality is used to resolve domain names in SIP URIs to IP addresses.(We discussed DNS in Section 7.3.3.) The resulting syntax is similar; the URIs of theprevious paragraph might translate to:

sip:[email protected] andsip:[email protected]:5001.

The latter indicates that a SIP entity will be listening on port 5001 at the IPaddress shown and that the name of the associated UA is antigone.

11.3.1 SIP Requests and Responses

There are two types of SIP messages: requests (which are also called methods) andresponses. Actually, RFC 3261 does make a distinction between request and methodby saying that a method is “the primary function that a request is meant to invoke ona server.” However, we will not be careful to maintain this distinction.

By definition, a SIP entity plays the role of client when it generates a request andplays the role of server when it responds to a request. To avoid confusion, it isimportant to be aware that SIP entities, including user agents, routinely play bothroles. To clarify this point, let us refer to Figure 11.5. When user agent 1 sends theinitial INVITE, it plays the role of client; user agent 2 acts as server when it sends180 Ringing and 200 OK messages. At the end of the signaling flow, the roles arereversed: when user agent 2 sends the BYE message (which SIP defines as a request),it acts as a client.

Requests. As of this writing, 13 SIP methods are defined in standards-track RFCs(i.e., there are 13 types of SIP requests). Table 11.1 lists the six methods defined inRFC 3261 itself. This serves to give the reader a sense of SIP’s “base” capability set.We already introduced INVITE, ACK, and BYE in Figure 11.5. (Strangely, SIPclassifies ACK as a request.)

We said that SIP relies on DNS functionality to resolve URIs to IP addresses. (Itwould be more accurate to say that SIP proxy servers rely on DNS functionality; wediscuss proxy servers later.) How are IP addresses bound to URIs in the first place?The REGISTER method provides a way for a user agent to establish or dissolve suchbindings dynamically. As a simple example, a subscriber may be REGISTERed whenhe/she arrives at work in the morning. The SIP URI resolves to the subscriber’s workIP address. Upon returning home in the evening, the subscriber’s UA updates the

154 Session Control

Table 11.1 SIP Methods Defined in RFC 3261

Method Name Description

REGISTER Used to create bindings between a URI and one or more contact addresses.INVITE Used to initiate a session.ACK Used by session originator to confirm receipt of a final response to its

INVITE request.CANCEL Used to abandon a request that is still pending.BYE Used to terminate a session.OPTIONS Used to query the capabilities of a SIP server or client.

URI-IP address binding to reflect the change in location. The SIP URI now resolvesto the subscriber’s home IP address.

To illustrate the usefulness of the CANCEL method, let us vary the example ofthe previous paragraph: suppose the subscriber REGISTERs at both locationssimultaneously so that phones in both places will ring whenever a call comes in. SIPservers support such “forking” behavior. If the subscriber answers at one location,the server will CANCEL the INVITE sent to the other location.

We said that, in the sample call flow of Figure 11.5, information about codecsupport is piggybacked on the initial INVITE message; if user agent 2 sees a codec it“likes” in the INVITE payload, it can specify this codec in its 200 OK message andthe call can proceed. There is another way to go about it: user agent 1 could havequeried user agent 2’s capabilities using the OPTIONS method and populated theINVITE based on the resulting information. (In this scenario, the OPTIONS requestwould precede the INVITE.)

Table 11.1 does not tell the whole story: seven other SIP methods are definedoutside RFC 3261. We defer discussion of these additional SIP methods untilChapter 12.

Responses. SIP response status codes, of which there are many, can be groupedinto six categories. Each status code consists of three decimal digits, with the firstdigit indicating the code’s category.

“1xx” responses are known as provisional responses; they report on requestswhose processing is not yet completed. All of the other response categories are finalresponses. Receipt of a final response indicates that processing of the associatedrequest is now complete. The response categories are listed and briefly describedin Table 11.2.

11.4 SIP Functional Entities

So far, we have only been exposed to UAs. These are the SIP entities in the end users’terminals. SIP networks also feature proxy servers and redirect servers. Among

11.4 SIP Functional Entities 155

Table 11.2 SIP Response Message Categories

ResponseCode

ResponseCategory

Description andExamples

1xx Information Used to indicate status of a request in progress.Examples: 100 trying; 181 call being forwarded

2xx Success Self explanatory.Example: 200 OK

3xx Redirection Further action required.Examples: 301 moved permanently;302 moved temporarily

4xx Client error Receiving server could not process the request.Examples: 401 unauthorized; 404 not found

5xx Server error Request processing failed although the request was valid.Example: 503 service unavailable

6xx Global failure Self-explanatory. Example: 600 busy everywhere

other things, these elements locate “called” UAs on behalf of “calling” UAs—theyare routing intermediaries, in other words.

11.4.1 Proxy Servers and Redirect Servers

The word server means more than one thing in the SIP lexicon. To avoid later confu-sion, we take some care here to distinguish between two uses of this term:

• Recall that every SIP message is either a request or a response; we say that SIPis a request/response protocol. In this context, server is simply a term for anentity that responds to a request. Various SIP entities, including user agentsand proxy servers, can respond to requests (i.e., act as servers) as well as gener-ate requests (i.e., act as clients). Thus, the “server” role is a transient one. Tosummarize, this use of the term refers to an entity’s role in a particular messageexchange, not to its “role in life.”

• A server is the source of something you need. Here are some concrete exam-ples: file servers provide access to storage media, Web servers provide content,and authentication servers provide access to things like subscriber passwords.In this context, the “server” role is indicative of the device’s “mission in life”(that is, the role is static).

The terms proxy server and redirect server should be interpreted in light of thesecond context. The difference between the two is what they provide:

• Proxy servers forward requests and responses. For example, proxy serversforward INVITEs toward destination user agents. Proxy servers can alsoforward responses toward originating user agents. There are two types ofproxy servers:• Stateful proxies (temporarily) keep track of the requests they forward. State-

ful proxies are further subdivided into transaction stateful and call statefulproxies. To describe the difference between the two, suppose we have a suc-cessful session. Roughly speaking, a call stateful proxy retains informationabout that session from INVITE until BYE. (Thus, the proxy must allocatememory for the purpose.) A transaction stateful proxy that is not call state-ful “remembers” the INVITE until it receives the 200 OK response; thisentity realizes that these two messages belong to the same transaction and,since 200 OK is a final response, discards all information about this transac-tion. When the BYE request comes along, the transaction stateful proxyregards it as something completely new.

• Stateless proxies “forward ‘em and forget ‘em.” That is, stateless proxies donot retain any information about the SIP messages they forward.

• Redirect servers do not forward INVITEs. Instead, they respond to the invitinguser agents (or their proxies) with information that will assist them in reach-ing the subscribers they wish to invite. The user agents or proxies are thenresponsible for reissuing the INVITEs. So redirect servers provide routinginformation.

156 Session Control

When a proxy server forwards an INVITE (from a UA, say) it might send a 1xxresponse (recall that 1xx responses are provisional responses, so the INVITE is stillpending after the UA receives such a response). On the other hand, when a redirectserver responds to an INVITE, it does so in the form of a 3xx response. Such aresponse is final, so after the INVITE’s issuer receives and processes the 3xxresponse, that INVITE transaction is finished. A new INVITE will then be issued(this INVITE is populated with information gleaned from the 3xx response).

11.4.2 Back-to-Back User Agents

We have seen that a stateless proxy is a signaling pass-through that maintains noawareness of SIP sessions. A back-to-back user agent (B2BUA) is an entity thatresides at the opposite end of the spectrum, so to speak. The B2BUA’s job is toengage in separate SIP sessions with end users and fool those users (or rather the SIPsoftware in their terminals) into thinking that they are participating in end-to-endsessions.

One could say that B2BUAs terminate SIP signaling (but in a particular way).B2BUAs are far from stateless: they have to retain bindings between identifiers asso-ciated with “incoming” and “outgoing” sessions. To illustrate, suppose user 1wants to INVITE user 2 to a SIP session and that there is a B2BUA situated betweenthe two users. Rather than passing user 1’s INVITE to user 2, the B2BUA crafts acompletely new INVITE. When user 2’s 200 OK comes back, the B2BUA must cor-relate that message to its own INVITE and then in turn to the original triggeringINVITE received from user 1.

Why would a carrier implement a B2BUA? As we will see in Chapter 12, SIPmessages can accumulate a substantial amount of routing information as they travelfrom one proxy to another; there is also information that identifies end users. If aservice provider’s users want to be anonymous, or if the service provider does notwant to disclose addresses of SIP proxies within its network, then B2BUAs might bea pragmatic choice. B2BUAs can also be useful when it comes to traversing firewallsand NATs.

11.4.3 Registrars

One other SIP functional entity bears mentioning: this is the registrar. As the namesuggests, this entity can accept and process REGISTER requests. Note that proxyservers, redirect servers, and registrars are all functional entities—a single networkelement might incorporate more than one of these entities.

Before moving on to other protocols, we note that much more information onSIP appears in Chapter 12. Among other things, that chapter presents detailed SIPsignaling flows. At this point, it may be worthwhile to glance ahead at Figures 12.1and 12.2. These are the overview diagrams for our detailed signaling flows and mayserve to flesh out the current discussion of SIP entities in the reader’s mind.

References

[1] Recommendation H.323 Version 4, Packet-Based Multimedia Communications Systems,ITU-T, 2000.

11.4 SIP Functional Entities 157

[2] Recommendation H.261, Video Codec for Audiovisual Services at px64 kbit/s, ITU-T,March 1993.

[3] Recommendation Q.931, ISDN User Network Interface Layer 3 Specification for BasicCall Control, ITU-TY, May 1998.

[4] Recommendation H.225.0 Version 4, Call Signaling Protocols and Media Stream Packeti-zation for Packet-based Multimedia Communication Systems, ITU-T, 2000.

[5] Recommendation H.245 Version 8, Control Protocol for Multimedia Commmunication,ITU-T, 2001.

[6] Rosenberg, J., et al., RFC 3261, SIP: Session Initiation Protocol, IETF, June 2002.[7] Fielding, R., et al., RFC 2616, Hypertext Transfer Protocol—HTTP/1.1, IETF, April 1998.[8] Hanley, M., and V. Jacobson, RFC 2327, SDP: Session Descriiption Protocol, IETF, April

1998.[9] Vaha-Sipila, A., RFC 2806, URLs for Telephone Calls, IETF, April 2000.

158 Session Control

C H A P T E R 1 2

More on SIP and SDP

SDP [1] was produced by IETF’s Multiparty Multimedia Session Control (mmusic)working group. Incidentally, the original version of SIP (RFC 2543, now obsolete)also came out of the mmusic working group. But SIP activity mushroomed; as aresult, a separate SIP working group was chartered.

12.1 A Detailed SDP Example

Recall that SDP is text-based. Each line in an SDP session description takes the form<type>=<value>, where <type> is always exactly one (case-sensitive) character. SDPcan be used to convey a wide range of session information. Before examining thefollowing session description in detail, let us note the following caveat: there isreally no such thing as an SDP packet. SDP information is always encapsulatedwithin another protocol’s packet (prime examples are Megaco, MGCP, and SIP).To underscore this point, SDP is sometimes called a “metaprotocol.”

v=0o=- 3240312009 3240312009 IN IP4 192.168.0.30s=Standalone SDP Examplec=IN IP4 224.0.12.17/15t=3240312009 0 m=audio 10108 RTP/AVP 0 100m=video 52170 RTP/AVP 31a=rtpmap:0 PCMU/8000a=rtpmap:100 telephone-event/8000a=ptime:20a=fmtp:100 0-11

The first line of the session description gives the SDP version number.The format of the “o=” (owner/creator and session identifier) line is

o=<username> <session id> <version> <network type> <addresstype> <address>.

In the “o=” line, the “-” is a placekeeper; the username subfield is basically null.The SDP RFC recommends (but does not mandate) the use of Network Time Proto-col (NTP)[2] time stamps for the session ID and version subfields. In this example,both fields are in fact NTP timestamps; this means that their values can be inter-preted as the number of seconds since January 1, 1900. The point of all this is to en-sure (or at least make it very likely) that the 5-tuple

<username> <session id> <network type> <address type> <address>

159

is a globally unique identifier for the session at hand, and moreover that distinct ver-sions of this session will not be confused. The last three subfields say that the hostlives in an IPv4 network and disclose its IPv4 address.

The “s=” (Session Name) field is self-explanatory.The subfields of the “c=” (connection data) line, which are of the form

<network type> <address type> <address>

often coincide with the last three subfields of the “o=” line. The current example isan exception, however: the IP address shown is a multicast address (as are all IPaddresses with a number between 224 and 239, inclusive, preceding the first “.”).The number after the “/”, which is called a TTL, says that no packet from this ses-sion shall traverse more than 15 IP routers. Without giving details on IP multicast,let us say that it is wise to include a TTL here to avoid congestion.

The “t=” line consists simply of <start time> <stop time>; again these subfieldsare NTP time stamps, converted to decimal. This feature is useful for scheduled con-ferences. In cases where we do not wish to impose a time limit, a stop time of 0 isgiven. The SDP RFC says that, if the start time is also 0, the session is regarded aspermanent. From our point of view, this overstates the case: it is reasonable toindicate start and stop times of 0 for sessions that will be set up and torn downdynamically (as we have done in the Megaco examples of Chapter 10). We do notreally mean that such sessions are permanent, but only that they are not scheduled.

The “m=” (media name and transport address) lines are easy to parse once oneknows that their format is

m=<media> <port> <transport> <fmt list>.

We see that there are audio and video streams assigned to UDP ports 10109 and52170, respectively. Next we see that both streams are transported over RTP, andthat the item(s) in <fmt list> refer to the AVP [3]. Looking first at the audio stream,the first payload type is 0, which AVP statically assigns to G.711. The second pay-load type, 100, is dynamically assigned; more on the latter in a moment. For thevideo stream, payload type 31 is H.261.

Next we have several “a=” (media attribute) lines. In general, the format can bea=<attribute> or a=<attribute>:<value>. The last four lines of our session descrip-tion can be interpreted as follows:

• The first of the session attributes says that payload type 0 is G.711 (pulse codemodulation, µlaw, sampled at 8,000 Hz); this actually reiterates the assign-ment given in the AVP so it is not, strictly speaking, necessary.

• The second “a=” line binds payload type 100 to the RTP payload type“telephone-event,” which is defined in [4].

• We have seen “a=ptime:20” before; this session attribute means that an RTPpacket will be transmitted every 20 milliseconds.

• The last line of the entire session description conforms to the format a=fmtp:<format> <list of values>, which is used for format-specific attributes. SDPis not concerned with the semantics of format-specific attributes, which are

160 More on SIP and SDP

conveyed unchanged to the entities that will employ the formats in question.In this example, we are completing the task begun in the second “a=” line bylisting which telephone-event types are supported. We will save the readerfrom suspense by saying that telephone-events 0 through 11 are associatedwith the DTMF “digits” 0-9, *, and #.

12.1.1 Additional Line Types

Most of the lines in this session description are mandatory. Exceptions include:

• The “c=” line can be omitted if the requisite information is included “in allmedia” (although we have never actually seen it omitted).

• The SDP “syntax” does not require that any “a=” lines be present (althoughthe sample session description would be ambiguous if those lines werestripped out).

The SDP specification defines a number of other line “types” that do not appearin our examples: they are either not relevant or the encapsulating protocol alreadyhas a means to specify the same content. As an example of the latter, we could spec-ify an “a=sendrecv” attribute in SDP. But in our Megaco examples (see Section10.3.8), we used the mode property in Megaco’s LocalControl descriptor to accom-plish the same task. Moreover, this makes good sense: if all we wanted to do waschange the mode of a termination, it would be wasteful to send an entire SDPdescription.

Additional optional SDP types include an “i=” line type for free-format sessioninformation, “e=” (email address) and “p=” (phone number) types, a “b=” line typefor bandwidth information, and a “k=” line type for conveying encryption keys.

RFC 3312 [5] extends SDP by defining media-level attributes for quality of serv-ice. We introduce a few of these additional attributes and briefly discuss their use inSection 12.6.

12.2 A Detailed SIP Example

In this section, we present SIP signaling flows and dissect the messages therein. SinceSIP is text-based, we can print the messages verbatim and still make some sense ofthem (as we have done with MGCP, Megaco and SDP).

The flows involve a proxy server and a redirect server, so they are more realisticthan the oversimplified flow depicted in Figure 11.5. As in that earlier example,there are only two users; they are called Zebra and BrerRabbit.

12.2.1 Registration Procedures

The users must first register. In Figure 12.1, we display the registration processfor Zebra. We do not display BrerRabbit’s registration, as it is entirely similar.Note the similarity of the current example to H.323 RAS signaling as discussed inSection 11.2.3.

12.2 A Detailed SIP Example 161

We now display the first REGISTER message from the flow of Figure 12.1.Explanatory comments follow the message itself.

REGISTER sip:jackalope.tri.sbc.com SIP/2.0Via: SIP/2.0/UDP 192.168.0.30:5001;branch=z9hG4bK001To: Zebra<sip:[email protected]>From: Zebra<sip:[email protected]>Call-ID: [email protected]: 1 REGISTERMax-Forwards: 70Expires: 60000Contact: <sip:[email protected]:5001;user=phoneContent-Length: 0

To understand the messages in this flow, it helps to know that the proxy serveris running on a machine with host name jackalope and is listening at the“well-known” port for SIP (which is 5060). Also, Zebra is a display name for the SIPURI sip:[email protected]. We have labeled the entities in Figure 12.1with their IP addresses and port numbers. Our purpose is to assist the reader in inter-preting “raw” IP addresses and port numbers that appear in the messages. Notethat, because we only had three machines at our disposal, the registrar/redirectserver and BrerRabbit’s UA ran on the same host. Each of the four entities appearingin the figure has a different port number, however, so focusing on port numbers mayhelp avoid confusion.

The first line of the message above exemplifies the following general request-lineformat.

SIP-Method Request-URI SIP-Version

Zebra specifies in its Request-URI that it wants its proxy server to “field” therequest. Zebra does not need to know where the registrar is, or even whether the reg-istrar and proxy server are running on different machines.

This message comes from a UA residing at the IP address and port numbershown in the Via: line. This message asks the registrar to bind the SIP URI in theFrom: line to the SIP URI in the Contact: line. Thus it binds the former URI to a UserAgent (UA) running at the IP address and port number contained in the latter URI.The Expires field is expressed in seconds; Zebra’s UA is asking that the registrationendure for this amount of time (unless a subsequent message explicitly changes it).The Content-Length: line indicates that there is no additional payload; the SIP


192.168.0.50port 5000

192.168.0.50port 5070

192.168.0.51port 5060

192.168.0.30port 5001

ZebraProxyserver

BrerRabbit

Redirectserver

200 OK

100 Trying

200 OK

REGISTER

REGISTER

Figure 12.1 SIP registration.

header is the entire message. We postpone discussion of the other fields for now-their meanings are a bit easier to explain in later messages.

The proxy server sends a provisional response to Zebra; the first line of thatmessage is SIP/2.0 100 Trying. The general response-line format is

SIP-Version Status-Code Reason-Phrase

Rather than reproduce the response message in its entirety, let us say that itsremaining lines are exact copies of lines from the preceding REGISTER message(namely, the Via:, To:, From:, Call-ID:, CSeq:, and Content-Length: lines). Theremaining lines from the REGISTER message are omitted from the 100 Tryingresponse. Zebra’s UA knows that this response pertains to its pending REGISTERrequest because the From, Call-ID, CSeq and Via fields match. (In fact, for anyresponse, these fields must be identical to their counterparts in the associatedrequest.)

Next, the REGISTER message is forwarded by the proxy server.

REGISTER sip:192.168.0.50:5070 SIP/2.0Via: SIP/2.0/UDP 192.168.0.51:5060;branch=z9hG4bK002Via: SIP/2.0/UDP 192.168.0.30:5001;branch=z9hG4bK001To: Zebra<sip:[email protected]>From: Zebra<sip:[email protected]>Call-ID: [email protected]: 1 REGISTERMax-Forwards: 69Expires: 60000Contact: <sip:[email protected]:5060>Contact: <sip:[email protected]:5001;user=phone>Content-Length: 0

The first Via: line in the message is new; it has been added by the proxy server.In this example, the proxy server knows (as a result of explicit configuration) theregistrar/redirect server’s IP address and port number. These fields are“hard-coded” in the first Via: line. (We doubt that this is typical of live networkdeployments.) The second Via: line is unchanged from the first REGISTER message.Looking collectively at the two REGISTER messages we have seen so far, a patternemerges. Keep in mind that these two messages are “incarnations” of the samerequest; the Via: line(s) reveal the path that the message has traversed thus far. Thisinformation will be used in routing responses.

Note that a similar change has been made to the Contact: information. That is,the first Contact: line is new; the second Contact: line has been copied across fromthe previous REGISTER message. The To:, From:, Call-ID:, and CSeq: lines areexactly the same as in the earlier REGISTER message. Note that the Max-Forwardsvalue has been decremented (so its function is just what the name implies).

The registration attempt is successful, as indicated by the following messagefrom the registrar to the proxy server.

SIP/2.0 200 OKVia: SIP/2.0/UDP 192.168.0.51:5060;branch=z9hG4bK002Via: SIP/2.0/UDP 192.168.0.30:5001;branch=z9hG4bK001To: Zebra<sip:[email protected];tag=c666e2c8From: Zebra<sip:[email protected]


Call-ID: [email protected]: 1 REGISTERExpires: 3600Contact: <sip:[email protected]:5060>Contact: <sip:[email protected]:5001;user=phone>Content-Length: 0

Before forwarding the 200 OK message to Zebra, the proxy server strips outthe first Via: line and the first Contact: line. These are the only changes the proxyserver makes.

12.2.2 Making a Call

Now that our users have registered, they can make calls. For example, Zebra can callBrerRabbit, as illustrated in Figure 12.2. In the interest of space, we dropped thehosts’ IP addresses from the figure. As discussed earlier, the port numbers (whichremain in the figure) are more useful to the reader anyway, since they uniquely iden-tify the entities participating in the call flow.

Let us start by looking at the INVITE that the proxy server forwards toward theredirect server. (In the figure, this is the second INVITE from the top.)

INVITE sip:[email protected]:5070;user=phone SIP/2.0Via: SIP/2.0/UDP 192.168.0.51:5060;branch=z9hG4bK004Via: SIP/2.0/UDP 192.168.0.30:5001;branch=z9hG4bK003To: BrerRabbit<sip:[email protected]:5060;user=phone>From: Zebra<sip:[email protected]:5001;user=phone>Call-ID: [email protected]: 1 INVITEMax-Forwards: 69Subject: Let’s talk about SIPRecord-Route: <sip:[email protected]:5060;maddr=192.168.0.51>


200 OK

BYEBYE

200 OK

200 OK200 OK

180 Ringing180 Ringing

ACK

ACKACK


302 Moved Temporarily

100 Trying

INVITE

INVITE

INVITE

Zebra

port 5001

Proxyserver

port 5060

Redirectserver

port 5070

BrerRabbit

port 5000

Figure 12.2 Making a SIP “call.”

Contact: <sip:[email protected]:5001;user=phone>Content-Type: application/sdpContent-Length: 201

v=0o=- 3240312009 3240312009 IN IP4 192.168.0.30s=-c=IN IP4 192.168.0.30t=3240312009 0m=audio 10108 RTP/AVP 0 100a=rtpmap:0 PCMU/8000a=rtpmap:100 telephone-event/8000a=ptime:20a=fmtp:100 0-11

The Via: lines in this message are similar to those of the second REGISTER mes-sage we examined in Section 12.2.1. The interpretation is the same: the request ema-nated from Zebra’s UA and went from there to the proxy server, which inserted thefirst Via: line. The To: and From: lines are intuitive here: they just say that Zebra istrying to call BrerRabbit. Note that the To: line essentially characterizes BrerRabbitas a user that is registered with the proxy server. This is because Zebra does notknow where BrerRabbit currently is, or that the proxy server is not the registrar. Itjust relies on the proxy server to get the necessary information.

The value of the Call-ID field is different here than in the registration procedureof the previous section. That signaling interchange was completed with the last 200OK, and the old Call-ID referred to that interchange. (Thus the name Call-ID is a bitof a misnomer.) The first INVITE in Figure 12.2 kicks off an entirely new dialog.(Here note that RFC 3261 has a formal definition of the word dialog, but that weare being somewhat loose with this term.)

This message features some fields we did not encounter in the previous section.Just like an e-mail message, an INVITE can have a subject; this is a text stringthat the receiving UA can display to the INVITEd user. This is also the first time wehave seen Record-Route: and Content-Type: lines. The Record-Route: line wasinserted by the proxy server. In so doing, it has asked that future requests in thesame dialog be routed through it. The Content-Type: line indicates that an SDP pay-load follows the header; the Content-Length: field indicates that this payload is 201bytes long.

Notice the blank line between the SIP header and the SDP payload. In fact, everySIP header must end with a blank line, but this was hard to see in our previous mes-sage displays (because all of them had Content-Length 0).

Next, the redirect server responds with a message that looks like this:

SIP/2.0 302 Moved TemporarilyVia: SIP/2.0/UDP 192.168.0.51:5060;branch=z9hG4bK004Via: SIP/2.0/UDP 192.168.0.30:5001;branch=z9hG4bK003To: BrerRabbit<sip:[email protected]:5060;user=phone;

tag=f8505b69>From: Zebra<sip:[email protected]:5001;user=phone>Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]:5000;user=phone>Content-Length: 0


The crucial piece of information in this 302 Moved Temporarily appears in theContact: line. This is where the registrar/redirect server indicates that BrerRabbit iscurrently registered at the IP address shown, and that its UA is listening on port5000.

Recall that 3xx responses are final, and therefore the INVITE is no longer pend-ing. The proxy server ACKnowledges the 302 Moved Temporarily response beforemoving on.

After ACKnowledging the redirect server’s message, the proxy server generatesa new INVITE as follows:

INVITE sip:[email protected]:5000;user=phone SIP/2.0Via: SIP/2.0/UDP 192.168.0.51:5060;branch=z9hG4bK005Via: SIP/2.0/UDP 192.168.0.30:5001;branch=z9hG4bK003To: [email protected]:5060;user=phoneFrom: [email protected]:5001;user=phoneCall-ID: [email protected]: 1 INVITEMax-Forwards: 69 Subject: Let’s talk about SIPRecord-Route: [email protected]:5060;maddr=192.168.0.51Contact: <sip:[email protected]:5001;user=phone>Content-Type: application/sdpContent-Length: 201

...SDP payload goes here...

Note that we have omitted the SDP payload from this message, as it is identicalwith that of the previous INVITE. In fact, the new INVITE differs from its predeces-sor in only two ways:

• In the request-line, the Request-URI now reflects BrerRabbit’s currentlocation.

• The branch parameter in the first Via: line is new. The INVITE that the proxyserver received from Zebra’s UA is still pending, even though the INVITEpreviously sent by the proxy server is not pending. Thus we can think of theproxy server’s newly issued INVITE as a new branch in its continuing effortsto process the still-pending INVITE that began this signaling interchange.

We do not display details of the 180 Ringing message that is originated by Brer-Rabbit’s UA and then forwarded by the proxy server. The following 200 OKresponse indicates that the session setup procedure is successful.

SIP/2.0 200 OKVia: SIP/2.0/UDP 192.168.0.51:5060;branch=z9hG4bK005Via: SIP/2.0/UDP 192.168.0.30:5001To: BrerRabbit<sip:[email protected]:5060;user=phone>;tag=771dcb18From: Zebra<sip:[email protected]:5001;user=phone>Call-ID: [email protected]: 1 INVITERecord-Route: <sip:[email protected]:5060;maddr=192.168.0.51>Contact: <sip:[email protected]:5000>Content-Type: application/sdpContent-Length: 147


v=0o=- 3240316793 3240316793 IN IP4 192.168.0.50s=-c=IN IP4 192.168.0.50t=3240316793 0m=audio 10042 RTP/AVP 0a=rtpmap:0 PCMU/8000a=ptime:20

Once the 200 OK is forwarded by the proxy server and the ACKnowledgmentmakes its way in the other direction (again, details are omitted), the voice conversa-tion begins.

When the conversation is over, Zebra initiates the call termination sequence byissuing the following BYE request:

BYE sip:[email protected]:5060;maddr=192.168.0.51 SIP/2.0Via: SIP/2.0/UDP 192.168.0.30:5001;branch=z9hG4bK006To: BrerRabbit<sip:[email protected]:5060;user=phone>;tag=771dcb18From: Zebra<sip:[email protected]:5001;user=phone>Call-ID: [email protected]: 2 BYEMax-Forwards: 70Route: <sip:[email protected]:5000>Content-Length: 0

The Call-ID field has remained constant throughout the entire signaling flow.That is how BrerRabbit’s UA knows which call is being terminated. Note that theCSeq field is different, however. It now refers to the BYE rather than to an INVITE(or any other SIP message that preceded the exchange of RTP packets). The Call-IDand CSeq are identical to those of the very last message in the flow:

SIP/2.0 200 OKVia: SIP/2.0/UDP 192.168.0.30:5001;branch=z9hG4bK007To: BrerRabbit<sip:[email protected]:5060;user=phone;tag=771dcb18From: Zebra<sip:[email protected]:5001;user=phone>Call-ID: [email protected]: 2 BYEContent-Length: 0

12.2.3 The Offer/Answer Model

SDP does not specify the manner in which session parameters should be negotiated.The use of SIP and SDP together to conduct such negotiations proceeds according tothe offer/answer model of RFC 3264 [5]. The first SDP session description that issent in a SIP dialog is called the offer; the SDP session description that is sent in theopposite direction is called the answer.

The codec negotiation is not complex in the previous example: Zebra includesthe offer (which only contains one codec) in its INVITE, and BrerRabbit acceptsthat choice of codec in its answer, which is included with its 200 OK response. Sinceit must be ACKed, we say that 200 OK is a reliable response. If the sender of a 200OK does not receive an ACK, it will suspect that something is wrong. Contrast thiswith the 100 Trying response, which is never ACKed, and the 180 Ringing response,


which is not ACKed in the foregoing call flow. The SDP “answer” cannot beincluded in an unreliable SIP response; if that response is lost in transmission, theintended recipient will have no way to know.

Alternative version of the codec negotiation. In the call flow of Figure 12.2, theoffer could have been omitted from the INVITE and included instead inBrerRabbit’s 200 OK. In that case, Zebra’s answer would have been included in itsACK. This would have allowed the session setup to progress to the point whereBrerRabbit’s willingness to engage in a session had been established. Note thefollowing regarding this alternative: even though Zebra is still the initiator of the SIPsession, it plays the role of answerer in the codec negotiation. Let us also make thepoint that BrerRabbit expects an ACK from Zebra (it is mandatory). So, if the ACKis lost in transmission (and the “answer” SDP session description is lost along withit), BrerRabbit will realize that something is wrong.

After reading Chapter 10, it may seem strange that there is no “mode” parame-ter—recall that the RTP termination on the first media gateway was initially inrecvonly mode. That termination could only be upgraded to sendrecv once a targetIP address and port number was obtained from the second media gateway.

SIP session parameter negotiation can also be more complicated than in the flowwe just presented. We will see an example in Section 12.6.

12.3 Forking of SIP Requests

SIP allows requests such as INVITE to be forked. This means that a proxy could for-ward an INVITE toward multiple UAs. Branch parameters and the CANCELmethod are crucial for supporting a flexible forking capability. The proxy usesbranch parameters to keep track of the different outgoing forks associated with asingle incoming INVITE. CANCEL is important for “pruning the dead ends,” as wewill soon see below.

Forking capability is useful, for example, in the case of a “follow me” service(see Section 1.2). A subscriber might want to have phones ring at work and at home.Forking can be done in parallel (the phones at both locations ring simultaneously;when one is answered, the proxy sends a CANCEL request toward the other phone)or sequentially (e.g., the office phone rings first; if unanswered, the proxy CANCELsthat fork and sends an INVITE toward the home phone).

12.4 SIP for Interswitch Signaling

In the Megaco and MGCP signaling flows of Chapter 10, the media gateways werepart of the same softswitch. What happens when a call spans two softswitches? If thesoftswitches are connected by TDM trunks, the signaling proceeds just as if one (orboth) of the switches were a circuit switch instead.

One would expect packet connectivity between softswitches, however; in thiscase, SIP is an appropriate vehicle for interswitch signaling. In the call flowsfrom Chapter 10, media gateways use controllers as intermediaries instead of


communicating session information directly to one another. Here, the situation isquite similar.

In Figure 12.3, we have redrawn the Megaco call flow of that earlier chapter(see Figure 10.3). The media gateway controller in the middle has bifurcated so thatthere are now two intermediaries: MGC 1 (which controls MG A) and MGC 2(which controls MG B).

We see that the SIP three-way handshake is interspersed with the Megacoportions of the call setup. In response to MGC 1’s Add request, MGC 1 fills inthe missing media parameters for the termination that faces MG B. (By wayof review, MG A supplies the IP address and port number in the Local descriptor ofits Megaco reply.) The resulting “fleshed out” SDP description is encapsulated inthe SIP INVITE for transmission to MGC 2, which passes that description on toMG B. (More precisely, MG B learns of MG A’s IP address and port number bylooking at the Remote descriptor in the Megaco Add transaction it receives fromMGC 2.)

Comments

If the bearer path traverses more than one MG in either softswitch (or bothsoftswitches), there is additional Megaco signaling that is not shown. However, theportion of the call flow that is shown is largely the same either way. Of course, wecould just as easily have employed MGCP signaling within one or both of thesoftswitches.

MGC 1 and MGC 2 view each other as SIP proxies. There could be additionalSIP proxies between the two (not shown in the figure for reasons of simplicity).Numerous configurations are possible, including variations on the SIP flow ofFigure 12.2. For example, MGC 1 might consult a redirect server directly to deter-mine where to send the INVITE, receiving this information in the body of a 302Moved Temporarily message. Or MGC 1 might send the INVITE to an intermedi-ate proxy server that in turn consults a redirect server before forwarding MGC 1’sINVITE.

12.4 SIP for Interswitch Signaling 169

MG BMGC 2MGC 1MG A

Subtract (x2)/Reply

Subtract (x2)/Reply

Modify/Reply

Add; Add/Reply

Add; Add/Reply

200 OK

180 Ringing

INVITE

200 OK

BYE


ACK

Figure 12.3 SIP for interswitch signaling.

12.4.1 Comparison with BICC

Recall that there is an alternative to SIP—BICC. When we discussed it (in Section10.7.1), we said that BICC is based on ISUP. If we assume that BICC would be run-ning atop a traditional SS7 stack, then BICC would have a clear disadvantage—namely, that it would rely on global title translation whenever call routing got com-plicated. We believe that SIP’s flexible “routing resolution” capabilities represent amore sensible option.

If BICC were running atop some “flavor” of sigtran, SIP’s advantage might beslightly less clear. Any analysis of the competitive merits would depend on the proto-col layers between SCTP and BICC.

Without going into detail, we believe that SIP is still a better choice overall.Moreover, the industry seems to be heading in this direction. Note, however, thatBICC has one clear advantage over SIP—built-in compatibility with ISUP.

12.5 Additional SIP Methods

In Section 11.3, we discussed the SIP methods defined in RFC 3261 itself (in particu-lar, see Table 11.1). Table 12.1 lists the remaining SIP methods currently defined instandards-track RFCs. In the table, we reference the defining RFC for each method.The MESSAGE method is included in the table for completeness; we will not com-ment on it further.

One of the strengths of SIP is that it can be used to pass along information that itdoes not understand. The INFO method is used when applications wish to passinformation back and forth, but the content is not of concern to intermediate SIPentities. Data encapsulated within an INFO message has no effect on the state of SIPsession(s). In Section 12.7, we will see an example INFO usage in which the “appli-cations” are ISUP entities.

The provisional response ACKnowledgment, or PRACK, method is used insituations that call for provisional responses to be reliable. Recall that provi-sional responses such as 180 Ringing were not acknowledged in the signaling flowsof Sections 12.2 and 12.4; in fact, the ACK method is used only for final responses.


Table 12.1 SIP Methods Defined Outside RFC 3261

Method Name Defining RFC [ref] Description

INFO RFC 2976 [6] Carries information that is generated during a session andthat relates to the control of that session by a non-SIPapplication.

PRACK RFC 3262 [7] Used when reliable transmission of provisional responsesis required.

SUBSCRIBE RFC 3265 [8] Used to request notification whenever specific eventsoccur (e.g., changes in call state).

NOTIFY RFC 3265 [8] Used to send notification of SUBSCRIBEd events.UPDATE RFC 3311 [9] Used to furnish updated session information while an

INVITE request is still pending.MESSAGE RFC 3428 [10] Used to transfer instant messages.REFER RFC 3515 [11] Instructs recipient to contact a third party and provides

the information necessary to do so.

The sender of a provisional response can ask for a PRACK by including a line of theform Require: 100rel in that response’s header. It is illegal to PRACK a 100 Tryingresponse (or for the sender to ask for a PRACK).

SUBSCRIBE and NOTIFY make it possible for SIP entities to be notified ofevents that take place in other domains (e.g., the PSTN). We elaborate on theSUBSCRIBE, NOTIFY, and REFER methods in Chapter 13.

12.5.1 UPDATEs and re-INVITEs

Suppose a party to a session wants to affect a change to the session parameters. If itis an established session (i.e., a success response to the initial INVITE has beenreceived), then a new INVITE can be issued. This is often called a re-INVITE.

If session establishment has not been completed, it is illegal to issue are-INVITE. It is possible to request that session parameters be changed, however, byusing the UPDATE method. Other than this difference in allowed usage, UPDATEand (re-)INVITE are entirely similar.

12.6 Resource Reservation and SIP

The previous call flows in this chapter (see Figures 12.2 and 12.3) assume that ade-quate resources are available. Of course the call setup fails if this is not true; this is adistinct possibility, especially in deployments that feature explicit resource reserva-tion and call admission control. With the call flows as they are drawn, we wouldhave already rung the called party’s phone by the time it became clear that the callsetup would fail.

Consider Figure 12.3. The SIP portion of the call setup is particularly simplethere: it is just the typical INVITE / 200 OK / ACK (with a 180 Ringing thrown infor good measure). Up until the ACK, the only message that MGC 2 receives fromMGC 1 is the INVITE itself. If we wish to avoid spurious ringing on the called par-ty’s phone, the MGCs must engage in additional dialog. Moreover, session parame-ters may be negotiated dynamically by the MGCs. (Recall that the MGCs see eachother as SIP proxies.)

RFC 3312 [12] addresses this problem. In Figure 12.4, we present a signalingflow that is compatible with the scheme proposed in that RFC. In this depiction, theinterchange takes place between two User Agents (UAs), but it could just as welltake place between two proxies acting on behalf of UAs. The flow of Figure 12.4 isapplicable to SIP interswitch signaling scenarios: in such scenarios, MGCs regardone another as SIP proxies with UAs “behind them,” so to speak.

In our example, the UAs use RSVP to reserve resources for the call. IP adheres toa unidirectional paradigm, so resource reservation for the UA 1 → UA 2 and UA 2→ UA 1 bearer directions requires two separate RSVP signaling interchanges.Moreover, RSVP signaling proceeds in the opposite direction of bearer traffic. Thus,UA 2 must send an RSVP Resv message toward UA 1 to reserve UA 1 → UA 2 bearercapacity (and vice versa).

We annotate the call flow of the figure as follows:

12.6 Resource Reservation and SIP 171

• The INVITE contains UA 1’s initial SDP offer. Included in the offer are the IPaddress and port number that UA 1 wishes to assign to this call. UA 2 needsthis information for two reasons:• As a target address for bearer traffic once the session has been established.• As a necessary parameter for RSVP signaling to allocate resources along the

UA 1 → UA 2 bearer path. In the right-hand margin of the diagram, we indi-cate that UA 2 launches an RSVP Resv message toward UA 1 as soon as itgets the prerequisite addressing information.

• MGC 2’s initial response to the INVITE is a 183 Session Progress messagecontaining its SDP answer. Now 1xx responses are provisional, and SDPoffer/answer dialogs must be conducted reliably, so MGC 2 requests a PRACK(by including a Require: 100rel):• Once it receives the IP address and port number in UA 2’s answer, UA 1 can

initiate RSVP signaling to reserve resources for the UA 2 → UA 1 bearerpath.

• The PRACK and ensuing 200 OK are a pair (i.e., the latter is a final response tothe former). Here we are simply following the rules pertaining to reliable pro-visional responses; no SDP descriptions are interchanged here.

• The UPDATE and 200 OK that follows it are also a request/response pair.However, these messages do contain SDP descriptions:• The Resv message initiated by UA 2 is propagated “upstream” toward UA 1,

with routers along the way reserving the necessary resources hop by hop.Once the propagated Resv reaches UA 1, the UA 1 → UA 2 bearer reserva-tion is complete. In effect, UA 1 says in its UPDATE message: “I can sendnow.”

• By the time it sends its 200 OK message, UA 2 has received a propa-gated Resv (analogous to the above, this is the culmination of the RSVPsignaling interchange initiated by the far end). Thus at this point UA 2 isalso able to say: “I can send now.” At this point, the QoS negotiation iscomplete.


UA 2UA 1

Resv rec’d

Resv --> UA 2

UA 1 sends RSVP

Resv rec’d

Resv--> UA 1

UA2 sends RSVP

...session now established...

200 OK/ACK

180 Ringing

200/OK

UPDATE

PRACK/200 OK

183 Session Progress

INVITE

Figure 12.4 SIP call flow incorporating resource management .

• The 200 OK and ACK at the end of the signaling flow represent the comple-tion of the three-way handshake that began with the INVITE.

Not everything about the foregoing signaling flow is cast in stone. Suppose, forinstance, that UA 2 had decided to send 200 OK (in response to UA 1’s UPDATE)before receiving the propagated Resv message. Then UA 2 would need to send anupdated session description once the Resv arrived. It could do so in its subsequent180 Ringing provisional response (but in this case the 180 Ringing would have to bePRACKed). This is quite reasonable, since our model in this example is that UA 2should not alert its user of the incoming call until resource reservation in both direc-tions has been confirmed.

Another variant is that the initial offer could have been included in the 183 Ses-sion Progress instead of the INVITE.

12.6.1 QoS Attributes in SDP

RFC 3312 [12] extends SDP by introducing QoS attributes. Recall the “I can sendnow” statements that appear in the previous signaling flow description. Thesedeclarations are formally expressed using QoS attributes. We provide a glimpse ofthe new attributes by excerpting SDP media descriptions from the INVITE andUPDATE messages in our signaling flow. Note well that these are not complete SDPsession descriptions; each only incorporates media level attributes.

First, let us look at the media attributes contained in the INVITE:

m=audio 10108 RTP/AVP 0c=IN IP4 192.168.0.30a=curr:qos e2e nonea=des:qos mandatory e2e sendrecv

The syntax of the “m=” (media name and transport address) and “c=” (connec-tion data) lines was covered in Section 12.1. A “c=” line that appears after an “m=”line applies only to the media stream associated with that “m=” line.

In this SDP fragment, the “a=curr” line says that the current level of end-to-endQoS is “none”; resources have not yet been reserved in either direction. The“a=des” line says that the desired level of end-to-end QoS is sendrecv. That is,resources must be reserved in both directions (as indicated by the word “man-datory”).

By the time it sends the UPDATE message, UA 1 has received an RSVP Resvmessage indicating that resources have been reserved along its downstream pathtoward UA 2. The “a=curr” line in the following SDP fragment therefore reflectsthat UA 1 is now authorized to send.

m=audio 10108 RTP/AVP 0c=IN IP4 192.168.0.30a=curr:qos e2e senda=des:qos mandatory e2e sendrecv

UA 2 wants to know when it would be appropriate to alert its user of the incom-ing call. Therefore, in its 183 Session Progress message, UA 2 includes an “a=conf”line (not shown in the interest of simplicity) asking UA 1 to send confirmation

12.6 Resource Reservation and SIP 173

whenever its downstream bearer path has been set up. The second of these mediadescriptions is the desired confirmation.

RFC 3312 also allows for endpoints to independently negotiate QoS parametersin their access networks. In such a scenario, separate lines with “local” and“remote” qualifiers would replace the single line with the “e2e” qualifier. Forexample,

a=curr:qos local nonea=curr:qos remote none

would replace the line

a=curr:qos e2e none

in the SDP payload of the INVITE. If only one of the access networks implementedQoS negotiation, only the “local” or “remote” line would appear.

12.6.2 More on Parameter Negotiation

In the signaling flow of Figure 12.4, four SDP session descriptions are sent in all:two “offers” from UA 1 and two “answers” from UA 2. It is easy to imagine otherscenarios that require more than a single offer/answer interchange. For instance,the offerer might list several codecs. The answerer could indicate which codecs itsupports by responding with a subset of the original list. One more step wouldremain: the offerer would make the final codec selection and, finally, inform theanswerer.

RFC 3312 was evidently aimed at integrating RSVP within SIP signaling flows.The authors introduce a general notion of a precondition, say that they will onlydefine “QoS” preconditions in the document in question, and finally give examplesin which the user agents employ RSVP to make sure that the QoS preconditions aremet before session establishment is completed. The model proposed by RFC 3312does not mandate RSVP for resource management, however. Moreover, the specifi-cation leaves the door open for other types of preconditions.

One might expect that the SDP extensions of RFC 3312 would be used in con-junction with MGCP and/or Megaco, or that there would be some other “formula”for integrating media gateway control with RSVP. Although there have been someInternet drafts addressing this general topic area, there are no active ones in theMegaco Working Group at the time of this writing (nor have any such drafts made itto RFC status).

12.7 SIP-T and Beyond

It is important for SIP to interwork with PSTN signaling protocols. The SIP-TRFC [13] concentrates on interworking between SIP and SS7 signaling domains(more specifically, between SIP and ISUP). The status of this RFC is “best currentpractice.”

For a simple two-party call, we can identify the following four possibilities:


1. The “SIP bridging” case: origination and termination are both in the PSTN,but call control signaling must traverse an intermediate SIP domain.

2. PSTN origination—IP termination.3. IP origination—PSTN termination.4. IP origination—IP termination.

Of these possibilities, SIP alone suffices only for the last; the other three requiresome degree of ISUP-SIP interworking. The SIP-T document provides signalingflows for the other three cases.

SIP-T seeks to satisfy three main interworking requirements:

• Transparency: The presence of an intermediate SIP signaling domain shouldnot alter the exchange between ISUP endpoints in any way. This requirementonly makes sense in case 1, the SIP bridging case.

• Routability: SIP messages must be routable in the SIP signaling domain purelyon the basis of information in their SIP headers. This requirement applies tocases 1 and 2.

• Ability to transfer mid-call ISUP messages: This requirement applies to case 1.

Let us concentrate first on the SIP bridging case. SIP-T’s authors observe thatthere is not a one-to-one mapping between ISUP message fields and SIP messagefields. Thus, any mapping of ISUP messages to SIP be imperfect and would generallyentail loss of information. Thus, it would be difficult if not impossible to:

• Translate ISUP message contents to SIP at ingress to a SIP signaling domain.• Reconstitute the ISUP messages at egress from that SIP domain.

Thus SIP-T recommends that the transparency requirement be satisfied byencapsulating ISUP messages within SIP payloads. The encapsulation format isspecified in RFC 3204 [14].

The philosophy behind the routability requirement is that SIP proxies cannot beexpected to screen piggybacked ISUP content for routing information. Instead, ISUPinformation that is pertinent to routing is translated into a form that can be incorpo-rated into the SIP header.

ISUP defines information request (INR) and information (INF) messages. Theyallow one signaling exchange to ask for and receive information from another sig-naling exchange during a call. There are also messages that allow a call to beSUSpended (without tearing down the connection) and later RESumed. INR/INFand SUS/RES are rather obscure. In spite of their rarity, these message types arethe motivation for the aforementioned mid-call requirement. For INR/INF andSUS/RES interchanges between ISUP protocol entities, the intermediate SIP domainis strictly a pass-through (recall that the mid-call requirement applies only to the SIPbridging case). In particular, no changes to SIP session state are implied. The SIPINFO method is employed for pass-through signaling.

RFC 3398 [15], a standards-track RFC, continues in the direction laid out bySIP-T. It does so by fleshing out the correspondence between ISUP parameters andSIP message headers. The bulk of the document specifies the mapping betweenparameters of ISUP Initial Address Messages and SIP INVITE message headers. The

12.7 SIP-T and Beyond 175

resulting benefit is that SIP proxies can make informed routing decisions. RFC 3398is pertinent to the aforementioned cases 1 and 2 above (the two PSTN originationscenarios listed earlier in this section).

Once an initial INVITE has been routed properly, there is typically enoughinformation in the Via: and Route: headers for correct routing of later messages per-taining to the same session. RFC 3398 also discusses the mapping of SIP status codesto ISUP Address Complete Messages and Release Messages.

12.8 Authentication and Security

SIP supports HTTP digest authentication [16]. In this scheme, a user agent wouldinitially send an unauthenticated REGISTER or INVITE. A SIP proxy, registrar,redirect server, or far-end user agent would issue a challenge within the body of a4xx final response (the details differ depending on whether the challenger is a proxyor another functional element). The UA would respond by incorporating its creden-tials into a new INVITE.

Wireless networks already employ sophisticated authentication schemes. Aswireless carriers move to deploy SIP-based services, they will base their authentica-tion procedures on those existing schemes.

We saw in Section 11.4.2 that information such as URIs and IP addresses can behidden from the “outside world” by B2BUAs, but that such devices have to maintainstate information in order to create the illusion of end-to-end SIP sessions. Let uslook at some other ways to protect routing information and other message content.

SIP messages contain URIs and IP addresses, both in the message headers and inSDP payloads. Secure/Multipurpose Internet Mail Extensions (S/MIME) [17] can beused for end-to-end encryption of SDP payloads.

End-to-end encryption of entire SIP messages is possible: SIP’s secure versionemploys the same approach as (and an analogous URI scheme to) that of HTTP overTLS [18]. However, much of SIP’s usefulness is tied to its routing functionality: SIPproxy servers and redirect servers can be configured in a variety of ways. Soend-to-end encryption is problematic because it defeats the purpose.

TLS [19] can be employed on a “hop-by-hop” basis. In this approach, SIP func-tional entities maintain TLS adjacencies. SIP messages would be decrypted andexamined by each proxy. The proxy would make its routing decision based on thedecrypted content and then re-encrypt the SIP message before sending it on to thenext proxy or UA (or other SIP functional element).

Security is a major topic; we have not done justice to it. In closing this section,we remark that telcos are accustomed to the physical security associated with theirSS7 infrastructures. Any large-scale move to a control plane based on SIP representsa drastically different security environment. We cannot overemphasize this point.

12.9 Further Reading

Even though we devoted a fair number of pages to SIP, we have not come close toexhausting this topic.


It is evident from the foregoing discussion of SIP that address resolution androuting is crucial. RFC 3263 [20] gives details on the use of DNS to support SIPmessage routing.

There was so much activity surrounding SIP that an additional IETF workinggroup was chartered: the Session Initiation Protocol Investigation (sipping) workinggroup. The sipping working group documents the use of SIP in applications; theoriginal SIP working group remains focused on the essential functionality of theprotocol.

SIP-T came out of the sipping working group. Two recent sipping RFCs [21,22], present a range of scenarios. Like the SIP-T RFC, these RFCs are categorized asbest current practices.

For readers who wish to delve further into SIP, we recommend books byCamarillo [23] and Johnston [24].

References

[1] Handley, M., and V. Jacobson, RFC 2327, SDPL Session Description Protocol, IETF, April1998.

[2] Mills, D., RFC 1305, Network Time Protocol (Version 3) Specification, Implementation,and Analysis, IETF, March 1992.

[3] Schulzrinne, H., and S. Casner, RFC 3551, RTP Profile for Audio and Video Conferenceswith Minimal Control, IETF, July 2003.

[4] Schulzrinne, H., and S. Petrack, RFC 2833, RTP DTMF Digits, Telephony Tones, andTelephony Signals, IETF, May 2000.

[5] Rosenberg, J., and H. Schulzrinne, RFC 3264, An Offer/Answer Model with the SessionDescription Protocol (SDP), IETF, June 2002.

[6] Donovan, S., RFC 2976, The SIP INFO Method, IETF, October 200.[7] Rosenberg, J., and H. Schulzrinne, RFC 3262, Reliability of Provisional Responses in Ses-

sion Initiation Protocol (SIP), IETF, June 2002.[8] Roach, A.B., RFC 3311, The Session Initiation Protocol (SIP) Specific Event Notification,

IETF, June 2002.[9] Rosenberg, J., RFC 3311, The Session Initiation Protocol (SIP) UPDATE Method, IETF,

September 2002.[10] Campbell, B., et al., RFC 3428, Session Initiation Protocol (SIP) Extension for Instant

Messaging, IETF, December 2002.[11] Sparks, R., RFC 3515, The Session Initiation Protocol (SIP) Refer Method, IETF, April

2003.[12] Camarillo, G., W. Marshall, and J. Rosenberg, RFC 3312, Integration of Resouce Manage-

ment and Session Initiation Protocol (SIP), IETF, October 2002.[13] Vemuri, A., and J. Peterson, RFC 3372, Session Initiation Protocol for Telephones (SIP-T):

Context and Architectures, IETF, September 2002.[14] Zimerer, E., et al., RFC 3204, MIME Media Types for ISUP and QSIG Objects, IETF, Sep-

tember 2002.[15] Camarillo, G., RFC 3398, Integrated Services Digital Network (ISDN) User Part (ISUP) to

Session Initiation Protocol (SIP) Mapping, IETF, December 2002.[16] Franks, J., et al., RFC 2617, HTTP Authentication: Basic and Digest Access Authentica-

tion, IETF, June 1999.[17] Ramsdell, B., RFC 2633, S/MIME Version 3 Message Specification, IETF, June 1999.[18] Rescorla, E., RFC 2818, HTTP Over TLS, IETF, May 2000.

12.9 Further Reading 177

[19] Dierks, T., and C. Allen, RFC 2246, The TLS Protocol Version 1.0, IETF, January 1999[20] Rosenberg, J., and H. Schulzrinne, RFC 3263, Session Initiation Protocol (SIP): Locating

SIP Servers, IETF, December 2003.[21] Johnston, A.B., et al., RFC 3665, Session Initiation Protocol (SIP) Basic Call Flow Exam-

ples, IETF, December 2003.[22] Johnston, A.B., et al., RFC 3666, Session Initiation Protocol (SIP) Public Switched Tele-

phone Network (PSTN) Call Flows, IETF, December 2003.[23] Camarillo, G., SIP Demystified, New York: McGraw-Hill Professional, 2002.[24] Johnston, A. B., SIP: Understanding the Session Initiation Protocol, 2nd ed., Norwood,

MA: Artech House, November 2003.


C H A P T E R 1 3

Implementing Services

In this chapter, we discuss intelligent network (IN) and related approaches to pro-viding telco services. Then we move on to SIP, where we cover SIP/IN hybrid serv-ices and SIP-based services.

Finally, we describe Short Message Service (SMS), which provides text messag-ing capabilities in wireless networks. SMS is a departure from IN-style telco serv-ices. That is the main reason we cover SMS—we think it helps one to associate abroader connotation with the word “service.” We also draw some interesting com-parisons between SMS and SIP.

13.1 Introduction

Traditionally, development of new services in the telco realm has been expensiveand time-consuming. Telecom service providers have come to recognize that this is amajor problem: to be profitable, services must enjoy long, useful (and revenue-gen-erating) lifetimes and mass-market penetration. Niche markets and rapidly evolvinguser requirements are therefore extremely difficult to accommodate.

Telco switches have been programmable for quite some time. Initially, serviceswere programmed directly on the switches. It would be nice if telco networks wereprogrammable, as it would become much easier to develop and maintain newservices. There has been progress toward this goal, but unfortunately it has beenvery slow.

Many approaches to this problem have sprung up. One can achieve a rough(albeit imperfect) dichotomy as follows:

• Initiatives such as Telcordia’s AIN project and ITU-T’s IN standardizationeffort seek “programmability from the inside.” That is, they seek to centralizeservice capabilities at SCPs, which reside in carriers’ networks (and are nottraditionally accessible from outside those domains). In this model, new serv-ices are developed by the SCP vendors (and/or the carriers themselves). WINand CAMEL are variants that seek to extend IN concepts to the wirelessrealm.

• Initiatives such as Parlay/OSA and JAIN seek “programmability from the out-side.” Such initiatives aim to provide a secure environment that is “friendly”to third-party software developers.

179

We will expand these acronyms as we go along. We remark here that the term“intelligent network” refers to a specific set of ITU-T standards and also to a moregeneric philosophy of service implementation. When it is not otherwise clear fromcontext, the reader should assume we are referring to the latter.

We begin our coverage by examining the generic IN philosophy. In the intelli-gent network approach, finite state machines running in telephone switches can beinterrupted at specified points. Interrupts are not generated for every call but onlywhen specified conditions are met. The service developer specifies the code (a.k.a.,service logic) that is to be executed whenever an interrupt is generated. The intelli-gent network model allows the service logic to reside outside the serving switch.

13.2 SS7 Service Architectures: Intelligent Network

Consider traditional telco services like calling name ID, call blocking, and toll-freeservice. How are these services provided in circuit-switched networks?

To a large degree, the answer is that SCPs tell voice switches what to do. (Recallthat SCPs reside in SS7 networks.) SCPs did not exist when many services were ini-tially conceived and implemented. Early on in the era of digital switching, servicelogic was executed by the switches themselves. (Digital switches, whose large-scaledeployment began in the 1970s, are programmable.) Hosting the service logicentirely on the switches proved to be a maintenance nightmare, however: logicfor new services had to be installed on every switch. Interaction with previouslyexisting services had to be debugged, and so on. Moreover, a service provider witha multivendor switching network had to go through this process separately foreach vendor. Thus, the idea of controlling services from a central point wasappealing.

With the deployment of SS7 in the 1980s, that idea became realizable: the SS7network provided a secure and reliable way for service control platforms to commu-nicate with voice switches. Various organizations sought to establish a systematicway to move service logic out of voice switches, housing that logic instead in SCPs.

We can characterize the classic example, toll-free service, as follows:

• The service is triggered by the originating switch (that is, the calling party’sserving switch) when it realizes that it does not have any routing informationthat is directly applicable to the called number.

• Two types of special handling are required (note that these are both taken careof during call setup):• Alternative billing;• Assistance in routing the call.

If every desirable service shared these characteristics, life would be easy. But:

• Some services (e.g., call blocking) are triggered by the terminating switch.• There are services that require mid-call interaction. In a credit card call, for

example, one can press and hold the “#” key to ask for dial tone (so as to placeanother call without reentering calling card number and PIN).

180 Implementing Services

• Some tasks/services are not associated with calls at all. The MAP UpdateLocation procedure covered in Section 8.7 is a case in point. By way of review,this procedure tells the home location register that a subscriber has “surfaced”in a given place. The procedure is therefore a crucial prerequisite for comple-tion of mobile terminated calls (but the Update Location itself is not associ-ated with any particular call).

The ability to manipulate individual call “legs” (e.g., to support three-way callsand conference calls) is also desirable.

One of the early IN-type initiatives was launched by Bellcore (later renamedTelcordia). The Bellcore project, which was limited to the wireline environment,was called Advanced Intelligent Network (AIN). The goal of Bellcore’s AIN initia-tive was to develop a conceptual model that would support a rich array of services,and to shorten the development cycle for new services. ITU-T’s IN standards wereinspired by AIN.

The IN conceptual model, as standardized by ITU-T, is made up of severalplanes: two layers of abstraction are interposed between service functionality (fromthe end user’s point of view) and service implementation on physical devices. Weelected not to list the (numerous) entities that reside in each plane: otherwise, therewould be acronyms all over the place and prolixity would be unavoidable. How-ever, we think it is worthwhile to briefly enumerate and describe the followingplanes:

• What features does the service offer to the end user? Its description inthe service plane answers this question but does not say anything aboutimplementation.

• In the global functional plane (GFP), the software components used to imple-ment the service are specified. The software components that live in this planeare called service independent building blocks (SIBBs). The GFP essentiallypretends that the network is one machine.

• The distributed functional plane (DFP) is a more realistic representation of thenetwork than the GFP. As we move from the GFP to the DFP, we admit thatthe former is oversimplified; here we model the network as a distributedentity.

• Network elements such as SCPs and voice switches reside in the physicalplane.

Before going on, we should be careful to say that, in today’s networks, someservice logic remains in voice switches. Not all services are equally amenable tothe IN model—in some cases, it may be more trouble than it is worth to implementa service along these lines. Moreover, carriers may choose to maintain thestatus quo with switch-based services that were in place before IN was sufficientlymature.

Throughout this section, our examples are given under the blanket assumptionthat services are implemented according to the IN model. The fact that this assump-tion sometimes differs from real-world implementations should not diminish theillustrative value of those examples.

13.2 SS7 Service Architectures: Intelligent Network 181

13.2.1 The Global Functional Plane

The developers of IN concluded that standardizing services was not a useful thing todo. One of the driving principles behind ITU-T’s IN effort was that it would be farmore useful to standardize the capabilities that services rely on. Different serviceswould use the same building blocks but in different ways. This notion is reflected bythe presence of SIBBs in the global functional plane and is very much in line with theconcepts of modularity and code reuse in object-oriented programming.

A special SIBB known as the basic call process (BCP) is a FSM; we introducedFSMs in Section 6.4. The idea is that a separate copy of the BCP is instantiated foreach call. At points of transition between the states, it is possible to interrupt theBCP and execute service logic before returning—that is, invoke other SIBB(s) withparameters appropriate to the situation at hand. Moreover, it is not necessary toreturn to the BCP at the point where the interrupt was generated. The call blockingexample is a case in point: if the calling party is on the called party’s “do not accept”list, the call will be aborted (perhaps after playing an announcement to the callingparty). There are SIBBs for a variety of functions, including authentication, userinteraction, and charging. Except for the ability to interrupt the BCP at specifiedpoints, the SIBBs are “black boxes.”

13.2.2 The Distributed Functional Plane

The BCP is an abstraction; let us take a step toward implementation by going fromthe global functional plane to the DFP. As we do so, the BCP “morphs” into twobasic call state models (BCSMs): the originating BCSM and the terminating BCSM.As the name suggests, the former (a.k.a., the O-BCSM) resides in the originatingswitch, whereas the latter resides in the terminating switch. So, at the DFP level, weexplicitly recognize that distinct software processes are acting on behalf of the call-ing and called parties.

The O-BCSM and the T-BCSM are finite state machines; thus, we have replacedthe BCP by a pair of more granular abstractions. Recall the IN mentality: the servicelogic resides, outside the switch, in an SCP. Thus, when an “interesting” eventoccurs, we need a way to notify the SCP. Moreover, call processing may have to besuspended until the switch receives instructions from the SCP. In the case of atoll-free call, for instance, the originating switch does not know how to route thecall. The O-BCSM generates an interrupt asking for routing information and sus-pends processing until that information arrives. In IN terminology, the interruptsare called detection points (DPs).

We confess that there are some mixed metaphors in the previous paragraph:some of the entities mentioned reside in the DFP, whereas others live in the physicalplane. To pave the way for our forthcoming discussion of SIP/IN interworking, itbehooves us to align ourselves with IN jargon by speaking of service control func-tions (SCFs) instead of SCPs. SCFs live in the distributed functional plane. SCPs,which are instantiations of SCFs, inhabit the physical plane.

Detection Points

DPs are associated with events that cause state transitions in the BCSMs. When exe-cution reaches an armed DP, the SCF is informed of the event. Control may be


transferred to the SCF (with processing in the BCSM suspended until the SCFreturns control thereto; this is called a request), or the BCSM may continue process-ing (this is called a notify). We already saw an example request; we will see an exam-ple notify shortly. DPs are further classified as follows:

• A trigger DP is armed when a user’s service subscription is configured. Forexample, when a user subscribes to a call blocking service, a trigger DP in theT-BCSM is armed. When this DP is tripped, the SCF will check the callingparty number against the called party’s “do not accept” list.

• An event DP is armed dynamically by service logic during call processing.

Example. Implementation of a “ringback on busy” service requires us to have atrigger DP and an event DP at our disposal, as we now describe. When a subscriberto this service tries to call a busy line, the service logic is invoked by a trigger DPcalled O_Called_Party_Busy. The “O_” prefix refers to the originating BCSM;O_Called_Party_Busy was armed when the user subscribed to the service. Whenthat trigger DP fires, the service logic must arm an event DP known as T_Disconnectin the terminating switch. (In effect, the service logic is asking the terminating switchto “let me know when the busy party hangs up.”) Both detection points in thisexample are of the “notify” variety.

There is a vague similarity here to the usage of Megaco and MGCP’s Notifycommands. We also point out the following distinction: recall that, in the MegacoNotify example of Section 10.3.9, the media gateway reported the occurrence ofan off-hook event for an analog line. In the current example, it does not matterwhether the line in question is analog- in the IN model, that aspect has been“abstracted out.”

13.2.3 IN Capability Sets

When it was released, IN capability set 1 (CS-1) represented a step forward. ButCS-1 suffers from the following serious limitations:

1. It is geared toward a model where services reside within a single operator’snetwork.

2. It lacks support for interactions that are not associated with any call.3. Multiparty calling, videoconferencing, and the like are largely out of scope.

Given the fact that wireless networks are evolving much more rapidly than theirwireline counterparts, items 1 and 2 point to serious shortcomings: roamingrequires that services be supported across network boundaries and mobility man-agement requires support for transactions not associated with calls.

CS-2 addresses item 1 by allowing SCFs (which are potentially in different net-works) to communicate among themselves. Regarding item 2 above, CS-2 intro-duces a call-unrelated counterpart of the Basic Call Process; improved support forteleconferencing is also added. CS-2 brought other enhancements, but in the interestof brevity we do not detail them here. CS-3 introduced a few new capabilities butwas mostly a maintenance release.

13.2 SS7 Service Architectures: Intelligent Network 183

ITU-T proceeded to standardize CS-4, which “blesses” the IETF’s PINT andSPIRITS protocols. But by this time, many people felt that IN was running out ofsteam, so to speak. We cover PINT and SPIRITS in Section 13.6.1.

13.2.4 Limitations and Trade-offs of IN

To a degree, we could view IN as an effort to extend PBX-type services to the massconsumer market, both in the wireline and wireless domains. IN did meet with somesuccess (notably for 800 number portability, followed by local number and finallywireless local number portability). But why was IN not a bigger success? In ourmind, the following reasons stand out:

• SCPs did not allow the degree of vendor independence that telcos had hopedfor. As a result of interoperability issues (e.g., vendor A’s SCF only works withvendor A’s voice switches), telcos often ended up buying separate SCPs fromeach of their switching vendors.

• IN did not shorten the service development cycle as much as its proponentshoped.

• The IN model is somewhat cumbersome. In our opinion, the class 5 switch isstill a bottleneck: it instantiates a complex state machine for every call.

• The telecommunications industry changed rapidly. As a result the bar wascontinually raised, and the cycle of standardizing a new capability set, devel-oping, and finally deploying compliant products was too slow to keep pace.• The importance of interworking between different network environments in

general (and wireless networks in particular) increased more quickly thanthe IN community could respond.

• Messaging changed dramatically. Business users now need to managee-mail, fax and voice mail messages. For many users, short messages and/orinstant messages are added to the mix. The IN community did not anticipatethe need for unified messaging. (To be fair, few people saw it coming.)

The telephone itself is part of the problem. Here we are referring to:

• The user interface: 12 buttons, accompanied in most cases by a tiny text dis-play (or no display at all). It is difficult to configure and control a complexservice via such a primitive interface. Thus, it is very difficult to create newservices that are easy to use.

• The lack of intelligence and signaling capabilities in the typical telephone. Theredial button on an analog wireline telephone comes to mind. Although itserves a purpose, it is not very smart. Suppose a subscriber makes a call that isanswered by a DTMF-driven menu system. The subscriber navigates throughthe menus to a certain point, perhaps entering a PIN for authentication some-where along the way. But suppose the subscriber gets disconnected prema-turely. The telephone does not know the difference between the called numberand the DTMF digits that were entered after the call was answered. So, ifthe subscriber attempts to access the system once again by pressing the redial


button, the phone replays the entire string of digits that was entered since thelast off-hook transition (or, rather, however many DTMF digits the phone canremember).

Although it has not fulfilled its initial promise, IN is still useful for flexible callcontrol in circuit-switched networks. We are interested mainly in the conceptual INarchitecture, as previously described. For completeness, we mention that the proto-col for IN signaling is called INAP. INAP is carried over SS7 links.

Mobility in wireless networks poses problems that are not encountered in wire-line environments. Next, we look briefly at two standards that apply the IN philoso-phy to these problems.

13.3 CAMEL and WIN

Customized Applications for Mobile Enhanced Logic (CAMEL [1, 2]), an IN-likestandard, is deployed in GSM networks. It reuses IN terminology and concepts. Inparticular, one speaks of arming CAMEL triggers, just as with IN.

Initially, CAMEL’s primary use was to support roaming for prepaid wirelesssubscribers. As with IN, the developers had high hopes, and CAMEL has evolvedthrough multiple capability sets. Some carriers now use CAMEL for more than justprepaid services. Overall, however, CAMEL appears to have limited horizons.

To support prepaid roaming, it is necessary for a service control platform in onenetwork to exert a degree of control over a voice switch in another network. In ourdiscussion of IN, we saw that CS-1 does not support such internetwork control sce-narios. CAMEL signaling interchanges are conducted between the home locationregister and the visiting location register. (We confess that we are oversimplifying abit here.)

Just as CAMEL was devised to solve problems in GSM networks, WirelessIntelligent Network (WIN) extends IN notions to solve mobility-related problemsin North American CDMA and TDMA networks.

CAMEL and WIN signaling is transported over SS7 links. For CAMEL, the sig-naling protocol is called CAMEL Application Part (CAP [3]). Message formats tosupport WIN signaling appear in the ANSI-41 standards.

13.4 Parlay/OSA

The stimulus for Parlay (see www.parlay.org) was a regulatory mandate: BritishTelecomm (BT) had to allow other service providers to access its switches. BT wasvery concerned about security; as a result, it became a cofounder of the Parlaygroup, which sought to define open, secure interfaces for third-party access to telconetworks.

Parlay’s creators wanted to open the interface between the SCP and the switchto allow third-party developers to create new services. Moreover, Parlay specifies aframework for security (i.e., authentication and authorization for third-party appli-cations wishing to access telco network resources) and service management (includ-ing service discovery).

13.3 CAMEL and WIN 185

Another group, Open Service Access (OSA), embarked on a similar work pro-gram. Parlay and OSA decided to align their specifications; here we treat Parlay andOSA as a single combined entity.

The Parlay group specifies application programming interfaces (APIs). One ofthe design goals of the APIs is to make it easy for software developers to create appli-cations that involve telephony regardless of the developers’ level of telecommunica-tions expertise. This is seen as a key to bringing innovation to the realm of telcoservice creation.

Actually, the Parlay group maintains two sets of specifications: Parlay itself anda variant called ParlayX. The two specifications differ “under the hood”: Parlayemploys CORBA as its middleware layer, whereas ParlayX uses XML. The ParlayXAPIs are easier to use (but somewhat less powerful) than their Parlay siblings.

A word on the difference between a protocol and an API may be in order here.The former specifies message formats for communicating parties. The latter specifiesprocedures that software developers can call within their code. The advantage of anAPI in the present context is that software developers can harness the capabilities ofunderlying protocol entities without getting involved in protocol stack “nuts andbolts.” For more on the distinction between protocols and APIs, we recommend theenlightening discussion in Mueller’s book [4].

13.5 JAIN

Java Advanced Intelligent Network (JAIN) is an initiative aimed at Java softwaredevelopers who lack in-depth telecom experience. Thus it bears some similarities toParlay/OSA (although JAIN is not as comprehensive). Again, the idea is to stimulateinnovation by making it possible for a larger community to participate in servicecreation.

13.6 SIP and Services

Our purpose in this section is to make the case that SIP is useful for services. We startby covering PINT and SPIRITS, which enable services that straddle circuit-switchedand packet-switched networks (using SIP in the process). It is telling that Igor Fayn-berg, cochair of PINT, has coauthored a book on intelligent networks [5].

13.6.1 SIP and Intelligent Networks: PINT and SPIRITS

In this section, we look at the output of two IETF working groups: PSTN and Inter-net Interworking (PINT; this working group is concluded) and Services in PSTNrequesting Internet services (SPIRITS, which is still active at the time of this writing).

PINT’s aim is to enable IP-based services to request PSTN services. WithSPIRITS, it is the other way around. Of the two, PINT came first. The main PINTRFC [6] introduced the SUBSCRIBE and NOTIFY methods (which were laterabsorbed into the “baseline” SIP specification—see [7]). Here is an example use ofPINT functionality: a user visits a company’s Web site, fills out a form, and requests


that a copy of the form be sent to a fax number. The PINT service might want toSUBSCRIBE to information about the success (or failure) of the fax delivery. Whenthe fax transmission’s success/failure code becomes available in the PSTN, it is con-veyed to the PINT service by means of a NOTIFY.

Complex services will require bidirectional interaction, so we expect that PINTand SPIRITS will be used together more often than not. Moreover, exposition canbe cumbersome if we insist on maintaining the distinction between the two. There-fore, we will not be careful to do so in the rest of this section but will instead justrefer to SPIRITS.

As is the case with IN, SPIRITS does not aim to specify services so much as itaims to specify flexible building blocks. However, it can be useful to have a para-digm example in mind. One of the paradigm examples in the SPIRITS architecturedocument [8] is Internet caller ID (ICID). Our primary purpose here is to familiarizethe reader with SIP’s SUBSCRIBE and NOTIFY commands; ICID is well suited tothat purpose.

We now give a thumbnail description of ICID. A PC user wants to be notifiedwhenever there is an incoming call to his/her phone. The notification, whichincludes the identity of the caller, is presented to the subscriber by an ICID clientrunning on the PC.

To realize this service, we clearly need SPIRITS functionality: the incoming callrequest “lives” in the PSTN, but the ICID client is running on a PC that is onlyreachable through the public Internet.

How should the ICID service work? When the terminating switch becomesaware of the call request (e.g., by receiving an ISUP Initial Address Message), it mustgenerate an event notification. This means that, somewhere along the way, a detec-tion point must have been armed in the terminating BCSM. Let us assume that, atthe request of the ICID subscriber, the ICID service logic arms an event DP. Whenthat event DP fires, a message is sent to the ICID client on the subscriber’s PC, whichin turn alerts the subscriber.

In Figure 13.1, there are two SIP user agents: one inside the ICID end user’s PC,and the other inside (or alongside) the ICID SCF. The SPIRITS gateway is a SIPproxy. The SIP SUBSCRIBE and NOTIFY methods can be used to implement ICIDin the following way:

1. The PC-based user agent issues a SIP SUBSCRIBE indicating that it wants toarm the appropriate DP in the Terminating BCSM. Thus we have labelledthis User Agent as the SPIRITS SUBSCRIBEr (the capital letters indicate thatwe are referring to the User Agent’s role rather than to the end user of theICID service).

2. The user agent in the SCF sends a 200 OK. After the SCF successfully armsthe DP on the terminating switch, its user agent sends a SIP NOTIFY toinform the user agent of its subscription status.

3. When the DP fires, the SCF user agent alerts the PC user agent by issuinganother SIP NOTIFY.

RFC 3265 [7] says that the notification in step 2 should be sent, even though it isnot an indication that the trigger has actually fired. The 200 OK tells the far-end UA

13.6 SIP and Services 187

to expect that a NOTIFY message will follow soon. The SCF UA can send a 202 OKinstead if it wants to acknowledge the SUBSCRIBE request without promising thatthe trigger will be armed. Since the NOTIFY method is used to communicate thestatus of the subscription request, there is really no need to send a provisionalresponse (e.g., 100 Trying).

A certain amount of provisioning is required to make ICID work: both UAs haveto be able to find the SPIRITS gateway and vice versa.

Why would anyone implement ICID? It would only be worthwhile if it allowedthe subscriber to influence the processing of the call in some useful way. Thus, for aservice built around ICID, the IN trigger would have to be a request DP (i.e., a DPfor which control is transferred to the ICID SCF). Presumably it would be useful toprovide calling name ID, regardless of the other particulars of the chosen service.This means that the SCF would need to dip the calling name database and incorpo-rate the resulting information into the NOTIFY message of step 3.

The following service examples come to mind:

• A call-forwarding capability (e.g., for a traveler who has to be away fromhis/her phone but does not know the forwarding number before reachinghis/her destination or who wants to forward calls selectively).

• An Internet call-waiting service, which “kicks in” when:• The subscriber is engaged in a dial-up Internet session on the subscribed line.• The subscriber’s serving switch receives an incoming call request for that

line.Instead of engaging in the default behavior (playing a busy signal or perhapsforwarding to voice mail), Internet call waiting enables the subscriber to deter-mine the disposition of incoming calls on a case-by-case basis.

An Internet call-waiting service must be able to alert the subscriber of the incom-ing call (this is ICID capability again), receive the subscriber’s instructions for dispo-sition of the call, and see to it that those instructions are carried out. In the casewhere the subscriber’s intent is to forward the call, the second step would normallybe carried out using the REFER method [9]. The REFER request would contain theforwarding information, which could “point” to a PSTN termination or to a VoIP


PSTN

ICID end user’sPC

IP Domain

SCF

SPIRITSSUBSCRIBEr

SPIRITSNOTIFYer

SPIRITS gateway

Event subscriptions

Event notifications

Figure 13.1 Schematic SPIRITS configuration.

domain (e.g., a VoIP gateway with connectivity to an H.323 terminal or SIP phone).The third step (carrying out the subscriber’s instructions) is beyond our scope.

Although each REFER request requires a final response, the REFER methoddoes not employ the three-way handshake we saw with INVITE (that is, 200 OK isnot followed by an ACK). As a result, REFER’s associated state machine is less com-plicated than INVITE’s. The same is true of SUBSCRIBE and NOTIFY.

In its current Internet draft incarnation, the SPIRITS protocol specifies an Inter-net call waiting service whose ICID portion differs from the SUBSCRIBE/NOTIFYapproach previously described. (We refer to this service by its acronym, ICW, to dis-tinguish it from the version described in previous paragraphs.) The ICW specifica-tion is at least partly the result of a desire to codify implementation approaches thatpredate SPIRITS [10]. One difference is worth mentioning: ICW uses a triggerdetection point in the serving switch; presumably this DP is armed when the enduser’s subscription (to the service) is processed. It may seem like a small thing at firstglance, but we claim that the security models for the two approaches are quite dif-ferent. For ICW, telco provisioning systems are responsible for arming the necessarytriggers. In the ICID approach, entities outside the service provider’s network areempowered to change settings on voice switches inside the network. With the ICIDapproach, service providers must account for (and adequately protect against)actions of rogue user agents. For example, a rogue UA might arm triggers for manylines that are not actually subscribed to the service and simply not respond toNOTIFY messages reporting that the triggers have fired. Eventually, the NOTIFYtransactions would time out in the SCF. But the SCF’s memory and/or processingcapacity might be overloaded (with unpredictable results), especially if the SCF hasbeen dimensioned for a fairly small customer base.

Why would a carrier want to offer an Internet call-waiting service? If offeredexclusively, it might enable the service provider to bring in additional revenue bypackaging services in attractive bundles. For instance, it might help the company sellthe services of its own (or an affiliated) Internet service provider to its exising cus-tomers. If ICW and calling name ID services were combined at an attractive price, itmight be possible to attract new subscribers.

The Internet call-waiting service concept is relatively new. But depending on thespeed of migration from dial up to broadband Internet access [e.g., cable modemand digitial subscriber line (DSL)], this service may have a fairly short usefullifetime.

Contrast this with the revenue-generating lifespans of services like call waitingand caller ID, which might be measured in decades. Although these services repre-sented a substantial investment of time and money on the part of service providers,there has been ample opportunity to recoup the investment several times over.Many services in the future may have short lifetimes. So the need for faster andcheaper development cycles is real.

At the time of this writing, the SPIRITS protocol has not reached RFC status.There is an Internet draft that is updated from time to time, however, and the proto-col described therein is based on SIP. In closing we note that there is a SPIRITS pro-tocol requirements RFC [11].

SIP is making inroads into wireless networks. As we continue our discussion ofSIP-based services in Section 13.7, we shift our attention to the wireless realm.

13.6 SIP and Services 189

13.7 SIP in Wireless Networks

The 3rd Generation Partnership Project (3GPP, www.3gpp.org) seeks to evolveGSM networks to support third generation services. As an aside, we note that theCDMA “camp” has similar initiatives underway—the interested reader can consultwww.3gpp2.org. Our discussion will focus on GSM and 3GPP.

A word about the history of wireless networks may be in order here. Firstgeneration mobile phones employed analog transmission in the radio frequency(RF) domain. So called second generation (2G) technologies such as TDMA, CDMAand GSM are digital. 2G represents a big step forward from analog, but its data net-working capabilities are minimal (2G technologies offer little more than wirelessversions of dial up service). Third generation (3G) wireless initiatives seek to offer amuch richer array of capabilities to the end user. Broadly speaking, the goal is toenable services that combine voice, video, and data in useful ways. As wireless net-works evolve, SIP promises to be an important piece of the puzzle.

In recent years, CDMA and GSM carriers have augmented their networks byadding IP routers. They also adapted their RF interfaces to incorporate a modicumof statistical multiplexing capability. While this still falls short of the “vision” of 3G,it is now possible to implement SIP-based services (that is, services with SIP, ratherthan SS7, inhabiting the control plane). Push to Talk over Cellular (PoC), an earlyexample, is the topic of Section 13.7.1.

To reach full-fledged 3G functionality, further enhancements to RF infrastruc-tures and mobile handsets are required. These improvements, which encompasssupport for higher data rates and multiple simultaneous sessions, will not beemphasized here.

3G architectures also incorporate enhancements to IP domains within PLMNs.We touch on aspects that are pertinent to enriched services in Section 13.7.3.

13.7.1 Push To Talk over Cellular

PoC is a half-duplex voice service that dispenses with customary call setup proce-dures. That is, PoC departs from the model in which the caller dials the called party’snumber, an end-to-end TDM channel is allocated, the called party’s phone rings,and finally the called party decides to accept or reject the call.

In some usage patterns, the standard call setup procedures become laborious;PoC is aimed at user populations that would benefit from “lightweight” call control.For example, construction workers or other blue-collar workers at job sites may needto relay information in short “talkbursts.” Setting up a standard circuit-switched callis overkill for such applications. Fleet dispatching applications are also candidates forsimplified control. PoC’s operation is often compared with that of walkie-talkies. Amajor difference is that PoC is designed to use wireless wide area networks and there-fore does not suffer from the distance limitations of walkie-talkies.

Push to Talk was pioneered (and the name was trademarked) by Nextel, a U.S.wireless carrier, using proprietary technology. At the time of this writing, PoC is inthe process of being standardized by the Open Mobile Alliance for (interoperable)use in 3GPP and 3GPP2 networks. The interested reader can find pointers to thePoC standardization effort at www.openmobilealliance.org.


Various carriers are introducing (or have already introduced) prestandard PoCimplementations that use RTP as the voice bearer and rely on SIP (and perhaps a bitof RTCP) for control. The standardized version will retain similar general charac-teristics. The PoC initiative will standardize the management of “buddy lists.”Buddy lists enhance ease of use by offering subscribers a simple way to contact indi-viduals or groups that they frequently interact with. PoC will also standardize waysto make use of presence, availability, and location information.

Why PoC? Now that wireless carriers have made basic data networking func-tionality available to their subscribers, they are eager to roll out revenue-generatingservices that take advantage of the new capabilities. PoC fills the bill. It is not anaccident that PoC voice is half duplex, for at least two reasons:

1. Half-duplex mode hides latency. Latency is substantial in today’s PLMN IPdomains; in particular, it is much greater than in PLMN circuit-switcheddomains. If one tried to implement a full-duplex voice service in the currentenvironment, delays in the bearer plane would be painfully obvious. Such aservice would be very hard to use.

2. Media mixing is not necessary in half-duplex mode. In PoC, only one partycan have the “floor” at any given time. This means that group PoC sessionsare much easier to implement than full duplex conference calls (although thePoC server must replicate voice packets). Unlike PoC servers, conferencebridges must also mix media streams (since they do not know whichparticipant is currently speaking; moreover, multiple participants may try tospeak at the same time). On the other hand, part of the complexity of PoCresides in its floor control scheme.

Thus, we see that, to a substantial degree, PoC embodies the “art of thepossible.”

13.7.2 SIP Header Compression

Wireless networks suffer from high bit error rates. Moreover, bandwidth is at a pre-mium, since licenses for wireless spectrum are expensive.

SIP signaling exchanges can consume a substantial amount of bandwidth (ascan IP traffic in general). As we have seen, SIP headers tend to be voluminous giventhe amount of routing information they can convey; this is especially true in IPv6deployments.

On the other hand, SIP signaling exchanges feature a significant amount ofrepeated and/or predictable information: SIP’s text-based nature makes the mes-sages easy for humans to understand, but no one would accuse the protocol of beingcompact. Thus, it should be possible to compress SIP headers for transmission overthe RF interface without any loss of information. But the high bit error rates that areendemic to the wireless domain must be carefully taken into account.

This is the motivation behind SigComp [12], which came out of IETF’s RobustHeader Compression (rohc) working group. Other RFCs that pertain to SIP com-pression are [13, 14].

13.7 SIP in Wireless Networks 191

13.7.3 IP Multimedia Subsystem

How should carriers go about deploying SIP-based services? Carriers face manyissues (such as operations, administration, maintenence, provisioning, billing, secu-rity/privacy, availability, and reliability) that differ from those encountered withservices residing in the public Internet. Of course, public Internet services also haveto be administered. Since carriers want to maintain a high degree of control overtheir networks, however, the two environments are very different. In addition, wire-less carriers require sophisticated mobility management functionality.

SIP’s development in the IETF was driven by people who embraced the notion oflightweight control; the progenitors wanted to develop tools that would enable mul-timedia services in the public Internet. This was especially true early on. Since telcosgot interested in SIP, the standards have “bulked up” a bit.

As we saw in the previous section, wireless carriers want to deploy SIP-basedservices. Is SIP now ready for the telco environment? If so, how does its usage varyfrom other scenarios? To shed some light on these questions, we take a cursory lookat 3GPP’s IP Multimedia Subsystem (IMS) specifications. In broad terms, IMS is aplatform for wireless telco services that feature:

• IP-based bearers;• SIP as the primary session control protocol (in lieu of SS7). Here we note that

SIP does not take on all of the functions performed by SS7 in today’s networks:for example, subscriber database platforms are queried using Diameter [15].

If PoC were the only forthcoming service to rely on SIP, IMS would be unneces-sary. The IMS standardization effort comes out of a belief that numerous serviceswill not only use SIP but will also be “consumers” of the same types of information.For example, SIP-based instant messaging may become widespread in the years tocome. Like PoC, instant messaging service can be enhanced by incorporating pres-ence information.

IMS is intended as a flexible platform for service creation and management. TheIMS overview document [16] states explicitly that the goal is to standardize flexibleservice-supporting mechanisms rather than the services themselves. Thus IMS bearsmore than a passing resemblance to the IN philosophy discussed in Section 13.2.

IMS Functional Elements

IMS defines a variety of call session control functions (CSCFs). Note this terminol-ogy’s similarity to that of IN’s distributed functional plane (see Section 13.2.2). TheCSCFs function primarily as SIP proxies, although they may behave as user agentsunder certain circumstances.

Let us first discuss the serving-CSCF (S-CSCF). In the IMS model, service logicresides on application servers (ASs); the S-CSCF acts as an intermediary betweenASs and the rest of the network. For example, in an IMS PoC implementation, theuser’s handset would register with the S-CSCF. After checking the user’s PoC sub-scription, the S-CSCF would provide access to the PoC server.

The proxy-CSCF (P-CSCF) serves as the first point of contact for the hand-set-resident user agent. That is, the handset’s SIP user agent talks to the SIP entity in


the P-CSCF. Note that, between the handset UA and the P-CSCF, there are interven-ing IP network elements. In particular, the gateway router in the visited PLMN isresponsible for finding the P-CSCF (e.g., by launching a DNS query). Note thatgateway routers go by different names depending on the cellular technology; that iswhy we prefer to remain nonspecific. The P-CSCF is also responsible for terminat-ing SigComp (i.e., compressing SIP messages in the downlink direction and decom-pressing SIP messages in the uplink direction).

It may seem a little odd to distinguish between the S-CSCF and P-CSCF. Keep inmind that CSCFs are functional entities; for a subscriber who is attached to his/herhome network, the serving- and proxy-CSCF roles may be played by the same net-work element. A quick look at the roaming case, which is a little more complicated,serves to motivate the S-CSCF/P-CSCF distinction. A simple supporting illustrationappears in Figure 13.2. After it attaches to the visited PLMN, the subscriber’s hand-set establishes IP connectivity with the outside world through the gateway IP router.The gateway IP router lacks a SIP stack; it can locate the P-CSCF on behalf of theuser but does not know about SIP entities in other networks. The P-CSCF is in turnresponsible for forwarding SIP requests and responses between the handset and theS-CSCF.

A third functional entity, the interrogating-CSCF (I-CSCF), is optional. In smalldeployments, separate I-CSCFs are unnecessary. When present, the I-CSCF assignsusers to S-CSCFs as those users register. In large deployments, the I-CSCF functioncould be used to implement load balancing (e.g., based on subscriber identity).Moreover, telcos may not want to disclose their topologies (or even the number ofS-CSCFs) to one another. The I-CSCF can be used to hide this type of informationfrom external entities.

Service Mobility

In Figure 13.2, why is the S-CSCF located in the subscriber’s home network? It is anarrangement that supports service mobility. Simply stated, a subscriber should beable to access the same services when roaming as are available in the home network.This idea, which has been bouncing around for years in the IN community, oftengoes under the name virtual home environment (VHE). To date, the VHE concept

13.7 SIP in Wireless Networks 193

IP

SIPHandset

VisitedPLMN

GatewayIP router

Proxy-CSCF

HomePLMN

Serving-CSCF

Appserver

Figure 13.2 IMS serving-CSCF and proxy-CSCF.

has remained somewhat nebulous. By listing VHE as a requirement, the framers ofthe IMS specifications have expressed a view that IMS is a suitable vehicle for realiz-ing service mobility.

Triggering IMS Services

How are IMS services triggered? Here we present a simplified view of 3GPP’sanswer to this question; for more information, see the IM Call Model TechnicalSpecification [17]. The influence of IN concepts is very prominent in this document.This makes sense: application servers (ASs) would get bogged down if they had toperuse every SIP signaling flow, message by message, to determine when they neededto do something. So ASs rely on S-CSCFs to notify them of pertinent events (much asCAMEL SCPs rely on mobile switching centers for notification).

How does an S-CSCF know when to notify an AS? Figure 13.3 gives a simplifiedview of the triggering architecture described in [17]. The service point triggers(SPTs) in the diagram are the SIP signaling points that potentially cause the S-CSCFto send a SIP message to some AS (although there is only one AS in the figure, theremay be many ASs in an actual deployment). SPTs can be based on the type of SIPmessage received, the presence (or absence) of specific header fields, and/or the con-tents of specific header fields.

The filter criteria determine which SPTs actually cause the S-CSCF to send mes-sage(s) to one or more ASs. Filter criteria also specify which application serversshould be contacted. When a user registers with IMS, the S-CSCF queries the sub-scriber database for the appropriate filter criteria. This allows for SPTs to be“armed” on a per-subscriber basis.

In the temporal realm, the interchange depicted in Figure 13.3 would play outas follows:

• When the subscriber registers, the S-CSCF acquires the associated filter criteriafrom the subscriber database. The filter criteria tell the S-CSCF which servicepoint triggers are pertinent for this subscriber.

• The incoming SIP message (an INVITE, say) matches one of the filter criteria,so the S-CSCF dispatches a SIP message to the AS.

• Upon receipt of this message, the AS invokes the appropriate service logic.

• Depending on the application particulars, the S-CSCF continues its tasks as aSIP proxy (e.g., message forwarding; this is the horizontal dotted arrow ema-nating from the “filter criteria” box) or waits for instructions from the AS (thisis the dotted arrow emanating from the “service logic” box).

Note that this example is highly simplified. In particular, space limitations pre-vent us from covering the following topics:

• What happens when multiple ASs “subscribe” to the same SPT.• The S-CSCF service control model. This defines finite state machines that

reside in S-CSCFs and ASs. Dialog between S-CSCFs and ASs occurs in thecontext of these state machines.


• How IMS interacts with circuit-switched domains (the short answer is that itdoes so via a softswitch).

• How IMS interacts with other control platforms (e.g., CAMEL platforms andOSA/Parlay gateways). For CAMEL interworking, see [18, 19].

Additional Comments on IMS

Before moving on, it is worth noting that the IMS specifications mandate support ofIPv6 (support of IPv4 is optional) and forbid forking on the part of CSCFs. Moreo-ver, there are some IMS-specific SIP headers that carry information about chargingand networks that are transited in roaming scenarios. In keeping with IETF’s guide-lines for extending SIP, the additional headers are defined as private headers (orP-headers) in an informational RFC [20].

IMS signaling also involves specialized use of SDP: namely, the “local” and“remote” QoS descriptors defined in RFC 3312 [21]. We refer the reader to thebrief discussion that appears in Section 12.6.1.

3GPP has published four main IMS technical specifications. We already cited[16, 17]. For detailed specifications on IMS-compliant use of SIP and SDP, theinterested reader can consult [22]. Detailed renditions of numerous call flowsappear in [23].

13.8 Short Message Service

People make a big deal (perhaps justifiably) of SIP’s ability to transfer free-formatinformation. That is, SIP does not care about the contents of the payload. But this isnot new—SMS has offered the same type of flexibility for some time.

SMS is heavily used in wireless networks; there has been talk of extending SMSfunctionality to wireline networks. However, we know of no wireline deploymentsat the time of this writing. For GSM networks (and their 3G descendents), SMS isspecified in [24].

SMS was originally conceived and deployed as a text messaging service; itadheres to a “store and forward” paradigm. In some ways, the solution is inelegant:

13.8 Short Message Service 195

Appserver

Serving-CSCF

Filtercriteria

Servicelogic

Servicepointtriggers

SIP messageIncoming

Subscriberdatabase

Figure 13.3 Triggering IMS applications.

• At various stages of its end-to-end path, a short message (SM) is likely to becarried over a variety of protocols. In PLMNs, SS7 MAP [25] is the primarytransport vehicle for SMs. A different protocol stack carries SMs over the RFinterface. A third protocol stack can be (and often is, at least in the UnitedStates) used for intercarrier transport of SMs, and so on.

• There are differences in text-encoding schemes (e.g., between CDMA andGSM carriers). There are also differences in the maximum message sizes (theyare typically somewhere around 150 characters).

• Based on these, we see that SMs really are…, well, short.• On today’s typical handsets, SMs are difficult to type: the 12-key keypad is a

poor substitute for a “real” keyboard.

SMS is all about the “art of the possible.” One can almost reconstruct thethought process that went into its creation: “How could we get a text message fromone (digital) handset to another? Well, the SS7 network that interconnects themobile switching centers is a packet network...let’s concoct a delivery mechanismthat uses excess capacity on our SS7 links.”

13.8.1 SMS in Support of Other Applications

SMS suffers from throughput and transport efficiency limitations. Despite theselimitations, SMS has been remarkably successful; people have employed it to do use-ful things. This is true from a technical point of view as well as a marketing point ofview. We give an example for each point of view:

• Over the air provisioning. This is very useful because it allows the carrier toupdate the settings on the handset without requiring the subscriber to visit astore location. As handsets have evolved complex architectures, SMS hasevolved the ability to address SMs to specific functional components residingwithin the handset.

• Voting applications. Here we are referring to mass-market campaigns thatallow subscribers to cast their votes for things like “most valuable player” or“most glamorous movie star.”

SMS is used for many things; this list is intended as an illustration and is by nomeans exhaustive.

13.9 Further Reading

Just as telephone switching technology is changing, service architectures are alsoevolving. This chapter only scratches the surface of this subject area.

For a general overview of IN concepts and their potential evolution, werecommend Zuidweg’s recent book [26]. We have been particularly sparing in ourcoverage of WIN (the ANSI-41 counterpart of CAMEL). Christenson et al. [27]have written an informative book on this topic.


We have also given short shrift to OSA/Parlay. Mueller’s book [4] is a very goodreference; the author is active in the Parlay group.

References

[1] TS 22.078 Customised Applications for Mobile Networks Enhanced Logic (CAMEL);Service Description, Stage 1, 3GPP.

[2] TS 23.078, Customised Applications for Mobile Netwrok Ehnanced Logic (CAMEL);Stage 2 Specification, 3GPP.

[3] TS 29.078, Customised Applications for Mobile Networks Enhanced Logic (CAMEL);CAMEL Application Part (CAP) Specification, 3GPP.

[4] Mueller, S. M., APIs and Protocols for Convergent Network Services, New York:McGraw-Hill Professional, 2002.

[5] Faynberg, I., et al., The Intelligent Network Standards: Their Application to Services, NewYork: McGraw-Hill, 1996.

[6] Petrack, S., and L. Conroy, RFC 2848, The PINT Service Protocol: Extentions to SIP andSDP for IP Access to Telephone Call Services, IETF, June 2000.

[7] Roach, A. B., RFC 3265, Session Initiation Protocol (SIP) Specific Event Notification,IETF, June 2002.

[8] Slutsman, L., I. Faynberg, and M. Weissman, RFC 3136, The SPIRITS Architecture, IETF,June 2001.

[9] Sparks, R., RFC 3515, The Session Initiation Protocol (SIP) Refer Method, IETF, April2003.

[10] Lu, H., RFC 2995, Pre-SPIRITS Implementation of PSTN-Initiated Services, IETF,November 2000.

[11] Faynberg, I., et al., RFC 3298, Service in the Public Switched Telephone/Intelligent Net-work (PSTN/IN) Requesting Internet Service (SPIRITS) Protocol Requirements, IETF,August 2002.

[12] Price, R., et al., RFC 3320, Signaling Compression (SigComp), IETF, January 2003.[13] Garcia-Martin, M., RFC 3485, The Session Initiation Protocol (SIP) and Session Descrip-

tion Protocol (SDP) Static Dictionary for Signaling Compression (SigComp), IETF, Febru-ary 2003.

[14] Camarillo, G., RFC 3486, Compressing the Session Initiation Protocol (SIP), IETF, Febru-ary 2003.

[15] Calhoun, P., et al., RFC 3588, Diameter Base Protocol, IETF, September 2003.[16] TS 23.228, IP Multimedia Subsystem (IMS); Stage 2, 3GPP.[17] TS 23.218, IP Multimedia (IM) Session Handling; IM Call Model; Stage 2, 3GPP.[18] TS 23.278, Customised Applications for Mobile Network Enhanced Logic (CAMEL)—

Stage 2; IM CN Interworking, 3GPP.[19] TS 29.2787, Customised Applications for Mobile Network Enhanced Logic (CAMEL)

CAMEL Application Part (CAP) Specification for IP Multimedia Subsytem (IMS), 3GPP.[20] Garcia-Martin, E. Henrikson, and D. Mills, RFC 3455, Private Header (P-Header) Exten-

sions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project(3GPP), IETF, January 2003.

[21] Camarillo, G., W. Marshall, and J. Rosenberg, RFC 3312, Integration of Resource Man-agement and Session Initiation Protocol (SIP), IETF, October 2002.

[22] TS 24.229, IP Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP)and Session Description Protocol (SDP); Stage 3, 3GPP.

[23] TS 24.228, Signalling Flows for the IP Multimedia Call Control Based on SIP and SDP;Stage 3, 3GPP.6

13.9 Further Reading 197

[24] TS 23.040, Technical Realization of the Short Message Service (SMS); Stage 2, 3GPP.[25] TS 29.002, Mobile Application Part, 3GPP.[26] Zuidweg, Next Generation Intelligent Networks, Norwood: Artech House, 2002.[27] Christenson, G., P. Florack, and R. Duncan, Wireless Intelligent Networking, Norwood,

MA: Artech House, 2000.


C H A P T E R 1 4

Properties of Circuit-Switched Networks

In this brief chapter, we take a look at the features and functionalities of today’spublic telephone networks. Where appropriate, we compare and contrast PSTN/PLMN traditions and design goals with those of data networks. The gist of the dis-cussion is this: the world’s PSTN/PLMN infrastructure does what it was designed todo on a truly enormous scale. Naturally, packet telephony will be compared withtoday’s telco networks; this means that “the bar is set very high.”

By and large, data networking gear is not built to the same reliability standardas telco equipment. To be fair, data networking equipment also does what it wasdesigned to do. We are pointing out, however, that data networking gear has nottraditionally been designed to provide “five 9’s” reliability (or, for that matter, toprovide real-time services).

To a significant degree, telcos are positioned as public utilities; surely this is abig reason why telco networks are designed to such a high level of reliability. Per-haps our experience coincides with that of many readers: when our PC breaks, weuse the telephone to call the help desk.

14.1 Telco Routing and Traffic Engineering

The term traffic engineering refers to network dimensioning. For the most part wewill think of traffic engineering as a decision process for which the main inputs aretraffic forecasts and the outputs are transmission link capacities.

In this section, we turn our attention to circuit-switched networks. Based on theexpected volume of traffic, the network topology, and the rules that will be used toroute the traffic, there is a well-developed methodology for determining link capaci-ties to meet a target blocking probability. (When the network cannot complete a callbecause it cannot find idle transmission capacity along any of its candidate routes,we say that the call is blocked.) This begs the question “How are the network topol-ogy and routing rules determined?” Let us assume for the time being that our net-work topology is fixed. We now undertake an overview of routing with a mindtoward understanding the bearer plane’s traffic dynamics. In a nutshell, the lack ofrouting flexibility conspires with a certain predictability in offered traffic patterns.This confluence makes it possible to determine “how much network to build” witha remarkable degree of accuracy. In other words, routing and dimensioning gotogether. For readers who want more information, we recommend Girard’s book[1]. We also note that Ash’s encyclopedic book [2] describes the evolution of telco

199

routing in great detail and offers a useful discussion of trunk reservation (seeSection 14.1.2).

Traditional telco routing is fixed—switch routing tables are configured manu-ally. When a call is placed, the caller’s serving switch proceeds through a static list ofrouting table entries in a fixed order until the call is successfully completed or the listis exhausted. In many, if not most, cases, this list is short—in the United States, twoor three entries is fairly typical for local calls. (Selection of routing table entries isbased on the called party’s number.)

Traditional telco routing is also hierarchical. At the bottom of the hierarchy areso-called end office switches—these are the switches that directly serve end users. Iftwo end office switches are directly connected, then this is the preferred routingoption. If (and only if) no direct channel is available, the originating end officeswitch goes up the hierarchy to a so-called tandem switch. (To make sense of thename, one can think of a tandem switch as “lashing together” pairs of switches thatare lower in the hierarchy.) If the call cannot be completed via this tandem switch, anattempt might be made via another tandem switch. If the latter attempt also fails, thecall is blocked (at which point the originating end office switch will send a “fastbusy” signal).

This description typifies routing of local calls in the United States, where localcarriers’ networks have two-layer hierarchies (consisting of end office switches andtandem switches that connect directly to these end office switches. We will refer tosuch tandem switches as local tandems.) Local carriers still employ fixed hierarchi-cal routing today.

Long-distance routing has become more sophisticated in the last 20 years. Let usfirst discuss the fixed hierarchical routing that was universal until the 1980s. Takenas a whole, the U.S. telephone infrastructure was designed as a five-layer hierarchy.The typical pattern was that two switches could be directly connected if they were,at most, one layer apart in the hierarchy. Thus, a call that needed to go up the hierar-chy would do so one layer at a time: the bearer path would consist of a trunk fromthe originating end office switch to a local tandem, a trunk from the local tandem toa long distance tandem residing in the middle of the five-layer hierarchy, and so on.Switches at the top two layers of the hierarchy did not directly connect to end officeor local tandem switches.

Nowadays, the largest long-distance carriers implement dynamic routingschemes and the rigid five-layer hierarchy is no longer ubiquitous. Before discussingsome of the challenges of dynamic routing, we note that telco routing is static inanother way: once a call is set up, voice samples follow the same path throughout thelife of the call. As we have seen, this also contrasts with traditional IP routing.

14.1.1 Truitt’s Model

Consider the simple network depicted in Figure 14.1. In this section, we assumethat switches A and C are end office switches; switch B is a tandem switch. To carrythe A-C offered load, what is the optimal dimensioning of the A-C and A-B trans-mission links?

Here the A-C offered load is the stream of setup requests for calls originating atswitch A and terminating at switch C, or vice versa. Note that, for purposes of

200 Properties of Circuit-Switched Networks

dimensioning, it does not matter which of the two switches originates the callattempt; for ease of exposition, we can assume that all calls originate at switch A.Moreover, the problem is symmetric: an A-C call traverses the A-B link if and only ifit also traverses the B-C link. So these two links carry an equal proportion of theA-C offered load.

It stands to reason that one hop is better than two: calls that are carried directlyon the A-C link consume resources on only one transmission link (and only twoswitches), so the direct connection is generally preferred. Therefore any incomingcall attempt that can be served on the A-C link will be served on the A-C link. Whencapacity on the A-C link is saturated, incoming call attempts will overflow to theA-B link; whenever the latter is also saturated, calls will be blocked.

Let us make a semiformal statement of the problem at hand by saying that:

• The objective is to minimize cost (or some “proxy” for cost).• The constraint is that we must not exceed a target blocking probability. In lan-

dline networks, the target blocking probability is usually 1% in the busy hour.For wireless networks, 2% is typical. For the sake of definiteness we willassume 1% for the remainder of this section.

Now if A and C were truly the only end office switches in the network, it wouldalways be cheaper to add capacity on the A-C link than on the A-B and B-C links.What we are really trying to do here is decompose a larger problem and work on atractable subproblem: suppose that, for each End Office switch X not shown inFigure 14.1, the capacities of the A-X and C-X links are held fixed. Moreover, over-flow traffic from the A-X offered load is carried on the A-B link (and similarly forthe C-X offered load and the C-B link). Recall that we are discussing fixed hierarchi-cal routing in this section—End Office switches never play a tandem role; all over-flow traffic goes through switch B.

With this reasoning in the back of our minds, it really does make sense to askwhether it is cheaper to satisfy the A-C load by adding capacity on the direct route,or instead by adding capacity on the tandem route. Suppose that, starting with asmall number of A-C trunks, we decide to add trunks until the blocking probabilitysatisfies the constraint. Up to a certain point (10% blocking, say), the number oftrunks required does not seem unreasonable. But “grinding out” another order ofmagnitude (i.e., going from 0.1 to .01) proves to be quite expensive and we begin tolose our resolve.

The trouble is that, at this point, the overflow process is a relative trickle com-pared to the original offered load. A-C offered load is the only traffic that can use

14.1 Telco Routing and Traffic Engineering 201

Switch CSwitch A

Switch B

Figure 14.1 Topology for discussion of Truitt’s model.

the A-C direct link; if we add enough capacity to reach the target blocking probabil-ity, we find that utilization on the direct link is poor.

Why is it more attractive to add capacity to the A-B and B-C links? There, we areable to realize “economies of scale,” so to speak, stemming from the fact that manyoverflow traffic streams are also carried on these links. Individually, the trafficintensities of the overflow streams may be quite small. When there are many endoffice switches, however, the traffic intensity of their superposition is “big enough tobe worthwhile.”

The foregoing discussion begs the question: where is the crossover point? Thatis, where does it cease becoming cost effective to add capacity along the direct route?Truitt conducted a detailed analysis of this problem [3]. In this context, the topologyof Figure 14.1 is often called Truitt’s triangle. Similar reasoning can be used todetermine whether the A-C offered load is sufficient to warrant any dedicated A-Ccapacity at all. Truitt’s work is an enormously influential foundation in telcotraffic engineering: in his voluminous book [2], Ash states that variants of Truitt’sideas appear throughout.

14.1.2 Dynamic Nonhierarchical Routing, Metastable States, and TrunkReservation

In a network with fixed hierarchical routing, calls may be blocked even when suffi-cient capacity is available. This is because the switches do not have the flexibility toexploit available transmission capacity unless that capacity happens to lie alongroutes specified in preplanned routing tables. Thus the motivation for dynamic rout-ing is simple enough: if capacity is available, let us find it and use it, rather thanblocking calls unnecessarily.

If it is implemented in a simple-minded way, dynamic routing introduces a fewnew problems. In a broad sense, routing and therefore capacity utilization is lesspredictable than in the old fixed hierarchical approach. Blocking probabilitiescan actually go up when dynamic routing is introduced. As a plausibility argumentfor this point, we again use the simplistic network topology of Figure 14.1. How-ever, let us:

• Drop the assumption that B is a tandem switch.• Add an assumption that each of the three transmission links in the figure has a

100-trunk capacity.

In this network, there are two possible bearer paths for each pair of switches;one is direct and the other goes through the third switch. For example, a call con-necting switches A and B can either go through C (we will call this the alternateroute) or not (the primary route). Consider the following two network states:

• 300 calls are active: 100 on the A-B primary route, 100 on the B-C primaryroute, and the remaining 100 on the A-C primary route.

• 150 calls are active: 50 on the A-B alternate route, 50 on the B-C alternateroute, and the remaining 50 on the A-C alternate route.


In both cases, our network’s transmission capacity is completely saturated. Thefirst scenario is far preferable to the second; in it, the network is able to carry twiceas many calls. The trouble with the second scenario is that calls borne on alternateroutes consume more resources than calls on primary routes. This general problemis not unique to the oversimplified scenario at hand.

A network state with a high percentage of alternate-routed calls is sometimescalled a metastable state. When a network finds itself in a metastable state, it maytake a substantial amount of time to get out of that state. To explain why this is thecase, consider the following state in our example network: 50 calls are active on theB-C alternate route and another 50 calls are active on the A-B alternate route.Transmission capacity on the A-C link is saturated with alternate-routed calls. If anA-C call comes along, it will have to be borne along the alternate route. Althoughthis example is simplistic, it illustrates the general metastable phenomenon: thepresence of many alternate-routed calls increases the probability that newly arrivingcall requests must also be served on alternate routes. Note that the scenariodescribed here would not occur if switch B was a local tandem, whereas switches Aand C were end office switches. Connections between switches B and C would neverpass through switch A, since switch A never plays a tandem role. Similarly, A-B con-nections would never pass through switch C. In fact, metastable states do not pres-ent a problem in networks with fixed hierarchical routing.

In networks with dynamic routing, how can we avoid metastable states? Look-ing back at the previous example, some of the capacity on the A-C link should havebeen reserved for A-C calls. At the very least, the alternate-routed call that con-sumed the last A-C trunk should have been blocked instead. This is the notion oftrunk reservation. This topic is much discussed in the literature on telephone net-works; empirical evidence, simulation studies and rigorous results in the mathe-matical literature on loss networks have firmly established the usefulness of trunkreservation, and addressed the question “how many trunks should be reserved?”Examples of the rigorous mathematical variety include work of Kelly [4], Mitra andSeery [5], and Nguyen [6].

14.1.3 Optional Section: Traffic Intensity and the Erlang B Formula

Traffic engineering topics such as those introduced in Sections 14.1.1 and 14.1.2have been studied extensively, resulting in rich mathematical modeling literature. Inthis section, we outline the derivation of the Erlang B formula—one of the essentialbuilding blocks in this subject area. We also mention adaptations to the basic for-mula and give references for further reading. The mathematical content presentedhere, which may not be to every reader’s taste, is not a prerequisite for any otherpart of this book.

Suppose setup requests arrive at a rate of λ calls per unit time and that the aver-age call duration is 1/µ units of time. Then the ratio λ/µ is called the traffic intensity.We say that the load on the system is λ/µ Erlangs. Traffic intensity, being the prod-uct of a rate and a time, is a dimensionless quantity. If we pretend that the systemhas infinite capacity (so that no calls are ever blocked), then λ/µ is the steady-statemean number of calls in progress at any given time.

14.1 Telco Routing and Traffic Engineering 203

Erlang computed the blocking probability for a system with the capacity for Nsimultaneous calls, given a traffic intensity of λ/µ. (All probabilities discussed hereare steady-state probabilities.)

Erlang assumed that the system was memoryless. (For readers unfamiliar withprobability theory, this means the following: although probabilities of future eventsdepend on the current state of the system, they are completely independent of pastevents—the path that the system took to get into this state is irrelevant. For readerswell versed in probability, it means that call holding times are independent identi-cally distributed exponential random variables, call interarrival times are also inde-pendent identically distributed exponential random variables, and moreover thatthe holding times and interarrival times are independent of one another.)

Let pk be the probability that there are exactly k calls in progress for k = 0,1,...,N(recall that N is the capacity of the system). Then for 1≤k≤N we can relate pk−1 andpk as follows: in steady state,

transition rate Sk−1 → Sk = transition rate S Sk k→ −1

where Sk is the state of having k active calls in the system. The left-hand side of theequation is λpk−1 regardless of the value of k (simply because calls arrive at rate λ).Regarding the right-hand side of the equation: the departure rate of calls is propor-tional to the number of active calls and is inversely proportional to the mean holdingtime 1/µ. Putting it all together, we have λpk−1 = kµpk; this recursion, along with thefact that the probabilities must sum to 1, leads to the celebrated formula

pN

kN

kN k

==∑

ρ

ρ

Ν !

!0

where ρ = λ/µ. Since an incoming call is blocked if and only if the system is operatingat full capacity, pN is in fact the blocking probability.

How realistic were Erlang’s assumptions? For a large population of userswho act independently of one another, a memoryless arrival process (this is alsocalled a Poisson arrival process) is a reasonable model. The assumption that thedeparture process is also memoryless is less intuitive (at least to us). It turns out,however, that calculations based on this assumption are still reasonable in practice.A famous theorem in queuing theory says that Poisson Arrivals See Time Averages,suggesting that system dynamics may not be terribly sensitive to deviations inthis regard.

The Erlang B formula is not perfect, however. We have tacitly assumed that,even though there is variability in the arrival process, the arrival rate itself is con-stant. Certainly this is not true in practice. Hill and Neal [7] showed how anErlang-based model could be adjusted for day-to-day variation in traffic load.Another important consideration is this: although the load that is offered to a directlink (e.g., the A-C link in the example of Section 14.1.1) may be characterizedby a memoryless arrival process, the overflow traffic is definitely not memoryless.This and other topics in this section are afforded careful treatment in Wolff’s queu-ing theory book [8].


14.2 Comparison with IP Routing and Dimensioning

It is already quite clear (by comparing the exposition of the previous section withSection 7.5’s discussion of IP routing) that IP routing and telco routing are quite dif-ferent. Here we add the following comments:

• Suppose that an IP bearer path fluctuates during the life of a call. Then, at thevery least, significant jitter is likely to result. Moreover, packets can arrive attheir destination out of order. If this happens with any regularity, it wreakshavoc on real-time applications, which cannot be expected to deal with reor-dering. MPLS can be employed to provide path stability.

• Stability is prized in the telco environment, and telco routing schemes reflectthat. In fixed hierarchical routing, a modest number of routes is typicallyavailable for each originating-terminating pair of switches. Calls that exhausttheir collection of candidate routes are blocked. As a result, a spike in callattempts for one switch pair has a limited effect on the rest of the network.Moreover, circuit switches implement so-called gapping to cope with intensebursts of activity (for example, if many people rush to call a radio station inresponse to a promotion, the serving switch does not try to process every callrequest, thereby allowing it to react gracefully to overflow conditions. Manycallers are unable to get through, of course, but the sudden spate of calls doesnot knock down the switch). We have also seen that long-distance carriersemploy trunk reservation to lend stability to dynamic routing schemes.

While there are schemes to avoid hysteresis in the data networking realm,we believe it is fair to say that IP networks do not typically offer the stabilityguarantees of their circuit-switched counterparts. To the best of our knowl-edge, there is no widely deployed analog of trunk reservation in IP networking(although one could argue that, with the advent of MPLS, such a thing is war-ranted: in an MPLS domain, a VoIP bearer path is likely to remain constantthroughout the life of a call).

• There is no simple way to dimension independently for bearer and controltraffic in IP networks because the two types of traffic are not systematicallysegregated. Note that there may still be a logical separation of bearer and con-trol and some degree of physical separation (e.g., bearer traffic may not flowthrough SIP proxies). Contrast this with circuit-switched domains: SS7 signal-ing traffic and TDM bearer traffic are carried on different networks. Amongother things, this means that the two networks can be dimensioned independ-ently. The optimization problems faced in dimensioning circuit-switcheddomains are therefore fundamentally simpler than in IP networks.

• In IP networks, the same routing protocols are applied to signaling and bearertraffic (excepting the signaling that drives the routing protocols themselves.)In circuit-switched networks, SS7 traffic is routed independently of bearertraffic. IP routing protocols are, in our opinion, far superior to SS7’s routingscheme.

• The upshot of Section 14.1 is that telco transmission links are dimensionedaccording to mathematical formulae. There is a well-established methodology

14.2 Comparison with IP Routing and Dimensioning 205

that tells traffic engineers when and where to add capacity. Telcos have alsoexplored “time of day” routing schemes to take advantage of noncoincidentbusy hours. When chronic congestion occurs in IP networks, the typical solu-tion is to “throw bandwidth at the problem.” That is, network engineers typi-cally add transmission capacity in a relatively ad hoc manner to relieve routinghot spots; they may adjust load balancing parameters. But they have far lessformal methodology to rely on than their telco counterparts.

14.3 Security

We have seen that SS7 networks interconnect voice switches with one another, andwith service control points, using signaling transfer points. SS7 networks essentiallyconnect to nothing else (except for low-level hardware such as digital cross-connectsystems). In particular, SS7 signaling does not extend to end users. The result is avery secure environment: How can you hack a network that you cannot touch? Wesay that SS7 networks have physical security. This is a big part of the reason why onenever hears of a virus attack on a PSTN.

Some telephone traffic is already carried over the public Internet; no doubtthis will continue. However the public Internet is much less secure than thetraditional telco environment. For this and other reasons, we believe that carriers’packet voice offerings will be realized, to a significant degree, over private datanetworks.

14.4 Quality of Service

QoS is another reason to deploy private data networks in support of packet teleph-ony. The public Internet follows a best-effort service model in which there is noadmission control. Admission control is essential for any network that provides QoSguarantees. That is, incoming call requests must be refused whenever the networkdetermines that it does not have enough available resources to meet its QoSobjectives.

We have seen that wireline telcos engineer their networks to meet blockingprobability objectives. Whenever a call setup is successful, resources are reservedalong an end-to-end bearer path, so QoS is not a problem. Wireless networks alsoengineer to blocking probability objectives. A wireless telco that is meeting its block-ing probability objectives may still have to upgrade its cell sites if customers experi-ence a high rate of dropped calls. But by and large, the arrangement is similar to thatof wireline networks: if a call attempt is successful, reserved bandwidth is available(end to end) throughout the life of the call.

Today’s corporate customers demand that their service providers enter intoformal service level agreements. Initially, service-level agreements primarily cov-ered data services, but they are starting to incorporate performance requirementsfor packet voice. This in turn means that service providers must have a way toguarantee that sufficient resources are available to maintain “toll quality” voiceservice.


14.5 Scalability

Telephony is, of course, deployed on a very large scale. Although we might arguethat people with telephone service still outnumber those with Internet service, thegap has certainly narrowed in recent years; the public Internet is no longer orders ofmagnitude smaller than the world’s telephone infrastructure. In circuit-switchedand packet-switched networking, there is (justifiably) a big emphasis on technolo-gies that are adaptable to very large subscriber populations.

14.6 Survivability and Reliability

For our purposes, a reliable network is a network that functions normally the vastmajority of the time. A survivable network is one that can continue to function,albeit at reduced capacity, even if disastrous things happen to isolated componentswithin the network.

Today’s telephone networks are extremely reliable. Typically, PSTN/PLMNinfrastructure is designed for “five 9’s” availability; this means that the network isable to complete calls, as in normal operation, 99.999% of the time. Core net-work equipment designs incorporate redundancy throughout: dual power supplies,backup storage, backup processors, “working” and “protect” switching fabrics,working/protect port pairs on line cards, and so on.

The study of reliability involves measures such as mean time between failureand mean time to repair. Reliability is a branch of applied probability and, as such,has a robust mathematical framework associated with it. The interested reader canconsult a textbook on reliability; for those new to the subject, the book by Billintonand Allan [9] is a good starting point. More rigorous mathematical treatments canbe found in [10–12].

To implement a survivable network, it is important to avoid single points of fail-ure in critical systems. We saw an example of this in Chapter 8 when we talkedabout mated pairs of STPs. Fiber-optic deployments commonly feature diverse“working” and “protect” paths. If, for example, a backhoe ruptures a fiber-opticlink, the outage is quickly detected and the system switches to the “protect” path.

For many data networking equipment manufacturers, the enterprise market iskey. The cost/benefit “equation” for enterprise networks traditionally has notfavored telco-grade reliability. However, redundant fiber-optic links are used forwide area network transport of data traffic as well as voice traffic. Moreover, asdata networking has become increasingly critical to corporations, outages are verydisruptive when they do occur. So reliability and survivability requirements arebecoming more important, especially for core routers, Ethernet technologies formetropolitan area networks, and so on.

14.7 Billing Functionality

The telco environment requires complex billing systems—voice switches generatecharging data records on a per-call basis. Why is this necessary? Such records arevital to the settlement process in which long distance carriers pay access charges to

14.5 Scalability 207

local exchange carriers (at least in the United States). Wireless carriers pay roamingcharges to one another; they also pay for the use of long-distance networks. Again,carriers “settle up” based on analysis of per-call records.

Traditionally, data networks have not featured such complex billing infrastruc-tures (nor have cable companies, for that matter). Why are flat-rate cable televisionand Internet services so common? Surely market drivers are one reason, but they arenot the only reason: it is far simpler and cheaper to implement a flat-rate billing sys-tem than it is to create and manage detailed use logs.

14.8 Emergency Service and other Government Mandates

Telcos are regulated; at this point, it is not yet clear whether packet telephony will beregulated to a similar degree. In the United States, regulatory mandates include:

• Emergency services. This includes technology that allows emergency person-nel to locate wireless callers. The US government also contracts with telcos toprovide special priority call handling for government officials in the event of anational emergency.

• Lawful interception. Telcos are required to provide surveillance access to lawenforcement personnel.

References

[1] Girard, A., Routing and Dimension in Circuit-Switched Networks, Reading, MA:Addison-Wesley, 1990.

[2] Ash, G. R., Dynamic Routing in Telecommunications Networks, New York: McGraw-Hill,1997.

[3] Truitt, C. J., “Traffic Engineering Techniques for Determining Trunk Requirements inAlternate Routed Networks,” Bell System Technical Journal, Vol. 31. No. 2, March 1954.

[4] Kelly, F. P., “Routing and Capacity Allocation in Networks With Trunk Reservation,”Mathematics of Operations Research, Vol. 15, November 1990, pp. 771–793.

[5] Mitra, D., and J. B. Seery, “Comparative Evaluations of Randomized and Dynamic RoutingStrategies for Circuit–Switched Networks,” IEEE Transactions on Communications, Janu-ary 1991, pp. 102–116.

[6] Nguyen, V., “On the Optimality of Trunk Reservation in Overflow Processes,” Probabilityand Engineering in the Mathematical Sciences, Vol. 5, 1991, pp. 369–390.

[7] Hill, D. W., and S. R. Neal, “The Traffic Capacity of a Probability Engineered TrunkGroup,” Bell System Technical Journal, Vol. 55, No. 7, 1976.

[8] Wolff, R. W., Stochastic Modeling and the Theory of Queues, Englewood Cliffs, NJ:Prentice-Hall, 1989.

[9] Billington, R., and R. N. Allan, Reliability Evaluation of Engineering Systems–Conceptsand Techniques, 2nd ed., New York: Plenum Press, 1992.

[10] Ascher, H., and H. Feigold, Repariable Systems Reliability: Modeling, Inference, Miscon-ceptinos, and Their Causes, New York: Marcel Dekker, 1984.

[11] Barlow, R. E., Engineering Reliability, Society for Industrial and Applied Mathematics,1998, AMS–SIAM Series on Statistics and Applied Probability 2.

[12] Lawless, J. F., Statistical Models and Methods for Lifetime Data, 2nd ed., New York, Lon-don: John Wiley and Sons, December 2002.


C H A P T E R 1 5

Evolving Toward Carrier-Grade PacketVoice: Recent and OngoingDevelopments

The telecommunications industry does appear poised to move toward packettelephony on a large scale. Historically, the IETF has been the standards body for allthings IP. But pieces of the carrier grade puzzle have been missing from the “IETFtoolbox.” Despite this fact, Voice over IP has significant momentum in the industry.(For thoughts on this trend, see Section A.3.7 in the appendix.)

The missing pieces of the puzzle have received a great deal of attention over thelast several years. Activity in the standards arena has not been limited to the IETF. Inthis chapter, we take stock of developments in the following areas:

• QoS and traffic engineering;• Billing;• Interworking with circuit-switched domains.

We also discuss IPv6, header compression, and middlebox traversal.

15.1 QoS and Traffic Engineering in IP Networks

QoS support in IP networks entails many things; there is no simple taxonomy ofrequirements. Class-based queuing is a reasonable starting point because it is neces-sary at every IP router along the data path. After covering class-based queuing, webranch out into other requirements associated with routing and signaling. Next welook at techniques for verifying and enforcing traffic contracts.

We then discuss standardized QoS performance measures. Finally, we look atinterworking between networks that adhere to different performance standards.

15.1.1 Class-Based Queuing

To support QoS, IP routers must implement some sort of class-based queuing. Thismeans that

• Incoming packets must be classified. Potential classification criteria includesource addresses, destination addresses, port numbers, protocol identifiers,and application layer information.

209

• Routers must subdivide their buffer capacity between the traffic classes (i.e.,maintain separate input and/or output queues).

• Routers must employ queue scheduling schemes that meet the requirements ofthe traffic classes.

Common families of scheduling algorithms include the following:

• Round-robin. The name is self-explanatory.• Priority queuing. If the traffic type for queue A has higher priority than that of

queue B and queue A is nonempty, then queue A is served. This affords verylow latency for the highest-priority queue(s), but traffic types that are “furtherdown the food chain” suffer starvation during periods of resource contention.

• Weighted fair queuing (WFQ). Each queue has a preassigned proportion ofavailable output bandwidth. The idea of weighted fair queuing is this: over anytime period, each queue is served according to its assigned proportion. Ofcourse, this is only possible in a fluid flow model (think of very short timeintervals); packets are certainly not infinitely divisible. So approximations arenecessary; because of ATM’s fixed cell length, good WFQ approximations areeasier to come by in ATM switches than in IP routers.

How fair can you be if there is extreme variability in packet length? Note thatfairness is reckoned in terms of throughput (e.g., megabits) rather than in number ofpackets. Note also that it is easier to approximate fairness on high-speed links(which are typical in large network cores) than on low-speed links: it takes very littletime for a router to “clock out” a packet on a high-speed link, even if that packetis large.

Not every scheme fits cleanly into this taxonomy. In the literature, one can findany number of articles proposing queue scheduling algorithms; many authors alsodefine measures of fairness. Examples include [1–8]. In selecting a scheduling algo-rithm, each router manufacturer must analyze the trade-off between desirable fair-ness properties and computational complexity.

15.1.2 DiffServ and IntServ Revisited

We described the two main IP QoS approaches, DiffServ and IntServ, in Section 7.7.Both require class-based queuing, but the granularities involved are very different.

Recall that DiffServ routers implement PHBs; PHBs are selected based on theDSCPs in the IP headers. Routers maintain separate ingress and/or egress queues foreach DSCP. Depending on the sophistication of the scheduling algorithm, the imple-mentation challenges may still be significant. Note, however, that the number ofqueues that have to be maintained remains constant even as the number of concur-rent data sessions grows. This is an attractive feature, but we point out that DiffServcannot offer “hard” QoS guarantees (at least not by itself). Since packets are markedat ingress to a DiffServ domain, the task of classification at each intermediate routerboils down to simply checking DSCPs.

To achieve quantifiable and reliable QoS for delay-sensitive applications, admis-sion control and resource allocation are necessary. Recall that IntServ is based

210 Evolving Toward Carrier-Grade Packet Voice: Recent and Ongoing Developments

on explicit resource reservation. Initially, IntServ’s intended use was per-sessionresource allocation, with RSVP [9] as the signaling vehicle. In this scenario, the clas-sification task performed at domain ingress must be repeated at each hop. Due toscalability concerns, however, the IntServ model is rarely implemented end-to-endon a per-session basis. We remark here that it is possible to conduct per sessionresource allocation on a large scale: the world’s PSTN/PLMN infrastructure is livingproof. However, we do take the point that it is counterproductive to attempt thisapproach on, say, 2.4 Gbit/s links between core IP routers. Routers interconnectedby such a link would have to maintain queues for an enormous number of sessions(implying that state variables would not only have to be maintained, but that instan-tiation and destruction of these state variables would have to be managed bysignaling).

RSVP was later extended for use with MPLS [10], which offers a way to“carve up” buffer and bandwidth resources in an IP domain. A second approach,Constraint-Based Routed Label Distribution Protocol (CR-LDP) [11], also cameout of the MPLS Working Group. (MPLS was introduced in Section 7.7.3; see thatsection for additional references.)

Deployment Options

For “hard” QoS, IntServ can be employed at the edge, with MPLS in the core. MPLSLSPs would not normally be allocated to serve individual sessions. Instead, each LSPwould aggregate many session flows. The ability to merge traffic streams as theytravel from ingress to core is a crucial capability in MPLS. In situations where“hard” QoS guarantees are not required, DiffServ at the edge/MPLS in the core is aneffective combination. The choice between IntServ/MPLS and DiffServ/MPLS com-binations may depend on access-network bandwidth. For example, the IntServmodel appears in the 3GPP specifications. This is not surprising: access-networkbandwidth is a scarce resource for wireless carriers, since it consumes licensedspectrum. DiffServ may be a more common option in LAN environments.

For softswitch deployments, MPLS is an attractive option for connectivitybetween Media Gateways. IP and/or Label Switched Routers within softswitch fab-rics may be dedicated to their softswitch roles in many carrier grade deployments, atleast in the early years. That is, service providers may not rush to carry large vol-umes of TCP/IP data traffic on the selfsame routers—traffic engineering is signifi-cantly easier in the absence of bursty data networking applications. DiffServ andpossibly IntServ will be used to manage bandwidth between Media Gateways andIP phones.

Constraint-Based Routing

In QoS enabled IP routers, not all traffic is treated the same. This is the idea behindclass-based queuing. In QoS-enabled IP networks, it might make sense to route traf-fic according to its QoS requirements.

More generally, the notion of constraint-based routing is that constraints mightvary with the type of traffic. Rather than basing routing decisions purely on standardlink metrics, additional criteria might be taken into account. QoS routing is a specialcase of constraint-based routing; policy-based routing is another special case.

15.1 QoS and Traffic Engineering in IP Networks 211

Although it is certainly not a new idea, it is unclear whether there will be awidely deployed consensus approach to constraint-based routing. Constraint-basedrouting has made its way into the standards, at least: see CR-LDP [11], or OSPF’straffic engineering extensions [12], for instance. Note also that RSVP-Traffic Engi-neering (RSVP-TE) [10] defines an EXPLICIT_ROUTE object.

15.1.3 Verifying and Enforcing Traffic Contracts

Corporate customers increasingly want to multiplex voice, video, and traditionalbursty data traffic on their access links (i.e., the links that connect to WAN serviceproviders). These customers, in order to make sure they are getting their money’sworth, want service providers to quantify network performance. By the same token,service providers need to know how much traffic their customers are actually inject-ing into their networks. So metering and performance reporting capabilities arerequired by both sides.

Moreover, service providers may want to police and/or shape incoming traffic tomake their networks less prone to congestion. Policing means discarding trafficwhen its rate exceeds the contracted rate. (A customer may have a very fast accesslink to a service provider’s network but only have the contractual right to run thatlink at high utilization for short periods of time.) Discards can take place at networkingress. There is also a less-severe variant in which “excess” traffic is marked forpotential discard. If an intermediate network element experiences congestion, itknows which packets to discard first.

Traffic shaping refers to techniques that groom ingress traffic. One well-knownapproach to shaping is the so-called token bucket. Tokens stream into the bucket ata specified rate. A packet that arrives at network ingress is only allowed to pass ifand when enough tokens are available to “escort” the packet (at which point thetokens are destroyed; the number of tokens required is usually prorated according topacket size). Tokens that overflow the bucket are discarded. The parameters for atoken bucket are its size (i.e., how many tokens can it hold) and the token rate.

As long as tokens are available, a token bucket allows traffic to enter the net-work at wire speed. Often it is desirable to remove some of the burstiness from atraffic source. One can employ a leaky bucket for this purpose. A leaky bucketadmits packets into the network at a fixed bit rate. When packets arrive at thebucket faster than the prescribed rate, they wait in the bucket—provided that thereis room. Otherwise, they are discarded. Buckets of one or both types are often usedin series.

15.1.4 ITU-T and 3GPP QoS Standards

We have talked about techniques for providing QoS. Using these techniques, whatkind of performance can one expect? On one hand, we could look at the perform-ance that is possible with today’s “QoS aware” routers. Or we could take arequirements approach instead: What performance targets must be met for a givenapplication to function properly? We hope the two approaches lead to a commonground of performance measures that are achievable and also consistent with a posi-tive user experience.


Mindful of this philosophy, ITU-T Study Group 13 has authored recommenda-tions on IP QoS. Recommendation Y.1540 [13] defines the following performanceparameters: IP packet transfer delay (IPTD), delay variation (IPDV), loss ratio(IPLR), error ratio (IPER) and spurious IP packet rate (SIPR). A companion recom-mendation, Y.1541 [14], specifies end-to-end target values for five QoS classes. Asixth QoS class is for “best-effort” service: no quantified performance targets areassigned to this class.

The values for IPTD and IPDV appear in Table 15.1. For each of the classes 0-4,the upper bound for IPLR is 10−3 and the upper bound for IPER is 10−4. SIPR is notquantified for any of the traffic classes. Class 5 is the best-effort class previouslymentioned.

How can a service provider meet the specified performance targets? Recom-mendation Y.1541 does not place any restrictions in this regard. However, it doesgive examples of node and network mechanisms that could be used to deliver thespecified QoS:

• For classes 0 and 1 (which are the only classes that place limits on delay varia-tion): queues with preferential servicing, coupled with traffic grooming, maybe necessary. Note that these mechanisms are implemented in the nodes.Interactive VoIP and video conferencing applications are sensitive to jitter aswell as delay, so they require this sort of QoS to function properly. Althoughclass 1 is less than ideal here, the idea is that such services should still be usablein less-favorable delay conditions so long as jitter is minimal.

• For classes 0 and 2 (which are the classes with the most stringent delaybounds), routing is constrained: large distances and/or high hop countsmake it difficult if not impossible to meet the delay requirements. Thus, lowlatency requires network-level mechanisms; contrast this with the node-basedqueuing techniques mentioned in the previous bullet. For high volume trans-actional applications, latency is likely to be important (since low-latencyperformance in the signaling plane helps keep the number of in-progresstransactions from getting out of hand), but delay variation does not matter somuch. Class 2 is aimed at supporting such applications.

• QoS class 3 may be sufficient to support transactional applications that areslightly less demanding.

15.1 QoS and Traffic Engineering in IP Networks 213

Table 15.1 ITU-T Performance Objectives

QoS Class Delay Objective:mean IPTD ≤

Delay Variation Objective:10−3 quantile of {IPDV − min(IPDV)}≤

0 100 ms 50 ms1 400 ms 50 ms2 100 ms Unspecified3 400 ms Unspecified4 1 sec Unspecified5 Unspecified Unspecified

• QoS class 4 is intended to support applications, such as video streaming, thatrequire a certain level of reliability (i.e., low loss and error ratios) but are notparticularly sensitive to delay.

Seitz’s overview article [15] does a nice job of summarizing the content ofY.1540 and Y.1541, and discusses ITU-T’s approach to formulating these recom-mendations. ITU-T recommendation Y.1221 [16] is more explicit (than Y.1541)regarding the means of meeting performance objectives. The Y.1221 specificationdefines three transfer capabilities:

• Dedicated bandwidth transfer capability, which can be associated with “spe-cified loss commitments” and “specified delay commitments,” seems to be arepackaging of IETF RFCs 2212 [17] and 2598 [18]. (The actual wording isthat the dedicated bandwidth transfer capability “strives for compatibility”with those RFCs. Note that RFC 2598 is an outdated specification of the expe-dited forwarding per hop behavior; it has been obsoleted by RFC 3246 [19].)

• Statistical bandwidth transfer capability, which can be associated with “speci-fied loss commitments,” seems to be a repackaging of IETF RFCs 2211 [20]and 2597 [21].

• Best Effort transfer capability.

3GPP’s QoS architecture document [22] defines four traffic classes: conversa-tional, streaming, interactive and background. There are significant differencesbetween the 3GPP and ITU-T approaches. First of all, the set of parameters is differ-ent. (We do not go into detail.) Secondly, although specification [22] does mentiondelay variation, it does not prescribe target values. Moreover, the delay specificationis given as a maximum value rather than as a mean. The values are 100 ms for con-versational class and 280 ms for streaming class. For interactive and backgroundclasses, no values are specified.

Performance over the RF interface varies greatly depending on conditions. It istherefore much harder to make performance guarantees than in a wireline environ-ment: quantifying delay variation might have been a case of “going out on a limb.”So it is not surprising that 3GPP was loath to prescribe target values for delay varia-tion. Even in good conditions, the bandwidth of the RF interface is more limitedthan that of its broadband landline counterparts. For this reason, the 3GPP specifi-cations place upper limits on session bandwidth, whereas the ITU-T specificationsdo not.

At this point in time, it is problematic to determine appropriate QoS classes andperformance targets for hybrid wireline-wireless sessions. In addition to the delayvariation issue noted previously, recall that delay itself is specified differently (as amean according to ITU-T but as a maximum in 3GPP). When a connection crossestwo networks, the delay “budget” must be apportioned between the two networksin some way. This is easier to do with a mean than with a maximum. At the time ofthis writing, efforts to standardize mappings between ITU-T and 3GPP QoS classeshad not gotten off the ground.

Before moving on, we point out the following curious difference between theITU-T and 3GPP specifications: the ITU-T delay bound for streaming applications


(mean value no greater than 1 second) is much less stringent than that of 3GPP(maximum value of 280 ms). Streaming is, by definition, half duplex. As a result,users are much less aware of delay than in conversational services. So why does3GPP specify such a tight delay bound? We believe that there is an implicit differ-ence in intended applications: wireless carriers are interested in building interactiveservices (somewhat similar to PoC, say; see Section 13.7.1) that rely on videostreaming.

15.2 Service-Level Agreements and Policy Control

Using the tools and techniques discussed in Sections 15.1.1, 15.1.2, and 15.1.3,service providers can safely enter into meaningful service level agreements. That is,they can enter into contracts that obligate them to meet quantifiable performancemeasures.

What are the economics of the situation? It is probably unrealistic to assumethat service providers will upgrade the QoS-delivery capabilities of their networksunless they have a way to charge customers for higher grades of service (higher thanthat afforded by the traditional best-effort model, that is). Otherwise, there is nomotivation to bear the cost of such upgrades.

Once they have entered into service-level agreements, service providers must“deliver the goods.” So service providers need efficient ways to implement appro-priate policies for access to (and use of) network resources. IETF’s Resource Alloca-tion Protocol (rap) working group has produced a body of work that addresses thisissue. The baseline document [23] specifies the Common Open Policy Server(COPS) protocol. COPS is a multipurpose framework. Its use in the QoS context,using RSVP as the vehicle for resource reservation, is described in [24]. The neces-sary RSVP extensions are defined in [25]. This covers connection admission controlin the “traditional” sense: requests are admitted if and only if adequate networkresources are available.

Policy-based admission control is a more general topic. Among other things, itoffers the flexibility to provide higher grades of service to customers willing to paypremium prices. For example, explicit resource reservation might be available onlyto a provider’s most-valued corporate customers. Or, in terms of the ITU-T QoSstandards of the previous section, classes 0 and 2 might be unavailable to all othercustomers.

Corporations have long interconnected their campuses via leased lines, whichprovide dedicated bandwidth. In this setting, there is no need for service providersto provide per session policy control. Whenever employees are present at theircorporate campuses, they have access to the leased transmission capacity (subject tothe policies implemented by their own information technology departments). Theleased-line business has been a huge “cash cow” for telcos. In this light, we offer thefollowing motivation for policy-based admission control:

• Corporations want to reduce cost by paying only for what they use ratherthan paying for dedicated, 24 × 7 capacity. However, they still want perform-ance guarantees.

15.2 Service-Level Agreements and Policy Control 215

• “Road warriors” are increasingly dependent on mobile access to corporatesystems.

Policy-based admission control is covered in [26]. For more information, theinterested reader can visit the rap working group’s home page.

15.3 SDP and SDPng

SDP [27] was originally designed to support announcement of multicast sessions.Like the original version of SIP (RFC 2543, now obsolete), SDP was produced byIETF’s mmusic working group.

SDP’s developers needed a way for the originator of a multicast session to com-municate session parameters (e.g., codec information) to a population of potentialparticipants. In the intended use, the session announcement would be a one-waything: a potential participant could only become an actual participant if it supportedthe offered session parameters.

Thus, the idea of employing SDP in the course of session parameter negotiationcame after the fact. In our discussions of Megaco, MGCP, and SIP, we have seen thatSDP can in fact be used in this way. However, SDP itself does not explicitly distin-guish between potential session configurations and actual session configurations.

The mmusic Working Group is developing a long-term replacement protocolthat overcomes the limitations of SDP; the new protocol is informally called SDPnext generation, or SDPng. SDPng distinguishes between potential and actual con-figurations. The specification sets forth session parameter negotiation procedures.Unlike SDP descriptions, SDPng descriptions are XML documents.

For details on SDPng, see the latest version of the document titled “SessionDescription and Capability Negotiation.” At the time of this writing, that documentwas an Internet draft in its seventh revision.

The mmusic group is also working on an updated version of the SDP specifica-tion; this was also an Internet draft at the time of this writing. The new version ofSDP will address the most pressing problems with SDP as currently specified. Theseproblems are:

• SDP’s incompatibility with NATs and firewalls;• The need to use SDP with TCP and/or SCTP.

SDPng descriptions tend to be larger than their SDP counterparts, so the lattermay be more attractive to wireless carriers. There is also the matter of SDP’s largeinstalled base.

15.4 Sigtran Adaptation Layers

SCTP [28] is seeing increasingly widespread use for SS7 traffic. Although the SCTPstandard is stable, there is still some flux regarding sigtran adaptation layers. In thissection, we briefly describe the landscape.


With SCTP, it is possible to transport SS7 traffic over an IP bearer rather than atraditional TDM bearer. (It is possible, but not ideal, to transport SS7 traffic overTCP). We covered SCTP, which was produced by IETF’s sigtran working group, inSection 7.8.2. For the following discussion, it may be helpful to refer to Figure 8.3.

SCTP provides a robust option for carrying higher layer protocols (such asISUP, SCCP, TCAP, MAP and ANSI-41) across an IP network. What goes betweenSCTP and the higher layer protocol entity? For compatibility reasons, the fact thatSCTP is now present should be transparent to that entity. The required transpar-ency is achieved by a so-called adaptation layer; the answer to the above questiondepends on where one chooses to put the adaptation layer. Options include:

• M2UA [29]. As the name suggests, M2UA sits between SCTP and MTP3. In asoftswitch, the signaling gateway (SG) may terminate MTP2 on attachedTDM SS7 links, but pass MTP3 (and all of the layers above it) through to themedia gateway controller. On the SG-MGC link, we would have MTP3 overM2UA, which in turn runs over SCTP.

• M3UA [30], which sits between SCTP and higher layer protocols such asSCCP and ISUP. This is another option for backhaul of SCCP and/or ISUPmessages between signaling gateways and media gateway controllers. In theISUP case we would have ISUP over M3UA over SCTP.

• SCCP user adaptation layer (SUA). Intended to carry higher layer protocols(such as TCAP) that have relied on SCCP in the past, SUA would take theplace of SCCP; the protocol stack would be TCAP over SUA over SCTP. In thesoftswitch case, SUA might be used between a signaling gateway (which ter-minates SCCP on its adjacent TDM SS7 links) and an SCP.

Unlike M2UA and M3UA, SUA was still an Internet draft at the time of thiswriting. The document has progressed through a series of revisions; check under thesigtran working group for the latest version.

In the sigtran working group, several other adaptation layers have been speci-fied (or specifications are in preparation).

15.5 Middlebox Traversal

NATs and firewalls are ubiquitous in today’s IP networks. Let us discuss the formerin connection with SIP. Suppose we have an application running on an end systemthat sits behind a NAT; the application is trying to set up a session with an entity inanother domain. Recall that the source IP address and port number that are knownto the application are not exposed to the “outside world”: the NAT functionexposes a different (IP address, port number) pair and keeps track of the bindingbetween the two.

The NAT function does not make analogous changes to address/port identifiersthat appear in SIP headers, however. This function is relegated to a so-calledALG. Often, the NAT and ALG functions reside on the same network element.When new applications come along, however, new functionality must be added tothe ALG. This slows deployment of new applications. Another problem with this

15.5 Middlebox Traversal 217

arrangement is that additional processing load is placed on the ALG, leading to scal-ability issues.

The philosophy behind the STUN protocol [31] is that it would be betterfor the end-system application to learn the NAT bindings. (STUN stands forsimple traversal of UDP through NATs.) Then it could place the externally-visibleaddress/port pairs in the SIP headers (and SDP payloads, for that matter). However,one problem is that the end-system application may not know whether NAT(s) arepresent or, if so, how many NATs are present. The idea of STUN is to locate anentity (known as a STUN server) in the public Internet that can respond to bindingrequests. The application sends binding requests to the STUN server, which sees theexternally visible address/port pair since it is on the other side of the NAT(s). TheSTUN server, upon receiving a binding request, incorporates the desired informa-tion in the payload of its binding response. Note that the NAT function does notalter the payload.

As the authors of the specification admit, STUN has serious limitations. Thereare a variety of NAT types, and STUN does not work with all of them. It does notenable incoming TCP connections through NATs, nor does it work correctly whenthe end systems that are trying to communicate reside behind the same NAT.

STUN was developed in IETF’s Middlebox Communication (midcom) workinggroup. Middlebox is an umbrella term intended to encompass network intermediar-ies such as the following:

• Firewalls, which perform policy-based packet filtering;• Network address translators;• Intrusion detectors;• Load balancers;• Security gateways.

Realizing that STUN is an incomplete, stop-gap solution, the midcom group isdeveloping a MIDCOM protocol. The midcom architecture RFC [32] talks aboutmoving “application intelligence’’ from middleboxes to external MIDCOM agents.Although generality is a design goal of the MIDCOM effort, NATs and firewalls arethe main focus of the current work. In the case of SIP interworking with NATs, theapproach seems to boil down to something quite tangible: namely, colocating aMIDCOM agent with the SIP proxy server.

The problem space that the midcom group seeks to attack is a big one, and thesolution space is immature, to say the least. Part of the trouble is that there are manyvariants of the basic NAT, making it difficult or impossible to deal with NATs in auniform way. NATs play an important role in conserving IP address space, and theyare part of the de facto privacy/security infrastructure in today’s IP networks. Insome ways, the problems associated with NATs are hateful. As a simple example,consider the following: RFC 3550 [33] says that, for RTP and RTCP streams associ-ated with the same session, the RTCP port number should equal the RTP portnumber plus 1. But NATs do not necessarily preserve this port number adjacency.As a result, RFC 3605 [34] specifies a way to include RTCP port numbers in SDPdescriptions. Examples like this one serve to strengthen our impression that it will bevery difficult to establish a sensible framework that is adequately encompassing.


It is not clear to us that there is sufficient will in the industry to standardize NATbehavior. (Although it would be painful to do so, we also think it would be a bighelp; keep in mind that NATs are likely to proliferate to support interworkingbetween IPv4 and IPv6 domains.) This is yet another reason we expect to see carri-ers deploying VoIP over private IP networks—otherwise, they may not have enoughcontrol to make sure that their solutions consistently “work as advertised.” It willbe interesting to see how the midcom work program develops.

15.6 Comments and Further Reading

15.6.1 More on IP QoS

IP QoS is the dominant topic in this chapter. Even so, space limitations prevent usfrom doing justice to this subject area. In the following paragraphs, we give a fewreferences for further investigation.

First we list some useful overview documents. In 2000, the Internet ArchitectureBoard issued a discussion document [35] highlighting key issues with IP QoS. Thedocument attempts to establish a consistent vocabulary and describes the limita-tions of available approaches. RFC 3272 [36] is similar in approach to the afore-mentioned Internet Architecture Board document but is more encompassing. RFC3272 came out of IETF’s Traffic Engineering working group (tewg).

Faynberg and Lu published an article [37] that, in the context of ITU-T’s ongo-ing QoS architecture effort, gives a good overview of IP QoS techniques.

In his article [15], Seitz envisions a three-step realization process for “anend-to-end IP QoS solution enabling successful IP/PSTN convergence.” The firststep is getting service providers to agree on common, quantifiable IP QoS objec-tives. The standards discussed in Section 15.1.4 concentrate primarily on the firststep. The second step is developing and deploying mechanisms that support theobjectives. Our discussion in Sections 15.1.1, 15.1.2, and 15.1.3 is pertinent tostep 2, but is far from being the last word. The third and last step is coming upwith signaling protocols that allow users to dynamically harness the QoS mecha-nisms based on their current needs. In this book, our coverage of step 3 is limitedat best.

The output of IETF’s tewg working group is pertinent here, especially to Seitz’sstep 2. Does step 3 represent huge changes to current signaling protocols, or rela-tively small changes? The answer to this question is unclear; this is arguably the areawhere IP QoS is most immature. In this regard, IETF’s Next Steps in Signaling (nsis)working group bears watching.

15.6.2 IPv6 and ROHC

Migration to IPv6 has not begun en masse. But numerous IETF working groups areaddressing aspects of IPv6, the migration thereto, and the implied transition periodin which interworking between IPv6 and IPv4 domains will be paramount. We havethe IPv6, Mobility for IPv6 (mip6), MIPv6 Signaling and Handoff Optimization(mipshop), Site Multihoming in IPv6 (multi6), and IPv6 Operations (v6ops) work-ing groups.

15.6 Comments and Further Reading 219

IPv6 is not a topic of emphasis in this book, so we will not detail the activitiesof the aforementioned working groups. We note, however, that IPv6 does haveperformance implications (and therefore impacts QoS), particularly in wirelessnetworks. There is an interesting conflict between objectives in the wireless realm.

On one hand, growth in wireless networks has been touted as an importantdriver for IPv6 deployment. Let us look at pressures that threaten to exhaust theIPv4 address space. A given subscriber might have multiple devices connected to aPLMN (a PC and a cell phone or a personal digital assistant with voice capability,for instance). Each device would need to be separately IP-addressable. Moreover,while wireless penetration rates are generally high in developed countries, emergingeconomies promise to grow the worldwide subscriber base substantially. For coun-tries that do not have reliable PSTNs (or whose PSTNs do not extend outside largepopulation centers), third generation wireless networks may be a sensible alterna-tive. Lastly, telematic applications will place additional pressure on the IP addressspace. Examples include vending machines connecting to the wireless wide areanetwork to inform back-end systems of their stocking levels, home appliances thatare remotely accessible via IP-based connectivity, and automobiles.

Wireless carriers are eager to market third generation services in terms of“always on” service capabilities; this was a key selling point of cable modem andDSL. Third generation mobile devices would require “permanent” IP addresses inorder to realize this vision, or so the argument goes. Here we play devil’s advocate,so to speak, by making the following “contrarian” observations:

• By and large, cable modem and DSL users obtain IP addresses temporarily viaDHCP, just like dial-up users. Often, these are private IP addresses hiddenbehind network address translators; any number of service providers can reusethe same private IP address space.

• It is unclear that telematic applications require always-on connectivity. In thevending machine example, it appears much more likely to us that the machinewould periodically connect to the network, obtain a temporary IP addressassignment via DHCP, upload its information to the owner’s IT network, andthen disconnect. There are issues if the IT network wants to contact the vend-ing machine...How do we “wake it up” and ask it to contact the network?Wireless carriers have encountered this problem; there are means to solve it,although they tend to be slow.

Although the wireless industry may see a long-term need to migrate to IPv6 (tosidestep limitations on its marketing opportunities), it is less able than the wire-line industry to accommodate the implied increase in overhead. Recall that IPv6addresses are 128 bits long, whereas IPv4 addresses are only 32 bits long. For thisreason, header compression is important. Header compression schemes have beenaround for a long time. Early schemes were not designed for the wireless environ-ment, however, and do not perform well in the wireless domain (because bit errorrates tend to be high). IETF’s rohc working group has turned its attention to thisproblem. Recalling that numerous IP addresses can appear in a single SIP message,we see that the header compression problem is not limited merely to UDP/IP andTCP/IP headers. Before enumerating several rohc specifications, we note that header


compression algorithms maintain state machines. The difficulty with this is that itconsumes memory and processing power in wireless handsets; these are scarceresources with many competing claimants. In the long run, we believe that afford-able handsets will have enough resources to run the necessary state machines.

Although work is ongoing, rohc’s main specifications are stable. RFC 3095 [38]is the baseline document. RFCs 3096 [39], 3242 [40], 3243 [41], 3408 [42], and3409 [43] are concerned with header compression for RTP streams over UDP. Sincebearer traffic flows throughout the life of a VoIP call (whereas signaling occursmostly at the beginning and end of a call), it is not surprising that RTP streams haveconsumed so much of the rohc group’s attention.

SIP header compression is important, however. This is especially true for appli-cations like PoC (see Section 13.7.1), which makes heavy use of SIP. Compression ofSIP and other signaling protocols generally goes under the name SigComp; see RFCs3320 [44], 3321 [45] and 3322 [46]. Details are available at the rohc workinggroup’s home page.

15.6.3 Routing for Voice over IP Protocols: iptel Working Group

The IP Telephony (iptel) working group was chartered to solve problems associatedwith naming and routing for Voice over IP. Using BGP-4 as a model, the group hasdeveloped the Telephony Routing over IP (TRIP) protocol [47]. Like BGP-4, TRIPis used to distribute reachability information across domain boundaries. The iptelgroup charter acknowledges that TRIP alone does not cover all of the scenariosunder which signaling servers exchange routing information; work is ongoing.

15.6.4 ENUM

Why not associate a multiplicity of services with a single telephone number? Herethe goal is to go beyond traditional vertical services like caller ID to include:

• Additional modes of communication like fax, e-mail, and instant messaging;• A variety of destination types for full-duplex voice service (SIP phones and

circuit-switched phones come to mind).

The idea of electronic numbering (ENUM) is to use DNS functionality to realizethis goal. The IETF’s Telephone Number Mapping (enum) working group hasproduced a baseline specification (RFC 2916 [48]). Technically, the result of aso-called ENUM query is a series of DNS naming authority pointer (NAPTR)resource records.

RFC 2916 is under revision, partly because the companion document definingNAPTR resource records has been obsoleted by the work of the Uniform ResourceNames (urn) Working Group [49–53]. The urn working group is concluded.

The results of an ENUM query identify the available methods for contactingthe subscriber associated with a given telephone number (typically in order ofpreference).

The technical difficulties of ENUM are relatively minor when compared withthe beaurocratic challenges. Telephone numbering is administered as specified in


ITU-T recommendation E.164 [54]; naturally, many national and internationalagencies are involved. There are ongoing efforts to establish an international“public” ENUM infrastructure: that is, a worldwide DNS hierarchy that can resolveENUM queries. Trials have taken place in Europe and Asia; at the time of this writ-ing, no large-scale public ENUM trial has been scheduled in the United States. Forup-to-date information, the reader can consult www.itu.int. For information ondevelopments in the US, one can consult www.enum-forum.org. For those seekinginformation on national developments in other countries, one approach is to moni-tor the mailing list of IETF’s enum working group.

15.6.5 Service Architectures

We introduced the IMS in Section 13.7.3. IMS provides a standard way for thirdgeneration wireless carriers to roll out SIP-based services. As yet, there is no wirelinecounterpart. However, TISPAN is looking at the possibility of defining an IMS-likeservice architecture for the wireline domain. TISPAN is a Technical Body that oper-ates under the auspices of European Telecommunication Standards Institute (ETSI);see www.etsi.org for more information. TISPAN was formed in 2003, so it is toosoon to tell whether the wireline IMS effort is likely to gain broad support.

References

[1] McKeown, N., “The iSLIP Scheduling Algorithm for Input-Queued Switches,” IEEE/ACMTransactions on Networking, Vol. 7, No. 2, 1999, pp. 188–201.

[2] Bennett, J., and H. Zhang, “Hierarchical Packet Fair Queuing Algorithms,” ACMSIG-COMM, 1996.

[3] Bennett, J., and H. Zhang, “Why WFQ is Not Good Enough for Integrated Services Net-works,” Proc. of the 6th International Workshop on Network and Operating Systems, Sup-port for Digital Audio and Video (NOSSDAV), April 1996.

[4] Bennett, J., and H. Zhang, “WF2Q: Worst-Case Fair Weighted Fair Queuing,” INFOCOM,1996.

[5] Parekh, A., and R. Gallager, “A Generalized Processor Sharing Approach to Flow Controlin Integrated Services Networks: The Single-Node Case,” IEEE/ACM Transactions on Net-working, Vol. 1, No. 3, June 1993, pp. 344-357.

[6] Zhang, L., “Virtual Clock: A New Traffic Control Algorithm for Packet SwitchingNetworks,” ACM SIGCOMM Computer Communications Review, Vol. 20, No. 4, 1990,pp. 19–29.

[7] Suri, S., G. Varghese, and G. Chandranmenon, “Leap Forward Virtual Clock: A New FairQueueing Scheme With Guaranteed Delays and Throughput Fairness,” IEEE Infocom,1997, pp. 557–565.

[8] Golestani, S., “A Self-Clocked Fair Queuing Scheme for Broadband Applications,” IEEEInfocom, 1994.

[9] Braden, R., et al., RFC 2205, Resource ReSerVation Protocol (RSVP)–Version 1 FunctionalSpecification, IETF, September 1997.

[10] Awduche, D., et al., RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels, IETF,December 2001.

[11] Jamoussi, B., et al., RFC 3212, Constraint-Based LSP Setup Using LDP, IETF, January2002.


[12] Katz, D., K. Kompella, and D. Yeung, RFC 3630, Traffic Engineering (TE) Extensions toOSPF Version 2, IETF, September 2003.

[13] Recommendation Y.1540, IP Packet Transfer and Availability Performance Parameters,ITU-T, December 2002.

[14] Recommendation Y.1541, Network Performance Objective for IP-Based Services, ITU-T,May 2002.

[15] Seitz, N., “ITU-T QoS Standards for IP-Based Networks,” IEEE Communications Maga-zine, June 2003, pp. 82–89.

[16] Recommendation Y. 1541, Traffic Control and Congestion Control in IP Based Networks,ITU-T, March 2002.

[17] Shenker, S., C. Partridge, and R. Guerin, RFC 2212, Specification of Guaranteed Quality ofService, IETF, September 1997.

[18] Jacobson, V., K. Nichols, and K. Poduri, RFC 2598, Expedited Forwarding PHB, IETF,June 1999.

[19] Davie, B., et al., RFC 3246, An Expedited Forwarding PHB, IETF, March 2002.[20] Wroclasski, J., RFC 2211, Specification of the Controlled-Load Network Element Service,

IETF, September 1997.[21] Heinanen, J., et al., RFC 2597, Assured Forwarding PHB Group, IETF, June 1999.[22] TS 23.107, Quality of Service (QoS) Concept and Architecture, 3GPP.[23] Durham, D., et al., RFC 2748, The COPS (Common Open Policy Service) Protocol, IETF,

January 2000.[24] Herzog, S., et al., RFC 2748, COPS Usage for RSVP, IETF, January 2000.[25] Herzog, S., RFC 2750, RSVP Extensions for Policy Control, IETF, January 2000.[26] Yavatkar, R., D. Penderakis, and R. Guerin, RFC 2753, A Framework for Policy-Based

Admission Control, IETF, January 2000.[27] Handley, M., and V. Jacobson, RFC 2327, SDP: Session Description Protocol, IETF, April

1998.[28] Stewart, R., et al., RFC 2960, Stream Control Transmission Protocol, IETF, October 2000.[29] K. Morneault, et al., RFC 3331, Signaling System 7 (SS7) Message Transfer Part 2

(MTP2)—User Adaption Layer, IETF, September 2002.[30] Sidebottom, G., K. Morneault, and J. Pastor-Balbas, RFC 3332, Signaling System 7 (SS7)

Message Transfer Part 3 (MTP3) User Adaption Layer (M3UA), IETF, September 2002.[31] Rosenberg, J., et al., RFC 3489, STUN—Simple Traversal of User Datagram Protocol

(UDP) Through Network Address Translators (NATs), IETF, March 2003.[32] Srisuresh, P., RFC 3303, Middlebox Communication Architecture and Framework, IETF,

August 2002.[33] Schulzrinne, H., et al., RFC 3550, RTP: A Transport Protocol for Real-Time Applications,

IETF, July 2003.[34] Huitema, G., RFC 3605, Real-Time Control Protocol (RTCP) Attribute in Session Descrip-

tion Protocol (SDP), IETF, October 2003.[35] Huston, G., RFC 2990, Next Steps for the IP QoS Architecture, IETF, November 2000.[36] Awduche, D., et al., RFC 3272, Overview and Principles of Internet Traffic Engineering,

IETF, May 2002.[37] Lu, H. -L., and I. Faynberg, “An Architectural Framework for Support of Quality of Service

in Packet Networks,” IEEE Communications Magazine, June 2003, pp. 98–105.[38] Bormann, C., et al., RFC 3095, Robust Header Compression (ROHC): Framework and

Four Profiles: RTP, UDP, ESP, and Uncompressed, IETF, July 2001.[39] Degermark, M., RFC 3096, Requirements for Robust IP/UTP/RTP Header Compression,

IETF, July 2001.[40] Jonsson, L. -E. and G. Pelletier, RFC 3242, Robust Header Compression (ROHC): A

Link-Layer Assisted Profile for IP/UDP/RTP, IETF, April 2002.


[41] Jonsson, L. -E. and G. Pelletier, RFC 3242, Robuts Header Compression (ROHC): Require-ments and Assumptions for 0-byte IP/UDP/RTP Compression, IETF, Aprile 2002.

[42] Liu, Z., and K. Le, RFC 3408, Zero-byte Support for Bidirectional Reliable Mode (R-mode)in Extended Link-Layer Assisted Robust Header Compression (ROHC) Profile, IETF,December 2002.

[43] Svanbro, K., RFC 3409, Lower Layer Guidelines for Robust RTP/UDP/IP Header Com-pression, IETF, December 2002.

[44] Price, R., et al., RFC 3320, Signaling Compression (SigComp), IETF, January 2003.[45] Hannu, H., RFC 3321, Signaling Compression (SigComp)—Extended Operations, ITEF,

January 2003.[46] Signaling Compression (SigComp) Requirements & Assumptions, IETF, January 2003.[47] Rosenberg, J., H. Salama, and M. Squire, RFC 3219, Telephony Routing Over IP (TRIP),

IETF, January 2002.[48] Faltstrom, P., RFC 2916, E.164 Number and DNS, IETF, September 2000.[49] Mealling, M., RFC 3401, Dynamic Delegation Discovery System (DDSS) Part One: The

Comprehensive DDDS, IETF, October 2002.[50] Mealling, M., RFC 3402, Dynamic Delegation Discovery System (DDDS) Part Two: The

Algorithm, IETF, October 2002.[51] Mealling, M., RFC 3403, Dynamic Delegation Discovery System (DDDS) Part Three: The

Domain Name System (DNS) Database, IETF, October 2002.[52] Mealling, M., RFC 3404, Dynamic Delegation Discovery System (DDDS) Part Four: The

Uniform Resource Identifiers (URI) Resolution Application, IETF, October 2002.[53] Mealling, M., RFC 3405, Dynamic Delegation Discovery System (DDDS) Part Five:

URI.ARPA Assignment Procedures, IETF, October 2002.[54] Recommendation E.164, The International Public Telecommunications Numbering Plan,

ITU-T.


C H A P T E R 1 6

Conclusion

Many telcos are now deploying packet telephony on a substantial scale. The IP Cen-trex industry is picking up steam. Softswitch deployments in telco core networks arealso taking place. With these trends, service providers are gaining operational expe-rience. Softswitch vendors and service providers have worked to adapt traffic engi-neering models to packet domains. Deployments furnish opportunities to validateand/or calibrate those traffic models.

However, numerous aspects of packet telephony are still in early phases ofthe maturation cycle. In this book, we highlighted the following issues:

• Routing and address resolution that encompasses packet-switched andcircuit-switched domains is still a work in progress.

• Today’s solutions for IP QoS are immature. In a nutshell, there is a very bigdifference between “make sure it gets there” and “make sure it gets there ontime.” TCP/IP is well suited to the former but is not enough for the latter:• It is possible to provide high-quality voice service over “managed” IP net-

works, but robustness and efficiency improvements are still needed. Aboveall, scalable IP QoS solutions are still evolving. Operational experience-something that was in short supply until very recently- will surely be crucialto furthering this evolution. On today’s wide area network links, high-quality VoIP is often realized as VoIP over ATM. This is due to ATM’s QoScapabilities.

• Voice over ATM, which can take advantage of ATM’s robust QoS support,is central to some packet telephony implementations. But Voice over ATMper se has not captured the industry’s imagination, and may see limited suc-cess in the marketplace. In particular, it appears highly unlikely that end-to-end Voice over ATM will be widely deployed.

• Enhanced service offerings are crucial to the widespread acceptance of packettelephony. “Enhanced service offerings” could mean services that cannot beoffered over today’s circuit-switched networks. But it could just as easilymean services that were conceived a long time ago but have typically beenoffered in limited ways. In the past, PBX/Centrex features have been availableonly in wireline environments. To be fair, wireless carriers now offer privatedialing plans to corporate customers. Integration of service offerings acrosswireless and wireline domains is an appealing prospect to corporate custom-ers and consumers alike. This is an area that is truly in its infancy. Softswitchtechnology, along with protocols such as SIP, show promise here. Although

225

we believe that SIP is well-suited to the development of integrated services, webelieve it is important to sound the following note of caution:• Since it is relatively new, SIP is probably not ready to “take on the world.”

Maturity will come over time with the accumulation of operational experi-ence. Meanwhile, however, it is hard to ignore that SS7 is established tech-nology; it has proven its robustness on a truly enormous scale. The advent ofsigtran means that the bandwidth limitations inherent in TDM-based SS7implementations can be overcome. We believe that SS7 call control signalingwill be phased out very slowly.

226 Conclusion

A P P E N D I X A

Data Link Layer Protocols

Our primary topics in this appendix are Frame Relay, ATM, and Ethernet. FrameRelay and ATM have strong similarities centering on the fact that both are connec-tion-oriented. Ethernet is connectionless. We will define these terms in the exposi-tion that follows.

Before moving into our main topics, we look briefly at a precursor to many linklayer protocols: HDLC.

A.1 HDLC

We begin our discussion of the data link layer with HDLC. For our purposes, themost important thing about HDLC is that it defines a frame structure that other linklayer protocols have copied. More precisely, many other link layer protocols haveadapted HDLC’s frame structure to suit their own purposes. For example, PPP [1]uses a framing mechanism based on HDLC framing (see [2]). PPP is perhaps bestknown for its widespread use in dial-up sessions, but it is deployed in many otherways (e.g., [3]).

HDLC defines three frame types, of which we mention two: information andsupervisory. Payload received from higher layers is transported within informationframes. Supervisory frames are used to implement error and flow control. Althoughwe do not describe the particulars, we note that IEEE logical link control (LLC) [4]uses a variant of HDLC’s error control mechanism. LLC is employed in Ethernet,Token Ring, and other LAN technologies.

HDLC frames begin and end with a 1-byte flag field (which contains the pattern‘01111110’). The flag pattern is used to delimit frames. Thus, we must make surethat the flag pattern never appears in mid-frame: wherever five consecutive ‘1s’occur in a payload, the link layer protocol entity appends a ‘0’. This process isreversed at the receiving end.

Rather than documenting HDLC frame formats (which is not necessary for ourpurposes), we turn our attention in the next section to Frame Relay. This is anothertechnology that uses HDLC-derived framing.

A.2 Frame Relay

Frame Relay is a descendent of the X.25 protocol. X.25 was designed for use onlinks with relatively high bit error rates; it uses an error control scheme based on

227

that of HDLC. X.25 also has flow control features. Because its error and flow con-trol schemes add lots of overhead, X.25 is not very efficient for transmission overhighly reliable links. As less reliable analog links were replaced by highly reliablelinks, an alternative was needed.

This was the motivation for Frame Relay, which is sort of a “stripped down”version of X.25. Frame Relay does not perform any error correction; it simply dis-cards frames that it recognizes as corrupted and assumes that higher layer protocolswill take care of the rest (e.g., by detecting missing data and requesting retransmis-sion whenever necessary).

A.2.1 The Frame Relay Header

The Frame Relay frame and header formats appear in Figure A.1. The 1-byte Flagfield contains the HDLC flag pattern and is used to delimit frames. (Note that thereis no field indicating the length of the frame, so Frame Relay switches have no othermeans of delineating frames. Most Frame Relay switches support a maximum framesize of 1,600 or more bytes.) The 2-byte cyclic redundancy check (CRC) field is usedto detect corrupted frames (which are discarded). For our purposes, the key headerfields are as follows (we will not cover the “grayed-out” header fields):

• Data link connection identifier (DLCI). This 10-bit field is used as a for-warding table index, as described in Section A.2.2. Note that the DLCI doesnot appear contiguously in the Frame Relay header; we have labeled the place-ment of the six most significant bits (MSBs) and the four least significant bits(LSBs).

• Forward explicit congestion notification (FECN). When a Frame Relay switchexperiences congestion, it can notify the destination endpoint by setting thisbit to 1.

• Backward explicit congestion notification (BECN). When a Frame Relayswitch experiences congestion, it can notify the originating endpoint by settingthis bit to 1.

• Discard eligibility (DE). When a customer exceeds its contracted data rate,this bit can be set to 1 at ingress to the Frame Relay network. When a FrameRelay switch experiences congestion, frames with DE=1 are the first to bediscarded.

228 Data Link Layer Protocols

User DataHeader Flag

C/RDLCI (MSB portion)

Flag CRC

EA1DEBECN

FECN

DLCI (LSB portion)EA0

16 bits

Figure A.1 Frame Relay format including header.

A.2.2 Label Switching and Virtual Circuits

How does a Frame Relay switch decide where to send an incoming packet? It doesso via a table lookup. The table is indexed by incoming port and incoming DLCI,and the table lookup actually yields two things: outgoing port and outgoing DLCI.Before queuing a frame for transmission on the appropriate output port, the FrameRelay switch replaces the incoming DLCI with the outgoing DLCI.

Table A.1 presents an illustrative example; here we have the mapping

(incoming port/DLCI = 2/3) → (outgoing port/DLCI = 4/7).

The table lookup described here can be done quickly; it is much simpler than the“longest match” lookups performed by IP routers. As the example demonstrates,two end systems that are exchanging frames across a Frame Relay switching net-work are not likely to see the same DLCI(s). We say that DLCIs have only local sig-nificance. To see why DLCIs lack end-to-end significance, let us refer again to theexample of Table A.1: by looking at the line for incoming port 3, we see that a dif-ferent input stream already has “dibs” on outoing port/DLCI = 4/3.

To make it so that DLCIs could remain constant along end-to-end paths, wewould create more problems than we would solve (particularly in regard to scalabil-ity). So how can we manage end-to-end paths through Frame Relay networks? Thisis accomplished using virtual circuits (VCs).

Data makes its way through individual Frame Relay switches by means ofbindings between (input port/DLCI) pairs and (output port/DLCI) pairs. A VC issimply a set of such bindings (one at each switch along a route) that collectivelydefine an end-to-end path. Frame Relay VCs are typically established by networkadministrators via element management systems; these are called permanent VCs.Switched VCs (which are dynamically set up and torn down via signaling) have beendiscussed over the years but have not seen widespread deployment. With the adventof MPLS, we may see dynamically established paths realized as MPLS labelswitched paths.

Several standards bodies were involved with standardizing of Frame Relay;the Frame Relay Forum was among them. The Frame Relay Forum merged withthe MPLS Forum in 2003, creating the MPLS and Frame Relay Alliance. The inter-ested reader can consult www.mplsforum.org for more information on FrameRelay.

A.2 Frame Relay 229

Table A.1 Label Switching Illustration

Incoming Port Incoming DLCI

1 2 3 ... 10241

2

3...

Port: 4DLCI: 7Port: 4DLCI: 3

A.3 Asynchronous Transfer Mode

Frame Relay is often called a label switching technology because it uses a short,locally significant label (namely, the DLCI) as a forwarding table index. ATM is alsoa label switching technology; the details of the label are different, and vari-able-length frames are replaced by fixed-length cells. But the basic idea is similar. Inparticular, a virtual circuit is created by establishing a label binding at each switchalong an end-to-end path. Until you have a virtual circuit or virtual path (we will dis-cuss the latter in Section A.3.5), you do not have a way to forward data through anATM network (and similarly for Frame Relay). We say that ATM and Frame Relayare connection-oriented. Note that frames reach the terminating endpoint of a VC inthe same order that they entered the originating endpoint. This contrasts with IPnetworking.

ATM does add a few twists. In particular, the developers of ATM paid closeattention to QoS issues. Whereas Frame Relay was developed to transport data traf-fic across wide area networks links, ATM was conceived as a multiservice technol-ogy for voice, video, and data. Moreover, Frame Relay was not designed for linkswith bit rates in excess of 45 Mbit/s; ATM interfaces are available at least up to ratesof 2.4 Gbit/s.

A.3.1 The ATM Header

The ATM cell format is displayed in Figure A.2. (Here, following the industry stan-dard parlance, we use the term cell as a synonym for “fixed-length frame.” EveryATM cell is 53 bytes long.)

When forwarding cells along a virtual circuit, an ATM switch uses the virtualpath identifier/virtual channel identifier (VPI/VCI) as the label: incoming portnumber and VPI/VCI are used as indices into a forwarding table. The table lookupyields an outgoing port number and VPI/VCI. (To emphasize that the VPI/VCI con-catenation is “of a piece,” we have cross-hatched this portion of the cell in the fig-ure.) At a network-network interface, the VPI consumes the first 12 bits of the ATMcell. Note that in Figure A.2, at a user-network interface, the first four bits are usedfor something else (the generic flow control (GFC) field, which we will not discussfurther); as a result, the VPI is only 8 bits long. The VCI is always 16 bits long.

We will not discuss the payload type identifier (PTI), except to say that it can beused to distinguish network management traffic from user data. The cell loss prior-ity (CLP) bit is analogous to Frame Relay’s discard eligibility bit. The header errorcheck is based on a cyclic redundancy check calculation; it is used to detect the pres-ence of bit errors and for cell delineation. (Notice in this regard that no flag patternis present to delineate ATM cells.)

A.3.2 ATM Approach to Quality of Service and Statistical Multiplexing

ATM was designed from the beginning with robust QoS in mind. To this end, ATMdefines several QoS classes. Depending on the QoS class of an ATM connection, theATM network may provide guarantees on a number of traffic parameters, includingcell delay variation (CDV), cell transfer delay (CTD) and cell loss ratio (CLR).


Generally, sources must behave in accordance with traffic contracts (or cells maybe discarded to prevent congestion). Pertinent source traffic descriptors includepeak cell rate, sustainable cell rate and maximum burst size. The classes are asfollows:

• Constant bit rate (CBR). Intended for emulation of TDM circuits, this classhas tight bounds on the aforementioned parameters; it is not suitable forbursty traffic sources.

• Real-time variable bit rate (rt-VBR). This class also provides guarantees onCDV, CTD, and CLR. Source descriptors pertinent to this class includesustainable cell rate and maximum burst size. As an example, note thatvideo traffic is by nature burstier than voice traffic. Note also that silence-suppressed voice has a variable bit rate.

• Nonreal-time variable bit rate (nrt-VBR). This class provides guarantees on(mean) CTD and CLR but not on CDV.

• Available bit rate (ABR). This class is intended to provide feedback-basedflow control (thus there are some similarities to TCP’s role in IP domains).ABR was basically never deployed.

• Unspecified bit rate (UBR). This is for best-effort service and is widelydeployed.

ATM switches make heavy use of weighted fair queuing and/or other classbased queuing schemes. Allocation of buffer and bandwidth for the real-time trafficclasses is delicate, and it is fair to say that this is a sophisticated subject area. Gorydetails are available in [5]; the authors, who worked for a major ATM switch ven-dor at the time, are experts.

A.3.3 The ATM Control Plane

ATM VCs can be managed administratively (via ATM element management sys-tems), in which case they are called permanent virtual circuits (PVCs). They can alsobe set up and torn down dynamically, in which case they are called switched virtual

A.3 Asynchronous Transfer Mode 231

Cell Payload (48 bytes)

Header Error Check

CLPPTI

8 bits

GFC or VPI

VCI

VPI

VPI

Figure A.2 ATM cell format.

circuits. The SVC signaling protocol at the User-Network Interface (UNI) is basedon ISDN signaling. Two versions of the ATM UNI, specified by ITU-T and ATMForum, respectively, are [6] and [7]. Earlier version(s) of the ATM UNI may alsoremain in widespread use.

What about signaling SVCs across an ATM network? In particular, where is therouting intelligence? Private Network-Network Interface (PNNI [8]) is a signalingand routing protocol aimed at this problem. Like OSPF (see Section 7.5.2), PNNIroutes dynamically based on a shortest path formulation. PNNI protocol entitiesflood routing information through the domains they inhabit; using that informa-tion, each PNNI switch builds a routing table. Like OSPF, PNNI is a link stateprotocol.

PNNI incorporates a notion of hierarchy that is more flexible than that of OSPFareas. Unlike OSPF, PNNI is source routed: the originating node selects a routewhen setting up an SVC. Intermediate nodes are obligated to stick with this routeunless adequate resources are unavailable (or administrative policies prohibit it).The call-control portion of PNNI is similar to UNI signaling.

Soft-Permanent Connections

We have talked about SVCs, which are dynamically established via signaling.SVCs have been studied extensively over the years but have not been used aswidely as expected. (However, some ATM-based softswitches use SVCs.) There isanother type of ATM connection: the soft-permanent connection. A soft-permanentvirtual circuit (S-PVC) is a hybrid of the SVC and PVC connection types, as we nowexplain.

S-PVC setups are triggered by administrative action (typically through an ele-ment management system), but the setups are actually carried out using signaling inthe same manner as with SVC setups. The attraction of S-PVCs is that they can beautomatically rerouted in failure conditions. Some ATM element management sys-tems implement their own rerouting capabilities. However, the capabilities are notstandardized and the rerouting process tends to be very slow. The “permanent” in“soft-permanent” refers to the idea that, under normal circumstances, an S-PVCwould be expected to remain in place for a considerable duration. S-PVCs are widelydeployed.

Ironically, S-PVCs were first conceived for another reason: to make it easy towork with end systems that did not have SVC signaling capability. If such an endsystem was attached to a network that did have SVC capability, then administrativeaction would be required to configure the PVC “leg” connecting the end system tothe rest of the network. However, the S-PVC notion allowed the rest of theend-to-end connection to be set up dynamically via signaling.

A.3.4 ATM Adaptation Layers and Options for Voice over ATM

ATM Adaptation Layers (AALs) are the glue between the “raw” ATM layer andhigher layers. Roughly speaking, AALs are packetization schemes. We list AALs andtheir intended uses below.


• AAL1. This adaptation layer [9] is used for PCM voice (i.e., G.711), either asindividual channels [10] or via emulation of channelized DS1s and/or DS3s[11]1. AAL1 can also be used for leased lines. AAL1 VCs are normally associ-ated with the CBR traffic type.

• AAL2. This adaptation layer can also be used for voice (primarily over rt-VBRVCs with vocoders such as AMR. G.711 voice can be transported over CBRAAL2 VCs, but compared with AAL1 there is additional overhead). The inter-esting thing about AAL2 is that it can multiplex voice calls within a singleATM VC. Further discussion of AAL2 appears later in this section.

• AAL5. This adaptation layer [12] performs simple segmentation and reassem-bly. AAL5 has historically been employed for UBR VCs carrying data traffic.Over VBR VCs, AAL5 can also be used for VoIP.

• Signaling ATM adaptation layer (SAAL). This adaptation layer [13] is usedfor SS7 signaling over so-called high-speed links. High-speed links are realizedusing circuit emulation over CBR VCs.

Historical Note on AAL3/4

Another AAL (AAL3/4) was standardized by ITU-T but is rarely mentioned (thuswe have omitted it from our list). AAL3 and 4 were intended to provide simpleframing support for connection-oriented and connectionless data services, respec-tively. Eventually these two AALs were combined. In addition to the 5-byte header,AAL3/4 consumes 4 bytes of the ATM payload. AAL5 does not require the addi-tional 4 bytes and is therefore preferred.

Options for Voice over ATM

Overlay networks of PVCs (or S-PVCs) are expensive to manage (not to mentiontheir stranded bandwidth). Therefore SVCs are probably a more attractive optionfor Voice over ATM. However, performing SVC setup on a per call basis places aheavy signaling load on ATM network elements. Sluggish call setup performancemay result. We might espouse the philosophy that, in a broadband network, an indi-vidual telephone call consumes too little bandwidth to merit per call signaling atevery switch. AAL2 was designed with this philosophy in mind.

More on AAL2. As noted, AAL2 [14–18] adds a layer of multiplexing within anATM connection. In the case of voice traffic in a large network, mapping each callto a different SVC results in a large number of ATM connections and places a hugesignaling burden on the ATM call-control processors (although it is efficient interms of transmission bandwidth). AAL2 addresses this problem by introducingcircuit identifiers (CIDs) into the ATM payloads. The CIDs are used to distinguishdifferent calls that are carried inside the same ATM VC. The endpoints of the ATM


1. A single digital signal 1 (DS1) carries 24 voice channels; its bit rate is around 1.5 Mbit/s. The 30-channelEuropean counterpart, E1, can also be emulated. A single digital signal 3 (DS3) carries 672 voice channelsand operates at around 45 Mbit/s.

VC can signal call setups and teardowns at the AAL2 layer without involving theATM control plane. This can be done within the AAL2 VC itself (in which case aspecific CID is set aside for signaling) or out of band.

We think AAL2 is quite ingenious. However, it has seen limited uptake in theindustry. One of the reasons is that, practically speaking, a mesh of VCs must bemaintained among the AAL2 endpoints. (The notion of an “AAL2 switching node”is mentioned in the standards. The idea of an AAL2 switching node is that it wouldterminate AAL2 VCs and repackage incoming AAL2-layer traffic into outgoing VCsbased on the AAL2 CIDs. This would allow one to connect AAL2 endpoints to theAAL2 switching node rather than to each other, thereby reducing the number ofAAL2 VCs required to do the job. To the best of our knowledge, nobody ever builtan AAL2 switching node.)

A.3.5 Virtual Paths

We previously said above that, in the case of virtual circuits, forwarding decisionsare based on the combined VPI/VCI field in the cell header. It is also possible toswitch cells based only on the VPI field; ATM defines the notion of a virtual path(VP) for this purpose. A single VP can have many VCs within it.

We have seen that AAL2 adds a more granular layer of multiplexing. VPs repre-sent a less granular multiplexing option at the ATM layer. Scalability is one of thekey motivations for this feature. As we have already seen, individual VCs possessQoS attributes. Switching at the VPI/VCI level of granularity entails class-basedqueuing to deliver the contracted QoS for each VC. In the core of a large network,there may be many VCs passing through an identical series of switches because theirdestinations are in relatively close proximity. The idea of switching at the VPI level isto ship all cells through the virtual path in the same order they were received (whichrequires only one queue per VPI at each switch in the interior of the VP). Class-basedqueuing mechanisms that operate at ingress to the VP make sure that cells from theconsituent VCs are transported in an appropriate order.

To the best of our knowledge, virtual paths have never seen large-scale deploy-ment. Service providers took the view that the administrative headaches involved inmaintaining a logical network of virtual paths outweighed the potential benefits.

A.3.6 MPLS over ATM: VC Merge Capability

We recall the following information about MPLS from Section 7.7.3. MPLS is allabout efficient transport of IP packets through wide area networks. MPLS sets uppaths at the data link layer; these are known as LSPs. MPLS nodes, which are calledlabel switched routers (LSRs), often have ATM fabrics. When traversing a networkof ATM LSRs, an LSP bears a strong resemblance to an ATM VC. There is a key dif-ference, however, which we now explain.

It will often be the case that traffic streams entering an ATM LSR on differentports will exit that LSR on the same port. It may not be necessary to distinguishbetween the two traffic streams at any of the downstream LSRs in the current MPLSdomain. This is the case if the two traffic streams are headed to the same egress nodeand do not require different treatment vis a vis queuing, discard priority, and so on.


In principle, it should only be necessary to allocate one label (i.e., VPI/VCI) for thecombined traffic stream on the outgoing interface. A network operator might wishto use only one label to avoid consuming too many labels or to limit the signalingtraffic associated with distributing the label bindings. (Note that both of these rea-sons boil down to scalability.)

Suppose we have two traffic streams that are routed from ATM LSRs 1 and 2through LSR 3 to LSR 4. If we assign the same VPI/VCI to all cells from the com-bined traffic stream as they exit LSR 3 on the link to LSR 4, then we must make cer-tain that we avoid the so-called “cell interleave” problem. That is, as cells from twoIP packets (one each from LSR 1 and LSR 2) arrive at LSR 3, they must not be inter-leaved on the outgoing interface. Thus the scenario depicted in Figure A.3 must notoccur. Otherwise, reassembly will not be successful and the frames will have to bediscarded. This means that cells must be buffered (at LSR 3, in this example) until anentire packet’s worth of cells have been received, then forwarded contiguously onthe outgoing interface. This functionality is called VC merge capability.

We now summarize the VC merge issue. When traffic streams enter an ATMLSR on different interfaces but leave, destined for the same egress ATM LSR, on thesame interface, we would often like to merge the two streams under a single label.This conserves labels and reduces signaling traffic associated with label bindings butrequires VC merge capability to avoid the cell interleave problem previously men-tioned. ATM was not originally devised with this capability in mind; in the earlyyears of MPLS, many ATM switches did not support VC merge. On the downside,VC merge requires additional buffering resources. The notion of merging MPLSLSPs, however, is a boon to scalability.

In closing, we note that recent work of the ATM Forum [19–21] has concen-trated on ATM-MPLS interworking.

A.3.7 Why Not Voice over ATM?

Actually, ATM is widely deployed in wide area network settings; voice traffic doesrun over ATM networks. There are deployments of various stripes:

• Circuit emulation service (in which ATM switches essentially act as glorifieddigital cross-connect systems);

• Switched services (at the ATM layer and, to a limited extent, at the AAL2layer [22]);


ATMLSR 1

ATMLSR 2

ATMLSR 3

ATMLSR 4

Direction of trafficPacket 2

Packet 1

Figure A.3 VC merge illustration.

• VoIP traffic (which is carried across ATM networks using AAL5);• Loop emulation service [23] is used to provide Voice over Digital Subscriber

Line.

Therefore, let us rephrase the question as follows: Why is voice not carried“directly” over ATM (as in item 2 above) more often? We offer the followinganswers:

• The continuing evolution and sustained popularity of Ethernet means thatATM is “not the only game in town.” In our opinion, this is the most impor-tant of the lot.

• It is natural to develop new services (and host the service logic) in an IPdomain. We have never encountered discussions that mention ATM and serv-ice logic in the same breath. While this does not necessarily imply that weshould also deploy IP bearer and control planes, the idea of universality doesappeal to people. Moreover, it may be less expensive in the long run to managefewer technologies.

• Voice over IP can run over a wide variety of data link layers.• Existing IP over ATM schemes (e.g., MPLS with ATM as the data link layer)

are imperfect.

In some circles, there seems to be a perception that ATM “lost out” to IP. Webelieve that this is largely incorrect. To the degree that ATM’s horizons have beenlimited by another technology, that technology is Ethernet. People did not believethat Ethernet would scale nearly as well as it has. Early on, ATM proponentsthought that ATM would become a LAN technology. For instance, there weremanufacturers that made 25 Mbit/s network interface cards, and software develop-ers entertained the idea of including SVC capabilities in operating systems. But ATMnever got a foothold in the LAN environment; Ethernet evolved in a way thatallowed equipment manufacturers to keep prices relatively low, even as that technol-ogy’s capability set improved. Thus the vision of end-to-end ATM has never beenrealized.

We may see large volumes of voice traffic being carried over MPLS, with ATMLSRs making up the data link layer. If so, “toll quality” voice may require sophisti-cated class-based queuing mechanisms at LSP ingress and merge points.

A.4 Ethernet

Ethernet is the dominant data link layer technology for LANs. As it overcomes itsdistance and scalability limitations, Ethernet’s “reach” is extending to metropolitanand wide area networks (MANs and WANs). The frame structure remains the samein both realms (until and unless jumbo frames or something similar are standard-ized). Beyond the frame structure, however, MAN/WAN Ethernet solutions bearlittle resemblance to traditional LAN implementations.


Note that, unlike ATM and Frame Relay, Ethernet is connectionless: there is nonotion of virtual circuit.

A.4.1 History of Ethernet

The initial version of Ethernet appeared in 1976, followed in 1980 by the DEC-Intel-Xerox (DIX) standard. The DIX standard specified a transmission rate of 10Mbit/s. The first Ethernet systems, which used coaxial cable, were based on bustopologies. Such networks were difficult to install and troubleshoot, leading to theintroduction (in the late 1980s) of twisted-pair Ethernet. Twisted-pair Ethernetcables are similar to telephone wire. Bus topologies gave way to the familiar “star”topologies (in which computers on the same LAN are connected to a central “hub”).Meanwhile, the IEEE published the first version of its 802.3 standard in 1985. Fromthere, the industry was able to coalesce around a single standard.

A.4.2 Ethernet Frame Structure

The Ethernet Frame structure is shown in Figure A.4. The 7-byte preamble field isan alternating series of 0s and 1s that enables synchronization. The 1-byte start-of-frame delimiter (SFD) contains the pattern ‘10101011’. The destination addressand source address are 6-byte fields in which the first bit is used to distinguishbetween multicast and unicast addresses. Note that source addresses are alwaysunicast. It is worth noting here that Ethernet addresses are globally unique. EachEthernet address begins with an organizally unique identifier or initial addressblock that identifies the manufacturer of the hardware. The remaining bits areassigned by the manufacturer. We will cover the optional field marked VLAN infoin Section A.4.4.

If the value of the 2-byte type/length field is between 46 and 1,500 (inclusive),then that value indicates the number of bytes in the data field. (Payloads shorterthan 46 bytes must be padded to enable reliable collision detection. Note that theminimum frame length for high-speed implementations, such as Gigabit Ethernet, islonger than for 10/100 Mbit/s implementations; we omit the details.) If the value ofthe type/length field is greater than or equal to 1,536, then it indicates an optionalpayload type. The frame check sequence is a cyclic redundancy check.

A.4 Ethernet 237

VLAN info(optional)

SFDPreamble

Source address

Data

Type/Length

Destination address

Frame checksequence

Figure A.4 Ethernet frame structure.

A.4.3 CSMA/CD and Its Scalability Limitations

The 1990s brought Fast Ethernet (which operates at 100 Mbit/s), Gigabit Ethernet,and full-duplex mode. To understand the significance of the latter, we need to fill ina little more background. The data link layer is subdivided into the media accesscontrol (MAC) layer and the LLC layer. The MAC layer interfaces with the physicallayer, whereas the LLC layer [4] sits directly above the MAC layer and interfaceswith the network layer. (Strictly speaking, the LLC layer plays the role of MAC-cli-ent only on end systems; on hubs, bridges and switches the MAC-client is called thebridge entity. We discuss bridging in Section A.4.4.)

The original MAC layer is based on carrier sense multiple access with collisiondetection (CSMA/CD, [24]). Similarly to many if not most LAN technologies, thetransmission medium is shared. It will routinely happen that multiple hosts want totransmit data simultaneously, so there must be a means of deciding who gets totransmit at any given time.

How does CSMA/CD resolve this resource contention problem? If a host wantsto transmit data, and it does not “hear” anybody else transmitting, it starts to sendits data. If another host begins to transmit right around the same time, the framessent by the two hosts will interfere with one another and become garbled—this is acollision. Whenever this happens, the two hosts will notice the problem (this is the“CD” in CSMA/CD). Each will stop transmitting and set a randomized timer. Who-ever’s timer expires first will retry its transmission. (Hearing this, the other host willwait its turn.)

We say that the two hosts in the foregoing example are in the same collisiondomain. Clearly, as more and more hosts are added to a collision domain, the inci-dence of collisions increases; at some point, throughput drops precipitously.

A.4.4 Hubs, Bridges, and Switches

Ethernet hubs are fairly simple devices. Each incoming packet is replicated and sentout on every port (except for the port it came in on). Devices connected to the samehub are therefore in the same collision domain, and we have seen that collisiondomains have definite scalability limits. (Moreover, stringing multiple hubs togetherdoes not do anything to solve the scalability problem.)

This led to the development of Ethernet bridges. Bridging functionality, which isformally defined in [25], includes learning and filtering. Learning simply means that,by observing the source addresses on incoming frames, bridges develop an associa-tion of hosts with ports. Based on the results of the learning exercise, Ethernetbridges build filtering databases.

Once it knows where a host “lives” (as evidenced by an entry in its filtering data-base), an Ethernet bridge will forward packets destined for that host only on theappropriate port. In this fashion, bridges subdivide networks into multiple collisiondomains. This is the aforementioned filtering functionality.

Spanning Trees

In a network with multiple bridges, routing loops must be prevented. For example,before the learning process has progressed to a stable point, it would be common for


two bridges to receive frames from the same originating host from one another. Forthis reason, Ethernet bridges residing on the same LAN run a distributed spanningtree algorithm. Recall from Section 7.5.1 that a spanning tree is a subgraph with thefollowing property: for any pair of nodes, there is one and only one interconnectingpath. (This solves the problem of routing loops, since trees do not have loops.)

Often, the spanning tree is not the whole network (in the sense that additionallinks may be present for the sake of redundancy). If a link goes down, the spanningtree is recalculated. However, this is not instantaneous; broadcast storms tend tooccur (and persist until the spanning tree algorithm has converged). Note that alltraffic is routed on the spanning tree—Ethernet does not come with ready-madeload balancing capabilities. (To be fair, link aggregation is a partial exception; seethe next section.) Schemes for addressing this problem have been proposed, but tothe best of our knowledge there is not a mature standard in this area.

Other Scalability Enhancements: Full-Duplex Links, Link Aggregation, andVirtual LANs

Imagine a point-to-point link connecting two bridges. If access to this link is gov-erned by CSMA/CD, it cannot be run at very high utilization (if both bridges aretransmitting the majority of the time, collisions will happen often and congestionwill result). Full-duplex mode allows both bridges to transmit simultaneously,allowing for much higher utilization. Full-duplex mode requires implementation offlow control capabilities (which are optional in half-duplex mode).

Suppose we want to add capacity by adding a second link between two bridgesalready interconnected. Clearly, we cannot have parallel links in a spanning tree.Link aggregation is a means of representing multiple physical links as a single logi-cal link. The spanning tree algorithm only sees the logical link; the link aggregationsublayer takes care of load balancing among the constituent physical links.

The IEEE 802.1Q standard [26] defines the notion of a virtual LAN (VLAN).VLANs allow administrators to assign end systems to logical groups. Filtering isthen performed based on those logical groups. Among other benefits, VLANsenhance scalability by segregating switched networks into multiple broadcastdomains. The VLAN info field in the Ethernet header (see Figure A.4) is actuallysubdivided into two 2-byte fields. The first is a type/length field with a designatedvalue indicating that the second 2-byte field is a so-called VLAN tag. The VLAN tagcontains a 3-bit user_priority field (which supports rudimentary QoS functionality)and a 12-bit VLAN ID. The maximum number of VLANs that can inhabit a singleswitched network is 4,094 (of the 212 = 4,096 possible values of the VLAN ID, twoare reserved).

VLAN tags are primarily useful on interbridge links. They are not typically usedon links from end systems to hubs or bridges (so Ethernet cards in workstations nor-mally do not need to support VLAN tagging). Bridges keep track of end systems’VLAN membership, transparently to the end systems.

A note on the difference between bridges and switches. Early generations of Ether-net bridges did not support full-duplex mode or VLAN tagging. Moreover, they didnot typically possess multipath switching fabrics, meaning that simultaneous burstsfrom several interfaces would cause congestion. This was tolerable with a small

A.4 Ethernet 239

number of ports but became a limiting factor on the number of ports a bridge couldreasonably support.

An Ethernet switch (which is also called a LAN switch) is basically a fancybridge that is a device with numerous ports and a multipath switching fabric, as wellas support for VLANs and full-duplex transmission. Bridge is still the term used inthe standards (i.e. bridging functionality is a formally defined thing). LAN switch isa more informal term.

A.4.5 Further Reading

We hope this brief introduction to Ethernet makes it clear that much has changedsince the early days. By way of expository references on Ethernet and its evolu-tion, the books by Spurgeon [27] and Seifert [28] are informative. Spurgeonalso maintains a compendium of information at www.ethermanage.com/ethernet/ethernet.html.

The IEEE 802 LAN/MAN Standards Committee is the key standards body forEthernet and related technologies. The landscape in this active area is still changing,and reference material becomes outdated quickly. For an outline of the IEEE 802standards, the reader can consult [29]. There are numerous active IEEE 802 workinggroups. Examples include 802.17, resilient packet rings, and various wireless initia-tives (802.11, 802.15, 802.16, and 802.20). Additional information is available atgrouper.ieee.org/groups.

References

[1] Simpson, W., RFC 1661, The Point-to-Point Protocol (PPP), IETF, July 1994, Part of IETFSTD 51.

[2] Simpson, W., RFC 1662, PPP in HDLC–like Framing, IETF, July 1994, Part of IETF STD51.

[3] Malis, A., and W. Simpson, RFC 2616, PPP over SONET/SDH, IETF, June 1999.[4] ANSI/IEEE Std 802.2, 1998 Edition, Local and Metropolitan Area Networks—Specific

Requirements Part 2: Logical Link Control, IEEE, 1998, Adopted by the ISO/IEC andredesignated as ISO/IEC 8802-2:1998.

[5] Giroux, N., and S. Ganti, Quality of Service in ATM Networks: State-of-the-Art TrafficManagement, Upper Saddle River, NJ: Prentice Hall PTR, 1999.

[6] Recommendation Q.2931, User-Network Interface (UNI) Layer 3 Specification for BasicCall/Connection Control, ITU-T, February 1995.

[7] ATM Forum Technical Committee, af-sig-0061.000, ATM User-Network Interface (UNI)Signaling Specification, Version 4.0, ATM Forum, July 1996.

[8] ATM Forum Technical Committee, af-pnni-0055.000, Private Network-Network InterfaceSpecification Version 1.0 (PNNI 1.0), ATM Forum, March 1996

[9] Recommendation I.363.1, B-ISDN ATM Adaption Layer (AAL) Specification, Types 1 and2, ITU-T, 1996.

[10] ATM Forum Technical Committee, af-vtoa-0119.000, Low Speed Circuit Emulation Serv-ice (LSCES), ATM Forum, May 1999.

[11] ATM Forum Technical Committee, af-vtoa–0078.000, Circuit Emulation ServiceInteroperability Specification Version 2.0, ATM Forum, January 1997.


[12] Recommendation I.363.5, B-ISDN ATM Adaption Layer Type 5 Specification, ITU-T,August 1996.

[13] Recommendation Q.2100, B-ISDN Signaling ATM Adaption Layer (SAAL)—OverviewDescription, ITU-T, July 1994.

[14] Recommendation I.363.2, B-ISDN ATM Adaption Layer 2 Specification, ITU-T, Novem-ber 2000.

[15] Recommendation I.366.1, Segmentation and Reassembly Service Specific ConvergenceSublayer for the AAL Type 2, ITU-T, June 1998.

[16] Recommendation I.366.2, AAL Type 2 Service Specific Convergence Sublayer for Narrow-band Services, ITU-T, March 2000.

[17] Recommendation Q.2630.1, AAL Type 2 Signaling Protocol—Capability Set 1, ITU-T,December 1999.

[18] Recommendation Q.2630.2, AAL Type 2 Signaling Protocol—Capability Set 2, ITU-T,December 2000.

[19] ATM Forum Technical Committee, af-aic-0178.001, ATM—MPLS Network Interwork-ing Version 2.0, ATM Forum, August 2003.

[20] ATM Forum Technical Committee, af-aic-0196.000, ATM-MPLS Network Interworking(N-to-One Model) Version 1.0, ATM Forum, August 2003.

[21] ATM Forum Technical Committee, af-aic-0197.000, ATM-MPLS Internetworking Signal-ing Specification Version 1.0, ATM Forum, August 2003.

[22] ATM Forum Technical Committee, af-vtoa-0113.000, ATM Trunking Using AAL2 forNarrowband Services, ATM Forum, February 1999.

[23] ATM Forum Technical Committee, af-vmoa-145.001, Loop Emulation Service UsingAAL2 Rev 1, ATM Forum, February 2003.

[24] IEEE Std 802.3, Local and Metropolitan Area Networks—Specific Requirements Part 3:Carrier Sense Multiple Access With Collision Detection (CSMA/CD) Access Method andPhysical Layer Specifications, IEEE, March 2000.

[25] ANSI/IEEE Std 802.1D, 1998 Edition, Local and Metropolitan Area Networks CommonSpecifications Part 3: Media Access Control (MAC) Bridges, IEEE, 1998, Adopted by theISO/IEC and redesignated as ISO/IEC 15802-3:1998.

[26] IEEE Std 802.1Q, Virtual Bridged Local Area Networks, IEEE, May 2003.[27] Spurgeon, C., Ethernet: The Definitive Guide, Sebastopol, CA: O’Reilly and Associates,

February 2000.[28] Seifert, R., Gigabit Ethernet: Technology and Application for High-Speed LANs, Reading,

MA: Addison-Wesley, May 1998.[29] IEEE Std 802-2001, IEEE Standard for Local and Metropolitan Area Networks: Overview

and Architecture, IEEE, February 2002.

A.4 Ethernet 241

About the Author

Matthew Stafford is currently a principal member of technical Staff at CingularWireless, where he works on next generation services. Matthew holds Ph.D. degreesin mathematics (1989, Northwestern University) and operations research (2000,University of Texas at Austin). His career in telecommunications began in 1996with SBC. In 2001, Matthew’s group made the transition to Cingular Wireless.Matthew lives in Austin, Texas.

243

Index

3rd Generation Partnership Project(3GPP), 190, 195

defined, 190QoS standards, 212–15

AAdaptive multirate (AMR) codec, 110–11Address space

IPv4, 67–68IPv6, 68–69

Advanced Intelligent Network (AIN), 181Algorithmic delay, 110Application-level gateways (ALGs), 68Assured forwarding (AF), 78Asynchronous Transfer Mode (ATM),

4, 230–36cell format, 231cells, 46defined, 230header, 230LSRs, 234–35MPLS over, 234–35QoS approach, 230soft-permanent connections, 232statistical multiplexing, 230–31voice over, 233–34, 235–36

ATM Adaptation Layers (AALs), 232–33AAL2, 233–34AAL3/4, 233defined, 232list of, 233

Authentication, 176Authentication, authorization, and accounting

(AAA), 70

BBackhaul example, 12–13Back-to-back user agents (B2BUAs), 157Basic call process (BCP), 182Basic call state models (BCSMs), 182Bearer connectivity

legacy switch, 28next generation switch, 29

Bearer Independent Call Control(BICC), 143–44

defined, 143initial capability set, 144interswitch signaling vs., 170specification, 143–44

Bearer plane, 107–16inhabiting, 143interworking, 111–13separating, 4, 21–30voice encoding, 107–11VoIP, 113–16

Bearer trafficdefined, 11new types, 25–26STPs and, 32

Best-effort service model, 77Billing functionality, 208Border Gateway Protocol (BGP), 73, 221

CCall-control signaling, 4, 33Caller ID service, 34, 35Caller ID subscription, 34Call state model. See Finite state machines

(FSMs)Carrier sense multiple access with collision

detection (CSMA/CD), 238Centrex service, 41Channels, 11Circuit identification codes (CICs), 121, 122Circuit-switched networks

billing functionality, 207–8deployment success, 7emergency service, 208functionality processing, 6–7interworking with, 142–43investment, 7IP routing/dimensioning comparison, 205–6

245

Circuit-switched networks (continued)limitations, 35–36properties, 199–208QoS, 206reliability, 7, 207routing, 26scalability, 207security, 206stability, 205survivability, 207voice optimization, 6

Circuit switchespacket switches vs., 19schematic, 16service plane assistance, 35

Class 5 switches, 41Class-based queuing, 209–10Codecs

AMR, 110–11defined, 107G.711, 107–8waveform, 109

Code division multiple access (CDMA), 58Code excited linear predictive (CELP)

schemes, 109Comfort noise, 115–16Common Channel Signaling 6 (CCS6), 56Constraint-based routing, 211–12Control plane, 31–32

ATM, 231–32illustrated, 32inhabiting, 14location, 34packet-switched, 39separating, 4, 21–30

Customized Applications for Mobile EnhancedLogic (CAMEL), 185

DData link layer, 45–46

defined, 45error detection, 47examples, 45–46responsibilities, 45

Data link layer protocols, 227–40ATM, 230–36Ethernet, 236–40Frame Relay, 227–29HDLC, 227

Data networks, 2Descriptors, Megaco, 130–31, 133, 135, 136Detection points (DP), 182

DiffServ, 78–79, 210–12architecture, 78Code Point (DSCP), 78defined, 78, 210deployment options, 211at edge, 80RFCs, 78

Digital subscriber line (DSL), 189DigitMap, 131Distributed architecture

bearer and control separation, 21–26defined, 11, 21

Distributed fabric, 6, 13Distributed functional plane (DFP), 181,182–83Distributed switching, 14, 40Domain name system (DNS), 69Dual tone multifrequency (DTMF), 112, 143Dynamic Host Configuration Protocol(DHCP), 68Dynamic routing, 26–27

nonhierarchical, 202–3problems, 202

EElectrical and Electronics Engineers (IEEE), 68Electronic numbering (ENUM), 221–22

defined, 221infrastructure, 222

Emergency services, 208Encapsulation, of digital sound, 111–12End office switch, 41Enhanced service offering, 225–26Erlang B formula, 104Ethernet, 236–40

bridges, 238CSMA/CD, 238defined, 236frame structure, 237history, 237hubs, 238switches, 238–40

Expedited forwarding (EF), 78Exterior gateway protocols, 73

FFabrics, 11

defined, 5, 11defining, 16–19distributed, 6, 13intergateway switching, 14, 17, 40

246 Index

packet, 26–30Finite state machines (FSMs)

defined, 53illustrated, 55states, 53, 54state transitions, 53, 54–55

Frame Relay, 227–29defined, 227–28header, 228header fields, 228label switching, 229virtual circuits, 229

Frames, 46Functional localization, 24

GG.711 codec, 107–8

decoder, 112encoder, 112sampling rate, 107voice quality, 108

G.723.1 vocoder, 110G.728 vocoder, 110G.729 vocoder, 110Gateway functionality, 103Gateway MSCs (GMSCs), 102Geographical localization, 25Global functional plane (GFP), 181, 182Global title translation (GTT), 95, 96–98

defined, 95, 96process, 96–97at SCCP layer, 98

HH.323 protocol suite, 148–52

call control, 149–50defined, 148evolution of, 151–52gatekeepers, 150–51heritage, 148–49media control signaling, 149–50terminology, 148tunneling, 152

HDLC, 227Home location register (HLR), 101, 102HTTP digest authentication, 176

IINAP, 185Integrated Local Management Interface

(ILMI), 68

Integrated Services Digital Network(ISDN), 31, 32

call flow, 149User Part (ISUP), 55, 58–59

Intelligent networks (INs), 180–85AIN, 181capability sets, 183–84conceptual model, 181distributed functional plane, 181, 182–83global functional plane, 181, 182JAIN, 186limitations, 184–85signaling protocol, 185SIP and, 186–89trade-offs, 184–85WIN, 185

Interactive voice recognition (IVR), 112Interfaces

on legacy voice switches, 23open, 22–23

Intergateway switching fabrics, 14, 40Interior gateway protocols, 73Internet Engineering Task Force (IETF), 63Internet Protocol (IP), 4, 63–85

addressing/address resolution, 67–69defined, 48differentiated services, 78–79headers, 48, 64–67Mobile, 84MPLS and, 79–80multiservice networks, 80–81QoS, 76–77reachability information, 76routing, 71–76statistical multiplexing, 77–78versions, 63See also IP routers; IPv4; IPv6; protocols

Interswitch signaling, 168–70BICC comparison, 170SIP for, 169

IntServ, 79, 210–12defined, 210deployment options, 211

IP Multimedia Subsystem (IMS), 192–95defined, 192as flexible platform, 192functional elements, 192–93I-CSCF, 193P-CSCF, 192–93S-CSCF, 192, 194services, triggering, 194–95services mobility, 193–94

Index 247

IP packet transfer delay (IPTD), 213IP routers

defined, 48with Ethernet and Frame Relay interfaces,

53packet flow through, 52

IP Security Protocol (IPSec), 70IPv4

address space, 67–68predominance, 63See also Internet Protocol (IP)

Ipv4 header, 64–65fields, 64–65illustrated, 64IPv6 header vs., 67

IPv6address space, 68–69migration to, 63Mobility for (mip6), 219Operations (v6ops), 219ROHC and, 219–21Signaling and Handoff Optimization

(mipshop), 219site-local addresses, 69Site Multihoming in (multi6), 219See also Internet Protocol (IP)

IPv6 header, 65–67extension, 66–67fields, 65–66fixed length, 65illustrated, 66IPv4 header vs., 67performance and, 66

ISDN User Part (ISUP), 55, 58–59call-control signaling, 147call flow diagram, 59defined, 55messages, 58, 59use, 58

ITU-T, 212–153GPP specifications and, 214performance objectives, 213Y.1221 recommendation, 214

JJava Advanced Intelligent Network

(JAIN), 186

LLabel switched paths (LSPs), 79Label switched routers (LSRs), 234–35

Label switching, 229, 230Latency, 142–43Lines, 40Link aggregation, 239Linksets, 91Load balancing, 75Local area networks (LANs), 1

defined, 2virtual (VLANs), 239–40See also Ethernet

Long-distance routing, 200

MMaximum transmission units (MTUs), 65Media gateway controllers (MGCs), 14, 119Media Gateway Control Protocol

(MGCP), 119, 137–42AuditConnection verb, 140AuditEndpoint verb, 140call flow example, 137–38conference call setup, 139–40connection model, 139connections, 139EndpointConfiguration verb, 140Megaco vs., 137, 138–40MoveConnection verb, 141NotificationRequest verb, 140packages, 142response acknowledgments, 141RestartInProgress verb, 141signaling flow, 138virtual endpoints, 139

Media gateways, 40, 119behavior, 24capabilities, 120controller instruction, 18defined, 14functions, 119–22number of, 16switching fabrics, 15

Megaco/H.248, 119, 123–37Add command, 126Audit/Capabilities command, 126Audit Value command, 126call flow, 126–29call flow illustration, 126call setup, 127call teardown, 127–28call waiting example, 129, 137CHOOSE wildcard, 132commands, 125–26, 127conference call example, 135

248 Index

connection model, 123–24connection model illustrations, 124, 125contexts, 124–25, 131descriptors, 130–31, 133, 135, 136MGCP vs., 137, 138–40Modify command, 126Move command, 126, 129–30Notify command, 126packages, 137properties, 130sample messages, 132–34ServiceChange command, 126Subtract command, 126terminations, 124, 131three-way calling example, 134–36transport, 137

Message Transfer Part Level 1 (MTP1), 56, 93Message Transfer Part Level 2 (MTP2), 56–57,

94defined, 56protocol entries, 94sequence numbers, 56signal units, 94

Message Transfer Part Level 3 (MTP3), 57fields, 95routing capabilities, 94

Metastable states, 203Middlebox transversal, 217–19Mobile Application Part (MAP), 56, 57–58,

100–103GSM signaling flows, 101messages, 102, 103Update Location Request, 101

Mobile IP, 84Mobile switching centers (MSCs), 100–101

defined, 100Gateway (GMSCs), 102

Mobility management, 58, 100Motivation, this book, 7–8Multiplexing, 50Multiprotocol label switching (MPLS), 79–80

at core, 80IP QoS and, 80philosophy, 79

Multiservice networks, 80–81

NNetwork address translation (NAT), 67–68,

217–19Network layer, 46Network optimization, 71–76

defined, 71

model limitations, 72objectives, 72

Next generation switchesbearer connectivity, 29benefits, 22defined, 14fabric definition, 15, 16features, 22as geographically distributed entities, 128schematic representation, 17signaling between, 143–44with signaling paths, 18See also Switches

Next generation switching architectures, 21

OOffer/answer model, 167–68Open interfaces, 22–23Open Service Access (OSA), 186Open Shortest Path First (OSPF), 72–73

defined, 72–73routers, 73

Organization, this book, 7–8

PPacketization delay, 113Packets

defined, 18fabrics, 26–30header information, 18SCTP, 82

Packet switchescircuit switches vs., 19in inter gateway switching, 17

Packet telephonycarrier motive/opportunity, 5–6case for, 2–3economic benefits, 3in maturation cycle, 225motivation, 21–30services, 3telco deployment, 225universality, 4

Parameter negotiation, 174Parlay, 185–86Per-hop forwarding behaviors (PHBs), 78Permanent virtual circuits (PVCs), 231Physical layer, 47Playout buffers, 113Point codes, 92Poisson arrival process, 204

Index 249

Policing, 212Policy-based admission control, 215–16Priority queuing, 210Private branch exchanges (PBXs), 41Private network-network Interface

(PNNI), 232Protocols, 43–61

ATM, 230–36BGP, 73BGP-4, 221design, modularity in, 147–48Ethernet, 236–40Frame Relay, 227–29FSM and, 53–55H.323 suite, 148–52HDLC, 227INAP, 185IP, 48, 63–85layer 4, 81–84MGCP, 119–44OSPF, 72–73RADIUS, 70RIP, 73routing, 72–75RSVP, 79RTP, 113–16SCTP, 82–84SIP, 152–57SS7, 55–69STUN, 218summary, 60–61TCP, 48–51TRIP, 221UDP, 52–53, 81–82, 83–84

Protocol stackdata link layer, 45–46defined, 43generic layer descriptions, 44–48last in/first out data structure comparison,

44network layer, 46physical layer, 47process, 43–44SS7, 89, 92–93summary, 60transport layer, 46

Proxy servers, 155, 156–57defined, 156function, 157stateful, 156stateless, 156See also Session Initiation Protocol (SIP)

PSTN and Internet Interworking (PINT),186–87

aim, 186RFC, 186

Public land mobile networks (PLMNs), 41Public-switched telephone networks

(PSTNs), 40Push to Talk, 190–91

QQuality of service (QoS), 39

3GPP standards, 212–15ATM, 230–31attributes in SDP, 173–74circuit-switched networks, 206defined, 77framework, 77IP and, 76–77MPLS and, 80statistical multiplexing and, 84traffic engineering in IP networks and,

209–15Queuing

class-based, 209–10priority, 210weighted fair (WFQ), 210

RReachability information, 76Real Time Transport Protocol (RTP), 113–16

Control Protocol (RTCP), 114header, 114payload formats, 115–16uses, 113

Redirect servers, 155, 156–57defined, 156functions, 156response, 165See also Session Initiation Protocol (SIP)

Registrars, 157Registration, admission, and status (RAS)

signaling, 149–50, 151illustrated, 151necessity of, 151

Re-INVITEs, 171Reliability, 207Remote Authentication Dial-In User Service

(RADIUS), 70Resource ReSerVation Protocol (RSVP), 79

signaling, 171SIP and, 171–74

250 Index

Traffic Engineering (RSVP-TE), 212RFCs

DiffServ, 78PINT, 186SIP-T, 174SPIRITS and, 189

Round-robin scheduling, 210Routesets, 92Routing, 39

circuit-switched networks, 26constraint-based, 211–12data network schemes, 39dynamic, 26–27, 202–3fixed hierarchical, 203hot spots, 75link cost adjustment and, 76long-distance, 200loop example, 74packet networks, 26–29protocol convergence, 73–75protocols, 72–75scalability, 75telco, 199–200trade-offs, 75–76

Routing Information Protocol (RIP), 73

SScalability, circuit-switched networks, 207Scheduling algorithms, 210SCTP, 52–53, 82–84

common header, 82data chunk header, 83defined, 82header fields, 83packets, 82SS7 traffic and, 217TCP comparison, 83–84use, 216

SDPng, 216Secure/Multipurpose Internet Mail Extensions

(S/MIME), 176Security, 176

circuit-switched networks, 206TLS, 176

Segmentation/reassembly, 50Service architectures, 222Service control points (SCPs)

defined, 34, 89description, 91representation of, 91

Service creation environment, 36Service-level agreements (SLAs), 215–16

Service planecircuit switches and, 35illustrated, 35inhabiting, 143

Services, 3, 32–33alternative billing schemes, 33caller ID, 34, 35implementing, 179–97introducing, 23–25maintaining, 23–25operational definition, 32short message, 33SIP and, 186–89SS7 architecture, 180–85unconditional, 33vertical, 32–33

Services in PSTN requesting Internet services(SPIRITS), 186–89

aim, 187functionality, 187gateway, 188RFC status and, 189schematic configuration, 188

Session control, 145–57“generic,” 145–48H.323 protocol suite, 148–52signaling flow for, 146SIP, 152–57

Session Description Protocol (SDP), 119,122–23

defined, 122detailed example, 159–61line types, 161offer/answer model, 167–68payload, 166QoS attributes in, 173–74scope, 122SDPng and, 216

Session Initiation Protocol (SIP), 100, 152–57back-to-back user agents, 157basics, 152–55call, making, 164–67call flow, with resource management, 172definition, 153detailed example, 161–68end-to-end encryption, 176forking requests, 168functional entities, 155–57header compression, 192, 221HTTP digest authentication support, 176identifiers, 153–54INs and, 186–89

Index 251

Session Initiation Protocol (SIP) (continued)for interswitch signaling, 168–70methods, 154, 170–71methods definition, 154offer/answer model, 167–68proxy servers, 155, 156–57redirect servers, 155, 156–57registrars, 157registration illustration, 162registration procedures, 161–64requests and responses, 154–55response message categories, 155response status codes, 155RSVP and, 171–74services and, 186–89signaling flow, 152strengths, 170in wireless networks, 190–95See also SIP-T

Short Message Service (SMS), 179, 195–96defined, 33in support of other applications, 196use, 195

SigComp, 191Signaling

call-control, 4, 33gateways, 14, 40interswitch, 168–70between next generation switches, 143–44RAS, 149–50, 151

Signaling Connection Control Part (SCCP),57, 95–98

classes of service, 95GTT, 95, 96–98in-sequence delivery, 95

Signaling System 7. See SS7Signaling transfer points (STPs)

bearer traffic and, 32defined, 31responsibilities, 31routing decisions, 31

SIP-T, 174–76interworking requirements, 175RFC, 174transparency requirement, 175See also Session Initiation Protocol (SIP)

Softswitches. See Next generation switchesSpanning trees, 238–39SS7, 55–59, 89–105

addressing, 91–92architecture, 89–91defined, 55

footprint, 100ISUP, 58–59ITU-T standards, 89link types, 90MAP, 56, 57–58, 100–103message types, 56MTP1, 94MTP2, 56–57, 94MTP3, 57, 94–95network management traffic, 93networks, 89packet formats, 93point codes, 92protocol stack, 89, 92–93routing, 91–92routing example, 96SCCP, 57, 95–98SCPs, 89, 91service architectures, 180–85signaling transfer points, 90strengths, 105subsystem number, 92summary, 103–5TCAP, 57, 98–100“traditional” stack illustration, 93traffic over IP network, 82–83voice switches, 90weaknesses, 104

Stability, 205States

active, 53analyzing information, 53, 54collecting information, 53, 54defined, 53idle, 53routing and alerting, 53, 54See also Finite state machines (FSMs)

State transitions, 54–55defined, 53illustrated, 55See also finite state machines (FSMs)

Statistical multiplexing, 77–78ATM, 230–31control plane, 231–32QoS and, 84switches, 231

STUN protocol, 218Subsystem number (SSN), 91, 92Survivability, 207Switches, 11

“big,” 16circuit, 15

252 Index

Class 5, 41components, 14–15components illustration, 16defined, 11design, 3–4end office, 41Ethernet, 238–40legacy voice, 22, 23packet, 17See also Next generation switches

TTCP/IP networking, 51–52Telco routing, 199–200Telephony Routing over IP (TRIP) protocol,

221Time division multiple access (TDMA), 58Time division multiplexing (TDM), 41TISPAN, 222Traffic contracts, 212Traffic engineering, 203–4

defined, 199in IP networks, 209–15telco routing and, 199–200

Traffic intensity, 203Traffic shaping, 212Transaction Capabilities Application Part

(TCAP), 57, 98–100components, 99defined, 98invoke component, 99number portability, 99–100queries, 100reject component, 99return error component, 99return response component, 99transactions, 99

Transcoding, 111Transmission Control Protocol (TCP), 48–51

alternatives, 52–53applications running over, 48defined, 48flow control, 49, 50, 84functionality, 49–50header, 48–49multiplexing, 50ordering, 84segmentation and reassembly, 50sequencing/eliminating duplication, 49–50sophistication, 50UDP/SCTP comparison, 83–84See also Protocols

Transport layer, 46Transport Layer Security (TLS), 69

hop-by-hop basis, 176working group, 69

Truitt’s model, 200–202topology, 201triangle, 202

Trunks, 40Tunneling, 152

UUDP, 52–53, 81–82, 83–84

header, 82TCP comparison, 83–84uses, 81

Uniform Resource Locators (URLs), 69User-Network Interface (UNI), 232

VVertical services, 32–33Virtual circuits (VCs), 229Virtual home environment (VHE), 193–94Virtual LANs (VLANs), 239–40Virtual paths (VPs), 234Vocoders

defined, 109G.723.1, 110G.728, 110G.729, 110GSM adaptive multirate, 110–11

Voice codecsbit rates, 29low bit-rate, 29–30

Voice encoding, 107–11digital, 108G.711 codec, 107–8G.723.1 vocoder, 110G.728 vocoder, 110G.729 vocoder, 110

Voice over ATM, 113Voice over IP (VoIP), 113–16

carrier grade, 113protocol routing, 221

Voice telephony, 1–2

WWaveform codecs, 109Weighted fair queuing (WFQ), 210Wireless Intelligent Network (WIN), 185

XX.25 protocol, 227–28

Index 253

Recent Titles in the Artech HouseTelecommunications LibraryVinton G. Cerf, Senior Series Editor

Access Networks: Technology and V5 Interfacing, Alex Gillespie

Achieving Global Information Networking, Eve L. Varma et al.

Advanced High-Frequency Radio Communications, Eric E. Johnson et al.

ATM Interworking in Broadband Wireless Applications, M. Sreetharan andS. Subramaniam

ATM Switches, Edwin R. Coover

ATM Switching Systems, Thomas M. Chen and Stephen S. Liu

Broadband Access Technology, Interfaces, and Management, Alex Gillespie

Broadband Local Loops for High-Speed Internet Access, Maurice Gagnaire

Broadband Networking: ATM, SDH, and SONET, Mike Sexton and Andy Reid

Broadband Telecommunications Technology, Second Edition, Byeong Lee,Minho Kang, and Jonghee Lee

The Business Case for Web-Based Training, Tammy Whalen and David Wright

Centrex or PBX: The Impact of IP, John R. Abrahams and Mauro Lollo

Chinese Telecommunications Policy, Xu Yan and Douglas Pitt

Communication and Computing for Distributed Multimedia Systems, Guojun Lu

Communications Technology Guide for Business, Richard Downey,Seán Boland, and Phillip Walsh

Community Networks: Lessons from Blacksburg, Virginia, Second Edition,Andrew M. Cohill and Andrea Kavanaugh, editors

Component-Based Network System Engineering, Mark Norris, Rob Davis, andAlan Pengelly

Computer Telephony Integration, Second Edition, Rob Walters

Customer-Centered Telecommunications Services Marketing, Karen G. Strouse

Deploying and Managing IP over WDM Networks, Joan Serrat andAlex Galis, editors

Desktop Encyclopedia of the Internet, Nathan J. Muller

Digital Clocks for Synchronization and Communications, Masami Kihara,Sadayasu Ono, and Pekka Eskelinen

Digital Modulation Techniques, Fuqin Xiong

E-Commerce Systems Architecture and Applications, Wasim E. Rajput

Engineering Internet QoS, Sanjay Jha and Mahbub Hassan

Error-Control Block Codes for Communications Engineers, L. H. Charles Lee

Essentials of Modern Telecommunications Systems, Nihal Kularatna andDileeka Dias

FAX: Facsimile Technology and Systems, Third Edition,Kenneth R. McConnell, Dennis Bodson, and Stephen Urban

Fundamentals of Network Security, John E. Canavan

Gigabit Ethernet Technology and Applications, Mark Norris

Guide to ATM Systems and Technology, Mohammad A. Rahman

A Guide to the TCP/IP Protocol Suite, Floyd Wilder

Home Networking Technologies and Standards, Theodore B. Zahariadis

Information Superhighways Revisited: The Economics of Multimedia, Bruce Egan

Installation and Maintenance of SDH/SONET, ATM, xDSL, and SynchronizationNetworks, José M. Caballero et al.

Integrated Broadband Networks: TCP/IP, ATM, SDH/SONET, and WDM/Optics,Byeong Gi Lee and Woojune Kim

Internet E-mail: Protocols, Standards, and Implementation,Lawrence Hughes

Introduction to Telecommunications Network Engineering,Second Edition, Tarmo Anttalainen

Introduction to Telephones and Telephone Systems, Third Edition,A. Michael Noll

An Introduction to U.S. Telecommunications Law, Second Edition,Charles H. Kennedy

IP Convergence: The Next Revolution in Telecommunications,Nathan J. Muller

LANs to WANs: The Complete Management Guide, Nathan J. Muller

The Law and Regulation of Telecommunications Carriers,Henk Brands and Evan T. Leo

Managing Internet-Driven Change in International Telecommunications,Rob Frieden

Marketing Telecommunications Services: New Approaches for a ChangingEnvironment, Karen G. Strouse

Mission-Critical Network Planning, Matthew Liotine

Multimedia Communications Networks: Technologies and Services,Mallikarjun Tatipamula and Bhumip Khashnabish, editors

Next Generation Intelligent Networks, Johan Zuidweg

Open Source Software Law, Rod Dixon

Performance Evaluation of Communication Networks, Gary N. Higginbottom

Performance of TCP/IP over ATM Networks, Mahbub Hassan andMohammed Atiquzzaman

Practical Guide for Implementing Secure Intranets and Extranets,Kaustubh M. Phaltankar

Practical Internet Law for Business, Kurt M. Saunders

Practical Multiservice LANs: ATM and RF Broadband, Ernest O. Tunmann

Principles of Modern Communications Technology, A. Michael Noll

A Professional’s Guide to Data Communication in a TCP/IP World,E. Bryan Carne

Programmable Networks for IP Service Deployment, Alex Galis et al., editors

Protocol Management in Computer Networking, Philippe Byrnes

Pulse Code Modulation Systems Design, William N. Waggener

Security, Rights, and Liabilities in E-Commerce, Jeffrey H. Matsuura

Service Level Management for Enterprise Networks, Lundy Lewis

Signaling and Switching for Packet Telephony, Matthew Stafford

SIP: Understanding the Session Initiation Protocol, Second Edition,Alan B. Johnston

Smart Card Security and Applications, Second Edition, Mike Hendry

SNMP-Based ATM Network Management, Heng Pan

Spectrum Wars: The Policy and Technology Debate, Jennifer A. Manner

Strategic Management in Telecommunications, James K. Shaw

Strategies for Success in the New Telecommunications Marketplace,Karen G. Strouse

Successful Business Strategies Using Telecommunications Services,Martin F. Bartholomew

Telecommunications Cost Management, S. C. Strother

Telecommunications Department Management, Robert A. Gable

Telecommunications Deregulation and the Information Economy, Second Edition,James K. Shaw

Telecommunications Technology Handbook, Second Edition, Daniel Minoli

Telemetry Systems Engineering, Frank Carden, Russell Jedlicka, and Robert Henry

Telephone Switching Systems, Richard A. Thompson

Understanding Modern Telecommunications and the InformationSuperhighway, John G. Nellist and Elliott M. Gilbert

Understanding Networking Technology: Concepts, Terms, and Trends,Second Edition, Mark Norris

Videoconferencing and Videotelephony: Technology and Standards,Second Edition, Richard Schaphorst

Visual Telephony, Edward A. Daly and Kathleen J. Hansell

Wide-Area Data Network Performance Engineering, Robert G. Cole andRavi Ramaswamy

Winning Telco Customers Using Marketing Databases, Rob Mattison

WLANs and WPANs towards 4G Wireless, Ramjee Prasad and Luis Muñoz

World-Class Telecommunications Service Development, Ellen P. Ward

For further information on these and other Artech House titles,including previously considered out-of-print books now available through our In-Print-Forever®

(IPF®) program, contact:

Artech House Artech House685 Canton Street 46 Gillingham StreetNorwood, MA 02062 London SW1V 1AH UKPhone: 781-769-9750 Phone: +44 (0)20 7596-8750Fax: 781-769-6334 Fax: +44 (0)20 7630-0166e-mail: [email protected] e-mail: [email protected]

Find us on the World Wide Web at:www.artechhouse.com

signaling and switching for packet telephony

Documents