Deriving Congestion Points Automatically
SRC-ACP can derive some congestion points automatically. Depending on your network configuration and requirements, however, you may need to enter congestion points manually. This section describes the conditions and requirements for SRC-ACP to derive congestion points automatically.
Deriving Edge Congestion Points
For SRC-ACP to derive edge congestion points, subscribers must always connect through the same interface on the router. In addition, SRC-ACP requires one of the following conditions to derive edge congestion points if you are not using a congestion point profile:
- Access to subscriber profiles that define bandwidth values and a list of the distinguished names (DNs) of congestion points between the subscriber and the router.
- An ATM access network between the subscriber and the router for which all the traffic coming from one DSLAM travels on a single virtual path. In this case, SRC-ACP automatically derives three congestion points through the network access server (NAS) port ID. (For information about the NAS port ID, see SRC-PE Subscribers and Subscriptions Guide, Chapter 11, Configuring Accounting and Authentication Plug-Ins with the SRC CLI.) Table 17 shows the edge congestion points and the corresponding locations in the directory.
For more information about automatically deriving congestion points from a configured congestion point profile, see Deriving Congestion Points from a Profile.
SRC-ACP does not use bandwidth statistics from subscriber profiles when it derives congestion points, because the congestion points already use that data.
Deriving Congestion Points from a Profile
If you configure a congestion point profile, SRC-ACP can automatically derive congestion points for cases in which:
- There is no subscriber profile.
- The congestion points can be derived from information provided by the access interface on B-RAS. For example, in an ATM or VLAN connection, you can derive congestion points representing physical interfaces and intermediate switches based on the NAS port ID reported by B-RAS.
When SRC-ACP receives notification to start subscriber tracking and to load congestion points for a subscriber, it runs a congestion point classification and accesses the configured congestion point profile. Congestion point classification uses the same classification engine as subscriber and interface classification in the SAE.
For this feature to operate correctly, you create a congestion point profile that automatically performs congestion point classification. For more information about this topic, see Defining a Congestion Point Profile (using the SRC CLI) or Configuring SRC-ACP (using SRC configuration applications on Solaris platforms).
Deriving Backbone Congestion Points
SRC-ACP can automatically derive backbone congestion points if you specify the setting <-vrName->/<-serviceName-> for the congestion point associated with a service. When the SRC-ACP starts operating, it will substitute the name of the VR and the service name from the activation request.
For example, you can specify the setting <-vrName->/<-serviceName-> for the congestion point associated with a service called News. Then, when a subscriber who connects to the network through a VR called boston requests activation of this service, SRC-ACP receives the request and proceeds as follows:
- SRC-ACP reads the congestion point specification, <-vrName->/<-serviceName->, from the congestion point defined for the service News.
- SRC-ACP substitutes the actual information, boston/News, in the variables.
- SRC-ACP uses this information to generate the DN cn=News, cn=boston, o=CongestionPoints, o=umc.
- SRC-ACP uses this DN to obtain from the directory the network interface, which defines the location of the congestion point, for this DN.
For this feature to operate correctly, you must configure the DN for each combination of VR and service to point to an actual network interface. For more information about this topic, see Configuring SRC-ACP to Manage the Backbone Network.