Catapult Ref Man

IxCatapult Software Reference Manual
Release 20.1
December 2010
Copyright 2010 Ixia. All rights reserved. This publication may not be copied, in whole or in part, without Ixias consent. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.22719. Ixia, the Ixia logo, and all Ixia brand names and product names in this document are either trademarks or registered trademarks of Ixia in the United States and/or other countries. All other trademarks belong to their respective owners. The information herein is furnished for informational use only, is subject to change by Ixia without notice, and should not be construed as a commitment by Ixia. Ixia assumes no responsibility or liability for any errors or inaccuracies contained in this publication.
Corporate Headquarters
Ixia Worldwide Headquarters 26601 W. Agoura Rd. Calabasas, CA 91302 USA +1 877 FOR IXIA (877 367 4942) +1 818 871 1800 (International) (FAX) +1 818 871 1805 sales@ixiacom.com
Web site: www.ixiacom.com General: info@ixiacom.com Investor Relations: ir@ixiacom.com Training: training@ixiacom.com Support: support@ixiacom.com +1 818 595 2599 For the online support form, go to: http://www.ixiacom.com/support/inquiry/ Support: eurosupport@ixiacom.com +44 1628 405797 For the online support form, go to: http://www.ixiacom.com/support/inquiry/ ?location=emea
EMEA
Ixia Europe Limited One Globeside, Fieldhouse Lane Marlow, SL7 1HZ United Kingdom +44 1628 405750 FAX +44 1628 405790 salesemea@ixiacom.com
Asia Pacific
Ixia Pte Ltd 210 Middle Road #08-01 IOI Plaza Singapore 188994
Support: Support-AsiaPac@ixiacom.com +65 6332125 For the online support form, go to: http://www.ixiacom.com/support/inquiry/ Support: Support-Japan@ixiacom.com +03 5326 1948 For the online support form, go to: http://www.ixiacom.com/support/inquiry/
Japan
Ixia Communications K.K. Nishi-Shinjuku Mitsui Bldg. 11F 6-24-1 Nishi Shinjuku Shinjuku-ku, Tokyo 160-0023 Japan
India
Ixia Technologies Pvt Ltd 2nd Floor, 19/1, Vithall Malya Road, Bangalore 560 001 India
Support: Support-India@ixiacom.com +91 80 22161000 For the online support form, go to: http://www.ixiacom.com/support/inquiry/ ?location=india
Table of Contents
Chapter 1. Overview 1.1 Overview ...................................................................... 1-2 1.1.1 Software ............................................................... 1-2 1.1.2 Hardware .............................................................. 1-2 1.2 References ................................................................... 1-3 1.3 Revision History ............................................................ 1-4 Chapter 2. Configuring an IxCatapult Session 2.1 Introduction .................................................................. 2-2 2.2 sysconfig Main Window ................................................... 2-2 2.2.1 Host Menu ............................................................. 2-3 2.2.2 Auto Config ........................................................... 2-3 2.2.3 Navigation ............................................................. 2-4 2.2.4 File Menu .............................................................. 2-4 2.2.5 Edit Menu .............................................................. 2-5 2.2.6 Action Buttons ....................................................... 2-5 2.3 User Security ................................................................ 2-6 2.4 Command-Line Parameters ............................................. 2-6 2.5 System Configuration File ............................................... 2-7 2.6 PPCI (E1/T1) Configuration Windows ................................ 2-7 2.6.1 Operating Modes .................................................... 2-7 2.6.2 Transmit Clock ....................................................... 2-9 2.6.3 Channel Selection ................................................... 2-9 2.6.4 Data Inversion ..................................................... 2-10 2.6.5 T1-Specific Options ............................................... 2-10 2.6.6 E1-Specific Options ............................................... 2-10 2.6.7 Alarms ................................................................ 2-11 2.6.8 PCM Coding ......................................................... 2-11 2.6.9 Handset Microphone ............................................. 2-11 2.6.10 Codec Modes ..................................................... 2-11 2.6.11 Codec Operation ................................................. 2-11 2.7 PPCI (E1_ATM/T1_ATM) Configuration Windows ............... 2-12 2.8 PPCI (J1/E1/T1) Configuration Window ........................... 2-13 2.8.1 Board-Level Configuration ..................................... 2-13
Table of Contents
Ixia
2.8.2 Link-Level Configuration ........................................ 2-15 2.8.3 Port-Level Configuration ........................................ 2-16 2.9 PPCI (Serial) Configuration Window ................................ 2-19 2.9.1 Physical Interface ................................................. 2-19 2.9.2 Operating Modes .................................................. 2-19 2.9.3 Clocking .............................................................. 2-19 2.9.4 Data Inversion ..................................................... 2-19 2.9.5 Flow Control ........................................................ 2-20 2.10 PPCI (BRI S/T) Configuration Window ........................... 2-20 2.10.1 Operating Modes ................................................ 2-20 2.10.2 Channel Selection ............................................... 2-21 2.10.3 Switchable Channels ........................................... 2-21 2.10.4 Data Ports ......................................................... 2-22 2.10.5 PCM Coding ....................................................... 2-23 2.10.6 Handset Microphone ............................................ 2-23 2.10.7 Codec Modes ...................................................... 2-23 2.10.8 Codec Operation ................................................. 2-23 2.11 PPCI (CII) Configuration Window .................................. 2-24 2.12 PPCI (OC3E) Configuration Window .............................. 2-25 2.12.1 Operating Modes ................................................ 2-25 2.12.2 VPI/VCI Modes ................................................... 2-25 2.12.3 Framing Format .................................................. 2-25 2.12.4 Cell Header Mask ................................................ 2-26 2.12.5 Empty Cell Header .............................................. 2-26 2.12.6 Empty Cell Payload ............................................. 2-26 2.12.7 Link Parameters ................................................. 2-26 2.12.8 Multiple VPI/VCI Mode Parameters ........................ 2-26 2.12.9 Port Configuration ............................................... 2-27 2.12.10 Traffic ............................................................. 2-28 2.12.11 Performance Limitations ..................................... 2-28 2.12.12 Alarms ............................................................. 2-28 2.13 PPCI (Ethernet) Configuration Window .......................... 2-30 2.13.1 Emulation Mode .................................................. 2-30 2.13.2 Monitor Mode ..................................................... 2-32 2.13.3 General Limitations ............................................. 2-33 2.13.4 Port Status Indications ........................................ 2-33 2.14 PPCI (GigE) Configuration Window ................................ 2-34
ii
IxCatapult Software Reference Manual, Release 20.1
Ixia
Table of Contents
2.14.1 Configuring the Board in Emulation Mode ............... 2-34 2.14.2 VLAN Configuration ............................................. 2-36 2.14.3 General Limitations ............................................. 2-37 2.14.4 Port Status Indications ........................................ 2-38 2.15 mCI(ATM) Configuration Window ................................. 2-39 2.15.1 Variable Bit Rate Support .................................... 2-42 2.16 mPI(Ethernet) Configuration Window ............................ 2-42 2.16.1 VLAN Configuration ............................................. 2-45 2.16.2 Restrictions and Limitations ................................. 2-46 2.17 mPI(OC3) Configuration Window .................................. 2-47 2.18 mPI(STM) Configuration Window .................................. 2-51 2.18.1 Standard and Card Type ...................................... 2-51 2.18.2 Physical Links .................................................... 2-51 2.18.3 Mode (Link or Port Interface and Global Options) .... 2-51 2.18.4 Sync Clock ......................................................... 2-52 2.18.5 ITU-T G.707 E1/T1 Number Scheme ..................... 2-52 2.18.6 Physical Interface Type ....................................... 2-52 2.18.7 Transmit Framing ............................................... 2-52 2.18.8 Receive Framing ................................................. 2-52 2.18.9 Signalling .......................................................... 2-52 2.18.10 PCM Idle Pattern ............................................... 2-52 2.18.11 Mode (Drop and Insert and Data Port Options) ...... 2-53 2.19 mCU(5)/mCU5E Configuration Window ......................... 2-53 2.20 UNIX Device Configuration Window .............................. 2-53 2.20.1 Using IPv4 and IPv6 Addresses ............................. 2-53 2.20.2 TTY Ports ........................................................... 2-54 2.20.3 TCP Socket Endpoints ......................................... 2-54 2.20.4 UDP Socket Endpoints ......................................... 2-55 2.21 Slot-Independent Naming ........................................... 2-56 2.22 Environment Variable Slot Definitions ........................... 2-58 Chapter 3. Running an IxCatapult Session 3.1 Introduction .................................................................. 3-2 3.2 IxCatapult Launcher ....................................................... 3-2 3.2.1 Running the IxCatapult Launcher .............................. 3-2 3.2.2 IxCatapult Launcher Window .................................... 3-2 3.2.3 Creating and Configuring Contexts ............................ 3-3 3.2.4 Creating and Configuring Connections ....................... 3-8
IxCatapult Software Reference Manual, Release 20.1 iii
Table of Contents
Ixia
3.2.5 Associating Context Ports to Board Ports and Interboard Ports ...................................................................... 3-15 3.2.6 ddriver Include File ............................................... 3-15 3.2.7 ddriver Log File .................................................... 3-16 3.2.8 System Configuration File ...................................... 3-16 3.2.9 Sector Configuration File ....................................... 3-16 3.2.10 Workstation Data Heap Memory Size ..................... 3-16 3.2.11 m500 Data Heap Memory Size .............................. 3-17 3.2.12 Display Format ................................................... 3-17 3.2.13 Running ddriver from the Launcher ....................... 3-17 3.2.14 Running ddriver as a Batch Job ............................. 3-17 3.2.15 Reading and Writing Files ..................................... 3-18 3.2.16 Importing Files ................................................... 3-18 3.2.17 Printing the Canvas ............................................. 3-18 3.2.18 Managing the Library of Contexts .......................... 3-19 3.2.19 Interfacing with Support Tools .............................. 3-19 3.2.20 Viewing Manuals ................................................. 3-20 3.2.21 Setting Preferences ............................................. 3-21 3.2.22 Command-Line Parameters .................................. 3-21 3.2.23 Running the Launcher from a Makefile ................... 3-24 3.2.24 Limitations ......................................................... 3-24 3.3 ddriver ....................................................................... 3-25 3.3.1 Sample ddriver Command Line ............................... 3-28 3.3.2 Re-Routing ddriver Output ..................................... 3-28 3.3.3 ddriver Windows ................................................... 3-29 3.3.4 Main Window in Detail Mode ................................... 3-29 3.3.5 Main Window in Brief Mode .................................... 3-31 3.3.6 Control Characters ................................................ 3-33 3.3.7 Limitations .......................................................... 3-34 3.3.8 System Monitor .................................................... 3-37 3.3.9 Error Reporting .................................................... 3-38 Chapter 4. Creating and Decoding Log Files 4.1 dctprint ........................................................................4-2 4.1.1 Command-Line Parameters ......................................4-2 4.1.2 Environment Variables ............................................4-3 4.1.3 Example ................................................................4-3 4.2 out2csv ........................................................................4-4
iv
Ixia
Table of Contents
4.2.1 Command-Line Parameters ...................................... 4-4 4.2.2 Example ................................................................ 4-5 Chapter 5. Compiling DCPL Scripts 5.1 DCPL Compiler .............................................................. 5-2 5.1.1 Command-Line Parameters ...................................... 5-2 5.2 Limitations ................................................................... 5-6 5.2.1 File Size ................................................................ 5-6 5.2.2 Line Length ........................................................... 5-6 5.2.3 DOS Files .............................................................. 5-6 Chapter 6. DFB Application 6.1 Introduction .................................................................. 6-2 6.2 DCPL Frame Builder Window ........................................... 6-2 6.2.1 Mouse Buttons ....................................................... 6-2 6.2.2 GUI Buttons .......................................................... 6-3 6.3 Command Line .............................................................. 6-3 6.4 Editing the Generated DCPL ............................................ 6-4 6.5 Building a Template ....................................................... 6-5 6.6 Limitations ................................................................... 6-6 Chapter 7. TTY Protocol 7.1 TTY Protocol ................................................................. 7-2 7.2 TTY Device Configuration ................................................ 7-2 7.2.1 Physical SPARC Ports .............................................. 7-2 7.2.2 TCP/UDP Sockets ................................................... 7-4 7.2.3 RAW IP Sockets ..................................................... 7-6 7.3 DCPL Customization for TTY Protocol ................................ 7-8 Chapter 8. Digital Communications Programming Language (DCPL) 8.1 Basic Syntax ................................................................. 8-2 8.1.1 Compiled and Interactive DCPL ................................ 8-2 8.1.2 Context Names and Port Expressions on Statements ... 8-2 8.1.3 Line Continuation ................................................... 8-3 8.1.4 Literal Values ......................................................... 8-3 8.1.5 Comments ............................................................ 8-3 8.1.6 Capitalization ......................................................... 8-4 8.1.7 Conversion from Integer to String ............................ 8-4 8.1.8 DCPL Keywords ...................................................... 8-4
Table of Contents
Ixia
8.1.9 Line Length ...........................................................8-4 8.2 Variables ......................................................................8-5 8.2.1 String and Integer Variables ....................................8-5 8.2.2 Scalar and Array Variables .......................................8-5 8.2.3 Port-Specific and General Variables ...........................8-5 8.2.4 Interaction of Port-Specific Statements and Variables ..8-6 8.2.5 Default Variables ....................................................8-6 8.2.6 Special Variables ....................................................8-6 8.3 Expressions ..................................................................8-7 8.3.1 Integer Expressions ................................................8-7 8.3.2 String Expressions ..................................................8-8 8.4 Statements ...................................................................8-9 8.4.1 Data Manipulation Statements ..................................8-9 8.4.2 Flow Control Statements ....................................... 8-10 8.4.3 Comment Statements ........................................... 8-17 8.4.4 Input/Output Statements ....................................... 8-18 8.4.5 Interval Timer Statements ..................................... 8-28 8.4.6 Compiler/Interpreter Statements ............................ 8-31 8.4.7 StatsView API ...................................................... 8-34 8.5 Functions .................................................................... 8-34 8.5.1 Integer Functions ................................................. 8-34 8.5.2 String Functions ................................................... 8-37 8.5.3 Dynamic TDM Channel Functions ............................ 8-54 8.5.4 Field Reference Functions ...................................... 8-56 8.5.5 Cryptographic Functions ........................................ 8-57 8.6 Field Reference ............................................................ 8-75 8.6.1 Field Reference Syntax .......................................... 8-75 8.6.2 Field Reference Modes ........................................... 8-76 8.6.3 Field Reference Forms ........................................... 8-77 8.6.4 Sample Script ...................................................... 8-78 8.6.5 Using Negative Integers with FRS ........................... 8-79 8.6.6 Information Element Fields that Have the Same Label 8-80 8.6.7 Difference Between FRS and locate ......................... 8-80 8.6.8 Exceptions ........................................................... 8-81 8.7 Macros ....................................................................... 8-82 8.7.1 Predefined Macros ................................................ 8-83 8.7.2 Limitations .......................................................... 8-84
vi
Ixia
Table of Contents
8.8 Special and Predefined Variables ................................... 8-84 8.8.1 Generic Special Variables ...................................... 8-84 8.8.2 Protocol-Specific Special Variables .......................... 8-87 8.8.3 E1/T1 Special Variables ......................................... 8-89 8.8.4 BRI S/T Special Variables ...................................... 8-90 8.8.5 CII Special Variables ............................................. 8-91 8.8.6 Serial Special Variables ......................................... 8-92 8.8.7 Dynamic TDM Special Variables for J1/E1/T1 ............ 8-93 8.8.8 OC-3 and OC-3E Special Variables .......................... 8-93 8.8.9 mCI(ATM) Special Variables ................................... 8-94 8.8.10 Ethernet Special Variables ................................... 8-98 8.8.11 mPI(STM) Special Variables ................................. 8-99 8.8.12 VLAN Special Variables ...................................... 8-102 8.8.13 mPI(GigE) Special Variables for IP Port Forwarding 8-103 8.9 DCPL Keywords ......................................................... 8-107 8.10 Differences in DCPL Between IxCatapult and DCT-S ...... 8-108 8.10.1 All Scripts are Multi-Ported ................................. 8-108 8.10.2 Size of Integer Variables .................................... 8-108 8.10.3 Non-Port-Specific Variables ................................ 8-108 8.10.4 Unsupported DCPL Statements ........................... 8-108 8.10.5 Renamed DCPL Statements ................................ 8-108 8.10.6 Port Numbers on Statements ............................. 8-108 8.10.7 Macro Parameters ............................................. 8-108 8.10.8 Multi-Line Macros ............................................. 8-109 8.10.9 Renamed DCPL Special Variables ........................ 8-109 8.10.10 Unsupported DCPL Special Variables .................. 8-109 8.10.11 Case Keyboard ............................................... 8-109 8.10.12 Default &timeout Value is 0 .............................. 8-110 8.11 Design Considerations .............................................. 8-110 8.12 Limitations .............................................................. 8-110 Chapter 9. C Interface 9.1 Introduction .................................................................. 9-2 9.2 Calling C Procedures from DCPL ....................................... 9-2 9.3 Calling DCPL Procedures from C ....................................... 9-3 9.4 Sharing Data Between DCPL and C .................................. 9-3 9.4.1 Integer Variables .................................................... 9-4 9.4.2 String Variables ..................................................... 9-5
IxCatapult Software Reference Manual, Release 20.1 vii
Table of Contents
Ixia
9.4.3 Constants ..............................................................9-5 9.5 Avoiding Naming Conflicts with the Library ........................9-5 9.6 C-Callable Functions Library ............................................9-6 9.6.1 DINT Declaration Macros .........................................9-6 9.6.2 String Manipulation Macros ......................................9-6 9.6.3 String Manipulation Functions ...................................9-7 9.6.4 Interprocess Functions ............................................9-9 9.6.5 File System Functions ........................................... 9-10 9.6.6 Display Functions ................................................. 9-10 9.6.7 Interval Timer Functions ........................................ 9-11 9.6.8 Special Variable Access Functions ........................... 9-12 9.6.9 Miscellaneous Functions ........................................ 9-14 9.6.10 Coprocessor UNIX Library Functions ...................... 9-16 Chapter 10. Other UNIX Commands 10.1 dcpl ......................................................................... 10-2 10.2 dinuse ...................................................................... 10-2 10.3 hminfo ...................................................................... 10-3 10.4 man ......................................................................... 10-4 10.5 r_util ........................................................................ 10-4 10.6 slot_info ................................................................... 10-4 10.7 whatsinslot ............................................................... 10-4 Chapter 11. Custom Display Interface 11.1 Introduction .............................................................. 11-2 11.2 Environment Variable ................................................. 11-2 11.3 Procedure Interfaces .................................................. 11-2 11.3.1 InitialiseCustomDisplay() ..................................... 11-2 11.3.2 AddLineToCustomDisplay() .................................. 11-3 11.3.3 ClearCustomDisplay() .......................................... 11-3 Chapter 12. Intermodule Timing 12.1 Introduction .............................................................. 12-2 12.2 Clock Sources ............................................................ 12-2 12.3 Interconnecting Boards in a Domain ............................. 12-3 12.4 Minimizing Propagation Delay ...................................... 12-3 12.5 Choosing a Domain Master and Clock Source ................. 12-4 12.5.1 .clockspec File .................................................... 12-5 12.5.2 Running ppci_startup .......................................... 12-7
viii
Ixia
Table of Contents
12.5.3 .clocklog File ...................................................... 12-7 12.6 Clock Configuration and ddriver ................................... 12-8 12.7 Clock Configuration and diag ....................................... 12-8 12.8 Clock Configuration and t600 ....................................... 12-9 Chapter 13. Multiple VPI/VCI 13.1 Introduction .............................................................. 13-2 13.2 Limits ....................................................................... 13-2 13.3 User Interaction ........................................................ 13-2 13.4 sysconfig .................................................................. 13-3 13.5 User Scripts .............................................................. 13-3 13.5.1 Channel Initialization .......................................... 13-3 13.5.2 Limitations and Exceptions ................................... 13-4 13.5.3 Transmission ..................................................... 13-5 13.5.4 Reception .......................................................... 13-6 13.5.5 Channel Invalidation ........................................... 13-6 13.5.6 Other Variables .................................................. 13-7 13.6 Example ................................................................... 13-8 13.7 VPI, VCI, Link, and CID Decoding ................................. 13-9 13.8 Peak Cell Rate Configuration ..................................... 13-10 13.8.1 ATM Performance Guidelines .............................. 13-10 13.8.2 E1/T1 Board .................................................... 13-10 13.8.3 OC3 Board ....................................................... 13-11 13.8.4 OC3E, J1/E1/T1, and mCI(ATM) Boards ............... 13-11 13.8.5 mPI(OC3) Board ............................................... 13-12 13.9 Variable Bit Rate (VBR) ATM Traffic Type .................... 13-12 13.9.1 Peak Cell Rate (PCR) ......................................... 13-13 13.9.2 Sustain Cell Rate (SCR) ..................................... 13-13 13.9.3 Maximum Burst Size (MBS) ................................ 13-13 13.9.4 VBR MAKE_INIT_CELL MACROS .......................... 13-13 13.9.5 Defining VBR Traffic .......................................... 13-14 13.9.6 VBR Limitations ................................................ 13-14 13.9.7 VBR Example ................................................... 13-14 13.10 ATM OAM F4/F5 Flow Configuration .......................... 13-15 13.10.1 F4 OAM Flow Support ...................................... 13-17 13.10.2 F5 OAM Flow Support ...................................... 13-17 13.10.3 AAL0PRIM and CRC-10 Calculation .................... 13-18 13.10.4 OAM Limitations ............................................. 13-18
IxCatapult Software Reference Manual, Release 20.1 ix
Table of Contents
Ixia
13.10.5 F4 OAM Example ............................................. 13-18 13.10.6 F5 OAM Example ............................................. 13-19 Chapter 14. Dynamic TDM Channels 14.1 Introduction .............................................................. 14-2 14.2 User Scripts .............................................................. 14-2 14.3 Example ................................................................... 14-3 14.4 Adapting Legacy Applications to Dynamic TDM ............... 14-4 14.4.1 Example Multiplexer Script ................................... 14-5 Chapter 15. Channel Filter 15.1 Introduction .............................................................. 15-2 15.2 User Interaction ......................................................... 15-3 15.2.1 DCPL Special Variables ........................................ 15-3 15.2.2 Setting the Filter ................................................. 15-4 15.2.3 Removing the Filter ............................................. 15-4 15.2.4 Reading the Frame Length Counters ...................... 15-4 15.3 User Scripts .............................................................. 15-5 15.3.1 Examples ........................................................... 15-5 15.3.2 Example 1 ......................................................... 15-5 15.3.3 Example 2 ......................................................... 15-6 15.3.4 Complete Example .............................................. 15-6 15.4 Filter Mode Settings .................................................... 15-8 15.4.1 DCPL Special Variables ........................................ 15-8 15.4.2 Example 3 ......................................................... 15-9 15.5 Restrictions ............................................................. 15-10 Chapter 16. Statistics Package 16.1 Introduction .............................................................. 16-2 16.2 Tabular Data Terminology ........................................... 16-2 16.3 DCPL Script Commands .............................................. 16-2 16.3.1 add_stat_row ..................................................... 16-2 16.3.2 delete_stat_row .................................................. 16-3 16.3.3 stat_field ........................................................... 16-3 16.3.4 stat_group ......................................................... 16-3 16.3.5 stat_log ............................................................. 16-3 16.3.6 stat_pref ........................................................... 16-4 16.3.7 update_stat_field ................................................ 16-4 16.3.8 update_stat_row ................................................ 16-4
Ixia
Table of Contents
16.3.9 Script Example ................................................... 16-5 16.4 DCPL Interactive and Script Commands ........................ 16-6 16.4.1 stats_on ............................................................ 16-6 16.4.2 stats_off ............................................................ 16-6 16.4.3 Run-time Display Control ..................................... 16-6 16.5 Run-time Logging ...................................................... 16-7 16.5.1 Specifying Log File .............................................. 16-7 16.5.2 Specifying Preferences File ................................... 16-7 16.6 Run-time Graphs ....................................................... 16-8 16.6.1 Graph Terminology ............................................. 16-8 16.6.2 Defining Legends ................................................ 16-8 16.6.3 Defining Graphs ................................................. 16-8 16.6.4 Displaying Graphs ............................................... 16-9 Appendix A. mvpivci.dh File A.1 mvpivci.dh File ..............................................................A-2 Index
xi
Table of Contents
Ixia
List of Figures
Figure 2-1. sysconfig Main Window ........................................... 2-2 Figure 2-2. PPCI E1/T1 Board - Passthrough Data Port Configuration Options ............................................................................. 2-8 Figure 2-3. PPCI E1/T1 Board - Monitor Mode Data Port Configuration Options ............................................................................. 2-8 Figure 2-4. BRI Passthrough .................................................. 2-21 Figure 2-5. BRI S/T Board - Passthrough Data Port Configuration Options ........................................................................... 2-22 Figure 2-6. Slot-Independent sysconfig Dialog .......................... 2-58 Figure 2-7. Slot-Independent sysconfig Dialog with Board Positions .... 2-59 Figure 3-1. IxCatapult Launcher Window ................................... 3-3 Figure 7-1. TTY Device Configuration - Physical SPARC Ports ........ 7-2 Figure 7-2. TTY Device Configuration - UDP Sockets .................... 7-5 Figure 7-3. TTY Device Configuration - TCP Sockets .................... 7-6 Figure 7-4. TTY Device Configuration - RAW IP Sockets ............... 7-7 Figure 14-1. Launcher for Multiplexer Script ............................. 14-4
xii
1
Overview
Contents 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.3 Revision History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Overview
Ixia
1.1
Overview
The Ixia Digital Communications Test System (IxCatapult) handles multiple links, running different protocols simultaneously, and provides a complete, independent test solution. It can also be integrated into an existing test environment. The IxCatapult system consists of both software and hardware elements.
1.1.1
Software The Ixia Digital Communications Programming Language (DCPL) is a high-level language designed specifically to facilitate sending, receiving, and analyzing protocol messages. The IxCatapult software is built upon an industry-standard UNIX operating system, consisting of protocol encoders and decoders, protocol state machines, protocol validation tests, and conformance test suites. With software products that include over 100 protocols and variants, the IxCatapult system can be configured for virtually any test application in the project life cycle.
1.1.2
Hardware The modular IxCatapult hardware architecture simplifies configuration for numerous applications, such as signalling and voice channel testing. A wide variety of physical interface options and high-performance Coprocessor boards are combined with a Linux workstation to run high-performance applications. This manual describes the configuration details for the hardware but not installation instructions or hardware specifications. See the p-Series Hardware Reference Manual [1] for PowerPCI-based boards, and the m500 Hardware Reference Manual [2] for m500-based boards.
1-2
Ixia
Overview
1.2
References
[1] [2] [3] [4] [5] [6] [7] [8] [9] p-Series Hardware Reference Manual m500 Hardware Reference Manual IxCatapult LTE UE Simulation API Manual Configuration Editor User Manual DCT-8600 Primary Rate Circuit Tone Generator/Detector User Manual CATTgen User Manual StatsView User Manual MTP2 State Machine Manual SCTP State Machine Manual
[10] TCP/UDP State Machine Manual [11] UDP State Machine Manual [12] AAL1PRIM Protocol Manual [13] AAL2 Protocol Manual [14] BCHAN Protocol Manual [15] MTP3 Protocol Manual
1-3
Overview
Ixia
1.3
Revision History
The information in the following table describes the changes in this manual for each release.
Release 10.6 Revision Description In mPI(OC3) Configuration Window section, reworded field descriptions for AAL2 CPS Packing Expiration Time-Out and AAL2/AAL5 Reassembly Expiration Time-Out fields. In mPI(Ethernet) Configuration Window section, reworded Auto Sense field description and added note that half-duplex mode is currently not supported. In Data Manipulation Statements section, modified description of locate statement. In String Functions section, added descriptions of wspaddlen and wspintval functions. 11.1 A new feature is added that allows you to select the variant of the carrier protocol if the variant of the protocol is of -Va,b type. The Configuring Connections section is updated to describe this feature. A new value, op=10 is added to the multicrc function. The Functions section is updated. ATM is supported on the J1/E1/T1 board. The PPCI (J1/E1/T1) Configuration Window section is updated to include ATM support. The -z parameter is added to the dctprint program. The dctprint section is updated with the parameter description. 11.2 The QoS Client and WAV Converter options are added to the Tools menu in the Launcher. The Interfacing with Support Tools section is updated to include these options. 6865 ER or PR Number 15555
15896
16529 13306
13226
16610
1-4
Ixia
Overview
Release 11.3
Revision Description The IxCatapult Launcher now supports importing and exporting port information files for a context. The IxCatapult Launcher section is updated to describe this feature. The IxCatapult system now supports the SA-9205 (mCU(5)) multi-processor computing board. Chapter 2, Configuring an IxCatapult Session, Chapter 3, Running an IxCatapult Session, and Chapter 12, Intermodule Timing are updated with information on this board type. ASCII display support has been added to the ddriver, Launcher, and dctprint applications. Chapter 3, Running an IxCatapult Session and Chapter 4, Creating and Decoding Log Files are updated to describe this feature.
ER or PR Number 7624
13885
16809
12.0
Moved descriptions of board-specific special variables from userman into Section 8.8, Special and Predefined Variables, on page 8-84. Updated Section 13.2, Limits, on page 13-2 to include information on number of VPIs/VCIs for mPI(OC3) board. There is a 16384-byte limit for DCPL string variables, messages between contexts, and messages on host socket ports. Added Section 3.3.7.4, Message Size, on page 3-36, Section 3.3.7.5, Display Truncation, on page 3-36, and Section 8.12, Limitations, on page 8-110. Modified Section 4.1.2, Environment Variables, on page 4-3, Section 8.1.2, Context Names and Port Expressions on Statements, on page 8-2, and Section 8.1.9, Line Length, on page 8-4. Updated Chapter 12, Intermodule Timing to describe m500 intermodule timing configuration with mCI/mCU and mPI boards. In Section 2.16, mPI(Ethernet) Configuration Window, on page 2-42, removed restriction stating that IPv6 is not supported on mPI board.
11908
15388
15409
16264
17953
12.1
Added Section 8.8.11, mPI(STM) Special Variables, on page 8-99. Added Section 2.18, mPI(STM) Configuration Window, on page 2-51.
18119 18132 17379
12.2
Added Section 8.5.5, Cryptographic Functions, on page 8-57.
1-5
Overview
Ixia
Release 12.3
Revision Description Added Section 2.16.1, VLAN Configuration, on page 2-45 and Section 8.8.12, VLAN Special Variables, on page 8-102. Added description of operation=4 to addgenericlen function description. Added Section 8.8.13, mPI(GigE) Special Variables for IP Port Forwarding, on page 8-103. Added base64_encode and base64_decode function descriptions. Added chkbs function description.
12.4
13839 17022
18171 18677 12896 19147
12.5 13.0
Added Section 2.14, PPCI (GigE) Configuration Window, on page 2-34. Added default portspec description to Section 8.4.6, Compiler/Interpreter Statements, on page 8-31. Added align description to Section 8.5.2, String Functions, on page 8-37. Added Section 2.16.2, Restrictions and Limitations, on page 2-46 describing mPI(Ethernet) board restrictions and limitations. Added default main description to Section 8.4.6, Compiler/Interpreter Statements, on page 8-31. Added Section 3.3.7.6, Display Congestion, on page 3-36. Added warning note about sysmon Stack option to Section 3.3.8.2, Running in Standard Input and Output Mode, on page 3-38.
13.1 13.2
19506 19782
19798
19923 19940
13.3
Updated Section 2.2.1, Host Menu, on page 2-3 with new sysconfig main window screenshot and explanation of Mesh Speed field. Updated the following sections due to discontinued Solaris support: Section 1.1.2, Hardware, on page 1-2 Section 2.2.1, Host Menu, on page 2-3 Section 3.2.4.1, Creating Connections, on page 3-8 Section 3.3.7.3, Download Contexts, on page 3-35 Updated description of wait statement to describe use with interval timers.
19060
19720
19847
1-6
Ixia
Overview
Release 13.3 (cont.)
Revision Description Updated descriptions of &vlan_tag_egress and %vlan_tag_ingress variables in Section 8.8.12, VLAN Special Variables, on page 8-102. Added descriptions of -Y ddc command-line parameters to Section 5.1.1, Command-Line Parameters, on page 5-2
20029
13.4
Updated Section 3.2.4.1, Creating Connections, on page 3-8 and Section 3.3.7.1, Memory, on page 3-34 for cBC+ m500 base board. Added Section 4.2, out2csv, on page 4-4. In sprint statement description in Section 8.4.4, Input/Output Statements, on page 8-18, added information about truncation when outputting to display and dctprint. Moved md5digest, milenage_3g_alg, security_3g_f8, and security_3g_f9 function descriptions from Section 8.5.2, String Functions, on page 8-37 to Section 8.5.5, Cryptographic Functions, on page 8-57. In Section 3.2.4.2, Configuring Connections, on page 3-10 and Section 3.2.20, Viewing Manuals, on page 3-20, removed statements about acroread being used as the default PDF viewer.
13590
15500 17733
20357
20388
13.5
In Section 8.5.2, String Functions, on page 8-37, added information and example to multibcd function description for op=7. Also added information and example to pad function description for optional fill parameter. Removed Chapter 17, Using BERT Functionality. Chapter content has been moved to the BERT User Manual. Added maximum Peak Cell Rate information to Section 13.8.5, mPI(OC3) Board, on page 13-12.
20043
20113
14.0
Added Section 8.8.13.3, IP Port Forwarding Restrictions and Limitations, on page 8-105. Updated Chapter 2, Configuring an IxCatapult Session, Chapter 3, Running an IxCatapult Session, and Chapter 12, Intermodule Timing to reference new SA-9215 mCU5E and SA-9310 mPIE boards.
20502
14.1
19060
1-7
Overview
Ixia
Revision Description Added -R parameter description to Section 3.3, ddriver, on page 3-25. Added -l parameter description to Section 4.1, dctprint, on page 4-2. Added gwrite timestamp and write timestamp statement descriptions to Section 8.4.4, Input/Output Statements, on page 8-18. Updated Section 3.2.19, Interfacing with Support Tools, on page 3-19 to refer to Tools>Video Sample Converter option. Added decode_base64 and encode_base64 function descriptions to Section 8.5.2, String Functions, on page 8-37. Updated mPI(Ethernet) window Section 2.16.1, VLAN Configuration, on page 2-45 and Section 2.16.2, Restrictions and Limitations, on page 2-46. Updated PPCI J1/E1/T1 window Section 2.8.1, Board-Level Configuration, on page 2-13 and Section 2.8.3, Port-Level Configuration, on page 2-16. Added des_encrypt and des_decrypt function descriptions to Section 8.5.5, Cryptographic Functions, on page 8-57. Expanded descriptions of channel_num and timeslot parameters in Section 8.8.11.1, Macros, on page 8-99.
14.2
20299
20748
20828
20951
20959
21250
14.3
Modified sprint statement description in Section 8.4.4, Input/Output Statements, on page 8-18. Added digital_hmac function description to Section 8.5.5, Cryptographic Functions, on page 8-57.
20904
21367
Updated Section 2.2.1, Host Menu, on page 21402 2-3 to refer to 3-slot instead of 4-slot p200. 14.5 Updated Section 12.5, Choosing a Domain Master and Clock Source, on page 12-4 with new examples. Added aes_cmac, aes_decrypt, and aes_encrypt function descriptions to Section 8.5.5, Cryptographic Functions, on page 8-57. Updated &pattern_input_length{port} description under Section 8.8.2.2, BCHAN Special Variables, on page 8-88. 21696
15.0
19661 20915 21630 21824
15.1
1-8
Ixia
Overview
Release 15.2 15.3
Revision Description Updated Chapter 7, TTY Protocol. Added description of op=11 to multicrc function description under Section 8.5.2, String Functions, on page 8-37. Updated wspintval function description under Section 8.5.2, String Functions, on page 8-37. Added cBC memory information to Section 3.3.7.1, Memory, on page 3-34. Corrected IP/Mask description in Section 2.16.1, VLAN Configuration, on page 2-45.
ER or PR Number 21993 18206
22210
22243 22350
15.5
Updated Section 2.2.1, Host Menu, on page 2-3 to reference new p250 hardware platform. Updated Section 3.2.4.2, Configuring Connections, on page 3-10 and Section 3.2.20, Viewing Manuals, on page 3-20 to explain how to override default KPDF document viewer using DCT2000DOC_READER environment variable. In Section 8.4.5, Interval Timer Statements, on page 8-28, added note under start_itimer subsection about starting itimers with a null period or duration.
22080
16.0
22825
22956
16.1
Added security_3g_eea and security_3g_snow function descriptions to Section 8.5.5, Cryptographic Functions, on page 8-57. Added Launcher -cc and -cf parameter descriptions to Section 3.2.22, Command-Line Parameters, on page 3-21. Added note to load statement description under Section 8.4.4, Input/Output Statements, on page 8-18, about amount of time required to load a script to a Coprocessor context as compared to a workstation context.
21941
22993
23111
16.2
Updated Ethernet MTU field description in Section 2.16, mPI(Ethernet) Configuration Window, on page 2-42 to state range of valid values (64 to 9714 bytes).
18207
1-9
Overview
Ixia
Release 16.4
Revision Description Updated Section 3.3.7.3, Download Contexts, on page 3-35 with information on maximum number of download contexts per Coprocessor CPU and in a single Launcher session. Changed maximum number of ports per context from 64 to 256. In Section 8.4.4, Input/Output Statements, on page 8-18, updated add display, remove display, add log, and remove log statement descriptions to describe limiting protocol display/logging. Added Section 3.2.9, Sector Configuration File, on page 3-16. Added -x file.sectorCfg command-line parameter to Section 3.3, ddriver, on page 3-25. Added security_3g_eia function description to Section 8.5.5, Cryptographic Functions, on page 8-57. Added Dsecurity3geea and Dsecurity3geia function descriptions to Section 9.6.9, Miscellaneous Functions, on page 9-14. In Section 8.4.4, Input/Output Statements, on page 8-18, added note about memory leaks to load statement description, and added load noglobals and unload noglobals statement descriptions. In Section 8.9, DCPL Keywords, on page 8-107, added noglobals keyword. In Section 9.6.4, Interprocess Functions, on page 9-9, added Dload_noglobals and Dunload_noglobals function descriptions.
22568
22688
22867
23159
16.5
Added VLAN parameter description to Section 2.14.1, Configuring the Board in Emulation Mode, on page 2-34. Added Section 2.14.2, VLAN Configuration, on page 2-36. Modified &MY_VID variable description in Section 8.8.12, VLAN Special Variables, on page 8-102. Modified Section 2.14, PPCI (GigE) Configuration Window, on page 2-34 to document GigE_2 (SA-9018) board configuration. Modified security_3g_eea and security_3g_eia function descriptions in Section 8.5.5, Cryptographic Functions, on page 8-57, to add information on supported algorithms.
20703
17.0
20734
21961
1-10
Ixia
Overview
Revision Description Updated maximum string length information in the following sections: sprint statement description in Section 8.4.4, Input/Output Statements, on page 8-18 base64_encode and base64_decode function descriptions in Section 8.5.2, String Functions, on page 8-37 Section 8.12, Limitations, on page 8-110 Updated Section 2.13.3, General Limitations, on page 2-33 and Section 2.14.3, General Limitations, on page 2-37 with information on jumbo frame support on PPCI(Ethernet) and PPCI(GigE) boards.
24546
17.1
Updated Section 3.2.22, Command-Line Parameters, on page 3-21 to add missing Launcher command-line parameters. Added Section 12.8, Clock Configuration and t600, on page 12-9. Rebranded DCT2000 as IxCatapult. In Section 9.6.10, Coprocessor UNIX Library Functions, on page 9-16, changed references to man -s2 <function> and man -s3c <function> to man <function>.
22993
17.3 17.5
25062 25307 26038
18.3
Added Section 10.3, hminfo, on page 10-3. 26613
1-11
Overview
Ixia
1-12
2
Configuring an IxCatapult Session
Contents 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2 sysconfig Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3 User Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4 Command-Line Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.5 System Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6 PPCI (E1/T1) Configuration Windows . . . . . . . . . . . . . . . . . . 27 2.7 PPCI (E1_ATM/T1_ATM) Configuration Windows. . . . . . . . . . 212 2.8 PPCI (J1/E1/T1) Configuration Window . . . . . . . . . . . . . . . . 213 2.9 PPCI (Serial) Configuration Window . . . . . . . . . . . . . . . . . . 219 2.10 PPCI (BRI S/T) Configuration Window . . . . . . . . . . . . . . . . 220 2.11 PPCI (CII) Configuration Window . . . . . . . . . . . . . . . . . . . 224 2.12 PPCI (OC3E) Configuration Window . . . . . . . . . . . . . . . . . 225 2.13 PPCI (Ethernet) Configuration Window . . . . . . . . . . . . . . . 230 2.14 PPCI (GigE) Configuration Window . . . . . . . . . . . . . . . . . . 234 2.15 mCI(ATM) Configuration Window . . . . . . . . . . . . . . . . . . . 239 2.16 mPI(Ethernet) Configuration Window . . . . . . . . . . . . . . . . 242 2.17 mPI(OC3) Configuration Window . . . . . . . . . . . . . . . . . . . 247 2.18 mPI(STM) Configuration Window . . . . . . . . . . . . . . . . . . . 251 2.19 mCU(5)/mCU5E Configuration Window . . . . . . . . . . . . . . . 253 2.20 UNIX Device Configuration Window . . . . . . . . . . . . . . . . . 253 2.21 Slot-Independent Naming . . . . . . . . . . . . . . . . . . . . . . . . 256 2.22 Environment Variable Slot Definitions . . . . . . . . . . . . . . . . 258
Ixia
2.1
Introduction
The sysconfig program is used to specify the hardware configuration of the external interface equipment.
2.2
sysconfig Main Window

The sysconfig main window (Figure 2-1) is labeled IxCatapult System Configuration Utility. This window allows you to select the PowerPCI (PPCI) boards installed in workstation PCI slots and to configure UNIX TTY devices such as socket ports or serial ports. This window also allows you to configure boards present on an m500 shelf carrying a single-board computer (SBC). Figure 2-1. sysconfig Main Window
2-2
Ixia
Three general classes of items can be configured. See sections 2.6 through 2.20 for more detail on configuring specific board types. Coprocessor boards - Each Coprocessor board generally has four data ports and an integrated physical interface (E1, T1, E1_ATM, T1_ATM, J1/E1/T1, Serial, BRI S/T, CII, OC3E, Ethernet, Gigabit Ethernet, mCI(ATM), mPI(Ethernet), mPI(OC3) or mPI(STM)). In general, the process of configuring a Coprocessor board consists of configuring the parameters of the physical interface, connecting physical ports to the four data ports, and configuring the data ports. In the case of pure Coprocessor boards that do not have a physical interface, such as mCU(5), there is no configuration required. UNIX devices - Using the TTY protocol, test sessions can address UNIX devices. These can either be standard TTY ports, UNIX TCP sockets, or UNIX UDP sockets. Coprocessor boards on m500 shelf - Any of the 18 Coprocessor boards residing on an m500 shelf carrying an SBC (not extended from a workstation) can be configured.
2.2.1
Host Menu The default Host value is Workstation, a generic designator for a 3-slot system. The Host value should be set to m500 only if the Coprocessor boards are resident on an m500 shelf carrying an SBC. For all other systems, set the Host value to p100, p200, p250, p300, or p400 as appropriate. NOTE: The 4-slot p200 has been discontinued and replaced with a 4-slot p250. When an m500 host is selected, the current backplane mesh speed is displayed to the right of the Host menu (see Figure 2-1).
2.2.2
Auto Config Clicking the Auto Config button in the main window causes sysconfig to determine the host type and the contents of each chassis automatically, and to update the in-memory configuration data to match the hardware. Auto Config is most useful for populating a new, empty configuration. The configuration of each board must still be completed manually. The Auto Config button is disabled if using the -o command-line parameter to allow optional naming of the definitions.
2-3
Ixia
2.2.3
Navigation The sysconfig program is organized as a hierarchy of windows for configuring various parts of the IxCatapult system. Users are guided through a series of menus and windows, each of which presents input options of two types: commands that cause the program to move to an area of the system to be configured selections that cause data to be entered or modified
Most menus and actions are activated or selected by clicking the left mouse button. Buttons labeled Configure lead to more detailed configuration windows for a particular entity. In most cases, users can make changes on any window being displayed by moving the cursor to the desired point. However, when an error, question, or warning dialog is displayed, it must be handled before moving to other windows. Normally, a drop-down menu (often indicated by v) is closed automatically after a selection is made. Double-clicking the menu button causes the menu to remain displayed for additional selections. Clicking the middle mouse button causes the menu to be torn off so that it can be moved to a convenient place on the screen. Clicking on the menu button again retrieves a torn-off menu. 2.2.4 File Menu When sysconfig is started, the system configuration file is automatically read into memory and used to initialize the various sysconfig windows. All changes made by sysconfig apply only to the copy of the database in memory until saved back to the file. This is done by exiting sysconfig using the OK button on the main workstation configuration window, or by selecting File>Save or File>Save As. Click the Cancel button in the main window to exit sysconfig without saving. Select File>Load, or click the Restart button on the workstation configuration window, to cause sysconfig to discard all changes to the memory-resident configuration data and restart by loading the system configuration file. Select File>New to cause the memory-resident configuration data to be reinitialized with a minimal configuration default. Icons below the menu options allow easy access to the File>Load, File>New, and File>Save options.
2-4
Ixia
2.2.5
Edit Menu The Edit menu has a Copy and Paste feature. This feature is used by selecting the position that you want to copy by clicking the left mouse button in the slot definition box on the right-hand side. The selected position will have a dark blue outline around the box. Select Edit>Copy. Next, select the slot where the copy should go and select Edit>Paste. The new slot will contain a copy of the same information as the previously selected slot position. The Copy command stores information about the selected item. The Copy command can copy Coprocessor board information. The Paste command inserts the stored information into the currently selected position. Any selected text or objects are replaced by the inserted contents. Icons below the menu options allow easy access to the Copy and Paste functions.
2.2.6
Action Buttons In all windows, click OK to save any changes and close the window. Click Cancel to close the window without saving changes. Some windows have an Apply button which saves changes without closing the window. This may be useful in situations in which changes saved on one window affect other windows. Some windows offer an Undo All button, which restores the window to the state it was in when opened or last saved. NOTE: Changes that can be undone are not visible to other windows until saved, at which point they can no longer be undone. The Apply and Undo All buttons refer to the memory-resident copy of the system configuration. The system configuration file, ${DCT2000PATH}/.sysconfig, is changed only by the OK or File>Save selections on the main workstation configuration window. Some windows have a Defaults button, which sets configuration parameters in that window to default values.
2-5
Ixia
In text entry boxes the cursor changes from an arrow to an insertion mark. If the box is enabled in the current context, clicking the left mouse button causes an insertion cursor to appear at that point. Pressing Ctrl-H or the Delete key deletes the character just before the insertion cursor. The entire entry can be deleted by pressing Ctrl-U. Pressing the Return key causes the entry to be checked for correctness. Any errors result in a dialog explaining the problem. Text entry boxes requiring a hexadecimal octet or octet string are labeled with the DCPL type characters # and $, respectively. All other numbers are entered as non-negative decimal integers.
2.3
User Security
There are two ways to use sysconfig, determined during installation of the IxCatapult software: superuser - restricted use of sysconfig general use by anyone
If sysconfig was installed for use by the superuser, any user can run the program to view the configuration, but cannot save changes to the file. This is referred to as read-only mode.
2.4
Command-Line Parameters
sysconfig accepts the following command-line parameters: -c Start sysconfig using the specified system configuration file. See Section 2.5, System Configuration File, on page 2-7 for more details. Start sysconfig with optional named configuration definitions. See Section 2.21, Slot-Independent Naming, on page 2-56 for more details. Show environment specifications for named slot definitions. See Section 2.22, Environment Variable Slot Definitions, on page 2-58 for more details. Automatically determine the contents of each chassis, update the in-memory configuration data to match the hardware, and exit. No display is generated.
-o
-e
-a
2-6
Ixia
2.5
System Configuration File

The sysconfig program edits the IxCatapult system configuration file. If the -c command-line parameter is used, the system uses the specified system configuration file. Otherwise, the default file ${DCT2000PATH}/.sysconfig is used. File names that are not complete path names, that is, do not begin with a /, are interpreted as being in the current directory.
2.6
PPCI (E1/T1) Configuration Windows

The PPCI E1/T1 mezzanine board supports either E1 or T1 links, selectable by software. Each board has two E1/T1 ports and one codec port. One E1/T1 port is designated link 0 and the other link 1. The codec port can be connected under software control to any timeslot on either link. Depending on the operating mode, you can drop and insert and/or drop selected timeslots on a particular link to each of the four test data ports.
2.6.1
Operating Modes The E1/T1 board supports the following operating modes: In emulation mode, link 0 and link 1 operate independently. In this mode, you can use a link to control a DCT-8600 (VOX) board, in which case the link is dedicated to this purpose; that is, no timeslots can be used by any other port. Selecting a link to control a DCT-8600 places some limitations on the E1/T1 board configuration. See Section 2.6.5, T1-Specific Options, on page 2-10 and Section 2.6.6, E1-Specific Options, on page 2-10 for further details. All traffic timeslots in the transmit direction carry idle code (#7f or #ff on T1 links, #55 on E1 links), except those selected for drop and insert to the four data ports. For timeslots with some bit positions selected (a 16 kb/s channel, for example) for drop and/or insert, the unselected bit positions within the timeslot will carry an unframed stream of 1s. NOTE: No two ports can drop and insert the same channels on the same link. In passthrough mode, each data port can either drop and insert timeslots on a selected link or simply monitor the received data on a link. The data in all other timeslots is passed transparently from one link to the other. In a drop and insert configuration, the
2-7
Ixia
inserted data replaces the passthrough data on the affected timeslots. Figure 2-2 illustrates the four possible data port configurations. Figure 2-2. PPCI E1/T1 Board - Passthrough Data Port Configuration Options
Insert Link 0 Insert Link 1 Drop Rx Link 1
Drop Rx Link 0
Rx
Tx
Rx
Tx
Link 0
Link 1
In monitor mode, you can choose between drop Rx and drop Tx to monitor traffic on the corresponding simplex of the link being monitored, which must be physically connected to link 0. Data ports configured for Drop Rx monitor data received on pins 1 and 2 of the link 0 connector; Drop Tx (a misnomer in this application) monitors data received on pins 4 and 5 of the link 0 connector. Figure 2-3 illustrates this. Figure 2-3. PPCI E1/T1 Board - Monitor Mode Data Port Configuration Options
Link 0 RJ-48 Pins Rx 1,2 Tx 4,5
Monitored Link
The monitor mode termination impedance depends on the termination type: Bridged (E1 and T1): 1000 ohm Terminated (T1): 100 ohm Terminated (E1) 120 ohm Terminated (E1 with Coaxial option): 75 ohm
2-8
Ixia
2.6.2
Transmit Clock The E1/T1 board can run link transmit clocks in slave mode or master mode. Both links must use the same transmit clocking mode. In master transmit clocking mode, the transmit clock is internally generated, based on a signal produced from the base board clock. When the board is put in slave transmit clocking mode, it derives its transmit clock on each link from the receive clock on that link. If no signal is present on the link, it reverts to its own master clock. When the board is in passthrough mode, the transmit clock of each link is generated from the receive clock on the other link. If links 0 and 1 are connected to each other (for example, during DCPL script application development and testing), select master transmit clocking mode. Since both links are driven by the same clock, there will be no frame slips.
2.6.3
Channel Selection sysconfig provides five options for selecting channels to drop and/or insert into the four test data ports: 64k bits/sec - This option lets you select any number of 64 kb/s timeslots to route to a test data port. 56k bits/sec - This option permits the selection of 56 kb/s timeslots. You are guaranteed a minimum total of ten 56 kb/s timeslots for all four test data ports. 64k switchable and 56k switchable - These two options provide for switchable timeslots for 64 kb/s and 56 kb/s. In this mode, you can switch which timeslot is routed to a test data port dynamically. When a switchable option is selected, you can select at most one timeslot for a given port. When a ddriver session is initiated, the selected timeslot will be routed to the port. You can change the routed timeslot by using the timeslot to command. If a port is not configured with either 64 kb/s switchable or 56 kb/s switchable, dynamic timeslot switching is prohibited. other - With this option, you can select combinations of 64 kb/s, 56 kb/s, 32 kb/s, 16 kb/s, and 8 kb/s channels to be routed to the test ports. You are guaranteed a minimum total of 10 of these channels for the four test data ports.
In cases with a limitation on the number of channels that can be selected, sysconfig informs you if you try to connect too many channels.
2-9
Ixia
NOTE: The limitation depends on the way in which channels are chosen as well as on the number chosen. 2.6.4 Data Inversion Transmit and receive data can be 0/1 inverted if desired. This method is sometimes used, for example, on HDLC timeslots to meet 1s density requirements on D4-framed T1 links. 2.6.5 T1-Specific Options T1-specific options allow you to: use D4 or ESF framing use AMI or B8ZS line coding enable robbed bit signaling enable bit 7 zero suppression select the idle code format select line buildout
When one or both of the T1 links is designated as a DCT-8600 Control port, the T1 parameters above are fixed to match with the default configuration of the DCT-8600. When a link is selected for DCT-8600 Control, sysconfig automatically selects the valid options and disables selection of the other options. 2.6.6 E1-Specific Options E1-specific options allow you to: enable CRC4 select Channel Associated Signaling (CAS) or Common Channel Signaling (CCS)
When one or both of the E1 links are designated as a DCT-8600 Control port, the E1 parameters above are fixed to match with the default configuration of the DCT-8600. When a link is selected for DCT-8600 Control, sysconfig automatically selects the valid options and disables selection of the other options.
2-10
Ixia
2.6.7
Alarms On an E1 configured E1/T1 board, when loss of synchronization or carrier loss is detected, a remote alarm is generated and unframed all ones are sent on timeslot 16 of the same link. Unframed all ones are sent on the other port if in passthrough mode. On a T1 configured E1/T1 board, a yellow alarm is generated according to the AT&T AccunetTM T1.5 Service specification TR 62411. A blue alarm is transmitted on the other port if the board is in passthrough mode.
2.6.8
PCM Coding The codec port supports A-law or Mu-law PCM coding schemes in either E1 or T1 board operation. Generally, T1 links use Mu-law coding and E1 links use A-law coding.
2.6.9
Handset Microphone Codec gain for either a carbon microphone or an electret microphone can be chosen to match the type of handset connected to the codec port.
2.6.10
Codec Modes There are two codec modes: drop and insert and monitor. In drop and insert mode, you can transmit and receive over the handset. In monitor mode, you can only receive over the handset. When the board is configured in passthrough mode, only the drop and insert codec mode is applicable. When the board is in monitor mode, the codec is automatically placed in monitor mode.
2.6.11
Codec Operation The codec port can be controlled using the DCPL commands codec on and codec off. For more information on these commands, see codec on on page 8-19 and codec off on page 8-19. The codec port can also be controlled using the C library functions Dcodec_on and Dcodec_off. For more information on these functions, see Dcodec_on on page 9-15 and Dcodec_off on page 9-15.
2-11
Ixia
2.7
PPCI (E1_ATM/T1_ATM) Configuration Windows

The PPCI E1/T1 mezzanine board can be configured for Asynchronous Transfer Mode (ATM) using the PPCI (E1_ATM/T1_ATM) configuration windows. These configuration windows contain common elements with the PPCI (E1/T1) configuration windows (see Section 2.6, PPCI (E1/T1) Configuration Windows, on page 2-7) as well as some ATM-specific items defined on a per-board or per-port basis. Like the normal E1/T1 configuration, using ATM the board can operate in emulation, passthrough, or monitor modes with various configurable parameters. For each board, a global Cell Header Mask, an Empty Cell Header, and an Empty Cell Payload are defined. For each link, a selection can be made on whether HEC Coset Rules are applied or Cell Scrambling is used. See Section 2.12, PPCI (OC3E) Configuration Window, on page 2-25 for details on these parameters. A port on an E1/T1 ATM mezzanine board represents an ATM VP/VC and can be set up on either link. Up to four ports can be configured per board in any combination, following the same restrictions as normal E1/T1 boards with respect to data mode (Drop and Insert, Drop Rx, and Drop Tx), except that passthrough does not support Drop and Insert mode. For each port, a Protocol, Cell Header, Peak Cell Rate, and certain optional protocol-specific parameters are defined. Default values are provided for each of these fields. The default values of the Cell Header subfields can be viewed in either the NNI or UNI format, as convenient. NOTE: In the monitor mode, the Empty Cell Payload value is not applicable, and the least significant nibble of the 32-bit Cell Header Mask must always be zero. Details of the various protocols and parameters entered on a per-port basis are the same as those described in Section 2.12, PPCI (OC3E) Configuration Window, on page 2-25.
2-12
Ixia
2.8
PPCI (J1/E1/T1) Configuration Window

The PPCI J1/E1/T1 mezzanine board has two flavors: 2-link connector with codec and 4-link connector. Each link supports J1/E1/T1 independently. The configuration is divided into three levels of hierarchy: board level link level port level
2.8.1
Board-Level Configuration The board-level configuration has the following parameters. 2.8.1.1 Links
The J1/E1/T1 board has two types of granddaughter connector boards: 4 physical links 2 physical links with codec
The Physical Links parameter is used to configure the total number of links on the granddaughter board. 2.8.1.2 Modes
The J1/E1/T1 board supports the following modes: In emulation mode, all the links operate independently. No two ports can Drop and Insert the same channel(s) on the same link. In passthrough mode: For the 4-link connector board, links 0-1 and 2-3 form pairs. For the 2-link connector board, links 0-1 form pairs. Each data port can either Drop and Insert timeslots on a selected link or simply monitor the received data on a link. The data in all other timeslots is passed transparently from one link to the other link in the pair. In a Drop and Insert configuration, the inserted data replaces the passthrough data on the affected timeslot(s). In monitor mode, two links can be monitored independently. You can choose between Drop Rx and Drop Tx to monitor traffic on the corresponding simplex of the link being monitored.
2-13
Ixia
The links options are different for the 4-link and 2-link connector boards: For the 4-link connector board, the monitored links should be physically connected to links 1 and 2. For the 2-link connector board, the monitored links can be connected to links 0 and 1. Data ports configured for Drop Rx monitor data received on pins 1 and 2 of the monitored link connector. Data ports configured for Drop Tx monitor data received on pins 4 and 5 of the link connector. In monitor mode it is possible to specify the type of monitoring termination: Bridged for short connection or Terminated for long wires. In dynamic monitor mode, 2 links can be monitored independently, but you can choose only Drop and Insert because the cable direction should be selected by link choice between all 4 links in the DCPL script (see Chapter 14, Dynamic TDM Channels), even for a 2-link board. Links 0 and 1 can service a first cable, and links 2 and 3 can service a second cable. It is also possible to create a pseudo-dynamic configuration for the Ixia MTP2 state machine. See Section 2.8.3.1, TDM Port Configuration, on page 2-16. 2.8.1.3 Operating Modes
The PPCI J1/E1/T1 board supports the following operating modes: TDM operating mode can be configured as either Static or Dynamic. With static TDM, the J1/E1/T1 board works with statically defined channels, usually one channel per board port. At the port level you can select a link and a specific timeslot or timeslots for a channel to send and receive data on the port. Dynamic TDM on the J1/E1/T1 board allows TDM channels to be allocated dynamically in DCPL. Many TDM channels can be allocated on a single port. See Chapter 14, Dynamic TDM Channels for details. ATM operating mode can be configured as either Single or Multiple. This mode refers to the number of VPI/VCIs that can be configured on a board port. While Single mode is a simpler mode of operation, allowing you to configure a single VPI/VCI and its ATM operating parameters on a single board port, Multiple mode is dynamic and allows for a far greater number of VPI/VCIs to be
2-14
Ixia
configured. See Chapter 13, Multiple VPI/VCI for details on how to use this feature. 2.8.2 Link-Level Configuration On the link level, you can configure each link separately. The configurable parameters are as follows: Physical Interface (J1, E1, or T1) Transmit Clock (Master or Slave for each link) T1- and J1-Specific Link Options
2.8.2.1
T1- and J1-specific options allow you to do the following: use D4 or ESF framing (enable CRC6) use AMI or B8ZS line coding enable robbed bit signaling enable bit 7 zero suppression select line buildout E1-Specific Link Options
2.8.2.2
E1-specific options allow you to do the following: enable CRC use Channel Associated Signaling (CAS) or Common Channel Signaling (CCS) ATM-Specific Link Options
2.8.2.3
In addition to the J1-, T1-, or E1-specific options, in ATM operating mode the ATM-specific link options allow you to do the following: enable link coset rules enable link scrambling select the timeslots that the ATM cell stream will occupy (for partial or full link operation) set the maximum aggregate cell rate for the ATM cell stream
2-15
Ixia
2.8.3
Port-Level Configuration You can configure four ports over any of the two or four links available. Port configuration is different depending on the selected operating mode (TDM or ATM). 2.8.3.1 TDM Port Configuration
Ports are configured differently based on the TDM operating mode (static or dynamic): In the static TDM mode, you can choose bits in any timeslot to be a part of the channel. Depending on the mode, you can drop and insert and/or drop a selected timeslot or timeslots on a particular link to each of the four board ports. Click Select to display the Timeslot Selection window for defining the timeslot allocation in the link. The dynamic TDM mode does not allocate a specific timeslot or link for any port but leaves this choice for contexts, which should be programmed to use it (see Chapter 14, Dynamic TDM Channels). However, you can configure the SS7 channels timeslots and the link configuration. This configuration is used only by the Ixia SS7 MTP2 state machine and is ignored in other cases. To display the SS7 Channels window, select SS7, then click SS7 Channels. The SS7 Channels window lets you define a variable number of channels for the SS7 MTP2 state machine and select a link and timeslot or timeslots for each channel. Click Add to add another channel or click Remove to remove an existing channel. The choice of links 0 and 1 services Tx and Rx directions of the first connected cable. The choice of links 2 and 3 services Rx and Tx directions of the second connected cable. You can configure up to 63 SS7 channels on one board port and 128 SS7 channels on one PPCI J1/E1/T1 board as long as an available timeslot exists. If necessary, you can configure the channels on different links on the same board. See the MTP2 State Machine Manual [8] for more details. The Timeslot Selection windows provide five choices for each timeslot: 64 kb/s - 1 choice in a timeslot 56 kb/s - 1 choice in a timeslot 32 kb/s - 2 choices in a single timeslot 16 kb/s - 4 choices in a single timeslot 8 kb/s - 8 choices in a single timeslot
2-16
Ixia
You can make a maximum of 32 choices over a single channel. sysconfig checks the timeslot overlapping by different channels and restricts some bandwidth choices if the timeslot is already used by another channel. In dynamic TDM operating mode, a maximum of 256 HDLC or transparent channels are supported on one J1/E1/T1 PPCI board (as long as an available timeslot exists). If all timeslots are used, it is not possible to open more channels. Each system has its own maximum number of channels, depending on the timeslot selections for each channel and whether a 4-link or 2-link connector is used. 2.8.3.2 ATM Port Configuration
Ports are configured differently based on the ATM operating mode (single VPI/VCI or multiple VPI/VCI). In single VPI/VCI ATM operating mode, each port can be configured with a particular mode (Drop and Insert, Drop Rx, Drop Tx, or Unused). For each mode, the physical link, ATM Network Type, Cell Header (VPI/VCI), Protocol, and associated parameters with each VPI/VCI can be configured. Each port uses one of the following five protocols: AAL0 - This protocol is used when you want to bypass the AAL layer and send 48-byte payloads. If the payload length is less than 48 bytes, the remaining bytes are padded by 0s. If the payload length is greater than 48 bytes, it is truncated to 48 bytes. Each payload is transmitted by exactly one cell. This protocol has no configurable parameters. AAL1 - This protocol has the following configurable parameters. See the AAL1PRIM Protocol Manual [12] and AAL1 standard for more detailed descriptions of these parameters. Structured Format Block Size Partial Fill Mode Valid Octet Size (applies only to Partial Fill Mode)
2-17
Ixia
AAL2 - This protocol has the following configurable parameters: CPCS Max. Packet Size - The maximum size of the packets that can be received by the AAL2-CPS layer. The default value is 45. Timer CU - The Combined Use timer represents the amount of time a partially filled AAL2 cell waits before transmission. This timer is specified in 5ms steps. The default value of this parameter is 0. Partial Fill Mode Partial Fill Threshold No STF Mode - If this mode is enabled, the cell does not contain the STF byte. In this mode each cell starts with a new packet and contains only whole packets. There are no split or partial packets. This mode is disabled by default.
AAL5 - This protocol has no configurable parameters. IP/AAL5 (according to RFC 2684/2492) - When this protocol is selected, the encapsulation method must be configured as either LLC-based or VC-based. Refer also to the TCP/UDP State Machine Manual [10]. You can select either of two ATM Service Categories/Transfer Capabilities by selecting either CBR (constant bit rate) or UBR (unspecified bit rate) as the value of the Traffic field. CBR channels are high-priority channels. ATM cell transmission is controlled by a pace controller, which currently schedules a maximum of one ATM channel in each timeslot. Depending on the desired bit rate for that channel, it can be scheduled to transmit cells in any number of consequent timeslots. UBR channels are scheduled to transmit by the pace controller only when no other CBR channel is scheduled in that timeslot. If the CBR channel is scheduled in that timeslot, the UBR channel is not scheduled until one of the future timeslots is available. In multiple VPI/VCI ATM operating mode, each port is a logical grouping of all dynamic ATM channels associated with a particular ATM protocol. Each port can be configured with a particular mode (Drop and Insert, Drop Rx, Drop Tx, or Unused), ATM Network Type, Protocol, and the associated global parameters with each logical port. Individual channels in multiple VPI/VCI mode are allocated and deallocated dynamically using DCPL. See Chapter 13, Multiple VPI/VCI for details on how to use this feature.
2-18
Ixia
2.9
PPCI (Serial) Configuration Window

The PPCI Serial mezzanine board can be configured as EIA-449, EIA-232, EIA-530, EIA-530A, or V.35. Each interface type requires cables designed for that particular interface. There are four serial interface ports.
2.9.1
Physical Interface The Physical Interface selected must correspond to the data cable connected to the PPCI Serial board. Select the required interface: EIA-232, EIA-449, EIA-530, EIA-530A, or V.35.
2.9.2
Operating Modes Each of the four data ports can be configured for DTE emulation, DCE emulation, monitoring, or DCT-8600 Control. Further information on the DCT-8600 can be found in the DCT-8600 Primary Rate Circuit Tone Generator/Detector User Manual [5]. In monitor mode, ports must be configured in pairs, sharing a single cable connector. When monitoring, one port in the pair monitors the DCE simplex and the other port monitors the DTE simplex. Only certain combinations are legal, and these are enforced by sysconfig. For example, if data port 1 is selected to monitor a DCE simplex, the window automatically configures data port 2 to monitor the DTE simplex and both ports 1 and 2 are shown to use data cable connector B. If, on the other hand, data port 1 monitors the DTE simplex, data port 2 monitors the DCE simplex and both ports use data connector A. Similarly, data ports 3 and 4 operate together in monitoring.
2.9.3
Clocking In emulation mode, the clock mode can be set for normal or terminal timing. Normally the DCE generates the clocks; however, in terminal timing, the DCE generates the transmit timing and the DTE generates the receive timing.
2.9.4
Data Inversion Optionally, data can be received and transmitted with 0/1 inversion. This option is sometimes required in conjunction with facilities that require a minimum 1's density.
2-19
Ixia
2.9.5
Flow Control When the board is configured for DTE emulation, there is an option to select CTS/CD flow control. When CTS/CD flow control is selected, the data port transmits data only when the CTS (Clear To Send) control signal is high, and receives data only when CD (Carrier Detect) is high. If CTS is lost during frame transmission (in flow control mode) the frame is retransmitted automatically when CTS is reasserted. If CD is lost during frame reception the partially received frame is discarded. The CTS and CD signals can be controlled using the following DCPL special variables: &ctrl_cts{port}, &ctrl_dcd{port}, &ctrl_dsr{port}, &ctrl_rts{port}, and &ctrl_dtr{port}. See Section 8.8.6, Serial Special Variables, on page 8-92 for descriptions of these variables.
2.10
PPCI (BRI S/T) Configuration Window

The ISDN Basic Rate Interface S/T (BRI S/T) mezzanine board supports two links that can be configured independently. The board has four data ports; each can be connected to any channel (B1, B2, or D) of either link. The board contains a codec, which can be connected to either B channel of either link.
2.10.1
Operating Modes The BRI S/T board supports the following operating modes: In emulation mode, link 0 and link 1 operate independently. Either link can be configured as an NT (Network Termination) or a TE (Terminal Equipment). In TE mode, the link can be terminated for normal point-to-point connections or bridged for use in a multidrop configuration. In multidrop, the last TE must be terminated and all others bridged. Note that the link 0 and link 1 connectors are wired in the TE configuration (see the BRI S/T Board Cables section of the p-Series Hardware Reference Manual [1]). This means a crossover cable (supplied) must be used when operating as an NT. When operating as a TE, use a straight-through cable. In passthrough mode, the receive end of link 0/1 is connected to the transmit end of the link 1/0. When passthrough mode is selected, sysconfig shows Passthrough (TE) for link 0 and Passthrough (NT) for link 1. This means that link 0 is configured as a TE and link 1 is configured as an NT. Thus, link 0 should be
2-20
Ixia
connected to an NT and link 1 should be connected to a TE, as shown in Figure 2-4. Figure 2-4. BRI Passthrough
BRI S/T IxCatapult Passthrough
Link 0
Link 1
NT
TE
In monitor mode, the line connected to link 0 is monitored and link 1 is disabled. Both the NT and TE sides of the connection are monitored. In sysconfig, the Monitor NT->TE port option means that the port is monitoring the NT-to-TE traffic. Monitor TE->NT is monitoring the TE-to-NT direction. The monitor mode termination impedance is configurable for either 1000 Ohm bridged or 100 Ohm terminated.
2.10.2
Channel Selection sysconfig allows you to select channels to drop and/or insert into any of the four test data ports. The two B channels (B1 and B2) have a channel rate of 64 kb/s. sysconfig provides the option to select subchannels of the B channels at rates of 32 kb/s, 16 kb/s, and 8 kb/s. In addition, the two B channels can be combined to form one 128 kb/s hyperchannel. The D channel has one rate, 16 kb/s. D channel and B channel data cannot be on the same port, and sysconfig enforces this restriction. No two ports can drop and insert the same channels on the same link.
2.10.3
Switchable Channels sysconfig provides the option for 64 kb/s switchable channels. In this mode, you can switch interactively the B channel that is connected to a given port. A maximum of one 64 kb/s channel (no subchannels) can be allocated to a port. For example, if you initially configured B1 of link 0 to be routed to port A and later wanted to route B2 of link 1 to that port, you should issue the following command, where {1} corresponds to port A:
{1} timeslot to 2 link 1
2-21
Ixia
2.10.4
Data Ports Depending on the operating mode, you can drop and insert and/or drop selected channels on a particular link to each of the four test data ports. 2.10.4.1 Emulation Mode In emulation mode, traffic channels in the transmit direction carry idle code (#ff), except for those selected for drop and insert to the four data ports. 2.10.4.2 Passthrough Mode In passthrough mode, each data port can either drop and insert channels on a selected link or simply monitor (Drop Rx) the received data on a link. The data in the other channels is passed transparently from one link to the other. In drop and insert configuration, the inserted data replaces the passthrough data on the affected channels. Figure 2-5 illustrates the four possible data port configurations: Figure 2-5. BRI S/T Board - Passthrough Data Port Configuration Options
Drop and Drop Rx Link 0 Insert Link 0 Drop and Insert Link 1 Drop Rx Link 1
Rx
Tx
Rx
Tx
Link 0
Link 1
2.10.4.3 Monitor Mode In monitor mode, you can choose between Monitor TE->NT and Monitor TE->NT to monitor traffic on the corresponding simplex of the link being monitored. The link to be monitored must be connected to link 0 of the BRI S/T board. Monitor NT->TE will monitor the NT-to-TE direction. Monitor TE->NT will monitor the TE-to-NT direction.
2-22
Ixia
2.10.5
PCM Coding The codec port supports A-law or Mu-law PCM coding schemes.
2.10.6
Handset Microphone Codec gain for either a carbon microphone or an electret microphone can be chosen to match the type of handset connected to the codec port.
2.10.7
Codec Modes There are two codec modes: drop and insert and monitor. In drop and insert mode, you can transmit and receive over the handset. In monitor mode, you can only receive over the handset. When the board is configured in monitor mode, the codec is automatically placed in monitor mode.
2.10.8
Codec Operation The codec port can be controlled using the DCPL commands codec on and codec off. For more information on these commands, see codec on on page 8-19 and codec off on page 8-19. The codec port can also be controlled using the C library functions Dcodec_on and Dcodec_off. For more information on these functions, see Dcodec_on on page 9-15 and Dcodec_off on page 9-15.
2-23
Ixia
2.11
PPCI (CII) Configuration Window

The PPCI CII mezzanine board supports the Japanese CII physical interface. It has four configurable serial interface ports. The PPCI (CII) configuration window is divided into two sections representing configurable entities: clocks and ports. When the window is initially displayed, all four clocks are set to None and all port menus are disabled. At least one clock source must be set before any ports can be configured. Initially, each of the four clocks can be configured as None, DCS Clock, N Clock, N-Wide Clock, Master or Master-Wide Clock. However, only certain clock/port mode combinations are legal; these are enforced by sysconfig. Each CII port must be configured with a data bit rate. The supported data rates are 48 Kbps, 9.6 Kbps, 4.8 Kbps, and 2.4 Kbps. Each of the four data ports can be configured for DTE Emulation, DCE Emulation, Monitor (DTE), or Monitor (DCE). Monitor ports must be configured in pairs, sharing a single cable connector. When one port is set to either of the monitor modes, the paired port is automatically set by sysconfig to the corresponding monitor mode. For example, if data port 1 is set to Monitor (DTE), the window automatically configures data port 2 as Monitor (DCE) and both ports 1 and 2 are shown to use data connector 1. Similarly, data ports 3 and 4 operate together when monitoring.
2-24
Ixia
2.12
PPCI (OC3E) Configuration Window

The PPCI OC3E mezzanine board has two independent physical links. Up to four IxCatapult physical ports can be configured per board.
2.12.1
Operating Modes The OC3E board supports the following operating modes: In emulation mode, there is no direct communication between the two links, and each IxCatapult physical port is a termination; that is, each port can be configured only in Drop and Insert mode. In passthrough mode, unmatched traffic is forwarded from link 0 to link 1 and from link 1 to link 0. Each IxCatapult physical port can be configured in Drop Rx mode, in which the ingress traffic belonging to this port is forwarded to the processor and the egress of the other link, or in Drop Rx and Tx mode, in which the matched traffic belonging to this port is only directed to the processor. The monitor mode is actually a restriction of the passthrough mode. All traffic is forwarded from link 0 to link 1 and from link 1 to link 0. Each port can only be configured in Drop Rx mode. The Max Aggregate Cell Rate for links 0 and 1 cannot be configured for monitor mode. It takes default values.
2.12.2
VPI/VCI Modes The OC3E board supports the following VPI/VCI modes: The single VPI/VCI mode supports one VPI/VCI per physical port. The cell header must be assigned on each port. The multiple VPI/VCI mode supports a multiple number of VPI/VCIs per physical port. See Chapter 13, Multiple VPI/VCI, for information on how to use this feature.
2.12.3
Framing Format The Framing Format field specifies the line framing format. It can be set to ITU-T I.432.4, B-ISDN user-network interface modes OC3 (ATM)155 Mbps or OC1 (ATM) 51 Mbps, which correspond to 155.52 Mbit/s or 51.84 Mbit/s line speeds, respectively. It can also be configured in SONET modes OC3 (STS-3c ATM) 155 Mbps or OC1 (STS-1 ATM)51 Mbps, and SDH modes STM-1 155 Mbps or STM-0 51 Mbps.
2-25
Ixia
2.12.4
Cell Header Mask This 32-bit wide bit field is bitwise and-ed with the ATM cell header of each incoming cell before selecting the route to the IxCatapult physical ports.
2.12.5
Empty Cell Header This cell header is used for empty cells.
2.12.6
Empty Cell Payload This pattern is used to fill the body of empty cells.
2.12.7
Link Parameters Each link is configured with the following parameters: Transmit clock - Selection of the link synchronization source. In Master mode the link is synchronized from the boards clock; in Slave mode it is synchronized from the incoming line clock. Coset - The coset polynomial x6+x4+x2+1 is added modulo 2 to the HCS octet of each received cell before comparison with the calculated result or added to this octet before transmission of a cell. Scrambling - The payload (last 48 bytes) of each received and transmitted cell is descrambled or scrambled using the x43+1 polynomial.
2.12.8
Multiple VPI/VCI Mode Parameters The PPCI OC3E board is configured with the following parameters in the multiple VPI/VCI mode only: Max Num Channels - This specifies the maximum number of channels that can be configured on a link. Max Aggregate Cell Rate - Each link can be configured to a maximum aggregate cell rate. This value specifies the maximum sum of all peakCellRate values for all active channels on the link. The maximum value and the default value of Max Aggregate Cell Rate is equal to the Framing Format rate. See Chapter 13, Multiple VPI/VCI for details on configuring individual channels.
Each IxCatapult port must be configured to specify which VPI/VCIs are defined as well as the associated parameters for each VPI/VCI.
2-26
Ixia
2.12.9
Port Configuration Each port uses one of the following protocols: AAL0 - This protocol is used when you want to bypass the AAL layer and send 48-byte long payloads. If the payload length is less than 48 bytes, the remaining bytes are padded by 0s, and if it is more, the payload is truncated to 48 bytes. Each payload is transmitted by exactly one cell. This protocol has no configurable parameters. AAL1 - This protocol has the following configurable parameters. See the AAL1PRIM Protocol Manual [12] and AAL1 standard for more detailed descriptions of these parameters. SF - Structured format indicator BS - Block size PFM - Partial Fill Mode indicator VOC - Valid Octet Count in partial fill mode AAL2 - This protocol has the following configurable parameters: max_cps_sdu_length - This is the maximum size of the packets that can be received by the AAL2-CPS layer. The default value is 45. Timer CU - The Combined Use timer represents the amount of time a partially-filled AAL2 cell waits before transmission. This timer is specified in 5ms steps. The default value of this parameter is 0. No STF Mode - (OC3E and mPI(OC3) only) If this mode is enabled, the cell does not contain the STF byte. In this mode each cell starts with a new packet and contains only whole packets. There are no split or partial packets. This mode is disabled by default. AAL5 - This protocol has no configurable parameters. IP/AAL5 (according to RFC 2684/2492) - When this protocol is selected, the encapsulation method must be configured as either LLC-based or VC-based. Refer also to the TCP/UDP State Machine Manual [10].
2-27
Ixia
2.12.10 Traffic You can select either of two ATM Service Categories/Transfer Capabilities by selecting either CBR (constant bit rate) or UBR (unspecified bit rate) as the value of the Traffic field. CBR channels are high-priority channels. ATM cell transmission is controlled by a pace controller, which currently schedules a maximum of one ATM channel in each timeslot. Depending on the desired bit rate for that channel, it can be scheduled to transmit cells in any number of consequent timeslots. UBR channels are scheduled to transmit by the pace controller only when no other CBR channel is scheduled in that timeslot. If the CBR channel is scheduled in that timeslot, the UBR channel is not scheduled until one of the future timeslots is available.
2.12.10.1 Variable Bit Rate Traffic The PPCI OC3E board also supports Variable Bit Rate (VBR) ATM traffic type; however, this support is available only when the board is configured for multiple VPI/VCI mode. Parameters for the VBR traffic are set using the multiple VPI/VCI configuration process. See Section 13.9, Variable Bit Rate (VBR) ATM Traffic Type, on page 13-12 for information on using this feature. 2.12.11 Performance Limitations Cells passed between links in passthrough and monitor modes are passed at full rate up to the capacity of the links. Cells processed by the communications processor have a maximum total throughput of 155 Mb/s. This is the aggregate of transmit and receive on both links. If this rate is exceeded, cells are dropped or delayed. This limitation is the hardware limitation of the link connections to the processor. The actual rate achievable will be significantly lower due to processing limitations. 2.12.12 Alarms The following table lists the alarms displayed in the Port Status GUI for the PPCI OC3E board. For more detailed explanations, see the appropriate SONET or SDH specification.
2-28
Ixia
Alarm LOS (Loss of Signal)
Description Occurs when a receiver detects a consistent zero pattern for at least 10 us, and the signal is considered to be completely gone. LOS persists until two valid frames are received. A loss of signal, frame, or pointer causes alarm indication signals to be transmitted downstream. Maintenance signals then are sent upstream in response to the alarm indication signals. Transmitted downstream to all potentially affected equipment when a SONET NE detects the presence of a signal or line fault. SDH equivalent of AIS_L. Occurs when the H1/H2 (payload pointers) pointer bytes are not present between eight and ten consecutive frames, so the pointer is considered to be lost. This condition clears when three consecutive frames are received with valid pointer values. Upstream line TE (terminating equipment) receives LAIS and then sends P_AIS downstream to alert that a defect has occurred upstream. SDH equivalent of AIS_P. Occurs with combined OOCD, out of cell delineation state. Returned to the transmitting line TE upon detecting a loss of signal, loss of frame, or MS_AIS defect. SDH equivalent of RDI_L. Occurs when the receiver is unable to detect a valid framing pattern for 3 us. Though similar to LOS, LOF clears when two consecutive and valid frames are received. Generated by the equipment detecting the failure condition. Its similar to MS_AIS. The primary difference between the AIS and RDI signals is that AIS is sent in the direction of downstream receivers and RDI is sent upstream toward the NE generating the original signal. SDH equivalent of RDI_P.
AIS_L (Line AIS - Alarm Indication Signal)
MS_AIS LOP (Loss of Pointer)
AIS_P (Path Alarm Indication Signal)
AU_AIS LOCD (Loss of Cell Delineation) RDI_L (Remote Defect Indication) MS_RDI LOF (Loss of Frame)
RDI_P (Path Remote Defect Indication)
HP_RDI
2-29
Ixia
2.13
PPCI (Ethernet) Configuration Window

The PPCI Ethernet mezzanine board has two independent physical links. Up to two IxCatapult physical ports can be configured per board. Port 1 and port 2 correspond to link 0 and link 1, respectively. Each link connects to an IPv4 or IPv6 sub-network and auto-negotiates 10Base-T or 100Base-TX, Full or Half Duplex. The Ethernet board can be used in emulation and monitor modes. The following sections provide details on how to configure the board in these modes.
2.13.1
Emulation Mode There is no direct communication between the two links, and each IxCatapult physical port is a termination, that is, each can be configured only in Drop and Insert mode. Each port on the Ethernet board is configured with the following parameters: MAC Address - The Medium Access Control (MAC) Address can be configured manually or defaulted to the Ixia internally-generated MAC address. The MAC Address button on the Ethernet configuration window displays another popup window, allowing two possible choices: Catapult - If Catapult is selected, the OUI and Address fields are disabled, and the Ethernet state machine uses a default internally-generated MAC Address based on the IxCatapult-assigned OUI. Other - If Other is selected, the fields for OUI and Address are enabled and you can enter your own values for both fields. The address format is described in IEEE 802-1990 and is divided into two parts: Organizationally Unique Identifier (OUI), a three-byte field specific to a manufacturer Address, a three-byte field denoting a physical connection in the network, i.e. one of the two links on the Ethernet board. Netmask - This 32-bit wide bit field defines the class of network to which this link belongs. It is bitwise and-ed with the IPv4 header of each incoming packet before determining if this packet belongs to this Net Address. Enter using standard dot notation.
2-30
Ixia
Net Address - This 32-bit wide bit field defines the IPv4 subnetwork. A local IPv4 address that is created over an Ethernet port, by a tcp_connect_request for example, must belong to the corresponding subnetwork. Enter using standard dot notation. NOTE: See the TCP/UDP State Machine Manual [10] for details on TCP. Routing - Additional routing parameters can also be configured if you want to connect to an IPv4 host that is not on the IPv4 subnetwork. Ten routes can be defined. The first route is evaluated first, the second one, second, and so on. The traffic is directed to the first matching route. Enter using standard dot notation. Each route is defined by three parameters: Netmask, Destaddr, and Gwaddr. Destaddr is the destination address and Netmask is the applicable mask. Gwaddr is the IPv4 address of the gateway. Any addresses that match the masked value of Destaddr are routed to the gateway. The gateway has to be on the IPv4 subnetwork to which the Ethernet link is connected. It is the IPv4 host that receives the traffic directed to this route. The rule used to determine if a given IP packet belongs to a given route is the following: Given the destination address of the IP packet (IPADDR), the network mask (NETMASK), and the configured destination address (DESTADDR), then the IP packet belongs to the route if (MASK & IPADDR) == (MASK & DESTADDR) The default gateway parameter defines the IPv4 host to which the traffic that does not belong to the connected subnetwork is directed when no matching route is found. To implement a default gateway, see the TCP/UDP State Machine Manual [10].
IPv6 - If the IPv6 checkbox is enabled, IPv6 parameters can be configured (Netmask, Net Address, and Routing). These parameters correspond to the equivalently named IPv4 parameters, except all fields are 128 bits wide and are specified using standard IPv6 colon notation.
2-31
Ixia
2.13.2
Monitor Mode Links are set in promiscuous mode where all Ethernet frames on the physical links, irrespective of source/destination MAC addresses and protocol type, are received by the board hardware and subsequently passed to your script. The Ethernet board does not perform any ARP functionality, address checking, and so forth in this mode. Frames received from the physical media are delivered in raw Ethernet format to your DCPL script. The following format is used (see the Ethernet specification for details): Destination MAC address - 6 bytes Source MAC address - 6 bytes Protocol type/length - 2 bytes User data - 46 to 1500 bytes CRC - 4 bytes
In Monitor mode each port (physical link) of the Ethernet board can be configured as: Drop and Insert - All frames received on this port are forwarded to the other port of the board (pass through the board). A copy of each frame is also delivered to your DCPL script. When both links are set in this mode the Ethernet board can be used to monitor point-to-point connections, for example, DUT to Ethernet switch Drop Rx - All frames received on the port are only delivered to your script. The frames are not forwarded to the other link. In this mode of operation, the Ethernet board can monitor up to two Ethernet broadcasting domains (one on each port). In both modes of operation your script can send (inject) frames to the link using the {port} free i=.... DCPL command. The format of the information passed should be a complete Ethernet frame (see above) except that the CRC field is not required (it is calculated and added by hardware). Each link can be set in a different mode depending on the type of monitoring/traffic replacement required. For example, setting one link in Drop and Insert mode and the other in Drop Rx mode enables you to monitor and pass traffic in one direction while traffic in the reverse direction can be blocked or replaced by frames generated by your script. Other configuration window parameters such as MAC address, net mask, routing, and so on are not used in monitor mode.
2-32
Ixia
2.13.3
General Limitations The Ethernet mezzanine supports up to 1,048,575 unique local IP addresses per link. Additionally, these IP addresses must be within the first 1,048,575 addresses in the subnetworks address space. There is no limit on the number of remote IP addresses supported. Once a socket is created with a given local IP address, the Address Resolution Protocol (ARP) layer claims packets with this address for the remainder of the IxCatapult session. All ARP entries are cleared each time a session is started. For example, assume that the Netmask of the subnetwork connected to the Ethernet link is ff000000, a class A subnetwork. The Network address is C0000000 (192.0.0.0). With this configuration, the only IP addresses that can be hosted by the link are c0000001 to c00fffff. The cBC(Ethernet), PPCI(Ethernet), PPCI+(Ethernet), and cBC+(Ethernet) boards have an MTU size of 1500 bytes, and thus do not support jumbo frames.
2.13.4
Port Status Indications The Port Status GUI indicates the board number, mode, physical medium, speed, and link. Speed: Green - 100B-TX Off - 10B-T
Link: Green - Link Detected Off - No Link Detected
2-33
Ixia
2.14
PPCI (GigE) Configuration Window

The Gigabit Ethernet mezzanine board is available in two different types: The GigE_2 board (SA-9018) provides two 10/100/1000 Mbps copper ports, which can be used simultaneously. The GigE board (SA-9019) provides a 10/100/1000 Mbps copper port and a 1000 Mbps optical port. Only one port can be used at a time. The active interface is specified by setting the physical medium in the system configuration file.
The Gigabit Ethernet board can be used in emulation mode only. The following section provides details on how to configure the board. 2.14.1 Configuring the Board in Emulation Mode Port configuration on the GigE_2 and GigE boards is identical. The GigE_2 board has two configurable ports; the GigE board has only one configurable port. MAC Address - The Medium Access Control (MAC) address can be configured manually or defaulted to the IxCatapult internally generated MAC address. The MAC Address button on the Ethernet configuration window displays another popup window, allowing two possible choices: Catapult - If Catapult is selected, the OUI and Address fields are disabled, and the Ethernet state machine uses a default internally generated MAC address based on the IxCatapult-assigned OUI. Other - If Other is selected, the OUI and Address fields are enabled, and you can enter your own values for both fields. The address format is described in IEEE 802-1990 and is divided into two parts: Organizationally Unique Identifier (OUI), a three-byte field specific to a manufacturer Address, a three-byte field denoting a physical connection in the network, that is, one of the two links on the Ethernet board Physical Medium - This field defines the physical connection with which the port is associated. For GigE_2 boards, the only available option for this field is copper. For GigE boards, the available options are copper and the optional SFP Optical module.
2-34
Ixia
IP MTU - This numeric field defines the Maximum Transmission Unit for the IP sub-layer. This is the maximum size IP frame payload (IP packet + IP headers) that the interface will transmit and receive. It does not include the 18-byte Ethernet II header. By default it is 1500 bytes, but it can take on values of 64 to 9714 bytes. VLAN - Virtual LAN parameters can be configured for the physical port (see Section 2.14.2, VLAN Configuration, on page 2-36). The GigE (9019) board supports IEEE 802.1q (VLAN) and operates like a MAC client as defined by the standard. This means it can recognize physical networks that are partitioned into multiple, independent logical networks using VLAN tags. VLAN ingress and egress processing can be configured statically using sysconfig or dynamically using DCPL extensions. The range of valid VIDs for GigE boards is 1-4094. The value 255 is reserved in addition. Netmask - This 32-bit wide bit field defines the class of network to which this link belongs. It is bitwise and-ed with the IPv4 header of each incoming packet before determining if this packet belongs to this Net Address. Enter using standard dot notation. Net Address - This 32-bit wide bit field defines the IPv4 subnetwork. A local IPv4 address that is created over an Ethernet port, by a tcp_connect_request for example, must belong to the corresponding subnetwork. Enter using standard dot notation. NOTE: See the TCP/UDP State Machine Manual [10] for details on TCP. Routing - Additional routing parameters can also be configured if you want to connect to an IPv4 host that is not on the IPv4 subnetwork. Ten routes can be defined. The first route is evaluated first, the second route, second, and so on. The traffic is directed to the first matching route. Enter using standard dot notation. Each route is defined by three parameters: Netmask, Destaddr, and Gwaddr. Destaddr is the destination address and Netmask is the applicable mask. Gwaddr is the IPv4 address of the gateway. Any addresses that match the masked value of Destaddr are routed to the gateway. The gateway must be on the IPv4 subnetwork to which the Ethernet link is connected. It is the IPv4 host that receives the traffic directed to this route.
2-35
Ixia
The following rule is used to determine if a given IP packet belongs to a given route: Given the destination address of the IP packet (IPADDR), the network mask (NETMASK), and the configured destination address (DESTADDR), then the IP packet belongs to the route if (MASK & IPADDR) == (MASK & DESTADDR) The default gateway parameter defines the IPv4 host to which the traffic that does not belong to the connected subnetwork is directed when no matching route is found. To implement a default gateway, see the TCP/UDP State Machine Manual [10]. IPv6 - If the IPv6 checkbox is enabled, IPv6 parameters can be configured (Netmask, Net Address, and Routing). These parameters correspond to the equivalently named IPv4 parameters, except all fields are 128 bits wide and are specified using standard IPv6 colon notation.
2.14.2
VLAN Configuration sysconfig is used to specify VLAN IDs and their rules, such as acceptable frame type, subnet address and mask, and whether the board should accept untagged frames. The rules can be set up to apply to all ports on egress or to a specified range of ports. When using sysconfig for egress classification, the VLAN tag can either be applied to all protocol ports, or be limited to specific protocol ports. In the latter case, it is important to know which protocol ports will be used in a test. Each entry in the egress classification table can specify a range of protocol ports. However, some frames such as ARP (IPv4) and ND (IPv6) do not carry a protocol port field. The frame that results in generation of the ARP has a destination IP and protocol port. This destination address is used to select the appropriate VLAN tag. You can choose to receive or reject untagged frames. The system will not receive frames with VLAN tags that are not specified in the configuration. PVID - This field defines the Port VLAN Identifier. This field is used when no other VLAN classification mechanism matches the packet. For GigE_2 boards, a specific VID value can only be used on one port. User Priority - When frames are tagged with the PVID, this field is used to populate the user priority.
2-36
Ixia
Drop Untagged Frames - Perform acceptable frame type filtering for frames received on this port. Apply to All Ports - If checked, the VLAN tag is applied to all protocol ports for the IP address and mask specified. Protocol Port Start/End are grayed out and show the full range of protocol ports. IP/Mask - Define a V4 or V6 destination IP address and network mask for VLAN classification. Protocol Port Start/End - Define a port range for VLAN classification. VID - Define a VID to use when tagging frames that match the VLAN classification criteria specified. For GigE_2 boards, a specific VID value can only be used on one port. User Priority - Define a user priority to use when tagging frames that match the VLAN classification criteria specified.
Packets are tagged at egress based upon the following rules: Packets tagged in using DCPL extensions are relayed without change. Packets matching egress classification rules are tagged with the corresponding VID/user priority. Packets not matching any of the above criteria are tagged with the default PVID/user priority if PVID is greater than 0.
You can click the Validate button to perform checks for common problems in the VLAN configuration. Note that clicking Validate is optional and is only intended as an aid since it cannot check all possible scenarios. 2.14.3 General Limitations The Ethernet mezzanine supports up to 1,048,575 unique local IP addresses per link. Additionally, these IP addresses must be within the first 1,048,575 addresses in the subnetworks address space. There is no limit on the number of remote IP addresses supported. Once a socket is created with a given local IP address, the Address Resolution Protocol (ARP) layer claims packets with this address for the remainder of the IxCatapult session. All ARP entries are cleared each time a session is started. For example, assume that the Netmask of the subnetwork connected to the Ethernet link is ff000000, a class A subnetwork. The Network address is C0000000 (192.0.0.0). With this
2-37
Ixia
configuration, the only IP addresses that can be hosted by the link are c0000001 to c00fffff. Both the GigE_2 and GigE boards support jumbo frames up to an MTU size of 9714 bytes.
2.14.4
Port Status Indications The Port Status GUI indicates the board number, mode, physical medium, speed, and link. Speed status (copper): Green - 1000B-T Yellow - 100B-TX Off - 10B-T
Speed status (optical): Green - 1000B-SX
Link status: Green - Link Detected Off - No Link Established
2-38
Ixia
2.15
mCI(ATM) Configuration Window

The mCI(ATM) board has two processor complexes and one physical link connected to the pluggable optical module or m500 mesh backplane. Up to four ports can be configured per processor complex. NOTE: The mCI(ATM) board is also known as the mCU(2) when used in conjunction with an mPI instead of its front-panel connector. The mCI(ATM) board can be used in an ATM configuration or as a generic processing board in conjunction with an mPI board across the m500 mesh backplane. If used with an mPI board, simply configure the board as Emulation and ignore all other parameters as they are ignored when using the m500 mesh backplane interface to an mPI. If the intent is to use the mCI(ATM) optical link, it must be configured in one of the following two modes: Emulation - Each physical port is a termination, that is, each can be configured only in Drop and Insert mode. Matched ingress traffic on the port is forwarded to the associated processor complex, while egress traffic from each processor complex is multiplexed onto the physical link. Passthrough - Unmatched traffic is forwarded from the ingress of link 0 to the egress of link 0. Each IxCatapult physical port can be configured in Drop Rx, in which the ingress traffic belonging to this port is directed to the associated processor complex and is forwarded to the egress of link 0, or in Drop Rx and Tx, in which the matched traffic belonging to this port is only directed to the associated processor complex.
Also, each board can be used in one of the following two modes: Single VPI/VCI mode - One VPI/VCI per physical port. The cell header must be assigned on each port. Multiple VPI/VCI mode - Multiple number of VPI/VCIs per physical port. See Chapter 13, Multiple VPI/VCI, for information on how to use this feature.
Similar to the OC3E board, each mCI(ATM) board is configured with the following parameters: Framing Format - This field selects the line framing format. It can be set to ITU-T I.432.4, B-ISDN user-network interface modes OC-12 (622.08 Mbps) or OC-3 (155.52 Mbps) depending on the type of pluggable module in the mCI(ATM). It can also be configured in SONET modes STS-12c (622.08 Mbps) or
2-39
Ixia
STS-3c(155.52 Mbps), and SDH modes STM-4 (622.08 Mbps) or STM-1 (155.52 Mbps). Cell Header Mask - This 32-bit wide bit field is bitwise and-ed with the ATM cell header of each incoming cell before selecting the route to the IxCatapult physical ports. Empty Cell Header - This cell header is used for empty cells. Empty Cell Payload - This pattern is used to fill the body of the empty cells.
The link is configured with the following parameters: Transmit clock - Selection of the link synchronization source. In Master mode the link is synchronized from the boards clock; in Slave mode it is synchronized from the incoming line clock. Coset - The coset polynomial x6+x4+x2+1 is added modulo 2 to the HCS octet of each received cell before comparison with the calculated result or added to this octet before transmission of a cell. Scrambling - The payload (last 48 bytes) of each received and transmitted cell is descrambled or scrambled using the x43+1 polynomial. Discard Idle Cell (GFC > 0)- Used in Passthrough mode, this prevents unwanted idle cells generated by the device under test from being forwarded.
Each processor complex on the mCI(ATM) board is configured with the following additional parameters in the multiple VPI/VCI mode only: Max Num Channels - Specifies the maximum number of channels that can be configured on a processor complex. Max Aggregate Cell Rate - Each processor complex can be configured to a maximum aggregate cell rate. This value specifies the maximum sum of all peakCellRate values for all active channels on the link. The maximum value and the default value of Max Aggregate Cell Rate is equal to the Framing Format rate. See Chapter 13, Multiple VPI/VCI for details on configuring individual channels.
Each processor complex on the mCI has four IxCatapult ports for configuring which VPI/VCIs are defined and the associated parameters with each VPI/VCI. Each port uses one of the five following protocols: ATM-AAL5, IP/AAL5 according to RFC 2684/2492, ATM-AAL2, ATM-AAL1, or ATM-AAL0.
2-40
Ixia
When used in IP/AAL5 mode, the encapsulation method must be configured, as either LLC-based or VC-based. Refer also to the TCP/UDP State Machine Manual [10]. When used in AAL2 mode, the following parameters also must be configured: max_cps_sdu_length - This is the maximum size of the packets that can be received by the AAL2-CPS layer. The default value is 45. Timer CU - The Combined Use timer represents the amount of time a partially-filled AAL2 cell waits before transmission. This timer is specified in 5ms steps. The default value of this parameter is 0. No STF Mode - If this mode is enabled the cell does not contain the STF byte. In this mode each cell starts with a new packet and contains only whole packets. There are no split or partial packets. This mode is disabled by default.
For AAL1, you must set up the following parameters: SF - Structured format indicator BS - Block size PFM - Partial Fill Mode indicator VOC - Valid Octet Count in partial fill mode
See the AAL1PRIM Protocol Manual [12] and AAL1 standard for more detailed descriptions of these parameters. AAL0 mode is used when you want to bypass the AAL layer, and send 48-byte long payloads. If the payload length is less than 48 bytes, the remaining bytes are padded by 0s. If it is more, the payload is truncated to 48 bytes. Each payload is transmitted by exactly one cell. Traffic - You can select either of two ATM Service Categories/Transfer Capabilities by selecting either CBR (constant bit rate) or UBR (unspecified bit rate) as the value of the field Traffic. CBR channels are high-priority channels. ATM cell transmission is controlled by a pace controller, which currently schedules a maximum of one ATM channel in each timeslot. Depending on the bitrate desired for that channel, it can be scheduled to transmit cells in any number of consequent timeslots. The UBR channels are scheduled to transmit by the pace controller only when there is no other CBR channel scheduled in that timeslot. If the CBR channel is scheduled in that timeslot, the UBR channel is not scheduled until one of the future timeslots is available.
2-41
Ixia
2.15.1
Variable Bit Rate Support The mCI(ATM) boards also support Variable Bit Rate (VBR) ATM traffic type; however, this support is available only when the PPCI board is configured for multiple VPI/VCI mode. Parameters for the VBR traffic are set using the multiple VPI/VCI configuration process. See Section 13.9, Variable Bit Rate (VBR) ATM Traffic Type, on page 13-12 for information on using this feature. Other configuration window parameters such as MAC address, net mask, and routing are not used in monitor mode.
2.16
mPI(Ethernet) Configuration Window

The mPI(Ethernet) board has four 10/100/1000 Mbps links. It must be used in conjunction with one or more Coprocessor boards with an m500 mesh backplane interface (that is, mCI(ATM)). Coprocessor boards can share physical links as long as the IP addresses used by each physical link do not conflict between Coprocessor boards. The relationship between what mPI and mCIs are used in a session is determined by the use of Interboard ports. See Section 3.2.4.1, Creating Connections, on page 3-8 and Section 3.2.4.2, Configuring Connections, on page 3-10 for details. The mPI(Ethernet) board can only be used in emulation mode. Each physical port is a termination; that is, each can be configured only in Drop and Insert mode. Matched ingress traffic on the port is forwarded to the associated Coprocessor board across the m500 mesh backplane, while egress traffic from each Coprocessor board is multiplexed onto the physical link. Similar to the PPCI(Ethernet) board, each mPI(Ethernet) board is configured with the following parameters for each of its four physical ports: MAC Address - The Medium Access Control (MAC) Address can be configured manually or defaulted to the IxCatapult internally-generated MAC address. The MAC Address button on the Ethernet configuration window displays another popup window, allowing two possible choices: Catapult - If Catapult is selected, the OUI and Address fields are disabled, and the Ethernet state machine uses a default internally-generated MAC Address based on the IxCatapult-assigned OUI.
2-42
Ixia
Other - If Other is selected, the fields for OUI and Address are enabled and you can enter your own values for both fields. The address format is described in IEEE 802-1990 and is divided into two parts: Organizationally Unique Identifier (OUI), a three-byte field specific to a manufacturer Address, a three-byte field denoting a physical connection in the network, i.e. one of the two links on the Ethernet board.
Physical Medium - This field defines the physical connector to use on the mPI(Ethernet) Rear Transition Module (RTM). You can select between the Copper or Optical interface. Auto Sense - This field defines whether the system will automatically detect the line rate and duplex mode of the network to which it is connected. The default value is Yes. If you need to select a particular mode, select No and set the line rate (10/100/1000 Mbps) and duplex mode. NOTE: Half-duplex mode is currently not supported.
Ethernet MTU - This numeric field defines the Maximum Transmission Unit for the Ethernet interface. This is the maximum size Ethernet frame payload (IP packet + IP headers) that the interface will transmit and receive. By default it is 1500 bytes, but can take on values of 64 to 9714 bytes. Note that the actual payload size is further limited in the IxCatapult system based on the computing module used. The mCU(5)/mCU5E board has a maximum frame size of 9728 bytes, which allows a maximum IP payload size of 9670 bytes (excluding the IP and Ethernet headers). The mCI(ATM) board has a maximum frame size of 8192 bytes, which allows a maximum IP payload size of 8134 bytes (excluding the IP and Ethernet headers).
VLAN - Virtual LAN parameters can be configured for each physical port (see Section 2.16.1, VLAN Configuration, on page 2-45). The mPI(Ethernet) board supports IEEE 802.1q (VLAN) and operates like a MAC client as defined by the standard. This means it can recognize physical networks that are partitioned into multiple, independent logical networks using VLAN tags. VLAN ingress and egress processing can be configured statically using sysconfig or dynamically using DCPL extensions.
2-43
Ixia
IPv4 Parameters - The following IPv4 parameters can be configured. Net Address - This 32-bit wide bit field defines the IPv4 subnetwork. A local IPv4 address that is created over an Ethernet port, by a tcp_connect_request for example, has to belong to the corresponding subnetwork. Enter using standard dot notation. NOTE: See the TCP/UDP State Machine Manual [10] for details on TCP. Routing - Additional routing parameters can also be configured if you want to connect to an IPv4 host that is not on the IPv4 subnetwork. Four routes can be defined. The first route is evaluated first, the second one, second, and so on. The traffic is directed to the first matching route. Enter using standard dot notation. Each route is defined by three parameters: Netmask, Destaddr, and Gwaddr. Destaddr is the destination address and Netmask is the applicable mask. Gwaddr is the IPv4 address of the gateway. Any addresses that match the masked value of Destaddr will be routed to the gateway. The gateway has to be on the IPv4 subnetwork to which the Ethernet link is connected. It is the IPv4 host that receives the traffic directed to this route. The rule used to determine if a given IP packet belongs to a given route is the following: Given the destination address of the IP packet (IPADDR), the network mask (NETMASK), and the configured destination address (DESTADDR), then the IP packet belongs to the route if (MASK & IPADDR) == (MASK & DESTADDR) Netmask - This 32-bit wide bit field defines the class of network to which this link belongs. It is bitwise and-ed with the IPv4 header of each incoming packet before determining if this packet belongs to this Net Address. Enter using standard dot notation. The ip address parameter defines a pingable IP address on the link. This IP address (if not 0.0.0.0) will respond automatically to ICMP echo requests for that IP address on the network. Primarily used for debugging purposes, it is completely independent of any applications running on any other Coprocessor boards using the mPI(Ethernet) over the m500 mesh backplane.
2-44
Ixia
The default gateway parameter defines the IPv4 host to which the traffic that does not belong to the connected subnetwork will be directed when no matching route is found. To implement a default gateway, see the TCP/UDP State Machine Manual [10]. IPv6 Parameters - If the IPv6 checkbox is enabled, IPv6 parameters can be configured (Net Address and Routing). These parameters correspond to the equivalently named IPv4 parameters, except all fields are 128 bits wide and are specified using standard IPv6 colon notation.
2.16.1
VLAN Configuration sysconfig is used to specify VLAN ingress processing behavior. Rules such as acceptable frame type, ingress filtering, and VLAN membership can be specified on a per-port basis. When using sysconfig for egress classification, the VLAN tag can either be applied to all protocol ports, or be limited to specific protocol ports. In the latter case, it is important to know which protocol ports will be used in a test. Each entry in the egress classification table can specify a range of protocol ports. However, some frames such as ARP (IPv4) and ND (IPv6) do not carry a protocol port field. In these cases, a special entry for protocol port 0 should be added to specify the VLAN tag used for such frames. When using DCPL extensions to send VLAN tagged frames (see Section 8.8.12, VLAN Special Variables, on page 8-102), it is important to ensure sysconfig settings are compatible. If ingress filtering is not required, it can be disabled. Otherwise, each VLAN identifier used in the test should be specified in the ingress database. PVID - This field defines the Port VLAN Identifier. This field is used when no other VLAN classification mechanism matches the packet. User Priority - When frames are tagged with the PVID, this field is used to populate the user priority. Ingress Filter - Perform ingress filtering for frames received on this port. Drop Untagged Frames - Perform acceptable frame type filtering for frames received on this port. Tag (Egress) - All frames transmitted from the port are tagged. If there is no match in the egress classification table, the PVID and default user priority are used.
2-45
Ixia
VLAN Database (ingress) - Use the Add and Remove buttons to define the VLANs of which the port is a member. If ingress filtering is enabled, frames received on VLANs not in the database are filtered out. VID - Virtual Identifier defined on this port. VLAN Database (egress) - Use the Add and Remove buttons to define egress VLAN tagging rules. Apply to All Ports - If checked, the VLAN tag is applied to all protocol ports for the IP address and mask specified. Protocol Port Start/End are grayed out and show the full range of protocol ports. IP/Mask - Define a V4 or V6 destination IP address and network mask for VLAN classification. Protocol Port Start/End - Define a port range for VLAN classification. VID - Define a VID to use when tagging frames that match the VLAN classification criteria specified. User Priority - Define a user priority to use when tagging frames that match the VLAN classification criteria specified.
Packets are tagged at egress based upon the following rules: Packets tagged in the mCU using DCPL extensions are relayed without change. Packets matching egress classification rules are tagged with the corresponding VID/user priority. Packets not matching any of the above criteria are tagged with the default PVID/user priority if Tag (Egress) is enabled.
You can click the Validate button to perform checks for common problems in the VLAN configuration. Note that clicking Validate is optional and is only intended as an aid since it cannot check all possible scenarios. 2.16.2 Restrictions and Limitations On an m500 shelf, the SA-9300 mPI board supports a maximum of 43,000 table-entries for IPv4 and IPv6 addresses per port. A table-entry consists of an IP address (either IPv4 or IPv6) coupled with a port-number, which, if used, is the UDP or TCP port-number associated with the IP address. The port-number field will be zero for protocols other than TCP or UDP.
2-46
Ixia
The port-number is normally zero even for TCP or UDP, unless the IP port forwarding feature is invoked. See the discussion of this feature in Section 8.8.13, mPI(GigE) Special Variables for IP Port Forwarding, on page 8-103. When IP port forwarding is enabled, the TCP or UDP port-number will be used in the table-entry. Each table-entry combination of IP address and port-number must yield a unique entry. Duplicates result in a failure message in the test case. Each port on an mPI board can contain up to 43,000 table-entries. An mPI(GigE) supports four ports, so it could, for example, support up to (4 x 43,000) entries, or a total of 172,000 entries. Table-entries on different ports are not required to be unique. There is a limit of 1000 entries in the egress classification table.
2.17
mPI(OC3) Configuration Window

The mPI(OC3) board has four links. The mPI(OC3) must be used in conjunction with one or more Coprocessor boards with an m500 mesh backplane interface (that is, mCI(ATM)). Coprocessor boards can share physical links. The relationship between what mPI and mCIs are used in a session are determined by the use of Interboard ports. See Section 3.2.4.1, Creating Connections, on page 3-8 and Section 3.2.4.2, Configuring Connections, on page 3-10 for details. The mPI(OC3) board can be configured as follows: Mode: Emulation - Each physical port is a termination; that is, each can be configured only in Drop and Insert mode. Matched ingress traffic on the port is forwarded to the associated Coprocessor board across the m500 mesh backplane, while egress traffic from each Coprocessor board is multiplexed onto the physical link. VPI/VCI mode: Multiple- Multiple number of VPI/VCIs per physical port. See Chapter 13, Multiple VPI/VCI, for information on how to use this feature. Framing Format: This field selects the line framing format. It can be configured in SONET modes STS-3c(155.52 Mbps), and SDH mode STM-1 (155.52 Mbps). In the STM-1 mode the SS bits are set to 2 on the first H1 overhead byte only. AAL2 CPS Packing Expiration Time-out: This mPI(OC3) timer represents the amount of time in microseconds that a partially filled AAL2 cell is buffered before transmission. Increasing this timer may improve link usage efficiency in transmission. The range is 12 to 10000 microseconds. The default value is 1000. For optimal link
2-47
Ixia
utilization, it is recommended that a value equivalent to twice the average AAL2 PCR defined be used:
Time-out = (353207/average PCR) x 2.8us x 2
AAL2/AAL5 Reassembly Expiration Time-out: This timer represents the amount of time in microseconds between the arrival of the final cell in the AAL2/AAL5 PDU and the AAL2/AAL5 PDU payload being made available up the stack to the service layer. This field is not utilized by the mPI(OC3) hardware and is disabled within the GUI. Transmit Clock: Selection of the link synchronization source. The possible selections are Slave to link 0, Slave to Link 1, Slave to Link 2, Slave to Link 3, and Master. With a Slave to Link <x> selection, the clock received on that link is recovered and used for transmission on all links. In addition, if that mPI(OC3) is shelf clock master, that clock is used to synchronize the boards on the midplane. With the Master selection, the shelf clock is used for transmission on all links.
On a per link basis, you can configure the following on the mPI(OC3): Cell Header Type: To inform the mPI(OC3) for the cell header type on that link. ATM Cell Header COSET: The coset polynomial x6+x4+x2+1 is added modulo 2 to the HCS octet of each received cell before comparison with the calculated result or added to this octet before transmission of a cell. This is always enabled on the mPI(OC3). ATM Cell Payload Scrambling: The payload (last 48 bytes) of each received and transmitted cell is descrambled or scrambled using the x43+1 polynomial. AAL2 SSCS-PDU Maximum Length (SSSAR): The maximum AAL2 SSCS-PDU is specified here. The range is 1 to 8192 bytes. The default value is 2048. Take care when setting this field. Some protocols append multiple PDUs together when transmitting, which increases the maximum length beyond what was specified with this field. The mPI(OC3) discards the PDUs that are larger than the value specified. AAL5 CPCS-PDU Maximum Length: The maximum AAL5 CPCS-PDU size is specified here. The range is 1 to 8192 bytes. The default value is 4096.
2-48
Ixia
Maximum Aggregate Cell Rate: The maximum cell rate for the full link is specified here. The range is 4 to 353207. This field is not used by the mPI(OC3) hardware, as the default maximum aggregate cell rate is always 353207 cells/second. Total AAL0 VPI/VCI Connections: This determines the maximum allowed unique VPI/VCI AAL0 channels. This is set to a default of 0. You must specify a correct nonzero value here to be able to open any AAL0 connections. Total AAL2 VPI/VCI Connections: Determines the maximum allowed unique VPI/VCI AAL2 channels. This value is set to a default of 0. You must specify a correct nonzero value here to be able to open any AAL2 connections. Total AAL2 VPI/VCI/CID Connections: Determines the maximum allowed unique VPI/VCI/CID AAL2 channels. This value is set to a default of 0. You must specify a correct nonzero value here to be able to open any AAL2 VPI/VCI/CID connections. In order to open AAL2 VPI/VCI/CID connections, you must fill up appropriate values in the Total AAL2 VPI/VCI Connections field and Total AAL2 VPI/VCI/CID Connections field. For example, if you need 20 CIDs each on five AAL2 VPI/VCIs, the value of Total AAL2 VPI/VCI Connections must be set to 5 and the value of Total AAL2 VPI/VCI Connections must be set to 100.
Total AAL5 VPI/VCI Connections: Determines the maximum allowed unique VPI/VCI AAL5 channels. This value is set to a default of 0. You must specify a correct nonzero value here to be able to open any AAL0 connections. Total OAM AAL0 VPI/VCI Connections: Determines the maximum allowed unique VPI/VCI AAL0 OAM channels. This value is set to a default of 0. You must specify a correct nonzero value here to be able to open any AAL0 connections.
NOTE: The maximum sum total of all connections across all four links is 88000. The mPI(OC3) boards are always used in conjunction with one or more Coprocessor boards with an m500 mesh backplane interface; that is, mCI(ATM). Each processor complex on the mCI can have four IxCatapult interboard ports for configuring the VPI/VCI/CIDs on the mPI. Each port uses one of the five following protocols: ATM-AAL5, IP/AAL5 according to RFC 2684/2492, ATM-AAL2, or ATM-AAL0.
2-49
Ixia
The protocols and their parameter on the mPI(OC3) are configured in the Data Drop and Insert section as follows: Link: The link is a unused field on the mPI(OC3). The link value is specified in the DCPL special variable %initcell on the mPI(OC3). Type: This value is used by the display process to decode the cell header information in the mPI(OC3). Protocol: IP/AAL5 When used in IP/AAL5 mode, the Encapsulation Method must be configured, as either RFC_2684/2492_LLC_based or RFC_2684/2492_VC_based. Refer also to the TCP/UDP State Machine Manual [10]. Protocol: AAL2 When used in AAL2 mode, the following parameters also must be configured: CPCS packet maximum size (1 to 64): This is the maximum size of the packets that can be received by the AAL2-CPS layer. The default value is 45. Timer CU: The Timer CU functionality is provided on the mPI with the AAL2 CPS Packing Expiration Time-out setting. No STF Mode: If this mode is enabled the cell does not contain the STF byte. In this mode each cell starts with a new packet and contains only whole packets. There are no split or partial packets. This mode is disabled by default. To enable Partial Fill mode, set this parameter to Yes. Protocol: AAL0 Use the AAL0 mode when you want to bypass the AAL layer and send 48-byte long payloads. If the payload length is less than 48 bytes, the remaining bytes are padded by 0s, and if it is more, the payload is truncated to 48 bytes. Each payload is transmitted by exactly one cell. This mode is also used for the OAM functionality. Cell Header (in hex): This is unused on the mPI(OC3). The cell header value is specified on the mPI(OC3) in the %initcell DCPL special variable. Traffic: This is an unused field on the mPI(OC3). The traffic type is specified in the %initcell DCPL special variable. The current supported traffic on the mPI(OC3) is the CBR (constant bit rate). Peak Cell Rate: This is unused on the mPI(OC3). The cell header value is specified on the mPI(OC3) in the %initcell DCPL special variable.
2-50
Ixia
2.18
mPI(STM) Configuration Window

The mPI(STM) board combines the functionality of a SONET/SDH ADM with an E1/T1/J1 multiplexer. It has four SFP optical links, each supporting a rate of OC-3 (STM-1). Alternatively, a rate of OC-12 (STM-4) can be supported with a single link. This creates 8064 individual DS0 channels that can be managed and used independently. The mPI(STM) must be used in conjunction with one or more Coprocessor boards with an m500 mesh backplane interface, i.e. mCI(ATM). Coprocessor boards can share physical links on the mPI(STM) as long as they use unique DS0 channel numbers. The relationship between what mPI and mCIs are used in a session is determined by the use of Interboard ports. See Section 3.2.4.1, Creating Connections, on page 3-8 and Section 3.2.4.2, Configuring Connections, on page 3-10 for details.
2.18.1
Standard and Card Type The available Card Type settings depend on the value specified in the Standard field. These fields can be configured as follows: SONET modes STS-12c (622.08 Mbps) or STS-3c (155.52 Mbps) SDH modes STM-4 (622.08 Mbps) or STM-1 (155.52 Mbps)
2.18.2
Physical Links Specifies the number of physical links (1-4).
2.18.3
Mode (Link or Port Interface and Global Options) Specifies if the shelf is operating in emulation, passthrough, or monitor modes. In emulation mode, there is no direct communication between the two configured links. Each port is a termination. The ports can only be configured in drop and insert mode. In passthrough mode, unmatched traffic is forwarded from link 0 to link 1 and from link 1 to link 0. Each physical port can be configured in Drop Rx where the ingress traffic belonging to the port is forwarded to the processor and the egress of the other link. Each port can also be configured in Drop Rx and Tx where the matched traffic belonging to the port is only directed to the processor. In monitor mode, all traffic is forwarded from link 0 to link 1 and from link 1 to link 0. This mode is a restriction of the passthrough mode. Each port can only be configured in Drop Rx mode.
2-51
Ixia
2.18.4
Sync Clock Specifies the clock source for each port: Slave to Link 0, Slave to Link 1, Slave to Link 2, Slave to Link 3, or Master.
2.18.5
ITU-T G.707 E1/T1 Number Scheme Specifies the numbering scheme (MLK or KLM).
2.18.6
Physical Interface Type You can choose either E1 (ETSI), T1 (ANSI), or J1 (Japan).
2.18.7
Transmit Framing This field specifies if CRC-4 framing is selected. Select Basic (Off) to turn off CRC-4 framing.
2.18.8
Receive Framing This field specifies if CRC-4 framing is selected. Select Basic (Off) to turn off CRC-4 framing.
2.18.9
Signalling NOTE: Signaling, referred to in CAS, is not SS7 signaling.
Specifies CAS (Channel Associated Signaling) or CCS (Common Channel Signaling). For the mPI(STM) board, you can also select 31B or 30B+ E1 signaling protocols. CAS consists of a 16-frame format. The FAS (Frame Alignment Signal) is transmitted in even frames on timeslot 0. The NFAS (Not Frame Alignment Signal) is transmitted in odd frames. Timeslot 16 in frame N, carries the signalling for voice channels N and N+15. In CCS, all or part of a channel is used to pass messages between two systems to indicate how a channel is being used. This type of system is commonly found in ISDN which uses a D channel to pass messages. CAS inserts signaling information into timeslot 16. CCS timeslot 16 is usable for user (SS7) data. 2.18.10 PCM Idle Pattern Specifies the Pulse Code Modulation quiet or idle pattern. You can choose 0x55 (A-LAW), 0x7F (MU-LAW), 0x54, 0x7E, 0xFF.
2-52
Ixia
2.18.11 Mode (Drop and Insert and Data Port Options) Specifies if the system is in a drop and insert mode. When this mode is selected, all frames received on the specified port are forwarded to the other port on the board. You can also select Unused. NOTE: Choose Drop and Insert to activate the HDLC button. Enable the HDLC button to configure the HDLC channels.
2.19
mCU(5)/mCU5E Configuration Window

The 5-processor mesh Computing Unit (mCU(5)) and enhanced mesh Computing Unit (mCU5E) do not require configuration and only appear in the GUI for informational purposes, particularly after using the Auto Config operation (see Section 2.2.2, Auto Config, on page 2-3).
2.20
UNIX Device Configuration Window

The IxCatapult system supports up to 30 standard UNIX devices as part of the test environment. Each logical device number (0 through 29) refers to either a TTY port or a socket endpoint. The UNIX device window directs you to identify the type as either TTY, TCP Socket, or UDP Socket and then displays the appropriate subwindow for entering the configuration data.
2.20.1
Using IPv4 and IPv6 Addresses TCP and UDP sockets can use either the IPv4 (4-byte) or IPv6 (16-byte) addresses of the workstation. IPv4 and IPv6 addresses assigned to a workstation can be seen by running the UNIX command ifconfig -a. In order to refer to a workstation by name and have the name resolved into an IPv6 address, either the address must be listed in the IxCatapult workstations /etc/inet/ipnodes file (if NIS is not used), or it must appear in the NIS servers ipnodes map (if NIS is used). NOTE: A socket with an IPv6 address can communicate only with another IPv6 socket. Likewise, an IPv4 socket can communicate only with another IPv4 socket.
2-53
Ixia
2.20.2
TTY Ports The following parameters are required.

Parameter TTY Device (/dev/) Speed (bits/second) Maximum Message length Parity Message Termination Characters Maximum Timeout from Message start Flow Control Start Character Stop Character Parity Mask 19200 80 None #0d 1 second Off #11 #13 #ff Default value
2.20.3
TCP Socket Endpoints The following parameters are required.

Parameter Dynamic Disable Disc Ind Service Name Remote Host Client/Server Address Type Use Protocol-specific Framing Maximum Message Length Parity Message Termination Characters Max Timeout from Message Start Parity Mask No ttyprotocol0 Server IPv4 GTP/SIP/TPKT/None 80 None #0d 0 second #ff Default value
2-54
Ixia
The Dynamic parameter configures the port for dynamic addressing; that is, the multiplexing of several sockets with different addresses onto the same port. This feature is useful only with protocols that support it. If this parameter is set to No, a single socket is created for this UNIX device when ddriver is started. Such sockets are referred to as static. The Use Protocol-specific Framing parameter specifies the protocol to be used in determining message boundaries within the TCP bytestream. See the manual for the protocol of interest to determine whether to set this field. The Message Termination Characters parameter specifies a set of one or more characters, any one of which terminates a message. The Remote Host field is used only for static sockets for which the Client/Server parameter is set to Client. It specifies the hostname or IP address of the server to which the client is to be connected. It can be a hostname, an IPv4 address in dot notation (for example, 1.2.3.4) or an IPv6 address in colon notation (for example, fe80::20ff::50f5). If a hostname is specified, the Address Type field determines whether the hosts IPv4 or IPv6 address is used. If the host does not have such an address, a run-time error occurs. If an IP address is specified in the Remote Host field, it must be of the type specified by the Address Type field. The Service Name parameter can be either a port number or a service name. In the latter case, the service name must be defined in /etc/services (see man services). Moreover, the service type specified in /etc/services must be tcp. The Disable Disc Ind field is used for dynamic TCP sockets. In case this field value is No, a TCP_DISCONNECT_INDICATION primitive or a T_DISCONNECT_INDICATION primitive is sent to the user when the peer terminates a connection. 2.20.4 UDP Socket Endpoints The following parameters are required.
Parameter Dynamic Service Name Remote Host Address Type Client/Server No ttyprotocol0 IPv4 Server Default value
2-55
Ixia
Parameter Parity Parity Mask #ff
Default value None
The Dynamic parameter configures the port for dynamic addressing; that is, the multiplexing of several sockets with different addresses onto the same port. This feature is useful only with protocols which support it. If this parameter is set to No, a single socket is created for this UNIX device when ddriver is started; such sockets are referred to as static. The Remote Host field is used only for static sockets for which the Client/Server parameter is set to Client. It specifies the hostname or IP address of the server to which the client is to be connected. It can be a hostname, an IPv4 address in dot notation (for example, 1.2.3.4) or an IPv6 address in colon notation (for example, fe80::20ff::50f5). If a hostname is specified, the Address Type field determines whether the hosts IPv4 or IPv6 address is used. If the host does not have such an address, a run-time error occurs. If an IP address is specified in the Remote Host field, it must be of the type specified by the Address Type field. The Service Name parameter can be either a port number or a service name. In the latter case, the service name must be defined in /etc/services (see man services); moreover, the service type specified in /etc/services must be udp.
2.21
Slot-Independent Naming
When the -o command-line parameter is specified, the sysconfig program displays a slightly modified main window. The left column is an entry field that allows naming the slot definitions. In this manner, a slot-independent file is created, allowing the system configuration file to be used on any system without needing to worry about the physical board positions until ddriver is run. The names given in sysconfig are used as environment variables to associate the names to the physical slots in your system.
2-56
Ixia
Environment variables are used to associate the slot names given during the configuration with physical boards in your system. Only the slot definitions that are required in a ddriver session must be defined in the environment before running ddriver or launch. There are several ways to set a variable in the environment depending on the type of shell or the method of invoking ddriver or launch. In csh, use setenv <defn_name> <board_no>, where defn_name is the name given to the configuration definition and board_no is the physical slot position of the board (for example, 3.6 or 2). In cases where the same definition is required for multiple boards in a single test, set the variable to a colon-separated list of board positions (for example, 3.6:2:1.4). Do not set more than one definition to the same board. Names for the definitions must be alphanumeric and can contain the underscore. No other special characters are allowed. The name is case-sensitive, so E1_LOOPBACK is not the same as E1_Loopback. The length of the name must be less than 80 characters. The -o flag is only required when creating a new slot-independent file or converting a slot dependent file. The sysconfig program automatically detects if the file is slot-independent and opens the correct dialog. This option allows the conversion of existing slot dependent files to slot-independent files. Default names are given to all definitions that are found in the specified configuration file. The default names are generated based on the original position of the definition in the slot dependent file (for example, unnamed_6 is a definition from a board in slot 6). However, once a file is converted to a slot-independent file, it cannot be converted back to a slot dependent file. Figure 2-6 shows the dialog when creating a slot-independent file. The names in the left hand column will later be set in the environment and associated to the boards in the system. If there is an Ethernet board in slot 3 of the workstation, either ETHERNET_LOOPBACK_IPV4 or ETHERNET_LAN_IPV4 could be used without changing the Launcher file.
2-57
Ixia
Figure 2-6.
Slot-Independent sysconfig Dialog
2.22
Environment Variable Slot Definitions

The -e command-line parameter displays the slot position for each name that is defined in the current environment, and is only valid with files created with the -o command-line parameter. This feature can help troubleshoot ddriver errors. Figure 2-7 shows the column with the board position displayed to the right of the definition name. In this example, there are OC3 boards in slots 1 and 2 and an Ethernet board in slot 3. The environment variables for the other slot names are not set.
2-58
Ixia
Figure 2-7.
Slot-Independent sysconfig Dialog with Board Positions
2-59
Ixia
2-60
3
Running an IxCatapult Session
Contents 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2 IxCatapult Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3 ddriver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Ixia
3.1
Introduction
This chapter explains the two ways to run an IxCatapult session: running the IxCatapult Launcher, an easy-to-use graphical interface running ddriver directly from the UNIX command line
3.2
IxCatapult Launcher
The Launcher is a graphical user-friendly way of creating contexts and running the IxCatapult system.
3.2.1
Running the IxCatapult Launcher To run the IxCatapult Launcher, type the launch command on the UNIX command line.
3.2.2
IxCatapult Launcher Window The IxCatapult Launcher window, shown in Figure 3-1, consists of two parts: a canvas on the left side, in which you build up the contexts of the IxCatapult session a palette on the right side containing a blank context and pre-existing contexts delivered with the IxCatapult product
The canvas contains a line separating the contexts that run on the workstation from those that run on Coprocessor (PowerPCI or mCI) boards.
3-2
Ixia
Figure 3-1.
IxCatapult Launcher Window
3.2.3
Creating and Configuring Contexts 3.2.3.1 Creating Contexts
Contexts are created by dragging a context from the palette onto the canvas using the left mouse button. Contexts above the dividing line run on the workstation. Contexts below the dividing line run on Coprocessor boards. Contexts can be moved after creation; the dividing line can also be dragged up and down. Contexts are not explicitly assigned to individual Coprocessor boards. Their assignment is inferred from the board ports to which they are connected. 3.2.3.2 Configuring Contexts
Each context has a popup (right mouse button) menu. Choosing the Define menu option displays the Define Context dialog shown in the next figure. Double-clicking the context also displays this dialog.
3-3
Ixia
The Define Context dialog allows you to select the contexts name, its include-file lines (see Section 3.2.6, ddriver Include File, on page 3-15), and its foreground and background colors. Context names must begin with a letter or underscore. The remaining characters must be letters, digits, and underscores. For further restrictions on context names, see Section 8.1.2, Context Names and Port Expressions on Statements, on page 8-2. The ports on the context can be nailed to any one side. By default, they will be moved from side to side as the context is moved on the canvas. Nailing all ports to a side takes effect only for currently defined ports. Any ports defined subsequently will be floating unless specifically nailed to a side. When the include file is read by ddriver, the include-file lines in each contexts dialog are sent to that context, irrespective of any default context statements (see default context on page 8-32). Contexts can be resized by dragging their corners. This feature accommodates long names and large numbers of connections. By default, contexts snap to a grid when they are moved or resized. This facilitates lining them up. Snapping to the grid can be disabled using the Edit>Snap to Grid menu option. You can duplicate contexts by selecting the Edit>Duplicate menu option, or delete contexts by selecting the Edit>Delete menu option. The Duplicate and Delete options are also available on the contexts popup menu.
3-4
Ixia
For contexts in the Coprocessor domain, the Define Context dialog is slightly different in that two extra fields are displayed: The Slot(s) field is used to attach a context to a particular board. This is useful when the program cannot determine automatically by means of connected board-port or other connected contexts. The Define Context dialog in the next figure shows that context MyContext is selected to run on the board in slot 3. The Processor(s) field is used to attach a context to a particular processor as supported by the board type. The default is set to 1. If Processor(s) is set to a number other than 1 and the board does not support it, when ddriver is run you receive a warning message stating that the processor number chosen is not supported and the context will instead be run on processor 1.
Contexts in the Coprocessor domain can also be configured to run on multiple slots or processors by setting the Slot(s) and/or Processor(s) field to either a comma-separated list or a dash-separated range.
3-5
Ixia
Some examples of valid slot lists: 1,2,3 - Slots 1, 2 and 3 1-3 - Slots 1, 2 and 3 $BOARD(1-3) - Slots determined by $BOARD1, $BOARD2, $BOARD3
Some examples of valid processor lists: 1,2 - Processors 1 and 2 1-2 - Processors 1 and 2 1-5 - Processors 1, 2, 3, 4, and 5 $PROC(1-2) - Processors determined by $PROC1, $PROC2
The following Launcher diagram and Define Context dialog show that context MyContext is selected to run on two boards: one in slot 1 and one in slot 2.
3-6
Ixia
To distinguish between each multi-process context, the context name defined by the Context name field is appended by _<num> with num always starting from 1. For the diagram as shown, there would then be one context named MyContext_1 running on slot one with two board connections to ports 1 and 2 on slot 1; and, one context named MyContext_2 running on slot 2 with two board connections to ports 1 and 2. Building on this example, if the Processor(s) field in the above diagram is changed to be a list (for example, 1-2), the context naming would be as follows: MyContext_1 - running on slot 1, processor 1 with two board connections to ports 1 and 2 on slot 1 MyContext_2 - running on slot 1, processor 2 with two board connections to ports 1 and 2 on slot 1 MyContext_3 - running on slot 2, processor 1 with two board connections to ports 1 and 2 on slot 2 MyContext_4 - running on slot 2, processor 2 with two board connections to ports 1 and 2 on slot 2
Include-file lines for a multi-process context defined in the contexts dialog that do not specify a specific context name are broadcast to each multi-process context. To send an include-file line to a particular multi-process context, the correct generated name must be used. Examples for the diagram shown: {1}add display - sent to port 1 on both MyContext_1 and MyContext_2 {MyContext_1.1}add display - only sent to port 1 on MyContext_1 Importing and Exporting Context Port Information
3.2.3.3
The Launcher can import and export port information files for a context. This feature allows the Launcher to use the same port information files that CATTgen can import/export (for more information on this feature, please see the CATTgen User Manual [6]). It allows you to easily use the same port/protocol/variant information in the .ppv files without having to enter the port information manually.
3-7
Ixia
To import port information, click the Import button in the Define Context window and select a source .ppv file. Once the .ppv file is selected, the port information from the file is imported and the endpoints in the context are updated with the port/protocol/variant information. To export port information, click the Export button and select a destination .ppv file. Port information for all the endpoints in that particular context is written into this file. This file can now be imported into a CATTgen file. 3.2.4 Creating and Configuring Connections 3.2.4.1 Creating Connections
There are five types of connections and ports: Internal connections are connections between contexts executing on the same Coprocessor board. Interboard connections are connections between contexts executing on different Coprocessor boards. These are shown in the Launcher as a line with a break in the middle. UNIX-device connections are connections to standard UNIX devices Board ports are connections between a context executing on a Coprocessor board and a physical interface port. Interboard ports are connections between a context executing on a Coprocessor board and a physical interface port that resides a
3-8
Ixia
board in a slot other than the Coprocessor board itself. This is used by boards with m500 mesh backplane connections. There are some restrictions on the allowable connections: Only workstation contexts may have UNIX-device connections. Only Coprocessor-board contexts may have board ports. Interboard connections are only allowed between PPCI boards or between m500 boards. They can be made between both the same and different board types (that is, mCI(ATM) and mCU(5), mCU(5) and cBC, mCU(5) and cBC+, PPCI(9000) and PPCI+(9051)). Some old revisions of mCI(9200) boards may not be supported (prior to Rev i, but Rev f is supported). Interboard ports are only allowed between boards capable of using the m500 mesh backplane interface (mCI(ATM), mCU(2), mCU(5)/mCU5E, mPI(OC3), mPI(Ethernet), and mPI(STM)). Connections between a single-process context and a multi-process context are not allowed when both contexts are on a Coprocessor board.
Contexts also have the following three limitations with regard to the number of connections: A single context may have up to 64 connections. The sum of all connections from all Coprocessor contexts on a Coprocessor CPU connecting directly to workstation contexts cannot exceed 32. On the mCU(5)/mCU5E, the maximum number of other Coprocessor CPUs that each Coprocessor CPU can connect to is 90. On all other m500 and PPCI boards, the maximum number of other Coprocessor CPUs that each Coprocessor CPU can connect to is 42. This limit does not apply directly to the number of interboard connections, because multiple interboard connections between the same two Coprocessor CPUs only counts as one.
Ports within a context are automatically assigned port numbers as connections are created. These can be changed (see Section 3.2.4.2, Configuring Connections, on page 3-10), but the auto-numbering generally produces the desired numbers in the first place if ports are created bottom-up: starting with the board ports and proceeding up the canvas.
3-9
Ixia
Select internal connections either by selecting Create Internal Connection from a contexts popup menu or by pressing the middle mouse button in a context. The context at the other end of the connection is selected by clicking in that context. Connections can be created between two ports of the same context. Create Interboard connections by selecting Create Interboard Connection from a contexts popup menu. Create UNIX-device connections by selecting Create Unix-device Port from a contexts popup menu. Create Board-port connections by selecting Create Board Port from a contexts popup menu. Create Board-port connections by selecting Create Interboard Port from a context popup menu. You can switch between Internal Connection and Interboard Connection, or Board Port and Interboard Port using the connection popup menu, activated using the right mouse button pressed while the cursor is over the connection. Connection endpoints of all types (context ports, UNIX-device ports, and board ports) require configuration after being created. UNIX-device and board ports display question marks, and context ports are displayed in red to indicate that information must be filled in. Connections of all types are redrawn automatically as contexts are moved and resized. Interboard connections use the host PCI bus except when both ends are on an mCU(9205) Coprocessor CPU when the mesh backplane is used. 3.2.4.2 Configuring Connections
Configure connection endpoints of all types (context ports, UNIX-device ports, and board ports) either by selecting Define from their popup menu or by double-clicking them. This invokes a Define Endpoint dialog appropriate to the type of endpoint.
3-10
Ixia
For context ports:
This dialog allows the protocol and variant to be specified for the port. Specifying the protocol is mandatory. The variant defaults to 1. The protocol name can be either typed into the entry field or selected from the fields drop-down list. Once a protocol has been specified, the port number in the context is displayed in black. The Variant drop-down list is enabled when the protocol has been specified. If the protocol is embedded within other protocols (carriers) and has a multi-part variant number (-Va,b), the variant entry is divided into multiple entries where the variants of the carrier protocol can also be specified.
The sequence of the entries is in the same -Va,b order as specified by the protocol manual. The drop-down list for the carrier protocol variant shows the carrier name and its variants. The drop-down list item that does not show any protocol name is the variant entry of the selected protocol. If the carrier protocol is optional, it is indicated by enclosing the drop-down list within square brackets.
3-11
Ixia
If the Edit>Auto Fill Port Info toggle option has been enabled, and if the opposite port on the internal connection is currently blank, it is filled in automatically with the same protocol and variant as specified for this port. Note that for some protocols, the port protocol and variant info may be different on each end of the internal connection. Alternatively, if you would like the same port information on the other side of the internal connection, you can copy and paste the port information into any other port. The View Manual button is enabled if a corresponding protocol manual is found. The default document viewer is KPDF. To override this default, set the DCT2000DOC_READER environment variable to invoke your preferred document viewer. See Section 3.2.5, Associating Context Ports to Board Ports and Interboard Ports, on page 3-15 for a description of the Associate with Board Port button. For UNIX-device ports:
This dialog allows the UNIX device number to be specified. For board and interboard ports:
3-12
Ixia
This dialog allows the board number and port number to be specified. For interboard ports, the Slot number must be different from the Slot number in the Define Context dialog. NOTE 1: All board ports or interboard ports on one context must be assigned to the same slot number. If the slot number for a port is changed, any other board ports on that context are automatically updated accordingly. NOTE 2: For interboard ports across all contexts on a single mCI(ATM), there is an additional restriction that all interboard ports on that mCI(ATM) board must connect to a single mPI board. However, many different mCI(ATM) boards may have interboard ports to a single mPI. NOTE 3: For interboard ports on a single mCU(5)/mCU5E, there is an additional restriction that all interboard ports on that mCU(5)/mCU5E must connect to a single mPI/mPIE. Many mCU(5)/mCU5E boards may have interboard ports to a single mPI/mPIE, and a single mCU(5)/mCU5E may have many interboard connections to other mCU(5)/mCU5E boards. The following example shows an interboard port between an mCI(ATM) in slot 3 connected via the mesh to an mPI(Ethernet) board in slot 5:
3-13
Ixia
Delete connections by selecting Delete from the popup menu on the connection itself (not on the endpoint). For context ports where a single-process context in the workstation domain is connected to a multi-process context in the Coprocessor domain:
This dialog shows the field Port Start, which is the first port number for connections to the multi-process contexts MyContext port number 4. The number of boards on which MyContext is set to run determines the end of the sequentially generated range. For the diagram as shown, port 3 of context MyCntrl is connected to port 4 of MyContext_1 and port 4 of context MyCntrl is connected to port 4 of MyContext_2. If the slot list is changed for MyContext, the port ranges for MyCntrl are regenerated automatically. The remaining fields Protocol and Variant are the same as described for normal context ports. If Associate with Board Port from the port dialog as shown is set to board port 1-2/2, an association is created between port 3 of MyCntrl to port 2 on the board in slot 1 and another association is created between port 4 of MyCntrl to port 2 on the board in slot 2. See Section 3.2.5, Associating Context Ports to Board Ports and Interboard Ports, on page 3-15 for more details on the Associate with Board Port button.
3-14
Ixia
3.2.5
Associating Context Ports to Board Ports and Interboard Ports Occasionally it is necessary to associate an arbitrary context port with a board or interboard port, so that the context can access the boards hardware. This technique is used, for example, to read the discarded-frame counter or to turn the codec on. The association is made using the Associate with Board Port button in the context ports Define dialog. This displays a second dialog which shows any existing association and lets you choose a new one.
NOTE: For multi-process context ports and single-to-multi-process context ports, the associated board port setting applies to all affected ports. 3.2.6 ddriver Include File Edit the ddriver include file by selecting Ddriver>Edit Include File. This invokes a dialog showing the lines of the file. The include-file lines of each context appear, interspersed with blank lines. You can use the blank lines to type new lines into the file, lines that are not associated with any context. The per-context lines appear in gray, indicating that they cannot be edited in this dialog. However, double-clicking on a contexts lines invokes the contexts Define Context dialog, allowing the lines to be edited. The contexts lines appear in the include file in top-down order according to the contexts position on the canvas. The order of contexts at the same height is indeterminate.
3-15
Ixia
The include file itself is considered an internal interface between the Launcher and ddriver. The Launcher creates the file in /tmp, passes it to ddriver, and then deletes it. 3.2.7 ddriver Log File Specify the log file to be created by the ddriver session by selecting Ddriver>Specify Log File. If you do not specify a filename, no log file is created by the ddriver session. 3.2.8 System Configuration File Specify the IxCatapult system configuration file by selecting Ddriver>Specify Sysconfig File. Selecting this option displays a dialog in which you can enter the filename. If you do not specify a filename, the default ${DCT2000PATH}/.sysconfig is used. You can edit the system configuration file by clicking the Launch IxCatapult sysconfig button in the dialog. For more information, please refer to Chapter 2, Configuring an IxCatapult Session. 3.2.9 Sector Configuration File For IxCatapult LTE UE testing, specify the sector configuration file (.sectorCfg) associated with a sector by selecting Ddriver>Specify Sector Config File. Selecting this option displays a Choose SectorConfig File dialog in which you can enter the filename. Sector configuration files are edited using the Configuration Editor application. To launch the Configuration Editor, click the Launch IxCatapult configEditor button in the Choose SectorConfig File dialog. For more information on sector configuration files, please refer to the IxCatapult LTE UE Simulation API Manual [3] and the Configuration Editor User Manual [4]. 3.2.10 Workstation Data Heap Memory Size Currently, each session is allocated 12MB of data heap for workstation contexts. Should a larger size be desired, you can select it from a set of predefined choices by selecting Ddriver>Specify WS Data Heap Memory Size. The available sizes include 12MB, 24MB, 48MB, 96MB, and 192 MB.
3-16
Ixia
3.2.11
m500 Data Heap Memory Size Processors in the mCU5 can transmit and receive frames between them over the mesh much faster than mCI-2s. This can result in the CPUs running out of heap memory if these frames are buffered in protocol stacks. State machines like SCTP will buffer frames if the peer side is slow or when connections to peers are lost. There are two possible solutions: (1) Distribute frame processing/buffering load to multiple processors. (2) Check for DCPL variable &available_memory to determine the remaining memory and stop or send an indication to the source that causes this frame processing backlog.
3.2.12
Display Format By default, messages are displayed in a ddriver session in DCPL. The Ddriver>Display Format option allows other display formats to be selected. Currently the only alternative format supported is ASCII (ipprim). Selecting this option causes text-based protocols carried on top of ipprim (for example, HTTP or SIP) to be displayed in plain ASCII up to the first non-TEXT character per RFC 2616.
3.2.13
Running ddriver from the Launcher Once the ddriver session has been completely described, run it by selecting Ddriver>Run. This invokes ddriver as a separate window. There are two shortcuts for the Ddriver>Run option: the Control-R key and the Play button. While ddriver is running, the Launchers Run and Exit buttons are grayed out and inactive. You must exit the ddriver session before running another session or exiting the Launcher. The ddriver command can be displayed by selecting Ddriver>Show Command. This can be useful for verifying the ddriver command before executing it.
3.2.14
Running ddriver as a Batch Job Once the ddriver session has been completely described, you can use the Ddriver>Batch Job option to manage the run as a batch job. You can specify a relative or an absolute starting time; you can check how much time is remaining before it starts a run; or, you can cancel the batch job.
3-17
Ixia
3.2.15
Reading and Writing Files A ddriver session description, that is, the contents of the Launcher canvas, can be written to a file by selecting File>Save or File>Save As. These files have the extension .lch automatically appended to their names. Read existing files by selecting File>Open.
3.2.16
Importing Files Launcher files can be merged by using the Import file feature. Only context and connection information is merged with the current Launcher definitions.
3.2.17
Printing the Canvas You can print an image of the canvas to either a printer or a file by selecting File>Print. A dialog will appear, allowing you to set the following options.
Print To Either a printer or a file. If printer is selected, the print command must be specified (default is lpr). If file is selected, a file name must be specified. Files are printed in encapsulated postscript format. Select the size of the paper to be used in the printer. Specify a title for the document. If no title is desired, leave the field empty. Either portrait or landscape. Number of copies to be printed.
Page size Title Page Orientation Copies
3-18
Ixia
The Print Dialog also includes a diagram of the page to be printed. The white rectangle represents the paper, and the yellow rectangle represents the printed area. The printed area can be positioned on the paper by clicking and dragging it. It can also be resized by clicking and dragging the corners. 3.2.18 Managing the Library of Contexts Each installed IxCatapult system has a single library of predefined contexts, which can be edited by the user(s). Copy contexts in the canvas to the palette by selecting Copy to Library from the Edit menu. The contents of the palette may be written to the library by selecting File>Save Library. The palette displays only contexts whose executable files exist in the $DCT2000PATH directory, to avoid cluttering the palette with state machines supplied by Ixia but not installed by individual customers. So if you add a context to the library, you should also create a .ws and/or .ppci file for it in $DCT2000PATH. 3.2.19 Interfacing with Support Tools The following IxCatapult utilities and applications may be invoked from the Tools menu. In some cases, you will be prompted to supply additional information such as a protocol and a variant needed by the tool. CATTgen StatsView DFB (DCPL Frame Builder) RTBL (Routing Table Builder) for MTP3, SCCP, SUA, M2UA, and M3UA LogViewer. By default, this tool will view the log file specified with the Ddriver>Specify Log File option. If no log file is specified, the user is prompted to enter a log file name. Tail Raw Log. This tool uses tail to display the log file specified with the Ddriver>Specify Log File option. This feature only works
3-19
Ixia
when a ddriver session is running, and does not reset if the ddriver session ends then restarts. QoS Client (GUI application for displaying PESQ analysis results) WAV Converter (GUI application for encoding speech files used for PESQ analysis) Video Sample Converter (GUI application for extracting the video data from .mpg sample files) Configuration Editor (GUI application for editing IxCatapult configuration files)
3.2.20
Viewing Manuals Various IxCatapult manuals may be viewed by invoking the Manuals menu. The default document viewer is KPDF. To override this default, set the DCT2000DOC_READER environment variable to invoke your preferred document viewer.
3-20
Ixia
3.2.21
Setting Preferences You can change colors and text attributes by selecting Edit>Preferences. This invokes the Preferences dialog window shown below.
3.2.22
Command-Line Parameters The launch command accepts the following command-line parameters. NOTE: For more information on the CATTgen- and CATTcontroller-related items referenced below, please see the CATTgen User Manual [6]. -A<num> This parameter causes the display process to show messages in an alternative format to DCPL. Currently the only format supported is ASCII/ipprim (specified with -A1), which allows text-based messages carried over ipprim to be displayed in plain ASCII up to the first non-TEXT character per RFC 2616.
3-21
Ixia
-a [file.lch] This parameter causes the Launcher to read file.lch during initialization rather than starting with an empty canvas. -ac This parameter forces CATTcontroller to automatically continue past the Interface Configuration window. -bc [context] Use this parameter with the -bf and -a parameters. It designates a context that will use the batch files passed to it at run time. It is intended to be used with CATTgen-generated executables. This parameter cannot be used with the -S, -o, or -c parameters. -bf [batchfile.pfl] Use this parameter with the -bc and -a parameters. It passes a CATTgen batch file to a designated executable, via the -bc parameter. It is intended to be used with CATTgen-generated executables. This parameter cannot be used with the -S, -o, or -c parameters. -c [configfile] This parameter is passed to ddriver and causes ddriver to use configfile as its system configuration file; otherwise, the configuration file specified in the Launcher file is used. This parameter must be used with the -nw parameter. -cc [context] This parameter specifies the context that will use the CATTgen interface configuration file (.icf) specified with the -cf parameter. -cf [interfaceconfigfile.icf] This parameter passes the specified CATTgen interface configuration file (.icf) to a designated executable, specified with the -cc parameter, when starting the run. -ddl [file.lch] This parameter directs the ddriver command output to standard-out. No window is created. -h This parameter displays help for the launch command-line parameters.
3-22
Ixia
-H This parameter displays help for the launch command-line parameters. -nw Use this parameter with the -a parameter. It causes the Launcher to run ddriver without displaying the Launcher window. -o [logfile] This parameter is passed to ddriver and specifies that the log of the ddriver session be written to logfile.out. The .out filename extension is automatically appended if not supplied. Logging can also be controlled at run time by the user or by scripts, using the write and write stop DCPL statements (see write on page 8-27 and write stop on page 8-28). This parameter must be used with the -nw parameter. -r Use this parameter with the -a parameter. It causes the Launcher to display its own window and run ddriver immediately. -rr HH:MM Use this parameter with the -a parameter. It causes the Launcher to start a timer. The timer duration is specified as HH in hours and MM in minutes from now. When the timer expires, it will run ddriver immediately. -S This parameter is passed down to ddriver causing ddriver to communicate with the user using standard UNIX input and output rather than using a separate graphical window. It overrides the Ddriver>Use Standard I/O option in the Launcher. This parameter must be used with the -nw parameter.
3-23
Ixia
3.2.23
Running the Launcher from a Makefile Device, port, and board numbers can be references to environment variables instead of numbers, as shown in the following illustration.
This allows the port numbers to be defined in a makefile. For example, the makefile might include the following lines:
PORT1 = 5 PORT1=$(PORT1) launch -nw -a myfile.lch
The assignment in the second line copies the makefile macro PORT1 to an environment variable of the same name. NOTE: It is generally preferable (and much easier) to run the Launcher from a makefile than to run ddriver directly from the makefile. 3.2.24 Limitations NOTE: For additional information on Launcher limitations, see Section 3.2.4.1, Creating Connections, on page 3-8, Section 3.3.7.2, Workstation Contexts, on page 3-35, and Section 3.3.7.3, Download Contexts, on page 3-35. 3.2.24.1 Running the Launcher using xterm on a PC The use of xterm running on a PC to display the Launcher GUI is not officially supported. Problems displaying the GUI could arise when fonts, larger than expected by the GUI, are used by the PC. However, in many cases the GUI will display without any problems.
3-24
Ixia
3.3
ddriver
ddriver is the command to run the IxCatapult system. This section describes how to create ddriver command lines. However it is generally easier to use the IxCatapult Launcher (see Section 3.2, IxCatapult Launcher, on page 3-2) for this purpose. The ddriver command accepts the following command-line parameters. -A<num> This parameter is passed to the display process by ddriver and causes the display process to show messages in an alternative format to DCPL. Currently, the only format supported is ASCII/ipprim (specified with -A1), which allows text-based messages carried over ipprim to be displayed in plain ASCII up to the first non-TEXT character per RFC 2616. -B This parameter bans keyboard input, that is, causes it to be ignored. -b [slot1.]port1 [,[slot2.]port2 ...] This parameter creates one or more ports in the current context (which must reside on a Coprocessor board) and specifies that they are connected to port1 (and port2, and so on) of the board. If the optional slot1 parameter is included, an interboard port is created between the slot that the current context is running on (specified by the -D parameter) and the slot of the physical port. NOTE: Interboard ports are only supported on boards that have an m500 mesh backplane interface. Also, the various slot parameters must all refer to the same interboard slot for mCI(ATM) and mCU(5)/mCU5E boards. -C name This parameter creates a context named name and makes it the current context for later -b, -D, -d, -p, and -s parameters. The contexts ports are created by the following -b, -d, and -p parameters, in numerical order. That is, the first such parameter creates the contexts port {1}, the second creates {2}, and so on. -c configfile This parameter causes ddriver to use configfile as its system configuration file; otherwise the default file ${DCT2000PATH}/.sysconfig is used. File names that are not
3-25
Ixia
complete path names (that is, do not begin with a /) are interpreted as being in the current directory. System configuration files are created using sysconfig (see Chapter 2, Configuring an IxCatapult Session). -D board[,processor] This parameter specifies that the current context resides on Coprocessor board number board on (optionally) a particular processor. For boards that do not support multiple processors, ddriver will generate a warning if it is set to a value other than 1. If processor is not set, it defaults to 1. For a given context, this parameter must precede any port specifications using the -b or -p parameters. -d device1 [,device2 ...] This parameter creates one or more ports in the current context (which must reside on the workstation) and specifies that they are connected to UNIX device device1 (and device2, and so on). -h board1[,processor],port1 This parameter is only valid following a -p parameter. It specifies that the -ps port is associated with port1 of processor on board1. (See Section 3.2.5, Associating Context Ports to Board Ports and Interboard Ports, on page 3-15.). If processor is not set it defaults to 1. -i includefile This parameter causes the lines of includefile.inc to be read as though they were typed at the keyboard, during ddriver initialization. The .inc filename extension is automatically appended if not supplied. -m protocol This parameter specifies protocol as the protocol to be sent and received on all following context ports (-b, -d, and -p parameters) until the next -m parameter. -o logfile This parameter specifies that the log of the ddriver session be written to logfile.out. The .out filename extension is automatically appended if not supplied. Logging can also be controlled at run time by the user or by scripts, using the write and write stop DCPL statements (see write on page 8-27 and write stop on page 8-28).
3-26
Ixia
-P heap size This parameter specifies the amount of data heap to be made available to the workstation contexts. By default 12MB of data heap memory is created. The available settings are 12, 24, 48, 96 or 192. -p This parameter has the following syntax:
-p conn1 [,conn2 ...]
This parameter creates one or more ports in the current context, and specifies that they are endpoints of internal connection conn1 (and conn2, and so on). Connection numbers must be in the range 1 to 100,000. However, they need not start at 1 or be sequential. Each connection number must be used exactly twice, that is, it must have two ends. -R [accuracy] This parameter specifies that ddriver should periodically resynchronize the PPCI clock with the workstation clock for improved timestamp accuracy. An optional value specifying the requested accuracy can be provided in units of milliseconds. If no value is specified, the default value of 250 ms is used. This feature can be enabled using the CATT_SYNC_PPCI_TIME environment variable:
setenv CATT_SYNC_PPCI_TIME [accuracy]
The computed PPCI drift value will be reported in the log files. PPCI timestamps will not be adjusted at run time. Instead, dctprint will adjust the timestamps as part of post-processing the log file. -S This parameter causes ddriver to communicate with the user using standard UNIX input and output, rather than using a separate graphical window. -s script This parameter specifies that script should be run in the current context at ddriver initialization. If script is not a complete pathname (that is, it does not begin with a /), it is looked for first in the current directory, then in $DCT2000PATH , and then in $PATH.
3-27
Ixia
-V variant This parameter specifies that variant variant of the current protocol is to be sent and received on all following context ports (-b, -d, and -p parameters) until the next -V parameter. If no -V parameter is specified, the default variant is 1. -x file.sectorCfg This parameter specifies the name of a file containing information used to configure Sector Card Sets in LTE systems. Sector configuration files are edited using the Configuration Editor application [4]. See Section 3.2.9, Sector Configuration File, on page 3-16. -y Sector1,Sector2,...,SectorN This parameter specifies the names of the LTE sectors associated with the port named by the following -p parameter. Sectors are named in the sector configuration file, edited using the Configuration Editor application [4]. See Section 3.2.9, Sector Configuration File, on page 3-16. 3.3.1 Sample ddriver Command Line Following is an example of a ddriver command line:
ddriver \ -Csaalnni -msaalnni_sscf -ssaalnni \ -D1 -b1,2 -p1,2 \ -Cmtp3 -msaalnni_sscf -slayer3 -p1,2 \ -mbisup -p3,4 \ -Cisup1 -mbisup -p3 -Cisup2 -mbisup -p4
3.3.2
Re-Routing ddriver Output In the C-shell, you may use the following to separate stderr and stdout from ddriver:
(ddriver [ddriver options] > outfile) >& errfile
In this example, any output from ddriver that would normally be displayed on stdout would be diverted to the file outfile, and any message that would normally be displayed on stderr would be diverted to the file errfile. The use of outfile and errfile is arbitrary, so you can use any filenames you wish. If the ddriver command line is long and inconvenient to place on the command line, the ddriver command can be placed in a shell script and executed in a similar manner as above. For example:
(shellscript > outfile) >& errfile
3-28
Ixia
where shellscript is the name of the shell script that contains the ddriver command. 3.3.3 ddriver Windows Unless you specify the -S command-line parameter, ddriver opens a single graphical user-interface window. By default all display and user input use this window. However, other windows may be opened using the view statement (see view on page 8-27). Each such window is devoted to a single context. Any display information from that context appears in the window, and all DCPL statements typed into the window are assumed to refer to that context. 3.3.4 Main Window in Detail Mode The main ddriver window in detail mode appears as follows.
3-29
Ixia
The window contains the following control buttons: The Status button displays the status of the physical interfaces used by the session. The Commands button displays a window showing the commands typed during the session. Double-click a command to retrieve it to the command-input line. The Brief Mode button switches what is displayed in the main window. In brief mode, only counts of messages sent and received are displayed. The first time in a session that the Brief Mode button is pressed, the Context Selection window is displayed. The window allows users to select contexts whose messages counts are to be displayed. The Clear Screen button clears the display area. The Freeze button freezes the display, so that it can be read more easily. It does not stop the operation of the session. The screen may also be frozen/unfrozen by using the right mouse button. This will display a menu from which you may choose to either freeze or unfreeze the display. After the display is unfrozen, a message will be shown indicating the number of lines which were not displayed due to the display being frozen. The Exit button exits ddriver.
Enter DCPL statements on the Command: line at the bottom of the window. The line above it is where prompts from prompt statements (see prompt on page 8-17) appear.
3-30
Ixia
3.3.5
Main Window in Brief Mode The main ddriver window in brief mode appears as follows.
The window contains the following control buttons: The Contexts menu item displays the Context Selection window. The Detail Mode button changes what is displayed in the Main Window. In detail mode, messages are displayed. The Zero Counts button sets messages counts of all contexts, displayed or not, to 0.
All other buttons and menu items have the same functionality as in detail mode.
3-31
Ixia
The Context Selection window allows users to select which contexts should have message counts displayed. The Context Selection window appears as follows:
The first time in a session that the Brief Mode button is pressed, the Context Selection window will be displayed. Thereafter, a user may modify the contexts shown in brief mode by selecting the Contexts menu item. The Select All button selects all contexts. The Deselect All button deselects all contexts. The Cancel button closes the Context Selection window. The OK button applies the changes made in the Context Selection window.
3-32
Ixia
3.3.6
Control Characters In addition to typing DCPL statements, you can type the following control characters.
Character Â ^B ^C ^D Ê ^F ^H ^L ^P Û ^W ^Z up/down page Meaning Redisplay last command, or move input cursor to start of line. Enter brief mode. Exit ddriver. Enter detail mode. Move input cursor to end of line. Freeze / resume display. Backspace. Clear screen. Redisplay previous command. Erase input line. Erase previous word of input line. Zero frame counts. When cursor is over the y-bar, freezes the screen and moves the display up/down one page. When cursor is over the y-bar, freezes the screen and moves the display up/down one line. When cursor is over any part of a window, other than the y-bar, redisplays previous command.
up/down arrows
up arrow
NOTE: In addition to using the Exit button or ^C character to exit the ddriver window, the UNIX kill command can also be used as with any other UNIX process. However, caution is recommended while using signal 9/KILL with the kill command. Killing ddriver with a kill -9 command will not delete any temporary files, usually generated in the /var/tmp/.SHMD directory, when ddriver was started. If ddriver crashes on signal 9 or the power is shut down while running ddriver, you may need to clean these files manually.
3-33
Ixia
3.3.7
Limitations The IxCatapult system supports large numbers of contexts and ports. However, there are several limitations to note. 3.3.7.1 Memory
PowerPCI The PowerPCI board is available with two memory sizes, 64 MB and 128 MB. The board with 64 MB provides 32 MB for user scripts, with the remaining 32 MB allocated for frame data structures. The 128MB board has 64MB for user scripts. PPCI+ The PPCI+ board is available with 512 MB, out of which 245 MB is reserved for frame data structures and 256 MB is reserved for user scripts. The remaining is used for internal system software. cBC The cBC board is available with two memory sizes, 64 MB and 128 MB. The board with 64 MB provides 32 MB for user scripts, with the remaining 32 MB allocated for frame data structures. The 128MB board has 64MB for user scripts. cBC+ The cBC+ board is available with 512 MB, out of which 245 MB is reserved for frame data structures and 256 MB is reserved for user scripts. The remaining is used for internal system software. mCI(ATM) The mCI(ATM) board is available with 512 MB. The board provides 154 MB for user scripts (80 MB on processor 1 and 74 MB on processor 2), with 320 MB allocated for frame data structures. The remaining is used for internal system software. mCU(5)/mCU5E The mCU(5)/mCU5E board is available with a total of 2.5 GB of memory, 512 MB per processor. Each processor provides 248 MB for user scripts and 256 MB for frame data structures. The remaining is used for internal system software. Workstation In the workstation environment, the amount of memory available for scripts is limited by size of swap space, memory usage of other processes and system resource limitations (see ulimit manual page). Each ddriver session requires at least 14.2 MB, plus space for workstation context processes. The amount of memory available may also limit how large that the workstation data heap size can be increased when using the -P parameter with ddriver and/or when setting it using the Ddriver>Specify WS Data Heap Memory Size option.
3-34
Ixia
3.3.7.2
Workstation Contexts
Number of Contexts The maximum number of workstation contexts per ddriver session is limited to 40. Number of Ports Each context can support up to 64 ports. The port-related resources are allocated globally; the IxCatapult system supports between 750 and 1000 ports total for workstation contexts. The lower limit assumes a large number of download contexts and the upper limit assumes no download contexts. 3.3.7.3 Download Contexts
A maximum of 63 download contexts per Coprocessor CPU are supported. A maximum of 2205 download contexts are supported in a single Launcher session. The following steps can be used to estimate a scripts memory requirements. 1. Use the size command to determine the size of the script. For example:
% size sscop.ppci 0 + 225280 + 1119152 = 1344432
Here the memory required is 1,344,432 bytes. 2. Add 65,536 bytes for stack space. In this example the result is 1,409,968 bytes. 3. Because of memory-management constraints, round up to one of: 128K, 256K, 512K, 1MB 2MB, 4MB, 8MB, 16MB, 32MB In this example the size is rounded up to 2 MB. 4. Add up the memory requirements of each script. In this example, 13 copies of the sscop script consume 26MB of available script space. Number of Ports Each context can have up to 256 ports. The port-related resources for the Coprocessor board are allocated globally and the total maximum number of ports per board varies based on configuration. The generally accepted limit is a range of 150 to 180 ports.
3-35
Ixia
3.3.7.4
Message Size
Inter-Context Ports Messages passed between context ports are limited to 16384 bytes including the header that encodes the fields of the message primitive. Unix-Device Ports Messages passed to or from Unix-device ports are limited to 16384 bytes including the header that encodes the fields of the message primitive. Board Ports The size of messages passed to or from board ports is limited by the capabilities of that board. The limit is typically <= 8192 bytes including the header that encodes the fields of the message primitive. 3.3.7.5 Display Truncation
The CATT_MAXDECLEN environment variable sets the maximum length of decoded messages in each line of display information. If the output is truncated but you need to see the whole message, set this environment variable to a value higher than 20000 (the default) before running ddriver. Setting CATT_MAXDECLEN to a value less than 20000 will cause decoded messages in each line of display information to be truncated at the specified value. 3.3.7.6 Display Congestion
Due to the programmable nature of the IxCatapult system, it is possible to configure the system such that CPU, memory, or I/O is overloaded. In the case of an overloaded display, the following system measures are taken: 1. If the display queue exceeds 5000 frames, the following warning is displayed (note that the warning is displayed only one time):
Warning: Display congested. Real-time behaviours of the system can be effected. Please remove display/log on some ports
3-36
Ixia
2. If more than 10% of the Coprocessor's available heap memory is consumed by the display queue, logs are discarded and a warning is displayed each time the system starts discarding display messages. This 10% threshold can be adjusted with the DCPL special variable &display_memory_ratio.
Warning: Memory allocated for Display is full! Please remove display and log on some ports
3.3.8
System Monitor System Monitor is a utility that gives continual reports about the state of the Coprocessor system. It monitors download contexts used in a session and the state of the Coprocessor boards used. 3.3.8.1 Running in Graphical User-Interface Mode
When ddriver is running in graphical user-interface mode, System Monitor is activated from the View menu in the main ddriver window.
The main System Monitor window shows a report on one or more Coprocessor boards. The top few lines display general information about the Coprocessor board, remainder of the screen displays information about individual contexts running on that board. Terminology and detailed explanation of the display is described in more detail in help screens that are accessible from the Help menu. System Monitor output can be logged to a file, this is activated from the File menu in the System Monitor window. Boards to be viewed are selected from the Boards menu, and various monitoring options can be selected from the View menu. A comprehensive documentation describing all menus and options is available from the Help menu.
3-37
Ixia
3.3.8.2
Running in Standard Input and Output Mode
When ddriver is using standard UNIX input and output, System Monitor must be started with a sysmon on interactive DCPL command. ddriver will use standard UNIX input and output when it is started with the -S flag, or Launcher is started with the -S flag, or the Use Standard IO checkbox is selected in the Launcher. The monitor output will be logged into a file called sysmon.log, located in the current working directory. All view options will be enabled except for stack monitoring, memory monitoring and processor monitoring. To disable the Monitor, use sysmon off interactive DCPL command. The sysmon statement replaces the obsolete ppcimon statement. NOTE: Using the sysmon Stack option is a CPU-intensive operation and may have negative impact on execution of load tests. 3.3.9 Error Reporting If a fatal software error occurs on a Coprocessor used by a ddriver session, an error log is generated in the current working directory using the ddriver process id to generate a unique error log file name, catapult_error_<pid>.log. A notification to standard UNIX error is displayed similar to the following: [ddriver]: ERROR: Exception caught on Slot: 2 Coprocessor: 1 Type: Ethernet [ddriver]: Exception in process: UDP_SM [ddriver]: Exception type: Program (0x0700) [ddriver]: Complete exception dump stored in file: catapult_error_14041.log To display the error log information to standard error rather than generating a log file, set the environment variable CATT_LOG_TO_STDERR to 1.
3-38
4
Creating and Decoding Log Files
Contents 4.1 dctprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.2 out2csv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Ixia
4.1
dctprint
The dctprint program produces a decoded version of the specified input log file. Log files are created using the write and gwrite statements (see write on page 8-27 and gwrite on page 8-20). It also sorts the log by timestamp. NOTE: Because of the distributed nature of the ddriver architecture, events are sometimes logged slightly out of sequence. The syntax of the dctprint command is as follows:
dctprint [-u] [-f] [-c] [-a] [-l] [-z] [-A<num>]
An example dctprint line is as follows:

dctprint <trace.out >trace.dct
4.1.1
Command-Line Parameters dctprint reads from standard input and writes to standard output. It accepts the following command-line parameters. -u This parameter causes dctprint to leave the file unsorted. NOTE: By default, dctprint does not wait for the entire log file to exist before it begins sorting and displaying it, but it assumes that each line is no more than 100 lines out of place. -f This parameter causes dctprint to wait for the entire log file to exist and then sort it completely. -c This parameter suppresses the Clocking log that may appear in some log files as a result of clock synchronization. See Chapter 12, Intermodule Timing. -a This parameter causes timestamps of each line to be displayed in the absolute time rather than the time relative to when the script starts executing.
4-2
Ixia
-l This parameter causes timestamps of each line to be displayed relative to the start of the log file. It is intended to be used with gwrite or write statements that include the timestamp option. -z This parameter allows you to read the value of an enumeration text string as an enumeration number. (The information elements are represented as integers.) For example, if the following message has been decoded as:
...payloadCRC_PresenceIndicator=cRC_Included ul_FP_Mode=silent ...
Using the -z parameter the result is as follows:

...payloadCRC_PresenceIndicator=0 ul_FP_Mode=1
-A<num> This parameter causes dctprint to print messages in an alternative format to DCPL. Currently, the only format supported is ASCII/ipprim (specified with -A1), which allows text-based messages carried over ipprim to be displayed in plain ASCII up to the first non-TEXT character per RFC 2616. 4.1.2 Environment Variables The CATT_MAXDECLEN environment variable sets the maximum length of the decoded message in each line of output. If the output is truncated but you want to see the whole message, set this environment variable to a value higher than 20000 (the default) before running dctprint. Setting CATT_MAXDECLEN to a value less than 20000 will cause the output to be truncated at the specified value. 4.1.3 Example This section provides an example of running dctprint on an input data file (log.out) using the following command:
${DCT2000PATH}/dctprint < log.out > log.dct
Input data file (log.out):

September 18, 2002 11:14:56.3403 a/// c1 tm 17.7331 value of 1 is 1 (#1) a/// c1 tm 19.2979 value of 1 2 is 1 (#1) a/// c3 tm 19.2981 2 syntax error near: 2 a/// c0 tm 22.6080 6 &Foo: variable not created a/// c1 tm 29.7535 value of 1 is 1 (#1) a.1/islp// s tm 32.5981 l $616a736468616a73686464
4-3
Ixia
b.1/islp// r tm 32.5981 l $616a736468616a736864640000000000000000000000000000000000000000000 0000000000000000000000000000000 a/// c2 tm 33.2127 hello a/// c1 tm 34.4989 value of 1 is 1 (#1)
Output data file (log.dct):

00000.0000 c September 18, 2002 11:14:56.3403 00017.7331 {a} c value of 1 is 1 (#1) 00019.2979 {a} c value of 1 2 is 1 (#1) 00019.2981 {a} c syntax error near: 2 00022.6080 {a} c &Foo: variable not created 00029.7535 {a} c value of 1 is 1 (#1) 00032.5981 {a.1} islp S free ('ajsdhajshdd') 00032.5981 {b.1} islp R free ('ajsdhajshdd',$00000000000000000000000000000000000000000000000000 000000000000000000000000) 00033.2127 {a} c hello 00034.4989 {a} c value of 1 is 1 (#1)
4.2
out2csv
The out2csv program converts the input log file to a comma-separated values (CSV) format. The syntax of the out2csv command is as follows:
out2csv [-h] [-a] [-p]
An example out2csv line is as follows:

out2csv < trace.out > trace.csv
4.2.1
Command-Line Parameters out2csv reads from standard input and writes to standard output. It accepts the following command-line parameters. -h This parameter causes out2csv to display the list of command-line parameters. -a This parameter causes the application specific field to be decoded. -p This parameter causes the Protocol Data Unit (PDU) to be decoded. NOTE: The output produced by the -a and -p parameters may be much larger than the original hex string.
4-4
Ixia
4.2.2
Example This section provides an example of running out2csv on an input data file (log.out) using the following command:
out2csv < log.out > log.csv
Input data file (log.out):

NODEB_UE.1/nbap/4/2,$001??==001// s tm 14.5107 l $200c22000b2c000002016a40162c0260010000020780000060076001000007078 000000176400b60016001000001078000000000003b
Output data file (log.csv):

50,14.5107,s,"",1,nbap,"4","","2,$001??==001","","","",l,"$200c220 00b2c000002016a40162c026001000002078000006007600100000707800000017 6400b60016001000001078000000000003b"
log.csv with -a parameter:

50,14.5107,s,"",1,nbap,"4","","L=1 GFC=0 VP=1 VC=65501","","","",l,"$200c22000b2c000002016a40162c026001000002078 0000060076001000007078000000176400b60016001000001078000000000003b"
With the -a parameter, note that 2,$001??==001 is decoded as L=1 GFC=0 VP=1 VC=65501. The PDU is not decoded. log.csv with -p parameter:
50,14.5107,s,"",1,nbap,"4","","2,$001??==001","","","",,"S aal_data_req param_data=[succesfulOutcome_commonTransportChannelSetup_fdd longTransActionId=11 value=[protocolIEs=[fACH_ParametersList_CTCH_SetupRsp=[CommonTrans portChannel_InformationResponse=[commonTransportChannelID=2 bindingID=$01000002 transportLayerAddress=0000000000000000] CommonTransportChannel_InformationResponse=[commonTransportChannel ID=7 bindingID=$01000007 transportLayerAddress=0000000000000000]] pCH_Parameters_CTCH_SetupRsp=[commonTransportChannelID=1 bindingID=$01000001 transportLayerAddress=0000000000000000]]]]"
4-5
Ixia
4-6
5
Compiling DCPL Scripts
Contents 5.1 DCPL Compiler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Ixia
5.1
DCPL Compiler
Ixia Digital Communications Programming Language (DCPL) scripts are compiled using the UNIX command ddc. Use this command also to compile C files, and to link DCPL, C, and .o files into an executable file. The command has the following syntax:
ddc [option ...] file ...
The files parameter can be .d (DCPL), .c, or .o files. The first file is assumed to be the main program; it executes first when the script is executed. In case the .o modules are being used, the corresponding .c files should be present to avoid complaints about the missing .c files. In the absence of the -o command-line parameter, the executable produced is given the name of the first file, with its extension replaced by .ws (for files compiled for the workstation) or by .ppci (for files compiled for a Coprocessor board). For example, the following command produces the file example.ws:
ddc -mtty -p1 example.d
The files parameter can consist of any alphanumeric character (a-z, A-Z, 0-9), and the underscore character (_). No other characters are allowed in filenames to ensure .d (DCPL) files are converted to .c files properly. When compiling a .d (DCPL) file, _file is used as a C function name, and certain characters are not allowed. 5.1.1 Command-Line Parameters The ddc command accepts the following command-line parameters. -C This parameter prevents ddc from deleting the intermediate .c files into which any .d files were translated. -c This parameter prevents ddc from linking the files into an executable; that is, .o files are produced. -D name[=body] This parameter enables a macro to be defined on the command line. If the macro body is not given, the value of the macro is 1.
5-2
Ixia
-d This parameter causes the files to be compiled and linked to run on a Coprocessor board. Without this parameter, they are compiled and linked to run on the workstation. -e This parameter prevents ddc from deleting any intermediate files. -fg++ option This parameter enables the g++ compiler for compiling the generated .c file instead of the default gcc compiler. -h This parameter causes ddc to display the list of command-line parameters. -I dirname This parameter causes ddc to add dirname to the list of directories in which it looks for include files. -L macrofile This parameter causes ddc to load precompiled macro definitions from macrofile, which is assumed to have been produced by the DCPL store statement (see store on page 8-26). -m protocol This parameter causes protocol to be used in encoding protocol-specific DCPL statements on the ports described by the following -p parameters. (A DCPL script can use several ports, with different protocols and variants on each. The -p parameter declares the ports; the -m and -V parameters specify the protocol and variants for them.) The -m parameter stays in effect until the next -m. A -m parameter must be declared prior to the first -p parameter. -O level This parameter causes ddc to optimize compilation. There are three levels in optimization; 1, 2, and 3. Level 0 can be used for no optimization. If no level is specified, the default level is 1.
5-3
Ixia
-o filename This parameter causes ddc to name the executable produced filename, or if used in conjunction with the -c parameter and a single file on the ddc command line causes an object file to be produced with the name filename. It is an error to use both the -c and -o parameters with multiple files specified on the command line. -p nports This parameter declares nports ports for the following file. Several -p parameters can be required to describe the ports in a file if the ports use different protocols and variants. It is an error for a file to use more ports than have been declared for it by the -p parameters. If .o files are created using separate ddc commands and then linked, the same number of ports must be specified in each of the ddc commands. -S This parameter prevents ddc from stripping the symbol table from the executable. -t This parameter causes ddc only to translate .d files to .c files, without compiling or linking the .c files. -V variant This parameter causes variant variant of the current protocol to be used in encoding protocol-specific DCPL statements on the ports described by the following -p parameters. (Refer also to the -m parameter on page 5-3). The parameter stays in effect until the next -V. If no -V parameter is specified, the default variant is 1. -v This parameter causes ddc to emit additional code that will check all DCPL variable references at run time. As array index expressions are evaluated, each is checked to ensure that it is in the valid range for that array. Similarly, port expressions are checked for validity with respect to the number of ports declared for the context in which the script is executing. And all references to string variables are checked to be sure that the variable has been initialized (assigned to). If any of these errors is detected, an error message identifies the faulty variable reference and the ddriver session is terminated. Use of the -v parameter is strongly encouraged for all
5-4
Ixia
but the most performance critical applications, since the scripting errors it detects can be otherwise difficult to diagnose. -W This parameter compiles .c files using the gcc -Wall flag to enable warnings. -Wimplicit This parameter causes ddc to verify that all variables used have been declared using the variable or array keyword. (See Section 8.1.8, DCPL Keywords, on page 8-4.) -X option This parameter enables features of the ddc compiler that are not backwards compatible. The value of option can be: comments - allows nested comment blocks within a DCPL script hash - expands macros before returning the quoted string in a macro parameter # expansion prompt - expands macros in comment/prompt/! statements hex - converts C style hex constants to DCPL style hex, for example, 0x1F to #1F (enabled by default) nohex - disables the -X hex option all - all the above options The -Y group of parameters are used to pass arguments directly to gcc. Note that no spaces are allowed between arguments or within each argument. -Ya,<arg1>,<arg2>,.. This parameter passes the arguments to the assembler. -Yc,<arg1>,<arg2>,.. This parameter passes the arguments to the compiler. -Yl,<arg1>,<arg2>,.. This parameter passes the arguments to the linker.
5-5
Ixia
5.2
5.2.1
Limitations
File Size Although ddc places no limits on the size of the input DCPL script, ddc is not currently largefile aware. Hence ddc cannot access files greater than 2 gigabytes in size. This restriction is also placed on intermediate and output files created by ddc. It is also important that sufficient space is available in /tmp, since the intermediate files are created there.
5.2.2
Line Length A single line of a DCPL script, after macro expansion, should be less than 16 kilobytes long.
5.2.3
DOS Files The ddc compiler does not compile DOS format files. The simple workaround is to use the utility dos2unix. For example:
dos2unix foo_dos.d foo_iso.d
5-6
6
DFB Application
Contents 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.2 DCPL Frame Builder Window . . . . . . . . . . . . . . . . . . . . . . . . 62 6.3 Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.4 Editing the Generated DCPL . . . . . . . . . . . . . . . . . . . . . . . . 64 6.5 Building a Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
DFB Application
Ixia
6.1
Introduction
The DCPL Frame Builder, DFB, is a graphical program that allows you to create protocol messages or protocol templates (when invoked with the -t command-line parameter) easily by displaying the messages, parameters, and fields that are valid at each point.
6.2
DCPL Frame Builder Window

An example of a completed message in the DCPL Frame Builder window is shown in the following figure.
In the DCPL Frame Builder window, the right pane shows the available messages, parameters, and fields at each stage. The left pane shows a graphical representation of the message or template created so far. The bottom pane shows the DCPL message or template created so far. 6.2.1 Mouse Buttons In the left pane, left-click to change the focus of the application to any current element of the frame under construction. This causes the associated grammar to be displayed in the right pane. Right-click in the left pane to display a menu of allowable actions for this element.
6-2
Ixia
DFB Application
In the right pane, left-click to select an item to be added to the frame under construction. Middle-click to perform a super select, which not ony adds the element to the frame but also causes the associated grammar to be displayed immediately. Right-click to display a menu of allowable actions for this grammar item. 6.2.2 GUI Buttons The Clear button clears the message and allows you to start over. The Quit button exits DFB without producing any output. The Apply button writes the DCPL message to standard output and exits DFB. Normally it is useful to redirect the DFB output to a file in order to capture the message. The Encode button (not shown) appears if the -E parameter is specified. It writes the encoded message to standard output and exits DFB.
6.3
Command Line
The DFB command line is:
dfb [-t] [-B] [-E] -mprotocol [-Vvariant]
The -t parameter starts dfb to be used to build a template. This template is used in a DCPL case template statement. See switch on page 8-13. The -B parameter is described in Section 6.4, Editing the Generated DCPL, on page 6-4. The protocol and variant are the protocol name and variant number, as used on the ddc command line. The default variant is 1. The DFB standard input can be redirected to a file that consists of a single line containing a DCPL message of the appropriate protocol and variant (with no preceding port number or context name). In this case DFB displays the message graphically, as though you had created it using DFB. However, DFB is somewhat lenient in its input parsing, so the fact that DFB accepts and displays a message does not guarantee that the message is valid and acceptable to ddc. The -E parameter displays the Encode button. See Section 6.2.2, GUI Buttons, on page 6-3.
6-3
DFB Application
Ixia
6.4
Editing the Generated DCPL

In rare cases, you might want to edit the DCPL output by DFB, for instance, to create an invalid message for negative testing. The -B command-line parameter allows you to do this. It causes the Edit button to appear, as shown below. After creating your message, click Edit to bring up the edit window (as shown in the following figure) with each message field commented. You can edit the DCPL, then click OK to write the result to standard output. When using the edit functionality, be aware that this function sometimes displays an incomplete message. For example, when you have a choice of parameters and do not choose any, no default value is added. This may cause the rest of the message not to be displayed.
The DCPL generated for many protocols is quite complex. A thorough knowledge of the protocols encoding rules helps in editing it successfully.
6-4
Ixia
DFB Application
The Edit DCPL window has an option to search for a text string. The search can be made case sensitive by selecting the Case Sensitive check box. The default search is a case insensitive text based search. The search text is entered in the Search: text box. The figure above shows that the pattern criticality is being searched for. The found text is highlighted on the Edit DCPL window. Click Find Again to repeat the previous search.
6.5
Building a Template
DFB does template building when invoked with the -t parameter. This template is used in the case template statement. See switch on page 8-13. The following applies specifically for template building. The exists keyword is added automatically to any field that does not have a value. This is shown in the bottom DCPL window and in the generated DCPL when you click Apply. Any field that does not have an = associator does not get an exists keyword with this field. This is generally the case for the type and indicator field. The exists keyword also can be explicitly entered as a value for any field.
The figure above shows a field that has an = associator. You can either trap on a value by selecting Compare (the default) and entering the value of the field, or assign the value of the field to a DCPL variable by selecting Assign and entering the name of the variable. An example follows:
acm route=exists cic=>&abc bci=[chrg=100]
This template traps any acm message that has the route, cic, and chrg fields present and that has the chrg value set to 100. Also, the value of the cic field in the received message is assigned to a DCPL variable &abc.
6-5
DFB Application
Ixia
To specify multiple appearance of a field (sample_field for example), either of the following methods can be used depending on what you want to do with your template: The first example traps any message that has the third appearance of sample_field set to value3:
sample_field=exists sample_field=exists sample_field=value3
The second example traps any message that has the first appearance of sample_field set to value1 and has the third appearance of sample_field set to value3:
sample_field=value1 sample_field=exists sample_field=value3
6.6
Limitations
Some protocols contain fields for which no legal values exist. DFB displays them in an attempt to reflect the protocol specification, but they are not intended to be used. Such fields typically are named extension, ie_extension, or protocol_extension. Case templates are limited by the encoder to 80000 bytes. This limit applies to the fully expanded template representation used internally. Any attempt to use templates beyond this limit will prompt the encoder to complain the case template is too long. You can work around this limit by creating two separate templates that can be used sequentially to make the same filtering effect.
6-6
7
TTY Protocol
Contents 7.1 TTY Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 7.2 TTY Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 72 7.3 DCPL Customization for TTY Protocol . . . . . . . . . . . . . . . . . . 78
TTY Protocol
Ixia
7.1
TTY Protocol
The TTY protocol is a means of sending and receiving data via serial lines and UNIX sockets. The TTY protocol can send and receive data via physical ports on the SPARC; TCP, UDP, or RAW IP sockets defined in the UNIX interprocess communication facilities; or PPCI Serial boards. TTY devices are configured using the sysconfig program, as explained in the following section. Also see Section 2.20, UNIX Device Configuration Window, on page 2-53.
7.2
7.2.1
TTY Device Configuration

Physical SPARC Ports A TTY device that uses a physical port is referenced through an associated file, usually located in /dev. Thus, if you wanted to test a piece of serial equipment, you could attach it to a terminal port (for example, ttya) and use the associated file /dev/ttya to access it. sysconfig also allows you to specify the speed (baud rate), parity, flow control, and other characteristics of the physical port that must be known. See the example shown in Figure 7-1. Figure 7-1. TTY Device Configuration - Physical SPARC Ports
7-2
Ixia
TTY Protocol
The TTY protocol cannot be used with sockets configured as Dynamic. Such sockets must be used with the IPPRIM protocol. The devices can then be referred to by their logical numbers (0 through 29). Data is reported back in units of lines. A line is terminated by one of three events: one of the stopper characters being received the maximum frame size (currently 80 characters) being exceeded the maximum delay time since the first character was received expiring
When one of the three events above is encountered, the line is terminated and reported back. The bytes received after this event are not included and are reported when the next event is encountered. An example is provided in Section 7.2.2, TCP/UDP Sockets, on page 7-4. When no framing protocol is selected in the configuration, the above three events determine when the line is reported. However, if a specific framing protocol is selected, each protocol has a specific rule on where the line is terminated. For example, some of the protocols have a parameter in the message that indicates the length of the message. See the individual protocol manuals. In the TTY protocol, characters can be specified in the configuration data as 8 bits without parity or 7 bits with parity (odd, even, mark, space, or none). Seven bits with no parity means 7 bits with dont care parity. Octets containing 7-bit characters are masked with #7f before being compared with the flow control and/or stopper characters specified in the configuration data. The stopper characters, as well as the maximum delay time, are accessible through run-time variables, described in Section 7.3, DCPL Customization for TTY Protocol, on page 7-8. Characters received in violation of the specified parity are suppressed.
7-3
TTY Protocol
Ixia
7.2.2
TCP/UDP Sockets To set up a TTY protocol port using sockets, you must decide whether the port should be a connection-oriented (TCP) or datagram (UDP) socket port. You also must decide if the port is to act as a client or a server. A server sits and listens for connections on a given address represented by a service name. A client attempts to connect to a remote service name. Note that server and client specifications do not apply to dynamic UDP sockets. If the selected socket is UDP and the Dynamic field is set to Yes, the Client/Server field is unavailable. For server ports, the port or service on which the port is to listen must be specified in the Service Name field. Either a port number or a service name defined in the /etc/services file must be entered. By default, sysconfig enters the service name ttyprotocoln where n is the port number. If a service name is used, the service type in /etc/services (UDP or TCP) must be correct. For client ports, the Service Name field must be filled in as for servers. If a service name is used, it must be defined in the clients /etc/services file. The Remote Host field must also be filled in for clients to indicate the host on which the server is running. This field can be either an IP address or a hostname. The hostname localhost refers to the clients host. You can select either IPv4 or IPv6 as the Address Type for the port being configured. The remaining parameters (including maximum message length, parity, message termination characters, maximum timeout from message start, and parity mask) are the same as for physical ports. An example of the use of the message length and maximum timeout to determine message termination follows: A TCP socket is configured with maximum message length of 80, and a timeout set to 5 seconds, with no message termination characters selected. If a TCP segment containing 100 valid bytes is received on this socket and no more data is received afterwards, the first 80 bytes of data is received immediately. After the 5-second delay, the rest of the data (the following 20 bytes) is received. However, when a TCP socket is configured as a dynamic port and no protocol specific framing is selected, the line is also terminated when the peer terminates the connection. In this case, all pending data is reported, even if none of the three events mentioned in Section 7.2.1, Physical SPARC Ports, on page 7-2 has been encountered.
7-4
Ixia
TTY Protocol
One example is shown in Figure 7-2, where a UDP client port is selected in sysconfig and other parameters are specified as shown. Figure 7-2. TTY Device Configuration - UDP Sockets
7-5
TTY Protocol
Ixia
Figure 7-3.
TTY Device Configuration - TCP Sockets
TCP connections on the tty ports can have Nagle algorithm turned off. By default it is turned on. The sysconfig TTY TCP configuration has a new option, TCP_NO _DELAY to turn off Nagle algorithm.
7.2.3
RAW IP Sockets RAW IP sockets can be used to provide application access to RAW IPv4 Linux capability. To specify RAW IP sockets in sysconfig, select RAW IP Socket Port in the TTY Device Configured As field (see the example shown in Figure 7-4). In the IP Protocol field, select a RAW IP protocol number which can be used for frame exchange, for example, 132 (SCTP).
7-6
Ixia
TTY Protocol
Figure 7-4.
TTY Device Configuration - RAW IP Sockets
The application port should be configured to process the IP-level frames, or it can use a high-level IP protocol such as TCP, UDP, or ICMP. Some Ixia-designed state machines, such as the SCTP state machine, are able to work with protocol messages regardless of protocol name port assignment (see the SCTP State Machine Manual [9] for details). The IP Protocol field value should be in the range 1-254. Value 255 (RAW) can be used only for outbound messages of any RAW IP protocol type. This is a Linux system restriction. Protocols ESP, AH, and COMP provide access to IPv6-over-IPv4 frames only but not to IPv6. Only IPv4 RAW IP sockets are currently supported. NOTE: To work with RAW IP sockets, an application (context or Ixia-designed state machine) should have a root user privileges. The simplest way to set up root user privileges is to change the application file (for example, sctp_sm.ws for the SCTP state machine) ownership to root and set up set-user-id file capability. See the Linux chmod and execl man pages for details.
7-7
TTY Protocol
Ixia
7.3
DCPL Customization for TTY Protocol

The TTY protocol is selected in the ddc and ddriver command lines using the -mtty parameter. The TTY protocol does not add any statements to DCPL. Messages are sent using the free i= statement. The TTY protocol uses these special variables: The string variable %STOPPERS contains all the bytes which will terminate a line of input. The variable &MAXDELAY specifies the time (in centiseconds) to wait for a message to complete before terminating it.
7-8
8
Digital Communications Programming Language (DCPL)
Contents 8.1 Basic Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 8.2 Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 8.3 Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 8.4 Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 8.5 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834 8.6 Field Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875 8.7 Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882 8.8 Special and Predefined Variables . . . . . . . . . . . . . . . . . . . . 884 8.9 DCPL Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8107 8.10 Differences in DCPL Between IxCatapult and DCT-S . . . . . 8108 8.11 Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 8110 8.12 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8110
Ixia
8.1
8.1.1
Basic Syntax
Compiled and Interactive DCPL There are two versions of DCPL: The compiled version is used in compiled scripts. The interactive version is used when typing commands into a running IxCatapult session.
The two versions are slightly different. One difference is that the interactive version has no flow-control statements. The interactive version is used to control the entire IxCatapult session and allows references to the various contexts. The compiled version allows only references to the scripts own context. 8.1.2 Context Names and Port Expressions on Statements Each context has one or more ports. Some DCPL statements, such as add display, apply to specific ports; others, such as stop, do not. In compiled DCPL, a port-specific statement is made to refer to a specific port by specifying the port at the beginning of the statement:
{2} add display {&x + 1} remove display
If a port-specific statement does not specify a port, port {1} is assumed. If you use an expression rather than a constant for the port number, it should be preceded by a default protocol statement (see default protocol on page 8-33) and a default variant statement (see default variant on page 8-33). If these are omitted, the first variant specified on the compilation line is taken as the default. For example:
ddc -mmtp3 -V1 -p2 # Variant 1 is used as default
In interactive DCPL, every statement must apply to a specific context, so you must specify a context for every statement. This is done in one of two ways: either by specifying the context at the beginning of the statement itself, or by using the default context statement (see default context on page 8-32). For example, this statement:
{Context_A} load mtp3
does the same thing as these two:

default context Context_A load mtp3
The default context statement applies to all following statements until the next default context statement. There is no initial default context.
8-2
Ixia
Statements in interactive mode can specify both a context and a port using this notation:
{Context_A.2} add display
Context names must begin with a letter or underscore; the remaining characters must be letters, digits, and underscores. Context names must not be longer than 256 characters. 8.1.3 Line Continuation Long statements can be continued onto other lines by using a backslash:
free i = \ $123456
No characters can follow the backslash, not even a space. 8.1.4 Literal Values Integer literals can be either decimal or hexadecimal. Hex literals begin with a pound sign:
&i = 12 &j = #0C /* decimal */ /* hex */
Integer literals cannot be larger than 232 - 1 (4294967295). String literals can be either ASCII or hexadecimal strings. ASCII literals are enclosed in apostrophes. Hex strings begin with a dollar sign and contain an even number of hexadecimal digits:
%msg = hello world %frame = $123456
Apostrophes can be included in string literals by doubling them:

%lyrics = Cant help lovin dat man o mine
8.1.5
Comments Two types of comments exist. Comments can be enclosed in /* and */. This type of comment may span multiple lines. Alternatively, a single-line comment begins with // and terminates at the end of the line.
/* This is a comment */ // This is also a comment
8-3
Ixia
8.1.6
Capitalization With two exceptions, DCPL ignores the case of keywords and variables. The case of characters within quoted strings is honored; and the names of C functions called must match their C declarations (see Section 9.2, Calling C Procedures from DCPL, on page 9-2). For example:
&TEMP = 5 print &temp
8.1.7
Conversion from Integer to String Integer values can be implicitly converted to strings. However, only the low-order byte is used; it is converted to a one-byte string. Conversion of multi-byte integer values requires choosing a byte order; use bitstr and bitcat. An example of implicit conversion is as follows:
$aa,#1122,$bb yields $aa22bb
8.1.8
DCPL Keywords DCPL keywords are always recognized as such and cannot be used in other ways. In practice this means that they cannot be used as filenames. Variable names are distinguished from keywords by their initial character. The DCPL keywords are listed in Section 8.9, DCPL Keywords, on page 8-107.
8.1.9
Line Length Each line of DCPL is limited to 16384 characters. This limit applies after any expansion by the protocol encoder and expansion of macro references.
8-4
Ixia
8.2
8.2.1
Variables
String and Integer Variables DCPL contains two types of variables, integer and string. Integer variable names begin with an ampersand; string variable names begin with a percent sign:
&counter = 5 %label = abc
The character following the % or & must be a letter or underscore. The remaining characters must be letters, digits, and underscores. Variable names are limited to 100 characters, including the initial % or &. Integer variables contain 32-bit unsigned values. String variables, unlike C strings, can contain binary-zero bytes:
%frame = $112233001122
It is not permitted to have an integer variable and a string variable of the same name. The value of a string variable may be a byte string or a bit-field. 8.2.2 Scalar and Array Variables Both integer and string variables can be either scalars or one-dimensional arrays. Array elements are referenced using square brackets:
&table[&index] = 43 %addresses[&last + 1] = %opc
It is not permitted to have a scalar variable and an integer variable of the same name; that is, a variable name followed by an array subscript must be followed by an array subscript everywhere it appears. Array indices are in the range of 0 through (array size - 1), inclusive. Subscripts that evaluate outside of this range are not permitted. Arrays are assumed to contain 128 elements unless declared using the array statement (see array on page 8-31) before their first use. 8.2.3 Port-Specific and General Variables DCPL contains two types of variables: those associated with a specific port and those not associated with any port. The latter are also referred to as general variables. Port-specific variables are referenced by specifying the port number in curly braces:
&port_counter{2} = 0 %port_name{&port} = unknown &port_array[12]{3} = 32
8-5
Ixia
%port_address[5]{&i-1} = $c00a
Variable references without the port expression refer to general variables, for example:
&counter = 28 %address = $887766
8.2.4
Interaction of Port-Specific Statements and Variables A port expression at the beginning of a statement does not apply to the variables in the statement. For example, in the following statement, %frame is a general variable, not a port {2} variable.
{2} free i = %frame
If %frame{2} is desired, it must be referenced explicitly:

{2} free i = %frame{2}
However, DCPL also provides a means of referencing the statements port number: variables having the empty port expression {} implicitly refer to the statements port. For example:
{&portin} free i = %message{}
8.2.5
Default Variables Most IxCatapult protocol encoders generate references to default variables for mandatory parameters that are omitted from messages. For example, the line:
{&p} tcr_begin
is equivalent to the line:

{&p} tcr_begin cda=%tcprim_cda{} \ cga=%tcprim_cga{} \ did=%tcprim_did{}
Default variables always contain empty port expressions, so they always refer to the statements port. 8.2.6 Special Variables Some DCPL variable names are reserved for special variables. For example, &portin is the port on which the last frame was received by the script. The special variables are listed in Section 8.8, Special and Predefined Variables, on page 8-84.
8-6
Ixia
8.3
8.3.1
Expressions
Integer Expressions DCPL integer expressions are composed of the following operators, listed in increasing order of precedence:
? : or and bitor bitxor bitand = != <> < <= > left right + * div mod not bitnot ( )
>=
The conditional operator, exp1 ? exp2 : exp3, evaluates exp1. If its value is nonzero, exp2 is returned, otherwise exp3 is returned. (Refer also to condstrexp on page 8-45.) The or operator returns 1 if either of its arguments is nonzero and returns 0 otherwise. The and operator returns 1 if both its arguments are nonzero and returns 0 otherwise. The bitor, bitxor, and bitand operators perform bitwise or, bitwise exclusive-or, and bitwise and operations, respectively, on their operands and return the result. The = operator returns 1 if its arguments are equal and returns 0 otherwise. The != and <> operators return 1 if their arguments are unequal and return 0 otherwise. The <, <=, >, and >= operators return 1 if their first operand is respectively less than, less than or equal to, greater, and greater than or equal to their second operand, and return 0 otherwise. The left and right operators shift their first operand left and right, respectively, by the number of bits specified by their second operand, and return the result. The binary + and - operators, exp1 + exp2 and exp1 - exp2, respectively return the sum and difference of their operands.
8-7
Ixia
The multiplication operator, *, returns the product of its two operands. The integer division operator, div, returns the integer part of the quotient of its two operands. The modulo operator, exp1 mod exp2, returns exp1 modulo exp2, that is, the remainder after dividing exp1 by exp2. The logical not operator, not exp1, returns 1 if exp1 is zero, and returns 0 otherwise. The bitwise not operator, bitnot exp1, inverts each bit of exp1 and returns the result. The unary plus operator, + exp1, returns exp1. The unary minus operator, - exp1, returns the negative of exp1. All DCPL integers are unsigned, so -1 would return #FFFFFFFF. Use parentheses to override the standard operator precedence. The atoms of integer expressions, on which the operators operate, are integer literals, integer variables, and functions that return integer values. 8.3.2 String Expressions DCPL contains two string operators: the comma operator, which performs concatenation, and the nullif operator: The comma operator operates on string literals, string variables, functions that return string values, and the results of other comma and nullif operators. The nullif operator, nullif exp1 nullthen exp2, returns a string. If exp1 is 0, a null string is returned; otherwise, a one-byte string containing exp2 is returned. For example:
nullif 1 nullthen #12 returns $12
The value of a string expression may be a byte string or a bit-field.
8-8
Ixia
8.4
8.4.1
Statements
Data Manipulation Statements DCPL uses the following data manipulation statements. assignment The assignment statement assigns integer expressions to integer variables and string expressions to string variables. Integer assignment includes both simple assignment (variable = expression) and arithmetic assignment, as shown in the following examples.
&x &x &x &x = 5 += 1 /* &x = &x + 1 */ -= 1 /* &x = &x - 1 */ *= 2 /* &x = &x * 2 */
String assignment is limited to simple assignment. Integer values can also be assigned to string variables. See Section 8.1.7, Conversion from Integer to String, on page 8-4. Examples of string assignments are as follows:
%str = Carpe diem %byte = &x
encode The encode statement is available in some protocols. It encodes a protocol-specific message and places it in the DCPL variable %Enc_frame. For example:
{1} encode status cause=$1234 callst=$4567 sets %Enc_frame to $0201000008007d0802123414024567
locate The locate statement is port specific and is available in all protocols. It works only in compiled scripts, not in the interactive language. In some protocols the syntax and semantics differ from those shown here. Check the individual protocol manuals for details. The standard locate statement is locate field [appearance n] in string. It finds the specified appearance of the named field in the specified string (which is assumed to be a protocol message) and records its location. It stores the index of fields first byte (counting from 1) into &Loc_index and its length in bytes into &Loc_length. &Loc-index is set to 0 if the field is not found. &Loc-length is set to 0 if the field is not found or if the field is found but it occupies no message bytes (possible in some protocols). Use the substr function (see substr on page 8-51) to extract the encoded field from string when &Loc-length is not 0. An example of a locate statement is as follows:
{1} locate cause in %frame IxCatapult Software Reference Manual, Release 20.1 8-9
Ixia
In some protocols where fields are not octet-aligned, the locate statement may also set the DCPL variables &Loc_bitoff and &Loc_bitlen. Again, see the individual protocol manuals to check if these variables are set. NOTE: Since locate returns the length and offset of an encoded message, the value of the extracted field is still encoded. Depending on the encoding rules used, the extracted value may not reflect the actual value of the field without additional processing. See Section 8.6.7, Difference Between FRS and locate, on page 8-80 for more information. parse The parse statement, parse string, assumes string to be a DCPL statement and executes it. For example:
parse %frame
The parse statement is intended to be used to parse DCPL statements received via the case keyboard statement (see switch on page 8-13). To execute a DCPL statement constructed by the script, the keyboard statement (see keyboard on page 8-21) should be used. pattern The pattern statement is used to assign a specific pattern to a pattern number for use within the BCHAN protocol. It is used in conjunction with the special variable &PATTERNO, which tells ddriver what to send out on a port running BCHAN when it has no other data to send. Valid values for <exp> in the command pattern are from 2 through 9. See the BCHAN Protocol Manual [14] for further details of the use of pattern. For example:
pattern 2 i=$5555555555555555555555555555555....
8.4.2
Flow Control Statements DCPL uses the following flow control statements. break The break statement breaks out of the innermost enclosing for loop (see for on page 8-12) or while loop (see while on page 8-17). For example:
break
8-10
Ixia
call The call statement, call subroutine, calls the specified subroutine. Each DCPL source file linked into a script becomes a subroutine. Its name is the name of the DCPL file with the .d removed. It is also possible to call C functions from DCPL. Parameters may be passed to the C function but no value returned. See Section 9.2, Calling C Procedures from DCPL, on page 9-2. However, DCPL calls to DCPL do not pass parameters and do not return values. An example of a call statement is as follows:
call handle_input
continue The continue statement jumps to the top of the innermost enclosing loop: to the test of a while loop (see while on page 8-17) or the second assignment of a for loop (see for on page 8-12). For example:
continue
exp switch The exp switch statement is used to perform a series of tests on a numeric expression. The switch statement (see switch on page 8-13), by contrast, performs tests on a string expression. The exp switch statement has the following syntax:
exp switch exp exp_case ... [other: statement ...] endswitch
where exp_case has the syntax:

case_list statement ... endcase
and case_list has the syntax:

case number: ...
Exp is compared against each number; if it matches, the corresponding block of statements is executed. If exp does not match any number, the other statement block is executed if specified; otherwise, no statements are executed. An example of a switch statement is as follows:
exp switch &option case 1: sprint Option 1 endcase case 2: case 3: sprint Option , string(&option) endcase other:
8-11
Ixia
endswitch
sprint Unknown option
exit The exit statement causes the IxCatapult session to exit. For example:
exit
Note that when exit is issued from a script compiled for the Coprocessor environment, only the workstation-based session exits. All Coprocessor scripts, including the one issuing the exit, running on all Coprocessor boards for the current IxCatapult session, continue executing. If you want to terminate a Coprocessor script, use the unload command instead. Once a Coprocessor script has issued an exit command, no DCPL commands that require user input, interact with the UNIX filesystem, or interact with the previously running workstation-based IxCatapult session will function (for example, pause, load, unload, keyboard, view, write, gwrite, add display/log, etc.). for The for statement has the following syntax:
for ([variable=exp]; [test]; [variable=exp]) statement ... endfor
The first assignment is performed if present, then the loop is iterated. At each iteration, test is evaluated if present. If it is absent or its value is nonzero, the iteration proceeds; otherwise, the for statement ends. The iteration proceeds by executing the statements, then the second assignment if present. An example of a for statement is as follows:
for (&i = 0; &i < 10; &i = &i + 1) sprint Iteration , string(&i) endfor
if The if statement executes one of two blocks of statements based on whether the test expression is nonzero. The syntax is:
if test statement ... [else statement ...] endif
For example:
if &i > &n break else continue endif
8-12
Ixia
pause The pause statement, pause string, displays string and pauses execution of the script until input is received from case keyboard (see switch on page 8-13). While a script is paused, it discards all incoming frames; that is, they are not buffered to trigger an eventual wait statement (see wait on page 8-15) after the pause is completed, though any frames already buffered before the pause statement are retained. If multiple scripts are simultaneously paused, they all resume when the Enter key is pressed. For example:
pause Hit Enter to continue
Only an empty line (or input such as a comment which results in an empty line after processing) will continue the execution of the script. Display commands (for example, view on/off, add display, default context) will be executed outside the script and will not terminate the pause. Any other input line will be ignored. This means that hello followed by the Enter key will not resume execution of the script but /*hello*/ followed by the Enter key will resume execution. NOTE: Input from a Launcher/ddriver include file (or a keyboard statement) is treated as keyboard input so a comment (/* ... */) will terminate the pause. The Launcher strips empty lines but not comments when it writes its temporary include file. Also, as previously explained, the display commands in the include-file lines will be executed and all other lines will be ignored. return The return statement returns from the current DCPL subroutine. For example:
return
switch The switch statement performs a series of tests on a string expression. The exp switch statement (see exp switch on page 8-11), by contrast, performs tests on a numeric expression. The switch statement has the following syntax: switch string_variable case_block ... [other: statement ...] endswitch where case_block has the following syntax: case_list statement ... endcase and case_list has the following syntax: case ... and case has the following syntax:
8-13
Ixia
case type message_type: or case template message_template: or case exp exp: or case timeout: or case itimeout: or case keyboard: Each case is evaluated. The first one to match has its statements executed. If none is found to be true, the other statement block is executed if specified; otherwise, no statements are executed. The case type statement matches if string_variable is a protocol-specific message of type message_type and the result of the last wait statement (see wait on page 8-15) was a message received on the case type statements port. It is intended that string_variable be the message received by the wait statement. The case template statement matches if string_variable is a protocol-specific message that matches the template given by message_template, and the result of the last wait statement (see wait on page 8-15) was a message received on the case template statements port. It is intended that string_variable be the message received by the wait statement. The message_template is of the following form (a bicc variant 4 example):
transfer_req sequence_control=3 user_data=[acm cic=exists bci=[chrg=1 cdsind=2]]
This template means: match the message that is of type transfer_req, field sequence_control must equal 3, user_data must be of type acm, field cic must be in the message, chrg must equal 1, and cdsind must equal 2. See the individual protocol manuals to make sure case template is supported before using it. Use dfb with the -t option to build a template. See Section 6.5, Building a Template, on page 6-5 for more details of template building.
8-14
Ixia
The case exp statement matches if exp is true. It might or might not refer to string_variable. The case timeout statement matches if the result of the last wait statement was a timeout. The case itimeout statement matches if the result of the last wait statement was the firing of an interval timer associated with the case itimeout statements port (see Section 8.4.5, Interval Timer Statements, on page 8-28). The case keyboard statement matches if the result of the last wait statement was input from the user. An example of a switch statement is as follows:
switch %frame {2} case type connect: sprint Received a connect endcase {2} case template transfer_req sequence_control=3 user_data=[acm cic=exists bci=[chrg=1 cdsind=2]]: sprint template matches endcase case exp (len(%frame)<5): sprint Frame too short endcase case timeout: sprint No frame received endcase {3} case itimeout: sprint Interval timer fired endcase case keyboard: sprint Keyboard input received endcase other: sprint Unknown input endswitch
wait The wait statement, wait string_variable [for timeout] [port numexp| port KEYBOARD], stops execution of the script until one of several events occurs: the reception of a message, either on a port or from the keyboard a timeout the firing of an interval timer (itimer)
8-15
Ixia
The switch statement (see switch on page 8-13) is usually used to handle the various cases. If a message is received on a port, it is placed into string_variable, and the port number is placed into &portin. If a message is received from the keyboard, it is placed into string_variable; however, it is not logged or displayed. If you want a script to display lines received from the keyboard, use the sprint statement (see sprint on page 8-25). The wait will time out if timeout centiseconds have elapsed with no other event occurring. If the timeout value is 0, the statement will never time out; the statement wait %frame is equivalent to wait %frame for 0. Note that by default wait is not port specific. Any received frame, including one received from the keyboard, will satisfy it, as will any itimer. To receive messages and itimers only from a specific port, specify the port parameter, as in the statement wait %frame port 2. If you want to receive messages only from the keyboard, use the statement wait %frame port KEYBOARD. Port-specific wait, including wait for port KEYBOARD, behaves the same as the default wait in the case of timeouts. Port-specific wait allows scripts more control over the order in which they receive events. The typical use for this feature would be for initialization and for functional tests. It is advised to avoid the use of port-specific wait for load testing. See Section 8.4.5, Interval Timer Statements, on page 8-28 for more information about interval timers. Examples of wait statements are as follows:
wait %frame for wait %frame &timeout = 200 wait %frame for &port_num = 2 wait %frame for wait %frame for 200 &timeout &timeout port &port_num 100 port KEYBOARD
8-16
Ixia
while
The while statement has the following syntax:
while test statement ... endwhile As long as test evaluates to a nonzero value, the statements are executed and test is re-evaluated. An example of a while statement is as follows:
while len(%frame) = 0 wait %frame endwhile
8.4.3
Comment Statements DCPL uses the following comment statements. These statements are terminated by either the end of line, the end of a macro (for example, }), or the beginning of a comment block (for example, /*). comment The comment statement, comment text, displays text (unless ddriver is in brief mode) and logs it to the log file. An example of a comment statement is as follows:
comment Beginning test 1
! The ! statement is identical to the comment statement. An example of a ! statement is as follows:

! Ending test 1
prompt The prompt statement, prompt text, is the same as the comment statement, except that in addition text is always displayed on the ddriver prompt line. An example of a prompt statement is as follows:
prompt Type go to start test
8-17
Ixia
8.4.4
Input/Output Statements DCPL uses the following input/output statements. add display The add display statement is port specific. It causes messages sent and received on its port to be displayed and logged. By default, display is turned off for all ports. (Refer also to add log on page 8-18, remove display on page 8-24, and remove log on page 8-25.) Use of the add display (and to lesser degree add log) instructions on ports that pass large quantities of traffic may affect real-time behaviors of the system. In particular, itimers in the scripts executed on the base board (PPCI) may be delayed. A warning is sent to the display/log file when display/log congestion is detected. In such cases, it is recommended to decrease the number of frames sent to the display/log by removing display/logging on some ports. An example of an add display statement is as follows:
{5} add display
To limit protocol display/logging, a numeric parameter can optionally be included at the end of the add display statement. This numeric parameter indicates the subset of the ports protocol to be affected by the statement. For example:
{1} add display protocol=5
Limiting protocol display/logging is supported only for certain protocols. Please see the individual protocol manuals for more information on whether the feature is supported and on what subsets the protocols define. add log The add log statement is port specific. It causes messages sent and received on its port to be logged without affecting whether they are displayed. (Refer also to add display on page 8-18, remove display on page 8-24, and remove log on page 8-25.) An example of an add log statement is as follows:
{2} add log
To limit protocol logging, a numeric parameter can optionally be included at the end of the add log statement. This numeric parameter indicates the subset of the ports protocol to be affected by the statement. For example:
{1} add log protocol=1
8-18
Ixia
Limiting protocol logging is supported only for certain protocols. Please see the individual protocol manuals for more information on whether the feature is supported and on what subsets the protocols define. badfcs The badfcs statement, badfcs i=string, is port specific. It sends string, which is a string expression, on its port with a bad frame checksum (FCS). This statement is supported only in certain protocols. See the individual protocol manuals for details. For example:
{2} badfcs i=$02,reverse(abc)
codec on The codec on statement, codec on channel [link link], is port specific. It connects a boards codec to the specified channel on the specified link on that board. The board is specified by the statements port, either because the port is connected directly to a board port or because the statements port has been associated to a board port (see Section 3.2.5, Associating Context Ports to Board Ports and Interboard Ports, on page 3-15). If link is not specified, it defaults to 0. codec off The codec off statement is port specific. It disconnects a boards codec. The board is specified by the statements port, either because the port is connected directly to a board port or because the statements port has been associated to a board port (see Section 3.2.5, Associating Context Ports to Board Ports and Interboard Ports, on page 3-15). forward The forward statement, forward to {port}, is port specific. It forwards any messages received on its port to port, with no further intervention from the script. Once forwarding is active from a port, none of the packets from that port will be seen by a user script. Hence, none of them will cause a wait statement to terminate. This situation also means that the frames will not be displayed or logged on that port. An example of a forward statement is as follows:
{2} forward to {3}
forward stop The forward stop statement is port specific. It stops the forwarding of messages on its port. An example of a forward stop statement is as follows:
{2} forward stop
free The free statement, free i=string, is port specific. It sends string, which is a string expression, on its port. For example:
{2} free i=$02,reverse(abc)
8-19
Ixia
If the string expression is a bit-field, it will be converted to a byte string. Any bits that do not fill a complete octet will be placed in the most significant bits of an octet followed by padding bits which will be set to zero. gwrite The gwrite statement, gwrite filename, causes global logged information to be written to filename.out. The .out filename extension is automatically appended if not supplied. Global logged information means information from all contexts whose information is not being logged to a per-context log file by the write statement (see write on page 8-27). No current context is required for this statement. The gwrite and write statements cannot log to the same file at the same time. An example of a gwrite statement is as follows:
gwrite global_trace
gwrite append The gwrite append statement, gwrite append filename, appends global logged information to existing file filename.out. The .out filename extension is automatically appended if not supplied. Global logged information means information from all contexts whose information is not being logged to a per-context log file by the write statement (see write on page 8-27). No current context is required for this statement. Log files can be displayed using the dctprint program (see Section 4.1, dctprint, on page 4-2). The gwrite and write statements cannot log to the same file at the same time. An example of a gwrite append statement is:
gwrite append global_trace
gwrite stop The gwrite stop statement, gwrite stop, stops global logged information from being written to the global log file opened using the gwrite statement (see gwrite on page 8-20). Global logged information means information from all contexts whose information is not being logged to a per-context log file by the write statement (see write on page 8-27). No current context is required for this statement. An example of a gwrite stop statement is as follows:
gwrite stop
gwrite timestamp The gwrite timestamp statement, gwrite timestamp filename, creates a new global log file just like gwrite and adds a timestamp indicating when the log file was created. This new log file entry can be used by dctprint to report events in the log file relative to the start of the log file. An example of the gwrite timestamp statement is as follows:
gwrite timestamp global_trace
8-20
Ixia
include or
The include statement has the following syntax:
include file
include <file>
It causes the compiler or interpreter to replace the statement with the contents of file. The first form looks for file in the current directory, then in $DCT2000PATH. The second form looks for file only in $DCT2000PATH. In interactive DCPL, the statement is not context specific; that is, each line in the included file is treated as though it were typed at the keyboard. Examples of the include statement are as follows:
include startup.cmds include <isdn.dh>
NOTE: The equivalent C syntax (#include "startup.cmds") is also accepted. See Section 9.4.3, Constants, on page 9-5 for more details. keyboard The keyboard statement, keyboard i=strexp, causes strexp to be handled as though it were typed at the keyboard. An example of a keyboard statement is as follows:
keyboard i={Context_B.6} free i=$01020304
NOTE: Please use string for a keyboard statement. Using the following will produce unintended results:
keyboard i={Context_B.6} free i=,#1234
Use the following instead:

keyboard i={Context_B.6} free i=,string(#1234)
load The load statement, load filename, causes the current script to be replaced by filename, which is assumed to be a compiled script. The statement is commonly executed from an include file. In this case the context it refers to must be specified. If script is not a complete pathname (that is, it does not begin with a /), it is looked for first in the current directory, then in $DCT2000PATH, and then in $PATH. An example of a load statement is as follows:
{Context_C} load tcap_state
The filename must consist of letters, digits, and underscores. It refers to the file filename.ws if the context is running on the workstation, or to filename.ppci if the context is running on a Coprocessor board.
8-21
Ixia
Variables (and their values) are preserved across a load statement. This applies to compiled as well as interactively created variables, in Coprocessor scripts as well as workstation scripts. However, if the script being loaded declares a variable in a way that conflicts with a preserved variable of the same name, the new variable is created and the old variable is not preserved. The conflicts that cause this behavior are: string vs. integer (the new variable is an integer and the old is a string, or vice versa) array vs. scalar general vs. port-specific differing array sizes
NOTE 1: The load statement may take up to several seconds to load a script to a Coprocessor context (compared to several milliseconds for a workstation context). NOTE 2: Due to performance constraints on the memory management system on Coprocessor contexts, memory allocated to variables leaks each time the load statement occurs. In most circumstances this has little effect on usability of the system, unless the script has many variables declared (for example, arrays), and the load statement is executed many times. To avoid this, use the load noglobals statement (see the following load noglobals section). load noglobals The load noglobals statement, load noglobals filename, causes the current script to be replaced by filename in the same manner as load filename, except that variables and their values are not preserved. With the noglobals option, load times are dramatically improved on Coprocessor contexts, memory is not leaked for declared variables, and conflicts between types on variables are allowed across the load. log The log statement, log strexp, is port specific. It logs strexp as though it were received on the statements port, but does not display it. An example of a log statement is as follows:
{3} log %frame
8-22
Ixia
preprocess The preprocess statement, preprocess state, controls the preprocessing of keyboard input in a ddriver session. By default, lines typed at the keyboard undergo macro preprocessing (macros are expanded, and new macros can be defined) and encoding (translation of protocol-specific messages into protocol-independent DCPL). Preprocess off turns off this processing; preprocess on restores it. Preprocess is a context-specific statement. The statement is valid only in interactive DCPL, not in scripts. Examples of preprocess statements are as follows:
{ss7_l2}preprocess on {ss7_l2}preprocess off
print The print statement, print exp, displays the value of exp. (Refer also to sprint on page 8-25.) An example of a print statement is as follows:
print len(%frame)
The print statement echoes the expression it is given, as part of its output. For example, the statement above might give this output:
The value of len ( %frame ) is 5
However, the expression can undergo extensive preprocessing before being echoed by the print statement. For example, given these two lines:
define N = 5 print N
The output will be:

The value of 5 is 5
This preprocessing of the expression is especially extensive with field references (see Section 8.6, Field Reference, on page 8-75) and the howmany function (see howmany on page 8-56). In all cases, the sprint statement can be used to give better control over the output. For example:
define N = 5 sprint The value of N is , string(N)
gives
The value of N is 5
8-23
Ixia
received The received statement, received strexp, is port specific. It logs and displays strexp as though it had been received on the statements port. strexp is assumed to be a valid message in the ports protocol. The statement is useful if display is turned off but it is desired to log periodic or interesting messages. An example using the received statement is as follows:
{2}remove display wait %frame switch %frame case KEYBOARD: parse %frame endcase other: /* log and display the contents of %frame if the * length of the frame is greater than 20 octets */ if ((&portin = 2) and (len(%frame) > 20)) {2} received %frame endif endswitch
remove display The remove display statement is port specific. It causes messages sent and received on its port not to be displayed or logged. By default, display is turned off for all ports (also see add display on page 8-18, add log on page 8-18, and remove log on page 8-25). An example of a remove display statement is as follows:
{5} remove display
To limit protocol display/logging, a numeric parameter can optionally be included at the end of the remove display statement. This numeric parameter indicates the subset of the ports protocol to be affected by the statement. For example:
{1} remove display protocol=3
Limiting protocol display/logging is supported only for certain protocols. Please see the individual protocol manuals for more information on whether the feature is supported and on what subsets the protocols define.
8-24
Ixia
remove log The remove log statement is port specific. It causes messages sent and received on its port not to be logged without affecting whether they are displayed (also see add display on page 8-18, add log on page 8-18, and remove display on page 8-24). An example of a remove log statement is as follows:
{2} remove log
To limit protocol logging, a numeric parameter can optionally be included at the end of the remove log statement. This numeric parameter indicates the subset of the ports protocol to be affected by the statement. For example:
{1} remove log protocol=12
Limiting protocol logging is supported only for certain protocols. Please see the individual protocol manuals for more information. send The send statement, send frame, is port specific. It sends, logs, and displays frame even if display has been turned off on that port. frame is assumed to be a valid protocol-specific DCPL command, or a free command. The statement is useful if display is turned off but it is desired to log periodic or interesting transmitted messages. An example using the send statement is as follows:
{2}remove display {2}free i=some uninteresting message {2}send free i=some interesting message
Another example using a protocol-specific DCPL command (ISUP in this case) is as follows:
{2}send anm route=[dpc=576 opc=577 sls=4] cic=12
screen clear The screen clear statement clears the display. It is intended to give the script writer some control over the display the user sees. An example of a screen clear statement is as follows:
screen clear
sprint The sprint statement, sprint strexp, displays the value of strexp (also see print on page 8-23.) An example of an sprint statement is as follows:
sprint string(&n), frames read
The maximum string length sprint can output is 16384 characters. Secondarily, when a long string is output by display or dctprint, its output may be truncated. See Section 3.3.7.5, Display Truncation, on page 3-36 for more information.
8-25
Ixia
store The store statement, store file, writes any current macro definitions to file.mlt, for later use by the -L command-line parameter. Use of the -L parameter decreases DCPL compilation time compared to reading the original macro definitions. (See Section 8.7, Macros, on page 8-82 and Chapter 5, Compiling DCPL Scripts.) An example of a store statement is as follows:
store macrodefs
sysmon The interactive DCPL statement, sysmon on|off, turns on or off a System Monitor log file. This monitor gives continual reports about the state of the system. It monitors download contexts used in a session and the state of the Coprocessor boards used. An example of a sysmon statement is as follows:
sysmon on
timeslot to The timeslot to statement, timeslot to expression [link], enables dynamic switching of the timeslot routed to a given port. When the statement is executed, the timeslot specified by expression is routed to the port, and the previously routed timeslot is disconnected. The timeslot to statement can be used with all valid protocols on a PowerPCI board with a T1/E1, J1/E1/T1, or BRI S/T mezzanine board. The use of timeslot to is not supported on other physical interfaces. The value of expression is limited to the range 124 for a T1, 131 for an E1, and 12 for a BRI S/T. If a link parameter is specified, the port is switched to the specified timeslot on the specified link; otherwise, the link currently associated with the port is used. The link parameter has two valid values, 0 and 1. In order to switch timeslots on the PowerPCI board, you must configure the board to have switchable timeslots/channels using sysconfig. In the E1 and T1 configuration windows, you can select 64k switchable or 56k switchable in the Timeslot Data Rate selection areas. Note that when these options are selected, only one timeslot can be selected for each port. In the BRI S/T configuration window, you can choose switchable in the Channel Mode selection. This limits you to a single 64 kb/s channel for each port. Note that both links are placed in switchable mode for all three mezzanines. It is not possible to configure one link for switchable timeslots and the other for normal operation.
8-26
Ixia
unload The unload statement causes its script to be replaced with a place-holder script. This script parses input from case keyboard (see switch on page 8-13) and discards other input. The statement is commonly executed from an include file. In this case the context it refers to must be specified. An example of an unload statement is as follows:
{Context_C} unload
unload noglobals The unload noglobals statement causes the current script to be replaced by a place-holder script in the same manner as the unload statement, except that variables and their values are not preserved. With the noglobals option, load times are dramatically improved on Coprocessor contexts, memory is not leaked for declared variables, and conflicts between types on variables are allowed across the load. view The view statement, view state, controls the existence of a separate display window for the specified context. The statement is commonly executed from an include file or from the keyboard. In this case the context it refers to must be specified. view on creates a separate window for the context. Its display appears there, and input typed there is assumed to refer to the context without the necessity of a default context statement (see default context on page 8-32). view off removes the window, and further display from the context appears in the main window. Examples of view statements are as follows:
{Context_D} view on {Context_D} view off
write The write statement, write filename, causes logged information from the current context to be written to filename.out. The .out filename extension is automatically appended to <filename> if it is not supplied. Thus, if <filename> is absent, the output file is .out; otherwise, it is <filename>.out. (Refer also to gwrite on page 8-20.) Log files can be displayed using the dctprint program (see Section 4.1, dctprint, on page 4-2). The gwrite and write statements cannot log to the same file at the same time, nor can two write statements. For example, write whatever produces a log file whatever.out; while write produces .out.
8-27
Ixia
write append The write append statement, write append filename, appends logged information from the current context to existing file filename.out. The .out filename extension is appended automatically if not supplied. (Refer also to write on page 8-27 and gwrite append on page 8-20.) The gwrite and write statements cannot log to the same file at the same time, nor can two write statements. An example of a write append statement is as follows:
write append context_trace
write stop The write stop statement, write stop, stops logged information from the current context from being written to the log file opened using the write statement (see write on page 8-27). (Refer also to gwrite stop on page 8-20.) An example of a write stop statement is as follows:
write stop
write timestamp The write timestamp statement, write timestamp filename, creates a new context log file just like write and adds a timestamp indicating when the log file was created. This new log file entry can be used by dctprint to report events in the log file relative to the start of the log file. An example of the write timestamp statement is as follows:
write timestamp context_trace
wsprint The wsprint statement, wsprint strexp, displays the value of strexp; strexp is allowed to contain two-byte characters, in particular, Kanji characters. Such characters are assumed to have the high-order bit of their first byte set. The workstation must be able to display such characters for this statement to work correctly. (Refer also to sprint on page 8-25.) An example of a wsprint statement is as follows:
wsprint %kanji_text
8.4.5
Interval Timer Statements Many protocol test applications require the use of interval timers for load generation, guard timers, periodic statistics generation, and other uses. DCPL provides built-in support for interval timers, referred to as itimers. Itimers are started using the start_itimer statement and stopped using stop_itimer. The time remaining on an itimer can be read using read_itimer. The timeout of an existing timer can be adjusted using adjust_itimer. All statements are port-specific.
8-28
Ixia
Individual interval timers are identified by the triplet (tag, index, port); in particular, a single-shot itimer and a periodic itimer cannot have the same triplet. The port is the statements port. The tag and index are integers and can take any value. Generally, tag identifies a class of timers (for example, a call hold timer or a statistics generation interval timer) and index indicates an instance of that class. NOTE: A potentially significant performance benefit exists if there are 16 or fewer distinct tag values in a DCPL program and the assigned tag values are sequential integers, although they need not start at zero. DCPL uses the following interval timer statements. start_itimer The start_itimer statement is port specific; it has the following two forms:
start_itimer [tag=tag] [index=index] \ [duration=duration] [units=units] start_itimer [tag=tag] [index=index] \ period=period [units=units]
The first form starts a single-shot itimer; the second form starts a periodic itimer. A single-shot itimer expires only once, whereas a periodic itimer continually retriggers itself, terminating a wait statement each time, until it is stopped using stop_itimer. This produces better timing accuracy than simply re-calling start_itimer each time. The units value is sec, csec, msec, or exp. In the case of units=exp, the value indicates the units: 0 = 1 sec; 1 = 0.1 sec; 2 = 0.01 sec; 3 = 0.001 sec; 4 = 0.0001 sec; 5 = 0.00001 sec; and 6 = 0.000001 sec. units is used solely for interpreting duration. It has no effect on the accuracy of the timer. Timer accuracy is platform- and load-dependent. The default units is csec. The default tag is &itimer_tag. The default index is &itimer_index. The default duration is &itimer_duration. There is no default period. These variables are all port specific. Like all variables, they must be given a value before they are used. If the timer expires, terminating a wait statement (see wait on page 8-15), the variables &portin, &itimeout_tag{&portin}, and &itimeout_index{&portin} are set: &portin is the port number of the start_itimer statement, &itimeout_tag is the tag used in the statement, and &itimeout_index is the index used in the statement.
8-29
Ixia
Starting an already-running timer cancels it and restarts it with the specified duration or period. If necessary, the timer is changed from single-shot to periodic or vice versa. An example of a start_itimer statement is as follows:
{2} start_itimer tag=7 index=&rx_cic duration=5000 \ units=msec
NOTE: When an itimer is started with a null period or duration, a timeout is immediately created and captured in the next wait statement. stop_itimer The stop_itimer statement has the following syntax:
stop_itimer [tag=tag] [index=index]
Stopping a nonexistent timer has no effect. An example stop_itimer statement is as follows:

{2} stop_itimer tag=7 index=&rx_cic
stop_itimers
The stop_itimers statement has the following syntax:
stop_itimers [index=index]
The stop_itimers command stops all active timers for a given index. Stopping a nonexistent timer has no effect. An example stop_itimers statement is as follows:
{2} stop_itimers index=&rx_cic
read_itimer
The read_itimer statement has the following syntax:
read_itimer [tag=tag] [index=index] [units=units]
where units is the same as for start_itimer. The statement sets the port-specific variable &itimer_remaining to the time remaining, in the units specified by units. The default units is csec. An overdue timer is one for which the the expiry time has passed but has not yet been serviced by a DCPL wait statement. An attempt to read an overdue timer returns 0 in &itimer_remaining. Similarly, an attempt to read a nonexistent timer also returns 0. Interval timer expiry is reported through the DCPL wait statement. A special subclass of the case statement, case itimeout, can be used to conveniently handle interval timer expiry. When an interval timer expires, a NULL string is returned in the wait variable, and the special variables &PORTIN, &ITIMEOUT_TAG, and &ITIMEOUT_INDEX are set to identify the special interval timer that has expired.
8-30
Ixia
The wait statement will always return with an expired internal timer event before it returns with a received data frame, even if the data frame was placed in the receive queue before the interval timer had expired. In other words, interval timer expiry is presented to user scripts through the wait statement at higher priority than received data frames. This minimizes the delay between the expiration of an interval timer and the start of a user script processing the expiry event, regardless of data traffic volume. adjust_itimer The adjust_itimer statement is port specific; it has the following syntax:
adjust_itimer [tag=tag] [index=index] \ [phase=phase] [units=units]
where phase defines the amount (positive or negative) by which the time should be adjusted and units is the same as for start_itimer. The default units is csec. An attempt to adjust a nonexistent timer has no effect. Adjusting the expiry time of an interval timer causes the timer to expire earlier (negative adjustment) or later (positive adjustment) than originally scheduled. Adjusting the expiry of a periodic timer has the effect of changing the time of all subsequent expiries. Thus adjust_itimer changes the phase, but not the period. If a timer expiry is adjusted backwards before now, the timer is not lost. Rather, it times out immediately at the next DCPL wait opportunity. 8.4.6 Compiler/Interpreter Statements DCPL uses the following compiler/interpreter statements. array The array statement, array var_name[size][{}], is used to declare the number of elements in the one-dimensional array var_name. If {} is specified, the array is port specific, otherwise it is a general variable.
8-31
Ixia
Arrays do not have to be declared. If they are not declared, they default to 128 elements. DCPL imposes a maximum array size of 0x3fffffff elements for scripts compiled for the workstation environment and 0x1fffffff elements for scripts compiled for the Coprocessor environment. For port-specific variables, these limits should be divided by the number of ports. In practice, however, array sizes are limited by available memory. See Section 3.3.7.1, Memory, on page 3-34 for information about memory limits and Section 3.3.7.3, Download Contexts, on page 3-35 to find out how to estimate a scripts memory requirements. If several DCPL files are linked into a script and reference an array, only one of them needs to declare it. Other files can also declare it; however, they must all specify the same size. The size in compiled files must be a constant or a numeric expression with constant terms. Examples of the array statement are as follows:
array &addresses[1000*2] array %names[5]{}
default context The default context statement is used only in interactive DCPL. It specifies the context to which the following statements apply. It applies to all following statements until the next default context. There is no initial default context. For restrictions on valid context names, see Section 8.1.2, Context Names and Port Expressions on Statements, on page 8-2. An example of the default context statement is as follows:
default context fred
default main The default main statement can be used to identify a script as an entry point into the application. If no default main is specified, the first DCPL script on the ddc command line is used as the entry point (see Section 5.1, DCPL Compiler, on page 5-2). An example of the default main statement is as follows:
default main
default portspec The default portspec statement, default portspec = port specification, is used to optionally define the ddc command line port specification within the file. This allows the script to be compiled without supplying the port specification on the ddc command line. The ddc port specifications includes a series of -m, -V, and -p options as used on the ddc command line. (See Section 5.1.1, Command-Line Parameters, on page 5-2.) An example of a default portspec statement is as follows:
default portspec = -mtty -p1 -misup -V2 -p2 8-32 IxCatapult Software Reference Manual, Release 20.1
Ixia
Supplying a port specification on the ddc command line overrides the default portspec defined in the script. The default portspec command can only be included once in a script. The default portspec command must be processed before any other DCPL statement. default protocol The default protocol statement, default protocol = protocol, is required before statements with non-constant port expressions. (See Section 8.1.2, Context Names and Port Expressions on Statements, on page 8-2). Because different ports can have different protocols, and the port expression cannot be evaluated until run time, the DCPL compiler cannot be sure which protocol to assume in compiling such a statement. The default protocol statement tells the compiler which protocol to use. An example of a default protocol statement is as follows:
default protocol = isdn
If a default protocol statement has not been specified, the DCPL compiler assumes the first protocol specified on the compile line. Note that constant port expressions are not affected by the default protocol statement. default variant The default variant statement, default variant = variant, is required before statements with non-constant port expressions. (See Section 8.1.2, Context Names and Port Expressions on Statements, on page 8-2). Since different ports can have different variant numbers, and the port expression cannot be evaluated until run time, the DCPL compiler cannot determine which variant to assume in compiling such a statement. The default variant statement tells the compiler which variant to use. Examples of a default variant statement are as follows:
default variant = 5 default variant = 3,2
If a default variant statement has not been specified, the DCPL compiler assumes the first variant value specified on the compile line. Note that constant port expressions are not affected by the default variant statement. variant The variant statement, variant exp, is port specific. It specifies the protocol variant to be used when encoding and displaying protocol-specific statements on its port. An example of a variant statement is as follows:
{1} variant 29
8-33
Ixia
variable The variable statement, variable var_name[size][{}], is used to declare the variable var_name. If [size] is specified, the variable is a one-dimensional array; otherwise, it is a scalar variable. If {} is specified, the variable is port specific; otherwise, it is a general variable. All DCPL files compiled with the -Wimplicit option must have all of its variables defined, otherwise an error is displayed. If several DCPL files are linked into a script and reference a variable, you can ensure that the same variable declarations are used by declaring the common variables in an include file and having each DCPL file that uses the variables include this file. If an array is defined using the array statement, no other declaration is required Examples of the variable statement are as follows:
variable &addresses[1000*2] variable %names[5]{}
8.4.7
StatsView API DCPL commands are used to interface with a run-time statistics package called StatsView. See Chapter 16, Statistics Package, for details.
8.5
8.5.1
Functions
Integer Functions DCPL has the following integer functions. bitl The bitl function, bitl(strexp), assumes that strexp is a bit-field created by either bits or bitn. It returns, as an integer, the number of bits in strexp. For example:
bitl(bitn(5; #12)) returns 5
char The char function, char(strexp; exp), returns the integer value of the expth byte of strexp. Bytes are numbered from 1, not from 0. (Refer also to substr on page 8-51.) For example:
char(abc;1) returns #61 (ASCII a)
8-34
Ixia
decval The decval function, decval(strexp [; exp]), interprets strexp as a string of ASCII decimal digits and returns its integer value. If exp is specified, it is used as the index of the first character converted (counting from 1); otherwise, conversion starts at the beginning of strexp. (See also hexval on page 8-35.) For example:
decval(123foo) returns 123 decval(8765;3) returns 65
enum_value The enum_value(<name>;<label>) function is used to access the numeric enumerated values of information elements (or parameters) defined by certain protocols. The first parameter specifies the name of the information element. The second identifies the label for the enumerated value. The function returns the associated numeric value. (See also enum_value on page 8-47.) This value can be assigned to an appropriate variable or used immediately in an expression as shown in the following IPPRIM protocol example.
{1} locate status in %frame exp switch (char(%frame;&loc_index)) case (enum_value(status;success)): sprint Success... endcase case (enum_value(status;failure)): sprint Failure... endcase other: sprint Unexpected Status value endswitch
NOTE: enum_value() currently has a limitation that it will not process an enumerated field if the label being checked is a duplicate of another non-enumerated numeric field. In this case a compile error referencing the field is generated. hexval The hexval function, hexval(strexp [; exp]), interprets strexp as a string of ASCII hexadecimal digits and returns its integer value. If exp is specified, it is used as the index of the first character converted (counting from 1); otherwise, conversion starts at the beginning of strexp. (See also decval on page 8-35, hex on page 8-47, hexstring on page 8-48, and str2num on page 8-36.) For example:
hexval(123foo) returns #123f hexval(xya; 3) returns 10
len The len function, len(strexp), returns the number of bytes in strexp. For example:
len(abcde) returns 5
8-35
Ixia
num2bcd The num2bcd function, num2bcd(exp) converts exp into binary-coded decimal form. (Refer also to multibcd on page 8-49.) For example:
num2bcd(1234) returns #1234
pcomp The pcomp function, pcomp(strexp1; strexp2; exp), is best described in DCPL:
pcomp(strexp1; strexp2; exp) is equivalent to same(substr(strexp1; exp+1); strexp2)
same The same function, same(strexp1; strexp2 [; exp1 [; exp2]]), compares strexp1 with a substring of strexp2, returning 1 if they are the same and 0 otherwise. If exp1 is omitted, all of strexp2 is used in the comparison; if exp1 is present, it is used as the index of the byte at which comparison begins. Also, if exp1 is zero, comparison starts at the beginning. If exp2 is present and nonzero, it is used as the number of bytes to compare in both strings; otherwise, comparison ends at the end of strexp2. An example of the same function is as follows:
same(cdg; abcde; 3; 2) returns 1
str2num The str2num function, str2num(strexp), returns an integer whose bytes are the bytes of strexp. strexp can contain at most 4 bytes. An example of the str2num function is as follows:
str2num(a) str2num(abcd) returns #61 returns #61626364
8-36
Ixia
8.5.2
String Functions DCPL has the following string functions. addlen The addlen function, addlen(strexp; min; max [; op]), verifies the length of strexp and returns it, preceded by its length. The length is an ASN.1 length, coded in 13 bytes; see X.209 for details. min is the minimum valid length of strexp; max is the maximum valid length. If both min and max are 0, then 0 is the only valid length; otherwise, a max of 0 indicates no maximum length. op controls the functions action if strexps length is invalid: if op is 0, a single length byte of $00 is returned; if op is 1, the return value is the same as if the length were valid; other values of op are undefined. For all values of op, an invalid length causes a run-time error message to be displayed. Following are examples of the addlen function.
addlen(abc; 1; 3; 0) returns $03616263 addlen(abc; 1; 2; 0) returns $00 addlen(abc; 1; 2; 1) returns $03616263
add1len The add1len function, add1len(strexp; min; max [; op]), is the same as addlen, except that the length returned is always a single byte. strexp must be no longer than 255 bytes. Following are examples of the add1len function.
add1len(abc; 1; 3; 0) returns $03616263 add1len(abc; 1; 2; 0) returns $00 add1len(abc; 1; 2; 1) returns $03616263
add1lenplus The add1lenplus function, add1lenplus(strexp; min; max; extra [;op]), is the same as add1len, except that extra is added to the value of the length byte. Extra is not added when checking the length against min and max. Following is an example of the add1lenplus function.
add1lenplus(abc; 1; 3; 5; 0) returns $08616263
add2len The add2len function, add2len(strexp; min; max [; op]), is the same as addlen, except that the length returned is always exactly two bytes. Following are examples of the add2len function.
add2len(abc; 1; 3; 0) returns $0003616263 add2len(abc; 1; 2; 0) returns $0000 add2len(abc; 1; 2; 1) returns $0003616263
8-37
Ixia
add2lenplus The add2lenplus function, add2lenplus(strexp; extra), performs no length checks. It returns strexp with a two-byte length prepended. The length is the length of strexp, plus extra. Following is an example of the add2lenplus function.
add2lenplus(abc; 5) returns $0008616263
add3len The add3len function, add3len(strexp1; strexp2; strexp3), returns the following information concatenated together: a byte containing the length of strexp1; a byte containing the length of strexp2; a byte containing the length of strexp3; strexp1 itself; strexp2 itself; and strexp3 itself. Following is an example of the add3len function.
add3len($1234; $5678; $9abc) returns $020202123456789abc
addgenericlen The addgenericlen function, addgenericlen(str; min; max; operation [; op]), performs one of a number of length operations on str, based on the value of operation: If operation = 1, the following information is returned, concatenated together: a byte containing the length of str + 1 in four-octet units; and str itself. If operation = 2, the operation is the same as add2len, except that the length bytes have the most and least significant bytes swapped. If operation = 3, the following information is returned, concatenated together: a byte containing the length of str in three-octet units; and str itself. If operation = 4, the following information is returned, concatenated together: str length in 1-2 bytes, with bit 8 of first byte defined as extension; then str itself. For the str length if the extension bit is 0, the length is extended to the first nibble of the next byte. The length is as shown below.
8 7 6 5 4 3 2 1 --------------------------|ext| LSB | --------------------------| 1 | 0 0 0 |MSB | optional
Following are examples of the addgenericlen function.

addgenericlen($010203; 1; 100; 1) returns $01010203 addgenericlen($01020304; 1; 100; 1) returns $0201020304 addgenericlen($010203; 1; 100; 2) returns $0300010203 addgenericlen($010203; 1; 100; 3) returns $01010203 addgenericlen($010203; 1; 100; 4) returns $83010203
8-38
Ixia
addnlenplus The addnlenplus function, addnlenplus(strexp; min; max; width; extra [;op]), verifies the length of strexp and returns it, preceded by its length. The length field returned is exactly width bytes long. min is the minimum valid length of strexp; max is the maximum valid length. If both min and max are 0, then 0 is the only valid length; otherwise, a max of 0 indicates no maximum length. width is number of bytes used to represent the length of strexp; extra is added to the value of the length field. op controls the functions action if strexps length is not valid; if op is 0, a length field of value 0 is returned; if op is 1, the return value is the same as if the length were valid. Other values of op are undefined. For all values of op, an invalid length causes a run-time error message to be displayed. Following are examples of the addnlenplus function.
addnlenplus(abc; addnlenplus(abc; addnlenplus(abc; addnlenplus(abc; $00000007616263 1; 1; 1; 1; 2; 2; 2; 2; 1; 2; 2; 4; 0; 0; 2; 4; 0) 0) 0) 0) returns $03616263 returns $0003616263 returns $0005616263 returns
The function is useful when the length must fit in a certain number of bytes and the length field includes the length of a header preceding the length field. The function is limited to a maximum width of 4. align The align function, align(val), is used to align a byte string to a byte boundary. It is best used in byte string concatenation expressions. Alignment is carried out by padding the byte string with zeros until the next byte boundary. The align function can be considered similar to the pad function, but the syntax avoids the need to have nested pad statements. The byte alignment required is specified by val. Alignment is relative to the start of the frame or the last align(0) call. Following is an example of the align function.
%val = $aa,align(4),$bb,align(3),align(0),$cc,align(5),$dd %val = $aa000000bb00cc00000000dd
The align(4) sets the $bb field to start on a 4-byte boundary relative to the start of the frame, while the align(3) aligns the $cc to a 3-byte boundary. The align(0) resets the alignment reference such that the $dd is 5-byte aligned relative to the align(0) call. The equivalent pad statement would be:
%val = pad(pad($aa;4),$bb;3),pad($cc;5),$dd
8-39
Ixia
apn The apn function, apn(strexp), takes an ASCII string in the format <label1>.<label2>.<label3> and returns the ASCII string with each label preceded by a one-byte length of label. Following is an example of the apn function.
apn(www.ixiacom.com) returns $03,www, $08,ixiacom,$03,com
asn1int The asn1int function, asn1int(exp), returns exp, interpreted as signed, encoded in the fewest possible number of bytes. This is the encoding required by ASN.1. See X.209 for details. Following is an example of the asnlint function.
asn1int(#C8) returns $00C8 asn1int(-1) returns $FF
base64_decode The base64_decode function, base64_decode(strexp1; strexp2), is a C function that converts the input text string, strexp1, from base64 encoded to its binary format. strexp1 has a maximum length of 16 MB. It must only contain printable characters in the base64 set. strexp2 is the output binary data. If an error occurs during the decoding, strexp2 will have a length of zero, and error logs will be output to the display. Following is an example of the base64_decode function.
%input = ABCD %output = call base64_decode(%input; %output) if( len(%output) != 0) sprint hexstring(%output) // displays $001083 endif
base64_encode The base64_encode function, base64_encode(strexp1; strexp2), is a C function that converts the input sequence of binary data, strexp1, into its base64 encoded text string representation. strexp1 has a maximum length of 12 MB. It must be a valid DCPL string variable of length 1-12582912. strexp2 is the output text string. If an error occurs during the encoding, strexp2 will have a length of zero, and error logs will be output to the display. Following is an example of the base64_encode function.
%input = $000102 %output = call base64_encode(%input; %output) if( len(%output) != 0) sprint %output // displays string AAEC endif
8-40
Ixia
NOTE: The base64_decode and base64_encode functions only work on variables. In contrast, the decode_base64 and encode_base64 functions (see the descriptions of these functions on page 8-45) work on arbitrary string expressions and return their results directly so they can be used in further expressions. bcd The bcd function, bcd(strexp), assumes strexp to consist of ASCII decimal digits and returns it in binary-coded decimal format. If strexp contains an odd number of characters, a 0 nibble is appended to the result. (Refer also to multibcd on page 8-49.) Following is an example of the bcd function.
bcd(123) returns $1230
bcf The bcf function, bcf(strexp), assumes strexp to consist of ASCII hex digits and returns it in binary-coded decimal format with the nibbles of each byte swapped. If strexp contains an odd number of characters, an f nibble is appended to the result. A * character is mapped to a hex b nibble in the output. A # character is mapped to a hex c nibble in the output. (Refer also to multibcd on page 8-49.) Following is an example of the bcf function.
bcf(*#01234abcdef) returns $cb1032a4cbedff
bcs The bcs function, bcs(strexp), assumes strexp to consist of ASCII hex digits and returns it in binary-coded decimal format with the nibbles of each byte swapped. If strexp contains an odd number of characters, a 0 nibble is appended to the result. A * character is mapped to a hex b nibble in the output; a # character is mapped to a hex c nibble in the output. (Refer also to multibcd on page 8-49.) Following is an example of the bcs function.
bcs(*#01234abcdef) returns $cb1032a4cbed0f
bct The bct function, bct(strexp), assumes strexp to consist of ASCII hex digits and returns it in binary-coded decimal format with the nibbles of each byte swapped. If strexp contains an odd number of characters, a 0 nibble is appended to the result. A * character is mapped to a hex b nibble in the output; a # character is mapped to a hex c nibble in the output; and a 0 character is mapped to a hex a nibble in the output. (Refer also to multibcd on page 8-49.) Following is an example of the bct function.
bct(*#01234abcdef) returns $cb1a32a4cbed0f
8-41
Ixia
bitbls The bitbls function, bitbls(length; lb; strexp), returns a bit-field of length bits concatenated with strexp. The bit-field contains the length of strexp (in bytes) minus lb. Following is an example of the bitbls function.
bitbls(5; 1; $A3C2) returns the bit-field 00001 concatenated with $A3
bitcat The bitcat function, bitcat(bits; value; bits; value; ... ), assembles bit-fields into a byte string, packing each byte in most- to least-significant-bit order. Each bit-field is described by a bits-value pair: value is the value, and bits is the width of the field in bits. If bits is 0, value is packed into 8, 16, 24, or 32 bits as necessary to contain the value. Even though this bit-field is a multiple of 8 bits wide, it is not forced to be byte-aligned. Multi-byte fields are packed in most- to least-significant-byte order. If the final result is not a multiple of 8 bits, the last byte is filled by adding 0 bits. (Refer also to bitstr on page 8-44.) Following are examples of the bitcat function.
bitcat(3; #F; 4; 10) returns $F4 bitcat(0; #1122) returns $1122
bitis The bitis function, bitis(charset; strexp), returns a bit-field with each 8-bit character in strexp replaced by a 4-bit index in charset (counted from 0). If a character in strexp cannot be found in charset, a warning is generated. Any unused bits in the last octet are padded with zeros. Following are examples of the bitis function.
bitis(ABC; ABBC) returns $0112 bitis(ABC; CBBBA) returns $211100
bitls The bitls function, bitls(strexp; open), returns the length of strexp concatenated with strexp itself. If the length of strexp is less than or equal to 127, it is output as an aligned byte. Otherwise, it is output as an aligned two-byte number with the most significant bit set. When open is 0, zero-length strings are encoded as the empty string. Otherwise, zero-length strings are encoded as $00. Following are examples of the bitls function.
bitls(123; 0) returns $03,123 bitls(; 0) returns $00 bitls(; 1) returns $0100
8-42
Ixia
bitn The bitn function, bitn(bits; value), returns a bit-field that can be concatenated with bit-fields returned by other calls to bitn and bits. Concatenation is performed in most- to least-significant-bit order. The bit-field can also be used as a parameter to condstrexp or assigned to a string variable. Any other use promotes the bit-field to a byte string. bits is the size of the bit-field in bits; value, an integer, is its value; the least significant bits bits of value are used. (Refer also to bits on page 8-43.) Following is an example of the bitn function.
bitn(4; #26) returns the bit-field 0110
bitreverse The bitreverse function, bitreverse(strexp; op) reverses the order of the bits in strexp. It has two modes of operation: bytewise and bitwise. In bytewise operation, the bits of each byte are reversed, but the bytes remain in their original order. In bitwise operation, the entire string is treated as a bitstring and reversed. op specifies bytewise operation if 1 and bitwise operation if 0. (Refer also to reverse on page 8-51.) Following is an example of the bitreverse function.
bitreverse($010307; 1) returns $80C0E0 bitreverse($010307; 0) returns $E0C080
bits The bits function, bits(bits; value), returns a bit-field that can be concatenated with bit-fields returned by other calls to bitn and bits. Concatenation is performed in most- to least-significant-bit order. The bit-field can also be used as a parameter to condstrexp or assigned to a string variable. Any other use promotes the bit-field to a byte string. bits is the size of the bit-field in bits; value, a string, is its value; the most significant bits bits of value are used. (Refer also to bitn on page 8-43.) Following is an example of the bits function.
bits(9; $26AB) returns the bit-field 001001101
bitsubstr The bitsubstr function, bitsubstr(strexp; start; length), returns a bit-field containing a substring of strexp. The substring starts at bit start (counted from 0) and extends for length bits. A length of zero is not permitted. Following is an example of the bitsubstr function.
bitsubstr($12345678; 0; 8) returns $12 bitsubstr($12345678; 6; 5) returns bits(5;$88)
8-43
Ixia
bitstr The bitstr function, bitstr(bits; value; bits; value; ... ), assembles bit-fields into a byte string, packing each byte in least- to most-significant-bit order. Each bit-field is described by a bits-value pair: value is the value, and bits is the width of the field in bits. If bits is 0, value is packed into 8, 16, 24, or 32 bits as necessary to contain the value. Even though this bit-field is a multiple of 8 bits wide, it is not forced to be byte-aligned. Multi-byte fields are packed in least- to most-significant-byte order. If the final result is not a multiple of 8 bits, the last byte is filled by adding 0 bits. (Refer also to bitcat on page 8-42.) Following is an example of the bitstr function.
bitstr(3; #F; 4; 10) returns $57 bitstr(0; #1122) returns $2211
catsort The catsort function, catsort(exp; strexp1; strexp2; ... ), returns the concatenation of the strexps, with the strings sorted in ascending order. exp is the number of strings. Following is an example of the catsort function.
catsort(3; a; c; b) returns abc
chkbs The chkbs function, chkbs(strexp; nbits; fieldname), verifies that strexp contains a bitstring rather than a byte string. If strexp does contain a bitstring, it is returned as the functions value. If it does not, an error message is displayed and a bitstring of nbits 0 bits is returned. The fieldname parameter is an arbitrary string and is named in the error message as the protocol field for which a bitstring value was expected. Following are examples of the chkbs function.
chkbs(bitn(6;12); 5; 'leg_id') returns bitn(6; 12) chkbs('x'; 5; 'leg_id') returns bitn(5; 0)
chklen The chklen function, chklen(strexp; min; max [; op]), verifies the length of strexp. min is the minimum valid length of strexp; max is the maximum valid length. If both min and max are 0, 0 is the only valid length; otherwise, a max of 0 indicates no maximum length. op controls the functions action if strexps length is invalid: if op is 0, the null string is returned; if op is 1, the return value is the same as if the length were valid; other values of op are undefined. For all values of op, an invalid length causes a run-time error message to be displayed. Following are examples of the chklen function.
chklen(abc; 1; 3; 0) returns $616263 chklen(abc; 1; 2; 0) returns $ (null string) chklen(abc; 1; 2; 1) returns $616263
8-44
Ixia
condstrexp The condstrexp function, condstrexp(exp; strexp1; strexp2), returns strexp1 if exp is nonzero, otherwise it returns strexp2. Following are examples of the condstrexp function.
condstrexp(1; yes; no) returns yes condstrexp(0; yes; no) returns no
crc24 The crc24 function, crc24(strexp), returns strexps CRC-24 value using the generator polynomial #BBA1B5 (from GSM 04.54). Following is an example of the crc24 function.
crc24($0000) returns $6064EC
crc32 The crc32 function, crc32(strexp), returns strexps CRC-32 value using the standard CRC-32 generator polynomial #04C11DB7. Following is an example of the crc32 function.
crc32($0000) returns $FF489B82
decode_base64 The decode_base64 function, decode_base64(strexp), interprets strexp as a base64 encoded string, and returns the decoded binary string. strexp can be any DCPL string expression that evaluates to a valid base64 string. If an error occurs during the decoding, the returned string will have a length of zero, and error logs will be output to the display. Following is an example of the decode_base64 function.
decode_base64('ABCD') returns $001083
encode_base64 The encode_base64 function, encode_base64(strexp), returns strexp encoded into a base64 printable text string. strexp can be any DCPL string expression, provided its base64 encoding is within the maximum length for a DCPL string variable. If an error occurs during the encoding, the returned string will have a length of zero, and error logs will be output to the display. Following is an example of the encode_base64 function.
encode_base64($000102) returns 'AAEC'
encode_list The encode_list function, encode_list(label [, sublabel] ; value), where label is the label for a list, optional sublabel is the label of the IE sequence that the label is made of, and value is the value of a list item in this list, returns the encoded value of the list item. Following are examples of the encode_list function.
8-45
Ixia
encode_list ( no_Split_in_TFCI; \ [ctfc2bit=2 signalledGainFactors = [fdd = \ [betaC=7 betaD=15]]]) returns bits(25;$42003f80)
The above example is from the NBAP protocol where no_Split_in_TFCI is a list of only TFCS_TFCSListItem items. The standard encode_list statement is limited in that the IE list it is encoding must have a unique label that can be found in the protocol definition. For example, in the statement above, no_Split_in_TFCI must be unique and the definition occurs only once in the protocol definition. This limitation causes problems when a label can have more than one definition and may appear in several IEs sequence lists, for example:
<information1> ::= Information = [ <definitionA> ]... <information2> ::= Information = [ <definitionB> ]... <information3> ::= Information = [ <definitionC> ]...
Here Information has more than one definition and therefore the encode_list statement is ambiguous. The solution is to specify more information about the IE sequence in the list to make the label unambiguous. The sublabel helps to choose the item to encode in this case. If sublabel is not provided in a situation like this, the first choice in the list is used to encode the message. This can lead to parse errors if value does not match the definition of the item selected. Setting the sublabel to the correct item helps to avoid this type of problem.
encode_list ( information, \ definitionB; \ [defb=...])
The encode_list function is supported only for some protocols. More details can be found in the specific protocol manuals. encoded_list The encoded_list function, encoded_list(number ; strexp), where strexp is the encoded value of a list and number is the number of list items in this list, can be used as the value of the list in the frame. Note that number can be a numeric expression such as &count+1. Following is an example of the encoded_list function used in an NBAP message.
{1}aal_data_req param_data = [ \ initiatingMessage_radioLinkSetup_fdd ... ... no_Split_in_TFCI = encoded_list (1024; %list)...]
The encoded_list function is supported only for some protocols. More details can be found in the specific protocol manuals.
8-46
Ixia
enum_value The enum_value(<name>;<label>) function is used to access the string enumerated values of information elements (or parameters) defined by certain protocols. The first parameter specifies the name of the information element. The second identifies the label for the enumerated value. The function returns the associated string value. (See also enum_value on page 8-35.) This can be assigned to an appropriate variable or used immediately in an expression as shown in the following AIN protocol example.
{1} locate pop_code in %frame %opcode = substr(%frame;&loc_index;&loc_length) switch %opcode case exp same(%opcode;enum_value(pop_code;infoCollected)): sprint infoCollected... endcase case exp same(%opcode;enum_value(pop_code;infoAnalyzed)): sprint infoAnalysed... endcase other: sprint Unexpected pop_code value endswitch
NOTE: enum_value() currently has a limitation that it does not process an enumerated field if the label being checked is a duplicate of another non-enumerated numeric field. In this case, a compile error referencing the field is generated. findstring The findstring function, findstring(strexp1; strexp2), finds the first occurrence of the substring strexp2 in the string strexp1 and returns an index (counting from 1) into strexp1 where strexp2 is found. If strexp2 is not found in strexp1, zero is returned. Following are examples of the findstring function.
findstring(abcde; bcd) returns 2 findstring(abcde; def) returns 0
hex The hex function, hex(exp), returns a string of ASCII digits representing the value of exp in hexadecimal. The result is guaranteed to have an even number of digits; a leading 0 is added if necessary. (Refer also to hexval on page 8-35, str2num on page 8-36, and hexstring on page 8-48.) Following is an example of the hex function.
hex(#89A) returns 089A
8-47
Ixia
hexstring The hexstring function, hexstring(strexp), returns an ASCII string, with each character representing a nibble of strexp. If strexp is a bit-field constructed using bitn (page 8-43) and/or bits (page 8-43), the string returned is a bits expression. (Refer also to hexval on page 8-35, str2num on page 8-36, and hex on page 8-47.) Following are examples of the hexstring function.
hexstring($12ab) returns 12ab hexstring(bitn(1;1)) returns bits(1;$80)
ipaddr The ipaddr function, ipaddr(ip-strexp) converts an IP address ip-strexp from different standard formats (as shown in the following examples) to a common format suitable for UNIX socket calls. Following are examples of the ipaddr function. Usage for IPv4 address:
ipaddr(192,168,0,85) returns $c0a80055 ipaddr($c0a80055) returns $c0a80055 ipaddr(192.168.0.85) returns $c0a80055
Usage for IPv6 address:

ipaddr($0001cd5600000000080020fffe7d3dd2) returns $0001cd5600000000080020fffe7d3dd2
iptext The iptext function, iptext(ip_strexp) converts an IP address ip-strexp from different formats (as shown in the following examples) to a common format suitable for UNIX socket calls. Following are examples of the iptext function. Usage for IPv4 address:
iptext(192.168.0.85) returns $c0a80055
Usage for IPV6 address:

iptext(fe80:0:0:0:a00:20ff:fea6:c3f2) returns $fe800000000000000a0020fffea6c3f2 iptext(fe80::a00:20ff:fea6:c3f2) returns $fe800000000000000a0020fffea6c3f2
Usage for IPV4 embedded in IPV6 address:

iptext(::192.168.0.85) returns $000000000000000000000000c0a80055 iptext(::ffff:192.168.0.85) returns $00000000000000000000ffffc0a80055
8-48
Ixia
multibcd The multibcd function, multibcd(strexp; op), assumes strexp to consist of ASCII hex digits and returns it in one of several binary-coded decimal formats, according to op: If op = 0, multibcd returns the same result as bcd (page 8-41). If op = 1, multibcd returns the same result as bcs (page 8-41). If op = 2, multibcd returns the same result as bcf (page 8-41). If op = 3, multibcd returns the same result as bct (page 8-41). If op = 4, digits are packed in most- to least-significant order; only decimal digits, * and # are allowed; the resulting string must be exactly 5 bytes long; f is used as the filler digit; * is coded as the nibble a; and # is coded as the nibble b. If op = 5, digits are packed in least- to most-significant order; 0 is used as the filler digit; * is coded as the nibble d; and # is coded as the nibble e. If op = 6, digits are packed in least- to most-significant order; f is used as the filler digit; * is coded as the nibble a; # is coded as the nibble b; a is coded as the nibble c; b is coded as the nibble d; c is coded as the nibble e; and f is coded as the nibble f. If op = 7, digits are packed in least- to most-significant order with the nibbles of each byte swapped; f is used as the filler digit; only decimal digits are allowed.
Following are examples of the multibcd function.

multibcd(*#01234; 4) returns $ab01234fff multibcd(*#01234adef; 5) returns $ed1032a4ed0f multibcd(*#012345abc; 6) returns $ba103254dcfe multibcd(123; 7) returns $2103
multicrc The multicrc function, multicrc(str; op), performs one of a number of CRC calculations on str, based on the value of op: If op = 1, the high-order seven bits of str are assumed to be unused. The seven-bit CRC is applied to the low-order bit and the remaining bytes and written into the unused seven bits. The resulting string is returned. The generator polynomial is #45. If op = 2, the 16-bit CRC is computed on str. The return value is str with the CRC appended. The generator polynomial is #8005. If op = 3, the 16-bit oness complement of the ones complement sum of all 16-bit words in str. The return value is str with the
8-49
Ixia
checksum at bytes 11 and 12. This is used to generate IP header checksums. If op = 4, the 10-bit CRC and a 6-bit CRC are computed on parts of the str. The 6-bit CRC is calculated on the first two bytes of the str using generator polynomial #2f, and the 10-bit CRC is calculated on the str starting from byte position 5 using polynomial #233. Bytes 3 and 4 of str was replaced by 6-bit CRC and 10-bit CRC fields together. If op = 5, the 6-bit CRC is computed on str; the return value is str with the CRC appended. The generator polynomial is #2f. If op = 6, the 32-bit checksum is computed on str using the Adler-32 algorithm. The return value is str with bytes 9, 10, 11, and 12 replaced by checksum bytes. These bytes are initialized to zeros in str. If op = 7, the 16-bit CRC is computed on str. The return value is str with the CRC appended. The generator polynomial is #1021, which is also known as CRC-CCITT. If op = 8, the 32-bit checksum is computed on str using the CRC32C algorithm. The return value is str with bytes 9, 10, 11, and 12 replaced by checksum bytes. These bytes are initialized to zeros in str. If op = 9, the 16-bit oness complement of the ones complement sum of all 16-bit words in str. If str is an odd number of bytes long, a zero is added to the end. The return value is str with the checksum at bytes 3 and 4. These bytes are initialized to zeros in str before the checksum calculation. This is used to generate ICMP checksums. If op = 10, the 11-bit CRC is applied to the low-order bit of the first byte, the four low-order bits of the second byte, and the remaining bytes. The result is written into the unused 11 bits of the first two bytes (seven high-order bits into the first byte and the remaining four bits into the second byte). The resulting string is returned. The generator polynomial is #307. If op = 11, the 16-bit header checksum is inserted to the offset byte of the input string which is 11. This is used for GRE checksum_present.
Following are examples of the multicrc function.

multicrc($1234; 1) returns $7C34 multicrc($1234; 2) returns $1234ECBB multicrc($123456789012345678900000; 3) returns $123456789012345678905a5a multicrc($123400001122334455;4) returns $12341ff91122334455 8-50 IxCatapult Software Reference Manual, Release 20.1
Ixia
multicrc($1234; 5) returns $12341c multicrc($1122334455667700000000; 6) returns $11223344556677000d0f01
null
The null function, null, returns the empty string. For example:
null returns
pad The pad function, pad(strexp; len [; fill]), modifies strexp if required, by appending a string of $00 bytes to the end of strexp to make the length of the returned string be a multiple of len. The optional fill parameter specifies the value of the filler byte. Following are examples of the pad function.
pad('abc'; 4)returns $61626300 pad('abcde'; 4)returns $6162636465000000 pad('abc'; 10)returns $61626300000000000000 pad('abc'; 4; #ff)returns $616263ff
This function is useful when a string must be of a specific length and must be padded with zero bytes at the end. reverse The reverse function, reverse(strexp), returns strexp with its bytes in reverse order. (Refer also to bitreverse on page 8-43.) Following is an example of the reverse function.
reverse(abcde) returns edcba
string The string function, string(exp), returns a string of ASCII digits representing the value of exp in decimal. (Refer also to decva,expl, page 8-54.) Following is an example of the string function.
string(676) returns 676
strrepeat The strrepeat function, strrepeat(strexp; exp), returns strexp repeated exp times. Following is an example of the strrepeat function.
strrepeat(a; 5) returns aaaaa
substr The substr function, substr(strexp; start [; length [; bitoffset]]), returns a substring of strexp. The substring starts at character start (counted from 1) and extends for length characters. If length is zero or is omitted, the substring ends at the end of strexp. If length and bitoffset are included, the substring is shifted left by bitoffset bits (up to 7), truncating the final byte. If the length is one and the bitoffset is provided, it returns the byte without any shifting. (Refer also to char on page 8-34.) Following are examples of the substr function.
8-51
Ixia
substr(abcde; 3) returns cde substr(abcde; 2; 3) returns bcd substr(abcdr; 2; 3; 5) returns Ll
touppercase The touppercase function, touppercase(strexp), returns strexp with all characters converted to upper case. Following is an example of the touppercase function.
touppercase( abc ) returns ABC
trimleft The trimleft function, trimleft(strexp), returns strexp with leading white spaces (if any exist) removed. Following is an example of the trimleft function.
trimleft( abc ) returns abc
trimright The trimright function, trimright(strexp), returns strexp with trailing white spaces (if any exist) removed. Following is an example of the trimright function.
trimright( abc ) returns abc
wspaddlen The wspaddlen function, wspaddlen(strexp; min; max [; op]), verifies the length of strexp and returns it, preceded by its length. The length is encoded as a Value-length per WAP-230-WSP Approved Version 5-July-2001 section 8.4.2.2. min is the minimum valid length of strexp. max is the maximum valid length. If both min and max are 0, 0 is the only valid length; otherwise, a max of 0 indicates no maximum length. op controls the functions action if strexps length is not valid: If op = 0, a single length byte of $00 is returned. If op = 1, the return value is the same as if the length were valid. Other values of op are undefined.
For all values of op, an invalid length causes a run-time error message to be displayed. Following are examples of the wspaddlen function.
wspaddlen(abc; 1; 3; 0) returns $03616263 wspaddlen($0102...28; 1; 0; 0) returns $1f280102...28
wspintval The wspintval function, wspintval(strexp; type), interprets strexp as a multi-octet integer in big-endian order (that is, MS octet first) and encodes it according to WAP-230-WSP Approved Version 5-July-2001 section 8.4.2.1 and 8.4.2.3.
8-52
Ixia
The encoding is determined by type: If type = 0, it is an integer-value (choice of either short-integer or long-integer). Values in the range 0-127 are treated as short-integers. Values greater than or equal to 128 are treated as long-integers (see below). If type = 1, it is a short-integer (an integer in the range 0-127). It is encoded as one octet with the most significant bit set to 1. For example, an integer 1 is encoded as 0x81. If type = 2, it is a long-integer. A long-integer is encoded as <short-length> <multi-octet-integer>. <short-length> is an integer in the range 0-30, which represents the length of the following <multi-octet-integer>. <multi-octet-integer> is the integer with 1-30 bytes in big-endian format with the minimum number of bytes used. For example, an integer 1 encoded as a long-integer is 0x0101. If type = 3, it is a uintvar (a variable-length unsigned integer). Each octet of the integer is comprised of a single continue bit and 7 bits of payload. All octets must set the continue bit to 1 except the last octet, which must set the continue bit to 0. For example, the value 0x87A5 is encoded in 3 octets as 0x828725.
Following are examples of the wspintval function.

wspintval($34; 0) wspintval($94; 0) wspintval($12345678; 0) returns $b4 returns $0198 returns $0412345678
8-53
Ixia
8.5.3
Dynamic TDM Channel Functions closechannel The closechannel function, closechannel(port; channel_id), where port is the context port number, and channel_id is the logical channel identifier, closes the TDM channel with the given channel_id on the port, and returns 1 or 0. If 1 is returned, the channel is closed successfully. This function is only valid for DCPL scripts running on the J1/E1/T1 PPCI board. See Chapter 14, Dynamic TDM Channels for more details. The following example closes channel 5 on port 1.
&ok = closechannel(1;5)
openchannel The openchannel function, openchannel(channel_id; port; channel_type; ... ), opens a TDM channel on the port with the given channel parameters and returns a logical channel identifier for the channel. The expected function input parameters vary depending on the value of channel_type, which identifies if the channel is defined as freeform, 64 kb/sec, 56 kb/sec, or low rate. See the following table for further details. channel_id is the user-defined channel identifier. If channel_id is 0, the function returns an arbitrary channel identifier; otherwise, it returns the provided channel_id. The maximum value for channel_id is 512. The same channel_id can be used for different board ports.
&channel_type value 0 (freeform) Function Call
openchannel(channel_id; port; 0; link; tdmbitmap)

Opens a channel as defined with tdmbitmap which is a 32-byte strexp where each byte represents a timeslot; such as byte 1 corresponds to the timeslot 0, byte 2 corresponds to the timeslot 1 and so on. If value of byte is 0xff -> 64 kb/sec channel If value of byte is 0x7f -> 56 kb/sec channel If value of byte is 0x01 -> 8 kb/sec channel Example 1:
%tdmbitmap= $0000ff00ff0000000000000000000000000000000000000000000 00000000000 &chn_id = openchannel(5; 1; 0; 1; %tdmbitmap)

Opens a 64 kb/sec channel on link 1 with timeslots 2 and 4. If the function call is successful, it returns &chn_id = 5, otherwise &chn_id = 0.
8-54
Ixia
&channel_type value 1 (64 kb/sec)
Function Call
openchannel(channel_id; port; 1; link; timeslot; timeslot(optional); ...)

Opens a 64 kb/sec channel on the given timeslot(s). Multiple timeslots could be assigned for a channel. Example 2:
&chn_id = openchannel(&channel_id; &port; 1; 1; 2; 4)

Opens the same channel as in Example 1. 2 (56 kb/sec)
openchannel(channel_id; port; 2; link; timeslot; timeslot(optional); ...)

Opens a 56 kb/sec channel on the given timeslot(s). Multiple timeslots could be assigned for a channel. Example 3:
&chn_id = openchannel(&channel_id; &port; 2; 1; 2; 4)

Opens a 56 kb/sec channel on link 1 and timeslots 2 and 4. 3 (low rate)
openchannel(channel_id; port; 3; link; timeslot; bitpattern)

Opens a low rate (32/16/8 kb/sec) channel on the given timeslot according to the bitpattern value as below: 8 kb/sec ----> &bitpattern = 1 16 kb/sec ---> &bitpattern = 3 32 kb/sec ---> &bitpattern = 15 Example 4:
&bitpattern = 1 &chn_id = openchannel(&channel_id; &port; 3; 1; 2; &bitpattern)

Opens a 8 kb/sec channel on link 1 and timeslot 2.
The function returns 0 (not a valid channel identifier) if an error occurs and the channel is not opened successfully. In this case, it is recommended to check the special DCPL variable &dcpl_errno for possible error codes (see &dcpl_errno on page 8-84). This function is only valid for DCPL scripts running on the J1/E1/T1 PPCI board. See Chapter 14, Dynamic TDM Channels for more details.
8-55
Ixia
8.5.4
Field Reference Functions Field reference has the following functions. For detailed information on field reference, see Section 8.6, Field Reference, on page 8-75. decompose The decompose function, decompose string_variable, completely decodes the message frame in string_variable into an internal cache. This cache is used by field reference syntax to extract one or more information elements. exists The exists function, exists (%frame..field), checks the existence of a field in a message and returns an integer value of 0 if the field does not exist in the message and a 1 if the field is found in the message. Its argument must be the field reference notation as defined in Section 8.6, Field Reference, on page 8-75. The exists function is port specific. Following is an example of the exists function for a BICC message.
{1}if exists (%frame.transfer_req.user_data.acm.bci) ... endif
howmany The howmany function, howmany (%frame..field), returns the total number of appearances of the field in the message and returns an integer value of 0 if the field does not exist in the message. Its argument must be the field reference notation as defined in Section 8.6, Field Reference, on page 8-75. Following is an example of the howmany function for an ISUP message.
&count = howmany(%frame.rel.sact.code)
NOTE: The appearance of the field in question must be 1. If it is specified as any other value, it is ignored and assumed as 1. Using the howmany function causes an automatic decompose to ensure the entire message is traversed.
8-56
Ixia
8.5.5
Cryptographic Functions All the cryptographic functions are C procedures; therefore, to call them in DCPL scripts, please use call <function()> format. All string variables should be defined before passing them in the function, even the strexp in which the result is expected. aes_cmac The aes_cmac function, aes_cmac(strexp1;strexp2;keystr;result), generates Cipher-based Message Authentication Code (CMAC) with the 128-bit Advanced Encryption Standard (AES). strexp1 is the data used for CMAC generation. keystr is the 16-byte (128-bit) key string. strexp2 is the generated 16-byte CMAC string. result indicates if aes_cmac() is successful (1) or not (0). Example:
%cbc_key=$2b7e151628aed2a6abf7158809cf4f3c %cbc_data=$6bc1bee22e409f96e93d7e117393172aae2d8a571e03ac9c9eb76fa c45af8e5130c81c46a35ce411 %cbc_cmac=$dfa66747de9ae63030ca32611497c827 %cbc_output='' call aes_cmac(%cbc_data;%cbc_output;%cbc_key;&result)
generates CMAC $dfa66747de9ae63030ca32611497c827, stores it in %cbc_output, and returns &result = 1. aes_decrypt The aes_decrypt function, aes_decrypt(mode;strexp1;strexp2;...;result), decrypts the strexp1 data using the AES algorithm and stores the plain text in strexp2. The variable result indicates if the decryption was successful (1) or not (0). The variable mode identifies the AES encryption mode: AES-ECB (0) or AES-CBC (1). The expected function input parameters are different depending on the value of mode. For AES-ECB:
aes_decrypt(0;strexp1;strexp2;keystr;result)
For AES-CBC:
aes_decrypt(1;strexp1;strexp2;keystr;ivstr;result)
keystr is a 16-byte, 24-byte, or 32-byte string used as the 128-bit, 192-bit, or 256-bit AES key, respectively. ivstr is the 16-byte initialization vector. Note that ivstr is updated after the function call.
8-57
Ixia
Example: NOTE: Also see the example under the description of aes_encrypt on page 8-59.
define CBC_MODE = 1 %cbc_key_128=$2b7e151628aed2a6abf7158809cf4f3c %cbc_key_192=$8e73b0f7da0e6452c810f32b809079e562f8ead2522c6b7b %cbc_key_256=$603deb1015ca71be2b73aef0857d77811f352c073b6108d72d98 10a30914dff4 %cbc_iv=$000102030405060708090a0b0c0d0e0f %cbc_plaindata=$6bc1bee22e409f96e93d7e117393172aae2d8a571e03ac9c9e b76fac45af8e5130c81c46a35ce411e5fbc1191a0a52eff69f2445df4f9b17ad2b 417be66c3710 %cbc_encrypteddata_128=$7649abac8119b246cee98e9b12e9197d5086cb9b50 7219ee95db113a917678b273bed6b8e3c1743b7116e69e222295163ff1caa1681f ac09120eca307586e1a7 %cbc_encrypteddata_192=$4f021db243bc633d7178183a9fa071e8b4d9ada9ad 7dedf4e5e738763f69145a571b242012fb7ae07fa9baac3df102e008b0e2798859 8881d920a9e64f5615cd %cbc_encrypteddata_256=$f58c4c04d6e5f1ba779eabfb5f7bfbd69cfc4e967e db808d679f777bc6702c7d39f23369a9d9bacfa530e26304231461b2eb05e2c39b e9fcda6c19078c6a9d1b %cbc_output=''
If the above data is provided to the following functions:

%iv=%cbc_iv call aes_decrypt(CBC_MODE;%cbc_encrypteddata_128;%cbc_output;%cbc_key_1 28;%iv;&result)
or
or
generates plain text $6bc1bee22e409f96e93d7e117393172aae2d8a571e03ac9c9eb76fac45af8e 5130c81c46a35ce411e5fbc1191a0a52eff69f2445df4f9b17ad2b417be66c3 710, stores it in %cbc_output, and returns &result = 1.
8-58
Ixia
aes_encrypt The aes_encrypt function, aes_encrypt(mode;strexp1;strexp2;...;result), encrypts the strexp1 data using the AES algorithm and stores the ciphertext in strexp2. The variable result indicates if the encryption was successful (1) or not (0). The variable mode identifies the AES encryption mode: AES-ECB (0) or AES-CBC (1). AES in ECB mode is the basic AES encryption routine that encrypts or decrypts a single 16-byte data in electronic code book (ECB) mode. AES in AES-CBC mode encrypts using the cipher-block-chaining (CBC) mode of AES. The expected function input parameters are different depending on the value of mode. For AES-ECB:
aes_encrypt(0;strexp1;strexp2;keystr;result)
For AES-CBC:
aes_encrypt(1;strexp1;strexp2;keystr;ivstr;result)
keystr is a 16-byte, 24-byte, or 32-byte string used as the 128-bit, 192-bit, or 256-bit AES key, respectively. ivstr is the 16-byte initialization vector. The AES algorithm expects the input data length to be a multiple of 16 bytes. If the length is not a multiple of 16 bytes, the input data is padded with zero bytes. The output strexp2 is always returned as a multiple of 16 bytes. Note that ivstr is updated after the function call. Example:
define CBC_MODE = 1 %cbc_key_128=$2b7e151628aed2a6abf7158809cf4f3c %cbc_key_192=$8e73b0f7da0e6452c810f32b809079e562f8ead2522c6b7b %cbc_key_256=$603deb1015ca71be2b73aef0857d77811f352c073b6108d72d98 10a30914dff4 %cbc_iv=$000102030405060708090a0b0c0d0e0f %cbc_plaindata=$6bc1bee22e409f96e93d7e117393172aae2d8a571e03ac9c9e b76fac45af8e5130c81c46a35ce411e5fbc1191a0a52eff69f2445df4f9b17ad2b 417be66c3710 %cbc_encrypteddata_128=$7649abac8119b246cee98e9b12e9197d5086cb9b50 7219ee95db113a917678b273bed6b8e3c1743b7116e69e222295163ff1caa1681f ac09120eca307586e1a7 %cbc_encrypteddata_192=$4f021db243bc633d7178183a9fa071e8b4d9ada9ad 7dedf4e5e738763f69145a571b242012fb7ae07fa9baac3df102e008b0e2798859 8881d920a9e64f5615cd %cbc_encrypteddata_256=$f58c4c04d6e5f1ba779eabfb5f7bfbd69cfc4e967e db808d679f777bc6702c7d39f23369a9d9bacfa530e26304231461b2eb05e2c39b e9fcda6c19078c6a9d1b
8-59
Ixia
%cbc_output=''

%iv=%cbc_iv call aes_encrypt(CBC_MODE; %cbc_plaindata;%cbc_output;%cbc_key_128;%iv;&result)
generates ciphertext as $7649abac8119b246cee98e9b12e9197d5086cb9b507219ee95db113a917678 b273bed6b8e3c1743b7116e69e222295163ff1caa1681fac09120eca307586e 1a7, stores it in %cbc_output, and returns &result = 1.
generates ciphertext as $4f021db243bc633d7178183a9fa071e8b4d9ada9ad7dedf4e5e738763f6914 5a571b242012fb7ae07fa9baac3df102e008b0e27988598881d920a9e64f561 5cd, stores it in %cbc_output, and returns &result = 1.
generates ciphertext as $f58c4c04d6e5f1ba779eabfb5f7bfbd69cfc4e967edb808d679f777bc6702c 7d39f23369a9d9bacfa530e26304231461b2eb05e2c39be9fcda6c19078c6a9 d1b, stores it in %cbc_output, and returns &result = 1. compute_masterkey The compute_masterkey function, compute_masterkey(algo;...;strexp;result), generates the RSA or Diffie-Hellman master key and puts it in strexp. result indicates if the key generation was successful (1) or not (0). algo identifies the algorithm for which the master key is to be generated. The expected function input parameters are different depending on the value of algo. For RSA:
compute_masterkey(algo;strexp1; strexp2; strexp3; len; strexp4;result)
strexp1 is the secret, strexp2 is the label, strexp3 is the seed, and len specifies the length of the master key. The generated master key is returned in strexp4. This is compliant to the master key generation described in RFC2246. For Diffie-Hellman:
compute_masterkey(algo;strexp1; strexp2; strexp3; strexp4;result)
8-60
Ixia
strexp1 is the DH public value, strexp2 is the DH private key and strexp3 is the DH prime number. The generated master key is stored in strexp4. Success or failure is indicated by the result value 1 or 0, respectively. Example:
If the above generated values of the DH keys are provided to the following function %dh_mskey='' call compute_masterkey(3;%dh_pub; %dh_priv;%dh_prime;%dh_mskey;&result) generates DH masterkey '2d1a304b80fa5c99' and store it in %dh_mskey and result = 1. %secret = 'abcdefg' %label='masterkey' %seed ='wrft' %rsa_mskey='' call compute_masterkey(1;%secret;%label;%seed;48;%rsa_mskey;&result) generates ' 9c62412b2dfa18a0e06c92a642051f33b2fb59da23935174d6098a0be3939d5c30 c14b87f413bff8f260249194589c90 ' and store it in %rsa_mskey and result = 1.
decrypt_data The decrypt_data function, decrypt_data(algo;strexp1;strexp2;strexp3;strexp4;strexp5;strex p6;strexp7;strexp8;strexp9;strexp10;result) decrypts the strexp1 data using the RSA private key parameters and stores the plain text in strexp2. strexp3 is the RSA public exponent e. strexp4 is the RSA private exponent d. strexp5 is the RSA modulus n. strexp6 is the prime factor p of n. strexp7 is the prime factor q of n. strexp8 is the d mod (p-1). strexp9 is the d mod (q-1). strexp10 is the Chinese Remainder Theorem coefficient q-1 mod p. algo identifies the algorithm to be used for decryption. Currently, decryption is supported only for RSA, hence the value of algo should always be 1. The result variable indicates if decryption was successful (1) or not (0). Example: If the above generated values of the RSA keys and %rsa_encrypt are provided to the following function
call decrypt_data(1;%rsa_encrypt;%rsa_decrypt;%rsa_pub;%rsa_priv;%rsa_m od;%prime1;%prime2;%exp1;%exp2;%coefficient;&result) returns 'abdcsdfjlsdg' in rsa_decrypt and 1 in result.
8-61
Ixia
des_decrypt The des_decrypt function, des_decrypt(mode;strexp1;strexp2;...;result), decrypts the strexp1 data using the DES algorithm and stores the plain text in strexp2. The variable result indicates if the decryption was successful (1) or not (0). The variable mode identifies the DES encryption mode: DES_ECB (0), DES_CBC (1), or 3DES_EDE_CBC (2). See des_encrypt on page 8-63 for more details about these DES modes. The expected function input parameters are different depending on the value of mode. For DES_ECB:
des_decrypt(0;strexp1;strexp2;keystr;result)
keystr is an 8-byte string used as the 64-bit DES key. For DES_CBC:
des_decrypt(1;strexp1;strexp2;keystr1;ivstr;result)
For 3DES_ECE_CBC:
des_decrypt(2;strexp1;strexp2;keystr1;keystr2;keystr3;ivstr;result )
strexp1 should be a multiple of 8 bytes since the DES encrypted data length is always a multiple of 8 bytes. keystr1, keystr2, and keystr3 are 8-byte strings used as the 64-bit DES keys. ivstr is the 8-byte initialization vector. Note that ivstr is updated after the function call. Example: NOTE: Also see the example under the description of des_encrypt on page 8-63.
define ECB_MODE = 0 define CBC_MODE = 1 define TDES_CBC_EDE_MODE = 2 %ecb_key = $07A1133E4A0B2686 %ecb_plaindata=$0248D43806F67172 %ecb_encrypteddata = $868EBB51CAB4599A %ecb_output = '' %cbc_plaindata=$37363534333231204E6F77206973207468652074696D652066 6F722000000000 %cbc_key1=$0123456789abcdef %cbc_key2=$f1e0d3c2b5a49786 %cbc_key3=$fedcba9876543210 %cbc_iv=$fedcba9876543210 %cbc_encrypteddata1 =$ccd173ffab2039f4acd8aefddfd8a1eb468e91157888ba681d269397f7fe62b4 %cbc_encrypteddata2 =$3fe301c962ac01d02213763c1cbd4cdc799657c064ecf5d41c673812cfde9675 %cbc_output = ''
8-62
Ixia
call des_decrypt(ECB_MODE;%ecb_encrypteddata;%ecb_output;%ecb_key;&resu lt)
generates plain text $0248D43806F67172, stores it in %ecb_output, and returns &result = 1.

%iv=%cbc_iv call des_decrypt(CBC_MODE; %cbc_encrypteddata1;%cbc_output;%cbc_key1;%iv;&result)
generates plain text $37363534333231204E6F77206973207468652074696D6520666F7220000000 0, stores it in %cbc_output, and returns &result = 1.

%iv=%cbc_iv call des_decrypt(TDES_CBC_EDE_MODE; %cbc_encrypteddata2; %cbc_output;%cbc_key1;%cbc_key2;%cbc_key3;%iv;&result)
generates plain text $37363534333231204E6F77206973207468652074696D6520666F7220000000 0, stores it in %cbc_output, and returns &result = 1. des_encrypt The des_encrypt function, des_encrypt(mode;strexp1;strexp2;...;result), encrypts the strexp1 data using the DES algorithm and stores the ciphertext in strexp2. The variable result indicates if the encryption was successful (1) or not (0). The variable mode identifies the DES encryption mode: DES_ECB (0), DES_CBC (1), or 3DES_EDE_CBC (2). DES in ECB mode is the basic DES encryption routine that encrypts or decrypts a single 8-byte data in electronic code book (ECB) mode. DES in DES_CBC mode encrypts using the cipher-block-chaining (CBC) mode of DES. DES in 3DES_EDE_CBC mode implements outer triple CBC DES encryption with three keys. The expected function input parameters are different depending on the value of mode. For DES_ECB:
des_encrypt(0;strexp1;strexp2;keystr;result)
keystr is an 8-byte string used as the 64-bit DES key. In this mode strexp1 is expected to be 8 bytes. For DES_CBC:
des_encrypt(1;strexp1;strexp2;keystr1;ivstr;result)
8-63
Ixia
For 3DES_ECE_CBC:
des_encrypt(2;strexp1;strexp2;keystr1;keystr2;keystr3;ivstr;result )
keystr1, keystr2, and keystr3 are 8-byte strings used as the 64-bit DES keys. ivstr is the 8-byte initialization vector. The DES algorithm expects the input data length to be a multiple of 8 bytes. If the length of strexp1 is not a multiple of 8 bytes, the input data is padded with zero bytes. The output strexp2 is always returned as a multiple of 8 bytes. Note that ivstr is updated after the function call. Example:
define ECB_MODE = 0 define CBC_MODE = 1 define TDES_CBC_EDE_MODE = 2 %ecb_key = $07A1133E4A0B2686 %ecb_plaindata=$0248D43806F67172 %ecb_output = '' %cbc_plaindata=$37363534333231204E6F77206973207468652074696D652066 6F722000000000 %cbc_key1=$0123456789abcdef %cbc_key2=$f1e0d3c2b5a49786 %cbc_key3=$fedcba9876543210 %cbc_iv= $fedcba9876543210 %cbc_output = ''

call des_encrypt(ECB_MODE;%ecb_plaindata;%ecb_output;%ecb_key;&result)
generates ciphertext as $868ebb51cab4599a, stores it in %ecb_output, and returns &result = 1.

%iv=%cbc_iv call des_encrypt(CBC_MODE; %cbc_plaindata;%cbc_output;%cbc_key1;%iv;&result)
generates ciphertext as $ccd173ffab2039f4acd8aefddfd8a1eb468e91157888ba681d269397f7fe62 b4, stores it in %cbc_output, and returns &result = 1.

%iv=%cbc_iv call des_encrypt(TDES_CBC_EDE_MODE; %cbc_plaindata; %cbc_output;%cbc_key1;%cbc_key2;%cbc_key3;%iv;&result)
generates ciphertext as $3fe301c962ac01d02213763c1cbd4cdc799657c064ecf5d41c673812cfde96 75, stores it in %cbc_output, and returns &result = 1.
8-64
Ixia
digital_hmac The digital_hmac function, digital_hmac (algo;strexp1;strexp2; strexp3;success), generates the HMAC and stores the output in strexp3. The variable success indicates if the function was able to generate the HMAC successfully or not. It returns 1 on success, 0 otherwise. HMAC is a fixed length message digest calculated using a cryptographic hash algorithm in combination with a secret key. The variable algo identifies the cryptographic hash algorithm used in the HMAC calculation. If algo is 0, the MD2 algorithm is used. If algo is 1, the MD4 algorithm is used. If algo is 2, the MD5 algorithm is used. If algo is 3, the SHA1 algorithm is used. If algo is 4, the SHA224 algorithm is used. If algo is 5, the SHA256 algorithm is used. If algo is 6, the SHA384 algorithm is used. If algo is 7, the SHA512 algorithm is used. strexp1 is the secret key and strexp2 is the message with which HMAC is calculated. Example:
define HMAC_SHA_256 = 5 %key = $0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b %message = $4869205468657265 %output_HMAC_SHA_256 = $b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7 %output='' call digital_hmac(HMAC_SHA_256;%key; %message; %output ; &result) if (&result = 1) if (same(%output;%output_HMAC_SHA_256)) sprint 'Test: HMAC_SHA_256 is PASSED !' else sprint 'Test: HMAC_SHA_256 is FAILED !' endif else sprint 'Test: HMAC_SHA_256 is not calculated successfully!' endif
8-65
Ixia
digital_sign The digital_sign function digitally signs the message digest using the private key of the specified algorithm (RSA or DSA) and returns the signature. For RSA it expects the message digest to be the output of MD5 and SHA1. For DSA it expects the message digest to be the output of SHA1. The variable success indicates if the function was able to generate the signature successfully or not. It returns 1 on success, 0 otherwise. This function has different parameters depending on the algorithm. For RSA:
digital_sign(algo;strexp1;strexp2;strexp3;strexp4;strexp5;strexp6; strexp7;strexp8;strexp9;strexp10;sucess)
Inputs: algo = 1 (RSA). strexp1 is the message to be signed. strexp2 is the RSA public exponent e. strexp3 is the RSA private exponent d. strexp4 is the RSA modulus n. strexp5 is the prime factor p of n. strexp6 is the prime factor q of n. strexp7 is the d mod (p-1). strexp8 is the d mod (q-1). strexp9 is the Chinese Remainder Theorem coefficient q-1 mod p. Outputs: strexp10 is the generated signature. success = 1 if signature is generated successfully, 0 otherwise. For DSA:
digital_sign(algo;stringexp1;strexp2;strexp3;strexp4;strexp5;strex p6;success)
8-66
Ixia
Inputs: algo = 2 (DSA). strexp1 is the message to be signed. strexp2 is DSA p, prime modulus. strexp3 is DSA q, prime divisor. strexp4 is DSA g. strexp5 is DSA x, private key. Outputs: strexp6 is the generated signature. success = 1 if signature is generated successfully, 0 otherwise. Example:
If the above generated values of the keys are provided to the following function with %mestobesig = ''abcdefghijklmnopqrstuvwxyzabcdefghij' (36 bytes, MD5+SHA1) call digital_sign(1;%mestobesig;%rsa_pub;%rsa_priv;%rsa_mod;%prime1;%pr ime2;%exp1;%exp2;%coefficient;%sign;&result) returns RSA signature ' 8386b2ed014d463f464bb11d48c02c0f27a44dc024a37bbf002006a60a37c90db2 bac4a26a739a796d9a3a20f7a7a485d12495b3417f45b4293868957310c731' in %sign. with %mestobesig = $84983E441C3BD26EBAAE4AA1F95129E5E54670F1 (20 bytes, SHA1) call digital_sign(2;%mestobesig;%dss_p;%dss_q;%dss_g;%dss_x;%dsa_sign;& result) returns DSA signature ' '302d02142501446ec4a41f95f8e4bc0541768f1f12db4e0f021500b1eb84dcc99 0ec78b83bdfcbe6071d78cbe42f02 in %dsa_sign
digital_sign_verify The digital_sign_verify function verifies that the signature matches a given message digest using the public key of the specified cryptographic algorithm (RSA or DSA). For RSA it expects the message digest to be the output of MD5 and SHA1. For DSA it expects the message digest to be the output of SHA1. This function has different parameters depending on the algorithm.
8-67
Ixia
For RSA:
digital_sign_verify(algo;strexp1; strexp2; strexp3; strexp4; result)
strexp1 is the MD5+SHA1 message digest of the message to be verified. strexp2 is the signature. strexp3 is the RSA public exponent e. strexp4 is the RSA modulus n. result = 1 if signature verification passes, 0 otherwise. NOTE: MD5+SHA1 implies concatenation of the strings produced by MD5 and SHA1 on the given message. For DSA:
digital_sign_verify(algo;strexp1; strexp2; strexp3; strexp4; strexp5;strexp6;result)
strexp1 is the SHA1 message digest of the message to be verified. strexp2 is the signature. strexp3 is the DSA prime number p. strexp4 is the DSA prime divisor q. strexp5 is the DSA g. strexp6 is the DSA y, public key. result = 1 if signature verification passes, 0 otherwise. Example:
If the above generated values of the keys are provided to the following function with the same values of %messtobesig as assigned in digital_sign then call digital_sign_verify(1;%mestobesig;%sign;%rsa_pub;%rsa_mod;&result) will verify the RSA signature and return 1 in result if it matches the %mestobesig, 0 otherwise. call digital_sign_verify(2;%mestobesig;%dsa_sign;%dss_p;%dss_q;%dss_g;% dss_y;&result)will verify the DSA signature and return 1 or 0 in result depending if verification passes or not.
8-68
Ixia
encrypt_data The encrypt_data function, encrypt_data(algo;strexp1; strexp2; strexp3;strexp4;success), encrypts the strexp1 data using the RSA public key and stores the ciphertext in strexp2. strexp3 is the RSA public exponent e and strexp4 is the RSA modulus n. The variable success indicates if the encryption was successful or not. It returns 1 on success, 0 otherwise. algo identifies the algorithm to be used for encryption. Currently, encryption is supported only for RSA, hence the value of algo should always be 1. Example:
If the above generated values of the RSA keys are provided to the following function %mes2enc = 'abdcsdfjlsdg' call encrypt_data(1;%mes2enc;%rsa_encrypt;%rsa_pub;%rsa_mod;&result) returns '1bd3d2a53af0655d32f4888ea4ea3e1b6279c03d5433f15aab8ab27247a6cc6dc e4d9b8db1961e21b5e17b95dcf055b7bf4ff9df952b3b1dd1f1add0f3781504' in rsa_encrypt and 1 in result.
generate_keys The generate_keys function, generate_keys(algo; keylen; ...;success), generates the public and private key parameters for the specified cryptographic algorithm (RSA, DSA, or DH (Diffie-Hellman)). The inputs to this function are the algorithm value and the required length (in bits) of the key. The public and private key parameters are calculated by the function and put in the appropriate string variables. The variable success indicates if the function was able to generate the keys successfully or not. It returns 1 on success, 0 otherwise. For RSA, algo = 1 For DSA, algo = 2 For DH, algo = 3 Depending on the algorithm, this function can have the following forms. For RSA:
generate_keys(1, keylen; strexp1;strexp2;strexp3; strexp4;strexp5;strexp6; ;strexp7; strexp8; success);
strexp1 returns the RSA public exponent e. strexp2 returns the RSA private exponent d. strexp3 returns the RSA modulus n. strexp4 returns the prime factor p of n. strexp5 returns the prime factor q of n.
8-69
Ixia
strexp6 returns the d mod (p-1). strexp7 returns the d mod (q-1). strexp8 returns the Chinese Remainder Theorem coefficient q-1 mod p. For DSA:
generate_keys(2;keylen;strexp1; strexp2; strexp3; strexp4; strexp5; success)
strexp1 returns DSA p, prime modulus. strexp2 returns DSA q, prime divisor. strexp3 returns DSA g. strexp4 returns DSA y, public key. strexp5 returns DSA x, private key. For DH:
generate_keys(3;keylen;strexp1; strexp2; strexp3; strexp4;success)
strexp1 returns DH prime number. strexp2 returns DH base. strexp3 returns DH private key. strexp4 returns DH public key. Example:
call generate_keys(1;512;%rsa_pub;%rsa_priv; %rsa_mod; %prime1; %prime2; %exp1; %exp2; %coeff; &success) generates RSA private key of 512 bits. 'rsa_pub: 11' 'rsa_priv: 168207d377ba597f88985e54a40b2fe3075d50e197db5a22b8d2998a30cf3942bd b9e69ecad4e963756e1973e2594e0e5246cb21b25fbd4737f591765e576f91' 'rsa_mod: bf51428579aff8bc090f21cf725f1709be992f7d8ac87e2722fe19169ee166b908 90d42d31ac95b696b41041156671402c390df16d88c379ee1c4a5071694b97' 'prime1: eec541f31a8b10cbf96d7514f715ce09f4462adc26e3425821a62ea99cba0b2f' 'prime2: eec541f31a8b10cbf96d7514f715ce09f4462adc26e3425821a62ea99cba0b2f' 'exp1: 9a7fa324d4f09265dda12da427687642ad1e57f7dced6729f7a7c3d7292d164b' 'exp2: 486570b0989c2773b919ea689fe35e7ec290673901cfe6aebe67192311ec4081' 'coefficient: b573847d98cc089b909bdf58cda87afd5007392f093b37cd9430f3386271460b'
8-70
Ixia
call generate_keys(2;512;%dss_p; %dss_q; %dss_g; %dss_y; %dss_x; &success) generates DSA private key of 512 bits. 'dss_p: 8df2a494492276aa3d25759bb06869cbeac0d83afb8d0cf7cbb8324f0d7882e5d0 762fc5b7210eafc2e9adac32ab7aac49693dfbf83724c2ec0736ee31c80291' 'dss_q: c773218c737ec8ee993b4f2ded30f48edace915f' 'dss_g: 626d027839ea0a13413163a55b4cb500299d5522956cefcb3bff10f399ce2c2e71 cb9de5fa24babf58e5b79521925c9cc42e9f6f464b088cc572af53e6d78802' 'dss_x: 867e2f0a39a6fdef6833ea03b5f3c1424621502e' 'dss_y: 0c57854dbb15c46bd0f7b76151b3e16260a6d818f5ec8684e1e17f618bae65fec2 d467575909b8bc898d206ee55032b49d26e903c856ca295654244667e6d4bd' call generate_keys(3;64;%dh_prime;%dh_base; %dh_priv; %dh_pub;&success) generates Diffile Hellman keys of 64 bits. dh_prime : ca5dde5f9e60e247' 'dh_base : 05' 'dh_priv : 73c1bccdd959c7ec' 'dh_pub : 62d75989f552d2e2'
md5digest The md5digest function, md5digest(strexp), returns strexps 16-byte (128-bit) digital signature (digest). The digest is calculated by applying the MD5 algorithm specified in RFC1321 to strexp. The md5digest function uses the RSA Data Security, Inc. implementation of MD5 Message-Digest Algorithm. Following are examples of the md5digest function.
md5digest() returns d41d8cd98f00b204e9800998ecf8427e md5digest(message digest) returns f96b697d7cb7938d525a2f31aaf161d0 md5digest(abcdefghijklmnopqrstuvwxyz) returns c3fcd3d76192e4007dfb496cca67e13b
8-71
Ixia
milenage_3g_alg The milenage_3g_alg function, milenage_3g_alg ( wh_func; alg; strexp OP; strexp K; strexp RAND [; strexp SQN; strexp AMF ]), returns the output of one of the functions from the MILENAGE algorithm set as defined in 3GPP TS 35.206, according to wh_func: If wh_func = 0, milenage_3g_alg returns the value of the f1 function. If wh_func = 1, milenage_3g_alg returns the value of the f1* function If wh_func = 2, milenage_3g_alg returns the value of the f2 function. If wh_func = 3, milenage_3g_alg returns the value of the f3 function. If wh_func = 4, milenage_3g_alg returns the value of the f4 function. If wh_func = 5, milenage_3g_alg returns the value of the f5 function. If wh_func = 6, milenage_3g_alg returns the value of the f5* function.
The input alg is for choosing the block cipher encryption function for the MILENAGE algorithm set. Currently the only valid value for arg is 0, that is for the block cipher algorithm Rijndael. All the strexp inputs must be fixed length as in the specification: OP, K, RAND, SQN, AMF (16, 16, 16, 6, and 2 bytes, respectively). The optional inputs SQN and AMF are only needed for functions f1 and f1*. Following are examples of the milenage_3g_alg function.
%OP = $cdc202d5123e20f62b6d676ac72cb318 %K = $465b5ce8b199b49faa5f0a2ee238a6bc %rand = $23553cbe9637a89d218ae64dae47bf35 %SQN = $ff9bb4d0b607 %AMF[1]= $b9b9 %MAC = milenage_3g_alg(0,0,%OP,%K,%rand,%SQN,%AMF) returns %MAC = $4a9ffac354dfafb3 %RES = milenage_3g_alg(2,0,%OP,%K,%rand) returns %RES = $a54211d5e3ba50bf
PRF The PRF (pseudo-random function) function, PRF(strexp1; strexp2; strexp3; len; strexp4), takes as input a secret, an identifying label, and a seed and produces an output string of arbitrary length. This function is compliant to the PRF function described in RFC2246. strexp1 is the secret, strexp2 is the label, strexp3 is the seed, and len specifies the length of the output string. The generated string is returned in strexp4.
8-72 IxCatapult Software Reference Manual, Release 20.1
Ixia
Example:
%secret='abc' %seed='efg' %label='test' %prf_result='' call PRF(%secret;%label;%seed;10;%prf_result), returns 10 bytes string $81236fbdb9e6deccc0f1 in %prf_result variable.
security_3g_eea The security_3g_eea function, security_3g_eea (exp eea_alg_id; strexp key;exp count;exp bearer;exp direction;strexp data;exp length), returns a string with the cipher or plaintext resulting from processing the data string. The eea_alg_id input defines which EEA algorithm should be used. This includes support for the Null cipher [0], the SNOW 3G cipher [1], and AES-128 CTR [3]. The function and inputs are defined in 3GPP TS 33.401 and pending submissions, except for the length field. The length field should be the length of the original text in bits. Following is an example of the security_3g_eea function.
&Count = hexval('fa556b26', 8) &bearer = 3 &dir = 1 security_3g_eea(1; %key; &Count; &bearer; &dir; %orig_str; 120)
security_3g_eia The security_3g_eia function, security_3g_eia(exp eia_alg_id; strexp key;exp count;exp bearer;exp direction;strexp data;exp length), returns a string with the MAC-I checksum string from processing the data string. The eia_alg_id input defines which EEA algorithm should be used. This includes the SNOW 3G cipher [1] and AES-128 in CMAC mode [2]. Note that CMAC is implemented using open source code from the Linux WPA Supplicant project (http://w1.fi/wpa_supplicant/) via a GPLv2 license. The function and inputs are defined in 3GPP TS 33.401 and pending submissions. Following is an example of the security_3g_eia function. Note that the length field can be a subset of the actual string to reflect the fact that there is already a MAC-I checksum at the end of the message that should not re-factor into the calculation.
&Count = hexval('fa556b26', 8) &bearer = 3 &dir = 1 %mac_i_string = security_3g_eia(1; %key; &Count; &bearer; &dir; %orig_str; 120)
8-73
Ixia
security_3g_f8 The security_3g_f8 function, security_3g_f8(strexp key;exp count;exp bearer;exp direction;strexp plaintext;exp length), returns a string with the ciphertext. The f8 function is as defined in 3GPP TS 35.201. The inputs are as defined in the specification. security_3g_f9 The security_3g_f9 function, security_3g_f9(strexp key;exp count;exp fresh;exp direction;strexp message;exp length), returns a string with the output. The f9 function is as defined in 3GPP TS 35.201. The inputs are as defined in the specification. security_3g_snow The security_3g_snow function, security_3g_snow(strexp key;strexp initial_vector;strexp data;exp length), returns a string with the cipher or plaintext of the input data string. The 3G SNOW cipher is as defined in the ETSI SAGE SNOW 3G specification. The inputs are a 128-bit key, 128-bit initial vector, and a plaintext or ciphertext data string whose length is given in bits by the length parameter. Following is an example of the security_3g_snow function.
%key = $1010d8524ea5f1454c0d51205acb1d64 %iv = $1c000000fa556b261c000000fa556b26 %test_str = security_3g_snow( %key; %iv; %orig_str; 120)
sha1 The sha1 function, sha1(strexp1,strexp2), returns the strexp1 20-byte (160-bit) digital signature (digest) in strexp2. The digest is calculated by applying the SHA1 algorithm specified in the NIST FIPS PUB 180-1 to strexp1. Example:
%result = '' call sha1('abc';%result) returns a9993e364706816aba3e25717850c26c9cd0d89d in %result.
8-74
Ixia
8.6
Field Reference
Field reference is a DCPL notation that can be used on a message to access a specific field or data item. While either field reference or locate can be used to access fields in a message, field reference can be much more efficient if multiple fields are accessed in a message. However, prior to accessing a field using field reference syntax, it is recommended that you check for the existence of that field. Use the exists DCPL function (see exists on page 8-56) to test for the existence of a field in a message. If a nonexistent field is attempted to be accessed, a run-time error message is displayed. Furthermore, the returning value is an empty string for a string field and the value 0 for a numeric field. Even though field reference does not require a port to be specified (it defaults to port 1), it is port specific and a valid port must be specified for FRS to work correctly. Field reference is not supported in all protocols. It is supported only by those protocols whose manuals specifically mention it.
8.6.1
Field Reference Syntax The field reference syntax is as follows: To retrieve the contents of a string field, use: To retrieve the contents of an integer value/indicator field, use: To retrieve the contents of an integer value/indicator field on a specific port, use: To test if a certain field exists on port 1:
{1}%variable = %frame.datafield1.datafield2[&i].datafield3[2]
{1}&int_variable = %frame.datafield1.datafield2[2]
{2}&int_variable = %frame.datafield1.datafield2[2]
{1}if exists(%frame.datafield1.datafield2[3].datafield3[2]) ... endif
8-75
Ixia
To test if a certain field exists on port 2:
{2}if exists(%frame.datafield1.datafield2[3].datafield3[2]) ... endif
where: %frame is the string variable that contains the incoming message. .datafield is the protocol-specific field name. [] contains the appearance count of the preceding field. It can be either a constant or a numeric variable. The default is 1. {} is the port number for a specific port. If omitted, it defaults to 1.
Please note that some protocols include fields whose types are not known at compile time. Their types are determined at run time by the value of a previous field in the message. FRS treats such fields as strings, even if at run time they are resolved to integers. 8.6.2 Field Reference Modes Field reference has two modes: a full decompose mode and a single lookup mode. 8.6.2.1 Decompose Mode
The decompose mode uses the decompose command (see decompose on page 8-56) and completely decodes a message frame in a DCPL string variable into an internal decompose cache. The decompose cache is associated with the DCPL string variable and used to extract multiple fields quickly. Decompose mode is the default mode for PER protocols and is assumed even if the decompose command is omitted. Decompose mode is the default mode for all protocols in release 4.3 and prior releases. The following is an example of a decompose:
wait %frame decompose %frame %field1 = %frame.datafield1.datafield2 %field4 = %frame.datafield1.datafield3.datafield4 %field5 = %frame.datafield1.datafield3.datafield5
8-76
Ixia
The decompose cache for each message is maintained for as long as the DCPL string variable contains the original message. Assignment and concatenation will flush the decompose cache. Copying a previously decomposed DCPL string variable to another DCPL string variable will not transfer the decompose cache; a decompose command on the assigned DCPL string variable is required. 8.6.2.2 Single Lookup Mode
The single lookup mode uses the field reference syntax to look up an IE without internal decomposition and is the default mode. If the decompose command is omitted, each IE lookup starts from the beginning, with no cached information about the frame. This method is useful for looking up very few IEs or IEs near the beginning of a message, especially where the rest of the message will require no further processing. The following is an example of a standard field reference lookup:
wait %frame %field1 = %frame.datafield1.datafield2 %field4 = %frame.datafield1.datafield3.datafield4 %field5 = %frame.datafield1.datafield3.datafield5
NOTE: Single lookup mode is the default field reference mode for all non-PER protocols in release 4.4 and later. At this time no protocols based on PER (packed encoding rules) support the single lookup mode. Decompose mode is assumed even if the decompose command is omitted. 8.6.3 Field Reference Forms There are two basic forms of field reference. 8.6.3.1 Fully Qualified Field Reference
The field reference syntax %frame.datafield1.datafield2[3].datafield3[2] is an example of fully qualified field reference. It means: look for the second data field that is contained in the third datafield2, which in turn is contained in the first datafield1 in the message in %frame. By using a fully qualified path, it requires that datafield3 is directly contained in datafield2, datafield2 is directly contained in datafield1, and datafield1 is a top-level field in message %frame.
8-77
Ixia
8.6.3.2
Wildcard Field Reference
The following is an example using wildcards:

{1}%variable = %frame.datafield1..datafield2..datafield3
where: .. is a wildcard search that can cross one or more levels of the protocol definition tree. The above DCPL syntax gets the contents of datafield3, which is contained (not necessarily directly) in datafield2, and datafield2 must be contained (not necessarily directly) in datafield1, and datafield1 is the first level field of message %frame. Following is another example of wildcard field reference. It gets the data of the data_target field that is contained in %frame. The appearance count can also be used with wildcard field reference.
{1}%variable = %frame..data_target
8.6.4
Sample Script Following is a sample DCPL script of the BICC protocol that shows field reference in use.
/* send transfer_req message */ {1} transfer_req sequence_control=123 user_data=[acm cic=2000 bci=[chrg=2 cdsind=1 cdcind=2 etoe=1 sccpmeth=2]] /* wait for a response */ wait %frame for 100 /* print received message */ sprint hexstring(%frame) /* check if field transfer_req exists within received message */ {1}if exists (%frame.transfer_req) /* it does exist; the above check is similar to "case type transfer_req" */ sprint this is a transfer_req type message endif {1}if exists (%frame.transfer_req.user_data.acm.bci.sccpmeth) /* extract and assign contents of a numeric field */ {1}&abc = %frame.transfer_req.user_data.acm.bci.sccpmeth sprint sccpmeth = , string(&abc) endif {1}if exists (%frame.transfer_req.user_data.acm.bci) /* print contents of a string field. */ {1}sprint bci=, %frame.transfer_req.user_data.acm.bci endif /* example using wild cards */ {1}if exists (%frame..cdsind)
8-78
Ixia
/* finds cdsind in any message */ {1}sprint cdsind = ,string(%frame..cdsind) /* finds cdsnind anywhere in acm message only */ {1}sprint cdsind = ,string(%frame..acm..cdsind) endif
Following is a DCPL sample script of the RANAP protocol where RANAP is the second port in a multi-port application.
&state = 0 &mycid = 2 define INITIAL_MESSAGE = {ncrq cid=&mycid rcs=0 eds=0cda=$43000007 cga=$43010006data=[initialUE_MessageprotocolIEs= [cN_DomainIndicator=ps_domain lAI=[pLMNidentity=111 lAC=11] sAI=[pLMNidentity=123 lAC=12 sAC=12] nAS_PDU=Lets set up a call global RNC_ID=[pLMNidentity=456 rNC_ID=1] iuSigConId=bits(24;$112233)]] qsp=1} while (1) wait %frame for 100 switch %frame /* Process SCCP nsid on port 2 */ {2}case type nsid: /* Finds IE us anywhere in nsid message using port /* 2 protocol and variant. */ {2}&result = %frame..us if &result = 1 sprint SCCP LINK IS UP! endif if &state = 0 pause Press Return to Setup Signalling/RAB /* Send a response on port 2 */ {2} INITIAL_MESSAGE &state=1 endif endcase {1} case type acm: /* Process ISUP ACM on port 1 */ ... endcase ... endswitch endwhile
8.6.5
Using Negative Integers with FRS DCPL integer variables contain 32-bit unsigned values. When using FRS to extract a negative number and assign it to an integer variable, the number will not be signed:
{1}&frs_value = %frame..maximumDL_power
Where &frs_value = -350:

print &frs_value
will print:
value of &frs_value is 4294966946 (#fffffea2)
Another example:
IxCatapult Software Reference Manual, Release 20.1 8-79
Ixia
{1}&frs_value = %frame..initialDL_Power
Where &frs_value = -1:

print &frs_value
will print:
value of &frs_test is 4294967295 (#ffffffff)
8.6.6
Information Element Fields that Have the Same Label Some of the different information elements in a protocol have the same label. This situation creates ambiguity when wildcard FRS is applied to it. When you do wildcard FRS on fields with such a label, the first field encountered in the protocol syntax tree is referenced. In such a case, to remove the ambiguity, further qualification should be used. For example, In RRC3.5.0, the AccessServiceClass field is both a sequence field and a numeric field when it appears in the <ASC> field. To access the sequence AccessServiceClass field, because it appears earlier in the syntax tree than the numeric field, the following wildcard FRS can be used.
{1}%AccessServiceClass_string = %frame..AccessServiceClass
Or fully qualified FRS can be used as well. To access the numeric AccessServiceClass field, use the following partially qualified FRS:
{1}&AccessServiceClass_int = %frame..ASC.AccessServiceClass
8.6.7
Difference Between FRS and locate As mentioned in locate on page 8-9, the locate statement can be used to extract the encoded value of a field, which may not correspond to the fields actual value. In protocols encoded with ASN.1 Packed Encoding Rules (PER), this is often the case with integer fields, but this difference can also occur outside of PER protocols. Examples include fields that do not occupy an entire octet and require bitwise masking/shifting and phone-number fields (such as IMSI) that are encoded in BCD format. FRS differs from locate in that the field is decoded before the value is returned, so the value returned matches the value originally entered. Consider the rb_identity field in the following RRC R6 message as an example:
rlc_am_data_req_rbs UE_Id=1 Logical_channel_type=DCH1 MUI=1 CNF=No DiscardReq=No Data=[activeSetUpdate_r3= [activeSetUpdate_r3=[rrc_TransactionIdentifier=3
8-80
Ixia
dummy3=[rB_WithPDCP_InfoList=[RB_WithPDCP_Info= [rb_Identity=1 pdcp_SN_Info=3]]]]]]
RRC R6 is a PER protocol. Because rb_Identity is a constrained integer with a range of 1-32, PER minimizes bits by encoding the value as the offset from the minimum. Hence, for an rb_Identity value of 1 the encoded offset is 0. Locating rb_Identity will return a value of 0 (to be exact, $00 with a bit offset of 3 and a bit length of 5) for this message. In contrast, a field reference will return the fields actual value of 1. 8.6.8 Exceptions Field reference is not allowed in certain constructs of DCPL syntax and should not be used in the following areas: When encoding a message. Field reference syntax should not be used as a variable expression in a DCPL protocol message. This includes a protocol-specific DCPL message in a compiled script, and when using the DCPL encode command in a script or interactively. Multiple field reference commands cannot be evaluated on one script line. Nesting of field reference commands is not supported. In case type expressions. case type is a case in a switch statement that allows quick detection of a message type without the use of locate or field reference. In locate expressions. Field reference is similar in function to locate, and cannot be mixed.
8-81
Ixia
8.7
Macros
A macro is a user-defined textual substitution: each occurrence of a macros name in DCPL code is replaced by the macros body. A macro can have parameters, which are used during the substitution. During a ddriver session (that is, not during compilation of a script) the macro substitution can be turned off and on with the preprocess statement (see preprocess on page 8-23). A macro cannot redefine a DCPL keyword. Macros defined during a ddriver session are context specific. DCPL has the following macro statements. define The define statement is used to define a macro. It has the following syntax: define name [(@param, ... )] = line_of_text or for long macros define name [(@param, ... )] = { line_of_text ... } Each line_of_text can be broken across lines by using a backslash. For example:
define N_PORTS = 10 define end_of_test = { sprint Test complete write stop exit } define x_sum = &x1 + &x2 + &x3 + &x4 + \ &x5 + &x6 define warn(@reason) = sprint Warning:, @reason define compare(@p1,@p2) = same(@p1;@p2)
Each parameter name begins with an @. If a parameter appears in the macro body as shown in the examples above, it is replaced by its value during macro expansion. However, if a parameter appears preceded by a #, it is replaced by its value inside quotes. For example, given the macro definition:
define show_hex(@str) = \ sprint Value of ,#@str, is $,hexstring(@str)
The macro call

show_hex(%fred)
produces
sprint Value of ,%fred, is $,hexstring(%fred)
If %fred contains the value $1234, this sprint will output:

Value of %fred is $1234
8-82
Ixia
undef The undef statement is used to undefine a macro. It has the following syntax:
undef name
ifdef / ifndef The ifdef and ifndef statements are used to conditionally exclude or include a section of code. For the ifdef statement, if a macro by the name given is defined then all the code before the next endifdef statement is compiled. Likewise for the ifndef statement, if a macro by the name is not defined then all the code before the next endifdef statement is compiled. Optionally, an elseifdef statement can be included between the ifdef/ifndef and endifdef statements, to compile one of two pieces of code dependent upon a macro being defined. Macros can be defined on the command line of ddc. The ifdef / ifndef statements have the following syntax.
ifdef name .... [ elseifdef .... ] endifdef ifndef name .... [ elseifdef .... ] endifdef
NOTE: Note that the C equivalents for these statements, #ifdef/#ifndef, #else, and #endif, can also be used as described in Section 9.4.3, Constants, on page 9-5. 8.7.1 Predefined Macros __LINE__ is set to line number in the DCPL script on which the macro was used. If used in a multi-line macro the __LINE__ macro expands to the line on which the macro was invoked. __FILE__ is set to the current file being processed when the macro is expanded. To use this macro, ddc "-Xhash" option is necessary and the script image should be like below.
define PRINTFNAME(@p1) = sprint #@p1 PRINTFNAME(__FILE__)
8-83
Ixia
8.7.2
Limitations If your macro text starts with {, you must put {} around the entire macro. For example: When a script is used interactively, context data in a macro is ignored. In the following example the explicit declaration of {contextB} in the macro is overridden by invoking the macro in contextA.
define run_foo(@A) = { {@A} free i = %frame{} }
{contextA} define foo = { {contextB} sprint hello } {contextA} foo
8.8
Special and Predefined Variables

DCPL has the following special and predefined variables.
8.8.1
Generic Special Variables &abortct received. The number of times the abort sequence has been
&available_memory &badfcs
Read percentage available memory.
The number of frames received with bad FCSes. Revision number of baseboard
&baseboard_revision{port} associated with a given port.
%context_name Name of the context in which the current DCPL script is running. It is a read-only variable. &cpu_idle Read CPU idle percentage (Coprocessor only).
&dcpl_errno Error code for prior DCPL variable assignments/accesses. The possible values can be found in dcpl_errno.dh. &itimer_tag{port} &itimer_index{port} Default itimer tag. Default itimer index. Default itimer duration.
&itimer_duration{port}
8-84
Ixia
&itimer_remaining{port} expiration. &itimeout_index{port} &itimeout_tag{port} &loc_index &loc_length
The time remaining until itimer
The index of the last expired itimer. The tag of the last expired itimer.
The index of the last protocol-specific field located. The length of the last protocol-specific field located.
&mezzanine_revision{port} The revision number of mezzanine board associated with a given port. &numports The number of ports in this script.
&physint{port} The type of physical interface connected to port. The values are described in $DCT2000PATH/physint.dh. &portin The port on which the last frame was received Note, for cases where a wait statement is triggered for reasons other than a frame being received, &portin is set to a special port number to signify that event.
wait %frame for 100 switch %frame case TIMEOUT: /* &portin will be = 65531 (0xFFFD) */ endcase case KEYBOARD: /* &portin will be = 65534 (0xFFFE) */ endcase case ITIMEOUT: /* &portin will be port that was specified by {<port>}start_itimer.... and %frame will be empty. */ endcase other: /* &portin = port on which last frame was received and %frame will contain the frame received. */ endswitch
&protocol{port}
The protocol in use on port.
8-85
Ixia
&receive_queue_length{port} The number of pending received frames on a port. This can be used to determine whether a connected context or device under test is sending more frames than the context can process given the current program load. If this value is increasing over time, it is a good indication that the current context is too heavily loaded. NOTE: If port represents a port connection from a board context to a workstation context this will always have a zero value. &random A random number if read, a seed for the random number generator if written. &send_queue_length{port} The number of outstanding transmitted frames on a port. This can be used to determine whether a connected context or device under test is unable to process the transmitted frames the current context is sending fast enough. If this value is increasing over time, it is a good indication that the connected context, device under test, or physical line is too heavily loaded. Also, if the test is running on an mCI board and it is configured in multiple VPI/VCI mode, there is a sending queue per channel. So the value returned is based on the queue associated with the most recent %sendcellheader{port}. If %sendcellheader{port} is null or a null string, the sum of the queues of all channels for the given port is returned. NOTE 1: If port represents a port connection from a workstation context to a board context this will always have a zero value. NOTE 2: For mCU mesh communications the &send_queue_length value presents a full size of kernel tranmission queue to the mPI or to another mCU/mCI board. &time Centisecond counter; can be written.
&time_us_high and &time_us_low Time since the start of test in microsecond units, &time_us_low is the least significant 32 bits of the time and &time_us_high is the most significant 32 bits of the time. To correctly read the time, &time_us_low must be read first followed by &time_us_high. Note that in the current release the time only has 100 microsecond resolution, so the two least significant decimal digits of &time_us_low will always be zero.
/* Read the current time, &time_us_low must be read first. */ &abs_time_lo = &time_us_low &abs_time_hi = &time_us_high
8-86
Ixia
&timein Timestamp of last frame received, in microsecond units. &timein is the least significant 32 bits of the frame timestamp. Note that in the current release, frame timestamps have 100 microsecond resolution, so the two least significant decimal digits of &timein is zero. &timeout Default timeout for wait statements, in centiseconds; initial value 0. &variant{port} The variant defined for port.
&wait_queue_length The number of pending events that will trigger a wait statement. In the workstation environment (not Coprocessor), this value can be used to determine whether too many frames are being received from all connected contexts after they have been dequeued from each ports receive queue and placed on the internal wait queue (see &receive_queue_length{port}). If this value is increasing over time, it is a good indication that the connected contexts or devices under test are transmitting too many frames given the current workstation CPU load. Note that if this variable is read in a Coprocessor context, it has a zero value. 8.8.2 Protocol-Specific Special Variables 8.8.2.1 ATM Special Variables Cellheader initialized in multiple VPI/VCI mode. Cellheader to release in multiple VPI/VCI mode. Current number of active
%initcell{port}
%invalidcell{port}
&mvpivcinumberchannels{port} channels in multiple VPI/VCI mode. &mvpivcireleasetimer{port} multiple VPI/VCI mode.
Release cellheader timer used in
%receivecellheader{port} Cellheader of the last frame to trigger the wait statement in multiple VPI/VCI mode. %sendcellheader{port} Cellheader to use when sending subsequent frames in multiple VPI/VCI mode.
8-87
Ixia
8.8.2.2
BCHAN Special Variables
NOTE: These variables apply only to BCHAN. See the BCHAN Protocol Manual [14] for details. &patterno{port} The pattern number of the pre-defined pattern to send on the channel. &pattern_input_length{port} The length of BCHAN input frames. This value should be a multiple of 4 on the E1/T1 boards and a multiple of 8 on the J1/E1/T1 (JET) boards. 8.8.2.3 GTP Special Variables
&num_tidmnc_digits{port} Number of BCD digits for MNC parameter for GTP V8 protocol, the default value is 2 BCD digits. 8.8.2.4 PDCP Special Variables
&pdcp_no_header_pdu{port} Indicator that tells when PDCP has a header or not. A 1 value means no header present. 0 means a PDCP header is present. %receive_ueid_lcid{port} User Entity ID and Logical Channel ID of the last frame to trigger the wait statement, if applicable. %send_ueid_lcid{port} User Entity ID and Logical Channel ID to use when sending subsequent frames.
8-88
Ixia
8.8.3
E1/T1 Special Variables The following special variables are used with the E1/T1 mezzanine board. These variables allow scripts to detect and, in some cases, modify the state of the E1/T1 links. The alarm and signaling variables refer to the link to which the corresponding data port is connected. 8.8.3.1 Link Alarm Status Variables
The E1 and T1 alarm variables are read-only integer values, with value 1 if the alarm condition is present, 0 otherwise. It is an error to refer to E1 variables with reference to a T1 link, and vice versa. &e1_frame_alarm{port}, &e1_rua1{port}, and &e1_rra{port} are special read-only variables applicable to E1 boards. When an E1 mezzanine board receives frame alarm, unframed all ones, or remote alarm, &e1_frame_alarm{port}, &e1_rua1{port}, or &e1_rra{port} is set to 1 correspondingly. &t1_red{port}, &t1_ryel{port}, and &t1_rbl{port} are special read-only variables applicable to T1 boards. When a T1 mezzanine board receives red alarm, yellow alarm, or blue alarm, &t1_red{port}, &t1_ryel{port}, or &t1_rbl{port} is set to 1 correspondingly. &pri_signaling[]{port} is a read/write numeric array, which allows you to do robbed-bit-signaling in T1 and CAS in E1. &pri_signaling[]{port} is indexed by timeslot and bits A to D are represented in bits 3 to 0 respectively. For example, &pri_signaling[3]{port} = #a sets bit A and C in timeslot 3 to 1. In the case of T1 with D4 framing, the C and D bit positions are unused and should be set to zero.
bit: D4(T1) ESF(T1) or CAS(E1) 15 0 0 ... 0 0 3 A A 2 B B 1 0 C 0 0 D
&pri_reg[]{port} is a read/write, port-specific numeric array of size 144 for E1 configured mezzanine boards and size 176 for T1 configured mezzanine boards. It permits reading from and/or writing to all registers in both Dallas transceivers on a mezzanine board. &pri_reg[]{port} is indexed by the registers address on the transceiver. For example, reading &pri_reg[#20]{port} is reading status register 1 on the T1 transceiver. Refer to Dallas DS2152 (T1) and DS2154 (E1) for the addresses of registers.
8-89
Ixia
NOTE: Reading and writing to non-existent addresses may cause undesired results. 8.8.3.2 E1 Spare Bits
&e1_sa{port} is a read/write, port-specific variable that allows the user to set and read the value of the spare bits in TS0 of an E1. The spare bits, named SA4-SA8, are located in TS0 of nonalignment E1 frames. The following table shows how the spare bits correspond to bit locations in the &e1_sa variable.
bit: D4(T1) 0 15 0 ... 4 SA4 3 SA5 2 SA6 1 SA7 0 SA8
8.8.4
BRI S/T Special Variables Several special reserved variables allow scripts to determine operational status of the BRI S/T mezzanine board. &bri_st_state{port} This variable is a read-only variable that reports the alignment and activation of the BRI S/T link corresponding to the port. The bits of the variable are defined as follows.
bit: 15 0 ... 0 3 ACT 2 Error 1 0 0 Frame Sync
&bri_st_state
ACT - Activation State (1-Fully Activated, 0-Not activated) Error - Error in activation state machine (1-Error 0-No error or recovery) Frame Sync - 1-Frame Sync achieved, 0-Frame Sync Lost
&bri_st_rxinfo{port} This variable is a read-only variable that indicates the RX Info state of the link. The possible values of this variable are as follows: 0 - Receiving Info 0 1 - Receiving Info Low 2 - Receiving Info High 3 - Receiving Info X
8-90
Ixia
&bri_st_txinfo{port} This variable is a read-only variable that indicates the TX Info state of the link. The possible values of this variable are as follows: 0 - Transmitting Info 0 1 - Transmitting Info Low 2 - Transmitting Info High 3 - Transmitting Info X &bri_st_reg[]{port} This variable is a read/write numeric array of size 34. It permits reading from and/or writing to the registers of the both Motorola ISDN S/T Transceivers on the BRI S/T mezzanine board. The Motorola MC145574 ISDN S/T Transceiver has 7 nibble registers, 16 byte registers, and 11 overlay registers. The following list shows the mapping of these registers to the indices of &bri_st_reg[]{port}: &bri_st_reg[0]-&bri_st_reg[6] &bri_st_reg[7]-&bri_st_reg[22] &bri_st_reg[23]-&bri_st_reg[32] &bri_st_reg[33] Nibble Register 0-6 Byte Register 0-15 Overlay Register 0-9 Overlay Register 15
NOTE: Writing incorrect values to the registers may cause undesirable results. Consult the Motorola MC145574 manual for more details about the contents of each register. 8.8.5 CII Special Variables The three port-specific special variables supported for the CII interface are as follows. &cii_stx_var{port} This variable is a read/write variable that reads or writes the current S transmit bit signal value on a port. &cii_srx_var{port} This variable is a read-only variable that reads the current S receive bit on a port. &cii_rate_var{port} the port data rate. This variable is a read-only variable that reads
8-91
Ixia
8.8.6
Serial Special Variables The following special variables are used with the Serial mezzanine board. 8.8.6.1 Control Lead Special Variables
The control lead special variables, &ctrl_cts{port}, &ctrl_dcd{port}, &ctrl_dsr{port}, &ctrl_rts{port}, and &ctrl_dtr{port} are available for serial mezzanine boards. These variables can be read anytime. &ctrl_cts{port}, &ctrl_dcd{port}, and &ctrl_dsr{port} can be written in DCE mode while &ctrl_rts{port} and &ctrl_dtr{port} can be written in DTE mode. Writing a one to any of these variables sets the corresponding signal active while writing a zero sets the corresponding signal inactive.
Variable Name &ctrl_cts &ctrl_dcd &ctrl_dsr &ctrl_dtr &ctrl_rts Function Read and write when port is configured as DCE; otherwise, read only. Read and write when port is configured as DCE; otherwise, read only. Read and write when port is configured as DCE; otherwise, read only Read and write when port is configured as DTE; otherwise, read only Read and write when port is configured as DTE; otherwise, read only.
NOTE: In DTE and DCE monitor mode &ctrl_dtr and &ctrl_dce correspond to DTR transmit and DTR receive. 8.8.6.2 Serial Clock Measurement Special Variables
The serial clock measurement variables, &serclk_r{port} and &serclk_t{port}, are used to access the receive and transmit clock rates, respectively, on the serial interface. Both variables are read only. When in normal clocking mode and the port is configured as a DTE, the serial clock rate is measured on the board.
8-92
Ixia
For a DCE, the reported clock rate is from the system configuration file. In terminal timing mode, the generated clock is reported from the configuration file and the received clock is measured on the board. In monitor mode, the transmit and receive clocks are measured on the MONITOR_DTE port. When clock rates on the MONITOR_DCE port are accessed, the reported clock rates are those measured on the MONITOR_DTE port. 8.8.7 Dynamic TDM Special Variables for J1/E1/T1 &receivechannelnum{port} The channel identifier of the channel for the last frame to trigger the wait statement in dynamic TDM mode. &sendchannelnum{port} The channel identifier of the channel to use when sending subsequent frames in dynamic TDM mode. 8.8.8 OC-3 and OC-3E Special Variables The following special variables are used with the OC-3/OC-1 mezzanine board. &_phy0_rx_framer{port} phy 0. &_phy0_tx_framer{port} phy 0. &_phy1_rx_framer{port} phy 1. &_phy1_tx_framer{port} phy 1. Read the number of received cells on
Read the number of transmitted cells on
Read the number of received cells on
Read the number of transmitted cells on
NOTE: The variables read, transmit, and receive 19-bit saturating framer counters for ATM cells. &oc3_frame_reg[]{port} This port-specific, numeric array variable of size 256 reads or writes to the framer registers of the OC3E board. It is indexed by register number as defined in the PMC-Sierra PM5350 S/UNI-155-ULTRA manual available at http://www.pmcsierra.com/. For example, print &oc3_frame_reg[86]{1} prints the LSB of the RACP receive cell counter for the link associated with port {1}.
8-93
Ixia
If the board is configured in multiple VPI/VCI mode, the link used is that associated with the last %sendcellheader{port} on that port. 8.8.9 mCI(ATM) Special Variables The special variables listed in this section provide low level access to mCI(ATM) hardware registers. These are used for hardware debugging. Writing to certain registers can cause adverse affects on the hardware. &_phy0_fpga_reg[reg]{port} Reads and writes to the FPGA control register. Some FPGA registers are read only. [reg] is the offset to the FPGA register accessed. For example:
This example shows how to reset all cell counters. {test}&_phy0_fpga_reg[36]{1} = &_phy0_fpga_reg[36]{1} bitor 61440 {test}&_phy0_fpga_reg[36]{1} = &_phy0_fpga_reg[36]{1} bitand 4095
&_phy0_serdes_reg{port} Reads and writes specifically to the FPGA Serdes (oc3/oc12 transceiver with clock recovery) control register. &_codec_reg{port} codec control register. Reads and writes specifically to the FPGA
&_phy0_cells_discarded_routing{port} Reads the FPGA register of the counter of the total number of cells discarded from the CAM due to mismatched routing directions. &_phy0_cells_discarded_passthru{port} Reads the FPGA counter of the number of cells discarded due to Pass Through FIFO Full. &_phy0_a_discarded_ingress_high{port} Reads the FPGA register of the number of cells discarded because the FPGA A side ingress high priority FIFO was full. &_phy0_b_discarded_ingress_high{port} Reads the FPGA register of the number of cells discarded because the FPGA B side ingress high priority FIFO was full. &_phy0_a_discarded_ingress_low{port} Reads the FPGA register of the number of cells discarded because the FPGA A low priority ingress FIFO was full.
8-94
Ixia
&_phy0_b_discarded_ingress_low{port} Reads the FPGA register of the number of cells discarded because the FPGA B low priority ingress FIFO was full. &_phy0_cam_matches{port} Reads the counter of the number of CAM matches for both A and B sides. &_phy0_cam_matches_a{port} matches for just the A side. &_phy0_cam_matches_b{port} matches for just the B side. Reads the number of CAM
Reads the number of CAM
&_phy0_cam_vpc_matches{port} Reads the counter of the CAM Virtual Path Circuits matches for both A and B sides. The counters can be reset by the Traffic ATM Cells Counters Reset bit of the ATM Control Register. &_phy0_cam_vpc_matches_a{port} Reads the counter of the CAM Virtual Path Circuits matches for the A side only. The counters can be reset by the Traffic ATM Cells Counters Reset bit of the ATM Control Register. &_phy0_cam_vpc_matches_b{port} Reads the counter of the CAM Virtual Path Circuits matches for the B side only. The counters can be reset by the Traffic ATM Cells Counters Reset bit of the ATM Control Register. &_phy0_a_ingress_high_fifo{port} Read to get the number of Cells to the 8260A from the High Priority FIFO. &_phy0_b_ingress_high_fifo{port} Read to get the number of Cells to the 8260B from the High Priority FIFO. &_phy0_a_ingress_low_fifo{port} Read to get the number of Cells to the 8260A from the Low Priority FIFO. &_phy0_b_ingress_low_fifo{port} Read to get the number of Cells to the 8260B from the Low Priority FIFO. &_phy0_a_egress_high_fifo{port} Read to get the number of Cells from the 8260A to the Low Priority FIFO.
8-95
Ixia
&_phy0_b_egress_high_fifo{port} Read to get the number of Cells from the 8260B to the Low Priority FIFO. &_phy0_a_egress_low_fifo{port} Read to get the number of Cells from the 8260A to the Low Priority FIFO. &_phy0_b_egress_low_fifo{port} Read to get the number of Cells from the 8260B to the Low Priority FIFO. &_phy0_cells_from_framer{port} Reads the total number of cells from the framer (limited to 65532). &_phy0_cells_passed_through{port} Reads the total number of Pass Through cells sent back to the framer. &_phy0_cells_to_framer{port} Reads the total number of cells sent to the framer (limited to 65532). &_phy0_framer_loopback_egress{port} Reads the framer loopback control registers. Write 1 to cause the framer to connect the transmitter to receiver (equipment loopback). Write 0 to unset loopback mode. Messages are sent from the 8260 to the FPGA to the framer and back to the FPGA and then to the 8260. Example:
&_phy0_framer_loopback_egress{2}=1
where 2 is the port number and 1 is the value cause the framer to go into loopback mode. The framers TX and RX FIFOs buffer 4 frames unless set to do otherwise. &_phy0_framer_loopback_ingress{port} Reads the loopback control register. Write 1 to cause the framer to connect the transmiter to receiver (facility loopback). Write 0 to unset. Messages will then be received from the fibre to the switch to the Serdes to the framer and back to the serdes to the switch to the fibre. &_phy0_framer_side_egress{port} Reads the FPGA loopback control registers. Write 1 to cause the fgpa to connect the transmiter to receiver. Write 0 to unset loopback mode. Messages will be sent from the 8260 to the FPGA and back the 8260.
8-96
Ixia
&_phy0_framer_side_ingress{port} Reads the loopback control register. Write 1 to cause the fgpa to connect the transmiter to receiver. Write 0 to unset. Messages are sent in from the fibre to the switch to the Serdes to the framer to the FPGA back to the Serdes and to back out to the fibre. &_phy0_serdes_loopback_egress{port} Reads the serdes loopback control register. Write 1 to cause the Serdes to connect the transmiter to receiver. Write 0 to unset. Messages are sent from the 8260 to the FPGA to the framer to the serdes back to the framer to the FPGA to the 8260. &_phy0_serdes_loopback_ingress{port} Reads the loopback control register. Write 1 to cause the Serdes to connect the transmiter to receiver. Write 0 to unset. Messages are received from the fiber to the switch to the serdes back to the switch to the fiber. &_phy0_serdes_reg{port} Reads the status of the Serdes register. Write allow manual configuration of the Serdes. &_phy0_framer_reg[register]{port} Reads writes the AMCC (Applied Micro Circuits Corporatoin) S1201 (doc rev 3.3) framer registers. Example:
print &_phy0_framer_reg[192]{1} &_phy0_framer_reg[192]{1} = 4
where 192(0xC0) is the register in the AMCC S1201 framer for Transmit Side Register Address Map for POS Provisioning. 4 is the bit mask for TX_POS_PMAX_ERR_SECE_MASK. &_switch_ingress_loop{port} This write-only variable connects the Serdes transmit and receive at the switch. Any write to this variable sets the loopback. &_switch_slot_connection{port} This write-only variable connects the Serdes transmit and receive to the specified slot over the backplane mesh. Example: The following connects the board associated with port 1 to the board in slot 4.
&_switch_slot_connection{1} = 4
8-97
Ixia
8.8.10
Ethernet Special Variables Ethernet special variables are read and write variables that accept only integer values. Minimal error checking is done in inputs. Use them at your own risk. The following Ethernet special variables are used with the PowerPCI Ethernet Interface mezzanine board. &eth_spd_det This variable is a port specific, status variable that displays 1 if the link is in 100 B-Tx mode or 0 if in 10B-t mode. If you write to this special variable, you may experience undesired results as this does a reset of the control register. &eth_lnk_det This variable is a port specific read only variable that displays 1 if a link was detected or 0 if not. If you would like to force the value, use the &eth_mi_reg[]. &eth_mi_reg[] This variable is a port specific, read and write array of registers 0 to 20 on the 80223 chip. No error checking is done on which register you write to or what you write to those registers. Improper procedures for setting certain functions may result in abnormal behavior followed by undesirable consequences.
8-98
Ixia
8.8.11
mPI(STM) Special Variables %stm_create_channel{port} %stm_remove_channels{port} channels. 8.8.11.1 Macros The macros described in this section are available in stm.dh. The macros use the following parameters: channel_num: 1-8064. This parameter is used with the HDLC channel macros. It is one of the HDLC channel numbers defined in the port options section of the IxCatapult system configuration file. timeslot: 0-8063 (for SSTM1, link 0 uses timeslots 0-2015, link 1 uses timeslots 2016-4031, link 2 uses timeslots 4032-6047, and link 3 uses timeslots 6048-8063). This parameter is used with the PCM and TFO channel macros. It is the timeslot that the channel occupies. channel_rate: 64k=$ff, 56k=$fe, 32k=$f0, 16k=$c0, 8k=$80. payload_type: 0=command, 1=data, 2=TFO PCM, 3=TFO Message, 4=TFO Frame. Adds an STM channel. Removes one or more STM
Adding an STM Connection To add an STM connection (HDLC, PCM or TFO-PCM), use the following macros.
%stm_create_channel{logical_port} = MAKE_STM_ADD_HDLC_CHANNEL(channel_num) %stm_create_channel{logical_port} = MAKE_STM_ADD_PCM_CHANNEL(timeslot, channel_rate) %stm_create_channel{logical_port} = MAKE_STM_ADD_TFO_PCM_CHANNEL(timeslot)
Removing STM Connections To remove STM connections (HDLC, PCM or TFO-PCM), use the following macros.
%stm_remove_channels{logical_port} = MAKE_STM_REMOVE_HDLC_CHANNEL(channel_num) %stm_remove_channels{logical_port} = MAKE_STM_REMOVE_PCM_CHANNEL(timeslot) %stm_remove_channels{logical_port} = MAKE_STM_REMOVE_TFO_PCM_CHANNEL(timeslot)
8-99
Ixia
Sending an STM Frame To send an STM frame (HDLC, PCM or TFO-PCM), use the following macros before sending a group of messages through the one channel number.
%sendcellheader{logical_port} = MAKE_STM_HDLC_CELL_HEADER(channel_num, payload_type) %sendcellheader{logical_port} = MAKE_STM_PCM_CELL_HEADER(timeslot) %sendcellheader{logical_port} = MAKE_STM_TFO_PCM_CELL_HEADER(timeslot, payload_type)
Receiving an STM Frame When receiving an STM frame, use the following macros to get the various details of the received frame.
&channelnum = RECEIVED_CELLHEADER_STM_CHANNELNUM(port) &channeltype = RECEIVED_CELLHEADER_STM_CHANNELTYPE(port) &payloadtype = RECEIVED_CELLHEADER_STM_PAYLOADTYPE(port)
Enabling Data Forwarding from STM mPI The following DCPL macro interface sends a request to the STM mPI to enable data forwarding (send-back) from the STM mPI. By default, such data forwarding is disabled for PCM channels.
%stm_config_channels{logical_port} = MAKE_STM_CHANNEL_PCM_FORWARDING(timeslot, channel_type, state)
where: channel_type is the channel type (0 = PCM, 2 = TFO). 1 is MTP2 and is not used in this DCPL macro. state enables or disables data forwarding (0 = disable data forwarding, 1 = enable data forwarding). NOTE 1: This macro should be used only after a PCM or TFO channel is established. Use of this macro is needed for an established PCM channel, but is not necessary for an established TFO channel. NOTE 2: For an established PCM channel, channel_type 0 (PCM) should be used.
8-100
Ixia
8.8.11.2 Limitations Since bearer is a streaming application, it requires special real time attention as well as correct shelf clock settings. In the m500 structured STM (SSTM) application, bearer (PCM) samples are generated from the mCIs and are transmitted to the network through the SSTM RTM. If an mCI sends data faster than the required 64kbps rate, the SSTM RTM will overflow and will discard data. If an mCI sends data slower than the required 64kpbs rate, the SSTM RTM will underflow and will insert idle patterns in the middle of the PCM speech, causing corruption in the data stream. Both these cases should be avoided. The suggested way of avoiding these overflow/underflow issues is to use an mCI context (tfo_sm.ppci) which has been built with very good real time handling. This context sends down data every 40ms for each channel and has an optimized real time scheduler to distribute the channels in time to minimize burst/processor usage spikes and generate a deterministic, steady stream. Although it is not necessary to use this context, it is highly recommended to do so. For functional test cases, the DCPL interface would work well if the real time scheduling is performed by the user context. For load testing, the user context may not be able to schedule a high number of channels as well as time distribution of these channels and would overflow/underflow the SSTM RTM. Therefore, it is recommend to use the tfo_sm context for all bearer load applications on the SSTM RTM. Another important area is clocking. If the mCI and SSTM RTM clocks are not synchronized, there will eventually be an overflow/underflow situation. See Chapter 12, Intermodule Timing for more information (particularly on the use of the .clockspec file). Similarly, the SSTM RTM and the user equipment must be synchronized. See Section 2.18, mPI(STM) Configuration Window, on page 2-51 for more information on link clock settings.
8-101
Ixia
8.8.12
VLAN Special Variables The following VLAN special variables are available for use with UDP applications running on the m500 Ethernet platform and on PPCI GigE boards. &vlan_tag_egress{port} Use the &vlan_tag_egress write-only variable to specify a VLAN ID and user priority to be used on every frame sent on the specified port from the time the variable is set. This supersedes the automatic tagging specified in sysconfig (see Section 2.16.1, VLAN Configuration, on page 2-45). It is used in conjunction with the macro MAKE_VLAN_TAG, which is defined in eth.dh:
&vlan_tag_egress{&PORT_NUM} = MAKE_VLAN_TAG(&MY_VID, &MY_PRIORITY)
where: &MY_VID specifies the desired VLAN ID. The valid range for the mPI board is 0-4094. The GigE board has a valid range of 1-4094, and the value 255 is reserved in addition. &MY_PRIORITY is the associated priority, in the range 0-7.
An alternative is to specify the VLAN tag directly:

&vlan_tag_egress{&PORT_NUM} = &MY_VLAN_TAG
The egress VLAN tag can be changed as often as desired. It can also be turned off to revert back to tagging based on sysconfig information. This is accomplished by using the macro NO_VLAN_TAG, also defined in eth.dh:
&vlan_tag_egress{&PORT_NUM} = NO_VLAN_TAG
%vlan_tag_ingress{port} Use the %vlan_tag_ingress read-only variable to query the VLAN ID and priority of the last frame received. A typical use of this variable is to display the VLAN information of the incoming frame:
wait %frame for 0 sprint %vlan_tag_ingress{&PORT_NUM}
If the frame did not have a VLAN tag, the variable shows No VLAN Tag. If a VLAN tag was present, the VLAN ID and priority are displayed, for example, VLAN: VID=60, Priority=2.
8-102
Ixia
8.8.13
mPI(GigE) Special Variables for IP Port Forwarding %IP_port_forward The IP port forwarding feature can be used on the m500 mPI(GigE) board to share a single IP address across multiple CPUs, to facilitate traffic testing. The mPI(GigE) board has the ability to (optionally) route UDP/TCP/SCTP packets to multiple destination mCU boards (CPUs) based on both IP address and destination protocol port number. IP port forwarding is enabled in a DCPL script by setting the %IP_port_forward write-only variable. IP port forwarding is supported only on the m500 mPI(GigE) board. The %IP_port_forward variable contains information for a specific IP address and a range of desired IP protocol ports. Setting this variable in a DCPL script indicates an IP address and range of ports to register for the current context. MAKE_IP_PORT_FORWARD Macro Because setting the %IP_port_forward variable requires three parameters, the MAKE_IP_PORT_FORWARD macro is supplied to simplify the syntax. The macro accepts the following parameters: IP-Address (text string), StartPort, and EndPort. Usage is as follows:
%IP_port_forward{<port>} = MAKE_IP_PORT_FORWARD(<IP-Address>, <StartPort>, <EndPort>)
The IP-Address parameter is either an IPv4 or IPv6 address. The port numbers (StartPort and EndPort) must be between 0 and 65535. Note that zero is a special case (see the following Default Port Forwarding section). The MAKE_IP_PORT_FORWARD macro is available in file eth.dh, located in the $DCT2000PATH directory. The %IP_port_forward variable is a port-specific variable. It will have a unique value for each context port used in the DCPL script. Note that the context port must be associated with a physical board port. The higher-layer context must associate this port with the lower-layer board port, so the internal port forwarding is set up correctly. As an alternative to using the %IP_port_forward variable, the tcp_udp_register_ports ipprim primitive or RegisterPortsReq sctpprim primitive can be used. For more information on these primitives, see the UDP State Machine Manual [11], TCP/UDP State Machine Manual [10], or SCTP State Machine Manual [9].
8-103
Ixia
Default Port Forwarding IP protocol port 0 is a reserved value and normally cannot be registered through a write to the %IP_port_forward variable. For a range of IP ports (where more than one IP port is specified), the port range must start with a value greater than or equal to 1. However, the concept of a default route is supported, which means forward all IP packets to this context that have an IP protocol port not registered by any other context. In a given test scenario (ddriver session), only one context is allowed to set the %IP_port_forward variable with a valid IP-Address, and a range of 0..0. This special range (0..0) indicates the default route. Other contexts would normally register one or more ranges for the same IP address, for example, 500..500, or 20..100. The default route of the range 0..0 means that packets that arrive, for example, on ports 230, or 300 (which are not registered in any other context), will be delivered to the default context. 8.8.13.1 Example The following example assumes that the test scenario sets up three contexts on three separate CPUs (or mCUs): Cntxt-A, Cntxt-B, and Cntxt-C. The scenario is to share IP address 192.168.2.10 across all three contexts, handling TCP port 500 in Cntxt-B, UDP ports 20 through 40 in Cntxt-C, and all other ports in Cntxt-A. The DCPL additions to share this IP address might look as follows: Cntxt-A: %IP_port_forward{2} = MAKE_IP_PORT_FORWARD( 192.168.2.10, 0, 0) Cntxt-B: %IP_port_forward{2} = MAKE_IP_PORT_FORWARD( 192.168.2.10, 500, 500) Cntxt-C: %IP_port_forward{2} = MAKE_IP_PORT_FORWARD( 192.168.2.10, 20, 40)
8-104
Ixia
8.8.13.2 Notes IP port forwarding is considered optional and defaults to off until any context in a test session sets the %IP_port_forward variable. Once the variable has been set, IP port forwarding is now considered on for that port, for the remaining duration of the test session. Physically, this means that the IP protocol port will not be used by the mPI in routing decisions while IP port forwarding is off. Once IP port forwarding is turned on for a specific port (by any context), the mPI will then use the received IP protocol port when attempting to route the packet to the destination CPU. A single IP address cannot be shared across multiple CPUs unless IP port forwarding is turned on. It is recommended to use an explicit range for IP protocol ports, rather than relying on the default route, if possible. There will be a small performance penalty for packets routed to the default route. When an IP packet is received for which there is not an explicit port range specified, there are two possible behaviors, assuming IP port forwarding is on: 1. If a default route (range 0..0) has not been specified, the packet is dropped in the mPI. 2. If a default route (range 0..0) was specified, the packet is forwarded to that route. 8.8.13.3 IP Port Forwarding Restrictions and Limitations MTU Fragmentation The Maximum Transmission Unit (MTU) size of the network determines the largest packet that can be transmitted or received by the system in a single fragment. The IxCatapult implementation of IP port forwarding may not work correctly for fragmented packets (packets that are larger than the configured MTU size). Fragmented packets have the protocol port specified only in the first fragment. Subsequent fragments do not contain port information. This applies to both IPv4 and IPv6. The mPI(GigE) handles each fragment of a packet individually. It routes each packet in the order in which it arrives, at line-rate. The mPI(GigE) does not store fragments or reassemble fragmented packets. This means that fragmented packets must arrive in order (with the first fragment arriving at the mPI first) in order for the mPI to be able to correctly forward the entire packet. The mPI correctly detects the first fragment of a packet and retains the routing information so that subsequent fragments can be routed to the same destination.
8-105
Ixia
Some packet fragmentation schemes, however, may send the packets out of order. Some systems may send the packets in reverse order (the last fragment arrives first and the first packet arrives last). The mPI cannot route the initial packets, since they do not contain the IP port destination information. This will result in part of the packet being misrouted or dropped by the mPI, causing the entire packet to be dropped by the receiving endpoint. For applications that require both IP port forwarding and large packets, which may be fragmented, the recommendation is to increase the configured MTU size so the packets are not fragmented. This will eliminate any possible misrouting based on the fragment order. Connecting the mPI(GigE) directly to the DUT is also recommended. This creates a point-to-point connection (without intervening routers), which should allow greater flexibility in setting the MTU size and may also eliminate any ordering issues even if the packets must be fragmented due to limits of the maximum MTU size. IPv6 Extension Headers To locate the protocol port information in a packet, the mPI(GigE) must parse the packet much deeper into the header than would normally be required for routing. Both IPv4 and IPv6 support optional information in the IP header. IPv4 does this through the Options field, which is a variable-length field containing zero or more options. The IP port forwarding feature correctly parses and forwards IPv4 packets with optional headers. IPv6 supports optional information using extension headers. The IP port forwarding feature supports the following IPv6 extension headers: Hop-by-Hop Options Destination Options Routing Fragment
The IP port forwarding feature does not support the following IPv6 extension headers: ESP, or Encapsulating Security Payload AH, or Authorization Header
8-106
Ixia
8.9
DCPL Keywords
Following is a list of the DCPL keywords.
add add_stat_row adjust_itimer all and appearance append array bitand bitnot bitor bitxor break call case clear comment context continue data default delete_stat_row display div duration else encode endcase endfor endif endswitch endwhile exit exp flush for forward free gwrite i if in include index itimeout keyboard left load locate log mod noglobals none not nullif nullthen off on or other parse pause pattern preprocess print prompt protocol read_itimer received remove return right screen send sprint start_itimer stat_field stat_group stats stop stop_itimer store switch sysmon tag timeout to type units unload update_stat_field update_stat_row variant variable view wait while write wsprint
8-107
Ixia
8.10
Differences in DCPL Between IxCatapult and DCT-S

All Scripts are Multi-Ported In the IxCatapult system, all scripts are multi-ported; whereas in the DCT-S, uploads and downloads are single-ported.
8.10.1
8.10.2
Size of Integer Variables In the IxCatapult system, all integer variables are 32 bits; whereas in the DCT-S, some are 16 bits and some are 32 bits. In the IxCatapult system, all integer variable names begin with &; whereas in the DCT-S, 32-bit variable names begin with &&.
8.10.3
Non-Port-Specific Variables In the IxCatapult system, variables with no port number are not associated with any port; whereas in the DCT-S, such variables are assumed to be associated with port 1.
8.10.4
Unsupported DCPL Statements These DCT-S DCPL statements are not supported in the IxCatapult system: dct8500cmd, flush, passup, passback, default layer, default varport, layer, raw, require. Also, &ms_timer is no longer supported.
8.10.5
Renamed DCPL Statements These DCT-S DCPL statements are renamed in the IxCatapult system: download to load; upload to load; read to load; read log to preprocess on followed by load; sendup to keyboard; read to call.
8.10.6
Port Numbers on Statements In the IxCatapult system, a port number at the beginning of a statement applies only to the statement itself, not to the variables used in it; whereas in the DCT-S, it applies to the variables as well. In the IxCatapult system, an empty port expression {} on a variable means that the variables port is the same as the statements.
8.10.7
Macro Parameters In the IxCatapult system, macro parameters begin with the @ character, whereas in the DCT-S they begin with the & character.
8-108
Ixia
8.10.8
Multi-Line Macros In the IxCatapult system, multi-line macro definitions are defined by surrounding the lines with { } characters; whereas in the DCT-S, the lines of the definition are separated by &cr.
8.10.9
Renamed DCPL Special Variables These DCT-S DCPL special variables were renamed in the IxCatapult system.
DCT-S &mpi_t1_red &mpi_t1_ryel &mpi_t1_rbl &mpi_pri_signalling &mpi_pri_reg &mpi_e1_rua1 &mpi_e1_rra &mpi_e1_sa &mpi_e1_frame_alarm &mpi_serclk_r &mpi_serclk_t &mpi_bri_st_reg &mpi_bri_st_state &mpi_bri_st_rxinfo &mpi_bri_st_txinfo &mpi_cii_stx_var &mpi_cii_srx_var &mpi_cii_rate_var IxCatapult &t1_red &t1_ryel &t1_rbl &pri_signalling &pri_reg &e1_rua1 &e1_rra &e1_sa &e1_frame_alarm &serclk_r &serclk_t &bri_st_reg &bri_st_state &bri_st_rxinfo &bri_st_txinfo &cii_stx_var &cii_srx_var &cii_rate_var
8.10.10 Unsupported DCPL Special Variables The following DCT-S DCPL special variables are not supported in the IxCatapult system: timeinls, timeinms, dctlevel, and __reqqqdata. 8.10.11 Case Keyboard In the DCT-S, the case up: statement was used to check for input from the user; the IxCatapult system uses the case keyboard: statement.
8-109
Ixia
8.10.12 Default &timeout Value is 0 In the IxCatapult system, the default value of &timeout is 0, whereas in the DCT-S it is 2000.
8.11
Design Considerations
Extensive use of display, logging to disk, file I/O, print, and sprint, has an effect on the overall performance of the system. Therefore, when developing scripts to be used in load applications, keep the use of these to a minimum. Note that doing any of the aforementioned activity on a context running on the workstation can affect the performance of contexts running on the PPCI boards, and vice versa.
8.12
Limitations
The minimum size of a string variable is 0 bytes. The maximum size of a string variable is 16 MB (16777216 bytes). The minimum value of an integer variable is 0. The maximum value of an integer variable is 232 - 1.
8-110
9
C Interface
Contents 9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 9.2 Calling C Procedures from DCPL. . . . . . . . . . . . . . . . . . . . . . 92 9.3 Calling DCPL Procedures from C. . . . . . . . . . . . . . . . . . . . . . 93 9.4 Sharing Data Between DCPL and C . . . . . . . . . . . . . . . . . . . 93 9.5 Avoiding Naming Conflicts with the Library . . . . . . . . . . . . . . 95 9.6 C-Callable Functions Library . . . . . . . . . . . . . . . . . . . . . . . . 96
C Interface
Ixia
9.1
Introduction
The IxCatapult software provides interfaces for calling C functions from DCPL, executing DCPL scripts from C functions, and sharing relevant data between those functions. This allows for maximum flexibility in the types of applications that can run on the IxCatapult system. Any C files making references to DCPL variables or C library functions must include the file, libC.h, delivered with the IxCatapult software. Include libC.h in your C files and compile them with ddc. See Chapter 5, Compiling DCPL Scripts, for details.
#include <libC.h>
The following restrictions apply when using the C Interface: You must not invoke any UNIX system calls that cause the current process to suspend, for example: select, sleep, wait, and so forth. Control should be returned for background processing only by using the DCPL wait command or the equivalent Dwait() C interface function. UNIX signals are used extensively within the IxCatapult system and are therefore not available to the script developer.
9.2
Calling C Procedures from DCPL

To be callable from DCPL, a C functions name must begin with an underscore. The function is called using the DCPL call statement (see call on page 8-11). The capitalization of the function name in DCPL and C must match. For example: DCPL:
call MyFunc
C:
void _MyFunc() { ... }
Parameters can be passed to the function but no value returned. All C functions should be defined as void functions. If parameters are passed to the C function, the function name is modified to reflect the types of the parameters. For instance, if the function MyFunc is called with a string and two integer parameters, the actual C function called would be _MyFunc_sii(), where s corresponds to a string, and i corresponds to an integer.
9-2
Ixia
C Interface
Note that all parameters are passed to the C function by reference. So it is possible to return information by using a DCPL string or integer variable as a parameter to the C function. However constants and expressions are passed by value, so the actual values of them have the same values before and after the function call. Following are examples. DCPL:
call f1(123; 3; %op{2},a; %result; &pass)
C:
void _f1_sissi(DSTR *x, DINT *y, DSTR *z, DSTR *t, DINT *k) { ...}
DCPL:
call f2(substr(%op{2};1;2); hexval(%k); &pass)
C:
void _f2_sii(DSTR *x, DINT *y, DINT *z) { ...}
9.3
Calling DCPL Procedures from C

The main program of each executable script must be DCPL, even if it is only a single call statement (see call on page 8-11) into C code. The code in each DCPL file is visible from C as a function whose name is the name of the DCPL file with a leading underscore, for example: DCPL file: sm.d C call: _sm();
9.4
Sharing Data Between DCPL and C

Data can be shared between DCPL and C through the use of global DCPL variables. A number of macros (described below) are provided in libC.h for referring to these variables.
#include <libC.h>
The C name of a DCPL variable is the same as the DCPL name, with the first character upper-case and the rest lower-case.
9-3
C Interface
Ixia
A macro is provided for accessing port-specific variables: DPORT(port). This macro generates a C array index for port. Another macro required for accessing port-specific variables, DPORTS, is the number of ports in the script. DPORTS must be #defined in your C files for accesses to port-specific variables to work. For example, in a script with 4 ports you would include this line:
#define DPORTS 4
In order for C code to declare and access a DCPL variable, the variable must be referred to at least once from DCPL code within the same script. If no such DCPL reference exists, variables can be accessed by way of a symbol table search, using Dfetchspecial and Dsfetchspecial (see Section 9.6, C-Callable Functions Library, on page 9-6), though this is slower than direct references. 9.4.1 Integer Variables All integer variables are declared using the Dint() macro. For example:
Dint(Xyz);
The variable Xyz above is a scalar non-port-specific variable with type DINT. It is referenced as follows:
Xyz = 55;
Port-specific scalar variables are declared using the Dportint() macro and are indexed using the DPORT() macro. They are treated as arrays of DINT indexed by port-1:
Dportint(Cic); addr = Cic[DPORT(2)];
Non-port-specific array variables are declared using the Dintarray() macro and indexed as a straightforward DINT array. For example:
Dintarray(Array_var); Array_var[77] = 55;
Port-specific array variables are declared using the Dportintarray() macro and are indexed as if it was a two dimensional array [size][port-1]:
Dportintarray(Array_per_port); Array_per_port[77][DPORT(2)] = 55;
9-4
Ixia
C Interface
9.4.2
String Variables All string variables are declared using the Dstr() macro. For example:
Dstr(Mystr); Dstrcpy(Mystr, "hello world");
The variable Mystr above is a variable length, non-port-specific string variable. All string variable declarations require that that particular variable (for example, %mystr) be referenced in at least one other DCPL file to be linked in with this C function. Port-specific string variables are declared using the Dportstr() macro and are indexed using the DPORT() macro:
Dportstr(Address); Dstrcpy(Address[DPORT(2)], "hello world");
Non-port-specific array variables are declared using the Dstrarray() macro and indexed as a straightforward DSTR *array. For example:
Dstrarray(Foo_Array_str); Dstrcpy(Foo_Array_str[77], "hello world");
Port-specific array variables are declared using the Dportstrarray() macro:

Dportstrarray(Array_per_port); Dstrcpy(Array_per_port[77][DPORT(2)], "hello world");
All operations on string variables, including retrieving their contents, must be done using the interface functions described in Section 9.6, C-Callable Functions Library, on page 9-6. 9.4.3 Constants The DCPL preprocessor is able to parse simple C style header files to allow sharing of constant definitions between C files and DCPL files. The allowable syntax is limited to macro definitions (#define) with no parameters and the preprocessor directives #include, #ifdef, #ifndef, #else, #endif, and #undef. Hexadecimal constants will be converted (regardless of the -Xhex flag option, which is now ignored).
9.5
Avoiding Naming Conflicts with the Library

All user-created functions and global data should begin with an uppercase letter other than D, to avoid conflicts with internal functions in the IxCatapult library.
9-5
C Interface
Ixia
9.6
C-Callable Functions Library

The majority of C-callable functions are defined in the file libC.h, delivered as part of the IxCatapult software. Include libC.h in your C files and compile them with ddc. See Chapter 5, Compiling DCPL Scripts, for details.
#include <libC.h>
There are also a number of functions modeled after standard UNIX library functions available for the Coprocessor environment. Following are the descriptions of these functions. 9.6.1 DINT Declaration Macros These macros are used at the beginning of a C function or file to provide access to a DCPL integer variable (DINT) defined in a DCPL file to be linked in. In all cases presented in the following topics, var_name is the C name of a variable. The C name is the same as the DCPL name, with the first character uppercase and the rest lowercase. NOTE: Do not use direct extern declarations in your application (for forward compatibility reasons). Dint The macro, Dint(var_name), makes a DCPL integer variable extern reference to the variable named var_name. Dintarray The macro, Dintarray(var_name), makes a DCPL integer array variable extern reference to the variable named var_name. Dportint The macro, Dportint(var_name), makes a DCPL port-specific integer variable extern reference to the variable named var_name. Dportintarray The macro, Dportintarray(var_name), makes a DCPL port-specific integer array variable extern reference to the variable named var_name. 9.6.2 String Manipulation Macros These macros are used at the beginning of a C function or file to provide access to a DCPL string variable (DSTR *) defined in a DCPL file to be linked in. In all cases following, var_name is the C name of a variable. The C name is the same as the DCPL name, with the first character uppercase and the rest lowercase.
9-6
Ixia
C Interface
NOTE: Do not use direct extern declarations in your application (for forward compatibility reasons). Dstr The macro, Dstr(var_name), makes a DCPL string variable extern reference to the variable named var_name. Dstrarray The macro, Dstrarray(var_name), makes a DCPL string array variable extern reference to the variable named var_name. Dportstr The macro, Dportstr(var_name), makes a port-specific DCPL string variable extern reference to the variable named var_name. Dportstrarray The macro, Dportstrarray(var_name), makes a port-specific DCPL string array variable extern reference to the variable named var_name. 9.6.3 String Manipulation Functions These functions are used to access and manipulate DCPL string variables. Dscopy The function, int Dscopy(DSTR *deststr, DSTR *srcstr), copies DCPL string variable, srcstr, into the DCPL string variable, deststr, overwriting anything that may already be in deststr. It returns OK if successful, FAIL otherwise. Dstrcpy The function, int Dstrcpy(DSTR *deststr, char *srcstr), copies character string, srcstr, into the DCPL string variable, deststr, overwriting anything that may already be in deststr. It returns OK if successful, FAIL otherwise. Dstrncpy The function, int Dstrncpy(DSTR *deststr, char *srcstr, DINT length), copies length bytes of the character string srcstr into the DCPL string variable deststr, overwriting anything that may already be in deststr. The length of deststr is set to length. NOTE: This function copies past NULL characters in srcstr, unlike the standard C librarys function, strncpy. It returns OK if successful, FAIL otherwise (that is, when deststr is NULL). Dstrcat The function, int Dstrcat(DSTR *deststr, char *srcstr), concatenates the character string srcstr into the DCPL string variable deststr. It returns OK if successful, FAIL otherwise.
9-7
C Interface
Ixia
Dstrncat The function, int Dstrncat(DSTR *deststr, char *srcstr DINT length), concatenates length bytes of the character string srcstr into the DCPL string variable deststr. It returns OK if successful, FAIL otherwise. Dsget The function, int Dsget(char *deststr, DSTR *srcstr), copies the string from the DCPL string variable srcstr into the user provided buffer deststr. It returns OK if successful, FAIL otherwise. Dset The function, int Dset(DSTR *srcstr, DINT byte_num, char value), sets the byte specified by byte_num in the DCPL string variable srcstr to value. If byte_num is an invalid reference into srcstr, FAIL is returned and srcstr remains unchanged. Otherwise, OK is returned. byte_num starts at 0 for the first character of the string. Dget The function, int Dget(DSTR *srcstr, DINT byte_num, unsigned char *value_ptr), copies the byte specified by byte_num in the DCPL string variable srcstr into the location pointed to by value_ptr. If byte_num is an invalid reference into srcstr, FAIL is returned and value_ptr remains unchanged. Otherwise, OK is returned. byte_num starts at 0 for the first character of the string. Dbcopy The function, int Dbcopy(DSTR *deststr, char *srcstr, DINT byte_num, DINT length), does a binary copy of length bytes of srcstr into the DCPL string variable deststr starting at destination offset byte_num. It returns OK if successful, FAIL otherwise. Dhexstring The function, int Dhexstring(char *deststr, DSTR *srcstr), copies the string from the DCPL string variable srcstr as an ASCII hexstring into the user-provided buffer pointed to by deststr. Each character in srcstr is converted to its two-character hex representation. For example, if srcstr contained the character string 12345, the character string copied into deststr would be 3132333435. It returns OK if successful, FAIL otherwise. Dlength The function, DINT Dlength(DSTR *srcstr), returns the length of srcstr. If srcstr is NULL it will return 0.
9-8
Ixia
C Interface
9.6.4
Interprocess Functions These functions are used to pass frames between contexts and to do basic context processing. Dwait The function, int Dwait(DSTR *frame, int duration, int units), waits until the next frame arrives in a context or a timeout occurs. When a frame arrives the number of port that frame arrives on is stored in the DCPL variable &portin. The units field may take on the values SECONDS or CSECONDS (1/100th of a second). It returns OK if successful, FAIL otherwise. Dsend The function, int Dsend(DSTR *frame, DINT portnum), sends frame out the port specified by portnum. A portnum of zero (0) has no meaning. It returns OK if successful, FAIL otherwise. Dsend_badfcs The function, int Dsend_badfcs(DSTR *frame, DINT portnum), sends frame out the port specified by portnum with a bad FCS encoding (as applicable by protocol). A portnum of zero (0) has no meaning. It returns OK if successful, FAIL otherwise. Dkeyboard The function, int Dkeyboard(char *srcstr), sends the text line in srcstr to be processed exactly as if it had been typed in at the keyboard. It returns OK if successful, FAIL otherwise. Dparse The function, int Dparse(char *message), sends the message to the DCPL parse function. It returns OK if successful, FAIL otherwise. Dload The function, int Dload(char *filename), loads the script named in filename in the current context and begins execution once the load is complete. To load over a different context, use the Dkeyboard() function. This function returns OK as long as filename is not NULL, in which case it returns FAIL. Dload_noglobals The function, int Dload_noglobals(char *filename), loads the script named in filename in the current context and begins execution once the load is complete, but does not preserve DCPL variables across the load. To load over a different context, use the Dkeyboard function. This function returns OK as long as filename is not NULL, in which case it returns FAIL. Dunload The function, void Dunload(), unloads the current script and returns to the default script behavior.
9-9
C Interface
Ixia
Dunload_noglobals The function, void Dunload_noglobals(), unloads the current script and returns to the default script behavior, without preserving DCPL variables. Dpause The function, void Dpause(), pauses the current context until input is entered at the keyboard. The input entered is discarded. Note that while a script is paused it discards all incoming frames; that is, they are not buffered to trigger an eventual wait statement after the pause is completed. 9.6.5 File System Functions These functions are used to access IxCatapult capabilities that access the filesystem. Several UNIX filesystem functions also are available in the Coprocessor environment as described in Section 9.6.10, Coprocessor UNIX Library Functions, on page 9-16. Workstation environment programs can make UNIX filesystem calls as usual. Dopen The function, int Dopen(char *filename, int append), begins an output trace to the file filename.out. If append is TRUE, the file is opened for appending; otherwise, the file is created. It returns OK if successful, FAIL otherwise. Dclose 9.6.6 The function, void Dclose(), stops any output trace.
Display Functions These functions are used for interacting with the display process. Ddisplay The function, int Ddisplay(char *message), sends a message to the display. The message should be terminated by NULL (\0). It returns OK if successful, FAIL if given a NULL message. Ddecode_msg The function, int Ddecode_msg(DINT portnum, DSTR *frame, DINT variant, DINT enumerated), sends a DCPL string variable, frame, to the display process to be decoded and returned on port DECODE_PORT. Portnum is used to determine with what protocol and variant frame is to be decoded. If variant is nonzero, variant is used instead of the variant value included on the ddriver command line (that is, -Vn). A portnum of zero (0) has no meaning. If enumerated is zero (0) then plain integer and string values are used. If set to one (1) then enumerated labels (if any) are used. For example: if field Found can be TRUE (1) or FALSE (0), then if enumerated is set to 1 then Found=FALSE is displayed rather than Found=0 during the decoding process. It returns OK if successful, FAIL otherwise.
9-10
Ixia
C Interface
9.6.7
Interval Timer Functions These functions are used to start, stop, and read interval timers (itimers). See Section 8.4.5, Interval Timer Statements, on page 8-28 for a detailed discussion of interval timers. Dstart_itimer The function, int Dstart_itimer(DINT portnum, DLONG tag, DLONG index, DLONG duration, int units), starts a single-shot interval timer using the identifying parameters tag and index. A portnum of zero (0) has no meaning. The timeout interval lasts for the time specified by duration and units, where units may take on any of the following values: SECONDS, CSECONDS (1/100th of a second), MSECONDS (1/1000th of a second), or USECONDS (1/1000000th of a second). It returns OK if successful, FAIL otherwise. If the timer expires, terminating a wait statement (see wait on page 8-15), the variables &portin, &itimeout_tag{&portin}, and &itimeout_index{&portin} are set: &portin is the portnum parameter of the Dstart_itimer call, &itimeout_tag is the tag parameter, and &itimeout_index is the index parameter. Dstart_periodic_itimer The function, int Dstart_periodic_itimer (DINT portnum, DLONG tag, DLONG index, DLONG duration, int units), starts a periodic interval timer using the identifying parameters tag and index. The portnum must be a valid port number within the script. The timeout interval lasts for the time specified by duration and units, where units may take on any of the following values: SECONDS, CSECONDS (1/100th of a second), MSECONDS (1/1000th of a second), or USECONDS (1/1000000th of a second). It returns OK if successful, FAIL otherwise. If the timer expires, terminating a wait statement (see wait on page 8-15), the variables &portin, &itimeout_tag{&portin}, and &itimeout_index{&portin} are set: &portin is the portnum parameter of the Dstart_itimer call, &itimeout_tag is the tag parameter, and &itimeout_index is the index parameter. Unlike single-shot itimers, a periodic itimer continually retriggers itself, terminating a wait statement each time, until it is stopped using Dstop_itimer(). This produces better timing accuracy than simply re-calling Dstart_itimer() each time. Dstop_itimer The function, int Dstop_itimer(DINT portnum, DLONG tag, DLONG index), cancels the interval timer matching the identifying parameters tag and index. A portnum of zero (0) has no meaning. It returns OK if successful, FAIL otherwise.
9-11
C Interface
Ixia
Dread_itimer The function, DLONG Dread_itimer(DINT portnum, DLONG tag, DLONG index, int units), returns the duration in units of the time remaining until the timer expires. A zero (0) return value indicates that the timer doesnt exist or has expired already. The portnum must be a valid port number within the script. It returns OK if successful, FAIL otherwise. Dadjust_itimer The function, int Dadjust_itimer(DINT portnum, DLONG tag, DLONG index, int phase, int units), adjusts the expiry time of the specified interval timer. The adjustment is defined by the signed value of phase and is specified in units using the same format as for Dstart_itimer(). It returns OK if successful, FAIL otherwise. 9.6.8 Special Variable Access Functions These functions are used to access special DCPL variables. Special variables are variables that are referenced normally in DCPL, but actually access system functions. A good example is the system variable, &time, which accesses the system time when it is read and is read-only. The actual implementation of &time is not just a DINT, so a Dint(Time) reference would result in a link error. See Section 8.8, Special and Predefined Variables, on page 8-84 for a listing of special variables. In each Special Variable Access function in the following topics, the portnum parameter specifies the port on which to access the port-specific variable. A NOTMULTIPORTED portnum value refers to a non-port-specific variable. The var_name parameter specifies the name of the DCPL special variable to be accessed. The first letter of var_name is always capitalized, while the remaining letters are lowercase (for example, Time). Finally, the subscript parameter is used to indicate the array subscript of the DCPL special variable being accessed. Use a subscript value of NOT_ARRAY if it is not an array variable. Note that these functions also work for accessing regular (not special) DCPL variables. However, these access functions are notably slower than the Section 9.6.1, DINT Declaration Macros, on page 9-6 and Section 9.6.2, String Manipulation Macros, on page 9-6.
9-12
Ixia
C Interface
Dassignspecial The function, int Dassignspecial(DINT portnum, char *var_name, DINT value, int subscript), sets the integer DCPL special variable specified by var_name to value. The following table lists possible return values and their meaning.
Return Value OK WRONGPORTSIZE BADPORT BADINDEX WRONGTYPE WRONGSIZE OTHERERROR Success Port is out of range Port is invalid Subscript out of range Attempt to assign to a STRING variable Attempt to subscript a non-array variable All other error cases Meaning
Dfetchspecial The function, int Dfetchspecial(DINT portnum, char *var_name, DINT *value_ptr, int subscript), copies the integer value from the special variable var_name to the location pointed to by value_ptr. The following table lists possible return values and their meaning.
Return Value OK UNINITIALIZED WRONGPORTSIZE BADPORT BADINDEX WRONGTYPE WRONGSIZE OTHERERROR Success Variable is uninitialized Port is out of range Port is invalid Subscript out of range Attempt to retrieve a STRING variable Attempt to subscript a non-array variable All other error cases Meaning
Following is a simple example that accesses the DCPL special variable &time:
DINT mytime; int retval; retval = Dfetchspecial(NOTMULTIPORTED, "Time", &mytime, NOT_ARRAY);
9-13
C Interface
Ixia
Dsassignspecial The function, int Dsassignspecial(DINT portnum, char *var_name, DSTR *str_value, int subscript), sets the string special variable specified by var_name to the string DSTR pointed to by str_value. The following table lists possible return values and their meaning.
Return Value OK WRONGPORTSIZE BADPORT BADINDEX WRONGTYPE WRONGSIZE OTHERERROR Success Port is out of range Port is invalid Subscript out of range Attempt to assign to a DINT variable Attempt to subscript a non-array variable All other error cases Meaning
Dsfetchspecial The function, int Dsfetchspecial(DINT portnum, char *var_name, DSTR **str_value_ptr, int subscript), copies the DCPL string from the special string variable var_name to the location pointed to by str_value_ptr. The following table lists possible return values and their meaning.
Return Value OK UNINITIALIZED WRONGPORTSIZE BADPORT BADINDEX WRONGTYPE WRONGSIZE OTHERERROR Success Variable is uninitialized Port is out of range Port is invalid Subscript out of range Attempt to retrieve a DINT variable Attempt to subscript a non-array variable All other error cases Meaning
Following is an example that accesses the DCPL special variable %route:

Dstr(Temp_string); int retval; retval = Dsfetchspecial(1, "Route", &Temp_string, NOT_ARRAY);
9.6.9
Miscellaneous Functions These functions are miscellaneous IxCatapult functions.
9-14
Ixia
C Interface
Dcodec_off The function, int Dcodec_off(DINT portnum), turns off the codec on the port specified by portnum. The port specified must be tied to a physical board either directly or indirectly to turn off the codec. A portnum of zero (0) has no meaning. It returns OK if successful, FAIL if attempted on an invalid port. Dcodec_on The function, int Dcodec_on(DINT portnum, DINT timeslot, DINT link), turns on the codec on the port specified by portnum and connects it to the specified link at the given timeslot. A portnum of zero (0) has no meaning. It returns OK if successful, FAIL if attempted on an invalid port. Dfwd The function, int Dfwd(DINT port1, DINT port2), starts a unidirectional dataswitch from port1 to port2. port1 is the incoming port and port2 is the outgoing port to which port1 is connected. It returns OK if successful, FAIL if attempted on an invalid port. Dexit The function, int Dexit(int exit_value), exits ddriver with the specified exit_value. DprocessedPort The function, DINT DprocessedPort(), returns the value of &portin variable then called by the main DCPL script or C-subroutine and the port value related with processed message then it is called by an asynchronous exit function like outheader function (see DsetOutheaderFunc on page 9-16). Dsecurity3geea The function, int Dsecurity3geea(FRAME *deststr, FRAME *key, DINT eea_version, DINT count, DINT bearer, DINT dir, FRAME *data, DINT length), applies the EEA algorithm identified by the algorithm_identifier as defined in 3GPP TS 35.401 and returns a string with the cipher or plaintext (since the operation is orthogonal). The EEA function is as defined in TS 35.401 Appendix B. The inputs are as defined in the specification, except for the length field. The length field should be the length of the orginal text in bits. Currently, only EEA0 and EEA1 are supported. Dsecurity3geia The function, int Dsecurity3geia(FRAME *deststr, FRAME *key, DINT eia_version, DINT count, DINT bearer, DINT dir, FRAME *data, DINT length), applies the EIA algorithm identified by the algorithm_identifier as defined in 3GPP TS 35.401 and returns a string with the cipher or plaintext (since the operation is orthogonal). The EIA function is as defined in TS 35.401 Appendix B. The inputs are as defined in the specification, except for the length field. The length field should be the length of the orginal text in bits. Currently, only EIA1 is supported.
IxCatapult Software Reference Manual, Release 20.1 9-15
C Interface
Ixia
Dsecurity3gf8 The function, int Dsecurity3gf8(DSTR *deststr,DSTR *key, DINT count, DINT bearer, DINT dir, DSTR *data, DINT length), applies the 3g f8 algorithm (TS35.201) to the data. It returns the result in deststr. The other values are as defined in the specification. Dsecurity3gf9 The function, int Dsecurity3gf8(DSTR *deststr,DSTR *key, DINT count, DINT fresh, DINT dir, DSTR *data, DINT length), applies the 3g f9 algorithm (TS35.201) to the data. It returns the result in deststr. The other values are as defined in the specification. DsetOutheaderFunc The function, int DsetOutheaderFunc(DINT portnum, int (*outfunc)(char,void*,char**)), registers the specified outheader function outfunc to be called for all frames displayed on the specified port. This function is only useful with protocols that have implemented handling for this function. Its arguments are described in the relevant protocol (state machine) manuals. The outheader function is called asynchronously to the main DCPL script and the value of &portin variable presents the protocol port value of a received message, which is processed by the main DCPL script. The function DprocessedPort() can be called by the outheader function to obtain a value of displayed message port portnum and it can be useful in case of reuse of the outheader function for different ports. 9.6.10 Coprocessor UNIX Library Functions In addition to the DCPL-related functions above, there are several C-callable functions available in the Coprocessor environment, modeled after standard UNIX library functions. Unless otherwise indicated, they adhere to the conventions in the UNIX man pages specified. Floating-point capabilities are supported in the Coprocessor environment. abs atoi atol bcmp bcopy See man abs. See man atoi. See man atol. See man bcmp. See man bcopy.
9-16
Ixia
C Interface
bzero
See man bzero.
close See man close. The programmer must #include <jump.h> after all other #include lines. If the return value is less than 0, then it indicates 0-errno, as errno is not available globally. crypt See man crypt. See man encrypt.
encrypt exit
See man exit. Halts all execution on the Coprocessor board.
fstat See man fstat. The programmer must #include <jump.h> after all other #include lines. If the return value is less than 0, then it indicates 0-errno, as errno is not available globally. getenv See man getenv. The programmer must #include <jump.h> after all other #include lines. index isalpha isupper islower isdigit isxdigit isspace ispunct isalnum isprint isgraph iscntrl See man index. See man isalpha. See man isupper. See man islower. See man isdigit. See man isxdigit. See man isspace. See man ispunct. See man isalnum. See man isprint. See man isgraph. See man iscntrl.
9-17
C Interface
Ixia
isascii
See man isascii.
lseek See man lseek. The programmer must #include <jump.h> after all other #include lines. If the return value is less than 0, then it indicates 0-errno, as errno is not available globally. memcpy memset See man memcpy. See man memset.
open See man open. The programmer must #include <jump.h> after all other #include lines. If the return value is less than 0, then it indicates 0-errno, as errno is not available globally. qsort rand See man qsort. See man rand.
read See man read. The programmer must #include <jump.h> after all other #include lines. If the return value is less than 0, then it indicates 0-errno, as errno is not available globally. rindex setkey See man rindex. See man setkey.
sprintf See man sprintf. The programmer must #include <jump.h> after all other #include lines. Only d, D, u, U, o, O, x, X, p, s, c, and % format characters are supported; numeric field widths are supported by all formats except c and %. srand See man srand. See man strcasecmp.
strcasecmp strcat strchr strcmp strcpy
See man strcat. See man strchr. See man strcmp. See man strcpy.
9-18
Ixia
C Interface
strlen strncat
See man strlen. See man strncat. See man strncasecmp.
strncasecmp strncmp strncpy strstr swab toascii
See man strncmp. See man strncpy.
See man strstr. See man swab. See man toascii.
unlink See man unlink. The programmer must #include <jump.h> after all other #include lines. If the return value is less than 0, then it indicates 0-errno, as errno is not available globally. write See man write. The programmer must #include <jump.h> after all other #include lines. If the return value is less than 0, then it indicates 0-errno, as errno is not available globally.
9-19
C Interface
Ixia
9-20
10
Other UNIX Commands
Contents 10.1 dcpl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 10.2 dinuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 10.3 hminfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 10.4 man . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 10.5 r_util . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 10.6 slot_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 10.7 whatsinslot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Other UNIX Commands
Ixia
10.1
dcpl
The dcpl command, dcpl subject, displays information about subject, which can be either a DCPL statement or DCPL function. For example:
dcpl switch
Command usage and a list of available subjects are displayed when the dcpl command is issued without any arguments. If the argument all is used (that is, dcpl all), information on all DCPL subjects is displayed.
10.2
dinuse
The dinuse command, dinuse, displays one line for each Coprocessor board currently in use by a ddriver session. Each line is of the form:
BOARD slot IN USE BY PROCESS number
The dinuse syntax is the following:

dinuse [-l -s <slot>]+
When the -s option is used, dinuse reports on only the Coprocessor boards mentioned on the command line. For example, dinuse -s 3.6 -s 3.11 may produce the following output:
BOARD 3.6 NOT IN USE BOARD 3.11 IN USE BY PROCESS 1947
When the -l option is used, dinuse reports on the owner of the test running on the PPCI board as well as the length of time that the test has been running. For example, dinuse -l -s 1.1 may produce the following output:
BOARD 1.1 IN USE BY PROCESS 5466 OWNER bob RUNNING 3 sec
Note that the -l option must be specified before the -s option when both the options are used together.
10-2
Ixia
Other UNIX Commands
10.3
hminfo
Located in the $DCT2000PATH directory, the hminfo utility displays the Health Monitor information for the system, either for all the slots or for the specific slots listed. The usage is as follows:
hminfo [options] {slot(s)]
where: -a -n -x -h displays the available information as text disables a 'ping' attempt to slots with IP-Address displays all information in XML format displays this help information
hminfo displays the board type of all the detected boards as well as the serial number and revision number of each board. If a t600 is present, hminfo will also display the board type, serial number, and IP address of each board in the t600 chassis. Following is an example of the hminfo output.
> hminfo Shelf barney8@nc.catapult.com (172.28.0.1) running Linux 2.6.16.21-0.8-smp Inventory Slot 2: mPI SA-9300-i (#350 ) GigE SA-9350-e (#88 Slot 4: mCU5E SA-9215-b (#5 ) Slot 5: mPI SA-9300-i (#323 ) GigE SA-9350-b (#7 Slot 7: mCU5E SA-9215-b (#12 ) Problem Checklist 1. Slot 5, GigE, has revision [b] but should be at least [e]. LTE Sectors Chassis 1: mch-661 Sector:sector-119D8 Slot 1:lsc Slot 2:dsp Slot 3:fpga Slot 4:fpga Slot 5:fpga Slot 6:fpga
) )
ip=172.30.1.35 sn=72152 sn=0 sn=806045 sn=803828 sn=806473 sn=804814
ok ok ok ok ok ok
ip=172.30.1.50 ip=0.0.0.0 ip=172.30.1.52 ip=172.30.1.78 ip=172.30.1.56 ip=172.30.1.87
10-3
Other UNIX Commands
Ixia
10.4
man
The man command, man program, displays information about the specified UNIX program: ddc, launch, and so forth. For example:
man ddc
10.5
r_util
The r_util program is used to create routing tables for the SS7 MTP3 state machine. For information on the program, please run the following command:
man r_util
For further information on MTP3 routing tables, see the MTP3 Protocol Manual [15].
10.6
slot_info
Located in the diag subdirectory, the slot_info utility reports the board type of all the boards detected by the workstation. The serial numbers and eeprom revision numbers of the base board and mezzanine are also displayed. The usage is as follows:
slot_info [-q][-s n]
The option -q also displays the qspan information for each detected board. The option -s displays only the information about slot number n.
10.7
whatsinslot
Located in the diag subdirectory, the whatsinslot utility reports the board type of the board in a given slot in the workstation. The usage is as follows:
whatsinslot [-a] <slot number>
The option -a displays all the information regarding the board.
10-4
11
Custom Display Interface
Contents 11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 11.2 Environment Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 11.3 Procedure Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Ixia
11.1
Introduction
The IxCatapult software lets you define your own custom interfaces for the run-time display. If a custom display application is defined, the default menu (Detailed, Brief) associated with the Display button is extended to include a Custom option. This menu is used to switch between different display modes. A custom display is mapped in place of the text display window. The standard toolbar, prompt, and command line elements are retained, along with their associated functions. The Application Programmers Interface (API) is described in the following sections. These sections assume that the reader is familiar with programming in Tcl/Tk. The Tcl/Tk version currently supported by the IxCatapult system is 8.4.
11.2
Environment Variable
To indicate that a custom display is to be activated, specify the name of the Tcl file using the UNIX environment variable DCT2000_TCLAPPFILE. The file is evaluated using the Tcl_EvalFile() procedure.
11.3
Procedure Interfaces
The custom display API defines three procedure interfaces from the IxCatapult run-time packages. The functions and their parameters are defined in the following sections.
11.3.1
InitialiseCustomDisplay()
################################## ## ## InitialiseCustomDisplay() - Initialise custom display ## ## Parameters:## Window - parent window for custom display ## proc InitialiseCustomDisplay {Window} { }
This procedure is called during initialization of the IxCatapult run-time display. The parameter Window defines the name of the parent frame in which you can define your own Tcl/Tk elements.
11-2
Ixia
11.3.2
AddLineToCustomDisplay()
################################## ## ## AddLineToCustomDisplay() - Process output from IxCatapult ## ## Parameters:## Window - parent window for custom display ## LineType - line type {s}, {r} or {c} ## LineData - full DCPL decode ## Protocol - protocol name ## proc AddLineToCustomDisplay {Window LineType LineData Protocol} { }
The procedure is called for each line to be displayed. The Window parameter defines the name of the parent frame, as supplied to the InitialiseCustomDisplay() procedure. The LineType parameter defines the type of message as being sent {s}, received {r}, or commentary {c}. The LineData parameter is a string containing the complete message information, including any DCPL decoding if appropriate. The Protocol parameter defines the name of the protocol associated with the message. For commentary messages the Protocol parameter is a null (zero length) string. 11.3.3 ClearCustomDisplay()
################################## ## ## ClearCustomDisplay() - Clear display ## ## Parameters:## Window - parent window for custom display ## proc ClearCustomDisplay {Window} { }
This procedure is called if you click Clear while the Custom Display is mapped. The Window parameter defines the name of the parent frame, as supplied to the InitialiseCustomDisplay() procedure.
11-3
Ixia
11-4
12
Intermodule Timing
Contents 12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 12.2 Clock Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 12.3 Interconnecting Boards in a Domain . . . . . . . . . . . . . . . . . 123 12.4 Minimizing Propagation Delay . . . . . . . . . . . . . . . . . . . . . 123 12.5 Choosing a Domain Master and Clock Source. . . . . . . . . . . 124 12.6 Clock Configuration and ddriver . . . . . . . . . . . . . . . . . . . . 128 12.7 Clock Configuration and diag . . . . . . . . . . . . . . . . . . . . . . 128 12.8 Clock Configuration and t600. . . . . . . . . . . . . . . . . . . . . . 129
Intermodule Timing
Ixia
12.1
Introduction
Frequently, it is desirable for all Coprocessor boards (modules) in an IxCatapult system to have synchronized clocking, whereby the communication clocks and frame timestamps from each board (for example, in log files) are synchronized with the communication clocks and frame timestamps on the other boards. A group of boards that are interconnected so as to share a common timing source is called a timing domain. No necessary relationship exists between the set of boards used by a particular ddriver session and the set of boards in a timing domain. That is, multiple ddriver sessions can use boards from the same timing domain, and a single ddriver session can use boards from more than one timing domain. With rare exceptions, the preferred configuration is to interconnect all the Coprocessor boards in an IxCatapult system (or systems) into a single timing domain.
12.2
Clock Sources
Each Coprocessor board can receive its clock signal from one of five sources: the internal clock crystal on the board a neighbor Coprocessor board in the same chassis using an internal cable or internal shelf timing interconnect (m500 shelf only) a Coprocessor board in a different chassis of the same IxCatapult system using an external cable a Coprocessor board in another IxCatapult system using an external cable an 8-kHz clock signal from outside the system using an external cable
NOTE: An mCU(5)/mCU5E cannot use an external cable as a clock source, nor can it be a clock master. It must receive its clock signal from a neighbor Coprocessor board in the same chassis.
12-2
Ixia
Intermodule Timing
The single board that propagates the clock signal to all other boards in a domain is referred to as the domain master. The clock source for the domain master can be the internal crystal on that board, an external 8-kHz clock signal, or an external connection to another IxCatapult system. On an m500 shelf, if no external domain master is available, the domain master is the first m500-based board in the shelf with the best internal clock source (mPI(sSTM), mPI(OC3), mPI(Ethernet), mCI(ATM), then cBC).
12.3
Interconnecting Boards in a Domain

The boards in a domain must all be connected. Within a workstation, PowerPCI boards are connected using internal timing cables. Each PowerPCI board can be connected using internal cables to a maximum of two other boards, typically the two boards adjacent to it. Boards in a m500 shelf are all automatically on the same timing domain because of an internal shelf timing interconnect on the m500 midplane. Boards in different chassis are connected using external timing cables. Each board can be connected using an external cable to a maximum of one other board. The external timing cable, the cable to an external IxCatapult system, and the cable to an external 8-kHz clock signal all use the same connector, so each board can use only one of these connections. NOTE: See the p-Series Hardware Reference Manual [1] and m500 Hardware Reference Manual [2] for details of the cables, connectors, and signals.
12.4
Minimizing Propagation Delay

In order to maximize timing accuracy, care must be taken to minimize the propagation delay of the clock signal within each domain. Do this by minimizing the distance from the domain master to the farthest board in the domain, as measured in the number of external cables. For instance, in the Poor illustration below, some boards always are two external cables away from the domain master, regardless of where the domain master is located. In the Good illustration, no board is more than one external cable away from the domain master, if the domain master is located in the second chassis or shelf.
12-3
Intermodule Timing
Ixia
The system in fact chooses to place the domain master in the second chassis or shelf of the Good illustration. The heuristic it uses is to choose the chassis or shelf with the largest number of external cables. To take advantage of this, chassis must be connected in a star arrangement as in the Good illustration, rather than in a daisy chain as in the Poor illustration.
Chassis/shelf
Board
Poor
Good
12.5
Choosing a Domain Master and Clock Source

Unless you override the selection, the system by default selects a domain master for each domain, and it uses the domain masters crystal as the timing source. One reason you might choose to override these defaults is to minimize the propagation delay. Another is to choose a different clock source.
12-4
Ixia
Intermodule Timing
A domain cannot automatically span multiple systems, system being defined as a group of boards and one control computer. In the case of multiple interconnected systems, each system has a local domain master, which must have a .clockspec specification to inform it to use the remote system as a timing reference. NOTE: If an external clock is connected to one of the boards, you must create a .clockspec file specifying that that slot has an external clock. Otherwise, the IxCatapult system tries to determine the master clock by driving the internal and external clock pins on all the boards. Since the external clock signal is on all the time, the IxCatapult default is that all the boards are connected to the same clock signal. See the following .clockspec File section to determine how to create a .clockspec file. 12.5.1 .clockspec File You can override the system default choices of domain master and clock source by creating the file $DCT2000PATH/.clockspec. Each line in this file specifies the domain master and clock source for one domain. The .clockspec file must reside in the $DCT2000PATH that is used when booting. NOTE: Some systems have multiple installations, and since the .clockspec file is read only when booting, it must be in the boot .rc file definition of the path. However, if ppci_startup is run manually, the .clockspec file must be in the path where ppci_startup is run. The domain is implicitly the one containing the specified slot. The syntax for the .clockspec file is:
slot <slot #> <source>
where <slot #> specifies the slot number of the domain master, and <source> is one of the following: internal crystal - specifies that the master board use its local crystal as the clock master. external 8kHz - specifies that the master board use the 8-kHz clock pulse present on its external jack as the clock master. external catapult - specifies that the master board use a proprietary 8-kHz signal present on its external jack as the clock master. This proprietary signal, which includes embedded time stamp information, can only be sent by another Ixia board.
12-5
Intermodule Timing
Ixia
Blank lines and lines beginning with ! are ignored. Case is ignored. Any combination of spaces and tabs may be used to separate the fields within a line. The .clockspec file is read by ppci_startup. It does not take effect until ppci_startup is run. The following examples illustrate the use of each of the three possible clock sources. Example 1: m500
!Shelf clock synchronized to the mPI(OC3) in slot 4. !Selection of the actual clock source (external link or !generated from the board's quartz itself) is made in !sysconfig slot 4 internal crystal
Example 2: p400
!Slots 4 & 5 have their clocks synchronized using the internal !wire, and the clock should come from slot 5's internal crystal slot 5 internal crystal
Example 3: p400
!Slots 6, 7 & 9 have their clocks synchronized using the internal !wire. Clock source should come from slot 7's external clock !connection, coming from an external 8-kHz source slot 7 external 8khz
Example 4: p400
! example of 2 clock sources in a p400 system !slots 1 2 3 4 5 have their clocks synchronized using !the internal wire. !slots 6 7 8 9 have their clocks synchronized using !the internal wire and there is an external catapult !timing source cabled to slot 6. slot 4 internal crystal slot 6 external catapult
12-6
Ixia
Intermodule Timing
12.5.2
Running ppci_startup Since the clocking is configured when ppci_startup runs at system boot time, usually it is only necessary to run ppci_startup again if the hardware configuration is changed, that is, if the cabling or the .clockspec file is changed. The command is:
ppci_startup 1
CAUTION: ppci_startup can be run only when the system has no active sessions because the clocking on all boards in the domain is reset by this process. Also, all the boards in the system are reset and thus any other interconnected systems using this clock will be disturbed, but no verification takes place. You must be aware of the configuration to avoid disrupting sessions on the other systems. In addition to reconfiguring the clocking, the command displays a summary of resetting the boards and the configuration. Following is a p400 example:
ppci_startup 1 RELEASE_ID 14.3, VERSION_DATE January 2008 Initializing slot 1 ... done Initializing slot 2 ... done Initializing slot 3 ... done Initializing slot 4 ... done Initializing slot 5 ... done Initializing slot 6 ... done Initializing slot 7 ... done Initializing slot 8 ... done Initializing slot 9 ... done 2 timing domain(s) detected: Board 4 is master; source is its internal crystal Board 6 is master; source is an external Catapult board See /tmp/.clocklog for details.
12.5.3
.clocklog File ppci_startup creates a log file, /tmp/.clocklog, which shows details of the clocking configuration. The ppci_startup application is run by the IxCatapult initialization scripts at boot time. As a result, the .clockspec file must exist in the path as specified by the $DCT2000PATH environment variable at the time of execution of the IxCatapult initialization script. On some systems this path may differ from the one specified in the $DCT2000PATH environment variable of a normal user. At boot time, the $DCT2000PATH environment variable is set to /usr/catt_init.
12-7
Intermodule Timing
Ixia
Following is a p400 example of a .clocklog file:

Timing domain details of host lab-p400-4 at Mon Mar 10 22:30:47 2008 Clock spec file /home/dct2000/14.3/.clockspec: slot 4 internal crystal slot 6 external catapult 2 timing domain(s) detected: Board 4 is master; source is its internal crystal Contains slots 1 2 3 4 5 Board 6 is master; source is an external Catapult board Contains slots 6 7 8 9 External connections:
Note that External connections are only listed if two clock domains in a single shelf are connected together.
12.6
Clock Configuration and ddriver

The ppci_startup utility sets the clock configuration on a system. ddriver checks for the clock configuration on each board that it claims. ddriver warns users to run ppci_startup if the clock configuration on the PPCI boards has changed. ddriver will warn and exit if the clock configuration has changed on mPI/mPIE or mCU(5)/mCU5E boards. The mPI/mPIE and mCU(5)/mCU5E in slave mode need the master clock to be present. ddriver will exit if the master clock is missing.
12.7
Clock Configuration and diag

Running diag on a system modifies the clock configuration. diag resets the clock configuration on boards to internal master. The master will no longer source the system clock for slave boards. diag warns users to run ppci_startup to restore clock configuration. Slave board configuration remains unchanged even if diag is run. If a slave boards master has been removed by running diag, the slaves free run on their local oscillators and may drift with respect to other boards in the domain.
12-8
Ixia
Intermodule Timing
12.8
Clock Configuration and t600

The timestamps on the t600 LTE sectors are synchronized to the SM system clock via Precision Time Protocol (PTP) (IEEE 1588). When ddriver is invoked with the -y parameter (specifying t600 LTE sectors), a feature is enabled to synchronize the timestamp offsets on the PPCI cards in that ddriver session with the SM system clock. If this feature is desired without LTE components, the environment variable CATT_SYNC_PPCI_TIMESTAMPS can be set. For example:
setenv CATT_SYNC_PPCI_TIMESTAMPS
12-9
Intermodule Timing
Ixia
12-10
13
Multiple VPI/VCI
Contents 13.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 13.2 Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 13.3 User Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 13.4 sysconfig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 13.5 User Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 13.6 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 13.7 VPI, VCI, Link, and CID Decoding. . . . . . . . . . . . . . . . . . . 139 13.8 Peak Cell Rate Configuration . . . . . . . . . . . . . . . . . . . . . 1310 13.9 Variable Bit Rate (VBR) ATM Traffic Type . . . . . . . . . . . . . 1312 13.10 ATM OAM F4/F5 Flow Configuration . . . . . . . . . . . . . . . 1315
Multiple VPI/VCI
Ixia
13.1
Introduction
In multiple VPI/VCI mode the system supports a multiple number of VPI/VCIs per physical port. The multiple VPI/VCI feature can be used in load testing, where a script simulates a large number of subscribers. The association between a port and a VPI/VCI combination is made dynamically. In single VPI/VCI mode, the system supports one VPI/VCI per physical port. In this mode, you specify statically at configuration time (using sysconfig) the VPI/VCI to be used at a physical port. A number of ATM protocols and ATM traffic types are supported with this feature. The ATM protocols include AAL0, AAL1, AAL2, AAL5, and IP/AAL5.
13.2
Limits
The limit on the number of VPI/VCIs of various protocol types varies depending on the particular physical interface board being used. See the following table.
Physical interface OC3 OC3E mCI(ATM) mPI(OC3) J1/E1/T1
Max # of VPI/VCIs 200 1023 2046 (1023 per Processor) 1023 200 200
Max # of AAL2 VPI/VCIs
400 (200 per Processor) 200
4096 (1024 per port) Note 1 16384 (4096 per port) Note 2, Note 3
NOTE 1: This can be achieved with 3 mCI or 3 mCU processors. Each mCI or mCU processor can support 1954 connections per processor. NOTE 2: This can be achieved with 9 mCI or 9 mCU processors with filtering OFF. Each mCI or mCU processor can support 1954 connections per processor. NOTE 3: Filtering can be turned ON on the mCI or mCU processors on 1023 unique AAL2 VPI/VCIs. The total number of filters that can be supported on AAL2 VPI/VCI/CID is 1954.
When physical ports are configured in AAL2 mode, several extensions to the features described in this section are provided by AAL2. See the AAL2 Protocol Manual [13] for details.
13.3
User Interaction
To be able to use a multiple number of VPI/VCIs per port, you must set up information in sysconfig and specify inside the DCPL script which VPI/VCI to use.
13-2
Ixia
Multiple VPI/VCI
13.4
sysconfig
The sysconfig program allows you to select single VPI/VCI mode or multiple VPI/VCI mode for the entire board. If you select single VPI/VCI mode for each physical port, you must select the mode, the link, and the protocol and enter the values of GFC, VPI, VCI, and PT for the cell header. If multiple VPI/VCI mode is selected, the link selection and the cell header entries are grayed out. The link value, cell header value, and other ATM parameters are set dynamically within DCPL user scripts. For more information, see Chapter 2, Configuring an IxCatapult Session.
13.5
13.5.1
User Scripts
Channel Initialization To configure the DCPL user scripts, you must initialize reception and transmission of the VPI/VCIs. To do this, use the port-specific %initcell special variable. This variable holds the value of the cell header (GFC, VPI, VCI and PT), the link number, and the channel peak cell rate used for cell transmission. Note that for AAL1 and AAL2 connections, %initcell also carries additional AAL1 and AAL2 specific parameters. See the AAL1PRIM Protocol Manual [12] and AAL2 Protocol Manual [13] for details. You can invoke macros to build the special variables by passing integers as parameters. These macros are defined and documented in the file, mvpivci.dh, located in $DCT2000PATH. You must include this file in your script in order to use these macros. For convenience, the content of mvpivci.dh is available in Appendix A, mvpivci.dh File. For example, the following expression initializes a Constant Bit Rate (CBR) AAL5 channel with GFC=0, VPI=4, VCI=25, PT/CLP=0, Link=1, and a PCR of 1650 cells/second.
%initcell{1} = MAKE_INIT_CELL(0, 4, 25, 0, 1, 1650)
The following expression initializes an Unspecified Bit Rate (UBR) AAL5 channel with GFC=0, VPI=4, VCI=25, PT/CLP=0, Link=1, and a suggested PCR of 1650 cells/second.
%initcell{1} = MAKE_INIT_CELL_UBR(0, 4, 25, 0, 1, 1650)
13-3
Multiple VPI/VCI
Ixia
When the VPI/VCI initialization is done from upper-layer protocols, the logical script port where %initcell is invoked must be associated with the corresponding physical port. This will add the -h option to the ddriver command line. Port associations must be added when special variable %initcell is set, because a command is sent directly to the mezzanine (rather than a frame being sent down) on the board port corresponding to the logical script port to do all the necessary initialization of the given cellheader. Similar to single VPI/VCI mode, in multiple VPI/VCI mode the same triplet (VPI, VCI, link number) must not be used on two different physical ports. On mCI(ATM), currently there is no enforcement of VPI/VCI conflicts between Coprocessors. A typical user script would initialize VPI/VCIs in a loop as follows:
for (&index=0; &index < ...; &index=&index+1) %initcell{port} = ... endfor ...
13.5.2
Limitations and Exceptions OC3 For OC3, the sum of the rates used in the %initcell calls must not exceed the maximum cell rate defined by the board configuration using sysconfig. For example, the default maximum cell rate is 65000 cells/second on each link (for OC3) so the sum of the rates for each %initcell call cannot exceed this value. If you set the maximum to something lower than 65000, then the sum of the rates cannot exceed the user-specified maximum. mCI(ATM) For mCI(ATM), references to an invalid link (that is, link 1) result in a run-time error and the channel is not initialized. For mCI(ATM) optical mode, AAL2 CIDs on a single VPI/VCI cannot be multiplexed between two processors. The mCI(ATM) will not route based on CIDs. The VP/VC's are also expected to be unique across processors on the same mCI(ATM). mPI(OC3) On the mPI(OC3), the preassigned values of VPI, VCI, and PT will be as per the ITU-T Recommendation I.361 B-ISDN ATM layer specifications. These preassigned values will be adhered to. The user scripts hence need to pay special attention to the values of VPI, VCI, and PT used for simulation.
13-4
Ixia
Multiple VPI/VCI
For the mPI(OC3), the Maximum Aggregate Cell Rate defined in sysconfig for each physical interface is not used. Instead, the maximum aggregate cell rate used is that of the OC-3c physical interface, or 353207 cells/second. When using AAL2 on the mPI(OC3), only the %initcell macros that end with the suffix _CID may be used to configure channels. With past IxCatapult hardware only the AAL2 VPI/VCI needed to be specified before sending data on a particular CID. The mPI(OC3) hardware requires that the %initcell macro include the VPI/VCI and CID to open a channel, before data can be sent on that CID. When using the mPI(OC3), the peak cell rate (PCR) for any AAL type is required and must be specified as non-zero. OC-3E, J1/E1/T1, and mCI(ATM) For OC-3E, J1/E1/T1, and mCI(ATM), the sum of the rates used in the %initcell calls must not exceed the Max Aggregate Cell Rate defined by the board configuration using sysconfig. For example, if the Max Aggregate Cell Rate is 255000, the sum of the rates for each %initcell call on that link cannot exceed this value. Accordingly, the minimum value for an individual channel on that link must be greater than or equal to (Max Aggregate Cell Rate)/(Max Num Channels) or, in the previous example, 997 if Max Num Channels is 256. The rate in the %initcell call for Monitor mode is used as a guideline for the speed expected on the monitored channel. It helps to prepare the internal data structures to best accommodate the expected speed. 13.5.3 Transmission When a frame is to be transmitted, a port specific special variable, specifying the cellheader and the link number to be used within the ATM frame cells, must be set. For example,
%sendcellheader{port} = MAKE_CELL_HEADER(0,4,25,0,1) {port} free i = %frame
where %frame is the frame to be sent, %sendcellheader is the port specific special variable, GFC=0, VPI=4, VCI=25, PT/CLP=0, and Link=1.
13-5
Multiple VPI/VCI
Ixia
Any subsequent frame sent on the port uses the value of %sendcellheader. Typically, a user script is written in such a way that the cellheader values and frame transmission are done inside a loop as shown in the following:
for (&index=0; &index< ..., &index=&index+1) %sendcellheader{port} = ... {port} free i = %frame endfor
where %sendcellheader has a different value at each occurrence. 13.5.4 Reception When receiving a frame, a script can check from which channel this frame came. This check is provided by getting the value of the port-specific special variable, %receivecellheader, that stores the value of GFC, VPI, VCI, PT, and CLP of the last received frame. The RECEIVED_ macros extract fields from the special variable and are in the file, mvpivci.dh. The content of mvpivci.dh is available in Appendix A, mvpivci.dh File. The following is an example of a script that stores the values of the received cellheaders into an array:
&index = 0 while (1) wait %frame for 0 %cellheaderArray[&index]{&portin} = %receivecellheader{&portin} &index = &index + 1 endwhile
sprint Received VCI=,string(RECEIVED_CELLHEADER_VCI(&portin))
13.5.5
Channel Invalidation In some cases a certain value of the cellheader that was used is no longer needed. In these cases, this particular value of the cell header can be released and another one may be used instead. This allows you to use more cellheaders than the maximum number of simultaneous cellheaders permitted by the system. To implement this feature, use the %invalidcell special variable. When a value is assigned to this variable, reception of all corresponding cells is stopped right away. At the expiration of a guard timer, transmission of corresponding cells is also stopped, and the hardware resources allocated to the corresponding channel are released. Transmission is stopped only after the expiration of a guard timer to allow any other potential script using the same cell header value to complete its frame transmissions. The guard timer value is specified as a port specific special variable &mvpivcireleasetimer{} in centisecond units with a default value equal to 0.
13-6
Ixia
Multiple VPI/VCI
For example, the following implies that the guard timer is set to 20 centiseconds on port 2:
&mvpivcireleasetimer{2} = 20
The resolution of the &mvpivcireleasetimer on the different physical interface types is shown in the following table.
Physical Interface Resolution of the Release Timer (in centiseconds) 1 20 20 Not Applicable 20 1 400 400 Not Applicable 20 Default Timer Setting (in centiseconds)
OC3 OC3E mCI(ATM) mPI(OC3) J1/E1/T1
If the release timer is not set, the default time setting for the interface will be applied before releasing all of the hardware resources associated with the invalidated channel. Any attempt to reinitialize this channel with an %initcell assignment during that period will fail. Note that the variable %invalidcell contains GFC, VPI, VCI, PT, CLP, and link number in the same order as %initcell. 13.5.6 Other Variables A special variable, &mvpivcinumberchannels{port}, allows you to check the current number of channels active at a specific context. Variable &mvpivcinumberchannels{port} is port-specific because, if there was a workstation context running above the PPCI board context, and the workstation context has to query the value of the variable, the workstation context has to associate a workstation context port with the board port to read the variable.
13-7
Multiple VPI/VCI
Ixia
13.6
Example
This example is of a loopback script running on a board that sends 100 AAL5 (SSCOP) frames on one port and receives them on the other port. Note that this example use the maximum number of 20 channels on each link.
include mvpivci.dh sprint Script Begins ... write trace {1}add display {2}add display &vpi = 1 &ln{1} = 0 &ln{2} = 1 &gfc = 0 &pt_clp = 0 &rate = 1000 define LOOP = 20 sprint Initialize Cellheaders Now ... for (&vci = 0; &vci < LOOP; &vci = &vci + 1) %initcell{1} = MAKE_INIT_CELL(&gfc, &vpi, &vci, \ &pt_clp, &ln{1}, &rate) %initcell{2} = MAKE_INIT_CELL(&gfc, &vpi, &vci, \ &pt_clp, &ln{2}, &rate) endfor sprint Sending frames for (&vci = 0; &vci < LOOP; &vci = &vci + 1) %sendcellheader{1} = MAKE_CELL_HEADER(&gfc, &vpi, &vci,\ &pt_clp, &ln{1}) {1} poll nps=1 ns=1 /* SSCOP Poll */ wait %f endfor sprint Received frames
13-8
Ixia
Multiple VPI/VCI
13.7
VPI, VCI, Link, and CID Decoding

When dctprint is run on log files using the multiple VPI/VCI feature, or at run time if the main ddriver window or context view windows have display turned on, any frames sent or received are decoded as normal. If VPI, VCI, link, and/or CID information is coming with that frame (which populates %receivecellheader) it is decoded as well. The format is as follows, depending on the length of the %receivecellheader:
%receivecellheader length 1 (CID only) 5 (VPI, VCI, link) 6 (VPI, VCI, link, CID) Example input $55 $1011223001 $101122300055 Example output C=85 L=1 VP=257 VC=4643 L=0 VP=257 VC=4643 C=85
The 32-bit cell header portion is decoded according to the selected format. If the UNI (NNI) format is selected, it is decoded in the UNI (NNI) format. You can post-process any IxCatapult log files (.out) generated during multiple VPI/VCI sessions, so that dctprint decodes in UNI format instead of NNI format. Use the sed command in place of the dctprint command: Before:
dctprint < xxxx.out > xxxx.dct
After:
sed -e s/1,\$/2,\$/g -e s/3,\$/4,\$/g xxxx.out | \ dctprint > xxxx.dct
Thus, output in UNI format would be:

%receivecellheader length 1 (CID only) 5 (GFC, VPI, VCI, link) 6 (GFC, VPI, VCI, link, CID) Example input $55 $1011223001 $10112230005 5 C=85 L=1 GFC=1 VP=1 VC=4643 L=0 GFC=1 VP=1 VC=4643 C=85 Example output
13-9
Multiple VPI/VCI
Ixia
13.8
13.8.1
Peak Cell Rate Configuration

ATM Performance Guidelines NOTE: This section applies to OC3, OC3E, and mCI(ATM) boards only. For T1/E1 and J1/E1/T1 boards, the limiting factor for throughput (for all frame sizes) is transmission capacity of the link. In order to maximize throughput for short (<200 bytes) frames, the sum of Channel Peak Cell Rates (used in %initcell{}) of all channels initialized per physical link (aggregated cell rate per link) must not exceed an optimum value. A high aggregated cell rate causes higher consumption of board resources (even under idle conditions) resulting in lowering throughput for short frame traffic. Note that for short frames, processing power of the communications subsystem, rather than bit rate of the transmission link, limits throughput. Setting the high aggregated cell rate does not increase overall throughput when the majority of the traffic is short frames. Optimal value of aggregated cell rate for short frames traffic depends on the board type and version of the IxCatapult software. As guidance, the aggregated cell rate used should be in the range of 18000 to 25000 cps for an OC3, and between 35000 to 60000 cps for an OC3E or mCI(ATM) Processor. The Maximum Aggregate Cell Rate also cannot exceed the physical link limit. When larger frames are used, higher values of aggregated cell rate can be set to achieve higher byte/sec throughput.
13.8.2
E1/T1 Board Due to the limitations of the processor used on the E1/T1 mezzanine, the Automatic Pace Control (APC) only works if the total number of channels initialized in multiple VPI/VCI mode on T1/E1 (sum of channels initialized on both links) is less then 31. Only the Channel Peak Cell Rate parameter of %initcell{} is valid. In other words, ATM cells are scheduled according to this number. When the number of initialized channels becomes greater then 30 ATM cells (for all channels) the Channel Cell Rate does not follow Channel Peak Cell Rate. For the case where APC is active (number of channels < 31) Channel Peak Cell Rate should follow the guidelines specified for the OC3 board. (This restriction does not apply to the J1/E1/T1 board.)
13-10
Ixia
Multiple VPI/VCI
13.8.3
OC3 Board The Channel Peak Cell Rate values used in %initcell{} must adhere to the following rules: highest Peak Cell Rate on board / 256 <= Channel Peak Cell Rate < = highest Peak Cell Rate on board sum of Channel Peak Cell Rates <= Peak Cell Rate on that board port
where Max Peak Cell Rate is configured using the sysconfig utility. For example to implement 8 channels on a port, each peaking at 20 cells/second, well need to select Peak Cell Rate such that it satisfies both rules described above. Channel Peak Cell Rate of 20 cells/second limits our choice of Peak Cell Rate to between 20 and 5120 (rule 1). In order to handle 8 such channels, the Peak Cell Rate must be at least 20 * 8 = 160 (rule 2), so it can be set to any value within 160 to 5120. In order to minimize transmission jitter, Channel Peak Cell Rates should be chosen such that highest Peak Cell Rate is divisible by Channel Peak Cell Rate, and Channel Peak Cell Rate is as close to Peak Cell Rate as possible. For example a more advanced test may require up to 10 channels running at 10, 13 or 15 cells/second with low jitter. Using rule 1 we can determine that Peak Cell Rate has to fall between 15 and 2560 cells/second. Rule 2 indicates that 10 x 15 cells/second channels requires Max Peak Cell Rate >= 150. Finally, to minimize jitter, the ideal Peak Cell Rate would be 390, since its the smallest number that is divisible by 10, 13 and 15 and falls within 150 and 2560. 13.8.4 OC3E, J1/E1/T1, and mCI(ATM) Boards The Channel Peak Cell Rate values used in %initcell{} must adhere to the following rules: (Max Aggregate Cell Rate on link)/(Max Num Channels) <= Channel Peak Cell Rate <= (Max Aggregate Cell Rate on link)/(Max Num Channels)*256 sum of Channel Peak Cell Rates on a link <= Max Aggregate Cell Rate on that link and Max Num Channels on a link are utility, see Section 2.12, PPCI (OC3E) 2-25, Section 2.8, PPCI (J1/E1/T1) 2-13, and Section 2.15, mCI(ATM) 2-39.
where Max Aggregate Cell Rate configured using the sysconfig Configuration Window, on page Configuration Window, on page Configuration Window, on page
13-11
Multiple VPI/VCI
Ixia
For example to implement 8 channels on link 0, each peaking at 20 cells/second, well need to select Max Aggregate Cell Rate such that it satisfies both rules described above. Max Num Channels should be 256. Channel Peak Cell Rate of 20 cells/second limits our choice of Max Aggregate Cell Rate to between 20 and 5120 (rule 1). In order to handle 8 such channels, the Max Aggregate Cell Rate must be at least 20 * 8 = 160 (rule 2), so it can be set to any value within 160 to 5120. For the J1/E1/T1 board configured for a partial link ATM cell stream, the physical link rate is the J1/E1/T1 ATM rate (4528 for E1 or 3622 for T1/J1) prorated to the number of time slots that are used. For example, a partial ATM in one time slot has a maximum link rate of 150 cells/second. NOTE: For the J1/E1/T1 board, the Maximum Aggregate Cell Rate for any one link can differ from the other three links by a maximum of 127 times. In addition, the Maximum Aggregate Cell Rate value that is less than the physical link rate my be slightly downgraded due to clock divider capability. 13.8.5 mPI(OC3) Board The mPI(OC3) board has a Maximum Aggregate Cell Rate of 353207 for each OC-3c physical interface. On each interface, the sum of all Peak Cell Rates for each VPI/VCI created must by less than or equal to 353207. If the sum is greater, the mPI(OC3) board will be unable to transmit all of the data presented to it. On the mPI(OC3) board, the maximum Peak Cell Rate for a single VPI/VCI is 88301 cells/second. The minimum Peak Cell Rate is 1 cell/second.
13.9
Variable Bit Rate (VBR) ATM Traffic Type

The PPCI OC3E and mCI(ATM) boards support Variable Bit Rate (VBR) ATM traffic type when configured to operate in multiple VPI/VCI mode. This functionality is currently not supported in single VPI/VCI mode. As a result to utilize the VBR functionality of these boards they must be configured for multiple VPIVCI operation via the sysconfig utility. Configuration of the traffic parameters for each VBR ATM channel is achieved through the extended used of the DCPL %initcell special variable which is initially outlined in Section 13.5, User Scripts, on page 13-3.
13-12
Ixia
Multiple VPI/VCI
Specifying the VBR traffic parameters for a VBR channel requires three (3) extra traffic parameters over the normal AAL parameters and cell header information required for CBR initcell operations. These parameters are Peak Cell Rate, Sustain Cell Rate and Maximum Burst Size, subsequently referred to as PCR, SCR and MBS respectively from this point on. 13.9.1 Peak Cell Rate (PCR) Peak Cell Rate is the rate in cells per second that the ATM pace controller will schedule cells for transmission whilst a positive non-zero burst credit remains. The Peak Cell Rate must be equal or greater than the Sustain Cell Rate. 13.9.2 Sustain Cell Rate (SCR) Sustain Cell Rate is the rate in cells per second that the ATM pace controller will schedule cells for transmission whilst the burst credit is exhausted (remains zero). The Sustain Cell Rate must be equal or less than the Peak Cell Rate. 13.9.3 Maximum Burst Size (MBS) Maximum Burst Size is the total number of cells which the ATM pace controller is allowed to schedule for transmission above the integral of the Sustain Cell Rate i.e. A MBS of 10000 would allow the ATM pace controller to schedule transmission of 10000 extra ATM cells at the PCR over and above what it would have been able to transmit at the SCR. 13.9.4 VBR MAKE_INIT_CELL MACROS As indicated above, VBR traffic parameters for each VBR channel are specified via the %initcell special variable. A series of DCPL macros have been define to facilitate the easy building of %initcell configuration strings. These macros can be found in the mvpivci.dh include file. All existing ATM adaptation layers (AAL0, AAL1, AAL2, AAL5) can operate over a VBR channel. The definitions of the parameters required by the VBR specific MAKE_INITCELL macros are the same as their Constant Bit Rate (CBR) counterparts except for the two additional parameters: Sustain Cell Rate (SCR) and Maximum Burst Size (MBS). Therefore, see the above CBR definitions of MAKE_INIT_CELL parameters other than SCR and MBS.
13-13
Multiple VPI/VCI
Ixia
13.9.5
Defining VBR Traffic The Variable Bit Rate (VBR) traffic is defined by these parameters in the following way. The ATM pace controller regulates the transmission of ATM cells offered to a VBR channel by means of a credit based burst allowance. The ATM pace controller will transmit offered traffic, at the cell rate defined by the PCR parameter, keeping a record of the difference between the number of cells that have been transmitted and the number of cells that would have been transmitted over the same period of time if the cells were transmitted at the SCR. As the PCR is always bigger than the SCR this difference is always a positive value. Once this difference has reached the value defined by the MBS parameter, the ATM pace controller is said to have exhausted it burst credit and now schedules the transmission of cells at the lower SCR. Cell transmission continues at the SCR whilst the burst credit for the channel remains exhausted. The burst credit remains exhausted until the traffic offered to the VBR channel becomes less than the SCR. In this situation the difference between the number of cells transmitted and the number of cell that would be transmitted at the SCR over the same period of time is recorded. This difference is the replenishment of the burst cell credit which continues to accumulate whilst the offered traffic remains less than the SCR or until the burst cell credit has reached the value specified by the MBS parameter to which burst credit is capped.
13.9.6
VBR Limitations CBR and VBR ATM traffic types are currently scheduled by the ATM Pace Controller at the same priority level. This will have no side effects should only one traffic type is being used or both types used under light traffic loads. Using both CBR and VBR ATM traffic types under heavy traffic loads may cause the jitter characteristics of the CBR traffic type to be degraded.
13.9.7
VBR Example The following example configures two VBR channels between links 0 and 1 of a OC3e PPCI board or mCI(atm) board with a Peak Cell Rate of 1000 cells/sec and a Sustain Cell rate of 500cells/sec. The Burst Tolerance is set to 100 cells. Once the VBR channels have been configured the script then transmits 100 saalunni_sscp poll messages from link 0 to link 1.
include mvpivci.dh
13-14
Ixia
Multiple VPI/VCI
// This script only functions on OC3E and mCI(ATM) cards sprint Script Begins ... {1}add display {2}add display &vpi = 1 &ln{1} = 0 &ln{2} = 1 &gfc = 0 &pt_clp = 0 &pcr = 1000 &scr = 500 &bt = 100 define LOOP = 20 sprint Initialize Cellheaders Now ... for (&vci = 0; &vci < LOOP; &vci = &vci + 1) // CBR initcell operations - not used //left for comparision // %initcell{1} = MAKE_INIT_CELL(&gfc, &vpi, \ &vci, &pt_clp, &ln{1}, &pcr) // %initcell{2} = MAKE_INIT_CELL(&gfc, &vpi, \ &vci, &pt_clp, &ln{2}, &pcr) // VBR initcell operations to establish a 2 VBR channels with //pcr=1000 cells/sec //scr = 500 cells/sec //bt = 100 cells %initcell{1} &vci, &pt_clp, %initcell{2} &vci, &pt_clp, endfor = MAKE_INIT_CELL_VBR(&gfc, &vpi, \ &ln{1} , &pcr, &scr, &bt) = MAKE_INIT_CELL_VBR(&gfc, &vpi, \ &ln{2} , &pcr, &scr, &bt)
wait %f for 100 sprint Sending frames for (&vci = 0; &vci < LOOP; &vci = &vci + 1) %sendcellheader{1} = MAKE_CELL_HEADER(&gfc, \ &vpi, &vci, &pt_clp, &ln{1}) //{1} free i=heello world {1} poll nps=1 ns=1 /* SSCOP Poll */ wait %f endfor sprint Received frames
13.10 ATM OAM F4/F5 Flow Configuration

The OC3E PPCI, J1/E1/T1, mCI(ATM) and mPI(OC3) boards support configuration of F4 and F5 OAM headers when configured to operate in multiple VPI/VCI mode to allow you to build, send and receive fault management type OAM cells. This functionality is currently not supported in single VPI/VCI mode. As a result to utilize the OAM functionality of these boards they must be configured for multiple VPI/VCI operation through the sysconfig utility.
13-15
Multiple VPI/VCI
Ixia
Configuration of a F4 and F5 OAM channel is achieved through the extended use of the DCPL %initcell special variable which is initially outlined in Section 13.5, User Scripts, on page 13-3. The specialized OAM %initcell format separates the AAL inputs for Payload Type Identifier (PT) and Cell Loss Priority (CLP) into 2 parameters.
13-16
Ixia
Multiple VPI/VCI
13.10.1 F4 OAM Flow Support F4 Flow is designated by pre-assigned VCIs. Segment OAM F4 is identified by VCI 3 and End-to-End OAM F4 is identified by VCI 4. A series of DCPL macros have been define to facilitate the easy building of %initcell configuration strings. These macros can be found in the mvpivci.dh include file. OAM Cells can only operate over AAL0 using the %initcell macros MAKE_INIT_CELL_AAL0_OAM or MAKE_NNI_INIT_CELL_AAL0_OAM with VCI set either to 3 or 4. The peak cell rate that is set on the first OAM %initcell dictates the cell rate that will be used for the course of the user script. Peak cell rates that differ in subsequent OAM %initcell settings will be ignored. The two kinds of F4 flows can exist simultaneously. Since F4 Flow is specified using pre-assigned VCI values, setting up an F4 OAM channel deducts from the overall available VPI/VCIs for the board. (See Section 13.2, Limits, on page 13-2.) 13.10.2 F5 OAM Flow Support F5 Flow is designated by pre-assigned Payload Type Identifiers (PT). Segment OAM F5 is identified by PT 4 and End-to-End OAM F5 is identified by PT 5. A series of DCPL macros have been define to facilitate the easy building of %initcell configuration strings. These macros can be found in the mvpivci.dh include file. OAM Cells can only operate over AAL0 using the %initcell macros MAKE_INIT_CELL_AAL0_OAM or MAKE_NNI_INIT_CELL_AAL0_OAM with VPI and VCI set to match an existing channel and a PT value set to either 4 or 5. The peak cell rate that is set on the first OAM %initcell dictates the cell rate that will be used for the course of the user script. Peak cell rates that differ in subsequent OAM %initcell settings will be ignored. Since F5 Flow is tied to a particular channel, the VPI/VCI that the user wishes to perform OAM on must already have been created via the normal %initcell setup for a data/signal channel. If the channel does not exist, the %initcell request to set up the F5 OAM will be rejected.
13-17
Multiple VPI/VCI
Ixia
13.10.3 AAL0PRIM and CRC-10 Calculation Since there is no encoder/decoder support for the different OAM cells, it is recommended that the OAM cells be built up in an aal0prim message format. The aal0prim protocol requires that the message be 48 bytes in length. OAM cells have the following format:
4 bits - OAM Type 4 bits - Function Type 45 bytes - Function Specific Field 6 bits - Reserved 10 bits - CRC-10
The CRC-10 is generated by the OC3E PPCI, J1/E1/T1 PPCI, mCI(ATM) and mPI(OC3) board before the OAM cell is transmitted in the last 10 bits of the cell. When building the OAM cell in the aal0prim message format, the user should set the last 16 bits of the message to zero. 13.10.4 OAM Limitations F4 and F5 OAM is only supported on OC3E PPCI, J1/E1/T1 PPCI, mCI(ATM) and mPI(OC3) boards. F4 and F5 OAM headers can only be configured in multiple VPI/VCI mode. F4 and F5 OAM headers can only be configured on a port configured as AAL0 in multiple VPI/VCI mode. Performance monitoring is currently not supported by the OC3E PPCI, J1/E1/T1 PPCI, mPI(OC3) or mCI(ATM) boards. There is no protocol support for the OAM messages. OAM messages should be built up in an aal0prim message. See Recommendation I.610 for details on the Fault Management OAM cell formats.
13.10.5 F4 OAM Example

// This script assumes that port 1 is tied to // a multiple VPI/VCI AAL0 port. include mvpivci.dh &F4_VPI = 0 &F4_SEG_VCI = 3 &F4_ETE_VCI = 4 &F4_LINK = 0 &F4_PCR = 500 define SEND_OAM_FRAME(@OAMFRAME,@MYVPI,@MYVCI,@PTI)={ if len (@OAMFRAME) = 48 %sendcellheader{1} = MAKE_NNI_CELL_HEADER_OAM(@MYVPI, \ @MYVCI, @PTI, 0, &F4_LINK) {1}aal0data i = @OAMFRAME else sprint Malformed OAM frame -impossible to send endif
13-18
Ixia
Multiple VPI/VCI
} define BUILD_OAM_RDI_FRAME(@OAMFRAME,@OAMTYPE,@FUNCTIONTYPE)={ @OAMFRAME = bitn(4;@OAMTYPE ),bitn(4;@FUNCTIONTYPE), \ strrepeat($6a;45),$0000 } // Initialize the F4 OAM Channels %initcell{1} = MAKE_NNI_INIT_CELL_AAL0_OAM(&F4_VPI, \ &F4_SEG_VCI, 0, 0, &F4_LINK, &F4_PCR) %initcell{1} = MAKE_NNI_INIT_CELL_AAL0_OAM(&F4_VPI, \ &F4_ETE_VCI, 0, 0, &F4_LINK, &F4_PCR) // Send an RDI Segment OAM &OAM_Type = 1 &Function_Type = 1 BUILD_OAM_RDI_FRAME(%OAM_Frame, &OAM_Type, &Function_Type) SEND_OAM_FRAME(%OAM_Frame, &F4_VPI, &F4_SEG_VCI, 0)
13.10.6 F5 OAM Example

// This script assumes that port 1 is tied to // a multiple VPI/VCI AAL0 port and port 2 is // tied to a multiple VPI/VCI AAL5 port. include mvpivci.dh &VPI = 0 &VCI = 65 &F5_SEG_PT = 4 &F5_ETE_PT = 5 &F5_LINK = 0 &F5_PCR = 500 define SEND_OAM_FRAME(@OAMFRAME,@MYVPI,@MYVCI,@PTI)={ if len (@OAMFRAME) = 48 %sendcellheader{1} = MAKE_NNI_CELL_HEADER_OAM(@MYVPI, \ @MYVCI, @PTI, 0, &F4_LINK) {1}aal0data i = @OAMFRAME else sprint Malformed OAM frame -impossible to send endif } define BUILD_OAM_RDI_FRAME(@OAMFRAME,@OAMTYPE,@FUNCTIONTYPE)={ @OAMFRAME = bitn(4;@OAMTYPE ),bitn(4;@FUNCTIONTYPE), \ strrepeat($6a;45),$0000 } // Initialize the AAL5 Channel on port 2. %initcell{2} = MAKE_NNI_INIT_CELL(&VPI, &VCI, 0, \ &F5_LINK, &F5_PCR) // Initialize the F5 OAM Channels on port 1. %initcell{1} = MAKE_NNI_INIT_CELL_AAL0_OAM(&VPI, \ &VCI, &F5_SEG_PT, 0, &F5_LINK, &F5_PCR) %initcell{1} = MAKE_NNI_INIT_CELL_AAL0_OAM(&VPI, \ &VCI, &F5_ETE_PT, 0, &F5_LINK, &F5_PCR) // Send an RDI Segment OAM &OAM_Type = 1 &Function_Type = 1 BUILD_OAM_RDI_FRAME(%OAM_Frame, &OAM_Type, &Function_Type) SEND_OAM_FRAME(%OAM_Frame, &VPI, &VCI, &F5_SEG_PT)
13-19
Multiple VPI/VCI
Ixia
13-20
14
Dynamic TDM Channels
Contents 14.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 14.2 User Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 14.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 14.4 Adapting Legacy Applications to Dynamic TDM . . . . . . . . . 144
Ixia
14.1
Introduction
There are two TDM operating modes for the PPCI J1/E1/T1 (JET) board: In static TDM mode, the system supports only one TDM channel per board port. In this mode, the channel is configured statically using sysconfig. In dynamic TDM mode, the system supports a multiple number of TDM channels per board port. The association between a port, a link and a timeslot combination is made dynamically using DCPL except for SS7 channels. SS7 channels in dynamic TDM mode are configured using sysconfig.
See Section 2.8, PPCI (J1/E1/T1) Configuration Window, on page 2-13 for details on configuring static and dynamic TDM modes using sysconfig.
14.2
User Scripts
The openchannel function can be used to open/initialize a TDM channel. This function is called from a DCPL script to open a TDM channel at a board port or an associated board port and returns a logical channel number which is used as a channel identifier.
&channelnum = openchannel(&channel_id; &port; &channel_type; ... )
See Section 8.5.3, Dynamic TDM Channel Functions, on page 8-54 for detail about how to use the openchannel function. When a frame is to be transmitted, the logical channel number should be assigned to a port specific special variable &sendchannelnum as:
&sendchannelnum{&port}=&channelnum {&port } free i = %frame
Any subsequent frame sent on that port will use the value of &sendchannelnum. When a frame is received, a script can check from which channel this frame came. This is provided by getting the value of the port specific special variable &receivechannelnum that stores the logical channel number that is assigned by openchannel function during opening the channel.
{&port}wait %frame sprint Frame is received on channel ,string(&receivechannelnum{&port})
14-2
Ixia
If a channel is no longer needed the channel can be closed using closechannel function:
&ok = closechannel(&port ; &channelnum)
14.3
Example
Following is an example of a loopback script running on a board that sends frames on one port and receives them on the other port. Note that this example use 10 channels on each link.
sprint Script starts.... define CHANNEL_NUMBERS = 11 define MSG_NUMBERS = 100 define PKT_SIZE = 100 &link1=0 &link2=1 &port1 = 1 &port2 = 2 sprint Opening channels ... /* Open all channels on link 0 and 1 */ for (&i= 0 ; &i< CHANNEL_NUMBERS; &i = &i + 1) &xmit_chn[&i] = openchannel(&i+1;&port1;1;&link1;&i+1)\ if (&dcpl_errno) sprint Error happened during openchannel function \ for channel id ,string(&i+1), on port ,string(&port1) sprint Please see dcpl_errno.dh for error code ,string(&dcpl_errno) endif &rcv_chn[&i] = openchannel(&i+1;&port2;1;&link2;&i+1) if (&dcpl_errno) sprint Error happened during openchannel function \ for channel id ,string(&i+1), on port ,string(&port2) sprint Please see dcpl_errno.dh for error code ,string(&dcpl_errno) endif sprint Channel ,string(&xmit_chn[&i]), and channel \ ,string(&rcv_chn[&i]), is opened on port 1 and 2, respectively. endfor %send_frame=strrepeat($11; PKT_SIZE) sprint Sending messages ... /* Send frames on all channels */ for (&y =0; &y < MSG_NUMBERS; &y = &y +1) for (&i= 0 ; &i< CHANNEL_NUMBERS; &i = &i + 1) &sendchannelnum{&port1}= &xmit_chn[&i] {&port1} free i=%send_frame wait %frame switch %frame case KEYBOARD: ... endcase other: if (not same(%frame; %send_frame)) sprint Test Failed! exit endif sprint Frame is received on channel \ ,string(&receivechannelnum{&port2}) endswitch endfor endfor /* Close all channels on link 0 and 1 */
14-3
Ixia
for (&i= 0 ; &i< CHANNEL_NUMBERS; &i = &i + 1) &xmit_chn_closed[&i] = closechannel(&port1;&xmit_chn[&i]) if (not &xmit_chn_closed[&i]) sprint Error in closing channel ,string(&xmit_chn[&i]) sprint Test Failed! exit endif &rcv_chn_closed[&i] = closechannel(&port2;&rcv_chn[&i]) if (not &rcv_chn_closed[&i]) sprint Error in closing channel ,string(&rcv_chn[&i]) sprint Test Failed! exit endif endfor sprint All channels are closed!
14.4
Adapting Legacy Applications to Dynamic TDM

Some applications on the IxCatapult system do not natively operate on Dynamic TDM channels. To adapt these applications, a simple multiplexer script can be used. The basic premise is to route all egress traffic coming from the upper layer port to a specific dynamically allocated channel on the multiplexer's board port, and vice versa for ingress traffic from the line. The multiplexer is configured by specifying the link and timeslot for each upper layer port in the mux context definition dialog in the Launcher diagram. The following example Launcher diagram and multiplexer script adapts the ISDN Layer 2 state machine to run on a Dynamic TDM channel (timeslot 1, link 2). Figure 14-1. Launcher for Multiplexer Script
14-4
Ixia
14.4.1 Example Multiplexer Script

mux.d, compiled with ddc -misdn_l2 -V1 -p64 -d mux.d: /* * multiplexer script * * {1} is the boardport on a dynamic TDM JET board * {2} and higher are to upper layers * * * &ts[] and &link[] are arrays indicating the timeslot and link for * a given multiplexed thread. The thread is determined by the * upper layer port number - 1. */ define define define define define MAX_TS = 31 MAX_LINK = 4 DOWN_PORT = 1 TYPE_64K = 1 TYPE_56K = 2 /* numbered 0 to 31 */ /* numbered 1 to 4 */
array &ts[MAX_TS+1] array &link[MAX_LINK] &board_port = for (&i = 1 ; &ts[&i] = &link[&i] endfor -1 &i < &numports; &i = &i + 1) -1 = -1
sprint '==== starting TDM multiplexor ====' /* Read the timeslot and link config data from the lch file */ while (&init_complete = 0) wait %frame for 500 switch %frame case KEYBOARD: parse %frame endcase case TIMEOUT: sprint 'Timed out waiting for configuration data' endcase endswitch endwhile /* initialize the channels */ if &board_port = -1 sprint 'Error: &board_port was not initalized' unload endif for (&i = 1 ; &i < &numports; &i = &i + 1) if (&ts[&i] = -1) or (&link[&i] = -1) sprint '==== Invalid configuration for thread ', string(&i) else &ok = openchannel(&i; DOWN_PORT; TYPE_64K; &link[&i]; &ts[&i]) if (&dcpl_errno) sprint '==== Error: Couldn''t open channel ', \ string(&i), ', link=', string(&link[&i]), ' ts=', \ string(&ts[&i]), '. ERRNO=', string(&dcpl_errno), '. \ See dcpl_errno.dh. ====' endif endif endfor sprint '==== TDM channels initialized ===='
14-5
Ixia
while (1) wait %frame switch %frame case KEYBOARD: parse %frame endcase other: if &portin = 1 /* frame received from board port. * Direct frame to upper port */ &rx = &receivechannelnum{&portin} {&rx+1}free i=%frame else /* frame received from upper port. Direct to board port */ &sendchannelnum{DOWN_PORT} = &portin - 1 {DOWN_PORT}free i=%frame endif endswitch endwhile
14-6
15
Channel Filter
Contents 15.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 15.2 User Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 15.3 User Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 15.4 Filter Mode Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 15.5 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1510
Channel Filter
Ixia
15.1
Introduction
The channel filter is a mechanism available at the download environment on the receiving side to block messages that higher layers are not interested in, to improve performance at the higher layers. A basic filter can be defined by using DCPL special variables %channel_rx_filter_value, %channel_rx_filter_mask and %channel_rx_filter_counter, which are defined on a per-channel basis (for example, for AAL2 a channel is VPI/VCI/link/CID). If the bitwise and of the incoming message and the mask equals the value, then the message matches with the given filter. Since the mask is generally shorter than the incoming message, only the first part of the incoming message is used. In some circumstances, instead of blocking all the messages that match with the given filter, we might prefer to let one matching message go through once in a while. The special variable %channel_rx_filter_counter has been introduced for this purpose. If %channel_rx_filter_counter is set to N, then every (N+1)th matching message will be passed to the upper layer. The framelength filtering is applied to further block messages based on length of the frame. Depending on how the length of the received frame compares with the filter framelength set by user, the filter classifies the message in one of the two length categories. The framelength filtering is used in conjunction with the filter counter to block or let pass some matching messages in each of the two length categories. If a filter match is found, the filter looks into the length of the frame and compares it with the DCPL special variable %channel_rx_filter_framelen. If the length is less than %channel_rx_filter_framelen, it is categorized as a type 1 frame or else a type 2 frame. Then for each type, the filter sends up every (N+1)th frame and blocks all other frames. The total number of received frames, blocked and not-blocked, for each length type can be read from the user script.
15-2
Ixia
Channel Filter
15.2
15.2.1
User Interaction
DCPL Special Variables Each special variable consists of two parts: the AAL2 cell header with CID and the value of the special variable. The AAL2 cell header is set up using the MAKE_CELL_HEADER_W_CID macro defined in mvpivci.dh (see Appendix A, mvpivci.dh File). See the examples below for details on how to set up the special variables. %channel_rx_filter_value{&port}: Sets the filter value. To define a filter, filter value has to be defined before filter mask, otherwise an error message will be displayed. %channel_rx_filter_mask{&port}: Sets the filter mask. The length of filter mask and the length of filter value have to be same, otherwise an error message will be displayed. The maximum length of filter mask itself (not including the cell header) is 32 bytes. %channel_rx_filter_counter{&port}: Sets the filter counter. The value of counter is set by a hexadecimal string. For example, $2100 means set counter to 8488 in decimal. Value of NULL means all the incoming messages matching with the filter will be blocked. Value of N means blocking up to the Nth messages that match the given filter, and let the (N+1)th matching message pass through to the upper layer, then the counter will restart from zero again. %channel_rx_filter_framelen{&port}: Sets the filter frame length. The value of framelen is also set by a hexadecimal string as described above. It categorizes the message as type 1 or 2 depending on whether the received frame length is less than this special variable or not. Then it sends up every (N+1)th frame in both type 1 and 2, where N is the filter counter. %rx_filter_channel{&port}: Sets the channel VPI, VCI, link number and CID for retrieving the total length counters. This is used in association with &rx_filter_lesslen_ctr{&port} and &rx_filter_morelen_ctr{&port}. &rx_filter_lesslen_ctr{&port}: Reads the total numbers of received frames with length less than filter framelength i.e total number of matching type 1 frames. &rx_filter_morelen_ctr{&port}: Reads the total numbers of received frames with length equal to or more than filter framelength, i.e. total number of matching type 2 frames.
15-3
Channel Filter
Ixia
15.2.2
Setting the Filter To set the filter, the value, mask, counter and framelength of the filter in the state machine context must be set using the following special variables: %channel_rx_filter_value{&port} %channel_rx_filter_mask{&port} %channel_rx_filter_counter{&port} %channel_rx_filter_framelen{&port}
NOTE: The value, mask, counter and framelength are all initialized to zero if not explicitly set. 15.2.3 Removing the Filter A defined filter can be removed by setting the filter mask to NULL. For example:
%channel_rx_filter_mask{&port} = MAKE_CELL_HEADER_W_CID \ (&gfc, &vpi, &vci, &pt, &link_num, &cid),
15.2.4
Reading the Frame Length Counters The user might want to read the frame length counters indicating the total number of frames received which have lengths less or more than the framelength specified in the filter settings. The user needs to set the %rx_filter_channel{&port} special variable first to specify the VPI, VCI, link and CID it wants to read the counters for. Then the user reads the values of &rx_filter_lesslen_ctr{%port} and &rx_filter_morelen_ctr{%port}. These values can be read from any context in the base board. NOTE: Reading the counters does not reset them, but the counter values wraparound to zero once they reach the maximum value of 4294967295.
15-4
Ixia
Channel Filter
15.3
15.3.1
User Scripts
Examples The following script defines a filter for the AAL2 channel specified by &vpi, &vci, &link_num, and &cid:
%channel_rx_filter_value{1}=MAKE_CELL_HEADER_W_CID \ (&gfc, &vpi, &vci, &pt, &link_num, &cid),$010101 %channel_rx_filter_mask{1}=MAKE_CELL_HEADER_W_CID \ (&gfc, &vpi, &vci, &pt, &link_num, &cid),$010101 %channel_rx_filter_counter{1}=MAKE_CELL_HEADER_W_CID \ (&gfc, &vpi, &vci, &pt, &link_num, &cid),$02 %channel_rx_filter_framelen{1}=MAKE_CELL_HEADER_W_CID \ (&gfc, &vpi, &vci, &pt, &link_num, &cid),$08
According to the filter definition above, the filter masks value is $010101. The filter value is $010101. The filter counter is 2. The filter framelength is set to 8. To read the filter counters, the &vpi, &vci, &link_num, and &cid values for that filter must first be set using the following command:
%rx_filter_channel{1}=MAKE_CELL_HEADER_W_CID \ (&gfc, &vpi, &vci, &pt, &link_num, &cid)
Then the counter values are read for this channel:

print &rx_filter_lesslen_ctr{&port} print &rx_filter_morelen_ctr{&port}
A filter is removed by the following command:

%channel_rx_filter_mask{1}=MAKE_CELL_HEADER_W_CID \ (&gfc, &vpi, &vci, &pt, &link_num, &cid),
15.3.2
Example 1 Suppose the sending side sends 3 of the following message:

sssar_unitdata_req uui=26 i=$010101010202030304641201
The incoming message on the receiving side will be $010101010202030304641201 in this case. Since incoming message & mask == value is true here, the message matches the filter. The length of the above message is 12 and the framelen is set to 8. So, it is a type 2 message. So after we send the message 3 times, the type 2 counter will read 3, which exceeds the filter counter set at 2. So the 3rd one will be pass through to the higher layer. The total message counters will read the following: &rx_filter_lesslen_ctr{1} will have the value 0 &rx_filter_morelen_ctr{1} will have the value 3
15-5
Channel Filter
Ixia
15.3.3
Example 2 If the sending side sends the following 3 messages:

{1}sssar_unitdata_req uui=26 i=$01010101 {1}sssar_unitdata_req uui=26 i=$01010101 {1}sssar_unitdata_req uui=26 i=$010101010202030304641202
First of all, we observe that all of the above messages match the filter. The first two messages have length 4 (type 1 message) and the third one has length 12 (type 2 message). So type 1 or 2 message-counts are 2 and 1 respectively and neither exceeds the filter counter 2. All the above messages are blocked. Now if the sender sends another
{1}sssar_unitdata_req uui=26 i=$01010101
then this message is sent up to the higher layer. The total message counters will read the following after the 4 messages are received: &rx_filter_lesslen_ctr{1} will have the value 3 &rx_filter_morelen_ctr{1} will have the value 1 15.3.4 Complete Example Below we give a full example with the complete send and receive side user scripts using the counters and the filters. 15.3.4.1 Sending Side Script The sending side script below initializes 2 channels with vpi 1 and 2, vci 0, link 1 and cid 12. After the receiving side filter initializes, it sends 4 frames of different lengths on each of these channels.
include mvpivci.dh &gfc = 0 &cid_1 = 12 &pt = 0 &vci_1 = 0 &link_num = 1 &cell_rate = 4000 sprint Sending initcell for(&vpi=1;&vpi<3;&vpi=&vpi+1) %initcell{1} = MAKE_INIT_CELL_AAL2 \ (0, &vpi, &vci_1, &pt, &link_num, \ &cell_rate, 1, 0, 0, 0) endfor /* Wait for setting up Channel Filter */ wait %frame for 1000
15-6
Ixia
Channel Filter
&vpi = 1 sprint ***Sending data on vpi , string(&vpi) %sendcellheader{1} = MAKE_CELL_HEADER_W_CID \ (&gfc, &vpi, &vci_1, &pt, &link_num, &cid_1) {1}sssar_unitdata_req uui=26 i=$01010101 {1}sssar_unitdata_req uui=26 i=$01010101 {1}sssar_unitdata_req uui=26 \ i=$010101010202030304641202 {1}sssar_unitdata_req uui=26 \ i=$010101010202030304641203 &vpi = 2 sprint ***Sending data on vpi , string(&vpi) %sendcellheader{1} = MAKE_CELL_HEADER_W_CID \ (&gfc, &vpi, &vci_1, &pt, &link_num, &cid_1) {1}sssar_unitdata_req uui=26 \ i=$010101010202030304641201 {1}sssar_unitdata_req uui=26 \ i=$010101010202030304641201 {1}sssar_unitdata_req uui=26 \ i=$010101010202030304641202 {1}sssar_unitdata_req uui=26 \ i=$010101010202030304641203 exit
15.3.4.2 Receiving Side Script The receiving side script initializes 2 channels with vpi 1 and 2, vci 0, link 0 and cid 12. It sets up the filters (mask is set to $010101, value is set to $010101, counter is set to 2 and framelen is set to 8). Finally it prints the counters on each of the channels.
include mvpivci.dh wait %frame for 100 &gfc = 0 &cid_1 = 12 &pt = 0 &vci_1 = 0 &link_num = 0 &cell_rate = 4000 for(&vpi=1;&vpi<3;&vpi=&vpi+1) %initcell{1} = MAKE_INIT_CELL_AAL2 \ (0, &vpi, &vci_1, &pt, &link_num, \ &cell_rate, 1, 0, 0, 0) endfor sprint Setting filters for(&vpi=1;&vpi<3;&vpi=&vpi+1) %channel_rx_filter_value{1}= \ MAKE_CELL_HEADER_W_CID(&gfc, &vpi, &vci_1, \ &pt, &link_num, &cid_1),$010101 %channel_rx_filter_mask{1}= \ MAKE_CELL_HEADER_W_CID(&gfc, &vpi, &vci_1, \ &pt, &link_num, &cid_1),$010101 %channel_rx_filter_counter{1}= \
15-7
Channel Filter
Ixia
MAKE_CELL_HEADER_W_CID(&gfc, &vpi, &vci_1, \ &pt, &link_num, &cid_1),$02 %channel_rx_filter_framelen{1}= \ MAKE_CELL_HEADER_W_CID(&gfc, &vpi, &vci_1, \ &pt, &link_num, &cid_1),$08 endfor &done = 0 while (not &done) wait %frame for 0 switch %frame {1}case type sssar_unitdata_ind: sprint sssar_unitdata_ind received &done = 1 endcase endswitch endwhile
In this example, the receiver will receive only 1 frame on VPI 2 from the 8 frames that the sender sent. So the receiver counts to 1 to make sure it has received the frames it is expected to receive.
15.4
Filter Mode Settings

Two new special variables have been added to alter the operational mode of the filters and the default action on all unfiltered channels.
15.4.1
DCPL Special Variables Special variable %channel_rx_filter_mode{port} consists of two parts: the AAL2 cell header with CID and the value of the special variable. The AAL2 cell header is set up using the MAKE_CELL_HEADER_W_CID macro defined in mvpivci.dh. The MAKE_CELL_HEADER_W_CID macro has been described in the section for Multiple VPI/VCI. See the examples below for details on how to set up these special variables. %port_rx_unfiltered_mode{&port}: When set to a non zero value will cause all aal2 frames to be dropped. The default is to allow all aal2 frames to pass. Note; This applies to all contexts which are associated with the same board port regardless of (VPI/VCI and CID) combinations. %channel_rx_filter_mode{&port}: When set to a non zero value will cause the selected filter to pass matched frames and drop any unmatched frame. The default is to drop matched frames and pass any unmatched frame.
15-8
Ixia
Channel Filter
15.4.2
Example 3 Uses of drop/pass filters could be, for example:

/* Filter defines to setup blocking filter modes. */ define DATA_PASS_MODE = 0 define DATA_DROP_MODE = 1 define PASS_RX_ALL_FILTER_W_CID(@port, @gfc, @vpi, @vci, @pt, @link, @cid)={ %channel_rx_filter_mode{@port} = MAKE_CELL_HEADER_W_CID(@gfc, @vpi, @vci, @pt, @link, @cid), DATA_PASS_MODE %channel_rx_filter_value{@port} = MAKE_CELL_HEADER_W_CID(@gfc, @vpi, @vci, @pt, @link, @cid), $0000 %channel_rx_filter_mask{@port} = MAKE_CELL_HEADER_W_CID(@gfc, @vpi, @vci, @pt, @link, @cid), $0000 %channel_rx_filter_counter{@port} = MAKE_CELL_HEADER_W_CID(@gfc, @vpi, @vci, @pt, @link, @cid), 0 %channel_rx_filter_framelen{@port} = MAKE_CELL_HEADER_W_CID(@gfc, @vpi, @vci, @pt, @link, @cid), 0 } define DROP_RX_ALL_FILTER_W_CID(@port, @gfc, @vpi, @vci, @pt, @link, @cid)={ %channel_rx_filter_mode{@port} = MAKE_CELL_HEADER_W_CID(@gfc, @vpi, @vci, @pt, @link, @cid), DATA_DROP_MODE %channel_rx_filter_value{@port} = MAKE_CELL_HEADER_W_CID(@gfc, @vpi, @vci, @pt, @link, @cid), $0000 %channel_rx_filter_mask{@port} = MAKE_CELL_HEADER_W_CID(@gfc, @vpi, @vci, @pt, @link, @cid), $0000 %channel_rx_filter_counter{@port} = MAKE_CELL_HEADER_W_CID(@gfc, @vpi, @vci, @pt, @link, @cid), 0 %channel_rx_filter_framelen{@port} = MAKE_CELL_HEADER_W_CID(@gfc, @vpi, @vci, @pt, @link, @cid), 0 } /* Only receive frames from selected (VPI=1/VCI=1 and CID=1). */ %port_rx_unfiltered_mode{&port} = DATA_DROP_MODE PASS_RX_ALL_FILTER_W_CID(&port, &gfc, 1, 1, &pt, &link, 1) /* Only drop frames from selected (VPI=1/VCI=2 and CID=1). */ %port_rx_unfiltered_mode{&port} = DATA_PASS_MODE DROP_RX_ALL_FILTER_W_CID(&port, &gfc, 1, 2, &pt, &link, 1)
15-9
Channel Filter
Ixia
15.5
Restrictions
The filter has the following restrictions: This filter is for AAL2 only. The filter runs only on the OC-3E, mCI(ATM) and mPI(OC3) board. It cannot be run from workstation. It is only for the download environment. The %channel_rx_filter_value{&port}, %channel_rx_filter_mask{&port}, %channel_rx_filter_counter{&port}, %channel_rx_filter_framelen{&port}, %channel_rx_filter_mode{&port}, and %port_rx_unfiltered_mode{&port} are all write-only variables; these values cannot be read. The counters &rx_filter_lesslen_ctr{&port} and &rx_filter_morelen_ctr{&port} are read-only variables, these cannot be set. The maximum number of filters currently supported is 1954. For an extreme case where in one CID is configured over 1699 VPI/VCI only 1699 filters can be setup. The CFP_Initialisation_Request filter flags Zero_bit_filter and AMR_filter should both be set to OFF.
15-10
16
Statistics Package
Contents 16.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 16.2 Tabular Data Terminology . . . . . . . . . . . . . . . . . . . . . . . . 162 16.3 DCPL Script Commands . . . . . . . . . . . . . . . . . . . . . . . . . 162 16.4 DCPL Interactive and Script Commands . . . . . . . . . . . . . . 166 16.5 Run-time Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 16.6 Run-time Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Statistics Package
Ixia
16.1
Introduction
The IxCatapult system provides a statistics package that allows you to generate line graphs from tabular data collected during the monitoring process. You can define and maintain a table of counters that your script periodically updates. The following sections define DCPL commands and describe typical graphs that can be generated at run time. The statistics package only supports the GUI version of the run-time display (that is, not the standard I/O).
16.2
Tabular Data Terminology

Data for the statistics package is organized as a table. Individual columns in the table are defined as fields. Therefore, a field number and column number express the same area. Multiple rows in the table are defined as groups. The table can contain multiple groups, each group containing multiple rows. Each row includes a cell from each of the existing fields. A unique index identifies each data cell in the table. This index is used as a reference by the update command.
16.3
DCPL Script Commands

The following commands control the statistics package from the DCPL script.
16.3.1
add_stat_row The add_stat_row command adds a new row to a defined group. The group parameter identifies the specific group to which the new row is to be added and is the value supplied to the stat_group command. The row parameter defines a unique reference value (number) for the row. The label parameter defines the label appearing as the row name in the run-time display.
add_stat_row group=<exp> row=<exp> label=<string>
16-2
Ixia
Statistics Package
16.3.2
delete_stat_row The delete_stat_row command deletes the specified row from the group. The group parameter identifies the group from which the specified row is to be deleted. The row parameter defines a unique reference value (number) for the row which is the value supplied to the stat_group or add_stat_row commands for that row.
delete_stat_row group=<exp> row=<exp>
16.3.3
stat_field The stat_field command defines a single field (column) entry in the statistics table. The field parameter defines the unique reference value (number). The label parameter defines the label to use as the column heading in the run-time display. The complete syntax is as follows:
stat_field field=<exp> label=<stringl>
16.3.4
stat_group The stat_group command defines a group (collection of rows) in the statistics table. The group parameter defines the unique reference value (number). The label parameter defines the group name appearing in the run-time display. The item parameter defines the set of Row entries comprising this group. The rows can also be added and removed from the group at run time (see Section 16.3.1, add_stat_row, on page 16-2 and Section 16.3.2, delete_stat_row, on page 16-3). Each row entry (item) contains two parameters. The row parameter defines a unique reference value (number). The label parameter defines the label appearing as the row name in the run-time display. The complete syntax is as follows:
stat_group group=<exp> label=<string> \ item=[row=<exp> label=<string>] item=[...]
16.3.5
stat_log The stat_log command is used to set the log filename for StatsView. The filename can either include or omit the .svl extension. The log file is overwritten if it already exists when starting the test. The complete syntax is as follows:
stat_log <filename>
16-3
Statistics Package
Ixia
16.3.6
stat_pref The stat_pref command is used to set the preference filename for StatsView. The filename can be with or without the .prf extension. The preference file can be previously defined and saved as mentioned in Section 16.5.2, Specifying Preferences File, on page 16-7 using StatsView Analysis Tool. See the StatsView User Manual [7] for more details about the StatsView Analysis Tool. The complete syntax is as follows:
stat_pref <filename>
16.3.7
update_stat_field The update_stat_field command is used to update a single element in the statistics table. The group, row and field parameters identify a specific entry using the values supplied to the stat_group and stat_field commands. The data is supplied in either a value or string parameter. The value parameter supplies the new numeric value and the string parameter supplies the new string value for the referenced field. The complete syntax is as follows:
update_stat_field group=<exp> row=<exp> \ field=<exp> [value=<exp> | string=<strexp>]
16.3.8
update_stat_row The update_stat_row command updates a single element in the statistics table. The group, row, and data parameters identify a specific entry using the values supplied to the stat_group and stat_field commands. data is a reserved keyword and cannot be used in user-defined macros. The data set is supplied in the value and/or string parameters. The value parameter supplies the new numeric value, and the string parameter supplies the new string value for the referenced field. The complete syntax is as follows:
update_stat_row group=<exp> row=<exp> \ data=[value=<exp> | string=<strexp> [...]]
16-4
Ixia
Statistics Package
16.3.9
Script Example The following script segment illustrates how the statistics package defines and maintains counters.
/* define tag for stats interval timer */ define IT_STATS = 0 /* initialize statistical counters */ &Attempts[1]{1} = 0 &Attempts[2]{1} = 0 &Attempts[1]{2} = 0 &Success[1]{1} = 0 &Success[2]{1} = 0 &Success[1]{2} = 0 &Failures[1]{1} = 0 &Failures[2]{1} = 0 &Failures[1]{2} = 0 /* define the common fields (columns) */ stat_field field=1 label=Attempts stat_field field=2 label=Success stat_field field=3 label=Failures /* define Node A rows, Link 1 & Link 2*/ stat_group group=1 label=Node_A item=[row=1 label=Link_1] item=[row=2 label=Link_2] /* define Node B row, Link 1 */ stat_group group=2 label=Node_B item=[row=1 label=Link_1] /* display the table */ stats on /* start statistical report counter */ start_itimer tag=IT_STATS period=30 units=sec while (1) wait %frame switch %frame case itimeout: exp switch (&itimeout_tag{1}) case IT_STATS: /* update stats for Node A / Link 1 */ update_stat_row group=1 row=1 \ data=[value=&Attempts[1]{1} \ value=&Success[1]{1} \ value=&Failures[1]{1}] /* update stats for Node A / Link 2 */ update_stat_row group=1 row=2 \ data=[value=&Attempts[2]{1} \ value=&Success[2]{1} \ value=&Failures[2]{1}] /* update stats for Node B / Link 1 */ update_stat_row group=2 row=1 \ data=[value=&Attempts[1]{2} \ value=&Success[1]{2} \ value=&Failures[1]{2}] endcase endswitch endcase endswitch endwhile \
16-5
Statistics Package
Ixia
16.4
16.4.1
DCPL Interactive and Script Commands

stats_on The stats_on command displays the statistics table in the current window manager.
16.4.2
stats_off The stats_off command removes the statistics table from the current window manager. The system continues logging statistical information, and any graphs the system defines continue to display.
16.4.3
Run-time Display Control Selecting the View>Statistics option displays the statistics table in the current window manager (see the following sample table). Once the table is displayed, the entry is disabled.
You can modify the format and presentation of the statistics data table by selecting the Table menu button. This button displays a subset of the Fields (columns) and allows you to modify the size, style, and font type. View Group option, allows to limit which groups contents are to be viewed in the table. By default, all groups are shown.
16-6
Ixia
Statistics Package
16.5
Run-time Logging
At run time, you can specify a log file to write the statistic information. Two log formats are supported: SVL (.svl extension) and tabular (.txt extension). The desired format is set via the Preference>Set Log File Format option. The SVL-format log file consists of DCPL commands, and the tabular-format log file consists of actual statistics data in text format. The SVL-format log file can be used for post-run processing. The StatsView analysis tool is provided for analyzing the log file in the offline environment. For additional information on using the StatsView analysis tool, see the StatsView User Manual [7]. Alternatively, you can use a spreadsheet for analyzing the statistics data. However, the log file may need to be processed via a filter script to prepare the data for spreadsheet analysis.
16.5.1
Specifying Log File You can specify a new log file by selecting the File>New Log option. Once specified, the new log file is immediately opened and logging starts until you select File>Close Log or exit the StatsView application.
16.5.2
Specifying Preferences File You can save legend and text definitions into a preferences file. The Preference>New Preference option resets the definitions to the defaults. The Preference>Open Preference option reads in previously saved definitions. The Preference>Save Preference option saves definitions into an opened preferences file.
16-7
Statistics Package
Ixia
16.6
Run-time Graphs
At run time, line graphs can be generated based on the data stored and updated in the statistics table.
16.6.1
Graph Terminology A graph represents a set of elements in the table. The statistics package may generate multiple graphs illustrating various data sets. A legend represents data in the form of a line on the graph. Multiple entries in the table may use the same legend producing graphically combined values. An overlay is the connection between statistical data and a graph. The overlay defines what data is presented on the graph and what legends are required to explain the graph.
16.6.2
Defining Legends The statistics package has six pre-defined legends: solid green, solid blue, solid red, solid pink, dash green, and dash pink. The attributes of these legends (color, style, size and shape) can be modified using the Graph>Legend option. You can also create new legends and remove existing legends. The Graph>Legend>Remove All option can be used to remove all legends from the table.
16.6.3
Defining Graphs The statistics package has a pre-defined default graph. You can create additional graphs by selecting the Graph>Add New option. Each graph (including the default) is managed using an independent overlay of the statistics table. To select a predefined legend, left-click in the table. After selecting a legend, data entries within the table are highlighted according to the color defined by the legend.
16-8
Ixia
Statistics Package
Example:
16.6.4
Displaying Graphs After assigning legends to the data entries in the statistics table, you can display one or more graphs by selecting the Graph>Display option. A shortcut display graph button is provided next to the Graph Overlay button. When selected, it will graph the currently selected overlay. The presentation of the graph can be changed using the Customize button. This button also provides access to the print facility. Example:
16-9
Statistics Package
Ixia
16-10
A
mvpivci.dh File
Contents A.1 mvpivci.dh File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2
mvpivci.dh File
Ixia
A.1
mvpivci.dh File
You can invoke the following macros to build the special variables by passing integers as parameters. These macros are defined and documented in the file mvpivci.dh, located in $DCT2000PATH. This appendix describes the mvpivci.dh file.
* File: mvpivci.dh * * Description: * * * * * NOTE: It is recommended that the PT_CLP field in the macros below * is always set to 0 for all ports that are not using AAL0 * directly (e.g., AAL5 or AAL2). The first 3 bits of this field This file contains definition of macros that can be used in multiple VPI/VCI mode and for use with multiple CIDs.
* is the PTI (Payload Type Identifier) and the last bit is * the CLP (Cell Loss Priority). * * %initcell{} macros: * ------------------* * IMPORTANT: These macros must be used on a port that is either * a board port or associated with a board port in Launcher. * * MAKE_INIT_CELL: macro to build %initcell special variable (UNI format). * This macro has the same effect as MAKE_INIT_CELL_CBR.
* Input: GFC, VPI, VCI, PT_CLP, LN (Link Number) and peakCellRate (cells/sec). * * MAKE_INIT_CELL_CBR: macro to build %initcell special variable (UNI format) * for Constant Bit Rate applications.
* Input: GFC, VPI, VCI, PT_CLP, LN (Link Number) and peakCellRate (cells/sec). * * MAKE_INIT_CELL_UBR: macro to build %initcell special variable (UNI format). * for Unspecified Bit Rate applications.
A-2
Ixia
mvpivci.dh File
* * *
Input: GFC, VPI, VCI, PT_CLP, LN (Link Number) and (suggested) peakCellRate (cells/sec).
* MAKE_INIT_CELL_AAL1: macro to build %initcell special variable (UNI format) * * * * * * * * * MAKE_INIT_CELL_AAL2: macro to build %initcell special variable (UNI format) * * * * * * * * * MAKE_INIT_CELL_AAL2_CID: macro to build %initcell special variable(UNI format) * * * * * * * * * * MAKE_INIT_CELL_AND_CID: macro to build %initcell special variable(UNI format) * * for AAL2 cid connections. Input: GFC, VPI, VCI, PT_CLP, LN (Link Number), for AAL2 cid connections. Input: GFC, VPI, VCI, PT_CLP, LN (Link Number), peakCellRate (cells/sec), maxsdu_deliverylen (max sdu delivery len), PFM (Partial Fill Mode indicator), PFT (Partial Fill Threshhold.When PFM=0,PFT should be 47), timercu (timer cu value) cid for AAL2 connections. Input: GFC, VPI, VCI, PT_CLP, LN (Link Number), peakCellRate (cells/sec), maxsdu_deliverylen (max sdu delivery len), PFM (Partial Fill Mode indicator), PFT (Partial Fill Threshhold.When PFM=0,PFT should be 47), timercu (timer cu value) for AAL1 connections. Input: GFC, VPI, VCI, PT_CLP, LN (Link Number), peakCellRate (cells/sec), SF (Structured format indicator), BS (Block size in structured format) PFM (Partial Fill Mode indicator), VOC (Valid Octet Count in partial fill mode)
A-3
mvpivci.dh File
Ixia
* * *
peakCellRate (cells/sec), cid
* MAKE_INIT_CELL_INIT_CID:macro builds %initcell special variable (UNI format) * * * * MAKE_NNI_INIT_CELL: macro to build %initcell special variable (NNI). * This macro has the same effect as MAKE_INIT_CELL_CBR. for AAL2 cid connections. Input: GFC, VPI, VCI, PT_CLP, LN (Link Number), cid
* Input: VPI, VCI, PT_CLP, LN (Link Number) and peakCellRate (cells/sec). * * MAKE_NNI_INIT_CELL_CBR: macro to build %initcell special variable (NNI) * for Constant Bit Rate applications.
* Input: VPI, VCI, PT_CLP, LN (Link Number) and peakCellRate (cells/sec). * * MAKE_NNI_INIT_CELL_UBR: macro to build %initcell special variable (NNI). * * * * * MAKE_NNI_INIT_CELL_AAL1: macro to build %initcell special variable (NNI format) * * * * * * * * * MAKE_NNI_INIT_CELL_AAL2: macro to build %initcell special variable (NNI format) * * * for AAL2 connections. Input: VPI, VCI, PT_CLP, LN (Link Number), peakCellRate (cells/sec), for AAL1 connections. Input: VPI, VCI, PT_CLP, LN (Link Number), peakCellRate (cells/sec), SF (Structured format indicator), BS (Block size in structured format) PFM (Partial Fill Mode indicator), VOC (Valid Octet Count in partial fill mode) for Unspecified Bit Rate applications. Input: VPI, VCI, PT_CLP, LN (Link Number) and (suggested) peakCellRate (cells/sec).
A-4
Ixia
mvpivci.dh File
* * * * *
maxsdu_deliverylen (max sdu delivery len), PFM (Partial Fill Mode indicator), PFT (Partial Fill Threshhold.When PFM=0,PFT should be 47), timercu (timer cu value)
* MAKE_NNI_INIT_CELL_AAL2_CID: macro to build %initcell special variable (NNI format) * * * * * * * * * * MAKE_NNI_INIT_CELL_AND_CID: macro to build %initcell special variable (NNI format) * initialising cids on * on * * * * * * MAKE_NNI_INIT_CELL_INIT_CID: macro to build %initcell special variable (NNI format) * * * * * * * MAKE_INIT_CELL_VBR: macro to build %initcell special variable * * * Input GFC, VPI, VCI, PT_CLP, LN (Link Number), for VBR ATM channels. for AAL2 cid connections. Input: VPI, VCI, PT_CLP, LN (Link Number), cid for AAL2 cid connections. Usedf for existing channelsUsedf for initialising cids existing channels Input: VPI, VCI, PT_CLP, LN (Link Number), peakCellRate (cells/sec), cid for AAL2 cid connections. Input: VPI, VCI, PT_CLP, LN (Link Number), peakCellRate (cells/sec), maxsdu_deliverylen (max sdu delivery len), PFM (Partial Fill Mode indicator), PFT (Partial Fill Threshhold.When PFM=0,PFT should be 47), timercu (timer cu value) cid
A-5
mvpivci.dh File
Ixia
* * * *
PCR (Peak Cell Rate), SCR (Sustain Cell Rate), MBS (Max Burst Size)
* MAKE_INIT_CELL_AAL1_VBR: macro to build %initcell special variable * * * * * * * * * * * * MAKE_INIT_CELL_AAL2_VBR: macro to build %initcell special variable * * * * * * * * * * * * MAKE_INIT_CELL_AAL2_CID_VBR: macro to build %initcell special variable * * * * * * * * Input GFC, VPI, VCI, PT_CLP, LN (Link Number), PCR (Peak Cell Rate), SCR (Sustain Cell Rate), maxsdu_deliverylen (max sdu delivery len), PFM (Partial Fill Mode indicator), PFT (Partial Fill Threshhold.When PFM=0,PFT should be 47), for VBR ATM channels with AAL2 specifing CID. Input GFC, VPI, VCI, PT_CLP, LN (Link Number), PCR (Peak Cell Rate), SCR (Sustain Cell Rate), maxsdu_deliverylen (max sdu delivery len), PFM (Partial Fill Mode indicator), PFT (Partial Fill Threshhold.When PFM=0,PFT should be 47), timercu (timer cu value) for VBR ATM channels with AAL2. Input GFC, VPI, VCI, PT_CLP, LN (Link Number), PCR (Peak Cell Rate), SCR (Sustain Cell Rate), MBS (Max Burst Size) SF (Structured format indicator), BS (Block size in structured format) PFM (Partial Fill Mode indicator), VOC (Valid Octet Count in partial fill mode) for VBR ATM channels with AAL1.
A-6
Ixia
mvpivci.dh File
* * *
timercu (timer cu value) cid
* MAKE_NNI_INIT_CELL_VBR: macro to build %initcell special variable * * * * * * * * MAKE_NNI_INIT_CELL_AAL1_VBR: macro to build %initcell special variable * * * * * * * * * * * * MAKE_NNI_INIT_CELL_AAL2_VBR: macro to build %initcell special variable * * * * * * * * * * * * MAKE_NNI_INIT_CELL_AAL2_CID_VBR: macro to build %initcell special variable Input VPI, VCI, PT_CLP, LN (Link Number), PCR (Peak Cell Rate), SCR (Sustain Cell Rate), maxsdu_deliverylen (max sdu delivery len), PFM (Partial Fill Mode indicator), PFT (Partial Fill Threshhold.When PFM=0,PFT should be 47), timercu (timer cu value) for VBR ATM channels with AAL2. Input VPI, VCI, PT_CLP, LN (Link Number), PCR (Peak Cell Rate), SCR (Sustain Cell Rate), MBS (Max Burst Size) SF (Structured format indicator), BS (Block size in structured format) PFM (Partial Fill Mode indicator), VOC (Valid Octet Count in partial fill mode) for VBR ATM channels with AAL1. Input VPI, VCI, PT_CLP, LN (Link Number), PCR (Peak Cell Rate), SCR (Sustain Cell Rate), MBS (Max Burst Size) for VBR ATM channels.
A-7
mvpivci.dh File
Ixia
* * * * * * * * * * *
for VBR ATM channels with AAL2 specifing CID.
Input VPI, VCI, PT_CLP, LN (Link Number), PCR (Peak Cell Rate), SCR (Sustain Cell Rate), maxsdu_deliverylen (max sdu delivery len), PFM (Partial Fill Mode indicator), PFT (Partial Fill Threshhold.When PFM=0,PFT should be 47), timercu (timer cu value) cid
* MAKE_INIT_CELL_AAL0_OAM: macro to build %initcell special variable * * * * * * * * * * MAKE_NNI_INIT_CELL_AAL0_OAM: macro to build %initcell special variable * * * * * * * * * * * * %invalidcell{} macros: * -------------------------------------------------* * MAKE_INVALID_VP: macro to build %invalidcell special variable Input VPI, VCI (3 = Segment OAM F4 Flow, 4 = End-to-end OAM F4 Flow), PT (4 = Segment OAM F5 Flow 5 = End-to-end OAM F5 Flow), CLP, LN (Link Number), PCR (Peak Cell Rate), for AAL0 OAM channels. Input GFC, VPI, VCI (3 = Segment OAM F4 Flow, 4 = End-to-end OAM F4 Flow), PT (4 = Segment OAM F5 Flow 5 = End-to-end OAM F5 Flow), CLP, LN (Link Number), PCR (Peak Cell Rate), for AAL0 OAM channels.
A-8
Ixia
mvpivci.dh File
* * *
for invalidating all channels on a VP (UNI formatting). Input: GFC, VPI, LN.
* MAKE_NNI_INVALID_VP: macro to build %invalidcell special variable * * * * * %invalidcell{} and %sendcellheader{} macros: * -------------------------------------------------* * MAKE_CELL_HEADER: macro to build %invalidcell or %sendcellheader * * * * MAKE_NNI_CELL_HEADER: macro to build %invalidcell or %sendcellheader * * * * MAKE_CELL_HEADER_W_CID: macro to build %sendcellheader special variable * * * * MAKE_NNI_CELL_HEADER_W_CID: macro to build %sendcellheader special variable * * * * MAKE_CID: macro to build %sendcellheader special variable * * * * MAKE_CELL_HEADER_OAM: macro to build %invalidcell or %sendcellheader * * * * MAKE_NNI_CELL_HEADER_OAM: macro to build %invalidcell or %sendcellheader special variables (UNI formatting). Input: GFC, VPI, VCI, PT, CLP and LN (Link Number). including AAL2 cid (NNI formatting). Input: VPI, VCI, PT_CLP, LN, CID. including AAL2 cid (NNI formatting). Input: VPI, VCI, PT_CLP, LN, CID. including AAL2 cid (UNI formatting). Input: GFC, VPI, VCI, PT_CLP, LN, CID. special variables (NNI formatting). Input: VPI, VCI, PT_CLP and LN (Link Number). special variables (UNI formatting). Input: GFC, VPI, VCI, PT_CLP and LN (Link Number). for invalidating all channels on a VP (NNI formatting). Input: VPI, LN.
A-9
mvpivci.dh File
Ixia
* * * *
special variables (NNI formatting). Input: VPI, VCI, PT, CLP and LN (Link Number).
* %receivecellheader{} macros: * ---------------------------* * * * * RECEIVED_CELLHEADER_GFC: macro to extract UNI format GFC * * RECEIVED_CELLHEADER_VPI: macro to extract UNI format VPI * * RECEIVED_CELLHEADER_NNI_VPI: macro to extract NNI format VPI * * RECEIVED_CELLHEADER_VCI: macro to extract VCI * * RECEIVED_CELLHEADER_PT: macro to extract PT and CLP * * RECEIVED_CELLHEADER_LN: macro to extract Link Number * * RECEIVED_CELLHEADER_CID: macro to extract the CID from a multiple VPI/VCI * * * RECEIVED_CID: macros to extract the CID from a Single VPI/VCI with CID frame * * RECEIVED_CELLHEADER_OAM_PT: macro to extract PT only from OAM cell. * ************************************************************************* **/ include mvpivci_defs.dh with CID frame These macros extract the respective field from the %receivecellheader special variable on the PORT provided as input. Input: PORT
define MAKE_INIT_CELL(@gfc, @vpi, @vci, @pt_and_clp, @ln, @peakCellRate) = \ bitcat(4; @gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), \
A-10
Ixia
mvpivci.dh File
bitcat(8; @ln; 32; @peakCellRate)
define MAKE_INIT_CELL_CBR(@gfc, @vpi, @vci, @pt_and_clp, @ln, @peakCellRate) = \ bitcat(4; @gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(8; @ln; 32; @peakCellRate; 8; 0)
define MAKE_INIT_CELL_AAL1(@gfc, @vpi, @vci, @pt_and_clp, @ln, @peakCellRate, @sf, @bs, @pfm, @vos) = \ bitcat(4; @gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(8; @ln; 32; @peakCellRate; 8; 0), \ bitcat(8; 1; 1; @sf; 1; @pfm; 6; 0; 16; @bs; 8; @vos)
define MAKE_INIT_CELL_AAL2(@gfc, @vpi, @vci, @pt_and_clp, @ln, @peakCellRate, @maxsdu_deliverylen, @pfm, @pft,@timercu) = \ bitcat(4; @gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(8; @ln; 32; @peakCellRate; 8;0; 8; @maxsdu_deliverylen), \ bitcat(8; INITCELL_V2_AAL_TYPE_AAL2; 7; 0; 1; @pfm; 8;@pft; 16; @timercu)
define MAKE_INIT_CELL_AAL2_CID(@gfc, @vpi, @vci, @pt_and_clp, @ln, @peakCellRate, @maxsdu_deliverylen, @pfm, @pft,@timercu,@cid) = \ bitcat(4; @gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(8; @ln; 32; @peakCellRate; 8;0; 8; @maxsdu_deliverylen), \ bitcat(8; INITCELL_V2_AAL_TYPE_AAL2; 7; 0; 1; @pfm; 8;@pft; 16; @timercu;8;@cid)
define MAKE_INIT_CELL_AND_CID(@gfc,@vpi, @vci, @pt_and_clp, @ln,@rate,@cid) = \ bitcat(4;@gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(8; @ln; 32; @rate; 8;0; 8; 0), \ bitcat(8; INITCELL_V2_AAL_TYPE_AAL2; 8; @cid)
define MAKE_INIT_CELL_INIT_CID(@gfc,@vpi, @vci, @pt_and_clp, @ln,@cid) = \ bitcat(4; @gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(8; @ln; 32; 0; 8;0; 8; 0), \ bitcat(8; INITCELL_V2_AAL_TYPE_AAL2; 8; @cid)
define MAKE_INIT_CELL_UBR(@gfc, @vpi, @vci, @pt_and_clp, @ln, @peakCellRate) = \
A-11
mvpivci.dh File
Ixia
bitcat(4; @gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(8; @ln; 32; @peakCellRate; 8; 1)
define MAKE_NNI_INIT_CELL(@vpi, @vci, @pt_and_clp, @ln, @peakCellRate) = \ bitcat(12; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(8; @ln; 32; @peakCellRate)
define MAKE_NNI_INIT_CELL_CBR(@vpi, @vci, @pt_and_clp, @ln, @peakCellRate) = \ bitcat(12; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(8; @ln; 32; @peakCellRate; 8; 0)
define MAKE_NNI_INIT_CELL_UBR(@vpi, @vci, @pt_and_clp, @ln, @peakCellRate) = \ bitcat(12; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(8; @ln; 32; @peakCellRate; 8; 1)
define MAKE_NNI_INIT_CELL_AAL1(@vpi, @vci, @pt_and_clp, @ln, @peakCellRate, @sf, @bs, @pfm, @vos) = \ bitcat(12; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(8; @ln; 32; @peakCellRate; 8; 0), \ bitcat(8; 1; 1; @sf; 1; @pfm; 6; 0; 16; @bs; 8; @vos)
define MAKE_NNI_INIT_CELL_AAL2(@vpi, @vci, @pt_and_clp, @ln, @peakCellRate, @maxsdu_deliverylen, @pfm, @pft,@timercu) = \ bitcat(12; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(8; @ln; 32; @peakCellRate; 8;0; 8; @maxsdu_deliverylen), \ bitcat(8; INITCELL_V2_AAL_TYPE_AAL2; 1; @pfm; 7; 0; 8;@pft; 16; @timercu)
define MAKE_NNI_INIT_CELL_AAL2_CID(@vpi, @vci, @pt_and_clp, @ln, @peakCellRate, @maxsdu_deliverylen, @pfm, @pft,@timercu,@cid) = \ bitcat(12; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(8; @ln; 32; @peakCellRate; 8;0; 8; @maxsdu_deliverylen), \ bitcat(8; INITCELL_V2_AAL_TYPE_AAL2; 7; 0; 1; @pfm; 8;@pft; 16; @timercu;8;@cid)
define MAKE_NNI_INIT_CELL_AND_CID(@vpi, @vci, @pt_and_clp, @ln,@rate,@cid) = \ bitcat(12; @vpi; 16; @vci; 4; @pt_and_clp), \
A-12
Ixia
mvpivci.dh File
bitcat(8; @ln; 32; @rate; 8;0; 8; 0), \ bitcat(8; INITCELL_V2_AAL_TYPE_AAL2; 8; @cid)
define MAKE_NNI_INIT_CELL_INIT_CID(@vpi, @vci, @pt_and_clp, @ln,@cid) = \ bitcat(12; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(8; @ln; 32; 0; 8;0; 8; 0), \ bitcat(8; INITCELL_V2_AAL_TYPE_AAL2; 8; @cid)
define MAKE_NNI_INIT_CELL_VBR(@vpi, @vci, @pt_and_clp, @ln, @pcr, @scr, @mbs) = \ bitcat(12; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(32; @pcr), \ bitcat(8; INITCELL_VER3_VBR_TYPE_AAL0; 8; INITCELL_VERSION_3; 16; @ln), \ bitcat(32; ZERO_PADDING), \ . . . . . . . . . . . . bitcat(8; INITCELL_VER3_TYPE_AAL0; 24; ZERO_PADDING), \ bitcat(32; ZERO_PADDING), \ bitcat(8; INITCELL_TRAFFIC_TYPE_VBR; 8; ZERO_PADDING; 16; @mbs), \ bitcat(32; @scr)
define MAKE_INIT_CELL_VBR(@gfc, @vpi, @vci, @pt_and_clp, @ln, @pcr, @scr, @mbs) = \ bitcat(4; @gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(32; @pcr), \ bitcat(8; INITCELL_VER3_VBR_TYPE_AAL0; 8; INITCELL_VERSION_3; 16; @ln),\ bitcat(32; ZERO_PADDING), \ . . . . . . . . . . . . bitcat(8; INITCELL_VER3_TYPE_AAL0; 24;0), \ bitcat(32; ZERO_PADDING), \ bitcat(8; INITCELL_TRAFFIC_TYPE_VBR; 8; ZERO_PADDING; 16; @mbs), \ bitcat(32; @scr)
define MAKE_NNI_INIT_CELL_AAL1_VBR(@vpi, @vci, @pt_and_clp, @ln, @pcr, @scr, @mbs, @sf, @bs, @pfm, @vos) = \ bitcat(12; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(32; @pcr), \ bitcat(8; INITCELL_VER3_VBR_TYPE_AAL1; 8; INITCELL_VERSION_3; 16; @ln), \ bitcat(32; ZERO_PADDING), \ . . . . . . . . . . . .
A-13
mvpivci.dh File
Ixia
bitcat(8; INITCELL_VER3_TYPE_AAL1; 1; @sf; 1; @pfm; 6; ZERO_PADDING; 16; @bs),\ . bitcat(2; ZERO_PADDING; 6; @vos; 24; ZERO_PADDING), \ bitcat(8; INITCELL_TRAFFIC_TYPE_VBR; 8; ZERO_PADDING; 16; @mbs), \ bitcat(32; @scr)
define MAKE_INIT_CELL_AAL1_VBR(@gfc, @vpi, @vci, @pt_and_clp, @ln, @pcr, @scr, @mbs, @sf, @bs, @pfm, @vos) = \ bitcat(4; @gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(32; @pcr), \ bitcat(8; INITCELL_VER3_VBR_TYPE_AAL1; 8; INITCELL_VERSION_3; 16; @ln),\ bitcat(32; ZERO_PADDING), \ . . . . . . . . . . . . bitcat(8; INITCELL_VER3_TYPE_AAL1; 1; @sf; 1; @pfm; 6; ZERO_PADDING; 16; @bs),\ . bitcat(2; ZERO_PADDING; 6; @vos; 24; ZERO_PADDING), \ bitcat(8; INITCELL_TRAFFIC_TYPE_VBR; 8; ZERO_PADDING; 16; @mbs), \ bitcat(32; @scr)
define MAKE_NNI_INIT_CELL_AAL2_VBR(@vpi, @vci, @pt_and_clp, @ln, @pcr, @scr, @mbs, @maxsdu_deliverylen, @pfm, @pft, @timercu) = \ bitcat(12; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(32; @pcr), \ bitcat(8; INITCELL_VER3_VBR_TYPE_AAL2; 8; INITCELL_VERSION_3; 16; @ln), \ bitcat(32; ZERO_PADDING), \ . . . . . . . . . . . . bitcat(8; INITCELL_VER3_TYPE_AAL2; 8; @maxsdu_deliverylen; 1 ; @pfm; 7; ZERO_PADDING; 8; @pft), \ bitcat(16; @timercu; 8; ZERO_PADDING; 8; ZERO_PADDING), \ bitcat(8; INITCELL_TRAFFIC_TYPE_VBR; 8; ZERO_PADDING; 16; @mbs), \ bitcat(32; @scr)
define MAKE_INIT_CELL_AAL2_VBR(@gfc, @vpi, @vci, @pt_and_clp, @ln, @pcr, @scr, @mbs, @maxsdu_deliverylen, @pfm, @pft, @timercu) = \ bitcat(4; @gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(32; @pcr), \ bitcat(8; INITCELL_VER3_VBR_TYPE_AAL2; 8; INITCELL_VERSION_3; 16; @ln),\ bitcat(32; ZERO_PADDING), \ . . . . . . . . . . . .
A-14
Ixia
mvpivci.dh File
bitcat(8; INITCELL_VER3_TYPE_AAL2; 8; @maxsdu_deliverylen; 1 ; @pfm; 7; ZERO_PADDING; 8; @pft), \ bitcat(16; @timercu; 8; ZERO_PADDING; 8; ZERO_PADDING), \ bitcat(8; INITCELL_TRAFFIC_TYPE_VBR; 8; ZERO_PADDING; 16; @mbs), \ bitcat(32; @scr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . define MAKE_NNI_INIT_CELL_AAL2_CID_VBR(@vpi, @vci, @pt_and_clp, @ln, @pcr, @scr, @mbs, @maxsdu_deliverylen, @pfm, @pft, @timercu, @cid) = \ bitcat(12; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(32; @pcr), \ bitcat(8; INITCELL_VER3_VBR_TYPE_AAL2_CID; 8; INITCELL_VERSION_3; 16; @ln), \ bitcat(32; ZERO_PADDING), \ . . . . . . . . . . . . bitcat(8; INITCELL_VER3_TYPE_AAL2; 8; @maxsdu_deliverylen; 1 ; @pfm; 7; ZERO_PADDING; 8; @pft), \ bitcat(16; @timercu; 8; @cid; 8; ZERO_PADDING), \ . bitcat(8; INITCELL_TRAFFIC_TYPE_VBR; 8; ZERO_PADDING; 16; @mbs), \ bitcat(32; @scr)
define MAKE_INIT_CELL_AAL2_CID_VBR(@gfc, @vpi, @vci, @pt_and_clp, @ln, @pcr, @scr, @mbs, @maxsdu_deliverylen, @pfm, @pft, @timercu, @cid) = \ bitcat(4; @gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), \ bitcat(32; @pcr), \ bitcat(8; INITCELL_VER3_VBR_TYPE_AAL2_CID; 8; INITCELL_VERSION_3; 16; @ln),\ bitcat(32; ZERO_PADDING), \ . . . . . . . . . . . . bitcat(8; INITCELL_VER3_TYPE_AAL2; 8; @maxsdu_deliverylen; 1 ; @pfm; 7; ZERO_PADDING; 8; @pft), \ bitcat(16; @timercu; 8; @cid; 8; ZERO_PADDING), \ bitcat(8; INITCELL_TRAFFIC_TYPE_VBR; 8; ZERO_PADDING; 16; @mbs), \ bitcat(32; @scr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . define MAKE_INIT_CELL_AAL0_OAM(@gfc, @vpi, @vci, @pt, @clp, @ln, @pcr) = \ bitcat(4; @gfc; 8; @vpi; 16; @vci; 3; @pt; 1; @clp), \ bitcat(32; @pcr), \ bitcat(8; ZERO_PADDING; 8; INITCELL_VERSION_3; 16; @ln),\ bitcat(32; ZERO_PADDING), \ . . . . . . . . . . . . bitcat(8; INITCELL_VER3_TYPE_AAL0), bitcat(24; ZERO_PADDING), \ . . . . . . . . . . . . . . bitcat(32; ZERO_PADDING), \ bitcat(8; INITCELL_TRAFFIC_TYPE_OAM; 24; ZERO_PADDING), \
A-15
mvpivci.dh File
Ixia
bitcat(32; ZERO_PADDING)
define MAKE_NNI_INIT_CELL_AAL0_OAM(@vpi, @vci, @pt, @clp, @ln, @pcr) = \ bitcat(12; @vpi; 16; @vci; 3; @pt; 1; @clp), \ bitcat(32; @pcr), \ bitcat(8; ZERO_PADDING; 8; INITCELL_VERSION_3; 16; @ln),\ bitcat(32; ZERO_PADDING), \ . . . . . . . . . . . . bitcat(8; INITCELL_VER3_TYPE_AAL0), bitcat(24; ZERO_PADDING), \ . . . . . . . . . . . . . . bitcat(32; ZERO_PADDING), \ bitcat(8; INITCELL_TRAFFIC_TYPE_OAM; 24; ZERO_PADDING), \ bitcat(32; ZERO_PADDING)
/* AAL5, CBR the rest of the parameters are all default values */ define MAKE_NNI_INIT_CELL_AAL5_CBR(@vpi, @vci, @pt, @clp, @ln, @pcr) = \ bitcat(12; @vpi; 16; @vci; 3; @pt; 1; @clp), \ bitcat(32; @pcr), \ bitcat(8; ZERO_PADDING; 8; INITCELL_VERSION_3; 16; @ln),\ bitcat(32; ZERO_PADDING), \ . . . . . . . . . . . . bitcat(8; INITCELL_VER3_TYPE_AAL5), bitcat(24; ZERO_PADDING), \ . . . . . . . . . . . . . . bitcat(32; ZERO_PADDING), \ bitcat(8; INITCELL_TRAFFIC_TYPE_CBR; 24; ZERO_PADDING), \ bitcat(32; ZERO_PADDING)
/* * AAL5, CBR and setup the TBD and RBD values * * Caution: This macro alters the behaviour of the 8260 code. * We are changing the receive buffer descriptor and * transmit buffer descriptors. One should use this * macro only if they are sure of the outcome. */ define MAKE_NNI_INIT_CELL_AAL5_CBR_BD(@vpi, @vci, @pt, @clp, @ln, @pcr, @rbd_size, @tbd_size) = \ bitcat(12; @vpi; 16; @vci; 3; @pt; 1; @clp), \ bitcat(32; @pcr), \ bitcat(8; ZERO_PADDING; 8; INITCELL_VERSION_3; 16; @ln),\ bitcat(32; ZERO_PADDING), \ . . . . . . . . . . . .
A-16
Ixia
mvpivci.dh File
bitcat(8; INITCELL_VER3_TYPE_AAL5), bitcat(24; ZERO_PADDING), \ . . . . . . . . . . . . . . bitcat(32; ZERO_PADDING), \ bitcat(8; INITCELL_TRAFFIC_TYPE_CBR; 8; ZERO_PADDING), \ bitcat(8; INITCELL_VER3_TYPE_RBD), bitcat(8; BDPARM_LEN), bitcat((BDPARM_LEN*8); @rbd_size) \ bitcat(8; INITCELL_VER3_TYPE_TBD), bitcat(8; BDPARM_LEN), bitcat((BDPARM_LEN*8); @tbd_size)
/* AAL5, UBR Plus the rest of the parameters are all default values */ define MAKE_NNI_INIT_CELL_AAL5_UBRP(@vpi, @vci, @pt, @clp, @ln, @pcr) = \ bitcat(12; @vpi; 16; @vci; 3; @pt; 1; @clp), \ bitcat(32; @pcr), \ bitcat(8; ZERO_PADDING; 8; INITCELL_VERSION_3; 16; @ln),\ bitcat(32; ZERO_PADDING), \ . . . . . . . . . . . . bitcat(8; INITCELL_VER3_TYPE_AAL5), bitcat(24; ZERO_PADDING), \ . . . . . . . . . . . . . . bitcat(32; ZERO_PADDING), \ bitcat(8; INITCELL_TRAFFIC_TYPE_UBRP; 8; ZERO_PADDING), \ bitcat(8; INITCELL_VER3_TYPE_MCR), bitcat(8; MCRPARM_LEN), bitcat(32; @mcr)\ bitcat(8; INITCELL_VER3_TYPE_MCRF), bitcat(8; MCRFPARM_LEN), bitcat(32; @mcrf)\ bitcat(8; INITCELL_VER3_TYPE_MDA), bitcat(8; MDAPARM_LEN), bitcat(32; @mda)\
/* * AAL5, UBR Plus and setup the RBD and TBD. If the RBD and TBD are setup * to 0. The RBD and TBD sizes will be assigned automatically * * Caution: This macro alters the behaviour of the 8260 code. * We are changing the receive buffer descriptor and * transmit buffer descriptors. One should use this * macro only if they are sure of the outcome. */ define MAKE_NNI_INIT_CELL_AAL5_UBRP_BD(@vpi, @vci, @pt, @clp, @ln, @pcr, @rbd_size, @tbd_size) = \ bitcat(12; @vpi; 16; @vci; 3; @pt; 1; @clp), \ bitcat(32; @pcr), \ bitcat(8; ZERO_PADDING; 8; INITCELL_VERSION_3; 16; @ln),\ bitcat(32; ZERO_PADDING), \ . . . . . . . . . . . .
A-17
mvpivci.dh File
Ixia
bitcat(8; INITCELL_VER3_TYPE_AAL5), bitcat(24; ZERO_PADDING), \ . . . . . . . . . . . . . . bitcat(32; ZERO_PADDING), \ bitcat(8; INITCELL_TRAFFIC_TYPE_CBR; 24; ZERO_PADDING), \ bitcat(8; INITCELL_VER3_TYPE_RBD), bitcat(8; BDPARM_LEN), bitcat((BDPARM_LEN*8); @rbd_size) \ bitcat(8; INITCELL_VER3_TYPE_TBD), bitcat(8; BDPARM_LEN), bitcat((BDPARM_LEN*8); @tbd_size)\ bitcat(8; INITCELL_VER3_TYPE_MCR), bitcat(8; MCRPARM_LEN), bitcat(32; @mcr)\ bitcat(8; INITCELL_VER3_TYPE_MCRF), bitcat(8; MCRFPARM_LEN), bitcat(32; @mcrf)\ bitcat(8; INITCELL_VER3_TYPE_MDA), bitcat(8; MDAPARM_LEN), bitcat(32; @mda)\
/************************************************************************ ***/
define MAKE_INVALID_VP(@gfc, @vpi, @ln) = \ bitcat(4; 0; 4; @gfc; 8; @vpi; 8; @ln)
define MAKE_NNI_INVALID_VP(@vpi, @ln) = \ bitcat(4; 0; 12; @vpi; 8; @ln)
define MAKE_INIT_VP(@gfc, @vpi, @ln) = \ bitcat(4; 0; 4; @gfc; 8; @vpi; 8; @ln)
define MAKE_NNI_INIT_VP(@vpi, @ln) = \ bitcat(4; 0; 12; @vpi; 8; @ln)
/************************************************************************ ***/
define MAKE_CELL_HEADER(@gfc, @vpi, @vci, @pt_and_clp, @ln) = \ set_app_spec_type(bitcat(4; @gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), bitcat(8; @ln); 2)
define MAKE_NNI_CELL_HEADER(@vpi, @vci, @pt_and_clp, @ln) = \ set_app_spec_type(bitcat(12; @vpi; 16; @vci; 4; @pt_and_clp), bitcat(8; @ln); 1)
A-18
Ixia
mvpivci.dh File
define MAKE_CELL_HEADER_W_CID(@gfc, @vpi, @vci, @pt_and_clp, @ln, @cid) = \ set_app_spec_type(bitcat(4; @gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), bitcat(8; @ln; 8; @cid); 4)
define MAKE_NNI_CELL_HEADER_W_CID(@vpi, @vci, @pt_and_clp, @ln, @cid) = \ set_app_spec_type(bitcat(12; @vpi; 16; @vci; 4; @pt_and_clp), bitcat(8; @ln; 8; @cid); 3)
define MAKE_CID(@cid) = \ bitcat(8; @cid)
define MAKE_CELL_HEADER_OAM(@gfc, @vpi, @vci, @pt, @clp, @ln) = \ set_app_spec_type(bitcat(4; @gfc; 8; @vpi; 16; @vci; 3; @pt; 1; @clp), bitcat(8; @ln); 2)
define MAKE_NNI_CELL_HEADER_OAM(@vpi, @vci, @pt, @clp, @ln) = \ set_app_spec_type(bitcat(12; @vpi; 16; @vci; 3; @pt; 1; @clp), bitcat(8; @ln); 1)
define MAKE_CELL_HEADER_XSTREAM(@gfc, @vpi, @vci, @pt_and_clp, @ln) = \ set_app_spec_type(bitcat(4; @gfc; 8; @vpi; 16; @vci; 4; @pt_and_clp), bitcat(8; @ln); 14)
/************************************************************************ ***/
define RECEIVED_CELLHEADER_GFC(@port) = { str2num(substr(%receivecellheader{@port}; 1; 1)) right 4 }
define RECEIVED_CELLHEADER_VPI(@port) = { (str2num(substr(%receivecellheader{@port}; 1;2)) bitand #0FF0) right 4 }
define RECEIVED_CELLHEADER_NNI_VPI(@port) = { (str2num(substr(%receivecellheader{@port}; 1;2)) bitand #FFF0) right 4 }
define RECEIVED_CELLHEADER_VCI(@port) = { (str2num(substr(%receivecellheader{@port}; 2; 3)) bitand #0FFFF0) right 4 }
A-19
mvpivci.dh File
Ixia
define RECEIVED_CELLHEADER_PT(@port) = { str2num(substr(%receivecellheader{@port}; 4; 1)) bitand #0F }
define RECEIVED_CELLHEADER_LN(@port) = { str2num(substr(%receivecellheader{@port}; 5; 1)) }
define RECEIVED_CELLHEADER_CID(@port) = { str2num(substr(%receivecellheader{@port}; 6; 1)) }
define RECEIVED_CID(@port) = { str2num(substr(%receivecellheader{@port}; 1; 1)) }
define RECEIVED_CELLHEADER_OAM_PT(@port) = { (str2num(substr(%receivecellheader{@port}; 4; 1)) bitand #0F) right 1 }
/***************************** End of File *********************************/
A-20
Index
ATM performance, 13-10 ATM special variables, 8-87 Auto Config function, in sysconfig,
2-3
BCHAN special variables, 8-88 BRI S/T special variables, 8-90
C procedures, calling from DCPL, 9-2 CATT_LOG_TO_STDERR environment variable, 3-38 CATT_MAXDECLEN environment variable, 3-36, 4-3 C-callable functions library, 9-6 channel filter removing, 15-4 setting, 15-4 special variables, 15-3 CII special variables, 8-91 comma-separated values format, converting log files to, 4-4 compiler/interpreter statements, 8-31 connections configuring, 3-10 creating, 3-8 creating board port, 3-10 creating interboard, 3-10 creating internal, 3-10 creating UNIX-device port, 3-10 interboard, 3-8 internal, 3-8 restrictions, 3-9 UNIX device, 3-8 context names, 8-2 Context Selection window, 3-32 contexts configuring, 3-3 creating, 3-3 managing the library, 3-19 control characters, 3-33 Coprocessor UNIX library functions, 9-16 CSV format, converting log files to, 4-4 custom display interface, 11-1 custom display, environment variable, 11-2
DCPL basic syntax, 8-2 capitalization, 8-4 channel functions closechannel, 8-54 openchannel, 8-54 comments, 8-3 compiled, 8-2 cryptographic functions aes_cmac, 8-57 aes_decrypt, 8-57 aes_encrypt, 8-59 compute_masterkey, 8-60 decrypt_data, 8-62 des_decrypt, 8-61 des_encrypt, 8-63 digital_hmac, 8-65 digital_sign, 8-66 digital_sign_verify, 8-67 encrypt_data, 8-69 generate_keys, 8-69 md5digest, 8-71 milenage_3g_alg, 8-72 PRF, 8-72 security_3g_eea, 8-73 security_3g_eia, 8-73 security_3g_f8, 8-74 security_3g_f9, 8-74 security_3g_snow, 8-74 sha1, 8-74 difference between FRS and locate, 8-80 editing, 6-4 expressions, 8-7 integer, 8-7 field reference decompose mode, 8-76 exceptions, 8-81 fully qualified, 8-77 single lookup mode, 8-77 syntax, 8-75 wildcard, 8-78 field reference functions decompose, 8-56 exists, 8-56 howmany, 8-56 information elements, 8-80 integer functions, 8-34
Index
Ixia
bit1, 8-34 char, 8-34 decval, 8-35 enum_value, 8-35 hexval, 8-35 len, 8-35 num2bcd, 8-36 pcomp, 8-36 same, 8-36 str2num, 8-36 integer to string conversion, 8-4 integer variables, 8-79 interactive, 8-2 keywords, 8-4, 8-107 line continuation, 8-3 line length, 8-4 literal values, 8-3 macro statements, 8-82 define, 8-82 itdef / ifndef, 8-83 limitations, 8-83 predefined macros, 8-83 undef, 8-83 script commands, 16-2 delete_stat_row, 16-3 stat_field, 16-3 stat_group, 16-3 stat_log, 16-3 stat_pref, 16-4 stats off, 16-6 stats on, 16-6 update_stat_field, 16-4 update_stat_row, 16-4 special variables See special variables statements, 8-9 !, 8-17 add display, 8-18 add log, 8-18 adjust_itimer, 8-31 array, 8-31 assignment, 8-9 badfcs, 8-19 break, 8-10 call, 8-11 case type, 8-14 codec off, 8-19 codec on, 8-19 comment, 8-17 continue, 8-11 default context, 8-32 default main, 8-32
default portspec, 8-32 default protocol, 8-33 default variant, 8-33 encode, 8-9 exit, 8-12 exp switch, 8-11 for, 8-12 forward, 8-19 forward stop, 8-19 free, 8-19 gwrite, 8-20 gwrite append, 8-20 gwrite stop, 8-20 gwrite timestamp, 8-20 if, 8-12 include, 8-21 keyboard, 8-21 load, 8-21 load noglobals, 8-22 locate, 8-9 log, 8-22 parse, 8-10 pattern, 8-10 pause, 8-13 preprocess, 8-23 print, 8-23 prompt, 8-17 read_itimer, 8-30 received, 8-24 remove display, 8-24 remove log, 8-25 return, 8-13 screen clear, 8-25 send, 8-25 sprint, 8-25 start_itimer, 8-29 stop_itimer, 8-30 store, 8-26 switch, 8-13 sysmon, 8-26 timeslot to, 8-26 unload, 8-27 unload noglobals, 8-27 variable, 8-34 variant, 8-33 view, 8-27 wait, 8-15 while, 8-17 write, 8-27 write append, 8-28 write stop, 8-28 write timestamp, 8-28
Index-2
Ixia
Index
wsprint, 8-28 string functions, 8-37 add1len, 8-37 add1lenplus, 8-37 add2len, 8-37 add2lenplus, 8-38 add3len, 8-38 addgenericlen, 8-38 addlen, 8-37 addnlenplus, 8-39 align, 8-39 apn, 8-40 asn1int, 8-40 base64_decode, 8-40 base64_encode, 8-40 bcd, 8-41 bcf, 8-41 bcs, 8-41 bct, 8-41 bitbls, 8-42 bitcat, 8-42 bitis, 8-42 bitls, 8-42 bitn, 8-43 bitreverse, 8-43 bits, 8-43 bitstr, 8-44 bitsubstr, 8-43 catsort, 8-44 chkbs, 8-44 chklen, 8-44 condstrexp, 8-45 crc24, 8-45 crc32, 8-45 decode_base64, 8-45 encode_base64, 8-45 encode_list, 8-45 encoded_list, 8-46 enum_value, 8-47 findstring, 8-47 hex, 8-47 hexstring, 8-48 ipaddr, 8-48 iptext, 8-48 multibcd, 1-7, 8-49 multicrc, 8-49 null, 8-51 pad, 1-7, 8-51 reverse, 8-51 string, 8-51 strrepeat, 8-51 substr, 8-51
touppercase, 8-52 trimleft, 8-52 trimright, 8-52 wspaddlen, 8-52 wspintval, 8-52 variables, 8-5 DCPL and C, sharing data, 9-3 DCPL compiler, 5-2 DCPL Frame Builder (DFB), 6-1 building a template, 6-5 DCPL Frame Builder window, 6-2 DCPL integer variable (DINT), 9-6 DCPL procedures, calling from C, 9-3 DCT2000_TCLAPPFILE environment variable, 11-2 DCT2000DOC_READER environment variable, 1-9, 3-12, 3-20 dctprint, 4-2 DCT-S, 8-108, 8-109 ddc limitations, 5-6 ddriver command, 3-25 interboard port, 3-25 Main window, 3-29, 3-31 reading and writing files, 3-18 running from the Launcher, 3-17 windows, 3-29 design considerations, 8-110 Digital Communications Programming Language (DCPL), 1-2 DINT declaration macros, 9-6 display functions, 9-10 document viewer, changing default, 3-12, 3-20 domain master, 12-3 dynamic TDM channels, 14-1 dynamic TDM special variables, 8-93
E1/T1 special variables, 8-89 environment variables CATT_LOG_TO_STDERR, 3-38 CATT_MAXDECLEN, 3-36, 4-3 DCT2000_TCLAPPFILE, 11-2 DCT2000DOC_READER, 1-9, 3-12, 3-20 for device, port, and board numbers, 3-24 for slot definitions, 2-56, 2-57, 2-58 Ethernet special variables, 8-98
Index-3
Index
Ixia
field reference, 8-75 fields, 16-2 file system functions, 9-10 functions abs, 9-16 atoi, 9-16 atol, 9-16 bcmp, 9-16 bcopy, 9-16 bzero, 9-17 close, 9-17 crypt, 9-17 Dadjust_itimer, 9-12 Dassignspecial, 9-13 Dbcopy, 9-8 Dclose, 9-10 Dcodec_off, 9-15 Dcodec_on, 9-15 Ddecode_msg, 9-10 Ddisplay, 9-10 DesetOutheaderFunc, 9-16 Dexit, 9-15 Dfetchspecial, 9-13 Dfwd, 9-15 Dget, 9-8 Dhexstring, 9-8 Dkeyboard, 9-9 Dlength, 9-8 Dload, 9-9 Dload_noglobals, 9-9 Dopen, 9-10 Dparse, 9-9 Dpause, 9-10 DprocessedPort, 9-15 Dread_itimer, 9-12 Dsassignspecial, 9-14 Dscopy, 9-7 Dsecurity3geea, 9-15 Dsecurity3geia, 9-15 Dsecurity3gf8, 9-16 Dsecurity3gf9, 9-16 Dsend, 9-9 Dsend_badfcs, 9-9 Dset, 9-8 Dsfetchspecial, 9-14 Dsget, 9-8 Dstart_itimer, 9-11 Dstart_periodic_itimer, 9-11 Dstop_itimer, 9-11 Dstrcat, 9-7, 9-8 Dstrcpy, 9-7
Dstrncpy, 9-7 Dunload, 9-9 Dunload_noglobals, 9-10 Dwait, 9-9 encrypt, 9-17 exit, 9-17 fstat, 9-17 getenv, 9-17 index, 9-17 isalnum, 9-17 isalpha, 9-17 isascii, 9-18 iscntrl, 9-17 isdigit, 9-17 isgraph, 9-17 islower, 9-17 isprint, 9-17 ispunct, 9-17 isspace, 9-17 isupper, 9-17 isxdigit, 9-17 lseek, 9-18 memcpy, 9-18 memset, 9-18 open, 9-18 qsort, 9-18 rand, 9-18 read, 9-18 rindex, 9-18 setkey, 9-18 sprintf, 9-18 srand, 9-18 strcasecmp, 9-18 strcat, 9-18 strchr, 9-18 strcmp, 9-18 strcpy, 9-18 strlen, 9-19 strncasecmp, 9-19 strncat, 9-19 strncmp, 9-19 strncpy, 9-19 strstr, 9-19 swab, 9-19 toascii, 9-19 unlink, 9-19 write, 9-19
generic special variables, GFC parameter, 13-3
8-84
Index-4
Ixia
Index
graphs, 16-8 groups, 16-2 GTP special variables,
8-88
Health Monitor utility, hminfo utility, 10-3
10-3
interboard port, creating, 3-10 interval timer functions, 9-11 IP port forwarding, 2-47 restrictions and limitations, 8-105 special variables, 8-103 IxCatapult hardware architecture, 1-2 test solution, 1-2 utilities, 3-19 CATTgen, 3-19 DCPL Frame Builder (DFB), 3-19 LogViewer, 3-19 Routing Table Builder, 3-19 StatsView, 3-19 tail raw log, 3-19 IxCatapult Launcher, 3-2
J1/E1/T1 board dynamic TDM mode, 14-2 dynamic TDM special variables, static TDM mode, 14-2
8-93
KPDF document viewer,
3-12, 3-20
launch command, command-line parameters, 3-21 Launcher running from a makefile, 3-24 legends, 16-8 limitations, 8-110 LTE sectors configuring, 3-16 specifying on ddriver command line, 3-28 timestamp synchronization, 12-9
m500 clock source, 12-2 macros Dint, 9-6 Dintarray, 9-6 Dportint, 9-6 Dportintarray, 9-6 Dportstr, 9-7 Dportstrarray, 9-7 Dstr, 9-7 Dstrarray, 9-7 string manipulation, 9-6 macros file mvpivci.dh, 13-3 manuals, viewing, 3-12, 3-20 Maximum Transmission Unit, 2-35, 2-43 mCI(ATM) board configuration window, 2-39 invalid link references, 13-4 Peak Cell Rate, 13-11 special variables, 8-94 VPI/VCI conflicts, 13-4 VPI/VCI limits, 13-2, 13-7 mCU(5) board configuration window, 2-53 mCU5E board configuration window, 2-53 miscellaneous functions, 9-14 mPI(Ethernet) board configuration window, 2-42 mPI(GigE) special variables, 8-103 mPI(OC3) board configuration window, 2-47 VPI/VCI limits, 13-2 mPI(STM) board configuration window, 2-51 special variables, 8-99 MTU, 2-35, 2-43 multiple VPI/VCI mode, 13-2 special variables, 8-87 mvpivci.dh, A-2
nullif operator,
8-8
OC3 Peak Cell Rate, 13-11 OC-3 special variables, 8-93 OC3 VPI/VCI limits, 13-2, 13-7 OC3E Peak Cell Rate, 13-11 OC-3E special variables, 8-93
Index-5
Index
Ixia
OC3E VPI/VCI limits, operator and, 8-7 bitand, 8-7 bitor, 8-7 bitxor, 8-7 conditional, 8-7 divmod, 8-7 left, 8-7 logical not, 8-8 or, 8-7 right, 8-7 out2csv, 4-4
13-2, 13-7
PDCP special variables, 8-88 PDF document viewer, changing default, 3-12, 3-20 Peak Cell Rate Configuration, 13-10 popup, 3-10 port expressions on statements, 8-2 ports board, 3-8 context to board ports and interboard port association, 3-15 interboard, 3-8 interboard port restrictions mCI(ATM), 3-13 PPCI BRI S/T board configuration window, 2-20 PPCI CII board configuration window, 2-24 PPCI E1/T1 board ATM configuration windows, 2-12 configuration windows, 2-7 PPCI J1/E1/T1 board configuration window, 2-13 PPCI OC3 board configuration window, 2-25 PPCI OC3E board configuration window, 2-25 PPCI Serial board configuration window, 2-19 ppci_startup command, 12-7 ppcimon statement, 3-38 preferences setting, 3-21 protocol manuals, viewing, 3-12, 3-20 protocol-specific special variables, 8-87 PT parameter, 13-3
sector configuration file, 3-16, 3-28 sectors configuring, 3-16 specifying on ddriver command line, 3-28 timestamp synchronization, 12-9 Serial special variables, 8-92 special variable functions, 9-12 special variables %context_name, 8-84 %initcell, 8-87, 13-3, 13-4, 13-7 %invalidcell, 8-87, 13-6 %IP_port_forward, 8-103 %receive_ueid_lcid, 8-88 %receivecellheader, 8-87, 13-6 %send_ueid_lcid, 8-88 %sendcellheader, 8-87, 13-5 %stm_create_channel, 8-99 %stm_remove_channels, 8-99 %vlan_tag_ingress, 8-102 &_codec_reg, 8-94 &_phy0_a_discarded_ingress_high, 8-94 &_phy0_a_discarded_ingress_low, 8-94 &_phy0_a_egress_high_fifo, 8-95 &_phy0_a_egress_low_fifo, 8-96 &_phy0_a_ingress_high_fifo, 8-95 &_phy0_a_ingress_low_fifo, 8-95 &_phy0_b_discarded_ingress_high, 8-94 &_phy0_b_discarded_ingress_low, 8-95 &_phy0_b_egress_high_fifo, 8-96 &_phy0_b_egress_low_fifo, 8-96 &_phy0_b_ingress_high_fifo, 8-95 &_phy0_b_ingress_low_fifo, 8-95 &_phy0_cam_matches, 8-95 &_phy0_cam_matches_a, 8-95 &_phy0_cam_matches_b, 8-95 &_phy0_cam_vpc_matches, 8-95 &_phy0_cam_vpc_matches_a, 8-95 &_phy0_cam_vpc_matches_b, 8-95 &_phy0_cells_discarded_passthru, 8-94 &_phy0_cells_discarded_routing, 8-94 &_phy0_cells_from_framer, 8-96 &_phy0_cells_passed_through, 8-96 &_phy0_cells_to_framer, 8-96 &_phy0_fpga_reg, 8-94
Index-6
Ixia
Index
&_phy0_framer_loopback_egress, 8-96 &_phy0_framer_loopback_ingress, 8-96 &_phy0_framer_reg, 8-97 &_phy0_framer_side_egress, 8-96 &_phy0_framer_side_ingress, 8-97 &_phy0_rx_framer, 8-93 &_phy0_serdes_loopback_egress, 8-97 &_phy0_serdes_loopback_ingress, 8-97 &_phy0_serdes_reg, 8-94, 8-97 &_phy0_tx_framer, 8-93 &_phy1_rx_framer, 8-93 &_phy1_tx_framer, 8-93 &_switch_ingress_loop, 8-97 &_switch_slot_connection, 8-97 &abortct, 8-84 &available_memory, 8-84 &badfcs, 8-84 &baseboard_revision, 8-84 &bri_st_reg, 8-91 &bri_st_rxinfo, 8-90 &bri_st_state, 8-90 &bri_st_txinfo, 8-91 &cii_rate_var, 8-91 &cii_srx_var, 8-91 &cii_stx_var, 8-91 &cpu_idle, 8-84 &ctrl_cts, 8-92 &ctrl_dcd, 8-92 &ctrl_dsr, 8-92 &ctrl_dtr, 8-92 &ctrl_rts, 8-92 &dcpl_errno, 8-84 &e1_frame_alarm, 8-89 &e1_rra, 8-89 &e1_rua1, 8-89 &e1_sa, 8-90 &eth_lnk_det, 8-98 &eth_mi_reg, 8-98 &eth_spd_det, 8-98 &itimeout_index, 8-85 &itimeout_tag, 8-85 &itimer_duration, 8-84 &itimer_index, 8-84 &itimer_remaining, 8-85 &itimer_tag, 8-84 &loc_index, 8-85 &loc_length, 8-85 &mezzanine_revision, 8-85
&mvpivcinumberchannels, 8-87, 13-7 &mvpivcireleasetimer, 8-87, 13-6 &num_tidmnc_digits, 8-88 &numports, 8-85 &oc3_frame_reg, 8-93 &pattern_input_length, 8-88 &patterno, 8-88 &pdcp_no_header_pdu, 8-88 &physint, 8-85 &portin, 8-85 &pri_reg, 8-89 &pri_signaling, 8-89 &protocol, 8-85 &random, 8-86 &receive_queue_length, 8-86 &receivechannelnum, 8-93 &send_queue_length, 8-86 &sendchannelnum, 8-93 &serclk_r, 8-92 &serclk_t, 8-92 &t1_rbl, 8-89 &t1_red, 8-89 &t1_ryel, 8-89 &time, 8-86 &time_us_high, 8-86 &time_us_low, 8-86 &timein, 8-87 &timeout, 8-87 &variant, 8-87 &vlan_tag_egress, 8-102 &wait_queue_length, 8-87 ATM, 8-87 BCHAN, 8-88 BRI S/T, 8-90 channel filter, 15-3 CII, 8-91 dynamic TDM, 8-93 E1/T1, 8-89 Ethernet, 8-98 generic, 8-84 GTP, 8-88 mCI(ATM), 8-94 mPI(GigE), 8-103 mPI(STM), 8-99 OC3, 8-93 OC-3E, 8-93 PDCP, 8-88 protocol-specific, 8-87 Serial, 8-92 unsupported, 8-109 VLAN, 8-102 statistics, 16-1
Index-7
Index
Ixia
StatsView, 16-3, 16-7 string expressions, 8-8 string manipulation functions, 9-7 string manipulation macros, 9-6 sysconfig program, 2-2 action buttons, 2-5 Auto Config function, 2-3 Coprocessor boards on m500 shelf, 2-3 Defaults button, 2-5 Edit menu, 2-5 File menu, 2-4 Host menu, 2-3 main window, 2-2 mCI(ATM) configuration window, 2-39 mCU(5)/mCU5E configuration window, 2-53 mPI(Ethernet) configuration window, 2-42 mPI(OC3) configuration window, 2-47 mPI(STM) configuration window, 2-51 navigation, 2-4 PPCI (BRI S/T) configuration window, 2-20 PPCI (CII) configuration window, 2-24 PPCI (E1/T1) configuration windows, 2-7 PPCI (E1_ATM/T1_ATM) configuration windows, 2-12 PPCI (Ethernet) configuration window, 2-30 PPCI (GigE) configuration window, 2-34 PPCI (J1/E1/T1) configuration window, 2-13 PPCI (OC3E) configuration window, 2-25 PPCI (Serial) configuration window, 2-19 Restart button, 2-4 system configuration file, 2-7 Undo All button, 2-5 UNIX Device configuration window, 2-53 UNIX devices, 2-3 user security, 2-6 sysmon statement, 3-38 sysmon.log, 3-38 System Monitor, 3-37
T1/E1 Peak Cell Rate, 13-10 TCP sockets, 7-4 TCP/UDP sockets, 7-4 timing domain, 12-2 TTY devices configuring, 7-2 TTY protocol, 7-2 tty protocol, 2-3
UNIX commands, 10-1 dcpl, 10-2 dinuse, 10-2 hminfo, 10-3 man, 10-4 r_util, 10-4 slot_info, 10-4 whatsinslot, 10-4
VCI parameter, 13-3 VLAN special variables, 8-102 VPI parameter, 13-3 VPI, VCI, link, and CID decoding, VPI/VCI mode parameter, 13-3
13-9
Index-8

Catapult Ref Man

Uploaded by

Document Information

Original Description:

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

Catapult Ref Man

Uploaded by

Copyright:

Available Formats

IxCatapult Software Reference Manual

IxCatapult Software Reference Manual, Release 20.1

IxCatapult Software Reference Manual, Release 20.1

IxCatapult Software Reference Manual, Release 20.1

IxCatapult Software Reference Manual, Release 20.1

IxCatapult Software Reference Manual, Release 20.1

IxCatapult Software Reference Manual, Release 20.1

IxCatapult Software Reference Manual, Release 20.1

IxCatapult Software Reference Manual, Release 20.1

IxCatapult Software Reference Manual, Release 20.1

IxCatapult Software Reference Manual, Release 20.1

IxCatapult Software Reference Manual, Release 20.1

18119 18132 17379

Added Section 8.5.5, Cryptographic Functions, on page 8-57.

IxCatapult Software Reference Manual, Release 20.1

18171 18677 12896 19147

IxCatapult Software Reference Manual, Release 20.1

Release 13.3 (cont.)

IxCatapult Software Reference Manual, Release 20.1

Release 14.1 (cont.)

19661 20915 21630 21824

IxCatapult Software Reference Manual, Release 20.1

Release 15.2 15.3

ER or PR Number 21993 18206

IxCatapult Software Reference Manual, Release 20.1

IxCatapult Software Reference Manual, Release 20.1

Release 17.0 (cont.)

25062 25307 26038

Added Section 10.3, hminfo, on page 10-3. 26613

IxCatapult Software Reference Manual, Release 20.1

IxCatapult Software Reference Manual, Release 20.1

Configuring an IxCatapult Session

sysconfig Main Window

IxCatapult Software Reference Manual, Release 20.1

Configuring an IxCatapult Session

IxCatapult Software Reference Manual, Release 20.1

Configuring an IxCatapult Session

IxCatapult Software Reference Manual, Release 20.1

Configuring an IxCatapult Session

IxCatapult Software Reference Manual, Release 20.1

Configuring an IxCatapult Session

IxCatapult Software Reference Manual, Release 20.1

Configuring an IxCatapult Session

System Configuration File

PPCI (E1/T1) Configuration Windows

IxCatapult Software Reference Manual, Release 20.1

Configuring an IxCatapult Session

Link 0 RJ-48 Pins Rx 1,2 Tx 4,5

IxCatapult Software Reference Manual, Release 20.1

Configuring an IxCatapult Session

IxCatapult Software Reference Manual, Release 20.1

Configuring an IxCatapult Session

IxCatapult Software Reference Manual, Release 20.1

Configuring an IxCatapult Session

IxCatapult Software Reference Manual, Release 20.1

Configuring an IxCatapult Session

PPCI (E1_ATM/T1_ATM) Configuration Windows

IxCatapult Software Reference Manual, Release 20.1

Configuring an IxCatapult Session

PPCI (J1/E1/T1) Configuration Window

IxCatapult Software Reference Manual, Release 20.1

Configuring an IxCatapult Session

Configuring an IxCatapult Session