|
|
Table Of Contents
Mapping Flow Attributes to Services
Traffic Accounting and Reporting
Other Traffic Processing Features
Traffic Forwarding to Value Added Services Servers
Defining Service Configurations in Practice
Traffic Processing Overview
This module describes how the Cisco Service Control Application for Broadband (SCA BB) installed on a Service Control Engine (SCE) platform processes traffic.
The module also defines the main elements (service configuration entities) of the SCA BB system and explains how they relate to each other.
•
Traffic Accounting and Reporting
•
Routing Environment
Traffic processing depends on the routing environment. The Cisco service control solution can operate in two typical routing schemes:
•
•
A flow is bidirectional when the inbound and outbound traffic of the flow pass through the same SCE platform. A unidirectional flow is one where only one of the inbound traffic and the outbound traffic go through the SCE platform.
The Cisco service control solution can handle both unidirectional and bidirectional flows. The SCE platform can be configured to operate in either a symmetric or an asymmetric routing environment. The traffic processing capabilities of the SCE platform in the asymmetric environment is a subset of its capabilities in the symmetric environment.
When the Cisco service control solution is deployed in an asymmetric routing environment, and asymmetric routing classification mode is enabled, the SCE platform classification is better tuned to identify traffic based on a single direction. The SCE platform handles unidirectional flows independently, with no synchronization with other SCE platforms that might handle the flows' opposite direction.
Traffic Processing
There are three stages of traffic processing:
•
•
•
These three stages are described in the following sections.
You control how classification, reporting, and control are performed by editing service configurations and applying them to the SCE platform.
Traffic Classification
Traffic processing starts with traffic classification , which categorizes network sessions into services.
For each commercial service that a provider offers to its subscribers, a corresponding service is defined in the Cisco Service Control solution. You can use this service to classify and identify the traffic, report on its usage, and control it.
•
•
•
•
Services
In the traffic classification process, SCA BB categorizes network sessions into services .
Services are the building blocks for:
•
•
From a provider's point of view, a service is a network product sold to a subscriber. The service is usually a network application—such as browsing, e-mail, file sharing, or voice—that the subscriber uses. From a technical point of view, a service consists of one or more service elements, each of which enables a decision about the service associated with a network traffic flow type.
A number of services are predefined in the default service configuration (these services are listed in the "Default Service Configuration Reference Tables" chapter of the Cisco Service Control Application for Broadband Reference Guide ). You can modify these services and add additional services to a service configuration.
A service configuration can contain up to 500 services.
The classification process occurs when a session starts. The process examines the first few packets of the session and decides to which service the session belongs. The session is then assigned a service ID that remains the same during the session's life cycle.
Traffic is classified and mapped to services on the basis of some or all of the following service elements:
•
•
•
Note
SCA BB uses these flow mappings to map each network connection passing through it to a service. You define rules for the different services to implement control policies. The classification rules can contain Layer 3 and Layer 4 parameters (such as port numbers and IP addresses), and also Layer 7 parameters (such as host name and user agent for HTTP connections).
Service Elements
A service consists of one or more service elements; different network traffic flow types are mapped to different service elements.
A service element maps a specific protocol, initiating side, zone, and flavor to the selected service. Some or all of these parameters can take wild-card values.
Note
A traffic flow is mapped to a specific service if it meets all four of the following criteria:
•
•
•
•
•
•
Examples of Services
The following table contains examples of services and their network parameters.
Protocols
One of the main classifications of a flow is the protocol of a session (that is, of the network application that generated the session).
A protocol, as defined in the SCA BB system, is a combination of one or more signatures, one or more port numbers, and a transport type. The protocol of the network flow is identified according to these parameters. For example, if the port number is 80, the transport type is TCP, and content matches the HTTP signature, SCA BB maps the flow to the HTTP protocol.
The default service configuration contains a long list of predefined protocols. You can add additional protocols.
When a TCP or UDP flow does not match a specific protocol definition, SCA BB maps the flow to the Generic TCP or Generic UDP protocol.
When a non-TCP/UDP flow does not match a specific protocol definition, SCA BB maps the flow to the Generic IP protocol.
When asymmetric routing classification mode is enabled protocol classification is performed in the normal way, with one exception: unidirectional UDP flows. In this case, SCA BB tries to classify the protocol using the destination port of the first packet; if no exact match is found, SCA BB tries to classify the protocol using the source port.
Protocol Elements
A protocol is a collection of protocol elements.
A protocol element maps a specific signature, IP protocol, and port range to the selected protocol. Some or all of these parameters can take wild-card values; port numbers can take range values.
A traffic flow is mapped to a specific protocol if it meets all three of the following criteria:
•
•
•
•
•
Signatures
SCA BB examines traffic flows using the SCE platform's deep-packet-inspection capabilities, and compares each flow with an installed set of protocol signatures to identify the network application that generated the flow.
SCA BB comes with a set of predefined signatures for common network applications and protocols, such as browsing, e-mail, file sharing, and VoIP.
When asymmetric routing classification mode is enabled and a unidirectional flow (inbound or outbound) passes through the SCE platform, the flow is matched against a special set of unidirectional protocol signatures. When a bidirectional flow passes through the SCE platform the protocol library tries to match it to one of its standard (bidirectional) protocol signatures.
Cisco periodically publishes protocol packs containing new signatures and updates to existing signatures. You can use these protocol packs to update the set of signatures installed on SCA BB, enhancing its classification capabilities.
Dynamic Signatures
Most signatures used by SCA BB are predefined and hard-coded. SCA BB also allows you to add dynamic signatures , which can be user-defined.
You can create and edit dynamic signatures in the Signature Editor tool. The Dynamic Signature Script (DSS) engine in SCA BB carries out the classification using these user-defined signatures in addition to the predefined signatures.
Initiating Side
The SCE platform is usually located between the provider's subscribers and the network. Subscriber-initiated flows are initiated by the subscriber toward the network; network-initiated flows are initiated from the network toward the subscriber.
You can limit some flow-types to one initiating side. For example, with HTTP you can restrict the direction of the flow to subscriber-initiated, because HTTP is always subscriber-initiated when the subscriber ventures outward to surf the Internet. If the direction of the HTTP flow is network-initiated, this probably means that a web server is open on the subscriber's local machine for receiving incoming HTTP traffic. The provider can block network-initiated HTTP.
Zones
A zone is a collection of network-side IP addresses.
You configure zones by arranging IP addresses in groups connected by a common purpose. A subscriber's network flow mapped to a service may be applied to a zone. In practice, zones often define geographical areas.
Zones are used to classify network sessions; each network session can be assigned to a service element based on its destination IP address.
Zone Items
A zone is a collection of related zone items.
A zone item is an IP address or a range of IP addresses.
EXAMPLES OF ZONES:
•
•
EXAMPLE OF ASSIGNING A ZONE TO A SESSION:
•
Flavors
Flavors are advanced classification elements that classify network sessions according to signature-specific Layer 7 properties.
Flavors provide an additional level of granularity in defining services in the Cisco Service Control solution. A protocol flavor uses an additional protocol attribute in classifying a service, making this service a flavor of the service based on the protocol only. For example, the user-agent attribute of the HTTP protocol could be added as a protocol flavor, enabling the definition of all HTTP traffic generated by the same browser type (indicated in the user-agent field) as one service.
Examples of flavor types are HTTP User Agent and SIP Source Domain.
Note
Flavor Items
A flavor is a collection of flavor items .
The type of a flavor item depends on the flavor type. For a list of available flavor types, see Flavor Types and Parameters.
The default service configuration includes some predefined flavors, such as HTTP Streaming Agents (a flavor of HTTP) and Vonage (a flavor of SIP).
Content Filtering
Content filtering involves classification and control of HTTP flows according to the requested URL. The classification of the URL is performed by accessing an external database.
Service providers require effective web filtering for their subscribers, for various purposes such as avoiding litigation and providing parental control. The problem is that the web is huge and constantly growing, and SCA BB and the SCE platform are not designed to track and maintain the huge database of URLs required for effective filtering.
SCA BB provides content filtering by integrating with SurfControl Content Portal Authority (CPA). SurfControl's technology enhances SCA BB URL classification capabilities by eliminating the need for a network administrator to manage a URL database or interact with the server, while creating a powerful filtering solution. It provides complete coverage of the web's most trafficked sites and access to the most accurate and relevantdatabase of URLs classified by risk category, such as sexually explicit, racist, hacker, and so forth.
The integration of SurfControl's CPA into SCA BB provides the required web-filtering solution. SCA BB, running on the SCE platform, contacts a CPA server to categorize the website that a subscriber requests. The returned category is then used to classify the HTTP flow. This classification is then used for the normal SCA BB traffic control and reporting.
Note
Mapping Flow Attributes to Services
The following figure illustrates the mappings of flow elements of a session to service elements of a service.
Figure 3-1 Mapping Flow Attributes to a Service
Traffic Accounting and Reporting
You can use data gathered by the SCE platforms for real-time signaling, billing, and reporting.
Various metrics are collected in different scopes—global (per entire link), per service (or group of services), per package (or group of packages), and per subscriber—based on user-defined usage counters.
•
•
The values from the usage counters can be either pushed or pulled:
•
•
Usage Accounting
SCA BB collects and maintains various network metrics, per service, in different scopes.
The network metrics are:
•
•
•
•
•
•
Note
Per service accounting takes place in the following scopes:
•
•
•
Several services may share the same service usage counter. For example, in the default service configuration, the SMTP service and the POP3 service share the E-Mail Counter. The assignment of services to usage counters is determined by the service hierarchy, as explained in the following section. Similarly, several packages may share the same package usage counter, and the assignment of packages to usage counters is determined by the The Package Hierarchy.
The Service Hierarchy
Services are arranged in a hierarchal tree. A single default service is at the root, and you can place each new service anywhere in the tree.
Services inherit the rule of their parents. When a rule is defined for a particular service (in a specific package), all its child services are controlled by the same rule for that package, unless explicitly specified.
Service Usage Counters
The service hierarchy provides a way to share usage counters and to organize services according to their semantics. Services are accounted in groups, as defined in the service hierarchy. Each service is assigned usage counters.
There are two categories of usage counters for services:
•
•
A global usage counter and a subscriber usage counter are assigned to each service. The use of a service can be accounted either exclusively for traffic classified to it or in conjunction with the traffic of its parent service. For example, if a service called Premium Video Content is defined as a child of Streaming, the operator can either define a special usage counter for Premium Video Content or configure it to use the same usage counter as Streaming. The global usage counter and the subscriber usage counter are independent; for the same service, one usage counter may be the same for parent and child, whereas the other is exclusive to the child.
The Package Hierarchy
Packages are arranged in a hierarchal tree. A single default package is the root of the tree, and you can place new packages anywhere in the tree.
Package Usage Counters
The package hierarchy allows you to organize packages according to their semantics and provides for sharing package usage counters. You can define a maximum of 1024 different exclusive package usage counters per service configuration, one of which is used for the Unknown Subscriber Traffic package.
Usage reporting at a package level is grouped as follows:
•
•
For example, in the example package tree shown in the following figure, if the Mail &Web Baseline package is allocated an exclusive counter, but neither child package is assigned an exclusive counter, then all Package Usage RDRs and derived reports (such as "Package Bandwidth per Service") would group together usage of subscribers assigned to all three packages.
On the other hand, if the Mail &Web Boost package also had an exclusive counter, the traffic for Main &Web Baseline and Mail &Web Captive HTTP would be accounted together, but traffic for Mail &Web Boost would be accounted separately. (In general this is not an efficient configuration. You should use the hierarchical structure to group packages that can share the same counter.)
Figure 3-2
Reporting
SCE platforms running SCA BB generate and transmit Raw Data Records (RDRs) that contain information relevant to the service provider.
RDRs are transmitted using a Cisco proprietary protocol. This requires you to use the Cisco Service Control Management Suite (SCMS) Collection Manager (CM) or to develop software to process the RDRs.
The data in some RDRs can also be exported using the NetFlow reporting protocol, which has become an industry standard. NetFlow reporting allows the SCA BB solution to be more easily integrated with your existing data collectors.
•
•
RDRs
The following are the main categories of RDRs:
•
–
–
–
–
•
•
•
•
NetFlow
The following information can be exported using the NetFlow protocol
•
•
Traffic Control
Traffic Control provides means to block, limit, or prioritize traffic flows according to service, subscriber package, subscriber quota state, and so on.
•
•
Packages
A package is a collection of rules describing subscriber policy. The package defines the group of services delivered to a specific group of subscribers and the system's behavior for each service. It may contain restrictions on network flows, guidelines for flows' prioritization, and instructions about how to report flows.
Each subscriber in the network is provided a reference to a package to which that subscriber belongs. The system:
1.
2.
3.
4.
Another scheme, Virtual Links mode, is described in the following section.
Virtual Links Mode
In normal mode, you define bandwidth controllers for each package (see Bandwidth Management. In Virtual Links mode, you define template bandwidth controllers. The actual bandwidth parameters are assigned to a subscriber when the subscriber enters the system. These parameters depend on the subscriber's package and the direction of the virtual link.
For more information, see Managing Virtual Links.
Unknown Subscriber Traffic
The SCE platform tries to identify the subscriber responsible for every traffic flow that it processes. The platform looks at the IP address or VLAN tag of the traffic flow, and checks its internal database for a subscriber identified by this IP Address or VLAN tag. If such a subscriber is not found in the database, the traffic flow is mapped to the Unknown Subscriber Traffic category.
Rules
A rule is a set of instructions that tell the SCE platform how to treat network flows of a specific service. A rule may:
•
•
•
Calendars
You can use calendars to divide the hours of the week into four time frames.
After you have configured a calendar, you can add Time-Based Rules to a package that uses the calendar.
Time-Based Rules
A time-based rule is a rule that applies to only one time frame. Time-based rules allow you to set rule parameters that will only apply at specific times. You might, for example, want to define different rules for peak, off-peak, nighttime, and weekend usage.
You can add time-based rules to any rule. If a time-based rule is not defined for a time frame, the parent rule is enforced.
Often, you will want the rules for the different time frames to be similar. When you add a time-based rule, the settings of the parent rule are copied to the new time-based rule; you can make any needed changes. Subsequent changes to the parent rule do not affect the time-based rule.
Bandwidth Management
The physical link bandwidth is an absolute limit on the bandwidth that can pass through the system. You can limit the total bandwidth passing through the SCE platform to a value lower than the physical link bandwidth. For example, if another device sitting next to the SCE platform on the IP stream has limited BW capacity, you can limit the bandwidth passing through the SCE platform to match the capacity of the other device.
Bandwidth control in SCA BB is accomplished in two stages:
•
•
•
•
Global Bandwidth Control
Total bandwidth use is controlled by global controllers. Global controllers are virtual queues in SCE platforms. You configure them for the entire system, rather than for individual subscribers.
Global controllers provide constraints for large, global volumes of traffic, such as "Total Gold Subscriber Traffic", or "Total P2P Traffic". Each global controller defines the maximum percentage of total available bandwidth allocated to all traffic of a particular type. Using a global controller, you can limit total traffic of services such as P2P in the system to any desired percentage of the total available bandwidth. In this way, you keep the total bandwidth consumed by this traffic under control.
The upstream and downstream interfaces are each assigned one default global controller that, by default, controls 100 percent of the link traffic. You can add up to 1023 more global controllers for each interface, and you can assign a maximum percentage of the total link limit to each global controller separately.
For each global controller, you can define separate values for the maximum percentage of total available bandwidth separately for each time frame. (See Calendars.)
In dual-link systems you can define different bandwidth values for each link. You can also set a limit on the aggregated bandwidth passing on the two links.
Virtual Links mode uses template global controllers . Template global controllers are templates of virtual queues, they are applied to as many separate physical links as exist in the system, in each case, actual bandwidth parameters depend on the link. ( For more information, see Managing Virtual Links.)
Subscriber Bandwidth Control
Bandwidth used by individual subscribers is controlled by Subscriber BW Controllers (BWCs). Each BWC controls available bandwidth for selected services. Services controlled by a particular BWC are defined per package, but bandwidth control is per service.
A BWC is specified by the following parameters:
•
•
•
•
The maximum available bandwidth (Admitted Information Rate (AIR)) ranges between the CIR and the PIR. The actual consumed bandwidth is always less than the AIR.
The BWC has a third parameter that controls how the AIR is determined at different congestion conditions. When the network is not congested the system allows the PIR and when the network is highly congested the system provides the CIR. In between these two extremes, the AIR is determined by a third parameter—Assurance Level (AL). The AL controls how fast the AIR would decrease from the PIR to the CIR as congestion builds, or increase from the CIR to the PIR as congestion decreases. A higher AL ensures a higher AIR compared to a similar BWC with a lower AL.
The BWC ensures that even when the network is congested (PIR-congestion) at least the CIR is granted. Similarly, the BWC ensures that even when there is little traffic associated with a BWC the PIR is not exceeded.
Figure 3-3 Bandwidth Control Levels
Bandwidth may be thought of in terms of a virtual pipe of adjustable width. The PIR is the maximum allowed width of the virtual pipe. The CIR is the minimum width to which the pipe can contract. The actual pipe width is the AIR. During network congestion, the system contracts each pipe differently to differentiate between subscribers and between their services.
Primary and Internal Bandwidth Control
In SCA BB each subscriber has an independent set of BWCs, consisting of a single Primary (Total) BWC (tBWC) that controls the total bandwidth available to the subscriber and several Internal BWCs (iBWCs) that control the available bandwidth of some services of that subscriber. For example, one BWC may control the Streaming Service; another may control the Download and E-mail Services together.
The PIR defines the maximum bandwidth for the associated services; the CIR defines the minimum bandwidth for them.
Figure 3-4 Bandwidth Control on Two Levels
You can link iBWCs to traffic in the following way:
1.
2.
Quota Management
You can assign subscribers a quota limit on selected services.
Each subscriber has 16 quota buckets, each of which you can define for volume or sessions. When a subscriber uses a certain service, the amount of consumed volume or number of sessions is subtracted from one of the buckets.
The service configuration determines which bucket to use for each service. Consumption of volume buckets is measured in units of L3 kilobytes. Consumption of session buckets is measured by the number of sessions. For example, you can define that the Browsing and E-Mail services consume quota from Bucket #1, that the P2P service consumes quota from Bucket #2, and that all other services are not bound to any particular bucket.
External quota provisioning systems can use the Quota Provisioning API (see the Cisco SCMS SCE Subscriber API Programmer's Guide ) to dynamically modify the quota in each bucket. For example, you can increase the quota of a certain bucket when a subscriber purchases additional quota. These external systems can also query the amount of remaining quota in each bucket. This can be used, for example, to show subscribers in a personal web page how much of their quota remains.
External quota provisioning can also be acquired using the Quota Manager (QM), an off-the-shelf solution provided by Cisco. For more information about the installation and operation of the QM, see the Cisco Service Control Management Suite Quota Manager Solution Guide .
Note
The internal SCA BB quota provisioning system replenishes each quota bucket by a fixed amount at fixed intervals.
Subscribers can be notified when they breach the quota in any bucket.
Subscriber Notification
The subscriber notification feature lets you push web-based messages (such as notifications of quota depletion) to a subscriber by redirecting the subscriber HTTP traffic to relevant web pages. HTTP redirection starts when the subscriber notification is activated and ceases when the notification is dismissed.
Note
Other Traffic Processing Features
•
Service Security
SCA BB includes service security functionality to help protect network operators and their subscribers from attacks and malicious traffic:
•
•
•
•
•
•
–
–
Although it is never possible to provide complete protection from network threats, the Cisco Service Control solution provides insight into malicious activity in a network, and can mitigate large scale eruptions of malicious activity that compromise overall network performance.
Networks operators can use SCA BB to:
•
•
•
Detecting Malicious Traffic
SCA BB uses three threat detection mechanisms:
•
Anomaly detection characteristics can indicate the following categories of malicious activity:
–
–
–
–
Note
–
•
•
Responding to Malicious Traffic
You can define the following actions when configuring the detection mechanisms described in the preceding section:
•
You can display graphs in the Console based on data collected for malicious activity analysis.
•
•
SCA BB provides a high level of flexibility in tuning the detection methods to define malicious activity and in configuring the actions to be taken when malicious activity is detected.
Traffic Filters
Filter rules are part of service configurations. They allow you to instruct the SCE platform to ignore some types of flow (based on the flow's Layer 3 and Layer 4 properties) and to transmit the flows unchanged.
When a traffic flow enters the SCE platform, the platform checks whether a filter rule applies to the flow. If a filter rule applies to this traffic flow, the SCE platform passes the traffic flow to its transmit queues without generating any RDRs (the flow will not appear in records generated for analysis purposes) and without enforcing any service configuration rules.
It is recommended that you add filter rules for OSS protocols (such as DHCP) and routing protocols (such as BGP) that might traverse the SCE platform These protocols usually should not be affected by policy enforcement, and their low volume makes them insignificant for reporting.
A number of filter rules are included in the default service configuration.
Flows of certain protocols can also be filtered according to the flow's Layer 7 characteristics.
Quick Forwarding
Quick forwarding is a flow filter rule action whose aim is to ensure low latency for delay sensitive flows. The packets of quick-forwarded flows are duplicated and sent through different paths: one copy goes directly to the transmit queue and thus suffers only a minimal delay, the other copy goes through the normal packet path. Since the SCA BB application handles quick-forwarded flows in an offline manner, those flows cannot be controlled.
Traffic Forwarding to Value Added Services Servers
Traffic forwarding to Value Added Services (VAS) servers allows the Cisco Service Control solution to use an external expert system (VAS server) for additional traffic processing. The SCE reroutes traffic to the preconfigured location of the VAS server. After processing, the traffic is sent back to the SCE, which then sends it to its original destination.
Note
Service Configurations
A service configuration implements and enforces the provider's business strategy and vision.
A service configuration can take effect only after it is propagated to the appropriate SCE platform. SCA BB enforces the service configuration by analyzing the network traffic passing through them.
A service configuration consists of:
•
•
•
•
Defining Service Configurations in Practice
In practice, defining service configurations is an iterative process.
It is recommended that you use the following sequence of steps:
1.
2.
3.
4.
5.
–
–
Posted: Wed May 30 12:20:04 PDT 2007
All contents are Copyright © 1992--2007 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
