This chapter describes the functionality and design of the Oracle Communications Network Integrity Cisco ONS 15454 SONET TL1 reference cartridge (Cisco 15454 TL1 reference cartridge) and how to use and build the cartridge.
The Cisco 15454 TL1 reference cartridge contains the Discover Cisco 15454 TL1 action. The Discover Cisco 15454 TL1 action discovers Cisco 15454 TL1 devices in your network. This discovery action extends the Discover Abstract TL1 action to establish the TL1 connection and set the TL1 properties.
The Discover Cisco 15454 TL1 action scans devices and provides a physical hierarchical model of the discovered data. This cartridge is designed to discover Cisco ONS 15454 SONET devices only. The scan fails if you use this cartridge to discover non-Cisco or other Cisco devices.
This discovery action inherits all the processors from the Discover Abstract TL1 actions. For more information about the inherited processors, see "About the TL1 Cartridge".
The Discover Cisco 15454 TL1 action contains the following processors run in the following order:
TL1 Property Initializer (inherited)
TL1 Property Customizer (inherited)
TL1 Connection Manager (inherited)
Figure 3-1 illustrates the processor workflow of the Discover Cisco 15454 TL1 action.
Figure 3-1 Discover Cisco 15454 TL1 Action Processors Workflow
This processor retrieves the device data using TL1 protocol and makes it available for modeling. This processor runs four TL1 commands for each device.
RTRV-NETYPE: to get network element (NE) level details.
RTRV-NE-GEN: to get NE level details.
RTRV-INV: to get card level details.
RTRV-EQPT: to get card level details.
This processor models the data collected by the Cisco 15454 TL1 Device Collector processor, building the hierarchical relationship for physical devices and children equipment, equipment holders, and physical ports.
The Cisco 15454 TL1 Device Persister persists the physical device tree to the Network Integrity database.
This section discusses the data that is collected for modeling, listing, and explaining each request and response command.
This section shows the TL1 request definition and sample TL1 responses that the processors could receive from a device.
The RTRV-NETYPE request resembles the following example:
RTRV-NETYPE:[<TID>]::<CTAG>;
The RTRV-NETYPE response line is made up of a positional parameter block with the following format:
SID DATE TIME M CTAG COMPLD "<VENDOR>,<MODEL>,<NETYPE>,<SW_ISSUE>" ;
Example 3-1 shows an example RTRV-NETYPE response.
Example 3-1 RTRV-NETYPE Response Example
TID-000 1998-06-20 14:30:00 M 001 COMPLD "CISCO,ONS15454,ADM&MSPP&MSTP,5.00.00" ;
The RTRV-NE-GEN request resembles the following example:
RTRV-NE-GEN:[<TID>]::<CTAG>;
The RTRV-NE-GEN response line is made up of one named parameter block with the following format:
SID DATE TIME M CTAG COMPLD "[IPADDR=<IPADDR>],[IPMASK=<IPMASK>],[DEFRTR=<DEFRTR>],[IPV6ADDR=<ipv6addr>],[IPV6PREFLEN=<ipv6preflen>],[IPV6DEFRTR=<ipv6defrtr>],[IPV6ENABLE=<ipv6enable>],[IIOPPORT=<IIOPPORT>],[NTP=<NTP>],[NAME=<NAME>],[SWVER=<SWVER>],[LOAD=<LOAD>],[PROTSWVER=<PROTSWVER>],[PROTLOAD=<PROTLOAD>],[DEFDESC=<DEFDESC>],[PLATFORM=<PLATFORM>],[SECUMODE=<SECUMODE>],[SUPPRESSIP=<SUPPRESSIP>],[MODE=<MODE>],[MSPUBVLANID=<MSPUBVLANID>],[MSINTLVLANID=<MSINTLVLANID>],[AUTOPM=<AUTOPM>],[SERIALPORTECHO=<SERIALPORTECHO>],[OSIROUTINGMODE=<OSIROUTINGMODE>],[OSIL1BUFSIZE=<OSIL1BUFSIZE>],[OSIL2BUFSIZE=<OSIL2BUFSIZE>], [NET=<NET>] >],[BKUPNTP=<BKUPNTP>]" ;
Example 3-2 shows an example RTRV-NE-GEN response.
Example 3-2 RTRV-NE-GEN Response Example
TID-000 1998-06-20 14:30:00 M 001 COMPLD IPADDR=192.168.100.52,IPMASK=255.255.255.0,DEFRTR=192.168.100.1,IPV6ADDR="[3ffe:0501:0008:0000:0260:97ff:fe40:efab]",IPV6PREFLEN=64,IPV6DEFRTR="[3ffe:0501:0008:0000:0260:97ff:fe40:e000]",IPV6ENABLE=NO,IIOPPORT=57970,NTP=192.168.100.52,NAME="NODENAME",SWVER=2.01.03,LOAD=02.13-E09A-08.15,PROTSWVER=2.01.02,PROTLOAD=02.12-E09A-09.25,DEFDESC=\"NE DEFAULTS FEATURE\",PLATFORM=15454-ANSI,SECUMODE=NORMAL,SUPPRESSIP=YES,PROXYSRV=N,FIREWALL=N,MSPUBVLANID=1,MSINTLVLANID=2,AUTOPM=NO,SERIALPORTECHO=Y,OSIROUTINGMODE=ES,OSIL1BUFSIZE=512,OSIL2BUFSIZE=512" ;
The RTRV-INV request resembles the following example:
RTRV-INV:[<TID>]:<AID>:<CTAG>[::::];
The RTRV-INV response line is made up of three parameter blocks: a positional block, followed by an empty block, followed by a named block. The response line has the following format:
SID DATE TIME M CTAG COMPLD "<AID>,<AIDTYPE>::[PLUGTYPE=<PLUGTYPE>],[PN=<PN>],[HWREV=<HWREV>],[FWREV=<FWREV>],[SN=<SN>],[CLEI=<CLEI>],[TWL=<TWL>],[PLUGINVENDORID=<PLUGINVENDORID>],[PLUGINPN=<PLUGINPN>],[PLUGINHWREV=<PLUGINWREV>],[PLUGINFWREV=<PLUGINFWREV>],[PLUGINSN=<PLUGINSN>],[ILOSSREF=<ILOSSREF>],[PID=<PID>],[VID=<VID>],[FPGA=<FPGA>],[MODULETYPE=<MODULETYPE>]" ;
Example 3-3 shows an example RTRV-INV response.
Example 3-3 RTRV-INV Response Example
TID-000 1998-06-20 14:30:00 M 001 COMPLD "SLOT-15,OC3-IR-4::PLUGTYPE=SX-IR-SW-SN,PN=87-31-00002,HWREV=004K,FWREV=76-99-00009-004A,SN=013510,CLEI=NOCLEI,TWL1=1546.12,TWL2=1546.92,TWL3=1547.72,TWL4=1548.51,PLUGINVENDORID=012345,PLUGINPN=ABCDE,PLUGINHWREV=ABCDE,PLUGINFWREV=01-02-03,PLUGINSN=01234,ILOSSREF=1.0,PID=CISCO_ONS15454,VID=V01,FPGA=F451,MODULETYPE=101" ;
The RTRV-EQPT request resembles the following example:
RTRV-EQPT:[<TID>]:<AID>:<CTAG>[::::];
The RTRV-EQPT response line is made up of four parameter blocks:
Block 1 uses the TL1PositionalParameterBlock format and models the following element:
AID
Block 2 uses the TL1PositionalParameterBlock format and models the following elements:
AIDTYPE
EQUIP
ROLE
STATUS
Block 3 uses the TL1NamesParameterBlock format. This block does not need to model any values. The CARDNAME element is modeled in this block as a container.
Block 4 uses the TL1PositionalParameterBlock format and models the following element:
PST
SST
The response line has the following format:
SID DATE TIME M CTAG COMPLD "<AID>:<AIDTYPE>,<EQUIP>,[<ROLE>],[<STATUS>]:[<PROTID>],[<PRTYPE>],[<RVRTV>],[<RVTM>],[<CARDNAME>],[<IOSCFG>],[<CARDMODE>],[<PEERID>],[<REGENNAME>],[<PEERNAME>],[<TRANSMODE>],[<RETIME>],[<SHELFROLE>],[<FRPROLE>],[<FRPSTATE>],[<FRPHOLDOFFTIME>],[<ADMINCVLAN>],[<ADMINSVLAN>],[<CFMSTATE>],[<CCTIMER>],[<SWITCHWITHCRCALARM>],[<CRCTHR>],[<CRCPOLLINTRVL>],[<CRCSOAKCOUNT>]:<PST>,[<SST>]" ;
Note:
This format, taken from Cisco documentation, does not show the third parameter block as named block, but is inferred from the example response provided.Example 3-4 shows an example RTRV-EQPT response.
Example 3-4 RTRV-EQPT Response Example
TID-000 1998-06-20 14:30:00 M 001 COMPLD "SLOT-1:10GE-XP,UNEQUIP,,NA:CARDMODE=10GEXP-L2ETH,FRPROLE=SLAVE,FRPSTATE=DISABLED,FRPHOLDOFFTIME=DISABLED,ADMINCVLAN=0,ADMINSVLAN=0,CFMSTATE=N,CCTIMER=ONE-SEC,SWITCHWITHCRCALARM=Y,CRCTHR=10E-2,CRCPOLLINTRVL=60,CRCSOAKCNT=10:OOS-AU,AINS&UEQ" "SLOT-2:GE-XP,UNEQUIP,,NA:CARDMODE=GEXP-L2ETH,FRPROLE=SLAVE,FRPSTATE=DISABLED,FRPHOLDOFFTIME=DISABLED,ADMINCVLAN=0,ADMINSVLAN=0,CFMSTATE=N,CCTIMER=ONE-SEC,SWITCHWITHCRCALARM=Y,CRCTHR=10E-2,CRCPOLLINTRVL=60,CRCSOAKCNT=10:OOS-AU,AINS&UEQ" ;
The Cisco 15454 TL1 reference cartridge models collected data according to the Information Model. Collected data is modeled into the following entities:
PhysicalDevice
Equipment
PhysicalPort
EquipmentHolder
Static field model entities are compliant with version 1.0.1 of the Information Model. Dynamic field model entities are application specific.
The following tables explain the field mappings for each Information Model object.
Table 3-1 Physical Device Field Mapping
Information Model Attribute | Information Model Support | TL1 Data Source | Type |
---|---|---|---|
ID |
Static |
N/A |
String |
Name |
Static |
RTRV-NE-GEN: NAME |
String |
Description |
Static |
RTRV-NE-GEN: DEFDESC |
String |
Serial Number |
Static |
N/A |
String |
Native EMS Name |
Static |
RTRV-NE-GEN: NAME |
String |
Physical Location |
Static |
N/A |
String |
Software Version |
Dynamic |
RTRV-NE-GEN: SWVER |
String |
Protect Software Version |
Dynamic |
RTRV-NE-GEN: PROTSWVER |
String |
Model Name |
Dynamic |
RTRV-NETYPE: MODEL |
String Values: ONS15454, ONS15600, Unknown |
NE Type |
Dynamic |
RTRV-NETYPE: NETYPE |
String Values: ADM, DCS, MSPP, MSTP |
Discovered Vendor Name |
Dynamic |
RTRV-NETYPE: VENDOR |
String |
Table 3-2 Equipment (Shelf) Field Mapping
Information Model Attribute | Information Model Support | TL1 Data Source | Type |
---|---|---|---|
ID |
Static |
N/A |
String |
Name |
Static |
N/A |
String Programatically generated. |
Description |
Static |
N/A |
String |
Serial Number |
Static |
N/A |
String |
Native EMS Name |
Static |
N/A |
String Programatically generated. |
Physical Location |
Static |
N/A |
String |
Note:
A shelf is not an entity that can be directly discovered. Therefore, shelves do not have any characteristics defined beyond the existing entity attributes.Table 3-3 Equipment (Card) Field Mapping
Information Model Attribute | Information Model Support | TL1 Data Source | Type |
---|---|---|---|
ID |
Static |
N/A |
String |
Name |
Static |
RTRV-INV: AIDTYPE |
String |
Description |
Static |
N/A |
String |
Serial Number |
Static |
RTRV-INV: SN |
String |
Native EMS Name |
Static |
RTRV-INV: AIDTYPE |
String |
Physical Location |
Static |
N/A |
String |
Discovered Part Number |
Dynamic |
RTRV-INV: PN |
String |
Firmware Revision |
Dynamic |
RTRV-INV: FWREV |
String |
Hardware Revision |
Dynamic |
RTRV-INV: HWREV |
String |
Note:
Equipment is modeled only if RTRV-EQPT:EQUIP for that equipment is set to EQUIP.Although the TL1 <AID> field is not modeled, it is used to determine the slot the equipment is mounted in.
Table 3-4 Equipment Holder Field Mapping
Information Model Attribute | Information Model Support | TL1 Data Source | Type |
---|---|---|---|
ID |
Static |
N/A |
String |
Name |
Static |
N/A |
String Programmatically generated. SLOT-# to match the RTRV-INV: AID values. |
Description |
Static |
N/A |
String |
Serial Number |
Static |
N/A |
String |
Native EMS Name |
Static |
N/A |
String Programmatically generated. SLOT-# to match the RTRV-INV: AID values. |
Physical Location |
Static |
N/A |
String |
Note:
Equipment holders cannot be discovered directly, so they are automatically created and populated. Because the cartridge is for a Cisco ONS 15454 SONET device, the cartridge will create the shelf with 17 slots ready to be populated with card equipment. For other models, a mapping file can be used to list how many slots each model has based on the RTRV-NETYPE: MODEL field.Because equipment holders are not discoverable, they are created without a specification.
Table 3-5 Physical Port Field Mapping
Information Model Attribute | Information Model Support | TL1 Data Source | Type |
---|---|---|---|
ID |
Static |
N/A |
String |
Name |
Static |
N/A |
String |
Description |
Static |
N/A |
String |
Serial Number |
Static |
N/A |
String |
Native EMS Name |
Static |
N/A |
String |
Physical Location |
Static |
N/A |
String |
Port Number |
Static |
N/A |
String |
Custom Port Name |
Static |
N/A |
String |
Note:
Physical ports cannot be discovered directly, so they are automatically created and populated using the value provided in the Cisco15454Cards property group that maps card types to the number of ports. No ports are created on the parent card if no entry exists in the property group.Model correction occurs when the TL1 information received through discovery does not conform to the Information Model or is incomplete and therefore cannot be saved to the Network Integrity database.
The Cisco 15454 TL1 reference cartridge applies model corrections in the following cases:
Missing EquipmentHolder under Equipment: TL1 does not directly discover slots. EquipmentHolder entities are created automatically under the shelf of the Cisco 15454. Because this Cisco 15454 shelf is specific to a model, the cartridge creates the 17 slots automatically.
Missing Equipment (Shelf) under PhysicalDevice: TL1 does not discover card and node level details. The existence of a shelf is not explicit and must be derived.
Missing PhysicalPort under Equipment: TL1 does not directly discover ports. PhysicalPort entities are created automatically under the cards of the Cisco 15454 depending on configured property values, as shown in the example below:
PhysicalDevice (Cisco 15454 Physical Device)
Equipment (Cisco 15454 Shelf)
EquipmentHolder (Specificationless entity)
Equipment (Cisco 15454 Card)
PhysicalPort (Specificationless entity)
This section describes how to use the Cisco 15454 TL1 reference cartridge.
The Cisco 15454 TL1 reference cartridge does not introduce any new scan parameter groups. Because the Cisco 15454 TL1 reference cartridge extends the TL1 cartridge, the configurable scan parameter groups are those from the TL1 cartridge.
The Cisco ONS 15454 SONET device can act as a TL1 gateway, through which the Cisco 15454 TL1 reference cartridge can discover other devices connected to the gateway. When discovering a TL1 gateway, you can configure and filter the list of returned NEs in the Network Integrity UI.
To discover TL1 devices through a Cisco ONS 15454 SONET TL1 gateway, create a TL1 discovery scan in the same way that you create a discovery scan for TL1 devices. See "Using the TL1 Cartridge" for the procedure. When setting the values in the General tab in the Scan Action Parameters area, do the following to set the Advanced TL1 scan parameter groups:
Set the Gateway Discovery list to True.
In the Gateway NE List Command field, enter the following TL1 request: RTRV-MAP-NETWORK:[<TID>]::<CTAG>;.
The RTRV-MAP-NETWORK request collects the list of devices that are in the span of control of the device that is acting as a TL1 gateway.
In the Gateway Response ID Section field, enter 0.
In the Gateway Response ID field, enter 1.
The response line has the following format:
SID DATE TIME M CTAG COMPLD "<IPADDR>,<NODENAME>,<PRODUCT>" ;
Example 3-5 shows an example RTRV-MAP-NETWORK response.
The Cisco 15454 TL1 reference cartridge uses a property group called Cisco15454Cards as a mapping table for the modeling processor to create physical ports on the cards. You can modify, add, or remove properties in this property group using the Enterprise Manager MBean Browser.
In the MBean Browser, this property group is found at the following location:
Discover Cisco 15454 TL1:Cisco 15454 TL1 Device Modeler:Cisco15454Cards
See Network Integrity System Administrator's Guide for more information about property groups and the MBean Browser.
Table 3-6 shows the preconfigured values for the Cisco15454Cards property group.
The discovered card name is taken from the AIDTYPE field in the RTRV-INV TL1 response. When adding new entries, remove spaces and dashes from the card name. For example, if the AIDTYPE is OC3-IR-4, enter the name in the property group as OC3IR4.
If the AIDTYPE of a card cannot be found in the table, no physical port is created under the card.
Discovered results have a result group for each device.
Table 3-7 lists the specifications that are used to model entities discovered by the Cisco 15454 TL1 reference cartridge in the Information Model.
Table 3-7 Cisco 15454 TL1 Reference Cartridge Discovery Specifications
Specification | Information Model Entity |
---|---|
Cisco 15454 Physical Device |
PhysicalDevice |
Cisco 15454 Shelf |
Equipment |
Cisco 15454 Card |
Equipment |
The tree below shows the hierarchy of the modeled devices:
PhysicalDevice (Cisco 15454 Physical Device) Equipment (Cisco 15454 Shelf) EquipmentHolder (Specificationless entity) Equipment (Cisco 15454 Card) PhysicalPort (Specificationless entity)
Physical device and shelf entities are modeled explicitly as Cisco model-specific specifications.
Cards are modeled using a generic Cisco 15454 card specification, instead of a card-specific specification. Depending on the inventory system used, you might want to explicitly model each card type as a specification.
Equipment holder (slot) entities are modeled without a specification because slots are not directly discoverable. Therefore, no parameters beyond the base entity attributes are populated. Because a slot is not a physical object, there is no need to explicitly define a specification for it. By creating a slot without a specification, you can extend the cartridge to assign any custom specification you require.
Ports are not directly discoverable. You can use and develop a property group to model ports on cards. See "Property Groups" for more information.
Figure 3-2 shows a sample set of discovered data from the Cisco 15454 TL1 reference cartridge.
Figure 3-2 Sample Discovery Data From Cisco 15454 TL1 Reference Cartridge
This section provides information about the composition of the TL1 cartridge from the Oracle Communications Design Studio perspective.
Table 3-8 shows the Design Studio construction of the Cisco 15454 model collection.
The following tables outline the Design Studio construction of the Cisco 15454 TL1 reference cartridge actions and associated components:
Table 3-9 TL1 Cartridge Actions
Action Name | Result Category | Address Handler | Scan Parameter Groups | Processors |
---|---|---|---|---|
Discover Cisco 15454 TL1 |
Device |
IPAddressHandler |
|
Table 3-10 TL1 Cartridge Processors
Processor Name | Variable |
---|---|
TL1 Property Initializer |
See "About the TL1 Cartridge" for more information. |
TL1 Connection Manager |
See "About the TL1 Cartridge" for more information. |
TL1 Property Customizer |
See "About the TL1 Cartridge" for more information. |
Cisco 15454 TL1 Device Collector |
Input:
Output:
|
Cisco 15454 TL1 Device Modeler |
Input: neName, gatewayNEDataMap, eqtResponse, invResponse, netypeResponse, negenResponse Output: physicalTree |
Cisco 15454 TL1 Device Persister |
Input: physicalTree Output: N/A |
The source code to this cartridge is provided. You can change any part of the code to customize this cartridge to fit your environment, or you can use the code as an example on which to model your own custom TL1 device cartridge.
For more information about extensibility, see Network Integrity Developer's Guide and Network Integrity Concepts.