Project

General

Profile

Actions

ADL process

Introduction

ADL is acronym for ANNA Diameter Launcher, that is to say, the diameter "launcher" based on ANNA suite, specifically its diameter module (A-Diameter).

The name "launcher" may not do justice to its multifunctionality, but somehow no longer be an interface node that provides diameter connectivity and facilitates interaction and generation of messaging in that protocol, thus, the diameter launch and redirection messaging. The name "simulator" is a concept that goes beyond their claims. A simulator, for example, for a GGSN node, requires the basic implementation of the functionality of that node. Are the scenarios and orchestration / coordination of messages, which brings us to the idea to emulate or simulate a GGSN or anything else.

In this sense, ADL is not a simulator at all, but its ability to integrate typical features of the diameter signaling network, goes beyond those provided by their functional predecessors of traditional Telefónica I+D diameter stack. The ADL improves integration for automation testing, provides a "burst" engine performance tests, and a management system failover for high availability tests in any environment with diameter interfaces.

ADL has a very large configuration flexibility to allow integration with any diameter system and abililty to test complex or improbable settings which should be considered in certain functional testing scenarios. To give a closer view of their potential, we will start by describing such configurability.

Multistack configurations

The ADL process is configured providing a unique stack information, by mean a dictionary or a set of dictionaries. This means that if our process has a local server configured, the received messages at the local endpoint will be interpreted by mean the only stack configured in the process. Then, no differenciation through the application-id or any other value (no sense because only one stack is loaded) will be done. If we need to establish a multistack environment we could achieve this, launching several ADL instances towards the same diameter entity and different stack configurations; however this is not possible for the server mode except if we configure listen ports and/or IP server addresses being different for each server service associated to a specific stack. There are another examples in the suite distribution, e.g. the PCAP decoder, which selects the stack using the application-id, demanding the stacks to be created with the stack id equals to that message field. The API allows to develop multistack servers in the same IP:port, but this process, due to simplification, does not implement it because it would not be really necessary. Anyway, there are stacks or contexts which are disjoint allowing the compatibility from each other. That is to say, we could have a unique dictionary with all the diameter elements inside (avps, messages, vendors, etc.) from different applications without awaited collision. In the case of Rx and Gx interfaces, it is possible to have collisions due to RAR/A message definitions. Also, depending on certain validation criteria, both RAR/A could be auto comptatibles and we could mix the dictionaries after all.

Summing up:
1. Multistack client with ADL: launch N instances with different stack configuration. The target entity can be perfectly the same.
2. Multistack server with ADL: launch N instances with different stack configuration hosted on different machines, or same machines with different virtual IPs and/or different listen ports.
3. Multistack balancer with ADL: combination of former ones.

In any case, you will need N instances to have N stacks. But that's the real situation: different stacks, different nodes. No need to emulate different nodes in the same process growing its complexity, and not only from development/design point of view, but from the user configuration one.

Only remember: if you need to develop a multistack server and/or client, the ANNA::diameter API won't limit you in any way.

Quick installation

The easier way to get started with the process consists in execution of script example/diameter/launcher/DEPLOY.sh from the git repository. With this procedure you could choose advanced or basic deployments (recommended for beginners) and also a function test client. Once installed, read the README file and follow the instructions. In few minutes you will launch clients, servers, or balancers, and connect them. You can also install the suite (sudo scons install, sudo scons install-example, etc.).

Configuration

ADL configuration begins describing the parameters provided in the command line of the process. As in any ANNA process, is enough to run without arguments to get a detailed help for each of the possible options. This is what we get in the shell executing as indicated:

myuser@myhostname:~/ADL-lite$ ./ADL-launcher 
Traces file ..................................: launcher.trace
Backup copy  .................................: launcher.trace.old
Files size (Kbytes) ..........................: 2000
Traces level .................................: Warning

launcher - DiameterLauncher. Version 1.1/ST/O/Linux 3.13 (x86_64)
(c) Copyright 2001-2006 Eduardo Ramos Testillano & Francisco Antonio Ruiz Rayo
                        eduardo.ramos.testillano@gmail.com & cisco.tierra@gmail.com
                        (project site: http://redmine.teslayout.com/projects/anna-suite)

Variable: 'dictionary' is not valid

Use: ./ADL-client [ --trace <value> ] [ --log <value> ] [ --splitLog ] [ --detailedLog ] [ --dumpLog ] [ --logStatisticSamples <value> ] [ --burstLog <value> ] [ --cntDir <value> ] [ --cntRecordPeriod <value> ] [ --httpServer <value> ] [ --httpServerShared ] [ --diameterServer <value> ] [ --diameterServerSessions <value> ] [ --entity <value> ] [ --entityServerSessions <value> ] [ --balance ] [ --sessionBasedModelsClientSocketSelection <value> ] --dictionary <value> [ --ignoreFlags ] [ --ignoreErrors ] [ --allowedInactivityTime <value> ] [ --tcpConnectDelay <value> ] [ --answersTimeout <value> ] [ --ceaTimeout <value> ] [ --watchdogPeriod <value> ] [ --reconnectionPeriod <value> ] [ --cer <value> ] [ --dwr <value> ] [ --originHost <value> ] [ --originRealm <value> ] [ --integrationAndDebugging ] 
Where: 
   --trace: 
     Trace level (emergency, alert, critical, error, warning, notice, information, debug, local0..local7)
   --log: 
     Process log file (operations result, traffic log, etc.). By default 'launcher.log'. Empty string or "null" name, to disable. Warning: there is no rotation for log files (use logrotate or whatever)
   --splitLog: 
     Splits log file (appends to log filename, extensions with the type of event: see help on startup information-level traces). No log files for code/decode and load operations are created
   --detailedLog: 
     Insert detailed information at log files. Should be disabled on automatic tests. Useful on '-balance' mode to know messages flow along the sockets
   --dumpLog: 
     Write to disk every incoming/outcoming message named as '<hop by hop>.<end to end>.<message code>.<request|answer>.<type of event>.xml'
   --logStatisticSamples: 
     Log statistics samples for the provided concept id list, over './sample.<concept id>.csv' files. For example: "1,2" will log concepts 1 and 2. Reserved word "all" activates all registered statistics concept identifiers. That ids are shown at context dump (see help to get it).
   --burstLog: 
     Burst operations log file. By default 'launcher.burst'. Empty string or "null" name, to disable. Warning: there is no rotation for log files (use logrotate or whatever). Output: dot (.) for each burst message sent/pushed, cross (x) for popped ones, and order number when multiple of 1% of burst list size, plus OTA requests when changed.
   --cntDir: 
     Counters directory. By default is the current execution directory. Warning: a counter file will be dump per record period; take care about the possible accumulation of files
   --cntRecordPeriod: 
     Counters record procedure period in milliseconds. If missing, default value of 300000 (5 minutes) will be assigned. Value of 0 disables the record procedure.
   --httpServer: 
     HTTP Management interface address (using i.e. curl tool) in '<address>:<port>' format. For example: 10.20.30.40:8080
   --httpServerShared: 
     Enables shared bind for HTTP Management interface address. It would be useful i.e. to allow a great amount of curl operations per second
   --diameterServer: 
     Diameter own server address in '<address>:<port>' format. For example: 10.20.30.40:3868
   --diameterServerSessions: 
     Diameter own server available connections (0: diameter server disabled). Default value of 1
   --entity: 
     Target diameter entity (comma-separated '<address>:<port>' format). For example: 10.20.30.40:3868,10.20.30.41:3868
   --entityServerSessions: 
     Diameter entity server sessions (0: diameter entity disabled). Default value of 1
   --balance: 
     Balance over entity servers instead of doing standard behaviour (first primary, secondary if fails, etc.)
   --sessionBasedModelsClientSocketSelection: 
     By default, round-robin will be applied for IEC model (SMS/MMS), and Session-Id Low Part will be analyzed for ECUR/SCUR model (data, voice and content). You could change ECUR/SCUR analysis behaviour providing 'SessionIdHighPart', 'SessionIdOptionalPart' (atoi applied; usually subscriber id data, i.e. MSISDN or IMSI) and 'RoundRobin'.
   --dictionary: 
     Diameter dictionary pathfiles (could be one or more ocurrences in a comma separated list, in order to accumulate loads). For example: avps_etsi.xml,avps_ietf.xml,avps_tgpp.xml,commands_qosControl.xml
   --ignoreFlags: 
     Ignore flags on validation (at the moment only bits M & P from AVPs, because V bit is too important; no operation flags could be checked). Also force compact xml presentation ignoring flags during dictionary elements identification
   --ignoreErrors: 
     Local server skips requests errors analysis which would prepare automatic answers for them when a problem is found. If no answer is programmed and entity is configured, a failed request would be forwarded (delegates at the end point) even if this parameter is missing
   --allowedInactivityTime: 
     Milliseconds for the maximum allowed inactivity time on server sessions born over the local server before being reset. If missing, default value of 90000 will be assigned
   --tcpConnectDelay: 
     Milliseconds to wait TCP connect to any server. If missing, default value of 200 will be assigned
   --answersTimeout: 
     Milliseconds to wait pending application answers from diameter peers. If missing, default value of 10000 will be assigned
   --ceaTimeout: 
     Milliseconds to wait CEA from diameter server. If missing, default value of 'answersTimeout' will be assigned
   --watchdogPeriod: 
     Milliseconds for watchdog timer (Tw) for diameter keep-alive procedure. If missing, default value of 30000 will be assigned
   --reconnectionPeriod: 
     Milliseconds to recover diameter client-session when server connection has been broken. If missing, default value of 10000 will be assigned
   --cer: 
     Pathfile for the Capabilities Exchange Request xml message. If missing, "cer.xml" is searched. If missing again, process creates own CER
   --dwr: 
     Pathfile for the Device Watchdog Request xml message. If missing, "dwr.xml" is searched. If missing again, process creates own DWR
   --originHost: 
     Diameter application host name (system name). If missing, process sets o.s. hostname
   --originRealm: 
     Diameter application node realm name. If missing, process sets domain name
   --integrationAndDebugging: 
     Sets validation mode to 'Always' (default validates only after decoding), and validation depth to 'Complete' (default validates until 'FirstError')
   --fixMode: 
     Sets message fix mode (unreconized values will assume default 'BeforeEncoding'). Allowed: 'BeforeEncoding', 'AfterDecoding', 'Always', 'Never'

myuser@myhostname:~/ADL-lite$

We will explain one by one, each of the setting items shown above. Note that it is only mandatory -dictionary, the diameter stack used by the process (although the ANNA-Diameter stack enables the development of multistack applications to create diameter traslation gateways or agents, in this case such functionality is not implemented as unnecessary for the purpose of the process).

Parameter [ --trace <value> ]

This is the trace level for the process. As in any ANNA process, trace levels are inspired by POSIX standards.
These levels are, for example, those used by the operating system syslog as shown on its manual pages:

       Possible values of severity level include:

       LOG_EMERG
              A panic condition.

       LOG_ALERT
              A condition that should be corrected immediately, such as a corrupted system database.

       LOG_CRIT
              Critical conditions, such as hard device errors.

       LOG_ERR
              Errors.

       LOG_WARNING
              Warning messages.

       LOG_NOTICE
              Conditions that are not error conditions, but that may require special handling.

       LOG_INFO
              Informational messages.

       LOG_DEBUG
              Messages that contain information normally of use only when debugging a program.

       The facility indicates the application or system component generating the message. Possible facility values include:

       LOG_USER
              Messages generated by arbitrary processes. This is the default facility identifier if none is specified.

       LOG_LOCAL0
              Reserved for local use.

       LOG_LOCAL1
              Reserved for local use.

       LOG_LOCAL2
              Reserved for local use.

       LOG_LOCAL3
              Reserved for local use.

       LOG_LOCAL4
              Reserved for local use.

       LOG_LOCAL5
              Reserved for local use.

       LOG_LOCAL6
              Reserved for local use.

       LOG_LOCAL7
              Reserved for local use.

The possible values for '-trace', are:

emergency
alert
critical
error
warning
notice
information
debug
local0
local1
local2
local3
local4
local5
local6
local7

At each level, traces for levels above are included. For example, at level 'warning', traces created from the application at warning, error, critical, alert and emergency levels are shown. At level 'debug', besides the above would see the trace logs (debug), information (information) and notification (notice).

The recommended starting production level is 'warning' (no error). This level is set by default in the absence of the optional parameter '-trace <level>'.
There is trace file rotation, making a renamed '.old' trace file (./launcher.trace -> ./launcher.trace.old). The rotation is performed each about 2 MB file growth. Under normal conditions, this will not happen, since the logging level would always be the 'warning' one. The 'debug' level is really designed to debug the process and perform deep analysis, but there are more sources of information aimed at practical use of the process as discussed below.

Parameter [ --log <value> ]

Specifies the traffic log measured by the process. By default (as it is an optional parameter), the traffic log is dumped on the './launcher.log' file generated in the starting point of the ADL. You can disable the file providing an empty string (-log "") or the word 'null' (-log null). Although the additional consumption for writing logs depends on the stress we subject the process, its influence on performance is minimal and its contribution is certainly very valuable to ignore his generation. There is no rotation in this file thus consider using logrotate or the like if it deems necessary.

This is an example of a traffic log for ADL process configured as proxy balancer of SMS traffic:


---------------------------------------------------------------------------------------------------------------------------------------
[recvfc] 10/12/2012 10:46:45 Europe/Madrid, isdst = 0 [Unix Timestamp: 1355132805, Ntp Timestamp: 3564121605], Local TZ = Europe/Madrid
---------------------------------------------------------------------------------------------------------------------------------------
<message version="1" name="Credit-Control-Request" p-bit="yes" application-id="4" hop-by-hop-id="1" end-by-end-id="1">
   <avp name="Session-Id" data="gbg.acision.com;421411;1000"/>
   <avp name="Origin-Host" data="gbg.acision.com"/>
   <avp name="Origin-Realm" data="SMSC.orig.OCS2.o2online.de"/>
   <avp name="Destination-Realm" data="SMSC.dest.OCS1.o2online.de"/>
   <avp name="Auth-Application-Id" data="4"/>
   <avp name="Service-Context-Id" data="8.6.0.07.262.8.32274@3gpp.org"/>
   <avp name="CC-Request-Type" data="4" alias="EVENT_REQUEST"/>
   <avp name="CC-Request-Number" data="1"/>
   <avp name="Destination-Host" data="OCS1"/>
   <avp name="Event-Timestamp" data="1"/>
   <avp name="Subscription-Id">
      <avp name="Subscription-Id-Type" data="0" alias="END_USER_E164"/>
      <avp name="Subscription-Id-Data" data="5555100000"/>
   </avp>
   <avp name="Requested-Action" data="0" alias="DIRECT_DEBITING"/>
   <avp name="Multiple-Services-Indicator" data="0" alias="MULTIPLE_SERVICES_NOT_SUPPORTED"/>
   <avp name="Multiple-Services-Credit-Control">
      <avp name="Requested-Service-Unit">
         <avp name="CC-Service-Specific-Units" data="1"/>
      </avp>
      <avp name="Service-Identifier" data="1"/>
   </avp>
   <avp name="Service-Information">
      <avp name="MMS-Information">
         <avp name="Originator-Address">
            <avp name="Address-Type" data="1" alias="MSISDN"/>
            <avp name="Address-Data" data="5555100000"/>
            <avp name="Address-Domain">
               <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
            </avp>
         </avp>
         <avp name="Originator-Address">
            <avp name="Address-Type" data="6" alias="Other"/>
            <avp name="Address-Data" data="262075555100000"/>
         </avp>
         <avp name="Submission-Time" data="3486294858"/>
         <avp name="Message-Size" data="4"/>
      </avp>
      <avp name="SMS-Information">
         <avp name="SMS-Node" data="3" alias="SMS-SC"/>
         <avp name="Client-Address" data="8|541760000405"/>
         <avp name="Originator-SCCP-Address" data="8|541760000005"/>
         <avp name="Originator-Received-Address">
            <avp name="Address-Type" data="1" alias="MSISDN"/>
            <avp name="Address-Data" data="5555100000"/>
            <avp name="Address-Domain">
               <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
            </avp>
         </avp>
         <avp name="Recipient-Info">
            <avp name="Destination-Interface">
               <avp name="Interface-Id" data="5417607020601"/>
               <avp name="Interface-Type" data="2" alias="MOBILE_TERMINATING"/>
            </avp>
            <avp name="Recipient-Address">
               <avp name="Address-Type" data="1" alias="MSISDN"/>
               <avp name="Address-Data" data="5417607020601"/>
               <avp name="Address-Domain">
                  <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
               </avp>
            </avp>
            <avp name="Recipient-Address">
               <avp name="Address-Type" data="6" alias="Other"/>
               <avp name="Address-Data" data="262074900005771"/>
            </avp>
            <avp name="Recipient-Received-Address">
               <avp name="Address-Type" data="1" alias="MSISDN"/>
               <avp name="Address-Data" data="5417607020601"/>
               <avp name="Address-Domain">
                  <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
               </avp>
            </avp>
            <avp name="Recipient-SCCP-Address" data="8|541760000005"/>
         </avp>
         <avp name="SMSC-Address" data="8|541760000405"/>
         <avp name="Data-Coding-Scheme" data="0"/>
         <avp name="SM-Message-Type" data="0" alias="SUBMISSION"/>
         <avp name="Originator-Interface">
            <avp name="Interface-Id" data="262074900005771"/>
            <avp name="Interface-Type" data="1" alias="MOBILE_ORIGINATING"/>
         </avp>
         <avp name="Number-Of-Messages-Sent" data="1"/>
      </avp>
   </avp>
   <avp name="CC-Correlation-Id" hex-data="6762672e61636973696f6e2e636f6d3b3432313431313b31303030"/>
</message>

Used resource
-------------
diameter::comm::ServerSession { Timer { timex::TimeEvent { Id: 0x9b4ba40 | Reference: 0x9b4ba40 | Timeout: 90000 ms } | Name: Diameter Inactivity Detection Timer } | Socket Id: 4 | State: Bound | OnDisconnect: WaitPendings | Next Hop by hop: 1888494197 | Next End to end: 4138298175 | OTA requests: 0 (idle) | Last Incoming Activity Time: 1355132805247 ms | Last Outgoing Activity Time: 1355132778004 ms | Timeout for ClassCode 'Bind': 10000 ms | Timeout for ClassCode 'ApplicationMessage': 10000 ms | Parent Local Server: 192.168.1.55:3868 | Client Socket: comm::ClientSocket { comm::Socket { Domain: Inet | Type: Stream | comm::TransportFactory { Name: diameter::comm::Transport | OverQuotaSize: 0 bytes } | fd: 14 | LocalPoint: { comm::INetAddress { comm::Device { IP: 192.168.1.55 | Status: Up } | Port: 3868 }  } | Bound: true | Opened: true | Category: 1 | anna::comm::ReceiverFactory { Name: diameter.comm.ServerSessionReceiver } } | RcvBufferSize: 16384 bytes | Status: Connected Working | MaxConDelay: 200 ms | OverQuotaSize: 2048 | Reserved: 1220 | Pending: 0 | Offset: 1220 | ExpectedSize: -1 | Remote access point: { comm::INetAddress { comm::Device { IP: 192.168.1.50 | Status: Up } | Port: 7001 }  } } | Allowed inactivity time: 90000 ms }

--------------------------------------------------------------------------------------------------------------------------------------
[fwd2e] 10/12/2012 10:46:45 Europe/Madrid, isdst = 0 [Unix Timestamp: 1355132805, Ntp Timestamp: 3564121605], Local TZ = Europe/Madrid
--------------------------------------------------------------------------------------------------------------------------------------
<message version="1" name="Credit-Control-Request" p-bit="yes" application-id="4" hop-by-hop-id="1" end-by-end-id="1">
   <avp name="Session-Id" data="gbg.acision.com;421411;1000"/>
   <avp name="Origin-Host" data="gbg.acision.com"/>
   <avp name="Origin-Realm" data="SMSC.orig.OCS2.o2online.de"/>
   <avp name="Destination-Realm" data="SMSC.dest.OCS1.o2online.de"/>
   <avp name="Auth-Application-Id" data="4"/>
   <avp name="Service-Context-Id" data="8.6.0.07.262.8.32274@3gpp.org"/>
   <avp name="CC-Request-Type" data="4" alias="EVENT_REQUEST"/>
   <avp name="CC-Request-Number" data="1"/>
   <avp name="Destination-Host" data="OCS1"/>
   <avp name="Event-Timestamp" data="1"/>
   <avp name="Subscription-Id">
      <avp name="Subscription-Id-Type" data="0" alias="END_USER_E164"/>
      <avp name="Subscription-Id-Data" data="5555100000"/>
   </avp>
   <avp name="Requested-Action" data="0" alias="DIRECT_DEBITING"/>
   <avp name="Multiple-Services-Indicator" data="0" alias="MULTIPLE_SERVICES_NOT_SUPPORTED"/>
   <avp name="Multiple-Services-Credit-Control">
      <avp name="Requested-Service-Unit">
         <avp name="CC-Service-Specific-Units" data="1"/>
      </avp>
      <avp name="Service-Identifier" data="1"/>
   </avp>
   <avp name="Service-Information">
      <avp name="MMS-Information">
         <avp name="Originator-Address">
            <avp name="Address-Type" data="1" alias="MSISDN"/>
            <avp name="Address-Data" data="5555100000"/>
            <avp name="Address-Domain">
               <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
            </avp>
         </avp>
         <avp name="Originator-Address">
            <avp name="Address-Type" data="6" alias="Other"/>
            <avp name="Address-Data" data="262075555100000"/>
         </avp>
         <avp name="Submission-Time" data="3486294858"/>
         <avp name="Message-Size" data="4"/>
      </avp>
      <avp name="SMS-Information">
         <avp name="SMS-Node" data="3" alias="SMS-SC"/>
         <avp name="Client-Address" data="8|541760000405"/>
         <avp name="Originator-SCCP-Address" data="8|541760000005"/>
         <avp name="Originator-Received-Address">
            <avp name="Address-Type" data="1" alias="MSISDN"/>
            <avp name="Address-Data" data="5555100000"/>
            <avp name="Address-Domain">
               <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
            </avp>
         </avp>
         <avp name="Recipient-Info">
            <avp name="Destination-Interface">
               <avp name="Interface-Id" data="5417607020601"/>
               <avp name="Interface-Type" data="2" alias="MOBILE_TERMINATING"/>
            </avp>
            <avp name="Recipient-Address">
               <avp name="Address-Type" data="1" alias="MSISDN"/>
               <avp name="Address-Data" data="5417607020601"/>
               <avp name="Address-Domain">
                  <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
               </avp>
            </avp>
            <avp name="Recipient-Address">
               <avp name="Address-Type" data="6" alias="Other"/>
               <avp name="Address-Data" data="262074900005771"/>
            </avp>
            <avp name="Recipient-Received-Address">
               <avp name="Address-Type" data="1" alias="MSISDN"/>
               <avp name="Address-Data" data="5417607020601"/>
               <avp name="Address-Domain">
                  <avp name="3GPP-IMSI-MCC-MNC" data="26207"/>
               </avp>
            </avp>
            <avp name="Recipient-SCCP-Address" data="8|541760000005"/>
         </avp>
         <avp name="SMSC-Address" data="8|541760000405"/>
         <avp name="Data-Coding-Scheme" data="0"/>
         <avp name="SM-Message-Type" data="0" alias="SUBMISSION"/>
         <avp name="Originator-Interface">
            <avp name="Interface-Id" data="262074900005771"/>
            <avp name="Interface-Type" data="1" alias="MOBILE_ORIGINATING"/>
         </avp>
         <avp name="Number-Of-Messages-Sent" data="1"/>
      </avp>
   </avp>
   <avp name="CC-Correlation-Id" hex-data="6762672e61636973696f6e2e636f6d3b3432313431313b31303030"/>
</message>

Used resource
-------------
diameter::comm::ClientSession { Timer { timex::TimeEvent { Id: 0x9b43dc0 | Reference: 0x9b43dc0 | Timeout: 30000 ms } | Name: Diameter Keep-Alive Timer } | Socket Id: 0 | State: Bound | OnDisconnect: WaitPendings | Next Hop by hop: 1235658055 | Next End to end: 127353711 | OTA requests: 1 | Last Incoming Activity Time: 1355132784902 ms | Last Outgoing Activity Time: 1355132805252 ms | Timeout for ClassCode 'Bind': 25000 ms | Timeout for ClassCode 'ApplicationMessage': 25000 ms | Parent Server: 192.168.1.55:3989 | Auto-recovery: yes | WatchdogState: WaitingTimerExpiration | Watchdog Period: 30000 ms | MaxConnectionDelay: 200 ms }

---------------------------------------------------------------------------------------------------------------------------------------
[recvfe] 10/12/2012 10:46:45 Europe/Madrid, isdst = 0 [Unix Timestamp: 1355132805, Ntp Timestamp: 3564121605], Local TZ = Europe/Madrid
---------------------------------------------------------------------------------------------------------------------------------------
<message version="1" name="Credit-Control-Answer" p-bit="yes" application-id="4" hop-by-hop-id="1" end-by-end-id="1">
   <avp name="Session-Id" data="gbg.acision.com;421411;1000"/>
   <avp name="Result-Code" data="2001" alias="DIAMETER_SUCCESS"/>
   <avp name="Origin-Host" data="OCS1"/>
   <avp name="Origin-Realm" data="SMSC.orig.OCS2.o2online.de"/>
   <avp name="Auth-Application-Id" data="4"/>
   <avp name="CC-Request-Type" data="4" alias="EVENT_REQUEST"/>
   <avp name="CC-Request-Number" data="1"/>
   <avp name="Multiple-Services-Credit-Control">
      <avp name="Granted-Service-Unit">
         <avp name="CC-Service-Specific-Units" data="1"/>
      </avp>
      <avp name="Service-Identifier" data="1"/>
      <avp name="Result-Code" data="2001" alias="DIAMETER_SUCCESS"/>
   </avp>
   <avp name="Cost-Information">
      <avp name="Unit-Value">
         <avp name="Value-Digits" data="200"/>
         <avp name="Exponent" data="-2"/>
      </avp>
      <avp name="Currency-Code" data="1"/>
   </avp>
   <avp name="Remaining-Balance">
      <avp name="Unit-Value">
         <avp name="Value-Digits" data="999988399"/>
         <avp name="Exponent" data="-2"/>
      </avp>
      <avp name="Currency-Code" data="1"/>
   </avp>
</message>

Used resource
-------------
diameter::comm::ClientSession { Timer { timex::TimeEvent { Id: 0x9b43dc0 | Reference: 0x9b43dc0 | Timeout: 30000 ms } | Name: Diameter Keep-Alive Timer } | Socket Id: 0 | State: Bound | OnDisconnect: WaitPendings | Next Hop by hop: 1235658055 | Next End to end: 127353711 | OTA requests: 1 | Last Incoming Activity Time: 1355132805376 ms | Last Outgoing Activity Time: 1355132805252 ms | Timeout for ClassCode 'Bind': 25000 ms | Timeout for ClassCode 'ApplicationMessage': 25000 ms | Parent Server: 192.168.1.55:3989 | Auto-recovery: yes | WatchdogState: WaitingTimerExpiration | Watchdog Period: 30000 ms | MaxConnectionDelay: 200 ms }

------------------------------------------------------------------------------------------------------------------------------------------
[fwd2c] 10/12/2012 10:46:45 Europe/Madrid, isdst = 0 [Unix Timestamp: 1355132805, Ntp Timestamp: 3564121605], Local TZ = Europe/Madrid
------------------------------------------------------------------------------------------------------------------------------------------
<message version="1" name="Credit-Control-Answer" p-bit="yes" application-id="4" hop-by-hop-id="1" end-by-end-id="1">
   <avp name="Session-Id" data="gbg.acision.com;421411;1000"/>
   <avp name="Result-Code" data="2001" alias="DIAMETER_SUCCESS"/>
   <avp name="Origin-Host" data="OCS1"/>
   <avp name="Origin-Realm" data="SMSC.orig.OCS2.o2online.de"/>
   <avp name="Auth-Application-Id" data="4"/>
   <avp name="CC-Request-Type" data="4" alias="EVENT_REQUEST"/>
   <avp name="CC-Request-Number" data="1"/>
   <avp name="Multiple-Services-Credit-Control">
      <avp name="Granted-Service-Unit">
         <avp name="CC-Service-Specific-Units" data="1"/>
      </avp>
      <avp name="Service-Identifier" data="1"/>
      <avp name="Result-Code" data="2001" alias="DIAMETER_SUCCESS"/>
   </avp>
   <avp name="Cost-Information">
      <avp name="Unit-Value">
         <avp name="Value-Digits" data="200"/>
         <avp name="Exponent" data="-2"/>
      </avp>
      <avp name="Currency-Code" data="1"/>
   </avp>
   <avp name="Remaining-Balance">
      <avp name="Unit-Value">
         <avp name="Value-Digits" data="999988399"/>
         <avp name="Exponent" data="-2"/>
      </avp>
      <avp name="Currency-Code" data="1"/>
   </avp>
</message>

Used resource
-------------
diameter::comm::ServerSession { Timer { timex::TimeEvent { Id: 0x9b4ba40 | Reference: 0x9b4ba40 | Timeout: 90000 ms } | Name: Diameter Inactivity Detection Timer } | Socket Id: 4 | State: Bound | OnDisconnect: WaitPendings | Next Hop by hop: 1888494197 | Next End to end: 4138298175 | OTA requests: 0 (idle) | Last Incoming Activity Time: 1355132805247 ms | Last Outgoing Activity Time: 1355132805377 ms | Timeout for ClassCode 'Bind': 10000 ms | Timeout for ClassCode 'ApplicationMessage': 10000 ms | Parent Local Server: 192.168.1.55:3868 | Client Socket: comm::ClientSocket { comm::Socket { Domain: Inet | Type: Stream | comm::TransportFactory { Name: diameter::comm::Transport | OverQuotaSize: 0 bytes } | fd: 14 | LocalPoint: { comm::INetAddress { comm::Device { IP: 192.168.1.55 | Status: Up } | Port: 3868 }  } | Bound: true | Opened: true | Category: 1 | anna::comm::ReceiverFactory { Name: diameter.comm.ServerSessionReceiver } } | RcvBufferSize: 16384 bytes | Status: Connected | MaxConDelay: 200 ms | OverQuotaSize: 2048 | Reserved: 0 | Pending: 0 | Offset: 0 | ExpectedSize: -1 | Remote access point: { comm::INetAddress { comm::Device { IP: 192.168.1.50 | Status: Up } | Port: 7001 }  } } | Allowed inactivity time: 90000 ms }

We can see three "multiplexors" or "loading docks", labeled with these key words:

   [recvfc] (received from client)
   [fwd2e]  (forwarded to entity)
   [recvfe] (received from entity)
   [fwd2c]  (forwarded to client)

We have kept these four in the example, since they represent the normal cycle in the proxy function, but there are many more that will appear depending on the setting and circumstances of the event:

   [sent2e/send2eError]   Send to entity (success/error)
   [sent2c/send2cError]   Send to client (success/error)
   [fwd2e/fwd2eError]     Forward to entity a reception from client (success/error)
   [fwd2c/fwd2cError]     Forward to client a reception from entity (success/error)
   [recvfc]               Reception from client
   [recvfe]               Reception from entity
   [req2c-expired]        A request sent to client has been expired
   [req2e-expired]        A request sent to entity has been expired
   [recvfc-ans-unknown]   Reception from client of an unknown answer (probably former [req2c-expired] has been logged)
   [recvfe-ans-unknown]   Reception from entity of an unknown answer (probably former [req2e-expired] has been logged)
   [retry]                Request retransmission

Each log record in the file contains a header with the event type within brackets and then the message corresponding to the diameter message traced in xml format. There is also detailed information (which is optionally added by mean the parameter '-detailedLog') consisting of the temporal event information in the header, and the data associated with the resource used for message transport (connection by which it is received or sends data associated with the session, etc.) right after the message.

Parameter [ --splitLog ]

The log file can be divided into N files for each event type. Each file name is formed by concatenating the 'log filename' (provided in '-log <value_log>' or './launcher.log' if one not specified) with an extension that is the type of event (list of types within brackets shown above). For example, the traffic from the previous example, usually would generate 4 files:

./launcher.log.recvfc
./launcher.log.fwd2e
./launcher.log.recvfe
./launcher.log.fwd2c

Parameter [ --detailedLog ]

Detailed information on records in logs consist of time stamp and information of resources involved in the traffic event. By default, this information is not logged facilitating test automation (in case we use the traffic log to validate, because a timestamp variable data imply a test that would invalidate the comparison with the reference). In any case, for additional information that may be of interest in certain situations, just add this parameter at startup.

Parameter [ --dumpLog ]

Dumps to disk every incoming/outcoming message named as '<hop by hop>.<end to end>.<message code>.<request|answer>.<type of event>.xml'. This could be useful in function test environment in order to detect traffic, analyze it and adapt the reaction to the tested system.

Parameter [ --logStatisticSamples <value> ]

The ANNA::diameter module, cornerstone of this process, incorporates a statistical engine that measures two main concepts: server processing time and size of messages processed. If the process is started in client mode and connects to N servers, there will be 2 * N statistical concepts, recorded dynamically and automatically. The information collected (average, maximum, minimum, variance, etc.) is managed independently in these 2 * N instances. When performing the dump process context (you can see this example), we can see the statistical data along the elements in the diameter system. For example, for a certain server, we could see processing time:

<Concept Id="1" Description="Diameter processing time (for requests) at servers on zape-ocs2dfed1:3868" Unit="ms">
   <Data Size="445" Average="19.82" StandardDeviation="30.33" BesselStandardDeviation="30.37" ProcessingRate="16.48 vps (values per second)">
      <Minimum Value="8" Date="21/04/2012" Time="05:24:20" TZContext="Europe/Madrid" Isdst="yes" UnixTimestamp="1334978660" NtpTimestamp="3543967460" LocalTZ="Europe/Madrid"/>
      <Maximum Value="328" Date="21/04/2012" Time="05:24:33" TZContext="Europe/Madrid" Isdst="yes" UnixTimestamp="1334978673" NtpTimestamp="3543967473" LocalTZ="Europe/Madrid"/>
      <LastResetTimestamp Date="21/04/2012" Time="05:24:18" TZContext="Europe/Madrid" Isdst="yes" UnixTimestamp="1334978658" NtpTimestamp="3543967458" LocalTZ="Europe/Madrid"/>
   </Data>
</Concept>

The 'Processing Rate' is the number of data events processed per second. If the contexts are completed (otherwise it can not compute the concept of processing time and therefore can not add the measure on the statistical sample) is considered a new data processing (transaction concept). Thus, in the example we could talk about a traffic rate of about 17 messages per second on that server.

We will talk now about the parameter '-logStatisticSamples':

At the end of the xml file of the context dump we can see general information from statistics engine, specially the concepts registered for analysis. For example, suppose a diameter client connected to two diameter entity servers:

<Concept Id="1" Description="Diameter processing time (for requests) at servers on zape-ocs2dfed1:3868" Unit="ms" IntegerNatureSample="yes"/>
<Concept Id="2" Description="Diameter message sizes received from servers on zape-ocs2dfed1:3868" Unit="bytes" IntegerNatureSample="yes"/>
<Concept Id="3" Description="Diameter processing time (for requests) at servers on zape-ocs2dfed2:3868" Unit="ms" IntegerNatureSample="yes"/>
<Concept Id="4" Description="Diameter message sizes received from servers on zape-ocs2dfed2:3868" Unit="bytes" IntegerNatureSample="yes"/>

In the case shown, the concepts 1 and 3 seem the most interesting, because they give a picture of the processing time to assess progress, bottlenecks, or impact of certain actions on a given interface connection. Concepts 3 and 4 can be interesting in the stages of preliminary analysis for sizing queues face to configure congestion thresholds on certain systems. Suppose we are only interested in concepts of "processing speed" and discard the statistical information on the size of messages processed. In that case, we might launch the process passing -logStatisticSamples 1,3 which means that the sample data concerning such concepts will be dump on disk. You can specify 'all' to activate the dump in all statistical concepts assigned to the process.

The statistical engine does not store the sample data, since this would have a great cost in memory and performance. Statistics are calculated cumulatively (including Bessel variance by a convenient development in the formula). However, by configuration, we could activate dumps for every processed data to disk. The destination dump files have a fixed name that includes the identifier of the concept: './sample.<concept id>.csv'. Its contents are comma-separated and contains the unix timestamp followed by the processed value. For example, we could have the time sample processed with this:

1355186310124,90
1355186310526,92
1355186310862,29
1355186311271,38
1355186312103,70
1355186312148,115
1355186312490,57
1355186312905,71
1355186313343,110

If we've just generated these nine transactions, statistical data show a maximum of 115 in the timestamp "1355186312148". But what is clear is that by activating the dump can access the actual test data. This is mainly used for the preparation of charts and trends. For example, in a test failover to two servers hosted on two front-ends, we note that when the service goes down into one of them, processing times on the front-end survivor increase slightly.

Parameter [ --cntDir <value> ]

Directory where the process counters are written (if cyclic dump is enabled).
The execution directory is taken as default when this optional parameter is not provided.
The files are automatically created in the form:

-rw------- 1 edu HOME 367 jul 25 04:37 Counters.Pid31061.Date20140725.Time043706
-rw------- 1 edu HOME   0 jul 25 04:38 Counters.Pid31061.Date20140725.Time043806
-rw------- 1 edu HOME   0 jul 25 04:39 Counters.Pid31061.Date20140725.Time043906
-rw------- 1 edu HOME   0 jul 25 04:40 Counters.Pid31061.Date20140725.Time044006

Parameter [ --cntRecordPeriod <value> ]

Time in milliseconds for the recording period of the counters information. The default is set to 5 minutes. A zero value disables writing to disk.
Recorded content includes the recording interval (not including seconds in range precission) and counter data (identifier, value and description):

eramedu@myhostname:~/ADL-lite/counters$ cat Counters.Pid31061.Date20140725.Time043706
2014-07-25 04:37|2014-07-25 04:37|002004|0000016|diameter::codec oam module::AvpDecode__UnknownAvpWithMandatoryBit
2014-07-25 04:37|2014-07-25 04:37|002015|0000004|diameter::codec oam module::LevelValidation__FailedRuleForCardinality
2014-07-25 04:37|2014-07-25 04:37|002016|0000004|diameter::codec oam module::LevelValidation__FailedRuleForCardinalityLessThanNeeded

Parameter --httpServer <value>

This is an optional parameter that indicates the management server via HTTP. It is a key management interface to leverage the process, although there is another mechanism by mean signals. Dynamic configuration, control and real time monitoring, are part of the offered possibilities. There is a wide range of operations offered on this interface which we will detail in the later section "HTTP Management". With tools for direct invocation on the linux shell, such as the client _ curl _, we can control any operation we want to apply. In addition, provides a variety of scripts that simplify and facilitate the use of the interface to perform operations in the simplest possible way for this process.

The value for the parameter has the format <address:port>. For the address you can specify the IP or delegate to /etc/hosts or DNS to resolve a given name. The port value is good to be 9000, 8000, etc.

Parameter [ --httpServerShared ]

By default, the HTTP interface listens exclusively, so that while a client is connected to send an operation, listening is not available for new connections. Enabling this parameter allows the shared interface and virtually unlimited operational use. Usually the operations are very fast in practice and non-exclusivity is not required. In performance tests with a single instance (which also must be aware that perhaps is not the most appropriate way) there is an operation called "burst sendXS" providing the number of messages per second that you want to generate. The script invokes the atomic operation "send" on a list of requests which ADL process loaded in memory, the number of times indicated per second. As we use the curl command, must take into account that makes the connection, sends the http message and then closes. That is done N times per second. When the number is very high for a single instance (and this depends on many factors), say 50 tps, it may happen that a customer enters a conflict with another (since it launched in background from script that would otherwise be slower). With the method of sharing listening (relay unix file descriptor of the connection) such a conflict will not occur. In any case, as we noted earlier, the most recommended way to inject charge is launching multiple instances of the process, for example a 10 tps each would be 5, and 10 transactions per second does not really offer any problems for the script or for the http client. The operation for traffic load at a given rate is based on a feedback cycle to recalculate in real time the number of milliseconds of delay between a shipment and the next. When the rate is very high, that period tends to zero and may even indicate reached in HTTP operation that sent more than one message no asynchronous manner, in order to "recover" delays and maintain the average rate for required shipment. All this complexity is determined on the scripts and through the operation interface.

Parameter [ --burstLog <value> ]

Log file for burst mode operations. This mode will be explained later, but basically it is a set of related operations to load launch for capacity tests of a diameter server system (eg OCS ). By default, the program will dump the related information over './launcher.burst' file. It can also disable the generation of such logs simply by providing 'null'. The log consists in a set of symbols for each type of event: (.) for each message sent, (x) for each event-reception discarded for sending, information for on-the-air messages, message order in the burst list, etc.:

.............. 540................... 560[OTA 2]................... 580[OTA 3]................... 600[OTA 1]................... 620................... 640................... 660................... 680[OTA 2]................... 700[OTA 1]................... 720................... 740................... 760................... 780[OTA 2]................... 800[OTA 1]................... 820[OTA 2]................... 840................... 860[OTA 1]................... 880................... 900................... 920................... 940................... 960................... 980................... 1000................... 1020................... 1040[OTA 2]................... 1060[OTA 1]................... 1080................... 1100[OTA 2]................... 1120[OTA 1]................... 1140................... 1160[OTA 2]................... 1180[OTA 1]................... 1200................... 1220................... 1240................... 1260................... 1280[OTA 2]................... 1300[OTA 8]................... 1320.........xxxxxx.... 1340[OTA 2]................... 1360[OTA 1]

etc.

Parameter [ --diameterServer <value> ]

Diameter server listen address in format '<address>:<port>'. For example: 10.20.30.40:3868 or ocs2dfed1:3868.
The process only listen on a port. It would be easy to have multiple ports to N different services, but it is normal to use a single port (which should also be the standard 3868) and classify traffic by mean the routing AVPs (Destination-Realm), or service (Service-Context-Id) to perform one or another action. The process is designed to treat a specific type of traffic analysis and does not analyze routing AVPs, but his proxy mode could delegate this task on other agents.

Parameter [ --diameterServerSessions <value> ]

This parameter indicates the number of connections allowed to the listen server. The default value (in case you specified the diameterServer parameter) is 1, meaning "mono-connection" mode. When the last connection is accepted by the process regarding the configuration (for example, the third connection in the case of value 3), the server closes the listen port to prevent external clients connect to our access point. When a connection is broken for any reason, the range of connections is released reopening the server listen port for new incoming connections. As discussed in the section operating commands, this data can be updated dynamically during operation of the process, to facilitate scaling without affecting the established transport and transactions in the air.

The process can disable the server listen port. Simply must set the value 0 in this parameter. This is typically done in client-only mode.

Parameter [ --entity <value> ]

Address for diameter entity to which we connect as a client. An entity is defined as a prioritized list of diameter servers. For the ADL process, each element (server) from the list is separated by commas and the format is, again, '<address>:<port>'. For example '10.20.30.40:3868,ocs3:3868', would be a typical entity formed by a primary and a secondary server. There is no limitation on the number of servers on which is formed an entity. Similarly, an entity may be formed by a single server.

The standard behavior of traffic distribution to the entity set is shipping the highest priority server (primary), going to the following when there is a failure on that server, and so on to use the last of the list. After, we will talk about balancing which is something like a round-robin with failover support, which is not standard, but makes easy high availability testing over a receiver cluster (eg, the one front-end of an OCS ).

Parameter [ --entityServerSessions <value> ]

The ADL process is multi-connection on the server side, but also on the client side. In this case, as customers we can launch N connections (default N = 1) to each of the servers that belong to the entity defined by the parameter '-entity'. In this way we can cover the pool of available connections in the interface layer of the entity node (for example, the OCS front-end). If we configure more connections than supported by a server, those which fail, will be retried periodically. Typically the sizing always leave a margin determined at the diameter entity, or at most, provide at least the resources that are going to apply.

As with server-side configuration, a null (0) disables the client functionality of the process, which is typical for server configurations (Rx interface at PCRF node simulation, simulation of Gy for OCS , etc.).

A process that has disabled ADL client mode and server mode, may seem useless, but as we shall see in operations management, this process can also be used as a server for encoding/decoding, useful for the test environment and preparation of scenarios from production dumps, traces, etc.

Parameter [ --balance ]

This parameter sets balancing between servers, from the diameter entity configured as active client functionality. Suppose we have 2 servers (primary, secondary) with N links each:

S11 S12 .. S1N S21 S22 .. S2N

Balance mode will deliver in this way:

S11 S21 S12 S22 .. S1N S2N

that is to say, something like a "round-robin inter-server-inter-socket", thus: RR between servers, and within them, between sockets in order of use (older activity on each socket). When sending fails (not available) to a particular server, it is retried with all its connections and if still fails is passed to another server, trying again with all connections). At the completion, if it failed to send, gives a fault.

The difference from the standard mode, is that standard always start with the primary, and if it fails (fail all connections) is passed to the next. At the end, if it failed to send the message, results in a failure. In balance mode, the server used for sending is the next to the last used, ie it does not start from the first, but from the next to last used as a round-robin, and the cycle is completed after the use of all the above to the first that was used to start the balanced delivery, which may be the last on the list or not.

The balanced mode facilitates testing HA (high availability) of certain systems. For example in the OCS , we can have an interface layer consisting of two machines (fed1, fed2). If we throw one of them, we only have available a machine in the list, but not half the traffic is lost, since it uses failover and when it fails against the front-end dropped, it automatically launches to the survivor (ie, is not a "blind" round-robin, so it has been called "balanced").

Parameter [ --sessionBasedModelsClientSocketSelection <value> ]

The behavior of delivery connections engine, has the "courtesy" to select destination sockets based on certain information, namely:

  1. Information on the AVP Service-Context-Id. With this data it can be inferred, for example, the billing model on credit control applications. Thus we would have the IEC model used for SMS/MMS, or ECUR/SCUR models used in data, voice and generic content.
  2. Information in the Session-Id AVP. This AVP consists of several parts: identity diameter, 'low part', 'high part' and an optional part.

The mentioned deference is because models like ECUR/SCUR, perform a selective delivery based on the Session-Id, namely the least significant part (or low context-id part). This could "liberate" the server to perform a hypothetical routing towards a specific destination for messages with the same value for analyzed context. In fairness, or rather in practice, this should not be the responsibility of the client node, which would not have to perform this type of selection and would be sufficient to make a round-robin to the connection pool available on the target entity. However, by default it does, but really, we can disable this behavior towards a pure RR. In any case, the IEC model (instant event charging) is always processed according to a round-robin delivery. Unidentified charging contexts, are also managed by RR.

The parameter '-sessionBasedModelsClientSocketSelection' is useful only to modify the SCUR/ECUR model behaviour used for data, voice and contents billing, assigning these values:

  1. SessionIdHighPart, to use the 'high part' from AVP Session-Id.
  2. SessionIdOptionalPart, to use the AVP Session-Id optional part (interpreting its value as integer, because normally it is an MSISDN or IMSI in this case).
  3. RoundRobin, to force RR algorithm, even in this kind of models.

The option '-sessionBasedModelsClientSocketSelection RoundRobin', would be the most general and certainly reasonable. Indeed on the OCS , is more than enough, and need not rely on the default behavior, since any node receiving traffic will process smoothly. It should not be a limitation of the OCS the fact that all transactions require the same session, arrive on the same physical path, and in fact, as we said, it is not.

Another very different topic (which may have aroused the concern of the reader) is the bad so-called "extended" delivery (because it really is the opposite, ie restricted), made by diameter distribution processes to the business logic (for example) . This distribution has been traditionally performed through the analysis of context-TEID of the Session-Id, so that a rigid target for a specific value was set. The motivation for this was to minimize deadlocks or races in the treatment of a context for different instances of the billing processes. If to ensure this type of deal between the interface (Front-end) and the business logic (Back-End) was necessary to ensure the same behavior from the client node (which it is not), then the default behavior of the sending engine of ADL client, would be fully justified, at least in the scope of an OCS.

Session-Id as described in RFC 6733:

The Session-Id MUST begin with the sender's identity encoded in the
   DiameterIdentity type (see Section 4.3.1).  The remainder of the
   Session-Id is delimited by a ";" character, and it MAY be any
   sequence that the client can guarantee to be eternally unique;
   however, the following format is recommended, (square brackets []
   indicate an optional element):

      <DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]

   <high 32 bits> and <low 32 bits> are decimal representations of the
   high and low 32 bits of a monotonically increasing 64-bit value.  The
   64-bit value is rendered in two part to simplify formatting by 32-bit
   processors.  At startup, the high 32 bits of the 64-bit value MAY be
   initialized to the time in NTP format [RFC5905], and the low 32 bits
   MAY be initialized to zero.  This will for practical purposes
   eliminate the possibility of overlapping Session-Ids after a reboot,
   assuming the reboot process takes longer than a second.
   Alternatively, an implementation MAY keep track of the increasing
   value in non-volatile memory.

   <optional value> is implementation specific, but it may include a
   modem's device Id, a Layer 2 address, timestamp, etc.

   Example, in which there is no optional value:

      accesspoint7.example.com;1876543210;523

   Example, in which there is an optional value:

     accesspoint7.example.com;1876543210;523;mobile@200.1.1.88

   The Session-Id is created by the Diameter application initiating the
   session, which, in most cases, is done by the client.  Note that a
   Session-Id MAY be used for both the authentication, authorization,
   and accounting commands of a given application.

Parameter --dictionary <value>

Traditionally, the dictionary defines the stack diameter that governs the encoding/decoding engine of the process. In ANNA::diameter, a dictionary really is not the same as a stack. Usually we talk about "diameter stack for sms" or "diameter dictionary for sms", however, is preferable to understand "dictionary" as a set of elements (vendors, avps, operations, formats, etc.) that define a specific context. A stack can consist of one or N dictionaries. The way they deliver and maintain dictionaries has taken a quantum leap from traditional resources, where each dictionary or stack was "autonomous". That forced them to redefine many common elements in different vendors, and this decentralization always gives maintenance problems, since a change in the format or meaning of a Avp, for example, has a horizontal impact often becomes a headache.

Now we can likewise have a single dictionary for stack with all the necessary elements (as in the past), but we also have a list of dictionaries that make up the battery, and take those resources from development base providing a very beneficial centralization.

The new dictionaries can be found in the base directory called setups

The dtd template to create dictionaries can be seen here

The idea is, as explained in readme.txt:

Mandatory notation for xml dictionary resources
-----------------------------------------------
There two file types here:
(A)Files with vendor/format and avp data info items:
     avps_<vendor-name (lower case)>.xml

(B)Files with application operations, command items:
     commands_<context>[_<product>][_<country>].xml

     context: Application and service-context-id (camel case).
     product: Manufacturer/equipment/version (camel case).
     country: Country site location according to iso 3166-1-alpha-2 (lower case).
              Also a dash-separated list of codes could be used when two or more
               sites support the diameter stack.

It is recommended to define only one vendor id per (A) file.
It is recommended to define only one context per (B) file.

Scripts
-------
-flags.sh:      show flags table for (A) files.
-dependence.sh: check dependences for (A) and (B) files.

That is, basically you sort the files in 'AVPs dictionaries' and 'command dictionaries'. Thus, a command that uses an AVP IETF (for example), charge in addition to defining the command itself, the dictionary of IETF AVPs. Another command that also uses that AVP, also charge that, but the dictionary command only defines the operations no more.

In addition to a comprehensive file naming, certain variants may define behavior "outside the specification" at the highest level to avoid affecting more variants on the standard versions, which is an interesting organizational advantage in planning deployments and configurations of different production sites.

The dictionaries also substantially enhance its appearance, which is much easier to interpret the structure of a certain operation without having close reference defining the elements that compose it.

The '-dictionary' parameter can be one or more occurrences in a comma-separated of file-dictionary list, for example:

-dictionary avps_etsi.xml,avps_ietf.xml,avps_tgpp.xml,commands_qosControl.xml

In practice, autonomous dictionaries are created (using one tool that calculates the dependencies and brings together the necessary dictionaries, ie not actually deliver "Collected versions" for batteries, which would be counterproductive with all the advantages discussed at the new stack management system), which are often called "Autonomous_xxx" .

Parameter [ --ignoreFlags]

Earlier we saw the dtd template to build dictionaries. Here we can see the template to construct diameter messages (click here). Diameter messages are useful to represent in XML format the operation content. The xml files are used mainly for testing (either functional, high availability or performance), and also to facilitate the configuration of base protocol (base structure for CER/CEA, DWR/DWA, DPR/DPA , etc.).

When representing a message in xml, as you can see in the template there is a "compact" option and an "open" alternative. Both for operation (can put your name instead of your code) and for some AVP (can put your name instead of the code, vendor id and flags). Where the idea is clearer to see compact/open mode meaning, is in the case of the AVP. Suppose the Session-Id AVP, whose definition in the dictionary is:

<avp name="Session-Id" code="263" may-encrypt="yes" v-bit="mustnot" m-bit="must" p-bit="may"><single format-name="UTF8String"/></avp>

Its definition follows the standard, which sets the following flags:

                                               AVP  |       Must  |        May  | Should Not  |   Must Not  | May Encrypt
-------------------------------------------------------------------------------------------------------------------------
                                        Session-Id  |          M  |          P  |          -  |          V  |          Y

If we send a message like following:

<message version="1" name="AA-Request" application-id="0" hop-by-hop-id="10" end-by-end-id="2">
   <avp name="Session-Id" data="ocs3;1332909618;0;1332909618"/>
   <avp name="Auth-Application-Id" data="16777236"/>
   <avp name="Origin-Host" data="OCS3"/>
   <avp name="Origin-Realm" data="OCS3"/>
   <avp name="Destination-Realm" data="PCRF"/>
   <avp name="Subscription-Id">
      <avp name="Subscription-Id-Type" data="0" alias="END_USER_E164"/>
      <avp name="Subscription-Id-Data" data="4851"/>
   </avp>
</message>

What we are saying is that the Session-Id AVP is encoded as dictionary says (corresponding to dictated by the standard), which is active M bit and inactive V bit (the concepts 'May', 'Should not' and 'May Encrypt' are indicative but not determinative, important are 'Must' and 'Must not').

This message could be defined with Session-Id equal to what the dictionary defines, but with the "non-compact" format as dtd allows:

   <avp code="263" vendor-code="0" flags="64" data="ocs3;1332909618;0;1332909618"/>

where value 64 corresponds to byte 01000000b [VMPr rrrr], ie active M bit.

Suppose now that we define AA-Request operation with this one Session-Id:

   <avp code="263" vendor-code="0" flags="0" data="ocs3;1332909618;0;1332909618"/>

Such AVP has now inactive M bit, what probably has no logic implications (very few nodes are exhaustive analyzing the flags), but it is clear that in this case, we're breaching the specification.

When the ANNA::diameter module analyzes and represents a diameter message processed (either debug traces or traffic logs dumps), it is in xml format because it is easier to understand than hexadecimal buffer. In this case, the message of the previous example with the Session-Id "non-standard" would appear as:

<message version="1" name="AA-Request" application-id="0" hop-by-hop-id="10" end-by-end-id="2">
   <avp code="263" vendor-code="0" flags="0" data="ocs3;1332909618;0;1332909618"/>
   <avp name="Auth-Application-Id" data="16777236"/>
   <avp name="Origin-Host" data="OCS3"/>
   <avp name="Origin-Realm" data="OCS3"/>
   <avp name="Destination-Realm" data="PCRF"/>
   <avp name="Subscription-Id">
      <avp name="Subscription-Id-Type" data="0" alias="END_USER_E164"/>
      <avp name="Subscription-Id-Data" data="4851"/>
   </avp>
</message>

And this is because the Session-Id is not exactly the same as defined in the dictionary, but a Session-Id AVP and specific flags that do not match 100%.

Here comes in the parameter '-ignoreFlags' whose presence means that even with no matching flags with the dictionary, the xml representation ignore such "capricious" definition of flags leading to the first representatin we set, ie which has the "simplified" Session-Id:

   <avp name="Session-Id" data="ocs3;1332909618;0;1332909618"/>

What is really happening is that the message processed (hexadecimal) does not fully coincide with the encoding (using the dictionary) for the xml represented, while the first will have the M flag off for the Session-Id, and the represented will have the specified flag at dictionary conform the specification: M bit active.

The recommendation is to start the ADL process without this optional parameter, since it does not guarantee 100% that what we see, for the purposes of flags, is exactly what we received, and this discrepancy, although too detailed, could confuse sometime when perform deeper analysis.

The ignoreFlags parameter internally prevents verification of M and P flags of AVPs, which involves having a compact XML representation, but mainly ignores validation errors messages generated by nodes that do not comply with the standard regarding the flags.

Parameter [ --allowedInactivityTime <value> ]

The server mode allows to configure the inactivity time (in milliseconds), which by default is one minute and a half (-allowedInactivityTime 90000). When the process does not detect activity in the receive buffer for 90 seconds will reset the connection and will put it into listening state again (since in the worst case that all sockets were busy, it would recover the margin to open this listen port).

The diameter protocol states that for a given connection, when there is no traffic, must be sent an DWR (keep alive diameter) message that will be answered by the server using a DWA. The period of sending for this keep alive is, as recommended by the standard, about 30 seconds. Downtime of 90 seconds covers most of the possible real configurations protecting against "ghost" connections that may occur due to conmutation equipment failure of TCP network (a router that does not complete a closing procedure cycle and our server not detect as such, or any other abnormality that disconnects us without knowing from the operating system, having the connection as 'ESTABLISHED' according to netstat command output).

Parameter [ --tcpConnectDelay <value> ]

This parameter is used to adapt our client to different servers with respect to the speed of response in the TCP connect. Some servers can be very slow and have to increase the default value of 200 milliseconds (default). Should establish a reasonable value as a single thread process with a large number of client connections may incur in "blocking" time too big if I had connectivity problems and we had set a higher value than is actually necessary.

Parameter [ --answersTimeout <value> ]

The ANNA::diameter module has a native transaction manager, which controls the contexts in the air to resolve sequences, locations, or any other information built in an inheritance message system (diameter::comm::Message). Among other things, it controls the expiration of contexts to notify to the application and release the associated resource as when a response is received correctly. The contexts timeout lapses 10 seconds, which is the standard (Tx) to application messages according to the diameter specification. However there may be more restrictive or more open.

For the configuration as proxy balancer, the process will receive traffic from an external client node, and forward it to the serving entity (for example, diameter gateway for an OCS). In this case, if we don't want to muddy the statistics collected on the external node, we must be open and set a high expiration timeout value, and perhaps, a "slow" context would arrive at its destination in any case but it would be cut if we set restrictive time. In tests, if you want to use the process as a mere intermediary, it is advisable, therefore, to put a value greater than or equal to the expiration time of the external node.

Parameter [ --ceaTimeout <value> ]

The message Capabilities-Exchange-Request (CER) as a request that is, has an associated context in the ANNA::diameter transactions engine. The timeout set by default (if not defined ceaTimeout) is Tx = 10 seconds or answersTimeout if it was defined.

Parameter [ --watchdogPeriod <value> ]

The ADL client process must generate diameter keep alive messages in the absence of traffic. The period laid down by the standard (Tw) for this procedure is 30 seconds. In some deployments it may be a higher value (such as one minute). It is set in milliseconds (the standard would be 30000, which is the default value of this optional parameter).

Parameter [ --reconnectionPeriod <value> ]

When a diameter connection is broken or simply initial connect fails, a periodic retry procedure, with a default time of 10 seconds (10000), is established. Failing on successive retries, the recovery process will continue indefinitely. There must be a commitment to establishing its order of magnitude in the case of expect systematic failures in certain target entities. Keep in mind that each retry process locks a single thread during the time provided in the tcpConnectDelay parameter.

Parameter [ --cer <value> ]

The ADL process automatically builds a CER message to establish the diameter protocol in client mode. This takes data such as the hostname, realm, host ip, etc. However, we can configure a specific CER for our application simply by creating a file in xml format and passing it as optional parameter. Omitting this parameter, as stated above, leads to the internal construction of a CER by default which in most environments gives no integration problem.

Parameter [ --dwr <value> ]

Similarly to the case of CER, the DWR message for keep alive the procedure can also be constructed as in xml format, indicating to the process the path file to read and encode.

Parameter [ --originHost <value> ]

The process defaults to 'hostname' of the operating system with this parameter unless otherwise stated. This can be useful for the internal construction of CER/DWR by default, when no xml is created for them.

Parameter [ --originRealm <value> ]

The process defaults to the 'domain name' from operating system with this parameter unless otherwise stated. This can be useful for the internal construction of CER/DWR by default, when no xml is created for them.

Parameter [ --integrationAndDebugging ]

The encoding engine has two configurations to manage validation. Firstly validation mode sets when said validation is performed: after decoding a message, before coding a message constructed by the application, in both cases, or never (optimization). By default, the engine only validates the decoded messages, but in the development phase is interesting validate messages that the application builds. Here, the parameter integrationAndDebugging fixes 'Always' as validation mode.
Moreover, there is what is called depth validation. There are two options: first error and complete validation. In the first case the validation stops on an error by throwing any exception. Possible future problems will not be known. Total or complete validation does warning level dump with all the anomalies found. In case of analyzing a request, the Failed-AVP and Result-Code, and other basic AVPs for response is constructed during the course set by the validation depth (with 'Complete' we could reach several AVPs within the failed-AVP internally created, although the Result-Code shall correspond to the first error encountered in validation or even during preprocessing). By default, the engine sets the type 'FirstError'. The integrationAndDebugging parameter is set to 'Complete' to facilitate integration testing with other systems and to thoroughly analyze any problem.

In summary, the integrationAndDebugging parameter sets the validation mode as 'Always' and depth as 'Complete'.

Parameter [ --ignoreErrors ]

The ANNA::diameter stack optionally builds an automatic response to the case of anomalies in the analysis of a request. AVPs as the Result-Code, Failed-AVP, etc. are built transparently during decoding and/or validation of the request. The answer is completed in accordance with standard RFC 6733 Section 6.2.

The ADL process can be configured using this parameter to ignore this analysis and answer accordingly from the side of local server based on the programmed responses. Under normal conditions (absence of this parameter), when an ADL in server mode receives an incorrect request will automatically respond with the basic information indicating the detected error. This would happen even if there is scheduled responses, to avoid inconsistencies (correct programmed response to a request that could be wrong), but you can always set this parameter to prioritize responses map of internal programming. In the case of having a client side (entity configured), requests are forwarded regardless of quality, ie no protocol analysis is performed delegating this task to the remote end point:

[sent2e]
<message version="1" name="AA-Request" application-id="0" hop-by-hop-id="0" end-by-end-id="0">
   <avp name="Session-Id" data="ocs3;1332909618;0;1332909618"/>
   <avp name="Auth-Application-Id" data="16777236"/>
   <avp name="Origin-Realm" data="OCS3"/>
   <avp name="Destination-Realm" data="PCRF"/>
   <avp name="Subscription-Id">
      <avp name="Subscription-Id-Type" data="15"/>
      <avp name="Subscription-Id-Data" data="606024200"/>
   </avp>
</message>

[recvfe]
<message version="1" name="AA-Answer" application-id="0" hop-by-hop-id="0" end-by-end-id="0">
   <avp name="Session-Id" data="ocs3;1332909618;0;1332909618"/>
   <avp name="Origin-Host" data="ocs2dfed1"/>
   <avp name="Origin-Realm" data="(none)"/>
   <avp name="Result-Code" data="5005" alias="DIAMETER_MISSING_AVP"/>
   <avp name="Failed-AVP">
      <avp name="Origin-Host" data/>
      <avp name="Subscription-Id-Type" data="15"/>
   </avp>
</message>

This parameter is also very useful when it is not known a priori stack to implement, but you want to program behavior responses to certain requests according to a pcap of production, that is, when you want to mimic flow captured for a particular scenario. Normally the battery is fully configured to facilitate tracing and interpretation of traffic, but if not known, the simulator can work perfectly abstracting the meaning of the received message and relaying on the hexadecimal content that has been programmed. It is sufficient to obtain the raw messages and decode them to get the xml representation that is more or less understandable in terms of the completeness of the application part in the dictionary definition.

Parameter [ --fixMode <value> ]

Defines behaviour mode regarding when to fix a message: before encoding (by default, if this optional parameter is missing or unreconized value is provided), after decoding, always or never. Values are: BeforeEncoding, AfterDecoding, Always, Never. An application could add Avps in any order; the fix procedure try to adjust it regarding dictionary. I.e., fixed Avps will be placed on first position, before mandatory and optional ones, within the message level or any grouped Avp. Usually we need to configure fixing before encoding in order to provide flexibility to the application during message construction, but actually, optimal mode implies disabling this procedure. Fixing after decoding will hide any validation problem regarding Avps position at any level.

Context dump

As in any ANNA process, we can cause a dump context sending the signal '-10' (SIGUSR1) to the process.
The context will be dumped to the file '/var/tmp/anna.context.<PID>' in xml format which greatly facilitates the understanding and classification of the information displayed.
Press here for an example of context dump of ADL configured as a client towards two diameter servers.
As we will see later, a context dump operation over the management interface is also supported, which allows to specify the target file where the information is dumped.

Hexadecimal content

By default, ANNA suite works with an hexadecimal readable format which consists in hexadecimal octets one behind the other without separators. For example: 6762672e61636973696f6e2e636f6d3b3432313431313b31303030. This applies to xml fields which are not being deeply decoded, and it also shall be used in the hex files used to be decoded as we will see in the following explanations. Anyway, hex files (with such hex readable content) as an input, could have the colon separator: 67:62:67:2e:61:63:69:73:69:6f:6e:2e:63:6f:6d:3b:34:32:31:34:31:31:3b:31:30:30:30. Both representations are well interpreted by the process. However, the xml fields containing hex data, will shown the colon-free format, which is more compact.

HTTP management operations

The typical stuff in a test directory of an ADL process, are scripts to launch requests, responses programming support, help & support, operations, etc. Virtually all scripts look because they rely on curl linux command to make a connection to the process http interface in order to perform a certain operation. These scripts help you to use this interface and abstract the user to the specific syntax of the content (body) for http message. In any case, we will start with a detailed explanation of such operations to understand the magnitude and operational capacity of the ADL. The scripts are provided in the full deployment (see script 'DEPLOY.sh' on the './examples/diameter/launcher' directory) and are based on dynamic hidden data that are configured according to the model (data routing, ports, launch options, etc.).

The process help focuses on management operations, since everything related to the parameterization of the command line (described in the previous points) displays as we know, running without arguments (or with incorrect arguments that do not cover the definition of all mandatory required ones). Such assistance is not delivered as a readme or similar, but is harcoded and accessible in two different ways: by traces on informational level (visible in debug or informational level, but not visible in warning level), and shown in the process stddout (nohup.out if any) when the operation "help" is sent to the http interface (eg using curl it would be curl -m 1 --data "help" localhost:9000). The traces are dumped in the process startup and when the http help operation is sent.

Let's see the help shown when run that operation:

myuser@myhostname:~/ADL-lite$ ./operation.sh help

                     ------------- HELP -------------

OVERVIEW
--------

The ADL (ANNA Diameter Launcher) process is a complete diameter agent with client and server
 capabilities as well as balancer (proxy) features. It could be used as diameter server
 (i.e. to simulate PCRF nodes, OCS systems, etc.), as diameter client (GGSNs, DPIs, etc.),
 and balancer systems to provide failover to external round-robin launchers. Also, auxiliary
 encoder/decoder/loader function could be deployed to reinterpret certain external flow and
 send it to another process.

The ANNA::diameter_comm built-in module provides a great set of characteristics as multiple connections
 on both server and client side, definition for multiple-server entities (and not only two as standard
 establish as minimum), separate statistics analyzer per each resource, automatic CER/CEA and DWR/DWA
 generation, expiration control and many more features.

Process traces are dump on "launcher.trace" and could have any trace level (POSIX levels), usually
 'debug' or 'warning'. See ANNA documentation for more details.

As any other ANNA process, context dump could be retrieved sending SIGUSR1 signal:
   kill -10 <pid>
    or
   kill -s SIGUSR1 <pid>
    and then
   vi /var/tmp/anna.context.<pid>

A complete xml report will show all the context information (counters, alarms, statistics,
 handlers, diameter dictionary, etc.), and a powerful log module could dump all the events
 processed and flow information. Statistics could be analized at context dump and optionally
 written to disk as sample files (useful for graphs and spreadsheet reports) with all the
 measurements.

Also SIGUSR2 is handled for management purposes. We will talk later about this.

COMMAND LINE
------------

Start the launcher process without arguments in order to see all the startup configuration
 posibilities, many of which could be modified on the air through the management interface
 (we will talk later about this great feature). Some of the more common parameters are:

As mandatory, the stack definition given through the xml dictionary:
   -dictionary <path to dictionary file>

Acting as a diameter server (accepting i.e. 10 connections), you would have:
   -diameterServer localhost:3868 -diameterServerSessions 10 -entityServerSessions 0

Acting as a diameter client (launching i.e. 10 connections to each entity server), you would have:
   -entity 192.168.12.11:3868,192.168.12.21:3868 -entityServerSessions 10 -diameterServerSessions 0

If you act as a proxy or a translation agent, you need to combine both former setups, and probably
 will need to program the answers to be replied through the operations interface. To balance the
 traffic at your client side you shall use '-balance' and '-sessionBasedModelsClientSocketSelection'
 arguments in order to define the balancing behaviour.

The process builds automatically CER and DWR messages as a client, but you could specify your own
 customized ones using '-cer <xml message file>' and '-dwr <xml message file>'.
The process builds automatically CEA and DWA messages as a server, but you could program your own
 customized ones using operations interface.

DYNAMIC OPERATIONS
------------------

ADL supports several operations which could be reconized via HTTP interface or SIGUSR2 caugh.
An operation is specified by mean a string containing the operation name and needed arguments
 separated by pipes. These are the available commands:

--------------------------------------------------------------------------------------- General purpose

help                                 This help. Startup information-level traces also dump this help.

------------------------------------------------------------------------------------ Parsing operations

code|<source_file>|<target_file>     Encodes source file (pathfile) into target file (pathfile).
decode|<source_file>|<target_file>   Decodes source file (pathfile) into target file (pathfile).
loadxml|<source_file>                Reinterpret xml source file (pathfile).

------------------------------------------------------------------------------------------- Hot changes

diameterServerSessions|<integer>     Updates the maximum number of accepted connections to diameter
                                      server socket.
context|[target file]                Application context could also be written by mean this operation,
                                      and not only through SIGUSR1. If optional path file is missing,
                                      default '/var/tmp/anna.context.<pid>' will be used.
collect                              Reset statistics and counters to start a new test stage of
                                      performance measurement. Context data can be written at
                                      '/var/tmp/anna.context.<pid>' by mean 'kill -10 <pid>'
                                      or sending operation 'context|[target file]'.
forceCountersRecord                  Forces dump to file the current counters of the process.

<visibility action>|[<address>:<port>]|[socket id]

       Actions: hide, show (update state) and hidden, shown (query state).
       Acts over a client session for messages delivery (except CER/A, DWR/A, DPR/A).
       If missing server (first parameter) all applications sockets will be affected.
       If missing socket (second parameter) for specific server, all its sockets will be affected.

       All application client sessions are shown on startup, but standard delivery only use primary
        server ones except if fails. Balance configuration use all the allowed sockets. You could also
        use command line 'sessionBasedModelsClientSocketSelection' to force traffic flow over certain
        client sessions, but for this, hide/show feature seems easier.

--------------------------------------------------------------------------------------- Flow operations

sendxml2e|<source_file>    Sends xml source file (pathfile) through configured entity.
sendxml2c|<source_file>    Sends xml source file (pathfile) to client.
sendxml|<source_file>      Same as 'sendxml2e'.
answerxml2e|[source_file]  Answer xml source file (pathfile) for incoming request with same code from entity.
                           The answer is stored in a FIFO queue for a specific message code, then there are
                           as many queues as different message codes have been programmed.
answerxml2c|[source_file]  Answer xml source file (pathfile) for incoming request with same code from client.
                           The answer is stored in a FIFO queue for a specific message code, then there are
                           as many queues as different message codes have been programmed.
answerxml|[source_file]    Same as 'answerxml2c'.
answerxml(2e/2c)           List programmed answers (to entity/client) if no parameter provided.
answerxml(2e/2c)|dump      Write programmed answers (to entity/client) to file 'programmed_answer.<message code>.<sequence>',
                           where 'sequence' is the order of the answer in each FIFO code-queue of programmed answers.
answerxml(2e/2c)|clear     Clear programmed answers (to entity/client).
answerxml(2e/2c)|exhaust   Disable the corresponding queue rotation, which is the default behaviour.
answerxml(2e/2c)|rotate    Enable the corresponding queue rotation, useful in performance tests.
                           Rotation consists in add again to the queue, each element retrieved for answering.

Send operations are available using hexadecimal content (hex formatted files) which also allow to test
special scenarios (protocol errors):

sendhex2e|<source_file>    Sends hex source file (pathfile) through configured entity.
sendhex2c|<source_file>    Sends hex source file (pathfile) to client.
sendhex|<source_file>      Same as 'sendhex2e'.

Answer programming in hexadecimal is not really neccessary (you could use send primitives) and also
 is intended to be used with decoded messages in order to replace things like hop by hop, end to end,
 subscriber id, session id, etc. Anyway you could use 'decode' operation and then program the xml created.

If a request is received, answer map (built with 'answerxml<[2c] or 2e>' operations) will be
 checked to find a corresponding programmed answer to be replied(*). If no ocurrence is found,
 or answer message was received, the message is forwarded to the other side (entity or client),
 or nothing but trace when no peer at that side is configured. Answer to client have sense when
 diameter server socket is configured, answer to entity have sense when entity does.

In the most complete situation (process with both client and server side) there are internally
 two maps with N FIFO queues, one for each different message code within programmed answers.
One map is for answers towards the client, and the other is to react entity requests. Then in
 each one we could program different answers corresponding to different request codes received.

(*) sequence values (hop-by-hop and end-to-end), Session-Id and Subscription-Id avps, are mirrored
    to the peer which sent the request. If user wants to test a specific answer without changing it,
    use sendxml/sendhex operations better than programming.

Balance ('-balance' command line parameter) could be used to forward server socket receptions through
 entity servers by mean a round-robin algorithm. Both diameter server socket and entity targets should
 have been configured, that is to say: launcher acts as client and server. If no balance is used, an
 standard delivery is performed: first primary entity server, secondary when fails, etc.

--------------------------------------------------------------------------- Processing types (log tags)

Used as log file extensions (when '-splitLog' is provided on command line) and context preffixes on log
 details when unique log file is dumped:

   [sent2e/send2eError]   Send to entity (success/error)
   [sent2c/send2cError]   Send to client (success/error)
   [fwd2e/fwd2eError]     Forward to entity a reception from client (success/error)
   [fwd2c/fwd2cError]     Forward to client a reception from entity (success/error)
   [recvfc]               Reception from client
   [recvfe]               Reception from entity
   [req2c-expired]        A request sent to client has been expired
   [req2e-expired]        A request sent to entity has been expired
   [recvfc-ans-unknown]   Reception from client of an unknown answer (probably former [req2c-expired]
                           has been logged)
   [recvfe-ans-unknown]   Reception from entity of an unknown answer (probably former [req2e-expired]
                           has been logged)
   [retry]                Request retransmission

-------------------------------------------------------------------------------------------- Load tests

burst|<action>|[parameter]     Used for performance testing, we first program diameter requests
                                messages in order to launch them from client side to the configured
                                diameter entity. We could start the burst with an initial load
                                (non-asynchronous sending), after this, a new request will be sent
                                per answer received or expired context. There are 10 actions: clear,
                                load, start, push, pop, stop, repeat, send, goto and look.

   burst|clear                 Clears all loaded burst messages.
   burst|load|<source_file>    Loads the next diameter message into launcher burst.
   burst|start|<initial load>  Starts (or restarts if already in progress) the message sending with
                                a certain initial load.
   burst|push|<load amount>    Sends specific non-aynchronous load.
   burst|pop|<release amount>  Skip send burst messages in order to reduce over-the-air requests.
                               Popping all OTA requests implies burst stop because no more answer
                                will arrive to the process. Burst output file (-burstLog command
                                line parameter) shows popped messages with crosses (x). Each cross
                                represents one received answer for which no new request is sent.
   burst|stop                  Stops the burst cycle. You can resume pushing 1 load amount.
   burst|repeat|[[yes]|no]     Restarts the burst launch when finish. If initial load or push load
                                amount is greater than burst list size, they will be limited when
                                the list is processed except when repeat mode is enabled.
   burst|send|<amount>         Sends messages from burst list. The main difference with start/push
                                operations is that burst won't be awaken. Externally we could control
                                sending time (no request will be sent for answers).
   burst|goto|<order>          Updates current burst pointer position.
   burst|look|<order>          Show programmed burst message for order provided.

USING OPERATIONS INTERFACE
--------------------------

------------------------------------------------------------------------- Operations via HTTP interface

All the operations described above can be used through the optional HTTP interface. You only have
 to define the http server at the command line with something like: '-httpServer localhost:9000'.
To send the task, we shall build the http request body with the operation string. Some examples
 using curl client could be:

   curl -m 1 --data "diameterServerSessions|4" localhost:9000
   curl -m 1 --data "code|ccr.xml" localhost:9000
   curl -m 1 --data "decode|ccr.hex" localhost:9000
   curl -m 1 --data "sendxml2e|ccr.xml" localhost:9000
   etc.

------------------------------------------------------------------------- Operations via SIGUSR2 signal

The alternative using SIGUSR2 signal requires the creation of the task(s) file which will be read at
 signal event:
   echo "<<operation>" > ./sigusr2.tasks.input
    then
   kill -12 <pid>
    or
   kill -s SIGUSR2 <pid>
    and then see the results:
   cat ./sigusr2.tasks.output

You could place more than one line (task) in the input file. Output reports will be appended in that
 case over the output file. Take into account that all the content of the task file will be executed
 sinchronously by the process. If you are planning traffic load, better use the asynchronous http
 interface.

As we have seen before, there is an alternative to the management via HTTP (which is actually optional): management by mean SIGUSR2 signal capture. Here are one by one, all available operations that can be applied to any of the two methods. Each of the sections will refer to an operation, so that for a section called "Operation xxxx", the way they would be thrown is: curl -m 1 --data "xxxx" localhost: 9000 or echo "xxxx"> sigusr2.tasks.input; SIGUSR2 kill -s <pid>.

Operation help

As seen above, this causes the screen dump and trace (level information) with help support.

Operation code|<source_file>|<target_file>

Operation of parsing category, encoding a source file on a file destination. Generally the source file has xml extension (which is its format) and the result is an readable representation of the hexadecimal content. The extension .hex is recommended for the target file. That extension is asummed to the content in coded form:

An encoded cer.xml could be:

myuser@myhostname:~/ADL-lite$ cat dwr.xml
<message version="1" name="Device-Watchdog-Request" application-id="0">
   <avp name="Origin-Host" data="pstelbe1.telefonica.mbbi.com.ar"/>
   <avp name="Origin-Realm" data="telefonica.mbbi.com.ar"/>
</message>

myuser@myhostname:~/ADL-lite$ code.sh dwr.xml

Operation processed; File 'dwr.xml.hex' created.
myuser@myhostname:~/ADL-lite$ cat dwr.xml.hex
0100005c800001180000000000000000000000000000010840000027707374656c6265312e74656c65666f6e6963612e6d6262692e636f6d2e617200000001284000001e74656c65666f6e6963612e6d6262692e636f6d2e61720000

Operation decode|<source_file>|<target_file>

Operation inverse to the encoding. Again, the script for decoding an encoded file to be transformed into xml format, is provided.

myuser@myhostname:~/ADL-lite$ decode.sh dwr.xml.hex

Operation processed; File 'dwr.xml.hex.xml' created.
myuser@myhostname:~/ADL-lite$ cat dwr.xml.hex.xml
<message version="1" name="Device-Watchdog-Request" application-id="0" hop-by-hop-id="0" end-by-end-id="0">
   <avp name="Origin-Host" data="pstelbe1.telefonica.mbbi.com.ar"/>
   <avp name="Origin-Realm" data="telefonica.mbbi.com.ar"/>
</message>

Operation loadxml|<source_file>

It may seem not useful, but becomes important when we want to know how to interpret by our stack a given xml when there are inconsistencies in the flags. Suppose you have started the ADL process in xml compact mode (remember the ignoreFlags parameter):

myuser@myhostname:~/ADL-lite$ cat dwr2.xml
<message version="1" name="Device-Watchdog-Request" application-id="0">
   <avp code="264" flags="0" vendor-code="0" data="pstelbe1.telefonica.mbbi.com.ar"/>
   <avp name="Origin-Realm" data="telefonica.mbbi.com.ar"/>
</message>

myuser@myhostname:~/ADL-lite$ loadXml.sh  dwr2.xml

<message version="1" name="Device-Watchdog-Request" application-id="0" hop-by-hop-id="0" end-by-end-id="0">
   <avp name="Origin-Host" data="pstelbe1.telefonica.mbbi.com.ar"/>
   <avp name="Origin-Realm" data="telefonica.mbbi.com.ar"/>
</message>

Operation processed; Message 'dwr2.xml' loaded.

If instead we started in strict mode:

myuser@myhostname:~/ADL-lite$ loadXml.sh  dwr2.xml

<message version="1" name="Device-Watchdog-Request" application-id="0" hop-by-hop-id="0" end-by-end-id="0">
   <avp code="264" vendor-code="0" flags="0" data="pstelbe1.telefonica.mbbi.com.ar"/>
   <avp name="Origin-Realm" data="telefonica.mbbi.com.ar"/>
</message>

Operation processed; Message 'dwr2.xml' loaded.

This Operation just be worth testing to validate xml (although this can be done using a generic XML editor, or xmllint, etc.):

myuser@myhostname:~/ADL-lite$ cat dwrBad.xml
<message version="1" name="Device-Watchdog-Request" application-id="0">
   <avp NNNName="Origin-Host" data="pstelbe1.telefonica.mbbi.com.ar"/>
   <avp name="Origin-Realm" data="telefonica.mbbi.com.ar"/>
</message>

myuser@myhostname:~/ADL-lite$ loadXml.sh dwrBad.xml

Operation processed with exception. See traces
myuser@myhostname:~/ADL-lite$ grep Exception launcher.trace
[10/05/2012 23:19:08] Error | xml.DTD.cc (85) | RuntimeException | XML Document: dwrBad.xml | Does not comply the DTD especification

Operation diameterServerSessions|<integer>

Regardless of the number of accepted connections by the process on the server side, that are configured on command line, we can change this information on the air. Obviously, the operation will fail if we set a smaller number to the number of current connections, since this dynamic configurability will never cause accidental socket disconnections if already established. In the context of a testing process, perhaps not a very attractive feature, since it is unlikely needed to scale such resources in this context (the process would stop and start reconfigured with the necessary data), but attests an inherent capacity in diameter::ANNA::comm communications engine, which is interesting in a process deployed in production (scalability could be applied without changing the number of instances of the process and therefore without touching the service configuration).
This command can even be used to "wake up" an ADL process server started without diameter (-diameterServer <server> -diameterServerSessions 0), no more than provide a positive factor for the number of connections.

Operation collect

This operation resets the statistical and process counters. It is useful to establish a new control point for data collection. In this sense, it would have been more appropriate to call it "reset" or "reset_stats" but his name rather is due to the fact that it is mainly used when coordinating data collection stages (for example, high availability: before/during/after a certain contingency).

This command can be combined with a context dump, trace cleaning, and data collection, in a series of steps for analyzing a test phase.
Using a collect.sh script (containing something like curl -m 1 --data "collect" localhost: 9000), we could have:

Start of data collection (stage):

# Restart
rm /var/tmp/anna.context.* *.csv *.log *.trace 2>/dev/null
./collect.sh
date > ./RESULT/fecha_ini.txt

Ending data collection (stage):

#!/bin/ksh
date > ./RESULT/fecha_fin.txt

# Context:
PID=`ps -fea|grep ADL-PROCESS | grep -v grep | awk '{ print $2 }'`
kill -10 $PID
sleep 1
mv /var/tmp/anna.context.* ./RESULT
mv *.csv ./RESULT 2>/dev/null
mv *.log ./RESULT 2>/dev/null
mv *.trace ./RESULT 2>/dev/null

The context dump is the most useful, and thanks to performing the reset collect.sh, reliable measures will not be marred with data from adjacent stages, both counters (accumulated that appear with the keyword accumulated), such as the rate of statistical values (shown as vps). For example:

myuser@myhostname:~/ADL-lite$ grep Accumulated /var/tmp/anna.context.08713
               <Counter Type="0" Description="RequestReceived" ScopeId="1" Offset="0" RealId="1000" AccumulatedAmount="427"/>
               <Counter Type="1" Description="AnswerReceived" ScopeId="1" Offset="1" RealId="1001" AccumulatedAmount="430"/>
               <Counter Type="3" Description="AnswerReceivedOnClientSession" ScopeId="1" Offset="3" RealId="1003" AccumulatedAmount="430"/>
               <Counter Type="4" Description="RequestReceivedOnServerSession" ScopeId="1" Offset="4" RealId="1004" AccumulatedAmount="427"/>
               <Counter Type="6" Description="RequestSentOK" ScopeId="1" Offset="6" RealId="1006" AccumulatedAmount="430"/>
               <Counter Type="8" Description="AnswerSentOK" ScopeId="1" Offset="7" RealId="1007" AccumulatedAmount="427"/>
               <Counter Type="10" Description="RequestSentOnClientSessionOK" ScopeId="1" Offset="10" RealId="1010" AccumulatedAmount="430"/>
               <Counter Type="12" Description="AnswerSentOnClientSessionOK" ScopeId="1" Offset="12" RealId="1012" AccumulatedAmount="427"/>
               <Counter Type="27" Description="CERReceived" ScopeId="1" Offset="27" RealId="1027" AccumulatedAmount="1"/>
               <Counter Type="28" Description="CEASentOK" ScopeId="1" Offset="28" RealId="1028" AccumulatedAmount="1"/>
               <Counter Type="30" Description="DWRSentOK" ScopeId="1" Offset="21" RealId="1021" AccumulatedAmount="7"/>
               <Counter Type="32" Description="DWAReceived" ScopeId="1" Offset="23" RealId="1023" AccumulatedAmount="7"/>
               <Counter Type="33" Description="DWRReceived" ScopeId="1" Offset="30" RealId="1030" AccumulatedAmount="3"/>
               <Counter Type="34" Description="DWASentOK" ScopeId="1" Offset="31" RealId="1031" AccumulatedAmount="3"/>
               <Counter Type="42" Description="ServerSocketsOpened" ScopeId="1" Offset="36" RealId="1036" AccumulatedAmount="1"/>
               <Counter Type="43" Description="ServerSocketsClosed" ScopeId="1" Offset="37" RealId="1037" AccumulatedAmount="1"/>

myuser@myhostname:~/ADL-lite$ grep vps /var/tmp/anna.context.08713
                                 <Data Size="211" Average="73.13" StandardDeviation="46.00" BesselStandardDeviation="46.11" ProcessingRate="1.55 vps (values per second)">
                                 <Data Size="214" Average="320.36" StandardDeviation="30.57" BesselStandardDeviation="30.64" ProcessingRate="1.57 vps (values per second)">
                                 <Data Size="212" Average="70.44" StandardDeviation="49.14" BesselStandardDeviation="49.25" ProcessingRate="1.56 vps (values per second)">
                                 <Data Size="216" Average="319.19" StandardDeviation="35.05" BesselStandardDeviation="35.13" ProcessingRate="1.59 vps (values per second)">
                           <Data Size="427" Average="1209.47" StandardDeviation="108.31" BesselStandardDeviation="108.44" ProcessingRate="3.14 vps (values per second)">

Operación forceCountersRecord

This operation forces the counters dump although no counter period has expired. It is useful if you don't want to wait such counters dump period. If the process was started and we are going to execute a controlled test case, it would be convenient to reset the counters at the test beginning by mean the former commented operation collect.

Operation <visibility action>|[<address>:<port>]|[socket id]

The ADL process client mode allow to configure the visibility of sockets for delivery. This means that although the sockets are always available online to keep alive when appropriate, or establishment protocol by CER/CEA when they reconnect or connect for the first time, there is a logic state of activation/deactivation for application messages. This feature allows you to filter in real time, the delivery routes from a traffic load for testing to certain instances or front-ends.

Scenarios could be prepared with specific Session-Id to make something like that through the mechanism of selective delivery (remember sessionBasedModelsClientSocketSelection) but are much simpler disable sockets that do not want to use.

Visualization operations are divided into two types: the query (shown/hidden) and update (show/hide), consisting respectively of querying and updating the active/inactive state of an element.

As an argument (target element), we have two optional parts, the server and the socket identifier within that server. If the latter is not provided, all server sockets will be affected by the operation. If not specified the server then affected all servers in the destination entity (the only) configured on the ADL process.

When you start the process, all sockets are active (even if we have not activated balancing, delivery will, under normal conditions, only the primary server).

Operation sendxml2e|<source_file>

This Operation is used to send to the entity and xml format diameter message. The process should be client a to use it, and delivery resources will be selected based on established algorithms and the availability of remote elements.

For sending a request, it will automatically become part of the context of the process until the corresponding response or an expiration of the pending context it is received.

The ADL process also supports natively (in ANNA::diameter module) automatically managing the DPR/DPA procedure, whereby the DPR (Disconnect-Peer-Request) is a message that can also be sent through this Operation to initiate a disconnection procedure.

Example of use through a script:

myuser@myhostname:~/ADL-lite$ sendXml.sh  aar.xml

Operation processed; Message 'aar.xml' sent to entity.
myuser@myhostname:~/ADL-lite$ cat launcher.log
[send2e]
<message version="1" name="AA-Request" application-id="0" hop-by-hop-id="10" end-by-end-id="2">
   <avp name="Session-Id" data="ocs3;1332909618;0;1332909618"/>
   <avp name="Auth-Application-Id" data="16777236"/>
   <avp name="Origin-Host" data="OCS3"/>
   <avp name="Origin-Realm" data="OCS3"/>
   <avp name="Destination-Realm" data="PCRF"/>
   <avp name="Subscription-Id">
      <avp name="Subscription-Id-Type" data="0" alias="END_USER_E164"/>
      <avp name="Subscription-Id-Data" data="616279266"/>
   </avp>
</message>

Operation sendxml2c|<source_file>

Like 'sendxml2e' is a delivery operation. The difference is that the message is sent to the client, not to the entity (server). If more than one socket is set, round-robin will take place between sockets (server sessions).

Requests sent to a client also have their own control context, and similarly to the case of transmission to servers, can also initiate a disconnection procedure by a DPR.

The script for the delivery is the same, but a second optional parameter to '2c' (to client) is added: sendXml.sh <message> 2c

Operation sendxml|<source_file>

Same as sendxml2e. The script could also be invoked thus: sendXml.sh <message> 2e. Although actually the second parameter '2e' (to entity) can be omitted, since the default is for sendings to servers, which is the normal thing.

Operation answerxml2c|[source_file]

The process can be programmed to respond to certain requests.
There are internal FIFO queues for the different message codes programed, that is to say, if we program two AA-Anwers (code=265) and one CC-Answer (code=272), then there will be one FIFO queue for code 265 and another one for code 272. The first one will have two messages, and the second, one. When the process receives a request with certain code, it will pop the next answer from the corresponding FIFO queue. Then, if we receive a CC-Request, its FIFO queue will be empty after sending the answer, and if we receive a AA-Request, then its FIFO queue will keep still one answer of this type because it had two AA-Answers programmed.

The process only reacts to requests (if answer comes, nothing is done). You can program in any moment if you need to coordinate or have a better control, but in general this feature is used to replay previously recorded diameter flows and then, we know the answers first of all. The FIFO differenciation is enough to give full control of the interactivity.

The hop-by-hop and end-to-end, are automatically transferred from the request received to the answer delivered. The session-id is also automatically propagated, and if any Subscription-Id AVPs, also move.

Operation answerxml2e|[source_file]

This Operation is similar to above. The difference is that the answers are scheduled to possible requests from the entity (server).

Operation answerxml|[source_file]

Equivalent to answerxml2c.

Operation answerxml without arguments

When no arguments are provided, a list of programmed answers will be shown on stdout.

myuser@myhostname:~/ADL-lite$ cat sigusr2.tasks.input 
answerxml2e
myuser@myhostname:~/ADL-lite$ kill -s SIGUSR2 <pid>

          ------------- CURRENT PROGRAMMED ANSWERS TO ENTITY -------------

================================================================================
                                 Answer code 265                                
================================================================================
<message version="1" name="AA-Answer" application-id="16777236" hop-by-hop-id="202475" end-by-end-id="509476">
   <avp name="Auth-Application-Id" data="16777236"/>
   <avp name="Session-Id" data="test1;afNodeHostname.afNodeHostRealm.com;1;8033450"/>
   <avp name="Origin-Host" data="sapcOwnHostId.operatorRealm.com"/>
   <avp name="Origin-State-Id" data="11111"/>
   <avp name="Origin-Realm" data="operatorRealm.com"/>
   <avp name="Experimental-Result">
      <avp name="Vendor-Id" data="10415"/>
      <avp name="Experimental-Result-Code" data="5063"/>
   </avp>
</message>

<message version="1" name="AA-Answer" application-id="16777236" hop-by-hop-id="202475" end-by-end-id="509476">
   <avp name="Auth-Application-Id" data="16777236"/>
   <avp name="Session-Id" data="test1;afNodeHostname.afNodeHostRealm.com;1;8033450"/>
   <avp name="Origin-Host" data="sapcOwnHostId.operatorRealm.com"/>
   <avp name="Origin-State-Id" data="22222"/>
   <avp name="Origin-Realm" data="operatorRealm.com"/>
   <avp name="Experimental-Result">
      <avp name="Vendor-Id" data="10415"/>
      <avp name="Experimental-Result-Code" data="5063"/>
   </avp>
</message>

Operation answerxml(2e|2c)|dump

With this operation, all the programmed answers are written to disk in xml format:

myuser@myhostname:~/ADL-lite$ echo "answerxml2e|dump" sigusr2.tasks.input 
myuser@myhostname:~/ADL-lite$ kill -s SIGUSR2 <pid>
myuser@myhostname:~/ADL-lite$ ls programmed_answer.*
programmed_answer.265.1.xml  programmed_answer.265.2.xml

Operation answerxml(2e|2c)|clear

This command will flush all the programmed answers for all the different code-FIFO queues programmed, regardless if they are queues to react against entities or clients when proceed (if the process is configured as client and server it will have both types).

Operation answerxml(2e|2c)|exhaust

The queue is by default exhausted when all the corresponding requests has been received. You could configure the queue to automatically rotate, but by default this rotation is disabled.

Operation answerxml(2e|2c)|rotate

When queue rotation is enabled, each answer which reacts a incoming requets, is added again to the queue in a infinite loop of answering. This could be useful on performance testing.

Send operations based on hexadecimal content

Similarly to sendxml2e|<source_file> (= sendxml|<source_file>) and sendxml2c|<source_file>, we have:

sendhex2e|<source_file>
sendhex2c|<source_file>
sendhex|<source_file> (same as sendhex2e)

All of them allow a higher flexibility than xml versions, because you could write a bad message to test protocol errors and other unexpected situations.

Operation burst|<action>|[parameter]

The Operation "burst" is specially designed for performance and stress testing, but also useful to sequence a set of scenarios with a rate controlled load. The different actions (first parameter) of operation burst offer a wide range of possibilities from a preprogrammed list (burst list). The idea is to load into memory requests to be launched, and then perform an action on the list. We can position ourselves and see what is in a point from the list, send N active requests (we'll see what this is) or N passive requests, etc.

The burst mode only works in client mode, as is the normal way to launch traffic from a diameter agent:

Action clear

Remove all the request loaded in the list.

Action load|<source_file>

Loads the file provided at the next position in the list. The burst.sh script, has an option of loading N elements, which below is done is to generate a message and load, N times. The order number is used to parameterize how the message is constructed. This depends on the type of billing, for example to generate SMS scenarios, being IEC is simple. An auxiliary sms.sh generates an SMS based on a template, for the given order. Then burst.sh script invokes the HTTP load operation. This is done N times, with N consecutive commands that form the list of messages for burst mode.
There is also a helper script called data.sh used to build data scenarios, more complex parameterized with a serial number, but quite possible. In general, sample scenarios of a real system and take one reference to be increasing as the subscriber data, sequence numbers, Session-Id, etc., is a prerequisite for the generation of these auxiliary scripts step. Parameterized through the load which can play back any environment of performance tests.

Action start|<initial load>

Start (or restart if already in progress) sending messages (provided load) of the burst list in order and in active mode. The active mode is that when the ADL process receives a response to a request or receive an expiration (which is a "virtual" response) gets the next item in the list and sends it. The active mode keeps constant the number of requests in the air (OTA request, this is over-the-air requets). If the initial charge is conveniently sized (assuming a fair distribution to the target servers, these will have a size of the receive queues based on the ratio between the number of servers and the initial charge launched) can calculate the number of messages in the air it will from the beginning, since the initial charge is sent to the principle of asynchronous manner, that is, without returning control to the communications module dealing activity of receive queues (that is, all sent at once when process operation). An initial load, "awakes" burst mode with an OTA equal to that load. This way, you get to "press" the server system to the maximum possible if the initial charge (OTA request) is sufficient to have no idleness on any destination server. As a new request is sent until a response (or expiration) is received, the queues are never increase as to increase levels of congestion (remains constant).

Requests in the air can be varied in real time, through the actions push and pop. The log for burst (remember burstLog parameter) displays each request sent with a symbol (.), and order within the burst list in each 1% of the total, with the current number of in-the-air requests when it changes. Messages for pop events are shown with a (x).

Action push|<load amount>

Injects a number of messages from the list, for no asynchronous delivery, increasing the number of requests in the air.
If we have a number of requests in the air equal to N, and make a push of P messages, behind the operation will have N+P in the air requests.

Action pop|<release amount>

Omit to make new requests for a number of responses received, reducing the number of requests in the air.
If we have a number of requests in the air equal to N, and make a pop of P messages, behind the operation we will have N-P in the air requests.
Perform a pop of all requests in the air (P greater than or equal to N) implies a cessation of deliveries, as they will not get more answers. Will be needed to make a start or a push to reactivate the steadily mode. The burst log shows the symbol x the pop messages (reception of events without sending the following request).

Operations push and pop allow fixing very easily, the congestion level of a receiving process. Suppose 30000 bytes queued for a level of congestion 3. If we have an average of 300 byes per request (this can be seen in the context dump in statistical calculations) means that when we have 100 messages in the receive queue for each server instance, will have reached that level. If the OCS awaits diameter servers with 4 instances, means that we inject charge to have OTA = 400 messages (assuming an equal distribution to each of the servers, then each will have 100 and therefore level 3 of congestion). We can launch an initial load of 400, or do it more gently, performing successive push operations to reach OTA = 400. The same applies to any other level of congestion, simply by calculating the number of messages that must let on the air on the side of OCS.

Action stop

Stop the process of sending in active mode. Answers may keep coming but will not cause new deliveries. You can resume doing a push.

Action repeat|[[yes]|no]

The burst list is finite. Suppose we have scheduled 2000 messages (500 data contexts of 4 requests: initial, update1, update2, termination). When the list is empty, the process ceases actively transmitting (equivalent to make a stop).

We can activate cycle mode, for the system to keep delivery cycle again and again. When the list is finished, it returns to the beginning, repeating again all scenarios. This can be useful to have maintained high load for a long period of time, unless we are willing to sacrifice some memory with a bigger list.

If we have not active the cyclic mode, and executes a push of N elements, lacking to the end of the list a number less than N, the push will be limited in the remaining margin. If we had repeated, would not be limited.

Action send|<amount>

Sends a number of messages from the list in passive mode, ie, unlike start or push, this delivery will not "wake up" automatic transmission at responses reception. We can externally control shipments from the list of scenarios and indeed, as we shall see, there is a script called burst.sh used to manage all the possible actions of this burst and especially using "sendXS" parameter that takes send N requests per second using a feedback control to stabilize and align the rate of loading.

Action goto|<order>

With this action we are positioned at a certain point in the list, providing the order number of message we want to prepare.

Action look|<order>

With this action we could look the xml message programmed at a certain point in the list, providing the order number of message.

Script burst.sh

One burst.sh script that facilitates the use of management commands of burst functionality.
When we launch this script without arguments, we obtain the following help:

Load tests configuration script

Use: ./burst.sh <action: clear | load | start | push | pop | stop | resume | repeat | send | goto | look> [action parameters]

     clear:
        Clears all loaded burst messages.

     load <amount> <traffic type: mms | sms | voice | data | content>:
        Loads 'amount' messages for the provided traffic type. For example:
           ./burst.sh load 2000 sms

     start [initial launch: default 1]:
        Starts the message sending from the begining of the burst list loaded,
        with a certain initial load. For example:
           ./burst.sh start 200

     push [amount: default 1]:
        Launch 'amount' messages as initial load does (non-asynchronous mode).
        It works even if burst launch is stopped. Useful to achieve congestion
        conditions. For example:
           ./burst.sh push 300

     pop [amount: default 1]:
        Skip send burst messages in order to reduce over-the-air requests.

     stop:
        Stops the burst cycle at the current position. It could affect sessions
        on the air (i.e. data contexts). Totally safe for IEC scenaries as SMS.

     resume:
        Resume an stopped burst launch from the same point (start will reset
        the work pointer to the first burst list position). This is equivalent
        to one-message-push operation.

     repeat [[yes] | no]:
        Restarts the burst launch cycle when finished.

     send [amount: default 1]:
        send messages from burst list. The main difference with start/push operations
        is that burst won't be awaken. Externally we could control sending time (no
        request will be sent for answers). When reach the last position, starts again.

     sendXS <requests per second> [amount: default -1 (no limit)]:
        send messages from burst list with the TPS provided. User could hot change
        speed by mean 'echo <TPS> > .tps' at another shell. You can stop the load
        removing that hidden file or using CTRL+C from the shell where you launched
        the burst command. Real tps is dumped on '.real_tps' file during testing.
        You could limit the amount of messages sent by mean the second parameter.
        No limit is established by default (-1 or negative value).

     goto <order>:
        Updates current burst pointer position.

     look <order>:
        Show programmed burst message for order provided.

Counters and alarms

In the context dump we can see the counters and alarms for each sub-module of the ADL process. There are two main modules: the encoding engine and communications engine. Each has a number of counters and alarms that generate the corresponding event when appropriate. The ADL process records no alarm, since it is not something that has an interest, or rather, no system (management element) expects these events to facilitate its evolution/display to the user. The alarms can be generated in the logging warning level of ADL process traces. Also counters, but also they increase the amount of memory in order to display it in the dump context when requested. The counters are very useful because they give a true and fair view of the program flow. There are many counters managed by ANNA::diameter, so the information is very detailed.

Generally, to see the counters quickly, usually make a grep Accumulated over context dump at the time of data collection. Thus only the counters that have increased at least once seen (since for them, the xml statistical section shows an "Accumulated" field in each event managed by the process, and that field does not appear (equals to zero) when there has never increased.

The communication engine, have also a counters module for application messages which are dynamically created/managed. If, for example, our process detects an application message with code 272 registered as "Credit-Control-Request / Credit-Control-Answer", automatically the following counters will be registered in the corresponding counter scope associated to the stack given by the message application-id:

      Credit-Control-Request_SentOK_AsClient
      Credit-Control-Request_SentNOK_AsClient
      Credit-Control-Answer_SentOK_AsClient
      Credit-Control-Answer_SentNOK_AsClient
      Credit-Control-Request_Received_AsClient
      Credit-Control-Answer_Received_AsClient
      Credit-Control-Answer_UnknownReceived_AsClient
      Credit-Control-Request_SentOK_AsServer
      Credit-Control-Request_SentNOK_AsServer
      Credit-Control-Answer_SentOK_AsServer
      Credit-Control-Answer_SentNOK_AsServer
      Credit-Control-Request_Received_AsServer
      Credit-Control-Answer_Received_AsServer
      Credit-Control-Answer_UnknownReceived_AsServer

If the request/answer description for the message code is unknown, the counter names would be something like:

      ApplicationMessageCode_272-Request_SentOK_AsClient
      ApplicationMessageCode_272-Request_SentNOK_AsClient
      ...

The capacity to register new dynamic counters, depends on the scope size (1000 at the moment) and the number of counter types implemented (14 at the moment).

Regarding static counters, this is the list of counters that under certain circumstances, the ADL process could increase:

   <oam.Module Name="diameter::comm oam module" Counters="Enabled" Alarms="Enabled" PreffixAlarmComponents="Shown" SuffixAlarmComponents="Shown">
      <RegisteredCounterScopes>
         <Scope Id="1" Description="diameter::comm oam module">
            <RegisteredCounters>
               <Counter Type="0" Description="RequestReceived" ScopeId="1" Offset="0" RealId="1000"/>
               <Counter Type="1" Description="AnswerReceived" ScopeId="1" Offset="1" RealId="1001"/>
               <Counter Type="2" Description="RequestReceivedOnClientSession" ScopeId="1" Offset="2" RealId="1002"/>
               <Counter Type="3" Description="AnswerReceivedOnClientSession" ScopeId="1" Offset="3" RealId="1003"/>
               <Counter Type="4" Description="RequestReceivedOnServerSession" ScopeId="1" Offset="4" RealId="1004"/>
               <Counter Type="5" Description="AnswerReceivedOnServerSession" ScopeId="1" Offset="5" RealId="1005"/>
               <Counter Type="6" Description="RequestSentOK" ScopeId="1" Offset="6" RealId="1006"/>
               <Counter Type="7" Description="RequestSentNOK" ScopeId="1" Offset="7" RealId="1007"/>
               <Counter Type="8" Description="AnswerSentOK" ScopeId="1" Offset="8" RealId="1008"/>
               <Counter Type="9" Description="AnswerSentNOK" ScopeId="1" Offset="9" RealId="1009"/>
               <Counter Type="10" Description="RequestSentOnClientSessionOK" ScopeId="1" Offset="10" RealId="1010"/>
               <Counter Type="11" Description="RequestSentOnClientSessionNOK" ScopeId="1" Offset="11" RealId="1011"/>
               <Counter Type="12" Description="AnswerSentOnClientSessionOK" ScopeId="1" Offset="12" RealId="1012"/>
               <Counter Type="13" Description="AnswerSentOnClientSessionNOK" ScopeId="1" Offset="13" RealId="1013"/>
               <Counter Type="14" Description="RequestSentOnServerSessionOK" ScopeId="1" Offset="14" RealId="1014"/>
               <Counter Type="15" Description="RequestSentOnServerSessionNOK" ScopeId="1" Offset="15" RealId="1015"/>
               <Counter Type="16" Description="AnswerSentOnServerSessionOK" ScopeId="1" Offset="16" RealId="1016"/>
               <Counter Type="17" Description="AnswerSentOnServerSessionNOK" ScopeId="1" Offset="17" RealId="1017"/>
               <Counter Type="18" Description="RequestSentExpired" ScopeId="1" Offset="55" RealId="1055"/>
               <Counter Type="19" Description="RequestSentOnClientSessionExpired" ScopeId="1" Offset="56" RealId="1056"/>
               <Counter Type="20" Description="RequestSentOnServerSessionExpired" ScopeId="1" Offset="57" RealId="1057"/>
               <Counter Type="21" Description="AnswerReceivedUnknown" ScopeId="1" Offset="58" RealId="1058"/>
               <Counter Type="22" Description="AnswerReceivedOnClientSessionUnknown" ScopeId="1" Offset="59" RealId="1059"/>
               <Counter Type="23" Description="AnswerReceivedOnServerSessionUnknown" ScopeId="1" Offset="60" RealId="1060"/>
               <Counter Type="24" Description="CERSentOK" ScopeId="1" Offset="18" RealId="1018"/>
               <Counter Type="25" Description="CERSentNOK" ScopeId="1" Offset="19" RealId="1019"/>
               <Counter Type="26" Description="CEAReceived" ScopeId="1" Offset="20" RealId="1020"/>
               <Counter Type="27" Description="CERReceived" ScopeId="1" Offset="27" RealId="1027"/>
               <Counter Type="28" Description="CEASentOK" ScopeId="1" Offset="28" RealId="1028"/>
               <Counter Type="29" Description="CEASentNOK" ScopeId="1" Offset="29" RealId="1029"/>
               <Counter Type="30" Description="DWRSentOK" ScopeId="1" Offset="21" RealId="1021"/>
               <Counter Type="31" Description="DWRSentNOK" ScopeId="1" Offset="22" RealId="1022"/>
               <Counter Type="32" Description="DWAReceived" ScopeId="1" Offset="23" RealId="1023"/>
               <Counter Type="33" Description="DWRReceived" ScopeId="1" Offset="30" RealId="1030"/>
               <Counter Type="34" Description="DWASentOK" ScopeId="1" Offset="31" RealId="1031"/>
               <Counter Type="35" Description="DWASentNOK" ScopeId="1" Offset="32" RealId="1032"/>
               <Counter Type="36" Description="DPRSentOK" ScopeId="1" Offset="24" RealId="1024"/>
               <Counter Type="37" Description="DPRSentNOK" ScopeId="1" Offset="25" RealId="1025"/>
               <Counter Type="38" Description="DPAReceived" ScopeId="1" Offset="26" RealId="1026"/>
               <Counter Type="39" Description="DPRReceived" ScopeId="1" Offset="33" RealId="1033"/>
               <Counter Type="40" Description="DPASentOK" ScopeId="1" Offset="34" RealId="1034"/>
               <Counter Type="41" Description="DPASentNOK" ScopeId="1" Offset="35" RealId="1035"/>
               <Counter Type="42" Description="ServerSocketsOpened" ScopeId="1" Offset="36" RealId="1036"/>
               <Counter Type="43" Description="ServerSocketsClosed" ScopeId="1" Offset="37" RealId="1037"/>
               <Counter Type="44" Description="UnableToDeliverOverEntity" ScopeId="1" Offset="38" RealId="1038"/>
               <Counter Type="45" Description="LostAvailabilityOverClientSession" ScopeId="1" Offset="39" RealId="1039"/>
               <Counter Type="46" Description="RecoveredAvailabilityOverClientSession" ScopeId="1" Offset="40" RealId="1040"/>
               <Counter Type="47" Description="LostAvailabilityOverServer" ScopeId="1" Offset="41" RealId="1041"/>
               <Counter Type="48" Description="RecoveredAvailabilityOverServer" ScopeId="1" Offset="42" RealId="1042"/>
               <Counter Type="49" Description="LostAvailabilityOverEntity" ScopeId="1" Offset="43" RealId="1043"/>
               <Counter Type="50" Description="RecoveredAvailabilityOverEntity" ScopeId="1" Offset="44" RealId="1044"/>
               <Counter Type="51" Description="LostAvailabilityOverEngineForEntities" ScopeId="1" Offset="45" RealId="1045"/>
               <Counter Type="52" Description="RecoveredAvailabilityOverEngineForEntities" ScopeId="1" Offset="46" RealId="1046"/>
               <Counter Type="53" Description="UnableToDeliverToClient" ScopeId="1" Offset="47" RealId="1047"/>
               <Counter Type="54" Description="LostConnectionForServerSession" ScopeId="1" Offset="48" RealId="1048"/>
               <Counter Type="55" Description="UnbindConnectionForServerSessionDueToInactivityTimeAnomaly" ScopeId="1" Offset="49" RealId="1049"/>
               <Counter Type="56" Description="CreatedConnectionForServerSession" ScopeId="1" Offset="50" RealId="1050"/>
               <Counter Type="57" Description="LostAvailabilityOverLocalServer" ScopeId="1" Offset="51" RealId="1051"/>
               <Counter Type="58" Description="RecoveredAvailabilityOverLocalServer" ScopeId="1" Offset="52" RealId="1052"/>
               <Counter Type="59" Description="LostAvailabilityOverEngineForLocalServers" ScopeId="1" Offset="53" RealId="1053"/>
               <Counter Type="60" Description="RecoveredAvailabilityOverEngineForLocalServers" ScopeId="1" Offset="54" RealId="1054"/>
            </RegisteredCounters>
         </Scope>
      </RegisteredCounterScopes>
      <RegisteredAlarms/>
   </oam.Module>
   <oam.Module Name="diameter::codec oam module" Counters="Enabled" Alarms="Enabled" PreffixAlarmComponents="Shown" SuffixAlarmComponents="Shown">
      <RegisteredCounterScopes>
         <Scope Id="2" Description="diameter::codec oam module">
            <RegisteredCounters>
               <Counter Type="0" Description="AvpDecode__NotEnoughBytesToCoverAvpHeaderLength" ScopeId="2" Offset="0" RealId="2000"/>
               <Counter Type="1" Description="AvpDecode__IncoherenceBetweenActivatedVBitAndZeroedVendorIDValueReceived" ScopeId="2" Offset="1" RealId="2001"/>
               <Counter Type="2" Description="AvpDecode__IncorrectLength" ScopeId="2" Offset="2" RealId="2002"/>
               <Counter Type="3" Description="AvpDecode__DataPartInconsistence" ScopeId="2" Offset="3" RealId="2003"/>
               <Counter Type="4" Description="AvpDecode__UnknownAvpWithMandatoryBit" ScopeId="2" Offset="4" RealId="2004"/>
               <Counter Type="5" Description="MessageDecode__NotEnoughBytesToCoverMessageHeaderLength" ScopeId="2" Offset="5" RealId="2005"/>
               <Counter Type="6" Description="MessageDecode__NotEnoughBytesToCoverMessageLength" ScopeId="2" Offset="6" RealId="2006"/>
               <Counter Type="7" Description="AvpValidation__EnumeratedAvpWithValueDoesNotComplyRestriction" ScopeId="2" Offset="10" RealId="2010"/>
               <Counter Type="8" Description="AvpValidation__AvpFlagsDoesNotFulfillTheDefinedFlagRules" ScopeId="2" Offset="11" RealId="2011"/>
               <Counter Type="9" Description="MessageValidation__UnknownOperationUnableToValidate" ScopeId="2" Offset="12" RealId="2012"/>
               <Counter Type="10" Description="MessageValidation__OperationHaveIncoherentFlags" ScopeId="2" Offset="13" RealId="2013"/>
               <Counter Type="11" Description="LevelValidation__MissingFixedRule" ScopeId="2" Offset="14" RealId="2014"/>
               <Counter Type="12" Description="LevelValidation__FailedRuleForCardinality" ScopeId="2" Offset="15" RealId="2015"/>
               <Counter Type="13" Description="LevelValidation__FailedRuleForCardinalityLessThanNeeded" ScopeId="2" Offset="16" RealId="2016"/>
               <Counter Type="14" Description="LevelValidation__FailedRuleForCardinalityMoreThanNeeded" ScopeId="2" Offset="17" RealId="2017"/>
               <Counter Type="15" Description="LevelValidation__FailedGenericAvpRuleForCardinalityFoundDisregardedItem" ScopeId="2" Offset="18" RealId="2018"/>
               <Counter Type="16" Description="LevelValidation__FoundDisregardedItemsAndGenericAVPWasNotSpecified" ScopeId="2" Offset="19" RealId="2019"/>
            </RegisteredCounters>
         </Scope>
      </RegisteredCounterScopes>

Communication system counters

Counter 'RequestReceived'

Total requests received by the process. They are received at the server access point (RequestReceivedOnServerSession) and, less frequently, from the server nodes through the client connection (RequestReceivedOnClientSession).
Depending on the type of process (client mode, server, mixed mode) This counter may contain one or both (mixed).

Counter 'AnswerReceived'

Total responses received by the process. Received from the server nodes through the client connection (AnswerReceivedOnClientSession) and, less frequently, at the point of access server (AnswerReceivedOnServerSession).
Depending on the type of process (client mode, server, mixed mode) This counter may contain one or both (mixed).

Counter 'RequestReceivedOnClientSession'

Petitions received in a client socket (requests from a server).

Counter 'AnswerReceivedOnClientSession'

Replies received in a client socket (responses from a server).

Counter 'RequestReceivedOnServerSession'

Petitions received in a server socket (requests from a client).

Counter 'AnswerReceivedOnServerSession'

Replies received in a server socket (responses from a client).

Counter 'RequestSentOK'

Correct requests submissions, either by a client socket (RequestSentOnClientSessionOK) or server (RequestSentOnServerSessionOK).

Counter 'RequestSentNOK'

Delivery failed requests, either by a socket (RequestSentOnClientSessionNOK) or server (RequestSentOnServerSessionNOK).

Counter 'AnswerSentOK'

Correct answer delivery, either a client socket (AnswerSentOnClientSessionOK) or server (AnswerSentOnServerSessionOK).

Counter 'AnswerSentNOK'

Same for failed responses, either a client socket (AnswerSentOnClientSessionNOK) or server (AnswerSentOnServerSessionNOK).

Counter 'RequestSentOnClientSessionOK'

Correct requests submissions on client socket.

Counter 'RequestSentOnClientSessionNOK'

Failed requests submissions on client socket.

Counter 'AnswerSentOnClientSessionOK'

Correct answers submissions on client socket.

Counter 'AnswerSentOnClientSessionNOK'

Failed responses submissions on client socket.

Counter 'RequestSentOnServerSessionOK'

Correct requests submissions on server socket.

Counter 'RequestSentOnServerSessionNOK'

Failed requests submissions on server socket.

Counter 'AnswerSentOnServerSessionOK'

Correct answers submissions on server socket.

Counter 'AnswerSentOnServerSessionNOK'

Failed answers submissions on server socket.

Counter 'RequestSentExpired'

Expirations of requests that were sent, whether by a client socket (RequestSentOnClientSessionExpired) or server (RequestSentOnServerSessionExpired).

Counter 'RequestSentOnClientSessionExpired'

Expirations of requests that were sent by a client socket.

Counter 'RequestSentOnServerSessionExpired'

Expirations of requests that were sent by a socket server.

Counter 'AnswerReceivedUnknown'

Receptions of unknown responses (there is no request in the context for the data transported sequence), either by a client socket (AnswerReceivedOnClientSessionUnknown) or server (AnswerReceivedOnServerSessionUnknown).

Counter 'AnswerReceivedOnClientSessionUnknown'

Receptions of unknown responses through a client socket (there is no request in the context for sequence data transported).

Counter 'AnswerReceivedOnServerSessionUnknown'

Receptions of unknown responses through a server socket (there is no request in the context for sequence data transported).

Counter 'CERSentOK'

Correct Capabilities-Exchange-Request submissions from the application. Although not usual, the server may also send this, but this process does not. Just send a CER in client mode from each client socket.

Counter 'CERSentNOK'

Failed Capabilities-Exchange-Request submissions from the application.

Counter 'CEAReceived'

Receptions of Capabilities-Exchange-Answer. Although not usual, the server may also receive, but not send CER process for socket server.

Counter 'CERReceived'

Receptions of Capabilities-Exchange-Request.

Counter 'CEASentOK'

Correct Capabilities-Exchange-Answer submissions from the application. Although it is unusual, a client may also respond to a CER, but this process does not. Just answer in server mode from a server socket.

Counter 'CEASentNOK'

Failed Capabilities-Exchange-Answer submissions from the application.

Counter 'DWRSentOK'

Correct Device-Watchdog-Request submissions from the application. Although not usual, the server may also send, but this process does not. Just send a DWR client mode from a client socket.

Counter 'DWRSentNOK'

Failed Device-Watchdog-Request submissions from the application.

Counter 'DWAReceived'

Receptions of Device-Watchdog-Answer. Although not usual, the server may also receive, but this process does not send DWR from socket server.

Counter 'DWRReceived'

Receptions of Device-Watchdog-Request.

Counter 'DWASentOK'

Correct Device-Watchdog-Answer submissions from the application. Although it is unusual, a client may also respond to a DWR, but this process does not. Just answer in server mode from a server socket.

Counter 'DWASentNOK'

Failed Device-Watchdog-Answer submissions from the application.

Counter 'DPRSentOK'

Correct Disconnect-Peer-Request submissions from the application.

Counter 'DPRSentNOK'

Failed Disconnect-Peer-Request submissions from the application.

Counter 'DPAReceived'

Receptions of Disconnect-Peer-Answer.

Counter 'DPRReceived'

Receptions of Disconnect-Peer-Request.

Counter 'DPASentOK'

Correct Disconnect-Peer-Answer submissions from the application.

Counter 'DPASentNOK'

Failed Disconnect-Peer-Answer submissions from the application.

Counter 'ServerSocketsOpened'

Opening a socket server.

Counter 'ServerSocketsClosed'

Closing a socket server.

Counter 'UnableToDeliverOverEntity'

Failure sending to an entity (Server). Failure occurs when sending to all his servers, and within each of them, all sockets.
Keep in mind that until all client sockets to a server are tested, it does not means unable to delivery to that server.

Counter 'LostAvailabilityOverClientSession'

Loss of availability in a client session. It occurs when a client connection is closed.

Counter 'RecoveredAvailabilityOverClientSession'

Recovery of availability in a client session. It occurs when reconnecting (or connecting for the first time) a client connection.

Counter 'LostAvailabilityOverServer'

Loss of availability in the connection to the server, and therefore, with all sockets.

Counter 'RecoveredAvailabilityOverServer'

Availability recovery from the server, and therefore, in any of their sockets.

Counter 'LostAvailabilityOverEntity'

Loss of connection availability to an entity, and therefore, with all its servers.

Counter 'RecoveredAvailabilityOverEntity'

Recovery of connection availability to an entity, and therefore, in any of its servers.

Counter 'LostAvailabilityOverEngineForEntities'

Loss of availability in the all the motor entities, and therefore, with all its servers.
The ADL process only configures an entity which, this counter is synchronized with 'LostAvailabilityOverEntity'.

Counter 'RecoveredAvailabilityOverEngineForEntities'

Recovery of availability in some of the motor entities, and therefore, in some of its servers.
The ADL process only configures an entity which, this counter is synchronized with 'RecoveredAvailabilityOverEntity'.

Counter 'UnableToDeliverToClient'

Failure sending to a client (through the local server). Occurs when sending through the socket used fails.
The sum of 'RequestSentOnServerSessionNOK' and 'AnswerSentOnServerSessionNOK'.

Counter 'LostConnectionForServerSession'

Loss of availability in a server session. Occurs when a server connection is closed.

Counter 'UnbindConnectionForServerSessionDueToInactivityTimeAnomaly'

Local closing due to inactivity on the transport session.

Counter 'CreatedConnectionForServerSession'

Creating a server connection (accept) initiated from a client.

Counter 'LostAvailabilityOverLocalServer'

Loss of availability of the local server. It happens when you close all your server connections.

Counter 'RecoveredAvailabilityOverLocalServer'

Recovery of availability of the local server. It occurs when one of its servers connections is established.

Counter 'LostAvailabilityOverEngineForLocalServers'

Loss of availability to the connections of all local servers.
The ADL process only configures a server access point, which, this counter is synchronized with 'LostAvailabilityOverLocalServer'.

Counter 'RecoveredAvailabilityOverEngineForLocalServers'

Recovery availability in connection to the local servers of the engine and therefore, in any of them.
The ADL process only configures a server access point, which, this counter is synchronized with 'RecoveredAvailabilityOverLocalServer'.

Counters for the encoding/decoding system

Counter 'AvpDecode__NotEnoughBytesToCoverAvpHeaderLength'

An AVP whose length fails to meet even the minimum length of the header of an AVP.

Counter 'AvpDecode__IncoherenceBetweenActivatedVBitAndZeroedVendorIDValueReceived'

An inconsistency between the flags and the value of the vendor-id is detected. It may be because the V bit is set but the transported value for the vendor-id is invalid, or that being the bit off, the vendor-id however have non-zero indicating that it is vendor-specific.

Counter 'AvpDecode__IncorrectLength'

Failed length of an AVP. Inconsistent length information (eg a grouped does not have a multiple of 4 as length, etc.).

Counter 'AvpDecode__DataPartInconsistence'

Fault in the data portion of an AVP. It is easily detected when it comes to data formats known and fixed length, or address types that do not meet your specification (it is not IPv4, IPv6, etc.).

Counter 'AvpDecode__UnknownAvpWithMandatoryBit'

When decoding an AVP with the M bit (mandatory) on, and nothing is known about it (not defined in the dictionary), the application should reject the message. There is a handler for this event that increases this counter and triggers an alarm.

Counter 'MessageDecode__NotEnoughBytesToCoverMessageHeaderLength'

The message which length fails to meet even the minimum length of the diameter of a message header.

Counter 'MessageDecode__NotEnoughBytesToCoverMessageLength'

Failed length of a message. Inconsistent length information internally.

Counter 'AvpValidation__EnumeratedAvpWithValueDoesNotComplyRestriction'

A validation failure for a enumerated AVP whose value is outside the range defined in the dictionary.

Counter 'AvpValidation__AvpFlagsDoesNotFulfillTheDefinedFlagRules'

Failure of flags validation of an AVP with respect to the constraints defined in the dictionary.

Counter 'MessageValidation__UnknownOperationUnableToValidate'

Inability to validate a message because ignored its structure (not defined in the dictionary).

Counter 'MessageValidation__OperationHaveIncoherentFlags'

Inconsistent message flags. In practice it is impossible because it is shielded by the dtd message.

Counter 'LevelValidation__MissingFixedRule'

Missing fixed AVP in the message or within a grouped AVP.

Counter 'LevelValidation__FailedRuleForCardinality'

Failed cardinality rule for AVP within a message or a grouped AVP.
It is the sum of the following two:

Counter 'LevelValidation__FailedRuleForCardinalityLessThanNeeded'

Failed cardinality rule for AVP within a message or a grouped AVP, for lack of items.

Counter 'LevelValidation__FailedRuleForCardinalityMoreThanNeeded'

Failed cardinality rule for AVP within a message or a grouped AVP, due to excess of items.

Counter 'LevelValidation__FailedGenericAvpRuleForCardinalityFoundDisregardedItem'

Failed cardinality rule of AVP due to find generic elements outside the structure that do not meet the cardinality constraint.

Counter 'LevelValidation__FoundDisregardedItemsAndGenericAVPWasNotSpecified'

There are Elements outside the structure and generic AVP has not been defined.

Updated by Eduardo Ramos (Edu1770) over 5 years ago · 143 revisions