Mobile IP Technology for M-Business [1st ed.] 1580533019, 9781580533010, 9781580534581

Citation preview

TE AM FL Y

Mobile IP Technology for M-Business

Mobile IP Technology for M-Business Mark Norris

Artech House Boston • London www.artechhouse.com

Library of Congress Cataloging-in-Publication Data Norris, Mark. Mobile IP technology for M-business / Mark Norris. p. cm. — (Artech House mobile communications series) Includes bibliographical references and index. ISBN 1-58053-301-9 (alk. paper) 1. TCP/IP (Computer network protocol). 2. Mobile communication systems. 3. Mobile computing. 4. Internet service providers. I. Title. II. Artech House mobile communications library. TK5105.585 .N67 2001 621.382’15—dc21 2001022885

British Library Cataloguing in Publication Data Norris, Mark Mobile IP technology for M-business. — (Artech House mobile communications series) 1. Internet telephony 2. Mobile communication systems I. Title 621.3’85 ISBN

1-58053-458-9

Cover design by Yekaterina Ratner

© 2001 ARTECH HOUSE, INC. 685 Canton Street Norwood, MA 02062 All rights reserved. Printed and bound in the United States of America. No part of this book may be reproduced or 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 writing from the publisher. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Artech House cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. International Standard Book Number: 1-58053-301-9 Library of Congress Catalog Card Number: 2001022885 10 9 8 7 6 5 4 3 2 1

Contents

1

2

Acknowledgments

xi

The mobile explosion

1

1.1 The mobile telephone network 1.1.1 The GSM standard

3 5

1.1.2

6

GSM in operation

1.1.3 Evolving standards 1.2 The addition of data 1.2.1 GPRS components

7 8 9

1.2.2 GPRS in action 1.3 State of the market 1.3.1 Some recent history

11 13 13

1.3.2 Market dynamics 1.4 About this book 1.5 Summary Selected bibliography

14 17 18 19

A segmented market

21

2.1 GPRS revisited 2.1.1 The big picture

22 22

2.1.2

26

Interfaces and information

2.1.3 It will all end in tiers 2.2 Deployment configuration options 2.2.1 Direct connection

27 29 30

v

Mobile IP Technology for M-Business

vi

3

4

5

2.2.2 Indirect connection 2.3 A deployment scenario 2.4 Summary Selected bibliography

31 32 37 38

Mobile IP

39

3.1 Basic operation 3.2 The care-of address 3.2.1 Discovery

40 44 44

3.2.2

Registration

45

3.2.3

Tunneling

46

3.2.4 Termination 3.3 Location information 3.3.1 Keeping information current 3.4 The end-to-end view 3.5 Status of mobile IP 3.6 Summary Selected bibliography

48 49 50 51 55 56 57

Addressing

59

4.1 IP addressing basics 4.1.1 Class A addresses

60 61

4.1.2

62

Class B addresses

4.1.3 Class C addresses 4.2 Registered and unregistered addresses 4.2.1 Benefits of private addressing

63 69 72

4.2.2 Disadvantages of private addressing 4.3 Static and dynamic addressing 4.3.1 Benefits of dynamic addressing

73 73 75

4.3.2 Disadvantages of dynamic addressing 4.4 Address management 4.5 Summary Selected bibliography

75 76 77 77

Routing

79

5.1 IP routing basics 5.1.1 Router attributes

81 81

5.1.2

88

Exterior/interior gateway routing protocols

Contents

vii

5.1.3

Distance vector protocols

90

5.1.4

Path vector protocols

95

5.1.5 Link state protocols 5.2 Distance vector protocols in detail 5.2.1 Routing information protocol 5.2.2

Interior gateway routing protocol

101

5.2.3 Enhanced interior gateway routing protocol 5.3 Path vector 5.4 Link state protocols 5.4.1 Open shortest path first

103 111 114 115

5.4.2

116

OSPF in operation

5.4.3 Integrated intermediate system to intermediate system 5.5 Choosing the right protocol 5.5.1 Convergence

121 126 126

5.5.2

CPU utilization

127

5.5.3

Bandwidth efficiency

128

5.5.4

Memory overhead

129

5.5.5

Scalability

130

5.5.6

Stability

131

5.5.7

Technology/service independence

131

5.5.8

Interoperability/open standards support

132

5.5.9 Security 5.6 Summary Selected bibliography

6

96 98 98

M-business

133 134 135

137

6.1 The spectrum of m-business 6.1.1 Business travel

138 139

6.1.2 Commercial on-line services 6.2 The back-end components of m-business 6.2.1 Catalogs

140 141 141

6.2.2

Payment systems

142

6.2.3

Settlement

143

6.2.4 Presentation 6.3 Design requirements 6.3.1 Ensuring network performance

143 144 146

6.3.2

149

Maintaining the network

Mobile IP Technology for M-Business

viii 6.4 Security 6.4.1 Understanding the threat

156 157

6.4.2

Guarding against attack

159

6.4.3

Security solutions

160

6.4.4 Security technology 6.5 Summary Selected bibliography

7

Future prospects

165 176 177

179

7.1 Deployment issues 7.1.1 Transparent mode

180 181

7.1.2

184

Nontransparent mode

7.1.3 The corporate VPN in transparent mode 7.2 Overview of end-to-end VPN operation 7.2.1 Business aspects

188 189 189

7.2.2

191

Partnering

7.2.3 Billing models 7.3 Into the future 7.4 Summary Selected bibliography

Appendix A The Internet Protocol, Versions 4 and 6

191 192 194 194

195

A.1 Overview of the Internet Protocol A.1.1 Addressing

196 202

A.1.2

Routing

204

A.1.3

Mapping IP addresses to physical locations

206

A.1.4

Moving data from the network to the application

207

A.1.5

Naming and addressing

208

A.1.6 Using names instead of IP addresses A.2 IP Version 4 limitations and constraints A.3 IP Version 6 development and features A.3.1 Addressing

208 210 212 212

A.3.2

Performance

215

A.3.3

Security

216

A.3.4 Autoconfiguration A.4 Impact of IP Version 6 on mobile data A.4.1 Security

217 217 218

Contents A.4.2

ix Route optimization

A.4.3 Source routing Selected bibliography

Appendix B Short-range interconnection technology B.1 Technologies compared B.2 Bluetooth B.3 IrDA B.4 Summary Selected bibliography

Appendix C The third-generation mobile network

218 218 219

221 223 225 227 230 230

231

C.1 A brief guide to UMTS C.2 Perspectives on the third generation C.3 Migrating to the third generation C.3.1 From GSM

232 233 233 233

C.3.2

234

From CDMA

C.3.3 From TDMA C.4 Implications for mobile data C.5 Summary Selected bibliography

Appendix D Mobile devices

234 234 235 236

237

D.1 Handheld devices D.2 Security D.2.1 Link security

238 239 240

D.2.2 Device security—smart cards D.3 Mobile operating systems D.4 Delivering m-business D.4.1 Telecommunications Information Networking Architecture

243 249 251 251

D.4.2

Jini

251

D.4.3

Wireless Knowledge

252

D.4.4 IBM Transcode Selected bibliography Web sites

252 252 253

Mobile IP Technology for M-Business

x

255

About the author

277

Index

279

TE

AM FL Y

Glossary

Acknowledgments

I

would like to thank those kind individuals who contributed their ideas, advice, words, pictures, and experiences to add interest and authority to this book. Some deserve special mention; I am particularly indebted to David Sutherland, Steve Pretty, Andrew Frost, and Steve West. And it would be remiss of me not to mention the team at Artech House— Dr. Julie Lancashire, Sharon Horn, Ruth Harris, and Judi Stone—who supported and encouraged me throughout the process. I am indebted to Malcolm Oliphant. His sharp observations, constructive criticisms, and helpful suggestions run throughout the entire book and do much to add to the quality of the final product. Mark Norris Debenham, England July 2001

xi

CHAPTER

1 Contents

The mobile explosion

1.1 The mobile telephone network 1.2

The addition of data

1.3

State of the market

1.4

About this book

1.5

Summary

Too much of a good thing is wonderful. —Mae West

O

nly a few years have passed since Arthur C. Clarke observed that “any sufficiently advanced technology is indistinguishable from magic.” Since then, one piece of magic has been made possible through advanced technology—the communication device used by just about every space hero on film and TV has arrived. Handheld computers that give you access to remote servers are now a reality, and the technology that makes them work is the subject of this book. Of course, things are not quite as the prophets and visionaries predicted. The servers providing the information are not well versed in alien culture and the geology of distant planets. They are more likely to be familiar Web servers attached to the Internet or an organization’s private network. And the device is not a special government issue device available to only a select few but,

1

2

Mobile IP Technology for M-Business

typically, a palm computer, fitted with a modem, available at any mall store, or a data-enabled mobile phone. Whatever the form, the function is the same. The technology of mobile computing is now sufficiently advanced to allow you access to information from wherever you might be. You should make sure you do not confuse mobile computing and networking with the portable computing and networking that has been possible for some years. In this book we are looking at a world where activities are not disrupted when the user moves from one point of attachment to another. Instead, all of the needed reconnection occurs automatically, behind the scenes, as an inherent feature of the system. Most of the protocols deployed at the moment to support information networks do not work well when the host moves between networks. The substrate of the Internet, the Internet Protocol or IP, implicitly assumes that the point at which a device attaches is fixed. Indeed, the address assigned to the device identifies the network to which it is connected—if that device moves to another network, the new point of attachment is not reflected if the original IP address is kept. As a consequence, routing protocols are unable to route packets correctly and, hence, the continuity of service is lost. The only way around the problem is to reconfigure the device every time it is moved, but the Internet is not a willing player in hide-and-seek games with wayward hosts. Clearly, there has to be a better way. This book explains the technology that enables true mobility for handheld devices. At the heart of this is the enhancement to the IP protocol, usually referred to as mobile IP, that allows a computer to roam freely on the Internet while maintaining the same IP address. A mobility protocol that allows a user to roam and not lose his or her connection is part of the magic, but more is needed if we are to see the complete network and service picture. Starting with the users, we have seen a proliferation of powerful handheld devices. The immediate point of attachment for these devices is the mobile communication network, built initially to carry voice traffic but now being enhanced to carry data. Behind the air interface lies a worldwide network of computers: the Internet. Advances in the protocols and services offered by this network promise to give users access to information wherever they may be. And the prospect is not simply one of more readily available information. Because many private networks use the IP suite of protocols, mobile users can access their private company data and services as they move around.

The mobile explosion

3

The purpose of this book is to give a comprehensive account of mobile data. In particular, it will explain how services available to users of both the Internet and of corporate (also known as enterprise or virtual private) networks can be extended to users as they roam from one place to another. Some time before Arthur C. Clarke uttered his famous words, Blaise Pascal noted that “the most difficult thing in any work is knowing what to put first.” Trying to explain a set of technologies that combine to produce magic is proof positive of Pascal’s words. Even so, all stories have to start somewhere, so this first chapter focuses on the networks that serve mobile devices and to which IP routers can attach. We give a brief resume of the growth of mobile services, with particular emphasis on the recent emergence of the GSM-based data service called GPRS. The essential network components required for mobile data are introduced and their place in the current mobile operator’s architecture is explained.

1.1

The mobile telephone network

The speed with which the mobile telephone network has grown is remarkable. In a little over 20 years it has come to rival the established fixed network, one that took 100 years to reach its current state. Predictions have been made that 1 billion mobile phones will be in use by the year 2003. Anything that develops as rapidly as the mobile phone network— which has experienced typical growth rates of 40% per annum—will inevitably seek to develop new services for its already large and everincreasing user community. Hence the drive to add data to the existing voice capability. To understand how this will happen, this section builds a picture of the current network and shows how it is evolving to support mobile data. First, some basic facts. Two factors limit any system based on airborne transmission: the limited natural resource of the radio spectrum and the technology available to exploit it. The first of these limitations was eased when Bell Labs devised the idea of frequency reuse as far back as the 1950s. But it was not until the early 1980s and the advent of the microprocessor that the idea was demonstrable and could be deployed in practical networks and equipment. Cellular telephony makes efficient use of the spectrum by dividing geographic coverage into small areas (or cells) each having its own radio

4

Mobile IP Technology for M-Business

base station. The cells are grouped into clusters and radio channels allocated to each cluster according to a regular pattern, which repeats over the coverage area (Figure 1.1). The smaller the number of cells in a cluster, the greater the number of radio channels per cluster and, hence, the greater the traffic carrying capacity of the cells. There is a penalty—the less distance between clusters, the greater the interference between clusters. The ratio of repeat distance to cell radius and of signal strength to interference for each of the configurations shown in Figure 1.1 can be readily calculated, as illustrated in Table 1.1.

2 1

Basic cell unit

4 3

Repetition to provide coverage 2 1 2 1

4 3

2

4 3

1

4

2

3

1

4 3

Figure 1.1

A typical cell repeat pattern.

Table 1.1 Planning Guidelines for Cell Repeat Patterns Number of Cells

4

7

Repeat distance/cell radius

3.5

4.6

6.0

13.7

19.4

24.5

Signal/interference (dB)

12

The mobile explosion

5

Because there is no fixed point of connection to a mobile network and in order to support roaming among cells, all mobile networks need to carry out some form of location management. Cellular networks are divided into administrative domains called location areas, which identify (approximately) the region in which a caller is located. The administrative domain holds the subscription records for a customer in a home database and this is used both for call connection and for accounting. Any handovers required between cells during a call are dealt with by call processing within the network Several radio system technologies are currently in use. The older analog systems include the Total Access Communications System (TACS) and the Advanced Mobile Phone System (AMPS). The more recently introduced digital systems include the Global System for Mobile Communications (GSM) and DCS-1800 (now called GSM-1800). GSM also appears on the 1900-MHz band (GSM-1900) in North America and Chile and has recently been specified for the 450-MHz band elsewhere. GSM has some competition in the form of the IS-136 and IS-95 systems. The former employs radio techniques similar to those in GSM, and the latter exploits some spread-spectrum radio techniques. For the purposes of illustration, we use GSM here, because many of the early mobile data offerings are based on this technology, and GSM is, by far, the most significant of the current digital cellular technologies. 1.1.1

The GSM standard

GSM uses a bandwidth of 200 kHz for each separate channel and, within each of the channels, accommodates a bit rate of 270 Kbps. The bit stream is divided up into a series of frames with a pattern repeating at a rate of 217 times per second. Each of the frames has eight slots within it. Each of the slots has a duration of 0.577 m/s and, at the given bit rate, this corresponds to 156.25 bits. The bits contained within each slot are made up of some overhead bits, some fixed patterns, and, predominantly, the bits allocated for the signal itself. The fixed patterns are there to allow the equalizers within the overall system to adapt to the characteristics of the radio signal, and the overhead bits allow control over the handset to base station dialogue to be effected. GSM encodes speech signals at a rate of 13 Kbps and this is protected against error by adding some extra bits to the transmitted stream. The resultant gross data rate is 22.8 Kbps.

6

Mobile IP Technology for M-Business

The frequency allocations for most GSM systems are 900 to 960 MHz for base stations and 890 to 915 MHz for the handsets. Also reserved are 1800 to 1880 MHz for base stations and 1710 to 1785 MHz for handsets in the GSM-1800 deployments. 1.1.2

GSM in operation

A GSM service works in much the same way as the established analog mobile system (Figure 1.2). First, the handset makes contact with the nearest base station, which then feeds into a base station controller. This establishes where the handset is currently located. The base station controller is linked to a mobile switch center that can interface to other mobile switch centers as well as to the fixed network. As a call progresses, a path to the handset is maintained through whichever base station is appropriate. Call continuity is effected through a visitor location register, which ensures that all active calls are tracked and connected to the right base station. The base stations themselves are deployed in a cell formation over the geography so that the handset can always be contacted. Over and above the tracking aspects of the system, a number of other controls are in place. An equipment identity register is kept so that the

Base station transceiver

Base station control

Gateway Telephone network

Mobile switch center Equipment identification

Home location register Authentication center

Figure 1.2

The structure of a GSM network.

Billing

Visitor location register

The mobile explosion

7

system knows what can and cannot be connected to the network. An authentication register contains details of acceptable subscriber identification modules (these are the cards inserted into the mobile handset). A home location register contains information on the class of service that a particular customer is allowed to enjoy. 1.1.3

Evolving standards

If we were to speculate on the future shape of radio system technologies, we would look at the convergence of fixed and mobile networks, now being explored through an initiative known, variously, as International Mobile Communications (or IMT2000), Universal Mobile Telecommunications Service (UMTS), or Third Generation Mobile (3G). Operating licenses for third-generation service have been awarded in several countries but services have yet to appear, so discussion is confined to prospects for the future. For now, we use the established GSM standard as a reference. The status of a few of the other candidate technologies and standards for the mobile network are given in Table 1.2. There is, of course, a lot more to the multibillion-dollar mobile telephony network than we have presented in this short treatment. The Table 1.2 Some of the Various Candidate Technologies That Enable Mobile Data Technology

Timescale

Comments

UMTS

2003

A true global standard, likely to offer significant speed advantage over GPRS.

Enhanced Data Rates for GSM 2001 (Global) Evolution (EDGE)

A less stringently specified variant of GSM that offers higher data rates but requires new radio equipment and upgraded devices.

Time-Division Multiple Access Now (TDMA)

Established in the United States and unlikely to be superseded until UMTS arrives. TDMA is converging with GSM on General Packet Radio Service and EDGE technologies.

Code-Division Multiple Access Now (CDMA) (IS-95-B)

The CDMA version of GSM’s GPRS extension.

High-Speed Circuit-Switched Data (HSCSD)

Now

Circuit-switched system that requires only a software upgrade to GSM infrastructure, but does require new user devices.

Wireless Access Protocol (WAP)

Now

Adds Web browsing and e-mail to WAP-enabled phones.

8

Mobile IP Technology for M-Business

reader should understand that there are even more possibilities for wireless local-area networks (LANs) and personal access networks (PANs). Even so, we have introduced the key components needed to link a mobile device to the computers that supply its services. Many excellent texts catalog every detail of any of the current mobile technologies available for the purpose.

1.2

The addition of data

The growth of the Internet has spurred the development of a number of fast data access technologies for mobile phones. Until recently, data was carried over the GSM network in much the same way that a computer dials up a connection to an Internet service provider (ISP). The connection was a dedicated one, which means that the user was attached for the duration of the call. The typical speed of connection was limited to around 14.4 Kbps. The second generation of GSM introduces General Packet Radio Service (GPRS), which allows mobile devices to send and receive packets of information without using a dedicated connection. Why is packet data technology important? It is important because packets provide a seamless and immediate connection from a mobile device to the Internet or to a corporate intranet. This allows all of the existing Internet applications such as e-mail and Web browsing to operate smoothly without having to dial into an ISP. Services such as BT Genie exemplify this capability (see www.genie.co.uk). From the network provider’s point of view, the advantage of a packet-based approach such as GPRS is that it uses only the shared medium, in this case part of the precious radio spectrum, for the duration of time that data is actually being sent or received. This means that multiple users can share the same radio channel, which promises efficient use of radio spectrum. In contrast, current circuit-switched connections have users retrieving and sending their packets over dedicated connections during their entire call, whether or not they are actually sending or receiving data. Because many applications have idle periods during a session, waste is inevitable in circuit-switched connections, particularly as the applications become more asymmetric. With packet data, users will pay only for the amount of data they actually communicate, and not the idle time. The idle time wasted in dedicated connections can be given to other users sharing the same portion of the radio spectrum. In fact, with

The mobile explosion

9

1.2.1

GPRS components

AM FL Y

GPRS, users could be “virtually” connected for hours at a time, yet incur only modest “connect” charges. An interesting aspect of GPRS is how it achieves its high speeds even though circuit-switched data today is limited to 9,600 or 14.4 Kbps. GPRS uses the same radio channel as a voice call, a 200-kHz-wide channel. This radio channel carries a raw digital radio stream of 271 Kbps. For voice calls this stream is divided into eight separate data streams, each carrying about 34 Kbps. After protocol and error correction overhead, about 14 Kbps is left for each voice connection—and the same for a data connection. Circuit-switched data today allocates one of these voice channels for each data user. GPRS works by combining up to eight channels, and since each of these can deliver up to 14 Kbps of data throughput, the net result is that a group of users can get peak rates of more than 100 Kbps. But not all eight voice channels have to be used. In fact, the most economical implementations will be ones that limit the bandwidth offered to each user, leaving some capacity spare for other purposes. The GPRS standard defines a mechanism by which a mobile station can request the amount of bandwidth it desires at the time it establishes a data session.

TE

To extend the GSM network shown in Figure 1.2 to support GPRS, several new components need to be overlaid on the existing ones, and these are shown in Figure 1.3. In this figure, the packet data moves between the Internet and the mobile terminal along the GGSN, SGSN, and BSC/BTS path. Note that the established circuit-switched elements are still in place—the SGSN, GGSN, and so on are additions, not replacements. All of the existing traffic moves between the mobile terminal and the public telephone network via the MSC and BSC/BTS. The new components shown in the diagram are not just notional blocks on a picture—they exist and are available from most of the large suppliers. Companies such as Nortel Networks, Nokia, and Lucent have all adapted their existing switches to the routing capability provided in the SGSN and GGSN. The actual functions of the elements shown in Figure 1.3 are as follows: ◗

PCU: This is the interface between the packet radio (BTS/BSC), where packets come into and leave the network on a synchronous,

10

Mobile IP Technology for M-Business MSC/VLR

HLR

Gb BTS/BSC

Gi

Gn SGSN

To the Internet

GGSN

PCU Gp PCU - Packet control unit SGSN - Serving GPRS support node GGSN - Gateway GPRS support node Gx - Standard GPRS network interfaces Figure 1.3

To another mobile operator

The main components and interfaces of a GPRS network.

connection-oriented link, and the packet network interface (known as the Gb interface), which is asynchronous and connectionless. The PCU is usually located inside the BSC in place of one of its trunking cards. ◗

GGSN: This holds the routing information for attached GPRS users and provides the external gateway, both to the Internet and to other external packet networks (such as the X.25 network, which is used for many financial applications).

◗

SGSN: This is the data equivalent of the mobile switch center (MSC) and visitor location register (VLR). It provides mobility management and authentication, as well as routing of the packets.

A couple of relevant observations on Figure 1.3 would be, first, that the GPRS network forms only part of an end-to-end data service and, second, that the figure shows only one mobile operator. The whole mobile data picture does not emerge until the interaction with other operators, the design of the core IP network, and the nature of the services offered are all clear. These topics are very much the subject of later chapters. We will avoid wireless details in what follows so as to keep our attention on the packet data network issues; we will consider the details only when we need them.

The mobile explosion 1.2.2

11

GPRS in action

In operation, a GPRS device appears to work in much the same way as a standard mobile phone—both communicate with a base station and the attached infrastructure, which provide authentication, connection, and service. Some significant differences do exist, however; the main one being that GPRS allows users to be continually “connected” to the network. Instead of sending data over a fixed destination, dial-up connection, GPRS allows packets of data to be inserted into a permanently available stream. The packets from different users in a cell are interleaved so that the “always-on” transmission capacity is shared with no permanently preset time slots allocated to an individual. Hence, capacity can be allocated when needed and released when not. The GSM data rate of about 14.4 Kbps, available through a fixed connection, is replaced in GPRS by access to up to eight time slots with a combined capacity of about 14.4 Kbps for each of the eight time slots. The exact data rate depends on radio conditions. How much of this capacity is available can vary. As well as contention with other users, different versions of GPRS have different characteristics. For instance, Class 8 GPRS can handle up to five contiguous time slots—four receive and one transmit—to give a downstream data rate in excess of 50 Kbps. Class 12 allows any combination of transmit and receive within the five time slots. All packets transmitted on the available time slots are sent from the base station (BTS) by the serving GPRS support node (SGSN). An SGSN can support multiple base stations. As indicated earlier, the SGSN keeps track of all of the mobiles within its service area. When a mobile device sends packets of data, they go via the SGSN to the GGSN, which converts them for transmission over the desired network, which could be the Internet, one of the X.25 networks, or a private network. Packets received from the Internet (i.e., IP packets) addressed to the mobile device are received by the GGSN, forwarded to the appropriate SGSN, and then transmitted to the mobile user. To forward packets between each other, the SGSN and GGSN encapsulate them using a specialized protocol called the GPRS tunnel protocol (GTP), which operates over the top of standard TCP/IP protocols. The details of the SGSN and GGSN are both invisible and irrelevant to the user who simply experiences a straightforward IP connection—it just happens to be wireless. Protocols and procedures have been established to govern the way in which a mobile device accesses and works with a GPRS network. These

12

Mobile IP Technology for M-Business

are quite complex—the relevant standards (notably ETSI EN 301 344— GPRS service description) give a comprehensive treatment. For now, we need to highlight a couple of the details of the interaction between the mobile device and the network, because they are directly relevant to subsequent ideas. The first detail is the way in which the mobile device makes itself known to the network. This operation, known as an “attach,” establishes a logical link between the device and the SGSN. The attach operation also exists in the legacy circuit-switched mobile networks, where it is used to make the mobile terminal’s location and authenticity known to the network. It is only when the mobile terminal needs to move traffic over the radio interface that a “connection” is established for the purpose. As well as authenticating the device and establishing its location, the attach procedure sets up the address of the mobile device. One of the options for this is to allocate a static IP address; this is known as static PDP addressing in the GPRS specifications. The static PDP address would usually be held in the HLR (although it is possible to hold it in the subscriber identification module or SIM card in the mobile device). Alternatively, a temporary IP address can be allocated. This address, known as the dynamic address, would be linked to the mobile device for a duration determined by several possible events. For instance, the end of a session or the movement of the user away from his or her point of attachment might trigger the allocation of another dynamic address. There are various options for the dynamic address. It can be allocated by the mobile network being visited or by the user’s home network. It can be structured in any of the IP address formats. The impact of the IP address format and management is explored in considerable depth in later chapters. The second detail to note at this point is that the GPRS GGSN node will have to connect to some device on another network (e.g., a border router through the Gi interface to connect to the Internet). In addition to the physical connection, the protocol used at this network interface needs to be considered as part of the overall network design. The various options and trade-offs in this area are treated in some depth. Once the connection and addressing issues are attended to, it might appear that the “transparent” transport of packets enabled by GPRS means that m-business is a twin of “standard e-business” with added roaming capability. However, a few practical issues and opportunities need to be considered at this level too. Again, this is an issue for later.

The mobile explosion

1.3

13

State of the market

Before we get into the fine technical details of how mobile IP services can be delivered, we should consider the marketplace in which those services will be offered. This section looks at some of the issues that any player—however good their technology—should consider. 1.3.1

Some recent history

Data services have, to date, largely been the domain of specialist operators. They have tended to offer packet radio access to a relatively small market segment, one with a clear and commercially justified need for such communication. Given this small and, to a large extent, dependent customer base, there have been no economies of scale, little competition, high equipment prices, and limited service development. This has resulted in a low market penetration, typically a few tens of thousand users in the United Kingdom, for instance. Similarly, although data services have been available to the millions of cellular users for many years, their uptake has been very limited. The main cause is inconvenience—specialized equipment (the PC card and the phone’s cable) can be hard to find and a high level of expertise is required to use the services effectively. So, despite working quite well, current GSM data services are only convenient money saves for users who have the patience and know-how to use them. The introduction of GPRS promises to build on a sound base and make data services altogether more popular. The availability of relatively cheap handheld devices (from suppliers such as Psion, Handspring, and Agilent) opens the door on mass access to mobile data services. Furthermore, the way in which GPRS operates promises reasonable access speeds (at least comparable with that of a PC dialing up via a modem), and moderate prices (due to the more efficient use of available bandwidth). The question remains of whether people really want to send and receive information as they move around. The evidence that they do can already be seen with the increasing popularity of the Short Message Service (SMS). Although each SMS message is limited to 160 characters, the service is increasingly being used for a variety of information and alerting services. One of the main reasons for the popularity of SMS is that it is an end-to-end data service. It is easy to use and its limitations are clearly evident. The chief advantage of GPRS is that it lets the PC behave more or less like it does in a wired dial-up connection even while on a wireless one. Hence, it shares the SMS attraction of being easy to use and

14

Mobile IP Technology for M-Business

familiar. The success of GPRS will, to a large extent, depend on how it capitalizes on this feature to offer appealing services. Despite some operators charging 15 cents a message, a rate that is more expensive than many off-peak tariffs for a whole minute of talk time, it is estimated that there are more than 9 million regular SMS users in Europe. It appears that the pent-up demand is there. The question then is one of what factors will accelerate the use of mobile data? 1.3.2

Market dynamics

Three critical factors will contribute to the development of the mobile data market, as discussed next. Increasing ubiquity of the Internet

Businesses, recognizing the value of readily available information, have introduced IP-based virtual private networks, or intranets that allow access to centrally held and managed corporate information. Furthermore, in the United States, and now increasingly in Europe, the Internet and its associated technologies are becoming an important tool in an information-rich society. E-commerce is beginning to become an accepted channel to market: Goods and services are purchased over the Internet and immediate access to information is becoming the standard. In both the business world and the consumer market, familiarity with—and reliance on—these services will create the pressure to have them available at all times, wherever the user is. Quite simply, companies that do not accommodate the needs of their mobile workers by the end of 2004 will fail. It is quite easy to envisage a world where people rely on their communicator. Realistic technology scenarios

The advent of ubiquitous packet data services to the mobile device during 2002 and 2003, as provided by GPRS in the GSM world, could be a standard offering. Combine this with the trend toward larger mobile displays and intuitive keypad and speech-based entry of text and a host of new services becomes practical on mobiles that look similar to the models available today. Broadened supply base

Mobile data services tend to blur some of the traditional supply options. Because the end-to-end service mixes established telecommunications

The mobile explosion

15

(the domain of Ericsson, Siemens, Nokia, Lucent, and Nortel) with IT and data networking (where players such as Microsoft, Sun, 3Com, and Cisco operate), each company is trying to build “turn-key” solutions. They all now realize that mobile telecommunications has become a mainstream business and their products must be capable of the full breadth of technological requirements. This has led to the introduction of new concepts and investments in the development of new ideas and of expertise and know-how. There is one problem, though, with a highly competitive supply base. Because of their very different pedigrees, the approaches advocated by each supplier will differ. For instance, the telephony-centric players may focus on issues of throughput, while those with an IT heritage might be more concerned with logical design. The danger is that a variety of solutions will be offered, the customer will become confused, scale efficiencies will not be achieved, and the market will remain fragmented. For all of the opportunity and promise of mobile data and its waiting users, the prospective service provider needs to bear certain issues in mind. One of these issues has been hinted at already. This is that because it is founded on the convergence of several technologies it can be difficult to establish a good end-to-end understanding. Indeed, the general dearth of a broadly based reference was one of the main motivations in writing this book. Another caveat for the prospective service provider has to do with timing. Announcements of new GPRS plans seem to appear regularly in the trade press but enthusiasm for this new technology among some of the GSM operators is less than fulsome. For instance, although two of the four U.K. operators have announced deals for infrastructure, the worldwide total shows commitment from only around 10 out of the 300-plus GSM operators. This is not an indication of lack of confidence in the technology, but a more realistically cautious approach to the impending “data revolution” currently being touted by many industry commentators and equipment manufacturers. Although a considerable capital outlay is required for an operator to implement GPRS, this may not, in the short term, be the primary cost of the service. The service requires dedicated radio resources, both for control channels (to allow signaling between the mobile device and the network) and for carrying user data packets. If the headline speeds of up to 115 Kbps are to be offered to the customer, then a whole radio carrier, with all eight of its time slots, would have to be dedicated to GPRS—a

16

Mobile IP Technology for M-Business

resource that could otherwise be used to carry eight simultaneous voice calls. As explained above, because GPRS is packet based, many more than eight users can share the same resource if none of the users requires all eight time slots for their applications. Even so, the trade-off between income from packet data against loss of income from having less telephony capacity is one that operators will have to work out. In the short term it seems likely that many operators will tend to cling to their voice services for income. This is not that simple a judgment. The allocation of valuable radio resources to GPRS may have several knock-on effects. For instance, it effectively lowers the grade of service for voice users (by denying them access to some radio resources, so more “network busy” failures occur at peak times) and reduces trunking efficiency and, therefore, overall network capacity. A less obvious (but potentially crucial) issue is that the complexity of billing for service becomes significantly more complex, particularly for operators used to billing for timed connections. If usage charges are levied for the number of packets sent and received, then an established operator will have to collect two types of call records (one based on time, the other on volume). These records may also have to be reconciled with other operators and combined into one user’s bill. Returning to the issue of revenue lost by reallocation of phone capacity, this can be particularly acute because the wireless operator is not, by itself, in a position to provide the end-to-end service that GPRS will facilitate. Traffic will typically be generated by third-party services and applications—for instance, entertainment portals or businessspecific solutions. There is every expectation that some operators will forge liaisons with content providers but, in general, the advent of GPRS is expected to herald a change in the structure of the cellular service value chain. The popularity of solutions offered will be largely content dependent and so will rely on the nature of the service value chain. It seems more than likely that some or all of these factors have led to the majority of operators adopting the “wait-and-see” approach. Operators may wait for applications such as WAP to establish a significant data market using conventional circuit-switched connections before redeploying resources to a packet network. If they then find that mobile data really do take off, they can then introduce GPRS and have the resources almost immediately fully utilized, thus taking full advantage of the capacity gains that will then be available.

The mobile explosion

1.4

17

About this book

The ultimate purpose of this book is to give the reader a comprehensive, end-to-end account of mobile data. In particular, it aims to explain the technology that allows services available to users of the Internet and corporate networks to be continually provided as they roam from one place to another. We bring together several areas that are often seen as specialized ones in their own right—network design, electronic and mobile business, and IP protocols. Because of this eclectic approach, here is brief overview of what lies ahead. This chapter has set the groundwork by reviewing, at a high level, the current infrastructure that supports the mobile user. The way in which the GSM network, which provides telephony and basic data services to millions of people, is evolving in a packet-based data network is explained. Chapter 2 follows up on some of the issues raised about the mobile data market by illustrating the various configurations that could emerge to provide end-to-end service. The next three chapters contain the technical details of how a mobile data service works. Chapter 3 introduces the Mobile-IP protocol and explains how it operates. Chapter 4 takes one of the key practical issues that affects the workings of the overall network—IP address management—listing what the various options are and what the impact of each one is. This group of technical chapters is completed in Chapter 5, which gives an in-depth treatment of routing protocols, including a suitability assessment of each one. The last part of the book is all about what sort of applications are likely to be carried over a mobile data network. In particular, the potential for m-business service is considered in Chapter 6, and an illustration of the practical issues and options in building mobile data network is given in Chapter 7. To complete the book, appendixes provide information on general issues that seem likely to impact the future of mobile data: the migration from IP version 4 to IP version 6, the development of third-generation mobile, the range of mobile device types, and the prospects for short-range connection technologies such as Bluetooth. Table 1.3 is intended to help the reader navigate the book as a whole. Some parts contain a lot of technical detail, others are more discursive—a quick reference to the ratings given in Table 1.3 could well minimize your chances of being bogged down or bored.

18

Mobile IP Technology for M-Business Table 1.3 Summary of Contents Technical Content

General Interest

Specialist Detail

Chapter 1

∗∗

∗∗∗∗

Chapter 2

∗∗

∗∗

∗∗∗

Chapter 3

∗∗∗

∗∗∗

∗∗∗∗

Chapter 4

∗∗∗

Chapter 5

∗∗∗∗∗

Chapter 6

∗∗

∗∗∗∗

∗∗∗

Chapter 7

∗∗

∗∗∗

∗∗

Appendix A

∗∗∗∗∗

Appendix B

∗∗

∗∗∗

Appendix C

∗

∗

Appendix D

∗∗

∗∗∗

Glossary

∗

∗

∗∗∗ ∗∗

∗

∗∗∗∗ ∗∗∗∗∗

∗

∗∗∗∗∗ ∗∗∗ ∗∗ ∗∗ ∗∗∗∗

To help those who prefer an occasional dip into the technical parts of the book, rather than a concerted attack, we have appended a fairly large glossary that should help you through the more challenging sections.

1.5

Summary

In a world that has become more and more dominated by communications and information, networks are key. And with an ever-increasing demand for mobile services, it seems likely that it will be radio-based networks that grow to meet this demand. This chapter has introduced the main components of a mobile network. To start with, it outlines the current, voice telephony-centric network. It then moves on to show how, with the addition of new elements, this network can be enhanced to carry packet-based data. This is a significant development because it opens the door on providing Internet services to roaming users. In deference to the fact that we are dealing with a promising but, as yet, unproven technology, the second part of this chapter considers the market for mobile data. In particular, we look at the drivers that will push it forward and some of the issues that need to be considered by prospective service providers.

The mobile explosion

19

Although uncertainties remain about which standards will prevail and, crucially, how much traffic will be generated, we can expect the mobile operators to take a cautious stance in the enhancing of their networks to support the new services. In any one market, however, the first mover can be expected to gain credibility and become well positioned to take a major share of the data traffic when it reaches an economic level.

Selected bibliography ETSI Standard EN 301 344, Digital Cellular Telecommunications System, General Packet Radio Service, Service Description, version 7.1.1, 2000, www.etsi.org. Holma, H., and A. Toskala, WCDMA for UMTS, New York: John Wiley & Sons, 2000.

AM FL Y

Kopomaa, T., The City in Your Pocket, London: Gaudeamus, 2000. Muller, N., Wireless Data Networking, Norwood, MA: Artech House, 1995. Norris, M., P. Muschamp, and S. Sim, “The BT Intranet; Information by Design,” IEEE Computer, Vol. 5, No. 3, 1999, pp. 59–66. Prasad, R., Third Generation Mobile Communications Systems, Norwood, MA: Artech House, 2000. Tisal, J., GSM Cellular Radio Telephony, New York: John Wiley & Sons, 1997.

TE

Van Nee, R., and R. Prasad, OFDM for Wireless Multimedia Communications, Norwood, MA: Artech House, 2000.

CHAPTER

2 Contents 2.1

2.2 Deployment configuration options 2.3 A deployment scenario 2.4

A segmented market

GPRS revisited

Faith is believing what you know ain’t so. —Mark Twain

Summary

O

ne of the most noticeable trends in the telecommunications industry during the last few years is how diversified it has become. Not that long ago the national telephone companies offered little more than a single service—telephony. These days, it is quite common for people to buy not only their telephone service but also their Internet services, on-line content, and high-speed data network from the likes of BT and France Telecom. And just as the large telephone companies, or telcos, have diversified, so have many of the other providers who once resided in a specialist market niche. The utility companies, banks, and supermarkets all now compete with the telcos. This is particularly noticeable in the United Kingdom, where many people get their telephone service from an offshoot of the electricity company Energis and their Internet services 21

22

Mobile IP Technology for M-Business

from one of the main supermarkets, such as Tesco. Perversely, these same people may well choose BT for their on-line shopping. The net effect of all this is that many communications offerings now involve several providers, working in concert. The long awaited convergence of networks, information technology, content, and user electronics has well and truly arrived and this is nowhere more evident than in the area of mobile data. Many options are available for assembling a mobile data service. Some of the components that are needed were introduced in the last chapter. Here we take an end-to-end view and explain how the various pieces of the overall service, potentially from separate sources, fit together. First, though, a more detailed picture of a GPRS network is in order.

2.1

GPRS revisited

In the last chapter we saw how extra elements can be added to a GSM network to give it GPRS capability. Now we need to look in a little more detail at how the various components of the GPRS network operate and how they fit into an overall data network. As in the last chapter, we will avoid the enormous mountain of details in the radio interface of GPRS networks, and remain comfortable in our assumption that it works for our purposes; packets are moved between base stations and mobile terminals as if there were wires between them. Readers who are interested in the radio aspects are directed to the GPRS and GSM references at the end of this chapter. 2.1.1

The big picture

If we step back from the detail of individual network elements to look at the end-to-end infrastructure that supports mobile data, the picture would be like that shown in Figure 2.1. The clear point in this figure is that the mobile operator’s network is one of a number of end points when viewed from the IP core in just the same way that an Internet service provider (ISP) or Internet is. Hence, the provision of an end-to-end service for mobile users is a special case of a more general IP design. Of course, the characteristics of the local delivery network cannot be overlooked—it may look like another subnetwork when viewed from the IP core, but it is a subnetwork that needs to be understood if it is to be used effectively.

A segmented market

23

ISP Home mobile network operator

Gi interface

IP core

Intranet

Figure 2.1

Visited mobile network operator

The end-to-end view of a mobile data network.

The salient issues in building IP services are the subject of later chapters. For now, we explore a little more of what is involved on the local delivery side. GPRS gateway support node

As shown in Figure 2.2, the GGSN is the gateway between an external packet data network and the GPRS core. It hides the mobile network, making it look like just another part of the data network—an external IP network would see the GGSN as an ordinary IP router, one that serves all of the IP addresses of the mobile devices attached to it. So, from a design point of view, a mobile operator can be treated as one part of an overall IP network that has attached devices within a known address range. The GGSN can (but does not have to) do more than act as an interface between the mobile and IP worlds. As well as serving a known address range, it can also give addresses to mobile devices when they need them. If the attached devices are allocated a dynamic IP address, this is done by the GGSN.

24

Mobile IP Technology for M-Business Gi interface

Gn interface

IP core GPRS network

GGSN

Associated services DHCP DNS Firewall

Figure 2.2

The role of the GGSN.

Dynamic IP address allocation (known as DHCP, which is discussed in more detail in Chapter 4) uses a pool of addresses and allocates them only when needed (i.e., when a user wants to connect to their services). This preserves address space and makes the subnetwork that the GGSN serves appear smaller when viewed by the core network. Looking into the mobile network, the task of the GGSN is to assign the correct SGSN for a given mobile device, depending on the location of that device. In practice, the GGSN usually includes packet filtering and firewall functionality to limit incoming traffic and thus ensure a level of security. One final part of the GGSN’s functionality is to provide the Internet name lookup service, DNS. This is a normal part of an ISP’s role. Whether it was implemented in the GGSN would depend on the boundary between mobile operator and ISP. This is discussed in the next section. Serving GPRS support node

The SGSN is the interface between the data network that lies beyond the GGSN and the radio access network. Just as the GGSN has to route incoming traffic to the correct SGSN, so the SGSN has to route traffic on to the right base station subsystem (BSC/BTS). Its main tasks are to manage the logical link to the mobile device as it moves during a session

A segmented market

25

and to authenticate the mobile device. It also provides a connection to the databases, such as the home and visitor location registers. The SGSN sits at the center of the mobile network and is connected to virtually all of the other elements, as shown in Figure 2.3. This figure adds detail to earlier views of the SGSN. On this occasion, the links that carry both data and signaling (as opposed to signaling only) are shown in bold. Both existing GSM interfaces (such as the C interface) and the new ones introduced for GPRS are shown in Figure 2.3. The key additional interfaces are described below. The packet control unit, which is usually inside the BSC, supports all of the GPRS protocols used for communication over the air interface. The PCU itself sets up, supervises, and disconnects packet-switched calls (this includes radio channel assignments and radio resource configurations). Above the SGSN are the key databases, the Home and Visitor Location Registers (HLR and VLR), which provide the information that allows the SGSN to do its job. The link to both of these databases is signaling only, because the SGSN will make queries but does not transfer data. Also shown in the diagram is the short message service server. The SGSN provides the link between this established GSM service and the GPRS network. SMS C

Gd

MSC/VLR

HLR Gs

Gb BTS

BSC/PDU

Gr Gc Gi

Gn SGSN

GGSN

IP core

Abis Gn

SGSN

Gp

GGSN Another mobile operator

Figure 2.3

The role of the SGSN.

26

Mobile IP Technology for M-Business

Below the SGSN are the remote units with which connections are required to provide a broadly based service. Other parts of this mobile operator’s area will be served by other SGSNs (and associated BSC/PCU), and other operators will serve their own user base in this and other areas via their own GGSNs. In both cases, the link carries both data and signaling information. 2.1.2

Interfaces and information

With reference to Figure 2.3, we should explain a few key interfaces in a little more depth. These are the Gi, Gn, and Gp interfaces that are used to link one part of a GPRS network with another and one mobile network provider with another. Taking these in turn: ◗

Gi: In line with previous descriptions, the Gi interface conforms to the Internet Protocol, IP. At present, the defined basis for interworking is based on IP version 4 (described in Chapter 4 and Appendix A). In some instances, tunneling is needed between the GGSN and the remote intranet or ISP. Because the Gi interface sits on the IP network side of the mobile network, any tunneling protocol supported in the rest of the network can be used (as long as the GGSN can use it). IPsec is a common choice.

◗

Gn: The raw IP data passed over this interface is encapsulated using the GPRS Tunneling Protocol, GTP. In addition to carrying data between the two main GPRS components, GTP supports a small signaling repertoire; create, delete, and update context request and responses. GTP uses UDP and IP as its underlying protocols. Hence, the protocol diagram for information between the SGSN and the GGSN is as shown in Figure 2.3.

◗

Gp: This interoperator connection is used to support roaming users who move from one mobile operator’s network to another’s. The physical connection can be a leased line or through a private or public network. At each end of the Gp interface, a border gateway is provided to ensure security between networks. If a user roams from his home network into another network, a forwarding route is created between the two so that the packets can continue to be exchanged between the user and his host, via the home network.

A segmented market

27

To complete our explanation of the GPRS logical node architecture, we need to see where the various data items are stored (and, by implication, where they are available). In Figure 2.3, data is stored in five places: the GGSN, the SGSN, the HLR, the VLR, and the mobile device itself. Table 2.1 lists some of the items that are available from each. Most of the items listed in Table 2.1 are stored simply to allow the various network elements to communicate with each other. The International Mobile Subscriber Identifier (IMSI) is a global reference for a mobile subscriber and, as such, acts as a unique tag. The IMSI is placed on the subscriber’s SIM card at provisioning time. The protocol type, mobile station (MS) class, and quality of service are all used to specify what sort of connection is required. We assume here that the protocol type is IP (other public data network standards, such as X.25, are also supported). The quality of service and MS class are both service dependent. 2.1.3

It will all end in tiers

One of the peculiarities of GPRS is that it uses the Internet Protocol as its internal standard, irrespective of the type of packets being carried between the mobile device and the GGSN. This can be a source of confusion when the GPRS network forms one part of an end-to-end IP service! To connect the SGSN and GGSN, the GPRS Tunneling Protocol is used. GTP uses one of the Internet transport protocols—either TCP or UDP, depending on whether a reliable connection is needed. When X.25 packets are being tunneled, reliability is required, so TCP is used. For IP packets, UDP suffices. The stack of protocols that sits between the GGSN and the mobile device is shown in Figure 2.4.

Table 2.1 Information Sources in a GPRS Node Network Element

Information Stored

GGSN

SGSN address, protocol type and addresses, quality of service, IMSI

SGSN

GGSN address, VLR address, IMSI, charging data, mobility management state

HLR

IMSI, GGSN address list, MS class, protocol type, quality of service

VLR

IMSI, SGSN address, MS class

Mobile device

IMSI, protocol type and address, channel identifier + parameters for radio interface, quality of service

28

Mobile IP Technology for M-Business

Mobile device

BSS

SGSN

Um

Gb

GGSG Gn

To application server

Application IP

IP SNDCP SNDCP

LLC

LLC

RLC

RLC

MAC

MAC

GSM RF

GSM RF

Figure 2.4

GTP

TCP UDP

IP

GTP

TCP/UDP

IP

The tiers in the GPRS transmission path.

The logical link shown in the diagram between the mobile device and the SSGN is handled by the Sub-Network Dependent Convergence Protocol (SNDCP). This allows an operator to carry either IP packets or X.25 packets without having to change any of the installed equipment. SNDCP also provides header compression, which improves the efficiency of the channel. Logical link control (LLC) operates across the Gb and Um interfaces to establish a connection between the mobile device and the SGSN. The LLC handles flow control, so it can detect and recover from transmission errors. Medium access control (MAC) and radio link control (RLC) work together to segment the LLC’s frames into very small packets, which are addressed to individual mobile terminals in a special format unique to the GPRS radio interface. On their recovery in the receiver on the other side of the radio link, these two layers reconstruct everything for easy handling by the peer LLC. Empty boxes in Figure 2.4 contain internal GPRS protocols—they are not dealt with here because they are confined entirely to the domain of the GPRS node.

A segmented market

29

Now that we have a clear view of the general architecture of a GPRS node and what part it plays in an end-to-end delivery of packets, we can examine some of the possible deployment configurations that might support mobile IP service. The next section looks at four typical configurations and discusses the issues associated with each.

2.2

Deployment configuration options

TE

AM FL Y

With so many points of flexibility, mobile operators, service providers, and corporate networks can play different roles in supporting the roaming user according to the network configuration. So far we have not talked about who provides which bit or bits of the network. In practice, this can have significant impact on how service is provided. In particular, we now consider the prospect for an existing mobile operator in providing the air interface for others and becoming the mobile virtual network operators (MVNOs) for an established service provider. This has the attraction that the mobile operator does not have to build her own data network—she simply “bolts onto” an existing one as a special-purpose subnetwork. In this instance, a number of scenarios are possible. If we sit at the Gi interface (as the flexibility point between our mobile network and IP networks) and consider ownership and connection, there are four basic situations, as shown in Figure 2.5. With reference to the figure, the four options are as follows: I.

Basic IP network access for our mobile operator’s own customers;

II. Basic IP network access for customers of other mobile operators who happen to be using the mobile network (i.e., support for roaming customers); III. As in option I, but to an intranet or an ISP that is not directly connected to our mobile network; IV. As in option II, but to an intranet or an ISP that is not directly connected to our mobile network. The first two on this list imply that the mobile operator has some control over the end-to-end session (direct connection). The second two have the mobile operator more in isolation, dependent on a third party for

30

Mobile IP Technology for M-Business

Visited network

Home network

Home network

Target IP network

Visited network

Target IP network

I

II

III IV Visited network

Home network

3rd party IP network

Figure 2.5

Target IP network

Home network

Visited network

3rd party IP network

Target IP network

End-to-end ownership and connection possibilities.

service completion (indirect connection). We can weigh the pros and cons for both of these general cases. 2.2.1

Direct connection

At this point, it appears to make little difference whether the user is on her home network or visiting from elsewhere. Once the GPRS node has accepted the user, she is logically attached to the same GGSN. This is a bit of a simplification because there may be differences in the profiles of users who are subscribers to different networks. This and details of how visitors are connected to and interact with a GPRS node are considered in later chapters. When the mobile network’s own customers want access to a directly connected IP network, the address allocated to their mobile devices can be handled either by the GPRS node or by the directly connected ISP. This depends on where the DHCP function shown earlier is located. A visiting user will have an address allocated by his or her own home network.

A segmented market

31

For both home and visiting users, the GPRS node will have to accept responsibility for the authorization of the mobile device prior to its connection to an external IP network. And it is possible that this network could refuse to connect certain users (e.g., those with an invalid IP address) or it may disconnect them (e.g., if they send more than an agreed amount of data). The mobile operator and/or the remote IP service will probably need to implement firewalls to protect their respective networks. The characteristics of the firewall need to be agreed on (e.g., whether FTP transfers are allowed or not). In this instance, this is a matter for policy as both sides fall under common ownership. 2.2.2

Indirect connection

In the last two of the cases listed, a tunnel is needed between the GPRS node and the indirectly connected ISP or intranet. The characteristics of the tunnel need to be agreed on between the mobile operator and the ISP. In practice, this may be a simple leased line or frame relay link. Indeed, for option III from Figure 2.5 this would often be the preferred solution because the GPRS node can serve as an alternative access route into a private network. In either case, as the number of users increases, it may be necessary to introduce a more sophisticated connection into the IP network. For example, a hierarchy of connected routers may be used to provide a number of tunnels. Because of the large numbers of tunnels, designers will need to provide some guarantees of the performance of the tunnels. In addition, the mobile operator may have to ensure fairness between users (who may have different agreed service characteristics, particularly the speed of the connections). In option IV from Figure 2.5, it may well be that there is no direct tunnel to the required intranet, so the Internet has to be used. In some cases, some form of end-to-end security protocol (such as IPsec) would need to be added. This would be transparent from the point of view of the GPRS node and the target intranet (i.e., packets would be tunneled between the two). In the case of nontransparent access to an intranet or ISP (i.e., when packets are tunneled from the GGSN), the mobile device would be given an address belonging to the ISP/intranet. In this instance, the GGSN would need a link to the address allocation server (e.g., the DHCP or

32

Mobile IP Technology for M-Business

radius server) belonging to the ISP or intranet for authorization and protocol configuration. Most of the above discussion relates to service delivery. The issues raised need to be addressed and solved either by agreement between the mobile operator and IP network provider or by design of the GPRS node and IP network. Even where the mobile operator wants to connect to several IP networks, it should be relatively straightforward to configure the necessary connections. In practice, the simplest option is by far the direct connection of the mobile operator’s users (whether their own or those roaming from another service provider) to the IP network.

2.3

A deployment scenario

In the last section, we looked at how an existing mobile operator might provide the air interface for others to become the Mobile Virtual Network Operators or MVNO for an established service provider. In this section we take the opposite point of view by considering how an IP network operator might go about extending it’s capability to support mobile users. For the purposes of illustration, we will assume that our mythical operator (known as IPcore) has an established network across several countries and is looking to increase its utilization of what it has, rather than install any significant amount of new equipment. In keeping with its desire to carry more traffic on the network without very much investment, IPcore does not feel inclined to buy any of the GPRS components—SGSNs and the like are heavy-duty items with a price tag to match. Hence, it will need to establish a relationship with a mobile operator (or, perhaps, a number of mobile operators). IPcore’s initial view of how it plans to enable mobile users is illustrated in Figure 2.6. A brief inspection of this figure raises a number of questions. For instance, how does IPcore support its users when they are out of range of the partner mobile operators? This is a point of general concern because most network providers tend to have points of presence in several countries but mobile operators tend to be national. Furthermore, a typical mobile operator will have dense coverage across its chosen base, but a network operator will probably have points of presence only where there is a sizable community of fixed users. The effect of this is that the issues of service provisioning change with geography. A user might be based in one country, where she can access

A segmented market

Mobile operator’s SGSN IPcore edge router

33

Mobile operator’s GGSN

Mobile operator’s SGSN

IPcore network

Remote access server

Mobile operator’s SGSN

Corporate servers Figure 2.6

An IP network provider in collaboration with mobile operators.

the mobile operator, but is a long way from a point of presence on the IPcore network. This same user can roam to another country, where she is close to a point of presence but has no mobile access. Each combination of mobile operator coverage and network operator presence raises different issues. In this scenario we will look at a prospective solution in each case. As before, we have four distinct possibilities, each of which is seen by IPcore as a distinct phase in its deployment schedule. Phase I: Owned fixed and mobile elements are both present

In its initial deployment phase, IPcore intends to partner with a mobile network operator capable of serving a large region (Figure 2.7). The agreement made is that remote users should be recognized by the mobile operator as IPcore customers. Fitting the mobile device with a subscriber identification module (SIM) that identifies who the owner is can effect this. Subscriber characteristics are usually confined to the SIM, which leaves the mobile equipment (ME) as a radio interface between the SIM and the network. Because it knows that a user is an IPcore customer, the mobile operator can route calls as required. Phase I is to be completed by connecting the main IPcore’s points of presence to the mobile operator’s GGSN. These links are implemented as

34

Mobile IP Technology for M-Business Mobile operator’s GGSN GTP GTP Mobile operator’s SGSN IPcore edge router

Mobile operator’s SGSN

Private link GTP

IPcore network

Mobile operator’s SGSN

Remote access server Corporate servers Figure 2.7

Phase I plan for IPcore’s mobile service.

ATM virtual private circuit connections and are brought in from the local telco. Phase II: Owned fixed element is present along with several mobile elements

The next step envisaged by IPcore (assuming that phase I is a success) is to use other mobile operators in order to extend the reach of its mobile service (Figure 2.8). Again, the remote user would need to be recognized as an IPcore customer so that the appropriate routing of calls can be made. It is at this point that some second thoughts occur. What exactly happens to the user as he roams from region 1, served by one mobile operator, into region 2, served by another? Having a user’s identification hard wired into his mobile device (e.g., the IP address on his SIM card) appears to cause problems. This is because guarantees of service require a customer’s identification (i.e., their address) to be temporarily transferred from his home mobile operator to the one he is using as a visitor. So for a call to survive, operator 1 has to somehow ensure that operator 2 can accept and maintain the user’s IP address, because this is what identifies him to the remote servers.

A segmented market

35

Region 1

Mobile operator 1 GGSN

IPcore edge router

Remote access server

IPcore network

Mobile operator 2 SGSN

Corporate servers

IPcore edge router

Region 2

Figure 2.8

Mobile operator 1 SGSN

Mobile Operator 2 GGSN

Phase II plan for IPcore’s mobile service.

The level of coordination needed to track a roaming user is far from simple and is not something that IPcore wants to have handled on an ad hoc basis. The next chapter explains just how a customer can change her point of connection without disrupting her service. Phase III: Owned fixed element is present but mobile is not

In this phase IPcore recognizes that it has no real control over how its customers, calls are handled when they are in this region. The deployment plan, therefore, is simply to capitalize on having a point of presence in this region and to make IPcore servers available by establishing a link from the servers to the GGSNs of the local mobile operator(s). Phase IV: No fixed or mobile elements

This is the most tenuous of IPcore’s propositions in that service can only be offered via a remote point of presence and through a mobile operator of unknown capability.

36

Mobile IP Technology for M-Business

The above considerations are far from complete. From IPcore’s point of view, issues of raising its customer bills when a service is provided by more than one party, of reporting against service level agreements to corporate users, of network faulting, and so forth are all very real and need to be addressed. In addition, the corporate users would need to give consideration to the management of their mobile devices—how software is distributed and updated, keeping inventories, and so forth. Although not the focus in this book, these operational issues are key to the launch of successful mobile services. To close this section, we look at what sort of services IPcore could offer to its users. In the first couple of deployment phases listed above, IPcore can find out where a remote user is located (because this information is available from their cooperative mobile operator). This means that some location

Mobile operator’s GGSN

Credit sent to smartcard

IPcore network

Remote access server Hotel reservation Corporate servers

Payment gateway Flight booking

Figure 2.9

Travel services offered by IPcore.

Mobile operator’s SGSN

A segmented market

37

dependent services can be supported. For instance, IPcore could provide a range of travel services, as illustrated in Figure 2.9. In this figure, a remote user can, for instance, request credit from his organization as he travels on business. Once the user has been authorized, updating a smart card attached to his mobile device with the correct currency can fulfill the request. The way in which the sort of network described here can be used for mobile business—or m-business—is the subject of a later chapter. Of course, other services could also be carried, the most obvious being voice. This would be carried over IP and would take advantage of the cooperation between IPcore and its correspondent mobile operators to preserve the numbering schemes used in corporate networks. This is a whole new area, though, and the focus here remains on mobile data. The next chapter introduces mobile IP and shows how it can be used to support the untethered user.

2.4

Summary

In this chapter we have taken a closer look at the GPRS infrastructure that supports mobile data services. In addition to examining the component parts of a GPRS node in some detail, we have shown where key data is stored and how the various interfaces defined between these components provide points of flexibility. The intent here has been to present those aspects of GPRS relevant to building a mobile IP service; a more comprehensive treatment can be found in the references given at the end of the chapter. In keeping with the aim of using GPRS as a means to an end, we step back from the mobile node in isolation to consider the various options for providing end-to-end service. Taking into account variable factors such as whether a user is on her home network or is a visitor and whether the mobile operator owns any network beyond the GPRS node, we have explored configuration issues that need to be considered as part of the service delivery proposition. To close the chapter, we have highlighted some of the key practical issues in deploying a network that supports mobile data users. A case study that involves an established IP network provider who wants to add mobility to their portfolio is used for illustration.

38

Mobile IP Technology for M-Business

Selected bibliography Black, U., Mobile and Wireless Networks, Upper Saddle River, NJ: Prentice Hall, 1996. ETSI EN 301 344 (defines the point-to-point operation of a GPRS packet data service). ETSI GSM 03.64 (describes the air interface, designated Um, for GPRS). ETSI TS 101 348 (details how GPRS interworks with an IP network). Heine, G., GPRS, EDGE, HSCSD, and the Path to 3G (an interactive multimedia course), Norwood, MA: Artech House/Inacon, 2000. Heine, G., GPRS from A-Z, Norwood, MA: Artech House, 2000. Kalden, R., et al., “Wireless Internet Access Based on GPRS,” IEEE Personal Communications, April 2000, pp. 8–18. Redl, S., et al., An Introduction to GSM, Norwood, MA: Artech House, 1995. Redl, S., et al., GSM and Personal Communications Handbook, Norwood, MA: Artech House, 1998.

CHAPTER

3 Contents

Mobile IP

Basic operation

3.2

The care-of address

3.3 Location information 3.4 The end-to-end view 3.5

Status of mobile IP

3.6

Summary

How much a dunce that has been sent to roam Excels a dunce that has been kept at home. —William Cowper

AM FL Y

3.1

O

TE

ne of the enduring trends in the computing industry over the years has been increasing portability. The centralized computer bureau of the 1970s evolved into the departmental minicomputers of the 1980s and the desktop processors we know today. In effect, the computer has moved closer and closer to its user—so much so that the user and the computer, which can now be slipped into a jacket pocket, often need to be considered almost as one entity. The only problem with this is that people tend to move around when they work. And this means that the conventional notion of a computer’s “point of attachment” to a network needs to be revisited. Users now need to be able to establish and maintain a session between their computer and their network as they roam from one place to

39

40

Mobile IP Technology for M-Business

another. Once connected, a continuous session with no interruptions will be the expectation. The term mobility-enabled IP centric networks is becoming widely used to define networks that fulfill this requirement. These networks use the established Internet Protocol (IP) addressing and routing mechanisms in concert with a new mobility protocol to deliver multimedia traffic to roaming users. To achieve this, the existing definition of the IP protocol has been extended by a team within the Internet Engineering Task Force. The mobile IP now emerging from this team introduces new concepts called the home agent (HA) and foreign agent (FA) as a basis for mobile data, in much the same way that home and visitor location registers were introduced to support mobile telephony. This chapter explains how the home and foreign agents cooperate with a mobile device to support a connection continuously as the user moves from one point of attachment to another. The concept of the “care-of” address, used to identify a roaming user without changing his or her IP address, is introduced and we follow through the various stages of its operation (discovery, registration, and access) in some detail. Bringing all of these concepts together we then go on to show how the Internet Mobile Host Protocol (IMHP) is used to keep a roaming user’s session intact without compromising the integrity of the network that is supporting that session. To close the chapter, we look at a few of the key challenges and issues being addressed in the development of mobile IP.

3.1

Basic operation

At the heart of mobile IP is the fact that the mobile device uses two addresses to ensure that a network connection is not disrupted as its user roams from one place to another. The first of these addresses is a static one, linked to the user’s home network. It is, in effect, the equivalent of the user’s post office box—the permanent location from which his mail and other services are forwarded. The second address changes with the point of attachment to the network and is known as the care-of address. This is used to reach the user at his current location. Just how the care-of address works is detailed in the next section. For now, a brief illustrated resume of the key stages in establishing a mobile IP connection is offered before we explore the details.

Mobile IP

41

To start with, we know that every mobile device has a unique IP address. This is the one that has been assigned to it by the user’s home network. The normal IP routing protocols (see Chapter 5 for a detailed examination of these) deliver packets intended for the mobile device to this IP address and also receive packets from the mobile device for the intended correspondent. If the mobile device is attached to its home network, then that is the end of the story and the packet is delivered as explained in earlier (and later) chapters. If on the other hand, the user has moved away, then it is the job of the home network to forward the packet from the home address to the care-of address (and, hence, to the mobile device, wherever it may be). And this is where the concept of the home agent needs to be introduced. The home agent, or HA, is one of the key components of a network that implements mobile IP. A home agent is a specially designated server that takes responsibility for intercepting and forwarding packets for absent subscribers. The mobile device uses a registration protocol to keep its home agent informed of its current location. As the user roams away from her home network onto a foreign network (or from one foreign network to another), it asks the foreign network to tell the home network where it is. This is where the foreign agent completes the magic. As well as caring for its own users through the HA, a mobile IP network also cares for visitors with a foreign agent (FA). The FA is responsible for finding a visitor’s home network and informing the home network that it has temporary care of that visitor by sending the registration message to its HA. In practice, the home agent and foreign agent services can be configured either on the same router or on separate routers to enable mobile IP service to users. This configuration entails, among other things, the definition of the IP addresses or subnets for which roaming services are allowed. Addressing is covered in more detail in the next chapter; for now we focus on the progress of a call. Following a successful registration, any packets that arrive on the home network for an absent user are forwarded by the HA to the FA. The forwarding is not entirely straightforward, because the static IP address of the user has to be suppressed in favor of their current care-of address. This is achieved through encapsulation—the process of enclosing original packets as data inside of new packets, complete with a new IP header with the new IP address. Returning to our land mail analogy, this is like sticking a new address label over an existing one when forwarding mail to someone who has moved.

42

Mobile IP Technology for M-Business

The source and destination address fields in the header of the new packet correspond to the HA and FA, respectively. Intermediate routers between the home and visited networks are oblivious to encapsulation—if they were aware of the “native” packet, they would see the HA address and simply return the packet to the home network. When the encapsulated packet arrives in the visited network, the FA strips off the temporary wrapping to reveal the original packet, which is then sent to the intended recipient. Needless to say, things do not always follow this script. As users move from one place to another, packets are lost while routing tables at the HA and FA are being updated to reflect a new point of attachment. The effect of these temporary problems is mitigated through the use of retransmissions and acknowledgments. These are used at the transport (e.g., TCP) layer to survive packet loss due to movement between networks as well as congestion and other end-to-end connection problems. All of the above can be summarized in a couple of diagrams. Figure 3.1 shows a couple of networks, both equipped with the two agents that support mobility. The instances where a user is at home and where the user is visiting another network are illustrated. The observant reader will have spotted that packets are always delivered to the home network. This can introduce a level of inefficiency in Mobile agent 2 142.177.3.8 Router

Network 2

142.177.3.1

Internet 142.122.1.9

142.122.1.12

142.122.1.1 Router

Mobile agent 1 Figure 3.1

A mobile device attached to its home network.

Network 1

Mobile IP

43

the end-to-end routing of a connection, but is a consequence of how mobile IP operates, at least at its simplest level. The impact of having to forward packets through a specified point (Figure 3.2) can be mitigated through the use of cache agents, which are explained at the end of this section. To complete this short overview of mobile IP, lets look at how a packet gets to a mobile device hosted on a foreign network, as illustrated in Figure 3.3. In this figure, the mobile device (which has been allocated a static IP address of 142.122.1.12) is receiving a mail message from a computer (known as the correspondent host), which is on a remote network. The IP headers of the packets that form the mail message, as it leaves the correspondent host, have a destination address of 142.122.1.12. The packets are, therefore, routed to the home network of the mobile device, as per conventional IP routing. At this point, the home agent picks up the packet and inserts an additional IP header and forwards it back into the network. The new IP header has a destination address of 142.177.3.1, which routes it to the network being visited. Assuming that all goes according to plan, the registration process has informed the foreign agent about the presence of the mobile device so that, when the encapsulated packet arrives, it knows to remove the outer header to reveal the original IP address and then forward the packet to its intended recipient.

142.177.3.8

Mobile agent 2 Router

Network 2

142.177.3.1

142.122.1.12

Internet 142.122.1.9 142.122.1.1 Router

Mobile agent 1 Figure 3.2

A mobile device visiting a foreign network.

Network 1

44

Mobile IP Technology for M-Business

Foreign network

Foreign agent Step 2 To foreign network

142.122.1.12

Router

142.177.3.1

Step 3 - To mobile device

Internet Router

Step 1 - To home network

142.122.1.1 Router

Correspondent host 123.23.7.11

Home agent 142.122.1.9

Home network Figure 3.3 network.

How a packet gets to a mobile device that is visiting a foreign

The path from the mobile device back to the correspondent host is a little simpler, because the home agent does not need to be involved. Packets pass from the foreign network into the Internet and on to their destination: the correspondent host.

3.2

The care-of address

The idea of having a temporary address at which the user (or rather, his device) can be found is central to the operations of mobile IP services. In this section we uncover the workings of the care-of address, in particular how it is acquired in the first place, how it is registered, and how it is used once set up. We will examine the process through four steps: discovery, registration, tunneling, and termination. 3.2.1

Discovery

This is the process by which a mobile device determines whether it is currently connected either to its home network or to a foreign network. It is based on the established IP mechanism of advertisement, where a node will broadcast information to its neighbors who, in turn, broadcast information (updated with what they have just received) to their neighbors.

Mobile IP

45

In this way, up-to-date information propagates through the network so that routers know what routes are available and, of more immediate interest, mobile devices discover mobility agents. Mobile IP discovery does not involve the modification of existing router advertisements—it simply extends them to associate mobility functions. Hence, a router advertisement can carry information about default routers, per existing practice, but it can also carry information about one (or more) care-of addresses. In keeping with the terminology introduced in the previous section, the router advertisements that have been extended to carry care-of addresses are known as agent advertisements. In operation, both home and foreign agents broadcast agent advertisements at regular intervals. The broadcast frequency is typically around 10 times per minute, although this will vary according to the chosen balance of traffic generated (which is better with few advertisements) against currency of information (which is better with more frequent advertisements). Specific needs, such as bandwidth preservation or accuracy of connection status, would determine the optimal frequency of advertisements. From the user’s point of view, the frequency of advertisements is largely immaterial. If a mobile device needs to get a care-of address, it does not have to wait for the periodic advertisement. It can broadcast a request that can be answered by any agent that is within range. This request takes the form of an established router solicitation (as defined in the RFC 1256 specification). If an advertisement is no longer detectable by the mobile device, the assumption is made that the agent that offered it has gone out of range. In this case another care-of address is sought (unless more than one was found through the initial solicitation). Once a prospective care-of address has been found, the connection process can proceed to the next step—registration of the address. 3.2.2

Registration

At this point, the mobile device and the foreign agent both know about the care-of address, but the home agent is not yet privy to their agreement. To bring the home agent up to date, the mobile device sends it a registration request that contains the care-of address. On receipt of this information, the home agent completes several actions. First, it authenticates the registration request, which is digitally signed by the mobile device to preserve network security. Once authenticated, the home agent can examine the parameters in the request. These parameters define the way in which the home agent can reach the

46

Mobile IP Technology for M-Business

care-of address (i.e., how to encapsulate packets destined for the foreign agent; see the next section for an explanation of the options). At this point, the home agent is in a position to accept the registration request. This triggers it to associate the care-of address with the home address it has for the mobile device and to update its routing table so that any packet destined for the mobile device in question can be forwarded to the newly discovered care-of address. Finally, it approves the registration request by sending a confirmation reply back to the mobile device. Once a registration request has been accepted, it endures until a new registration request is received. If the mobile device fails to reach its home agent, it can attempt to register with another home agent (if there is one!) on its home network. This is known as automatic home agent discovery, and entails the substitution of a broadcast IP address (directed to the IP nodes in the home network) in the registration request, instead of the normal home agent’s IP address. When the broadcast packet reaches the home network, all home agents other than the user’s default home agent will assume that something has gone wrong and issue a rejection notice. This notice contains the address of the alternative home agent(s), and so the mobile device can use this in any new registration request. Now that all of the necessary associations have been validated and recorded, the mobile user can start to interact with the IP network of her choice. The only remaining challenge is to ensure that the packets constitute an exchange of information flow to and from the mobile device, as they should. This is where the third aspect of working with the two-address scheme—tunneling—comes in. 3.2.3

Tunneling

There is a default encapsulation scheme that must be supported by all mobile IP implementations. It is known as “IP-within-IP.” Using this scheme, the home agent, designated as the tunnel source, inserts a new IP header (or tunnel header) in front of the normal IP header of a packet that has been sent to the mobile device’s home address. This newly added tunnel header ensures that the mobile device’s current care-of address is used as the destination IP address, or tunnel destination. The tunnel header is structured to allow the original packet to be extracted—a field in the header is set (i.e., the protocol number in the header is set to 4) to indicate that the next protocol header is also to be interpreted as an IP header (Figure 3.4). This works because IP-within-IP preserves the whole of the original IP packet header in the first part of the

Mobile IP

47

IP packet Extent of tunnel across the network Router

IP packet Router

Packet encapsulated with new header added before sending to network for delivery

IP packet Packet decapsulated and delivered in original form IP packet

Figure 3.4

The basic idea of tunneling.

tunnel header. This means that the foreign agent has only to strip off the tunnel header and deliver what remains to the mobile device. Although IP-within-IP is the default scheme, encapsulation schemes other than IP-within-IP are available to support tunneling. For instance, the minimal encapsulation scheme can carry out the same function as IP-within-IP but with a reduced header overhead. It adds only 8 or 12 bytes to each packet sent to the mobile device instead of the 20 bytes added by the standard IP header in the IP-within-IP scheme. It achieves this at a cost of more complex processing because it uses both the original and tunneling packet headers to restore the IP packet to be delivered to the mobile device. With minimal encapsulation, the home address of the mobile device and the protocol number in the IP header are moved from the original packet header into a forwarding header. The structure of this header is shown in Figure 3.5. Here, the block containing the original source address may be added if encapsulation is not done in the corresponding host. The presence (or absence) of the third block is indicated by setting the S bit in the header. Hence the length of the minimal encapsulation header is 8 or 12 bytes, depending on where the encapsulation is done. Once the forwarding header is complete, the original packet header is changed. As with IP-within-IP, the protocol number is used to indicate

48

Mobile IP Technology for M-Business Byte 1

Protocol

Byte 2

S

Reserved

Byte 3

Byte 4

Header checksum

Original destination address

Original source address (optional)

Figure 3.5

Format of the minimal forwarding header.

the encapsulation method; in this instance it is set to 55. The destination address is set to the care-of address of the mobile device (because this is where the packet is being sent), and the source address is set to the IP address of the machine doing the encapsulation. If the care-of address is incorrect, then there is some clue as to where the encapsulation was done. Because mobile terminals are likely to remain mobile, arrangements between home and foreign agents will need to be revised from time to time. 3.2.4

Termination

As long as the mobile device stays attached to a specific agent, the chosen tunneling mechanism ensures that packets are forwarded from the correspondent to the mobile device and vice versa. This situation can be terminated in a number of ways. Most obviously, the mobile host may move, causing it to reregister and start the process described in this section all over again. Alternatively, the registration lifetime (which is one of the parameters set up during the registration process) may expire. One specific instance that combines both ways of terminating a mobile IP session is for the user to deregister: If the mobile device returns home, it sets its

Mobile IP

49

Location information

TE

3.3

AM FL Y

care-of address to its home address by sending a registration request to the home agent with the lifetime set to zero. We need to look at one final issue before moving on from our examination of the component parts of mobile IP: security. As mentioned earlier on, the mobile device digitally signs its registration request to ensure that the home agent knows that the request is from a bona fide source. In operation, a mobile device is likely to make a number of registration requests as it roams and this opens the way for “replay attacks,” in which an intruder could record a valid registration and use it to fool the home agent and plant erroneous routing information. The digital signature (which is a fixed-length code generated from the data in the registration request) can be protected in either of two main ways. The first is to incorporate a time stamp so that each separate request is different and thus immune from attack. The other is to use a pseudo random number in the identification field that forms part of the registration request—the chances of an impostor guessing a 32-bit random number are small. Both of these mechanisms provide a high degree of protection in a process that, by its very nature, is prone to attack. Some of the consequences of the security approach are considered later in the chapter.

To work as it should, mobile IP requires information to be stored in several places. The home agent needs to maintain a home list that identifies those mobile devices it serves. Associated with each entry on this list should be the current location of each device; in other words, the address of the foreign agent to which the mobile device is connected. The subscriber base for a home network is represented by the combined home lists of all of the home agents on that network. Any node in a network can ask the home agent for the current location of a mobile device. Each foreign agent needs to maintain a visitor list. This identifies all of the mobile devices currently registered with it and comprises the home address of the mobile device and its current location, a combination known as a binding. Each entry in the visitor list has a time stamp, which is generated by the mobile device every time it tries to register with a foreign agent. This time stamp is always included with the binding information and is passed across the network as a security check (see the previous section).

50

Mobile IP Technology for M-Business

Special packets, defined as part of the IMHP, are available that can be used to update location information. Any node in the network can issue a Binding Notify packet to a node that has been detected to have an obsolete or incorrect binding for a mobile device. This mechanism keeps spurious and out-of-date location information to a minimum. Network nodes that are neither home nor foreign agents also need to be considered. Any such node that keeps track of bindings and is able to encapsulate packets is known as a cache agent and the bindings that it maintains are its location cache. The correspondent with which a mobile device is communicating may be a cache agent, in which case it encapsulates packets for that device straight away. 3.3.1

Keeping information current

One of the key advantages of the mobile IP standard over earlier proposals is that it does not flood binding updates through the network. Instead, new bindings are targeted only on those nodes that have incorrect or expired information. As already mentioned at the end of Section 3.2.3, the address of the encapsulating node is included in the header to support this. When a Binding Notify packet is received, the time stamps are compared to determine which of the care-of addresses is the up-to-date version and which one is obsolete. If the Binding Notify contains more up-to-date information than is held already, it is used to modify the cache. If the cache is more up to date, then the Binding Notify is returned. Nodes in the network usually initiate binding updates. There are, however, two instances when the mobile device is the instigator. One occurs when the mobile device notifies its home agent, and the other occurs as an attempt to notify previous foreign agents as it roams. This is illustrated in Figure 3.6. Packets received by the home agent from the network are encapsulated and sent on to the appropriate foreign agent. In addition, the home agent also sends a Binding Notify to the sender of the packet. Because this passes through any intermediate cache agent, it can, if need be, update its location cache. In subsequent operations, packets going along the same route can carry out the necessary encapsulation. Thus, the route is optimized, with the “tromboning” of the packet through the home agent on first pass through being removed. When a mobile device roams and attaches to a new foreign agent, an encapsulated packet might be misrouted to the old foreign agent. In this

Mobile IP

51

Foreign agent

Router

Internet Notify Register

Home agent Router

Figure 3.6

Router

Previous foreign agent

The two actions of the mobile device as it roams.

instance, the agent receiving the packet that should no longer be directed at it reencapsulates the packet with the correct address and sends a Binding Notify to the sender of the misrouted packet to prevent further erroneous delivery. If the agent receiving misdirected packets does not have the correct address for the mobile device, it encapsulates the packet and sends it to the home agent. The home agent can then return a Binding Notify that allows the previous foreign agent to react correctly if any more misdirected packets are received. In just the same way that a registration request has a specified lifetime, so location caches typically have a time-out value for bindings. When the time out expires, the binding is deleted.

3.4

The end-to-end view

In this section we briefly recap what we have learned about the concepts and procedures introduced so far to show how they all fit together when a mobile device wants to communicate with a remote correspondent. For the purposes of illustration, we assume that the required link is between

52

Mobile IP Technology for M-Business

two mobile devices, both of which are roaming and so need to find a foreign agent. The first step is for both mobile devices to register with their current foreign agents and notify their respective home agents of their new bindings (Figure 3.7). If we assume that the originator of the communication is Mark (see left side of Figure 3.7), then the first thing that happens is that his mobile device sends a packet via its current foreign agent to the home agent of the mobile device used by Steve. To do this, Mark need merely know the static IP address that Steve has on his home network. Once the packet arrives on Steve’s home network, it is encapsulated and tunneled to Steve’s current foreign agent, where it is decapsulated and delivered to the intended mobile device (Figure 3.8). When Steve’s home agent receives the packet from Mark’s foreign agent, it can deduce that the sender does not have a binding cached for it. Hence it returns a Binding Notify. This allows Mark’s mobile device to transmit packets without involving the home agents; instead they are tunneled directly between the two foreign agents via intermediate caches, and an optimized route is established, as shown in Figure 3.9. Of course, this happy state of affairs does not persist for very long. One of the two mobile devices will inevitably move away from its foreign agent, thus triggering new activities that are needed to maintain the

HA-1

Registration

Registration

FA-1

Mark Figure 3.7

HA-2

Mobile hosts registering.

FA-2

Steve

Mobile IP

53

HA-1

HA-2

FA-1

FA-2

Mark Figure 3.8

Steve

Initial packet transfer via home agents.

HA-1

HA-2 Binding notify

FA-1

Mark Figure 3.9

Route optimization.

FA-2

Steve

54

Mobile IP Technology for M-Business

session between Steve and Mark. First of all, the mobile device that has moved detects that it is connected to a new foreign agent. (Because it is midway through a session, it would rely on agent advertisements rather than seek a new agent itself.) In Figure 3.10, Steve’s device has registered with the new foreign agent (step 1), which has notified his home agent and also informed the previous foreign agent of the new bindings (step 2), as already explained. Now, consider a situation in which Mark now wants to send a packet to Steve, but believes that he is still attached to the previous foreign agent. In this case, the packet is forwarded to Steve’s new foreign agent where it is decapsulated and delivered locally—the route shown by the dashed line in Figure 3.10. At this point, Steve’s previous foreign agent, FA-2, recognizes that Mark has an old binding for Steve (otherwise the tunnel would have gone directly to the new foreign agent), so it would send a Binding Notify that returns the connection to the state shown in Figure 3.9. Clearly, the details involved with all of the processes just discussed should be included for completeness (such as the encryption of registration requests). Even so, our typical sequences give a good picture of the way in which the Mobile IP components fit together to allow mobile

1. Registration

HA-1

2. Forwarding notification

FA-3

FA-1

FA-2

1. Registration

Mark Steve Figure 3.10

HA-2

Reconfiguration as a mobile host moves.

Mobile IP

55

devices to maintain a session as they roam and for the network that supports the session to maintain its integrity as devices change their points of connection.

3.5

Status of mobile IP

The idea of extending the IP protocol to cater to mobile devices is far from new. Indeed, work has been going on in this area for around 10 years, and several candidate solutions predate the currently proposed standard. These early attempts to solve the mobility problem (e.g., Sony Mobile Host Protocol, IBM Mobile Host Protocol) all shared the approach of keeping the location of the mobile host as a separate piece of information that had to be propagated through the network. The differences were in the way that this location information was defined and propagated. The working group within the Internet Engineering Task Force responsible for developing the mobile IP standard (documented in RFC 2002) has followed many of the principles established by its predecessors. Concepts illustrated earlier in this chapter, such as the care-of address and home and foreign agents, represent the agreed-on format of mature ideas. In addition, aspects of the mobile IP standard, such as the IMHP, improve on previous mobile IP protocols by providing the same functions more efficiently. For instance, the procedure for updating location caches, as we have seen, applies only to those caches and entries detected to be incorrect. In previous versions, the update was less discriminating (and, hence, slower and more resource hungry). Just as important as the refinement of the technical solutions for mobile IP is the fact that it is being standardized under the auspices of the IETF. The earlier attempts in this area were proprietary (led by Sony, IBM) and, however well crafted, were unlikely to receive the universal acceptance of an addition to the established IP repertoire. For all the recent progress and consensus, there is still work to be done on mobile IP. Perhaps the main area of concern centers on security. It is clear from the end-to-end description of mobile IP that strong authentication is needed to guard against attack; the very nature of the registration process offers many opportunities for malicious intervention. The public and private keys used to construct the certificates that validate the identity of a node are effective but are complex to process and can slow operation.

56

Mobile IP Technology for M-Business

A less obvious consideration of the security measures that can be used in mobile IP networks is that firewalls tend to block some types of incoming packets, notably those that appear to enter an intranet with an address of a machine inside that intranet. Hence, a mobile device that tries to connect to another node on its intranet is blocked because packets from the mobile device carry its own home address. The very observant reader will have spotted another issue in the end-to-end connection walkthroughs in the previous section. This is that packets sent from a correspondent, at least initially, take a dogleg route through the home agent. Packets in the reverse direction can, assuming that correspondent is static, be sent direct with no tunneling required. This “triangle routing” means that there is asymmetry and, hence, potential problems in maintaining efficient dialogue between the two parties. These and other issues are being studied as the addressing base for mobile IP moves from IP version 4 to IP version 6. The impact of this migration is dealt with in Appendix A, which also explains the essential differences between the two versions of the Internet Protocol.

3.6

Summary

This chapter introduces the key concepts that make mobile IP possible. Perhaps the most fundamental of these is the notion of the care-of address, a temporary IP address used to identify where a roaming user is located at any particular time. The first part of the chapter explains how home and foreign agents can be introduced into a network to link a user’s care-of address with a static IP address, thus allowing that user’s connection to be maintained, irrespective of his point of attachment to the network. The details of how a connection (i.e., the routing of a packet) is set up and transferred when one party moves her point of attachment is explained and illustrated. Delving into more detail, we introduce cache agents and discuss how they can be used to optimize a route after a session has been established. Overall, this chapter presents a complete view of the main elements that support Mobile IP and how they work together. The final part of the chapter looks at some of the known issues in the area of mobile IP, some of which are the subject of current research. Of course, mobile users form only a part of any real network; indeed, a prime consideration in the development of mobile IP has been to

Mobile IP

57

develop a solution that works in large-scale networks. Now that we have established a firm grasp on what is needed to support the roaming user, the way in which this fits into an overall networking picture, with its mix of static and mobile components, can be more clearly understood. From here on we look at the technical issues of addressing and routing that affect all packet networks—both mobile and static—in order to determine what options are available and what the issues are in each case.

Selected bibliography Myles, A., and D. Skellern, Comparing 4 IP Based Mobile Host Protocols, ftp.mpc.mq.edu.au/pub/elec/dist/mobile. Perkins, C., IP Encapsulation Within IP, RFC 2003, www.ietf.org, 1996. Perkins, C., IP Mobility Support, RFC 2002, www.ietf.org, 1996. Perkins, C., Minimal Encapsulation Within IP, RFC 2004, www.ietf.org, 1996. Solomon, J., Mobile-IP: The Internet Unplugged, Upper Saddle River, NJ: Prentice Hall, 1998. Zao, J., et al., “A Public-Key Based Secure Mobile-IP,” Proc. ACM Mobicom ’97, ACM/Baltzer, pp. 173–184.

CHAPTER

4 Contents

Addressing

4.1 IP addressing basics 4.2 Registered and unregistered addresses

4.5

Summary

I

nternet access has traditionally required the accessing device—generally a PC—to have an Internet address temporarily allocated to it for the duration of its connection, typically for a few hours. Once the user has disconnected, this IP address is released for reallocation to another user. The Internet service provider (ISP) industry has relied on the statistical behavior of this type of connection whereby only about 1 in 20 of its subscribers (or even fewer) will want to be on-line and connected at any given time. Therefore, even a large ISP with a million customers requires only a few thousand IP addresses. However, with the emerging mobile data services, such as GPRS, the connection pattern may well change dramatically. Once users have switched their phone on and are connected to the network, they are likely to

TE

4.4 Address management

AM FL Y

4.3 Static and dynamic addressing

Addresses are given to us to conceal our whereabouts. —Saki

59

60

Mobile IP Technology for M-Business

stay connected for much longer. Hence, any temporarily allocated IP address will be required to stay allocated to an individual user for a much longer period. Historical behavior in the established mobile networks shows that more than half of all subscriber cellular phones are switched on during the busiest period—an indicator of the challenge to future operators. This chapter explains the various options in IP addressing (such as static or dynamic, registered or unregistered) and the criteria and consequences of selecting an appropriate scheme. A more general review of IP and its associated protocols is given in Appendix A.

4.1

IP addressing basics

The job of the Internet Protocol is to provide a packet delivery service. IP takes no responsibility for the end-to-end connection and, as such, it is an unreliable service. The task of ensuring the connection is the job of transport layer protocols such as TCP, which is frequently used in conjunction with IP. Furthermore, IP is known as a connectionless protocol because packets are sent independently of each other and may traverse different paths to the destination. This contrasts with a connection-oriented service in which a logical circuit is set up for packet transfer and all packets will traverse this same path to the destination. Due to the connectionless nature of IP and the ability for individual packets to be routed or forwarded independently, each packet must contain, among other things, a source and destination IP address. In version 4 of the Internet Protocol, addresses are coded as a 32-bit integer field and for ease are normally specified in a dotted decimal notation (Figure 4.1). At its inception, the allocation of 32 bits for addressing was deemed adequate. As the use of the Internet has expanded, concerns have grown over the suitability of 32 bits to cope with the demand for Internet connectivity. These concerns have led to the development of a new version of the protocol, IP version 6, which has, among other things, extended addressing capabilities. Given that the uptake of this new version has been slow and that conservation of address space has eased IP version 4 concerns, we focus on the established version, IP version 4, in this text. Each IP address attached to the Internet or indeed an intranet must be unique. To help cope with diversity of applications, IP addresses are

Addressing

61 32-bit address 10000100 10010010 11010111 00001000

Dotted decimal notation 132.146.213.8 Figure 4.1

IP address: dotted decimal notation.

split conceptually into two parts: the network part and the host part. So, despite every IP packet having a 32-bit address field the number of bits apportioned to each part is dependent on the class of IP address (see Appendix A for a full explanation of this). The five classes of IP addresses are depicted in Figure 4.2. Two of the five classes are not for general use—Class D addresses are used for IP multicast networks and Class E addresses are reserved for future use. The remaining three form the basis for the addressing structure of the Internet. 4.1.1

Class A addresses

As depicted in Figure 4.2, a Class A address has a 0 as the first bit. Thus by definition (and in dotted decimal format) the range of Class A addresses goes from 0.1.0.0 to 126.255.255.254. (Addresses starting with 0 and 127 are reserved.)

bits Class A Class B Class C Class D Class E

0 0 1 1 1 1

1 2 3 4 8 16 Network Id. Host Id. 0 Network Id. 1 0 Network Id. 1 1 0 Multicast address 1 1 1 0 Reserved for future use

Figure 4.2

IP address classes.

24

31

Host Id. Host Id.

62

Mobile IP Technology for M-Business

With a Class A address, the first 8 bits (0 to 7) represent the network identity and the following 24 bits represent the host portion. Hence, a Class A address will support approximately 126 network addresses (i.e., 27) with each of these networks supporting approximately 16,777,216 host addresses (i.e., 224). What this really represents is that a Class A address can be used to support a very large network with more than 16 million end user devices or connections per each one of the 126 networks (where each connection or interface has its own IP address). Here are some examples of Class A addresses: 10.1.1.1 32.32.32.1

10 forms the network part 1.1.1 forms the host part 32 forms the network part 32.32.1 forms the host part

Given the number of host addresses that a Class A range can support, they are usually to be found in large organizations, such as an ISP like AOL, a telco like BT that provides data networks, and a bank that offers many on-line services. In each of these instances, the address range would be a registered one (similar to the second of the two examples given above). A large private network or intranet that does not offer extensive public access might use an unregistered Class A address range (like the first of the examples given above). A more detailed explanation of the registered and unregistered address options is given later in this chapter. Whichever option is chosen, the management of the address space is the responsibility of the organization that owns it; they own the address block for the long term and must take care to use it to best advantage. 4.1.2

Class B addresses

The presence of 1 and 0 in the first 2 bits represents a Class B address. In this instance, the first 16 bits represent the network portion (although as indicated the first 2 bits are used to specify the class) and the remaining 16 bits represent the host portion. Class B addresses range from 128.0.0.0 up to 191.255.255.254. More specifically the Class B range will support up to 214 network addresses (i.e., 16,384) and approximately 216 host addresses per network (i.e., 655,366). An example of a Class B address follows: 132.146.213.1

132.146 represents the network part 213.1 represents the host portion

Addressing

63

Although not on the same scale as a Class A address, this class can support large networks and is often used by ISPs. 4.1.3

Class C addresses

Class C addresses are represented by a 1,1,0 in the first 3 bits. Bits 0 to 23 represent the network identity and bits 24 to 31 represent the host portion. Class C networks range from 192.0.0.0 to 255.255.255.254. Approximately 224 networks (more than 2 million) can be supported by the Class C addressing format, each supporting approximately 28 (254) end hosts. Here is an example of a Class C address: 194.10.10.1

194.10.10 represents the network part 1 represents the host part

Because there are many of them, Class C addresses are what a small or medium enterprise would probably use. Whatever the format of the address space, all devices within a network must contain a unique IP address. This is essential to all IP packets between devices being forwarded or routed to the appropriate device (or more precisely to the appropriate interface because an address can be swapped over at an interface, by means of network address translation; more on this later). Additionally all devices connecting to the same physical network and which are deemed (logically) to be part of the same IP network must use the same network portion, with each device (or interface) having a unique host part. This concept is depicted in Figure 4.3, which shows a physical 10-Mbps Ethernet segment that has a number of IP devices attached to it. As can be seen, a Class B IP address is being used and hence the network portion is 132.146 or as normally represented 132.146.10.0. The second half of the dot address (the 10.X portion) represents the host part. This concept of all devices attached to the same physical network [either a local-area (LAN) or wide-area network (WAN)] is extended a little further in Figure 4.4. In Figure 4.4, regardless of whether a LAN or WAN is used, devices that wish to communicate across the same physical media must use the same network address (e.g., 132.146.10.0) and within the host portion each connected device must have a unique host address (e.g., 10.104). The organization and allocation of addresses are important parts of logical

64

Mobile IP Technology for M-Business

Ethernet IP address 132.146.10.100

IP address 132.146.10.101

IP address 132.146.10.1

IP address 132.146.10.102 IP router

IP address 132.146.10.103

IP address 132.146.10.104

End host Figure 4.3

Physical network IP addressing.

network design. A good addressing scheme can ease many potential network administration problems (notably the inevitable reallocation of addresses when things change). This concept of IP addressing is very straightforward. But a practical problem occurs—because the Internet has become more and more popular, the address space (i.e., the 32 bits used for the Class A, B, and C addresses) has become depleted. A Class A network is overkill for a network with only a few end hosts (e.g., a Class A network can support approximately 16 million hosts) and in some scenarios a Class C network supports too few hosts per network. A number of measures have been proposed to combat the impact on the depletion of the IP version 4 address space. One of the most effective

Addressing

Ethernet

Ethernet

IP address 200.10.10.100

IP address 132.146.10.100

IP address 200.10.10.101

IP address 132.146.10.1

IP address 132.146.10.101

Wide area network

IP address 200.10.10.102

IP router IP address 200.10.10.1

IP address 200.10.10.103

IP address 10.1.1.1

IP address 132.146.10.102

IP router IP address 10.1.1.12

IP address 132.146.10.103

IP address 200.10.10.104

IP address 132.146.10.104 End host End host

IP addressing across a WAN.

65

Figure 4.4

66

Mobile IP Technology for M-Business

has been to ensure that address space is efficiently used. A prime criterion for the IP registration bodies in their allocation of address ranges is efficiency of use. A network can be configured in many different ways to allow for conservation of IP addresses. Perhaps the most extreme is to use unregistered IP addresses. This entails the adoption of a private addressing scheme (which still follows the IP format) and deployment of conversion facilities (known as network address translation) at the edge of the network. A second conservation strategy would be to “loan” an IP to a device for the duration of a session, rather than give it a permanent address. The established Dynamic Host Control Protocol (DHCP) has been developed to allow IP addresses to be pooled and allocated when needed. Both of the unregistered address and dynamic allocation conservation strategies are widely used. Each has its consequences and neither suits in all circumstances—their impact and application is considered in greater detail in later sections. In addition to these overall strategies, one established design approach, known as subnetting, allows IP addresses to be used efficiently. Subnetting or subnet addressing allows a Class A, B, or C network to be partitioned depending on local, physical requirements. In the traditional addressing scheme described previously, each physical network is assigned a unique network address; each host on a network has the network address as a prefix of the host’s individual address. This is incredibly wasteful if, for example, a Class A address is allocated to a single Ethernet LAN segment (e.g., a Class A address can support approximately 16 million hosts). Subnetting allows the network administrator to partition this address space to cater to multiple physical networks. This is depicted in Figure 4.5. In normal IP addresses a mask is usually used to differentiate between the network and host portions (Table 4.1), and typically these masks follow the network portion of the different address classes. Table 4.1 Natural Masks Address Class

Mask

A

255.0.0.0

B

255.255.0.0

C

255.255.255.0

Addressing

67

Ethernet

IP address 132.146.10.100

All traffic to 132.146.0.0

IP address 132.146.10.101

Network 132.146.10.0

Router To rest of network Network 132.146.11.0 IP address 132.146.11.100

IP address 132.146.11.101 End host Figure 4.5

Subnetting.

When subnetting is used, masks allow the network portion of the address to be extended and the host portion reduced. Hence, the number of networks increases and the number of hosts per network decreases. This concept is depicted in Figure 4.6. In this figure, it is clear that the Class B address of 132.146.10.0 has been subnetted using a mask of 255.255.255.0. (Note that the natural mask for a Class B address is 255.255.0.0. Therefore, 8 bits have been specified for the subnet.) Bits within the mask are set to 1 to indicate that the corresponding bits within the IP address are part of the network and subnetwork component. Bits within the mask set to 0 specify that this part of the address represents the host portion. Nothing in the standard specifies that bits in the subnet mask be contiguous; however, it is recommended that these bits be contiguous because, in practice, this enables easier configuration, maintenance, and

68

Mobile IP Technology for M-Business

No subnetting

Dotted decimal

Binary format

IP Address

132. 146. 10. 100

10000100. 10010100. 00001010. 01100100

Mask

255. 255. 0. 0

11111111. 11111111. 00000000. 00000000

Network portion

Host portion

Dotted decimal

Subnetting IP address

132. 146. 10.

Mask

255. 255. 255. Network

Network portion

Host portion

Binary format

100

10000100. 10010100. 00001010. 01100100

0

11111111. 11111111. 11111111. 00000000

Host

Network

Subnet

Host

Subnet

Figure 4.6

A subnetting example.

management of end hosts and routers. Using the subnetwork mask depicted in Figure 4.6, networks 132.146.1.0 to 132.146.254.0 are each supported with 254 hosts. Subnetting allows a network administrator to optimize the use of the available address space whether this is a Class A, B, or C address and, hence, allows a hierarchy of addressing to be provided. Just as with the main address classes, it is suggested that the all 1’s addresses (i.e., 255) and the all 0’s addresses (i.e., 0) for subnetwork designation should not be used. One caveat should be mentioned about subnets: If you implement multiple subnets, they should be adjacent. That is, you should avoid having a configuration where you get from subnet 132.146.10 to subnet 132.146.11 by going through some other network entirely, for example, 128.121. For an organization with sites in London and Paris, it is perfectly OK for the networks in both cities to be subnets of 132.146. In this case, the network between the two must also be part of 132.146. If another network is used to link the two, some routers will not work as they should and routing problems are possible. One final issue on basic IP addressing to mention is that the Class A, B, and C addresses described above are not as rigid as they once were. A process known as supernetting allows blocks of address space to be added to form a “classless” group. For instance, if an ISP needed a thousand IP addresses, this would require more than a Class C (254 hosts) but

Addressing

69

4.2

AM FL Y

nowhere near a Class B (65,534 hosts) address. To get around this problem and allow more efficient use, classless interdomain routing (CIDR) has been introduced to allow concatenation of address blocks. So, for instance, our ISP could choose to use four Class C address blocks to get the required 1,000 addresses by taking them (199.106.104.0 to 199.106.107.0) and partitioning the third octet of the address into 5 bits for network addresses and the other 3 for hosts, as shown in Table 4.2. The first 5 bits of the octet shown in Table 4.2 do not change and so effectively form part of the network address. However, the other 3 are effectively added to the host address section. Because we now have only 21 bits for the network address, this arrangement would be referred to as 199.106.104.0/21. In much the same way, the Class A, B, and C addresses explained earlier are sometimes referred to as /8, /16, and /24, respectively.

Registered and unregistered addresses

TE

The architects of the Internet in the 1970s did not envisage the extent to which it would grow in the 1990s and beyond. Their expectation was that all devices connecting to the Internet and accessing available services would require an IP address. These addresses were acquired free of charge by organizations by applying to the relevant Internet registry and were known as registered addresses. The criteria for acquiring them were, in retrospect, fairly loose. By the mid-1990s it was clear that this model was no longer valid because the supply of available IP addresses was being rapidly exhausted. A new addressing model was created consisting of several components. First, the concept of “unregistered” or “private” IP address ranges was introduced. Certain ranges were set aside for anyone to use in whatever way they wished, with the only criterion being that these ranges would Table 4.2 Supernetting with CIDR 3rd Octet

Binary

104

01101 000

105

01101 001

106

01101 010

107

01101 011

70

Mobile IP Technology for M-Business

not be routed on the Internet. Secondly the technique of network address translation (NAT) was introduced where a NAT device would sit between a private network and the Internet. In addition, companies began to use sophisticated security devices known as firewalls that sit between the private network and the Internet. These would allow authorized traffic to pass through, yet prevent unauthorized users from probing or attacking the private network. Firewalls and NAT provide distinct functions, but are frequently combined in a single device. In operation, the NAT is quite simple. Any device on a private network wishing to send traffic to the public Internet can do so, but, as the individual packets pass through the NAT, the source address of the device is replaced with a registered Internet address—usually that of the NAT itself. When the Internet device responds, the NAT receives the packet and then works out from the port numbers (which identify the application) and sequence numbers on the packets which device inside the private network had sent the packet. The packet then has the correct destination address replaced and is forwarded to its destination. In Figure 4.7, we give an example of a user PC in a corporate network with private IP addressing requesting information from an Internet Web server. In this instance, NAT is being performed at the corporate firewall. In this example the setup always works when the user PC that sits inside the private network initiates requests. If, hypothetically, communication was initiated from the Web server how would it continue to work? The simple answer is that it cannot because there is no established

request

request

From 10.4.202.136 to 193.34.122.58

From 158.230.100.101 to 193.34.122.58

response

User PC 10.4.202.136 (private)

From 193.34.122.58 to 10.4.202.136

response

NAT firewall

10.122.23.45 (private)

Private IP addressing

Figure 4.7

Network address translation.

From 193.34.122.58 to 158.230.100.101 158.230.100.101 (registered)

Public IP addressing

Server 193.34.122.58 (registered)

Addressing

71

way of routing data to a “private” address. In addition, the Web server cannot know or find the identity of the User PC with which it might wish to communicate. With existing Web access no problem occurs because communication is always initiated from the user. However, particularly in the mobile world, there is a potential demand for “push” technology where remote servers may send unsolicited messages to a user; for example, travel or weather updates when a user moves, an alert when new mail arrives at a user’s central mail store, or notification when a share price reaches a particular level. To solve the problem when providing a mobile service such as GPRS (or rather, make appropriate choices), we have to look beyond the immediate situation and examine the services that will be offered to users. This involves identifying the user groups and forecasting those services that will be in most demand. The GPRS user groups can be divided simply into the following groups: 1. Business users accessing their company network via a direct link; and 2. Those accessing the Internet. This group needs to be further divided into (a) those using WAP only (with the recent release of cheap, WAP-enabled mobiles, it is expected that early demand will be for users in this group); (b) those using WAP along with an established service such as Web or POP3 e-mail; and (c) those with nonstandard needs that probably involve using a PC-type device. One example would be someone who needs to view a spreadsheet held on the corporate LAN. The IP addressing of the business users accessing their company network is simple with addresses allocated from the company network. GPRS is designed to allow this; effectively, the user device is on an extension to the company network. Many companies will use a private IP addressing scheme on their internal network. GPRS does not care what scheme is used. Even though hundreds of companies may all be using the same private 10.x.x.x address space, GPRS’s IP tunneling keeps them separate because it does not care about the IP address of the mobile device or of the correspondent host in order to route traffic between the two.

72

Mobile IP Technology for M-Business

Internet WAP users will work quite happily with private addressing, as will those who additionally require established services such as Web or POP3 e-mail. This concept is explained more fully in subsequent sections. Some other needs may not, however, be compatible with private addressing. For example, a corporate network that uses the emerging IP security techniques, defined in the IPsec documents, to protect itself will not work properly with NAT because the IPsec authentication header uses IP packets to produce a security digest. NAT, by definition, modifies IP packets and is therefore incompatible with IPsec. In addition to this, a number of protocols carry IP addresses in their payload. For instance, Simple Network Management Protocol (SNMP) packets carry information about the status of a device. This includes its IP address, which, if changed by NAT, is not much use. Finally, some applications, such as NetMeeting, are known to be problematic when used with NAT. The problems are not insurmountable, but may be enough to influence the addressing strategy. Consequently, there are some groups of users who cannot or should not use NAT, so they will need to instead use public registered addresses. The number of users in this category is likely to be relatively small (remote users of a corporate network, for instance) but may significantly impact the chosen addressing scheme—the needs of the few may affect the overall strategy. There is no straightforward formula for deciding whether to go for a registered or unregistered addressing scheme. Each option has its pros and cons and the weight attached to them depends on the services being offered. In some instances, an overriding factor may mean that only one option is viable. In most cases, though, a measure of judgment is called for. To close this section, we summarize some of the key factors that should be considered. 4.2.1

Benefits of private addressing

Perhaps the main benefit of private addressing is conservation. By not utilizing the valuable resource of registered IP addresses where they are not needed, more addresses can be made available to those activities that do require them. However, there are other more tangible benefits: 1. Rapid deployment. Because registered addresses are not required, it is no longer necessary to go through a request process that might create unforeseen delays. If there is a sudden and unexpected uptake in demand for a particular service, it can be provisioned

Addressing

73

without depending on the granting of new IP address ranges by an external registry. 2. Better security. Private addresses are not directly accessible from the Internet and by using a NAT device (which includes basic firewalling functionality) the users are not vulnerable to direct attacks from the Internet. However, this is not always an option, as described above. 4.2.2

Disadvantages of private addressing

Naturally, private addressing does have a few disadvantages: 1. NAT devices must be utilized. These cost money, can have a performance impact, and must be maintained. However, either Internet security devices such as firewalls or WAP gateways have to be employed anyway, therefore, the addition of NAT functionality to them represents only a small increment. 2. For a very large network operator, where more than 16 million customers might be on-line at any one time, insufficient private addresses are available for providing each customer with a unique address. This is not a likely scenario, though, and there is always the option of using a second Class A address range. In the context of mobile services, the choice of registered or unregistered addressing is heavily influenced by the overall networking strategy: The inclusion of a mobile element often does not have that great an impact. Nonetheless, the pros and cons listed above should be applied evenly before a choice is made.

4.3

Static and dynamic addressing

One of the Internet innovations that has spread rapidly during the last few years is the use of dynamic addressing. The development of the Dynamic Host Control Protocol (DHCP) allows operators to allocate an IP address to a device for the duration of a session and then reallocate the same address to another user when it becomes free. This means that a network can be effective with only a fraction of the IP addresses it would otherwise need. A thousand users on a corporate network can be adequately supported with a couple of hundred IP addresses.

74

Mobile IP Technology for M-Business

As part of network design, we have the choice of specifying either fixed IP addressing for mobiles (usually stored with the user’s subscription record in the home location register [HLR]) or dynamic addressing. In the latter case, the address is allocated to a mobile only when it successfully connects, and it is released for reallocation once the mobile disconnects. According to the ETSI GPRS specification (EN310 344), the choice of specifying whether the IP address of mobile devices is fixed or dynamic lies with the mobile (i.e., GPRS) network operator. If dynamic addresses are used, these are allocated by the GGSN when a mobile device attaches to the network with a blank address field. Hence, services provided by anyone other than the mobile operator need to be designed in collaboration with that operator to ensure end-to-end integrity. This could be a very important issue, since third parties outside the network hold one of the keys to success. The static addressing option requires little explanation here because it entails no more than a straightforward allocation process. This might be to ship each mobile device with a hard-wired IP address (for instance, already programmed into the subscriber identification module or SIM card in a mobile phone). Alternatively, it might be accomplished by allocating an IP address to each user when they register with their service provider and storing this as part of their details in the HLR. Dynamic addressing is a little more complex. In this instance, a client has to broadcast a DHCP “discover” packet. This identifies the client as requesting an IP address. A designated server responds with a DHCP “offer” packet, which is relayed to the client with an available address. If no offer is received within a specified amount of time, the client resends its discover packet. If several offers are received, the client can compare configuration parameters (which identify preferred settings) and decide which server to target. When it has made its choice, the client broadcasts a DHCP “request” packet, which contains the address of the target server in the server IP address field of the packet. This tells servers not selected that their offer is still available and the selected server that their offer should now be completed. With dynamic addressing, the IP address of remote devices is not necessarily a part of the mobile operator’s system—it is held on the DHCP server rather than in the HLR or SIM card on the mobile device. This means that the overall system and service design needs to ensure that there is adequate linkage between the various components that support the mobile device (notably the HLR, GGSN, and DHCP server).

Addressing

75

One of the capabilities of DHCP is that it allows the same IP address to be requested by a specific user. In this instance, some of the negotiation steps outlined above are omitted because the client is only looking for a specific offer. There is no guarantee that the requested address will be available, but there is at least some scope for addressing a specific device, even when IP addresses are dynamically allocated. As with registered and unregistered addresses, there are pros and cons to the choice of fixed or dynamic addressing. 4.3.1

Benefits of dynamic addressing

The key driver for dynamic addressing is conservation of addresses. The consequent benefits are as follows: 1. Faster deployment. Because fewer addresses are required, it is much easier to get registered addresses. The registration procedures from the IP address bodies such as Reseaux IP European Network Control Centre (RIPE NCC) focus on efficiency of use and so require you to justify the class/number of addresses requested in some detail. 2. Flexibility. There are no real break points at which more addresses have to be acquired. With fixed addressing, you have to know in advance how many are needed (and be able to justify that need to the registration bodies). With DHCP the probability of getting an IP address from the DHCP server may decline as the number of users grows, but there will always be some chance. 4.3.2

Disadvantages of dynamic addressing

Naturally, a few disadvantages are associated with using private addressing: 1. Complexity. When the IP address moves from being a straightforward attribute of the mobile device to being a temporary one, extra complexity occurs. In particular, the designer must ensure that the overall network design is sound (and that the IP address is available to all of the system components that need to use it). 2. Contention. The introduction of contention for addresses means that some element of blocking is inevitable. Just as network design is key, so is dimensioning—the pool of dynamic addresses needs to be matched to the number of users and their connection requirements.

76

Mobile IP Technology for M-Business

As in the previous section, there are no “right” or “wrong” answers. However, the use of dynamic IP addressing is usually recommended for a number of reasons. First, and most obviously, it reduces the size of the IP address pool required. Second, it ensures the IP routing is workable in more complex setups where several operators (each with their own GPRS serving node, GGSN) wish to connect to a specific service.

4.4

Address management

Whatever addressing option is selected, the designer must ensure that the address space used to identify mobile devices is properly managed. For all but the smallest of operations, this means using some sort of tool to automate the process. Table 4.3 describes a few of the many available tools that help to administer and operate an IP network. Many of them deal with issues raised in the sections on addressing options. For instance, several tools are available that allow a mobile device to have a permanent name (stored in a DNS server) despite having a dynamic addressing network (by keeping records that associate a name with its current IP address). Table 4.3 Selected Candidate IP Address Management Tools Name

Supplier

Function

Comments

IP Address Works

Process software

Central DNS/DHCP management—allows dynamic IP address allocation with automatic name server updates.

Network information is stored in a lightweight directory application protocol (LDAP) database, which is standard, so it is readily exportable.

QIP

Lucent

As above.

More powerful (and expensive) than above.

IOS Easy IP

Cisco

As above, plus NAT; rich set of routing and address management features (e.g., allows central VPN setup).

A more complete IP network management toolkit.

Afaria

Xcellenet

Applications management —keeps track of the configuration and status of remote devices (including software updates, inventory management, session management).

Part of the session management function is allocation of IP addresses (so it can be used with one of the above).

Addressing

77

The level of sophistication of tool support will vary according to the size of network being managed and the type of automation demanded by the design options that have been chosen.

4.5

Summary

This chapter examines the main issues in choosing an appropriate addressing scheme for a mobile IP service. In addition to explaining the basics of IP addressing, we look in some detail at the impact that certain design choices have on the implementation and operation of a mobile IP network. In particular, the choice between registered and unregistered, fixed and dynamic IP addresses is considered and the consequences of each explained. A short summary would be to say that unregistered and fixed addressing are the easier (but not necessarily optimum) options. In contrast, registered and dynamic addressing require a little more thought and effort but may be preferable in the long run. The treatment of IP addressing, per se, is quite brief in this chapter. Several of the references go in to a lot more detail, and more general information is given in Appendix A. The aim here has been to highlight those aspects of IP addressing that affect and, therefore, should concern the designer, operator, or providers of mobile IP services. Given that different solutions apply to different deployment options, no universal answer is given; instead, a set of criteria and considerations is given that leads to the right solutions for a specific instance.

Selected bibliography Comer, D., Internetworking with TCP/IP, Volume 1: Principles, Protocols and Architecture, 3rd ed., Upper Saddle River, NJ: Prentice Hall, 1995. Norris, M., Understanding Network Technology, 2nd ed., Norwood, MA: Artech House, 1999. Norris, M., and S. Pretty, Designing the Total Area Network, New York: John Wiley & Sons, 1999. Stevens, W., TCP/IP Illustrated, Volume 1: The Protocols, Reading, MA: Addison Wesley, 1994.

CHAPTER

5 Contents

Routing

IP routing basics

5.2 Distance vector protocols in detail 5.3

Path vector

5.4

Link state protocols

5.6

Summary

T

he Internet and all of the services that are built around it need some reliable means of moving packets of information from one place to another. To meet this need, a number of routing protocols have been developed. Like the various overland postal services, these ensure that packages and packets are safely delivered to specific destinations. And different protocols have different characteristics, just as regular, registered, and courier deliveries have specified levels of service. The routing protocols used in IP networks are responsible for the exchange of forwarding information between routers and for helping each router build a routing table. This table shows, for each possible destination, which router the user’s packets must be sent to next in order to reach their nominated destination. In general, the routing protocols for IP-based networks can be categorized into

TE

5.5 Choosing the right protocol

By indirections, find directions out. —Shakespeare, Hamlet

AM FL Y

5.1

79

80

Mobile IP Technology for M-Business

either interior gateway protocols (IGPs) or exterior gateway protocols (EGPs). The former are typically used to route traffic within a network, whereas the latter usually route traffic among different networks or, more commonly, among different service providers. In keeping with the ideas of providing an integrated information network that supports roaming users, as developed in earlier chapters, our primary focus is on the IGP. Our routing protocols can be further split into three types: distance vector, link state, and path vector protocols. Each of these is described at length later in the chapter but the basic operation of each is as follows: ◗

Distance vector protocols are the simplest of the three and work by building up a table in each router that contains a measure of how far it is to its neighboring routers. The path that a packet takes is built up, hop by hop, with each router on the way forwarding the packet to its nearest neighbor.

◗

Link state protocol routers are similar, but the routers exchange link states instead of building routing tables. These link states take the form of advertisements that describe different aspects of the network. Each router within the network stores the link state advertisements from the other routers in the network and, once it has a complete set, it can carry out a shortest path calculation for all destinations in the network.

◗

Path vector protocols operate rather like the distance vector protocols but paths to a destination are exchanged among routers instead of distances to the next router. As each router receives the available paths from its neighbors, it calculates the paths it should use to reach a specific destination. This calculation is usually on the basis of lowest cost (i.e., fewest intermediary routers), but can also contain specific conditions (i.e., must not use a particular link).

Both the distance and path vector protocols operate by forwarding periodic updates of routing information, whereas the link state protocols forward updates only when there is a change in network topology. As you might expect given their different ways of working, each of these protocols has different attributes. They offer choice in terms of the time it takes to establish a full routing picture, the bandwidth needed to exchange information, and the demands made of a router’s processing

Routing

81

and memory. In addition, each protocol has its own scalability and stability characteristics. Thus, the network designer is faced with a range of candidate routing protocols, each with its strengths and weaknesses. Selecting the optimum routing protocol (or mix of protocols) for a specific network configuration is one of the key decisions of the logical network design process. This chapter explains, in general terms, how routing protocols work. It then goes on to show in some detail how the particular types operate. To conclude, an analysis is provided for choosing the right routing option for an effective network.

5.1

IP routing basics

As we have seen, there are three broad approaches to getting a packet across a network. From the packet’s point of view, the end-to-end journey involves stopping and, perhaps, making some sort of selection at each of the stops (i.e., routers) on the way. As with any journey, choices must be made in terms of departure times, road conditions, travel mode, ticket price, and number of intermediate stops. The way in which these choices are preempted can be used to characterize a routing protocol. Hence, we can establish a sound basis for evaluating different options and selecting the most appropriate candidate. The attributes discussed in the following subsections are used at the end of the chapter to compare the various routing protocols that are explained in the intervening pages. 5.1.1

Router attributes

Convergence

Convergence refers to the point in time at which an entire network becomes updated to the fact that a particular network has appeared or disappeared. When a network has not converged (i.e., is awaiting to be updated about the reachability or not of a particular route) then obviously end-to-end connection is not possible; we could argue, however, that the actual convergence time required may be dependent on end applications. For example, a fixed bandwidth service (e.g., an ATM permanent virtual circuit) might be used as a customer’s primary network and a circuit-switched network such as ISDN deployed as the backup network. On failure of the ATM link, the path across the ISDN network must be

82

Mobile IP Technology for M-Business

configured and routers across the network must be up to date with the relevant routing information before the end applications’ time out (i.e., drop the working session before the transfer from ATM to ISDN is completed). Thus, in certain scenarios the quickest convergence times may not be required, as long as the routing converges before problems become evident. Bandwidth efficiency

In the process of exchanging routing information or routing packets the available wide-area network (WAN) and local-area network (LAN) bandwidth should not be consumed fully by routing update information. Hence, a desirable attribute of any routing protocol is to efficiently utilize available bandwidth, particularly in the wide area where long-haul bandwidth can be very expensive. Hence, network administrators do not wish to overuse this bandwidth with administrative traffic such as routing update information. One of the rules of thumb for many network designers is that bandwidth is significantly more expensive (on an ongoing basis) than the one-off costs of router hardware and memory. Router CPU efficiency

When a router actually receives routing update information, that information must be processed and either the routing table updated or, assuming no changes are necessary, the information discarded. A router must be able to process the routing information relatively easily and without too much impact on the CPU, otherwise other important tasks such as the forwarding of packets may be impacted or the router may shut down due to the continuous processing of routing information required. Obviously as different processors become available and are used by the different router vendors, designers must be prepared to select a router that can do the necessary job. A small branch router will not be able to support and process the 50,000 routes supported by Internet backbone routers. Router memory overhead

As memory (and the cost of routers) becomes cheaper, the issue of overhead will become less important. However, where hundreds or even thousands of routers are used within corporate networks, then the choice of routing protocol (and the memory required) may affect the commercial proposition of the network design. As indicated previously, the ability

Routing

83

to support the Internet routing table will require a large amount of memory, whereas for small corporate networks routing tables will not be as large and, hence, the need for memory will not be as significant. Scalability

The routing protocol selected must scale to the size of the network for which it is intended and additionally must allow the network to be easily extended. A number of attributes increase scalability, as discussed next. Variable-length subnet mask support Variable-length subnet mask (VLSM) is an extension of subnetting (as introduced in the previous chapter). Rather than having a fixed subnet mask for the whole network, the mask can be of a variable length or size. This allows the network administrator to further optimize the use of address space and flexibly allocate addresses depending on requirements. For example, consider the situation in which a network administrator has been assigned a Class C address and needs to assign addresses to three LANS, one with up to 100 hosts and two with up to 60 hosts. If VLSM is used (Figure 5.1), this is a trivial problem, using a mask of 255.255.255.128 to cater to the LAN with up to 100 hosts and using a Network 200.10.10.0 Mask 255.255.255.128 Subnet: 0 Host Addresses : 1..126

IP address 200.10.10.1 Network 200.10.10.0 Mask 255.255.255.192 IP address 200.10.10.2

Subnet: 192 Host Addresses : 193..254 IP address 200.10.10.193

Router

IP address 200.10.10.194

Network 200.10.10.0 Mask 255.255.255.192 Subnet: 128 Host Addresses : 129..190 IP address 200.10.10.129

IP address 200.10.10.130

Figure 5.1

Example of a variable-length subnet mask.

84

Mobile IP Technology for M-Business

mask of 255.255.255.192 to cater to the two LANs with up to 60 hosts. The way in which the subnet mask allows some of the address range to be used to identify subnets was illustrated in Figure 4.6 in the preceding chapter. Without VLSM, it would be much more difficult to support this scenario with a single Class C address. Classless interdomain routing Classless interdomain routing (CIDR), introduced in the previous chapter, is specified in RFC 1519 and is one of a number of attempts to reduce the increasing size of the Internet’s routing tables. CIDR or supernetting allows a block of contiguous IP addresses to be represented by a single route. CIDR is referred to as classless because it does not hold to the classful boundaries of IP addresses and instead allows a contiguous block of addresses to be “summarized” by a single aggregate address. The use of CIDR has imposed a hierarchical structure on parts of the Internet (and has also required that address allocation be much more efficient and organized). This is depicted in Figure 5.2. When CIDR is used, the number of routes advertised by service providers A, B, and C are dramatically reduced (service provider C advertises 1 route as opposed to more than 500 separate routes). Where addressing is not hierarchical (i.e., where addresses have been previously allocated on an ad hoc basis and do not follow any topological hierarchy), then this will cause some problems with the use of supernet routes. To avoid this problem, RFC 1519 indicates that the network destinations contained within a router’s routing table should be represented by a network address and mask and that the “classful” nature of addresses must be ignored. Additionally where a customer’s network is multihomed (i.e., has a number of connections to different service providers), then RFC 1519 states that these destination networks must be explicitly advertised into each of the attached domains. In these instances, the routing policy of the higher layer domain determines if it needs to provide a summary of these routes. This concept is depicted in Figure 5.3 and indicates that router D has advertised all explicit routes within the network 200.10.0.0 range. Router B has also advertised each explicit route, however, router C has chosen to summarize the range of routes. RFC 1519 dictates that packets should be routed based on the longest match between the packet destination and entries within the routing table. In the preceding example where router A receives a packet destined for network 200.10.20.10 then the packet would be routed via router B. If router A did not have a more explicit route for network

Routing

Networks 200.10.1.0 … 200.10.255.0

Networks 200.0.0.0 Mask 255.0.0.0

200.11.1.0 … 200.11.255.0

Networks 200.10.1.0 … 200.10.255.0

Service provider C

Networks 200.11.1.0 … 200.11.255.0

Service provider B

Service provider A

200.11.1.0 ... 200.11.255.0

200.10.1.0 ... 200.10.255.0

Service provider C

Service provider A

Service provider B

200.10.1.0 ... 200.10.255.0

(a)

Classless interdomain routing: (a) without CIDR and (b) with CIDR.

200.11.1.0 ... 200.11.255.0

(b)

85

Figure 5.2

Networks 200.11.0.0 Mask 255.255.0.0

Networks 200.10.0.0 Mask 255.255.0.0

86

Mobile IP Technology for M-Business Network 200.10.1.0, 200.10.2.0…200.10.255.0

Network 200.10.1.0, 200.10.2.0…200.10.255.0

Router B

Router A

Address range 200.10.0.0 to 200.10.255.255

Network 200.10.1.0, 200.10.2.0…200.10.255.0

Network 200.10.0.0

Figure 5.3

Router D

Router C

Multihomed domain.

200.10.10.0, then the packet would be forwarded via route C which, in this instance, would still be the longest match route. Simplistically, a router that has to decide between different length prefixes of the same network will always follow those routes with the longer mask. As discussed above, router A always forwards packets to 200.10.20.10 based on the routing table entry of 200.10.20.0/24 rather than the routing table entry 200.10.0.0/1. (See Chapter 4 for details of the addressing terminology used here.) Conceptually, packets are routed based on a step-by-step search through the routing table for the longest match route. Given that a routing table may consist of thousands of routes, this type of sequential lookup is unrealistic, so specialized lookup algorithms have been developed. Logical domains When networks become very large, it is useful to be able to break down the network into logical domains. This in itself allows some hierarchy to be imposed on the network and also allows the network to be more easily managed (due to the smaller size of each routing domain) and for the techniques of VLSM and CIDR to be used. Stability

Although difficult to measure or quantify, good stability and robustness in a routing protocol are essential. In all scenarios where customer traffic is to be routed across either an intranet or Internet, it is important for traffic to be routed correctly and for the routing protocol to deal reliably with additions and modifications to the network. A misconfigured router can easily cause instability throughout the Internet.

Routing

87

Within each type of routing protocol there may also be some features that ensure the stability of either the routing protocol itself or the information provided by the routing protocol. Technology/service independence

The routing protocol must work in conjunction with the underlying technology used to carry it, particularly where that technology provides either fixed bandwidth or dial-up-on-demand bandwidth. The important consideration for these technologies with regard to the routing protocol operation is the impact of the partial meshing of connections and its effect on neighbor relationships (or peering), bandwidth utilization, and also protocol operation. We use the term partial meshing to refer to technologies that are connection oriented. In a full mesh there is a link from every point on the network to every other point. With a partial mesh, however, a connection that is set up and maintained between two end points may go via a transit site. This is depicted in Figure 5.4, where traffic between the two branch sites must be forwarded via the host site. By contrast, connectionless services (where there is no permanent virtual connection between sites) can be thought of as having the same properties of a LAN for broadcasts (i.e., every router attached to the network can, in the absence of a total failure, reach every other router).

Host site

Logical connection

Branch site Figure 5.4

Partial mesh network.

Branch site

88

Mobile IP Technology for M-Business

Interoperability/open standards support

The ability for different vendors’ routing protocol implementations to interoperate can be seen as very important; this attribute avoids proprietary support and vendor lock-in (thus allowing customers to use and migrate to different vendor equipment but still enabling existing equipment to be used). Protocols that are open also tend to be better documented and understood by the relevant technical communities. In certain instances, however, proprietary solutions may be the best option. This is particularly so when standards bodies delay the specification of a particular feature due to either political or bureaucratic reasons. This tends to produce “interpretations” of the standards that are specific to a given implementation. Security

Security in itself is a hot topic within the data networking community. This is represented by the growth in security products during the early 2000s. The real cost of a security breach is obviously dependent on the organization and the business of the organization. A number of financial organizations have indicated that the liability could be millions of dollars. Hence, some form of security and authentication must be in place, because it is important to ensure that traffic is routed to the correct destination. It is also needed to protect from faulty routers or nonmalicious users, which may transmit incorrect routing information. Not only is robustness of the routing protocol important, but the network should also be robust in the areas of firewall protection, self-stabilization, fault detection, and resilience to partial failure. These concerns will be revisited in Section 5.5 and again in the next chapter. 5.1.2

Exterior/interior gateway routing protocols

As the Internet was evolving, it became quite clear that groups of networks controlled by a single administrative entity would connect to the Internet core or backbone network. Hence, as more and more of these autonomous systems (ASs) evolved and the complexity of (or number of networks within) these autonomous systems increased, the need arose for two types of routing protocols. Exterior gateway protocols (EGPs) are usually considered to be a mechanism for ensuring that the network reachability information pertaining to a particular autonomous system is passed to other autonomous systems connected to the Internet. Interior gateway protocols (IGPs), on

Routing

89

the other hand, are the mechanism for advertising network reachability within an autonomous system. Figure 5.5 depicts simplistically the differences between an EGP and an IGP. Note, however, that there were a number of drivers for both types of protocol as the Internet evolved. These drivers included (and still include): Scalability. It soon became apparent that it was not possible for a single routing protocol to cope with the size and continuing growth of the Internet’s routing tables, hence the evolution of an EGP. Additionally, it is not practical for all of the routers in a very large IP network to provide all the other routers with routing updates; hence, the concept of core routers and autonomous systems to introduce levels of hierarchy (and thus easing scalability) was implemented.

◗

Autonomous system independence. As the Internet evolved it became clear that there were a large number of well-established autonomous systems operating different IGPs. And so, although it was necessary to advertise reachability of the networks within these autonomous systems, it was also important to ensure that these domains remained independent.

◗

Functionality. The requirements of an EGP and an IGP are different; in certain instances an IGP must support a very low number of networks, whereas an EGP must carry vast amounts of routing

TE

AM FL Y

◗

Internet EGP

IGP

IGP

Autonomous system 1 Figure 5.5

Autonomous system 2

Exterior/interior gateway routing protocols.

90

Mobile IP Technology for M-Business

information allowing a large degree of control by either the service provider or network administrator. Separating this functionality eases scalability, manageability, and independence from the other protocol. Hence, EGPs evolved to allow the scaling of the Internet by isolating different parts and requiring only highly summarized route information to be passed between those parts. The drivers behind both EGPs and IGPs are thus very different. In both cases, though, the actual mechanisms for exchanging interior and exterior routing information can be categorized as either distance vector or link state. 5.1.3

Distance vector protocols

Distance vector protocols are relatively simple in their operation, especially when compared to link state protocols. The term distance vector relates to the fact that a vector or table of distances to specific destinations is sent in routing updates between routers. These distances could be measured in number of hops, available bandwidth, or any other measure that reflects the best way of getting a packet from one point to another. When an IP router is switched on, it initializes its IP routing table with a list of directly connected networks. Associated with each of these directly connected networks will be a metric of 0, which designates an immediate neighbor. Periodically, the router will send a copy of its routing table to neighboring routers and in this way each router within the network will build up a full routing table, allowing packets to be forwarded or routed to the whole of the network. This is shown in Figure 5.6. Figure 5.6(a) depicts the initial instance of a distance vector routing table. Figure 5.6(b) depicts the IP routing table after the initial interval. In the example above costs/distances have not been associated with the routes to specific networks; however, usually either a hop-count or a metric (associated with bandwidth, delay, or load) is used to denote a cost to a particular network. The distance relates to the cost or distance to a particular destination. Distance vector protocols only exchange routing information between routers that are adjacent (or are neighbors). Hence, where the total distance between two routers i and j is D(i,j) then the total distance between a number of routers i to m is D(i,m) = minimum [d(i,j) + d(j,k) + d(k,l) + d(l,m)]

Routing

91 Routing Table

Routing Table

Network 1 directly connected Network 2 directly connected

Network 3 directly connected Network 4 directly connected

Network 1 Router A

Router B Network 4

Network 2

Network 3 (a)

Routing Table Network 1 directly connected Network 2 directly connected

Routing Table Network 3 directly connected Network 4 directly connected

Network 3 via Router B Network 4 via Router B

Network 1 via Router A Network 2 via Router A

Network 1 Router A

Router B Network 4

Network 2

Network 3 (b)

Figure 5.6 Concept of distance vector routing protocols. Status of routing tables at (a) time t = 0 and (b) time t = interval.

The properties of distance vector protocols can be summarized as follows: ◗

Each router maintains an entry in a table for every destination within the autonomous system or indeed the whole system. This entry consists of the network and also a cost to reach that particular network. The lower the designated cost, the better the route.

◗

The router periodically sends a copy of its whole routing table to each neighbor.

◗

When a routing update arrives from a neighbor over network N, the total cost to reach the destination network is the cost of traversing network N added to the cost specified in the routing update.

Distance vector protocols have been around for a number of years (the first standard of this type, the Routing Information Protocol, RIP, was ratified by the IETF in 1988). RIP and its descendants have a number

92

Mobile IP Technology for M-Business

of technical limitations, the main one being the well-known counting to infinity problem. Counting to infinity problem

As indicated previously, distance vector protocols exchange their whole routing tables periodically; in certain scenarios however this can result in slow convergence. Figure 5.7(a) depicts a snapshot of the routing tables of each of the routers, specifically the routes to and associated costs for network 1. Figure 5.7b shows the status of each of the routing tables following the failure of network 1 at each update interval. Figure 5.7 is a simplified example and assumes that routing updates are transmitted and processed at each of the routers simultaneously. When network 1 fails, router A knows it is unreachable; however, the other router (B) still believes network 1 is reachable via router A and advertises this route at a cost of 1. Router A adds its cost to reach router B

Network 1

Router A Routing table

Router B Routing table

Network 1 directly connected

Network 1 via A 1 hop

(a) Network 1

Router A Routing table

Router B Routing table

1

Network 1 unreachable

Network 1 via A 1 hop

2

Network 1 via B 2 hops

Network 1 via A 3 hops

3

Network 1 via B 3 hops

Network 1 via A 4 hops

4

Network 1 via B 4 hops

Network 1 via A 5 hops

5

Network 1 via B 5 hops

Network 1 via A 6 hops

6

...

Update intervals

(b)

Figure 5.7 Distance vector protocols: (a) snapshot of routing tables (all routing tables are up to date) and (b) counting to infinity.

Routing

93

(i.e., a cost of 1) and hence router A updates its routing table to indicate that network 1 is reachable via router B at a cost of 2. Router A advertises its cost to reach network 1 via router B at a cost of 2 and hence router B updates its routing table accordingly and the process continues. This exchange is known as the counting to infinity or the slow convergence problem; a number of solutions, discussed in the following subsections, have been designed to reduce the impact of this problem. Limit the hop count Routes that reach a cost of infinity are obviously not feasible and should be deleted from the routing table. Thus, by artificially placing infinite cost on a route or limiting the hop count that a route can reach, we can ensure that a route is discarded from the routing table. RFC 1058 defines infinity to be 16; thus using RIP the maximum possible network size is 15 hops. This limit was defined as a trade-off between network size and convergence speed. Split horizon Many of the problems caused by counting to infinity lie in the fact that routers advertise routing information back in the direction from which it originated. Clearly this is inefficient and the simple splithorizon scheme specifies that routes learned from a particular neighbor be omitted in subsequent updates back to that neighbor (as shown in Figure 5.8). The split-horizon scheme with the poison reverse feature is more elegant than just split horizon. The split-horizon scheme with poison reverse does advertise routes learned from a neighbor back to that neighbor, but specifies that the cost be set to infinity or 16 in RIP-based networks. Loops are immediately broken because routes with a cost of infinity are immediately purged from the routing table; with the pure split-horizon scheme, invalid routes are purged using various timers and these are implementation dependent. The split-horizon scheme with poison reverse does, however, use more bandwidth than a simple split-horizon scheme because all routes are included in an update regardless of whether or not they are accessible. Timers Certain vendors have implemented various timers to ensure that invalid routing information is not incorrectly reinstated. These holddown timers are used to ensure that when a route to a destination network becomes invalid, a new route for that particular destination will not be entered into the routing table until the hold-down period has expired.

94

Mobile IP Technology for M-Business Network 1

Routing update

Network 2

Network 2 directly connected Network 1 cost : 1 hop

Router A

Router B

Routing update Network 1 directly connected Network 2 cost: 1 hop (a) Network 1

Routing update

Network 2

Network 2 directly connected

Router A

Router B

Routing update Network 1 directly connected (b) Network 1

Routing update

Network 2

Network 2 directly connected Network 1 cost: 16 hops

Router A

Router B

Routing update Network 1 directly connected Network 2 cost: 16 hops (c) Figure 5.8 Split horizon in distance vector routing protocols: (a) no split horizon, (b) simple split horizon, and (c) split horizon with poison reverse.

The hold-down period is designed to avoid the scenario depicted in Figure 5.9 where routes that are no longer valid are reinstated by neighboring routers. A triggered update is forwarded when a route changes state (or possibly its metric) and may be either a full update of the routing

Routing Network 1

95 Network 1 unreachable

Router A

Router B

Router C

(a) Network 1 reachable

Network 1

Router A

Router B

Router C

(b) Figure 5.9 The use of a hold-down interval to increase routing stability: (a) Router A sends triggered update indicating that network 1 is unreachable; (b) router C sends scheduled update indicating that network 1 is reachable.

table or, preferably, an update of only the routes that have changed. The hold-down period is normally set to be the time that it would take a routing update to traverse the whole network. Despite the counting to infinity problem, distance vector protocols have been and continue to be popular within the networking community and additionally have been used as the basis for other protocols such as AppleTalk’s Routing Table Maintenance Protocol (RTMP) and Novell’s RIP-like implementation. 5.1.4

Path vector protocols

Path vector protocols operate in a similar manner to distance vector protocols but instead of a vector of distances to each destination being exchanged between routers, a vector of paths to a destination is exchanged. Looking at Figure 5.10, router A would advertise to neighboring routers that to reach G its path vector is A, D, F, G. This indicates that router A would send traffic destined to G via nodes D and F. This vector of paths can be viewed as a source-route path (i.e., each node indicates the exact path which must be traversed to reach a specific destination). As each router receives the path vector or routing update from its neighbors, it calculates the optimum path to reach a specific destination

96

Mobile IP Technology for M-Business

B C

A

E

D G F

Figure 5.10

Path vector protocol.

by using some preconfigured policy. This may state that routes must always be the lowest cost (in terms of metric) or must not traverse a particular node. Path vector protocols avoid the counting to infinity problem inherent in distance vector protocols. The routing update will include the path to be taken to a specific destination so that if a node or router detects its own identity within the path advertised by a neighbor, then the receiving router must not use this path as a loop may have formed. Path vector protocols are used mainly as EGPs of which the Border Gateway Protocol (BGP) is the most obvious example used within the Internet today. 5.1.5

Link state protocols

Link state protocols such as Open Shortest Path First and Integrated Intermediate System to Intermediate System work on the basis that routers or intermediate systems do not exchange routing tables but exchange link states. Link state advertisements (LSAs) describe different aspects of the network and, simplistically, each router within the network stores the most recently generated LSA from the other routers in the network. Once each router in the network has a full set of LSAs from the other routers in the network, then it can carry out a shortest path calculation to compute routes to all destinations in the network. The operation of a link state protocol can be divided into several parts: ◗

Discovering neighbors and their addresses. Neighbors on a network (either broadcast or nonbroadcast) are discovered using a simple hello mechanism.

Routing

97

◗

Measuring the cost to each neighbor. Typically the cost to reach a neighbor is taken as the interface cost to reach that specific neighbor.

◗

Construct the LSA, indicating all it has just learned. Link state protocols operate by ensuring that all routers in a given domain have the same topology information. Conceptually each router constructs an LSA, which reflects the cost from that router to reach a neighboring router. This concept is illustrated in Figure 5.11.

◗

Send or flood the LSA to all neighbors. Following on from the construction of the LSA, each router sends or floods that LSA to each specific neighbor. The sequence number and the age values are used to check the validity of the new LSA versus any previous LSAs received from the router. Any new LSAs received by a router are flooded out

Router B

Cost 6 Router C Cost 9

Cost 15 Cost 8

Router A

Cost 1 Router D

Link state advertisement Router A

Router B

Router C

Router D

Sequence No. # Age # Node Cost B 9 D 1

Sequence No. # Age # Node Cost A 9 C 6 D 15

Sequence No. # Age # Node Cost B 6 D 8

Sequence No. # Age # Network Cost A 4 B 13 C 8

Figure 5.11

LSA construction.

98

Mobile IP Technology for M-Business

on all interfaces except the interface on which the LSA was originally received. In this way the LSA will be flooded around the complete domain (and the router originating the LSA will discard it if it is received from one of its neighbors). To improve stability, LSAs must be acknowledged by a receiving router. ◗

Compute the shortest path to every other router. When each router has a full list of LSAs, it can use a shortest path algorithm to calculate the path (or route) to each specific node. The algorithm typically used to calculate this shortest path is the Dijkstra algorithm. Simplistically, this algorithm specifies that because each router has the same database of LSAs then each router can calculate the shortest path across the network with itself as root. A simple example is shown in Figure 5.12.

Now that the broad operational modes of the various routing protocols have been explained, we can take a more detailed look at the main routing alternatives in common use.

5.2

Distance vector protocols in detail

This section provides a more detailed explanation of how the distance vector routing protocols work. The specific distance vector routing protocols discussed in this section are: ◗

RIP version 1;

◗

RIP version 2;

◗

IGRP;

◗

Enhanced Interior Gateway Routing Protocol (EIGRP).

With reference to the last section, each of these can be viewed categorically as interior gateway protocols. 5.2.1

Routing information protocol

RIP works by exchanging routing information (by default) every 30 sec with a single RIP update packet carrying routing information for 25 networks or hosts. The maximum size of each RIP update packet is

Routing

Router B Router B

Cost 6

Cost 9 Cost 6

Cost 9

Router C

Cost 15

Router A

Router D

Cost 1

1. Place B as root, examine B’s LSA

Router D

AM FL Y

Router D

Router A

Router C

Cost 15

2. Place A in the path, examine A’s LSA Better path to D found

Router B Cost 6

Router C

TE

Cost 9

Router B

Cost 9

Cost 6

Router C

Cost 8 Router A

Router D

Cost 1 Router D

3. Place C in the path, examine C’s LSA No better path to D found Example of shortest path tree (Dijkstra) algorithm.

Cost 1 Router D 4. Place D in the path, examine D’s LSA Tree is already optimal

99

Figure 5.12

Router A

100

Mobile IP Technology for M-Business

512 octets (excluding the IP and UDP headers). RIP uses the User Datagram Protocol (UDP) port 520 for the sending and receiving of datagrams. RIP uses a hop count to denote the cost to a particular destination network or host. The IP address specified in the RIP packet is the normal 32-bit IP network address. The metric field must contain a value between 1 and 15 inclusive. A metric of 16 associated with a particular network defines infinity and is used to indicate that the specified network is no longer reachable. RIP originally had five packet types (two are now obsolete and one is reserved by Sun Microsystems), so the remaining two commonly used packet types are the request packet and the response packet. ◗

Request packet: This is indicated by the value 1 in the command field and is used to request either the full routing table [indicated by a single network in the request packet (address 0.0.0.0) with a metric of 16] or part of the routing table. (Networks for which information is being requested are listed in the packet with infinite metrics.) It is uncommon for a partial request to be made apart from diagnostic software.

◗

Response packet: This is indicated by the value 2 in the command field. Response packets can be generated in response to a request packet, as a periodic update, or as a triggered update. Periodic updates are sent every 30 sec (by default) and contain the full routing table. Triggered updates occur when there has been a change to a particular route or set of routes (e.g., metric change); the full routing table does not need to be forwarded in this instance.

RIP version 2 is specified in RFC 1723 and was designed to address some of the limitations of RIP version 1. The operation of the protocol is for the most part exactly like that of RIP version 1, however, the limitations that have been addressed include these: ◗

Subnet support: The lack of subnet mask support within RIP version 1 is a particularly serious omission. RIP version 2 uses the unused fields in the RIP message to carry the subnet mask (and also the next hop address). The subnet mask is applied to the IP address carried within the address field to yield the network address.

Routing

101

◗

Security: If authentication is used, the address family identifier is set for the first entry in the RIP version 2 message so that only 24 routing entries can be carried by a single RIP packet.

◗

Route tag: The route tag field is used to indicate whether a route is internal to a domain or external to a domain and hence denotes routes that may have been imported or redistributed from another routing protocol such as an EGP.

◗

Next hop: The next hop field specifies the immediate next hop to which packets to a destination network should be forwarded and is used to optimize the routing. The next hop address must be directly reachable on the subnet over which the advertisement is made (a next hop of 0.0.0.0 indicates that routing should be via the originator of the update).

RIP version 2 can either interwork with RIP version 1 or be configured to operate independently; that is, RIP version 2 can be configured to either broadcast each update or to multicast each update (using multicast address 224.0.0.9) to RIP version 2 routers. 5.2.2

Interior gateway routing protocol

IGRP is a proprietary Cisco Systems distance vector protocol. IGRP by default sends updates every 90 sec. The IGRP header uses 14 octets per route advertised. IGRP runs on top of IP, and a maximum of 105 routes can be advertised per IGRP routing update. IGRP operates as per RIP version 1 and like RIP version 1 does not provide VLSM support. The main differences between IGRP and RIP version 1 are discussed next. Metric

RIP associates a hop count with particular routes. In some instances, however, this can provide suboptimal routing as depicted in Figure 5.13. In this instance packets will be routed to network 2 (by router A) via router B. This is because there is a hop count of 1 to reach network 2 from router A, as opposed to a hop count of 2 to reach network 2 via router C. Clearly in this instance the optimum choice is to route packets to network 2 via router C. IGRP overcomes this hop count problem by using a metric that describes bandwidth, reliability, load, and delay. The algorithm used to calculate the IGRP metric is shown in Figure 5.14.

102

Mobile IP Technology for M-Business Network 1

Network 2

Router A

19.2 Kbps

2 Mbps

Router B

2 Mbps Router C

Network 3 Use of hop count in RIP.

Figure 5.13

BW - 16000 Delay 630

BW - 2048 Delay - 20000

BW - 448 Delay - 20000

Network N

Intermediate network Router A

Figure 5.14

Router B BW - 16000 Delay 630

Network M

IGRP metric calculation.

The metric for router A in Figure 5.14 to reach network N is calculated using the following rules: 1. Select the smallest outgoing bandwidth along the path between router and the destination network. In this example the smallest outgoing bandwidth from router A to network N is 2,048 Kbps (out of a choice of either 2,048 going right and 16,000 going left, through network M). 2. Divide 10,000,000 by the smallest outgoing bandwidth. Round this result down to the nearest integer value. In this example the result would be 10,000,000/2,048 = 4,882. 3. Add the delay value on each of the outgoing interfaces. In this example, the total delay of the outgoing interfaces between router A and the destination network would be 20,000 + 630. This would provide a total of 20,630. Divide this result by 10 to produce 2,063.

Routing

103

4. Add the two results from steps 2 and 3, that is, 4,882 + 2,063 = 6,945. This is the metric that router A would use as the cost to reach network N. This formula is similar to that used by EIGRP, which multiplies the result of step 4 by 256. The IGRP metric allows for greater flexibility and administrative control over the hop count used by RIP. For example, a specific interface (i.e., Ethernet) can be configured with an administrative bandwidth of 10 Mbps, which will be reflected in the metric associated with the route in the routing table. Because IGRP makes use of a metric to indicate a distance to a particular network (as opposed to the hop count used by RIP), stability of the routing protocol is paramount. To this end, IGRP relies heavily on stability features such as hold-down timers, triggered routing updates, and a split-horizon scheme with poison reverse. Autonomous system numbers

IGRP (like EIGRP) domains are associated with an autonomous system. Routers that wish to communicate must have interfaces within the same autonomous system. 5.2.3

Enhanced interior gateway routing protocol

EIGRP is an enhanced version of IGRP and in this respect is also proprietary to Cisco. Despite being a distance vector protocol EIGRP attempts to “operate” in the same manner as a link state protocol using partial updates and acknowledgments to provide reliability. EIGRP is more complicated than IGRP, hence, the greater level of detail provided here. EIGRP can be used in both IP and AppleTalk networks—a separate instance of the EIGRP routing protocol operates for each protocol in use, effectively operating as “ships in the night” within the same router. The EIGRP protocol has a number of basic components that fit together as shown in Figure 5.15. Each of the components shown in this figure is now explained in some detail. Neighbor discovery

EIGRP must maintain reachability information for each of its adjacent neighbors on each of its directly connected networks. This process is achieved through the process of neighbor discovery and maintenance,

104

Mobile IP Technology for M-Business Routing table

Form routing table entries Topology table

DUAL Select topology table entries Queries, replies, updates

Reliable transport

Acknowledgments

Neighbor table

Hellos

Figure 5.15

Neighbor discovery

EIGRP protocol architecture.

and it makes use of the periodic generation of hello packets. As long as a router receives hello packets from a neighbor configured as part of the same autonomous system, then it assumes that the neighbor is functioning correctly. The hello process does not carry any indication that an “adjacency” has formed, hence there is no way for a local router to know if its neighboring routers know that it exists. This can lead to problems when unidirectional traffic flows are observed (i.e., when hello packets are received in one direction but not in the reverse path). The neighbor discovery process is important because it provides the mechanism by which an EIGRP-capable router dynamically learns of other routers attached to its directly connected networks. This information is then maintained in a neighbor table. The neighbor table must maintain information on the address of the neighbor and the interface through which the neighbor can be reached. Each neighbor also advertises a hold-down period—the length of time its neighbors should

Routing

105

“believe” the router is reachable in the absence of received hello packets. This is typically three times the hello interval, but can be configured to suit particular circumstances. The hold-down interval and hello interval are included in the generated hello packets. This allows the hello and hold-time values to be set independently on routers attached to a common network. However, care must be exercised when changing the hello and hold-down values because they can affect overall convergence times. Hello packets are transmitted as multicasts to the IP address 224.0.0.10 for neighbor discovery and maintenance—these packets are not acknowledged. Neighboring routers must be configured to be in the same autonomous system for the EIGRP “adjacency” to be formed. This process is displayed in Figure 5.16. Hello packets are multicast at a default interval of 5 sec on LANs and point-to-point interfaces. Hello packets are forwarded at a default of 60 sec on nonbroadcast multiaccess networks such as frame relay. Reliable transport/EIGRP packet types

The reliable transport component is responsible for guaranteed ordered delivery of EIGRP routing protocol packets to all neighbors. Because EIGRP behaves like a link state protocol in the forwarding of partial

B Autonomous system 10

Hello (multicast) Destination 224.0.0.10

A

Autonomous system 10 Hello (multicast) Destination 224.0.0.10 Figure 5.16

Neighbor discovery using hello packets.

C

Autonomous system 10 Hello (multicast) Destination 224.0.0.10

106

Mobile IP Technology for M-Business

updates, these partial updates must be guaranteed. Reliable transport is provided using sequence numbers and acknowledgments. All packets that carry routing information (i.e., query, reply, and update packets) are forwarded reliably (as they are not sent periodically). Acknowledgments and hello packets are not sent reliably. EIGRP supports five packet types: 1. Hello packets: Hellos are multicast at regular, periodic intervals and are transmitted to the multicast address (224.0.0.10) regardless of network type. Hello packets carry a zero acknowledgment field and hence are not acknowledged. 2. Acknowledgments: An acknowledgment is in effect a special instance of a hello packet and contains no data, but has a nonzero acknowledgment number. Acknowledgments are always sent as unicast packets. 3. Updates: Update packets are used to indicate the reachability of network destinations. When a new neighbor is discovered, the update message is unicast. This allows the topology table to be constructed. When a neighbor already exists and there is a change to the routing table, the update message will be multicast. Update messages are always transmitted reliably. Note that the information provided in update messages depends on whether split horizon is enabled on the particular outgoing interface—Cisco’s implementation of split horizon also incorporates poison reverse. The “simple” split-horizon scheme omits routes learned from one neighbor over an interface being included in updates sent to that or any other neighbor on that interface. The split-horizon with poison reverse scheme does include routes learned from one neighbor in updates sent to others on the same interface; however, the metric associated with these routes will be set to infinity. 4. Queries: Query packets are only transmitted when a router does not have a successor or feasible successor for a particular destination. In this scenario, the router will send out a query to all neighbors. Queries are transmitted as multicast packets. Briefly, queries “ask” neighboring routers of the cost to reach a destination network via the neighboring router. Queries also indicate to a receiving router that the route to a destination network (via the querying router) is

Routing

107

no longer valid—this information will activate the DUAL (diffusing update algorithm) process and the invalid route will be removed from the topology table and subsequently the routing table. 5. Replies: Reply packets are sent in response to queries and indicate to the querying router the cost to reach a specific destination network (as requested in the query packet). The routing information contained in reply messages will depend on whether split horizon is enabled on a particular interface (as discussed earlier in the updates section). Replies are unicast to the originator of the query. Topology table

When a router dynamically learns about a new neighbor (i.e., by receiving a hello message) then the router receiving the hello will send an update message. This update message communicates the routes and metrics that the neighboring router uses to reach the networks within the topology. This process is depicted in Figure 5.17, in which we assume that router A also receives a hello message from router B. The information contained in the update messages is used to populate the EIGRP topology table. The information that is maintained in the topology table is used to populate the routing table of the protocol in question (e.g., IP, Novell, AppleTalk). The routing table can be seen as a subset of the topology table.

Router A

Router B

Hello (multicast) Sequence 0, Acknowledgment 0 Update (unicast to Router A) Sequence 10, Acknowledgment 0 Update (unicast to Router B) Sequence 100, Acknowledgment 10 Update (unicast to Router A) Sequence 11, Acknowledgment 100 Acknowledgment (unicast to Router B) Sequence 0, Acknowledgment 11

Figure 5.17

Neighbor discovery and exchange of routing information.

108

Mobile IP Technology for M-Business

The topology table will consist of the most optimum route to a specific destination network (i.e., via a successor router) and “backup” routes to the destination network (i.e., via feasible successor routers). Both of these routes will be maintained in the topology table; however, the optimum route will be placed into the routing table. Equal cost routes will be maintained in the topology table and also added to the routing table. Along with the routes to a specific destination, the topology table also maintains the metrics that neighboring routers use to reach a network. A key premise of distance vector protocols is that if routers advertise a route to a destination then that router must use that particular route to forward packets. Hence, the topology table will be updated when a connected interface or metric changes. The topology table entry for a specific destination can have one of two states: passive or active. If a router has either a successor or feasible successor for the destination, then the entry in the topology table will remain in a passive state. This means that if the router loses a route to a destination, it will then look in the topology table for a route via a feasible successor. If one is available, then this route will be “promoted” into the routing table and, hence, the state will remain passive for the destination (thus avoiding any computation of routes). If a router does not have a successor or feasible successor for the destination, then the route will become active. When a route is active, recomputation is necessary and this involves sending a query packet to all neighboring routers. The DUAL process caters for the change of state from passive to active (and vice versa). DUAL finite state machine

The distributed (or diffusing) update algorithm (DUAL) is the algorithm used by EIGRP to ensure that loop-free routes are used within a network. The DUAL finite state machine tracks all routes and their metrics as advertised by neighboring routers and processes this information to determine if the route should be placed into the EIGRP topology table. The optimum route to a destination network will be entered into the routing table and the topology table. This optimum route will be via a successor—a successor is a neighboring router that has the least cost path to a destination network and that is guaranteed not to be part of a routing loop.

Routing

109

AM FL Y

In Figure 5.18, router C will select router A as its successor for access to network N. The cost of the route to network N is 110 via router A as opposed to 1,010 via router B and 210 via router D. The route via the successor will be maintained in both the EIGRP topology table as well as in the routing table. Had there been a second equal cost path to network N, then router A would have two successors and would apply load sharing on either a per-destination basis (fast switching) or on a per-packet basis (process switching). The cost of the route to network N via router A is 110; this is the least cost and this metric is defined as the feasible distance (FD) to reach network N from router C. Once a router has calculated a feasible distance (i.e., the optimum path to the destination network), it is able to determine backup routes via feasible successor routers. A feasible successor router is defined as a neighbor router that advertises a path to the destination network that is not the least cost path and hence is not used for forwarding data. To become a feasible successor, a neighboring router must satisfy the EIGRP feasibility condition. The feasibility condition is implemented as part of Cisco’s EIGRP and includes the following three steps:

TE

1. Calculate the subset of neighboring routers whose advertised metric to the destination network is less than the feasible distance. Network N Cost 10

Cost 10

Cost 10 A

D

B

Cost 1000 Cost 100

Cost 200

C

Figure 5.18

DUAL successor/feasible successor selection.

110

Mobile IP Technology for M-Business

Neighboring routers satisfying this initial condition become part of set V1. The successor router cannot (by definition) be part of the V1 set. In Figure 5.18 the feasible distance to network N as calculated by router C is 110. The distance as advertised by router B to reach the destination network N is 10 and the distance as advertised by router D is also 10. Thus the metric as advertised by router B and D is less than the feasible distance, hence router B and D become part of set V1. 2. Calculate Dmin, where Dmin is the minimum cost to the destination network via the neighboring routers contained in the V1 set. Routers B and D are the neighboring routers in set V1. The minimum cost to reach the destination network via router D is 210. Thus Dmin is equal to 210. In scenarios where there are a number of elements to the V1 set, Dmin will equal the minimum cost to the destination network. 3. Determine membership of set V2. Set V2 is the set of neighbor routers who are part of V1 and whose computed cost to reach the destination network equals Dmin. This subset of routers forms the group of feasible successor routers for access to the destination network. Routers B and D are the elements of V1, now applying the above rule, that is, taking the minimum cost to reach the destination network Dmin and comparing it against each router in set V1 gives router D as the only feasible successor for accessing network N from router C.

This process ensures that the routing table formed is loop free and also that a finite list of feasible successors is formed. Note that a route may have more than one successor and also more than one feasible successor. The information pertaining to successors and also feasible successors is entered into the topology table. The successor route(s) are used within the routing table. When multiple successors are available with equal cost paths, multiple routes will be entered into the routing table and load sharing will result. The route via the feasible successor can be seen as a backup route providing quick convergence and switch over in scenarios where the route via the successor fails.

Routing

111

EIGRP in operation

EIGRP makes use of all of the components described in the previous sections. When a router loses a route to a destination network, it will consult the EIGRP topology table to see if a route exists via a feasible successor. If a route to the destination network is available via a feasible successor, then the route will remain in the passive state and the route via the feasible successor will be promoted to the routing table. If a route via a feasible successor is not available, then the route will migrate to an active state—this requires the router to transmit query packets to all neighboring routers on interfaces other than the one where the previous successor was located. Additionally should a query be received over an interface from which the successor was accessible, then it too will also be queried in response. These query packets inquire as to whether neighboring routers have a route to the destination. Neighboring routers will reply to this query if they have a route via a feasible successor to the destination or if they have no valid route at all. However, if the neighboring routers were using the querying router as their successor (i.e., next hop) for the destination network and the neighboring routers do not have a feasible successor route for the destination, then the neighboring routers will in turn query all of their neighbors. These routers will reply if they have a feasible successor route for the destination. (If they do not then these routers will send out another wave of query packets.) When the last reply is received, the routers can reply to the original query. This ensures that the expanding tree of queries collapses back to the point of origin. Once a router converges on a route (i.e., has received replies to queries) and where a metric or interface has changed to reach the destination, then the router will send an update message to each neighbor indicating the routes on which the router has converged.

5.3

Path vector

We now move on to look at the path vector category of routing protocols and will consider version 4 of the Border Gateway Protocol (BGP-4) for this purpose. The BGP-4 path vector protocol is used throughout the Internet today as a mechanism for advertising information associated with different autonomous systems. As indicated previously, BGP is used as an EGP.

112

Mobile IP Technology for M-Business

BGP-4 is defined in RFC 1771 and is a path vector protocol, which is used extensively within the Internet and sometimes within large corporate networks. BGP is an exterior gateway protocol, used to carry routing information between autonomous systems as depicted in Figure 5.19. BGP is a very powerful and ubiquitous protocol that evolved from an earlier protocol used to carry routing information between autonomous systems known as the exterior gateway protocol. EGP had severe problems regarding routing loops and so has been superseded by BGP. BGP is termed a path vector protocol because each piece of routing information is associated with a path of autonomous systems and indicates the path a route has traversed. This vector of paths also gets around the counting to infinity problem inherent in distance vector protocols because, when a routing update is received, each router checks to see if its autonomous system number is already contained in the path of autonomous systems. If a loop has occurred, then the update can be immediately discarded. BGP operates using the hop-by-hop routing paradigm, which specifies that any routes advertised from a BGP router to its peers are those routes used specifically by the advertising BGP router. Put another way, a router cannot advertise routes to a peer and then proceed to forward traffic via another route unless some form of source routing is used. Reliable transmission for BGP packets is provided by the Transport Control Protocol (TCP). Two neighboring routers will use TCP port

AS 100

AS 20 AS 10 AS 50 AS 40

Interior gateway protocol used within AS Figure 5.19

AS 200

Exterior gateway protocol used between ASs, e.g., BGP

BGP used as an exterior gateway protocol.

Routing

113

number 179 to establish a session over which BGP can exchange routing information. BGP does not provide periodic updates; instead, after an initial exchange of the complete routing table only changes to the routing table are forwarded. Routing information is exchanged between BGP routers using an update message (the maximum BGP packet size is 4,096 octets, the minimum size is 19 octets). BGP uses four types of messages: open, notification, keep alive, and update. The sending of the open message follows from the successful establishment of the TCP session. The notification message is used to inform a BGP peer of errors that have occurred in exchanging information or establishing a session. Keep alive messages are used to ensure that neighboring routers are still reachable (keep alive messages are sent periodically). Update messages provide the mechanism by which routing information is exchanged between BGP peers. The update message can be split into three specific parts: 1. Withdrawn routes: BGP uses the withdrawn routes field to indicate those routes that are no longer valid. Withdrawn routes are represented by the the nomenclature where the length represents the mask in bits and the prefix represents the IP prefix. 2. Path attributes: One of the most important attributes of BGP is the fact that it carries additional information related to advertised routing information. Specifically, these path attributes (of which there are four categories) allow very powerful routing policies to be administered. Two of the path attributes of interest include the AS_Path (which includes the sequence of autonomous systems traversed) and the Next_Hop (allowing optimized routing to take place on exit from an autonomous system). There is no restriction on the type of routing policies that BGP can support, so the policies that can be supported are vendor independent. BGP merely provides the attributes that can be worked on to allow suitable policies to be administered. The ability to design a policy based on the path attributes is one of the major features of BGP. 3. Network layer reachability information: Update messages naturally carry network layer reachability information, which is

114

Mobile IP Technology for M-Business

represented by the the nomenclature. Again the length represents the bit mask. As stated previously, BGP is used to advertise network reachability information between autonomous systems. It can also be used to advertise routes within an autonomous system. If BGP is used within an autonomous system then it is termed an internal BGP (IBGP). If BGP is used between autonomous systems, then it is termed an external BGP (EBGP). BGP may also be used internally to advertise routes from other autonomous systems. An example of this would be where an autonomous system is to act as a transit autonomous system. In some cases, the IGP may not be able to cope with all of the BGP routes being redistributed into it. For example, redistributing the complete Internet routing table into an IGP would not be sensible and would probably cause the routers within that autonomous system to run out of both memory and processing power! Additionally, because the IBGP still propagates the BGP attributes and network layer reachability information, this gives the network administrator a great deal of control over which routes are used as exit points from the autonomous system. If BGP is used within an autonomous system, it is important to ensure that, when a BGP router receives an update from another BGP router within the same autonomous system, the receiver does not forward that BGP update to other BGP nodes. This case is shown in Figure 5.20. Router C does not onward distribute IBGP updates from both router B and router D, the reason being to avoid routing loops within the autonomous system (because the check on the sequence of autonomous system numbers is no longer relevant for avoiding routing loops). To get around this problem, a full mesh of internal BGP peers should be configured. A number of other techniques can be used to enable the scaling of IBGP such as confederations but these are beyond the scope of this chapter.

5.4

Link state protocols

The two leading link state protocols, both of which fall into the category of Internal Gateway Protocols are (1) Open Shortest Path First (OSPF) and (2) Integrated Intermediate System to Intermediate System.

Routing

115

Router C IBGP update network 132.146.0.0

IBGP update network 200.10.10.0 IBGP peering

Router B

EBGP update network 200.10.10.0

EBGP peering

Router A Network 200.10.10.0

Figure 5.20

5.4.1

Router D

EBGP update network 132.146.0.0

EBGP peering

Router E

Network 132.146.0.0

Internal BGP.

Open shortest path first

RFC 1583 defines version 2 of the OSPF routing protocol, which is a link state protocol that introduces a number of advantages over the more traditional distance vector type routing protocols already discussed. To illustrate, RIP limits the diameter of a network to a maximum of 15 hops, which drastically affects the scaling of the topology and it cannot handle variable-length subnet masks (VLSM), which serve to summarize route information. OSPF overcomes these limitations and also provides a logical hierarchy in the form of areas that are overlaid onto the physical network. This allows for the logical partitioning of a large-scale network and also lends itself more suitably to address summarization (and, hence, smaller IP routing tables). The area concept also restricts routing traffic from within that area from being flooded throughout the whole network, which allows large networks to be built using OSPF. Perhaps the major difference between distance vector and link state routing protocols is that when using a link state protocol, update traffic only occurs when there is a change to the topology of the network: If a link changes state (e.g., from up to down) then information pertaining to only this change is flooded. This reduces the bandwidth required (because only that specific link state change needs to be advertised) and

116

Mobile IP Technology for M-Business

provides for a quicker update to routing tables within the network as the change is flooded immediately. Link state protocols also reduce the chance of routing loops (which are a key problem of distance vector protocols). In contrast to link state protocols, distance vector protocols send periodic updates of the whole routing table regardless of whether the network has changed topology or not. 5.4.2

OSPF in operation

A very brief summary of an OSPF setup follows. All routers in an area have a synchronized topological database. Each router in the area uses the shortest path first (Dijkstra) algorithm to calculate the shortest path routes to destination networks in the area. Each router can then build up its own intra-area routing table. Interarea routes are provided by summary link advertisements, which are added to the routing table. External routes are then added (assuming the area is not at the end of the network). Figure 5.21 illustrates the following process: 1. A router goes through a number of states before forming an adjacency with another router. The designated router, backup designated router, and neighbor election are achieved via the OSPF Hello Protocol. When the interfaces on router A and router B become operational they then begin sending hello messages. 2. When router B sees a hello message, it changes to the INIT state. This state indicates that a hello packet has recently been received from the neighbor however bidirectional communication has not yet been established because the receiving router did not appear in the neighbor’s hello packet. 3. A router changes state to TWO-WAY when it sees its own address in a neighbor’s hello packet. Routers are said to be neighbors when they see their own address in their neighbor’s hello packets. The TWO-WAY state is the most advanced state short of beginning adjacency establishment. In this state both routers decide whether to become adjacent—if the OSPF network is broadcast or nonbroadcast multiaccess and neither router is DR or BDR then the two routers stay in a TWO-WAY state with each other (i.e., neighbor state) and do not form an adjacency. The forming of an

Routing

117

Router A

Router B

DOWN

DOWN Hello (DR = 0, routers seen = 0) Hello (DR = Router B, routers seen = A)

EXSTART

INIT

Database description (Seq = X, master) EXSTART Database description (Seq = Y, slave)

EXCHANGE

Database description (Seq = Y) Database description (Seq = Y + 1)

EXCHANGE

Database description (Seq = Y + n) Database description (Seq = Y + n) LOADING

Link state request Link state update

FULL

FULL Figure 5.21 databases.

Forming an adjacency and the synchronization of link state

adjacency ensures that the two routers have exactly the same link state database. 4. The EXSTART state is the first step in creating an adjacency between two neighbors. The goal of this step is to decide which router is the master and which is the slave, and to determine the initial database description sequence number. Once the initial database description number has been agreed on, then the EXCHANGE process takes place, whereby database description packets are exchanged between the two routers. The exchange of database description packets is a summary of the link state information contained in a router’s database. Hence, each neighbor can

118

Mobile IP Technology for M-Business

detect a more up-to-date piece of link state (LS) information (by examination of LS sequence number, LS age, and LS checksum fields). During this period, a list of the more up-to-date LSAs that are available from the neighboring router is maintained. This list is known as the link state request list. 5. If the two databases are not synchronized and a link state request list has evolved, then the LOADING state is entered, whereby either router may request a more up-to-date LSA from its neighbor. 6. Each router trawls through its own link state request list and sends a link state request packet for a particular advertisement to its neighbor. Requests are acknowledged with link state update packets that contain the more recent link state database contents. Only one link state request packet may be outstanding at any particular time. 7. When all link state requests are acknowledged then the adjacency will enter the FULL state. At this stage, link state databases are an exact match between the two routers. This part of the process provides the database synchronization among routers in an area, and all routers in an area maintain the same topological database. We should stress that an exchange of database information is via an adjacency only. 8. Once the topological databases of all routers in an area are synchronized then the shortest path first (Dijkstra) algorithm can be calculated. This is carried out separately by each router in the area. Each router places itself as the root of the tree and by inspection of the link state database can ascertain the lowest costs to reach each destination network; in this way the shortest path can be calculated and the routing table can be built. We should stress that the shortest path first algorithm uses only the router link and network link advertisements as part of its calculation and it is this which causes the greatest CPU overhead. Future changes to the link state database are sent to all routers in the area by the flooding procedure. This dictates that when there is a change to a router’s link or to the status of a neighbor then the router will increase the sequence number of the update and then flood the new update across all adjacencies. Increasing the sequence number is essential

Routing

119

because this is used by neighboring routers to detect which link state updates are the most recent. Hence, the most recent link state updates are used in the calculation of the shortest path tree, whereas the older link state updates are aged out of the database. The flooding procedure is reliable (i.e., all flooded updates are acknowledged) and this ensures synchronization of the topological database in all routers in an area. 9. The next stage of calculating the routing table is to add the summary link advertisements injected by the area border routers—these form the interarea routes. Note that summary link advertisements can be used to advertise a summarized route as configured on the area border router.

AM FL Y

10. External routes are then added to the routing table by inspection of the external link state updates. Normally external link state updates describe routes to specific destinations (external to the autonomous system) or alternatively a default route can be flooded into the autonomous system. External routes will not be flooded into an area if that area has been configured as a stub area.

TE

It should be stressed that the Dijkstra algorithm is recalculated only when there are changes to either router links or network link updates within an area. For the most part, the Dijkstra algorithm is not recalculated when there are changes to both summary and external link updates. Figure 5.22 summarizes the processes involved when a link fails and how this affects both the link state database and also the IP routing table. OSPF network types

This section explains the working of different OSPF network types on different physical network topologies, such as broadcast and nonbroadcast multiaccess (NBMA) technologies. This gives some basis for determining which configurable OSPF network types to use over which technologies and what the advantages and disadvantages of each are. These logical OSPF network types include the following: ◗

Point to point: This is a network that joins a single pair of routers. These networks do not use a designated router or a backup designated router. Adjacencies will be formed between neighbors

120

Mobile IP Technology for M-Business

Hellos

(1) Hello

Hellos

(1) Hello: Hellos are used to establish neighbor status and to detect when neighbors are no longer reachable over a given link.

Neighbor table

(2)

Link state Updates, link state acks

Flooding

Link state Updates, link state acks

(2) Flooding: Ensures that all routers in an area have the same link state database.

Link state database

(3) SPF

(3) SPF: Calculates the routers IP routing table from the link state database.

Router table

Figure 5.22

OSPF processes.

(assuming the values of the network mask, hello interval, and dead interval match the values of the receiving interface). ◗

Point to multipoint: This network type can be used to provide connectivity across NBMA networks such as frame relay and ATM. OSPF treats this network as a series of point-to-point networks and, hence, a designated router is not required. This OSPF network type would be used in preference to the NBMA OSPF network type for networks such as frame relay and ATM. An example point-to-multipoint network is depicted in Figure 5.23.

◗

Nonbroadcast multiaccess network: This is a network that supports multiple routers but does not have broadcast capability. Neighboring routers must be statically configured to ensure correct operation of

Routing

121

Point-multipoint interface

Point-multipoint interface

Figure 5.23

Point-multipoint interface

Point-multipoint interface

Example point-to-multipoint network.

the protocol. Frame relay, X.25, and ATM are examples of NBMA networks. ◗

5.4.3

Broadcast network: This is a network that supports more than two attached routers and has the ability to address all routers on the network with a single physical message. Ethernet or token-ring LANs are examples of broadcast networks. Integrated intermediate system to intermediate system

The Intermediate System to Intermediate System (IS-IS) protocol is a link state routing protocol designed by the ISO standards body to provide routing in OSI environments. Because the ISO has a telecommunications background, it uses different terminology than that of the IETF, which has its roots in distributed computing. For example, ISO refers to a router as an intermediate system (IS). That said, there is considerable cooperation between ISO and the IETF and standards transfer between the two. When IS-IS reached a mature state, RFC 1195 was issued, which specified an integrated routing protocol based on IS-IS. RFC 1195 provides, among other things, six new fields for the transport of IP traffic within IS-IS: (1) protocols supported, (2) IP interface address, (3) authentication information, (4) IP internal reachability information, (5) IP external reachability information, and (6) interdomain routing protocol information.

122

Mobile IP Technology for M-Business

At the time of issue there appeared to be many advantages for having an integrated routing protocol (such as the ability to run a single protocol to support both traffic types and also future traffic types and additionally the reduction in network management overhead, CPU overhead, etc.). Over time, however, the main use of IS-IS has been for the support of IP traffic, hence, the integrated IS-IS nomenclature. Integrated IS-IS in action

Integrated IS-IS (also known as IS-IS) operates in a similar manner to OSPF. Hence, this section summarizes the operation of IS-IS and highlights differences between the two protocols. Both IS-IS and OSPF support link state routing and also impose a hierarchy on the network design. OSPF uses the concept of splitting the network into areas whereas IS-IS uses the concept of level 1 (intra-area) routing and level 2 (interarea) routing. Level 1 routers can be viewed as area routers, and level 2 routers can be viewed as the backbone routers. Routers can be configured as level 1, level 2, or level 1 and 2 routers as shown Figure 5.24. The connection of the level 2 routers that form the backbone domain must be contiguous. So there must be a path between all level 2 routers that traverses only level 2 routers. In IS-IS level 1 routers know only the information about their own area and hence in this sense can be likened to OSPF stub areas. Although IS-IS is used for the routing of IP traffic, it is mandatory that each IS (or router) be configured with an OSI style address in the form of a network entity title (NET). The NET is used purely for the operation of the IS-IS protocol (specifically to denote the area membership of routers and in the exchange of IS-IS hello packets) and can vary in length from 8 to 20 bytes. A simplified structure for the NET address is shown in Table 5.1.

L2 only

L1 only

Area 2

Area 3

L1L2 L1L2 L1L2 L1L2

L1 only

Area 1 Figure 5.24

Interworking of IS-IS routers.

Area 4 L1 only

Routing

123 Table 5.1 Network Entity Title Format Area

Identity

Selector

(1–13 octets)

(6 octets)

(1 octet)

The area field in reality supports a number of layers of hierarchy but the area parameter must be unique across the routing domain (i.e., areas must be uniquely identified). The identity field conveniently is the same length as an IEEE 802 address (i.e., Ethernet MAC address) and because these addresses are unique then it makes sense to use this address. The selector field is used to differentiate between multiple network layer users, but for the most part this is always set to 00. IS-IS packets are encapsulated directly in the data link layer frame, whereas OSPF packets run on top of IP. IS-IS uses variable-length fields. This is a flexible option, but not the most efficient encoding mechanism in terms of cache lookups and so forth. IS-IS uses hello packets to bring up and maintain adjacencies on broadcast and nonbroadcast networks. Three types of hellos are used in IS-IS: level 1 LAN IS to IS hellos, level 2 LAN IS to IS hellos, and pointto-point IS to IS hellos. The hello packets transmitted on point-to-point links are padded to the full maximum transmission unit (MTU) size; hence, where there are inconsistencies between MTU size, adjacencies may not be formed (this is only an issue on point-to-point adjacencies). Additionally, IS-IS only supports point-to-point or broadcast network types. Networks that support point-to-multipoint must be configured completely as point to point. When two routers become adjacent, both OSPF and IS-IS exchange the headers of link state packets (LSPs) contained within their topological database. OSPF does this by exchanging database description packets when the adjacency is first forming, whereas IS-IS achieves this by exchanging complete sequence number packets (CSNPs). On point-topoint links, IS-IS exchanges CSNPs only when a link is coming up and the adjacency is first forming. On a broadcast network (such as a LAN), however, IS-IS uses a designated router (known as the DIS in OSI speak) to transmit the CSNPs periodically. Note that in OSPF a number of parameters must be configured identically for two neighboring routers to become adjacent, such as the hello, dead time, and the stub area flag. These can either be configured differently in IS-IS or may not be required at all.

124

Mobile IP Technology for M-Business

Due to the periodic transmission of CSNPs on a broadcast network, there is no need for other routers to specifically acknowledge receipt. Additionally, where the range of link state headers does not fit into a CSNP, fragmentation occurs. Fragmentation is dealt with by IS-IS by including the start and end source addresses contained within the CSNP. When a router receives this CSNP and detects that its address fits within the range but has not been included within the CSNP then it will transmit its link state information to the designated router (or DIS). On a point-to-point link, reliable exchange of the link state database is provided by the use of partial sequence number packets (PSNPs), which can be seen merely as acknowledgments or requests for the transmission of the latest link state packet (LSP). OSPF uses IP fragmentation when the link state information is too large for a particular packet. Link state information is forwarded using an LSP or LSA in OSPF. IS-IS specifies two types of LSPs, namely, pseudo-node LSPs, which represent LANs, and non-pseudo-node LSPs, which represent routers. These two types of LSPs appear similar to the network and router link LSAs within OSPF. More specifically, the pseudo-node LSP provides reachability information pertaining to all routers attached to a LAN; the non-pseudonode LSP provides reachability information through a particular router. The pseudo-node LSP created by the designated router on a broadcast network reduces the number of adjacencies and flooding required across a LAN (this is similar to the operation of the designated router in OSPF). The designated router in IS-IS is elected based on the highest priority. When priorities match, the router with the highest media access control address is used. If a new router with a higher priority attaches to the LAN then this will become the designated router in IS-IS, whereas in OSPF a router with a higher priority will only take over from the existing designated router if that router should fail. Level 1 routers will create a level 1 LSP, a level 2 router will create a level 2 LSP, and a level 1/2 router will create a level 1 and a level 2 LSP. A non-pseudo-node LSP and pseudo-node LSP will be created for each level. The maintenance and operation of designated routers and pseudonodes is as per the IS-IS standard. If an IS-IS designated router needs to send an LSP that is too large to fit into one packet, fragmentation occurs. This allows the fragment to be treated as an independent LSP for the purpose of forwarding and retransmission if the fragment is lost as illustrated in Figure 5.25. In this instance, fragments R.0.0, R.0.1, and R.0.2 are completely independent with different source addresses and different sequence numbers. The fragments can be retransmitted independently of

Routing

125

R R has large LSP to distribute Neighbors

Fragmented LSP R.0.0

R.0.1

R.0.2

Figure 5.25

IS-IS LSP fragmentation.

each other; indeed, the LSPs are only logically reassembled for the purposes of computing routes, thus allowing for efficient forwarding of LSPs that have changed. OSPF avoids large LSPs by allowing router R to send LSPs with different link state information (e.g., networks, router links). RFC 2328 specifies that a router may contain multiple advertisements within a single external and summary LSA to enhance forwarding efficiency; however, many OSPF implementations still use the RFC 1583 implementation, which specifies a single destination only per summary and external LSA. IS-IS allows any router to send an LSP onto a LAN to a well-known (i.e., standard) address listened to by all routers. OSPF uses the designated router to do all the forwarding. Lost packets are accounted for by periodic sending of the CSNP packets used by IS-IS. OSPF uses explicit acknowledgments. Thus when neighboring routers appear or disappear and new IP prefixes are inserted or removed, a pseudo-node and non-pseudo-node LSP will be transmitted. (Note that LSPs will also be transmitted on expiration of an LSP timer.) Once IS-IS has synchronized link state databases and the routing table has been populated with valid routes (following operation of the Dijkstra algorithm) then routing can occur. Routing occurs at two levels: level 1 and level 2. Level 1 routers know in detail only the topology of their area, hence intra-area routing is straightforward. If traffic is to be

126

Mobile IP Technology for M-Business

forwarded interarea, a level 1 router will forward that traffic toward its nearest level 2 router. (A level 1 router knows how to reach a level 2 router due to the setting of the attached bit.) If there are multiple level 2 routers, then the level 2 router with the lowest metric is selected. Level 2 routers are aware of all other areas, hence routing across the backbone can take place. For level 1 and level 2 routing to take place, each router must maintain a link state database for either the level 1 topology or the level 2 topology or both, depending on how the router has been configured. From a security point of view, both OSPF and IS-IS support the use of passwords for authentication of messages. IS-IS allows multiple passwords per interface to be supported, whereas OSPF supports only a single password per interface; this restricts migration possibilities (i.e., where two company networks may merge for instance).

5.5

Choosing the right protocol

As can be seen from the preceding sections, a wide number of IP routing protocols are available, each with different characteristics and hence associated costs in terms of either memory/bandwidth utilization or convergence time. Choosing the right one depends on the type of network being deployed and the requirements of the services that the network will support. This section evaluates the protocols explained earlier in terms of the key criteria set out at the beginning of the chapter: convergence, processing efficiency, bandwidth, memory overhead, scalability, stability, technology independence, interoperability, and security. 5.5.1

Convergence

The distance vector protocols (i.e., RIP and IGRP) tend to converge more slowly than the link state protocols (EIGRP is included in this category because it is often cited by the vendor as being link state-like although it is clearly distance vector in nature). Table 5.2 summarizes the typical range of convergence times for the IGP routing protocols. The times indicated in Table 5.2 for both RIP and IGRP can be reduced to increase the overall convergence time by reducing timers from default levels, but this may result in increased bandwidth overhead because routing updates will be sent more frequently. Additionally, by reducing the hold-down timer used to handle fluctuations in network availability and hence add stability (depending on the number of hops

Routing

127 Table 5.2 Summary of IGP Routing Convergence Protocol

Routing Protocol Type

Convergence Time

EIGRP

Distance vector

100 ms–1 sec

OSPF

Link state

1–10 sec

IS-IS

Link state

1–10 sec

RIP

Distance vector

100+ sec

IGRP

Distance vector

500+sec

from ingress to egress within the network) routing loops may form within the network. Distance vector protocols also have to recalculate the distance vector before it is transmitted. Within the link state protocols the recalculation and forwarding processes are independent (hence LSAs can be forwarded before an SPF recalculation is carried out). A factor in the OSPF and ISIS convergence times is that both make use of a stability feature (which is inherent in the Cisco implementation but not part of the standard) to reduce the CPU overhead of running the Dijkstra algorithm. This feature also suppresses the effects of repetitive state change in the network and minimizes the effect of “flapping links” (usually caused by an intermittent fault on a connection). By default this delay is set to 5 sec and ensures that the routers in the network will not continuously recalculate the SPF (shortest path first). This is particularly important because processing of the Dijkstra algorithm can be processor intensive. A reset of the default times can speed convergence but this may result in more processor occupancy. In Table 5.2 EIGRP clearly converges the fastest. This is partly due to the fact that EIGRP does not attempt to constrain the time between route calculations but this, in turn, can lead to high processor utilization. 5.5.2

CPU utilization

Although CPU utilization is completely dependent on the power of the underlying processor being used, different routing protocols (i.e., link state or distance vector) require varying degrees of CPU power to calculate the routing table. Comparing the processor utilization of routing protocols is difficult and proponents of each protocol can demonstrate topologies that favor one above the other. Additionally, it is possible to include optimizations within each of the protocols with which to reduce the overall CPU

128

Mobile IP Technology for M-Business

utilization. For example, the Dijkstra algorithm of IS-IS can be optimized when metrics of 64 and less are used. Turning off triggered updates will also smooth the overall CPU utilization for distance vector protocols. As processors become more powerful, the impact of the routing protocol should decrease. If this is an issue, it is important not to rely on benchmarks that aim to show a protocol in its best light—the reality may be very different with another network configuration. 5.5.3

Bandwidth efficiency

The bandwidth utilization of distance vector and link state protocols is another contentious subject. Bandwidth utilization is affected primarily by the number of networks being advertised, but also by any imposed hierarchy in the topology of the network and, depending on network service, the meshing of private virtual circuits within the network topology. Distance vector protocols (i.e., RIP v1/v2 and IGRP) transmit updates at regular intervals (for RIP the default period is 30 sec; for IGRP the default period is 90 sec). The size of the routing updates transmitted is dependent on the number of networks being advertised (i.e., the size of the routing table). The link state protocols (including EIGRP) transmit hello packets periodically (between 5 and 30 sec). These hello packets are fixed in size for EIGRP (each router will transmit a 60-byte hello message) and ISIS (padded to the MTU of the underlying link layer, e.g., 1,518 bytes for Ethernet). For OSPF the size of the hello packets is dependent on the number of routers attached to the network segment. For example, on a broadcast network with 50 routers, each hello packet (excluding the MAC header) will be 240 bytes in length [44 + (49 ∗ 4)]. Hello packets are transmitted every 10 sec on LAN interfaces and point-to-point serial interfaces. Additionally the link state protocols of OSPF and IS-IS periodically refresh their link state databases. This is done every 30 minutes for OSPF and 15 minutes for IS-IS, and each router within the network will refresh only the link state packets that they originated. (EIGRP does not refresh its topology database periodically in typical distance vector protocol style.) In general, distance vector protocols use more of the bandwidth than link state protocols. This is particularly true when the network increases in size. For networks with a small number of sites and a single LAN attached, the argument can be made that link state hellos are of

Routing

129

TE

AM FL Y

approximately the same size as distance vector periodic updates. The refreshing of the link state database and the overhead of the link state updates used is more bandwidth efficient than using RIP (or IGRP) to advertise the same number of routes. Where a distance vector protocol is used to indicate that a network is no longer reachable—even assuming that poison reverse is being used—the distance vector protocol information will utilize more bandwidth than a link state protocol. The distance vector protocol will reforward the entire routing table and will indicate those networks unreachable by setting the metric to infinity (RIP uses 16). A link state protocol, however, will forward a new LSA with only valid and relevant routing information. The Dijkstra calculation will operate on this new information to populate the routing table. As the meshing of the network increases, distance vector protocols will also utilize a larger proportion of the bandwidth than link state protocols. Where a router has n neighbors, a distance vector protocol will forward the complete routing table to each of these n neighbors with each update interval. This overhead is greater than that of a link state protocol. Finally, the distance vector protocols (and also EIGRP) do not limit the scope of the flooding of update packets. This means that updates will be rippled across the whole network, whereas with a link state protocol it is possible to limit the scope of update packets via the logical area configuration. Hence, the bandwidth utilization caused by network changes is bounded. For reference, RFCs 1245 and 1246 provide an overview on the bandwidth utilization of OSPF and indicate the bandwidth savings in operational networks as compared with RIP. 5.5.4

Memory overhead

The link state protocols operate using a link state database (for OSPF and ISIS) and the topology table for EIGRP. These need to be stored so that the Dijkstra and DUAL algorithms can be calculated to provide the routing table entries. With distance vector protocols such as RIP superfluous routes can be filtered out. In this way, unnecessary routes will not be injected into a hierarchy of routers and consequently memory utilization will be reduced. The ability to filter out superfluous routes is not possible using a link state protocol because this would contravene a basic concept of a link state protocol: that all routers within an area must have an identical

130

Mobile IP Technology for M-Business

topology database for the calculation of the shortest path tree to take place. 5.5.5

Scalability

The features offered by each of the protocols that relate to the scalability of the protocol are summarized in Table 5.3. As publicly available IP address space is reduced, it is essential that efficient use of existing address space is achieved. The support of VLSM is key to achieving this efficiency and to optimize the most suitable allocation of address ranges. For example point-to-point links require a maximum of two addresses only (i.e., use of a 252 subnet mask) and hence in this scenario it is wasteful to use a wider subnet mask. Table 5.3 Scalability Techniques Used by Routing Protocols Routing Protocol

VLSM Support

CIDR Support

Area Support

Additional Comments

RIP version 1

No

No

No

Hop count limit restricting diameter of network.

RIP version 2

Yes

Yes

No

Hop count limit restricting diameter of network.

IGRP

No

No

No; makes use of autonomous system number to separate domains and hence routing traffic.

Uses a larger metric field, which provides flexibility in assigning link costs.

EIGRP

Yes

Yes

No; makes use of autonomous system number to separate domains and hence routing traffic.

Uses a larger metric field, which provides flexibility in assigning link costs.

OSPF

Yes

Yes

Yes

Allows use of stub areas to reduce amount of external information within area. Strong summarization capabilities to reduce load.

IS-IS

Yes

Yes

Yes

Traffic is routed out of an area via nearest level 2 router, which may not be the optimal path.

Routing

131

Additionally, with some protocols such as OSPF such links may be termed unnumbered, which further reduces the address requirement. A routing protocol that carries a prefix and a subnet mask can support CIDR addresses. This is relevant to core Internet routers in reducing the size of their routing tables and is a major feature of BGP-4. Additionally, CIDR can be used within enterprise networks and, hence, IGPs to reduce the size of the routing table and the degree of information that has to be exchanged (which consumes network bandwidth and router resources). Logical area configurations are used to restrict the flooding domain within both OSPF and ISIS. Additionally, they introduce a hierarchy into the network rather than a flat domain as per the other protocols (i.e., changes propagate across the entire network using the distance vector protocols). This two-level hierarchy requires strict network design and allows a geographical or logical structure to be imposed on the network, as well as introducing stability to the network. 5.5.6

Stability

The stability of a routing protocol can be inferred to some extent from the maturity of the protocol. This is because network administrators know the operational characteristics of the protocol and can exploit them. The stability features included in the various routing protocols are summarized in Table 5.4. 5.5.7

Technology/service independence

Routing protocols should operate independently of the underlying layer 2 technology or service. Where the underlying service is circuit switched such as ISDN, PSTN, or X.25 switched virtual circuits (SVCs), the routing protocol will trigger calls to set up. In these circumstances, control over the frequency and length of calls is essential in reducing end customer costs, and the use of a dynamic routing protocol with periodic updates is not recommended. Instead static routes can be used to route traffic over these dial-up circuits. These are manually configured by the network administrator and although they provide a great deal of control, they are not scalable and do not adapt to changes within the network. However, they are suitable for reducing the costs incurred by a dynamic routing protocol when traffic is to be routed over a dial-up network. Although all of the protocols operate independently of the underlying technology/service, certain recommendations can be made to ensure that correct and optimal routing takes place, as delineated in Table 5.5.

132

Mobile IP Technology for M-Business Table 5.4 Routing Protocol Stability Features

Routing Protocol

Maturity

Stability Features

RIP version 1

Evolved from early days of the ARPANET (concepts used since 1969, became de facto standard due to free inclusion in Unix Systems). Standardized in 1988.

Distance vector protocol; makes uses of limited hop count, split-horizon scheme with poison reverse, triggered updates, and hold-down timers.

RIP version 2

More recently standardized within IETF (1993).

As above.

IGRP

Proprietary to Cisco Systems. Available since 1985.

Distance vector protocol; makes use of split-horizon scheme with poison reverse, triggered updates, and hold-down timers.

EIGRP

Proprietary to Cisco Systems. Available since 1993.

Distance vector protocol; makes use of neighbor discovery mechanism (hellos), guaranteed delivery of packets, DUAL algorithm to provide loop-free topology, retains feasible successor routes. Uses split-horizon scheme with poison reverse.

OSPF

Open standard; standardized initially in the IETF in 1988.

Link state protocol; uses Dijkstra algorithm to provide loop-free tree, guaranteed delivery of packets, designated router election, virtual links (allow nonbackbone area routing), logical network types, various timers to reduce impact of SPF recalculation, retransmission of LSAs. LSA database refreshes every 30 minutes.

IS-IS

ISO Standard since 1992. Based on work originally done for Phase V DecNet.

Link state protocol; uses Dijkstra algorithm to provide loop-free tree, guaranteed delivery of packets, designated router election, automatic detection and repair of level 1 areas, various timers to reduce impact of SPF recalculation, retransmission of link state PDUs. LS database refreshes every 15 minutes by default. Database overload detection.

5.5.8

Interoperability/open standards support

All of the protocols mentioned here have been standardized via the International Organization for Standardisation (apart from the proprietary protocols of IGRP and EIGRP, which are proprietary to Cisco Systems).

Routing

133 Table 5.5 Support of IP Routing Protocol over Layer 2 Technology

IP Routing Protocol

Nonbroadcast Multiaccess Technology (Frame Relay, ATM, ISDN)

Broadcast Technology (SMDS)

RIP version 1/RIP Typically partial meshing of PVCs takes place into host site. Logical version 2/ subinterfaces required to allow IGRP/EIGRP routing updates to be forwarded back out otherwise split horizon needs to be disabled (not recommended because it may lead to routing loops).

Protocols will operate as per LAN technology.

IS-IS

Point-to-point connections supported only.

ISIS will operate as per LAN technology.

OSPF

Typically partial meshing of connections is used within the network. OSPF point to multipoint recommended in these scenarios. (OSPF broadcast network type not recommended because it can lead to routing problems in network failure scenarios.)

OSPF broadcast network type recommended in these scenarios; uses designated router (DR) to reduce flooding. DR and backup DR require careful selection to ensure router CPU and memory are sufficient.

In general, nonproprietary protocols should be used where possible to avoid vendor lock-in. Additionally, publicly available documentation lends itself to an increased understanding of the workings of a particular protocol, and also the concepts behind the protocol can be more widely tested by a wider audience. More specifically, this allows potential problems to be identified and resolved and creates cooperation with vendors to further develop protocols. 5.5.9

Security

The security support available in the protocols is summarized in Table 5.6. Security of the routing protocol is essential to protect from malicious abusers, both internal and external to the network, and also from faulty equipment that may flood a network with incorrect routing information. Network administrators typically concentrate on the protection of the router itself. However, if incorrect routing protocol information is received by the router, legitimate users might be denied service. It is clear that routers and their protocols should be authenticated and the overall

134

Mobile IP Technology for M-Business Table 5.6 Security Features Supported in IP Routing Protocols

Routing Protocol

Security Support

RIP version 1

None specified in RFC. Security features are vendor dependent.

RIP version 2

Plain text password specified in RFC.

IGRP

None specified.

EIGRP

None specified.

OSPF

RFC 2328 specifies that all OSPF exchanges are authenticated using either weak security (plain text password) or strong security (using cryptographic exchanges).

IS-IS

Plain text password specified in standard. Passwords specified for hello packets and sequence number packets. Multiple transmit and receive passwords specified, however, Cisco supports only single transmit and receive passwords.

security of a network should be continually maintained using an overall security policy. Where possible, the strongest form of authentication between routers should be used (i.e., using cryptographic techniques).

5.6

Summary

A large number of routing protocols have been developed for use in both the Internet and in other private IP-based networks. These protocols can be split into three broad categories: distance vector, path vector, or link state. Each of these has many operational characteristics associated with it. This chapter has explained how the main routing protocols work and given guidelines on how they perform. Some of the key criteria for evaluating their performance used in this chapter are convergence time, processor, bandwidth, and memory overhead. For any sort of IP network to be effective, the characteristics of the routing protocol need to suit the type of network and the services it supports. It is one thing to guarantee a connection to a roaming user, quite another to ensure that the connection results in a reliable end-to-end service. This chapter, along with the previous one, lays out the necessary detail to build a core IP network to support mobile services.

Routing

135

Selected bibliography Comer, D., Internetworking with TCP/IP, Volume 1: Principles, Protocols and Architecture, 3rd ed., Upper Saddle River, NJ: Prentice Hall, 1995. Halabi, B., Internet Routing Architectures, New York: Cisco Press, 1997. Norris, M., & S. Pretty, Designing the Total Area Network, New York: John Wiley & Sons, 1999. Perlman, R., Interconnections, Bridges and Routers, Reading, MA: Addison-Wesley, 1992. Standards: The standards contained in the RFC (Request for Information) series can be located via the IETF home page (http://www.ietf.org).

CHAPTER

6 Contents

M-business

6.1 The spectrum of m-business 6.2 The back-end components of m-business 6.3 Design requirements 6.4

Security

6.5

Summary

There is nothing remarkable about it. All one has to do is to hit the right keys at the right time and the instrument plays itself. —J. S. Bach

T

he advent of lightweight but powerful handheld computers, the spread of wireless networks, and the popularity of the Internet have combined to make mobile computing the hot topic in the communications industry. In particular, the prospect of having access to on-line services wherever you are and wherever you are going is something that excites just about everyone. Just as e-business flourished as browsing capability was added to the Internet, so m-business is set to grow now that the technology to make it a viable reality is becoming available. Predictions of the likely scale of mbusiness vary but no one is guessing that it will be small. It is widely anticipated that browser-enabled mobile phone ownership will rise sharply, from around 1 million in 2001 to nearly 80 million by 2003. During 137

138

Mobile IP Technology for M-Business

the same period the number of Internet-capable handheld computers is expected to increase from less than 5 million to at least 15 million. The effect of all this is that the level of interest in, and hence potential revenue from, mobile services across Europe will grow from $484.5 million now to $34.5 billion by 2003. Signs of the emerging mass market for m-business services are already evident. In Japan, more than 200 companies are providing data services on DoCoMo’s i-Mode service. In addition to e-mail, these services include multiplayer games, on-line banking, and the remote booking of tickets. J-Phone, a competing mobile phone operator based in Tokyo, estimates that nearly 90% of its subscribers use the data and e-mail services on offer. Evidence of latent demand is not confined to Japan. In 2000, more than 2 billion messages in short message service (SMS) format were sent between mobile phones across Europe. Is this a sign of things to come? The relatively slow uptake of Wireless Access Protocol (WAP) based service across Europe might suggest a false dawn for mobile data. However, a quick glance back through the history of computing technology tells us that people always overestimate what will happen in the next two years but underestimate what will change in the next 10. The initial expectations of a mobile data boom have passed—the time for the promise to be realized lies in the next few years. In this chapter we look at the services that the technology presented in earlier chapters enables. The components that turn a mobile data capability into m-business services are examined, and some of the key aspects of running an on-line business for mobile users—security, resilience and efficiency—are addressed. In each case, a set of design and implementation guidelines is given. Before anything else, though, we should define what we mean by m-business. The first section aims to do just that by defining its scope.

6.1

The spectrum of m-business

So what exactly do we mean by m-business? Perhaps the best route to a definition is to give some examples of what it enables a user to do. A first attempt would be to say that m-business is a subset of e-business. After all, people who transact on-line will, on occasion, want to move around and, when they do, will want continuous connection to their on-line services.

M-business

139

TE

AM FL Y

This definition is a little restrictive in that it assumes that e-business services cater for every eventuality. Sure enough, there are some activities—such as stock control and goods ordering—that do not really make much sense when you move them out of the fixed domain. On the other hand, in many instances, being on-line and mobile allows you to do things that were previously just not possible. The ability to be able to work while both remote and roaming has been the holy grail of many IT departments for years. Comprehensive mobile information services make work an activity, not a place. Another instance of an m-business service that offers new freedom is when you need remote guidance and alerts. Sometimes, you have to know what is going on in other places and, short of cloning yourself, the only way to do this is to be on-line and in touch. A specific case of this would be when you need access to services dictated by your location. For instance, if you were to find yourself stuck in the outer reaches of Kamchatka at three o’clock in the morning, it would be helpful if your corporate emergency travel service credited some rubles, rather than dollars, to the smart card connected to your mobile device. In a nutshell, m-business is all about being continuously in touch with information, which is generally seen as a good thing because you do not have the frustration of being isolated from the data you need. Of course, m-business does carry the consequence that there is no hiding place—work can continue as long as the technology keeps working—but this is something that most mobile phone users are quite familiar with by now. One other consequence of being permanently wired is that the loss of a connection can be significant if too much reliance is placed on it. Personal applications, such as wireless heart monitoring, which may have life-and-death consequences, seem to define the m-business limit. To close this section, let’s take a look at what a full range of m-business services might mean both to the business user, who would have her corporate information services permanently on tap, and the individual, who would likely benefit from a raft of innovative new market offerings. 6.1.1

Business travel

Jo has a company issue communicator that connects to the company intranet. On arriving in New York on a Thursday morning from the United Kingdom, Jo checks the schedule on her communicator, which has now been automatically updated since turning it back on after leaving the aircraft. There is a new appointment in Los Angeles for the

140

Mobile IP Technology for M-Business

following day as well as a number of new e-mails. While scanning these new messages, Jo sees that several have large attachments, so she downloads these over coffee in the airport departure lounge. In the taxi on the way to her meeting, Jo uses the time to search the Internet for flights that evening to Los Angeles, and subsequently books a seat on an early evening flight. The seat is confirmed and an e-ticket transmitted to the electronic purse smart card currently inserted into the communicator. Next, Jo searches the net for hotels in Los Angeles and books a room on-line. Later at the airport, after checking in with the e-ticket, Jo has a little free time in the lounge. This is a convenient break for checking the bank balance back in the United Kingdom and transferring some cash from it to the electronic purse in her smart card. That done, there’s time for a bit of duty-free shopping, all debited directly from the e-cash card, using the current Euro-sterling exchange rate. The card is also useful to obtain a small snack from a vending machine, eliminating the requirement for coins in the local currency. Once checked into the Los Angeles hotel, Jo sets up her laptop PC and attends to still more e-mails. One message from a colleague has a report attached, with a request for Jo to review it. Although her colleague has forgotten to compress the 50-page report, this file is downloaded within only a few seconds and Jo starts the review straight away. Once finished, the modified report is sent back to its author, and Jo accesses the company server to download a couple of documents needed for the meeting tomorrow. Properly prepared, it is time to relax and enjoy the Los Angeles nightlife. 6.1.2

Commercial on-line services

Sam is just getting used to a favorite birthday present—a new pay-asyou-go mobile. Following a call from a friend, Sam is reminded about a promise to meet for lunch in London, so he uses his phone’s browser to access the railway timetable, and downloads an e-ticket for the next train to Liverpool Street. On arrival at the station, Sam inserts his smart card into the machine on the platform, and the ticket is printed. It is some time before his train is due, so Sam goes to a nearby soft drink machine and buys a soda using the phone to pay for the can. In addition to handling the transaction, the GSM chip in the vending machine can also alert the owner when the stock needs replacing or the cash box needs emptying (some people still use coins).

M-business

141

After meeting with the friend and ordering lunch, Sam’s friend mentions that he saw a house advertised in the area Sam is interested in moving to. A few seconds later, the phone is connected to the Web site of a national estate agent, and the details of the property in question are displayed on the phone’s screen. It looks interesting and is in a good location. Given that it might not be there later, Sam decides to get more details by pressing the Connect to Agent button and uses the phone to arrange an appointment for the next day. Finally, after finishing their lunch, Sam uses a short-range data link (Bluetooth—see Appendix B) to transmit data from the smart card in his phone to the portable reader that the waiter brings to the table. The display already indicates the total from the lunch, to which a tip can be added and the total is immediately debited from the cash balance on the card. Given these, and other, possibilities, it may not be that long before m-business is the dominant form of on-line trading. After all, in the world of voice telephony, mobile radio-based telephone systems have rapidly supplemented landline telecommunications, even if the latter did dominate for more than 100 years. It is far from inconceivable that primary access to on-line data and information will be through a mobile device. Furthermore, many predict that most Internet access in the second half of the 2000s will be with handheld wireless terminals. Given their small size, reliability, simplicity, and low cost (relative to PCs), these are likely to be the chief methods of access for most new entrants.

6.2

The back-end components of m-business

Many of the ideas and concepts that have been established for e-business are also needed for m-business. In fact, it would not be unusual to find the self-same servers looking after both. In this section we take a short tour around the behind-the-scenes kit that supports on-line trading, whatever the chosen form of access to that kit. 6.2.1

Catalogs

The fundamental prerequisite for presenting products and services on-line in the e-business world is the catalog. These are central and are the electronic equivalent of a shop’s shelves, goods, special offers, and departments. The catalog is the on-line representation of what is “for sale” (or, more correctly, what is available for trading).

142

Mobile IP Technology for M-Business

It is important to appreciate that there are different scales of catalogs. They range from a set of Web pages and a simple script that allows orders to be taken, through midrange catalog products that are characterized by a predefined structure of product categories and subcategories, up to large-scale corporate catalogs that can be customized. In this last case, back-end integration with inventory, stock control, and ordering systems is used. Another important point about catalogs is that they are different for buyers and for sellers. The former is a virtual directory that allows the buyer to look at and judge a range of competing products from a number of different suppliers. The latter is a structured set of information that represents what a particular supplier has to sell. The technology used to represent these different types of catalog has to match—that is, it either has to be optimized for one seller and multiple buyers or vice versa. One further differentiation in catalogs that should be made is that of business-to-business as opposed to business-to-consumer catalogs. The consumer-oriented catalogs tend to be stronger on presentation because they usually have to sell their wares on the basis of eye-appeal. The business catalogs are focused more on quick access to another business’s needs, and these tend to be high volume and fairly routine. For instance, many supermarkets issue stock replenishment orders from their automated stock control systems—they buy a lot of cans of beans on a regular basis! 6.2.2

Payment systems

M-business needs to emulate in some way the customary direct exchange of cash for goods. Attitudes to the use of different payment mechanisms are changing (and vary when considering Europe, the United States, Asia-Pacific, or the entire world). A priority in establishing an m-business service is to put in place an acceptable mechanism for paying for goods or services. Many technical options are available and to choose appropriately, factors such as scale (cents, dollars) and acceptability (secure, auditable) need to be carefully examined. By way of illustration, various scales of payments can be considered: Items such as books and videos are regularly purchased electronically. It is common for a single customer to buy a single video and pay with a single credit card transaction (probably in the $10 to $50 range). However, the cost of processing credit card transactions is quite high and may not be economical for the purchase of small-value items such as an on-line newspaper, which would typically be around $1. Technologies exist that

M-business

143

handle these small-value payments (known as micropayments) and aggregate them into single credit card transactions. The range below $1 is often referred to as the area of nanopayments. Such payments may represent, for example, the price of viewing an individual Internet page of information (e.g., a particular share price). Not only are different technologies required to aggregate these various categories of small-scale payments, but also the m-business provider will need to put in place different strategies for such things as handling account queries and dealing with bad debts. For instance, a sensible way of dealing with lost nanopayments would be to write off the debts and blacklist the offenders because the cost of recovering the debt would be too high. 6.2.3

Settlement

It is all very well to take a “virtual” payment for goods or services offered over the Internet but, at some point, this must be converted into beads, dollar bills, Euros, or some other tangible form of money. Hence, we need a gateway between the virtual world and the real world—a payments gateway. This can be effected with automated connection to merchant acquirers (e.g., Barclays Merchant Services), established clearing systems such as BACS and direct debits, or other systems, such as PC-EFT, WorldPay, and Clear Commerce. These last three all provide a suite of programs that can easily be integrated with the merchant’s software to allow the processing of payments by Visa, MasterCard, Diners Club, and so forth. Of course, traditional settlements are not mandatory—people have used all kinds of different objects to represent money. In the electronic world, additional payment possibilities include token-based systems in which you first buy a number of tokens, in your chosen currency, and are then free to spend them on goods that are priced in tokens. Electronic wallets and smart cards such as Mondex provide a particularly attractive alternative for the mobile user, because they can receive credit irrespective of location. Some of these types of electronic cash are fully portable, whereas others store your “wallet” on your PC or on a server. 6.2.4

Presentation

As with catalogs, the way in which on-line products and services are presented depends on the market. A particular constraint in the mobile market is that the user device is often quite small (if it wasn’t, it wouldn’t be portable) and so there is a restricted viewing area for information. The extreme example of this is the presentation of information on

144

Mobile IP Technology for M-Business

WAP phones. To cut down the amount of information presented to these phones, an alternative protocol operates on a microbrowser on the mobile device. Instead of running the established HTTP/TCP/IP stack for sending Web information, WAP has its own, lightweight alternatives that are tolerant of bandwidth restrictions and end-to-end delay. A WAP service requires a gateway to convert between the standard protocols and those used on the user side. Although currently growing in popularity, we do not deal with WAP here. The design of on-line information is very much in its infancy, but some basic guidelines should be followed to get the right presence and operation for the job in hand (and one of the best ways to see what you should do right is to look at other people’s mistakes). Navigational dead-ends, inconsistent and out-of-date information, lack of an overall information map, frustrating and nonintuitive structures, and poor search/browse capabilities all put customers off. One of the interesting twists to offering on-line service is that it is possible to find out where a customer tends to call in from, what they look at, what they purchase and when. This would consume a huge amount of time and video to do in a conventional chain of shops, but consists of little more than system logs for an m-business service. Information about individual customers and their travel, browsing, and buying patterns provides important feedback as you decide how to present your goods to your customers. To complete this section, we should mention security. The importance of ensuring that the users of mobile services can connect safely is paramount (and is cited as the major issue in the uptake of on-line services). Hence, we deal with this topic in some detail later in the chapter.

6.3

Design requirements

There are many ways in which technology can be configured to support m-business. Some options are better than others, and it is the role of the designer to ensure that the layout of the network and the way in which the applications are set up are suitable. This section sets out some guidelines for the design of an effective network to support mobile service. In general, the effectiveness of any design (or its “quality” or “fitness for purpose”) can be measured against the following criteria:

M-business

145

◗

User needs. The ultimate purpose of an enterprise network is to provide those who use it with a means of doing their job faster, better, and more easily. So the final test of suitability for the purpose is the extent to which the network supports the applications that run on it. The remainder of the points here are, to a greater or lesser degree, aspects of user needs.

◗

Cost. Not just the cost of purchasing and installing the new network, but also the cost of keeping it. As a rule of thumb, the cost of ownership of a software-rich system (and enterprise networks increasingly fall into this category) is twice its initial cost. So the cost of the design—its whole life cost—is an important consideration for the designer to bear in mind.

◗

Performance. As with cost, this quality attribute also has two sides. First, the design of the network must allow transactions to be executed quickly enough to satisfy the user. This entails careful end-toend checks for the range of applications being supported. The second performance issue is throughput—not only must the network be fast enough, it must also cope with the peak traffic volumes.

◗

Reliability. This is another end-to-end issue for the designer to consider. The perceived reliability of any network relies on all the elements that contribute to a user’s session working at the same time. So, it may be that if one or more network elements can go down without affecting the user, that would be evidence of a well-designed network. A poorly designed network may keel over every time one particular element goes wrong. There is, of course, a trade-off between the level of reliability and cost.

◗

Availability. Some level of maintenance and administration is inevitable with any network. The extent to which this intrudes on the user is a measure of fitness for the purpose. Again, this is a feature that costs money (because it usually depends on having field staff ready to fix problems), so an equitable balance needs to be struck.

◗

Expandability. Today’s new system is tomorrow’s legacy (and usually, the day after’s problem). Design for change is an increasingly important factor with an organization’s continually changing structure, procedures, and working practices. A good design should be built to accommodate the incorporation of new services, dynamic capacity

146

Mobile IP Technology for M-Business

management, easy administration (users and their preferences are in constant flux), and some means of integrating data from a range of sources. ◗

Manageability. It should be possible to keep as expensive and dynamic an asset as an operational network in good shape. And this means that it must be designed so that it can be managed. Hence, each element of the network must be open to some standard form of interrogation from a network management system. The whole area of network and service management is a complex one that covers the fulfillment and assurance of network operation as well as the collection of chargeable events and the subsequent issuing of bills.

The trouble with these benchmarks is that they are easy enough to state but most are difficult to satisfy and all rather difficult to quantify. Also, they are mostly retrospective as the real limits and thresholds only appear once the network is installed and is finally being used. Nonetheless, some things can be anticipated before they become a problem. The rest of this section is a checklist of what should be attended to during the design phase. 6.3.1

Ensuring network performance

There is a basic need to design in enough resilience, speed, and availability to support mobile data services. This is something that should be considered during the early, architectural design phase, when the designer should have decided and documented the following: ◗

The number and definition of site types to be used in the design;

◗

The technology and topology of any local-area network (LAN) systems to be used;

◗

The topology and technology of the wide-area network (WAN) system;

◗

The choice of gateway technology between WAN and LAN; and

◗

How legacy systems will be handled by the gateway device.

There is a strong possibility that multiple design alternatives will come to light at this stage. To help choose the best, the designer should develop a

M-business

147

series of “thumbnail” designs using each of the contending solutions. The designs can then be compared using aspects such as: ◗

Cost (outline costing can be done based on any known network supplier’s tariffs for their WAN services, and list prices for LAN, router, and gateway components);

◗

Performance;

◗

Likely reliability;

◗

Technical risk. (Is it proven technology or state of the art, and, more to the point, which does it need to be? Risk should only be taken with the latest technology if the proven solutions cannot do the job.)

By this stage in the design process, we should have a fully costed design ready to present. We have reached this stage by performing these tasks for each generic site type in the network: ◗

Select solution required at that site type.

◗

Determine the WAN connectivity required (link capacity, availability, backup arrangements).

◗

Determine the additional resilience networking requirements.

◗

Plan the placement of servers at the site.

◗

Select the gateway device (e.g., a router) needed to connect the LAN and WAN components.

To be confident that the proposed network will work as a whole and support the user’s applications, we also must: ◗

Carry out sufficient logical design work to understand how the network will operate.

◗

Have thought through how the network will be managed, so that any additional management components can be costed.

◗

Carry out verification to confirm that the design will meet the end user requirements.

148

Mobile IP Technology for M-Business

A number of issues always come up in the early stages of design. It is worth stating them here, simply as a guide to inform any choices that need to be made at this stage: ◗

It is said that all useful networks fill to capacity, thus networks cannot be designed; they just evolve. Special care should be paid to the need for growth. Ensure that a way forward exists to increase connectivity and capacity of all network components.

◗

Good quantitative performance information can be difficult to obtain from suppliers. For example, because routers are so complex, they may simply never have measured the performance in the configuration you plan to use. Where figures are provided, the exact test conditions may not be revealed and, of course, any figures quoted may be selected to show the product in a good light. Independent test houses often publish comparative test reports that can be of value (e.g., Kevin Tolly in Data Communications). At the end of the day, however, you may have to carry out some of these measurements yourself.

◗

Design is a compromise and optimization process in which you trade off cost, quality, and functionality. The typical user wants a cheap network that is 100% available, is fast, and covers all current and future application needs. A certain amount of expectation management is called for on the part of the designer and this should be catered for as soon as possible.

◗

Beware of “cloud mindedness.” It is all too easy to fall into the trap of portraying the WAN as a nice friendly fluffy cloud. This can be a useful abstraction at times, but sooner or later, you need to think through the impact of the design on the cloud and of the cloud on the design. For example, if the proposed network is large, will the network provided have to expand the network (in terms of the number of ports and bandwidth between nodes) to cope? If so, how long will this take? Is the underlying network technology suitably scalable?

◗

What really happens when a network node or trunk link fails? How long does it take to reestablish connections via an alternate path and how good will the alternate path be? It may be congested or might be much longer, adding significant delay.

M-business

149

6.3.2

AM FL Y

Attention to these issues should result in a viable and practical design. This means that the end-to-end operation can be explained, recovery in the event of component failure can be dealt with, the effect of degradation due to link problems is known, and the possible reconfiguration options are known. However good a design, issues will always arise when a service is launched. Sometimes these may appear to “break” the design, but, as often as not, they can be solved through reconfiguration rather than a rebuild. For instance, if demand on the network increases, you do not necessarily have to add new equipment. It is often worth seeing what can be done with what exists—the concept of network tuning. Through the use of this and other techniques, it is often possible to squeeze enough extra bandwidth out of an already busy network to avoid major work. Table 6.1 lists some of the causes of network inefficiency and describes what can be done about them. Maintaining the network

It would be nice if our well-designed network, once installed, just kept on working. But this is never the case; even in stable operation, a network management system must meet plenty of needs. The potential problems that network management design should cater for include these: Chain reaction failures. These are failures in which you need to know how a failure in one part of the network might affect the total operation. For instance, there could be a bug in the database software that keeps track of network addresses. It could block access to critical services like backup systems, but at the same time it could hide this problem from the monitoring system. You need crosschecks and consistency checks to detect this kind of problem.

◗

Traffic congestion. Just like a well-designed highway, any network can suffer from traffic jams. If several network elements fail simultaneously, the load of blocked and diverted traffic can bring the system to a halt. Adding to the congestion are the messages the network generates to report the problems.

◗

The unexpected. A network hit by unexpected events must be able to help itself. It should manage and reroute traffic to avoid trouble spots. The system must also react properly to duplicate messages or verify messages from questionable sources.

TE

◗

150

Mobile IP Technology for M-Business Table 6.1 Network Inefficiencies and Their Solutions

Cause

Action

Issues

User data

Where possible, developers should work to minimize the number and size of messages that must be sent across the network.

If using routers to perform compression, this will place a significant processing load on the router. Care should be taken that this does not impact on data throughput.

Data compression should be considered. This is best done in end systems (e.g., files may be compressed before transmission), but this may be done in routers or dedicated compression hardware.

It is all too easy for departments to introduce new applications, protocols, and LAN components without the network administrator being aware of it. This can have an unforeseen impact on the operation and performance of the network.

User guidance and discipline. An example would be the issue of large file attachments on e-mails. If the mail is to be sent to many people, it will be more efficient to store the attachment on a common file server and pass a file pointer Regular network audit (using LAN analyzers) is in the e-mail. recommended, together with an efficient mechanism for handling user change requests. Protocol headers

This can be a large source of overhead. Where possible, tune the network to send user data in as large a packet as possible. This reduces the percentage overhead of headers. Routers may be capable of performing header compression in many cases (much of a header does not change within the context of a session, or changes in a predictable way).

Making packets large can adversely affect performance of transaction-oriented traffic and is best for file transfer traffic. Again, we need to check that the increased level of router processing is not an issue.

Unwanted traffic

Careful use of traffic filtering using access — lists can reduce load on networks.

Broadcasts

“Broadcast storms” can cripple networks. These occur when many sites have a need to broadcast data simultaneously (e.g., in a source route bridged network, all workstations may explore for the host at the start of the working day). Routers are much more effective at suppressing broadcasts than bridges. Special features (such as “proxy explorer,” in which a bridge can cache paths to hosts and respond to workstation explorers) can help.

—

M-business

151 Table 6.1 (continued)

Cause

Action

Routing updates

The impact of distance vector protocols such as RIP can be reduced by reducing the update frequency.

SAP broadcasts

This is an issue for Novell networks. Servers on these networks advertise their presence every 60 sec, and this information is broadcast around the network. Routers should filter this information so that information about locally significant servers (e.g., print servers) is not broadcast.

Issues

Increasing the update interval adversely impacts network convergence time following Use of a link state protocol such as OSPF faults. These protocols need careful is more bandwidth friendly. design to avoid “broadcast storm” problems following network faults as routers reconverge.

Management The frequency with which routers are traffic polled and the level of data collected must be carefully managed. It is easy to design a network that grinds to a halt every 15 minutes as the management system tries to read the complete MIB on every router in a network!

—

A clear trade-off exists between responsiveness to network problems and the frequency of polling. The ability to forecast future growth requirements may be impaired if too little data is collected too infrequently.

◗

Centralized and decentralized management. Central management can also create a central point of failure. Decentralized management can be a source of inconsistency. In an enterprise network, you are likely to have elements of both, with their combined drawbacks. You must decide who should be responsible for managing such things as database consistency, standby systems, and database updates. Another decision is one of who should receive status information and error messages.

◗

Protocol standards. The choice of a network management standard— or none at all—can either improve management or make it harder. If you base the system on a standard, such as the Simple Network Management Protocol (SNMP), you must be sure the entire system follows it. Otherwise, it might interpret nonstandard messages in strange ways. You must also make sure you can support the

152

Mobile IP Technology for M-Business

standards you want to maintain. On the other hand, standards make it easier to integrate network management with the network as a whole. ◗

Growth potential. The management system should adapt to traffic growth, the addition of new nodes and networks, and the management of user information (e.g., their addresses, permissions, etc). It should also incorporate new technology and accept new features as opportunities arise. This should be done relatively easily and with little disruption.

We now move on to look at the architectures of typical management platforms used to tackle these problems. A basic management platform

Figure 6.1 shows a fairly minimal network management system. It consists of a UNIX workstation, connected via a router and core network connection to the target network sites that are to be managed. The operator would be able to view the status of the network elements through the element manager and might also have other, more summarized

Element manager

Configuration activation

Fault performance

Operator’s workstation

Other management tools (root cause, trend, analysis)

LAN

Firewall router

Network

Managed element

Figure 6.1

Managed element

A basic network management system.

M-business

153

information from supplementary tools that show, for instance, the root cause of network problems or trends in network performance. The element manager will typically be a UNIX platform running SNMP management software (e.g., Sun Net Manager or HP Openview). SNMP itself is a standard, ubiquitous, and straightforward request/ response protocol that allows for the retrieval of information from the various agents (a type of monitoring device) on the network through its “get” and “get-next” commands. It also permits network devices to deliver traps (also known as alarms) and have them delivered into the management system (using the “put” command). The task of the SNMP management software is to provide a network manager with a graphical view of the network, highlighting nodes with problems. The user will be able to use the graphical user interface to home in on such nodes to perform further diagnoses (often through using TCP/IP telnet to log on to the router, which will offer a much richer set of management and diagnostic facilities than can SNMP alone). The management system is also able to gather statistics and prepare reports to assist in long-term health checking and capacity planning for the network. The element manager is connected to the rest of the network via a LAN and a router. The router will perform a security firewall function to protect the management system from misuse. For large networks, a separate overlay network (usually known as a DCN0) would be installed, and the management equipment, along with the operational staff, would be housed in a network operations center (NOC). The NOC would typically be collocated with a customer care center so that network and customer issues can be coordinated. In addition to monitoring the network for faults, the NOC would monitor performance, configure and activate network elements, and set up access lists, users privileges, and so on, as indicated in Figure 6.1. Multiple users can be accommodated in the NOC by adding extra machines, which can have sessions with the network management workstation using the X-windows protocol, or simply a number of windows on a PC running an emulation program such as eXceed. How does the management system know the state of network nodes? There are two key methods, the first reactive, the second proactive: 1. Alarm or trap processing. Network components tend to produce a rich set of event notification messages (examples would be failure

154

Mobile IP Technology for M-Business

of a token ring attached to a router, or if a router is running short on memory). These messages are sent using the SNMP protocol and logged by the management system. The trick when dealing with such messages is being able to tell the forest from the trees! The management systems will require alarm filter capability so that only the most serious events are brought to the attention of the operator. Where possible, information type alarms should be suppressed at their point of origin; to avoid unnecessary traffic, most network components will have the ability to configure just how talkative they are about their status. 2. Polling. Alarms are not in themselves sufficient. Clearly, if a network component or its communications path to the management system has failed, no alarms will be seen. This problem is overcome by the management system periodically polling the network component. This can be done using a PING (a process whereby a test packet is reflected by the node under test using the TCP). Alternatively, we can use SNMP to get one or more variables from the nodes management information base (MIB). This is the repository of information on network devices. It contains a description of SNMPcompliant objects on the network and the kind of management information they provide. These objects can be hardware, software, or logical associations, such as a connection or virtual circuit. An object’s attributes might include such things as the number of packets sent, routing table entries, and protocol-specific variables for IP routing. Given their scope, MIBs can be rather large! Clearly, a design trade-off must be made here: If you poll too often, then excessive network bandwidth is consumed. Polling too infrequently means that it takes too long to react to faults. Polling network components every 5 minutes is often a sensible compromise. Network statistics are also gathered by polling. In this case, we need to make a whole series of SNMP “get” commands to fetch the relevant data. A typical MIB will contain many kilobytes of “useful” data. It is all too easy to consume excessive bandwidth and network management system disk space by collecting too much information too often. Collecting statistics every 15 minutes usually provides adequate resolution. Care should be taken to request only the minimum necessary information. This might include:

M-business

155

◗

Router peak processor utilization: To help predict when and where more powerful routers might be needed.

◗

Router free memory: To identify where more memory might be needed.

◗

Network access link utilization: To identify sites needing more capacity, or where we need to investigate how the load can be reduced through tuning.

◗

Packet drop rate: Routers are generally dealing with connectionless IP-type protocols, and they cope with port congestion by simply discarding or dropping any overload. The drop rate is a good warning that undesirable levels of congestion are being reached.

◗

Errored packet rate: Network access links will generally be running protocols based on HDLC framing. These frames include a frame check sequence, which routers use to detect and discard faulty packets. High rates of dropped or discarded frames will indicate links that need maintenance attention. Note that high rates of line errors may also raise alarms.

The gathering of information from the network is but one part of the overall management story. Ideally, you want to be able to correlate what is happening to packets and routers with the services and customers that rely on them. The overall map of how operational support systems (OSS) link the network to its users is shown in Figure 6.2. This figure shows all of the activities included in operating a network-based service. In addition to the three horizontal categories (customer, service, and network processes), there are also three vertical themes. Moving from left to right across the map, these are fulfillment, assurance, and billing. The full text of the TOM breaks each one of the boxes in the figure down into enough detail to build day-to-day operating processes. In terms of automation, many vendors supply OSS elements and several of these vendors have formed alliances so that they can address the whole management space. For instance, Micromuse offers probes that gather information from network elements and tools to correlate this with the services offered. They work with Orchestream, which deals with provisioning and remote configuration, and Belle, which provides billing systems. Equipment vendors Cisco and Sun and integrator Cap Gemini

156

Mobile IP Technology for M-Business

Order handling

Sales

Problem handling

Customer quality of service management

Invoicing/ collections

Customer care processes

Service planning/ development

Service configuration

Service problem resolution

Service quality management

Rating and discounting

Service development and operations processes

Network planning/ development

Network provisioning

Network inventory management

Network maintenance and restoration

Network data management

Network and systems management processes Element management, technology related Physical network and information technology

Figure 6.2

The telecommunications operations map (TOM).

complete the alliance. Just as in the rest of the telecommunications marketplace, many alliances exist and they change on a regular basis.

6.4

Security

All on-line services involve the transfer of information between a provider and a consumer. If this information is not protected from attacks by a third party, then the service will soon be abandoned, especially when the information being transferred is a bank credit or a confidential document. Security is often cited as the main reason why people choose not to do business over a network. But the single word security covers a raft of issues: 1. The authentication of information, provider, and consumer; 2. The protection of information in transit; and 3. Defense against eavesdropping.

M-business

157

And this list names but a few. In this section we consider the nature of the threat and then go on to explain some of the measures that are available to counter it. 6.4.1

Understanding the threat

Any sort of data network is a potential target for attack by a malicious, or simply curious, hacker. And as more and more business is conducted over networks, these attacks will be increasingly motivated by criminal intent. This could be as simple as someone stealing private data and selling it (e.g., to competitors) or it could be a direct attack on bank records. Before we can start to design security into a network-based service, we must understand the nature and level of threats to which it is exposed and the modes of attack that might be used. Once this is clear, we can look at what sort of security needs be built in to protect against attacks. One point that should be made at the outset is that security can never be perfect. There will always be some possibility of services being compromised. The aim is to find the right balance of resources used (e.g., time and processing power) against the level of protection provided. This balance will vary according to the service on offer—some network designs may have to undergo a security audit against a formal standard, such as BS7799 or a risk assessment method such as CRAMM; others may simply require informal testing. Of course, the network designer should really be keeping network security in mind all through the design process, so that the design will pass the audit process with little or no modification. To help with this, the designer should ask the following questions. Who will attack my network and why?

The why is fairly straightforward. It is usually greed—people aiming to steal money or fraudulently acquire goods. Of course, there are other motives. Disgruntled former employees may seek retribution against an employer or someone may simply enjoy the challenge of beating the system. The latter types of attackers tend to confine themselves to those targets that will get the most publicity. An attack could come from a competitor or unhappy customer who might simply want to shut the company’s system down. Outside attack is also possible from criminals intending to commit a crime against the company. This would generally lead to financial gain by attacking applications, stealing data or programs, or perhaps blackmailing a company (company reputations can be badly damaged if customers find out their systems are vulnerable to hacking).

158

Mobile IP Technology for M-Business

Last, but by no means least, the attack could be indirect; for example, the company could receive a computer virus in an e-mail. This virus may have passed through many systems before reaching the company. What will be attacked?

The easy answer is that any element of the service is a potential candidate for attack. Some of the network components are particular targets—routers, LAN hubs, switches, terminal servers, and remote access (dial-up) servers. In addition, Web servers and the scripts and applications (e.g., CGI and Java) that reside on them are vulnerable. And, of course, the information that resides on any of these devices could be valuable (or sorely missed if corrupted). What type of attack can I expect?

Different attackers will have different aims, so an attack can take a variety of forms. These are the main ones: ◗

Direct attack. An attacker aims to log on to an application and use it as though he were a legitimate user, but for covert purposes. The attack might involve stealing or guessing passwords, using operating system or application “backdoors.” Unsuspecting users may download and run software containing a Trojan Horse, which introduces such a backdoor, or subverting user authentication procedures.

◗

Denial of service. This type of attack prevents the network or application (e.g., a Web server) from operating correctly. There are plenty of options in this form of attack. They can choose from a variety of tools that restrict bandwidth, lock up TCP/IP sockets, use up CPU power, and so forth. There are many ways to deny service by disabling the resources required to deliver it. An example of a denial of service attack that many will be familiar with is the bogus e-mail with an attachment that, when opened, infects the user’s machine.

◗

Loss of privacy. Data can be tapped in transit and then used to damage the company’s reputation or for criminal purposes. LAN sniffers and WAN datascopes are readily available and can be used for such illicit purposes.

◗

Data modification. Data in transit can be modified (e.g., a purchase of $1,500 could be made, but the attacker could modify the data to show that only $15 had been spent).

M-business

159

◗

Masquerade. The attacker simply pretends to be the legitimate host. This could be done by setting up a Web site with a similar name or by diverting traffic from the legitimate site to the bogus one. The main reasons for masquerade are to trick remote workers into sending information or revealing passwords. Alternatively, a masquerade may just be for fun—a spoof White House site carried out a lot of policies not endorsed by the Clinton administration.

◗

Information gathering. This is often the prelude to one of the above attacks. Basic TCP/IP tools like PING can be used to see which applications are accessible over a network. More sophisticated scanning tools can systematically search a host for security vulnerabilities.

TE

AM FL Y

Many of the tools that can be used for these forms of attack can be freely downloaded from the Internet. Also, with the reach and availability of the Internet, attack can come from any corner of the globe. Given the ease with which an attacker can equip him- or herself and the potential number of sources of attack, it is safe to assume that all of the above threats are likely and need to be actively guarded against. Finally, a few maxims should be kept in mind when considering what sort of attack is likely. The first of these is to assume that the enemy knows your systems. The fine details of many commercial encryption and security systems have been published. Many will have studied these for weak spots (and will have shared their findings with their partners in crime). A second maxim is that the potential level of attack should not be underestimated—hackers have time on their hands and, with the help of powerful computers, can launch many thousands of assaults a minute. Fortunately, techniques do exist to counter the threats, as we discuss next. 6.4.2

Guarding against attack

Security is all about safeguarding the operation and preserving integrity in the face of accidental damage or deliberate attack. The many aspects of security include privacy (the ability to keep secrets) and integrity and the “three A’s” of (1) authentication (knowing who people are), (2) authority (allowing them to do only what they should), and (3) audit (the forensic trace, so that you can find out what happened, who did it, and when). Given this breadth of scope, the sheer range of threats listed above, and the tendency to leave security out of computer science curricula, the

160

Mobile IP Technology for M-Business

protection of network services from attack is a specialist field. Hence designers of any m-business service will typically need to seek advice from experts in the field, but there is a base level of awareness that they should have and a lot of measures that they can take themselves. The full range of defense approaches can easily be remembered with a slight extension of the 3A’s into the initials CIAAA: 1. Confidentiality. Ensuring that data is protected from loss of privacy through the use of encryption. 2. Integrity. Protecting against data modification by adding secure electronic signatures to messages. 3. Authentication. Protecting against direct attacks by making sure that the user connecting to the system is who he purports to be. In a similar vein, protecting against a masquerade by testing that the host system being attached to is genuine. 4. Availability. Using resilient server designs that have been hardened against denial of service attacks. Simple techniques such as regular data backup are also important to allow speedy recovery in the aftermath of a successful attack. 5. Audit. Keeping records of who connects to a host and what they do. This allows any attack to be analyzed, hence minimizing the chance of its reoccurrence. A lot can be done to minimize threats to the network services, simply by avoiding them. For instance, if a large amount of sensitive data needs to be processed, it would be better to move the processing to the same place as the data rather than the other way round. Sometimes, though, genuine or unavoidable risk presents itself and this needs to be countered. A host of methods can be deployed to give some level of assurance. The remainder of this section looks at network design techniques used to implement these methods. 6.4.3

Security solutions

There is no one path to security. Indeed the most effective approaches operate at a number of levels. For instance, a first step is to establish a security policy. This entails defining what it is that needs to be protected,

M-business

161

how the protection required is built in to the way that business is conducted, and who takes responsibility. A security policy should be fairly straightforward to define, given that you are selecting what you deem important from the list of the usual suspects given above. Some major breaches (such as the widespread infection of systems with the ILOVEYOU virus) could have been avoided if only people had treated an interesting looking e-mail message with suspicion. Hence, the real challenge in establishing a security policy is to ensure that it is operated correctly—the best encryption technology counts for little if its current key is written on a Post-It note attached to a computer screen. The watchword for this very people centric aspect of security is simplicity. It should be easier to maintain security than to break it. The technical aspects of security systems are complex and powerful—they should be adjusted by experts to present a near foolproof face to the user. The next in-building security solution is to look at the various technical options and how they might be used in concert. A good way to structure this quite large and often daunting task is to determine at what layer in the communication “stack” (see Appendix A) security techniques should be implemented. The best security will be achieved when techniques are implemented at multiple layers, and this may involve multiple levels of access (e.g., one password to get onto a server, another to get into a particular application). The odds of a hacker getting past several layers of protection are considerably less than those of guessing one password. Before looking in detail at the nuts-and-bolts technology that is available to implement specific security solutions, we should review just where security can be inserted—that is, the various layers of a network that can be protected from attack. Application security

Although required at all levels, the most effective security will be designed in at the application level. If we revisit the CIAAA checklist introduced earlier, the steps that can be taken in each area are as follows: ◗

Confidentiality. Application software could encrypt data for storage and/or before transmission between client and server.

◗

Integrity. Application software can add electronic signatures to messages.

162

Mobile IP Technology for M-Business ◗

Authentication. Users will be required to log on to operating systems and applications. This is often through the use of account names and passwords. Security is improved where rules on password length, design, and lifetime are implemented; such rules make passwords difficult for the attacker to guess. Security is improved when the password is used in conjunction with a token—something the user knows and something the user has! The token could generate a secure sequence of pseudo-random numbers, time synchronized to a process at the host site (e.g., the Security Dynamics SecureID card). It could use a challenge response principle where the host presents a random number to the user that is entered into the token. The token encrypts it and the user returns the result. The host will share the token’s key and can check the validity of the token. Increasingly important in this field are public key infrastructures (these are explained later). Here the token is a public key certificate (perhaps held on a smart card). This cannot only be used to authenticate clients or servers, but also is important in implementing encryption and digital signatures.

◗

Availability. Application software has to be backed up regularly. Ideally the application is available from multiple servers at different sites.

◗

Audit. Operating systems and applications would be used to keep such records.

The design (and sometimes, selection) of applications is something over which you don’t necessarily have a lot of control. Furthermore, security in many applications is not sufficient, so it has to be enhanced by the network. This might be because legacy applications are used that do not have adequate security designed in for use in a networked environment. It may be that it is not cost-effective to provide sufficiently powerful host systems to handle the processing demands of cryptographic security. Whatever the reason, the overall level of security is insufficient. Fortunately, the multiple layer approach both anticipates and offers a solution to this situation. Session layer security

Generally, secure applications will be session oriented in nature, with the user system setting up a session binding with the host system. Checks

M-business

163

such as periodic status polling and message sequence numbering can be used to ensure session integrity (i.e., detect if the original user has been cut off in midsession and an interloper is now posing as the original user). Additional security can be applied at session start-up time. This may be by means of a challenge system, where the host system sends out a random number that must be encrypted by the user system under a secret key. The response is checked to see if the user is a bona fide key holder. Other systems require the user to possess a token (usually an access card) that generates one-time passwords, according to an algorithm that the host system can track, so it will be anticipating the next one-time password to be offered. Increasingly, networks are using standardized security servers that will authenticate users wishing to access end systems and will supply them with a cryptographic token to be used when logging on to an application. Berbers, the security mechanism within the distributed computing environment (DCE), is an example of this approach. If such a security server is to be used, the network designer will have to provision network connectivity for it and ensure that all possible users can route traffic to it. The server must have ample bandwidth to cope with peak demands (such as when workers log on to systems at the start of a working day). Network layer security

Many network layer protocols provide useful security mechanisms. A few of the more common and useful examples used across the various types of networks deployed by organizations are discussed next. The majority of security attacks are likely to come from public data networks such as the Internet or X.25 networks. Where the enterprise network has no need of intercompany communication or is not offering a public service and very high levels of security are sought, this may be a justification for setting up a private network (based on leased point-to-point circuits and privately owned switches). Private networks and virtual private networks

Private virtual circuits Networks such as frame relay and X.25 can offer permanent virtual circuit connections. The network supplier sets these up at subscription time. Because end users cannot set up or change the routing of these connections, it is difficult for hackers to gain connections to hosts connected in this way. There is a weak spot, though, because networks that

164

Mobile IP Technology for M-Business

offer dial-up or switched virtual circuit connections make it possible for hackers to connect to an unprotected host. Closed user groups Closed user group arrangements are found on switched networks such as X.25 and are sometimes implemented across intranets. When calls are set up, the user can quote a closed user group number. The network administrator will have agreed with the network provider about which network connections are members of the closed user group with this number. The call cannot be directed to users outside the closed user group, and people not in the closed user group cannot call into it. These closed user groups rely on tables programmed into the network, which only the network supplier can change. Calling party identification In networks such as X.25 and ISDN, when a call is set up, the call request will contain the network address of the calling party. The network will ensure that this address is the correct address for the physical circuit from which the call came. Host systems can maintain a list of acceptable source addresses and can discard calls from any other address.

This is a form of security most commonly associated with networks that are interconnected to the Internet. This form of security is also used where some parts of an organization require its applications to be protected from other users (e.g., the finance department). In its simplest form, a firewall would consist of a router configured with an access list that would permit traffic only from predefined locations to pass through the router. Access lists may also be programmed to allow traffic to be routed onward to specified hosts. A more sophisticated form of firewall works at higher layers of the communication stack and normally consists of a UNIX host, with Firewall software, through which traffic must pass. This firewall may provide a number of functions including: Firewalls

◗

Encryption;

◗

Session management with user password verification;

◗

Address translation gateway (where the target network does not use registered Internet addresses);

M-business ◗

165

Proxy agent, which is used with applications such as World Wide Web servers, where each access request is screened to see if the page selected is available for access by that particular user, and if so will fetch the page from the server before forwarding it back to the requester.

A more general detailed treatment of firewalls is given at the end of this section. Data link layer security

A commonly used mechanism at the data link layer in TCP/IP-based networks is the PPP protocol. This standard includes security mechanisms called CHAP and PAP, which can be useful when using dial-up connectivity. As part of the link establishment process, the calling party sends out a password that is checked by the equipment receiving the call. This exchange is done quite transparently to the user. As with the use of calling party identification, the use of CHAP incurs significant administrative overhead: ensuring that all possible users have their passwords or addresses programmed into all possible items of equipment that may receive the call. In addition to the above, we can add tunneling, as described in Chapter 3. 6.4.4

Security technology

Many devices can play a part in protecting a network, and many suppliers specialize in providing security advice and equipment, from the basic virus guard programs that disinfect a PC to sophisticated codes that protect data. There are also a number of people who are willing to break into or otherwise violate your network—a useful test of the robustness of any network security solution is to let them try (having engaged their services first, of course). In this section, we describe the fundamental concepts of security technology: encryption, public key infrastructures, firewalls, and the like. Encryption

The primary role of encryption is to ensure the privacy of data when in transit across public networks. So one of the most effective ways to protect a network would be to encrypt all data flowing over it so that no intelligible data is available to the hacker.

166

Mobile IP Technology for M-Business

The idea of using secret codes (which is what encryption is all about) is nothing new. They have been used for years to ensure the privacy of information that is sent over untested carriers, such as a public network. Some of the earliest codes can be traced back to the ancient Egyptians. In 1660, Samuel Pepys was certainly devising such codes for use by English aristocrats communicating with the exiled King Charles. In the early part of the twentieth century Claude Shannon of Bell Laboratories proved that you could generate codes that could not practically be broken. By the 1940s, codes that realized Shannon’s ideas were being generated by the German “enigma” machine to protect wartime secrets (and were only broken when a code book was captured). Most schoolchildren have at least a passing acquaintance with encryption—they will have used some form of code to disguise messages passed around among their friends. A typical example of this is shown in the top half of Figure 6.3. The transposition of letters (very simple in this case) is a very basic secret algorithm and one often used by children for “secret messages.” Exactly the same idea can be applied to digital data. For example, the Clipper chip designed by the U.S. military contained an encryption algorithm known as Skipjack. Any two Clipper-enabled devices could exchange data and with considerably more security than Ordinary text

Ordinary text Message encrypted in transit

A-j B-h C-l

Secret encryption algorithm applied Secret key Sequential text of message

Secret encryption algorithm reversed

? Original text

Values for X,Y

Go forward X, take away Y, etc.

Figure 6.3

j-A h-B l-C

Message encrypted in transit

The basic idea of key encryption.

Decrypt

M-business

167

with our simple example! The only drawback is that all data are visible if the secret algorithm is discovered. And if the algorithm is burnt into silicon, as is the case with Clipper, it is difficult to restore security. A more flexible option is to use an algorithm that can be customized with a secret key, as illustrated in the lower half of Figure 6.3. The key, which is just a string of digits, contains the rules that drive the encryption algorithm. Hence, the issue now is to protect the key, rather than the algorithm, so now it is the way in which the key or keys are handled that needs to be carefully managed. With this approach, changing the key can restore a breach in security—there is no need to throw everything away and start again. Ideally, the data should be encrypted from end to end—in the end system hosts and terminals as well as in transit. This is not always possible, and a compromise solution is to encrypt data within specialist routers or stand-alone encryption hardware at the end sites. Most stand-alone encryption systems available on the market are designed to operate over point-to-point synchronous data links, but an increasing number of systems are being developed that are able to work over packet-oriented networks. The packet-oriented encryptors are also known as “payload” encryptors, because they encrypt only user data, leaving protocol headers in the clear, so that packets can be properly sent across the network. Successful use of encryption technology will depend on secure housing of the encryptors and the proper management of encryption keys (including changing them on a regular basis). There are two basic approaches to key management. The first is to have a private key, where the security of the encryption depends on a shared secret that only the two communicating parties know. The International Data Encryption Algorithm (IDEA) and Data Encryption Standard (DES) are examples of private key systems. The second, alternative approach is to have a public key, where a user has a pair of keys—one private and one public. A message encrypted using the public key can only be decrypted using the private key and vice versa. So you can receive messages from anyone who knows your public key (which you decrypt with your private key) and can happily send an encrypted message to anyone whose public key you know. Perhaps the best known of the public key systems is RSA (so called because it was devised by Messrs. Rivest, Shamir, and Adleman). For all its worth, the use of encryption faces some major barriers. The main one is actually obtaining the necessary hardware or software that removes the (sometimes) significant processing burden of encryption.

168

Mobile IP Technology for M-Business

Special-purpose chips (such as Clipper) have been developed to do this, but, because encryptors can have military use, their sale and export is rigorously controlled. Perhaps the best-known example of such restriction is the U.S. government’s Data Encryption Standard, which is classed as “munitions” and thus is subject to export restrictions. The network designer will have to fully investigate these licensing limitations before firming up a choice of encryption technology that is proposed in a design or in a bid. In terms of usage, private key systems, which use symmetric algorithms, are currently the most popular. Because these use the same key used for encryption and decryption they operate on blocks of data and subject them to a pattern of bit permutations and logic operations controlled by the key value. As such, they are able to operate at high speed and can be implemented using silicon hardware. Within some industries (e.g., the finance sector), the preferred symmetric algorithm was the 56-bit DES algorithm. In practice, computer technology now exists that can break 56-bit DES in a matter of days (and, often, a lot less). Hence, demand is increasing for stronger encryption (such as Triple DES) that uses a 112-bit key and is expected to remain safe from attack for many years to come. The standard 56-bit DES can be used by any customer, but U.S. export restrictions limit Triple DES to financial services applications. The latest standard aimed at providing secure, encrypted tunnels across the public Internet is IPsec. Encryptors are loaded with sets of source and destination IP addresses or subnets, each set constituting an intranet or virtual private network (VPN). Unless specifically configured to do so, the encryptor will not permit traffic to pass between intranets or VPNs, and will use different sets of encryption keys for each separate network. In terms of implementation, IPsec is basically a DES IP payload encryptor, with added MD5/SHA integrity checking. Key management is effected using RSA public key methods. Less common at present are public key systems, which use asymmetric algorithms with different encryption and decryption keys. These algorithms tend to be relatively slow and require considerable processing. They are generally only used for signing documents and encrypting symmetric data encryption keys so that they can be safely exchanged. DiffieHellman was the first of the published asymmetric algorithms (although it is suitable only for key exchange). RSA is the most widely used standard here today, with elliptic curve cryptography an emerging alternative. All of the algorithms are based on complex mathematics, using

M-business

169

problems that are known to have no algorithmic solution (e.g., RSA uses the known difficulty of finding the factors of the product of two large prime numbers). These problems can only be tackled by “sledgehammer” techniques that require exponential time in relation to the key length to solve. A major factor in the choice of a public key system is efficiency—performance-constrained systems need an efficient algorithm. In this respect, ECC appears to be the long-term favorite because it is designed to offer a higher level of security per bit of key length. Depending on the solution used, encryption technology can also provide a number of other valuable services. IPsec encryptors tend to provide the richest feature set, covering many of the defense areas mentioned earlier: Access control. The encryptor can maintain lists of allowed subnets—only data to and from these will pass through the encryptor.

◗

Authentication. Confirmation that the data comes from the location it claims to come from.

◗

Integrity. The data has not been corrupted or tampered with in transit—through the use of encrypted message digests.

◗

No replay. Sequence numbering and time stamping can be used to prevent improper replay of a transaction.

TE

AM FL Y

◗

These capabilities are particularly relevant when considering mobile IP because control is afforded over the places that a packet can go and packets can be uniquely identified by the time stamp. Public key infrastructures

Asymmetric encryption algorithms form the base of public key infrastructures. As indicated above, public key schemes are widely used for electronic document signatures (to prove source and provide nonrepudiation of transactions) and for exchanging data encryption keys. A user will generate a pair of keys—one public and one private—and publish the public key. However, we do need to know that the public key belongs to the right person and not an impostor. The public key infrastructure achieves this by having a trusted third party sign the user’s private key, after the user has proved her identity to the third party. This signed key is called a certificate, and a certificate authority (such as Verisign) issues

170

Mobile IP Technology for M-Business

them. The certificates need to be accessed from a directory, so that a message recipient can retrieve reliable public keys. The “digital signatures” provided by the two keys work with the certificate as follows. If Castor encrypts a message using his own private key, and Pollux is able to decrypt it using Castor’s public key, Pollux can be highly confident that the message actually came from Castor and not an impostor. If the message authorizes Pollux to perform some action (such as to take some money out of Castor’s bank account), the fact that the message has been verified as originating from Castor gives a similar level of confidence as if Castor had put his own moniker on the message. If we consider some of the practical detail, the technique as it is described above is a bit unwieldy. With the “signature” being the encrypted version of the entire message, there is potential for significant processing overhead—the message may have been a long one. So, for practical purposes, the digital signature is created from a digest of the message rather than the entire message. The way in which the digest is created is shown in Figure 6.4.

Original document

Hash algorithm Fixed-length digest

Encryption algorithm Issuer’s private key

Encrypted digest = digital signature Figure 6.4

Generating a digital signature.

M-business

171

In Figure 6.4, the whole of the original, uncoded message is passed through a one-way function (which is also known as a hash function) and which has the following properties: 1. It is “one way” in the sense that it is easy to convert the original message into a digest but impossible to use the digest to recreate the original message. 2. The digest is of a small and standard length, irrespective of the length of the original message. 3. Every character of the original message is significant in creating the digest, so that changing a single character in the original will result in a different digest. 4. The function is sufficiently complicated that it is very difficult to make multiple changes to the original message so as to yield the same digest. This last point is necessary to prevent the possibility of an unscrupulous person making some change to the message (such as adding an extra zero to a sum of money) and then making other compensatory changes such that the entire message still gives the same digest as the original. The algorithm commonly used for creating digital signatures (for, example in the Secure Electronic Transaction, SET, banking standards) creates digests that are 20 bytes long, irrespective of the original message size. This algorithm meets the requirement of being one way in nature; apart from anything else, reducing a long message down to a 20-byte digest must of necessity discard a lot of the original information, ensuring that there is no possibility of reverse-engineering the message from the digest. Despite this apparent discarding of information, the algorithm is such that changing a single bit in the message will change, on average, half of the bits in the message digest. In addition to this, the probability of any two messages having the same digest is 1 in 10 to the power of 48 (a number bigger than the number of atoms in the solar system!). Hence, it is not computationally feasible to generate two different messages that have the same message digest. So, if we have a couple of stars who want to keep the content of their communications out of the public gaze and, at the same time, be ensured that no impostors disrupt their dialogue, the actual process goes like this:

172

Mobile IP Technology for M-Business

1. Castor wants to sign the message he is sending to Pollux. 2. Castor (or his software) creates the 20-byte digest of the message. 3. Castor encrypts the digest using his private key—the resulting object is the digital signature of the message. 4. Castor sends the message together with the digital signature to Pollux. 5. On receiving the message, Pollux also generates a digest of it. 6. Pollux decrypts the signature using Castor’s public key. 7. Pollux compares the decrypted signature with his locally generated digest. If the two signatures (from steps 6 and 7) match, then Pollux can be confident that Castor signed the message and that it has not been tampered with by anyone else. The various steps in this process are illustrated in Figure 6.5. Returning briefly to the certificate, we have said that this is basically a set of data elements, bound together and electronically signed by a trusted certification authority (CA) using its closely guarded private key.

Castor’s message

Castor’s message

One-way algorithm

One-way algorithm Castor’s message

Message digest Castor’s private key

+

Message digest

Signature Encryption

Decrypted signature

Signature

Decryption

Signature

Figure 6.5

The digital signature in action.

Compare

Castor's public key

M-business

173

A basic class 1 certificate binds a user’s name with his e-mail address and the public key. This is used by individual Internet users to send secure e-mail or to identify themselves to Web servers. A class 2 certificate is issued by an organization, such as a bank, to identify its customers. It has bound into it further details such as account numbers. The certificates are still issued by a CA, but the user’s applications are processed by an in-house RA (registration authority), which is used to approve requests for certificates (e.g., once credit checks and written application for service is received). BT TrustWise Onsite is one of the U.K. providers of an RA facility. Web server operators will seek a class 3 certificate. In this instance, the CA will carry out rigorous checks to confirm the identity of the server owner and that it is a creditable organization. The certificate binds the server’s URL, the organization name, and its public key. If a server has such a certificate, browser users can confirm that they are communicating with a genuine server and not an impostor. More importantly, the certificate enables encryption keys to be exchanged and secure HTTP sessions to be run (e.g., for e-commerce and electronic banking applications). One important design issue with PKI is where the private keys should be stored. If on a PC, the key only really proves a message came from the PC, not the person—simple user passwords are used to protect the private key on the PC, a weak protection. A much better option is to keep the private keys on a smart card that moves from machine to machine with the key owner. When small secrets (keys) are used to protect big secrets (data), this is an altogether better design option—rather like the idea mentioned earlier of moving the processing to the secure data, rather than moving the data to the processor. Firewalls

One of the most effective and widely used strategies for preserving security is to use a firewall system. Just as a real firewall is a specially built barrier that stops the spread of a fire within a building, so a computer firewall tries to limit the extent of damage to computer security. The basic idea is that machines and networks on the “inside” of a firewall are trusted, whereas those “outside” are generally not trusted, as shown in Figure 6.6. All communications between machines inside and outside the enterprise go through the firewall (which, in practice, is usually a specialpurpose computer such as Cisco’s PIX or Sun’s Netra). It is the job of the

174

Mobile IP Technology for M-Business

Private

Demilitarized Zone - DMZ

Highly secure and totally trusted

Moderately secure and partially trusted

Public Unsecured Cannot be trusted

Firewall only admits known users Figure 6.6

Firewall restricts access to DMZ

The basic function of a firewall.

firewall to monitor and filter all traffic passing through it and only to allow through known communication corresponding to certain welldefined services or to trusted external systems. Hence, incoming traffic can be screened to allow access only to the privileged, and outgoing traffic can be limited if there are certain places an organization does not wish its people to visit! Machines on the inside of a firewall have a reasonable degree of trust of other machines within the firewall and so have to apply fewer controls themselves. Often, sections of the internal network will themselves employ firewalls to restrict the domain of trusted machines even further. This arrangement is usually applied within an enterprise network to give layers of protection to one organization’s information. With the growth of extranets and community of interest networks (COINs), a similar approach is used to create demilitarized zones (DMZs), where the information shared between organizations is protected from the world at large but is still outside any one organization’s intranet or VPN. The functionality of IPsec is ideally suited for implementing secure COINs/extranets.

M-business

175

Firewalls are most often applied at the level of network transport (i.e., the protocols used to transfer data between computers—TCP, UDP, IP, and so on). However, the same idea is also applied to higher level services with good effect. For instance, a particular service may be shielded by a proxy server. The proxy presents the same interface to the outside world as the real service, but instead of performing the requested operations itself it filters out undesirable requests and only passes approved requests on to the real server. Firewall products are increasingly able to provide encryption and this is used to create secure tunnels over public networks such as the Internet (to create IP VPNs). Encryptors are increasingly being given strong abilities to decide whether to drop, pass in clear, or encrypt based on established rules. Rules would cover source address, destination address, protocol type, and transport layer port information. Thus, we see that firewalls and encryptors tend to converge. In today’s networks, however, it is quite common to need both a firewall and an encryptor at each site! Remote access security

Remote access services (that is, those that entail the user making some temporary connection, such as dial-up, into a network) are particularly prone to attack. We have mentioned some of the means of protection already, such as a password-protected session log on and calling party identification. For completeness, we close this section by discussing two more useful techniques associated with dial-up networks: dial back and tail gating prevention. Dial back The user makes a dial-up connection to the host and goes through some initial password logon procedure. At this point, the host will clear down the call. The host will maintain a table of the users’ names and passwords, associated with the phone numbers that they should be calling from. The host then calls the user back on the approved number to permit the session to continue. This can be a good form of protection where calling party identification is not possible (e.g., analog telephone networks). It is not of use where the user population is likely to be mobile (and hence the phone number from which they are calling is not known).

A major risk area for dial-up access occurs when a legal user completes a call. If the network is not properly designed, it may be possible for an inappropriate user to connect to that port immediately afterward, picking up the legal user’s session and continuing it. This is Tail gating prevention

176

Mobile IP Technology for M-Business

especially likely where users do not properly log out from their host sessions and just hang up, relying on the host to detect the disconnection and close the session (naturally, users should be discouraged from doing this!). To prevent this problem, communications equipment must be designed to respond to loss of the connection when indicated by the modem or ISDN terminal adapter (through loss of the “carrier detect” signal). When this happens, it is good practice to disable the modem/terminal adapter for a short guard period of sufficient duration to permit the host to detect and fully close the application session before permitting the next call. In terms of technology, many of the options explained earlier in this section apply. In particular, IPsec is great for securing dial-up access due to ready availability of software implementations. In the context of network security, this section has explained only the most basic issues that the designer should be aware of and the defenses that can be deployed. The key message is that security is an increasingly important aspect of the logical design of a network and should be allocated a significant amount of attention. Several excellent references on network security are listed at the end of the chapter.

6.5

Summary

In this chapter, we focus on the end result of deploying all of the technology explained earlier, a result we term mobile business, or m-business. In particular, we have illustrated how both company and domestic users might benefit from the ability to access information while they move around. Having painted the picture of what m-business services might look like, we then go on to examine the challenge in providing them. The first step is to outline the essential components of an on-line service, such as catalogs and payment systems. These have become established with the growth of electronic business in general, but are well worth revisiting for mobile applications. Following this, we look at the considerations that need to be made in the design of the infrastructure that carries m-business transactions—the network. Guidelines for ensuring that the network provides a robust platform to support evolving services are given. Finally, we give detailed consideration to key issues of security. The sources and motivation for attacks on m-business services are outlined

M-business

177

and the various techniques for defense against them are presented. In addition to network protection methods, the way in which digital signatures and certificates work is explained and an overview of encryption is given. The successful deployment of m-business services will depend on many things. Perhaps the main message in this chapter is that attention needs to be paid to all aspects of a service—its presentation as well as the enabling technology and provision for security. Every deployment will have its own characteristics, the aim here has been to put together a blueprint that can be generally used and one that is generally useful.

Selected bibliography Cheswick, W., and S. Bellovin, Firewalls and Internet Security: Repelling the Wily Hacker, Reading, MA: Addison-Wesley-Longman, 1994. Cronin, M., Doing Business on the Internet, New York: Van Nostrand Reinhold, 1994. Garfinkel, S., & G. Spafford, Web Security and Commerce, Sebastopol, CA: O’Reilly, 1997. Hegering, H. -G., S. Abeck, and R. Weis, “A Corporate Operation Framework for Network Service Management,” IEEE Communications Magazine, Vol. 34, January 1996, pp. 51–72. Oppliger, R., Internet and Intranet Security, Norwood, MA: Artech House, 1998. Subramanian, M., Introduction to Network Management, Reading, MA: Addison-Wesley-Longman, 1999. Webb, W., The Future of Wireless Communications, Norwood, MA: Artech House, 2001. Yesil, M., Setting Up the Online Shop, New York: John Wiley & Sons, 1998.

CHAPTER

7 Contents 7.1

Future prospects

Deployment issues

7.2 Overview of end-to-end VPN operation

There is more to life than increasing its speed. —Mahatma Gandhi

Into the future

7.4

Summary

AM FL Y

7.3

I

TE

n the early 1980s, the BBC introduced a television series called Space Cops that rapidly built a cult following. One of the most memorable features of the series was the device that accompanied the lead character everywhere he went. This interactive unit provided all the information, sent all the messages, and carried out all the analyses that any self-respecting space cop could wish for. It was their personal Oracle and, give or take a few stylistic updates, was the mobile device that the technology explained in this book makes possible. Of course, this is a very selective view of what the future might hold. The way in which mobile services are provided will, most likely, vary according to the target audience. For example, a mass-market offering that allowed browsing and electronic mailing from a mobile device would have a different network configuration than that of 179

180

Mobile IP Technology for M-Business

a corporate intranet. The reason behind this is that a corporate network would probably have some very specific requirements, whereas the average consumer would simply buy what is on offer. By way of example, an organization wanting to support its staff as they roam would probably want to create a standard environment. It would also want to offer a common set of applications, preferably a set that is centrally managed—not many large organizations like diversity. The private individual, on the other hand, would more than likely load applications on their mobile device to suit their specific needs. Given the spread of requirements, it seems unlikely that there will be one way, and only one way, of implementing mobile data network and services. In this chapter, we revisit some of the possible configurations introduced at the start of the book to see what options are open, and how mobile IP alleviates some of the problems of building a secure network that can accommodate users with no fixed point of attachment.

7.1

Deployment issues

Toward the end of Chapter 2 we looked at some of the options for configuring a mobile data network. Various deployment scenarios were introduced—some with the mobile operator also providing the data services; others with a separation between data services and the mobile network operator. In this section we look deeper into the issues that arise in one specific deployment scenario, that of an organization trying to extend its internal information network. Of course, there is one significant difference this time around: We now know that mobile IP is an option. To start with, let’s add a little more detail to the two modes of GPRS access, transparent and nontransparent. The key difference between them is in the way in which they secure the link to the correspondent host. The former simply terminates the GTP tunnel at the GGSN and then forwards IP packets. With the latter, after the GTP tunnel is terminated, the user data is automatically transferred into a new tunnel created by the GGSN. This new tunnel passes through the Internet to a termination point (i.e., a corporate network or another service provider). Before this second tunnel is created, a subscriber-supplied user name and password would usually have to be authenticated, and then an IP address would be assigned to the mobile device. This difference in treatment has significant

Future prospects

181

consequence in terms of the overall network and the services that it would carry. We now consider the issues in both the transparent access and nontransparent access cases. 7.1.1

Transparent mode

Figure 7.1 shows the main elements of a transparent mode GPRS network along with some of the areas in which key implementation decisions need to be made (the big arrows). To start our examination of this setup, we consider some general points that are applicable to all transparent mode GPRS systems and then move on to discuss some specific business models. Addressing needs

Any mobile device that wants to access services requires a routable IP address. That is to say it needs an address to which any arbitrary server on the Internet (such as artechhouse.com) will be able to respond. The mobile operator will need an address for every simultaneously connected subscriber. An operator can get routable address space for its operation in one of two ways. Probably the easiest is to make an agreement with an upstream backbone or wholesale Internet service provider (ISP) for the loan of IP addresses. In addition to leasing the mobile operator address space within its allocated address block, this agreement ensures that other parts of the Internet can be reached. One or more providers for IP addresses and Internet connectivity could be selected. Alternatively, an operator can apply for its own address space from the Internet Corporation for Names and Numbers (ICANN) or from Reseaux IP European (RIPE). In this case, the operator will have to justify the need for the addresses they ask for, because allocation is driven largely by the need to conserve IP version 4 addresses (so the application must demonstrate efficiency of use). The operator will also have to apply for an autonomous system number and then negotiate for upstream Internet connectivity with one or more wholesale ISPs or Internet exchanges (such as LINX or CIX). Once the required address ranges are available, they can be assigned to users in any of a number of ways. The most efficient approach is to allocate them from a server via the Dynamic Host Configuration Protocol, as explained in Chapter 4. The real skill is in determining how many addresses are actually needed for a given subscriber population.

182

Subscriber billing

Protection Billing records

Billing records

GTP tunnels Internet

GPRS network

GGSN

Home location register (HLR)

Other GPRS elements

Internal DNS address pool (DHCP)

Determine addressing needs Figure 7.1

A transparent GPRS implementation.

Configure domain name services

Sizing of Internet connection

Mobile IP Technology for M-Business

Remote SGSN

Future prospects

183

Domain names

In addition to an address range for allocation to mobile devices and upstream connectivity to the global Internet, the operator in a transparent access GPRS network would expect to provide domain name resolution services. This is the service that turns the human-readable name (like www.artechhouse.com) into the actual IP address of the Web server. This entails running a domain name server and configuring it to correctly forward name resolution requests and cache the replies. An upstream ISP may be able to provide this service for the mobile operator. Protection

Hackers have already shown that the emerging mobile Internet operators present an interesting challenge. Their most likely target will be the public (Gi) interface from the Internet. In this case, destination addresses from packets coming from the public interface are routed, via an open tunnel table, into GTP tunnels going directly to the connected mobiles. There is no other path for packets from the public interface (e.g., into the operator infrastructure to attack billing or other resources that might be present on the private side of the GGSN). On the network side of the public interface, packets are just like any other on the Internet. Billing

The information collected from the GGSN and SGSN includes typical byte counts and session times—the same as that found in many Internet and data applications. This base information is then keyed to the user’s mobile identifier (the IMSI), rather than the familiar username/password models typically used for Internet applications. Hence, operators who have existing Internet services with accounts based on user names will have to consider how best to organize the mediation of network usage records to produce the bills for the wireless Internet service. Sizing the Internet circuit

The mobile operator will be responsible for sizing the circuit(s) that provide the connection to the upstream ISPs. For resilience and load balancing, redundant sets of GGSNs are likely to be deployed at the Internet connection site. Sizing of the circuits would be driven by analysis and monitoring. Analysis entails estimating the speed of the mobiles as well as the customer traffic patterns. This will typically be supplemented by day-to-day trend analyses of the Gi circuit utilization.

184

Mobile IP Technology for M-Business

Once the mobile operator has attended to all of the above issues, along with the inevitable 1,001 other implementation tasks, it would have a perfectly viable network through which to offer a range of IP services. Earlier chapters provide most of the technical information (on addressing, security, etc.) that the operator needs and the prospect of mobile IP gives the operator’s customers the freedom to roam. This deployment option would, as it stands, probably not suit a corporate user. They would want more protection past the Gi interface and, hence, we now need to look at nontransparent access. 7.1.2

Nontransparent mode

The key difference in this instance is that the link from the GGSN to the correspondent node is secured by tunneling. This means that functions such as authentication and attribute assignment can now reasonably take place in the mobile operator’s infrastructure, as shown in Figure 7.2. In Figure 7.2, a simple IPsec connection is shown between the GGSN and the point of access to the corporate network. The customer authentication server would most likely offer a RADIUS (remote-access dial-in user service) service with multicustomer capability. This would allow the operator to host the server on its premises, but allow each customer to maintain and manage her subscriber user base, in the manner of an application service provider. The GGSN would probably also support multiple customer-based address pools, and so support multiple address spaces via DHCP. More interestingly, in this configuration, the authentication and attribute assignment can take place at the customer service provider or corporate site. In this case, the GGSN in the operator network functions like an L2TP-enabled access concentrator (LAC), and creates an IPsecprotected L2TP tunnel to the destination VPN server (Figure 7.3). To gain access over this network, the user would need to enter his name and password into the mobile device. This is then sent to the appropriate authentication server as configured in the nontransparent APN definition for the corporate VPN. Accounting and provisioning

In both cases a RADIUS style accounting record with the data-oriented user name and password would be written (as opposed to the IMSI-based record written in the transparent case). In the case of the IPsec-protected L2TP, this makes the operator’s GPRS system look like just another access concentrator into an established service provider’s facility. This

Billing records

Billing records

GTP tunnels

ISDN/DIAL

Partner with ISP for other access methods and VPN services

Internet

GPRS network

SGSN

Home location register (HLR)

DNS (APN resolution)

Customer authorization server Customer addressing(DHCP) and naming (DNS)

Cable modem

Future prospects

XDSL

GGSN Billing records

Nontransparent IPsec tunnel

VPN server Intranet

Service broker/WAP gateway Nontransparent GPRS.

185

Figure 7.2

Customer application servers (e-mail, etc)

Billing records

Billing records

GTP tunnels

186

XDSL

ISDN/DIAL Cable modem

Partner with ISP for other access methods and VPN services

Internet

GPRS network GGSN SGSN Nontransparent IPSec L2TP tunnel DNS (APN resolution)

VPN server

Customer authorization server Customer addressing(DHCP) and naming (DNS) Service broker/WAP gateway

Figure 7.3

Nontransparent GPRS access with IPsec-protected L2TP.

Billing records

Intranet

Customer application servers (e-mail, etc)

Mobile IP Technology for M-Business

Home location register (HLR)

Future prospects

187

availability of RADIUS style billing records, keyed to user names, makes it easier for the service provider or the operator to do integrated billing, including models that may charge for connect time or the capacity used. In nontransparent mode, the operator does not have to allocate address space for the subscriber. The one and only address assigned to the user’s mobile device comes from the user’s corporate address space. Hence, the home addresses of mobile users are owned and controlled by the organization and not a third party. As with the transparent mode, the operator GGSN is connected to the public Internet with the same level of security as in that case. The key task for the operator will be managing the capacity and performance of this circuit. Similar to the end-to-end transparent model (where the user would need to carry the client software for access to their corporate network on their PC), the mobile operator has a preconditioned market for mobile VPN services from customers that are already doing VPN access via other technologies. Companies in this position would already be running their own VPN infrastructure (servers along with addressing and authentication). A compelling business strategy here would be to partner with a managed VPN service provider to add the wireless access to the seamless portfolio. One difference from the end-to-end model discussed above is that no software needs to be deployed on devices connected to the mobile operator. With a nontransparent VPN, the user is captive and not free to roam to other Internet services (unless allowed access via their intranet connection). Security considerations

The nontransparent tunnel that connects the operator’s core network to the organization’s VPN server would probably use IPsec technology and so could deploy strong encryption. This encryption, however, is not end to end. Data travels in clear text through the operator’s network and is encrypted by the proprietary wireless encryption protocol (with a 56-bit key length) over the air interface. A full-function mobile device can augment the basic security [a 56-bit key and a secure socket layer (SSL) protocol with any number of end-to-end mechanisms, including SSL or transport mode IPsec]. An important security consideration for any organization using nontransparent GPRS access is that once users are authenticated, they

188

Mobile IP Technology for M-Business

become a part of the intranet environment, and will be deemed to be inside the corporate firewall. Hence, the organization does not have to make any application servers available on the public Internet because only users that are authenticated can access the VPN applications.

7.1.3.

The corporate VPN in transparent mode

To close this section we examine how an end-to-end corporate VPN service can be implemented on a GPRS transparent mode service. Of course, the same service could be implemented via the nontransparent mode of access (and probably more easily, as shown above) but the aim here is to illustrate the spectrum of deployment choices. To implement an effective end-to-end link when using transparent mode GPRS, the mobile user would have to put tunneling and encryption software on her mobile device and then use the public Internet to connect to a VPN server on her corporate network. This might not work in some cases, but there are reasons why an organization might want to implement the end-to-end model including such considerations as the two discussed next.

Better overall security

The level of security in a nontransparent GPRS implementation has yet to be fully developed. With an end-to-end VPN the user controls security and can specify, for instance, Triple DES encryption from his mobile device all the way to his corporate VPN server.

Uniformity of access

The user may already use end-to-end VPN technology for corporate access via wireline dial-up or over broadband access such as xDSL or cable. Many businesses have already implemented remote access to their VPNs through the Internet, either as managed network services or simply managed by themselves. The installed customer base already has VPN terminations and authentication equipment and the users have a VPN client installed. Hence, the user can work equally well on the wireless Internet as on a faster broadband or dial-up connection. Of course, the nature of the access method will have some impact—applications may need to be sensitive to the speed difference and some applications may or may not be appropriate for the roaming user.

Future prospects

7.2

189

Overview of end-to-end VPN operation

TE

AM FL Y

Figure 7.4 shows a typical set up—a laptop connected to a GPRS-enabled cell phone via a serial cable (alternatively, the laptop could be equipped with a PCMCIA GPRS card). The user would initiate data operations by running something like the Microsoft-Supplied Dial-Up Networking (MSDUN) application. This application sends a series of AT-style commands to set up a wireless data connection. These commands are quite cryptic and will typically be set up by an install process rather than by the user directly. Even though the dial-up application has fields for user names and passwords, these are ignored. As stated earlier, the transparent access user is authenticated for wireless data operations by her home location register entry. A GTP tunnel is connected from the SGSN serving the user’s current location to the GGSN node connecting the user to the Internet. Billing records from both the SGSN and GGSN are written to the billing gateway. A routable Internet address (which serves, for the time being, as the care-of address) and a domain name server are then assigned to the user. The user now can run any application that can be reached from the mobile operator’s public interface. However, the application of interest here is the VPN client, which enables the mobile device to access service on the company intranet, just as if he had dialed in via a standard modem. The client software would have a destination field preset with the public IP address of the corporate VPN server. The user would then enter her user name and password. The authentication server verifies these at the entrance to the VPN, and the user is assigned a second IP address in the corporate address space (her home address) that remains active for the duration of the connection. This address can be assigned either by the VPN server itself or by an (DHCP) address server running on the corporate network. The end-to-end VPN connection encrypts all data traveling through the Internet and the wireless parts of the connection. The end users can therefore access e-mail, information, and internal applications with high levels of security applied to the connection. 7.2.1

Business aspects

As with the basic transparent service, the key business issues include the nature of the peering relation between the mobile operator and the Internet, with its related billing implications. These include the

Billing records

Billing records

GTP tunnels

ISDN/DIAL

Partner with ISP for other access methods and VPN services

GPRS network

Cable modem

Internet GGSN

SGSN

Internal DNS address pool or DHCP

VPN end-to-end tunnel (i.e. IPsec)

VPN client software Corporate VPN access with transparent GPRS.

VPN server

Customer authorization server Customer application servers (e-mail, etc)

Intranet

Mobile IP Technology for M-Business

Home DNS (APN location resolution) register (HLR)

Figure 7.4

190

XDSL

Future prospects

191

financial arrangement between the mobile operator and the upstream Internet service provider (ISP), and the overall billing environment for the user. 7.2.2

Partnering

Almost all ISPs, large and small, are offering VPN services to business customers as a managed network service. Key drivers of this business include: ◗

The cost savings due to the replacement of obsolete modems and 800 (free phone) services with a VPN server connected to the Internet;

◗

Time and management effort savings (and, potentially, increased services) from outsourcing the remote-access operation to a service provider; and

◗

The flexibility of VPNs, which allows the connection of business partners, suppliers, and customers to company applications through a shared area. This arrangement (known as an extranet or a demilitarized zone) enables a raft of on-line business applications.

The mobile operator can partner with ISPs to offer VPN services. This partnership helps the mobile operator find an instantaneous market for its wireless Internet service, and it helps the ISP by adding mobility to its service offering. 7.2.3

Billing models

In the transparent mode of GPRS access, billing records for subscriber data access are written to the charging gateway showing connect times and bytes transferred during the data session. The GPRS was originally conceived as an always-on model similar to xDSL or cable modem access. Because actual services have not yet been deployed, we do not yet know whether billing will follow the flat rate access charges (typical in the wireline-based always-on services) or whether operators will bill for connect times or, more interesting, for the amount of data transferred. In this case, the operator partners with an ISP for actual addressing and access to the Internet backbone. The ISP is probably providing value-added services associated with the VPN operation including:

192

Mobile IP Technology for M-Business ◗

End user help desk and support;

◗

Capacity and operational management for the VPN server and the Internet connection;

◗

End user training;

◗

Management of end user VPN software;

◗

Other optional services such as end user password management and applications support.

The Internet/VPN service provider clearly must consider a number of costs when extending the VPN connection to the wireless users. These costs include the cost of access circuits between the mobile operator and the ISP and their management and also the cost of fielding and escalating help desk questions relating to the new wireless operations. It may be tempting for the VPN service provider to consider persubscriber billing for these additional services. In the transparent model, per-session subscriber information is not sent to the service provider. Per-session billing would involve the transfer of the GPRS billing records to the service provider, who would have to process them by translating the IMSI subscriber ID to the user name ID typically used by them. Thus, the mobile operator can defray its expenses either by billing a fixed fee to the corporation for the VPN service or by adjusting the connect time or capacity-based charges appropriately. The Internet/VPN service provider may want to consider either a paid-for wireless option for its VPN service or a per-subscriber supplement to defray costs.

7.3

Into the future

By its very definition, mobile data does not stand still. Just as the options and issues for deploying the latest technology become clearer, so do new capabilities emerge. A considerable amount of effort is now being devoted in the standards arena to the definition of more powerful solutions. Of particular interest is the third-generation partnership project (3GPP; see www.3gpp.org), which has been working to enhance the GSM/GPRS technology described in the body of this book. Their ultimate aim is to devise protocols, specifications, and concepts for the emerging

Future prospects

193

“all-IP” cellular network—one in which all traffic, voice, and data are carried in IP packets. The realization of all parts of the 3GPP’s work has yet to materialize. Indeed, the deployment of today’s technology is challenge enough for many. Even so, it is worth considering what might lie ahead. One part of the 3GPP mission is accomplished by enhancing the capabilities of the existing GPRS components. In the latest specifications, the SGSN, GGSN, and HLR are upgraded so that they can cater to the transmission characteristics and information requirements of the range of traffic types envisaged by 3GPP. These upgraded components are designated E-GGSN, E-HLR, and so on, with the addition of the “E” designating enhanced, as in EDGE. In addition to enhanced versions of existing components, a mix of voice, data, and multimedia traffic demands improvement to mobility management for real/non-real-time call and session control. This is where new components are needed and the main additions proposed are as follows: ◗

The call state control function (CSCF) controls the progress calls to and from the mobile network.

◗

The signaling gateway (SGW) mediates call control between the mobile network and the Public Switched Telephone Network or PSTN (which uses the C7 signaling system).

◗

The media gateway control function (MGCF) controls the state of calls that pass through the MG.

◗

The media gateway (MG) provides media stream processing.

Because of this increased number of network components, new interfaces are required, and 3GPP has added the “M” series to the existing “G” series. There is one anomaly and to complete the picture, the “Cx” interface is introduced to define the link between the E-HLR and the CSCF. The overall approach of 3GPP is to tightly integrate the traffic that passes through a mobile. A somewhat different philosophy prevails with the evolution of CDMA—the cdma2000 solution persists with two parallel networks, a circuit-switched one and a packet-switched one. It remains to be seen which is the better option or whether something else, such as wireless LAN networks, gain popular acceptance. As J. B. Priestly observed, prediction only serves to make our descendants laugh.

194

7.4

Mobile IP Technology for M-Business

Summary

A mobile data network can be set up in any of many ways. This chapter has illustrated some of the deployment options that seem likely to find favor. First, we describe a configuration that would suit an operator that wants to offer a selection of mobile Internet services. We then outline the sort of arrangement that might be chosen by a large organization wishing to add a mobile dimension to its intranet services. Each of the options described has its own particular characteristics, some positive and some negative. Only time will tell how the marketplace and, hence, the best arrangement of technology and ownership to satisfy it will evolve. Many predictions have been made about what the world of mobile data will look like in coming years. Virtually all of the analysts expect huge growth, consolidation of mobile operator and ISP business, and massive demand for m-business applications. A few of the pundits go further and predict which operators and which technologies will come to dominate. Ultimately, though, prediction only really serves to make our descendants laugh. In this book we stick to the issue of how, not whether, to provide mobile data services.

Selected bibliography Frankel, S., Demystifying the IPsec Puzzle, Norwood, MA: Artech House, 2001. J. P. Morgan, Wireless Data—The World in Your Hand, Industry Analysis, 2000. Webb, W., The Future of Wireless Communications, Norwood, MA: Artech House, 2001.

Appendix A The Internet Protocol, Versions 4 and 6 Nothing holds up the progress of science so much as the right ideas at the wrong time. —Vincent de Vignaud

T

he Internet Protocol (IP) is a connectionless packet protocol that has made it possible for millions of computers to be connected. Since its introduction, around 30 years ago, IP has become the lingua franca of data communications—the protocol that supports every application. Not since the adoption of the RS-232 interface that adorns just about every computing device have we seen such wide acceptance of a standard. The level of global interworking that IP allows has taught the industry the value of cooperation. With the prolific growth of computer network applications, however, the current version of IP, version 4, is being pushed to its limits. In particular, the ever-increasing demand for IP addresses means that the 32-bit address field in IP version 4 is facing exhaustion. The problem is not a new one. During the late 1990s, several technical innovations have been designed to mitigate the pressure on IP addresses. The widespread use of dynamic address allocation (e.g., DHCP), more effective use of address ranges (e.g., CIDR), and more

195

196

Mobile IP Technology for M-Business

stringent conservation goals applied by the address registration authorities (IANA, RIPE) have all helped to prevent exhaustion. At the same time, the root of the problem has been tackled through the development of an updated version of the Internet Protocol, version 6 (IPv6). IPv6 is now a reality. The most obvious feature is that it greatly expands the version 4 addressing scheme. In addition, it provides facilities for the authentication and privacy of transmissions, plus a host of other enhancements—some of which help considerably with mobile data. In this appendix, we give a brief overview of IPv4 and the main protocols with which it interacts to support a communication link. The next section explains IPv6 and discusses the key differences between IPv4 and IPv6. Finally, the effect of IPv6 on mobility is discussed.

A.1

Overview of the Internet Protocol

A protocol defines the expected behavior between entities, a set of rules to which the communicating parties comply. Telecommunications and computer protocols have to be understood by machines, so they must be precise and unambiguous. The protocol needs to define the information to be conveyed, how it is sent and received, to whom it is addressed, from whom it is sent, and its meaning within its relative context. The best known of the Internet protocols is usually referred to as TCP/IP since this is the collective term used for its many implementations (and many component protocols) on PCs and UNIX computer systems. It gets its name from two of its components Internet Protocol (IP) and Transmission Control Protocol (TCP). In practice, Internet applications use either TCP or User Datagram Protocol (UDP). The differences between these two are that UDP is for unreliable connectionless packet delivery, and TCP is for reliable connection-oriented byte-stream delivery. UDP tends to be used for simpler services that can benefit from its speed (especially for delay-sensitive applications such as voice over IP). TCP is used for more demanding applications where it is worth trading a little efficiency for greater reliability (e.g., mail and file transfer). The difference between the two protocols is evidenced in their headers; see Figures A.1, A.2, and A.3 for TCP, UDP, and IP headers, respectively. In each case, the width of the diagrams implies 32 bits of information.

The Internet Protocol, Versions 4 and 6

197

Source Port

Destination Port

Sequence Number Acknowledgment Number HLEN and Code Bits

Window

Checksum

Urgent Pointer

Basic TCP header.

Figure A.1

Source Port

Destination Port

Length

Checksum Data

UDP header.

Figure A.2

Ver

IHL

Type of Service

Total Length

Flags

Fragment Offset

Identification TTL

Protocol

Header Checksum Source Address

Destination Address Checksum

Urgent Pointer

Options (If Any)

Padding

Data Figure A.3

IP header.

The Transmission Control Protocol is described in detail in RFCs 793 and 1323. The purposes of the main fields shown in the header are as follows: Source Port

Refers to the application that sent the packets

Destination Port

Refers to the application receiving the packets

Sequence Number

Ensures that data are received in the right order

198

Mobile IP Technology for M-Business

Ack. Number

Keeps track of the next expected octet

HLEN

Header length, which gives the number of 32-bit words in the header

Code Bits

Control functions

Window

The limit of the number of octets that the sender can accept

Urgent Pointer

Indicates the end of the data

The User Datagram Protocol is described in detail in RFC 768. The purposes of the main fields shown in the header are as follows: Source Port

Refers to the application that sent the packets

Destination Port

Refers to the application receiving the packets

Length

Header length

Checksum

Header checksum

The TCP header is clearly more complex than the UDP header. Both identify the source and destination ports (Table A.1), the bare minimum of information needed to set up an end-to-end connection. The TCP header has additional fields that allow the sequence of packets in a transaction to be tracked. Hence, any lost information can be retransmitted and both the sender and receiver have some confidence Table A.1 Commonly Used Port Numbers*

TCP

UDP

Application

Port Number

FTP (file transfer)

20, 21

Telnet (remote login)

23

SMTP (mail)

25

HTTP (Hypertext)

80

DNS (name serving)

53

TFTP (file transfer)

69

SNMP (management)

161

*Defined in RFC 1500 for TCP and RFC 1700 for UDP.

The Internet Protocol, Versions 4 and 6

199

that their dialogue is under control. The advantage of the minimalist approach taken with UDP is that there are few delays, so the connection may not be as well controlled, but it is quick. Both TCP and UDP rely on IP to get them from point A to point B. This means that an Internet packet is arranged in layers, with the user’s data wrapped up inside the TCP or UDP bits, which are wrapped up inside of the IP bits. IP version 4 is described in detail in RFC 791. The purposes of the main fields in the header are as follows: Version

IP version number (currently 4)

IHL (Internet Header Length) Datagram header length (measured in 32-bit words) Priority and quality of service settings

AM FL Y

Type of Service Total Length

Length of IP datagram (including octets in the header)

Flags Fragment Offset

With LAN datagrams of the order of 4.5 kbyte (token ring), 1.5 kbyte (Ethernet), fragmentation of the IP packet can occur; this unique number assigned to a datagram fragment helps with reassembly

TE

Identification

Used in the control of fragments

Specifies offset in the original datagram of data being carried in the fragment (measured in 8-octet units)

TTL (Time to Live)

Time that the datagram can remain in the internetwork before being declared lost (and so deleted)

Protocol

Specifies the higher layer protocol contained in data field; UDP uses the number 17 and TCP uses the number 6

Checksum

A 16-bit checksum of the IP header (which checks only the header)

Source/Destination Address

The 32-bit IP addresses

200

Mobile IP Technology for M-Business

The portrayal of communications protocols as layers within a stack is quite conventional. This approach was evident in the seven layers of the Open Systems Interconnection (OSI) model whose concepts and layering have been retrofitted onto a variety of proprietary communications protocol (such as IBM’s SNA and Digital’s DECnet). TCP/IP has not been exempt from this treatment and so the layered model is repeated (Figure A.4). The stacking or layering within the protocol is a convenient way to separate functions in the protocol. Different standards bodies have chosen different numbers of layers to represent a communication session. For instance, the OSI, which generates standards for telecommunication, has developed a seven-layer model. The Internet has four layers, as explained below. Many references are available that show how the layers from one standard map into those of another. Layer 4 The application layer defines the application software, its processes, and the protocol it uses to convey its data to the communications protocol stack. In the case of e-mail, it uses the Simple Mail Transfer Protocol (SMTP). E-mail applications wrap up messages with start and end markers and attach header information about where the mail is from and who the mail is to be sent to. This is passed to the layer below to be sent on its way. The process is much like putting a letter in an envelope, writing an address on the front, affixing the proper postage, and dropping it into a postbox.

Figure A.4

Applications

FTP, SMTP, Telnet, HTTP file transfer,Web browsing, etc.

Transport

TCP, UDP End-to-end delivery

Internet

IP Point-to-point packet routing

Network access

Ethernet, etc. Basic connection to the Internet

The TCP/IP layered stack model.

The Internet Protocol, Versions 4 and 6

201

Layer 3 The transport layer wraps up the application layer message in its own data that defines the application that is sending it and the application to receive it; these are known as the source and destination ports. It will also add data to specify the overall length of the message and a number, the checksum, to use to check if any of the data it is carrying has been corrupted. This is the layer in which both TCP and UDP reside. UDP is generally used to convey small messages of a request-response nature within single packets, and TCP is used to convey larger messages within a bytestream where some delivery assurances are needed. The reasoning behind this difference is that, for small messages, the overhead of creating connections and ensuring reliable delivery is greater than the work of retransmitting the entire message. To this end, TCP will attach further information to the message passed from the application to ensure that the reliable connection is maintained during the transmission and that the segments of the byte-stream all arrive at their destination. Continuing the earlier post office analogy this is like having a set of numbered boxes being dispatched from a shipping office that looks after the customer’s accounts (and hence ensures that they get all of their boxes when they should). Layer 2 The Internet layer provides the most important function of the TCP/IP stack. It structures the data into packets, known as datagrams, moves the datagrams between the network access layer and the transport layer, routes the datagrams from source to destination addresses, and performs any necessary fragmentation and reassembly of datagrams. The Internet layer wraps up the transport layer data in its own data, which includes the length of each datagram and the source and destination addresses (the IP addresses), which specify the network and host of the source and destination. This layer is akin to the internal workings of a post office—how letters are bundled into bags, how the delivery trucks are routed and scheduled, which commercial subcontractors are used, and so forth. Layer 1 The network access layer is perhaps the least discussed of all the layers since the protocols within it are generally specific to a particular hardware technology for the delivery of data. Therefore, many protocols exist, one or more for each physical network implementation. The role of the network access layer is to ensure the correct transmission of IP datagrams across the physical medium and mapping of IP addresses to the

202

Mobile IP Technology for M-Business

physical addresses used by the network. In the “real world,” this layer provides the planes, boats, and trains that get packages from A to B. The examples above explain how an application may send data across the Internet using the TCP/IP suite of protocols, from application layer to network access layer. The reverse is also true when data are received by the network access layer. The roles of each layer are the same, the difference being that the data are “peeled” as they ascend the stack, each layer removing the layer-specific data put there by the source TCP/IP. The concept of wrapping up data, layer by layer, in this way is referred to as encapsulation. A.1.1

Addressing

Each host on the Internet has a unique number, known as an IP address (this concept and the fact that there are a limited number of these were discussed earlier in this appendix). The IP address is a 32-bit number that can be used to address a specific network and host attached to the Internet. This does not mean that every Internet user has a permanent IP address. As we have seen, dial-in users using the point-to-point protocol (PPP) to connect to an ISP are “loaned” one for the duration of their connection. Enduring IP addresses relate to a specific host on a specific network. The 32-bit IP address needs therefore to be split to define both a network part and a host part. This split occurs in different positions within the number according to the class of the address, and there are four classes, A through D. Figure A.5 shows the allocation of network and host addresses in each of the IP classes. Class A addresses use 7 bits of the first byte to define the network (the first bit indicates that this is a class A address). The remaining 24 bits are used to address the hosts on the network. Hence the network numbers are in the range of 1 to 126 and the host numbers range from 1 to 255.255.254. A bit-by-bit view is given here:

Class A

| 76543210 | 76543210 | 76543210 | 76543210 | | 0 [network] | [host] |

Class B addresses use the first 2 bytes to define the network (bits 1 and 2 tell you that this is a class B address, bits 3–16 identify the network). The remaining 16 bits are used to address the hosts on the network; therefore, thousands of hosts can be addressed from thousands of class B networks. Hence, network numbers range from 128.1 through

The Internet Protocol, Versions 4 and 6

203

Class A

Addressable hosts

Addressable networks

Class B

Addressable networks

Addressable hosts

Class C

Addressable networks Bits 1–8 Figure A.5

9–16

Addressable hosts 17–24

25–32

Main structure options in the 32-bit IP address.

191.254 and host numbers go from 1 to 255.254. The bit view is as follows:

Class B

| 76543210 | 76543210 |10 [network]

| 76543210 | 76543210 | | [host] |

Class C addresses use the first 3 bytes to define the network (bits 1, 2, and 3 say this is class C, bits 4–24 are for the network). The remaining 8 bits are used to address the hosts on the network. Class C network numbers are in the range of 192.0.1 to 223.255.254 and host numbers are in the range of 1 to 254. The picture is as follows:

Class C

| 76543210 | 76543210 | 76543210 | |110 [network] |

76543210 [host]

| |

Class D addresses are special, reserved for multicast protocol address. For the sake of completeness the class D network numbers go from

204

Mobile IP Technology for M-Business

224.0.0.1 to 239.255.255.255, but there are no host numbers. The range of 240 to 255.255.255.255 is reserved:

Class D

| 7 6 5 4 3 2 1 0 | 76543210 | 7654321 | 76543210 | |1110 [multicast] |

IP does not allow all zero [00000000 = 0] or all one [11111111 = 255] bits in either the host or network portion of the 32-bit address; these are reserved for special uses. Two class A addresses are missing from the list above: 000 [00000000] and 127 [01111111]. These are special addresses used for default and loopback routing when configuring a host. Also, host numbers 000 [00000000] and 255 [11111111] are reserved; 000 defines the network itself, and 255 is often used to broadcast to every host on the network. It is often necessary to define additional networks from an address range. The “robbing” of host address bits for use as additional network address bits does this. Hence, the total number of addressable hosts is reduced, but the number of networks is increased. These networks are known as subnets. The need to define subnets is usually not technical but managerial or organizational. Subnetting caters to the delegation of address assignments to other organizations, however, subnets are only locally defined and the actual IP address of a host is still interpreted as a standard IP address. Subnets are defined by applying a bit-mask (the subnet mask) to the IP address. If a bit is 1 in the mask, it defines a network bit; if a bit is 0 in the mask, it defines a host bit. It is best to define subnet masks on byte boundaries (it makes them easier to read), so a standard class A address would have a subnet mask of 255.0.0.0. All bits in the first byte are 1 (defining the network), and all bits in bytes 2, 3, and 4 are 0, defining the millions of hosts that are addressable on a class A network. 255.0.0.0 = | 11111111 | 00000000 | 00000000 | 00000000 | A.1.2

Routing

Two basic types of devices are used on the Internet, either a host, such as a computer, and a gateway, such as a network router. Gateways are essential components of the Internet; without them, no two networks would be interconnected. Both of these devices are required to route data

The Internet Protocol, Versions 4 and 6

205

both to and from hosts. The routing decisions are not complex. When a device, such as a router, receives an IP datagram, it examines the network portion of the IP address. It will first decide that if the destination address is on the local network it will deliver the datagram directly to the host. If it is destined for a remote network, it will deliver the data to the next switch (router) en route, which will make the same decisions and route accordingly. How the router decides where to go next depends on the routing protocol being used. The most basic option is a distance vector protocol, such as Routing Information Protocol (RIP). The header for version 2 of RIP is shown in Figure A.6. Each row in the header is 32 bits (4 octets) wide, with the last 20 octets (4 rows) used to specify the destination network. These octets are repeated for each network being advertised—a maximum of 25 networks can be advertised per RIP version 2 packet. Routers running this type of protocol are just configured with a list of the subnetworks directly attached to that router. The router will periodically broadcast a routing update to all other routers attached to these subnetworks, telling them about the subnetworks that can be reached. When a router receives a routing update from a neighbor, the update will contain information about subnetworks not directly connected to the recipient router. The router will merge this newly acquired information into its own routing table. When this router next sends its own update, it will pass on information about the networks it has just learned about. The process is repeated until, eventually, all nodes have learned routes to all subnetworks. Although effective, RIP can generate a lot of traffic and the router can spend a lot of time updating its tables. To resolve these difficulties, a new

Command

Version

Family ID

Route Tag IP Address Subnet Mask Next Hop Metric

Figure A.6

RIP 2 header.

Zero

206

Mobile IP Technology for M-Business

generation of routing protocols has been created called the link state protocols; the TCP/IP version is known as Open Shortest Path First (OSPF). During normal operations, routers simply exchange “hello” messages with their neighbors, to make sure the links are working well. These messages are short and use little bandwidth. Only if a hello handshake fails do the routers then enter a recalculation process, in which all routers will recalculate the network topology. When the network first starts up, a router broadcasts a message out of all of its interfaces to try to discover its neighbors. Once a router has done this, it will broadcast a neighbor list to all routers in the network. The router is now able to calculate a complete network map from the all the neighbor lists received. Only a failed link (or a new link added to the network) triggers a recalculation process. The knowledge of what is local and what is remote is usually preconfigured into gateways by system administrators. Gateways are also configured with routing information from more routing protocols. These protocols pass routing information between gateways to build routing tables that hold information on networks and the extent of their interconnection. These routing tables, like those above, do not hold end-to-end routes; they hold lists of which networks can be reached via their own. There are a number of these gateway protocols: the Gateway to Gateway Protocol (GGP), Exterior Gateway Protocol (EGP), Border Gateway Protocol (BGP), and Remote Gateway Protocol (RGP) are but a few. For more detailed explanations of addressing and routing, see Chapters 4 and 5, respectively. A.1.3

Mapping IP addresses to physical locations

IP datagrams are routed across networks using Internet layer protocols. When these datagrams reach their final destinations, the local networks on which the destination host resides, the network access layer protocols are able to route the datagrams directly to physical locations. The most common of these local networks, known as Ethernets, consist of a logical bus to which many users connect and contend for transmission capacity. The network access layer protocol that performs this function on Ethernet networks is known as the Address Resolution Protocol (ARP). ARP software uses a simple table in which IP addresses and their corresponding Ethernet addresses are stored. When a datagram, with associated IP address, is delivered to this software, ARP will look up its corresponding

The Internet Protocol, Versions 4 and 6

207

Ethernet address and route the datagram direct to the host. If the IP address does not have an entry in the table, it will broadcast a message to all the devices on the local network and wait for a reply. If one of the hosts on the local network receives a broadcast message containing its IP address, it will respond with its Ethernet address. The ARP software will then cache the IP/Ethernet address pair for the next time that it is needed. RARP is a variation on the ARP protocol and stands for Reverse Address Resolution Protocol. It is used by computers that do not have disks and, therefore, cannot store any static information about network addresses. Diskless workstations can, however, request network devices for an IP address providing they have an Ethernet address. Because Ethernet peripheral devices have hard-wired addresses, the diskless workstation can use RARP to request an IP address by trading its Ethernet address. A.1.4

Moving data from the network to the application

When data has been passed from your local application down to the network through TCP/IP, routed across the network, and passed to the host you have addressed, the data then has to pass back up through the TCP/IP software to the application with which you are communicating. The IP protocols will ensure that the data is delivered safely to the Internet layer, but then has to determine which transport layer protocol to give it to—TCP or UDP. Other transport layer protocols are also used for passing routing and control information. Because of this diversity of choice, each transport layer protocol has a number (defined in a configuration file), known as a protocol number. TCP is 6, UDP is 17, where the number is assigned by the Internet layer, to each datagram, according to the transport layer protocol that passed it down. When the Internet layer receives a datagram from a remote host it will examine the number and pass it up to the appropriate transport layer protocol. The transport layer faces the same problem when it needs to pass data up to the correct application process. Like transport layer protocols, applications have their own numbers, but these are called ports (not application numbers). Well-known applications, such as SMTP (25), Telnet (23), FTP (21), NNTP (119), and HTTP (80), have well-known numbers, and like the protocols these definitions are also stored in a configuration file.

208

Mobile IP Technology for M-Business

But what if an application wants to hold multiple sessions with multiple users? With a single port number, multiple users could potentially view each other’s data or actions during concurrent access to a single application process. In this scenario, the source port dynamically allocates a random port number to the source. This is then used by the destination port to uniquely identify the source. The combination of source and destination port numbers defines a unique network connection. In the example of simple terminal-host access, Telnet uses TCP to establish a connection-oriented session between two hosts. The combination of the IP address of the source host and the dynamically assigned port number is sometimes referred to as a socket, although the terms socket and port are often used to describe the same thing. The concept of the socket as an addressed communications channel is widely used. A development of the basic idea is the secure sockets layer (SSL), which provides secure transactions between a client and a server at the network access layer. Under SSL, the server is given a digital signature that allows a client to recognize a bona fide resource. It is rather like having a package delivered to a secured or secret P.O. box rather than to a residential address where others might lie in wait with evil intent. A.1.5

Naming and addressing

IP addresses are a simple and effective means of addressing individual computers on the Internet, but not as convenient as calling them names, or using a system to find a name for you if all you have is a string of 4 bytes separated by dots. The 4 bytes and dots convention is fine for machines but very awkward for people. A.1.6

Using names instead of IP addresses

Internet addresses, for all their charm, are cumbersome. They are difficult to remember and easier to get wrong when typing them into an application or configuration file. Enter the domain name system (DNS), which allows for the friendly assignment of names to numbers in the following form: 194.172.34.25 = host.network.domain These names and numbers are stored in a database and can be quickly and easily retrieved using a domain name resolver (DNR). When a new name is created it is entered into a local DNS database. This database does

The Internet Protocol, Versions 4 and 6

209

AM FL Y

not hold all the names registered on the Internet, only a few, relevant to its local domain and those remote hosts and networks most frequently accessed from the local domain. Any new name will be shared with a DNS primary name service so that all the Internet DNS information is shared beyond its local domains. Usually, a local DNS will have a primary DNS or authoritative server that it can refer to if the local DNS receives a name lookup request for a name it does not hold. The request will be passed from the local DNS, up a logical tree of DNS servers until the IP address, or name, is found. The requested information is then passed back down to the local server and cached for future use. This tree of DNS servers can be compared to the UNIX file system structure and is referred to as the domain hierarchy. At the topmost level are a group of servers referred to as the root servers. Below these are organizational and geographical domains. The domain hierarchy can be visualized as an inverted tree, with a single root at the top and multiple branches stemming downward. The use of two- and three-letter codes, to specify either a country of origin or an organizational affiliation, identifies those domains below the root level. The following list is not a complete list, but serves to illustrate the idea. Commercial organizations

mil

Military organizations

edu

Educational establishments

org

Organizations (such as charities and societies)

gov

Governmental institutions

net

Network support organizations (ISPs)

uk, nl, de

United Kingdom, Netherlands, Germany, respectively.

TE

com

And many other new identifiers (such as .tv) are now becoming available. It is interesting to note that the United States does not have a .us code to denote an organization in the United States. This is because they invented the concept (rather like the United Kingdom did for postal service) and use .com, .mil, .edu, .org, .gov, and .net. although most of the U.S. local government organizations use the “.us” convention, (e.g., [email protected]). However, there is a growing trend on the Internet to present yourself as a global entity and more and more commercial

210

Mobile IP Technology for M-Business

organizations are choosing to drop their country code in preference for a .com suffix on their domain name. All sorts of variations are occurring within local country domains; here are a few: .co.uk

Commercial organizations within the United Kingdom

.ac.uk

Academic establishments within the United Kingdom

.org.uk

Noncommercial organizations in the United Kingdom

.nhs.uk

The National Health Service in the United Kingdom

The subdivision of names and numbers by the decimal point or dot does not imply any relationship. The IP address is always 4 bytes separated by dots. An IP address may have many (aliased) domain names associated with it. For example, two domain names, “pin.orion.nn.co.uk” and “preside.lvlnk.nn.co.uk,” may both point to the same physical host.

A.2

IP Version 4 limitations and constraints

The current version of the Internet Protocol, IPv4, does have the capability for more than 4 billion addresses, which might sound more than adequate. But it is not so much the number of addresses that is a problem as it is the way in which IPv4 groups bits for its network/host numbering system. IPv4’s numbering system wastes address assignments and suffers from excessive routing overhead. To illustrate these problems, we need to explain how IPv4 assigns addresses and how that affects IP routing tables. IP addressing is based on network number assignment and host number assignment. In IPv4, these numbers are organized as 32-bit addresses, with host numbers and network numbers embedded in the addresses. These numbers identify the network or host connection and not the actual network or computer. As we said earlier, IPv4 divides its address assignment into three main classes: A, B, and C. To recap: ◗

Class A addresses assign the first 7 bits (or 1 byte) to a network and the last 24 bits (or 3 bytes) to a host. These addresses are reserved for organizations that have up to 16,777,216 hosts, and there can be at most 127 of these networks.

◗

Class B addresses assign the first 14 bits (or 2 bytes) to a network and the last 16 bits (or 2 bytes) to a host. These addresses are reserved for

The Internet Protocol, Versions 4 and 6

211

organizations that have up to 65,536 hosts, and there can be at most 16,382 networks. ◗

Class C addresses assign the first 21 bits (or 3 bytes) to a network and the last 7 bits (or 1 byte) to a host. These addresses are reserved for organizations that have less than 256 hosts, and there can be at most 2,097,152 networks.

The address class determines the network mask of the address. A network mask is a 32-bit Internet address that has all the bits in the network number set to one and all the bits in the host number set to zero. Hosts and routers use the network mask to route Internet packets. Table A.2 lists the decimal value of each address class and its corresponding network mask. With more than a hundred address classes that can support many thousands of hosts and many thousands that can support hundreds, it might seem like enough to serve everyone in the world who needs an IP address. It probably would be, if it weren’t for the way that IPv4 handles the addresses within each of these classes. To illustrate the issue, let’s look at a company that needs 300 host addresses. This amount would put them into the class B category. However, if the company is assigned a class B address, then they would have 65,536 hosts, which is significantly more than they need. About 65,000 addresses would be wasted. To alleviate this type of situation, the classless interdomain routing (CIDR) scheme was introduced a few years ago. CIDR essentially eliminates the class structure of addressing and, instead, allows the assignment of network numbers at any bit boundary. In this way network numbers can be created, for example, by aggregating several contiguous class C addresses. CIDR requires that network masks be explicitly specified when needed, rather than allowing them to be implicitly derived from the address (as in the class system). Table A.2 Internet Address Classes and Network Masks Class

First Byte

Network Mask

Network Mask

A

1. — 127.

11111111.00000000.00000000.00000000

255.0.0.0

B

128. — 191.

11111111.11111111.00000000.00000000

255.255.0.0

C

192. — 223.

11111111.11111111.11111111.00000000

255.255.255.0

212

Mobile IP Technology for M-Business

Another problem attributed to IPv4’s address classes is the Internet backbone router table size explosion. CIDR also addresses this by allowing for address aggregation, which means that fewer spurious addresses are advertised by routers. CIDR has helped, but the basic problem of address exhaustion, based on the limited IP address field, is still there. Furthermore, a negative aspect to CIDR is that with an arbitrary address, you cannot determine the network and host numbers unless you know the network mask. Hence, the limitations of IPv4 are quickly being realized, and measures, such as CIDR, have only extended its life slightly. Worldwide network demand is driving the need for IPv6, so the next section describes how it is being developed and what features it will bring to the Internet.

A.3

IP Version 6 development and features

Various groups within the Internet community have been working on the next version of the Internet Protocol since the early 1990s. The brief for these groups was to develop a protocol that not only addresses the known limitation of IPv4 but also supports a multimedia environment, rich in applications. The advent of complex client/server environments and intranets in the corporate world makes support for these applications a must. The resulting design of IPv6 has therefore focused on three key areas: addressing, performance, and security. We now look at each of these in turn. A.3.1

Addressing

IPv6 uses a 128-bit addressing scheme, which increases address space by a factor of 296! According to one IPv6 paper, this should provide for “adequate addressing capability for any network limited to this planet.” By using 128 bits rather than 32 bits as IPv4 does, IPv6 increases address space by a billion times a billion times a billion times. A comparison of this increase translates to: IP Version

Size of Address Space

IPv4

32 bits = 4,294,967,296

IPv6

128 bits = 340,282,366,920,938,463,463,374,607,431,768,211,456

The Internet Protocol, Versions 4 and 6

213

But what is as important as the address space is how the addresses are allocated. IPv6 assigns addresses in a hierarchical manner, as needed by the requester, rather than in blocks that have unused addresses, as IPv4 does. In this hierarchical scheme, an upper authority subdivides its address allocation to a lower authority, which can subdivide its address allocation to the next lower authority, and so forth. Currently, most addresses are assigned by network providers. With IPv6, addresses are not centrally allocated and only one prefix (010) is for network provider allocations. The address classes of IPv6 also meet the needs of the user community more directly than IPv4. There are basically three types of network users: (1) ones who use an organization’s intranet and the Internet; (2) ones who use only their company’s intranet at this time, but might connect to the Internet in the future; and (3) individuals who connect to the Internet via telephone lines from home, airports, hotels, or anywhere else. IPv6 provides a better way of servicing these kinds of users by offering three address types: ◗

Four categories of unicast addresses;

◗

Improved multicast address format;

◗

The new anycast address format.

The IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces. Unicast addresses

Unicast addresses identify a single interface. Packets sent to a unicast address are delivered to the interface identified by that address. The four types of unicast addresses are explained next. 1. Provider-based, which provides global addressing to all connected hosts. For example: Bits

3

n

m

o

p

125-n-m-o-p

010

Registry ID

Provider ID

Subscriber ID

Subnet ID

Interface ID

214

Mobile IP Technology for M-Business

2. Local use, which includes link-local for addressing on a single link (physical network) or subnetwork, and site-local designed for local use that can later be integrated into global addressing. Here is an example of link-local: Bits

10

n

118-n

1111111010

0

Interface ID

Here is an example of site-local: Bits

10

n

m

118-n-m

1111111011

0

Subnet ID

Interface ID

3. IPv4 compatible, which provides compatibility between IPv4 and IPv6 until a complete transition is attained. For example: Bits

96

32

0000 FFFF

IPv4 Address

4. Loopback, which sends an IPv6 packet to itself. These packets are not sent outside a single node. For example: Bits

96

32

0000 0000

0001

The interface is the system’s Ethernet, FDDI, or token-ring MAC (48-bit) address. Multicast addresses

Multicast addresses identify a set of interfaces that usually belong to different nodes. Packets sent to a multicast address are delivered to all interfaces identified by that address. This is useful in several ways, such as sending discovery messages only to the machines that are registered to receive them. A particular multicast address can be confined to a single system, restricted to a specific site, associated with a particular network

The Internet Protocol, Versions 4 and 6

215

link, or distributed worldwide. Note that IPv6 has no broadcast addresses and uses multicasting instead. For example: Bits

8

4

4

112

11111111

Flags

Scope

Group ID

Anycast addresses

Anycast addresses are new to IP technology with this version of the protocol. This kind of address identifies a set of interfaces, usually belonging to different nodes. A packet sent to an anycast address is delivered to one of the interfaces identified by the address. This is usually the nearest interface, and is determined by how the router measures distance. This makes routing more efficient because the address itself can specify intermediate hops en route to a destination, rather than having the router determine the route. For example: Bits

A.3.2

n

128-n

Subnet prefix

0000 0000

Performance

Network performance is directly related to routing. The amount of traffic that leaves the local network (external traffic) compared to the amount of traffic that occurs on the network is constantly increasing. This is due in part to the demand for more services, especially graphics-based services. Speeds for LANs and WANs have also increased to hundreds of megabits per second, with gigabit networks not far in the future. Routers need to perform their functions of processing and forwarding IP datagrams much quicker than before. An IPv6 packet header has fewer fields than does an IPv4 header. To increase the speed at which a packet travels past a router, separate optional headers are placed between the IPv6 header and the transport layer header. Most of these are not examined or processed by routers along the packet’s path, which simplifies and speeds up router processing. Additional optional headers are also easier to add, making IPv6 more flexible than IPv4. Because the IPv6 packet header has a fixed length, processing is also simplified. IPv6 does not fragment packets as they are routed as IPv4 does. Instead, packet fragmentation and reassembly are done exclusively in the

216

Mobile IP Technology for M-Business

communicating hosts, thus reducing the workload for intermediate routers. When the transition to IPv6 is complete, the Internet will consist of only networks with maximum transmission units (MTUs) equal to or larger than 576 bytes. Performance with IPv6 will be optimized by the use of flow labels. The flow source specifies in the label any special service requirements from routers along a path, such as priority, delay, or bandwidth. All packets in the sequence carry the same details of this information in the flow label to reserve the type of service they need from intermediate routers. Such a need would be for transmitting video or for limiting traffic a specific computer or application sends to avoid congestion. With IPv6, a flow can be one or multiple TCP connections, and a single application could generate a single flow or multiple flows. An example of a single flow would be a text page, and an example of a multiple flow would be an audiovisual conference. Packets that share a flow label also share path, resource allocation, discard requirements, accounting, and security attributes. The flow label is defined before transmission. A.3.3

Security

As the Internet has grown in popularity and use, the reasons for its use have changed and increased. More and more, users want to know that their transactions and access to their own sites are secure. Users also want to increase security across protocol layers. Up until IPv6, security has been available only by adding applications or services. IPv6 provides security measures in two functional areas, authentication and privacy. Authentication requires that a sender log into the receiver. If the sender is not recognized, then access is not allowed. If access is allowed, this ensures that the packets were actually sent by the approved sender and that the content was not changed in transit. Privacy takes the form of encryption and protects data from unintended users. Packets that leave a site can be encrypted and packets that enter a site can be authenticated. Both privacy and authentication can be applied in a “security association.” For a one-way exchange between a sender and a receiver, one association is needed; for a two-way exchange, two associations are needed. When combining authentication and privacy, either can be applied first. If encryption is applied first, the entire packet is

The Internet Protocol, Versions 4 and 6

217

authenticated, including encrypted and unencrypted parts. If authentication is applied first, authentication applies to the entire packet. A.3.4

Autoconfiguration

Configuring IPv4 systems has traditionally been difficult and problematic. IPv6 offers two-way computer systems and personal electronic products that configure themselves automatically: stateful and stateless. With stateful autoconfiguration, servers can dynamically assign unique addresses to computers as they are requested, getting the addresses from a database of preallocated values. With stateless autoconfiguration, IPv6 nodes can generate globally unique addresses by concatenating the link-local address of the network connection they are using with an internal interface number, such as an Ethernet or a token-ring MAC address. Much planning, testing, and more testing has gone into the development of IPv6 to ensure that use of the Internet is interrupted as little as possible—in creating the next-generation Internet Protocol, the IETF has paid close attention to the transition path from IPv4 to IPv6. The immense size of the Internet, and thus all the users of IPv4, makes an overnight change impossible. And no user can afford any downtime caused by waiting to upgrade. For these reasons, the transition to IPv6 will be done on a node-by-node basis. Autoconfiguration helps in this by eliminating the need for human intervention to configure systems. Some features of IPv6 are compatible with IPv4, which will help ease the transition. For example, IPv4 addresses can be embedded within IPv6 addresses, and all IPv6 nodes, at least for the time being, also support IPv4. Packets for IPv6 can be embedded within IPv4 packets so tunneling through parts of the network that support only IPv4 is possible.

A.4

Impact of IP Version 6 on mobile data

The support for mobility in IPv6 follows the design for Ipv4. Hence, the ideas of home network, home agent, and the use of encapsulation to deliver packets from the home network to the mobile node’s point of attachment—the care-of address—are all retained. We still need to determine the care-of address, but with IPv6 a mobile node can configure its

218

Mobile IP Technology for M-Business

own using stateless address autoconfiguration and neighbor discovery. This means that foreign agents do not have to support mobility. Three areas, known to be a problem when using IPv4, are significantly impacted by the introduction of IPv6. These are security, route optimization, and source routing. Taking each of these in turn, we now highlight the differences. A.4.1

Security

Perhaps the biggest difference between IPv4 and IPv6 is that all IPv6 nodes are expected to implement strong authentication and encryption. This means that mobility support with IPv6 can be that much simpler because all authentication procedures can be assumed present. They do not have to be specified as a specific requirement for mobility. A point made in the chapter that relates to security was that authentication is a complex procedure and one that consumes processor power. Hence, the routine use of certificates, keys, and so on, can have an effect on performance. For this reason, the current recommendation is that authentication procedures should be carried out as infrequently as possible. A.4.2

Route optimization

The techniques for optimizing routes and prevention of “tromboning” were explained in Chapter 3. IPv6 builds on these ideas, in particular, the use of binding updates directly to correspondent nodes. This means that, when it knows what the current care-of address of a mobile node is, a correspondent node can deliver packets directly to the mobile node’s home address, without any assistance from the home agent. There are two reasons why route optimization is likely to be a feature on all IPv6 nodes. First, processing binding updates can be implemented as a simple modification to the way in which IPv6 uses its binding cache. Second, because, IPv6 has yet to be widely deployed, requirements that support efficient mobile use can readily be included, with every expectation that there will be a standard implementation feature. A.4.3

Source routing

In IPv6 correspondent nodes do not tunnel packets to mobile nodes. Instead, they use IPv6 routing headers, which implement a variation on the IPv4 source routing option. This alternative way of specifying route optimization would not have worked in IPv4 because its source

The Internet Protocol, Versions 4 and 6

219

TE

AM FL Y

routing options require the receiver of source routed packets to follow the reversed path to the sender back along the stated intermediate nodes. This would, in the absence of strong authentication, allow a malicious node to use source routes from remote locations to impersonate other nodes. Also, in practice, routers do not handle source routes well and they tend to have a strong negative impact on performance. In IPv6 these problems go away because there is no need for source route reversal. And so correspondent nodes can use routing headers without penalty, allowing the mobile node to easily determine whether or not the correspondent node has the correct care-of address. Packets that are sent by encapsulation, instead of by source routes in a routing header, can only have been sent by a correspondent node that needs to receive binding updates from the mobile node. Last, because key management is more likely to protect a dialogue between mobile and correspondent nodes, the former can deliver binding updates directly to the latter instead of going through the home node. One final point should be made about IPv6 in general and its support for mobility in particular. Because of its widespread acceptance and long established use, IPv4 is very much the dominant protocol at present. This situation is likely to persist for some time yet; for all its merits, IPv6 is unlikely to be the Internet default for some time. In addition, the specification for IPv6 is not static. Features that will allow hierarchical agents, better tunneling protocols, and more efficient ways of address registration are all subjects of current work. This appendix has highlighted the main areas of difference between the current and emerging version of IP. The devil lies in the detail and that (very fittingly) is mobile.

Selected bibliography All of the standards that relate to the Internet are contained in a series of documents known as Requests for Comment, or RFCs. These are available online from http://www.ietf.com. Some of the more detailed RFCs that relate to IPv6 are listed here: RFC 1809, Using the Flow Label in IPv6. RFC 1825, Security Architecture for the Internet Protocol. RFC 1826, IP Authentication Header. RFC 1827, IP Encapsulating Security Payload.

220

Mobile IP Technology for M-Business

RFC 1881, IPv6 Address Allocation Management. RFC 1883, Internet Protocol, Version 6 Specification. RFC 1884, IP Version 6 Addressing Architecture. RFC 1887, An Architecture for IPv6 Unicast Address Allocation. RFC 1933, Transition Mechanisms for IPv6 Hosts and Routers.

Appendix B Short-range interconnection technology The longest march starts with a single step. —Mao Tse-tung

O

ne of the basic assumptions throughout this book has been that the user’s mobile device connects directly to a national (or international) network. This may well be the predominant modus operandi with most mobile data applications, but we should consider another angle: the use of a short-range link to a hub of some description. If the hub is a server, users may get what they want locally (and avoid paying for a network connection). If the hub is a switch, they can use it to connect to remote applications. We will discuss the two distinct types of short-range interconnection technologies. The first short-range technology is the wireless local-area network (WLAN), leading examples of which are HiperLan II and IEEE 802.11. The second is the proximity or personal access (PAN) technologies, named Bluetooth and IrDA. PANs replace the wire mess that adorns many offices and homes, but WLANs are somewhat larger in scale and capability. Because we have thus far focused on the roaming individual, this appendix considers only the PAN option.

221

222

Mobile IP Technology for M-Business

Two technologies lead the way in providing short-range (around 10m) wireless connectivity. These are IrDA, after the Infrared Data Association, and Bluetooth, named after Harald Bluetooth, an ancient Danish lord who united his people. At first glance, the two appear to compete with each other in the marketplace, and industry analysts have openly wondered whether both technologies can survive. But close examination of the benefits of each technology reveals that each has its strengths, neither can meet all user needs, and both are critical to the marketplace. IrDA uses an infrared beam to provide wireless connectivity technologies for devices that would normally use cables. It is a point-to-point, narrow-angle (30-deg cone), ad hoc data transmission standard designed to operate over distances up to a few meters and at speeds of 9,600 bps to 16 Mbps. It has an installed base of more than 50 million units (growing at 40% per annum) and a wide range of supporting hardware and software platforms. Bluetooth is a radio-frequency (RF) specification for short-range, point-to-multipoint voice and data transfer. Bluetooth can transmit through solid, nonmetal objects. Its nominal link range is from 10 cm to 10m, but can be extended to 100m by increasing the transmit power. It is based on a low-cost, short-range radio link, and facilitates ad hoc connections for stationary and mobile communication environments. An ad hoc networking technology such as Bluetooth is one in which there is some kind of “discovery” functionality that enables terminals to find each other and form local networks among themselves without direct intervention from the users. Bluetooth operates in the 2.4-GHz industrial-scientificmedical (ISM) band and uses frequency hopping (FH) spread-spectrum radio techniques to divide the frequency band into a number of hopping channels so that radio transceivers can hop from one channel to another in a pseudo-random fashion during transmission. Because many radio channel problems tend to be frequency selective, frequency hopping improves the radio channel performance by adding frequency diversity gain to it. It is unlikely that a problem on one channel will appear on another RF channel at the same time. Bluetooth supports up to eight devices in a piconet (two or more Bluetooth units sharing a channel), is omnidirectional (unlike IrDA), and supports both isochronous and asynchronous services. The former use a reference clock, whereas the latter rely on start and stop bits to delineate characters.

Short-range interconnection technology

223

In this appendix, we briefly compare IrDA and Bluetooth. The key message here is that each has its strengths and weaknesses and the choice between them would depend on the application and circumstances. To complete the appendix, more detailed explanations of the two technologies are given.

B.1

Technologies compared

There is little doubt that the application opportunities of Bluetooth and IrDA overlap. Many of the applications defined for IrDA are also defined for Bluetooth. Yet, in many situations and conditions, IrDA is better suited for transmitting data than Bluetooth and vice versa. By way of example, both IrDA and Bluetooth consider data exchange to be a fundamental function. Data exchange can be as simple as pushing a business card from a mobile phone to a personal digital assistant (PDA) or as sophisticated as synchronizing personal information between a PDA and a PC. Bluetooth and IrDA specify both of these applications as well as other data exchange applications. Both technologies use the same upper layer protocol (OBEX) to implement these applications. IrDA and Bluetooth intend to utilize the same data exchange applications when appropriate. By using the same upper level protocol, a single application can run over both Bluetooth and IrDA. The reader may wonder, if IrDA and Bluetooth support the same applications, why we have both technologies. The answer lies in the fact that each technology has its strength and weaknesses. And, fortunately, the very scenarios where IrDA falls short are the ones in which Bluetooth excels and vice versa. This is an example of a universal theme in wireless technologies: Each technology tends to have its own advantages. To the extent that we try to make a wireless technology serve the needs of everyone in all circumstances, we end up serving nobody’s needs particularly well. Though this kind of selectivity is evident in all kinds of connection technologies, it is particularly evident in wireless ones. A common data exchange scenario is one in which the exchange will take place in a room containing a number of other devices. An example is electronic business card exchange. Two people meet to exchange business cards, face to face, in a large conference room. Many other people

224

Mobile IP Technology for M-Business

carrying wireless devices are also present in the room, possibly attempting to do the same thing. This is an application for which IrDA is ideally suited. The shortrange, narrow angle of IrDA allows the user to aim, in a point-and-shoot style at the intended recipient. Proximity to the other person is natural in a business card exchange situation, as is pointing one device at another. The limited range and angle of IrDA allows others to be performing a similar activity without interference. The short range and narrow angle of IrDA provides a simple form of security and a natural ease of use. This same situation is a weakness for Bluetooth. With its omnidirectional characteristic, Bluetooth has problems discovering the intended recipient. It does not allow the user to simply point at the intended recipient. A Bluetooth device must perform a time-consuming discovery operation that will find many of the other devices in the room. Proximity to the intended recipient will not help. The user will be forced to choose from a list of discovered devices. Choosing the proper device will probably require special information from the other person (e.g., 48-bit device address or friendly name). Also, Bluetooth has multipoint capabilities and therefore utilizes security mechanisms to prevent unauthorized access. The two users attempting to perform a business card exchange using Bluetooth would also need to execute security measures. In other data exchange situations, Bluetooth is the obvious choice. Bluetooth’s ability to penetrate solid objects and its capability for maximum mobility within the piconet allows for data exchange applications that are very difficult or impossible with IrDA. For example, with Bluetooth a person could synchronize her phone with a PC without taking the phone out of her pocket or purse (this is not possible with IrDA). The omnidirectional capability of Bluetooth allows synchronization to start when the phone is brought into range of the PC. Using Bluetooth for synchronization does not require that the phone remain in a fixed location. If the phone is carried in the person’s pocket, the synchronization can occur while the person moves around. With IrDA, the phone must be placed in the proper location and remain stationary while the synchronization executes. In many other instances, IrDA and Bluetooth are also complementary. For some devices, having both Bluetooth and IrDA will provide the best short-range wireless solution. For other devices, the choice of adding Bluetooth or IrDA will be based on the applications and intended usage models. The story on short-range wireless communication technology is

Short-range interconnection technology

225

still being written and IrDA and Bluetooth will be the major forces driving this area. Table B.1 shows a quick comparison of the two technologies.

B.2

Bluetooth

Bluetooth is a de facto open standard for short-range digital radio. It is designed to operate in the unlicensed ISM band, which is generally available in most parts of the world (see Table B.2). The specification includes air interface protocols to allow several Bluetooth applications to intercommunicate simultaneously and to overcome external sources of interference such as domestic washing machines and commercial microwave ovens. The short range referred to above is defined as up to 10m in normal operation although greater range/penetration can be achieved through higher output powers under some circumstances. The goal of the promoters of Bluetooth is to enable the intercommunication of just about any piece of apparatus with any other (where this is appropriate of course!) and consequently one of the main constraints on Table B.1 Comparison of Bluetooth and IrDA Wireless Technologies Technology

Maximum Bandwidth

Comments

Bluetooth

1 Mbps (gross rate)

Packet oriented for data applications, maximum full-duplex data rate is 432 Kbps, arranged as 64-Kbps channels for speech.

IrDA

4 Mbps

Very cheap (now around $1 to $2 per installation), low range (~1m) and line of sight only.

Table B.2 Operating Bands for Bluetooth Area

Frequency Band (GHz)

Bluetooth Channels

United States, Europe, and most 2.400–2.4835 other countries

79

Spain

2.445–2.475

23

France

2.4465–2.4835

23

226

Mobile IP Technology for M-Business

the design must be cost. When the infrared interface, common on mobile phones and PCs today, was conceived, the designers knew that to persuade equipment manufacturers to implement this interface, the cost of implementation had to be low. The target cost, set at $5, was achieved and more than 90% of portable PCs and an increasing number of mobile phones now have a built-in IR interface. A sophisticated radio interface is more complicated (and more flexible) than the IR interface and therefore more expensive. The price target of $10 per unit, however, seems to be realistic especially if all our homes will eventually have half a dozen or so Bluetooth-equipped items operating in them, driving quantities to very high numbers. In addition to cost, size matters. With ever-decreasing form factors and weight, any new addition to a piece of electronic apparatus must be small, lightweight, and consume minimum power from the host system or separate battery. The Bluetooth implementation is feasible in a very small footprint comprising a single chip and associated RF components, and should be relatively easy to install in anticipated applications. Its low output power and sophisticated power conservation design ensure minimum power consumption. Bluetooth has the potential for impacting many areas, including applications that would have been inconceivable a few years ago, for example, a refrigerator-freezer telling a microwave oven what ingredients are available, allowing the microwave to suggest menu options! However, one particular area where Bluetooth will have a significant impact is in the support of other wireless delivery mechanisms such as cellular telephony. While national networks are suited to delivering communication on the move or wireless to any location, purely local interconnection is better handled by a local communication system, the so-called “complementary wireless network” concept. To deliver telephony-based services from one undefined location to another and to distribute the services and functions at those locations, a hybrid solution is required. At the core of this hybrid solution is a cellular handset with a built-in Bluetooth transceiver. Bluetooth is able to interconnect simultaneously up to eight transceivers in a piconet over a short range. Each Bluetooth transceiver costs the same (~$10), and no infrastructure is required. The simultaneous connectivity limit of eight devices may seem to be a serious constraint; however, several piconets can operate in proximity and Bluetooth devices can rapidly move from one piconet to another. In fact, Bluetooth devices need only remain a member of a piconet for the period of time

Short-range interconnection technology

227

required to complete a communication transaction. So devices can join and leave a local piconet frequently, effectively overcoming the eightdevice constraint. When two piconets are interconnected, they form a scatternet. They are able to operate within the vicinity of each other because they are using different hopping sequences, reducing mutual interference to an acceptable level. In this way it is possible to have several small groups of Bluetooth devices communicating with each other in the same area, which is particularly useful at a conference where, for example, individuals may be comparing notes while the main discussion points are being broadcast to all. Devices communicating using Bluetooth can transmit and receive up to 1 Mbps, though in reality to allow multiple applications to communicate simultaneously, data rates will be somewhat lower than this. Bluetooth devices that are not currently part of a piconet are constantly “listening” for other Bluetooth devices, and when they are close enough to become part of a piconet, they identify themselves so that other devices can communicate with them if required. An example would be a Bluetooth-equipped printer and notebook PC. When the PC comes into range of the printer (arriving at the office, for example), the printer makes itself known to the PC so that if and when the user wishes to print a document, the two devices can immediately begin the data transfer. Meanwhile other PCs will have joined the piconet so that they too can use the printer when required.

B.3

IrDA

IrDA devices conforming to standards IrDA 1.0 and 1.1 work over distances up to 1.0m with a BER (bit-error ratio, the number of incorrectly transferred bits over the number of correctly transferred bits) of 10–9 with the maximum level of surrounding illumination of 10 klux (daylight). Values are defined for a 15-deg deflection (off-alignment) of the receiver and the transmitter; output power for individual optical components is measured at up to 30 deg. Directional transmitters (IR LEDs) for higher distances exist; however, they do not comply with the required 30-deg radiation angle. Speeds for IrDA version 1.0 range from 2,400 to 115,200 Kbps. Pulse modulation is employed with 3/16 of the length of the original duration

228

Mobile IP Technology for M-Business

of a bit used and the data format is the same as for a serial port: asynchronously transmitted words, with a start bit at the beginning of each word. A transmitter can use either the 3/16 mark-to-space ratio for 1 bit, or a fixed-length 1.63ms optical pulse, which corresponds to 115 Kbps. With fixed length and a speed of 38,400 bps, each bit takes three pulses. In addition, IrDA version 1.1 defines speeds of 0.576 and 1.152 Mbps, with a 1/4 mark-to-space ratio. At these speeds, the basic unit (packet) is transmitted synchronously, with a starting sequence at the beginning. The reason why IrDA uses pulse modulation is interesting. Clearly, the receiver needs a way to distinguish between the surrounding illumination, noise, and received signal. For this purpose, it is useful to use the highest possible output power: Higher power leads to higher current in the receiver, which, in turn, gives a better signal-to-noise ratio. However, IR-LEDs cannot transmit at full power continuously over 100% of the time. So, a pulse width of only 3/16 or 1/4 (mark-to-space ratio) of the total time for 1 bit is used. So, the power can be up to four or five times the possible maximum power for LEDs shining continuously. An IrDA packet consists of two start words followed by the target address (devices are assigned numbers by means of the IrDA protocol, so they are able to identify themselves unambiguously), followed by the data, CRC-16, and a stop word. The whole packet (frame) including CRC-16 is generated by an IrDA-compatible chipset. Start and stop words cannot appear anywhere else in the data stream. Start and stop words last 1.5 times the bit duration. For 4-Mbps speed, so-called 4PPM (pulse position modulation) with 1/4 mark-to-space ratio is used. Two bits are encoded in a pulse within one of the four possible positions in time. So, information is carried by the pulse position, instead of the pulse existence as in many other modulations. For example, bits 00 would be transmitted as a sequence 1000 (flash–nothing–nothing–nothing), bits 01 would be 0100, bits 11 would be send as 0001. The reasoning behind the 4PPM modulation is that only half of the LED flashes are needed (compared to other modulation schemes) so data can be transferred twice as fast. In addition, it is easier for the receiver to deal with the level of the surrounding illumination with the 4PPM modulation as a constant number of pulses is received within a given time. IrDA defines a low-power device, with range up to 20 cm and a maximum speed of 115 Kbps. The limiting factor for the range is the

Short-range interconnection technology

229

radiation intensity at the receiver. This value is higher for faster bit speeds but increases for the slower bit speeds (long pulses). IrDA devices use a number of protocols. The main ones are discussed next. IrDA Infrared Link Access Protocol (IrLAP)

AM FL Y

IrLAP is a modification of the HDLC protocol that reflects the needs of IrDA communication. In general, it encapsulates the frames and makes sure the IrDA devices do not fight among themselves—in multiple-device communication, there is only one primary device, others are secondary. IrLAP describes how the devices establish a connection, close it, and how they are going to be internally numbered. Connection starts at 9,600 Kbps; as soon as information about the supported speeds is exchanged, logical channels (each controlled by a single primary device) are created. IrDA Infrared Link Management Protocol (IrLMP)

TE

As the configuration of an IrDA device changes (e.g., you turn on your IrDA camera and then put it next to your notebook), each device lets the others know about itself via the IrLMP protocol. This runs above IrLAP (the link protocol described above). IrLMP’s goal is to detect the presence of devices offering a service, to check data flow, and to act as a multiplexer for configurations with more devices with different capabilities involved. Then, applications use the IrLMP layer to ask if a required device is within range and so forth. However, this layer does not define a reliable way to create a channel; IrDA transport protocols (Tiny TP) define this. IrDA Transport Protocols (Tiny TP)

This layer manages virtual channels between devices, performs error corrections (lost packets, etc.), divides data into packets, and reassembles the original data from packets. It is similar in function to TCP. IrDA Object Exchange Protocol (IrOBEX)

A simple protocol, built on top of Tiny TP, that defines PUT and GET commands, thus allowing binary data transfer between devices. The standard defines what a packet must contain in order for the devices to recognize each other and communicate.

230

Mobile IP Technology for M-Business

Extensions to IrOBEX for IR mobile communications

This extension of IrOBEX for mobile devices—handhelds, PDAs, cellular phones—defines how to transfer information pertaining to the GSM network (SMS, dialing control, etc).

B.4

Summary

Bluetooth and IrDA are complementary technologies that provide shortrange data links. Both can be used to supplement the range of mobile data services, and their relative merits and limitations are explained in this appendix.

Selected bibliography Bluetooth main reference: http://www.bluetooth.com. Infrared Data Association: http://www.irda.org. Muller, N., Bluetooth Demystified, New York: McGraw Hill, 2000.

Appendix C The third-generation mobile network If you open that Pandora’s box, you never know what Trojan Horses will jump out. —Ernest Bevin

T

he capabilities of a mobile network clearly have significant bearing on the type of mobile data services that can be offered. The early GSM networks could only support 9.6-Kbps data channels, and the resulting data services were generally seen as too slow and cumbersome. The advent of GPRS has kindled new interest in mobile data services because it provides a technical route for delivering useful services (as explained in the main text) and the prospect of reasonable access speeds (50 Kbps plus—enough to make working with mobile data a pleasurable and satisfying experience for the user). The evolution of the mobile network into its “third generation” holds the promise of higher speed access and more easily integrated data services. Universal Mobile Telecommunications Service (UMTS) is one of the major new third-generation mobile systems being developed within the framework that has been defined by the International Telecommunication Union (ITU), known as IMT-2000. It has been the subject of intense worldwide research and development efforts during the 1990s and is

231

232

Mobile IP Technology for M-Business

seen by major telecommunications operators and manufacturers as the key to high value, personalized mobile services. The perceived importance of third-generation mobile networks is readily illustrated by the $36 billion offered (against an expected $7.5 billion) for the five U.K. operator licenses. This appendix takes a brief look at UMTS and the services that it is likely to support.

C.1

A brief guide to UMTS

The World Radio Conference has identified the frequency bands of 1,885 to 2,025 MHz and 2,110 to 2,200 MHz for future IMT-2000 systems. Of these the bands 1,980 to 2,010 MHz and 2,170 to 2,200 MHz are intended for the satellites employed in these future systems. Europe and Japan have decided to implement the terrestrial part of UMTS (the Universal Terrestrial Radio Access or UTRA air interface) in the paired bands of 1,920 to 1,980 MHz and 2,110 to 2,170 MHz. Europe has also decided to implement UTRA in the unpaired bands of 1,900 to 1,920 MHz and 2,010 to 2,025 MHz. In the United States, the potential candidate bands for third-generation technologies are the PCS bands, the WCS bands, and parts of the UHF TV bands. At launch, terrestrial UMTS will have the capability for data rates up to 2 Mbps, but it is designed as an open system that can evolve to incorporate new technologies as they become available. This will allow UMTS to eventually increase its capability above that currently being standardized, in much the same way that GSM has evolved from the original capability of 9.6 Kbps for data to the GPRS speeds (up to 115 Kbps) and then to a stepping stone to UMTS known as enhanced data rates for GSM/global evolution, or EDGE technology (which offers 384 Kbps). Like GPRS, UMTS integrates packet and circuit data transmission. The packet data over-the-air transmission gives the same sort of benefits to users that GPRS offers: virtual connectivity to the network at all times, alternative ways of billing (for example pay per bit, per session, or flat rate per month), and asymmetric bandwidth in the uplink and downlink (which suits video transmission, etc.). UMTS is also being designed to offer data rate on demand, where the network reacts flexibly to the user’s demands, her profile, and the current status of the network.

The third-generation mobile network

C.2

233

Perspectives on the third generation

The technical promises of UMTS and the like are more or less universally accepted. That is not to say that consensus has been reached on how third-generation networks will be deployed. A number of areas are still the subject of active debate. First, with so much investment in each of the various secondgeneration technologies, the evolution path to the third generation (3G) is not clear. Two central European suppliers, Alcatel and Siemens, are both very GSM centric, so they see this as the baseline for progress. However, other suppliers see it rather differently, because the secondgeneration standards in the United States are time division multiple access (TDMA) and code division multiple access (CDMA). Motorola has a foot in both the GSM and CDMA camps, while Ericsson is split between GSM and TDMA/CDMA. Very closely related to the question of how the path to 3G is defined is the extent to which different versions of 3G will be backwardly compatible with the established technologies of GSM, TDMA, and CDMA. The Japanese approach to the problem is to build a separate 3G network and not allow 3G users to roam onto 2G networks. The approach elsewhere is not yet clear. One final point on the likely nature of 3G is what its primary purpose should be. Some see the technical capability to deliver streamed video to mobile devices as the key driver. Others see the migration as one that is needed to reduce the cost and maximize the flexibility of the mobile network infrastructure. The range of services developed for 3G networks is likely to be wider if the first view prevails.

C.3

Migrating to the third generation

In the previous section, the point was made that there are several views on how best to get to 3G. We give a little more background to this now by explaining the options for migration (or possibly, emigration, if there is no intent to provide a return route to 2G). C.3.1

From GSM

Three sets of acronyms are used to designate the 3G target from GSM: IMT-2000, UMTS, and WCDMA. The first two have already been introduced, and the third refers to a wideband version of CDMA that will

234

Mobile IP Technology for M-Business

occupy a 5-MHz radio-frequency channel. Both UMTS and IMT-2000 use the 1.9- to 2.1-GHz spectrum. It is intended that each of the 3G targets be backward compatible with existing GSM networks. C.3.2

From CDMA

The 3G derivative of CDMA is known as CDMA2000 but, despite being branded as “one of the IMT-2000 family” it does not operate in the 1.9- to 2.1-GHz range. The point of convergence between CDMA evolution and GSM is that CDMA2000 uses three carriers of 1.25 MHz, which combine to fill a 5-MHz carrier. As a result, it is known as the multicarrier mode of WCDMA. The primary disadvantage of CDMA2000 is that it is not backward compatible with either GSM or TDMA. C.3.3

From TDMA

The transition planned for TDMA is to overlay a GPRS network onto the established network and then introduce EDGE as the air interface. This gives TDMA several stages in its evolution—all in a few years. In practice, one or more of these stages may be missed as technology or, indeed, the marketplace evolves. One caveat that should be added here is that the way in which the mobile operators will move toward 3G is far from settled. There is little doubt that it will happen—the level of sunk investment provides significant motivation—but the how and when questions are still open. It seems likely that the GSM-to-GPRS-to-3G path will lead the way, simply by virtue of worldwide market dominance (GSM accounts for more than 50% of the installed mobile base).

C.4

Implications for mobile data

If we assume that mobile networks do evolve, somehow, then mobile data services will be impacted. Of course, the main benefit will be higher speeds, and this is likely to give the same sort of boost to mobile service that high-speed PC modems gave to Internet access. Quite apart from the prospect of faster access, UMTS will help m-business to flourish in some other areas as well. First, the issue of national network operators supporting internationally roaming users goes away. UMTS has been designed from the

The third-generation mobile network

235

outset as a global system, comprising both terrestrial and global satellite components. Multimode terminals that are also able to operate via second-generation systems such as GSM-900 and GSM-1800 will further extend the reach of many UMTS services. In the future, there are likely to be even more networks using these and other standards: The goal is to achieve truly personal communications, with terminals able to roam between these different networks. This means that a subscriber will be able to roam from a private network, into a picocellular/microcellular public network, then into a wide-area macrocellular network (which may actually be a second-generation network), and then to a satellite mobile network with minimal breaks in communication. Second, the user experience will be consistent. UMTS services are based on standardized service capabilities, which are common throughout all UMTS users and radio environments. This means that a personal user will experience a consistent set of services even when he roams from his home network to other UMTS operators—a “virtual home environment” (VHE). Users will always “feel” that they are on their home network, even when roaming. VHE will ensure the delivery of the service provider’s total environment, including, for example, a corporate user’s virtual work environment, independent of the user’s location or mode of access (satellite or terrestrial). VHE will also enable terminals to negotiate functionality with the visited network, possibly even downloading software so that it will provide “home-like” service, with full security, transparently across a mix of access and core networks. The ultimate goal is that all networks, signaling, connection, registration, and any other technology should be invisible to the user, so that mobile multimedia services are simple, userfriendly and effective.

C.5

Summary

This appendix has reviewed the prospects and technologies for thirdgeneration mobile communications. Given the diversity in the current second-generation network, it is clear that more than one evolutionary path lies open, although the way forward defined for GSM networks appears, by virtue of having the largest installed base, to be the dominant one. Some of the implications for mobile data are considered.

236

Mobile IP Technology for M-Business

Selected bibliography Coursey, C., Understanding DPCS: The TDMA Standard, Norwood, MA: Artech House, 1999. Heine, G., GPRS, EDGE, HSCSD and the Path to 3G, Norwood, MA: Artech House, 2001. Holma, H., and A. Toskala, WCDMA for UMTS, New York: John Wiley & Sons, 2000. Korhonen, J., Introduction to 3G Mobile Communications, Norwood, MA: Artech House, 2001. Muratore, F., UMTS—Mobile Telecommunications for the Future, New York: John Wiley & Sons, 2001.

Appendix D Mobile devices Anytime, anyplace, anywhere, There’s a wonderful world you can share. —Martini ad

T

his final appendix takes a look at the user’s point of contact with a mobile data service: the mobile device. The variety and sophistication of these devices grew significantly during the late 1990s and early 2000s, so much so that many handheld computers are as powerful as the desk machines of just a few years ago. This fact, along with the way that both voice and data technology has come together in the mobile device, makes them a key element in any mobile service. The fundamental requirement of an access device for mobile data services is to provide an intuitive and usable interface, particularly as the use of such services spreads beyond the domain of computer-literate users. A Web browser running on a PC typifies the target interface, but such interfaces increasingly assume a high-resolution full-color screen. When the same service is accessed on a device with more limited capabilities (typically, a low-resolution, quite small monochrome screen), it becomes very difficult to use. Another requirement for access devices is support for a communications protocol to communicate with the service

237

238

Mobile IP Technology for M-Business

provider. For access to the services we envisage in this book, this will be TCP/IP or other IP-based protocols, but for access to some of the established mobile services, more specialized protocols (notably short message service, SMS) will be used. Any service that is requested by and delivered to a remote user places high demands on security. These demands are increased when that user is connected over a radio link that is more susceptible to attack by a malicious user than a landline. Aspects relevant to user devices include access security, which may be provided via a personal authorization device (e.g., smart card), and secure data transfer, which requires the device to support suitable protocols [e.g., the secure sockets layer (SSL) within TCP/IP].

D.1

Handheld devices

Many of the recent advances in handheld device technology have provided greatly increased support for user mobility. It is widely predicted that wireless devices such as mobile phones will become the next pointof-sale (POS) devices for all manner of services and that e-business will evolve into m-business as the ubiquitous mobile phone evolves into a fully functional personal mobile assistant. In line with the strong growth prediction for m-business, handheld computing is expected to be a $7.5 billion market by 2003. Mobile computing devices, such as laptops, notebooks and handheld PCs, palmtop computers, personal digital assistants (PDAs), and smart mobile phones, pagers, and other messaging devices, will provide alternative forms of access to mobile data services. New technologies, such as touch screens, handwriting recognition, and, perhaps most significantly, voice recognition, are providing the vision of radically different human/computer interfaces on mobile devices. These advances are far more than cosmetic (because of limited size) because the ease of use of the mobile device interfaces is the key issue in its acceptance by consumers. A variety of new forms of mobile devices, each tailored to a specific user environment, emerged in the late 1990s, early 2000s. For instance, the Psion 5 is equipped with a conventional keyboard but the 3COM Palm III uses a touch screen with character recognition. Both can be

Mobile devices

239

TE

AM FL Y

connected to a mobile network operator and act as a fully functional terminal. An issue for current users of mobile devices is the complexity of connecting to networks. Conventional devices, such as laptop PCs, can use standard PCMCIA modem cards, but for smaller devices, such as palmtop computers, life can be more complicated. For example, connecting a Palm III to a GSM network requires a “snap-on” modem, an interface adapter, a GSM phone, and connecting cables. Infrared or radio connection between devices and mobile phones, using one of the short-range connection technologies (see Appendix B), can simplify this complexity, but range is an issue and some special conditions may apply (e.g., line of sight is required for an infrared link). An alternative in the development of mobile devices is to build the computing functionality into a mobile phone. The Nokia 9110 communicator epitomizes this approach. This well-known device provides e-mail, fax, SMS, Web, and PDA capabilities in a pocket-size package. The need for a reasonable size screen and keyboard constrains the minimum practical size for such a device, but further innovations are likely to address even these issues. As a sighting shot of where we may be going, wristwatches with built-in PDAs and communications facilities have begun to appear. Furthermore, some of the commercially available watches have significant computing capabilities; Seiko’s Ruputer has a 16-bit processor, 128 Kb of RAM, and 512 Kb of ROM, plus a 38-Kbps infrared port. Some Japanese watch manufacturers have built-in communications capabilities for their own Personal HandyPhone System (PHS), making the watch into a mobile phone. In Europe, Swatch is currently looking to build GSM capability into their watches.

D.2

Security

One of the reasons many people cite for not using mobile services is a lack of security. The user perception that they are open to attack when connected over a radio link has sparked a considerable amount of attention on how best to ensure security. Given that there are already techniques to protect a radio channel (e.g., frequency hopping), security can be added in two places: in the remote device itself and in the way that the

240

Mobile IP Technology for M-Business

device and the service it attaches to authenticate each other. This section considers both aspects. D.2.1

Link security

Various ways are available for ensuring that a data link is secure. Indeed, so much has been written on the subject that we only give a few examples of the techniques that are available. Secure sockets

A socket is a combination of an IP address and a port number (see Appendix A for a detailed description of both of these). It is used to define a connection between a user and the service she is using. A secure socket is an enhancement of this basic socket that allows the authentication of peers, the exchange of secret keys, and the encryption of data streams between client and server. Netscape, in their specification of an SSL and the corresponding secure socket protocol, used this general idea. SSL was initially used only inside the Netscape browser Navigator, but SSL version 2 became a de facto standard for the protection of HTTP traffic. Now at issue 3, SSL is a transport layer security protocol that sits between an application and the TCP/IP protocols that carry that application. This is shown in Figure D.1. Because it sits outside of the application

Figure D.1

Client

Server

Application

Application

SSL handshake

SSL handshake

SSL record

SSL record

TCP/IP

TCP/IP

The architecture of SSL.

Mobile devices

241

it protects, SSL can be used to transparently secure any TCP/IP application layered on top of it. SSL has three basic security properties. First, the communicating entities can authenticate each other using public key cryptography. See Chapter 6 for a discussion of this. Second, the confidentiality of the exchanged data is protected as the connection is, after an initial handshake and session key negotiation, encrypted. Third, the integrity of the exchanged data is authenticated and checked for integrity. SSL does not protect against all sorts of attacks. For instance, because the IP header is sent in the clear, we can determine where packets are coming from and going to. This is a deliberate omission from the standard because traffic analysis attacks are considered a minor threat when connections being made are very varied (as they typically are for Internet access). For SSL to work, both sides of a link must be aware that it is being used. This awareness can be created by using dedicated port numbers for SSL-protected applications, by negotiating SSL support after a normal session is established, or by using TCP to negotiate the use of a security protocol during the establishment of the connection. In practice, the first option is used. Some of the port numbers assigned for SSL protected applications are given in Table D.1. A wealth of details is available on SSL and all of the other generalpurpose security measures that have been developed to support Internet applications. Two very fine references that have implementation-level detail as well as a lot of interesting background are Internet and Intranet Security by Rolf Oppliger (Artech House, 2000) and Implementing IPsec by Elizabeth Kaufman and Andrew Newman (John Wiley, 1999). In addition to the measures that have been developed to secure sessions over an IP connection, security measures have also been developed specifically to allow safe on-line transactions. In particular, Secure

Table D.1 Port Number for SSL-Supported Applications Application

Port Number

Protocols

HTTPS

443

HTTP with SSL support

SSMTP

465

SMTP with SSL support

SLDAP

636

LDAP with SSL support

242

Mobile IP Technology for M-Business

Electronic Transactions (SET) has been developed to protect payments over the net. Secure electronic transactions

The SET standard was sponsored by Visa and MasterCard to provide secure communications across the Internet between the card provider, its holder, the card holder’s financial institution, and the merchant’s financial institution. SET’s goal is to ensure that only those parties who need access to information are able to obtain it and that all parties trust the identities of all other parties. It also allows individuals to authorize transactions (i.e., “sign” them). SET works as outlined in Figure D.2. Here, a payments gateway is shown at one end of the payment chain. A protected network between the merchant and the acquirer is not necessary because SET was designed such that conducting the entire transaction over the public Internet is made possible. Crucial within this is the status of the mobile device— SET and other security technologies will evolve to serve the existing e-business boom. The security features of the mobile device will either enable or prevent its playing a part in that boom.

User

Merchant

SET

Web server

Internet

CGI application SET

Browser

SET-compliant components

SET

Acquiring bank

Figure D.2

The SET standard.

Payments gateway

Internet

Mobile devices D.2.2

243

Device security—smart cards

The smart card is a credit card-sized plastic strip with some integral memory and processing capacity. It has external connectors but does not usually have keys or buttons like a calculator. It can be used as an electronic purse or as a multifunction security pass. Smart cards can have any permutation of processing power, memory, and security features. Current technology is capable of producing cards that can carry out the complex mathematical calculations required to encode data so that they can be safely transferred over networks. The memory on a card can be reprogrammed around a million times, failure rates are virtually negligible, and the cost of the smart card is comparable to that of a phone card. Features such as card size, contact layout, and electrical characteristics have all been defined by the ISO (International Standards Organization) in standard ISO 7816. At the functional level, smart cards can be categorized as either memory cards or microprocessor cards. Memory cards, such as disposable prepaid phone cards or loyalty cards, are the most basic and cheapest type of smart card. They contain a small amount of memory in the form of read-only memory (ROM) and electrically erasable programmable read-only memory (EEPROM). The capacity may only be a few tens of bytes, but the “nonvolatile” nature of the memory enables the storage of simple data, such as decrementing value counters. This can be retained after the electrical power supply provided by the terminal is removed—a useful feature, given that smart cards do not have their own power supply. Microprocessor cards are more advanced than simple memory cards in that they contain a microprocessor central processing unit (CPU) and random-access memory (RAM) in addition to ROM and EEPROM. The ROM contains the card’s operating system and factory-loaded applications. Smart card operating systems tend to be proprietary and there is as yet no widely accepted standard operating system, although Multos and Smart Cards for Windows are the two leading candidates for that title. Although ISO 7816 is the basic standard for smart cards, it tends to focus mainly on interoperability at the physical, electrical, and data link protocol levels. That said, it also defines a standardized logical structure and a small set of commands, but this was adopted as an international standard, by ISO, relatively recently. In the absence of a standard, this aspect of the smart card market has evolved on a largely proprietary basis.

244

Mobile IP Technology for M-Business

With no widely accepted standard smart card operating system, card manufacturers have tended to develop their own unique operating systems, specific to the particular chip hardware. Card applications are then specific to a particular operating system embedded in the chip. Thus, even in schemes like GSM, where cards from different suppliers are interchangeable, the firmware in them is proprietary and nonportable. For the most part, smart cards hold only one application per card; hence, users have had to carry several cards, typically from different manufacturers, to meet all of their needs. The fact that end users need an extra piece of hardware, the smart card reader, is one obstacle. Requiring them to use more than one manufacturer’s reader is another. We have yet to reach the stage where devices are either supplied with or can be fitted with industry-standard readers in which smart cards for a variety of different applications can be used interchangeably. In 1996 Europay, MasterCard, and Visa (EMV) defined a specification that extended ISO 7816 with the addition of data types and encoding rules for use by the financial services industry. The European telecommunications industry also embraced the ISO 7816 standards for their Global System for Mobile (GSM) communications smart card specification to enable identification and authentication of mobile phone users. For PC-based smart card applications, further (de facto) standards have emerged to address the fact that there was no standard way for PCs to talk to smart card readers, with users being locked into proprietary solutions where a particular manufacturer’s card could only be used with that manufacturer’s reader. Some five years ago, the Personal Computer/Smart Card (PC/SC) work group was formed by some of the major players in the smart card market such as Microsoft, HP, IBM, Sun, Gemplus, and Schlumberger. It was created to develop open specifications for a standard model to interface smart card readers and cards with PCs. The PC/SC specifications are based on the ISO 7816 standards and are compatible with both the EMV and GSM industry-specific specifications. They provide a layered model, shown in Figure D.3, that allows smart card-aware applications to talk to the smart card in a transparent manner, in much the same way as applications today talk to other peripherals such as printers. At the topmost level in the model, developers can write smart cardaware applications in a device (card reader) independent manner. Below this, the smart card manufacturers provide high-level APIs (application programming interfaces) for specific card functions. At the lowest level,

Mobile devices

245

“Card-aware” applications

Applications with modules which conform to the PC/SC API

Service providers

High-level APIs to specific cards

Tracks device types and cards connected Tracks card events and controls card sessions

Card resource manager

IFD handler RS232 IFD

Figure D.3

IFD handler PS/2 IFD

IFD handler

Handles various interfaces to various card accepting devices Standard interfaces

USB IFD

Interface device (card accepting device)

The PC/SC model.

and transparent to anything above it, manufacturers provide PC/SC compatible smart card readers and device drivers for the particular Windows platform. Two of the more promising new smart card technologies that address the issue of lengthy development times for new applications are Java Card (which is an API) and Multos (which is an operating system and API). Java Card

A Java Card is a smart card capable of running programs written in a much-reduced version of Sun’s Java programming language. It is a specialized implementation because smart cards impose many constraints, such as the use of 8-bit integers instead of the 32 bits normally required. The Virtual Machine (VM) that translates Java byte code into card processor-specific instructions, language specification, and core packages all have to be made more compact for smart cards. The Java Card API defines the calling conventions by which an applet accesses the Java Card run-time environment and native services. This

246

Mobile IP Technology for M-Business

allows applications written for one Java Card-enabled platform to run on any other Java Card-enabled platform. On a Java Card, applets or “cardlets” sit on top of the Java VM, which in turn sits on top of the card’s operating system. The applets are stored in EEPROM, hence the ability to download new applets and delete unwanted applets during the card’s lifetime. This provides great flexibility in that multiple applications can run on a single card, applications can be changed or corrected without having to issue a new card and the time to market for new applications is greatly reduced. The major disadvantage is that the hitherto fixed and tamperproof features of smart cards are now potentially accessible. Malicious applets could be unknowingly loaded, causing increased security concerns. In addition, the speed of execution is a problem for Java-based programs due to the extra layer of activity introduced by the Java VM. Some Java Card products are currently available or are in production, such as Gemplus’s GemXpresso, Schlumberger’s Cyberflex, and Bull’s Odyssey, but it could take some time for Java Cards to reach maturity. The Visa Open Platform specification is being designed to supply extra features, including aspects of security that are not currently addressed by the Java Card API. Multos

An alternative and more mature technology for multiple-application smart cards is Multos, promoted by the Maosco consortium. Set up in 1997, this group includes Multos founders Mondex International along with other industry leaders. The Multos specification is more comprehensive than the Java Card specification, defining the physical chip security and operating system as well as the virtual machine and APIs for programming it. Like the Java Card API, Multos is compliant with the ISO 7816 and EMV standards. Applications are again stored in EEPROM, but Multos provides a certification scheme for the life cycle of applications: secure downloading, storage, and deletion. Multos checks the validity of new applications being downloaded and provides an area of memory for each to reside in. The design of the system provides a logical firewall around each of the applications that will stop any interference between them. Each application is interpreted and talks to external systems via the operating system. This clear separation of applications on the card is vital. Some companies may only be happy having their application added to

Mobile devices

247

a multiple-application card if they have some confidence that other rival applications on the same card will not interact with it. Maosco claims to be aiming for ITSEC certification level E6 for type-approved Multos cards. Applications for Multos smart cards can be developed either in a low-level language called Multos Executable Language (MEL) or in a high-level language such as C. MEL is part of the Multos specification and is a language optimized for 8-bit smart card microprocessors and the Multos-specific security requirements. Applications

The smart card is capable of providing secure access to a variety of services, independent of the delivery channel. Some of the most common uses for smart cards today fall into this category. Satellite television decoder cards are one example, along with subscriber identity module (SIM) cards that authenticate GSM mobile phone users. As we move into an age of network computing, kiosk-type terminals and all of the other access devices mentioned in the first section can be personalized using smart cards. A mechanism often employed to ensure that its authorized user is using the smart card is known as card holder verification (CHV). Commonly CHV is achieved by the off-line entry of a PIN known only to the card and its rightful holder. A correct entry will authenticate the card holder, whereas a successive number of incorrect attempts will lock the card (or an application on it) against further attempts. Authentication with a smart card is an example of two-factor authentication, requiring “something you own” (the smart card) and “something you know” (the PIN). Payment is a key application for smart cards. In 1996, Europay, MasterCard, and Visa jointly published a specification called IC Card Specifications for Payment Systems. This specification became known as EMV and covers design aspects for smart cards, terminals, and debit/credit applications used in financial transactions. One of the drivers for the move to smart cards is the ease and low cost with which magnetic stripe credit/debit cards can be forged, causing increasing fraud losses. A measure of the success of EMV is that many smart card products are now advertised as “EMV-compatible.” The EMV specifications were designed such that card terminals are not required to contain secure application modules (SAMs) for

248

Mobile IP Technology for M-Business

authenticating cards. This is due to the high cost of managing the worldwide distribution and updating of symmetrical keys to partly off-line card terminals. Instead, EMV uses asymmetric techniques to authenticate the card, adopting either static or dynamic data authentication. These are both based on digital signature technology, meaning the terminal will not need to contain any private keys. Some issues are still outstanding, including transaction speeds, staff training, and the integration of point-of-sale (POS) terminals. In response to these, the Association for Payment Clearing Services (APACS) has announced that EMV-compliant chip cards will replace magnetic stripe credit cards in the United Kingdom during 2002 and 2003. Furthermore, APACS has set the target that, by April 2002, 65% of all credit and debit transactions in the United Kingdom will use smart cards. Currently, many users of public key cryptography store their private keys on their desktop computers. This private key database tends to take the form of an encrypted file on the hard drive, with access being controlled by a single password. Many risks are associated with this practice. How well the keys are protected ultimately depends on the strength of the password chosen by the user. Smart cards can be used to address these security weaknesses, with varying degrees of improvement that can be chosen to match the tradeoff between perceived risk and cost. Because of the very nature of its use, security is of paramount importance in the design of an operating system for smart cards, something that is not always the case for desktop computers. The first-generation digital signature cards simply provide secure private key storage. The card still relies on some form of PIN or password authentication but is designed to be more tamper resistant, both physically and by dedicated software. While this results in a secure and portable storage medium for private keys, the cryptographic processing is still provided by the host computer, hence private keys are still read from the smart card for operations such as digitally signing and decrypting messages, as illustrated in Figure D.4. The manner in which the exchange of keys ensures security is explained in some detail in Chapter 6. Because it only stores security keys, the smart card functionality in the preceding example could be subsumed into the mobile device. However, the separation of a user’s signature from the device being used allows some flexibility: The same user can have a range of mobile devices, all protected by one card.

Mobile devices

249

Computer

Hash

Document

k Mar

Smart card Encrypt with private key

#

#

Hash (Message digest)

Hash

k Mar

Signed hash

Append to document

Figure D.4

D.3

AM FL Y

Signed document

Signing a document using a smart card.

Mobile operating systems

TE

One of the points made in the section on handheld devices was that each brand of device tends to have its own operating system. The current view is that no single operating system (OS) will dominate the mobile computer market, and that four main systems will dominate. The Palm OS, owned by 3Com, is the basis for the successful Palm palmtop device range, which has the largest user base of all of the PDAs, with more than 40% of the worldwide handheld market and 70% in the United States. Microsoft released Windows CE in the late 1990s with the vision that it would suit a range of small devices, including handheld PCs and palmtop computers. CE has, so far, failed to make the market impact expected on its initial release, but with many established hardware vendors (including Philips, Casio, Hewlett Packard, and Sharp) increasing their device range, and with enhanced OS releases, it may see significant market growth. The third vendor is Symbian with its EPOC operating system. The Symbian alliance includes Psion, Motorola, Ericsson, and Nokia—an

250

Mobile IP Technology for M-Business

interesting combination of talents, ranging from PDA producers to mobile phone technology manufacturers. EPOC is used in the current Psion PDAs, but no mobile devices using EPOC have been announced yet. Java OS is the fourth option, and Sun has released a specification detailing a Java application environment, PersonalJava, that is aimed at consumer devices. Its architecture is more suited to constrained memory and processing environments and can optionally include parts of the full Java API. New devices running the PersonalJava operating systems are only just appearing, and it is difficult to predict their market take-up. Sun is also producing other Java API’s for speech, sound, telephony, and multimedia. These are likely to migrate into mobile devices. The other consideration with Java is that JVM may be available on top of existing OSs. Symbian has released details of their intended implementation of a PersonalJava JVM, to run on the EPOC OS, and a JVM for Windows CE OS is available. Most of the existing on-line services use Web access, and because this is likely to continue as m-business matures, mobile computer Web browsing capabilities will be important. Web browsers for smaller devices, such as personal organizers, are quite varied and often tightly linked to the device platform. Here is a comparison of the five main vendors in the area: 1. 3Com relies on independent software vendors to supply Web browsing capabilities for their Palm devices, including Smartcode’s HandWeb, which offers a simple text-only interface, and ProxiNet’s ProxiWeb browser, which performs some proxy image conversion. 2. Microsoft Windows CE offers a pared-down version of the Desktop PC Internet Explorer. 3. Symbian offers its own Web browser for EPOC OS. 4. Java OS has Sun’s own HotJava browser, although they will be offering a package of personal applications to suit PersonalJava environments. 5. For wireless devices, the Wireless Access Protocol (WAP) group is developing standards for Web access. WAP-compliant devices use a specialized Wireless Mark-up Language (WML), with specially developed content or via a proxy translation from HTML to WML.

Mobile devices

251

They use a menu-driven user interface (microbrowser) to access Web text data.

D.4

Delivering m-business

Delivering m-business services to a range of access devices, each of which has its own operational capabilities and peculiarities, will require the use of a flexible, high-performance middleware architecture. This software architecture must be capable of supporting the expanding range of network standards, device capabilities, and user expectations. Key issues that need to be addressed include not only how services are provided but how they are managed, including updating and charging. Some of the emerging architectures are described briefly next. All of these attempt architectures to address the issue of access device diversity. D.4.1

Telecommunications Information Networking Architecture

The Telecommunications Information Networking Architecture (TINA) has a service architecture that is primarily designed to support telecommunications and information management services. The consortium is made up of telecommunications operators and equipment manufacturers, computer manufacturers, and software companies. TINA access devices (computation objects) interact with other objects via the distributed processing environment (DPE), which provides transparency of location, distribution, and replication. Implementations of the DPE are strongly based on the Common Object Request Broker Architecture (CORBA) protocol. TINA includes session and subscription models to support service provisioning. A number of trial TINA platforms have been developed, mainly for providing telecom carrier services, but also including an electronic shopping mall, video-on-demand, and customer network management services. D.4.2

Jini

Jini is Sun’s network architecture—a distributed system that behaves as a network federation. A computing resource (e.g., disk storage, application) can register itself as a service to any other registered device within the federation. It provides lookup services, a service leasing model,

252

Mobile IP Technology for M-Business

transactions, and event models. It is based on Java technology, with Java Remote Method Invocation (RMI) as the interobject protocol. Java-based access devices integrate in a straightforward manner with the architecture, whereas non-Java-based applications require a proxy. Several scenarios for the use of Jini have been put forward, most notably around the idea of renting applications. D.4.3

Wireless Knowledge

Wireless Knowledge is a joint venture between Microsoft and Qualcomm. The main focus is on ubiquitous wireless device access to central services. Its technology is based on the Microsoft BackOffice family and the Microsoft Commercial Internet System (MCIS) and best suits devices that are based on a Microsoft OS (e.g., Microsoft Windows 98, Microsoft Windows CE). Wireless Knowledge’s strength is in its working relationships with most wireless carriers in the United States, and it covers all digital wide-area network technologies, most notably GSM. D.4.4

IBM Transcode

IBM Transcode is an implementation of IBM’s idea of pervasive computing. The middleware takes content that is written in a generic language, for example, HTML, and transcodes it into a form suitable for the access device. For this it uses a proxy server, which is also able to complete other operations on behalf of the client, for example, providing continued connection over an intermittent network link. At this time, all of the above are still at the preparatory stage. With the uncertain evolution from second- to third-generation mobile networks and the still maturing protocols to support mobility, it is likely to be some time before a software architecture to support the full range of mobile services emerges. Nonetheless, the attention focused on the issue is likely to positively affect the delivery of service.

Selected bibliography Kaufman, E., and A. Newman, Implementing IPsec, New York: John Wiley & Sons, 1999. Mougayar, W., “Web Business Will Soon Go Wireless,” LANTIMES, April 1998.

Mobile devices

253

Norman, D. A., The Invisible Computer, Cambridge, MA: The MIT Press, 1998. Oppliger, R., Internet and Intranet Security, Norwood, MA: Artech House, 2000. Zoreda, J. L., and J. M. Otón, Smart Cards, Norwood, MA: Artech House, 1994.

Web sites Java Card, www.javasoft.com. Multos, www.multos.com. PC/SC, www.smartcardsys.com. SET, www.setco.org. WAP, www.wapforum.com.

Glossary An approximate answer to the right question is to be preferred to an exact answer to the wrong one. —Albert Einstein

A

s you might expect, mobile technology does not stand still. In fact, it moves at such a pace that it tends to leave many of its observers and practitioners bewildered. This is the main motivation for providing this fairly extensive glossary. With mobile data service and m-business driven by both technical and business innovation, the language of the software engineer, the banker, the network designer, the market maker, and the information technologist all have their part to play. Here we draw on these diverse disciplines by listing some of the more commonly used abbreviations and concepts. The simple aim is to shed some light on complex ideas by giving an extra view on their context and application.

Authentication, authorization, and accounting. These are the three essential aspects of network services. First you have to know exactly who you are dealing with, then you have to ensure that they receive service, according to their privilege, and, finally, you have to charge for what has been used. AAA

255

256

Mobile IP Technology for M-Business

A common term used both in computers and data communication designating the destination or origination of data or terminal equipment in the transmission of data. Address

The method by which a mobile node determines whether it is currently connected to its home network or a foreign network and detects whether it has moved and the way it has moved. It is the mechanism by which mobile nodes query and discover mobility agents. This is done through an extension of the ICMP router discovery protocol (IRDP, defined in RFC 1256), which includes a mechanism to advertise mobility services to potential users. Agent discovery

Algorithm A group of defined rules or processes for solving a problem. This might be a mathematical procedure enabling a problem to be solved in a definitive number of steps. A precise set of instructions for carrying out some computation (e.g., the algorithm for calculating an employee’s take-home pay).

Application program interface; software designed to make a computer’s facilities accessible to an application program. All operating systems and network operating systems have APIs. In a networking environment it is essential that various machines’ APIs be compatible; otherwise, programs would be exclusive to the machines in which they reside. API

Application The user task performed by a computer (such as making a hotel reservation, processing a company’s accounts, or analyzing market research data).

A series of computer instructions or a program that, when executed, performs a task directly associated with an application such as spreadsheets, word processing, database management. Application program

Applications software cations task.

The software used to carry out the appli-

When applied to computer and communication systems, it denotes the logical structure or organization of the system and defines its functions, interfaces, data, and procedures. In practice, architecture is not one thing but a set of views used to control or understand complex systems. Architecture

Glossary

257

ASC X12 Accredited Standards Committee, X12. It comprises government and industry members who create electronic data interchange (EDI) standards for submission to ANSI for subsequent approval and dissemination. Asynchronous data A data transmission process in which receiver and transmission transmitter clocks are not synchronized, each character (word/data block) is preceded by a start bit and terminated by one or more stop bits, which are used at the receiver for synchronization. AuC Authentication center; logical component of a GSM network responsible for verifying requests for connection.

The process of verifying the identification of the true sender of a message and also that the text of the message itself has not been altered. Authentication

The difference between the highest and lowest sinusoidal frequency signals that can be transmitted by a communications channel, it determines the maximum information carrying capacity of the channel. Bandwidth

Batch processing Batch processing is the transmission or processing of a group of payment orders and/or securities transfer instructions. Browser A browser is a computer program that facilitates locating and displaying information on the World Wide Web. Examples include Netscape Navigator and Microsoft Explorer. The browser could work on the Internet or through internal information management systems called Intranets. Bug An error in program or fault in equipment. A hangover from the days when an insect caught in an early electromechanical computer caused it to fail.

The termination point of the tunnel to a mobile node. This can be a colocated care-of address, in which the mobile node acquires a local address and detunnels its own packets, or a foreign agent care-of address, in which a foreign agent detunnels packets and forwards them to the mobile node. Care-of address

258

Mobile IP Technology for M-Business

A catalog is the electronic equivalent of a shop’s shelves, goods, and departments, and so is a central concept in all aspects of online business. It is the on-line representation of what is “for sale” (or more correctly, what is available for trading). Catalogs for buyers and sellers are different—the former is a virtual catalog through which the buyer can see competing products from a number of suppliers, and the latter is a structured set of information that represents what a supplier has to sell.

Catalog

Certificate authority A trusted third party that authenticates that a public key belongs to a specific, registered party. C/GOS Class/grade of service. The level of certainty and timeliness with which packets are delivered in a shared medium network. CIDR Classless interdomain routing protocol. A policy that basically eliminates the IPv4 address class structure. This allows, for example, a single network number to be assigned from a block of class C addresses to a requesting organization. Circuit An electrical path between two points generally made up with a number of discrete components. Circuit switching A method of communication in which a continuous path is first established by switching (making connections) and then using this path for the duration of the transmissions. Circuit switching is used in telephone networks and some newer digital data networks. Client An object that is participating in an interaction with another object and is taking the role of requesting (and receiving) the required service.

The division of an application into two parts, where one acts as the “client” (by requesting a service) and the other acts as the “server” (by providing the service). The rationale behind client/server computing is to exploit the local desktop processing power, leaving the server to govern the centrally held information. This should not be confused with PCs holding their own files on a LAN, as here the client or PC is carrying out its own application tasks. Client/server

Commodity codes Codes used to define specific types of commodities across selling organizations. No existing standards exist, and many

Glossary

259

third-party organizations market their proprietary commodity coding schemas. Configuration A collection of items that bears a particular relation to each other (e.g., the data configuration of a system in which classes of data and their relationships are defined).

Occurs when information is exchanged over a fixed link with predictable characteristics. The public switched telephone network exemplifies this type of network. Connection oriented

AM FL Y

Connectionless Occurs when information is dynamically routed across a network in self-contained units. X.25 was the first commercial connectionless service; IP is the dominant one at present. This type of network is characterized by possible loss, delay, or reordering of information. It is the user who has to implement the end-to-end protocols to reorder, resequence, and recover. CORBA Common Object Request Broker Architecture. An evolving framework being developed by the Object Management Group to provide a common approach to systems interworking.

TE

Correspondent node A peer with which a mobile device is communicating. A correspondent node may be either stationary or mobile.

A term used to describe the world of computers and the society that gathers around them. First coined by William Gibson in his novel Neuromancer.

Cyberspace

Data Usually the same as information. Sometimes information is regarded as processed data. Data compression A method of reducing the amount of data to be transmitted by applying an algorithm to the basic data source. A decompression algorithm expands the data back to its original state at the other end of the link. Commonly used data compression formats are .zip (for computer files) and .mp3 (for music).

A collection of interrelated data stored with controlled redundancy to support one or more applications. On a network, data files are organized so that users can access a pool of relevant information. Database

260

Mobile IP Technology for M-Business

Database server The machine that controls access to the database using client/server architecture. The server part of the program is responsible for updating records, ensuring that multiple access is available to authorized users, protecting the data, and communicating with other servers holding relevant data. Datagram Term used in IPv4. The format for a packet of data sent on the Internet to a specific destination address. Specifies standards for the header information. In IPv6, datagrams are known as packets.

Database management systems; groups of software used to set up and maintain a database that will allow users to call up the records they require. In some cases, DBMS also offer report and application generating facilities. DBMS

Detached digital signature PKCS #7 signatures can be detached or self-contained. A detached signature is a signature that is separate from the content to which the signature applies, whereas in a self-contained signature the signature and the content are linked. A detached signature is a PKCS #7 data object of type SignedData with the SignerInfos field containing signatures on external data and the ContentInfo field being empty. OBI/1.0 specifies the use of a detached signature. DHCP Dynamic Host Control Protocol; a mechanism that allocates a temporary IP address to a user from a pool. This minimizes the size of the address range needed by an operator. Digital certificate A document signed with a digital signature which states that a specified public key belongs to someone or something with a specified name. Within OBI, certificates are signed or issued by a trusted third party (certificate authority) to requisitioners, servers, and authorized signers of order documents. Digital signature Digital signatures utilize public key cryptography and one-way hash functions to produce a signature on the data that can be authenticated and that is difficult to forge or repudiate. A digital signature is often referred to as an encrypted message digest. Within OBI, a digital signature can be included with an order or order request using the PKCS #7: Cryptographic Message Syntax Standard defined by RSA Data Security.

Glossary

261

Distributed computing The move away from having large centralized computers such as minicomputers and mainframes and bringing processing power to the desktop. Often confused with distributed processing. Distributed database A database that allows users to gain access to records, as though they were held locally, through a database server on each of the machines holding part of the database. Every database server needs to be able to communicate with all the others as well as being accessible to multiple users.

The distribution of information processing functions among several different locations in a distributed system. Distributed processing

DNA Distributed Internet applications architecture; the Microsoft view of how Internet-based software should operate. DNA consists of business process, storage, user identification, and navigation elements. It builds on established COM, DCOM, and Active-X ideas and provides middleware for distributed applications. DNS Distributed name system; the method used to convert Internet names to their corresponding Internet numbers. Domain Part of a naming hierarchy, usually in an IP-based network. A domain name consists of a sequence of names or other words separated by dots. Also, a part of a network.

A term that embraces all aspects of buying and selling products and services over a network. The essential characteristics of e-business are that the dealings between consumers and suppliers are on-line transactions and that the key commodity being traded is information. E-business is the gateway to a deal—it is a virtual entity that may (but doesn’t necessarily have to) lead to physical product. Common synonyms for e-business include e-commerce and e-trading.

e-business

Electronic commerce The sale or procurement of supplies and services using information systems technology. Electronic data interchange (1) Intercompany, computer-tocomputer communication of data that permits the receiver to perform the function of a standard business transaction and is in a predefined standard data format. (2) The transfer of structured data, using

262

Mobile IP Technology for M-Business

agreed-on message standards, from one computer system to another, by electronic means. Electronic funds transfer Computerized systems that process financial transactions and information about financial transactions; specifically, the exchange of value between two financial institutions.

Common abbreviation for electronic mail. E-mail comes in many guises and has been popularized, to a large extent, through the growth of the Internet. E-mail

Encapsulation The process whereby a packet is enclosed as data inside another packet. Hence, an IP packet would be encapsulated in the payload of another packet, which would have a new header. The inverse of encapsulation is decapsulation.

Encryption is the process of disguising a message (using mathematical formulas called algorithms) in such a way as to hide its substance, a process of creating secret writing.

Encryption

Enterprise network The public and private switches, transmission links, subnetworks, management systems, network applications, and so on, that combine to provide an identifiable group of people with the communication service that they need to operate effectively. FAQ Frequently asked question; a set of files, available over the Internet, that provides a compendium of accumulated knowledge in a particular subject. Fault tolerance A method of ensuring that a computer system or network is resilient to faults or breakdowns to avoid lost data and downtime. Differing applications achieve this and include processor duplication and redundant media systems. File server A station in local-area networks dedicated to providing file and data storage to other terminals in the network. Flow, flow label A flow is a sequence of transmitted packets for which the source wants special handling by intervening routers. It has a unique identification of a source address and a nonzero 24-bit flow label. Foreign agent A router on a mobile node’s visited network that provides routing services to the mobile node while registered. The

Glossary

263

foreign agent detunnels and delivers packets (or datagrams) to the mobile node that were tunneled by the mobile node’s home agent. For datagrams sent by a mobile node, the foreign agent may serve as a default router for registered mobile nodes. FTP The Internet standard high-level protocol for transferring files from one computer to another. A widely used de facto standard. FYI For your information; these are Internet bulletins that answer common questions. Gateway Hardware and software that connect incompatible networks, thus enabling data to be passed from one network to another. The gateway performs the necessary protocol conversions. GPRS General Packet Radio Service; an extension of basic GSM that provides a connectionless data service. In GPRS, a number of voice channels are reserved for data, with a number of users sharing the available capacity. The data channel is always open and users vie to insert their data packets into the available bandwidth.

Global System for Mobile Communications; one of the leading standards for digital mobile telephony. GSM

Graphical user interface; an interface that enables the user to select a menu item by using a mouse to point to a graphic icon (small simple pictorial representation of a function such as a paint brush for shading diagrams). This is an alternative to the more traditional character-based interface where an alphanumeric keyboard is used to convey instructions.

GUI

Hardware The physical equipment in a computer system. Contrast with software. Header The information at the beginning of a message being transmitted. Includes the source and destination addresses, routing, and other information. Hierarchical network A network structure composed of layers. An example of this can be found in a telephone network. The lower layer is the local network followed by a trunk (long-distance) network up to the international exchange networks.

264

Mobile IP Technology for M-Business

HLR Home location register; the part of a GSM network that stores information about users of that network. Home address An IP address that is assigned for an extended time to a mobile node. It remains unchanged regardless of where the node is attached to the Internet. Home agent A router on a mobile device’s home network that tunnels packets to the mobile device while it is away from home. It keeps current location information for registered mobile devices called a mobility binding. Home network The network or virtual network that matches the subnet address of the mobile node.

Any end-user computer, such as a personal computer or workstation, that is part of a local-area network, or any other system that connects to a network and functions as the end point of a data transfer on the Internet. Host

HyperText Markup Language; used to describe formatting in Web documents. It is defined in the Internet’s RFC series. HTML

HTTP HyperText Transfer Protocol; the basic protocol that underlies the World Wide Web. It is a simple, stateless request-response protocol, defined in the Internet’s RFC series. IAB Internet Activities Board; the influential panel that guides the technical standards adopted over the Internet. Responsible for the widely accepted TCP/IP family of protocols. More recently, the IAB has accepted SNMP as the approved network management protocol. IETF Internet Engineering Task Force; the part of the IAB responsible for the development of technical standards, which are issued as Requests for Comment (RFC). Information processor A computer-based processor for data storage and/or manipulation services for the end user.

Any method or procedure that is used for the recovering of information or data that has been stored in an electronic medium. Information retrieval

Glossary

265

Information technology A rather loosely defined term that is usually taken to cover the technology relevant to providing information services for an organization. Generally a mix of software, hardware, office systems, databases, networks, and computing. Interface The boundary between two things, typically two programs, two pieces of hardware, a computer and its user, a project manager and the customer.

The connection of the uncountable, dissimilar networks of computers throughout the world using TCP/IP to exchange data. Differentiate this from internet, with a lowercase i, or intranet, which are both local networks that share a common communications protocol.

Internet

Internet service provider Businesses that provide subscription services, such as on-line information retrieval software, bulletin boards, e-mail, and so on to users for a fee.

Specialized form of interworking where the interaction involves two or more networks. Internetworking

Generic interaction between two entities to achieve operational, syntactic, and semantic integrity of information. Interworking

IP Internet Protocol. The ubiquitous protocol responsible for the link-by-link delivery of packets across the Internet.

A highly portable programming language that allows software to be written once and run anywhere—the task of porting a program onto different operating systems is avoided. Java

A sequence of bits that can be used to decode an encrypted message. Also the record identifier used in many information retrieval systems (i.e., database keys). Key

LAN Local-area network; a data communications network used to interconnect data terminal equipment distributed over a limited area. Language An agreed-on set of symbols, rules for combining them, and meanings attached to the symbols that are used to express something (e.g., the Pascal programming language, job-control language for an operating system, or a graphical language for building models of a proposed network).

266

Mobile IP Technology for M-Business

LDAP Local Directory Access Protocol; a protocol used on IP-based networks for populating customer records.

A system that has been developed to satisfy a specific requirement and is, usually, difficult to substantially reconfigure without major reengineering. Sometimes referred to as a cherished system (and sometimes as a millstone). Legacy system

Life cycle A defined set of stages through which a piece of software passes over time—from requirements analysis to maintenance. Common examples are the waterfall (for sequential, staged developments) and the spiral (for iterative, incremental developments). Life cycles do not map to reality too closely, but do provide some basis for measurement and hence control. Maintenance Changes to software or a network after its initial development; also called evolution. In practice, it is the task of modifying (locating problems, correcting or updating, etc.) hardware configurations and (more often) software systems after they have been put into operation.

A secure hashing algorithm that converts an arbitrarily long data stream into a digest of fixed size. This algorithm is widely used for ensuring message integrity and as part of creating and verifying digital signatures. MD5

Middleware A general term for software that provides connectivity between front-end and back-end systems. The latter are usually legacy systems that hold important data. The middleware provides a common set of services, interfaces, and functions that can be used by new frontends. The technology that enables middleware is DCE, DCOM, and remote procedure calls.

A host or router that changes its point of attachment from one network or subnet to another. A mobile device may change its location without changing its IP address; it may continue to communicate with other Internet nodes at any location using its home IP address, assuming link-layer connectivity to a point of attachment is available. Mobile device/node

Mobility agent

A home agent or a foreign agent.

Glossary

267

Mobility binding The association of a home address with a care-of address and the remaining lifetime. Mobility security association A collection of security contexts between a pair of nodes, which may be applied to mobile IP protocol messages exchanged between them. Each context indicates an authentication algorithm and mode, a secret (a shared key or appropriate public/private key pair), and a style of replay protection in use. Modularization The splitting up of a software system into a number of sections (modules) to ease design, coding, and other tasks. It only works if the interfaces between the modules are clearly and accurately specified. NAT Network address translation; a process that converts registered IP addresses into matching unregistered ones and vice versa. NAT is typically deployed at the boundary between the Internet and a private IP network (or intranet).

A general term used to describe the interconnection of computers and their peripheral devices by communications channels, for example, Public Switched Telephone Network (PSTN), Packet Switched Data Network (PSDN), local-area network (LAN), and widearea network (WAN). Network

The circuitry that connects a node to the network, usually in the form of a card fitted into one of the expansion slots in the back of the machine. It works with the network software and operating system to transmit and receive messages on the network. Network interface

A general term embracing all the functions and processes involved in managing a network, including configuration, fault diagnosis, and correction. It also concerns itself with statistics gathering on network usage.

Network management

Network topology The geometry of the network relating to the way the nodes are interconnected. NFS Network file system; a method, developed by Sun Microsystems, that allows computers to share files across a network as if they were local. Node

A host or router.

268

Mobile IP Technology for M-Business

Nonproprietary Software and hardware that is not bound to one manufacturer’s platform. Equipment that is designed such that it can accommodate other companies’ products. The advantage of nonproprietary equipment is that a user has more freedom of choice and a larger scope. The disadvantage is that when it does not work, you may be on your own. NIC Network Information Center; source of much information on the Internet and related networking issues.

Open buying on the Internet; a standard for secure, interoperable, business-to-business Internet commerce developed by the Internet Purchasing Roundtable and maintained by the OBI Consortium. OBI

OBI WAN True first name of Ben Kenobe, Jedi knight, padawan of Qui Gon Jinn. Object An abstract, encapsulated entity that provides a welldefined service via a well-defined interface. Object oriented A philosophy that breaks a problem into a number of cooperating objects. Each object has defined properties (e.g., it can inherit features from another object). Object oriented design is becoming increasingly popular (e.g., in the specification of network management systems). One-way hash function A one-way transformation that converts an arbitrary amount of data into a fixed-length hash. It is computationally hard to reverse the transformation or to find collisions. MD5 and SHA are examples of one-way hash functions. One-way hash functions are utilized within digital signatures. Packet switching The mode of operation in a data communications network whereby messages to be transmitted are first transformed into a number of smaller self-contained message units known as packets. Packets are stored at intermediate network nodes (packetswitched exchanges) and are reassembled into a complete message at the destination.

A variable whose value may change the operation but not the structure of some activity (e.g., an important parameter in the productivity of a program is the language used). Parameter

Glossary

269

Peer-to-peer communication Communications between two devices on an equal footing, as opposed to host/terminal, or master/slave. In peer-to-peer communications both machines have and use processing power. Pixel Picture element; the smallest discrete element making up a visual display image.

AM FL Y

PKCS Public-Key Cryptography Standards; a set of standards for public-key cryptography, developed by RSA Laboratories in cooperation with an informal consortium, originally including Apple, Microsoft, DEC, Lotus, Sun, and MIT. Published standards are PKCS #1, #3, #5, #6, #7, #8, #9, #10, and #11. PKCS includes both algorithm-specific and algorithm-independent implementation standards. Algorithms supported include RSA and Diffie-Hellman key exchange among many others. However, only RSA and Diffie-Hellman are specifically detailed. It also defines an algorithm-independent syntax for digital signatures, digital envelopes, and extended certificates; this enables someone implementing any cryptographic algorithm whatsoever to conform to a standard syntax, and thus achieve interoperability.

TE

Cryptographic Message Syntax Standard from RSA Data Security. Defines a general syntax for data with cryptography applied to it. OBI uses the PKCS #7 standard for digital signatures.

PKCS #7

Process of interrogating terminals in a multipoint network in a prearranged sequence by controlling the computer to determine whether the terminals are ready to transmit or receive. Once determined, the polling sequence is temporarily interrupted while the terminal transmits or receives. Polling

A device that acts as an input/output connection. A serial port and a parallel port are examples. Also, a warming after-dinner drink of surprising power. Port

Private-key encryption In this scheme, the security of the encryption depends on a shared secret that only the two communicating parties know. The International Data Encryption Algorithm (IDEA) and Data Encryption Standard (DES) are examples of private-key systems.

270

Mobile IP Technology for M-Business

Technically, a procedure that is being executed on a specific set of data; more generally, a procedure for doing something that is actually being carried out. Process

A set of instructions for a computer, arranged such that when executed they will cause some desired effect (such as the calculation of a quantity or the retrieval of a piece of data). Program

An artificial language constructed in such a way that people and programmable machines can communicate with each other in a precise and intelligible way. Fortran, Cobol, and C are three languages that account for most of the deployed software systems at present.

Programming language

A set of rules and procedures used to formulate standards for information transfer between devices. Protocol

PSTN Public Switched Telephone Network; the public telephone system that provides local, long-distance, and international telephone services. Widely used (with modems) for many other data services.

In this scheme, a user has a pair of keys— one private and one public. A message encrypted using the public key can only be decrypted using the private key and vice versa. So you can receive messages from anyone who knows your public key (which you decrypt with your private key) and can happily send an encrypted message to anyone whose public key you know. Perhaps the best known of the public key systems is RSA. Public-key encryption

Queuing When a frame or packet is to be transmitted on a link, it may have to wait because another frame is being processed in front of it. The frame is placed in a buffer until the transmitter is free. Hence queuing systems (i.e., packet switched systems) require buffers (matched to load and capacity) and introduce delay (as opposed to circuit switching systems, which block excess traffic, which then has to be resent). Registration The process by which the mobile node is associated with a care-of address on the home agent while it is away from home. This may happen directly from the mobile node to the home agent or through a foreign agent. Resolve The process of translating an Internet name into its equivalent IP address or other DNS information.

Glossary

271

RFC Request for comment; a long-established series of informal Internet documents widely followed by commercial software developers. RFCs tend to provide the implementation detail to supplement the more general guidance of ISO and other formal standards. RFCs are the main vehicle for the publication of Internet standards, such as SNMP. Router An Internet device that connects two networks, either local- or wide-area networks, that use identical protocols. Passes, or routes, data being sent between the two networks. Routing table A table of information on each machine that stores information about possible destination addresses and how to reach them. Used by IP to decide where to send a datagram or packet. RSA A well-known and widely used software-based public key encryption method. It is named after its inventors—Rivest, Shamir, and Adleman.

Small computer system interface; a bus-independent standard for system-level interfacing between a computer and an intelligent device (e.g., an external disk). Pronounced “scuzzy.” SCSI

Secure sockets layer; the Secure Sockets Layer Handshake Protocol was developed by Netscape Communications Corporation to provide security and privacy over the Internet. The protocol supports server and client authentication. The SSL protocol is application independent, allowing protocols like HTTP, FTP, and Telnet to be layered on top of it transparently. The SSL protocol is able to negotiate encryption keys as well as authenticate the server before data is exchanged by the higher level application. The SSL protocol maintains the security and integrity of the transmission channel by using encryption, authentication, and message authentication codes. SSL

Secure A situation is said to be secure when the level of security is commensurate with the business risk. Security The combination of software, hardware, networks, and policies designed to protect sensitive business information and to prevent fraud. Server An object that is participating in an interaction with another object and is taking the role of providing the required service.

272

Mobile IP Technology for M-Business

Session The connection of two nodes on a network for the exchange of data; any live link between any two data devices. SHA The secure hash algorithm defined in FIPS PUB 180-1. It produces a 20-byte output.

The passing of information and instructions from one point to another for the setting up or supervision of a telephone call or message transmission. Signaling

Simple Mail Transfer Protocol. The Internet standard for the transfer of mail messages from one processor to another. The protocol details the format and control of messages. SMTP

Specification A description of a system or program that states what should be provided, but does not necessarily provide information on exactly how the system or program will work. Store and forward Pertaining to transmission of data, messages are received at an intermediate routing point and recorded (stored). They are subsequently transmitted to a further routing point or to the ultimate recipient.

The set of rules for combining the elements of a language (e.g., words) into permitted constructions (e.g., phrases and sentences). The set of rules does not define meaning, nor does it depend on the use made of the final construction. Syntax

System A collection of independently useful objects that happen to have been developed at the same time.

The protocol at the Internet’s transport layer that governs the transmission of datagrams or packets by providing reliable, full-duplex, stream service to application protocols, especially IP. Provides reliable connection-oriented service by requiring that the sender and receiver exchange control information, or establish a connection before transmission can occur. TCP

Transmission Control Protocol/Internet Protocol; a set of transport internetworking protocols that has become a de facto networking standard. Commonly used over X.25 and Ethernet wiring, TCP and IP are viewed as two of the few protocols available that are able to offer a true migration path toward OSI. TCP/IP operates at the third TCP/IP

Glossary

273

and fourth layers of the OSI model (network and transport, respectively). The general name given to the means of communicating information over a distance by electrical and electromagnetic methods. The transmission and reception of information by any kind of electromagnetic system. Telecommunications

A TCP/IP-based application that allows connection to a remote computer. Telnet

Throughput A way of measuring the speed at which a system, computer, or link can accept, handle, and output information. Topology A description of the shape of a network, for example, star, bus, and ring. It can also be a template or pattern for the possible logical connections onto a network.

Transaction processing; process for controlling the rate of inquiries to a database. Specialist software (known as a TP monitor) allows a potential bottleneck to be managed. TP

A reversible conversion of a data stream prior to transmission to ensure proper processing. Typically this is done so that 8-bit data may be sent via a channel that only transmits 7-bit data. Transfer encoding

The path followed by a packet while it is encapsulated from the home agent to the mobile node. A packet entering a tunnel is being tunneled; a packet exiting a tunnel is being detunneled. Tunnel

Uniform Commercial Code; a set of model laws governing commercial and financial transactions. UCC

User Datagram Protocol An unreliable, connectionless protocol suite that manages the transport of data. Often used with the Internet Protocol for transmissions that will normally create an automatic response when received. UMTS Universal Mobile Telephony Service; the concept that users will be able to access all of their network services irrespective of location. The goal of UMTS is to provide a network based around the individual—the individual registers their access device with the network rather than having to find a fixed access device.

274

Mobile IP Technology for M-Business

A company that acts as a pipe or an electronic mailbox for the transmission of data and provides communications services such as line speed conversion and protocol matching. Value-added network

Hardware or software that will work with hardware and software manufactured by different vendors; the approximate opposite of proprietary. Vendor independent

Verification The ability to positively identify and authenticate a particular encrypted communication. Virtual circuit A logical connection across a network (e.g., the transmission path through an X.25 packet-switched data network established by exchange of setup messages between source and destination terminals). Virtual device A module allocated to an application by an operating system or network operating system, instead of a real or physical one. The user can then use a computer facility (keyboard or memory or disk or port) as though it were really present. In fact, only the operating system has access to the real device. Virtual network A network with no physical instantiation beyond a router (with a physical network interface on another network). The router (a home agent, for example) generally advertises reachability to the virtual network using conventional routing protocols.

A program, passed over networks, that has potentially destructive effects once it arrives. Packages such as Virus Guard are in common use to prevent infection from hostile visitors.

Virus

Visited network A network other than a mobile devices home network to which the mobile device is currently connected. Visitor list

The list of mobile devices visiting a foreign agent.

VLR Visitor location register; the part of a GSM network that keeps information on devices that are visiting that network (i.e., have a home network elsewhere).

Virtual private network; a combination of public and private resources that has been combined to give the user a network that looks like a coherent resource, suited to their particular needs. To all intents and purposes, a VPN is an enterprise network. VPN

Glossary

275

An ordered set of vendor offerings available via the World Wide Web.

Web catalog

Wide-area network A connection of the computers of several business users within an organization such that they may all access the same computer software or may have access to one another’s computer files.

An Internet-based project that has provided an intuitive and powerful means of navigating a very large information space. The Web has become almost synonymous with the client packages (browsers) such as Netscape and Internet Explorer that allow a user to traverse the Internet via hypertext links to access multimedia information. World Wide Web

Worm A computer program and a form of virus that replicates itself. The Internet worm was probably the most famous—it successfully, and accidentally, duplicated itself across the entire system.

ITU-T Recommendation X.509 specifies the widely adopted X.509 public-key certificate syntax. A certificate is signed by the certificate issuer to authenticate the binding between a specific user’s name and public key. X509.V3

X/Open An industry standards consortium that develops detailed system specifications drawing on available standards. X/Open owns the UNIX trademark and thereby brings focus to its various flavors (e.g., HP-UX, AIX from IBM, Solaris from SUN). XML eXtended Markup Language. A more powerful, and general, successor to HTML that allows the nature of information embedded in a Web page to be identified as well as its presentation format.

About the author

M

ark Norris is a technical director of Norwest Communications, a specialist network and computing consultancy. He has more than 20 years of experience in software development, computer networks, and telecommunications systems, and has managed dozens of projects, including multimillion-dollar, multiple-site projects. Norris has worked in Australia and Japan and has published widely during the last 10 years, including a number of books on e-business, software engineering, computing, project and technology management, telecommunications, and network technologies. He lectures on network and computing issues, has contributed to references such as Encarta, is a visiting professor at the University of Ulster, Northern Ireland, and is a fellow of the IEE. He can be reached at [email protected].

277

Index A

AMPS. See Advanced mobile phone system Anycast address, 213, 215 APACS. See Association for Payment Clearing Services API. See Application programming interface AppleTalk, 95 Application layer, 200, 207–8 Application programming interface, 244–45 Application security, 161–62 ARP. See Address resolution protocol AS. See Autonomous system Association for Payment Clearing Services, 248 Asymmetric encryption, 168–69 Asymmetric routing, 56 Asynchronous transfer mode, 121, 133 ATM. See Asynchronous transfer mode Attach operation, 12 Attacks, security, 49, 158–59 Audit, security, 159, 160, 162 Authentication general packet radio service, 12, 184 global system for mobile communications, 247 Internet protocol v6, 216–17

TE

AM FL Y

Access control, 169 Accounting. See Billing Acknowledgment packet, 106 Active state, 108, 111 Addressing allocation duration, 59–60 basics, 60–69 care-of, 40, 44–49, 55, 189, 218 classless, 68–69, 84–86 conserving, 66, 72, 76 dynamic, 12, 23–24, 66, 73–76, 195, 217 Internet protocol, 41–44, 61-69, 73, 181, 187, 202–4, 210–15 management, 76–77 registration, 196 router, 100, 130–31 unregistered, 66, 69–73 Address resolution protocol, 206–7 Address translation gateway, 164 Adjacency between neighbors, 103–5, 116–20, 123 Advanced mobile phone system, 5 Advertisement agent, 45, 54 router, 44–45 Agent advertisement, 45, 54 Air interface, 29 Alarm processing, 153–54 Always-on transmission, 8–9, 11

279

280 Authentication (continued) nontransparent mode, 184–95 registration request, 45 routers, 133–34 secure sockets layer, 241 security issues, 156, 159–60, 162, 169 smart cards, 248 Authentication register, 7 Authority, security and, 159 Authorization, mobile device, 31, 32 Autoconfiguration, 217, 218 Automatic home agent discovery, 46 Autonomous system, 88–89, 111, 114 Availability in security, 160, 162 m-business network, 145

B Backbone router, 122, 212 Backdoor, 158 Bandwidth efficiency, 82, 128–29 Base station, 4, 6, 11 Base station controller, 6, 9–10, 24, 26 Base transceiver station, 9, 24 Belle system, 155 BER. See Bit-error ratio Berbers, 163 BGP. See Border gateway protocol Billing general packet radio service, 16 nontransparent mode, 184, 187 transparent mode, 183 virtual private network, 191–92 Binding, 49–50, 218 Binding notify packet, 50–51, 52, 53 Bit-error ratio, 227 Blocking, address, 75 Bluetooth, 221–27 Bluetooth, Harald, 222 Border gateway protocol, 96, 206 version 4, 111–14, 131 Broadcast network, 121, 123, 124, 133 Brower technology, 250–51 BSC. See Base station controller BT Genie, 8

Mobile IP Technology for M-Business BTS. See Base transceiver station BT TrustWise Onsite, 173 Business users, 71

C C interface, 25 CA. See Certification authority Cache agent, 43, 50, 55 Calling party identification, 164 Call state control function, 193 Cap Gemini, 155 Card holder verification, 247 Care-of addressing, 40, 44–49, 55, 189, 218 Carrier-detect signal, 176 Catalogs, 141–42 CDMA. See Code division multiple access Cell repeat patterns, 4 Central management, 151 Central processing unit, 82 Certificate, public key encryption, 169–70, 172–73 Certification authority, 169–70, 172–73 Chain reaction failure, 149 Challenge system, 163 CHAP, 165 CHV. See Cardholder verification CIDR. See Classless interdomain routing Circuit-switched network, 8, 9, 12 Cisco Systems, 101, 103, 106, 127, 132, 155 Class A addressing, 61–62, 68–69, 73, 202, 204, 210 Class B addressing, 62–63, 68–69, 202–03, 210–11 Class C addressing, 63–69, 203, 211 Class D addressing, 61, 203–4 Class E addressing, 61 Classless interdomain routing, 69, 84–86, 131, 211–12 Closed user group, 164 “Cloud mindedness,” 148

Index Code division multiple access, 193, 233 Code division multiple access 2000, 234 COIN. See Community of interest network Common object request broker architecture, 251 Community of interest network, 174 Complete sequence number packet, 123–25 Confidentiality, security and, 160, 161 Configuration file, 207 Connection operation, GPRS, 12 Connection-oriented service, 60, 87 Connectionless service, 60, 87, 155, 195 Contention, address, 75 Convergence, network, 81–82, 92–93, 110, 126–27 CORBA. See Common object request broker architecture Cost, mobile business, 145, 147 Counting to infinity problem, 92–93, 96 CSCF. See Call state control function CSNP. See Complete sequence number packet

D Data access, mobile telephone network, 8 Data encryption standard, 167, 168 Database description packet, 123 Datagram, 201 Data link layer security, 165, 240–42 Data modification, 158–59 Data transfer, 207–8 DCE. See Distributed computing environment DCN0 network, 153 DCS-1800, 5 Dead time, 123 Decentralized management, 151 Demilitarized zone, 174

281 Denial of service, 158 DES. See Data encryption standard Designated router, 123–25 DHCP. See Dynamic host control protocol Dial back, 175 Diffie-Hellman algorithm, 168 Diffusing update algorithm, 107–10 Digest, message, 170–71 Digital signature, 49, 170–72 Dijkstra algorithm, 98, 116, 118, 125, 127, 128, 129 Direct attack, 158 Direct connection, 29–32 Discover packet, 74 Discovery process, 44–45 DIS. See Designated router Distance vector protocol bandwidth utilization, 128–29 convergence, 126–27 memory overhead, 129–30 operation, 80, 90–95, 108 versus link state protocol, 115–16 Distributed computing environment, 163 Distributed processing environment, 251 DMZ. See Demilitarized zone DNR. See Domain name resolver DNS. See Domain name service DoCoMo i-Mode, 138 Domain hierarchy, 209 Domain name resolver, 208 Domain name service, 24, 208–10 Domain name, transparent mode, 183 DPE. See Distributed processing environment DUAL. See Diffusing update algorithm Dynamic address allocation, 12, 23–24, 66, 73–76, 195, 217 benefits, 75 disadvantages, 75–76 Dynamic host control protocol, 24, 66, 73, 74, 75, 181, 189, 195 Dynamic port allocation, 208 Dynamic routing, 131

282

Mobile IP Technology for M-Business

E

F

Eavesdropping, 156 ECC encryption, 169 EGP. See Exterior gateway protocol EIGRP. See Enhanced interior gateway routing protocol Electronic commerce, 14 Electronic mail, 72 Electronic signature, 49, 161, 170–72 Electronic wallet, 143 Element manager, 152–53 EMV. See Europay, MasterCard, and Visa EN310 344 specification, 12, 74 Encapsulation, 26, 41–42, 46–48, 50, 202, 217, 219 minimal, 47–48 Encryption, 161, 164, 165–69, 187, 188, 216–17 End-to-end service, 10, 14–15, 22–23, 29, 30, 51–55 Enhanced gateway GPRS support node, 193 Enhanced home location register, 193 Enhanced interior gateway routing protocol, 103–11, 126–27, 128, 129 Enhanced serving GPRS support node, 193 EPOC system, 249–50 Equipment identity register, 6–7 Ericsson Corporation, 233 Errored packet rate, 155 Ethernet network, 121, 206–7 ETSI EN310 344 specification, 12, 74 Europay, MasterCard, and Visa, 244, 247–48 Europe, 138 Event notification message, 153–54 Expandability, network, 145–46 Exstart state, 117–18 Exterior gateway protocol, 80, 88–90, 96, 206 See also Border gateway protocol

FA. See Foreign agent Failure, network, 148–49 Fast switching, 109 FD. See Feasible distance Feasibility condition, 109–10 Feasible distance, 109 Feasible successor route, 109, 111 FH. See Frequency hopping File transfer protocol, 207 Filtering, 24, 129–30 Finite state machine, 108–10 Firewalls, 24, 56, 70, 73, 153, 164–65, 173–75, 188 Flapping link, 127 Flooding procedure, 96–98, 118–120, 129, 131 Flow label, 216 Foreign agent, 40–46, 49–54 Fragmentation, packet, 124–25, 215–16 Frame check sequence, 155 Frame relay network, 31, 121, 133, 163 Frequency hopping, 222, 239 Frequency reuse, 3 FTP. See File transfer protocol Full state, 118

G Gateway GPRS Support Node, 9–10, 11, 12, 23–24, 74, 180, 183–85, 187, 189, 193 Gateway to gateway protocol, 206 Gateways, 204–5. See also Routing General packet radio service characteristics, 8–9, 15–16, 22–23, 74 components, 9–10 deployment, 29–37 interfaces, 26–27 node architecture, 23–29 nontransparent mode, 180, 184–88 operation, 11–12 transmission path tiers, 27–29 transparent mode, 180–84, 188

Index user groups, 71–72 General packet radio service tunnel protocol, 11, 27–28 GGP. See Gateway to gateway protocol GGSN. See Gateway GPRS support node Gi interface, 26, 29 Global system for mobile communications, 5–7, 231, 244 Global system for mobile communications 1800, 5 Gn interface, 26 Gp interface, 26 GPRS. See General packet radio service Growth, network, 148, 152 GSM. See Global system for mobile communications GTP. See General packet radio service tunnel protocol

H HA. See Home agent Handheld devices, 138, 238–39 Hash function, 171 HDLC framing, 155 Header, transport control protocol, 198–99 Hello packet, 96, 104–7, 116, 120, 122, 123, 128, 206 HiperLan, 221 HLR. See Home location register Hold-down period, 104–5 Hold-down timer, 93–95, 126 Home agent, 40–42, 45–46, 49–54, 217 Home list, 49 Home location register, 12, 25, 74, 193 Home network, 217 Hop-by-hop routing, 112 Hop count, 90, 93, 100–3 Host, network, 204–5 HTTP. See Hypertext transfer protocol

283 Hypertext transfer protocol, 207, 240

I IBGP. See Internal border gateway protocol IBM Mobile Host Protocol, 55 IBM Transcode, 252 ICANN. See Internet Corporation for Names and Numbers IC Card Specification for Payment Systems, 247 IDEA. See International data encryption algorithm Idle period, 8 IEEE 802 standard, 123, 221 IETF. See Internet Engineering Task Force IGP. See Interior gateway protocol IGRP. See Interior gateway routing protocol IMHP. See Internet mobile host protocol i-Mode service, 138 IMSI. See International mobile subscriber identification IMT. See International mobile telecommunications IMT2000. See International mobile telecommunications 2000 Indirect connection, 31–32 Industrial-scientific-medical band, 222, 225 Information, current, 50–51 Information gathering, 159 Infrared Data Association, 222 Init state, 116 Integrated intermediate system to intermediate system, 96, 114, 121–28 Integrated services digital network, 131, 133 Integrity, security and, 160, 161, 169, 241 Interarea routing, 122, 123, 124, 125–26 Interfaces, GPRS, 26–27, 29

284 Interior gateway routing protocol, 80, 88–90, 101–3, 126, 128 Interleaving, 11 Intermediate system, 121 Intermediate system to intermediate system, 121–28 Internal border gateway protocol, 114 International data encryption algorithm, 167 International mobile subscriber identification, 183, 192 International mobile telecommunications, 7 International mobile telecommunications 2000, 231, 233–34 International Organization for Standardisation, 132 7816 protocol, 243, 244 International Telecommunications Union, 231 Internet circuit size, 183–84 commercial uses, 14 user groups, 71–72 Internet Corporation for Names and Numbers, 181 Internet Engineering Task Force, 40, 55, 91, 121, 217 Internet layer, 201 Internet mobile host protocol, 40, 50, 55 Internet protocol, 2, 27, 40, 195 addressing, 202–4 mapping addresses, 206–7 moving data, 207–8 names, 208–10 overview, 195–202 routing, 41–44, 204–6 version 4, 60–61, 181, 195, 199, 210–12 version 6, 196, 212–19 Internet protocol within Internet protocol, 46–47

Mobile IP Technology for M-Business Internet service provider, 22, 59, 181 Interoperability, router, 88, 132–33 Intra-area routing, 122, 123, 124, 125–26 IP. See Internet protocol IPcore scenario, 32–37 IPsec, 31, 72, 168, 169, 174, 184, 186, 187 IP-within-IP. See Internet protocol within Internet protocol IrDA, 221–25, 227–30 IrDA infrared link management protocol, 229 IrDA Link access protocol, 229 IrDA Object exchange protocol, 229–30 IrDA transport protocol, 229 IrLAP. See IrDA infrared link access protocol IrLMP. See IrDA infrared link management protocol IrOBEX. See IrDA object exchange protocol IS. See Intermediate system IS-95, 5 IS-136, 5 ISDN. See Integrated services digital network IS-IS. See Intermediate system to intermediate system ISM band. See Industrial-scientificmedical band ISO. See International Organization for Standardisation ISP. See Internet service provider ITU. See International Telecommunications Union

J Japan, 138 Java Card, 245–46 Java OS, 250 Java Remote Method Invocation, 252 Jini, 251–52 J-Phone, 138

Index

285

K

M

Keep alive message, 113 Key encryption, 166–69

M-business. See Mobile business MAC. See Medium access control Maintenance, network, 149–56 Manageability, network, 146 Management centralized and decentralized, 151 network, 152–56 Management information base, 154 Mapping addresses, 206–7 Market, mobile services dynamics, 14–16 history, 13–14 segmentation, 21–22 Masquerade, 159 Maximum transmission unit, 123, 128, 216 MD5 integrity check, 168 ME. See Mobile equipment Media gateway, 193 Media gateway control function, 193 Medium access control, 28 MEL. See Multos executable language Memory overhead, 82–83, 129–30 Meshing, network, 129 Message sequence numbering, 163 Metric, router, 90, 101–3, 106, 108, 129 MG. See Media gateway MGCF. See Media gateway control function MIB. See Management information base Micromuse, 155 Micropayment, 143 Microprocessor, 3 Microprocessor card, 243 Microsoft Corporation, 249, 252 Microsoft-Supplied Dial-Up Networking, 189 Minimal encapsulation, 47–48 Mobile business back-end components, 141–50 delivery architecture, 251–52 design requirements, 144–56 market growth, 137–38

L L2TP-enabled access concentrator, 184, 186 LAC. See L2TP-enabled access concentrator LAN. See Local-area network; Wireless local-area network Layered architecture, 200 Leased line, 31 Legacy system, 145–46, 162 Level 1/Level 2 routing, 122, 123, 124, 125–26 Limit the hop count, 93 Link security, 165, 240–42 Link state advertisement, 96–98, 124, 125, 129 Link state information, 118 Link state packet, 118–19, 123–25 Link state protocol bandwidth utilization, 128–29 integrated IS-to-IS, 121–26 memory overhead, 129 open shortest path first, 114–21 operation, 80, 96–98, 127 versus distance vector protocol, 115–16 LLC. See Logical link control Loading state, 118 Loaned address, 66, 181, 202 Local-area network, 82, 146, 215, 221 Location area, 5 Location cache, 50 Location information, 49–51, 55 Location management, 5 Logical domain, router, 86 Logical link control, 28 Logical tree, 209 LSA. See Link state advertisement LS information. See Link state information LSP. See Link state packet Lucent Technologies, 9

286 Mobile business (continued) network solutions, 150–51 uses, 138–41 See also Security, mobile business Mobile device requirements, 237–38 Mobile equipment, 33 Mobile host, 55 Mobile Internet protocol, 2, 55–56 Mobile phones, 137–38, 239 Mobile switching center, 6, 10 Mobile telephone network GSM standard, 5–7 overview, 3–5 Mobile virtual network operator, 29 Mobility-enabled IP centric network, 40 Mondex, 143 Motorola Corporation, 233 MSC. See Mobile switching center MSDUN. See Microsoft-Supplied Dial-Up Networking MTU. See Maximum transmission unit Multicarrier mode, 234 Multicast address, 61, 101, 105, 106, 213, 214–15 Multihoned network, 84, 86 Multos executable language, 247 Multos smart card, 246–247 MVNO. See Mobile virtual network operator

N Naming, Internet protocol, 208–10 Nanopayment, 143 NAT. See Network address translation NBMA. See Nonbroadcast multiaccess Neighbor table, 104 Neighbors advertisement, 44–45 discovery, 96–98, 103–5, 106, 107, 206, 218 flooding, 96–98, 118–19, 120, 129, 131 NET. See Network entity title NetMeeting, 72 Network access layer, 201–2

Mobile IP Technology for M-Business Network access link utilization, 155 Network address translation, 66, 70–72, 73 Network busy failure, 16 Network connection devices, 239 Network entity title, 122–23 Network layer reachability information, 113–14 security, 163 Network operations center, 153 Network tuning, 149 Next hop field, 101 NOC. See Network operations center Nodes general packet radio service, 23–29 network, 50, 153–54 Nokia Corporation, 9 Nokia 9110, 239 Nonbroadcast multiaccess network, 119, 120–21, 123, 133 Non-pseudo node link state packet, 124–25 Nontransparent access, 31–32, 180, 184–88 Nortel Networks, 9 Notification message, 113 Novell Networks, 95

O OBEX. See Object exchange protocol Object exchange protocol, 223, 229–30 Offer packet, 74 One-way function, 171 On-line services, 140–41 Open message, 113 Open shortest path first convergence, 127 link state database, 128 network types, 119–21 operation, 96, 114–21, 125, 206 Open standards, routing, 88, 132–33 Open systems interconnection, 121, 200 Operating systems, 249–51

Index Operational support systems, 155–56 Orchestream, 155 OS. See Operating systems OSI. See Open systems interconnection OSPF. See Open shortest path first OSS. See Operational support systems Overlay network, 153

P Packet control unit, 9–10, 25, 26 Packet data technology, 8. See also General packet radio service Packet drop rate, 155 Packet network security, 167 Palm OS, 249 PAN. See Personal access network PAP, 165 Partial meshing, 87, 133 Partial sequence number packet, 124 Partial update, 103, 105–6 Partnering, virtual private network, 191 Passive state, route, 108 Passwords, 126, 162, 164 Path attributes, border gateway protocol, 113 Path vector protocol, 80, 95–96, 111–14 Payload encryptor, 167 Payments systems, 142–43 PCMCIA card, 239 PC/SC. See Personal computer/ smart card PCU. See Packet control unit PDA. See Personal digital assistant Pepys, Samuel, 166 Performance m-business network, 145–49 network, routing and, 215–16 Personal access network, 8, 221–30 Personal computer/smart card, 244–45 Personal digital assistant, 223, 238–39 Personal Handyphone System, 239 PersonalJava, 250

287 PHS. See Personal Handyphone System Ping test, 154 PKI. See Public key infrastructure Point-of-sale terminal, 248 Point-to-multipoint network, 120, 121, 123 Point-to-point network, 119–20, 123, 130, 167 Point-to-point protocol, 165, 202 Poison reverse, 93, 94, 106 Polling, 154–55 Port number allocation, 208 POS terminal. See Point-of-sale terminal PPM. See Pulse position modulation PPP. See Point-to-point protocol Presentation, on-line products, 143–44 Privacy, 158–59, 216–17 Private address, 66, 69–73 Private key, 55, 167-69, 172, 173 Private network security, 163–64 Process switching, 109 Protocol number, 207 Protocol standards, 151–52 Proxy agent, 165 Proxy server, 175 Pseudo-node link state packet, 124–25 PSNP. See Partial sequence number packet Psuedo random number, 49 Public key certificate, 162 Public key encryption, 55, 241, 248 infrastructure, 167–73 Public switched telephone network, 131, 193 Pulse position modulation, 228 Push technology, 71

Q Qualcomm, 252 Quality of service, 16 Query packet, 106–7, 111

288

R RA. See Registration authority Radio link control, 28 Radio spectrum cellular system coverage, 3–5 shared usage, 8 Radius. See Remote-access dial-in user service RARP. See Reverse address resolution protocol Reachability, network, 88–90, 92–93, 103, 113–14 Registered address, 69, 72 Registration authority, 173 Registration, care-of address, 45–46, 52, 75 Registration lifetime, 48 Registration request, 49, 54 Reliability EIGRP packet transport, 105–7 m-business network, 145, 147, 149–56 router, 112–13 Remote-access dial-in user service, 184, 187 Remote access security, 175 Remote gateway protocol, 206 Remote method invocation, 252 Replay attack, 49 Reply packet, 106–7 Replay, transaction, 169 Request packet, 74, 100 Response packet, 100 Reverse address resolution protocol, 207 Reverse-direction packet, 56 RFC 791, 199 RFC 793, 197 RFC 1058, 93 RFC 1195, 121–22 RFC 1245, 129 RFC 1246, 129 RFC 1256, 45 RFC 1323, 197 RFC 1519, 84

Mobile IP Technology for M-Business RFC 1583, 115, 125 RFC 1723, 100 RFC 1771, 112 RFC 2002, 55 RFC 2328, 125 RGP. See Remote gateway protocol RIP. See Routing information protocol RIPE NCC (Reseaux IP European Network Control Centre), 75, 181 Risk, technical, 147 RLC. See Radio link control RMI. See Remote method invocation Roaming user, 34–36, 40 “Robbing” host address, 204 Root server, 209 Route tag field, 101 Router free memory, 155 Router peak processor utilization, 155 Routing/routers choosing protocol, 2, 126–34 gateway protocols, 88—90 as firewall, 164 Internet protocol, 204–6, 218–19 link state protocol, 96–98 loops, 116, 127 optimization, 218 overview, 79–81 path vector protocol, 80, 95–96, 111–14 polling, 155 router attributes, 81–88 See also Distance vector protocol; Link state protocol Routing information protocol, 91–92, 93, 115, 126, 128, 129, 205 operation, 98, 100 version 2, 100–1, 205 Routing table, 206, 212 Routing table maintenance protocol, 95 RSA (Rivest, Shamir, and Adleman) public key, 167, 168, 169 RTMP. See Routing table maintenance protocol

Index

289

S

TE

AM FL Y

SAM. See Secure application module Satellite television decoder card, 247 Scalability, router, 83, 89, 90, 130–31 Secure application module, 247–48 Secure electronic transaction, 171, 242 Secure sockets layer, 187, 208, 240–41 Security data link, 240–43 Internet protocol v6, 216–18 mobile transmission, 49, 55–56 nontransparent access, 187–88 protection techniques, 72–73 routers, 88, 101, 126, 133–34 smart cards, 243–49, 248 transparent access, 183, 188 user perceptions, 239 Security association, 216–17 Security, mobile business, 157 applications, 161–62 attack targets/types, 158–59 attacker types, 157–58 calling party identification, 164 closed user groups, 164 data link layer, 165 defenses, 159–60 dial back, 175 encryption, 165–73 firewalls, 164–65, 173–75 multiple levels, 161 network layer, 163 policies, 160–61 private networks/ circuits, 73, 163–64 remote access, 175 session layers, 162–63 tailgating prevention, 175–76 Seiko Ruputer, 239 Service independence, router, 87, 131–32 Serving GPRS support node, 9–10, 11, 24–26, 189, 193 Session layer security, 162–63 Session management, 164

SET. See Secure electronic transaction Settlement, on-line payment, 143 SGSN. See Serving GPRS support node SGW. See Signaling gateway SHA integrity checking, 168 Shannon, Claude, 166 Shared medium, 8 Short message service, 13–14, 138, 238, 239 Shortest path first, 96, 98–99, 116, 118, 127. See also Open shortest path first Signaling gateway, 193 SIM card. See Subscriber identification module card Simple mail transfer protocol, 200, 207 Simple network management protocol, 72, 151, 153, 154 Simplicity, security and, 161 Skipjack algorithm, 166–67 “Sledgehammer” techniques, 169 Slow convergence, 93 Smart cards, 143, 243–49 SMS. See Short message service SNDCP. See Sub-network dependent convergence protocol SNMP. See Simple network management protocol Socket, 208, 240 Sony mobile host protocol, 55 Source routing, 218–19 SPF. See Shortest path first Split horizon, 93, 94, 106, 107, 202 Splitting network concept, 122 Spread-spectrum radio, 5 SSL. See Secure sockets layer Stability, router, 86–87, 103, 126, 131, 132 Start-up security, 163 Stateless autoconfiguration, 217, 218 Static addressing, 12, 40, 74 Static routing, 131 Status polling, 163 Stub area flag, 123 Subnet mask, 67–68, 100, 130–31, 204, 211

290 Subnetting, 66–68, 83–84, 100, 204 Sub-network dependent convergence protocol, 28 Subscriber identification module, 7, 12, 33, 74, 247 Sun Microsystems, 155, 245–46, 250–52 Supernetting, 68–69, 84–86 SVC. See Switched virtual circuit Switched virtual circuit, 131 Symbian EPOC, 249–50 Symmetric algorithm, 168 System administrator, 206

T TACS. See Total access communications system Tailgating, 175–76 TCP. See Transport control protocol TDMA. See Time division multiple access Technology independence, router, 87, 131–32 Telecommunications information networking architecture, 251 Telecommunications operations map, 155–56 Telnet, 207, 208 Termination, mobile packet, 48–49 Third generation mobile, 7, 231–32 data implications, 234–35 migration to, 233–34 Third-Generation Partnership Project, 192–93 Third-party services, 16 3G. See Third generation mobile 3GPP. See Third-Generation Partnership Project Time division multiple access, 233, 234 Timer, hold-down, 93–95 Time stamp, 49, 50 TINA. See Telecommunications information networking architecture Tiny TP. See IrDA transport protocol

Mobile IP Technology for M-Business Token, security, 162, 163 Token-ring local-area network, 121 TOM. See Telecommunications operations map Topology table, 106, 107–8, 109, 129 Total access communications system, 5 Traffic analysis attack, 241 Traffic congestion, 149 Transparent access, 31, 180–84, 188, 192 Transport control protocol, 27, 60, 112–13, 207 Transport control protocol/Internet protocol, 196–202 Transport layer, 201, 207–8, 240 Trap processing, 153–54 Travel, business, 139–40 Triangle routing, 56 Triple data encryption standard, 168 Trojan horse, 158 Tunnel header, 46 Tunneling methods, 31, 46–48, 52, 54, 71, 180, 184, 189, 217 Tunneling protocol, 11, 27–28 Turn-key solution, 15 Two-way state, 116–17

U UDP. See User datagram protocol UMTS. See Universal mobile telecommunications service Unexpected events, 149 Unicast address, 213–14 Uniformity of access, 188 United Kingdom, 21–22 Universal mobile telecommunications service, 7, 231–33, 234–35 UNIX system, 209 Unregistered address, 66, 69–73 Update packet, 106, 113–14, 116, 118, 119, 129 User datagram protocol, 27, 100, 196, 199, 201, 207 User groups, 71–72 User needs, 145

Index

V Variable-length field, 123 Variable-length subnet mask, 83–84, 115, 130 Verisign, 169 VHE. See Virtual home environment Virtual home environment, 235 Virtual Machine, 245–46 Virtual private network, 168 nontransparent mode, 187–188 overview, 189–192 security, 163 transparent mode, 188 Visitor list, 49 Visitor location register, 6, 25 VLR. See Visitor location register VLSM. See Variable-length subnet mask VM. See Virtual Machine VPN. See Virtual private network

W WAN. See Wide-area network

291 WAP. See Wireless access protocol WCDMA. See Wideband code division multiple access Web browsers, 250–51 Wide-area network, 65, 82, 146, 147, 215 Wideband code division multiple access, 233–34 Windows CE, 249 Wireless access protocol, 16, 71–72, 138, 144 Wireless Knowledge, 252 Wireless local-area network, 8, 221 Withdrawn routes field, 113 WLAN. See Wireless local-area network Wristwatches, 239

X X.25 network, 10, 11, 27, 121, 131, 163, 164