 Feedback
|
Table Of Contents
Release Notes for Cisco ONS 15600 Release 6.0.1
Maintenance and Administration
Resolved Caveats for Release 6.0.1
New Features and Functionality
OC-48 DWDM SFPs for the 15600-ASAP-4PIO
Obtaining Optical Networking Information
Where to Find Safety and Warning Information
Cisco Optical Networking Product Documentation CD-ROM
Obtaining Documentation and Submitting a Service Request
Release Notes for Cisco ONS 15600 Release 6.0.1
July 2008
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 15600. For detailed information regarding features, capabilities, hardware, and software introduced with this release, refer to Release 6.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 6.0.1, 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://tools.cisco.com/Support/BugToolKit/action.do?hdnAction=searchBugs
Contents
Resolved Caveats for Release 6.0.1
New Features and Functionality
Obtaining Optical Networking Information
Obtaining Documentation and Submitting a Service Request
Changes to the Release Notes
This section documents supplemental changes that have been added to the Release Notes for Cisco ONS 15600 Release 6.0.1 since the production of the Cisco ONS 15600 System Software CD for Release 6.0.1.
No changes have been added to the release notes for Release 6.0.1.
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.
Hardware
ONS-SE-2G-xx.x
The ONS-SE-2G-xx.x complies with performance criteria for all intrafacility fiber cables and connectors per Telcordia GR-326-CORE, Issue 3 Sept 1999. Cisco recommends the following approved suppliers for intrafacility fiber cables to use with this product:
•
•
•
•
•
Maintenance and Administration
Caution
CSCeh84908
A CTC client session can disconnect from an ONS node during simultaneous deletion of large numbers of VT level circuits (3000+). Connectivity to the node will recover without any user action. If the condition persists, restart the CTC session to reconnect. This issue is under investigation.
CSCei44592
You can have no more than 113 DCC links in one area ID. For example, with 128 DCC Links provisioned within one area ID, 14 DCC links gray out in CTC. To avoid this issue divide the 128 DCCs into multiple area IDs (at least two). This issue is resolved in Release 7.0.
CSCei14295
After restoring a previously backed up database, the restoral of the PM history database is not time-based, but rather, position-based. The PM history database is stored or retrieved to or from position-dependent time slots from the present PM period. Thus, PM history backed up 24 hours prior to the restore will show the PM history without acknowledging the missing day. This issue will be resolved in a future release.
CSCeg57163
ONS platforms support only a single OSPF virtual link. This issue will be resolved in a future release.
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.
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.
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 not be resolved.
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 not be resolved.
Optical IO Cards
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.
CSCei37179
Rarely, when an ASAP card is participating in a DCC tunnel, and working and protect spans both fail, the ASAP card might stop responding, sometimes followed by a reset. When this occurs there is no resulting traffic loss, and protection switching continues to function. To recover ASAP card responsiveness a soft reset of the card might be necessary. This issue is resolved in Release 7.0.
CSCsb46157
When the first and second ports of a PIM are provisioned as GIGE and, at a minimum, the second port is in a circuit, or, when the third and fourth ports of a PIM are provisioned as GIGE and, at a minimum, the fourth port is in a circuit, packets might be dropped on a soft reset of the associated ASAP card. To prevent this, avoid provisioning a GIGE port next to another GIGE port. This issue is resolved in Release 6.1.
BLSR Functionality
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 not be resolved.
Interoperability
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 not be resolved.
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 not be resolved.
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.
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.
Bridge and Roll
CSCei37364
When a rollTo leg is not receiving a good signal, and because of this the rollPending alarm is not cleared, there is no alarm indicating the reason that the RollPending alarm fails to clear. This issue is resolved in Release 7.0.
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.
TL1
CSCeh88565
When the Cisco ONS 15600 is supporting 500 TL1 sessions and there is a sustained high level of management traffic the active TSC might reset. This issue is visible when the Cisco ONS 15600 is supporting 500 TL1 ENE logins to DCC-linked network nodes such as the Cisco ONS 15454. In a laboratory test it was observed that an alarm flood (approximately 70000 alarm messages) in the network would overload the active TSC and cause it to reset. The standby TSC transitions to active and the node recovers. To avoid this issue configure TL1 sessions to throttle the amount of alarm data that is sent across the management network. For example, when a TL1 session starts, the REPT^ALM and REPT^EVT messages are allowed by default. The TL1 command "INH-MSG-ALL" will inhibit all REPT-ALM and REPT^EVT autonomous messages from being transmitted. This issue is resolved in Release 7.0.
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 6.0.1
The following caveats were resolved in Release 6.0.x.
Upgrades
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. This issue will not occur for upgrades from Release 5.0.x to 6.0.x. For further documentation of this circumstance, see the Upgrading Cisco ONS 15600 Release 6.0 document.
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 is resolved in Release 6.0.
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 is resolved in Release 6.0.
Optical Cards
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 is resolved in Release 6.0.
Common Control Cards
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 is resolved in Release 6.0.
BLSR Functionality
CSCsb60780
The wrong ACT/STBY state is reported for BLSR facilities using the TL1 RTRV-OCn command. After a ring or span switch, the TL1 RTRV-OCn command might return incorrect ACT/STBY states for the affected BLSR facilities. To recover from this situation, soft reset the TSC or soft reset both matrix cards. This issue is resolved in Releases 6.0.1, 6.1, and 7.0.
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 is resolved in Release 6.0.
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 is resolved in Release 6.0.
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 is resolved in Release 6.0.
Path Protection Functionality
CSCei64765
Rarely, path protection switching can fail to switch ports in IO Slots 2-4 or 12-14. This issue might occur for path protection selectors after any of the following:
•
•
•
This issue does not occur for cards in IO Slots 1 or 11. This issue can occur for cards in IO Slots 2-4 or 12-14.
There is no workaround for ports on IO Slots 2-4 and 12-14. The possibility for the occurrence is less than 1% under an IO or TSC hard reset or system power failure. This issue is resolved in Releases 5.0.7 and 6.0.1.
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 is resolved in Release 6.0.
TL1 Functionality
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 is resolved in Release 6.0.
CSCsh41324
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 later, the circuit retrieve does not show the same value as before. For example FAC-4-1 changes to FAC-4-0. Workaround is to manually reset the active TSC after the upgrade.
New Features and Functionality
This section highlights new features and functionality for Release 6.0.x. For detailed documentation of each feature, consult the user documentation.
New Hardware
OC-48 DWDM SFPs for the 15600-ASAP-4PIO
With Release 6.0.x the OC-48/STM16 supports 32 DWDM channel SFPs that can be plugged into the four port 15600-ASAP-4PIO. The following parameters are common across all 32 SFPs.
•
•
•
•
•
For further details, including a list of the SFPs by their name and associated operating wavelengths consult the user documentation.
New Software Features
Bridge and Roll TL1 Bulk Roll
Release 6.0.x TL1 bridge and roll features support for bulk rolling. Bulk rolling enables you to roll a subset of cross-connections from one port/facility to another port/facility.
The following TL1 commands specifically support bulk rolls. These commands support line-level rolling/bulk rolling and cannot be used for path-level rolling. For a complete list of TL1 commands supporting bridge and roll, as well as examples for each of the supported features, including bulk roll, consult the user documentation.
DLT-BULKROLL-<OCN_TYPE>
This command deletes an attempted rolling operation or completes an attempted rolling operation. The rolls that are created using the ENT-BULKROLL-<OCN_TYPE> command can be deleted using the DLT-BULKROLL-<OCN_TYPE> command.
ED-BULKROLL-<OCN_TYPE>
This command edits information about rolling traffic from one end point to another without interrupting service. This command can use the CMDMDE option to force a valid signal. The only parameter that can be edited is CMDMDE. The time slots cannot be edited.
ENT-BULKROLL-<OCN_TYPE>
This command enters information about rolling traffic from one end-point to another without interrupting service.
RTRV-BULKROLL-<OCN_TYPE>
This command retrieves roll data parameters.
Four-Fiber BLSR
Release 6.0.x supports four-fiber BLSR for the ONS 15600. A four-fiber BLSR doubles the bandwidth you would have obtained from using a two-fiber BLSR. Because they allow span switching as well as ring switching, four-fiber BLSRs increase the reliability and flexibility of traffic protection. In a four-fiber BLSR two fibers are allocated for working traffic and two fibers for protection. To implement a four-fiber BLSR, you can install either two or four OC-48 or OC-192 cards at each BLSR node. For further details consult the user documentation.
Enhanced Security Features
Security Policy Enhancements
With Release 6.0.x the range of days over which you can enforce disabling of inactive users has increased. The previous range was 45 to 90 days. The new range is 1 to 99 days.
With Release 6.0.x enforced single concurrent user session applies to EMS, TL1, telnet, SSH, sftp, and ftp. This support applied only to EMS and TL1 in previous releases.
In Release 6.0.x you can set how many characters difference must exist between a user's old password and the next new password in a range of one to five characters.
Secure Shell Encryption and Node Access Security
In previous releases the ONS platforms supported SSH version 2 (SSHv2) as an alternative to the ability to telnet into a node (shell access). In Release 6.0.x SSH encrypts all traffic (including passwords) to effectively eliminate unwanted monitoring of node activity. SSHv2 also supports access to the line card shell via shelf controller (that is, via relay).
In Release 6.0.x all HTTP access to a node (for example, database backup, bulk PM retrieval, or software download) allows the use of HTTPS.
In previous releases any service type supported by ONS software could access ONS nodes. In Release 6.0.x node access can be controlled by service type. Each service type from which you can access a node in Release 6.0.x is configurable to support a choice of access states. The available states are non-secure (the default), secure (via SSHv2), and disabled (deny access from this service type). The SSHv2 secure state is supported for shell and ftp (using sftp), TL1, and EMS access types. Only nonsecure and disabled modes are supported for SNMP access.
RADIUS Security
As of Release 6.0 users with Superuser security privileges can configure nodes to use Remote Authentication Dial In User Service (RADIUS) authentication. Cisco Systems uses a strategy known as authentication, authorization, and accounting (AAA) for verifying the identity of, granting access to, and tracking the actions of remote users.
RADIUS Authentication
RADIUS is a system of distributed security that secures remote access to networks and network services against unauthorized access. RADIUS comprises three components:
•
•
•
The server runs on a central computer, while clients reside in the dial-up access servers and can be distributed throughout the network.
An ONS node operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers, and then acting on the response that is returned. RADIUS servers are responsible for receiving user connection requests, authenticating the user, and returning all configuration information necessary for the client to deliver service to the user. RADIUS servers can act as proxy clients to other kinds of authentication servers. Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. User passwords are sent encrypted between the client and RADIUS server. This eliminates the possibility that someone illicitly monitoring an unsecured network might detect a user's password.
An ONS node acting as a RADIUS client can request authentication from up to ten hierarchically arranged RADIUS servers. RADIUS security provisioning features are located in the Provisioning > Security > RADIUS tabs. For further details and operation of RADIUS security features consult the user documentation.
RADIUS Session Time Limits
Release 6.0.x RADIUS supports RADIUS session time limits. This feature applies only when a RADIUS server is used for authentication. When RADIUS indicates that a session is to have a time limit, that session is terminated immediately after the time expires. There is no local database support for session time limits. Rather, when EMS users are forcibly logged out by the RADIUS server, they are presented with a notification dialog box indicating that they have been forcibly logged out due to session time expiration. Similarly, when a TL1 user is logged out, an autonomous REPT_EVT_SESSION is sent. After a TL1 user is logged out, the next command the user enters receives a DENY response with a reason code of PLNA (Login Not Active).
AAA Server Enable/Disable
In Release 6.0.x RADIUS a Superuser can turn AAA server authentication on or off. When AAA server authentication is turned off, the local security policy and settings are employed for user authentication. When AAA server authentication is enabled, it applies to all NE management services, overriding local settings where the two conflict.
Note
•
•
•
•
•
•
•
•
•
AAA server authentication can be set in the node view > Provisioning > Defaults tabs. The default for AAA server authentication is OFF.
Audit Trail Enhancements
The following features enhance your ability to monitor node and network activity through use of the audit trail in Release 6.0.x.
•
•
•
•
•
•
•
CTC Enhanced Security Support
Note
CTC provides several user-configurable security features in the following subtabs under the The CTC node view Security tab.
•
•
•
•
•
The Active Logins, Policy, Access, and RADIUS tabs support new features for Release 6.0.x, as described below.
Active Logins
The Active logins tab supports session management for Release 6.0.x. The Active Logins tab displays current login status information for the network. In previous releases the Active Logins tab displayed only which users were logged in, and the IP address from which each user was logged in. As of Release 6.0.x, in addition to user names and IP addresses, the Active Logins tab displays the specific node to which the user is logged in, the type of session used to log in, the date and time each user logged in, and the last date/time each user was active during the login. You can refresh the Last Activity Time by clicking the Retrieve Last Activity Time button. You also have the option to log out selected sessions. This feature logs out any selected sessions immediately, and interrupts any activities associated with those sessions. When you log out an active user session you have the option to lock the user out (from future sessions) prior to the logout.
In Release 6.0.x the following services are monitored in the Active Logins tab.
•
•
•
•
•
•
Policy
The Policy tab supports user security policy options. The Policy tab provides security policy settings and options. In previous releases the Policy tab provided the following functionality, in five display areas, in which settings could be applied:
•
•
–
–
–
–
•
•
•
With Release 6.0.x, in the "Other" area, enforced single concurrent user session applies to EMS, TL1, telnet, SSH, HTTP, sftp, and ftp, and also, the range of days over which you can enforce disabling of inactive users has increased. The new range is 1 to 99 days.
Release 6.0.x also adds a new Password Change configuration that sets how many characters difference must exist between the old password and the new password in a range of one to five characters.
Node Access
The Access tab supports node access options, including enhanced SSH secure connection support for Release 6.0.x. The Access tab provides settings and options for each type of access that can be used to reach the node. In previous releases, the Access tab included the following three areas for applying node access settings and options.
•
•
•
With Release 6.0.x the Access tab provides four new areas, plus functional changes to the Shell Access area, for a total of seven areas in which settings can be applied as follows.
•
•
•
•
•
•
•
RADIUS
The RADIUS tab is new for Release 6.0.x, and supports the new RADIUS security features, including RADIUS server management, authentication, accounting, and management of shared secrets. The RADIUS tab provides an area for setting the options to:
•
•
•
The RADIUS tab also provides a display area for RADIUS servers, in order of authentication preference. This area displays the IP Address, Shared Secret, Authentication Port, and Accounting Port for each RADIUS server.
In the RADIUS tab you can create a RADIUS server by clicking the Create button. The RADIUS tab also provides the following additional actions, which can be performed upon selected server(s).
•
•
•
•
For information on using and configuring RADIUS features in Release 6.0.x consult the user documentation.
IP and OSI on DCC
As of Release 6.0, IP and OSI can coexist on DCC on a Cisco ONS network, addressing legacy OSI via NSIF Mediation, and allowing migration into IP via G.7712. IP on DCC provides security through strong encryption, SSH, SSL, and HTTPS; centralized control and strong authentication (AAA); RADIUS; communication to Layer 2 and Layer 3 devices (IP + Optical); and pseudo wire, in support of the interworking function between IP and OSI. The ability to address IP/OSI issues gives you flexibility for the future, while working within existing DCN/DCC/OSS infrastructure.
Release 6.0.x uses PPP, a Layer 2 encapsulation protocol, with high-level data link control (HDLC) datagram encapsulation to transport IP and OSI data, and link control protocol (LCP) to establish, configure, and test the point-to-point connections. CTC automatically enables IP over PPP whenever you create an SDCC or LDCC. The SDCC or LDCC can also be provisioned to support OSI over PPP. Link access protocol on the D channel (LAP-D), a data link protocol used in the OSI protocol stack, provides provisionable parameters when you elect to provision an ONS SDCC as OSI only.
Release 6.0.x TCP/IP and OSI networking employs the following additional features, described in detail in the user documentation.
OSI Connectionless Network Service
OSI connectionless network service is implemented by using the Connectionless Network Protocol (CLNP) and Connectionless Network Service (CLNS). CLNP and CLNS are described in the ISO 8473 standard.
OSI Routing
OSI routing uses a set of routing protocols that allow end system and intermediate system information collection and distribution; a routing information base; and a routing algorithm (shortest path first).
TARP
TID Address Resolution Protocol (TARP) is used when TL1 target identifiers (TIDs) must be translated to network service access point (NSAP) addresses.
TCP/IP and OSI Mediation
Two mediation processes, T-TD and FT-TD, facilitate TL1 networking and file transfers between NEs and ONS client computers running TCP/IP and OSI protocol suites.
OSI Virtual Routers
Release 6.0.x supports three OSI virtual routers, provisionable on the Provisioning > OSI > Routers tab.
IP-over-CLNS Tunnels
IP-over-CLNS tunnels are used to encapsulate IP for transport across OSI NEs. Release 6.0.x supports two tunnel types, Generic Routing Encapsulation (GRE) and Cisco IP.
OSI Provisioning in CTC
The following OSI features are provisionable in the CTC node view, Provisioning tab. For full explanations of CTC provisioning for OSI, consult the user documentation.
•
•
•
•
•
FLT Secondary State
Release 6.0.x introduces a new secondary service state (SST), Fault (FLT). The FLT secondary state is defined as follows:
•
The FLT SST is an extension to the existing ONS state model. As such, the FLT state is a Telcordia GR-1093 secondary state. It identifies that the affected entity is OOS because it is faulty. The FLT secondary state affects the service state only. The AdminState (the state you manage the entity into) is not affected. The FLT SST is the result of autonomous action; you cannot manage an entity into the FLT SST. The FLT SST is for retrieval purposes only. An entity's service state will transition into the OOS-AU or OOS-AUMA (AU for autonomous) service state if alarms or conditions are present. The FLT SST is appended to the existing secondary state for the entity when an alarm or condition exists.
Equipment FLT Service State
Some Equipment alarms will not generate an FLT SST transition. If a state already exists to represent the equipment condition, FLT will not be added to the secondary state list:
•
•
•
FLT SST with Ports
In pre-6.0 releases, an IS-NR port with an LOS alarm remains as IS-NR service state. There is no service state change to reflect the port is down. A new PST-PSTQ service state is introduced in Release 6.0.x to reflect a port in MT state that is alarmed, OOS-AUMA (Autonomous, Management).
Any port alarm that results in the AINS countdown being inhibited will result in an FLT SST transition for the port. Loopback alarms will not result in an FLT SST transition, as there is a LPBK state to represent this information. There is NO FLT SST in the DSBLD state, as all alarms are cleared in the DSBLD state.
Connection FLT Service State
FLT SST connection changes are the same as for port changes. As with the port, the connection with an alarm in pre-6.0 releases has a service state of IS-NR. A new PST-PSTQ pair is introduced in Release 6.0.x to reflect a cross connect in maintenance with an alarm, OOS-AUMA (Autonomous, Management). Any connection alarm that results in the AINS countdown being inhibited will result in the FLT SST transition for the connection. There is no FLT SST in the DSBLD state, as all alarms are cleared in the DSBLD state.
CTC Launcher
Release 6.0.x introduces the CTC Launcher utility, CtcLauncher.jar. The CTC Launcher utility can be used to launch CTC and manage an ONS node running Release 6.0.x or higher.
CTC Launcher provides two connection options. First, it can be used to access ONS NEs that have IP connectivity to the CTC computer (supported for the ONS 15600). Second, CTC Launcher can establish connectivity to ONS NEs that reside behind a third party, OSI-based GNE (supported for other ONS platforms). To create a connection through the OSI-based GNE, CTC Launcher creates a TL1 tunnel. This tunnel is similar to the static IP-over-CLNS tunnels that are available in CTC Release 6.0.x. (For information about IP-over-CLNS tunnels, refer to the Release 6.0 ONS product documentation.) However, unlike the static IP-over-CLNS tunnels, the TL1 tunnel does not require provisioning on the third party GNE, the DCN routers, or the ONS NEs. The tunnel connection is created using the CTC Launcher. It can then be managed using CTC.
Note
Prior to using the CTC Launcher utility, the CTC jar files must be precached, either from the installation CD, using the LDCACHE utility, or from the node, by launching CTC from a web browser. For installation instructions for the CTC Launcher utility, consult the readme file. The CtcLauncher.jar utility and the CtcLauncher-README.txt file are located in the CtcLauncher directory on the R6.0.x software CD. For additional information about CTC Launcher, refer to the CTC Launcher Application Guide. To access the application guide:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
TL1
TL1 Open GNE
TL1 supports the ability to act as a GNE or ENE to an OEM IP DCN (foreign) connected node that also uses TL1. To accomplish TL1 GNE-ENE interoperability, the DCN communication path between the GNE and ENE employs PPP and OSPF in a non-proprietary manner, while ensuring that these connections remain secure. Open GNE TL1 functionality enables you to configure DCC terminations to interoperate with a system on the far end that does not support proprietary PPP vendor extensions or OSPF types.
Open GNE Commands
The following commands support TL1 open GNE. For input and output formats and parameters, plus examples of how to use each command, consult the user documentation.
RTRV-TADRMAP
•
This command is used to instruct a Gateway NE to return the entries of the TADRMAP. One row is used for each displayed TID name.
DLT-TADRMAP
•
This command is used to instruct a Gateway NE to delete an entry in the table which maps the TIDs of the subtending NEs to their addresses. The OSs will address the subtending NEs using the TID in TL1 messages and a Gateway NE will address these NEs using IP Addresses or NSAPs. This table, which resides in a Gateway NE, correlates a TID and an address.
ENT-TADRMAP
•
This command is used to instruct a Gateway NE to create an entry in the table which maps the TIDs of the subtending NEs to their addresses. The OSs will address the subtending NEs using the TID in TL1 messages and a Gateway NE will address these NEs using IP Addresses or NSAPs. This table, which resides in a Gateway NE, correlates a TID and an address. This command requires that at least one of (IPADDR or NSAP) be specified.
ENT-TUNNEL-PROXY
•
This command is used to create a proxy tunnel.
DLT-TUNNEL-PROXY
•
This command is used to delete a proxy tunnel.
RTRV-TUNNEL-PROXY
•
This command is used to a view the proxy tunnels contained in the NE proxy table.
ENT-TUNNEL-FIREWALL
•
This command is used to create a firewall tunnel.
DLT-TUNNEL-FIREWALL
•
This command is used to a delete a firewall tunnel.
RTRV-TUNNEL-FIREWALL
•
This command is used to a view the firewall tunnels contained in the NE proxy table.
Changed Commands for Open GNE
The following previously-existing TL1 commands support new parameters for open GNE.
ED-<OCN_TYPE>
•
•
RTRV-<OCN_TYPE>
•
•
The following command has been modified to support open GNE as described.
REPT^DBCHG
Generate an update after an addition to or deletion from the TADRMAP or an addition or deletion of a firewall or proxy tunnel. The ENT-TADRMAP, DLT-TADRMAP, ENT-TUNNEL-PROXY, DLT-TUNNEL-PROXY, ENT-TUNNEL-FIREWALL, and DLT-TUNNEL-FIREWALL commands each generate an appropriate REPT^DBCHG message.
TL1 Command Changes
New Commands
The following new TL1 commands are added for Release 6.0.x.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Command Syntax Changes
The syntax of the following commands is changed in Release 6.0.x.
Note
COPY-IOSCFG syntax:
COPY-IOSCFG[:<TID>]:<aid>:<CTAG>::SRC=<src>,DEST=<dest>;
Is changed to:
COPY-IOSCFG[:<TID>]:<aid>:<CTAG>::SRC=<src>,DEST=<dest>[,FTTD=<fttd>];
COPY-RFILE syntax:
COPY-RFILE[:<TID>]:<src>:<CTAG>::TYPE=<xfertype>,[SRC=<srcurl>,][DEST=<desturl>,][OVWRT=<ovwrt>,][FTTD=<fttd>];
Is changed to:
COPY-RFILE[:<TID>][:<src>]:<CTAG>::TYPE=<xfertype>,[SRC=<srcurl>,][DEST=<desturl>,][OVWRT=<ovwrt>,][FTTD=<fttd>];
DLT-ROUTE syntax:
DLT-ROUTE[:<TID>]::<CTAG>::<DESTIP>,<IPMASK>;
Is changed to:
DLT-ROUTE[:<TID>]::<CTAG>::<DESTIP>;
ED-10GIGE syntax:
ED-10GIGE[:<TID>]:<aid>:<CTAG>[:::NAME=<portname>,][MACADDR=<macaddr>,][MFS=<mfs>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]];
Is changed to:
ED-10GIGE[:<TID>]:<aid>:<CTAG>[:::NAME=<portname>,][MACADDR=<macaddr>,][MFS=<mfs>,][CMDMDE=<cmdmde>,][FREQ=<freq>,][LOSSB=<lossb>][:<pst>[,<sst>]];
ED-BITS syntax:
ED-BITS[:<TID>]:<aid>:<CTAG>[:::LINECDE=<linecde>,][FMT=<fmt>,][SABIT=<sabit>,][IMPEDANCE=<impedance>,][LBO=<lbo>,][SYNCMSG=<syncmsg>,][AISTHRSHLD=<aisthrshld>,][BITSFAC=<bitsfac>,][ADMSSM=<admssm>][:<pst>];
Is changed to:
ED-BITS[:<TID>]:<aid>:<CTAG>[:::LINECDE=<linecde>,][FMT=<fmt>,][SABIT=<sabit>,][LBO=<lbo>,][SYNCMSG=<syncmsg>,][AISTHRSHLD=<aisthrshld>,][BITSFAC=<bitsfac>,][ADMSSM=<admssm>][:<pst>];
ED-CRS-STS-PATH syntax:
ED-CRS-STS-PATH:<src>,<dst>:<CTAG>[:::ADD=<add>,][REMOVE=<remove>,][CKTID=<cktid>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]]
Is changed to:
ED-CRS-STS-PATH:<src>,<dst>:<CTAG>[::<cct>][:ADD=<add>,][REMOVE=<remove>,][CKTID=<cktid>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]]
ED-E1 syntax:
ED-E1[:<TID>]:<aid>:<CTAG>[:::LINECDE=<linecde>,][FMT=<fmt>,][TACC=<tacc>,][TAPTYPE=<taptype>,][SFBER=<sfber>,][SDBER=<sdber>,][SOAK=<soak>,][NAME=<name>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]];
Is changed to:
ED-E1[:<TID>]:<aid>:<CTAG>[:::LINECDE=<linecde>,][FMT=<fmt>,][TACC=<tacc>,][TAPTYPE=<taptype>,][SFBER=<sfber>,][SDBER=<sdber>,][SOAK=<soak>,][NAME=<name>,][CMDMDE=<cmdmde>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][ADMSSM=<admssm>,][SABIT=<sabit>][:<pst>[,<sst>]];
ED-EC1 syntax:
ED-EC1[:<TID>]:<aid>:<CTAG>[:::PJMON=<pjmon>,][LBO=<lbo>,][SOAK=<soak>,][SFBER=<sfber>,][SDBER=<sdber>,][NAME=<name>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]];
Is changed to:
ED-EC1[:<TID>]:<aid>:<CTAG>[:::PJMON=<pjmon>,][LBO=<lbo>,][SOAK=<soak>,][SFBER=<sfber>,][SDBER=<sdber>,][NAME=<name>,][AISONLPBK=<aisonlpbk>,][CMDMDE=<cmdmde>,][EXPTRC=<exptrc>,][TRC=<trc>,][TRCMODE=<trcmode>,][TRCFORMAT=<trcformat>][:<pst>[,<sst>]];
ED-FFP-MOD2 syntax:
ED-FFP-MOD2:<aid>:<CTAG>[:::PROTID=<protid>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][PSDIRN=<psdirn>][:]
Is changed to:
ED-FFP-MOD2:<aid>:<CTAG>[:::PROTID=<protid>,][RVRTV=<rvrtv>],
ED-G1000 syntax:
ED-G1000[:<TID>]:<aid>:<CTAG>[:::MFS=<mfs>,][FLOW=<flow>,][LOWMRK=<int>,][HIWMRK=<int>,][NAME=<name>,][CMDMDE=<cmdmde>,][SOAK=<soak>][:<pst>[,<sst>]];
Is changed to:
ED-G1000[:<TID>]:<aid>:<CTAG>[:::MFS=<mfs>,][FLOW=<flow>,][LOWMRK=<int>,][HIWMRK=<int>,][AUTONEG=<autoneg>,][NAME=<name>,][CMDMDE=<cmdmde>,][SOAK=<soak>][:<pst>[,<sst>]];
ED-GIGE syntax:
ED-GIGE[:<TID>]:<aid>:<CTAG>[:::ADMINSTATE=<adminstate>,][LINKSTATE=<linkstate>,][MTU=<mtu>,][FLOWCTRL=<flowctrl>,][OPTICS=<optics>,][DUPLEX=<duplex>,][SPEED=<speed>,][NAME=<name>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]];
Is changed to:
ED-GIGE[:<TID>]:<aid>:<CTAG>[:::ADMINSTATE=<adminstate>,][LINKSTATE=<linkstate>,][FLOWCTRL=<flowctrl>,][OPTICS=<optics>,][DUPLEX=<duplex>,][SPEED=<speed>,][NAME=<name>,][CMDMDE=<cmdmde>,][FREQ=<freq>,][LOSSB=<lossb>][:<pst>[,<sst>]];
ED-NE-GEN syntax:
ED-NE-GEN[:<TID>]::<CTAG>[:::NAME=<name>,][IPADDR=<ipaddr>,][IPMASK=<ipmask>,][DEFRTR=<defrtr>,][IIOPPORT=<iiopport>,][NTP=<ntp>];
Is changed to:
ED-NE-GEN[:<TID>]::<CTAG>[:::NAME=<name>,][IPADDR=<ipaddr>,][IPMASK=<ipmask>,][DEFRTR=<defrtr>,][IIOPPORT=<iiopport>,][NTP=<ntp>,][SUPPRESSIP=<mode>];
ED-POS syntax:
ED-POS[:<TID>]:<src>:<CTAG>[:::ENCAP=<encap>,][NAME=<name>,][CMDMDE=<cmdmde>,][SOAK=<soak>][:<pst>[,<sst>]];
Is changed to:
ED-POS[:<TID>]:<aid>:<CTAG>;
ED-T1 syntax:
ED-T1[:<TID>]:<aid>:<CTAG>[:::LINECDE=<linecde>,][FMT=<fmt>,][LBO=<lbo>,][TACC=<tacc>,][TAPTYPE=<taptype>,][SOAK=<soak>,][SFBER=<sfber>,][SDBER=<sdber>,][NAME=<name>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]];
Is changed to:
ED-T1[:<TID>]:<aid>:<CTAG>[:::LINECDE=<linecde>,][FMT=<fmt>,][LBO=<lbo>,][TACC=<tacc>,][TAPTYPE=<taptype>,][SOAK=<soak>,][SFBER=<sfber>,][SDBER=<sdber>,][SYNCMSG=<syncmsg>,][SENDDUS=<senddus>,][NAME=<name>,][CMDMDE=<cmdmde>,][AISONLPBK=<aisonlpbk>,][MODE=<mode>,][SYNCMAP=<syncmap>,][ADMSSM=<admssm>,][VTMAP=<vtmap>,][AISVONAIS=<aisvonais>,][AISONLOF=<aisonlof>,][INHFELPBK=<inhfelpbk>][:<pst>[,<sst>]];
ED-T3 syntax:
ED-T3[:<TID>]:<aid>:<CTAG>[:::FMT=<fmt>,][LINECDE=<linecde>,][LBO=<lbo>,][INHFELPBK=<inhfelpbk>,][TACC=<tacc>,][TAPTYPE=<taptype>,][SOAK=<soak>,][SFBER=<sfber>,][SDBER=<sdber>,][NAME=<name>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]];
Is changed to:
ED-T3[:<TID>]:<aid>:<CTAG>[:::FMT=<fmt>,][LINECDE=<linecde>,][LBO=<lbo>,][INHFELPBK=<inhfelpbk>,][TACC=<tacc>,][TAPTYPE=<taptype>,][SOAK=<soak>,][SFBER=<sfber>,][SDBER=<sdber>,][NAME=<name>,][AISONLPBK=<aisonlpbk>,][CMDMDE=<cmdmde>][:<pst>[,<sst>]];
ED-VC3 syntax:
ED-VC3[:<TID>]:<src>:<CTAG>[:::RVRTV=<rvrtv>,][RVTM=<rvtm>,][HOLDOFFTIMER=<holdofftimer>,][TACC=<tacc>,][TAPTYPE=<taptype>,][CMDMDE=<cmdmde>,][EXPTRC=<exptrc>,][TRC=<trc>,][TRCMODE=<trcmode>][:<pst>[,<sst>]];
Is changed to:
ED-VC3[:<TID>]:<src>:<CTAG>[:::RVRTV=<rvrtv>,][RVTM=<rvtm>,][HOLDOFFTIMER=<holdofftimer>,][TACC=<tacc>,][TAPTYPE=<taptype>,][CMDMDE=<cmdmde>,][EXPTRC=<exptrc>,][TRC=<trc>,][TRCMODE=<trcmode>,][TRCFORMAT=<trcformat>][:<pst>[,<sst>]];
ED-VT1 syntax:
ED-VT1[:<TID>]:<aid>:<CTAG>[:::RVRTV=<rvrtv>,][RVTM=<rvtm>,][HOLDOFFTIMER=<holdofftimer>,][TACC=<tacc>,][TAPTYPE=<taptype>,][CMDMDE=<cmdmde>,][EXPTRC=<exptrc>,][TRC=<trc>,][TRCMODE=<trcmode>][:<pst>[,<sst>]];
Is changed to:
ED-VT1[:<TID>]:<aid>:<CTAG>[:::SFBER=<sfber>,][SDBER=<sdber>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][HOLDOFFTIMER=<holdofftimer>,][TACC=<tacc>,][TAPTYPE=<taptype>,][CMDMDE=<cmdmde>,][EXPTRC=<exptrc>,][TRC=<trc>,][TRCMODE=<trcmode>,][TRCFORMAT=<trcformat>][:<pst>[,<sst>]];
ED-VT2 syntax:
ED-VT2[:<TID>]:<src>:<CTAG>[:::RVRTV=<rvrtv>,][RVTM=<rvtm>,][HOLDOFFTIMER=<holdofftimer>,][TACC=<tacc>,][TAPTYPE=<taptype>,][CMDMDE=<cmdmde>,][EXPTRC=<exptrc>,][TRC=<trc>,][TRCMODE=<trcmode>,][:<pst>[,<sst>]];
Is changed to:
ED-VT2[:<TID>]:<src>:<CTAG>[:::SFBER=<sfber>,][SDBER=<sdber>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][HOLDOFFTIMER=<holdofftimer>,][TACC=<tacc>,][TAPTYPE=<taptype>,][CMDMDE=<cmdmde>,][EXPTRC=<exptrc>,][TRC=<trc>,][TRCMODE=<trcmode>,][TRCFORMAT=<trcformat>][:<pst>[,<sst>]];
ENT-EQPT syntax:
ENT-EQPT[:<TID>]:<aid>:<CTAG>::<aidtype>[:PROTID=<protid>,][PRTYPE=<prtype>,][RVRTV=<rvrtv>,][RVTM=<rvtm>,][CARDMODE=<cardmode>,][PEERID=<protid>,][REGENNAME=<regenname>,][PWL=<pwl>,][CMDMDE=<cmdmde>][:];
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>,][RETIME=<retime>][:];
ENT-ROLL syntax:
ENT-ROLL-<MOD_PATH>:[<TID>]:<src>,<dst>:<CTAG>:::RFROM=<rfrom>,RTO=<rto>,RMODE=<rmode>,[FORCE=<force>];
Is changed to:
ENT-ROLL-<MOD_PATH>:[<TID>]:<from>,<to>:<CTAG>:::RFROM=<rfrom>,RTO=<rto>,RMODE=<rmode>,[CMDMDE=<cmdmde>];
SET-ATTR-SECUDFLT syntax:
SET-ATTR-SECUDFLT[:<TID>]::<CTAG>[::PAGE=<page>,][PCND=<pcnd>,][MXINV=<mxinv>,][DURAL=<dural>,][TMOUT=<tmout>,][UOUT=<uout>,][PFRCD=<pfrcd>,][POLD=<pold>,][PINT=<pint>,][LOGIN=<login>,][PRIVLVL=<uap>];
Is changed to:
SET-ATTR-SECUDFLT[:<TID>]::<CTAG>[::PAGE=<page>,][PCND=<pcnd>,][MXINV=<mxinv>,][DURAL=<dural>,][TMOUT=<tmout>,][UOUT=<uout>,][PFRCD=<pfrcd>,][POLD=<pold>,][PINT=<pint>,][LOGIN=<login>,][PRIVLVL=<uap>,][PDIF=<pdif>];
Miscellaneous syntax changes:
Syntax:
[:<TID>]:<aid>:<CTAG>;
Is changed to:
[:<TID>]::<CTAG>;
Response:
<aid>:<sc>,[<switchtype>]
Is changed to:
[<vendor>],[<netype>]
Command Response Changes
The following TL1 responses have changed in Release 6.0.x.
Note
RTRV-10GIGE response:
<aid>:,,[<role>],[<status>]:[<portname>],[<macaddr>],[<lbcl>],[<opt>],[<opr>],[<mfs>]:<pst>,[<sst>]
Is changed to:
<aid>:,,[<role>],[<status>]:[<portname>],[<macaddr>],[<lbcl>],[<opt>],[<opr>],[<mfs>],[<freq>],[<lossb>]:<pst>,[<sst>]
RTRV-DS3I response:
<aid>::<fmt>,<linecde>,<lbo>,[<tacc>],[<taptype>],[<sfber>],[<sdber>],[<soak>],[<name>]:<pst>,[<sst>]
Is changed to:
<aid>::<fmt>,<linecde>,<lbo>,[<tacc>],[<taptype>],[<sfber>],[<sdber>],[<soak>],[<soakleft>],[<name>],[<inhfelpbk>]:<pst>,[<sst>]
RTRV-E1 response:
<aid>::<linecde>,<fmt>,[<tacc>],[<taptype>],[<sfber>],[<sdber>],[<soak>],[<name>]:[<pst>],[<sst>]
Is changed to:
<aid>::<linecde>,<fmt>,[<tacc>],[<taptype>],[<sfber>],[<sdber>],[<soak>],[<soakleft>],[<name>],[<syncmsg>],[<senddus>],[<retime>],[<admssm>],[<providesync>],[<aisonlpbk>],[<saBit>]:[<pst>],[<sst>]
RTRV-E3 response:
<aid>::[<tacc>],[<taptype>],[<sfber>],[<sdber>],[<soak>],[<name>]:<pst>,[<sst>]
Is changed to:
<aid>::[<tacc>],[<taptype>],[<sfber>],[<sdber>],[<soak>],[<soakleft>],[<name>]:<pst>,[<sst>]
RTRV-E4 response:
<aid>::[<payload>],[<sfber>],[<sdber>],[<soak>],[<name>]:<pst>,[<sst>]
Is changed to:
<aid>::[<payload>],[<sfber>],[<sdber>],[<soak>],[<soakleft>],[<name>]:<pst>,[<sst>]
RTRV-EC1 response:
<aid>::[<pjmon>],[<lbo>],[<rxequal>],[<soak>],[<soakleft>],[<sfber>],[<sdber>],[<name>],[<aisonlpbk>]:<pst>,[<sst>]
Is changed to:
<aid>::[<pjmon>],[<lbo>],[<rxequal>],[<soak>],[<soakleft>],[<sfber>],[<sdber>],[<name>],[<aisonlpbk>],[<exptrc>],[<trc>],[<inctrc>],[<trcmode>],[<trcformat>]:<pst>,[<sst>]
RTRV-EQPT response:
<aid>:<aidtype>,<equip>,[<role>],[<status>]:[<protid>],[<prtype>],[<rvrtv>],[<rvtm>],[<cardname>],[<ioscfg>],[<cardmode>],[<peerid>],[<regenname>],[<pwl>]:<pst>,[<sst>]
Is changed to:
<aid>:<aidtype>,<equip>,[<role>],[<status>]:[<protid>],[<prtype>],[<rvrtv>],[<rvtm>],[<cardname>],[<ioscfg>],[<cardmode>],[<peerid>],[<regenname>],[<pwl>],[<transmode>],[<retime>]:<pst>,[<sst>]
RTRV-FSTE response:
<aid>::[<adminstate>],[<linkstate>],[<mtu>],[<flowctrl>],[<duplex>],[<speed>],[<flow>],[<expduplex>],[<expspeed>],[<vlancosthreshold>],[<iptosthreshold>],[<name>],[<soak>],[<soakleft>]:<pst>,[<sst>]
Is changed to:
<aid>::[<adminstate>],[<linkstate>],[<mtu>],[<flowctrl>],[<optics>],[<duplex>],[<speed>],[<flow>],[<expduplex>],[<expspeed>],[<vlancosthreshold>],[<iptosthreshold>],[<name>],[<soak>],[<soakleft>]:<pst>,[<sst>]
RTRV-GIGE response:
<aid>::[<adminstate>],[<linkstate>],[<mtu>],[<flowctrl>],[<optics>],[<duplex>],[<speed>],[<name>]:<pst>,[<sst>]
Is changed to:
<aid>:,,[<role>],[<status>]:[<adminstate>],[<linkstate>],[<mtu>],[<flowctrl>],[<optics>],[<duplex>],[<speed>],[<name>],[<freq>],[<lossb>]:<pst>,[<sst>]
RTRV-INV response:
<aid>,<aidtype>::[<plugtype>],[<pn>],[<hwrev>],[<fwrev>],[<sn>],[<clei>],[<twl1=nwl in code>],[<twl2= wl1 in code>],[<twl3=wl2 in code>],[<twl4=wl3 in code>],[<pluginvendorid>],[<pluginpn>],[<pluginhwrev>],[<pluginfwrev>],[<pluginsn>],[<ilossref>],[<productId>],[<versionId>],[<fpgaVersion>]
Is changed to:
<aid>,<aidtype>::[<pn>],[<hwrev>],[<fwrev>],[<sn>],[<clei>],[<twl1=nwl in code>],[<pluginvendorid>],[<pluginpn>],[<pluginhwrev>],[<pluginfwrev>],[<pluginsn>],[<ilossref>],[<productId>],[<versionId>],[<fpgaVersion>]
RTRV-STM1E response:
<aid>::[<payload>],[<syncmsg>],[<senddus>],[<sfber>],[<sdber>],[<soak>],[<name>]:<pst>,[<sst>]
Is changed to:
<aid>::[<payload>],[<syncmsg>],[<senddus>],[<sfber>],[<sdber>],[<soak>],[<soakleft>],[<name>]:<pst>,[<sst>]
RTRV-T1 response:
<aid>::[<linecde>],[<fmt>],[<lbo>],[<tacc>],[<taptype>],[<soak>],[<soakleft>],[<sfber>],[<sdber>],[<name>],[<syncmsg>],[<senddus>],[<retime>],[<aisonlpbk>]:<pst>,[<sst>]
Is changed to:
<aid>::[<linecde>],[<fmt>],[<lbo>],[<tacc>],[<taptype>],[<soak>],[<soakleft>],[<sfber>],[<sdber>],[<name>],[<syncmsg>],[<senddus>],[<retime>],[<aisonlpbk>],[<aisvonais>],[<aisonlof>],[<mode>],[<syncmap>],[<admssm>],[<providesync>],[<vtmap>],[<inhfelpbk>]:<pst>,[<sst>]
RTRV-VT2 response:
<aid>::[<sfber>],[<sdber>],[<rvrtv>],[<rvtm>],[<holdofftimer>],[<exptrc>],[<trc>],[<inctrc>],[<trcmode>],[<tacc>],[<taptype>],[<upsrpthstate>]:<pst>,[<sst>]
Is changed to:
<aid>::[<sfber>],[<sdber>],[<rvrtv>],[<rvtm>],[<holdofftimer>],[<exptrc>],[<trc>],[<inctrc>],[<trcmode>],[<trcformat>],[<tacc>],[<taptype>],[<upsrpthstate>]:<pst>,[<sst>]
SET-TOD response:
<year>,<month>,<day>,<hour>,<minute>,<second>,<tmtype>
Is changed to:
<year>,<month>,<day>,<hour>,<minute>,<second>,<difference>:<tmtype>
TL1 ENUM Changes
Note
TL1 ENUM Types Changed
The following enum types have been merged into the EQUIPMENT_TYPE enum type.
•
•
•
TL1 ENUM Items Added or Removed
The following section, including Table 1 through Table 29, highlights ENUM items changed (added or removed) for Release 6.0.x, by ENUM type.
Table 1 ADDRTYPE enum items added to Release 6.0.x
ADDRTYPE_ENUM_IP
"IP"
ADDRTYPE_ENUM_IPANDNSAP
"IP-AND-NSAP"
ADDRTYPE_ENUM_NSAP
"NSAP"
ADDRTYPE is used in the following commands:
•
Table 2 CARDMODE enum items added to Release 6.0.x
CARDMODE_DS1E1_DS1ONLY
"DS1E1-DS1ONLY"
CARDMODE_DS1E1_E1ONLY
"DS1E1-E1ONLY"
CARDMODE is used in the following commands:
•
•
•
Table 3 DL_TYPE enum items added to Release 6.0.x
DL_TYPE_ACCEPT
"ACPT"
DL_TYPE_CANC
"CANC"
DL_TYPE is used in the following commands:
•
Table 4 ENCODING enum items added to Release 6.0.x
ENCODING_ENUM_LV
"LV"
ENCODING_ENUM_RAWCISCO
"RAW-CISCO"
ENCODING_ENUM_RAWSTD
"RAW-STD"
ENCODING is used in the following commands:
•
ENV_ALM is used in the following commands:
•
•
•
•
EQUIPMENT_TYPE is used in the following commands:
•
•
EQPT_TYPE is used in the following command response:
•
Table 8 FC_LINKRATE enum items dropped from Release 5.0.x
FC_LINKRATE_1GFC
"1GFC"
FC_LINKRATE_2GFC
"2GFC"
FC_LINKRATE is used in the following commands:
•
Table 9 FC_LINKRATE enum items added to Release 6.0.x
FC_LINKRATE_1GBPS
"1GBPS"
FC_LINKRATE_2GBPS
"2GBPS"
FC_LINKRATE is used in the following commands:
•
Table 10 FRAME_FORMAT enum items added to Release 6.0.x
FRAME_FORMAT_LT_JESF
"JESF"
FRAME_FORMAT is used in the following commands:
•
•
•
•
•
•
•
•
Table 11 LO_XC_MODE enum items added to Release 6.0.x
LO_XC_MODE_MIXED
"MIXED"
LO_XC_MODE_VC11
"VC11"
LO_XC_MODE_VC12
"VC12"
LO_XC_MODE_VT1
"VT1"
LO_XC_MODE_VT2
"VT2"
LO_XC_MODE is used in the following commands:
•
•
Table 12 LPBK_TYPE enum items dropped from Release 5.0.x
LPBK_TYPE_FE_CMD_ESF_PAYLD_LPBK
"PAYLOAD"
FC_LINKRATE is used in the following commands:
•
Table 13 LPBK_TYPE enum items added to Release 6.0.x
LPBK_TYPE_FE_CMD_ESF_PAYLD_LPBK
"FE-CMD-ESF-PAYLOAD"
LPBK_TYPE_PAYLOAD_LPBK
"PAYLOAD"
LPBK_TYPE is used in the following commands:
•
•
MOD2 is used in the following commands:
•
•
•
•
•
•
MOD2ALM is used in the following commands:
•
•
Table 16 MOD2B enum items added to Release 6.0.x
MOD2B_M2_TSC
"TSC"
MOD2B_M2_VC11
"VC11"
MOD2B is used in the following commands:
•
•
•
•
•
•
•
•
•
•
•
•
MOD_PATH is used in the following commands:
•
•
•
•
•
OPTICAL_WLEN is used in the following commands:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Table 19 OPTICS enum items added to Release 6.0.x
OPTICS_OP_100_BASE_FX
"100_BASE_FX"
OPTICS_OP_100_BASE_LX
"100_BASE_LX"
OPTICS is used in the following commands:
•
•
•
•
Table 20 PROTOCOLAID enum items added to Release 6.0.x
PROTOCOLAID_EMS
"EMS"
PROTOCOLAID_SHELL
"SHELL"
PROTOCOLAID_SNMP
"SNMP"
PROTOCOLAID_TL1
"TL1"
PROTOCOLAID is used in the following commands:
•
Table 21 PROTOCOLSTAT enum items added to Release 6.0.x
PROTOCOLSTAT_DISABLED
"DISABLED"
PROTOCOLSTAT_SECURE
"SECURE"
PROTOCOLSTAT_UNSECURE
"UNSECURE"
PROTOCOLSTAT is used in the following commands:
•
REACH is used in the following commands:
•
•
•
•
•
•
•
•
•
•
REQTYPE is used in the following commands:
•
RFILE is used in the following commands:
•
•
Table 25 SYNCMAP enum items added to Release 6.0.x
SYNCMAP_ASYNC
"ASYNC"
SYNCMAP_BYTE
"BYTE"
SYNCMAP is used in the following commands:
•
•
Table 26 SYNC_CLOCK_REF_QUALITY_LEVEL enum items dropped from Release 5.0.x
SYNC_CLOCK_REF_QUALITY_LEVEL_QREF_RES_SDH
"RES-SDH"
SYNC_CLOCK_REF_QUALITY_LEVEL is used in the following commands:
•
•
•
•
•
•
•
•
•
TIDADRMODE is used in the following commands:
•
Table 28 TRANSMODE enum items added to Release 6.0.x
TRANSMODE_AU3
"AU3"
TRANSMODE_AU4
"AU4"
TRANSMODE_SONET
"SONET"
TRANSMODE is used in the following commands:
•
•
•
Table 29 VTMAP enum items added to Release 6.0.x
VTMAP_GR253
"GR253"
VTMAP_INDUSTRY
"INDUSTRY"
VTMAP 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 Optical Networking Information
This section contains information that is specific to optical networking products. For information that pertains to all of Cisco, refer to the Obtaining Documentation and Submitting a Service Request section.
Where to Find Safety and Warning Information
For safety and warning information, refer to the Cisco Optical Transport Products Safety and Compliance Information document that accompanied the product. This publication describes the international agency compliance and safety information for the Cisco ONS 15454 system. It also includes translations of the safety warnings that appear in the ONS 15454 system documentation.
Cisco Optical Networking Product Documentation CD-ROM
Optical networking-related documentation, including Cisco ONS 15xxx product documentation, is available in a CD-ROM package that ships with your product. The Optical Networking Product Documentation CD-ROM is updated periodically and may be more current than printed documentation.
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2007-2008 Cisco Systems, Inc. All rights reserved.
