Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

SRC ACP Overview

SRC ACP is an external plug-in for the SAE. SRC ACP authorizes and tracks subscribers’ use of network resources associated with services that the SRC software manages. Service providers can implement SRC ACP configurations for both residential and enterprise subscribers. Consequently, both JunosE routers and devices running Junos OS are compatible with SRC ACP. References to virtual routers (VRs) in this documentation refer to an actual VR on a JunosE router or the single VR called default that the SRC software associates with each device running Junos OS.

SRC ACP operates in two separate regions of the SRC network: the backbone network. The edge network is the layer 2 access network through which subscribers connect to the router. The backbone network is the region between the router and the service provider’s network. edge network and the

Congestion often occurs in the network at points where connections are aggregated. SRC ACP monitors congestion points at interfaces between devices in the edge network. In the backbone network, SRC ACP monitors one congestion point, a point-to-point label-switched path (LSP) between the router and the service provider’s network.

Figure 61 shows a typical network topology.

Figure 61: Position of SRC ACP in Network

Position of SRC ACP in Network

In the edge network, SRC ACP performs the following procedures to determine whether there are sufficient resources to activate a service:

  • Tracks active services for each subscriber and the guaranteed traffic rate (bandwidth) at the congestion points associated with a subscriber.
  • Tracks the rate of traffic between the subscriber and the network (upstream bandwidth) and the rate of traffic between the network and subscriber (downstream bandwidth).
  • Monitors new requests for activation of services.
  • Compares the resources required for the new services with the resources available for the subscriber and the congestion points.
  • Activates the service if sufficient resources are available, and prevents activation of the service if sufficient resources are not available.

In the backbone network, SRC ACP performs the following procedures to determine whether there are sufficient resources to activate a service:

  • Tracks the guaranteed traffic rate for a service at the congestion point.
  • Tracks the actual traffic rate for the service at the congestion point.
  • Monitors new requests for activation of services.
  • Compares the resources required for the new services with the resources available at the congestion point.
  • Activates the service if sufficient resources are available, and prevents activation of the service if sufficient resources are not available.

Typically, network administrators use their own network management applications and external applications to provide data for SRC ACP. SRC ACP first obtains updates from external applications through its remote CORBA interface, and then obtains updates from the directory by means of LDAP. For information about developing external applications that send data to SRC ACP, see Creating an Application to Update Information for SRC ACP. SRC ACP does not interact directly with the network to assess the capacity of a congestion point or actual use of network resources.

In the backbone network, SRC ACP can also execute applications defined in the action congestion point. Some applications require real-time congestion point status. If SRC ACP must provide real-time congestion point status to the application, state synchronization must be enabled to handle interface tracking events so that the congestion points are updated properly.

Best Practice: Be careful with service sessions that require asymmetrical bandwidth—for example, more downstream bandwidth than upstream bandwidth—especially when dealing with backbone congestion points. The upstream and downstream bandwidth required by a service session always consumes the available upstream and downstream bandwidth defined in the congestion point. However, what is upstream in one part of the network may be considered downstream in another part of the network.

When the SRC ACP's congestion point classification script maps from a session authorization start or stop event to a set of congestion points, it cannot indicate whether the upstream bandwidth required by the service session maps to the upstream or downstream available bandwidth defined in the congestion point. For asymmetrical service sessions, we recommend that you define action congestion points that contain the logic required to implement this mapping.

Related Documentation

Modified: 2017-08-03