Oracle® Communications
Network Integrity

Optical Circuit Assimilation Cartridge Guide

Release 7.3.2

E66045-01

May 2016

Oracle Communications Network Integrity Optical Circuit Assimilation Cartridge Guide, Release 7.3.2

E66045-01

Copyright © 2010, 2016, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Contents

Preface

- Audience

- Documentation Accessibility

- Document Revision History

1 Overview

- About the Optical Circuit Assimilation Cartridge

- Limitations

- Circuit Entity- Discrepancy Handling on Root Entity

- About Cartridge Dependencies

- Run-Time Dependencies

- Design Studio Dependencies

- Downloading and Opening the Cartridge Files in Design Studio

- Building and Deploying the Cartridge

2 About the Cartridge Components

- Assimilate Optical Circuits

- Layer Rate Initializer

- Optical Assimilation Initializer

- Optical VC4 HOT HOP Assimilator

- Optical VC3 LOT LOP Assimilator

- Optical VC12 LOT LOP Assimilator

- Optical Assimilation Circuit Matcher

- Page Initialization for Circuit

- Optical Assimilation Modeler

- Optical Assimilation Persister

- Link Modeler

- Link Persister

- Cleanup Processor

- Abstract Optical Circuit Discrepancy Detection

- Circuit Discrepancy Name Filter Initializer

- Missing Entity Filter Initializer

- Discrepancy Detector

3 Using the Cartridge

- Creating a Circuit Assimilation Scan

4 About Collected Data

- About Collected Data

5 About Cartridge Modeling

- About Cartridge Modeling

- About Fully-Protected Circuits

- About Partially-Protected Circuits

- About Circular Circuits

- About SDH JKLM Values

- About the Intermediate Assimilation Model

- Assimilation Data Modeling

6 About Design Studio Construction

- Model Collection

- Actions

7 About Design Studio Extension

- Creating a Custom Circuit Matcher

- SONET Assimilation

- About SONET JKLM Values

- Network Boundary Partial Circuit Correction

Preface

This guide explains the functionality and design of the Oracle Communications Network Integrity Optical Circuit Assimilation cartridge.

Audience

This guide is intended for Network Integrity administrators, developers, and integrators.

This guide assumes that you are familiar with the following documents:

- Network Integrity Developer's Guide: for a basic understanding of cartridges.

- Network Integrity Installation Guide: for an understanding of deploying and undeploying cartridges.

- Network Integrity Concepts: for an understanding of Network Integrity and cartridge extensibility.

This guide assumes that you are familiar with the following:

- Oracle Communications Design Studio for Network Integrity

- Network Integrity Optical TMF814 CORBA Cartridge

- Synchronous digital hierarchy (SDH)

- TMF814 and Multi Technology Network Management (MTNM) standards and terminology

- Development and extensibility of Network Integrity cartridges

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Document Revision History

The following table lists the revision history for this guide:

Version

Date

Description

E66045-01

May 2016

Initial release.

1 Overview

This chapter describes the Oracle Communications Network Integrity Optical Circuit Assimilation cartridge.

About the Optical Circuit Assimilation Cartridge

The Optical Circuit Assimilation cartridge enables you to derive end-to-end circuits that traverse through your synchronous digital hierarchy (SDH) networks. The Optical Circuit Assimilation cartridge uses topological link and cross-connect data from existing action results to assimilate circuits.

The Optical Circuit Assimilation cartridge can use scan results from the following types of actions as input:

- Discover TMF814

- Discover SNMP

- File Transfer and Parsing

- Assimilate Optical Circuits

When the input is an existing set of assimilation data, the Optical Circuit Assimilation cartridge performs additional levels of assimilation. The first level of assimilation results consists of the parent hierarchy, such as from multiple systems. Subsequent assimilation actions assimilate the circuits that span the multiple systems. The completed assimilation results shows the complete hierarchy of circuits.

Limitations

The Optical Circuit Assimilation cartridge has the following limitation.

Circuit Entity- Discrepancy Handling on Root Entity

In some cases, it can happen that the Optical Circuit Assimilation cartridge fails to discover a network circuit present in inventory without reporting a discrepancy. This is due to the default behavior of the Network Integrity Base detection cartridge.

In general, if a discovery scan finds Device1 with circuits A and B in the network, and the same device exists in inventory, but with circuits A, B, and C, Network Integrity reports an Entity- discrepancy on circuit C in the network.

In the above example, Network Integrity can fully compare the results for Device1 using the network discovery results and the inventory results.

However, by default, when Device1 is not listed in the discovery results (or, for this cartridge, in the assimilation results), Network Integrity does not report circuit discrepancies on the device.

You can extend the Optical Circuit Assimilation cartridge to detect Entity- discrepancies on root entities using one of the following approaches:

- Extend the Base detection cartridge or the Optical Circuit Assimilation cartridge by introducing a custom discrepancy detection action that reports discrepancies on root entities.

- Extend the Optical Circuit Assimilation cartridge with a custom discrepancy detection action (specifically, the Extra Circuit Filter Initializer processor) that checks missing circuits on the final assimilation scan. Copy fully-traced circuits to the assimilation scan results as shadow entities.

See Network Integrity Developer's Guide for more information about cartridge extensibility and discrepancies.

About Cartridge Dependencies

The Optical Circuit Assimilation cartridge has the following types of dependencies.

Run-Time Dependencies

The Optical Circuit Assimilation cartridge has no run-time dependencies.

Design Studio Dependencies

The Optical Circuit Assimilation cartridge has the following dependencies:

- NetworkIntegritySDK

- Optical_Model

- ora_uim_model

Downloading and Opening the Cartridge Files in Design Studio

To open, view, and extend the Optical Circuit Assimilation cartridge, you must first download the cartridge ZIP file from the Oracle software delivery web site:

https://edelivery.oracle.com

The Optical Circuit Assimilation cartridge ZIP file has the following structure:

- Network_Integrity_Cartridge_Projects/OpticalAssimilation_Cartridge

- Network_Integrity_Cartridge_Projects/Optical_Model

The OpticalAssimilation_Cartridge project contains the extendable Design Studio files.

See Network Integrity Concepts for guidelines and best practices for extending cartridges. See Design Studio Help for information about importing projects and opening files in Design Studio.

Building and Deploying the Cartridge

See Design Studio Help for information about building and deploying cartridges.

2 About the Cartridge Components

This chapter provides information about the components of the Oracle Communications Network Integrity Optical Circuit Assimilation cartridge.

The Optical Circuit Assimilation cartridge contains the following actions:

- Assimilate Optical Circuits

- Abstract Optical Circuit Discrepancy Detection

Assimilate Optical Circuits

The Assimilate Optical Circuits action reads unprocessed circuit data, such as topological links, cross-connects, and other partially assimilated circuit data, from previous scans and builds end-to-end circuits.

The Assimilate Optical Circuits action contains the following processors run in the following order:

1. Layer Rate Initializer

2. Optical Assimilation Initializer

3. Optical VC4 HOT HOP Assimilator

4. Optical VC3 LOT LOP Assimilator

5. Optical VC12 LOT LOP Assimilator

6. Optical Assimilation Circuit Matcher

7. Page Initialization for Circuit

8. Optical Assimilation Modeler

9. Optical Assimilation Persister

10. Link Modeler

11. Link Persister

12. Cleanup Processor

Figure 2-1 illustrates the processor workflow of the Assimilate Optical Circuits action.

Figure 2-1 Assimilate Optical Circuits Processor Workflow

Layer Rate Initializer

This processor initializes the layer rates for cross-connects and topological links.

You can extend the assimilation action with a processor that overrides the default layer rates and proposes new ones.

Optical Assimilation Initializer

This processor is used to set up the data for the Intermediate Assimilation Model, in preparation for the assimilation processors, by doing the following:

- If the Process Discovery Results field in the UI is set to true (which indicates that this is the first level of assimilation in a series of hierarchical assimilation scans), this processor places the discovered topological link and cross-connect data in the Intermediate Assimilation Model.

- Initializes the scope of the scan by labeling the defined scan data from other actions and in the Intermediate Assimilation Model with the scan ID from the current assimilation action.

Optical VC4 HOT HOP Assimilator

This processor takes the data from the Intermediate Assimilation Model and traces all higher order transport and customer circuits that are at the rate of VC4.

Optical VC3 LOT LOP Assimilator

This processor takes the data from the Intermediate Assimilation Model and traces all lower order transport and customer circuits that are at the rate of low order VC3.

Optical VC12 LOT LOP Assimilator

This processor takes the data from the Intermediate Assimilation Model and traces all lower order transport and customer circuits that are at the rate of VC12.

Optical Assimilation Circuit Matcher

This processor matches assimilated data with your inventory system. Cross-connect and topological link object naming can often vary over a network. When this processor matches an assimilated circuit with an inventory circuit, it applies the inventory circuit name to the assimilated circuit, thus reducing the number of detected discrepancies from the inventory system to ensure that the assimilated data matches the inventory data as closely as possible, to reduce the quantity of detected discrepancies.

The default circuit matching logic can query Import action scan results. You can extend the Assimilate Optical Circuits action to retrieve circuit naming information from another source or to change the criteria for circuit matching.

The default circuit matching logic matches circuits by doing all of the following:

- Searches for a circuit with the same A-port and Z-port, then searching for matching circuit and path names.
If this processor finds a matching circuit in the inventory scan results, it assigns the inventory circuit name to the network circuit. Otherwise, this processor generates a name for the circuit and its paths.

- Returns the name of the result group (by default, the device name) into which to save the matched circuit.
This adds some flexibility where the grouping is determined by the import results.

- Ensures that discrepancy detection functions properly.
The circuit matcher determines whether the network path and the inventory path are in the same order. If the orders are reversed, this processor reverses the assimilated circuit (even circuits with multiple paths and protected paths) to match the inventory circuit.

- Determines if a circuit is rerouted.
The processor compares the paths between the network and inventory circuits to see if parent pipes are different at any point. This processor adds a flag to the results of a rerouted circuit.

- Merges partial duplicate circuits.
After the processor has finished circuit matching, the processor takes partial circuits with the same circuit name and merges them together and redefines their start and end port. The processor attempts to match the updated circuit with a circuit from the inventory.

If the Model Incomplete Circuits field in the UI is set to True, this processor searches for complete circuit names and partial circuit names. If Model Incomplete Circuits is set to False, this processor searches for complete circuit names only.

Page Initialization for Circuit

This processor counts the number of circuits and synchronous transport modules (STMs). It initializes the number of pages to be processed based on the page size. This processor passes the pages for STMs to the Link Modeler processor and passes the pages for circuits to the Optical Assimilation Modeler processor.

Optical Assimilation Modeler

This processor takes each circuit from the Intermediate Assimilation Model and models it in the circuit hierarchy. The result for each unmatched circuit appears under one of the two end-device result groups. Matched circuit are modeled under the result group provided by the Optical Assimilation Circuit Matcher processor.

If the Model Incomplete Circuits field in the UI is set to True, this processor also models all partial circuits.

Optical Assimilation Persister

This processor saves the modeled circuit data to the Network Integrity database.

Link Modeler

This processor models STMs in the Intermediate Assimilation Model. Matched STMs are modeled under a result group provided by the Optical Assimilation Circuit Matcher processor. Unmatched STMs appear under one of the two end-device result groups.

Link Persister

This processor saves the modeled link data to the Network Integrity database.

Cleanup Processor

This processor flushes the Intermediate Assimilation Model when the Is Top Level Assimilation list in the UI is set to True.

Abstract Optical Circuit Discrepancy Detection

The Abstract Optical Circuit Discrepancy Detection action is used to build a solution that detects discrepancies between assimilated data and data imported from an inventory system.

See Network Integrity Developer's Guide for more information about discrepancy detection.

The Abstract Optical Discrepancy Detection action is made up of the following processors run in the following order:

1. Circuit Discrepancy Name Filter Initializer

2. Missing Entity Filter Initializer

3. Discrepancy Detector

Figure 2-2 illustrates the processor workflow of the Abstract Optical Circuit Discrepancy Detection action for the Optical Circuit Assimilation cartridge.

Figure 2-2 Abstract Optical Discrepancy Detection Action Processor Workflow

Circuit Discrepancy Name Filter Initializer

This processor implements discrepancy filters to populate the Custom attribute of discrepancies related to the same circuit. In this context, circuit can mean Topological Link, Transport Pipe, or Circuit.

This processor retrieves the circuit name from the Custom attribute and uses it to relate any discrepancies on a circuit or its parts (such as pipe termination point, trail path, or trail pipe). In Network Integrity, you can search on the circuit name to find all discrepancies related to a particular circuit.

Missing Entity Filter Initializer

During hierarchical assimilation, there is not enough information available in any one assimilation scan to properly detect missing circuit discrepancies.

The Optical Model uses InventoryGroup containers (such as Links, Transport, or Circuits) to organize circuits. The Assimilate Optical Circuits action can be done hierarchically, meaning that not all circuits are known until the topmost assimilation scan completes.

By default, discrepancy detection generates missing entity discrepancies for circuits that are not traced until later scans. This processor applies a filter to such circuits to avoid false discrepancies. The Discrepancy Detection action must be extended to correctly identify authentic discrepancies in hierarchical assimilation.

This processor returns True if the assimilation scan is neither first nor last in a hierarchical assimilation scan. The filter is not applied for a simple assimilation scan.

You can extend the Discrepancy Detection action to apply different conditions. If an extending action uses a different condition, disabling the filter (which would allow for false discrepancies) during the last hierarchical assimilation, the assimilation action should also be extended. Any circuits present in input scans should be copied to this scan as a temporary entity (called a shadow entity). Only the name and type need to be populated, along with setting the shadow attribute to True. For more information on shadow entities, see Network Integrity Developer's Guide. If information is available about whether the circuit was matched in inventory, then circuits known to not exist in inventory do not need to be copied.

Discrepancy Detector

This processor inherits base operations from the base detection cartridge. See Network Integrity Developer's Guide for more information about the Base Detection Cartridge.

3 Using the Cartridge

This chapter explains how to use the Oracle Communications Network Integrity Optical Circuit Assimilation cartridge.

Creating a Circuit Assimilation Scan

A Circuit Assimilation scan runs the Assimilate Optical Circuits action, which assimilates circuit data from discovery scan results to identify, trace, and name continuous circuits.

The input for a Circuit Assimilation scan is one or more discovery or assimilation scan results containing optical circuit information.

To create a Circuit Assimilation scan:

1. Create a scan.
See the Network Integrity online Help for more information.

2. On the General tab, do the following:

- From the Scan Action list, select Assimilate Optical Circuits.
The Scan Type field displays Assimilation.

- Configure the following parameters:

- To assimilate VC12 circuits, select True from the Assimilate VC12 list.

- To assimilate VC3 circuits, select True from the Assimilate VC3 list.

- To convert the input results to the Intermediate Assimilation Model, select True from the Process Discovery Results list. Select True when you are running the first scan of a hierarchical set of assimilations scans.

- To model partial circuits (in addition to complete circuits) from the Intermediate Assimilation Model, select True from the Model Incomplete Circuits list. Select True when you are running the last scan of a hierarchical set of assimilation scans.

- To specify that the scan is being run on the top and final level in a hierarchical set of assimilation scans, select True from the Is Top Level Assimilation list. When this list is set to True, the circuit matcher attempts to name all partial and complete circuits. When this list is set to False, the circuit matcher attempts to name complete circuits only.

See Table 6-2, "Cartridge Scan Parameters Design Studio Construction" for more information.

3. On the Scope tab, do the following:

- Add one or more scans as input for the Assimilation scan.

- From the Assimilate Input Scan Results list, specify how input scan results are assimilated. Choose one of the following options:

- To process input discovery scans simultaneously for all scan address and result groups for all scan runs, select All Scans, All Scan Addresses.

- To process input discovery scans in parallel for all scan addresses and result groups by scan run, select Single Scan, All Scan Addresses.

- To process input discovery scans in parallel for each scan address by scan run, select Single Scan, Single Scan Address.

- From the Automatically Run Input Scans list, specify whether input scans are automatically re-run before the Assimilation scan is run. Choose one of the following options:

- To not re-run input discovery scans before the assimilation scan, no matter how old the scan results are, select Never.

- To re-run all input discovery scans before the assimilation scan, no matter how recent the scan results are, select Always.

- To re-run input discovery scans before the assimilation scan only if the scan results are older than a specified value, select If Older than X.

- To re-run input discovery scans before the assimilation scan only if the scan results are older than a custom value, select If Older than a Custom Age and enter a value in Hours, Days, or Weeks.

4. Make any other required configurations.

4 About Collected Data

This chapter explains how the data collected by the Oracle Communications Network Integrity Optical Circuit Assimilation cartridge is treated.

About Collected Data

The Assimilate Optical Circuits action uses discovered data as input. The input data must be in the Optical Model for Network Integrity.

This cartridge uses the following subset of objects from the Optical Model as input for assimilation:

- Topological Links:

- Device name and port name on each end of the topological link

- Topological link bandwidth

- Cross-connects:

- Device name that the cross-connect traverses

- Device ports at each end of the cross-connects

- The channel on each port on a cross-connect

- Cross-connect bandwidth

For more information on the Optical Model for Network Integrity, see Network Integrity Developer's Guide.

5 About Cartridge Modeling

This chapter explains how the Oracle Communications Network Integrity Optical Circuit Assimilation cartridge models collected data.

About Cartridge Modeling

The Assimilate Optical Circuits action models its results to the Optical Model for Network Integrity. For more information on the Optical Model for Network Integrity, see Network Integrity Developer's Guide.

This cartridge models its results as the following entities:

- Topological Links

- Transport Circuits

- Customer Circuits

Both the Optical Circuit Assimilation cartridge and the Optical Model for Network Integrity support fully-protected and partially-protected circuits. Circuit protection is known as subnetwork connection protection (SNCP).

The Optical Circuit Assimilation cartridge uses an intermediate or staging model to manipulate the assimilated data before persisting the fully-modeled circuits to the Optical Model. See "About the Intermediate Assimilation Model" for more information.

About Fully-Protected Circuits

A fully-protected circuit is one with a fully redundant path between the A-port and the Z-port: two paths leave the A-port and do not converge until the Z-port. See Figure 5-3, "Fully-Protected LOP", for an example of a fully-protected circuit.

About Partially-Protected Circuits

A partially-protected circuit is one with redundant segments, but not fully redundant. For example, a circuit that starts off unprotected, but then enters one or more optical rings, providing protection for one or more segments of the circuit. See Figure 5-4, "Partially-Protected LOP", and Figure 5-5, "Partially-Protected LOP with Multiple Protection Segments", for examples of partially-protected circuits.

About Circular Circuits

A circular circuit (or a loop circuit) is one with a duplicate trail pipe in the path. The Optical Circuit Assimilation cartridge models a circular circuit as a partially-protected circuit with a discrepancy. The discrepancy status is set to Ignore, because the circuit has to be fixed in the network.

You can identify circular circuits by reviewing the trail path information of the circuit with the discrepancy set to Ignore and finding a duplicate trail pipe. Or you can view the diagnostic logs for instances of "circular," as shown in the following example:

Found circular VC12 path in A direction at port port_number.
Found circular VC12 path in Z direction at port port_number.

About SDH JKLM Values

JKLM values are used to define the path and indexes a channel uses within the synchronous digital hierarchy:

- J is the AUG index (1..n)

- K is the TUG-3 index (1..3)

- L is the TUG-2 index (1..7)

- M is the TU-12 index (1..3)

The following list represents SDH JKLM channel index mappings:

- J(AUG)=VC4 139.264(E4)

- K(TUG-3)=VC3 34.368(E3)

- L(TUG-2)=None

- M(TU-12)=VC12 2.048(E1)

An example JKLM value for an SDH connection termination point (CTP) VC-12 on an STM-16 is /sts3c_au4-j=5/vt2_tu12-k=1-l=5-m=2.

Higher order transports (HOTs) and paths (HOPs) can ride on VC4(AUG) pipes. Lower order paths (LOPs) can ride on VC3(AUG/TUG-3) pipes and on VC12(AUG/TUG-3/TUG-2/TU-12) pipes.

All pipes have either a J, JK, or JKLM value in the hierarchy. The Optical Circuit Assimilation cartridge models all pipes with full JKLM values, with a value of 0 for any unused indexes. A VC4 pipe with just a J value sets KLM index values to 0 (for example: 3000). A VC3 pipe with just a JK value sets the LM index values to 0 (for example: 3200).

Table 5-1 shows the layer rates for different types of cross-connects.

Table 5-1 Layer Rates by Cross-Connect Type

Cross-Connect Type

Layer Rate Code

LR_E1_2M

5

LR_E3_34M

7

LR_E4_140M

8

LR_STS3c_and_AU4_VC4 (higher order cross-connect)

15

LR_Low_Order_TU3_VC3 (lower order cross-connect)

13

LR_VT2_and_TU12_VC12 (lower order cross-connect)

11

About the Intermediate Assimilation Model

Before persisting fully modeled circuits and paths to the Optical Model, the assimilated data is staged in the Intermediate Assimilation Model. Staging the data in the Intermediate Assimilation Model reduces system traffic and improves performance.

The Intermediate Assimilation Model also provides a safe buffer in the event that a scan fails or is interrupted by not manipulating live data in the database. The Cleanup processor flushes the Intermediate Assimilation Model at the end of a scan run or series of hierarchical scans. Failures and errors are flushed when the Cleanup processor runs.

When hierarchical information is being assimilated, the Intermediate Assimilation Model passes the data onto follow-on assimilation actions.

Figure 5-1 shows the relationships for an unprotected LOP. There are relationships between the LOP, LOT, HOT, and STMs. The LOT can reference both an HOT and an STM as the parent. The LOP has only one path.

Figure 5-1 Unprotected LOP

Figure 5-2 shows the relationships for an unprotected HOP. This HOP has only one path.

Figure 5-2 Unprotected HOP

Figure 5-3 shows a circuit with multiple paths. One path is the primary path and the other is the protected path. This is an example of a fully-protected circuit where the LOP has two LOT paths.

Figure 5-3 Fully-Protected LOP

Figure 5-4 shows a partially-protected circuit. The protection path only represents the protected segments of the LOP. The protection path is protecting only part of the circuit, between device 2 and device 5, by taking a different path through device 4. The segments between device 1 and 2 and between device 5 and 6 are not protected.

Figure 5-4 Partially-Protected LOP

Figure 5-5 shows a more complex example of a partially-protected LOP, containing multiple protected segments.

Figure 5-5 Partially-Protected LOP with Multiple Protection Segments

Assimilation Data Modeling

By default, when the Optical Circuit Assimilation cartridge models assimilated data, it begins by modeling the physical tree, followed by the logical tree. When you extend a cartridge or create a custom cartridge, ensure that the assimilated data is modeled in this order.

The following tables explain what information is used to assimilate circuit entities.

Table 5-2 lists the cross-connect information used in the assimilation of circuits.

Table 5-2 Cross-Connect Assimilation Data

Field

Description

SCANRUNID(long)

The scan run ID of the assimilation scan.

DEVICE(string)

The device name.

APORT(string)

The port name on the start-side of the cross-connect (A-port).

ZPORT(string)

The port name on the end-side of the cross-connect (Z-port).

RATE(short)

The layer rate code.

ACHANNELHO(string)

The J channel on the A-port of the cross-connect.

ZCHANNELHO(string)

The J channel on the Z-port of the cross-connect.

ACHANNELLO(String)

The KLM channel on the A-port of the cross-connect.

ZCHANNELLO(String)

The KLM channel on the Z-port of the cross-connect.

PATHREF(long)

An optional reference to the path.

PROTSTATUS(String)

The protection status: W for primary, P for backup.

PROCESSED(Boolean)

The circuit tracing status indicator (default is false).

Table 5-3 lists the STM information used in the assimilation of circuits.

Table 5-3 STM Assimilation Data

Field

Description

SCANRUNID(long)

The scan run ID of the assimilation scan.

STMNAME(string)

N/A

RGROUP(string)

Result group to which to persist the data.

ADEVICE(string)

The device name of the first device (A-device).

ZDEVICE(string)

The device name of the last device (Z-device).

APORT(string)

The port name on the start-side of the A-device (A-port).

ZPORT(string)

The port name on the end-side of the Z-device (Z-port).

RATE(short)

The layer rate code.

Table 5-4 lists the path information used in the assimilation of circuits.

Table 5-4 Path Assimilation Data

Field

Description

SCANRUNID(long)

The scan run ID of the assimilation scan.

ADEVICE(string)

The device name of the first device (A-device).

ZDEVICE(string)

The device name of the last device (Z-device).

APORT(string)

The port name on the start-side of the A-device (A-port).

ZPORT(string)

The port name on the end-side of the Z-device (Z-port).

AFINAL(Boolean)

Indicates whether the pipe is completely traced at the A-port (default is false).

ZFINAL(Boolean)

Indicates whether the pipe is completely traced at the Z-port (default is false).

CIRCUITREF(long)

An optional reference to an HOT, HOP, or LOP.

RATE(short)

The layer rate code.

PROTSTATUS (string)

The protection status: M for primary, P for protection path.

ACHANNELHO(string)

The J channel on the A-port of the path.

ZCHANNELHO(string)

The J channel on the Z-port of the path.

ACHANNELLO(string)

The KLM channel on the A-port of the path.

ZCHANNELLO(string)

The KLM channel on the Z-port of the path.

REROUTED(Boolean)

Indicates whether the same circuit followed a different path in inventory (default is false).

PATHNAME(string)

The path name.

Table 5-5 lists the circuit information used in the assimilation of circuits.

Table 5-5 Circuit Assimilation Data

Field

Description

SCANRUNID(long)

The scan run ID of the assimilation scan.

CIRCUITNAME(string)

The circuit name taken from the Inventory data.

TYPE(string)

Indicates whether the circuit is a transport circuit or customer circuit.

RGROUP(string)

Result group to which to persist the data.

ADEVICE(string)

The device name of the first device (A-device).

ZDEVICE(string)

The device name of the last device (Z-device).

APORT(string)

The port name on the start-side of the A-device (A-port).

ZPORT(string)

The port name on the end-side of the Z-device (Z-port).

Table 5-6 lists the CPCRels information used in the assimilation of circuits.

Table 5-6 CPCRels Assimilation Data

Field

Description

SCANRUNID(long)

The scan run ID of the assimilation scan.

PARENTPIPE(long)

A pointer to the parent pipe, such as a link for an HOT.

CHILDPIPE(long)

A pointer to the child pipe, such as the HOT using a link.

CHANNEL(string)

The JKLM channel of the child circuit within the parent.

PARENTTYPE(String)

The circuit type of the parent circuit, such as STM.

SEQUENCE(LONG)

The order of the parent circuit, such as 3,2,1,-1,-2,-3…

6 About Design Studio Construction

This chapter provides information on the composition of the Oracle Communications Network Integrity Optical Circuit Assimilation cartridge from the Oracle Communications Design Studio perspective.

Model Collection

The Optical Circuit Assimilation cartridge uses the Optical Model for its model collection. See Network Integrity Developer's Guide for more information.

Actions

The following tables outline the Design Studio construction of the Optical Circuit Assimilation cartridge actions and associated components.

Table 6-1 shows the Design Studio construction of the actions for the Optical Circuit Assimilation cartridge.

Table 6-1 Actions Design Studio Construction

Action Name

Result Category

Address Handler

Scan Parameters

Processors

Assimilate Optical Circuits (assimilation)

Device

N/A

See Table 6-2

See Table 6-3

Discrepancy Detection

OpticalAssimilation

N/A

None

See Table 6-4

Table 6-2 shows the Design Studio construction of the scan parameters belonging to the Optical Circuit Assimilation cartridge.

Table 6-2 Cartridge Scan Parameters Design Studio Construction

Parameter Name

Type

Description

UI Label

assimilateVC12

Drop down

Select True to run the VC12 LOT LOP Assimilator processor. Values are True or False.

Assimilate VC12

assimilateVC3

Drop down

Select True to run the VC3 LOT LOP Assimilator processor. Values are True or False.

Assimilate VC3

processDiscoveryResults

Drop down

Causes the Optical Assimilation Initializer processor to convert the input results to the Intermediate Assimilation Model. If you are running a hierarchical set of assimilation scans, set this field to True for the first assimilation scan. Values are True or False.

Process Discovery Results

modelIncompleteCircuits

Drop down

Causes the Optical Assimilation Modeler processor to convert complete and partial circuits from the Intermediate Assimilation Model. If you are running a hierarchical set of assimilation scans, set this field to True on the last assimilation scan. Values are True or False.

Model Incomplete Circuits

isTopLevelAssimilation

Drop down

Indicates whether the assimilation scan is being run on the top and final level of the hierarchy. When this field is set to False, the circuit matcher matches circuit names for complete circuits only. When this field is set to True, the circuit matcher also matches partial circuits. Values are True or False.

Is Top Level Assimilation

Table 6-3 shows the Design Studio construction of the processors belonging to the Assimilate Optical Circuits action.

Table 6-3 Optical Circuit Assimilation Processors Design Studio Construction

Processor Name

Variable

Layer Rate Initializer

Input: N/A

Output: layerRates

Optical Assimilation Initializer

Input: layerRates

Output: N/A

Optical VC4 HOT HOP Assimilator

Input: N/A

Output:

- assimilateVC3
Configured scan parameter specifying whether to assimilate VC3s.

- assimilateVC12
Configured scan parameter specifying whether to assimilate VC12s.

- scansInScope
The list of scanRunIds in the assimilation scope, excluding the discovery scan run ID (toplevel).

Optical VC3 LOT LOP Assimilator

Input: scansInScope

Output: N/A

Optical VC12 LOT LOP Assimilator

Input: scansInScope

Output: N/A

Page Initialization For Circuit

Input: scansInScope

Output:

- devicePipeMap
A mapping of managed element (ME) names to circuit pipes.

- linkPages
The total number of links page based on page size.

- pageSize
The size of each page.

- pages
The total number of Circuit pages based on page size.

Optical Assimilation Circuit Matcher

Input: N/A

Output: N/A

Optical Assimilation Modeler

Input: N/A

Output: N/A

Optical Assimilation Persister

Input: devicePipeMap, pageIndex, pageSize, scansInScope

Output: N/A

Link Modeler

Input: devicePipeMap

Output: N/A

Link Persister

Input: devicePipeMap, linkPageIndex, pageSize, scansInScope

Output: N/A

Cleanup Processor

Input: N/A

Output: N/A

Table 6-4 shows the Design Studio construction of the processors belonging to the Discrepancy Detection action.

Table 6-4 Discrepancy Detection Processors Design Studio Construction

Processor Name

Variable

Circuit Discrepancy Name Filter Initializer

Input: N/A

Output:

- isTopLevel
Configured scan parameter specifying whether the scan configuration is the top level scan.

Missing Entity Filter Initializer

Input: isTopLevel

Output: N/A

DiscrepancyDetector

Input: N/A

Output: N/A

7 About Design Studio Extension

This chapter explains how to extend certain aspects of the Oracle Communications Network Integrity Optical Circuit Assimilation cartridge. See Network Integrity Developer's Guide for more information about extending cartridges. See Network Integrity Concepts for guidelines and best practices for extending cartridges.The following examples are explained in this section:

- Creating a Custom Circuit Matcher

- SONET Assimilation

- Network Boundary Partial Circuit Correction

Creating a Custom Circuit Matcher

You can extend the Optical Assimilation Circuit Matcher processor to use custom circuit matching logic, such as different matching criteria or different name sources.

See "Optical Assimilation Circuit Matcher" for more information about the default circuit matching logic.

To create a custom circuit matcher processor:

1. Open Oracle Communications Design Studio in the Design perspective.

2. Create a Network Integrity cartridge project.

3. Make the cartridge project dependent on the Optical Circuit Assimilation cartridge project.

4. Create an assimilation action.

5. Add the Assimilate Optical Circuits action as a processor in your assimilation action.

6. Create an assimilation processor named Custom Circuit Matcher to contain your custom circuit matching logic and insert it after the Optical Assimilation Circuit Matcher processor.
The Custom Circuit Matcher processor must fulfill all the functions of the Optical Assimilation Circuit Matcher processor. Your new action must also include a new condition on the Optical Assimilation Circuit Matcher processor that disables the Optical Assimilation Circuit Matcher processor, so only your new Circuit Matcher processor runs.

7. Build, deploy, and test your cartridge.
Your Custom Circuit Matcher processor is included and run by your new action, as shown in Figure 7-1.

Figure 7-1 Custom Circuit Matcher Processor Workflow

SONET Assimilation

The Optical Circuit Assimilation cartridge can be extended to assimilate circuits in other types of optical networks. This example explains how to assimilate circuits in a SONET network and is based on JKLM values for SONET networks. See "About SONET JKLM Values" for more information.

To extend the cartridge to assimilate circuits in a SONET network:

1. Open Design Studio in the Design perspective.

2. Create a Network Integrity cartridge project.

3. Make the cartridge project dependent on the Optical Circuit Assimilation cartridge project.

4. Create an assimilation action.

5. Add the Assimilate Optical Circuits action as a processor in your assimilation action.

6. Create an assimilation processor for higher order circuits named Optical VC3 HOT HOP Assimilator and insert it after the Optical VC4 HOT HOP Assimilator processor.
This processor must fulfill all the functions of the Optical VC4 HOT HOP Assimilator processor.

7. Create an assimilation processor for lower order circuits named Optical VC11 LOT LOP Assimilator and insert it before the Optical VC12 LOT LOP Assimilator processor.
This processor must fulfill all the functions of the Optical VC12 LOT LOP Assimilator processor.

8. Build, deploy, and test your cartridge.
Your new assimilation processors are included and run by your new action, as shown in Figure 7-2.

Figure 7-2 SONET Assimilation Processor Workflow

About SONET JKLM Values

JKLM values are used to define the path and indexes a channel uses within the SONET hierarchy, where:

- J is the AUG index (1..n)

- K is the AU-3 index (1..3)

- L is the TUG-2 index (1..7)

- M is the TU-11 index (1..4)

The following list represents SONET JKLM channel index mappings:

- J(AUG)=None

- K(AU3)=VC3/ST1 44.736(DS3)

- L(TUG-2)=None

- M(TU-11)=VC11/VT15 1.544(DS1)

An example JKLM value for SONET connection termination point (CTP) VT-1.5 on an OC-12 is /sts1_au3-j=2-k=2/vt15_tu11-l=1-m=2.

Higher order transports (HOTs) and paths (HOPs) can ride on VC3(AUG/AU-3) pipes. Lower order paths (LOPs) can ride on VC11(AUG/AU-3/TUG-2/TU-11) pipes.

All pipes have either a J, JK, or JKLM value in the hierarchy. The Optical Circuit Assimilation cartridge models all pipes with full JKLM values, with a value of 0 for any unused indexes. A VC4 pipe with just a J value sets KLM indexes to 0 (for example: 3000). A VC3 pipe with just a JK value sets the LM indexes to 0 (for example: 3200).

Table 7-1 shows the layer rates for different types of cross-connects.

Table 7-1 Cross-Connect Layer Rates by Type

Cross-Connect Type

Layer Rate Code

VC3 (higher order cross-connect)

14

VC11 (lower order cross-connect)

10

Network Boundary Partial Circuit Correction

The Optical Circuit Assimilation cartridge considers a partial circuit as one missing a drop port on either the start-port or the end-port. As such, this cartridge models circuits that leave the network boundary as partial, because port in the circuit that it can trace does not have a drop port.

You can extend the Optical Circuit Assimilation cartridge to model circuits that start or end outside the boundaries of the network or management scope as complete circuits, instead of as partial circuits.

To extend the cartridge to correct partial circuits that start or end at a network or management boundary:

1. Open Design Studio in the Design perspective.

2. Create a Network Integrity cartridge project.

3. Make the cartridge project dependent on the Optical Circuit Assimilation cartridge project.

4. Create an assimilation action.

5. Add the Assimilate Optical Circuits action as a processor in your assimilation action.

6. Create an assimilation processor named Network Boundary Corrector and insert it inside the ForEach processor that models the circuit data (after the Optical Assimilation Circuit Matcher processor).

7. Design the Correct Network Boundary processor to do the following:

- Evaluate whether a partial circuit is truly partial or if the circuit path starts or ends outside the network or management boundary.
You must analyze your inventory or database information or another source of information that the processor uses to determine the boundary.

- Set the circuit path for circuits starting or ending outside the boundary to the complete state.
The modeling processors interprets and models these circuits as complete circuits instead of as partial circuits.

8. Build, deploy, and test your cartridge.
Your new Correct Network Boundary processor is included and run by the Assimilate Optical Circuits action, as shown in Figure 7-3.

Figure 7-3 Network Boundary Partial Circuit Corrector Processor Workflow

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2016, Oracle and/or its affiliates. All rights reserved.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Alpha and Beta Draft Documentation Notice

If this document is in preproduction status:

This documentation is in preproduction status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.

Private Alpha and Beta Draft Documentation Notice

If this document is in private preproduction status:

The information contained in this document is for informational sharing purposes only and should be considered in your capacity as a customer advisory board member or pursuant to your beta trial agreement only. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle.

This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Master Agreement, Oracle License and Services Agreement, Oracle PartnerNetwork Agreement, Oracle distribution agreement, or other license agreement which has been executed by you and Oracle and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced, or distributed to anyone outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.