Implementing Prioritization On IP Networks
With the introduction of 802.1Q and 802.1p, you can now prioritize Ethernet traffic on your network. Using simple rules-based policies, administrators can dictate that their networks' switching infrastructures give precedence to Lotus Notes and e-mail traffic rather than to the RealAudio streams that are sucking up all of the bandwidth. This is a real boon for Ethernet technology.
Yet, while the drafts' advances provide prioritization services to the most popular Layer 2 topology, they do not necessarily provide end-to-end prioritization across your entire network. In particular, 802.1Q and 802.1p won't help you prioritize the Layer 3 IP traffic traveling across your low-speed WAN and ISP connections—the points in your overall infrastructure where bottlenecks usually occur.
To handle network congestion across your entire network, you must first provide for the prioritization of IP traffic. Doing this effectively raises a series of design questions. Does your internal network support IP-prioritization services? Does your WAN equipment? What about your Internet service provider? What about the infrastructure at the other end of the connection? If any device between two systems cannot provide IP-prioritization services, you won't be able to implement an end-to-end solution.
The Basics of IP Prioritization
Unlike Ethernet, IP has had prioritization capabilities ever since version 4 was first published in 1981. Every IP packet has an 8-bit field—called the ToS (Type of Service) byte—that consists of two subfields. These subfields consist of a 3-bit precedence field used for prioritization as well as a 4-bit field for the specific ToS desired by this packet (the remaining bit is unused).
By using 3 bits for precedence, IP has the same eight levels of prioritization—0 through 7—as 802.1p, 802.1Q and most of the other LAN topologies. By implementing a cross-mapping service, it becomes feasible to provide a one-to-one mapping between 802.1Q Ethernet frames and the IP precedence, letting you build a network that carries prioritization from one Ethernet LAN to another across an IP-based WAN or ISP connection. Many router vendors say they will be implementing this functionality in the coming months as they roll out their 802.1Q-compliant products.
The remaining 4 bits of ToS information let administrators implement per-packet routing based on the characteristics of the packet's data. Thus, an NNTP (Network News Transfer Protocol) packet that carries UseNet news traffic can be marked as a low-cost service, while a telnet packet can be marked as a low-latency service.
Originally, only three types of services were defined in RFC 791, the original basis of the IP standard. These services were identified with unique bits that were either on or off, depending on whether the specific ToS was desired. However, this setup was modified by RFC 1349, which added a fourth service to the mix; it also stated that the bits were to be numerically additive rather than distinct entities. Because they were additive, the four bits provided for a maximum of 16 possible values—0 through 15.
Network managers handling complex networks with multiple routing paths can use these ToS flags in conjunction with ToS-based routing protocols such as OSPF to provide specific routing services across their networks.
For example, you may want to send low-latency packets through a high-speed fiber plant rather than through a satellite connection. Or, you may decide to route a low-cost packet through an Internet connection rather than route it across your private WAN. Furthermore, by combining the Type of Service flags with prioritization bits, it's possible to dictate very explicit types of behavior with certain types of data.
Another example might be where you would define network filters that mark all Lotus Notes packets as medium priority and tag them with the low-latency ToS flag. This would provide Notes users with preferential service over less-critical traffic, routing this traffic over specific network segments. Conversely, you could define another set of filters that mark all RealAudio traffic as lower priority and also set the high-bandwidth ToS flag, forcing that traffic to use an alternate—and more appropriate—route.
As long as you own the end-to-end connection between the source and destination systems, you can do whatever you want with these packets. Keep in mind, however, that most ISPs will not treat these packets any differently than unmarked packets. Indeed, if you need a certain ToS from an ISP, you will most likely end up paying for a dedicated PVC (Permanent Virtual Circuit) between your sites, since you won't be able to prioritize packets using these services. In this regard, a private WAN is still your best option.
However, you also could apply filters to incoming Internet data, and at least be able to manage it from that point through the rest of your network, giving you a minimum of bandwidth manageability.
OS and Application Support Issues
Apart from the network, there are significant hurdles to getting the precedence and ToS bits into your IP packets. There are two ways to circumvent these problems: You could have the applications write this information into the packets while they are being sent, or you could have network devices write this information using application-specific traffic filters. In either case, you will be dependent on the vendors of your applications, operating systems and infrastructure equipment to support these attributes.
Surprisingly, there is very little support for this undertaking in the commercial market. Only a few operating systems, for example, have mechanisms in their IP stacks for writing the precedence and ToS bits into a packet. The WINSOCK.DLL that comes with Microsoft Corp.'s Windows95 and Windows NT does not allow this functionality at all, returning "invalid operation" errors when the "setsockopt(IP_TOS)" function is called. Other OSes, including Irix, HP-UX and Solaris, are only slightly better, providing some support within the OS.
In fact, of all the operating systems we've used, the only two that offer high levels of support for the Type of Service byte are Linux and Digital Unix. These systems excelled in our tests not only because they supported these functions directly but because they incorporated these services into their bundled applications.
Both systems, for example, offer a telnet client and server that set the low-latency ToS flag, whereas none of the others we tested provide this basic functionality. The FTP client and server bundled with Linux and Digital Unix use the low-latency flag for the FTP command channel while using the high-throughput flag for the data channel. This lets an FTP command such as "abort operation" be routed through a fast network, getting it to the server quickly (thus canceling the download faster).
Why don't more applications support ToS? Because, for the most part, the operating systems they run on don't offer the necessary support. Until Microsoft fixes the WINSOCK.DLL provided with Windows NT, application vendors such as Lotus Development Corp., Netscape Communications Corp. and Oracle Corp. will be unable to implement application-specific prioritization services directly within their applications.
Implement in Infrastructure
There are ways around the vendor-specific shortcomings, however—the most common route is to implement IP prioritization services in the infrastructure rather than in the end-point applications and operating systems. For years, many of the largest and busiest networks have been building manual prioritization controls using per-application filters within their routers.
In this type of model, you can manually define a filter that queues and sends Notes traffic at a higher priority than FTP traffic, for example. While such tools are crude, they get the job done on a per-hop basis, if not on an enterprisewide level. Network managers may also find it's worth exploring some of the new bandwidth-management products, such as CLASS Data's Classifier (recently acquired by Cisco Systems), which uses end-point agents to adjust IP prioritization and ToS services within the network infrastructure.
We found 3Com Corp.'s DynamicAccess software very helpful as well. Since DynamicAccess runs on Windows95 and NT systems, we were able to implement application-specific prioritization services at the source and destination systems directly, letting the rest of the network process the packets according to the criteria defined at the end points.
And DynamicAccess does not suffer from the WINSOCK.DLL limitations because it works as a shim between the protocols and the NDIS (Network Driver Interface Specification) 3.1 drivers. Essentially, DynamicAccess monitors the packets coming in from the Layer 3 protocol (whether IP or IPX) and modifies the IP precedence and ToS bits before sending them on to the network adapter's driver, just as it does with the 802.1Q priority bits. This lets you prioritize the IP traffic at the end points, rather than on a per-hop basis within your network.
The Future of IP Prioritization
There are many opportunities and methods for implementing application-centric prioritization schemes across an IP network. These services can be tied to the priorities found on 802.1Q/802.1p networks, spoofed by infrastructure applications like 3Com's DynamicAccess, and even implemented by vendors directly (where the operating system supports this functionality).
But hold on to your hats! This area also is undergoing dramatic change. In an effort to provide better prioritization-management services to ISP networks, an IETF working group has convened to consider changing the fundamental nature of the ToS byte.
The name of the working group—Differential Services, or "diffserv" for short—is a good indication of the goal of this group: to provide customers with different classes of service (such as "silver" or "gold"). Current proposals the group is considering suggest replacing the ToS byte with a new set of values based on this goal.
If this comes to pass, network managers will lose the ability to define per-application prioritization services on an end-to-end basis, because whatever you put into the ToS byte will be overwritten by the ISP once it gets the packet. There are no facilities for preserving the existing data in the current proposals.
Whether or not this is a good thing depends entirely upon your perspective. ISPs love it, of course, since they get to charge for PVCs without having to build them. Furthermore, there's some benefit to being able to relay this information to other ISPs on a per-packet basis, which diffserv should allow.
However, if the current ToS byte is replaced—and there is no backward compatibility—managers of end-point networks will likely lose out. The prioritization schemes you implement for the benefit of your network and applications will only get discarded once they leave your local network. The only way to preserve the existing prioritization functionality will be to buy your own private WANs.
Copyright © 2010-2017 Eric A. Hall.
Portions copyright © 1998 CMP Media, Inc. Used with permission.