[Contents] [Prev] [Next] [Index] [Report an Error]

# 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 9 provides common terms used in the COPS environment.

Table 9: 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.

1. 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.
2. 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.
3. 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). The COPS-PR support in JUNOSe software uses a proprietary PIB. The proprietary PIB consists of a series of tables that is supported in previous JUNOSe software releases, including the proprietary accounting and address assignment mechanisms.

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

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

1. 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
   `
2. 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
   `
3. (Optional) Enable policy and QoS configuration support for IPv6 interfaces.
   `
   host1(config)#sscc protocol ipv6
   `
4. (Optional) Specify on which router the TCP/COPS connection is to be established.
   `
   host1(config)#sscc transportRouter chicago
   `
5. (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
   `
6. (Optional) Specify a fixed source interface for the TCP/COPS connection.
   `
   host1(config)#sscc sourceInterface atm 3/0
   `
7. (Optional) Specify the delay period during which the SRC client waits for a response from the SAE.
   `
   host1(config)#sscc retryTimer 120
   `

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 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

[Contents] [Prev] [Next] [Index] [Report an Error]