Appendix A System Software Task and Subsystem Descriptions

Appendix A
System Software Task and Subsystem Descriptions
 
 
For redundancy, scalability and robust call processing, the system’s software is divided into a series of tasks that perform specific functions. These tasks communicate with each other as needed to share control and data signals. As a result, system processes can be distributed across multiple tasks thus reducing the overall work-load on any given task and improving system performance. In addition, this distributed design provides fault containment that greatly minimizes the impact to the number of processes or sessions due to a failure.
All tasks run in a Common Firmware Environment (CFE) that resides on specialized Central Processing Units (CPUs) on each of the application cards. The Packet Services Card (PSC) contains two CPUs (CPU 0 and 1, CPU 0 is the lead CPU). The CPUs on the PSC are responsible for session processing, and for running the various tasks and processes required to handle the mobile data call. In addition to the CPUs, PSCs each have a Network Processor Unit (NPU) for IP forwarding.
The following sections describe the primary tasks that are implemented by the system:
 
Primary Task Subsystems
The individual tasks that run on the CPUs are divided into subsystems. Following is a list of the primary subsystems responsible for call session processing:
 
 
System Initiation Task (SIT): This subsystem starts tasks and initializes the system. This includes starting a set of initial tasks at system startup time (static tasks), and starting individual tasks on demand at arbitrary times (dynamic tasks).
High Availability Task (HAT): With the Recovery Control Task (RCT) subsystem, the HAT subsystem maintains the operational state of the system. HAT monitors the various software and hardware components of the system. If there are unusual activities, such as the unexpected termination of another task, the HAT subsystem takes a suitable course of action, such as triggering an event to the RCT subsystem to take corrective action or to report the status. The end result is that there is minimal or no impact to the service.
Recovery Control Task (RCT): This subsystem executes a recovery action for any failure that occurs in the system. The RCT subsystem receives signals from the HAT subsystem (and in some cases from the NPU subsystem) and determines what recovery actions are needed.
The RCT subsystem runs on the active SMC and synchronizes the information it contains with the RCT subsystem on the standby SMC.
Shared Configuration Task (SCT): This subsystem provides a facility to set, retrieve, and receive notification of system configuration parameters. The SCT is mainly responsible for storing configuration data for the applications that run on the system.
The SCT subsystem runs only on the active SMC and synchronizes the information it contains with the SCT subsystem on the standby SMC.
Resource Management (RM): This subsystem assigns resources, such as CPU loading and memory, for every system task upon start-up. The RM subsystem monitors resource use to verify that allocations are as specified. RM also monitors all sessions and communicates with the Session Controller to enforce capacity licensing limits.
Virtual Private Network (VPN): This subsystem manages the administrative and operational aspects of all VPN-related entities in the system. The functions performed by the VPN subsystem include:
All IP operations within the system are done within specific VPN contexts. In general, packets are not forwarded across different VPN contexts. The only exception currently is the Session subsystem.
Network Processing Unit (NPU): This subsystem is responsible for the following:
Card/Slot/Port (CSP): Coordinates the events that occur when any card (application or line) is inserted, locked, unlocked, removed, shutdown, or migrated. SCP also performs auto-discovery and configures ports on a newly-inserted line card. It determines how line cards map to PSC/PSC2 cards (through a Redundancy Crossbar Card (RCC), if necessary).
The CSP subsystem runs only on the active SMC and synchronizes the information it contains with the SCT subsystem on the standby SMC. It is started by the SIT subsystem and monitored by the HAT subsystem.
Session: Performs high-touch processing of mobile subscribers’ packet-oriented data session flows. High-touch user data processing consists of the following:
Primary Subsystem Composition
Many of the primary subsystems are composed of critical tasks—controller tasks called Controllers, and subordinated tasks called Managers. Critical tasks are essential to the system’s ability to process calls, such as those in the SIT subsystem.
 
Controllers serve several purposes:
Managers manage resources and mappings between resources. In addition, some managers are directly responsible for call processing.
The following sections provide information about the composition of the primary subsystems that are composed of critical, controller, and /or manager tasks:
ASR 5000 Subsystems
The following tables describe managers and tasks performing within the specified subsystems on an ASR 5000.
Important: Variations regarding how the managers and tasks are distributed based on session recovery are included in the Card and CPU columns in some tables. Tables without these indicators are applicable to ASR 5000s with and without session recovery. The ASR 5000 dynamically distributes processes, tasks, and managers on startup. The following tables list the typical locations but variations can occur depending on available resources.
ASR 5000 System Initiation Subsystem
Important: SITPARENT replaces the sub-functions SITPAC, SITSPC and SITTAC.
ASR 5000 High Availability Subsystem
ASR 5000 Resource Manager (RM) Subsystem
ASR 5000 Virtual Private Networking (VPN) Subsystem
ASR 5000 Network Processing Unit (NPU) Subsystem
ASR 5000 Session Subsystem
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active PSC.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active PSC. The HNBMGRs should not be started on a PSC which has the HNB DEMUX MGR started.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active PSC.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active PSC.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active PSC.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active PSC.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active PSC but should not be created on the same PSC that has HNB Manager.
Important: For ASR 5000s with session recovery enabled, this manager is usually established on one of the CPUs on the 1st active PSC. The HNBMGRs should not be started on a PSC which has the HNB DEMUX MGR started.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active PSC.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active PSC. The IMSIMgr will not start on a PSC in which SessMgrs are started.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active deumux PSC. The IMSIMgr will not start on a PSC in which SessMgrs are already started.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active PSC.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active PSC.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active PSC but should not be created on the same PSC that has MME Manager.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active PSC. The MMEMGRs should not be started on a PSC which has the MME DEMUX MGR started.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active demux PSC. The IMSIMgr will not start on a PSC in which SessMgrs are already started.
Important: For ASR 5000s with session recovery enabled, this demux manager is usually established on one of the CPUs on the 1st active demux PSC. The IMSIMgr will not start on a PSC in which SessMgrs are already started.
ASR 5000 Platform Processes
ASR 5000 Management Processes
 
 
 

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883