|
|
State management plays a key role in monitoring system resource status, managing service turn-up, and deleting resources. This chapter provides detailed information about the various Cisco 6100 states, their meanings, and their impact on system operation.
The following states will be supported by the 6100 and by ViewRunner for Windows:
Of these states, Administrative, Operational, and Usage states are International Standards Organization (ISO) compliant. The remaining states are Cisco 6100-specific states.
The Administrative state is an operator-defined state. All other states are system provided either through auto-discovery or through ViewRunner for Windows polling of the Cisco 6100 event log or Cisco 6100 SNMP Agent data elements.
To access the state of a particular entity in ViewRunner for Windows, place your cursor over the particular module in the Cisco 6100 Chassis View and click the right mouse button. States are readily viewable under each module's Status tab. Use each module's Configuration tab to manage the Administrative state.
The values of each state displayed within ViewRunner for Windows are a function of the most recent Cisco 6100 SNMP Agent poll of the Cisco 6100 event log. These states presented on a dialog are retrieved from the Cisco 6100 whenever a dialog is opened and whenever a Status tab is selected. Therefore, it is important to manage service affecting changes with the Refresh button, provided on many of the user interface dialogs. The Refresh button retrieves the latest available values for the fields in the opened dialog, enabling you to make change decisions on more real time data.
With ViewRunner for Windows, you can display the states of a particular module or port. Modules include ATU-C, line interface module (LIM), system controller (SC), network interface (NI), and LIM controller, and in the case of subtended Cisco 6100s, the subtend NI. The status dialogs are similar for both modules and ports. The dialogs contain:
The Status tab on a module properties dialog displays state information about that specific module. Figure 5-1 is representative of the display of states on module Status tabs for all the modules in the user interface. See "System Operation and Performance (DOH)," for information about status displays for particular modules of the Cisco 6100.
The Administrative and Operational states are indented under the Service State Details field. If one or more of these states takes on a "negative" state relative to its ability to provide service, the Service State field will transition from In Service to Out of Service. For example, if the Administrative state is changed from Unlocked to Locked, the Service State field changes from In Service to Out of Service.
Press the Configuration tab to display additional fields. These include Inventory Details and ATU-C (or LIM) Connect on Demand, and the Administrative State --- which allows the user to lock or unlock the particular module.
The Status tab on a port displays state information about a specific port. Figure 5-2 is representative of the display of states on module Status tabs for all the modules in the user interface. See "System Operation and Performance (DOH)," for information about status displays for particular ports on the Cisco 6100.
When the Usage State field is Busy, you can click on the LIM Properties... button to get information on the LIM that corresponds to this ATU-C port. When the ATU-C Port field is Trained, the window also displays port information such as upstream and downstream rate.
Click on the Configuration tab to display the Administrative state of the port (which allows the user to lock or unlock the particular port) or to edit a physical or logical pool.
To fully understand states and their impact on system operations, some background in terminology is helpful. Key terminology includes entities and the containment hierarchy.
Figure 5-3 illustrates the specific containment hierarchy model to propagate state changes between various entities.
Within the containment hierarchy, superior entities contain subordinate entities. As shown in the preceding containment diagram, chassis are superior to slots; slots are superior to modules; and modules are superior to ports.
Note that some entities may be both superior and subordinate. For example, a module is a superior entity to its ports, and a subordinate entity to its chassis.
Supporting/subordinate resource relationships are also important when managing resource deletions. See "Adding and Deleting System Components," for more information on deleting entities.
Cisco 6100 states are detected by means of a polling algorithm. Thus, ViewRunner retrieves state information from the Cisco 6100 when dialogs are opened. The information displayed by ViewRunner for Windows is provided in near real-time. ViewRunner for Windows provides a Refresh button in each status dialog allowing you to refresh the current state information.
The data is not real-time. Please use caution when changing resource states. For example, if a particular modem's Usage state is Idle, you might press the Refresh button and begin the process of removing that modem from the pool. This action might disconnect a subscriber who accessed that modem just after your refresh action.
The Usage state indicates whether or not the module is currently involved in an active ADSL connection. For an ADSL connection to be active, a modem must either be Trained or Training. For Digital Off-Hook (DOH) configurations, the Busy state also indicates that an analog cross-connect exists between an ATU-C modem from the modem pool and a LIM port. Table 5-1 shows each Usage state that may appear on the Status window.
| Screen Display | Description |
|---|---|
Busy | Entity is 100% in use. Normally associated with ports. For a module to be Busy, all of its subordinate ports must be busy. |
Idle | Entity is not in use. |
Active | Indicates the entity is in use, but has more capacity. For example, a module is Active when one but not all of its subordinate ports are busy. The active state provides a quick check to see if any of its subordinate resources are in use. Active states apply to modules, logical pools, chassis, and nodes. |
The Slot state identifies whether a module has been detected by the Cisco 6100 as present and whether a configuration or managed object representation exists for it in the node. When a module is detected, a managed object is automatically generated. Table 5-2 describes Slot states.
| Screen Display | Description |
|---|---|
Empty Unprovisioned | Neither a module nor a module managed object exists. Entity managed object is not supported in this release. |
Empty Provisioned | A module managed object exists, but the system has not detected the presence of the module since power up or since the previous deletion of the managed module configured (for that slot). This state is not supported in this release. |
Filled Invalid | The module detected is invalid for the slot. |
Filled Mismatch | This state indicates the module detected does not match the managed object module type configured for the slot. |
Filled Valid | A module managed object exists and the module type is present. For slots in the LCC1, a LIM controller module must be equipped in the LCC and be communicating with a previously detected MC. For slots in the MC, an SC module must be equipped in the MC. |
| 1line concentration chassis |
In addition to the Slot state value, ViewRunner for Windows also displays the type of module that has been auto-discovered just below the Slot state field. For ATU-C modules, the words Direct Connect or Digital Off-Hook are appended to the module name, depending on how the module is jumpered. Refer to the Cisco 6100 Setup and Installation Manual for more detail on ATU-C jumpering.
The SC monitors states to know when a particular port or connection is available. For example, the SC does not send a connection request to a modem that has a Service state of Out of Service.
Service states describe the overall ability of a resource to provide service. It is derived from a combination of Administrative, Operational and Supporting Entity Service states. Table 5-3 describes the Service states.
| Screen Display | Description |
|---|---|
In Service | The resource has all necessary permission, ability, and availability to provide service when requested. |
Out of Service | One or more assigned or derived attributes of the resource prevent it from providing service. |
If a supporting entity's Service state is Out of Service, that state propagates downward through the Cisco 6100 containment hierarchy to all subordinate entities. The Subordinate Service state depends on its supporting entity's Service state. Therefore, if the supporting entity in the containment hierarchy has a Service state of Out of Service, then all of its subordinate entities are also Out of Service.
All entities' states change depending on the setting of the supporting entity's state. The Cisco 6100's Service state describes whether an entity is able to provide service. Service state is derived from a combination of Administrative, Operational and Supporting Entity Service states.
Supporting Entity Service state is a key aspect of Service state which causes an Out of Service state to propagate downward through the Cisco 6100 object containment hierarchy to all subordinate entities. A supporting entity is defined as containing subordinate entities. For example, a module is a supporting entity to its ports, and conversely a port is a subordinate entity to a module.
When an entity's Service state transitions Out of Service, all subordinate resources' service states will also automatically be transitioned to Out of Service based on their Supporting Entity's Service state. The Cisco 6100 tears down active calls for entities that transition to Out of Service and does not attempt to use them for new calls.
The Supporting Entity Service state is simply the Service state of the supporting entity in the containment hierarchy. This state represents the administrative permissions and the operational capabilities of all the higher level entities depending on by this resource. If the Supporting entity's Service state is Out of Service, then the Subordinate entity's Service state will also be Out of Service.
Table 5-4 describes the Supporting Entity Service states.
.
| Screen Display | Description |
|---|---|
In Service | All resources depended on by this resource have the necessary permission, ability, or availability to provide service when requested. |
Out of Service | A resource depended on by this resource is unable to provide service. |
The Administrative state serves two purposes. It enables you to lock an entity to prevent it from providing service. It also provides a mechanism for triggering state changes in the Cisco 6100's configuration.
The Status tab displays the Administrative state for that entity. The Configuration tab lets you both display and modify the entity's Administrative state. To access the Administrative state, select the Configuration tab on any entity's Property dialog box. In this release, the Administrative state is either Locked or Unlocked. When an entity is Locked, it cannot actively participate in node operation.
Unlocking an entity gives administrative permission to allow that entity to perform its function. Table 5-5 describes the administrative states.
| Screen Display | Description |
|---|---|
Locked | Entity does not have administrative permission to perform its function. |
Unlocked | Entity has administrative permission to perform its function. |
Shutting Down | Entity has been configured as administratively Locked, while actively participating in providing a service connection. It will remain Unlocked until the service connection is disconnected, and will then transition to Locked. The Shutting Down state is used to prevent ADSL connections from being dropped immediately when a resource's configuration transitions to Locked. This allows ADSL connections to terminate in an orderly fashion, and then automatically transition to Locked so it cannot be used by subsequent ADSL connections. Note This state is not supported in this release. |
As Administrative state is a component of the service state, if Administrative state is Locked, the Service state becomes Out of Service.
When an administrator locks an entity, the lock ripples downward through the Cisco 6100 containment hierarchy to all of its subordinate resources. As a result, every subordinate resource's Service state changes to Out of Service.
Configuration changes are not applied to an entity unless changed after its Administrative state is set to Locked. Configuration changes can be entered into the entity's configuration dialog while the entity is Unlocked. However, these changes do not get applied until the entity's Administrative state is subsequently locked and re-unlocked.
ViewRunner for Windows requires you to carefully evaluate whether or not to administratively lock an entity's use. Locking an entity takes it Out of Service and terminates any active calls.
ViewRunner for Windows requires the highest level entity to be administratively locked prior to executing an action that results in ViewRunner locking subordinate entities. This paradigm guarantees that service affecting configuration changes will never be sent to an In Service entity without forcing a transition to the Unlocked state first.
ViewRunner for Windows requires an entity to be locked prior to allowing modification or deletion of the entity's service affecting configuration parameters. Service affecting parameters are any parameters that alter the service (DOH connection or PVC) provided to a subscriber. Examples include bit rate configuration, administrative state, and PVC configuration.
Non-service affecting configuration parameters do not require an unlock transition in order for them to take effect in the Cisco 6100. Non-service affecting parameters include entity names, such as Subscriber ID, and other system configuration parameters that are not directly involved with services. ViewRunner dialogs allow modification of these non-service affecting parameters while they are unlocked, and allows selection of the OK and Apply button.
When OK or Apply buttons are selected, ViewRunner for Windows determines the configuration modifications that you requested. If only non-service affecting data has changed, ViewRunner proceeds with modifying the entity's Administrative state.
In some instances, ViewRunner for Windows sends lock messages to the Cisco 6100 without an explicit state change. Done for convenience, this eliminates tedious lock operations, when locking would clearly be required to take further action.
ViewRunner for Windows performs automatic locks under the following conditions:
Operational states specify whether the resource is an alarmed condition or not. Operational states cannot be changed; it is a display-only field in the Status windows.
Table 5-6 describes the Operational states.
| Screen Display | Description |
|---|---|
Enabled | Resource is not in an alarm state. The resource is partially or fully operable and is able to provide service when so requested. |
Disabled | Resource is currently in an alarm state due to a fault being detected. The resource is totally inoperable and unable to provide service. |
The Operational state signals that a fault has been detected for a resource, but does not provide any details of specific alarms or the severity. ViewRunner allows you to view specific alarms by displaying a list box directly below the Operational state that shows all current alarms for the resource along with their severity. The alarms are listed in order by severity.
Posted: Mon Oct 11 22:18:51 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.