×

Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

High-Speed Networks: TCP/IP and ATM Design Principles
     

High-Speed Networks: TCP/IP and ATM Design Principles

by William Stallings
 
High Speed Networks: TCP/IP and ATM Design presents integrated, up-to-date coverage of key issues in high-speed TCP/IP and ATM network design. Surveys developments in high-speed networks to provide a solid grasp of technical design issues related to carrying large volumes of traffic with differing quality-of-service requirements at very high data

Overview

High Speed Networks: TCP/IP and ATM Design presents integrated, up-to-date coverage of key issues in high-speed TCP/IP and ATM network design. Surveys developments in high-speed networks to provide a solid grasp of technical design issues related to carrying large volumes of traffic with differing quality-of-service requirements at very high data rates. Covering basic technology as well as new traffic control standards for the asynchronous transfer mode (ATM) in WANs and LANs, this book presents a range of related topics. Among these are: next-generation Internet technology; high-speed (100 Mbps) and Gigabit Ethernet; TCP performance design issues; unicast and multicast routing; and compression. Also covers self-similar traffic with an explanation of the mathematics behind it for the first time in any book. In addition, it presents math essential for understanding the issues of high-speed network performance and design. There is a web page (...

Editorial Reviews


Fatbrain Review

This comprehensive, integrated book presents integrated, up-to-date coverage of the key issues in the design of high-speed TCP/IP and ATM networks. It reviews network protocols, network fundamentals, TCP/IP architecture and ATM protocol architecture. Based on ATM nets, the book discusses packet, cell and frame relay networks. It also focuses on transportation, network level traffic modeling, analysis and management. Performance modeling and estimation is covered with respect to queuing, throughput, buffer and delay requirements. This is followed by modeling and analysis approaches for self-similar traffic. Specific chapters address end-to-end system traffic management, performance parameters, throughput techniques and link/transport level flow control issues. Other chapters survey IP switching and routing approaches, including distance vector, path vector, link-state and multicast. Finally, the text investigates lossless and lossy compression techniques.

Booknews
With over 15 titles on related topics to his credit, Stallings now canvasses the rapidly evolving world of high-speed (including gigabit) networks for students and professionals. Coverage spans: protocol and network fundamentals, high-speed networks, performance modeling and estimation, end-system traffic management, network traffic management, Internet routing, and compression. Includes problems, a glossary, acronym list, and references; supplementary support is available though a noted web page. Annotation c. by Book News, Inc., Portland, Or.

Product Details

ISBN-13:
9780135259658
Publisher:
Simon & Schuster Adult Publishing Group
Publication date:
09/25/1997
Series:
William Stallings Books on Computer Series
Edition description:
Older Edition
Pages:
576
Product dimensions:
7.29(w) x 9.58(h) x 1.23(d)

Read an Excerpt


Chapter 11: InternetWork Traffic Management

    In the Tokyo underground, staff are employed exclusively to collect into baskets sleeves torn from passengers' clothes in the crush and the shoes they have left behind.

    -King Solomon's Carpet, Barbara Vine (Ruth Rendell)

As the Internet and private internets grow in scale, a host of new demands march steadily into view. Low-volume TELNET conversations are leapfrogged by high-volume client/server applications. To this has more recently been added the tremendous volume of Web traffic, which is increasingly graphics intensive. Now real-time voice and video applications add to the burden.

To cope with these demands, it is not enough to increase internet capacity. Sensible and effective methods for managing the traffic and controlling congestion are needed. This is the focus of this chapter. We begin with an overview of the two extant versions of the internet protocol: IPv4 and IPv6; it is IP that is the primary vehicle for traffic management. Next, we look at an emerging framework for internet traffic management known as ISA. Finally, we discuss important resource allocation and congestion control mechanisms in the areas of queuing discipline and packet discard policy.

11.1 The Internet Protocol

In this section, we look at version 4 of IP, officially defined in RFC 791.1 Although it is intended that IPv4 will ultimately be replaced by IPv6 it is currently the standard IP used in TCP/IP networks.

The protocol between IP entities is best described with reference to the IP datagrarm format, shown in Figure 11.1. The fields are as follows:

  • Version (4 bits): Indicates version number, to allow evolution of the protocol; the value is 4.

  • Internet Header Length (IHL) (4 bits): Length of header in 32-bit words. The minimum value is five, for a minimum header length of 20 octets.

  • Type of Service (8 bits): Provides guidance to end-system IP modules and to routers along the datagram's path. Figure 11.2 shows the encoding for this field, as defined in RFC 1349.

  • Total Length (16 bits): Total datagram length, in octets.

  • Identifier (16 bits): A sequence number that, together with the source address, destination address, and user protocol, is intended to identify a datagram uniquely. Thus, the identifier should be unique for the datagram's source address, destination address, and user protocol for the time during which the datagram will remain in the internet.

  • Flags (3 bits): Only two of the bits are currently defined. When a datagram is fragmented, the More bit indicates whether this is the last fragment in the original datagram. The Don't Fragment bit prohibits fragmentation when set. This bit may be useful if it is known that the destination does not have the capability to reassemble fragments. However, if this bit is set, the datagram will be discarded if it exceeds the maximum size of an en route subnetwork. Therefore, if the bit is set, it may be advisable to use source routing to avoid subnetworks with small maximum packet size.

  • Fragment Offset (13 bits): Indicates where in the original datagram this fragment belongs, measured in 64-bit units. This implies that fragments other than the last fragment must contain a data field that is a multiple of 64 bits in length. Time to Live (8 bits): Specifies how long, in seconds, a datagram is allowed to remain in the internet. Every router that processes a datagram must decrease the TTL by at least one, so the TTL is somewhat similar to a hop count.

  • Protocol (8 bits): Indicates the next higher-level protocol, which is to receive the data field at the destination.

  • Header Checksum (16 bits): An error-detecting code applied to the header only. Because some header fields may change during transit (e.g., time to live, segmentation-related fields), this is reverified and recomputed at each router. The checksum field is the 16-bit one's complement addition of all 16-bit words in the header. For purposes of computation, the checksum field is itself initialized to a value of zero.

  • Source Address (32 bits): Coded to allow a variable allocation of bits to specify the network and the end system attached to the specified network (7 and 24 bits, 14 and 16 bits, or 21 and 8 bits).

  • Destination Address (32 bits): Same characteristics as source address.

  • Options (variable): Encodes the options requested by the sending user.

  • Padding (variable): Used to ensure that the datagram header is a multiple of 32 bits in length.

  • Data (variable): The data field must be an integer multiple of 8 bits in length. The maximum length of the datagram (data field plus header) is 65,535 octets.

In the remainder of this section, we look at the type-of-service and options fields in more detail.

Type of Service

The type-of-service (TOS) field consists of two subfields: a 3-bit precedence subfield and a 4-bit TOS subfield. These subfields serve complementary functions. The TOS subfield provides guidance to the IP entity (in the source or router) on selecting the next hop for this datagrarm, and the precedence subfield provides guidance about the relative allocation of router resources for this datagram.

TOS Subfield

The TOS field is set by the source system to indicate the type or quality of service that should be provided, if possible, for this datagram. In practice, routers may ignore this subfield. However, if a router implements a TOS capability, there are three possible ways in which the router can respond to the TOS value:

  • Route selection: A routing decision could be made on the basis of type of service. For example, any datagram requesting minimized delay should not be routed through a subnetwork that includes a satellite link.

  • Subnetwork service: For the next hop, the router can request a type of service from the subnetwork that most closely matches the requested TOS. A number of networks (e.g., ATM) support some sort of type of service.

  • Queuing discipline: A router may allow TOS and precedence to affect how queues are handled. For example, a router may give preferential treatment in queues to datagrams requesting minimized delay, or a router might attempt to avoid discarding datagrams that have requested maximized reliability.

Both RFC 1349, which defines the current interpretation of the TOS field, and RFC 1812, which lists requirements for IPv4 routers, focus on the first alternative namelyalternativenamely, the influence of TOS on routing decisions. The way in which a router learns which routes support which TOS is beyond the scope of these specifications. In general, there are two possibilities. First, within a routing domain, a domain administrator could preconfigure the TOS to be associated with different routes. Second, a routing protocol could dynamically monitor the TOS along various routes by monitoring delays, throughputs, and dropped datagrams; OSPF (open shortest path first) is an example of a protocol that supports this capability (see Section 14.3).

When TOS routing is implemented, RFC 1812 specifies the following rules for forwarding a datagram with a nonzero TOS:

    1. The router determines all available routes to the destination; if there are none, the datagram is discarded.

    2. If one or more routes have the same TOS as the requested TOS, then the router chooses the route with the best metric based on its routing algorithms; this choice is discussed in Part Six of this book.

    3. Otherwise, if one or more routes have a TOS = 0 (normal service), then the best of these routes is chosen.

    4. Otherwise, the router discards the datagram.

Under this set of rules, a router might actually discard a datagram even though a route is available, because there is no route with either the same TOS or normal service. In practice, routing algorithms always support a TOS = 0 route for any destination that is reachable.

Table 11.1 shows the recommended TOS values that should be requested by common protocols.

Precedence Subfield

The precedence field is set to indicate the degree of urgency or priority to be associated with a datagram. The precedence indicator ranges from the highest level of Network Control to the lowest level of Routine. The Network Control level is intended for use only within a subnetwork. For example, if a subnetwork management entity needs to send control information to a host attached to the same subnetwork, this precedence level would be used and could be supported by actions in the sending IP entity. The Internetwork Control level is intended for router-based control messages; an example is the exchange of routing information. The remaining levels have suggestive titles but no precise definition for general use.

Again, in practice, routers may ignore this subfield. As with the TOS subfield, if a router supports the precedence subfield, there are three approaches to responding: route selection, subnetwork service, and queuing discipline. Among routes with equal routing metrics, a particular route may be selected if the router has a smaller queue for that route or if the next hop on that route supports subnetwork precedence or priority (e.g., a token ring network supports priority). Regardless of the route chosen, if the subnetwork on the next hop supports precedence, then that service is invoked.

However, it is intended that the principal effect of the precedence subfield is in relationship to the queuing discipline at the router. The way in which a router deals with precedence is explored in more detail in Section 11.4. Here, we summarize the recommendations in RFC 1812, which fall into two categories:

  • Queue service

    a. Routers SHOULD implement precedence-ordered queue service. Precedence-ordered queue service means that when a packet is selected for output on a (logical) link, the packet of highest precedence that has been queued for that link is sent.

    b. Any router MAY implement other policy-based throughput management procedures that result in other than strict precedence ordering, but it MUST be configurable to suppress them (i.e., use strict ordering).

  • Congestion control. When a router receives a packet beyond its storage capacity, it must discard it or some other packet or packets.

    a. A router MAY discard the packet it has just received; this is the simplest but not the best policy.

    b. Ideally, the router should select a packet from one of the sessions most heavily abusing the link, given that the applicable quality-of-service policy permits this. A recommended policy in datagram environments using FIFO queues is to discard a packet randomly selected from the queue. An equivalent algorithm in routers using fair queues is to discard from the longest queue or that using the greatest virtual time (this strategy is explained in Section 11.4). A router MAY use these algorithms to determine which packet to discard.

    c. If precedence-ordered queue service is implemented and enabled, the router MUST NOT discard a packet whose IP precedence is higher than that of a packet that is not discarded.

    d. A router MAY protect packets whose IP headers request the maximize reliability TOS, except where doing so would be in violation of the previous rule.

    e. A router MAY protect fragmented IP packets, on the theory that dropping a fragment of a datagram may increase congestion by causing all fragments of the datagram to be retransmitted by the source.

    f. To help prevent routing perturbations or disruption of management functions, the router MAY protect packets used for routing control, link control, or network management from being discarded. Dedicated routers (i.e., routers that are not also general-purpose hosts, terminal servers, etc.) can achieve an approximation of this rule by protecting packets whose source or destination is the router itself.

IPv4 Options

The options field is a variable-length field that, if present, specifies one or more options related to this datagram. The options currently defined are as follows:

  • Security: Allows a security label to be attached to a datagram.

  • Source routing: A sequenced list of router addresses that specifies the route to be followed. Routing may be strict (only identified routers may be visited) or loose (other intermediate routers may be visited).

  • Route recording: A field is allocated to record the sequence of routers visited by the datagram.

  • Timestamping: The source IP entity and some or all intermediate routers add a timestamp (precision to milliseconds) to the data unit as it goes by....

Meet the Author


William Stallings has made a unique contribution to understanding the broad sweep of technical developments in computer networking and computer architecture. He has authored 15 titles, and counting revised editions, a total of 32 books on various aspects of these subjects. In over 20 years in the field, he has been a technical contributor, technical manager, and an executive with several high-technology firms. Currently he is an independent consultant whose clients have included computer and networking manufacturers and customers, software development firms, and leading-edge government research institutions.

He is the recipient of the 1998 Texty Award from the Textbook and Academic Authors Association for the best Computer Science and Engineering textbook of the year, awarded for his book Operating Systems: Internals and Design Principles, Third Edition (Prentice Hall, 1998). He also received the 1997 Texty Award for his book Data and Computer Communications, Fifth Edition (Prentice Hall, 1997). He also received the 1996 Texty Award for his book Computer Organization and Architecture, Fourth Edition (Prentice Hall, 1996).

Bill has designed and implemented both TCP/IP-based and OSI-based protocol suites on a variety of computers and operating systems, ranging from microcomputers to mainframes. As a consultant, he has advised government agencies, computer and software vendors, and major users on the design, selection, and use of networking software and products.

Dr. Stallings holds a PhD from M.I.T. in Computer Science and a B.S. from Notre Dame in electrical engineering.

Customer Reviews

Average Review:

Post to your social network

     

Most Helpful Customer Reviews

See all customer reviews