Directing Your Network Traffic

As more network-centric applications are developed and deployed, the network bandwidth and latency crunch grows. Almost every LAN faces congestion issues at some point during the workday. WANs encounter even more problems, with directory replication, database access and other high-load technologies forcing massive quantities of data through a global organization's narrow pipes.

Under the heading of Quality of Service (QoS), a variety of technologies promise administrators improved control over the data that travels across their networks, though none provide more bandwidth or less latency. Instead, they help you manage your existing resources so important traffic flows smoothly.

You will likely need multiple technologies to gain any benefits. For example, if you are running IPX and IP simultaneously, you will probably require a traffic-management service at the data-link or physical layers to balance the load between these different protocols, in addition to whatever services you have for specific application protocols.

Even on IP-only networks it isn't entirely feasible to rely on a single technology. For example, your switch vendor may support only data-link prioritization, while your router vendor supports network- or transport-layer services. In this article, we will help you pinpoint the most appropriate technologies for enterprisewide traffic management.

Physical and Link-Layer Services

The most fundamental traffic management comes in the form of physical-layer and data-link-layer access services, with the network determining which stations get the highest access levels. Token ring and FDDI have led this area, each featuring a managed-access topology and a set of control services that use an access token. If a node with high-priority data got the token, it would send as much data as possible before other devices with lower priority levels would be able to transmit.

Neither of these features was found in the original Ethernet design. Over the past few years, however, Ethernet has moved from shared access (with access based on who recovered from a collision first) to managed access (switching). Now an Ethernet switch can make access decisions based on the MAC (Media Access Control) address of the attached device, or by the physical port number of the switch itself.

Control services were added to Ethernet with last year's IEEE adoption of the 802.1Q VLAN (virtual LAN) tagging specification and the 802.1p extension to the 802.1D bridging specification. Essentially, the 802.1Q VLAN tag adds 32 new bits of header data to Ethernet frames, with three of those bits used to provide eight levels of prioritization tagging for each frame. The 802.1p extension to the 802.1D bridging specification provides a topology-neutral mechanism for priority enforcement within the infrastructure devices, letting the switches make queuing decisions based on content instead of identity. In addition, per-frame tags let the data be carried through the network across switch boundaries, while location-specific elements typically do not. For a more detailed discussion of these technologies, see "Bringing Prioritization Services to Ethernet".

Many other technologies work at the data-link layer (including those found in frame relay and ATM). Almost all of them rely on a managed-access physical layer and do not work on a shared-access medium, such as CD/ CSMA Ethernet, because that model offers no means for queuing data. It's interesting that AIM Engineering and other companies are working to deliver prioritization to shared-access media using software within the end point devices, which essentially requires that devices ask for permission before transmitting data. This approach may be particularly useful with wireless or SOHO (small office/home office) networks that lack managed-access topologies.

IP-Specific Services

Although data-link-layer tagging services provide a usable mechanism for marking important frames, very few large-scale networks employ the same topology throughout the organization, which dramatically limits this method of traffic management. For example, if two sites with Ethernet switches are interconnected by a frame relay WAN, you will not be able to pass the 802.1Q frame markings between the Ethernet segments. To secure a consistent set of markings across all your topologies, you must use network-layer services, such as those found with IP.

IPv4 provides an eight-bit field called the ToS (Type of Service) byte, which incorporates two subfields that are useful for defining per-packet handling services. One of the subfields is a three-bit prioritization service that provides eight distinct levels of priority for each IP packet (similar to the eight levels used by token ring and Ethernet). Another four bits is used to define specific ToS, which tells routers to forward the packet across a link that offers a particular service (such as low latency or high reliability). For more information on the ToS byte, see "Implementing Prioritization on IP Networks".

Although the IPv4 standard as defined by STD 2 still mandates the use of the ToS byte, work is under way to reinvent this particular wheel, with some new mechanisms promising a richer set of services. In particular, the Differentiated Services (DiffServ) working group has developed a set of markings that redefine the ToS byte so that specific per-hop behaviors can be requested by a sender. Applications can request a premier service level with certain characteristics, and DiffServ-aware devices that received the packet would treat it accordingly. This model also lets ISPs tag specific customers' data as "bronze" or "platinum plus," which also goes beyond the existing ToS byte's capabilities.

Unfortunately, this change comes with no backward compatibility whatsoever; consequently, the data you generate with a ToS-based stack may be overwritten by your ISP, resulting in unpredictable behavior for ToS-based equipment at the other end of the link. If this is a problem, you'll have to upgrade your hosts and applications (whenever DiffServ-aware versions appear), negotiate a no-marking clause in your service level agreement, or choose a different IP carrier. Another problem is that traffic crossing multiple ISPs may be subjected to each ISP's definition of the ToS byte's purpose. One possible solution is to employ a "bandwidth broker," third-party independent software that lets multiple ISPs map and share their ToS levels.

Another IP-specific effort, being conducted by the Multi-Protocol Label Switching (MPLS) working group, defines route-specific traffic flows. Essentially, MPLS technology lets end points dictate the specific path their packets should take through a network. Although IPv4 offers this ability via the Source Routing option, MPLS allows this data to be represented in a tighter form, helping routers make forwarding decisions faster. MPLS is still a work-in-progress, with compliant products due soon.

Also IP-specific is the Resource Reservation Protocol (RSVP), which uses a separate group of control packets to inform routers of the bandwidth and latency requirements of specific connections. When an RSVP-aware application or host establishes a connection, an RSVP request shoots through the network, informing all the intermediary devices of the necessary resource requirements. The devices then compare the request to the availability and policy definitions, and grant or deny the request explicitly. Although beneficial on self-contained corporate LANs and WANs, this design is difficult to scale on the Internet.

Network-Layer Services

All the IP-specific tools work at the IP layer. They manage the IP packets carrying the data, rather than managing the different types of data within the packets. It's a fine distinction, since an IP packet can only carry data from a single application at any given time, assuming that the sender (or an intermediary device) can trap application-specific flows and make the appropriate IP markings.

However, IP will move as much data as it encounters, even if the specific application traffic flow overwhelms the network. By itself, IP does not offer any flow-control services that can react to changes in the network, so some technologies work at the transport layer to minimize the quantity or rate of data that an application sends, preventing the IP network from becoming congested in the first place.

For a simple example, look to RealNetworks' RealMedia player and other streaming media systems. With those products, the recipient system quantifies the available bandwidth (such as "28.8-Kbps modem"), and the sending system limits the amount of data being transmitted appropriately. A prioritization or bandwidth reservation may also be used on the underlying IP packets, but for the most part, traffic management is handled by constraining the flow of UDP (User Datagram Protocol) datagrams to a quantity appropriate for the connection.

Typical TCP applications--including e-mail, terminal emulation and other client/server applications--cannot tolerate any loss, so rather than controlling quantity, you have to regulate the rate at which a fixed amount of data will be transmitted. Packeteer and other companies offer products that do this by adjusting the size of the TCP receive window that is advertised by the end point systems, as well as by pacing the rate at which acknowledgments are exchanged. By adjusting these values on a per-connection basis, these products constrain the end points to a predetermined amount of bandwidth, which allows administrators to dictate how much bandwidth will be consumed by individual applications.

All Together Now

Each of these technologies can be used to build traffic management systems, though in most organizations it will prove useful to run multiple services in tandem. For example, a site that was truly concerned about application response times could tweak the application flows using traffic shapers, while passing reservation requests for the resulting flows out through the rest of the network, and prioritizing the packets that comprise the individual flows.

Over time, we can expect that these technologies will cooperate to an extent. Some policy management products promise just that, offering each of these mechanisms in a grab bag so that applications or network administrators can define specific network characteristics using the most appropriate tool.

In addition, the Common Open Policy Service (COPS) working group of the IETF is defining mechanisms for combining traffic-management tools with LDAP policies so that management mechanisms can be linked to the specific user of an application (the restrictions are on the application and host). Some vendors are offering this type of architecture, though it's usually restricted to specific OSes and infrastructure gear. Down the road, a more open approach will make vendor-neutral traffic management easier.

Written by Eric A. Hall.
Copyright © 1999 CMP Media, Inc. Used with permission.