| Oracle® Communications IP Service Activator Concepts Release 7.2 E47715-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications IP Service Activator Concepts Release 7.2 E47715-01 |
|
|
PDF · Mobi · ePub |
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 Table 5-1.
| Vendor | Devices Supported by Device Driver | Devices Supported by Cartridge |
|---|---|---|
|
Juniper M |
Juniper M-series Device Support Guide |
Juniper JUNOS Cartridge Guide |
|
Cisco |
Not Applicable |
Cisco IOS Cartridge Guide |
|
Brocade |
Not Applicable |
Brocade IronWare Cartridge Guide |
|
Huawei |
Not Applicable |
Huawei Cartridge Guide |
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.
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:
Policy Rules are used to classify traffic and define packet marking, policing requirements, and access control.
Per Hop Behavior Groups (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.
SLA Measurement and Collector Parameters are used to define NetFlow or MIB-based measurement and to specify that NetFlow or SNMP MIB data is to be collected.
Driver Scripts are used to implement a specific policy requirement by means of a specially-written Python script. Driver scripts are discussed in detail in "Extending IP Service Activator".
A configured policy can comprise a combination of these policy elements.
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.
Table 5-2 Examples of Conditions and Actions for Policy Rules
| Condition | Action |
|---|---|
|
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.
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.
Measurement parameters and collector parameters are used when configuring SLA monitoring. For more information, see "SLA Monitoring".
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 "Extending IP Service Activator".
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.
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 Figure 5-1, 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.
Figure 5-1 Assigning Roles to Policy Targets and Elements
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 Figure 5-2.
Figure 5-2 System-defined Device and Interface Roles
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.
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 Figure 5-3:
Logical: includes domains, customers, sites and VPNs
Physical: includes networks, devices and interfaces
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 Figure 5-4:
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 for a particular packet, a set of actions is performed.
Routers need to identify and classify types of traffic that are to be allocated different QoS. For example, traffic can be identified by source or destination address or by source or destination port. For IP traffic, this requires the IP header to be examined. Ideally, traffic would be classified once only at the edge of the network, as some overhead is involved in checking the packet. Methods of classification depend on the capabilities of the router.IP Service Activator can classify traffic on any combination of:
Source address
Destination address
Type of traffic
The identified source and destination can be a specific IP address or a subnet.
The traffic type is generally identified by source or destination port number and IP protocol, since all network devices can classify traffic in this way.
For devices that can support other methods of classification, IP Service Activator also supports traffic identification and classification by the following:
Packet marking (such as IP Precedence settings or DiffServ codepoints)
DNS domain name
Application or sub-application for HTTP traffic, URL or MIME type
Traffic classifications are set up by means of traffic types, which can then be associated with the policy rule. A number of predefined traffic types identifying the most common TCP and UDP port numbers are included and additional ones can be set up as required.
Global classification categories can be set up, which identify a particular type of traffic, between a source and destination. Any number of these classification types can then be associated with a particular policy rule. Alternatively, the source, destination and traffic type can be defined specifically for each rule.
Identified traffic can be marked with a value to indicate the QoS/CoS that is to be applied to it. If CoS techniques are used, a small number of classes are defined, such as Gold, Silver and Bronze, with each one marked with a specific codepoint.
IP Service Activator supports the following standards for marking IP packets:
The RFC 2474 standard, ”Definition of Differentiated Services Field in the IPv4 and IPv6 Headers”, specifies that IPv4 packet headers include a DiffServ field, as illustrated in Figure 5-5.
The six DiffServ bits allow the definition of up to 64 different classes of service. However, the standards define a number of recognized codepoint settings and the corresponding packet forwarding treatment, known as a per-hop behavior.
RFC 791, which defines the format of IPv4 packet headers, specifies that IP packet headers should include a Type of Service byte, structured as illustrated in Figure 5-6.
The three-bit IP Precedence field is intended to indicate the importance or priority of the packet. It allows a set of eight values from 0 to 7 to be set, where 0 is the lowest priority and 7 is the highest. Values 6 and 7 are normally reserved for network control traffic, such as routing updates, leaving six values available for normal traffic.
The three bits of the Type of Service field are intended to be used as switches which can be used in combination to specify requirements for Delay, Throughput and Reliability respectively.
For MPLS traffic, a label is attached to each IP packet at the ingress router to the LSP. This label is used by routers when forwarding packets along the path, and the IP packet header is not examined at any point along the LSP. The three IP Precedence bits are copied from the IP header into the three bits within the MPLS label known as the experimental CoS bits.
The application that generates the IPv4 packet controls the original IP Precedence value. However, some devices are able to reset this value, which can be useful if a precedence is set for a packet at the edge of the network and a Service Provider wants to override this value while the packet transits the core.
Traffic shaping and queuing techniques are implemented by means of PHB groups. A PHB group is a way of applying one or more policy definitions to a particular interface. The actual forwarding behavior is controlled by the QoS mechanisms that control the queuing and dropping of packets on each router, and thus are specific to particular device manufacturers and types. However, IP Service Activator's detailed reporting of device and interface capabilities ensure that it is easy to find out what mechanisms are supported.The PHB group maps one or more defined classes of service on to the queuing and shaping mechanisms available at that interface.IP Service Activator supports the following queuing and traffic shaping mechanisms:
Priority Queuing
Weighted Round Robin (WRR)
Weighted Fair Queuing (WFQ)
Weighted Random Early Detection (WRED)
Rate Limiting
Frame Relay Traffic Shaping
ATM Traffic Shaping
Traffic shaping, or rate limiting, is a mechanism for controlling traffic on an interface by constraining specific outbound traffic to a particular bandwidth range, for example by specifying a particular maximum bandwidth or by defining burst parameters that the traffic cannot exceed.
Traffic shaping is often used to control access to the core network by constraining the outbound traffic. Traffic shaping does not in itself implement queuing, and in some cases can be used in conjunction with a queueing mechanism.
Generic Traffic Shaping (GTS) on Cisco routers is an example of rate limiting. Rate limiting is implemented in the form of a ”token bucket” mechanism. The average bit rate defines the rate at which tokens are placed into a bucket of fixed capacity. Each token permits a number of bits to be transmitted. To send a packet, an appropriate number of tokens must be removed from the bucket. If there are not enough tokens in the bucket to send a packet, the packet is queued (or dropped if the queue is full). Therefore, the largest burst that can be transmitted is proportional to the size of the bucket.
Throughout the network, QoS can be applied by the implementation of specific queuing mechanisms implemented at the various routers throughout the network.
These can be defined as congestion management techniques (applying a queuing algorithm to organize and prioritize the traffic), and congestion avoidance techniques (selectively dropping lower priority traffic to ensure that TCP slows down the rate of its transmission, in order to avoid congestion before it starts).
The way in which QoS mechanisms are implemented is specific to particular device types and models, and more detailed information can be obtained from the appropriate manufacturer. In some cases default settings can apply, and in others various parameters can be set.
Policing involves checking the traffic to ensure that the packets meet an agreed profile, for example an average and burst bit rate. Packets that are out of profile may be dropped or remarked to a lower class of service.
Policing is implemented by means of policing rules, which can be used to limit and optionally re-mark identified traffic. A rule defines the bandwidth and burst requirements for the identified traffic, and the action to be taken if traffic conforms to or exceeds the requirements.
Each policing 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
The following bandwidth requirements can be set:
Average rate permitted
Maximum burst rate permitted
Burst interval: the period of time over which the traffic is allowed to maintain its maximum burst rate
Policing actions can be defined for traffic that conforms to or exceeds its bandwidth allocation. Actions are:
Transmit: transmit packets as they are. This would be the normal course of action for conforming traffic.
Drop: drop packets immediately. You would normally only choose to drop packets where low priority traffic had exceeded its limitations.
Re-mark and Transmit: re-mark packets with a different packet marking and transmit. The packets may then be treated differently at subsequent routers.
Re-mark and Continue: re-mark traffic with a different codepoint and continue checking traffic against subsequent policing rules. This could be used when traffic exceeds bandwidth or burst rates. For example, if traffic marked as ”Gold” exceeds the agreed policing, it can be remarked to ”Silver”, and checked against subsequent rules; if this traffic then exceeds the ”Silver” policing it can be remarked to ”Bronze”
Modular QoS CLI (MQC) is Cisco's simplified configuration of policy mechanisms and actions for traffic queuing, shaping, policing, congestion avoidance and re-marking. It is supported on selected devices and IOS versions.
IP Service Activator supports MQC by means of a specific MQC PHB group, which can be used to define an entire QoS policy that may be used at various points in the network. For example, an MQC 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.
An MQC PHB group may be applied to one or more classes of service that are based on a classification or classification group. The classification may be defined by factors such as source and/or destination IP address or account and traffic type. A number of classes of service may be linked to an MQC PHB group and one or more different mechanisms applied to each one.
The following traffic management mechanisms can be implemented within an MQC PHB group and applied to traffic by class of service:
Low Latency Queuing (LLQ): assigns a traffic class to a strict priority queue with a guaranteed maximum bandwidth during congestion
Class-based Weighted Fair Queuing (CB-WFQ): assigns a traffic class to a queue with a priority based on a guaranteed minimum bandwidth during congestion
Class-based Policing (single-rate or two-rate): specifies and enforces conditions that define the maximum inbound and outbound bandwidth of a traffic class, packets that exceed the conditions can be dropped or re-marked
Class-based Shaping: specifies and constrains the maximum outbound bandwidth of a traffic class, outbound packets that exceed the conditions are delayed
Class-based Marking: marks packets to allocate a priority status or class
Congestion avoidance (Queue limit and/or WRED): defines how packets are discarded during congestion
You can specify the order in which packets are evaluated against each CoS's match criteria to ensure that packets have the correct mechanism applied to them.
You can also nest an MQC PHB group within another MQC PHB group. This enables you to apply a policy to a broad range of traffic (defined by the parent MQC PHB group) and another to a subset of that range (defined by the child MQC PHB group).
IP Service Activator's access control features enable Service Providers to block specific applications, protect sensitive data or prevent identified users from accessing certain services. As part of a comprehensive security policy, this can protect sites and users from malicious denial of service attacks, prevent access to services by unauthorized users and prevent data loss.
Like QoS services, access control is implemented by means of rule-based policies that can deny or explicitly permit identified traffic. Rules can be set up to apply at specific dates or times
Access rules (or filters) are used to provide network security. Identified traffic can be denied or permitted access to the network. Each access rule defines a set of conditions and the actions that are taken if the conditions are true.
The conditions can be any 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).
Figure 5-8 illustrates how access rules work.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
