Chapter 11: InternetWork Traffic Management
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.
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.
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.
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....