4 About Collected Data

This chapter explains how the Oracle Communications Network Integrity Optical TMF814 CORBA cartridge treats collected data.

About Collected Data

The Oracle Communications Network Integrity Optical TMF814 CORBA cartridge uses a standard TMF814 common object request broker architecture (CORBA) interface, which models network elements using the Multi Technology Network Management (MTNM) standard.

Table 4-1 lists MTNM objects and corresponding TMF814 IDL API class definitions.

Table 4-1 MTNM IDL Class Definitions

MTNM Object Name	TMF814 IDL API Class Definition
Managed Element (ME)	ManagedElement_T
Equipment Holder (Rack)	EquipmentHolder_T
Equipment Holder (Shelf)	EquipmentHolder_T
Equipment Holder (Slot)	EquipmentHolder_T
Equipment Holder (Sub Slot)	EquipmentHolder_T
Equipment (Card)	Equipment_T
Physical Termination Point (PTP)	TerminationPoint_T
Floating Termination Point (FTP)	TerminationPoint_T
Connection Termination Point (CTP)	TerminationPoint_T
Cross-connect	CrossConnect_T
Topological Link	TopologicalLink_T
LayeredParameters	LayeredParameters_T

A CTP can have a child CTP with infinite nesting levels. LayeredParameters are not top-level MTNM objects. They are a property of a termination point (TP).

Multi Technology Network Management Hierarchy

The following example demonstrates the MTNM hierarchy:

Managed Element
  Equipment Holder(rack 1)
    Equipment Holder (shelf 1)
      Equipment Holder (sub shelf 1)
        Equipment Holder (slot 1)
          Equipment Holder(sub slot 1)
            Equipment(card 1)
              Termination Point (PTP){0…*}
                Termination Point (CTP){0…*}
          Equipment Holder(sub slot 2)
            Equipment(card 2)
              Termination Point (PTP){0…*}
                Termination Point (CTP){0…*}
                  Termination Point (CTP){0…*}

The following tables describe the properties of each MTNM object collected by the Optical TMF814 CORBA cartridge:

Table 4-2, "Managed Elements Properties"
Table 4-3, "Equipment Properties"
Table 4-4, "Equipment Holder Properties"
Table 4-5, "PTP, FTP, and CTP Properties"
Table 4-6, "Cross-Connect Properties"
Table 4-7, "Topological Link Properties"

Table 4-2 Managed Elements Properties

Property Name	Description
name	The name of the managed element (ME) that is assigned by the element management system (EMS) upon creation.
userLabel	Identifies the label assigned to the ME by the operator.
nativeEMSName	Indicates how the ME is referred to on EMS displays.
owner	Provided by the network management system (NMS).
location	Indicates the geographical location of the ME.
version	The active software version of the ME.
productName	Identifies the ME product or type name.
communicationState	Indicates the viability of EMS-ME messaging. Possible values are CS_AVAILABLE, CS_UNAVAILABLE.
emsInSyncState	Indicates if the EMS is able to keep the current EMS data synchronized with the current ME data and generate all appropriate notifications. The EMS sets this attribute to FALSE to indicate that it requires re-synchronization with ME data and that it is not able to generate the appropriate notifications while doing so.
supportedRates	This attribute is a list of potential cross-connection rates at which it is possible to have cross-connections within the ME.
additionalInfo	Represents a list of attributes that are EMS and NMS implementation specific. This field is common to all MTNM-managed objects. This field consists of a list of name and value pairs that call additional information, which allow EMS or NMS to give additional information that is not explicitly modeled at the MTNM interface. Some parameter names and values may be predefined.

Table 4-3 Equipment Properties

Property Name	Description
name	The name of the Equipment that is assigned by the EMS upon creation.
nativeEMSName	Indicates how the Equipment is referred to on EMS displays.
userLabel	A label assigned to the Equipment by the operator.
owner	Provided by the NMS.
alarmReportingIndicator	Indicates whether alarm reporting for this instance is active.
expectedEquipmentObjectType	Defines the type of expected Equipment. Leave empty if there is no expected Equipment. Example value: MBP_300.
installedEquipmentObjectType	Defines the type of installed Equipment. Leave empty if there is no installed Equipment.
installedPartNumber	Indicates the part number of the installed Equipment.
installedSerialNumber	Indicates the serial number of the installed Equipment.
installedVersion	Indicates the firmware version of the installed Equipment.
serviceState	Indicates the current state of the Equipment. Possible values are IN_SERVICE, OUT_OF_SERVICE, OUT_OF_SERVICE_BY_MAINTENANCE, SERV_NA.
additionalInfo	Represents a list of attributes that are EMS and NMS implementation specific. This field is common to all MTNM-managed objects. This field consists of a list of name and value pairs calling additional information and allowing EMSs or NMSs to give additional information that is not explicitly modeled at the MTNM interface. Some parameter names and values may be predefined.

Table 4-4 Equipment Holder Properties

Property Name	Description
name	Equipment Holder unique name. The EMS is responsible for the uniqueness of the name within the context of the ME.
nativeEMSName	Indicates how the Equipment Holder is referred to on EMS displays.
userLabel	Provided by the NMS.
owner	Provided by the NMS.
alarmReportingIndicator	Indicates whether alarm reporting is active for the instance.
holderType	Indicates the type of Equipment Holder. Valid values are: rack, shelf, sub_shelf, slot, sub_slot.
holderState	Indicates the state of the Equipment Holder directly contained equipment. Possible values are: EMPTY (0), INSTALLED_AND_EXPECTED (1), EXPECTED_AND_NOT_INSTALLED (2), INSTALLED_AND_NOT_EXPECTED (3), MISMATCH_OF_INSTALLED_AND_EXPECTED (4), UNAVAILABLE (5), UNKNOWN (6).
expectedOrInstalledEquipment	The Equipment object expected or installed in the Equipment Holder, if any. A value of NULL indicates that the Equipment Holder is empty or that it contains only other Equipment Holders.
acceptableEquipmentTypeList	Represents the types of Equipment objects that can be directly supported by the Equipment Holder.
additionalInfo	Represents a list of attributes that are EMS and NMS implementation specific. This field is common to all MTNM-managed objects. This field consists of a list of name and value pairs that call additional information, which allow EMS or NMS to give additional information that is not explicitly modeled at the MTNM interface. Some parameter names and values may be predefined.

Table 4-5 PTP, FTP, and CTP Properties

Property Name	Description
name	Indicates the assigned TP name when created by the EMS. The EMS is responsible for guaranteeing the uniqueness of the name within the context of the ME. The naming for CTPs, PTPs, and FTPs is deterministic.
nativeEMSName	Indicates how the TP is referred to on EMS displays.
userLabel	The user label of the TP is set with NMS data (typically the end-to-end trail data).
owner	Indicates the ownership of the TP so that adminstrativeState can be managed.
direction	Indicates the direction of the TP. Possible values are: D_NA (0), D_BIDIRECTIONAL (1), D_SOURCE (2), D_SINK (3).
tpProtectionAssociation	Indicates the associated TP indication. The NMS is responsible for running the multiLayerSubnetwork::MultiLayerSubnetworkMgr_I::getAssociatedTP() service to obtain any related TP.
edgePoint	Indicates if the TP is an edge point of one or more subnetworks.
ingressTransmissionDescriptorName	Indicates whether a CTP references an ingress (incoming) Traffic Descriptor or Transmission Descriptor.
egressTransmissionDescriptorName	Indicates whether a CTP references an egress (outgoing) Traffic Descriptor or Transmission Descriptor.
connectionState	Indicates the connection state of the source. A value of TPCS_BI_CONNECTED indicates that the source is connected to one entity and the sink is connected to the other. Possible values are: TPCS_NA, TPCS_SOURCE_CONNECTED, TPCS_SINK_CONNECTED, TPCS_BI_CONNECTED, TPCS_NOT_CONNECTED.
tpMappingMode	Indicates and controls the connection of the named connection point at a specified LayerRate to the dedicated G.805 TCP and associated G.805 Termination Function at the same LayerRate within the CTP or FTP. Possible values are: TM_NA(0), TM_NEITHER_TERMINATED_NOR_AVAILABLE_FOR_MAPPING (1), TM_TERMINATED_AND_AVAILABLE_FOR_MAPPING (2).
type	Possible value are: TPT_PTP (0), TPT_CTP (1), TPT_TPPool (2).
transmissionParams	A list of transmission parameters that can be set or retrieved on the TP at a specified layer. This attribute must contain the complete set of layer rates represented by a PTP, CTP, or FTP, even if they have no parameters associated with them. The Layer Rates are listed in the order of their client-server relationship.
additionalInfo	Represents a list of attributes that are EMS and NMS implementation specific. This field is common to all MTNM-managed objects. This field consists of a list of name and value pairs that call additional information, which allows the EMS or NMS to give additional information that is not explicitly modeled at the MTNM interface. Some parameter names and values may be predefined.

Table 4-6 Cross-Connect Properties

Property Name	Description
active	Indicates if the cross-connect is active in the ME.
ccType	Indicates the cross-connect type. Possible values are: ST_SIMPLE, ST_ADD_DROP_A, ST_ADD_DROP_Z, ST_INTERCONNECT, ST_DOUBLE_INTERCONNECT, ST_DOUBLE_ADD_DROP, ST_OPEN_ADD_DROP, ST_EXPLICIT
direction	Directionality of the cross connection. Possible values are: CD_UNI, CD_BI
aEndNameList	Names of CTPs, FTPs, and group termination points (GTPs) at the aEnd of the cross-connect.
zEndNameList	Names of CTPs, FTPs, and GTPs at the zEnd of the cross-connect.
additionalInfo	Represents a list of name value pairs that allow EMSs or NMSs to give additional information that is not explicitly modeled at the MTNM interface, but some parameter names and values may be predefined. Some predefined parameter names may include: ConnectionId, Fixed, RouteActualState, RouteAdminState, RouteExclusive, RouteId, RouteIntended, RouteInUseBy.

Table 4-7 Topological Link Properties

Property Name	Description
name	Indicates the name of the Topological Link, assigned by the EMS upon creation.
userLabel	Indicates the topological link user label (end-to-end trail data) in NMS data.
nativeEMSName	Indicates how the topological link is referred to on EMS displays.
owner	Provided by the NMS.
direction	Indicates the direction of the topological link. A topological link can be unidirectional even if both its ends are bidirectional TPs. Possible values are CD_UNI (unidirectional) and CD_BI (bidirectional).
rate	Indicates the layer rate (bandwidth) of the topological link.
aEndTP	Indicates the name of the aEnd for the PTP, CTP, or FTP.
zEndTP	Indicates the name of the zEnd for the PTP, CTP, or FTP.
additionalInfo	Represents a list of name/value pairs that allow EMSs or NMSs to give additional information that is not explicitly modeled at the MTNM interface, but some parameter names and values may be predefined. Some predefined parameter names may include: AlarmReporting, AllocatedNumber, ASAPpointer, FragmentServerLayer, NetworkAccessDomain.

Layer Parameters

The Optical TMF814 CORBA cartridge collects layer parameters for TPs. In the MTNM model, these layer parameters are encapsulated by TPs as transmission parameters. For details on layered parameters see the TMF814 documentation.

TMF814 APIs

This section describes the APIs used by the Optical TMF814 CORBA cartridge to collect data.

CORBA APIs

Table 4-8 lists the APIs used by the Optical TMF814 CORBA cartridge.

Table 4-8 TMF814 ManagedElement and Equipment CORBA APIs

API	Used Operations
org.tmforum.mtnm.emsSessionFactory.EmsSessionFactory_I	getEmsSession(): used to obtain the EmsSession objects.
org.tmforum.mtnm.emsSession.EmsSession_I	getManager(): used to obtain managers. endSSession(): used to close the EMS session.
org.tmforum.mtnm.managedElementManager.ManagedElementMgr_I	getAllFTPs(): used to obtain all FTPs, but not obtain any PTPs. getAllPTPs(): used to obtain all PTPs. getContainedInUseTPs(): used to obtain all contained in-use TPs. getContainedPotentialInUseTPs(): used to obtain all contained potential CTPs for a given TP.
org.tmforum.mtnm.nmsSession.NmsSession_I	EmsSessionFactory_I.getEmsSession: required nmsSesion while getting a Ems session so a dummy implementation is provided.
org.tmforum.mtnm.equipment.EquipmentInventoryMgr_I	getAllEquipment(): used to obtain all Equipment. getAllSupportedPTP(): used to obtain all the PTPs for a given Equipment.

APIs for Cross-Connect Collection

Table 4-9 lists the APIs used for cross-connect collection.

Table 4-9 TMF814 Cross-Connect Collection APIs

API	Used Operations
managedElementManager.ManagedElementMgr_I	getAllCrossConnections(MEName, layerRate, how_many, CClist, CCIter)
multiLayerSubnetwork.MultiLayerSubnetworkMgr_I	getAllTopLevelSubnetworks(how_many, holder, iter) getAllSubnetworkConnections(SN_Name, layerRateList, how_many, holder, iter) getRoute(SNC_Name, includeHigherOrderCCs, route)

APIs for Topological Link Collection

There are two levels of Topological Links that can be retrieved using two different APIs. Table 4-10 lists the APIs used for cross-connect collection.

Table 4-10 TMF814 Topological Link Collection APIs

APIs	Used Operations
emsMgr.EMSMgr_I	getAllTopLevelTopologicalLinks(how_many, topoList, topoIt)
multiLayerSubnetwork.MultiLayerSubnetworkMgr_I	getAllTopologicalLinks(SN_Name, how_many, topoList, topoIterator)

The EMSMgs API is used when the entire network is treated as a subnetwork. The MLSN API is used when each ME is treated as a subnetwork.

Handling Vendor Variations

This section explains how the Optical TMF814 CORBA cartridge handles some of the particular data collected from some vendors.

FTP Collection API Variations

The ManagedElementMgr_I.getAllFTP() operation, from MTNM version 3.0, is the preferred API to get all FTPs of a ME. For the vendors and devices that do not support MTNM version 3.0, the getAllPTP() operation is used. The getAllPTP() operation returns both PTPs and FTPs. While modeling FTPs, PTPs are filtered out.

Cross-Connect Collection API Variation

Cross-connects are collected using different APIs depending on the vendor. Use the crossConnectCollectionType parameter to specify the collection method, based on vendor device specifications. See "APIs for Cross-Connect Collection" for more information.

Topological Link Collection API Variation

Topological links are collected using different APIs depending on the vendor. Use one or both methods as required by the vendor or vendor device. Use the topologicalLinkCollectionType parameter to specify the collection method. See "APIs for Topological Link Collection" for more information.

Cross-Connect Protection Role

The productized Optical TMF814 CORBA cartridge does not discover protection role information on cross-connect segments because vendors and devices differ in the way this information is accessed. You must extend the Optical TMF814 CORBA cartridge to collect and model protection role information. See "Collecting and Modeling Protection Role Information" for more information.