Alcatel-Lucent 1665 DMX supports a three tiered operations philosophy consisting of the system controller functions and visual indicators, local interface to the shelf via serial ports and LAN ports and remote OS interface over a Data Communications Channel. The following features highlight a few of the key operations features that provide effective operation and maintenance of the system.
WaveStar® CIT manages the Alcatel-Lucent 1665 DMX system through the TL1/CIT port, providing TL1 messaging, software download, and full operations and provisioning capability via a Graphic User Interface (GUI) or TL1 cut-through. WaveStar® CIT can run a full-featured GUI or TL1 scripts. Using the GUI, a crafts person can access all Alcatel-Lucent 1665 DMX software functions and context-sensitive help. The TL1 cut-through, also known as the TL1 Translation Device (T-TD), is a flexible TL1 interface that supports full TL1 management through TCP/IP or RS-232 interfaces.
WaveStar® CIT is not used to download release software to the system (the PC is used, but not the CIT software). Release software can be copied to other NEs remotely, provided the initial download of Alcatel-Lucent 1665 DMX release software has occurred on each system.
The TL1 cut-through interface provides full TL1 management via the Serial and IAO LAN interfaces.
TL1 message exchange is supported over TCP/IP via IAO LAN, OSI LAN, and WaveStar® CIT interfaces. IAO LAN supports TCP/IP protocol and OSI protocol. These provide a communication link from an Alcatel-Lucent 1665 DMX to a local node that may serve as a gateway to the network.
Beginning in Release 9.1, TL1 command entry in TL1 cut-through mode is simplified. The last TID entered is remembered and used in all subsequent commands in which a TID is not specified until a different TID is entered.
Alcatel-Lucent 1665 DMX supports two types of IP Access. In one case, Alcatel-Lucent 1665 DMXcan serve as a TL1 Translation Device (T-TD) by being a gateway network element that allows a OMS and/or WaveStar® CIT to communicate to other network elements (NEs) on an OSI network through an IP access network. In the second instance, the Alcatel-Lucent 1665 DMX can functionally encapsulate IP packets within OSI packets to be transmitted through the OSI network to the proper NE. This capability is called IP tunneling.
Alcatel-Lucent 1665 DMX can copy the application information within an IP packet into an OSI packet. Thus, all IP protocol information is lost. This translation is performed at the application layer. Separate gateways can be provided by a single Alcatel-Lucent 1665 DMX.
IP tunneling allows for file transfer through an IP access network. IP tunneling is used to perform end-to-end FTP through the OSI portion of the IP access network. In this instance the Alcatel-Lucent 1665 DMX serves as a gateway network element (GNE) that encapsulates an IP packet within an OSI packet. When the final destination of the file is reached, the IP packet is removed from within the OSI packet and processed by the TCP/IP stack. Thus, IP tunneling allows an OMS and/or CIT to reach NEs in an OSI based DCN network with FTP over IP. In this case, the end points of the IP tunnel are the actual terminating points for the IP traffic.
In normal ARP usage for an Ethernet LAN, the sending system broadcasts an ARP request on the physical LAN. The ARP request contains the target IP address and asks the system with this IP address to respond with its physical Ethernet address. All systems on the LAN receive the request, but only the system which recognizes the target IP address as its own will send a point-to-point ARP reply to the sending system. The broadcast ARP request on a physical LAN only reaches systems which are attached to this physical LAN. If the sending system and the target system are on different physical networks, the target system will not receive the ARP request and thus can not respond to it. Proxy ARP lets a system, called ARP subnet gateway, answer ARP requests received from one of its physical (LAN) networks for a target system which is not attached to this physical network.
To allow SNMP manager/NTP server located in the IP-based access Data Communication Network (DCN) to communicate with NEs located in the OSI-based DCN, Alcatel-Lucent 1665 DMX supports IP tunneling solution to encapsulate and route IP packets over OSI-based embedded DCN. The provisioning of static routes on the external router(s) is required to route the IP packets from the access DCN to the embedded DCN. The Proxy ARP support on the Gateway Network Element (GNE) will eliminate this need of static routes on the external router(s).
The ARP Subnet Gateway implementation adheres to RFC1027 which states that, if the IP networks of the source and target hosts of an ARP request are different, an ARP subnet gateway implementation should not reply to the request. This is to prevent the ARP subnet gateway from being used to reach foreign IP networks and possibly bypass security checks provided by IP gateways.
Because of this RFC requirement, the IP addresses of both the GNE and RNE must be in the same network with respect to network class (A, B and C). For example, if the GNE has a class C IP address 192.168.170.1, the RNE must have an IP address in the same Class C network, in the form 192.168.170.x. For proxy ARP to function properly, the Remote NE IP address must be in the same subnet as the IP address of the router, as specified by the network mask on the router. Otherwise, the router will not send the ARP request to the appropriate LAN port, and will instead route the packet through its default IP gateway into the IP cloud.
However, the IP address of the remote NE should not be in the same subnet as the IP address of the GNE, from either the GNEs network mask perspective or the RNEs network mask perspective. An easy way to achieve this on the RNE is to assign a 32-bit network mask to all RNEs.
Also referred to as FTTD (File Transfer Translation Device), the FTTD allows Alcatel-Lucent 1665 DMX to function as a Gateway Network Element (GNE) that can facilitate the download of files located at FTP servers to remote NEs connected to the Alcatel-Lucent 1665 DMX.
Beginning in 9.0, the LNW2 SYSCTL circuit pack supports SSH File Transfer Protocol (SFTP) for software download, database backup, and database restoration. SSH File Transfer Protocol (SFTP) is a new protocol defined by IETF which runs over a secure SSH channel and provides secure file transfers. Network configurations, user names, passwords, FTP commands and transferred files are protected.
Note:
You must have IP connectivity between your NE and your SFTP server, and your NE must have a defined IP address. The WaveStar® CIT is not SSH FTP (SFTP) server. You must have access to an SSH FTP server to use this feature.
This feature enables software (upgrade) to be downloaded to remote NEs from a central office site via the data communications channel (DCC).
When used as a GNE, Alcatel-Lucent 1665 DMX supports a total of 300 OSI associations (logins). Each TCP/IP (or Telnet) connection can support 300 associations. The Alcatel-Lucent 1665 DMX GNE supports up to 20 TCP/IP connections. The combined number of OSI associations on all TCP/IP sessions cannot exceed 300.
This feature provides interworking using the Open Systems Interconnection (OSI) seven-layer protocol stack over the data communications channel (DCC). The OSI seven-layer protocol stack refers to the OSI reference model, a logical structure for network operations standardized by the International Standards Organization (ISO).
Alcatel-Lucent 1665 DMX can support a total of 250 NEs per Level 1 area.
This feature partitions a subnetwork into maintenance domains (alarm groups). An Alarm Group is a set of NEs that share status information. Alarm groups can be nodes in a ring or any other logical grouping such as a maintenance or geographical group. Each Level 1 area can be identified as a separate Alarm Group, as long as it does not exceed 50 nodes. You must provision one NE in an Alarm Group as an alarm gateway NE (AGNE) to support office alarms and a summary alarm information of remote NEs in the local alarm report. More than one AGNE can be provisioned per alarm group, but this is not recommended.
Alcatel-Lucent 1665 DMX is compatible with any other-vendor NEs that support Target ID Address Resolution Protocol (TARP), OSI, IAO LAN, and TL1 as specified in Telcordia ® GR-253.
Many of the traditional SONET maintenance, provisioning, operations, control, and synchronization features are included in the Alcatel-Lucent 1665 DMX. The flexible SONET standard provides a formidable foundation for Alcatel-Lucent 1665 DMX to build upon.
Security features include 1–999 day password aging, customized login proprietary message, and 150 users.
When the network element is provisioned to use RADIUS authentication, any user TL1/CLI/Web GUI login attempt triggers the network element, if the maximum number of logins is not reached, to query the designated RADIUS server(s) and act on the response.
Performance monitoring (PM) data is reported on the VT1.5, VC12, STS-1, STS-3c, STS-12c, STS-48c, , STS-192c, DS1, E1, DS3, EC-1, Ethernet (LAN and VCG ports), SAN, OC-3, OC-12, OC-48, and OC-192 levels.
Alcatel-Lucent 1665 DMX supports adjustable ASAPs. With ASAPs, alarms are grouped into categories called "Profile Types". Each Profile Type can have multiple views (ASAPs). These views include the default view and various user created/provisioned profiles. Each ASAP within a profile type has the same alarms, but alarm severity levels are user provisionable. The user can then assign ASAPs to entities within the shelf.
ASAPs make it possible to assign different alarm severity levels for all alarms. This feature also allows the user to assign different alarm severity levels for the same probable cause to different entities within the shelf. Once alarm severity levels are set, the user can assign the same level to different entities without re-provisioning the level itself.
These capabilities give the user greater control over alarm reporting.
Improved circuit pack failure alarms are supported to identify circuit packs that contribute to the failure of another circuit pack. The existing circuit pack failure alarms are augmented by reporting the CP contributing to a pack failure alarm for all circuit packs that are contributing to the circuit pack failure. The severity level is provisionable using alarm severity assignment profiles.
Alcatel-Lucent 1665 DMX is supported by Telcordia ® OSs: TIRKS, NMA, and Transport.
Alcatel-Lucent 1665 DMX supports interoperability with many vendors' equipment.
Alcatel-Lucent 1665 DMX supports TARP interoperability with Product Family 2000 nodes such as the FT-2000 OC-48 Lightwave System, the DDM-2000 OC-3/OC-12 Multiplexer, the DDM-2000 FiberReach Multiplexer, and Alcatel-Lucent 1850 TSS-5.
Alcatel-Lucent 1665 DMX provides interoperability with all WaveStar® Product Family nodes supporting TARP over both UPSR and BLSR applications.
Alcatel-Lucent 1665 DMX also provides interoperability with WaveStar® BandWidth Manager nodes supporting TARP over both OC-48 and OC-192 BLSRs.
Alcatel-Lucent 1665 DMX supports operations via OMS and 1340INC.
Alcatel-Lucent 1665 DMX supports Simple Network Management Protocol (SNMP). It is a language protocol for communications between network elements and management systems. As such, it includes verbs (commands), nouns (objects) and a structure and rules (protocol). It has a degree of standardization that is much greater than TL1, particularly with respect to the commands and objects and it’s intended to be a very simple UDP/IP based protocol, with few commands, that is easy to implement at low cost, for monitoring and managing low cost bridges and routers.
Alcatel-Lucent 1665 DMX supports a maximum of 10 enabled SNMP Users for request functionality and a maximum of 10 enabled SNMP Users for receiving traps. However, the NE only supports 16 users total.
The three basic SNMP components are:
The protocol defines the rules and specifications for exchanging information between a manager and an agent. This includes the detailed specification of the SNMP commands, messages and the command/message PDUs (packet data units) as well as the way security is handled.
Management Information Base (MIB) is the set of managed objects on which the SNMP commands operate. These managed objects can be provisionable or status parameters or alarms and events entities.
SNMP applications use public and private Management Information Bases (MIBs) that define the equipment and Ethernet/SONET/SDH/PDH performance monitoring parameters (objects) and alarm/event messages (traps) that can be communicated. Public MIBs are specified in standards. Private MIBs are unique to . The public and private MIBs are stored on the PC that is running the SNMP application.
Structure of Management Information (SMI) is the rules for the definition of managed objects, including the object name, the Object Identifier (OID), and the object syntax, which in SNMP uses ASN.1 standard encoding.
Alcatel-Lucent 1665 DMX provides SNMP support of certain reports and traps for all Ethernet interfaces. For more information, see SNMP parameters and traps in Chapter 5, Operations, administration, maintenance, and provisioning.
Alcatel-Lucent 1665 DMX supports SNMP on DS1/E1 and DS3/EC-1 interfaces. SNMP support of these TDM interfaces includes traps and performance monitoring parameters.
Beginning in 9.0, the Alcatel-Lucent 1665 DMX circuit packs independently support SNMPv3 protocol to monitor individual circuit pack operation. SNMPv3 was developed to provide a higher level of security through the use of encryption.
SNMPv3 provides secure access by a combination of authenticating and encrypting packets over the network. The
SNMPv3 security features are:
Message integrity - ensuring that a packet has not been tampered with in-transient.
Authentication - Determining that the message is from a valid source.
Encryption - Scrambling the contents of a packet to prevent it from being seen by an unauthorized source.
SNMPv3 control is through a View BasedAccess Control model (VACM). In VACM, users are assigned to groups which define and specify:
The SNMP version, (v1, v2c or v3) specifies the SNMP version provides the means for allowing some users to access the NE via the earlier SNMP versions with minimum security while allowing other users to access the NE via the more secure V3. While the VACM groups are user provisionable starting with the phase 2 implementation, it would be expected that write access will generally be allowed only to VACM groups that specify SNMPv3.
The access policy for the users assigned to the group. For example, the SNMP MIBs and objects that can be accessed for reading, writing and creating. The SNMP MIBs and objects are specified in the VACM as a text strings identifying a MIB groups.
The list of notifications the group’s users can receive. Notifications are also specified in the VACM group as a text strings identifying a MIB groups.
noAuthNoPriv: without authentication and without privacy — for DMX, this is equivalent to the minimal authentication currently provided for SNMPv2
authNoPriv: with authentication but without privacy. This level of security uses MD5 and the Secure Hash Algorithm as keyed hashing algorithms to protect against data modification attacks and to provide data origin authentication and to defend against masquerade attacks
authPriv: with authentication and with privacy. In addition to secure authentication, this level of security uses the Data Encryption Standard (DES) to encrypt the message content to protect against disclosure.
| November 2011 | Copyright © 2011 Alcatel-Lucent. All rights reserved. |