topology database reference · v ibm tivoli network manager ip edition network troubleshooting...

Network Manager IP EditionVersion 4 Release 1.1

Topology Database Reference

R4.1.1 E2

��

NoteBefore using this information and the product it supports, read the information in “Notices” on page 293.

This edition applies to version 4.1.1 of IBM Tivoli Network Manager IP Edition (product number 5724-S45) and toall subsequent releases and modifications until otherwise indicated in new editions.

© Copyright IBM Corporation 2006, 2015.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corp.

Contents

About this publication . . . . . . . . viiIntended audience . . . . . . . . . . . . viiWhat this publication contains . . . . . . . . viiPublications . . . . . . . . . . . . . . viiiAccessibility . . . . . . . . . . . . . . xiTivoli technical training . . . . . . . . . . xiSupport and community information . . . . . . xiiConventions used in this publication . . . . . xiii

Chapter 1. NCIM topology database . . . 1

Chapter 2. About NCIM . . . . . . . . 3Topology database tasks . . . . . . . . . . 3Topology database architecture . . . . . . . . 3Topology database properties . . . . . . . . . 5Topology data . . . . . . . . . . . . . . 6

Domains and entities . . . . . . . . . . 6Relationships . . . . . . . . . . . . . 15

NCIM cache files . . . . . . . . . . . . 18SQL files for the NCIM schema. . . . . . . . 18

Chapter 3. Topology database queries 21Logging in to NCIM . . . . . . . . . . . 21Formatting used in the SQL queries . . . . . . 21Techniques used in the SQL queries . . . . . . 22

Choice of driving table . . . . . . . . . 22Aliasing . . . . . . . . . . . . . . 22Table joins . . . . . . . . . . . . . . 22

Use of specific fields and tables in queries . . . . 23mainNodeEntityId field . . . . . . . . . 23entityType field . . . . . . . . . . . . 23Protocol endpoint tables . . . . . . . . . 24

Queries for domain information . . . . . . . 24List all main nodes in a domain . . . . . . 25Count the number of entities in a domain . . . 26

Queries for main node information . . . . . . 28List all devices with class name and systemobject identifier . . . . . . . . . . . . 28List all IP addresses on all main node devices . . 30

Queries for containment information . . . . . . 32List all components on a device . . . . . . 32List all components on a device and showcomponent type . . . . . . . . . . . . 34Display the number of cards on each device . . 35Find all devices containing Three-Port GigabitEthernet cards . . . . . . . . . . . . 37Find entities within all cards. . . . . . . . 39

Queries for port and interface information . . . . 41List all interfaces on all devices. . . . . . . 41List all interfaces with specific attributes. . . . 42List all interfaces on all devices with interfacetype . . . . . . . . . . . . . . . . 43List all IP addresses and the interfaces thatimplement them . . . . . . . . . . . . 46

Queries for connectivity information . . . . . . 48

Types of connectivity . . . . . . . . . . 49Hierarchy modeling with the networkPipe andpipeComposition tables . . . . . . . . . 50Find devices connected to a named device . . . 50Find all devices connected to a named devicetogether with connecting interfaces . . . . . 52Identify all connections between routers . . . . 55

Queries for LTE network information. . . . . . 56Find specific LTE entity types . . . . . . . 56

Queries for MPLS Traffic Engineered Tunnelinformation . . . . . . . . . . . . . . 58

List all Traffic Engineered tunnels . . . . . . 59Show interfaces utilized by Traffic Engineeredtunnels . . . . . . . . . . . . . . . 59Show Traffic Engineered tunnel configuration . . 60List supporting routers for a Traffic Engineeredtunnel . . . . . . . . . . . . . . . 60Show performance data for a Traffic Engineeredtunnel . . . . . . . . . . . . . . . 61

Queries for Radio Access Network information . . 62Find specific RAN entity types . . . . . . . 62Retrieve RAN connectivity . . . . . . . . 63Find RAN containment . . . . . . . . . 72Find RAN dependencies . . . . . . . . . 74

Queries for hosted services . . . . . . . . . 76Find all chassis devices hosting OSPF services . . 76

Queries for collection information . . . . . . . 77Show all PIM adjacencies . . . . . . . . . 77Show PIM adjacencies for a device . . . . . 77Find PIM enabled routers. . . . . . . . . 77Find all devices in each subnet . . . . . . . 78Find all devices in a given VPN . . . . . . 79

Queries for mapping and enumeration information 80Identify all the device hardware manufacturerslisted in the database . . . . . . . . . . 80Show all the entity types defined in the database 82

Extending NCIM . . . . . . . . . . . . 83Example of extending the database . . . . . 84Enabling polling and visualization using thecustom tags . . . . . . . . . . . . . 84Enabling visualization of custom attributes inTopoviz. . . . . . . . . . . . . . . 86

Chapter 4. NCIM topology databaseschemas . . . . . . . . . . . . . . 89Core schema . . . . . . . . . . . . . . 89Data schema . . . . . . . . . . . . . . 91

BGP . . . . . . . . . . . . . . . . 92Collections . . . . . . . . . . . . . 93Containment . . . . . . . . . . . . . 94Endpoints . . . . . . . . . . . . . . 95Geographical location . . . . . . . . . . 96IP endpoints . . . . . . . . . . . . . 97LTE . . . . . . . . . . . . . . . . 98MPLS traffic engineered (TE) tunnels . . . . 110

© Copyright IBM Corp. 2006, 2015 iii

MPLS VPNs . . . . . . . . . . . . . 111OSPF . . . . . . . . . . . . . . . 112Services . . . . . . . . . . . . . . 113UMTS and GSM . . . . . . . . . . . 114VLANs . . . . . . . . . . . . . . 120

Chapter 5. Data dictionary . . . . . . 123Core tables . . . . . . . . . . . . . . 123

aggregatedLink. . . . . . . . . . . . 124aggregationDomain . . . . . . . . . . 124CIDRinfo . . . . . . . . . . . . . . 125classMembers . . . . . . . . . . . . 126collects . . . . . . . . . . . . . . 127connectActions . . . . . . . . . . . . 127connects . . . . . . . . . . . . . . 128connectSpeeds . . . . . . . . . . . . 129contains . . . . . . . . . . . . . . 130dependency . . . . . . . . . . . . . 131deviceFunction . . . . . . . . . . . . 131discoverySource . . . . . . . . . . . 132domainMembers . . . . . . . . . . . 133domainMgr . . . . . . . . . . . . . 133entityActions . . . . . . . . . . . . 135entityClass . . . . . . . . . . . . . 135entityData . . . . . . . . . . . . . 136entityDetails . . . . . . . . . . . . . 138entityNameCache . . . . . . . . . . . 139entityType . . . . . . . . . . . . . 140enumerations . . . . . . . . . . . . 141hostedService . . . . . . . . . . . . 143manager . . . . . . . . . . . . . . 144mappings . . . . . . . . . . . . . 144networkPipe. . . . . . . . . . . . . 145notes . . . . . . . . . . . . . . . 146pipeComposition . . . . . . . . . . . 146protocolEndPoint . . . . . . . . . . . 147topologyLinks . . . . . . . . . . . . 148

Core views . . . . . . . . . . . . . . 149discoveryOverview . . . . . . . . . . 149entity . . . . . . . . . . . . . . . 151interfaceDomain . . . . . . . . . . . 152interfaces . . . . . . . . . . . . . . 152mainNodeDetails . . . . . . . . . . . 155interfaceDomain . . . . . . . . . . . 158

Entity attribute tables. . . . . . . . . . . 158aggregationGroup . . . . . . . . . . . 158antennaFunction . . . . . . . . . . . 160atmEndPoint . . . . . . . . . . . . 161bgpAutonomousSystem . . . . . . . . . 161bgpCluster . . . . . . . . . . . . . 162bgpEndPoint . . . . . . . . . . . . 162bgpNetwork. . . . . . . . . . . . . 165bgpRouteAttribute. . . . . . . . . . . 165bgpService . . . . . . . . . . . . . 167computerSystem . . . . . . . . . . . 168controlPlaneViewCollection. . . . . . . . 175cpu. . . . . . . . . . . . . . . . 175discoveryAttributes . . . . . . . . . . 175domainSummary . . . . . . . . . . . 176eirFunction . . . . . . . . . . . . . 176emsSystem . . . . . . . . . . . . . 178

enbFunction . . . . . . . . . . . . . 179eUtranCell . . . . . . . . . . . . . 180eUtranSector . . . . . . . . . . . . 182frameRelayEndPoint . . . . . . . . . . 183genericCollection . . . . . . . . . . . 183genericRange . . . . . . . . . . . . 184geographicLocation . . . . . . . . . . 184geographicRegion . . . . . . . . . . . 185globalVlan . . . . . . . . . . . . . 186hsrpGroup . . . . . . . . . . . . . 186hssFunction . . . . . . . . . . . . . 187igmpEndPoint . . . . . . . . . . . . 188igmpGroup . . . . . . . . . . . . . 190igmpService . . . . . . . . . . . . . 190ipConnection . . . . . . . . . . . . 191ipEndPoint . . . . . . . . . . . . . 191ipMRouteDownstream . . . . . . . . . 193ipMRouteEndPoint . . . . . . . . . . 194ipMRouteGroup . . . . . . . . . . . 195ipMRouteMdt . . . . . . . . . . . . 196ipMRouteService . . . . . . . . . . . 196ipMRouteSource . . . . . . . . . . . 197ipMRouteUpstream . . . . . . . . . . 197ipPath . . . . . . . . . . . . . . . 199itnmService . . . . . . . . . . . . . 199lagEndPoint . . . . . . . . . . . . . 200lingerTime . . . . . . . . . . . . . 201localVlan . . . . . . . . . . . . . . 201lteInterface . . . . . . . . . . . . . 202ltePool. . . . . . . . . . . . . . . 204managedStatus . . . . . . . . . . . . 205mmeFunction . . . . . . . . . . . . 206mplsTEService . . . . . . . . . . . . 207mplsTETunnel . . . . . . . . . . . . 208mplsTETunnelEndPoint . . . . . . . . . 209mplsTETunnelResource . . . . . . . . . 210mplsLSP . . . . . . . . . . . . . . 210multiplexer . . . . . . . . . . . . . 211netcoolAsmsRunning . . . . . . . . . . 211networkInterface . . . . . . . . . . . 211networkServiceEntityEndPoint. . . . . . . 215networkVpn . . . . . . . . . . . . . 215operatingSystem . . . . . . . . . . . 215ospfArea . . . . . . . . . . . . . . 219ospfEndPoint . . . . . . . . . . . . 219ospfNetworkLSA . . . . . . . . . . . 220ospfRoutingDomain . . . . . . . . . . 220ospfService . . . . . . . . . . . . . 221pcrfFunction. . . . . . . . . . . . . 221pgwFunction . . . . . . . . . . . . 223physicalBackplane . . . . . . . . . . . 224physicalCard . . . . . . . . . . . . 225physicalChassis. . . . . . . . . . . . 228physicalConnector . . . . . . . . . . . 232physicalFan . . . . . . . . . . . . . 233physicalOther . . . . . . . . . . . . 235physicalPowerSupply. . . . . . . . . . 237physicalSensor . . . . . . . . . . . . 238physicalSlot . . . . . . . . . . . . . 241pimEndpoint . . . . . . . . . . . . 242pimNetwork. . . . . . . . . . . . . 243

iv IBM Tivoli Network Manager IP Edition: Topology Database Reference

pimService . . . . . . . . . . . . . 243plmn . . . . . . . . . . . . . . . 244portEndPoint . . . . . . . . . . . . 245ranBaseStation . . . . . . . . . . . . 245ranBaseStationController . . . . . . . . 246ranCircuitSwitchedCore . . . . . . . . . 246ranGGSN. . . . . . . . . . . . . . 247ranGSMCell . . . . . . . . . . . . . 248ranLocationArea . . . . . . . . . . . 249ranMediaGateway . . . . . . . . . . . 249ranMobileSwitchingCentre . . . . . . . . 250ranMSS . . . . . . . . . . . . . . 250ranNodeB . . . . . . . . . . . . . 251ranNodeBLocalCell . . . . . . . . . . 251ranPacketControlUnit. . . . . . . . . . 252ranPacketSwitchedCore . . . . . . . . . 252ranRadioCore . . . . . . . . . . . . 253ranRadioNetworkController . . . . . . . 254ranRoutingArea . . . . . . . . . . . 254ranSector . . . . . . . . . . . . . . 255ranSGSN . . . . . . . . . . . . . . 255ranTransceiver . . . . . . . . . . . . 256ranUtranCell . . . . . . . . . . . . 256rtExportList . . . . . . . . . . . . . 257rtImportList . . . . . . . . . . . . . 257sgwFunction. . . . . . . . . . . . . 258snmpSystem. . . . . . . . . . . . . 259subnet . . . . . . . . . . . . . . . 260

trackingArea . . . . . . . . . . . . 260transmissionTp . . . . . . . . . . . . 261userPlaneViewCollection . . . . . . . . 262vlanCollection . . . . . . . . . . . . 262vlanTrunkEndPoint . . . . . . . . . . 262vpnRouteForwarding . . . . . . . . . . 263vpwsEndPoint . . . . . . . . . . . . 264vtpDomain . . . . . . . . . . . . . 264

Entity attribute views. . . . . . . . . . . 265backplane . . . . . . . . . . . . . 265chassis . . . . . . . . . . . . . . 266fan . . . . . . . . . . . . . . . . 270interface . . . . . . . . . . . . . . 271module . . . . . . . . . . . . . . 274other . . . . . . . . . . . . . . . 276psu . . . . . . . . . . . . . . . . 278sensor . . . . . . . . . . . . . . . 279slot . . . . . . . . . . . . . . . . 282sourceEms . . . . . . . . . . . . . 283

Common Data Model views . . . . . . . . 284

Appendix. Network Manager glossary 289

Notices . . . . . . . . . . . . . . 293Trademarks . . . . . . . . . . . . . . 295

Index . . . . . . . . . . . . . . . 297

Contents v

vi IBM Tivoli Network Manager IP Edition: Topology Database Reference

About this publication

IBM Tivoli Network Manager IP Edition provides detailed network discovery,device monitoring, topology visualization, and root cause analysis (RCA)capabilities. Network Manager can be extensively customized and configured tomanage different networks. Network Manager also provides extensive reportingfeatures, and integration with other IBM products, such as IBM Tivoli ApplicationDependency Discovery Manager, IBM Tivoli Business Service Manager and IBMSystems Director.

The IBM Tivoli Network Manager IP Edition Topology Database Reference describes theschemas of the database used for storing topology data in Network Manager.

Intended audienceThis publication is intended for system and network administrators who areresponsible for configuring IBM Tivoli Network Manager IP Edition.

IBM Tivoli Network Manager IP Edition works in conjunction with IBM TivoliNetcool/OMNIbus; this publication assumes that you understand how IBM TivoliNetcool/OMNIbus works. For more information on IBM Tivoli Netcool/OMNIbus,see the publications described in “Publications” on page viii.

What this publication contains

This publication contains the following sections:v Chapter 1, “NCIM topology database,” on page 1

Introduces the Network Connectivity and Inventory Model (NCIM) topologydatabase.

v Chapter 2, “About NCIM,” on page 3Provides an overview of the Network Connectivity and Inventory Model(NCIM) database.

v Chapter 3, “Topology database queries,” on page 21Provides sample SQL queries, which are based on real-world queries, as anexample of the kind of data that can be extracted, and as a basis for constructingfurther queries.

v Chapter 4, “NCIM topology database schemas,” on page 89Describes how the relationships between topology data are modelled.

v Chapter 5, “Data dictionary,” on page 123Describes the relational database tables that represent the topology model in theNCIM database.

© Copyright IBM Corp. 2006, 2015 vii

PublicationsThis section lists publications in the Network Manager library and relateddocuments. The section also describes how to access Tivoli publications online andhow to order Tivoli publications.

Your Network Manager library

The following documents are available in the Network Manager library:v IBM Tivoli Network Manager IP Edition Release Notes, GI11-9354-00

Gives important and late-breaking information about IBM Tivoli NetworkManager IP Edition. This publication is for deployers and administrators, andshould be read first.

v IBM Tivoli Network Manager Getting Started Guide, GI11-9353-00Describes how to set up IBM Tivoli Network Manager IP Edition after you haveinstalled the product. This guide describes how to start the product, make sure itis running correctly, and discover the network. Getting a good networkdiscovery is central to using Network Manager successfully. This guide describeshow to configure and monitor a first discovery, verify the results of thediscovery, configure a production discovery, and how to keep the networktopology up to date. Once you have an up-to-date network topology, this guidedescribes how to make the network topology available to Network Operators,and how to monitor the network. The essential tasks are covered in this shortguide, with references to the more detailed, optional, or advanced tasks andreference material in the rest of the documentation set.

v IBM Tivoli Network Manager IP Edition Product Overview, GC27-2759-00Gives an overview of IBM Tivoli Network Manager IP Edition. It describes theproduct architecture, components and functionality. This publication is foranyone interested in IBM Tivoli Network Manager IP Edition.

v IBM Tivoli Network Manager IP Edition Installation and Configuration Guide,SC27-2760-00Describes how to install IBM Tivoli Network Manager IP Edition. It alsodescribes necessary and optional post-installation configuration tasks. Thispublication is for administrators who need to install and set up IBM TivoliNetwork Manager IP Edition.

v IBM Tivoli Network Manager IP Edition Administration Guide, SC27-2761-00Describes administration tasks for IBM Tivoli Network Manager IP Edition, suchas how to administer processes, query databases and start and stop the product.This publication is for administrators who are responsible for the maintenanceand availability of IBM Tivoli Network Manager IP Edition.

v IBM Tivoli Network Manager IP Edition Discovery Guide, SC27-2762-00Describes how to use IBM Tivoli Network Manager IP Edition to discover yournetwork. This publication is for administrators who are responsible forconfiguring and running network discovery.

v IBM Tivoli Network Manager IP Edition Event Management Guide, SC27-2763-00Describes how to use IBM Tivoli Network Manager IP Edition to poll networkdevices, to configure the enrichment of events from network devices, and tomanage plug-ins to the Tivoli Netcool/OMNIbus Event Gateway, includingconfiguration of the RCA plug-in for root-cause analysis purposes. Thispublication is for administrators who are responsible for configuring andrunning network polling, event enrichment, root-cause analysis, and EventGateway plug-ins.

viii IBM Tivoli Network Manager IP Edition: Topology Database Reference

v IBM Tivoli Network Manager IP Edition Network Troubleshooting Guide,GC27-2765-00Describes how to use IBM Tivoli Network Manager IP Edition to troubleshootnetwork problems identified by the product. This publication is for networkoperators who are responsible for identifying or resolving network problems.

v IBM Tivoli Network Manager IP Edition Network Visualization Setup Guide,SC27-2764-00Describes how to configure the IBM Tivoli Network Manager IP Edition networkvisualization tools to give your network operators a customized workingenvironment. This publication is for product administrators or team leaders whoare responsible for facilitating the work of network operators.

v IBM Tivoli Network Manager IP Edition Management Database Reference,SC27-2767-00Describes the schemas of the component databases in IBM Tivoli NetworkManager IP Edition. This publication is for advanced users who need to querythe component databases directly.

v IBM Tivoli Network Manager IP Edition Topology Database Reference, SC27-2766-00Describes the schemas of the database used for storing topology data in IBMTivoli Network Manager IP Edition. This publication is for advanced users whoneed to query the topology database directly.

v IBM Tivoli Network Manager IP Edition Language Reference, SC27-2768-00Describes the system languages used by IBM Tivoli Network Manager IPEdition, such as the Stitcher language, and the Object Query Language. Thispublication is for advanced users who need to customize the operation of IBMTivoli Network Manager IP Edition.

v IBM Tivoli Network Manager IP Edition Perl API Guide, SC27-2769-00Describes the Perl modules that allow developers to write custom applicationsthat interact with the IBM Tivoli Network Manager IP Edition. Examples ofcustom applications that developers can write include Polling and DiscoveryAgents. This publication is for advanced Perl developers who need to write suchcustom applications.

v IBM Tivoli Monitoring for Tivoli Network Manager IP User's Guide, SC27-2770-00Provides information about installing and using IBM Tivoli Monitoring for IBMTivoli Network Manager IP Edition. This publication is for systemadministrators who install and use IBM Tivoli Monitoring for IBM TivoliNetwork Manager IP Edition to monitor and manage IBM Tivoli NetworkManager IP Edition resources.

Prerequisite publications

To use the information in this publication effectively, you must have someprerequisite knowledge, which you can obtain from the following publications:v IBM Tivoli Netcool/OMNIbus Installation and Deployment Guide, SC23-9680

Includes installation and upgrade procedures for Tivoli Netcool/OMNIbus, anddescribes how to configure security and component communications. Thepublication also includes examples of Tivoli Netcool/OMNIbus architectures anddescribes how to implement them.

v IBM Tivoli Netcool/OMNIbus User's Guide, SC23-9683Provides an overview of the desktop tools and describes the operator tasksrelated to event management using these tools.

v IBM Tivoli Netcool/OMNIbus Administration Guide, SC23-9681

About this publication ix

Describes how to perform administrative tasks using the TivoliNetcool/OMNIbus Administrator GUI, command-line tools, and process control.The publication also contains descriptions and examples of ObjectServer SQLsyntax and automations.

v IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide, SC23-9684Contains introductory and reference information about probes and gateways,including probe rules file syntax and gateway commands.

v IBM Tivoli Netcool/OMNIbus Web GUI Administration and User's Guide SC23-9682Describes how to perform administrative and event visualization tasks using theTivoli Netcool/OMNIbus Web GUI.

Accessing terminology online

The IBM Terminology Web site consolidates the terminology from IBM productlibraries in one convenient location. You can access the Terminology Web site at thefollowing Web address:

http://www.ibm.com/software/globalization/terminology

Accessing publications online

IBM posts publications for this and all other Tivoli products, as they becomeavailable and whenever they are updated, to the IBM Knowledge Center Web siteat:

http://www-01.ibm.com/support/knowledgecenter/

Network Manager documentation is located under the Cloud & SmarterInfrastructure node on that Web site.

Note: If you print PDF documents on other than letter-sized paper, set the optionin the File > Print window that allows your PDF reading application to printletter-sized pages on your local paper.

Ordering publications

You can order many Tivoli publications online at the following Web site:

http://www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss

You can also order by telephone by calling one of these numbers:v In the United States: 800-879-2755v In Canada: 800-426-4968

In other countries, contact your software account representative to order Tivolipublications. To locate the telephone number of your local representative, performthe following steps:1. Go to the following Web site:

http://www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss2. Select your country from the list and click Go. The Welcome to the IBM

Publications Center page is displayed for your country.3. On the left side of the page, click About this site to see an information page

that includes the telephone number of your local representative.

x IBM Tivoli Network Manager IP Edition: Topology Database Reference

http://www.ibm.com/software/globalization/terminology

http://www-01.ibm.com/support/knowledgecenter/



AccessibilityAccessibility features help users with a physical disability, such as restrictedmobility or limited vision, to use software products successfully.

Accessibility features

The following list includes the major accessibility features in Network Manager:v The console-based installer supports keyboard-only operation.v Network Manager provides the following features suitable for low vision users:

– All non-text content used in the GUI has associated alternative text.– Low-vision users can adjust the system display settings, including high

contrast mode, and can control the font sizes using the browser settings.– Color is not used as the only visual means of conveying information,

indicating an action, prompting a response, or distinguishing a visualelement.

v Network Manager provides the following features suitable for photosensitiveepileptic users:– Web pages do not contain anything that flashes more than two times in any

one second period.

The Network Manager Information Center is accessibility-enabled. The accessibilityfeatures of the information center are described in Accessibility and keyboardshortcuts in the information center.

Extra steps to configure Internet Explorer for accessibility

If you are using Internet Explorer as your web browser, you might need toperform extra configuration steps to enable accessibility features.

To enable high contrast mode, complete the following steps:1. Click Tools > Internet Options > Accessibility.2. Select all the check boxes in the Formatting section.

If clicking View > Text Size > Largest does not increase the font size, click Ctrl +and Ctrl -.

IBM® and accessibility

See the IBM Human Ability and Accessibility Center for more information aboutthe commitment that IBM has to accessibility.

Tivoli technical training

For Tivoli technical training information, refer to the following IBM TivoliEducation Web site:

http://www.ibm.com/software/tivoli/education

About this publication xi

http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.help.ic.doc/iehs36_accessibility.html

http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/topic/com.ibm.help.ic.doc/iehs36_accessibility.html

http://www.ibm.com/able

http://www.ibm.com/software/tivoli/education

Support and community informationUse IBM Support, Service Management Connect, and Tivoli user groups to connectwith IBM and get the help and information you need.

IBM Support

If you have a problem with your IBM software, you want to resolve it quickly. IBMprovides the following ways for you to obtain the support you need:

OnlineGo to the IBM Software Support site at http://www.ibm.com/software/support/probsub.html and follow the instructions.

IBM Support AssistantThe IBM Support Assistant (ISA) is a free local software serviceabilityworkbench that helps you resolve questions and problems with IBMsoftware products. The ISA provides quick access to support-relatedinformation and serviceability tools for problem determination. To installthe ISA software, go to http://www.ibm.com/software/support/isa

Tivoli user groups

Tivoli user groups are independent, user-run membership organizations thatprovide Tivoli users with information to assist them in the implementation ofTivoli Software solutions. Through these groups, members can share informationand learn from the knowledge and experience of other Tivoli users. Tivoli usergroups include the following members and groups:v 23,000+ membersv 144+ groups

Access the link for the Tivoli Users Group at www.tivoli-ug.org.

Service Management Connect

Access Service Management Connect at https://www.ibm.com/developerworks/servicemanagement/. Use Service Management Connect in the following ways:v Become involved with transparent development, an ongoing, open engagement

between other users and IBM developers of Tivoli products. You can access earlydesigns, sprint demonstrations, product roadmaps, and prerelease code.

v Connect one-on-one with the experts to collaborate and network about Tivoliand the (enter your community name here) community.

v Read blogs to benefit from the expertise and experience of others.v Use wikis and forums to collaborate with the broader user community.

xii IBM Tivoli Network Manager IP Edition: Topology Database Reference

http://www.ibm.com/software/support/probsub.html

http://www.ibm.com/software/support/probsub.html

http://www.ibm.com/software/support/isa

http://www.tivoli-ug.org

https://www.ibm.com/developerworks/servicemanagement/

https://www.ibm.com/developerworks/servicemanagement/

Conventions used in this publicationThis publication uses several conventions for special terms and actions andoperating system-dependent commands and paths.

Typeface conventions

This publication uses the following typeface conventions:

Bold

v Lowercase commands and mixed case commands that are otherwisedifficult to distinguish from surrounding text

v Interface controls (check boxes, push buttons, radio buttons, spinbuttons, fields, folders, icons, list boxes, items inside list boxes,multicolumn lists, containers, menu choices, menu names, tabs, propertysheets), labels (such as Tip:, and Operating system considerations:)

v Keywords and parameters in text

Italic

v Citations (examples: titles of publications, diskettes, and CDsv Words defined in text (example: a nonswitched line is called a

point-to-point line)v Emphasis of words and letters (words as words example: "Use the word

that to introduce a restrictive clause."; letters as letters example: "TheLUN address must start with the letter L.")

v New terms in text (except in a definition list): a view is a frame in aworkspace that contains data.

v Variables and values you must provide: ... where myname represents....

Monospace

v Examples and code examplesv File names, programming keywords, and other elements that are difficult

to distinguish from surrounding textv Message text and prompts addressed to the userv Text that the user must typev Values for arguments or command options

Bold monospace

v Command names, and names of macros and utilities that you can typeas commands

v Environment variable names in textv Keywordsv Parameter names in text: API structure parameters, command

parameters and arguments, and configuration parametersv Process namesv Registry variable names in textv Script names

About this publication xiii

Operating system-dependent variables and paths

This publication uses environment variables without platform-specific prefixes andsuffixes, unless the command applies only to specific platforms. For example, thedirectory where the Network Manager core components are installed is representedas NCHOME.

On UNIX systems, preface environment variables with the dollar sign $. Forexample, on UNIX, NCHOME is $NCHOME.

xiv IBM Tivoli Network Manager IP Edition: Topology Database Reference

Chapter 1. NCIM topology database

The Network Connectivity and Inventory Model (NCIM) topology database is arelational database that Network Manager uses to consolidate topology data aboutthe physical and logical composition of devices, layer 1, layer 2, and 3 connectivity,routing protocols and network technologies such as OSPF, BGP and MPLS Layer 3VPNs.

Usage considerations

This information about the NCIM database assumes that you are familiar withrelational databases. It also assumes that you are familiar with SQL querytechniques used to extract data from relational databases. You can use these querytechniques to query the NCIM database to obtain topology data. Expert users canmanipulate data in the NCIM database using insert, update, and delete statements.Related reference:“Techniques used in the SQL queries” on page 22The SQL query examples use a variety of techniques that are aimed at extractinginformation efficiently. Use this information to familiarize yourself with thetechniques used in SQL queries.

© Copyright IBM Corp. 2006, 2015 1

2 IBM Tivoli Network Manager IP Edition: Topology Database Reference

Chapter 2. About NCIM

Use this information to understand how NCIM works, what you can use NCIMfor, and the how the NCIM database is structured to store data, and supportqueries and extensibility.Related tasks:“Extending NCIM” on page 83To store custom data on entities, and enable network operators to view customdata in network maps, extend the NCIM database.

Topology database tasksYou can use the NCIM topology database to perform the tasks, such as extractingdata topology using SQL queries, exporting data from the topology database tothird-party applications, and including data from third-party sources and fromcustomized discoveries by extending the database.

Use the NCIM topology database to perform the following tasks:

Extracting dataYou can write SQL queries to extract topology data from NCIM. SQLqueries can be made using ncp_oql as well as using third-party tools.

Integrating with third-party applicationsYou can export data from the topology database to third-party applications.In order to do this, you must understand the structure of the database.

Extending the databaseYou can extend the database to include data from third-party sources andfrom customized discoveries. For example, discovery stitchers may beconfigured to look up customer details from a third-party source based onIP address.

Topology database architectureUse this information to understand how the NCIM topology database works.

The following figure shows how Network Manager populates NCIM, and showshow the topology data is shared and accessed by different processes withinNetwork Manager.


Network Manager populates NCIM by means of the Discovery engine, ncp_disco,and Topology Manager, ncp_model, processes.

The topology data in NCIM can be shared and accessed by the following processesand applications:

�1� TopoVizUsed for displaying topology maps.

�2� Structure BrowserUsed for navigating within the containment structure of devices in thetopology.

�3� Asset reportingUsed for asset reporting software.

�4� Integrations with third-party applicationsUsed for example provisioning software that requires regularly updatedtopology data from Network Manager. These activities require knowledgeof programming languages such as Java™ and Perl.

Network

StructureBrowser

NCIMtopologydatabase

Third party

SQLqueries

Assetreporting

TopoViz

NetworkManager

1

2

34

Figure 1. NCIM working with Network Manager


Topology database propertiesUse this information to understand how the NCIM topology database is structuredto store data, and support queries and extensibility.

NCIM data storage

The NCIM relational database are divided into core tables and attribute tables.Core tables define all entities within NCIM together with the relationships betweenthese entities. Attribute tables contain attribute data for each entity; they arespecific to Network Manager.

NCIM database structure

Base information for the discovered network resources and relationships is heldwithin the entityData table. Resource-specific attribute data is held inproduct-specific extension tables that typically have a foreign key relationship withthe core-model entityData table.

The NCIM topology database also holds meta-data in tables such as the mappings,enumerations, CIDRInfo and deviceFunction tables. You can query this data to getuseful, typically human-readable information for device attributes. For example,you can determine the user-friendly name of BGP AS numbers.

The NCIM topology database has been designed to be familiar to users who workwith the MODEL database in legacy object-oriented format. This is most apparentin the naming of NCIM relational database tables and fields. Where possible, thenaming is the same as that used in MODEL.

Multiple domain queries

NCIM allows multiple network domains to be stored in the databasesimultaneously. A domain is a scoped set of entities discovered and managed byan application, such as Network Manager.

A single SQL query on the NCIM database can extract data from multipledomains. This is in contrast to Object Query Language (OQL) queries on theTopology manager, ncp_model, topology database, which are able to extractinformation only from a single domain at a time.

Extensibility

The NCIM topology database can hold additional data that is collected during acustomized discovery. For example, discovery stitchers can be configured to lookup customer details from a third-party source based on an IP address. It is possibleto configure MODEL to populate NCIM with this additional data and to configureNCIM to store this additional data in the form of key-value pairs.

Continuing the example, you might configure NCIM to store a customer name andcustomer type, associated with each main node entity discovered. It is also possibleto modify NCIM to create new multicolumn tables and configure MODEL topopulate these tables following a customized discovery. These modifications enableNCIM to store more custom data. For example, you might want to store a set ofdata on each customer associated with an IP address.Related concepts:

Chapter 2. About NCIM 5

“Domains”A domain is a scoped set of entities that are discovered and managed by anapplication, such as Network Manager. NCIM holds entity data related to multipledomains.

Topology dataWhen the network is discovered, both core NCIM tables and entity attribute tablesare updated with topology data. These tables include Layer 1, Layer 2, Layer 3,device structure, routing protocol, containment, and technology-specificinformation.

The NCIM tables are not case-sensitive.

The core and entity attribute tables are listed in the data dictionary.

Data modeled by NCIM

NCIM models different types of network data, including the following:

IP networksNCIM models network devices and device connections within layer 2 andlayer 3 of the OSI model.

Optical networksNCIM models optical network devices within layer 1 of the OSI model.

Routing networksNCIM models routing networks based on routing protocols such as MPLS,BGP, and OSPF.

VLANsNCIM models Virtual Local Area Networks (VLANs).

Radio access networksNCIM models a variety of radio access networks (RANs), including GSM,UMTS, and LTE.

Related concepts:Chapter 5, “Data dictionary,” on page 123The NCIM topology database schema is made up of a set of relational databasetables that represent the topology model.

Domains and entitiesThe NCIM topology database models network domains and entities within thosedomains.

DomainsA domain is a scoped set of entities that are discovered and managed by anapplication, such as Network Manager. NCIM holds entity data related to multipledomains.

For more information on domains, see the IBM Tivoli Network Manager IP EditionNetwork Troubleshooting Guide and the IBM Tivoli Network Manager IP EditionInstallation and Configuration Guide.


EntitiesA Network Manager discovery returns many different types of entity. If youunderstand the entities that you might encounter, you can more easily restrict yourqueries to return only required information.

Basic information about discovered network resources is held within theentityData table. Resource-specific attribute data is held in product-specificextension tables that typically have a foreign key relationship with the core-modelentityData table. Information on relationships between discovered networkresources, such as containment and connectivity, is also held in tables, such as thecontains and connects tables.

Records in the entityData table are at least related to a given instance and thedomainMgr, manager, and domainMembers tables.

Discovered resources held in the entityData table can be any of the followingtypes:v Physical and logical entities, including devices and their physical and logical

characteristics, such as slots, cards, ports, and interfaces, and the relationshipsbetween them.

v Protocol end points represent protocol or technology-specific information that istypically associated with an entity representing a port or interface resource.

v Device collections, including MPLS VPNs, global VLANs and subnets.v Hosted services, including BGP and OSPF services hosted on a device.

Network Manager populates the database with information about discovered layer1, layer 2 and layer 3 entities. To uniquely identify entities as they are discovered,the NCIM database uses a unique key, entityId. The entityId column appears in alldatabase tables that reference entities.

For example, the entityId column appears in the core entityData table, as well asin the physicalChassis, networkInterface, and physicalPowerSupply tables.

The following table describes the discovery-related entities that are stored in theNCIM database.

Table 1. Network Manager entities

Entitytype Entity type name Category NCIM table Description

0 Unknown Element

1 Chassis Element physicalChassis Main node device.

2 Interface Element networkInterface Interfaces with entityType 2 can be discoveredand polled.

3 Logical Interface Element networkInterface Interfaces with entityType 3 are inferred but arenot directly accessible. Hot Standby RoutingProtocol (HSRP) virtual IP interfaces are anexample of logical interfaces.

4 Local VLAN Element localVlan VLAN port on a main node device.

5 Module Element physicalCard Card within a switch or router. The term module isused to avoid confusion with the term card whichis used in layer 1 networks.

6 PSU Element physicalPowerSupply

Power® supply unit within a main node device.


Table 1. Network Manager entities (continued)


7 Logical Collection Collection Examples of logical collections include MPLSVPNs, global VLANs and subnets. NCIM can alsomodel OSPF areas.

8 Daughter Card Element The child of a network card.

9 Fan Element physicalFan Fan component within a main node device.

10 Backplane Element physicalBackplane Backplane component within a main node device.Backplanes usually contain slot entities.

11 Slot Element physicalSlot Slot component within a main node device. Slotsusually contain module entities.

12 Sensor Element physicalSensor Sensor component within a main node device.

13 Virtual Router Element virtualRouter Represents a instance of a virtual router within achassis device.

14 CPU Element cpu Represents Central Processing Units (CPUs).

15 Subnet Collection subnet Logical collection that lists the IP address in aclass A, B, or C subnet.

16 Global VLAN Collection globalVlan Collection of VLAN entities across multiplechassis devices that combine to form a virtualnetwork.

17 VPN Collection networkVpn Logical collection of IP address collected within aVPN.

18 HSRP Group Collection hsrpGroup Represents an Hot Standby Routing Protocol(HSRP) group logical collection. The Cisco HRSPimplements a virtual router with its own IP andMAC addresses. This virtual router forms anHSRP group that consists of a number of realinterfaces, only one of which is active at anygiven time. The active interface forwards IP trafficthat is sent to the virtual router, and the otherinterfaces in the group stand by ready to becomeactive if the active interface fails.

19 Stack Element Collection of chassis devices as defined by theEntity MIB.

20 VRF Element vpnRouteForwarding

Represents a VPN routing and forwarding table.

21 OSPF RoutingDomain

Collection ospfRoutingDomain Represents an OSPF routing domain.

22 OSPF Service Service ospfService Represents an OSPF service running on a device.

23 OSPF Area Collection ospfArea Represents an OSPF area.

24 VTP Domain Collection vtpDomain Represents a VLAN trunking protocol domain.

25 Other Element physicalOther Stores attributes of a component whose entitytype the discovery was unable to determine. Thisoccurs if the physical entity class is known, butdoes not match any of the supported values.

26 BGP Service Service bgpService Represents a BGP service.

27 BGP AS Collection bgpAutonomousSystem

Represents a BGP autonomous system.

28 BGP Route Attribute bgpRouteAttribute Represents a BGP route.




29 BGP Cluster Collection bgpCluster Represents a BGP cluster.

30 BGP Network Service bgpNetwork Represents a BGP network.

31 ISIS Service Collection Represents an ISIS service.

32 ISIS Level Element Represents the ISIS level.

33 OSPF Pseudo-Node Element Represents an OSPF pseudo-node.

34 ITNM Service Collection itnmService The base type for other services such as ISISService.

35 MPLS TE Service Service mplsTEService Represents a Multi Protocol Label SwitchingTraffic Engineered (MPLS TE) service

36 MPLS TE Tunnel Element mplsTETunnel Represents an MPLS TE tunnel

37 MPLS TE Resource Element mplsTETunnelResource

Represents an MPLS TE resource

38 MPLS LSP Element mplsLSP Represents an MPLS Label Switch Path (LSP)

40 IP Connection Element ipConnection Represents a connection using TCP/IP.

41 PIM Service Service pimService Represents a Protocol Independent Multicast(PIM) service.

42 PIM Network Collection pimNetwork Represents a PIM network.

43 IPMRoute Service Service ipMRouteService Represents an IP Multicast Routing service.

44 IPMRouteUpstream

Element ipMRouteUpstream Stores the upstream (RPF) route statistics for eachdevice or Multicast Distribution Tree (MDT).

45 IPMRouteDownstream

Element Stores the downstream route statistics per deviceor MDT.

46 IPMRouteMdt Collection ipMRouteMdt Stores the Collection entities representing theMDTs for each Multicast Source or Group.

47 IPMRouteSource Element ipMRouteSource Represents Multicast Sources, as contained by theMDT.

48 IPMRouteGroup Element ipMRouteGroup Represents Multicast Groups, as contained by theMDT.

49 IP Path Collection ipPath Represents a network path between IP devices.

50 IP End point ProtocolEndpoint

ipEndPoint Represents a logical IP end point that isimplemented by a physical interface.

51 VLAN Trunk Endpoint

ProtocolEndpoint

vlanTrunkEndPoint Represents a logical VLAN trunk end point that isimplemented by a physical interface.

52 Frame Relay Endpoint

ProtocolEndpoint

frameRelayEndPoint

Represents a logical Frame Relay end point that isimplemented by a physical interface.

53 OSPF End point ProtocolEndpoint

ospfEndPoint Represents a logical OSPF end point that isimplemented by a physical interface.

54 ATM End point ProtocolEndpoint

atmEndPoint Represents a logical ATM end point that isimplemented by a physical interface.

55 VPWS End point ProtocolEndpoint

vpwsEndPoint Represents a logical VPWS end point that isimplemented by a physical interface.

56 BGP End Point ProtocolEndpoint

bgpEndPoint Represents a logical BGP end point that isimplemented by a physical interface.




57 ISIS End Point ProtocolEndpoint

Represents a logical ISIS end point that isimplemented by a physical interface.

58 MPLS Tunnel EndPoint

ProtocolEndpoint

mplsTETunnelEndPoint

Represents a logical MPLS tunnel end point thatis implemented by a physical interface.

59 TCP/UDP EndPoint

ProtocolEndpoint

Represents a logical TCP/UDP end point that isimplemented by a physical interface.

60 PIM End Point ProtocolEndpoint

pimEndpoint Represents the Protocol Independent Multicast(PIM) end points discovered in the network andtheir associated attributes.

61 IPMRoute EndPoint

ProtocolEndpoint

ipMRouteEndPoint Stores information on the IP Multicast RoutingProtocol End Points.

62 IGMP End Point ProtocolEndpoint

igmpEndPoint Stores information on the Internet GroupMembership Protocol (IGMP) End Points.

63 Network ServiceEntity End Point

ProtocolEndpoint

networkServiceEntityEndPoint

Helps model relationships related to themanagement of frame relay links.

67 LAG End Point ProtocolEndpoint

lagEndPoint Represents a logical Link Aggregation Group(LAG) end point that is implemented by aphysical interface.

70 Topology Topology Grouping of connections which belong to atopology.

71 Layer 1 Topology Topology Grouping of connections which belong to a Layer1 topology.

72 Layer 2 Topology Topology Grouping of connections which belong to a Layer2 topology.

73 Layer 3 MeshedTopology

Topology Grouping of connections which belong to a Layer3 meshed topology.

74 ConvergedTopology (Layer 1 -Layer 3)

Topology Based on data available in NCIM, groups togetherconnections at the lowest layer for which data isavailable.

75 MPLS TE Topology Topology Grouping of connections which belong to anMPLS TE topology.

77 Pseudo WireTopology

Topology Grouping of connections which belong to aPseudo Wire topology.

78 OSPF Topology Topology Represents an OSPF topology.

79 BGP Topology Topology Represents a BGP topology.

80 IP Path Topology Topology ipPath Represents an IP path.

81 PIM Topology Topology Represents PIM topologies.

82 Local VLANTopology

Topology Represents local VLAN topologies.

83 IPMRoute Topology Topology Represents an IP Multicast Routing topology.

84 VPLS Pseudo WireTopology

Topology Respresents a VPLS Pseudo Wire Topology.

85 VirtualizationTopology

Topology Represents a virtualization topology.




86 MicrowaveTopology

Topology Represents a microwave topology.

87 RAN Topology Topology Represents a radio access network topology.

90 LTE Control Plane Topology Represents the devices and connectivity thatmake up the LTE control plane.

91 LTE User Plane Topology Represents the devices and connectivity thatmake up the LTE user plane.

110 Generic Collection Collection genericCollection A collection that is not of any other type.

111 GeographicLocation

Element geographicLocation Represents a geographic location.

112 Geographic Region Collection geographicRegion Represents a geographic region.

113 VLAN Ports Collection vlanCollection Represents a collection of the ports on a givennamed VLAN or, if no name is provided, on agiven VLAN identifier.

120 IGMP Service Service igmpService Represents an Internet Group ManagementProtocol (IGMP) service.

121 IGMP Groups Collection igmpGroup Stores multicast group collections for which thereare associated Internet Group MembershipProtocol (IGMP) end points in the igmpEndPointtable.

122 VSI (Virtual SwitchInstance)

Element virtualSwitchInstance

Represents a virtual switch instance (VSI)configured on a Provider Edge (PE) device that isassociated with a Virtual Private LAN Service(VPLS) Virtual Private Network (VPN) instance.

123 Data Center Element Represents a data center.

124 Virtual Cluster Collection virtualCluster Represents a cluster of virtual machines.

125 VirtualManagementService

Service virtualMgmtService Represents a virtual management service.

126 Hypervisor Element hypervisor Represents a hypervisor.

127 Port Group Collection portGroup Represents a port group.

128 EMS System Element emsSystem Represents an EMS system accessed by a collector.

130 RAN GSM Cell Element ranGSMCell Represents a GSM cell.

131 RAN UTRAN Cell Element ranUtranCell Represents a UTRAN cell.

132 RAN Sector Element ranSector Represents a RAN sector.

133 RAN NodeB LocalCell

Element ranNodeBLocalCell Represents a NodeB Local Cell.

134 RAN Location Area Collection ranLocationArea Represents a RAN Location Area.

135 RAN Routing Area Collection ranRoutingArea Represents a RAN Routing Area.

136 RAN Packet Core Collection Represents RAN packet switch core entity.

137 RAN Circuit Core Collection Represents a RAN circuit switched core entity.

138 RAN Radio Core Collection ranRadioCore Represents a RAN radio core entity.

139 RAN Transceiver Collection ranTransceiver Represents a RAN transceiver.




150 LTE Sector Element eUtranSector Represents a geographic area of radio coverageand is implemented and supported by physicalradio equipment. An LTE sector implements oneor more LTE cells.

151 LTE Cell Element eUtranCell Represents a geographical area of radio coverageand is implemented and supported by physicalradio equipment, such as towers, amplifiers, andantennas.

152 MME Function Element mmeFunction The Mobility Management Entity (MME) is themain signalling control element in the corenetwork and is the key control node for enablinguser equipment access to the core network. Therole of the MME is implemented within anetwork hardware node and is modelled byNCIM using the mmeFunction entity type.Multiple mmeFunction instances can beimplemented within a single network hardwarenode.

153 Tracking Area Collection trackingArea Represents an LTE tracking area.

154 SGW Function Element sgwFunction The Serving Gateway (SGW) resides in the userplane where it forwards and routes packets toand from the eNodeB and packet data networkgateway (PGW). The role of the SGW isimplemented within a network hardware nodeand is modelled by NCIM using the sgwFunctionentity type. Multiple sgwFunction instances canbe implemented within a single networkhardware node.

155 PGW Function Element pgwFunction The Packet Data Network Gateway (PGW)provides user plane connectivity to packet datanetworks. The role of the PGW is implementedwithin a network hardware node and is modelledby NCIM using the pgwFunction entity type.Multiple pgwFunction instances can beimplemented within a single network hardwarenode.

156 ENB Function Element enbFunction The eNodeB device manages the radio airinterface communication with users of the LTEnetwork. Each eNodeB device controls one ormore cells, which are geographic areas of radiocoverage. The role of the eNodeB is implementedwithin a network hardware node and is modelledby NCIM using the enbFunction entity type.Multiple enbFunction instances may beimplemented within a single network hardwarenode.

157 LTE Pool Collection ltePool Generic modelling mechanism for groups ofpooled LTE entities, and currently used to modelMME pools, PGW pools, and SGW pools. As anexample, in order to model an MME pool, therelationship between the ltePool entity andassociated mmeFunction entities is modelledusing the collects table.




158 PLMN Element plmn Models a Public Land Mobile Network (PLMN).A PLMN is a network that provides land mobiletelecommunications services to the public. Eachoperator providing mobile services has its ownPLMN.

159 HSS Function Element hssFunction Models the LTE Home Subscriber Service (HSS).The HSS manages subscriber identities, serviceprofiles, authentication, authorization, and qualityof service (QoS), and acts as the master repositoryfor subscriber profiles, device profiles and stateinformation.

160 PCRF Function Element pcrfFunction Models the LTE Policy and Charging RulesFunction (PCRF). The PCRF manages the policyand charging for uplink and downlink serviceflows and the permitted EPS bearer QoS.

161 EIR Function Element eirFunction Models the LTE Equipment Identity Register(EIR). The EIR keeps track of mobile deviceswhich should either be banned from using thenetwork or monitored. When a mobile phone isstolen its identity it is added to the EIR blacklistand the result is that this phone will never beable to attach to the network for service. Usuallyeach network has its own EIR which is oftencombined with the HSS node. It is possible formultiple operators to share a common EIR whichenables the blacklisted information to be moreeasily and widely available.

163 LTE Control Plane CollectioncontrolPlaneViewCollection

Supports the dynamic collection views under LTENetwork Topology > Control Plane by TrackingArea in the Network Views. Each instance of thisentity type collects the eNodeBs in thecorresponding tracking area, together with thedevices that these eNodeBs are connected to onthe control plane.

164 LTE User Plane CollectionuserPlaneViewCollection

Supports the dynamic collection views under LTENetwork Topology > User Plane by TrackingArea in the Network Views. Each instance of thisentity type collects the eNodeBs in thecorresponding tracking area, together with thedevices that these eNodeBs are connected to onthe user plane.

170 Aggregated Link Collection aggregatedLink Represents a network link between LinkAggregation Groups (LAGs)

171 Link AggregationGroup

Element aggregationGroup

Represents a Link Aggregation Group (LAG).

Related reference:“entityType” on page 140The entityType table provides a comprehensive list of every entity type in NCIM.It belongs to the category entities.


entityData table and entity viewInformation on entities is held in the entityData table in Network Managerversions 3.9 and later. This table replaces the entity table used in earlier versions.To ensure backward compatibility an entity view has been created to hold thesame data as the entity table from earlier versions.

The difference between the entityData table and the earlier entity table is thatentities in the entityData can be members of more than one domain. In versions 3.8and earlier, an entity in the entity table could only be a member of a singledomain.

In order to facilitate this, the domainMgrId field that was in the earlier entitytables does not appear in the entityData table. Instead, in versions 3.9 and later anew domainMembers table maps entityId values from the entityData table to thedomainMgrId values from the domainMgr table. This enables a single entity to bea member of multiple domains.

In versions 3.9 and later the entity view is created by joining the two tables,entityData and domainMembers.Related reference:“domainMembers” on page 133The domainMembers table stores information on membership of entities withindomains. This table belongs to the category domains.“domainMgr” on page 133The domainMgr table stores data on network domains. This table belongs to thecategory domains.“entity” on page 151The entity view joins data from the entityData and domainMembers tables and isequivalent to the entity table that existed in Network Manager versions 3.8 andearlier.The entity view stores data on entities and includes the domainMgrId,which the domain in which the entity is located.“entityData” on page 136The entityData table stores data on entities. This table belongs to the categoryentities.

Protocol-specific dataDevice entities, usually interfaces, can be associated with protocol-specific data.One example is the association of a device interface with the IP addressing data.Ports and interfaces can also be associated with other data, including ATM, BGPand OSPF protocol endpoints.

NCIM associates protocol-specific information with entities such as interfaces,using protocol endpoint tables. Examples of protocol endpoint tables are theatmEndPoint and ipEndPoint tables.


Technology-specific dataNCIM models a range of different network technologies, including IP, VLANs, andMPLS VLANs.Related reference:“ipEndPoint” on page 191The ipEndPoint table represents an IP end point and includes relevant data. Theendpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.

RelationshipsThe NCIM topology database models relationships between entities.

Connectivity dataConnectivity data defines how entities are connected in the network. It includesconnections between different devices, and VLAN-related connections within thesame device. Connectivity information is stored in the topologyLinks, networkPipe,and pipeComposition tables.

Bidirectional connections are only entered into the database once, either from the“A” end to the “Z” end or from the “Z” end to the “A” end. Therefore, SQLqueries that extract connectivity data must check for the connection in eitherdirection.

Representation of connectivity at different layers of the topology

The NCIM database represents the connectivity of entities in different independentlayers. Therefore representation of connectivity at layer 2 is representedindependently of the connectivity at layer 3. Each connection is associated with atopology entity.

Representation of connectivity within sub-topologies

The NCIM database represents complex connectivity scenarios. For example,within the MPLS VPN realm, NCIM can model the layer 3 connection between aprovider-edge (PE) router and multiple customer-edge (CE) routers. Connectivitybetween multiple devices that form a mini-topology is defined in thetopologyLinks table.Related reference:“Find devices connected to a named device” on page 50This query identifies all main node devices connected to a single specified mainnode device.

Containment dataContainment data defines logical and physical containment within your network.A containment model is generated at the end of the discovery process when thenetwork topology is created. This model reflects the real-world topology of thenetwork that is being modelled, in a physical, logical or business-oriented sense.

Overview of containment

Containment is a key principle of the network model. Containers are objects thatcan "hold" both elements and other containers. Elements and containers canrepresent logical or physical entities. You can put any object within a container andeven mix different objects within the same container.


An example of physical containment is a chassis containing network interface cards;the network interface cards can themselves contain individual ports. An exampleof logical containment is a set of ports or interfaces being contained by a particularVLAN. Network Manager also uses VLAN objects to model containment. VLANobjects are created by the stitchers. They contain all the interfaces that exist on eachVLAN.

Use of the containment model

When generated, the default containment model represents both physical andlogical containment:v The physical containment model enables you to perform device management

down to the port level.v The logical containment model shows how objects are contained within logical

containers that do not necessarily exist in the physical sense. One example is aVLAN container, which is a logical grouping of devices, cards, and ports that arenot necessarily physically connected together or in the same location. Thedefault logical containment model is based on VLAN containment.

VLAN naming:

Network Manager uses different naming conventions. One approach is to identifythe entity name, card and port numbers of specific ports, in the format EntityName[ card [ port ] ].

For example, port 12 on card 1 of chassis A is identified as A[ 1 [ 12 ] ].

By using stitchers, VLAN names can also be modified to reflect the businesscontext in which a given VLAN is used.

The naming used also depends on configuration of the product. This means thatinterface naming might be used; for example, Se4/0.

VLAN trunking:

When traffic from different VLANs is passed along a single trunk link betweenswitches, this is represented in the Network Manager containment model.

The following figure shows how the containment model represents this traffic.

1 2 33

Switch

VLAN 1 VLAN 2 VLAN 3

34

Figure 2. Logical sub-interfaces contained within a trunk port


If a port is being used for a trunk link, it contains logical sub-interfaces. Thefollowing information describes the properties of the ports and sub-interfacesshown in Figure 2 on page 16:

�1� A sub-interface connecting VLAN 2 on the switch to VLAN 2 on anotherswitch. Sub-interfaces are contained by trunk ports.�2� A sub-interface connecting VLAN 3 on the switch to VLAN 3 on anotherswitch. Sub-interfaces have no upward connections to their containing trunkport.�3� A normal port.�4� A port containing sub-interfaces.

Customization of the containment model:

The containment model can be customized. This customization is an advancedfeature of the discovery process. To generate a custom containment model, youmust either modify the existing stitchers, or write a new stitcher and configure theexisting stitchers to run the new stitcher during the creation of the networktopology.

Two example stitchers, ExampleContainment1.stch and ExampleContainment2.stchare supplied to help you modify the containment model. These stitchers can beexecuted by removing the comments before the ExecuteStitcher(); statements inthe BuildContainment.stch stitcher.

These stitchers are stored in the following directory: $NCHOME/precision/disco/stitchers/.

For a syntax definition of the stitcher language, see the IBM Tivoli Network ManagerIP Edition Language Reference.

DependenciesWhen one entity in a system cannot meaningfully function without another entityit is said to be dependent. Dependencies can be defined by the containment model.A container can be dependent upon the objects it contains.

Network Manager applications take dependencies into account. The root-causeanalysis (RCA) engine (a plug-in to the Event Gateway, ncp_g_event), for example,can consider dependencies when performing root cause analysis of network faults.

Collection dataCollection data defines logical collections. Collections are defined in the collectstable. Examples of logical collections defined within NCIM include MPLS VPNs,global VLANs, and subnets.

NCIM can also model OSPF areas. Each row in the collects table holds a pair ofentity identifiers: the collecting entity, for example the VPN, and one of the entitieswithin that collecting entity.Related reference:“Find all devices in a given VPN” on page 79This query identifies all of the VPNs listed in the database. For each VPN thequery provides the name of that VPN and the list of IP addresses collected withinthat subnet. The IP address collected within a VPN might refer to main nodes orinterfaces; typically they refer to interfaces.


“collects” on page 127The collects table stores data on collections of entities, such as subnets and MPLSVPNs. This table belongs to the category collections.

Hosted servicesA hosted service is a service or application running on a specific device. Forexample, a device can host BGP or OSPF services. NCIM can also model the factthat a software application, is running on a workstation.Related reference:“Find all chassis devices hosting OSPF services” on page 76This query identifies all devices that are hosting OSPF services. These devices areserving as routers within an autonomous system (AS). Each device identified hasan IP address and a separate OSPF router IP address.

NCIM cache filesTopology updates are held in a set of files called the NCIM cache files.

There is one cache file for each type of update message and the name of eachcache file reflects the content. The format of each file matches the data in thencimCache database tables. The cache files are as follows:v NCHOME/var/precision/Store.Cache.ncimCache.collects.DOMAIN

v NCHOME/var/precision/Store.Cache.ncimCache.connectActions.DOMAIN

v NCHOME/var/precision/Store.Cache.ncimCache.connects.DOMAIN

v NCHOME/var/precision/Store.Cache.ncimCache.contains.DOMAIN

v NCHOME/var/precision/Store.Cache.ncimCache.dependency.DOMAIN

v NCHOME/var/precision/Store.Cache.ncimCache.domainMembers.DOMAIN

v NCHOME/var/precision/Store.Cache.ncimCache.entityActions.DOMAIN

v NCHOME/var/precision/Store.Cache.ncimCache.entityData.DOMAIN

v NCHOME/var/precision/Store.Cache.ncimCache.hostedService.DOMAIN

v NCHOME/var/precision/Store.Cache.ncimCache.lingerTime.DOMAIN

v NCHOME/var/precision/Store.Cache.ncimCache.managedStatus.DOMAIN

v NCHOME/var/precision/Store.Cache.ncimCache.networkPipe.DOMAIN

v NCHOME/var/precision/Store.Cache.ncimCache.pipeComposition.DOMAIN

v NCHOME/var/precision/Store.Cache.ncimCache.protocolEndPoint.DOMAIN

Where DOMAIN is the current domain.

SQL files for the NCIM schemaThe NCIM database schema is contained within several SQL files. The following isa list of SQL files that contain the schema.

The files are as follows:

DB2

$NCHOME/precision/scripts/sql/db2/createPrecisionMgmtTables.sql

$NCHOME/precision/scripts/sql/db2/createNetCoolCoreDb.sql

Oracle

$NCHOME/precision/scripts/sql/oracle/createPrecisionMgmtTables.sql


$NCHOME/precision/scripts/sql/oracle/createNetCoolCoreDb.sql

The schema files below are common to all database products.v $NCHOME/precision/scripts/sql/data/populateMappings.sql

v $NCHOME/precision/scripts/sql/data/populateEnumerations.sql

v $NCHOME/precision/scripts/sql/data/populateDeviceFunction.sql

v $NCHOME/precision/scripts/sql/data/populateDefaults.sql

The database schema specific to Network Manager is contained in thecreatePrecisionIPDb.sql file.

The directory location of the Network Manager database schema is as follows:

DB2

$NCHOME/precision/scripts/sql/db2/createPrecisionIPDb.sql

Oracle

$NCHOME/precision/scripts/sql/oracle/createPrecisionIPDb.sql

To better understand how to formulate queries for purposes of correlating,analyzing, or reporting data, you can view these files, but do not attempt tomodify them.


Chapter 3. Topology database queries

Use these sample SQL queries, which are based on real-world queries, as anexample of the kind of data that can be extracted, and as a basis for constructingfurther queries.

Different databases can require differently formed queries. Refer to your databasedocumentation for the required format of queries. This information assumes thatyou are familiar with SQL syntax. For more information about SQL, refer to anappropriate SQL tutorial or reference text.

Note: Earlier versions of this documentation contained a section on Extending theNCIM topology database. This section has now been replaced by the new topologyenrichment features. For more information see the Enriching the topology chapterwithin IBM Tivoli Network Manager IP Edition Discovery Guide.

Logging in to NCIMLog in to NCIM to run an SQL query that retrieves topology data.

To log in to NCIM using ncp_oql you must provide a valid NCIM user name andpassword. The default user name for the NCIM database user is ncim. The defaultpassword is ncim.

To log in to NCIM enter the following command:

ncp_oql -domain DOMAIN -service ncim -username USERNAME -password PASSWORD

Use the tabular display format capabilities of the ncp_oql command. The -tabularoption is useful when retrieving only a small number of columns. For moreinformation on the ncp_oql command, see the IBM Tivoli Network Manager IPEdition Administration Guide.

Formatting used in the SQL queriesThe SQL queries are formatted for readability.

The following formatting is used:v SQL keywords, such as SELECT and INNER JOIN, are presented in uppercase.v Code is spaced to aid scanning.v Each piece of data extracted by a SELECT statement is presented on a separate

line.v Capitalization is used within table and field names. For example, in the field

name mainNodeEntityId the M, E, and I are capitalized.

Note: Capitalization of table and field names is not required in the SQL queriesthat you submit to NCIM.


Techniques used in the SQL queriesThe SQL query examples use a variety of techniques that are aimed at extractinginformation efficiently. Use this information to familiarize yourself with thetechniques used in SQL queries.Related reference:“Find devices connected to a named device” on page 50This query identifies all main node devices connected to a single specified mainnode device.

Choice of driving tableOne of the most important design decisions when creating a query is the choice ofdriving table. The choice of driving table is particularly important for ensuring theefficiency of queries.

The driving table is the table from which rows of data are first selected. Data isthen added from other tables by joining these tables, initially to the driving table.Therefore, choose the driving table so that a minimum of rows are initiallyselected. This ensures that the query is as efficient as possible. In many of thesample queries, the driving table is the domainMgr table, as there are generallyvery few rows in this table. This is in contrast to the entityData table, whichgenerally holds tens or hundreds of thousands of rows.

AliasingAliasing is the use of a temporary name for a column, sub-query or table within aquery.

Common reasons for using aliasing include:v Brevity: For example, use e to refer to the entityData table.v Distinguishing between table data in a meaningful way: For example, use

eComponent to refer to the entityData table when extracting component datafrom this table. Use eMainNode to refer to the entityData table when extractingmain node data from the table.

Aliasing can also be applied to columns, functions, and subqueries. For example,aliasing can be used to rename a results column.

Table joinsUse table joins to combine records from one or more tables. Two types of table joinare used, INNER JOIN and OUTER JOIN.

OUTER JOINAn OUTER JOIN table join preserves all the rows in one or both tables,even when they do not have corresponding rows in the other tables beingqueried. An example of when an OUTER JOIN table join is useful is if youwant to retrieve all interface and IP addressing data where applicable,bearing in mind that some interfaces may not have IP addresses.Commonly used outer joins include:

LEFT OUTER JOINRetains all records from the left table even if the join predicatedoes not find any matching record in the right table.


RIGHT OUTER JOINRetains all records from the right table even if the join predicatedoes not find any matching record in the left table.

INNER JOINAn INNER JOIN table join between tables combines the records from oneor more tables based on a given join predicate to produce a record set thatincorporates rows and columns from each table included in the join.Typically, a common attribute, such as the NCIM entityId, is used toretrieve sets of associated records. For example, an inner join could be usedto retrieve all of the records that contain other resources by joining theentity.entityId and contains.containingEntityId attributes.

Use of specific fields and tables in queriesYou can write more efficient SQL queries by making careful use of certain strategicfields and tables.

mainNodeEntityId fieldThe mainNodeEntityId field in the entityData table specifies the main node of theentity. This field provides a shortcut to the main node for a particular entity,avoiding the need to traverse the entire containment tree.

The mainNodeEntityId field is relevant only for entities that are wholly containedwithin a single main node device. It therefore has a non-NULL value only forentities that are related to a single main node device, such as:v The main node itselfv Physical and logical device components, such as interfaces, modules, PSUs,

sensors, backplanes, and fansv Logical interfaces entities on the main node, such as IP endpoints and VLAN

trunk endpointsv Local VLANs, which are local VLAN entities contained within a single main

node device. The interfaces contained by this VLAN are constrained to onlythose interfaces contained within the main node device.

Entities that are related to multiple main node devices, such as VPNs and globalVLANs, have a NULL value in the mainNodeEntityId field.

To retrieve only the entities that are wholly contained within a single main nodedevice, use an INNER JOIN statement on the entityData table. This statementensures that only entities that have a non-NULL value in the mainNodeEntityIdfield are retrieved.

entityType fieldThe entityType field can be used in SQL queries to limit the type of componentdata that is retrieved.

For example, if you specify the entity type 2, which corresponds to interfaces, in anSQL query, only component data of the type "interface" is retrieved. The entitytype of each entity is specified in the entityType field of the entityData table.

Chapter 3. Topology database queries 23

Protocol endpoint tablesThe protocolEndPoint and ipEndPoint tables can be used in SQL queries toidentify the IP addresses that are implemented by the device interfaces.

protocolEndPointThis table associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. The mostcommon example of the contents of the protocolEndPoint table is a row ofdata that associates a device interface with the IP addressing dataassociated with that interface. The protocolEndPoint table refers toprotocol-specific information, such as IP addressing data, using an entityID.

ipEndPointThis table contains the IP addressing data.

Protocols other than IP have their own protocol endpoint tables, for example:v atmEndPoint table for ATMv bgpEndPoint for Border Gateway Protocol (BGP)v frameRelayEndPoint for Frame Relayv igmpEndPoint for Internet Group Multicast Protocol (IGMP)v ipmRouteEndPoint for IP Multicast routesv mplsTeTunnelEndPoint for Traffic Engineering tunnelsv OSPFEndPoint table for OSPFv pimEndPoint for Protocol Independent Multicastv portEndPoint for portsv vlanTrunkEndPoint table for VLAN trunksv vpwsEndPoint for Virtual Private Wire ServicesRelated reference:“protocolEndPoint” on page 147The protocolEndPoint table allows a higher-level connection to be defined in termsof lower-level connections. It associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. TheprotocolEndPoint table belongs to the category connectivity.

Queries for domain informationThese queries retrieve information relevant to an entire domain or multipledomains. A domain is a scoped set of entities discovered and managed by anapplication. Sample queries extract information on the number of devices in adomain, names of devices in a domain, and so on.

Tip: A single SQL query on the NCIM database can extract data from multipledomains, whereas queries on the MODEL topology database, which can extractinformation from only a single domain at a time.


List all main nodes in a domainThis query provides a list of all main nodes in the database for a specified domain,or for all domains. The query provides the entity ID of the main node togetherwith the entity name.

Entity IDThe unique primary key of the entity within the entityData table. This isan integer value assigned to the entity by the database. Entities are notonly main nodes. Entities include any device component present in thedatabase, and other items recorded in the database, such as collections oflogical or physical network elements, for example, VPNs and VLANs.

Entity nameA string value used to refer to the entity. If the entity is a device, then theentity name might be the IP address of the device or the device name.

Note: Entity names are unique only within a given domain.

Example

1]2]3]4]5]6]

SELECT e.entityId Entity_ID,e.entityName Device_Name

FROM domainMgr dINNER JOIN entity e ON e.domainMgrId = d.domainMgrIdWHERE d.domainName = ’NCOMS’AND e.entityType = 1

Description

The table below describes this query.

Table 2. Description of the query

Line numbers Description

1-2 Specify the data to show in the results as follows:

v The entity identifier of a main node device, represented by e.entityId.

v The entity name of the device, represented by e.entityName.

3 Specify the domainMgr table as the driving table for this query.

4 Retrieve all entities in each domain by joining the entity view. The INNERJOIN ensures that only entities that are associated to a domain (that is,with a valid domainMgrId field) are retrieved.

5 Restrict the results to entities within the NCOMS domain.Tip: To list all main node devices across all domains, omit this line fromthe query.

6 Restrict the entities to main nodes. Entities that have an entityType of 1 aremain nodes.

Results

The table below shows a portion of the results of this query.

Table 3. Results of the query

Entity ID Device name

1 192.168.15.23


Table 3. Results of the query (continued)

Entity ID Device name

3 192.168.15.7

5 192.168.15.21

72 VE002.example.net

74 172.20.4.20

77 172.20.4.16

83 172.50.0.2


109 10.1.254.7

143 10.1.254.30

269 10.1.1.9

Related reference:“Choice of driving table” on page 22One of the most important design decisions when creating a query is the choice ofdriving table. The choice of driving table is particularly important for ensuring theefficiency of queries.

Count the number of entities in a domainThis query counts the total number of entities in a domain. Entities include anydevice component present in the database, as well as other items recorded in thedatabase such as collections of logical or physical network elements, for example,VPNs and VLANs. This query returns a number indicating the number of entitiesin the domain.

Example

1]2]3]4]

SELECT COUNT(*)FROM domainMgr dINNER JOIN entity e ON e.domainMgrId = d.domainMgrIdWHERE d.domainName = ’NCOMS’

Description

The table below describes this query:


Linenumber(s) Description

1 Specify that we wish to count the number of rows returned by the query.Each entity returned by the query generates a row of results; therefore thenumber of rows returned corresponds to the number of entities in thedomain.


3-4 Retrieve all entities in the NCOMS domain, by joining the entity view.Restrict the domain to NCOMS by means of the WHERE statement.


Customizing the query

It is possible to customize this query to retrieve only entities of a specific type. Youcan find a complete listing of entity types by viewing the contents of theentityType table. To count the number of interfaces only in the domain, add thefollowing line to the query:AND e.entityType = 2

In this line e.entityType is the entityType field within the entity view. Theentity view is referred to using the alias e.

1]2]3]4]5]

SELECT COUNT(*)FROM domainMgr dINNER JOIN entity e ON e.domainMgrId = d.domainMgrIdWHERE d.domainName = ’NCOMS’AND e.entityType = 2

Description

The table below describes this customized query:

Table 5. Description of the customized query


1 Specify that you want to count the number of rows returned by the query.Each entity returned by the query generates a row of results; therefore thenumber of rows returned corresponds to the number of entities in thedomain.


3 Retrieve all entities in the NCOMS domain, by joining the entity view.

4 Restrict the results to entities within the NCOMS domain.

5 Restrict the entities returned by the query to interfaces. Entities with anentityType of 2 are interfaces.

Related reference:“Techniques used in the SQL queries” on page 22The SQL query examples use a variety of techniques that are aimed at extractinginformation efficiently. Use this information to familiarize yourself with thetechniques used in SQL queries.“Choice of driving table” on page 22One of the most important design decisions when creating a query is the choice ofdriving table. The choice of driving table is particularly important for ensuring theefficiency of queries.


Queries for main node informationThese sample queries retrieve data on main node devices.

List all devices with class name and system object identifierThis query retrieves all main node devices across all domains and, for each device,provides the class name of the device and the type of device.

Class nameThe manufacturer and product family of the device. For example,CiscoCat35xx is the Cisco Catalyst 3500 product family.

Type of deviceThe model number of the device within product family of themanufacturer. For example, catalyst3524XL is the Cisco Catalyst 3524XLGigabit Ethernet switch. The query determines the type of device byextracting the system object identifier (sysObjectId) value for the device.The sysObjectId field is held in the chassis table, which is one of thetables joined as part of the query. The system object identifier is a MIBvalue that provides the vendor's authoritative identification of the networkmanagement subsystem contained in the entity and serves as easy andunambiguous means for determining the type of device.

You can convert the system object identifier (for example, (1.3.6.1.4.1.9.1.248) intohuman-readable text (for example, catalyst3524XL), by using an OUTER JOINstatement to join the mappings table to the query. Within the mappings table, thesysObjectId mapping group lists system object identifier strings and theircorresponding human-readable string values. The mappings table providesstring-to-string mappings, unlike the enumerations table, which providesinteger-to-string mappings.

If no entry exists in the mappings table for a specific system object identifier, thequery returns a NULL value for the device type. Use of an OUTER JOIN statementenables you to perform this conversion without losing any rows of main nodedata. If no string exists for any particular system object identifier, the OUTER JOINstatement ensures that you nevertheless do not lose the row of data for the mainnode device associated with that system object identifier.

Example

1]2]3]4]5]6]7]8]9]10]11]12]

SELECT e.entityName Entity_Name,ec.className Class_Name,s.sysObjectId System_Object_ID,m.mappingValue Device_Type

FROM entityData eINNER JOIN physicalChassis c ON c.entityId = e.entityIdINNER JOIN snmpSystem s ON s.entityId = e.entityIdINNER JOIN classMembers cm ON cm.entityId = e.entityIdINNER JOIN entityClass ec ON ec.classId = cm.classIdLEFT OUTER JOIN mappings m ON m.mappingGroup = ’sysObjectId’

AND m.mappingKey = s.sysObjectIdORDER BY ec.className, s.sysObjectId

The following table describes this query:




1-4 Specify the data to show in the results, as follows:

v The entity name of a device, represented by e.entityName.

v The class name of the device, indicating the manufacturer and productfamily. This is represented by ec.className, where ec is the alias used torefer to the entityClass table.

v The system object identifier for this device, represented by s.sysObjectId.(SNMP devices only)

v The device type, based on a lookup of the system object identifier in themappings table. This is represented by m.mappingValue.

5 Use the entityData table as the driving table for this query.

6 Limit the results of the query to main node devices, by joining thephysicalChassis table to the entityData table. There is now a line of datafor each main node device. Use an INNER JOIN statement to ensure thatonly entities that are main node devices are retrieved.

7 For SNMP devices determine the System Object ID.

8 Determine the class to which the device belongs. This is a two-stepprocess. The first step, shown in this line, is to use an INNER JOINstatement to the classMembers table to retrieve the classId value for theclass to which the device belongs.

9 Use the classId retrieved in line 7 as a lookup to determine the name of theclass to which the device belongs. Do this by performing an INNER JOINstatement with the entityClass table. The entityClass table holds classdetails, including class names, and the name of the superclass, thecontaining class in the class hierarchy.

10-11 Look up the system object identifier in the mappings table in order toobtain a human-readable string for the device type. Do this by performinga join on the mappings table. Use an OUTER JOIN statement to enable youto perform this join without losing any rows of main node data. If nostring exists for any particular system object identifier, the OUTER JOINstatement ensures that you nevertheless do not lose the row of data for themain node device associated with that system object identifier.

12 Order the query results for maximum readability. In order to do this listthe devices first by manufacturer and product family (classname) and thenby model (system object identifier).

Results

The table below shows a portion of the results of the query.


Entity name Class name System object ID Device type

192.168.15.23 3ComSuperStack 1.3.6.1.4.1.43.10.27.4.1.2.2

3Com SuperStack II

192.168.15.7 3ComSuperStack 1.3.6.1.4.1.43.10.27.4.1.2.2

3Com SuperStack II

172.20.4.16 Cisco26xx 1.3.6.1.4.1.9.1.185 cisco2610

10.1.1.8 Cisco26xx 1.3.6.1.4.1.9.1.186 cisco2611

10.1.1.9 Cisco26xx 1.3.6.1.4.1.9.1.209 cisco2621

172.20.4.15 Cisco36xx 1.3.6.1.4.1.9.1.122 cisco3620



Entity name Class name System object ID Device type

10.1.254.1 Cisco72xx 1.3.6.1.4.1.9.1.222 cisco7206VXR

172.18.1.151 CiscoCat35xx 1.3.6.1.4.1.9.1.247 catalyst3512XL

172.18.1.203 CiscoCat35xx 1.3.6.1.4.1.9.1.248 catalyst3524XL

172.20.1.41 HuaweiARxx 1.3.6.1.4.1.2011.1.1.1.12809

NULL

10.1.1.5 MarconiASX 1.3.6.1.4.1.326.2.2.5 NULL

192.168.32.13 Sun 1.3.6.1.4.1.42 NULL

192.168.34.199

Sun 1.3.6.1.4.1.42.2.1.1 SunMicrosystemsServers

192.168.15.4 Windows 1.3.6.1.4.1.311.1.1.3.1.2 MicrosoftWindowsServer

List all IP addresses on all main node devicesThis query retrieves all IP addresses on all main node devices. For each IP address,the query lists the entity that implements the IP address. This entity is usually aninterface, but under certain conditions the IP address might be implemented by themain node itself.

This query lists the IP addresses implemented by each interface identified on amain node or by the main node itself. If an interface does not implement an IPaddress, that interface is not returned by this query.

Note: IP end points might be present on interfaces and on any of the followingmain nodes:v Main nodes with no SNMP accessv Inferred chassisv NAT-translated chassis

Example

1]2]3]4]5]6]7]8]9]10]

SELECT e.entityId Implementing_Entity_ID,eMainNode.entityName Main_Node_Name,e.entityName Implementing_Entity_Name,ip.address IP_Address

FROM entityData eINNER JOIN entityData eMainNode ON eMainNode.entityId =

e.mainNodeEntityIdINNER JOIN protocolEndPoint p ON p.implementingEntityId = e.entityIdINNER JOIN ipEndPoint ip ON ip.entityId = p.endPointEntityIdORDER BY e.entityId


Description





v The unique entity ID of the interface within the topology database,represented by e.entityId

v The name of a main node device, represented by eMainNode.entityName

v The name of the interface, represented by e.entityName

v An IP address implemented by this interface, represented by ip.address

5 Use the entityData table as the driving table for this query. Use the alias efor the entityData table.

6-7 Identify the containing main node device for each of the entities retrievedin the preceding line.

Do this by joining the entityData table to itself using the mainNodeEntityIdfield.

8-9 Identify the IP addresses implemented by each of the entities identified inline 5 of the query.

Do this by performing an INNER JOIN statement on the protocolEndPointtable to extract the entity ID for any protocol-specific informationassociated with the entities identified in line 5.

Then perform a second INNER JOIN statement on the ipEndPoint table tolimit the protocol-specific information returned by the query to IPinformation.

10 To facilitate readability of the results, order first by the unique entity ID ofthe interface.

Results

The table below shows the results of this query.


Implementing EntityID Main Node Name

Implementing EntityName IP Address

270 172.20.4.11 172.20.4.11[0[5]] 172.50.0.2

338 172.18.1.196 172.18.1.196[0[2]] 172.50.0.3

366 172.18.1.54 172.18.1.54[0[2]] 172.50.0.4

370 172.18.1.54 172.18.1.54[0[1]] 172.50.0.5

373 172.20.4.13 172.20.4.13[0[1]] 172.50.0.6

377 172.20.4.20 172.20.4.20[0[1]] 172.50.0.7

417 192.168.139.7 192.168.139.7[ 0 [5 ] ]

172.20.11.1

417 192.168.139.7 192.168.139.7[ 0 [5 ] ]

172.20.1.2


Queries for containment informationThese queries retrieve data on logical and physical containment within yournetwork.

The containment model can reflect the real world topology of the network that isbeing modelled, in a physical, logical or business-oriented sense. Logicalcontainment includes the definition of local VLAN objects and VLAN trunkswithin main nodes.

The following sample queries extract containment information.

List all components on a deviceThis query retrieves all components on a named device, and lists each component.The query lists the components by entity ID and displays the name of thecomponent. All components are displayed, regardless of their type.

You can run this query in the following ways, which specify the main node devicedifferently:v Using the device name (entityName) and the name of the domain in which the

device is located (domainName). The device name might be an IP address or atextual name and should be unique within a given domain. This query is shownbelow.

v You can also write this query using the entityId for the device within theentityData table. This field contains an integer value unique across all domains.

Note: The SQL query in this section uses meaningful table aliases, such aseComponent and eMainNode . This makes the query more readable by enablingyou to distinguish between different types of data from the same table.

Example

1]2]3]4]5]6]7]8]9]

SELECT eComponent.entityId Component_Entity_ID,eComponent.entityName Component_Name,eMainNode.entityName Main_Node_Name

FROM domainMgr dINNER JOIN entity eComponent ON eComponent.domainMgrId = d.domainMgrIdINNER JOIN entityData eMainNode ON eMainNode.entityId =

eComponent.mainNodeEntityIdWHERE eMainNode.entityName = ’VE004.example.net’AND d.domainName = ’NCOMS’;





v The entity ID of a component within the specified main node device,represented by eComponent.entityId.

v The name of a component, represented by eComponent.entityName.

v The name of the specified main node device, represented byeMainNode.entityName.

4 Use the domainMgr table as the driving table for this query.


Table 10. Description of the query (continued)


5 Retrieve data for all the entities in this domain by joining the entity viewto the query. This join retrieves all entities in the domain, including thosewholly contained within a single main node (required) as well as thoseentities related to multiple main nodes , such as VPNs and global VLANs(not required).

In this join, the entity view is aliased using a meaningful alias,eComponent. This alias indicates that the data retrieved from the entityview using this join is component data.

6-7 Identify the containing main node device for each of the entities by joiningthe entityData table to itself using the mainNodeEntityId field. Thisautomatically excludes those entities that are related to multiple main nodedevices, such as VPNs and global VLANs. These entities have a NULLvalue in the mainNodeEntityId field.

8-9 Limit the entities retrieved to those contained within the main nodeVE004.example.net and the domain to the NCOMS domain.

The table below describes the results of this query.


Comp-onententity ID Component name Main node name

83 VE004.example.net VE004.example.net

84 VLAN_trunk_1_VE004.example.net[0[26]]

VE004.example.net

2151 VE004.example.net[0[21]] VE004.example.net





2231 VE004.example.net[0[1]IP:192.168.32.65]

VE004.example.net


2233 VLAN_OBJECT_VE004.example.net_VLAN_1

VE004.example.net

3187 VE004.example.net_CARD_0 VE004.example.net

Related reference:“Aliasing” on page 22Aliasing is the use of a temporary name for a column, sub-query or table within aquery.“mainNodeEntityId field” on page 23The mainNodeEntityId field in the entityData table specifies the main node of theentity. This field provides a shortcut to the main node for a particular entity,avoiding the need to traverse the entire containment tree.


List all components on a device and show component typeThis query displays all the components on a device and also displays the type ofcomponent.

To determine the type of component, the query uses the entityType value for thedevice. The system object identifier is a numerical key that specifies the type ofentity. For example, an entityType value of 1 indicates a main node; an entityTypevalue of 2 indicates an interface.

The entityType table provides a comprehensive list of every entity type in NCIM.This query joins the entityType table to the query to extract the name of the entitytype for each component.

Example

1]2]3]4]5]6]7]8]9]10]11]

SELECT eComponent.entityId Component_Entity_ID,eComponent.entityName Component_Name,et.typeName Component_Type,eMainNode.entityName Main_Node_Name

FROM domainMgr dINNER JOIN entity eComponent ON eComponent.domainMgrId = d.domainMgrIdINNER JOIN entityData eMainNode ON eMainNode.entityId =

eComponent.mainNodeEntityIdINNER JOIN entityType et ON et.entityType = eComponent.entityTypeWHERE eMainNode.entityName = ’VE004.example.net’AND d.domainName = ’NCOMS’;

Description

The table below describes how the query determines the type of component.



3 In addition to the main node and component data, this query also retrievesthe component type of the component contained within the named device.This is represented by et.typeName.

9-10 Join the entityType table to extract data related to the entity type,including the name of the entity type for each component.

Results



Comp-onententity ID Component name Component type Main node name

83 VE004.example.net chassis VE004.example.net

84 VLAN_trunk_1_VE004.example.net[0[26]]

vlanTrunkEndPoint VE004.example.net

2151 VE004.example.net[0[21]] interface VE004.example.net



Comp-onententity ID Component name Component type Main node name





2231 VE004.example.net[0[1]IP:192.168.32.65]

ipEndPoint VE004.example.net


2233 VLAN_OBJECT_VE004.example.net_VLAN_1

localVlan VE004.example.net

3187 VE004.example.net_CARD_0 module VE004.example.net

Display the number of cards on each deviceThis query lists all of the main node devices in a domain and retrieves the numberof cards in each of these devices.

The query retrieves only devices that contain at least two cards; devices that haveno cards are not displayed.

Examples of cards include Three-Port Gigabit Ethernet cards, WAN interface cards,and mainboards cards.

Example

1]2]3]4]5]6]7]8]9]10]

SELECT eMainNode.entityName Main_Node_Entity_Name,COUNT(physicalCard.entityId) AS ’Number of Cards’

FROM domainMgr dINNER JOIN entity eCard ON eCard.domainMgrId = d.domainMgrIdINNER JOIN physicalCard ON physicalCard.entityId = eCard.entityIdINNER JOIN entityData eMainNode ON eMainNode.entityId =

eCard.mainNodeEntityIdWHERE d.domainName = ’NCOMS’GROUP BY eMainNode.entityIdHAVING count(physicalCard.entityId) > 1


Description





v The name of a main node device, represented by eMainNode.entityname

v The number of cards in that device, represented byCOUNT(physicalCard.entityId)

4-6 Join relevant tables to the domainMgr table in order to retrieve therequired data. The joins are as described in the next two rows.

4 Retrieve all the entities in each domain. The INNER JOIN clause ensures thatonly entities that have a valid domainMgrId field are retrieved.

5 From all the entities, extract only that subset of entities that are cards. Usean INNER JOIN statement to ensure that only entities that havecorresponding entries in the physicalCard table are retrieved. There is aline of data for each card. This line of data consists of all columns from thedomain table, the entity view, and the physicalCard table related to thatcard.

6-7 Identify the containing main node device for each of the cards by joiningthe entityData table to itself using the mainNodeEntityId field. The join onthis field enables the query to go directly to the top of the containmenttree.

8 Limit the resulting data to the main node devices in the NCOMS domainonly.

9 Group the results by the name of the main node device. This means thatthe results show the number of cards within each main node.

10 Use the HAVING clause to specify that you want to retrieve only devicesthat contain two or more cards.

Results

The table below shows a portion of the results for this query.


Main node entity name Number of cards

172.18.1.102 20

VE001.example.net 10

Related reference:“mainNodeEntityId field” on page 23The mainNodeEntityId field in the entityData table specifies the main node of theentity. This field provides a shortcut to the main node for a particular entity,avoiding the need to traverse the entire containment tree.


Find all devices containing Three-Port Gigabit Ethernet cardsThis query looks for specific containment information within a device. In thisexample, the query finds all main-node devices that contain a specific component:a Cisco Three-Port Gigabit Ethernet card.

This query also returns the following information about each Three-Port GigabitEthernet Card retrieved:v Serial number of the cardv Hardware revision of the cardv The physical position occupied within the main node device by the slot that

contains this card

Tip: To perform this type of query, you need to know the MIB OID of thecomponent contained within the device. In this example, you need to know thatthe OID of the Three-Port Gigabit Ethernet Card within the Cisco MIB is1.3.6.1.4.1.9.12.3.1.9.18.49.

Prerequisites

Before you run this query, you must have enabled the Entity agent to run duringthe discovery process. This enables the query to retrieve the required data. TheEntity agent discovers detailed containment information from the Entity MIB. Formore information about the Entity agent, see the IBM Tivoli Network Manager IPEdition Discovery Guide. By default the Entity agent is not configured to run duringdiscovery. You must therefore configure this agent manually if you want thetopology database to contain the detailed MIB information that is required forqueries of this type.

Example

1]2]3]4]5]6]7]8]9]10]11]12]13]

SELECT d.domainname Domain,e2.entityName Device_Name,c.serialnumber Serial_Number,c.hwRevision Hardware_Revision,s.relativePosition Slot_Number

FROM domainmgr dINNER JOIN entity e1 ON e1.domainmgrid = d.domainmgridINNER JOIN physicalCard c ON c.entityid = e1.entityidINNER JOIN entityData e2 ON e2.entityid = e1.mainnodeentityidINNER JOIN contains c2 ON c2.containedentityid = c.entityidINNER JOIN physicalSlot s ON s.entityid = c2.containingentityidWHERE c.vendorType = ’1.3.6.1.4.1.9.12.3.1.9.18.49’ORDER BY LOWER(d.domainname) ASC, LOWER(e2.entityName) ASC;


Description





v The domain to which the main node device belongs, represented byd.domainname

v The name of a main node device containing a Three-Port GigabitEthernet card, represented by e2.entityName

v The serial number of the Three-Port Gigabit Ethernet card, representedby c.serialnumber

v The hardware version of the Three-Port Gigabit Ethernet card,represented by c.hwRevision

v The slot occupied by the Three-Port Gigabit Ethernet card in the mainnode device, represented by s.relativePosition

7-11 Join relevant tables to the domainMgr table in order to retrieve the requireddata.

7 Retrieve all the entities in each domain. The INNER JOIN clause ensures thatonly entities that have a valid domainMgrId field are retrieved.

8 From all the entities, extract only that subset of entities that are cards. Carddata is held in the physicalCard table. There is a line of data for each card.This line of data consists of all columns from the domain table, the entityview, and the physicalCard tables related to that card.

9 For each card, obtain the name of the main node that contains that card.Do this by performing a second INNER JOIN statement on the entityDatatable to retrieve all the data for the main node that contains the card.

10-11 These two lines retrieve for each card, the physical position occupiedwithin the main node device by the slot that contains that card.

10 The query has so far extracted all cards in the database, together with lineof relevant data for each card. From all these cards, extract only thosecards that are contained within another entity. Do this by performing anINNER JOIN statement between the physicalCard table and the containstable. This INNER JOIN statement also retrieves the containingEntityIdcolumn values, which are the IDs of the entities containing the cards.

11 For each card, obtain data for the slot that contains the card. Do this byperforming an INNER JOIN statement between the physicalSlot table andthe contains table to retrieve all the data for the main node that containsthe card. This limits the results to only those cards which are containedwithin slots.

12 Limit the resulting data to those cards that have an OID of1.3.6.1.4.1.9.12.3.1.9.18.49. This OID corresponds to the MIB variablecevGsr3ge, which is the MIB variable for the Cisco Three-Port GigabitEthernet Card.

13 For readability purposes, order the results first by domain and then byname of the main node device.


Results

The following table shows an example of the results of this query.


Domain Device name Serial number Hardware revisionSlotnumber

NCOMS VE001.example.net

SAD06A400WY 2.0 3

NCOMS 172.20.4.13 SDK04A70XV4 2.0 4

NCOMS 172.50.0.2 SAD06A300PY 2.0 5

Find entities within all cardsThis query retrieves entities contained within all cards. Cards might containentities of different types, including ports, slots, and sensors. The query lists eachof the cards identified and, for each card, lists the entities contained within thecard.

This query does not traverse the entire containment tree within the card. Therefore,the query only retrieves components at the top level within the card.

This query uses the contains table. This table defines all the containmentrelationships between entities. Each row in the contains table holds a pair of entityidentifiers: the containing entity and the contained entity identifier. For each cardidentified, the query joins to the contains table and extracts information about oneof the entities contained within that card.

Example

1]2]3]4]5]6]7]8]

SELECT container.entityName Card_Name,m.cardNumber Card_Number,part.entityName Contained_Entity

FROM physicalCard mINNER JOIN entityData container ON container.entityId = m.entityIdINNER JOIN contains c ON c.containingEntityId = m.entityIdINNER JOIN entityData part ON part.entityId = c.containedEntityIdORDER BY container.entityName





v The name of the card, represented by container.entityName

v The number of the card within the main node device, represented bym.cardNumber

v The name of the interface, represented by part.entityName

4 Use the physicalCard table as the driving table for this query.

The FROM clause extracts data for all cards.




5 For each card, extract the full set of entity data for that card. This ensuresthat the entity name of the card is retrieved for display in the queryresults, as specified in line 1). Use the alias container for the entityDatatable to indicate that data extracted using this alias is data for thecontaining card.

Do this by specifying an INNER JOIN statement with the entityData table.

6 For each card, extract records from the contains table on entities containedwithin that card. Limit the query results to those cards that contain otherentities.

Do this by specifying an INNER JOIN statement with the contains table.

The query extracts a record from the contains table for each entitycontained within a given card. Each of these records includes the entityidentifier for an entity contained within the card.

7 Extract the full set of entity data for each contained entity. Use the aliaspart for the entityData table to indicate that data extracted using this aliasis data for a contained entity.

Do this by specifying a second INNER JOIN statement with the entityDatatable.

8 To facilitate readability of the results, order by the entity name of thecontaining card.



Card name Card number Contained entity

10.1.1.11_CARD_1 1 10.1.1.11[ 1 [ 1 ] ]

10.1.1.11_CARD_2 2 10.1.1.11[ 2 [ 1 ] ]

10.1.1.12_CARD_0 0 10.1.1.12[ 0 [ 14 ] ]

10.1.1.12_CARD_0 0 10.1.1.12[ 0 [ 10 ] ]

10.1.1.12_CARD_0 0 10.1.1.12[ 0 [ 12 ] ]

10.1.1.12_CARD_0 0 10.1.1.12[ 0 [ 11 ] ]

10.1.1.12_CARD_0 0 10.1.1.12[ 0 [ 13 ] ]

10.1.1.8_CARD_I3_R0 NULL 10.1.1.8_SLOT_I4_R0’




10.1.254.2_CARD_I1000_R1 NULL 10.1.254.2_SENSOR_I1002_R2

10.1.254.2_CARD_I1000_R1 NULL 10.1.254.2_SENSOR_I1001_R1

10.1.254.2_CARD_I1100_R1 NULL 10.1.254.2_PORT_I1102_R1

10.1.254.2_CARD_I1100_R1 NULL 10.1.254.2_PORT_I1101_R0

Related reference:“Aliasing” on page 22Aliasing is the use of a temporary name for a column, sub-query or table within a


query.“Table joins” on page 22Use table joins to combine records from one or more tables. Two types of table joinare used, INNER JOIN and OUTER JOIN.“Choice of driving table” on page 22One of the most important design decisions when creating a query is the choice ofdriving table. The choice of driving table is particularly important for ensuring theefficiency of queries.

Queries for port and interface informationThese sample queries extract interface and protocol information associated withinterfaces.

Device entities, usually interfaces, might be associated with protocol-specific data.The most common example is the association between a device interface with theIP addressing data. Interfaces might also be associated with other types ofaddressing data, including ATM protocol data and OSPF protocol data.

List all interfaces on all devicesThis query provides a list of all main node devices within a domain together withthe identifiers and names of the interfaces on each device.

Example

1]2]3]4]5]6]7]8]

SELECT eMainNode.entityName Main_Node_Name,eInterface.entityId Interface_Entity_ID,eInterface.entityName Interface_Entity_Name

FROM entityData eInterfaceINNER JOIN entityData eMainNode ON eMainNode.entityId =

eInterface.mainNodeEntityIdWHERE eInterface.entityType = 2ORDER BY eMainNode.entityName, eInterface.entityName

Description






v The unique entity ID of the interface within the topology database,represented by eInterface.entityId

v The name of the interface, represented by eInterface.entityName

4 Use the entityData table as the driving table for this query. Use the aliaseInterface for the entityData table to indicate that the data extractedusing this alias is interface data.

5-6 Identify the containing main node device for each of the entities retrievedin the preceding line. Do this by joining the entityData table to itself usingthe mainNodeEntityId field.

7 Limit the components of the device to interfaces only. Do this filtering thecomponents to retrieve only components with an entity type of 2, whichcorresponds to an interface.




8 To facilitate readability of the results, order first by main node name andthen by interface name.

Results

The table below shows a portion of the results for this query.


Main node name Interface entity ID Interface entity name

172.20.1.41 1622 172.20.1.41[0[1]]

172.20.4.11 1621 172.20.4.11[0[1]]

172.20.4.11 1624 172.20.4.11[0[10]]

172.20.4.11 1479 172.20.4.11[0[11]

172.20.4.11 1632 172.20.4.11[0[12]

VE001.example.net 1631 VE001.example.net[0[1]]

Related reference:“mainNodeEntityId field” on page 23The mainNodeEntityId field in the entityData table specifies the main node of theentity. This field provides a shortcut to the main node for a particular entity,avoiding the need to traverse the entire containment tree.“entityType field” on page 23The entityType field can be used in SQL queries to limit the type of componentdata that is retrieved.

List all interfaces with specific attributesThis query provides a list of all interfaces within a domain that have specificattribute values.

The example given here retrieves interfaces that have an interface speed greaterthan 155 MB per second; however, you can construct a query using any of theattributes in the networkInterface table.

Example

1]2]3]4]5]6]7]

SELECT e.entityName Interface_Name,i.ifName IfName,i.ifSpeed Interface_Speed

FROM entityData eINNER JOIN networkInterface i ON i.entityId = e.entityIdWHERE ifSpeed > 155000000ORDER BY i.ifSpeed DESC;


Description





v The name of an interface, represented by e.entityName

v The name of the interface stored in the MIB, represented by i.ifName

v The speed of the interface, represented by i.ifSpeed

4 Use the entityData table as the driving table for this query. This part ofthe query retrieves all entities held in the database.

5 Limit the results of the query to interfaces.

Do this by joining the networkInterface table to the entityData table usingthe mainNodeEntityId field. There is now a line of data for each interface inthe database. The INNER JOIN statement ensures that only interface data isretrieved.

6 Limit the results of the query to interfaces with interface speeds greaterthan 155 MB per second.

7 Order the results by the speed of the interface.

Results



Interface name IfName Interface speed

10.1.254.2[ 1 [ 1 ] ] Gi1/1 1000000000

192.170.170.10[ 0 [ 51 ] ] Gi50 1000000000

192.170.170.10[ 0 [ 50 ] ] Gi49 1000000000

192.170.170.10[ 0 [ 1 ] ] FX1 1000000000

172.20.4.19[ 0 [ 1 ] ] ATM0/1/0 622080000

172.18.1.102[ 2 [ 1 ] ] FEC-9/39-42 400000000

172.20.4.19[ 0 [ 2 ] ] ATM0 155520000

192.170.170.10[ 0 [ 52 ] ] Co51 155520000

List all interfaces on all devices with interface typeThis query retrieves all interfaces on all devices across all domains, and alsoretrieves information about the interface.

For each interface the query retrieves the following information about the interface:v ifName

v ifType

v A textual description corresponding to the ifType field

In addition to using information from the entityData table to list the interfaces oneach device, this query provides a join to the networkInterface table to bring indetailed attribute data for the interfaces identified.


Example

1]2]3]4]5]6]7]8]9]10]11]12]

SELECT eInterface.entityId Interface_Entity_ID,eMainNode.entityName Main_Node_Name,eInterface.entityName Interface_Entity_Name,i.ifName IfName,i.ifType Interface_Type,i.ifTypeString Interface_Type_String


eInterface.mainNodeEntityIdINNER JOIN networkInterface i ON i.entityId = eInterface.entityIdWHERE eInterface.entityType = 2ORDER BY eMainNode.entityName, i.ifType

Description






v The name of the main node to which the interface belongs, representedby eMainNode.entityName


v The textual name of the interface, as specified in the MIB, represented byi.ifName

v The type of interface, as specified in the MIB, represented by i.ifType

v The textual description corresponding to this type of interface,represented by i.ifTypeString




10 Extract all attribute data for the various interfaces. This attribute data isheld in the networkInterface table.

Do this by joining the networkInterface table to the entityData table usingthe entityId field. The INNER JOIN statement ensures that only interfacedata is retrieved.

11 Limit the components of the device to interfaces only.

Do this by filtering the components to retrieve only components with anentity type of 2, which corresponds to an interface.

12 To facilitate readability of the results, order first by main node name andthen by ifType.


Results



Inter-faceentityID

Main nodename Interface entity name IfName

Inter-facetype Interface type string

1479 10.1.1.11 10.1.1.11[ 0 [ 12 ] Fa0/11 6 ethernetCsmacd

1621 10.1.1.11 10.1.1.11[ 0 [ 10 ] Fa0/9 6 ethernetCsmacd

1622 10.1.1.11 10.1.1.11[ 0 [ 1 ] VL1 6 ethernetCsmacd

2466 10.1.1.5 10.1.1.5[ 0 [ 1029 ] 1B1 18 ds1

2471 10.1.1.5 10.1.1.5[ 0 [ 1035 ]]

1B4 18 ds1

2465 10.1.1.5 10.1.1.5[ 0 [ 1032 ]]

1B2 37 atm

2476 10.1.1.5 10.1.1.5[ 0 [ 1030 ]]

1B1 37 atm

2477 10.1.1.5 10.1.1.5[ 0 [ 1024 ]]

1CTL 37 atm

2474 10.1.1.5 10.1.1.5[ 0 [ 1059 ]]

44 frameRelayService

2480 10.1.1.5 10.1.1.5[ 0 [ 1053 ]]


2482 10.1.1.5 10.1.1.5[ 0 [ 1055 ]]


2488 10.1.1.5 10.1.1.5[ 0 [ 5 ] ] qaa1 114 ipOverAtm

2490 10.1.1.5 10.1.1.5[ 0 [ 4 ] ] qaa0 114 ipOverAtm

2496 10.1.1.5 10.1.1.5[ 0 [ 6 ] ] qaa2 114 ipOverAtm

1652 10.1.1.9 10.1.1.9[ 0 [ 1 ] ] Se0/0 22 propPointToPointSerial

1131 10.1.254.1 10.1.254.1[ 0 [ 20 ]]

Fa0/1.80 135 l2vlan

1130 10.1.254.1 10.1.254.1[ 0 [ 22 ]]

Se1/1:0 166 mpls

Related reference:“Techniques used in the SQL queries” on page 22The SQL query examples use a variety of techniques that are aimed at extractinginformation efficiently. Use this information to familiarize yourself with thetechniques used in SQL queries.“List all interfaces on all devices” on page 41This query provides a list of all main node devices within a domain together withthe identifiers and names of the interfaces on each device.“entityType field” on page 23The entityType field can be used in SQL queries to limit the type of componentdata that is retrieved.


List all IP addresses and the interfaces that implement themThis query retrieves all interfaces on all main node devices. For each interface, thequery lists the IP addresses that the interface implements. An interface canimplement multiple IP addresses.

In addition to using information from the entityData table to list the interfaces oneach device, this query lists the IP addresses implemented by each interfaceidentified. If an interface does not implement an IP address, that interface is notreturned by this query.

Example

1]2]3]4]5]6]7]8]9]10]11]12]

SELECT eInterface.entityId Interface_Entity_ID,eMainNode.entityName Main_Node_Name,eInterface.entityName Interface_Entity_Name,ip.address IP_Address


eInterface.mainNodeEntityIdINNER JOIN protocolEndPoint p ON p.implementingEntityId =

eInterface.entityIdINNER JOIN ipEndPoint ip ON ip.entityId = p.endPointEntityIdWHERE eInterface.entityType = 2ORDER BY eInterface.entityId

Description








v An IP address implemented by this interface, represented by ip.address




8-10 Identify the IP addresses implemented by each of the entities identified inline 5 of the query.

Do this by performing an INNER JOIN statement on the protocolEndPointtable to extract the entity ID for any protocol-specific informationassociated with the entities identified in line 5.

Then perform a second INNER JOIN statement on the ipEndPoint table tolimit the protocol-specific information returned by the query to IPinformation.




11 Limit the components of the device to interfaces only.

Do this by filtering the components to retrieve only components with anentity type of 2, which corresponds to an interface.

12 To facilitate readability of the results, order first by the unique entity ID ofthe interface.

Results



Interface Entity ID Main Node NameInterface EntityName IP Address

270 172.20.4.11 172.20.4.11[0[5]] 172.50.0.2

338 172.18.1.196 172.18.1.196[0[2]] 172.50.0.3

366 172.18.1.54 172.18.1.54[0[2]] 172.50.0.4

370 172.18.1.54 172.18.1.54[0[1]] 172.50.0.5

373 172.20.4.13 172.20.4.13[0[1]] 172.50.0.6

377 172.20.4.20 172.20.4.20[0[1]] 172.50.0.7

417 192.168.139.7 192.168.139.7[ 0 [5 ] ]

172.20.11.1

417 192.168.139.7 192.168.139.7[ 0 [5 ] ]

172.20.1.2

Related reference:“List all interfaces on all devices” on page 41This query provides a list of all main node devices within a domain together withthe identifiers and names of the interfaces on each device.“Techniques used in the SQL queries” on page 22The SQL query examples use a variety of techniques that are aimed at extractinginformation efficiently. Use this information to familiarize yourself with thetechniques used in SQL queries.“ipEndPoint” on page 191The ipEndPoint table represents an IP end point and includes relevant data. Theendpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.“mainNodeEntityId field” on page 23The mainNodeEntityId field in the entityData table specifies the main node of theentity. This field provides a shortcut to the main node for a particular entity,avoiding the need to traverse the entire containment tree.“Protocol endpoint tables” on page 24The protocolEndPoint and ipEndPoint tables can be used in SQL queries toidentify the IP addresses that are implemented by the device interfaces.


Queries for connectivity informationThese sample queries extract data on connectivity within your network.

Connectivity includes connections between different devices, and VLAN-relatedconnections within the same device. In addition, the NCIM database independentlyrepresents connectivity of entities in different layers, so that the connectivity atlayer 2 is represented independently of the connectivity at layer 3.

NCIM can model complex connectivity scenarios. For example, within the MPLSVPN realm, NCIM can model the layer 3 connection between a provider-edge (PE)router and multiple customer-edge (CE) routers.

Connectivity information is stored in the connects table. This table stores eachconnection as a single record. However, because two entities are involved in aconnection, the order of the connected entities in the connects table is random.

For example, the following figures shows the devices that are connected to themain node device VE001.example.net.

The following table shows how the connects table might store the data about theconnectivity between the device VE001.example.net and neighboring devices.

Table 28. Example data from the connects table for connections to main node deviceVE001.example.net

connectionId aEndEntityId zEndEntityId

101 VE001.example.net 192.168.35.225

102 VE001.example.net 192.168.34.86

103 192.168.39.175 VE001.example.net

192.168.39.17

VE001.example.net

192.168.34.86192.168.35.25

Figure 3. Devices connected to main node device VE001.example.net


It is arbitrary whether a device is designated at the start (the aEnd) or at the end(zEnd) of a connection. The following example from Table 28 on page 48 showswhy:

Connections 101 and 102 show the device VE001.example.net at the aEnd of theconnection.Connection 103 shows the device VE001.example.net at the zEnd of theconnection.

Connections in NCIM can be bidirectional or unidirectional. A field in the connectstable that specifies whether the connection is bidirectional or unidirectional.

To ensure that all connections are retrieved from the connects table for a givendevice, the query must take into account the random ordering of aEnd and zEnddata in the table. This is done using a UNION statement. The query works asfollows:Find all devices connected to the device VE001.example.net where VE001.example.netis the aEnd of the connectionUNIONFind all devices connected to the device VE001.example.net where VE001.example.netis the zEnd of the connection

Types of connectivityQueries that retrieve device connectivity can identify different types of connection.Use this information to learn about the connectivity types that can be queried.

The following types of connectivity are retrieved:

Connections to other devicesThe connection passes through a physical or logical interface. Interfaceshave an entity type of 2 and are modleled using the interface table.

Trunk connection between a specific VLAN on the named device to the sameVLAN on a different device

The connection passes through a VLAN trunk port. A VLAN trunk port isa physical port that carries data from multiple VLANs. Each VLANtrunked by the VLAN trunk port is modelled with a VLAN trunk endpoint.

Connections within the named device between local VLANs and VLAN trunkports The connection passes between a local VLAN on the current device to a

VLAN trunk on the same device. The query reports this connection as aconnection between the device and itself. Local VLANs are modelled usingthe localVlan table.

Related reference:“networkInterface” on page 211The networkInterface table represents interfaces on a chassis device.“vlanTrunkEndPoint” on page 262The vlanTrunkEndPoint table represents a VLAN trunk end point and includesrelevant data. This endpoint is implemented by a physical interface, as modeled inthe protocolEndPoint table.“localVlan” on page 201The localVlan table specifies which global VLAN the local VLAN belongs to. Alocal VLAN represents all the interfaces on a single chassis device that belong to aglobal VLAN.


Hierarchy modeling with the networkPipe andpipeComposition tables

The networkPipe table and pipeComposition table can be used together torepresent connectivity at different layers, for example the modeling of layer 2 andlayer 3 connections.

A layer 3 connection can be considered as a higher-level connection that is definedin terms of lower-level layer 2 connections. A hierarchy of connections is modeledusing the networkPipe and pipeComposition tables, as follows:

Rows in the networkPipe table can be combined in collections using thepipeComposition table

The difference between a network pipe and a simple connection is that anetwork pipe is an entity. This gives the network pipe the followingadvantages over a simple connection:v You can associate attributes to the network pipe, for example by using

the entityDetails table.v A network pipe is able to participate in the relationships available to

entities, including containment, connectivity, and dependencyrelationships.

The pipeComposition table allows a higher-level connection to be defined interms of lower-level connections

The higher-level and lower-level connections are all represented by rows inthe networkPipe table.

Find devices connected to a named deviceThis query identifies all main node devices connected to a single specified mainnode device.

Example

1]2]3]4]5]6]7]8]9]10]11]12]13]14]15]16]17]18]19]20]21]

SELECT locm.entityid Local_Main_Node_Entity_ID,locm.entityName Local_Main_Node_Entity_Name,nbrm.entityid Neighbor_Main_Node_Entity_ID,nbrm.entityName Neighbor_Main_Node_Entity_Name

FROM entityData locINNER JOIN connects c ON c.aEndEntityId = loc.entityIdINNER JOIN entityData nbr ON nbr.entityId = c.zEndEntityIdINNER JOIN entityData nbrm ON nbrm.entityid = nbr.mainnodeentityidINNER JOIN entityData locm ON locm.entityid = loc.mainnodeentityidWHERE loc.mainNodeEntityId = 5UNIONSELECT locm.entityid as locMainNodeEntityId,

locm.entityName as locMainNodeEntityName,nbrm.entityid as nbrMainNodeEntityId,nbrm.entityName as nbrMainNodeEntityName

FROM entityData locINNER JOIN connects c ON c.zEndEntityId = loc.entityIdINNER JOIN entityData nbr ON nbr.entityId = c.aEndEntityIdINNER JOIN entityData nbrm ON nbrm.entityid = nbr.mainnodeentityidINNER JOIN entityData locm ON locm.entityid = loc.mainnodeentityidWHERE loc.mainNodeEntityId = 5


Description





v The unique entity ID of a specified main node device, represented bylocm.entityId. This is the named device whose neighbors you want toextract from the database. The rest of this description refers to thisdevice as the local device

v The name of the local device, represented by locm.entityName

v The unique entity ID of a device that is next to the specified device,represented by nbrm.entityId

v The name of the neighboring device, represented by nbrm.entityName

5 Use the entityData table as the driving table for this query. Use the aliasloc for the entityData table to indicate that the data extracted using thisalias is for local entities.

6 Identify all the connections for the entities associated with the local device.

Do this by joining the connects table using the aEndEntityId value.

7 Extract the entity data for each neighboring entity.

Do this by joining the entityData table a second time using thezEndEntityId value. Use the alias nbr for the entityData table to indicatethat the data extracted using this alias is for neighboring entities.

8 Limit the results to neighboring main node devices only.

Do this by joining the entityData table a second time using themainNodeEntityId value.

Use the alias nbrm for the entityData table to indicate that the dataextracted using this alias is entity data for a neighboring main node device.

9 Limit the results to local main node devices only.

Do this by joining the entityData table a second time using themainNodeEntityId.

Use the alias locm for the entityData table to indicate that the dataextracted using this alias is entity data for a local main node device.

10 Specify the identity of the local device.

11 Use the UNION statement to ensure that all connections are retrieved.

12-21 This is the same code as line 1-10 with the difference that here thespecified device is considered to be the zend (see line 17) and theneighboring devices are all considered to be at the aend (see line 18).

Results

The table below shows the results of this query. This data includes examples ofdevices connected to themselves. These are connections within the same devicebetween local VLANs and VLAN trunk ports.



Local main nodeentity ID

Local main nodeentity name

Neighbor main nodeentity ID

Neighbor mainmode entity name

5 VE001.example.net 83 192.168.35.225

5 VE001.example.net 2698 192.168.34.86

77 VE002.example.net 77 VE002.example.net

77 VE002.example.net 77 VE002.example.net

531 192.168.39.175 5 VE001.example.net

Related concepts:“Connectivity data” on page 15Connectivity data defines how entities are connected in the network. It includesconnections between different devices, and VLAN-related connections within thesame device. Connectivity information is stored in the topologyLinks, networkPipe,and pipeComposition tables.Related reference:“connects” on page 128The connects table stores data on connectivity between devices. This table belongsto the category collections.“Techniques used in the SQL queries” on page 22The SQL query examples use a variety of techniques that are aimed at extractinginformation efficiently. Use this information to familiarize yourself with thetechniques used in SQL queries.Related information:“Find all devices connected to a named device together with connecting interfaces”This query identifies all main node devices that are connected to a main device,and also retrieves the interface data that is associated with each of thoseconnections.

Find all devices connected to a named device together withconnecting interfaces

This query identifies all main node devices that are connected to a main device,and also retrieves the interface data that is associated with each of thoseconnections.


Example

1]2]3]4]5]6]7]8]9]10]11]12]13]14]15]16]17]18]19]20]21]22]23]24]25]

SELECT locm.entityid Local_Main_Node_Entity_ID,locm.entityName Local_Main_Node_Entity_Name,loc.entityName Local_Interface_Name,nbrm.entityid Neighbor_Main_Node_Entity_ID,nbrm.entityName Neighbor_Main_Node_Entity_Name,nbr.entityName Neighbor_Interface_Name

FROM entityData locINNER JOIN connects c ON c.aEndEntityId = loc.entityIdINNER JOIN entityData nbr ON nbr.entityId = c.zEndEntityIdINNER JOIN entityData nbrm ON nbrm.entityid = nbr.mainnodeentityidINNER JOIN entityData locm ON locm.entityid = loc.mainnodeentityidWHERE loc.mainNodeEntityId = 5UNIONSELECT locm.entityid as locMainNodeEntityId,

locm.entityName as locMainNodeEntityName,loc.entityName as locEntityName,nbrm.entityid as nbrMainNodeEntityId,nbrm.entityName as nbrMainNodeEntityName,nbr.entityName as nbrEntityName

FROM entityData locINNER JOIN connects c ON c.zEndEntityId = loc.entityIdINNER JOIN entityData nbr ON nbr.entityId = c.aEndEntityIdINNER JOIN entityData nbrm ON nbrm.entityid = nbr.mainnodeentityidINNER JOIN entityData locm ON locm.entityid = loc.mainnodeentityidWHERE loc.mainNodeEntityId = 5

Description





v The unique entity ID of a specified main node device. This is the nameddevice whose neighbors you want to extract from the database. The restof this description refers to this device as the local device, represented bylocm.entityId

v The name of the local device, represented by locm.entityName

v The name of the interface on the local device, represented byloc.entityName

v The unique entity ID of a device that is adjacent to the specified device,represented by nbrm.entityId

v The name of the neighboring device, represented by nbrm.entityName

v The name of the interface on the neighboring device, represented bynbr.entityName


Do this by joining the entityData table a second time using thezEndEntityId value. Use the alias nbr for the entityData table to indicatethat the data extracted using this alias is for neighboring entities.




8 Limit the results to neighboring main node devices only.

Do this by joining the entityData table a second time using themainNodeEntityId value.

Use the alias nbrm for the entityData table to indicate that the dataextracted using this alias is entity data for a neighboring main node device.

9 Limit the results to local main node devices only.

Do this by joining the entityData table a second time using themainNodeEntityId.

Use the alias locm for the entityData table to indicate that the dataextracted using this alias is entity data for a local main node device.

10 Specify the identity of the local device.

11 Use the UNION statement to to ensure that all connections are retrieved.


Results

The following table shows an example of the results of the query.the results of thequery.


LocalmainnodeentityID

Local mainnode entityname

Local interfacename

Neigh-bormainnodeentityID

Neighbormain nodeentityname

Neighbor interfacename

5 VE001.example.net

VE001.example.net[0[3]]

83 192.168.35.225

192.168.35.225

5 VE001.example.net


2698 192.168.34.86

192.168.34.86


VLAN_OBJECT_VE002.example.net_VLAN_400


VLAN_trunk_400_VE002.example.net[ 0 [ 2 ] ]

77 VE002.examplenet

VLAN_OBJECT_VE002.example.net_VLAN_1


VLAN_trunk_1_VE002.example.net[ 0 [ 2 ] ]

531 192.168.39.175

192.168.39.175

5 VE001.example.net



Identify all connections between routersThis query identifies all connections between routers. These types of connectionsare also called Layer 3 router links. Each of these connections also represents aconnection between two subnets.

You can use similar queries to determine the type of connection between twodevices. You can determine whether a connection falls into any of the followingtypes:v Layer 2 connectionv Layer 3 router links

This refers to connections between routers, and hence, between subnets, and isthe example provided in this query.

v Psuedowire connection

Use the topologyLinks table to identify which connections belong to a specific typeof topology. This table lists all the connections in the database and specifies theidentifier of a topology type entity from the entityData table.

Example

1]2]3]4]5]6]7]8]

SELECT a.entityName Connected_Entity,z.entityName Connected_Entity

FROM topologyLinks tINNER JOIN entityData topo ON topo.entityId = t.entityIdINNER JOIN connects c ON c.connectionId = t.connectionIdINNER JOIN entityData a ON a.entityId = c.aEndEntityIdINNER JOIN entityData z ON z.entityId = c.zEndEntityIdWHERE topo.entityType = 73

Description





v The name of an interface at one end of the connection, represented bya.entityName

v The name of an interface at the other end of the connection, representedby z.entityName

3 Use the topologyLinks table as the driving table for this query. Use thealias t for the topologyLinks table for purposes of brevity.

4 Identify all the types of topology listed in the topologyLinks table. Do thisby joining the entityData table using the entityId field.

5 Extract the connection data for each connection. Do this by joining theconnects table using the connectionId field.

6-7 Extract entity details for each of the interfaces at either end of theconnection.

Do this by joining the entityData table a second time using the entityIdfield in the entityData table and the aEndEntityId and zEndEntityId fieldsin turn in the connects table.




8 Limit the results to connections within layer 3 router links only. This limitsthe results to connections between routers, and hence, between subnets.

Results

The table below shows the results of the query.


Connected entity Connected entity

172.20.4.16[ Et0/0 ] 172.20.4.11[ Fa0/0 ]

172.20.4.11[ Fa0/0 ] 172.20.4.16[ Et0/0 ]

172.20.4.16[ Et0/0 ] 172.20.4.12[ Fa0/0 ]

172.20.4.11[ Fa0/0 ] 172.20.4.12[ Fa0/0 ]

172.20.4.12[ Fa0/0 ] 172.20.4.16[ Et0/0 ]

172.20.4.12[ Fa0/0 ] 172.20.4.11[ Fa0/0 ]

172.20.4.16[ Et0/0 ] 172.20.4.15[ Fa0/1 ]

172.20.4.11[ Fa0/0 ] 172.20.4.15[ Fa0/1 ]

172.20.4.12[ Fa0/0 ] 172.20.4.15[ Fa0/1 ]

172.20.4.15[ Fa0/1 ] 172.20.4.12[ Fa0/0 ]

172.20.4.15[ Fa0/1 ] 172.20.4.11[ Fa0/0 ]

172.20.4.15[ Fa0/1 ] 172.20.4.16[ Et0/0 ]

172.20.4.16[ Et0/0 ] 172.20.4.28[ Gi0/0 ]

Related reference:“Techniques used in the SQL queries” on page 22The SQL query examples use a variety of techniques that are aimed at extractinginformation efficiently. Use this information to familiarize yourself with thetechniques used in SQL queries.

Queries for LTE network informationThese sample queries retrieve information about Long-Term Evolution (LTE)devices.

Find specific LTE entity typesThese queries retrieve details of specific entity types used in LTE networks; forexample, Extended NodeB entities, Packet Gateway entities, or Serving Gatewayentities.

Example: find all discovered Extended NodeB entities

This query retrieves the details of all Extended NodeB entities that have beendiscovered.


1]2]3]4]5]6]7]

select e.entityId,e.entityName,enb.eNodeBId,enb.eNodeBName,enb.emsDistinguishedNamefrom ncim.entityData eINNER JOIN ncim.enbFunction enb ON enb.entityId = e.entityId





v The entity ID of the Extended NodeB function entities, represented bye.entityId.

v The name of the eNodeB, represented by e.entityName.

v The identifier of the eNodeB, represented by enb.eNodeBId.

v A more user-friendly name for the eNodeB, represented byenb.eNodeBName.

v The name by which the enbFunction is known to its elementmanagement system (EMS), represented by enb.emsDistinguishedName.


7 Limit the results of the query to eNodeB function entities.

Do this by joining the enbFunction table to the entityData table using theentityId field.

Similar queries

The following example queries retrieve relevant data for different LTE entity types,using similar syntax to the above example.

Example: find all discovered Equipment Identity Register entities

This query retrieves the details of all Equipment Identity Register (EIR) entitiesthat have been discovered.select e.entityId,e.entityName,eir.eirFunctionName,eir.emsDistinguishedNamefrom ncim.entityData eINNER JOIN ncim.eirFunction eir ON eir.entityId = e.entityId

Example: find all discovered Home Subscriber Server entities

This query retrieves the details of all Home Subscriber Server (HSS) entities thathave been discovered.select e.entityId,e.entityName,hss.hssFunctionName,hss.emsDistinguishedNamefrom ncim.entityData eINNER JOIN ncim.hssFunction hss ON hss.entityId = e.entityId


Example: find all discovered Mobility Management Entities

This query retrieves the details of all Mobility Management Entities (MMEs) thathave been discovered.select e.entityId,e.entityName,mme.MMEGI,mme.MMEC,mme.mmeName,mme.emsDistinguishedNamefrom ncim.entityData eINNER JOIN ncim.mmeFunction mme ON mme.entityId = e.entityId

Example: find all discovered Packet Gateway entities

This query retrieves the details of all Packet Gateway entities that have beendiscovered.select e.entityId,e.entityName,pgw.pgwFunctionName,pgw.emsDistinguishedNamefrom ncim.entityData eINNER JOIN ncim.pgwFunction pgw ON pgw.entityId = e.entityId

Example: find all discovered Policy and Charging Rule Functionentities

This query retrieves the details of all Policy and Charging Rule Function entitiesthat have been discovered.select e.entityId,e.entityName,pcrf.pcrfFunctionName,pcrf.emsDistinguishedNamefrom ncim.entityData eINNER JOIN ncim.pcrfFunction pcrf ON pcrf.entityId = e.entityId

Example: find all discovered Serving Gateway entities

This query retrieves the details of all Serving Gateway entities that have beendiscovered.select e.entityId,e.entityName,sgw.sgwFunctionName,sgw.emsDistinguishedNamefrom ncim.entityData eINNER JOIN ncim.sgwFunction sgw ON sgw.entityId = e.entityId

Queries for MPLS Traffic Engineered Tunnel informationThese sample queries retrieve information about the MPLS Traffic Engineeredtunnels that have been discovered.


List all Traffic Engineered tunnelsThis database query shows the names of the Traffic Engineered (TE) tunnels thathave been discovered, and the domain they are associated with.

Example

1]2]3]4]5]

SELECT e.entityName, e.displayLabel, d.domainNameFROM entityData eINNER JOIN entityType t on t.entityType = e.entityTypeINNER JOIN domainMgr d on d.domainMgrId = e.domainMgrIdWHERE t.typeName = ’MPLS TE Tunnel’;

Results

The following table provides an example of part of the result set for this query.


entityName displayLabel domainName

172.20.1.6_MPLS_TE_Tunnel_Idx_10_Inst_0

172.20.1.6 Tunnel10 10:0 NCOMS


172.20.1.6 Tunnel10 10:12Primary

NCOMS


172.20.1.7 Tunnel12 12:0 NCOMS



NCOMS


172.20.1.7 Tunnel50 50:0 NCOMS



NCOMS

Show interfaces utilized by Traffic Engineered tunnelsThis database query shows the interfaces and physical ports used by a particularTraffic Engineered (TE) tunnel.

Example

1]2]3]4]5]

SELECT eTun.entityName as Tunnel, eInt.entityName as InterfaceFROM collects cINNER JOIN entityData eTun ON eTun.entityId = c.collectingEntityIdINNER JOIN entityData eInt ON eInt.entityId = c.collectedEntityIdWHERE eTun.entityName = ’172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12’;

Results



Tunnel Interface

172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12 172.20.1.7[ 0 [ 22 ] ]





Tunnel Interface




Show Traffic Engineered tunnel configurationThis query shows a subset of the tunnel attributes for a particular tunnel.

Example

1]2]3]4]5]

SELECT e.entityName, m.role, m.ingressLSRId, m.egressLSRId,m.signallingProtocol

FROM mplsTETunnel mINNER JOIN entityData e on e.entityId = m.entityIdWHERE e.entityName = ’172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12’;

Results

The following table provides an example of the result set for this query.


entityName 172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12

role head

ingressLSRId 172.20.1.7

egressLSRId 172.20.1.6

signallingProtocol rsvp

List supporting routers for a Traffic Engineered tunnelThese queries show which routers and services support a particular tunnel.

Example: which router and service support a particular tunnel

1]2]3]4]5]6]7]8]

SELECT eHost.entityName as HostingRouter, eServ.entityName as TunnelService,eTun.entityName as TunnelNameFROM entityData eTunINNER JOIN contains c ON c.containedEntityId = eTun.entityIdINNER JOIN entityData eServ ON eServ.entityId = c.containingEntityIdINNER JOIN hostedService h ON h.hostedEntityId = eServ.entityIdINNER JOIN entityData eHost ON eHost.entityId = h.hostingEntityIdWHERE eTun.entityName = ’172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12’;

Results



HostingRouter TunnelService TunnelName

172.20.1.7 MPLS_TE_Service_172.20.1.7 172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12


Example: show all routers in a tunnel path

1]2]3]4]5]6]

SELECT DISTINCT eMain.entityNameFROM collects cINNER JOIN entityData eTun ON eTun.entityId = c.collectingEntityIdINNER JOIN entityData eInt ON eInt.entityId = c.collectedEntityIdINNER JOIN entityData eMain ON eMain.entityId = eInt.mainNodeEntityIdWHERE eTun.entityName = ’172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12’;

Results



entityName

172.20.1.7

172.20.1.4

172.20.1.6

Show performance data for a Traffic Engineered tunnelThis query shows performance data for a tunnel.

Example

1]2]3]4]5]

SELECT eTun.entityName, res.maxRate, res.meanRate, res.maxBurstSize,res.meanBurstSizeFROM entityData eTunINNER JOIN dependency d ON d.dependentEntityId = eTun.entityIdINNER JOIN mplsTETunnelResource res ON res.entityId = d.independentEntityIdWHERE eTun.entityName = ’172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12’;

Results



entityName 172.20.1.7_MPLS_TE_Tunnel_Idx_50_Inst_12

maxRate 100000

meanRate 100000

maxBurstSize 1000

meanBurstSize 1


Queries for Radio Access Network informationThese sample queries retrieve information about Radio Access Network (RAN)devices.

Find specific RAN entity typesThese queries retrieve details of specific entity types used in Radio AccessNetworks, for example, base stations, node B entities, or Mobile Switching Centres.

Example: find all discovered base stations

This query retrieves the details of all base stations that have been discovered.

1]2]3]4]5]6]7]8]

select e.entityId,e.entityName,c.className,rbs.baseStationId,rbs.ranTechnologyTypefrom ncim.entityData eINNER JOIN ncim.physicalChassis c ON c.entityId = e.entityIdINNER JOIN ncim.ranBaseStation rbs ON rbs.entityId = c.entityId





v The entity ID of the base station, represented by e.entityId.

v The name of the base station, represented by e.entityName.

v The Active Object Class assigned to the base station, represented byc.className.

v The unique identifier of the base station, represented byrbs.baseStationId.

v The type of wireless technology used by the base station, represented byrbs.ranTechnologyType.


7 Limit the results of the query to chassis entities.

Do this by joining the chassis table to the entityData table using theentityId field.

8 Limit the results of the query to entities that are present in theranBaseStation table, that is, to base stations.

Similar queries

The following example queries retrieve relevant data for different RAN entitytypes, using similar syntax to the above example.

Example: find all discovered Node B entities

This query retrieves the details of all Node B entities that have been discovered.


select e.entityId,e.entityName,c.className,rnb.nodebId,rnb.ranTechnologyTypefrom ncim.entityData eINNER JOIN ncim.physicalChassis c ON c.entityId = e.entityIdINNER JOIN ncim.ranNodeB rnb ON rnb.entityId = c.entityId

Example: find all discovered Base Station Controllers

This query retrieves the details of all base station controllers that have beendiscovered.select e.entityId,e.entityName,c.className,rbsc.baseStationControllerId,rbsc.ranTechnologyTypefrom ncim.entityData eINNER JOIN ncim.physicalChassis c ON c.entityId = e.entityIdINNER JOIN ncim.ranBaseStationController rbsc ON rbsc.entityId = c.entityId

Example: find all discovered Radio Network Controllers

This query retrieves the details of all Radio Network Controllers that have beendiscovered.select e.entityId,e.entityName,c.className,rrnc.rncId,rrnc.ranTechnologyTypefrom ncim.entityData eINNER JOIN ncim.physicalChassis c ON c.entityId = e.entityIdINNER JOIN ncim.ranRadioNetworkController rrnc ON rrnc.entityId = c.entityId

Example: find all discovered Mobile Switching Centers

This query retrieves the details of all Mobile Switching Centers that have beendiscovered.select e.entityId,e.entityName,c.className,rmsc.mscId,rmsc.msctype,rmsc.ranTechnologyTypefrom ncim.entityData eINNER JOIN ncim.physicalChassis c ON c.entityId = e.entityIdINNER JOIN ncim.ranMobileSwitchingCentre rmsc ON rmsc.entityId = c.entityId

Retrieve RAN connectivityThese queries retrieve the details of entities that are connected to RAN entities.


Example: connectivity of a given base station

This query retrieves the connectivity of a given base station.

1]2]3]4]5]6]

select e1.entityName BTSName,e2.entityName BTSConnectedName,e3.entityName ConnectedInt,e4.entityName ConnectedDevice,e4.entityType, ch4.className,et.entityName Topology

7]8]9]10]11]12]13]14]15]16]

from ncim.entityData e1,ncim.ranBaseStation rbs,ncim.entityData e2,ncim.connects c,ncim.topologyLinks tl,ncim.entityData et,ncim.entityData e3,ncim.entityData e4,ncim.physicalChassis ch4where

17]18]19]20]21]22]23]24]25]26]27]28]29]30]31]32]33]34]35]

(e1.entityName = ’BaseStation10’ANDe1.entityId = rbs.entityIdANDe2.mainNodeEntityId = e1.entityIdANDe2.entityId = c.aEndEntityIdANDe3.entityId = c.zEndEntityIdANDc.connectionId = tl.connectionIdANDtl.entityId = et.entityIdANDe3.mainNodeEntityId = e4.entityIdANDch4.entityId = e4.entityId)

36]37]38]39]40]41]42]43]44]45]46]47]48]49]50]51]52]

UNIONselect e1.entityName BTSName,e2.entityName BTSConnectedName,e3.entityName ConnectedInt,e4.entityName ConnectedDevice,e4.entityType, ch4.className,et.entityName Topologyfrom ncim.entityData e1,ncim.ranBaseStation rbs,ncim.entityData e2,ncim.connects c,ncim.topologyLinks tl,ncim.entityData et,ncim.entityData e3,ncim.entityData e4,ncim.physicalChassis ch4where


53]54]55]56]57]58]59]60]61]62]63]64]65]66]67]68]69]70]71]

(e1.entityName = ’BaseStation10’ANDe1.entityId = rbs.entityIdANDe2.mainNodeEntityId = e1.entityIdANDe2.entityId = c.zEndEntityIdANDe3.entityId = c.aEndEntityIdANDc.connectionId = tl.connectionIdANDtl.entityId = et.entityIdANDe3.mainNodeEntityId = e4.entityIdANDch4.entityId = e4.entityId)





v Name of the base station, represented by as e1.entityName

v Name of the connected base station, represented by e2.entityName

v Name of the connected interface, represented by e3.entityName

v Name of the connected device, represented by e4.entityName

v Class of the connected device, represented by e4.entityType

v Name of the connection, represented by et.entityName

7-15 Retrieve the data from the following tables:

v entityData

v ranBaseStation

v connects

v topologyLinks

v chassis

18 The entity name of the base station is BaseStation10.

20 Ensure that the entity is a base station.

22 Limit the results (connected devices) to entities that are main nodes.

24 Identify all the connections for the entities associated with the specifiedbase station.


28 Determine the connecting point on the other device for the connection.This is captured in e3.entityId.

30 Determine the layer in which the other connection is located. This isdetermined using the topologyLinks object.

32 Determine the entityData entry corresponding to the topology layer. Thisenables the query results to specify in which layer the connecting point onthe other device is; for example, layer 1,or layer 2.

34 Determine the chassis that the connecting point is in.

36 Use the UNION statement to ensure that all connections are retrieved.





Similar queries

The following example queries retrieve relevant data for different RANrelationships, using similar syntax to the above example.

Example: connectivity of a given Node B entity

This query retrieves the connectivity of a given Node B entity.select e1.entityName AS NodeBName,e2.entityName AS NodeBConnectedName,e3.entityName AS ConnectedInt,e4.entityName AS ConnectedDevice,e4.entityType, ch4.classNamefrom ncim.entityData e1,ncim.ranNodeB rnb,ncim.entityData e2,ncim.entityData et,ncim.topologyLinks tl,ncim.connects c,ncim.entityData e3,ncim.entityData e4, ncim.physicalChassis ch4where(e1.entityName = ’NodeB10’ANDe1.entityId = rnb.entityIdANDe2.mainNodeEntityId = e1.entityIdANDe2.entityId = c.aEndEntityIdANDe3.entityId = c.zEndEntityIdANDc.connectionId = tl.connectionIdANDtl.entityId = et.entityIdANDe3.mainNodeEntityId = e4.entityIdANDch4.entityId = e4.entityId)UNIONselect e1.entityName AS NodeBName,e2.entityName AS NodeBConnectedName,e3.entityName AS ConnectedInt,e4.entityName AS ConnectedDevice,e4.entityType,ch4.classNamefrom ncim.entityData e1,ncim.ranNodeB rnb,ncim.entityData e2,ncim.entityData et,ncim.topologyLinks tl,ncim.connects c,ncim.entityData e3,ncim.entityData e4,


ncim.physicalChassis ch4where(e1.entityName = ’NodeB10’ANDe1.entityId = rnb.entityIdANDe2.mainNodeEntityId = e1.entityIdANDe2.entityId = c.zEndEntityIdANDe3.entityId = c.aEndEntityIdANDc.connectionId = tl.connectionIdANDtl.entityId = et.entityIdANDe3.mainNodeEntityId = e4.entityIdANDch4.entityId = e4.entityId)

Example: connectivity of a given base station controller

This query retrieves the connectivity of a given base station controller.select e1.entityName AS BSCName,e2.entityName AS BSCConnectedName,e3.entityName AS ConnectedInt,e4.entityName AS ConnectedDevice,e4.entityType,ch4.classNamefrom ncim.entityData e1,ncim.ranBaseStationController rbsc,ncim.entityData e2,ncim.entityData et,ncim.topologyLinks tl,ncim.connects c,ncim.entityData e3,ncim.entityData e4,ncim.physicalChassis ch4where(e1.entityName = ’BaseStationController2’ANDe1.entityId = rbsc.entityIdANDe2.mainNodeEntityId = e1.entityIdANDe2.entityId = c.aEndEntityIdANDe3.entityId = c.zEndEntityIdANDc.connectionId = tl.connectionIdANDtl.entityId = et.entityIdANDe3.mainNodeEntityId = e4.entityIdANDch4.entityId = e4.entityId)UNIONselect e1.entityName AS BSCName,e2.entityName AS BSCConnectedName,e3.entityName AS ConnectedInt,e4.entityName AS ConnectedDevice,e4.entityType, ch4.className


from ncim.entityData e1,ncim.ranBaseStationController rbsc,ncim.entityData e2,ncim.entityData et,ncim.topologyLinks tl,ncim.connects c,ncim.entityData e3,ncim.entityData e4,ncim.physicalChassis ch4where(e1.entityName = ’BaseStationController2’ANDe1.entityId = rbsc.entityIdANDe2.mainNodeEntityId = e1.entityIdANDe2.entityId = c.zEndEntityIdANDe3.entityId = c.aEndEntityIdANDc.connectionId = tl.connectionIdANDtl.entityId = et.entityIdANDe3.mainNodeEntityId = e4.entityIdANDch4.entityId = e4.entityId)

Example: connectivity of a given radio network controller

This query retrieves the connectivity of a given radio network controller.select e1.entityName AS RNCName,e2.entityName AS RNCConnectedName,e3.entityName AS ConnectedInt,e4.entityName AS ConnectedDevice,e4.entityType,ch4.classNamefrom ncim.entityData e1,ncim.ranRadioNetworkController rrnc,ncim.entityData e2,ncim.entityData et,ncim.topologyLinks tl,ncim.connects c,ncim.entityData e3,ncim.entityData e4,ncim.physicalChassis ch4where(e1.entityName = ’radioNetworkController2’ANDe1.entityId = rrnc.entityIdANDe2.mainNodeEntityId = e1.entityIdANDe2.entityId = c.aEndEntityIdANDe3.entityId = c.zEndEntityIdANDc.connectionId = tl.connectionIdANDtl.entityId = et.entityIdANDe3.mainNodeEntityId = e4.entityIdAND


ch4.entityId = e4.entityId)UNIONselect e1.entityName AS RNCName,e2.entityName AS RNCConnectedName,e3.entityName AS ConnectedInt,e4.entityName AS ConnectedDevice,e4.entityType,ch4.classNamefrom ncim.entityData e1,ncim.ranRadioNetworkController rrnc,ncim.entityData e2,ncim.entityData et,ncim.topologyLinks tl,ncim.connects c,ncim.entityData e3,ncim.entityData e4,ncim.physicalChassis ch4where(e1.entityName = ’radioNetworkController2’ANDe1.entityId = rrnc.entityIdANDe2.mainNodeEntityId = e1.entityIdANDe2.entityId = c.zEndEntityIdANDe3.entityId = c.aEndEntityIdANDc.connectionId = tl.connectionIdANDtl.entityId = et.entityIdANDe3.mainNodeEntityId = e4.entityIdANDch4.entityId = e4.entityId)

Example: connectivity of a given media gateway

This query retrieves the connectivity of a given media gateway.select e1.entityName AS MGWName,e2.entityName AS MGWConnectedName,e3.entityName AS ConnectedInt,e4.entityName AS ConnectedDevice,e4.entityType,ch4.classNamefrom ncim.entityData e1,ncim.ranMediaGateway rmgw,ncim.entityData e2,ncim.entityData et,ncim.topologyLinks tl,ncim.connects c,ncim.entityData e3,ncim.entityData e4,ncim.physicalChassis ch4where(e1.entityName = ’MediaGateway1’ANDe1.entityId = rmgw.entityIdANDe2.mainNodeEntityId = e1.entityIdANDe2.entityId = c.aEndEntityId


ANDe3.entityId = c.zEndEntityIdANDc.connectionId = tl.connectionIdANDtl.entityId = et.entityIdANDe3.mainNodeEntityId = e4.entityIdANDch4.entityId = e4.entityId)UNIONselect e1.entityName AS MGWName,e2.entityName AS MGWConnectedName,e3.entityName AS ConnectedInt,e4.entityName AS ConnectedDevice,e4.entityType,ch4.classNamefrom ncim.entityData e1,ncim.ranMediaGateway rmgw,ncim.entityData e2,ncim.entityData et,ncim.topologyLinks tl,ncim.connects c,ncim.entityData e3,ncim.entityData e4,ncim.physicalChassis ch4where(e1.entityName = ’MediaGateway1’ANDe1.entityId = rmgw.entityIdANDe2.mainNodeEntityId = e1.entityIdANDe2.entityId = c.zEndEntityIdANDe3.entityId = c.aEndEntityIdANDc.connectionId = tl.connectionIdANDtl.entityId = et.entityIdANDe3.mainNodeEntityId = e4.entityIdANDch4.entityId = e4.entityId)

Example: connectivity of a given serving GPRS support node

This query retrieves the connectivity of a given serving GPRS support node.select e1.entityName AS SGSNName,e2.entityName AS SGSNConnectedName,e3.entityName AS ConnectedInt,e4.entityName AS ConnectedDevice,e4.entityType, ch4.classNamefrom ncim.entityData e1,ncim.ranSGSN rsgsn,ncim.entityData e2,ncim.entityData et,ncim.topologyLinks tl,ncim.connects c,ncim.entityData e3,ncim.entityData e4,ncim.physicalChassis ch4where


(e1.entityName = ’SGSN3’ANDe1.entityId = rsgsn.entityIdANDe2.mainNodeEntityId = e1.entityIdANDe2.entityId = c.aEndEntityIdANDe3.entityId = c.zEndEntityIdANDc.connectionId = tl.connectionIdANDtl.entityId = et.entityIdANDe3.mainNodeEntityId = e4.entityIdANDch4.entityId = e4.entityId)UNIONselect e1.entityName AS SGSNName,e2.entityName AS SGSNConnectedName,e3.entityName AS ConnectedInt,e4.entityName AS ConnectedDevice,e4.entityType,ch4.classNamefrom ncim.entityData e1,ncim.ranSGSN rsgsn,ncim.entityData e2,ncim.entityData et,ncim.topologyLinks tl,ncim.connects c,ncim.entityData e3,ncim.entityData e4,ncim.physicalChassis ch4where(e1.entityName = ’SGSN3’ANDe1.entityId = rsgsn.entityIdANDe2.mainNodeEntityId = e1.entityIdANDe2.entityId = c.zEndEntityIdANDe3.entityId = c.aEndEntityIdANDc.connectionId = tl.connectionIdANDtl.entityId = et.entityIdANDe3.mainNodeEntityId = e4.entityIdANDch4.entityId = e4.entityId)


Find RAN containmentThese queries retrieve the details of RAN entities that are contained, by otherentities.

Example: find all sectors within a given cell

This query retrieves the details of all sectors within a given cell. There is no directrelationship between a sector and a cell. Sectors are hosted by transceivers, andtransceivers are contained within a base station. There is a collects relationshipbetween cells and transceivers. The query also deals with fact that there are twodifferent types of cell: GSM cells and UTRAN cells.

1]2]3]4]5]6]7]8]9]10]11]12]13]14]15]16]17]18]19]20]21]22]23]24]

select e1.entityId sectorEntityId,e1.entityName sectorName,e2.entityId cellEntityId ,e2.entityName cellEntityName,COALESCE(rgc.cellid, ruc.cellid),COALESCE(rgc.rantechnologytype,’UMTS’) cellTypefrom ncim.entityData e1INNER JOIN ncim.ranSector rs ON rs.entityId = e1.entityIdINNER JOIN ncim.hostedService hs ON hs.hostedEntityId = e1.entityIdINNER JOIN ncim.entityData e3 ON e3.entityId = hs.hostingEntityIdINNER JOIN ncim.collects c ON c.collectedEntityId = e3.entityIdINNER JOIN ncim.entityData e2 ON e2.entityId = c.collectingEntityIdLEFT OUTER JOIN ncim.rangsmcell rgc ON rgc.entityId = e2.entityIdLEFT OUTER JOIN ncim.ranutrancell ruc ON ruc.entityId = e2.entityIdWHERE(e2.entityName = cell_nameAND(e2.entityType = 130ORe2.entityType = 131));





v The entity ID of the sector, represented by e1.entityId.

v The name of the sector, represented by e1.entityName

v The ID of the cell, represented by e2.entityId

v The name of the cell, represented by e2.entityName

v Use the COALESCE function to take either GSM or UTRAN cell IDs as areturn value.


8 Limit the results of the query to RAN sectors

9-10 The alias e3 identifies the hosting transceiver. The JOIN operations onthese lines limit the results to the transceiver that hosts the RAN sectors.

11-12 The alias e2 identifies the cells that collect the transceivers. The JOINoperations on these lines limit the results to the cells that collect thetransceiver, that in turn hosts the RAN sectors.




13-14 Join the two cell tables, GSM and UTRAN. Use an outer join, as one ofthese tables will be empty.

15-23 Specify the cell name and include results for GSM cells (entityType = 130)and UTRAN cells (entityType = 131).

Similar queries


Example: find contents of the RAN radio core

This query retrieves the contents of the RAN radio core.SELECT e.entityId,e.entityName, ch.className,e2.entityName RANRadioCore,rrc.mmc, rrc.mncFROM ncim.entityData eINNER JOIN ncim.physicalChassis ch ON ch.entityId = e.entityIdINNER JOIN ncim.collects c ON c.collectedEntityId = e.entityIdINNER JOIN ncim.entityData e2 ON e2.entityId = c.collectingEntityIdINNER JOIN ncim.ranRadioCore rrc ON rrc.entityId = e2.entityIdWHEREe2.entityType = 138

Example: find contents of the RAN circuit-switched core

This query retrieves the contents of the RAN circuit-switched core.SELECT e.entityId,e.entityName, ch.className,e2.entityName RANCircuitSwitchedCore,rcsc.mmc, rcsc.mncFROM ncim.entityData eINNER JOIN ncim.physicalChassis ch ON ch.entityId = e.entityIdINNER JOIN ncim.collects c ON c.collectedEntityId = e.entityIdINNER JOIN ncim.entityData e2 ON e2.entityId = c.collectingEntityIdINNER JOIN ncim.ranCircuitSwitchedCore rcsc ON rcsc.entityId = e2.entityIdWHEREe2.entityType = 137

Example: find contents of the RAN packet-switched core

This query retrieves the contents of the RAN packet-switched core.SELECT e.entityId,e.entityName, ch.className,e2.entityName RANPacketSwitchedCore,rpsc.mmc,rpsc.mncFROM ncim.entityData eINNER JOIN ncim.physicalChassis ch ON ch.entityId = e.entityIdINNER JOIN ncim.collects c ON c.collectedEntityId = e.entityIdINNER JOIN ncim.entityData e2 ON e2.entityId = c.collectingEntityIdINNER JOIN ncim.ranPacketSwitchedCore rpsc ON rpsc.entityId = e2.entityIdWHEREe2.entityType = 136


Find RAN dependenciesThese queries retrieve the details of RAN entities that are dependent upon otherRAN entities.

Example: find all cells managed by a given base station

This query retrieves the details of all cells that are managed by a given basestation.

1]2]3]4]5]6]7]8]9]10]11]12]

select e1.entityId cellEntityId,e1.entityName cellName,rc.cellid,e2.entityId btsEntityId,e2.entityName BTSname,rbs.baseStationIdfrom ncim.entityData e1INNER JOIN ncim.rangsmcell rc ON rc.entityId = e1.entityIdINNER JOIN ncim.dependency dep ON dep.dependentEntityId = e1.entityIdINNER JOIN ncim.entityData e2 ON e2.entityId = dep.independentEntityIdINNER JOIN ncim.ranBaseStation rbs ON rbs.entityId = e2.entityIdWHERE (e2.entityName = base_station_name)





v The entity ID of the cell, represented by e1.entityId.

v The name of the cell, represented by e1.entityName

v The ID of the cell, represented by rc.cellid

v The entity ID of the base station, represented by e2.entityId

v The name of the base station, represented by e2.entityName

v The identifying string of the base station, represented byrbs.baseStationId


8 Limit the results of the query to RAN GSM cells.

Do this by joining the ranGSMCell table to the entityData table using theentityId field.

9-11 Limit the results of the query to cells that have dependencies listed onentities that are RAN base stations.

12 Limit the results of the query to cells managed by the base station knownas base_station_name.

Similar queries


Example: find all cells managed by a given Node B entity

This query retrieves the details of all cells managed by a given Node B entity.


select e1.entityId cellEntityId,e1.entityName cellName, rc.cellid,e2.entityId nodeBEntityId,e2.entityName nodeBName,rnb.nodeBIdfrom ncim.entityData e1INNER JOIN ncim.ranutrancell rc ON rc.entityId = e1.entityIdINNER JOIN ncim.dependency dep ON dep.dependentEntityId = e1.entityIdINNER JOIN ncim.entityData e2 ON e2.entityId = dep.independentEntityIdINNER JOIN ncim.ranNodeB rnb ON rnb.entityId = e2.entityIdWHERE(e2.entityName = node_b_name)

Example: find all base stations managed by a given base stationcontroller

This query retrieves the details of all base stations managed by a given base stationcontroller.select e1.entityId btsEntityId,e1.entityName btsName,rbs.basestationid,e2.entityId bscEntityId,e2.entityName bscName,rbsc.baseStationControllerIdfrom ncim.entityData e1INNER JOIN ncim.ranBaseStation rbs ON rbs.entityId = e1.entityIdINNER JOIN ncim.dependency d ON d.dependentEntityId = e1.entityIdINNER JOIN ncim.entityData e2 ON e2.entityId = d.independentEntityIdINNER JOIN ncim.ranBaseStationController rbsc ON rbsc.entityId = e2.entityIdWHERE(e2.entityName = base_station_controller_name);

Example: find all Node B entities managed by a given radionetwork controller

This query retrieves the details of all Node B entities managed by a given radionetwork controller.select e1.entityId nodeBEntityId,e1.entityName nodeBName,rnb.nodeBid,e2.entityId rncEntityId,e2.entityName rncName,rrnc.rncIdfrom ncim.entityData e1INNER JOIN ncim.ranNodeB rnb ON rnb.entityId = e1.entityIdINNER JOIN ncim.dependency d ON d.dependentEntityId = e1.entityIdINNER JOIN ncim.entityData e2 ON e2.entityId = d.independentEntityIdINNER JOIN ncim.ranRadioNetworkController rrnc ON rrnc.entityId = e2.entityIdWHERE(e2.entityName = radio_network_controller_name);


Queries for hosted servicesThese queries extract data on services or applications running on specific devices.

A hosted service is a service or application running on a specific device. Forexample, a device can host BGP or OSPF services.

Find all chassis devices hosting OSPF servicesThis query identifies all devices that are hosting OSPF services. These devices areserving as routers within an autonomous system (AS). Each device identified hasan IP address and a separate OSPF router IP address.

Example

1]2]3]4]5]

SELECT e.entityName Entity_Name,o.routerId OSPF_Router_ID

FROM entityData eINNER JOIN hostedService h ON h.hostingEntityId = e.entityIdINNER JOIN ospfService o ON o.entityId = h.hostedEntityId;

Description





v The IP address of the hosting entity, represented by e.EntityName

v The ID of the hosted service, represented by o.routerID


4 Restrict the entities returned to devices that host services. Do this byjoining the hostedService table.

5 For each of the entities identified as devices hosting services, retrieve theOSPF service hosted on that device. Do this by joining the ospfServicetable to the query.

Results



Entity name OSPF router ID

172.18.1.2 22.130.159.0

172.18.2.4 22.130.53.0

router1.ibm.net 172.20.4.16

Related concepts:“Hosted services” on page 18A hosted service is a service or application running on a specific device. Forexample, a device can host BGP or OSPF services. NCIM can also model the factthat a software application, is running on a workstation.


Queries for collection informationThese queries extract data on logical collections of devices.

Device collections are logical collections of devices. Examples of logical collectionsdefined within NCIM include MPLS VPNs, global VLANs, and subnets. NCIM canalso model OSPF areas.

Show all PIM adjacenciesThis query returns details of all Protocol Independent Multicast (PIM) adjacencies.

Example

1]2]3]4]5]6]7]

SELECT eA.entityName A, eZ.entityName ZFROM topologyLinks tINNER JOIN connects c ON t.connectionId=c.connectionIdINNER JOIN entityData eA ON eA.entityId=c.aEndEntityIdINNER JOIN entityData eZ ON eZ.entityId=c.zEndEntityIdINNER JOIN entityData et ON et.entityId = t.entityIdWHERE et.entityName=’PIMTopology’;

Show PIM adjacencies for a deviceThis query shows Protocol Independent Multicast (PIM) adjacencies for a particulardevice.

Example

This example shows PIM adjacencies for the device 172.20.1.7.

1]2]3]4]5]6]7]8]9]10]

SELECT eA.entityName A, eZ.entityName ZFROM topologyLinks tINNER JOIN connects c ON t.connectionId=c.connectionIdINNER JOIN entityData eA ON eA.entityId=c.aEndEntityIdINNER JOIN entityData eZ ON eZ.entityId=c.zEndEntityIdINNER JOIN entityData et ON et.entityId = t.entityIdINNER JOIN entityData eAMain ON eAMain.entityId=eA.mainNodeEntityIdINNER JOIN entityData eZMain ON eZMain.entityId=eZ.mainNodeEntityIdWHERE et.entityName=’PIMTopology’and eAMain.entityName = ’172.20.1.7’ or eZMain.entityName = ’172.20.1.7’;

Find PIM enabled routersThis query returns a list of all routers that are enabled to use Protocol IndependentMulticast (PIM).

Example

1]2]3]4]5]6]7]

SELECT e.entityName,c.sysName,p.joinPruneInterval

FROM pimService pINNER JOIN hostedService h ON h.hostedEntityId=p.entityIdINNER JOIN entityData e ON e.entityId=h.hostingEntityIdINNER JOIN physicalChassis c ON c.entityId = e.mainNodeEntityId;


Find all devices in each subnetThis query identifies all of the subnets listed in the database. For each subnet thequery provides the netmask of that subnet and the list of IP addresses collectedwithin that subnet. The IP address collected within a subnet might refer to mainnodes or interfaces; typically, they refer to interfaces.

Example

1]2]3]4]5]6]7]

SELECT s.network Network,s.netmask Netmask,e.entityName Entity_Name

FROM subnet sINNER JOIN collects c ON c.collectingEntityId = s.entityIdINNER JOIN entityData e ON e.entityId = c.collectedEntityIdORDER BY s.network

Description





v The IP address of the collecting subnet, represented by s.network

v The netmask of the subnet, represented by s.netmask

v The name – usually an IP address – of an interface or main node withinthis subnet, represented by e.entityName

4 Use the subnet table as the driving table for this query. This enables thequery to extract all the subnets in the database.

5 Retrieve a listing of all the collected entities within each subnet. At thispoint the collected entities are identified by their entity identifier only. Thecorresponding IP address is retrieved in the next line. Do this by joiningthe collects table.

6 Extract the entity data for each interface or main node collected withineach subnet. Do this by joining the entityData table to the query. Thisenables the query to retrieve the IP address for each of the collectedentities.

7 For readability purposes, order the results by the IP address of thecollecting subnet.

Results



Network Netmask Entity name

10.1.1.0 255.255.255.0 10.1.1.6

10.1.1.0 255.255.255.0 10.1.1.8

10.1.1.0 255.255.255.0 10.1.1.9

10.1.1.0 255.255.255.0 10.1.1.25

10.1.1.0 255.255.255.0 10.1.1.26



Network Netmask Entity name

10.1.1.0 255.255.255.0 10.1.1.27

172.18.1.0 255.255.255.0 172.18.1.30

172.18.1.0 255.255.255.0 172.18.1.31

172.20.11.0 255.255.255.248 172.20.11.54

172.20.11.0 255.255.255.248 172.20.11.75

Find all devices in a given VPNThis query identifies all of the VPNs listed in the database. For each VPN thequery provides the name of that VPN and the list of IP addresses collected withinthat subnet. The IP address collected within a VPN might refer to main nodes orinterfaces; typically they refer to interfaces.

Example

1]2]3]4]5]6]7]

SELECT v.VPNName VPN_Name,v.VPNType VPN_Type,e.entityName Entity_Name

FROM networkVpn vINNER JOIN collects c ON c.collectingEntityId = v.entityIdINNER JOIN entityData e ON e.entityId = c.collectedEntityIdORDER BY v.VPNName

Description





v The IP address of the VPN, represented by v.VPNName

v The VPN type, represented by v.VPNType

v The name – usually an IP address – of an interface or main node withinthis VPN, represented by e.entityName

4 Use the networkVpn table as the driving table for this query. This enablesthe query to extract all the VPNs in the database.

5 Retrieve a listing of all the collected entities within each VPN. At this pointthe collected entities are identified by their entity identifier only. Thecorresponding IP address is retrieved in the next line. Do this by joiningthe collects table.

6 Extract the entity data for each interface or main node collected withineach VPN. Do this by joining the entityData table to the query. Thisenables the query to retrieve the IP address for each of the collectedentities

7 For readability purposes, order the results by the name of the collectingVPN.


Results



VPN name VPN type Entity name

VPN-BLUE MPLS L2 PseudoWire 172.18.1.31



VPN-GREEN MPLS L2 BGP VPN 10.1.1.26



VPN-PURPLE MPLS IP VPN RT PAIR 10.1.1.59

VPN-PURPLE MPLS IP VPN RT PAIR 10.1.1.75

VPN-RED MPLS IP VPN 172.20.11.103

VPN-RED MPLS IP VPN 172.20.11.111

VPN-WHITE MPLS IP VPN MESH 172.18.1.233

VPN-WHITE MPLS IP VPN MESH 172.18.1.240

VPN-YELLOW MPLS IP VPN 10.1.1.6




Related concepts:“Collection data” on page 17Collection data defines logical collections. Collections are defined in the collectstable. Examples of logical collections defined within NCIM include MPLS VPNs,global VLANs, and subnets.

Queries for mapping and enumeration informationThese sample queries extract mapping and enumeration data from NCIM.

Mappings and enumerations provide a means of looking up a database value innumerical or textual format and retrieving corresponding human-readable text.

Identify all the device hardware manufacturers listed in thedatabase

This query provides a list of all device manufacturers held in the topologydatabase.

The query uses the mappings table. This table provides lookups for alternativetextual names. These lookups provide more human-readable text for fields. Youcan perform lookups in the mappings table for the types of information (ormapping groups) shown in the following table.


Table 52. Mapping groups supported by the mappings table

Type of information String provided for lookupHuman-readable output oflookup

MAC vendors MAC address suffixinformation

Name of equipment vendor

Internet Assigned NumberAuthority (IANA) enterprisenumber

IANA enterprise number Name of company with anenterprise section in theSNMP object MIB

entPhysicalVendorType MIB value forentPhysicalVendorType MIBvariable

Vendor-specific hardwaretype of the physical entity

sysObjectId MIB value for sysObjectIdMIB variable

Vendor's authoritativeidentification of the networkmanagement subsystemcontained in an entity

This query identifies the list of all device manufacturers held in the topologydatabase by extracting a list of all mappings in the MACVendors mapping groupin the mappings table.

The mappings table provides string-to-string mappings, whereas the enumerationstable provides integer-to-string mappings.

Example

1]2]3]4]

SELECT DISTINCT(mappingValue) Equipment_VendorFROM mappings mWHERE mappingGroup = ’MACVendors’ORDER BY mappingValue;

Description

The following table describes this query.



1 Display the name of the equipment vendor.

This is represented by DISTINCT(mappingValue). Ensure that each name islisted only once by using the DISTINCT keyword.

2 Use the mappings table as the driving table for this query. This enables thequery to extract all the mapping data in the database.

3 Limit the mappings to those that form part of the MACVendors mappinggroup.

4 Order the results by the name of the equipment vendor.


Results

The following table shows an example of the results of this query.


Equipment vendor

360 Systems

3COM

3e Technologies International Inc.

A-TREND TECHNOLOGY CO., LTD.

Abatron AG

ABB Automation Technology Products AB, Control

Abbey Systems Ltd

ABIT CORPORATION

AboveCable, Inc.

AbsoluteValue Systems, Inc.

AC Tech corporation DBA Advanced Digital

AC&T SYSTEM CO., LTD.

ACACIA NETWORKS, INC.

Related reference:“Identify all the device hardware manufacturers listed in the database” on page 80This query provides a list of all device manufacturers held in the topologydatabase.

Show all the entity types defined in the databaseThis query provides a list of entity types configured within the topology database.Entity type data includes a numerical key, a textual name for the entity type, and acategory of entity to which the entity belongs.

Network Manager has the following entity categories:v Elementv Collectionv Servicev Protocol endpointv Topology

This query uses the entityType table. This table contains every entity type inNCIM. If you want to define a new entity type, you need to update this table toinclude the entity type.

Example

1]2]3]4]

SELECT e.entityType Entity_Type,e.typeName Entity_Name,e.metaClass Category_of_Entity

FROM entityType e;


Description

The following table describes this query.




v The numerical enumeration key value, represented by e.entityType

v The corresponding human-readable string value, represented bye.typeName

v Category of entity, represented by e.metaClass

4 All of this information is held in the entityType table.

Results

The following table shows some of the results of this query.


Entity type Entity name Category of entity

0 Unknown Element

1 Chassis Element

2 Interface Element

3 Logical Interface Element

4 localVlan Element

5 Module Element

6 PSU Element

9 Fan Element

10 Backplane Element

11 Slot Element

12 Sensor Element

Related concepts:“Topology data” on page 6When the network is discovered, both core NCIM tables and entity attribute tablesare updated with topology data. These tables include Layer 1, Layer 2, Layer 3,device structure, routing protocol, containment, and technology-specificinformation.

Extending NCIMTo store custom data on entities, and enable network operators to view customdata in network maps, extend the NCIM database.

Custom data typically comes from custom discovery stitchers that retrieve thisadditional data from an external source.


Example of extending the databaseUse this example to learn how to extend the topology database to store customdata on entities.

The following example shows a set of interface records resulting from a discoverythat used custom stitchers to look up the customer name and type from anexternal source by using the IP address of each main node device discovered.Other discovery stitchers then add these customer attributes into the ExtraInfosection of the interface records in the MODEL database.{

ObjectId=45;EntityName=’host.example.com[ 0 [ 1 ] ]’;Address=[’192.168.3.4’,’00:04:DD:0D:00:76’,’’];EntityType=2;EntityOID=’1.3.6.1.4.1.9.1.326’;ExtraInfo={

.........m_IfIndex=1;m_ifType=6;m_LocalNbrPhysAddr=00:04:DD:0D:00:76;.........<lines ommitted>.........m_CustomerName=’MyCompany’;m_CustomerType=’Internal’;

};ClassName=’Cisco’;

}{

ObjectId=53;EntityName=’host.example.com[ 0 [ 1 ] ]’;Address=[’10.10.3.5’,’00:04:DD:0D:00:77’,’’];EntityType=2;EntityOID=’1.3.6.1.4.1.9.1.326’;ExtraInfo={

.........m_IfIndex=2;m_ifType=6;m_LocalNbrPhysAddr=00:04:DD:0D:00:77;.........<lines ommitted>.........m_CustomerName=’Acme’;m_CustomerType=’External’;

};ClassName=’Cisco’;

}

Enabling polling and visualization using the custom tagsAfter you have customized discovery to add custom tags you must ensure that theNCIM topology database entityDetails table is updated with the custom tags. Thisenables you to poll and visualize devices using these custom tags.

To enable polling and visualization based on custom tags:1. Go to the $NCHOME/etc/precision directory and edit the DbEntityDetails.cfg

file.2. Uncomment the insert statement. For an example of the insert statement, see

“Sample insert statement” on page 85.


MODEL checks the ExtraInfo section of each interface record for the followingfields:v m_CustomerNamev m_CustomerType

If either field is found, the value is inserted into the NCIM topology databaseentityDetails table and is associated with an entityId that is equal to the valuespecified in the current MODEL interface record. For more information on theentityDetails table, see the IBM Tivoli Network Manager IP Edition Topology DatabaseReference.

If a MODEL interface record does not contain an m_CustomerType or anm_CustomerName attribute in the ExtraInfo section, or if either of these fields hasa NULL value, no row is added to the entityDetails table for that interface record.

Sample insert statement///////////////////////////////////////////////////////////// This file provides a means to extend the NCIM database// schema by adding key-value pair data to the database// table named entityDetails.//////// The following example assumes that a custom stitcher has been created// with the ability to populate the ExtraInfo section of chassis// entities with the name and type of each customer.//// insert into dbModel.entityDetails// (// EntityType,// EntityDetails// )// values// (// 1, -- chassis// {// CustomerName = "eval(text, ’&ExtraInfo->m_CustomerName’)",// CustomerType = "eval(text, ’&ExtraInfo->m_CustomerType’)"// }// );

You can now run a full discovery to discover your network with the custom tags.Related reference:“entityDetails” on page 138The entityDetails table allows the addition of arbitrary data about an entity in theform of key-value pairs. This enables you to extend the database to provideadditional data on entities. The entityDetails table belongs to the category entities.


Enabling visualization of custom attributes in TopovizTo enable network operators to use custom attributes in the Hop View and theNetwork Views, create a new topology database table to contain the custom data,and configure MODEL to populate the new table.

This method enables operators to use the custom attributes as follows:v To search for devices in the Hop Viewv To create new network views in the Network Views

To enable visualization of custom attributes in Topoviz:1. Create a new topology database table to contain the custom data.2. Call the first field of the new table entityID and define the field as a foreign

key to the entityData table. This ensures that the new table is linked to theinterface entity, and that the rows within the table are automatically deleted ifthe main interface is deleted.

3. Configure MODEL to populate the new table:a. Go to the NCHOME/etc/precision directory.b. Add the following lines to the DbEntityDetails.cfg file:

insert into dbModel.entityMap(

EntityFilter,TableName,FieldMap

)values(

"EntityType = 2 AND ExtraInfo->m_CustomerName IS NOT NULL","customer",{

entityId = "eval(int, ’&ObjectId’)",CustomerName = "eval(text, ’&ExtraInfo->m_CustomerName’)",CustomerType = "eval(text, ’&ExtraInfo->m_CustomerType’)"

});

Note: The EntityFilter has been chosen to match interface records. This iswhere attributes for the new customer table are expected to be found.

4. Configure Topoviz to display the new table in dropdown lists:a. Go to the $ITNMHOME/profiles/TIPProfile/etc/tnm/ directory.b. Edit the ncimMetaData.xml file by appending the following line:

<entityMetaData table="customer" manager="AllManagers" entitySearch="true"><dataField dataType="str" column="customerName"/><dataField dataType="str" column="customerType"/>

</entityMetaData>

Operators can now select the table when performing a search in the Hop Viewor when creating a new dynamic network view.

Examples

The following example shows how to add a customerName field and acustomerType field.CREATE TABLE customer(

entityId INTEGER NOT NULL,customerName VARCHAR(64) NOT NULL,customerType VARCHAR(32),


CONSTRAINT customer_pk PRIMARY KEY (entityId),

CONSTRAINT customer_fk FOREIGN KEY (entityId)REFERENCES entityData(entityId) ON DELETE CASCADE

);

CREATE TABLE customer(


CONSTRAINT customer_pk PRIMARY KEY (entityId),

CONSTRAINT customer_fk FOREIGN KEY (entityId)REFERENCES entityData(entityId) ON DELETE CASCADE

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE utf8_bin;

The following example shows how to add a customerName field and acustomerType field.CREATE TABLE customer(

entityId NUMBER(10) NOT NULL,customerName VARCHAR2(64) NOT NULL,customerType VARCHAR2(32),

--CONSTRAINT customer_pk PRIMARY KEY (entityId),

--CONSTRAINT customer_fk FOREIGN KEY (entityId)REFERENCES entityData(entityId) ON DELETE CASCADE

);

The following example shows how to add a customerName field and acustomerType field.CREATE TABLE ncim.customer(


PRIMARY KEY (entityId) CONSTRAINT customer_pk,

FOREIGN KEY (entityId)REFERENCES entityData(entityId) ON DELETE CASCADECONSTRAINT customer_fk

);


Chapter 4. NCIM topology database schemas

Use this information to understand how the relationships between topology dataare modelled.

The NCIM database has the following schemas:v Core schemav Data schema

The NCIM database schemas are represented as a set of UML diagrams that modelthe relationships between topology data. Each class and relationship shown in theUML diagrams is modeled by a table in the NCIM relational database. The UMLdiagrams are color-coded and use the following color key.

entityData

chassis

subnet

ipEndPoint

ospfService

rtExportTargets

Core ModelCore Model

Elements

Collections

Protocol End PointsProtocol End Points

Services

Attributes

Core schemaUse the following information to understand the NCIM database core schema.

The following UML diagram shows how NCIM models containment relationships.

In this diagram, the entity class has no connections to any of the other classes. Thisis intentional because the entity view is no longer part of the NCIM model as itgot split into the entityData and domainMembers classes, and their correspondingtables. However, the entity class has been maintained as a database view partly forconvenience as it makes some SQL easier to write but mainly to ensure backwardscompatibility with previous versions of the schema. The entity class is shown inthe diagram for completeness.


Table 57 describes the NCIM relationship database table and data dictionary thatcorrespond to each class and relationship in the core schema.

Table 57. Classes and relationships for the core schema

NCIM tableClass orrelationship

Related NCIM table orview Data dictionary

Collection Abstract Class Not applicable Not applicable

Figure 4. Core schema


Table 57. Classes and relationships for the core schema (continued)



collects Relationship collects “collects” on page 127

connects Relationship connects “connects” on page 128

contains Relationship contains “contains” on page 130

dependsOn Relationship entityDetails “dependency” on page131

domainMembers Class domainMembers “domainMembers” onpage 133

domainMgr Class domainMgr “domainMgr” on page133

Element Abstract Class NA NA

entity Class entity “entity” on page 151

entityClass Class entityClass “entityClass” on page135

entityData Class entityData “entityData” on page136

entityDetails Class entityDetails “entityDetails” on page138

entityNameCache Class entityNameCache “entityNameCache” onpage 139

entityType Class entityType “entityType” on page140

hostedService Relationship hostedService “hostedService” onpage 143

implementsEndPoint Relationship hostedService “protocolEndPoint” onpage 147

manager Class manager “manager” on page 144

networkPipe Class networkPipe “networkPipe” on page145

pipeComposition Class pipeComposition “pipeComposition” onpage 146

protocolEndPoint Class hostedService “protocolEndPoint” onpage 147

topologyLinks Relationship hostedService “topologyLinks” onpage 148

Data schemaIn the NCIM database, Network Manager topology data falls into differentcategories.

Chapter 4. NCIM schemas 91

BGPUse this information to understand how the NCIM database models BorderGateway Protocol (BGP).

The following UML diagram shows how NCIM models BGP.

Table 58 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model BGP.

Table 58. Classes and relationships for BGP

Item Class or relationship Data dictionary

bgpAutonomousSystem Class “bgpAutonomousSystem” onpage 161

bgpEndPoint Class “bgpEndPoint” on page 162

bgpNetwork Class “bgpNetwork” on page 165

bgpRouteAttribute Class “bgpRouteAttribute” on page 165

bgpService Class “bgpService” on page 167

chassis Class “physicalChassis” on page 228

collects Relationship “collects” on page 127

connects Relationship “connects” on page 128

contains Relationship “contains” on page 130

entity Class “entity” on page 151

hostedService Relationship “hostedService” on page 143

implementsEndPoint Class “protocolEndPoint” on page 147

interface Class “networkInterface” on page 211

topologyLinks Relationship “topologyLinks” on page 148

Related concepts:Chapter 4, “NCIM topology database schemas,” on page 89Use this information to understand how the relationships between topology dataare modelled.

Figure 5. BGP schema


CollectionsUse this information to understand how the NCIM database models devicecollections, such as subnets, VPNs, and VLANs.

The following UML diagram shows how NCIM models device collections, such assubnets, VPNs and VLANs.

Table 59 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used for modelling device collections.

Table 59. Classes and relationships for device collections


bgpAutonomousSystem Class “bgpAutonomousSystem” onpage 161

bgpNetwork Class “bgpNetwork” on page 165

Collection Abstract Class Not applicable



globalVlan Class “globalVlan” on page 186

hsrpGroup Class “hsrpGroup” on page 186

networkVpn Class “networkVpn” on page 215

ospfArea Class “ospfArea” on page 219

ospfRoutingDomain Class “ospfRoutingDomain” on page220

pimNetwork Class “Collections”

VTPDomain

subnet

Class

Class

“vtpDomain” on page 264

“subnet” on page 260


Figure 6. Device collections schema


ContainmentUse this information to learn how the NCIM database models containmentrelationships.

The following UML diagram shows how NCIM models containment relationships.

Table 60 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model containment relationships.

Table 60. Classes and relationships for containment


backplane Class backplane


Element Abstract Class Not applicable


fan Class “physicalFan” on page 233


localVlan Class “localVlan” on page 201

module Class “physicalCard” on page 225

other Class “physicalOther” on page 235

psu Class “physicalPowerSupply” on page237

sensor Class “physicalSensor” on page 238

slot Class “physicalSlot” on page 241

vlanTrunkEndPoint Class “vlanTrunkEndPoint” on page262

vpnRouteForwarding Class “vpnRouteForwarding” on page263


Figure 7. Containment schema


EndpointsUse this information to understand how the NCIM database models endpoints.

The following UML diagram shows how NCIM models protocol endpoints. Not allendpoints are shown in the diagram; see the following table for a full list ofendpoints.

Table 61 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model endpoints.

Table 61. Classes and relationships for protocol endpoints


atmEndPoint Class “atmEndPoint” on page 161

bgpEndPoint Class “bgpEndPoint” on page 162


frameRelayEndPoint Class “frameRelayEndPoint” on page183

igmpEndPoint Class “igmpEndPoint” on page 188


ipEndPoint Class “ipEndPoint” on page 191

ipMRouteEndPoint Class “ipMRouteEndPoint” on page194

mplsTETunnelEndPoint Class “mplsTETunnelEndPoint” onpage 209

pimEndPoint Class “pimEndpoint” on page 242

portEndPoint Class “portEndPoint” on page 245

protocolEndPoint Class “protocolEndPoint” on page 147

ospfEndPoint Class “ospfEndPoint” on page 219

Figure 8. Protocol endpoints schema


Table 61. Classes and relationships for protocol endpoints (continued)


vlanTrunkEndPoint Class “vlanTrunkEndPoint” on page262

vpwsEndPoint Class “vpwsEndPoint” on page 264


Geographical locationThe NCIM database models geographical locations using several database tables.

The following UML diagram shows how NCIM models geographical locations.

Table 62 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model geographical locations.

Table 62. Classes and relationships for geographical locations

NCIM table Class or relationship Data dictionary


entityData Class “entityData” on page 136

geographicLocation Class “geographicLocation” on page184

geographicRegion Class “geographicRegion” on page 185

entityData

geographicRegion

*

0..1

geographicLocation

*

0..1 *0..1

collects

collects collects

Figure 9. Geographical location schema


IP endpointsUse this information to understand how the NCIM database models InternetProtocol (IP) endpoints.

The following UML diagram shows how NCIM models IP endpoints.

Table 63 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model IP endpoints.

Table 63. Classes and relationships for IP



Collection Abstract class Not applicable






ipEndPoint Class “ipEndPoint” on page 191

protocolEndPoint Class “protocolEndPoint” on page 147

subnet Class “subnet” on page 260


Figure 10. IP endpoints schema


LTEIn the NCIM database, Network Manager LTE topology data is modelled using avariety of NCIM tables.

LTE schemaUse the following information for a high-level view of the LTE schema.

The following UML diagram shows how NCIM models LTE entities andrelationships.

The following table describes the NCIM relationship database table that correspondto each class and relationship in the LTE schema.

Table 64. Classes and relationships for the LTE schema



antennaFunction Class antennaFunction “antennaFunction” onpage 160

collects Relationship collects “collects” on page 127

contains Relationship contains “contains” on page 130

depends Relationship depends “dependency” on page131

eirFunction Class eirFunction “eirFunction” on page176

enbFunction Class enbFunction “enbFunction” on page179

PLMN

trackingArea

enbFunction mmeFunction

eUtranSector

ltePool

sgwFunction

SGSN

pgwFunction

pcrfFunction

eUtranCell antennaFunction

eirFunction

hssFunction

collectscollects collectscollects

contains

contains

depends

S1-MME

X2 S13

S6a

S3

S10S11

S4 Gx

S1-U

NCIM relationship PLMN collects other entitiesLTE Interface

Figure 11. LTE schema


Table 64. Classes and relationships for the LTE schema (continued)



eUtranCell Class eUtranCell “eUtranCell” on page180

eUtranSector Class eUtranSector “eUtranSector” on page182

hssFunction Class hssFunction “hssFunction” on page187

ltePool Class ltePool “ltePool” on page 204

mmeFunction Class mmeFunction “mmeFunction” onpage 206

pcrfFunction Class pcrfFunction “pcrfFunction” on page221

pgwFunction Class pgwFunction “pgwFunction” on page223

PLMN Class PLMN “plmn” on page 244

sgwFunction Class sgwFunction “sgwFunction” on page258

SGSN Class ranSGSN “ranSGSN” on page255

trackingArea Class trackingArea “trackingArea” on page260

LTE interfacesThe NCIM database models LTE interfaces using several database tables.

The following UML diagram shows how NCIM models the LTE interfaces.


The following table describes the NCIM relationship database tables and datadictionary that correspond to each class and relationship used to model LTEinterfaces.

Table 65. Classes and relationships for LTE interfaces

UML elementModelled by NCIMtable

Class orrelationship Data dictionary

entityData entityData Class “entityData” on page136

lteInterface lteInterface Class “lteInterface” on page202

Gx lteInterface Class “lteInterface” on page202

networkInterface networkInterface Class “networkInterface” onpage 211

OAM lteInterface Class “lteInterface” on page202

SGi lteInterface Class “lteInterface” on page202

0 .. 1

0 .. 1

0 .. 1

0 .. 1

0 .. 1

0 .. 1

0 .. 1

0 .. 1

0 .. 1

0 .. 1

0 .. 1

0 .. 1

Gx

0 .. 1 0 .. 1

networkInterface

entityData

lteInterface

inherits

OAM

SGi

X2

S1-MME

S1-U

S3 S13

S11

S10

S8

S6a

S5

S4

Figure 12. LTE interface schema


Table 65. Classes and relationships for LTE interfaces (continued)



X2 lteInterface Class “lteInterface” on page202

S1-MME lteInterface Class “lteInterface” on page202

S1-U lteInterface Class “lteInterface” on page202

S3 lteInterface Class “lteInterface” on page202



S6a lteInterface Class “lteInterface” on page202





X2 lteInterface Class “lteInterface” on page202

LTE elementsIn the NCIM database, Network Manager LTE elements are modelled using avariety of NCIM tables.

Note: Equipment Identity Register (EIR), Home Subscriber Server (HSS) and Policyand Charging Rules Function (PCRF) are not exclusively LTE elements. These threeelements service a variety of technologies, including GSM, LTE, and UMTS.However, within the NCIM topology database, these elements are currentlymodelled only within LTE. They are therefore presented in the NCIM schematogether with the other LTE elements.

Equipment Identity Register:

The NCIM database models the Equipment Identity Register (EIR) using severaldatabase tables.

The following UML diagram shows how NCIM models the EIR.


The following table describes the NCIM relationship database tables and datadictionary that correspond to each class and relationship used to model the EIR.

Table 66. Classes and relationships for EIR



collects collects Relationship “connects” on page 128

contains contains Relationship “contains” on page 130

eirFunction eirFunction Class “eirFunction” on page176



physicalChassis physicalChassis Class “physicalChassis” onpage 228

physicalInterface networkInterface

Where the entity typeof the interface has thevalue 2.

Class “networkInterface” onpage 211

Related reference:“LTE interfaces” on page 99The NCIM database models LTE interfaces using several database tables.

physicalChassis

1 1

eirFunction physicalInterface

lteInterface

entityData

collects contains

1 1

0...*

contains

0 .. * 0 .. *

hostedService

0...*

Figure 13. Equipment Identity Register (EIR) schema


Evolved NodeB:

The NCIM database models the Evolved NodeB (eNodeB) using several databasetables.

The following UML diagram shows how NCIM models the eNodeB.

The following table describes the NCIM relationship database tables and datadictionary that correspond to each class and relationship used to model theeNodeB.

Table 67. Classes and relationships for Evolved NodeB (eNodeB)





enbFunction enbFunction Class “enbFunction” on page179







Related reference:

physicalChassis

1 1

enbFunction physicalInterface

lteInterface

entityData

collects contains

1 1

0...*

contains

0 .. * 0 .. *

hostedService

0...*

Figure 14. Evolved NodeB (eNodeB) schema


“LTE interfaces” on page 99The NCIM database models LTE interfaces using several database tables.

Home Subscriber Server:

The NCIM database models the Home Subscriber Server (HSS) using severaldatabase tables.

The following UML diagram shows how NCIM models the HSS.

The following table describes the NCIM relationship database tables and datadictionary that correspond to each class and relationship used to model the HomeSubscriber Server (HSS).

Table 68. Classes and relationships for Home Subscriber Server (HSS)





hssFunction hssFunction Class “hssFunction” on page187




physicalChassis

1 1

hssFunction physicalInterface

lteInterface

entityData

collects contains

1 1

0...*

contains

0 .. * 0 .. *

hostedService

0...*

Figure 15. Home Subscriber Server (HSS) schema


Table 68. Classes and relationships for Home Subscriber Server (HSS) (continued)







Mobility Management Entity:

The NCIM database models the Mobility Management Entity (MME) using severaldatabase tables.

The following UML diagram shows how NCIM models the Mobility ManagementEntity.

The following table describes the NCIM relationship database tables and datadictionary that correspond to each class and relationship used to model MobilityManagement Entity.

Table 69. Classes and relationships for Mobility Management Entity (MME)





physicalChassis

1 1

mmeFunction physicalInterfac

lteInterface

entityData

collects contains

1 1

0...*

contains

0 .. * 0 .. *

hostedService

0...*

Figure 16. Mobility Management Entity (MME)


Table 69. Classes and relationships for Mobility Management Entity (MME) (continued)



mmeFunction mmeFunction Class “mmeFunction” onpage 206








Packet Gateway:

The NCIM database models the Packet Gateway (PGW) using several databasetables.

The following UML diagram shows how NCIM models the Packet Gateway.

The following table describes the NCIM relationship database tables and datadictionary that correspond to each class and relationship used to model PacketGateway.

physicalChassis

1 1

pgwFunction physicalInterface

lteInterface

entityData

collects contains

1 1

0...*

contains

0 .. * 0 .. *

hostedService

0...*

Figure 17. Packet Gateway (PGW) schema


Table 70. Classes and relationships for Packet Gateway (PGW)





pgwFunction pgwFunction Class “pgwFunction” on page223








Policy and Charging Rules Function:

The NCIM database models the Policy and Charging Rules Function (PCRF) usingseveral database tables.

The following UML diagram shows how NCIM models the Policy and ChargingRules Function (PCRF).

physicalChassis

1 1

pcrfFunction physicalInterface

lteInterface

entityData

collects contains

1 1

0...*

contains

0 .. * 0 .. *

hostedService

0...*

Figure 18. Policy and Charging Rules Function (PCRF) schema


The following table describes the NCIM relationship database tables and datadictionary that correspond to each class and relationship used to model the Policyand Charging Rules Function (PCRF).

Table 71. Classes and relationships for Policy and Charging Rules Function (PCRF)





pcrfFunction pcrfFunction Class “pcrfFunction” on page221








Serving Gateway:

The NCIM database models the Serving Gateway (SGW) using several databasetables.

The following UML diagram shows how NCIM models the Serving Gateway.


The following table describes the NCIM relationship database tables and datadictionary that correspond to each class and relationship used to model ServingGateway.

Table 72. Classes and relationships for Serving Gateway (SGW)





sgwFunction sgwFunction Class “sgwFunction” on page258








physicalChassis

1 1

sgwFunction physicalInterface

lteInterface

entityData

collects contains

1 1

0...*

contains

0 .. * 0 .. *

hostedService

0...*

Figure 19. Serving Gateway (SGW) schema


MPLS traffic engineered (TE) tunnelsThe NCIM database models MPLS TE tunnels using several databases.

The following UML diagram shows how NCIM models MPLS TE tunnels.

Table 73 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model MPLS TE tunnels.

Table 73. Classes and relationships for MPLS TE tunnels


chasssis Class “physicalChassis” on page 228


dependency Relationship “dependency” on page 131


hostedService Class “hostedService” on page 143


mplsTEService Class “mplsTEService” on page 207

mplsTETunnel Class “mplsTETunnel” on page 208

entity

networkPipe

protocolEndPoint elementservice

interface chassis

mplsTETunnelEndPoint mplsTESservice

mplsTETunnelResource

mplsTETunnel

mplsLSP

*

* * *

contains

1 *

implementsEndPoint

1

*

hostedService

1

0..1

dependency

1

*

1*

provides(dependency) 0..*

1

dependency1

0..1

connects

0..1 0..1

1

1..*

Figure 20. MPLS TE schema


Table 73. Classes and relationships for MPLS TE tunnels (continued)


mplsTETunnelEndPoint Class “mplsTETunnelEndPoint” onpage 209

mplsTETunnelResource Class “mplsTETunnelResource” onpage 210

mplsLSP Class “mplsLSP” on page 210

MPLS VPNsUse this information to understand how the NCIM database models Multi ProtocolLabel Switching Virtual Private Networks (MPLS VPNs).

The following UML diagram shows how NCIM models MPLS VPNs.

Table 74 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model MPLS VPNs.

Table 74. Classes and relationships for MPLS VPNs







networkVpn Class “networkVpn” on page 215

RTExportTargets Relationship “rtExportList” on page 257

RTImportTargets Relationship “rtImportList” on page 257

vpnRouteForwarding Class “vpnRouteForwarding” on page263

Related concepts:

Figure 21. MPLS VPNs schema


Chapter 4, “NCIM topology database schemas,” on page 89Use this information to understand how the relationships between topology dataare modelled.

OSPFUse this information to understand how the NCIM database models Open ShortestPath First (OSPF) protocols .

The following UML diagram shows how NCIM models OSPF.

Table 75 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model OSPFs.

Table 75. Classes and relationships for OSPF










ospfArea Class “ospfArea” on page 219

ospfEndPoint Class “ospfEndPoint” on page 219

ospfNetworkLSA Class “ospfNetworkLSA” on page 220

ospfRoutingDomain Class “ospfRoutingDomain” on page220

Figure 22. OSPF schema


Table 75. Classes and relationships for OSPF (continued)


ospfService Class “ospfService” on page 221

topologyLinks Relationship “topologyLinks” on page 148


ServicesUse this information to understand how the NCIM database models the servicesthat are offered by device interfaces, for example BGP services or OSPF services.

The following UML diagram shows how NCIM models services. Not all servicesare shown in the diagram; see the following table for a full list of services.

Table 76 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model services.

Table 76. Classes and relationships for services


bgpService Class “bgpService” on page 167



igmpService Class “igmpService” on page 190

ipMRouteService Class “ipMRouteService” on page 196

itnmService Class “itnmService” on page 199

Figure 23. Services schema


Table 76. Classes and relationships for services (continued)


mplsTEService Class “mplsTEService” on page 207

ospfService Class “ospfService” on page 221

pimService Class “pimService” on page 243

Service Abstract class Not applicable


UMTS and GSMIn the NCIM database, Network Manager UMTS and GSM topology data ismodelled using a variety of NCIM tables.

GSMThe NCIM database models GSM using several database tables.

The following UML diagram shows how NCIM models GSM.

Note: In addition to the standard relationships between entities shown in the coreschema diagram, the GSM schema diagram models extra relationships betweenRAN entities. These RAN entity relationships have been added to make it easier toprocess RAN data. For example, the dependency relationship betweenranBaseStation and ranBaseStationController was added to enable a single queryto retrieve all RAN base stations managed by a given RAN base station controller.


Table 77 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model GSM.

Table 77. Classes and relationships for GSM







physicalChasssis Class “physicalChassis” on page 228

ranBaseStationController Class “ranBaseStationController” onpage 246

ranBaseStation Class “ranBaseStation” on page 245

ranGSMCell Class “ranGSMCell” on page 248

ranPacketControlUnit Class “ranPacketControlUnit” on page252

ranSector Class “ranSector” on page 255

entityData

ranGSMCell

physicalChassis physicalChassis physicalChassis

ranBaseStationController ranBaseStation

ranPacketControlUnit

ranTransceiver ranSector

1

dependency

dependency

dependency

collects

contains

*

*

*

* *

0..1

0..1

11

1

1 hostedService

Figure 24. GSM schema


Table 77. Classes and relationships for GSM (continued)


ranTransceiver Class “ranTransceiver” on page 256

RAN collectionsThe NCIM database models RAN collections using several database tables.

The following UML diagram shows how NCIM models RAN collections.

Table 78 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model RAN collections.

Table 78. Classes and relationships for RAN collections






ranBaseStationController Class “ranBaseStationController” onpage 246

entityData

ranCircuitSwitchedCore

ranMobileSwitchingCentre

physicalChassis

1

ranRadioCore ranPacketSwitchedCore

ranMediaGateway

ranRadioNetworkController

ranBaseStationController

ranPacketControlUnit

ranSGSN

ranGGSN

ranMSS

dependency

collects

collects

collects

collects

collects

collects

collects

1 1 1 1 1 1

*

*

*

*

*

*

*

1

0..1

Figure 25. RAN collections


Table 78. Classes and relationships for RAN collections (continued)


ranCircuitSwitchedCore Class “ranCircuitSwitchedCore” onpage 246

ranGGSN Class “ranGGSN” on page 247

ranMediaGateway Class “ranMediaGateway” on page 249

ranMSS Class “ranMSS” on page 250

ranMobileSwitchingCentre Class “ranMobileSwitchingCentre” onpage 250

ranPacketControlUnit Class “ranPacketControlUnit” on page252

ranPacketSwitchedCore Class “ranPacketSwitchedCore” onpage 252

ranRadioCore Class “ranRadioCore” on page 253

ranRadioNetworkController Class “ranRadioNetworkController” onpage 254

ranSGSN Class “ranSGSN” on page 255

RAN routing and location areasThe NCIM database models RAN routing and location areas using severaldatabase tables.

A routing area is the region within which an end user can move using the dataservice without having to update the Serving GPRS Serving Nodes (SGSN). Thelocation area is the area within which an end user can move using the voiceservice without having to update the VLR (visitor location registrar, whichindicates where you are physically located). Therefore RAN routing and locationareas do not indicate geographic location but rather the responsibilities of thedevices in the system.

The following UML diagram shows how NCIM models RAN routing and locationareas.


Table 79 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model radio access networkentity location.

Table 79. Classes and relationships for radio access network entity location




ranGSMCell Class “ranGSMCell” on page 248

ranLocationArea Class “ranLocationArea” on page 249

ranRoutingArea Class “ranRoutingArea” on page 254

ranUtranCell Class “ranUtranCell” on page 256

UMTSThe NCIM database models UMTS using several database tables.

The following UML diagram shows how NCIM models UMTS.

Note: In addition to the standard relationships between entities shown in the coreschema diagram, the UMTS schema diagram models extra relationships betweenRAN entities. These RAN entity relationships have been added to make it easier toprocess RAN data. For example, the dependency relationship betweenranUtranCell and ranNodeB was added to enable a single query to retrieve allUTRAN cells managed by a given Node B entity.

entityData

ranRoutingArea

ranUtranCell

collects

*

ranLocationArea

ranGSMCell

collects

collects

collects

* * *

1 1

Figure 26. RAN location schema


Table 80 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model UMTS.

Table 80. Classes and relationships for UMTS








ranNodeB Class “ranNodeB” on page 251

ranNodeBLocalCell Class “ranNodeBLocalCell” on page251

ranRadioNetworkController Class “ranRadioNetworkController” onpage 254

ranSector Class “ranSector” on page 255

ranTransceiver Class “ranTransceiver” on page 256

entityData

ranUtranCell

physicalChassis physicalChassis

ranRadioNetworkController ranNodeB

ranTransceiver ranSector

1

dependency

dependency

collects

contains

*

*

*

* *

0..1

1

1

1 hostedService

*

ranNodeBLocalCell

0..1

dependency

1

*

contains

Figure 27. UMTS schema


Table 80. Classes and relationships for UMTS (continued)


ranUtranCell Class “ranUtranCell” on page 256

VLANsUse this information to understand how the NCIM database models virtual localarea networks (VLANs).

The following UML diagram shows how NCIM models VLANs.

Table 81 describes the NCIM relationship database tables and data dictionary thatcorrespond to each class and relationship used to model VLANs.

Table 81. Classes and relationships for VLANs






globalVlan Class “globalVlan” on page 186


entity

VlanTrunkEndPoint

connects

SVlanTrunkEndPoint

*

1

contains

1

*

contains

1

*

implementsEndPoint

contains1

*

implementsEndPoint

1

1

1

*

collects

CVlanTrunkEndPoint1*

entitychassis

globalVlan interfaceinterface

VlanTrunkEndPointlocalVlan

connects

vtpDomainvtpDomain

SVlanTrunkEndPoint

vlanCollection

1

*

collects

Figure 28. VLAN schema


Table 81. Classes and relationships for VLANs (continued)


localVlan Class “localVlan” on page 201


vlanCollection Class “vlanCollection” on page 262

vtpDomain Class “vtpDomain” on page 264

VLANTrunkEndPoint Class “vlanTrunkEndPoint” on page262



Chapter 5. Data dictionary

The NCIM topology database schema is made up of a set of relational databasetables that represent the topology model.Related concepts:“Topology data” on page 6When the network is discovered, both core NCIM tables and entity attribute tablesare updated with topology data. These tables include Layer 1, Layer 2, Layer 3,device structure, routing protocol, containment, and technology-specificinformation.

Core tablesCore tables define entities and relationships between them. Core tables do notprovide detailed attribute information on the entities.

Core tables include those tables that define the domains, for example thedomainMgr table and the domainSummary table, and also the entityData table,which provides generic information about an entity, for example entityName andentityType.

The core table models the following categories of topology data:

DomainsA domain is a scoped set of entities that are discovered and managed byan application, such as Network Manager. Domains are represented usingthe domainMgr table. Membership of entities within these domains isrepresented using the domainMembers table.

EntitiesAn entity is a topology database concept. All devices and devicecomponents discovered by Network Manager are entities. Also devicecollections such as VPNs and VLANs, as well as pieces of topology thatform a complex connection, are entities. Generic information for all entitieswithin NCIM is held within the entityData table. The entity view joinsdata from the entityData and domainMembers tables and is equivalent tothe entity table that existed in Network Manager versions 3.8 and earlier.

Containment relationshipsContainment relationships express physical and logical containment. Theserelationships are represented by the contains table.

Connectivity relationshipsConnectivity relationships are relationships between entities. Theserelationships are represented by the connects table. Other tables used todefine connectivity include the networkPipe, pipeComposition, andtopologyLinks tables.

Collection relationshipsCollection relationships enable NCIM to model collections of entities, suchas MPLS VPNs, global VLANs and subnets. The relationship is representedby the collects table.


Dependency relationshipsDependency relationships express a generic dependency relationshipbetween two entities. This relationship is represented by the dependencytable.

MappingsMappings provide a means of looking up a database value in numerical ortextual format and retrieving corresponding human-readable text.

Related concepts:“Topology data” on page 6When the network is discovered, both core NCIM tables and entity attribute tablesare updated with topology data. These tables include Layer 1, Layer 2, Layer 3,device structure, routing protocol, containment, and technology-specificinformation.

aggregatedLinkFix Pack 1

The aggregatedLink table records the entity IDs of aggregated links in LinkAggregation Groups.

The following table describes the aggregatedLink table.

Table 82. aggregatedLink table

Column name Type Constraints Description

entityId 32-bit integer Foreign key

Primary key

Not null

Automatically incrementedID that provides a uniquevalue for each aggregatedlink across all domains.

aggregationDomainThe aggregationDomain table records the timestamps of when the last aggregationfor an entity was done. If an entity is already up to date, it is not updated again.

The following table describes the aggregationDomain table.

Table 83. aggregationDomain table



Primary key

Not null

Automatically incrementedID that provides a uniquevalue for each entity acrossall domains.

domainMgrId 32-bit integer Foreign key

Primary key

Not null

The identifier of thedomain from thedomainMgr table.

createTime Not null The time that the entitywas created.

changeTime Not null The time that the entitywas updated.


CIDRinfoThe CIDRinfo table provides the means to map between different representationsof subnets and subnet masks. This table belongs to the category mappings.

The following table describes the CIDRinfo table.

Table 84. CIDRInfo table


maskBits 32-bit integer Primary key

Not null

The number of bits in themask. For example, for aclass C network, this is 24.

CIDRString 7-character string Not null The Classless Inter-DomainRouting (CIDR) notationfor the subnet. Forexample, for a class Cnetwork, this is /24.

inverseMask IP Address Not null The inverse mask for thenetwork. The inverse maskacts as a wildcard forOSPF and ACLs.

numHosts 64-bit integer Not null The number of IPaddresses in the network.For example, for a class Cnetwork this is 256.

numClassC Double precisionfloating pointnumber

Not null The number of class Cnetworks within thesubnet.

netmask 15-characterstring

Not null The subnet mask for thenetwork. For example, fora class C network this is255.255.255.0.

The following table summarizes the information in the CIDRInfo table.

Table 85. Summary of the information in the CIDRInfo table

Subnet mask Bits CIDR notation Number of hosts

0.0.0.0 0 /0 4294967296

128.0.0.0 1 /1 2147483648

192.0.0.0 2 /2 1073741824

224.0.0.0 3 /3 536870912

240.0.0.0 4 /4 268435456

248.0.0.0 5 /5 134217728

252.0.0.0 6 /6 67108864

254.0.0.0 7 /7 33554432

255.0.0.0 8 /8 (A) 16777216

255.128.0.0 9 /9 8388608

255.192.0.0 10 /10 4194304

255.224.0.0 11 /11 2097152

255.240.0.0 12 /12 1048576

Chapter 5. Data dictionary 125

Table 85. Summary of the information in the CIDRInfo table (continued)

Subnet mask Bits CIDR notation Number of hosts

255.248.0.0 13 /13 524288

255.252.0.0 14 /14 262144

255.254.0.0 15 /15 131072

255.255.0.0 16 /16 (B) 65536

255.255.128.0 17 /17 32768

255.255.192.0 18 /18 16384

255.255.224.0 19 /19 8192

255.255.240.0 20 /20 4096

255.255.248.0 21 /21 2048

255.255.252.0 22 /22 1024

255.255.254.0 23 /23 512

255.255.255.0 24 /24 (C) 256

255.255.255.128 25 /25 128

255.255.255.192 26 /26 64

255.255.255.224 27 /27 32

255.255.255.240 28 /28 16

255.255.255.248 29 /29 8

255.255.255.252 30 /30 4

255.255.255.254 31 /31 2

255.255.255.255 32 /32 1

classMembersThe classMembers table specifies the device class to which a specific entitybelongs. This table belongs to the category entities.

This table is populated only for entities that are chassis devices.

The following table describes the classMembers table.

Table 86. classMembers table



Not null

Foreign key from theentityData table. Specifiesthe entity ID of the chassisdevice.

classId 32-bit integer Foreign key

Not null

Foreign key from theentityClass table. Specifiesthe ID of the class to whichthe chassis belongs.


collectsThe collects table stores data on collections of entities, such as subnets and MPLSVPNs. This table belongs to the category collections.

The sequence column of the collects table allows collections to be ordered, ifrequired.

The following table describes the collects table.

Table 87. collects table


collectingEntityId 32-bit integer Foreign key

Not null

Foreign key from theentityData table. Specifiesthe collection instance.There is a row in this tablefor each entity within thiscollection.

collectedEntityId 32-bit integer Foreign key

Not null

Foreign key from theentityData table. Specifiesan entity within thecollection.

sequence 32-bit integer For ordered collections,specifies the sequencenumber of the collection.

Related concepts:“Collection data” on page 17Collection data defines logical collections. Collections are defined in the collectstable. Examples of logical collections defined within NCIM include MPLS VPNs,global VLANs, and subnets.

connectActionsThe connectActions table records all manual connection additions and allconnection removals, including removal of connections that were discovered ratherthan manually added.

The following table describes the connectActions table.

Table 88. connectActions table


connectActionsId 32-bit integer Primary key

Automaticallyincremented

Not null

Unique auto generatedprimary key column.

aEndEntityId 32-bit integer Foreign key

Not null

Foreign key to theentityData table. EntityIdof the A-end of theconnection.

zEndEntityId 32-bit integer Foreign key

Not null

Foreign key to theentityData table. EntityIdof the Z-end of theconnection.


Table 88. connectActions table (continued)


topologyEntityId 32-bit integer Foreign key

Not null

Foreign key to theentityData table. EntityIdof the topology for thisconnection.

unidirectional Boolean Not null

Not null

Boolean indicating if theconnection ID is directedor not.

action 6-character string Enumeration ofvalues “add” and“delete”

Not null

Indicates an action thatadded or deleted an entity.

changeTime Timestamp Not null Indicates when thisentityAction was lastupdated.

username 64-characterstring

Not null Indicates the user thatperformed the entityaction.

location 512-characterstring

Indicates location fromwhich user is logged in.

description 512-characterstring

Textual description ofreason for the connectaction.

userSpeed 64-bit integer User specified speedValuefrom connectSpeeds table.

manual Boolean Not null Indicates if the entity wasmanually added.

connectsThe connects table stores data on connectivity between devices. This table belongsto the category collections.

Each row in the connects table defines a relationship between two entities.

The connects table stores each connection as a single record. However, becausetwo entities are involved in a connection, the order of the connected entities withinthe connects table is random. One of the devices involved in the connection isconsidered to be at a notional start (or aEnd) of the connection, while the seconddevice is considered to be at a notional end (or zEnd) of the connection.

The following table describes the connects table.


Table 89. connects table


connectionId 32-bit integer Primary key

Not null


Unique

This is anautomatically-incrementedfield that must be uniquefor each connection acrossall domains.

aEndEntityId 32-bit integer Foreign key

Not null

The entityId of an interfacefrom the entityData tablegiving the notional start ofthe connection.

zEndEntityId 32-bit integer Foreign key

Not null

The entityId of an interfacefrom the entityData tablegiving the notional end ofthe connection.

unidirectional Boolean Not null

Takes one of thefollowing values:0: is not unidirectional1: is unidirectional

Indicates whether theconnection is unidirectionalor bidirectional. Currentlyall connections arebidirectional.

connectSpeedsThe connectSpeeds table stores data on connectivity speed between devices.

The connectSpeeds table stores each connection as a single record.

The following table describes the connectSpeeds table.

Table 90. connectSpeeds table


connectionId 32-bit integerPrimary key

Foreign key

Not null

The connection ID from theNCIM connects table.


Table 90. connectSpeeds table (continued)


speedType 9-bit integerPrimary key

Not null

The type of the speed ofthe connection. Thiscolumn can take one of thefollowing values:

DEFAULTThe standardspeed derivedfrom the datafrom the networkelement.

RATELIMITNot currentlyused.

USER The speedspecified by theuser.

speedValue 64-bit integerForeign key

The speed of theconnection, if known, inbits per second.

containsThe contains table stores data on physical and logical containment. This tablebelongs to the category containment.

The following table describe the contains table.

Table 91. contains table


containingEntityId 32-bit integer Foreign key

Not null

The identifier of thecontaining entity from theentityData table

containedEntityId 32-bit integer Foreign key

Not null

The identifier of thecontained entity from theentityData table

upwardConnection Boolean Unique withindomain

Takes one of thefollowing values:0: bidirectional1: unidirectional

Used by the root-causeanalysis (RCA) engine (aplug-in to the EventGateway, ncp_g_event).This field enables the RCAengine to describe theconnectivity between theentity identified by thecontainedEntityId field andother entities that share thesame containing entity.

Related reference:“localVlan” on page 201The localVlan table specifies which global VLAN the local VLAN belongs to. Alocal VLAN represents all the interfaces on a single chassis device that belong to aglobal VLAN.


dependencyThe dependency table defines a general dependency between two entities. Thistable belongs to the category dependency.

This relationship is more general than the containment and connectivityrelationships defined in other tables.

The following table describes the dependency table.

Table 92. dependency table


independentEntityId 32-bit integer Foreign key

Not null

The identifier from theentityData table of theentity on which thedependent entity depends.

dependentEntityId 32-bit integer Foreign key

Not null

The identifier of thedependent entity from theentityData table.

dependencyType Integer Not null The value identifying thetype of dependencyrelationship.

deviceFunctionThe deviceFunction table stores data on device vendors, associated device modelstogether with the role of the device model such as router, switch, and so on. Thistable belongs to the category entities.

The following table describes the deviceFunction table.

Table 93. deviceFunction table


vendorName 100-characterstring

Not null The name of a devicevendor.

vendorOID 100-characterstring

Not null The MIB object ID (OID)associated with thisvendor.

sysObjectId 100-characterstring

Primary key

Not null

The vendor's authoritativeidentification of thenetwork managementsubsystem contained inentities of this type.Provides an indication ofwhat kind of device this is.

deviceModel 150-characterstring

Not null The commercial nameassociated with this devicetype.

deviceFunction 30-characterstring

The function of the device,such as “Router,” “Switch,”“Hub,” or “Firewall.”


discoverySourceThe discoverySource table describes the source of the data discovered for an entity.In the case where there are multiple sources, for example, SNMP and an EMS, ortwo different EMSs, the table identifies all of the data sources for that entity.

In the case where there are multiple data sources for a single entity, there will bemultiple rows in the discoverySource table for that entity. The nativeId andnativeIdString fields are important, as they are the identifiers used by the EMS toidentify a given device. Network Manager might refer to the same entity in acompletely different way. For example, a DNS lookup on a retrieved IP might haveprovided a DNS name, and this DNS name would then be used to name the entityin the NCIM topology database.

The following table describes the discoverySource table.

Table 94. discoverySource table


entityId Integer not null The identifier of an entityfrom the entityData table.

managedBy 255-characterstring

The name of an elementmanager. This is usuallyeither Network Manager orthe name of an EMS.

source 14-characterstring

Source of the data. Thisfield takes one of thefollowing values:

v Unknown

v Other

v TopologyEditor

v PresetLayer

v Agent

v Collector

discoveryProtocol 13-characterstring

Protocol of the dataprovided by this discoverysource. This field takes oneof the following values:

v Unknown

v Other

v Manual

v FlatFile

v SNMP

v Telnet

v XML-RPC

v VSphere

v OtherJavaAPI

v TL1

v CORBA

nativeId Integer Identifier used by thediscovery source toidentify a given device.


Table 94. discoverySource table (continued)


nativeIdString 255-characterstring

String used by thediscovery source toidentify a given device.

managedElementId 255-characters String optionally used tohold a non-EMS specific IDfor a device. Useful wheremultiple systems need tomanage the device butmight use different EMSsto do so.

domainMembersThe domainMembers table stores information on membership of entities withindomains. This table belongs to the category domains.

The following table describes the domainMembers table.

Table 95. domainMembers table


entityId 32-bit integer Foreign keyNot nullAutomaticallyincremented

Foreign key to theentityNameCache table.


Not null

The identifier of thedomain from thedomainMgr table.

Related concepts:“entityData table and entity view” on page 14Information on entities is held in the entityData table in Network Managerversions 3.9 and later. This table replaces the entity table used in earlier versions.To ensure backward compatibility an entity view has been created to hold thesame data as the entity table from earlier versions.

domainMgrThe domainMgr table stores data on network domains. This table belongs to thecategory domains.

The following table describes the domainMgr table.

Table 96. domainMgr table


domainMgrId 32-bit integer Primary key

Not null


Unique

This is anautomatically-incrementedfield that must be uniquefor each domain.


Table 96. domainMgr table (continued)


domainName 255-characterstring

Not null The name of the domain.

creationTime Timestamp Not null The timestamp indicatingwhen the domain wascreated.

lastUpdated Timestamp Not null The timestamp indicatingwhen this domain was lastupdated.

managerName 100-characterstring

Foreign key

Not null

The application thatmanages this domain. Thisis usually NetworkManager. This is one of thenetwork managerapplications specified inthe manager table.


The textual description ofthe domain.

webtopDataSource 32-characterstring

The name of theTivoliNetcool/OMNIbus WebGUI data source thatTopoviz must connect to.The default value is NCOMS.If you change this value,then you must also edit theModelNcimDb.DOMAIN.cfgand insert the new valuethere.

domainHost 32-characterstring

Used by Topoviz tocommunicate with theNetwork Manager server.This value is automaticallyset by the ncp_modelprocess.

domainPort 32-characterstring

Used by Topoviz tocommunicate with theNetwork Manager server.This value is automaticallyset by the ncp_modelprocess.

batchUpdatePercent 8-bit integer This field is updated bythe domain managerduring batch updates.



entityActionsThe entityActions table records all manual node additions and all node removals,including removal of nodes that were discovered rather than manually added andthe swapping of nodes into and out of a domain.

The following table describes the entityActions table.

Table 97. entityActions table


entityActionsId 32-bit integer Primary key


Not null

Unique auto generatedprimary key column.


Not null

Foreign key to theentityData table.


Not null

Foreign key to thedomainMgr. Indicatesdomain that an entity wasadded to or deleted from.

action 6-character string Enumeration ofvalues “add” and“delete"

Not null

Indicates an action thatadded or deleted an entity.

changeTime Timestamp Not null Indicates when thisentityAction was lastupdated.

username 64-characterstring

Not null Indicates the user thatperformed the entityaction.

location 512-characterstring

Indicates location fromwhich user is logged in.


Textual description ofreason for the entity action.

manual Boolean Not null Indicates if the entity wasmanually added.

entityClassThe entityClass table stores information on all device classes and relationshipsbetween device classes. The table belongs to the category entities.

The following table describes the entityClass table.


Table 98. entityClass table


classId 32-bit integer Primary key

Not null


Unique

A unique field for eachclass.

className 32-characterstring

Not null The name of a class ofdevices.

superClassId 32-bit integer Foreign key The classID valueassociated with the classthat contains the deviceclass specified by theclassName value.

For example, the classIdfor the NetworkDeviceclass is 5. Because Alcateland Cisco device classesare contained in theNetworkDevice deviceclass, they have asuperClassId of 5.

classType 32-characterstring

Not null The type of device or typeof class.


Foreign key

Not null

The application thatmanages this device class.This is usually NetworkManager.

Related reference:“physicalChassis” on page 228The physicalChassis table stores the attributes of chassis entities.

entityDataThe entityData table stores data on entities. This table belongs to the categoryentities.

The following table describes the entityData table.

Table 99. entityData table


entityId 32-bit integer Foreign keyNot nullAutomaticallyincrementedUnique

Foreign key to theentityNameCache table.Must be unique for eachentity across all domains.


Table 99. entityData table (continued)


mainNodeEntityId 32-bit integer Foreign key This field is relevant onlyfor entities that are whollycontained within a singlemain node device. Thefield therefore has anon-null value only forentities that are related to asingle main node device,such as the main nodeitself, physical and logicaldevice components, orlogical interfaces (forexample IP end points orlocal VLAN entities).

entityName 255-characterstring

Not null

Unique withindomain

Name of the entity. Thisfield must be unique for allentities within a givendomain.

entityType 32-bit integer Foreign key

Not null

A lookup value thatindicates the type of entity.To look up the entity type,use the entityType table.

createTime Timestamp Not null Indicates when the entitywas created.

changeTime Timestamp Not null Indicates when this entitywas last updated.

displayLabel 255-characterstring

Not null Human-readable name tobe displayed adjacent tothis entity in a topologymap and in the NetworkViews tabular layout.


Textual description of theentity.

alias 255-characterstring

Field that can be used tostore a user-defined namefor the entity.

manual Boolean Not null

Takes one of thefollowing values:

v 0: entity wasnot manuallyadded

v 1: entity wasmanuallyadded

Default = 0

Indicates whether thisentity was discovered aspart of the discoveryprocess or was manuallyadded.


Table 99. entityData table (continued)


cdmAdminState Enumeratedvalue

16-bit integer


v 0 - Unknown:administrativestate of thiselement is notknown.

v 1 - Other:administrativestate of thiselement isknown, butdoes not matchone of thedefinedenumeratedvalues.

v 2 - Enabled:this entity hasbeen enabledfor use.

v 3 - Disabled:this entity hasbeen disabledand cannot beused.

Default value = 0

An enumeration thatcorresponds to theAdminState attribute in thecdmModelObject view. Thevalues of this are stored inthe enumerations tableunder the cdmAdminStategroup.


entityDetailsThe entityDetails table allows the addition of arbitrary data about an entity in theform of key-value pairs. This enables you to extend the database to provideadditional data on entities. The entityDetails table belongs to the category entities.

To add arbitrary data about an entity to the entityDetails table, you must firstcustomize your discovery to retrieve data from an external source, using the IPaddress of the device as a lookup.

Restriction: NCIM cannot check the constraints of any value that is stored withthe key in the entityDetails table.

On completion of a new discovery, MODEL automatically populates the NCIMtopology database. You can modify the way in which this population occurs inorder to ensure that the customer data held in the ExtraInfo section of the interfacerecords within the MODEL database is used to populate key-value pair recordswithin the entityDetails table.


The following table describes the entityDetails table.

Table 100. entityDetails table



Not null

The identifier from theentityData table of anentity. The current row ofthis table provideskey-value pair data for thisentity.

keyName 255-characterstring

Not null Name of the key part ofthe extra data. Forexample, this might be thename of the customer orlocation associated withthis device.

keyValue 1000-characterstring

Value of the key part of theextra data. For example,this might be a customertype.

Related tasks:“Extending NCIM” on page 83To store custom data on entities, and enable network operators to view customdata in network maps, extend the NCIM database.

entityNameCacheThe entityNameCache table is a lookup table that provides the entity name forevery entity in the entityData table. This table belongs to the category entities.

The following table describes the entityNameCache table.

Table 101. entityNameCache table


entityId 32-bit integer Primary key

Not null

Automatically-incrementedfield that provides aunique value for eachentity across all domains.

entityName 255-characterstring

Not null The name of the entity.

domainMgrId 32-bit integer Not null The identifier from thedomainMgr table of thedomain that contains thisentity.


entityTypeThe entityType table provides a comprehensive list of every entity type in NCIM.It belongs to the category entities.

If you want to define a new entity type, you must update the entityType table toinclude the new entity type.

The following table describes the entityType table:

Table 102. entityType table


entityType 32-bit integer Primary key

Not null

Unique field for each entitytype.

typeName 32-characterstring

Not null The name of an entitytype.

dbTable 32-characterstring

Not null The name of the NCIMdatabase table that containsattribute data for thisentity type.

metaClass Enumeratedvalue

Not null


v Element

v Collection

v ProtocolEndPoint

v Topology

v Service

v NetworkPipe

v Attribute

The category of device towhich this entity typebelongs.


Not null The application thatmanages this entity type.This is usually PrecisionIP(Network Manager).

The following table summarizes the information in the entityType table. You canuse this table to look up the value for a particular type of entity, for example, fordefining a connectivity type for use in the Hop View and Network Views.Related concepts:“Entities” on page 7A Network Manager discovery returns many different types of entity. If youunderstand the entities that you might encounter, you can more easily restrict yourqueries to return only required information.


enumerationsThe enumerations table provides a means of looking up a human-readable stringvalue by providing a numerical value. Each enumeration is defined as a key-valuepair. The enumerations table belongs to the category mapping.

Description

The following table describes the enumerations table.

Table 103. enumerations table

Column Name Type Constraints Description

enumGroup 100-characterstring

Primary key withenumKey

Not null

Groups together all thekey-name pairs that formpart of a singleenumeration.

enumKey 32-bit integer Primary key withenumGroup

Not null

Integer value used as thekey by the enumeration.

enumValue 100-characterstring

Not null Human-readable stringvalue that corresponds tothe key.

enumDescription 100-characterstring

Brief description of theenumeration.

Summary

The following table summarizes the information in the enumerations table.

Table 104. Summary of the information in the enumerations table

Enumeration group Description Example

accessProtocol Address protocol. 3 = Ipv6

altitudeUnits Positional data unit. 5 = Miles

ASN BGP ASN assignment lookups. 8406 = Cablecom

cardIfConnectorTypeEnabled

Interface connector type. 3 = RJ45

cdmAdminState CDM style administrative state of theentity.

2 = Enabled

cdmCardConfiguration CDM style card configuration state. 2 = Configured

cdmDataLinkLayerDiscovery CDM style data link layer protocol. 4 = LLDP

cdmDuplex CDM style duplex state. 2 = Auto

cdmEncapsulation CDM-style encapsulation setting. 17 = frame-relay

cdmIpAddressType CDM-style IP address type. 7 = Multicast

cdmMediaType CDM-style media type. 3 = gbic

cdmPhysType CDM-style physical entity type. 8 = sensor

cdmSlotState CDM-style slot state. 3 = connected

cdmSwitchPortMode CDM-style switch port mode. 3 = Trunk

cefcFRUPowerAdminStatus

Administrative status for a PSU 1 = on


Table 104. Summary of the information in the enumerations table (continued)


cefcFRUPowerOperStatus

Operational status of a PSU 8 = failed

cefcModuleAdminStatus

Administrative status of a card 1 = enabled

cefcModuleOperStatus

Operational status of a card 2 = ok

cefcModuleResetReason

Reason for card reset 2 = powerUp

cefcPowerRedundancyMode

Redundancy mode of PSUs 2 = redundant

cpwOperStatus Operational status of a virtual circuit. 1 = up , Ready to pass packets

cpwVcType Virtual circuit type. 9 = atmVccCell

discoveryProtocol Method used for network discovery. 5 = Telnet

discoverySource Source of network discovery data. 5 = Collector

dot3StatsDuplexStatus Duplex type. 3 = FullDuplex

duplexToLegacyNcim Legacy duplex method used withNCIM.

1 = fullDuplex

entPhysicalClass Entity MIB type of an entity 10 = port

entPhysicalIsFRU Indication of whether a component isfield replaceable

1 = true

entSensorScale Scale of a sensor 11 = mega

entSensorStatus Status of a sensor 1 = OK

entSensorThresholdEvaluation

Indication of whether to evaluatesensor threshold-crossing

1 = true

entSensorThresholdNotificationEnable

Indication of whetherthreshold-crossing should be notified

1 = true

entSensorThresholdRelation

Sensor relationship type to evaluate 1 = lessThan

entSensorThresholdSeverity

Severity of a sensorthreshold-crossing

20 = major

entSensorType Type of sensor 3 = voltsAC

ifAdminStatus Administrative status of an interface 1 = up

ifOperStatus Operational status of an interface 1 = up

ifOperStatusToOperationalStatus Mapping used to translate SNMPifOperStatus values into CDMOperationalStatus style values

1 = started

ifType Type of interface 24 = softwareLoopback

ipForwarding Is IP forwarding on? 2 = not-forwarding

jnxVpnPwStatus Status of the JNX VPN. 2 = up

mscType MSC type. 3 = MSCS

ncimDuplexToCdm Duplex method used from NCIM toCDM

2 = fullDuplex

OperationalStatusEnum Operational status 2 = started

ospfIfState OSPF interface state. 2 = loopback


Table 104. Summary of the information in the enumerations table (continued)


ospfIfType OSPF interface type 3 = pointToPoint

protocolEndPoint Protocal endpoint value 3 = layer3

ranTechnologyType Radio access network technologytype

4 = UMTS

sysServices Open Systems Interconnection (OSI)layers supported by a device

5 = physical(1) network(3)

terminationPointType Type of termination type. 2 = ctp , connection termination point

transceiverType Type of transceiver. 3 = Dedicated

TruthValue Boolean values. 2 = 0 , false

TruthValueString Textual equivalent of Boolean values. 2 = false

hostedServiceA hosted service is a service or application running on a specific main node device.The hostedService table maps a main node device, the hosting entity, to the serviceor applications that are running on that device, the hosted entities. ThehostedService table belongs to the category entities.

The following table describes the hostedService table.

Table 105. hostedService table


hostingEntityId 32-bit integer Foreign key

Not null

The identifier of a mainnode device from theentityData table. Thismain node device hosts theservice or applicationidentified byhostedEntityId.

hostedEntityId 32-bit integer Foreign key

Not null

The identifier of a serviceor application from theentityData table. Thisservice or application isrunning on the main nodedevice identified byhostingEntityId.

Related reference:“bgpService” on page 167The bgpService table represents a BGP service and includes relevant protocol data.This BGP service runs on a device, as modeled in the hostedService table.“ospfService” on page 221The ospfService table represents an OSPF service and includes relevant protocoldata. This OSPF service runs on a device, as modeled in the hostedService table.


managerThe manager table lists the applications that manage the network domains stored inNCIM, for example Network Manager. The manager table belongs to the categorydomains.

The following table describes the manager table.

Table 106. manager table



Primary key

Not null

The textual identifier ofone of the networkmanagement applicationsthat manage the networkdomains stored in NCIM.


Not null Full name and descriptiveinformation of the networkmanagement application.

version 32-characterstring

Not null The current version of thenetwork managementapplication.

contact 64-characterstring

Contact person for thenetwork managementapplication.

mappingsThe mappings table provides a means of looking up an alternative textual name. Itis used to map non-human-readable data to human-readable data. The mappingstable belongs to the category mapping.

Description

The following table describes the mappings table.

Table 107. mappings table


mappingGroup 100-characterstring

Primary key withmappingkey

Not null

Groups together all thekey-value pairs that formpart of a single mappingtype.

mappingkey 100-characterstring

Primary key withmappingGroup

Not null

Non-human readable stringvalue used as the key bythe enumeration.

mappingValue 100-characterstring

Not null Human-readable stringvalue that corresponds tothe key.

mappingDescription 1000-characterstring

Description of the itemspecified by the key-valuepair.


Summary

The following table summarizes the information held in the mappings table.

Table 108. Summary of information held in the mappings table

Mapping group Description Example

entPhysicalVendorType Physical component lookups 1.3.6.1.4.1.9.12.3.1.9.20 .33= cevCat8500m4pDs3

IANAEnterprise Internet Assigned NumbersAuthority (IANA) vendorobject Identifier (OID) tovendor name

1.3.6.1.4.1.9=Cisco Systems, Inc

MACVendors Holds partial MAC addressesthat represent theOrganizationally UniqueIdentifier (OUI)

00:02:9C = 3COM

sysObjectId Lookups for sysObjectId todevice model

1.3.6.1.4.1.318.1.3.2.6 =APC SmartUPS 2000

Related reference:“physicalChassis” on page 228The physicalChassis table stores the attributes of chassis entities.

networkPipeThe networkPipe table represents managed connections in the network. This tablebelongs to the category connectivity.

The following table describes the networkPipe table.

Table 109. networkPipe table



Not null

The identifier of a networkpipe entity from theentityData table.

connectionId 32-bit integer Foreign key

Not null

The identifier of aconnection from theconnects table.

aggregationType Enumeratedvalue

Not null

Takes one of thefollowing values:1: unknown2: no lower level3: in parallel4: in sequence

Indicates how the networkpipe is made up of othernetwork pipes. You canmodel redundancy bycombining lower-levelnetwork pipes in parallel.

Related reference:“entityDetails” on page 138The entityDetails table allows the addition of arbitrary data about an entity in theform of key-value pairs. This enables you to extend the database to provideadditional data on entities. The entityDetails table belongs to the category entities.“pipeComposition” on page 146The pipeComposition table allows a higher-level connection to be defined in termsof its lower-level connections. This table belongs to the category connectivity.


“Hierarchy modeling with the networkPipe and pipeComposition tables” on page50The networkPipe table and pipeComposition table can be used together torepresent connectivity at different layers, for example the modeling of layer 2 andlayer 3 connections.

notesThe notes table provides a means of storing textual data related to an entity. Thistable belongs to the category entities.

The following table describes the notes table.

Table 110. notes table



Not null

The identifier of an entityfrom the entityData table.

createTime Timestamp Not null The date and time of entitycreation.

note 1000-characterstring

A textual note associatedwith the entity.

pipeCompositionThe pipeComposition table allows a higher-level connection to be defined in termsof its lower-level connections. This table belongs to the category connectivity.

The pipeComposition table can be used together with the networkPipe table torepresent a hierarchy of connections.

The following table describes the pipeComposition table.

Table 111. pipeComposition table


groupComponent 32-bit integer Foreign key

Primary key withpartComponent

Not null

A foreign key from the rowin the entityData table thatrepresents the networkpipe instance.

partComponent 32-bit integer Foreign key

Primary key withgroupComponent

Not null

A foreign key from the rowin the entityData table thatrepresents the networkpipe that is part of thecomposition.

aggregationSequence 32-bit integer The sequence number ofthe composition. Forunordered paths this valuecan be null.

Related reference:“networkPipe” on page 145The networkPipe table represents managed connections in the network. This tablebelongs to the category connectivity.


“Hierarchy modeling with the networkPipe and pipeComposition tables” on page50The networkPipe table and pipeComposition table can be used together torepresent connectivity at different layers, for example the modeling of layer 2 andlayer 3 connections.

protocolEndPointThe protocolEndPoint table allows a higher-level connection to be defined in termsof lower-level connections. It associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. TheprotocolEndPoint table belongs to the category connectivity.

The following table describes the protocolEndPoint table.

Table 112. protocolEndPoint table


endPointEntityId 32-bit integer Foreign key

Not null

The identifier of an entityfrom the entityData tablethat specifiesprotocol-specificaddressing information forthis endpoint.

implementingEntityId 32-bit integer Foreign key

Not null

The identifier of an entityfrom the entityData tablethat implements thisprotocol end point. This isusually a device interface.

Related reference:“atmEndPoint” on page 161The atmEndPoint table represents a logical ATM end point and includes relevantATM data. This endpoint is implemented by a physical interface.“bgpEndPoint” on page 162The bgpEndPoint table represents a logical BGP end point and includes relevantBGP data. This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table“igmpEndPoint” on page 188The igmpEndPoint table holds information on the Internet Group MembershipProtocol (IGMP) End Points.“ipMRouteEndPoint” on page 194The ipMRouteEndPoint table holds information on the IP Multicast RoutingProtocol End Points.“mplsTETunnelEndPoint” on page 209The mplsTETunnelEndPoint table represents an MPLS TE protocol end point and isimplemented on the interface associated with the configured tunnel. The end pointreferences the associated TE tunnels unique instance id.“ospfEndPoint” on page 219The ospfEndPoint table represents an OSPF end point and includes relevant data.This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.“pimEndpoint” on page 242The pimEndPoint table represents the Protocol Independent Multicast (PIM) endpoints discovered in the network and their associated attributes.


“portEndPoint” on page 245The portEndPoint holds data about TCP/UDP endpoints found by the NMAPScanagent.“vlanTrunkEndPoint” on page 262The vlanTrunkEndPoint table represents a VLAN trunk end point and includesrelevant data. This endpoint is implemented by a physical interface, as modeled inthe protocolEndPoint table.“vpwsEndPoint” on page 264The vpwsEndPoint table represents a VPWS end point and includes relevant data.This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.“frameRelayEndPoint” on page 183The frameRelayEndPoint table represents a logical Frame Relay end point andincludes relevant data. This endpoint is implemented by a physical interface, asmodeled in the protocolEndPoint table.“ipEndPoint” on page 191The ipEndPoint table represents an IP end point and includes relevant data. Theendpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.“Protocol endpoint tables” on page 24The protocolEndPoint and ipEndPoint tables can be used in SQL queries toidentify the IP addresses that are implemented by the device interfaces.

topologyLinksThe topologyLinks table allows you to identify which connections belong to aspecific type of topology. This table belongs to the category connectivity.

Examples of distinct network topologies modeled in NCIM include:v Layer 2 topologyv Layer 3 router links: This refers to connections between routers, and therefore,

between subnets.v Pseudowire topologyv OSPF topology

The following table describes the topologyLinks table.

Table 113. topologyLinks table



Not null

The identifier of a topologytype entity from theentityData table.

connectionID 32-bit integer Foreign key

Not null

The identifier of aconnection from theconnects table.


Table 113. topologyLinks table (continued)


manual Boolean Not null


v 0: entity wasnot manuallyadded

v 1: entity wasmanuallyadded

Default = 0

Indicates whether thisentity was discovered aspart of the discoveryprocess or was manuallyadded.

Core viewsThe core views group together useful entity data that does not appear in a singletable.

discoveryOverviewThe discoveryOverview view joins data from the entityData collates timestampsfrom various sources.

The information stored in this view is accessible from the Show DiscoveryOverview right-click tool in the topology GUIs.

For more information on the Show Discovery Overview right-click tool, see theIBM Tivoli Network Manager IP Edition Discovery Guide.

The following table describes the discoveryOverview view.

Table 114. discoveryOverview view

Column name Description Containing table

classNameClass of devices to which thisdevice belongs.

entityClass

currentTime The current time is given as avisual reference aid only.

NA

entityIdForeign key to theentityNameCache table. Mustbe unique for each entityacross all domains.

entityData

entityNameIP address, DNS name, orsysName for this device. Forexample, an IP address suchas 172.20.1.7, or a DNS name,such as company-abc.net.

entityData


Table 114. discoveryOverview view (continued)


interfaceFiltered A flag to show whether thedevice has had interfacefiltering applied to it or not. Ifyou do not see all theinformation for the device thatyou expect, the informationmight have been filtered out.You can do an SNMP walk ofthe device using the MIBBrowser with the option toignore filtering.

discoveryAttributes

ipAddressIP address through which thisentity was discovered andthrough which it is monitored.

chassis

firstDiscoveryCompleteDate and time when the entitywas first uploaded to theNCIM topology database.

entityData

lastDiscoveredDate and time when theDetails agent last accessed thedevice.

chassis

lastModifiedDate and time when the lastdetected change on the devicewas reflected in the NCIMtopology database. Forexample, if an interface nameon the device changes, this isthe time at which that changewas uploaded to NCIM.

entityData

rebootTimeDate and time when thedevice was last rebooted. Thisis calculated based on thesysUpTime MIB valueretrieved from the device, soLast Reboot is only availableif the sysUpTime wasretrieved. For example, fordevices with no SNMP access,the value of Last Reboot isNULL.

Calculated based on data inthe chassis table


entityThe entity view joins data from the entityData and domainMembers tables and isequivalent to the entity table that existed in Network Manager versions 3.8 andearlier.The entity view stores data on entities and includes the domainMgrId,which the domain in which the entity is located.

The following table describes the entity view.

Table 115. entity view


entityId Foreign key to theentityNameCache table. Mustbe unique for each entityacross all domains.

entityData

mainNodeEntityId This field is relevant only forentities that are whollycontained within a singlemain node device. The fieldtherefore has a non-null valueonly for entities that arerelated to a single main nodedevice, such as the main nodeitself, physical and logicaldevice components, or logicalinterfaces (for example IP endpoints or local VLAN entities).

entityData

entityName Name of the entity. This fieldmust be unique for all entitieswithin a given domain.

entityData

domainMgrId The identifier of the domainfrom the domainMgr table.

domainMgr

entityType A lookup value that indicatesthe type of entity. To look upthe entity type, use theentityType table.

entityData

createTime Indicates when the entity wascreated.

entityData

changeTime Indicates when this entity waslast updated.

entityData

displayLabel Human-readable name to bedisplayed adjacent to thisentity in a topology map andin the Network Views tabularlayout.

entityData

description Textual description of theentity.

entityData

alias Field that can be used to storea user-defined name for theentity.

entityData

manual Indicates if the entity wasmanually added.

Related concepts:


“entityData table and entity view” on page 14Information on entities is held in the entityData table in Network Managerversions 3.9 and later. This table replaces the entity table used in earlier versions.To ensure backward compatibility an entity view has been created to hold thesame data as the entity table from earlier versions.Related reference:“entityType” on page 140The entityType table provides a comprehensive list of every entity type in NCIM.It belongs to the category entities.

interfaceDomainThe interfaceDomain view adds the domain name to the interface table. This viewis used to get the domain details of a particular interface.

The following table describes the interfaceDomain view.

Table 116. interfaceDomain view


ipAddress The IP address through whichthis entity was discovered andwill be monitored.Note: For non-IP entities, suchas layer 1 optical devices, thisfield is null.

chassis

In the chassis table, this fieldis called accessIpAddress.

ifName The name assigned to theinterface.

interface

ifDescr A description of the interface. interface


entityData


entityData


domainMgr

domainName The name of the domain inwhich the node wasdiscovered.

domainMgr

interfacesThe interfaces view provides a consolidated set of data on all device interfaces.This view groups together data that appeared together in the legacy 3.6 MySQLdatabase.

The following table describes the interfaces view. The type, constraints, anddescription are automatically inherited, where appropriate, from the tables towhich the fields belong.


Table 117. interfaces view



entityData

duplex Actual duplex of the interface.Takes one of the followingvalues:

v HalfDuplex

v FullDuplex

v Auto

v Unknown

v Other

interface

entPhysicalParentRelPos An indication of the relativeposition of this childcomponent among all itssibling components. Siblingcomponents are defined asentPhysicalEntries which sharethe same instance values ofeach of theentPhysicalContainedIn andentPhysicalClass objects.

chassis


entityData


entityData

ifAdminStatus The required state of theinterface. Takes one of thefollowing values:

v Up

v Down

v Testing

interface

ifAlias The alias for the interface. interface


ifHighSpeed An estimate of the currentbandwidth of the interface inunits of 1,000,000 bits persecond.

interface

ifIndex The index of the interface. interface

ifMTU The maximum transmissionunit for this interface.

interface


interface


Table 117. interfaces view (continued)


ifOperStatus The current operational stateof the interface. Takes one ofthe following values:

v Up

v Down

v Testing

v unknown

v dormant

v notPresent

v lowerLayerDown

interface

ifPhysAddress The physical address of theinterface.

interface

ifPromiscuousMode Indicates whether thisinterface only accepts packetsor frames addressed to thisstation. Takes one of thefollowing values:

v True

v False

interface

ifSpeed An estimate of the currentbandwidth of the interface inbits per second.

interface

ifType The interface type. interface

ifTypeString The textual string for theinterface type.

interface


chassis


isTrunkPort Indicates whether thisphysical interface is a VLANtrunk port.

interface

mainNodeEntityId This field is relevant only forentities that are whollycontained within a singlemain node device. The fieldtherefore has a non-null valueonly for entities that arerelated to a single main nodedevice, such as the main nodeitself, physical and logicaldevice components, or logicalinterfaces (for example IP endpoints or local VLAN entities).

entityData


Table 117. interfaces view (continued)


portNumber The port number for thisinterface on the chassis device.The method of determiningthe port number is dependenton the make and model of thedevice that is discovered. Forthis reason, use this valuewith caution.

interface

domainMgrId The ID for the domain towhich this interface belongs.

domainMgr

mainNodeDetailsThe mainNodeDetails view provides a consolidated set of data on all networkdevices. This view groups together data that appeared together in the legacy 3.6MySQL database.

The following table describes the mainNodeDetails view. The type, constraints, anddescription are automatically inherited, where appropriate, from the tables towhich the fields belong.

Table 118. mainNodeDetails view


className The name of a class ofdevices. The masterclassName field is in theentityClass table.

chassis

classType The type of device or type ofclass.

entityClass

description Textual description of theentity.

entityData


entityData

entPhysicalDescr A textual description ofphysical entity. This objectmust contain a string whichidentifies the manufacturer'sname for the physical entity.The value must be set to adistinct value for each versionor model of the physicalentity.

chassis

entPhysicalVendorType An indication of thevendor-specific hardware typeof the physical entity.

chassis

entityId Unique ID for each entityacross all domains.

entityData


Table 118. mainNodeDetails view (continued)



entityData


chassis


ipForwarding Indication of whether thisentity is acting as an IPgateway in respect to theforwarding of datagramsreceived by this entity but notaddressed to this entity. IPgateways forward datagrams,whereas IP hosts do not,unless the source is routedthrough the host. Takes one ofthe following values:

v forwarding

v not-forwarding

chassis

serialNumber The serial number of theentity.

chassis

sysContact The textual identification ofthe contact person for thismanaged node, andinformation on how to contactthis person. If no contactinformation is known, thevalue is the zero-length string.

chassis

sysDescr A textual description of theentity. This value must includethe full name and versionidentification of the systemhardware type, softwareoperating-system, andnetworking software.

chassis

sysLocation The physical location of thisnode, for example “telephonecloset, 3rd floor.” If thelocation is unknown, the valueis the zero-length string.

chassis

sysName An administratively-assignedname for this managed node.By convention, this is thefully-qualified domain nameof the node. If the name isunknown, the value is thezero-length string.

chassis


Table 118. mainNodeDetails view (continued)


sysObjectId The vendor's authoritativeidentification of the networkmanagement subsystemcontained in the entity.

chassis

sysServices A value that indicates the setof services that this entitypotentially offers. The value isa sum that initially takes thevalue zero. Then, for eachlayer, L, in the range 1through 7, that this nodeperforms transactions for, 2raised to (L - 1) is added tothe sum. For example, a nodethat performs only routingfunctions would have a valueof 4 (2^(3-1)). A node that is ahost offering applicationservices would have a valueof 72 (2^(4-1) + 2^(7-1)). Forthe Internet suite of protocols,values should be calculatedaccordingly:

v Layer 1: Physical, forexample repeaters)

v Layer 2: Datalink orsubnetwork, for examplebridges

v Layer 3: Internet, forexample supports IP

v Layer 4: End-to-end, forexample supports TCP

v Layer 7: Applications, forexample supports the SMTP

For systems including OSIprotocols, layers 5 and 6 canalso be considered.

chassis

sysUpTime The time (in hundredths of asecond) since the networkmanagement portion of thesystem was last reinitialized.

chassis

domainMgrId The ID for the domain towhich this device belongs.

domainMgr


interfaceDomainThe interfaceDomain view adds the domain name to the interface table. This viewis used to get the domain details of a particular interface.

The following table describes the interfaceDomain view.

Table 119. interfaceDomain view



chassis



interface



entityData


entityData


domainMgr

domainName The name of the domain inwhich the node wasdiscovered.

domainMgr

Entity attribute tablesEntity attribute tables define attributes for the entities discovered by NetworkManager, that is, layer 1, layer 2 and layer 3 entities.

If the entity is a physical element, such as a chassis or module, these are the tablesthat contain the attributes which relate specifically to that physical element, such assysDescr and sysObjectId for a chassis or serialNumber for a module. If the entityis a device collection, such as a VLAN or VPN, these tables containcollection-specific parameters, such as vlanId or vpnName.

aggregationGroupFix Pack 1

The aggregationGroup table holds information about Link Aggregation Groups(LAGs).

The following table describes the aggregationGroup table.


Table 120. aggregationGroup table


entityId 32-bit integer Not null

Primary Key

Foreign Key

Automatically incrementedID that provides a uniquevalue for each aggregatedgroup across all domains.

lagId 32-bit integer Not null The ID of the LAG.

lagName 255-characterstring

The name of the LAG.

lagMode 8-character string The mode that the LAG isoperating in. Takes one ofthe following values:

v lacp

v static

v unknown

v other

v disabled

lacpMode 7-character string The Link AggregationControl Protocol mode.Can be active or passive.

actorSystemPriority Integer The priority associatedwith the Actor's System ID.

actorSystemId 255-characterstring

The MAC address valueused as a unique identifierfor the server that containsthis LAG.

actorAdminKey Integer Administrative value of thekey for the LAG.

actorOperKey Integer Operational value of thekey for the LAG.

partnerSystemPriority Integer The priority associatedwith the Partner's SystemID.

partnerSystemId 255-characterstring

The MAC address valueused as a unique identifierfor the current protocolpartner of this LAG.

partnerAdminKey Integer Administrative value of thekey for the protocolpartner.

partnerOperKey Integer Operational value of thekey for the protocolpartner.


antennaFunctionThe antennaFunction table models the physical antenna which support eUTRANcells and sectors.

The following table describes the antennaFunction table.

Table 121. antennaFunction table


entityID Integer FOREIGN KEY

NOT NULL

The identifier of an antenna entity from theentityData table.

antennaSerialNumber

64-character string NOT NULL Unique antenna identifier.

emsDistinguishedName

255-characterstring

Distinguished name by which the antenna is knownto its element management system (EMS).

antennaHeight Float Height of the antenna above sea level in metres.

antennaDownTilt Float Antenna vertical tilt in degrees.

antennaBearing Float Bearing in degrees that the antenna is pointing in.

antennaMaxAzimuth

Float Maximum amount of change of azimuth the systemcan support. This is the change in degrees clockwisefrom bearing.

antennaMinAzimuth

Float Minimum amount of change of azimuth the systemcan support. This is the change in degrees clockwisefrom bearing.

antennaHorizontalBeamwidth

Float Power beamwidth of the antenna pattern in thehorizontal plane. A value of 360 indicates anomni-directional antenna. A single integral valuecorresponding to an angle in degrees between 0 and360.

antennaVerticallBeamwidth

Float Power beamwidth of the antenna pattern in thevertical plane. A value of 360 indicates anomni-directional antenna. A single integral valuecorresponding to an angle in degrees between 0 and360.

antennaLatitude Float Latitude of Antenna equipment associated with thesector. This is the angular distance (east and west)from the prime meridian on the earth's surface; forexample, 35.832636. The value of this attribute isdetermined based on World Geodetic System WGS84standard.

antennaLongitude Float Longitude of Antenna equipment associated with thesector. This is the angular distance (north and south)from the equator on the earth's surface; for example,78.838753. The value of this attribute is determinedbased on World Geodetic System WGS84 standard.

antennaManufacturer

64-character string Vendor or manufacturer of the antenna.

antennaModel 64-character string Vendor-specific antenna type.


atmEndPointThe atmEndPoint table represents a logical ATM end point and includes relevantATM data. This endpoint is implemented by a physical interface.

The following table describes the atmEndPoint table.

Table 122. atmEndPoint table



Not null

The identifier of a logicalATM end point from theentityData table.

VPI 32-bit integer Virtual Path Indicator (VPI)in the ATM cell header.The VPI is used togetherwith the Virtual ChannelIdentifier (VCI) to route theATM cell.

VCI 32-bit integer VCI in the ATM cellheader. The VCI is usedtogether with the VPI toroute the ATM cell.

Related reference:“protocolEndPoint” on page 147The protocolEndPoint table allows a higher-level connection to be defined in termsof lower-level connections. It associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. TheprotocolEndPoint table belongs to the category connectivity.

bgpAutonomousSystemThe bgpAutonomousSystem table stores data about a BGP autonomous system(AS), including number, name, and whether the AS is private.

The following table describes the bgpAutonomousSystem table.

Table 123. bgpAutonomousSystem table



Not null

The identifier of a BGP ASfrom the entityData table.

ASN 32-bit integer Not null The number of this BGPAS. This can be a valuebetween 1 and 65535; therange from 64512 to 65535is reserved for private use.Every AS has a unique ASnumber, which is assignedto it by an InternetRegistry or a serviceprovider.

ASName 64-characterstring

The name of this BGP AS.


Table 123. bgpAutonomousSystem table (continued)


isSingleHomed 8-bit integer Indicates whether this ASis single-homed. Asingle-homed AS reachesnetworks outside of itsdomain through a singleexit point.

isTransit 8-bit integer Indicates whether this ASis a transit AS. A transit ASadvertises routes that itlearns from other ASs. Anon-transit AS will onlyadvertise its own routes.

isPrivate 8-bit integer Indicates whether this ASis private.

bgpClusterThe bgpCluster table represents use of route reflectors within a BGP AS. This tableis currently not used.

The following table describes the bgpCluster table.

Table 124. bgpCluster table



Not null


clusterID 15-characterstring

Not null Identifier for the BGP routereflector in the clusterwhen there is more thanone route reflector in thelocal AS.

bgpEndPointThe bgpEndPoint table represents a logical BGP end point and includes relevantBGP data. This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table

The following table describes the bgpEndPoint table:

Table 125. bgpEndPoint Table



Not null


isEBGP 8-bit integer Indicates whether this is aninstance of the externalversion of BGP (eBGP).


Table 125. bgpEndPoint Table (continued)


isEBGPMultiHop 8-bit integer Normally, two routersrunning eBGP must bephysically connected. Thisfield indicates whetherthere is a logicalconnection between tworouters that are runningeBGP. For example, theremight be an intermediaterouter or interface betweenthem.

localIdentifier 15-characterstring

The unique identifier of theBGP peer router. This isoften the router identifier,for example, an IP address.Corresponds to thebgpIdentifier MIB variablein BGP4-MIB.

peerIdentifier 15-characterstring

The unique identifier of thepeer BGP router. This isoften the router identifier,for example, an IP address.Corresponds to thebgpIdentifier MIB variablein BGP4-MIB.

peerState 20-characterstring

The BGP state of theconnection, as stored in thebgpPeerState MIB variablein BGP4-MIB.

adminStatus 5-character string Not null The required state of theBGP connection.

localAddress 15-characterstring

The local IP address of theBGP connection for thisrouter. Corresponds to thebgpPeerLocalAddr MIBvariable in BGP4-MIB.

localPort 32-bit integer The local port number forthe TCP connection of theBGP connection of therouter. Corresponds to thebgpPeerLocalPort MIBvariable in BGP4-MIB.

remoteAddress 15-characterstring

The remote IP address ofthe BGP connection for thisrouter. Corresponds to thebgpPeerRemoteAddressMIB variable in BGP4-MIB.

remotePort 32-bit integer Remote port number forthe TCP connection theBGP connection of thisrouter. Corresponds to thebgpPeerRemotePort MIBvariable in BGP4-MIB.




remoteAS 32-bit integer Remote AS number of theBGP peer connected to thisrouter. The AS number canbe a value between 1 and65535; the range 64512 to65535 is reserved forprivate use. Every AS has aunique AS number, whichis assigned to it by anInternet Registry or aservice provider.Corresponds to thebgpPeerRemoteAS MIBvariable in BGP4-MIB.

connectRetryInterval 32-bit integer Time interval, in seconds,for the ConnectRetry timer.Corresponds to thebgpConnectRetryIntervalMIB variable in BGP4-MIB.

holdTime 32-bit integer Maximum amount of timeelapsed in secondsbetween receipt ofsuccessive KEEPALIVE orUPDATE messages.

holdTimeConfigured 32-bit integer Time interval in secondsfor the hold timeconfigured for this BGPspeaker with a peer.Corresponds to thebgpHoldTimeConfiguredMIB variable in BGP4-MIB.

keepAlive 32-bit integer Time in seconds for theKEEPALIVE timerestablished with the BGPpeer.

keepAliveConfigured 32-bit integer Time interval in secondsfor the KeepAlive timerconfigured for this BGPspeaker with a peer.Corresponds to thebgpPeerKeepAliveConfigured MIB variable inBGP4-MIB.

minASOrigInterval 32-bit integer Time interval in secondsfor theMinASOriginationIntervaltimer. Corresponds tothebgpPeerMinASOriginationInterval MIBvariable in BGP4-MIB.




minASRouteAdvInterval

32-bit integer Time interval in secondsfor theMinRouteAdvertisementInterval timer. Correspondsto the bgpPeerMinRouteAdvertiseMentInterval MIBvariablein BGP4-MIB.

Related reference:“protocolEndPoint” on page 147The protocolEndPoint table allows a higher-level connection to be defined in termsof lower-level connections. It associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. TheprotocolEndPoint table belongs to the category connectivity.“frameRelayEndPoint” on page 183The frameRelayEndPoint table represents a logical Frame Relay end point andincludes relevant data. This endpoint is implemented by a physical interface, asmodeled in the protocolEndPoint table.“ipEndPoint” on page 191The ipEndPoint table represents an IP end point and includes relevant data. Theendpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.

bgpNetworkThe bgpNetwork table holds a collection of BGP ASs.

The following table describes the bgpNetwork table:

Table 126. bgpNetwork table



Not null

The identifier of a BGPnetwork from theentityData table.

bgpRouteAttributeThe bgpRouteAttribute table stores data about a given BGP route such as its nexthop and prefix. These attributes affect routing decisions for the AS.

The following table describes the bgpRouteAttribute table.

Table 127. bgpRouteAttribute table



Not null


AFI 30-characterstring

Address Family Identifier(AFI)information for this BGProute.


Table 127. bgpRouteAttribute table (continued)


SAFI 30-characterstring

Subsequent AddressFamily Identifier (SAFI)information for this BGProute.

prefix 15-characterstring

IP prefix for the advertizednetwork. Corresponds tothebgp4PathAttripAddrPrefixMIB variable in BGP4-MIB.

prefixLength 8-bit integer CIDR prefix length of theadvertized network.Corresponds to thebgp4PathAttripAddrPrefix-Length MIB variable inBGP4-MIB.

peerAddress 15-characterstring

IP address of the BGP peerfrom which this path waslearned.

nextHop 15-characterstring

Next hop IP address of theeBGP to reach a givennetwork. Corresponds tothe bgp4PathAttrNextHopMIB variable in BGP4-MIB.

origin 15-characterstring

Origin of this BGP route.

localPreference 32-bit integer Local preference of a routewith respect to other routesto the same destination.Higher value indicates apreferred route.Corresponds to thebgp4PathAttrLocalPref MIBvariable in BGP4-MIB.

aggregatingAddr 15-characterstring

Aggregating address forthis route.

aggregatingAS 32-bit integer AS number of the lastBGP4 speaker thatperformed routeaggregation. The ASnumber is a value between1 and 65535; the range64512 to 65535 is reservedfor private use. Every AShas a unique AS number,which is assigned to it byan Internet Registry or aservice provider.Corresponds to thebgp4PathAttrAggregatorASMIB variable in BGP4-MIB.


Table 127. bgpRouteAttribute table (continued)


ASPathSegment 100-characterstring

Sequence of AS pathsegments to a givennetwork. Corresponds tothe bgp4PathAttrASPathMIB variable in BGP4-MIB.

atomicAggregate 40-characterstring

Indicates whether a lessspecific route is selectedinstead of amore specific route.Corresponds to thebgp4PathAttrAtomic-AggregrateMIB variable in BGP4-MIB.

MED 8-bit integer Multi-Exit Discriminator(MED) value that indicatesa preferred entry point intothe AS for a givennetwork. Lower MEDvalues are preferred.Corresponds to thebgp4PathAttrMultiExitDiscMIB variable in BGP4-MIB.

bestRoute 10-characterstring

Indicates whether thisroute was chosen as thebest BGP4 route.

peerType 10-characterstring

Peer type for this BGProute attribute.

bgpServiceThe bgpService table represents a BGP service and includes relevant protocol data.This BGP service runs on a device, as modeled in the hostedService table.

Each row in this table corresponds to a single hosted BGP service. BGP routers canonly host one BGP service.

The following table describes the bgpService table.

Table 128. bgpService table



Not null

The identifier of a BGPservice from theentityData table.

BGPVersion 6-character string Not null Negotiated BGP versionnumber. Each peernegotiates this versionnumber from the vectorcontained in thebgpVersion MIB variablewithin the BGP4-MIB.

BGPLocalAS 32-bit integer Not null Local AS for this BGPservice.


Table 128. bgpService table (continued)


BGPIdentifier 15-characterstring

Not null Identifier for this BGPservice.

RouteReflectorMode 25-characterstring

Not null Router reflector mode forthis BGP service.

Related reference:“hostedService” on page 143A hosted service is a service or application running on a specific main node device.The hostedService table maps a main node device, the hosting entity, to the serviceor applications that are running on that device, the hosted entities. ThehostedService table belongs to the category entities.

computerSystemThe computerSystem table represents the logical or virtual perspective of thephysical device

The following table describes the computerSystem table.

Table 129. computerSystem table


entityId Integer not null The identifier of acomputerSystem entityfrom the entityData table.

architecture 255-characterstring

Architecture of the device.Valid values are

v alpha

v i686

v sun4

v PowerPC®

v PowerPC_POWER3

v PowerPC_POWER4

v PowerPC_POWER5

v PowerPC_604

v HP PA-RISC

assetID 255-characterstring

Asset identifier for thisentity.

assetTag 255-characterstring

Asset tag for this entity.

autoStart Tiny integer Indicates whether thecomputer system can beautomatically started.

v TRUE: computer systemcan be automaticallystarted.

v FALSE: computer systemcannot be automaticallystarted.


Table 129. computerSystem table (continued)


availableMemForAllVMs

64-bit integer Amount of memory (inbytes) currently availablefor all virtual machines.

bootOrder 255-characterstring

Boot sequence settings of asystem. The colon (:)character is used to delimitmultiple device names.Possible values for thisattribute are as follows:

v Hard Drive x (where x isoptional and is aninteger value startingfrom 0).

v DVD x.

v CD x.

v LAN PXE (including allvariants such as MBA,IGA and others).

ciCategory 255-characterstring

Configuration itemcategory for this entity.

ciRole Tiny integer Identifies the environment,or role, in which aconfiguration item (CI)resides. For example, if aCI is set aside for testpurposes, then this columncan be set to a value ofTest. If a role is neededthat is not defined in theenumeration for ciRole,then use the value Other.

cpuLimit 64-bit integer Maximum amount of CPUthat can be used by thisvirtual machine even ifthere is more CPUavailable in the resourcepool.

cpuReservation 64-bit integer Amount of CPU that isreserved for this virtualmachine.




cpuSharesLevel Tiny integer Level of shares specifiedfor this virtual machine.Shares define the relativepriority or importance of avirtual machine within aspecific Hypervisor. Eachvirtual machine is entitledto resources in proportionto its specified shares,bounded by its reservationand limit. A virtualmachine with twice asmany shares as another isentitled to twice as manyresources. The values arecomparable only acrossVMs that are virtualizingthe same ComputerSystem.

cpuSharesValue 64-bit integer Actual number of CPUshares allocated to thisvirtual machine or resourcepool. It is used only whenthe level of CPU shares(defined by theCPUSharesLevel attribute)is set to the value Custom.

cdpDeviceId 255-characterstring

Device ID defining thenode for the CiscoDiscovery Protocol. Thisattribute is Cisco-specificand will move to a classrepresenting the CiscoComputer System.

configLastUpdate 255-characterstring

UTC date and time whenthe information was lastaltered in the sourceapplication.

currentMemForAllVMs 64-bit integer Amount of memorycurrently allocated for allvirtual machines.

generalCIRole 255-characterstring

Environment, or role, inwhich a configuration item(CI) resides.




isVMIDanLPAR Tiny integer Specifies if the computersystem is a LogicalPARtition (LPAR) or if thecomputer system is usingother virtual machinetypes, such as a centralprocessor complex (CPC) .An LPAR represents allIBM mainframe andnon-mainframevirtualization technologies,including zSeries, pSeries,iSeries®, and DS8000®.Possible value are:

v TRUE: computer systemis an LPAR.

v FALSE: computer systemis using a virtualmachine type other thanan LPAR.

lastAuditState Tiny integer Last audit state for thisdevice. Possible values are:

v 0 Unknown

v 1 Other

v 2 Good

v 3 No Physical CI

v 4 No CMDB Record

v 5 Inaccurate CMDBRecord

lastAuditTime Timestamp Last audit time this entity.

lastLifecycleStateTime Timestamp Last lifecycle state time forthis entity.




lifecycleState Tiny integer Lifecycle state for thisdevice. Possible values are:

v 0 Unknown

v 1 Other

v 2 Ordered

v 3 Received

v 4 In Test

v 5 Tested

v 6 Installed

v 7 Enabled

v 8 Disabled

v 9 In Maintenance

v 10 Retired

v 11 Archived

v 12 Accepted

v 13 Draft

v 14 Build

v 15 Validate

v 16 ProductionReady

v 17 Production

v 18 Sunset

v 19 PostProduction

v 20 Inventory

v 21 Development

v 22 Offline

manufacturer 255-characterstring

Vendor-specific hardwaretype for this entity.

memoryLimit 64-bit integer Last audit time this device.

memoryReservation 64-bit integer Amount of memory that isreserved for this machine.

memorySharesLevel Tiny integer level of memory sharesspecified for this virtualmachine. Shares define therelative priority orimportance of a virtualmachine. Each virtualmachine is entitled toresources in proportion toits specified shares,bounded by its reservationand limit. A virtualmachine with twice asmany shares as another isentitled to twice as manyresources.

memorySize 64-bit integer Size of physical memorythat is present in thecomputer system.




model 255-characterstring

Model name for this entity.

name 255-characterstring

The textual name of thephysical entity. The valueof this object must be thename of the component asassigned by the localdevice and is suitable foruse in commands enteredat the console of thedevice. Depending on thephysical componentnaming syntax of thedevice, this value might bea text name, for exampleconsole, or a singlecomponent number, forexample a port number ora module number.

namingRuleAlgorithms 255-characterstring

Proprietary attribute, usedinternally by IBM TivoliApplication DependencyDiscovery Manager.

primaryMACAddress 255-characterstring

MAC Address of thenetwork adapter in thecomputer system. If thereare multiple networkadapters in the computersystem, the primary MACAddress is determined byordering the MAC addressaccording to their numericvalue, selecting the lowestvalued MAC address.

processCapacityUnits Tiny integer Units in which theProcessingCapacity fieldvalue is expressed.

processingCapacity Floating-pointnumber

Processing capacity of thiscomputer system,including all of the CPUsassigned to it.

romVersion 255-characterstring

ROM (Read-Only Memory)or the BIOS (BasicInput/Output System)version of the motherboardin the computer system.

serialNumber 255-characterstring

The serial number of theentity.

serviceConsoleMemSize 64-bit integer Amount of memory that isreserved for the serviceconsole.




signature 255-characterstring

Signature of the computersystem. The value iscomposed as follows: thedot-notated IP address, the( character, the MACAddress in hexadecimalwith upper case charactersonly (sans hashes), the)character.

swapMemSize 64-bit integer Memory size of a datastoreon which the virtualmachine swap files areallocated.

systemBoardUUID 255-characterstring

Specifies the burned-inGlobally Unique Identifier(GUID) of this piece ofequipment.

systemId 255-characterstring

Field used by IBM TivoliApplication DependencyDiscovery Manager.

cdmType 255-characterstring

Common data model typefor this device.

uuid 255-characterstring

Unique identifier of thispiece of equipment.

vmid 255-characterstring

Unique identifier for thevirtual machine. Itcorresponds to the VirtualMachine ID in the VMtable.

virtual Tiny integer Specifies whether thiscomputer system is virtual.Possible values are:

v TRUE: computer systemis virtual.

v FALSE: computer systemis not virtual.

vmotionEnabled Tiny integer Specifies whether theVMWare VMotion featureis enabled on thiscomputer system.


controlPlaneViewCollectionThe controlPlaneViewCollection table supports the dynamic collection viewsunder LTE Network Topology > Control Plane by Tracking Area in the NetworkViews. Each instance of this entity type collects the eNodeBs in the correspondingtracking area, together with the devices that these eNodeBs are connected to on thecontrol plane..

The following table describes the controlPlaneViewCollection table.

Table 130. controlPlaneViewCollection table


entityId Integer FOREIGN KEY

NOT NULL

The identifier of ancontrolPlaneViewCollectionentity from the entityDatatable.

viewType 64-character string NOT NULL Specifies the type of view.

cpuThe cpu table describes Central Processing Units (CPUs).

The following table describes the cpu table.

Table 131. cpu table



Not null

The identifier of a CPUfrom the entityData table.

serialNumber Varchar (100) The serial number of theprocessor.

modelName Varchar (100) The model of theprocessor.

manufacturer Varchar (100) The manufacturer of theprocessor.

cpuSpeed Big int The clock speed of theprocessor.

coresEnabled Integer How many cores areenabled.

coresInstalled Integer How many cores areinstalled.

discoveryAttributesThe discoveryAttributes table stores data that shows whether a device has beensubject to interface filtering.

The following table describes the discoveryAttributes table.


Table 132. discoveryAttributes table


entityId IntegerPrimary key

Not null

The entity ID of the device.

interfaceFiltered Boolean integer Not null A flag showing whetherthe SNMP informationfrom the device had aninterface filter applied to it.If the value is 1, then theinformation was filtered.The default is zero.

domainSummaryThe domainSummary table stores statistical data on a given domain.

The following table describes the domainSummary table.

Table 133. domainSummary table



Not null

An automatically-incremented field thatmust be unique for eachdomain.

createTime Timestamp Not null The date and time that thedomain was created.

changeTime Timestamp Not null The date and time that thedomain was changed.

entityCount 32-bit integer Not null The number of entities inthe domain.

chassisCount 32-bit integer Not null The number of main nodechassis devices in thedomain.

interfaceCount 32-bit integer Not null The number of interfacesin the domain.

eirFunctionThe eirFunction table models the Equipment Identity Register (EIR). The EIRkeeps track of mobile devices which should either be banned from using thenetwork or monitored. When a mobile phone is stolen its identity it is added to theEIR blacklist and the result is that this phone will never be able to attach to thenetwork for service. Usually each network has its own EIR which is oftencombined with the HSS node. It is possible for multiple operators to share acommon EIR which enables the blacklisted information to be more easily andwidely available.

The following table describes the eirFunction table.


Table 134. eirFunction table



NOT NULL

The identifier of an eirFunction entity from theentityData table.

eirFunctionName 64-character string NOT NULL Name of the eirFunction (Equipment IdentityRegister) instance configured on the physicalnode that implements the eirFunction.

MCC 3-character string An EIR can support multiple PLMNs. TheMCC attribute specifies the Mobile CountryCode (MCC) of the primary PLMN supportedby the EIR. Primary PLMN usually means thesole PLMN or the PLMN of the operatorresponsible for the operation and maintenanceof the EIR. The MCC consists of three digits.

MNC 3-character string An EIR can support multiple PLMNs. TheMNC attribute specifies the Mobile NetworkCode (MNC) of the primary PLMN supportedby the EIR. Primary PLMN usually means thesole PLMN or the PLMN of the operatorresponsible for the operation and maintenanceof the EIR. The length of the MNC (two orthree digits) depends upon the value of theMCC.

supportedPLMNs Integer Count of the number of PLMNs (Public LandMobile Networks) supported by the EIR.

emsDistinguishedName 255-character string Distinguished name by which the EIR is knownto its element management system (EMS)

emsIpAddress 39-character string IP address of the element management system.

vendorName 64-character string Vendor or manufacturer of the EIR.

vendorModuleType 64-character string Vendor specific EIR Type.

softwareVersion 64-character string Vendor specific EIR sofware version.

operationalState Enumeration Operational state of the eirFunction. Takes oneof the following values:

v Enabled

v Disabled

v Other

v Unknown

administrativeState Enumeration Administrative state of the eirFunction. Takesone of the following values:

v Unlocked

v Locked

v Shutting Down

v Other

v Unknown


emsSystemThe emsSystem table describes EMS system entities.

The following table describes the emsSystem table.

Table 135. emsSystem table


entityId Integer not null The identifier of an EMSsystem entity from theentityData table.

collectorPort Integer Port number on the EMScollector used to retrievedata.

collectorhost 64-characterstring

EMS host identifier string

collectorSourceIdInteger Source identifier for the

collector.

emsHost255-characterstring

Hostname of the EMS.

emsName255-characterstring

Name of the EMS.

emsVersion255-characterstring

Version of the EMS.

emsIdentifier255-characterstring

Identifier for the EMS andkey for integrating theNetwork Manager collectorwith the NetcoolConfiguration Managerdriver.

emsRole7-character string Role of the EMS. This

parameter can take one ofthe following values:

v unknown

v primary

v backup

v other

emsStatus7-character string Status of the EMS. This

parameter can take one ofthe following values

v unknown

v up

v down

v other


enbFunctionThe enbFunction table models the role of the eNodeB entity within a networkhardware node. Multiple enbFunction instances may be implemented within asingle network hardware node. The eNodeB entity manages radio air interfacecommunication with users of the LTE network. Each eNodeB controls one or morecells which are geographic areas of radio coverage.

The following table describes the enbFunction table.

Table 136. enbFunction table



NOT NULL

The identifier of an enbFunctionentity from the entityData table.

eNodeBId 64-character string NOT NULL Identifier of the eNodeB.

eNodeBName 64-character string NOT NULL User friendly name of the eNodeB.

MCC 3-character string An eNodeB can support multiplePLMNs. The MCC attributespecifies the Mobile Country Code(MCC) of the primary PLMNsupported by the eNodeB. PrimaryPLMN usually means the solePLMN or the PLMN of the operatorresponsible for the operation andmaintenance of the eNodeB. TheMCC consists of three digits.

MNC 3-character string An eNodeB can support multiplePLMNs. The MNC attributespecifies the Mobile Network Code(MNC) of the primary PLMNsupported by the eNodeB. PrimaryPLMN usually means the solePLMN or the PLMN of the operatorresponsible for the operation andmaintenance of the eNodeB. Thelength of the MNC (two or threedigits) depends upon the value ofthe MCC.

supportedPLMNs Integer Count of the number of PLMNs(Public Land Mobile Networks)supported by the enbFunction.

emsDistinguishedName 255-character string Distinguished name by which theenbFunction is known to its elementmanagement system (EMS).

emsIpAddress 39-character string IP address of the elementmanagement system.

vendorName 64-character string Vendor or manufacturer of theenbFunction.

vendorModuleType 64-character string Vendor-specific eNodeB type.

softwareVersion 64-character string Vendor-specific eNodeB softwareversion.


Table 136. enbFunction table (continued)


userCapacity Integer Maximum number of active piecesof user equipment (UEs) that canconnect to this eNodeBsimultaneously.

maximumOutputPower Float Maximum output power of theeNodeB.

operationalState Enumeration Operational state of theenbFunction. Takes one of thefollowing values:

v Enabled

v Disabled

v Other

v Unknown

administrativeState Enumeration Administrative state of theenbFunction. Takes one of thefollowing values:

v Unlocked

v Locked

v Shutting Down

v Other

v Unknown

backHaulConnection 39-character string IP address of the first hop backhauldevice to which the enbFunction isconnected; for example, the IPaddress of a cell-site router.

eUtranCellThe eUtranCell table models a geographical area of radio coverage that isimplemented and supported by physical radio equipment, such as towers,amplifiers, and antennas.

The following tables describes the eUtranCell table.

Table 137. eUtranCell table


entityId Integer FOREIGNKEY

NOT NULL

The identifier of an eUtranCell entity from theentityData table.

eUtranCellId 64-characterstring

NOT NULL Uniquely identifies a cell within a PLMN. It is oftenconstructed from eNodeB ID + Physical Cell ID.

eUtranCellName 64-characterstring

NOT NULL Cell identifier or name of the cell.


Table 137. eUtranCell table (continued)


physicalCellID Integer Physical cell identifier. Takes a value in the range 0 to503. The physical cell id is used by the cell to encode anddecode the data that it transmits. It is used in a similarway to the UMTS scrambling code. To avoid interference,neighboring cells should have different physical cellidentifiers. The physical cell id is derived from theprimary and secondary synchronization signals (PSS andSSS). The PSS takes a value from 0 to 2, the SSS takes avalue from 0 to 167, and the physical cell id isdetermined based on the following formula:

PSS + 3*SSS

The result of this calculation equates to a value ofbetween 0 and 503.

localCellId Integer Local cell id unique within the eNodeB.

emsDistinguishedName 255-characterstring

Distinguished name by which the eUtranCell is known toits element management system (EMS).

channelBandwidthUI Integer Uplink channel bandwidth. Takes one of the followingvalues in MHz

v 3

v 5

v 10

v 15

v 20

channelBandwidthDI Integer Downlink channel bandwidth. Takes one of the followingvalues in MHz

v 3

v 5

v 10

v 15

v 20

maximumOutputPower Float Maximum power in Watts for the sum of all downlinkchannels that are allowed to be used simultaneously in acell.

userCapacity Integer Maximum number of pieces of user equipment (UEs)that can connect to this eUtranCell simultaneously.

earfcnDl Integer E-UTRA Absolute Radio Frequency Channel Number(downlink). An integer value which identifies thedownlink carrier frequency of the cell.

earfcnUl Integer E-UTRA Absolute Radio Frequency Channel Number(uplink). An integer value which identifies the uplinkcarrier frequency of the cell.

TAI 64-characterstring

Tracking area identifier of the cell. This corresponds tothe value stored in the NCIM trackingArea table.


Table 137. eUtranCell table (continued)


operationalState Enumeration Operational state of the LTE cell. Takes one of thefollowing values:

v Enabled

v Disabled

v Other

v Unknown

administrativeState Enumeration Administrative state of the LTE sector. Takes one of thefollowing values:

v Unlocked

v Locked

v Shutting Down

v Other

v Unknown

eUtranSectorThe eUtranSector table models a geographic area of radio coverage that isimplemented and supported by physical radio equipment. An eUTRAN sectorimplements one or more eUTRAN cells.

The following table describes the eUtranSector table.

Table 138. eUtranSector table


entityID Integer FOREIGN KEY

NOT NULL

The identifier of an eUtranSector location entityfrom the entityData table.

sectorId 64-characterstring

NOT NULL Sector identifier.

sectorName 64-characterstring

NOT NULL Sector name.

sectorNumber Integer Sector number.


Distinguished name by which the sector is knownto its element management system (EMS).

frequencyBand Integer Frequency band supported by the sector. All cellsserviced by the sector must have carrier frequenciesfalling within this band.

maximumOutputPower Float Available sector power in Watts.

operationalState Enumeration Operational state of the sector. This field takes oneof the following values:

v Enabled

v Disabled

v Other

v Unknown


Table 138. eUtranSector table (continued)


administrativeState Enumeration Administrative state of the sector. This field takesone of the following values:

v Unlocked

v Locked

v Shutting Down

v Other

v Unknown

frameRelayEndPointThe frameRelayEndPoint table represents a logical Frame Relay end point andincludes relevant data. This endpoint is implemented by a physical interface, asmodeled in the protocolEndPoint table.

The following table describes the frameRelayEndPoint table.

Table 139. frameRelayEndPoint table



Not null

The identifier of a FrameRelay endpoint entity fromthe entityData table.

DLCI 32-bit integer The data link connectionidentifier for this FrameRelay endpoint.

Related reference:“protocolEndPoint” on page 147The protocolEndPoint table allows a higher-level connection to be defined in termsof lower-level connections. It associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. TheprotocolEndPoint table belongs to the category connectivity.“bgpEndPoint” on page 162The bgpEndPoint table represents a logical BGP end point and includes relevantBGP data. This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table

genericCollectionThe genericCollection table stores information on generic collections of entities.

The following table describes the genericCollection table.

Table 140. genericCollection table


entityId Integer not null The identifier of a genericcollection from theentityData table.


genericRangeThe genericRange table holds information about which Customer VLANS areswitched through each Virtual Switch Instance (VSI).

The following table describes the genericRange table.

Table 141. genericRange table


entityId Integer Foreign key

Primary key

Not null

The entity ID of theinterface that is associatedwith the Customer VLANrange data.

minimumvalue Integer Not null The minimum value of therange. Customer VLANswithin the range areswitched through the VSI;Customer VLANs outsidethe range are discarded.

maximumvalue Integer Not null The maximum value of therange.

rangeType Enumerated Not null Can only take the valueCVlanRange.

geographicLocationThe geographicLocation table stores geographic location information for networkentities. It does this by creating collections of entities at a specific location.

The following table describes the geographicLocation table.

Table 142. geographicLocation table


entityId Integer NOT NULL The identifier of ageographical location entityfrom the entityData table.

locationId 64-characterstring

NOT NULL The location identifier bywhich the location is knowto the end-user.

locationDescription 255-characterstring

Free-format textualdescription of location

timezoneOffset 9-character string Offset of local time fromUTC in formatUTC-HH:MM orUTC+HH:MM; forexample, UTC+10:30,UTC-6:00


Table 142. geographicLocation table (continued)


longitude 64-characterstring

Measurement of longitudefor this entity. This is theangular distance (north andsouth) from the equator onthe earth's surface; forexample, 78.838753. Thevalue of this attribute isdetermined based on WorldGeodetic System WGS84standard.

latitude 64-characterstring

Measurement of latitiudefor this entity. This is theangular distance (east andwest) from the primemeridian on the earth'ssurface; for example,35.832636. The value of thisattribute is determinedbased on World GeodeticSystem WGS84 standard.

altitude Integer Vertical height above WorldGeodetic System WGS84datum surface (EGM96) atthe particular geographicallocation

altitudeUnits 11-characterstring

Units to use for thealtitude.

v 0 – Meters

v 1 – Kilometers

v 2 – Centimeters

v 3 - Feet

v 4 – Yards

v 5 - Miles

v 6 - Inches

geographicRegionThe geographicRegion table stores geographic region information for radio accessnetwork entities. The geographicRegion table collects geographic locations from thegeographicLocation table or other geographic regions from the current table tobuild a geographical hierarchy.

The following table describes the geographicRegion table.

Table 143. geographicRegion table


entityId Integer NOT NULL The identifier of ageographical region fromthe entityData table.

hierachyName 64-characterstring

The name of hierarchywhich this region is partof.


Table 143. geographicRegion table (continued)


levelName 64-characterstring

The name of the hierarchylevel which this regionrepresents.

hierarchyLevel Integer Represents the level of thisregion within thegeographical hierarchy,where the value 1 is thefirst or lowest level.

globalVlanThe globalVlan table models global VLAN logical collections. A global VLAN is acollection of VLAN entities across multiple chassis devices that combine to form avirtual network.

The following table describes the globalVlan table.

Table 144. globalVlan table



Not null

The identifier of a globalVLAN entity from theentityData table.

subnet 16-characterstring

Not null The subnet address of theVLAN.


Not null The netmask of the subnetfor this VLAN.

vlanClass Enumerated The class of the VLAN.Possible values are: cvlan(Customer VLAN usingQinQ), svlan (ServiceVLAN using QinQ), orlocal (VLAN not usingQinQ).

vlanDescr 255-characterstring

A description of thisVLAN.

hsrpGroupThe hsrpGroup table represents a Cisco Hot Standby Routing Protocol (HRSP)group logical collection.

The HRSP implements a virtual router with its own IP and MAC addresses. Thisvirtual router forms an HSRP group that consists of a number of real interfaces,only one of which is active at any given time. The active interface forwards IPtraffic that is sent to the virtual router and the other interfaces in the group standby ready to become active if the active interface fails.

The following table describes the hsrpGroup table.


Table 145. hsrpGroup table



Not null

The identifier of a HSRPgroup entity from theentityData table.

virtualIP 32-bit integer Foreign key

Not null

The virtual IP address usedby this HSRP group.

hssFunctionThe hssFunction table models the Home Subscriber Server (HSS). The HSSmanages subscriber identities, service profiles, authentication, authorization, andquality of service (QoS), and acts as the master repository for subscriber profiles,device profiles and state information.

The following table describes the hssFunction table.

Table 146. hssFunction table



NOT NULL

The identifier of ahssFunction entity from theentityData table.

hssFunctionName varchar(64) NOT NULL Name of the hssFunction(Home Subscriber Server)instance configured on thephysical node thatimplements the hssFunction

MCC varchar(3) An HSS can supportmultiple PLMNs. The MCCattribute specifies theMobile Country Code(MCC) of the primaryPLMN supported by theHSS. Primary PLMNusually means the solePLMN or the PLMN of theoperator responsible for theoperation and maintenanceof the HSS. The MCCconsists of three digits.

MNC varchar(3) An HSS can supportmultiple PLMNs. The MNCattribute specifies theMobile Network Code(MNC) of the primaryPLMN supported by theHSS. Primary PLMNusually means the solePLMN or the PLMN of theoperator responsible for theoperation and maintenanceof the HSS. The length ofthe MNC (two or threedigits) depends upon thevalue of the MCC.


Table 146. hssFunction table (continued)


supportedPLMNs Integer This is a count of thenumber of PLMNs (PublicLand Mobile Networks)supported by the HSS.

emsDistinguishedName varchar(255) The distinguished name bywhich the HSS is known toits element managementsystem (EMS)

emsIpAddress varchar(39) The IP address of theelement managementsystem

vendorName varchar(64) The vendor/manufacturerof the HSS

vendorModuleType varchar(64) Vendor specific HSS Type

softwareVersion varchar(64) Vendor specific HSSsofware version

operationalState Enumeration The operational state of thehssFunction. Takes one ofthe following values:

v Enabled

v Disabled

v Other

v Unknown

administrativeState Enumeration The administrative state ofthe hssFunction. Takes oneof the following values:

v Unlocked

v Locked

v Shutting Down

v Other

v Unknown

igmpEndPointThe igmpEndPoint table holds information on the Internet Group MembershipProtocol (IGMP) End Points.

Each End Point holds various attributes describing the interface that implements it.There is a dependency between the end point and service associated with it(modeled via the existing dependency table). The End Point is associated with theinterface which implements it using the existing protocolEndPoint table.

The following table describes the igmpEndPoint table.


Table 147. igmpEndPoint table


entityId 32-bit integer v Primary Key

v Foreign Key(entityDatatable)

v Not Null

The identifier of the IGMPEnd Point.

groups 32-bit integer A count of the numberCache Table entries for thisend point

lastMembQueryIntvl 32-bit integer Holds the Last MemberQuery Interval

numJoins 32-bit integer Number of IGMP groupmembership joins thathave occurred

proxyIfIndex 32-bit integer Where IGMP proxying isused, this field holds theinterface index to whichIGMP Host MembershipReports are sent.

querier 25 characterstring

IP address of the IGMPQuerier

querierExpiryTime 64-bit integer Remaining time beforeexpiry of the Other QuerierPresent Timer expires. (0 iflocal system is the querier)

querierUpTime 64-bit integer Time ticks since theQuerier last changed

queryInterval 32-bit integer How often IGMP querymessages are sent on theinterface associated withthis End Point.

queryMaxResponseTime

32-bit integer Maximum response time intenths of a second

robustness 32-bit integer The Robustness Variableused to alter IGMPsensitivity to packet loss

status EnumeratedValue


v ‘other'

v ‘unknown'

v ‘enabled'

v ‘disabled'

The status of IGMP on theinterface associated withthe End Point.

version 32-bit integer Version of IGMP running

versionQuerierTimer 64-bit integer Remaining time before it isassumed that no IGMProuters are present on theinterface associated withthe End Point


Table 147. igmpEndPoint table (continued)


wrongVersionQueries 32-bit integer A count of number ofqueries received withunexpected IGMP versions.A non-zero value indicatesan IGMP configurationissue.


igmpGroupThe igmpGroup table holds multicast group collections for which there areassociated Internet Group Membership Protocol (IGMP) end points in theigmpEndPoint table. Entries in the igmpGroup table collect associatedigmpEndPoints using the existing collects table.

The following table describes the igmpGroup table.

Table 148. igmpGroup table




v Not Null

The identifier of the IGMPgroup

groupAddress 25-characterstring

IP address of the multicastgroup

groupMask 25-characterstring

Mask of the multicastgroup

groupName 60-characterstring

Name associated with thegroup

igmpServiceThe igmpService table represents an Internet Group Management Protocol (IGMP)service. Each row in the table corresponds to a single hosted IGMP service. Theservice is associated with the device on which it runs using the hostedServicetable.

The following table describes the igmpService table.


Table 149. igmpService table




v Not Null

The identifier of the IGMPService

ipConnectionThe ipConnection table stores information on IP connections.

The following table describes the ipConnection table.

Table 150. ipConnection table


entityId Integer not null The identifier of an IPconnection from theentityData table.

ipEndPointThe ipEndPoint table represents an IP end point and includes relevant data. Theendpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.

The following table describes the ipEndPoint table:

Table 151. ipEndPoint table


entityId 32–bit integerForeign key

Not null

The identifier of an IP end point entity fromthe entityData table.

DNSName 255–character string DNS name for the IP address associatedwith this IP end point.

address 39–character string Not null IP address associated with this IP end point.

ipNumber 64–bit integer,unsigned

Not nullFor IPv4: IP address represented as a 32–bitinteger.

For IPv6: The first half of the IP address isrepresented as a 128–bit integer. The value isshown as a signed 64-bit integer. Forexample, for the IPv6 addressfe80:0000:0000:0000:21a:30ff:fe2b:fb80, thehexadecimal ipNumber is FE80 0000 00000000.


Table 151. ipEndPoint table (continued)


netNumber 64–bit integer Not nullFor IPv4: Not applicable

For IPv6: Second half of IP addressrepresented as a 128–bit integer. The value isshown as a signed 64-bit integer. Forexample, for the IPv6 addressfe80:0000:0000:0000:21a:30ff:fe2b:fb80, thehexadecimal netNumber is 021A 30FF FE2BFB80. (The decimal number is18338657682652659712 as an unsignedinteger and 108086391056891904 as a signedinteger.)

subnet 39–character string Subnet to which the IP address belongs.

netmask 39–character string Netmask for the subnet.

netmaskbits 32–bit integer Netmask bits for the subnet

addressSpace 255–character string Relevant NAT address space if networkaddress translation is being used.

protocolString value An integer representation of the IP protocol

used by the presently-defined zone:

v 1: IPv4

v 2: IPv4 that has been through networkaddress translation (NAT)

v 3: IPv6

cdmAddressType 16-bit integer Not null

Default value: 0

The IBM Common Data Model defines anattribute named AddressType in theIpV4Address and IPv6Address views andthe ipEndPoint class is the equivalent objectin NCIM. Therefore to make the attributes inthe classes consistent, a new attribute namedcdmAddressType has been added to theipEndPoint table.

Related concepts:“Technology-specific data” on page 15NCIM models a range of different network technologies, including IP, VLANs, andMPLS VLANs.Related reference:“protocolEndPoint” on page 147The protocolEndPoint table allows a higher-level connection to be defined in termsof lower-level connections. It associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. TheprotocolEndPoint table belongs to the category connectivity.“bgpEndPoint” on page 162The bgpEndPoint table represents a logical BGP end point and includes relevantBGP data. This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table


ipMRouteDownstreamThe ipMRouteDownstream table holds the downstream route statistics per deviceor MDT. Each entity in this table will have a dependency relationship with theassociated MDT via the existing dependency table.

The following table describes the ipMRouteDownstream table.

Table 152. ipMRouteDownstream table


closestMemberHops 32-bit integer The number of hops that itwill take to reach theclosest member of thismulticast group.



v Not Null

The identifier of the IGMPEnd Point

expiryTime 32-bit integer Time ticks left before theroute entry expires

hopState Enumeratedvalue


v unknown

v other

v pruned

v forwarding

Indicates whether thedownstream interface isbeing used to forwardpackets.

nextHop 15-characterstring

IP Address of the nextdownstream hop. Thisaddress may be themulticast group address.

outInterface 32-bit integer NULL if ifIndex was 0

packetCount 32-bit integer The number of packetsfrom sources destined forthe group.

protocol Enumeratedvalue


v other

v local

v netmgmt

v DVMRP

v MOSPF

v

PIMSparseDense

v CBT

v

PIMSparseMode

v

PIMDenseMode

v IGMPOnly

v BGMP

v MSDP

The protocol used to learnthe downstream next hoproute


Table 152. ipMRouteDownstream table (continued)


startTime Timestamp Approximate time that theroute entry was learnt;calculated using uptimeand the system time at thetime the device wasinterrogated.

uptime 32-bit integer Time ticks since this routeentry was learnt

ipMRouteEndPointThe ipMRouteEndPoint table holds information on the IP Multicast RoutingProtocol End Points.

Each End Point holds various attributes describing the interface that implements it.There is a dependency between the end point and service associated with it(modelled using the existing dependency table). The End Point is associated withthe interface which implements it through the existing protocolEndPoint table.

The following table describes the ipMRouteEndPoint table.

Table 153. ipMRouteEndPoint table




v Not Null

The identifier of the IPMulticast Routing ProtocolEnd Point

flowDirection Enumeratedvalue


v upstream

v downstream

Indicates the direction offlow represented by thisend point

isLastHop 32-bit integer 0 or 1 Indicates whether this endpoint represents a lastknown hop


Table 153. ipMRouteEndPoint table (continued)




v other

v local

v netmgmt

v DVMRP

v MOSPF

v

PIMSparseDense

v CBT

v

PIMSparseMode

v

PIMDenseMode

v IGMPOnly

v BGMP

v MSDP

Routing protocol runningon the interface associatedwith this End Point

rateLimit 32-bit integer Rate limit in kbps ofmulticast traffic on theinterface associated withthis End Point

ttl 32-bit integer Time To Live counter


ipMRouteGroupThe ipMRouteGroup table represents Multicast Groups, as contained by theMulticast Distribution Tree (MDT).

The following table describes the ipMRouteGroup table.

Table 154. ipMRouteGroup table




v Not Null

The identifier of the IPMulticast Routing Group

groupAddress 15-characterstring

Not Null The address of themulticast group

groupMask 15-characterstring

15-character string


ipMRouteMdtThe ipMRouteMdt table holds the Collection entities representing the MulticastDistribution Trees (MDTs) for each Multicast Source/Group. The name of the entity(present in the entityData table) takes the form (S,G). Each row in the tablerepresents a single MDT. The MDT collects the End Points involved using theexisting collects table. The MDT contains their related Groups/Source entities(through the existing contains table), and depend on the Multicast Route entities(through the dependency table).

The following table describes the ipMRouteMdt table.

Table 155. ipMRouteMdt table




v Not Null

The identifier of the IPMulticast Routing MDTentity

mdtType Enumeratedvalue


v unknown

v other

v SPT

v SDT

Holds the type of MDTrepresented

ipMRouteServiceThe ipMRouteService table represents an IP Multicast Routing service and includesany attributes relevant to the service. Each row in the table corresponds to a singlehosted IPMRouting service. The service is associated with the device on which itruns through the hostedService table.

The following table describes the ipMRouteService table.

Table 156. ipMRouteService table




v Not Null

The identifier of the IPMulticast Routing Service

routeCount 32-bit integer The number of routesknown to this Service


ipMRouteSourceThe ipMRouteSource table represents Multicast Sources, as contained by theMulticast Distribution Tree (MDT).

The following table describes the ipMRouteSource table.

Table 157. ipMRouteSource table




v Not Null

The identifier of the IPMulticast Routing Source

source 15-characterstring

Not Null The address of the source

sourceMask 15-characterstring

The mask of the source

ipMRouteUpstreamThe ipMRouteUpstream table holds the upstream (RPF) route statistics for eachdevice or MDT. Each entity in this table has a dependency relationship with theassociated MDT through the existing dependency table.

The following table describes the ipMRouteUpstream table.

Table 158. ipMRouteUpstream table




v Not Null

The identifier of the RPFupstream route entity

inInterface 32-bit integer NULL if ifIndex was 0

upstreamNbr 15-characterstring

IP address of the RPFneighbour (if known)

uptime 32-bit integer Time ticks since this routeentry was learnt

expiryTime 32-bit integer Time ticks left before theroute entry expires

startTime Timestamp Approximate time that theroute entry was learnt;calculated using uptimeand the system time at thetime the device wasinterrogated.

packetCount 32-bit integer The number of packetsfrom sources destined forthe group.


Table 158. ipMRouteUpstream table (continued)


differentInIfPackets 32-bit integer The number of packetsdropped because they werereceived on the wronginterface

octets 32-bit integer The number of octetsforwarded



v other

v local

v netmgmt

v DVMRP

v MOSPF

v

PIMSparseDense

v CBT

v

PIMSparseMode

v

PIMDenseMode

v IGMPOnly

v BGMP

v MSDP

The protocol used to learnthis route entry

rtProto Enumeratedvalue

Takes one of thefollowing values;

v other

v local

v netmgmt

v ICMP

v EGP

v GGP

v hello

v RIP

v ISIS

v ESIS

v ciscoIGRP

v bbnSpfIGP

v OSPF

v BGP

v IDRP

v ciscoEIGRP

v DVMRP

The protocol used to learnthe upstream interface forthis route entry

rtAddress 15-characterstring

Address used to determinethe upstream interface

rtMask 15-characterstring

Mask used to determinethe upstream interface


Table 158. ipMRouteUpstream table (continued)


rtType EnumeratedValue


v unknown

v other

v unicast

v multicast

The type of route

ipPathThe ipPath table stores information on IP paths.

The following table describes the ipPath table.

Table 159. ipPath table


entityId Integer Not null The identifier of an IPpathfrom the entityDatatable.

fromIP 39-characterstring

Starting IP address for thispath.

toIP 39-characterstring

End IP address for thispath.

viaIP 39-characterstring

IP address that this pathmust traverse.

hops 32-bit integer Not null Number of hops in thepath.

ecmp Indicates whetherequal-cost multi-pathrouting applies to thispath.

asymmetric Indicates whether this is anasymmetric path.

protocols 100-characterstring

Indicates the protocolsused in this path.

cost 32-bit integer

itnmServiceThe itnmService table represents Service-Affected Events (SAE); the table is usedby the SAE plug-ins in the Event Gateway, ncp_g_event. This table is used onlyindirectly by the SAE plug-ins, since the SAE plug-ins use the NCIM cache tables,which are based on NCIM tables.

The following table describes the itnmService table.


Table 160. itnmService table


entityID 32–bit integer Not null The identifier of theSAE entity from theentityData table.

serviceName 255–character string Not null The name of theSAE.

serviceType 64–character string Not null The type of SAE

lagEndPointFix Pack 1

The lagEndPoint table holds information about end points within Link AggregationGroups (LAGs).

The following table describes the lagEndPoint table.

Table 161. lagEndPoint table


entityId 32-bit integer Not null

Primary Key

Foreign Key

Automatically incrementedID that provides a uniquevalue for each end pointacross all domains.

lagId 32-bit integer Not null The ID of the LAG.

priority 32-bit integer The priority of the endpoint.

lagMode 8-character string The mode that the LAG isoperating in. Takes one ofthe following values:

v lacp

v static

v unknown

v other

v disabled

actorAdminState 255-characterstring

The administrative value ofActor_State as transmittedby the actor in the LinkAggregation Control PDUs.

actorOperState 255-characterstring

The operational value ofActor_State as transmittedby the actor in the LinkAggregation Control PDUs.

actorSystemId 255-characterstring

The MAC address valueused as a unique identifierfor the server that containsthis LAG.

actorAdminKey Integer Administrative value of thekey for the LAG.

actorOperKey Integer Operational value of thekey for the LAG.


Table 161. lagEndPoint table (continued)


partnerAdminState 255-characterstring

The administrative value ofActor_State for the protocolpartner.

partnerOperState 255-characterstring

The value of Actor_State inthe most recently receivedLink Aggregation ControlPDU transmitted by theprotocol partner.

partnerSystemId 255-characterstring

The MAC address valueused as a unique identifierfor the current protocolpartner of this LAG.

partnerAdminKey Integer Administrative value of thekey for the protocolpartner.

partnerOperKey Integer Operational value of thekey for the protocolpartner.

lingerTimeThe lingerTime table stores the linger time for a device. The linger time is thenumber of discoveries that a device can fail to be found in before it is removedfrom the topology.

The linger time is set for a device when it is instantiated, from the default value inthe model.config table. Each time that a device in the topology is not discovered,the linger time is decreased by 1. When the linger time is zero, if the device is notdiscovered, it is removed from the topology.

The lingerTime table is described in the following table:

Table 162. lingerTime table



Not null

The identifier of a device.

lingerTime Integer Not null The current linger time ofthe device.

localVlanThe localVlan table specifies which global VLAN the local VLAN belongs to. Alocal VLAN represents all the interfaces on a single chassis device that belong to aglobal VLAN.

In addition, the contains table specifies the interfaces contained by the localVLAN.


Table 163. localVlan Ttable



Not null

The identifier of a localVLAN entity from theentityData table.


vlanId 32-bit integer Not null The identifier of aconnection from theconnects table.

vlanDescr 255-characterstring

The description of aconnection from theconnects table.

vlanName 64-characterstring

The name of a connectionfrom the connects table.

vlanType 32-characterstring

The type of a connectionfrom the connects table.

vlanState 32-characterstring

The state of a connectionfrom the connects table.

Related reference:“contains” on page 130The contains table stores data on physical and logical containment. This tablebelongs to the category containment.

lteInterfaceThe lteInterface table models the different types of interfaces between LTEdevices.

LTE interfaces modelled in NCIM

The following table lists the LTE interface types that are modelled in NCIM, andshows which interface types are used to connect different LTE elements. Theinterface types are described below the table.

Table 164. LTE interfaces modelled in NCIM

LTE element EIR eNodeB HSS MME PCRF PGW SGW SGSN

Equipment Identity Register (EIR)

“eirFunction” on page 176

S13

Evolved NodeB

“enbFunction” on page 179

X2 S1-MME S1-U

Home Subscriber Server (HSS)

“hssFunction” on page 187

S6a


Table 164. LTE interfaces modelled in NCIM (continued)

LTE element EIR eNodeB HSS MME PCRF PGW SGW SGSN

Mobility Management Entity(MME)

“mmeFunction” on page 206

S13 S1-MME S6a S10 S11 S3

Policy and Charging RulesFunction (PCRF)

“pcrfFunction” on page 221

Gx

Packet Data Network Gateway(PGW)

“pgwFunction” on page 223

Gx S5

S8

Serving Gateway (SGW)

“sgwFunction” on page 258

S1-U S11 S5

S8

S4

Serving GPRS Support Node(SGSN)

“ranSGSN” on page 255

S4

Gx Interface between the PGW and the Policy and Charging Rules Function(PCRF). In particular, this is the interface between the Policy ControlEnforcement Function (PCEF) or the PGW and the PCRF.

OAM Operational and maintenance interface, used to manage the device.

SGi Interface between the PGW and any packet data network.

S1 Interface between the eNodeB and the core network.

S1-MMEControl plane interface between an eNodeB and an MME.

S1-U User plane interface between an eNodeB and one or more SGWs.

S3 Control plane interface between an MME and a Serving GPRS SupportNode (SGSN). The interface is used to manage mobility inter-3GPP RadioAccess Technology (RAT) mobility between, for example, LTE and UMTSor GPRS.

S4 Control and user plane interface between an SGW and a Serving GPRSSupport Node (SGSN).

S5 Modelled in NCIM as a user plane interface between an SGW and a PGWwithin the same Public Land Mobile Network (PLMN).

Note: The S5 interface can carry control and user plane data but in NCIMit is modelled as user plane only.

S6a Control plane interface between MME and Home Subscriber Server (HSS).

S8 Equivalent to the S5 interface except that it connects an SGW in the VisitedPLMN (VPLMN) to a PGW in the roaming subscriber's Home PLMN(HPLMN).

Note: The S5 interface can carry control and user plane data but in NCIMit is modelled as user plane only.

S10 Inter-MME control plane interface.


S11 Control plane interface between an MME and an SGW.

S13 Control plane interface between MME and the Equipment Identity Register(EIR).

X2 Modelled in NCIM as a control plane interface between neighbouringeNodeBs. Used for signalling between neighbouring eNodeBs.

Note: The X2 interface can carry control and user plane data but in NCIMit is modelled as control plane only.

The following table describes the lteInterface table.

Table 165. lteInterface table



NOT NULL

interfaceType Enumeration Type of LTE interface. Takes one of thefollowing values:

v Gx

v OAM

v SGi

v S1

v S1-MME

v S1-U

v S3

v S4

v S5

v S6a

v S8

v S10

v S11

v S13

v X2

ltePoolThe ltePool table is a generic modelling mechanism for groups of pooled LTEentities, and is used to model MME pools, PGW pools, and SGW pools. As anexample, in order to model an MME pool, the relationship between the ltePoolentity and associated mmeFunction entities is modelled using the collects table.

The following table describes the ltePool table.

Table 166. ltePool table



NOT NULL

The identifier of an ltePool entity from theentityData table.

lteGroupId 64-character string The group identifier of the LTE pool.


Table 166. ltePool table (continued)


ltePoolName 64-character string NOT NULL The name of the MME Pool.

ltePoolType Enumeration Type of LTE pool. Takes one of the followingvalues:

v MME

v SGW

v PGW

ltePoolArea 64-character string The name of the Pool Area that is covered bythe pool. There is a one to one mappingbetween a Pool and a Pool Area.

managedStatusThe managedStatus table stores the managed status information for each networkentity in the topology.

The following table describes the managedStatus table.

Table 167. managedStatus table


entityId 32–bit integerForeign keyNot null

Identifier of an entity from the entityData table.

status 8–bit integerThe managed status of an entity can be one of the followingvalues:

0 Managed state. The entity is managed.

1 Unmanaged state. The entity is unmanaged. A devicecan be set to unmanaged using the Topoviz or theStructure Browser GUIs. This value is set for newdevices in the topology when they are set to beexcluded from polling initially in theTagManagedEntities.stch stitcher.

2 Unmanaged by ncp_disco. This setting cannot bemodified from the GUI. This value is set by thePopulateDNCIM_ManagedStatus.stch stitcher.

3 Unmanaged because the IP address is out of thediscovery scope. The device has been discoveredthrough another IP address that is within thediscovery scope. A managed status of 3 is usuallygiven to interfaces, rather than chassis. This value isset by the TagManagedEntities.stch stitcher.

Note: Unmanaged entities do not suppress other events inRCA. The ncp_poller process does not poll unmanaged entities.Events on unmanaged entities have the fieldNmosManagedStatus set in the alerts.status field in theObjectServer.

username 240–characterstring

Name of the user who last set the status of the entity.

changeTime Timestamp Date and time when the status of the entity was changed.


Table 167. managedStatus table (continued)


maintenanceStartTime

Timestamp Start time for device to be in unmanaged state.

maintenanceEndTime

Timestamp End time for device to be in unmanaged state.

mmeFunctionThe mmeFunction table models the role of the Mobility Management Entity (MME)within a network hardware node. Multiple mmeFunction instances can beimplemented within a single network hardware node. The MME is the mainsignalling control element in the core network and is the key control node forenabling user equipment access to the core network.

The following table describes the mmeFunction table.

Table 168. mmeFunction table



NOT NULL

The identifier of an mmeFunction location entityfrom the entityData table.

MMEC 64-characterstring

MME code. Uniquely identifies an MME withinan MME Group. This attribute consists of 8 bits.

MMEGI 64-characterstring

MME group identifier. Uniquely identifies anMME Group within a public land mobilenetwork (PLMN). This attribute consists of 16bits.

mmeName 64-characterstring

NOT NULL Uniquely identifies an MME when more thanone MME configured on same device.

MCC 3-character string An MME can support multiple PLMNs. TheMCC attribute specifies the Mobile CountryCode (MCC) of the primary PLMN supported bythe MME. Primary PLMN usually means the solePLMN or the PLMN of the operator responsiblefor the operation and maintenance of the MME.The MCC consists of three digits.

MNC 3-character string An MME can support multiple PLMNs. TheMNC attribute specifies the Mobile NetworkCode (MNC) of the primary PLMN supported bythe MME. Primary PLMN usually means the solePLMN or the PLMN of the operator responsiblefor the operation and maintenance of the MME.The length of the MNC (two or three digits)depends upon the value of the MCC.

supportedPLMNs Integer Count of the number of PLMNs supported bythe MME.


Distinguished name by which the MME isknown to its element management system (EMS).

emsIpAddress 39-characterstring

IP address of the element management system.


Vendor or manufacturer of the MME.


Table 168. mmeFunction table (continued)


vendorModuleType 64-characterstring

Vendor-specific MME type.

softwareVersion 64-characterstring

Vendor-specific MME sofware version.

operationalState Enumeration Operational state of the mmeFunction. Takes oneof the following values:

v Enabled

v Disabled

v Other

v Unknown

administrativeState Enumeration Administrative state of the mmeFunction. Takesone of the following values:

v Unlocked

v Locked

v Shutting Down

v Other

v Unknown

mplsTEServiceThe mplsTEService table represents an MPLS TE service and includes relevantprotocol data. This MPLS TE service runs on a device, as modeled in thehostedService table. Each row in this table corresponds to a single hosted MPLS TEservice. MPLS TE configured devices will host only one MPLS TE service, which inturn can support multiple MPLS TE tunnels.

The following table describes the mplsTEService table.

Table 169. mplsTEService table


entityId 32-bit integer Foreign Key

Not Null

The identifier of an MPLSTE service from theentityData table.

numTunnelsConfigured 32-bit integer The number of configuredtunnels represented by thisservice.

numTunnelsActive 32-bit integer The number of activetunnels represented by thisservice.

teDistributionProtos 30-characterstring

Names of the TEdistribution protocols inuse by the service.

maxNumTunnelHops 32-bit integer Maximum number of hopsa TE tunnel is allowed tomake.


mplsTETunnelThe mplsTETunnel table represents the MPLS TE tunnels discovered in thenetwork and includes a number of tunnel attributes. Each row in this tablecorresponds to a TE tunnel discovered on a device.

The following table describes the mplsTETunnel table.

Table 170. mplsTETunnel table


adminStatus Enumeratedvalue


v up

v down

v testing

Administrative status

creationTime Timestamp Time when tunnel wascreated


The description of thetunnel

egressLSRId 15-characterstring

Egress LSR ID of thetunnel


Not Null

The identifier of an MPLSTE service from theentityData table

excludeAllAffinity 32-bit integer Exclude-All constraint

holdPriority 32-bit integer Hold priority

includeAllAffinity 32-bit integer Include-All constraint

includeAnyAffinity 32-bit integer Include-Any constraint

ingressLSRId 15-characterstring

Ingress LSR ID of thetunnel

instanceId 25-characterstring

Unique tunnel identifier

instancePriority 32-bit integer Priority of this tunnelinstance

locallyProtected 8-bit integer Denotes whether tunnel islocally protected or not


The name of the tunnel

numPathChanges 32-bit integer Number of times thetunnel path has changed

operStatus Enumeratedvalue


v up

v down

v testing

v unknown

v dormant

v notPresent

v lowerLayerDown

Operational status


Table 170. mplsTETunnel table (continued)


owner 20-characterstring

Owner of the tunnel

resourcePointer 32-bit integer Index into the resourcetable for this tunnel.

role Enumeratedvalue


v head

v transit

v tail

Role of this tunnel

sessionAttributes 90-characterstring

Tunnel session attributes intext form

setupPriority 32-bit integer Setup priority

signallingProtocol Enumeratedvalue


v none

v rsvp

v crldp

v other

The protocol used to signalthe tunnel

transitions 32-bit integer Number of times the statehas changed

tunnelInstance 25-characterstring

Identifies a specificinstance of the tunnelidentified by tunnelIndex

tunnelIndex 25-characterstring

Tunnel index

uptime 32-bit integer Amount of time tunnel hasbeen up

xcPointer 128-characterstring

Index into the LSPcross-connect table for thistunnel

mplsTETunnelEndPointThe mplsTETunnelEndPoint table represents an MPLS TE protocol end point and isimplemented on the interface associated with the configured tunnel. The end pointreferences the associated TE tunnels unique instance id.

The following table describes the mplsTETunnelEndPoint table.

Table 171. mplsTETunnelEndPoint table



Not Null

The identifier of an MPLSTE service from theentityData table

instanceId 25-characterstring

Unique tunnel identifier, asseen in the mplsTETunneltable

Related reference:


“protocolEndPoint” on page 147The protocolEndPoint table allows a higher-level connection to be defined in termsof lower-level connections. It associates a device entity, usually an interface, withprotocol-specific information associated with that device entity. TheprotocolEndPoint table belongs to the category connectivity.

mplsTETunnelResourceThe mplsTETunnelResource table represents the MPLS TE Tunnel resourceconfigurations that tunnels might be associated with.

The following table describes the mplsTETunnelResource table.

Table 172. mplsTETunnelResource table



Not Null


resourceIndex 32-bit integer Resource index. This is thevalue associated with themplsTETunnel tablesresourcePointer.

maxRate 32-bit integer Maximum data rate in bitsper second, where 0 meansbest effort.

meanRate 32-bit integer Average data rate in bitsper second. 0 means besteffort

maxBurstSize 32-bit integer Maximum burst size inbytes

meanBurstSize 32-bit integer Average burst size in bytes

mplsLSPThe mplsLSP table represents LSPs (Label Switched Paths) that might be traversedby MPLS TE tunnels.

The following table describes the mplsLSP table.

Table 173. mplsLSP table



Not Null


lspID 40-characterstring

The ID of the LSP.


multiplexerThe multiplexer table describes multiplexer entities.

The following table describes the multiplexer table.

Table 174. multiplexer table


entityId Integer not null The identifier of amultiplexer entity from theentityData table.

netcoolAsmsRunningThe netcoolAsmsRunning table lists instances of ASM running on main nodedevices.

The following table describes the netcoolAsmsRunning table.

Table 175. netcoolAsmsRunning table



Not null

The identifier of a chassisdevice from the entityDatatable.

ASMName 64-characterstring

Not null The name of an ASMrunning on this chassisdevice.

networkInterfaceThe networkInterface table represents interfaces on a chassis device.

The following table describes the networkInterface table.

Table 176. networkInterface


entityId 32–bit integer Foreign keyNot null

The identifier of a physicalinterface from theentityData table.

ifTypeString 45-characterstring

The textual string for theinterface type.

aid 255-characterstring

TL1 access identifier.

alternativeName 255-characterstring

Alternative name for thedevice.

bandwidth NUMBER(19) Bandwidth of the interfacemeasured in kilobits persecond.


Table 176. networkInterface (continued)


configuredDuplex Enumeratedvalue

Current® administrativeduplex setting for thisinterface. Takes one of thefollowing values:

v HalfDuplex

v FullDuplex

v Auto

v Unknown

v Other

connectorPresent Enumeratedvalue

Indicates whether theinterface has a connector.Takes one of the followingvalues:

v True

v False

dataLinkLayerDiscovery

Integer An indication as towhether this interface isrunning a data-link-layerdiscovery protocol.

encapsulation Tiny integer Current encapsulation usedon the interface.

ifType 32–bit integer The interface type.

keepalive 32–bit integer Shows the durationbetween keepalivemessages.

mediaType Tiny integer Indicates the physicalmedia being used by thisinterface.

mtu 32–bit integer The maximumtransmission unit for thisinterface.


Name of the interface.

operationalDuplex Enumeratedvalue

Actual duplex of theinterface. Takes one of thefollowing values:

v HalfDuplex

v FullDuplex

v Auto

v Unknown

v Other

operationalStatus 12-characterstring

Takes one of the followingvalues:

v unknown

v other

v started

v stopped




physicalAddress 255–characterstring

The physical address of theinterface.

promiscuous 5–character string Indicates whether thisinterface only acceptspackets or framesaddressed to this station.Takes one of the followingvalues:

v True

v False

sendLinkStateAlarm 5–character string Indicates whether theinterface or port isconfigured to send linkstate alarms to amanagement station. Takesone of the followingvalues:

v True

v False

ifIndex 32–bit integer The index of the interface.

speed 64–bit integer Normalized actualavailable speed of theinterface measured in bitsper second.

switchPortMode Tiny integer Indicates whether thisphysical interface is aVLAN trunk port.

ifName 128-characterstring

The name assigned to theinterface.

ifDescr 255-characterstring

A description of theinterface.

ifAlias 255-characterstring

The alias for the interface.

ifSpeed 64–bit integer An estimate of the currentbandwidth of the interfacein bits per second.

ifHighSpeed 32–bit integer An estimate of the currentbandwidth of the interfacein units of 1,000,000 bitsper second.

ifAdminStatus Enumeratedvalue

The required state of theinterface. Takes one of thefollowing values:

v Up

v Down

v Testing




ifOperStatus Enumeratedvalue

The current operationalstate of the interface. Takesone of the followingvalues:

v Up

v Down

v Testing

v unknown

v dormant

v notPresent

v lowerLayerDown

accessIPAddress 39-characterstring

The IP address throughwhich this entity wasdiscovered and will bemonitored.Note: For non-IP entities,such as layer 1 opticaldevices, this field is null.

accessProtocol Enumerated type(string 7 chars)

An integer representationof the network protocolused by thepresently-defined zone:

v 0: Unknown

v 1: IPv4

v 2: IPv4 that has beenthrough network addresstranslation (NAT)

v 3: IPv6

v 4: Element ManagementSystem (EMS) key for anon-IP device

portNumber 32–bit integer The port number for thisinterface on the chassisdevice. The method ofdetermining the portnumber is dependent onthe make and model of thedevice that is discovered.For this reason, use thisvalue with caution.

status 255-characterstring

Status of this entity.


networkServiceEntityEndPointThe networkServiceEntityEndPoint table describes network service entityendpoints.

The following table describes the networkServiceEntityEndPoint table.

Table 177. networkServiceEntityEndPoint table


entityId Integer not null The identifier of a network serviceentity from the entityData table.

NSEI Integer Network service entity identifier.An NSEI is used in themanagement of frame relay links.The networkServiceEntityEndPointobject helps model thatrelationship.

networkVpnThe networkVpn table represents a logical collection of IP addresses collectedwithin a VPN.

The following table describes the networkVpn table.

Table 178. networkVpn table



Not null

The identifier of a networkVPN from the entityDatatable.

VPNName 255-characterstring

Not null The name of the VPN.

VPNType 64-characterstring

Not null The type of VPN.

operatingSystemThe operatingSystem table represents the software responsible for interacting withhardware devices.

The following table describes the operatingSystem table.

Table 179. operatingSystem table


entityId Integer not null The identifier of anoperating system entityfrom the entityData table.

assetID 255-characterstring

Asset identifier for thisentity.

assetTag 255-characterstring

Asset tag for this entity.

bootTime 64-bit integer Time duration theoperating system has beenonline.


Table 179. operatingSystem table (continued)


buildLevel 255-characterstring

Build level of the operatingsystem without anyversion or releaseinformation.

ciCategory 255-characterstring

Configuration itemcategory for this entity.

ciRole Tiny integer Identifies the environment,or role, in which aconfiguration item (CI)resides. For example, if aCI is set aside for testpurposes, then this columncan be set to a value ofTest. If a role is neededthat is not defined in theenumeration for ciRole,then use the value Other.

configLastUpdate 255-characterstring

UTC date and time whenthe information was lastaltered in the sourceapplication.

currentTime 64-bit integer Current time of theinstance of the operatingsystem.

fqdn 255-characterstring

Fully-qualified host nameassigned to the operatingsystem. In cases where thedatacenter does notimplement the DomainName System (DNS), thefully-qualified host name isthe short name.

generalCIRole 255-characterstring

Environment, or role, inwhich a CI resides.

kernelArchitecture 255-characterstring

Raw details of thesupported systemarchitecture of the kernelcomponent of theoperating system.

kernelVersion 255-characterstring

Raw version of the kernelcomponent of theoperating system.

lastAuditState Tiny integer Last audit state for thisdevice. Possible values are:

v 0 Unknown

v 1 Other

v 2 Good

v 3 No Physical CI

v 4 No CMDB Record

v 5 Inaccurate CMDBRecord




lastAuditTime Timestamp Last audit time this entity.

lastLifecycleStateTime Timestamp Last lifecycle state time forthis entity.

osLevel Integer Operating system level.

lifecycleState Tiny integer Lifecycle state for thisdevice. Possible values are:

v 0 Unknown

v 1 Other

v 2 Ordered

v 3 Received

v 4 In Test

v 5 Tested

v 6 Installed

v 7 Enabled

v 8 Disabled

v 9 In Maintenance

v 10 Retired

v 11 Archived

v 12 Accepted

v 13 Draft

v 14 Build

v 15 Validate

v 16 ProductionReady

v 17 Production

v 18 Sunset

v 19 PostProduction

v 20 Inventory

v 21 Development

v 22 Offline

majorVersion Integer Major version of theproduct, and generallyspecified as the firstnumber in a version string(for example, inWebSphere® 6.1, the '6' isthe major version).

modifier Integer Version specification that isnormally tied to fixeswithin a software release,and is normally specifiedthird in a version string.The Modifier may notalways be specified, as inWebSphere 6.1.






osConfidence Integer Field used by IBM TivoliApplication DependencyDiscovery Manager.

osMode 255-characterstring

Current kernel bitarchitecture mode of theoperating system.

osName 255-characterstring

String representation of theoperating system name.

osVersion 255-characterstring

Raw text representation ofthe operating systemversion.

osId Integer Field used by IBM TivoliApplication DependencyDiscovery Manager.

osRelease Integer Raw text representation ofthe operating systemrelease.

systemGuid 255-characterstring

Globally Unique Identifier(GUID) for the operatingsystem.

versionString 255-characterstring

Complete versionspecification of the entity,expressed as a singlestring.

virtualMemorySize 64-bit integer Allocated size of memorythat does not includephysical memory size.


ospfAreaThe ospfArea table models an OSPF area.

The following table describes the ospfArea table.

Table 180. ospfArea table



Not null

The identifier of an OSPFarea entity from theentityData table.

areaId 15-characterstring

Not null Identifier for the OSPFarea.

isNSSA 8-bit integer Indicates whether this is anOSPF not-so-stubby area(NSSA).

isExtArea 8-bit integer Indicates whether this is anOSPF external area.

ospfEndPointThe ospfEndPoint table represents an OSPF end point and includes relevant data.This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.

The following table describes the ospfEndPoint table.

Table 181. ospfEndPoint table



Not null

The identifier of an OSPFendpoint entity from theentityData table.

areaID 15-characterstring

Not null

ospfIfAdminState 32-bit integer

ospfIfState Enumeratedvalue


1: down2: loopback3: waiting4: pointToPoint5: designated-Router6: backup-DesignatedRouter7: other-DesignatedRouter

The state of the OSPFinterface.


Table 181. ospfEndPoint table (continued)


ospfIfType Enumeratedvalue

Takes one of thefollowing values:1: broadcast2: nbma3: pointTo-Point5: pointTo-Multipoint

The OSPF interface type.

defaultCost 32-bit integer


ospfNetworkLSAThe ospfNetworkLSA table represents an OSPF Link-State Advertisement (LSA)and includes relevant data.

The following table describes the ospfNetworkLSA table.

Table 182. ospfNetworkLSA table



Not null

The identifier of an OSPFLSA entity from theentityData table.

linkStateId 15-characterstring

Not null Specifies link state ID.

networkMask 15-characterstring

Specifies network mask.

networkType 10-characterstring

Indicates the network type.

ospfRoutingDomainThe ospfRoutingDomain table represents an OSPF routing domain.

The following table describes the ospfRoutingDomain table.

Table 183. ospfRoutingDomain table



Not null


ospfDomain 32-bit integer Not null The domain of the OSPF.


ospfServiceThe ospfService table represents an OSPF service and includes relevant protocoldata. This OSPF service runs on a device, as modeled in the hostedService table.

The following table describes the ospfService table.

Table 184. ospfService table



Not null

The identifier of an OSPFservice entity from theentityData table.

routerId 15-characterstring

Not null The entity ID of the routeron which this OSPF serviceis running.

isAreaBdrRtr 8-bit integer Indicates whether thisrouter is an area borderrouter.

isAsBdrRtr 8-bit integer Indicates whether thisrouter is an AS borderrouter.

isDrRtr 8-bit integer Indicates whether thisrouter is acting as adesignated router.

isBdrRtr 8-bit integer Indicates whether thisrouter is acting as abackup designated router.

isDrOtherRtr 8-bit integer Indicates that this router isneither a designated routernor a backup designatedrouter.

Related reference:“hostedService” on page 143A hosted service is a service or application running on a specific main node device.The hostedService table maps a main node device, the hosting entity, to the serviceor applications that are running on that device, the hosted entities. ThehostedService table belongs to the category entities.

pcrfFunctionThe pcrfFunction table models the Policy and Charging Rules Function (PCRF).The PCRF manages the policy and charging for uplink and downlink service flowsand the permitted EPS bearer QoS.

The following table describes the pcrfFunction table.

Table 185. pcrfFunction table



NOT NULL

The identifier of apcrfFunction entity fromthe entityData table.


Table 185. pcrfFunction table (continued)


pcrfFunctionName 64-character string NOT NULL Name of the pcrfFunction(Policy Control andCharging Rules Function)instance configured on thephysical node thatimplements thepcrfFunction

MCC 3-character string A PCRF can supportmultiple PLMNs. The MCCattribute specifies theMobile Country Code(MCC) of the primaryPLMN supported by thePCRF. Primary PLMNusually means the solePLMN or the PLMN of theoperator responsible for theoperation and maintenanceof the PCRF. The MCCconsists of three digits.

MNC 3-character string A PCRF can supportmultiple PLMNs. The MNCattribute specifies theMobile Network Code(MNC) of the primaryPLMN supported by thePCRF. Primary PLMNusually means the solePLMN or the PLMN of theoperator responsible for theoperation and maintenanceof the PCRF. The length ofthe MNC (two or threedigits) depends upon thevalue of the MCC.

supportedPLMNs Integer This is a count of thenumber of PLMNs (PublicLand Mobile Networks)supported by the PCRF.

emsDistinguishedName 255-character string Distinguished name bywhich the PCRF is knownto its element managementsystem (EMS)

emsIpAddress 39-character string IP address of the elementmanagement system

vendorName 64-character string Vendor or manufacturer ofthe PCRF

vendorModuleType 64-character string Vendor specific PCRF Type

softwareVersion 64-character string Vendor specific PCRFsofware version


Table 185. pcrfFunction table (continued)


operationalState Enumeration The operational state of thepcrfFunction. Takes one ofthe following values:

v Enabled

v Disabled

v Other

v Unknown

administrativeState Enumeration The administrative state ofthe pcrfFunction. Takes oneof the following values:

v Unlocked

v Locked

v Shutting Down

v Other

v Unknown

pgwFunctionThe pgwFunction table models the Packet Data Network Gateway, which providesuser plane connectivity to packet data networks. The role of the PGW isimplemented within a network hardware node and is modelled by NCIM usingthe pgwFunction entity type. Multiple pgwFunction instances can be implementedwithin a single network hardware node.

The following table describes the pgwFunction table.

Table 186. pgwFunction table



NOT NULL

The identifier of a pgwFunction location entityfrom the entityData table.

pgwFunctionName 64-characterstring

NOT NULL Name of the PGW function instance configuredon the physical node.

MCC 3-character string A PGW can support multiple PLMNs. The MCCattribute specifies the Mobile Country Code(MCC) of the primary PLMN supported by thePGW. Primary PLMN usually means the solePLMN or the PLMN of the operator responsiblefor the operation and maintenance of the PGW.The MCC consists of three digits.

MNC 3-character string A PGW can support multiple PLMNs. The MNCattribute specifies the Mobile Network Code(MNC) of the primary PLMN supported by thePGW. Primary PLMN usually means the solePLMN or the PLMN of the operator responsiblefor the operation and maintenance of the PGW.The length of the MNC (two or three digits)depends upon the value of the MCC.

supportedPLMNs Integer This is a count of the number of PLMNs (PublicLand Mobile Networks) supported by the PGW


Table 186. pgwFunction table (continued)



The distinguished name by which the PGW isknown to its element management system (EMS)


The IP address of the element managementsystem


The vendor/manufacturer of the PGW


Vendor specific PGW Type


Vendor specific PGW sofware version

operationalState Enumeration Operational state of the pgwFunction. Takes oneof the following values:

v Enabled

v Disabled

v Other

v Unknown

administrativeState Enumeration Administrative state of the pgwFunction. Takesone of the following values:

v Unlocked

v Locked

v Shutting Down

v Other

v Unknown

physicalBackplaneThe physicalBackplane table stores the attributes of chassis entities.

The following table describes the physicalBackplane table.

Table 187. physicalBackplane table


entityId 32-bit integer Foreign keyNot null

The identifier of a chassisentity from the entityDatatable.

fwRevision 255-characterstring

Firmware version for thisentity.

hwRevision 255-characterstring

Hardware version for thisentity.



manufacturingDate Timestamp Date of manufacture forthis entity.




Table 187. physicalBackplane table (continued)




relativePosition 32-bit integer Indication of the relativeposition of this entitywithin the containment.

swRevision 255-characterstring

An indication of thevendor-specific hardwaretype of the physical entity.



cdmType 32-bit integer The model name of theentity.

physicalIndex 32-bit integer The physical index for thisentity.

vendorType 255-characterstring

Vendor assigned typeinformation.

physicalCardThe physicalCard table represents card entities.

The following table describes the physicalCard table.

Table 188. physicalCard table



Not null

The identifier of a module(card) entity from theentityData table.

aisle 255-characterstring

Column or longitudinaldivision of an interior area.

altitude FLOAT Column or longitudinaldivision of an interior area.

cardConfigurationState NUMBER(3) Default value for this fieldis 0.


Table 188. physicalCard table (continued)


fruNumber 255-characterstring

Specifies the numberassigned to a FRU(field-replaceable unit) bythe manufacturer.

fruSerialNumber 255-characterstring

Specifies the serial numberassigned to a FRU(field-replaceable unit) bythe manufacturer.












partNumber 255-characterstring

Orderable part number forthis entity.

rfidTag 255-characterstring

Radio frequency ID tagidentifier.

rackPosition NUMBER(10) Particular vertical positionon a data center rack.


cdmRow 255-characterstring

Latitudinal division of aninterior area.


Software revision.








cdmType NUMBER(3) NOT NULL Default value for this fieldis 8.

userTracking 64-characterstring

Common language locationidentification (CLLI) code.

xCoordinate 255-characterstring

Angular distance (east andwest) from the primemeridian on the earth'ssurface.

yCoordinate 255-characterstring

Angular distance (northand south) from theequator on the earth'ssurface.




softwareImage 100-characterstring

isFRU Indication of whether thispiece of equipment isreplaceable in the field.Takes one of the followingvalues:

v True

v False

operStatus Enumeratedvalue

Operational status of thiscard. Takes one of thefollowing values:

v unknown

v ok

v disabled

v okButDiagFailed

v boot

v selfTest

v failed

v missing

v mismatchWithParent

v mismatchConfig

v diagFailed

v dormant

v outOfServiceAdmin

v outOfServiceEnvTemp




adminStatus Enumeratedvalue

Administrative status ofthis card. Takes one of thefollowing values:

v unknown

v enabled

v disabled

v reset

v outOfServiceAdmin

numItemsSupported 32-bit integer The number of itemssupported by this entity.For example, if the entitymodels a layer 1 card, thenthis number indicates thenumber of cards supportedon the entity. Negativevalues are ignored.

status 255-characterstring

Status of this entity.

primaryState 255-characterstring

Primary state of this entity.

This field only applieswhere the module is thecard of a layer 1 device.

secondaryState 255-characterstring

Secondary state of thisentity.

This field only applieswhere the module is thecard of a layer 1 device.

cardNumber 32-bit integer Card number.

physicalChassisThe physicalChassis table stores the attributes of chassis entities.

The following table describes the physicalChassis table.

Table 189. physicalChassis table


entityId 32-bit integer Foreign keyNot null

The identifier of a chassisentity from the entityDatatable.



altitude FLOAT Vertical height above sealevel at the particulargeographical location.

chassisUUID 255-characterstring

Unique identifier of thischassis.


Table 189. physicalChassis table (continued)














The model name of theentity.





rfidTag 255-characterstring

Radio frequency ID tagidentifier.

rackPosition 255-characterstring

Particular vertical positionon a data center rack.

relativePosition NUMBER(10) Indication of the relativeposition of this entitywithin the containment.


Latitudinal division of aninterior area.


Software revision.








cdmType NUMBER(3) NOT NULL Default value for this fieldis 2.

userTracking 255-characterstring

Common language locationidentification (CLLI) code.








className 32-characterstring

NOT NULL The name of a class ofdevices. The masterclassName field is in theentityClass table.

upTime 32-bit integer The time (in hundredths ofa second) since thenetwork managementportion of the system waslast reinitialized.




services 100-characterstring

A value that indicates theset of services that thisentity potentially offers.The value is a sum thatinitially takes the valuezero. Then, for each layer,L, in the range 1 through 7,that this node performstransactions for, 2 raised to(L - 1) is added to the sum.For example, a node thatperforms only routingfunctions would have avalue of 4 (2^(3-1)). A nodethat is a host offeringapplication services wouldhave a value of 72 (2^(4-1)+ 2^(7-1)). For the Internetsuite of protocols, valuesshould be calculatedaccordingly:





v Layer 7: Applications,for example supports theSMTP

For systems including OSIprotocols, layers 5 and 6can also be considered.

interfaceCount 32-bit integer The number of networkinterfaces (regardless oftheir current state) presenton this system.

isIpForwarding 16-characterstring

Indication of whether thisentity is acting as an IPgateway in respect to theforwarding of datagramsreceived by this entity butnot addressed to thisentity. IP gateways forwarddatagrams, whereas IPhosts do not, unless thesource is routed throughthe host. Takes one of thefollowing values:

v forwarding

v not-forwarding




accessIPAddress 39-characterstring

The IP address throughwhich this entity wasdiscovered and will bemonitored.Note: For non-IP entities,such as layer 1 opticaldevices, this field is null.

accessProtocol Enumerated type(string 7 chars)

String representation of thenetwork protocol. Takesone of the followingvalues:

v Unknown

v IPv4

v IPv6

v EMSKey

discoveryTime Timestamp Time at which the Detailsagent attempted todiscover the device. Thisvalue is stored even if thedevice is not accessibleusing SNMP.

Related reference:“entityClass” on page 135The entityClass table stores information on all device classes and relationshipsbetween device classes. The table belongs to the category entities.“mappings” on page 144The mappings table provides a means of looking up an alternative textual name. Itis used to map non-human-readable data to human-readable data. The mappingstable belongs to the category mapping.

physicalConnectorThe physicalConnector table stores information about physical connectors.

The following table describes the physicalConnector table.

Table 190. physicalConnector table


entityId 32-bit integer Not null The identifier of ageographical location fromthe entityData table.

fwRevision 64character string Firmware version for thisentity.

hwRevision 64character string Hardware version for thisentity.

manufacturer 32-bit integer Vendor-specific hardwaretype for this entity.



Table 190. physicalConnector table (continued)








Software revision.



cdmType Tiny integer Not null




physicalFanThe physicalFan table represents fan cooling unit entities.

The following table describes the physicalFan table.

Table 191. physicalFan table



Not null

The identifier of a fan entity fromthe entityData table.

fruNumber 255-character string Specifies the number assigned to aFRU (field-replaceable unit) by themanufacturer.

fruSerialNumber 255-character string Specifies the serial numberassigned to a FRU(field-replaceable unit) by themanufacturer.

fwRevision 255-character string Firmware version for this entity.


Table 191. physicalFan table (continued)


hwRevision 255-character string Hardware version for this entity.

manufacturer 255-character string Vendor-specific hardware type forthis entity.

manufacturingDate timestamp Date of manufacture for this entity.

model 255-character string Model name for this entity.

name 255-character string The textual name of the physicalentity. The value of this objectmust be the name of thecomponent as assigned by the localdevice and is suitable for use incommands entered at the consoleof the device. Depending on thephysical component naming syntaxof the device, this value might be atext name, for example console, or asingle component number, forexample a port number or amodule number.

partNumber 255-character string Orderable part number for thisentity.

relativePosition NUMBER(10),

This format isNUMBER(precision,scale), whereprecision is the numberof digits in a numberand scale is thenumber of digits tothe right of thedecimal point.

Indication of the relative positionof this entity within thecontainment.

swRevision 255-character string Software revision.

serialNumber 255-character string The serial number of the entity.

cdmType NUMBER(3)


Not null By default, this field takes thevalue 6

uuid 255-character string Unique identifier of this piece ofequipment.


Table 191. physicalFan table (continued)


physicalIndex NUMBER(10),


The physical index for this entity.

isFRU Enumerated value Indication of whether this piece ofequipment is replaceable in thefield. Takes one of the followingvalues:

v True

v False

vendorType 255-character string Vendor assigned type information.

physicalOtherThe physicalOther table stores attributes of a component whose physical entityclass is known, but does not match any of the supported values.

The following table describes the physicalOther table.

Table 192. physicalOther table



Not null











Table 192. physicalOther table (continued)




powerOperStatus Enumeratedvalue

Operation status. Takes oneof the following values:

v unknown

v offEnvOther

v on

v offAdmin

v offDenied

v offEnvPower

v offEnvTemp

v offEnvFan

powerAdminStatus Enumeratedvalue

Administrative status.Takes one of the followingvalues:

v unknown

v on

v off

v inlineAuto

v inlineOn



Software revision.



cdmType NUMBER(3) NOT NULL By default, takes the value0.

physicalIndex NUMBER(10) The physical index for thisentity.

physicalClass Enumeratedvalue

Takes one of the followingvalues:

v 1: unknown

v 2: other


Table 192. physicalOther table (continued)




physicalPowerSupplyThe physicalPowerSupply table represents a power supply unit (PSU) entity.

The following table describes the physicalPowerSupply table.

Table 193. physicalPowerSupply table



Not null




















Table 193. physicalPowerSupply table (continued)


relativePosition NUMBER(10), Indication of the relativeposition of this entitywithin the containment.


Software revision.



cdmType NUMBER(3) NOT NULL By default, this field takesthe value of 5.

uuid 255-characterstring

Unique identifier of thispiece of equipment.


isFRU Enumeratedvalue

Indication of whether thispiece of equipment isreplaceable in the field.Takes one of the followingvalues:

v True

v False

powerOperStatus Enumeratedvalue

See the values forcefcFRUPowerOperStatusin Eumerations table.

powerAdminStatus Enumeratedvalue

See the values forcefcFRUPowerAdminStatusin Eumerations table.



physicalSensorThe physicalSensor table represents sensor entities.

The following table describes the physicalSensor table.

Table 194. physicalSensor table



Not null

The identifier of a sensorentity from the entityDatatable.



altitude Floating-pointnumber

Vertical height above sealevel at the particulargeographical location.






Table 194. physicalSensor table (continued)








rackPosition 255-characterstring

Particular vertical positionon a data center rack.

relativePosition NUMBER(10) Indication of the relativeposition of this entitywithin the containment.



Software revision.

sensorID 255-characterstring

Identifier for a sensor.



cdmType NUMBER(3) The default value for thisfield is 7.







Table 194. physicalSensor table (continued)


sensorType Enumeratedvalue

Sensor type. Takes one ofthe following values:

v other

v unknown

v voltsAC

v voltsDC

v amperes

v watts

v hertz

v celsius

v percentRH

v rpm

v cmm

v truthValue

v specialEnum

sensorScale Enumeratedvalue

Sensor scale. Takes one ofthe following values:

v unknown

v yocto

v zepto

v atto

v femto

v pico

v nano

v micro

v milli

v Units

v kilo

v mega

v giga

v tera

v exa

v peta

v zetta

v yotta

sensorStatus Enumeratedvalue

Sensor status. Takes one ofthe following values:

v ok

v unavailable

v nonoperational

v unknown

sensorValue 255-characterstring

The value for the sensor.




physicalSlotThe physicalSlot table represents slot entities.

If you want this table to be populated with MIB data, you must configure theEntity agent to run during the discovery process. The Entity agent discoversdetailed containment information from the Entity MIB. By default, the Entity agentis configured not to run during discovery.

The following table describes the physicalSlot table:

Table 195. physicalSlot table



Not null

The identifier of a slot entity fromthe entityData table.

fwRevision 255-character string Firmware version for this entity.

hwRevision 255-character string Hardware version for this entity.

manufacturer 255-character string Vendor-specific hardware type forthis entity.

model 255-character string Model name for this entity.

name 255-character string The textual name of the physicalentity. The value of this objectmust be the name of thecomponent as assigned by the localdevice and is suitable for use incommands entered at the consoleof the device. Depending on thephysical component naming syntaxof the device, this value might be atext name, for example console, or asingle component number, forexample a port number or amodule number.

slotNumber NUMBER(10) Slot number.

relativePosition NUMBER(10) Indication of the relative positionof this entity within thecontainment.

swRevision 255-character string Software revision.

serialNumber 255-character string The serial number of the entity.

slotState Current state of the slot.

cdmType NUMBER(3) The default value for this field is 7.

powerRedundancyMode

17-character string Takes one of the following values:

v unknown

v notSupported

v redundant

v combined

physicalIndex NUMBER(10) The physical index for this entity.


Table 195. physicalSlot table (continued)


numItemsSupported NUMBER The number of items supported bythis slot. For example, if the slotmodels a layer 1 shelf, then thisnumber indicates the number ofcards supported on the shelf.Negative values are ignored.

status 255-character string Status of this entity.

primaryState 255-character string Primary state of this entity.

This field only applies where theslot is the rack or shelf of a layer 1device.

secondaryState 255-character string Secondary state of this entity.

This field only applies where theslot is the rack or shelf of a layer 1device.

vendorType 255-character string Vendor assigned type information.

pimEndpointThe pimEndPoint table represents the Protocol Independent Multicast (PIM) endpoints discovered in the network and their associated attributes.

The following table describes the pimEndPoint table.

Table 196. pimEndPoint table



Not null

The identifier of a PIM endpoint from the entityDatatable.

pimmode Enumeratedvalue


v unknown

v sparse

v dense

v sparseDense

The PIM mode.

designatedRouter 15-characterstring

IP address of theDesignated Router.

helloInterval 32-bit integer Frequency (seconds) ofPIM Hello messagetransmission.

joinPruneInterval 32-bit integer Frequency (seconds) ofPIM join/prune messages

csbrPreference 32-bit integer Candidate BSR preferencevalue. A value of -1 meansit is not a BSR candidate.

isCandidateRP 8-bit integer Indicates that the end pointacts as a Candidate RP.


Table 196. pimEndPoint table (continued)


rpCandidateGroup 15-characterstring

IP address of multicastgroup for which this endpoint is a Candidate RP.

rpCandidateMask 15-characterstring

Mask of multicast groupfor which this end point isa Candidate RP

crpHoldTime 32-bit integer The hold time for theCandidate RP. A value of 0indicates that this endpoint is not an RPcandidate.

bsrAddress 15-characterstring

Bootstrap Router IPaddress

bsrExpiryTime 32-bit Integer Time remaining until BSRis considered down (and anew one selected).


pimNetworkThe pimNetwork table holds the Protocol Independent Multicast (PIM) Networkcollection entity which collects all PIM-enabled routers.

The following table describes the pimNetwork table.

Table 197. pimNetwork table



Not null

The identifier of the PIMNetwork collection entity.

pimServiceThe pimService table represents a Protocol Independent Multicast (PIM) serviceand includes relevant protocol data.

The following table describes the pimService table.

Table 198. pimService table



Not null

The identifier of a PIMservice entity from theentityData table.

joinPruneInterval 32-bit integer The PIM join/prunemessage interval (inseconds).


Table 198. pimService table (continued)


isRP 8-bit integer Indicates whether theservice is known to beacting as a RendezvousPoint for one or moreMulticast Groups.

isCRP 8-bit integer Indicates whether theservice acts as a CandidateRendezvous Point for oneor more Multicast Groups.

isBSR 8-bit integer Indicates whether theservice is known to beacting as a BootstrapRouter.

isCBSR 8-bit integer Indicates whether theservice acts as a CandidateBootstrap Router.

isDR 8-bit integer Indicates whether theservice acts as aDesignated Router.

plmnThe plmn table models a Public Land Mobile Network (PLMN). A PLMN is anetwork that provides land mobile telecommunications services to the public. Eachoperator providing mobile services has its own PLMN.

The following table describes theplmn table.

Table 199. plmn table

Columnname

Type Constraints Description


NOT NULL

The identifier of a plmn entity from theentityData table.

plmnName 64-characterstring

Name or description of the PLMN

MCC 3-characterstring

Specifies the Mobile Country Code (MCC) of thePLMN. The MCC consists of three digits.

MNC 3-characterstring

Specifies the Mobile Network Code (MNC) ofthe PLMN. The length of the MNC (two or threedigits) depends upon the value of the MCC.


portEndPointThe portEndPoint holds data about TCP/UDP endpoints found by the NMAPScanagent.

The following table describes the pimEndPoint table.

Table 200. pimEndPoint table


entityId Integer Not null

Primary key

The entityId of theportEndPoint entity.

portId Integer Not null The numeric port ID, suchas 3306 for MySQL.

portState 15-characterstring

The port state, such asopen/closed.

protocol 5-character string The protocol, whether TCPor UDP.

serviceProduct 255-characterstring

The name of the portservice, such as MySQL forport 3306.

serviceVersion 75-characterstring

The version if available,such as 5.0.54a-enterprise.

serviceName 75-characterstring

The service name, typicallyshort, such as mysql or ftp.


ranBaseStationThe ranBaseStation table describes Radio Access Network (RAN) base stations.

The following table describes the ranBaseStation table.

Table 201. ranBaseStation table


baseStationId varchar(64) not null A string identifying thebase station. In a namingconvention that follows theGSM 04.08 standard, thestring consists of theNetwork Color Code(NCC) and the Base StationCode (BSC).

entityId Integer not null The identifier of a basestation entity from theentityData table.


Table 201. ranBaseStation table (continued)


ranTechnologyType varchar(10) The type of wirelesstechnology used by thebase station. Possiblevalues are:

v Unknown

v Other

v GSM

v GPRS

v UMTS

ranBaseStationControllerThe ranBaseStationController table describes Radio Access Network (RAN) basestation controllers.

The following table describes the ranBaseStationController table.

Table 202. ranBaseStationController table


baseStationControllerId varchar(64) A string identifying thebase station controller. In anaming convention thatfollows the GSM 04.08standard, the stringconsists of the Base StationColor Code (BSC).

entityId Integer not null The identifier of a basestation controllers entityfrom the entityData table.


v Unknown

v Other

v GSM

v GPRS

v UMTS

ranCircuitSwitchedCoreThe ranCircuitSwitchedCore table describes RAN circuit switched core entities,which are collection entities that collect the entities involved in the circuit switchedcore network of a given mobile phone network.

The following table describes the ranCircuitSwitchedCore table.


Table 203. ranCircuitSwitchedCore table


entityId Integer not null The identifier of a RANcircuit switched core entityfrom the entityData table.

mcc varchar(64) Mobile country code,which consists of threedigits. The MCC uniquelyidentifies the country ofdomicile of the mobilesubscriber.

mnc varchar(64) Mobile network code,which consists of two orthree digits for GSM andUMTS applications. TheMNC identifies the homePLMN (Public LandMobile Network) of themobile subscriber. Thelength of the MNC (two orthree digits) depends onthe value of the MCC.

ranGGSNThe ranGGSN table describes Radio Access Network (RAN) Gateway GPRSServing Nodes (GGSNs).

The following table describes the ranGGSN table.

Table 204. ranGGSN table


accessPointName varchar(64) The Access Point Name isa unique name that isassociated with the IPaddress of a specific GGSNthrough a DNS lookup.

entityId Integer not null The identifier of a GGSNentity from the entityDatatable.

ggsnId varchar(64) A unique identifier for theGGSN.


v Unknown

v Other

v GSM

v GPRS

v UMTS


ranGSMCellThe ranGSMCell table describes Radio Access Network (RAN) GSM cells.

The following table describes the ranGSMCell table.

Table 205. ranGSMCell table


bcc integer The Base station Color Code(BCC), which is used to distinguishneighboring cells of the sameoperator on the same channel.

broadcastPower varchar(64) The broadcast channel power level(dBm).

broadcastScramblingCode

integer From 0 to 500. Used to generate the primaryscrambling code.

cellId varchar(64) Unique identifier for the cell.

entityId Integer not null The identifier of a GSM cell entityfrom the entityData table.

hopSeqNum integer From 0 to 63. The hopping sequence number.Defines the set of channels that thecell is to use for frequencyhopping.

msTxPower integer The maximum power level that themobile station is allowed to use.

ncc integer The Network Color Code (NCC) isused to distinguish neighboringcells between operators of differentcountries broadcasting channel.

racc integer The Routing Area Color Code.

ranTechnologyType varchar(10) The type of wireless technologyused by the base station. Possiblevalues are:

v Unknown

v Other

v GSM

v GPRS

v UMTS

rxLevAccessMin integer The minimum Rx signal strengththreshold.

tsc integer From 0 to 7. Specifies the Training SequenceCode (TSC) used in the cell.


ranLocationAreaThe ranLocationArea table describes Radio Access Network (RAN) location areas,in which there may be one or more GSM/UMTS cells. This entity is a collectionand it models those devices within which a given mobile user can move for voiceaccess before having to switch to a different location area.

The following table describes the ranLocationArea table.

Table 206. ranLocationArea table


entityId Integer not null The identifier of a RANlocation area entity fromthe entityData table.

lac varchar(64) not null The Location Area Code(LAC) identifies a locationarea within a PLMN.

mcc varchar(64) not null The three-digit MobileCountry Code (MCC)uniquely identifies thecountry of the mobilesubscriber.

mnc varchar(64) not null The Mobile Network Code(MNC) identifies the homePLMN (Public LandMobile Network) of themobile subscriber. Thelength of the MNC (two orthree digits) depends onthe value of the MCC(Mobile Country Code).

ranMediaGatewayThe ranMediaGateway table describes Radio Access Network (RAN) mediagateways.

The following table describes the ranMediaGateway table.

Table 207. ranMediaGateway table


entityId Integer not null The identifier of a mediagateway entity from theentityData table.

mgwId varchar(64) Unique identifier for themedia gateway.


ranMobileSwitchingCentreThe ranMobileSwitchingCentre table describes Radio Access Network (RAN)Mobile Switching Centers.

The following table describes the ranMobileSwitchingCentre table.

Table 208. ranMobileSwitchingCentre table


entityId Integer not null The identifier of atransceiver entity from theentityData table.

mscId varchar(64) A unique,enterprise-specificidentifier for the mobileswitching center.

mscType varchar(10) The type of the mobileswitching centers. Possiblevalues are:

v Unknown

v Other

v Voice Switch

v MSCS

v Type2G3G


v Unknown

v Other

v GSM

v GPRS

v UMTS

ranMSSThe ranMSS table describes Radio Access Network (RAN) mobile switching centerservers.

The following table describes the ranMSS table.

Table 209. ranMSS table


entityId Integer not null The identifier of a mobileswitching center serverentity from the entityDatatable.

mssId varchar(64) Unique identifier for theMMS.


ranNodeBThe ranNodeB table describes Node B entities.

The following table describes the ranNodeB table.

Table 210. ranNodeB table


entityId Integer not null The identifier of a Node Bentity from the entityDatatable.

ranTechnologyType varchar(10) The wireless technologytype for this entity, whichcan take any of thefollowing values:

v 0: Unknown

v 1: Other

v 2: GSM

v 3: GPRS

v 4: UMTS

nodeBId varchar(64) not null Node B entity identifierstring

ranNodeBLocalCellThe ranNodeBLocalCell table models the local Node B identifier. This identifier isrelated to local hardware that is available to manage a given cell.

The following table describes the ranNodeBLocalCell table.

Table 211. ranNodeBLocalCell table


entityId Integer not null The identifier of a Node Blocal cell entity from theentityData table.


v 0: Unknown

v 1: Other

v 2: GSM

v 3: GPRS

v 4: UMTS

localCellId varchar(64) not null Node B local cell entityidentifier string


ranPacketControlUnitThe ranPacketControlUnit table describes Radio Access Network (RAN) basestation controllers.

The following table describes the ranPacketControlUnit table.

Table 212. ranPacketControlUnit table



pcuId varchar(64) Unique internal identifierfor the Packet ControlUnit. In some networks,this is the same as the BaseStation Controller ID.


v Unknown

v Other

v GSM

v GPRS

v UMTS

ranPacketSwitchedCoreThe ranPacketSwitchedCore table describes RAN packet switched core entities,which are collection entities that collect the entities involved in the packet switchcore network of a given mobile phone network.

The following table describes the ranPacketSwitchedCore table.

Table 213. ranPacketSwitchedCore table


entityId Integer not null The identifier of a RANpacket switched core entityfrom the entityData table.



Table 213. ranPacketSwitchedCore table (continued)



ranRadioCoreThe ranRadioCore table describes RAN radio core entities, which are collectionentities that collect the entities involved in the RAN network radio core; that is,radio network controller (RNC) and base station controller (BSC) entities.

The following table describes the ranRadioCore table.

Table 214. ranRadioCore table


entityId Integer not null The identifier of a RANradio core entity from theentityData table.




ranRadioNetworkControllerThe ranRadioNetworkController table describes RAN radio network controllerentities.

The following table describes the ranRadioNetworkController table.

Table 215. ranRadioNetworkController table


entityId Integer not null The identifier of a RANradio network controllerentity from the entityDatatable.


v 0: Unknown

v 1: Other

v 2: GSM

v 3: GPRS

v 4: UMTS

rncId varchar(64) not null RAN radio networkcontroller entity identifierstring. A unique identifierin the network in whichthe RNC is operational.

ranRoutingAreaThe ranRoutingArea table describes RAN routing area entities, which are deviceswithin which a given mobile user can move for data access before having to switchto a different routing area.

The following table describes the ranRoutingArea table.

Table 216. ranRoutingArea table


entityId Integer not null The identifier of a RANrouting area entity fromthe entityData table.

rac varchar(10) not null Enterprise-specific routingarea code.

mcc varchar(64) not null Mobile country code,which consists of threedigits. The MCC uniquelyidentifies the country ofdomicile of the mobilesubscriber.


Table 216. ranRoutingArea table (continued)


mnc varchar(64) not null Mobile network code,which consists of two orthree digits for GSM andUMTS applications. TheMNC identifies the homePLMN (Public LandMobile Network) of themobile subscriber. Thelength of the MNC (two orthree digits) depends onthe value of the MCC.

lac varchar(64) not null Location area code, whichis a fixed length code (of 2octets) identifying alocation area within aPLMN.

ranSectorTheranSector table describes Radio Access Network (RAN) cell sectors.

The following table describes the ranSector table.

Table 217. ranSector table


beamDirection integer The beam direction of thesector. Degrees 0 – North,90 East, 180 South, 270West.

entityId Integer not null The identifier of a cellsector entity from theentityData table.

sectorHeight integer Height of the sector aboveground in centimeters.

sectorId varchar (64) not null Enterprise-specific sectoridentifier.

ranSGSNThe ranSGSN table describes Radio Access Network (RAN) Serving GPRS ServingNodes (SGSNs).

The following table describes the ranSGSN table.

Table 218. ranSGSN table


entityId Integer not null The identifier of a SGSNentity from the entityDatatable.


Table 218. ranSGSN table (continued)



v Unknown

v Other

v GSM

v GPRS

v UMTS

sgsnId varchar(64) not null Unique identifier for theSGSN.

ranTransceiverThe ranTransceiver table describes transceivers.

The following table describes the ranTransceiver table.

Table 219. ranTransceiver table



transceiverType varchar(10) The type of transceiver,which can be any of thefollowing values:

v 0: Unknown

v 1: Other

v 2: Normal

v 3: Dedicated

v 4: Extended

trxId varchar(64) not null Transceiver identifier string

ranUtranCellThe ranUtranCell table describes Radio Access Network (RAN) UTRAN cells.

The following table describes the ranUtranCell table.

Table 220. ranUtranCell table


broadcastPower varchar(64) The broadcast channel power level(dBm).

broadcastScramblingCode

integer From 0 to 500. Used to generate a number forcode scrambling.

cellId varchar(64) not null Unique identifier for the cell.

entityId Integer not null The identifier of a transceiverentity from the entityData table.


Table 220. ranUtranCell table (continued)


maxTransmissionPower

integer Maximum transmission power forall downlink channels that areallowed to be used simultaneouslyin a cell, added together Unit: 0.1dBm Range 0-500.

primarySchPower integer Primary synchronization power.Unit: 0.1 dB Range: 350-150.

primaryScramblingCode

long A code used to separate thetransmission of one cell fromanother.

secondarySchPower integer Secondary synchronization power.Unit: 0.1 dB Range: 350-150.

uarfcnDL integer Absolute downlink radio frequencynumber.

uarfcnUL integer Absolute uplink radio frequencynumber.

rtExportListThe rtExportList table stores export route targets associated with VirtualForwarding and Routing (VRF).

The following table describes the rtExportList table.

Table 221. rtExportList table



Not null

The identifier of a routetarget export list entityfrom the entityData table.

routeTarget 64-characterstring

Not null Router target value.

rtImportListThe rtImportList table stores import route targets associated with VirtualForwarding and Routing (VRF).

The following table describes the rtImportList table.

Table 222. rtImportList table

Column Name Type Constraints Description


Not null

The identifier of a routetarget import list entityfrom the entityData table.

routeTarget 64-characterstring

Not null The router target value.


sgwFunctionThe sgwFunction table models the Serving Gateway (SGW), which resides in theuser plane where it forwards and routes packets to and from the eNodeB andpacket data network gateway (PGW). The role of the SGW is implemented withina network hardware node and is modelled by NCIM using the sgwFunction entitytype. Multiple sgwFunction instances can be implemented within a single networkhardware node.

The following table describes the sgwFunction table.

Table 223. sgwFunction table



NOT NULL

The identifier of an sgwFunction location entityfrom the entityData table.

sgwFunctionName 64-characterstring

NOT NULL Name of the SGWFunction instance configuredon Physical node that implement theSGWFunction

MCC 3-character string An SGW can support multiple PLMNs. TheMCC attribute specifies the Mobile CountryCode (MCC) of the primary PLMN supportedby the SGW. Primary PLMN usually means thesole PLMN or the PLMN of the operatorresponsible for the operation and maintenanceof the SGW. The MCC consists of three digits.

MNC 3-character string An SGW can support multiple PLMNs. TheMNC attribute specifies the Mobile NetworkCode (MNC) of the primary PLMN supportedby the SGW. Primary PLMN usually means thesole PLMN or the PLMN of the operatorresponsible for the operation and maintenanceof the SGW. The length of the MNC (two orthree digits) depends upon the value of theMCC.

supportedPLMNs Integer This is a count of the number of PLMNs (PublicLand Mobile Networks) supported by the SGW


The distinguished name by which the SGW isknown to its element management system(EMS)


The IP address of the element managementsystem


The vendor/manufacturer of the SGW


Vendor specific SGW Type


Vendor specific SGW sofware version

operationalState Enumeration Operational state of the sgwFunction. Takes oneof the following values:

v Enabled

v Disabled

v Other

v Unknown


Table 223. sgwFunction table (continued)


administrativeState Enumeration Administrative state of the sgwFunction. Takesone of the following values:

v Unlocked

v Locked

v Shutting Down

v Other

v Unknown

snmpSystemThe snmpSystem table represents a Simple Network Management Protocol (SNMP)managed host on a network.

The following table describes the snmpSystem table.

Table 224. snmpSystem table


entityId Integer not null The identifier of ansnmpSystem entity fromthe entityData table.

sysContact 255-characterstring

The textual identificationof the contact person forthis managed node, andinformation on how tocontact this person. If nocontact information isknown, the value is thezero-length string.

sysDescr 255-characterstring

A textual description of theentity. This value mustinclude the full name andversion identification of thesystem hardware type,software operating-system,and networking software.

sysLocation 255-characterstring

The physical location ofthis node, for example“telephone closet, 3rdfloor.” If the location isunknown, the value is thezero-length string.

sysName 255-characterstring

An administratively-assigned name for thismanaged node. Byconvention, this is thefully-qualified domainname of the node. If thename is unknown, thevalue is the zero-lengthstring.


Table 224. snmpSystem table (continued)


sysObjectId 100-characterstring

The vendor's authoritativeidentification of thenetwork managementsubsystem contained in theentity.

subnetThe subnet table represents a logical collection of IP addresses collected within asubnet.

The following table describes the subnet table

Table 225. subnet table


entityId 32-bit integer Not nullForeign key

The identifier of a subnetentity from the entityDatatable.

network 39-characterstring

Not null The IP address of thissubnet.


Not null The netmask for thissubnet.

protocol String value An integer representationof the IP protocol used bythe presently-defined zone:

v 1: IPv4


v 3: IPv6

netmaskBits 32–bit integer Netmask bits for thesubnet

addressSpace 255–characterstring

Relevant NAT addressspace if network addresstranslation is being used.

trackingAreaThe trackingArea table models an LTE tracking area.

The following table describes the trackingArea table.

Table 226. trackingArea table



NOT NULL

The identifier of a trackingArea location entityfrom the entityData table.

TAC 64-characterstring

Tracking Area Code (TAC), consisting of 16 bits.This is an identifier for the tracking area and isunique within a public land mobile network(PLMN).


Table 226. trackingArea table (continued)


TAI 64-characterstring

NOT NULL Tracking Area Identifier (TAI). This is a globallyunique tracking area identifier, made up of thePLMN ID and the TAC.

trackingAreaName 64-characterstring

Name of the tracking area.

transmissionTpThe transmissionTp table provides information about transmission interfaceentities in the network.

The following table describes the transmissionTp table.

Table 227. transmissionTp table


entityId 32–bit integer Not null The identifier of atransmission interfaceentity from the entityDatatable.

tpType 3-character string The type of transmissioninterface entity:

v Physical terminationpoint (PTP)

v Connection terminationpoint (CTP)

primaryState 255-characterstring

Primary state of this entity.

secondaryState 255-characterstring

Secondary state of thisentity.

layerRate 255-characterstring

Layer rate of thetransmission interfaceentity.

isEdgePoint 5-character string Label of the transmissioninterface entity. Takes oneoft he following values:

v True

v False

mappingMode 255-characterstring

Mapping mode of thetransmission interfaceentity.


userPlaneViewCollectionThe userPlaneViewCollection table supports the dynamic collection views underLTE Network Topology > User Plane by Tracking Area in the Network Views.Each instance of this entity type collects the eNodeBs in the corresponding trackingarea, together with the devices that these eNodeBs are connected to on the userplane.

The following table describes the userPlaneViewCollection table.

Table 228. userPlaneViewCollection table



NOT NULL

The identifier of auserPlaneViewCollectionentity from the entityDatatable.

viewType 64-character string NOT NULL Specifies the type of view.

vlanCollectionThe vlanCollection table represents a collection of the ports on a given namedVLAN or, if no name is provided, on a given VLAN identifier.

The following table describes the vlanCollection table.

Table 229. vlanCollection table



Not null

The identifier of a VLANcollection entity from theentityData table.

vlanId 39-characterstring

The identifier of thisVLAN collection.

vlanName 39-characterstring

The name of this VLANcollection, as defined bythe network administrator.This is not the same as thename of the vlanCollectionobject defined in theentityData table in theentityName field.

vlanTrunkEndPointThe vlanTrunkEndPoint table represents a VLAN trunk end point and includesrelevant data. This endpoint is implemented by a physical interface, as modeled inthe protocolEndPoint table.

The following table describes the vlanTrunkEndPoint table.

Table 230. vlanTrunkEndPoint table



Not null

The identifier of a VLANtrunk endpoint entity fromthe entityData table.


Table 230. vlanTrunkEndPoint table (continued)



vlanId 32-bit integer The identifier for theVLAN carried by thisprotocol end point object.If multiple VLANs arecarried by the trunk then avlanTrunkEndPoint entityshould be created for eachone.

vlanTag 32-bit integer The tag used for thisVLAN. In Cisco devices,this tag is usually the sameas the vlanId value.However, for othermanufacturers, the tagmight be different.


vpnRouteForwardingThe vpnRouteForwarding table models a VPN routing and forwarding table.

The following table describes the vpnRouteForwarding table.

Table 231. vpnRouteForwarding table



Not null

The identifier of a VPNRouting and Forwardingtable entity from theentityData table.

VRFName 255-characterstring

The name of the VPNRouting and Forwardingtable.

routeDistinguisher 255-characterstring

Not null The route distinguisher forthe VPN Routing andForwarding table.


vpwsEndPointThe vpwsEndPoint table represents a VPWS end point and includes relevant data.This endpoint is implemented by a physical interface, as modeled in theprotocolEndPoint table.

The following table describes the vpwsEndPoint table.

Table 232. vpwsEndPoint table



Primary key

Not null


VCID 64-characterstring

Primary key

Not null

The Virtual CircuitIdentifier (VCID) for thisentity.

circuitId 128-characterstring

The ID for this circuit.

circuitType 32-bit integer The type of circuit.

circuitStatus 32-bit integer The status of circuit.

inboundLabel 32-bit integer The inbound label relatedto this endpoint.

outboundLabel 32-bit integer The outbound label relatedto this endpoint.


vtpDomainThe vtpDomain table represents a VLAN trunking protocol domain.

The following table describes the vtpDomain table.

Table 233. vtpDomain table



Not null

The identifier of a VTPdomain entity from theentityData table.

vtpDomainName 64-characterstring

Not null The name of this VTPdomain.

vtpDomainLocalMode 15-characterstring

The local mode of this VTPdomain.


Entity attribute viewsEntity attribute views define attributes for the entities discovered by NetworkManager, in legacy NCIM topology database format. This enables backwardcompatibility; for example, SQL queries written to use the legacy NCIM databasetables still function because they retrieve data from the entity attribute views.

backplaneThe backplane view joins data from a number of tables and is equivalent to thebackplane table that existed in Network Manager version 3.9 and earlier , therebyensuring backward compatibility.

The following table describes the backplane view.

Table 234. backplane view

Column name DescriptionContaining table and fieldname


physicalBackplane

entityId


physicalBackplane

Model


physicalBackplane

RelativePosition

entPhysicalIndex The physical index for thisentity.

physicalBackplane

PhysicalIndex

entPhysicalName The textual name of thephysical entity. The value ofthis object must be the nameof the component as assignedby the local device and issuitable for use in commandsentered at the console of thedevice. Depending on thephysical component namingsyntax of the device, thisvalue might be a text name,for example console, or a singlecomponent number, forexample a port number or amodule number.

physicalBackplane

Name


Table 234. backplane view (continued)



entityData

Description

chassisThe chassis view joins data a number of tables, and is equivalent to the chassistable that existed in Network Manager versions 3.9 and earlier, thereby ensuringbackward compatibility.

The following table describes the chassis view.

Table 235. chassis view



physicalChassis

entityId

className The name of a class ofdevices. The masterclassName field is in theentityClass table.

physicalChassis

className

sysName An administratively-assignedname for this managed node.By convention, this is thefully-qualified domain nameof the node. If the name isunknown, the value is thezero-length string.

physicalChassis

sysName

sysDescr A textual description of theentity. This value must includethe full name and versionidentification of the systemhardware type, softwareoperating-system, andnetworking software.

entityData

Description

sysObjectId The vendor's authoritativeidentification of the networkmanagement subsystemcontained in the entity.

physicalChassis

sysObjectId

sysLocation The physical location of thisnode, for example “telephonecloset, 3rd floor.” If thelocation is unknown, the valueis the zero-length string.

physicalChassis

Location


Table 235. chassis view (continued)


sysContact The textual identification ofthe contact person for thismanaged node, andinformation on how to contactthis person. If no contactinformation is known, thevalue is the zero-length string.

physicalChassis

Contact

sysUpTime The time (in hundredths of asecond) since the networkmanagement portion of thesystem was last reinitialized.

physicalChassis

UpTime

sysServices A value that indicates the setof services that this entitypotentially offers. The value isa sum that initially takes thevalue zero. Then, for eachlayer, L, in the range 1through 7, that this nodeperforms transactions for, 2raised to (L - 1) is added tothe sum. For example, a nodethat performs only routingfunctions would have a valueof 4 (2^(3-1)). A node that is ahost offering applicationservices would have a valueof 72 (2^(4-1) + 2^(7-1)). Forthe Internet suite of protocols,values should be calculatedaccordingly:





v Layer 7: Applications, forexample supports the SMTP

For systems including OSIprotocols, layers 5 and 6 canalso be considered.

physicalChassis

Services

ifNumber The number of networkinterfaces (regardless of theircurrent state) present on thissystem.

physicalChassis

InterfaceCount




ipForwarding Indication of whether thisentity is acting as an IPgateway in respect to theforwarding of datagramsreceived by this entity but notaddressed to this entity. IPgateways forward datagrams,whereas IP hosts do not,unless the source is routedthrough the host. Takes one ofthe following values:

v forwarding

v not-forwarding

physicalChassis

isIpForwarding


physicalChassis

Model


physicalChassis

RelativePosition


physicalChassis

physicalIndex


physicalChassis

Name


entityData

Description





physicalChassis

SerialNumber

modelName The model name of the entity. physicalChassis

Model

orderablePartNumber Orderable part number forthis entity.

physicalChassis

PartNumber

hardwareVersion Hardware version for thisentity.

physicalChassis

HWRevision

OSType The operating system typerelated to this chassis.

operatingSystem

OSName

OSVersion The operating system versionrelated to this chassis.

operatingSystem

OSVersion

OSImage The operating system imagerelated to this chassis.

operatingSystem

VersionString

accessIPAddress The IP address through whichthis entity was discovered andwill be monitored.Note: For non-IP entities, suchas layer 1 optical devices, thisfield is null.

physicalChassis

accessIP

accessProtocol An integer representation ofthe network protocol used bythe presently-defined zone:

v 0: Unknown

v 1: IPv4


v 3: IPv6


physicalChassis

accessProtocol

memorySize The size, in MB, of theavailable memory.

computerSystem

MemorySize

discoveryTime Time at which the Detailsagent attempted to discoverthe device. This value isstored even if the device is notaccessible using SNMP.

physicalChassis

DiscoveryTime

Related reference:“entityData” on page 136The entityData table stores data on entities. This table belongs to the categoryentities.


“physicalChassis” on page 228The physicalChassis table stores the attributes of chassis entities.

fanThe fan view joins data from a number of tables and is equivalent to the fan tablethat existed in Network Manager versions 3.9 and earlier , thereby ensuringbackward compatibility.

The following table describes the fan view.

Table 236. fan view



entityData

entityId


physicalFan

Model


physicalFan

RelativePosition


physicalFan

physicalIndex


physicalFan

Name

entPhysicalDescr A textual description of theentity. This value must includethe full name and versionidentification of the systemhardware type, softwareoperating-system, andnetworking software.

entityData

Description


Table 236. fan view (continued)



physicalFan

SerialNumber

modelName Model name for this entity. physicalFan

Model

isFieldReplaceable Indication of whether thispiece of equipment isreplaceable in the field. Takesone of the following values:

v True

v False

physicalFan

isFRU

Related reference:“entityData” on page 136The entityData table stores data on entities. This table belongs to the categoryentities.“physicalFan” on page 233The physicalFan table represents fan cooling unit entities.

interfaceThe interface view joins data from a number of tables and is equivalent to theinterface table that existed in Network Manager version 3.9 and earlier , therebyensuring backward compatibility.

The following table describes the interface view.

Table 237. interface view



networkInterface

entityData

ifIndex The index of the interface. networkInterface

SNMPIndex

ifPhysAddress The physical address of theinterface.

networkInterface

PhysicalAddress


networkInterface

ifName

ifDescr A description of the interface. networkInterface

ifDescr

ifAlias The alias for the interface. networkInterface

ifAlias


Table 237. interface view (continued)


ifSpeed An estimate of the currentbandwidth of the interface inbits per second.

networkInterface

ifSpeed

ifHighSpeed An estimate of the currentbandwidth of the interface inunits of 1,000,000 bits persecond.

networkInterface

ifHighSpeed

ifAdminStatus The required state of theinterface. Takes one of thefollowing values:

v Up

v Down

v Testing

networkInterface

ifAdminStatus

ifOperStatus The current operational stateof the interface. Takes one ofthe following values:

v Up

v Down

v Testing

v unknown

v dormant

v notPresent

v lowerLayerDown

networkInterface

ifOperStatus

ifType The interface type. networkInterface

IANAInterfaceType

ifTypeString The textual string for theinterface type.

networkInterface

ifTypeString

ifMTU The maximum transmissionunit for this interface.

networkInterface

MTU

ifPromiscuousMode Indicates whether thisinterface only accepts packetsor frames addressed to thisstation. Takes one of thefollowing values:

v True

v False

networkInterface

PromiscuousMode

ifConnectorPresent Indicates whether theinterface has a connector.Takes one of the followingvalues:

v True

v False

networkInterface

ConnectorPresent




accessIPAddress The IP address through whichthis entity was discovered andwill be monitored.Note: For non-IP entities,such as layer 1 opticaldevices, this field is null.

networkInterface

accessIP

accessProtocol An integer representation ofthe network protocol used bythe presently-defined zone:

v 0: Unknown

v 1: IPv4


v 3: IPv6


networkInterface

accessProtocol

entPhysicalVendorType The vendor-specific hardwaretype of this physical entity.

x_cdmPhysicalConnector

Model

entPhysicalParentRelPos The relative position of thisentity within the containment.


RelativePosition



physicalIndex

entPhysicalName The textual name of thisphysical entity.


Name

entPhysicalDescr The textual description of thisphysical entity.


entPhysicalDescr

portNumber The port number for thisinterface on the chassisdevice. The method ofdetermining the port numberis dependent on the make andmodel of the device that isdiscovered. For this reason,use this value with caution.

networkInterface

portNumber

isTrunkPort Indicates whether thisphysical interface is a VLANtrunk port.

networkInterface

SwitchPortMode




duplex Actual duplex of the interface.Takes one of the followingvalues:

v HalfDuplex

v FullDuplex

v Auto

v Unknown

v Other

networkInterface

OperationalDuplex

Related reference:“entityData” on page 136The entityData table stores data on entities. This table belongs to the categoryentities.“networkInterface” on page 211The networkInterface table represents interfaces on a chassis device.

moduleThe module view joins data from a number of tables and is equivalent to the moduletable that existed in Network Manager version 3.9 and earlier , thereby ensuringbackward compatibility.

The following table describes the module view.

Table 238. module view



physicalCard

entityId


physicalCard

Model


physicalCard

RelativePosition


physicalCard

Physical Index


Table 238. module view (continued)



physicalCard

Name

entPhysicalDescr A textual description of theentity. This value must includethe full name and versionidentification of the systemhardware type, softwareoperating-system, andnetworking software.

entityData

Description


physicalCard

SerialNumber

modelName Model name for this entity. physicalCard

Model

orderablePartNumber Orderable part number forthis entity.

physicalCard

PartNumber

hardwareVersion Hardware version for thisentity.

physicalCard

HWRevision

firmwareVersion Firmware version for thisentity.

physicalCard

FWRevision

softwareVersion Software revision. physicalCard

SWRevision

softwareImage physicalCard

softwareImage


v True

v False

physicalCard

isFRU


Table 238. module view (continued)


operStatus Operational status of this card.Takes one of the followingvalues:

v unknown

v ok

v disabled

v okButDiagFailed

v boot

v selfTest

v failed

v missing

v mismatchWithParent

v mismatchConfig

v diagFailed

v dormant

v outOfServiceAdmin

v outOfServiceEnvTemp

physicalCard

operStatus

adminStatus Administrative status of thiscard. Takes one of thefollowing values:

v unknown

v enabled

v disabled

v reset

v outOfServiceAdmin

physicalCard

adminStatus

cardNumber Indication of the relativeposition of this entity withinthe containment.

physicalCard

RelativePosition

Related reference:“entityData” on page 136The entityData table stores data on entities. This table belongs to the categoryentities.“physicalCard” on page 225The physicalCard table represents card entities.

otherThe other view joins data from a number of tables and is equivalent to the othertable that existed in Network Manager version 3.9 and earlier , thereby ensuringbackward compatibility.

The following table describes the other view.


Table 239. other view


entityId The identifier of a networkpipe entity from theentityData table.

physicalOther

entityId


physicalOther

vendorType


physicalOther

relativePosition


physicalOther

physicalIndex


physicalOther

name


entityData

description

entPhysicalClass Takes one of the followingvalues:

v 1: unknown

v 2: other

physicalOther

physicalClass

Related reference:“entityData” on page 136The entityData table stores data on entities. This table belongs to the categoryentities.


“physicalOther” on page 235The physicalOther table stores attributes of a component whose physical entityclass is known, but does not match any of the supported values.

psuThe psu view joins data from a number of tables and is equivalent to the psu tablethat existed in Network Manager version 3.9 and earlier , thereby ensuringbackward compatibility.

The following table describes the psu view.

Table 240. psu view



physicalPowerSupply

entityId


physicalPowerSupply

Model


physicalPowerSupply

RelativePosition


physicalPowerSupply

PhysicalIndex


physicalPowerSupply

Name


Table 240. psu view (continued)



entityData

Description


physicalPowerSupply

SerialNumber

modelName Model name for this entity. physicalPowerSupply

Model


v True

v False

physicalPowerSupply

isFRU

adminStatus See the values forcefcFRUPowerAdminStatus inEumerations table.

physicalPowerSupply

powerAdminStatus

operStatus See the values forcefcFRUPowerOperStatus inEumerations table.

physicalPowerSupply

powerOperStatus

Related reference:“entityData” on page 136The entityData table stores data on entities. This table belongs to the categoryentities.“physicalPowerSupply” on page 237The physicalPowerSupply table represents a power supply unit (PSU) entity.

sensorThe sensor view joins data from a number of tables and is equivalent to the sensortable that existed in Network Manager version 3.9 and earlier , thereby ensuringbackward compatibility.

The following table describes the sensor view.

Table 241. sensor view



physicalSensor

entityId


Table 241. sensor view (continued)



physicalSensor

Model


physicalSensor

RelativePosition


physicalSensor

physicalIndex


physicalSensor

Name


entityData

Description


Table 241. sensor view (continued)


sensorType Sensor type. Takes one of thefollowing values:

v other

v unknown

v voltsAC

v voltsDC

v amperes

v watts

v hertz

v celsius

v percentRH

v rpm

v cmm

v truthValue

v specialEnum

physicalSensor

sensorType

sensorScale Sensor scale. Takes one of thefollowing values:

v unknown

v yocto

v zepto

v atto

v femto

v pico

v nano

v micro

v milli

v Units

v kilo

v mega

v giga

v tera

v exa

v peta

v zetta

v yotta

physicalSensor

sensorScale

sensorStatus Sensor status. Takes one of thefollowing values:

v ok

v unavailable

v nonoperational

v unknown

physicalSensor

sensorStatus

sensorValue The value for the sensor. physicalSensor

sensorValue

Related reference:


“entityData” on page 136The entityData table stores data on entities. This table belongs to the categoryentities.“physicalSensor” on page 238The physicalSensor table represents sensor entities.

slotThe slot view joins data from a number of tables and is equivalent to the slottable that existed in Network Manager version 3.9 and earlier , thereby ensuringbackward compatibility.

The following table describes the slot view.

Table 242. slot view



physicalSlot

entityId


physicalSlot

Model


physicalSlot

RelativePosition


physicalSlot

PhysicalIndex


physicalSlot

Name


Table 242. slot view (continued)



entityData

Description

powerRedundancyMode Takes one of the followingvalues:

v unknown

v notSupported

v redundant

v combined

physicalSlot

SerialNumber

Related reference:“entityData” on page 136The entityData table stores data on entities. This table belongs to the categoryentities.“physicalSlot” on page 241The physicalSlot table represents slot entities.

sourceEmsThe sourceEms view joins data a number of tables. This view provides data ondevices discovered by an EMS collector and provides a mapping between thedevice and the EMS or EMSs that manage the device.

The following table describes the sourceEms view.

Table 243. sourceEms view



discoverySource

entityId

entityName Name of the entity. discoverySource

entityName

source Source of the data. This fieldtakes one of the followingvalues:

v Unknown

v Other

v TopologyEditor

v PresetLayer

v Agent

v Collector

discoverySource

source


Table 243. sourceEms view (continued)


discoveryProtocol Protocol of the data providedby this discovery source. Thisfield takes one of thefollowing values:

v Unknown

v Other

v Manual

v FlatFile

v SNMP

v Telnet

v XML-RPC

v VSphere

v OtherJavaAPI

v TL1

v CORBA

discoverySource

discoveryProtocol

nativeId Identifier used by thediscovery source to identify agiven device.

discoverySource

nativeId

nativeIdString String used by the discoverysource to identify a givendevice.

discoverySource

nativeIdString

emsEntityId Automatically-incrementedfield that provides a uniquevalue for each entity across alldomains.

entityNameCache

entityId

emsEntityName Name of the entity. entityNameCache

entityName

emsName Name of the EMS. emsSystem

emsName

domainMgrId Automatically-incrementedfield that is unique for eachdomain.

domainMgr

domainMgrId

domainName Name of the domain. domainMgr

domainName

Common Data Model viewsThe Common Data Model (CDM) is an information model that provides consistentdefinitions for managed resources, business systems and processes, and other data,and the relationships between those elements. CDM is based on the unifiedmodeling language (UML).

The IBM Common Data Model (CDM) overlay schema enables Network Managerto expose a subset of its data in a CDM-like relational representationcorresponding to aspects of the CDM Computer System, Networking, Operating


System, and Physical sub-models. The CDM schema complements the NCIMtopology database by providing tables to allow the storage of extra CDMattributes.

This section describes the CDM views exposed by Network Manager. The CDMviews have been defined using existing NCIM database tables and attributes.

CDM views

The CDM views are described below. For each CDM view the corresponding rowlists the tables and views mapped to by the CDM view.

Table 244.

CDM view Tables and views mapped to by this CDM view

CDMCARD This view maps to the following tables and views:

v CDMMODLEOBJECT view

v mappings table

v module view

v x_cdmCard table

CDMCHASSIS This view maps to the following tables and views:

v CDMMODELOBJECT view

v chassis view

v deviceFunction table

v x_cdmChassis table

CDMCOMPUTERSYSTEM

This view maps to the following tables and views:


v chassis view

v deviceFunction table

v virtualMachine table

v x_cdmComputerSystem table

CDMFAN This view maps to the following tables and views:


v fan view

v mappings table

v x_cdmFan table

CDMIPV4ADDRESS This view maps to the following tables and views:


v ipEndPoint table

CDMIPV4NETWORK This view maps to the following tables and views:


v subnet table

CDMIPV6ADDRESS This view maps to the following tables and views:


v ipEndPoint table

CDMIPV6NETWORK This view maps to the following tables and views:


v subnet table


Table 244. (continued)

CDM view Tables and views mapped to by this CDM view

CDMMODELOBJECT Provides generally applicable data to the other CDM views.


v entityData

v domainMembers

v domainMgr

CDMNETWORKINTERFACE


v CDMModelObject view

v enumerations table

v interface view

v x_cdmNetworkInterface table

CDMOPERATINGSYSTEM


v CDMModelObject view

v chassis table

v x_cdmOperatingSystem table

CDMOTHERPHYSICALPACKAGE



v chassis view

v x_cdmOperatingSystem table

CDMPHYSICALCONNECTOR



v interface view

v mappings table

v x_cdmPhysicalConnector table

CDMPOWERSUPPLY



v mappings table

v psu view

v x_cdmPowerSupply table

CDMSENSORThis view maps to the following tables and views:


v mappings table

v sensor view

v x_cdmSensor table

CDMSLOT This view maps to the following tables and views:


v mappings table

v sensor view

v x_cdmSensor table

CDMSNMPSYSTEMGROUP



v chassis view

Related information:


IBM Tivoli Common Data Model: Guide to Best PracticesThe Common Data Model (CDM) is an information model that provides consistentdefinitions for managed resources, business systems and processes, and other data,and the relationships between those elements. CDM is based on the unifiedmodeling language (UML). This IBM Redpaper presents a set of example templatesand scenarios that help you learn and apply the basics of the Common DataModel.


http://www.redbooks.ibm.com/abstracts/redp4389.html?Open

Appendix. Network Manager glossary

Use this information to understand terminology relevant to the Network Managerproduct.

The following list provides explanations for Network Manager terminology.

AOC filesFiles used by the Active Object Class manager, ncp_class to classifynetwork devices following a discovery. Device classification is defined inAOC files by using a set of filters on the object ID and other device MIBparameters.

active object class (AOC)An element in the predefined hierarchical topology of network devicesused by the Active Object Class manager, ncp_class, to classify discovereddevices following a discovery.

agent See, discovery agent.

bookmarkSee, network view bookmark.

class hierarchyPredefined hierarchical topology of network devices used by the ActiveObject Class manager, ncp_class, to classify discovered devices following adiscovery.

configuration filesEach Network Manager process has one or more configuration files used tocontrol process behaviour by setting values in the process databases.Configuration files can also be made domain-specific.

discovery agentPiece of code that runs during a discovery and retrieves detailedinformation from discovered devices.

Discovery Configuration GUIGUI used to configure discovery parameters.

Discovery engine (ncp_disco)Network Manager process that performs network discovery.

discovery phaseA network discovery is divided into four phases: Interrogating devices,Resolving addresses, Downloading connections, and Correlatingconnectivity.

discovery seedOne or more devices from which the discovery starts.

discovery scopeThe boundaries of a discovery, expressed as one or more subnets andnetmasks.

Discovery Status GUIGUI used to launch and monitor a running discovery.

discovery stitcherPiece of code used during the discovery process. There are various


discovery stitchers, and they can be grouped into two types: data collectionstitchers, which transfer data between databases during the data collectionphases of a discovery, and data processing stitchers, which build thenetwork topology during the data processing phase.

dNCIM databaseThe dNCIM is a relational database embedded into the Discovery engine,ncp_disco, and it stores the containment model that is derived from thefullTopology database (and created by stitchers). This is the version of thetopology that is sent to the Topology manager, ncp_model. The dNCIMdatabase performs the same function as the scratchTopology database didin previous versions of Network Manager.

domainSee, network domain.

entity A topology database concept. All devices and device componentsdiscovered by Network Manager are entities. Also device collections suchas VPNs and VLANs, as well as pieces of topology that form a complexconnection, are entities.

event enrichmentThe process of adding topology information to the event.

Event Gateway (ncp_g_event)Network Manager process that performs event enrichment.

Event Gateway stitcherStitchers that perform topology lookup as part of the event enrichmentprocess.

failoverIn your Network Manager environment, a failover architecture can be usedto configure your system for high availability, minimizing the impact ofcomputer or network failure.

Failover plug-inReceives Network Manager health check events from the Event Gatewayand passes these events to the Virtual Domain process, which decideswhether or not to initiate failover based on the event.

Fault Finding ViewComposite GUI view consisting of an Active Event List (AEL) portletabove and a Network Hop View portlet below. Use the Fault Finding Viewto monitor network events.

full discoveryA discovery run with a large scope, intended to discover all of the networkdevices that you want to manage. Full discoveries are usually just calleddiscoveries, unless they are being contrasted with partial discoveries. Seealso, partial discovery.

message brokerComponent that manages communication between Network Managerprocesses. The message broker used byNetwork Manager is called ReallySmall Message Broker. To ensure correct operation of Network Manager,Really Small Message Broker must be running at all times.

NCIM databaseRelational database that stores topology data, as well as administrativedata such as data associated with poll policies and definitions, andperformance data from devices.


ncp_discoSee, Discovery engine.

ncp_g_eventSee, Event Gateway.

ncp_modelSee, Topology manager.

ncp_pollerSee, Polling engine.

network domainA collection of network entities to be discovered and managed. A singleNetwork Manager installation can manage multiple network domains.

Network Health ViewComposite GUI view consisting of a Network Views portlet above and anActive Event List (AEL) portlet below. Use the Network Health View todisplay events on network devices.

Network Hop ViewNetwork visualization GUI. Use the Network Hop View to search thenetwork for a specific device and display a specified network device. Youcan also use the Network Hop View as a starting point for networktroubleshooting. Formerly known as the Hop View.

Network Polling GUIAdministrator GUI. Enables definition of poll policies and poll definitions.

Network ViewsNetwork visualization GUI that shows hierarchically organized views of adiscovered network. Use the Network Views to view the results of adiscovery and to troubleshoot network problems.

network view bookmarkNetwork view bookmarks group together just those network views thatyou or your team need to monitor. Create new bookmarks or changeexisting bookmarks to help network operators visualize just those devicesthat they need to monitor.

OQL databasesNetwork Manager processes store configuration, management andoperational information in OQL databases.

OQL languageVersion of the Structured Query Language (SQL) that has been designedfor use in Network Manager. Network Manager processes create andinteract with their databases using OQL.

partial discoveryA subsequent rediscovery of a section of the previously discoverednetwork. The section of the network is usually defined using a discoveryscope consisting of either an address range, a single device, or a group ofdevices. A partial discovery relies on the results of the last full discovery,and can only be run if the Discovery engine, ncp_disco, has not beenstopped since the last full discovery. See also, full discovery.

Path ViewsNetwork visualization GUI that displays devices and links that make up a

Appendix. Network Manager glossary 291

network path between two selected devices. Create new path views orchange existing path views to help network operators visualize networkpaths.

performance dataPerformance data can be gathered using performance reports. Thesereports allow you to view any historical performance data that has beencollected by the monitoring system for diagnostic purposes.

Polling engine (ncp_poller)Network Manager process that polls target devices and interfaces. ThePolling engine also collects performance data from polled devices.

poll definitionDefines how to poll a network device or interface and further filter thetarget devices or interfaces.

poll policyDefines which devices to poll. Also defines other attributes of a poll suchas poll frequency.

Probe for Tivoli Netcool/OMNIbus (nco_p_ncpmonitor)Acquires and processes the events that are generated by Network Managerpolls and processes, and forwards these events to the ObjectServer.

RCA plug-inBased on data in the event and based on the discovered topology, attemptsto identify events that are caused by or cause other events using rulescoded in RCA stitchers.

RCA stitcherStitchers that process a trigger event as it passes through the RCA plug-in.

root-cause analysis (RCA)The process of determining the root cause of one or more device alerts.

SNMP MIB BrowserGUI that retrieves MIB variable information from network devices tosupport diagnosis of network problems.

SNMP MIB GrapherGUI that displays a real-time graph of MIB variables for a device and ussethe graph for fault analysis and resolution of network problems.

stitcherCode used in the following processes: discovery, event enrichment, androot-cause analysis. See also, discovery stitcher, Event Gateway stitcher,and RCA stitcher.

Structure BrowserGUI that enables you to investigate the health of device components inorder to isolate faults within a network device.

Topology Manager (ncp_model)Stores the topology data following a discovery and sends the topologydata to the NCIM topology database where it can be queried using SQL.

WebToolsSpecialized data retrieval tools that retrieve data from network devices andcan be launched from the network visualization GUIs, Network Views andNetwork Hop View, or by specifying a URL in a web browser.


Notices

This information applies to the PDF documentation set for IBM Tivoli NetworkManager IP Edition.

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document inother countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user's responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not grant youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785U.S.A.

For license inquiries regarding double-byte character set (DBCS) information,contact the IBM Intellectual Property Department in your country or sendinquiries, in writing, to:

Intellectual Property LicensingLegal and Intellectual Property LawIBM Japan, Ltd.19-21, Nihonbashi-Hakozakicho, Chuo-kuTokyo 103-8510, Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law: INTERNATIONALBUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS"WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFNON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULARPURPOSE. Some states do not allow disclaimer of express or implied warranties incertain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.

Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of those Web


sites. The materials at those Web sites are not part of the materials for this IBMproduct and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way itbelieves appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM Corporation958/NH04IBM Centre, St Leonards601 Pacific HwySt Leonards, NSW, 2069AustraliaIBM Corporation896471/H128B76 Upper GroundLondonSE1 9PZUnited KingdomIBM CorporationJBF1/SOM1 294Route 100Somers, NY, 10589-0100United States of America

Such information may be available, subject to appropriate terms and conditions,including in some cases, payment of a fee.

The licensed program described in this document and all licensed materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement or any equivalent agreementbetween us.

Any performance data contained herein was determined in a controlledenvironment. Therefore, the results obtained in other operating environments mayvary significantly. Some measurements may have been made on development-levelsystems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurements may have beenestimated through extrapolation. Actual results may vary. Users of this documentshould verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include the


names of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, whichillustrate programming techniques on various operating platforms. You may copy,modify, and distribute these sample programs in any form without payment toIBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operatingplatform for which the sample programs are written. These examples have notbeen thoroughly tested under all conditions. IBM, therefore, cannot guarantee orimply reliability, serviceability, or function of these programs.

TrademarksThe terms in Table 245 are trademarks of International Business MachinesCorporation in the United States, other countries, or both:

Table 245. IBM trademarks

AIX® Informix® RDN

BNT iSeries solidDB®

ClearQuest® Lotus® System p

Cognos® Netcool® System z®

DB2® NetView® Tivoli®

DB2 UniversalDatabase

Notes® WebSphere

developerWorks® OMEGAMON® z/OS®

DS8000 PowerPC z/VM®

EnterpriseStorage Server®

PowerVM® zSeries

IBM PR/SM™

Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo,Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks orregistered trademarks of Intel Corporation or its subsidiaries in the United Statesand other countries.

Java and all Java-based trademarks and logos are trademarks orregistered trademarks of Oracle and/or its affiliates.

Notices 295

Linux is a registered trademark of Linus Torvalds in the United States, othercountries, or both.

UNIX is a registered trademark of The Open Group in the United States and othercountries.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks ofMicrosoft Corporation in the United States, other countries, or both.

Privacy policy considerations

IBM Software products, including software as a service solutions, ("SoftwareOfferings") may use cookies or other technologies to collect product usageinformation, to help improve the end user experience, to tailor interactions withthe end user or for other purposes. In many cases no personally identifiableinformation is collected by the Software Offerings. Some of our Software Offeringscan help enable you to collect personally identifiable information. If this SoftwareOffering uses cookies to collect personally identifiable information, specificinformation about this offering's use of cookies is set forth below.

This Software Offering may collect IP addresses, user names and passwords for thepurpose of performing network discovery. Failure to enable the collection of thisinformation would likely eliminate important functionality provided by thisSoftware Offering. You as customer should seek your own legal advice about anylaws applicable to such data collection, including any requirements for notice andconsent.

For more information about the use of various technologies, including cookies, forthese purposes, See IBM's Privacy Policy at http://www.ibm.com/privacy andIBM's Online Privacy Statement at http://www.ibm.com/privacy/details thesection entitled "Cookies, Web Beacons and Other Technologies" and the "IBMSoftware Products and Software-as-a-Service Privacy Statement" athttp://www.ibm.com/software/info/product-privacy.


http://www.ibm.com/privacy

http://www.ibm.com/privacy/details

http://www.ibm.com/software/info/product-privacy

Index

Aaccessibility xiaggregatedLink table 124aggregationDomain table 124aggregationGroup table 158antennaFunction table 160atmEndPoint table 161

Bbackplane view 265BGP 92bgpAutonomousSystem table 161bgpCluster table 162bgpEndPoint table 162bgpNetwork table 165bgpRouteAttribute table 165bgpService table 167

CCDM 284chassis view 266CIDRinfo table 125classMembers table 126collections 93collects table 127Common Data Model 284computerSystem table 168connectActions table 127connectivity

queriesdevices and interfaces connected to

a named device 53devices and interfaces connections

between routers 55devices connected to a named

device 50types 49

connectivity datadescription 48representation 15

connects table 15, 48, 128connectSpeeds table 129containment 94

queriescomponents on a device 32components on a device and

component type 34devices with Cisco Three-Port

Gigabit Ethernet cards 37entities in all cards 39number of cards per device 35

containment dataaltering the containment model 17description 15usage 15VLANs

dependencies on other entities 17naming 16

containment data (continued)VLANs (continued)

trunking 16contains table 39, 130controlPlaneViewCollection table 175conventions, typeface xiiicore schema 89core views 149cpu table 175custom tags

enabling network visualization basedon 84

enabling polling based on 84

Ddata dictionary

tablesaggregatedLink 124aggregationDomain 124aggregationGroup 158domainMembers 133lagEndPoint 200

viewsbackplane 265chassis 266discoveryOverview 149entity 151fan 270interface 271interfaceDomain 152, 158interfaces 152mainNodeDetails 155module 274other 276psu 278sensor 279slot 282sourceEms 283

databaseschema

endpoints 95database tables

collects 17core 7entity

resource types 7product-specific 7

dependency table 131device collections 93

description 77queries

devices per subnet 78devices per VPN 79

deviceFunction 131discoveryAttributes table 175discoveryOverview view 149discoverySource table 132domainMembers table 133domainMgr table 133

domainsdescription 6queries

description 24differences between NCIM and

MODEL queries 24main nodes 25number of entities 26

domainSummary table 176

Eeducation

see Tivoli technical training xieirFunction table 176emsSystem table 178enabling

network visualization based oncustom tags 84

polling based on custom tags 84enbFunction table 179endpoints 95entity view 151entityActions table 135entityClass 135entityData table 46, 136

entityType 34mainNodeEntityId 23

entityDetails 138entityNameCache table 139entityType table 140enumerations


device hardwaremanufacturers 80

entity types 82enumerations table 141environment variables, notation xiiieUtranCell table 180eUtranSector table 182

Ffan view 270files

database schema 18for NCIM cache 18

frameRelayEndPoint table 183

GgenericCollection table 183genericRange table 184geographicLocation table 184geographicRegion table 185globalVlan 186glossary 289


HHop View 86hosted serves

description 76hosted services 18, 143

querieschassis devices for OSPF 76

hostedServices table 143hsrpGroup table 186hssFunction table 187

IigmpEndPoint table 188igmpGroup table 190igmpService table 190interface table 42interface view 271interfaceDomain view 152, 158interfaces

IP addresses 46queries

attribute values 42main-node devices 41

interfaces view 152IP endpoints 97ipConnection table 191ipEndPoint table 24, 191ipMRouteDownstream table 193ipMRouteEndPoint table 194ipMRouteGroup table 195ipMRouteMdt table 196ipMRouteService table 196ipMRouteSource table 197ipMRouteUpstream table 197ipPath table 199itnmService table 199

LlagEndPoint table 200lingerTime table 201localVlan table 201LTE

queriesentity types 56

lteInterface table 202ltePool table 204

Mmain nodes

IP addresses 30queries

devices with class name and objectID 28

mainNodeDetails view 155managedStatus table 205manager table 144manuals viiimappings


device hardwaremanufacturers 80

mappings (continued)queries (continued)

entity types 82mappings table 144mmeFunction table 206module view 274MPLS

TE tunnelslisting all, query for 59listing dependencies, query for 59showing configuration, query

for 60showing performance data, query

for 61showing routers, query for 60

MPLS VLANs 111mplsLSP table 210mplsTEService table 207mplsTETunnel table 208mplsTETunnelEndPoint table 209mplsTETunnelResource table 210

NNCIM

core schema 89core tables

categories of topology data 123database schema 18database tables

core 7product-specific 7

description 1extending 3

example interface record 83Hop View 86Network Views 86

logging in 21querying domains 3, 24schema

BGP 92collections 93containment 94endpoints 95IP endpoints 97MPLS VLANs 111OSPF 112services 113VLANs 120

storing data 3structure 3supported technologies 15tables 123

aggregatedLink 124aggregationDomain 124aggregationGroup 158antennaFunction 160atmEndPoint 161bgpAutonomousSystem 161bgpCluster 162bgpEndPoint 162bgpNetwork 165bgpRouteAttribute 165bgpService 167CIDRinfo 125classMembers 126collects 127

NCIM (continued)tables (continued)

computerSystem 168connectActions 127connects 128connectSpeeds 129contains 130controlPlaneViewCollection 175cpu 175dependency 131deviceFunction 131discoveryAttributes 175discoverySource 132domainMembers 133domainMgr 133domainSummary 176eirFunction 176emsSystem 178enbFunction 179entity attribute tables 158, 265entityActions 135entityClass 135entityData 136entityDetails 138entityNameCache 139entityType 140enumerations 141eUtranCell 180eUtranSector 182frameRelayEndPoint 183genericCollection 183genericRange 184geographicLocation 184geographicRegion 185globalVlan 186hostedService 143hsrpGroup 186hssFunction 187igmpEndPoint 188igmpGroup 190igmpService 190ipConnection 191ipEndPoint 191ipMRouteDownstream 193ipMRouteEndPoint 194ipMRouteGroup 195ipMRouteMdt 196ipMRouteService 196ipMRouteSource 197ipMRouteUpstream 197ipPath 199itnmService 199lagEndPoint 200lingerTime 201localVlan 201lteInterface 202ltePool 204managedStatus 205manager 144mappings 144mmeFunction 206mplsLSP 210mplsTEService 207mplsTETunnel 208mplsTETunnelEndPoint 209mplsTETunnelResource 210netcoolAsmsRunning 211



networkInterface 211networkPipe 145networkPipe hierarchy

modeling 50networkServiceEntityEndPoint 215networkVpn 215notes 146operatingSystem 215ospfArea 219ospfEndPoint 219ospfNetworkLSA 220ospfRoutingDomain 220ospfService 221pcrfFunction 221pgwFunction 223physicalBackplane 224physicalCard 225physicalChassis 228physicalConnector 232physicalFan 233physicalOther 235physicalPowerSupply 237physicalSensor 238physicalSlot 241pimEndPoint 242pimNetwork 243pimService 243pipeComposition 146pipeComposition hierarchy

modeling 50plmn 244portEndPoint 245protocolEndPoint 147ranBaseStation 245ranBaseStationController 246ranCircuitSwitchedCore 246ranGSMCell 248ranLocationArea 249ranMediaGateway 249ranMobileSwitchingCentre 250ranMSS 250ranMultiplexer 211ranNodeB 251ranNodeBLocalCell 251ranPacketControlUnit 252ranPacketSwitchedCore 252ranRadioCore 253ranRadioNetworkController 254ranRoutingArea 254ranSector 255ranSGSN 247, 255ranTransceiver 256ranUtranCell 256rtExportList 257rtImportList 257sgwFunction 258snmpSystem 259subnet 260topologyLinks 148trackingArea 260transmissionTp 261userPlaneViewCollection 262vlanCollection 262vlanTrunkEndPoint 262vpnRouteForwarding 263


vpwsEndPoint 264vtpDomain 264

usage considerations 1views

backplane 265chassis 266discoveryOverview 149entity 151fan 270interface 271interfaceDomain 152, 158interfaces 152mainNodeDetails 155module 274other 276psu 278sensor 279slot 282sourceEms 283

NCIM cachefiles 18

netcoolAsmsRunning table 211network entities

collection data 17connectivity data 15containment data 15types 7

Network Manager glossary 289Network Views 86network visualization

enabling based on custom tags 84networkInterface 211networkPipe table 145networkServiceEntityEndPoint table 215networkVpn table 215notes table 146

Oonline publications viiioperatingSystem table 215ordering publications viiiOSPF 112OSPF areas

modelling 15ospfArea table 219ospfEndPoint table 219ospfNetworkLSA table 220ospfRoutingDomain table 220ospfService table 221other view 276

PpcrfFunction table 221pgwFunction table 223physicalBackplane table 224physicalCard table 225physicalChassis table 228physicalConnector table 232physicalFan 233physicalOther 235physicalPowerSupply table 237physicalSensor table 238

physicalSlot table 241PIM

queriesadjacencies for device 77enabled routers 77show adjacencies 77

pimEndPoint table 242pimNetwork table 243pimService table 243pipeComposition table 146plmn table 244polling

enabling based on custom tags 84portEndPoint table 245protocalEndPoint table 147protocolEndPoint table 24protocols

association with devices 14psu view 278publications viii

Qqueries

connectivityconnections between routers 55devices and interfaces connected to

a named device 53devices connected to a named

device 50containment

components on a device 32components on a device and

component type 34devices with Cisco Three-Port

Gigabit Ethernet cards 37entities in all cards 39number of cards per device 35

device collectionsdevices per subnet 78devices per VPN 79

domainsdescription 24differences between NCIM and

MODEL queries 24main nodes 25number of entities 26

enumerationsdevice hardware

manufacturers 80entity types 82

interfacesattribute values 42IP addresses 46main-node devices 41

LTEentity types 56

main nodesdevices with class name and object

ID 28IP addresses 30

mappingsdevice hardware

manufacturers 80entity types 82

PIMadjacencies for device 77

Index 299

queries (continued)PIM (continued)

enabled routers 77show adjacencies 77

RANconnectivity 64containment 72dependencies 74entity types 62

TE tunnelslist all 59show configuration 60show dependencies 59show performance data 61show routers 60

RRAN

queriesconnectivity 64containment 72dependencies 74entity types 62

ranBaseStation table 245ranBaseStationController table 246ranCircuitSwitchedCore table 246ranGGSN table 247ranGSMCell table 248ranLocationArea table 249ranMediaGateway table 249ranMobileSwitchingCentre table 250ranMSS table 250ranMultiplexer table 211ranNodeB table 251ranNodeBLocalCell table 251ranPacketControlUnit table 252ranPacketSwitchedCore table 252ranRadioCore table 253ranRadioNetworkController table 254ranRoutingArea table 254ranSector table 255ranSGSN table 255ranTransceiver table 256ranUtranCell table 256rtExportList table 257rtImportList table 257

SSAE plug-ins 199schema

BGP 92collections 93containment 94core tables

categories of topology data 123IP endpoints 97MPLS VLANs 111OSPF 112services 113tables 123

antennaFunction 160atmEndPoint 161bgpAutonomousSystem 161bgpCluster 162

schema (continued)tables (continued)

bgpEndPoint 162bgpNetwork 165bgpRouteAttribute 165bgpService 167CIDRinfo 125classMembers 126collects 127computerSystem 168connectActions 127connects 128connectSpeeds 129contains 130controlPlaneViewCollection 175cpu 175dependency 131deviceFunction 131discoveryAttributes 175discoverySource 132domainMgr 133domainSummary 176eirFunction 176emsSystem 178enbFunction 179entity attribute tables 158, 265entityActions 135entityClass 135entityData 136entityDetails 138entityNameCache 139entityType 140enumerations 141eUtranCell 180eUtranSector 182frameRelayEndPoint 183genericCollection 183genericRange 184geographicLocation 184geographicRegion 185globalVlan 186hostedService 143hsrpGroup 186hssFunction 187igmpEndPoint 188igmpGroup 190igmpService 190ipConnection 191ipEndPoint 191ipMRouteDownstream 193ipMRouteEndPoint 194ipMRouteGroup 195ipMRouteMdt 196ipMRouteService 196ipMRouteSource 197ipMRouteUpstream 197ipPath 199itnmService 199lingerTime 201localVlan 201lteInterface 202ltePool 204managedStatus 205manager 144mappings 144mmeFunction 206mplsLSP 210


mplsTEService 207mplsTETunnel 208mplsTETunnelEndPoint 209mplsTETunnelResource 210netcoolAsmsRunning 211networkInterface 211networkPipe 145networkPipe hierarchy

modeling 50networkServiceEntityEndPoint 215networkVpn 215notes 146operatingSystem 215ospfArea 219ospfEndPoint 219ospfNetworkLSA 220ospfRoutingDomain 220ospfService 221pcrfFunction 221pgwFunction 223physicalBackplane 224physicalCard 225physicalChassis 228physicalConnector 232physicalFan 233physicalOther 235physicalPowerSupply 237physicalSensor 238physicalSlot 241pimEndPoint 242pimNetwork 243pimService 243pipeComposition 146pipeComposition hierarchy

modeling 50plmn 244portEndPoint 245protocolEndPoint 147ranBaseStation 245ranBaseStationController 246ranCircuitSwitchedCore 246ranGGSN 247ranGSMCell 248ranLocationArea 249ranMediaGateway 249ranMobileSwitchingCentre 250ranMSS 250ranMultiplexer 211ranNodeB 251ranNodeBLocalCell 251ranPacketControlUnit 252ranPacketSwitchedCore 252ranRadioCore 253ranRadioNetworkController 254ranRoutingArea 254ranSector 255ranSGSN 255ranTransceiver 256ranUtranCell 256rtExportList 257rtImportList 257sgwFunction 258snmpSystem 259subnet 260topologyLinks 148



trackingArea 260transmissionTp 261userPlaneViewCollection 262vlanCollection 262vlanTrunkEndPoint 262vpnRouteForwarding 263vpwsEndPoint 264vtpDomain 264

VLANs 120sensor view 279service xiiservice management connect xiiService-Affected Events 199services 113sgwFunction table 258slot view 282SMC xiisnmpSystem table 259sourceEms view 283sql

views 149SQL

aliasing 22driving tables 22formatting 21table joins 22

subnet table 260support xiisupport information xii

TTivoli software information center viiiTivoli technical training xitopology data 6topology database

architecture 3properties 5tasks 3

topologyLinks table 148trackingArea table 260training, Tivoli technical xitransmissionTp table 261typeface conventions xiii

UuserPlaneViewCollection table 262

Vvariables, notation for xiiiviews

core 149visualization

enabling based on custom tags 84vlanCollection table 262VLANs 120

dependencies on other entities 17naming 16trunking 16

vlanTrunkEndPoint table 262vpnRouteForwarding table 263vpwsEndPoint table 264

vtpDomain table 264

Index 301

��

Printed in the Republic of Ireland

topology database reference · v ibm tivoli network manager ip edition network troubleshooting...

Documents