- •QoS Overview
- •“Do I Know This Already?” Quiz
- •QoS: Tuning Bandwidth, Delay, Jitter, and Loss Questions
- •Foundation Topics
- •QoS: Tuning Bandwidth, Delay, Jitter, and Loss
- •Bandwidth
- •The clock rate Command Versus the bandwidth Command
- •QoS Tools That Affect Bandwidth
- •Delay
- •Serialization Delay
- •Propagation Delay
- •Queuing Delay
- •Forwarding Delay
- •Shaping Delay
- •Network Delay
- •Delay Summary
- •QoS Tools That Affect Delay
- •Jitter
- •QoS Tools That Affect Jitter
- •Loss
- •QoS Tools That Affect Loss
- •Summary: QoS Characteristics: Bandwidth, Delay, Jitter, and Loss
- •Voice Basics
- •Voice Bandwidth Considerations
- •Voice Delay Considerations
- •Voice Jitter Considerations
- •Voice Loss Considerations
- •Video Basics
- •Video Bandwidth Considerations
- •Video Delay Considerations
- •Video Jitter Considerations
- •Video Loss Considerations
- •Comparing Voice and Video: Summary
- •IP Data Basics
- •Data Bandwidth Considerations
- •Data Delay Considerations
- •Data Jitter Considerations
- •Data Loss Considerations
- •Comparing Voice, Video, and Data: Summary
- •Foundation Summary
- •QoS Tools and Architectures
- •“Do I Know This Already?” Quiz
- •QoS Tools Questions
- •Differentiated Services Questions
- •Integrated Services Questions
- •Foundation Topics
- •Introduction to IOS QoS Tools
- •Queuing
- •Queuing Tools
- •Shaping and Policing
- •Shaping and Policing Tools
- •Congestion Avoidance
- •Congestion-Avoidance Tools
- •Call Admission Control and RSVP
- •CAC Tools
- •Management Tools
- •Summary
- •The Good-Old Common Sense QoS Model
- •GOCS Flow-Based QoS
- •GOCS Class-Based QoS
- •The Differentiated Services QoS Model
- •DiffServ Per-Hop Behaviors
- •The Class Selector PHB and DSCP Values
- •The Assured Forwarding PHB and DSCP Values
- •The Expedited Forwarding PHB and DSCP Values
- •The Integrated Services QoS Model
- •Foundation Summary
- •“Do I Know This Already?” Quiz Questions
- •CAR, PBR, and CB Marking Questions
- •Foundation Topics
- •Marking
- •IP Header QoS Fields: Precedence and DSCP
- •LAN Class of Service (CoS)
- •Other Marking Fields
- •Summary of Marking Fields
- •Class-Based Marking (CB Marking)
- •Network-Based Application Recognition (NBAR)
- •CB Marking show Commands
- •CB Marking Summary
- •Committed Access Rate (CAR)
- •CAR Marking Summary
- •Policy-Based Routing (PBR)
- •PBR Marking Summary
- •VoIP Dial Peer
- •VoIP Dial-Peer Summary
- •Foundation Summary
- •Congestion Management
- •“Do I Know This Already?” Quiz
- •Queuing Concepts Questions
- •WFQ and IP RTP Priority Questions
- •CBWFQ and LLQ Questions
- •Comparing Queuing Options Questions
- •Foundation Topics
- •Queuing Concepts
- •Output Queues, TX Rings, and TX Queues
- •Queuing on Interfaces Versus Subinterfaces and Virtual Circuits (VCs)
- •Summary of Queuing Concepts
- •Queuing Tools
- •FIFO Queuing
- •Priority Queuing
- •Custom Queuing
- •Weighted Fair Queuing (WFQ)
- •WFQ Scheduler: The Net Effect
- •WFQ Scheduling: The Process
- •WFQ Drop Policy, Number of Queues, and Queue Lengths
- •WFQ Summary
- •Class-Based WFQ (CBWFQ)
- •CBWFQ Summary
- •Low Latency Queuing (LLQ)
- •LLQ with More Than One Priority Queue
- •IP RTP Priority
- •Summary of Queuing Tool Features
- •Foundation Summary
- •Conceptual Questions
- •Priority Queuing and Custom Queuing
- •CBWFQ, LLQ, IP RTP Priority
- •Comparing Queuing Tool Options
- •“Do I Know This Already?” Quiz
- •Shaping and Policing Concepts Questions
- •Policing with CAR and CB Policer Questions
- •Shaping with FRTS, GTS, DTS, and CB Shaping
- •Foundation Topics
- •When and Where to Use Shaping and Policing
- •How Shaping Works
- •Where to Shape: Interfaces, Subinterfaces, and VCs
- •How Policing Works
- •CAR Internals
- •CB Policing Internals
- •Policing, but Not Discarding
- •Foundation Summary
- •Shaping and Policing Concepts
- •“Do I Know This Already?” Quiz
- •Congestion-Avoidance Concepts and RED Questions
- •WRED Questions
- •FRED Questions
- •Foundation Topics
- •TCP and UDP Reactions to Packet Loss
- •Tail Drop, Global Synchronization, and TCP Starvation
- •Random Early Detection (RED)
- •Weighted RED (WRED)
- •How WRED Weights Packets
- •WRED and Queuing
- •WRED Summary
- •Flow-Based WRED (FRED)
- •Foundation Summary
- •Congestion-Avoidance Concepts and Random Early Detection (RED)
- •Weighted RED (WRED)
- •Flow-Based WRED (FRED)
- •“Do I Know This Already?” Quiz
- •Compression Questions
- •Link Fragmentation and Interleave Questions
- •Foundation Topics
- •Payload and Header Compression
- •Payload Compression
- •Header Compression
- •Link Fragmentation and Interleaving
- •Multilink PPP LFI
- •Maximum Serialization Delay and Optimum Fragment Sizes
- •Frame Relay LFI Using FRF.12
- •Choosing Fragment Sizes for Frame Relay
- •Fragmentation with More Than One VC on a Single Access Link
- •FRF.11-C and FRF.12 Comparison
- •Foundation Summary
- •Compression Tools
- •LFI Tools
- •“Do I Know This Already?” Quiz
- •Foundation Topics
- •Call Admission Control Overview
- •Call Rerouting Alternatives
- •Bandwidth Engineering
- •CAC Mechanisms
- •CAC Mechanism Evaluation Criteria
- •Local Voice CAC
- •Physical DS0 Limitation
- •Max-Connections
- •Voice over Frame Relay—Voice Bandwidth
- •Trunk Conditioning
- •Local Voice Busyout
- •Measurement-Based Voice CAC
- •Service Assurance Agents
- •SAA Probes Versus Pings
- •SAA Service
- •Calculated Planning Impairment Factor
- •Advanced Voice Busyout
- •PSTN Fallback
- •SAA Probes Used for PSTN Fallback
- •IP Destination Caching
- •SAA Probe Format
- •PSTN Fallback Scalability
- •PSTN Fallback Summary
- •Resource-Based CAC
- •Resource Availability Indication
- •Gateway Calculation of Resources
- •RAI in Service Provider Networks
- •RAI in Enterprise Networks
- •RAI Operation
- •RAI Platform Support
- •Cisco CallManager Resource-Based CAC
- •Location-Based CAC Operation
- •Locations and Regions
- •Calculation of Resources
- •Automatic Alternate Routing
- •Location-Based CAC Summary
- •Gatekeeper Zone Bandwidth
- •Gatekeeper Zone Bandwidth Operation
- •Single-Zone Topology
- •Multizone Topology
- •Zone-per-Gateway Design
- •Gatekeeper in CallManager Networks
- •Zone Bandwidth Calculation
- •Gatekeeper Zone Bandwidth Summary
- •Integrated Services / Resource Reservation Protocol
- •RSVP Levels of Service
- •RSVP Operation
- •RSVP/H.323 Synchronization
- •Bandwidth per Codec
- •Subnet Bandwidth Management
- •Monitoring and Troubleshooting RSVP
- •RSVP CAC Summary
- •Foundation Summary
- •Call Admission Control Concepts
- •Local-Based CAC
- •Measurement-Based CAC
- •Resources-Based CAC
- •“Do I Know This Already?” Quiz
- •QoS Management Tools Questions
- •QoS Design Questions
- •Foundation Topics
- •QoS Management Tools
- •QoS Device Manager
- •QoS Policy Manager
- •Service Assurance Agent
- •Internetwork Performance Monitor
- •Service Management Solution
- •QoS Management Tool Summary
- •QoS Design for the Cisco QoS Exams
- •Four-Step QoS Design Process
- •Step 1: Determine Customer Priorities/QoS Policy
- •Step 2: Characterize the Network
- •Step 3: Implement the Policy
- •Step 4: Monitor the Network
- •QoS Design Guidelines for Voice and Video
- •Voice and Video: Bandwidth, Delay, Jitter, and Loss Requirements
- •Voice and Video QoS Design Recommendations
- •Foundation Summary
- •QoS Management
- •QoS Design
- •“Do I Know This Already?” Quiz
- •Foundation Topics
- •The Need for QoS on the LAN
- •Layer 2 Queues
- •Drop Thresholds
- •Trust Boundries
- •Cisco Catalyst Switch QoS Features
- •Catalyst 6500 QoS Features
- •Supervisor and Switching Engine
- •Policy Feature Card
- •Ethernet Interfaces
- •QoS Flow on the Catalyst 6500
- •Ingress Queue Scheduling
- •Layer 2 Switching Engine QoS Frame Flow
- •Layer 3 Switching Engine QoS Packet Flow
- •Egress Queue Scheduling
- •Catalyst 6500 QoS Summary
- •Cisco Catalyst 4500/4000 QoS Features
- •Supervisor Engine I and II
- •Supervisor Engine III and IV
- •Cisco Catalyst 3550 QoS Features
- •Cisco Catalyst 3524 QoS Features
- •CoS-to-Egress Queue Mapping for the Catalyst OS Switch
- •Layer-2-to-Layer 3 Mapping
- •Connecting a Catalyst OS Switch to WAN Segments
- •Displaying QoS Settings for the Catalyst OS Switch
- •Enabling QoS for the Catalyst IOS Switch
- •Enabling Priority Queuing for the Catalyst IOS Switch
- •CoS-to-Egress Queue Mapping for the Catalyst IOS Switch
- •Layer 2-to-Layer 3 Mapping
- •Connecting a Catalyst IOS Switch to Distribution Switches or WAN Segments
- •Displaying QoS Settings for the Catalyst IOS Switch
- •Foundation Summary
- •LAN QoS Concepts
- •Catalyst 6500 Series of Switches
- •Catalyst 4500/4000 Series of Switches
- •Catalyst 3550/3524 Series of Switches
- •QoS: Tuning Bandwidth, Delay, Jitter, and Loss
- •QoS Tools
- •Differentiated Services
- •Integrated Services
- •CAR, PBR, and CB Marking
- •Queuing Concepts
- •WFQ and IP RTP Priority
- •CBWFQ and LLQ
- •Comparing Queuing Options
- •Conceptual Questions
- •Priority Queuing and Custom Queuing
- •CBWFQ, LLQ, IP RTP Priority
- •Comparing Queuing Tool Options
- •Shaping and Policing Concepts
- •Policing with CAR and CB Policer
- •Shaping with FRTS, GTS, DTS, and CB Shaping
- •Shaping and Policing Concepts
- •Congestion-Avoidance Concepts and RED
- •WRED
- •FRED
- •Congestion-Avoidance Concepts and Random Early Detection (RED)
- •Weighted RED (WRED)
- •Flow-Based WRED (FRED)
- •Compression
- •Link Fragmentation and Interleave
- •Compression Tools
- •LFI Tools
- •Call Admission Control Concepts
- •Local-Based CAC
- •Measurement-Based CAC
- •Resources-Based CAC
- •QoS Management Tools
- •QoS Design
- •QoS Management
- •QoS Design
- •LAN QoS Concepts
- •Catalyst 6500 Series of Switches
- •Catalyst 4500/4000 Series of Switches
- •Catalyst 3550/3524 Series of Switches
- •Foundation Topics
- •QPPB Route Marking: Step 1
- •QPPB Per-Packet Marking: Step 2
- •QPPB: The Hidden Details
- •QPPB Summary
- •Flow-Based dWFQ
- •ToS-Based dWFQ
- •Distributed QoS Group–Based WFQ
- •Summary: dWFQ Options
108Chapter 2: QoS Tools and Architectures
•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 collective web flows the exact same way with their QoS tools. Therefore, most QoS tools tend to operate 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
May Apply Different |
May Apply Different |
May Apply Different |
QoS Tools, Using |
QoS Tools, Using |
QoS Tools, Using |
Different Parameters |
Different Parameters |
Different Parameters |
Classify Just Like Other Routers, Based on Lots of Header Fields
IP
Classify Just Like Other Routers, Based on Lots of Header Fields
Hannah
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SW1 |
R1 s0 s0 R2 s1 |
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Classify Just Like Other
Routers, Based on Lots of
Header Fields
|
|
|
Server 1 |
|
|
|
IP |
|
|
|
FA0 |
T1 |
s0 |
R3 |
SW2 |
201
301
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,
The Good-Old Common Sense QoS Model 109
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 categories. You need to use six different IOS QoS tools—which is not an unreasonable choice,
110 Chapter 2: QoS Tools and Architectures
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.
The Good-Old Common Sense QoS Model 111
Figure 2-12 GOCS Design: Mark Packets near the Edge of the Network
Mark
X |
Y |
Z |
May Apply Different
QoS Tools, Using
Different Parameters
Mark Packet in One of the “QoS” Marking Fields |
Classify Easily Based on |
Mark at Ingress |
Previously Marked Fields |
Mark on Switch if Possible |
|
Server 1
IP |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
IP |
Hannah |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FA0 |
SW1 |
R1 |
s0 |
s0 |
R2 |
s1 |
T1 |
s0 |
R3 |
SW2 |
201
301
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 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.
112 Chapter 2: QoS Tools and Architectures
Figure 2-13 QoS Between Different Companies over the Internet
QoS Field Marked For: |
QoS Tools Expect: |
QoS Tools Expect: |
QoS Tools Expect: |
||
1: FTP Traffic |
0: FTP Traffic |
0: FTP Traffic |
0: Web Traffic |
||
2: Web Traffic |
2: Web Traffic |
2: Web Traffic |
1: Voice Signaling |
||
3: VoIP Payload |
3: VoIP Signaling |
3: VoIP Signaling |
2: FTP Traffic |
||
4: VoIP Signaling |
5: VoIP Payload |
5: VoIP Payload |
4: VoIP Payload |
||
McCoy |
|
ISP1 |
|
ISP2 |
Hatfield |
Ordinance, Inc. |
|
|
Gunsmiths |
||
|
|
|
|
||
-ISP1 Trusts McCoy |
ISP2 Trusts ISP1, |
-Hatfield Distrusts McCoy, |
|||
-Reclassify Marked Fields |
No Need to Remap |
Therefore Distrusting ISP1 |
|||
at Ingress: |
|
|
|
and ISP2: |
|
QoS 1 = QoS 0 |
|
|
|
-Untrusted Link. Reclassify by |
|
QoS 2 = QoS 2 |
|
|
|
Examining Packet Headers: |
|
QoS 3 = QoS 5 |
|
|
|
|
|
Qos 4 = QoS 3 |
|
|
|
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.
The Good-Old Common Sense QoS Model 113
•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 |
Flow-based tools automatically recognize flows without explicit classification |
tools |
configuration. Each flow can be treated differently, providing a great amount |
|
of granularity for QoS. |
|
|
Class-based QoS |
Class-based tools treat packets differently based on the category or class to |
tools |
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 |
Some QoS tools operate on all traffic entering or exiting an interface. Other |
neither flow or class |
tools may work on a predetermined type of traffic. For example, compressed |
based |
RTP only operates on packets with RTP headers. Therefore, some tools do not |
|
need to consider flows or explicitly defined classes. |
|
|
QoS class |
For a single enterprise network, a considered, thorough analysis of the network |
planning—enterprise |
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 |
Packets should be classified and marked near the edge of the network, as |
marking |
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 |
For the Internet, anything more than a handful of general class conventions is |
planning—Internet |
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 reclassifica- |
Between different autonomous systems, reclassification and re-marking may |
tion and re-marking |
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. |
|
|