Multicast-Enabled Markets
The use of multicast in financial environments is very prevalent, and it is extremely important for business application in the trade environment. This section introduces you to multicast design and fundamentals of financial networks. The elements of the financial network are stock exchanges, financial service providers, and brokerages (see Figure 5-19). These domains are not only separate multicast networks, they are separate entities; for example, NASDAQ is an example of a stock exchange, Bloomberg is an example of a financial provider, and JPMorgan is an example of a brokerage.
)
Figure 5-19 Market Domain Feeds
As you will see, the multicast applications must function across all these environments to provide a quality end-to-end user experience. Before we review multicast network design, you must understand market data delivery, which consists of two main phases.
Phase 1: The stream is brought from the exchange to the brokerage network. The feeds are terminated at the customer premises. These multicast streams are normalized and republished by feed handlers in the data center.
Phase 2: The second phase involves injecting the normalized data stream into the application messaging bus, which feeds the core infrastructure of the trading applications. The data in the application messaging bus is used by a multitude of applications that use the market data streams for live trades, long-term trending, arbitrage, risk modeling, compliance, and so on. Many of these applications listen to the feeds and then republish their own analytical and derivative information. For example, let’s consider a CSCO stock comparison. A brokerage might compare the offered price of CSCO to the option price of CSCO on another exchange and then publish ratings that a different application might monitor to see how far out of sync they are. A complex analytical engine provides traders relevant information related to selling or buying in the market in real time at trade floor stations. The application bus is needed for network designers to understand the system. These data streams are typically delivered over a reliable multicast transport protocol. Traditionally, this has been TIBCO Rendezvous, which operates in a publish-and-subscribe environment. The application has a built-in reliability mechanism by which the market data retransmission is sent using a unicast stream.
Let’s review the network components.
Exchange network: An exchange network includes the exchange data center, where the servers process financial orders. The financial orders based on the application are sent as two feeds, feed A and feed B. The service distribution network feeds these transmissions to the edge that connects to the financial service provider. Note that some exchange networks outsource their service distribution network; in such a case, the multicast domain within the exchange network has two domains for control.
Financial service provider (FSP): The FSP is the provider network that extends over a regional or global area. The design of regional and global is tied to the FSP’s business model and customers. The network design is similar to that of a traditional enterprise WAN.
An additional element of the FSP is the service edge network, which includes access points of presence (POPs) to support necessary service policies for positioning services for end brokerage customers. Some FSPs also offer a service that involves normalization of market data feeds to reduce errors (if any) in the transmission by identifying any missing parameters in the ordering process. Such a service is offered by the brokerages themselves or could be tied to a service from the FSPs. The FSPs also provide business-to-business service of market data feeds for brokerages that deal with high volume. This necessitates a network transport system created for differential services.
Brokerage network: This network is divided into two components:
The back-office network: This network includes trading and security, trading record keeping, trade confirmation, trade settlement, and regulatory compliance, and so on. This network is highly secured and always protected by firewalls.
The front-end brokerage network: This is where the feeds (A and B) are collapsed by an application (such as TIBCO) in a messaging bus architecture for arbitration. These streams are distributed to the traders.
Multicast Design in a Market Data Environment
This section provides an overview of market data multicast design considerations. For more information, see IP Multicast, Volume 1 and Chapter 1, “Interdomain Routing and Internet Multicast,” Chapter 2, “Multicast Traffic Engineering, Scalability, and Reliability,” and Chapter 3, “Multicast MPLS VPNs,” of this book. Figure 5-20 illustrates multicast domains from the exchange, FSP, and brokerage environment.
)
Figure 5-20 Multicast Domain in FSP and Brokerage Data Environments
The exchange network produces two live feeds (feeds A and B). The feeds, which are identical, are created for redundancy. The feeds are transported using different source and multicast groups. The multicast and unicast routing information base (RIB) design should ensure path diversity for the feeds. Physical path diversity and node diversity are employed to create the separation. Ideally, for complete redundancy, separate infrastructures with isolated control and data planes provide resiliency and reliability to the transport mechanism. Multicast designs should include separate RPs for multicast routing for different feeds, tied to separate multicast address groups. If platform support is available, Bidir-PIM is recommended for this type of market data distribution. At the FSP exchange points, the bidir-neighbor-filter command should be used on the customer-facing interfaces. This ensures that designated forwarder (DF) election occurs, even if the downstream router does not support Bidir-PIM. RP redundancy for Bidir-PIM is created by using the Phantom-RP method.
The exchange between two domains is achieved by using one of the methods for interdomain exchange reviewed in Chapter 1: static or dynamic provisioning between interdomain multicast. Normally, static provisioning methods are used if the FSP requires the feeds constantly. The dynamic provisioning method allows the FSP to manage the feeds based on the bandwidth available and offers more granular bandwidth management. The dynamic method provides more control and is therefore recommended.
FSP Multicast Design
Figure 5-21 provides an overview of the FSP network and connectivity. This is the network on which the multicast domain is overlaid.
)
Figure 5-21 FSP Network and Connectivity
The design requirements for an FSP are similar to those of a regular service provider. The key difference is that an FSP may require higher reliability and strict latency. The market data streams are typically forwarded statically into the FSP, as noted earlier in this chapter. Path separation for the multicast streams is created by traffic engineering methods, or the FSP can have a dual-core architecture to create complete isolation and separation of the control and data planes. For segmentation of traffic, MPLS VPN service is commonly utilized. Multicast transport schemes applicable to WAN, traffic engineering, and MPLS VPN are applied in the design.
Brokerage Multicast Design
The multicast design of the front-office brokers transports the multicast feed to the application message bus. Each feed terminates at a different data pod infrastructure; this pod consists of a message bus for handling the feeds. The design is simple, but multiple geographic locations or sites for the pod distribution require multicast to be enabled over a WAN or metro network. Generally, Bidir-PIM is best in this scenario. Figure 5-22 illustrates the multicast data feed to a brokerage network. The figure shows the multicast brokerage design.
)
Figure 5-22 Brokerage Network Multicast Feed
The back-end office that hosts the traders has separate RPs for the new multicast streams available from the different application handlers and should use Bidir-PIM. Due to network platform restriction, if Bidir-PIM is not a viable option, PIM-SM with shortest path tree (SPT) threshold infinity should be considered. Multiple RPs can be deployed, each tied to a multicast group range based on the application use case.