Auto-Fill Fields

When you define a message in a DMF or a Lite DMF, you can insert fields that will supply dynamic values for the message when it is generated during a test. The information that is inserted with a field can be drawn from the IP header, from messages received, or from values generated by or defined in the test case. You can also capture values from a received message and use them to provision the port used in a DMF (subflow) OR Lite DMF or to calculate other values that can be inserted into a subsequent message. Values can be represented in text or binary formats as appropriate.

In the example shown, three different types of values generated by the test are inserted in the message. Each value will be inserted at the byte offset specified, and each will use the selected format. You can Add and Remove rows.

See About the Message Editor Window for more information about field placement and the user interface.

This topic describes the different types of fields available, how they can be used, and how they are defined, including practical examples. The topics listed under Related Parameters cover the other settings used to define messages and DMFs. The topics listed under Related Topics provide more information about message definition and about tools that can help you build a DMF.

In this topic...

Type
Format
Offset

Command/Search Pattern
RTSP Examples

Related Parameters

Field Types

Many different types of information can be inserted into or extracted from messages with the following fields.

Values from the packet's IP header
Values generated by or defined in the test case
Information received in a message or user defined information via Copy/Paste Buffers
Subflow port information
Message time stamps
Per-Flow CDR Validation values
IMS Fields

NOTE: When a field generically indicates an endpoint, such as source or destination, the entity referenced by the field is relative to the message's sender and receiver. Fields that insert information act from the perspective of the message's sender, while fields that extract information act from the perspective of the message's receiver. In a message sent by the client, for example, one field can insert the value of the subflow's Client Port (the sender's source port) and another field can capture the inserted value by using a field that extracts the subflow's destination port (the client's port is the destination of the server's subflow).

IP Header Values

You can insert values from the packet's IP header with the following fields:

Source IP Address
Dest IP Address
Source Port
Dest Port

NOTE: In this context, the terms source and destination refer to the sender or recipient of the message. If the packet is sent by the MN, the MN is the source. If the packet is sent by the Network Host, the host is the source.

Test Case Values

Information generated by the test case provides zero-based counters and identifiers at the session, DMF, and subflow levels:

Session Offset — Increments for each data session. When an MN establishes multiple data connections, each connection is considered a data session. When each MN establishes one data connection, each MN session is a data session.
Transaction Count — Increments for each DMF transaction within one data session.
Message Count — A cumulative counter of all messages sent by the source across all DMF transactions within one data session.

DMF Row Count — The step number of the command that generated the message. Since the index is zero-based, step numbers 1— 64 are reported as rows 0— 63.

NOTE: If the Sequencing View of a DMF is set to Client or Server, the step numbers displayed may change since commands that do not apply to the view are not displayed. The step numbers used in DMF Row Count are from the Combined view.

Copy/paste Buffers

Paste Buffers can be configured and initialized on the Sequence Tab for Advanced Data DMFs or Paste Buffers Tab for Lite DMFs.

You can capture any value from one message and insert those bytes into any subsequent messages with the Copy Buffer and Paste Buffer fields. Place a Copy Buffer in a defined message to capture the actual value contained in the message when it is received. Place the corresponding Paste Buffer in any subsequent messages to insert the captured value into the message before it is sent. If a DMF contains subflows, the same Paste Buffer can be used to insert values in the mainflow and any associated subflows.

Ten field types, Copy Buffer 1 through Copy Buffer 10, allow you to capture bytes from a received message. You can specify the bytes to capture in one of two ways:

Copy_Buffer_1 to Copy_Buffer_10 — Ten field types, Copy Buffer 1 through Copy Buffer 10, allow you to capture bytes from a received message. You can specify the bytes to capture in one of two ways:
Paste_Buffer_1 to Paste_Buffer_10 — Information that was captured with a Copy Buffer field can be inserted into one or more outgoing messages by adding the corresponding paste buffer to the messages. Corresponding paste fields, Paste Buffer 1 through Paste Buffer 10, are provided for each copy buffer. Paste Buffer 1 inserts the value captured by Copy Buffer 1, and so on. The number of bytes inserted is defined by Format. Select the variable-size Binary format to insert the contents of the copy buffer without regard to length. You can also select one of the fixed-length formats. If you insert more bytes than the copy buffer holds, the extra bytes are coded as 0x00. If you insert less bytes than the copy buffer holds, the information from the copy buffer is truncated.

Paste Buffer Configuration is used to configure the name, size and initial values for the Auto-Fill Paste Buffers. When the copy and paste buffers are used, ensure the buffer is sized properly to store all the data that is placed in the buffer. Optionally, set the initial/default values and assign names to the buffers.

Subflow Ports

You can capture a port value and use it to provision the defined port for a subflow. With these fields, a Search Pattern must be used to find the port value in the message.

Extract Subflow n Src Port — Copy the port value from a received message and use it to provision the Client Port of the selected subflow.
Extract Subflow n Dest Port — Copy the port value from a received message and use it to provision the Server Port of the selected subflow.

NOTES:

In order to dynamically provision either the client or server port, the port number must be defined as 0 in the subflow. If a specific port is defined in the subflow, that port will be used rather than the extracted value.
If the test case will be executing multiple DMFs, make sure that the port provisioning will not violate the rules governing client and server port assignments.

You can also paste a subflow's Client Port or Server Port into a message, allowing you to configure messages that dynamically change based on the subflow's actual ports.

Insert Subflow n Src Port — Paste the selected subflow's Client Port into the message.
Insert Subflow n Dest Port — Paste the selected subflow's Server Port into the message.

Time Stamps

You can insert the time a message is sent — the source's local time — into a message and extract the time stamp at the destination.

Insert Local Time — Inserts a time stamp at the byte specified.
Extract Remote Time — Extracts the time stamp that was inserted into a message.

These fields are required to measure one-way latency, measured from the time a message is sent until it is received, between the source and the destination. A Remote Host and two DMFs are required to calculate one-way latency. One side uses Insert Local Time to include a time stamp in a message, and the other side uses Extract Remote Time to capture the time stamp from that message. You can measure one-way latency from the MN/MS to the Network Host and from the Network Host to the MN/MS with the same pair of DMFs.

NOTE: The 8-bit binary format does not allow space for enough information to reliably calculate latency. A minimum of 64 bits should be used to configure Insert and Extract time parameter. The delay calculations will not be accurate without both Insert and Extract time parameters.

Related Measurements

NOTE: The latency measurements are shown in the One Way Delay counters in the L5-7 Client | Advanced and L5-7 Server | Advanced tabs.

Per-Flow CDR Validation Values

When your test includes Per-Flow CDR Validation, you can capture a value from a message that will be included in the LDRs and compared to values in classification templates.

Extract Source Billing Reference
Extract Dest Billing Reference

IMS Fields and HTTP

If you have enabled authentication for an IMS Security test, you can use the following fields to capture and insert authentication credentials and keying material. See Building an IMS AKA DMF for more information on how to use these fields.

Extract RAND — Extracts the random challenge received in a message, which is then parsed and used to formulate the response. If the server requires authentication, the challenge is normally received in a "4XX" message sent in response to the client's initial request.
Insert Digest — Inserts the encrypted challenge response and user credentials into client requests.
Insert Basic Credentials — Inserts the encrypted user credentials (username and password) into client requests for HTTP Basic defined in the Security Options window.
Insert RAND — Inserts a random challenge into a response message. A static value can be used for all AKA challenges when you select Fixed RAND in the Security Options window.
Extract QOP — Extracts the Quality of Protection supported by the server.
Insert QOP — Inserts the captured QOP value into a client response.
Extract Source Method — Extracts the local peer's HTTP method from an outgoing message.
Extract Dest Method — Extracts the remote peer's HTTP method from a received message.
Insert Method — Inserts the captured source or destination method into an outgoing message during Digest authentication. Method is only specified if the server does not issue a QOP directive.
Insert Digest URI — Inserts the Digest URI defined in the Security Options window.
Insert Host URI — Inserts the Host URI defined in the Security Options window.
Insert CNonce — Inserts the CNonce defined in the Security Options window. CNonce is only used in Digest authentication when the server issues a QOP directive.
Insert Nonce Count — Inserts the Nonce Count defined in the Security Options window. Nonce Count is only used in Digest authentication when the server issues a QOP directive.
Insert IK — Inserts the Integrity Key into the challenge message sent to the client. This field is only used when the Network Host is simulating an S-CSCF. The P-CSCF strips this key from the message before forwarding it to the MN.
Insert CK — Inserts the Cipher Key into the challenge message sent to the client. This field is only used when the Network Host is simulating an S-CSCF. The P-CSCF strips this key from the message before forwarding it to the MN.
Extract Realm — Extracts the realm from an incoming message.
Insert Realm — Inserts the captured realm value into an outgoing message.
Extract Nonce — Extracts a nonce from the server challenge.
Insert Nonce — Inserts the captured nonce into a client's challenge response.
Insert Content Length — Calculates at run-time and inserts into a message the lengh of 'message-body' as defined in RFC3261, RFC 2616. Used in the Content-Length header which must be the last message header, in spite, it does not have to be according to RFC. <CR><LR><CR><LR> should be used between last message-header and the optional message-body.
Cert Insert, Signed Start, Signed End — Use with Encrypted Content (Signed Content) to insert . Use Auto-Fills <Signed_Start>/<Signed_End> to define range, <Cert_Insert> is Optional. Additional details in About the Message Editor Window.
URL Encode Start, URL Encode End — Use with Encrypted Content (Signed Content). Set multiple ranges of URL Encoding. URL Encoding happens last after all other Auto-Fills occur. First pass normal Auto-Fills occur, Second pass Signing Data happens, Third pass URL Encoding happens. You don't have to add Start/End Auto-fill separately, just select the text you want to Encode/Sign and right-click.
Domain Name — Insert Domain Name.
FQDN — Insert FQDN (Fully Qualified Domain Name).
MSISDN — Insert MSISDN (Mobile Station International Subscriber Directory Number) information to HTTP messages. The dynamically inserted MSISDN field in http data flow will be constructed based on its corresponding UE’s “MSISDN” value in S11 tab of SGW Nodal. User only needs to add this new “Auto-Fill” field to the message body of HTTP messages. Landslide will automatically update the MSISDN changes per UE to this field.

During the registration process an IPSec connection is established and the client and server must identify the SPIs that are associated with the IPSec SAs. The following fields can be used to provision the Peer SPI for the IPSec tunnel or to insert the provisioned Source SPI into a message. A set of fields is provided for each of the sixteen possible IPSec tunnels.

Extract Peer SPI n — Extracts the SPI received in a message and uses it to provision the Peer SPI for that tunnel.
Insert Peer SPI n — Inserts the captured Peer SPI in an outgoing message.
Extract Source SPI n — Extracts the SPI received in a message and uses it to provision the Source SPI for that tunnel.
Insert Source SPI n — Inserts the captured Source SPI in an outgoing message.

^ Back to Top

Field Formats

Values can be generated or captured in text or binary formats. In some cases, you can choose the number of bits used in a binary format. If the length is not specified, the length of the field will be the number of bits required for the value. The table below shows the formats that are available for the different field types.

NOTES:

When you use a fixed-length binary format, ensure that the length can accommodate the largest possible value that will be generated during the test.
The Format does not automatically change when you change the field Type unless you click on the format list. You will receive a validation error if the message contains an invalid type/format combination.

Field	Binary Formats							ASCII/String
Field	8-Bit	16-Bit	32-Bit	64-Bit	96-Bit	NTP	Binary (variable)	ASCII/String
Source IP Address
Dest IP Address
Source Port
Dest Port
Domain Name
FQDN
MSISDN
Cert Insert
Signed Start / Signed End
URL Encode Start / URL Encode End
Session Offset
Transaction Count
Message Count
DMF Row Count
Copy Buffer n
Paste Buffer n
Insert Subflow n Src Port
Extract Subflow n Src Port
Insert Subflow n Dest Port
Extract Subflow n Dest Port
Insert Local Time
Extract Remote Time
Extract Source Billing Reference
Extract Dest Billing Reference
Extract RAND
Insert Digest
Insert Host URI
Insert Basic Credentials
Insert RAND

^ Back to Top

Offset

The Offset setting determines the starting byte of a field operation. A field that captures information uses Offset to target the starting byte of the capture or the starting point of a search when a Search Pattern is used. A field that inserts information uses Offset to determine where the information is placed. If you enter a 0 offset, for example, the information is inserted or copied beginning with the first byte in the message.

NOTE: You may sort the Auto-fill fields in the Message Editor Window based on the Offset Column.

The Message Editor window provides several ways to help you determine the correct Offset for a field. See About the Message Editor Window for more information about field placement.

NOTES:

Offset positions are based on the literal portion of the message, as displayed on the Hex-Ascii tab, without regard to any content that may be inserted by another field.
Values can only be inserted into the literal portion of the message, excluding the range of bytes that are verified by the receiving end, and cannot be inserted into the portion of the message containing Filler Data.

^ Back to Top

Command/Search Pattern

When you capture information from a received message, you can define search criteria to find information of variable length or location. In this case, the Format setting is ignored since the format is defined within the criteria and Offset specifies the starting point for the search. The message is searched using the criteria that you define in Command/Search Pattern and when a match is found, the number of characters or bytes specified is copied. You can literally specify the number of bytes or define a second search pattern to terminate the capture. If a match is not found, either the default value defined for the Paste Buffer is used or a dynamic port is assigned to the subflow depending on the type of field performing the search.

The search criteria is made up of three parameters: the starting pattern, the length and format of the information to capture, and the ending pattern. Up to 32 characters can be used in the Search Pattern. Double-click the field to enter or edit the criteria.

Syntax: <starting pattern>%[n]f[ending pattern]

Definitions:

<starting pattern> — A text representation of the bytes immediately preceding the information to be captured. Non-displayable ASCII values and raw binary values can be represented with a hexadecimal format, and \r and \n are also supported. You can search for a CR-LF pair, for example, by entering either \r\n or \x0d\x0a.
%[n]f — The length and format element always begins with a percent sign. You can optionally specify the number of bytes captured and must specify the information format.
- n — The number of bytes or characters to capture (1— 12). If n is not included, the bytes immediately following starting pattern that also match the specified format (f) are captured unless an ending pattern is also defined.
- f — The format of the bytes to be captured:

s = ASCII characters (A— Z, a— z, 0— 9, @, _)
d = Decimal characters (0— 9)
x = Hexadecimal characters (0— 9, A— F, a— f)
b = Raw binary byte (0x0— 0xff)

[ending pattern] (binary format only) — When you need to copy information that is not a fixed length, use the binary format and define a pattern that terminates the capture. A maximum of 12 bytes following the starting pattern and preceding the ending pattern will be captured.

NOTES:

Most displayable characters that do not meet the definition of the ASCII format above, "/," or blank spaces for example, can be used as text in the pattern definition but will only be included in a capture if the format is binary (b).
The capture will terminate when a byte that does not match the defined value format is encountered.
Offset must be less than or equal to the actual location of search pattern.

Search Criteria Examples

Find a session identifier containing a variable number of digits.

Value in received message: Session: 102\r\n (blank space between the colon and the identifier)
Search Pattern: Session: %d (only captures decimal characters)

Find a padded, fixed-length 10-digit identifier that does not occur in a fixed location.

Value in received message: UID:0000636294\r\n
Search Pattern: UID:%10d

Find the client port number to be assigned to a subflow.

Value in received message: client_port=4901;
Search Pattern: client_port=%b; (semicolon is the ending pattern)

Find a variable-length value embedded in a tag.

Text representation of the received message: <user id=testuser>
Search Pattern: <user id=%s (only ASCII characters captured)

Modifying Inserted Auto-Fill Items

For some inserted Auto-Fill items, you can modify the inserted item using certain operations. The Auto-Fill items to which this applies include the following:

Source Port
Destination Port
Session Offset
Transaction Count
Message Count

The available operators are as follows:

'*' = Multiplication
'+' = Addition
'>' = Shift Right
'<' = Shift Left

The syntax is as follows:

<%n><Opr><Num><Format>

% — The length element always begins with a percent sign
n — Number of bytes or characters of the Auto-Fill value to insert
Opr — Operator
Num — For multiplication and addition, the number to multiple by or add to the Auto-Fill value
- For Shift Left and Shift Right, the number of bit positions to shift
- If Num is left blank, 0 is the default
Format — The format of the bytes:
- b = Raw binary byte (0x0—0xff)
- d = Decimal, padded with leading 0's according to <n>

NOTE: The format in the Command will override the format selected in the Format Field.

^ Back to Top

RTSP Examples

The following examples show you how to use fields to capture and use identifiers that are received from an application server and how to design messages and DMFs that react to changes that you make to the DMF's configuration.

Capturing an RTSP Session ID

When you test with a "real" application server rather than a Network Host, requests sent to the server must include the Session ID established by the server and transmitted to the client in the SETUP response. It is not necessary to fully define every response message in your DMF since the server will be generating the messages but enough content must be defined to verify the message and to provide the framework to place a Copy Buffer. The default RTSP TCP DMF is used to illustrate this example.

Initialize a buffer —
1. Click the Paste Buffer Configuration button and open the Buffer Fields window.
2. Set the Name of the first buffer to sessionID or something similar.
3. Set the Size to 8 so that it can accommodate the ID length.
4. Set the Initial Value to 00000000 or some other value that will indicate that the session ID is not correct.
Capture the session ID — The ID is contained in the first RTSP message received from the server (the response message in Step 1 of the DMF):

RTSP/1.0 200 OK
CSeq:102
Session:56420343
Transport:RTP/AVP;unicast;client_port=4900-4901;server_port=4900-4901;

In this DMF, the sequence number will always be a fixed length (3 digits) since it is defined by the client, and therefore the session ID will be in a fixed location. The length of the ID may vary, however.

Edit the response message and select the Text Editor sub-tab.
Select the entire session ID value, right-click, and select Add Auto-Fill from the context menu as shown in the example. A new field, with the correct Offset, is added to the grid.
In the grid, set the field's Type to Copy_sessionID and set the Format to ASCII/String. Since the ID is text-based and "\r\n" immediately follows the ID value, the digits, beginning with byte 35, will be captured until a non-alphanumeric byte is reached (\r or 0x0d in this example).

Insert the captured session ID — Insert the captured ID in the remaining client requests (Steps 2 and 3).

Edit the PLAY request in Step 2 and select the Text Editor sub-tab.
Replace the session ID with a field as you did when you placed the Copy Buffer.
Set the new field's Type to Paste_sessionID and set the Format to Binary since the ID length is variable.
Select the Auto-Fill Viewer sub-tab to check the field placement.
Repeat these steps with the TEARDOWN request in Step 3.

When you execute your test, the DMF can correctly respond with the different session IDs the server will assign for every transaction.

Changing Subflow Ports

In the initial RTSP request, the client informs the server of a range of ports that it is willing to use for the content TCP connection — the subflow in this case. The server responds with the range of ports that it may use to establish the connection. You can structure your messages to react to changes that you make to the subflow's Client Port, and you can structure the subflow to accept any Server Port. The customized RTSP TCP DMF from the previous example will be used in this example.

Insert the subflow Client Port — The client port range is specified in the request message in step 1 of the DMF.
1. Edit the request message and replace the first client port with an Insert Subflow 1 Source Port field using the default Format. The value of the subflow's Client Port will be inserted into the message when you run the test and will change whenever you modify the subflow.
2. Set the upper range (4901 in this example) to a value that will accommodate the upper range of ports you may be using. You can edit the message or initialize a Paste Buffer to provide the value as shown in the example.
Configure the subflow server port
1. Edit the subflow DMF.
2. Set the Server Port to 0. This allows the test to accept any port the server chooses to use.

Your DMF can now react to port changes that you make and it can correctly respond to port selections made by the server.

^ Back to Top