How to Plan Forwarding Behavior
Forwarding behavior determines the priority and drop precedence of traffic flows that are about to be forwarded to the network. You can choose two major forwarding behaviors: prioritize the flows of a class in relationship to other traffic classes or drop the flows entirely.
The Diffserv model uses the marker to assign the chosen forwarding behavior to traffic flows. IPQoS offers the following marker modules.
dscpmk - Used to mark the DS field of an IP packet with a DSCP
dlcosmk - Used to mark the VLAN tag of a datagram with a class-of-service (CoS) value
Note - The suggestions in this section refer specifically to IP packets. If your IPQoS system includes a VLAN device, you can use the dlcosmk marker to mark forwarding behaviors for datagrams. For more information, refer to Using the dlcosmk Marker With VLAN Devices.
To prioritize IP traffic, you need to assign a DSCP to each packet. The dscpmk marker marks the DS field of the packet with the DSCP. You choose the DSCP for a class from a group of well-known codepoints that are associated with the forwarding behavior type. These well-known codepoints are 46 (101110) for the EF PHB and a range of codepoints for the AF PHB. For overview information on DSCP and forwarding, refer to Traffic Forwarding on an IPQoS-Enabled Network.
Before You Begin
The next steps assume that you have defined classes and filters for the QoS policy. Though you often use the meter with the marker to control traffic, you can use the marker alone to define a forwarding behavior.
Review the classes that you have created thus far and the priorities that you have assigned to each class.
Not all traffic classes need to be marked.
Assign the EF per-hop behavior to the class with the highest priority.
The EF PHB guarantees that packets with the EF DSCP 46 (101110) are released onto the network before packets with any AF PHBs. Use the EF PHB for your highest-priority traffic. For more information about EF, refer to Expedited Forwarding (EF) PHB.
Assign forwarding behaviors to classes that have traffic to be metered.
Assign DS codepoints to the remaining classes in agreement with the priorities that you have assigned to the classes.
Example 33-3 QoS Policy for a Games Application
Traffic is generally metered for the following reasons:
An SLA guarantees packets of this class greater service or lesser service when the network is heavily used.
A class with a lower priority might have a tendency to flood the network.
You use the marker with the meter to provide differentiated services and bandwidth management to these classes. For example, the following table shows a portion of a QoS policy. This policy defines a class for a popular games application that generates a high level of traffic.
Class | Priority | Filter | Selector | Rate | Forwarding? |
---|---|---|---|---|---|
games_app | 9 | games_in | sport 6080 | N/A | N/A |
games_app | 9 | games_out | dport 6081 | meter=tokenmt committed rate=5000000 committed burst =5000000 peak rate =10000000 peak burst=15000000 green precedence=continue processing yellow precedence=mark yellow PHB red precedence=drop | green =AF31 yellow=AF42 red=drop |
The forwarding behaviors assign low-priority DSCPs to games_app traffic that conforms to its committed rate or is under the peak rate. When games_app traffic exceeds peak rate, the QoS policy indicates that packets from games_app are to be dropped. All AF codepoints are listed in Table 37-2.
See Also
To plan for flow accounting of certain types of traffic, refer to How to Plan for Flow Accounting.
To add more classes to the QoS policy, refer to How to Define the Classes for Your QoS Policy.
To add more filters to the QoS policy, refer to How to Define Filters in the QoS Policy.
To define a flow-control scheme, refer to How to Plan Flow Control.
To define additional forwarding behaviors for flows as the packets return to the network stream, refer to How to Plan Forwarding Behavior.
To create an IPQoS configuration file, refer to How to Create the IPQoS Configuration File and Define Traffic Classes.
How to Plan for Flow Accounting
You use the IPQoS flowacct module to track traffic flows for billing or network management purposes. Use the following procedure to determine if your QoS policy should include flow accounting.
Does your company offer SLAs to customers?
If the answer is yes, then you should use flow accounting. Review the SLAs to determine what types of network traffic your company wants to bill customers for. Then, review your QoS policy to determine which classes select traffic to be billed.
Are there applications that might need monitoring or testing to avoid network problems?
If the answer is yes, consider using flow accounting to observe the behavior of these applications. Review your QoS policy to determine the classes that you have assigned to traffic that requires monitoring.
Mark Y in the flow-accounting column for each class that requires flow accounting in your QoS planning table.
See Also
To add more classes to the QoS policy, refer to How to Define the Classes for Your QoS Policy.
To add more filters to the QoS policy, refer to How to Define Filters in the QoS Policy.
To define a flow-control scheme, refer to How to Plan Flow Control.
To define forwarding behaviors for flows as the packets return to the network stream, refer to How to Plan Forwarding Behavior.
To plan for additional flow accounting of certain types of traffic, refer to How to Plan for Flow Accounting.
To create the IPQoS configuration file, refer to How to Create the IPQoS Configuration File and Define Traffic Classes.
Introducing the IPQoS Configuration Example
Tasks in the remaining chapters of the guide use the example IPQoS configuration that is introduced in this section. The example shows the differentiated services solution on the public intranet of BigISP, a fictitious service provider. BigISP offers services to large companies that reach BigISP through leased lines. Individuals who dial in from modems can also buy services from BigISP.