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 categories. 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 configuration 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 classification 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 configurations, 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

Mark

Ixl zXs

Mark Packet in One of the "QoS" Marking Fields

Mark at Ingress

Mark on Switch if Possible m fo

___i 1Z May Apply Different aoa-fa QoS Tools, Using

Different Parameters in m IE

Classify Easily Based on Previously Marked Fields

Mark Packet in One of the "QoS" Marking Fields

Mark at Ingress

Mark on Switch if Possible in m IE

Classify Easily Based on Previously Marked Fields

Server 1

V 4

i

■J*

3

HI

r'

S

9

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

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 probably 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 treatment—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.

Figure 2-13 QoS Between Different Companies over the Internet

QoS Field Marked For:

FTP Traffic Web Traffic VoIP Payload VoIP Signaling

QoS Tools Expect: 0: FTP Traffic 2: Web Traffic 3: VoIP Signaling 5: VoIP Payload

QoS Tools Expect:

FTP Traffic Web Traffic VoIP Signaling VoIP Payload

QoS Tools Expect:

Web Traffic Voice Signaling FTP Traffic VoIP Payload

FTP Traffic Web Traffic VoIP Payload VoIP Signaling

QoS Tools Expect: 0: FTP Traffic 2: Web Traffic 3: VoIP Signaling 5: VoIP Payload

FTP Traffic Web Traffic VoIP Signaling VoIP Payload

Web Traffic Voice Signaling FTP Traffic 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:

-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

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 customer 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 each class, 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.

• 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 configuration. Each flow can be treated differently, providing a great amount of granularity for QoS.

Class-based QoS tools

Class-based tools treat packets differently based on the category or class to which they belong. The number of classes chosen in a typical network is small (typically fewer than 10). Network engineers choose which types of packets are placed into each class, so class-based QoS tools require explicit configuration of classification parameters.

QoS tools that are neither flow or class based

Some QoS tools operate on all traffic entering or exiting an interface. Other tools may work on a predetermined type of traffic. For example, compressed RTP only operates on packets with RTP headers. Therefore, some tools do not need to consider flows or explicitly defined classes.

QoS class planning—enterprise

For a single enterprise network, a considered, thorough analysis of the network can yield a relatively small set of useful QoS packet categories. Agreement to these categories should occur before beginning the classification and marking strategy of marking near the edge.

Classification and marking

Packets should be classified and marked near the edge of the network, as packets enter the network. By doing so, classification configuration on the remaining routers in the packets' path is simplified, reducing processing overhead, complexity, the risk of misconfiguration.

QoS class planning—Internet

For the Internet, anything more than a handful of general class conventions is unlikely to be agreed upon by a large number of ISPs and customers. Cisco suggests a short list with five categories: VoIP payload, video payload, voice/ video signaling, important data, and not-so-important important data.

Internet reclassification and re-marking

Between different autonomous systems, reclassification and re-marking may need to occur. If the autonomous systems distrust each other, packets must be matched based on the contents of the various fields in their headers. If the autonomous systems trust each other, and agree on what packets belong to each of the traffic classes, all that may be required is to reclassify and re-mark based on the marked field inside the IP header.

Advance SEO Techniques

Advance SEO Techniques

Turbocharge Your Traffic And Profits On Auto-Pilot. Would you like to watch visitors flood into your websites by the 1,000s, without expensive advertising or promotions? The fact is, there ARE people with websites doing exactly that right now. How is that possible, you ask? The answer is Advanced SEO Techniques.

Get My Free Ebook


Post a comment