I N D E X

1. INTRODUCTION
2. PHYSICAL DESCRIPTION
3. INSTALLATION
4. CONFIGURATION
5. UMI MODULE COMMAND REFERENCE
6. UMI SNMP AGENT
7. SUPPORTED TRAPS
8. FIELD SOFTWARE UPGRADE
9. APPENDIX A: UMI MODULE MEASUREMENTS
10. APPENDIX B: UMI VIRTUAL PORT MEASUREMENTS
11. APPENDIX C: ALARMS
12. APPENDIX D: USING STARKEEPER TO CONFIGURE THE UMI
13. APPENDIX E: UMI HUNT GROUP DEMONSTRATION
14. APPENDIX F: UMI CLOSED USER GROUP DEMONSTRATION
15. HARDWARE WARRANTY
16. END-USER LICENSE AGREEMENT FOR SOFTWARE

1   INTRODUCTION

Connectivity between an IP network and a BNS (refers to both BNS-2000 and BNS-2000 VCS) network is accomplished using the Universal Mediation Interface Module (UMI). As a state-ofthe- art “solid state” module (no disks or fans) which resides in a BNS node, the UMI is both a replacement and enhancement of the LCS60 product.

The UMI allows both synchronous and asynchronous endpoints connected to a BNS network to access endpoints on an IP network. Similarly, endpoints on an IP network can access both synchronous and asynchronous endpoints on a BNS network.

The UMI can be located anywhere in the BNS network, thus simplifying configuration, administration and maintenance without affecting operation or connectivity.

1.1   FEATURE SUMMARY

The UMI provides a complete mediation interface (i.e., gateway) for BNS and IP protocols. The basic features are:

1.1.1   504 Virtual Sessions per UMI

The UMI operates like a “virtual SAM504”, in effect mapping 504 SAM ports within a BNS network to 504 “virtual ports” residing in the IP network, and vice versa.

1.1.2   Seamless Operation in Either Call Set-up Direction

The UMI provides the terminal/PC user on either network with a “terminal server” type interface where a connection setup to a user/device on the other network can be made to appear to the calling user as if the destination endpoint is on the same network.

1.1.3   Closed User Groups (CUGs)

The UMI supports Closed User Groups (CUGs) to restrict callers to specified destinations. This is an important feature for protecting sensitive endpoints in a corporate wide network without the burden of special “security servers”.

1.1.4   Hunt Groups

A Hunt Group is a set of UMI “virtual ports”, which are arranged to receive calls from the IP network at a common address.

1.1.5   Domain Name Server (DNS) capability

The UMI can maintain a set of mnemonic host names, analogous to the /etc/hosts file on both UNIX and Microsoft Windows platforms. This allows the UMI to perform a translation between a user-provided name and its associated IP address and TCP port number, for BNS-to-IP calls. The use of a mnemonic name is optional; the UMI will always accept an IP address in its base form.

Additionally, the UMI allows for the definition of an external DNS to be used for translation of mnemonic addresses not defined in the internal host table. Three DNS name server IP addresses are supported by the UMI.

1.1.6   Peer to Peer Encryption

The UMI can encrypt user data on the IP network. This prevents unauthorized access to sensitive information. Encryption can be enabled on a per session basis.

2   PHYSICAL DESCRIPTION

2.1   FACEPLATE

2.1.1   Light Emitting Diodes (LED)

The lights on the module faceplate are green, yellow, and red. They indicate on-line, off-line, and fault states respectively. When the module circuitry detects an on-board fault, the red LED (fault) is lit.

2.1.2   Mode Switch

The Mode Switch supports three positions: Enabl, Diag and Disab. The Mode switch must be in the Enabl position for the UMI to function properly.

2.1.3   Reset Button

When the Reset button is pressed, the module buffers and registers are cleared, and the module application program is restarted. The module is taken out of service, and all connections are terminated.

2.2   High Performance I/O Board

The UMI¹ mates with the DTK41 High Performance I/O (HPIO) board in support of the UTM connectivity options. The DTK41 I/O board contains all the necessary connectors the UTM requires for currently available Console and LAN connections.

Note: Cables and adapters are available

2.2.1   Serial

The UMI does not use the serial interface of the DTK41 at this time. The DTK41 Serial interface is software configurable. Options are as an RS-232C DTE for serial rates up to 64Kbps, or as a V.35 DTE for serial rates up to E1.

2.2.2   Console

The UMI Console interface may be used for console activities and the initial configuration. It assumes the connected device is configured as 9600 baud, 8 bits and no parity.

2.2.3   10/100 BaseT and Fiber LAN

The DTK41 LAN and Fiber ports are used for IP network connectivity. The UMI supports Internet peer level protocols (e.g. IP, TCP, UDP, ICMP and SNMP). All of the 10/100 ports are fully switched, not bridged. The capacity of the switch is over 1Gbps. The 10/100 and Fiber ports are managed from the UMI console. Each 10/100 port and the Fiber port may be enabled or disabled individually. Alarms are generated if a link is established, or if a link is lost.

An advanced feature DTK41 is that no crossover cable is ever required on the 10/100 ports. The 10/100 ports will automatically correct for the cabling mismatch.

The 10/100 ports will self-configure to match the speed of the link (10 Mbps or 100 Mbps ), and the Duplex ( Full or Half ). No configuration is required.

The Fiber interface connects to the industry standard SC cabling. If ST cabling is used, the DTK41 ST plug-in module is used. No adapter cables are required.

2.2.4   DSU

The UMI does not utilize the DSU interface at this time. The DTK41 DSU (4-wire) interface is software configurable for T1 or E1 rates. A value of T1 is used for domestic 1.544 MHz interfaces with 193 Bit Superframes. A value of E1 is used for European 2.048 MHz interfaces with 256 Bit Superframes. The DSU functionality is built in. This interface may be used for connectivity to TDM, Frame Relay, and ATM networks.

2.2.5   Variants

The DTK41 high performance I/O board is available with two different mounting brackets. The DTK41N incorporates a mounting bracket specifically designed to be installed in a BNS node, a Datakit VCS node, or an MPC. The DTK41S has a mounting bracket specifically designed to be placed in a SAM504, SAM64, or SAM128. It is anticipated that the UMI shall use only the DTK41N variant of the DTK41.

2.3   Standard Performance I/O Board

The UMI mates with the CEY5 I/O board in support of the UMI connectivity options. The CEY5 I/O board contains all the necessary connectors the UMI requires for currently available Console and LAN connections.

Cables and adapters are available.

2.3.1   Console

This interface requires a standard RJ45 terminated, twisted pair, data cable. It connects as a data terminating equipment (DTE) to an asynchronous device and uses RS-232C signaling. Connection to the UMI console is required for UMI “Module-Based” Administration (described later in this document) or StarKeeper® II NMS alarm collection². Otherwise, the console can be disconnected during normal operation.

2.3.2   LAN

This interface requires a standard RJ45 terminated Category 5, twisted pair, data cable. It connects to a 10BaseT hub or Router on the local LAN segment.

1. A Series 1:2 UMI is required for the DTK-41 (or any other I/O board which requires power) since the original UMI did not provide any power whatsoever to the I/O module, and the original UMI did not provide a management interface.
2. The UMI also supports console access through a TCP telnet connection, which is accessed using TCP port 1023. This service is available only when the unit is in service.

3   INSTALLATION

UMI installation consists of:

• inserting the DTK41 or CEY5 distribution board in the backplane slot
• inserting the module in the corresponding shelf slot
• cabling console and data ports

• Ensure protection from electromagnetic interference (EMI). Wear an electrostatic discharge (ESD) wrist strap to prevent equipment damage.
• To prevent damage to module circuitry, always insert the I/O board before inserting its corresponding module. Never remove the I/O board before removing the module.

3.1   INSERTING THE I/O BOARD

The I/O board plugs into the backplane at the rear of the shelf; it is held in place by shrouds on the backplane pinfield, and secured with two screws. Insert the I/O board before inserting its corresponding UMI.

• Align the I/O board backplane connector with the backplane pinfield, and align the screw slots with the screw holes.
• Slip the backplane connector onto the pins. The board should seat easily. If seating is difficult, the board may be canted or some pins may be bent.
• Insert the screws, and tighten them securely.

3.2   REMOVING THE I/O BOARD

Remove the I/O board only for relocation, replacement, or board type confirmation.

Requirement: The Module in the slot corresponding to the I/O board must be removed first.

• Disconnect all cabling to I/O board ports, labeling the cable ends if appropriate.
• Remove the screws holding the I/O board in place.
• Carefully rock the board as you pull it out.

3.3   INSERTING THE UMI MODULE

Requirement: The I/O board for the module must be installed in its corresponding slot on the backplane at the rear of the shelf first.

• Set the mode switch on the module faceplate to Disab.
• With the module latch extended, carefully push the module all the way into the slot. The backplane pins slip into the module receptacle.
• Close the latch to lock the module into position.
• Move the mode switch on the module faceplate to Enabl.

3.4   REMOVING THE UMI MODULE

You can remove and replace a UMI in an operating node without damaging the module itself, or without disrupting calls on other modules. Only the calls on the UMI being removed are disrupted.

Requirement: I/O board for the module must still be in its corresponding slot on the backplane at the rear of the shelf.

• If the mode switch is in the Enabl position, move it to Disab.
• Open the latch on the module faceplate.
• Pull the module straight out of the slot.

3.5   CABLING

This section provides information on how to cable the UMI console and data ports with the CEY5 I/O board. Consult the following table for ordering information regarding all of the cabling options shown in this section.

3.5.1   Cabling the I/O Console Port

Depending upon access availability, one of the cables shown in the following diagram will be needed to set up a UMI console connection.

3.5.2   Cabling the CEY5 LAN Port

The following will be needed to set up a UMI data connection.

• A Shielded Twisted Pair CAT5 cable is attached to the LAN port of the I/O board and will allow for cabling to either a hub or router. The DTK41 I/O board may use a 10BaseT or 100BaseT hub or router. The CEY5 I/O board uses a 10BaseT hub or router.

4   CONFIGURATION

4.1   OVERVIEW

The following diagram is a functional representation of UMI operation, intended as an aid to understanding the configuration process.

The overall configuration process can be divided into two phases:

Base Configuration – setting up the UMI for IP connectivity and console security

Operational Configuration – setting up the UMI and BNS node to enable users to make calls between the BNS and IP networks

Actual command sequences will be presented in this section to illustrate the UMI and related node configuration process. For node commands, the appropriate references are the Data Networking Products Synchronous/Asynchronous Multiplexer Reference and Commands Reference. Section 5 of this document should be used as the reference for UMI module commands.

4.2   BASE CONFIGURATION

This phase of the configuration process sets up the UMI for IP networking. This includes the UMI’s IP address and subnet mask, the IP address of the gateway router, the IP address of an SNMP manager (optional), and the IP address of a domain name server (optional). It also includes setting up console-security parameters, i.e., an administrative login password and the (optional) timeout for automatic console logoff. These aspects of the configuration will rarely need to be changed once they are satisfactorily set up.

The following is an example of base configuration:

4.3   OPERATIONAL CONFIGURATION

There is an implicit one-to-one mapping of SAM504 boards/ports (as the node views them) to the UMI’s virtual ports (“vports”), as shown in the following table. These associations are built into the UMI module software, and will need to be kept in mind for proper coordination of node and module administration procedures for operational configuration.

The following subsections describe how the node and UMI are jointly configured to enable calls to be set up in each direction.

4.3.1   BNS-to-IP Calling

UMI virtual ports designated as originating, as part of module-based administration, are for the BNS-to-IP calling direction. From the node administration perspective, the corresponding SAM ports are set up as host service-type ports, since they receive calls from the BNS network. Predefined destination (PDD) information, in the form of a destination IP address and TCP port number, may be optionally set up on the UMI for each virtual port.

For UMI virtual ports configured as originating, operation from the perspective of a user calling from somewhere in the BNS network is determined by whether or not a PDD has been specified for the virtual port chosen to originate the call. An originating-type virtual port which has a PDD associated with it will have that connection automatically established at the time a BNS connection is made to the UMI. If no PDD has been specified, the calling user is greeted with a UMI Destination> prompt each time the virtual port receives a BNS connection. The user would then enter the destination IP address plus TCP port number desired. If no TCP port number is entered, the telnet default (23) is used. The user also has the option to enter a mnemonic host name which has been previously administered into the UMI’s host table. The session is terminated when the UMI virtual port receives a disconnect from the BNS side of the call, e.g., when the calling user uses the attention sequence.

If a Domain Name Server has been defined on the UMI, the calling user may also enter a fully qualified destination name (e.g. “server.ab.company.com”) to be resolved. It is also possible to override the TCP port while still resolving the IP address. For example, the dial string “server.ab.company.com 50030” selects TCP port 50030 and then asks DNS to resolve “server.ab.company.com” to an IP address.

The following diagram illustrates the configuration elements affecting call setup in the BNS-to-IP direction.

The following is a sample UMI module administration command sequence, which will set up a group of originating virtual ports on the UMI, followed by the corresponding node command sequence to enable BNS-to-IP calling:

The first node-administration step is to establish one or more receive groups to which SAM504 ports can be associated, using the enter group command. They should be configured with HOST AUTOBAUD OFF.

To illustrate an alternative setup, suppose we had not entered the PDD information as part of the vport command. The calling user would have gotten the UMI Destination> prompt, and could then enter “135.17.59.20 23” to reach the same destination and service. This would be preferable if there were many different endpoints in the IP network which BNS network users need to reach. Rather than require these users to keep track of a multitude of IP addresses, mnemonic names could instead be used. Each of these could be set up with the following command:

<UMI> host 1 name=ip-host1 ipaddr=135.17.59.20 port=23

BNS users could now type “ip-host1” at the UMI Destination> prompt to reach the same destination/service.

4.3.2   IP-to-BNS Calling

UMI virtual ports designated as receive, as part of module-based administration, are for the IP-to- BNS calling direction. From the node administration perspective, the corresponding SAM ports are set up as term service-type ports, since they act like terminals originating calls on the BNS network. If required, PDD information in the form of a BNS destination would be set up as part of node administration for the “SAM504” ports.

A UMI virtual port configured as receive “listens” on a configured TCP port for an incoming call arrival. Once a call is established, the Telnet over TCP protocol is used for transport.

The following diagram illustrates the configuration elements affecting call setup in the IP-to-BNS direction.

The following command sequence demonstrates the set up of one UMI hunt group, as well as related node administration for IP-to-BNS calling:

4.4   CLOSED USER GROUPS

CUGs can be established within the BNS network via node administration to control access to BNS endpoints from UMI virtual ports (represented by their corresponding SAM504 ports), and vice versa (see Data Networking Products Commands Reference).

The UMI also has its own implementation of closed user groups to control access between its virtual ports and endpoints on the IP network. The module administration command cug is used to create a closed user group as a single IP address or range of addresses in a sub net. The vport command allows up to 32 CUGs to be associated with a group of virtual ports. The console command allows up to 32 CUGs to be associated with the telnet administrative console of the UMI. The snmp command allows up to 32 CUGs to be associated with the SNMP interface to the UMI as a security feature. Calls in either the IP->BNS direction are restricted as follows:

4.4.1   IP-to-BNS Calling

A call to the TCP port number corresponding to a hunt group of rcv-type virtual ports will be blocked unless the calling IP address belongs to at least one of the CUGs associated with the selected virtual port. End-to-end security could be accomplished with node administration, by setting up a PDD to a specific BNS destination address for the SAM504 ports corresponding to the virtual port hunt group (most restrictive), or by using CUG assignments in the BNS network to control dialing access from each originating group of SAM ports. See Appendix F for an example scenario.

4.4.2   Telnet Console

A call to the TCP port number corresponding to the telnet console (i.e. 1023) will be blocked unless the calling IP address belongs to at least one of the CUGs associated with the telnet console.

4.4.3   SNMP Interface

A UDP packet sent to the SNMP interface port number will be blocked unless the sender IP address belongs to at least one of the CUGs associated with the SNMP interface.

4.5   UMI CONFIGURATOR

This tool facilitates initial UMI configuration. The configurator is a free StarKeeper. II NMS utility that significantly reduces the time required to configure an entire UMI, including node and module-based configuration. UMI Configurator Installation and Usage notes can be found in Appendix D.

5   U M I MODULE COMMAND REFERENCE

These module commands are used to configure the operation of the UMI.

Not all commands are visible all the time. Should the unit be logged out, only the login command is visible. The reboot command places the unit in the logged-out mode.

Parameters of the form name=<value> must be entered in order, and all parameters being used must be entered on a single command line.

• Commands may be entered in upper or lower case.
• Parameters of the form name=<value> may use upper or lower case for name.
• Case is preserved for values.
• Backspace erases one character.

5.1   LOGIN

Syntax: login passwd=<password> (default password is: initial)

The login command is only visible when the unit is in the logged out (i.e. secure) mode. The unit enters this mode whenever a logout command is issued or when a reboot occurs for any reason. The password is not echo-suppressed and consists of up to seven alphanumeric characters. Special characters are not allowed.

NOTE: The "Login" command accepts an optional form. By entering the command without arguments, a password will be prompted for. In this alternate form, the password is not echoed. Only asterisks are echoed (i.e. login <enter>).

5.2   LOGOUT

Syntax: logout

The logout command is only visible when the unit is logged in. The command has no arguments. It returns the user to the logged out mode.

5.3   CHGPASS

Syntax: chgpass old=<password> new=<password> confirm=<password>

The chgpass command is only visible when the unit is logged in. The command allows the user to change the password configured for the unit. All arguments are required for the command to complete. The old password is the one currently in effect. The new and confirm passwords must be identical. Passwords are up to seven characters in length. The characters are alphanumeric and special characters are not allowed.

5.4   LOCAL

Syntax: local [ipaddr=<IP address>][submask=<submask>]

The local command is only visible when the unit is logged in.

The ipaddr field is the IP address of this unit.

The submask field is the subnet mask for the LAN segment on which the unit is located. It defaults to 255.255.255.0.

The IP address and subnet mask are used to determine whether a destination IP address is on the same LAN segment, or if a gateway hop is required

5.5   GATEWAY

Syntax: gateway ipaddr=<IP address>

The gateway command is only visible when the unit is logged in.

The ipaddr field is the IP address of the gateway router to be used to reach a destination IP address on a different LAN segment.

5.6   DOMAIN NAME SERVER

Syntax: dns

ipaddr1=<IP address> ipaddr2=<IP address> ipaddr3=<IP address> name1=<Domain Name> name2=<Domain Name> name3=<Domain Name>

The dns command is only visible when the unit is logged in.

Each ipaddrX field is the IP address of a Domain Name Server to be used for mnemonic addresses not defined in the host table. When all are set to 0.0.0.0, the DNS functions on the UMI are disabled. The DNS addresses are used in order. If only one address is to be defined, it should be ipaddr1.

The name1, name2, and name3 parameters are domain names. These domain names are appended to a dial string which is not fully specified for DNS purposes. For example, a name “bender.ho.lucent.com” is fully specified, so nothing is appended by the UMI. A name such as “bender” would need to have a domain appended before the DNS server could resolve it. The UMI will append the specified domain names in the order of name1 through name3, and send the resulting strings to the DNS server in succession until the latter is able to perform a resolution.

5.7   HELP

Syntax: help

The help command is always visible. It displays the commands allowed for the mode that the unit is currently in.

5.8   VERSION

Syntax: version

The version command is only visible when the unit is logged in. It displays the current software and database revisions of the unit.

5.9   REBOOT

Syntax: reboot

The reboot command is only visible when the unit is logged in. It resets the unit, which allows physical attributes to be set. The console interface returns to the logged-out mode.

This command is password protected. The administrative password will be prompted and echoed with asterisks.

5.10   REMOVE MODULE

Syntax: rm

The remove command is only visible when the unit is logged in. It takes the unit out of service. This command must be performed before any module level configuration changes can occur.

This command is password protected. The administrative password will be prompted and echoed with asterisks.

5.11   RESTORE MODULE

Syntax: rs

The restore command is only visible when the unit is logged in. It returns the unit to service. If any physical attribute was changed, the unit will be automatically rebooted by this command.

5.12   CLEAR MEASUREMENTS

Syntax: clr

The clear command is only visible when the unit is logged in. It sets all the measurements and error counters to zero.

5.13   DISPLAY MEASUREMENTS

Syntax: dm [mod][vport<vport#>]

The dm command is only visible when the unit is logged in. It displays the current measurements in a formatted report on the console.

The value of is between 1 and 504, inclusive.

See Appendix A for an enumeration of module measurements. Virtual port information is not displayed on a module-level report.

See Appendix B for an enumeration of virtual port measurements. Module information is not displayed on a virtual-port-level report.

5.14   VERIFY

Syntax: vfy [mod][vport<vport#|vport range|ALL>][cug][host]

The vfy command is only visible when the unit is logged in. The command accepts mod, vport, cug, or host as objects.

The mod option displays the module-level configuration in a formatted report.

For the vport option, the <vport #> is between 1 and 504. The <vport range> accepts a numeric range such as 3-6.

A value of ALL provides a report of all virtual ports in the UMI.

The cug option produces a list of all closed user groups on the UMI, with the specification of how each is configured.

The host option produces a list of all mnemonic host names configured on the UMI.

The vfy command with a large range, or the value of “ALL”, may produce voluminous results. The output of the vfy command may be manually aborted with a Control-C, or a DEL, character.

5.15   HOST NAME ADMINISTRATION

Syntax: host <host #> [name=<host name>][ipaddr=<IP address>] [port=<TCP port>][del]

The UMI can maintain a set of mnemonic host names for “dialing” out to the IP network, analogous to the /etc/hosts file on both UNIX and Microsoft Windows platforms. This allows the UMI to perform a translation between a user-provided name and its associated IP address and TCP port number during call setup, for originating virtual ports without a PDD. The use of a mnemonic name is optional; the UMI will always accept an IP address in its base form.

The host command is used to configure the translation table.

The name field is a mnemonic up to 9 characters in length.

If the parameter del is used, the entry is deleted.

5.16   Mnemonic PDD ADMINISTRATION

Syntax: pdd <pdd #> < <Mnemonic PDD Address> | DELETE >

The UMI can maintain a set of mnemonic destination addresses for “dialing” out to the IP network. These can be assigned to individual virtual ports via the vport command. The mnemonic address may be an entry in the host table, an unqualified DNS address (if domain names have been defined), or a fully qualified DNS address. The mnemonic address may be up to 63 characters in length.

The use of mnemonic addressing is optional in the UMI. Numeric IP addresses may be defined on a virtual port range basis using the dest parameter of the vport command.

The pdd command is used to configure the translation table. Up to sixteen mnemonic destinations may be defined. The mnemonic destinations may be assigned to any number of virtual ports.

The <pdd_id> parameter is numeric identification of the mnemonic address. It has a value of one through sixteen inclusive.

The <Mnemonic PDD Address> is the address string without any quotes.

If the <Mnemonic PDD Address> parameter of delete is used, the entry <pdd #> is deleted.

5.17   SNMP

Syntax: snmp [ipaddr=<SNMP Mgr IP address>]

[ipaddr=<SNMP Mgr address>]
[port=< [CUG=<<+|-> CUG Number> ]
[COMM=< "Double Quoted Community String" | NONE > ]
[syscontact=< "Double Quoted String" | NONE > ]
[sysloc=< "Double Quoted String" | NONE > ]

The snmp command is used to configure the IP address of the SNMP trap manager. Since traps are unsolicited alarms, an agent can take the initiative to inform the manager of the occurrence of a predefined condition.

A single or multiple SNMP managers can access the UMI. However, only one SNMP manager can be predefined as the trap manager. As result of using this command, all traps will be directed to the chosen trap manager. The ipaddr field defines the IP address of the SNMP manager to whom the traps are to be sent. The port field indicates the UDP port on that SNMP manager and defaults to the standard value of 162. If closed user groups are to be defined on the interface the cug option allows the association of up to 32 individual groups defined with the cug command.

The COMM option allows the configuration of a private SNMP community. The public community is always present per the specification. This option takes effect immediately.

The sysContact option allows a non-volatile initialization of the MIB-II sysContact variable. The MIB-II sysContact variable remains changeable from the SNMP management station. However, it is initialized to the non=volatile value each time the UMI is rebotted. Setting this option to the constant none removes the non-volatile initialization of the MIB-II variable. This option takes effect immediately. However, the non-volatile contents are stored on the DTK41. If a DTK41 is not installed the settings are lost on the next reboot. If the UMI is administered via the Datakit Controller enhanced interface updated for build #21 or later, the DTK41 is not required since the Datakit controller will apply the settings on each restart.

The sysName option allows a non-volatile initialization of the MIB-II sysName variable. The MIB-II sysName variable remains changeable from the SNMP management station. However, it is initialized to the non-volatile value each time the UMI is rebotted. Setting this option to the to the constant none removes the non-volatile initialization of the MIB-II variable. This option takes effect immediately. However, the non-volatile contents are stored on the DTK41. If a DTK41 is not installed, the settings are lost on the next reboot. If the UMI is administered via the Datakit Controller enhanced interface updated for build #21 of later, the DTK41 is not required since the Datakit controller will apply the settings on each restart.

The sysLocation option allows a non=volatile initialization of the MIB-II sysLocation variable. The MIB-II sysLocation variable remains changeable from the SNMP management station. However, it is initialized to the non=volatile value each time the UMI is rebotted. Setting this option to the constant none removes the non-volatile initialization of the MIB-II varialbe. This option takes effect immediately. However, the non=volatile contents are stored on the DTD41. If a DTK41 is not installed, the settings are lost on the next reboot. If the UMI is administered via the Datakit Controller enhanced interface updated for build #21 or later, the DTK41 is not required since the Datakit controller will apply the settings on each restart.

5.18   INSTALL SOFTWARE

Syntax: install [key=<registration key>]

The UMI module is shipped with the software pre-registered for the installed software. A registration procedure must be performed after each upgrade to a new software release.

The install command is used to register the UMI software. The command is available at all times, since registration is required for a console login. When this command is used with no argument, it provides the data needed to generate the registration key. The same command is then used with the key value to register the software. The registration is performed after the new software is made active with a module reboot command.

5.19   CONSOLE TIMEOUT

Syntax: timeout [off | <number of seconds>]

The UMI console uses a three-wire interface (RD, TD, GND), and the lead state of other signals is not relevant. This would imply that the only way to change the state of the console is to explicitly log in or log out, or via a reboot or reset, which forces the console to be logged out. For users who wish the console to automatically log off after a period of inactivity, there is a console timer. The console timer defaults to the disabled condition, and may be activated by the timeout command.

This command is only visible when the console is logged in. The <number of seconds> value must be between 15 and 255, inclusive.

When the UMI determines a period of inactivity of the specified time, it automatically forces the console to log off. An INFO-level alarm (see Appendix C) is issued at that time.

5.20   VIRTUAL PORT ADMINISTRATION

Syntax: vport <vport #>

[cnt=<#>] [incr=<#>] [type=<ORIG|RCV>] [pdd=<PDD #>] [dest=<IP Addr>] [dport=<Dest TCP Port>] [hport=<Hunt Group TCP Port>] [cug=[+|-]<CUG Number>] [prot=<ASYNC | SYNC | RAW>] [crfix=< TRANS | NONULL >] [crlf-< TRANS | LCS60 >] [data=<7bit | trans>] [sess=<hold | trans>] [crypt=<on | off>]

The vport command configures one or more virtual ports. The value of <vport #> is in the range of 1 through 504, inclusive, and represents the first virtual port to be affected by this command.

The cnt parameter allows more than one port to be affected. All virtual ports may be configured with a single command having a cnt of 504.

The incr parameter allows for multiple dport configurations from a single command. It is an increment added to the TCP port base value for each subsequent port specified in the cnt option.

Examples using the inrc command together with the cnt command.

The first example configures two vports (starting at vport 1) and increments the dport by a value of one. The second example configures three vports (starting at vport 1) and increments each subsequent dport by a value of 200.

When a virtual port is a call receiver (listener), it is assigned a default port number value of 23 (TELNET service). If only one class of service is needed for access to the BNS network, this does not need to be changed. However, when a specific TCP port is specified via the hport=<tcp_port> option, it is used in place of the default value.

Multiple virtual ports may share the same TCP port value, to define a hunt group of virtual ports. A connection that is directed to this TCP port value would select the next available virtual port. The hport=<tcp_port> option may only be used with receive virtual ports.

The cug=[+|-]<CUG_num> option allows the inclusion or deletion of a Closed User Group in the list of CUGs assigned to the virtual port. The “+” will add the <CUG_num> to the CUG list. The “-” is used to delete the <CUG_num> from the list.

The prot option allows the specification of the encapsulation method associated with the virtual port. The async encapsulation method uses a telnet service without extensions. This is applicable to asynchronous connections. The sync encapsulation is basically the same as asynchronous, but with the extensions needed for synchronous protocols. The raw option is used when no encapsulation is desired. It should be noted that the DT-4000 and DT-2020 series devices are tolerant of synchronous encapsulation for asynchronous connections, so virtual ports with these protocols may be grouped together for connections exclusively to endpoints on those devices.

The crfix=< TRANS | NONULL > option accommodates an anomaly in some early variants of telnet implementation on UNIX systems, which insert a NULL character in the data stream after a carriage return. Most end devices are not affected by this NULL character. However, some devices (e.g. the BNS control computer) have erroneous operation if these characters are received. The value TRANS indicates transparent operation, where all data received by the UMI, including a NULL after a carriage return, is forwarded to the end device. The value of NONULL removes a NULL character immediately following a carriage return. No other NULL characters are affected. The default operation is transparent, and the crfix option may only be specified if the protocol selected is asynchronous.

The crlf=< TRANS | LCS60 > option accommodates Microsoft MSDOS (and Windows variants) of telnet implementations. These implementations insert a LF character in the data stream after a carriage return. Since both characters are treated equally by some endpoints, the result is a double line entry where only one was desired. The LCS60 device would always strip the LF following a CR. However, this would yield problems for some applications where transparency was desired. The crlf option allows the selection of either operation. When the crlf=TRANS is selected, the virtual port is transparent. When the crlf=LCS60 is selected, the virtual port performs LCS60 style processing on the LF following a CR. It is stripped from the data stream.

The data=<7bit | trans> option allows you to "filter" data to 7bit by essentially masking out the parity bit on each character. This is useful when a TY card connected to a Network Element is configured as 8 bit and no parity and the Network Element is 7bit and even parity. Datakit takes care of parity conversion on egress, but Telnet does not. Some telnet clients will display garbage, and others will work fine. This feature will eliminate the issue altogether.

The sess=<hold|trans> option allows an IP session to be maintained across multiple BNS sessions. The option is available for sessions that originate in the IP infrastructure, and for the async encapsulation method. The default value is trans which provides seamless service instead of session hold. If the BNS port has been configured with an attention character, that attention character will control the BNS sessions. The UMI supports attention character sequences that are printable text, a DELETE, or a single Break. The double break attention sequence is not supported.

The crypt=<on|off> option allows an IP session to be encrypted between peer entities. Both ends of the connection must have encryption enabled or disabled. The UMI uses a dynamic random key method of data encryption when this option is enabled.

5.21   CLOSED USER GROUP (CUG) ADMINISTRATION

Syntax: cug [ipaddr=<IP address>][submask=<IP submask>]

The cug command is only visible when the unit is logged in. The parameter is the closed user group identifier used to assign the CUG to a virtual port (with the vport command), and may be a value between 1 and 32, inclusive. The CUG may also be assigned to the telnet console (with the console command), or the SNMP interface (with the SNMP command).

Each CUG is specified by a single IP address and subnet mask pair. The ipaddr parameter is an address of an endpoint (or base address of a group of endpoints) to be allowed into the group. The ipaddr value ANDed with the submask value must agree with the caller’s or destination’s IP address ANDed with the same submask for a call to be allowed to or from a virtual port to which the CUG is assigned. Depending on the submask value, this allows an individual (submask=255.255.255.255), intermediate, or network-wide level of authorization.

Setting the ipaddr value to 0.0.0.0 deletes any prior configuration for the <CUG_num>. A <CUG_num> may not be deleted if it is currently assigned to any virtual port.

A list of all configured CUGs is reported via the vfy cug command. The list of closed user groups associated with a given virtual port is presented in response to the vfy vport command.

5.22   DISPLAY CONNECTIONS

Syntax: dconn

The dconn command is only visible when the unit is logged in. The command displays the connections between virtual ports and their destinations. Only active virtual ports are displayed.

5.23   DISCONNECT PORT

disc VPORT [ <port_num> ] [ CONSOLE ]

The disc command is only visible when the unit is logged in. The value of is between 1 and 504, inclusive. If the specified virtual port is in service, any existing circuit spanning it will be dropped. This is useful in IP networks when the remote peer vanishes due to a remote reboot or a network error.

The value of console will allow the disconnect of the telnet console from itself or the serial console interface. This is useful when the telnet console peer is not responding.

This command is password protected. The administrative password will be prompted and echoed with asterisks.

5.24   PING

ping <IP address> [ Interval Seconds ]

The ping command is only visible when the unit is logged in. The command has a single argument, the IP address that is to be pinged.

The ping command formats an ICMP echo request packet which is then sent to the IP Address specified. The device with that address will issue an ICMP echo reply to the request. This is required of all IP implementations by RFC 791. If a reply is received, an informational alarm is issued on the UMI console. If no reply is received, there is a timeout message that will appear for that ICMP echo request.

The ping command issues a single ICMP echo request packet and awaits a response. The response is printed, and another ICMP echo request is issued. The operation continues until the user presses any character. The [ Interval Seconds ] argument specifies the amount of time to wait in seconds between the individual ICMP echo requests. It should be noted that some host Internet Protocol implementations issue duplicate responses to a single ICMP request. The ping command will suppress duplicate replies.

5.25   Label

Syntax: label [ “Double Quoted String” | none ]

The label command is used to give the command console a unique prompt. The command is visible only when logged into the UMI administrative console. If the label command is invoked without arguments, the current configuration of the label is displayed. If the argument to the label command is the word ‘none’, any current label is set to a null value. If the argument to the label command is a double quoted string, the contents of the string becomes the application console prompt label. A console label may be up to thirty one characters in length, and may contain spaces. The console label string may not contain the colon character (:).

5.26   Administrative Password

Syntax: admpass [old=<Old Password>] new=<New Password> confirm=<New Password>

The admpass command is used to configure or change an administrative password for the UMI console. The administrative password is required to use the Remove, Disconnect, or Reboot commands. The administrative password defaults to a NULL value until changed.

The [old=<Old Password>] specifies the previous administrative password for use of this command. This option is not required on the first configuration of the administrative password.

The new=<New Password> confirm=<New Password> specifies the administrative password. Both values are required and must match exactly.

The administrative password takes effect immediately after the successful execution of the command.

5.27   CONSOLE Administration

Syntax: console [cug=<<+|->CUG Number>]

The console command is used to configure or change the closed user group configuration of the telnet console to the UMI. Up to 32 CUGs may be associated with the telnet console.

5.28   HPIO Administration

Syntax: HPIO RESET

RESET ENABLE < ALL | FIBER | <10/100 PHY RANGE> > DISABLE < ALL | FIBER | <10/100 PHY RANGE> >

The HPIO command is used to enable or disable the physical LAN connections on the DTK41 high performance I/O module. The DTK41 operates defaults to all ports being active. Therefore, no configuration is required unless security of the unused ports becomes an issue.

The RESET command option is used to perform a restart on the DTK41 module. Under normal circumstances, it should never be required to use this command. No arguments are required. The ‘Link Active’ alarms for all connected links will be issued after a reset.

The ENABLE command enables the physical interfaces that have been previously disabled. The DTK41 defaults to all interfaces being enabled. The ENABLE accepts a target to specify those ports to be affected. A target value of ALL specifies that all three 10/100 BaseT ports, and the Fiber port is to be affected. A target value of FIBER specifies that only the fiber port is to be affected. A numeric value or range specifies the 10/100 BaseT ports. The numberic value may be a single number (e.g. ‘2’) or a range (e.g. 1-2).

The DISABLE command disables physical interfaces. When disabled, the interface is not capable of communications. The DISABLE accepts a target to specify those ports to be affected. These are in the same form as the ENABLE command.

6   UMI SNMP AGENT

The UMI SNMP V1 agent supports a multitude of SNMP MIB variables, SNMP trap operations, as well as set and get operations.

One or more SNMP managers may query the SNMP agent.

6.1   SNMP Version 1 Commands

6.2   UMI SNMP MIB Variable Database

RO = Read Only Variable
R/W = Read Variable / Write Variable
SIV = Storage is Volatile

7   SUPPORTED TRAPS

8   FIELD SOFTWARE UPGRADE

A Field Software upgrade of the UMI is a two-step process, consisting of a software download to the module’s flash memory followed by a restart of the module to activate the new software. The download can be accomplished through either of the two different I/O interfaces on the UMI I/O board: Telnet (LAN) or RS-232C.

Specific upgrade instructions are made available with any maintenance release software.

8.1   Upgrade via Telnet Console

Using an industry standard Telnet application, you can download to the UMI while it is in service and transporting data.

Unlike other products in the family, the UMI console is at TCP port 1023. It was necessary to move the console since TCP port 23 is being used for mediation functions (user data) on the UMI.

8.2   Upgrade via RS-232C Console

The UMI may also be upgraded through its RS-232C console port. This is done either remotely from a StarKeeper® II NMS, or locally from a PC. When upgrading via RS-232C, the module needs to be taken out of service for the software download portion of the upgrade.

9   APPENDIX A: UMI MODULE MEASUREMENTS

This appendix itemizes the measurements available using the display measurements (dm) command with the mod option. These are module-based measurements. The base measurements are always displayed, while the error and exception counters are only displayed if nonzero.

10   APPENDIX B: UMI VIRTUAL PORT MEASUREMENTS

This appendix itemizes the measurements available using the display measurements (dm) command with the vport option. These are the virtual-port-based measurements.

11   APPENDIX C: ALARMS

This appendix is an enumeration of the alarms presented on the UMI console along with their severity.

11.1   Major Alarms

A major alarm indicates a serious, service-degrading condition.

11.2   Minor Alarms

A minor alarm indicates a secondary or transient error that is not likely to affect overall service unless multiple minor alarms are issued. In this case, a serious condition exists that may affect overall system performance.

11.3   Info Alarms

An information alarm is a message that does not necessarily require attention. It typically is important for network administration, but does not adversely affect service.

12   APPENDIX D: USING STARKEEPER TO CONFIGURE THE UMI

Configuring a UMI in a BNS node consists of several steps. Since the UMI is represented as a SAM504 in the node, configuration information on the node must match the configuration information in the UMI in order for the module to operate correctly.

StarKeeper II NMS R10 provides a package, the UMI Configurator, which supports the initial configuration of a UMI in a BNS node. This package performs these activities:

• Prompts the administrator for UMI virtual port configuration information;
• Performs validation on the entered information;
• Creates update specifications for both the UMI and BNS node configuration updates;
• Performs configuration update operations on both the UMI and BNS node.

This package does not perform the following configuration activities:

• Delete a currently configured BNS slot
• Process UMI Closed User Group (CUG) information
• Perform configuration updates to the BNS node after the initial configuration is established

NOTE: The use of UMI Configurator is optional. Administrators may use the appropriate module and BNS node commands to directly configure UMI units and BNS nodes.

12.1   PRE-CONFIGURATION ACTIVITIES

Several activities must take place before UMI and BNS configuration can take place.

12.1.1   Package Installation

Install the package on StarKeeper according to the instructions provided in the document StarKeeper II NMS R10 Console Support for Datatek Products. Establish a console connection from StarKeeper to the UMI console port, using the instructions provided in that document.

12.1.2   Develop Configuration Information

Develop the configuration information by planning how the UMI will be used in the network. The following worksheets can be used to list out the information needed to perform the configuration:

12.1.3   Perform BNS Activities

Perform these activities on the BNS node, using node commands:

• Check that the UMI slot is not configured. If it is, delete the configuration data.
• Enter the group names.
• Enter the service addresses.

12.1.4   Perform UMI Activities

Perform these activities on StarKeeper:

• Check that the console connection to the UMI is active.
• Check that the UMI is logged in

12.2   USING THE UMI CONFIGURATOR

The UMI Configurator is invoked in the following manner: In the umi directory created during script installation on StarKeeper, run command umicfg.ctl. The command works by providing a menu of operations from which the user selects an operation to be performed.

12.2.1   UMI Configurator Menu of Operations

When the administrator invokes the UMI Configurator, the screen prompts appear as follows:

Menu item 1 allows the input configuration data to be displayed. This includes the administrator input, as well as the generated UMI and node update data.

Menu item 2 allows configuration data to be added and modified. Data is modified by deleting the previous entry and entering new input.

Menu item 3 causes the UMI to be configured.

Menu item 4 causes the BNS node to be configured.

Menu item 5 exits the UMI Configurator.

12.2.2   Running the UMI Configurator

The UMI Configurator is used as follows:

1. Log onto the StarKeeper as user cnmsadm.
2. Verify that the StarKeeper console connection to the BNS node is active.
3. Verify that the console connection to the UMI is active.
4. Verify that the UMI console connection is logged in.
5. Change directory to directory umi.
6. Invoke the configuration script using the command ./umicfg.ctl.
7. Create a new UMI configuration file by selecting the appropriate menu item..
8. Display and edit the configuration file, as appropriate.
9. Update the UMI with the configuration data.
10. Update the BNS node with the SAM configuration data. As the update takes place, messages will appear on the screen. 11. Exit the UMI Configurator.

12.3   POST-CONFIGURATION ACTIVITIES

The UMI Configurator establishes an initial, consistent configuration in the UMI and BNS node. However, there are other activities that the administrator must perform. These include:

1. Restore the SAM to service. The UMI Configurator sets the ports in-service, but it leaves the boards and module out of service.
2. Define and add CUGs to virtual ports, if appropriate. This is done using the cug and vport module commands. 3.
3. UMI commands to make the changes.

13   APPENDIX E: UMI HUNT GROUP DEMONSTRATION

A UMI Hunt Group is a set of virtual ports arranged to receive calls at a common TCP port number. These calls may in turn be directed to a Predefined Destination (PDD) in the BNS network. Consider the following diagram:

This is solved with the UMI by assigning a common TCP port number to a hunt group of virtual ports from which the modems are automatically dialed in the BNS network. Multiple distinct banks of modems may be dialed in the BNS network from a single UMI hunt group. The command sequence to configure the UMI for the desired operation was shown in section 4.3.2.

When a host calls the correct IP address and TCP port, it is connected to the next available virtual port in the hunt group. (A TCP connection timeout will take place only if no virtual ports are available.) When this connection is made, a BNS PDD directs the call to the address specified (by node administration) for the corresponding SAM504 port. This destination may actually be a BNS hunt group of ports, hence the ability to have a UMI hunt group act like a group of hunt groups.

14   APPENDIX F: UMI CLOSED USER GROUP DEMONSTRATION

The UMI supports the notion of Closed User Groups (CUGs). In a BNS network, CUGs are administered on the affected nodes, in order to restrict UMI virtual ports (i.e., SAM504 ports) to specific BNS endpoints, and vice versa. CUGs may also be fully extended from a UMI virtual port into the IP network. This can apply in either call direction (IP to BNS or BNS to IP), providing a secure firewall for BNS-IP connectivity. This is an important feature for protecting sensitive endpoints in a corporate-wide network without the burden of special “security servers”.

In the following diagram, there is a corporate IP network infrastructure which may be used by endpoints throughout the network. Some endpoints require access to Network Elements (NE) reachable via the BNS network, and some endpoints are not to be allowed such access. Those IP endpoints which are allowed access to the NE are placed in a CUG associated with a UMI virtual port. (The same CUG may be associated with any number of UMI virtual ports. Any one virtual port may have up to 32 CUGs.) A UMI virtual port is treated by the BNS Control Computer as a SAM504 port belonging to a BNS CUG, and the far endpoint in the BNS network also has a corresponding CUG association. Jointly, these CUG arrangements provide end-to-end security.

The UMI is configured with CUG 1 with the address of Endpoint A, as follows:

cug 1 ipaddr=135.17.59.5 submask=255.255.255.255

The protected virtual ports (i.e., those forming a hunt group which will be given access to the NEs via a separate node-administered BNS CUG) are set up with CUG 1 assigned to them, as follows:

vport 1 cnt=4 type=rcv hport=26 cug=+1

When Endpoint A calls the UMI and TCP port number 26, access to the NE in the BNS network is granted and everything proceeds transparently. If anyone outside CUG 1 (e.g., Endpoint B) attempts to call the same TCP port, however, the following happens:

1. The call is terminated during authentication without any data being transported in either direction.
2. An authentication alarm is generated and sent to an attached Starkeeper, an attached Telnet Console and the SNMP Trap Manager. The Alarm contains the IP address of the remote endpoint that attempted the unauthorized access.

Endpoint B is given access to the BNS network in general by means of a separate hunt group on the UMI with a different TCP port number, which has no corresponding CUG restriction on the BNS network. This UMI hunt group might still have CUGs associated with it (for these two IP endpoints) if there are other endpoints in the IP network which should be totally restricted from accessing the BNS network.

15   HARDWARE WARRANTY
The warranty period for hardware shall be one year from the date of delivery. Replacements and repairs are guaranteed for the longer of the remaining original warranty period or 90 days.

16   END-USER LICENSE AGREEMENT FOR SOFTWARE
This License Agreement ("License") is a legal contract between you and the manufacturer ("Manufacturer") of the system ("HARDWARE") with which you acquired software product(s) identified above ("SOFTWARE"). The SOFTWARE may include printed materials that accompany the SOFTWARE. Any software provided along with the SOFTWARE that is associated with a separate end-user license agreement is licensed to you under the terms of that license agreement. By installing, copying, downloading, accessing or otherwise using the SOFTWARE, you agree to be bound by the terms of this LICENSE. If you do not agree to the terms of this LICENSE, Manufacturer is unwilling to license the SOFTWARE to you. In such event, you may not use or copy the SOFTWARE, and you should promptly contact Manufacturer for instructions on return of the unused product(s) for a refund.

16.1   Software License
You may only install and use one copy of the SOFTWARE on the HARDWARE (unless otherwise licensed by Manufacturer). The SOFTWARE may not be installed, accessed, displayed, run, shared or used concurrently on or from different computers, including a workstation, terminal or other digital electronic device (“Devices”). Notwithstanding the foregoing and except as otherwise provided below, any number of Devices may access or otherwise utilize the services of the SOFTWARE. You may not reverse engineer, decompile, or disassemble the SOFTWARE, except and only to the extent that such activity is expressly permitted by applicable law notwithstanding this limitation. The SOFTWARE is licensed as a single product. Its component parts may not be separated for use on more than one HARDWARE. The SOFTWARE is licensed with the HARDWARE as a single integrated product. The SOFTWARE may only be used with the HARDWARE as set forth in this LICENSE. You may not rent, lease or lend the SOFTWARE in any manner. You may permanently transfer all of your rights under this LICENSE only as part of a permanent sale or transfer of the HARDWARE, provided you retain no copies, you transfer all of the SOFTWARE (including all component parts, the media and printed materials, any upgrades, this LICENSE and, if applicable, the Certificate(s) of Authenticity), and the recipient agrees to the terms of this LICENSE. If the SOFTWARE is an upgrade, any transfer must also include all prior versions of the SOFTWARE. Without prejudice to any other rights, Manufacturer may terminate this LICENSE if you fail to comply with the terms and conditions of this LICENSE. In such event, you must destroy all copies of the SOFTWARE and all of its component parts.

16.2   Intellectual Property Rights
The SOFTWARE is licensed, not sold to you. The SOFTWARE is protected by copyright laws and international copyright treaties, as well as other intellectual property laws and treaties. You may not copy the printed materials accompanying the SOFTWARE. All title and intellectual property rights in and to the content which may be accessed through use of the SOFTWARE is the property of the respective content owner and may be protected by applicable copyright or other intellectual property laws and treaties. This LICENSE grants you no rights to use such content. All rights not expressly granted under this LICENSE are reserved Manufacturer and its licensors (if any).

16.3   Software Support
SOFTWARE support is not provided by Manufacturer, or its affiliates or subsidiaries separate from the HARDWARE. For SOFTWARE support, please contact your supplier of the HARDWARE. Should you have any questions concerning this LICENSE, or if you desire to contact Manufacturer for any other reason, please refer to the address provided in the documentation for the HARDWARE.

16.4   Export Restrictions
You agree that you will not export or re-export the SOFTWARE to any country, person, or entity subject to U.S. export restrictions. You specifically agree not to export or re-export the SOFTWARE: (i) to any country to which the U.S. has embargoed or restricted the export of goods or services, which as of March 1998 include, but are not necessarily limited to Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria, or to any national of any such country, wherever located, who intends to transmit or transport the products back to such country; (ii) to any person or entity who you know or have reason to know will utilize the SOFTWARE or portion thereof in the design, development or production of nuclear, chemical or biological weapons; or (iii) to any person or entity who has been prohibited from participating in U.S. export transactions by any federal agency of the U.S. government.

16.5   Limited Warranty
Manufacturer warrants that (a) the SOFTWARE will perform substantially in accordance with the accompanying written materials for a period of ninety (90) days from the date of receipt. Any implied warranties on the SOFTWARE are limited to ninety (90) days. Some states/jurisdictions do not allow limitations on duration of an implied warranty, so the above limitation may not apply to you.

Manufacturer's and its suppliers' entire liability and your exclusive remedy shall be, at Manufacturer's option, either (a) return of the price paid, or (b) repair or replacement of the SOFTWARE that does not meet this Limited Warranty and which is returned to Manufacturer with a copy of your receipt. This Limited Warranty is void if failure of the SOFTWARE has resulted from accident, abuse, or misapplication. Any replacement SOFTWARE will be warranted for the remainder of the original warranty period or thirty (30) days, whichever is longer.

16.6   No Other Warranties
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MANUFACTURER AND ITS SUPPLIERS DISCLAIM ALL OTHER WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT, WITH REGARD TO THE SOFTWARE AND THE ACCOMPANYING WRITTEN MATERIALS. THIS LIMITED WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS. YOU MAY HAVE OTHERS, WHICH VARY FROM STATE/JURISDICTION TO STATE/JURISDICTION.

16.7   Limitation of Liability
To the maximum extent permitted by applicable law, in no event shall Manufacturer or its suppliers be liable for any damages whatsoever (including without limitation, special, incidental, consequential, or indirect damages for personal injury, loss of business profits, business interruption, loss of business information, or any other pecuniary loss) arising out of the use of or inability to use this product, even if Manufacturer has been advised of the possibility of such damages. In any case, Manufacturer's and its suppliers' entire liability under any provision of this License shall be limited to the amount actually paid by you for the SOFTWARE and/or the HARDWARE. Because some states/jurisdictions do not allow the exclusion or limitation of liability for consequential or incidental damages, the above limitation may not apply to you.

16.8   Special Provisions
The SOFTWARE and documentation are provided with RESTRICTED RIGHTS. Use, duplication, or disclosure by the United States Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and HARDWARE Software clause at DFARS 252.227-7013 or subparagraphs (c)(1) and (2) of the Commercial HARDWARE Software-Restricted Rights at 48 CFR 52.227-19, as applicable. Manufacturer is Datatek Applications, Inc., Rte. 202-206, Bridgewater, New Jersey 08807.

If you acquired the SOFTWARE in the United States of America, this Software License are governed by the laws of the State of New Jersey, excluding its choice of laws provisions. If you acquired the SOFTWARE outside the United States of America, local law may apply. This LICENSE constitutes the entire understanding and agreement between you and the Manufacturer in relation to the SOFTWARE and supercedes any and all prior or other communications, statements, documents, agreements or other information between the parties with respect to the subject matter hereof.