cc/td/doc/product/ong/15400
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table Of Contents

Release Notes for Cisco ONS 15454
Release 8.0

Contents

Changes to the Release Notes

Changes to Caveats

Caveats

Maintenance and Administration

DWDM Cards

Hardware

Common Control Cards

Optical IO Cards

Electrical IO Cards

Data IO Cards

DWDM Cards

Interoperability

BLSR Functionality

Path Protection Functionality

Alarms

SNMP

TL1

Resolved Caveats for Release 8.0

Maintenance and Administration

Hardware

Electrical IO Cards

DWDM Cards

Bridge and Roll

New Features and Functionality

Common Hardware

MSPP Hardware

MSTP Hardware

New Software Features and Functionality

TL1

Related Documentation

Release-Specific Documents

Platform-Specific Documents

Obtaining Documentation, Obtaining Support, and Security Guidelines


Release Notes for Cisco ONS 15454
Release 8.0


June 27, 2007


Note The terms "Unidirectional Path Switched Ring" and "UPSR" may appear in Cisco literature. These terms do not refer to using Cisco ONS 15xxx products in a unidirectional path switched ring configuration. Rather, these terms, as well as "Path Protected Mesh Network" and "PPMN," refer generally to Cisco's path protection feature, which may be used in any topological network configuration. Cisco does not recommend using its path protection feature in any particular topological network configuration.


Release notes address closed (maintenance) issues, caveats, and new features for the Cisco ONS 15454 SONET multiplexer. For detailed information regarding features, capabilities, hardware, and software introduced with this release, refer to the "Release 8.0" version of the Cisco ONS 15454 DWDM Installation and Operations Guide; and the "Release 8.0" version of the Cisco ONS 15454 Procedure Guide; Cisco ONS 15454 Reference Manual; Cisco ONS 15454 Troubleshooting Guide; and Cisco ONS 15454 SONET TL1 Command Guide. For the most current version of the Release Notes for Cisco ONS 15454 Release 8.0, visit the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/ong/15400/454relnt/index.htm

Cisco also provides Bug Toolkit, a web resource for tracking defects. To access Bug Toolkit, visit the following URL:

http://www.cisco.com/cgi-bin/Support/Bugtool/launch_bugtool.pl

Contents

Changes to the Release Notes

Caveats

Resolved Caveats for Release 8.0

New Features and Functionality

Related Documentation

Obtaining Documentation, Obtaining Support, and Security Guidelines

Changes to the Release Notes

This section documents supplemental changes that have been added to the Release Notes for Cisco ONS 15454 Release 8.0 since the production of the Cisco ONS 15454 System Software CD for Release 8.0.

Added additional caveats for the DWDM hardware section. Added the MSPP-on-a-Blade (ADM-10G) feature description.

Added addational hardware caveats.

Changes to Caveats

The following caveats have been added to the release notes:

CSCsi64440

CSCsi29405

Caveats

Review the notes listed below before deploying the ONS 15454. Caveats with tracking numbers are known system limitations that are scheduled to be addressed in a subsequent release. Caveats without tracking numbers are provided to point out procedural or situational considerations when deploying the product.

Hardware

CSCsg42366

Traffic outage (120 sec) occurs when field-programmable gate array (FPGA) upgrade is done with manual switch on Y-cable and client port is in out of service.

To prevent traffic outage, follow the procedure for the FPGA upgrade:

1. Configure the following:

Near End node, 2 MXP-MR-10DME, Working and Protect, with the Working Active and the Protect Stdby for each protection group supported on the client ports

Same configuration on the Far End node

NE Working card trunk port connected to FE Working card trunk port

NE Protect card trunk port connected to FE Protect card trunk port

2. Ensure traffic is running on the Working cards, for each protection group is supported by the MXP-MR-10DME cards.

3. Issue a Lockout of Protect to ensure traffic does not switch to Protect. Perform this on both NE and FE protection groups.

4. Disable client ports on the Protect cards and complete Manual FPGA upgrade. The upgrade should be hitless since traffic is accommodated on the Working facilities.

5. Once the card has completed SW reset, move back client ports to IS-NR state. Ensure no unexpected alarm/condition is present on the Protect cards.

6. Release Lockout of Protection on both ends, on every protection group. This operation is not traffic affecting. Traffic is still carried on Working facilities.

7. Issue a Force to Protect on both NE and FE protection groups so that traffic switches from Working to Protect facilities. Do this on every protection group supported by these cards. The Force to Protect switching is affecting traffic(<50ms).

8. Disable client ports on the Working cards and complete Manual FPGA upgrade. The upgrade should be hitless since traffic is accommodated on the Protect facilities.

9. Once the card has completed SW reset, move back client ports to IS-NR state. Ensure no unexpected alarm/condition is present on the Working cards.

10. Release Force to Protect on both ends, on every protection group. If the protection group is revertive, this operation will revert traffic to Working facilities. Less than 50ms hits are expected. The operation will keep traffic on Protect facilities if the protection group is non-revertive, hitless.

OC-48 IR 1310 Card Not Supported

The OC-48 IR 1310 card is not supported in the 8.0 release. These cards should be removed from the system before upgrading.

CSCsi64440

A software upgrade from a release prior to 8.0, to 8.0 causes a multi-second outage on the DS3XM-12 card in slots 1,3,5,12,14,16, when XC or XCVT cross connect cards are installed.

A software upgrade from a release prior to 8.0, to 8.0 causes a complete outage on the DS3XM-12 cards in protect slots 2,4,6,13,15,17, when XC or XCVT cross connect cards are installed.

A soft reset in 8.0 causes multi-second outage on the DS3XM-12 card in the slots 1,3,5,12,14,16 when the active XC or XCVT cross connect cards is in slot 8.

A total outage of the DS3XM-12 card in slots 1,3,5,12,14,16 occurs when the active XC or XCVT cross connect card is in slot 10. A hard reset will clear the problem, but a further soft reset will cause an outage again.

A soft reset in 8.0 causes a multi-second outage on the DS3XM-12 card in protect slots 2,4,6,13,15,17 when the active XC or XCVT cross connect card is in slot 10.

A total outage of the DS3XM-12 card in protect slots 2,4,6,13,15,17 occurs when the active XC or XCVT cross connect card is in slot 8. A hard reset will clear the problem, but a further soft reset will cause an outage again.

There is no workaround when using DS3XM-12 and XC or XCVT cross connect cards. Replacing the XC or XCVT with a XC10G or XC-VXC-10G cross connect cards resolves this problem. This will be fixed in a future release.

CSCuk44284

An optical connector and optical attenuators inserted into the SFP may force the fiber against the shelf door when it is closed. Use the following types of optical connectors and optical attenuators when connecting to the SFP:

Optical connectors: The length of the connector (starting from the ferule tip) plus the fiber boot must be 50 mm or shorter.

Optical Attenuators: The following attenuator Cisco P/Ns are recommended:

39-0228-XX

39-0229-XX

39-0230-XX

CSCsg35496

When slot 17 is switched in 1:N protection for the first time, slot 16 is switched. This issue was observed in Release 7.04 and occurs only at the first-time switch.

CSCse67377

AIS-L Alarm is not visible against EC1 port, if LOS or LOF is injected onto the port. EC1 port is in service and there is no circuit present. This is a hardware limitation which detects AIS-L received from line side, but it cannot raise AIS-L when it receives LOS or LOF from the line.

Jitter Performance with XC10G

During testing with the XC10G, jitter generation above 0.10 UI p-p related to temperature gradient testing has been observed. This effect is not expected to be seen under standard operating conditions. Changes are being investigated to improve jitter performance in a future release. Tracking numbers related to this issue include CSCdv50357, CSCdv63567, CSCdv68418, CSCdv68441, CSCdv68389, CSCdv59621, and CSCdv73402.

CSCdz49928

When using KLM type fuses with specific types of fuse and alarm panels, the PWR-REDUN alarm may not be displayed once the fuse is blown. A KLM fuse does not have a blown fuse indicator built into it. As a result, the blown fuse detection circuitry on the FAP may continue to provide voltage on its output despite a blown fuse.

CSCsi78715

When loss of signal (LOS) occurs on the client side of MXP-MR-2.5G card, the Y-cable protection switch does not occur and drops the traffic. The MXP-MR-2.5G will not report generic framing procedure (GFP) alarms such as client signal fail (CSF) and in case of fiber channel client, the link recovery counter will not be incremented correctly.

Workaround is to manually switch the traffic away from the client experiencing LOS. This will be fixed in a future release.

CSCsi29405

The 15454-FTA3 Fan Tray Assemblies have an electrical noise problem that might cause communications failures between the fan tray and the controller cards. Eventually this condition causes fan tray alarms, and the controller card resets. Also, the LCD might display meaningless characters and the buttons on the LCD will not function normally. Running the fan tray at high speed decreases the noise and prevents the communication failure and the card reset. The workaround is to remove one of the fans, which will cause the fans to run at full speed. This will be fixed in a future release.

Maintenance and Administration


Caution VxWorks is intended for qualified Cisco personnel only. Customer use of VxWorks is not recommended, nor is it supported by Cisco's Technical Assistance Center. Inappropriate use of VxWorks commands can have a negative and service affecting impact on your network. Please consult the troubleshooting guide for your release and platform for appropriate troubleshooting procedures. To exit without logging in, enter a Control-D (hold down the Control and D keys at the same time) at the Username prompt. To exit after logging in, type "logout" at the VxWorks shell prompt.


Note CTC does not support adding/creating more than 5 circuits in auto-ranged provisioning. This is as designed.



Note In releases prior to 4.6 you could independently set proxy server gateway settings; however, with Release 4.6.x and forward, this is no longer the case. To retain the integrity of existing network configurations, settings made in a pre-4.6 release are not changed on an upgrade to Release 7.x. Current settings are displayed in CTC (whether they were inherited from an upgrade, or they were set using the current GUI).


CSCsc00811

Deleting a monitor circuit and its parent at the same time might result in a PARTIAL parent circuit. To avoid this, delete the monitor circuit before deleting the parent circuit. This issue will not be resolved

CSCsc36281

The software Activating progress popup window might fail to automatically close during multiple or parallel software activations. If this occurs you must manually close the popup window. The following error message might also be raised and need to be closed:

"EID-3251 Unable to complete requested action. Unable to activate because the working software version is newer than the protect one."

To ensure that all nodes are using the correct software version you should close and restart CTC. This issue will be resolved in a future release.

CSCsh02230

If IOS CLI is used to configure Timezone and DST rule configuration then the output shown in the show running config command and show clock detail differ from what was configured. To avoid this issue it is recommended to use CTC provisioning tab to configure clock related provisioning. This issue will be resolved in a future release.

CSCse04103

Applying the forced switch/manual switch on protect facility when no protection switch in operation, FRCDWKSWBK-NO-TRFSW/MANWKSWBK-NO-TRFSW is not raised for 1+1. There is no workaround for this issue.

CSCse87943

RFI-P is raised on both Working and Protect path in a 1+1 topology on an ONS 15310-MA. This occurs with an ML card with an STS cross connection with another ML card in another chassis and when the POS port on the 15310 MA side is shut down. There is no workaround for this issue.

CSCse38590

In the RPR topology, one station reports a "remote WTR" on a space, even though the neighboring station is not advertizing WTR. This issue is observed after many XC pulls/switches, deleting and recreating circuits, and replacing cross connects completely. This issue does not appear to have any real impact to traffic, but can potentially complicate troubleshooting. This problem was seen after multiple XC-pulls, XC-side-switches, circuit-deletions and circuit-creations. The workaround is to configure a forced-switch on both ends of the problem span, and then remove the forced-switch from both ends.

CSCsd44081

A series of crashes and reboots may occur when a policy-map includes approximately 200 class-map entries and policers. This error appears to occur when the card is boots up, the FPGA process is attempting to download the new FPGA, the policy-map has at least 200 class-map entries, and traffic has been punted to the host. These conditions may trigger a provisioning-message timeout on the ML card that can lead to a crash. Since the system boots up in the same state, a continuous series of crashed and reboots may occur. A workaround is to remove the circuits and wait until the node boots up with the latest FPGA image before reconfiguring the circuits.

CSCse23518

The RPR SPAN-MISMATCH alarm is not reported correctly in some situations. After creating and deleting an East-to-East RPR circuit through TL-1 x-connects and creating a West-to-West RPR circuit through the TL-1 x-connects script, both within less than on second of the other, the RPR-SPAN-MISMATCH alarm is seen only on one side of the circuit and not on the other side. This problem does not occur when the operations are made manually. This alarm indicates mis-cabling or cross-connects created between two East spans or two West spans. A workaround is to ensure more than one second between the deletion of one circuit and creation of the another.

CSCse75851

Tracebacks are seen in "show tech" or "show ons alarm defect" output for ML100T-8 on the ONS 15310-CL after logging in through the CTC by way of the IOS CLI. This issue does not occur when these commands are issued through the console. The workaround is to ignore these tracebacks because they do not impact the functioning of the data card.

CSCse90514

The soak timer on POS port reduces which is not an expected behavior after creating a circuit on a POS port that is kept in OOS state. There is no workaround for this issue.

CSCse58432

Upgraded splitter OCHCC has OCHTRAILs shown as OOS[PARTIAL]. When upgrading a splitter-protected OCHCC 7.01 to 8.0, in 8.0 the OCHTRAIL circuits are reported as OOS[PARTIAL]. Indeed the two terminal nodes (Source and Destination) report state as OOS,DSBLD. TL1 and TCC report their states as IS-NR.

CSCsg29444

On rare occasions, the STM64 4-port DWDM card may into continuous resets after a node power down. A hard reset of the card usually brings it up normal.

CSCsd00882

In an IDRI setup, with an exiting SRG Violation between one of the rings and the IDRI hand-off spans, the SRG Violation Warning prints the same span twice. This happens only when the circuit is routed manually on a BLSR-path protection or a path protection DRI/IDRI. The functionality of the Circuit Routing is as expected. The one violation gets printed twice because the DRI span traverses twice.

CSCse96118

RTRV-COND-STS does not display path alarms on BLSR protect path. When BLSR is switched onto protection and the protect paths have conditions on them, the TL1 retrieval command does not show those conditions on protection paths.

CSCse53133

RTRV-COND-STS does not display path alarms on BLSR protect path. When BLSR is switched onto protection and the protect paths have conditions on them, the TL1 retrieval command does not show those conditions on protection paths.

CSCsb88234

When a card is provisioned and a filler card is plugged in, a DBCHG with ENT-EQPT is sent, but when a filler card is plugged in without a prior provision there is no plug-in message. Similarly, there is no message upon removal of the filler card. The workaround for TL1-NONE, is to issue an inventory call and the filler card appears. For CTC, the card is displayed and removed when the card is removed.

CSCsg03334

After ML card reset, system comes up with POS0=PSAS true. When nodes from Release 6.2 are activated with ML V-up enabled and there is a soft reset of the ML cards to clear SW-MISMATCH, the ML cards come up with PSAS on for POS 0. Consequently, the port does not report any alarms (only conditions) for eight hours. The NE Default is off for PSAS, so POS 0 should not have PSAS on. The workaround is to manually reset PSAS flag to FALSE.

CSCsg10963

Connections remain in OOS-AU,FLT after roll is cancelled. This occurs under the following conditions:

1. Create OC48/OC192 2F-BLSR ring among three Cisco ONS 15454 SDHs.

2. Create five STS1 2F-BLSR circuits from Cisco ONS 15454 Node 1 to Cisco ONS 15454 Node 2. All connections enter IS-NR state.

3. Perform bulkroll to roll all connections from East port to West port. Roll is not complete. UNEQ-P alarms are raised for rollTo paths. Connection states change to OOS-AU,FLT.

4. Cancel roll.

UNEQ-P alarms clear and connection states remain OOS-AU,FLT.

CSCsg16500

ROLL-PEND condition is seen for VT circuits on the CTC conditions pane.

1. Create a two-node OC12 unprotected setup among two Cisco ONS 15454 SDHs.

2. Create 1 VT circuit from Cisco ONS 15454 SDH node 1, OC3 card to Cisco ONS 15454 node 2, OC12 card.

3. Give autobulkroll to circuit on the OC12 span from STS#1 to STS#4.

4. Force the valid signal using ED-BULKROLL command to "true." Bulkroll completes and no rolls are present on any of the nodes.

The ROLL-PEND condition is now visible on VT circuits in CTC, TL1.

CSCsg32263

When DBCHG messages are turned on by using the ALW-MSG-ALL command, there is no DBCHG message when creating and then deleting a proxy firewall tunnel. This issue will be resolved in a future release.

CSCse22576

CTC BLSR views not updated properly after consecutive ENT-MSSPR commands. After entering 16 consecutive ENT-MSSPR TL1 commands across three nodes, the CTC does not update the NetView > BLSR table. The workaround is to restart the CTC so it shows the screens properly. This issue will be resolved in a future release.

CSCse91968

The AINS-to-IS transition on BLSR 4F Protect not functioning properly. When a BLSR 4fibre ring is used, the AINS-to-IS transition is not correct when protect is active (ring switched). Sometimes the wrong protect is transitioning at the IO. If the TSC is notified incorrectly, it becomes out of sync with the IO, and becomes stuck in AINS, even when the protect switch is released. The PCA is also being incorrectly notified of an AINS-to-IS transition. This issue will be resolved in a future release.

CSCse92248

System does not declare TIM-P or retrieves received J1 Path Trace value on switched BLSR. With BLSR switched onto the protect. With the J1 path trace value changed on one node, the receiving node is not retrieving the new J1 Path Trace value and, therefore, is not raising the TIM-P alarm. This issue will be resolved in a future release. This issue will be resolved in a future release.

CSCsf01901

Standby TSC may continuously reboot and Node may loose visibility when there is a huge number of alarm transitions on the node for more than an hour. The standby TSC should be hard reset and the visibility will be regained. This issue will be resolved in a future release.

CSCsf96856

Database Restore may fail with a large database. When restoring a large database with full-capacity cross connects, alarms, and PM databases, the restoration through CTC may fail with an error. A workaround is to attempt the database operation again and it usually succeeds. This issue will be resolved in a future release.

CSCsg00090

There is no response when command "RTRV-TH-STS1::all:1;" is issued. Expected behavior is a DENY response with the correct error message or COMPLD response with the appropriate threshold values displayed. This issue will be resolved in a future release.

CSCsg16680

RTRV-PM-<mod2_path> does not display any PM counts for ALL aid. The TL1 command is COMPLD, but nothing displays. This issue arises when 2F-BLSR circuits are provisioned with IPPM enabled and B3 errors are injected and where some PM counts are generated. Then, STS12c circuits are created and the command RTRV-PM-STS12c::all:1 is executed. Otherwise, RTRV-PM-ALL works fine, and RTRV-PM-<mod2_path> with individual AID works normally.

CSCsg13597

After pulling line cards out of shelves involved in the DCC between nodes a EOC alarm was raised and did not clear after the cards were re-inserted.

DWDM Cards

CSCsg22669

There is a traffic hit of greater than 50ms but less than 60 ms on MXP-2.5G-10E in Y cable configuration when a fiber cut occurs.

CSCsf04299

When triggering the switch of optimized 1+1 protection and the failure is cleared, the WTR condition is raised, but once the WTR time expires the switch back of protection is not triggered. A workaround is to manually force back the protection.

CSCse97200

On ADM-10G, attempts to preprovision local and express orderwire circuits on trunk port are not successful. E1/E2 orderwire is not supported.

Hardware

CSCse74522

The LAN front panel LEDs of the standby TCC were switched OFF (i.e. no lights, port disabled). Multishelf MSTP with SSC connected to the Node Controller via Catalyst 3750.

Mismatch Equipment Attributes Alarm on EIA

In Release 6.0 a Mismatch Equipment Attributes (MEA) alarm is raised incorrectly against the B-Side BIC (EIA) on an ONS 15454 node using the 15454-SA-HD (high density) chassis with 1BNCB48, 1BNCB24, or 1SMBB84 EIAs installed. The 1BNCB48, 1BNCB24, and 1SMBB84 EIA panels are compatible with the 15454-SA-HD shelf assembly; however, the software in Release 6.0 fails to recognize their compatibility. The MEA alarm raised as a result of this issue is not service impacting, but does cause a standing alarm.

As a workaround to the standing alarm, you can change the BIC-MEA alarm severity by creating and using a custom alarm profile following the steps that apply for your network in the NTP-A71 Create, Download, and Assign Alarm Severity Profiles procedure of the Manage Alarms chapter in the Cisco ONS 15454 Procedure Guide, Release 6.0. This issue will be resolved in Release 6.1.

CSCeh84908

A CTC client session can disconnect from an ONS node during simultaneous deletion of large numbers of VT level circuits (3000+). Connectivity to the node will recover without any user action. If the condition persists, restart the CTC session to reconnect. This issue is under investigation.

CSCei36415

When retrieving GBIC inventory for the FC_MR-4, nothing is returned for the CLEI code. In a future release, enhanced inventory information will be available for ONS GBICs. This will include the CLEI code.

CSCeh92201

When you create a bidirectional BLSR-path protection IDRI circuit using autorouting and select the PCA option for secondary spans, the circuit is created over working BLSR spans and does not use PCA spans. To enforce the use of the PCA option, provision the circuit using manual routing. This issue will not be resolved.

CSCee96164

The Wait To Restore (WTR) alarm does not appear to be raised for as long as the WTR timer is set for. The WTR is raised correctly, but the alarm is hidden for the first 12 seconds due to the clear soaking time for a CLDRESTART alarm. You can see this behavior if you set up a 1+1 bidirectional revertive protection group, remove the working card, and then reinsert the card. There are no plans to change this behavior.

CSCee25136

If you create a PM schedule with the Start time for the PM report equal to 00:00 (in TL1, "0-0"), after a few minutes the PM report start time might change to 23:59 (in TL1, "23-59"). This issue will not be resolved.

CSCed23484

A user might remain in the logged-in state after rebooting the PC while logged into a node running CTC. The user login will time out once the "Idle User Timeout" limit is up. Alternatively, you can log in as a superuser and force the user off. This issue will not be resolved.

CSCds88976

When a new circuit is created around a ring (path protection or BLSR), the SD BER or SF BER alarm can be raised depending on the order in which the spans are provisioned. The alarms will eventually clear by themselves. Traffic is not affected. This issue will not be resolved.

CSCdu82934

When you auto-route a VT circuit on an ONS 15454 node, a path is computed based on the availability of STSs on the nodes involved. This selection process, when combined with a lack of VT matrix (or STS-VT connections) on an auto-route selected node, can result in the VT circuit creation failing with the message "unable to create connection object at node." To correct this situation, manually route VT circuits in cases when auto-routing fails. The error message will indicate which node is at issue.

CSCef28522

When you inject errors on a splitter protection card in the node's working port, CVL and ESL are incremented for the working and protect far end ports. This issue will not be resolved.

CSCuk49106

The amplifier gain set point shown by CTC and the actual measured amplifier gain differ. The following steps illustrate this issue.


Step 1 Reduce the insertion loss of the span just before the amplifier.

Step 2 Execute the APC procedure.


The APC procedure does not check consistency between the gain set point and the real gain, but rather only verifies the amplifier total output power. As a workaround, manual setting can be performed to align these values, although the discrepancy does not impact the normal functioning of the amplifier. This issue will not be resolved.

CSCef05162

Clearing the displayed statistics for a port will also clear the displayed history for that port. Clearing the displayed statistics for all ports will also clear the displayed history for all ports. There is no warning message from the TCC2. If History information is to be retained, do not clear displayed statistics for any port without first documenting the displayed history information for the associated port. This issue will not be resolved.

CSCef29516

The ALS pulse recovery minimum value is 60 instead of 100. If this occurs, increase the value to 100. This issue will not be resolved.

CSCeb36749

In a Y-Cable configuration, if you remove the client standby RX fiber; a non-service affecting LOS is raised, as expected. However, if you then remove the trunk active RX fiber; a non-service affecting LOS-P is raised, but the previously non-service affecting LOS on the client port is now escalated to a service affecting alarm, in spite of no traffic having been affected. This issue will not be resolved.

CSCee82052

After setting the node time (either manually or via NTP) you must wait for the endpoint of the interval to be reached before the end time will reflect the recently-set node time. Until this has occurred, the date time stamp for the end of the retrieved interval remains 12/31/69. This issue has been closed and will not be resolved.

CSCdx35561

CTC is unable to communicate with an ONS 15454 that is connected via an Ethernet craft port. CTC does, however, communicate over an SDCC link with an ONS 15454 that is Ethernet connected, yielding a slow connection. This situation occurs when multiple ONS 15454s are on a single Ethernet segment and the nodes have different values for any of the following features:

Enable OSPF on the LAN

Enable Firewall

Craft Access Only

When any of these features are enabled, the proxy ARP service on the node is also disabled. The ONS 15454 proxy ARP service assumes that all nodes are participating in the service.

This situation can also occur immediately after the aforementioned features are enabled. Other hosts on the Ethernet segment (for example, the subnet router) may retain incorrect ARP settings for the ONS 15454s.

To avoid this issue, all nodes on the same Ethernet segment must have the same values for Enable OSPF on the LAN, Enable Firewall, and Craft Access Only. If any of these values have changed recently, it may be necessary to allow connected hosts (such as the subnet router) to expire their ARP entries.

You can avoid waiting for the ARP entries to expire on their own by removing the SDCC links from the affected ONS 15454 nodes. This will disconnect them for the purposes of the proxy ARP service and the nodes should become directly accessible over the Ethernet. Network settings on the nodes can then be provisioned as desired, after which the SDCC can be restored.

This issue will not be resolved.

CSCdy56693

Microsoft Windows XP uses more memory than previous Microsoft operating systems, and this may result in reduced CTC performance. To avoid reduced performance, you can:

Limit the number of nodes you log into

Avoid or limit bulk operations

Avoid bulk circuit deletion

Prevent CTC's discovery of DCC connected nodes by using the login "Disable Network Discovery" feature

Prevent CTC's discovery of circuits unless needed by using the login "Disable Circuit Management"

CSCdy62092

When a node connected via SDCC has no Ethernet LAN connectivity, display of SDCC termination alarms is delayed if the fiber connecting a DCC connected node is removed. This issue cannot be resolved.

CSCdy10030

CVs are not positively adjusted after exiting a UAS state. When a transition has been made from counting UAS, at least 10 seconds of non-SES must be counted to exit UAS. When this event occurs, Telcordia GR-253 specifies that CVs that occurred during this time be counted, but they are not. There are no plans to resolve this issue at this time.

CSCdy11012

When the topology host is connected to multiple OSPF areas, but CTC is launched on a node that is connected to fewer areas, the topology host appears in CTC, and all nodes appear in the network view, but some nodes remain disconnected. This can occur when the CTC host does not have routing information to connect to the disconnected nodes. (This can happen, for example, if automatic host detection was used to connect the CTC workstation to the initial node.)

CTC will be able to contact the topology host to learn about all the nodes in all the OSPF areas, but will be unable to contact any nodes that are not in the OSPF areas used by the launch node. Therefore, some nodes will remain disconnected in the CTC network view.

To work around this issue, if no firewall enabled, then the network configuration of the CTC host can be changed to allow CTC to see all nodes in the network. The launch node must be on its own subnet to prevent network partitioning, and craft access must not be enabled. The CTC host must be provisioned with an address on the same subnet as the initial node (but this address must not conflict with any other node in the network), and with the default gateway of the initial node. CTC will now be able to contact all nodes in the network.

If a firewall is enabled on any node in the network, then CTC will be unable to contact nodes outside of the initial OSPF areas. This issue will not be resolved.

NE Defaults

The following caveats apply for NE defaults when managing older, pre-Release 4.5 nodes.

OC12-4 allows provisioning of PJStsMon from 0 to 48. The workaround is to limit provisioning to between Off and 1 to 12 only.

CTC displays "PJStsMon=off" in the standard provisioning pane when provisioning PJStsMon off; however, TL1 and the NE Defaults editor both display 0 for this same condition.

If you only make changes to a single default in the NE defaults editor, you must click on another default or column before the Apply button becomes functional.

ONS 15454 Conducted Emissions Kit

If you are deploying the Cisco ONS 15454 within a European Union country that requires compliance with the EN300-386-TC requirements for Conducted Emissions, you must obtain and install the Cisco ONS 15454 Conducted Emissions kit (15454-EMEA-KIT) in order to comply with this standard.

CSCdv10824: Netscape Plugins Directory

If you use CTC, JRE, and the Netscape browser with a Microsoft Windows platform, you must ensure that any new installation of Netscape uses the same Netscape directory as the previous installation did, if such an installation existed. If you install Netscape using a different path for the plugins directory, you will need to reinstall JRE so that it can detect the new directory.

"Are you sure" Prompts

Whenever a proposed change occurs, the "Are you sure" dialog box appears to warn the user that the action can change existing provisioning states or can cause traffic disruptions.

Common Control Cards

CSCdw27380

Performing cross connect card switches repeatedly might cause a signal degrade condition on the lines or paths that can trigger switching on these lines or paths. If you must perform repeated cross connect card switches, lock out the corresponding span (path protection, BLSR, or 1+1) first. This issue will not be resolved.

Active Cross Connect (XC10G/XCVT) or TCC2/TCC2P Card Removal

You must perform a lockout in BLSR, path protection, and 1+1 before physically removing an active cross connect (XC10G/XCVT) or TCC2/TCC2P card. The following rules apply.

Active cross connect (XC10G/XCVT) cards should not generally be physically removed. If the active cross connect or TCC2/TCC2P card must be removed, you can first perform an XCVT/XC10G side switch or TCC2/TCC2P reset and then remove the card once it is in standby, or you can perform a lockout on all circuits that originate from the node whose active cross connect or active TCC2/TCC2P will be removed (performing a lockout on all spans will also accomplish the same goal). No lockout is necessary for switches initiated through CTC or through TL1.


Caution If you mistakenly remove an active TCC2/TCC2P card and you subsequently lose traffic on some interface cards, you may need to physically reset these cards if they fail to regain traffic.

Ethernet Polarity Detection

The TCC2/TCC2P does not support Ethernet polarity detection. The TCC+ and TCCI both support this feature. If your Ethernet connection has the incorrect polarity (this can only occur with cables that have the receive wire pairs flipped), the TCC+/I will work, but the TCC2/TCC2P will not. In this event, a standing condition, "LAN Connection Polarity Reverse Detected" (COND-LAN-POL-REV), will be raised (a notification will appear on the LCD, and there will be an alarm raised). This issue will most likely be seen during an upgrade or initial node deployment. To correct the situation, ensure that your Ethernet cable has the correct mapping of the wire wrap pins. For Ethernet pin mappings, consult the user documentation.

Optical IO Cards

CSCei26718

On the 15454_MRC-12, when a one way VT/VC circuit on path protection over 1+1 protection is

created, the alarm behavior is not the same as in two way circuit creation. In particular, for the one way circuit creation, UNEQ-V and PLM-V alarms are reported, and the circuit state remains OOS. This issue will not be resolved.

CSCdw66444

When an SDH signal is sent into an ONS 15454 OC-12/STM-4 (IR, 1310 LR and 1550 LR) or an OC-48/STM-16 high-speed (IR and LR) port which has been configured to support SDH, an SD-P (Signal Degrade) alarm will appear as soon as the circuit is created. This alarm will continue to exist until the circuit is deleted.

To avoid this problem, when provisioning an OC-12/STM-4 (IR, 1310 LR and 1550 LR) or an OC-48/STM-16 high-speed (IR and LR) port to support SDH, disable the signal degrade alarm at the path level (SD-P) on the port.

Also, PM data at the path level will not be reliable. You must set associated threshold values to 0 in order to avoid threshold crossing alerts (TCA) on that port. The path threshold values to set to zero are CV-P, ES-P, SES-P, and UAS-P.

These issues are the result of a hardware limitation, and there are no current plans to resolve them.

CSCdw09604

If you are using an XC10G with OC-48, you must use either OC-48AS or OC-48 cards with a revision number higher than 005D.

Electrical IO Cards

CSCsc65320 and CSCin92295

In a DS3-EC1-48 1:N protection group for which a path protection circuit drops onto a 1:N protected card, if you remove the card and then reseat it the switch time might exceed 60 ms. This issue will be resolved in a future release.

CSCei59527

When an XC switch occurs, LOF is driven to the line side. On a DS1-14 this can cause us to see long switch times that are related to hardware issues if the "Treat LOF as a Defect" flag has been set. To avoid this issue, do not set the "Treat LOF as a Defect" flag to true on DS1-14 cards. A future release will remove the "Treat LOF as a Defect" option for this card.

CSCeh43011

An LOS alarm is cleared when switching to protect when the working card is on opposite side of the shelf from the protect card (in portless configuration) in a DS3XM-12 1:N protection group. An electrical port brought into IS state on the portless only card produces an LOS alarm. If you then switch to protect, the alarm appears to clear. To avoid this issue, do not bring electrical ports into IS state on a portless only card. This issue will be resolved in a future release.

CSCdx40300

A transient WKSWPR condition is raised upon deletion of a DS3XM 1:1 protection group. This issue will be resolved in a future release.

CSCec39567

Deleting a DS3I 1:N protection group may leave the protect card LED in a standby state. This can occur in a DS3I 1:N protection group with a LOCKON applied to the working card (ONS 15454 ANSI chassis only). Upon deleting the protection group, the LED on the protect DS3I card and the CTC display are still in the standby state. Soft reset the protect card to update the LED on the card and in CTC. An alternative workaround is to remove the LOCKON before deleting the protection group. This issue will be resolved in a future release.

Data IO Cards

SONET and SDH Card Compatibility

Tables 1, 2, and 3 list the cards that are compatible for the ONS 15454 SONET and ONS 15454 SDH platforms. All other cards are platform specific.

Table 1 SDH Data Cards that are SONET Compatible 

Product Name
Description

15454E-G1000-4

4 port Gigabit Ethernet Module - need GBICs

15454E-E100T-12

12 port 10/100BT Ethernet Module

15454E-E1000-2

2 port Gigabit Ethernet Module - need GBICs

15454E-ML100T-12

10/100 Mbps Ethernet card, 12 ports, RJ-45, L2/L3 switching, SDH/ETSI system, includes console cable

15454E-ML1000-2

1000 Mbps Ethernet card, 2 SFP slots, L2/L3 switching, SDH/ETSI system


Table 2 SONET Data Cards that are SDH Compatible 

Product Name
Description

CE-1000-4

4 port 1000-Mbps Gigabit Ethernet module

CE-100T-8

8 port 10/100FE Ethernet module

15454-G1000-4 

4 Port Gigabit Ethernet

15454-E100T-G 

10/100BT, 12 circuit, compatible w/ XC, XCVT and XC10G

15454-E1000-2-G 

Gigabit Ethernet, 2 circuit, GBIC - G

15454-ML100T-12

10/100 Mbps Ethernet card, 12 ports, RJ-45, L2/L3 switching, SONET/ANSI system, includes console cable

15454-ML1000-2

1000 Mbps Ethernet card, 2 SFP slots, L2/L3 switching, SONET/ANSI system


Table 3 Miscellaneous Compatible Products 

Product Name
Description

15454-BLANK 

Empty slot Filler Panel

15454-GBIC-LX 

1000Base-LX, SM or MM, standardized for 15454/327

15454-GBIC-SX 

1000Base-SX, MM, standardized for 15454/327

15454-FIBER-BOOT= 

Bag of 15 90 degree fiber retention boots

15454-SFP-LC-SX

1000BASE, SX, short-reach, multimode, small form factor pluggable (SFP), LC connectors

15454-SFP-LC-LX

1000BASE, LX, long-reach, single mode, SFP, LC connectors

15454-CONSOLE-02

Cable, console, ML-Series, RJ-11 plug to RJ-45 jack, 22in/55.9cm long, SONET/ANSI system

15454E-CONSOLE-02

Cable, console, ML-Series, RJ-11 plug to RJ-45 jack, 22in/55.9cm long, SDH/ETSI system


CSCsc11981

Under certain circumstances, E-series cards might learn invalid MAC addresses and temporarily lose well-known/static addresses, possibly resulting in high flood rates. This issue can occur when traffic flows through an E-series card and there are no MAC addresses currently in the MAC table for that E-series card (for instance, after you have cleared the complete MAC table, or when the node is just coming up). The chipset can cause the E-series card to learn invalid addresses in this scenario under high rates of flood traffic (multicast, broadcast, unknown) or PHY interface noise. Side-effects of clearing the MAC table when traffic is flowing can cause the E-series card to lose well-known/static MAC addresses along with dynamically learned MAC addresses. This can cause high flood rates (multicast, broadcast, unknown) possibly reaching the limitation described in the following field notice:

http://www-tac.cisco.com/Support_Library/field_alerts/fn13171.html

This issue can last for a few seconds (typically less). The workaround is to avoid issuing any operation (such as the "Clear all MAC" command) that clears the complete MAC table under heavy traffic loads. To recover from this issue, wait for a few seconds to let the invalid addresses age out, and to allow the software to restore the well-known/static MAC addresses.

CSCdy37198

On Cisco ONS 15454s equipped with XCVT cross-connect cards, neither the E100T-12 nor the E1000-2 cards raise an alarm or condition in CTC when Ethernet traffic is predictably lost due to the following circumstances:

Circuits exist between Ethernet cards (E100T-12 and/or E1000-2) built over Protection Channel Access (PCA) bandwidth on BLSR spans. When BLSR issues a switch, the PCA bandwidth is preempted. Since there is no longer a connection between the ends of the Ethernet circuit, traffic is lost.


Note In nodes equipped with XC10G, these Ethernet cards will raise an AIS-P condition.


This issue will not be resolved.

CSCdr94172

Multicast traffic can cause minimal packet loss on the E1000-2, E100-12, and E100-4 cards. Packet loss due to normal multicast control traffic should be less than 1%. This issue was resolved in Release 2.2.1 for broadcast, and in Release 2.2.2 for OSPF, and some multicast frames. As of Release 3.0.3, the ONS 15454 supports HSRP, CDP, IGMP, PVST, and EIGRP, along with the previously supported broadcast and OSPF.


Note If multicast is used for such applications as video distribution, significant loss of unicast and multicast traffic will result. These cards were not designed for, and therefore should not be used for, such applications.



Note If the multicast and flood traffic is very rare and low-rate, as occurs in most networks due to certain control protocols and occasional learning of new MAC addresses, the loss of unicast frames will be rare and likely unnoticeable.



Note A workaround for this issue is to use the port-mapped mode of the E-series cards.


Multicast MAC addresses used by the control protocols in Table 4 have been added to the static MAC address table to guarantee no loss of unicast traffic during normal usage of these MAC addresses.

Table 4 Protocols Added to the MAC Address Table

Protocol
Release Protocol Introduced In

Broadcast MAC (used by many protocols)

2.2.1

Open Shortest Path First (OSPF)

2.2.2

Cisco Discovery Protocol (CDP)

2.2.2

Per-VLAN Spanning Tree (PVST)

2.2.2

Enhanced Interior Gateway Routing Protocol (EIGRP)

2.2.2

Internet Group Management Protocol (IGMP)

2.2.2

Hot Standby Routing Protocol (HSRP)

3.0.3


E1000-2/E100T

Do not use the repair circuit option with provisioned stitched Ethernet circuits.This issue is under investigation.

Single-card EtherSwitch

Starting with Release 2.2.0, each E100/E1000 card can be configured as a single-card EtherSwitch configuration to allow STS-12c of bandwidth to be dropped at each card. The following scenarios for provisioning are available:

1. 12c

2. 6c, 6c

3. 6c, 3c, 3c

4. 6c, six STS-1s

5. 3c, 3c, 3c, 3c

6. 3c, 3c, six STS-1s

7. Twelve STS-1s

When configuring scenario 3, the STS-6c must be provisioned before either of the STS-3c circuits.

Multicard EtherSwitch

When deleting and recreating Ethernet circuits that have different sizes, you must delete all STS circuits provisioned to the EtherSwitch before you create the new circuit scenario. (See the preceding "Single-card EtherSwitch" section for details on the proper order of circuit creation.) Enable front ports so that the VLANs for the ports are carried by the largest circuit first. A safe approach is to enable the front port before you create any circuits and then retain the front port VLAN assignment afterwards. If you break the rules when creating a circuit, or if you have to delete circuits and recreate them again, delete all circuits and start over with the largest first.

CSCds02031 E1000-2/E100

When you drop two 3c multicard EtherSwitch circuits onto an Ethernet card and delete only the first circuit, you should not provision STS-1 circuits to the card without first deleting the remaining STS-3c circuit. If you attempt to create an STS-1 circuit after deleting the first STS-3c circuit, the STS-1 circuit will not work and no alarms will indicate this condition. Under rare conditions, this could trigger a TCC reset. To avoid a failed STS-1 circuit and other possible problems, delete the second STS-3c prior to creating any STS-1 circuit.

CSCed96068

If an ML-Series card running Software Release 4.6.2 or later is interoperating with an ML-Series card running Software Release 4.6.0 or 4.6.1, then the pos vcat resequence disable command must be added to the configuration of the ML-Series card running R4.6.2 or later. For documentation of this command, consult the Ethernet Card Software Feature and Configuration Guide.

CSCec52443

On an ML-series RPR ring circuit deletion or creation causes an approximately 200 ms traffic loss. To avoid this issue, from the ML-series CLI, perform a "shutdown" on both ends of the circuit prior to circuit changes. This issue will not be resolved.

CSCec52372

You must issue a "shut" command to both ends of a POS circuit before placing the circuit OOS, and issue IS before a "no shut" command. Placing a POS circuit OOS without shutting down can cause long traffic hits. This issue will not be resolved.

CSCec51252

You must issue a "shut" on both ends of affected POS circuits before performing a maintenance action on those circuits. If a POS circuit is restored without first issuing the shut commands, one end of the circuits could come up before the other. During that time, traffic is lost because the other end is not up yet. This issue will not be resolved.

CSCea46580

SPR input counters do not increment on a BVI with an SPR interface. This issue will not be resolved.

CSCea35971

A monitor command may disappear from the configuration after a TCC reboots. To avoid this issue, use the exec command, "terminal monitor," instead (a minor drawback is that this command applies to all VTYs), or, alternatively, reapply the monitor command after connection is lost. This is as designed.

CSCdz49700

The ML-series cards always forward Dynamic Trunking Protocol (DTP) packets between connected devices. If DTP is enabled on connected devices (which might be the default), DTP might negotiate parameters, such as ISL, that are not supported by the ML-series cards. All packets on a link negotiated to use ISL are always counted as multicast packets by the ML-series card, and STP and CDP packets are bridged between connected devices using ISL without being processed. To avoid this issue, disable DTP and ISL on connected devices. This functionality is as designed.

CSCdz68649

Under certain conditions, the flow-control status may indicate that flow control is functioning, when it is not. Flow-control on the ML-series cards only functions when a port-level policer is configured. A port-level policer is a policer on the default and only class of an input policy-map. Flow-control also only functions to limit the source rate to the configured policer discard rate, it does not prevent packet discards due to output queue congestion.

Therefore, if a port-level policer is not configured, or if output queue congestion is occurring, policing does not function. However, it might still mistakenly display as enabled under these conditions. To avoid this issue, configure a port-level policer and prevent output queue congestion. This issue will not be resolved.

CSCdz69700

Issuing a shutdown/no shutdown command sequence on an ML1000 port clears the counters. This is a normal part of the startup process and there are no plans to change this functionality.

CSCin29274

When configuring the same static route over two or more interfaces, use the following command:

ip route a-prefix a-networkmask a.b.c.d

Where a.b.c.d is the address of the outgoing gateway, or, similarly, use the command:

ip route vrf vrf-name

Do not try to configure this type of static route using only the interface instead of the address of the outgoing gateway. This issue will not be resolved.

CSCin32057

If no BGP session comes up when VRF is configured and all interfaces have VRF enabled ensure that at least one IP interface (without VRF) is configured and add an IP loopback interface on each node. This issue will not be resolved.

CSCdy47284

ML-100 FastEthernet MTU is not enforced. However, frames larger than 9050 bytes may be discarded and cause Rx and Tx errors. This issue will not be resolved.

CSCdz74432

Issuing a "clear IP route *" command can result in high CPU utilization, causing other processes to be delayed in their execution. To avoid this issue do not clear a large number of route table entries at once, or, if you must use the "clear IP route *" command, do not install more than 5000 EIGRP network routes.

DWDM Cards

CSCsd92505

Traffic hits of 100 ms to 300 ms might occur during an OPT-PRE or OPT-BST card software reset or firmware upgrade. This occurs only with cards displaying the vendor ID 1025 in the CTC node level inventory tab when the following conditions are present for the affected card.

OPT-PRE

WorkingMode is set to Output Power and the Input Com Power value is less than -33dBm.

OPT-BST

WorkingMode is set to Gain with a Gain value of greater than 17 dB, and Input Com Power is less than -10 dBm (three channels at approximately -14 dBm).

This issue is resolved in Release 7.0.1 and all subsequent releases except for Release 7.2.

CSCei19148

When a port is placed in-service while the conditions necessary to squelch the port are present, as in when the trunk port on a DWDM card is OOS,DSBLD and a client port is placed in-service, the client will momentarily enable, emitting light, before squelching due to the trunk OOS,DSBLD condition. The pulse is approximately 500 ms. This issue will not be resolved.

CSCei87554

When using a 1GE payload over the TXP_MR_2.5G the IfInErrors counter does not report oversized, undersized, or CRC errored frames, but rather, reports frame coding only. This issue will not be resolved.

CSCsb47323

For MXP_MR_10DME-C and MXP_MR_10DME-L cards, an unexpected RFI condition might be raised along with an OTUk-BDI. When there is an LOS downstream, the node receives OTUk-BDI. Because of the placement of dual OTN and SONET wrappers, it can also receive an RFI. This issue will not be resolved.

CSCsb79548

A long traffic hit can occur when an active TCC2/TCC2P resets while an MXP_MR_10DME-C or MXP_MR_10DME-L card is rebooting.

This issue can be reproduced as follows:


Step 1 1. Set up two MXP_MR_10DME-C or MXP_MR_10DME-L cards, connected back-to-back in two different nodes, A and B.

Step 2 2. Ensure that Node A has two TCC2 cards; one is active, and the other is standby.

Step 3 3. Set up any kind of traffic between the two MXP_MR_10DME-C or MXP_MR_10DME-L cards.

Step 4 4. Soft reset the MXP_MR_10DME card in Node A, then soft reset the active TCC2/TCC2P.


OTUk/ODUk-SD, FEC Uncorrected word alarms are raised on the trunk port. Traffic goes down and does not recover until the MXP_MR_10DME card is able to come up. It is not known when or if this issue will be resolved.

CSCsb94736

After a fault condition (trunk LOS or Y-cable switch) an MXP_MR_10DME card might fail to detect the login message and traffic might not start for some minutes (after multiple login trials). This can occur in an N-F configuration with MDS switch and MXP_MR_10DME distance extension on, where test equipment traffic is set to 2G Fibre channel (FC) full bandwidth occupancy and started. Stop traffic or keep bandwidth occupancy below 80% during the login phase to work around this issue. This issue will not be resolved.

CSCsb95918

All GFP related alarms are raised with their active severities on the standby card after a Y-Cable protection switch. When a DWDM card (with GFP support) in a Y-Cable protection group becomes standby as a result of a Y-Cable protection switch, the GFP alarms raised when the card was active retain their severities instead of assuming standby severities. The alarms can be seen in the alarm pane if not suppressed, or in the condition pane if suppressed. This issue will be resolved in a future release.

CSCsc36494

Manual Y cable switches with squelching turned off can cause a Fibre channel link with brocade switches to go down.

This issue can be reproduced as follows:


Step 1 Set up MXP_MR_10DME cards so that they are Y cable protected. Squelching is provisioned to be off. Distance extension is turned on.

Step 2 The path between the working pair of Y cable protected cards, has no distance introduced. But the protect path has a delay of 800 km introduced.

Step 3 Start Fibre channel traffic with brocade switches.

Step 4 Perform user-initiated manual Y cable switches from CTC.


After a few switchovers, the FC link will go down. SIGLOSS and GFP-CSF alarms are seen on the CTC.

Cisco recommends you provision squelching to be on when interworking with brocade switches. If for some reason, squelching must be off with brocade switches, Cisco recommends you use a FORCE command to perform Y cable switches. It is not known when or if this issue will be resolved.

CSCsc60472

CTC is not able to discover a TL1 OCHCC circuit provisioned over an ITU-T line card (ITU-T OC48/STM16 and ITU-T OC192/STM64). This issue can occur when, using the TL1 client interface, you create the OCHNC layer that will be used by the OCHCC circuit, then create the OCHCC connections that involve the ITU-T line cards. The result is an OCHNC and two OCHCC partial circuits, instead of an OCHNC and a single OCHCC complete circuit. This issue will not be resolved.

CSCsc14290

LOW communication between two nodes equipped with TXP-MR-10E and AIC-I cards does not work with TXP-MR-10E cards in line termination mode, G.709 enabled, GCC present on the trunk port, and LOW circuits created between the transponders and AIC-I; Cisco recommends that you use EOW instead. This issue will be resolved in a future release.

CSCeh94567

Setting a Terminal loopback on an MXP-2.5G-10G trunk port causes OTUK alarms.

This can occur under the following conditions.

1. Two MXP-2.5G-10G cards are connected via the trunk ports.

2. The client ports are connected to respective STM16 line cards.

3. SDCC is enabled on the client ports and the line cards' STM16 port.

4. A terminal loopback is set on the MXP-2.5G-10G trunk port.

This terminal loopback causes OTUK-LOF and OTUK-IA alarms to be reported on both MXP-2.5G-10G trunk ports. This issue will not be resolved.

CSCef15415

RMON TCAs are not raised on the TXPP_MR_2.5G client port after a hardware reset. To see this issue, provision two nodes with TXPP_MR_2.5G (TXP-1 and TXP-2) as follows.


Step 1 Connect the TXP-1 DWDM-A trunk to the TXP-2 DWDM-A trunk.

Step 2 Connect the TXP-1 DWDM-B trunk to the TXP-2 DWDM-B trunk.

Step 3 Create an external fiber loopback on the TXP-1 client.

Step 4 Connect the TXP-2 client to a traffic generator.

Step 5 Provision 1G FC payload on the TXP-1 and TXP-2.

Step 6 Ensure that traffic is running smoothly.

Step 7 Provision RMON thresholds using TL1 for all TXPP_MR_2.5G ports (client and trunks).

Step 8 Apply a hardware reset to the TXPP_MR_2.5G.


After the card reboots, only DWDM-A and DWDM-B (trunk) port RMON TCAs are raised in the CTC History pane. RMON TCAs for port 1 (client) are not raised. This issue will not be resolved.

CSCef15452

RMON TCAs are not raised when the RMON history is cleared on TXPP_MR_2.5G card. To see this issue, provision two nodes with TXPP_MR_2.5G (TXP-1 and TXP-2) as follows.


Step 1 Connect the TXP-1 DWDM-A trunk to the TXP-2 DWDM-A trunk.

Step 2 Connect the TXP-1 DWDM-B trunk to the TXP-2 DWDM-B trunk.

Step 3 Create an external fiber loopback on the TXP-1 client.

Step 4 Connect the TXP-2 client to a traffic generator.

Step 5 Provision 1G FC payload on the TXP-1 and TXP-2.

Step 6 Ensure that traffic is running smoothly.

Step 7 Provision RMON thresholds using TL1 for all TXPP_MR_2.5G ports (client and trunks).

Step 8 While the traffic is running reset the RMON history by clicking the Clear button in the CTC Payload PM pane.


RMON TCAs are not raised for any port. This issue will not be resolved.

CSCuk48503

Under very specific conditions the MXPD fails the Telcordia GR-253/G.825 Jitter generation mask test on the 10G transmit trunk port. The 2.5 G transmit client jitter generation remains within mask and does not exhibit this issue.

This only occurs when, in SONET mode, with no FEC, no G,709, and client interfaces looped back, with non-synchronous clocking, and performing the following steps.


Step 1 Connect a jitter testbox TX to Trunk RX port.

Step 2 Connect a jitter testbox RX to Trunk TX port.


The jitter testbox TX clock recovers from RX with an additional 5 ppm offset added. This issue will not be resolved.

Maurizio: this caveat was removed under the Hardware section, did you mean to remove it from here also?

CSCef50726

Receive client fiber removal can cause a switch from the protect to the active in a TXPP_MR_2.5G. To see this issue, perform the following steps.


Step 1 Set up two nodes with TXPP_MR_2.5G (call the nodes TXP-1 and TXP-2).

Step 2 Ensure that TXP-1 DWDM-A trunk is connected to TXP-2 DWDM-A trunk with a 100 Km span.

Step 3 Ensure that TXP-1 DWDM-B trunk is connected to TXP-2 DWDM-B trunk with a 0 Km span.

Step 4 Ensure that TXP-1 client has an external fiber loopback.

Step 5 Connect the TXP-2 client to a traffic generator.

Step 6 Provision TXP-1 and TXP-2 with FICON 1G payload.

Step 7 Ensure that traffic is running smoothly on the protected span.

Step 8 Remove the receive client fiber at the near end.


This causes the far end trunk to switch from protect to working span. Similarly, removal of the receive Client fiber at far end causes the near end trunk to switch from the protect to the working span. (Note that the traffic is already lost due to the receive client fiber pull.) To work around this issue, manually switch via CTC from the working to the protect span. This issue will not be resolved.

CSCef13304

Incorrect ALS initiation causes a traffic outage on an FC payload. This issue can be seen by performing the following steps.


Step 1 Set up two nodes with TXPP_MR_2.5G (call these nodes TXP-1 and TXP-2).

Step 2 Connect the TXP-1 DWDM-A trunk to the TXP-2 DWDM-A trunk.

Step 3 Connect the TXP-1 DWDM-B trunk to the TXP-2 DWDM-B trunk.

Step 4 Provision the TXP-1 client with an external fiber loopback.

Step 5 Connect the TXP-2 client to a traffic generator.

Step 6 Ensure that TXP-1 and TXP-2 have 1G FC payload provisioned.

Step 7 Enable ALS on TXP-1 trunk port and set it to "Manual Restart."

Step 8 When traffic is running, remove the receive and transmit fibers on TXP1 port 1 (client). Traffic goes down and shutdown on TXP-1 port 2 (trunk) displays "No."

Step 9 Reconnect the fibers for TXP-1 port 1 (client).


ALS is now initiated on TXP-1 port 2 (trunk) and the laser shuts down. Traffic never comes back.


Note This issue is restricted to the TXPP_MR_2.5G card.


To recover from this situation, perform a manual restart or disable the ALS in this configuration. This issue will not be resolved.

CSCuk51184

When downloading Release 4.7 nodes with Release 4.6 installed, The 15454-32MUX-O and 15454-32DMX-O report an AWG Temperature fail low alarm that subsequently clears. This also occurs when downgrading from Release 4.7 to Release 4.6, where the AWG Temperature alarm fail is high. This issue cannot be resolved.

CSCec22885

AS-MT is not enabled in Port 3 when a loopback is applied. To see this issue, on the TXPP card, make the following 3 changes before clicking Apply:


Step 1 Change Port 2 to OOS-MT from IS.

Step 2 Change Port 3 to OOS-MT from IS.

Step 3 Change Port 2 to facility or terminal loopback.


Now, when you click Apply, CTC issues the error message: "Error applying changes to row2 peer trunk port must not be IS." Port 3 is still IS and the loopback changes are not applied. You must place Port 3 in the OOS-MT state, apply the changes, and then change the loopback to recover.

This error occurs only when all three of the above changes are attempted at the same time.

To avoid this issue, first change both the trunk ports to OOS-MT, click Apply, and then place port 2 in loopback and click Apply again. This issue will not be resolved.

CSCed76821

With Y-cable provisioned for MXP-MR-2.5G cards, if you remove the client receive fiber on one side, the far end takes greater than 100 ms to switch away from the affected card. This issue will not be resolved.

CSCef44939

Under certain conditions you may be unable to provision an Express Order Wire (EOW) circuit using an MXP_2.5G_10G or TXP_MR_10G card trunk port. This can occurs as follows.


Step 1 Provision an MXP_2.5G_10G or TXP_MR_10G card within a node.

Step 2 Disable OTN.

Step 3 Provision DCC on both client and trunk ports.

Step 4 Go to the Network view Provisioning > Overhead Circuits tab.


During the EOW circuit provisioning only the MXP/TXP client ports are listed for the selection. This issue will not be resolved.

CSCuk51185

After a soft reset of an OSCM or OSC-CSM card, a CONTBUS-IO alarm is raised. This issue will not be resolved.

CSCuk50144

Neither E1 nor E2 circuits are available for EOW circuits on TXP_MR_2.5 TXT in Section and Line Termination mode. This issue will not be resolved.

CSCee45443

When the FICON bridge does not receive the expected number of idle frames between data packets it will transition to SERV MODE. This issue will not be resolved.

CSCec40684

After a database restore TXPP trunk ports might report SF, resulting in a traffic outage. The SF occurs when you restore the database and then put the port OOS for DWDM cards; then the operating mode in the database is different from the current operating mode. To avoid this issue, either put the DWDM port OOS before restore the database, or, after restoring the database, reset the DWDM cards. This issue will not be resolved.

CSCec51270

Far end traffic does not switch in line termination mode with .G709 off. This can occur with non-revertive Y-cable, and DCC enabled, under certain specific conditions. To avoid this issue, turn on .G709 when in line mode. This issue will not be resolved.

CSCuk42668

TXP-MR-2.5G F1-UDC may not be passed through in a line-terminated configuration with OTN off. This can occur with clean, OC-3/STM-1, line-terminated traffic, with OTN disabled, when you create a D1-D3 tunnel, a D4-D12 tunnel, and an F1-UDC from client to client. This issue will not be resolved.

CSCuk42752

If you go to the Overhead Circuits Tab in network view and select any User Data, F1 or User Data D4-D12 circuit type, no nXP cards are available for selection in the Endpoints. However, user Data type circuits can still be made end-to-end (where "end-to-end" refers to external cards, such as AIC to AIC) if the nXP cards are put in Transparent mode. This issue will not be resolved.

CSCeb49422

With TXPP cards, a traffic loss up to six seconds can occur during a DWDM protection switch. This behavior may be exhibited during protection switches by certain third-party fiber channel switches due to loss of buffer credits resulting in a reconvergence of the fiber channel link. This issue will not be resolved.

CSCeb53044

The 2G Fiber Channel (FC) payload data type in the TXP_MR_2.5G and TXPP_MR_2.5G cards do not support any 8B/10B Payload PM monitoring. This is as designed.

CSCea78210

The TXP_MR_2.5G and TXPP_MR_2.5G cards do not support TX Optical power performance monitoring on the trunk port. This is as designed.

CSCeb32065

Once engaged, ALR will not restart on the trunk lines of a TXP or TXPP card. This occurs whenever ALR engages on the trunk lines of a TXP or TXPP card and the recover pulse width is provisioned to less than 40 seconds. This is a function of the trunk laser turn-on time, and the limiting recovery pulse width will vary by card. To avoid this issue, provision the pulse width to 40 seconds or more. This issue will not be resolved.

CSCuk42588

With ALS mode configured as "Auto Restart" or "Manual Restart," it is possible the ALS Pulse Duration Recovery time can be set to values out of ITU-T recommendation G.664. You can use values out of the range defined in ITU-T recommendation G.664 only in order to interoperate with equipment that lasers cannot turn on or off within the required pulse time. To stay within the specification, you can set this value to 2 seconds and up to 2.25 seconds.

CSCea81219

On the TXPP, the default value for Tx Power High for TCAs & Alarms is too high for the trunk ports. Since Tx Power TCA and Alarm are not supported for trunk ports, this caveat is for informational purposes only.

CSCeb27187

During a Y-Cable protection switch, the client interface sends 200,000 to 300,000 8B/10B errors towards the attached Catalyst 3550 switch. The switch reacts to this large amount of 8B/10B errors by reinitializing the interface and spanning tree. The end result is that a protection switch can lead to a 30-45 second traffic hit if the switch is running spanning tree (default mode). This is expected behavior.

CSCea87290

In a Y-Cable protection group, if GCCs are defined on both cards, both cards' active LEDs will be green. This is by design.

CSCeb12609

For the TXPP, attenuating Port 2 Rx signal, SD, and SF alarms are not declared before LOS-P is raised. This is due to the intrinsic design of the optical interface, which allows required BER performances with dispersion and OSNR penalties.

This can occur when Port 2 is in back to back or has low dispersions and high OSNR.

CSCea68773

The ACTV/STBY LED shows AMBER when a 2.5G transponder is first connected. The DWDM cards introduced a new design: When all the ports are OOS on a card, the card is considered to be in standby mode.

Interoperability

CSCds13769: Fujitsu FLM-150 and Nortel OC-3 Express

You cannot provision the FLM-150 and OC-3 Express in 1+1 revertive switching mode. The problem occurs when the ONS 15454 issues a user request in revertive mode to the protect channel. When the user request is cleared, the ONS 15454 issues a No Request. However, the FLM-150 and OC-3 Express issues a Do Not Revert, which causes traffic to remain on the protection channel. Based on Telcordia GR-253, section 5.3.5.5, the FLM-150 and the OC-3 Express should respond with a No Request.

BLSR Functionality

CSCei67965

A VT traffic hit up to 140 ms can occur when an intermediate node of the VT circuit is isolated. For example, if you have three nodes, A, B, and C, where the circuit is routed from A to C via B, when you isolate Node B, Nodes A and C perform STS-level 100 ms squelching as a part of the VT squelching process. However, the timer resolution on the cross connect card yields 16 2/3 ms accuracy, so the 100 ms timer sometimes (about 80% of the time, depending on the number of VT circuits on a ring) expires approximately 17 ms delayed. This causes VT traffic to be squelched for slightly more than 100 ms. Due to system limitation of timer resolution accuracy and task scheduling delay, there is no further optimization available in the current 15454 BLSR design.

CSCed10127

Extra traffic is not restored when an SF-R occurs on the same span where a lockout of protect is applied at the opposite node, and where the extra traffic is sourced, destined, or travels through the node with the SF-R. to work around this, issue a lockout on each end of the span at the node where the SF-R occurs. Extra traffic should then be restored. This issue will not be resolved.

CSCea59342

DS3 PCA traffic may take up to 20 seconds to recover after a BLSR switch is cleared. This can occur with DS3 PCA traffic on two-Fiber or four-Fiber BLSR configuration with XCVT cards in the same nodes as the DS3 cards. This issue will be resolved in a future release.

CSCdw58950

You must lock out protection BLSR, 1+1, and path protection traffic to avoid long, or double traffic hits before removing an active XCVT or XC10G card. You should also make the active cross connect card standby before removing it.

CSCdv53427

In a two ring, two fiber BLSR configuration (or a two ring BLSR configuration with one two fiber and one four fiber ring) it is possible to provision a circuit that begins on one ring, crosses to a second ring, and returns to the original ring. Such a circuit can have protection vulnerabilities if one of the common nodes is isolated, or if a ring is segmented in such a way that two non-contiguous segments of the circuit on the same ring are each broken.

Database Restore on a BLSR

When restoring the database on a BLSR, follow these steps:


Step 1 To isolate the failed node, issue a force switch toward the failure node from the adjacent east and west nodes.

Step 2 If more than one node has failed, restore the database one node at a time.

Step 3 After the TCC2/TCC2P has reset and booted up, ensure that the "BLSR Multi-Node Table update completed" event has occurred for all nodes in the ring.

Step 4 Release the force switch from each node.


Path Protection Functionality

CSCee53579

Traffic hits can occur in an unprotected to path protection topology upgrade in unidirectional routing. If you create an unprotected circuit, then upgrade the unprotected circuit to a path protection circuit using Unprotected to path protection wizard, selecting unidirectional routing in the wizard, the circuit will be upgraded to a path protection circuit. However, during the conversion, traffic hits on the order of 300 ms should be expected. This issue will not be resolved.

Active Cross Connect (XC10G/XCVT) or TCC2/TCC2P Card Removal

As in BLSR and 1+1, you must perform a lockout on path protection before removing an active cross connect or TCC2/TCC2P card. The following rules apply to path protection.

Active cross connect (XC10G/XCVT) cards should not generally be physically removed. If the active cross connect or TCC2/TCC2P card must be removed, you can first perform an XCVT/XC10G side switch or TCC2/TCC2P reset and then remove the card once it is in standby, or you can perform a lockout on all circuits that originate from the node whose active cross connect card or active TCC2/TCC2P will be removed (performing a lockout on all spans will also accomplish the same goal). No lockout is necessary for switches initiated through CTC or through TL1.

Alarms

CSCsc66474

The ODU-Alarm indication signal is not sent downstream on a client when the line card is provisioned as line terminated. This issue will not be resolved.

SNMP

SNMP Attribute Changes

The following SNMP attributes will be replaced in future releases, and will no longer be supported after Release 7.x.

cMsDwdmIfMultiplexSectionRingDirection

cMsDwdmIfTransportRingDirection

cMsDwdmIfChannelRingDirection

TL1


Note To be compatible with TL1 and DNS, all nodes must have valid names. Node names should contain alphanumeric characters or hyphens, but no special characters or spaces.


CSCsb72582

You cannot perform an ENT-EQPT for a valid card type when the current equipment state is OOS-AUMA,MEA&UAS. When the fault PPM comes up as OOS-AUMA,MEA&UAS and then the ENT-EQPT command is entered using TL1, the command is rejected. This issue will be resolved in a future release.

CSCsc41650

Using a TL1 script to rapidly preprovision/delete various cards repeatedly in the same slot will reboot the TCC approximately 1 out of 10 times. Put a delay of about 10 seconds between preprovisioning/deletion cycles and the node will not reboot. This issue will be resolved in a future release.

CSCdu53509

When a TL1 session to a remote node (ENE) is established via a gateway node (GNE) and you have changed the node name of the ENE via either TL1, CTC or SNMP, then you must wait for about 30 seconds to issue a TL1 command via the GNE. This delay is to permit the updates to propagate to all nodes in the network. During this transition, neither the old node name nor the new node name can be used in the TL1 session to access the ENE. This 30 second window may be reduced in a future release.

Resolved Caveats for Release 8.0

This section documents caveats resolved in Release 8.0.

Maintenance and Administration

CSCsd47626

Bulk deletion of Low Order Server Trails can cause a TCC card to reset. To avoid this delete low order server trails one by one. This issue is resolved in Release 8.0.

CSCse52258

APS CHANNEL FAILURE ALARMS may appear while software upgrade is in progress. Once upgrade is complete, the alarms clears. This issue is due to the FPGAs being reprogrammed and k3 not supported under hardware control. Once the FPGAs finish, k3 is restored and the alarms clear. This issue is resolved in Release 8.0.

CSCse75892

Entering wait to restore is inconsistent in dual unidirectional failures on working and protect lines of a 4-fiber BLSR.

Scenario 1: In a 4-fiber ring where node 1 and node 2 are adjacent nodes, there is a unidirectional signal fail on the working line into node 1 and unidirectional signal fail into the protect line of node 2. When node 1 working line failure is cleared, the ring starts wait to restore while the protect line is still failed.

Scenario 2: In a 4-fiber ring where node 1 and node 2 are adjacent nodes, there is a unidirectional signal degrade on the working line into node 1 and unidirectional signal fail into the protect line of node 2. When node 1 working line signal degrade is cleared, the ring stays ring switched until the protect line clears. Then the ring reverts. This issue is resolved in Release 8.0.

CSCsg08650

When all active members of the LAG are manually "shutdown," the time taken for switching over to "hot-stdby" links is more than 6 secs. In this scenario, the port-channel interface goes down and comes back when the "hot-stdby" members are added to the LAG, causing routing and spanning tree reconvergence. This occurs when all active members of the port-channel are simultaneously "shutdown." The workaround is to increase the carrier delay timer of the port-channel to greater than 2 seconds. This issue is resolved in Release 8.0.

CSCsc89462

When idle GFP frames are sent, CE-100T-8 card reports a GFP-UP-MISM alarm after a few RX SONET fiber pulls, GFP-UP-MISM alarm is cleared and a valid GFP frame is sent. This issue is resolved in Release 8.0.

CSCsd36183

The path alarm counters in the ML100T-8 is not present, but in the ML100-T12 (ONS 15454) they are present. These counters are useful for debugging purposes. This issue is resolved in Release 8.0.

CSCse69401

There is a traffic hit of around 15 to 25 seconds, when the LACP system priority is modified. All the members of the port-channel are removed from the port-channel and added back. This is done to re-negotiate the LAG ID. The workaround is to modify system priority before adding members to the channel-group. This issue is resolved in Release 8.0.

CSCsg05124

In a LAG with members of equal port priority, members could be repeatedly added/removed from the LACP LAG, when the interface with the lowest if-number is flapping. When LACP priority is equal, the link with the lowest if-number is given preference to be added to the etherchannel. However, this behavior could lead to links being added/removed from the channel, when the port with lowest if-number is flapping. The workaround is to modify the port-priorities of the LAG members. This issue is resolved in Release 8.0.

CSCsd37116

No password is required on CTC IOS CLI after ML card is re-seated. When requesting an IOS connection for CLI through CTC, system opens immediately to the EXEC user prompt with no request for a password. This issue is resolved in Release 8.0.

CSCse55726

CTC displays the wrong node if the CTC cache is not deleted. CTC behavior is consistent with that for a different NE type or version. This may result in partial or total loss of functionality in accessing the NE in question. An ACNS device must be configured to cache the HTTP response from the NE in question. This issue is resolved in Release 8.0.

CSCse75849

DWDM links remain grey after a node power down cycle. When three MSTP nodes are connected by OSC links with one configured as GNE and the other two as ENE, when the GNE node is power down, all the nodes become gray. When powering up the GNE, sometimes the connected ENE nodes remain gray even after all the nodes are completely up and running. This issue is resolved in Release 8.0.

CSCsg02556

OCHTRAIL and OCHCC are PARTIAL_TL1 after an activation/revert. From CTC, this issue occurs when activation is complete on a single node, with a release between 7.01 to 8.00, as part of a ring, and a revert is executed twice. This issue is resolved in Release 8.0.

CSCse93291

There is DS3 traffic loss during a soft-reset of an active protect card when an unlock is issued. This issue is resolved in Release 8.0.

CSCse09512

A software reset of Transponder/Muxponder cards (a whole protection group) cause External Patchcords Link to go down for twice and all the circuits momentarily goes partial. This occurs to any of Transponder/Muxponder cards in Y-cable protection connected to ROADM node via external patchcords. This issue is resolved in Release 8.0.

CSCsg40898

SHELF-COMM-FAIL is raised after upgrade to 8.0 and a TCC Software reset. In a multi-shelf in secure mode in releases from 7.2 to 8.0, activation is successful. Software resets SSC active TCC. After a complete reboot, software resets NC active TCC. The SSC is lost and SHELF-COMM-FAIL is raised.

CSCsf23325

Rebooting of TCC while in Version-Up may result in the loss of the NE defaults for the switch on a Release 6.2.x. The user's alarm profile is lost and the system reverts to the default alarm profile.

CSCsg62116

After the hard reset of a trunk card, the WKSWPR is not always reported for path protection revertive circuit, and upon reinsertion of the card and the WTR is not always reported. This issue is resolved in Release 8.0.

CSCsd53751

When there is an active circuit between the nodes, CTC and TL1deny provisioning of an OSPF Area ID. TL1 rejects the command with a proper error message, but CTC needs modification to make the error message appropriate. This issue is resolved in Release 8.0.

Hardware

CSCsh17399

OPT-PRE units with FW version 2.0.6, HW version 1.0.0 and Vendor Id 1025 at times don't turn on correctly after first circuit creation. This happens under normal operating conditions. A firmware load to fix this issue has been downloaded on the module. This issue has been fixed in 7.04, 7.22 and 8.0.

Electrical IO Cards

CSCsc60437

DS3XM one way circuits created with no electrical lines attached to the ports fail to carry traffic. This issue is resolved in Release 8.0.

CSCse96077

In Release 7.2, when either you remove and then reinsert an I/O card, or a small burst of defects occurs for a very short period (less than 1 sec), false TCAs can be triggered that indicate line or traffic problems on an I/O port. Once triggered, the TCAs will be raised every 15 mins, after the 15 min pm report. There are no alarms for the associated ports. Traffic is not affected.

The cards affected are:

ONS 15454 DS1, DS1_E1_56, DS3 (including DS3, DS3N, DS3E, DS3NE), DS3_EC1, DS3XM, DWDM, E1, E1_42, OC3-8, OC12-4, MRC-12, OC192XFP; and ONS 15310-CL and ONS 15310-MA IO ports.

There are two workarounds:

1. Place the affected ports in OOS-DSBLD and then back to IS. This clears the problem for the specific port on the card, but the traffic will be down during the period of OOS-DSBLD.

2. Soft reset the card with problem ports. This clears the problem on all ports on the card. Soft reset might cause a protection switch if any port on that card or the card itself is in a protection group.

You can switch all protected ports away from the card that is to be soft-reset. In this case you can do manual switches away from the ports on that card, or in the case of an equipment switch, away from the equipment to be reset.

You can also perform a soft reset without any pre-action. This might result in protection switches of all active protected ports on that card. In the case of an equipment protection group resetting, the active equipment might incur a protection switch. The switch time will not exceed 60 ms.

For unprotected ports or card equipment, traffic will not be affected.

DWDM Cards

CSCeh22604

When an MXP_MR_2.5G card is in MIXED or ESCON mode, TCA and alarm optical thresholds of Tx power for laser bias are configurable for ESCON payload, though not supported. This issue is resolved in Release 8.0.

CSCsc58941

Trunk ports of the TXPP_MR_2.5G and MXPP_MR_2.5G can be in facility and terminal loopback at the same time. this can occur if you provision terminal loopback on the protected trunk port after putting the trunk ports in facility loopback. You can clear this condition by removing loopback provisioning on the trunk ports. This issue is resolved in Release 8.0.

CSCsc17683

Calculate Default Connection! does not create a patchord between the trunk port of a transponder and the related OCH filters ports when in HUB Node. Internal patch-cord are now part of Automatic Node Provisioning and are provided by MetroPlanner inside XML file. This issue is resolved in Release 8.0.

CSCsf16427

Switch Time exceeds 60 ms when protections switching is triggered by extracting the ADM main Board and double switching occurs. This issue is resolved in Release 8.0.

CSCsg10090

OTUK-LOF, LOM, and FEC-MISM alarms are raised on a trunk port when the far end card trunk port is configured in a terminal loop. This issue is resolved in Release 8.0.

CSCse67458

There is a traffic loss of 80 seconds when software simultaneously resets the Y-cable, TXP-MR-2.5G and the active TCC. This issue is resolved in Release 8.0.

CSCse73482

TXPP-MR-2.5G splitter protection switching does not revert to working when revertive is set with WTR = 0.5s. When a LOS-P on working trunk is generated when pulling out RX fiber, the traffic switches to Protect Trunk. When LOS-P on working trunk is removed by reinserting the fiber, the WTR condition is not raised and the traffic remains on protect trunk. This issue is resolved in Release 8.0.

CSCsd06988

PM on some ports of OPT-AMP-17-C and OPT-AMP-23-C are not correctly collected. This issue is resolved in Release 8.0.

CSCse65984

The switch status related to a protection group (Y cable or splitter) is incorrect after SHELF-COMM-FAIL. Extracting the fiber from the RX working port causes a switch to protect.
After disconnecting the shelf from Node controller, CTC reports that the protect entity is still carrying traffic (i.e., it is marked as Act and the working entity as Stdby). This issue is resolved in Release 8.0.

CSCse83704

When the Y cable protection is running and has traffic, a software reset on the protect card, and a fiber cut on the trunk of the working card, traffic is lost until the protect card completes the software reset. This issue is resolved in Release 8.0.

CSCse83706

All the cards report SWDL when resetting Active TCC of the SSC shelf. This issue is resolved in Release 8.0.

CSCse21172

Channel start-up procedure is restarted if Ptarget of an already provisioned channel is increased by more than 5 dB. This issue is resolved in Release 8.0.

Bridge and Roll

CSCsc60635

Bridge and Roll is allowed on the STM1E card, although it is not supported. This issue is resolved in Release 8.0.

New Features and Functionality

This section highlights new features and functionality for Release 8.0. For detailed documentation of each of these features, consult the user documentation.


Note The ML-MR-10 and CE-MR-10 cards appear in the software user interface, but the cards themselves will not be available until a future release.


Common Hardware

Fan Tray Assembly

The 15454-CC-FTA fan tray assembly power requirements are: 115 W, 2.4 A, and 393 BTU/hr.

MSPP Hardware

15454_MRC-12 Multirate Card

The 15454_MRC-12 card existed in a previous release; however, the card now supports additional PPMs, which adds to the card's functionality. The PPMs and their functionality are listed below:

PPM = ONS-SI-155-SR-MM (OC3/STM1 Multimode).

PPM = ONS-SI-622-SR-MM (OC12/STM4 Multimode).

PPM = ONS-SC-Z3-XXXX (OC48/STM16 CWDM), where XXXX = 1470, 1490, 1510, 1530, 1550, 1570, 1590, or 1610 nm.

PPM = ONS-SE-Z1 (OC48IR1, OC12/3SR1).

MRC-2.5G-4 Multirate Card

The MRC-2.5G-4 multirate card provides up to four OC-3/STM-1 ports, four OC-12/STM-4 ports, or one OC-48/STM-16 ports using small form-factor pluggables (SFPs), in various combinations of line rates. All ports are Telcordia GR-253 compliant. The SFP optics can use SR, IR, LR, coarse wavelength division multiplexing (CWDM), and DWDM SFPs to support unrepeated spans.

The ports operate at up to 2488.320 Mbps over a single-mode fiber. The MRC-2.5G-4 card has four physical connector adapters with two fibers per connector adapter (Tx and Rx). The card supports VT payloads, STS-1 payloads, and concatenated payloads at STS-3c, STS-6c, STS-9c, STS-12c, STS-18c, STS-24c, STS-36c, or STS-48c signal levels. It is fully interoperable with the ONS 15454 G-Series Ethernet cards.

Each MRC-2.5G-4 port contains a transmit and receive connector (labeled) on the card faceplate. The card supports 1+1 unidirectional and bidirectional facility protection. It also supports 1+1 protection in four-fiber BLSR applications where both span switching and ring switching might occur. You can provision this card as part of an BLSR, path protection, or 1+1 linear configuration. The MRC-2.5G-4 card also supports optimized 1+1 protection when used with OC-3 SFPs.

MSTP Hardware

MSPP-on-a-Blade Card (ADM-10G)

The MSPP-on-a-Blade card (also known as ADM-10G) operates on ONS 15454 SONET or DWDM networks to carry optical signals and Gigabit Ethernet signals over DWDM wavelengths for transport. In a DWDM network based on Gigabit Ethernet and OC-3, OC-12, OC-48, or OC-192 SONET, the MSPP-on-a-Blade transports low-bit-rate SONET traffic (or tunnels SDH traffic) over DWDM by mapping Gigabit Ethernet and SONET or SDH circuits onto the same wavelength with multiple protection options.

The MSPP-on-a-Blade is a double-slot card that can be installed in Slots 1 through 5 or 12 through 16 in standard and high-density SONET (15454-SA-ANSI or 15454-SA-HD) shelves. Installation is supported in any of these slots. Release 8.0 supports two-card configurations only. A future release will support single card configurations


Caution Fan-tray assembly 15454E-CC-FTA (ETSI shelf)/15454-CC-FTA (ANSI shelf) must be installed in a shelf where the MSPP-on-a-Blade card is installed.

The card is compliant with ITU-T G.825 and ITU-T G.783 for SDH signals. It supports concatenated and nonconcatenated AU-4 mapped STM-1, STM-4, and STM-16 signals as specified in ITU-T G.707. The card also complies with Section 5.6 of Telcordia GR-253-CORE and supports synchronous transport signal (STS) mapped OC-3, OC-12, and OC-48 signals as specified in the standard.

The client SFP and trunk XFP are compliant with interface requirements in Telcordia GR-253-CORE, ITU-T G.957 and/or ITU-T G.959.1, and IEEE 802.3.

The MSPP-on-a-Blade card has the following high-level features:

A two-slot width

Operates with the TCC2 or TCC2P

Supported by the integrated Cisco Transport Controller Craft Manager for the Cisco ONS 15454 MSPP

Supports concatenated payloads of STS-3c, STS-6c, STS-12c, STS-18c, STS-24c, STS-36c, STS-48c, and nonconcatenated payloads on an STS-1basis

Has built-in OC-192 ADM function including client, trunk, and STS cross-connect

Provides dual-card redundancy in path protection and 1+1 client protection schemes

Allows creation of ADM peer groups

Supports SONET and Gigabit Ethernet protocols on client SFPs

Supports XFP DWDM trunk interface single wavelengths

Tunnels SDH signals through a SONET system, provisionable from CTC

Returns zero bit errors when a TCC2 or TCC2P switches from active to standby or when manual or forced protection switches occur.

The MSPP-on-a-Blade card defaults to frame-mapped generic framing procedure (GFP-F) encapsulation that is compliant with ITU-T G.7041. This mode allows the card to operate with ONS 15310-CL, ONS 15310-MA, or ONS 15454 data cards (for example, ONS 15454 CE100T-8 or ML1000-2 cards). GFP encapsulation also allows the MSPP-on-a-Blade card to interoperate with other vendors' Gigabit Ethernet interfaces that adhere to the ITU-T G.7041 standard.

OPT-AMP-17-C Card

The OPT-AMP-17-C is a 17-dB gain, C-band, DWDM EDFA amplifier/preamplifier with OSC add-and-drop capability. It supports 80 channels at 50-GHz channel spacing in the C-band (that is, the 1530.3 nm to 1562.5 nm wavelength range). When an ONS 15454 has an OPT-AMP-17-C installed, an OSCM card is needed to process the OSC. You can install the OPT-AMP-17-C in Slots 1 to 6 and 12 to 17.

The card's features include:

Fixed gain mode (no programmable tilt)

Standard gain range of 14 to 20 dB at startup when configured as a preamplifier

Standard gain range of 20 to 23 dB in the transient mode when configured as a preamplifier

Gain range of 14 to 23 dB (with no transient gain range) when configured as a booster amplifier

True variable gain

Fast transient suppression

Nondistorting low-frequency transfer function

Settable maximum output power

Fixed output power mode (mode used during provisioning)

ASE compensation in fixed gain mode

Full monitoring and alarm handling with settable thresholds

OSRI

ALS

GE_XP Card

The GE_XP card is a Gigabit Ethernet (GE) Xponder for the ONS 15454 ANSI and ETSI platforms. The card aggregates Ethernet packets received on the client ports for transport on the 100-GHz-grid, and have DWDM XFP-based trunk ports with ITU-T G.709 framing and either FEC or E-FEC. These cards are designed for bulk GE point-to-point transport over 10GE LAN PHY wavelengths for Video-on-Demand (VOD), or broadcast video across protected 10GE LAN PHY wavelengths.

The GE_XP card can be installed in Slots 1 through 8 or 13 through 17. The GE_XP is a double-slot card with twenty GE client ports and two 10GE trunk ports. The client ports support SX, LX, and ZX SFPs and SR and 10GBASE LR XFPs. The trunk ports support a DWDM XFP.

A fan-tray assembly (15454E-CC-FTA for the ETSI shelf or 15454-CC-FTA for the ANSI shelf) must be installed in a shelf where a GE_XP card is installed.

GE_XP card can be provisioned to perform different GE transport roles. It can perform as a Layer 2 Ethernet switch or a 10GE or 20GE MXP.


Note Changing the GE_XP and 10GE_XP card mode requires the ports to be in a OOS-DSBL (ANSI) or locked, disabled (ETSI) service state. In addition, no circuits can be provisioned on the cards when the mode is being changed.


10GE_XP Card

The 10GE_XP card is a Gigabit Ethernet (GE) Xponder for the ONS 15454 ANSI and ETSI platforms. The card aggregates Ethernet packets received on the client ports for transport on the 100-GHz-grid, and have DWDM XFP-based trunk ports with ITU-T G.709 framing and either FEC or E-FEC. The card is designed for bulk GE point-to-point transport over 10GE LAN PHY wavelengths for Video-on-Demand (VOD), or broadcast video across protected 10GE LAN PHY wavelengths.

The 10GE_XP card can be installed in Slots 1 through 8 or 13 through 17. The 10GE_XP is a single-slot card with two 10GE client ports and two 10GE trunk ports. The client ports support SX, LX, and ZX SFPs and SR and 10GBASE LR XFPs. (LR2 XFPs are not supported.) The trunk ports support a DWDM XFP.

A fan-tray assembly (15454E-CC-FTA for the ETSI shelf or 15454-CC-FTA for the ANSI shelf) must be installed in a shelf where a GE_XP or 10GE_XP card is installed.

10GE_XP card can be provisioned to perform different GE transport roles. The card can perform as a Layer 2 Ethernet switch. However, the 10GE_XP can also perform as a 10GE TXP, and the GE_XP can perform as a 10GE or 20GE MXP.


Note Changing the GE_XP and 10GE_XP card mode requires the ports to be in a OOS-DSBL (ANSI) or locked, disabled (ETSI) service state. In addition, no circuits can be provisioned on the cards when the mode is being changed.


40-WSS-C Card

The double-slot 40-channel Wavelength Selective Switch C-Band (40-WSS-C) card switches 40 ITU-T 100-GHz-spaced channels and sends them to dedicated output ports. The 40-WSS-C card is bidirectional and optically passive. The card can be installed into Slots 1 to 6, and into Slot 12 to 17.

The 40-WSS-C features include:

Receipt of an aggregate DWDM signal into 40 output optical channels from the Line receive port (EXP RX) in one direction and from the COM-RX port in the other direction.

Per-channel optical power monitoring using photodiodes.

Signal splitting in a 70%-to-30% ratio, sent to the 40-DMX-C for dropping signals, then to the other 40-WSS-C card.

Aggregate DWDM signal monitoring and control through a variable optical attenuator (VOA). In the case of electrical power failure, the VOA is set to its maximum attenuation for safety purposes. A manual VOA setting is also available.

Within the 40-WSS-C card, the first AWG opens the spectrum and each wavelength is directed to one of the ports of a 1x2 optical switch. The same wavelength can be passed through or stopped. If the pass-through wavelength is stopped, a new channel can be added at the ADD port. The card's second AWG multiplexes all of the wavelengths, and the aggregate signal is output through the COM-TX port.

40-DMX-C Card

The single-slot 40-Channel Demultiplexer C-band (40-DMX-C) card demultiplexes 40 100-GHz-spaced channels identified in the channel plan and sends them to dedicated output ports. The overall optical power can be adjusted using a single VOA that is common to all channels. The 40-DMX-C card is unidirectional, optically passive, and can be installed in Slots 1 to 6 and 12 to 17.

40-DMX-C Faceplate Ports

The 40-DMX-C has two types of ports:

COM RX port: COM RX is the line input port for the aggregate optical signal being demultiplexed. This port is supported by a VOA for optical power regulation and a photodiode for per-channel optical power monitoring.


Note By default, the VOA is set to its maximum attenuation for safety purposes (for example, electrical power failure). A manual VOA setting is also available.


DROP TX ports (1 to 40): On its output, the 40-DMX-C card provides 40-drop ports that are typically used for dropping channels within the ROADM node. These ports are connected using five physical connectors on the front panel that accept MPO client input cables. (MPO cables break out into eight separate cables.) The 40-DMX-C card also has one LC-PC-II optical connector for the main input.

40-MUX-C Card

The single-slot 40-Channel Multiplexer C-band (40-MUX-C) card multiplexes forty ITU-T 100-GHz-spaced channels. The 40-MUX-C card can be installed into Slots 1 to 6, and into Slots 12 to 17. The 40-MUX-C card is typically used in hub nodes.

40-MUX-C Faceplate Ports

The 40-MUX-C has two types of ports:

COM TX port: COM TX is the line output port for the aggregate optical signal being multiplexed. This port is supported by both a VOA for optical power regulation and a photodiode for per-channel optical power monitoring.


Note By default, the VOA is set to its maximum attenuation for safety purposes (for example, electrical power failure). A manual VOA setting is also available.


DROP RX ports (1 to 40): The 40-MUX-C card provides 40 input optical channels. These ports are connected using five physical receive connectors on the card's front panel that accept MPO cables for the client input interfaces. MPO cables break out into eight separate cables. The 40-DMX-C card also has one LC-PC-II optical connector for the main output.

40-WXC-C Card

The double-slot 40-channel Wavelength Cross-Connect C Band (40-WXC-C) card selectively sends any wavelength combination coming from nine input ports to a common output port. The device can manage up to 41 channels spaced at 100GHz on each port. Each channel can be selected from any input. The card is optically passive and provides bidirectional capability. It can be installed into Slots 1 to 6, and into Slots 12 to 17.

.The 40-WXC-C card provides the following features:

Demultiplexing, selection, and multiplexing of DWDM aggregate signal from input ports to common output port.

Aggregate DWDM signal monitoring and control through a VOA.

VOAs are deployed in every channel path in order to regulate the channel's optical power. In the case of an electrical power failure, VOAs are set to their maximum attenuation value, or to a fixed and configurable one. The VOA can also be set manually.

Per-channel optical power monitoring using photodiodes.

The 40-WXC-C card acts as a selector element with the following characteristics:

It is able to select a wavelength from one input port and pass the wavelength through to the common out port. Simultaneously, the card can block the same wavelength coming from the other eight input ports.

It is able to stop wavelengths from all nine inputs.

It is able to monitor optical power and control path attenuation using per-channel VOA independently of the wavelength input-to-out port connection.

40-WXC-C Faceplate Ports

The 40-WXC-C card has six types of ports:

COM RX: The COM RX port receives the optical signal from a preamplifier (such as the OPT-PRE) and sends it to the optical splitter.

COM TX: The COM TX port sends an aggregate optical signal to a booster amplifier card (for example, the OPT-BST card) for transmission outside of the NE.

EXP TX: The EXP TX port sends an optical signal to the other 40-WXC-C card within the NE.

MON TX: The optical service channel (OSC) monitor.

ADD/DROP RX: The 40-WXC-C card provides 40 input optical channels. These ports are connected using five physical receive connectors on the card's front panel that accept MPO cables for the client input interfaces. MPO cables break out into eight separate cables.

ADD/DROP TX: The DROP TX port sends the split off optical signal that contains drop channels to the 40-WXC-C card, where the channels are further processed and dropped.

PM Threshold Reset Button

In node view, you can double-click the card where you want to view PM thresholds, and click the Reset button in CTC to reset the values of all PM thresholds to the default threshold values saved on the NE.

CTC displays a confirmation dialog of the default threshold values in the applicable threshold panel when you click the one-button threshold reset.

CTC supports the one-button reset (reset to default thresholds) for all Electrical, SONET, SDH, and Optical PM thresholds.

New Software Features and Functionality

ML-AINS and other Enhanced State Model (ESM) changes.

Several changes ave been made to the Cisco ONS 15454 SONET alarms and transient conditions. See the Cisco ONS 15454 Troubleshooting Guide for more details.

Link Aggregation Control Protocol (LACP)

In Software Release 8.0.0, ML100T-12, ML1000-2, ML100T-8, and CE-100T-8 cards can utilize the link aggregation control protocol (LACP) to govern reciprocal peer packet transmission with respect to LACP's detection of flawed packets. The cards' ports transport a signal transparently (that is, without intervention or termination).

Passive Mode and Active Mode

Passive mode or active are configured for a port in IEEE 802.17 RPR mode. They differ in how they direct a card to transmit packets: In passive mode, the LACP resident on the node transmits packets only after it receives reciprocal valid packets from the peer node. In active mode, both peers transmit packets without determining the validity of what they receive.

LACP Functions

LACP performs the following functions in the system:

Maintains configuration information in order to control aggregation

Exchanges configuration information with other peer devices

Attaches or detaches ports from the link aggregation group based on the exchanged configuration information

Enables data flow when both sides of the aggregation group are synchronized

In addition, LACP provides the following benefits:

Logical aggregation of bandwidth

Load balancing

Fault tolerance

SFP Management Completion

Supported services (rates, wavelengths, formats, reach, and so on) are encoded in the EEPROMs of SFPs and XFPs following industry standards. PPMs (SFPs or XFPs) that do not follow this standard cannot be read by the platform and are referred to as Unrecognized PPMs.

PPMs that are inserted into a card may be checked for the validity of an MD5 security code. PPMs failing this test are referred to as non-Cisco PPMs. PPMs passing this test as referred to in this document as Cisco PPMs.

Different cards are tested with a limited subset of Cisco PPMs. Customers are encouraged to use these PPMs, referred to as Qualified Cisco PPMs (for the particular card). Since each card supports different services (rates and formats), a PPM qualified for one card is not necessarily qualified for another. For example, a PPM qualified to work on a DWDM card may not be qualified to work on a SONET card. Cisco PPMs that are not recommended for use with a particular card are termed Unqualified Cisco PPMs (for the particular card).


Note This feature may not be described in the Release 8.0 documentation


Y-Cable Protection

Y-cable protection is offered on the GE_XP and 10GE_XP cards, both new to release 8.0. The GE_XP card supports Y-cable protection when it is provisioned in 10GE or 20GE MXP card mode. The 10GE_XP supports Y-cable protection when it is provisioned in 10GE TXP card mode. Two cards can be joined in a Y-cable protection group with one card assigned as the working card and the other defined as the protection card. This protection mechanism provides redundant bidirectional paths. The Y-protection mechanism is provisionable and can be set ON or OFF (OFF is the default mode). When a signal fault is detected (LOS, LOF, SD, or SF on the DWDM receiver port in the case of ITU-T G.709 mode) the protection mechanism software automatically switches between paths.

DISA Password Complexity, Max Password Length, Min Password Length.

The password length, by default, must be set to a minimum of six and a maximum of 20 characters. You can configure the default values in node view through Provisioning > NE Defaults > Node > security > passwordComplexity. The minimum length can be set to eight, ten or twelve characters, and the maximum length to 80 characters. The password must be a combination of alphanumeric (a-z, A-Z, 0-9) and special (+, #,%) characters, where at least two characters are nonalphabetic and at least one character is a special character. For TL1 compatibility, the password must be 6 to 10 characters. The password must not contain the user name.

Required JRE Version is 5.0

JRE version 5.0 was optional in Release 7.0. It is required for release 8.0 that JRE be version 5.0.

Solaris 10 Supported.

Solaris 10 is supported in release 8.0

Mozilla 1.7 Supported on Solaris 9 with Java plug-in 5.0.

Mozilla 1.7 on Solaris 9 with Java plug-in 5.0 is supported in release 8.0.

E1 SDH Timing

On the Cisco ONS 15454 chassis, the TCC2P card supports typical external E1 SDH timing sources so that the card can be provisioned to accept either an SDH or SONET timing standard. The initial default is for the card to use SONET timing; the default can be changed to SDH timing after the TCC2P card boots up. The BITS OUT clock runs at a rate determined by the BITS IN clock, as follows:

· If BITS IN = E1, then BITS OUT = E1

· If BITS IN = 2.048 MHz (square wave clock), then BITS OUT = 2.048 MHz (square wave clock)

· If BITS IN = 64 kHz, then BITS OUT = 6.312 MHz

The TCC2P card supports the E1 BITS OUT signal as defined in ITU-T G.703 Section 9, and the BITS OUT 2.048 MHz signal as defined in ITU-T G.703 Section 13. All of the BITS OUT signals meet the output signal criteria (including jitter and wander) as defined in ITU-T G.813 Sections 5 and 6, ITU-T G.811 Section 5, and ITU-T G.812, Section 6.

When SDH timing is selected, SDH Sync Status Messaging (SSM) is transmitted on the output ports and received on the input ports. SSM can be enabled or disabled.

The following framing options are allowed when E1 2.048 MHz timing is selected:

· Frame Alignment Signal (FAS)

· Frame Alignment Signal plus Channel Associated Signal (FAS + CAS)

· Frame Alignment Signal plus Cyclic Redundancy Check (FAS + CRC)

· Frame Alignment Signal plus Channel Associated Signal plus Cyclic Redundancy Check (FAS + CAS + CRC)

ML Version Up

The Version Up software upgrade feature allows users to independently upgrade ML-Series cards as part of an overall software upgrade process. With this feature enabled, the user first upgrades all the cards in the node that are not ML-Series cards, then in a second pass updates the ML-Series cards. Version Up is disabled by default.

The user can initiate individual upgrades for each ML-Series card or upgrade all the ML-Series cards at the same time. In the case of redundant ML-Series cards, individual upgrades allow time to verify the proper operation of the first card before the second card is upgraded. No ML-Series cards are updated until the user specifically requests it.

The user can perform a Version Up upgrade with CTC or Cisco Transport Manager (CTM). The Version Up feature is only supported on the ONS 15454 and SDH platforms. TL1 does not support the Version Up feature, and you cannot enter TL1 commands during the Version Up process.

IPv6

Cisco ONS 15xxx products can function in an IPv6 network when an internet router that supports Network Address Translation - Protocol Translation (NAT-PT) is positioned between the GNE, such as an ONS 15454, and the client workstation. NAT-PT is defined in RFC-2766. IPv4 and IPv6 nodes communicate with each other using NAT-PT by allowing both IPv6 and IPv4 stacks to interface between the IPv6 DCN and the IPv4 DCC networks.

NAT-PT binds addresses in IPv6 networks with addresses in IPv4 networks and vice versa to provide transparent routing for the packets traveling between address types. This requires no changes to end nodes and IP packet routing is completely transparent to end nodes. It does, however, require NAT-PT to track the sessions it supports and mandates that inbound and outbound datagrams pertaining to a session traverse the same NAT-PT router. Protocol translation is used to extend address translation with protocol syntax/semantics translation.


Note Only Mozilla 1.7 is supported on clients interfacing with IPv6 networks.


Superuser Privileges for Provisioning Users

Superusers can grant permission to Provisioning users to perform a set of tasks. The tasks include retrieving audit logs, restoring databases, clearing PMs, and activating and reverting software loads. These privileges can be set only through CTC network element (NE) defaults, except the PM clearing privilege, which can be granted to Provisioning users using CTC Provisioning> Security > Access tabs. For more information on setting up Superuser privileges, refer to the Cisco ONS 15454 DWDM Procedure Guide.

CTC Launcher 8.0

The CTC Launcher application is an executable file, StartCTC.exe, that is provided on Software Release 8.0 CDs for Cisco ONS products. You can use CTC Launcher to log into multiple ONS nodes that are running CTC Software Release 3.3 or higher, without using a web browser.

CTC Launcher provides two connection options. The first option is used to connect to ONS network elements (NEs) that have an IP connection to the CTC computer. The second option is used to connect to ONS NEs that reside behind third party, OSI-based gateway network elements (GNEs). For this option, CTC Launcher creates a TL1 tunnel to transport the TCP traffic through the OSI-based GNE.

The TL1 tunnel transports the TCP traffic to and from ONS ENEs through the OSI-based GNE. TL1 tunnels are similar to the existing static IP-over-CLNS tunnels GRE and Cisco IP that can be created at ONS NEs using CTC. (Refer to the Cisco ONS product documentation for information about static IP-over-CLNS tunnels.) However, unlike the static IP-over-CLNS tunnels, TL1 tunnels require no provisioning at the ONS ENE, the third-party GNE, or DCN routers. All provisioning occurs at the CTC computer when the CTC Launcher is started.

Hub Node


Note This has been updated to include the 40-WSS-C and 40-DMX-C cards


A hub node is a single ONS 15454 node equipped with two TCC2/TCC2P cards and one of the following combinations:

Two 32MUX-O cards and two 32DMX-O or 32DMX cards

Two 32WSS cards and two 32DMX or 32DMX-O cards

Two 32WSS-L cards and two 32DMX-L cards

Two 40-WSS-C cards and two 40-DMX-C cards


Note The 32WSS/32WSS-L/40-WSS-C and 32DMX/32DMX-L/40-DMX-C cards are normally installed in ROADM nodes, but they can also be installed in hub and terminal nodes. If the cards are installed in a hub node, the 32WSS/32WSS-L/40-WSS-C express ports (EXP RX and EXP TX) are not cabled.


A dispersion compensation unit (DCU) can also be added, if necessary. The hub node does not support both DWDM and time-division multiplexing (TDM) applications because the DWDM slot requirements do not provide room for TDM cards.

ROADM Node


Note This has been updated to include the 40-WSS-C and 40-DMX-C cards


A ROADM node adds and drops wavelengths without changing the physical fiber connections. A ROADM node is equipped with two TCC2/TCC2P cards and one of the following combinations:

Two 32WSS cards and, optionally, two 32DMX or 32DMX-O cards

Two 32WSS-L cards and, optionally, two 32DMX-L cards

Two 40-WSS-C cards and, optionally, two 40-DMX-C cards

Transponders (TXPs) and muxponders (MXPs) can be installed in Slots 6 and 12 and, if amplification is not used, in any open slot.


Note Although not required, 32DMX-O can be used in an ROADM node. Cisco MetroPlanner automatically chooses the demultiplexer card that is best for the ROADM node based on the network requirements.


Terminal Node


Note This has been updated to include the 40-WSS-C, 40-DMX-C, 40-MUX-C, and 40-DMX-C cards


A terminal node is a single ONS 15454 node equipped with two TCC2/TCC2P cards and one of the following combinations:

One 32MUX-O card and one 32DMX-O card

One 32WSS card and either a 32DMX or a 32DMX-O card

One 32WSS-L card and one 32DMX-L card

One 40-WSS-C card and one 40-DMX-C card

One 40-MUX-C and one 40-DMX-C card

Terminal nodes can be installed in Slots 1 through 6 or Slots 12 through 17. The side where cards are installed is always assigned as Side A. The channel flow for a terminal node is the same as the hub node.

Configuring Mesh DWDM Networks

ONS 15454 shelves can be configured in mesh DWDM networks using the 40-WXC-C wavelength cross-connect cards, multishelf provisioning, and the 40-channel patch panel, four-degree patch panel, and eight-degree patch panels. ONS 15454 DWDM mesh configurations can be up to four degrees (four optical directions) when the four-degree patch panel patch panel is installed, and up to eight degrees (eight optical directions) when the eight-degree patch panel is installed. Two mesh node types are available, the line termination mesh node and the cross-connect (XC) termination mesh node.

Line Amplifier Node

A line amplifier node is a single ONS 15454 node that is used to amplify the optical signal in long spans. The line amplifier node can be equipped with one of the following sets of cards:

Two OPT-PRE cards, two OPT-BST cards, and two OSCM cards

Two OPT-PRE cards and two OSC-CSM cards

Two OPT-AMP-17-C cards and two OSCM cards

Attenuators might also be required between each preamplifier and OPT-BST amplifier to match the optical input power value and to maintain the amplifier gain tilt value.

Two OSCM cards are connected to the OPT-BST cards to multiplex the OSC signal with the pass-though channels. If the node does not contain an OPT-BST card, OSC-CSM cards must be installed instead of OSCM cards.

DCN Extension

MSTP Intelligent Network applications has a communication channel to exchange data among different nodes. DCN Extension removes OSC constraint, when OSC is a penalty, leveraging on the external DCN (in Metro-access networks) or GCC/DCC that is already available (for LH). For instance in HUB Traffic, the Matrix HUB node can be connected to all other nodes by the GCC/DCC link, so by HUB node, a CTC or TL1 user can reach all other sites belonging to the same network.


Note This feature may not be described in the Release 8.0 documentation


Creating and Deleting OCHCCs

To create an OCHCC, you must know the client port states and their parameters. If the client port state is IS/Unlocked, OCHCC creation fails if OTN line parameters (ITU-T G.709, FEC, signal fail bit error rate (SF BER)), and signal degrade bit error rate (SD BER) on the OCHCC differ from what is provisioned on the trunk port. The port state must be changed to OOS-DSLB/Locked, disabled in order to complete the OCHCC.

If you delete an OCHCC, you can specify the administrative state to apply to the client card ports. For example, you can have the ports placed in OOS,DSBLD/Locked, disabled state after an OCHCC is deleted. If you delete an OCHCC that originates and terminates on MXP cards, the MXP trunk port states can only be changed if the trunk ports do not carry other OCHCCs.

Optical Sides


Note This has been updated to include the 40-WXC-C card


When 40-WXC-C cards are installed, DWDM nodes configured in multishelf mode can be connected to up to eight different spans. The sides are identified by the letters, A, B, C, D, E, F, G, and H. Sides are viewed and managed from the Provisioning > WDM-ANS > Optical Sides tab. Each side identifies a span to which the node is connected.


Note Side A and Side B replace "west" and "east" when referring to the two sides of the ONS 15454 shelf. Side A refers to Slots 1 through 6 (formerly "west"), and Side B refers to Slots 12 through 17 (formerly "east"). The line direction port parameter, East-to-West and West-to-East, has been removed.


Virtual Patchcords


Note This has been updated to include the GE_XP and 10GE_XP cards


TXP, MXP, TXPP, MXPP, GE_XP, 10GE_XP, and ADM-10G client ports and DWDM filter ports can be located in different nodes or in the same single-shelf or multishelf node. ITU-T line card trunk ports and the corresponding DWDM filter ports are usually located in different nodes.

OCHCC provisioning requires a virtual patchcord between the client card trunk ports and the DWDM filter ports. Depending on the physical layout, this can be an internal patchcord or a provisionable (external) patchcord (PPC). Both patchcord types are bidirectional. However, each direction is managed as a separate patchcord.

Internal patchcords provide virtual links between the two sides of a DWDM shelf, either in single-shelf or multishelf mode. They are viewed and managed on the Provisioning > WDM-ANS > Internal Patchcords tab (Figure 11-2).

CTC calculates internal patchcords automatically after you click the Default Patchcords button on the Internal Patchcords tab. However, some internal patchcords cannot be calculated because of the card types that are installed and/or the card positions within a shelf. These internal patchcords must be created manually. For example, internal patchcords related to optical bypass circuits must be manually provisioned. When you create an internal patchcord manually, the Internal Patchcord Creation wizard asks you to choose one of the following internal patchcord types:

OCH-Trunk to OCH-Filter—Creates an internal patchcord between the trunk port of a TXP, MXP, GE_XP, 10GE_XP, or ITU-T line card, and an OCH filter card (wavelength selective switch, multiplexer, or demultiplexer).

OTS/OCH to OTS/OCH—Creates an internal patchcord between two OTS OCH ports.

Automatic Node Setup


Note This has been updated to include the 40-WSS-C, 40-WXC-C, 40-DMX-C, and 40-MUX-C cards


Automatic node setup (ANS) is a TCC2/TCC2P function that adjusts values of the variable optical attenuators (VOAs) on the DWDM channel paths to equalize the per-channel power at the amplifier input. This power equalization means that at launch, all channels have the same amplifier power, independent from the input signal on the client interface and independent from the path crossed by the signal inside the node. This equalization is needed for two reasons:

Every path introduces a different penalty on the signal that crosses it.

Client interfaces add their signal to the ONS 15454 DWDM ring with different power levels.

To support ANS, integrated VOAs and photodiodes are provided in the following cards:

AD-xB-xx.x card express and drop paths

AD-xC-xx.x card express and add paths

4MD-xx.x card add paths

32MUX-O card add paths

32WSS/40-WSS-C/40-WXC-C add and pass through paths

32DMX-O card drop paths

32DMX, 40-DMX-C card input port

40-MUX-C card output port

Optical power is equalized by regulating the VOAs. Based on the expected per-channel power, ANS automatically calculates the VOA values by:

Reconstructing the different channels paths.

Retrieving the path insertion loss (stored in each DWDM transmission element).VOAs operate in one of three working modes:

Automatic VOA Shutdown—In this mode, the VOA is set at maximum attenuation value. Automatic VOA shutdown mode is set when the channel is not provisioned to ensure system reliability in the event that power is accidentally inserted.

Constant Attenuation Value—In this mode, the VOA is regulated to a constant attenuation independent from the value of the input signal. Constant attenuation value mode is set on VOAs associated to aggregated paths.

Constant Power Value—In this mode, the VOA values are automatically regulated to keep a constant output power when changes occur to the input power signal. This working condition is set on VOAs associated to a single channel path.

ANS calculates the following VOA provisioning parameters:

Target attenuation

Target power

To allow you to modify ANS values based on your DWDM network requirements, provisioning parameters are divided into two contributions:

Reference Contribution—(Display only) This value is set by ANS.

Calibration Contribution—This value can be set by the user.

To complete the equalization, ANS requires the following information:

The order in which DWDM cards are connected together on the express paths.

The number of channels that are add or dropped.

The number of channels and/or bands that are configured as passthrough.

ANS assumes that every DWDM port is associated to one on the node side. The port-to-side association is based on node layout deriving from provisioned (or automatically calculated) internal patchcords.

From CTC or TL1 you can:

Calculate the default connections on the NE.

Retrieve the list of existing connections.

Retrieve the list of free ports.

Create new connections or modify existing ones.

Launch ANS.

After you launch ANS, one of the following statuses is provided for each ANS parameter:

Success - Changed—The parameter setpoint was recalculated successfully.

Success - Unchanged—The parameter setpoint did not need recalculation.

Unchanged - Port in IS state—ANS could not modify the setpoint because the ports in an IS state.

Not Applicable—The parameter setpoint does not apply to this node type.

Fail - Out of Range—The calculated setpoint is outside the expected range.

Fail - Missing Input Parameter—The parameter could not be calculated because the required provisioning data is unknown or not available.

Optical patchcords are passive devices that are modeled by the two termination points, each with an assigned slot and port. If user-provisioned optical patchcords exist, ANS checks that the new connection is feasible (according to internal connection rules) and returns a denied message if the user connection violates one of the rules. ANS requires the expected wavelength to be provisioned. When provisioning the expected wavelength, the following rules apply:

The card name is generically characterized by the card family, and not the particular wavelengths supported (for example, AD-2C-xx.x for all two-channel OADMs).

At the provisioning layer, you can provision a generic card for a specific slot using CTC or TL1.

Wavelength assignment is done at the port level.

An equipment mismatch alarm is raised when a mismatch between the identified and provisioned value occurs. The default value for the provisioned attribute is AUTO.

ONS 15454 ANS parameters set the values required for the node to operate successfully. Cisco MetroPlanner calculates the ANS parameters based on the requirements for a planned network. Cisco MetroPlanner exports the parameters to an ASCII, NE Update file. The NE Update file can then be imported by CTC to automatically provision the node for the network. All ANS parameters can be viewed and manually modified from the node view Provisioning > WDM-ANS > Provisioning tab.

Automatic Node Turn-Up (Installation without Cisco MetroPlanner)

Automatic Node Turn-Up (installation without Cisco MetroPlanner) allows you to provision ONS 15454 automatic node setup (ANS) parameters without the Cisco MetroPlanner NE Update file. Instead, Cisco Transport Controller (CTC) provisions the ANS parameters using the data values that are calculated from the far-end nodes.

However, because of the requirements and complexity of the installation-without-Cisco-MetroPlanner sequence, Cisco recommends that you do not use installation without Cisco MetroPlanner unless it is absolutely required.


Note The installation-without-Cisco-MetroPlanner feature enables you to turn up network nodes without the Cisco MetroPlanner NE Update file. However, you must use Cisco MetroPlanner to create the network design to ensure an implementation using the installation-without-Cisco-MetroPlanner is feasible.



Note Unless otherwise specified, "ONS 15454" refers to both ANSI and ETSI shelf assemblies.



Caution This feature requires planning and preparation. Do not begin until you have a full understanding of the requirements and turn-up sequence.

During normal ONS 15454 turn up, a Cisco MetroPlanner NE Update file is imported into each ONS 15454 node and used by CTC to provision the ONS 15454 ANS parameters. The NE Update file ensures that all node parameters are set to levels that meet the specific requirements of your network. Installation without Cisco MetroPlanner provides a method for calculating the required installation values without the NE Update file. ANS uses the calculated values to provision the node parameters.

Installation without Cisco MetroPlanner requires physical and optical service channel (OSC) connections to far-end nodes. For example, let's say Node B is to be provisioned using installation without Cisco MetroPlanner. If only one far-end node, Node A, is connected, installation without Cisco MetroPlanner retrieves values to provision the side that is connected to Node A (Step 1). If a third node, Node C, is later connected to Node B, installation without Cisco MetroPlanner must be run again to provision the side connected to Node C (Step 2). Alternatively, installation without Cisco MetroPlanner can be run after both far-end nodes are connected, meaning the installation values are retrieved for both Node A and Node C at one time (Steps 1 and 2 combined).

The same sequence must be repeated at each network node. After Node B is provisioned, you move to Node C. If it is connected to Node B only, installation must be run twice, once for the Node B side. If Node D is connected later, installation without Cisco MetroPlanner must be run again. If Node C is connected to Nodes B and D, installation without Cisco MetroPlanner can be run once to provision Node C.

Requirements

The following requirements must be met before you can use the installation without Cisco MetroPlanner feature:

The network design must be prepared using Cisco MetroPlanner. Choose the installation-without-MetroPlanner option during network design. Cisco MetroPlanner will determine whether an installation without Cisco MetroPlanner is possible for your network (that is, whether the ANS parameters can be provisioned without the Cisco MetroPlanner NE Update file). If so, Cisco MetroPlanner designs the network assuming that you will use installation without

Cisco MetroPlanner to turn up the network nodes.

OPT-PRE amplifier cards are required. If you choose the installation-without-MetroPlanner option in the Cisco MetroPlanner design, it will include OPT-PRE cards in all the network nodes.

Installation without Cisco MetroPlanner is available only for networks that are designed for a flat optical power spectrum (tilt = 0) transmitted over the optical fiber links.

Cross-connect (XC) termination meshed nodes are not supported.

Installation without Cisco MetroPlanner is not available over C+L (networks that have both C-band and L-band channels) or 50 GHz networks.

Installation without Cisco MetroPlanner is not available on links using data communications network (DCN) extension. OSC connectivity is required.

View DWDM Facilities

This feature allows you to display DWDM facility information for all facilities in a node (single-shelf mode), shelf view (multishelf mode), or multishelf node (multishelf mode). The feature requires a maintenance security level and higher.

In node view (single-shelf mode), shelf view (multishelf mode), or multishelf view (multishelf mode), you can use the Maintenance > DWDM> All Facilities tabs to access the following display controls:

Marked—Displays a check mark if you have designated the facility for logical grouping (to mark certain facilities to group during column sorting, click the desired row and click Mark. A check mark appears in the Marked column. Click the Marked column header to group all of the checked facilities in ascending order. Click the Marked header again to sort in descending order).

Location—Displays the slot number, slot type, port number, and port type of the facility.

Admin State—Displays the administrative state of the facility.

Service State—Displays the service state of the facility.

Power—Displays the power level of the facility.

To sort the facilities by the Location, Admin State, Service State, or Power columns in ascending order, you can click on the desired column header. Click the column header again to sort in descending order.

TL1

New Card Support

The following new cards are supported in Release 8.0.

CE-MR-6

CE-MR-10

ML-MR-10

MRC-2.5G-4 (ANSI platform)

MRC-2.5G-12 (ETSI platform)

40-WSS-C, 40-WXC-C, 40-DMX-C, 40-MUX-C

40-WSS-L, 40-WXC-L, 40-DMX-L, 40-MUX-L

OPT-AMP-17-C

GE_XP, 10GE_XP

ADM-10G (ANSI)

MXP_MR_10DME_C

MXP_MR_10DME_L

TL1 Command Changes

New Commands

The following new TL1 commands are added for Release 8.0.

LIST

DLT-NNI-ETH

DLT-QNQ-ETH

DLT-RMONTH-MOD2-DATA

DLT-VLAN

DLT-WDMSIDE

ED-COS-ETH

ED-ETH

ED-L2-ETH

ED-LMP

ED-OTU2

ED-QNQ-ETH

ED-VLAN

ED-WDMSIDE

ENT-NNI-ETH

ENT-QNQ-ETH

ENT-VLAN

ENT-WDMSIDE

LMP-CTRL

LMP-DLINK

LMP-TLINK

RTRV-COS-ETH

RTRV-ETH

RTRV-L2-ETH

RTRV-NNI-ETH

RTRV-PATH-OCH-TYPE

RTRV-PM-ALL

RTRV-QNQ-ETH

RTRV-VLAN

RTRV-WDMSIDE

RTRV-WLEN

Removed Commands

The following commands were removed in Release 8.0.

DLT-OSC

ED-OSC

ENT-OSC

RTRV-OSC

Command Syntax Changes

The syntax of the following commands is changed in Release 8.0.

CHG-EQPT syntax changed:

CHG-EQPT[:<TID>]:<aid>:<CTAG>::<new_eqpt_type>;

CHG-EQPT[:<TID>]:<aid>:<CTAG>::<new_eqpt_type>[:PPMTYPE=<ppmtype>,][PPMNUM=<ppmnum>,][PORTNUM=<portnum>,][PORTRATE=<portrate>];

ED-APC syntax changed:

ED-APC[:<TID>]::<CTAG>[:::APCENABLE=<apcenable>][:];

ED-APC[:<TID>]:<aid>:<CTAG>[:::APCENABLE=<apcenable>][:];

The syntax of the following commands was changed from the last release:

(ALW-SWTOPROTN-EQPT enum changes:

DIRECTION)

(ALW-SWTOWKG-EQPT enum changes:

DIRECTION)

CHG-EQPT syntax changed: (454, 54 SDH)

CHG-EQPT[:<TID>]:<aid>:<CTAG>::<new_eqpt_type>;

CHG-EQPT[:<TID>]:<aid>:<CTAG>::<new_eqpt_type>[:PPMTYPE=<ppmtype>,][PPMNUM=<ppmnum>,][PORTNUM=<portnum>,][PORTRATE=<portrate>];

(CHG-EQPT enum changes:

EQUIPMENT_TYPE

PORTRATE)

(COPY-IOSCFG enum changes:

RFILE)

(DLT-RMONTH-MOD2-DATA enum changes

MOD2_DATA)

ED-APC syntax changed:

ED-APC[:<TID>]::<CTAG>[:::APCENABLE=<apcenable>][:];

ED-APC[:<TID>]:<aid>:<CTAG>[:::APCENABLE=<apcenable>][:];

(ED-BITS enum changes:

SYNC_CLOCK_REF_QUALITY_LEVEL)

(ED-E1 enum changes:

SYNC_CLOCK_REF_QUALITY_LEVEL)

ED-EQPT syntax changed:

ED-EQPT[:<TID>]:<aid>:<CTAG>[:::PROTID=<protid>,][PRTYPE=<prtype>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][CARDMODE=<cardmode>,][PEERID=<peerid>,][REGENNAME=<regenname>,][CMDMDE=<cmdmde>,][RETIME=<retime>,][SHELFROLE=<shelfrole>,][NEWSHELFID=<newshelfid>][:<pst>[,<sst>]];

ED-EQPT[:<TID>]:<aid>:<CTAG>[:::PROTID=<protid>,][PRTYPE=<prtype>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][CARDMODE=<cardmode>,][PEERID=<peerid>,][REGENNAME=<regenname>,][PEERNAME=<peername>,][CMDMDE=<cmdmde>,][RETIME=<retime>,][SHELFROLE=<shelfrole>,][NEWSHELFID=<newshelfid>,][FRPROLE=<frprole>,][FRPSTATE=<frpstate>][:<pst>[,<sst>]];

(ED-EQPT enum changes:

CARDMODE (454, 310MA, 310CL : Lotus20gCE2, Gt3CE2)

FRPROLE

FRPSTATE)

(ED-FAC enum changes:

PAYLOAD)

ED-FSTE syntax changed:

ED-FSTE[:<TID>]:<src>:<CTAG>[:::FLOW=<flow>,][EXPDUPLEX=<expduplex>,][EXPSPEED=<expspeed>,][VLANCOS=<vlancosthreshold>,][IPTOS=<iptosthreshold>,][NAME=<name>,][CMDMDE=<cmdmde>,][SOAK=<soak>][:<pst>[,<sst>]];

ED-FSTE[:<TID>]:<src>:<CTAG>[:::FLOW=<flow>,][EXPDUPLEX=<expduplex>,][EXPSPEED=<expspeed>,][VLANCOS=<vlancosthreshold>,][IPTOS=<iptosthreshold>,][NAME=<name>,][CMDMDE=<cmdmde>,][SUPPRESS=<suppress>,][SOAK=<soak>][:<pst>[,<sst>]];

ED-GIGE syntax changed:

ED-GIGE:[<TID>]:<aid>:<CTAG>:::[ADMINSTATE=<adminstate>],[LINKSTATE=<linkstate>],[MTU=<mtu>],[FLOWCTRL=<flowctrl>],[AUTONEG=<autoneg>],[HIWMRK=<hiwmrk>],[LOWMRK=<lowmrk>],[OPTICS=<optics>],[DUPLEX=<duplex>],[SPEED=<speed>],[NAME=<name>],[CMDMDE=<cmdmde>],[MACADDR=<macaddr>],[FREQ=<freq>],[LOSSB=<lossb>],[SOAK=<soak>]:[<pst>[,<sst>]];

ED-GIGE:[<TID>]:<aid>:<CTAG>:::[ADMINSTATE=<adminstate>],[LINKSTATE=<linkstate>],[MTU=<mtu>],[FLOW=<flow>],[FLOWCTRL=<flowctrl>],[AUTONEG=<autoneg>],[HIWMRK=<hiwmrk>],[LOWMRK=<lowmrk>],[OPTICS=<optics>],[DUPLEX=<duplex>],[SPEED=<speed>],[NAME=<name>],[CMDMDE=<cmdmde>],[MACADDR=<macaddr>],[FREQ=<freq>],[LOSSB=<lossb>],[SUPPRESS=<suppress>],[SOAK=<soak>],[SQUELCH=<squelch>],[CIR=<cir>],[CBS=<cbs>],[EBS=<ebs>]:[<pst>[,<sst>]];

(ED-G1000 enum changes:

ENCAP)

(ED-L2-ETH enum changes:

ETH_BRIDGESTATE

ETH_NIMODE

ETH_QNQMODE)

(ED-LMP enum changes:

OPSTATE

WDM_ROLE)

ED-NE-GEN syntax changed:

ED-NE-GEN[:<TID>]::<CTAG>[:::NAME=<name>,][IPADDR=<ipaddr>,][IPMASK=<ipmask>,][DEFRTR=<defrtr>,][IIOPPORT=<iiopport>,][NTP=<ntp>,][PROXYSRV=<isProxyServer>,][FIREWALL=<isFireWall>,][SUPPRESSIP=<mode>,][MODE=<mode>];

ED-NE-GEN[:<TID>]::<CTAG>[:::NAME=<name>,][IPADDR=<ipaddr>,][IPMASK=<ipmask>,][DEFRTR=<defrtr>,][IIOPPORT=<iiopport>,][NTP=<ntp>,][SUPPRESSIP=<mode>,][MODE=<mode>,][SERIALPORTECHO=<serialportecho>];

ED-NE-PATH syntax changed:

ED-NE-PATH[:<TID>]::<CTAG>[:::PDIP=<pdip>];

ED-NE-PATH[:<TID>]::<CTAG>[:::PDIP=<pdip>,][XCMODE=<xcmode>];

ED-OCH syntax changed:

ED-OCH[:<TID>]:<aid>:<CTAG>[:::RDIRN=<rdirn>,][EXPWLEN=<expwlen>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][CALOPWR=<calopwr>,][CHPOWER=<chpower>,][NAME=<portname>,][SFBER=<sfber>,][SDBER=<sdber>,][OSDBER=<sdber>,][COMM=<comm>,][GCCRATE=<gccrate>,][DWRAP=<drwap>,][FEC=<fec>,][PAYLOADMAP=<payloadmap>,][MACADDR=<macaddr>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][SOAK=<soak>,][OSPF=<ospf>,][MFS=<mfs>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]];

ED-OCH[:<TID>]:<aid>:<CTAG>[:::EXPWLEN=<expwlen>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][CALOPWR=<calopwr>,][CHPOWER=<chpower>,][NAME=<portname>,][OSDBER=<sdber>,][GCC=<gcc>,][GCCRATE=<gccrate>,][DWRAP=<drwap>,][FEC=<fec>,][PAYLOADMAP=<payloadmap>,][SOAK=<soak>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]];

(ED-OCH enum changes:

RDIRN_MODE)

(ED-OCHCC enum changes:

MOD2)

ED-OCHNC syntax changed:

ED-OCHNC[:<TID>]:<src>,<dst>:<CTAG>[:::CKTID=<cktid>,][CMDMDE=<cmdmde>][:<pst>][,<sst>];

ED-OCHNC[:<TID>]:<src>,<dst>:<CTAG>[:::CKTID=<cktid>,][CMDMDE=<cmdmde>,][WLOPWR=<wlopwr>,][VOAATTN=<voaattn>][:<pst>][,<sst>];

ED-OMS syntax changed:

ED-OMS[:<TID>]:<aid>:<CTAG>[:::RDIRN=<rdirn>,][EXPBAND=<expband>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][CALOPWR=<calopwr>,][CHPOWER=<chpower>,][NAME=<name>,][SOAK=<soak>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]];

ED-OMS[:<TID>]:<aid>:<CTAG>[:::EXPBAND=<expband>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][CALOPWR=<calopwr>,][CHPOWER=<chpower>,][NAME=<name>,][SOAK=<soak>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]];

(ED-OMS enum changes:

RDIRN_MODE)

ED-OTS syntax changed: (MultiShelf 454, 54 SDH)

ED-OTS[:<TID>]:<aid>:<CTAG>[:::RDIRN=<rdirn>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][OFFSET=<offset>,][CALTILT=<caltilt>,][OSRI=<osri>,][AMPLMODE=<amplmode>,][CHPOWER=<chpower>,][EXPGAIN=<expgain>,][NAME=<name>,][SOAK=<soak>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]];

ED-OTS[:<TID>]:<aid>:<CTAG>[:::VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][OFFSET=<offset>,][REFTILT=<reftilt>,][CALTILT=<caltilt>,][OSRI=<osri>,][AMPLMODE=<amplmode>,][CHPOWER=<chpower>,][EXPGAIN=<expgain>,][NAME=<name>,][SOAK=<soak>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]];

(ED-OTS enum changes:

RDIRN_MODE)

(ED-OTU2 enum changes:

PMMODE

REACH)

(ED-POS enum changes:

ENCAP)

(ED-QNQ-ETH enum changes:

ETH_RULE)

(ED-T1 enum changes:

SYNC_CLOCK_REF_QUALITY_LEVEL)

ED-WDMANS syntax changed:

ED-WDMANS[:<TID>]:<aid>:<CTAG>[:::POWERIN=<powerIn>,][POWEROUT=<powerOut>,][POWEREXP=<powerExp>,][NTWTYPE=<ringType>];

ED-WDMANS[:<TID>]:<aid>:<CTAG>[:::POWERIN=<powerIn>,][POWEROUT=<powerOut>,][POWEREXP=<powerExp>,][NTWTYPE=<ringType>,][PPMESH=<ppmesh>,][DITHER=<dither>];

(ED-WDMANS enum changes:

PPMESH)

(ENT-CKT-ORIG enum changes:

MOD_PATH)

(ENT-CKT-TERM enum changes:

MOD_PATH)

ENT-EQPT syntax changed:

ENT-EQPT[:<TID>]:<aid>:<CTAG>::<aidtype>[:PROTID=<protid>,][PRTYPE=<prtype>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][CARDMODE=<cardmode>,][PEERID=<protid>,][REGENNAME=<regenname>,][CMDMDE=<cmdmde>,][TRANSMODE=<transmode>,][RETIME=<retime>,][SHELFROLE=<shelfrole>][:];

ENT-EQPT[:<TID>]:<aid>:<CTAG>::<aidtype>[:PROTID=<protid>,][PRTYPE=<prtype>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][CARDMODE=<cardmode>,][PEERID=<protid>,][REGENNAME=<regenname>,][CMDMDE=<cmdmde>,][TRANSMODE=<transmode>,][RETIME=<retime>,][SHELFROLE=<shelfrole>,][FRPROLE=<frprole>,][FRPSTATE=<frpstate>][:];

(ENT-EQPT enum changes:

CARDMODE (454, 310MA, 310CL : Lotus20GCE2, Gt3CE2)

EQUIPMENT_TYPE (454, 454 SDH,310MA, 310CL : Lotus20GCE2, Gt3CE2)

FRPROLE

FRPSTATE)

ENT-OCHNC syntax changed:

ENT-OCHNC[:<TID>]:<src>,<dst>:<CTAG>[::<wct>][:CKTID=<cktid>,][CMDMDE=<cmdmde>][:<pst>][,<sst>];

ENT-OCHNC[:<TID>]:<src>,<dst>:<CTAG>[::<wct>][:CKTID=<cktid>,][CMDMDE=<cmdmde>,][WLOPWR=<wlopwr>,][VOAATTN=<voaattn>][:<pst>][,<sst>];

(ENT-OCHNC enum changes:

WCT)

(ENT-QNQ-ETH enum changes:

ETH_RULE)

(ENT-VCG enum changes:

MOD_PATH) (454, 454 SDH : Lotus20gML2Lite)

(INH-SWTOPROTN-EQPT enum changes:

DIRECTION)

(INH-SWTOWKG-EQPT enum changes:

DIRECTION)

(LMP-CTRL enum changes:

OPSTATE)

(LMP-DLINK enum changes:

DATALINK

OPSTATE)

(LMP-TLINK enum changes:

MUXCAP

OPSTATE)

OPR-APC syntax changed:

OPR-APC[:<TID>]::<CTAG>;

OPR-APC[:<TID>]:<aid>:<CTAG>;

OPR-WDMANS syntax changed: (454, 454 SDH)

OPR-WDMANS[:<TID>]::<CTAG>;

OPR-WDMANS[:<TID>]::<CTAG>[:::MODE=<mode>,][AGINGMARGIN=<agingMargin>][:];

(OPR-WDMANS enum changes:

WDMANS_MODE)

RTRV-ALM-ALL syntax changed: (All platforms)

RTRV-ALM-ALL[:<TID>][:<aid>]:<CTAG>[::<ntfcncde>,][<condtype>,][<srveff>][,,,];

RTRV-ALM-ALL[:<TID>][:<aid>]:<CTAG>[::<ntfcncde>,][<condtype>,][<srveff>,][<locn>,][<dirn>][,];

RTRV-ALM-ALL response changes:

[<aid>],[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,<ocrdat>,<ocrtm>,,:[<desc>],[<aiddet>]

[<aid>],[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,<ocrdat>,<ocrtm>,[<location>],[<direction>]:[<desc>],[<aiddet>]

(RTRV-ALM-ALL enum changes:

DIRECTION

MOD2B)

RTRV-ALM-BITS syntax changed: (All platforms)

RTRV-ALM-BITS[:<TID>]:<aid>:<CTAG>[::<ntfcncde>,][<condtype>,][<srveff>][,,,];

RTRV-ALM-BITS[:<TID>]:<aid>:<CTAG>[::<ntfcncde>,][<condtype>,][<srveff>,][<locn>,][<dirn>][,];

RTRV-ALM-BITS response changes:

<aid>,[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],,:[<desc>],

<aid>,[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],[<location>],[<direction>]:[<desc>],

(RTRV-ALM-BITS enum changes:

DIRECTION

MOD2B)

RTRV-ALM-EQPT syntax changed: (All platforms)

RTRV-ALM-EQPT[:<TID>]:<aid>:<CTAG>[::<ntfcncde>,][<condtype>,][<srveff>][,,,];

RTRV-ALM-EQPT[:<TID>]:<aid>:<CTAG>[::<ntfcncde>,][<condtype>,][<srveff>,][<locn>,][<dirn>][,];

RTRV-ALM-EQPT response changes:

[<aid>],[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],[<stringValue>],:[<desc>],

[<aid>],[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],[<location>],[<direction>]:[<desc>],

(RTRV-ALM-EQPT enum changes:

DIRECTION

MOD2B)

RTRV-ALM-SYNCN syntax changed: (All platforms)

RTRV-ALM-SYNCN[:<TID>]:<aid>:<CTAG>[::<ntfcncde>,][<condtype>,][<srveff>][,,,];

RTRV-ALM-SYNCN[:<TID>]:<aid>:<CTAG>[::<ntfcncde>,][<condtype>,][<srveff>,][<locn>,][<dirn>][,];

RTRV-ALM-SYNCN response changes:

<aid>,[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],,:[<desc>],

<aid>,[<aidtype>]:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],[<location>],[<direction>]:[<desc>],

(RTRV-ALM-SYNCN enum changes:

DIRECTION

MOD2B)

REPT^ALM^<MOD2ALM> response changes : (All platforms)

"<aid>:< ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>]>],,:[<desc>],[<aiddet>]";

"<aid>:< ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>]>],<locn>,<dirn>,,:[<desc>],[<aiddet>]";

REPT^ALM^BITS response changes: (All platforms)

"<aid>:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>]:[<desc>]";

"<aid>:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],<locn>,<dirn>:[<desc>]";

REPT^ALM^COM response changes: (All platforms)

"[<aid>]:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>]:[<desc>]";

"[<aid>]:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],[<locn>],[<dirn>]:[<desc>]";

REPT^ALM^EQPT response changes: (All platforms)

"<aid>:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>]:[<desc>],[<aiddet>]";

"<aid>:<ntfcncde>,<condtype>,<srveff>,[<ocrdat>],[<ocrtm>],<locn>,<dirn>:[<desc>],[<aiddet>]";

Same response change applies to REPT^ALM^SYNCN

REPT^EVT^<MOD2ALM> response changes : (All platforms)

"<aid>:<condtype>,[<condeff>],,,[<monval>],[<thlev>],[<tmper>]:[<desc>],[<aiddet>]";

"<aid>:<condtype>,[<condeff>],,,[<locn>],[<dirn>],[<monval>],[<thlev>],[<tmper>]:[<desc>],[<aiddet>]";

REPT^EVT^BITS response changes: (All platforms)

"<aid>:<condtype>,[<condeff>],,,,,:[<desc>]";

"<aid>:<condtype>,[<condeff>],,,,,[<locn>],[<dirn>],:[<desc>]";

REPT^EVT^COM response changes: (All platforms)

"[<aid>]:<condtype>,[<condeff>],,,,,:[<desc>]";

"[<aid>]:<condtype>,[<condeff>],,,[<locn>],[<dirn>],,,:[<desc>]";

REPT^EVT^SECU response changes: (All platforms)

"<aid>:<condtype>,<condeff>,,,,,:<security>:<msg>";

"<aid>:<condtype>,<condeff>,,,<locn>,<dirn>,,,:<security>:<msg>";

REPT^EVT^EQPT response changes: (All platforms)

"<aid>:<condtype>,[<condeff>],,,,,,:[<desc>],[<aiddet>]";

"<aid>:<condtype>,[<condeff>],,,,,,[<locn>],[<dirn>]:[<desc>],[<aiddet>]";

Same response change applies to REPT^EVT^SYNCN

RTRV-APC syntax changed:

RTRV-APC[:<TID>]::<CTAG>[::::];

RTRV-APC[:<TID>]:<aid>:<CTAG>[::::];

RTRV-APC response changes:

::[<apcenable>],[<apcstate>]:

[<aid>]::[<apcenable>],[<apcstate>]:

RTRV-BITS response changes:

<aid>::[<linecde>],[<fmt>],[<lbo>],[<syncmsg>],[<aisthrshld>],<saBit>,[<bitsfac>],[<admssm>]:[<pst>]

<aid>::[<linecde>],[<fmt>],[<lbo>],[<syncmsg>],[<aisthrshld>] [<saBit>],[<impedance>],[<bitsfac>],[<admssm>] [<pst>]

(RTRV-BITS enum changes:

SYNC_CLOCK_REF_QUALITY_LEVEL)

(RTRV-CKT-ORIG enum changes:

MOD_PATH)

(RTRV-CKT-TERM enum changes:

MOD_PATH)

RTRV-COND-ALL syntax changed:

RTRV-COND-ALL[:<TID>][:<aid>]:<CTAG>[::<typereq>][,,,];

RTRV-COND-ALL[:<TID>][:<aid>]:<CTAG>[::<typereq>,][<locn>,][<dirn>][,];

RTRV-COND-ALL response changes:

<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],,,[<desc>]

<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],[<location>],[<direction>],[<desc>]

(RTRV-COND-ALL enum changes:

DIRECTION

MOD2B)

RTRV-COND-BITS syntax changed:

RTRV-COND-BITS[:<TID>]:<aid>:<CTAG>[::<typereq>][,,,];

RTRV-COND-BITS[:<TID>]:<aid>:<CTAG>[::<typereq>,][<locn>,][<dirn>][,];

RTRV-COND-BITS response changes:

<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],,,[<desc>]

<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],[<location>],[<direction>],[<desc>]

(RTRV-COND-BITS enum changes:

DIRECTION

MOD2B)

RTRV-COND-EQPT syntax changed:

RTRV-COND-EQPT[:<TID>]:<aid>:<CTAG>[::<typereq>][,,,];

RTRV-COND-EQPT[:<TID>]:<aid>:<CTAG>[::<typereq>,][<locn>,][<dirn>][,];

RTRV-COND-EQPT response changes:

<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],,,[<desc>]

<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],[<location>],[<direction>],[<desc>]

(RTRV-COND-EQPT enum changes:

DIRECTION

MOD2B)

RTRV-COND-SYNCN syntax changed:

RTRV-COND-SYNCN[:<TID>]:<aid>:<CTAG>[::<typereq>][,,,];

RTRV-COND-SYNCN[:<TID>]:<aid>:<CTAG>[::<typereq>,][<locn>,][<dirn>][,];

RTRV-COND-SYNCN response changes:

<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],,,[<desc>]

<aid>,[<aidtype>]:[<ntfcncde>],<typerep>,[<srveff>],[<ocrdat>],[<ocrtm>],[<location>],[<direction>],[<desc>]

(RTRV-COND-SYNCN enum changes:

DIRECTION

MOD2B)

(RTRV-CRS enum changes:

CRS_TYPE (454, 454 SDH : Lotus20gML2Lite)

MOD_PATH)

RTRV-DGN-EQPT response changes:

<aid>:

<slot>:

(RTRV-E1 enum changes:

DIRECTION

SYNC_CLOCK_REF_QUALITY_LEVEL)

(RTRV-E4 enum changes:

PAYLOAD)

RTRV-EQPT response changes:

<aid>:<aidtype>,<equip>,[<role>],[<status>]:[<protid>],[<prtype>],[<rvrtv>],[<rvtm>],[<cardname>],[<ioscfg>],[<cardmode>],[<peerid>],[<regenname>],[<transmode>],[<retime>],[<shelfrole>]:<pst>,[<sst>]

<aid>:<aidtype>,<equip>,[<role>],[<status>]:[<protid>],[<prtype>],[<rvrtv>],[<rvtm>],[<cardname>],[<ioscfg>],[<cardmode>],[<peerid>],[<regenname>],[<peername>],[<transmode>],[<retime>],[<shelfrole>],[<frprole>],[<frpstate>]:<pst>,[<sst>]

(RTRV-EQPT enum changes:

CARDMODE (454, 310MA, 310CL : Lotus20gCE2, Gt3CE2)

FRPROLE

FRPSTATE)

RTRV-FSTE response changes:

<aid>::[<adminstate>],[<linkstate>],[<mtu>],[<flowctrl>],[<optics>],[<duplex>],[<speed>],[<flow>],[<expduplex>],[<expspeed>],[<vlancosthreshold>],[<iptosthreshold>],[<name>],[<soak>],[<soakleft>]:<pst>,[<sst>]

<aid>::[<adminstate>],[<linkstate>],[<mtu>],[<flowctrl>],[<optics>],[<duplex>],[<speed>],[<flow>],[<expduplex>],[<expspeed>],[<vlancosthreshold>],[<iptosthreshold>],[<name>],[<suppress>],[<soak>],[<soakleft>]:<pst>,[<sst>]

RTRV-GIGE response changes:

<aid>:,,<role>,<status>:[ adminstate>],[ linkstate>],[mtu>],[ encap>],[ flowctrl>],[<autoneg>],[hiwmrk>],[<lowmrk>],[<optics>],[<duplex>],[<speed>], [<name>],[<freq>],[<lossb>],[<soak>],[<soakleft>],[<squelch>]:<pst>,<sst>;

<aid>:,,<role>,<status>:[ adminstate>],[ linkstate>],[mtu>],[ encap>],[<flow >],[flowctrl>],[<autoneg>],[hiwmrk>],[<lowmrk>],[<optics>],[<duplex>],[<speed>],[<name>],[<freq>],[<lossb>],[<suppress>],[<soak>],[<soakleft>],[<squelch>], [<cir>],[<cbs>],[<ebs>]:<pst>,<sst>;

(RTRV-G1000 enum changes:

ENCAP)

RTRV-INV response changes:

<aid>,<aidtype>::[<pn>],[<hwrev>],[<fwrev>],[<sn>],[<clei>],[<twl1=nwl in code>],[<pluginvendorid>],[<pluginpn>],[<pluginhwrev>],[<pluginfwrev>],[<pluginsn>],[<ilossref>],[<productId>],[<versionId>],[<fpgaVersion>],[<vendorId>]

<aid>,<aidtype>::[<pn>],[<hwrev>],[<fwrev>],[<sn>],[<clei>],[<twl>],[<pluginvendorid>],[<pluginpn>],[<pluginhwrev>],[<pluginfwrev>],[<pluginsn>],[<ilossref>],[<productId>],[<versionId>],[<fpgaVersion>],[<vendorId>],[<moduletype>]

(RTRV-L2-ETH enum changes:

ETH_BRIDGESTATE

ETH_NIMODE

ETH_QNQMODE)

(RTRV-NE-APC enum changes:

MOD2)

RTRV-NE-GEN response changes :

[IPADDR=<ipaddr>],[IPMASK=<ipmask>],[DEFRTR=<defrtr>],[IIOPPORT=<iiopport>],[NTP=<ntp>],[ETHIPADDR=<ethipaddr>],[ETHIPMASK=<ethipmask>],[NAME=<name>],[SWVER=<swver>],[LOAD=<load>],[PROTSWVER=<protswver>],[PROTLOAD=<protload>],[DEFDESC=<defdesc>],[PLATFORM=<platform>],[SECUMODE=<secumode>],[SUPPRESSIP=<suppressip>],[MODE=<mode>]

[IPADDR=<IPADDR>],[IPMASK=<IPMASK>],[DEFRTR=<DEFRTR>],

[IIOPPORT=<IIOPPORT>],[NTP=<NTP>],[ETHIPADDR=<ETHIPADDR>],

[ETHIPMASK=<ETHIPMASK>],[NAME=<NAME>],[SWVER=<SWVER>],[LOAD=<LOAD>],

[PROTSWVER=<PROTSWVER>],[PROTLOAD=<PROTLOAD>],[DEFDESC=<DEFDESC>],

[PLATFORM=<PLATFORM>],[SECUMODE=<SECUMODE>],[SUPPRESSIP=<SUPPRESSIP>],

[PROXYSRV=<PROXYSRV>],[FIREWALL=<FIREWALL>],[AUTOPM=<AUTOPM>],

[SERIALPORTECHO=<SERIALPORTECHO>

RTRV-NE-PATH response changes:

<rvtm>

<pdip>,<loxcmode>

RTRV-NE-SYNCN response changes:

[<aid>]::[<tmmd>],[<ssmgen>],[<qres>],[<rvrtv>],[<rvtm>]

[<aid>]::[<tmmd>],[<ssmgen>],[<qres>],[<rvrtv>],[<rvtm>],[<systmn>]

(RTRV-NE-SYNCN enum changes:

SYSTEM_TIMING)

(RTRV-NE-WDMANS enum changes: (454, 454 SDH)

MOD2)

RTRV-OCH response changes:

<aid>:,,[<role>],[<status>]:[<rdirn>],[<opticalPortType>],[<power>],[<expWlen>],[<actWlen>],[<iloss>],[<voamode>],[<voaattn>],[<voapwr>],[<voarefattn>],[<voarefpwr>],[<refopwr>],[<calopwr>],[<chpower>],[<portname>],[<sfber>],[<sdber>],[<comm>],[<gccrate>],[<dwrap>],[<fec>],[<payloadmap>],[<lbclcurr>],[<optcurr>],[<oprcurr>],[<osfber>],[<osdber>],[<macaddr>],[<syncmsg>],[<senddus>],[<soak>],[<soakleft>],[<ospf>],[<mfs>]:<pst>,[<sst>]

<aid>:,,[<role>],[<status>]:[<opticalPortType>],[<power>],[<expWlen>],[<actWlen>],[<iloss>],[<voamode>],[<voaattn>],[<voapwr>],[<voarefattn>],[<voarefpwr>],[<refopwr>],[<calopwr>],[<chpower>],[<chpowerFlg>],[<portname>],[<gcc>],[<gccrate>],[<dwrap>],[<fec>],[<payloadmap>],[<lbclcurr>],[<optcurr>],[<oprcurr>],[<osfber>],[<osdber>],[<soak>],[<soakleft>],[<lossb>]:<pst>,[<sst>]

(RTRV-OCH enum changes:

RDIRN_MODE

WDMANS_FLAG)

RTRV-OCHCC response changes:

[<aid>]:<payload>:[<pst>]

<aid>::[<payload>],[<cktId>]:<pst>,[<sst>]

(RTRV-OCHCC enum changes:

MOD1PAYLOAD)

RTRV-OCHNC response changes:

[<src>]:[<wct>]:[<pst>]

<aidsrc>,<aiddst>:<wct>:[<cktId>],[<wlopwr>],[<opwr>],[<voaattn>]:<pst>,[<sst>]

(RTRV-OCHNC enum changes:

WCT)

RTRV-OMS response changes:

<aid>::<rdirn>,<opticalPortType>,[<power>],<expBand>,[<actBand>],[<iloss>],[<voamode>],[<voaattn>],[<voapwr>],[<voarefattn>],[<voarefpwr>],[<refopwr>],[<calopwr>],[<chpower>],[<name>],[<soak>],[<soakleft>]:<pst>,[<sst>]

<aid>::<opticalPortType>,[<power>],<expBand>,[<actBand>],[<iloss>],[<voamode>],[<voaattn>],[<voapwr>],[<voarefattn>],[<voarefpwr>],[<refopwr>],[<calopwr>],[<chpower>],[<chpowerFlg>],[<name>],[<soak>],[<soakleft>]:<pst>,[<sst>]

(RTRV-OMS enum changes:

RDIRN_MODE

WDMANS_FLAG)

RTRV-OPM response changes:

<aid>::[<powerout>],[<poweradd>],[<powerpt>]:

RTRV-OTS response changes:

<aid>::<rdirn>,<opticalPortType>,[<power>],[<iloss>],[<voamode>],[<voaattn>],[<voapwr>],[<voarefattn>],[<voarefpwr>],[<osri>],[<amplmode>],[<chpower>],[<gain>],[<expgain>],[<refopwr>],[<offset>],[<reftilt>],[<caltilt>],[<aseopwr>],[<dculoss>],[<awgst>],[<heatst>],[<name>],[<soak>],[<soakleft>]:<pst>,[<sst>]

<aid>::<opticalPortType>,[<power>],[<iloss>],[<voamode>],[<voaattn>],[<voapwr>],[<voarefattn>],[<voarefpwr>],[<osri>],[<amplmode>],[<amplmodeFlg>],[<chpower>],[<chpowerFlg>],[<gain>],[<expgain>],[<expgainFlg>],[<refopwr>],[<offset>],[<reftilt>],[<reftiltFlg>],[<caltilt>],[<aseopwr>],[<dculoss>],[<awgst>],[<heatst>],[<name>],[<soak>],[<soakleft>]:<pst>,[<sst>]

(RTRV-OTS enum changes:

RDIRN_MODE

WDMANS_FLAG)

(RTRV-PM-ALL enum changes:

DIRECTION)

(RTRV-QNQ-ETH enum changes:

ETH_RULE)

(RTRV-STM1E enum changes:

PAYLOAD)

(RTRV-TH-ALL enum changes:

MOD2B)

(RTRV-TRC-OC48 enum changes:

MOD_PATH)

(RTRV-TRC-OCH enum changes:

MOD2)

RTRV-VC syntax changed:

RTRV-VC[:<TID>]:<aid>:<CTAG>[:::BLSRPTHTYPE=<blsrpthtype>][:];

RTRV-VC[:<TID>]::<CTAG>;

(RTRV-VC enum changes:

PRODUCT_TYPE)

(RTRV-VCG enum changes:

MOD_PATH) (454, 454 SDH : Lotus20gML2Lite)

RTRV-WDMANS response changes: (454, 454 SDH)

<aid>::[<powerIn>],[<powerOut>],[<powerExp>],[<ringType>],[<_opticalNodeType>],[<lastrundat>],[<lastruntm>]:

<aid>::[<powerIn>],[<powerInFlg>],[<powerOut>],[<powerOutFlg>],[<powerExp>],[<powerExpFlg>],[<ringType>],[<opticalNodeType>],[<nepLaunch>],[<fepLaunch>],[<ppmesh>],[<dither>],[<lastrundat>],[<lastruntm>],[<lastcalcdat>],[<lastcalctm>]:

(RTRV-WDMANS enum changes: (454, 454 SDH)

OPTICAL_NODE_TYPE

PPMESH

WDMANS_FLAG)

(RTRV-WLEN enum changes:

WCT)

(SW-TOPROTN-EQPT enum changes:

DIRECTION)

(SW-TOWKG-EQPT enum changes:

DIRECTION)

TL1 ENUM Changes

TL1 ENUM Items Added or Removed

The following section highlights ENUM items changed (added or removed) for Release 8.0, by ENUM type.

AUTOPM_TMPER

AUTOPM_TMPER enum added with the following items in it (all platforms):

AUTOPM_TMPER_NONE

AUTOPM_TMPER_15MIN

AUTOPM_TMPER_1DAY

AUTOPM_TMPER_BOTH

BURST_SIZE

BURST_SIZE enum items added (454, 454 SDH):

BURST_SIZE_128K => "128K"

BURST_SIZE_16K => "16K"

BURST_SIZE_16M => "16M"

BURST_SIZE_1M => "1M"

BURST_SIZE_256K => "256K"

BURST_SIZE_2M => "2M"

BURST_SIZE_32K => "32K"

BURST_SIZE_4K => "4K"

BURST_SIZE_4M => "4M"

BURST_SIZE_512K => "512K"

BURST_SIZE_64K => "64K"

BURST_SIZE_8K => "8K"

BURST_SIZE_8M => "8M"

BURST_SIZE is used in the following commands:

ED-GIGE

RTRV-GIGE

CARDMODE

CARDMODE enum items added (454, 454 SDH):

CARDMODE_10GEXP_L2ETH => "10GEXP-L2ETH"

CARDMODE_10GEXP_TXP => "10GEXP-TXP"

CARDMODE_GEXP_10x1Gx2_MXP => "GEXP-10x1Gx2-MXP"

CARDMODE_GEXP_20x1G_MXP => "GEXP-20x1G-MXP"

CARDMODE_GEXP_L2ETH => "GEXP-L2ETH"

CARDMODE_ML_IEEE_RPR => "ML-IEEE-RPR"

CARDMODE enum items added (454, 310 MA, 310 CL)

CARDMODE_CEMR_AUTO => "CEMR-AUTO" (Lotus20gCE2,Gt3CE2)

CARDMODE_CEMR_MANUAL => "CEMR-MANUAL" (Lotus20gCE2, Gt3CE2)

CARDMODE is used in the following commands (454, 310 MA, 310 CL):

ED-EQPT (Lotus20gCE2,Gt3CE2)

ENT-EQPT (Lotus20gCE2,Gt3CE2)

RTRV-EQPT (Lotus20gCE2,Gt3CE2)

CRS_TYPE

CRS_TYPE enum items added (454, 454 SDH):

CRS_TYPE_STS96C => "STS96C" (Lotus20gML2Lite)

CRS_TYPE is used in the following commands:

RTRV-BULKROLL-OCN-TYPE

RTRV-CRS (Lotus20gML2Lite)

DATALINK

DATALINK enum items added (454, 454 SDH, LMP):

DATALINK_COMPONENT => "COMPONENT"

DATALINK_PORT => "PORT"

DATALINK is used in the following commands:

ENT/ED/RTRV-LMP-DLINK

LMP-DLINK

DIRECTION

DIRECTION enum items added (454, 454 SDH, 310 MA, 310 CL, 600, 600 SDH):

DIRECTION_TD_NA => "NA"

DIRECTION is used in the following commands:

ALW-SWTOPROTN-EQPT

ALW-SWTOWKG-EQPT

EX-SW-OCN-BLSR

INH-SWTOPROTN-EQPT

INH-SWTOWKG-EQPT

INIT-REG-MOD2

OPR-PROTNSW-OCN-TYPE

RLS-PROTNSW-OCN-TYPE

RTRV-ALM-ALL

RTRV-ALM-BITS

RTRV-ALM-EQPT

RTRV-ALM-MOD2ALM

RTRV-ALM-SYNCN

RTRV-COND-ALL

RTRV-COND-BITS

RTRV-COND-EQPT

RTRV-COND-MOD2ALM

RTRV-COND-SYNCN

RTRV-E1

RTRV-PM-ALL

RTRV-PM-MOD2

SW-TOPROTN-EQPT

SW-TOWKG-EQPT

ENCAP

ENCAP enum items added to (454, 454 SDH, 310 MA, 310 CL, 600 SDH):

ENCAP_RPR_GFP_F => "RPR-GFP-F"

ENCAP is used in the following commands:

ED-G1000

ED-POS

RTRV-FC

RTRV-G1000

RTRV-POS

EQPT_TYPE

EQPT_TYPE enum items dropped:

EQPT_TYPE_EQPT_ID_ML2_EXIGE_MAPPER_CARD => "CE-100T-8"

EQPT_TYPE enum items added:

EQPT_TYPE_EQPT_ID_40_DMX_C => "40-DMX-C" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_40_DMX_L => "40-DMX-L" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_40_MUX_C => "40-MUX-C" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_40_MUX_L => "40-MUX-L" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_40_WSS_C => "40-WSS-C" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_40_WSS_L => "40-WSS-L" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_40_WXC_C => "40-WXC-C" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_40_WXC_L => "40-WXC-L" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_ADM_10G => "ADM-10G" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_ADM_10G_OC12 => "ADM-10G-OC12"

EQPT_TYPE_EQPT_ID_ADM_10G_OC192 => "ADM-10G-OC192"

EQPT_TYPE_EQPT_ID_ADM_10G_OC3 => "ADM-10G-OC3"

EQPT_TYPE_EQPT_ID_ADM_10G_OC48 => "ADM-10G-OC48"

EQPT_TYPE_EQPT_ID_CEMR_310 => "CE-MR-6" (310 MA, 310CL: Gt3CE2)

EQPT_TYPE_EQPT_ID_CEMR_454 => "CE-MR-10" (454, 454 SDH, Lotus20gCE2)

EQPT_TYPE_EQPT_ID_ML2_EXIGE_MAPPER => "CE-100T-8" (454, 454 SDH, 310 MA, 310CL)

EQPT_TYPE_EQPT_ID_MLMR_454 => "ML-MR-10" (454, 454 SDH, Lotus20gML2Lite)

EQPT_TYPE_EQPT_ID_MRC25G_12 => "MRC-2.5G-12" (454 SDH)

EQPT_TYPE_EQPT_ID_MRC25G_12_OC12 => "MRC-2.5G-12-OC12 " (454 SDH)

EQPT_TYPE_EQPT_ID_MRC25G_12_OC3 => "MRC-2.5G-12-OC3 " (454 SDH)

EQPT_TYPE_EQPT_ID_MRC25G_12_OC48 => "MRC-2.5G-12-OC48 " (454 SDH)

EQPT_TYPE_EQPT_ID_MRC25G_4 => "MRC-2.5G-4" (454)

EQPT_TYPE_EQPT_ID_MRC25G_4_OC12 => "MRC-2.5G-4-OC12 " (454 SDH)

EQPT_TYPE_EQPT_ID_MRC25G_4_OC3 => "MRC-2.5G-4-OC3 " (454 SDH)

EQPT_TYPE_EQPT_ID_MRC25G_4_OC48 => "MRC-2.5G-4-OC48 " (454 SDH)

EQPT_TYPE_EQPT_ID_MXP_2_5G_10X => "MXP-2.5G-10X" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_MXP_MR_10DMEX => "MXP-MR-10DMEX" (454, 454 SDH, UT3)

EQPT_TYPE_EQPT_ID_OC192_4_DWDM => "OC192-4-DWDM" (600, 600 SDH)

EQPT_TYPE_EQPT_ID_OPT_AMP_17_C => "OPT-AMP-17-C" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_OPT_AMP_23_C => "OPT-AMP-23-C" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_OPT_AMP_C => "OPT-AMP-C" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_PIM_1_PPM => "PIM-1" (600 SDH)

EQPT_TYPE_EQPT_ID_TXPP_MR_10EX => "TXPP-MR-10EX" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_TXP_MR_10EX => "TXP-MR-10EX" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_XP_10GE => "10GE-XP" (454, 454 SDH)

EQPT_TYPE_EQPT_ID_XP_GE => "GE-XP" (454, 454 SDH)

EQUIPMENT_TYPE

EQUIPMENT_TYPE enum items dropped:

EQUIPMENT_TYPE_ET_ML2_EXIGE_MAPPER_CARD => "CE-100T-8"

EQUIPMENT_TYPE enum items added:

EQUIPMENT_TYPE_ET_40_DMX_C => "40-DMX-C" (454, 454 SDH)

EQUIPMENT_TYPE_ET_40_DMX_L => "40-DMX-L" (454, 454 SDH)

EQUIPMENT_TYPE_ET_40_MUX_C => "40-MUX-C" (454, 454 SDH)

EQUIPMENT_TYPE_ET_40_MUX_L => "40-MUX-L" (454, 454 SDH)

EQUIPMENT_TYPE_ET_40_WSS_C => "40-WSS-C" (454, 454 SDH)

EQUIPMENT_TYPE_ET_40_WSS_L => "40-WSS-L" (454, 454 SDH)

EQUIPMENT_TYPE_ET_40_WXC_C => "40-WXC-C" (454, 454 SDH)

EQUIPMENT_TYPE_ET_40_WXC_L => "40-WXC-L" (454, 454 SDH)

EQUIPMENT_TYPE_ET_ADM_10G => "ADM-10G" (454, 454 SDH)

EQUIPMENT_TYPE_ET_CEMR_310 => "CE-MR-6" (310 MA, 310CL: Gt3CE2)

EQUIPMENT_TYPE_ET_CEMR_454 => "CE-MR-10" (454, 454 SDH, Lotus20gCE2)

EQUIPMENT_TYPE_ET_ML2_EXIGE_MAPPER => "CE-100T-8" (454, 454 SDH, 310 MA, 310 CL)

EQUIPMENT_TYPE_ET_MLMR_454 => "ML-MR-10" (454, 454 SDH, Lotus20gML2Lite)

EQUIPMENT_TYPE_ET_MRC25G_12 => "MRC-2.5G-12" (454 SDH)

EQUIPMENT_TYPE_ET_MRC25G_4 => "MRC-2.5G-4" (454)

EQUIPMENT_TYPE_ET_MXP_2_5G_10X => "MXP-2.5G-10X" (454, 454 SDH)

EQUIPMENT_TYPE_ET_MXP_MR_10DMEX => "MXP-MR-10DMEX" (454, 454 SDH, UT3)

EQUIPMENT_TYPE_ET_OC192_4_DWDM => "OC192-4-DWDM" (600,600 SDH)

EQUIPMENT_TYPE_ET_OPT_AMP_17_C => "OPT-AMP-17-C" (454, 454 SDH)

EQUIPMENT_TYPE_ET_OPT_AMP_23_C => "OPT-AMP-23-C" (454, 454 SDH)

EQUIPMENT_TYPE_ET_OPT_AMP_C => "OPT-AMP-C" (454, 454 SDH)

EQUIPMENT_TYPE_ET_PIM_1 => "PIM-1" (600 SDH)

EQUIPMENT_TYPE_ET_STM16_16 => "STM16_16" (600 SDH)

EQUIPMENT_TYPE_ET_STM64_4 => "STM64_4" (600 SDH)

EQUIPMENT_TYPE_ET_STM64_4_DWDM => "STM64-4-DWDM" (600, 600 SDH)

EQUIPMENT_TYPE_ET_TXPP_MR_10EX => "TXPP-MR-10EX" (454, 454 SDH)

EQUIPMENT_TYPE_ET_TXP_MR_10EX => "TXP-MR-10EX" (454, 454 SDH)

EQUIPMENT_TYPE_ET_XP_10GE => "10GE-XP" (454, 454 SDH)

EQUIPMENT_TYPE_ET_XP_GE => "GE-XP" (454, 454 SDH)

EQUIPMENT_TYPE

EQUIPMENT_TYPE is used in the following commands:

CHG-EQPT

ENT-EQPT

ETH_BRIDGESTATE

ETH_BRIDGESTATE enum items added (454, 454 SDH):

ETH_BRIDGESTATE_BLOCKING => "BLOCKING"

ETH_BRIDGESTATE_BROKEN => "BROKEN"

ETH_BRIDGESTATE_DISABLED => "DISABLED"

ETH_BRIDGESTATE_FORWARDING => "FORWARDING"

ETH_BRIDGESTATE_LEARNING => "LEARNING"

ETH_BRIDGESTATE_LISTENING => "LISTENING"

ETH_BRIDGESTATE_UNKNOWN => "UNKNOWN"

ETH_BRIDGESTATE is used in the following commands:

ED-L2-ETH

RTRV-L2-ETH

ETH_NIMODE

ETH_NIMODE enum items added (454, 454 SDH):

ETH_NIMODE_NNI => "NNI"

ETH_NIMODE_UNI => "UNI"

ETH_NIMODE is used in the following commands:

ED-L2-ETH

RTRV-L2-ETH

ETH_QNQMODE

ETH_QNQMODE enum items added (454, 454 SDH):

ETH_QNQMODE_SELECTIVE => "SELECTIVE"

ETH_QNQMODE_TRASPARENT => "TRASPARENT"

ETH_QNQMODE is used in the following commands:

ED-L2-ETH

RTRV-L2-ETH

ETH_RULE

ETH_RULE enum items added:

ETH_RULE_ADD => "ADD"

ETH_RULE_XLTE => "XLTE"

ETH_RULE is used in the following commands:

ED-QNQ-ETH

ENT-QNQ-ETH

RTRV-QNQ-ETH

FRPROLE

FRPROLE enum items added to (454, 454 SDH):

FRPROLE_MASTER => "MASTER"

FRPROLE_SLAVE => "SLAVE"

FRPROLE is used in the following commands:

ED-EQPT

ENT-EQPT

RTRV-EQPT

FRPSTATE

FRPSTATE enum items added (454, 454 SDH):

FRPSTATE_DISABLED => "DISABLED"

FRPSTATE_ENABLED => "ENABLED"

FRPSTATE_FORCED => "FORCED"

FRPSTATE is used in the following commands:

ED-EQPT

ENT-EQPT

RTRV-EQPT

MOD1PAYLOAD

MOD1PAYLOAD enum items added (454):

MOD1PAYLOAD_ILK => "ILK"

MOD1PAYLOAD_OCH => "OCH"

MOD1PAYLOAD_OTU2 => "OTU2"

MOD1PAYLOAD is used in the following commands:

RTRV-OCHCC

MOD2

MOD2 enum items dropped:

MOD2_M2_OCHNC => "OCHNC"

MOD2 enum items added (454, 454 SDH):

MOD2_M2_ETH => "ETH" (454, 454 SDH, 310 MA, 310CL, Lotus20gCE2, Gt3CE2)

MOD2_M2_ILK => "ILK" (454)

MOD2_M2_OTU2 => "OTU2" (454, 454 SDH)

MOD2_M2_STS96C => "STS96C" (454, 454 SDH, Lotus20gML2Lite)

MOD2 is used in the following commands:

ED-OCHCC

RTRV-FFP-MOD2

RTRV-NE-APC

RTRV-NE-WDMANS

RTRV-TRC-OCH

SCHED-PMREPT-MOD2

RTRV-PMSCHED-ALL

RTRV-PMSCHED-MOD2

RTRV-TRC-MOD2

MOD2ALM

MOD2ALM enum items added:

MOD2ALM_M2_ETH => "ETH" (454, 454 SDH, 310 MA, 310CL, Lotus20gCE2, Gt3CE2)

MOD2ALM_M2_ILK => "ILK" (454)

MOD2ALM_M2_LMP => "LMP" (454, 454 SDH)

MOD2ALM_M2_OTU2 => "OTU2" (454, 454 SDH)

MOD2ALM_M2_RPRIF => "RPRIF" (454, 454 SDH)

MOD2ALM_M2_STS96C => "STS96C" (454, 454 SDH)

MOD2ALM is used in the following commands:

RTRV-ALM-MOD2ALM

RTRV-COND-MOD2ALM

MOD2B

MOD2B enum items added:

MOD2B_M2_ETH => "ETH" (454, 454 SDH, 310 MA, 310CL, Lotus20gCE2, Gt3CE2)

MOD2B_M2_ILK => "ILK" (454)

MOD2B_M2_OTU2 => "OTU2" (454, 454 SDH)

MOD2B_M2_RPRIF => "RPRIF" (454, 454 SDH)

MOD2B_M2_STS96C => "STS96C" (454, 454 SDH, Lotus20gML2Lite)

MOD2B is used in the following commands:

ALS

RTRV-ALM-ALL

RTRV-ALM-BITS

RTRV-ALM-EQPT

RTRV-ALM-SYNCN

RTRV-COND-ALL

RTRV-COND-BITS

RTRV-COND-EQPT

RTRV-COND-SYNCN

RTRV-PM-MOD2

RTRV-TH-ALL

RTRV-TH-MOD2

MOD2O

MOD2O enum items added:

MOD2O_M2_ILK => "ILK" (454)

MOD2O_M2_OTU2 => "OTU2" (454, 454 SDH)

MOD2O is used in the following commands:

RTRV-ALMTH-MOD2O

MOD2_DATA

MOD2_DATA enum items added:

MOD2_DATA_M2_ETH => "ETH" (454, 454 SDH, 310 MA, 310CL, Lotus20gCE2, Gt3CE2)

MOD2_DATA is used in the following commands:

DLT-RMONTH-MOD2-DATA

MOD_PATH enum items added:

MOD_PATH_M2_STS96C => "STS96C" 454, 454 SDH, Lotus20gML2Lite)

MOD_PATH is used in the following commands:

ENT-CKT-ORIG

ENT-CKT-TERM

ENT-VCG

RTRV-CKT-ORIG

RTRV-CKT-TERM

RTRV-CRS

RTRV-PATH

RTRV-TRC-OC48

RTRV-VCG

MUXCAP

MUXCAP enum items added (Multishelf 454, 454 SDH):

MUXCAP_FIBER => "FIBER"

MUXCAP_LAMBDA => "LAMBDA"

MUXCAP_LAYER2 => "LAYER2"

MUXCAP_PKTSWITCH1 => "PKTSWITCH1"

MUXCAP_PKTSWITCH2 => "PKTSWITCH2"

MUXCAP_PKTSWITCH3 => "PKTSWITCH3"

MUXCAP_PKTSWITCH4 => "PKTSWITCH4"

MUXCAP_TDM => "TDM"

MUXCAP is used in the following commands:

ED-LMP

LMP-TLINK

RTRV-LMP-TLINK

OPSTATE

OPSTATE enum items added (454, 454 SDH):

OPSTATE_ACTIVE => "ACTIVE"

OPSTATE_ACT_FAILED => "ACT-FAILED"

OPSTATE_CFG_RCV => "CFG-RCV"

OPSTATE_CFG_SND => "CFG-SND"

OPSTATE_DEGRADED => "DEGRADED"

OPSTATE_DOWN => "DOWN"

OPSTATE_GOING_DOWN => "GOING-DOWN"

OPSTATE_GOING_UP => "GOING-UP"

OPSTATE_INIT => "INIT"

OPSTATE_TESTING => "TESTING"

OPSTATE_UNKNOWN => "UNKNOWN"

OPSTATE_UP => "UP"

OPSTATE_UP_ALLOC => "UP-ALLOC"

OPSTATE_UP_FREE => "UP-FREE"

OPSTATE is used in the following commands:

RTRV-LMP

RTRV-LMP-CTRL

RTRV-LMP-DLINK

RTRV-LMP-TLINK

OPTICAL_NODE_TYPE

OPTICAL_NODE_TYPE enum items added:

OPTICAL_NODE_TERMINAL => "TERMINAL"

OPTICAL_NODE_TYPE is used in the following commands:

RTRV-WDMANS

PAYLOAD

PAYLOAD enum items dropped:

PAYLOAD_PT_ETHER => "ETHERNET"

PAYLOAD enum items added:

PAYLOAD_PT_ETHER => "ETH" (454, 454 SDH, 310 MA, 310CL, Lotus20gCE2, Gt3CE2)

PAYLOAD_PT_ILK => "ILK"

PAYLOAD_PT_OCH => "OCH"

PAYLOAD_PT_OTU2 => "OTU2"

PAYLOAD is used in the following commands:

ED/RTRV-FAC

ED/RTRV-E4

ED/RTRV-STM1E

PMMODE

PMMODE enum items added:

PMMODE_PROPRIETARY => "PROPRIETARY"

PMMODE_STD => "STD"

PMMODE is used in the following commands:

ED/RTRV-OTU2

PORTRATE

PORTRATE enum items added (454, 454 SDH):

OC12 => "OC12"

OC192 => "OC192"

OC3 => "OC3"

OC48 => "OC48"

PORTRATE is used in the following commands:

CHG-EQPT

PPMESH

PPMESH enum items added (454, 454 SDH):

PPMESH_DEGREE_4 => "DEGREE-4"

PPMESH_DEGREE_8 => "DEGREE-8"

PPMESH_DEGREE_UNKNOWN => "DEGREE-UNKNOWN"

PPMESH is used in the following commands:

ED/RTRV-WDMANS

PRODUCT_TYPE

PRODUCT_TYPE enum items added: (600 SDH):

PRODUCT_TYPE_NE_15600SDH => "ONS15600SDH"

PRODUCT_TYPE is used in the following commands:

RTRV-MAP-NETWORK

RTRV-VC

RDIRN_MODE

RDIRN_MODE enum items dropped from Release 7.0 and 8.0 (454, 454 SDH):

RDIRN_MODE_RDIRN_E_W => "E-W"

RDIRN_MODE_RDIRN_W_E => "W-E"

RDIRN_MODE is used in the following commands:

ED-OCH

ED-OMS

ED-OTS

RTRV-OCH

RTRV-OMS

RTRV-OTS

REACH

REACH enum items added:

REACH_CWDM => "CWDM"

REACH_DWDM => "DWDM"

REACH_ZR => "ZR"

REACH is used in the following commands:

ED-DWDM-CLNT

ED-FC

ED-GIGE

ED-OCH

ED-OCN-TYPE

ED-OTU2

RTRV-DWDM-CLNT

RTRV-FC

RTRV-GIGE

RTRV-OCH

RTRV-OCN-TYPE

RTRV-OTU2

REGULATED_PORT_TYPE

REGULATED_PORT_TYPE enum items added:

REGULATED_PORT_MISSING_PARAM => "MISSING-PARAM"

REGULATED_PORT_TYPE is used in the following commands:

RTRV-NE-WDMANS

REPTPM_TYPE

REPTPM_TYPE enum added with the following items in it (all platforms)

REPTPM_TYPE_NONE

REPTPM_TYPE_AUTO

REPTPM_TYPE_SCHED

REPTPM_TYPE_BOTH

REPTPM_TYPE

REPTPM_TYPE is used in the following commands:

SCHED-PMREPT-<MOD2>

RFILE

RFILE enum items added (454, 454 SDH, 310 MA, complete Db backup):

RFILE_COMPDB => "RFILE-COMPDB"

RFILE is used in the following commands:

COPY-IOSCFG

COPY-RFILE

RPRSPAN_DIRN

RPRSPAN_DIRN enum items added (454, 454 SDH):

RPRSPAN_EAST => "EAST"

RPRSPAN_WEST => "WEST"

RPRSPAN_DIRN is used in the following commands:

ED/RTRV-POS

SYNC_CLOCK_REF_QUALITY_LEVEL

SYNC_CLOCK_REF_QUALITY_LEVEL enum items added:

SYNC_CLOCK_REF_QUALITY_LEVEL_QREF_SSM_FAILED => "SSM-FAILED"

SYNC_CLOCK_REF_QUALITY_LEVEL is used in the following commands:

ED-BITS

ED-E1

ED-OCN-TYPE

ED-T1

RTRV-BITS

RTRV-E1

RTRV-OCN-TYPE

RTRV-SYNCN

RTRV-T1

SYSTEM_TIMING

SYSTEM_TIMING enum items added:

SYSTEM_TIMING_SDH => "SDH"

SYSTEM_TIMING_SONET => "SONET"

SYSTEM_TIMING is used in the following commands:

ED-NE-SYNCN

RTRV-NE-SYNCN

VALIDITY

VALIDITY enum items dropped:

VALIDITY_CV_OFF => "OFF"

VALIDITY enum items added:

VALIDITY_CV_OFF => "NA"

VALIDITY is used in the following commands:

RTRV-PM-MOD2

WCT

WCT enum items added:

WCT_DIAG => "DIAG"

WCT_TWOWAYDCN => "2WAYDCN"

WCT is used in the following commands:

ENT-OCHNC

RTRV-OCHNC

RTRV-WLEN

WDMANS_FLAG

WDMANS_FLAG enum items added (454, 454 SDH):

WDMANS_FLAG_CALC => "CALC"

WDMANS_FLAG_CALC => "ERROR"

WDMANS_FLAG_CALC => "FE-COM-ERROR"

WDMANS_FLAG_CALC => "FE-NOT-SUPPORTED"

WDMANS_FLAG_CALC => "IMPORTED"

WDMANS_FLAG_CALC => "INFO-OUT-OF-RANGE"

WDMANS_FLAG_CALC => "NE-COM-ERROR"

WDMANS_FLAG_CALC => "NO-AD-OUT-PWR"

WDMANS_FLAG_CALC => "NO-FE-LPWR"

WDMANS_FLAG_CALC => "NO-FE-OSC-LPWR"

WDMANS_FLAG_CALC => "NO-FSTAGE-IL"

WDMANS_FLAG_CALC => "NO-PRE-TILT"

WDMANS_FLAG_CALC => "NO-SPAN-LOSS"

WDMANS_FLAG_CALC => "NOT-SUPPORTED"

WDMANS_FLAG_DFLT => "DFLT"

WDMANS_FLAG_PROV => "PROV"

WDMANS_FLAG is used in the following commands:

RTRV-OCH

RTRV-OMS

RTRV-OTS

RTRV-WDMANS

WDMANS_MODE

WDMANS_MODE enum items added (454, 454 SDH):

WDMANS_MODE_ALL => "ALL"

WDMANS_MODE_CALC => "CALC"

WDMANS_MODE_SETUP => "SETUP"

WDMANS_MODE is used in the following commands:

OPR-WDMANS

WDM_ROLE enum items added (Multishelf 454, 454 SDH):

ROLE_OLS => "OLS"

ROLE_PEER => "PEER"

WDM_ROLE is used in the following commands:

ED/RTRV-LMP

Related Documentation

Release-Specific Documents

Release Notes for the Cisco ONS 15454, Release 7.2

Release Notes for the Cisco ONS 15454 SDH, Release 8.0

Release Notes for the Cisco ONS 15600 SDH, Release 8.0

Release Notes for the Cisco ONS 15600, Release 8.0

Release Notes for the Cisco ONS 15310-CL, Release 8.0

Release Notes for the Cisco ONS 15310-MA, Release 8.0

Cisco ONS 15454 Software Upgrade Guide, Release 8.0

Platform-Specific Documents

Cisco ONS 15454 Procedure Guide
Provides installation, turn up, test, and maintenance procedures

Cisco ONS 15454 Reference Manual
Provides technical reference information for SONET/SDH cards, nodes, and networks

Cisco ONS 15454 DWDM Installation and Operations Guide
Provides technical reference information for DWDM cards, nodes, and networks

Cisco ONS 15454 Troubleshooting Guide
Provides a list of SONET alarms and troubleshooting procedures, general troubleshooting information, and hardware replacement procedures

Cisco ONS SONET TL1 Command Guide
Provides a comprehensive list of TL1 commands

Cisco ONS 15454 and Cisco ONS 15454 SDH Ethernet Card Software Feature and Configuration Guide
Provides technical reference and configuration information for Ethernet cards.

Obtaining Documentation, Obtaining Support, and Security Guidelines

For information on obtaining documentation, obtaining support, providing documentation feedback, security guidelines, and also recommended aliases and general Cisco documents, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html


hometocprevnextglossaryfeedbacksearchhelp

Posted: Wed Jun 27 12:03:04 PDT 2007
All contents are Copyright © 1992--2007 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.