Before you Start:
The Akamai Multicast Internet for Carriers Proof of Concept is intended for customers and partners who wish to experiment with multicast and AMT technology. Note: There are currently no commercially available delivery services which will take advantage of the configurations listed below. Rather, it is an active area of R&D and the PoC gives an opportunity to engage deeply on the latest technology developments.
The explosive growth in OTT video traffic is demanding infrastructural investment to scale with the bandwidth required for streaming in HD and beyond. This is a common challenge faced by the CDN providers and service providers alike. At Akamai, we have always worked on using technology innovations to overcome scalability challenges. To this end, we are building our next-generation Media Acceleration technology to help enable a "broadcast to broadband" market transition.
One key area of innovation is our work in Multicast technologies. And one critical piece of enabling multicast is ensuring that carriers and service providers are able to connect to Akamai's Multicast backbone to deliver significant amounts of video traffic via Multicast rather than unicast.
The Akamai Multicast Interconnect for Carriers Proof of Concept (AMIC PoC) provides a recipe (below) for how to configure Automatic Multicast Tunneling (AMT) components at the Carrier premises for the purpose of proving that Carriers and Service Providers are able to work in an autonomous fashion to leverage multicast sources that Akamai is providing.
We believe it is very important to design the interconnect for ease of adoption, and we have set the following design goals:
- No Akamai proprietary technology on premise
- Deployment under service provider administration
- Supported as a router function, from well known brands
- Multicast tunneling must be dynamically provisioned (AMT rather than GRE)
- Low barrier to entry in terms of router configurations
Akamai has experimented with Multicast in the past, and our lessons learned indicated that it is critical that carriers themselves have full control over how Multicast is managed and implemented within their networks. To that end, we are advocating an open interconnect approach where Akamai will publish a set of standards-based instructions, and carriers can implement these instructions at their own discretion to interconnect with Akamai's Multicast backbone.
The interconnect between Akamai and a carrier can be seen as establishing an IP tunnel to encapsulate native Multicast traffic. To that end, we leverage the now IETF standard, Automatic Multicast Tunneling (AMT)1 to implement this encapsulation. Our use of AMT is mainly to facilitate the ingest of Multicast streams. We seek to establish one or more AMT tunnels between Akamai owned AMT relays and carrier owned AMT gateways to move Multicast traffic via controlled points into a carrier's network. Once inside a carrier's network, the carrier's own policy will dictate how the Multicast traffic will propagate inside its own network. Akamai will also make available Native and AMT Multicast client software for end user devices as part of it's Media Acceleration suite of Acceleration and Efficiency technologies.
The diagram below gives a high level overview of how this interconnect is intended to work. As indicated, the "Carrier AMT Gateway" is where the AMT specific instructions would be implemented in order to connect to Akamai's Multicast backbone.
Akamai has allocated a list of Anycast address for IPv4 AMT relay discovery: 18.104.22.168/24, and a block of addresses as IPv4 Multicast sources: 22.214.171.124/24.
Separately, there is a list of Anycast addresses for IPv6 AMT relay discovery: 2600:14e0:8::/48 and a block addresses as IPv6 Multicast sources: 2600:14e0::/48.
We have setup a publicly reachable AMT infrastructure as of March 2017, to which you can connect your own Multicast enabled networks. Below is the information you will need to connect to our setup:
|AMT relay discovery address||126.96.36.199|
188.8.131.52 responds with a relay IP that can forward traffic from multicast source 184.108.40.206.
|SSM Multicast source address||220.127.116.11|
18.104.22.168 is reachable via any AMT relay discovered from 22.214.171.124
|SSM Multicast group address|
This is the Multicast group we use for test traffic. Sending side is looping iperf-ssm (https://github.com/GrumpyOldTroll/iperf-ssm):
Cisco CSR1000V Configuration
AMT Tunnel Config
We have selected CSR1000V because it is a recommended platform for AMT tunneling by Cisco. For those that are already familiar with Cisco terminology, AMT supports is built on top of the existing tunnel interface. The configuration that worked for us is to:
- Configure a Loopback0 interface
- Configure a tunnel using the Loopback0 interface as its source
- Configure AMT
Here is the Cisco configuration for our Loopback0 (please use an IP address appropriate for your network instead of 10.100.201.100) and please note the 32-bit netmask:
and the Cisco configuration snippet for Tunnel0 (please use an appropriate source IP address instead of 10.100.201.1) and again note the 32-bit netmask:
Please note the IP address used on the line "amt gateway relay-address" is the IP of the AMT relay discovery server, not an actual AMT relay. The relay address is obtained dynamically by the gateway during relay discovery (in the example output below, it is 126.96.36.199).
The output of "show interface Tunnel0" should look like the following:
You'll need to configure multicast routing in your network.
If you have downstream multicast routers, you'll probably want to configure PIM. For our traffic, you only need to handle ordinary SSM traffic, so the configuration is simple; just enable multicast routing and allow the default PIM handling for SSM in all the routers along the paths from the gateway to any hosts that might connect (including the router with the AMT gateway configured):
And along interfaces on that path, turn on PIM-SM:
For the reverse-path join propagation, you'll also need to configure a static route for each of the source addresses in the router with the AMT gateway configured. For example, for 188.8.131.52, you need the following:
Assuming you have some kind of IGP running, this will propagate the source throughout your network so that joins will propagate back to your gateway. These sources are reserved as multicast sources.
Testing and Debugging
In a follow-up document, we describe how one could build a lab setup to connect to our Multicast backbone https://community.akamai.com/docs/DOC-8143
- Automatic Multicast Tunneling. RFC 7450: https://datatracker.ietf.org/doc/rfc7450/
- Cisco AMT commands for IOS 4.x: http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-3/multicast/configuration/guide/b_mcast_cg43xcrs/b_mcast_cg43xcrs_chapter_011.html
- Cisco AMT commands for IOS 5.x http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r5-2/multicast/command/reference/b-mcast-cr52xcrs/b-mcast-cr52xcrs_chapter_0110.html