A flow consists of all the packets about which the following are true:
•
All packets use the same transport layer protocol (for instance, UDP or TCP).•
All packets have the same source IP address.•
All packets have the same source port number.•
All packets have the same destination IP address.•
All packets have the same destination port number.The slightly different, but just as exact definition, is that a flow consists of the packets between two IP sockets. For instance, a web browser on a PC, connecting to a server, creates a flow. (Actually, in the case of HTTP, it may create multiple TCP connections, which would actually be multiple flows.) Regardless, consider Figure 2-9. In this network, one flow exists from Hannah to Server1’s web server.
Figure 2-9 GOCS Approach to QoS for a Single Flow
R1 IP R2 R3 IP SW1 Hannah 201 s0 s0 s1 T1 s0 FA0 SW2 301 Server 1
-Classify into Flows
-Apply Other QoS Tools, per Flow -Performed at Each Router
The single flow shown in the figure consists of the packets sent by Hannah to Server1. Note that flows are unidirectional—in effect, two flows, one in each direction, would exist. To reduce the complexity, the samples in this section show flows going left to right only.
Flow-based QoS tools behave like the logic shown in the figure. Some QoS tools recognize flows and treat packets in one flow differently than another flow. So, common sense may imply that the QoS tools must first identify the packets that belong to this single flow, and then take some QoS action—such as queuing, LFI, shaping, and so on—for the packets in that flow. The tools may be applied for packets entering an interface, and other QoS tools may be applied for packets exiting an interface. Some tools may even be applied on the LAN switches. Some QoS tools may be applied in the Frame Relay cloud—but those are not typically under your control. Real networks will have a widely varying number of flows, but the general ideas behind flow- based QoS tools do not change when more flows exist. Take a look at Figure 2-10, which shows a pretty small network with only four flows at this point.
Figure 2-10 GOCS Approach to QoS for Multiple Flows
R1 R2 R3 IP SW1 Hannah Vinnie 201 s0 s0 s1 T1 s0 FA0 SW2 301 Server 1 Class. (Flow-Based) ? Dropped Queueing (Flow-Based) Drop Policy Same General Logic as R2 Same General Logic as R2
Flow1: Hannah’s Browser1 to Server1 Web Server Flow2: Hannah’s FTP Client to Server1 FTP Server Flow3: Vinnie’s Browser1 to Server1 Web Server Flow4: Vinnie’s Browser2 to Server1 Web Server
This figure shows four flows. Even though Vinnie sends all packets for both flows to Server1, they are in two different flows, because each of the two browser windows would open separate TCP connections, with different source TCP port numbers. (Note: HTTP 1.1 could cause mul- tiple connections to be opened; FTP uses a control and data connection, which would result in two flows.) However, assume that only four flows exist at this point.
How does the GOCS model with flow-based tools change with multiple flows? Well, not much. Each flow must be identified, based on its unique source/destination address/port values. The QoS actions at each router may be different for each flow—for instance, maybe FTP just gets leftover bandwidth, or maybe Hannah gets better treatment for her web flow than does Vinnie. The reasons and rationale behind deciding what traffic gets what QoS treatment will change from network to network, but the basic process works the same:
•
Identify each packet, determining which flow it belongs to.•
Apply some QoS action to the packets in each flow.•
The QoS actions on a single router may be different for each flow.•
The QoS actions among all routers may be different for each flow.Flow-based QoS tools provide some advantages and some disadvantages. Because each sepa- rate flow is identified, the QoS tools can literally provide different levels of service to every flow. A single queue could be used for each flow, for instance, giving each a different reserved bandwidth. With a large number of flows, however, the overhead associated with keeping state information about each flow can be a lot of work. Imagine a router with 1000, or even 10,000, concurrent flows, which would not be surprising in the Internet—and then imagine the overhead in trying to perform queuing with 1000 or 10,000 queues! So, flow-based QoS tools provide a great deal of granularity, but they do not scale as well as some other QoS tools that do not con- sider flows (particularly with very large networks or the Internet).
Engineers gain another advantage and disadvantage when configuring flow-based QoS tools. Suppose that your job is to explicitly configure the routers in Figure 2-10 as to which source and destination IP addresses and ports to use to find each flow. And instead of 4 flows, there are 1000 concurrent flows. Over the course of a day, there may be hundreds of thousands of flows. Your job is to find the details that make each flow unique and configure it! Well, that would be rather ridiculous, a lot of work, and mostly impractical. Therefore, flow-based tools typically require no configuration to match and classify packets into a flow. However, some configuration control is lost.
The following list summarizes the key points about flow-based QoS tools:
•
Flow-based QoS tools automatically recognize flows based on the source and destination IP address and port numbers, and the transport layer protocol.•
Flow-based tools automatically identify flows, because it would be impractical to configure parameters statically to match the large number of dynamically created flows in a network.•
Flow-based tools provide a great amount of granularity, because each flow can be treated differently.•
The granularity may create scaling problems when the number of flows becomes large.GOCS Class-Based QoS
Most QoS tools do not need to differentiate between each flow. In the Figure 2-10, for instance, flows to web Server1 were identified. Most network engineers would want to treat those collec- tive web flows the exact same way with their QoS tools. Therefore, most QoS tools tend to oper- ate on the idea of a category, or class, of flows and packets. Consider Figure 2-11, for example, which has thousands of flows, all of which are classified into four types of traffic.
Figure 2-11 GOCS Approach to QoS with Classes
Class-based QoS tools do not have to identify each flow. However, they do need to identify packets based on something in the packet header—such as TCP destination port 80 for web traffic—and consider that traffic to be in one category or class for QoS treatment. Once again,
R1 IP R2 R3 IP SW1 Hannah 201 s0 s0 s1 T1 s0 FA0 SW2 301 Server 1
Classify Just Like Other Routers, Based on Lots of Header Fields
May Apply Different QoS Tools, Using Different Parameters
Classify Just Like Other Routers, Based on Lots of Header Fields
May Apply Different QoS Tools, Using Different Parameters
Classify Just Like Other Routers, Based on Lots of Header Fields
May Apply Different QoS Tools, Using Different Parameters
the reasons and rationale behind deciding what traffic gets what QoS treatment changes from network to network, but the basic process works the same, but per class rather than per flow:
•
Identify each packet, determining which class it belongs to.•
Apply some QoS action to the packets in each class.•
The QoS actions on a single router may be different for each class.•
The QoS actions among all routers may be different for each class.Unlike flow-based QoS tools, class-based QoS tools typically require the engineer to specify exactly what must be seen in the packet header to classify a packet. If this network currently has 4 flows to the web server, or 400, or 4000, if the classification criteria just states “all TCP port 80 traffic,” no additional configuration is required as the network scales. Both flow-based and class-based tools need to examine every packet to classify the packet into the appropriate flow or class. Because class-based tools typically only need a small number of classifications, however, the tool can reasonably be configured to specify the types of traffic that get added to each class.
Class-based QoS tools can use more complex rules to classify packets than do flow-based tools. For instance, a class-based tool can examine subsets of the IP addresses (matching a subnet, for example), the incoming interface, the URL for web traffic, and anything that an IP ACL can match. For flow-based tools, the router always look at five fields, all in the IP header—Source and Destination Address, Source and Destination Port, and the Protocol Type field (which identifies the transport layer protocol). In short, classification options for class-based tools tend to be much more varied and functional, but they require more configuration work to take advantage of the different options.
Flow-based and class-based QoS tools both have a useful place in a QoS strategy for a network. Most QoS tools tend to be based on general classes, as opposed to looking at each individual flow.
Classification and Marking at the Edge
Class-based tools have advantages and disadvantages as well. The engineer can exercise great control over the packets placed into the classes or categories used in a network. Because a small number of categories are used, in most cases fewer than 10, the configuration scales. For instance, you build a network and choose four categories for packets. As the network grows, you can keep using the same four categories, and even with growing numbers of packets and routers, the number of classes can remain the same.
However, the same explicit classification configuration details can be the cause of two particular types of problems. For instance, suppose that you have 500 sites, with at least one router and several switches at each site. At each site, you want to classify packets into the same four cate- gories. You need to use six different IOS QoS tools—which is not an unreasonable choice,
because you might need different types of queuing, shaping in some cases, fragmentation only in some cases, compression in other cases, and so on. Each of the six tool’s classification con- figuration differs. In some cases, the switches can perform classification and marking at Layer 3, but not in other cases. You also have 5 different engineers, plus 10 operational staff, who have to enable secret passwords to the routers and switches. What are the chances that the classifica- tion configurations will be correct, on each router, and stay that way? Even if the configurations remain correct and unchanged, do you really want all routers looking at 10 different things in every packet header, taking CPU cycles, to classify each packet? Well, common sense tells us that there may be a better method.
You can use the Cisco QoS Policy Manager (QPM) to overcome the configuration correctness and consistency problem. QPM creates the QoS configurations for you, based on your input about QoS policies using a GUI. QPM loads the configurations, and re-verifies the QoS configurations to discover whether changes have been made. It can also reconfigure a router after someone has inadvertently changed the QoS configuration—automatically. Any large QoS implementation begs for the use of QPM.
Through good QoS design, you can solve the problem of having every router in the network examining a lot of fields in every packet header. This design choice reduces the complexity of the configurations as well. Packets can be classified and marked near the ingress points of traffic into the network; the QoS tools in the center of the network can just look for the marked field in the packet header, as shown in Figure 2-12.
Classifying and marking the packets near the edge of the network simplifies the classification logic and configuration at the rest of the routers in the network. For instance, the figure shows the same classes as Figure 2-11, but with classification and marking performed near the ingress edge of the network. Ideally, packets should be marked even before they reach the first router, typically by a LAN switch. If not, packets entering R1’s E0 interface can be classified and marked. R1, R2, and R3 all still need to classify packets, but now the classification details just look for a single well-known field inside the IP header. (Note: The two IP header fields used are the IP Precedence and IP DSCP fields.) This design choice simplifies the QoS configuration and reduces the processing effort for the intermediate routers. (Note: Classification and marking can happen in the switches, IP Phones, and end-user computers—all of which are discussed in detail in Chapter 3.)
Proper planning prevents poor policies when using the “class and mark near the edge” GOCS strategy. For instance, the Figure 2-12 shows four classes, one of which is “all web traffic.” Four classes may work well for this network, but other networks may need to treat web traffic to Server1 differently than web traffic to Server2 or Server3. Before beginning to deploy QoS, the network architects and engineers should agree on what types of traffic need to be in a separate class. Then they must classify and mark at the edge and use simplified classification configura- tions, based on the marked fields in the IP header, in the interior of the network. With flow-based tools, there is no requirement to plan the different traffic classifications, because flow-based tools categorize based on flow.
Figure 2-12 GOCS Design: Mark Packets near the Edge of the Network
It is possible to plan QoS classes for an enterprise network. However, planning classes for all networks in the Internet is a bit more challenging! For instance, although everyone may agree that VoIP and video may need different treatment than data over the Internet needs, they prob- ably do not agree about differentiation between different types of data traffic. Also a company paying a premium to a service provider may expect better service—translated, better QoS treat- ment—so the classification may be based on the source IP addresses, and may be different for different ISPs.
Therefore, although the political and business challenges of Internet-scale QoS may be difficult, cases will still exist where QoS can be implemented over the Internet. Consider Figure 2-13, which shows two companies, each connected to two different ISPs.
R1 IP R2 R3 IP SW1 Hannah 201 s0 s0 s1 T1 s0 FA0 SW2 301 Server 1
Mark Packet in One of the “QoS” Marking Fields Mark at Ingress
Mark on Switch if Possible
Classify Easily Based on Previously Marked Fields
May Apply Different QoS Tools, Using Different Parameters
X Y Z
Mark
Marked with QoS=1: Lots of Flows to Server1 Web Server Marked with QoS=2: Lots of Flows to Server1 FTP Server Marked with QoS=3: Lots of VoIP Payload Flows Marked with QoS=4: Lots of VoIP Signaling Traffic
Figure 2-13 QoS Between Different Companies over the Internet
Two key QoS issues exist in this case. First, the parties must agree to the different classifications of packets. In this example, all four networks agree to the need for four classes. (Agreement will not always occur!) For instance, McCoy Enterprises may want a different class for cus- tomer web traffic versus supplier web traffic. Even if all companies want these same general categories, it is difficult to effectively match the correct traffic for all companies connected to the Internet, because every company has different customers and suppliers. Therefore, QoS across the Internet may well end up using general categories—categories such as voice, video, voice/video signaling, important data, and not-so-important data.
Even with general categories agreed upon, not every network chooses to mark the IP packets with the same value to denote the same class. Figure 2-13 shows just such a case, where ISP1 and ISP2 agree to the values to use when marking packets, but McCoy Ordinance and Hatfield Gunsmiths, two long-time competitors, do not agree on what marked values to use.
Three commonsense QoS design choices help overcome common Internet QoS issues:
•
If neighboring autonomous systems do not agree about what traffic should be in eachclass, each autonomous system should reclassify ingress traffic based on more complex matching of packets based on the large variety of packet header fields.
•
If neighboring autonomous systems do agree about the classes, but not the marked values, each autonomous system should reclassify ingress traffic based on simple matching of packets based on the previously marked fields in the IP header, as shown in Figure 2-13.McCoy
Ordinance, Inc. ISP1 ISP2 QoS Field Marked For:
1: FTP Traffic 2: Web Traffic 3: VoIP Payload 4: VoIP Signaling
QoS Tools Expect: 0: FTP Traffic 2: Web Traffic 3: VoIP Signaling 5: VoIP Payload
QoS Tools Expect: 0: FTP Traffic 2: Web Traffic 3: VoIP Signaling 5: VoIP Payload
QoS Tools Expect: 0: Web Traffic 1: Voice Signaling 2: FTP Traffic 4: VoIP Payload
-ISP1 Trusts McCoy -Reclassify Marked Fields at Ingress:
QoS 1 = QoS 0 QoS 2 = QoS 2 QoS 3 = QoS 5 Qos 4 = QoS 3
ISP2 Trusts ISP1, No Need to Remap
-Hatfield Distrusts McCoy, Therefore Distrusting ISP1 and ISP2:
-Untrusted Link. Reclassify by Examining Packet Headers: Port 80 = QoS 0
Match all VoIP Signaling = QoS 1 Match Ports 20, 21 = QoS 2 Match UDP Port Range for VoIP = QoS 4
Gunsmiths Hatfield
•
If an autonomous system does not trust its neighbor regarding QoS, neighboring autonomous systems should also reclassify traffic at ingress, based on detailed matching of packets.The GOCS QoS model introduces some basic concepts for QoS. The following two sections cover in detail the two formal QoS architectural models, DiffServ and IntServ. Table 2-10 summarizes the key points from the GOCS model.
Table 2-10 Summary of GOCS Features
Feature Comments
Flow A flow is a unidirectional set of packets, sent from one source IP address and port, to one destination IP address and port, using the same transport layer protocol.
Flow-based QoS tools
Flow-based tools automatically recognize flows without explicit classification