How to run Schneider Electric’s Responder OMS using AWS Transit Gateway multicast

Government agencies and public sector organizations in energy and utilities rely on smart solutions to detect, locate, and fix utilities outages faster based on input from their customer contact centers and field crews.

One popular outage management solution (OMS) is Schneider Electric’s ArcFM Responder (Responder) OMS. With the shift to AWS Cloud in the public sector, there is a growing demand to deploy and host the Responder solution on AWS. However, for the Schneider Electric’s Responder solution to work on AWS, many application servers within the Responder environment need to communicate together using IP multicast. This is covered in the “Tech Paper – Responder Communication Framework.”

As announced at re:Invent 2019, AWS Transit Gateway now supports routing Internet Protocol (IP) multicast traffic between attached Amazon Virtual Private Cloud (Amazon VPC) connections, making it possible to deploy and run the Schneider Electric’s Responder solution on AWS.

In this post, we discuss how to deploy the Schneider Electric’s Responder environment on AWS.

What is multicast?

Multicast delivers a single stream of data to many users simultaneously and is a preferred method to stream multimedia content and subscription data to a group of subscribers. Previously, customers had to either maintain legacy on-premises networks for multicast applications or implement complex workarounds to run these workloads on the cloud.

About Transit Gateway

AWS Transit Gateway is a service that enables customers to connect their Amazon VPCs and their on-premises networks to a single gateway. Without AWS Transit Gateway, you need to peer each Amazon VPC to each other and to each onsite location using a virtual private network (VPN) connection, which can be complex as its scales. With AWS Transit Gateway, you simply connect each Amazon VPC or VPN to the AWS Transit Gateway and to route traffic to and from each VPC or VPN.

AWS Transit Gateway multicast

With native support for multicast, AWS Transit Gateway enables customers to easily deploy their multicast applications on the cloud and take advantage of the elasticity, scalability, reliability, and other benefits offered by AWS.

AWS Transit Gateway multicast is the one of the few cloud-based multicast solutions available to quickly distribute the same content to multiple, specific destinations. Transit Gateway multicast eliminates the requirement for on-premises multicast networks, enabling the transmission of data straight from multicast applications on AWS. It reduces the bandwidth need across the network for high-throughput applications such as video conferencing, media, or teleconferencing. With less congestion, multicast helps end users get information quickly.

To learn more about IP multicast key concepts and definitions such as multicast domain, multicast group, multicast source, and multicast group member, check out “Multicast on Transit Gateways Overview” documentation.

Architecture

Figure 1 shows the high-level architecture for deploying an environment to host and run Schneider Electric’s Responder Solution on AWS.

Figure 1: High-level architecture for hosting Responder on AWS

Setup

After setting up the POC high-level architecture above including the VPC, public and private subnets, and Amazon Elastic Compute Cloud (Amazon EC2) instances, complete the following steps:

Create a Transit Gateway in the VPC view

Figure 2: Create a Transit Gateway in the VPC view

Create a Transit Gateway VPC attachment

This should be attached to the Transit Gateway created as per Figure 2.

Figure 3: Create a Transit Gateway VPC attachment

Create a Transit Gateway Multicast Domain

This should be associated with the Transit Gateway created in Figure 2.

Figure 4: Create a Transit Gateway Multicast Domain

Transit Gateway Multicast Association

Associate the Transit Gateway Multicast Domain with the Transit Gateway Attachment created in Figure 2.

Figure 5: Transit Gateway Multicast Association

Transit Gateway Multicast Group

Create Multicast sources and members for a specified Multicast Group IP address.

Figure 6: Transit Gateway Multicast Group

Important Note: Currently, there is a service limitation of one source per multicast group IP address i.e. you can add one multicast source for any particular multicast group IP address for example 239.254.0.1. To raise this limit, contact AWS support requesting to increase the limit of sources per Transit Gateway Multicast Group IP address.

Testing Multicast on EC2 with Windows 2016 server

Enable Message Queuing Server on Server Manager in Windows Server 2016 on EC2. For more information, please follow the documentation from Microsoft on installing Message Queuing (MSMQ).
Add this EC2 instance as a sender and a member in the Multicast Group IP address 239.254.0.1 in the Transit Gateway as shown in Figure 6.

Figure 7: Enable Message Queuing Server on Server Manager

Create a private message queue with the name POC and a multicast address and port; for example, 239.254.0.1:8005.

Figure 8: Create a private message queue

Send a multicast packet using any multicast packet sender. In this example, I use the mqsender utility, which is part of the MSMQ tools, and can be downloaded from this link.

Figure 9 shows an example command on Windows PowerShell to send a multicast packet:

.\mqsender.exe /f:multicast=239.254.0.1:8005 /c:5 PGMTEST

Figure 9: Windows PowerShell to send a multicast packet

View the multicast packets in the Windows Message Queue.

Figure 10: View the multicast packets in the Windows Message Queue

You can also view the multicast packets in all other EC2 Windows instances, which are added as members in the same Multicast Group IP address 239.254.0.1.

Applying Multicasting Address in Schneider Electric’s Responder OMS

Since we have now successfully tested that multicasting works fine between EC2 nodes, we can go ahead and install the Schneider Electric’s Responder OMS solution on the EC2 instances.

Please refer to the Schneider Electric’s Responder installation instructions.

You can now open the Miner.Responder.DataServices.exe.config file to apply the Multicasting address 239.254.0.1:8005 as shown in the screenshot in Figure 11.

Figure 11: Miner.Responder.DataServices.exe.config file

You can now use the Responder explorer application to view all the incidents, using the multicasting.

Figure 12: Responder explorer

Conclusion

You have now configured Transit Gateway Multicast group in a VPC and tested that multicasting works correctly between the various EC2 instances you have configured as senders or members in the multicast group.

Now, install the Schneider Electric’s Responder solution on the EC2 machines and operate it on AWS, using the multicast group you configured.

Considerations

You need to create a new transit gateway to enable multicast.
You cannot share multicast-enabled transit gateways with other accounts (using AWS Resource Access Manager).
Multicast group membership is managed using Amazon VPC Console or the AWS CLI.
AWS support Multicast Listener Discovery (MLD) on IPv4 and IPv6 for managing group membership.
A subnet can only be in one multicast domain.
If you use an EC2 instance that is not based upon Nitro hardware (non-Nitro instance), you need to disable the Source/Destination check. For information about disabling the check, see “Changing the Source or Destination Checking” in the Amazon EC2 User Guide for Linux Instances.
A non-Nitro instance cannot be a multicast sender.

Review the “Multicast on Transit Gateways” overview documentation for more information regarding the considerations.

Learn more about AWS for power & utilities.

Credits

Thank you to the team at Bahrain Electricity and Water Authority, Geographic Information Systems (GIS) department for their sheer collaboration and support to the AWS team in Bahrain to accomplish the deployment of Schneider Electric’s Responder OMS on AWS.