Akamai Multicast Interconnect for Carriers (AMIC) - Proof of Concept

Document created by Cheng Jin Employee on May 30, 2017Last modified by Cheng Jin Employee on Jun 5, 2017
Version 2Show Document
  • View in full screen mode

Skip to end of metadataBefore 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.

Intro

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

Tech Overview

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.

Config Details

Akamai Addresses

Akamai has allocated a list of Anycast address for IPv4 AMT relay discovery: 23.202.36.0/24, and a block of addresses as IPv4 Multicast sources: 23.212.185.0/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:

Address Type
Akamai IP
Note
AMT relay discovery address23.202.36.1

23.202.36.1 responds with a relay IP that can forward traffic from multicast source 23.212.185.1.

SSM Multicast source address23.212.185.1

23.212.185.1 is reachable via any AMT relay discovered from 23.202.36.1

SSM Multicast group address

232.43.211.200

This is the Multicast group we use for test traffic. Sending side is looping iperf-ssm (https://github.com/GrumpyOldTroll/iperf-ssm):
iperf --client 232.43.211.200 --udp --ttl 30 --bandwidth 1K --bind 23.212.185.1 --len 125 --time 900

 

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:

  1. Configure a Loopback0 interface
  2. Configure a tunnel using the Loopback0 interface as its source
  3. 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:

interface Loopback0
 ip address 10.100.201.100 255.255.255.255

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:

interface Tunnel0
 bandwidth 50000
 ip address 10.100.201.1 255.255.255.255
 ip pim passive
 ip igmp version 3
 tunnel source Loopback0
 tunnel mode udp ip
 tunnel destination dynamic
 tunnel dst-port dynamic
 tunnel src-port dynamic
 amt gateway traffic ip
 amt gateway relay-address 23.202.36.1

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 207.244.66.102).

The output of "show interface Tunnel0" should look like the following:

csr1#sh interface Tunnel0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 10.100.201.1/32
  MTU 9970 bytes, BW 50000 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 2/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel linestate evaluation up
  Tunnel source 10.100.201.100 (Loopback0), destination 207.244.66.102
   Tunnel Subblocks:
      src-track:
         Tunnel0 source tracking subblock associated with Loopback0
          Set of tunnels with source Loopback0, 1 member (includes iterators), on interface <OK>
  Tunnel protocol/transport UDP/IP
    TEID 0x0, sequencing disabled
    Checksumming of packets disabled
    source_port:50260, destination_port:2268
  Tunnel TTL 255
  Tunnel transport MTU 1470 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Last input never, output never, output hang never
  Last clearing of "show interface" counters 22:33:18
  Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 1000 bits/sec, 1 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     6248 packets input, 955944 bytes, 0 no buffer
     Received 0 broadcasts (6248 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     80 packets output, 8240 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

Reachability

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):

ip multicast-routing distributed
ip pim ssm default

And along interfaces on that path, turn on PIM-SM:

interface GigabitEthernet3
  ip pim sparse-mode

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 23.212.185.1, you need the following:

ip route 23.212.185.1 255.255.255.255 Tunnel0

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

Reference

  1. Automatic Multicast Tunneling. RFC 7450: https://datatracker.ietf.org/doc/rfc7450/
  2. 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
  3. 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

Attachments

    Outcomes