34 About Models in Network Integrity

This chapter explains the different models supported by Oracle Communications Network Integrity.

Overview

Network Integrity supports the following models:

• About the Network Integrity Model

• About the Oracle Communications Information Model for Network Integrity

• About the Optical Model for Network Integrity

Developers are expected to be familiar with the Oracle Communications Information Model, as explained in Oracle Communications Information Model Reference.

Cartridge developers are expected to have detailed understanding of scan run entities.

Report writers using Oracle Business Intelligence Publisher (BI Publisher) are expected to have detailed understanding of scan run entities and familiarity of other entities depending on the report types.

Integrators using the Web Services are expected to have detailed understanding of any entity specific to the integration work taking place.

About the Network Integrity Model

The Network Integrity model defines the entities and relationships used to represent all persisted data within Network Integrity. This includes application-specific entities like scans, scan runs, and discrepancies and the more general entities taken directly from the Information Model.

This section describes the Network Integrity entities, and any relationships to the Information Model. Information Model entities are described in Oracle Communications Information Model Reference. See "About the Oracle Communications Information Model for Network Integrity" for information about how the Information Model is applied to Network Integrity.

This section describes entity groups and entities pertaining to the Unified Modeling Language (UML), and includes references to more detailed entity descriptions.

About Scan Entities

A scan is a set of configurations that is used to perform a Network Integrity operation. Typically, a scan includes a scan action and scan action parameters, network addresses (scope), and schedules.

Figure 34-1 shows how a scan is modeled with DisConfig and related entities.

Figure 34-1 DisConfig and Related Entities

For more detail, refer to the individual scan entity descriptions:

• DisAddress

• DisAssimilationAddress

• DisBlackoutSchedule

• DisConfig

• DisInventoryAddress

• DisInventoryConfig

• DisParameterGroup

• DisParameterGroupSpecification

• DisPlugin

• DisSchedule

• DisScope

About Scan Run Entities

A user can directly initiate a scan run for a particular scan, or scan scheduling can initiate a scan run. Figure 34-2 shows how a scan is modeled with DisScanRun and related entities.

Figure 34-2 DisScanRun and Related Entities

For more detail, refer to the individual scan run entity descriptions:

• DisDiscrepancy

• DisDiscrepancyCounts

• DisResultGroup

• DisRootEntityRef

• DisScanAddress

• DisScanRun

About Cartridge Entities

Cartridges extend Network Integrity by introducing new actions and address handlers. Cartridge deployment status is modeled by the standalone DisCartridgeStatus entity. Figure 34-3 shows how an action or a handler is modeled, respectively, by a DisPlugin or DisAddressHandler entity and related entities.

Figure 34-3 DisPlugin DisAddressHandler and Related Entities

For more detail, refer to the individual cartridge entity descriptions:

• DisAddressHandlerHelper

• DisAssimilationPlugin

• DisCartridgeStatus

• DisDiscoveryPlugin

• DisDiscrepancyDetectionPlugin

• DisDiscrepancyResolutionPlugin

• DisHelper

• DisHelperReference

• DisInventoryImportPlugin

• DisNetworkDiscoveryPlugin

• DisReconciliationPlugin

About Tag Entities

Tags are used to organize scans. Figure 34-4 shows a tag that is modeled by the DisTag entity and related entities.

Figure 34-4 DisTag and Related Entities

For more detail, refer to the individual tag entity descriptions:

• DisTag

• DisTaggable

Miscellaneous Entities

Refer to the individual entities for detail on the remaining entities:

• DisConfigurationData

• DisRegionalLinks

Modeling Considerations for Scan Results

Some modeling considerations apply to scan run entities. For example, Network Integrity partitions scan results by scan run, scan address, result group, and root entity. This section is about partitioning and its affect on modeling scan results for actions.

A scan run contains one or more scan addresses. Scan runs and scan addresses are managed by Network Integrity and are not created by actions. An action is invoked separately for each scan address and might create one or more result groups. The action might associate one or more root entities with each result group. A result group, with its child entities, is an independent (meaning that there are no direct references to entities in another result group) subset of results.

Note:

If you break the rules, the actions does not work properly and might cause general application problems. If you do not follow the guidelines, you might need additional code in your actions to compensate.

Rule: Create Results Only Under Your Own Scan Run/Scan Address

If you use the addToResult SDK method, the results are created under the proper scan run/scan address for the current invocation of the action.

Rule: Do Not Reference Entities in Another Result Group

Because a result group, with its child entities, is an independent subset of results, you cannot have an explicit entity reference between an entity in one result group and an entity in another.

You might want to reference entities in different result groups. For example, devices might be modeled one per result group and you want to model a service that references multiple devices. In these cases, there are alternative modeling constructs that are used in place of direct references. You can introduce a shadow entity in the result group to represent the device (create the entity with shadow attribute True). See "About the Oracle Communications Information Model for Network Integrity" for more information. Or you can use an extended attribute to reference the device by name.

Guideline: Use the Same Result Group/Root Entity Partitioning for Network and Inventory Results

Network and Inventory results are produced by independent scans. Typically, the scan and scan address partitioning is different between network and discovery. For example, one scan address per device for a Network scan, but multiple devices for a single scan address for an Inventory scan.

In the Network example, there are many scan addresses with one result group each. In the Inventory example, there is a single scan address with many result groups.

For default discrepancy detection to work, the partitioning of result groups needs to match between Network and Inventory. In the device example, the discovery action models a particular Network device as one or more root entities within a particular result group, which is defined by name and category. The Inventory action should model the corresponding device as equivalent root entities within an equivalent result group (same name, same category).

Note:

If you partition result groups differently between Network and Inventory, you must introduce additional custom discrepancy detection code to compensate.

About the Oracle Communications Information Model for Network Integrity

This section explains the Information Model entities, patterns, and application-specific capabilities available with Network Integrity. The complete Information Model is documented in Oracle Communications Information Model Reference.

Information Model Entities

Network Integrity supports a large subset of the entities defined by the Information Model.

Physical Resource Entities

Network Integrity supports the following physical resource entities:

• Equipment

• EquipmentAssignment

• EquipmentAssignmentToPipeTerminationPoint

• EquipmentAssignmentToService

• EquipmentCharacteristic

• EquipmentConsumer

• EquipmentEquipmentRel

• EquipmentHolder

• EquipmentHolderAssignment

• EquipmentHolderAssignmentToService

• EquipmentHolderCharacteristic

• EquipmentHolderConsumer

• EquipmentHolderEquipmentRel

• EquipmentHolderSpecification

• EquipmentRole

• EquipmentSpecification

• PhysicalConnector

• PhysicalConnectorAssignment

• PhysicalConnectorAssignmentToPipeTerminationPoint

• PhysicalConnectorAssignmentToService

• PhysicalConnectorCharacteristic

• PhysicalConnectorConsumer

• PhysicalConnectorRole

• PhysicalConnectorSpecification

• PhysicalDevice

• PhysicalDeviceAssignment

• PhysicalDeviceAssignmentToGeographicSite

• PhysicalDeviceAssignmentToPipeTerminationPoint

• PhysicalDeviceAssignmentToService

• PhysicalDeviceCharacteristic

• PhysicalDeviceConsumer

• PhysicalDeviceEquipmentRel

• PhysicalDevicePhysicalDeviceRel

• PhysicalDeviceRole

• PhysicalDeviceSpecification

• PhysicalPort

• PhysicalPortAssignment

• PhysicalPortAssignmentToPipeTerminationPoint

• PhysicalPortAssignmentToService

• PhysicalPortCharacteristic

• PhysicalPortConsumer

• PhysicalPortRole

• PhysicalPortSpecification

Logical Resource Entities

Network Integrity supports the following logical resource entities:

• DeviceInterface

• DeviceInterfaceAssignment

• DeviceInterfaceAssignmentToGeographicSite

• DeviceInterfaceAssignmentToLogicalDevice

• DeviceInterfaceAssignmentToPipeTerminationPoint

• DeviceInterfaceAssignmentToService

• DeviceInterfaceCharacteristic

• DeviceInterfaceConfigurationItem

• DeviceInterfaceConfigurationItemCharacteristic

• DeviceInterfaceConsumer

• DeviceInterfaceRole

• DeviceInterfaceSpecification

• LDAccountAssignment

• LDAccountAssignmentToService

• LDAccountCharacteristic

• LDAccountConsumer

• LogicalDevice

• LogicalDeviceAccount

• LogicalDeviceAccountSpecification

• LogicalDeviceAssignment

• LogicalDeviceAssignmentToGeographicSite

• LogicalDeviceAssignmentToNetwork

• LogicalDeviceAssignmentToPipeTerminationPoint

• LogicalDeviceAssignmentToService

• LogicalDeviceCharacteristic

• LogicalDeviceConfigurationItem

• LogicalDeviceConfigurationItemCharacteristic

• LogicalDeviceConsumer

• LogicalDeviceLogicalDeviceRel

• LogicalDeviceRole

• LogicalDeviceSpecification

• MediaInterface

Custom Object Entities

Network Integrity supports the following custom object entities:

• CustomObject

• CustomObjectAssignment

• CustomObjectAssignmentToGeographicSite

• CustomObjectAssignmentToLogicalDevice

• CustomObjectAssignmentToNetwork

• CustomObjectAssignmentToPipeTerminationPoint

• CustomObjectAssignmentToService

• CustomObjectCharacteristic

• CustomObjectConsumer

• CustomObjectCustomObjectRel

• CustomObjectRole

• CustomObjectSpecification

Custom Network Address Entities

Network Integrity supports the following custom network address entities:

• CustNetAddrAssignment

• CustNetAddrAssignmentToGeographicSite

• CustNetAddrAssignmentToLogicalDevice

• CustNetAddrAssignmentToNetwork

• CustNetAddrAssignmentToPipeTerminationPoint

• CustNetAddrAssignmentToService

• CustNetAddrConsumer

• CustNetAddrSpecification

• CustomNetworkAddress

• CustomNetworkAddressCharacteristic

• CustomNetworkAddressCustomNetworkAddressRel

Place Entities

Network Integrity supports the following place entities:

• GeoAddressRangeAssignment

• GeoAddressRangeAssignmentToGeographicSite

• GeoAddressRangeConsumer

• GeographicAddress

• GeographicAddressAssignment

• GeographicAddressAssignmentToGeographicSite

• GeographicAddressConsumer

• GeographicAddressRange

• GeographicLocation

• GeographicLocationAssignment

• GeographicLocationAssignmentToGeographicSite

• GeographicLocationAssignmentToService

• GeographicLocationConsumer

• GeographicPlace

• GeographicSite

• GeographicSiteAssignment

• GeographicSiteAssignmentToGeographicSite

• GeographicSiteAssignmentToService

• GeographicSiteConsumer

• PlaceCharacteristic

• PlaceConfigurationItem

• PlaceConfigurationItemCharacteristic

• PlaceCustomNetworkAddressRel

• PlaceCustomObjectRel

• PlaceDeviceInterfaceRel

• PlaceConfigurationItem

• PlaceConfigurationItemCharacteristic

• PlaceCustomNetworkAddressRel

• PlaceCustomObjectRel

• PlaceDeviceInterfaceRel

• PlaceEquipmentRel

• PlaceInventoryGroupRel

• PlaceLogicalDeviceAccountRel

• PlaceLogicalDeviceRel

• PlaceNetworkNodeRel

• PlaceNetworkRel

• PlacePhysicalDeviceRel

• PlacePipeRel

• PlacePipeTerminationPointRel

• PlaceRel

• PlaceRole

• PlaceServiceRel

• PlaceSpecification

Network Entities

Network Integrity supports the following network entities:

• NetEdgeCustomObjectRel

• NetEdgePipeRel

• NetNodeCustomNetworkAddressRel

• NetNodeCustomObjectRel

• NetNodeDeviceInterfaceRel

• NetNodeEquipmentRel

• NetNodeLogicalDeviceRel

• NetNodeNetEdgeRel

• NetNodeNetworkRel

• NetNodePhysicalDeviceRel

• NetNodePhysicalPortRel

• Network

• NetworkAssignment

• NetworkAssignmentToPipeTerminationPoint

• NetworkAssignmentToService

• NetworkCharacteristic

• NetworkConfigurationItem

• NetworkConfigurationItemCharacteristic

• NetworkConsumer

• NetworkEdge

• NetworkEdgeCharacteristic

• NetworkEdgeRole

• NetworkEdgeSpecification

• NetworkNode

• NetworkNodeCharacteristic

• NetworkNodeRole

• NetworkNodeSpecification

• NetworkRole

• NetworkSpecification

Connectivity Entities

Network Integrity supports the following connectivity entities:

• Pipe

• PipeAssignment

• PipeAssignmentToPipe

• PipeAssignmentToService

• PipeCharacteristic

• PipeConfigurationItem

• PipeConfigurationItemCharacteristic

• PipeConsumer

• PipePipeTPRel

• PipeRel

• PipeRole

• PipeSpecification

• PipeTerminationPoint

• PipeTerminationPointCharacteristic

• PipeTerminationPointSpecification

• TrailPath

• TrailPipeRel

• TrailPipeRelPipeRel

• TrailPipeRelTrailPathRel

See "About the Optical Model for Network Integrity" for examples of connectivity entities. See "Optical Topological Link" for an example of a simple connectivity entity. See "Optical Circuit" for an example of a more complex connectivity entity.

Service Entities

Network Integrity supports the following service entities:

• Service

• ServiceAssignment

• ServiceAssignmentToGeographicSite

• ServiceAssignmentToService

• ServiceCharacteristic

• ServiceConfigurationItem

• ServiceConfigurationItemCharacteristic

• ServiceConsumer

• ServiceSpecification

Telephone Number Entities

Network Integrity supports the following telephone number entities:

• TNAssignment

• TNAssignmentToService

• TNCharacteristic

• TNConsumer

• TelephoneNumber

• TelephoneNumberSpecification

Information Model Patterns

The following patterns are supported within Network Integrity.

• Authorization Pattern*

• Characteristic Pattern

• Configuration Pattern*

• Consumer Pattern*

• Inventory Group Pattern*

• Involvement Pattern*

• Network Relationship Pattern

• Persistent Pattern

• Place Relationship Pattern

• Role Pattern

• Specification Pattern

• Trackable Pattern*

• Weak Reference Pattern

Note:

*There are differences in the patterns that are marked with an asterisk (*), which are described in following sections for those patterns.

In general, ignore the attributes in the Information Model patterns that are not used in Network Integrity. For example, Network Integrity does not support the Business Interaction pattern and so ignore attributes like action and businessInteraction.

Authorization Pattern

The attributes that are added with this pattern are available. However, they are not populated. Developers should not use the owner, partition, and permissions attributes.

Configuration Pattern

The topology of a configuration enabled entity has changed due to the unsupported Business Interaction.

The entity <Entity1> has a direct relationship to the <Entity1>ConfigurationItem child entities.

The Information Model distinguishes between an assignment (target of assignment relationship is <Entity2>AssignmentTo<Entity1>) and a reference (target of assignment relationship is <Entity2>). Network Integrity treats assignments and references the same way in the UI and in discrepancy detection. Generally, you would use a reference relationship rather than introduce the extra <Entity2>AssignmentTo<Entity1> entity.

Figure 34-5 illustrates the configuration item relationships within Network Integrity.

Figure 34-5 Configuration Item Relationship within Network Integrity

Consumer Pattern

The Information Model describes the following types of consumer relationship: Assignment, Reservation, and Condition. Network Integrity only supports Assignment.

Most consumer relationships involve configuration items. In these cases, the <Entity2>AssignmentTo<Entity1> relationship from Entity1 can be omitted. The relationship of interest is from the Entity1 configuration item to either the <Entity2>AssignmentTo<Entity1> entity or directly to <Entity2>.

Inventory Group Pattern

Network Integrity uses InventoryGroup as a general purpose container for organizing entities.

The Information Model describes the InventoryGroup to InventoryGroupRef relationship as unidirectional from InventoryGroupRef. Network Integrity uses a bidirectional relationship to enable direct navigation from group to group members.

Involvement Pattern

In general, the involvement pattern describes an intermediate entity used to relate two or more other entities. This pattern is used at various places in the Information Model, including entities used by Network Integrity.

The involvement pattern also describes the specific custom involvement entity, which provides a way to relate arbitrary entities using the weak reference pattern. Network Integrity does not support the custom involvement entity.

Trackable Pattern

The createdDate and lastModifiedDate attributes are populated as described by the Information Model documentation. The createdUser and lastModifiedUser attributes are not populated and should not be used.

Network Integrity Capabilities

Network Integrity augments Information Model entities and adds application-specific attributes through the DiscrepancyEnabled and Groupable capabilities.

These attributes are maintained internally by the application but are exposed in the Web service.

DiscrepancyEnabled Capability

The DiscrepancyEnabled capability is applied to entities eligible for discrepancy detection. It supports additional attributes needed for the discrepancy detection and resolution process.

Table 34-1 describes the attributes and types required for discrepancy detection.

Table 34-1 Discrepancy Detection Attributes and Types

Attribute	Type	Description
alias	String	An optional, alternative name for an entity. This is one way to deal with naming differences between network and inventory.
shadow	Boolean	A flag indicating if this entity instance is a shadow entity. Defaults to false. A shadow entity has special meaning to discrepancy detection. Only the relationships to a shadow entity are significant. Attributes of a shadow entity and relationships from a shadow entity are ignored.
localDiscrepancyCounts	DisDiscrepancyCounts	The discrepancy counts for this entity.
totalDiscrepancyCounts	DisDiscrepancyCounts	The discrepancy counts for this entity and its children.
modelingError	ResultModelingError	Indicates that a cartridge could not properly model some part of the source data. Typically this is due to a topology that is not understood. For example, a cartridge may not expect to find a physical port under a physical port. If found, it could set a modeling error on the parent port, which would be presented in the UI.

See "DisDiscrepancyCounts" for more information on the DisDiscrepancyCounts type.

The following entities have the DiscrepancyEnabled capability applied within Network Integrity:

• CustomNetworkAddress

• CustomObject

• DeviceInterface

• DeviceInterfaceConfigurationItem

• Equipment

• EquipmentHolder

• GeographicPlace

• InventoryGroup

• InventoryRole

• LogicalDevice

• LogicalDeviceAccount

• LogicalDeviceConfigurationItem

• Network

• NetworkConfigurationItem

• NetworkEdge

• NetworkNode

• PhysicalConnector

• PhysicalDevice

• PhysicalPort

• Pipe

• PipeConfigurationItem

• PipeTerminationPoint

• PlaceConfigurationItem

• Service

• ServiceConfigurationItem

• TelephoneNumber

• TrailPath

Groupable Capability

The Groupable capability allows arbitrary entities to be related through an application-defined ID. This capability is used internally within Network Integrity to group all result entities for a given scan.

Table 34-2 describes the groupId attribute.

Table 34-2 Discrepancy Detection Attributes and Types

Attribute	Type	Description
groupId	Long	The ID used to identify the group. For internal use only by Network Integrity.

The Groupable capability is applied to the following entities:

• CustNetAddrConsumer

• CustomNetworkAddress

• CustomNetworkAddressCharacteristic

• CustomNetworkAddressCustomNetworkAddressRel

• CustomObject

• CustomObjectCharacteristic

• CustomObjectConsumer

• CustomObjectCustomObjectRel

• DeviceInterface

• DeviceInterfaceCharacteristic

• DeviceInterfaceConfigurationItem

• DeviceInterfaceConfigurationItemCharacteristic

• DeviceInterfaceConsumer

• Equipment

• EquipmentCharacteristic

• EquipmentConsumer

• EquipmentEquipmentRel

• EquipmentHolder

• EquipmentHolderCharacteristic

• EquipmentHolderConsumer

• EquipmentHolderEquipmentRel

• GeoAddressRangeConsumer

• GeographicAddressConsumer

• GeographicLocationConsumer

• GeographicPlace

• GeographicSiteConsumer

• InvGroupRef

• InvGroupRel

• InvRoleCharacteristic

• InventoryGroup

• InventoryGroupCharacteristic

• InventoryRole

• LogicalDevice

• LogicalDeviceAccount

• LogicalDeviceCharacteristic

• LogicalDeviceConfigurationItem

• LogicalDeviceConfigurationItemCharacteristic

• LogicalDeviceConsumer

• LogicalDeviceLogicalDeviceRel

• NetEdgeCustomObjectRel

• NetEdgePipeRel

• NetNodeCustomNetworkAddressRel

• NetNodeCustomObjectRel

• NetNodeDeviceInterfaceRel

• NetNodeEquipmentRel

• NetNodeLogicalDeviceRel

• NetNodeNetEdgeRel

• NetNodeNetworkRel

• NetNodePhysicalDeviceRel

• NetNodePhysicalPortRel

• Network

• NetworkCharacteristic

• NetworkConfigurationItem

• NetworkConfigurationItemCharacteristic

• NetworkConsumer

• NetworkEdge

• NetworkEdgeCharacteristic

• NetworkNode

• NetworkNodeCharacteristic

• PhysicalConnector

• PhysicalConnectorCharacteristic

• PhysicalConnectorConsumer

• PhysicalDevice

• PhysicalDeviceCharacteristic

• PhysicalDeviceConsumer

• PhysicalDeviceEquipmentRel

• PhysicalDevicePhysicalDeviceRel

• PhysicalPort

• PhysicalPortCharacteristic

• PhysicalPortConsumer

• Pipe

• PipeCharacteristic

• PipeConfigurationItem

• PipeConfigurationItemCharacteristic

• PipeConsumer

• PipeDirectionality

• PipeDirectionalityPipePipeTPRelRel

• PipePipeTPRel

• PipeRel

• PipeTPPipeTPRel

• PipeTerminationPoint

• PipeTerminationPointCharacteristic

• PlaceCharacteristic

• PlaceConfigurationItem

• PlaceConfigurationItemCharacteristic

• PlaceCustomNetworkAddressRel

• PlaceCustomObjectRel

• PlaceDeviceInterfaceRel

• PlaceEquipmentRel

• PlaceInventoryGroupRel

• PlaceLogicalDeviceAccountRel

• PlaceLogicalDeviceRel

• PlaceNetworkNodeRel

• PlaceNetworkRel

• PlacePhysicalDeviceRel

• PlacePipeRel

• PlacePipeTerminationPointRel

• PlaceRel

• PlaceServiceRel

• Service

• ServiceCharacteristic

• ServiceConfigurationItem

• ServiceConfigurationItemCharacteristic

• ServiceConsumer

• TNCharacteristic

• TNConsumer

• TelephoneNumber

• TrailPath

• TrailPipeRel

• TrailPipeRelPipeRel

• TrailPipeRelTrailPathRel

About the Optical Model for Network Integrity

The Optical Model for Network Integrity supports links, cross-connects, transport pipes, and circuits. It includes both generic specifications and synchronous digital hierarchy (SDH) specifications.

The Optical Model uses a generic specification to define its set of attributes. The generic specification can be extended to introduce new attributes, but it must always contain the entire set of generic attributes.

The Optical Model is built on the Information Model for Network Integrity, with modifications to support integration with Oracle Communications Unified Inventory Manager (UIM).

This section describes new entities introduced by this model, or default mappings of Information Model entities to the Optical Model. See "About the Oracle Communications Information Model for Network Integrity" for more information on the Information Model for Network Integrity, its entities, and attributes.

Specifications

Table 34-3 summarizes the generic specifications for the Optical Model for Network Integrity.

Table 34-3 Generic Specifications for the Optical Model

Specification	Type	Description
Optical Topological Link	Pipe	N/A
Cross-connect	InventoryGroup	N/A
Cross-connect Segment	Pipe	A cross-connect is composed of one or more cross-connect segments.
Optical Trail Pipe	Pipe	An optical trail path is enabled by one or more trail pipes.
Optical Transport Pipe	Pipe	N/A
Optical Circuit	Pipe	N/A

Table 34-4 shows explicit types for the Generic specification.

Table 34-4 Explicit Types for the Generic Specifications of the Optical Model

Specification	Type	Description
STM-1	Pipe	A specialized topological link.
STM-4	Pipe	A specialized topological link.
STM-8	Pipe	A specialized topological link.
STM-16	Pipe	A specialized topological link.
STM-64	Pipe	A specialized topological link.
STM-256	Pipe	A specialized topological link.
VC4 HOT	Pipe	A specialized transport pipe.
VC3 Circuit	Pipe	A specialized circuit.
VC4 Circuit	Pipe	A specialized circuit.
VC12 Circuit	Pipe	A specialized circuit.

Optical Topological Link

A topological link is a connection between two devices. Each topological link is represented as an Information Model pipe entity, as shown in Figure 34-6.

Figure 34-6 Optical Topological Link Model

Table 34-5 lists the expected attributes belonging to the generic Topological Link specification.

Table 34-5 Topological Link Specification for the Optical Model

Attribute	Source	Description
name	Pipe	The name of the optical topological link.
pipeTerminationPoints	Pipe	The two end points of the link. TerminationPoints must use a specification that supports Port Termination Point attributes. See "Port Termination Point" for more information.
layerRate	Specification	The textual layer rate (for example, STM-1). See "Optical Layer Rates" for more information.

Port Termination Point

A Port Termination Point is a specialization of the Information Model PipeTerminationPoint entity, but with a simplified representation and presentation of the directionality. All end point information for a port is specified within the entity, and not in the result group.

It is possible for a cartridge to extend the model to assign the port if necessary.

For TMF814, the Port Termination Point can apply to physical termination points (PTPs), connection termination points (CTPs), and floating termination points (FTPs).

Table 34-6 lists the expected attributes belonging to the generic Port Termination Point specification.

Table 34-6 Port Termination Point Specification for the Optical Model

Attribute	Source	Description
name	PipeTerminationPoint	The name of the port.
device	Specification	The name of the device containing the port.
directionality	Specification	The direction of signal from this port to pipe. Allowed values are: UNKNOWN, SOURCE, SINK, BIDIRECTIONAL For a unidirectional pipe, the termination point at one end should be SOURCE and the other end SINK.
rate	Specification	The port rate in Mbit/s (for example, 34 Mbit/s for an e3).
channel	Specification	The channel number, if applicable. In SDH networks, this is known as the JKLM value, and represents the channel positions in the optical hierarchy.

Cross-Connect

Cross-connects are connections between two ports within a device. Each cross-connect is represented as a container (as an Inventory Group entity in the Information Model) with one or more Information Model Pipe entities that represent the A-to-Z connections that define the cross-connect, as shown in Figure 34-7.

Figure 34-7 Cross-Connect Model

Table 34-7 lists the expected attributes belonging to the generic Cross-connect specification.

Table 34-7 Cross-connect Specification for the Optical Model

Attribute	Source	Description
name	InventoryGroup	The name of the cross-connect.
layerRate	Specification	The textual layer rate (for example, VC4). See "Optical Layer Rates" for more information.
type	Specification	The type of cross-connect. Allowed values are: SIMPLE, ADD_DROP_A, ADD_DROP_Z, INTERCONNECT, DOUBLE_INTERCONNECT, DOUBLE_ADD_DROP, OPEN_ADD_DROP, EXPLICIT.

Table 34-8 lists the expected attributes belonging to the generic Cross-connect Segment specification.

Table 34-8 Cross-connect Segment Specification for the Optical Model

Attribute	Source	Description
name	Pipe	The name of the cross-connect segment. This attribute cannot contain a value.
pipeTerminationPoints	Pipe	The two end points of the link. Termination Points must use a specification that supports Port Termination Point attributes. See "Port Termination Point" for more information.
protectionRole	Specification	Possible values are PRIMARY and BACKUP

Optical Transport Pipe

Transport pipes represent a partial or complete path through an optical network; for example, a VC4 higher order transport (HOT) involving three devices and two synchronous transport modules (STMs). Although a VC4 channel on a single STM link between two devices could be considered a HOT and modeled as such, it is typically omitted. The reference to this HOT is replaced with a reference to the parent STM link with the appropriate J value.

A transport pipe can include one or more paths; for example, there could be one primary path and one protection path, as shown in Figure 34-8.

Figure 34-8 Transport Pipe Model

Table 34-9 lists the expected attributes belonging to the generic Transport Pipe specification.

Table 34-9 Transport Pipe Specification for the Optical Model

Attribute	Source	Description
name	Pipe	The name of transport pipe.
pipeTerminationPoints	Pipe	The two end points of the link. TerminationPoints must use a specification that supports Port Termination Point attributes. See "Port Termination Point" for more information.
trailPaths	Pipe	The ordered list of TrailPath instances representing the paths of end-to-end connectivity of the pipe.
layerRate	Specification	The textual layer rate (for example, VC4). See "Optical Layer Rates" for more information.
rerouted	Specification	A flag indicating that the transport pipe has been rerouted. This flag simplifies reports by providing a clearer discrepancy in some cases.
partial	Specification	A flag indicating that the transport pipe could not be fully traced. This flag simplifies reports by providing a clearer discrepancy in some cases.

A trail path must define the trail pipes (link or transport) used between devices in the path. Optionally, the trail path can also include the cross-connect segments or the circuit trail path, even though this information can be obtained from other sources.

Optical Trail Pipe Reference

Transport pipes and circuits include one or more trail paths. A trail path is made up of one or more trail pipes. The trail pipes can be transport pipes or links. The trail path uses a particular channel on each trail pipe.

Because trail pipes are modeled in a different result group, a trail pipe reference is used to associate the pipe to the channel. A trail pipe reference is modeled as a pipe with the minimal amount of data needed to identify the actual trail pipe and describe the channel.

Table 34-10 lists the expected attributes belonging to the generic Trail Pipe specification.

Table 34-10 Trail Pipe Reference Specification for the Optical Model

Attribute	Source	Description
name	Pipe	The name of the referenced transport pipe or link.
channel	Specification	The channel number. In SDH networks, this is known as the J-K-L-M value.

Optical Circuit

A circuit represents a path through a network, passing through and between devices. A circuit can be complete or partial. A complete circuit is one that has a known start and end-point. A partial circuit is one is missing one or both of its end-points. Optical trail pipes trace the path of the circuit between and through devices.

Figure 34-9 shows the circuit model.

Figure 34-9 Optical Circuit Model

Table 34-11 lists the expected attributes belonging to the generic Circuit specification.

Table 34-11 Circuit Specification for the Optical Model

Attribute	Source	Description
name	Pipe	The name of transport pipe.
pipeTerminationPoints	Pipe	The two end points of the link. TerminationPoints must use a specification that supports Port Termination Point attributes. See "Port Termination Point" for more information.
trailPaths	Pipe	The ordered list of Trail Path instances representing paths of end-to-end connectivity that enable the pipe.
layerRate	Specification	The textual layer rate (for example, VC12). See "Optical Layer Rates" for more information.
rerouted	Specification	A flag indicating that the circuit has been rerouted. This flag simplifies reports by providing a clearer discrepancy in some cases.
partial	Specification	A flag indicating that the circuit could not be fully traced. This flag simplifies reports by providing a clearer discrepancy in some cases.

Optical Layer Rates

Table 34-12 describes the supported optical layer rates for the Optical Model, specifying to which parts of the model the layer rates apply, and how they are mapped from the TMF814 layer rates.

Table 34-12 Optical Layer Rates for the Optical Model

Layer Rate Value	Applies To	Mapped from TMF814 Layer Rates
STM0	Link	LR_DSR_OC1_STM0 LR_Line_OC1_STS1_and_MS_STM0 LR_Section_OC1_STS1_and_RS_STM0
STM1	Link	LR_DSR_OC3_STM1 LR_DSR_2xSTM1 LR_Line_OC3_STS3_and_MS_STM1 LR_Section_OC3_STS3_and_RS_STM1
STM4	Link	LR_DSR_OC12_STM4 LR_Line_OC12_STS12_and_MS_STM4 LR_Section_OC12_STS12_and_RS_STM4
STM8	Link	LR_DSR_OC24_STM8 LR_Line_OC24_STS24_and_MS_STM8 LR_Section_OC24_STS24_and_RS_STM8
STM16	Link	LR_DSR_OC48_and_STM16 LR_Line_OC48_STS48_and_MS_STM16 LR_Section_OC48_STS48_and_RS_STM16
STM64	Link	LR_DSR_OC192_and_STM64 LR_Line_OC192_STS192_and_MS_STM64 LR_Section_OC192_STS192_and_RS_STM64
STM256	Link	LR_DSR_OC768_and_STM256 LR_Line_OC768_STS768_and_MS_STM256 LR_Section_OC768_STS768_and_RS_STM256
VC4	Cross-connect, Transport Pipe, Circuit	LR_STS3c_and_AU4_VC4
VC3	Cross-connect, Circuit	LR_Low_Order_TU3_VC3
VC12	Cross-connect, Circuit	LR_VT2_and_TU12_VC12

Default Result Model

By default, all Optical Model entities are modeled relative to a result group representing a device. When an entity spans multiple devices, it is modeled relative to the device that appears first in a sorted list, known as the lower device.

This result model can be extended. For example, a cartridge can extend the result model to map entities to different result groups. Such an extension may also require changes to all actions. For example, default discrepancy detection assumes that the network and inventory results have consistent modeling. Either a change to the default modeling must be made to network discovery, assimilation, and inventory import or custom discrepancy detection must be introduced to compensate.

Where possible, use the same result group for all entities related to a given device. For example, if equipment, links, and cross-connects for a device are discovered by the same action, all should be modeled under a single result group, not under two or three different result groups. This reduces clutter in the UI when viewing results and reduces cost during discrepancy detection.

Figure 34-10 Default Result Model

Link Result Model

A root entity container named Links is the parent for all topological links associated with a device. The topological link appears on the lower device of the two end points.

Cross-connect Result Model

A root entity container named cross-connects is the parent for all cross-connects associated with a device.

Optical Transport Pipe Result Model

A root entity container named Transport is the parent for all transport pipes associated with a device. The transport pipe appears on the lower device of the two end points.

Optical Circuit Result Model

A root entity container named Circuits is the parent for all circuits associated with a device. A circuit appears on the result group for the lower device of the two end points.

Information Model Relationship Entities

This section summarizes the Information Model relationship entities used in the Optical Model.

Inventory Group to Pipe

The InventoryGroup entity is used as a general-purpose container to group related entities. In the Optical Model, only Pipe entities are grouped. The InvGroupRef relationship entity is used to relate the pipe to the inventory group, as in the following example:

InventoryGroup - InvGroupRef - Pipe

See “Inventory Group Pattern” in Oracle Communications Information Model Reference for more information.

Pipe-to-Port Termination Point

This relationship appears in links, cross-connects, transport pipes, and circuits. The PipePipeTPRel relationship entity is used to relate the pipe termination point to the pipe, as in the following example:

Pipe - PipePipeTPRel - PipeTerminationPoint

See “Connectivity Entities” in Oracle Communications Information Model Reference for more information.

Trail Path to Optical Trail Pipe

This relationship appears in transport pipes and circuits. There are two relationship entities used to relate the trail path to the parent pipe, as in the example below:

Pipe (Trail Path Parent) - TrailPipeRel - Pipe (Trail Pipe)

Pipe (Trail Pipe) - TrailPipeRelTrailPathRel - TrailPath

See “Connectivity Entities” in Oracle Communications Information Model Reference for more information.

Discrepancy Detection Considerations

Discrepancy detection is used to compare matching result trees. The way that a cartridge populates containers (such as Circuits) affects discrepancy detection. If one side has the container, but the other does not, then there is a discrepancy for the extra (or missing) container, not individual discrepancies for the contents of the container.

An ideal discrepancy scenario is one where a discrepancy is reported for each extra circuit on a device, and not a single discrepancy for the device that is missing circuits.

When creating result groups using the Optical Model, create all relevant containers, even if they are empty.