IP Access for network management

Overview

For network management purposes, Alcatel-Lucent 1665 DMX supports the following types of IP Access:

• Alcatel-Lucent 1665 DMX can serve as a TL1 Translation Device (T-TD) by acting as a gateway network element that allows OMS and/or WaveStar^® CIT to communicate to other network elements (NEs) through an IP access network. This capability allows you to send TL1 commands from OMS or WaveStar^® CIT located on a TCP/IP based network to various NEs connected on an OSI network.

• Alcatel-Lucent 1665 DMX can functionally encapsulate IP packets within OSI packets to be transmitted through the OSI network to the proper NE. Thus Alcatel-Lucent 1665 DMX supports IP based protocols such as FTP by providing end-to-end IP connectivity between OS and NE. This capability is called IP tunneling. IP tunneling is required to support remote database backup/restore in between Alcatel-Lucent 1665 DMX systems.

• Alcatel-Lucent 1665 DMX can also serve as a File Transfer Translation Device (FTTD) by acting as an FTAM-FTP gateway network element. The FTAM-FTP gateway network element translates FTAM over OSI presentation to FTP over TCP/IP. The FTAM-FTP gateway supports software downloads, database backups, and database restores.

• Alcatel-Lucent 1665 DMX also supports Simple Network Management Protocol (SNMP). Alcatel-Lucent 1665 DMX provides limited support for certain reports and traps (alarms and events autonomous messages).

• Alcatel-Lucent 1665 DMX also supports Network Time Protocol (NTP) using IP tunneling to synchronize the time and date to a standard time reference.

TL1 GNE (T-TD)

Alcatel-Lucent 1665 DMX can copy the application information within an IP packet into an OSI packet. This translation is performed at the application layer. When acting as a TL1 translation device, Alcatel-Lucent 1665 DMX must be provisioned with a list of possible OSs. If an OS is not on the list residing within the system, a connection from that OS will not be accepted. When Alcatel-Lucent 1665 DMX is used as a TL1 translation device it is referred to as the T-TD GNE (Gateway Network Element).

Figure 5-17: TL1 translation device

OSI associations and TCP/IP connections

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.

IP tunneling

Today, Telecom networks mix a wide range of heterogeneous protocols and applications.

The Alcatel-Lucent IP tunneling solution consists in encapsulating IP packets inside CLNP (ISO 8473 ConnectionLess Network Protocol) PDU, in order to be able to use an existing OSI-based embedded Data Communications Network (DCN) for IP traffic.

With the IP tunneling over CLNP solution, Alcatel-Lucent 1665 DMX NE can support the following two customer applications: IP access and IP fringe.

An IP access application is shown in Figure 5-18, IP tunneling, where an IP based OS (for example, SNMP manager) located in the IP access DCN manages a remote Alcatel-Lucent 1665 DMX NE located in the OSI-based embedded DCN. The IP application initiated at the OS terminates at the remote NE.

Figure 5-18: IP tunneling

An IP fringe application, where an IP based OS located in the IP access DCN manages an IP managed NE (non Alcatel-Lucent 1665 DMX) on the fringe of Alcatel-Lucent 1665 DMX OSI-based embedded DCN. The IP application initiated at the OS terminates at the IP managed NE. If the IP managed NE is not directly connected to Alcatel-Lucent 1665 DMX remote NE via the LAN, but can be reached via additional routers, some static routes have to be provisioned manually on the routers.

Alcatel-Lucent 1665 DMX and Alcatel-Lucent 1850 TSS-100/Alcatel-Lucent 1850 TSS-320 IP tunneling interworking

In a typical network, the Alcatel-Lucent 1665 DMX is a remote NE (RNE) interworking with an Alcatel-Lucent 1850 TSS-100 or Alcatel-Lucent 1850 TSS-320 functioning as the gateway NE (GNE). The Alcatel-Lucent 1850 TSS-100/Alcatel-Lucent 1850 TSS-320 GNE supports T-TD (TL1 Translation Device) to translate TL1 over TCP/IP to TL1 over OSI. This allows TL1 management of a remote Alcatel-Lucent 1665 DMX.

However, to fully support IP tunneling interworking between a remote Alcatel-Lucent 1665 DMX and the Alcatel-Lucent 1850 TSS-100/Alcatel-Lucent 1850 TSS-320 GNE, Alcatel-Lucent 1665 DMX supports a provisionable NSAP selector and a reduced Maximum Transmission Unit (MTU) size.

To support interworking with the Alcatel-Lucent 1850 TSS-100/Alcatel-Lucent 1850 TSS-320, the NSAP selector parameter must be provisioned to f0 (04 default value) at the remote Alcatel-Lucent 1665 DMX. This allows software operations (download/backup/restore) to a remote Alcatel-Lucent 1665 DMX using FT-TD (File Transfer Translation Device) to translate FTP over TCP/IP to FTAM over OSI.

Encapsulating IP packets

The Alcatel-Lucent 1665 DMX GNE acts as the tunnel entrance, i.e., the interface between IP and CLNP. When an IP packet is received from the LAN interface of the GNE, if it is not destined for the GNE, the received IP packet is encapsulated into CLNP PDU(s) as simple CLNP user data, loosing any IP protocol meanings (such as IP addressing and life time), as shown in the figure below.

Figure 5-19: Encapsulated IP packets

For the CLNP PDU that contains the encapsulated IP packet, the CLNP source address is the NSAP of the NE where the IP packet is encapsulated (tunnel entrance), and the CLNP destination address is the NSAP of the NE where the IP packet will be de-capsulated (tunnel exit). The CLNP PDU then is routed via the ISO-10589 "IS to IS intra-domain information exchange protocol (IS-IS)" within the embedded OSI DCN. Therefore, the IP tunneling over CLNP is transparent for the IP world. The CLNP world is only used to carry the IP traffic and there is no possible connections between the OSI applications and the IP applications. The IP tunnel serves as a normal point-to-point link for the IP traffic between two NSAP entities (the tunnel entrance and tunnel exit). Because the IP traffic flows in both directions between two NSAP entities, the tunnel entrance entity also serves as the tunnel exit entity, and vice versa.

In the tunnel entrance, the way to associate an IP destination address in the IP packet with an OSI NSAP address (the NSAP of tunnel exit entity) can be derived by the static user provisioned information or by the automatic distributed tunnel routing information, called Tunnel Auto Provisioning (TAP).

Tunnel auto provisioning (TAP)

In the OSI networks, the network elements use the ISO-10589 "IS to IS intra-domain information exchange protocol (IS-IS)" to exchange the topology information. The knowledge by every network element of the whole network topology at a given time allows the computation of the optimal route to any possible destination on the network. The IS-IS protocol provides for the inclusion of optional variable length fields in all IS-IS packets. This allows additional IP specific information to be added to the OSI IS-IS routing packets.

The topological information between network elements (or called intermediate systems) is communicated by sending a specific IS-IS PDU called LSP (Link-State PDU). In the LSP optional fields, the NEs send (advertise) information about the IP subnets that can be reached via that NE. By default, this will be locally attached, but other subnets can also be provisioned for the advertisement.

Advertising IP information using LSP options can be enabled or disabled via the user interfaces. Based on the specification of the IS-IS protocol, any intermediate systems that can not recognize the encoded optional fields just ignores this and passes them through unchanged. This makes it possible that the NEs that advertise both OSI and IP routing information can seamlessly interwork with the NEs that advertise the OSI routing information only.

With automatic distribution of IP routing information via IS-IS LSP, a NE, which learned such information, then can associate an IP destination address of an IP packet with an OSI NSAP address, and uses this NSAP address as the destination address of CLNP PDU(s) which encapsulates the IP packet.

FTAM-FTP gateway network element

Alcatel-Lucent 1665 DMX can serve as a File Transfer Translation Device (FTTD) by acting as an FTAM-FTP gateway network element. The FTAM-FTP gateway network element translates FTAM over OSI presentation to FTP over TCP/IP. The FTAM-FTP gateway supports software downloads, database backups, and database restores.

The figure below shows an Alcatel-Lucent 1665 DMX provisioned as an FTAM-FTP gateway network element. The FTAM-FTP gateway network element allows remote Alcatel-Lucent 1665 DMX network elements to request software downloads and database restores from an FTP server. The FTAM-FTP gateway network element also allows remote Alcatel-Lucent 1665 DMX network elements to backup databases to an FTP server.

Figure 5-20: FTAM-FTP gateway

IP over DCC

The sections above described how Alcatel-Lucent 1665 DMX can act as a GNE providing FTTD and TTD functionality. If there is no Alcatel-Lucent 1665 DMX in a particular office where GNE can connect, via IAO LAN interface, to the IP WAN, these options can prove ineffective. For this reason Alcatel-Lucent 1665 DMX incorporates IP communications over the DCC channel. This feature allows operations communications to flow through another device (like Ciena Core Director) to the Alcatel-Lucent 1665 DMX GNE via an IP over DCC link. This feature also enables interworking with Ciena Core Director (CD).

Management traffic flow (OMS to Alcatel-Lucent 1665 DMX)

OMS originates IP packets destined to Alcatel-Lucent 1665 DMX GNE, and uses Router R1 as the Default Router. Router R1 routes the packets via IP access DCN to Router R2. Router R2 forwards the packets to CD via Proxy ARP supported by CD. Based on the static routing, CD forwards the IP packets to Alcatel-Lucent 1665 DMX GNE via IP over DCC link. Alcatel-Lucent 1665 DMX GNE translates IP messages to OSI messages and routes CLNP packets to the remote NE (RNE) via OSI embedded DCN.

Management traffic flow (Alcatel-Lucent 1665 DMX to OMS)

Alcatel-Lucent 1665 DMX RNE originates CLNP packets destined to Alcatel-Lucent 1665 DMX GNE, and routes CLNP packets to Alcatel-Lucent 1665 DMX GNE via OSI embedded DCN. The Alcatel-Lucent 1665 DMX GNE translates OSI messages to IP messages, and originates IP packets destined to OMS. Based on static routing, the Alcatel-Lucent 1665 DMX GNE uses the IP over DCC link to forward the IP packets to the CD. CD forwards the IP packets to Router R2 via default routing provisioned by user. Router R2 routes the IP packets via IP access DCN to Router R1.Router R1 forwards the IP packets to OMS.

The figure below depicts the functionality of IP over DCC.

Figure 5-21: Operations communication via IP over DCC

Access control list

The access control list adds a layer of control in addition to the TL1 user ID and password. When the access control list is enabled, an IP-based OS can log in to a remote target NE via a GNE (T-TD) only if the GNE, represented by its TID or NSAP, is included on the target network element access control list. Up to 50 different entries can be included on the access control list.

An OSI-based OS can log in to a remote target NE only if the OSI-based OSI, represented by its NSAP, is included on the target network element access control list.

Important!

Specifying a GNE's NSAP is more secure than specifying the TID. Since the TID is provisionable and are generally available, a user attempting unauthorized access to the NE could present a TID that duplicates a TID on the access control list, thereby, bypassing the security provided by the access control list.