THOMSON REUTERS MATCHING API CLIENT SITE DEPLOYMENT GUIDE

Transcription

1 THOMSON REUTERS MATCHING API CLIENT SITE DEPLOYMENT GUIDE Date of issue: 29 June 2011

2 Legal Information Thomson Reuters All Rights Reserved. Thomson Reuters, by publishing this document, does not guarantee that any information contained herein is and will remain accurate or that use of the information will ensure correct and faultless operation of the relevant service or equipment. Thomson Reuters, its agents and employees, shall not be held liable to or through any user for any loss or damage whatsoever resulting from reliance on the information contained herein. This document contains information proprietary to Thomson Reuters and may not be reproduced, disclosed, or used in whole or part without the express written permission of Thomson Reuters. Any Software, including but not limited to, the code, screen, structure, sequence, and organization thereof, and Documentation are protected by national copyright laws and international treaty provisions. This manual is subject to U.S. and other national export regulations. Nothing in this document is intended, nor does it, alter the legal obligations, responsibilities or relationship between yourself and Thomson Reuters as set out in the contract existing between us. Matching API - Client Site Deployment Guide Page 2 of 24

3 Contents Contents About this document...4 Intended readership... 4 In this document... 4 Glossary... 4 Feedback... 4 Chapter 1 Introduction...5 Chapter 2 Matching API connectivity overview General Requirements for RFA/FIX Client Applications Connectivity requirements specific to RFA client applications Connectivity requirements specific to FIX client applications Connectivity requirements for Prime Broker Sites...7 Chapter 3 Topologies New Matching API only deployment Client Site with Matching APIs Hybrid Client Site...10 Chapter 4 Service IP Addressing and use Service Delivery Connecting to the Matching FIX Gateway Connecting to the Matching Point to Point Servers (P2PS) Example MAPI Application IP Addressing Requirements...16 Chapter 5 ASA5510 Firewall Deployment Firewall Choices Rules and Configuration ASA5510 Resiliency Arrangements...20 Matching API - Client Site Deployment Guide Page 3 of 24

4 About this document About this document Intended readership Thomson Reuters internal support staff planning or installing systems or client network and infrastructure personnel using and implementing the Thomson Reuters Matching API product. In this document This document describes network configuration options to support the Matching API product that uses FIX and RFA interfaces into Thomson Reuters Matching. Glossary Term AQ CNET DNS DR FIX FQDN IDN MFG MPLS PB PBC RFA TLAN Definition Auto Quote Client network, i.e. the client s own infrastructure Domain Name System Disaster recovery Financial Information exchange Protocol. Protocol for trading partners to communicate order related messages electronically. Fully Qualified Domain Name Integrated Data Network. Reuters network for delivery of information products. Matching FIX Gateway Multi-Protocol Label Switching Prime Broker Prime Broker Client Reuters Foundation API (RFA) Transactions LAN Feedback For more information please contact your Thomson Reuters Account Manager or current Transactions Business contact. Matching API - Client Site Deployment Guide Page 4 of 24

5 Chapter 1 Introduction Chapter 1 Introduction As part of our going commitment towards providing a world-leading FX Matching service Thomson Reuters has made a significant investment into its Thomson Reuters Matching service. The Thomson Reuters New Matching Program (NMP) delivers an enhanced Matching system that is high performing, scalable and extensible. The first phase of the NMP successfully upgraded the core Matching host on September 19 th The second phase delivers a completely new set of Matching API solutions. Later phases will introduce a new Matching user interface for spot traders as well as functional enhancements to the Matching service. The Matching APIs will replace our current Auto Quote API and consist of two interfaces, namely the Reuters Foundation API (RFA) and the Matching FIX interface. The RFA interface is used for price discovery and the Matching FIX interface is used for order entry, cancelation and post trade processing. The Financial Information exchange (FIX) Protocol is a widely used industry standard for order entry and post trade management. For further details you can register at and review the Thomson Reuters FIX messaging proposal which has been approved by FIX Protocol, Ltd. as part of their v5.0 SP2 EP100 release Matching API - Client Site Deployment Guide Page 5 of 24

6 Chapter 2 Matching API connectivity overview Chapter 2 Matching API connectivity overview We start by showing, in Figure 1, a high level logical architecture diagram of the Thomson Reuters Matching API service. Subscriber Trusted THOMSON REUTERS Network Figure 1: Thomson Reuters Matching API logical architecture 2.1 General Requirements for RFA/FIX Client Applications All FIX and RFA client applications are developed and managed by the client, not by Thomson Reuters. As such, client applications are deployed on the client s LAN. All FIX Order entry traffic originates from the client s LAN and is routed into the TLAN via a Thomson Reuters firewall. Subscriber applications connect to two services, a FIX gateway to support FIX protocol message workflows and a Point to Point server (P2PS) to provide market data to the RFA Market Data Feed Direct (MDFD) consumer. 2.2 Connectivity requirements specific to RFA client applications In lieu of planned future FQDN support clients will be provided with 4 IP addresses. These addresses are for the purposes below: One pair (2) for A and B connections to P2PSs located within their assigned primary regional distribution site. Another pair (2) for accessing the A and B P2SPs located at their designated secondary site. In the event of a primary site failure scenario, clients will be required to manually re-point their RFA applications accordingly. Matching API - Client Site Deployment Guide Page 6 of 24

7 Chapter 2 Matching API connectivity overview For day one, (prior to the deployment of the P2PS on the TLAN), clients will only be permitted to deploy a maximum of 2 RFA client applications per client site. 2.3 Connectivity requirements specific to FIX client applications In lieu of planned future FQDN support clients will be provided with 4 ip address used to access the live Matching FIX Gateway (MFG) in each service condition. The IP address is that of a firewall located within a Thomson Reuters regional data centre. The firewall effectively acts as a proxy for all FIX connections originating from the client site to the Thomson Reuters global data centre where the live MFG is deployed and running. These addresses are for the purposes below: Two for routing their FIX connections to the live and DR MFG from their assigned primary regional site. Two for routing their FIX connections to the live and DR MFG from their assigned secondary regional site. In the event of a primary site failure scenario, clients are required to manually re-point their FIX applications accordingly from Live to DR. Note: Under normal operating conditions (non DR scenarios) clients will be unable to establish connections to servers located within the Thomson Reuters DR site. FIX clients may optionally utilise one TLAN for RFA/FIX connectivity (e.g. mini-tlan) and another for credit purposes, both sites can trade into Matching under same Matching Site Id (Credit Code). This concept is explained in greater detail below. 2.4 Connectivity requirements for Prime Broker Sites Connectivity requirements for Prime Broker (PB) sites are the same as standard subscriber sites with the exception of the features highlighted below. Prime brokers have a unique requirement to login a Special Ticket User (STU). STUs are used for the processing of post trade messages generated from their Prime Broker Clients (PBCs). Prime Brokers may login their STUs from a: Matching Keystation Custom built FIX based post trade application FIX2TOF adaptor developed by Thomson Reuters. The following connectivity requirements apply to all STU deployment types: Any FIX STU s, including the FIX2TOF Adaptor developed and licensed by Thomson Reuters, must be deployed on the client LAN. FIX STUs connect via the Thomson Reuters firewall to the MFG to receive notifications and Trade Capture Reports (TCRs). Connectivity requirements to the MFG are identical to that of any other FIX application. Matching API - Client Site Deployment Guide Page 7 of 24

8 Chapter 3 Topologies Chapter 3 Topologies In this section we describe the supported topologies used in the Matching API service. Please liaise with you local Thomson Reuters Technical account manager who will be able to advise on the best approach to suit your business. 3.1 New Matching API only deployment In the first topology option we show a typical arrangement for deployment of the Matching API. In this example a Matching subscriber wishes to deploy the Thomson Reuters Matching APIs at a remote location from their primary trading site. Within the remote site the client does not have any requirement to manually execute trades, administer credit or manage payment instructions. This deployment option will typically be used by Prime Broker Clients (PBCs) but is also available to standard subscribers. The reduced footprint client site configuration is often referred to as a Mini-TLAN configuration and is shown in Figure 2. Figure 2: Mini-TLAN with RFA and FIX Matching API - Client Site Deployment Guide Page 8 of 24

9 Chapter 3 Topologies 3.2 Client Site with Matching APIs The following provides an example of a Matching subscriber who has completely migrated from AQ to RFA/FIX however they still have requirements to retain the Matching Keystations for the purpose of manual trading, payment instructions and credit management. This client site configuration is referred to as a Maxi-TLAN configuration and is depicted in Figure 3.. THOMSON REUTERS MATCHING MPLS TLAN Switch Transactions LAN FIX v5.0 SP2 EP100 (RFA market data) OMM via RSSL Client LAN TCSS TCSS Standard Matching FX Matching Keystation FX Matching Keystation Matching Matching C3 C3 MDFD FIX Engine TLAN Firewall Optional Subscriber Application Figure 3: Maxi-TLAN with RFA and FIX Matching API - Client Site Deployment Guide Page 9 of 24

10 Chapter 3 Topologies 3.3 Hybrid Client Site The following provides an example of a Matching subscriber who, in the process of migrating to RFA/FIX, wishes to retain their Auto Quote applications during their migration period. This client site configuration is referred to as a hybrid Maxi-TLAN configuration. In Figure 4 below the left Transactions LAN demonstrates the existing configuration found in an AutoQuote deployment with a firewall configuration supporting connectivity to/from the client LAN hosting the Matching API Application, etc. THOMSON REUTERS MATCHING MPLS TLAN Switch Transactions LAN FIX v5.0 SP2 EP100 (RFA market data) OMM via RSSL Client LAN TCSS TCSS Standard Matching FX Matching Keystation FX Matching Keystation Matching Matching C3 C3 AutoQuote FX Matching Keystation TLAN Firewall Optional MDFD FIX Engine Subscriber Application Figure 4: Hybrid Maxi-TLAN Client Site with AQ and RFA/FIX Matching API - Client Site Deployment Guide Page 10 of 24

11 Chapter 4 Service IP Addressing and use Chapter 4 Service IP Addressing and use 4.1 Service Delivery On completion of certification a series of IP addresses will be released which will provide connectivity to the Production (London) and Disaster Recovery (Geneva) Matching service via primary distribution systems located in the following regions: EMEA (London) Americas (Nutley) Asia Pacific (Singapore) And to the Production (London) and Disaster Recovery (Geneva) Matching service via secondary distribution infrastructure in: EMEA (Geneva) Americas (Hauppauge) Asia Pacific (Hong Kong) To demonstrate this addressing and configuration we shall consider connectivity to Production and DR Matching over a primary EMEA (London) distribution and secondary EMEA (Geneva). Figure 5 describes the connectivity routes to the service (legend overleaf). Figure 5: Connection routing to the Matching services in Production and DR Matching API - Client Site Deployment Guide Page 11 of 24

12 Chapter 4 Service IP Addressing and use Client Managed Targeting RFA Normal service. Primary distribution for market data Client Managed Targeting RFA Primary distribution failure. Secondary distribution for market data Client Managed Targeting FIX Normal service. Production (or DR) deal management via primary distribution Client Managed Targeting FIX Primary distribution failure. Production (or DR) deal management via secondary distribution Thomson Reuters Controlled Production Matching Service to primary distribution Thomson Reuters Controlled Production Matching service to secondary distribution Thomson Reuters Controlled Matching Host failure state. DR service to primary distribution Thomson Reuters Controlled Matching Host failure state. DR service to secondary distribution Given the diagram on the previous page we can now consider FIX and RFA (MDFD) connectivity individually. The tables in the following sections describe the IP address ranges for each service conditions to demonstrate where a particular IP address is valid. Please refer to sections 2.2 and 2.3 in this document for further details on how your IP targets will be allocated. Note: The assigned connectivity which is provided after certification of Matching API Application is subject to Rule 15.2 in the Matching Rule Book. This constrains the use of IP addresses in the tables below and only permits a Matching API Client to use the IP addressing supplied on completion of certification. Matching API - Client Site Deployment Guide Page 12 of 24

13 Chapter 4 Service IP Addressing and use 4.2 Connecting to the Matching FIX Gateway The following table details the IP address ranges for FIX message routes shown in section 4.1. Here we consider all three primary and all three secondary distribution centres and their relation to the service/routing conditions. As described in section 2.3; in the future when Thomson Reuters provided FQDNs are used to connect to the FIX proxy at the primary distribution site (or secondary in the event of a primary distribution site failure) a Matching Host DR state will automatically re point the FQDN to the DR Matching Host. This can be thought of as the green line to red line in the FIX path being switched on the FQDN association. If IP addresses are used instead of the FQDN the client must factor in the requirement to re point the FIX engine as required given the service conditions this is set out in Table 4.2: Table 4.2 FIX Gateway Address Ranges REGIONAL DISTRIBUTION CENTRE PRIMARY DISTRIBUTIONS FIX PROXY IP ADDRESS RANGE SERVICE CONDITION NORMAL OPERATION FIX MESSAGE ROUTES EMEA (LONDON) AMERICAS (NUTLEY) ASIA PACIFIC (SINGAPORE) To Use MFG IP addresses at the primary distribution site SECONDARY DISTRIBUTIONS EMEA (GENEVA) AMERICAS (HAUPPAUGE) ASIA PACIFIC (HONG KONG) To DR MODE FOR PRIMARY DISTRIBUTION SITE Transition from primary to secondary distribution site Use IP addresses at the secondary distribution site PRIMARY DISTRIBUTIONS EMEA (LONDON) AMERICAS (NUTLEY) ASIA PACIFIC (SINGAPORE) SECONDARY DISTRIBUTIONS EMEA (GENEVA) AMERICAS (HAUPPAUGE) ASIA PACIFIC (HONG KONG) To To DR MODE FOR MFG Matching Service transitions from normal operation to remote DR site Use secondary MFG IP addresses at the primary distribution site DR MODE FOR MFG AND PRIMARY DISTRIBUTION SITE Matching Service transitions and distribution site transition from normal operation to remote DR site Use secondary MFG IP addresses at the secondary distribution site Matching API - Client Site Deployment Guide Page 13 of 24

14 Chapter 4 Service IP Addressing and use Note: White background in the table denotes scenarios where the Matching Engines are running in the normal service mode. Grey background in the table denotes scenarios where the Matching Engines are running in a DR mode at a different location. Example: A client in the New York area wishing to configure network devices in preparation for use would be interested in the IP ranges for Americas (Nutley) and Americas (Hauppauge) Matching API - Client Site Deployment Guide Page 14 of 24

15 Chapter 4 Service IP Addressing and use 4.3 Connecting to the Matching Point to Point Servers (P2PS) Table 4.2 details the IP address ranges for connections to Point to Point Servers (P2PS) described in section 4.1 and Figure 5 by the RFA MDFD. Here it can be seen that there are only two service conditions to be considered as opposed to four in relation to FIX. These are: Primary Distribution site active Secondary Distribution site active (primary failure) Table 4.3 RFA P2PS Address Ranges DISTRIBUTION CENTRE P2PS TARGET IP ADDRESS RANGE SERVICE CONDITION ROUTE CONDITIONS PRIMARY DISTRIBUTION EMEA (LONDON) To NORMAL PRIMARY DISTRIBUTIONS AMERICAS (NUTLEY) ASIA PACIFIC (SINGAPORE) To Primary distribution IP address range OR SECONDARY DISTRIBUTION EMEA (GENEVA) SECONDARY DISTRIBUTIONS AMERICAS (HAUPPAUGE) ASIA PACIFIC (HONG KONG) To To DR MODE FOR DISTRIBUTION SITE Transition from primary to secondary distribution site Use P2PS IP addresses at the secondary distribution site OR Note: White background in the table denotes the scenario where the P2PS is running in a normal mode within the primary distribution site. Grey background in the table denotes a scenario where the P2PS is running in a DR configuration within a secondary distribution site Matching API - Client Site Deployment Guide Page 15 of 24

16 Chapter 4 Service IP Addressing and use 4.4 Example MAPI Application IP Addressing Requirements Putting together the information from sections 4.1, 4.2 and 4.3 we can provide an example of the IP address that a MAPI application may be given as part of its deployment into production. Table 4.4a demonstrates a typical list of IP addresses that might be released to you for one of your FIX sessions. The FIX client application must use the IP addresses provided below based on the service conditions previously outlined in section 4.2. The FIX session details which will include the FQDN, IP address, SenderCompId and User authentication details will be provided to you upon completion of your Matching API certification testing. Similarly for RFA table 4.4b lists an example allocation of P2PS target IP address to be used by the RFA client application under the two distinct service conditions mentioned in section 4.3. Table 4.4a Example allocated FIX target addressing FIX Gateway Target IP Address Service Condition NORMAL Primary distribution IP addresses DR Mode for Primary Distribution Site Transition from primary to secondary distribution site Use IP addresses at the secondary distribution site DR Mode for Matching FIX Gateway (MFG) Matching Service transitions from normal operation to remote DR site Use secondary MFG IP addresses at the primary distribution site DR Mode for Matching FIX Gateway (MFG) and Primary Distribution Site Use secondary MFG IP address at the secondary distribution site Note: White background in the table denotes scenarios where the Matching Engines are running in the normal service mode. Grey background in the table denotes scenarios where the Matching Engines are running in a DR mode at a different location. Matching API - Client Site Deployment Guide Page 16 of 24

17 Chapter 4 Service IP Addressing and use Table 4.4b Example allocated RFA target addressing P2PS Target IP Address Service Condition NORMAL Primary distribution IP addresses DR Mode for Primary Distribution Site Transition from primary to secondary distribution site Use P2PS IP addresses at the secondary distribution site Note: White background in the table denotes the scenario where the P2PS is running in a normal mode within the primary distribution site. Grey background in the table denotes a scenario where the P2PS is running in a DR configuration within a secondary distribution site. Matching API - Client Site Deployment Guide Page 17 of 24

18 Chapter 5 ASA5510 Firewall Deployment. Chapter 5 ASA5510 Firewall Deployment. 5.1 Firewall Choices The Matching API product requires access into matching via a Transaction LAN firewall to route the messaging to/from a client Matching API Application. The firewall(s) are intended to provide secure connectivity into the Matching Service fulfilling the security requirement to control/limit access to/from external services on the client LAN. Please refer to you sales point of contact for further information: A dual configuration of the Cisco Secure Remote Access Firewall ASA 5510 provided by Thomson Reuters provides a resilient configuration. Please refer to you sales point of contact for further information. 5.2 Rules and Configuration A predefined set of rules and configuration settings are implemented onto the chosen firewall deployment option. It is important that these firewall rules are maintained as they are implemented to not only protect the TLAN but to ensure correct and efficient message traffic routing to and from the Matching Host. This is as FIX and RFA traffic once inside the Matching Over IP (MOIP) circuit on the BT MPLS routing infrastructure is treated in the same manner as current Matching traffic. In order for this to be achieved it is important that client connections are presented to BT as having come from a reserved TLAN address of X.X.X.3 or in some cases X.X.X.4. The TLAN is therefore configured inside the firewall security and the Subscriber s infrastructure is considered outside the TLAN firewall security. RFC1918 addressing must not be propagated as it may clash with the Client s own addressing. Therefore there is a need to NAT the destination at the firewall. Table 5.2 below describes the particular settings that the ASA5510 uses to correctly integrate into the BT MPLS Matching Over IP (MOIP) delivery circuit. Table 5.2 Firewall configuration requirements. Configuration item Setting Details Open firewall port Non-SSL access to FIX Gateway. Open firewall port SLL access to FIX Gateway. Open firewall port Connection for RFA to P2PS. Diagnostics/Logs Network Address Translation Deny IP any log Translate MAPI service RFC1918 addresses to registered address space Has the effect of denying all other connections and logs this activity to file. A NAT to the x Thomson Reuters registered addresses Matching API - Client Site Deployment Guide Page 18 of 24

19 Chapter 5 ASA5510 Firewall Deployment. Configuration item Setting Details Connection/IP settings Connection/IP settings TLAN side of firewall connects to: xxx.xxx.xxx.3 xxx.xxx.xxx.4 The Matching host servers are provided in the following registered network range: /26 Essential setting which allows firewall traffic entering the TLAN to be routed correctly. This is in line with the Matching Over IP (MOIP) service package on MPLS. The designated TLAN IP which replaces xxx.xxx.xxx will be provided by your Thomson Reuters Technical Account Manager after BT MPLS connection setup. Firewalls and routers on the client side should be configured correctly to connect this range. Note: Specific production connection addressing will be provided after completion of certification. Connection/IP settings On TLAN switch the firewalls are connected to FASTETHERNET at: 1 st firewall to Port 0/6 on first switch 2 nd firewall to Port 0/6 on second switch Configuration on the TLAN switch is as below: interface FastEthernet0/6 description connect to 1 st switchport mode access switchport nonegotiate spanning-tree portfast firewall This port is configured as AUTO/AUTO. This is already setup on the switches and is shown for reference. Note: Whilst the default is AUTO some clients require the port to be set to 100 Full duplex. A check is therefore required to verify the CNET interface port setting. Matching API - Client Site Deployment Guide Page 19 of 24

20 Chapter 5 ASA5510 Firewall Deployment. 5.3 ASA5510 Resiliency Arrangements The ASA5510 can be provided as a standalone or resilient pairing. On the firewall the Cisco Adaptive Security Device Manager (ASDM) software is used to configure the device as required by the Matching service. These configurations are made by Thomson Reuters prior to client handover. In depth information regarding the Cisco device can be found on the Cisco website in the Navigating the Cisco ASA 5500 Series Documentation section at For reference a schematic of the resilient Active/Standby failover arrangement is shown in Figures 6 and 7 overleaf where Figure 6 shows normal operation and Figure 7 a situation under failure. This allows a Standby ASA to take over the functionality of a failed Active unit. When the active firewall fails it enters a Standby state leaving the Standby unit become Active. The Active firewall assumes the IP addresses and MAC addresses of the failed unit and begins passing traffic. The firewall that has become Standby takes the Standby IP addresses and MAC addresses. Network devices see no change in the MAC to IP address pairing and as such there is no ARP entry change required or time out seen anywhere on the network. Therefore client systems new not attempt any other connections and continue via the default gateway which will have switched transparently. Figure 6. Resilient Active/Standby ASA5510 pair Normal running Matching API - Client Site Deployment Guide Page 20 of 24

21 Chapter 5 ASA5510 Firewall Deployment. Figure 7. Resilient Active/Standby ASA5510 pair Switched running Matching API - Client Site Deployment Guide Page 21 of 24

22 Chapter 5 ASA5510 Firewall Deployment. 5.4 Client Network Address Information Gathering The ASA5510 forms the demarcation point of the Matching service into a client s network infrastructure. In order to configure routing correctly between the Matching host and the client s own Matching API Application the following pieces of IP information should be provided by the client. Items 4 and 5 and options accompanying items 6, 7 and 8 are repeatable up to a value of 5 i.e. we are able to support up to 5 separate client IP ranges/network: As per the note in Table 5.2 there is a requirement to check interface port setting. Whilst the default setting on the ASA device port is AUTO some clients require the port to be set to 100 Full duplex. A check is therefore required to verify the CNET interface port setting. Item IP Parameter Notes Mandatory/Opt ional 1 Client Network Interface IP Address <CNET Interface IP Address> This is the gateway the client will use for routing to the MAPI registered addresses. Mandatory 2 Client Network Standby Interface IP Address <CNET Interface standby IP Address> Required for configuration but not used for MAPI connections. Mandatory 3 Client Network Subnet Mask <CNET Interface Subnet Mask> The mask for items 1 and 2 Mandatory 4 Start of Client Application System IP Range <First FIX/RFA Client IP Range 1> Beginning of IP range of client systems hosting the Matching API Application Mandatory 5 End of Client Application System IP Range <Last FIX/RFA Client IP Range 1> End of IP range of client systems hosting the Matching API Application Mandatory 6 Network to route to <FIX/RFA Client Network 1> If routing is required for IP range defined in items 4 and 5 Optional 7 Subnet mask used in route <FIX/RFA Client Network 1 Subnet Mask> The mask for associated with item 6 Optional Matching API - Client Site Deployment Guide Page 22 of 24

23 Chapter 5 ASA5510 Firewall Deployment. Item IP Parameter Notes Mandatory/Opt ional 8 Gateway IP address for route <CNET Gateway IP Address> Gateway for route defined in item 6 and 7 Optional Matching API - Client Site Deployment Guide Page 23 of 24

24 2011 Thomson Reuters. All rights reserved. Republication or redistribution of Thomson Reuters content, including by framing or similar means, is prohibited without the prior written consent of Thomson Reuters. 'Thomson Reuters' and the Thomson Reuters logo are registered trademarks and trademarks of Thomson Reuters and its affiliated companies. For more information Send us a sales enquiry at financial.thomsonreuters.com/sales Read more about our products at financial.thomsonreuters.com Find out how to contact your local office financial.thomsonreuters.com/locations Date of issue: 29 June 2011