Release Notes for Cisco ONS 15454 Release 4.5
2.5G Multi-Rate Transponder Cards
DDTS # CSCeb26662 and CSCea88023
Maintenance and Administration
DDTS # CSCdx40462, CSCdx47176, CSCdw22170
ONS 15454 Conducted Emissions Kit
DDTS # CSCdv10824: Netscape Plugins Directory
Transponder (TXP_MR_10G) and Muxponder (MXP_2.5G_10G) Documentation
Resolved Software Caveats for Release 4.5
New Features and Functionality
Optical Service Channel Modules
Multiplexer and Demultiplexer Cards
Optical Add Drop Multiplex Cards
2.5G_MR_TXP and 2.5G_MR_TXP-P Cards
New Software Features and Functionality
Optical Service Channel & Supervisory Bus
DWDM Network Topology Discovery
Parameter, Operation, and Syntax Changes
Obtaining Technical Assistance
Contacting TAC by Using the Cisco TAC Website
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 4.1 and 4.5” version of the Cisco ONS 15454 Procedure Guide; Cisco ONS 15454 Reference Guide; Cisco ONS 15454 Troubleshooting Guide; and Cisco ONS 15454 and Cisco ONS 15327 TL1 Command Guide. For the most current version of the Release Notes for Cisco ONS 15454 Release 4.5, visit the following URL:
https://www.cisco.com/c/en/us/td/docs/optical/15000r4_5/release/notes/454rn45.html
Cisco also provides Bug Toolkit, a web resource for tracking defects. To access Bug Toolkit, visit the following URL:
This section documents supplemental changes that have been added to the Release Notes for Cisco ONS 15454 Release 4.5 since the production of the Cisco ONS 15454 System Software CD for Release 4.5.
The following changes have been added to the release notes for Release 4.5
A Note on page 6 has been added to the release notes for Release 4.5.
Review the notes listed below before deploying the ONS 15454. Caveats with DDTS tracking numbers are known system limitations that are scheduled to be addressed in a subsequent release. Caveats without DDTS tracking numbers are provided to point out procedural or situational considerations when deploying the product.
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:
Occasionally CTC displays a LO-TXPOWER alarm when SMT4 and STM1 SFP is installed at the client port of a TXP or TXPP card. The LO-TXPOWER alarm is displayed when the alarm threshold is set to the default value in the TX POWER LOW field of the Optical Threshold in the CTC provisioning window. To work around this issue, lower the alarm threshold value (TX POWER LOW (dBm)) of Optical Threshold in the CTC provisioning window. Refer to Table XX for threshold values. This issue will be resolved in Release 4.6.
Table 1 contains the High and Low Alarm Thresholds of Tx-power and Rx-power of SFPs in TXP and TXPP cards. The values of these thresholds are read from the EEPROM inside the SFPs. This table can be used as a reference in PM alarm provisioning and Threshold Alarm verification.
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.
A soft reset of the working or protect 2.5g multirate card in a Y-cable protection group clears an existing "Lockout of protection" request. It is not known when or if this issue will be resolved.
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. It is not known when or if this issue will be resolved.
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 is under investigation.
The 2G Fiber Channel (FC) payload data type in the TXP_MR_2.5G and TXPP_MR_2.5G cards does not support any 8B/10B Payload PM monitoring. This is as designed.
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.
SCHED-PMREPT-CLNT does not generate the automatic report for TXPP cards. If you schedule PM reports on a Client or Trunk port of a TXPP, REPT^PM^EVT is never generated. However, the RTRV-PMSCHED-ALL count shows that the count is decreasing. This issue will be resolved in Release 4.6.
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.
The Lamp Test feature does not display all the LED colors available on the 2.5G Transponder. This issue will be resolved in Release 4.6.
Near end and far end PMs might increment simultaneously on TXPP-2.5G cards. This can occur when two nodes have TXPP-2.5G cards and two nodes have STM16 cards in a four node network, where both TXPP-2.5G cards have STM16 SFPs on them, and are in MS (Line Termination) mode. By default, the TXPP-2.5G cards are in Splitter protection: the first DWDM port is working and the second is protect. If you remove the receive fiber of the first DWDM port on one TXPP-2.5G card, both near and far end counts begin to increment. The far end counts should not increment in this case. This issue is seen only when the Txpd cards have G709 and FEC on. If the cards have G709 and FEC off, only the near end counts will increment, as expected. This issue will be resolved in Release 4.6.
With TXP-MR-2.5G cards, when the current 1 day Optics PM rolls over, the information is inaccurate for “avgs.” This issue is under investigation for resolution in a future release.
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.
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.
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.
In a Y-Cable protection group, if GCCs are defined on both cards, both cards' active LEDs will be green.
For the TXPP, attenuating Port 2 Rx signal, SD, and SF alarms are not declared before LOC 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.
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.
Rarely, when the active TCC2 is removed, small traffic errors of 2 to 30 ms can sometimes occur, especially on boards with OCN ASIC. To avoid this issue, switch to the protect TCC2 before removing the working TCC2. This issue is under investigation.
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 build 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.
The TCC2 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 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 “DLP-A 21 Install LAN Wires on the Backplane” procedure in the user documentation.
Active TCC2 cards should not be removed. If the active TCC2 card must be removed, to minimize network interruption you can first perform a lockout on all circuits that originate from the node whose active TCC2 will be removed (performing a lockout on all spans will also accomplish the same goal). No lockout is necessary for switches initiated through CTC.
Note Release 4.5 supports DWDM applications only. You may not upgrade from an earlier release to Release 4.5.
Cisco ONS platforms ship with a Java Runtime Environment (JRE) from Sun Microsystems. Occasionally Sun releases maintenance releases to the JRE. The Sun Microsystems website lists JRE maintenance releases and the issues resolved for each. Cisco recommends that you review these listings to determine if the issues resolved in any given JRE maintenance release warrant a JRE upgrade for your particular network. Cisco tests only with the specific JRE actually shipped with the ONS software CD.
In the Network View, a Terminal site for which only the boards but not the connections between them are provisioned is displayed as “unknown site.” In the provisioning panel the type shown is Terminal, but it is not possible to insert Power values. To correct this, create the connections between the boards. This issue will be resolved in a future release.
At the end of a software reset sequence, both the OPT-PRE and OPT-BST cards override the OSRI command. The resulting effect is that if an amplifier is switched off by OSRI command and then is affected by a software reset command, it switches on the power output at the power set value. Avoid inspecting the amplifier optical connectors via a microscope tool when the unit is powered on or there is an optical signal connected to its input port (COM RX port). This issue will be resolved in a future release.
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:
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.
If a user is logged into CTC as a superuser (or other higher level security type), and then another superuser changes the first user's security level to “retrieve” (or another lower level security type) without first logging the user out, the lower level user is then still able to perform some actions authorized only for the original login security level. For example, a “provisioning” level user demoted to “retrieve” level in this manner can still provision and edit MS-SPRings (BLSRs) while logged into the current session, though the same user may no longer provision DCCs. To ensure that a user's level is changed completely, the superuser must log the user out prior to changing the security level. This issue is under investigation.
In the Maintenance > Cross Connect Resource Pane, the VT matrix port detail is inconsistent with the general VT matrix data. This can occur when a 1+1 protection scheme is in place. To avoid confusion, note that the VT matrix data counts the VTs for both the working and protect card, while the detail data counts the VTs only for the working card. This issue is under investigation.
Rarely, CTC Network view can freeze following the deletion or addition of a node from or to a BLSR/MS-SPRing. This can result in the CTC Network view no longer updating correctly. If this occurs, restart CTC. This issue will be resolved in Release 5.0.
CTC does not support adding/creating more than 5 circuits in auto-ranged provisioning. This is as designed.
The UCP ND-FAIL alarm is not functional. This issue will be resolved in a future release.
An LOP-P alarm can be inadvertently cleared by an LOS that is raised and cleared. On OC48AS, OC192, and OC12-4 cards, when an LOP condition and an LOS condition are both present on the input, an LOS will be raised as per Telcordia GR 253 alarm hierarchy. However, upon clearing the LOS with the LOP still present, the LOP alarm, which should then be raised, is not. An AIS-P condition will be visible. This issue will be resolved in a future release.
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:
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.
Far end path FC-P is not counted on EC1 or OC3 cards. When a path defect is transmitted to the far end, it reports RDI-P. However, the condition is not examined and reported as a PM count. This issue will be resolved in a future release.
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.
In a 1:N protection group, where a protect card is protecting a failed card and another working card, which is missing, has a lockon condition, upon removing the lockon condition from the missing working card, the protect card may switch from the card it had been protecting to carry the traffic of the missing working card that just had the lockon removed. To avoid this issue, replace the failed working card before removing the lockon. This issue will be resolved in a future release.
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.
The following caveats apply for NE defaults when managing older, non-Release 4.5 nodes.
The terminology used for provisioning overhead circuits has changed as of Release 3.4 as follows.
Note These circuits are now provisioned at the network level, rather than on a node-by-node basis.
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 be resolved in a future release.
While upgrading nodes from releases prior to 3.2, CTC might lose connection to the far end nodes. When this occurs, you will not be able to ping the grayed-out nodes; however, if you continue the upgrade, this problem resolves itself. This issue is resolved in Release 3.2, but can still occur when upgrading from nodes with earlier software releases.
XCVTs (both active and standby) reboot continuously when the K3 byte is mapped to the E2 byte on one side of a WTR span. The rebooting occurs after the WTR timer expires. This has been seen on a two fiber BLSR with OC-48AS. To avoid this issue, if possible, change the K3 mapping on both ends of the span before creating the ring; or, alternatively, you can prevent the ring from reverting during the K3 mapping by setting the Ring Reversion time to “never.” Once you have completed the mapping of the K3 byte to the E2 byte on both sides, return the Ring Reversion to its normal value. This issue will be resolved in a future release.
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.
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.
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.
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.
The documentation set for the Cisco ONS 15454 contains references to new transponder (TXP_MR_10G) and muxponder (MXP_2.5G_10G) cards. These portions of the documentation are meant to refer to cards that will become available with Release 4.6. These nXP cards are not available with Release 4.5. Cisco apologizes for any confusion this may cause.
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.
When running release 4.1.4, if a circuit is created within CTC and if that circuit is retrieved via TL1, all looks as expected. However, after the software is upgraded to release 6 and latter, the circuit retrive does not show the same value as was before. For example FAC-4-1 changes to FAC-4-0. Workaround is to delete and recreate the circuit within CTC
When you have a TL1 session with active test access connections and you activate a new software load, the Test Access traffic will remain after the software activation. To avoid this, remove test access connections or disconnect the TL1 session before activation. To recover after this has already happened, create or delete a circuit or test access following the activation. This issue will be resolved in a future release.
In one rare case, the ONS 15454/15327 times out a user session without communicating the timeout to TL1. If this happens, the TL1 user remains logged in, although the session is actually timed out. This can occur when you log into the node with a timeout of X minutes. If the user session sits idle for all but 5 seconds of the X minutes, then you have only 5 seconds to type in a command to notify the node that the session is active. If you try this, you will likely miss the five second window, in which case the node will respond as though the session is inactive and deny access. However, because you have typed a key, irrespective of the five second window, TL1 responds as though the session is active and does not log you out (time out). You will not have access to the node and will receive a “DENY” response to TL1 commands. The error message may vary depending on commands issued. To recover from this situation, log out and log back in to TL1. This issue will be resolved in Release 5.0.
The TL1 COPY-RFILE command, used for SW download, database backup, and database restore, currently does not allow a user-selected port parameter to make connections to the host. The command expects the default parameter of Port 21 and will only allow that number. This issue will be resolved in Release 5.0
The default state, when no PST or SST inputs are given for The TL1 command, RMV-<MOD2_IO>, is OOS instead of OOS-MT. Thus, if you issue a RMV statement, followed by maintenance-state-only commands, such as OPR-LPBK, the maintenance state commands will not work, since the port will be in the out-of-service state (OOS), instead of the out-of-service maintenance state (OOS-MT). To work around this issue, place ports in the OOS-MT state, by specifying the primary state as OOS and a secondary state of MT in either the RMV-<MOD2_IO> command or the ED-<MOD2_IO> command.
Scripts that depend on the RMV-<MOD2_IO> command defaulting to OOS-MT without specifying the primary and secondary states should be updated to force the primary and secondary state inputs to be populated. This issue will be resolved in Release 5.0.
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.
This section is for items are resolved in Release 4.5. Because Release 4.5 is a first DWDM release, there are no resolved items in this section.
New Features and FunctionalityThis section highlights new features and functionality for Release 4.5. For detailed documentation of each of these features, consult the user documentation.
An optical service channel (OSC) is a bidirectional channel connecting all the nodes in a ring. The channel transports OSC overhead that is used to manage ONS 15454 DWDM networks. The OSC uses the 1510 nm wavelength and does not affect client traffic, because the OSC signal is outside the client traffic band (OOB). The primary purpose of this channel is to carry supervision and management traffic for the DWDM network. It also provides transparent links between each node in the network. The OSC is an OC-3 formatted signal.
There are two versions of the OSC modules, OSCM and OSC-CSM with a combiner and separator module.
The OSCM is used in amplified nodes that include the booster amplifier called the OPT-BST. The OPT-BST includes the required OSC wavelength combiner and separator component. The OSCM cannot be used in nodes where you want to use OC-N cards, electrical cards, or cross-connect cards. The OSCM uses Slots 8 and 10 which are also cross-connect card slots. The cross-connect cards enable functionality on the OC-N cards and electrical cards.
Release 4.5 does not support DWDM cards and features along with cross-connect, OC-N, and electrical cards.
The OSCM supports the following features:
The OC-3 SDCC overhead bytes are used for network communications. An optical transceiver terminates the OC-3 then it is regenerated and converted into an electrical signal. The SDCC bytes are forwarded to the active and standby TCC2 cards for processing via the SCL bus on the backplane. The OSCM is able to terminate/insert the F1 User channel in the Overhead of OC-3 / STM-1 frame. The F1 is forwarded to the AIC-I and made available via a G.703 interface at 64Kb/s. Order-wire bytes (E1, E2) are also forwarded via the SCL bus to the TCC2 for forwarding to the AIC-I card.
The payload portion of the OC-3 is used to carry the fast Ethernet user data channel. The frame is sent to a POS processing block that extracts the Ethernet packets and makes it available at the RJ-45 connector.
The OSC-CSM is used in all the nodes where OPT-BST is not needed/used. The OSC-CSM can be installed in Slots 1-6 and 12-17. OSC-CSM will be used in the future with OPT-BST to support configurations where both OPT-BST and XC units are required (hybrid).
Note Release 4.5 does not support DWDM cards and features along with cross-connect, OC-N, and electrical cards.
The OSC-CSM supports the following features:
The WDM signal coming from the line is passed through the OSC combiner and separator where the OSC signal is extracted from the WDM signal. The WDM signal is sent along with the remaining channels to the COM port (label on the front panel) for routing to the OADM or amplifier units, while the OSC signal is sent to an optical transceiver.
The OSC is an OC-3 formatted signal. The OC-3 SDCC overhead bytes are used for network communications. An optical transceiver terminates the OC-3 then it is regenerated and converted into an electrical signal. The SDCC bytes are forwarded to the active and standby TCC2 cards for processing via the SCL bus on the backplane. The OSCM is able to terminate/insert the F1 User channel in the Overhead of OC-3 / STM-1 frame. The F1 is forwarded to the AIC-I and made available via a G.703 interface at 64Kb/s. Order-wire bytes (E1, E2) are also forwarded via the SCL bus to the TCC2 for forwarding to the AIC-I card.
The payload portion of the OC-3 is used to carry the fast Ethernet user data channel. The frame is sent to a POS processing block that extracts the Ethernet packets and makes it available at the RJ-45 front panel connector.
The OSC-CSM distributes the reference clock information by removing it from the incoming OC-3 signal and then sending it to the active and standby TCC2s.
Optical amplifiers are used in amplified nodes such as hub nodes, amplified OADM nodes, terminal nodes, and line amplifier nodes. There are two forms of amplifiers, the optical preamplifier (OPT-PRE) and the optical booster amplifier (OPT-BST). For more information consult the user documentation. The optical amplifier card architecture includes an optical plug-in module with a controller that manages optical power, laser current, and temperature control loops.
The OPT-PRE can operate in two modes:
In constant gain rings, the APC (Automatic Power Control) feature will compensate any span degradation.
In constant power mode, automatic power control (APC) requirements change since span loss degradation does not effect the system and amplifiers are not able to automatically modify the output power for variations in the number of channels when provisioning changes and a failure occurs.
The OPT-BST is always operated in Constant Gain Mode. Its optical gain is limited to 20 dB.
The OPT-PRE is designed to support 64 channels at 50 GHz channel spacing, but currently Release 4.5 supports 32 channels at 100 GHz. The OPT-PRE is a C-band DWDM, two-stage EDFA with mid-stage access loss (MAL) for allocation to a dispersion compensation unit (DCU). To control the gain tilt, the OPT-PRE is equipped with a built-in variable optical attenuator (VOA). The VOA can also be used to pad the DCU to a reference value. You can install the OPT-PRE in Slots 1-6 and 12-17.
The OPT-PRE has four signal photodiodes to monitor the input and output optical power of the two amplifier stages through CTC. The OPT-PRE also has an optical output port for external monitoring.
The OPT-BST is designed to support 64 channels at 50 GHz channel spacing, but currently Software R4.5 supports 32 channels at 100 GHz. The OPT-BST is a C-band DWDM EDFA with optical service channel add and drop capability. When an ONS 15454 has an OPT-BST installed, it is only necessary to have the optical service channel module (OSCM) to process the OSC. You can install the OPT-BST in Slots 1-6 and 12-17. To control the gain tilt, the OPT-BST is equipped with a built-in variable optical attenuator (VOA).
The OPT-BST amplifier supports optical safety remote interlock (OSRI) and automatic laser shutdown (ALS). The OSRI is a feature capable of shutting down the optical output power or reducing the power to a safe level (automatic power reduction). The ALS feature is a safety mechanism used in the event of a fiber cut.
The 32 channel multiplex card multiplexes 32 100 GHz spaced channels identified in the channel plan. The 32MUX-O takes up two slots in an ONS 15454 and can be installed in Slots 1-6 and 12-17. The 32MUX-O features include
Each single channel port is equipped with VOAs for automatic optical power regulation prior to multiplexing. In the case of electrical power failure, the VOA is set to its maximum attenuation (or to a fixed and configurable value) for safety purposes. A manual VOA setting is also available.
Each single channel port is monitored using a photodiode to enable automatic power regulation.
An additional optical monitoring port with 1/99 splitting ratio is available.
The 32 channel demux card demultiplexes 32 100 GHz spaced channels identified in the channel plan. The 32DMX-O takes up two slots in an ONS 15454 and can be installed in Slots 1-6 and 12-17. The 32DMX-O features include
Each single channel port is equipped with VOAs for automatic optical power regulation after demultiplexing. In the case of electrical power failure, the VOA is set to its maximum attenuation (or to a fixed and configurable value) for safety purposes. A manual VOA setting is also available.
Each single channel port is monitored using a photodiode to enable automatic power regulation.
The 4MD-xx.x card multiplexes and demultiplexes four 100 GHz spaced channels identified in the channel plan. The 4MD-xx.x card is designed to be used with band OADMs. There are eight versions of this card that correspond with the eight, four-channel band OADMs. The 4MD-xx.x can be installed in Slots 1-6 and 12-17.
The 4MD has the following features:
The One-Channel Add/Drop card passively adds and drops one of the 32 channels utilized within the 100-GHz grid spacing of the DWDM card system. Thirty-two versions of this card—each designed only for use with one wavelength—are used in the ONS 15454 DWDM system. Each wavelength version of the card has a different part number.
The AD-1C-xx.x has the following features:
The Two-Channel Add/Drop card passively adds and drops two adjacent 100-GHz channels within the same band. Sixteen versions of this card—each designed for use with one pair of wavelengths—are used in the ONS 15454 DWDM system. The card bidirectionally adds and drops in two different sections on the same card to manage signal flow in both directions.
The AD-2C-xx.x has the following features:
The Four-Channel Add/Drop card passively adds and drops all four 100GHz-spaced channels within the same band. Eight versions of this card—each designed for use with one band of wavelengths—are used in the ONS 15454 DWDM system. The card bidirectionally adds and drops in two different sections on the same card to manage signal flow in both directions. There are eight versions of this card.
The AD-4C-xx.x has the following features:
The One-Band Add/Drop card passively adds and drops a single band of four adjacent 100GHz-spaced channels. Eight versions of this card with eight different part numbers—each version designed for use with one band of wavelengths—are used in the ONS 15454 DWDM system. The card bidirectionally adds and drops in two different sections on the same card to manage signal flow in both directions. This card can be used when there is asymmetric adding and dropping on each side (east or west) of the node; a band can be added or dropped on one side but not on the other.
The AD-1B-xx.x has the following features:
Passive optical plug-in module with two cascaded interferential filters that perform the channel add and drop functions.
– VOA Drop is used to regulate the output power of the channels in the dropped band
– VOA Express is used to regulate the insertion loss of the express path
The Four-Band Add/Drop card passively adds or drops four bands of four adjacent 100GHz-spaced channels. Two versions of this card with different part numbers—each version designed for use with one set of bands—are used in the ONS 15454 DWDM system. The card bidirectionally adds and drops in two different sections on the same card to manage signal flow in both directions. This card can be used when there is asymmetric adding and dropping on each side (east or west) of the node; a band can be added or dropped on one side but not on the other.
The AD-4B-xx.x has the following features:
Each ONS 15454 DWDM node has an automatic power control (APC) feature that maintains constant channel power when channels are added and dropped, or maintains the channel power constant when span loss degradation occurs. This feature functions at both the node and network levels.
For further details on automatic power control, consult the user documentation.
Automatic node setup (ANS) is a TCC2 function that adjusts values of the VOAs on the DWDM channel paths to equalize the per-channel power at the amplifier input. This power equalization means that at launch, all the channels have the same amplifier power level, independent of the input signal on the client interface and independent of the path crossed by the signal inside the node. This equalization is needed for two reasons:
1. Every path introduces a different penalty on the signal that crosses it.
2. Client interfaces add their signal to the ONS 15454 DWDM ring with different power levels.
For further details on automatic node setup, consult the user documentation.
The 2.5G_MR_TXP card (2.5G multirate transponder) processes one 8-Mbps to 2.488-Gbps signal (client side) into one 8-Mbps to 2.5-Gbps, 100-GHz DWDM signal (trunk side). It provides one long reach STM-16/OC-48 port per card (trunk side), compliant with ITU-T G.707, ITU-T G.957, and Telcordia GR-253-CORE.
The 2.5G_MR_TXP card features an ITU compliant 1550 nm laser for the trunk/line port and a 1310 nm laser for the client port (the client side is equipped with SFP and may be either 1310nm or 850nm) and contains two transmit and receive connector pairs (labeled) on the card faceplate. The card uses dual LC connectors for optical cable termination.
The 2.5G_MR_TXP-P card (2.5G multirate transponder-protected) processes one 8-Mbps to 2.488-Gbps signal (client side) into two 8-Mbps to 2.5-Gbps, 100-GHz DWDM signals (trunk side). It provides two long reach STM-16/OC-48 ports per card, compliant with ITU-T G.707, ITU-T G.957, and Telcordia GR-253-CORE.
The 2.5G_MR_TXP-P card features an ITU compliant 1550 nm laser for the trunk/line port and a 1310 nm or 850 nm laser (depending on the SFP) for the client port and contains three transmit and receive connector pairs (labeled) on the card faceplate. The card uses dual LC connectors for optical cable termination.
The 2.5G_MR_TXP and 2.5G_MR_TXP-P cards are tunable over four adjacent wavelengths in the 1550 nm, ITU 100-GHz range. They are available in eight different versions, covering 32 different wavelengths in the 1550 nm range.
The trunk/line port operates at up to 2.488 Gbps (or up to 2.66 Gbps with ITU-T G.709 Digital Wrapper/FEC) over unamplified distances up to 223.7 miles (360 km) with different types of fiber.
You can install 2.5G_MR_TXP and 2.5G_MR_TXP-P cards in Slots 1 to 6 and 12 to 17. You can provision either card in a linear configuration. TXP_MR_10G and 2.5G_MR_TXP-P cards cannot be provisioned as BLSR or path protection. They can be used in the middle of BLSR or 1+1 spans; however, they can only be used in the middle of BLSR and 1+1 spans when configured for transparent termination mode.
The 2.5G_MR_TXP and 2.5G_MR_TXP-P cards detect SF, LOS, or LOF conditions on the optical facility. Refer to the Cisco ONS 15454 Troubleshooting Guide for a description of these conditions. These cards also count section and line BIP errors from B1 and B2 byte registers in the section and line overhead.
For further specifications, protection, and operation modes of these cards, consult the user documentation.
Release 4.5 offers a DWDM optical solution designed to provide transparent, reliable and manageable transport capacity to Cisco Metro optical products such as the ONS 15454, ONS 15600, ONS 15530 and ONS 15540. Release 4.5 DWDM features a transport capacity of 32 wavelengths, 100 GHz spaced, in the C-band. Future releases will upgrade the transport capacity to 64 wavelengths 50 GHz spaced.
Release 4.5 supports DWDM transmission over three different network topologies: hubbed ring, multi-hubbed ring, meshed ring and single span. The ring extension covered by Release 4.5 DWDM ranges to upwards of 400 km.
Release 4.5 supports a common DWDM transport layer to different Cisco ONG products. Release 4.5 DWDM works as a common transport server layer for multiple Cisco clients such as the ONS 15454, ONS 15600, ONS 15530, and ONS 15540 over a Metro ring. The concurrent transmission of these clients over the ring offered by Release 4.5 DWDM is
The Release 4.5 DWDM transport capacity is 32 channels at 100 GHz spacing. Future releases will upgrade this capacity to 64 channels at 50 GHz spacing.
Release 4.5 DWDM is designed to be compatible with the ONS 15454 platform. All DWDM cards are ONS 15454-like cards that fit in ONS 15454 shelves, the local craft interface used to manage the DWDM cards is an extension of the ONS 15454 CTC, and CTM may be used as the network manager.
Release 4.5 DWDM supports transmission over Metro Core/Regional rings of most line cards of the Cisco metro products, both of the ONS 15454 and ONS 15530 family. For a complete list of the supported interfaces, see the user documentation.
Each DWDM Network Element can be equipped with cards that realize the termination of all DWDM channels (Hub node), or with cards that perform the add/drop of a channel subset with a granularity of 1, 2, 4 channels or 1, 4 bands (OADM nodes). All NE losses can be compensated with optical amplifier cards. Dispersion Compensating Units (DCUs) provide chromatic dispersion compensation when needed. For a detailed description of DWDM NEs, see the user documentation.
An OSC channel is provisioned to carry user data channels and network management channels, supporting DCN and engineering orderwire.
The SW features of Release 4.5 DWDM allow the easy provisioning of new channels in the ring and the automatic power control of the channel power when there is a change both in terms of channel count and span loss.
In this network topology a hub node terminates all the DWDM channels. In an open ring, a channel can be configured to support protected traffic between the hub node and any node in the ring--working and protected traffic are allocated on the same wavelength on both sides of the ring. Protected traffic completely saturates a wavelength channel in an open ring; that is, no wavelength reuse is possible. Conversely a wavelength channel can be configured to support unprotected multi-hop traffic, reusing the same wavelength channel in different sections of the ring. From a transmission point of view, this network application corresponds to two bidirectional point-to-point links with OADM nodes.
A multi-hubbed ring is a special case of an open ring, where two or more hub nodes are inserted. Protected traffic can be established only between the two hub nodes. Multi-hop traffic can be provisioned on this ring. From a transmission point of view, this corresponds to two (or more) point-to-point links with OADM nodes.
Closed (or meshed) ring topology is characterized by the absence of the hub node: only amplified and passive OADM nodes are present. Protected traffic can be provisioned between any two nodes, but in this case the selected wavelength channel cannot be reused in the ring. Unprotected multi-hop traffic can also be provisioned on this network topology. A meshed ring must be designed in order to prevent ASE lasing in the ring. Configuring a particular node as an Anti-ASE node does this.
Linear configurations are characterized by the presence of two terminal sites (west and east). The terminal sites must be equipped with a 32-MUX-O and a 32-DMX-O card. Between the two terminal sites OADM, or line amplifier nodes can be inserted. On a linear configuration only unprotected traffic can be provisioned.
A single span link is a particular linear configuration characterized by a very long single span, exceeding 28 dB and up to 37 dB, with pre and post amplification.
The following node types are supported with Release 4.5. For system functional specifications and power requirements, consult the user documentation.
The hub node is a node equipped with two 32-channel mux (32MUX-O) and two 32-channel demux (32DMX-O) cards. A node equipped with two couples of 32MUX-O and 32DMX-O with some channels configured as pass through is a particular instance of an OADM node. The main architecture of a hub node is very similar to the architecture of a back-to-back terminal node in a conventional DWDM system.
All the units equipping a hub node can be plugged into a single ONS 15454 shelf, plus a DCU shelf, if dispersion compensation function is necessary.
A Release 4.5 DWDM terminal node is used in point-to-point configurations and is simply a hub node where either the west (terminal node east) or the east (terminal node west) is removed. For signal flow and description refer to the user documentation. The presence of a Terminal node is mandatory in all linear configurations.
In an OADM node a channel can be:
Note The difference between an OPTICALLY BYPASSED and EXPRESS path is that when a channel is configured as OPTICALLY BYPASSED, it can be dropped in a future ring reconfiguration without affecting any other channel.
In a Release 4.5 DWDM system, the OADM sites can be equipped with OPT-PRE and/or OPT-BST amplifiers, depending on the loss of the node and on the loss of the preceding and following spans. Whenever the OPT-BST is absent, the OSC-CSM must be used instead of the OSCM card.
An OADM site can be realized in two ways:
1. Using band and/or channel OADM filter units. This configuration provides the best flexibility as the OADM filter units can be combined in many different ways to satisfy the node traffic. The list of OADM filter units that can be deployed in an OADM node is:
2. Using two couples of 32MUX-O and 32DMX-O cards and configuring all the channels that are express in that node as pass through. Solution 2 is preferable when a significant amount of traffic is terminated in the node. In this configuration the OADM node also provides Anti-ASE functionality.
The OADM cards (either band or channel) can be configured East or West side. For example, a single band OADM card (AD-1B-xx.x) west facing will drop the band with ID xx.x on the west-to-east fiber, while it will add the same band, xx.x, on the east-to-west fiber. Symmetrically the band AD-1B-xx.x unit east facing will add the band xx.x on the west-to-east fiber, while it will drop the band xx.x on the east-to-west fiber. Band and/or channel OADM cards can be used in the same OADM node.
For amplified OADM and passive OADM node unit combinations and examples, consult the user documentation.
In a closed loop configuration the Release 4.5 ONS 15454 requires a site that prevents ASE accumulation and lasing.
The anti-ASE node can be realized in two ways:
1. With an OADM node equipped with 32MUX-O and 32DMX-O cards.
2. When the total number of wavelengths deployed in the ring is lower than 10, the anti-ASE node is realized with an OADM node where all the channels that are not terminated in the node are configured as optically bypass. In other words, no channels in the anti-ASE node can travel through the express path of the OADM node. This is because the express path-cord is physically removed in an anti-ASE node.
In a closed ring there are additional constraints on the number of times a wavelength must be terminated in the ring in order to avoid lasing.
Reference configurations for an Anti-ASE node can be obtained using any OADM node configurations where no channels can travel through the express path, but they can only be dropped and demultiplexed at channel level on one side, and added and multiplexed on the other.
The Line Amplifier Node is composed of only amplifier units (OPT-PRE and OPT-BST in all possible combinations), placed at each side of the node and all of the required common cards.
In order to maintain the amplifier gain tilt within the specification, an additional fixed attenuator may be required between each preamplifier output and the booster corresponding input for matching the correct optical input power value.
The two OSCMs are connected with the relevant ports of the east or west booster units in order to multiplex the Optical Service Channel signal with the pass through channels. If an OPT-BST is not deployed within the node, an OSC-CSM unit must be used instead of the OSCM.
The Release 4.5 DWDM system uses an OC-3 framed out of band (1510 nm) Optical Service Channel (OSC) to transport signaling, supervision, user channels and order-wire signals from one node to another. The OSC signal is multiplexed on the same transmission fiber pairs used by the DWDM signal.
In the Service channel the following services are transported:
In a generic node two OSCMs are used to transport the service channel, one OSCM facing west (OSCM-W) and the other OSCM facing east (OSCM-E). The two units have the same hardware and software images but are automatically configured to be east or west depending on slot position.
A single OSCM can be used in terminal nodes of a point-to-point link.
Each OSCM or OSC-CSM establishes a point-to-point link with the adjacent node (OSCM-W communicates with OSCM-E and vice versa).
Each ONS 15454 DWDM node has a network topology discover function that can identify:
For further details on DWDM network topology discovery, consult the user documentation.
In a Release 4.5 DWDM network you can create new circuits and retrieve circuits already created via Network Circuit Provisioning (NCP). The following NCP enhancements make this possible.
DWDM circuit provisioning and removal is performed by a CTC component called NCP.
A Circuit Removal Request allows you to remove a circuit previously created. Circuit multiple selection is supported. CTC notifies the user of the Circuit Deletion Result (by means of an Information or Error Dialog).
Since creation of a bidirectional circuit is split by NCP into creation of two independent unidirectional circuits, DWDM circuits retrieved by NCP will be all unidirectional.
This means that it’s not possible to remove bidirectional circuits; rather, you will remove a pair of unidirectional circuits.
CTC is able to discover the circuit map of a Release 4.5 DWDM network using the same approach implemented for SONET and SDH circuits.
NCP is able to discover the Release 4.5 DWDM circuits using information created during circuit provisioning.
CTC is able to show the list of discovered circuits at the Network, Node, and Card levels.
CTC also provides a separate graphical representation of the OCHNC Circuit, called “Detailed Map.” The Detailed Map representation of an OCHNC Circuit displays in a separate window and shows all Release 4.5 DWDM nodes through which the circuit traverses, from the source node to the destination node.
Release 4.5 DWDM OADMs are not configurable and Mux/Demuxes are not transparent: optical paths are pre-cabled, and non-software configurable by the user.
You can activate existing circuits but not create an unanticipated new circuit. DWDM circuit provisioning supports the following:
Before creating a new circuit NCP checks if the circuit is feasible. A circuit if feasible if:
a. When the port is in OOS, OOS_MT or IS state the SOAKLEFT will not be displayed.
b. When the port is in OOS_AINS, but the countdown has not started due to faulty (or lack of) signal, the value will be SOAKLEFT = NOT-STARTED.
c. When the port is in OOS_AINS and the countdown is on, the value will be shown in HH-MM format (for example, SOAKLEFT = 12-25).
The RTRV-CLNT/OCH response is rearranged to group the SFP inventory parameters, such as PN, SN, CLEI, and VENDORREV.
The following commands were added in Release 4.5.
The following enumerations were present in Release 4.1, but were removed in Release 4.5.
The following ALL_MONTYPE enum items were present in Release 4.1, but were removed in Release 4.5.
The following ALL_MONTYPE enum items were added to Release 4.5.
The following ALL_THR enum items were present in Release 4.1, but were removed in Release 4.5.
The following ALL_THR enum items were added to Release 4.5.
The following ALM_THR enum items were present in Release 4.1, but were removed in Release 4.5.
The following ALM_THR enum items were added in Release 4.5.
The following AWG_STATUS enum items were added to Release 4.5.
The following DWDM_RING_TYPE enum items were added to Release 4.5.
The following EQUIPMENT_TYPE enum items were added to Release 4.5.
The following HEATER_STATUS enum items were added to Release 4.5.
The following MOD2ALM enum items were added to Release 4.5.
The following MOD2O enum items were added to Release 4.5.
The following OPTICAL_BAND enum item was present in Release 4.1, but was removed in Release 4.5.
The following OPTICAL_BAND enum item was added to Release 4.5.
The following OPTICAL_LINK_TYPE enum items were present in Release 4.1, but were removed in Release 4.5.
The following OPTICAL_LINK_TYPE enum items were added to Release 4.5.
The following OPTICAL_PORT_TYPE enum items were present in Release 4.1, but were removed in Release 4.5.
The following OPTICAL_PORT_TYPE enum items were added to Release 4.5.
The following PAYLOAD enum items were added to Release 4.5.
The following PROTTYPE enum item was added to Release 4.5.
The following RDIRN_MODE enum items were present in Release 4.1, but were removed in Release 4.5.
The following SECUALMTYPE enum items were added to Release 4.5.
The following SYS_TYPE enum items were added to Release 4.5.
The following TRCLEVEL enum items were present in Release 4.1, but were removed in Release 4.5.
The following TRCLEVEL enum items were added to Release 4.5.
The following WDM enum items were added to Release 4.5.
The following WLEN_MODE enum items were added to Release 4.5.
Each of the following show the command syntax for Release 4.1 followed by the changed syntax in Release 4.5.
ED-CLNT[:<TID>]:<aid>:<CTAG>[:::SFBER=<sfber>,][SDBER=<sdber>,][ALSMODE=<alsmode>,][ALSRCINT=<alsrcint>,][ALSRCPW=<alsrcpw>,][COMM=<comm>,][MACADDR=<macaddr>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][RLASER=<rlaser>,][SOAK=<soak>][:<pst>,][<sst>];
ED-CLNT[:<TID>]:<aid>:<CTAG>[:::NAME=<portname>,][SFBER=<sfber>,][SDBER=<sdber>,][ALSMODE=<alsmode>,][ALSRCINT=<alsrcint>,][ALSRCPW=<alsrcpw>,][COMM=<comm>,][MACADDR=<macaddr>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][RLASER=<rlaser>,][SOAK=<soak>][:<pst>,][<sst>];
ED-DWDM[:<TID>]:<src>:<CTAG>[:::PEERID=<peerid>,][TERMMODE=<termmode>,][PAYLOAD=<payload>,][PWL=<pwl>][:];
ED-DWDM[:<TID>]:<src>:<CTAG>[:::PEERID=<peerid>,][NAME=<regenname>,][TERMMODE=<termmode>,][PAYLOAD=<payload>,][PWL=<pwl>][:];
ED-OCH[:<TID>]:<aid>:<CTAG>[:::VOAATTN=<voaattn>,][SFBER=<sfber>,][SDBER=<sdber>,][ALSMODE=<alsmode>,][ALSRCINT=<alsrcint>,][ALSRCPW=<alsrcpw>,][COMM=<comm>,][GCCRATE=<gccrate>,][OSFBER=<sfber>,][OSDBER=<sdber>,][DWRAP=<drwap>,][FEC=<fec>,][MACADDR=<macaddr>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][RLASER=<rlaser>,][SOAK=<soak>][:<pst>,][<sst>];
ED-OCH[:<TID>]:<aid>:<CTAG>[:::RDIRN=<rdirn>,][EXPWLEN=<expwlen>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][CALOPWR=<calopwr>,][CHPOWER=<chpower>,][NAME=<portname>,][SFBER=<sfber>,][SDBER=<sdber>,][ALSMODE=<alsmode>,][ALSRCINT=<alsrcint>,][ALSRCPW=<alsrcpw>,][COMM=<comm>,][GCCRATE=<gccrate>,][OSFBER=<sfber>,][OSDBER=<sdber>,][DWRAP=<drwap>,][FEC=<fec>,][MACADDR=<macaddr>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][RLASER=<rlaser>,][SOAK=<soak>][:<pst>,][<sst>];
ED-OMS[:<TID>]:<aid>:<CTAG>[:::RDIRN=<rdirn>,][EXPBAND=<expband>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][VOAST=<voast>,][ALSMODE=<alsmode>,][ALSCFG=<alscfg>,][CALOPWR=<calopwr>][:<pst>,][<sst>];
ED-OMS[:<TID>]:<aid>:<CTAG>[:::RDIRN=<rdirn>,][EXPBAND=<expband>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][CALOPWR=<calopwr>,][CHPOWER=<chpower>][:<pst>,][<sst>];
ED-OTS[:<TID>]:<aid>:<CTAG>[:::RDIRN=<rdirn>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][VOAST=<voast>,][ALSMODE=<alsmode>,][ALSCFG=<alscfg>,][AMPLMODE=<amplmode>,][EXPOPWR=<expopwr>,][NCHAN=<nchan>,][CALOPWR=<calopwr>,][CALTILT=<caltilt>][:<pst>,][<sst>];
ED-OTS[:<TID>]:<aid>:<CTAG>[:::RDIRN=<rdirn>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][CALOPWR=<calopwr>,][CALTILT=<caltilt>,][OSRI=<osri>,][EXPGAIN=<gain>][:<pst>,][<sst>];
Each of the following show the command response for Release 4.1 followed by the changed response in Release 4.5.
RTRV-CLNT response Release 4.1:
“<aid>:,,[<role>],<status>:[COMM=<comm>,][SFBER=<sfber>,][SDBER=<sdber>,][ALSMODE=<alsmode>,][ALSRCINT=<alsrcint>,][ALSRCPW=<alsrcpw>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][LSRSTAT=<lsrstat>,][CLEI=<clei>,][PN=<partnum>,][SN=<serialnum>,][VENDOR=<vendor>,][VENDORREV=<vendorrev>,][OPTICS=<optics>,][MACADDR=<macaddr>,][SOAK=<soak>]:<pst>,[<sst>]”
RTRV-CLNT response Release 4.5:
“<aid>:,,[<role>],<status>:[NAME=<portname>,][COMM=<comm>,][SFBER=<sfber>,][SDBER=<sdber>,][ALSMODE=<alsmode>,][ALSRCINT=<alsrcint>,][ALSRCPW=<alsrcpw>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][LSRSTAT=<lsrstat>,][CLEI=<clei>,][PN=<partnum>,][SN=<serialnum>,][VENDOR=<vendor>,][VENDORREV=<vendorrev>,][PLGTYPE=<plgtype>,][MACADDR=<macaddr>,][SOAK=<soak>,][SOAKLEFT=<soakleft>]:<pst>,[<sst>]”
RTRV-DWDM response Release 4.1:
“<aid>:<aidtype>,<equip>,,[<status>]:[PEERID=<peerid>,][NAME=<name>,][TERMMODE=<termmode>,][PAYLOAD=<payload>,][CARDNAME=<cardname>,][PWL=<pwl>,][TWL1=<twl1>,][TWL2=<twl2>,][TWL3=<twl3>,][TWL4=<twl4>]:[<pst>],[<sst>]”
RTRV-DWDM response Release 4.5:
“<aid>:<eqptType>,<equip>,,[<status>]:[PEERID=<peerid>,][NAME=<name>,][TERMMODE=<termmode>,][PAYLOAD=<payload>,][CARDNAME=<cardname>,][PWL=<pwl>,][TWL1=<twl>,][TWL2=<twl1>,][TWL3=<twl2>,][TWL4=<twl3>]:[<pst>],[<sst>]”
RTRV-OCH response Release 4.1:
“<aid>:,,,[<status>]:[RDIRN=<rdirn>,][OPTYPE=<opticalPortType>,][OPWR=<power>,][EXPWLEN=<expWlen>,][ACTWLEN=<actWlen>,][ILOSS=<iloss>,][VOAMODE=<voamode>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][VOAREFATTN=<voarefattn>,][VOAREFPWR=<voarefpwr>,][REFOPWR=<refopwr>,][CALOPWR=<calopwr>,][SFBER=<sfber>,][SDBER=<sdber>,][ALSMODE=<alsmode>,][ALSRCINT=<alsrcint>,][ALSRCPW=<alsrcpw>,][COMM=<comm>,][GCCRATE=<gccrate>,][DWRAP=<dwrap>,][FEC=<fec>,][OSFBER=<osfber>,][OSDBER=<osdber>,][MACADDR=<macaddr>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][LSRSTAT=<lsrstat>,][SOAK=<soak>]:<pst>,[<sst>]”
RTRV-OCH response Release 4.5:
“<aid>:,,,[<status>]:[RDIRN=<rdirn>,][OPTYPE=<opticalPortType>,][OPWR=<power>,][EXPWLEN=<expWlen>,][ACTWLEN=<actWlen>,][ILOSS=<iloss>,][VOAMODE=<voamode>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][VOAREFATTN=<voarefattn>,][VOAREFPWR=<voarefpwr>,][REFOPWR=<refopwr>,][CALOPWR=<calopwr>,][CHPOWER=<chpower>,][NAME=<portname>,][SFBER=<sfber>,][SDBER=<sdber>,][ALSMODE=<alsmode>,][ALSRCINT=<alsrcint>,][ALSRCPW=<alsrcpw>,][COMM=<comm>,][GCCRATE=<gccrate>,][DWRAP=<dwrap>,][FEC=<fec>,][OSFBER=<osfber>,][OSDBER=<osdber>,][MACADDR=<macaddr>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][LSRSTAT=<lsrstat>,][SOAK=<soak>,][SOAKLEFT=<soakleft>]:<pst>,[<sst>]”
RTRV-OMS response Release 4.1:
“<aid>::RDIRN=<rdirn>,OPTYPE=<opticalPortType>,[OPWR=<power>,]EXPBAND=<expBand>,[ACTBAND=<actBand>,][ILOSS=<iloss>,][VOAMODE=<voamode>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][VOAREFATTN=<voarefattn>,][VOAREFPWR=<voarefpwr>,][REFOPWR=<refopwr>,][CALOPWR=<calopwr>,][CHPOWER=<chpower>]:<pst>,[<sst>]”
RTRV-OMS response Release 4.5:
“<aid>::RDIRN=<rdirn>,OPTYPE=<opticalPortType>,[OPWR=<power>,]EXPBAND=<expBand>,[ACTBAND=<actBand>,][ILOSS=<iloss>,][VOAMODE=<voamode>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][VOAREFATTN=<voarefattn>,][VOAREFPWR=<voarefpwr>,][REFOPWR=<refopwr>,][CALOPWR=<calopwr>,][CHPOWER=<chpower>]:<pst>,[<sst>]”
RTRV-OTS response Release 4.1:
“<aid>:RDIRN=<rdirn>,OPTYPE=<opticalPortType>,[OPWR=<power>,][ILOSS=<iloss>,][VOAMODE=<voamode>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][VOAREFATTN=<voarefattn>,][VOAREFPWR=<voarefpwr>,][LASERST=<laserst>,][OSRI=<osri>,][AMPLMODE=<amplmode>,][GAIN=<gain>,][EXPGAIN=<expgain>,][REFOPWR=<refopwr>,][CALOPWR=<calopwr>,][REFTILT=<reftilt>,][CALTILT=<caltilt>,][DCULOSS=<dculoss>,][AWGST=<awgst>,][HEATST=<heatst>]:<pst>,[<sst>]”;
RTRV-OTS response Release 4.5:
“<aid>:RDIRN=<rdirn>,OPTYPE=<opticalPortType>,[OPWR=<power>,][ILOSS=<iloss>,][VOAMODE=<voamode>,][VOAATTN=<voaattn>,][VOAPWR=<voapwr>,][VOAREFATTN=<voarefattn>,][VOAREFPWR=<voarefpwr>,][LASERST=<laserst>,][OSRI=<osri>,][AMPLMODE=<amplmode>,][GAIN=<gain>,][EXPGAIN=<expgain>,][REFOPWR=<refopwr>,][CALOPWR=<calopwr>,][REFTILT=<reftilt>,][CALTILT=<caltilt>,][DCULOSS=<dculoss>,][AWGST=<awgst>,][HEATST=<heatst>]:<pst>,[<sst>]”;
RTRV-TRC-CLNT response Release 4.1:
“[TRCLEVEL=<trclevel>,][EXPTRC=<exptrc>,][TRC=<trc>,][INCTRC=<inctrc>,][TRCMODE=<trcmode>,][TRCFORMAT=<trcformat>]”
RTRV-TRC-CLNT response Release 4.5:
“<aid>,<mod>::[TRCLEVEL=<trclevel>,][EXPTRC=<exptrc>,][TRC=<trc>,][INCTRC=<inctrc>,][TRCMODE=<trcmode>,][TRCFORMAT=<trcformat>]”
RTRV-TRC-OCH response Release 4.1:
“[TRCLEVEL=<trclevel>,][EXPTRC=<exptrc>,][TRC=<trc>,][INCTRC=<inctrc>,][TRCMODE=<trcmode>,][TRCFORMAT=<trcformat>]”
RTRV-TRC-OCH response Release 4.5:
“<channel>,<mod>::[TRCLEVEL=<trclevel>,][EXPTRC=<exptrc>,][TRC=<trc>,][INCTRC=<inctrc>,][TRCMODE=<trcmode>,][TRCFORMAT=<trcformat>]”
The following sections provide sources for obtaining documentation from Cisco Systems.
You can access the most current Cisco documentation on the World Wide Web at the following sites:
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or as an annual subscription.
If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:
Attn Document Resource Connection
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-9883
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at anytime, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.
Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.
Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.
The Cisco TAC website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.
If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website:
https://mycase.cloudapps.cisco.com/case
P3 and P4 level problems are defined as follows:
In each of the above cases, use the Cisco TAC website to quickly find answers to your questions.
To register for Cisco.com, go to the following website:
https://id.cisco.com/signin/register
If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at the following website:
If you have a priority level 1 (P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to the following website:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtm l