CORE IPC API

Version 1.21 This document defines the communication interface for the Common Open Research Emulator (CORE). CORE uses this API internally to communicate between its components. Other systems may connect to CORE using this API to control the emulated network topology. One example of such an external system is a physical/link-layer simulator. The API aims to operate on a higher level of nodes and links, abstracting the lower-level details.

Table of Contents 1 Overview ..................................................................................................................... 2 2 Message Format ........................................................................................................... 3 3 Message Types ............................................................................................................ 6 3.1 Node Message ...................................................................................................... 6 3.2 Link Message ....................................................................................................... 8 3.3 Execute message ................................................................................................ 11 3.4 Register message ................................................................................................ 14 3.5 Configuration message ....................................................................................... 16 3.6 File Message ....................................................................................................... 19 3.7 Interface Message ............................................................................................... 21 3.8 Event Message.................................................................................................... 22 3.9 Session Message ................................................................................................. 24 3.10 Exception Message ......................................................................................... 25 4 Change Log................................................................................................................ 26

1 Overview
For information about CORE and for downloading the software, visit the CORE project page: http://cs.itd.nrl.navy.mil/work/core/ For a quick reference to this API and to view API examples, refer to the CORE wiki page: http://code.google.com/p/coreemu/wiki/API The CORE daemon listens on a TCP socket for CORE API messages from other local or remote systems. The CORE GUI connects locally to this daemon and uses this API to instantiate topologies. CORE will also act as an emulation server that listens for a TCP connection from another system. Upon connection establishment, the other system transmits messages to the CORE daemon that can control the live-running emulation. Port 4038 was chosen at random from the IANA list of assigned port numbers (current status is unassigned). The message types defined by this API are summarized in Table 1-1.
Table 1-1 Overview of API Messages Type 1 2 3 4 5 6 7 8 9 10 Message Name Node Link Execute Register Configuration File Interface Event Session Exception Description Adds and removes nodes from an emulation. Links two nodes together. Run a command on a node. Register an entity with another, for notifications or registering services. Exchange configuration information with CORE. Transfer or copy short files (e.g. configuration files) to a node. Add and remove interfaces from nodes. Signal an event between entities. Manage emulation sessions. Signal errors, warnings, or other exception conditions.

CORE API Version 1.21 - Page 2

2 Message Format
One or more CORE API control messages may appear in a single TCP data packet. The CORE API control messages use the following format:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Flags | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Data (variable length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Flags | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Data (variable length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Flags | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Data (variable length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2-1 CORE Message Format

The TCP header everything (shown in gray) before Message Type represents the standard TCP header taken from the TCP specification in RFC 793. What follows is one or more CORE messages (shown in black). Each Message starts with four bytes that indicate the Message Type, Flags, and Message Length. A variable Message Data field follows, depending on the Message Type. Numeric fields are unsigned values expressed in network byte order where applicable.

CORE API Version 1.21 - Page 3

Table 2-1 CORE Message Fields Field Message Type Flags Length 8-bit value 8-bits Description Type of CORE message, which defines the contents of the Message Data, required for parsing. Message flags. Possible values: 00000001 = (0x01) Add flag 00000010 = (0x02) Delete flag 00000100 = (0x04) Critical flag 00001000 = (0x08) Local flag 00010000 = (0x10) Status response requested 00100000 = (0x20) Text output requested 01000000 = (0x40) TTY flag Length in bytes of the Message Data. Note that this is represented in network byte order, and excludes the Message Type, Flags, and Message Length fields. The maximum Message Length is 65,535 bytes. Data specific to each Message Type, defined in the sections below.

Message Length

16-bit value

Message Data

variable length

Each Message Type may implement one or more <Type, Length, Value> tuples, or TLVs, for representing fields of data. This allows the flexibility of defining future additional fields. The TCP packet can contain multiple messages, each which may include several TLVs. This is depicted in Figure 2-2. Each message type defines its own TLV types. The TLV Length indicates the length in bytes of the TLV data, excluding the Type and Length fields. For clarity, all of the TLV data fields shown in Figure 2-2 are 32 bits in length, but in reality the TLV data can be any length specified by the TLV length field (up to 255).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Flags | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | TLV Length | TLV data (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | TLV Length | TLV data (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV data (variable, continued, example > 16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Flags | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | TLV Length | TLV data (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2-2 Message sub-TLVs

The TLV data is padded to align to the 32-bit boundaries, and this padding length is not included in the TLV length. For 32-bit and 64-bit values, pre-padding is added (a series of zero bytes) so the actual value is aligned. Because the Type and Length fields combined occupy 16 bits, there will be 16-bits of padding and

CORE API Version 1.21 - Page 4

then 32-bits of Value for 32-bit values. Strings are padded at the end to align with the 32-bit boundary. Although the TLV Length field is limited to 8 bits, imposing a maximum length of 255, special semantics exist for lengthier TLVs. Any TLV exceeding 255 bytes in length will have a TLV Length field of zero, followed by a 16-bit value (in network byte order) indicating the TLV length. The variable data field then follows this 16bit value. This increases the maximum TLV length to 65,536 bytes; however, the maximum Message Length (for the overall message) is also limited to 65,536 bytes, so the actual available TLV length depends on the lengths of all of the TLVs contained in the message.

CORE API Version 1.21 - Page 5

3 Message Types
3.1 Node Message
The Node Message is message type 1. The Node message may cause a variety of actions to be performed, depending on the message flags: No flag (00) when neither the add or delete flags are set, this message is assumed to modify an existing node or node state. Add flag (01) message is to create a node or create state for a node. Delete flag (10) message is to stop a node or delete state for a node. Critical flag (100) message should be processed, for example if the nodes position is unchanged but a link calculation is requested. Local flag (1000) message is informational, for example to update a display only. Status request (10000) a response message is requested containing the status of this add/delete message. (Text output (100000) this flag is undefined for the Node Message.) The TLVs for the Node Message are defined in Table 3-1 below. The Node Type TLV determines what type of node will be created. These values are defined in Table 3-2 below. The Model Type TLV further determines the configuration of the node depending on node types defined in the GUI (e.g. router, PC). When the Model Type is not present, its value defaults to zero.
Table 3-1 Node Message Fields TLV type 0x01 TLV length 32-bit value Name Node Number Description Unique number used to identify a node. Usually node numbering starts with zero and increments. Indicates the type of node to be emulated. See Table 3-2 for possible values. Text name assigned to a node. The string does not need to be NULL terminated as the exact length is specified in the TLV length. Note that the node number identifies a node, not its name. Optional: indicates the model used for this node type. Assumed to be router if the TLV is omitted. Used for associating services with a node. This field is like a node sub-type that allows for user-defined types. Optional server name on which this node should be instantiated. Optional numeric identifier(s) indicating the Session(s) this message is intended for. A list of Session numbers may be used, separated by a pipe | symbol.

0x02 0x03

32-bit value variable string

Node Type Node Name

0x07

Variable string

Model Type

0x08 0x0A

variable string variable string

Emulation Server Session Number(s)

CORE API Version 1.21 - Page 6

0x20

16-bit value

X position

0x21

16-bit value

Y-position

0x22

16-bit value

Canvas

0x23

32-bit value

Emulation ID

0x24

32-bit value

Network ID

0x25 0x42 0x50

variable string variable string variable string

Services Icon Opaque data

Optional: horizontal position where the node should be drawn on the logical network map. If no position is given, CORE selects the nodes position. The typical width of the CORE screen is 1024. Optional: vertical position where the node should be drawn on the logical network map. If no position is given, CORE selects the nodes position. The typical height of the CORE screen is 768. Optional: canvas number (0 or higher) on which node should be drawn with X, Y coordinates. If omitted, default value is 0. The ID of the emulated node. This implies that the emulated node has been instantiated. For FreeBSD this is the Netgraph ID of the wireless interface of the node. Number identifying the network this node belongs to. For example, the node number of the attached WLAN node. List of startup services configured for this node, string names separated by | character Optional: path of icon file for display User-defined data for passing any type of information.

Table 3-2 Node Type TLV Values Node Type Value 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xA Name Default Physical Xen Undefined Switch Hub WLAN RJ45 Tunnel Ktunnel EMANE Description Network Namespace (Linux) or jail (FreeBSD) based emulated node. A physical testbed machine that can is available to be linked in to the emulation and controlled by CORE. A Xen based domU node. Layer 2 Ethernet bridge, learns connected hosts and unicasts to appropriate link only. Layer 2 Ethernet hub, forwards data to all connected links. Wireless LAN object forwards data intelligently between connected node pairs based on rules. Connects physical Ethernet device to the emulation. Uses Span tool to build tunnels to other emulations or systems. Uses ng_ksocket to build tunnels from one kernel to another. EMANE network uses pluggable MAC/PHY models.

CORE API Version 1.21 - Page 7

3.2 Link Message

The Link Message is message type 2. A Link specifies a connection between two nodes, specified by their node numbers. The Link message may cause a variety of actions to be performed, depending on the message flags: No flag (00) when neither the add or delete flags are set, this message is assumed to modify an existing link or link state. Add flag (01) message is to create a link or create state for a link. Delete flag (10) message is to remove a link or delete state for a link. Critical flag (100) message should not be ignored, for example due to rate limiting. Local flag (1000) message is informational, for example to update a display only. Status request (10000) a response message is requested containing the status of this add/delete Link Message. (Text output (100000) this flag is undefined for the Link Message.)

The TLVs for the Link Message are defined in Table 3-3 below.

CORE API Version 1.21 - Page 8

Table 3-3 Link Message Fields TLV Type 0x01 0x02 0x03 TLV Length 32-bit value 32-bit value 64-bit value Field Node 1 Number Node 2 Number Link Delay Description The number of the first node that the link connects. The number of the second node that the link connects. The value of the delay of the link in microseconds (s), in network byte order. The value may be zero (no delay). The maximum value is 2000000 s (2 s). The value of the bandwidth of the link in bits per second (bps), in network byte order. Sample values are: 100000000 = 100M 10000000 = 10M 512000 = 512 kbps 0 = Unrestricted bandwidth. Up to gigabit speeds are supported. The Packet Error Rate, specified in percent (%), or Bit Error Rate (FreeBSD). The value should be between 0-100% inclusive for PER. The duplicate packet percent (%), where the specified percentage of packets will be randomly duplicated on this link. The value may be zero (no duplicates). Maximum value is 50%. The value of the random delay applied to the link in microseconds (s), in network byte order. The value may be zero (no jitter). The maximum value is 2000000 s (2 s). The Multicast Error Rate, specified in percent (%). The Burst rate, specified in percent (%), which is the conditional probability that the next packet will be dropped given the last packet was dropped. Optional numeric identifier(s) indicating the Session(s) this message is intended for. A list of Session numbers may be used, separated by a pipe | symbol. The Burst rate for multicast packets (%) Indicates whether this message is creating/deleting a link (type=1) or signaling a wireless link event (type=0). The ID of the emulated node. For FreeBSD this is the Netgraph ID of the wireless interface of the node. This TLV can appear multiple times, first for node 1, then for node 2. The number of the network to which this link belongs. This allows the same node pairs to be joined to two networks.

0x04

64-bit value

Link Bandwidth

0x05

64-bit value

PER

0x06

16-bit value

Duplicates

0x07

32-bit value

Link Jitter

0x8 0x9

16-bit value 16-bit value

MER Burst

0xA

variable string

Session Number(s)

0x10 0x20

16-bit value 32-bit value

Multicast Burst Link Message Type Emulation ID

0x23

32-bit value

0x24

32-bit value

Network ID

CORE API Version 1.21 - Page 9

0x25 0x30

32-bit value 16-bit value

Key Interface 1 Number Node 1 IPv4 Address Node 1 IPv4 Netmask Bits Node 1 MAC Address Node 1 IPv6 Address Node 1 IPv6 Netmask Bits Interface 2 Number Node 2 IPv4 Address Node 2 IPv4 Netmask Bits Node 2 MAC Address Node 2 IPv6 Address Node 2 IPv6 Netmask Bits Opaque data

0x31 0x32

32-bit value 16-bit value

0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x40 0x41 0x50

64-bit value 128-bit value 16-bit value 16-bit value 32-bit value 16-bit value 64-bit value 128-bit value 16-bit value variable string

Value used with Tunnel Node t as the GRE key. The number of the interface on Node 1; for example 0 would cause an interface eth0 to be created, 1 would create eth1, etc. The IPv4 address assigned to the interface on Node 1; auto-assigned if not specified The number of bits forming the network mask for the IPv4 address on Node 1, for example 24 for a /24 address The MAC address assigned to the interface on Node 1 The IPv6 address assigned to the interface on Node 1 The number of bits forming the network mask for the IPv6 address on Node 1 The number of the interface on Node 2 The IPv4 address assigned to the interface on Node 2; auto-assigned if not specified The number of bits forming the network mask for the IPv4 address on Node 2 The MAC address assigned to the interface on Node 2 The IPv6 address assigned to the interface on Node 2 The number of bits forming the network mask for the IPv6 address on Node 2 User-defined data for passing any type of information.

CORE API Version 1.21 - Page 10

3.3 Execute message

The Execute Message is message type 3. This message is used to execute the specified command on the specified node, and respond with the command output after the command has completed if requested to do so by the message flags. Because commands will take an unknown amount of time to execute, the resulting response may take some time to generate, during which time other API messages may be sent and received. The message features a 32-bit identifier for matching the original request with the response. No flags are defined. Either the Command String or Result String TLV may appear in an Execute Message, but not both. The following flags are used with the Execute Message: (Add flag (01) this flag is undefined for the Execute Message.) Delete flag (10) cancel a pending Execute Request Message having the given Execution Number. Critical flag (100) this Execute Request should be immediately executed, regardless of any existing, pending requests for this node. Local flag (1000) this Execute Request should be executed on the host machine, not from within the specified Node; the command being executed affects the specified Node and should be run in the order it was received with other local Execute Requests regarding this Node. Status request (10000) an Execute Response message is requested containing the numeric exit status of the executed process. Text output (100000) an Execute Response message is requested containing the complete output text of the executed command. Interactive terminal (TTY) flag (1000000) this message requests the command to be executed in order to spawn an interactive user shell on the specified node. The TLVs for the Execute Message are defined in Table 3-4 below. Note that the Result String will likely exceed the TLV length of 255, depending on the output of the specified command. In that case, the TLV Length field is set to zero, followed by a 16-bit value specifying the TLV length. The maximum result length is therefore 65,536 bytes minus the length of the other TLVs.

CORE API Version 1.21 - Page 11

Table 3-4 Execute Message Fields TLV Type 0x01 TLV Length 32-bit value Field Node Number Description The number of the node on which the command will be executed or was executed, or the number of the node that this command is concerned with. An identifier generated by the caller for matching an asynchronous response. (Optional TLV) For Execute Requests, indicates a desired time for starting command execution. For Execute Responses, indicates the time at which command execution has completed. The time value represents the number of seconds since the Epoch of 00:00:00 UTC January 1, 1970, as the Unix time(2) and gettimeofday(2) system calls. A zero value indicates that the command should execute immediately. Absence of this optional TLV implies a zero value. The presence of this field indicates an Execute Request Message. String containing the exact command to execute. The string does not need to be NULL terminated as the exact length is specified in the TLV length. The presence of this field indicates an Execute Response Message. String containing the output of the command that was run. Note that the string does not need to be NULL terminated as the exact length is specified in the TLV length. This field may be included in the Execute Response Message and contains the numeric exit status of the executed process. Optional numeric identifier(s) indicating the Session(s) this message is intended for. A list of Session numbers may be used, separated by a pipe | symbol.

0x02 0x03

32-bit value 32-bit value

Execution Number Execution Time

0x04

variable string

Command String

0x05

variable string

Result String

0x06

32-bit value

Result Status

0x0A

variable string

Session Number(s)

CORE API Version 1.21 - Page 12

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type=3 |0 0 0 0 0 0 0 0| Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-type=0x01 | TLV-len=4 | Pad (zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-type=0x02 | TLV-len=4 | Pad (zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Execution Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-type=0x03 | TLV-len=4 | Pad (zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Execution Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-type=0x04 | TLV-len=10 | Command String | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (... Command String cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (... Command String cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3-1 Execute Message Format

CORE API Version 1.21 - Page 13

3.4 Register message

The Register Message is message type 4. This message is used by entities to register to receive certain notifications from CORE or to register services. The following flags are used with the Register message: Add flag (01) - add a registration (same as no flags) Delete flag (10) - remove a registration, i.e. unregister Critical flag (100) - undefined Local flag (1000) - undefined Status request (10000) - request a list of child registrations Text output (100000) - response of child registrations Child registrations are defined as follows: if entity 1 registers with entity 2 and requests a list of child registrations, entity 2 will respond with a list of entities that it currently has registered with itself. Register TLVs may occur multiple times within a Register message, for example if there are several Wireless Modules. The TLVs for the Register Message are defined in Table 3-5 below.

CORE API Version 1.21 - Page 14

Table 3-5 Register Message Fields TLV Type 0x01 TLV Length variable string Field Wireless Module Description Registers a wireless module for use with CORE. The string contains a single model name. For example, the string simple for the simple module. Registers a mobility module for use with CORE. The string contains a single model name. For example, the string random waypoint for the random waypoint module. Registers a utility module for use with CORE. The string contains a single model name. For example, the string GPS for the GPS module. Registers a daemon that will handle Execution Messages. Registers a GUI that will display nodes and links. May trigger a Register Message response back to the GUI with daemon capabilities. Registers a daemon that will handle emulation of Nodes and Links. Registers a daemon that relays CORE messages. Optional numeric identifier(s) indicating the Session(s) this message is intended for. A list of Session numbers may be used, separated by a pipe | symbol.

0x02

variable string

Mobility Module

0x03

variable string

Utility Module

0x04 0x05

variable string variable string

Execution Server GUI

0x06 0x07 0x0A

variable string variable string variable string

Emulation Server Relay Session Number(s)

CORE API Version 1.21 - Page 15

3.5 Configuration message

The Configuration Message is message type 5. This message is used by an external entity to exchange configuration information with CORE. Configuration Request (request)

CORE

Configuration response (types, values, captions) Configuration data (types, values)

external entity

Figure 3-2 Configuration Messaging

Using this Configuration Message, CORE can cause the external entity to provide configuration defaults and captions for use in a GUI dialog box (for example when a user clicks configure), and after the dialog box has been filled in, CORE sends the entered data back to the entity. See Figure 3-2. The Configuration Message must contain the Configuration Object TLV. This identifies the object being configured. For example, this string might be one of the WLAN models listed in a previous Register Message. The Configuration Message must contain the Configuration Type Flags TLV. This TLV contains one or more flags indicating the content of the message. The valid flags are: 0001 = 0x1 = Request - a response to this message is requested 0010 = 0x2 = Update - update the configuration for this node (this may be used to communicate a Netgraph ID) 0100 = 0x3 = Reset - reset the configuration to its default values The Data Types TLV includes one or more 16-bit values that indicate the data type for each configuration value. The possible data types are described in Table 3-6.
Table 3-6 Data Types TLV Values Type number 1 2 3 4 5 6 Description 8-bit unsigned value 16-bit unsigned value 32-bit unsigned value 64-bit unsigned value 8-bit signed value 16-bit signed value Size (bytes) 1 2 4 8 1 2

CORE API Version 1.21 - Page 16

7 8 9 10 11

32-bit signed value 64-bit signed value 32-bit floating point value NULL-terminated string boolean value

4 8 4 variable 1

The Values TLV contains one or more strings, each representing a value. The strings are separated by a pipe | symbol. These values may be default values or data supplied by the user. The Captions TLV contains one or more strings, which may be displayed as captions in a configuration dialog box. The strings are separated by a pipe | symbol. Generally, the Data Types, Values, and Captions TLVs will refer to the same number of configuration items. This number may vary depending on the object being configured. One additional caption may be specified in the Captions TLV for display at the bottom of a dialog box.

CORE API Version 1.21 - Page 17

Table 3-7 Configuration Message Fields TLV Type 0x01 0x02 TLV Length 32-bit value variable string Field Node Number Configuration Object Configuration Type Flags Description Node number being configured. This could be the WLAN node number, for example. Names the object being configured. This could be the name of the wireless model, for example. Bit flags indicating the type of configuration message. Possible values are: 0001 = 1 = Request 0010 = 2 = Update 0100 = 3 = Reset List of data types for the associated Values; each type is a 16-bit value. Text list of configuration values, separated by a pipe | symbol. List of captions for dialog box display, separated by a pipe | symbol. Pathname of a bitmap for dialog box display. Optional text list of possible configuration values, separated by a pipe | symbol. Numeric value ranges may be specified with a dash, e.g. 30-70; individual options may be specified with a comma, e.g. 1,2,5.5,11; text labels for boolean values, e.g. on,off Optional text list of value groupings, in the format title1:1-5|title2:6-9|10-12, where title is an optional group title and i-j is a numeric range of value indices; groups are separated by commas Optionally indicate session number(s) for this configure message, possibly overriding the node number. A list of Session numbers may be used, separated by a pipe | symbol.

0x03

16-bit value

0x04 0x05 0x06 0x07 0x08

variable variable string variable string variable variable string

Data types Values Captions Bitmap Possible Values

0x09

variable string

Value Groups

0x0A

variable string

Session Number(s)

0x23 0x24 0x50

32-bit value 32-bit value variable string

Emulation ID Network ID Opaque data

User-defined data for passing any type of information.

CORE API Version 1.21 - Page 18

3.6 File Message

The File Message is message type 6. This message is used to transfer a file or a file location. Because files may be large, compression may be used or, if the two entities have access to the same file system, this message can provide the path name to a file. If the Add flag is specified, any existing file will be truncated. If the Delete flag is specified, the specified file will be deleted and the file data ignored. If neither the Add nor Delete flags are used, file data may be appended to the end of a file if it exists. If the Node Number TLV is present, the File Name TLV indicates the full path and name of the file to write on the specified nodes filesystem (where applicable). If the Node Number TLV is absent, then the File Name TLV indicates the destination file name on the hosts local filesystem, not the (virtual) filesystem of one of the nodes. The Source File Name TLV may optionally be used to specify a path accessible by the receiving entity. In this case, any file data is ignored, and data is copied from the source file to the destination file name. Note that the file data will likely exceed the TLV length of 255, in which case, the TLV Length field is set to zero, followed by a 16-bit value specifying the TLV length. The maximum file data length is therefore 65,536 bytes minus the length of the other TLVs. If the file exceeds 65,536 bytes in length, it should be transferred in chunks using the File Sequence Number TLV.

The TLVs for the File Message are defined in Table 3-8.

CORE API Version 1.21 - Page 19

Table 3-8 File Message Fields TLV Type 0x01 TLV Length 32-bit value Field Node number Description Indicates the node where the file should be written. If this TLV is absent, the file will be written on the host machine. The full path and name of the file to be written. Optionally specifies the file mode bits as used by the chmod(2) system call. Optional file number. May be a sequence number used to specify chunks of a file that should be reassembled, or other semantics defined by an entity. Optional file type provided so the receiving entity knows what to do with the file (e.g. service name, session hook.) Specifies a path name of a source file on the filesystem, so the file data TLV is not needed. Optional numeric identifier(s) indicating the Session(s) this message is intended for. A list of Session numbers may be used, separated by a pipe | symbol. The binary uncompressed file data. The binary file data that has been compressed with gzip compression.

0x02 0x03 0x04

variable string variable string 16-bit value

File name File mode File number

0x05

variable string

File type

0x06

variable string

Source file name

0x0A

variable string

Session Number(s)

0x10 0x11

variable binary data variable binary data

Uncompressed file data Compressed file data

CORE API Version 1.21 - Page 20

3.7 Interface Message

The Interface Message is message type 7. This message will add and remove interfaces from a node. While interface information may be contained in the Link messages, this separate message was defined for clarity. Virtual interfaces typically may be created and destroyed, while physical interfaces are generally either marked up or down. If the Add flag is specified, an interface is created. If the Delete flag is specified, the specified interface will be deleted. If neither the Add nor Delete flags are used, the interface will be modified according to the given parameters.
Table 3-9 Interface Message Fields TLV Type 0x01 0x02 0x03 TLV Length 32-bit value 16-bit value variable string Field Node number Interface Number Interface Name Description Indicates the node associated with the interface. Interface number, for associating with the interface numbers used in the Link message. The name of the interface, for example eth3. If this name is not specified, the name may be derived from the interface number. Optional IPv4 address assigned to this interface. Value in network byte order. Optional IPv4 network mask. Requires IPv4 address. Optional MAC address assigned to the interface. Usually only 48-bits of the 64-bit value are used. Optional IPv6 address assigned to the interface. Optional IPv6 network mask. Requires IPv6 address. Interface type specifier: 0 = Wired Ethernet interface, 1 = Wireless interface, other values TBD. Optional numeric identifier(s) indicating the Session(s) this message is intended for. A list of Session numbers may be used, separated by a pipe | symbol. 0 = Interface is up, 1 = Interface is down, other values TBD. The ID of the emulated interface. On FreeBSD for example this may be the Netgraph ID. Number identifying the network this interface belongs to, for associating with Link Messages for example.

0x04 0x05 0x06

32-bit value 16-bit value 64-bit value

IPv4 Address IPv4 Mask MAC Address

0x07 0x08 0x09

128-bit value 16-bit value 16-bit value

IPv6 Address IPv6 Mask Interface type

0x0A

variable string

Session Number(s)

0x0B 0x23

16-bit value 32-bit value

Interface state Emulation ID

0x24

32-bit value

Network ID

CORE API Version 1.21 - Page 21

3.8 Event Message

The Event Message is message type 8. This message signals an event between entities or schedules events in a session event queue. For example, here is an exchange of Event messages when the user presses the Start button from the CORE GUI: GUI Event(type=configuration state) CORE Services GUI Node() Link() CORE Services I am sending you node/link configurations. GUI Event(type=instantiation state) CORE Services I am done sending node/link configurations. Go ahead with instantiating the emulation. GUI Event(type=runtime state) CORE Services The emulation has been started, and entered the runtime state. Message Flags are currently used only to add and remove scheduled events. Event Message TLVs are shown in Table 3-10 below. Possible values for the Event Type TLV are listed in Table 3-11 below.
Table 3-10 Event Message Fields TLV Type 0x01 TLV Length 32-bit value Field Node number Description Optional. Indicates the node associated with the Event. When not specified, the Event may pertain to all nodes. Indicates the type of event this message describes. Optional name associated with the Event. Optional data associated with the Event. Event start time in seconds, a float value in string format. Optional Event number. Optional numeric identifier(s) indicating the Session(s) this message is intended for. A list of Session numbers may be used, separated by a pipe | symbol.

0x02 0x03 0x04 0x05 0x06 0x0A

32-bit value variable string variable string variable string 64-bit value variable string

Event Type Event Name Event Data Event Time Event Number Session Number(s)

Table 3-11 Event Type TLV Values Type number 1 2 3 4 5 6 7 8 Description Definition state Configuration state Instantiation state Runtime state Data collection state Shutdown state Start Stop

CORE API Version 1.21 - Page 22

9 10 11 12 13

Pause Restart File Open File Save Scheduled

CORE API Version 1.21 - Page 23

3.9 Session Message

The Session Message is message type 9. This message is used to exchange session information between entities. The following flags are used with the Session message: Add flag (01) - add new session or connect to existing session if it exists Delete flag (10) - remove a session and shut it down Status Response Flag (10000) request a list of sessions; if used in conjunction with the Add flag, request a list of session objects upon connecting Session Message TLVs are shown in Table 3-12 below. The Session number is required. However, the current session number may be unknown, and a value of zero can be used to indicate the current session.
Table 3-12 Session Message Fields TLV Type 0x01 TLV Length variable string Field Session number(s) Session name(s) Description Unique numeric identifier(s) for a Session. A list of Session numbers may be used, separated by a pipe | symbol. Optional name(s) associated with this Session. A list of Session names may be used, separated by a pipe | symbol. Optional filename(s) associated with this Session. A list of Session filenames may be used, separated by a pipe | symbol. Optional number of nodes in this session. A list of number of nodes may be used, separated by a pipe | symbol. Date and time the session was started. Optional thumbnail filename for displaying a preview image of this session. Option username. Used to inform which user is connecting to a session, for helping with e.g. file permissions. Opaque data associated with this Session.

0x02

variable string

0x03

variable string

Session file(s)

0x04

variable string

Node count

0x05 0x06 0x07

variable string variable string variable string

Date Thumbnail File Username

0x0A

variable string

Session opaque

CORE API Version 1.21 - Page 24

3.10 Exception Message

The Exception Message is message type 10 (0x0A). This message is used to notify components of warnings, errors, or other exceptions. No flags are defined for the Exception Message. Exception Message TLVs are shown in Table 3-13 below. The Exception Level is required.
Table 3-13 Exception Message Fields TLV Type 0x01 0x02 TLV Length 32-bit value variable string Field Exception Node number Exception Session number(s) Level Source Date Exception Text Exception opaque Description Optional node number indicating the exception is associated with a node. Optional numeric identifier(s) associating the exception with one or more Sessions. A list of Session numbers may be used, separated by a pipe | symbol. Required numeric value used to indicate level of severity for this exception. Optional text indicating the name of the component the generated the exception. Date and time string of when the exception was thrown. Required text describing the exception. Opaque data associated with this Exception.

0x03 0x04 0x05 0x06 0x0A

16-bit value variable string variable string variable string variable string

Exception Levels, used to indicate the severity of the exception, are defined in Table 3-14 below.
Table 3-14 Exception Levels Exception Level 1 2 3 4 Description Fatal Error Error Warning Notice

CORE API Version 1.21 - Page 25

4 Change Log
Version 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.10 1.11 1.12 Date 2/6/06 2/15/06 2/16/06 4/4/06 7/20/06 9/1/06 9/20/06 2/14/07 8/1/07 12/3/07 12/18/07 1/3/08 1/9/08 4/15/08 Description initial revision added the TLV format to allow flexibility in defining various fields that are suggested by Dan Mackley allow multiple nodes per packet as suggested by DM update fields to 32-bits, add padding for 32-bit boundary; total length changed to sequence number add IP, IPv6, and MAC address fields to Node Message correction of type/length field to 8 bits in all sections addition of Canvas selection for node location specification renamed to CORE API, removed message header added Execute Message; fix Link Message diagram; other minor fixes added Register Message; increase TLV lengths for link parameters, added some new TLVs, allow TLV length of 65,536, remove some figures changed order of link effect TLVs; BER becomes PER updated formatting added Configuration Message enhanced Register Message with additional module types; added types to Data Types TLV; Data Values TLV into string; distinguish between Emulation ID and Network ID, no longer overloading Node Number with Netgraph IDs; list maximum values and fix packet error rate to % Added separate Node Type table and new Model Type TLV for the Node Message; added critical flag Added Exec Server TLV to Register Message; added link type, interface numbers, and addressing TLVs to Link message; added MER, burst and multicast burst effects to Link message; use 64-bit number for MAC addresses instead of 48-bit; added local, status, and text flags; added Exec Status TLV Added File Message, GUI and server TLVs for Register; updated overview text Added Interface, Event, and Session Messages. Updated the overview section. Added Relay type to Register message. Added model type for WLAN nodes. Added EMANE node type and Opaque node TLV. Changed lat/long/alt Node TLVs to strings. Added Possible Values and Groups TLVs to Configuration message along with boolean data type. Added Emulation Server TLV to Node Message. Added services TLV to Node Message, Session Number and Opaque Data to Configuration and Link Messages. Added Key TLV to Link Message. Node Model TLV changed from 32-bit to string. PER changed to 64-bit value. Changed node types to accommodate different machine types, removing XORP, PC, Host types, which are now represented by node services. Changed link type TLV to separate wireless link/unlink events. Removed heading, platform type, platform ID TLVs from node message. Added flags and user TLV to Session Message. Added Exception Message. Changed File Type TLV to string in File Message. Added File Open and File Save event types. Added Session TLV to all messages (except Session, Exception) for connectionless messages, and changed Configuration Message Session TLV to a string. Added link TLVs for color and width. Added support for scheduled events, event time, and event number to the Event Message. Removed unused TLVs from Conf Message and Node Message; removed

1.13 1.14

5/15/08 11/12/08

1.15 1.16 (CORE 4.0)

6/19/09 8/6/10

1.17 (CORE 4.1) 1.18 (CORE 4.2)

12/23/10

8/18/11

1.19 (CORE 4.3) 1.20 (CORE 4.4)

2/10/12 7/30/12

1.21

3/20/13

CORE API Version 1.21 - Page 26

(CORE 4.5)

deprecated table of model types from Node Message.

CORE API Version 1.21 - Page 27