SDX 6.4.x Application Library Guide > Providing Admission Control with ACP > Overview of ACP

Overview of ACP

ACP is an external plug-in for the SAE. ACP authorizes and tracks subscribers' use of network resources associated with services that the SDX software manages. Service providers can implement ACP configurations for both residential and enterprise subscribers. Consequently, both JUNOSe routers and JUNOS routing platforms are compatible with 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 SDX software associates with each JUNOS routing platform (see SDX Network Guide: SAE, Juniper Networks Routers, and NIC, Chapter 3, Using JUNOSe Routers in the SDX Network or SDX Network Guide: SAE, Juniper Networks Routers, and NIC, Chapter 4, Using JUNOS Routing Platforms in the SDX Network.)

ACP operates in two separate regions of the SDX network: the edge network and 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.

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

Figure 19 shows a typical network topology.

Figure 19: Position of ACP in Network

In the edge network, 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, 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 ACP. 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 ACP, see API for ACP. 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, ACP can also execute applications defined in the action congestion point. For information about defining applications in congestion points, see Configuring Action Congestion Points. Some applications require real-time congestion point status. If 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.

Deriving Congestion Points Automatically

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 ACP to derive congestion points automatically.

Deriving Edge Congestion Points

For ACP to derive edge congestion points, subscribers must always connect through the same interface on the router. In addition, 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, ACP automatically derives three congestion points through the network access server (NAS) port ID. (For information about the NAS port ID, see SDX Subscribers and Subscriptions Guide, Chapter 7, Configuring Authorization and Accounting Plug-Ins.) Table 22 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.

ACP does not use bandwidth statistics from subscriber profiles when it derives congestion points, because the congestion points already use that data.

 Table 22:  Congestion Points Derived Through NAS Port ID 

 Congestion Points
 Location of Object in Directory

 Physical interface 
on router

 interfaceName=ATM<slot>/<port>, orderedCimKeys=<routerName>, o=AdmissionControl, o=umc
 <slot>—Number of port on router
 <port>—Number of port on router
 <routerName>—Hostname configured for router


 ATM virtual path

 interfaceName=ATM<slot>/<port>:<vpi> orderedCimKeys=<routerName>, o=AdmissionControl, o=umc
 <vpi>—Number of virtual path on router


 ATM virtual connection

 interfaceName=ATM<slot>/<port>:<vpi>.<vci> orderedCimKeys=<routerName>, o=AdmissionControl, o=umc
 <vci>—Number of virtual connection on router



 

Deriving Congestion Points from a Profile

If you configure a congestion point profile, 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 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.

Deriving Backbone Congestion Points

ACP can automatically derive backbone congestion points if you specify the setting <-vrName->/<-serviceName-> for the congestion point associated with a service. When the 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, ACP receives the request and proceeds as follows:

1. ACP reads the congestion point specification, <-vrName->/<-serviceName->, from the congestion point defined for the service News.
2. ACP substitutes the actual information, boston/News, in the variables.
3. ACP uses this information to generate the DN cn=News, cn=boston, o=CongestionPoints, o=umc.
4. 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 ACP to Manage the Backbone Network.

Allocating Bandwidth to Applications Not Controlled by ACP

If you control the bandwidth of some applications by means of ACP, you can accommodate the applications that are not controlled by ACP by assigning background bandwidths for the edge congestion points. The background bandwidth is the total bandwidth allocated to the applications for which bandwidth is not controlled by ACP.

Because the total background bandwidth is unlikely to be used at a particular time, you can also specify a tuning factor that provides an estimation of the fraction of the background bandwidth that will be used. You can configure multiple values for the background bandwidth with corresponding tuning factors.

Use of Multiple ACPs

An ACP can support one or more SAEs. Similarly, multiple ACPs can support one SAE; for example, if an SAE is managing multiple VRs, you may have an ACP for each VR. However, only one ACP can manage a particular congestion point.

Interactions Between ACP and Other Components

This section describes how ACP interacts with other components to track data.

1. (Edge and dual mode only) When a subscriber connects to the router, ACP loads the subscriber profile from the directory. If the subscriber profile contains provisioned and actual traffic rates for the subscriber's interface and the set of congestion points between the subscriber and the router, ACP caches the information while the subscriber is connected to the router. ACP automatically updates the subscriber's actual upstream and downstream rates if the subscriber profile changes in the directory.
2. (Backbone mode only) When a subscriber activates a service, ACP loads the network interfaces defined in the service and caches the information.
3. (Optional) ACP obtains through its remote CORBA interface data from external applications about subscribers and congestion points. If a congestion point is unavailable, ACP denies service activation requests on the associated network interface until the interface is available again.
4. If ACP does not receive data from an external application, ACP loads data about congestion points from the directory. For each congestion point the following data is retrieved:

• Provisioned bandwidth
• Background bandwidths (if used for edge congestion points)

ACP caches this information and automatically updates the cache when the information changes in the directory.

5. (Edge and dual modes) If ACP does not receive data from an external application, ACP loads a subscriber's provisioned or actual bandwidth from the subscriber profile. If the actual bandwidth is available, ACP ignores the provisioned bandwidth.

ACP caches this information and automatically updates the cache when the information changes in the directory.

6. (Backbone and dual modes only) Using a hosted plug-in, the SAE monitors the states of router interfaces associated with backbone congestion points. The SAE sends relevant data to ACP through the ACP's remote interface.
7. When the subscriber requests activation of a service subscription (either through the SAE core API or automatically for activate-on-login services), the SAE notifies ACP to authorize and track the service usage.

1. The SAE sends the requested bandwidth to ACP.
2. For each congestion point, ACP checks whether:

(current bw + requested bw) > [provisioned bw - (background bw x tuning factor)] 

If the desired bandwidth exceeds the allocated bandwidth, ACP denies service activation.

ACP distinguishes between bandwidth exceeded on the subscriber interface (first congestion point) and bandwidth exceeded on a network interface by sending two different messages back to the SAE. In the first case, the subscriber may resolve the bandwidth problem by deactivating another service.

8. ACP authorizes or denies service activation.

• If ACP authorizes the service activation, the SAE activates the service and sends a tracking event to ACP. ACP updates the current bandwidth for all congestion points with the requested bandwidth.

Because authorization and tracking are independent events, ACP can authorize additional services even if the subscriber exceeds the bandwidth. The administrator can configure ACP to deal with this situation as follows:

• Ignore overallocation.
• Check allocated bandwidth after service has been activated. If the bandwidth exceeds the configured limit, the service is immediately deactivated.

• If ACP does not authorize the service activation, the SAE delivers a message detailing the reason to the originator of the activation request.

9. When a service is deactivated (either through the SAE core API or because a session times out), ACP updates the current bandwidth for all congestion points by removing the original requested bandwidth.
10. ACP stores all information about subscribers, services, and congestion points in a set of files.

ACP continually adds data to these files, but does not delete old data. Consequently, the sizes of the files continue to increase. ACP does, however, reorganize the files when the sum of their sizes increments by a specified value. Reorganizing the files reduces their sizes. You can also reorganize the files by using the ACP Web application (see Reorganizing the File That Contains ACP Data.)

Redundancy

You can configure ACP redundancy for a region of the network by installing ACP on two different hosts, installing a naming service application on the SAE, and connecting both ACP hosts to the SAE (see Figure 19). One ACP acts as the primary application, and the other as the secondary application.

NOTE: Both ACPs in a redundant pair must operate in the same mode. You cannot configure an ACP in edge mode and an ACP in backbone mode as a redundant pair.

The primary and secondary ACPs communicate with each other through a CORBA interface. When you start each ACP (see Starting ACP), it will register its redundancy CORBA interface with the naming service application, and import the interface for the other ACP from the naming service application.

Each ACP continuously monitors the other's availability. The primary ACP receives data from the SAE and sends any changes to the secondary ACP. If the secondary ACP is unavailable, the primary ACP caches the data to send when the secondary ACP becomes available.

If the primary ACP becomes unavailable, the secondary ACP immediately notifies the naming service application and assumes the primary role. If the former primary ACP recovers very quickly, it will again assume the primary role. However, if the former primary ACP recovers more slowly, it will assume the primary role only if the former secondary ACP becomes unavailable.

Fault Recovery

If the SAE cannot reach ACP, the SAE will deny all service activation requests. As soon as it reaches ACP, the SAE again sends authorization requests to ACP.

ACP keeps the state of the congestion points in persistent storage, and if ACP becomes unavailable, the service authorization can continue in the correct state. Because service activation requests are automatically denied when the SAE cannot reach ACP, ACP does not miss any active service sessions. The SAE will resend all service deactivation requests after ACP is reachable again.

ACP monitors SAE synchronization events for information about VR availability and SAE availability. If a VR reboots or an SAE becomes unavailable, ACP updates the states of congestion points associated with those devices accordingly.

If the SAE becomes unavailable, the router will automatically reestablish connection to either the redundant SAE or, if a redundant SAE is not available, to the original SAE when it again becomes available. The new SAE notifies ACP that the original SAE failed and specifies which subscriber and service sessions were logged during this time. ACP uses this information to update its state.

State Synchronization

You can configure ACP to synchronize states with the SAE.

If state synchronization is enabled, the current state can be transferred when ACP has started up or lost its state. ACP does not have to keep a local and persistent copy of the state. However, ACP requires additional bandwidth to transfer state information that can affect performance.

Both ACP redundancy and state synchronization can be enabled at the same time. In this situation, the primary and secondary ACPs are set up as a community and will communicate with each other to determine the primary ACP. The primary ACP registers its interoperable object reference (IOR) with the SAE so that the SAE will communicate only with the primary ACP. When the primary ACP becomes unavailable, the secondary ACP assumes the role of the primary ACP and performs state synchronization if necessary.