Unde nderstandi nding ng the he Evolvi ving ng Interne rnet Ram Durairajan Assistant Professor, Computer and Information Science Co-director, Oregon Networking Research Group University of Oregon 0
In Inter erne net t is is a a co complex syst ystem Users, Apps and Data Mobile Devices Datacenters and CDNs SDNs and NFVs Cloud Services Internet of Things Physical Internet 1
Physic Ph ical al In Inter ernet To London Point of Presence (POP) Datacenter Colocation facility … Fiber optics link Conduit Submarine cable Dark fiber Lit fiber 2
Problem Pr Perfect Connectivity No Connectivity Existing Mechanisms ( e.g. , traffic engineering) Level of Robustness ( Robustness: ability of the physical Internet to cope with evolution ) Gi Given the claim that In Inter ernet’s d s desi esign i is r s rob obust, , why do we have • ou outages? P es? Per erfor ormance i e issu ssues? B es? Bandwidth th on on d dem emand? 3
No No o one h has a a c complete v view o of t the I Internet Autonomous Router-level Systems-level Topology Topology Source: Lumeta Source: Peer1 4
Problem Pr Perfect Connectivity No Connectivity Existing Mechanisms ( e.g. , traffic engineering) Level of Robustness ( Robustness: ability of the physical Internet to cope with evolution ) Gi Given the claim that In Inter ernet’s d s desi esign i is r s rob obust, , why do we have • ou outages? P es? Per erfor ormance i e issu ssues? B es? Bandwidth th on on d dem emand? What about evolving components? IoTs? Private interconnects? • How do we transcend this robustness gap to build a better • Internet? 5
Ou Outline Introduction and Motivation Unravelling the Structural Complexity - Mapping the Internet Ecosystem Providing Flexible Decision Support 6
Ma Mapping the Intern rnet ecosystem • XConnects, Cloud connects and Private Interconnects • Internet of Things • Long-haul and Metro 7
Ma Mapping the Intern rnet ecosystem • XConnects, Cloud connects and Private Interconnects • Internet of Things • Long-haul and Metro 8
Mapping the Internet of Th Things • Map and Characterize the IoT devices and deployments • An active measurements-based approach • Specific focus on IPv6-enabled IoT devices • Challenges • IPv6 address space is large. How to efficiently scan IPv6 prefixes? • How to differentiate IoT vs. non-IoT devices? • Apply this to problems of interest • Security and privacy, census and survey, business intelligence, etc. 9
Ma Mapping long-ha haul ul and nd metro • Internet Atlas: a comprehensive repository of the Physical Internet • Search-based data • Maps nodes, links, fiber strands, etc. • Repository has over 1,400 maps • Apply this to problems of interest • Robustness, performance, security, resilience, etc. • Popular Science • Best of What’s New, Security Category, 2017 • One of the 100 Greatest Innovations of 2017 10
Ma Map of US S long-ha haul ul fiber ber 11
Asse Assessi ssing ng infr frastruc uctur ure sha sharing ng • Striking characteristic of constructed maps is conduit sharing • 20-year fiber IRU to reduce costs 12
Connectivity-on Co only s shared r risk • How many ISPs share a conduit? 600 542 conduits 89.67% 500 400 Raw number 63.28% 53.50% 300 200 12 critical 100 choke points 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Number of ISPs sharing a conduit Physical connectivity lacks much diversity that is a hallmark of commonly-known models. 13
Ke Key observation • There is a lot of sharing in the Internet • Risks and outages • Optical connections cannot be reconfigured • Inflexibility • Risks + outages + inflexibility = NOT robust! 14
Ou Outline Introduction and Motivation Unravelling the Structural Complexity Providing Flexible Decision Support - Building systems to create a better Internet 15
Ne Need f for f flexible d deci cision s support • Flexible decision support is important • Enhance robustness, resilience, security • Resilience: remove the inflexible leasing model (and reduce shared risk) • Security: connectivity/bandwidth on demand to counter volumetric DDoS attacks • Given the understanding of the physical Internet, what radical change can we introduce to build a better Internet? • Wide-area Connectivity as a Service • Agility meets the Internet • E.g., Deploy NFVs in the wild 16
Wi Wide de-ar area ea Connec ectivity tivity as as a a Ser ervic vice • Objective: a system (called GreyFiber) for cloudification of the physical Internet • Cloud: Rent cycles, use resources, and release • GreyFiber: Rent connectivity, transfer data, and release connectivity • System considers • Infrastructure abundance ( e.g. , unused fiber) • Market economics ( e.g. , CAPEX, OPEX) • Technology trends ( e.g. , fast remote reconfigurations in routers) • Flexible access to fiber-optic paths between endpoints ( e.g. , IXP) over a range of use scenarios 17
Gr GreyFib iber sy system design • GreyFiber consists of three components • Global control, local site control and physical infrastructure substrate 18
• Control and command center Fiber Exchange • Sellers are major fiber/major GreyFiber Sellers Buyers Global cable providers Control Global Controller • Buyers are the customers (e.g., CDNs, enterprise networks) • Fiber exchange to enable economic viability • Runs GSP auctions • Global controller • Traffic engineering • Time-based circuit provisioning • Network management • Backup restoration
• Local control over marked Fiber Exchange geographic region ( e.g. , IXP) GreyFiber Sellers Buyers Global • Mimics minimal functionalities Control from global control Global Controller • Configure links Site A Site C • Monitor connectivity Local Local GreyFiber Controller Controller • Report statistics to global Local Site Site B Control control Local Controller
• Composed of traditional nodes Fiber Exchange and links ( e.g. , fiber paths) GreyFiber Sellers Buyers Global • Assumption Control • Fiber is already lit Global Controller Site A Site C Local Local GreyFiber Controller Controller Local Site Site B Control Local Controller Physical Infrastructure
GreyFib Gr iber sy system design • GreyFiber consists of three components • Global control, local site control and physical infrastructure substrate • Supports a range of use scenarios • Small (seconds to minutes), medium (hours), large (days to months) and extra-large (years) • Short lifetime to address unexpected outages and demands • Medium-to-large to service unexpected demands without deadlines • Extra-large to support traditional lease 22
Gr GreyFib iber im implem lemen entatio tion an and evalu aluatio tion • Implemented in ~22K lines of Python code • Evaluated in GENI and CloudLab testbeds 23
Ke Key results • Performance benefits of GreyFiber? 1G on GENI 10G on CloudLab 24
Qu Questions? Thanks to Reza Rejaie, Paul Barford, Joel Sommers, Walter Willinger and “great” students! Ram Durairajan ram@cs.uoregon.edu 25
Recommend
More recommend
