1 / 37

Prototyping, Implementation & Large-Scale-Experimentation of VIRO in GENI

Prototyping, Implementation & Large-Scale-Experimentation of VIRO in GENI. Zhi-Li Zhang Qwest Chair Professor Department of Computer Science and Engineering University of Minnesota Email: zhzhang@cs.umn.edu.

karis
Télécharger la présentation

Prototyping, Implementation & Large-Scale-Experimentation of VIRO in GENI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Prototyping, Implementation & Large-Scale-Experimentation ofVIRO in GENI Zhi-Li Zhang Qwest Chair Professor Department of Computer Science and Engineering University of Minnesota Email: zhzhang@cs.umn.edu

  2. VIRO: Scalable, Robust Virtual-Id Routingfor Future Large, Dynamic Networks Designed to meet the following challenges & requirements • Scalability: capability to connect tens of thousands, millions or more devices (& users) • routing table size, constrained by router memory, lookup speed • Availability& Reliability: must be resilient to failures • need to be “proactive” instead of reactive • need to localize effect of failures • Mobility: hosts (both clients & servers) are more mobile • need to separate location (“addressing”) and identity (“naming”) • Manageability: ease of deployment, “plug-&-play” • need to minimize manual configuration • self-configure, self-organize, while ensuring security and trust • Agility: dynamically adapt to demand; net expands/shrinks, … • ......

  3. VIRO: A Scalable and Robust “Plug-&-Play” Routing Architecture • Decoupling routing from naming/”addressing” • “native” naming/address-independent • “future-proof” & capable of supporting multiple namespaces • Introduce a “self-organizing” virtual id (vid) layer • a layer 2 (LLC)/layer-3 convergence layer -- replacing IP • subsume layer-2/layer-3 routing/forwarding functionality • except for first/last hop: host to switch or switch to host • 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 • O(log N) routing table size, localize failures, enable fast rerouting • support multiple topologies or virtualized network services

  4. M C N H D G A L J E B F K IPv4/IPv6 DNS Names Other Namespace 1 0 Virtual ID layer and VID space 1 1 0 0 0 1 1 1 0 1 0 0 0 1 0 0 1 1 1 0 1 0 1 1 1 1 1 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 E - F - G - H - J - - - K - L - A - B - C - D - M - N - - - - - Virtual ID Layer Layer 2 Physical Network Topology • Topology-aware, structured virtual id (vid) space • Kademlia-like “virtual” binary tree • vid: embed topological “location” information structurally • self-configurable and self-organizing

  5. VIRO: Three Core Components • Virtual id space construction and vid assignment • performed most at the bootstrap process (i.e., network set up): • a vid space “skeleton” is created • 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 • (Persistent) layer-2/3 address/name resolution and vid look-up • DHT directory services built on top of the same vid space • “persistent” identifier (e.g., MAC/IP address) hashed to a “vid” key, which is then used for (pid, vid) mapping registration, look-up, etc. • Data forwarding among VIRO switches using vid only

  6. VIRO Routing& Forwarding • Forwarding: a packet to a destination node, say, L • compute the logical distance (“level”) to the dest. node • look up gateway & next-hop pair at the distance level (bucket) • if no routing entry, drop the packet 01000 00100 M C 01001 N H 10110 00000 D G A 00110 11000 10100 L 10000 J 11110 E B F K 00010 10010 11100 • Routing: Bottom-up, round-by-round process • highly scalable: O(L) routing entries per node • no single point of failure, and localize effect of failures • completely eliminate “network-wide” control flooding

  7. M M C C N N H H D D G G A A L L J J E E B B F F K K Robustness: Localized Failures 01000 01000 00100 00100 01001 01001 10110 10110 00000 00000 00110 00110 11000 11000 10100 10100 Link F-K fails 10000 10000 11110 11110 Initial Topology 00010 00010 10010 10010 11100 11100 After link F-K fails Routing table for node A does not change despite the failure!

  8. Built-in Multi-Path Routing, Load-Balancing and Resilient Fast Re-Routing • Learn multiple gateways at each level • Default gateway is the one that is logically closest • Use additional gateways for multi-path routing, load balancing & fast failure re-routing • Requires consistent gateway selection strategies • otherwise forwarding loops may occur • Use appropriate “forwarding directive” carried in packets to select appropriate gateways to ensure consistent gateway selection • Forwarding directives may be modified to dynamically adapt to network conditions

  9. Key (Other) Features & Advantages • Load balancing & fast rerouting can be naturally incorporated • no additional complex mechanisms needed • Can support multiple namespaces, and inter-operability among such namespaces (e.g., IPv4<->IPv6, IP<->Phone#, NDN, etc.) • VIRO: “native” naming/address-independent • simply incorporate more <namespace, vid> directory services • Support multiple topologies or virtualized network services • e.g., support for multiple virtual networks • 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

  10. GENI-VIRO Project: Goals VIRO as a “non-IP” layer 3 protocol & service • Implement & prototype VIRO in GENI • what capabilities does GENI, & how flexible GENI is to support prototyping VIRO? • Large-scale Experimentation of VIRO in GENI • test & evaluate VIRO functionality & performance • what GENI capabilities/tools facilitate such large-scale “shake-up” experiments, e.g., dynamic link/node failures? • Longer-Term Goal: VIRO as “long-lived” non-IP layer 3 prototype service • Potentially incorporated in GENI as a non-IP alternative • to support research, experiments & educational activities by other GENI researchers

  11. GENI-VIRO: Prototype & Implementation Challenges Plan to implement using the GENI OVS platform, as a GENI slice • OVS (open virtual switch) platform derived from the openflow switch spec & SDN paradigm • centralized control/management planes • more flexible forwarding behavior, but still tied to existing Ethernet/IP/TCP protocol suite • Can we implement VIRO using OVS platform? • has its own “topology-aware” addressing (vid’s) scheme, centrally managed and/or “self-configured” • perform distributed routing, using novel “pub-sub” paradigm • forwarding behavior: using both destination vid (via prefix matching) and a forwarding directive to select gateway & next-hop, with built-in multipath & fast failure (re)routing

  12. GENI-VIRO: Data Plane Prototype Challenges • Re-use MAC address (40 bits) as vid’s • Virtual id space construction and virtual id assignment • Centralized vid construction & management plane • via a centralized OVS/SDN controller • distributed topology discover, but centralized topology management: e.g., VIRO switch join or leave operations • end host: dynamically assigned vid; report to controller • VIRO packet header: similar to Ethernet frame format, but need an additional “forwarding directive” field • as an extension to Ethernet, similar to VLAN extension • VIRO forwarding behavior: dest. vid + forwarding directive • difficult to implement directly using openflow OVS • need to define new flow table format & implement our own flow classifier, as an extension to standard OVS

  13. GENI-VIRO: Control Plane Prototype Challenges • Can implement a centralized version using the openflow OVS/SDN paradigm, but • lose some of the key advantages of VIRO, e.g., its ability to adapt to failures dynamically • Implement distributed VIRO routing via OVS: • equip each OVS node with a local OVS controller • configure local flow table to forward VIRO routing messages to local OVS controller • local OVS controller implements & emulates VIRO routing protocols • additional OVS controllers as rendezvous points (RPs) • Additional functions & modules for neighbor discovery, monitoring, etc.

  14. GENI-VIRO “Shakedown” Experiments • Test & evaluate functionality & performance of VIRO • VIRO GENI experiment designs, topology configuration and workload generation tools • Large-scale experimental evaluation of VIRO scalability • as # of nodes and links, or richness of topology grows • metrics: routing entities, memory requirements, routing stretches, routing overheads, etc.; • Large-scale experimental evaluation of VIRO reliability • how well does it adapt to dynamic topology changes, failures • metrics: convergence speed, response time, packet loss, control load, … • Experimental evaluation of VIRO multi-path routing at scale • What GENI facilities or tools can we leverage to facilitate these experiments at scale? • workload generation? dynamic (experiment) topology control? failure generation? monitoring and measurement tools? • what scale (# nodes, links, topology richness) can we attain?

  15. Summary VIRO as a non-IP (layer 3) service • Test, evaluate & shake-down GENI in terms of its flexibility & limitations for realizing non-IP services • in particular, the OVS platform used by GENI • hope to report our results on these by end of Year 1 • Test, evaluate & shake-down GENI in terms of its support for large-scale evaluation of a non-IP layer 3 routing protocol & service • What control do experimenters have in experiment design? • What scale can we attain? How realistic can we get? • hope to report our results on these by end of Year 2 • If successful, incorporate into GENI as long-running service? To support other research & experiments? • Will also enable our own research on SDN, CDN/CCN and future network architecture designs

  16. Thank You! Questions?

  17. Pros & Cons of Existing Technologies • (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 • (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

  18. M C N H D G A L J E B F K 1 0 Vid Assignment : Key Properties 1 1 0 0 0 1 1 1 0 1 0 0 0 1 0 0 1 1 1 0 1 0 1 1 1 1 1 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 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. E - F - G - H - J - - - K - L - A - B - C - D - M - N - - - - - 01000 00100 01001 10110 00000 00110 11000 10100 10000 11110 00010 10010 11100

  19. 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

  20. M M M C \ C N N H H N H D D D G G G A A A L L L J J J E E E B B B F F F K K K M M C C N H N H D D G G A A L L J J E E B B F F K K 0 Vid Assignment: Bootstrap Process 0 0 0 0 0 0 0 0 0 0 0 0 0 00 00 10 10 00 10 00 10 00 00 00 10 10 000 1000 100 0100 110 1001 110 010 0110 0000 000 0110 110 1000 0100 100 000 0000 000 1110 Initial vid assignment and vid space construction performed during the network bootstrap process Performed using either a centralized or distributed vid assignment algorithm. 010 100 0010 010 0010 1100

  21. VIRO Routing: Routing Table Construction • Correctness of the algorithm can be formally established! Bottom-up, “round-by-round” 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)

  22. VIRO Routing: Key Features • Inspired by Kademlia DHT • but need to build end-to-end connectivity/routes! • Bottom-up, round-by-round process • first: neighbor discovery • then: build routing entries to reach nodes within each level of the vid space (virtual binary tree) • use “publish-query” mechanisms • Highly scalable: O(L) routing entries per node • L = O(log N), N: number of nodes (VIRO switches) • more importantly, path diversity (e.g., multi-path routing) can be naturally exploited for load-balancing, etc. • routing is no longer “shortest” path based ! • No single point of failure, and localize effect of failures • unlike link state routing, node/link failure/recovery is notflooded network-wide; impact scope is limited • also enable localized fast rerouting • Completely eliminate “network-wide” control flooding

  23. 1 0 VIRO Routing: Some Definitions 1 1 0 0 0 1 1 1 0 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 0 0 0 1 0 0 1 1 1 0 1 0 1 1 1 1 1 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 E - F - G - H - J - - - K - L - A - B - C - D - M - N - - - - - 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}

  24. M C N H D G A L J E B F K VIRO Routing: Routing Table - - - - - - - - - - - - - - - - - - - 01000 00100 01001 10110 00000 00110 11000 10100 10000 11110 00010 10010 11100 1 0 1 1 0 0 0 1 1 1 0 1 0 0 1 0 0 1 1 1 0 1 0 1 1 1 1 1 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 E F G H J K L A B C D M N

  25. M C N H D G A L J E B F K VIRO Routing: Example E.g. Node A: discover three direct neighbors, B,C,D; build the level-1 routing entry to reach B1(A)={} 01000 00100 01001 10110 00000 00110 11000 10100 10000 11110 00010 10010 11100 Routing Table for node A • 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)

  26. M C N H D G A L J E B F K VIRO Routing: Example … 01000 00100 E.g. Node A: B2(A)={B}; node A directly connected to node B; publish itself as gateway to B2(A) 01001 10110 00000 00110 11000 10100 10000 11110 00010 10010 11100 Routing Table for node A • 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)

  27. M C N H D G A L J E B F K VIRO Routing: Example … 01000 00100 01001 10110 00000 00110 E.g. Node A: B3(A)={C,D}; A publishes edges A->C, A->D to “rendezvous point” in S2(A), say, B; 11000 10100 10000 11110 00010 10010 11100 • 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)

  28. M C N H D G A L J E B F K VIRO Routing: Example … 01000 00100 01001 E.g. Node A: B4(A)={M,N}; A queries “rendezvous point” in S3(A), say, C; learns C as gateway 10110 00000 00110 11000 10100 10000 11110 00010 10010 11100 • 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)

  29. VIRO Routing: Example … 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 M C 01001 N H 10110 00000 D G A 00110 11000 10100 L 10000 J 11110 E B F K 00010 10010 11100 • 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)

  30. M C N H D G A L J E B F K VIRO Routing: Packet Forwarding 01000 00100 01001 10110 00000 00110 11000 10100 10000 11110 00010 10010 11100 • 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

  31. <pid, vid> Mapping and vid Lookup • pid: persistent identifier of end host/device, or switch • e.g., MAC/IP address, or any other layer 2/3 address, “flat” host id, or higher layer names • can simultaneously support multiple namespaces • <pid, vid> mapping registration and look-up using Kademlia DHT on top of the same vid space • Hash(pid) -> vidkey: used for registration & look-up • mapping stored at “access switch” whose vid is “closest” to vidkey • Look-up speed, scalability & mobility support trade-off • can use one-hop or multi-hop DHT • or use hierarchical (or “geographically scoped”) hash tables • vid look-up and data forwarding may be combined • use hierarchical (or “geographically scoped”) rendezvous points • provide better support for mobility

  32. VEIL: a VIRO Realization over Ethernet (and 802.11, etc) • switch vid (32 bits) • assigned to switches using the vid assignment process • L: default 24 bits • host id (16 bits) • assigned by “host-switches” • uniquely identify hosts directly connected to a switch. L • End hosts agnostic of their vid’s • Host switch performs vid/MAC address translation • Backward compatible w/ Ethernet, 802.11, etc. Re-use 48-bit MAC addresses for vid vid structure: divided into two fields

  33. VIRO Switch Sz VEIL: <IP/MAC, vid> Mapping Access-switch for y VIRO Switch Sx register mapping IPy VIDy VIRO Switch Sy y x Host-switch for y An example using IP address as pid • Host-switch: • a switch directly connected to the host • discover host MAC/IP through (gratuitous) ARP, and assign vid to host • host-switch publishes pidvid mappings at an “access-switch” • Access-switch: • a switch whose vidis closest to hash (pidof the host)

  34. Address/vid Lookup & Data Forwarding VIRO Switch Sz 3. ARP Reply (IPy VIDy) 6. Sy changes destination MAC address Ethernet packet (VIDx MACy) 2. ARP query forwarded as unicastrequest (IPy MAC?) 1. ARP Query (IPy MAC?) VIRO Switch Sx VIRO Switch Sy y x 5. Sx changes source MAC address Ethernet Packet (VIDx VIDy) 4. Ethernet packet (MACx VIDy) • Use DHT look-up for address/vid resolution • with local cache • vidto MAC address translation at last-hop

  35. More Than One Gateway Exist and Can be Used ! E - F - G - H - J - - - K - L - A - B - C - D - M - N - - - - - 1 0 1 1 0 0 0 1 1 1 0 1 0 0 0 1 0 0 1 1 1 0 1 0 1 1 1 1 1 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1

  36. VIRO: Scalable, Robust & Name-Independent Virtual Id Routing for (future) Large-scale, Dynamic Networks main student contributors: Sourabh Jain Yingying Chen Saurabh Jain Guor-Huar Lu

More Related