Configuring the SRC Client

The JunosE Software has an embedded client that interacts with the Juniper Networks SRC software, enabling the SRC software to manage the router’s policy and QoS configuration.

The connection between the router and the SRC software uses the Common Open Policy Service (COPS) protocol and is fully compliant with the COPS usage for policy provisioning (COPS-PR) specification. The router’s SRC client functions as the COPS client, or policy enforcement point (PEP). The SRC software functions as the COPS server, or policy decision point (PDP).

Table 11 provides common terms used in the COPS environment.

Table 11: SRC Client and COPS Terminology

Term	Description
COPS	Common Open Policy Service; query-and-response protocol used to exchange policy information between a policy server and its clients.
COPS-PR	COPS usage for policy provisioning; the PEP requests policy provisioning when the operational state of interface and DHCP addresses changes.
PDP	Policy decision point; the COPS server. which makes policy decisions for itself and for clients that request decisions. The SRC software is the PDP.
PEP	Policy enforcement point; the COPS client, which enforces policy decisions. The JunosE COPS interface is a PEP.
PIB	Policy Information Base; a collection of sets of attributes that represent configuration information for a device.
SRC	Session and Resource Control (SRC) software, formerly the Service Deployment System (SDX) software; functions as a COPS PDP.

The JunosE Software COPS-PR implementation uses the outsourcing model that is described in RFC 3084. In this model, the PEP delegates responsibility to the PDP to make provisioning decisions on the PEP’s behalf.

Note: When you upgrade from an earlier JunosE release, the software removes the instance of SSCC that was configured with XDR.

If you are going to perform a unified ISSU from a JunosE release numbered lower than Release 10.0.0 and you have an XDR configuration, unified ISSU is not supported while an XDR configuration is presented.

The provisioning is event-driven and is based on policy requests rather than on an action taken by an administrator—the provisioning is initiated when the PDP receives external requests and PEP events. Provisioning can be performed in bulk (for example, an entire QoS configuration) or in smaller segments (for example, updating a marking filter). The following list shows the interaction between the PEP and the PDP during the COPS-PR operation.

Initial connection
1. PEP starts the COPS-PR connection with the PDP.
2. PDP requests synchronization.
3. PEP sends all currently provisioned policies to PDP.
Change of interface state
1. PEP requests provisioning of an interface from the PDP.
2. PDP determines policies and sends provisioning data to the PEP.
3. PEP provisions the policies.
PDP requests policy provisioning
1. PDP determines new policies and sends provisioning data to the PEP.
2. PEP provisions the policies.

The information exchange between the PDP and PEP consists of data that is modeled in Policy Information Bases (PIBs) and is encoded using the standard ASN.1 basic encoding rules (BERs).

JunosE Software uses the following PIBs:

Proprietary PIB

JunosE-IP-PIB—This PIB defines the data model for manipulating IP service policies and addresses offered through DHCP in JunosE Software.

Non-proprietary PIBs

COPS-PR-SPPI
COPS-PR-SPPI-TC
DIFFSERV-PIB
FRAMEWORK-FEEDBACK-PIB
FRAMEWORK-PIB
FRAMEWORK-TC-PIB

The COPS-PR support in JunosE Software uses the proprietary PIB. This PIB consists of a series of tables that is supported in previous JunosE Software releases, including the proprietary accounting and address assignment mechanisms.

You can force the router to restart a COPS connection to, and resynchronize with, a PDP, without disabling the SRC client’s COPS support. The SRC software and the SRC client maintain common state information in PIBs that both the SRC software and the SRC client use. Previously, you disabled the SRC client and reenabled it to start synchronization. The disabling of the SRC client’s COPS support was undesirable for the applications that required resynchronization in addition to maintaining the COPS support. If the state of the SRC software is not synchronized with the router, the SRC software may be required to initiate resynchronization from the router.

The proprietary PIB provides the Policy Manager and QoS Manager functionality shown in the following lists.

Policy Manager
- Committed access rate
- Packet filtering
- Policy routing
- QoS classification and marking
- Rate limiting
- Traffic class
QoS Manager
- Queues
- Schedulers
- Traffic classes

The JunosE-IP-PIB file is updated with each JunosE release. Since the PIB is implemented by both Juniper Networks SRC and JunosE devices, distribution of the PIB file to customers is not necessary. Customers can access the proprietary PIB file, on approval from Juniper Networks, through Juniper support.

You can configure SRC clients on a per-virtual-router basis. To configure the SRC client:

Enable the SRC client. With the CLI sscc enable command you can specify BER-encoded information exchange for COPS-PR.
host1(config)#sscc enable cops-pr
Specify the IP addresses of up to three service activation engines (SAEs) (primary, secondary, and tertiary). You can optionally specify the port on which the SAEs listen for activity.
host1(config)#sscc primary address host1(config)#sscc secondary address 192.168.12.1 port 3288
(Optional) Enable policy and QoS configuration support for IPv6 interfaces.
host1(config)#sscc protocol ipv6
(Optional) Enable policy and QoS configuration support for L2TP interfaces on an L2TP access concentrator (LAC).
host1(config)#sscc protocol lac
(Optional) Specify on which router the TCP/COPS connection is to be established.
host1(config)#sscc transportRouter chicago
(Optional) Specify a fixed source address for the TCP/COPS connection created for an SRC client session.
host1(config)#sscc sourceAddress 10.9.123.8
(Optional) Specify a fixed source interface for the TCP/COPS connection.
host1(config)#sscc sourceInterface atm 3/0
(Optional) Specify the delay period during which the SRC client waits for a response from the SAE.
host1(config)#sscc retryTimer 120
(Optional) Enable the user IP address mask to be sent to a Policy Decision Point (PDP) in place of the interface IP address mask for a virtual router.
host1(config)#sscc option user-ip-mask-override
(Optional) Enable the calling station ID to be sent to a PDP for a virtual router.
host1(config)#sscc option send-calling-station-id
(Optional) Enable the local QoS profile attachment information to be sent to a PDP for a virtual router.
host1(config)#sscc option send-local-qos-profile-config
(Optional) Enable the SRC client to obtain updated line rate parameters from ANCP and transmit them to the COPS server
host1(config)#sscc update-policy-request enable
(Optional) Restart a COPS connection to, and resynchronize with, a PDP.
host1#sscc restart

sscc address

Use to configure the SRC client with the IP addresses of the SAEs and the ports on which the SAEs listen for activity.
You can specify primary, secondary, and tertiary SAEs, and the port numbers on which each listens for activity. By default, the SAE listens on port 3288.
Example
host1(config)#sscc primary address 192.168.128.10 port 3288
Use the no version to remove a specific SAE (primary, secondary, or tertiary) from the list of SAEs.
See sscc address

sscc enable

Use to enable the SRC client’s COPS support in the router.
Use with the cops-pr keyword to enable COPS-PR support.
Example
host1(config)#sscc enable cops-pr
Use the no version to disable the feature.
See sscc enable

sscc protocol ipv6

Use to configure IPv6 support on the SRC client. IPv6 support enables policy and QoS configuration on IPv6 interfaces. The IPv6 support is in addition to the default IPv4 support.
Example
host1(config)#sscc protocol ipv6
Use the no version to disable IPv6 support on the SRC client.
See sscc protocol ipv6

sscc protocol lac

Use to configure support for L2TP LAC interfaces on the SRC client. LAC support enables policy and QoS configuration on L2TP interfaces.
When you configure LAC interfaces to be managed by the SRC client, the router generates COPS messages for every LAC interface created and removed from the router and sends them to the COPS server.
Such messages contain the necessary details about the newly created and removed LAC interfaces that enable the SRC software or the COPS server to determine the policy and QoS management for these interfaces
Observe the following guidelines when you configure the policy and QoS settings support for L2TP LAC interfaces:
- Access Node Control Protocol (ANCP), also known as Layer 2 Control (L2C) rate report, which contains the a QoS adjustment factor to be applied to the upstream data rate and downstream data rate reported by ANCP for a DSL type, for L2TP LAC interfaces is not supported.
- LAC interfaces that participate in L2TP tunnel switching are not supported for management of policy and QoS settings by the SRC client.
- L2TP dial-out sessions, in which VPNs that use B-RAS to dial out to remote offices that have only narrowband dial-up access, are not supported for policy and QoS management by the COPS client.
- L2TP network server (LNS) sessions are not supported for policy and QoS management by the COPS client because the interfaces configured on router, which functions as an LNS, are not reported as L2TP interfaces to the SRC software.
Example
host1(config)#sscc protocol lac
Use the no version to restore the default, which is to disable L2TP LAC support on the SRC client.
See sscc protocol lac

sscc restart

Use to force the router to restart a COPS connection to, and resynchronize with, the SRC software, without removing the SRC client. The no sscc enable cops command removes the SRC client.
When you issue this command, the SRC client closes the connection and connects again to the SRC software, which then requests complete synchronization. As part of the synchronization, the SRC client provides information about the policies that are already installed on the router to the SRC software.
To enable a complex restart where the SRC client closes the connection and clears the PIB structures and tables, use the optional clean-state keyword. Then, the SRC client connects to the SRC software, which requests full synchronization, which restores correct policies and QoS provisioning. Using this option consumes more time because the command enables the router to clear the existing PIB structures in addition to performing the synchronization.
Example
host1#sscc restart clean-state
There is no no version.
See sscc restart

sscc retryTimer

Use to specify the delay period (in the range 5–300 seconds) during which the SRC client waits for a response from the SAE.
If only a primary SAE is configured, the client resends the request to the primary SAE.
The client attempts to connect to a tertiary SAE only if both the primary and secondary SAEs are unavailable. For example, if the client is connected to the secondary SAE when the delay period expires, the client first tries to connect to the primary SAE before trying the tertiary SAE. The client waits for the length of the delay period before each attempt.
Example
host1(config)#sscc retryTimer 90
Use the no version to restore the default value, 90 seconds.
See sscc retryTimer

sscc sourceAddress

Use to specify a fixed source address for the TCP/COPS connection created for an SRC client session. This is the local address.
If you do not specify a source address, the TCP/COPS connection is not bound to a specific source (that is, local) address.
Example
host1(config)#sscc sourceAddress 10.9.123.8
Use the no version to remove the specified address.
See sscc sourceAddress

sscc sourceInterface

Use to specify a fixed source interface for the TCP/COPS connection created for an SRC client session. This is a local interface.
You may need to set a source interface in cases where a firewall, access control list, or policy configuration exists; and it is important to know what the interface is, or you need to set the interface independently from other protocols that have conflicting requirements.
If you do not specify a source interface, the TCP/COPS connection is not bound to a specific source (that is, local) interface.
Example
host1(config)#sscc sourceInterface atm 3/0
Use the no version to remove the source interface.
See sscc sourceInterface

sscc transportRouter

Use to specify on which router the TCP/COPS connection is to be established.
The router can be the same as or different from the router the SRC client session is created in and associated with.
If you do not specify the transport router for an SRC client session, the transport router defaults to the router associated with the session.
Example
host1(config)#sscc transportRouter chicago
Use the no version to remove the specified SRC client transport router.
See sscc transportRouter

sscc option

Use to send either the user IP address mask instead of the interface IP address mask , the calling station ID, or the local QoS profile attachment information to a Policy Decision Point (PDP).
Example
host1(config)#sscc option user-ip-mask-override
host1(config)#sscc option send-calling-station-id
host1(config)#sscc option send-local-qos-profile-config
Use the no version to remove the specified user-ip-mask-override ,send-calling-station-id, and send-local-qos-profile-config.
See sscc option

sscc update-policy-request enable

Use to enable updated DSL line rate parameters to be collected from ANCP and transmitted to the COPS server with the corresponding COPS messages.
The SRC client gathers line rate information from the access node and transfers it to the COPS sever, both during connection establishment between a subscriber and an access node, and when any of the values of the line rate parameters changes after the connection is built.
A COPS server that is running SRC software Release 3.0.0 and earlier releases does not support the receipt of updated DSL line rate information from the SRC client. If you configure the SRC client to send updated line rate parameters to the COPS server, regardless of the version of SRC software that it is running, the COPS server ignores the received updated line rate information and processes the other COPS details. Therefore, this feature of retrieval of updated line rate parameters from ANCP by the SRC client is backward compatible with older versions of SRC software.
When you enter the sscc update-policy-request enable command, a warning message is displayed, prompting you to confirm whether you want to enable the router that functions as the SRC client to forcibly send line rate information parameters to the COPS server, which is running a release of SRC software earlier than Release 3.0.0 that is not compatible with the line rate message format.
Example
host1(config)#sscc update-policy-request enable
Use the no version to restore the default behavior, which disables updated line rate parameters to be sent to the COPS server.
See sscc update-policy-request enable