CISCO-WAN-SCT-MGMT-MIB: View SNMP OID List / Download MIB

MIB module to manage SCT files in a node. SCTs (Service Class Templates) are nodal configuration files, which define the traffic characteristics of a switch based on class of service queues. There is a unique SCT file for every combination of card type, SCT type, SCT Id and major SCT version. For instance, the file AXSM_PORT_SCT.4.V2 refers to a SCT for the card type AXSM, port type SCT, SCT id 4 and a major version of 2. SCTs are transfered to a node using FTP by NMS. The NMS adds, deletes, discovers and monitors SCT files in a node using this MIB.

This MIB defines a SCT file management table in which each row corresponds to a unique SCT file. When the NMS needs to add a SCT to a node, it transfers the SCT file to a transient storage area on the node. The NMS then performs a SET operation requesting the agent to accept the transferred file. The agent validates the integrity of the file and if valid, transfers the file to a secure area. It would then create a new row in the SCT file management table. This newly added row is then advertised to all NMS in the network using appropriate traps (refer CISCO-WAN-SCT-MGMT-TRAPS-MIB). Once a row is created, the agent keeps track of the operational status of the corresponding SCT file. The NMS can query the status of a SCT file by performing a GET operation on the row. The NMS can delete a SCT file and its corresponding row in the SCT file management table by performing a SET operation with the appropriate RowStatus. The agent, upon successful deletion of the row would advertise this configuration change to all the NMS using appropriate traps. The NMS could also perform a GETNEXT operation to discover all the configured SCTs on a node.

An entry in the SCT file Management Table. This represents a unique SCT file in the node. Each entry contains the configuration and status information of a specific SCT in the node.

This represents service modules in a node that require the use of a SCT. The content of the SCT varies depending on the specific hardware used. Hence there is a different SCT for every type of card. The card types that support SCTs are listed in the SYNTAX clause Enumeration: 'axsme': 2, 'pxm1e': 3, 'hsfr': 4, 'axsmxg': 5, 'axsm': 1.

There are several types of SCTs. The portSct (1) specifies traffic parameters that are applicable to a logical port within a card. The cardSct (2) specifies traffic parameters that are applicable to the whole card. Enumeration: 'portSct': 1, 'cardSct': 2.

Each logical port on a service module could need different 'class of service' characteristics. This can be achieved by applying different SCTs on different ports. Thus for a given card type, there could be multiple SCTs of different IDs.

The SCT file consists of several tables. The number of tables depend on the service module card type. Both the contents and the row/column size of a table are subject to change. The major version is incremented by the manager whenever there is a change in the row/column size of the table.

This object specifies the absolute path name of the file corresponding to the SCT indices. After the agent accepts a SET operation and creates a new row in the SCT file management table, it transfers the file from the transient storage area to a secure location on the disk. This object identifies the absolute path name of the secure location on disk. The file name would be in the format: _SCT...V

The SCT file consists of several tables. The number of tables depend on the service module card type. Both the contents and the row/column size of a table are subject to change. The minor version is incremented by the manager whenever there is a change in contents of the table.

The manager specifies this checksum when trying to add a SCT on the node. The agent while acting on the SET operation would perform a checksum computation on the FTPed file and compare against this object. If they differ, the SET operation would be negated. If same, the file is considered valid and this value is stored in a persistent database. SCT files across the network with the same combination of card type, sct type, major and minor versions would have the same checksum.

A description string can be associated with a specific SCT index and in turn the SCT file. This may be used for associating customized filenames.

Reflects the operational status of the SCT file. The agent sets the value to valid(1) if the computed checksum of the SCT file matches the provisioned checksum. The agent sets the value to invalid(2) if the computed checksum of the SCT file mismatches with the provisioned checksum. This usually suggests a corrupted SCT file. The agent sets the value to absent(3) if the file is missing in the secure area of the disk, while a row exists in the SCT file management table. Enumeration: 'absent': 3, 'valid': 1, 'invalid': 2.

* To create a row, the manager needs to perform a SET operations with a 'CreateAndGo' option. The agent would validate the file specified by the indices if found valid would create a new row. * SET operation with 'CreateAndWait' option will be rejected by the agent. * SET operations with 'active' option would be treated as a modify operation. The only objects that can be modified in a row are the cwSctFileDescription and the cwSctFileMinorVersion. * SET operation with a 'Destroy' option would be used for deleting a row in the cwSctFileMgmtTable and its associated SCT file in the switch. * The GET status of this object would always return 'active'.

The compliance statement for Cisco SCT file management group.

Objects used for SCT file management.