Software Guide Version 4.9

V25, V50PLUS, V150 AND V200
Software Guide
Version 4.9
www.vocality.com
BEFORE INSTALLING THE UNIT PLEASE REFER TO THE SAFETY INSTRUCTIONS IN APPENDIX A
Contacts
For further information, contact: Vocality International Ltd Lydling Barn Lydling Farm Puttenham Lane Shackleford Surrey GU8 6AP United Kingdom Tel +44 (0) 1483 813 120 Fax +44 (0) 1483 813 121 For technical support, email support@vocality.com For sales information, email sales@vocality.com For online support, registered users should visit www.vocality.com and select the support section.
Table of Contents
1
1.1 1.2
ABOUT THIS MANUAL .................................................................................... 8

Conventions..............................................................................................................8 Structure ..................................................................................................................8
2
2.1
CONFIGURING THE UNIT............................................................................... 9

Standard Configuration or Push-Config?...................................................................9
2.2 The Port Addressing Scheme ....................................................................................9 2.2.1 The Node ID....................................................................................................... 10 2.2.2 The Slot and Channel Numbers ............................................................................. 10 2.2.2.1 V200 and V150 ................................................................................................ 10 2.2.2.2 V50plus, V25 ................................................................................................... 12 2.3 Using the Supervisor or Management and Configuration (M&C) Port......................13 2.3.1 User Interface .................................................................................................... 13 2.3.2 Cursor Movement................................................................................................ 15 2.3.3 Parameter Selection ............................................................................................ 15 2.3.4 Updating the Configuration................................................................................... 15 2.3.5 Password Protection ............................................................................................ 17 2.4 Menu Structure .......................................................................................................19 2.4.1 The MAIN menu.................................................................................................. 20 2.4.2 The SYSTEM menu .............................................................................................. 22 2.4.3 The CONFIGURATIONS menu................................................................................ 28 2.4.4 The CLOCKING menu .......................................................................................... 32 2.4.4.1 Clocking and Push Config................................................................................... 34 2.4.5 The ROUTING menu ............................................................................................ 35 2.4.5.1.1 Overview .................................................................................................. 39 2.4.5.2 Secondary Routing ........................................................................................... 39 2.4.5.2.1 Configuration ............................................................................................ 39 2.4.5.2.2 Failure & Recovery ..................................................................................... 40 2.4.5.2.2.1 Data Aggregates................................................................................... 40 2.4.5.2.2.2 IP Aggregates ...................................................................................... 40 2.4.5.2.3 Status, Logs & Alarms ................................................................................ 40 2.4.5.3 Push Config ..................................................................................................... 40 2.4.6 The SIP GATEWAY menu ...................................................................................... 41 2.4.6.1 The SYSTEM menu............................................................................................ 42 2.4.6.2 The CHANNEL SUMMARY menu........................................................................... 43 2.4.6.3 The CHANNEL DETAILS menu............................................................................. 44
2.4.6.4 The SIP DIRECTORY menu ................................................................................. 47 2.4.7 The FEATURE KEYS menu..................................................................................... 48 2.4.8 The CALL ROUTING menu .................................................................................... 49 2.4.8.1 The HUNT GROUPS menu .................................................................................. 50 2.4.8.2 The AUTO MAPPING menu ................................................................................. 52 2.4.8.3 The DIRECTORY menu....................................................................................... 55 2.4.8.4 The MLPP menu................................................................................................ 57 2.4.8.4.1 The MLPP ENTRIES menu ............................................................................ 59 2.4.9 The SLOTS menu ................................................................................................ 61 2.4.9.1 The DATA menu ............................................................................................... 63 2.4.9.2 The ANALOGUE VOICE menu.............................................................................. 69 2.4.9.2.1 The ANALOGUE PORTS menu....................................................................... 70 2.4.9.2.2 The SIGNALS & TONES menu ...................................................................... 73 2.4.9.2.3 The VOICE ACTIVATION menu ..................................................................... 75 2.4.9.3 The IP menu .................................................................................................... 76 2.4.9.3.1 The GENERAL menu ................................................................................... 77 2.4.9.3.2 The NETWORKS menu ................................................................................ 79 2.4.9.3.2.1 Loopback interfaces .............................................................................. 81 2.4.9.3.3 The ROUTE MANAGEMENT menu .................................................................. 81 2.4.9.3.3.1 The RIPv2 menu ................................................................................... 82 2.4.9.3.3.2 The OSPF menu.................................................................................... 84 2.4.9.3.3.2.1 The SYSTEM menu......................................................................... 85 2.4.9.3.3.2.2 The AREA menu ............................................................................ 87 2.4.9.3.3.2.3 The INTERFACE menu .................................................................... 89 2.4.9.3.3.2.4 The VIRTUAL LINK menu ................................................................ 91 2.4.9.3.4 The IP STATIC ROUTE TABLE menu .............................................................. 93 2.4.9.3.5 The POLICY menu ...................................................................................... 95 2.4.9.3.5.1 The ADDRESS LISTS menu .................................................................... 96 2.4.9.3.5.2 The ROUTE MAPS menu......................................................................... 99 2.4.9.3.5.3 The RIP EXPORT FILTERS menu ............................................................ 103 2.4.9.3.5.4 The AGGREGATION menu .................................................................... 104 2.4.9.3.6 The ACCESS TABLE menu ......................................................................... 106 2.4.9.3.7 The UDP RELAY TABLE menu ..................................................................... 107 2.4.9.3.8 The DBA POOLS menu .............................................................................. 108 2.4.9.3.9 The MAC SOURCE FILTER TABLE menu ....................................................... 112 2.4.9.3.10 The SERVICE MANAGEMENT menu............................................................ 113 2.4.9.3.10.1 The ADDRESS DEFINITIONS menu ........................................................ 114 2.4.9.3.10.2 The PROTOCOL DEFINITIONS menu ...................................................... 115 2.4.9.3.10.3 The FILTER TABLE menu...................................................................... 116 2.4.9.3.10.4 The TCPGw FILTER TABLE menu ........................................................... 118 2.4.9.3.11 IP AGGREGATES menu............................................................................ 118 2.4.9.4 The SYSLOG menu ......................................................................................... 122 2.4.9.5 The ISDN menu.............................................................................................. 124 2.4.9.5.1 Terminal Adaptor(TA) Mode....................................................................... 125 2.4.9.5.1.1 US NI-1, Manual SPID Entry ................................................................. 128 2.4.9.5.1.2 US NI-1, Automatic SPID Entry............................................................. 129 2.4.9.5.1.3 US NI-1, Auto SPID Entry with SPID Guessing ........................................ 130 2.4.9.5.2 Network Function Semi(NFS) Mode............................................................. 132 2.4.9.6 The DIGITAL VOICE menu ............................................................................... 135 2.4.9.6.1 The DIAL PARAMETERS menu .................................................................... 141 2.4.9.7 The TDM menu............................................................................................... 143 2.4.9.7.1 The TDM Timeslots menu .......................................................................... 144 2.4.9.7.1.1 Destination Specifics ........................................................................... 146 2.4.9.7.2 Timeslot Types ........................................................................................ 147 2.4.9.7.2.1 Selecting The Best Packet Type ............................................................ 151 2.4.9.7.3 The TDM Advanced Config menu ................................................................ 152 2.4.9.7.3.1 Radio Silence mode............................................................................. 153 2.4.9.8 The DIAGNOSTICS menu ................................................................................. 154 2.4.9.9 The SNMP menu ............................................................................................. 155 2.4.9.9.1 The SNMP GENERAL menu ........................................................................ 156 2.4.9.9.2 The SNMP KEYS menu .............................................................................. 157 2.4.9.9.3 The SNMP TARGET TABLE menu................................................................. 158 2.4.9.9.4 The SNMP TRAP CONFIGURATIONS menu.................................................... 159
2.4.10 The SOFTWARE MANAGEMENT menu ................................................................... 2.4.11 The SLOT MANAGEMENT menu ........................................................................... 2.4.12 The BACKUP SYNCHRONIZATION menu ............................................................... 2.4.13 The ALARM MANAGEMENT menu ......................................................................... 2.4.13.1 The CURRENT ALARMS menu ........................................................................... 2.4.13.2 The ALARM SIGNALS menu .............................................................................. 2.4.13.3 The SYSTEM EVENTS menu.............................................................................. 2.4.13.4 The SERIAL DATA EVENTS menu ...................................................................... 2.4.13.5 The IP EVENTS menu ...................................................................................... 2.4.13.6 The E1/T1/J1 EVENTS menu ............................................................................ 2.4.13.7 The ALARM LOG menu .................................................................................... 2.4.14 The PUSH CONFIG CLIENTS menu ....................................................................... 2.4.15 The REMOTE menu............................................................................................
160 162 165 166 167 169 170 172 173 175 176 177 179
DIAGNOSTICS ........................................................................................... 181
3.1 The DIAGNOSTICS menu .................................................................................181 3.1.1 The CLOCK STATUS menu .................................................................................. 182 3.1.2 The AGG SUMMARY menu .................................................................................. 183 3.1.3 The TEST PORTS menu ...................................................................................... 184 3.1.4 The SLOTS menu .............................................................................................. 186 3.2 The SLOT N / DIAGNOSTICS menu ...................................................................186 3.2.1 The IP menu .................................................................................................... 187 3.2.1.1 The PING menu.............................................................................................. 187 3.2.1.2 The IP ROUTE TABLE menu .............................................................................. 191 3.2.1.3 The IP STATISTICS menu ................................................................................ 192 3.2.1.4 The ETHERNET menu ...................................................................................... 195 3.2.1.5 The POWER OVER ETHERNET menu .................................................................. 196 3.2.1.5.1 The SLOT x menu .................................................................................... 197 3.2.1.6 The ARP TABLE menu...................................................................................... 199 3.2.1.7 The BRIDGE FDB menu ................................................................................... 200 3.2.1.8 The BRIDGE PORTS menu................................................................................ 201 3.2.2 The DATA PORT STATS menu ............................................................................. 202 3.2.3 The AGG CALL STATS menu ............................................................................... 206 3.2.4 The TRIB CALL SUMMARY menu .......................................................................... 207 3.2.5 The TRIB CALL STATS menu ............................................................................... 208 3.2.6 The AGG STATUS menu ..................................................................................... 209 3.2.7 The SYSTEM INFO menu .................................................................................... 210 3.2.8 The TDM Status menu ....................................................................................... 211 3.2.9 The TDM STATISTICS menu ............................................................................... 213 3.2.10 The LOGS menu ............................................................................................... 217 3.2.10.1 The CONNECTION LOG menu ........................................................................... 218 3.2.10.2 The CONFIGURATION LOG menu ...................................................................... 219 3.2.10.3 The ALARM LOG menu .................................................................................... 220 3.2.10.4 The CALL RECORD LOG menu .......................................................................... 221 3.2.10.5 The IP LOG menu ........................................................................................... 222 3.2.10.6 The SIP GATEWAY LOGS menu ......................................................................... 223 3.2.10.7 The SVR DEBUG LOG menu.............................................................................. 224 3.2.10.8 The ALL LOGS menu ....................................................................................... 225 3.2.10.9 The LOG HELP menu ....................................................................................... 226 3.2.11 The SNMP STATS menu ..................................................................................... 227
4
4.1 4.2
FEATURES.................................................................................................. 228
Data Capabilities...................................................................................................228 Voice Capabilities .................................................................................................228
4.3 Multi-level Precedence and Pre-emption (MLPP) ..................................................229 4.3.1 MLPP Service Invocation .................................................................................... 230
4.3.1.1 Primary rate interface ..................................................................................... 4.3.1.2 Invoking an outgoing precedence call ................................................................ 4.3.1.3 Provisioning access codes ................................................................................ 4.3.2 Pre-emption Rules............................................................................................. 4.3.2.1 Precedence call with no pre-emption ................................................................. 4.3.2.2 Precedence Call Pre-empted............................................................................. 4.3.2.3 Precedence Ringback and Cadence.................................................................... 4.3.3 Interaction with other features............................................................................
230 230 231 232 232 233 233 233
4.4 Push-Config ..........................................................................................................234 4.4.1 Push-Config Features......................................................................................... 235 4.4.1.1 Multi-unit configuration at hub site for remotes ................................................... 235 4.4.1.2 Remote Unit Identification ............................................................................... 235 4.4.1.3 Pushing the Config.......................................................................................... 235 4.4.1.4 Automatic Routing .......................................................................................... 236 4.4.1.5 Start-up Configs for Remote Units..................................................................... 236 4.4.1.6 Reconfiguration Control ................................................................................... 238 4.5 4.6 4.7 Call Progress Tones ..............................................................................................238 Dynamic Bandwidth Allocation .............................................................................239 Asymmetric Bandwidth.........................................................................................240
4.8 Clocks ...................................................................................................................240 4.8.1 Direction Conventions........................................................................................ 240 4.8.2 Global Clocks ................................................................................................... 242 4.8.3 Receive Clocks ................................................................................................. 243 4.8.4 Transmit Clocks ................................................................................................ 244 4.8.5 Phase-Locked Loops .......................................................................................... 245 4.9 Broadcast Mode ....................................................................................................245
4.10 Async Error-correction and Compression ..............................................................245 4.10.1 Error-correction ................................................................................................ 246 4.10.2 Compression .................................................................................................... 247 4.10.3 General Characteristics ...................................................................................... 247 4.11 Switched Carrier Operation...................................................................................247 4.11.1 SWITCHED Mode .............................................................................................. 247 4.11.2 SCADA Mode .................................................................................................... 249 4.12 The Integrated IP Router......................................................................................251 4.12.1 Overview ......................................................................................................... 251 4.12.2 Basic IPV4 Routing ............................................................................................ 251 4.12.3 Network Configuration ....................................................................................... 251 4.12.4 Virtual Ports ..................................................................................................... 252 4.12.5 Unnumbered IP ................................................................................................ 254 4.12.6 MTUs .............................................................................................................. 255 4.12.7 RIPv2 and OSPF................................................................................................ 258 4.12.7.1 Compatibility ................................................................................................. 259 4.12.8 Static Routes.................................................................................................... 260 4.12.9 Loopback Interfaces .......................................................................................... 260 4.12.10 Example Configuration....................................................................................... 261 4.12.11 UDP Relay........................................................................................................ 265 4.12.12 TCP Gateway (TCP PEP) ................................................................................... 266 4.12.13 DHCP Client/Server/Relay .................................................................................. 266 4.12.14 Telnet Access ................................................................................................... 270 4.12.15 Spanning Tree Protocol ...................................................................................... 271 4.13 IP Aggregates.......................................................................................................271
4.14 TDM Aggregates ...................................................................................................272 4.14.1 TDM Aggregate Specification .............................................................................. 273 4.14.2 Targets Supported ............................................................................................ 273 4.14.3 Interworking .................................................................................................... 273 4.14.4 TDM Tunnelling................................................................................................. 274 4.14.5 Configuration Summary ..................................................................................... 274 4.15 4.16 SIPGw...................................................................................................................275 SNMP ....................................................................................................................275
5
5.1 5.2 5.3 5.4
APPLICATIONS EXAMPLES ........................................................................ 276

Back-to-back Testing ............................................................................................276 Use with Satellite Modems....................................................................................280 Use with IP Aggregates ........................................................................................285 Broadcast Voice and Data .....................................................................................292
APPENDIX A: APPENDIX B:
ABBREVIATIONS ...................................................................... 295 INDEX ...................................................................................... 297
C H A P T E R
A B O U T
T H I S
M A N U A L
1 About This Manual
Chapter Chapter
The portfolio of Vocality International multiplexer/router products contains a wide range of units from the compact hand-portable V25 to the expandable, rackmount V200. Even so, the whole range is based on a common core of software functionality and the various members differ only in their physical architecture, number of ports and flexibility. This manual describes the generic software facilities for all products, with specific exceptions noted either in the text itself or through the use of icons as described below. Details of the hardware for each unit are provided in an individual Hardware Guide which should be read in conjunction with this manual. The Hardware Guide contains important safety information and Declarations of Conformity and must be read before installing the product.
1.1
Conventions
Throughout the text, each section heading is accompanied by a set of four icons bearing the legends V25, V50+, V150 and V200:
Some icons may be absent, indicating the section is not relevant to a particular product. It may be the case that most of a section is relevant but specific details are different; where this is the case the icon is present but exceptions are noted in the text with an asterisk *. For example, the valid range for some configurable objects is different on the high-speed CPU on the V200 and V150 systems only.
1.2
Structure
This manual contains a section on Configuration, which consists of detailed examples of all of the menu pages together with explanations of all of the features and lists of all of the selection options. For a summary of the unique features and benefits the Vocality products offer, read the section entitled Features. For practical discussions on how the software should be configured to suit specific applications, there is a section entitled Applications Examples.
Multiplexer Software Guide Version 4.9 Page 8 of 297
C H A P T E R
C O N F I G U R I N G
T H E
M U L T I P L E X E R
2 Configuring the Unit

2.1 Standard Configuration or Push-Config?
Chapter
All of the units may be configured manually using a menu system which is accessed using a PC or laptop. The computer can gain access to the menus either serially using the Monitor and Control port or via the Ethernet port using a Telnet session. These techniques may be used to set up both the locally connected unit and also any remote unit that is connected in the network and it relies on complete knowledge of how all of the relevant parameters must be set, against a background of default initial values which help to get the unit working with the minimum number of changes. As an alternative to the manual approach, V25, V50plus and V150 units may receive their configuration settings automatically from a hub unit using a mode known as Push-Config. In this case, the hub unit, which may be either a V200 or a V150, contains all of the configurations for the clients in the network and pushes them out using a proprietary protocol at start of day. These configurations are entered at the hub on a dedicated menu screen. By default, V25 and V50plus units start up in Push-Config mode and must be configured into Standard Configuration mode in order to be set up manually. Refer to section 4.4 Push-Config for details. The primary aim of Push-Config is to remove the need for multiplexer management skills from personnel in the field, whilst retaining the ability to dynamically change network operation. The ultimate aim is for a factory-defaulted multiplexer to be installed at a remote site, and automatically obtain its multiplexer settings when it is connected to the Vocality network. When in PushConfig mode, a remote unit obtains its configuration when it initially connects to a hub multiplexer therefore only basic serial aggregate connectivity to the hub unit is required in the remote unit configuration. Note that this feature is an optional enhancement to the existing management scheme. It is intended for remote sites in a hub-spoke type network (i.e. not mesh) where there is a single aggregate link in use at the remote site. A customer may continue with the manual configuration mode (where the remote multiplexer carries its own complete configuration) if the restrictions imposed by Push-Config operation are too inflexible.
2.2
The Port Addressing Scheme
Throughout the configuration of the Vocality multiplexer/router products, references are made to nodes, bays, slots and port numbers in the network. By convention, the addressing syntax used is NODE:SLOT:CHANNEL, where NODE is the Node ID, SLOT refers to a logical grouping of ports, often on the chassis or a particular card and CHANNEL refers to a specific port within a slot. This scheme is
C H A P T E R
T H E
interpreted according to the physical arrangement of each unit. The details specific to each product are given below. 2.2.1 The Node ID
The most important item in the multiplexers configuration is the Node ID. This is a unique number between 0 and 999 (however, 240-255 are reserved) which specifies each chassis in the network and it must be programmed into the unit before anything else. This is done on the SYSTEM menu see Section 2.4.2 for details. Once the Node ID has been programmed, the unit should be restarted since this allows it to clear all previous routing information and assume the new identity without confusion. NOTE: When a remote unit is configured for Push-Config (the factory default operation for all multiplexers except the V200 and V150), the Node ID is set via the Push Config Client menu screen. See section 2.4.14, The PUSH CONFIG CLIENTS menu. 2.2.2 2.2.2.1 The Slot and Channel Numbers V200 and V150
From the rear, the V200 is laid out as follows:
TX
TX
STATUS
STATUS
ALERT
ALERT
The V150 is laid out as follows:

M&C PORT BACKUP PSU
A SLOT is a number which maps a card in a physical bay to a logical slot via the Slot Management menu and CHANNEL is a number which indicates the particular channel number within that logical slot. By default Bay A is mapped to Slot 0, Bay B is mapped to Slot 1 and so on. See the table below:
PORT 1 1 2 STATUS M&C ETHERNET 2 ALARMS ETHERNET 1 ALERT
PORT 1 1 2 STATUS M&C ETHERNET 2 ALARMS ETHERNET 1 ALERT
CHANNELS 1-8
CHANNELS 1-8
RX
RX
1 STATUS 2
1 STATUS 2
PORTS 1 TO 4 STATUS
PORTS 1 TO 4
EXPANSION
EXPANSION
UTP STATUS
UTP STATUS
ALERT 1234 5678 ENET
ALERT 1234 5678 ENET
STATUS
ALERT
ALERT
DATA
DATA
100-240AC 47-63Hz
100-240AC 47-63Hz
CPU
CPU
DATA
DATA
E1/T1
E1/T1
A.C. PSU
A.C. PSU
A
MAIN PSU
A B Multiplexer Software Guide Version 4.9

Page 10 of 297
C H A P T E R
T H E
Bay A B C D E F G H I J
Default Slot mapping V150 V200 0 0 1 1 2 2 3 4 5 6 7 8/PSU2 PSU1
The configuration pages list local channels only, so they begin with a simplified version just using the slot and channel numbers, such as 0:1 and 0:2. So why use bays as well as slots? Bays are used as a means of identifying the physical position of a card within the chassis, whereas the slot number is purely a logical identity used to define a cards place in the addressing system. This allows a CPU card in Bay A to be defined as Slot 0, with its backup CPU card in Bay B, which is defined as the Slot 0 Backup Card and which is configured identically to the primary card. In this example Bay C could then house Slot 1 and so on. In fact, the only rule is that Bay A must house the Slot 0 primary card all other logical slots may be located in any other physical Bay, in any order. CHANNEL is a number which means the particular channel number within a slot. So, for example, the DB15HD connector labelled DATA on the Standard CPU card in Bay A(Slot 0) Node3, which happens to be the V150 above, would be indicated as 3:0:0, or voice channel 4 on same card would be called 3:0:4. The routing of voice channels is often done dynamically by decoding the DTMF dialling digits. In this case, the destination field is simply set to AUTO and the route is either directly decoded from the dialled digits or looked up in the internal directory. So, for example, if the directory number for 23:1:7 is 820, then when the number 820 is dialled from anywhere in the network, the telephone on channel 7 of the card in Option Card 1 in node 23 will ring. NOTE: This assumes the directory entry is configured on all multiplexers in the network.
C H A P T E R
T H E
2.2.2.2
V50plus, V25
The ports of the V50plus are grouped as follows:
Option Slot 1
The ports of the V25 are grouped as follows:
Option Slot 2 Slot 0 the chassis
Slot 0 The Chassis
Slot 1 the Voice ports
For V25 and V50plus systems the integrated router is on slot 0 and channels 0:10 through 0:31 are used to represent IP tributaries. The configuration pages list local channels only, so they begin with a simplified version just using the slot and channel numbers, such as 0:10 and 0:11. Voice channels in the V25 are assigned to logical slot 1 and all other ports are assigned to slot 0. The assignment is similar in the V50plus, although the option slot numbers more naturally represent the physical module that may be fitted at either end. For V150 and V200 systems on the High-Speed CPU cards, channels x:10 through x:99 are used to represent IP tributaries. On standard CPU cards, channels x:10 through x:31 are used to represent IP tributaries. Again for V150 and V200 systems, the integrated router may be in the system multiple times one for each CPU card (standard or high speed) installed. If IP is configured on a high speed CPU card in slot 3, the tributaries available are 3:10-3:99. If IP is configured on a standard CPU card in slot 0, the tributaries are 0:10-0:31.
C H A P T E R
T H E
2.3
2.3.1
Using the Supervisor or Management and Configuration (M&C) Port

User Interface
Vocality multiplexer/routers provide either a formatted menu control structure for interactive user control, or a simple Teletype mode for interface to a network management system. The use of the formatted M&C (supervisor) is described here; the Teletype mode is described in a separate manual supplement. In formatted mode, the unit is configured by moving around the menus using the cursor keys and selecting from a choice of available options for each parameter. The current cursor position is highlighted in most terminal emulations. There are also a number of keys, which may be used as a shortcut or to access additional features. The keys are summarised below, with key names represented between chevrons, e.g. <SPACE> for the spacebar, <CR> for Carriage Return or Enter. The unit is configured using an asynchronous terminal or PC running Windows 95/98/2000/XP/Vista HyperTerminal, connected to the dedicated port on the back panel marked "M & C". On the Connect To tab, HyperTerminal should be configured to use the COM port on the PC used to connect to the multiplexer and on the Settings tab, the Function, arrow and ctrl keys should be set to act as terminal keys:
C H A P T E R
T H E
Click on the Configure button to set HyperTerminal to operate at 9600bps, 8 data bits, no parity, one stop bit with no flow control:
The unit supports most common terminal emulations, such as VT100, VT52, TVI925 and will automatically detect the emulation in use. When the multiplexer is powered up with no passwords entered, it displays the initial banner shown below. (This menu may be returned to at any time by entering <CTRL>&<E>). Teletype mode may be entered at this time by typing <CTRL>&<T> twice (the commands and responses used in teletype mode are detailed in a separate manual). Once in Teletype mode, the above menu may again be returned to by entering <CTRL>&<E>. To use the full-screen formatted configuration display, proceed as described below. Once the unit has been configured for use in an IP network, the management menus may also be accessed via telnet.
C H A P T E R
T H E
2.3.2
Cursor Movement Move to parameter above the current cursor position. Move to parameter below the current cursor position. Move to parameter to the right of the current cursor position. Move to parameter to the left of the current cursor position. Select a menu Return to the previous screen Parameter Selection
<Up Arrow> <Down Arrow> <Right Arrow> <Left Arrow> <CR> <ESC> 2.3.3
Some parameters are selected by toggling around a sequence of choices, some are entered as alphanumeric characters. Context-sensitive instructions are given at the bottom of the screen. <+> or <Spacebar> <-> <Spacebar> at alphanumeric field <Characters> 2.3.4 Updating the Configuration Select next item in list Select previous item in list Clear field Enter literal data
When a menu has been edited, the changes are stored in non-volatile system memory by entering <ESC>, which prompts the user with this message: Save Changes (y/n)?
C H A P T E R
T H E
Responding with a <Y> will update the non-volatile memory. The changes may be abandoned by entering <N> instead. If at any time the user wishes to clear all configuration settings and start again from factory defaults, return to the terminal selection screen (Section 2.3.1) by entering <CTRL>&<E>, then enter <CTRL>&<R> three times, to which the unit will prompt: Set Factory Defaults and Reboot? To proceed, enter y. Any other key will abort. NOTE: This clears all the information stored in the numbered configuration stores and in the system configuration.
C H A P T E R
T H E
2.3.5
Password Protection
To prevent unauthorised access to the menus, the unit has three levels of password protection; Readonly, Read/Write and Superuser. The serial number is used in the password mechanism. By default, the units have no passwords configured, and there is no password required to access the supervisor port. The user can configure two levels of password through the SYSTEM menu. The first is for read-only (RO) access - the second is for read-write (RW) access. Once a RW password has been configured then any future access to the supervisor port (either local or remote) will encounter a request for a password before allowing access. If the RW password is entered, then the supervisor port works as before with full management functionality. If the RO password is entered, then the menu system is presented, but any changes made to the configuration will not be saved - also access to the debug menus and debug mode (and other shortcuts) are prevented. The RO password is only effective once the RW password is configured. Password entry is in a conventional format, with the entry being asterisked out and password setting requiring re-entry for confirmation. The password is case-sensitive. If the user forgets their configured password there is a backdoor mechanism to get them back into their units. This backdoor is the "superuser" password - it is unique for each multiplexer, and consists of an encrypted key based on the serial number. Once entered, the user is given normal read-write privileges to allow him/her to set the RW password to something that they can remember! A superuser password can only be supplied by Vocality International on the following telephone number: +44 1483 813120 Please be prepared to supply your name, company name and the serial number of the unit.
Status No password or default RO password entered RW or superuser password entered
Unit Response
Access rights
None Prompt for password Prompt for password
Full access to menus, terminal and debug mode Full access to menus but no configs can be changed no access to terminal and debug modes.
Full access to menus, terminal and debug mode
Users are encouraged to configure the ACCESS TIMEOUT on the SYSTEM screen to activate auto-logout. NOTE: Users are advised not to configure the ACCESS TIMEOUT to less than 10 seconds. Once a password has been entered it is effective until that session is completed with a CTRL-E command or the session is inactive for the configured access timeout. - i.e. a CTRL-E to escape to the top-level menu will require the user to re-enter the password (if configured) to continue.
C H A P T E R
T H E
In read-only access mode, the lines which divide the menu screens are composed of the tilde ~ character. (In default or read-write mode they use the hyphen -).
C H A P T E R
T H E
2.4
Menu Structure
Once the user has entered an UP ARROW cursor key on the terminal selection screen - and if the unit is not configured as a Push-Config client - the following page appears:
This is the Main Menu page. From here all of the submenu pages may be accessed by moving the highlighted cursor up or down and pressing <ENTER>. To return up the menu tree, press <ESC> at any time. The screen shown above is an example; the menu for each option card will only be shown if the card is fitted. All of the menu pages display the status lines at the top of the screen for information. At top left, the Node Name of the currently logged unit appears. Below the Vxxx Multiplexer Supervisor banner, the connection status of the aggregate links is displayed. For V200 and V150 systems, only the status of aggregate ports on slot 0 is shown. The status of aggregate ports on other slots can be seen by accessing the menus for those slots. In the example above, chassis data port 0:1 is configured as an aggregate and has lost connection with a remote unit. Below this, the third line confirms the current menu page. The right-hand corner of the top line is also used for important status messages. For example, the V200 and V150 CPU card redundancy scheme will indicate when backup synchronization is required (BACKUP SYNC REQUIRED). See the section The BACKUP SYNCHRONIZATION menu for more information. At the bottom of the screen, the active configuration store (one of seven) is shown and on the final line, a context-sensitive help line guides the user as to what may be entered in the current field.
C H A P T E R
T H E
2.4.1
The MAIN menu
The default MAIN menu for the V25, V50plus and V150 systems is shown below:
If this remote system is connected to a Vocality multiplexer network and if the hub system has been configured to include this Push-Config client, the appropriate configuration is pushed to this remote client enabling this system to connect to other multiplexers on the network. See section 2.1, Standard Configuration or Push-Config? and section 4.4, Push-Config for more information. If you wish to configure the multiplexer locally and do not wish to use the Push-Config feature, select START-UP CONFIGURATION. The following screen is displayed:
C H A P T E R
T H E
Change the Mode from Push Config to Normal. Press <ESC>, then y to save the changes. The full menu system is then displayed:
C H A P T E R
T H E
2.4.2
The SYSTEM menu
REAL TIME CLOCK

NOTE: V200 and V150 only Sets the time and date of the real time clock. Once the time and date have been set, this is used by the real time clock to ensure the multiplexer always shows the correct time and date. This information is not lost during a reset or a default configuration.
NODE NAME
The SYSTEM SETTINGS menu allows the user to define a name for the chassis, which appears at the top left-hand corner of the screen and is used to address the unit in Teletype mode. This may be alphanumeric but must start with a letter.
NODE ID
The I.D. number specifies the chassis and must be unique within the network; the multiplexer uses it to route packets to the correct destination. This number must be entered explicitly into each unit before the network is configured and cannot be entered remotely. All other fields (except the Configuration By Remote field see below) may be edited locally or remotely.
C H A P T E R
T H E
CONFIGURATION BY REMOTE
Allows or prevents other users on the network from configuring this multiplexer via remote configuration. The Configuration By Remote field may only be set locally since this prevents remote tampering.
MLPP COMPATIBILITY
In order to implement the MLPP functionality it has been necessary to add extra parameters to various call control messages. This means that an MLPP enabled system is not compatible with pre-4.8.X versions of software. In order to retain compatibility with these systems an additional item MLPP COMPATIBILITY has been added to the system screen, the default for this option is OFF. If the Compatibility option is set to OFF, the software will still be able to communicate with older software variants however the MLPP functionality will be disabled and access to the MLPP configuration screens will be blocked. If the option is turned ON, the MLPP functionality will be available however the unit will no longer communicate with any connected units running older software. In order for the MLPP functionality to work, all participating units must have this option switched ON.
COUNTRY
Five country selections are available to allow the user to tailor the ring cadence and comfort tones of the voice channels to suit national standards.
PROGRESS TONES
Call progress tones are generated by the multiplexer for voice calls connected through the system. These indicate when a call is ringing, connecting and busy. Previously, the tones generated by the Vocality multiplexer have been a proprietary set of frequencies and cadences these are known as VOCALITY progress tones. The tone can now also be set to COUNTRY these are the standard set of frequencies and cadences for the COUNTRY parameter that is also configured on this page.
CONNECTION TIMEOUT
Data paths in a multiplexer network are managed in terms of connections. When a telephone is lifted and a destination channel number dialled, a connection request is processed by the routing software and either accepted or rejected according to the existing link traffic. The CONNECTION TIMEOUT parameter allows the network manager to optimise the timeout before the multiplexer rejects the request. This can be adjusted to allow slow-response networks (e.g. DAMA) time to connect.
RECEIVE READY FILTER

In satellite systems there is often a Carrier Detect or Receiver Ready signal returned by the network when the connection is made. In SWITCHED carrier modes (see Data Configuration), this is used by the
C H A P T E R
T H E
multiplexer as an indication to proceed. The signal produced by satellite modems can be unstable during the initial stages of carrier acquisition and so a programmable filter is provided to guarantee the Receiver Ready signal is steady before the multiplexer sends connection messages across the link.
DATA CHANNEL ACTIVATION

Connections for data channels in the multiplexer network are always point-to-point. In other words, however complex the route taken from say, terminal to computer, a permanent connection is still set up between the two devices. Here, the DATA CHANNEL ACTIVATION option is left in its default state of Auto. In some cases, it may be desirable for the connected terminal equipment to switch the bandwidth on only when required; in this case the DATA CHANNEL ACTIVATION option may be set to Flag, such that the connection is set up when the terminal affirms the RTS signal (or equivalent in V.11, RS449 or V.35 modes) into the port. This allows more flexible interworking with voice and DBA data channels.
DATA CHANNEL FLAG

In a similar way, the DATA CHANNEL FLAG setting allows the user to select how the CTS (or equivalent) signal from the multiplexer reacts. It may be set permanently on, to activate only when the connection is made or to reflect the state of the RTS signal at the remote port.
TIE-LINE ACTIVATION
This item only appears when voice channels are fitted. For voice channels, the TIE_LINE ACTIVATION field specifies how Tie-line bandwidth is requested. In Auto mode, a permanent connection is made which takes bandwidth all the time. When set to M-lead, connections are made only when the M-lead is seized, thereby yielding bandwidth when not required. M-lead & Back Busy was developed to overcome a failing in system topologies which are indirectly connected to a remote analogue PABX. Such systems in the multiplexer network could take the form of a unit connected via an intermediate node, where the carrier status of the overall link is unknown. In such a case the call is placed by the local PBX, which sees the local port is free and raises the M-lead. The local unit tries to connect to the remote port but the connection fails because a link along the way is down. To the calling PBX, the call status is unknown because there is no feedback and the user hears nothing. To avoid this frustrating phenomenon, the M-lead & Back Busy selection was designed. Here, the local port issues pings every 30 seconds from mapped Tie-Line ports (provided the system Tie-Line Activation mode is set to "M-Lead & Back Busy" and the Tie-Line port has an algorithm selected). The remote port responds to this ping if it is free. The local port checks for Ping Response timeouts (45 seconds) and asserts a Back Busy request. If the port is in the idle state the Back Busy state is immediately translated into the E-Lead signal. So, the state of Back Busy is translated to the E-Lead signal, unless the port is turned off in which case the E-Lead signal is affirmed (busy). This provides the following features on mapped Tie-Line Voice channels: Back Busy will be asserted between 15 and 45 seconds after loss of communication
C H A P T E R
T H E
Back Busy will be disaffirmed between 0 and 30 seconds after communication is restored. A manual Back Busy facility is activated by turning the coder algorithm off.
ASYNC BUFFER SIZE

The ASYNC BUFFER SIZE field allows the user to optimise the number of 100mS input buffers used by asynchronous channels. This can be useful when channels are used for remote internet access which is made at a negotiated rate and cannot be controlled.
JITTER TOLERANCE
The size of jitter buffers used for voice channels and constant bit-rate (CBR) data tributaries can be independently configured via TTY commands (contact your Vocality support representative for details). It is also possible to increase the size of all jitter buffers in the system via this parameter in the SYSTEM menu. If all tributaries are using aggregate links with a significant jitter (> 10ms), the JITTER TOLERANCE parameter should be set to represent the network jitter. This will automatically increase the jitter buffer size implemented for all voice and CBR data tributaries, at the expense of throughput delay.
PASSWORDS
The RW and RO passwords allow the user to enter personal codes to restrict supervisor access to ReadWrite or Read-Only. In both cases, the code must be followed by a carriage return and then entered a second time for confirmation. The new password is saved when the screen is exited in the normal way. Once a password is entered, the user is prompted to enter it when first logging on to the system before any access is granted to the menus. Refer to Section 2.3.5 for details.
ACCESS TIMEOUT
As an additional security feature, if either an RW or an RO password has been set, the ACCESS TIMEOUT parameter allows the user to specify a period of keyboard inactivity after which menu access is denied. When this happens, the user is logged off and the following message is displayed: Password Access Expired.... Re-Enter Password for Node0: This feature can be turned off by entering a value of zero seconds.
ACTVITY TIMEOUT
The ACTIVITY TIMEOUT is relevant to dial-up links only. When configured, it sets the aggregate dial-up links activity timeout period. After the specified period of inactivity the dial-up link is dropped. This feature can be turned off by entering a value of PERMANENT.
C H A P T E R
T H E
BACKUP TIMER
This timer allows the user to control how long it takes following the detection of an aggregate failure for the route to use the backup path. This timer defaults to 40 seconds.
FALLBACK TIMER
This timer allows the user to control how long it takes following the detection of an aggregate recovery for the route to use the fall back to the original path. This timer defaults to 40 seconds.
POE PSU RATING

NOTE: Power over Ethernet is not supported by the V25 This field allows the user to configure the rating of the external power supply used with the VI68054/PoE Power over Ethernet (PoE) option module, when fitted. Power supplies differ in rating so please refer to the specification of the power supply you are using to determine the value you should enter here. This value is used by the POWER OVER ETHERNET menu in the DIAGNOSTICS menu to calculate how much power is available for additional devices.
The parameters and options available on the SYSTEM menu are shown in the following table:
Field
REAL TIME CLOCK
Options
hh:mm:ss dd/mm/yyyy or hh:mm:ss mm/dd/yyyy when in US mode Any Alphanumeric string up to 8 characters 0-999 numeric 240-255 excluded Enabled,
Description
V200 and V150 only Displays the current time and date for the multiplexer, and allows a new time and date to be entered Allows the user to enter a convenient network name for the chassis. Also used as identifier in Teletype Mode Network I.D. for this chassis. MUST be unique Configuration settings may be changed by another unit in the network Configuration settings may only be changed at the local unit Unit will operate the MLPP protocol but not communicate with older software versions Unit will not operate the MLPP protocol but will be able to communicate with older versions BT standard ringing cadence AT&T standard ringing cadence France Telecom standard ringing cadence Deutsche Telecom ringing cadence
NODE NAME
NODE ID CONFIGURATION BY REMOTE
Inhibited MLPP COMPATIBILITY On,
Off
COUNTRY
UK, US, France, Germany
C H A P T E R
T H E
Field
PROGRESS TONES
Options
Australia Vocality COUNTRY
Description
Telstra ringing cadence Use the Vocality proprietary tones Use the standard tones for the configured COUNTRY (above) Number of seconds after which a connection request is rejected Number of seconds from assertion of RR after which signal is accepted Connection is made when one end is mapped Connection only is made when one end is mapped AND C lead affirmed at both ends Channel output signal always asserted Channel output signal asserted when connection is established Channel output signal follows remote input signal transparently Channel output signal disaffirmed during alarm conditions Connections are only made when the M-Lead is seized Same as above but pings are used to check the link status. See the section TIE LINE ACTIVATION above for details Permanent connection is made which takes bandwidth all the time. Number of 1K buffers used by data channels in async mode Global addition to size of tributary jitter buffers Read-Write access password Read-Only access password
CONNECTION TIMEOUT RECEIVE READY FILTER DATA CHANNEL ACTIVATION
10-255 numeric entry 0-255 numeric entry Auto, Flag
DATA CHANNEL FLAG
Always On, Follows Connect, Follows Remote, Follows Alarms
TIE LINE ACTIVATION
M-Lead M-Lead & Back-Busy
Auto ASYNC BUFFER SIZE JITTER TOLERANCE RW PASSWORD RO PASSWORD ACCESS TIMEOUT 8-256 numeric entry 0-1000ms Alphanumeric entry Alphanumeric entry 0-86400 numeric
ACTIVITY TIMEOUT
BACKUP TIMER FALLBACK TIMER
PoE PSU RATING
Supervisor keyboard timeout period. if either an RW or an RO password has been set, 0 = Permanent access (default) 1-86400 = Seconds as entered PERMANENT PERMANENT = Permanent supervisor access 0-86400 numeric This sets the aggregate dial-up links activity timeout period. 0= immediate timeout 1-86400 = Seconds as entered 0-600 seconds Delay before switching to backup aggregate path Delay before falling back to original 0-300 seconds, aggregate path Do not fall back NEVER, Restart the fallback timer RESET V150 and V50plus with PoE option only 0-250 watts This sets the rating for the power supply used with the PoE option
C H A P T E R
T H E
2.4.3
The CONFIGURATIONS menu
The unit supports multiple configuration stores which allow up to seven different configurations to be stored on the multiplexer. The selection of which configuration is being edited or used at any time is made in the CONFIGURATIONS menu. There are also options for copying and deleting configurations. The screen for the V200 is shown below:
The screen for the V150, V50plus and V25 multiplexers is shown below:
C H A P T E R
T H E
CONFIGURATION MODE
CONFIGURATION MODE determines whether the remote multiplexer uses the Push-Config functionality to enable the unit to be remotely configured or whether the configuration mode is set to Normal to allow the unit to be configured locally.
ACTIVE CONFIGURATION#
The ACTIVE configuration is the one currently being used by the multiplexer. The CONFIGURATION# identifies the configuration number. Seven configurations may be stored (1-7). NOTE The ACTIVE configuration and the EDIT configuration can be the same. When this happens, all configuration changes take effect immediately the <ESC>, <y> key sequence is used to save the configuration.
EDIT CONFIGURATION#
The EDIT configuration is the one that will change as a result of any parameter changes on the menus. For example, if parameters on the Clocking Menu are changed, those changes are saved in the configuration identified here. The CONFIGURATION# identifies the configuration number. Seven configurations may be stored (1-7). NOTE The ACTIVE configuration and the EDIT configuration can be the same. When this happens, all configuration changes take effect immediately the ESC key is used to save the
C H A P T E R
T H E
configuration. When the ACTIVE configuration and the EDIT configuration are different, changes made to parameters are stored in the specified configuration number but the effects of those changes are not seen until the edited configuration is made the ACTIVE configuration.
COPY CONFIGURATION#
A configuration can be copied to another configuration. This is useful when you want to make some network configurations but want to have the option of reloading a known good configuration should the changes prove unsuccessful. The COPY configuration specifies the number of the configuration you want to make a copy of. The CONFIGURATION# identifies the configuration number. Seven configurations may be stored (1-7).
TO CONFIGURATION#
The TO configuration specifies the configuration that is overwritten with the COPY configuration (see above). The CONFIGURATION# identifies the configuration number. Seven configurations may be stored (1-7).
FACTORY DEFAULT CONFIG#

The FACTORY DEFAULT configuration specifies the configuration to be overwritten with the factory default settings. The CONFIGURATION# identifies the configuration number. Seven configurations may be stored (1-7). NOTE: If the ACTIVE configuration and the FACTORY DEFAULT configuration are the same, network connectivity may be lost until a valid configuration is entered.
CONFIGURATION#
The CONFIGURATION# identifies the configuration number. Seven configurations may be stored (1-7).
SIZE
The configuration size is shown in bytes.
DESCRIPTION
A description may be given to a configuration number to help identify it.
C H A P T E R
T H E
Field
CONFIGURATION MODE
Options
Push Config Normal
Description
On connection with the network, the multiplexer is given a configuration by the hub unit. The multiplexer may be configured locally using the menus described in this manual. The number of the Configuration currently being used. The number under which to save the Configuration currently being edited. Note: if the ACTIVE CONFIGURATION# is different from the EDIT CONFIGURATION#, the changes being made to the configuration will have no effect until the ACTIVE CONFIGURATION# is set to the EDIT CONFIGURATION#
ACTIVE CONFIGURATION# EDIT CONFIGURATION#
1-7 1-7
COPY CONFIGURATION# TO CONFIGURATION# DEFAULT CONFIGURATION#
1-7 None 1-7 None 1-7 None
The number of the Configuration currently being copied. No Configuration is currently being copied. The number the Copied Configuration will be saved under. No copy will take place. Set the Configuration specified back to the factory default settings. No Configuration is currently being set to the factory default settings. The configuration (1-7). The size in bytes of the configuration file. Up to 55 characters used to identify the configuration.
CONFIGURATION# SIZE DESCRIPTION
Information only Information only Alphanumeric text
C H A P T E R
T H E
2.4.4
The CLOCKING menu
The clocking menu specifies how the GRX and GTX clocks in the Multiplexers are driven. These are reference clocks that allow data and voice ports in different multiplexers to be driven from a common clock to prevent clock slip problems. Two configurations are given; the Primary for the preferred clock configuration to be used and the Backup for the clock configuration to be used in the event of primary clock failure. If no backup is specified, the primary clock configurations are used at all times.
SOURCE TYPE
Configures the source for driving the GRX and GTX system clocks. NOTE: V25 does not support GTX. NOTE: When a digital voice card is present, this can also be set to E1/T1/J1.
SOURCE CLOCK
When the SOURCE TYPE is configured to DATA, SOURCE CLOCK specifies which data interface clock is driving GRX or GTX. When SOURCE TYPE is configured to IP AGG, SOURCE CLOCK specifies the name of IP Aggregate driving GRX or GTX. The names of the IP aggregates configured in the IP AGGREGATES menu are given in list format and are selected using the SPACE bar or the + and keys. For all other values of SOURCE TYPE, the SOURCE CLOCK field is not used.
C H A P T E R
T H E
NOTE: When a digital voice card is present and SOURCE TYPE is set to E1/T1/J1, SOURCE CLOCK is set to slot:x The parameters and options are shown in the following table:
Field
GRX SOURCE TYPE
Options
Internal Data
Description
GRX system clock is driven from a clock within the system. GRX is driven from a clock on a serial data port. When this is selected, the SOURCE CLOCK is selected from a list of installed data ports. GRX is driven from a clock reference received on an IP aggregate. When this is selected, the SOURCE CLOCK is selected from a list of configured IP Aggregates. GRX is driven from the digital voice card.
IP AGG
E1/T1/J1 SOURCE CLOCK None Slot:Channel Text Slot:x
When Source is set to Data, the data slot: channel must be selected from a list of valid data ports. When Source set to IP AGG, select the name from the list of configured IP Aggregates. When GRX Source Type is set to E1/T1/J1, the SOURCE CLOCK is selected from a list of installed digital voice cards. GTX system clock is driven from a clock within the system. GTX is driven from a clock on a serial data port. When this is selected, the SOURCE CLOCK is selected from a list of installed data ports. GTX is driven from a clock reference received on an IP aggregate. When this is selected, the SOURCE CLOCK is selected from a list of configured IP Aggregates. GTX is driven from the digital voice card.
GTX SOURCE TYPE
Internal Data
IP AGG
E1/T1/J1 SOURCE CLOCK None Slot:Channel Text Slot:x
When Source is set to Data, the data slot: channel must be selected from a list of valid data ports. When Source set to IP AGG, select the name from the list of configured IP Aggregates. When GTX Source Type is set to E1/T1/J1, the SOURCE CLOCK is selected from a list of installed digital voice cards.
The clock source failure and recovery conditions are summarized below:
Type Data IP E1/T1/J1 Internal
Failure Calibration reports a missing clock No clock sync packets received from far end Framer reports Loss of line interface transmit clock None
Recovery Calibration reports a non-zero clock rate Clock sync packet received from far end Framer clears previous Loss of line interface transmit clock N/A
C H A P T E R
T H E
An additional failure and recovery mechanism is available for data and IP aggregate ports. This additional mechanism provides an interaction between route backup and clock synchronization. A switch to the secondary clock source will occur if all the following conditions are true: A secondary route is configured (see Route Back-up section for more details) The primary reference clock source is the serial data port or IP aggregate used in the primary route The primary route is considered to have failed and the router switches to using the secondary route.
In this case the secondary clock reference source will continue to be used until the router switches back to using the primary route. The conditions under which this happens are described later (in the route backup section). Note that there is no requirement for the backup clock source to be related to the backup route aggregate. 2.4.4.1 Clocking and Push Config
A secondary reference clock source configuration is included in the client configuration as part of the pushconfig scheme. The push-config client controls the selection of the secondary clock under the normal failure and recovery rules.
C H A P T E R
T H E
2.4.5
The ROUTING menu
The routing menu describes the mechanisms the multiplexer uses to direct traffic across a network. The principle of the routing table is to configure which aggregate is used to reach a particular destination. The destination is typically a target node number, but can also be a target slot or channel number if traffic to different channels within slot, or slots within a node are to traverse the Vocality network along different paths. The following example shows a V200 routing setup with a leased satellite service, IP aggregate interconnecting three V200 units. The units are labelled Node1, Node2 and Node3. A leased satellite service connects Node1 (port 0:1) to Node2 (port 0:1). An IP aggregate connects Node2 to Node3. On Node2 this IP aggregate is configured with the name Node3. On Node3 this IP aggregate is configured with the name Node2. For full connectivity between all V200s in the network, each node must contain a route to each other node in the network.
Node1 routes all traffic via the leased satellite service on port 0:1.
C H A P T E R
T H E
Node2 uses the IP aggregate to Node3 to communicate with Node3. Traffic to Node1 is routed via port 0:1:
C H A P T E R
T H E
Node3 uses the IP aggregate to Node2 to reach Node1 and Node2:
It is necessary to enter the routes to all nodes since any chassis only has knowledge of its immediate neighbours; the address in the data packets contains the full destination port address so by consulting the routing table, every node can determine the next route to the destination even if it is to an intermediate node, no matter how many nodes there are in the network. The Vocality architecture allows a maximum of 999 chassis to be interconnected in a single network and individual routing information must be entered into each chassis when the network is commissioned. Once all the data has been entered, the entire network may be managed from any node the remote supervisor function depends on the routing tables as well! Three options are presented on the ROUTING page, each of which may be accessed using the conventional cursor keys and selected using the <space> bar. The typical entry sequence is as follows: STEP 1 STEP 2 Select <DELETE ALL ROUTES> to clear all entries and start afresh. Select <NEW ROUTE> to create a new entry line in the table. This may
then be accessed using the cursor keys to enter data. Repeat this step until all routes has been entered. STEP 3 end of each group. Select <TIDY LIST> to regroup the entries in a logical order. All routes
from each node are arranged in ascending order, with any specific channel routes from each node at the
C H A P T E R
T H E
NOTE: It is not necessary to use the ROUTING menu for simple point-to-point networks. The complex example above requires the user to specify particular routes other than those that the multiplexer will automatically work out. The multiplexer uses a technique called implicit routing to automatically establish the most direct aggregate route to adjacent nodes. Any configured routes are overlaid on top of the implicit routes; any duplicate implicit routes are replaced. In this way, by starting with implicit routes, the entries required to set up even a complex network are minimised and the routing tables are kept as simple as possible. Implicit routing is not available over IP aggregates or switched aggregate links. The parameters and options for the ROUTING menu are shown in the following table:
Field
NAME NODE
Options
Text Field 0-999 numeric ANY BRD
Description
Provides an identifying name for the route Identity of node to which traffic will be routed (240255 reserved) Any of the available nodes. Traffic to be broadcast to many remotes is routed to the port specified by the AGG field (see below). This is used for the broadcast voice feature. The broadcast traffic may be routed to any number of aggregate ports this way. Identifies the slot within the specified node which traffic will be routed to. Any of the available slots on the target NODE. Identifies the channel within the specified SLOT on the specified NODE which traffic will be routed to. If specified then the SLOT must contain a specific slot number. Any of the available channels on the target SLOT on the target NODE. Identify the aggregate to use to route traffic to the target NODE:SLOT:CHAN No aggregate configured Route using an IP aggregate. The CONNECT USING field specifies the name of the IP aggregate to use. Identify ISDN BRI S/T interface to use to route traffic to the target NODE:SLOT:CHAN Only used for routes using IP aggregates. For an IP aggregate route this is the name of the IP aggregate to use this must match the name of a configured IP aggregate. For future use. For future use.
SLT
0-99 ANY
CHAN
0-999
ANY AGG Dev: Chan IP Dev: ST(1-4) CONNECT USING Text
ALTERNATE SEC
Text Text
Note that more specific routes (i.e. those with specific channel and slot targets) always take precedence over least specific routes.
C H A P T E R
T H E
2.4.5.2 2.4.5.1.1
Secondary Routing Overview
The route backup feature allows the multiplexer router to route traffic down an alternate aggregate if the path that is normally used fails. Once the original path recovers, traffic is routed back along the primary path. The following rules apply to this route back-up feature: Primary aggregate is non-switched point to point data aggregate or IP aggregate Secondary aggregate may be any aggregate type (including switched data & IP) An aggregate used as a secondary route may be the primary or secondary path for other routes
Providing route back-up for shared outbound links is another possible future enhancement. The problem here is again down to detecting when the outbound path has failed. The failures that cause the back-up to the secondary route and the recoveries that initiate the fallback to the primary route depend on the type of aggregates used. They are detailed in the Failure & Recovery sub-section below. Tributaries that are established via a route when a back-up or fallback switch occurs for that route are automatically disconnected. These tributaries will re-connect if the connection attempt is retried once the route switch has occurred. Tributaries that are already established on an aggregate (via a route) remain connected when another route switches to use that aggregate. Note that in this case, the additional bandwidth load of the tributaries that have been switched may alter the performance of the already established connections. Once a secondary route is in use, the fallback to the primary path will only occur if the primary path recovers. If the secondary path fails the route remains via the secondary path. 2.4.5.2.1 Configuration
The second row in each route table entry is used to allow the user to specify the aggregate to use for the backup link. A SEC mode of BACKUP is the normal mode used. BoD is to be used when an ISDN data aggregate is used for the backup facility. The SYSTEM menu includes the BACKUP and FALLBACK TIMERS which allow the user to control how long it takes following the detection of an aggregate failure or recovery for the route to use the backup path or fallback to the primary path. These timers both default to 40 seconds. Primary and backup aggregates may be used on different slots. Note however that the primary and secondary aggregates must be on the same node.
C H A P T E R
T H E
2.4.5.2.2
Failure & Recovery
Failure and recovery conditions on the primary link control how and when the secondary route is used. The failure and recovery conditions used depend on the primary aggregate in use. Routes are removed and re-installed with the appropriate aggregate connection and backup and fallback occur. 2.4.5.2.2.1 Data Aggregates
The mechanism to detect link failure on the data aggregate must be able to identify a half-duplex failure. The existing frame sync protocol determines when an inbound link has failed. The secondary routing v1 operation halts the outbound frame sync protocol when the inbound mechanism fails however this requires frequent fallback attempts in order to allow the primary to recover this can lead to the aggregate bouncing when the path fails in one direction. To overcome this, the frame sync protocol conveys the health of the return links on point-to-point serial aggregates. For this to work successfully, units at both ends of a link must be running the same software for the link failure detection to work. However, the aggregate link itself will work between a unit running the enhanced frame sync protocol and one running the older version. The backup is initiated if either the inbound or outbound path is determined to have failed. Inbound failure detection is based on not receiving Frame Sync protocol packets for the AGGTO (configurable via TTY mode) period. Outbound failure detection based on the peer not receiving Frame Sync protocol packets for its AGGTO period. The frame sync protocol continues to run on the failed link to allow the recovery to be detected. The link recovery is simply the successful reception of the frame sync protocol that indicates a good bidirectional data path. 2.4.5.2.2.2 IP Aggregates
IP aggregate failure is identified when the clock management protocol fails between IP aggregate peers. A recovery condition is considered to be when we start to receive these clock management protocol packets again. Note that there is no half-duplex detection available here. 2.4.5.2.3 Status, Logs & Alarms
An entry in the configuration trace log is generated for each switchover or fallback. An alarm is already generated on aggregate failure. 2.4.5.3 Push Config
Secondary routing is not available in a push config scheme. The routing table is not directly distributed to the push-config client. Normal configuration mode must be selected on the remote nodes, and secondary routes installed through the router menu.
C H A P T E R
T H E
2.4.6
The SIP GATEWAY menu
SIP gateway is enabled via a feature key. Feature keys may be purchased for various numbers of SIP User Agents (UAs). If there are no SIP UAs on this product (i.e. no SIP UA feature key has been entered), this menu is empty.
C H A P T E R
T H E
2.4.6.1
The SYSTEM menu
The System sub-menu provides control of parameters that apply to the entire SIP gateway (i.e. they are not UA-specific):
MODE
Specifies whether the gateway is enabled or not. It takes the values Gateway or Disabled
FULLY QUALIFIED DOMAIN NAME

Allows the user to specify a name the SIP gateway uses for identifying its UAs. If not specified, the gateway uses the IP address configured on the first Ethernet port.
SIP TRANSPORT
A read-only field that indicates SIP is run over UDP.
THE RE-REGISTRATION INTERVAL

Specifies the frequency at which a UA will re-register with its configured registration proxy. Note that the actual period used may be over-ridden by the SIP registration proxy itself.
C H A P T E R
T H E
PROTOCOL LOGGING
Protocol logging is provided to enable the generation of verbose trace logs to help debug call set up issues. Each SIP packet received or transmitted is collected in the SIP trace log when this is enabled. It is intended that this only be enabled by field engineers when debugging problems, as there is considerable processing overhead to leaving it permanently enabled. 2.4.6.2 The CHANNEL SUMMARY menu
The UA configuration is accessed via two separate menu screens. The channel summary screen shows a line for each UA present. It shows the user-id (Name), and configured destination for each channel present.
Select the <VIEW> button of the appropriate entry to see the Channel Details. A description of the fields used here can be found in the Channel Details menu description.
C H A P T E R
T H E
2.4.6.3
The CHANNEL DETAILS menu
The channel details menu screen contains a page for each SIP UA channel present. The example screen below shows the Channel To Edit is set to COMMON. This setting allows common values to be configured for all UAs in the SIP gateway. It is used to set the IP TOS, Outbound Proxy, Registration Proxy, Auth Login ID, Alt Auth ID, Auth Password and Algorithm. If one of these values is changed for an individual channel then that channel will no longer pick up a change to the common value. An individual channel can revert to the common channel settings by pressing Ctrl-D when editing that channel in the details page. When the Channel To Edit is set to a specific channel, all items on the screen may be set.
CHANNEL TO EDIT
Shows which channel we are currently displaying/editing. Changing this selection automatically changes the page display to the selected UA.
USER-ID (AOR)
Allows the configuration of the user ID to use for setting the AOR (Address Of Record)) for this UA.
C H A P T E R
T H E
DESTINATION
Specifies the peer location in the Vocality network to map calls received on this UA to. The default setting is AUTO, which indicates that received calls are to be processed through the directory table and automapping procedure.
SIP PEER URI

Allows the user to configure a fixed entity in the SIP network to forward all outgoing call on this SIP UA to. It effectively provides a long-line extension feature into the SIP network.
IP TOS
Specifies the IP TOS field (in hex) to use for voice packets generated into the SIP network from this UA.
OUTBOUND PROXY
The location (DNS name) or address of the SIP proxy server all calls made out of the SIP UA are forwarded through if the SIP PEER DEST or SIP DIRECTORY TABLE is not used.
REGISTRATION PROXY
The location (DNS name) or address of the SIP registration server this UA should attempt to register with. If left blank no registration occurs.
AUTH LOGIN ID
Takes the values UserID or AltAuthID. It specifies whether the UA should use the configured UserID or separate Alt Auth ID when attempting to authenticate this UA.
ALT AUTH ID
The alternative authentication ID to use when the Auth Login ID is set to AltAuthID.
AUTH PASSWORD
Password used during authentication of this SIP UA. This should be left blank if no authentication is required.
ALGORITHM
Specifies the voice coder type to use for calls through this SIP UA. Supported values are G.729A 8K, G.711A 64K and G.711u 64K.
C H A P T E R
T H E
In addition, a page is shown for the common channel configuration.
C H A P T E R
T H E
2.4.6.4
The SIP DIRECTORY menu
The SIP directory is used to map SIP destination addresses into the Vocality network numbering scheme. It is typically used for simple SIP outbound call routing when no outbound proxy is available:
Each line in the table represents a single SIP destination. The destination field is the complete URI for routing the call to. The Directory Number specifies the called number that must match to route the call to this SIP destination.
C H A P T E R
T H E
2.4.7
The FEATURE KEYS menu
The feature keys menu allows the entry of encrypted keys which enable enhanced features in the multiplexer. Two types of keys are supported permanent keys are purchased to permanently enable the features. Temporary keys are available to trial test a feature. They are active for up to 24 hours or until the multiplexer is restarted. Please contact Vocality International to obtain the appropriate keys for your units.
Select the feature you want to enable and then enter the key provided by Vocality in the appropriate field. Press <Enter> to accept the key. The permanent keys are based on the serial number on the backplane of the multiplexer. Therefore the keys remain valid even when cards are swapped out or system control changes from the active to backup card. NOTE: The TCP Gateway (PEP) feature key and the SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) feature key are built-in (automatically supported) on the V200 only. For all other products, these features keys must be purchased. Once a feature key has been purchased and correctly entered, the State changes from LOCKED to UNLOCKED. NOTE: For the SIP Gateway UA Count feature, both the correct UA Count and the corresponding Key must be entered before the feature is UNLOCKED (useable).
C H A P T E R
T H E
2.4.8
The CALL ROUTING menu
The call routing menu provides access to sub-menus that provide configuration for the call routing services in the multiplexer.
C H A P T E R
T H E
2.4.8.1
The HUNT GROUPS menu
Hunt groups allow voice calls to be routed to an available port within a configured group of ports. The hunt group feature makes it possible to route a call to an available port within a hunt group and allow the generation of an outgoing DTMF digit stream on the available port if required. This provides for hot-line extension into a PBX or PSTN. A hunt group can be configured to ring the first available phone (FirstAvailable), or all available phones (RingAll), or it can be configured to call the first available phone but if all phones are busy, a call back will be made to the caller as soon as a phone is available (RingBack). Once a hunt group is defined, it can be used as a destination for a voice call - either through directory routing, AUTO DTMF routing, or hot-line configuration. The address of a hunt group is node:HG:[1-n]. See the appropriate menu in this chapter for more information.
HG TO EDIT/VIEW
This is the primary selection field which allows any of the currently configured Hunt Groups to be displayed. The format for Hunt Group names is HG:1, HG:2, and so on.
C H A P T E R
T H E
OUT DIAL STRING

This is blank by default and can be configured with up to 25 digits. Supported digits are 0 1 2 3 4 5 6 7 8 9 # $ ,. The string is dialled on FXO or digital voice hunt group members when attempting to connect through the hunt group. A comma adds a 1 second delay in the dial string. For example, the dial string 9, 1234 dials the digit 9, pauses for 1 second, then dials 1234.
OPERATION MODE
There are three operating modes: first available, ring all, and ring back. First available is the default and in this mode, the call is connected to the first detected available port. Ring all mode is used with FXS ports only. In this mode phones connected to all the FXS ports that are members of the hunt group are rung together. When a phone is picked up, the call is connected and all the other phones stop ringing. The ring back mode can only be used with originating ports configured as FXS although the hunt group member ports may be either FXS or FXO. In this mode, if the call cannot be completed because all ports are busy, as soon as a port is available, a callback is made to the originating port causing it to ring and a connection is made upon answer.
MEMBER LIST
A hunt group can have voice port members from the multiplexer the hunt group is configured on, or from other systems in the network. These members may be FXS ports, FXO ports, or digital voice channels. Typically, however, they will be located in the local chassis. The location of each member port of a hunt group is configured in the member list in the form node:port:channel.
SOFT KEYS
Four soft keys manage the addition or deletion of members within a Hunt Group and the addition or deletion of Hunt Groups completely. <ADD MEMBER> is used to include a new element within the currently selected Hunt Group; <DELETE MEMBERS> empties a Hunt Group of all its members; <ADD NEW GROUP> appends the next sequential Hunt Group number to the end of the list; <DELETE GROUP> removes the currently selected Hunt Group from the list. These keys are activated by positioning the cursor and typing the space bar.
Field
HG TO EDIT/VIEW OUT DIAL STRING
Options
HG:1, HG:2HG:n Up to 25 digits: 0 1 2 3456789#$,
Description
Selects a configured Hunt Group DTMF digit string dialled on FXO hunt group members when attempting connection through a hunt group. 0 1 2 3 4 5 6 7 8 9 # $ are valid DTMF digits. A comma adds a 1 second delay in the dial string.
C H A P T E R
T H E
OPERATION MODE
FirstAvailable RingAll
Default. In this mode, the call is connected to the first detected available port. Used with FXS ports only. In this mode available (non-busy) phones connected to all the FXS ports members of the hunt group are rung together. When a phone is picked up, all the other phones stop ringing. Used only with originating ports configured as FXS although the hunt group member ports may be either FXS or FXO. In this mode, if the call cannot be completed because all ports are busy, as soon as a port is available, a callback is made to the originating port causing it to ring and a connection is made upon answer. Identifies the full port number of the ports belonging to the shown hunt group. Up to 32 entries can be added to each hunt group. Identifies a range of ports belonging to the shown hunt group. For example, 1:1:1-4 defines the range of ports 1:1:1, 1:1:2, 1:1:3 and 1:1:4 and is a way of using a single entry to add multiple port members to the shown hunt group. Up to 32 entries can be added to each hunt group.
RingBack
MEMBER LIST
node:port:channel node:port:1st channel - last channel
2.4.8.2
The AUTO MAPPING menu
Calls received on digital voice channels, FXS ports or FXO ports configured with an AUTO destination or SIP UAs configured with an AUTO destination use automapping and/or the directory table to route the call across the Vocality network.
C H A P T E R
T H E
Automapping is used to specify the number of digits used to represent nodes, slots and channels in the auto DTMF mapping scheme. These all default to one digit (one digit for node, one digit for slot, one digit for channel) to provide backward compatibility with the pre-3.0 release scheme. This menu also allows you to configure a slot number to represent hunt groups and the SIP gateway in the automapping scheme (see Section 2.4.8.1 for more information on hunt groups).
AUTOMAP MODE
This is used to enable and disable the automapping feature.
DIGIT COUNTS
These counts allow the user to define how dialled digits are mapped to the node, slot and channel components of destinations in the multiplexer network.
SLOT # FOR HUNT GROUPS

If the automapping feature is required to route calls to hunt groups, a number must be used to represent a hunt group (as the usual designator, HG, cannot be dialled on a phone).This is done by configuring a slot number to be used to represent a hunt group. The slot number for hunt groups defaults to an unconfigured value (indicated by -). If the dialled slot number is configured to any other value (valid range 0-999) then the hunt group mapping will be the standard slot mapping. For example, if the digit count for the node is set to 1, the digit count for the slot is set to 1, and the digit count for the channel is
C H A P T E R
T H E
set to 1, and the hunt group slot number is configured as 1, then a call to 511 will be routed to hunt group 1 on node 5, and not voice channel 1 on slot 1 on node 5. NOTE: It is advisable to use an unused slot for the slot number for hunt groups so that calls are not mistakenly routed to a hunt group instead of a voice port.
SLOT # FOR SIP GATEWAYS

If the automapping feature is required to route calls to SIP gateways, a number must be used to represent a SIP gateway (as the usual designator, SG, cannot be dialled on a phone).This is done by configuring a slot number to be used to represent a SIP gateway. The slot number for SIP gateways defaults to an unconfigured value (indicated by -). If the dialled slot number is configured to any other value (valid range 0-999) then the SIP gateway mapping will be the standard slot mapping. For example, if the digit count for the node is set to 1, the digit count for the slot is set to 1, and the digit count for the channel is set to 1, and the SIP gateway slot number is configured as 1, then a call to 611 will be routed to SIP gateway 1 on node 6, and not voice channel 1 on slot 1 on node 6. NOTE: It is advisable to use an unused slot for the slot number for SIP gateways so that calls are not mistakenly routed to a SIP gateway instead of a voice port.
The parameters and options are shown in the following table:
Field
Options
Description
C H A P T E R
T H E
AUTOMAP MODE
Enabled Disabled
Enables the automapping mode. Disables the automapping mode. Calls are routed via the directory menu only. Determines the number of digits assumed to be the node number. For example if the number 98765 is called, and the digit count for node is 1, then 9 is assumed to be the Node number. If the count is set to 2 then 98 is assumed to be the node number. If set to 3 then 987 is assumed to be the node number. Determines the number of digits assumed to be the slot number. Determines the number of digits assumed to be the channel number. The slot number used to represent a hunt group. Unconfigured. Calls are not automatically mapped to a hunt group unless the dialled slot is set to 253 see the section SLOT # FOR HUNT GROUPS above for more information. The slot number used to represent a SIP gateway. Unconfigured. Calls are not automatically mapped to a SIP gateway unless the dialled slot is set to 253 see the section SLOT # FOR SIP GATEWAYS above for more information.
DIGIT COUNT FOR NODE
1-3
DIGIT COUNT FOR SLOT DIGIT COUNT FOR CHANNEL SLOT # FOR HUNT GROUPS
1,2 1-4 1-999 -
SLOT # FOR SIP GATEWAYS
1-999 -
2.4.8.3
The DIRECTORY menu Any of the voice channels in the network may be assigned a dialling code such that dialling digit sequences map on to physical destination ports. This page lists all ports in the network and allows the user to enter DTMF destination numbers that the network will use to set up calls, without having to use the multiplexer hardware port numbering scheme. The DIRECTORY page for voice ports in a network could look like
this:
C H A P T E R
T H E
This facility may be used to integrate ports connected over a multiplexer network into an existing dialling plan or corporate extension list. The direct hardware numbering scheme may still be used at the same time i.e. in the example above both 114 and 823 would dial port 1:1:4 as long as the number 114 has not also been used as a directory code. See section 2.4.8.2, The AUTO MAPPING menu for more information on automapping. However this consumes the dialed digits and only additional digits are passed onto the destination. e.g If as above a directory entry for a primary rate card existed: 0:1:X 123
And a call were made with the Called Party Number (CPN) of 123456, the digits 123 would be consumed by the node and only the digits 456 would be passed onto the destination in the outgoing SETUP message. In many applications, the Vocality products are used to transparently extend the primary rate link between two PBXs and therefore calls need to be routed without consuming routing digits. Additionally there is a requirement to be able to substitute routing digits with a different digit string. To satisfy both of these requirements an additional Prefix field is available in the directory entries. This entry, if present, will insert the given digits at the start of the remaining digit stream before forwarding the call onto the destination. This can be used either to re-insert consumed routing digits or to substitute consumed routing digits with a different digit string. In the example above, an incoming call with the CPN 123456 will cause the consumed routing digits 123 to be re-inserted and the SETUP message sent to the destination 0:1:X will contain the CPN 123456.
C H A P T E R
T H E
An incoming call with a CPN 124456 will cause the routing digits 124 will be consumed and the prefix string 789 will be inserted so the outgoing SETUP message sent on to the destination, 0:2:X, will contain the CPN 789456. The existing functionality, where the digits are consumed, can be achieved by the fourth entry. A CPN of 125456 would consume 125 and insert no replacement digits and so the destination 1:1:X would send a SETUP with a CPN of 456. In addition an ANY directory number is now supported. A directory number of ANY will cause any CPN which doesnt match a specific entry to be routed over the default route, additional digits can be inserted into the outgoing CPN. In the example above a CPN of 321 will route to destination 1:2:X and send a CPN of 555321 in the outgoing setup menu. If the directory contains more than one ANY entry, the first one encountered will be used and subsequent entries will be ignored. The enhancements are also available for hunt groups and although the requirement in mainly for primary rate circuits, the feature is also available to other supported destinations. The Directory menu is a multi-page menu with buttons provided for moving between pages (if enough entries are present for multiple pages). The parameters and options are shown in the following table:
Field
CHANNEL
Options
Node:Slot:Channel Node:HG:Channel Node:SG:Channel X #
Description
Specifies the channel the call is mapped to. Specifies the Hunt Group the call is mapped to. Specifies the SIP UA the call is mapped to. Can be used to identify any channel on a digital voice card, or any channel on a SIP gateway. Digit used with Hunt Groups to signify the HG should wait to collect further digits before sending out the dial string. The wait timeout is 4 seconds but can be expedited by actually entering a# at the end of the digit string. Aggregates are not supported in this release. For future use. When the directory number is dialled, the call is mapped to the specified channel. The * digit is supported Any CPN without a direct match in the Directory gets routed to the specified channel. When the directory number is dialed the prefix is sent out by the Hunt Group
AGG DIRECTORY NUMBER
No 1-25 digits, *, ANY 1-25 digits
PREFIX
2.4.8.4
The MLPP menu
If the MLPP Compatibility option on the System menu is turned ON, the MLPP submenu is provided under the Call Routing menu. Choosing this option causes the following new submenu to be displayed:
C H A P T E R
T H E
This menu has two entries: MLPP ENTRIES Choosing this causes the new MLPP Entries submenu to be launched. The MLPP functionality for individual ports is provisioned in this menu. Network Identity Is a value sent in the ISDN signalling when an MLPP call attempt is made. It is essentially the international dialing code for the network. The default value for this field is 001, the international dialing code for the USA.
C H A P T E R
T H E
2.4.8.4.1
The MLPP ENTRIES menu
The MLPP functionality is provisioned on a per port basis. The functionality is provisioned via the MLPP Entries submenu shown below. Only ports provisioned in this menu will participate in the MLPP functionality. Only MLPP ports in the same domain will be considered for pre-emption in the case of congestion.
The screen has the following softkeys defined: Add Entry, Delete All Entries, Next (not always present) Add Entry creates a new entry in the table. Delete All Entries Deletes all the entries in the table. Next only appears if there are more MLPP entries than will fit on one page, it scrolls onto the next page of entries.
CHANNEL
The CHANNEL field indicates the port to which the MLPP entry pertains, this field is in the format <node>:<slot>:<channel>. The first two entries shown in the example are single analogue voice ports. The third entry describes a primary rate interface, a primary rate interface is described by an entry in the format <node>:<slot>:X , this is consistent with the dial plan notation used in the directory. Hunt group
C H A P T E R
T H E
entries such as 1:HG:2 are not valid in this screen, please see section on feature interaction for more details.
PRECEDENCE
PRECEDENCE is the maximum priority this port may request, this is a numerical field in the range 0 (highest) to 4 (lowest). This menu only describes the maximum precedence level a call can request, in the case of a PRI this is forced to 0 as the assumption is made that the connected equipment will verify subscriber precedence. Making a precedence call request is done on a per call basis and is determined by the digits dialled.
ACCESS
ACCESS determines whether the user access (the terminating equipment) can be pre-empted. If this is set to NO, a call to this subscriber cannot be pre-empted because the users access is busy. The call still may be pre-empted if congestion is encountered in the network. The default for this field is YES.
DOMAIN
DOMAIN is a six digit hexadecimal number identifying the MLPP domain. Only calls in the same MLPP domain may pre-empt one another.
OPERATION
OPERATION defines the action the port should take when receiving an incoming precedence call while connected to a pre-emptable call. The two options are FRIENDLY and RUTHLESS. In Friendly mode, when the call is pre-empted, the called user hears the pre-emption tone through the handset which persists until the handset is hung-up. The phone will then ring with the precedence cadence and when the pre-empted user picks up, the pre-empting caller is connected. In Ruthless mode, when a call is pre-empted, the called user hears a brief pre-emption tone through the handset and will then be immediately connected to the pre-empting caller.
C H A P T E R
T H E
2.4.9
The SLOTS menu
The Slots menu allows you to configure the voice, data, and IP features on slots associated with the physical bays in the V200 and V150 multiplexers. This menu also provides access to the diagnostic tools for each of the slots.
A menu item is presented for all slots present in the system and any slots that have been pre-provisioned in the SLOT MANAGEMENT menu. In the example above, the V200 has two CPU cards installed and slot 5 has been pre-provisioned for a serial data card in the SLOT MANAGEMENT menu. Slot 5 can now be configured as though it had a serial data card installed. Select the slot you wish to configure:
C H A P T E R
T H E
A menu for the selected slot is then shown. Above, the Slot 0 CPU card has been selected.
C H A P T E R
T H E
2.4.9.1
The DATA menu
CHANNEL
The data channels resident on this slot are presented on this menu page. The slot number and channel number distinguish the position of the channel within the chassis.
IFACE
The electrical interface standard used by each port must be selected according to the equipment to be connected.
MODE
Data channels may operate in one of two basic modes, either as an aggregate port or as a tributary channel. An aggregate port performs the function of multiplexing a number of tributary connections over a carrier service to a remote unit. The multiplexer is capable of operating multiple aggregate ports. Point-to-multi-point (PMP) aggregates are used to multiplex over shared outbound links. See Section 4.9 Multi-point to multi-point (MPMP) aggregates are used to multiplex over full mesh broadcast networks. Mesh is used when it is known that all data received on an aggregate has already been received by all other units in the network.
C H A P T E R
T H E
TYPE
The port type field allows the user to select the correct circuit presentation for the data port. When DTE type is selected, the port is configured as Data Terminating Equipment and may be logically connected using a straight cable to modems, for example (which are normally DCE). In other words, the TXD signal is an output from the multiplexer and should be connected to the TXD pin on the modem, which is an input. When DCE is selected, all of the signals reverse direction and the port is configured as Data Circuit terminating Equipment and may be logically connected using a straight cable to terminals, for example. The TXD signal is now an input to the multiplexer and should be connected to the TXD pin on the PC, which is an output. The changeover is performed under software control and no jumper links need to be changed internally. NOTE: On the V25, 0:1 is DTE only while 0:2 is DCE only.
FORMAT
The format field is used to specify the kind of data to be transferred by the port. If synchronous, then transparent (SYNC) or NRZ framed data may be selected, or if async then the specific word structure is selected. The format must be the same at both ends of the multiplexer link. In async modes an additional parameter is accessible immediately to the right of the main format entry which consists of a single character. This allows the user to select from Raw, Error-corrected or Compressed operation (Raw is selected by default). See Section 4.10 Async Error-correction and Compression for details. The format field is also used to select TDM operation on a per-port basis in conjunction with the Mode being set to Agg. Refer to Section 4.14 TDM Aggregates for details.
CLOCK SETTINGS
The multiplexer offers independent RX and TX clocks on every port and each one has three settings controlling rate, source and reference. The convention used is that the RX clock is associated with the direction of data from the aggregate to the tributary, whereas the TX clock is associated with the flow of data from the tributary to the aggregate. The clock source defines where the clock physically comes from. The reference field defines if the unit generates the clock using one of the two internal busses as a reference. When the clock is generated by the unit, the rate field must be specified. For external (EXT) or looped clocks, it may be left blank. Every data port can have two independent Phase-Locked Loops (PLLs) associated with it; one for the receive clock and the other for the transmit. In combination with the two internal clock busses this allows channels to be set up for asymmetric bit rates, or to onward link or phase lock to any Clock source in the network. By default, standard clock speeds are available at predefined granularities (see the Specification
C H A P T E R
T H E
in the relevant Hardware Guide) but other non-standard rates are achievable by using special commands; refer to Vocality for details. Clock switching selections are available according to the following table:
RXC
89 T (Input, from pin) TXC (Output, looped from TXC) DBA (Variable output, from PLL) PLL (Output, locked to clock bus)
TXC
EXT (Input, from pin) RXC (Output, looped from RXC) DBA (Variable output, from PLL) PLL (Output, locked to clock bus) TTP (TT input, ST output from PLL) TTD (AS TTP but variable ST output)
In PLL, TTP, TTD, and DBA modes, where an output clock is being derived from a Phase-Locked Loop, the PLL reference source must be selected from either the Global Receive Clock (GRX) bus or the Global Transmit Clock (GTX) bus. The reference clock bus must first be attached to a source by configuring the Clocking menu. The RX PLL reference for the tributary channel may then be derived from the GRX bus by selecting <GRX (FROM GRX) on the Data Channels menu. In DBA modes, the Rate entered is the maximum rate at which the channel will run, when there is no demand for bandwidth from higher priority sources such as voice channels. Refer to Section 4.8, for more details.
DESTINATION
Destinations are needed by tributary channels to specify to which port the data should be sent and the format follows the rules NODE:SLOT:CHANNEL. The destination must be a channel of the same type, i.e. a data channel destination must always be another data channel, but it can be anywhere in the network, even for example, on the same card. This can be a useful aid in diagnostics. Another useful technique is to specify a loopback in the destination field. By entering the word LOOP as the destination, data to be sent out of a port is looped back internally to the receiver. By entering the word ECHO as the destination, data coming into a port is internally looped to the transmitter. This is applicable to aggregate ports and tributaries, but care should be exercised when using aggregate loopbacks! DO NOT USE AGGREGATE LOOPBACKS UNLESS LOCAL M&C ACCESS IS AVAILABLE.
C H A P T E R
T H E
Tributary in ECHO: Data transmitted back out of the port Tributary in LOOP: Data transmitted back over the aggregate
Aggregate in LOOP: Data transmitted back out of all tributaries Aggregate in ECHO: All data transmitted back over the aggregate
The multiplexer operates by sending packets from tributaries to their corresponding port using a route, which is looked up based on the destination in the packet header. This is usually via a serial aggregate port but could be via an IP aggregate. In any case, the route a packet takes out of the multiplexer may be indirect, going via another unit to reach the final destination. Aggregate ports therefore use routing information only and do not need a destination to be specified in the menu; the destination field should be left blank. The only exceptions to this are SWITCHED or SCADA modes, which are specified by entering the keyword in the destination field (see Section 4.11 for more information on Switched mode and SCADA mode). Tributary ports however are the end points of all connections and so, the port address of the final destination must be specified by all tributaries. This is true of both point-to-point connections and shared outbound connections, which are discussed more fully in the context of the voice menus in section 4.9. The parameters and options for the DATA menu are shown in the following table:
C H A P T E R
T H E
Field
CHANNEL INTERFACE MODE
Options
Information only RS449, V.11, RS232, V.35, RS422, V.36 Agg, Trib, PMP MPMP Mesh
Description
Displays the numbers of all data channels installed in the slot on a separate line. Electrical interface standard used on the port. Channel is used as a point to point aggregate Channel is a tributary Channel is used as a point to multi-point aggregate Channel is used as a multi-point to multi-point aggregate Channel is connected to a meshed network. Port is configured as Data Terminating Equipment (TX is an output) Port is configured as Data Communications Equipment (TX is input) Data is transparent synchronous Data is synchronous, HDLC Non-Return to Zero format Data is synchronous, HDLC Non-Return to Zero Inverted format Agg mode must be selected; port will operate as a TDM aggregate Data is async, 8bits, no parity, one stop Data is async, 8bits, no parity, two stop Data is async, 7bits, even parity, one stop Data is async, 7bits, even parity, two stop Data is async, 7bits, odd parity, one stop Data is async, 7bits, odd parity, two stop Data is async, 7bits, no parity, one stop Data is async, 7bits, no parity, 1.5 stop Not on V200 Data is async, 5bits, no parity, one stop Data is async, 5bits, no parity, 1.5 stop Not on V200 Raw data passed transparently Error-correction active Compression active (error-correction is automatic) Receive clock bit rate. This may be set at any rate from: (*see *PLL rates) 50 to 10240000bps (synchronous) High-speed CPU card only 50 to 5120000bps (synchronous) All systems except high-speed CPU card 50 to 115200bps (asynchronous) RX clock input from the interface
TYPE
DTE, DCE
FORMAT
Sync, NRZ, NRZI, TDM, 8N1, 8N2, 7E1, 7E2, 7O1, 7O2, 7N1, 7N1.5, 5N1, 5N1.5
FORMAT (ASYNC)
R, E, C
RX CLOCK RATE
50-10240000bps
RX CLOCK SRC
Ext,
C H A P T E R
T H E
Field
Options
Txc, PLL, Dba
Description
RX clock output, looped from TX RX clock output, derived from PLL Dynamic Bandwidth Allocation (output) None The reference for the TX PLL is taken from the Global RX Clock bus The reference for the RX PLL is taken from the Global RX Clock bus Transmit clock bit rate. This may be set at any rate from:(see *PLL rates) 50 to 10240000bps (synchronous) High-speed CPU card only 50 to 5120000bps (synchronous) All systems except high-speed CPU card 50 to 115200bps (asynchronous) TX clock input from the interface TX clock output, looped from RX TX clock output, derived from PLL Dynamic Bandwidth Allocation (output) Terminal Timing with ST supplied to DTE As TTP, with DBA facility on ST supplied to DTE Data will only be transmitted to the designated port Port TX data is internally looped to RX Port RX data is internally looped to TX Aggregate link requested by RTS flag Aggregate link uses SCADA protocol Broadcast TX channel number Broadcast RX channel number Broadcast TX and RX channel numbers
RX CLOCK REFERENCE
<GTX, <GRX
TX CLOCK RATE
50-10240000bps
TX CLOCK SRC
Ext, Rxc, PLL, Dba, TTP, TTD
DESTINATION
NODE:SLOT:CHANNEL", LOOP, ECHO, SWITCHED, SCADA BTXnnn, BRXnnn, BTRttt,rrr"
When the RX CLOCK SRC or TX CLOCK SRC is set to PLL, DBA, TTP or TTD the actual rate used is limited to certain intervals. The intervals vary according to the frequency range the configured rate is in. When configured to rates that do not match these intervals, the multiplexer uses the nearest rate available. Min Max Interval
25Hz 110 10400 520000 5128000 Table 1 *PLL rates
9600Hz 110 51200 5120000 10240000
25Hz 800Hz 8000Hz 8000Hz High-speed CPU card l
C H A P T E R
T H E
2.4.9.2
The ANALOGUE VOICE menu
This menu is displayed when an Analogue Voice Card is installed.The VOICE menu allows you to select from a choice of items in a sub-menu.
C H A P T E R
T H E
2.4.9.2.1
The ANALOGUE PORTS menu
CHANNEL
All voice channels detected on power-up are presented on the same menu page. The slot number and channel number distinguish the position of the channel within the chassis.
CLOCK REFERENCE
All voice ports may be configured completely independently of each other. The only restriction is that the reference clock source is common to all the channels in an option slot, since the voice motherboard (VI68701) contains one PLL. As with all other cards, the PCM sample clock generated on the voice card must be phase-locked to either the GRX or the GTX clock busses.
SIGTYPE
Voice channel connections are made by dialling the remote destination. This may be done using tonebased signalling, loop dialling or E&M pulses according to the application. The choice of signalling type allows the user to specify how the channel is operated and also which of the modem or fax relays may be used. DTMF signalling type decodes the tone pair digits and passes them to the remote end. E&M passes all tones but decodes pulse dialling digits if present. The remaining options pass all tones but allow the user to select which modem/fax relay function will operate. TRANS signalling passes all tones and
C H A P T E R
T H E
loop pulses transparently and turns off all of the modem/fax relay functions. V.22 permits only the V.22 modem relay to operate, and STU permits only the STU-IIB/STU-III relay to operate (if the card is fitted).
INTERFACE
When the interface type is set to FXS, the port provides DC loop current or ring voltage for driving a telephone or a trunk port on a PABX, while FXO configures the port to accept DC current or ring voltage; both types are 2-wire interfaces. When set to TIE-LINE, the port is configured as a 4-wire E&M port and should not be connected to network voltages.
ALGORITHM
The wide range of voice algorithms (codecs) allows a trade-off between voice quality, delay and bandwidth. Codec/Algorithm negotiation: it is possible to select a different codec in each direction, with the sending codec forcing the choice of receiving codec; this allows different bandwidth to be used according to which end makes the call. Note that, if using a TDM Aggregate, and a TDM timeslot is carrying the call, then codec negotiation should not be used (since the TDM timeslot is configured with a fixed bandwidth size).
GAIN
Analogue voice applications often require adjustment to optimise the speech quality. This can be caused by poor line impedance matching, signal loss and echo across the telephone network. A combination of input and output gain adjustment over a wide range allows the user to achieve the clearest line, consistent with echo cancellation. At the far end, input gain should be adjusted down to the lowest level which cancels any echo, then the near end output gain adjusted to compensate for the overall signal level.
DESTINATION
When a voice channel destination is specified as AUTO, calls made on this channel will be automatically routed to the dialled destination port according to the DTMF or E&M signalling received. It is also possible to set up fixed destinations, as in the example above, by entering the specific address of the destination port. This feature is useful when configuring Tie-lines between PABXs, or hotlines between telephones and avoids the need for the user to enter any dialling digits just to route through the Vocality network. Using the Directory menu it is possible to specify personalised numbers instead of Vocality-style port numbers. This allows an existing network numbering scheme to be used with the multiplexer, as well as permitting the use of node numbers greater than 9. The parameters and options are shown in the following table:
Field
CHANNEL
Options
Information only
Description
Displays the numbers of all data channels installed.
C H A P T E R
T H E
Field
CLKREF SIGTYPE
Options
GRXCLK, GTXCLK DTMF, E&M, TRANS, V.22, STU, NOSTU
Description
Clock reference bus used by the voice card PLL DTMF signalling passed. All relays enabled E&M signalling passed. All relays enabled All signalling passed in-band. All relays disabled As DTMF, but only V.22 data modem relay enabled As DTMF, but only STU-IIB/STU-III relays enabled As DTMF, but all relays except STU-IIB/STU-III enabled 2-wire port configured to drive a telephone or Trunk Line input 2-wire port configured to connect to an extension port 4-wire E&M port. No telephone voltages allowed Channel not used PCM coded voice PCM coded voice ADPCM coded voice ADPCM coded voice ADPCM coded voice ADPCM coded voice E-ADPCM coded voice E-ADPCM coded voice with asymmetric bit rate TX/RX E-ADPCM coded voice E-ADPCM coded voice with asymmetric bit rate TX/RX E-ADPCM coded voice with asymmetric bit rate TX/RX E-ADPCM coded voice E-ADPCM coded voice with asymmetric bit rate TX/RX E-ADPCM coded voice with asymmetric bit rate TX/RX E-ADPCM coded voice with asymmetric bit rate TX/RX ML-PLQ compressed voice ML-PLQ compressed voice CELP compressed voice Raw PCM sampled voice Proprietary CELP compressed voice Proprietary CELP compressed voice Proprietary CELP compressed voice Proprietary CELP compressed voice Proprietary CELP compressed voice Input and Output gains Voice channel has fixed destination Call routed by dialled digits Hunt group identified by the node number, HG, and the hunt group number SIP Gateway identified by the node number, SG and the SIP Gateway number
INTERFACE
FXS, FXO, Tie-line
ALGORITHM
Off, G.711-A 64K, G.711-u 64K, G.726 16K, G.726 24K, G.726 32K, G.726 40K, G.727 16K, G.727 24/16K, G.727 24K, G.727 32/16K, G.727 32/24K, G.727 32K, G.727 40/16K, G.727 40/24K, G.727 40/32K, G.723.1 5.3K, G.723.1 6.3K, G.729A 8K, Transp. 64K, Netcode 6.4K, Netcode 7.2K, Netcode 8K, Netcode 8.8K, Netcode 9.6K
I-GAIN-O DESTINATION
-31dB to +31dB "NODE:SLOT:CHANNEL", AUTO NODE:HG:NUMBER NODE:SG:NUMBER
C H A P T E R
T H E
Field
Options
BTXnnn, BRXnnn, BTRttt,rrr"
Description
Broadcast TX channel number Broadcast RX channel number Broadcast TX and RX channel numbers
2.4.9.2.2
The SIGNALS & TONES menu
DTMF RELAY
DTMF Relay mode is enabled or disabled on all ports. When DTMF Relay mode is disabled, the multiplexer operates as it did prior to release 2.1.22 - the DTMF tones are carried through the compressed voice path. When DTMF Relay is enabled, the DTMF digits are regenerated in the decoder and thus are not subject to the loss effects through the standard encoder/decoder path. If DTMF is disabled and DTMF applications do not seem to be working, the user may enable DTMF and tune the signal levels as necessary until the application detectors work correctly. NOTE: DTMF Relay must be enabled on at least the encoding side for the relay to work -even if DTMF Relay is disabled on the decoder, the DTMF digit is regenerated correctly.
C H A P T E R
T H E
DTMF OUTPUT LEVEL

By using the DTMF Output Level setting, it is possible to adjust the volume of DTMF tone pairs relative to all other (comfort) tones. The relative output level of the low frequency tone for DTMF digits (relative to the high frequency output level) can be tuned.
DTMF TWIST
The twist allows you to set the relative levels of each member of the tone pair if necessary although by using the defaults this is rarely necessary.
SIGNAL OUTPUT GAIN

The Signal Output Gain setting adjusts the output volume of both DTMF tones and call progress tones i.e. the volume of generated DTMF tones is controlled via a combination of the DTMF output level and Signal output gain. The parameters and options are shown in the following table:
Field
DTMF RELAY DTMF OUTPUT LEVEL
Options
Disabled Enabled Mute -31dBm +3dBm -4dB-0dB -4dB-0dB 50 to 1000ms 20 to 500ms Disabled, Enabled
Description
Default Enables DTMF Relay. Mutes the output. Sets the output level.. Sets the DTMF Twist. Sets the DTMF Output Gain. Sets the DTMF tone-on period. Sets the DTMF tone-off period. Default ring detection thresholds. Should be used in most cases. An alternative ring detection thresholds are invoked, recommended for certain PBXs e.g. Alcatel
DTMF TWIST DTMF TWIST DTMF TONE PERIOD(ms) DTMF INTER-TONE GAP(ms) ALT FXO RING DETECT
C H A P T E R
T H E
2.4.9.2.3
The VOICE ACTIVATION menu
The VOICE ACTIVATION menu should be used only when it is necessary to guarantee that no data, IP or Voice traffic is sent over a link. For example, when using Inmarsat-based apps where the link is a dial-up commodity (which is expensive), it is important only to bring up the link when it is needed for genuine traffic and not for the purposes of "background IP chatter". This is achieved by locking the activation in to voice channels. When the first voice call is made, the link comes up and can then be used by any other channel that can benefit from it, including other voice calls, IP traffic and so on. The link is then dropped when all voice calls have finished, even if there is traffic on other ports. In all other configuration locations no destination mappings should be configured that is, they should be left blank. The activation script is run when the first voice call goes off-hook. A single TTY command (please refer to the TTY Manual for more information) is entered on each line which assigns a destination to the voice, data or IP channel. The deactivation script is run when the last voice call goes on-hook. A single TTY command is entered on each line which removes the destinations added in the activation script. Both the activation script and the deactivation script are limited to eight TTY commands.
C H A P T E R
T H E
2.4.9.3
The IP menu
C H A P T E R
T H E
2.4.9.3.1
The GENERAL menu
The parameters and options are shown in the following table: Field ETHERNET MODE Options AUTONEGOTIATE, 1000Mbps/FULL DUPLEX 100Mbps/FULL DUPLEX, 100Mbps/HALF DUPLEX, 10Mbps/FULL DUPLEX, 10Mbps/HALF DUPLEX DNS SERVER Numeric IP address entry as: nnn.nnn.nnn.nnn OFF, IP address of the DNS Server in the host network
Description
Local connection mode V200 only
DHCP SERVER MODE applies to ENET1 only
The Integrated IP Router acts as a DHCP client SERVER*, The Integrated IP Router acts as a DHCP server RELAY** The Integrated IP Router relays DHCP address negotiations transparently between the client and the host server *SERVER MODE = "SERVER" only operates on ENET1 LEASE* Numeric entry 0-99999 secs Duration of the DHCP IP address lease. (0=permanent)
C H A P T E R
T H E
Field ADDRESS RANGE.TO*
Options Numeric IP address entry as: nnn.nnn.nnn.nnn Numeric IP address entry as: nnn.nnn.nnn.nnn Alphanumeric entry Numeric IP address entry as: nnn.nnn.nnn.nnn Numeric IP address entry as: nnn.nnn.nnn.nnn
Description
Inclusive range of grantable IP addresses
WINS SERVER*
IP address of the WINS Server in the host network Domain name of local network Primary IP address of the DNS Server in the host network Secondary IP address of the DNS Server in the host network (optional)
DOMAIN NAME* PRIMARY ADDRESS**
**SERVER MODE = "RELAY
SECONDARY ADDRESS**
BRIDGE PRIORITY and HELLO TIME are always present BRIDGE PRIORITY 0-65535 Sets the Spanning Tree bridge priority. See Section 4.12.15 for more information on the Spanning Tree protocol. Sets the Spanning Tree hello time. See Section 4.12.15 for more information on the Spanning Tree protocol. Sets the amount of time an idle TCP connection will remain connected when TCP PEP feature is used. Idle TCP connections are left connected until the TCP peer disconnects the session.
HELLO TIME(secs)
1-10
IDLE TIME
60-86400 seconds PERMANENT
C H A P T E R
T H E
2.4.9.3.2
The NETWORKS menu
When Ethernet ports are available they are represented in the user interface with the port name ENET1 and ENET2. When only a single Ethernet port is available it is represented in the user interface as ENET. The Ethernet must be configured with the IP address of the Ethernet port on the local network, and the mask of the local subnet. Any host stations (PCs), or routers on this local network, must be configured to use the IP address of the multiplexers Ethernet as the next-hop gateway for all IP networks that the multiplexer is providing interconnect services for. Alternatively, RIP may be used to do this automatically. In the example below, the Ethernet port ENET1 has been configured with the address 192.168.0.135, and the mask 255.255.255.0 this mask allows the configuration of 253 other IP stations on the local network (two addresses are also reserved for broadcast use). The Maximum Transmission Unit (MTU) in bytes is typically left at the default value of 1514 for the Ethernet port. The UDP Gateway (UDPGw) option is discussed later in the UDP relay section. The Bridge field allows bridging or bridging and Spanning Tree Protocol to be enabled on a per-port basis. If the IP field is configured as OFF and bridging is ON or STP then all traffic is bridged across the multiplexer network. If the IP field is NUM (for ENETx port) or UNN (for tributary channels) and bridging is ON or STP, then IP traffic is routed across the multiplexer network and all other traffic is bridged. (See Section 4.12.15 for more information on Spanning Tree Protocol.) The DBA and Destination fields are not used for the Ethernet port.
C H A P T E R
T H E
The TCP Gateway (TCPGw) option enables the use of the Performance Enhancement Protocol (PEP) and is either blank (because a Feature Key has not been programmed) or can be set to On or OFF, on both ENETx and the logical channels. See Section 4.12.12 for more information on PEP. The IP field is fixed at NUM for standard numbered packet support for the Ethernet ports. If an entry is provided for both ENET1 and ENET2 the multiplexer will bridge or route traffic locally between these two ports. A set of channel numbers (10-99) has been reserved within the multiplexer port numbering scheme for use as virtual IP ports. These are assigned to the slot that is being configured. In this example, Slot 0 is being configured and so the first virtual port, 0:10, is configured as a 512000bps DBA pipe connecting to the corresponding virtual port in the remote multiplexer. All virtual ports may use the same IP address allocation as the Ethernet port itself. It is possible to configure up to 90 such ports so as to link together the integrated routers of up to 90 remote systems through the integrated router on this slot. Refer to section 4.12.4 for details. The parameters and options are shown in the following table:
Field
CHAN
Options
ENET1, ENET2, x:10 - x:99, LOOP 0-10240000 UNN, NUM or OFF
Description
Port or Virtual Port number on slot x Create a Loopback interface (See section 2.4.9.3.2.1) Maximum DBA rate allocation between multiplexer units IP routing mode. Unnumbered for tributary interfaces, numbered for the Ethernet interface or Off. IP port address
DBA IP
ADDRESS
Numeric IP address entry as: nnn.nnn.nnn.nnn Numeric IP address entry as: nnn.nnn.nnn.nnn or /bitcount Numeric 128 to 1516 OFF, ON
MASK
IP address mask. May be entered e.g. as "/24"
MTU UDPGw
Maximum Transmission Unit. Set to give max 20mS packets User Datagram packet support
TCPGw
ON OFF
Bridge
ON STP OFF
Enable/disable the TCP PEP optimisation feature. This is only configurable if the TCPPEP feature has been purchased and the appropriate key has been entered in the feature key menu Bridging is enabled on the specified port Bridging and Spanning Tree Protocol is enabled on the specified port Bridging is disabled on the specified port Data will be forwarded to this virtual port address
DEST
NODE:SLOT:CHANNEL
C H A P T E R
T H E
2.4.9.3.2.1 Loopback interfaces A separate loopback interface may be configured for each Ethernet port that the embedded router supports. If there is just a single Ethernet interface present, then the loopback interface is represented with the port name LOOP. If there are two Ethernet interfaces present, then the loopback interfaces are represented with the port names LOOP1 and LOOP2. To create a loopback interface, add a subnet to the IP NETWORKs menu for the LOOP interface. The address used on the loopback interface can be a sub-component of one of the other numbered interfaces. The loopback address can be used for ping or telnet access regardless of the state of the Ethernet interfaces. It may also be used as the unnumbered source address for IP tributaries. This should be done to avoid routing problems over the IP tributaries if the Ethernet ports fail. When OSPF is run, and the loopback interface address is used as the unnumbered source address for IP tributaries, then the loopback interface must be configured with a mask that is less than 31 bits. 2.4.9.3.3 The ROUTE MANAGEMENT menu
The route management menu provides access to the RIPv2 and IP static route table menus, as well as providing access to an OSPF sub-menu and a route policy control sub-menu:
C H A P T E R
T H E
2.4.9.3.3.1 The RIPv2 menu
Field
CHAN RIPv2 IMPORT
Options
ENET1,ENET2 x:10 x:99 ENABLED, DISABLED ENABLED, ACCESS, DISABLED
Description
Port or Virtual Port number Turns RIPv2 on or off on the specified channel. All received updates are processed. Only updates received from IP addresses configured for RIP access in the access table are processed. All received updates are discarded. Sets the metric or cost value used in the RIP protocol for this embedded router port. Routes for local interface routes that have been configured on this IP router are included in RIP route advertisements sent on this port. Routes for local interface routes that have been configured on this IP router are not included in RIP route advertisements sent on this port. The RIP export table configuration (under the policy sub-menu) controls which interface routes are advertised via RIP on this port.
COST IF
0-15 YES,
NO,
FILT
C H A P T E R
T H E
STAT
YES,
NO,
FILT
RIP
YES,
NO,
Routes for static routes that have been configured on this IP router are included in RIP route advertisements sent on this port. Routes for static routes that have been configured on this IP router are not included in RIP route advertisements sent on this port. The RIP export table configuration (under the policy sub-menu) controls which static routes are advertised via RIP on this port. RIP routes that have been learnt on this IP router are included in RIP route advertisements sent on this port. RIP routes that have been learnt on this IP router are not included in RIP route advertisements sent on this port. The RIP export table configuration (under the policy sub-menu) controls which RIP routes are advertised via RIP on this port OSPF routes that have been learnt on this IP router are included in RIP route advertisements sent on this port. OSPF routes that have been learnt on this IP router are not included in RIP route advertisements sent on this port. The RIP export table configuration (under the policy sub-menu) controls which OSPF routes are advertised via RIP on this port No authentication is required on RIP protocol packets sent and received on this port. Clear text authentication is attempted on RIP protocol packets sent and received on this port. Encrypted authentication is attempted on RIP protocol packets sent and received on this port. The KeyID used for MD5 Authentication is fixed to the value 1. The authentication information (password) to use when using simple MD5 authentication on this port up to 16 characters. The poison reverse mechanism of the RIP protocol is used. This setting must be the same for all RIP enabled ports. The poison reverse mechanism of the RIP protocol is not used. This setting must be the same for all RIP enabled ports.
FILT
OSPF
YES,
NO,
FILT
AUTH MODE
NONE,
OPEN,
MD5
AUTH KEY
Alphanumeric entry
POISON REVERSE*
ENABLED,
DISABLED
* The POISON REVERSE feature can be set to ENABLED (default) or DISABLED for each IP subnet. When it is enabled we will advertise routes learnt on an interface back out of that interface with an infinite metric. When it is disabled we will not advertise routes learnt on a interface back out of that same interface.
C H A P T E R
T H E
2.4.9.3.3.2 The OSPF menu Four sub-menus are provided for controlling OSPF configuration. An OSPF system menu provides control over slot-wide system OSPF parameters. An Area sub-menu allows the user to configure which OSPF areas the router will operate in. An Interface sub-menu allows the user to configure how OSPF will operate on each router interface. The Virtual Link sub-menu allows the user to configure OSPF virtual links. The menu is presented as follows:
C H A P T E R
T H E
2.4.9.3.3.2.1 The SYSTEM menu
The OSPF system menu controls the parameters that affect OSPF protocol operation across the entire embedded IP router (i.e. on the slot being configured). The menu is presented as follows:
Field
PROTOCOL SUPPORT
Options
ENABLED, DISABLED
Description
Controls whether the OSPF protocol is run on this embedded router. Note that the protocol must be enabled here and on each interface that it is required on to operate successfully. The highest IP address configured on the routers loopback ports is used as the OSPF protocol 32-bit router ID. If no loopback ports are present then the highest address on the Ethernet ports is used. Uses a specific address
ROUTER ID
AUTOMATIC,
RFC1583 COMPATIBILITY * ASE ROUTE PREFERENCE
Numeric IP address entry as: nnn.nnn.nnn.nnn ENABLED, DISABLED Integer range 1-255
Enable RFC 1583 compatibility mode for the SPF calculation. Default state. Specifies how active routes that are learned from the OSPF ASE (Autonomous System External) (compared to other protocols) will be selected. When a route has been learned from more than one protocol, the active route will be selected from the protocol with
C H A P T E R
T H E
NSSA ROUTE PREFERENCE
Integer range 1-255
the lowest preference. Each protocol has a default preference in this selection. Specifies how active routes that are learned from the OSPF NSSA (Not So Stubby Area) (compared to other protocols) will be selected. When a route has been learned from more than one protocol, the active route will be selected from the protocol with the lowest preference. Each protocol has a default preference in this selection. This node causes Interface routes to be considered for redistribution into OSPF-ASE when set to All. Interface routes will not be considered for redistribution. Interface routes that match the named route map will be considered for redistribution into OSPF-ASE. This node causes Static routes to be considered for redistribution into OSPF-ASE when set to All. Static routes will not be considered for redistribution. Static routes that match the named route map will be considered for redistribution into OSPF-ASE. This node causes RIP routes to be considered for redistribution into OSPF-ASE when set to All. RIP routes will not be considered for redistribution. RIP routes that match the named route map will be considered for redistribution into OSPF-ASE. This node causes ASE routes to be considered for redistribution into OSPF-ASE when set to All. ASE routes will not be considered for redistribution. ASE routes that match the named route map will be considered for redistribution into OSPF-ASE. This node causes NSSA routes to be considered for redistribution into OSPF-ASE when set to All. NSSA routes will not be considered for redistribution. NSSA routes that match the named route map will be considered for redistribution into OSPF-ASE. This node causes Interface routes to be considered for redistribution into OSPFNSSA when set to All. Interface routes will not be considered for redistribution. Interface routes that match the named route map will be considered for redistribution into OSPF-NSSA.
ASE EXPORT IFACE ROUTES
ALL,
NONE, CONFIGURED **
ASE EXPORT STATIC ROUTES
ALL,
NONE, CONFIGURED **
ASE EXPORT RIP ROUTES
ALL,
NONE, CONFIGURED **
ASE EXPORT ASE ROUTES
ALL,
NONE, CONFIGURED **
ASE EXPORT NSSA ROUTES
ALL,
NONE, CONFIGURED **
NSSA EXPORT IFACE ROUTES
ALL,
NONE, CONFIGURED **
C H A P T E R
T H E
NSSA EXPORT STATIC ROUTES
ALL,
This node causes Static routes to be considered for redistribution into OSPFNSSA when set to All. Static routes will not be considered for redistribution. Static routes that match the named route map will be considered for redistribution into OSPF-NSSA. This node causes RIP routes to be considered for redistribution into OSPFNSSA when set to All. RIP routes will not be considered for redistribution. RIP routes that match the named route map will be considered for redistribution into OSPF-NSSA. This node causes ASE routes to be considered for redistribution into OSPFNSSA when set to All. ASE routes will not be considered for redistribution. ASE routes that match the named route map will be considered for redistribution into OSPF-NSSA. This node causes NSSA routes to be considered for redistribution into OSPFNSSA when set to All. NSSA routes will not be considered for redistribution. NSSA routes that match the named route map will be considered for redistribution into OSPF-NSSA.
NONE, CONFIGURED **
NSSA EXPORT RIP ROUTES
ALL,
NONE, CONFIGURED **
NSSA EXPORT ASE ROUTES
ALL,
NONE, CONFIGURED **
NSSA EXPORT NSSA ROUTES
ALL,
NONE, CONFIGURED **
* NB RFC1583 COMPATIBILITY: Do not configure this parameter "ENABLED" if all the routers using an OSPF implementation in your domain are based on RFC 2328 or later. This parameter should be specified the same way on all routers in the domain. If any of the routers do not have this option, you should always enable this. When disabled, the preference rules for best route election are changed to eliminate certain kinds of possible routing loops. ** NB Route maps need to be configured first before this option is available in the menu. 2.4.9.3.3.2.2 The AREA menu The OSPF Area sub-menu allows to specification of which areas the OSPF protocol should operate in. An area must be added via this menu for OSPF to operate successfully. Interfaces are configured to operate in areas created via this menu. By default there are no areas created, and the menu is presented as follows:
C H A P T E R
T H E
Use the ADD AREA button to create a new area. Once areas have been added, the menu is presented as:
C H A P T E R
T H E
Field
AREA TO EDIT/VIEW
Options
Select from list
Description
Select which area you are currently configuring parameters for. If only a single area has been created then this has no affect. IP address Each OSPF router must be configured into at least one OSPF area. Each OSPF area must have a unique ID. An area ID of 0.0.0.0 signifies that the area is a backbone. Generic Area A "stub" area is one in which there are no ASE or NSSA routes. Each router in the area must specify that the area is a stub, or adjacencies will not form. A Not-So-Stubby-Area (NSSA) is configured according to draft-ietf-ospf-nssa-update-11.
AREA ID
Numeric IP address entry as: nnn.nnn.nnn.nnn
TYPE
NORMAL, STUB,
NSSA
2.4.9.3.3.2.3 The INTERFACE menu The OSPF Interface menu allows the user to configure how the OPSF protocol will operate on each interface on the embedded router. A separate page is presented for each interface that has been configured (via the Networks menu) on the router:
C H A P T E R
T H E
Field
ENTRY TO EDIT/VIEW INTERFACE PROTOCOL
Options
Select from list Read only ENABLED, DISABLED, PASSIVE
Description
Select which interface you are currently configuring parameters for. The interface name of the interface currently being configured. OSPF routing protocol is run on this interface. OSPF routing protocol is not run on this interface. The port does not receive or transmit any protocol packets onto the interface, but the attached network is treated as part of the routing domain. The router only accepts OSPF protocol packets from units with IP addresses that are configured in the access table. No Access security checks are made Selects which of the areas configured via the area menu this interfaces is operating within. The metric for this interface. The default for the number of seconds between link state advertisement retransmissions for adjacencies. If a Link State Protocol is not acknowledged within the amount of time specified here, it is re-sent. This parameter sets the estimated number of seconds required to transmit a link state update. This parameter takes into account transmission and propagation delays and must be greater than 0. The priority for becoming the DR (Designated Router). * Defaults to 10 seconds. This parameter specifies the length of time, in seconds, between hello packets that the router sends on the interface. Defaults to 40 seconds. This parameter specifies the number of seconds that may elapse without receiving a router's hello packets before the router's neighbours will declare it down. A general rule is to be at least three times the HELLO interval. Do not set this value to be less than the HELLO interval, or convergence will not occur. Defaults to 120 seconds. This parameter sets the length of time in seconds between OSPF packets that the router sends before adjacency is established with a neighbour. The poll interval can be used to reduce network overhead in cases where a router may or may not have a neighbour on a given interface at the expense of initial convergence time. The authentication protocol to run on this interface. The KeyID to use when using MD5 authentication. Not used when the Authentication parameter is set to Simple.
ACCESS CHECK
ENABLED,
DISABLED AREA ID Numeric IP address entry as: nnn.nnn.nnn.nnn Integer between 1 and 65535 defaults to 10. Integer between 1 and 65535 defaults to 5.
OUTPUT COST RETRANSMIT INTERVAL
TRANSMIT DELAY
Integer between 1 and 65535 defaults to 1.
ROUTER PRIORITY HELLO INTERVAL
Integer between 0 and 255 defaults to 1. Value in seconds between 1 and 65535
DEAD INTERVAL
Value in seconds between 1 and 65535
POLL INTERVAL
AUTHENTICATION MD5 KEY ID
SIMPLE, MD5 0-255
C H A P T E R
T H E
The key or password used for OSPF authentication on this interface. The entry is hidden from the user and must be re-entered to verify. * NB When more than one router attached to a network attempts to become the DR, the one with the highest priority wins. If the competing routers have the same priority, the one with the highest router ID becomes the DR. The router coming in second in the election becomes the backup DR. A router with a router priority set to 0 is ineligible to become the DR.
KEY
Alphanumeric, 16 characters maximum
2.4.9.3.3.2.4 The VIRTUAL LINK menu This menu allows the OSPF implementation to operate over virtual links. Virtual links are used to establish or increase connectivity of the backbone area. By default there are no virtual links configured and the following menu is presented:
The ADD LINK button allows the user to add a new virtual link. Once at least one virtual link has been added, the following menu page is presented to control the parameters of each of the virtual links. Note that the backbone area (0.0.0.0) must be present in the routers configuration for virtual links to work correctly:
C H A P T E R
T H E
Field
LINK TO EDIT/VIEW NEIGHBOUR ID
Options
Select from list Numeric IP address entry as: nnn.nnn.nnn.nnn Numeric IP address entry as: nnn.nnn.nnn.nnn Value in seconds between 1 and 65535
Description
Select which link you are currently configuring parameters for. IP Address. The router ID of the remote end of the virtual link. Selects the transit area through which this virtual link should exist. This should be one of the areas that is configured on the unit, but cannot be the backbone area (0.0.0.0). Defaults to 5 seconds. This parameter sets the default for the number of seconds between link state advertisement retransmissions for adjacencies. If a Link State Protocol is not acknowledged within the amount of time specified here, it is re-sent. Defaults to 1 second. This parameter sets the estimated number of seconds required to transmit a link state update. This parameter takes into account transmission and propagation delays and must be greater than 0. Defaults to 1. This parameter specifies the priority for becoming the DR (Designated Router).* Defaults to 10 seconds. This parameter specifies the length of time, in seconds, between hello packets that the router sends on the virtual link. Defaults to 40 seconds. This parameter specifies the number of seconds that may elapse without
AREA ID
RETRANSMIT INTERVAL
TRANSMIT DELAY
ROUTER PRIORITY
Integer between 0 and 255 Value in seconds between 1 and 65535
HELLO INTERVAL
DEAD INTERVAL
C H A P T E R
T H E
receiving a router's hello packets before the router's neighbours will declare it down. A general rule is for this value to equal atleast three times the HELLO interval. Do not set this value to be less than the HELLO interval, or convergence will not occur. POLL INTERVAL Value in seconds Defaults to 120 seconds. This parameter sets between 1 and 65535 the length of time in seconds between OSPF packets that the router sends before adjacency is established with a neighbour. The poll interval can be used to reduce network overhead in cases where a router may or may not have a neighbour on a given virtual link at the expense of initial convergence time. AUTHENTICATION SIMPLE, The authentication protocol to run on this MD5 interface. MD5 KEY ID 0-255 The KeyID to use when using MD5 authentication. Not used when the Authentication parameter is set to Simple. KEY Alphanumeric, 16 The key or password used for OSPF characters maximum authentication on this interface. The entry is hidden from the user and must be re-entered to verify. * NB When more than one router attached to a network attempts to become the DR, the one with the highest priority wins. If the competing routers have the same priority, the one with the highest router ID becomes the DR. The router coming in second in the election becomes the backup DR. A router with a router priority set to 0 is ineligible to become the DR.
2.4.9.3.4
The IP STATIC ROUTE TABLE menu
If RIP is not used, each multiplexer IP router must be configured with static routes to tell it how to reach IP networks other than the one that it is locally attached to. An IP STATIC ROUTE TABLE menu screen is provided under the IP sub-menu to do this. Each configured route consists of a description, a destination address, a mask for the destination address and a next-hop. The IP static route table includes a route preference parameter with each route configured. Route preferences provide a selection mechanism when the same route (address/mask match) is learnt from multiple sources (static routes, RIP and OSPF). The route with the lowest preference is selected. Note that both address and mask must match for the preference to be considered. A route with a more specific mask will always take preference over one with a more generic mask regardless of the configured preferences. RIP routes are always installed with a preference value of 100. The preference for OSPF routes is taken from the OSPF system configuration menu. The preference used for static routes is taken from the parameter configured in the static route table:
C H A P T E R
T H E
Field
DESCRIPTION DESTINATION
Options
Alphanumeric Numeric IP address entry as: nnn.nnn.nnn.nnn Numeric IP address entry as: nnn.nnn.nnn.nnn or /bitcount Numeric IP address entry as: nnn.nnn.nnn.nnn or /bitcount or Virtual port I.D. x:[10-99] NODE:SLOT:CHANNEL 1 to 255
Description
For user entry IP port address
MASK
IP address mask. May be entered e.g. as "/24"
NEXT HOP
Address of forwarding node or port
PREFERENCE
Route preference rating (lowest preferred)
C H A P T E R
T H E
2.4.9.3.5
The POLICY menu
By default, when a routing protocol is enabled it will advertise all routes in the embedded protocols routing table. The routing policy menu allows control over whether another protocols routes are advertised it is also possible to be more selective about which routes are advertised. The route policy allows single aggregate routes to be advertised in place of member routes that make up that aggregate (in order to reduce the complexity/size of the routing updates through the network), and for more complex selection on what routes are exported via the routing protocols. The policy control is done via address lists, route maps, RIP export filters and route aggregation. Address lists just define ranges of IP addresses with inclusion and exclusion rules. These address lists are referenced from route maps definitions and RIP export filters. Route maps identify sets of routes. They are referenced from RIP export filters, OSPF export rules and route aggregation definitions. RIP export filters define which routes are included in RIP updates when the RIP export control is set to filter for a particular protocol. Route aggregation rules specify which aggregate routes to advertise when member routes are present. The policy sub-menu provides access to the configuration pages for the policy control:
C H A P T E R
T H E
2.4.9.3.5.1 The ADDRESS LISTS menu
Address lists define ranges of IP addresses with inclusion and exclusion rules. Each address list should be configured with a unique name. These named address lists are referenced from route maps definitions and RIP export filters. By default there are no address list names present and the Address List menu is presented as:
A new list button is presented to allow the user to add the first named address list. When this is selected, an empty address list with the name AL00 is created and the following menu is presented:
C H A P T E R
T H E
Each line in the presented table represents a named address list. The name of the address list may be altered at this time. Note that address lists are referenced by name, so if you change the name of an address list that is already referenced from a route map or RIP export filter, then those entities will not get configured correctly when the configuration is saved and applied to the running router. Each named address list is made up of a number of entries (rules) which specify which addresses are included in the list. The number of rules in each address list is shown in the EntryCount column (readonly). To configure or view the address matching rules the <CONFIGURE> button should be selected. When there are no address rule entries in an address list, the following menu is presented:
C H A P T E R
T H E
The NEW ENTRY button can be used to add entries to the named address list. When it is selected, the next entry in the sequence of address list rules (0 if there are no entries currently in the list) is created. Each line in the menu is a new sequenced entry in the address list rules. Each entry allows the user to specify an IP address and IP mask, and whether the checked address should match (MATCH) or not match (IGNORE) this information to be considered as part of this address list. When an address is checked against an address list, it is checked against each entry in the sequence order specified. If the address matches any of the entries then it is considered a member of the address list. The following example shows an address list (named AL00) that has been configured to check for any addresses on the 192.168.1.0/24 or 192.168.2.0/24 subnets:
C H A P T E R
T H E
2.4.9.3.5.2 The ROUTE MAPS menu Route maps identify sets of routes. Each route map should be configured with a unique name. These named route maps are referenced from RIP export filters, OSPF export rules and route aggregation definitions. A route map is made up of a sequence of rules that are used to match route destination addresses and other route characteristics. Route maps also allow the user to change some metric characteristics of the route that matches the identification rules. The top-level route map menu page shows a row for each route map that has been configured on the unit. When there are no route maps present, the following menu is presented:
C H A P T E R
T H E
To create the first route map, select the NEW ROUTE MAP button. This creates a new route map with a default name of RM00. The name can be changed and the menu for creating rules for this route map can be accessed via the menu screen:
C H A P T E R
T H E
The CONFIGURE button provides access to the configuration of the rules entries. By default a new route map has no rule entries associated with it. The following menu is presented:
Use the ADD ENTRY button to create the next rule. A menu page is provided for each rule in each map:
C H A P T E R
T H E
NEXT ENTRY and PREV ENTRY buttons are available for scrolling between them. The DELETE ENTRY button will delete the rule entry, but leave the route map in place. The parameters for each route map rule entry are as follows:
Field
MAP NAME SEQUENCE NUMBER
Options
Alphanumeric
Description
ALLOW/DENY
Read-only identification of the route map name that this rule belongs to. Numeric 0-99 The relative order in which this rule is checked compared to other rules in the same route map. If this is set to the same value as another rule in the same route map, then the other rule will be removed. ALLOW, Selects whether routes that match the route DENY identification rules are either included (ALLOW) or excluded (DENY) in the route map. ROUTE IDENTIFICATION NO, YES STATIC, RIP, OSPF, OSPFASE, OSPFNSSA, IF NO, YES List of configured address names Selects whether the route must match the PROTOCOL specified to be considered to follow the rule specified. Selects the protocol that a route must be learned from if the MATCH PROTOCOL parameter is set to YES. OSPF indicates OSPF AS-internal routes. OSPFASE indicates OSPF AS-external routes. OSPFNSSA indicates OSPF type-7 LSA routes. IF indicates local interface routes. Selects whether the route must match the address list specified via ADDR LIST NAME to be considered to follow the rule specified. The address list name that the route destination is checked against if the MATCH ADDRESS parameter is set to YES. Only address list names that are currently configured on the unit are selectable create the address list name first if this is being used. If a route map references a route map that is then deleted, then the route map check will no longer operate correctly. Selects whether the outbound interface for a route must match the INTERFACE specified to be considered to follow the rule specified. The interface name to be used if the MATCH INTERFACE parameter is set to YES.
MATCH PROTOCOL
PROTOCOL
MATCH ADDRESS
ADDR LIST NAME
MATCH INTERFACE
NO, YES List of configured interface names
INTERFACE
REDISTRIBUTE OPTIONS REAPPLY METRIC NO, YES When set the YES then the route metric for routes that match the identification rules is updated with the specified METRIC value. When set to NO the metric is unaltered except for standard protocol rules. Route cost. Only values between 0 and 15 are valid when using RIP however. The OSPF metric type that is used when advertising routes that match this route map rule via the OSPF protocol. This parameter controls whether Area Border Routers on an NSSA area propagate the route into type-5 reachability.
METRIC
Value between 1 and 65535 1 or 2
OSPF METRIC TYPE
OSPF TYPE 5 PROPAGATION
NO, YES
C H A P T E R
T H E
Note that the parameters that are used to create route map rules are generic for all route types. Some parameters may not be required when using route maps for certain mechanisms. For example, when using route maps to filter which static routes are advertised via RIP, it is not necessary to indicate that we should match static routes within the route map rule entry, as this has already been constrained by checks at a different level. 2.4.9.3.5.3 The RIP EXPORT FILTERS menu When the RIP export policy for an interface running the RIP protocol is set to FILT, the RIP export filters are checked to find routes to include in RIP updates on that interface. These are configured via the RIP Export Filters menu. By default there are no RIP export filters present (and therefore no routes will match the filters and be included in filtered updates). The menu is presented as follows:
The NEW EXPORT FILTER button creates a new filter to check. Each filter is made up of the interface that the filter applies to, a reference to an address list to check the route destination address against, a protocol to specify where the route was learned from, and an optional route map that can further restrict the route selection (based on outbound interface) and/or update the metric to use in the RIP update. A single row is used for each filter in the RIP export filter database:
C H A P T E R
T H E
The address list is a named address list that must have been previously configured on the unit. The route map is a named route map that must have been previously configured on the unit, or the name (Unconfigured) if the route map is not required for the filtering. 2.4.9.3.5.4 The AGGREGATION menu The route aggregation menu allows the user to configure the IP router to aggregate routes that it is advertising. Aggregation involves advertising a summary route in place of several less significant contributing routes. Configuration of a route aggregate involves specifying the aggregate route (address/mask combination) and then specifying which contributing routes may make up this aggregate. If any of the contributing routes is present then the aggregate route is used instead of the contributing route. The route aggregation feature can also be used to filter out which routes are advertised you can select to block the advertisement of the aggregate route. By default there are no route aggregates configured and the route aggregation menu is presented as:
C H A P T E R
T H E
The NEW ROUTE AGG button is used to create a new aggregate route. When the route is created, it is presented on a single row in the menu as follows:
C H A P T E R
T H E
The destination and mask specifies the aggregate route to advertise. The contributing route map is a route map name for the aggregates contributing routes. The route map must be already configured on the unit. The Block parameter allows the user to either BLOCK or ALLOW the advertisement of the aggregate route when the contributing routes are present. 2.4.9.3.6 The ACCESS TABLE menu
The supervisor configuration screens can now be accessed via the telnet protocol. To provide additional security to ensure that telnet access is only granted to the appropriate parties, an access table has been provided. The access table must be configured to specify which station or group of stations are allowed access to IP host facilities on the multiplexer. Each access table entry comprises a description an IP address, an IP mask, and a service definition. When an attempt is made to access the host service (e.g. a telnet connection is requested), the access table is checked to ensure that an entry matches the requesting host. An IP address/mask pair of 0.0.0.0/0.0.0.0 will allow access from any station to the configured service. The services that are controlled through this access are currently (i) the embedded telnet server, and (ii) Chargen (character generator) TCP server. This table is empty by default. An entry must be added to allow telnet access.
C H A P T E R
T H E
2.4.9.3.7
The UDP RELAY TABLE menu
Standard IPV4 router operation does not allow for the forwarding of subnet broadcasts. However certain network applications rely on the relay of UDP packets sent to the subnet broadcast address. For example Windows browsing service relies on Netbios datagram service packets (addressed to UDP port 138 and the IP subnet broadcast address) reaching all stations within the browsing domain. The UDPGw configuration must be turned to On for each port that we wish the relay operation to work on and an entry in the UDP relay table must be added for each service that must be relayed. Some well-known service types are pre-configured for addition to this table other services require the appropriate UDP port number to be configured. The example below shows the configuration required to get legacy Windows networking working smoothly:
Service
Domain Name NetBIOS Name NetBIOS Datagram Time Other
Port Number
53 137 138 37 For user entry
C H A P T E R
T H E
2.4.9.3.8
The DBA POOLS menu
DBA pools are used to pool available DBA-assigned bandwidth between IP tributaries that share a common aggregate path. The pooling allows unused bandwidth from one tributary in a pool to be assigned to other tributaries that currently have excess data routed through them. It is intended for use in networks where IP tributaries are routed across a common broadcast aggregate, or where several IP tributaries have been configured between two multiplexers and are used separately for service management. An unlimited number of DBA pools may be defined in the system. By default, no tributaries are assigned to the pools. To use the DBA pooling, the IP tributaries must be assigned to DBA pools. The DBA pools menu provides the mechanism for assigning the tributaries to pools. Members may be added to a pool from a selection list of all available IP tributaries, as configured on the Networks menu. A tributary is assigned to a pool by giving it a priority (highest/high/medium/low/lowest) within the pool. A pool must have at least two tributaries assigned to it for the pooling to operate. To remove a tributary from a pool, the priority value should be toggled to EXCLUDE and the member is deleted when the page is updated. The priority scheme defines how bandwidth is shared between tributaries. Each tributary always has access to the bandwidth assigned from the original DBA calculation. However, any bandwidth not used is then shared according to the following scheme: - Highest priority tributaries share the spare bandwidth between them using as much as is needed. - If any spare bandwidth is available after this then the remainder is shared with a weighting between high, medium and low priority tributaries. - Any spare bandwidth after this is assigned to lowest priority tributaries. Tributaries must only be configured in the same pool if they share a common aggregate path - otherwise bandwidth management will be compromised. An example: 0:10 is an IP tributary between node 0 and node 1. 0:11 is an IP tributary between node 0 and node 2.
C H A P T E R
T H E
0:10 & 0:11 are routed across a shared outbound aggregate. On Node0 you can configure 0:10 and 0:11 in the same DBA pool.
C H A P T E R
T H E
If 0:10 and 0:11 are both assigned 64kbps of bandwidth, then when 0:10 is not using its share, 0:11 has access to 128k of the broadcast aggregate. If 0:10 is only using 32kbps at any instant, then 0:11 is given access to 96kbps at the same instant. Another example: 0:10, 0:11 & 0:12 are three IP tributaries between node 0 and node 1. 0:10 has been set up to provide bandwidth for TCP application X. 0:11 has been setup to provide bandwidth for TCP application Y. 0:12 has been setup to provide bandwidth for TCP application Z. Application X is considered much more important than application Y, and Y is more important than Z. DBA has assigned 64kbps to 0:10, 4kbps to 0:11 and 4kbps to 0:12.
By pooling 0:10, 0:11 and 0:12 together with 0:10 assigned at highest priority, 0:11 assigned at medium and 0:12 assigned at lowest priority, applications Y & Z can access the additional 64kbps bandwidth assigned to application X when it is not in use. Application Y gets access to the bandwidth before application Z.
C H A P T E R
T H E
C H A P T E R
T H E
2.4.9.3.9
The MAC SOURCE FILTER TABLE menu
This table adds a security feature to the multiplexer enabling the administrator to limit IP and bridge access to a defined set of end stations. By default the table is empty and no MAC source filtering occurs all traffic is successfully received. As soon as a single entry is added to the table and the configuration changes are saved, MAC source filtering is enabled. Only stations whose MAC address appears in the MAC source filter table may access the IP and bridge services.
New entries are given a description which is used to identify the device specified by the MAC address in the table. The Address is the devices MAC address. In the example above, only the two devices with the MAC addresses 08:00:31:02:22:ad and 08:ab:11:00:a2:f4 will be able to receive traffic (however, unauthorised units will still be able to receive traffic broadcast by the multiplexer). Also, although unauthorised units will be able to access other machines on the remote network, the embedded DHCP server will not assign them addresses because it will not receive the DHCP request. MAC source filter table entries affect all received Ethernet traffic including bridged, IP routed, PEP, and telnet traffic for the local supervisor. NOTE: When two Ethernet ports are present, the entries in this table apply to both ENET1 and ENET2.
C H A P T E R
T H E
2.4.9.3.10 The SERVICE MANAGEMENT menu
The service management facility allows the multiplexer administrator to perform IP filtering and forwarding decisions based on fields within the protocol header in addition to the standard destination address. This allows bandwidth management per protocol, set of end stations (source and/or destination), and/or IP ToS field. Configuring the service management is a 3-stage process: 1. 2. 3. Defining sets of address ranges in the address definitions menu Defining IP/UDP/TCP/ICMP protocol definitions in the protocol definitions menu Applying address range matches against source and/or destination addresses in combination with matching IP TOS fields and protocol definitions to determine a filter disposition. This disposition is to either forward a packet down a specific tributary or discard the packet. If no match is found in the configured filter table for a packet, then standard destination address IP routing is performed. The Service Management feature allows the multiplexer administrator to perform IP filtering and forwarding decisions based on fields within the protocol header. This allows bandwidth management per protocol, set of end stations (source and/or destination) and/or IP Type of Service (ToS) field.
C H A P T E R
T H E
NOTE: Service Management applies only to IP routed traffic. It does not apply to bridged traffic. Traffic forwarded by the PEP feature is also subject to Service Management.
2.4.9.3.10.1 The ADDRESS DEFINITIONS menu
NOTE: This table does not define a filter, it only defines address ranges. Filters are created when address ranges are combined with protocols (see Section 2.4.9.3.10.2) in the FILTER TABLE menu (see Section 2.4.9.3.10.3). This menu allows the user to define the range of addresses to be used in the filtering definitions. Each range is given a name to identify it, an address range (ADDRESS and MASK), and an operator (either MATCH or NOT MATCH). The name is used in the Service Management Filter Table. In the example above, the address 192.168.0.1 falls within the range defined by the entry INTERNET. However, since the operator is NOT MATCH, the entry only filters those addresses that do not fall within the address range specified. Since the address 192.168.0.1 does not fall within the range defined by the entry LOCATION1 either, Service Management filters are not applied to it. However, the address 192.168.1.1 falls within the address range specified by the LOCATION1 entry. Since the operator is MATCH, this address is filtered using the rules defined in the SERVICE MANAGEMENT FILTER TABLE.
C H A P T E R
T H E
NOTE: If an address definition that is in use in the SERVICE MANAGEMENT FILTER TABLE is deleted then any entries in the SERVICE MANAGEMENT FILTER TABLE that reference the deleted address entry are also deleted.
2.4.9.3.10.2 The PROTOCOL DEFINITIONS menu
This page is used to define the protocols and ports used in the Service Management filters. Each entry is given a name which is used in the SERVICE MANAGEMENT FILTER TABLE. The definition can either be a range of UDP ports for UDP IP packets, a range of TCP ports for TCP IP packets, or any other IP protocol. The IP PROTO field defines which IP protocol the packet is for. This is a decimal value for the IP protocol field in the received packet. Three special values of TCP, UDP, and ICMP are available for common protocols. If a value other than TCP or UDP is entered, nothing else needs to be configured for the entry. If TCP or UDP (or the corresponding IP protocol number) is entered, a range of source and destination ports must be specified for the protocol definition. The range consists of a minimum and maximum (inclusive) decimal port number. The value ANY may be used to indicate the range does not matter for a particular entry. A single page of up to 14 protocol definitions is allowed. NOTE: If a protocol definition that is in use in the SERVICE MANAGEMENT FILTER TABLE is deleted then any entries in the SERVICE MANGEMENT FILTER TABLE that reference the deleted protocol entry are also deleted.
C H A P T E R
T H E
2.4.9.3.10.3 The FILTER TABLE menu
The FILTER TABLE combines address ranges and protocols defined in the other two Service Management menus and applies them to packets received on the Ethernet ports.
PRIO
Each set of rules has a priority which defines the order the rules are applied - 01 is the highest priority. To change the priority of an entry, edit the PRIO field with a new number. All the entries are re-numbered to reflect changes to the priorities. Filters are applied in the order of priority in the table. Once a filter is matched no other filters in the table are attempted. The SERVICE MANAGEMENT FILTER TABLE provides a single page of up to 15 entries.
RXNET
RxNet is used to identify the Ethernet interface of IP tributary that a packet was received on. Valid entries are ENET (for single port products), ENET1, ENET2 (for dual port products), virtual channel (slot:channel) or ANY.
C H A P T E R
T H E
TARGET
Target is used to identify the Ethernet interface of IP tributary that the packet would normally get routed to (based on an IP route table lookup). Valid entries are ENET (for single port products), ENET1, ENET2 (for dual port products), virtual channel (slot:channel) or ANY.
ADDRESSES
The SOURCEADDR and DESTADDR fields can be configured with the value ANY or a name from the SERVICE MANAGEMENT ADDRESS DEFINITIONS menu. The value ANY indicates any source or destination address.
TOS
The Type of Service (TOS) field may be any 8-bit hex value or the word ANY. This defines what the TOS field in the IP header should be to match the rule.
PROTOCOL
The PROTOCOL field can be configured with the value ANY or a name from the SERVICE MANAGEMENT PROTOCOLS DEFINITIONS menu. The value ANY indicates any IP, UDP or TCP protocol/port combination.
RESULT
The RESULT field is used to define the operation should all the other elements of the filter match. The entry may forward the traffic to an IP tributary (slot:port) or it may DISCARD the traffic or it may ALLOW matching entries to be passed on to the destination. NOTE: If an address or protocol definition that is in use in the SERVICE MANAGEMENT FILTER TABLE is deleted then any entries that reference the deleted entry are also deleted.
C H A P T E R
T H E
2.4.9.3.10.4 The TCPGw FILTER TABLE menu The TCPGw filter table allows a simple and efficient scheme for selecting which TCP traffic is subject to the Proxy Enhancement Protocol (PEP) optimization. This TCPGw Filter table is laid out in an identical fashion to the standard Filter Table above. The filter can use any combination of the received interface (RxNet), the target interface (Target), the source address, the destination address, the ToS and the TCP protocol to decide whether the packet is subjected to the optimization (Result = PEP) or whether the optimization is bypassed (Result = BYPASS). If no match is found in the TCPGw table then the default result is to optimize (PEP) the traffic this default behavior can be changed by added a default entry (all the parameters set to ANY) with a result of BYPASS as the last entry in the table. The TCPGw Filter table is presented as:
2.4.9.3.11 IP AGGREGATES menu The multiplexer supports multiplexing over IP networks. This is achieved through the configuration of point-to-point connections between pairs of multiplexers over an IP network. These connections are known as IP aggregates. NOTE: IP Aggregates can only be configured on Slot 0.
C H A P T E R
T H E
Each page in this menu represents a separate IP aggregate. Up to 31 IP aggregates may be specified. Additional pages are presented with menu buttons to move between pages. The aggregate to edit or view can be selected via the Next Channel and Prev Channel buttons or via the Agg to Edit/View field. The IP aggregates operate over the UDP transport protocol. The quality of tributary connections across the IP aggregate depends on the quality of service provided by the IP network. For optimum performance the IP network should provide a guaranteed level of service - where a fixed bandwidth is always available between the IP aggregate peers with minimum variation in latency. When an IP quality of service scheme is in place in the IP network, the IP QoS edge router can identify the multiplexer IP aggregate frames either by address/port recognition, or by configuring the IP aggregate to generate packets with a certain TOS (type of service) setting. The IP aggregate multiplexing protocol includes a facility for re-ordering multiplexed packets that were mis-ordered within the IP network (typically due to split-path routing with latency variation on the split paths). The IP aggregate can also be tuned to trade-off multiplexing overhead versus latency. A multiplexing period specifies the frequency at which tributary packets are multiplexed into IP packets over the IP network. A small multiplexing period will create a larger number of smaller IP aggregate packets. A large multiplexing period will create a smaller number of larger IP aggregate packets, thus reducing the IP header overhead at the expense of a greater multiplexing latency. The configuration of a DNS name instead of an IP address is made in the Peer Address field just enter a name instead of an IP address. The term ANY can also be used in this field if the address of the IP aggregate peer is unknown or variable (and no dynamic DNS name is available). If the term ANY is used then the authentication field must be used to configure a password that is the same at both ends of the IP
C H A P T E R
T H E
aggregate. The authentication field is a case-sensitive alphanumeric field that is hidden by asterisk characters when displayed it must be entered twice when configured. The menu also has fields for Control TOS, Setup Delay and Setup Idle Time. The Control ToS allows the user to specify the IP ToS field used for packets in the IP aggregate control protocol this protocol permanently runs in the background even if there is no traffic to multiplex. By default the same value as the standard TOS is used. The Setup Delay and Setup Idle time are designed for use in networks where the ToS in multiplexed traffic is used to setup bandwidth across a packet switched network. If this bandwidth reservation is not instantaneous and the network equipment does not buffer outstanding traffic when establishing the circuit, the IP aggregate can be configured to buffer this traffic for the Setup Delay period. During this period, ICMP packets with the IP Aggregate TOS are sent to the peer. If no traffic is multiplexed over the aggregate for the setup idle time, the next traffic to be multiplexed will be subjected to the setup delay time. The Data Duplication field is a field that is used to configure the simple forward error correction scheme available for IP aggregates. N.B. when enabled, the bandwidth used by the IP aggregate is increased. The IP aggregate protocol allows for the synchronization of multiplexer system clocks over the IP aggregate. An IP aggregate peer can be configured to transfer clock synchronization data (derived from the local GRX or GTX clock) to its peer. The peer can use this clock synchronization protocol to drive GRX and/or GTX. NOTE Implicit routing is not supported across IP aggregates. Multiplexer routes across the IP aggregate must be configured in the routing table. The parameters and options are shown in the following table:
Field Agg to Edit/View

Description
Options Information only

Alphanumeric text
Description Select the IP Aggregate to Edit or View.

Up to 11 characters used to identify the configuration. This is used in the Connect Using field in the route table to match routes to IP aggregates. IP address of the IP Aggregate Peer. This may be also be configured via the Domain field. If the IP address of the IP aggregate peer is not known its URL may be configured here instead. The UDP Port number of the IP Aggregate Peer. This must be configured to the same value at each end of the IP aggregate. The effective bandwidth of the IP aggregate that is available for multiplexing. This does not include the overhead of IP headers. When configured this Rate also determines the value set for the IP CIR. If a value is entered for Rate and then the user enters a value for IP CIR (discarding the automatically generated value) the Rate will be re-calculated based on the IP CIR. Normal operation Activated only when there is traffic to send.
Peer IP Address*
Numeric IP address entry as: nnn.nnn.nnn.nnn or text for DNS name 0-65535
UDP Port
Rate
0-10240000 or automatically generated based on the IP CIR
Mode
Permanent, Switched
C H A P T E R
T H E
Field Agg to Edit/View

IP CIR
Options Information only

Automatically configured based on the Rate or 0-10240000 0-5121000
Description Select the IP Aggregate to Edit or View.

The committed information rate required from the IP network to support this IP aggregate. This does include the overhead of IP headers, but can only be used when there is a non-zero multiplexing overhead configured. The IP CIR is automatically calculated based on the value entered for Rate. If a specific IP CIR is entered (discarding the automatically generated value), the Rate will be recalculated based on the IP CIR. 0 -10240000 range for high-speed CPU cards 0-5121000 range for other systems. Hex value relating to network provider's TOS/DSCP scheme. The IP TOS value is used in packets sent on each aggregate allows the IP aggregate network edge nodes to make bandwidth management service decisions based on IP address, UDP port numbers and/or IP TOS value. ToS field used for packets in the Vocality IP aggregate control protocol. The packetisation period for multiplexed packets to be sent over the IP aggregate. The larger this value, the more efficient the multiplexing over the IP aggregate is. The smaller the value, the less jitter is introduced over the IP aggregate The maximum time to wait for out-ofsequence packets. This should be set to the largest expected variation in latency between different paths between the IP aggregate peers across an IP network with multiple paths. Setting this value too high creates unwanted jitter that may affect voice and data quality in networks where IP aggregate packets are lost. No clocking calibration information is sent to the peer. Clocking calibration information is sent to the peer based on the GRX clock. Clocking calibration information is sent to the peer based on the GTX clock Initial traffic buffering delay to be used over switched aggregates. Traffic idle timer after which the next traffic is again subject to the Setup Delay Control for the simple FEC Up to 16-character password which must match that of the peer if the Peer IP Address field is set to ANY.
TOS
0-FF hex value
Control TOS Mux Delay
0-FF hex value 0-1000 milliseconds
Reseq Delay
0-1000 milliseconds
Tx Clock
<GRX <GTX
Setup Delay Setup Idle Time Data Duplication Authentication
0-60000 milliseconds 0-86400 secs OFF, ON Alphanumeric text
*The term ANY can also be used in this field if the address of the IP aggregate peer is unknown or variable (and no dynamic DNS name is available.
C H A P T E R
T H E
2.4.9.4
The SYSLOG menu
The SYSLOG feature allows the multiplexer to send log messages generated on this slot to an external server known as a Syslog Daemon. The protocol for sending these messages is described in RFC 3164. The protocol is run over UDP port 514. The customer defines the IP address of the Syslog Daemon. If no IP address is specified then no log messages are sent to the Syslog Daemon. The messages that are sent can also be seen in the diagnostic log pages. They include a timestamp from the multiplexer indicating when the message was generated and two sequence numbers. Each trace type (CONNECTION, CONFIGURATION, IP, etc) has its own sequence range this is the first sequence number generated. The second is a sequence number for all messages sent to the Syslog Daemon. These sequence numbers provide the user with an indication as to whether a log message has been missed. The message format is: Nodename: Timestamp : (Specific Seq No : Overall Seq No) log message The Slot number is also put in here. The Syslog protocol provides a mechanism for each message to be sent with a category and a priority, to allow facilities such as filtering on the Syslog Daemon. The multiplexer sends all of its messages with a priority of 6 (Informational). Configuration options are provided to enable categories to be used for each
C H A P T E R
T H E
type of log message. Each log message type can be configured to generate Syslog messages at categories Local0 through Local7, or not at all (Disabled). For example if a user wants to use the Syslog facility to monitor only voice port call records, then configure the Call Records category for Local0 and disable the category for all other traces. Parameters and options for the SYSLOG menu are shown in the following table.
Field
Daemon Address
Options
Numeric IP address entry as: nnn.nnn.nnn.nnn Information only Local0-Local 7 Disabled
Description
IP address of the Syslog daemon
Trace Type Category
Identifies the type of log message. The category sent for the log type Log messages are disabled for this trace message type
C H A P T E R
T H E
2.4.9.5
The ISDN menu
The ISDN Basic Rate Interface (BRI) Module (68057) presents a single S-bus interface, or when supplemented by the 68059 ISDN expansion card, up to four ISDN S-bus interfaces via the standard 8port 8-way RJ45 connector. Ports are wired in parallel in vertical pairs, so ports 1 and 5 represent the same S-bus, then 2 and 6, 3 and 7, 4 and 8. This allows single-bearer devices to be connected together on the same S-bus. Ports may be used in Terminal Adaptor (TA) mode, when they give the host unit the ability to dial up a 64K bearer for communication with a peer unit, as the sole aggregate, a supplementary aggregate or as a backup service for another aggregate port. They may also be used to present an ISDN network in Network Function Semi (NFS) mode, also in conjunction with a peer module or a digital voice card in another unit. It is possible to program any combination of TA and NFS on all 4 ports. The module is compatible with any Euro-ISDN (NET3) or US National ISDN network as standard. The following menu is only available when an ISDN Module is installed:
PORT
Up to four ISDN BRI ports are available when the 68059 ISDN Expansion Card is fitted to the Module and more than one module may be fitted in a system at the same time. This field specifies the particular slot and port to be configured. ISDN_2ST1 refers to BRI #1 of the module in slot 2.
C H A P T E R
T H E
MODE
Ports may be operated in either Terminal Adaptor (TA) mode or Network Function Semi (NFS) mode. In TA mode they present a TE interface and can be used to dial up a switched aggregate connection to another unit. In NFS mode, ports present an ISDN network with an NT interface and may be used to link together ISDN terminals over the Vocality network. 2.4.9.5.1 Terminal Adaptor(TA) Mode
The card provides the host with a dual 64K bearer interface and either bearer may be used as a permanent connection or dialled up in response to bandwidth requests from any tributaries that are routed over it. To use the ISDN interface as a 64K backup service to another aggregate, it should be specified as a secondary route to a normally available primary aggregate (the corresponding unit must, of course, also have an ISDN Link Interface fitted). If the primary route fails, all connections are then re-routed via the ISDN interface, which will automatically dial the stored destination number. This principle may be extended to provide top-up bandwidth on a temporary basis, simply by overbooking bandwidth on the primary route with the ISDN interface specified as the secondary route. Then, when a connection cannot be made over the primary route through congestion, the ISDN interface will automatically be used. The ISDN call will be maintained until all re-routed connections are closed, even if the primary route becomes free. Next time, the primary route will be used as normal.
LINK MODE
In normal operation the card is configured to Dial On Demand, in which case the ISDN link will be dialled when the first request for a connection is made, for example by a voice channel or data port which is routed over the ISDN link (See ROUTING). The ISDN connection will remain up until the last channel clears its bandwidth request or there is no traffic activity for the configured activity timeout (SYSTEM menu). It is also possible to specify which end makes the call by setting the other end into Answer mode (This can be useful for billing purposes).
CALL TIMER
The ISDN service carries a tariff based on call duration. It is therefore advantageous to be able to limit the maximum duration to prevent excessive call charges. The Call Timer offers the ability to select a maximum call time after which any ongoing ISDN call is dropped. It may also be set to Permanent, which ensures that the timer never expires and calls stay up permanently.
LINE TYPE AND TEIS

The user must configure the ISDN Link Interface to operate according to the correct service type. Point to Point(PP) mode requires fixed (known) Terminal Endpoint Identifiers (TEIs) to be set for Layer 2 of the protocol to establish a connection. The number is usually 0 but may be set in the range 0-63. Layer 1 is
C H A P T E R
T H E
activated immediately with or without a call and Layer 2 comes up and stays up. This is useful for fixed links which use the ISDN network for connectivity. Point to Multi Point(PMP) mode, TEIs are negotiated automatically with the network via a broadcast channel 127 and assigned a number in the range 64-126. Layer 2 of the protocol is activated by an exchange of SABME UA (Unnumbered Acknowledge) messages and thereafter by sequentially numbered messages. This is stimulated by placing a call, which brings up first layer 1 and can take a few seconds to activate. Once activated, Layers 1 and 2 will stay active until physically disconnected. It is possible therefore that the first call may fail following line connection, but calls will always succeed thereafter.
ISDN PROTOCOL
The ISDN protocols are programmed into the ISDN Link Interface Card in the factory. See below for the range of protocols supported.
SPIDS AND LDNS

These are only applicable to ISDN connections in the USA and only therefore appear if the ISDN Link Interface is fitted with an American software stack. The Service Profile IDentifier (SPID) is a number assigned by the Local Exchange Carrier (LEC) or ISDN provider when the customer requests an ISDN line. It allows the network to associate the correct level of functionality with the terminal and also to identify a unique terminal on a BRI circuit (to which up to 8 may be connected) with the same directory number. The generic SPID format is comprised of 14 digits which can be divided into the following three components: a 10 digit telephone number, a 2 digit Sharing Terminal Identifier and a 2 digit Terminal Identifier (TID). The 10 digit number is the main directory number associated with the terminal and includes the 3 digit area code. The 2 digit TID differentiates terminals that have the same main number and the same Sharing Terminal ID. These terminals have the same service profile, which means they have access to the same services and translations in the ISDN network switch. TID values range from 01 to 08, with values assigned in sequential order beginning with 01. Terminals not sharing the same main number always use the value 01 by default. Although the generic SPID format allows for many different combinations of Sharing TID and TID, configurations that use values other than 0101 may not be available from all ISDN service providers. Local Directory Number (LDN): Used for call routing, the LDN is associated with a SPID and therefore with North American BRI interfaces. It is necessary for receiving incoming calls on the second B-channel.
SPID ALLOCATION
SPID Allocation may be performed manually by the user, who simply appends the relevant codes (if known) to the 10 digit local telephone number. Alternatively, if his ISDN service supports it, the unit offers an Automatic SPID mode in which only one SPID is supported. The SPID 1 and LDN 1 fields cannot be entered and if a SPID response is received from the network in response to the first call, the fields are automatically updated on the menu. A third option Auto + SPID guessing requires the user to enter
C H A P T E R
T H E
the LDN field only. This enables the switch to guess against a likely or similar SPID to reduce the response time. This mode is recommended.
ANSWER DELAY
The Answer Delay is the delay in milliseconds between the host being presented with an ISDN call, and it indicating to the network that it can answer that call. It may be required when the host ISDN port is attached to equipment that is sensitive to the immediate answering of presented calls.
RETRY STRATEGY
The Retry Strategy defines the behaviour in the event of the ISDN call failing.
CLOCK REF
The Clock Ref field allows the user to select either GRX or GTX as the clock reference source for the module when in network (NFS) mode.
BOD
The BoD settings control the ISDN call management strategy when the secondary routing mode is set to BoD. The Bandwidth on Demand (BoD) feature continually monitors the level of traffic that is routed through the ISDN interface, and raises and clears the second bearer as required and configured. The traffic levels are calculated with a damping factor to avoid unnecessary dial and clear events in bursty traffic situations. The lower the damping factor the faster the host is to react to changes in traffic patterns (at the cost of potentially unexpected dial/clear events in bursty networks). When the dampened traffic level exceeds the dial threshold the second bearer is dialled. Once established, traffic is split between the two bearers. When both bearers are established and the dampened traffic level drops below the configured clear threshold, all traffic is routed over the first bearer channel. The second bearer is dropped if the dampened traffic level remains below the dial threshold for the secondary activity timer.
C H A P T E R
T H E
Some examples of the used of the SPIDs, LDNs and Allocation are given below: 2.4.9.5.1.1 US NI-1, Manual SPID Entry
The above mode is used if the SPIDs and LDN values are known. The second fields may be left blank when only the first SPID entry is required. The SPID format is different for both the Switch Types and the Local Telecom Provider used, and knowledge of this is required before entry. A SPID code is asserted around the LDN with examples shown above. All North American SPID codes tend to use this but the SPID entry requires local knowledge of the network type as well as the switch, ie two different networks using AT&T switches will have different SPID codes. Example entries might be as follows: NI xxxxxxx = 7 digit number. AT&T <01xxxxxxx0>. <nnnxxxxxxx0101> where nnn = 3 digit area code.
C H A P T E R
T H E
2.4.9.5.1.2 US NI-1, Automatic SPID Entry
Only one SPID is supported. The SPID and LDN fields are deleted. The ISDN Terminal Adaptor is programmed with blank SPID and LDN fields. The SPID/LDN values are not saved in the configuration.
C H A P T E R
T H E
2.4.9.5.1.3 US NI-1, Auto SPID Entry with SPID Guessing
Only one SPID is supported. In this case, SPID guessing requires the user to enter the LDN field only. This enables the switch to guess against a likely or similar SPID to reduce the response time. This mode is recommended. The SPID 1 field is set to SPID guessing format with the code above. The ISDN Terminal Adaptor is programmed as above. The SPID/LDN values are not saved in the Configuration. The parameters and options are shown in the following table:
Field
PORT MODE
Options
ISDN_0ST1 TA, NFS
Description
ISDN_XSTY where X = slot number, Y = port number Terminal Adaptor mode. The module presents TE interface(s) Network Function Semi mode. The module presents NT interface(s) ISDN number dialled on first bandwidth request. Incoming calls also answered. Incoming calls answered only. Maximum single call duration. The ISDN call will be terminated when this duration is exceeded.
LINK MODE
Dial On Demand, Answer
CALL TIMER
LINE TYPE
5min, 10mins, 20mins, 1 hour, 2 hours, 5 hours, 10 hours, 24 hours, Permanent PMP,
Point-to-multipoint. This is the default for Euro ISDN.
C H A P T E R
T H E
PP TEI ISDN PROTOCOL AUTO EURO ISDN, France VN6, NI (National ISDN), ATT 5ESS (Custom), Nortel DMS-100 Text Entry EN-BLOC, EN-BLOC/OVERLAP SPID ALLOCATION Manual, Automatic, Auto + SPID Guessing SPID1 Special field
Point-to-point. A TEI must be entered in the range 0-63. Terminal Endpoint Identifier for information only Country-specific protocols
CLI1, CLI2 DIAL TYPE
Text appears as Calling Line Identifier All digits output in dial message Digits forwarded when entered by user SPID and LDN must be entered by the user. SPID1, LDN1 are displayed automatically when allocated by the network
LDN1
Special field
Manual : Numeric Entry Automatic: Information only Auto+Guessing: Enter 01010101010101 Manual : Numeric Entry Automatic: Information only Auto+Guessing: Numeric Entry Numeric Entry, visible in Manual SPID allocation Numeric Entry, visible in Manual SPID allocation Programmable delay from receiving call to answering it. Minimum 2secs between calls and no more than 10 calls per 30-minute period to the same number Only retries after 62 seconds Continual redialing without delay Do not use (or need) a clock reference Clock reference from GRX Clock reference from GTX Sets the Bandwidth on Demand dial threshold which determines when the second bearer channel is dialled. Sets the Bandwidth on Demand clear threshold which determines when the second bearer channel is dropped. Sets the Bandwidth on Demand damping factor which is used to calculate traffic levels and hence whether to dial up or drop the second bearer channel. Sets the Bandwidth on Demand activity timer which determines after what time the second bearer is dropped if the dampened traffic level remains below the dial threshold The second bearer channel is never dropped
SPID2 LDN2 ANSWER DELAY (ms) RETRY STRATEGY
Special field Special field 0-5000 NORMAL, INMARSAT, AGGRESSIVE
CLOCK REF
-, <GRX, <GTX
BoD DIAL THRESH (bps) BoD CLEAR THRESH (bps) BoD DAMPING FACTOR (%)
0-64000
0-64000
0-99
BoD ACTIVITY TIMER
0-86400
PERMANENT
C H A P T E R
T H E
2.4.9.5.2
Network Function Semi(NFS) Mode
In Network Function Semi mode, the D-channel is terminated on the BRI extender card. Connections are signalled across the Vocality network using the standard Vocality connection signalling protocol. 64kpbs connections are opened for the B-channel traffic when required. Calls made from devices connected to the BRI extender card are forwarded across the Vocality network to either another BRI card running in Network Function Semi mode, or to a PRI interface. Calls made from devices connected to a PRI card can be forwarded across the Vocality network to a BRI module in Network Function Semi mode. This provides new network architecture possibilities for ISDN services across Vocality equipment. Note that only basic call establishment services are provided, and any enhanced services that are typically available on PTT ISDN networks are not available. Call routing from the BRI module in Network Function Semi mode will be handled in a similar fashion to the Vocality voice ports. The CALL ROUTING\DIRECTORY menu is used to set up either a destination BRI module or a hunt group (n:s:x) for routing the call to its destination card in the Vocality network. Since the first available bearer is used, the port number is superfluous and should be left as a X. So, in the example below when a dial digit 9 is received, the call is automatically routed to the ISDN BRI module in chassis 0, slot 2:
C H A P T E R
T H E
If the call signalling succeeds, then data is carried between the B-channels across the Vocality network as a 64kbps synchronous data stream. The following parameters are configurable for each BRI extender card running in network function semi mode:
OPERATING MODE
In NFS operation the card can only be operated in NT mode; its function is to look like an ISDN network.
PROTOCOL
The ISDN protocols are programmed into the ISDN Link Interface Card in the factory. See above for the range of protocols supported.
SPIDS AND LDNS

Refer to the preceding section on TA operation.
CLIS
The user may enter the text to be used as the Calling Line Identification.
C H A P T E R
T H E
DIAL TYPE
The module generates dialing either EN-BLOC (all digits together in the called number) or OVERLAP, when digits are still collected until a terminating # is entered or the digit collection timeout expires (4 seconds). The card will accept either form of dialing.
C H A P T E R
T H E
2.4.9.6
The DIGITAL VOICE menu
This menu is only available when a Digital Voice card is installed.
NOTE: When an option value is changed, the Digital Voice card is reconfigured causing it to be unavailable for 10 seconds.
PORT
Within the user interface the channel identifiers X & Y are used to represent the two interfaces (also marked X & Y on the metalwork) on the 48/60-channel dual digital voice card. On a 24/30-channel card, this parameter does not appear.
OPERATING MODE
Only Switched mode is supported in this release.
INTERFACE
E1 and T1 are supported in this release.
C H A P T E R
T H E
PRESENTATION
This controls the presentation of the 4 wire physical interface. When TE is selected the primary rate ISDN signal is received on pins 1 & 2 and transmitted on pins 4 & 5. When NT is selected the signal is transmitted on pins 1 & 2 and received on pins 4 & 5.
TX CLK SRC
This parameter selects the source for the Transmit Clock on the Digital Voice card.
PLL REF
This parameter selects the reference for the clocks on the Digital Voice card.
IDLE CODE
This allows the binary pattern for the idle code to be defined. The idle code is transmitted down bearer timeslots when no call is present.
CRC4
Enables and disables the Cyclic Redundancy Check procedures on the Digital Voice card.
INT TERM
Sets the internal line termination resistance on the Digital Voice card.
SIGNALLING MODE
Sets the signalling mode on the Digital Voice card. Only Common Channel Signalling (CCS) is supported in this release.
LAYER 2
Allows the unit to be configured as either Master or Slave at layer 2.
TEI
Sets the Terminal Endpoint Identifier.
PROTOCOL
The layer 3 protocol to be implemented.
C H A P T E R
T H E
COMPRESSION
The compression algorithm to be used on calls. Note that this field applies to all voice calls handled on the interface. A transparent 64kbps codec is used for all data calls.
CPN ROUTING
Calls from an ISDN network that are presented to the digital voice card require a scheme for routing these calls into the multiplexer network. Since there is no control over which digital voice channel any call is presented on, there is no concept of fixed mappings for hot-line extension of digital voice channels. All calls must be auto-map routed or directory routed. The number that is used to do this routing is the Called Party Number (CPN) that is presented by the ISDN network. CPN ROUTING is permanently enabled (ON) such that the call routing is done with the CPN value presented by the ISDN network. This parameter is therefore for information only. Refer to section 2.4.8.3 Directory for details.
CLI
CLI presentation allows calls originated from the multiplexer on the digital voice card to present a calling line identifier value. When the feature is set to AUTOMAP, the CLI presented is made up of the node/slot/channel of the multiplexer port that originated the voice call in the multiplexer network. The number is formatted according to the digit counts that are configured in the AUTO MAPPING menu. For example, if the auto mapping settings have a single digit defined for node, slot and channel, and a call is made from 1:2:3, the CLI presented in the outgoing digital voice call is 123. If the auto mapping settings have a single digit allocated for node and slot, but two digits allocated for the channel, then the same call will generate a CLI of 1203. If the configured digit counts are not big enough for the originated port identifier, then no CLI is presented in the outgoing call. When the CLI feature is configured to OFF, no CLI is presented on calls to the ISDN network.
DIAL PARAMETERS
This allows access to the Dial Parameters Menu. See section 2.4.9.6.1, The DIAL PARAMETERS menu.
C H A P T E R
T H E
The menu above is only available when a Digital Voice card is installed in T1 mode. The variances from E1 mode are described below:
FRAMING
Selects the superframe mode on the Digital Voice card.
LINE BUILD OUT

Defines the gain setting for the transmit pulse shape according to the application. The overall parameters and options are shown in the following table:
Field
PORT OPERATING MODE INTERFACE PRESENTATION TX CLK REF
Options
sX, sY Switching E1, T1 TE NT Rxc Int
Description
Interface identifier, where s=slot number. Not displayed on single-span digital voice cards. Only Switching mode is supported in this release. Identifies the type of interface installed. The UTP port is configured as a TE The UTP port is configured as an NT The Transmit Clock reference can be set to the received clock. The Transmit Clock reference can be set to the internal clock generated from a PLL. There is no reference clock for the PLL.
PLL REF
NONE
C H A P T E R
T H E
Field
Options
GRXCLK GTXCLK
Description
The GRX clock is the reference for the PLL The GTX clock is the reference for the PLL Binary coded field, MSB first Enables and disables the Cyclic Redundancy Check procedures on the Digital Voice card - E1 only Sets the internal line termination resistance on the Digital Voice card Superframe (12 frames/multiframe) structure Extended Superframe (24 frames/multiframe) Sets the signally mode on the Digital Voice card. Only CCS is supported in this release - E1 only Short haul TX gain settings
IDLE CODE CRC4 INT TERM FRAMING (T1 ONLY) SIGNALLING MODE LINE BUILD OUT (T1 ONLY)
00000000 to 11111111 Enable, Disable 75 Ohm, 100 Ohm, 120 Ohm D4 ESF CCS DSX-1 0 to 133Ft, DSX-1 133 to 266Ft, DSX-1 266 to 399Ft, DSX-1 399 to 533Ft, DSX-1 533 to 655Ft, CSU 7.5 dB, CSU 15 dB, CSU 22.5 dB CCS Master, Slave 0 - 63 ETSI(DSS1) QSIG ETSI QSIG ISO/ECMA Cornet-N National ISDN Lucent 4ESS Lucent 5ESS Nortel DMA-100
Long-haul TX gain settings
SIGNALLING MODE LAYER 2 TEI PROTOCOL
Common Channel Signalling available only Allows the unit to be configured as either Master or Slave at layer 2 Sets the Terminal Endpoint Identifier The layer 3 voice card The layer 3 voice card The layer 3 voice card The layer 3 voice card The layer 3 protocol to be emulated on the digital protocol to be emulated on the digital protocol to be emulated on the digital protocol to be emulated on the digital protocol to be emulated in T1 mode
The layer 3 protocol to be emulated in T1 mode The layer 3 protocol to be emulated in T1 mode The layer 3 protocol to be emulated in T1 mode Channel not used PCM coded voice PCM coded voice ADPCM coded voice ADPCM coded voice ADPCM coded voice ADPCM coded voice E-ADPCM coded voice E-ADPCM coded voice with asymmetric bit rate TX/RX E-ADPCM coded voice E-ADPCM coded voice with asymmetric bit rate TX/RX E-ADPCM coded voice with asymmetric bit rate TX/RX E-ADPCM coded voice E-ADPCM coded voice with asymmetric bit rate TX/RX E-ADPCM coded voice with asymmetric bit rate TX/RX E-ADPCM coded voice with asymmetric bit rate TX/RX
COMPRESSION
Off G.711-A 64K G.711-u 64K G.726 16K G.726 24K G.726 32K G.726 40K G.727 16K G.727 24/16K G.727 24K G.727 32/16K G.727 32/24K G.727 32K G.727 40/16K G.727 40/24K G.727 40/32K
C H A P T E R
T H E
Field
Options
G.723.1 5.3K G.723.1 6.3K G.729A 8K Transp. 64K NetCode 6.4K NetCode 7.2K NetCode 8K NetCode 8.8K, NetCode 9.6K
Description
ML-PLQ compressed voice ML-PLQ compressed voice CELP compressed voice Raw PCM sampled voice Proprietary CELP compressed voice Proprietary CELP compressed voice Proprietary CELP compressed voice Proprietary CELP compressed voice Proprietary CELP compressed voice The call routing is done with the CPN value presented from the ISDN network. See the section CPN ROUTING above for more information Calling line Id is enabled and automapped according to the digit counts configured in the AUTO Mapping menu. See the section CLI above for more information Calling line Id is disabled Select the DIAL PARAMETERS menu. See Section 2.4.9.6.1
CPN ROUTING
On
CLI
AUTOMAP
Off DIAL PARAMETERS
Within the user interface, the channel identifiers X & Y are used to represent the two interfaces (also marked X & Y on the metalwork) on a dual digital voice card. n:s:X is interface X on slot s in node n. n:s:Y is interface Y on slot s in node n. These interface identifiers can be used to route calls directly (i.e. not via a configured hunt group) to an interface on the dual digital voice card. Note that the internal channel definition for channel X has had to be changed for dual digital voice operation. Channel X is now designated as channel number 979 it was previously 0 this channel number has changed for older single digital voice cards as well. Other units that need to route calls directly to n:s:X on a dual digital voice card will need to be running a software version greater than or equal to the version that first includes dual digital voice functionality. Similarly newer versions that route calls directly to old single digital voice interfaces will need to ensure that the system with the old digital voice interface is running a software with this channel number change. Note that if calls are routed via configured hunt groups instead of via the automatic hunt groups X & Y then there is no backward compatibility issue here. Channel Y is now designated as channel number 978. Note also that there is no shortcut to allow auto-mapping to work directly to the digital voice interfaces (you could previously use channel 0 to do this). The only way for auto-mapping to work directly to the interface is to assign a 3 digit channel mapping and use the numbers 978 & 979 to route the calls. Alternatively use configured hunt groups. The single interface digital voice card uses channels 1-30 to represent the voice & data call endpoints on the digital voice interface. The dual digital voice interface operates on the standard CPU card, and these channel numbers are already assigned for other uses. The following channels are therefore assigned to represent the voice & data call endpoints:
C H A P T E R
T H E
Interface X: Channels 101-130
Interface Y: Channels 201-230
These channel numbers are required for configured hunt group operation and appear in the connection trace logs. There is no automatic configuration to allow a call to be routed to either interface X or interface Y. To allow this, a hunt group entry must be configured. The hunt group should contain the members n:s:101130 and n:s:201-230. There is a limitation on the hardware architecture of the dual digital voice card that means that the two interfaces must share a common clock configuration. Therefore the TX CLK SOURCE and PLL REF parameters are common between the two interfaces on the same card. When one of these parameters is changed for interface X, the parameter is automatically changed for interface Y. Similarly, when one of these parameters is changed for interface Y, the parameter is automatically changed for interface X. Either interface X or interface Y may be configured as the source for either of the system reference clocks. If the SOURCE TYPE is set to E1/T1/J1, both interfaces appear in the configuration list for the SOURCE CLOCK. 2.4.9.6.1 The DIAL PARAMETERS menu
C H A P T E R
T H E
Field
PORT RELAY TYPE
Options
1, 2 DTMF V.22 Trans
Description
Digital Voice span identifier. Fixed at 1 on a singlespan card, selectable on a Dual-span card DTMF signalling passed. All relays enabled As DTMF, but only V.22 data modem relay enabled All signalling passed in-band. All relays disabled Sets the level (or loudness) of the generated tone Sets the twist (the difference in amplitude between the two tones) of the generated dual tone Sets the period in milliseconds for which a tone is applied Sets the length of the silent period in milliseconds between tone pairs
TONE LEVEL TONE TWIST TONE PERIOD SILENCE PERIOD PROGRESS TONES
-31 to +3dBm -4 to 0dBM 50 to 1000 ms 20 to 500 ms TONES OFF
TONES ON
INPUT GAIN OUTPUT GAIN DTMF RELAY
-31dB to +31dB, MUTE -31dB to +31dB, MUTE Enabled
The digital voice interface does not generate call progress tones on calls presented on the interface - in this case it is expected that the ISDN network equipment generates any tones back to the caller To be used when the ISDN network equipment does not support progress tone generation itself. The digital voice interface generates call progress tones on calls presented on the interface Gain applied to calls in the input direction Gain applied to calls in the output direction DTMF tones are sent across the network in the signalling path and regenerated at the target voice port Tones are sent across the network in the compressed voice path The SENDING COMPLETE information element will be sent/not sent in outgoing SETUP messages
Disabled SENDING COMPLETE* SEND, DONT SEND
* The Sending Complete information element is an optional information element which, if sent in an outgoing SETUP message, indicates to the remote receiving device that the call routing information (dialled digits) is complete and no further information will be sent. The Sending complete information element is supported in all the European protocols the Vocality multiplexers support (ETSI DSS1, QSIG ETSI, QSIG ISO/ECMA and CORNET-N).
C H A P T E R
T H E
2.4.9.7
The TDM menu
The TDM menu provides access to two further sub-menus for the detailed configuration of timeslots on each one of the ports available on this slot. TDM functionality is available on any data port in the system, subject to the restrictions noted in Section 4.14.2. TDM configuration is always available for all ports on which TDM is supported, regardless of whether TDM Format has been selected in the DATA menu.
C H A P T E R
T H E
2.4.9.7.1
The TDM Timeslots menu
This menu configures the Timeslots on each Port.
Field
CHANNEL TIMESLOTS <NEXT TDM>
Options
Node:Slot Information only
Description
The Channel/Port being configured
The Maximum Number of Timeslots supported. Set to 16 if using TDM on this port, 0 otherwise Space bar only Select using the space-bar to move on to the next TDM port TRANSMIT TIMESLOTS* The total Transmit or Receive bandwidth configured. It is the total of each timeslots Actual Bandwidth in bits/sec. Under some situations it is valid for this to exceed the TDM ports line-speed: for example, if DBA is being used; or if multiple Voice channels are present, not all of which may be used at the same time. Note that DBA-Ctrl timeslots are not included in this total since the bandwidth they use is stolen. 0 to 15 The ID of the Timeslot CBR, CBR-DBA, Voice, ModemFax, Constant Bit-Rate traffic
TOTAL
TS
CBR with Dynamic Bandwidth Allocation

Use for voice-only traffic (no relays) Use for voice traffic with Modem/Fax relay support
C H A P T E R
T H E
SVR, Packet, Pack-DBA, IP-DBA, DBA-Ctrl Underlying Types PCBR PCBR-CRC Relay
Use for voice traffic with Modem/Fax/SVR relay support
Use for packetized traffic: Aysnc, SerialNRZ/NRZI, Test Ports

Use for packetized traffic where DBA is in use This uses the same techniques as Pack-DBA but has more (configurable) local buffering to handle the bursty nature of Internet traffic Dedicated Bandwidth control timeslot This is the underlying mode which is used in Voice mode. This is the same as PCBR except a two-byte CRC is added to each frame. Thus, corrupted data will be discarded. This is the underlying mode which is used in ModemFax and SVR modes. It may be selected explicitly. If selected explicitly, then the user should specify the data rate to INCLUDE any overhead. This is the underlying mode which is used in IPDBA mode. Standard Node:Slot:Channel address Peer node:Slot:Channel Local node:Slot:Channel Specify a Test Port (normally Packet type) Specify a particular SIP Gateway, Specify any SIP Gateway Specify a CallGen port For example BRD2- if the Timeslot is to carry traffic from Broadcast multiplex 2 The timeslot will carry a simple incrementing pattern The timeslot will be used to carry Remote Management traffic Special editing keys, see notes below The amount of Payload which this timeslot will carry, excluding overhead in Bits per second
Pack-IP DESTINATION n:s:c, P:s:c L:s:c n:TP:c, n:SG:c, n:SG:X n:CG:c BRDn PATTERN REMOTE =, +, blank PAYLOAD** Numeric, 0, 400-2046400 (modulo 400) Information only
ACTUAL***
The actual amount of bandwidth used by this Timeslot, including the timeslots overhead RECEIVE TIMESLOTS as TRANSMIT TIMESLOTS
*There is no explicit correlation between Transmit and Receive Timeslots. However in the interests of simplicity, most users will use the same timeslot for traffic to/from the same destination. **PAYLOAD: This is normally set to the corresponding Tribs normal data size. For example, if using a 64K G711 codec, then set this field to 64000; or if using a 128000 Sync Trib, then set it to 128000. If this field is set to 0, then the Timeslot is not used. ***ACTUAL: The actual amount of bandwidth used by this Timeslot, including the timeslots overhead, measured in bits/sec.. The amount of overhead required varies depending upon the type of traffic being carried.
C H A P T E R
T H E
2.4.9.7.1.1 Destination Specifics Note that a particular BRDn circuit will normally only ever be specified in the transmit or receive direction never both-ways. Note that hunt groups will never be specified here the interpretation of Hunt-group to a destination N:S:C is performed at a higher level than the TDM. The TDM deals with actual addresses. PATTERN: An incrementing pattern is generated which will be validated at the Peer the results of this can be displayed using TDM RXSLOT Diagnostic Command. This provides a simple BERT-type test which can be used to check the integrity of a connection. PATTERN traffic should normally use the CBR timeslot type. REMOTE: The timeslot will be used to carry Remote Management traffic (for access to the menus on a remote unit). REMOTE should normally use the Packet-DBA timeslot type. If no REMOTE timeslot is specified, Remote Management traffic will use the Dynamic area of the frame. P : Rather than specify a particular node number, it is possible to use the P (Peer) option to specify a generic peer node number, to whose specified slot and channel the timeslot payload will be directed. Thus, if a number of identically configured remotes exist, which are redeployed from time to time to reappear on a different TDM port, no further configuration changes are needed. The actual node number used will be learned by the implicit routing function when the TDM aggregate comes up. L : In a similar way the Local node ID may be specified when defining received timeslots, such that data from a particular timeslot is always received on the local port corresponding to the specified channel, irrespective of which node it may be coming from. = : Instructs the menu to duplicate this timeslots configuration from the other direction. This may be entered for transmit or receive timeslots. If the TX Destination includes a Node (Chassis) Id, then it is overwritten with P for the Peer Chassis number; If the RX Destination includes a Node (Chassis) Id, then it is overwritten with L for the Local Chassis number. For example, say receive timeslot 5 is mapped to 6:7:8; if = is entered for transmit timeslot 5, then transmit timeslot 5 will be set to P:7:8. Note that BRDn values are not duplicated. Note: this option is provided as a short-cut to make creation of configs easier. Often the equipment at each end of the link will be symmetrical in which case the values automatically entered will be usable; alternatively the Destination field may need to be edited. + : Incrementing copy: copies the configuration of the previous row (transmit or receive), incrementing the value of the Port by 1. + is not supported on the first row. (Blank): Data will never be sent on a timeslot if its Destination field is blank, except for the special case of DBA-Ctrl timeslots, which implicitly carry traffic between each end of the TDM and do not need a destination to be specified.
C H A P T E R
T H E
2.4.9.7.2
Timeslot Types
CBR-DBA (Constant Bit-Rate with Dynamic Bandwidth Allocation) Timeslot Overhead: zero CRC: none Error Extension: none Notes: This is used to carry CBR-type serial port traffic with automatic negotiation of the Timeslot size when DBA-negotiation occurs. The Payload in this case is the maximum which the TDM will assign to this timeslot. The Trib must also be configured with a maximum bandwidth, as for conventional aggregates. The Timeslot Payload should normally be configured to the same as configured against the Trib. (Note also that trib-to-trib bandwidth negotiation does not intelligently use the value configured here: if the trib-to-trib negotiates a higher value than that configured against the timeslot then data will be lost). Note that data will be lost whenever a rate-change occurs. DBA Trib channel speeds must be symmetric (i.e. the same in both directions). A DBA-Ctrl channel must be configured in each direction for CBR-DBA to function correctly. Unused bandwidth is recycled in the Dynamic Area (used by Type Packet).
Voice Timeslot Overhead: zero CRC: none Error Extension: none Notes: Carries Voice Traffic in a highly efficient manner. This is NOT suitable for Fax/Modem/SVR calls. (Uses the underlying PCBR type)
C H A P T E R
T H E
ModemFax Timeslot Overhead: 2400 bits/sec more than payload CRC: yes Error Extension: may occur Notes: Carries Voice, Modem, and Fax traffic (Uses the underlying Relay type). Note that when Modem and Fax calls are made, additional overhead is required.
SVR (Secure Voice Relay)
Timeslot Overhead: 3600 bits/sec more than payload CRC: yes Error Extension: may occur Notes: Carries Voice, Modem, Fax, and SVR traffic. Similar to ModemFax, but SVR requires more overhead. (Uses the underlying Relay type with additional overhead)
Packet Timeslot Overhead: Variable depending on nature of traffic. If single packet being carried, then 2800 bits/sec more than payload. The overhead budgeted is configurable in the TDM Advanced Config. yes may occur since the data is protected by a CRC.
CRC: Error Extension: Notes: Carries packet-oriented data. Use for: Aysnc, Serial-NRZ/NRZI. Supports fragmentation: one buffer may be split over multiple frames; one frame may carry multiple messages (or message fragments). Data is protected by a CRC. The Packet type can be used for IP but for
IP the timeslot type would normally be IP-DBA.
C H A P T E R
T H E
Pack-DBA (Packet with Dynamic Bandwidth Allocation). Timeslot Overhead: Variable depending on nature of traffic. If single packet being carried, then 2800 bits/sec more than payload. The overhead budgeted is configurable in the TDM Advanced Config. yes may occur since the data is protected by a CRC.
CRC: Error Extension: Notes: As for Packet, but with automatic DBA negotiation of the bandwidth to be used. The Payload in this case is the maximum which the TDM will assign to this timeslot. Note that the Trib must also be configured with a maximum bandwidth, as for conventional aggregates. The Timeslot Payload should normally be configured to the same as configured against the Trib. (Note also that trib-to-trib bandwidth negotiation does not intelligently use the value configured here. If the trib-to-trib negotiates a higher value than that configured against the timeslot then data will be lost). The Packet-DBA type is suitable for NRZ-Tribs with DBA, or Test Ports. It may be used for IP traffic, but IP would normally use IP-DBA. Data is protected by a CRC. A DBA-Ctrl channel must be configured in each direction for CBR-DBA to function.
IP-DBA (Packet with Dynamic Bandwidth Allocation, tuned for IP traffic) Timeslot Overhead: Variable depending on nature of traffic. If single packet being carried, then 2800 bits/sec more than payload. The overhead budgeted is configurable in the TDM Advanced Config. yes may occur since the data is protected by a CRC.
CRC: Error Extension: Notes: As for Pack-DBA but this is tuned to handle the bursty nature of IP traffic. It has a larger transmit queue size, which is configurable in the Advanced Config menu.
DBA-Ctrl (Dynamic Bandwidth Allocation control channel). Control channel for CBR-DBA channels. This is used to negotiate changes in bandwidth assigned to CBR-DBA and Packet-DBA channels. When a DBA speed-change occurs, this channel steals bandwidth from the circuit which is being negotiated. It is necessary to specify a timeslot size here so that both ends agree. No destination need be configured. If used, this should normally be one of the first timeslots (to ensure that it has priority of transmission). A bandwidth of at least 4800 is recommended. Note that bandwidth allocated to DBA-Ctrl timeslots are not included in bandwidth total since the bandwidth they use is stolen.
C H A P T E R
T H E
The following (shown greyed out) are the fundamental underlying packet types, which should only be used with knowledge of the format of the expected traffic:
PCBR Timeslot Overhead: zero. CRC: none Error Extension: none Notes: This is the underlying mode which is used in Voice mode. It may be selected explicitly.
Pack-IP (Packet with queue size tuned for IP traffic) Timeslot Overhead: Variable depending on nature of traffic. If single packet being carried, then 2800 bits/sec more than payload. The overhead budgeted is configurable in the TDM Advanced Config. yes may occur since the data is protected by a CRC.
CRC: Error Extension: Notes: As for Packet but this is tuned to handle the bursty nature of IP traffic. It has a larger transmit queue size, which is configurable in the Advanced Config. (This option would not normally be used: IP traffic should normally use IP-DBA since IP-Trib connections are implicitly DBA)
Relay Timeslot Overhead: none included but the user should make allowance. CRC: yes Error Extension: may occur Notes: This is the underlying mode which is used in ModemFax and SVR modes. It may be selected explicitly. If selected explicitly, then the user should specify the data rate to INCLUDE any overhead.
PCBR-CRC Timeslot Overhead: 800 bits/sec. CRC: yes Error Extension: may occur Notes: This is the same as PCBR except a two-byte CRC is added to each frame. Thus, corrupted data will be discarded.
C H A P T E R
T H E
2.4.9.7.2.1 Selecting The Best Packet Type This section lists the various types of call within the Vocality product range and indicates the type of timeslot to use. (Note that all types may also be routed via the dynamic area if a timeslot is not explicitly set-up). Serial Data: Format Sync: CBR or CBR-DBA (the data consists of a continuous stream of data) Format NRZ or NRZI: Packet or Pack-DBA. (the data is packet-oriented and must be CRCProtected) Format Async: Packet or Pack-DBA IP: Usually IP-DBA.
Analogue Voice call types (from FXO, FXS): Use Voice, ModemFax or SVR depending on type of voice calls being carried. Note that TDM Timeslots do not support Codec-Negotiation: the timeslot size configured must match the configured codec. If codec-negotiation is happening, then do not assign a timeslot (instead, let the calls use the dynamic area). G723 5.3k and G723 6.3k codecs are not supported: TDM timeslots require data-rates of precise multiples of 400 bits/sec. ISDN-PRI: PRI does have access to codecs . For voice calls, the codec to be used is configured in the COMPRESSION option in the DIGITAL VOICE menu. The TDM timeslot should be set to be compatible with this in a similar fashion to Analogue Voice. If ISDN DATA calls are being used, then use CBR/64000. If it is not possible to predict the type of traffic (i.e. there is a mixture of Data and Voice calls) then it is not suitable for TDM timeslots (instead, let the calls use the dynamic area) ISDN-BRI: Always use CBR at 64000 (for both Speech/3k1 audio and Data traffic). Note that there are no codecs available for BRI calls. REMOTE management: Normally should be Packet-DBA. Set speed to 9600. Packet may be used if do not wish to configure a DBA-Ctrl timeslot. If other DBA connections are in use on the TDM, recommend that dont assign a timeslot (so that Remote connections use the dynamic area). This is because it is not as bandwidth efficient. Test Ports: Pack-DBA should be used since these are inherently DBA the bandwidth allocated to them will vary. (Packet type will often be OK. However on a fully-booked connection the bandwidth allocated to Test Ports will vary).
C H A P T E R
T H E
2.4.9.7.3
The TDM Advanced Config menu
This menu allows the configuration of certain advanced TDM parameters. Each parameter applies only to the port in question. The default settings should normally be used. The parameters and options are shown in the following table:
Field
CHANNEL <NEXT TDM> TDM MODE
Options
Node:Slot Space bar only DUPLEX, SIMPLEX
Description
The Channel/Port being configured. Select using the space-bar to move on to the next TDM port. DUPLEX should normally be used. This makes use of two-way negotiation to establish the connection Use if Radio-silence is required. Both ends of the link must be set the same. Normal setting. Used when running a TDM aggregate as a Tributary over another TDM. One of the TDMs should be configured as OFF, the other as INVERTED. Reserves additional overhead in the transmit or receive direction respectively. This additional overhead reserves space in the Dynamic area of the TDM frame. The overhead to calculate for Packet (and PackDBA) timeslots.
DATA STREAM INVERSION
OFF, INVERTED
CONFIGURED OVERHEAD (TX), CONFIGURED OVERHEAD (RX) PACKET TIMESLOT OVERHEAD*
0-2048000bps
0-2048000bps
C H A P T E R
T H E
SEND BROADCAST MESSAGES VIA DYNAMIC
SEND,
DISCARD MAX TX FRAMES IN TRANSIT Numeric
IP-DBA/Pack-IP queue limit (frames)
2 - 1000
All Broadcast data will be sent over the TDMs dynamic area if no transmit timeslot is explicitly assigned to it. Broadcast data will only be sent over the TDM if a timeslot is explicitly allocated. This determines the size of the transmit Jitter buffer on the TDM port. Set to the number of frames in transmit. The default value of 2 should normally be suitable. This value may need to be increased under certain loading conditions. This determines the amount of transmit data which may be buffered for IP-DBA and Pack-IP timeslots on this port. It is measured in frames (50 frames are sent per second). Thus, a value of 100 will permit a maximum of 2 seconds of data to be buffered.
*Packet Timeslot Overhead: The default value of 2800 will normally be fine. However, if the traffic includes a large number of small packets then more overhead may need to be budgeted. Note that this parameter only affects Packet/Pack-DBA/IP-DBA/Pack-IP traffic when routed via Timeslots, not via the Dynamic area.
2.4.9.7.3.1 Radio Silence mode Under certain operational conditions it may be desirable to operate a TDM aggregate stream in one direction only. This requires the transmitting end to override the normal bidirectional synchronization handshakes and to start transmission irrespective of a return channel. Any receiving stations are able to acquire and synchronise to the bitstream at any time. The synchronization pattern is cyclically repeated to allow this to happen. To implement Radio Silence Mode, configure the TDM at all stations to run in SIMPLEX Mode as above. Any tributary circuits which are required to operate in Radio Silence Mode should be configured as Broadcast (BRD) Channels. Radio Silence Mode cannot be used over conventional aggregates since they require bi-directional comms.
C H A P T E R
T H E
2.4.9.8
The DIAGNOSTICS menu
See Section 3.2 for information on the Diagnostics menus.
C H A P T E R
T H E
2.4.9.9
The SNMP menu
The SNMP menus define the configuration of the embedded SNMP agent in the unit. This allows monitoring of the system operation via the SNMP V2/V3 protocols as defined in RFC 1442.
NOTE: SNMP Requires a Feature Key on all products except the V200.
C H A P T E R
T H E
2.4.9.9.1
The SNMP GENERAL menu
NOTE: SNMP Requires a Feature Key on all products except the V200. These configuration parameters control which versions of SNMP are to be used and the security settings that apply.
Field
SNMPV3 ENABLED SNMPV1V2C ENABLED V3 SEC LEVEL
Options
Yes No Yes No
Description
SNMPv3 messages are to be handled All SNMPv3 transactions will fail - they will be silently ignored SNMPv1 and SNMPv2c messages are to be handled All SNMPv1 and SNMPv2c transactions will fail they will be silently ignored Received SNMPv3 messages must match this security level precisely. This field also determines the security level used for all Trap messages transmitted The security level to use for all SNMPv3 messages no authentication and no privacy The security level to use for all SNMPv3 messages authentication but no privacy The security level to use for all SNMPv3 messages authentication and privacy Select the Authentication Protocol to be used for all SNMPv3 messages This field is only used if V3 SEC LEVEL is AuthNoPriv or AuthPriv
NoAuthNoPriv AuthNoPriv AuthPriv V3 AUTH PROTOCOL MD5, SHA1
C H A P T E R
T H E
Field
V3 PRIVACY PROTOCOL V1/V2C COMMUNITY NAME
Options
DES Public Alphanumeric string
Description
The privacy protocol to be used if V3 SEC LEVEL is AuthPriv The Community Name for SNMPv1/v2c Alphanumeric with upper and lower case letters
NOTE: Changes to these fields require the unit to be rebooted in order for them to be applied. A message is displayed when this is necessary. 2.4.9.9.2 The SNMP KEYS menu
NOTE: SNMP Requires a Feature Key on all products except the V200. If SNMPV3 is configured and authentication and/or privacy is enabled, then the multiplexer must be configured with the correct keys. The keys should match the settings on the SNMP server.
Field
V3 AUTH PASSWORD V3 PRIVACY PASSWORD PROGRESS
Options
8-30 characters 8-30 characters No keys generated Keys invalid - EngineID mismatch Compatible keys exist
Description
Sets the local authentication password. Sets the local privacy password Keys have not been generated and saved. the Engine-ID used to generate the keys is different to that of the unit Keys exist which were generated using this units Engine-ID
C H A P T E R
T H E
2.4.9.9.3
The SNMP TARGET TABLE menu
NOTE: SNMP Requires a Feature Key on all products except the V200. The SNMP Target Table specifies the destinations for traps, along with the format in which they are to be sent. SNMPv1 and v2c messages will only be accepted if their source address is in this table. The number of entries in this table is limited to six. This allows support for four different Trap Destinations and also allows room for multiple IP address masks to restrict SNMPV2c access.
Field
Description IP ADDRESS
Options
16 alphanumeric characters Numeric IP address entry as: nnn.nnn.nnn.nnn
Description
Description of the entry. IP address of the destination of the traps. Also used in conjunction with the Mask to specify the valid sources of SNMPv2c (and SNMPv1) messages which the Vocality unit will accept. Note that no such restriction is placed upon the source of SNMPv3 messages this is in conformance with the SNMPv3 recommendations Mask used in conjunction with the IP address field to specify the valid sources of SNMPv2c and SNMPv1 messages. If set to Yes SNMPv2c (and SNMPv1) messages from the IP Address/Mask combination will be handled Enables or disables this IP address as a destination for SNMP traps
MASK
SRC
Numeric IP mask entry as: nnn:nnn:nnn:nnn Yes, No
TRAP
Yes, No
C H A P T E R
T H E
Field
TRAPVER
Options
V2C, V3
Description
The version of SNMP to use to send Traps to this destination SNMPV2c or SNMPV3.
2.4.9.9.4
The SNMP TRAP CONFIGURATIONS menu
NOTE: SNMP Requires a Feature Key on all products except the V200.
This menu provides the option of individually enabling/disabling the generation of each type of trap. NOTE: On the V200 and V150, CPU Cards operating as SLOT-0 display all possible traps both Vocality and MIB-2/SNMP Standard Traps. However, for SNMP agent CPU Cards functioning as line-cards, only the COLDSTART trap is displayed. All other traps are generated through the SNMP client on slot 0. Note SNMP Standard Authentication Failure traps are never generated. Trap statistics are displayed on the SNMP STATS menu screen in the DIAGNOSTICS menu. The actual traps that can be generated on a unit depend on the hardware and the configuration of the unit. The complete list of all possible traps is provided in section 3.2.10, The LOGS menu and sub-sections.
C H A P T E R
T H E
2.4.10 The SOFTWARE MANAGEMENT menu
This menu is used to display and manage the application software which is present on the Compact Flash on the Slot 0 CPU card and distributed to the rest of the cards in the chassis. The card can store a large number of files which allows the user freedom to load the one most appropriate to his particular application and to keep previous versions for reference/backup. It also provides a fail-safe method for upgrading the unit as the previous version is retained and can be restored in the event of a problem. The version name uniquely identifies each application version as it was distributed by Vocality International Ltd and each version is given an Attribute which is used to specify how it is used. For each version present, one may be identified as primary, one as secondary and one as upgrade. The primary and secondary files must be different. The upgrade file may also be primary or secondary. For details of the upgrade process refer to the appropriate Hardware Guide. When a unit is booted, it first tries to find an UPGRADE file. If one is found, the UPGRADE attribute is removed and the file is loaded. Note that if the loading fails, then the subsequent load should find another file. If no UPGRADE file is found, a PRIMARY file is loaded. If no PRIMARY file is found, a SECONDARY file is loaded. If no SECONDARY file is found, the most current file is loaded. If no application can be found, then a command line kernel is entered disaster recovery operations can be controlled via this command line kernel. Contact Vocality International in this event.
VERSION
Shows the software version of the files stored.
C H A P T E R
T H E
ATTRIBUTES
Sets the software application files attribute. This may be Primary, Secondary, or blank.When a new version is downloaded to the unit it is displayed with the Upgrade attribute.
CREATED
Shows the date and time when the software application was created by Vocality International Ltd.
LOADED
Shows when the software application was loaded on to the multiplexer.
TFTP SERVER
The IP address of the TFTP Server used to upgrade the software application. See the appropriate Hardware Guide for information on upgrading the application software.
UPGRADE VERSION
Shows the software version of the application being loaded on to the multiplexer. This must be the prefix of the file being upgraded. For example, if the file on the TFTP Server is named V04_01_01.APL, the Upgrade Version field must be V04_01_01.
OPERATION
Starts the upgrade of the software application specified in Upgrade Version on the TFTP Server specified in TFTP SERVER to the multiplexer.
STATUS
Shows the status of the software application upgrade.
C H A P T E R
T H E
2.4.11 The SLOT MANAGEMENT menu
This screen provides information about the cards installed in each of the ten slots and the serial number and hardware revision of the backplane (BP).
BAY
Shows the bays A-J and the backplane (BP).
C H A P T E R
T H E
SLOT
By default, bay A is mapped to slot 0, bay B to slot 1, and so on. However, the mapping between a bay and a slot may be changed. This is usually done to configure a redundant (backup) card. See the example below.
FUNCTION
A card is normally set as Primary. However, redundancy can be configured: If there is an identical card installed in the V200/V150 and both cards have been configured to use the same slot, one card must be configured as Secondary. NOTE: Secondary should not be configured except when redundancy is configured.
STATE
The State shows whether the bay is empty, or, if a card is installed, whether it is ACTIVE or OFF.
CARD TYPE
This shows the type of card installed in the bay, or empty if no card is installed. If a bay is empty it is possible to preselect from a range of options using the space bar to select. The selected card appears in parentheses and may be stored using the normal procedure. From this point onwards the phantom card appears in menus as if it were present and allows the user to preconfigure its functionality, ready for when the real card is plugged in.
REV
The hardware revision of the card or backplane.
SER NUM
The serial number of the card or backplane.
OPERATION
The default operation is NONE. However, if a card is in state OFF, the operation can be set to RESTART. The V200/V150 then attempts to make the card ACTIVE. If a card is ACTIVE, the operation can be set to SHUTDOWN. This causes the multiplexer to turn off the specified card. NOTE: An attempt to SHUTDOWN an ACTIVE CPU card which does not have a Secondary CPU card configured on the same slot number will fail. In the example, there are similar cards in bay A and bay D. Both cards have been configured to use Slot 0, with the CPU card in bay A set as the Primary card for that slot, and the CPU card in bay D set as the Secondary card for that slot. The multiplexer now has a redundant CPU card and should the Primary CPU card fail or be shutdown, the Secondary CPU card will become ACTIVE.
C H A P T E R
T H E
NOTE: When two identical cards are configured to use the same slot, one of the cards must be configured as Primary the other as Secondary. If this is not done, one of the cards will be turned OFF (see STATE above).
C H A P T E R
T H E
2.4.12 The BACKUP SYNCHRONIZATION menu
When two CPU cards have been configured for redundancy (see the example in Section 2.4.11), the Backup Synchronization Menu can be used to ensure both CPU cards are running the same application software and to ensure all the configuration information is backed up on to the Secondary CPU card. The Software Status shows that an update is required if the Primary and Secondary CPU cards are running different versions of software. When the cards are synchronised by selecting Update Now the application software from the Primary CPU card is copied to the Secondary CPU card. This ensures that should the Primary CPU card fail, the Secondary CPU card will take over and will be running the same software as the Primary CPU card. By selecting Update Later no action is taken at this time. In a similar way, the Configuration Status shows that an update is required if the Primary and Secondary CPU cards have different configuration data. This data can also be synchronised, causing the configuration information to be copied from the Primary CPU card to the Secondary CPU card, thus ensuring the configuration information is not lost if the Primary CPU card fails.
C H A P T E R
T H E
2.4.13 The ALARM MANAGEMENT menu
The Alarm Management menus enable the user to control how the multiplexer signals, collects and manages alarms.
The conditions that can cause alarms and the way alarms can be signalled differ between the products in the Vocality multiplexer range. The menus presented and the layout of the parameters is customised for the features available on each product and may therefore not match what is documented here. The conditions that can cause alarms are split into the following categories: SYSTEM, SERIAL, DATA, IP, E1/T1/J1. Two categories of alarms are supported: Major and Minor. The alarm management configuration allows the user to select which events cause which alarms to be raised, and how those alarms are signalled.
C H A P T E R
T H E
2.4.13.1 The CURRENT ALARMS menu This menu shows the current alarm events and enables the user to ignore or unignore current alarms.
In this example, there is currently one major alarm condition present. The IGNORE button allows the user to ignore the alarm condition. An ignored alarm condition will not generate an alarm signal.
Field
ALARM
Options
Minor Major
Description
Indicates a current minor alarm. Indicates a current major alarm. When an alarms OPERATION is set to IGNORE, the ALARM field is blank. A system alarm has occurred. An alarm has occurred on a serial data port. An alarm has occurred on an IP port. An alarm has occurred on an E1, T1 or J1 port. Alarm indicating the multiplexer has been powered up or power-cycled. Alarm indicating the system reference clock has been lost. Alarm indicating a password failure for the menu system. Alarm indicating the aggregate is lost. Alarm indicating an unexpected disconnection on a switched aggregate link. Alarm indicating a connection failure on a switched aggregate link.
TYPE
SYS DATA IP E1/T1/J1
CONDITION
SYSTEM START/RESTART REFERENCE CLOCK LOST SUPERVISOR SECURITY FAILURE CARRIER LOSS SWITCHED AGG UNEXPECTED DISC SWITCHED AGG CONNECTION FAIL
C H A P T E R
T H E
Field
Options
ACCESS TABLE VIOLATION ETHERNET DISCONNECTED IP AGGREGATE FAILURE E1/T1/J1 NOS/LOS/RED E1/T1/J1 RAI/AIS/YELLOW/BLUE slot:channel IP aggregate name IP address ENET1 or ENET2 GRX or GTC
Description
Alarm indicating the password failed during an attempt to log in to the Access Table. Alarm indicating the Ethernet link was disconnected. Alarm indicating an IP aggregate failure. Alarm indicating no signal/loss of signal/T1 red alarm. Alarm indicating remote alarm indication/alarm indication signal/T1 yellow or blue alarm. Serial data port alarm conditions are reported with the slot:channel that the alarm condition occurred on. IP aggregate alarm conditions are reported with the name of the IP aggregate. IP access violation events are reported with the IP address of the station attempting the bad access. Ethernet failure events are reported with the name of the Ethernet port. System reference clock failures are reported with the name of the clock that has failed. All other alarm events are reported without a value in the INSTANCE field. The current alarm condition is set The current alarm condition is ignored (see OPERATIONS below) The current alarm condition has triggered and is configured as a manually cleared alarm. IGNORE an event in the SET or LATCHED state. An ignored alarm will not cause an alarm signal to be generated. The event will remain in the ignored state until the system is restarted or the event is UNIGNORED. UNIGNORE an event in the IGNORED state. Clear a latched alarm The event is removed from the current list when the event is cleared.
INSTANCE
STATE
SET IGNORED LATCHED
OPERATIONS
IGNORE
UNIGNORE CLEAR
C H A P T E R
T H E
2.4.13.2 The ALARM SIGNALS menu The Alarm Signals menu allows the user to control how Major and Minor alarms are signalled on the unit. The V200 has separate major and minor alarm relays. The major alarm relay may be configured to signal major alarms. The minor alarm relay may be configured to signal minor alarms. The V150 has a single alarm relay. Major and minor alarms can be separately configured to trigger the relay.
Field
SIGNAL DELAY
Options
0-600 seconds
Description
Sets the amounts of time to wait from the first alarm event to generating the signal. A value of 0 indicates the alarm signal will be generated as soon as the alarm event occurs. V200 and V150 only The alarm relay is turned on when an alarm is signalled and off when an alarm is cleared. The relay is not used as part of the alarm signal. When Toggle is selected, the user can configure a period at which to toggle the alarm relay between on and off states whilst the alarm is signalled. The period may be set between 0 and 600 seconds. When configured to 0 seconds, the relay toggles at the highest rate supported by the system.
SIGNAL RELAY Enabled Disabled Toggle 0-600 seconds
C H A P T E R
T H E
Field
SUPERVISOR BELL
Options
RING 0-60 seconds
Description
The alarm causes a bell signal to be sent to the supervisor port. When RING is configured, the user can configure how often a signal is sent. When 0 seconds is configured, the bell signal is sent almost constantly. No supervisor bell signal is generated when an alarm is generated. The front panel alarm LED is used to show an alarm. The front panel alarm LED is NOT used to show an alarm. V200 and V150 only The Backup Failover option is disabled. If a major alarm condition arises, a switchover is forced from the slot reporting the alarm to a backup bay. The switchover only occurs if a backup card is both configured and installed for the reporting slot. The failover is supported on all slots including slot0. The failover delay is independent from the major signal delay. The failover delay is set between 0 and 600 seconds. NOTE If BACKUP FAILOVER is configured on a V200 which generates Major alarms constantly, the V200 may continually switch from one bay to the backup and then back again.
DISABLED FRONT PANEL LED BACKUP FAILOVER Enabled Disabled
Disabled Failover 0-600 seconds
2.4.13.3 The SYSTEM EVENTS menu The events menus specify which multiplexer events cause an alarm condition to be raised. When the Alarm is set to Off the condition is ignored and no alarms are generated for that condition. When the Alarm is set to Major, a major alarm event is generated when the condition occurs. When the Alarm is set to Minor, a minor alarm event is generated when the condition occurs. Clear specifies how an alarm condition is cleared. Some conditions have an automatic clearing event. For example, an alarm condition for an Ethernet port disconnecting can be automatically cleared by the port reconnecting. For conditions that support auto-clearing, the user can configure whether they want the alarm condition to be autocleared. If an event is set to Manual clearing, an alarm condition is latched when it occurs, and must be manually cleared via the CURRENT ALARMS menu. Conditions that do not support auto-clearing may only have a Clear setting of Manual. The Log setting indicates whether changes to the alarm condition are included in the ALARM LOG. Events may be logged in the alarm log, even if they are not configured to generate an alarm. NOTE Each of the events pages show different subsets of conditions which control the alarms. Although the conditions displayed on each events page are different, the settable options are the same. The conditions have been put on to different menus to make it easier to find and configure the various conditions.
C H A P T E R
T H E
Field
Condition
Options
SYSTEM START/RESTART REFERENCE CLOCK LOST SLOT FAILURE BACKUP SYNC REQUIRED SUPERVISOR SECURITY FAILURE Major Minor Off
Description
Alarm indicating the multiplexer has been powered up or power-cycled Alarm indicating the system reference clock has been lost Alarm indicating a slot with a card installed has failed. V200 and V150 only Alarm indicating a Backup synchronization is required. See Section 2.4.12 for more information. V200 and V150 only Alarm indicating a password failure for the menu system The alarm has been defined as a Major event The alarm has been defined as a Minor event The event does not cause an alarm The alarm is cleared manually by the user. Some events may only be cleared manually. other alarms may be configured to be cleared either manually or automatically The alarm is cleared automatically by the system. For example, a carrier loss alarm may be raised and then cleared automatically once the connection has been re-established. Some events may only be cleared manually. other alarms may be configured to be cleared either manually or automatically The alarm event is written to the Alarm Log The alarm event is not written to the Alarm Log
Alarm
Clear
Manual
Automatic
Log
Enabled Disabled
C H A P T E R
T H E
2.4.13.4 The SERIAL DATA EVENTS menu The events menus specify which multiplexer events cause an alarm condition to be raised. When the Alarm is set to Off the condition is ignored and no alarms are generated for that condition. When the Alarm is set to Major, a major alarm event is generated when the condition occurs. When the Alarm is set to Minor, a minor alarm event is generated when the condition occurs. Clear specifies how an alarm condition is cleared. Some conditions have an automatic clearing event. For example, an alarm condition for an Ethernet port disconnecting can be automatically cleared by the port reconnecting. For conditions that support auto-clearing, the user can configure whether they want the alarm condition to be autocleared. If an event is set to Manual clearing, an alarm condition is latched when it occurs, and must be manually cleared via the CURRENT ALARMS menu. Conditions that do not support auto-clearing may only have a Clear setting of Manual. The Log setting indicates whether changes to the alarm condition are included in the ALARM LOG. Events may be logged in the alarm log, even if they are not configured to generate an alarm. NOTE Each of the events pages show different subsets of conditions which control the alarms. Although the conditions displayed on each events page are different, the settable options are the same. The conditions have been put on to different menus to make it easier to find and configure the various conditions.
C H A P T E R
T H E
Field
Condition
Options
CARRIER LOSS SWITCHED AGG UNEXPECTED DISC SWITCHED AGG CONNECTION FAIL Major Minor Off
Description
Alarm indicating the aggregate is lost. Alarm indicating an unexpected disconnection on a switched aggregate link. Alarm indicating a connection failure on a switched aggregate link. The alarm has been defined as a Major event. The alarm has been defined as a Minor event. The event does not cause an alarm. The alarm is cleared manually by the user. Some events may only be cleared manually. other alarms may be configured to be cleared either manually or automatically. The alarm is cleared automatically by the system. For example, a carrier loss alarm may be raised and then cleared automatically once the connection has been re-established. Some events may only be cleared manually. other alarms may be configured to be cleared either manually or automatically. The alarm event is written to the Alarm Log. The alarm event is not written to the Alarm Log.
Alarm
Clear
Manual
Automatic
Log
Enabled Disabled
2.4.13.5 The IP EVENTS menu The events menus specify which multiplexer events cause an alarm condition to be raised. When the Alarm is set to Off the condition is ignored and no alarms are generated for that condition. When the Alarm is set to Major, a major alarm event is generated when the condition occurs. When the Alarm is set to Minor, a minor alarm event is generated when the condition occurs. Clear specifies how an alarm condition is cleared. Some conditions have an automatic clearing event. For example, an alarm condition for an Ethernet port disconnecting can be automatically cleared by the port reconnecting. For conditions that support auto-clearing, the user can configure whether they want the alarm condition to be auto-cleared. If an event is set to Manual clearing, an alarm condition is latched when it occurs, and must be manually cleared via the CURRENT ALARMS menu. Conditions that do not support auto-clearing may only have a Clear setting of Manual. The Log setting indicates whether changes to the alarm condition are included in the ALARM LOG. Events may be logged in the alarm log, even if they are not configured to generate an alarm. NOTE Each of the events pages show different subsets of conditions which control the alarms. Although the conditions displayed on each events page are different, the settable options are the same. The conditions have been put on to different menus to make it easier to find and configure the various conditions.
C H A P T E R
T H E
Field
Condition
Options
ACCESS TABLE VIOLATION ETHERNET DISCONNECTED IP AGGREGATE FAILURE Major Minor Off
Description
Alarm indicating the password failed during an attempt to log in to the Access Table. Alarm indicating the Ethernet link was disconnected. Alarm indicating an IP aggregate failure. The alarm has been defined as a Major event. The alarm has been defined as a Minor event. The event does not cause an alarm. The alarm is cleared manually by the user. Some events may only be cleared manually. other alarms may be configured to be cleared either manually or automatically. The alarm is cleared automatically by the system. For example, a carrier loss alarm may be raised and then cleared automatically once the connection has been re-established. Some events may only be cleared manually. other alarms may be configured to be cleared either manually or automatically. The alarm event is written to the Alarm Log. The alarm event is not written to the Alarm Log.
Alarm
Clear
Manual
Automatic
Log
Enabled Disabled
C H A P T E R
T H E
2.4.13.6 The E1/T1/J1 EVENTS menu The events menus specify which multiplexer events cause an alarm condition to be raised. When the Alarm is set to Off the condition is ignored and no alarms are generated for that condition. When the Alarm is set to Major, a major alarm event is generated when the condition occurs. When the Alarm is set to Minor, a minor alarm event is generated when the condition occurs. Clear specifies how an alarm condition is cleared. Some conditions have an automatic clearing event. For example, an alarm condition for an Ethernet port disconnecting can be automatically cleared by the port reconnecting. For conditions that support auto-clearing, the user can configure whether they want the alarm condition to be auto-cleared. If an event is set to Manual clearing, an alarm condition is latched when it occurs, and must be manually cleared via the CURRENT ALARMS menu. Conditions that do not support auto-clearing may only have a Clear setting of Manual. The Log setting indicates whether changes to the alarm condition are included in the ALARM LOG. Events may be logged in the alarm log, even if they are not configured to generate an alarm. NOTE Each of the events pages show different subsets of conditions which control the alarms. Although the conditions displayed on each events page are different, the settable options are the same. The conditions have been put on to different menus to make it easier to find and configure the various conditions.
C H A P T E R
T H E
Field
Condition
Options
E1/T1/J1 NOS/LOS/RED E1/T1/J1 RAI/AIS/YELLOW/BLUE Major Minor Off
Description
Alarm indicating no signal/loss of signal/T1 red alarm. Alarm indicating remote alarm indication/alarm indication signal/T1 yellow or blue alarm. The alarm has been defined as a Major event. The alarm has been defined as a Minor event. The event does not cause an alarm. The alarm is cleared manually by the user. Some events may only be cleared manually. other alarms may be configured to be cleared either manually or automatically. The alarm is cleared automatically by the system. For example, a carrier loss alarm may be raised and then cleared automatically once the connection has been re-established. Some events may only be cleared manually. other alarms may be configured to be cleared either manually or automatically. The alarm event is written to the Alarm Log. The alarm event is not written to the Alarm Log.
Alarm
Clear
Manual
Automatic
Log
Enabled Disabled
2.4.13.7 The ALARM LOG menu
This log shows messages relating to events which have occurred and which may be configured to raise alarm conditions.
C H A P T E R
T H E
2.4.14 The PUSH CONFIG CLIENTS menu This menu page only exists on Push-Config hosts and allows the user to specify which remote units (serial number and type) are configured via the Push-Config scheme. It also provides a mechanism for the user to specify which hardware options are present on the remote unit. A single line on the menu page is used for each remote unit. The user must specify the node number and node name to use for the remote unit. The menu page provides a button for accessing the configuration pages for this remote unit. NOTE: If the hardware options are changed following initial configuration, then the configuration specific to any hardware options may be lost. A button to add a new remote unit is provided. There is also an option to remove all remote configurations. A single remote unit may be removed by typing <Ctrl-D> when the cursor is on the line representing that unit. If more remote units are added than can be displayed on a single page, then <NEXT PAGE> & <PREV PAGE> buttons are provided. There is no limit placed on the number of supported remote units. The configuration is stored on the hub unit and is pushed out to the remote unit when the remote unit connects to the hub. This connection does not need to be present when the <CONFIGURE> button is pressed.
Once the hardware information has been entered for a node, use the <CONFIGURE> button to configure parameters for that remote unit. The example below shows the remote node boston being configured via the <CONFIGURE> button.
C H A P T E R
T H E
The banner near the top of the screen shows Push-Config is being used to configure the remote node boston. To complete the configuration of boston use the menus provided. Use the appropriate sections of this manual for more information on the menu option. See section 4.4, Push-Config for more information on this feature.
C H A P T E R
T H E
2.4.15 The REMOTE menu This Main Menu screen allows the user to log on to any unit in the network, by selecting the REMOTE option. The user is then prompted for the node I.D. number of the unit to be selected, as shown below:
The required node number is then entered, followed by <CR> and the following message then appears: Connecting to node N. Please wait If the connection is successful, the menu selection page of the chosen unit is then presented, as if logged on locally. All menus appear as normal and any data edited and accepted will be stored in the logged chassis. To return to the local unit, enter <CTRL>&<E> at any time. To configure or monitor a different unit, return to the local unit (the only location at which the REMOTE menu option is provided) and enter a different node I.D. If the chosen unit cannot be reached due to, perhaps, a faulty or unconfigured aggregate route, the following message is displayed: Failed to connect to node N. Press any key After pressing a key, the main menu selection page is again displayed. The user can then inspect the local menus to discover why the chosen remote could not be reached.
C H A P T E R
T H E
WARNING:
During the remote configuration process, it is of course possible to change settings which could result in loss of carrier to that remote unit. Under these circumstances, unpredictable results may occur. Be cautious when changing the configuration settings of any remote aggregate ports!
NOTE:
When a remote node is accessed, the connection to the chosen unit requires at least 2400bps of bandwidth, which must be available throughout the route to that node. If the route already supports a DBA (Dynamic Bandwidth Allocation) connection, the DBA rate will drop by 2400bps. If not, the connection to the remote supervisor will itself act as a DBA connection and use as much spare bandwidth as is available. This process is automatic and ensures that the responses of the remote unit are as rapid as possible.
C H A P T E R
D I A G N O S T I C S
3
3 Diagnostics
specific diagnostics and generic diagnostics which are relevant to the whole unit. 3.1
Chapter
Extensive diagnostics facilities are available in all products. They are divided into two categories, Slot-
The DIAGNOSTICS menu
The generic Diagnostics menu appears on the MAIN MENU.
C H A P T E R
3.1.1
The CLOCK STATUS menu
The CLOCK STATUS menu shows several key statistics relating to the two internal clock reference busses, GRX and GTX (the V25 only has GRX). This page is for information only and has no editable fields. The statistics shown automatically uodate every 30 seconds but may be updated manually by pressing the REFRESH STATS softkey. The statistics may be reset using the RESET STATS softkey. For details on clocking strategies, refer to section Error! Reference source not found.. An entry in the configuration log is made whenever a switch is made between the Primary and Backup clock sources. On a V150/V200 system this log is generated on both the slot that the clock reference is on as well as slot0. The following logs are generated when the primary clock source fails for GRX: 000d:00h:05m:59s:17 GRX source rate change to 0 000d:00h:05m:59s:17 GRX switch to backup source The clock management scheme generates an alarm when the GRX/GTX control logic reports a problem locking the reference clock to the configured source. This alarm is cleared when lock is achieved. This same alarm generation scheme remains in place for the reference clock source back-up scheme. When a primary clock fails it is likely that the clock failure alarm condition is temporarily raised whilst the secondary is being switched in. Once the control logic has locked on the secondary source the alarm condition will be locked. The alarm control mechanism (signal delay) can ensure that this temporary alarm condition does not result in an alarm being signalled.
C H A P T E R
3.1.2
The AGG SUMMARY menu
The AGG SUMMARY shows some simple statistics relating to aggregate status. It is for information only. The menu presents all currently configured aggregates, showing their current state, number of failures and time since the last failure and recovery. The statistics shown automatically uodate every 30 seconds but may be updated manually by pressing the REFRESH STATS softkey. The statistics may be reset using the RESET STATS softkey. The aggregate name is the serial data port name for the aggregate or the IP aggregate name appended to the term IP. The state column reports whether we consider each aggregate to be either UP or DOWN. If the system contains more aggregate ports than can be shown on a single page then <NEXT PAGE> and <PREV PAGE> buttons are provided to access this info for all ports.
C H A P T E R
3.1.3
The TEST PORTS menu
The Test Ports menu provides the ability to test the packet connectivity between two tributaries in a multiplexer network. Slot 253 is reserved as the test port known as TP. The channels in this slot are peered with each other to provide mappings across the multiplexer network over which test packets can be sent. To configure a connection between two Test Ports, one test port is configured to Type TxRx and the other end is configured to Type echo. In this example, node 1 is configured to TxRx (see screen above). Node 0 is configured for echo (see screen below).
C H A P T E R
The screen shows the channels up to 16 can be configured. The Type is configured as either Off, Echo, or TxRx. Off stops the test. The Rate is configured on the TxRx side. A rate between 0 and 2048000 bps can be entered. The Dest is entered as node:TP:channel, where TP indicates a test port. State shows either the receive rate (Rx@rate), the transmit rate (Tx@rate) or Idle (the test port is Off). Packets shows the number of packets received. Lost shows the total number of packets lost. % shows the percentage of packets lost. RTT Min shows the minimum round trip time in milliseconds, Avg shows the average round trip time in milliseconds and Max shows the maximum round trip time in milliseconds. Statistics are updated every 30 seconds once the test is started. Since these tests use up bandwidth, it is advisable to stop the test by setting the Type to Off, once the connection has been successfully established.
C H A P T E R
3.1.4
The SLOTS menu
The SLOTS menu gives an alternative route to the same diagnostics menus as are available under the individual SLOTS configuration menus. Refer to section 3.2 below for details.
3.2
The SLOT N / DIAGNOSTICS menu
A number of tools, statistics and messages are available under the diagnostics menu. The V200 and V150 systems provide separate access to these tools for each slot on the unit. The diagnostics tools on these platforms apply just to the ports and IP router on the slot being diagnosed.
C H A P T E R
3.2.1
The IP menu
There are a number of troubleshooting tools in an IP sub-menu beneath the DIAGNOSTICS menu. These tools allow the user to run the ping protocol (ICMP echo) from the multiplexer, view the current internal IP route table, view the statistics from the IP router, view the statistics from the Ethernet device, and view the Address Resolution Protocol (ARP) table. When the network is not performing as expected, these tools can be used to troubleshoot behaviour. The Diagnostics, IP sub-menu is shown below:
3.2.1.1
The PING menu
This menu provides the user with a series of screens, which can be used for running Ping tests and analysing the results. Refer to the following example configuration for IP routing across a pair of multiplexers:
C H A P T E R
Troubleshooting - example network

If Station A is not successfully communicating with Station B, the following steps should be taken to troubleshoot the network configuration: Local Ping Tests Ping Station A from Node 1 Ping Station B from Node 2 Inter-multiplexer Ping Test Ping Node 2 from Node 1 (or vice-versa) Remote Ping Tests Ping Node 2 from Station A Ping Node 1 from Station B Full Ping Tests Ping Station A from Station B (or vice versa) Selecting the PING test from the menu displays the following screen:
C H A P T E R
The table below shows the configurable parameters and the ranges that may be set: NOTE: Once a ping test has been started, it is possible to leave the test running while you view other screens. The test is stopped by clicking the <STOP> button. NOTE: The parameters on this page are not stored and will be lost over a system reset.
Parameter
Target Count Size Response Timeout(mS) Delay(mS)
Range of Values
IP address nnn.nnn.nnn.nnn. 0-9999 pings 0-1472 bytes 10-30000 0-60000 mS between pings
A simple guide to PING diagnostics is given below:
C H A P T E R
Problem
Local Ping test fails
What to check
IP network configuration on multiplexer & Station: Are the multiplexer ENET port and the station configured on the same IP subnet? multiplexer connectivity: Are other services operating between the multiplexers? IP Subnet config on multiplexer: Does Node1 have a subnet configured to Node 2 with a peer matching Node 2s channel ID? Does Node 2 have a subnet configured to Node 1 with a peer matching Node 1s channel ID? Are the DBAs configured at something other than 0? Are the IP addresses for the unnumbered links set the same for the local ENET port? IP Route Configuration on multiplexer: Is the NoRoutes count in the IP STATISTICS page incrementing? Is there an IP Route to get to Node 2 on Node 1? Is there an IP Route to get to Node 1 on Node 2? IP Route Configuration on Station: Does the station have a route configured that will ensure the ping request to the remote multiplexer node goes through the local multiplexer node? IP Route Configuration on Stations: Does Station A have an IP route configured that will ensure that packets for Station B are routed through Node 1? Does Station B have an IP route configured that will ensure that packets for Station A are routed through Node 2?
Solution
Correct the configuration
Inter-multiplexer Ping test Fails
Standard multiplexer connection troubleshooting Correct configuration
Add routes or enable RIP
Remote Ping Test fails
Add correct route to Station or enable RIP
Full Ping test fails
Add correct route to Station or enable RIP
C H A P T E R
3.2.1.2
The IP ROUTE TABLE menu
The IP ROUTE TABLE, IP STATISTICS, ETHERNET and ARP TABLE screens are for information only. The two tables record the IP routes in use while the IP STATISTICS and ETHERNET pages give detailed packet statistics and Address Routing Protocol conversions and are updated every ten seconds. These may be used to help track down any routing, congestion or filtering problems but require specialist knowledge contact Vocality for details.
C H A P T E R
3.2.1.3
The IP STATISTICS menu
The IP ROUTE TABLE, IP STATISTICS, ETHERNET and ARP TABLE screens are for information only. The two tables record the IP routes in use while the IP STATISTICS and ETHERNET pages give detailed packet statistics and Address Routing Protocol conversions and are updated every ten seconds. These may be used to help track down any routing, congestion or filtering problems but may require specialist knowledge contact Vocality for details. A brief explanation of each is given below: ipForwarding The indication of whether this entity is acting as an IP router in respect to the forwarding of datagrams received by, but not addressed to, this entity. IP routers forward datagrams. IP hosts do not (except those source-routed via the host).
ipDefaultTTL The default value inserted into the Time-To-Live field of the IP header of datagrams originated at this entity, whenever a TTL value is not supplied by the transport layer protocol.
ipInReceives The total number of input datagrams received from interfaces, including those received in error.
ipInHdrErrors The number of input datagrams discarded due to errors in their IP headers, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IP options, etc.
C H A P T E R
ipInAddrErrors The number of input datagrams discarded because the IP address in their IP headers destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., 0.0.0.0) and addresses of unsupported Classes (e.g., Class E). For entities which are not IP routers and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address.
ipForwDatagrams The number of input datagrams for which this entity was not their final IP destination, as a result of which an attempt was made to find a route to forward them to that final destination. In entities which do not act as IP routers, this counter will include only those packets which were Source-Routed via this entity, and the Source-Route option processing was successful.
ipInUnknownProtos The number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol.
ipInDiscards The number of input IP datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly.
ipInDelivers The total number of input datagrams successfully delivered to IP user-protocols (including ICMP).
ipOutRequests The total number of IP datagrams which local IP user-protocols (including ICMP) supplied to IP in requests for transmission. Note that this counter does not include any datagrams counted in ipForwDatagrams.
ipOutDiscards The number of output IP datagrams for which no problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted in ipForwDatagrams if any such packets met this (discretionary) discard criterion.
ipOutNoRoutes The number of IP datagrams discarded because no route could be found to transmit them to their destination. Note that this counter includes any packets counted in ipForwDatagrams which meet this no-route criterion. Note that this includes any datagrams which a host cannot route because all of its default routers are down.
ipReasmTimeout The maximum number of seconds which received fragments are held while they are awaiting reassembly at this entity.
ipReasmReqds The number of IP fragments received which needed to be reassembled at this entity.
C H A P T E R
ipReasmOKs The number of IP datagrams successfully re-assembled.
ipReasmFails The number of failures detected by the IP re-assembly algorithm (for whatever reason: timed out, errors, etc). Note that this is not necessarily a count of discarded IP fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received.
ipFragOKs The number of IP datagrams that have been successfully fragmented at this entity.
ipFragFails The number of IP datagrams that have been discarded because they needed to be fragmented at this entity but could not be, e.g., because their Dont Fragment flag was set.
ipFragCreates The number of IP datagram fragments that have been generated as a result of fragmentation at this entity.
ipRoutingDiscards The number of routing entries which were chosen to be discarded even though they are valid. One possible reason for discarding such an entry could be to free-up buffer space for other routing entries.
C H A P T E R
3.2.1.4
The ETHERNET menu
The IP ROUTE TABLE, IP STATISTICS, ETHERNET and ARP TABLE screens are for information only. The two tables record the IP routes in use while the IP STATISTICS and ETHERNET pages give detailed packet statistics and Address Routing Protocol conversions and are updated every ten seconds. These may be used to help track down any routing, congestion or filtering problems but require specialist knowledge contact Vocality for details.
C H A P T E R
3.2.1.5
The POWER OVER ETHERNET menu
This menu is present when the V150 or V50plus has the power over Ethernet option installed. This menu allows you to view the power used on an option slot. NOTE: This menu is displayed only when multiple option cards are present. If a single option card is present, the following screen is shown instead.
C H A P T E R
3.2.1.5.1
The SLOT x menu
This menu shows the power used by devices connected to the option slot selected (in this case, slot 2). In the example above, a device is connected to port 5 that is using 16 Watts of power. The status line below the table shows the maximum power available (as configured on the SYSTEM page) and the remaining free power.
PORT
Identifies the port on the chosen slot.
STATUS
The status can be Empty, indicating no devices are connected to the port, Non PoE Device indicating a device is connected but it is not a PoE device, and PoE Device indicating a PoE device is connected to the port.
C H A P T E R
DEVICE
- is displayed when the STATUS is Empty or a non PoE device is attached otherwise the class of the attached PoE device is shown. The classes are shown in the table below:
Class
0 1 2 3 4
Minimum Power Levels Output at the PSE (Watts)

15.4 4.0 7.0 15.4 Reserved for future use.
Maximum Power Levels at the Powered Device (Watts)

0.44 12.95 0.44 3.84 3.84 6.49 6.49 12.95 Reserved for future use.
POWERED
Yes indicates the device is currently powered by the power over Ethernet option. No indicates that this is not currently powered by the power over Ethernet option.
WATTS
Shows the power used by the device shown.
C H A P T E R
3.2.1.6
The ARP TABLE menu
This menu provides details of the current internal state of the IP address resolution protocol table of the embedded IP router. You may be asked to provide details of the contents of this table during troubleshooting sessions with qualified multiplexer service personnel.
C H A P T E R
3.2.1.7
The BRIDGE FDB menu
This menu provides details of the current internal state of the bridge forwarding database in the embedded transparent bridge. It indicates which MAC stations have been learned on which bridge ports. You may be asked to provide details of the contents of this table during troubleshooting sessions with qualified multiplexer service personnel.
C H A P T E R
3.2.1.8
The BRIDGE PORTS menu
This menu provides details of the current internal state of the embedded transparent bridging ports. It includes details of the number of packets that have been forwarded (to a learnt destination), filtered (the destination is local) and flooded (multicast packet or unknown destination) through the configured bridge ports. It also provides details of the current spanning tree protocol state of each port if the spanning tree protocol is configured. You may be asked to provide details of the contents of this table during troubleshooting sessions with qualified multiplexer service personnel. This page automatically refreshes periodically if no keys are hit.
C H A P T E R
3.2.2
The DATA PORT STATS menu
This menu displays data about the data ports in use in the V25 or V50plus multiplexer or on the specified V200 or V150 slot. These data ports include serial data ports, IP ports and internal ports used to connect across the system backplane in V200 and V150 systems. A separate page is shown for each port supported. The user may use the <NEXT PORT> and <PREVIOUS PORT> buttons to move through the pages, or may select the port page via the Port field.
SYSTEM UPTIME
Shows the time the multiplexer has been up and running since the last power-cycle.
PORT
Identifies the port in the form slot:channel. Both physical and virtual ports (such as virtual ports used by Aggregates) can be displayed. Statistics for a different port on the slot can be viewed by selecting the <NEXT PORT> button at the top of the screen.
TYPE
Shows the type of ports for example, Serial Data or IP.
C H A P T E R
MODE
Shows whether the port is configured as a Tributary or Aggregate port.
NAME
The name of the IP aggregate or the route name used to create a switched aggregate.
STATE
Shows the current state of the port for example, disconnected.
SINCE LAST CHANGE

Shows the time that has elapsed since the last state change.
CONNECTIONS
Shows the number of times this port has successfully connected.
CURRENT RX CLOCK
Shows the rate the receive clock is currently running at.
CURRENT TX CLOCK
Shows the rate the transmit clock is currently running at.
MINIMUM RX CLOCK
For tributaries only, shows the minimum rate of the receive clock on this port.
MINIMUM TX CLOCK
For tributaries only, shows the minimum rate of the transmit clock on this port.
MAXIMUM RX CLOCK
For tributaries only, shows the maximum rate of the receive clock on this port.
MAXIMUM TX CLOCK
For tributaries only, shows the maximum rate of the transmit clock on this port.
RX PACKETS
Shows the number of packets received on this port.
C H A P T E R
TX PACKETS
Shows the number of packets transmitted on this port.
RX BYTES
Shows the number of bytes received on this port.
TX BYTES
Shows the number of bytes transmitted on this port.
RX ERRORS
Shows the count of receive errors detected on this port.
TX ERRORS
Shows the count of transmit errors detected on this port.
SINCE LAST RX ERRORS

Shows the time since the last receive error was detected on this port if any.
SINCE LAST TX ERRORS

Shows the time since the last transmit error was detected on this port if any.
CURRENT RX RATE
Shows the current receive rate in bits per second.
MAXIMUM RX RATE
Shows the maximum receive rate in bits per second.
SHORTAVG RX RATE
Shows the short term receive rate average in bits per second. This represents the average receive rate over the last 30 seconds (approximately).
LONGAVG RX RATE
Shows the long term receive rate average in bits per second. This represents the average receive rate over the last 30 minutes (approximately).
C H A P T E R
The statistics for this port only can be reset to zero by selecting the <RESET PORT STATS> button at the bottom of the screen. The statistics for all the ports can be reset to zero by selecting the <RESET ALL STATS> button at the bottom of the screen. On the V200 and V150 systems, this button resets all the statistics on the unit.
C H A P T E R
3.2.3
The AGG CALL STATS menu
N.B This menu is only displayed if SWITCHED aggregates are configured in the system.
On the V200 and V150 systems, this menu provides call statistics for switched aggregate ports on this slot. On the V25 and V50plus systems, this menu provides call statistics for switched aggregate ports on this unit. Step through the port statistics pages by using the <NEXT PORT> and <PREVIOUS PORT> buttons at the top of the page - if these buttons are not present there is just a single port to report statistics for. Each page is split into three sections. The top sections report the call statistics for that port since the multiplexer last restarted, and the current state of the port. The middle section reports the call statistics for the last 24 hour period, split into 3 hour segments. The bottom section reports the call statistics for the last 7 days split into 24 hour periods. NOTE: Call statistics are not maintained through a restart of the multiplexer. This page automatically refreshes periodically if no keys are hit.
C H A P T E R
3.2.4
The TRIB CALL SUMMARY menu
This menu identifies all of the voice channels fitted in the current slot and displays their statistics: IN/OUT/IDLE for handling incoming call/handling outgoing call/no call present The time in minutes that the channel has been in that state The Peer: n:s:c of the port that this call is connected to How many calls have been made through this device since restart.
Also at the top of the menu is a summary of the total number of outbound calls made and the number currently active; also the total number of inbound calls received and the number currently active.
C H A P T E R
3.2.5
The TRIB CALL STATS menu
The Trib Call Stats menu is available only when a Digital Voice card is installed.
This menu provides call statistics for voice ports. The call statistics provided are the same for voice ports and switched aggregates. Step through the port statistics pages by using the <NEXT PORT> and <PREVIOUS PORT> buttons at the top of the page - if these buttons are not present there is just a single port to report statistics for. Each page is split into three sections. The top sections report the call statistics for that port since the multiplexer last restarted, and the current state of the port. The middle section reports the call statistics for the last 24 hour period, split into 3 hour segments. The bottom section reports the call statistics for the last 7 days split into 24 hour periods. NOTE: Call statistics are not maintained through a restart of the multiplexer. A "CallIn" represents an external device taking the port "off-hook". A "CallOut" represent the multiplexer taking the device "off-hook". This page automatically refreshes periodically if no keys are hit.
C H A P T E R
3.2.6
The AGG STATUS menu
This menu provides a summary of the multiplexing currently occurring over each aggregate in the multiplexer. The status is provided for each aggregate port in the system - each port's status is on a separate page. Use the <UP> and <DOWN> buttons to cycle through each port. Each line in the status reports the current state of a tributary connection that is multiplexed over the aggregate. This page automatically refreshes periodically if no keys are hit.
C H A P T E R
3.2.7
The SYSTEM INFO menu
The data presented on this menu is for information only. It shows details of the hardware and software revisions currently installed in this slot.
C H A P T E R
3.2.8
The TDM Status menu
This menu provides detailed status information about the TDM connection.
CHANNEL
The Channel/Port being displayed.
<NEXT TDM>
Select using the space-bar to move on to the next TDM port. (In chassis systems such as V150 or V200, this will select between TDM ports on the current card).
OVERALL STATUS
The overall status of the TDM Aggregate: UP : UP-LOOPED: DOWN: Both Transmit and Receive directions are active and calls can be made. Established and Loop detected (either a loopback connection is in place or the peer is configured with the same Node-Id). TDM is not established in both directions.
C H A P T E R
PEER
The Id of the peer automatically detected by the TDM protocol. This is displayed in brackets if the Overall Status is not Up (or Up-looped), to indicate the ID of what was last connected to this port. Note that this information could be out-of-date if displayed in brackets.
TDM MODE
SIMPLEX or DUPLEX, as configured on the TDM ADVANCED CONFIG menu.
TIMESLOTS
The number of Timeslots, as configured on the TDM TIMESLOTS menu.
TRANSMIT STATUS
The status of the TDM in the transmit direction (i.e. of data leaving the local unit). NO_CLOCK: SYNCING-SIMPLEX: START_SENT_1: START_SENT_2: ACTIVE: No clock detected in the transmit direction. The TDM is in the process of initialising and is configured to SIMPLEX mode. In Simplex mode, the Transmit direction will automatically go active without requiring signalling from the peer. The first phase of TDM protocol initialisation when in DUPLEX mode. The second phase of TDM protocol initialisation when in DUPLEX mode. The transmit direction is fully active.
RECEIVE STATUS
The status of the TDM in the receive direction (i.e. of data incoming to this unit from the TDM aggregate). SYNC_WAIT: ACTIVE: The receiver is waiting for the peer to start communicating. The receive direction is fully active
TRANSMIT SPEED
The speed of the transmit direction in bits/sec. *TOO HIGH* is displayed if the speed is higher than that specified for TDM. *NOT 1600 MULT* is displayed if the speed is not a multiple of 1600 bits/sec.
RECEIVE SPEED
The speed of the receive direction in bits/sec. *TOO HIGH* is displayed if the speed is higher than that specified for TDM. *NOT 1600 MULT* is displayed if the speed is not a multiple of 1600 bits/sec.
LOCAL TDM VERS

The version of TDM protocol running on this unit.
C H A P T E R
PEER TDM VERS

The version of TDM protocol running on the peer. 3.2.9 The TDM STATISTICS menu
This menu provides detailed status information about the TDM connection.
CHANNEL
The Channel/Port being displayed.
TIMESLOTS
The number of Timeslots, as configured on the TDM TIMESLOTS menu.
<RESET STATS>
Resets statistics for all TDM ports on this card
C H A P T E R
<NEXT TDM>
Select using the space-bar to move on to the next TDM port. (In chassis systems such as V150 or V200, this will select between TDM ports on the current card). TRANSMIT AND RECEIVE STATISTICS
CURRENT LINE SPEED

The speed of the transmit/receive direction in bits/sec.
TOTAL TIMESLOT B/W (BITS)

The total bandwidth assigned to all configured timeslots (including the timeslots overhead). Calculated on the basis of all timeslots active simultaneously and (in the case of DBA timeslots) running at the maximum rate. Under some situations it is valid for this to exceed the TDM ports line-speed: for example, if DBA is being used; or if multiple Voice channels are present, not all of which may be used at the same time.
FRAMING OVERHEAD
The framing overhead used by the TDM protocol, before considering the timeslots. This comprises the standard signalling overhead (when 16 timeslots are configured, this is 1600 bits/sec) plus any Configured Overhead from the TDM ADVANCED CONFIG menu.
RESERVED TIMESLOT B/W

The total amount of bandwidth "reserved" for Timeslots on this line. This is for the special cases of PATTERN mode and BRD Broadcast voice timeslots: there is no call-control set-up for either of these types of timeslot. The bandwidth is permanently reserved for both of these types. If the total Reserved Timeslot B/W plus Framing Overhead exceeds the current line speed, then the warning *HIGH* will be displayed here since there is no bandwidth available for traffic.
DYNAMIC B/W AVAILABLE

The total amount of bandwidth available in the Dynamic area of the frame. This area is the lowest priority after all other timeslot types and accepts any bandwidth from temporarily unused timeslots. LAST SECOND STATISTICS These statistics show traffic levels for the last complete second for TX and RX directions as follows:
C H A P T E R
TIMESLOTS USED
Count of the number of different timeslots used in the last second.
TIMESLOT USAGE (BITS SENT)

The amount of bandwidth consumed by Timeslots in the last second (including Timeslot Overhead)
DYNAMIC PACKETS SENT

The number of packets sent/received through the Dynamic Area in the last second. LAST TRANSMITTED/RECEIVED FRAME STATISTICS These statistics show the usage of the last Frame transmitted or received. (The TDM protocol sends 50 frames/second each frame corresponds to 20 ms. The Frame size in bits is the line-speed in bits/second divided by 50).
TIMESLOTS IN USE
The number of timeslots carrying payload.
TIMESLOT AREA (BITS)

The amount of data (including timeslot overhead) used by Timeslots in the frame.
DYNAMIC AREA (BITS)

The size in bits of the Dynamic Area of the frame.
DYNAMIC AREA USED

The amount of data (including overhead) used within Dynamic Area of the frame.
DYNAMIC AREA SPARE

The amount of spare space in the Dynamic Area of the frame. LONG TERM STATISTICS These are two statistics which relate to the long-term operation of the TDM link, (Note that both of these relate to the transmit direction).
C H A P T E R
DISCARD TIMESLOT TX PACKETS

The number of packets associated with Transmit Timeslots which have been discarded. Packets may be discarded when DBA changes occur, or on TDM Aggregate failure. Alternatively, this may be an indication that a timeslot has been misconfigured (e.g. a Trib is running at a faster rate than the aggregate).
DISCARD DYNAMIC TX PACKETS

The number of packets which were routed to the Dynamic area which have been discarded.
C H A P T E R
3.2.10 The LOGS menu
The LOGS menu presents a range of more detailed historical information on specific types of event. There is also an overall log which combines them all so as to display everything sequentially, with time stamps. Examples of the individual selections follow.
C H A P T E R
3.2.10.1 The CONNECTION LOG menu
This log shows messages relating to the management of tributary connections. These messages refer to internal multiplexer state machines and protocols and are not intended for customer interpretation. Commands to pause the log storage, resume the log storage, move through the log buffer, and list the entire contents of a log buffer are documented in the LOG HELP page. You may be asked to provide details of the contents of these pages during troubleshooting sessions with qualified multiplexer service personnel. These pages update as new log messages are generated.
C H A P T E R
3.2.10.2 The CONFIGURATION LOG menu
This log shows messages relating to the storage, retrieval and implementation of configurations. These messages refer to internal multiplexer state machines and protocols and are not intended for customer interpretation. Commands to pause the log storage, resume the log storage, move through the log buffer, and list the entire contents of a log buffer are documented in the LOG HELP page. You may be asked to provide details of the contents of these pages during troubleshooting sessions with qualified multiplexer service personnel. These pages update as new log messages are generated.
C H A P T E R
3.2.10.3 The ALARM LOG menu
This log shows messages relating to the major and minor alarms generated on the multiplexer. Commands to pause the log storage, resume the log storage, move through the log buffer, and list the entire contents of a log buffer are documented in the LOG HELP page. You may be asked to provide details of the contents of these pages during troubleshooting sessions with qualified multiplexer service personnel. These pages update as new log messages are generated.
C H A P T E R
3.2.10.4 The CALL RECORD LOG menu
This log shows messages relating to voice and switched aggregate ports going on- and off-hook. Commands to pause the log storage, resume the log storage, move through the log buffer, and list the entire contents of a log buffer are documented in the LOG HELP page. You may be asked to provide details of the contents of these pages during troubleshooting sessions with qualified multiplexer service personnel. These pages update as new log messages are generated.
C H A P T E R
3.2.10.5 The IP LOG menu
This log shows messages relating to the operation of the internal embedded IP router. These messages refer to internal multiplexer state machines and protocols and are not intended for customer interpretation. Commands to pause the log storage, resume the log storage, move through the log buffer, and list the entire contents of a log buffer are documented in the LOG HELP page. You may be asked to provide details of the contents of these pages during troubleshooting sessions with qualified multiplexer service personnel. These pages update as new log messages are generated.
C H A P T E R
3.2.10.6 The SIP GATEWAY LOGS menu
This log shows messages relating to the operation of the SIP gateway. These messages refer to internal multiplexer state machines and protocols and are not intended for customer interpretation. Commands to pause the log storage, resume the log storage, move through the log buffer, and list the entire contents of a log buffer are documented in the LOG HELP page. You may be asked to provide details of the contents of these pages during troubleshooting sessions with qualified multiplexer service personnel. These pages update as new log messages are generated.
C H A P T E R
3.2.10.7 The SVR DEBUG LOG menu
This log shows messages relating to the operation of the Secure Voice Relay module, if fitted to a voice card in this slot. These messages refer to internal multiplexer state machines and protocols and are not intended for customer interpretation. Commands to pause the log storage, resume the log storage, move through the log buffer, and list the entire contents of a log buffer are documented in the LOG HELP page. You may be asked to provide details of the contents of these pages during troubleshooting sessions with qualified multiplexer service personnel. These pages update as new log messages are generated.
C H A P T E R
3.2.10.8 The ALL LOGS menu
This log shows all the log events regardless of their category. These messages refer to internal multiplexer state machines and protocols and are not intended for customer interpretation. Commands to pause the log storage, resume the log storage, move through the log buffer, and list the entire contents of a log buffer are documented in the LOG HELP page. You may be asked to provide details of the contents of these pages during troubleshooting sessions with qualified multiplexer service personnel. These pages update as new log messages are generated.
C H A P T E R
3.2.10.9 The LOG HELP menu
In most cases, the commands are self-explanatory with [S]tart, [E]nd, [U]p, [D]own moving the viewing window to the relevant point in the trace buffer. [L]ist outputs the contents of the whole trace buffer, which may be useful when capturing the trace to a file and [C]lear empties the buffer. The [P]ause command freezes the trace buffer and stops recording status messages. When the[R]esume command is entered, the last page in the buffer is repeated together with the next five messages from live output. The display then continues in real-time.
C H A P T E R
3.2.11 The SNMP STATS menu
This log shows messages relating to the operation of the SNMP. Counts are shown for the different SNMP message types. Commands to pause the log storage, resume the log storage, move through the log buffer, and list the entire contents of a log buffer are documented in the LOG HELP page. You may be asked to provide details of the contents of these pages during troubleshooting sessions with qualified multiplexer service personnel.
C H A P T E R
F E A T U R E S
4
4 Features
4.1 Data Capabilities
DCE/DTE presentation, Sync/Async protocol, clock rate/sources and peer destination. speeds up to 5.12Mbps on all products, with the High-speed CPU and Data cards extending this to 10.24Mbps. Also provided are the ability to clock high-speed data sources using source-synchronous Allocation (DBA), thereby making the most of available bandwidth at all times under varying traffic conditions.
Chapter
Serial data channels are presented with common functionality right across the range of Vocality products, with only a few minor variations. Except where specifically noted in the relevant Hardware Guides, the user can expect to be able to freely configure the Electrical Interface type, Aggregate/Tributary mode,
Synchronous modes give the user the ability to specify clock sources with great flexibility and provide for
clocking in the TTP and TTD modes and the ability to smoothly vary the clock rate by Dynamic Bandwidth
Access to the DATA menu is direct from the SYSTEM menu for the simpler V25 and V50plus products, while the slot-based V150 and V200 have an intermediate menu level for SLOTS. This allows for an architecture where data ports are present on a wide range of cards which can be fitted in almost any Bay. The DATA menu is then accessed in the same way on a per-slot basis. Modem Control signals for all data ports are conditioned the same way, on the SYSTEM menu. Here the user may define the behaviour of the output signals and also how the input signals bring data connections up.
4.2
Voice Capabilities
The Vocality range of multiplexers provides a powerful solution for carrying voice calls in a high-quality, bandwidth-efficient manner. The smaller V25 and V50plus products provide 2-wire analogue telephony and 4-wire monitoring circuits only, which are configured via the VOICE menu. On the V150 and V200 products, both analogue voice and primary rate digital voice interfaces are available, accessed first via the SLOTS menu then by selection of the relevant interface type. In all cases, voice channels may be configured to use one of a wide range of compression algorithms according to the quality and bandwidth profile required. Voice channels are given dedicated bandwidth for the duration of the call and can interact dynamically with data and IP services for optimum bandwidth usage. Voice quality may be optimised using adjustable gain parameters.
C H A P T E R
F E A T U R E S
For efficient Fax, Data Modem or Secure Telephone Unit (STU) calls the voice channels can operate in relay modes, where data may be transferred directly at speeds up to the compression algorithm rate. Here, the DSP in the multiplexer trains locally with the originating device and demodulates the connection back into data, which is passed to the remote channel using the bandwidth-efficient Vocality proprietary protocol, where it is re-modulated before passing out to the terminating device. Analogue ports support Pulse-dialling and DTMF relay, while the digital ports support E1 ETSI Q.931 (DSS1) primary rate ISDN signalling or T1 National ISDN2 (NI2), AT&T 5ESS and Nortel DMS-100 CCS protocols. The products provide considerable flexibility of call routing either through the use of an internal automapping facility which uses the NODE-SLOT-CHANNEL numbering scheme to identify destinations or a Directory menu that allows voice ports on the Vocality network to be mapped to match the numbering scheme being used by the customers installation. Hunt groups allow voice calls to be routed to any available port within a configured group of ports. The hunt group feature makes it possible to route a call to an available port within a hunt group and allow the generation of an outgoing DTMF digit stream on the available port if required. This provides for hot-line extension into a PBX or PSTN.
4.3
Multi-level Precedence and Pre-emption (MLPP)
References: [1] ITU Q955 (03/93) Stage 3 - Clause 3 Multi-Level Precedence and Pre-Emption. [2] ITU Q85 Stage 2 Section 3 Multi-Level Precedence and Pre-emption. [3] Department of Defence Voice Networks. Generic Switching Centre Requirement (GSCR) 8 Sept 2003 Errata change 2 14 Dec 2006. [4] ANSI T1.619 -1992 Integrated Services Digital Network (ISDN) Multi-Layer Precedence and Preemption (MLPP) Service Capability. [5] ANSI T1.619a -1994 (R2007) Integrated Services Digital Network (ISDN) Multi-Layer Precedence and Preemption (MLPP) Service Capability (MLPP Service Domain and Cause Value Changes)
This feature is provided as a Supplementary Service on the primary rate ISDN interfaces available in Vocality equipment, whereby voice calls may be assigned precedence on a per call basis ranging from the lowest precedence, 4 (Routine) to highest precedence 0 (Flash Override). In the case of congestion, either at the terminating user end or within shared network resources, this precedence level may be used to pre-empt (terminate) existing low precedence calls to allow a high precedence call to complete. Preemption can only occur on calls where the parties are assigned to participate in the MLPP feature. This feature provides:
C H A P T E R
F E A T U R E S
ISDN signaling on the primary rate interface to allow MLPP requests incoming to the Vocality network to be processed. ISDN signaling to allow outgoing MLPP requests to be forwarded from the Vocality network across the primary rate interface Transport of MLPP functionality across the proprietary portions of the Vocality network. Pre-emption based on call precedence at each point within the Vocality network where congestion may occur. Participation in MLPP functionality by analogue voice extensions within the Vocality network.
Restrictions and limitations: The optional Look Forward Busy (LFB) functionality detailed in (Ref. [1], Ref. [2]) is not supported. The optional Alternate Party functionality detailed in (Ref. [1], Ref[2]) is not supported. Only voice calls participate in MLPP functionality. In Band recorded announcements detailed in Ref.[3] are not implemented. For incoming MLPP requests received on the PRI, it is assumed that subscriber precedence validation has taken place at the connected equipment and the precedence level being requested is allowed for the originating subscriber. Only one precedence level per PRI span will be allowed, essentially to turn feature on/off, it is assumed connected equipment carries out subscriber precedence checking. Only calls involving parties provisioned to participate in MLPP may be pre-empted. Within the Vocality network only E1/T1 digital voice cards and analogue voice ports currently support MLPP. Other voice ports such as SIP, ISDN BRI etc. do not currently support MLPP.
4.3.1 4.3.1.1
MLPP Service Invocation Primary rate interface
If the PRI is not provisioned for MLPP the call will be treated as a routine call. If no precedence invocation is received in the call SETUP but the destination has MLPP provisioned, the call will be treated as a precedence 4 (Routine) call. If a call SETUP is received invoking a precedence call with a Data bearer capability, the call will be rejected with cause 88 incompatible destination. If a PRI is provisioned for MLPP and a SETUP is received with a data bearer capability and no precedence invocation it will be treated as a routine call. 4.3.1.2 Invoking an outgoing precedence call
In order to invoke a precedence call from an analogue port which has been provisioned for MLPP, the originating user must dial an access code prior to dialing the routing digits. If no access code is recognised as being dialed by an MLPP subscriber, the call will be treated as an MLPP call with precedence 4 (routine). When a valid precedence access code is recognised, the associated precedence level is validated against the maximum precedence level provisioned for that user. If the invoked precedence level exceeds the provisioned maximum, the call will fail.
C H A P T E R
F E A T U R E S
4.3.1.3
Provisioning access codes
The access codes used to invoke a precedence call from an analogue port can be provisioned under the existing directory menu. An access code takes a channel entry in the format <chassis>:P:<precedence>, where precedence is a value from 0 to 4 and denotes the call precedence value associated with this access code.
The above screen is for a hypothetical unit, Node 0 which is connected via an aggregate to Node 1 and also connected to Node 1 via a digital voice card in slot 1. Entry Line1: The precedence level associated with the digit 3 is defined Entry Line 2: If a subscriber wishes to make a routine call to port 1:0:2 via the aggregate, the subscriber would dial the digits 102. If the subscriber wishes to make a precedence 3 (priority) call to port 1:0:2 via the aggregate, the subscriber would dial the digits 3102. In order to successfully invoke MLPP on the call the following would also need to be true: (1) Both subscribers are provisioned MLPP users in the same domain. (2) The calling user is provisioned to a maximum precedence level of at least 3. Entry Line 3: If the subscriber wishes to make a precedence 3 (priority) call over the PRI link to port 1:0:2 the subscriber would dial 3555, this would route to the PRI line and add the dialed digits 102 to the outgoing setup message.
C H A P T E R
F E A T U R E S
Entry Line 4: If the subscriber wishes to make a precedence 3 (priority) call to huntgroup 1 the subscriber would dial 3123. The huntgroup inherits the MLPP settings of its members as described later. 4.3.2 Pre-emption Rules
If a precedence call attempt is made from one MLPP subscriber to another in the same domain and the call cannot complete due to congestion, pre-emption may occur if calls using the congested resource are: MLPP calls in the same MLPP domain potentially overriding calls of lower precedence which will allow the call attempt to succeed
Congestion may take two forms: Access congestion, where the terminating subscriber is busy. Pre-emption in this case is only possible if Access is set to YES. Network congestion. Where elements transporting the call are congested, a user may have a call pre-empted in this case even if Access is set to NO. The diagram below shows possible congestion points when making a call attempt from analogue subscriber B to analogue subscriber A across the Vocality network:
4.3.2.1
Precedence call with no pre-emption
If a precedence call attempt is made it may fail to complete if congestion is encountered at any point and any of the following are true at that point: Congestion is at the terminating user and that users provision is set to Access = NO Insufficient MLPP calls of a lower precedence in the same MLPP domain exist
The call will be treated as a busy call.
C H A P T E R
F E A T U R E S
4.3.2.2
Precedence Call Pre-empted
If a precedence call attempt encounters congestion at any point and the following are true at the congestion point: MLPP calls from the same domain are present MLPP calls of lower precedence are present Clearing lower precedence calls will allow precedence call to complete
One or more of the lower precedence calls may be terminated to allow the higher precedence call to complete. If the congestion is at the terminating user an indication will be given to the terminating user that the existing call has been preempted. If the terminating subscriber is on the PRI this will take the form of a DISCONNECT message with cause 8 pre-emption and Return Error component failureCaseB. If the terminating user is an analogue subscriber a distinctive audio tone will be presented and on the called subscriber hanging up, the precedence call will complete. 4.3.2.3 Precedence Ringback and Cadence
When a precedence MLLP call with a precedence other than 4 (routine) is delivered to an analogue voice port within the Vocality network the ringing cadence of the phone will be changed from the standard ring cadence selected by the country code to a precedence ring cadence as defined in Ref[3]. When a precedence call attempt from a Vocality voice port is successfully delivered to the destination as a precedence call the ringback tone heard in the earpiece will be changed from the standard ringback tone associated with the country code setting to a special ringback tone as described in Ref[3]. When a precedence call attempt is made into a Vocality Digital card and gets successfully delivered as a precedence call a special precedence ringback tone, as described in Ref.[3] gets applied to the bearer channel in place of the standard ringback tone associated with the country code. Note: A ringback tone will only be applied to the bearer channel when the Progress Tone option on the Digital card menu is set to ON. 4.3.3 Interaction with other features
The MLPP functionality interacts with the following V100 features: Hunt Groups The Hunt group itself cannot be provisioned to the MLPP service. The hunt group will inherit the MLPP status of its constituent members. Also with hunt groups the calling party does not actually originate the call, rather it sends a request to the hunt group which interrogates each of its members in turn looking for an available member. It is then the hunt group member that originates the call. The hunt group request will have to communicate MLPP parameters from the originating subscriber to the hunt group which will then interrogate its constituent members as follows:
C H A P T E R
F E A T U R E S
Scan all members for MLPP subscribers of same domain and if available, establish an MLPP call. If not, scan non-MLPP domain members for availability and if found, establish a non-MLPP call. If no members are available at all, scan MLPP domain members for pre-emptable members and if there are any, preempt the call but if not, scan non-MLPP domain members for availability and establish a non-MLPP call if possible. In the event that no available member can be found, the call is not placed. Secondary Routing Should secondary routing be active and the primary aggregate route fails, all calls regardless of precedence will be cleared. Once the secondary route is established normal precedence and pre-emption rules will be applied to any calls re-established.
4.4
Push-Config
Push-Config is a proprietary mechanism for configuring remote multiplexers from a central V200 or V150 hub. The primary aim of Push-Config is to remove the need for multiplexer management skills from personnel in the field, whilst retaining the ability to dynamically change network operation. The ultimate aim is for a factory-defaulted multiplexer to be installed at a remote site, and automatically obtain its multiplexer settings when it is connected to the Vocality network. When in Push-Config mode, a remote unit obtains its configuration when it initially connects to a hub multiplexer therefore only basic serial aggregate connectivity to the hub unit is required in the remote unit configuration. Note that this feature is an optional enhancement to the existing management scheme. It is intended for remote sites in a hub-spoke type network (i.e. not mesh) where there is a single aggregate link in use at the remote site. Note also that TDM aggregates fall outside the scope of Push-Config mode and only standard aggregate types may be configured when using it. A customer may continue with the standard operation mode (where the remote multiplexer carries its own complete configuration) if the restrictions on the push config operation are too inflexible. The implementation of these features is split between the hub and remote sites. The hub site functionality is intended for the V200 and V150 platforms (it relies on the V200 file system to operate). The remote site functionality is provided for V150, V50plus and V25 and platforms. NOTES: (i) The Standard CPU card
supports Push-Config client only - i.e. no Push-Config hub site operation (ii) The High-speed CPU card
supports Push-Config server only - i.e. no Push-Config remote site operation. A V150 at a remote site cannot have a high-speed CPU in any slots if it is to support Push-Config. (iii) A server pushes a client type of V150 and therefore assumes a standard CPU card at the remote site (iv) Push-Config for voice, data, digital voice cards, SIP and a single IP router (in slot0) only. There is currently no support for pushing a config to an IP router in slots 1 or 2 of the V150. (v) There is no slot management config via Push-Config - i.e. you cannot have slot redundancy at the remote V150 with Push-Config operation.
C H A P T E R
F E A T U R E S
4.4.1 4.4.1.1
Push-Config Features Multi-unit configuration at hub site for remotes
The menu system for configuring the remote multiplexers is provided in the management menus on the hub (V150 or V200) multiplexer. The user can select which remote units require a configuration on a hub unit, and then configure that remote unit at the hub site using the standard Vocality menu system. There is no need for the remote unit to be connected during this configuration. The configuration is stored in the file system on the hub site, and can be altered at any time. If alterations are made whilst the remote unit is connected, then the changes will be immediately applied to the remote unit. If the remote unit is not connected, any changes will be applied when it is next connected. To provide the correct menus, the hub site must be told what the installed hardware options on the remote units are. This allows it to provide the correct menu schemes for the remote site. Each remote site configuration contains the parameters that would normally be stored in the numbered edit configuration set. System configuration parameters are not configurable for each remote site they are taken from the hub sites system configuration. Therefore all the system page parameters (except the node number which is configured on the PUSH CONFIG CLIENTS menu), directory page parameters, automapping parameters and alarm management parameters are common between the hub unit and any remote units connecting via this Push-Config scheme. In addition, there is no routing page provided for each remote unit. Push-Config is only intended for remote units with a single aggregate link. Therefore only a default (all nodes) route is required at the remote site this can be automatically installed during the Push-Config operation. 4.4.1.2 Remote Unit Identification
The serial number and platform type of a remote unit are used to uniquely identify it. This allows for Push-Config operation without entering usernames and passwords at the remote sites. The multi-unit configuration at the hub site is keyed from the serial number and platform type. The hub site administrator must configure the hub site with the serial number and platform type of each remote unit that it is hosting the Push-Config feature for. Each remote site must be assigned a node number. This is the node number that is assigned to the remote site whenever it connects to this hub unit. It stays the same regardless of the aggregate that is used to connect to the hub site this allows for static mappings on hub-site tributaries and directory tables used to connect to the remote site tributaries. 4.4.1.3 Pushing the Config
Once the hub-site has authenticated the remote site that is attempting to connect, the hub-site pushes the configuration across the aggregate. The configuration that is pushed comprises the system configuration from the hub unit and the stored configuration for the remote unit that is connecting. The system configuration from the hub site is filtered to ensure that the correct node number and node name is sent to the remote site, and also to ensure that we do not send the hub sites access passwords across the link. Note that the link used to push the configuration may be a shared outbound aggregate, and only the remote unit that requested the configuration should install it. The pushed operation contains
C H A P T E R
F E A T U R E S
checksumming and retry mechanisms to ensure that the whole configuration is transferred successfully even on low quality aggregate links. This configuration is applied to the remote unit (as the active configuration). However the configuration is not stored in the remote unit. When the configuration is applied on top of a remote startup config (see later section), the startup configuration is reapplied to ensure that the aggregate mechanism for accessing the hub site remains in place. 4.4.1.4 Automatic Routing
When a remote unit receives a pushed configuration it installs a default (all nodes) route in its route table via the aggregate link used to connect to the hub. At the hub site, inferred routing is used to install a route to the remote site. 4.4.1.5 Start-up Configs for Remote Units
The default configuration for a remote unit sets a serial data port in aggregate mode for a RS449 interface with external clocking. If this is good enough to establish a link to the hub unit then no configuration is required on the remote unit. However, if a different serial data port configuration is required for the aggregate link or an IP aggregate is to be used, then a basic configuration containing enough details to access the hub unit is required. This portion of the configuration is maintained following reception of the pushed configuration from the hub site. In other words, if the pushed configuration attempts to reconfigure the aggregate link setup in the start-up configuration, the reconfiguration will not work. The default client Push-Config screen is shown below:
C H A P T E R
F E A T U R E S
A DTE presentation is assumed for the Push-Config aggregate port. The Electrical Interface, RXC Source and TXC Source fields may be programmed as follows: INTERFACE RX CLOCK SRC TX CLOCK SRC RS449, V.11, RS232, V.35, RS422, V.36 Ext, Txc, Ext, Rxc, PLL, Electrical interface standard used on the port. RX clock input from the interface RX clock output, looped from TX TX clock input from the interface TX clock output, looped from RX TX clock output, derived from PLL
The Push-config technique may also be used successfully over IP aggregates by toggling the Aggregate Type field to IP. This allows access to enter the basic parameters as follows:
Here, the client remote must be programmed with the minimum basic IP parameters of Address, Mask and Nexthop Gateway in order to connect to the host. The DEF GW OVERRIDE field permits or denies configs pushed out from the host to override the default values stored in this menu. The AGG ADVANCED PARAMS selection displays the following screen:
C H A P T E R
F E A T U R E S
Here is it possible to configure some advanced options such as the TOS value, Mux or Resequence delays and other parameters for use on the Push-Config IP Aggregate if desired. Refer to the IP Aggregates section 2.4.9.3.11 for details. The factory default configuration mode for V25, V50plus and V150 will be for Push-Config operation. If locally set and stored configurations are required, then this mode should be disabled (see section 2.4.1 for more information). 4.4.1.6 Reconfiguration Control
Once a remote unit has its pushed configuration it will operate as normal. However if the aggregate is lost for more than the connection timeout, the pushed configuration is removed and the remote unit attempts to retrieve a new configuration from the hub unit. This means that if a remote unit is connecting to a different hub the Push-Config only works correctly if the aggregate is down for at least the connection timeout between disconnecting it from one hub and reconnecting it to the new one.
4.5
Call Progress Tones
With the ability to dynamically route telephone calls through the network, the multiplexer can act as a small PABX. It is therefore the case that in order to provide the subscriber with meaningful information while a call is connected, the multiplexer must provide audible call progress tones. Many applications for the multiplexer involve a satellite delay between subscribers and so no tones are generated for 600mS after a call sequence is commenced, to avoid confusion during the latency.
C H A P T E R
F E A T U R E S
In the simplest scenario, the telephone is lifted and if bandwidth is available via the prescribed route and the destination party is not busy, the call is connected and the caller hears a ringing cadence, according to the country code selected, until the call is answered. If the call is connected but the destination party is busy, the caller hears an unavailable tone pattern (long beeps, slow repeat). If after the initial 600mS, the call setup has not completed (this can be the case with DAMA networks) but the call timeout has not been reached, the caller will hear a call pending tone pattern (fast beeps, fast repeat). This will give way either to the ringing tone pattern, if successful or to the unavailable tone pattern if the call fails or times out.
4.6
Dynamic Bandwidth Allocation
The versatility of the multiplexer is a direct result of its packetised data transport architecture. Voice/FAX, IP, bridged, synchronous and asynchronous data are processed in a prioritised manner which reflects their individual demands for bandwidth. The primary contention for bandwidth comes from Voice/FAX channels, which demand bandwidth when a call is active and from synchronous data channels, which either demand permanent bandwidth as in the case of a transparent channel, or which may demand bandwidth on a sporadic basis according to the traffic they carry. Dynamic Bandwidth Allocation (DBA) on the multiplexer data ports uses a sophisticated internal rate-change protocol to resolve the problem, which allows bandwidth to vary dynamically (on DBA ports) in both transmit and receive directions independently. Data channels may be set to operate at any speed up to 10.24Mbps. In DBA mode, the maximum clock frequency of a synchronous tributary channel is configured by the user and the multiplexer then varies the actual clock rate applied to the channel according to traffic demand. DBA mode uses the channels RXC and TXC phase-locked loops to generate an internal clock which is output to the connected device. Following any successful new connection, which is routed through the same aggregate as the DBA sync channel, the multiplexer calculates the highest permissible clock rate that is consistent with a total capacity of 87.5% on the chosen route and smoothly varies the output clock to the connected device. This allows a LAN Router with a relatively low loading factor to operate without penalty while the multiplexer simultaneously supports a voice/FAX call. As the voice traffic increases, the multiplexer is able to successively reduce the clock speed to the Router so as to permit high-priority calls to be made at the cost of minor and temporary reduction in Router throughput, which will probably go unnoticed by the LAN users. The clock rate is successively restored as soon as competing connections are closed again. By convention, the TX clock at the local end sets the originating DBA maximum rate and the RX clock at the far end sets the terminating DBA maximum rate. They should be set equal and must both be set. The multiplexer also supports asymmetrical Dynamic Bandwidth Allocation to cater for those cases where network topology produces different bandwidth demands in each direction on an aggregate. In this case, the above rules are still obeyed, but the local TX/remote RX rate and the local RX/remote TX rate are set to different maximum values. In most cases, DBA will be used to drive bandwidth-agile devices such as
C H A P T E R
F E A T U R E S
routers and therefore will be used in V.11 single-clock mode. Here the DBA RX and TX rates are set the same throughout the connection, with the RX clock sources set to TXC. As with all other cases where the phase-locked loops are used, the clock reference(s) must be sourced from the correct internal global clock bus (GRX or GTX). All data channels configured with DBA clock source are assigned a pool of dynamic bandwidth, which is distributed between them in proportion to their configured bit rate. The multiplexer smoothly adjusts the clock speeds on all DBA ports whenever a change occurs in the DBA pool. The rate-change calculations are performed at both ends of the connection, with the overall size of the dynamic bandwidth pool limited by the lowest link bit rate across the network. Asynchronous channels are treated in a similar way, where the configured channel bit rate again defines the proportion of the DBA pool allocated, but this time to the internal connection between the two ends, since the local connection speed out of the port must be set as configured. One extra feature takes advantage of the bursty nature of async data: when data stops, the internal connection speed drops to a nominal 2400bps (or the port speed, whichever is the lower) to maintain the connection ready for use while returning most of the bandwidth to the DBA pool. When the next data character is received by the port, the internal connection rate resumes its normal DBA level. In this way the multiplexer maximises bandwidth use automatically, without the user having to intervene or precalculate any bit rates. IP and bridge tributaries also participate in the DBA scheme. The DBA rate configured for an IP/bridge tributary is the originating DBA maximum rate. At all times the multiplexer optimises buffering and delay so as to maintain voice quality and efficient data transfer. Packet lengths are constantly adapted to match the varying traffic demands of all channel types.
4.7
Asymmetric Bandwidth
The multiplexer is capable of considerable flexibility in clocking schemes and may operate RX and TX clock independently and at different rates. Each direction can use a Phase-Locked Loop (PLL) to generate a clock, which may use either Global clock (GRX or GTX) as its reference. Each PLL is capable of generating an output clock at any rate from 800bps up to 512Kbps in steps of 800bps and from 512Kbps to 10.24Mbps in steps of 8Kbps. Below 800bps, any multiple of 25bps from 50bps upwards may be generated.
4.8
4.8.1
Clocks
Direction Conventions
Every data port supports the same functionality whether it is used as a tributary (DCE) or an aggregate (DTE), the choice being defined by software. By convention, the Receive Clock RXC is defined as the clock associated with the direction of data flow from aggregate to tributary and the Transmit Clock TXC as the clock associated with the direction of data flow from tributary to aggregate. This assumes that
C H A P T E R
F E A T U R E S
aggregate ports are normally DTE presentation and tributaries are normally DCE, so for an aggregate, RX data is input and TX data is output whereas for a tributary, RX data is output and TX data is input.
C H A P T E R
F E A T U R E S
4.8.2
Global Clocks
There are two Global Clock busses internal to the V200 chassis, the purpose of which is to make a common, stable clock signal available to all resources in the system. These are referred to as the GRX and GTX clock busses. GRX and GTX may be referenced to the RX or TX clock from any port and are used as the stable reference source for all of the PLLs on any card in the system. Generally, one of them is associated with the input data clock of the aggregate nominated as the master clock source. This one is then used as the reference source for all tributary ports. GRX and GTX are entirely equivalent and interchangeable. For the purposes of the following discussion, GRX is used throughout. NOTE: V25 supports only a single reference clock GRX. The GRX clock bus is driven by the output of a VCXO which produces a stable frequency of 6.144MHz. Phase-locked loops on the line cards use this as their reference frequency to produce any clocks required by the card. A Gate Array provides the ability to select the clocks (a) used on the interface and (b) routed to the backplane. It also provides the ability to select clocks for DTE mode or DCE mode on the interface. In the example below, part of a serial card is shown in DTE mode with a PLL output routed to the TT pin on the serial port under the control of the Gate Array (red). At the same time the RT signal from the port is routed to the backplane Gate Array, which contains logic to lock the VCXO to it (blue). Using this technique, it is possible to onward-link a clock without degradation from any port to any other in a V200 network, even if it is located in another chassis or even in a remote location via a satellite link. Any number of PLLs may use the GRX or GTX busses as their reference (<GRX or <GTX on the menus).
V200 Backplane Gate Array

VCXO 6.144MHz
GRX Bus
Gate Array PLL Pool other line cards DTE PHY Line Card DCE PHY
RT
ST
TT
Serial Port
C H A P T E R
F E A T U R E S
4.8.3
Receive Clocks
The RXC signal is selected from four possible modes: (i) EXT: (ii) TXC: (iii) PLL: (iv) DBA: The external interface The channel TX clock Derived from a Phase-locked Loop PLL derived as (iii), but the rate can be dynamically varied
A block diagram of the clock logic is shown below, simplified to show only the GRX clock bus and the selection of RXC clock sources in DTE mode:

VCXO 6.144MHz
GRX Bus
PLL Pool CPU
PLL DBA TXC
Gate Array
EXT
DTE PHY Line Card
DCE PHY
other line cards
RXC
TXC
TT
Serial Port
C H A P T E R
F E A T U R E S
4.8.4
Transmit Clocks
The TXC signal is also selected from four possible modes (i) EXT: (ii) RXC: (iii) PLL: (iv) DBA: The external interface The channel TX clock Derived from a Phase-locked Loop PLL derived as (iii), but the rate can be dynamically varied
with the addition of two further modes in DCE mode on a tributary port only: (v) TTP: (vi) TTD: Terminal Timing from external device with ST generated by PLL As (v), but the ST rate can be dynamically varied by the V200
These modes are provided to allow a tributary port to supply a phase-locked ST clock to the DTE whilst at the same time allowing TX data to be clocked into the V200 using the TT clock. This is necessary when the TT clock is derived by the DTE from the ST clock and used to actually clock the data back to the V200. For simplicity, the RX clock is shown with PLL selected and the interface is in DCE mode:

VCXO 6.144MHz
GRX Bus
RX PLL CPU TX PLL

RXC EXT, TTP, TTD PLL, DBA
other line cards Gate Array DTE PHY DCE PHY
Line Card
RT
ST
TT
Serial Port
C H A P T E R
F E A T U R E S
4.8.5
Phase-Locked Loops
All data ports have access to a pool of Phase-Locked Loops (PLLs) for the independent derivation of RXC or TXC. The reference clock for the PLLs is derived from either the GRX or the GTX global clock busses as selected on the configuration menu. The PLLs allow data ports bit rates to be derived in steps of 800Hz up to 512Kbps and in steps of 8Kbps up to 10.24Mbps. See Table 1*PLL rates for details. During DBA rate changes (see Section 4.6) a Glitchless Transition Machine ensures that clocks change rate smoothly without truncation, thereby avoiding data discrepancies between the V200 and the connected device.
4.9
Broadcast Mode
The path from a hub unit to a number of remotes is a Broadcast Mode link (shared outbound aggregate). To use Broadcast Mode, the data port on the hub multiplexer must be configured as PMP mode via the DATA menu (see Section 2.4.9.1). When configuring a shared outbound link, the port at the hub site that is the source of the shared outbound must be configured as point-to-multipoint (PMP) in the DATA menu if (and only if) the return path from one of the remote sites comes back via the same shared outbound port. The ports on the remote sites that receive the shared outbound traffic should be configured as Aggregate (Agg) ports. The remote multiplexers on the shared outbound must be configured with routes to handle all destinations that use the same shared outbound - this is necessary even if the remote sites do not need to communicate with each other. The correct configuration should be that routes to all nodes that are configured at the hub site to use the shared outbound should also be configured to use the returning outbound port at the remote site (except the remote site route itself). Therefore if the default route (ANY node) uses the shared outbound at the hub site, a default route (whose aggregate is the received shared outbound connection) must be configured at each of the remote sites as well.
4.10 Async Error-correction and Compression

This feature allows individual async channels to operate error-free over a satellite link. It does not affect or relate in any way to bulk error-correction that may be taking place within the satellite modem or aggregate link. Asynchronous channels have a single-character field displayed to the right of the FORMAT field when the channel is configured into an async mode. The field allows three selections as follows: R Raw E Error-correction only C Compression Data is passed without error-correction or compression. Data is error-corrected. Data is error-corrected AND compressed.
C H A P T E R
F E A T U R E S
In Raw mode, async data is transferred transparently. The compression mode intrinsically uses errorcorrection, since the compression tables cannot work reliably otherwise. 4.10.1 Error-correction The error-correction function is based on 100mS time periods. Data received by the tributary port is buffered into a 100mS superframe irrespective of channel rate, which is then split into a number of smaller sub-packets according to Dynamic Bandwidth Allocation (DBA) requirements. For example, if the channel is configured with a baud rate of 115,200bps then there will be approximately 800 characters per superframe buffer, which is then sent as a number of small HDLC frames depending on the internal DBA rate, or the size of the logical connection on the aggregate which is allocated to the channel. The underlying rule here is that no subframe or packet on the aggregate should occupy more than 20mS on the aggregate. The error-correction has a window size of 128, so it can correct up to 128 100mS buffers of continuous data, representing roughly 128Kbytes of data at 115,200bps. For surfing/browsing this would improve, since the data is much more sporadic. In practice, only 75% of this buffer is used for safety reasons, before flow control is asserted at the port. This means that at worst case, the error-correction can survive up to 9 seconds without receiving a good frame. The principle used for error-correction uses a NACK-only protocol. This means that a negative acknowledgement packet is sent back whenever a good frame is received out of sequence, since at least one frame in the middle must be missing. This NACK asks for the retransmission of frames starting with the first missing one. Errors experienced on the link affect the whole 100mS superframe, which has to be retransmitted. When the error rate approaches 1 in 10e4 to 1 in 10e5, the error-correction will start to fail since every superframe will be received in error. The technique therefore starts to reach a useful limit at error rates of around 1 in 10e5. When the channel input buffer reaches 75%, as caused by a poor link, insufficient bandwidth or loss of carrier, the CTS signal on the port is dropped by the multiplexer. This signal must be connected to the DTE for the error-correction to work. Loss of carrier is then handled by asserting flow control to stop the input data. Realistically, this means that a channel should continue without data loss through carrier losses of up to at least 5 seconds PROVIDED it is configured so that it does not lose any data. NOTE: The Data Channel Flag parameter on the SYSTEM menu must be set to Follows Alarms for the error-correction to work properly. If the connection is lost for more than 30 seconds then the channel dumps all data, deletes the compression and restarts.
C H A P T E R
F E A T U R E S
4.10.2 Compression The data compression feature uses a derivative of the Lempel-Ziv algorithm with a code size of 12 bits. The algorithm runs above the error-correction layer, which is always enabled when data compression is selected. The 100mS data buffers are compressed and fed into the error-corrector, which builds up a table of 12-bit codes according to the data coming in. If the code table ever fills up completely (i.e. all 212 Code entries are used) then the table is reset and begins to accumulate all over again. Similarly, the compression is turned off whenever the throughput reaches 100%, in which case there is no gain achievable and the data is passed transparently. The compressor also stops operating when the channel goes idle for more than 0.5 seconds and drops into transparent mode. This is to optimise the transfer of single characters or sequences of data less than four characters the compression will only start again when a block of at least four characters are present in a buffer. If for any reason, the compressor turns off, perhaps during a sequence of incompressible data, then it will retry after 5 seconds. This allows it to pick up again to optimise transmission automatically. 4.10.3 General Characteristics Error-correction or compression on channels below 4800bps may start to impose excessive delays. The usefulness of this feature should be carefully assessed before configuration. The operation of the error-correction facility imposes a processing burden upon the host. Testing has indicated that a safe performance limit of up to four channels per chassis running at 57600bps should be observed to prevent any adverse effects on the normal functioning of the unit. Performance degradation may be indicated by a slowing of the supervisor update speed.
4.11 Switched Carrier Operation

Aggregate ports are usually connected via a fixed carrier network, for example a VSAT link. However, the multiplexer also permits operation over switched carrier links where the circuit is available on a temporary basis such as DAMA or SCADA networks. 4.11.1 SWITCHED Mode In this mode the multiplexer Aggregate port is connected to a switched service such as an Inmarsat-B terminal, where the link is inactive and the multiplexer has no carrier with the remote unit until the ISDN link is established. The modem needs to be told when to establish carrier by the mux and this will happen when stimulated by a tributary port being activated. For example, when a telephone call is made from a channel on the mobile unit, link bandwidth is required. This causes the aggregate port to raise the C or RTS signal, which causes the Inmarsat terminal to request service. When the ISDN link is established, the Receiver Ready (RR) signal from the terminal indicates that the connection may proceed, the multiplexers establish carrier, a call setup packet is sent to the hub unit and the user hears dialtone from the PABX. The call proceeds in the normal way until cleared, either by the mobile multiplexer, which drops the RTS signal to the terminal when the handset is replaced or by the hub multiplexer which clears the
C H A P T E R
F E A T U R E S
ISDN call when the line is dropped by the PABX. In both cases the RR signal is dropped by the terminal and carrier is lost. To configure the multiplexer to operate in this way, the aggregate port connected to the Inmarsat terminal must be configured with the word SWITCHED entered in the destination field. In addition, the Connection Timeout and Receive Ready Filter fields on the SYSTEM SETTINGS page become relevant. When an Inmarsat terminal establishes carrier, the RR signal can be unstable until the link is securely established. The Receive Ready Filter ensures that the multiplexer waits for the signal to stabilise before sending its first packet. The ISDN system connection time can be quite long (up to 30 seconds is quite common on Inmarsat networks) and so the Connection Timeout may be adjusted to ensure the multiplexer does not give up too soon. One final point to note is the clocking regime used with the switched system. Inmarsat terminals commonly maintain a 64Kbps clock at all times irrespective of the connection state; in this case the conventional scheme is used where the RX Clock is driven on to the GRX bus. With DAMA modems, since the carrier is not permanently present, the mux must provide a TX clock to the modem at the intended rate. This must also be used as the reference for the voice card, which generates call progress tones during the connection sequence. A standard configuration is shown below:
C H A P T E R
F E A T U R E S
4.11.2 SCADA Mode The aggregate port should be configured with the word SCADA entered in the destination field. This causes the port to adopt the SCADA packetised frame structure which supports the connection protocol of the RF terminal to which it is connected:
The terminals are referred to as RT (or Remote Terminal) units. It is essential that on the ROUTING page, a route to each potential destination RT is entered explicitly, so that the unit knows which address to transmit when establishing a call. This is done in the Connect Using field on the ROUTING page and must be of the format RTnnn where nnn is a numeric field. It may contain up to 14 digits and will be transmitted to the local RT when the call is established:
C H A P T E R
F E A T U R E S
Notice that all RTs are accessed over the primary route 0:1. This is because in our example, Port 1 of the chassis is used as the aggregate port in SCADA mode and is connected to the local RT unit. All other units must be programmed in a similar way (they will of course contain a route to Node 0, our local node) and then voice calls may be made between any stations. As with the standard fixed-link mode of operation, destination channels for voice calls may be either entered as specific channel numbers for hotline operation or left in AUTO mode, when the multiplexer destination channel number is dialled on the telephone. Thus, to place a telephone call to voice channel 3 in Option Card 1 of Node 2 from anywhere in the network, pick up the receiver and dial 213. The routing menu tells the unit how to reach Node 2 and which destination RT number to transmit to the local RT to establish the link. Once the link is established, the rest of the dialled number tells the receiving unit which channel to route the call to. During placement of the call it is normal to hear a succession of rapid beeps denoting establishment of the link. This will then be followed by a ringing tone when the connection is made. If the link cannot be established due to network congestion, the user will hear the normal busy tone in the handset. All of the normal multiplexer voice channel facilities are still available in SCADA mode and so for example may be used to connect to PABX extension ports in FXO mode or between PABXs over the 4-wire Tie-line interface. Group III FAX machines or modems may also be used. To prevent any unintended call or bandwidth charges, Voice Activation may be utilised.
C H A P T E R
F E A T U R E S
4.12 The Integrated IP Router

4.12.1 Overview This section describes the basic concepts behind the integrated IPV4 router available on each CPU card. It is assumed that the reader has a basic understanding on the operation of an IP router and the operation of other services in the multiplexer. The section includes configuration examples for typical installations and troubleshooting tips however, it is not intended to fully describe the user interface please refer to the MENUs section for these details. 4.12.2 Basic IPV4 Routing The multiplexer integrated IP router forwards data from one LAN to another across a multiplexer WAN link. This is achieved by establishing a connection from one node to another and assigning it a maximum bandwidth over the aggregate in a similar way to a DBA data channel. Once this is established, the IP router at each end performs the filtering or forwarding of all traffic relevant to the remote network according to a manually entered static route table. The router may act as a local DHCP server and supports UDP broadcasts to support WindowsTM applications. 4.12.3 Network Configuration The multiplexer includes routing software for forwarding IP data between the 10/100/1000base-T Ethernet ports and aggregate ports. To utilize this facility, the multiplexer must be configured with information about the IP sub-networks that the multiplexer network is interconnecting. All configurations must include at least: IP address and subnet mask for the Ethernet port(s) Configuration of how the IP router connects to the multiplexer network Configuration of static IP routes Configuration of the first two components is done through the NETWORKS screen of the IP sub-menu. The NETWORKS screen describes how the IP router connects to both the local LAN (or LANs) and the multiplexer WAN network. The Ethernets are represented in the user interface with the port names ENET1 and ENET2. The Ethernet must be configured with the IP address of the Ethernet port on the local network, and the mask of the local subnet. Any host stations (PCs), or routers on this local network, must be configured to use the IP address of the multiplexer Ethernet as the next-hop gateway for all IP networks that the multiplexer is providing interconnect services for. In the example below, the Ethernet port has been configured with the address 192.168.1.1, and the mask 255.255.255.0 this mask will allow the configuration of 253 other IP stations on the local network (two addresses are also reserved for broadcast use). The Maximum Transmission Unit (MTU) in bytes is typically left at the default value of 1514 for the Ethernet port. The UDP Gateway (UDPGw) option is discussed later in the UDP relay section. The DBA and
C H A P T E R
F E A T U R E S
Destination fields are not used for the Ethernet port. The IP field is be fixed at NUM (for standard numbered packet support) for the Ethernet port.
Example of IP Subnet configuration for Ethernet

With just a single IP network entity configured on the Ethernet port, the multiplexer can communicate with IP stations on the locally connected network, but will not yet route IP traffic over the multiplexer network. Further network entries must be configured for this however, unlike traditional wide-area network routers, IP networks are not configured directly for the aggregate ports to the multiplexer network as this would by-pass the multiplexer bandwidth management facilities provided by the multiplexer data router. Instead, the concept of virtual ports (see below) is used to represent the wide area networks of the IP router. 4.12.4 Virtual Ports IP connectivity is provided across the multiplexer network as a set of point-to-point connections between multiplexers with integrated IP capability. The IP router forwards traffic between the Ethernet ports of pairs of multiplexers via the multiplexer network. A point-to-point connection between the IP router on a multiplexer and the corresponding IP router on a peer multiplexer is represented by a virtual port, which works in the same way as any other multiplexer channel but does not have a physical connector. The IP router is fully integrated with the other multiplexer services. It interfaces to the multiplexer Data Router for interconnectivity across the multiplexer network. The multiplexer Data Router is built on the concept of connecting peer logical ports across the multiplexer network via aggregate links. Each tributary
C H A P T E R
F E A T U R E S
has a port number that is unique within the multiplexer network. The diagram below shows how the integrated IP router interfaces with the multiplexer Data Router via these tributary ports, and includes a voice card for comparison.
Aggregate Ports
Data Router
Tributaries IP Subnets for WAN
Voice Card (e.g.)
Voice Channels
IP Router
IP Subnet for Ethernet
The Interaction of the IP Router with Data Router

Tributary ports are represented by a port number. These typically provide information about the location of the tributary port the 4 voice ports on a voice card are represented as n:s:c, where n is the node number, s is the slot number that the voice card is inserted in, and c is the channel number within the voice card. A set of special virtual ports has been reserved to represent the IP router WAN ports. These follow the standard multiplexer port terminology of n:s:c. The slot component of the channel identifier is the slot number of the CPU card that the integrated IP router and 10/100/1000BT Ethernet ports are on. Channels 10 to 99 have been allocated for IP router operation. A separate channel is required for each integrated IP multiplexer router that this unit peers with. The network configuration requires that the peer channel is configured for each channel configured on the local router. In the example below, Node1 is connected to both Nodes 2 and 3. The integrated router on all three nodes is in slot 0. Channel 0:10 on Node 1 is peered with channel 0:10 on Node2. Channel 0:11 on Node1 is peered with Channel 0:10 on Node 3.
C H A P T E R
F E A T U R E S
Example of virtual port use

4.12.5 Unnumbered IP The integrated IP router acts as a half-router a pair of IP routers connected via the multiplexer network provide the full router operation. To preserve IP addresses, the point-to-point link between the multiplexers does not require an IP subnet configuration. When IP traffic is routed over the point-to-point connection, it can only be received by the peer unit, and therefore IP addressing is not necessary. If host IP services are run from the multiplexer across the multiplexer network, then the IP address on one of the Ethernet ports can be used as the source address for host communications. The sample IP NETWORKS menu page below shows the configuration of the IP virtual ports for Node1 from the earlier example.
C H A P T E R
F E A T U R E S
Example configuration of IP virtual ports

Each virtual port requires a DBA (Dynamic Bandwidth Allocation) and Destination configured. The DBA is the maximum bandwidth (in bits per second) of IP traffic that can be sent to the peer multiplexer the actual amount is determined by the data routers in the multiplexer network according to other offered loads). The destination is the virtual port identifier on the remote device that we are peering with. The IP field indicates that we are running unnumbered IP across this link the IP address and mask should match the ENET address and mask to allow for host operations from this virtual port. The MTU (maximum transmission unit) is discussed below. One quirk of IP unnumbered operation is that IP routes that are configured for IP networks across the multiplexer network must be configured with a next-hop that identifies the unnumbered link to transfer that data across, instead of an IP address of the next-hop gateway. This is discussed further in the section on Static Routes. 4.12.6 MTUs The Maximum Transmission Unit or MTU for an IP network specifies the largest datagram that may be transmitted on to that network. Routed packets that exceed the MTU for the onward network are fragmented before transmission over the multiplexer network and are reassembled by the peer multiplexer unit. The default MTU for the Ethernet is 1514 this allows transmission of the maximum sized Ethernet frame (the 4-byte CRC is not included in the MTU).
C H A P T E R
F E A T U R E S
Most servers are on segments with large MTUs, but it is increasingly common for internet users to be connected via links with reduced MTUs, so it is becoming common for some packets to be too big. How the problem of oversize packets has been handled has evolved considerably over time. The original approach was to send only small packets corresponding to the TCP/IP default MTU (576 bytes). (To this day, a sending system needs permission from the receiving system to send larger packets, but that permission is given as a matter of routine.) For some packets, especially those sent by older equipment, an oversize packet can be sent by breaking it into fragments and sending the fragments as smaller packets. The fragments can be reassembled downstream to reconstruct the original large packet, but this packet fragmentation has several problems involving both efficiency and security. Newer servers try to optimise their transmissions by discovering the path MTU and sending packets of the maximum size when there's enough data to fill them. The procedure for doing this was standardised and published as in RFC 1191 1990, but it did not become widely deployed until years later. By mid 2002, 80% to 90% of computers on the internet used Path MTU Discovery. The basic procedure is simple - send the largest packet you can, and if it won't fit through some link get back a notification saying what size will fit. The notifications arrive as ICMP (Internet Control Message Protocol) packets known as "fragmentation needed" ICMPs (ICMP type 3, subtype 4). The notifications are requested by setting the "do not fragment" (DF) bit in packets that are sent out. Some network and system administrators view all ICMPs as risky and block them all, disabling path MTU discovery, usually without even realizing it. Of the several dozen ICMP types and subtypes, some do pose some risk, but the risk is mostly mild and is of the "denial of service" nature. That is, an attacker can use them to interfere with service on and from the network. By blocking all ICMPs the administrator himself interferes with service on and from his own network. Unless he also turns off path MTU discovery on his network's servers, he makes his servers unusable by users with reduced-MTU links in their paths. Because service is affected only in relatively unusual cases, it can be difficult to convince the administrator that a problem exists. The prevalence of such "unusual" cases is growing rapidly though. Administrators who want to block all ICMPs should disable path MTU discovery on their computers, especially on their servers. It makes no sense to ask for ICMP notifications and then refuse to accept them. In addition, doing so opens the server to a special type of distributed denial of service attack based on resource exhaustion from a large number of fully-open connections. Clearly all of the above requires careful setup by the network administrator but it can still lead to basic incompatibility when trying to access certain internet servers. The other disadvantage is that even if reduced MTUs are allowed, the fragmentation potentially resulting from it causes a significant additional overhead due to the increased number of packet headers (each typically containing 20 bytes in an IP packet) and ultimately reduced throughput due to the burden of additional packet processing. The IP Router avoids this by providing its own proprietary fragmentation over the multiplexer WAN network, which uses only a 4-byte header to optimise throughput, while appearing to pass the original packets sent by the network transparently. Setting the multiplexer MTU requires some care in configuration to avoid degradation of the quality of voice channels (or other services) that are multiplexed across the same aggregates as the IP traffic. It is recommended that a value for the multiplexer MTU is calculated which
C H A P T E R
F E A T U R E S
avoids the creation of any packets that will take longer than 20ms on the slowest aggregate between the local multiplexer and its peer. The MTU should be set according to: MTU = LS/400 where LS is the slowest link speed (in bits per second) on the aggregate link to the peer. If the calculated MTU exceeds the MTU for the Ethernet, then the MTU for the multiplexer channel should also be set to 1514. In the case of a link running at 64Kbps, the MTU should therefore be set to (64000/400) = 160. Note that fragmentation has an overhead in both the computation required on the multiplexer, and the bandwidth required to send data (each fragment carries an IP header), and you should avoid setting the MTU below the recommended value unnecessarily.
C H A P T E R
F E A T U R E S
4.12.7 RIPv2 and OSPF The implementation of Routing Information Protocol version 2 (RIPv2) is described in IETF RFC 2453/STD56 and is provided as an extension to the existing embedded IP router functions within the Vocality multiplexer family. This functionality simplifies the integration of Vocality multiplexers within customers IP networks as it removes the need to configure static routes on both the mutliplexers and IP gateways. It also allows for dynamic re-routing of IP traffic when network components fail. RIP may be used on both the LAN interfaces and the IP tributaries across the Vocality network. When used across the IP tributaries, any bandwidth required for protocol datagrams is shared with other IP routed packets taken from the dynamic bandwidth allocated for that tributary. Each device must be configured for RIPv2 operation or with static routes to tell it how to reach IP networks other than the one that it is locally attached to. A RIPv2 menu screen is provided under the IP sub-menu to configure RIPv2 operation. RIPv2 should not be used on the IP Tributaries in situations where the tributary operates across a switched aggregate since the RIP updates will keep the aggregate permanently established. The following features are supported: Import Control Enabled/Access/Disable Metrics Export Controls: Enable/Disable/Filter Static/RIP routes Enable/Disable/Filter OSPF routes Enable/Disable/Filter local interface routes MD5 authentication System wide poison reverse control
Support for the Open Shortest Path First (OSPF) protocol (as defined in RFC 2328) is also included. OSPF is a router protocol used within larger autonomous system networks in preference to RIP, an older routing protocol that is installed in many of today's corporate networks. Like RIP, OSPF is designated by the Internet Engineering Task Force (IETF) as one of several Interior Gateway Protocols (IGPs). Using OSPF, a host that obtains a change to a routing table or detects a change in the network immediately multicasts the information to all other hosts in the network so that all will have the same routing table information. Unlike the RIP in which the entire routing table is sent, the host using OSPF sends only the part that has changed. With RIP, the routing table is sent to a neighbor host every 30 seconds. OSPF multicasts the updated information only when a change has taken place, making its use of bandwidth resources considerably more efficient. Rather than simply counting the number of hops, OSPF bases its path descriptions on "link states" that take into account additional network information. OSPF also lets the user assign cost metrics to a given host router so that some paths are given preference. OSPF supports a variable network subnet mask so
C H A P T E R
F E A T U R E S
that a network can be subdivided. RIP is supported alongside OSPF for router-to-end station communication. Since many networks using RIP are already in use, router manufacturers tend to include RIP support within a router designed primarily for OSPF. The following features of the OSPF protocol are supported: Control per router interface RFC1583 backward compatibility mode Access control Normal, Stub & NSSA Areas Simple & MD5 authentication Virtual Links
In the Vocality implementation, policies for controlling which routes are used and how they are used may be configured on the unit. This provides some control over: RIP export policies OSPF export policies Route aggregation Route preference between different route sources
4.12.7.1 Compatibility The implementation of RIPv2 is compatible with RFC2453/STD56. The implementation includes split horizon with poisoned reverse to avoid routing loops. Triggered updates are also sent to speed up network convergence. Updates are triggered when routes change and/or interfaces (Ethernets or IP tributaries) go up or down. Route summarization is not supported. All timers used in the RIP process use the values specified in the RFC: Unsolicited response every 30 seconds Route timeout after 180 seconds Route garbage collection after a further 120 seconds Route updates received on a LAN interface will be verified to ensure that the router that sourced the update is recognised as being on the same subnet that is configured for that interface.
Note that there is no support for RFC2082 RIP-II MD5 authentication. Each IP network interface configured on the multiplexer may have RIPv2 support either enabled or disabled. When enabled the multiplexer generates and processes RIP messages on UDP port 520. When disabled, the multiplexer does not open access to this port. The default value for RIPv2 support is DISABLED. If RIPv2 is enabled on an IP tributary interface, it is expected that the RIPv2 feature is also enabled on the peer IP tributary across the Vocality network.
C H A P T E R
F E A T U R E S
4.12.8 Static Routes If the RIPv2 and/or OSPF protocols are disabled, each multiplexer IP router must be configured with static routes to tell it how to reach IP networks other than the one that it is locally attached to. An IP STATIC ROUTE TABLE menu screen is provided under the IP sub-menu to do this. Each configured route consists of a description, a destination address, a mask for the destination address and a next-hop. The Description is a text field used to identify a route in the configuration. The Next-hop is either the IP address of the next-hop gateway on the local Ethernet network, or the channel number for a unnumbered link to a peer multiplexer across the IP network. When a route lookup matches more than one configured route, the one with the longest mask (i.e. the most specific) is used to route the packet. A default route (one to use if all other route lookups fail) can be configured by using a destination and mask value of 0.0.0.0. The following example shows a route table that will send all traffic to network 192.168.0.1/255.255.255.0 via the unnumbered link 0:10, and all other traffic to the next-hop gateway 192.168.3.100:
Example of IP Static Route Configuration

4.12.9 Loopback Interfaces Loopback interfaces may be configured in the IP networks menus. These allow for a host (i.e. non-router) address to be assigned to each of the Ethernet interfaces on the embedded router. These interfaces remain up even when the associated Ethernet interface goes down. The addresses used on these loopback interfaces can be used as the unnumbered source addresses for the IP tributary ports. These addresses are typically an unused address on the Ethernet subnet.
C H A P T E R
F E A T U R E S
4.12.10 Example Configuration Portions of example configurations have been given in the above sections. This section gives a complete example IP configuration for a simple 3-node network. Three remote networks are interconnected with multiplexers. Node 1 is connected to the 1.1.1.0/255.255.255.0 network. Node 2 is connected to the 1.1.2.0/255.255.255.0 network. Node 3 is connected to the 1.1.3.0/255.255.255.0 network. The multiplexer network provides connections between Node1 and Node2, and Node1 and Node 3. Virtual ports 0:10 and 0:11 on Node 1 have been configured to communicate with Nodes 2 & 3 respectively. A default network is not defined at Node1, so traffic from Node 2 and Node 3 networks will only communicate with stations on the 1.1.1.0, 1.1.2.0 and 1.1.3.0 networks, and nothing beyond. The dynamic bandwidth allocation and MTU for all multiplexer channels is set at 256000. A network diagram of this example configuration network is given below:
Example configuration network diagram

The following six screen samples show the IP network and static route configuration for all three nodes to achieve this topology:
C H A P T E R
F E A T U R E S
Screen #1: IP Network Configuration for Node 1
Screen #2: IP Route Configuration for Node 1

C H A P T E R
F E A T U R E S

C H A P T E R
F E A T U R E S

C H A P T E R
F E A T U R E S
4.12.11
UDP Relay
Standard IPV4 router operation does not allow for the forwarding of subnet broadcasts. However certain network applications rely on the relay of UDP packets sent to the subnet broadcast address. For example WindowsTM browsing service relies on Netbios datagram service packets (addressed to UDP port 138 and the IP subnet broadcast address) reaching all stations within the browsing domain. To allow seamless operation of such applications across the IP ports of a multiplexer network, the ability to relay UDP subnet broadcasts has been provided. To enable such operation the UDPGw configuration must be turned to On for each port that we wish the relay operation to work on. Additionally, an entry in the UDP relay table must be added for each service that must be relayed. Some well-known service types are pre-configured for addition to this table other services require the appropriate UDP port number to be configured. The example configurations shown in below show the configuration required to relay NetBIOS datagrams (UDP port 138) and subnet broadcasts to UDP port 200 between the Ethernet and multiplexer channel 0:11 (but not to 0:10). Note the NetBIOS Name and Domain Name ports have also been included since they will be required to get legacy WindowsTM networking working smoothly:
Example IP Network configuration for UDP relay
When using UDP relay care must be taken to ensure that broadcast loops are not introduced into the network. The multiplexer will ensure that the affects of such loops are minimised through TTL reduction, but network operation will still be adversely affected.
C H A P T E R
F E A T U R E S
Example UDP Relay Table configuration

4.12.12 TCP Gateway (TCP PEP)
The TCP gateway provides a TCP performance enhancing proxy (PEP) providing optimisation of TCP traffic carried over high latency aggregates. To enable the optimisation the TCP gateway function must be enabled on the IP network entries that the traffic is routed through. Up to 32 (255 on high-speed CPU cards) simultaneous TCP connections may be optimised at any one time. Note that the optimisation feature only applies to TCP traffic that is routed through the multiplexer, If the TCP traffic is bridged, or the TCP traffic is encrypted within an IPSec tunnel then the optimisation is not performed. 4.12.13 DHCP Client/Server/Relay
The multiplexer has three modes of operation for DHCP (Dynamic Host Configuration Protocol). The mode and other DHCP parameters are configurable on the GENERAL page from the IP sub-menu. The default mode is OFF in this mode the multiplexer does not take part in DHCP operation it is assumed that all stations on the local network have a static IP configuration, or that a separate DHCP server is available on the local network, or an externally routed network. When the product is not configured for IP router operation, an external DHCP server can be used to assign an IP address to an Ethernet interface. To achieve this, the Address and Mask fields in the IP NETWORKS menu should be configured as 0.0.0.0. When the DHCP server assigns an address, a default route to the default router assigned by the DHCP server is automatically installed in the IP route table.
C H A P T E R
F E A T U R E S
Above: Network configuration when DHCP server mode is OFF

In SERVER mode, the multiplexer has an embedded DHCP server that will respond to received requests from clients:
Above: Example network configuration for DHCP SERVER mode

The embedded DHCP server can provide the following host configuration parameters in response to received DHCP requests: IP Address, Lease Time, WINS Server, Domain, DNS Server Address The DHCP server only operates on ENET1.
C H A P T E R
F E A T U R E S
The IP address is assigned from the (inclusive) range configured in the GENERAL parameters the address range should be from the range of addresses on the subnet configured on the ENET port of the multiplexer. This range should not contain the address configured for the ENET port itself however. The DNS Server address sent to the DHCP client (the other side of the multiplexer network) must be entered into the DNS SERVER address configured on the GENERAL page of the IP configuration. A secondary server address can also be entered. Finally, the IP address of the WINS server and its domain name should be entered. Note that these fields are used by the multiplexer in its name lookup for ping requests. An example of the GENERAL page configured for DHCP server operation is shown below:
Example GENERAL page for DHCP mode

In RELAY mode, DHCP requests are relayed to a remote DHCP server through the multiplexer requests are relayed to the addresses configured in the primary and secondary server addresses in the DHCP server configuration:
C H A P T E R
F E A T U R E S
Example network configuration for DHCP Relay mode

For this example network, the DHCP relay parameters would be set as follows:
Example configuration of DHCP Relay parameters
Note that this configuration is required on both Node 1 and Node 2. The DHCP relay operation only works on ENET1.
C H A P T E R
F E A T U R E S
4.12.14
Telnet Access
The integration of an IP stack into the multiplexer allows the supervisor configuration screens to be accessed through the Ethernet port using the telnet protocol. Telnet access is possible once IP has been configured. To provide additional security to ensure that telnet access is only granted to the appropriate parties, an Access Table has been provided. The Access Table must be configured to specify which station or group of stations are allowed access to IP host facilities on the multiplexer. Each access table entry comprises a description (simple text not used in the access decision), an IP address, an IP mask, and a service definition. When an attempt is made to access the host service (e.g. a telnet connection is requested), the access table is checked to ensure that an entry matches the requesting host. An IP address/mask pair of 0.0.0.0/0.0.0.0 will allow access from any station to the configured service. The services that are controlled through this access are currently (i) the embedded telnet server, and (ii) Chargen (character generator) TCP server. The following example configuration shows two entries one is allowing telnet access from any station the second is allowing Chargen access only from station 1.1.1.6:
Example configuration of the Access Table
C H A P T E R
F E A T U R E S
4.12.15
Spanning Tree Protocol
The spanning tree protocol is an implementation of IEEE802.1d. The protocol may be enabled on individual bridge ports by changing the Bridge mode in the Networks Menu (see Section 2.4.9.3.2). The spanning tree protocol is used to detect and prevent loops in bridged networks. If the multiplexer is bridging in a network topology that contains loops then the Bridge mode should be set to STP on each port that makes up part of the looped network - the port takes part in the spanning tree protocol and forwards bridged traffic when the spanning tree protocol determines the port is in a forwarding state. If the multiplexer is bridging in a network topology that does not contain loops then the Bridge mode should be set to On the port does not take part in the spanning tree protocol and forwards bridged packets. The spanning tree protocol operates between the bridges in a looped network, and produces a tree structure of bridge ports. Ports that would complete network loops are put in a blocking mode and do not actively forward bridged packets. The tree topology is determined by the relative priority of each bridge in the network and the relative path cost assigned to bridge hops. The multiplexer bridge priority can be configured here in the GENERAL menu. The port priority is set to a default of 128 and cannot be altered. The relative path cost assigned to each bridge port is calculated as 19 for the Ethernet port and (1000000000/assigned DBA rate) for multiplexer tributary ports. Note that the Spanning Tree Protocol relies on the periodic sending of "hello" bridge protocol data packets. When the multiplexer is determined to be the root bridge in the spanning tree network, the period of sending these "hello" packets is set to the HELLO TIME configured in the general menu. This periodic sending of spanning tree protocol packets makes the use of STP undesirable is dial-up networks.
4.13 IP Aggregates
The IP aggregate feature allows tributary services such as voice, data and IP to be transported across an IP network between Vocality systems. All tributary services that are available across data aggregate links are also available across an IP aggregate link - this means that Vocality's dynamic bandwidth allocation scheme allows for bandwidth management of voice and data services across the IP network. A proprietary protocol running over UDP provides an efficient mechanism for carrying data and voice or for tunneling IP across any IP network. The protocol also allows for a reference clock to locked between the Vocality units at either end of an IP aggregate. Configuration parameters are provided to allow the user to optimize bandwidth usage, at the expense of delay and jitter. For optimum results, the intermediate IP network should be able to provide a guaranteed quality of service (QoS). The IP aggregate can be configured to generate packets with a specific ToS marked to allow the network to route the traffic with the correct QoS. The Push Config startup menu can access the IP Agg configuration menu so that all aggregate fields can be configured. The IP Push Config also allows for the DNS server to be configured so that the IP Agg can be configured via DNS name. Also the Push Config server at the hub site has an option to allow the Push Config client clocking to be configured to the IP Agg since the IP Agg itself does not appear in the client configuration.
C H A P T E R
F E A T U R E S
An authentication field is provided for IP aggregate configuration. This is used to identify "connection" attempts from unknown peers who have come through NAT gateways. The authentication info must match on both ends of the IP Agg for the aggregate to be valid. The authentication scheme itself is based on a random challenge scheme to avoid replay attacks. The authentication will be used only when configured - if it is not configured for an IP Agg then the aggregate will work anyway - if the peer is unknown we will accept a "connection" from any unit.
4.14 TDM Aggregates

For many applications, the standard packetized Vocality networking protocol is a flexible and versatile transmission standard well-suited to dynamic applications with varying bandwidth demands and proven in many complex mesh topologies. However, for some point-to-point applications where bandwidth is critical and link conditions are challenging, Time-Division Multiplexing (TDM) is an alternative Aggregate protocol which confers the following benefits: Greater bandwidth efficiency Radio Silence mode option Limited/zero Error Extension depending upon call-type
The potential drawbacks of TDM mode are: Longer latency More complex to configure Higher processing burden
The fundamental characteristic of a TDM protocol is a fixed, repeating frame structure, which is split into a number of timeslots. The bandwidth requirements of each tributary channel are met by assigning a number of timeslots for each one according to its needs. The predictable nature of the frame structure requires less bandwidth to be used on overheads such as the lengths, flags or checksums which are used by packetized protocols. Historically the rigid nature of the frame means that, to take maximum advantage of the bandwidth, the timeslots must be permanently used and cannot adapt to dynamic traffic patterns, which ironically leads to inefficiency. The Vocality implementation overcomes this by using a small, error-corrected header section which dynamically defines the makeup of each frame as it is transmitted. Overall efficiency gains are made in many ways: Some types of traffic are Constant Bit Rate (CBR) and therefore need no length byte in the timeslot at all since the quantity of data never varies; the aggregate data format is purely transparent synchronous without the HDLC zero-bit insertion of packetized formats; bandwidth is recycled dynamically when there is no data for a particular timeslot. This latter technique requires the existence of a Dynamic area in the frame which can grow and shrink; it is an ideal bucket for IP traffic, making the most use of available bandwidth at all times.
C H A P T E R
F E A T U R E S
4.14.1 TDM Aggregate Specification Line Speed: 9600 2048000 bits/sec. Line speed must be a multiple of 1600 bits/sec. Requires stable line speed. Asymmetric line-speeds are supported. Minimum overhead : 1600 bits/sec Timeslots: Multiples of 400 bits/sec Timeslot range supported : 400 2046400 (i.e. 2048000 minus the minimum overhead of 1600 bits/sec) For user convenience when using DBA, the menus permit 2048000 to be specified. Some types of timeslot require minimum timeslot size of 2400 bits/sec. Asymmetric tributary rates are supported (except when using DBA) Latency: In order to operate without error, TDM will potentially have a higher latency than conventional NRZ Aggregates. Efficiency: Up to 99.92% dependent upon frame structure. Simplex and Duplex operation. TDM3 Tunnelling (i.e. TDM3-over-TDM3 operation) is supported, with limitations. Physical interface: Same range of physical interfaces as conventional Aggregates (RS-449 etc). Error Extension: TDM connections can run without Error Extensions for certain types of timeslot. Push Config: TDM is not supported by Push Config.
4.14.2 Targets Supported
TDM Aggregates are supported on the following systems/cards: V25 V50+ Standard CPU Card 68151 (V150/V200) High Speed CPU Card 68201 (V150/V200) Quad Serial Card 68204 (V150/V200) on first 4 ports only
It is not supported on the following: V50 V100 V150/V200 Serial Expansion Card 68205 on ports 5-12
4.14.3 Interworking TDM3 is a new feature introduced in version 4.9.1. It is not present on earlier versions. For full compatibility, peer units must be running version 4.9.1 or later, even if TDM aggregates are not used. This is because the convention used for rounding serial port line speeds has been changed. The range and
C H A P T E R
F E A T U R E S
granularity of speeds supported on serial ports is finite: we can only generate specific multiples. Up to version 4.8.1, if a non-multiple speed was set, we rounded UP the extra overhead would be absorbed within the conventional aggregates overhead flexibility. From version 4.9.1 we have to round DOWN so that the data can be guaranteed to fit in the assigned TDM3 timeslot (otherwise there will be data loss). NOTE THAT THIS AFFECTS ALL CASES WHEN BANDWIDTH ROUNDING IS DONE even if the call is not routed via a TDM aggregate. In configurations where this rounding factor does not come into play (e.g. fixed line speeds of the supported granularity, which use the correct multiples with no DBA) then interworking with pre-4.9.1 software is supported. 4.14.4 TDM Tunnelling A TDM may be tunnelled as a synchronous Tributary over another TDM Aggregate. This is subject to the following restrictions: The tunnel must run at a constant speed. i.e. the sync trib must be a fixed speed, and cannot be DBA. One TDM Aggregate should be configured with the Data Stream Inversion option set to OFF for both ends, the other with the Data Stream Inversion option set to INVERTED for both ends. There is a limit of one level of tunnelling. TDM3 may be tunnelled over previous Vocality TDM offerings, provided again that a constant speed is used for the tributary tunnel. 4.14.5 Configuration Summary In order to configure a TDM aggregate follow these steps: Enter the DATA menu: Set Mode to Agg and Format to TDM. Configure Clocks and Interface type in the same manner as for a conventional aggregate. The Destination field should be left blank. If externally clocked, there is no need to specify the Rate (it should be set to 0).
Enter the TDM TIMESLOTS menu: Navigate to the Channel (port) on which you wish to run TDM using the <NEXT TDM> button. Set the number of Timeslots to a suitable value. (In version 4.9.1, there is a limit of 16 timeslots) Configure the transmit and receive timeslots which you wish to use. If any of the timeslots are CBR-DBA or Pack-DBA, ensure that a DBA-Ctrl timeslot is also configured
Enter the TDM ADVANCED CONFIG menu: configure any special settings which you require (the default will normally be suitable).
C H A P T E R
F E A T U R E S
Then repeat at the peer node. Transmit timeslot configuration should be compatible with the Receive configuration at the peer and vice-versa. Note that should you want to, you can always reconfigure a TDM Aggregate back to conventional mode (NRZ or NRZI). The settings in the TDM TIMESLOTS menu will not be used, but will be preserved.
4.15 SIPGw
The SIP gateway feature allows VoIP devices in a SIP network to communicate across a Vocality network. Calls may be routed from SIP devices to analogue voice ports, digital voice ports, or indeed other SIP devices. The voice traffic is carried across the Vocality network in a payload that provides greater bandwidth efficiency then VoIP. Calls that are handled via the SIPGw take part in the Vocality Dynamic Bandwidth Allocation scheme (DBA) where bandwidth from other multiplexed services (if available) is reduced to provide the bandwidth required for the voice call. The SIP gateway may be configured to operate either with or without a SIP registration proxy or outbound proxy. When no SIP registration or outbound proxy is available, the Vocality SIPGw feature provides simple call routing features to allow calls across the Vocality network to be routed to the correct SIP device. The SIPGw allows calls originated from the SIP network to be routed directly to other voice ports across the Vocality network - it may also be configured to provide a secondary dial-phase, where subsequent dialled digits are used to route the call.
4.16 SNMP
The SNMP feature provides an SNMP agent to the Vocality multiplexer/router. This provides management services via the SNMPv1/2c/3 protocol set to an SNMP client that allow the client to monitor the status of the Vocality unit. System and network conditions that can be configured to raise system alarms can also be configured to trigger the generation of SNMP trap messages to SNMP clients.
C H A P T E R
A P P L I C A T I O N
E X A M P L E S
5
5 Applications Examples
Inmarsat M4 terminal, and use with an IP aggregate. A full set of Application Notes are available on the Vocality International support website www.vocality.com/support.
Chapter
Four common applications are given here: Back-to-back testing, use with a satellite modem, use with an
5.1
Back-to-back Testing
Before commissioning the multiplexer, it can be very useful to configure a pair of multiplexers in a backto-back configuration to gain familiarity with their setup and operation. In the example below, two units are connected via Port 1 of a Serial Card in Slot 5 using cable VI68726A. System settings for the units are as follows:
..and for the other unit:

C H A P T E R
E X A M P L E S
The settings for Node I.D. are critical they must be set to different values for the units to communicate correctly. The Clocking Configuration settings for the units are as follows:
C H A P T E R
E X A M P L E S
The Data Configuration settings for the units are as follows:
C H A P T E R
E X A M P L E S
Note that Unit 0 is configured to generate a transmit link clock of 128Kbps (Int), which is used internally as the GRX reference (CLOCKING menu GRX source) and also received by Unit 1 and used as the GRX reference (CLOCKING menu GRX source). Unit 1 then turns the clock around (TX clock set to RXC) and it is received back at Unit 0, which uses it as the RX clock source. The programming of the clock references is essential to all tributary channels, since they must use a clock reference to generate all local bit rates. In this example, the Global Receive clock bus (GRX) takes the Port 1 Aggregate RX clock and Port 2, which will be used to connect a router, uses the GRX as its reference for generating the RX router clock. To go one stage further and operate Port 2 dynamically, the RX clock source is set to DBA. This allows the multiplexer to smoothly vary the RX clock on Port 2 according to traffic demand. Finally, a destination address must be entered for Port 2.
C H A P T E R
E X A M P L E S
5.2
Use with Satellite Modems
The multiplexer is often used in combination with satellite modems to provide telecommunications links between remote sites. This example describes the use of the V200 with a Paradise Datacom P300 modem that is fitted with the standard P1440 interface in RS422 mode, thereby allowing the use of the standard RS422/RS449 cable (part number VI68723A,see the appropriate Hardware Guide for part numbers for your multiplexer) at both ends of the link. (When using the serial data card, the four-way serial data cable - part number VI68231A - is also required.) It is also applicable to the P400 modem when fitted with the P1448 interface, but in this case the cable number VI68723B/P1448 should be used, to operate the interface in Direct mode. The standard cable should be used with all other modems.
Disclaimer: This example uses settings for the modems that have been tested and proven to work. There are alternative settings, which may be used according to the application. The validity of this example cannot be guaranteed with other manufacturers equipment or when using other settings.
The configuration concept is to use one unique clock in the system as generated by Modem0 (connected to the V200 with Node I.D. 0), with all other clocks derived from this:
In this example, port 1 on slot 5 is used on both units. The System settings for the units are as follows:
C H A P T E R
E X A M P L E S
The settings for Node I.D. are critical they must be set to different values for the units to communicate correctly.
C H A P T E R
E X A M P L E S
The Clocking Configuration settings for the units are as follows:
C H A P T E R
E X A M P L E S
The Data Configuration settings for the units are as follows:
C H A P T E R
E X A M P L E S
Unit 0 is configured to accept the stable receive link clock of 128Kbps (Ext) from Modem0, which is used to clock data out of the Doppler buffer. This is turned around as the transmit clock (RXC) and given back to modem as Terminal Timing, it is then sent over the satellite link to Modem1, which recovers the receive clock and outputs it to V200 Unit1. Unit1 is configured to accept this receive clock (Ext), to use it as the GRX reference (GRX source in CLOCKING menu) and then turn it around (TX clock set to RXC) and output it back to Modem1 as Terminal Timing (TT). Modem1 sends this back via the satellite to Modem0 which recovers the receive clock and uses it to clock the Doppler buffer. Once again, the programming of the clock references is essential to all tributary channels, since they must use a clock reference to generate all local bit rates. In this example, the Global Receive clock bus (GRX) takes the Port 1 Aggregate RX clock and Port 2 (also in slot 5), which will be used to connect a router, uses the GRX as its reference for generating the RX router clock. To go one stage further and operate Port 2 dynamically, the RX clock source is set to DBA. This allows the V200 to smoothly vary the RX clock on Port 2 according to traffic demand. Modem Settings: In the example above, two Paradise Datacom P300 modems may be used. Modem0 is used to generate the network clock, since it has a stable +/- 1ppm reference. On the Change, Tx, Baseband menu, select Continuous Data then enter the baseband data rate, in this case 128000. On the Change, Tx, Clocking menu, the TX clock should be set to TX CLOCK IN which expects the transmit clock on the TT clock pair. On the Change, Rx, Buffer/Clocking menu, the RX clock should be set to INTERNAL. This will enable the Change, Rx, Buffer/Clocking,Buffer Size menu, which allows the user to select a buffer to accommodate the incoming Doppler shift. Normally, 4mS per satellite transition is sufficient, i.e. a total of 8mS. Modem1 recovers the clock from the satellite. On the Change, Rx, Buffer/Clocking menu, the RX clock should be set to SATELLITE which will disable the Doppler buffer and output the RX clock on the RT clock pair. On the Change, Tx, Clocking menu, the TX clock should be set to TX CLOCK IN so as to accept the TT clock back in from the V200.
C H A P T E R
E X A M P L E S
5.3
Use with IP Aggregates
The following example shows a unit with node number 0 connected to a unit with node number 1 over an IP aggregate. Unit0 is configured with an IP address of 1.1.1.2/24. It is configured on an IP network with a default gateway of 1.1.1.1. Unit1 is configured with an IP address of 2.2.2.2/24. It is configured on an IP network with a default gateway of 2.2.2.1.
V200
IP
10/100/1000BT
ETHERNET
10/100/1000BT
ETHERNET
Before the IP aggregate itself is configured the system node numbers and base IP configuration should be completed. The System settings for the units are as follows:
V200
C H A P T E R
E X A M P L E S
The IP Networks menus for the units are as follows:
C H A P T E R
E X A M P L E S
The IP static route table settings for the units are as follows:
C H A P T E R
E X A M P L E S
The IP aggregate is configured to provide a 64000bps aggregate to multiplex over. Clock synchronization is required between the two units. Unit0 is configured to provide its internal clock source as a reference for Unit1. The IP Aggregate settings specify the characteristics of the IP aggregate as follows:
C H A P T E R
E X A M P L E S
A V200 routing table entry is required on both units to activate the IP aggregate. Note that the name used in the route configuration must match the name assigned in the IP aggregate configuration:
C H A P T E R
E X A M P L E S
To complete this IP aggregate configuration the clocking configuration on both units should be updated to drive GRX from the IP aggregate:
C H A P T E R
E X A M P L E S
Normal IP Tributary traffic can be routed across the IP aggregate in the normal way and is the preferred configuration where no QoS is available.
C H A P T E R
E X A M P L E S
5.4
Broadcast Voice and Data
We offer a broadcast facility, which allows Voice or Serial Data traffic to be routed to multiple destinations. (It does not apply to IP traffic). This facility is available within unit and across conventional and TDM aggregates. TDM Aggregates make use of Broadcast Voice/Data in order to deliver voice/data in Radio Silence mode. We define the concept of a Broadcast Pathway: this is a logical path-way within a unit which carries data from one source to one or more destinations. A Broadcast Pathway may be directed to other units by directing it to an Aggregate. In order to configure a Broadcast Voice or Data connection: 1. 2. 3. Configure the source and destinations of the broadcast data Define entries in the ROUTING menu to direct the Broadcast Pathway to other nodes If in a Chassis-based system (e.g. V150 or V200), define additional entries in the ROUTING menu to create the Broadcast Pathway within the unit. 4. If using TDM, define BRDn timeslots on the TDM TIMESLOTS menu
In more detail, these steps are as follows: Configure the source and destinations of the broadcast data Serial Data and Voice ports may be configured as the source and/or destination of the broadcast data. This is done by entering BTXnn/BRXnn/BTRmm,nn in the DESTINATION field for the appropriate port, as follows. Note that the directions in BTX/BRX are relative to the BROADCAST PATHWAY, not to the physical interface. Use BTXnnn if the port is to originate broadcast voice or data. For example, if BTX1 is specified on an analogue voice port, received audio will supply the Broadcast Pathway 1. No audio will be transmitted to the telephone line. Use BRXnnn if the port is to transmit broadcast voice or data. For example, if BRX1 is specified on an analogue voice port, it will transmit audio from broadcast Pathway 1. No audio will be received from the telephone line. Use BTRmmm,nnn if the port is to both transmit and receive Broadcast data/voice. i.e. originate broadcast voice/data onto one Broadcast Pathway, and transmit broadcast voice/data from another Broadcast Pathway. For example, if BTR1,2 is specified on an analogue voice port, then received audio will supply Broadcast Pathway 1, and transmitted audio will come from Broadcast Pathway 2.
C H A P T E R
E X A M P L E S
Note that any one Broadcast Pathway should only be supplied from one port. Define entries in the ROUTING menu to direct the Broadcast Pathway to other nodes For each Aggregate to which the Broadcast data is to be sent, add an entry to the ROUTING menu, as follows. This example will cause all Broadcast traffic to be routed to the Aggregate 0:1.
Add additional entries in the ROUTING menu to create the Broadcast Pathway within the unit. If in a chassis-based system (e.g. V200 or V150), then it may be necessary to add additional entries to the ROUTING menu, in order to create Broadcast Pathways within the unit. This will only be necessary if the source and destinations (whether tributary port or aggregate) of the broadcast data are on different cards. The following example would handle the case of a Voice Card in slot 3 generating or receiving Broadcast data (note that there does not actually need to be an Aggregate in the specified position).
C H A P T E R
E X A M P L E S
If using TDM, define BRDn timeslots on the TDM TIMESLOTS menu This step is only needed if routing broadcast data across a TDM Aggregate. A Broadcast Pathway should normally be routed over TDM Aggregates using a dedicated timeslot, rather than using the dynamic area. BRD timeslots should be of the type appropriate for the port being used typically this will be Voice, ModemFax or SVR if Analogue voice traffic is being carried, or CBR or Packet if Serial Data is being carried (see the TDM section for more details). There is no Call-Control Signalling when a Broadcast path is established over TDM these means that they can be used in TDM Radio Silence Mode.
A P P E N D I X
A :
A B B R E V I A T I O N S
A
Appendix A: Abbreviations
ACK Agg AIS AOR ARP Bps(Kbps) CBR CIR CLI CPN DBA DES DHCP DNS FQDN GRX GTX ICMP IETF IGP IP LAN LDN LOS MAC MD5 MTU MUX NACK NFS NSSA OSFP PEP PLL PoE QoS RAI RFC RIPv2 RXC RXD SHA1 SIP SIPGw Acknowledgement Aggregate Port Alarm Indication Signal Address Of Record Address Resolution Protocol Bits per Second (Kilobits per second) Constant Bit Rate Committed Information Rate Calling Line Identification Called Party Number Dynamic Bandwidth Allocation Data Encryption Service Dynamic Host Configuration Protocol Domain Name Service Fully Qualified Domain Name Global Receive Clock Global Transmit Clock Internet Control Message Protocol Internet Engineering Task Force Interior Gateway Protocol Internet Protocol Local Area Network Local Directory Number Loss Of Signal Media Access Control message digest 5 Maximum Transmission Unit (bytes) Multiplexer Negative Acknowledgement Network Function Semi(ISDN) Not So Stubby Area Open Shortest Path First Performance Enhancing Proxy Phase-Locked Loop Power over Ethernet Quality of Service Remote Alarm Indication Request For Comments Routing Information Protocol version 2 Receive Clock Receive Data Secure Hash Algorithm 1 Session Initiation Protocol SIP Gateway
Appendix
A P P E N D I X
A :
SNMP STP TA TCP TCPGw TDM TFTP ToS Trib TXC TXD UA UDP UDPGw URI UTP WAN
Simple Network Management protocol Spanning Tree Protocol Terminal Adaptor (ISDN) Transmission Control Protocol TCP Gateway Time-Division Multiplexer Tiny File Transfer Protocol Type of Service Tributary port Transmit Clock Transmit Data User Agent User Datagram Protocol UDP Gateway Universal Resource Identifies Unshielded Twisted Pair Wide Area Network
A P P E N D I X
A :
Appendix B: Index
Back Busy, 24 Back-to-back testing, 281 Bandwidth on Demand (BoD), 132, 136 Broadcast mode, 250 Clocking, 66, 233, 245, 253, 284, 289 menu, 33 Over IP Aggregates, 124 CONFIGURATION Mode, 30 Stores, 31 CONFIGURATIONS menu, 29 DBA, 244 Pools, 112 remote configuration, 185 Diagnostics, 191 Alarms, 225 Call log, 226 Configurations, 224 Connections, 223 IP PoE power, 201 IP Route Table, 196 Ping, 193 Test Ports, 189 Feature Keys, 49, 51 FXO, 53, 54, 73, 74, 255 FXS, 53, 54, 73, 74 GRX, 144 GTX, 144 High-speed CPU, 8 Hunt Groups, 53, 57, 59 IP Aggregates, 33, 36, 37, 39, 122, 124, 125, 281, 290, 293, 295, 296, 297 IP Router, 258 MTU, 81 Discussion, 260 Node ID, 10, 22 Passwords, 14, 17, 25, 27 PEP, 82, 271
Appendix
Port Numbers, 9, 57, 73, 82, 85, 111, 119, 124, 258, 270 Ports Data, 19, 66, 244, 245 M&C, 13 Supervisor, 17 Virtual, 82, 83, 85, 97, 257, 259, 260, 266 Power over Ethernet (PoE), 26 Relay Fax, 72 Modem, 72 STU, 73 UDP, 111 V.22, 72 Routing, 36 Implicit, 39 Precedence, 39 RIPv2, 85 Static, 96 Table entry, 38 Service Management, 112, 117, 118, 119, 121, 133, 134 Shared outbound links, 65 SIP, 42 Address Of Record, 45 Destination, 48 Gateways, 56 UA Channels, 45 User Agents, 42 Spanning Tree Protocol, 81, 276 Supervisor, 27, 38, 110, 116, 185, 252, 275 Telnet, 110, 116, 275 Tie-Line, 24, 27 Tones, 243 Voice Analogue, 71 Digital, 129, 140

Software Guide Version 4.9

Uploaded by

Copyright:

Available Formats

Software Guide Version 4.9

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Guide Version 4.9

Uploaded by

Copyright:

Available Formats

V25, V50PLUS, V150 AND V200

ABOUT THIS MANUAL .................................................................................... 8

CONFIGURING THE UNIT............................................................................... 9

DIAGNOSTICS ........................................................................................... 181

230 230 231 232 232 233 233 233

APPLICATIONS EXAMPLES ........................................................................ 276

ABBREVIATIONS ...................................................................... 295 INDEX ...................................................................................... 297

1 About This Manual

Multiplexer Software Guide Version 4.9 Page 8 of 297

2 Configuring the Unit

The Port Addressing Scheme

From the rear, the V200 is laid out as follows:

The V150 is laid out as follows:

PORT 1 1 2 STATUS M&C ETHERNET 2 ALARMS ETHERNET 1 ALERT

PORT 1 1 2 STATUS M&C ETHERNET 2 ALARMS ETHERNET 1 ALERT

ALERT 1234 5678 ENET

ALERT 1234 5678 ENET

A B Multiplexer Software Guide Version 4.9

Default Slot mapping V150 V200 0 0 1 1 2 2 3 4 5 6 7 8/PSU2 PSU1

Multiplexer Software Guide Version 4.9 Page 11 of 297

The ports of the V50plus are grouped as follows:

Option Slot 2 Slot 0 the chassis

Slot 0 The Chassis

Slot 1 the Voice ports

Multiplexer Software Guide Version 4.9 Page 12 of 297

Using the Supervisor or Management and Configuration (M&C) Port

Multiplexer Software Guide Version 4.9 Page 13 of 297

Multiplexer Software Guide Version 4.9 Page 14 of 297

Multiplexer Software Guide Version 4.9 Page 16 of 297

Status No password or default RO password entered RW or superuser password entered

None Prompt for password Prompt for password

Full access to menus, terminal and debug mode

Multiplexer Software Guide Version 4.9 Page 17 of 297

Multiplexer Software Guide Version 4.9 Page 18 of 297

Multiplexer Software Guide Version 4.9 Page 19 of 297

The MAIN menu

Multiplexer Software Guide Version 4.9 Page 20 of 297

Multiplexer Software Guide Version 4.9 Page 21 of 297

The SYSTEM menu

REAL TIME CLOCK

Multiplexer Software Guide Version 4.9 Page 22 of 297

RECEIVE READY FILTER

DATA CHANNEL ACTIVATION

DATA CHANNEL FLAG

ASYNC BUFFER SIZE

Multiplexer Software Guide Version 4.9 Page 25 of 297

POE PSU RATING

NODE ID CONFIGURATION BY REMOTE

Inhibited MLPP COMPATIBILITY On,

UK, US, France, Germany

Multiplexer Software Guide Version 4.9 Page 26 of 297

CONNECTION TIMEOUT RECEIVE READY FILTER DATA CHANNEL ACTIVATION

10-255 numeric entry 0-255 numeric entry Auto, Flag

DATA CHANNEL FLAG

Always On, Follows Connect, Follows Remote, Follows Alarms

TIE LINE ACTIVATION

M-Lead M-Lead & Back-Busy

BACKUP TIMER FALLBACK TIMER

PoE PSU RATING

Multiplexer Software Guide Version 4.9 Page 27 of 297