Which queuing algorithm provides support for user-defined traffic classes?

This chapter explains the policy-based service activation components that can be used to create a service to users.

Oracle Communications IP Service Activator supports a variety of policy-based services for a range of devices from different vendors. For more information about the services supported for each device, refer to the Supported features tables in the respective support document, as indicated in .

Key Policy Configuration Concepts

IP Service Activator uses a policy-based approach to implement QoS, access control and selected measurement features. It is a flexible and powerful model, based on two key concepts:

• Policy elements: the definitions of the policies to be applied. Policy elements define what policies are configured.

• Policy targets: the points in the network at which the defined policies are applied. Policy targets define where policies are configured.

These two aspects of setting up a policy are described in the following sections.

About Policy Elements

In IP Service Activator, you can set up specific policy elements, which can then be applied to the relevant points in the network. A policy element can be one of the following:

• are used to classify traffic and define packet marking, policing requirements, and access control.

• (PHB groups) are used to provide low-level control of the queuing, policing, marking, congestion avoidance and traffic shaping mechanisms available on a particular interface.

• are used to define NetFlow or MIB-based measurement and to specify that NetFlow or SNMP MIB data is to be collected.

• are used to implement a specific policy requirement by means of a specially-written Python script. Driver scripts are discussed in detail in .

A configured policy can comprise a combination of these policy elements.

Policy Rules

One aim of policy-based network management is that high level policies can be defined by an organization's business requirements and the actual details of implementation – the conversion from a high-level request to the actual configuration of a network device – are hidden from users.

Although policy-based network management is commonly used to implement quality of service it can also be applied to resource allocation, security issues, measurement and other configuration requirements.

Policy rules can define one or more conditions and the actions associated with them, examples of which are shown in .

Table 5-2 Examples of Conditions and Actions for Policy Rules

Trading traffic is travelling between New York and Chicago.

Specify a bandwidth of 128k

Web-browsing traffic transiting the core.

Mark as low-priority and drop in times of congestion

Game-playing traffic detected.

Deny access to identified traffic between 9:00 and 5:00

Within IP Service Activator there are three types of rule:

• Classification rules are used to identify traffic and mark packets. They also apply bandwidth limits to defined traffic.

• Policing rules are used to identify traffic and set up policing parameters – the bandwidth requirements and the action to take for conforming and non-conforming traffic.

• Access rules are a security measure that can deny or explicitly permit identified traffic to access the network.

All rules identify and classify traffic in the same way. In addition all rules can be made dependent on date and time.

Per Hop Behavior Groups

A PHB group is a way of applying one or more policy definitions to a particular interface. There are two types of PHB group:

• Standard PHB groups are used to implement QoS mechanisms (queuing, congestion avoidance, policing and traffic shaping) on Cisco and Juniper devices. Although where possible these are generic, such as Weighted round Robin (WRR) the actual forwarding behavior is specific to particular device manufacturers and types.

• MQC PHB groups allow you to implement Modular QoS CLI mechanisms developed by Cisco to simplify the configuration of QoS on all device types.

SLA Measurement and Collector Parameters

Measurement parameters and collector parameters are used when configuring SLA monitoring. For more information, see .

Driver Scripts

A driver script is a Python program, specifically written to perform a particular configuration task. Scripts act like any other policy element within IP Service Activator. For more information, see .

About Policy Targets

A policy target is the point in the network at which a policy element is to be applied. Depending on the policy, this can be a device, an interface, a sub-interface or a PVC endpoint.

IP Service Activator's policy model is completely flexible: policy elements can be defined at any point in the system, but the policy targets at which they will be implemented depend on the use of policy roles and an inheritance model.

Policy Roles

Roles enable you to logically group devices and interfaces, for example by customer or service package, and set up policy specifically targeted at that group. A role is a way of grouping a set of policy targets so that they attract the same policy-based configuration.

As illustrated in , a role identifies the function of a configurable network object such as a device or an interface. These roles can then be linked to policy elements (such as rules, PHB groups or driver scripts) to define the policy configuration that is to be applied. Policy elements are only applied to network objects that have matching roles.

Each device and interface to be managed using IP Service Activator must have at least one allocated role which defines its function.

IP Service Activator includes a number of pre-defined device and interface roles that define how it works. Pre-defined roles are important because they ensure that VPN configuration is applied to the appropriate devices and interfaces.

The pre-defined roles support a DiffServ model, consisting of Access, Gateway, and Core devices:

• Access devices are routers on customer premises that provide access to the core Service Provider network. Access devices are equivalent to Customer Edge (CE) routers in MPLS terminology.

• Gateway devices are those on the edge of the core network that have a direct connection to the local or customer access device. Gateway devices are equivalent to Provider Edge (PE) routers.

• Core devices are those used for routing within the core Service Provider network. Core devices are equivalent to Provider (P) routers.

In addition, a Shadow device role is pre-defined; this is used when setting up Service Assurance Agent (SAA) measurements.

There are also four system-level interface roles:

• Access interfaces connect access and gateway routers

• Local interfaces are interfaces on access routers that connect to the customer's local LAN or hosts

• Core interfaces connect core and gateway routers or two core routers

• Disabled interfaces are not used.

These system-defined device and interface roles are illustrated in .

The system-defined roles allow you to set up a simple QoS policy based on DiffServ, but for a more complex policy, you can create any number of user-defined roles.

Types of interfaces or devices can be grouped together and given a specific role which can then be used to define the policy that is applied. The type of roles required depend on the policy to be applied. For example, roles could be based on interface capacity (64k, 128k, 1Gig), device function, customer or service package.

Inheritance

A process of inheritance means that a policy element that is to be implemented only needs to be applied at a single point in the network and will then automatically apply to all appropriate points. For example, a policy rule to mark packets can be applied to a network object and it will be implemented at all relevant interfaces with appropriate matching device and interface roles.

There are two branches in the inheritance model, illustrated in :

• Logical: includes domains, customers, sites and VPNs

• Physical: includes networks, devices and interfaces

Configuring QoS Policies

Quality of Service (QoS) can be defined as a set of specific measures, characteristics and properties that defines how well a network is performing, as experienced by particular traffic flows across the network. QoS can be measured in a number of ways:

• Delay or latency: how long it takes for a packet to get from source to destination.

• Jitter: the variation in latency between subsequent packets. This is particularly important for audio or video transmissions.

• Throughput: the average and peak transmission rates.

• Data loss: how often packets are dropped and have to be re-sent.

Class of Service (CoS) techniques implement QoS by categorizing network traffic into a small number of defined aggregate classes. This enables some identified network traffic to be treated better than the rest; for example by allocating it more bandwidth, ensuring faster handling, or guaranteeing a lower than average loss rate.

Implementing a QoS solution requires a number of techniques, as illustrated in :

• Identifying and classifying traffic to determine the QoS to be applied

• Marking the packets so that they can be recognized by nodes throughout the network

• Traffic shaping, to constrain specific outbound traffic to a particular bandwidth range

• Queuing techniques, to prioritize different traffic separately on outbound queues

• Policing traffic to ensure that traffic classes do not exceed their share of resources

IP Service Activator is also capable of setting the Diffserv Codepoints, IP Precedence or MPLS experimental bits where they are supported. Marking is implemented by means of classification rules.

Each classification rule defines a set of conditions and the actions that are taken if the conditions are true. The conditions can be any combination of the following:

• One or more classification types which identify the source, destination and type of traffic.

• Date and time – optionally, specifies the period of time that the rule applies.

Where these conditions are true, the identified traffic can be denied or permitted access (either inbound or outbound or both).

Which queuing method provides user defined traffic classes?

Which queuing algorithm is effective for large links that have little delay and minimal congestion?

Which queuing method should be used for voice traffic?

Which QoS model is the most widely used?