iLink uses the FIX Performance (FIXP) protocol to establish and manage bi-directional sessions. Per the FIXP protocol, a FIX session is defined as a bi-directional stream of ordered messages between two parties within a continuous sequence number series. With iLink, the Convenience Gateways (CGW) and Market Segment Gateways (MSGW) will support weekly client FIX sessions and also support mid-week initialization.

Contents

1 FIXP Session Attributes
2 Universally Unique Identifier (UUID)
- 2.1 UUID Rules
- 2.2 Re-Setting UUID
3 Weekly Reset
4 Session Security
5 FIXP Session Messages

FIXP Session Attributes

In iLink, for each customer, the MSGW starts the session at the beginning of the week. A FIXP session will be maintained by default on a weekly basis; however, the customer can Negotiate, Establish, and Terminate multiple times. Each FIXP session will also be represented with a Universally Unique ID (UUID), which should be a current timestamp.

The term, FIX connection, has a new connotation in iLink. A successful logon consists of a two-step process that involves first Negotiation and then Establishment.

The exchange will support a FIXP session created at the beginning of the week all through the end of that week. The customer can then Establish and Terminate FIX connections multiple times intra-day or at the end of each day, with the same UUID or Negotiate the new FIXP session with a new UUID as well.

Universally Unique Identifier (UUID)

Each FIXP session established at the start of the week, intra-day, or at the beginning of each trading day is represented with a unique UUID value set by the customer as a 64-bit value. CME Group recommends using the system timestamp, which represents the number of microseconds since epoch (Jan 1, 1970) as the timestamp. Business messages received from the exchange are recoverable for that sequence number + UUID combination.

UUID Rules

The following rules apply to the UUID:

UUID must be sent in the Negotiate message and that ID is used for the lifetime of the connection.
Customer must reset sequence numbers back to 1 for each direction (from customer to CME and from CME to customer) every time they negotiate with new UUID.
UUID in the Negotiate message is greater than the UUID used in the last successful Negotiate/Establish message.
- This will prevent usage of duplicate UUID's intraweek, which can affect subsequent retransmission of those messages.
- For this reason it is strongly recommended to use current timestamp value (number of microseconds since epoch) as UUID.
RequestTimestamp must be current timestamp in nanoseconds.
Customers will be able to use the same UUID across all segments at the same time.
One UUID can be used by more than one customer.
A UUID previously used on segment ‘X’ can be used to negotiate on segment ‘Y’ if never used on ‘Y’ by the given customer and higher than the most recent UUID used by that customer on ‘Y’.

Re-Setting UUID

In the event of customer application failure, it may be necessary to reset the UUID intra-session on the same trading day to force synchronization of sequence numbers to and from the exchange.

Important:

Do not Terminate the FIXP session and Re-Negotiate with a new UUID as a normal response to a Not Applied message.
Re-Negotiate with a new UUID should be used only to recover from a disaster situation that cannot be recovered via the use of Sequence message.
Re-Negotiating with a new UUID will mean recovering messages sent by the exchange in the previous FIXP session with the previous UUID.
Re-Negotiating with a new UUID resets the inbound and outbound sequence numbers back to "1" so sending a higher than expected sequence number to the exchange in the Establish message will result in successful Establishment followed by a Not Applied message, and the new NextSeqNo in the Establish message will be adopted as the new expected sequence number.

Weekly Reset

CME will internally reset its inbound and outbound sequence numbers to “1” at the start of each week. The customer should also reset their sequence numbers in both directions prior to negotiating and establishing a FIX session on Sunday.

When FIXP sessions are established at the start of each week, the customer must initiate a session by sending the Establish message (after Negotiation) with NextSeqNo as “1”.

CME will respond with an Establishment Acknowledgment confirmation with NextSeqNo as “1”.

If the customer does not reset the outbound sequence number to the exchange to “1” at the start of each week, they will receive a Terminate message informing them of this error in the Code field.
If a new UUID is assigned to subsequent FIXP sessions after the first, the sequence stream is reset to '1' in both directions (from customer to exchange and exchange to customer).

Session Security

The customer will authenticate an iLink session by digitally signing FIXP Negotiate and Establish messages using a hashed message authentication code (HMAC). In general, the customer interaction with CME will be as follows:

Customer logs into the CME Self Service Portal using 2-factor authentication over a secure channel (HTTPS).
CME generates a pair of cryptographically random keys—an Access Key and a Secret Key—for the customer. The keys are provided to the customer and also securely stored in a secure vault with CME.
Customer connects to iLink and sends a digitally signed Negotiate or Establish message. The digital signature is generated using a hashed message authentication code (HMAC) based on the contents of the message and the Secret Key and is included in the Login message or Negotiate and Establish messages sent to CME.
CME processes the Negotiate or Establish messages, calculates the digital signature using the same HMAC based process, and compares the calculated signature with the signature provided on the customer's Negotiate or Establish messages. If the signatures match, the Negotiate or Establish messages are authentic and validates that the sender has the Secret Key.

The details of of calculating the digital signature are described below.

Steps to Sign the Negotiate and Establish Messages

Create the canonical Negotiate or Establish message.
Create Signature using Secret Key provided by CME and Canonical Message.
Populate HMAC Signature plus Access Key ID fields of the Negotiate and Establish messages.

Only the field value—not the field name—must be used for the calculation of HMAC signature.

Example: where SessionID=<ABC>, use only 'ABC'.

Step 1 - Create the Canonical Message

These field values must be assembled in this order with the values concatenated into a single string delimited by the new line character (i.e. ‘\n’).

Negotiate Message

The required FIXP fields in Negotiate message are:

RequestTimestamp (A timestamp older than 5 seconds will be rejected as stale.)
UUID
SessionID
FirmID

An Example Canonical message for Negotiate:

“RequestTimestamp” + "\n" + “UUID” + "\n" + “SessionID+ "\n" + FirmID

Sample Code to Generate Canonical Negotiate Message

public String prepareCanonicalMessageForNegotiate(){

long requestTimestamp = 1563720650008L;

long uUID = 1563720660068L;

String session = "ABC";

String firmID = "007";

StringBuilder canonicalMsg = new StringBuilder();

canonicalMsg.append(requestTimestamp).append(New_Line);

canonicalMsg.append(uUID).append(New_Line);

canonicalMsg.append(session).append(New_Line);

canonicalMsg.append(firmID);

return canonicalMsg.toString();

}

Establish Message

The required FIXP fields in the Establish message are:

RequestTimestamp (A timestamp older than 5 seconds will be rejected as stale.)
UUID
SessionID
FirmID
TradingSystemName
TradingSystemVersion
TradingSystemVendor
NextSeqNo
KeepAliveInterval

An Example Canonical message for Establish:

“RequestTimestamp” + "\n" + “UUID” + "\n" + “SessionID+ "\n" + FirmID+ "\n" + “TradingSystemName” + "\n" + “TradingSystemVersion” + "\n" + “TradingSystemvendor” + "\n" + “NextSeqNo” + "\n" + “KeepAliveInterval”

Sample Code to Generate Canonical Establish Message

public String prepareCanonicalMessage For Establish(){

long requestTimestamp = 1563720650008L;

long uUID = 1563720660068L

String session = "ABC";

String firmID = "007";

String tradingSystemName = " ";

String tradingVersionId = " ";

String tradingSystemVendorId = " ";

long nextSeqNo = 1;

long keepAliveInterval = 30;

StringBuilder canonicalMsg = new StringBuilder();

canonicalMsg.append(requestTimestamp).append(New_Line);

canonicalMsg.append(uUID).append(New_Line);

canonicalMsg.append(session).append(New_Line);

canonicalMsg.append(firmID).append(New_Line);

canonicalMsg.append(tradingSystemName).append(New_Line);

canonicalMsg.append(tradingSystemVersionId).append(New_Line);

canonicalMsg.append(tradingSystemVendorId).append(New_Line);

canonicalMsg.append(nextSeqNo).append(New_Line);

canonicalMsg.append(keepAliveInterval);

return canonicalMsg.toString();

}

Step 2 - Create Signature Using the Secret Key and Canonical FIX Message

The signature is a hash (digest) of the canonical message created in Step 1 using the Secret Key provided by CME.

The Secret Key downloaded from Request Center is Base64 URL Encoded. Customers must decode the secret key first.

Example of Creating Signature Using HMAC SHA256 in Java 8+

The HMAC signature is populated in a fixed length string field (i.e. String32Req) since SHA-256 signature is always 32 bytes.

While real logic provides two options to encode this field—as a string and as a byte array—the byte array option should be used.

Encoding options for SHA-256 (256 bits long):

Base64URL encoding FIX ASCII: 6 bits per char = CHAR(44)including padding character
Hex: 4 bits per char = CHAR(64)
- HEX example → 617633EFEF2F98DCA32DD3BD8407122B9B375CF4BC076930F24C1F7A0F930094
Binary: 8 bits per byte = BINARY(32)
- Binary example → byte array:[97, 118, 51, -17, -17, 47, -104, -36, -93, 45, -45, -67, -124, 7, 18, 43, -101, 55, 92, -12, -68, 7, 105, 48, -14, 76, 31, 122, 15, -109, 0, -108]

The signature should be encoded as a byte array.

Signature calculation in Java:

public byte[] calculateHMAC(final String canonicalRequest, final String userKey) {
    byte[] hash = null;
 
    try
    {
      // Init HMAC instance
      Mac sha256HMAC;
      sha256HMAC = Mac.getInstance("HmacSHA256");
 
      // Initialize HMAC instance with the key
      // Decode the key first, since it is base64url encoded
 
      byte[] decodedUserKey = Base64.getUrlDecoder().decode(userKey);
      SecretKeySpec secretKey = new SecretKeySpec(decodedUserKey, "HmacSHA256");
      sha256HMAC.init(secretKey);
 
 
      // Calculate HMAC
      hash = sha256HMAC.doFinal(canonicalRequest.getBytes("UTF-8"));
 
    } catch (NoSuchAlgorithmException | InvalidKeyException | IllegalStateException | UnsupportedEncodingException e)
    {
      e.printStackTrace();
    }
 
    return hash;
  }
 
 
}

Step 3 - Populate HMAC Signature Plus Access Key ID fields of the Negotiate and Establish Messages

tag 39004-AccessKeyID - contains the AccessKeyID
tag 39005-HMACSignature - contains the HMAC signature

FIXP Session Messages

FIXP session messages are summarized as follows:

Stage	Message Name	From \| To	Purpose

Stage	Message Name	From \| To	Purpose
Initialization	Negotiate	Client System to CME Globex	Initiates Connection
	Negotiation Response	CME Globex to Client System	Accepts Connection
	Negotiation Reject	CME Globex to Client System	Rejects Connection
Binding	Establish	Client System to CME Globex	Binds Connection
	Establishment Acknowledgment	CME Globex to Client System	Accepts Binding
	Establishment Reject	CME Globex to Client System	Rejects Binding
Transferring	Sequence	Client System to CME Globex CME Globex to Client System	Initiates a Sequenced Flow, Keep Alive
	Retransmit Request	Client System to CME Globex	Requests Replay
	Retransmission	CME Globex to Client System	Accepts Replay
	Retransmit Reject	CME Globex to Client System	Rejects Replay
	Not Applied	CME Globex to Client System	Negative Acknowledgment of Missed Messages
Unbinding	Terminate	Client System to CME Globex CME Globex to Client System	Kill Connection Ungracefully or Gracefully

Overview Diagram

This diagram provides an overview of the session Establishment, Binding, and Unbinding process.

CME Group Client Systems Wiki

iLink Binary Order Entry - Session Layer