- Shopping Bag ( 0 items )
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.
-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.
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:
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.
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:
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:
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.
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:
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).
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.
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:
|Pt. 1||Protocol and Network Fundamentals||21|
|Ch. 2||Protocols and the TCP/IP Suite||23|
|Ch. 3||Data Networks||43|
|Pt. 2||High-Speed Networks||73|
|Ch. 4||Asynchronous Transfer Mode||75|
|Ch. 5||High-Speed LANs||101|
|Pt. 3||Performance Modeling and Estimation||121|
|Ch. 6||Overview of Probability and Stochastic Processes||125|
|Ch. 7||Queuing Analysis||147|
|Ch. 8||Self-similar Traffic||181|
|Pt. 4||End-System Traffic Management||209|
|Ch. 9||Link-level Flow and Error Control||211|
|Ch. 10||Transport-Level Traffic Control||239|
|Pt. 5||Network Traffic Management||299|
|Ch. 11||Internetwork Traffic Management||301|
|Ch. 12||Traffic and Congestion Control in ATM Networks||343|
|Pt. 6||Internet Routing||379|
|Ch. 13||Overview of Graph Theory and Least-Cost Paths||383|
|Ch. 14||Routing Protocols||401|
|Ch. 15||Routing for High-Speed and Multimedia Traffic||431|
|Ch. 16||Overview of Information Theory||471|
|Ch. 17||Lossless Compression||485|
|Ch. 18||Lossy Compression||511|