Computer
`Networks
`
`Prepared by Prulcn'ur limud Almclcla. Uniwrsily nf' Al.maximums/Durhmmlb
`
`NETWORK SIMULATION EXPERIMENTS MANUAL
`
`|PR2016-01106
`
`A Systems Approach
`
`EMC Exhibit 1030
`
`EMC V. Intellectual Ventures
`
`

`

`

`

`The Morgan Kaufmann Series in Networking
`
`Series Editor, David Clark, M.I.T.
`
`Computer Networks: A Systems Approach, 3 e
`Larry L. Peterson and Bruce 5. Davie
`Network Architecture, Analysis, and Design, 2e
`James D. McCabe
`MPLS Network Management: MIBs, Tools, and Techniques
`Thomas D. Nadeau
`
`Developing IP—Based Services: Solutions for Service Providers and Vendors
`Monique Morrow and Kateel Vijayananda
`Telecommunications Law in the Internet Age
`Sharon K. Black
`
`Optical Networks: A Practical Perspective, 2e
`Rajiv Ramaswami and Kumar N. Sivarajan
`Internet QoS: Architectures and Mechanisms
`Zheng Wang
`TCP/IP Sockets in java: Practical Guide for Programmers
`Michael J. Donahoo and Kenneth L. Calvert
`TCP/IP Sockets in C: Practical Guide for Programmers
`Kenneth L. Calvert and Michael J. Donahoo
`Multicast Communication: Protocols, Programming, and Applications
`Ralph Wittmann and Martina Zitterbart
`MPLS: Technology and Applications
`Bruce Davie and Yakov Rekhter
`
`High—Performance Communication Networks, 2e
`Jean Walrand and Pravin Varaiya
`Internetworking Multimedia
`Jon Crowcroft, Mark Handley, and Ian Wakeman
`Understanding Networked Applications: A First Course
`David G. Messerschmitt
`
`Integrated Management of Networked Systems: Concepts, Architectures,
`and their Operational Application
`Heinz—Gerd Hegering, Sebastian Abeck, and Bernhard Neumair
`Virtual Private Networks: Making the Right Connection
`Dennis Fowler
`
`Networked Applications: A Guide to the New Computing Infrastructure
`David G. Messerschmitt
`
`Modern Cable Television Technology: Video, Voice, and Data Communications
`Walter Ciciora, James Farmer, and David Large
`Switching in IP Networks: IP Switching, Tag Switching, and Related Technologies
`Bruce 5. Davie, Paul Doolan, and Yakov Rekhter
`Wide Area Network Design: Concepts and Tools for Optimization
`Robert S. Cahn
`
`Frame Relay Applications: Business and Technology Case Studies
`James P. Cavanagh
`
`For further information on these books and for a list of forthcoming titles, please visit
`our website at http://www.mkp.com
`
`

`

`THIHI] EDITIUN
`
`Larry L. Peterson 86 Bruce S. Davie
`
`W
`
`A Systems Approach
`
`M ’4®
`
`MORGAN KAUFMANN PUBLISHERS
`
`AN IMPRINT OF ELSEVIER SCIENCE
`A M S T E R D A M
`B O S T O N
`L O N D O N
`N E W Y O RK
`O X F 0 R D
`P A R | S
`S A N D | E G O
`S A N F R A N C | S C0
`S | N G A P O R E
`S Y D N E Y
`T O K YO
`
`

`

`Senior Editor Rick Adams
`
`Publishing Services Manager Simon Crump
`Developmental Editor Karyn Johnson
`Cover Design Ross Carron Design
`Cover Image Vasco de Gama Bridge, Lisbon, Portugal
`Composition/Illustration International Typesetting and Composition
`Copyeditor Ken DellaPenta
`Proofreader
`Jennifer McClain
`Indexer Steve Rath
`
`Printer Courier Corporation
`
`Designations used by companies to distinguish their products are often claimed as trademarks
`or registered trademarks. In all instances in which Morgan Kaufmann Publishers is aware of a
`claim, the product names appear in initial capital or all capital letters. Readers, however, should
`contact the appropriate companies for more complete information regarding trademarks and
`registration.
`
`Morgan Kaufmann Publishers
`An Imprint of Elsevier Science
`340 Pine Street, Sixth Floor
`San Francisco, CA 94104—3205
`www.mkp.com
`
`© 2003 by Elsevier Science (USA)
`All rights reserved
`Printed in the United States of America
`
`0706050403
`
`54321
`
`No part of this publication may be reproduced, stored in a retrieval system, or transmitted in
`any form or by any means—electronic, mechanical, photocopying, or otherwise—without the
`prior written permission of the publisher.
`
`Library of Congress Control Number: xxxxxxxxxx
`ISBN: 1—55860—832—X (Casebound)
`
`ISBN: 1—55860—833—8 (Paperback)
`
`This book is printed on acid—free paper.
`
`

`

`212
`
`3 Packet Switching
`
`This is sometimes called the packet per sec—
`
`ond (pps) rate. (This number is representa—
`
`tive of what is achievable on today’s high—
`
`end PCs.) If the average packet is short, say,
`
`64 bytes, this would imply
`
`Defining Throughput
`It turns out to be difficult to de-
`
`fine precisely the throughput of a
`
`switch. Intuitively, we might think
`
`Throughput = pps X (BitsPerPacket)
`
`that if a switch has 71 inputs that
`
`=500X103x64x8
`
`= 256 x 106
`
`that
`
`is, a throughput of 256 Mbps—
`
`substantially below the range that users are
`
`demanding from their networks today. Bear
`
`in mind that this 256 Mbps would be shared
`
`by all users connected to the switch, just as
`
`the 10 Mbps of an Ethernet is shared among
`all users connected to the shared medium.
`
`Thus, for example, a 10—port switch with
`
`this aggregate throughput would only be
`
`able to cope with an average data rate of
`
`25.6 Mbps on each port.
`
`To address this problem, hardware de—
`
`signers have come up with a large array
`
`of switch designs that reduce the amount
`
`of contention and provide high aggregate
`
`throughput. Note that some contention is
`
`unavoidable: If every input has data to send
`
`to a single output, then they cannot all send
`it at once. However, if data destined for dif—
`
`ferent outputs is arriving at different inputs,
`
`a well—designed switch will be able to move
`
`data from inputs to outputs in parallel, thus
`
`increasing the aggregate throughput.
`
`3.4. 1 Ports
`
`Most switches look conceptually similar to
`
`the one shown in Figure 3.28. They con—
`sist of a number of input ports and output
`
`ports and a fabric. There is usually at least
`
`6
`
`each support a link speed of s,- , then
`
`the throughput would just be the
`
`sum of all the 5,. This is actually
`
`the best possible throughput that
`
`such a switch could provide, but
`
`in practice almost no real switch
`
`can guarantee that level of perfor-
`mance. One reason for this is sim-
`
`ple to understand. Suppose that, for
`
`some period of time, all the traf-
`
`fic arriving at the switch needed
`
`to be sent to the same output. As
`
`long as the bandwidth of that out-
`
`put is less than the sum of the input
`bandwidths, then some of the traf-
`fic will need to be either buffered
`
`or dropped. With this particular
`
`traffic pattern,
`
`the switch could
`
`not provide a sustained through-
`
`put higher than the link speed of
`
`that one output. However, a switch
`
`might be able to handle traffic ar-
`
`riving at the full link speed on all
`
`inputs if it is distributed across all
`
`the outputs evenly; this would be
`
`considered optimal.
`Another
`factor
`
`that affects
`
`the performance of switches is the
`
`the size of packets arriving on the
`
`inputs. For an ATM switch,
`
`this
`
`is normally not an issue because
`
`

`

`3.4 Implementation and Performance
`
`213
`
`all “packets” (cells) are the same
`
`length. But for Ethernet switches
`
`or IP routers, packets of widely
`
`varying sizes are possible. Some of
`
`the operations that a switch must
`
`perform have a constant overhead
`
`per packet, so a switch is likely
`
`to perform differently depending
`
`on whether all arriving packets are
`
`very short, very long, or mixed.
`For this reason, routers or switches
`
`that forward variable-length pack-
`
`ets are often characterized by a
`
`packet per second (pps) rate as well
`
`as a throughput in bits per second.
`
`The pps rate is usually measured
`
`with minimum-sized packets.
`
`The first thing to notice about
`
`this discussion is that the through-
`
`put of the switch is a function of the
`
`traffic to which it is subjected. One
`
`of the things that switch designers
`
`spend a lot of their time doing is
`
`trying to come up with traffic mod-
`
`els that approximate the behavior
`of real data traffic. It turns out that
`
`it is extremely difficult to achieve
`accurate models. A traffic model at-
`
`tempts to answer several important
`
`questions: (1) When do packets ar-
`
`rive? (2) What outputs are they des-
`
`tined for? And (3) how big are they?
`
`Traffic modeling is a well-
`established science that has been
`
`extremely successful in the world of
`
`telephony, enabling telephone com-
`
`panies to engineer their networks
`
`one control processor in charge of the whole
`
`switch that communicates with the ports
`
`either directly or, as shown here, Via the
`
`switch fabric. The ports communicate with
`
`the outside world. They may contain fiber
`
`optic receivers and lasers, buffers to hold
`
`packets that are waiting to be switched or
`
`transmitted, and often a significant amount
`
`of other circuitry that enables the switch
`
`to function. The fabric has a very simple
`
`and well—defined job: When presented with
`
`a packet, deliver it to the right output port.
`
`One of the jobs of the ports, then, is to
`
`deal with the complexity of the real world
`
`in such a way that the fabric can do its
`
`relatively simple job. For example, suppose
`
`that this switch is supporting a Virtual cir—
`
`cuit model of communication. In general,
`
`the Virtual circuit mapping tables described
`
`in Section 3.1.2 are located in the ports.
`
`The ports maintain lists of Virtual circuit
`
`identifiers that are currently in use, with
`
`information about what output a packet
`should be sent out on for each VCI and
`
`how the VCI needs to be remapped to ensure
`
`uniqueness on the outgoing link. Similarly,
`
`the ports of an Ethernet switch store tables
`
`that map between Ethernet addresses and
`
`output ports (bridge forwarding tables as
`
`described in Section 3.2). In general, when
`
`a packet is handed from an input port to
`
`the fabric, the port has figured out where
`
`the packet needs to go, and either the port
`
`sets up the fabric accordingly by comm—
`
`unicating some control information to it, or
`
`it attaches enough information to the packet
`
`itself (e.g., an output port number) to al—
`
`low the fabric to do its job automatically.
`
`Fabrics that switch packets by looking only
`
`7
`
`

`

`214
`
`3 Packet Switching
`
`at the information in the packet are referred
`L
`a
`to as ‘self—routing,’ since they require no
`
`external control to route packets. An ex—
`
`ample of a self—routing fabric is discussed
`below.
`
`The input port is the first place to
`
`look for performance bottlenecks. The in—
`
`put port has to receive a steady stream of
`
`packets, analyze information in the header
`
`of each one to determine which output port
`
`(or ports) the packet must be sent to, and
`
`pass the packet on to the fabric. The type of
`
`header analysis that it performs can range
`
`from a simple table lookup on a VCI to
`
`complex matching algorithms that examine
`
`many fields in the header. This is the type of
`
`operation that sometimes becomes a prob—
`
`lem when the average packet size is very
`
`small. For example, 64—byte packets arriv—
`
`ing on a port connected to an 0048 link
`
`have to process packets at a rate of
`
`2.48 x 109 + (64 x 8): 4.83 x 106 pps
`
`In other words, when small packets are
`
`arriving as fast as possible on this link (the
`
`worst—case scenario that most ports are
`
`engineered to handle), the input port has
`
`approximately 200 nanoseconds to process
`
`each packet.
`
`Another key function of ports is
`
`buffering. Observe that buffering can hap—
`
`pen in either
`
`the input or the output
`
`port; it can also happen within the fab—
`
`ric (sometimes called internal buffering).
`
`Simple input buffering has
`
`some seri—
`
`ous limitations. Consider an input buffer
`
`to carry expected loads quite effi-
`
`ciently. This is partly because the
`
`way people use the phone network
`
`does not change that much over
`
`time: The frequency with which
`
`calls are placed, the amount of time
`
`taken for a call, and the tendency of
`
`everyone to make calls on Mother’s
`
`Day have stayed fairly constant for
`many years.4 By contrast, the rapid
`evolution of computer communi-
`
`cations, where a new application
`
`like Napster can change the traffic
`
`patterns
`
`almost overnight, has
`
`made effective modeling of com—
`
`puter networks much more diffi-
`cult. Nevertheless, there are some
`excellent books and articles on the
`
`subject that we list at the end of the
`
`chapter.
`
`To give you a sense of the range
`
`of throughputs that designers need
`
`to be concerned about, a high-end
`router used in the Internet at the
`
`time of writing might support 10
`
`OC—192 links for a throughput of
`
`approximately 100 Gbps. A 100-
`
`Gbps switch, if called upon to han-
`
`dle a steady stream of 64-byte pack-
`
`ets, would need a packet per second
`rate of
`
`100 x 109 + (64 x 8)
`
`= 195 X 106 pps
`
`4This statement has recently become less true with the advent of fax machines and modem connections to
`the Internet.
`
`8
`
`

`

`3.4 Implementation and Performance
`
`215
`
`Elia;
`
`Figure 3.28 A 4 )< 4 switch.
`
`Port 1
`
`Port 2
`
`
`
`Figure 3.29 Simple illustration of head-of—Iine blocking.
`
`implemented as a FIFO. As packets arrive at the switch, they are placed in the input
`
`buffer. The switch then tries to forward the packets at the front of each FIFO to their
`
`appropriate output port. However, if the packets at the front of several different input
`
`ports are destined for the same output port at the same time, then only one of them
`can be forwarded;5 the rest must stay in their input buffers.
`The drawback of this feature is that those packets left at the front of the input
`
`buffer prevent other packets further back in the buffer from getting a chance to go
`
`to their chosen outputs, even though there may be no contention for those outputs.
`
`This phenomenon is called head-of-line blocking. A simple example of head-of-line
`
`blocking is given in Figure 3.29, where we see a packet destined for port 1 blocked
`
`behind a packet contending for port 2. It can be shown that when traffic is uni-
`
`formly distributed among outputs, head-of-line blocking limits the throughput of an
`
`5 For a simple input-buffered switch, exactly one packet at a time can be sent to a given output port. It is possible
`to design switches that can forward more than one packet to the same output at once, at a cost of higher switch
`complexity, but there is always some upper limit on the number.
`
`9
`
`

`

`216
`
`3 Packet Switching
`
`input—buffered switch to 59% of the theoretical maximum (which is the sum of the
`
`link bandwidths for the switch). Thus, the majority of switches use either pure out—
`
`put buffering or a mixture of internal and output buffering. Those that do rely on
`
`input buffers use sophisticated buffer management schemes to avoid head—of—line
`
`blocking.
`
`Buffers actually perform a more complex task than just holding onto packets
`
`that are waiting to be transmitted. Buffers are the main source of delay in a switch,
`
`and also the place where packets are most likely to get dropped due to lack of space
`
`to store them. The buffers therefore are the main place where the quality of service
`
`characteristics of a switch are determined. For example, if a certain packet has been
`
`sent along a VG that has a guaranteed delay, it cannot afford to sit in a buffer for very
`
`long. This means that the buffers, in general, must be managed using packet scheduling
`
`and discard algorithms that meet a wide range of QoS requirements. We talk more
`
`about these issues in Chapter 6.
`
`3.4.2 Fabrics
`
`While there has been an abundance of impressive research conducted on the design
`
`of efficient and scalable fabrics, it is sufficient for our purposes here to understand
`
`only the high—level properties of a switch fabric. A switch fabric should be able to
`
`move packets from input ports to output ports with minimal delay and in a way that
`
`meets the throughput goals of the switch. That usually means that fabrics display
`
`some degree of parallelism. A high—performance fabric with n ports can often move
`
`one packet from each of its 11 ports to one of the output ports at the same time. A
`
`sample of fabric types includes the following:
`
`I Shared-bus: This is the type of “fabric” found in a conventional workstation
`used as a switch, as described above. Because the bus bandwidth determines
`
`the throughput of the switch, high—performance switches usually have spe—
`
`cially designed busses rather than the standard busses found in PCs.
`
`I Shared-memory: In a shared—memory switch, packets are written into a mem—
`
`ory location by an input port and then read from memory by the output ports.
`
`Here it is the memory bandwidth that determines switch throughput, so wide
`
`and fast memory is typically used in this sort of design. A shared—memory
`
`switch is similar in principle to the shared—bus switch, except it usually uses a
`
`specially designed, high—speed memory bus rather than an I/O bus.
`
`I Crossbar: A crossbar switch is a matrix of pathways that can be configured
`
`to connect any input port to any output port. Figure 3.30 shows a 4 x 4
`
`10
`
`

`

`3.4 Implementation and Performance
`
`217
`
`
`
`Figure 3.30 A 4 x 4 crossbar switch.
`
`crossbar switch. The main problem with crossbars is that, in their simplest
`
`form, they require each output port to be able to accept packets from all inputs
`
`at once, implying that each port would have a memory bandwidth equal to the
`
`total switch throughput. In reality, more complex designs are typically used
`
`to address this issue (see, for example, the Knockout switch and McKeown’s
`
`virtual output—buffered approach in the “Further Reading” section at the end
`
`of the chapter).
`
`I Self-routing: As noted above, self—routing fabrics rely on some information
`
`in the packet header to direct each packet to its correct output. Usually, a
`
`special “self—routing header” is appended to the packet by the input port af—
`
`ter it has determined which output the packet needs to go to, as illustrated
`
`in Figure 3.31; this extra header is removed before the packet leaves the
`
`switch. Self—routing fabrics are often built from large numbers of very sim—
`
`ple 2 x 2 switching elements interconnected in regular patterns, such as the
`
`banyan switching fabric shown in Figure 3.32. For some examples of self—
`
`routing fabric designs, see the “Further Reading” section at the end of this
`
`chapter.
`
`Self—routing fabrics are among the most scalable approaches to fabric design, and
`
`there has been a wealth of research on the topic, some of which is listed in the “Further
`
`Reading” section. Many self—routing fabrics resemble the one shown in Figure 3.32,
`
`11
`
`

`

`218
`
`3 Packet Switching
`
`111%
`:Q
`
`Original packet
`header
`
`(a)
`
`CC!
`
`Self-routing
`header
`
`(b)
`
`"a;
`
`(c)
`
`Figure 3.31 A self-routing header is applied to a packet at input to enable the fabric to
`send the packet to the correct output, where it is removed. (a) Packet arrives at input
`port. (b) Input port attaches self-routing header to direct packet to correct output. (c)
`Self-routing header is removed at output port before packet leaves switch.
`
`consisting of regularly interconnected 2 X 2 switching elements. For example, the 2 x 2
`
`switches in the banyan network perform a simple task: They look at 1 bit in each self-
`
`routing header and route packets toward the upper output if it is 0 or toward the
`
`lower output if it is 1. Obviously, if two packets arrive at a banyan element at the
`
`12
`
`

`

`3.4 Implementation and Performance
`
`219
`
`001
`
`011
`
`110
`
`111
`
`001
`
`110 111
`
`011
`
`
`
`Figure 3.32 Routing packets through a banyan network. The 3-bit numbers represent
`values in the self-routing headers of four arriving packets.
`
`same time and both have the bit set to the same value, then they want to be routed
`
`to the same output and a collision will occur. Either preventing or dealing with these
`
`collisions is a main challenge for self—routing switch design. The banyan network is a
`
`clever arrangement of 2 X 2 switching elements that routes all packets to the correct
`
`output without collisions if the packets are presented in ascending order.
`
`We can see how this works in an example, as shown in Figure 3.32, where the
`
`self—routing header contains the output port number encoded in binary. The switch
`
`elements in the first column look at the most significant bit of the output port number
`
`and route packets to the top if that bit is a 0 or the bottom if it is a 1. Switch elements
`in the second column look at the second bit in the header, and those in the last column
`
`look at the least significant bit. You can see from this example that the packets are
`
`routed to the correct destination port without collisions. Notice how the top outputs
`
`from the first column of switches all lead to the top half of the network, thus getting
`
`packets with port numbers 0—3 into the right half of the network. The next column
`
`gets packets to the right quarter of the network, and the final column gets them to the
`
`right output port. The clever part is the way switches are arranged to avoid collisions.
`
`Part of the arrangement includes the “perfect shuffle” wiring pattern at the start of
`
`the network. To build a complete switch fabric around a banyan network would require
`
`additional components to sort packets before they are presented to the banyan. The
`
`Batcher—banyan switch design is a notable example of such an approach. The Batcher
`
`network, which is also built from a regular interconnection of 2 X 2 switching elements,
`
`13
`
`

`

`220
`
`3 Packet Switching
`
`sorts packets into descending order. On leaving the Batcher network, the packets are
`
`then ready to be directed to the correct output, with no risk of collisions, by the banyan
`network.
`
`One of the interesting things about switch design is the wide range of different
`
`types of switches that can be built using the same basic technology. For example,
`
`the Ethernet switches and ATM switches discussed in this chapter, as well as Internet
`
`routers discussed in the neXt chapter, are all built using designs such as those outlined
`in this section.
`
`3.5 Summary
`
`This chapter has started to look at some of the issues involved in building large scalable
`
`networks by using switches, rather than just links, to interconnect hosts. There are
`
`several different ways to decide how to switch packets; the two main ones are the
`
`datagram (connectionless) model and the virtual circuit (connection—oriented) model.
`
`An important application of switching is the interconnection of shared—media
`
`LANs. LAN switches, or bridges, use techniques such as source address learning to
`
`improve forwarding efficiency and spanning tree algorithms to avoid looping. These
`
`switches are extensively used in data centers, campuses, and corporate networks.
`
`The most widespread uses of virtual circuit switching are in Frame Relay and
`
`ATM switches. ATM introduces some particular challenges through the use of cells,
`
`short fixed—length packets. The availability of relatively high—throughput ATM switches
`
`has contributed to the acceptance of the technology, although it has certainly not swept
`
`all other technologies aside as some predicted. One of the main uses of ATM today is
`
`to interconnect widely separated sites in corporate networks.
`
`Independent of the specifics of the switching technology, switches need to forward
`
`packets from inputs to outputs at a high rate, and in some circumstances, switches
`
`need to grow to a large size to accommodate hundreds or thousands of ports. Building
`
`switches that both scale and offer high performance at acceptable cost is complicated
`
`by the problem of contention, and as a consequence, switches often employ special—
`
`purpose hardware rather than being built from general—purpose workstations.
`In addition to the issues of contention discussed here, we observe that the related
`
`problem of congestion has come up throughout this chapter. We will postpone our
`
`discussion of congestion control until Chapter 6, after we have seen more of the
`
`network architecture. We do this because it is impossible to fully appreciate congestion
`
`(both the problem and how it to address it) without understanding both what happens
`
`inside the network (the topic of this and the neXt chapter) and what happens at the
`
`edges of the network (the topic of Chapter 5).
`
`14
`
`

`

`Further Reading
`
`221
`
`ATM was originally envisioned by
`
`many of its proponents as the foun-
`dation for the “Broadband Integrated
`Services Digital Network,” and it was
`
`predicted in some quarters that ATM
`
`would displace all other networking
`
`O P E N I S S U E
`
`The Future of ATM
`
`technologies. Hosts would acquire
`
`ATM adaptors instead of Ethernet ports, enabling “ATM to the desktop.” Phone
`
`companies everywhere would deploy ATM, and as the technology that supports all
`
`media types—voice, video, and data—it would remove the need for any other type of
`network.
`
`It is now apparent that this scenario is unlikely to play out. The success of Eth-
`
`ernet switches in particular has killed off the ATM-to-the-desktop movement. Gigabit
`
`Ethernet and 10-Gigabit Ethernet technologies have successfully addressed the need
`
`for high-speed connections to servers where ATM might once have been used. In fact,
`
`we now hear ATM referred to as a “legacy protocol,” a term that was much used in
`
`the heyday of ATM to refer to older protocols.
`
`Another factor that has limited the acceptance of ATM has been the success of
`
`the Internet. It is now a fact of life that consumers are willing to pay for Internet
`
`access, and that means selling a service that delivers IP packets. While ATM can be
`
`used to help deliver that service (as it is in many DSL networks, for example), simply
`
`selling ATM connections to consumers does not meet their data networking needs. The
`
`notable exception is corporate customers looking to interconnect many sites, where
`
`an ATM VC may be just the right thing to economically replace a leased line. In fact,
`
`this is the primary niche for ATM today—it is used (in conjunction with Frame Relay)
`
`to provide wide area virtual circuit services to corporate networking customers.
`
`The future of ATM therefore seems to hinge on the future of wide area virtual
`
`circuit-based services. These services are unlikely to go away any time soon, but ATM’s
`
`role is to some extent being challenged by newer technologies, such as encrypted IP
`
`tunnels and Multiprotocol Label Switching (MPLS). Both of these technologies will
`
`be described in the next chapter.
`
`FURTHER READING
`
`The seminal paper on bridges, in particular the spanning tree algorithm, is the article
`
`by Perlman below. There is a wealth of survey papers on ATM; the article by Turner,
`
`an ATM pioneer, is one of the earliest to propose the use of a cell-based network for
`
`integrated services. The third paper describes the Sunshine switch and is especially
`
`15
`
`

`

`Glossary
`
`739
`
`statistical multiplexing: Demand—based multiplexing of multiple data sources over a
`shared link or channel.
`
`stop—and—wait: A reliable transmission algorithm in which the sender transmits a
`
`packet and waits for an acknowledgment before sending the next packet. Compare
`
`with sliding window and concurrent logical channels. See also ARQ.
`
`STS: Synchronous Transport Signal. The prefix for various rates of SONET transmis—
`
`sion. For example, STS—1 refers to the SONET standard for 51.84—Mbps transmission.
`
`subnetting: The use of a single IP network address to denote multiple physical net—
`
`works. Routers within the subnetwork use a subnet mask to discover the physical
`
`network to which a packet should be forwarded. Subnetting effectively introduces a
`third level to the two—level hierarchical IP address.
`
`SunRPC: Remote procedure call protocol developed by Sun Microsystems. SunRPC
`
`is used to support NFS. See also ONC.
`
`switch: A network node that forwards packets from inputs to outputs based on header
`
`information in each packet. Differs from a router mainly in that it typically does not
`
`interconnect networks of different types.
`
`switching fabric: The component of a switch that directs packets from their inputs to
`
`the correct outputs.
`
`T1: A standard telephone carrier service equal to 24 ISDN circuits, or 1.544 Mbps.
`Also called D51.
`
`T3: A standard telephone carrier service equal to 24 T1 circuits, or 44.736 Mbps.
`Also called D53.
`
`TCP: Transmission Control Protocol. Connection—oriented transport protocol of the
`
`Internet architecture. TCP provides a reliable, byte—stream delivery service.
`
`Telnet: Remote terminal protocol of the Internet architecture. Telnet allows you to
`
`interact with a remote system as if your terminal is directly connected to that machine.
`
`throughput: The observed rate at which data is sent through a channel. The term is
`
`often used interchangeably with bandwidth.
`
`16
`
`