NexusWare WAN Protocol

calvesnorthΔίκτυα και Επικοινωνίες

24 Οκτ 2013 (πριν από 4 χρόνια και 14 μέρες)

880 εμφανίσεις

NexusWare WAN Protocol
Configuration Guide
www.pt.com
140 Canal View Boulevard Rochester, NY 14623 Phone 585.256.0200 support
@
pt.com

®

Document Revision History
Disclaimer
This document presents information for users of PT products. Although the information contained within
this document is considered accurate and characteristic of the subject product, PT reserves the right to
make changes to this document and any products described herein to improve reliability, functionality, or
design.
PT does not assume any liability arising out of the application or use of any product or circuit described
herein. No part of this document may be copied or reproduced in any form or by any means without the
prior permission of PT.
Trademarks
This document is the sole property of PT. All other brands or names are trademarks of their respective
holders.
PT is a trademark of Performance Technologies, Inc.
The PT logo is a registered trademark of PT.
© Copyright 2013 PT. All Rights Reserved.
Errors and Omissions
Although diligent efforts are made to supply accurate technical information to the user, occasionally
errors and omissions occur in manuals of this type. For the most current user documentation, contact
Customer Support.
Part Number Date Explanation of changes
106P0150.57 February 27, 2007 HDLC Connectivity and Radar Connectivity
106P0150.58 August 10, 2007 MPTTS Updates
106p0150.60 October 4, 2007 Widespread changes to Chapter Chapter 5, “MPSx000 LAN
Interface”; Added -d link num to wcpLoad utility on page 34;
Reformatted manual.
106p0150.61 May 8, 2008 Added Baud Rate Generators information.
106p0150.62 June 2, 2008 Removed Baud Rate Generators sections due to change of support.
106p0150.63 October 31, 2008 Added parameters to sysOptions.cfg in “Performance Tuning” on
page 189.
106p0150.70 June 7, 2012 Added Chapter 7, MPS Mcast Layer and updated the template.
3
Contents
Chapter 1: About This Guide 15
Who Should Read This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Contents of This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Text Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Customer Support and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Customer Support Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Other Web Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Return Merchandise Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Product Warranty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Chapter 2: NWC Configuration 19
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Running the NWC Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
NWC Configuration File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
System Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
TDM Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Port Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
H.110 Switch Clock Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Processor Channel Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
H.110 Switch Connections Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Controller Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Sub-Channeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Serial Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Contents
4
Chapter 3: WCP Network Configuration 29
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Access to the NexusWare Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
pticonfig File Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Editing the pticonfig File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Saving the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Example Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
The mps Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
The updateTimeOfDay Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Chapter 4: Client Utilities 33
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Download Program (wcpLoad) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Events Monitor Program (eventsClient) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
NWSL Command Line Interface Utility (nwslCli) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
NWSL Copy Utility (nwslCp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Chapter 5: MPSx000 LAN Interface 43
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Primary and Secondary Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Operating Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Single-LAN Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Dual Redundant LAN Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Hybrid Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Remotely Accessing the MPS1000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Data Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Control Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Control Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Tunable Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Asynchronous Event Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Contents
5
Configuring Event Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Receiving Event Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Soft Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Soft Reset Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Sample Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Setprams Sample Program (setprams) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Failover Sample Program (failover) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Events Sample Program (events) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Softreset Sample Program (softreset) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Chapter 6: Board Clocking 59
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
H.110 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Primary Clock Reference Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Secondary Clock Reference Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Clock Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Transition Upon Primary Clock Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
No Transition Upon Primary Clock Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
Chapter 7: MPS Mcast Layer 69
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
Example Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
Runtime Monitoring and Servicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
Sample Test Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
mcstrcv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
mcastsnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Payload Flow Sample Test Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Configuration File Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Standard for All Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Parameters Specific to TADIL-B (WEC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
Contents
6
Parameters Specific to All Radar Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Parameters Specific to ASTERIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Parameters Specific to CD-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Parameters Specific to Thomson-CSF, Thomson-TVT2, Toshiba . . . . . . . . . . . . . . . . . . . . . 88
Parameters Specific to HDLC-DFX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Appendix A: NexusWare Drivers 101
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
T1/E1/J1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
T1 IOCTL( ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
T1/E1/J1 General Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
T1/E1 Alarm Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Get T1/E1/J1 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
T1/E1/J1 Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
T1/E1 Diagnostic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
DS0 General Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Line Equalization Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
FALC Register Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
T1/E1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Port Status Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
H.110 Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
H.110 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
CTBUS_SUCCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
H.110 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Multichannel Communications Controller (MCC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Application Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Appendix B: SS7 139
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
PCI384 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
440GX Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Contents
7
Appendix C: Application to Controller Communications 141
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
Configuration Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
IOCTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
Asynchronous Events Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187
System Services Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
Appendix D: Performance Tuning 189
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189
NWC Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189
Protocol Specific Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
sysOptions.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
Index 193
Contents
8
9
Table 1-1: Chapters in this Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Table 1-2: Text Conventions in this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Table 1-3: PT Support Contact Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Table 2-1: Topics in this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Table 2-2: System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Table 2-3: Port Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Table 2-4: H.110 Switch Clock Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Table 2-5: Processor Channel Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Table 3-1: Topics in this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Table 3-2: Ethernet Configuration Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Table 4-1: Topics in this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Table 5-1: Topics in this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Table 6-1: Topics in this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Table 7-1: Topics in this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Table A-1: Topics in this Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Table A-2: T1/E1/J1 Configuration Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Table A-3 T1/E1/J1 Trunk ID Field. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Table A-4: DSX1 Line Type Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Table A-5: DSX1 Line Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Table A-6: DSX1 Send Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Table A-7: DSX1 Signal Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Table A-8: DSX1 Transmit Clock Source. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Tables
Tables
10
Table A-9: DSX1 FDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Table A-10: DSX1 Line Length Parameter Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Table A-11: DSX1 Line Status Change Event Enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Table A-12: DSX1 AIS Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Table A-13: DSX1 FERF Alarm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Table A-14: DSX1 Line Status Bits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Table A-15: DSX1 Loopback Status Bits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Table A-16: DSX1 Statistics Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Table A-17: DSX1 Statistics Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Table A-18: DSX1 Loopback Configuration Bits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Table A-19: DSX1 Auto Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Table A-20: Gain Settings per Interface Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Table A-21: Long Haul Xmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Table A-22 Short Haul Rev. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Table A-23: CTbus Terminus Bus Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Table A-24: CTbus Terminus Stream Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Table A-25 CTbus Terminus Timeslots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Table A-26: H.110 Interface Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Table A-27: H.110 Stream Speed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Table A-28: S/W Specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Table A-29: H.110 Hardware Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Table A-30: Failure Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Table A-31: IOCTL_MCC_CFG Timeslot Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Table A-32: bit32 func Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Table A-33 bit32 looptype Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Table B-1: Topics in this Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Tables
11
Table C-1 Topics in this Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Table D-1: Topics in this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Tables
12
13
Figure 6-1: Healthy H.110 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 6-2: H.110 Bus After Loss of Primary Clock Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 6-3: CPC396 Clock MUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figure 6-4: CPC388 Clock MUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 6-5: PCI384 Clock Mux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figure 6-6: H.110 Failover Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figure 6-7: Clocking Automatic Failover and Recovery Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 6-8: Clocking: Failover with Application Intervention Diagram . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 7-1: MPS Server Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Figure A-1: CPC388 Time Slot Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Figure A-2: PCI384 Time Slot Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Figure A-3: CPC388 H.110 Switch Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Figure A-4: PCI384 H.100/H.110 Switch Streams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Figures
Figures
14
15
Chapter 1
About this Guide
Who Should Read this Guide
This guide describes the NexusWare
®
WAN Protocol, PT’s Linux-based development,
integration and management environment. NexusWare WAN is intended for systems engineers
using PT’s I/O and Communications products to build packet-based applications, including
next-generation wireless and IP telephony systems.
Contents of this Guide
Table 1-1 lists and describes the contents of this guide.
Table 1-1: Chapters in this Guide
Chapter Description
NWC Configuration Provides information about the utility that is designed to
configure the controller. Also included are sample
configuration files.
WCP Network Configuration Contains procedural information for using the
configuration file on the NexusWare Controller and
information about the ethernet configuration options
available to the user.
Client Utilities Describes information about the client utilities used to
monitor and maintain the WCP software running on the
NexusWare controller. Descriptions and examples of each
utility are provided.
MPSx000 LAN Interface Describes how the NexusWare controllers are configured
when they are part of an MPS1000 unit.
Board Clocking Describes how to configure the H.110 switch of the
NexusWare controller.
NexusWare Drivers Provides information about low-level IOCTLs to program
the NexusWare components.
SS7 Provides information about the Motorola SS7 microcode
that can be invoked on the CPC388 and PCI384
NexusWare controllers.
Application to Controller Communications Provides information about accessing controller services,
configuration requests and event messages.
Performance Tuning Describes how the WAN Protocol software supports
various mechanisms to help optimize performance based
on the customer’s application requirements.
Chapter 1: About This Guide
16
Text Conventions
Table 1-2 lists the text conventions used in this guide.
Table 1-2: Text Conventions in this Guide
Customer Support and Services
PT offers a variety of standard and custom support packages to ensure customers have access
to the critical resources that they need to protect and maximize hardware and software
investments throughout the development, integration, and deployment phases of the product
life cycle.
If you encounter difficulty in using this PT, Inc. product, you may contact our support personnel
by:
1
EMAIL (Preferred Method) – Email us at the addresses listed below or use our online email
support form. Outline your problem in detail. Please include your return email address and a
telephone number.
2
TELEPHONE – Contact us via telephone at the number listed below, and request Technical
Support. Our offices are open Monday to Friday, 8:00 a.m. to 8:00 p.m. (Eastern Standard
Time).
Convention What it is Used For
Monospace font
Monospace font is used to represent sample code.
Bold font Bold font is used to represent:
• pathnames
• filenames
• UNIX commands
• user input
Italic font Italic font is used to represent:
• notes that supply useful advice
• general information
• referenced documents
< > Angle brackets are used to represent variables such as
filenames, commands, passwords, and so on.

CAUTION
The caution icon advises users that failure to take or
avoid a specified action could result in loss of data.
Table 1-3: PT Support Contact Information
Embedded Systems and Software
(Includes Platforms, Blades, and Servers)
SS7 Systems
(Includes SEGway™)
Email
support@pt.com ss7support@pt.com
Phone
+1 (585) 256-0248
(Monday to Friday, 8 a.m. to 8 p.m.
Eastern Standard Time)
+1 (585) 256-0248
(Monday to Friday, 8 a.m. to 8 p.m.
Eastern Standard Time)
Product Warranty
17
If you are located outside North America, we encourage you to contact the local PT’ distributor
or agent for support. Many of our distributors or agents maintain technical support staffs.
Customer Support Packages
Our configurable development and integration support packages help customers maximize
engineering efforts and achieve time-to-market goals. To find out more about our Customer
Support packages, visit http://www.pt.com/page/support/.
Other Web Support
Support for existing products including manuals, release notes, and drivers can be found on
specific product pages at http://www.pt.com. Use the product search to locate the information
you need.
Return Merchandise Authorization
To submit a Return Merchandise Authorization (RMA) request, complete the online RMA form
available at http://pt.com/assets/lib/files/rma-request-form.doc and follow the instructions on
the form. You will be notified with an RMA number once your return request is approved.
Shipping information for returning the unit to PT will be provided when the RMA is issued.
Product Warranty
PT warrants that its products sold hereunder will at the time of shipment be free from defects in
material and workmanship and will conform to PT’s applicable specifications or, if appropriate,
to Buyer’s specifications accepted by PT in writing. If products sold hereunder are not as
warranted, PT shall, at its option, refund the purchase price, repair, or replace the product
provided proof of purchase and written notice of nonconformance are received by PT within 12
months of shipment, or in the case of software and integrated circuits within ninety (90) days of
shipment and provided said nonconforming products are returned F.O.B. to PT’s facility no later
than thirty days after the warranty period expires. Products returned under warranty claims
must be accompanied by an approved Return Material Authorization number issued by PT and
a statement of the reason for the return. Please contact PT, or its agent, with the product serial
number to obtain an RMA number. If PT determines that the products are not defective, Buyer
shall pay PT all costs of handling and transportation. This warranty shall not apply to any
products PT determines to have been subject to testing for other than specified electrical
characteristics or to operating and/or environmental conditions in excess of the maximum
values established in applicable specifications, or have been subject to mishandling, misuse,
static discharge, neglect, improper testing, repair, alteration, parts removal, damage, assembly
or processing that alters the physical or electrical properties. This warranty excludes all cost of
shipping, customs clearance and related charges outside the United States. Products
containing batteries are warranted as above excluding batteries.
Chapter 1: About This Guide
18
THIS WARRANTY IS IN LIEU OF ALL OTHER WARRANTIES WHETHER EXPRESS,
IMPLIED OR STATUTORY INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS. IN NO EVENT SHALL PT BE LIABLE FOR ANY INCIDENTAL OR
CONSEQUENTIAL DAMAGES DUE TO BREACH OF THIS WARRANTY OR ANY OTHER
OBLIGATION UNDER THIS ORDER OR CONTRACT.
19
Chapter 2
NWC Configuration
Overview
A special configuration utility is provided for NexusWare controller products. This utility is
designed to configure the controller when it is first started by reading configuration parameters
from a text file and transmitting the information to the product either over a backplane
connection (PCI or CompactPCI) or by TCP/IP.
Source code for the configuration utility, nwc.c, nwc_wcpIF.c, and sample configuration files
are included with the release in the /usr/pti/util/nwc

directory. The configuration files are
designed so that data will be successfully transported when adjacent ports are externally
looped back, for example, when port 0 is connected to port 1.
Table 2-1lists the topics covered in this chapter.
Table 2-1:
Topics in this Chapter
Topic Page
Running the NWC Utility Page 20
NWC Configuration File Format Page 20
System Configuration Parameters Page 21
TDM Controllers Page 22
Serial Controllers Page 28
Chapter 2: NWC Configuration
20
Running the NWC Utility
The following is the command line format to execute the NWC utility:
nwc [-v] [-d] [-c controller] [-s sever] [-S service] [-f filename]
Options
-v displays detailed information as the configuration file is parsed and is
useful when debugging the configuration file syntax.
-d displays all messages exchanged with the controller and is useful to
view the actual controller configuration process.
-c controller identifies which controller to configure when multiple
controllers are in a single backplane with controller being the
controller's number. If this parameter is not specified, a default value of
0 is used.
-s server identifies which server to configure when TCP/IP is used to configure
the controller with the server being the controller's name.
-S service identifies which service to use when configuring the controller using
TCP/IP with service being the name of the service. If this parameter
is not specified when the -s parameter is, a default value of mps is
used.
-f filename specifies the configuration file to use with filename being the path
name of the file.
NWC Configuration File Format
The NWC utility uses the information contained in a configuration file to identify the controller
and configure the controller's NexusWare and WAN STREAMS drivers. There is one type of
configuration file for TDM controllers and another type for Serial controllers with the types
differentiated by the boardType parameter described in System Configuration Parameters.
Each configuration file contains multiple sections with each section containing one or more
lines. A system configuration section is always the first one in a file and is the same for both
types of controllers. The subsequent sections are controller specific and are based upon the
functionality and device/driver being configured. Each line in a section specifies the value of
one parameter for the device/driver except for H.110 switch connection configuration lines.
The NWC parses all of the lines of a configuration file and then formats the accumulated
information into messages for the controller. As a result, any detected syntax error will prevent
any configuration information from being sent.
All configuration sections do not need to be specified, except for the system configuration
parameters which must always be specified. If a configuration section is not specified, no
messages associated with the missing device information are sent to the controller. This means
no messages containing default values are sent. If all parameters for a section are not
specified, the indicated default values will be used when the information is sent.
System Configuration Parameters
21
The following rules apply to all configuration file lines:
• A line is defined as zero (or more characters) followed by a line feed.
• Each keyword and parameter must be surrounded by white space--any combination of one
or more blanks, horizontal or vertical tabs, carriage returns, or form feeds.
• Keywords and parameters are case insensitive.
• Blank lines are ignored.
• All characters following a "#" are ignored until the line feed. This defines the comment
character which can appear anywhere in a line.
• After a section has been specified, it cannot be respecified.
The following rules apply to all lines except those specifying H.110 switch connections:
• Each line consists of one parameter keyword that identifies the parameter being specified,
followed by one selection keyword or value.
• If a parameter keyword is specified more than once, the last selection is used.
The lines specifying H.110 switch connections contain multiple keywords and values whose
format is discussed in its associated detailed discussion.
System Configuration Parameters
These parameters must always be specified and precede all other configuration information.
They can be in any order. The following is a list of these keywords followed by their associated
selection keywords.
Note:Values enclosed by brackets [ ] are the assigned default values.
An optional system configuration keyword is noHscmReset which has no parameters. When
this is specified, if implementing the configuration file would require that a reset request be
issued to the HSCM, this request is not sent, although all other requests would be sent. See
“Controller Reconfiguration,” on page 26 for when this would be useful.
Table 2-2:System Configuration
Keyword Potential Value(s)
boardType CPC3000, CPC3080, CPC3240, CPC3880, PCE3850, PCI3840
softwareLoadType wcp
ss7BoardMode disable, enable (only available on PCI384 and CPC388 controllers).
Chapter 2: NWC Configuration
22
TDM Controllers
The following sections describe the TDM controllers' configuration file sections as well as
additional information for special uses and configurations.
Port Configuration Parameters
The first parameter specified for each port configuration must be the portId. This parameter
can be followed by zero or more lines containing the following parameter keywords in any
order. If only the portId and lineType are specified, no configuration information is sent to
the card. To configure a port with all default values at least one more port specification must be
provided. All configuration information for a port must be specified before another portId or
device is specified.
Notes:
• Port configuration parameters are not valid for CPC300 controllers.
• This chart is applicable for all ports.
• Values enclosed by brackets [ ] are the assigned default values.
Table 2-3:Port Configuration
Keyword Potential Value(s)
portId PCI384 and PCE385: 0 – 3; CPC388 0 - 8; CPC308: 0 – 7; CPC324: 0 – 23
lineType [esf], D4, E1, E1crc, J1
lineCoding [b8zs], ami, hdb3, other
sendCode [none], lineCode, payLoadCode, resetCode
signalMode [none], robbedBit, chanAssociated
fdl [enable] or disable. (fdl is only valid if lineType = esf or D4)
lineLength T1 - line length in meters, monitor;
E1 - short75, short120, long75, long120, monitor;
J1 – J1Short, J1Long, monitor
xmitAtten [xmit0dB], xmitM7dB, xmitM15dB, xmitM22dB
recvGain
1
1.On the CPC324 and CPC308, options other than the recv0db are only valid when lineLength=monitor.
[recv0dB] or recv20db
recv26dB (CPC324 and CPC308 only)
recv32dB (CPC324 and CPC308 only)
alarmEgress [alarmRAI] or alarmAIS
suppressRcvdRAI [enable] or disable
optIdleCode [0x7E] Optional idle code to transmit, can be specified as a hexadecimal value by
preceding the value with a "0x" (only required if the optional idle code
transmission is enabled on one or more DS0s)
optIdleCodeEnable [0] Enables sending the optional idle code on associated DS0(s) where 0 in the
bit position disables the transmission and a 1 enables it (the least significant bit
corresponds to DS0 0, etc.)
signallingEnable [0] Enables signaling information on the associated DS0(s) where 0 in the bit
position disables the signalling and a 1 enables it (the least significant bit
corresponds to DS0 0, etc.)
feLoopbackReqEnable [disable], loopbackPayload, loopbackLine, loopbackLocal, outBand, inBand
TDM Controllers
23
H.110 Switch Clock Configuration Parameters
The first parameter specified for this section must be clockSource. This parameter can be
followed by zero or more lines containing the following parameter keywords in any order. All
H.110 clocking configuration information must be specified before another device is specified.
Note:Values enclosed by brackets [ ] are the assigned default values.
Processor Channel Configuration Parameters
These parameters specify information that is applied by the hardware to all time-slots
associated with the specified MCC or Mindspeed device. The ProcChanId identifies the
specific MCC or Mindspeed device. When specifying connections in the “H.110 Switch
Connections Configuration Parameters” section, on PCI384, PCE385 and CPC388 controllers,
link IDs 0 – 127 are assigned to MCC 0 and link IDs 128 – 255 are assigned to MCC 1. On
CPC300, CPC308 and CPC324 controllers, link IDs 0 – 255 are assigned to Mindspeed part 0
and on CPC300 and CPC324 controllers link IDs 256 – 511 are assigned to Mindspeed part 1
and 512 – 767 are assigned to part 2.
The first parameter specified for this section must be procChanId. This parameter can be
followed by zero or more lines containing the following parameter keywords in any order. All
configuration information for a processor channel must be specified before another
procChanId or device is specified. If no H.110 switch connections to a processor channel are
specified, its configuration is not sent to the card. See “H.110 Switch Connections
Configuration Parameters,” on page 24 of linkId to determine which connections are
connected to which processor channel.
Table 2-4:H.110 Switch Clock Configuration
Keyword Potential Value(s)
clocksource [internal], network, netref1, netref2, huntMode
networkSource port id - PCI384: 0 - 3, CPC388: 0 - 8, CPC308: 0 – 7, CPC324: 0 – 23
(networksource is only valid if clocksource = network)
h100ClockMode [standAlone], slave, master_a, master_b
fallbackClockSource [none], internal, network, netref1, netref2, B, huntMode
driveNetRefNetMode [none], netref1, netref2
driveNetRefNetSource port id - PCI384: 0 - 3, CPC388: 0 - 8, CPC308: 0 – 7, CPC324: 0 – 23
(driveNetRefNetSource is only valid if driveNetRefMode is not “none”)
driveNetRefClkSpd [2048K], 8K, 1544K (driveNetRefClkSpd is only valid if driveNetRefClkSpd is not
“none”)
fallbackNetworkSource port id - PCI384: 0 - 3, CPC388: 0 - 8, CPC308: 0 – 7, CPC324: 0 – 23
(fallbackNetworkSource is only valid if fallbackClockSource = network)
clkPref [none], A, B
clkSpd [2048K], 8K, 1544K
Table 2-5:Processor Channel Configuration
Keyword Potential Value(s)
ProcChanId PCI384, PCE385 and CPC388: 0 – 1; CPC300 and CPC324: 0 – 2; CPC308: 0
MaxFrame 100 - 4086
Chapter 2: NWC Configuration
24
H.110 Switch Connections Configuration Parameters
Each configuration line in this section specifies a single H.110 switch connection or both the
input and output connections for a single port's timeslot. An H.110 switch connection line
consists of a connection's source, destination, and other optional information. The source and
destination specification can be either the source of the data stream or the sink of the data
stream except if a processor channel is involved and either the CTBus/H.110 bus or the PTMC/
H.110 bus is the source specification. A processor channel can only be part of a destination
specification and if the source specification is either H.110 buses, then the destination
specification cannot contain a port specification.
The following is the basic format of an H.110 switch connection:
sourceSpec direction destinationSpec
where
sourceSpec consists of the type of the source connection T1, E1, J1 for a port, Str
for a CTBus/H.110 bus, or Ptmc for a PTMC/H.110 bus connection;
followed by its corresponding identifier value (either its port or CTBus
stream number), followed by the number of the timeslot to be switched.
CTBus H.110 streams identifiers are restricted to between 0 and 31
with their timeslots restricted to between 0 and 127. PTMC H.110
streams identifiers are between 0 and 19 for PTMC slot 1 and 20 and
39 for slot 2. Either individual or multiple consecutive timeslots may be
specified. If multiple timeslots are specified, the number defined in the
sourceSpec must match the number specified in the destinationSpec.
Multiple timeslots can be marked by specifying a starting and ending
timeslot, separated by “-”, e.g., “5 - 8”. However, the starting and
ending timeslots do not have to be the same in the two specifications.
direction specifies which end of the connection is the data's source or sink.
bi

indicates that two H.110 switch connections are to be made involving
both endpoints with each end being a source and sink for one or the
other connection.
to
indicates that the sourceSpec is the data's source
with destinationSpec being its sink and
from
indicates the opposite
with sourceSpec being the sink and destinationSpec being the source.
destinationSpec has the same options and format as the sourceSpec with the following
exceptions: a processor channel connection type is also allowed which
has the format given below and if either Str or Ptmc is the sourceSpec
then only Str, Ptmc, or procChan can be the destinationSpec.
procChan linkId conFormat optBitOrder bitCnt options
where
procChan is the keyword identifying a processor channel specification.
linkId is the value used by the host application to establish its data link to the
connection. See “Processor Channel Configuration Parameters,” on
page 23 for the assignments of linkIds to processor channels.
TDM Controllers
25
conFormat is either HDLC or transparent, indicating whether the connection
transports HDLC data or raw data respectively.
optBitOrder is only specified if conFormat is transparent. It can be either big,
indicating big endian (the most significant bit is transmitted first); or
little, indicating little endian (the least significant bit is transmitted first).
bitCnt is the number of data bits transported by the connection. It can be any
value between 1 and 7 or any multiple of 8 between 8 and 128.
Zero or more options may be specified and include the following:
• optional data formats
• loopback or echo
• frame size
• number of flags
• enable or disable idle codes
• transmit and receive queue lengths
• synchronize time-slots
An optional data format is only valid if bitCnt is not a multiple of 8. It can be msBits, lsBits, or
padToByteAlign. msBits indicates that the timeslot is composed of 8 bits, but the relevant data
is contained in the most significant bitCnt bits. lsBits indicates that the timeslot is composed of
8 bits, but the relevant data is contained in the least significant bitCnt bits. padToByteAlign
indicates that if the bitCnt bits in the specification line do not start on a byte boundary of
processor channel stream, discard all bits until the byte boundary is reached and then start
transporting bitCnt bits.
Either loopback or echo may be specified for any processor channel connection for testing
purposes. Loopback will cause all outbound data from the specified linkId to be both sent out of
the processor channel and be looped back to the same linkId. Echo causes all inbound data to
the specified linkId to be both sent to the linkId connection and to be sent outbound from the
linkId connection.
When the configuration line specifies a transparent connection, e.g. conFormat is transparent,
an optional frame size may be specified using “frameSize n” where n is the frame size. If this
option is not specified, the frame size defaults to the maximum frame size specified in the
Processor Channel Configuration Parameters. This value defines the size of the buffer supplied
to the hardware for the received data. Note that this option is not available for transparent
connections on CPC300, CPC308 and CPC324 controllers or when conFormat is HDLC. In
both of these cases, frameSize defaults to the value of the maximum frame size.
If the configuration line’s connection format is HDLC, the number of flags (0x7E) inserted
between transmitted frames can optionally be specified using “nof n” where n is the number of
additional flags to insert with 1 being the current default. On a PCI384 controller, one flag is
always inserted and “n” is the number of additional flags to insert. So specifying 0 will insert
zero additional flags (which is flag sharing), 1 will insert two flags, 2 will insert 3 flags, etc. On
all other controllers, two flags are always inserted so a value of 0 or 1 produces the same result
of two flags, a value of 2 produces three flags, etc. To enable flag sharing on these controllers,
specify ENABLE_TX_FLG_SHARE in the HDLC OPEN_LINK's CONFIG.mode parameter.
Refer to the HDLC Protocol User's Guide.
Chapter 2: NWC Configuration
26
Flags (0x7E) or idles (0xFF) can be inserted between transmitted frames by specifying
“disableIdles” or “enableIdles” respectively. The insertion of flags is the default.
The number of buffers queued to the transmitter and the number of buffers queued on the
receiver can be optionally specified using “txQueueLen n” and “rxQueueLen n” where n is the
number of queued buffers to allow. The default for both is 10 buffers. As the number of
configured links increases, increasing this value can cause the controller’s watchdog timer to
expire during the NWC utility’s configuration phase. This is especially the case with a CPC324
because of the number of links and the amount of memory that must be allocated. See
“Performance Tuning” on page 189 for information about specifying this option.
When a time-slot is configured as transparent, the arriving data will be transferred to or from the
supplied buffers without regard to any alignment since there is no internal synchronization as
with HDLC and its leading flags. This results in the data being bit-shifted. On the PCI384,
PCE385, and CPC388 controllers, this shifting can be eliminated by specifying “syncSlot” for
the connection.
Controller Reconfiguration
The NWC utility can be used to not only initially configure a controller but also to reconfigure it.
After the controller has been configured with a configuration file, any device, with some
exceptions, can be reconfigured with a different configuration file without configuring any other
device or having to reset the controller or reconfigure the whole product.
All mandatory system configuration parameters must be specified in the reconfiguration file.
This enables the NWC to verify the configuration file’s compatibility with the destination
controller.
As mentioned in “System Configuration Parameters,” on page 21, not specifying any
configuration for a device will prevent that device from being configured. The only exception to
this is that if any H.110 switch connections are made to a port, that port’s portId and lineType
must be specified so that the NWC has the information required to perform error checking on
the timeslot specification. Specifying this information for a port does not cause it to be
reconfigured.
Adding H.110 switch connections require special attention since each connection’s end point
determines the reconfiguration process. If a reconfiguration connection specifies a port, the
CTBus/H.110 bus, or the PTMC/H.110 bus; no previous configuration can specify the same
port/stream and timeslot. This is due to the NWC having no access to any previous
configurations and there being no current syntax to inform the NWC to close a connection. If a
reconfiguration connection specifies a processor channel that has been configured before, all
connections from host applications to linkIds must be closed whether they are associated with
the processor channel or not before the reconfiguration is performed. In addition, all H.110
switch connections must be reconfigured due to the H.110 switch being reset and the NWC
having no access to any previous configurations.
The H.110 switch reset and reconfiguration can be avoided by specifying the system
configuration noHscmReset option. This limits what can be changed in a processor channel
connection to the processor channel parameters only. That is, the processor channel cannot be
connected to a different end point. In addition, all processor channel connections associated
with the processor channel being reconfigured must be re-specified if that connection is to be
used.
TDM Controllers
27
The processor channel must be specified (see “Processor Channel Configuration Parameters,”
on page 23) in the reconfiguration file if H.110 switch connections are specified to it and the
processor channel was not configured by the previous configuration.
The only reconfiguration that is not allowed is changing a controller’s SS7 mode. To effect this
change the controller must be reset.
Sub-Channeling
Sub-channeling involves dividing a processor channel connection/timeslot into smaller parts or
channels. For example, dividing a connection into two four-bit channels or a two-bit channel
and a six-bit channel. Sub-channeling is specified with consecutive H.100 switch connection
statements each with the same sourceSpec and consecutive linkIds. The connection with the
least significant bit must be associated with the lowest linkId progressing to the most significant
bit associated with the highest linkId. In addition, all sub-channel linkIds associated with a
processor channel connection must be either less than 128 or greater than or equal to 128
since all sub-channels must be on the same processor channel and the NWC uses the linkId to
assign the processor channel.
The following is an example of sub-channeling a port’s timeslot:
T1 1 9 bi ProcChan 100 hdlc 2
T1 1 9 bi ProcChan 101 hdlc 2
T1 1 9 bi ProcChan 102 hdlc 2
T1 1 9 bi ProcChan 103 hdlc 2
All sub-channels for a timeslot must specify consecutive bits and include the least significant
bit. For example, if two-bit sub-channels are specified, bits 0 & 1, 2 & 3, and 4 & 5 can be
specified but neither 2 & 3, 4 & 5, and 6 & 7 nor 0 & 1, 4 & 5, and 6 & 7 are valid specifications.
If all of the bits in a timeslot are not specified, as in the previous valid example, the next
timeslot’s specification must contain the padToByteAlign option.
The following are other restrictions placed by the WAN STREAMS software on the number of
sub-channels that may be specified:
The maximum number of DS0s per processor channel is 128 and the maximum number of link
identifiers per processor channel is 256.
The maximum number of linkIds per processor channel is 128. This limit is imposed by the
NWC since it uses the link identifier for processor channel assignments. If the customer does
his own configuration, all 256 link identifiers can be used on one processor channel.
The maximum number of linkIds is 128 per port. This maximum allows all 32 DS0s in an E1
port to be divided into four 2-bit sub-channels but does not allow all of them to be divided into 8
1-bit sub-channels.
Chapter 2: NWC Configuration
28
In addition to these restrictions, the processor channel hardware places other restrictions on
the number of sub-channels that may be specified. Since these restrictions are due to the
processing time required verses the time available, they are not fixed restrictions. For example,
if all channels and sub-channels are transparent connections, more sub-channels may be able
to be processed since less processing is performed for each compared to that required by
HDLC. Also, if sub-channeled timeslots are interspersed with regular timeslots, the processor
has time to catch up and more sub-channel timeslots may be able to be specified. The
wcp388SubChanT1 configuration file provides a baseline for the maximum number of sub-
channels that can be specified.
Serial Controllers
Currently there are no configuration sections for serial controllers.
29
Chapter 3
WCP Network Configuration
Overview
The NexusWare communications controller is initially set up to have the connections to its
client side applications be made over the PCI bus. The alternate method for such connections
is using TCP/IP over the Ethernet interface.
Table 3-1lists the topics covered in this chapter.
Access to the NexusWare Controller
The NexusWare controller offers a full Linux OS environment, and can be accessed through its
console port. The initial login for the card is "root", and there is no password.
pticonfig File Setup
The pticonfig file is a configuration file that is used as a flexible, efficient way to configure the
network on the host board, and to choose what driver modules to load. The file is located in
/etc. Table 3-2 shows the ethernet configuration options available to the user.
Table 3-1:
Topics in this Chapter
Topic Page
Access to the NexusWare Controller Page 29
pticonfig File Setup Page 29
The mps Service Page 31
The updateTimeOfDay Task Page 31
Table 3-2:Ethernet Configuration Options
Variable Definition
NETWORKING Type “Y” to load the ethernet driver, and to use the Networking
options.
NISDOMAIN Domain name for the network. Use NISDOMAIN if DHCP does not
provide a domain name.
HOSTNAME Name of the host board (CPC388/CPC395). Use HOSTNAME if
DHCP does not provide a host name.
MOUNT List of file systems to mount after the network has been configured.
DAEMON List of daemons to start AFTER the network has been configured.
DEVICES List of network devices to configure.
eth0_IPADDR The static IP address of the CPC388/CPC395 board (x.x.x.x)
eth0_GATEWAY The IP address of the gateway (x.x.x.x)
Chapter 3: WCP Network Configuration
30
30
Note:A secondary Ethernet port is available as part of NexusWare and its parameters are also
selectable in the config file. Those parameters are identical to the first Ethernet port, although
they are designated with eth1 as the prefix (e.g. eth1_IPADDR).
Editing the pticonfig File
To edit the pticonfig file:
cd /etc
vi pticonfig
Manually change the file to reflect the desired settings and then save the file after all
modifications are complete.
Saving the Configuration
After changes to the /etc/pticonfig, /etc/host, and /etc/fstab files are made, save with the
following command:
save_config
This will save the configuration to flash.
Example Configurations
The following are examples of configuration settings for typical systems:
Dynamic IP network (using DHCP)
NETWORKING="Y”
eth0_USE_DHCP="Y"
eth0_DHCP_SETHOSTNAME="Y"
eth0_DHCP_SETDOMAINNAME="Y"
NISDOMAIN=""
HOSTNAME=""
eth0_NETMASK The netmask used; usually 255.255.255.0
eth0_NETWORK The IP address of the machine that the host board (CPC388/
CPC395) is installed in.
eth0_BROADCAST The broadcast address of the network the host board (CPC388/
CPC395) is on.
eth0_USE_DHCP “Y” or “N” to select whether DCHP is used or not.
eth0_DHCP_SETHOSTNAME Sets host name of the DHCP client.
eth0_DHCP_SETDOMAINNAME Sets the domain name of the DHCP client.
eth0_DHCP_HOST Host name of the DHCP server.
Table 3-2:Ethernet Configuration Options
The mps Service
31
Static IP Network
NETWORKING="Y"
NISDOMAIN=""
HOSTNAME="/samplehostname"
eth0_IPADDR="192.168.6.23"
eth0_GATEWAY="192.168.6.9"
eth0_NETMASK="255.255.255.0"
eth0_NETWORK="192.168.6.0"
eth0_BROADCAST="192.168.6.255"
The mps Service
In order for a client application to access the NexusWare controller over the network during
runtime operations, the service name (mps) and port number must be added to the file /etc/
services on the client. The port number value should be the same as the one specified in the
NexusWare controller's /etc/services file (48879 by default). The entry should look something
like:
mps 48879/tcp # TCP, normal mode
A client application uses the service name in the column to establish a connection to the server
through the PT API. You should always use the service name mps.
The port number in the second column must be followed by /tcp, which specifies the TCP/IP
protocol to be used to access the server.
The server’s logical hostname and Internet address should also be maintained in the host
machine's /etc/hosts database.
The updateTimeOfDay Task
This task is designed to periodically update the system Time Of Day with that of a time server
peer with rdate. Both the Peer and the update interval are definable system parameters which
are stored in the configuration file /wanStr/updateTimeOfDay.conf. This program will read the
configuration information at controller startup. If there is a change made to the configuration
file, the task must be re-started for them to take affect. The easiest way to achieve this is by
restarting the controller.
The format of the configuration file (updateTimeOfDay.conf) is:
[IP Address] [Seconds]
where IP Address is the IP Address of the time server, and Seconds is the number of
seconds in between intervals. A -1 value for seconds will disable this feature. TCP/IP
connectivity is needed to properly transact the time update requests. Note, after editing the
updateTimeOfDay configuration file, be sure to run save_config before rebooting the
controller.
Chapter 3: WCP Network Configuration
32
32
33
Chapter 4
Client Utilities
Overview
This chapter contains information about the client utilities used to monitor and maintain the
WCP software running on the NexusWare controller. The utilities are installed in the PTI bin
directory. A description of each utility is provided inthe chapter.
Table 4-1lists the topics covered in this chapter.
Download Program (wcpLoad)
The wcpLoad utility provides an easy way to update the communication controller with the
latest kernel software. A valid, bootable wcp kernel image must exist on the card for this utility
to work. If both kernel images are corrupt on the card, an alternate flash utility must be used.
Therefore, care must be taken not to corrupt both kernel images, but to leave one in a bootable
state.
This utility performs some basic checking to see if the image file you provide is valid to be
flashed. If these checks fail, you are given the option to flash with the image file anyway. Flash
only a valid image file or your kernel will be corrupt.
Although not specifically associated with loading an image on the controller or resetting the
card, the '-t' option is used as a way to demonstrate how to instruct a controller to synch up its
Time Of Day with the with that of the host system. When the controller is initially reset, the host
sets the Time Of Day for the card. The card could drift after many hours of uptime. The host
driver supports an IOCTL, MPS_SYNCH_TIME, which will synch up the time on the controller
when desired. The IOCTL, MPS_SYNCH_TIME_CONDITIONAL can also be used. In this case,
if the time difference between the host and the controller is not in a specified microsecond
window, it will be rejected.
Table 4-1:
Topics in this Chapter
Topic Page
Download Program (wcpLoad) Page 33
Events Monitor Program (eventsClient) Page 36
NWSL Command Line Interface Utility (nwslCli) Page 38
NWSL Copy Utility (nwslCp) Page 39
Chapter 4: Client Utilities
34
Another use of this utility program is to access the global Maximum Memory setting that the
low-level drivers (HDLC, SBSI, Async) use to determine how much data to backlog due to the
Host application(s) not reading fast enough. When the limit is hit, newly arrived data will be
dropped, and the Receive Overrun statistic is updated. For burst oriented traffic, a larger value
might resolve lost messages. Note, if the Host application is not allowed enough time to read
the data off, the controller will eventually hit the limit no matter how large the Maximum Memory
value is set to.
To get and set the Maximum Memory value, the wcpLoad utility connects to the Link
Maintenance task, and issues an WANSTRREQ_MAX_MEMORY IOCTL with the appropriate action
declared.
Note:The new Maximum Memory pool setting only is valid while the controller is running. If it
is rebooted, the value has to be reset again.
This utility can also be used to reset an unresponsive protocol link. The ‘-l’ option can be used
to send a WANSTRREQ_RESET_LINK to the wanStr Driver for the link to be reset. For the lapd
and hnrm protocols, the ‘-a’ option can send an additional IOCTL,
WANSTRREQ_RESET_LINK_2, which will be required to restart the link after the reset IOCTL
has been issued. This is because of the way these protocol’s daemons setup the wanStr Driver.
This utility can also be used to unbind an unresponsive Radar multiplexed protocol link. The ‘-u’
option can be used to send a WANSTRREQ_RDR_EXTERN_UNBIND to the wanStr Driver for the
link to be unbound. The Radar protocol will then send an RDR_EXTERN_UNBIND primitive to
the application (refer the Radar Receiver User’s Guide for more information). This IOCTL can
be used for the Radar protocol instead of the WANSTRREQ_RESET_LINK IOCTL when several
links are multiplexed under a controlling stream and just one lower link needs to be unbound.
The WANSTRREQ_RESET_LINK IOCTL will still work for the Radar protocol to reset a one-to-
one, non-multiplexed stream connection.
Name
wcpLoad - PT’s utility for updating the communication controller.
Synopsis
wcpLoad [-c controller] [-f image file] [-k kernel number] [-t] [-r] [-R] [-
m] [-X] [-z] [-v verbose][-D] [-C val] [-n][-s server] [-S service] [-g] [-p
memVal] [-l link num] [-a link num] [-u link num]
[-d link num]
Options
-c ctlrnum
Load image to controller number ctlrnum. If this option is not specified, controller number 0
will be loaded.
-f image file
This parameter identifies the path and filename to use as the image file to be flashed to the
kernel.
-k kernel num
Download Program (wcpLoad)
35
Load image to kernel number kernel num. There are two kernels available on the controller:
0 and 1. If this option is not specified, kernel number 0 will be loaded. The controller will be
rebooted to the new image after the load process.
-m
Issues an MCC terminate command to the controller specified by the -c option, controller
number 0 is the default.
-n
No reset of controller after firmware has been loaded. This option is handy when updating the
firmware of the MPS1000. One hard reset can be issued when complete.
-R
Reset the controller through a TCP/IP connection. The controller must be in an operable state
with networking enabled for the reset to succeed.
-r
Reset the controller specified by the -c option, controller number 0 is the default. The reset is
issued through the Host driver; no special connection to the card is required. This is the
preferred method to issue a reset since the controller can be in any state. This option is valid
only for embedded controllers.
-s server
This parameter identifies the targets server. For a LAN-based server, this is the logical host
name as specified in the client's /etc/host database. For a controller installed in a backplane,
server is the path name of the driver's cloneable special file. If not specified, the server name
defaults to /dev/ucsclone.
-S service
For LAN-based servers, this parameter identifies the service name to be accessed, as a
specified in the client's /etc/services database. If not specified, service defaults to mps. This
parameter is not required for embedded controllers.
-t
Synch up the specified controller's Time Of Day with the host. This option is valid only for
embedded controllers.
-v verbose
This parameter is used to display informational messages about the progress of the command
being issued.
-D
Dynamically turn on/off Time Sync debugging on the controller. When on, the controller will
print console messages.
-C value
This will specify conditional time synchronization. The value is the maximum number of
microseconds the controller and host time values can be apart.
Chapter 4: Client Utilities
36
-X This command prohibits the MCC terminate command from being issued during a
controller reset.
-zS
can the bus for all functional controllers and issue an MCC terminate command to each.
-g
Get the current Maximum Memory Pool value.
-p memValue
Set the current Maximum Memory Pool value to memValue.
-l link num
This parameter is used to reset an unresponsive protocol link. Link num is the link to be reset.
-a link num
This parameter is used to restart a link after a link is reset. This reset is required by protocols
like lapd and hnrm that run daemons which cannot restart the link after a reset. Link num is the
link to be restarted.
-u link num
This parameter is used to unbind an unresponsive Radar protocol link. Link num is the link to
be unbound.
-d link num
This parameter is used to both unbind an unresponsive Radar protocol link and have the links
state set to Detached. Future connections to this link will need to go through the Radar Attach
process. Link num is the link to have this action applied to.
Example
The following is a sample download session:
kirin% wcpLoad -f cpc3xx.img -k1
wcpLoad for controller: 0 (0x3880)
Transfer of image file to board in progress.
Percent Complete 100.0%
Image file copied to board.
Board will now be flashed with image file. This may take a while.
Controller will now be reset.
Now rebooting controller: 0
kirin%
Events Monitor Program (eventsClient)
The eventsClient utility provides remote registration and receipt of asynchronous events
detected by the embedded controller. This utility may be used to monitor these events or as an
example of how these events may be monitored.
Events Monitor Program (eventsClient)
37
Name
eventsClient - PT’s asynchronous events monitoring program.
Synopsis
EventsClient [-s server] [-S service] [-c ctlrnum]
Description
The eventsClient utility uses the Application to Controller Communications in conjunction with
the MPSapi to communicate with the embedded controller. This allows the user to monitor,
using either the backplane or a LAN, all asynchronous events detected and reported by the
embedded controller.
Options
-s server
This parameter identifies the target server. For a LAN-based server, this is the logical host
name as specified in the client’s hosts database. For a controller installed in a backplane,
server is the path name of the driver’s cloneable special file. If this option is not specified, the
server name defaults to /dev/ucsclone for UNIX and Linux, and \\.\PTIXpqcc for Windows NT.
-S service
For LAN-based servers, this parameter identifies the service name to be accessed, as
specified in the client’s services database. If this option is not specified, the service name
defaults to mps. For a controller installed in a backplane, this parameter is not used.
-c ctlrnum
Specifies the controller to use. If this option is not specified, the controller number defaults to 0.
For a LAN-based controller, this parameter is not used.
Interpreting the Events Report
Whenever an asynchronous event is detected by the embedded controller, it sends
notifications of the event to all registered connections. The following is a sample report:
Event type = 0x00040001, device # = 6, time stamp = 240538, Event =
0x00000001.
Event type
This value identifies the type of device that detected the event and, in some cases, the type of
event detected. Its values are defined in Application to Controller Communications, sub-section
Asynchronous Events Messages and wcpMPSapi.h.
device #
Chapter 4: Client Utilities
38
This value identifies the instance of the device that detected the event with 0 always identifying
the first instance. If only one instance of the device exits, this value is always 0. For example, if
the embedded controller monitors and controls eight T1 lines, this value identifies which of the
eight T1 lines the event was detected on.
time stamp
This value represents the time when the event was detected, in
1/100ths of a second since the embedded software was started.
Event
This value provides more identifying information on the detected event. This information is
described in Application to Controller Communications, sub-section Asynchronous Events
Messages and wcpMPSapi.h.
NWSL Command Line Interface Utility (nwslCli)
The nwslCli utility provides a method to issue simple commands which will be executed on the
NexusWare-EMB controller. The output results (stdout and stderr) of the execution of the
command will then be displayed. This utility gives the user the ability to perform many tasks
that previously required a console connection to the controller.
This utility is intended to be used for “backdoor” debugging and/or specific modification of the
behavior of the controller. A general rule of thumb is that the command-line issued should
return with no more input required, else the nwslCli utility will wait forever for a response. Do
not issue something like “vi /tmp/foo.bar”. The user of this utility should be aware of the
consequences of the commands issued since they are run with Super User privileges.
After the nwslCli utility has successfully opened a connection to the controller specified, it will
then either continuously prompt and process the user for commands (exit with ctlr-c or
ctlr-d), or just process the one specified command. The results of the command will be
displayed as standard output from this utility.
Name
nwslCli - PT’s command line interface utility used for debugging and controller behavior
modification.
Synopsis
nwslCli [-c controller] [-s server] [-S service] command
Options
-c controller This parameter specifies the controller number. If not issued, controller
defaults to 0.
NWSL Copy Utility (nwslCp)
39
-s server This parameter identifies the targets server. For a LAN-based server,
this is the logical host name as specified in the client’s /etc/host
database. For a controller installed in a backplane, server is the path
name of the driver’s cloneable special file. If not specified, the server
name defaults to /dev/ucsclone.
-S service For LAN-based servers, this parameter identifies the service name to
be accessed, as specified in the client’s /etc/services database. If not
specified, service defaults to mps. This parameter is not required for
embedded controllers.
command This allows the user to specify the command line to be processed up
front. After the command is complete, the utility exits. Use double
quotes ("") around the command that you wish to send to the card if it
has special shell characters in it (like "-x").
Example
[victoria]$ nwslCli
nwslCli> peekl 0x30000000
38801214
nwslCli> pti_info device_id
PCI Device ID : 0x3880
nwslCli> cat /proc/mcc_drv
MCC driver v50 Built May 27 2003
Buffer Memory: 0
mcc0: Features: []
mcc1: Features: []
nwslCli> ^C
[victoria]$
NWSL Copy Utility (nwslCp)
The nwslCp utility provides a method to transfer a file from a client host down to the
NexusWare-EMB controller and vice versa. It gives the user the ability to perform tasks that
previously required a console connection to the controller, i.e. logging on the controller to
modify a configuration file (updating pticonfig …).
This is helpful tool to use by Engineers for debugging when updating a software component on
the controller, especially if the controller that has no network support such as PCI384.
Building and reflashing the entire firmware can be avoided.
Note:Only one instance of nwslCp can be run at the same time.
Chapter 4: Client Utilities
40
Name
nwslCp - PT’s command line interface utility used to transfer a file from a client host down to
the NexusWare-EMB controller and vice versa.
Synopsis
nwslCp [-c controller] [-s server] [-S service] [-g] [-f] [-v] srcfile
destfile
Options
-c controller This parameter specifies the controller number. If not issued, controller
defaults to 0.
-s server This parameter identifies the targets server. For a LAN-based server,
this is the logical host name as specified in the client’s / etc/host
database. For a controller installed in a backplane, server is the path
name of the driver’s cloneable special file. If not specified, the server
name defaults to /dev/ucsclone.
-S service For LAN-based servers, this parameter identifies the service name
to be accessed, as specified in the client’s /etc/services database. If
not specified, service defaults to mps. This parameter is not required
for embedded controllers.
-g This parameter if specified, source file is copied from the controller up
to the host. Without specified, file is copied from the host down to the
controller.
-f This parameter forces to overwrite the destination file if it exists.
-v Enables verbose mode to display the completion status as copying
progresses.
srcfile Source file name
destfile Target file name. If destfile exists, nwslCp will not overwrite its
content unless –f flag is specified. If destfile does not exists, nwslCp
creates a new file named destfile that has the same mode as srcfile. If
destfile is a directory, nwslCp creates a new file named srcfile and
put it under the directory.
Example
1
Copy pticonfig from /etc on the controller to current directory on the host machine.
[victoria]$ nwslCp -g /etc/pticonfig pticonfig
2
Copy pticonfig back to /etc on the controller with a –f flag to overwrite the existing one.
[victoria]$ nwslCp -f pticonfig /etc/.
NWSL Copy Utility (nwslCp)
41
3
Copy a large image file with –v option to /tmp directory on the controller.
[victoria]$ nwslCp -v wanStrTdm.img /tmp/.
4
Copying wanStrTdm.img to /tmp in progress.
Percent Complete 44%
Chapter 4: Client Utilities
42
43
Chapter 5
MPSx000 LAN Interface
Overview
The “MPSx000” (pronounced M-P-S 'x'-thousand) term is a generic term for the MPS1000,
MPS2000, and MPS4000 server family. However, at the time of this writing, the MPS2000 and
MPS4000 are still under development. Although it is anticipated that much of the information
contained in this section will apply to those server models as well, the information presented is
specific to the MPS1000 only.
Table 5-1lists the topics covered in this chapter.
Table 5-1:
Topics in this Chapter
Topic Page
Primary and Secondary Controllers Page 44
Failover Page 44
Operating Modes Page 45
Single-LAN Mode Page 45
Dual Redundant LAN Mode Page 45
Hybrid Modes Page 46
Server Configuration Page 46
Remotely Accessing the MPS1000 Page 46
Data Connections Page 47
Control Connections Page 47
Control Requests Page 47
Tunable Parameters Page 49
Asynchronous Event Notification Page 50
Configuring Event Notification Page 50
Receiving Event Notifications Page 50
Soft Reset Page 51
Soft Reset Interface Page 52
Sample Programs Page 53
Chapter 5: MPSx000 LAN Interface
44
Primary and Secondary Controllers
A daemon task known as the “MPS1000 daemon” executes on each controller in an MPS1000
server. The daemon is responsible for accepting TCP/IP connections from remote applications,
routing messages to the appropriate controller, and performing internal coordination tasks
among the two controllers. In effect, the daemon is the heart of an MPS1000; it is the piece of
software that allows distinct controllers in an MPS1000 server to interact as a unified system
rather than as separate individual controllers. At any given time, one controller's MPS1000
daemon is executing as the “primary”, while the other controller's MPS1000 daemon executes
as the “secondary.” The controller whose MPS1000 daemon is executing as the primary is
called the primary controller; the controller whose daemon task is executing as the secondary
is referred to as the secondary controller.
The notion of primary and secondary is purely logical; a controller is capable of executing in
either context. However, only one controller in the server can be the primary at any given time;
it is impossible for both controllers to operate as primaries simultaneously. Remote applications
connect to the primary controller of an MPS1000 server to access the protocol software
handling the WAN interface, even though the desired WAN links may physically reside on the
secondary controller. It is sometimes helpful (and perhaps more accurate) to think of the
primary controller as a master, and the secondary controller as a slave; the secondary
controller only transfers data using intervention from the primary controller.
Failover
A major feature of the MPS1000 server is the ability to fail over if the LAN interface on the
primary controller is lost. A failover is a switch in mastership; the current primary controller
becomes the secondary, and the current secondary controller becomes the primary.
Note:Do not confuse "primary" and "secondary" with "Controller 0" and "Controller 1",
respectively. The notion of "primary" or "secondary" can change from one controller to the other
as the result of a failover; but Controller 0 will remain Controller 0 after the failover, and the
same is true for Controller 1.
The MPS1000 provides a grace period before actually failing over. The duration of the grace
period is one of the MPS1000's tunable parameters and is user-settable. After it is determined
that ENET-A has gone down on the primary controller, the grace period is started. The
MPS1000 continues to operate in the usual manner during the grace period (except for the
absence of the LAN). The only difference is that a timer is now active. If the LAN is restored
before the timer expires, the grace period is cancelled and no failover is performed.
Conversely, if the grace period expires before ENET-A is restored, a failover is performed.
All connections to the MPS1000 that were active at the time of a failover become stale and
unusable after failover processing completes. The MPS1000 has the ability to notify remote
applications of the occurrence of a failover, but it is the user application’s responsibility to close
its stale sessions, reestablish the connections with the new primary controller, and rebuild the
protocol stacks for each connection from scratch.
Operating Modes
45
Operating Modes
The MPS1000 server can operate in one of two modes, either Single-LAN mode or Dual
Redundant LAN mode. Although the operating mode applies to the server as a whole, it is
more accurate to say that the secondary controller operates in one of the two possible modes;
the primary controller's behavior does not change from one mode to the other.
Single-LAN mode is the operating mode for which the MPS1000 was originally developed. An
MPS1000 allows users to conserve IP addresses by providing eight WAN links (on two
controllers) that are accessed with only one IP address. However, with the addition of the
failover functionality to the MPS1000, a second mode (Dual Redundant LAN) has been added
to provide redundancy in the event of failure. The addition of a second operating mode
provides more flexibility in the design of mission-critical solutions.
Single-LAN Mode
In Single-LAN mode, the MPS1000 is connected to one LAN only; that is, the ENET-A ports of
both controllers are connected to the same LAN. However, the secondary controller has its
network link disabled, so only the primary controller can transmit or receive network traffic.
When operating in Single-LAN mode, the IP address of the MPS1000 does not change after a
failover. The new primary controller has the same IP address as the previous primary controller
had. However, the MAC address associated with the IP address changes. Thus, the MPS1000
will always be accessed with the same IP address, regardless of which controller is operating
as the primary. However, after a failover occurs, all connections with the MPS1000 that were
active at the time of the failover are stale and must be reestablished with the new primary
controller.
Dual Redundant LAN Mode
In Dual Redundant LAN mode, the ENET-A link of each controller in the MPS1000 is connected
to a separate LAN. Further, the controllers are assigned distinct IP addresses and each has its
ENET-A link enabled. Thus, both controllers are capable of sending or receiving traffic on their
respective networks simultaneously.
As always, users should connect to the primary controller when accessing an MPS1000 server
operating in Dual Redundant LAN mode. However, because each controller has its own unique
IP address, a failover results in a change of IP address for the primary controller. Stale
connections must be reestablished with the new primary controller, using the new IP address.
The secondary controller’s ENET-A link is active when operating in Dual Redundant LAN
mode. Although the secondary controller does not accept data connections, it does accept
control connections when executing in this mode. Control connections are used to control the
MPS1000’s operating characteristics from a remote application, and are described in more
detail in a later section. By allowing the secondary controller to accept control connections, this
provides a “back door” entrance into the MPS1000 server. Should the network path to the
primary controller on network ‘A’ fail, users may still access the secondary controller on network
‘B’, although in a limited capacity. The benefit of allowing backdoor access to the MPS1000 is
that users can explicitly force a failover whenever the primary controller becomes unreachable;
provided, of course, that the secondary controller is still accessible.
Chapter 5: MPSx000 LAN Interface
46
Note:The backdoor method for accessing an MPS1000 server only works provided the