4 Defining Standard Per Hop Behavior Groups

This chapter describes how to implement queuing and traffic shaping mechanisms in an Oracle Communications IP Service Activator network using standard Per Hop Behavior (PHB) groups. The chapter:

• Provides an overview of standard PHB groups and the queuing and traffic shaping mechanisms that can be implemented using IP Service Activator

• Highlights points you should consider before setting up standard PHB groups

See "Implementing and Managing Per Hop Behavior Groups" for details on implementing and managing PHB groups. See "Defining MQC PHB Groups" for information on defining MQC PHB groups.

Introduction

A PHB group provides a way of managing traffic at specific interfaces by implementing a device-specific queuing or traffic shaping mechanism. Standard PHB groups manage traffic in one of two ways:

• Class-of-service (CoS) mechanisms allow you to define different priorities or bandwidth allocations for each class of service that will be used in your network. Examples include configuring Weighted Round Robin (WRR) and Priority Queuing (PQ).

• VC mechanisms allow you to set up ATM and Frame Relay-specific traffic shaping at the VC endpoint level. These mechanisms apply to all traffic on the endpoint, irrespective of class of service.

A PHB group can be applied to a network component (such as a network, device or interface) or to a customer, site or VPN. As for any other policy element, the policy targets that a PHB group actually applies to are controlled using policy roles and the inheritance model.

Within IP Service Activator there are no restrictions on where a PHB group can be applied. For example, you can apply a WRR PHB group to a device at the network edge or in the network core.

Note:

IP Service Activator's ability to install a PHB group on a network object is dependent on an interface's capabilities. For example, a WRR PHB group can only be installed on an interface whose capabilities show WRR support. For information on checking interface capabilities, see IP Service Activator User's Guide.

Supported Traffic Shaping/Queuing Mechanisms

This section discusses CoS mechanisms, VC traffic shaping mechanisms, vendor support, and CoS mechanism combinations.

Class of Service Mechanisms

The following queuing and shaping mechanisms can be implemented within a standard PHB group and applied to traffic by CoS:

• WRR

• PQ

• Rate limiting/traffic shaping

• Weighted Random Early Detection (WRED)

• Weighted Fair Queuing (WFQ)

VC Traffic Shaping Mechanisms

The following per-VC traffic shaping mechanisms can be implemented within a standard PHB group:

• ATM Traffic Shaping

• Frame Relay Traffic Shaping (FRTS)

ATM traffic shaping and FRTS are applied to all traffic on the VC endpoint. They cannot be applied to selected classes of service.

Vendor Support

Table 4-1 summarizes device type support for each class of service mechanism.

Table 4-1 Device Type Support

Mechanism	Cisco	Juniper M-series	Juniper E-series
WRR	Y	Y	N
PQ	Y	N	N
Rate Limiting	Y	Y	N
WRED	Y	Y	N
WFQ	Y	Y	N
ATM Traffic Shaping	Y	N	N
FRTS	Y	N	N

*Only applies to a port in a layer 2 site.

Note:

If you apply FRTS to Frame Relay interfaces on distributed platforms, such as 75xx VIP-based devices, IP Service Activator configures Distributed Traffic Shaping (DTS) rather than FRTS. Alternatively, you can apply FRTS to Frame Relay interfaces on distributed platforms using an MQC PHB group. See "Defining MQC PHB Groups" for more information.

Class of Service Mechanism Combinations

Table 4-2 shows the CoS mechanism combinations that are permitted in a standard PHB group.

Table 4-2 Standard PHB Group CoS Mechanism Combinations

CoS	WRR	WFQ	PQ	WRED	Rate Limiting	ATM TS	FRTS
WRR	Y	N	N	N	Y	N	Y
WFQ	N	Y	N	Y	N	N	Y
PQ	N	N	Y	N	Y	N	Y
WRED	N	Y	N	Y	N	N	N
Rate Limiting	Y	N	Y	N	Y	N	N
ATM TS	Y	Y	Y	Y	Y	Y	N
FRTS	Y	Y	Y	Y	N	N	Y

WRR and Priority Queuing are mutually exclusive, but on some devices you can implement rate limiting in conjunction with a queuing mechanism.

On Cisco devices, you can implement Low Latency Queuing (LLQ) on a Frame Relay interface by selecting Priority Queuing for class-based WFQ in combination with FRTS or you can use an MQC PHB group.

Table 4-3 shows the combinations of QoS actions permitted in an MQC PHB group.

Table 4-3 MQC PHB Group QoS Combinations

QoS	LLQ	CB-WFQ	SR Police	TR Police	Shape	Mark	Congestion	Nest	RTP Compression
LLQ	*	N	Y	Y	N	Y	Y	Y	Y
CB-WFQ	N	*	Y	Y	Y	Y	Y#	Y	Y
SR Police	Y	Y	*	N	Y	Y	Y#	Y	Y
TR Police	Y	Y	N	*	Y	Y	Y#	Y	Y
Shape	N	Y	Y	Y	*	Y	Y	Y	Y
Mark	Y	Y	Y	Y	Y	*	Y#	Y+	Y
Congestion	Y	Y#	Y#	Y#	Y	Y#	#	Y#	Y#
Nest	Y	Y	Y	Y	Y	Y+	Y#	+	Y+
RTP Compression	Y	Y	Y	Y	Y	Y	Y#	Y+	*

Note:

Y – Combination of the two QoS actions is allowed

* – Can be selected on its own

# – Requires Shape, LLQ, and/or CB-WFQ to be selected except for the default CoS

+ – Requires any combination of Shape, SR/TR Police, CB-WFQ, LLQ

N – Combination of the two QoS actions is not allowed

Before Setting Up a Standard PHB Group

This section outlines the points you need to consider before setting up a standard PHB group.

Selecting the Queuing or Traffic Shaping Mechanisms

The decision as to which queuing or traffic shaping mechanism to use depends on the policy you want to implement and the capabilities of the router. Since the available techniques are often specific to the device type, operating system and interface, consult the relevant vendor's documentation for your specific device(s).

IP Service Activator reports the capabilities of each interface. Ensure the interface is reported by IP Service Activator to support the desired operation. For information on checking an interface's capabilities, see IP Service Activator User's Guide. For more information about supported capabilities, consult the router documentation.

You must set up a standard PHB group for each different queuing mechanism you want to implement.

Deciding Where to Apply the Standard PHB Groups

A standard PHB group defines a queuing or shaping mechanism that can be used at various points in the network. For example, a PHB group might be used to manage the traffic going into the core network or to maintain the prioritization set up at the network edge throughout the core network.

PHB groups are implemented on the inbound and/or outbound interfaces of the routers to which they are applied. However, they are created as templates within a domain and can be applied to various points throughout the network.

A PHB group, applied to devices and interfaces sharing the same role on the root level network, will also automatically apply to all relevant interfaces throughout the network. In accordance with IP Service Activator's policy inheritance model, a locally defined PHB group overrides a PHB group defined at a higher level. Because IP Service Activator can only apply one concrete PHB group to an interface, a locally defined PHB group will take precedence over the inherited PHB group.

See "Policy Inheritance" for more information on inheritance.

Using Roles in PHB Groups

Every PHB group must have a device and interface role associated with it. The roles you associate with a PHB group specify the policy targets to which the queuing mechanism will apply. See "Using Roles in Policy Elements" for information on using roles in policy elements.

Depending on the roles that you assign to policy targets, it is possible to apply policy only at very specific points in the network. For example, you can apply a role to a sub-interface independent of its parent interface. By associating a PHB group with the sub-interface role you can apply policy only at the sub-interface.

Importing Policy Files

IP Service Activator provides sample PHB groups and policy rules in policy files located in the SamplePolicy directory. See "Importing QoS-related Policy Files" for information on loading these policy files.

Note:

When you create a PHB group there are no policy roles associated with it by default. You must associate both a device and an interface role for the PHB group's configuration to be applied at the appropriate points in the network. If either the device or interface role are not specified, no configuration will be applied.

Setting Up a Standard PHB Group

When setting up a standard PHB group you must specify:

• The classes of service and/or VCs that are to be controlled by the PHB group

• The roles that define the policy target of the PHB group

• The queuing mechanism to be used, and any specific parameters that need to be set. This will depend on the mechanisms available on the devices to which the PHB group will be applied.

For complete dialog box and property page descriptions, refer to IP Service Activator online Help.

Setup and Application of PHB and MQC PHB Groups as Separate Operations

PHB groups can be created and stored as definitions within the object model. These PHB groups are visible under the Policy tab, but until they are applied to an object, they exist only as definitions and have no effect. Defined PHB groups are instantiated when they are applied to a target object in the object model. The normal rules of roles and inheritance apply to the target object and its sub-objects in the hierarchy.

An overview of the steps follows:

1. Right-click the PHB Groups folder and create a new PHB group.

2. Configure the PHB group and commit the transaction.

3. Display the target object in the Details pane.

4. Display the PHB group in the hierarchy pane.

5. Drag the PHB group onto the target object.

6. Commit the transaction.

This procedure applies to both PHB and MQC PHB Groups.

Setup and Application of PHB and MQC PHB Groups as a Combined Single Operation

You can combine the creation of the PHB Group definition and the instantiation of that PHB Group definition onto a target object into one operation.

An overview of the steps follows:

1. Right-click the target object and create a new PHB group.

2. Configure the PHB group and commit the transaction.

The PHB group definition is shown in the Policy tab.

This procedure applies to both PHB and MQC PHB Groups.

Setting Up a Standard PHB Group

To set up a standard PHB group:

1. Do one of the following:

   • On the Policy tab, select the PHB Groups folder.

   • Select a target object — a network component, device, interface, customer, site, or VPN.

2. Right-click on the folder or target object and select Add PHB Group from the pop-up menu.

   The PHB Group dialog box opens.

3. Enter values including Name, Configured Name, and Direction.

4. If a Virtual Circuit-based mechanism is to be applied, select ATM or FRTS.

   Note that these techniques are applied to all traffic on the VC, not per class of service. You can configure FRTS in conjunction with WRR, Priority Queuing, or CB-WFQ for finer control of traffic prioritization and queuing.

5. For CoS mechanisms, specify the classes of service to be controlled by this PHB group.

   Click on the check box associated with the desired CoS Mechanism.

6. Select the CoS queuing mechanism(s) that the PHB group will apply. See "Class of Service Mechanism Combinations" for more information.

   Click Apply to apply the changes before setting specific details of the selected CoS mechanisms.

7. Select the Role property page and select the device and interface roles to which the PHB group applies.

   You must specify both a device and an interface role. The system-defined Any Role can be used to apply the PHB group to any device or interface tagged with a role. See "Using Roles in PHB Groups" for information on using roles in PHB groups.

8. Select the appropriate property page(s), depending on the mechanism(s) selected and set the appropriate parameters. For details of configuring each mechanism, see the appropriate description:

   • WRR – "Setting up Weighted Round Robin"

   • PQ – "Setting up Priority Queuing"

   • Rate Limiting/Traffic Shaping – "Setting Up Rate Limiting "

   • WFQ – "Setting Up Weighted Fair Queuing"

   • WRED – "Setting Up Weighted Random Early Detection"

   • FRTS – "Setting Up Frame Relay Traffic Shaping"

   • ATM Traffic Shaping – "Setting Up ATM Traffic Shaping"

9. Click OK to close the dialog box and save the PHB group.

Setting up Weighted Round Robin

Weighted Round Robin (WRR) is a mechanism for allocating bandwidth to queues so that higher priority applications have more bandwidth than lower priority applications when the network is congested. Custom Queuing in Cisco devices is an implementation of WRR.

For complete dialog box and property page descriptions, refer to IP Service Activator online Help.

To set up WRR:

1. Select the WRR property page on the PHB Group dialog box.

2. Select the Class of Service and set Weight and Packet limit values.

3. Click Apply before changing another value. The specified weight is converted to a bandwidth percentage.

4. Repeat steps 2 to 3 for each class of service to be set up.

Setting up Priority Queuing

Priority Queuing specifies that each packet is to be placed in one of a number of queues according to its priority. Packets on the highest-priority queue are transmitted first; when that queue is empty, packets on the next-highest queue are transmitted, and so on.

For complete dialog box and property page descriptions, refer to IP Service Activator online Help.

To set up Priority Queuing:

1. Select the Priority Queuing property page on the PHB Group dialog box.

2. Selecting each CoS in turn, specify the Priority that will be applied (High, Medium, Normal or Low).

3. Click Apply before changing another value.

4. Repeat steps 2 to 3 for each class of service to be set up.

Setting Up Rate Limiting

Rate limiting, or traffic shaping, constrains specific outbound traffic to a particular bandwidth. It is commonly used to control access to the core network. It can be used to regulate the flow of traffic in order to avoid the congestion that can occur when transmitted traffic exceeds the access speed of the remote interface.

For complete dialog box and property page descriptions, refer to the IP Service Activator online Help.

To set up Rate Limiting:

1. Select the Rate Limiting property page on the PHB Group dialog box.

2. Choose the Class of Service and set the Average rate, Burst rate, and Burst interval.

3. Click Apply before changing another value.

4. Repeat steps 2 to 3 for each class of service to be set up.

Setting Up Weighted Random Early Detection

Weighted Random Early Detection (WRED) is a variant of the RED mechanism, which drops packets randomly in times of congestion. WRED drops packets at specified thresholds. Different thresholds can be specified according to the IP Precedence or DiffServ codepoint of the packet. A minimum threshold level defines the queue size at which packets start to be dropped and a maximum threshold level defines the queue size at which a specified number of packets are dropped.

Applying WRED avoids congestion and is commonly used in the network core.

Normally, the WRED implementation on the device calculates default values for the minimum and maximum threshold settings for each interface, depending on the buffering capacity and speed of the interface.

To take advantage of this, use the As default setting. It is possible to override the defaults and set specific threshold values in the PHB, if required.

An MQC PHB group configured with congestion avoidance can use the WRED settings configured in a standard PHB group. The standard PHB group must only have WRED configured, can have any CoS associated with it that is not linked to a classification and must be linked to at least one packet marking. See "Setting Up Congestion Avoidance" for more information.

For complete dialog box and property page descriptions, refer to the IP Service Activator online Help.

To set up WRED with default values:

1. Select the WRED property page on the PHB Group dialog box.

2. Ensure the As default check box is selected.

3. Click Apply or OK.

To set up WRED with specific values for an interface:

1. Select the WRED property page on the PHB Group dialog box.

2. Clear the As default check box.

3. Select Explicit Congestion Notification, if required.

4. Choose the Class of Service for which you want to set specific parameters.

5. Specify the Min threshold, Max threshold, and Drop probability.

6. If necessary, amend the default Weight Factor – an exponent weight factor used to calculate the average queue size. The range is 1 to 16, the default is 9.

7. Click Apply before changing another value.

8. Repeat steps 3 to 6 for each class of service to be set up.

You can configure WRED in conjunction with Class-based WFQ to define the drop strategy. See "Setting Up Weighted Fair Queuing" for more information.

Setting Up Weighted Fair Queuing

Weighted Fair Queuing (WFQ) is a queuing algorithm used for congestion management.

There are two types of WFQ:

• Flow-based: Used by default on all serial interfaces less than 2 Mbits/s on Cisco routers. A flow is identified as all packets with the same source IP address, destination IP address and source or destination TCP or UDP port. WFQ allocates an equal share of the available bandwidth to each flow.

• Class-based WFQ (CB-WFQ): Only supported on a restricted set of Cisco routers. It allows you to allocate a particular bandwidth to a particular class of service. Each class is allocated to a particular queue according to its bandwidth. A traffic class allocated a higher bandwidth has a higher priority than a traffic class allocated less bandwidth.

On Cisco routers, for interfaces that support WFQ you can either specify that flow-based WFQ is applied, or select CB-WFQ and set specific parameters for each class of service.

CB-WFQ can also be implemented on Cisco devices using an MQC PHB group. "Setting Up Class-Based Weighted Fair Queuing" for more information.

On Cisco devices, by default, flow-based queuing is applied and no parameters can be set. Since there may be very large numbers of individual flows, and one queue per flow, this is process-intensive, and is not recommended for fast interfaces.

For details on vendor support for PHB group properties, refer to the vendor-specific cartridge guide.

For complete dialog box and property page descriptions, refer to IP Service Activator online Help.

To set up flow-based WFQ:

1. Select the WFQ property page on the PHB Group dialog box.

2. Ensure the Class Based check box is cleared.

3. Click OK. Flow-based WFQ is configured on the appropriate interfaces using default parameters.

To set up CB-WFQ:

1. Select the WFQ property page on the PHB Group dialog box.

2. Select the Class Based check box.

3. Specify how the Weight field is interpreted by selecting Interpret Weight as either Kbps or Percent.

   Kbps specifies that values are entered directly.

   Percent specifies values as a percentage of available bandwidth.

4. Choose the Class of Service for which you want to set the weighting parameters.

5. Specify the Weight. This value specifies the weighting to be allocated to the selected class of service, either a Kbps value or a percentage, as specified above. By default, all classes are allocated equal weighting. Bandwidth values can be entered as exact values in kbits/s or as percentage values. If kbps is selected, weights entered must be in the range:

   For Low priority queues: 8 - 2 000 000

   For High priority queues: 32 - 155 000

   Choose a Queue Priority, of High if the traffic is directed to the CB-WFQ strict priority queue. Priority queuing for CB-WFQ (PQ CB-WFQ or LLQ) is particularly relevant to delay-sensitive data, such as voice traffic where it reduces jitter. You can include any number of Classes of Service in the priority queue.

   For Frame Relay traffic, you can set the Frame Relay Discard Eligibility (DE) bit for specific classes of service considered to be of lower priority. To set the DE bit for a particular class, select the Set DE check box.

6. Select the Drop Strategy by choosing one of the following options from the drop-down list:

   • Default - drop packets according to the device default

   • Tail Drop - apply tail drop. A queue depth limit can be specified, and so can the units.

     • Limit - maximum queue depth in packets, if Tail Drop is selected as the Drop Strategy.

     • Units - cells, default, microseconds, milliseconds, packets

       Note:

       If the Queue Priority is High, then the drop strategy must be set to default.

   • Default WRED - apply WRED to the queue, using the default WRED parameters.

     Any parameters entered on the WRED property page are ignored. Note that you must have selected WRED on the PHB Group property page.

   • WRED - apply WRED to the queue and set specific parameters on the WRED property page (see Configuring WRED). The Min Threshold, Max Threshold and Drop Probability parameters can be set per codepoint. For example if there are two codepoints in a class of service, two queues are configured, each of which can have independent WRED settings. The Weight Factor can be set per class of service.

7. Click Apply before changing to another class of service.

8. Repeat steps 3 to 7 for each class of service to be set up.

Note:

For information on monitoring the class maps that are configured for a CB WFQ PHB group, see IP Service Activator Network and SLA Monitoring Guide.

Setting Up ATM Traffic Shaping

Traffic shaping specifies a queuing mechanism to limit surges that can congest a network. Data is buffered and then sent into the network in regulated amounts to ensure that the traffic will fit within the promised traffic envelope for the particular connection.

For complete dialog box and property page descriptions, refer to IP Service Activator online Help.

To set up ATM Traffic Shaping

1. Select the ATM property page on the PHB Group dialog box.

2. In the field VC class name select Generated to use a system generated VC class name. To manually specify a name, type the name in the field. The maximum length of the name is 126 characters.

3. Select the Service Category.

4. Set the appropriate parameters including PCR, SCR MBS and MCR.

5. Specify appropriate values in Hold queue depth and Transmit ring buffer limit.

6. Click OK.

Setting Up Frame Relay Traffic Shaping

Frame Relay Traffic Shaping (FRTS) delays excess traffic using a queuing mechanism to hold packets and shape the flow when the data rate of the source is higher than expected. FRTS is sometimes used to eliminate bottlenecks in Frame Relay networks that have high-speed connections at the central site and low-speed connections at branch sites. A rate enforcement is configured to limit the rate at which data is sent on the VC at the central site.

FRTS is applied at VC level and can be combined with PQ, WRR, CB-WFQ or WRED applied at the VC or sub-interface. This allows for finer control over traffic prioritization and queuing.

You can configure FRTS to use information contained in the BECN (Backward Explicit Congestion Notification) and FECN (Forward Explicit Congestion Notification)-tagged frames received from the network. These features throttle traffic dynamically when congestion occurs.

The FRTS PHB group also allows you to apply FRF.12 fragmentation to traffic, either in conjunction with traffic shaping or independently. FRF.12 is a Frame Relay standard that allows long data frames to be fragmented into smaller pieces and interleaved with real-time frames. This means that real-time voice and non real-time data frames can be carried together on lower speed networks without causing excessive delay to the real-time traffic.

Note:

FRTS with FRF.12 cannot be used in combination with WRR or Priority Queuing.

You can implement LLQ on a Frame Relay interface by selecting FRTS in combination with CB-WFQ. For information on support for LLQ by Cisco devices, refer to the vendor-specific cartridge guide.

For complete dialog box and property page descriptions, refer to IP Service Activator online Help.

To set up FRTS:

1. Select the FRTS property page on the PHB Group dialog box.

2. To configure FRF.12, select the FRF.12 check box and set the required Fragment size.

3. To configure traffic shaping, select the Shaping check box and set the parameters including CIR, Min CIR, Bc, and Be. You can configure Inbound and Outbound parameters independently, for vendor specific devices.

4. Select the BECN Adapt check box if you want to monitor for Frame Relay frames that have the BECN (Backward Explicit Congestion Notification) bit set.

5. Select the FECN Adapt check box if you want to monitor for Frame Relay frames that have the FECN (Forward Explicit Congestion Notification) bit set.

6. In the Hold queue depth, specify the maximum number of packets that can be stored in the traffic-shaping queue for a Frame Relay PVC. Select Device default to specify the default value for that particular device.

7. Click OK.

Distributed Traffic Shaping

If you apply FRTS to Frame Relay interfaces on distributed platforms, such as 75xx VIP-based devices, IP Service Activator configures Distributed Traffic Shaping (DTS) rather than FRTS. Like other traffic shaping mechanisms, DTS buffers excess traffic and regulates the rate at which packets are sent into the network, setting a Committed Information Rate (CIR) a Committed Burst (Bc) and an Excess Burst rate (Be).

Although the same parameters are configured for DTS, note that the permitted parameter ranges are different from those for FRTS. Table 4-4 shows the DTS parameters and ranges.

Table 4-4 DTS Parameters and Ranges

Parameter	Range
CIR	1 - 45 000 000
Min CIR	1000 - 45 000 000
Bc	300 - 16 000 000
Be	0 - 16 000 000

To configure DTS on Frame Relay Interface (7500):

1. Enable distributed Cisco Express Forwarding (dCEF) with the following command:

   router(config)#ip cef distributed
   

2. Ensure that the Frame Relay interface is enabled for distributed switching.

Before configuring DTS on frame relay interface(7500 series) through PHB FRTS, make sure that the following option elements are set as specified below for that device-ios combination:

<cartridge.cisco.qos.trafficShapingOnFRInterface>dts</cartridge.cisco.qos.trafficShapingOnFRInterface>

<cartridge.cisco.qos.interface.frtsCommand>false</cartridge.cisco.qos.interface.frtsCommand>

Note:

If the "cartridge.cisco.qos.interface.frtsCommand" is not set as false, the "frame-relay traffic-shaping" command will be configured at interface level causing the device to rollback.