Overview of Policy Management
The SRC software works with Juniper Networks routers and PacketCable Multimedia Specification (PCMM)-compliant cable modem termination system (CMTS) platforms to provide differentiated quality of service (QoS). The SRC software uses policies to define how the router or the CMTS device treats subscriber traffic. Policy management is responsible for defining policies and deploying the policies on a router or CMTS device.
Router Policy Features Supported
This section describes the features that the SRC policy management software supports on JUNOS routing platforms and on JUNOSe routers. For information about features supported on CMTS devices, see Delivering QoS Services in a Cable Environment.
JUNOS Routing Platform Features
The SRC software supports the following features on JUNOS routing platforms:
Allows you to provide differentiated services. You can assign forwarding classes to different applications, set a loss priority, define which packets are placed into each output queue, schedule the transmission service level for each queue, and manage congestion using a random early detection (RED) algorithm. You can also configure a shaping rate for interfaces.
For complete information about how this feature works on the router, see the JUNOS Network Interfaces and Class of Service Configuration Guide.
Allows you to control packets transiting the router to a network destination and packets destined for and sent by the router.
For complete information about how this feature works on the router, see the JUNOS Policy Framework Configuration Guide.
Enables you to limit the amount of traffic that passes into or out of an interface. Policing is designed to thwart denial-of-service (DoS) attacks. It applies two types of rate limits on the traffic:
- Bandwidth—Number of bits per second permitted, on average.
- Maximum burst size—Maximum size permitted for bursts of data that exceed the bandwidth limit.
For complete information about how this feature works on the router, see the JUNOS Policy Framework Configuration Guide.
Supports stateful firewall and network address translation (NAT) services:
- Stateful firewall—Type of firewall filter that considers state information derived from previous communications and other applications when evaluating traffic.
- NAT—Security procedure for concealing host addresses on a private network behind a pool of public addresses.
For complete information about how this feature works on the router, see the JUNOS Services Interfaces Configuration Guide.
Allows you to control traffic on the router by mirroring traffic with a preconfigured mirroring port and filtering with a specific policy.
For complete information about how this feature works on the router, see the JUNOS Policy Framework Configuration Guide.
JUNOSe Router Features
The SRC software supports the following policy management features on JUNOSe routers:
Allows the router to classify a packet on ingress and make a forwarding decision based on that classification, without performing the normal routing table processing.
Provides bandwidth management by enforcing line rates below the physical line rate of the port and setting limits on packet flows.
Marks packets in a packet flow so that the QoS application can provide traffic-class queuing.
Forwards packets in a packet flow.
Drops packets in a packet flow.
For complete information about how these features work on the router, see the JUNOSe Policy Management Configuration Guide.
For more information about using the SRC software to manage QoS services on JUNOSe routers, see SRC-PE Solutions Guide, Chapter 1, Managing Tiered and Premium Services with QoS on JUNOSe Routers with the SRC CLI.
Default Policies and Service Policies
The policy management feature provides two types of policies that make it possible for you to control when the policies are deployed; this feature provides dynamic deployment of policies. The two types of policies are:
- Default policies—Are attached to a router interface when the SAE begins to manage the interface, before subscribers activate services. Default policies define the subscriber's initial network access. Typically, they block access to value-added services, restrict a subscriber's bandwidth, or restrict network access altogether.
If you are using the captive portal in a PCMM environment, you do not need default policies.
- Service policies—Are attached to an interface when a subscriber activates a service; they take priority over the default policy. Service policies allow access to value-added services or provide higher bandwidth. (When you create a service policy, you assign a lower precedence number to the policy rule so that it is preferred over the default policy.)
Where you reference the policies determines whether it is a default policy or a service policy. Default policies are referenced in interface classification scripts. Service policies are referenced in value-added service definitions.
How Policies Are Installed on the Router
The policy engine in the SAE makes decisions about the deployment of policies on the router. When the SAE needs to install a policy on the router, it retrieves the policy data from the directory, processes the data, and sends the data to the router. The router uses the data to construct the policy, and then it applies the policy as instructed by the SAE.
Figure 9 gives an overview of how policies are installed on the router.
![]()
Installing Default Policies
When an interface comes up on the router, the SAE runs the interface classification script to determine whether it manages the interface. If the interface is managed—that is, controlled by—the SAE, the SAE sends the default policy referenced in the interface classification script to the router.
Installing and Removing Service Policies
When a subscriber activates a service (for example, video-gold), the portal application notifies the SAE to activate that service. The SAE obtains the policy data associated with the service and sends the data to the router. The router constructs and installs the appropriate policies.
When the subscriber deactivates the service, the portal application passes the request to the SAE, and the SAE notifies the router to remove the policies for the service.
Reloading Default Policies
The SAE reapplies default policies when:
When the SAE is triggered to reload default policies, it generates default policies for each interface that was previously reported as up. If the default policies have changed compared with the previously applied policies, the current default policies (if any) are removed and the new policies are applied.
NOTE: This behavior means that the SAE also must keep track of unmanaged interfaces to handle changes in the interface classification script.
Policy List Sharing
Policy list sharing is supported on JUNOS routing platforms and on JUNOSe routers that are managed using the COPS-PR router driver. Policy sharing allows the same policy list to be attached to multiple interfaces. Before the SAE modifies policies that are attached to an interface, installs policies on an interface, or removes policies from an interface, it checks whether the requested combination of policy rules already exists on the router.
- If the combination exists, the SAE changes the policy attachment of the interface to use the existing policy. Using an existing policy increases router performance because the router does not have to construct a new policy.
The router maintains policy counters when it changes policy attachments. To generate accounting data, the SAE reads the policy counters before it deactivates a policy.
- If the combination does not exist, the SAE sends the policy data to the router. The router either creates a new list (if the interface is not managed yet) or modifies the policy list currently attached to the interface.
If a policy list is no longer referenced by a session, the SAE removes it from the interface.
Network Perspective for Creating Policies
When you create a policy, you indicate where the policy is applied on the router. You can apply policies to the ingress (input) side of the interface, to the egress (output) side of the interface, to both the ingress and egress sides of the interface, or, in the case of JUNOS scheduler policy rules, you can attach the policy to the interface without indicating direction. Typically, policies are applied to subscriber-facing interfaces.
Figure 10 shows a sample network diagram with an enterprise network and a service provider network. Ingress traffic flows from the enterprise network to the service provider's network. Egress traffic flows from the service provider's network to the enterprise network.
![]()
Collecting Accounting Statistics
You can specify whether accounting data is collected for the actions specified in a policy rule. If you specify that accounting data is collected, the SAE begins collecting accounting information when a service that uses the policy rule is activated. When the service is deactivated, the SAE sends the accounting records to the RADIUS accounting server or to a plug-in.
When you specify multiple actions for accounting, the SAE adds the accounting data for individual actions together to obtain a summary accounting record for that interface direction.
Accounting is not available for all actions. For example, the NAT action does not provide accounting.