ard. We will conclude this section on QoS by saying that the field remains largely in a desired state. Although much progress has been made in understanding the technical problems associated with the modules that compose it, this is just the tip of the iceberg. It will arguably take much more than mechanisms and tools of the trade such as algorithms and signaling protocols. A great deal of stan- dardization work is still needed. This is obviously the mission of industry bodies such as the Internet Engineering Task Force (IETF). However, several issues are still unresolved regarding how to inter- pret the available bit fields of mechanisms consistently across the industry in order to create mean- ingful differentiated services or determine how to deal with QoS when crossing the boundaries of autonomous systems or network domains. This may sound mundane, but it is actually one of the thorniest problems in this field. Downloaded from Digital Engineering Library @ McGraw-Hill (www.digitalengineeringlibrary.com) Copyright © 2004 The McGraw-Hill Companies. All rights reserved. Any use is subject to the Terms of Use as given at the website. TRAFFIC MANAGERS TRAFFIC MANAGERS QoS-ORIENTED PROTOCOLS One of the key notions in the subsequent discussions is the term flow. This is a loosely defined con- cept, but for our purposes, we will clarify that any quantity of traffic consisting of a series of packets that can be viewed or treated in some common way may be characterized as flow. More specifically, this implies that traffic packets with the same source address, port number, protocol ID, destination address, and destination port number should be treated as one flow. Consequently, we can use the term to describe packets belonging to a specific session, originating from a specific network node, or fit- ting a specific profile. The term is generic, but serves an important objective when it comes down finer-granularity traffic management. Packets belonging to multiple and unrelated sessions are usually aggregated in multiple 