 Feedback
|
Table Of Contents
Release Notes for Cisco ONS 15600 Release 5.0.5
Maintenance and Administration
Resolved Caveats for Release 5.0.5
Maintenance and Administration
Common Control and Cross Connect Cards
New Features and Functionality
Additional Support for In Service Topology Upgrades
State Verification Scan Before Activation
SONET J1 Path Trace Automatic Mode
Timing Synchronization Enhancements
High Level Functional Differences
Obtaining Technical Assistance
Contacting TAC by Using the Cisco TAC Website
Release Notes for Cisco ONS 15600 Release 5.0.5
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.
September 2007
Release notes address closed (maintenance) issues, caveats, and new features for the Cisco ONS 15600. For detailed information regarding features, capabilities, hardware, and software introduced with this release, refer to Release 5.0 of the Cisco ONS 15600 Procedure Guide, Cisco ONS 15600 Reference Manual, Cisco ONS SONET TL1 Command Guide, and Cisco ONS 15600 Troubleshooting Guide. For the most current version of the Release Notes for Cisco ONS 15600 Release 5.0.5, visit the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/ong/15600/600relnt/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
Resolved Caveats for Release 5.0.5
New Features and Functionality
Obtaining Technical Assistance
Changes to the Release Notes
This section documents supplemental changes that have been added to the Release Notes for Cisco ONS 15600 Release 5.0.5 since the production of the Cisco ONS 15600 System Software CD for Release 5.0.5.
No changes have been added to the release notes for Release 5.0.5.
Caveats
Review the notes listed below before deploying the ONS 15600. 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.
Upgrades
DDTS # CSCeg34361
Revert fails if the internal subnet differs from that in the revert database. This issue is seen in a revert from a 5.0.x release to Release 5.0. This issue is not seen in reverts from Release 5.0.x to 1.x. This issue will be resolved in Release 6.0.
DDTS # CSCeh16339
Clicking the Cancel button from the CTC network view, Software tab during a software download does not stop the download, but gives the appearance in the network view, Software tab that it has. This symptom only occurs if you click the Cancel button after the software has been copied to the node, and during the "Copying to Standby TSC" phase of the software download. To avoid this issue, cancel the software download from the node view, Software tab instead of from the network view, Software tab when canceling during the "Copying to Standby TSC" phase of the software download. This issue will be resolved in a future release.
DDTS # CSCee60276
Some circuits might be displayed as PARTIAL after one or more ONS 15600 nodes is upgraded to Release 5.0.x. This can occur when the ONS 15600 interoperates with ONS 15454, 15327, or 15310 nodes in the same network, and there exist circuits with their source on the ONS 15454/15327/15310 nodes and drops on the ONS 15600 nodes. If this occurs, run "Circuit Reconfigure" on the affected PARTIAL circuits. For further documentation of this circumstance, see the Upgrading Cisco ONS 15600 Release 1.x to 5.0 document.
Maintenance and Administration
Caution
DDTS # CSCeg57163
ONS platforms support only a single OSPF virtual link. This issue will be resolved in a future release.
DDTS # CSCdy58342
Network connectivity could be lost if a backbone area becomes segmented into multiple GNEs. This occurs only if multiple ONS 15600 nodes and routers are connected to the same LAN in OSPF area 0. If a link between two routers breaks, the CTC session connected to Router 1 will not be able to communicate with the ONS 15600 connected to Router 2. To resolve, you must repair the link between the routers or provide another form of redundancy in the network. This is as designed.
DDTS # CSCdz07098
If OSPF on LAN is enabled with an area ID that is the same as the area ID of any of the DCC Links, CTC will not be able to discover any of the DCC Connected Nodes. To avoid this issue, set the OSPF on LAN area ID to an area other than any of those already occupied by a DCC link. This is as designed.
DDTS # CSCdy25142
Equipment alarms are always reported based on the activity of the particular card, without taking card redundancy into consideration. Thus, an equipment alarm such as CTNEQPT-PB-0 may be raised against a line card as CR(SA) even though the traffic is protected. This issue will be resolved in a future release.
DDTS # CSCeb49407
Choosing certain qualities of RES settings in the CTC Provisioning tab, Timing subtab, may trigger a reference failure. Specifically, this can occur if you select the quality of RES level such that any of the following are true.
•
•
•
When you then input an actual reference signal lower than ST3E quality, the failure is triggered. This issue will be resolved in a future release.
DDTS # CSCdy14265
The manual bridge and roll feature allows you to perform the END command once the roll operation transitions from a ROLL PENDING to ROLL condition, even if the roll to port has an invalid signal. To avoid traffic impact, ensure that the roll-to line is alarm-free. If an alarm exists, you can choose to do nothing and wait for the alarm to clear, to delete the roll, or to proceed in spite of the alarm. This issue will not be resolved.
Control Cards
DDTS # CSCeg16339
Performing a TSC soft reset on an ONS 15600 with a large BLSR and circuit configuration sometimes causes subordinate I/O cards to soft reset. This issue will be resolved in a future release.
Data IO Cards
DDTS # CSCef20813
No graphical representations of LEDs for ASAP ports are displayed in the CTC card view. SD and SF LED representations are also absent from the CTC node view for some legacy OCn cards. There are no plans to resolve this issue.
DDTS # CSCeg12963
On an OC-48 port of an ASAP card, use of the ED-STS9c TL1 command to create a dual TAP port is only accepted for STS-x-y-z-4/16/28, and is incorrectly denied for the first, and the rest of all the STSs. To work around this issue, when creating an STS-9c dual tap on an OC-48 ASAP port, start the tap on the STS 4, STS 16, or STS 28 boundary. This issue will be resolved in a future release.
BLSR Functionality
DDTS # CSCeh49665
Connections might still exist after circuit deletions on BLSR DRI rings for which the primary node is isolated. For BLSR DRI rings with several types of DRI circuits, if you isolate the primary node by deleting the database, reseat the I/O cards, then delete all BLSR DRI circuits, the SSXCs still show connections. To avoid this issue, do not delete or create BLSR DRI circuits when a node on the BLSR DRI ring is isolated. This issue will be resolved in a future release.
DDTS # CSCeh35448
Rarely, a line card might reboot after multiple times creating and deleting a BLSR with circuits provisioned for PCA and DRI. If you have a BLSR with circuits provisioned for PCA and DRI, and you then delete the circuits, delete the BLSR, and reenter the same ring ID and facilities (as the BLSR you just deleted), it is possible to see a line card reboot. This issue will be resolved in a future release.
DDTS # CSCeh11972
Soft resetting both SSXC cards at the same time while the BLSR is in wait to restore results in a one-second hit. This also causes an out of sync condition where the ring appears switched on the GUI interface and CID-MISMATCH alarms are possibly declared. This issue can occur on a ring that is still switched and for which wait to restore period is active. Avoid soft resetting both SSXC cards at the same time when a wait to restore is active. Soft resets should only be performed when rings are in a steady state (switched or idle). If this out of sync condition occurs, a manual or forced switch on the affected rings will be required to resynchronize the system. This issue will be resolved in a future release.
DDTS # CSCeb56502
A circuit remains in the roll_pending state after a roll attempt is cancelled on a path roll in a two-fiber BLSR, where the path has an active protection switch at the circuit destination node. To recover from this situation, restart CTC. This issue will be resolved in the future release.
Path Protection Functionality
DDTS # CSCec15064
A path protection/SNCP circuit with a defect signal present (for example, AIS-P or AIS-V) on the protect path will produce RDI-P or RDI-V upstream of the detection point, but these signals will not be detected or indicated. This issue will be resolved in a future release.
Interoperability
DDTS # CSCdx61916
If, using CTC, you attempt to create a protected VT1.5 circuit that originates on one ONS 15327/454 that is connected to the ONS 15600 via path protection to another ONS 15327/454 that is connected to the ONS 15600 via 1+1 or BLSR, the circuit creation request will be denied because of mixed protection domains. CTC is currently incapable of routing VT circuits across the ONS 15600 when mixed protection schemes are involved. VT traffic can be routed across the ONS 15600 when mixed protection schemes are involved by performing the following:
Step 1
Step 2
Step 3
Note
This issue will be resolved in a future release.
DDTS # CSCdy68110
When you attempt to configure VT circuits on a test configuration consisting of two ONS 15454 nodes and one ONS 15600 node, when both ONS 15454s are connected to the ONS 15600 node using a dual path protection connection configuration, and when the ONS 15600 node serves as an intermediate node between the two ONS 15454 nodes, you may be unable to create a VT circuit from one ONS 15454 to the ONS 15600 and then to the other ONS 15454. VT Tunnels are created, but the VT circuit is not created. A mixed protection domain error message is raised when this occurs. To avoid this issue, create the VT tunnels manually, so that the two tunnels do not create a topology where the working and protect tunnels share the same I/O card. After the tunnels have been created, the VT circuit can be successfully added. This issue will be resolved in future release.
DDTS # CSCdx94969
Physical PM parameters can not be retrieved through the SNMP interface. MIBs released with the ONS 15600 do not have entries for the following physical PM parameters.
•
•
•
The standard SONET Generic MIB does not have entries for these. To work around this issue, use CTC to retrieve the values. SNMP support for these parameters may be considered for a future release.
DDTS # CSCdy54737
The following PM parameters can not be retrieved through SNMP.
•
–
•
–
–
–
–
–
•
–
–
•
•
To retrieve these counts, use CTC. SNMP support for these parameters may be considered for a future release.
TL1
DDTS # CSCeg14663
The response from the TL1 command, RTRV-NE-IPMAP, contains two rows (one duplicate) of information for each DCC connected port that has provisioned BLSR protection. This issue will be resolved in a future release.
DDTS # CSCeg15770
The TL1 command RTRV-INV::ALL does not return inventory information for all cards present in the node when a preprovisioned PIM exists on a ASAP card. To use this command you must first delete the preprovisioned PIM. This issue will be resolved in a future release.
DDTS # CSCeb46234
A TL1 user cannot preprovision IO cards when a filler card is in the slot. Removal of the filler card will clear the slot and allow the TL1 user to preprovision the IO card. This is by design.
Resolved Caveats for Release 5.0.5
The following caveats were resolved in Release 5.0.x.
Hardware
DDTS # CSCeh07574
Do not install an ASAP card in a system running Release 5.0. During normal testing at 50 deg C temperature the ASAP card can experience a silent failure that at times can be service affecting. Traffic might take errors when you run a fully loaded node with ASAP cards at 50 deg C temperature. Bit errors can occur on some ports. This issue is resolved in Release 5.0.2.
Maintenance and Administration
DDTS # CSCeg60310
Issuing ampersand ranging to manage a full line card's worth of STSs, while at the same time issuing CTC commands against STSs on the same line card, might cause the TSC to reset. This issue is resolved in Release 5.0.2.
DDTS # CSCea78286
In a network topology where ONS 15600 A and ONS 15600 B are connected to the same LAN, with OSPF turned on, both Nodes A and B in the same non-backbone area, and a virtual link created from Node A to a backbone router, if another virtual link to the backbone is created on Node B, a TSC switch may occur. To avoid this situation, do not design a network in the aforementioned configuration; specifically, do not create the second virtual link. This issue is resolved in Release 5.0.
DDTS # CSCdy43268
When the OSPF DCC Metric or the OSPF LAN Metric is modified via CTC, there is no change to the routing of traffic. If a link is broken anywhere in the network, or if the TSC is soft reset the traffic will then be routed appropriately. This issue is resolved in Release 5.0.
DDTS # CSCea47483
If you initiate a roll from the circuits tab, then switch to the rolls subtab of the circuits tab, select the circuit and press the finish button multiple times (for example, if you accidentally double-click the finish button) to complete the roll, then multiple circuits will be displayed on the circuits tab, only one of which is complete (the rest are incomplete). When completing a roll from the rolls subtab of the circuits tab, only press the finish button a single time for each circuit that you wish to roll. This issue is resolved in Release 5.0.
DDTS # CSCea82511
The WTR condition is not displayed after rebooting the working port in an OC-48 1+1 bidirectional revertive configuration. This issue is resolved in Release 5.0.
Common Control and Cross Connect Cards
DDTS # CSCei16460
A common control card reset can occur under the following three conditions.
1.
2.
3.
This issue has been only seen in Release 5.0.2. To avoid this issue, disable OSPF on the LAN. This issue is resolved in Releases 5.0.4 and 5.0.5.
Data IO Cards
DDTS # CSCeg32936
When you remove an ASAP PPM or PIM, the current PM interval is marked invalid. However, when the current 15min time period expires, the first historical PM interval (Prev in CTC) is incorrectly updated to valid. The invalid PM intervals should last for the duration of the PPM/PIM absence. To recover from this you must reinsert the PPM/PIM. This issue is resolved in Release 5.0.2.
BLSR Functionality
DDTS # CSCeg47868
Opposite side BLSR IDRI circuits do not recover after segmenting both BLSR DRI rings. If you create opposite side I-DRI circuits, service on working and secondary on RIP, segment both BLSR DRI rings using force switches so that termination nodes are on one segment, primary and secondary nodes on the other segment, then release the force switches in the order that they were performed, some circuits will drop traffic. To avoid this issue, segment one BLSR DRI ring at a time with force switches and release force switches before segmenting the second rings. This issue is resolved in Release 5.0.2.
DDTS # CSCeg72819
In a BLSR/MS-SPRing DRI configuration, if you add an intermediate node to the BLSR/MS-SPRing on the path between the primary and the secondary handoff, node isolation on the DRI can cause a loss of traffic. To correct this, delete and recreate the circuit in CTC. You can avoid the issue by creating the cross connect using TL1 instead of performing a network view right-click on the node and executing "Update Circuits With New Node." This issue is resolved in Release 5.0.2.
SNMP
DDTS # CSCdz19797
On an ONS 15600, SNMP alarms that have an alarm state of "notAlarmed" show up as "administrative" when retrieved from the MIB browser.
Alarms retrieved from CTC and via the TL1 interface do not have this issue, and so, can be used to verify any alarm states that are incorrectly displayed from the SNMP interface. This issue is resolved in Release 5.0.
TL1 Functionality
DDTS # CSCeg18208
The TL1 command OPR-LPBK-<STS_PATH> gives an "Invalid Path" when using a VFAC AID, even though using the same VFAC AID in a RTRV-CRS command shows the AID is actually involved in a cross connect, so the path should be valid for the OPR-LPBK-<STS_PATH> command. This can occur when the VFAC AID used in the OPR-LPBK-<STS_PATH> command refers to a port on an ASAP-4 card that has been configured for the GIGE payload, where the PIM and PPM layers on the ASAP card are already present or provisioned, and where there is a cross connect provisioned on the node for which the VFAC AID is one of the endpoints, with cross connect and ports in the proper maintenance state such that provisioning a loopback should be allowed. To work around this issue, use CTC instead of TL1 to create the loopback. This issue is resolved in Release 5.0.2.
DDTS # CSCeg87471
Do not set the TID for an ENE to more than 19 characters. Setting the TID for an ENE to 20 characters or more and then issuing a TL1 command on the GNE to execute on the ENE will result in TL1 agent connectivity issues on the ENE. Specifically, if you set the TID on the ENE to 20 characters, reboot the TCC, then try to connect to that ENE from a GNE this will result in a loss of TL1 connectivity to the GNE. This issue is resolved in Release 5.0.2.
DDTS # CSCeb58786
When a node is provisioned for external timing and SSM Message Set configured for Generation 1, if SONET Minimum Clock (SMC) or Stratum 4 is received, the TL1 RTRV-SYNCN command will display DUS (an incorrect message). CTC, however, shows the correct SSM message being received, and all other Generation 1 messages are displayed correctly.
This can also be seen with the Generation 2 Message Set. Whenever Stratum 3, SMC, or Stratum 4 are received, the RTRV-SYNCN command displays DUS. CTC consistently displays the correct SSM messages being received. Use CTC to retrieve the SSM information. This issue is resolved in Release 5.0.
New Features and Functionality
This section highlights new features and functionality for Release 5.0.x. For detailed documentation of each feature, consult the user documentation.
New Hardware
SSXC Card
The single shelf cross-connect card (SSXC) is the central element for ONS 15600 switching. The SSXC card establishes connections and performs time division switching (TDS) at STS-1 and STS-Nc levels between ONS 15600 traffic cards.
The SSXC card works with the TSC card to maintain connections and set up cross-connects within the ONS 15600. You establish cross-connect and provisioning information using CTC or TL1. The TSC card stores the proper internal cross-connect information and relays the setup information to the SSXC card.
SSXC Switch Matrix
The switch matrix on each SSXC card consists of 6,144 STS-1 ports, with a maximum of 6,144 STS-1 cross-connections. When creating bidirectional STS-1 cross-connects, each bidirectional cross-connect uses two STS-1 ports, so the result is that the SSXC supports 3,072 bidirectional STS-1 cross-connects. Any STS-1 on any port can be connected to any other port, meaning that the STS cross-connections are non blocking. Non-blocking connections allow network operators to connect any STS1, STS3, STS12, STS24, STS48, or STS192 payload that is received on an OC-48 or OC-192 interface (or any STS6 or STS9 payload that is received on an ASAP interface) to any other interface capable of supporting the bandwidth.
The SSXC card has 128 input ports and 128 output ports capable of STS-48. An STS-1 on any of the input ports can be mapped to an STS-1 output port, thus providing full STS-1 time slot assignments (TSAs).
SSXC Slots and Connectors
Install an SSXC card in Slot 6 and a second SSXC card in Slot 8 for redundancy. (Slots 7 and 9 are also occupied by the SSXC faceplate.) The SSXC card has no external interfaces. All SSXC card interfaces are provided on the ONS 15600 backplane. For SSXC card level indicators consult the Cisco ONS 15600 Reference Manual.
Any Service Any Port Card
The Any-Service, Any-Port (ASAP) card provides up to 16 Telcordia-compliant, GR-253 SONET OC-3, OC-12, OC-48, or Gigabit Ethernet ports per card in any combination of line rates. The ports operate at up to 2488.320 Mbps over a single-mode fiber. The ASAP card has sixteen physical connector adapters with two fibers per connector adapter (Tx and Rx). The card supports STS-1 payloads and concatenated payloads at STS-3c, STS-6c, STS-9c, STS-12c, STS-24c, or STS-48c signal levels. It is fully interoperable with the ONS 15454 G-Series Ethernet cards.
The ASAP card consists of the ASAP carrier modules, the 4-port I/O module (4PIO), and the Pluggable Port Module (PPM, also known as a Small Form-Factor Pluggable [SFP]). The ASAP carrier module has 4 slots available for the 4PIOs, totaling 16 ports. The ports can each be provisioned as either OC-3, OC-12, OC-48, or Gigabit Ethernet.
You can install ASAP carrier modules in Slots 1 through 4 and 11 through 14. Each 4PIO module can accommodate up to four SFPs, and each SFP has a female LC connector. For card level indicators, port level indicators, and port numbering consult the Cisco ONS 15600 Reference Manual.
ASAP Card Application
The ASAP Carrier Card plugs into any of the eight available I/O slots for the ONS 15600. Each ASAP carrier card has four slots available for up to and including four ASAP Pluggable Input/output Modules (PIMs). There are four slots available on each PIM for Pluggable Port Modules (PPMs), which are Small Form-factor Pluggable (SFP) optics. Four PPMs per ASAP PIM are allowed, which means that there can be as many as 16 PPM optical network interfaces for each ASAP carrier card. Each PPM port can support any of the following SFP optics modules:
•
•
•
•
–
–
–
–
Each ASAP 4port I/O (ASAP_4PIO) PIM is hot-pluggable while other ports on other PIMs are functional. Each SFP is also hot-pluggable.
Layer 1 Ethernet transport is implemented for Gigabit Ethernet (GE) interfaces. GE traffic is generic framing procedure (GFP), ITU X.86, or Cisco high-level data link control/LAN extension (HDLC/LEX) encapsulated and mapped into a SONET payload.
The data path processing consists of:
•
•
Note
Ethernet facilities on the ASAP card include:
•
•
–
–
–
For specifics on Ethernet operation, framing, mapping, etc. using the ASAP card refer to the Cisco ONS 15600 Reference Manual.
New Software Features
GFP-F Framing
Generic Framing Procedure (GFP) defines a standard-based mapping for different types of services onto SONET/SDH. With Release 5.0.x the ASAP card supports frame-mapped GFP (GFP-F), the PDU-oriented client signal adaptation mode for GFP. GFP-F maps one variable length data packet onto one GFP packet. GFP defines common functions and payload specific functions. Common functions are those shared by all payloads. Payload-specific functions differ depending on the payload type. The GFP standard is detailed in ITU recommendation G.7041.
Provisionable Framing Mode
Release 5.0.x provides a method to provision framing mode in the card view, Provisioning > Card tab, which displays the framing mode selections for the card in a drop-down list, and allows you to change the framing mechanism to either HDLC or GFP-F. You can also preprovision the framing mode prior to installing the card, and the card will boot up in the pre-provisioned mode. For details on framing mode provisioning consult to user documentation.
Pluggable Port Module Support
Release 5.0.x supports four small form-factor pluggables (SFPs), also known as Pluggable Port Modules (PPMs), for the ONS 15600 ASAP card.
Table 1 lists the available SFPs for the Cisco ONS 15600.
For SFP applications with the ASAP card refer to the Cisco ONS 15600 Reference Manual. For information on the particular SFPs and their installation, consult the document, Installing GBIC, SFP and XFP Optical Modules in Cisco ONS 15454, 15327, 15600, and 15310 Platforms.
Enhanced State Model
Release 5.0.x introduces new administrative and service states for Cisco ONS 15600 cards, ports, and cross-connects. Administrative and service states are based on the generic state model defined in Telcordia GR-1093 Core, Issue 2 and ITU-T X.731 and are available for all support management interfaces. The following state types and state transition types are defined for Release 5.0.x. Consult the Cisco ONS 15600 Reference Manual for specific states and their applications.
Service States
Service states include a Primary State (PST), a Primary State Qualifier (PSTQ), and one or more Secondary States (SST).
Administrative States
Administrative states are used to manage service states. Administrative states consist of a PST and an SST. A change in the administrative state of an entity does not change the service state of supporting or supported entities.
Service State Transitions
The possible transitions from one service state to the next state for cards, ports, and cross-connects. A service state transition is based on the action performed on the entity and any autonomous activity.
Card Service State Transitions
The service state transitions for cards.
Port and Cross-Connect Service State Transitions
Port states do not impact cross-connect states with one exception. A cross-connect in the OOS-AU,AINS service state cannot transition autonomously into the IS-NR service state until the parent port is IS-NR.
Circuit State Model
Release 5.0.x adds support for circuit service and administrative states in CTC. For more information consult the user documentation.
32 Ring Two-fiber BLSR
With Release 5.0.x The ONS 15600 can support 32 concurrent two-fiber bidirectional line switched rings (BLSRs). Each BLSR can support up to 24 ONS 15600s. Because the working and protect bandwidths must be equal, you can create only OC-48 or OC-192 BLSRs.
In-Service Topology Upgrades
In Release 5.0.x in-service topology upgrades are supported for unprotected to path protection, and terminal to linear (add a node to a 1+1). Release 5.0.x provides both manual methods and CTC wizards for completing these upgrades.
Note
CTC Topology Upgrade Wizards
The following CTC topology upgrade wizards have been added for Release 5.0.x to support in service topology upgrades.
Terminal to Linear—Add a Node to 1+1
The wizard for this feature is invoked by right-clicking on a 1+1 link and then selecting the "terminal to linear" option. The option adds a node between a two nodes connected by a 1+1.
Additional Support for In Service Topology Upgrades
Circuit Routing
With Release 5.0.x you can choose between manually or automatically routing path protection circuits for a topology upgrade.
The following circuit types are supported for topology upgrades.
•
•
•
•
•
•
Circuit Merge and Reconfigure
The circuit merge and reconfigure features enable you to merge selected CTC or TL1 circuits into one or more discovered CTC circuits based on the alignment of the circuit cross-connects, rather than the circuit ID.
Circuit Merge merges m circuits into one circuit. This feature takes one master circuit and merges aligned circuits with the master.
Circuit Reconfigure merges m circuits into n circuits. This feature takes m circuits and reconfigures them based on cross-connect alignment. To merge circuits choose the Merge subtab of the Edit Circuits tab in CTC. To merge circuits choose the Merge subtab of the Edit Circuits tab in CTC. To reconfigure circuits, choose the CTC Tools > Circuits tab, and select "Reconfigure Circuits..."
Dual-ring Interconnect
Dual-ring interconnect (DRI) topology provides an extra level of path protection for circuits on interconnected rings. DRI allows users to interconnect BLSRs, path protection configurations, or a path protection with a BLSR, with additional protection provided at the transition nodes. In a DRI topology, ring interconnections occur at two or four nodes.
DRI Features
The following list provides supported BLSR DRI features at a glance.
•
•
•
•
•
•
•
•
•
•
•
•
Note
Note
BLSR DRI
Unlike BLSR automatic protection switching (APS) protocol, BLSR DRI is a path-level protection protocol at the circuit level. Drop-and-continue BLSR-DRI requires a service selector in the primary node for each circuit routing to the other ring. Service selectors monitor signal conditions from dual feed sources and select the one that has the best signal quality. Same-side routing drops the traffic at primary nodes set up on the same side of the connected rings, and opposite-side routing drops the traffic at primary nodes set up on the opposite sides of the connected rings. For BLSR DRI, primary and secondary nodes cannot be the circuit source or destination.
A DRI circuit cannot be created if an intermediate node exists on the interconnecting link. However, an intermediate node can be added on the interconnecting link after the DRI circuit is created.
DRI protection circuits act as protection channel access (PCA) circuits. In CTC, you set up DRI protection circuits by selecting the PCA option when setting up primary and secondary nodes during DRI circuit creation.
Path Protection to BLSR DRI Handoff Configurations
Path protection configurations and BLSRs can also be interconnected. In path protection to BLSR DRI handoff configurations, primary and secondary nodes can be the circuit source or destination, which is useful when non-DCC optical interconnecting links are present.
Open GNE
Release 5.0.x supports open GNE configurations, through which the ONS 15600 can communicate with non-ONS nodes that do not support point-to-point protocol (PPP) vendor extensions or OSPF type 10 opaque link-state advertisements (LSA), both of which are necessary for automatic node and link discovery. An open GNE configuration allows the DCC-based network to function as an IP network for non-ONS nodes. To support open GNE Release 5.0.x provides provisionable foreign DCC terminations, provisionable proxy server tunnels, and provisionable firewall tunnels.
Foreign DCC termination
To configure an open GNE network, you can provision SDCC, LDCC, and GCC terminations to include a far-end, non-ONS node using either the default IP address of 0.0.0.0 or a specified IP address. You provision a far-end, non-ONS node by checking the "Far End is Foreign" check box during SDCC, LDCC, and GCC creation. The default 0.0.0.0 IP address allows the far-end, non-ONS node to provide the IP address; if you set an IP address other than 0.0.0.0, a link is established only if the far-end node identifies itself with that IP address, providing an extra level of security.
Proxy Server Tunnels and Firewall Tunnels
By default, the SOCKS proxy server only allows connections to discovered ONS peers, and the firewall blocks all IP traffic between the DCC network and LAN. You can, however, provision proxy tunnels to allow up to 12 additional destinations for SOCKS version 5 connections to non-ONS nodes. You can also provision firewall tunnels to allow up to 12 additional destinations for direct IP connectivity between the DCC network and LAN. Proxy and firewall tunnels include both a source and destination subnet. The connection must originate within the source subnet and terminate within the destination subnet before either the SOCKS connection or IP packet flow is allowed.
To set up proxy and firewall subnets in CTC, use the Provisioning > Network > Proxy and Firewalls subtabs. The availability of proxy and/or firewall tunnels depends on the network access settings of the node. See the user documentation for further details.
State Verification Scan Before Activation
Before allowing a software activation or reversion to proceed, Release 5.0.x nodes verify that their current state meets required activation criteria. Activation criteria must be met in order to avoid traffic hits. For ONS 15454, ONS 15454 SDH, ONS 15327, and ONS 15310 nodes, all BLSR spans on the node must be locked-out, and no 1:1, 1:N, 1+1 or Y-Cable protection switches can be in progress. For ONS 15600 nodes, all BLSR spans on the node must be locked-out.
Admin SSM
Synchronization status messaging (SSM) is a protocol that communicates information about the quality of the timing source. SSM messages enable nodes to automatically select the highest quality timing reference and to avoid timing loops. With Release 5.0.x you can configure an SSM value for a timing source (either BITS-IN or Optical Line) by selecting from the "ADMIN. SSM" selection box in the BITS Facilities subtab of the node view, Provisioning > Timing tabs. This feature is useful when the selected external timing source has no SSM information. When you select the Admin SSM value, all switching decisions are subsequently made based on your selection. The same SSM value is transmitted out of the interface configured for BITS Out, and in transmit Optical S1. The DS1 BITS type with framing type SF(D4) only supports Admin SSM. The 64KHz+8KHz clock (ONS 15454 SONET) also only supports Admin SSM. ESF Framing must have Sync Messaging turned off (uncheck the check box) in order to enable Admin SSM selection. SONET nodes use the SSM Generation II message set, as defined in Table 4 of ANSI T1.101-1999. SDH nodes support SDH generation 1 SSM and STU. SONET nodes support only SONET SSM (GR-253).
STS Around Ring
Release 5.0.x supports manual provisioning of contiguous concatenation (CCAT) STS circuits around the ring (traffic travels around the ring, starting and ending at the same node). In previous releases, if you selected the circuit source and destination as starting and ending on different I/O ports of the same node, the result would be an intra-node circuit only. With Release 5.0.x, you can manually route this type of circuit all the way around the ring. STS around the ring is supported for an unprotected path, in an unprotected ring, unless the underlying topology is line protected, in which case the around the ring circuit will also be line protected. STS around the ring is supported for all circuit sizes, starting with STS1 (SONET), or STM1 (SDH), and for all supported management interfaces.
Provisionable Patchcords
A provisionable patchcord is a user-provisioned link that is advertised by OSPF throughout the network. Provisionable patchcords, also called virtual links, are needed if an ONS 15600 optical port is connected to an ONS 15454 transponder or muxponder client port provisioned in transparent mode. Provisionable patchcords are required on both ends of a physical link. The provisioning at each end includes a local patchcord ID, slot and port information, remote IP address, and remote patchcord ID. Patchcords appear as dashed lines in CTC network view.
For supported combinations for ONS 15600 optical cards and the ONS 15454 transponder/muxponder cards used in a provisionable patchcord, refer to the Cisco ONS 15600 Reference Manual. For more information about the ONS 15454 transponder and muxponder cards, refer to the Cisco ONS 15454 Reference Manual.
Optical ports have the following requirements when used in a provisionable patchcord:
•
•
•
SONET J1 Path Trace Automatic Mode
With Release 5.0.x the ONS 15600 supports J1 path trace automatic mode through both CTC and TL1.
You can enable the SONET J1 Path Trace byte to monitor interruptions or changes to circuit traffic provisioned on the following ONS 15600 cards.
•
•
•
•
•
•
The J1 byte transmits a repeated, 64-byte, fixed-length string. If the string received at a circuit drop port does not match the string the port expects to receive, an alarm is raised. In automatic mode, the receiving port assumes the first J1 string it receives is the baseline J1 string.
Note The ONS 15600 does not support J1/IPPM for BLSR.
Timing Synchronization Enhancements
Support for additional timing synchronization enhancements is added for the Release 5.0.x ONS 15600. The following additional timing enhancements are supported by both CTC and TL1.
•
•
•
For full details of timing synchronization support, refer to the Cisco ONS 15600 Reference Manual.
CTC Enhancements
SSH Shell Access Option
With Release 5.0.x an ONS 15600 Superuser can select secure shell (SSH) as an alternative to Telnet at the CTC Provisioning > Security > Access tabs. SSH is a terminal-remote host Internet protocol that uses encrypted links. It provides authentication and secure communication over unsecure channels. Port 22 is the default port and cannot be changed.
CTC Circuits State Default
The Release 5.0.x circuit creation wizard uses the new node default value, Node.circuits.State, as the default circuit state when creating a circuit. This default can be set in the NE Defaults window, and will not be overridden by the "user preferences" command feature, which caused the default value to be abandoned when using the wizard in previous releases.
Shell Login Challenge
Release 5.0.x supports the requirement of a specific shell password, set initially by the first shell user and then required of subsequent shell users at login. When this feature is enabled, the password is required of all shell users (rather than each user having a separate account) from the time it is set or changed. In the CTC node view, Provisioning > Security> Access tabs, check the "Enable Shell Password" check box to enable the shell password feature. The password can then be set or changed in a telnet or SSH shell session using the "passwd" command.
Note
Date Format Selection
Release 5.0.x adds a date format option to CTC, enabling you to choose between U.S. (MM/DD/YY) and European (DD/MM/YY) date formats. To choose the date format, click the Edit menu and choose Preferences. Select the desired date format (the default is MM/DD/YY) and click OK. The name/value pair ("ctc.dateFormat=DD/MM/YY" or "ctc.dateFormat=MM/DD/YY") will be updated in the ctc.ini (Windows), or .ctcrc (UNIX) file, where preferences are stored. Subsequently, the date format used in all tables, dialogs, and tabs will be changed to the format you selected in the Preferences dialog.
Provisionable Patchcord Tab
Provisionable patchcords, also called virtual links, are needed if an ONS 15600 optical port is connected to an ONS 15454 transponder or muxponder client port provisioned in transparent mode. Release 5.0.x features a Provisionable Patchcord subtab in CTC that displays physical links and their associated protection types, so that, when a control channel cannot be terminated on either end of a physical link, and as a result, the physical link cannot be automatically discovered by OSPF, you can still view the physical link and its protection type in the management software interface. You can view the physical links and their terminations from the CTC network view > Provisioning > Provisionable Patchcords tabs; or from the CTC node view > Provisioning > Comm Channels > Provisionable Patchcords tabs. To provision the patchcord, you select the Node Name, Slot, Port, and ID for both ends of the physical link. The ID is a unique 16-bit number used to identify a virtual link on a node. IDs are only unique for the particular node.
TL1-CTC Circuit Unification
In Release 5.0.x CTC fully supports TL1-created circuits and TL1 fully supports CTC-created circuits. Release 5.0.x circuit behavior and appearance is unified across both management interfaces, and you can easily alternate between the two. It is also no longer necessary to upgrade a TL1 circuit for CTC, or to downgrade a CTC circuit for TL1. The following circuit unification enhancements are supported with Release 5.0.x.
•
•
•
•
•
•
•
•
•
•
•
•
•
Software Upgrade
Software upgrades from Release 1.x to 5.0.x are supported.
Cisco Transport Manager
Cisco Transport Manager (CTM) Release 5.0 supports the ONS 15600 Release 5.0.
TL1
High Level Functional Differences
The following high level support is added for Release 5.0.x.
Enhanced State Model Support
In Release 5.0.x, equipment, ports and circuits support additional Primary and Secondary states. Messages of the form REPT^DBCHG^MSG contain new Enhanced State Model (ESM) states in Release 5.0.x. The following are the new SONET states in ESM, as defined for TL1.
PST-PSTQ
Table 2 describes each service state of the entity described by the Primary State (PST) and a Primary State Qualifier (PSTQ).
Table 2 Primary States
IS-NR
In Service - Normal
OOS-AU
Out of Service - Autonomous
OOS-AUMA
Out of Service - Autonomous and Management
OOS-MA
Out of Service - Management
SST
Table 3 describes the Secondary States (SST). This parameter provides additional information pertaining to PST and PSTQ.
Remote Monitoring
TL1 support for Remote Monitoring (RMON) is added in Release 5.0.x for GIGE ports on the ASAP card.
Additional Functional Support
The following additional high level features add functional support in Release 5.0.x TL1.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
TL1 Command Changes
New Commands
The following commands were added in Release 5.0.x
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Command Syntax Changes
The syntax of the following commands is changed in Release 5.0.x.
ALW-MSG-ALL syntax:
ALW-MSG-ALL:[<TID>]::<CTAG>[::,,];
Is changed to:
ALW-MSG-ALL:[<TID>]:[<aid>]:<CTAG>[::,,];
DLT-CRS-<PATH> syntax:
DLT-CRS-<STS_PATH>:[TID]:<from>,<to>:[CTAG]::[]:[];
Is changed to:
DLT-CRS-<PATH>:[<TID>]:<src>,<dst>:<CTAG>:::[CKTID=<cktid>,][CMDMDE=<cmdmde>];
ED-CRS-<PATH> syntax:
ED-CRS-<STS_PATH>:[TID]:<src>,<dst>:[CTAG]::<cct>;
Is changed to:
ED-CRS-<PATH>:[<TID>]:<src>,<dst>:<CTAG>:::[ADD=<add>,][REMOVE=<remove>,][CKTID=<cktid>,][CMDMDE=<cmdmde>]:<pst>,[<sst>];
ED-<OCN_TYPE> syntax:
ED-<OCN_TYPE>:[TID]:<aid>:[CTAG]:::[DCC=<dcc>],[AREA=<area>],[SYNCMSG=<syncmsg>],[SENDDUS=<senddus>],[SFBER=<sfber>],[SDBER=<sdber>],[MODE=<mode>]:[<pst>];
Is changed to:
ED-<OCN_TYPE>:[<TID>]:<aid>:<CTAG>:: :[DCC=<dcc>,][AREA=<area>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][SFBER=<sfber>,][SDBER=<sdber>,][MODE=<mode>,][MUX=<mux>,][SOAK=<soak>,][OSPF=<ospf>,][LDCC=<ldcc>,][NAME=<name>,][CMDMDE=<cmdmde>,][EXPTRC=<exptrc>,][TRC=<trc>,][TRCMODE=<trcmode>,][TRCFROMAT=<trcfromat>,][ADMSSM=<admssm>,][SENDDUSFF=<senddusff>]:<pst>,[<sst>];
ED-BITS syntax:
ED-BITS:[<TID>]:<aid>:<CTAG>:::[LINECDE=<linecde>,][FMT=<fmt>,] [SYNCMSG=<syncmsg>,] [:<pst>];
Is changed to:
ED-BITS:[<TID>]:<aid>:<CTAG>:::[LINECDE=<linecde>,][FMT=<fmt>,][SABIT=<sabit>,][IMPEDANCE=<impedance>,][LBO=<lbo>,][SYNCMSG=<syncmsg>,][AISTHRSHLD=<aisthrshld>,][BITSFAC=<bitsfac>,][ADMSSM=<admssm>][:<pst>];
ED-CRS-STS-PATH syntax:
ED-CRS-<STS_PATH>:[TID]:<src>,<dst>:[CTAG]::<cct>;
Is changed to:
ED-CRS-<PATH>:[<TID>]:<src>,<dst>:<CTAG>:::[ADD=<add>,][REMOVE=<remove>,][CKTID=<cktid>,][CMDMDE=<cmdmde>]:<pst>,[<sst>];
ED-<MOD_PATH> syntax:
ED-<STS_PATH>:[TID]:<aid>:[CTAG]::[]:[SFBER=<sfber>],[SDBER=<sdber>],[RVRTV=<rvrtv>],[RVTM=<rvtm>],[EXPTRC=<exptrc>],[TRCMODE=<trcmode>],[TACC=<tacc>],[TAPTYPE=<taptype>]:[];
Is changed to:
ED-<MOD_PATH>:[<TID>]:<aid>:<CTAG>:::[SFBER=<sfber>,][SDBER=<sdber>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][SWPDIP=<swpdip>,][HOLDOFFTIMER=<holdofftimer>,][EXPTRC=<exptrc>,][TRC=<trc>,][TRCMODE=<trcmode>,][TACC=<tacc>,][TAPTYPE=<taptype>,][CMDMDE=<cmdmde>]:<pst>,[<sst>];
ENT-CRS-<STS_PATH> syntax:
ENT-CRS-<STS_PATH>:[TID]:<from>,<to>:[CTAG]::[<cct>]::[];
Is changed to:
ENT-CRS-<PATH>:[<TID>]:<src>,<dst>:<CTAG>::<cct>:[DRITYPE=<dritype>,][DRINODE=<drinode>,][CKTID=<cktid>,][CMDMDE=<cmdmde>]:<pst>,[<sst>];
ENT-EQPT syntax:
ENT-EQPT:[TID]:<aid>:[CTAG]::<aidtype>;
Is changed to:
ENT-EQPT:[<TID>]:<aid>:<CTAG>::<aidtype>:[PROTID=<protid>,][PRTYPE=<prtype>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][CARDMODE=<cardmode>,][PEERID=<protid>,][REGENNAME=<regenname>,][PWL=<pwl>,][CMDMDE=<cmdmde>][:];
EX-SW-<OCN_BLSR> syntax:
EX-SW-<OCN_BLSR>:[TID]:<aid>:[CTAG]::<st>;
Is changed to:
EX-SW-<OCN_BLSR>:[<TID>]:<aid>:<CTAG>::,<switchType>,[<direction>];
RTRV-CRS syntax:
RTRV-CRS:[<TID>]:<aid>:<CTAG>[:::CRSTYPE=<crstype>][:];
Is changed to:
RTRV-CRS:[<TID>]:[<aid>]:<CTAG>[:::CRSTYPE=<crstype>][:];
TL1 Response Changes
The following TL1 responses have changed in Release 5.0.x.
RTRV-BITS response:
"<aid>::[LINECDE=<linecde>],[FMT=<fmt>],[SYNCMSG=<syncmsg>]:[<pst>]"
Is changed to:
"<aid>::[LINECDE=<linecde>,][FMT=<fmt>,][LBO=<lbo>,][SYNCMSG=<syncmsg>,][AISTHRSHLD=<aisthrshld>,][SABIT=<sabit>,][IMPEDANCE=<impedance>,][BITSFAC=<bitsfac>,][ADMSSM=<admssm>]:[<pst>]"
RTRV-CRS response:
<from>,<to>:<cct>,<level>
Is changed to:
<src>,<dst>:<cct>,<crsType>:[DRITYPE=<dritype>,][DRINODE=<syncsw>,][CKTID=<cktid>]:<pst_pstq>,[<sstq>]
RTRV-CRS-<PATH> response:
<from>,<to>:<cct>,<level>
Is changed to:
<src>,<dst>:<cct>,<crsType>:[DRITYPE=<dritype>,][DRINODE=<syncsw>,][CKTID=<cktid>]:<pst_pstq>,[<sstq>]
RTRV-FFP-<OCN_TYPE> reponse:
<work>,<protect>::[PROTID=<protid>],[RVRTV=<rvrtv>],[RVTM=<rvtm>],[PSDIRN=<psdirn>]
Is changed to:
<work>,<protect>::[PROTID=<protid>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][PSDIRN=<psdirn>,][VRGRDTM=<vrgrdtm>,][DTGRDTM=<dtgrdtm>,][RCGRDTM=<rcgrdtm>,][OPOTYPE=<opotype>]
RTRV-INV reponse:
<aid>,<aidtype>::[PN=<pn>],[HWREV=<hwrev>],[FWREV=<fwrev>],[SN=<sn>],[CLEI=<clei>],[UCODE=<ucode>]
Is changed to:
<aid>,<aidtype>::[PLUGTYPE=<plugtype>,][PN=<pn>,][HWREV=<hwrev>,][FWREV=<fwrev>,][SN=<sn>,][CLEI=<clei>,][TWL1=<twl>,][TWL2=<twl1>,][TWL3=<twl2>,][TWL4=<twl3>,][PLUGINVENDORID=<pluginvendorid>,][PLUGINPN=<pluginpn>,][PLUGINHWREV=<pluginhwrev>,][PLUGINFWREV=<pluginfwrev>,][PLUGINSN=<pluginsn>,][ILOSSREF=<ilossref>,][PID=<pid>,][VID=<vid>,][FPGA=<fpga>]
RTRV-EQPT response:
<aid>:<aidtype>,<equip>,[],[<status>]:[CARDNAME=<cardname>]:[<pst>]
Is changed to:
<aid>:<aidtype>,<equip>,[<role>],[<status>]:[PROTID=<protid>,][PRTYPE=<prtype>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][CARDNAME=<cardname>,][IOSCFG=<ioscfg>,][CARDMODE=<cardmode>,][PEERID=<peerid>,][REGENNAME=<regenname>,][PWL=<pwl>]:<pst_pstq>,<sstq>
RTRV-OCN-TYPE response:
<aid>:,,[<role>],[<status>]:[DCC=<dcc>],[AREA=<area>],[TMGREF=<tmgref>],[SYNCMSG=<syncmsg>],[SENDDUS=<senddus>],[SFBER=<sfber>],[SDBER=<sdber>],[MODE=<mode>],[WVLEN=<wvlen>],,:[<pst>]
Is changed to:
<aid>:,,[<role>],[<status>]:[DCC=<dcc>,][AREA=<area>,][TMGREF=<tmgref>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][SFBER=<sfber>,][SDBER=<sdber>,][MODE=<mode>,][WVLEN=<wvlen>,][RINGID=<ringid>,][BLSRTYPE=<blsrtype>,][MUX=<mux>,][UNIC=<unic>,][CCID=<ccid>,][NBRIX=<nbrix>,][SOAK=<soak>,][SOAKLEFT=<soakleft>,][SSMRCV=<ssmrcv>,][OSPF=<ospf>,][LDCC=<ldcc>,][NAME=<name>,][LBCL=<lbcl>,][OPT=<opt>,][OPR=<opr>,][EXPTRC=<exptrc>,][TRC=<trc>,][TRCMODE=<trcmode>,][TRCFORMAT=<trcformat>,][ADMSSM=<admssm>,][SENDDUSFF=<senddusff>]:<pst_pstq>,[<sstq>]
Autonomous Message Changes
The following autonomous message syntax has changed.
REPT^DBCHG syntax:
SID DATE TIME
A ATAG REPT DBCHG
"TIME=<time>,DATE=<date>,[SOURCE=<source>],[USERID=<userid>],DBCHGSEQ=<dbchgseq>:<command>:<aid>"
;
Is changed to:
SID DATE TIME
A ATAG REPT DBCHG
"TIME=<time>,DATE=<date>,[SOURCE=<source>,][USERID=<userid>,]DBCHGSEQ=<dbchgseq>:<command>:<aid>:::<pstpstq>,<sst>"
;
TL1 ENUM Changes
The following section, including Table 4 through Table 29, highlights ENUM items changed (added or removed) for Release 5.0.x, by ENUM type.
BITS_FAC is used in the following commands:
•
•
CCT is used in the following commands:
•
•
•
•
Table 6 CRS_TYPE enum items added in Release 5.0.x
CRS_TYPE_STS6C
"STS6C"
CRS_TYPE_STS9C
"STS9C"
CRS_TYPE is used in the following commands:
•
DETECTION_GUARD_TIMER is used in the following commands:
•
•
•
Table 8 DRINODE enum items added in Release 5.0.x
DRINODE_INT
"INT"
DRINODE_NA
"NA"
DRINODE_PRI
"PRI"
DRINODE_SEC
"SEC"
DRINODE is used in the following commands:
•
•
DRITYPE is used in the following commands:
•
•
Table 10 ENCAP enum items added in Release 5.0.x
ENCAP_GFP_F
"GFP-F"
ENCAP_HDLC
"HDLC"
ENCAP_HDLC_X86
"HDLC-X86"
ENCAP_UNKNOWN
"UNKNOWN"
ENCAP is used in the following commands:
•
•
EQPT_TYPE is used in the following commands:
•
•
•
•
Table 12 CONST_MODE enum used instead of ENV_CRTL_MODE
CONST_MODE_NA
"NA"
CONST_MODE_OPER
"CLOSE"
CONST_MODE_RLS
"OPEN"
Table 13 FCS enum items added in Release 5.0.x
FCS_16
"FCS-16"
FCS_32
"FCS-32"
FCS_NONE
"NONE"
FCS is used in the following commands:
•
•
•
MOD1PAYLOAD is used in the following commands:
•
•
MOD2 is used in the following commands:
•
•
•
Table 16 MOD2RMON enum items added in Release 5.0.x
MOD2_GIGE
"GIGE"
MOD2_POS
"POS"
MOD2RMON is used in the following commands:
•
•
•
Table 17 MOD_PATH enum items added in Release 5.0.x
MOD_PATH_M2_STS6C
"STS6C"
MOD_PATH_M2_STS9C
"STS9C"
MOD_PATH is used in the following commands:
•
•
•
•
Table 18 NE_SECU_MODE enum items added in Release 5.0.x
NE_SECU_MODE_REPEATER
"REPEATER"
NE_SECU_MODE_SECURE
"SECURE"
NE_SECU_MODE is used in the following commands:
•
PAYLOAD is used in the following commands:
•
Table 20 PRODUCT_TYPE enum items added in Release 5.0.x
PRODUCT_TYPE_NE_15310_CL
"ONS15310-CL"
PRODUCT_TYPE is used in the following commands:
•
Table 21 PST_PSTQ enum items added in Release 5.0.x
PST_PSTQ_IS_NR
"IS-NR"
PST_PSTQ_OOS_AU
"OOS_AU"
PST_PSTQ_OOS_AUMA
"OOS_AUMA"
PST_PSTQ_OOS_MA
"OOS_MA"
PST_PSTQ is used in the following commands:
•
•
•
•
•
•
•
•
•
•
RECOVERY_GUARD_TIMER is used in the following commands:
•
•
•
Table 23 SAMPLE_TYPE enum items added in Release 5.0.x
SAMPLE_TYPE_ABSOLUTE
"ABSOLUTE"
SAMPLE_TYPE_DELTA
"DELTA"
SAMPLE_TYPE is used in the following commands:
•
Table 24 SNMP_VERSION enum items added in Release 5.0.x
SNMP_VERSION_SNMPV1
"SNMPV1"
SNMP_VERSION_SNMPV2
"SNMPV2"
SNMP_VERSION is used in the following commands:
•
•
SST is used in the following commands:
•
•
•
•
•
•
•
•
•
•
•
•
Table 26 STARTUP_TYPE enum items added in Release 5.0.x
STARTUP_TYPE_FALLING
"FALLING"
STARTUP_TYPE_RISING
"RISING"
STARTUP_TYPE_RISING_OR_FALLING
"RISING-OR-FALLING"
STARTUP_TYPE is used in the following commands:
•
Table 27 TMPER enum items added in Release 5.0.x
TMPER_PER_HR
"1-HR"
TMPER_PER_MIN
"1-MIN"
TMPER_RAW_DATA
"RAW-DATA"
TMPER is used in the following commands:
•
•
•
•
•
•
•
•
VALIDITY is used in the following commands:
•
•
Table 29 VERIFICATION_GUARD_TIMER enum items added in Release 5.0.x
VERIFICATION_GUARD_TIMER_1
"1.0"
VERIFICATION_GUARD_TIMER_500
"0.5"
VERIFICATION_GUARD_TIMER is used in the following commands:
•
•
•
Related Documentation
Release-Specific Documents
•
•
•
•
•
•
Platform-Specific Documents
•
Provides installation, turn up, test, and maintenance procedures•
Provides technical reference information for SONET/SDH cards, nodes, and networks•
Provides a list of SONET alarms and troubleshooting procedures, general troubleshooting information, and hardware replacement procedures•
Provides a comprehensive list of TL1 commandsObtaining Documentation
The following sections provide sources for obtaining documentation from Cisco Systems.
World Wide Web
You can access the most current Cisco documentation on the World Wide Web at the following sites:
Documentation CD-ROM
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.
Ordering Documentation
Cisco documentation is available in the following ways:
•
http://www.cisco.com/cgi-bin/order/order_root.pl
•
http://www.cisco.com/go/subscription
•
Documentation Feedback
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-9883We appreciate your comments.
Obtaining Technical Assistance
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
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.
To access Cisco.com, go to the following website:
Technical Assistance Center
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.
Contacting TAC by Using the Cisco TAC Website
If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website:
http://www.cisco.com/en/US/support/index.html
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:
http://tools.cisco.com/RPF/register/register.do
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:
http://www.cisco.com/tac/caseopen
Contacting TAC by Telephone
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.shtml
P1 and P2 level problems are defined as follows:
•
•
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
Copyright © 2007, Cisco Systems, Inc.
All rights reserved.
