benefits of programmable topological routing policies in rina-enabled large scale dcs

Benefits of Programmable Topological Routing Policies in RINA-enabled

Large-scale Datacenters

Sergio Leon(1), Jordi Perelló(1), Davide Careglio(1), Eduard Grasa(2), Diego R. López(3) and Pedro A. Aranda (3)

(1) Universitat Politècnica de Catalunya (UPC) (2) Fundació Privada i2CAT (i2CAT) (3) Telefónica I+D

* This research has been funded by the European Project FP7 PRISTINE, as well as the Spanish National project SUNSET. 1

UPC

NGN.9 - Sergio Leon, Jordi Perelló, Davide Careglio, Eduard Grasa, Diego R. López and Pedro A. Aranda, “Benefits of Programmable Topological Routing Policies in RINA-enabled Large-scale Datacenters”

Summary

Datacenter networks overview

A quick look into RINA

RINA-enabled datacenter scenario

Topological forwarding

Rules

Exceptions

Failure centered routing

Numerical results

Conclusions

2

UPC


Datacenter networks overview

Large number of nodes, but well distributed

Large routing and forwarding tables:

TCP/IP routing solutions does not take profit from the topology

IP does not differentiate well between forwarding domains

3

UPC


A quick look into RINA(1/2)

RINA : Recursive InterNetworking Architecture

Key idea:

“Networking is Inter Process

Communication (IPC) and only IPC”

What it really is:

Clean-slate recursive Internet model

Same type of layer, Distributed IPC Facility (DIF), at each level

All DIFs share the same functionality

Even so, each DIF can be fully configured via any policy (addressing and routing included)

Each DIF may provide full support for a wide range of QoS

4

UPC


A quick look into RINA(2/2)

Each IPC Process (IPCP) shares the same API

Upper IPCPs and applications use it to request flows with specific QoS requirements

5

UPC


RINA-enabled datacenter scenario(1/3)

RINA-enabled Datacenter networks with multiple layers:

DC-Fabric DIF:: ToR-2-ToR and ToR-2-Edge communication

DC DIF:: Server-2-Server and Server-2-Gateway communication

Tenant DIFs – Application-2-Application communication

6

UPC



Leaf-spine DCN (e.g., Google)

Proposed addressing scheme:

ToR switch <Pod_id . (ToR_id + #Fabrics)>

Fabric switch <Pod_id . Fabric_id>

Spine switch <0 . Spine_id>

7

UPC



Clos DCN (e.g., Facebook)

Proposed addressing scheme:

ToR switch <(Pod_id + #SpineSets) . (ToR_id + #Fabrics)>

Fabric switch <(Pod_id + #SpineSets) . Fabric_id>

Spine switch <Spine_set . Spine_id>

8

UPC


Topological forwarding - Rules

Non-failure scenario

Forwarding decisions are simple

e.g., to reach a ToR switch:

At a ToR switch, go to any neighbor

At a fabric switch, either destination is a neighbor or use any spine switch neighbor

At spine switch, go to any fabric switch in the destination pod

Simple rules can be executed quickly

Groups of neighbors can be used to simplify rules

9

UPC


Topological forwarding - Exceptions

Failures in the network → Few rules may fail

Exceptions to overwrite non-valid rules

Similar to traditional forwarding entries

But support different encodings (e.g., use any neighbor but X)

Common failures may require 1 or no exception

Hardware with support for rules and exceptions can replace traditional forwarding tables

10

UPC


Failure centered routing

Expected network graph known at “0-cost”

Only failures and recovery need to be shared

Exception computation directed near failures

Routing can be distributed

e.g., link-state-based policies for failure propagation

Or Centralized

e.g., take profit from existing servers to compute exceptions and populate forwarding policies

11

UPC


Numerical results(1/2)

Non-failure scenario

Number of entries required for forwarding minimized to almost the number of neighbors

Size of entries also greatly reduced

12

UPC


Numerical results(2/2)

Amount of entries remains almost constant with failures in the network

As the datacenter size grows, the number of entries remains quite steady

13

UPC


Conclusions

IP-based datacenters have multiple scalability limitations

RINA-based datacenters already avoid the sharing of unnecessary addresses between forwarding domains

And the use of policies tailored to the network

Our policies minimize the required forwarding knowledge to only that of connected neighbor nodes

Additionally, failure based routing reduces both cost of sharing and computing new network states

14

Thanks. Questions?

The authors of this work would like to thank all members of the PRISTINE Project consortium for the valuable

discussions and inputs

15