Identification of Traffic

After the QoS policy and toolsets that can be employed have been defined, the starting point is to understand the profile of traffic that exists in the network. To identify the traffic, several approaches can be taken to identify the current flows and start the work of classification. The easiest way to do this is to first determine the real-time applications that require special handling as they traverse the network. With these, there is a need to identify not just the bearer traffic but also the signaling traffic that may be required as part of the bearer's normal operation.

What Would Constitute This Real-Time Traffic?

Applications, such as VoIP, videoconferencing over IP, and certain business-critical applications or systems processes, can be one such classification. These applications could be categorized and then assigned a specific handling criteria, such as SAP enterprise resource planning (ERP), storage area network (SAN) replications, Citrix applications, CAD/CAM operations, and, of course, those real-time requirements of voice and video.

The treatment of the traffic is, within a framework of QoS policy, done based on its classification. Endpoints that perform this function need to be able to mark their traffic in a specific way to allow the proper handling to be done as traffic traverses the network. When it comes to real-time applications, this requires identifying the bearer and control (signaling) traffic and ensuring that it is placed in the appropriate class. When this occurs, action needs to be taken to understand what happens with the remaining traffic. Thus, a process of identification is required. It is safe to assume that most applications that traverse the network are, for the most part, unclassified or unmarked where no QoS policy is currently in play.

Figure 5-12 takes the simplistic approach of baselining the existing network to determine the makeup of traffic and applications in play. This is useful because it helps serves as the checkpoint from where to start the classification work. It also requires that an audit be done of the existing network infrastructure to assess its ability to support the applicable policies. Areas such as device capability and Cisco IOS version must be brought to a consistent level to ensure that there is a base level of capability, stability, and ability to execute the policy.

Figure 5-12. Identifying the Policy Process

There are many different mechanisms to start to derive the application communications flow, the most useful of which is Cisco NetFlow Accounting. NetFlow provides valuable information about who is using the network, what applications are being used, when the network is used, and where traffic is going on the network. Essentially it is a way to answer the questions of who, where, when, and what. The mechanism extracts the following:

• Source IP address

• Destination IP address

• Source port

• Destination port

• Layer 3 protocol type

• Type of service byte (DSCP)

• Input logical interface (ifIndex)

Using this capability helps you build a scalable mechanism by which to classify application characteristics and start the work of placing these within a classification framework.