OS and WaveStar® CIT users access remote Alcatel-Lucent 1665 DMX using the remote Alcatel-Lucent 1665 DMX Target Identifier (TID, name) but remote Alcatel-Lucent 1665 DMX are addressed on the DCC using Network Service Access Point Address (NSAP). Therefore, a method to provide TID-to-NSAP (name-to-address) and NSAP-to-TID (address-to-name) translations is necessary. Target Identifier Address Resolution Protocol (TARP) provides this capability.
For SONET NEs that support TCP/IP and TL1 OS interfaces, TARP is a directory services standard that supports multi-vendor OI compatibility. TARP is specified in Telcordia ® GR-253-CORE, SONET Transport Systems: Common Criteria.
Each NE in a network must be provisioned with a unique TID. The Alcatel-Lucent 1665 DMX's default TID is "LT-DMX". The terms TID and source identifier (SID) are generally used interchangeably.
Important!
Some other-vendor NEs may require that all TIDs adhere to specific rules, for example, that each TID start with an alphabetic character and/or that each TID consist of at least 6-to-7 characters.
To be compatible with other products, Alcatel-Lucent 1665 DMX TIDs should not include special characters "%" and "#". Even though Alcatel-Lucent 1665 DMX TID provisioning allows those special characters, T1.245 SONET Directory Services (SDS) does not support those special characters.
By default, each Alcatel-Lucent 1665 DMX has a unique Network Service Access Point (NSAP) address, thus no NSAP provisioning is necessary in small networks. If the network size exceeds 50 OSI nodes, NSAP provisioning is required.
Although TARP functions automatically without any user provisioning, using standard default values, Alcatel-Lucent 1665 DMX allows provisioning of the following TARP parameters. All TARP parameters are provisionable:
It is recommended that the TARP default values always be used.
The three operations that depend on TARP TID-to-NSAP translations are:
When a TL1 TCP/IP Gateway Network Element (GNE) receives a TL1 login request for a TL1-RNE, the TL1 login request includes the TL1-RNE's TID. The TL1–GNE relies on TARP to determine the TL1-RNE's NSAP. The TL1–GNE needs the NSAP to establish an OSI association with the TL1-RNE. The TL1 login request is forwarded to the TL1-RNE over that OSI association.
The local Alcatel-Lucent 1665 DMX serves as a TL1–GNE and uses TARP as described above for WaveStar® CIT access via Alcatel-Lucent 1665 DMX's serial ports or TCP/IP. When accessing Alcatel-Lucent 1665 DMX via OSI LAN, the WaveStar® CIT (or OS) performs the TL1–GNE function and uses TARP in a similar manner, also. The local Alcatel-Lucent 1665 DMX uses TARP as described above to support remote Install Program/Copy Program.
The first time a TL1–GNE (or local Alcatel-Lucent 1665 DMX) requires a TARP TID-to-NSAP translation for each remote NE, the TL1–GNE originates a TARP query. The TARP query is propagated to all NEs in the same OSI routing area, and if no response is received from within the area, up to two additional TARP queries are propagated throughout the OSI domain. Each NE forwards the TARP queries to each of its neighboring OSI nodes (that is, adjacencies), except the neighbor from which the TARP query was received.
When the TARP query reaches the remote NE with the requested TID, that remote NE responds to the originating NE with the remote NE's NSAP address. If there is no response to any of the TARP queries for a TID, after the third query times out, an error response (for example, TL1–GNE unknown TID or TID not found) is returned to the originating NE.
When an Alcatel-Lucent 1665 DMX is commanded to perform this translation, it knows the NSAPs of the remote NEs to be included in the responses but relies on TARP to determine the corresponding TIDs.
To ensure that the responses to these commands always include the most up-to-date network information, real-time TARP queries are originated instead of relying on the TARP Data Cache or TDC (although the TDC is updated, as appropriate, based on the responses to these NSAP-to-TID queries).
Because the NSAPs are known, these TARP queries are addressed directly to each remote NE (TARP propagation is not necessary). Each remote NE responds to the originating NE with the remote NE's TID.
In order to reduce the frequency of TARP propagation, and to improve the performance of the affected operations, Alcatel-Lucent 1665 DMX supports a TDC option. By default, the TDC is enabled.
Each Alcatel-Lucent 1665 DMX maintains its own TDC, independently. The TDC consists of TID-NSAP translations. Each Alcatel-Lucent 1665 DMX automatically updates its own TDC based on the responses to previous TARP queries. The TDC may also be updated upon receipt of an unsolicited, automatic notification from another NE in the same OSI domain of a TID or NSAP change. The TDC has a maximum number of 16 entries; up to 15 entries may be manually entered. A circular buffer is used for the dynamic entries in the TARP Data Cache.
Alcatel-Lucent 1665 DMX checks its TDC to see if it already has a required TID-to-NSAP translation before originating a TARP query. If a translation is not found in the TDC, the response to that TARP query is used to update the originating Alcatel-Lucent 1665 DMX's TDC. Alcatel-Lucent 1665 DMX assures that its TDC maintains only one TID-NSAP translation for each unique TID. Alcatel-Lucent 1665 DMX supports TDC sizes of up to 110 TID-NSAP translations. If the TDC is disabled or Alcatel-Lucent 1665 DMX's system controller is reset, the contents of the TDC are deleted.
In the unlikely event that a TDC includes an inaccurate TID-to-NSAP translation, Alcatel-Lucent 1665 DMX confirms that both the NSAP and TID of the remote Alcatel-Lucent 1665 DMX are correct before a remote operation proceeds. If there is a mismatch, an error response (for example, TL1-RNE unknown TID, Inconsistent TID, or Association Setup Failure) is returned to the originating NE.
To correct such a situation, delete the subject TID (L4tdctid) from the TDC, then re-request the remote operation for the subject TID. The subsequent TARP query results in an accurate TID-to-NSAP translation, and the TDC is updated accordingly. A broader solution is to disable and re-enable the TDC in which case all TDC entries are deleted.
| November 2011 | Copyright © 2011 Alcatel-Lucent. All rights reserved. |