Presentation is loading. Please wait.

Presentation is loading. Please wait.

Sourabh Jain (now at Cisco), Yingying Chen, Saurabh Jain

Similar presentations

Presentation on theme: "Sourabh Jain (now at Cisco), Yingying Chen, Saurabh Jain"— Presentation transcript:

1 Sourabh Jain (now at Cisco), Yingying Chen, Saurabh Jain
Decoupling Naming from Routing via Virtual Id ROuting A Scalable, Robust and Namespace Independent Routing Architecture for Future Networks Zhi-Li Zhang, University of Minnesota-Twin Cities Joint work with my students: Sourabh Jain (now at Cisco), Yingying Chen, Saurabh Jain Good morning everyone!

2 Outline Introduction and Motivation VIRO Evaluation
Current Trends Challenges Recent Proposals VIRO Virtual ID layer Routing Table Construction vid lookup & Forwarding Evaluation Simulation based Setup Real Implementation and Prototyping Summary and On-going work

3 Current Trends and Future Networks
Large number of mobile users and systems smart appliances High bandwidth core data centers & clouds Diverse edges mobility intermittent connectivity Heterogeneous technologies More and more virtualizations: virtual servers, clients virtual networks Social networks Multimedia Streaming IP TV Games Web, s & cloud services VoIP Internet (or Future Networking Substrate) POTS Banking & e-commerce Let’s start by first looking at the current networking trends. As we all see that, there are large number of mobile users and systems that connect to the network. There are more number of smart appliances connecting to the network, and rely on the network for providing useful services. To support the growing demands set by these large number of devices and services, we are building high bandwidth core and as well as edge network. Moreover, these devices use heterogeneous technologies to connect to the network, including Ethernet, WiFI LANs etc. Another key trend is the increasing popularity of virtual appliances in computing. We now use Virtual servers in the data-centers, which can moved from one physical machine to another without interrupting the services. surveillance & Security Smart meters, smart grid, sensors, etc. Smart phones, smart pads, etc. Home users

4 Within the Internet Core
Large ISPs with large geographical span Large content/service providers with huge data centers High capacity, dense and rich topology Cloud Computing & Mobile Services public IP addresses for customer-facing servers/devices private IP address realms for internal servers/devices

5 Challenges posed by These Trends
Scalability: capability to connect tens of thousands or more users and devices routing table size, constrained by router memory, lookup speed Mobility: hosts are more mobile, “virtual servers” are also mobile need to separate location (“addressing”) and identity (“naming”) Availability & Reliability: must be resilient to failures need to be “proactive” instead of reactive need to localize effect of failures Manageability (& Security): ease of deployment, “plug-&-play” need to minimize manual configuration self-configure, self-organize, while ensuring security and trust ……. These trends are setting several key challenges to existing networking architectures. First and the foremost challenge is the requirement of Scalability. Network has to accommodate tens of thousands and more users and devices. And the exploding routing/forwarding table sizes at Ethernet switches and routers is a growing concerns, which are limited by the physical memory, bandwidth and look up speeds. The second challenge is to handle the increasing host-mobility. In case of existing networks, IP addresses are used to route the traffic between the hosts, and as well as for identifying the hosts in the network. Therefore, when a hosts moves from one subnet to another its IP address is changed, which creates confusion in the end-to-end protocols. Networks now have more number of mobile users and virtual appliances which needs to be moved around due to several reasons. For instance, in case of large data centers, virtual machines are often migrated from one physical host to another. The live migration of these virtual hosts is easy when they are moved within the same layer-2 subnets, however, the movement between different subnets creates problems due to the required network reconfiguration. The key idea to support the host mobility is the separation of location from the identity or the names of the devices. Another key challenge is the increasing requirement of higher availability and reliability from the networks. Networks need to be more resilient to failures. To achieve this the key is to proactively prepare for the failures instead of simply reacting to it. Last, but not the least, since networks are growing in size, therefore, the need of manageability is one of the prime concerns now. Networks need to be easy to deploy and manage. In case of existing networks, each network device must be configured with appropriate IP address, based on its location in the network. Similarly, virtual machines also need to be configured appropriately, however with the ever increasing number of such devices, it is becoming more challenging to configure them in a scalable way. Therefore, we need to minimize the need of careful manual configuration, while ensuring security and trust.

6 How Existing Technologies Meet these Challenges?
(Layer-2) Ethernet/Wireless LANs Pluses: plug-&-play, minimal configuration, better mobility Minuses: (occasional) data plane flooding, sub-optimal routing (using spanning tree), not robust to failures Not scalable to large (& wide-area) networks (Layer-3) IPv4/IPv6 Pluses: better data plane scalability, more “optimal” routing, … Minuses: control plane flooding, global effect of network failures poor support for mobility difficulty/complexity in “network renaming” Esp., changing addressing schemes (IPv4 - > IPv6 transition) requires modifications in routing and other network protocols Let’s look at how existing technologies meet these challenges. On one hand we have layer-2 technologies, such as Ethernet/Wireless networks, Which are largely, plug-&-play, and do not require extensive configuration. However, it is not possible to create large layer-2 networks, mainly because of the use of flooding in underlying protocols. In addition, the use of spanning trees, network wide flooding in the data-plane for forwarding and address resolution leads to inefficiency in the network, and further limits the scalability of such networks. On the other hand, layer-3 IP networks have better data plane scalability than layer 2 networks. These networks use more sophisticated routing protocols, for instance, OSPF employs link-state routing based protocol for the shortest path routing. However, they still require control plane flooding for the routing table computation, and offer poor support for mobility. Furthermore, these networks require careful manual configuration, in terms of careful IP address assignments, need for defining OSPF areas for better control plane scalability.

7 IP address Management & Mobility
IP address (re-)assignment creates management overhead: Careful IP configurations DHCP servers need to maintain state Static assignment requires manual effort Breaks the mobility Firewall re-configurations Interface IP address: Interface IP address: To: Firewall: Allow TCP port 80 for Subnet Prefix: Mask: Gateway: Subnet Prefix: Mask: Gateway: Now, I will explain some of the basic manageability and mobility issues faced by existing networking architectures. As seen in this slide, we have two separate layer-2 networks, which are connected together using a layer-3 router. The proper IP address assignment to these networks requires, that each of the layer-2 subnet MUST have a unique IP prefix in the whole network. Next, when a host connects to this network it must be assigned appropriate IP address/gateway specific to the subnet that it connects from. Once the configuration is done, it can communicate with other hosts in the network. Now consider the scenario, when host-device is moved to a different subnet in the same network. Since this new subnet has a different IP addresses, it needs to be reconfigured appropriately to be able to connect to other hosts. However, if this host was talking to another host prior to the change, the other host may not be able to reach it, till it learns its new address. In particular, the mobility will break any existing network connections, and requires the state at all the other hosts to be updated. On top of these IP address configuration, if network installs a firewall, with a specific rule for this device, then it must be updated immediately otherwise, it might provide a door for malicious users to exploit. On the other hand, the network firewall must be reconfigured at the new subnet to allow the traffic for the host machines. In summary, networks are increasing becoming complicated to manage, where the key problem lies in the issues related IP address assignment/reassignments and more and more manual configurations. Because of these extensive configuration requirements, it breaks the mobility for the endhost devices, creates cumbersome firewall management tasks and so on.. IP address Gateway: IP address Gateway:

8 Recent proposals SEATTLE [SIGCOMM’08] , VL2 [SIGCOMM’09], TRILL, LISP
Shortest path routing using link state routing protocol on Ethernet switches “Identifier and location” separation for better mobility Seattle uses DHT style lookup, VL2 uses a directory service for flooding free lookup No flooding on data plane However, control plane still uses flooding! ROFL [SIGCOMM’06], UIP [HotNets’03] DHT style routing for scalability (based on “virtual circuits” between id’s) Uses flat labels for mobility However, these may incur significant routing stretch due to no topology awareness No fundamental support for advanced features such as: Multipath routing Fast Failure Rerouting Here is a list of couple of key proposals, which attempt to address the growing challenges faced by existing networking architectures. There have been several proposals to address the scalability challenges faced by existing Ethernet networks. I have listed a couple of such proposals here, which includes SEATTLE, VL2, TRILL, and LISP. The key ideas behind such proposals are the following: First, they continue the support for location/id split, as used in conventional Ethernet networks by using the broadcast based data-plane forwarding and as well as for the address resolution. However, instead of using flooding style address resolution, they propose a more scalable address resolution in the form of either a DHT based mapping service or a centralized directory system. Second, SEATTLE, VL2, and TRILL, use link-state based routing protocol for better data-plane scalability. This not only helps in avoiding data-plane flooding, but also allows the use of more efficient routing by choosing the shortest paths for the routing. However, they still use control plane flooding, which again limits the scalability of the routing architecture. Similarly, there have been several proposals to address the routing scalability of link-state based routing proposals, by having compact forwarding tables. The key idea behind these proposals is the use of DHT style routing protocols for scalability, and the use of flat labels for better mobility. However, since these flat labels used for routing do not take in to account the underlying network connectivity information, they may incur significant routing stretch. Finally, none of these proposals provide fundamental support for many advanced features such as multipathing and fast failure re-routing, which will be the key to make network resilient to failures and efficient.

9 Outline Introduction and Motivation VIRO Evaluation
Current Trends Challenges Recent Proposals VIRO Virtual ID layer Routing Table Construction vid lookup & Forwarding Evaluation Simulation based Setup Real Implementation and Prototyping Summary and On-going work

10 Meeting the Challenges: VIRO: A Scalable and Robust “Plug-&-Play” Routing Architecture
Decoupling routing from naming/“addressing” [in “IP/MAC” sense] “native addressing”/logical naming-independent (i.e., identifier-independent) “future-proof”: capable of supporting multiple namespaces & inter-operability Introduce a “self-organizing” virtual id (vid) layer a layer 2/layer-3 convergence layer: vid – dynamically assigned “locator” subsume layer-2/layer-3 routing & forwarding functionalities except for first/last hop: host to switch or switch to host for backward compatibility layer-3 addresses (or higher layer names): global “addressing” or naming for inter-networking and “persistent” identifiers “DHT-style” routing using a topology-aware, structured vid space highly scalable and robust: built-in support for multi-path, fast rerouting O(log N) routing table size, localize failures, enable fast rerouting support multiple topologies or virtualized network services

11 Virtual ID layer and VID space
Topology-aware, structured virtual id (vid) space Kademlia-like “virtual” binary tree (other structures can also be used) vid: encode (topological) location info (a “locator” a la Cisco LISP or HIP) 1 - F E H G B A D C N M J L K Layer 2 Physical Network Topology IPv4/IPv6 Virtual ID Layer Other Namespace DNS Names M N H G J L K C F E B D A As mentioned earlier, the first key idea behind the VIRO is the introduction of a topology aware, structured virtual ID space, by assigning virtual identifiers (vids in short) to the routing nodes in the network. Here, by topology aware I mean, if two nodes are close to each other in the virtual id space then they are also close in the physical topology. In other words, the proximity in the virtual ID space implies the physical proximity. For instance consider the physical topology shown in the left figure, we show the corresponding virtual id space for this topology in the figure on the right. As seen in this figure, if two nodes are close to each other in this virtual binary tree, then they are also close to each other in the physical topology. For instance, consider the nodes A,B,C and D which are close to each other in the Virtual Binary tree, and now if we refer to the physical topology show on the left, we find that they are close to each other in the physical topology as well.

12 VIRO: Three Core Components
Virtual id space construction and vid assignment Performed at the bootstrap process (i.e., network set up): Once network is set up/vid space is constructed: a new node (a “VIRO switch”) joins: assigned based on neighbors’ vid’s end-host/device: inherits a vid (prefix) from “host switch” (to which it is attached), plus a randomly assigned host id; host may be agnostic of its vid VIRO routing algorithm/protocol: DHT-style, but needs to build end-to-end connectivity/routes a bottom-up, round-by-round process, no network-wide control flooding O(log N) routing entries per node, N ≈ # of VIRO switches DHT based name/identifier to address/locator mapping service Data forwarding among VIRO switches using vid only switch vid host id l L These three key ideas are implemented in VIRO using its three core components. Which are described here: The first key component is Virtual ID assignment: Routing nodes in VIRO are assigned virtual ids when the network bootstraps for the first time. However, when a new node joins after the network is already set up, it gets its vid based upon its neighbor’s vids. On the other hand end-host devices inherit vid prefix from the “switches or routing nodes” that they directly connect to. Next VIRO employs a DHT style routing using virtual ids. The routing table construction process is a bottom-up round-by-round process, uses a pub-sub system to avoid network wide flooding completely. Since routing is done purely on the basis of virtual ids, it requires a mapping service to map the host identities to their location. It is performed by the third key component of VIRO, which builds a DHT style mapping service.

13 Vid Assignment: Bootstrap Process
Initial vid assignment and vid space construction performed during the network bootstrap process Via either a centralized (top-down, for “managed” networks) or distributed (bottom-up, for “ad hoc” nets) vid assignment algorithm M N H G J L K C F E B D A 10 00 M N H G J L K \ F E B D A C In this slide I describe one simple mechanism to perform the “topology aware” vid assignment to routing nodes in VIRO. The basic idea here is to recursively cluster nodes, and at each step assign them 0 or 1 prefix, so that each node has a unique virtual id in the cluster. Consider the example shown on the slide. At the beginning, each node forms a cluster containing itself. In the next step, it tries to cluster with its neighboring clusters. In order to identify each node in the new cluster, they prepend a prefix of ‘0’ or ‘1’ to each other’s vids. This process of clustering continues till we are left with one large cluster. 010 000 M N H G J L K C F E B D A 100 110 0010 1100 M N H G J L K C F E B D A 0000 0100 0110 1000 1001 1110

14 Vid Assignment : Key Properties
00010 10010 11100 M N H G J L K C F E B D A 00000 00100 00110 01000 01001 10000 10100 10110 11110 11000 Key invariant properties: closeness: if two nodes are close in the vid space, then they are also close in the physical topology esp., any two logical neighbors must be directly connected. connectivity: any logical sub-trees must be physically connected. 1 - F E H G B A D C N M J L K 1 I demonstrate the final vid assignment at the end of this recursive clustering method in this slide. As you can see, we can also arrange the nodes in a form of a virtual binary tree, where the leaf nodes represent the routing nodes in the network, and the path from the root of the tree to the leaf node represents the virtual id for that node. Grey dashed lines in this binary tree represents the physical connectivity. Such a vid assignment ensures two key invariant properties required for the correctness for the routing algorithm. The first invariant property is the property of closeness: if two nodes are close in the vid space, then they should also be close in the physical topology esp., any two logical neighbors must be directly connected. The second key invariant is the connectivity property: any two adjacent logical sub-trees must be physically connected. 1 1 1 1 1 1 1 1 1 1 1 1 1 1

15 Vid based distance: Logical distance
Logical distance defined on the vid space d(vidx, vidy) = L – lcp (vidx,vidy) L: max. tree height; lcp: longest common prefix e.g. d(00001, 00111) = 5 – lcp(00001, 00111) = 5 – 2 = 3 d(01001, 01011) = 5 – lcp(01001, 01011) = 5 – 3 = 2 Let me define logical distance now, which is used to compare the two virtual ids. Logical distance between a pair of VIDs is defined as the difference between the height of the virtual binary tree and the longest common prefix between the virtual ids. For instance, consider the virtual ids and 00111, then logical distance between these two ids is 5 – longest common prefix between and which is 2. therefore the logical distance is 5-2 which is 3.

16 VIRO Routing: Some Definitions
For k =1, …, L, and any node x: (level-k) sub-tree, denoted by Sk(x): set of nodes within a logical distance of k from x (level-k) bucket, denoted by Bk(x): set of nodes exactly k logical distance from node x (level-k) gateway, denoted Gk(x): a node in Sk-1(x) which is connected to a node in Bk(x) is a gateway to reach Bk(x) for node x; a direct neighbor of x that can reach this gateway node is a next-hop for this node 1 - F E H G B A D C N M J L K Before, I describe the routing table construction algorithm, let me define some terminologies to facilitate the discussion. We define a sub-tree at level k for node x as the set of nodes which are with in a logical distance of k from x Similarly, a bucket at level k for node x is the set of nodes which are at EXACTLY k logical distance from x Next, a gateway for node x at level k is the node in Subtree k-1 which is directly connected to a node in Bucket k of x. Lets illustrate these using few examples: A sub-tree for node A at level 3 is the set of nodes: A, B, C and D since all of these nodes are at no more than 3 logical distance from A On the other hand, the bucket at level 3 for node A contains only nodes C and D, since they are at exactly logical distance 3 from A. Similarly, B is a gateway for node A to reach its bucket level 5 since it is connected to node E directly which is in bucket 5 for node A. Example: S1(A)= {A}, S2(A) ={A,B}, B2(A)={B} G2(A)={A}, S3(A) = {A,B,C,D} B3(A) = {C,d} G3(A) = {A,B}

17 VIRO Routing: Routing Table Construction
Bottom-up, round-by-round, “publish-&-query” process: round 1: neighbor discovery discover and find directly/locally connected neighbors round k ( 2 ≤ k ≤L): build routing entry to reach level-k bucket Bk(x) -- a list of one or more (gateway, next-hops) use “publish-query” (rendezvous) mechanisms Algorithm for building Bk(x) routing entry at node x: if a node(x) is directly connected to a node in Bk(x), then it is a gateway for Bk(x), and also publishes it within Sk-1(x). nexthop to reach Bk(x) = direct physical neighbor in Bk(x) else node x queries within Sk-1(x) to discover gateway(s) to reach Bk(x), choose the logically closest if multiple gateways. nexthop to reach Bk(x) = nexthop(gateway) The routing table construction procedure consists of a total of L rounds. In the first round, each node discovers its physical neighbors, by exchanging HELO packets With each other directly. Subsequently, in a round k a node builds its connectivity to reach nodes in its kth bucket. In case, a node already has such connectivity, through one of its physical neighbors, then it publishes the mapping to other nodes. On the other hand the nodes which do not have such neighbor, they query the sub-tree to learn the connectivity information. We use a publish-query mechanism to share the gateway information at each level. Also, we formally establish the correctness of the routing, which can be found in the related publications. Correctness of the algorithm can be formally established.

18 VIRO Routing: Routing Table
00010 10010 11100 M N H G J L K C F E B D A 00000 00100 00110 01000 01001 10000 10100 10110 11110 11000 Level Gateway Nexthop 1 - 2 3 .. L 1 Here is the routing table structure. It consists of L routing entries, corresponding to each bucket level. (Here L is the depth of the binary tree). So for example, for node A it will have 5 different routing entries, one for each bucket. Each routing entry, consists of 3-tuples: level, gateway, and nexthop. 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 A - B C D M N E F G H J K L

19 VIRO Routing: Packet Forwarding
To forward a packet to a destination node, say, L compute the logical distance to that node Use the nexthop corresponding to the logical distance for forwarding the packet If no routing entry: drop the packet 00010 10010 11100 M N H G J L K C F E B D A 00000 00100 00110 01000 01001 10000 10100 10110 11110 11000 Bucket Distance Gateway Nexthop 1 - 2 A B 3 C,D 4 C 5 Next, I show, how a node forwards the packets using the routing table. For example if a node A wants to forward a packet to a destination ‘d’. Then, first A would compute the logical distance to destination d, and lookup the nexthop information Corresponding to the logical distance, and forward the packet to it. In case no entry was found, then it implies that no route exist that would connect node A to destination ‘d’.

20 Multiple routing entries: An example
1 1 1 1 1 1 1 1 1 1 1 VIRO provides built-in mechanism for multipath routing. To illustrate this, consider the node A in the shown topology. Here, node A chooses node B as the default gateway to reach its bucket at level 5, since it is logically closest to it. However, nodes D, M and N also have direct path to reach the bucket 5 for node A, and therefore can be used as alternate gateways by node A. I demonstrate these alternate gateway connection using blue dashed lines in the current example. 1 1 1 1 1 1 1 1 1 1 1 1 1 F E H G B A D C N M J L K -

21 Multiple Routing Entries
Learn multiple gateways at each level Default gateway is the one that is logically closest Use additional gateways for multi-pathing and fast failure re-routing Requires consistent gateway selection Otherwise forwarding loops may occur Use appropriate “forwarding directive” while using alternate gateways As shown in the previous example, VIRO can pre-compute several other back-up routes at each bucket level, by simply learning multiple gateways at each level. While the gateway that is logically closest acts as the default gateway for a node. A node can use these alternate gateways to perform the multi-pathing and fast failure re-routing. However, it needs to be done carefully, otherwise it may cause routing loops. To avoid loops, whenever a node chooses one of the alternate gateway to forward a packet it indicates it to other nodes on the forwarding path by incorporating a “forwarding directive” on the packet header, whereby it ensures the consistent gateway selection at intermediate nodes.

22 pid to vid translation DHT Style lookup/store mechanism
Simple and scalable A backward compatible approach to work with Ethernet based protocols Re-use ARP (address resolution protocol) to perform IP to vid mapping Assumes IP address as the pid for the host-devices Simple modification to ARP will allow any host namespace to vid mapping

23 VIRO: <IP/MAC, vid> Mapping
Host-switch: a switch directly connected to the host vidiscover host MAC/IP through ARP, and assign d to host host-switch publishes pid  vid mappings at an “access-switch” Access-switch: a switch whose vid is closest to hash (IP address of the host) Access-switch for y Sx Sy Sz x y IPy VIDy register mapping IPy  VIDy VEIL uses a DHT style mapping service to map IP addresses to vids for the host devices using the ‘host-switches’ and the ‘access-switch’. The host-switch for a host-device is the veil-switch that it is directly connect to (or through Ethernet switches) These switches discover the host-devices directly connected to them, by sniffing the packets coming from them. Whenever they detect a new host-device they assign a vid to it, and the mapping between the IP address and vid is then published to corresponding access-switch. (while a host-device can be either configured using DHCP or may be assigned a static IP address) Other hosts that want to communicate with the given host, can query the access switch to learn the mapping. An access-switch for a given host-device is determined by taking a hash of the IP address of the host. For example, in the example show on the slide, switch Sy is the host-switch for host y, and Sz is the access switch for the host. Sy, being the host-switch for host y, performs the vid-assignment for the host, and publishes it to the access switch Sz periodically. Host-switch for y IPy MACy VIDy An example using IP address as pid

24 Address/vid Lookup & Data Forwarding
Use DHT look-up for address/vid resolution with local cache vid to MAC address translation at last-hop Mapping Table at Sz IP Address VID IPy VIDy Switch Sz 3. ARP Reply (IPy  VIDy) 2. ARP Query Forwarded as Unicast request (IPy  MAC?) 6. Sy changes destination MAC address Ethernet Packet (VIDx  MACy) Now I show how the vid lookup and packet forwarding works in VEIL. To illustrate this, consider the following example. Say a host x wants to connect to host y, first it performs an ARP request to resolve IP address of host y to its MAC address. This arp request packet is captured by the host-switch sx, and it Computes the hash of IPy to learn the access switch for y, Sz. It will forward the arp request message as an encapsulated unicast message to the access switch Sz. Upon, receiving this ARP request, Sz will send the encapsulated ARP reply packet to Sx, which contains The 48-bit long vid for the host y, and not the MAC address of it. Finally, Sx decapsulates the packet, and forwards this ARP reply packet to x. Next host x will send the ethernet packet with destination mac address as VID of y., Switch Sx knows that host X is directly connected to it, therefore it replaces the source mac address on the packet by the vid of host x before forwarding it. Finally packet reaches to switch Sy, which knows the destination vid on the packet corresponds to one of the hosts connected to it. Therefore, it forwards the packet to host y directly, after replacing the destination ethernet address in the Ethernet header by the actual MAC address of the host y. 1. ARP Query (IPy  MAC?) 5. Sx changes source MAC address Ethernet Packet (VIDx  VIDy) Switch Sx Switch Sy y x 4. Ethernet Packet (MACx  VIDy)

25 Seamless Host Mobility: An illustration
Mapping Table at Sz IP Address VID IPy VIDy Mapping Table at Sz IP Address VID IPy VIDynew Switch Sz Host y’s vid is VIDynew Host y is vid is VIDynew Lets see how VEIL supports seamless host-mobility. Consider the previous example where, x and y are communicating with each other. And say, after some time Host y, moves and re-connects from the switch Sw in the network. Upon detecting the new host y, Switch Sw assigns a vid to it, and publishes the VID assignment to its access switch at Sz. Which sees, that there is an old mapping for host y at switch sy, it updates the VID mapping for y in its table, and also informs the switch Sy that host y has moved to Sw. Now, when Sy receives the packet for host y, it updates the vid on the packet to new vid of the host y and forwards it. It also sends an arp reply message to host x with the new vid of y, so that it can directly send the packet to host y at its new location. Switch Sw Switch Sx x ARP reply packet containing the new vid of host y Switch Sy y

26 Outline Introduction and Motivation VIRO Evaluation
Current Trends Challenges Recent Proposals VIRO Virtual ID layer Routing Table Construction vid lookup & Forwarding Evaluation Simulation based Setup Real Implementation and Prototyping Summary and On-going work

27 Initial Evaluation using Simulations
Used various AS and data center network topologies VIRO is compared against link-state routing protocol (e.g., OSPF) Compared routing stretch, routing table size, control overhead, failure dynamics, etc. Simulation code implemented in JAVA AS Topologies AS1755(295 nodes, 543 edges) AS3967(353 nodes, 820 edges) AS6461(654 nodes, 1332 edges) Data Center Topologies DC125(125 nodes, 500 edges) DC320(320 nodes, 2048 edges) DC500(500 nodes, 4000 edges) BRITE Topologies BT200(200 nodes, 790 edges) BT400(400 nodes, 1590 edges) BT600(600 nodes, 2390 edges) Since, It is not feasible to create large network topologies using the real prototype. We used simulation to evaluate VIRO for large topologies. For the simulation we implemented our own custom simulator using JAVA. And use several AS, Datacenter and random network graph topologies for the simulation. Using simulation we compared various metrics including routing stretch, routing table size, control overhead etc for VIRO and OSPF.

28 Evaluation: Routing Table Size
In this slide, I compare the routing table size for OSPF and VIRO for different topologies. The horizontal axis represents the various topologies used, and vertical axis represents the size of routing table. The routing table size for OSPF is represented using Blue bars, while Yellow bars are used for VIRO. As seen in this plot, VIRO provides amazing scalability in terms of the size of routing table when compared with OSPF. VIRO: O(log N) routing entries, compared to O(N) for link state

29 Evaluation: Control Overhead
In addition to comparing the routing table size, it is important to compare the overhead of creating the routing tables. For this we compare the number of control messages processed by each node to compute the routing table. In this figure vertical axis represent the control overhead, and the horizontal axis represents the topologies. The overhead for OSPF is shown using dark blue bars, and other colors represent various variants of VIRO. As seen in this figure, VIRO provides significant reduction in the control overhead, and therefore, is more scalable. This incredible reduction in control overhead is due to the fact that VIRO does not require any flooding in both control and data planes. However, OSPF relies on the flooding of LSA (links state advertisements). A popular workaround to reduce this control overhead is by introducing “ospf areas” in the network, whereas flooding is limited to each ospf area, however, it adds more cost in terms of the management and configuration for the network. Significant reduction in control overhead per node (VIRO-1,2,4 with 1,2 and 4 rendezvous nodes at each level, VIRO-log has log(k) rendezvous nodes at kth level

30 Evaluation: Routing Stretch
While VIRO is more scalable than OSPF, the scalability comes at the cost of routing stretch. Since the routes between a source and destination are not necessarily shortest, it incurs smaller cost by taking slightly longer routes. However, the topology aware virtual ids help in keeping this cost low, and as seen in this plot, the routing stretch which is the ratio of length of the path and shortest path as number of hops, is close to one. Hence, routing in VIRO is not optimal, but it is close! Routing in VIRO is not optimal, but it is close!

31 VEIL-Click: An initial prototype
Implementation of VIRO/VEIL architecture using Click Modular Router framework VEIL-Click enabled switch consists of: A linux machine Multiple network interfaces Click Modular Router VEIL as Click elements I have completed the initial prototype implementation of VEIL using Click modular router framework. The design of prototype consist of a linux based machine, with multiple network interfaces. We run Click modular router on it, while VEIL functionality is implemented as a set of Click modules.

32 Summary VIRO provides a scalable & robust substrate for future networks No flooding in both data and control planes Back up routing entries for robustness Support for multiple namespaces Essential for seamless mobility VIRO can be realized! VEIL (Virtual Ethernet ID Layer) for large-scale layer-2 networks Backward compatible compatible with current host protocols (such as ARP etc) Enables (nearly) configuration-free networks Built-in support for Multi-path routing Extensible to support multiple topologies, virtualized network services Ongoing work: Prototype using Click & OpenFlow switches Extensions to enable multiple ‘virtual’ topologies, management control plane… Finally, here is the summary of the second part. VIRO provides a scalable & robust substrate for future networks: Its unique features shows how we can exploit the richness of the topologies in a more scalable way. Finally, to demonstrate the feasibility of such an architecture, we designed VEIL, which can create large scale ethernet networks with all these features. In addition, VEIL offers complete backward compatibility with current host protocols (such as ARP etc) It enables (nearly) configuration-free networks It supports multiple namespaces, and provides Location/Identity split, which is the key to provide seamless mobility support. It provides built-in support for multi-path routing, which enables efficient use of network resources and makes network more resilient to failures by pre-computing the backup routing entries. Furthermore, it can be easily extended to support multiple virtual topologies to provide virtualized network services, for enhanced security and other features. Future work prototyping using Click and Openflow inter-domain routing issues

33 Thanks! Thanks! Please visit for:
Demo videos, List of related publications, Source code! Or simply search online for “VIRO VEIL” Thanks!

34 VIRO Routing: Example Round 1: each node x discovers and learns about its directly/locally connected neighbors build the level-1 routing entry to reach nodes in B1(x) E.g. Node A: discover two direct neighbors, B,C,D; build the level-1 routing entry to reach B1(A)={} 00010 10010 11100 M N H G J L K C F E B D A 00000 00100 00110 01000 01001 10000 10100 10110 11110 11000 Bucket Distance Gateway Nexthop 1 - 2 A B 3 C,D Here is the round 1, for node A, where it discovers its physical neighbors using HELO packets. Routing Table for node A

35 VIRO Routing: Example …
Round 2: if directly connected to a node in B2(x), enter self as gateway in level-2 routing entry, and publish in S1(x) otherwise, query “rendezvous point” in S1(x) and build the level-2 routing entry to reach nodes in B2(x) E.g. Node A: B2(A)={B}; node A directly connected to node B; publish itself as gateway to B2(A) 00010 10010 11100 M N H G J L K C F E B D A 00000 00100 00110 01000 01001 10000 10100 10110 11110 11000 Here is the round 2. Bucket Distance Gateway Nexthop 1 - 2 A B 3 C,D Routing Table for node A

36 VIRO Routing: Example …
Round 3: if directly connected to a node in B3(x), enter self as gateway in level-3 routing entry, and publish in S2(x) otherwise, query “rendezvous point” in S2(x) and build the level-2 routing entry to reach nodes in B3(x) E.g. Node A: B3(A)={C,D}; A publishes edges A->C, A->D to “rendezvous point” in S2(A), say, B; Round 3 00010 10010 11100 M N H G J L K C F E B D A 00000 00100 00110 01000 01001 10000 10100 10110 11110 11000 Bucket Distance Gateway Nexthop 1 - 2 A B 3 C,D

37 VIRO Routing: Example …
Round 4: if directly connected to a node in B4(x), enter self as gateway in level- 4 routing entry, and publish in S3(x) otherwise, query “rendezvous point” in S3(x) and build the level-4 routing entry to reach nodes in B4(x) E.g. Node A: B4(A)={M,N}; A queries “rendezvous point” in S3(A), say, C; learns C as gateway Round 4 Bucket Distance Gateway Nexthop 1 - 2 A B 3 C,D 4 C 00010 10010 11100 M N H G J L K C F E B D A 00000 00100 00110 01000 01001 10000 10100 10110 11110 11000

38 VIRO Routing: Example …
Round 5: if directly connected to a node in B5(x), enter self as gateway in level-5 routing entry, and publish in S4(x) otherwise, query “rendezvous point” in S4(x) and build the level-4 routing entry to reach nodes in B5(x) E.g. Node A: B5(A)={E,F,G,H,J,K,L}; A queries “rendezvous point” in S4(A), say, D; learns B as gateway 01000 00100 Bucket Distance Gateway Nexthop 1 - 2 A B 3 C,D 4 C 5 M And here is the final round. At the end of this round, node A has full routing table ready. C 01001 N H 10110 00000 D 00110 A G 11000 10000 10100 L J E 11110 B F K 00010 10010 11100

39 Evaluation: vid Assignment
In this slide I show how “virtual id layer” Smaller logical distance  shorter physical distances

40 Evaluation: Localized effect of failure
Nodes farther from failed node/link are lesser affected by the failures!

41 Evaluation: Failure Fast Rerouting
No disconnection during small failures. (VIRO with 1, 2, and 4 gateways in the routing table For fast failure rerouting)

42 Evaluation: Rendezvous Node Overhead
Topology: AS3967 (VIRO with 1, 2, and 4 and log(k) rendezvous node at any kth level sub-tree) Overhead can be significantly reduced by having more Rendezvous nodes at higher levels!

43 Evaluation: Failure Overhead
Total number of failure update messages Next, we compare the overhead for VIRO and OSPF in case of failures. In case of OSPF, whenever a node/link fails, adjacent nodes flood the updated LSA packets carrying the failure information in the network. The overhead to carry these packets is significant in case of large networks, and incurs significant cost. However, VIRO localizes the effect of failures by only notifying the nodes which are affected by the failures. Therefore, the cost to update the routing tables of all the nodes in the network is manageable. In the current plot, I demonstrate the failure overhead (as average number of failure update messages processed by each node) for both VIRO and OSPF. As we see, the VIRO provides significant reduction in the overhead. VIRO has much lesser overhead to handle the failure notifications!

44 Other Advantages/Features
Can support multiple namespaces, and inter-operability among such namespaces (e.g., IPv4<->IPv6, IP<->Phone No., etc.) VIRO: “native” naming/address-independent simply incorporate more <namespace, vid> directory services Fast rerouting can be naturally incorporated no additional complex mechanisms needed Support multiple topologies or virtualized network services e.g., support for VLANs multiple vid spaces may be constructed e.g., by defining different types of “physical” neighbors Also facilitate security support host and access switches can perform access control “persistent” id is not used for data forwarding eliminate flooding attacks

45 Robustness: Localized Failures
Link H-L fails 00010 10010 11100 M N H G J L K C F E B D A 00000 00100 00110 01000 01001 10000 10100 10110 11110 11000 00010 10010 11100 M N H G J L K C F E B D A 00000 00100 00110 01000 01001 10000 10100 10110 11110 11000 After link H-L fails Initial Topology Bucket Distance Gateway Nexthop 1 - 2 A B 3 C,D 4 C 5 Routing table for node A does not change despite the failure!

Download ppt "Sourabh Jain (now at Cisco), Yingying Chen, Saurabh Jain"

Similar presentations

Ads by Google