Here, you'll find a basic description of Edge IP Binding and the various components involved.

The original issue: Unicast Routing

The basic concept behind Unicast Routing is that a classless inter-domain routing (CIDR) block of IP addresses belongs to one group of servers. The various routers along the path produce border gate protocol maps that tell requesting clients where those servers are located, and how to send traffic to them.

This is the traditional way TCP/IP is designed to work. It's a one-to-one relationship relying on unique IP addresses for both ends of the connection. Unfortunately, it doesn't always produce the most efficient results, as some clients must travel a long distance to reach the destination IP address.

The potential solution: Anycast Routing

Anycast Routing is different because multiple server blocks can advertise the same CIDR block of IP addresses. The routers along the way build border gate protocol maps that help identify those locations, and the routes can be altered to reach closer servers. This gives you a one-to-nearest relationship, where packets are routed to the nearest machine that is broadcasting the CIDR block of the requested destination IP address.

Alone, Anycast can have its own set of issues. Too many server stacks broadcasting the same /24 CIDR block can pollute border gate protocol routing tables, and it doesn't consider server load, capacity, or availability.

The actual solution: Edge IP Binding

With Edge IP Binding, Akamai servers are using Anycast to advertise their presence for requesting clients, but they are responding to end-user requests with the Akamai edge.

We use proprietary mapping schemes to identify the best edge server to respond to the client's request. Edge IP Binding accesses the edge server with details on how and where to respond. That edge server then responds to the request pretending to use an IP address included in the initial client request—one of several fixed IP addresses that have been assigned for your use after configuring Edge IP Binding.

A brief outline of the Edge IP Binding workflow

Edge IP Binding set up

Once Edge IP Binding has been provisioned for your use, you generate property configurations in Property Manager and enable Edge IP Binding for a supported product (for example, Adaptive Media Delivery), and apply your end-user facing (vanity) hostname. This hostname and Edge IP Binding are used to generate a unique Edge IP Binding-enabled edge hostname that is associated with up to 20 unique Anycast IP addresses.

The Edge IP Binding request flow

The end user (client) requests content from your vanity domain.
The request is resolved to the edge hostname, which in turn resolves to the Edge IP Binding-enabled hostname which initiates a resolution with Akamai DNS servers.
One of Akamai's DNS servers returns an Edge IP Binding static Anycast IP address to the client.
The client sends a synchronization packet via the Anycast IP to contact the nearest Edge IP Binding region.
The nearest Edge IP Binding region system appends the client’s Anycast IP address to the Edge IP Binding-enabled hostname and performs another resolution with Akamai DNS servers.
Akamai end user mapping determines the nearest edge server IP to the client and communicates it to the Edge IP Binding region system.
The Edge IP Binding region system forwards the client’s synchronization packet to this nearest edge server.
The edge server sends the synchronization acknowledgment response directly to the client.
The client tunnels its synchronization acknowledgment to the edge server, using the same process (steps 4 - 7).
The edge server responds by sending content directly to the client.
The client verifies delivery by again tunneling acknowledgments to the edge server.

Additional points on Edge IP Binding

Edge IP Binding allows for delivery at full scale, without expanding the IP address range.
Return traffic is from the Edge IP Binding Anycast address, enabling zero-rating by carriers.
Edge IP Binding supports both HTTP and HTTPS.