1 Applying a QoS or Access Control Policy

This chapter introduces the Oracle Communications IP Service Activator elements that can be used to define a QoS or security policy and highlights some of the issues you need to consider. The chapter:

Outlines IP Service Activator's rules, Per Hop Behavior (PHB) groups and driver scripts
Describes the policy roles that enable you to group sets of devices and interfaces and so apply policy on a group by group basis
Explains how to use policy roles in the policy elements you define
Describes IP Service Activator's policy inheritance model
Outlines the tasks involved in setting up a QoS or access control policy
Highlights some of the points you need to consider when setting up a QoS or security policy
Explains how to implement the QoS or access control policy and describes what happens when policy is propagated to the network
Describes IP Service Activator's concept of abstract and concrete policy elements and explains how they appear in the user interface

Overview

IP Service Activator provides the following basic building blocks for creating a QoS or access control policy:

Policy rules – there are three rule types, each with a distinct function:
- Classification rules enable you to mark traffic and optionally manage bandwidth
- Policing rules police the bandwidth used by a particular traffic type and, optionally, re-mark traffic
- Access rules implement security by permitting or denying traffic
PHB groups allow QoS mechanisms to be applied to interfaces. There are two types of PHB groups:
- Standard PHB groups – allow you to implement QoS mechanisms
- MQC PHB groups – allow you to implement Modular QoS CLI mechanisms developed by Cisco to simplify the configuration of QoS on all device types
Driver scripts – enable you to make minor configuration changes by directly configuring a device. Driver scripts function only on device driver technology.
Configuration policies – flexible way of expressing configuration models and extending IP Service Activator functionality within a policy framework. Configuration policies function only with network processor/cartridge technology.

These basic building blocks are collectively referred to as policy elements.

Figure 1-1 illustrates how and where you might apply rules and standard PHB groups.

IP Service Activator provides an easily maintainable method for applying policy through a policy inheritance model and the concept of roles. The inheritance model enables policy defined at a high level, such as the domain or network, to be inherited to lower level objects, such as devices and interfaces. Roles enable you to group devices and interfaces by, for example, customer and service package, and create policy targeted at that group. Policy can be directed towards specific groups of devices and interfaces.

Rules, PHB groups driver scripts, and configuration policies can be applied to any policy target – that is, a customer, VPN or site, or a network component such as a device or interface. The configuration associated with a policy element is inherited through the inheritance model and applied at the relevant devices, interfaces, sub-interfaces or VC endpoints.

Figure 1-1 Rules and Standard PHB Application

Description of "Figure 1-1 Rules and Standard PHB Application"

Note:

You can apply rules, configuration policies, and PHB groups to Domains but you cannot apply driver scripts at this level.

To support the definition of rules, a range of rule components can be defined and used within any number of policy rules. A number of these components can be created by loading a set of example policy files.

See "Setting Up Basic Policy Data" for more information about rule components. See "Importing Policy Files" for information on loading example policy files into IP Service Activator.

Standard PHB and Modular QoS CLI PHB Groups

Standard PHB groups provide a method for implementing a QoS policy mechanism for traffic queuing and/or shaping on the interfaces of specific device types. The QoS mechanism that you select is applied to all of the classes of service associated with the standard PHB group. You can apply other QoS policies to the same interfaces using policing and classification rules. The Class of Service (CoS) that is associated with a PHB group is defined by packet marking. See "Defining Standard Per Hop Behavior Groups" for more information about standard PHB groups.Modular QoS CLI (MQC) PHB groups use Cisco's simplified configuration of policy mechanisms and actions for traffic queuing, shaping, policing, congestion avoidance and re-marking on the interfaces of Cisco routers and switches. MQC PHB groups differ from standard PHB groups in a number of ways:

They provide a wider range of QoS mechanisms than standard PHB groups – for example, they can be used to police and classify traffic as well as applying a queuing mechanism.
Several different QoS mechanisms may be specified for each of the classes of service associated with an MQC PHB group.
The traffic class that an MQC PHB group applies to is defined by a classification or classification group, unlike standard PHB groups that apply to traffic characterized by a packet marking.

Note:

You can associate a CoS defined by a classification or classification group and/or a packet marking with an MQC PHB group but packet markings are ignored. If you wish to define a traffic class that is characterized by a packet marking, you must create a packet marking traffic type and associate it with a classification.

MQC PHB groups can be nested, enabling you to re-use an MQC PHB group that defines QoS actions for one or more classes of service in multiple 'parent' MQC PHB groups.

Note:

In many instances, policy rules and MQC PHB groups can be configured on the same interface. Note, however, that if a classification rule is configured on an interface using policy maps, you cannot configure an MQC PHB group on the same interface. For information on which mechanisms and options are used to configure classification rules, see the appropriate Cartridge or Device Driver guide.

See "Defining MQC PHB Groups" for more information about MQC PHB groups.

Figure 1-2 illustrates how and where you might apply MQC PHB groups.

Figure 1-2 MQC PHB Group Application

Description of "Figure 1-2 MQC PHB Group Application"

Policy Roles

Some policies apply throughout the network while other policies apply only at certain points. Roles enable you to group a set of policy targets – such as a set of devices or interfaces – and apply one or more policies and PHB groups to the policy target group. Roles can be assigned to network components at the device level and below and associated with policy elements. By applying roles to selected policy targets, rules and PHB groups, you define the policy that will be applied at specific points in the network.

IP Service Activator supports two types of roles:

System-defined roles: a set of system-defined roles automatically provided to classify devices and interfaces according to their function in a VPN
User-defined roles: roles created by users to support their own policy setup

You can use system-defined and user-defined roles in combination. For policy targets and policy elements, you can assign one system-defined role and/or any number of user-defined roles. For policy elements, you can assign one system-defined role and zero or one user-defined roles.

The number and type of roles you choose to create will depend on the network to be managed and the number of variables you need to control. As an example, you might create roles for each service package, customer and bandwidth connection that feature in the network.

For more information on defining roles and assigning them to policy targets, see IP Service Activator User's Guide.

Using Roles in Policy Elements

In order for a policy element to be applied to a policy target, it must have both a device and an interface role associated with it. This role combination specifies where the policy element will be applied. For example, by associating the Gateway device role and Access interface role with a PHB group, configuration is applied only at Access interfaces on Gateway devices.

Note:

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

Figure 1-3 illustrates the use of roles in PHB groups. Roles are used within two PHB groups – Prem_64K_PHB and core_WRED_PHB – to target policy at the appropriate interfaces, that is, those tagged with matching roles.

Figure 1-3 Using Roles in PHB Groups

This figure is described in the surrounding text.

For both device and interface roles, you can associate one system-defined role and zero or more user-defined roles with a policy element. If a policy element has only one device and/or interface role associated with it, its policy is applied to policy targets whose assigned roles include that role – that is, the policy target may have additional roles assigned to it. For example, if a policy element has the following roles associated with it:

Device role: Access
Interface role: 64K

configuration will be applied to interfaces tagged with roles named Core and 64K as well as those tagged with the 64K role only, provided the parent device's assigned roles include Access.

Where two or more device or interface roles are specified, the policy element is only applied to policy targets tagged with all of the specified roles. For example, if a policy element definition specifies the following:

Device roles: Access
Interface roles: Access, 64K

configuration will only be applied at interfaces tagged with the Access and 64K roles whose parent devices are tagged with the Access role. Configuration is not applied if the interface is tagged with only one of the specified roles.

Note:

The system-defined role Any Role can be specified within a policy element definition as the device and/or interface role. This role acts as a wildcard, effectively instructing IP Service Activator to ignore the device and/or interface role. However the device or interface must have at least one role in order for Any Role to match it.

In Figure 1-4, Any Role is specified as the device role. IP Service Activator therefore disregards the device role (as long as the device has a role) and applies the policy element wherever the interface roles match those in the policy element definition.

Figure 1-4 Any Role Example

This image is described in the surrounding text.

Policy Inheritance

IP Service Activator supports a policy inheritance model – QoS or access control policy applied to a policy target is automatically inherited by lower-level objects. For example, a rule that is applied to the network is inherited by the devices that make up that network. Note that devices and interfaces must be tagged with the appropriate role(s) for policy to be inherited.

There are two branches in the inheritance model:

Logical – includes domains, customers and VPNs
Physical – includes networks, devices and interfaces

The branches converge at device level. Figure 1-5 shows an example of inheritance.

Figure 1-5 Inheritance

Description of "Figure 1-5 Inheritance"

Where policy is defined at a low-level object, and would conflict with an inherited policy, the locally-defined policy takes precedence over the inherited policy. In the case of rules, locally-defined rules are evaluated before inherited rules. For PHB groups, only one PHB group can be applied to an interface. However, it is possible for a concrete standard PHB group configured with either Frame Relay traffic shaping or ATM traffic shaping to be installed on the same interface as a concrete MQC PHB group that is configured with other QoS mechanisms.

A locally-defined PHB group overrides a PHB group applied at a higher level. This means you can define broad high-level policies and refine or supplement those policies at lower points in the hierarchy.

Note:

Policy applied to a customer is inherited to a site, unless the site is a member of a VPN to which a policy element of the same type has been applied. In this case, the policy applied to the VPN overrides that applied to the customer. This is valid only for policies applied through MQC PHBs or Standard PHBs.

When you view the policy that applies to a policy target, IP Service Activator indicates whether it has been inherited from above or defined at the policy target. See "Checking Implemented Rules" and "Checking Implemented PHB Groups" for more information.

Before Implementing a QoS or Access Control Policy

A detailed analysis of the network to be managed and the requirements to be met are essential pre-requisites for implementing a QoS or access control policy.

This section outlines the tasks you need to perform and highlights the points you need to consider when setting up a QoS or access control policy. It assumes that a detailed analysis phase has been performed.

Set Up Basic Data

You need to make sure that you have set up all necessary CoS and rule component data before creating policy rules and PHB groups:

Set up classes of service to associate with PHB groups

A CoS may be defined by a packet marking and/or a classification or classification group.
Set up packet markings (for example, DiffServ codepoints, IP Precedence, MPLS experimental bits and MPLS Topmost experimental bits, Frame Relay DE bit, ATM CLP bit, Discard-class, Trust Types, COS, COS Inner).
Set up traffic types that identify the categories of traffic that you want to manage
Set up classifications and classification groups that classify existing traffic types by source and/or destination if required

Classifications and classification groups can be associated with policy rules and with the classes of service that you associate with MQC PHB groups.
Set up account groups that identify the source and destination points of the traffic to be managed. This is optional, as you can also identify source and destination points by IP address within a classification.
Set up date and time templates if relevant (for devices supported by device driver technology only)

See "Setting Up Basic Policy Data" for more information.

Check Capabilities

Before setting up policy rules and PHB groups, you need to know the capabilities of the interfaces to which you intend to apply policy. Check the Capabilities property page on the properties dialog box of relevant interfaces if necessary. See IP Service Activator User's Guide for information on retrieving capabilities.

Set Up and Assign Policy Roles

Policy roles can be associated with network components and with rules, PHB groups, driver scripts and configuration policies. By applying a role to a policy target you effectively specify which policy will be applied at that point. Before setting up rules and PHB groups, you should decide whether to use system and/or user-defined roles and decide which roles to apply to each policy target.

Note:

You must assign a role manually for each device. Do not use role assignment rules. For more information, see IP Service Activator User's Guide.

Assign Traffic to Appropriate Classes of Service

A CoS defines a class of traffic based on packet characteristics allowing traffic on the network to be identified. A CoS can be defined by one or more packet markings (coarse-grained) or by additional parameters such as source and/or destination IP address and traffic type (fine-grained). These additional parameters are defined by a classification or classification group.

Note:

Fine-grained and coarse-grained refer to component granularity. Smaller tasks requiring low latency (such as accessing specific client data) call for the use of fine-grained components in an application. Fine-grained components are used where smaller data packets are sent in short durations of time. Coarse-grained components have a wider reference and can be re-used in multiple contexts. Coarse-grained components are used where larger data packets are sent in longer time intervals.

A PHB group applies QoS mechanisms to classes of service that are associated with the PHB group. Therefore, before creating PHB groups you need to create suitable classes of service. Note the following:

A standard PHB group applies to a CoS characterized by a packet marking
An MQC PHB group applies to a CoS defined by a classification or classification group

If you associate a CoS that is associated with both a packet marking and a classification or classification group with a standard or MQC PHB group, each PHB group type ignores any irrelevant part of a CoS definition. For more information, see "Classes of Service".

Policy rules operate on traffic types, classifications or classification groups. If required, a policy rule can be associated with a class of service (CoS) by creating a policy rule that specifies either the same packet marking associated with the CoS or a classification or classification group that specifies a traffic type that has the same packet marking associated with the CoS. A CoS can have several packet markings and PHBs associated with it.

See "Setting Up Traffic Types" and "Setting Up a Classification" for more information.

Consider Where to Apply Policy Elements

Policy rules, PHB groups, driver scripts and configuration policies can be created at various levels in IP Service Activator and are automatically inherited so that they are applied to interfaces tagged with the appropriate role. For example, a rule created at domain level will apply throughout the domain (if the rule's matching criteria are met), while one created at device level will apply to that device's interfaces only (again, if the rule's matching criteria are met).

Organizing QoS Objects Into User-defined Folders

A number of QoS objects can be organized in the IP Service Activator GUI into folders and sub-folders:

PHBs and MQC PHBs
Classifications and classification groups
CoS
Roles

For example, PHBs and MQC PHBs are located under the PHB Groups folder in the Policy tab. To create a folder, right-click on the appropriate parent object under the PHB Groups folder, or the PHB Groups folder itself, and select Add Folder from the pop-up menu. To add a PHB or MQC PHB to an interface, simply drag and drop it.

User-defined folders for the other QoS objects are similarly created under their top-level system-defined folder in the Policy tab.

User-defined folders can contain sub-folders. Drag and drop operations can be used to move folders, or their contents. You can also define folder permissions to restrict access to a subset of users for these folders.

For more information on managing user-defined folders, refer to IP Service Activator User's Guide.

Marking on Cisco Routers

When using an MQC PHB group or a classification and/or a policing rule to implement a QoS policy on Cisco routers, you need to consider which marking mechanism to use.

The Cisco cartridge can mark packets in several different ways. Marking is applied either using Cisco route maps or by means of class maps and policy maps (Class-Based Marking) on devices that support MQC or Network–Based Application Recognition (NBAR). The ability to mark on an inbound or outbound interface depends on the Cisco device type. You should therefore check device capabilities before formulating policy rules. For information on checking device capabilities, see IP Service Activator User's Guide.

Alternatively, the cartridge can be configured to mark using the Committed Access Rate (CAR) mechanism, on either the inbound or the outbound interfaces. At present, CAR is implemented by means of a command-line parameter.

For detailed information, see IP Service Activator Cisco IOS Cartridge Guide.

QoS on Juniper M-series Routers

IP Service Activator supports access rules rate limiting and WRR on Juniper M-series devices. For detailed information, see IP Service Activator Juniper M-series Device Support Guide.