Advances in Rou.ng Models and Algorithms (for the Internet)

Transcription

1 Advances in Rou.ng Models and Algorithms (for the Internet) EULER Summer School 2013 July 1-5, 2013 Barcelona Spain Dimitri Papadimitriou lucent.com Alcatel- Lucent Bell NV

2 Outline Introduc.on Part I: Fundamental dimensions of rou.ng models and algorithms Shortest path rou.ng (and variants) Part II: Alterna.ves Space and tradeoffs Compact rou.ng Part III: Recent advances Geometric rou.ng on hyperbolic spaces Concluding remarks

3 Outline Introduc.on Part I: Fundamental dimensions of rou.ng models and algorithms Shortest path rou.ng (and variants) Part II: Alterna.ves Space and tradeoffs Compact rou.ng Part III: Recent advances Geometric rou.ng on hyperbolic spaces Concluding remarks

4 Internet and Rou.ng System RFC 4984: Report from IAB Workshop on Rou.ng & Addressing (Sep.07) Reports outcome of Rou.ng and Addressing IAB Workshop held on Oct., 2006 Goal: develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet rou.ng system Findings: analysis of the major factors that are driving rou.ng table growth, constraints in router technology, and the limita.ons of today's Internet addressing architecture Has anybody made any serious estimates of how long it will be before we run out of 32-bit IP addresses? IPng (Internet Protocol Next Generation) a.k.a. IPv6: 1991 to BGPv3 (RFC 1267, Oct.1991) BGPv4 (RFC 1771) BGP: reaction to need for NSFnet policy routing ROAD (Routing and Addressing) RFC 1287: Towards the Future Internet Architecture, Dec Classless Inter-domain routing (CIDR) as reaction to running out of class B RFC 1338 (Jun.92) - RFC 1519 (Sep.93) Internet Protocol, Version 6 (IPv6) RFC 1883 (Dec.95) - RFC 2460 (Dec.98) NewArch ( ): Future- Generation Internet Architecture RPO - Grow WG BGPv4 (RFC 4271) RAWS (Sep.2007) - RRG CAIDA (97) IPv4 pools usage 98.4% (exhaustion by )

5 Posi.oning of research efforts Research efforts can be classified as follows i) incremental improvements to BGP BGP BGP++ ii) new class of path- (vector) based rou.ng protocols BGP Path(-vector) iii) new rou.ng paradigms BGP???

6 Objec.ve and Target Target space: dynamic rou.ng (distributed x adap.ve) Objec.ve: determine if there is more than one rou.ng scheme possible in that space (today: only BGP(++) and PV) Centralized Sta.c Sta.c Fault- tolerant Adap.ve Distributed Compact rou.ng Geometric rou.ng etc. Today: BGP or Path vector no simple transi.on possible from to

7 Fundamental Tradeoffs Sta.c rou.ng: memory space x stretch (x computa.onal complexity) of distributed rou.ng func.on Memory space (RT Size) Adapta.on Adapta.on to dynamics of topology, policy, etc. Stretch (rou.ng path length) Dynamic rou.ng adds adapta.on cost Communica.on cost (distributed rou.ng algorithm) number of rou.ng updates per topology/policy change Processing cost: store rou.ng update process (compute and possibly add/remove, or replace RT entry) distribute rou.ng update

8 Current Internet Growth Rate Traffic Traffic volume (per month): [8,9] Exabytes Traffic growth rate: 50% (+/- 5%) per year Rou.ng tables size Number of ac.ve RT entries: 320k (Feb.2010) Growth rate: 15%- 25% per year Autonomous Systems (AS) Number of adver.zed AS: 33k (Feb. 2010) Growth rate: 10% per year Characteris.c AS- path length: steady ~3.4 Growth of Active BGP Entries (from Jan 89 to Feb 10) Jan FIB Size: 176,000 prefixes Update Rate: 0.7M prefix updates / day Withdrawal Rate: 0.4M prefix withdrawals / day Jan FIB size: [275,000;300,000] prefixes - Update Rate: 1.7M prefix updates / day - Withdrawal Rate: 0.9M withdrawals / day Jan (low-end predictions) - Size: [370,000;400,000] prefixes - Update Rate: 2.8M prefix updates per day - Withdrawal Rate: 1.6M withdrawals per day - 550Mbytes Memory - 120% of 1.5Ghz processor Number of AS advertised in BGP routing table Ratio: prefix/as ~ 10 Source: BGP Routing Table Analysis Reports -

9 Current Internet Growth Rate Dynamics BGP updates (rou.ng convergence) Between Jan.2006 and Jan.2009: prefix update and withdrawal rates per day increased by a factor of about [Huston07] Average: 2-3 per sec. Peak: O(1000) per sec. BGP suffers from churn which increases load on routers due to topological failures and traffic engineering (prefix de- aggrega.on) BGP s path vector amplifies these problems (path explora.on)

10 Addressing (amplifica.on of address prefix de- aggrega.on) Originally, host IP addresses were Provider Allocated (PA) and assigned based on network topological loca.on Adop.on in the mid 90's of Classless Inter- Domain Rou.ng (CIDR) [RFC4632] to perform address aggrega.on was felt sufficient to handle address scaling Condi.ons to achieve efficient address aggrega.on and rela.vely small rou.ng tables (tradeoff rou.ng informa.on aggrega.on vs granularity) are not met anymore [RFC4984] Deteriora.on root causes Host mobility, site mul.- homing (~25% of sites), traffic- engineering (prefix de- aggrega.on) RIR policy to allocate PI addresses (not topologically aggregatable) thus making CIDR ineffec.ve Super- linear growth of rou.ng table (rou.ng protocol must not only scale with increasing network size!) Even if network itself would not be growing

11 Outline Introduc.on Part I: Fundamental dimensions of rou.ng models and algorithms Shortest path rou.ng (and variants) Part II: Alterna.ves Space and tradeoffs Compact rou.ng Part III: Recent advances Geometric rou.ng on hyperbolic spaces Concluding remarks

12 Preliminaries (Unweighted) Graph G = (V,E) Set V of ver.ces (nodes), V = n Set E of edges (links), E = m Elements of E are pair (u,v) where u,v V An edge (v,v) is a self- loop Weighted Graph G = (V,E,ω) Elements of set E are ((u,v),ω) where ω is a numerical value called the weight of the edge (u,v) which can represent e.g. cost Directed graph (digraph) The edge pairs are ordered Undirected graph The edge pairs are unordered E is a symmetric rela.on (v,w) E implies (w,v) E In an undirected graph (v,w) and (w,v) are the same edge

13 Preliminaries Network topology modeled as undirected unweighted graph G = (V,E) Router- level topology: ver.ces (nodes) set V, V = n, represents routers or inter- connec.on points, and edges (or links) set E, E = m, represents nodes interconnec.on AS- level topology: ver.ces (abstract nodes) set V, V = n, represents the autonomous systems (AS), and edges (or links) set E, E = m, represents the interconnec.on between AS pairs (u,v), u, v V Diameter Δ(G): maximum length of the shortest (topological) path p(u,v) between any two pair of ver.ces (u,v), u, v V D = set of reachable des.na.ons (n D ) Path from source s to des.na.on t, p(v 0 =s,v m =t): node sequence [v 0 (=s),v 1,...,v i- 1 =u,v i,...,v m (=t)] such that v i is adjacent to v i- 1, (v i- 1,v i ) E(G), i Note: dis.nc.on between rou.ng path and topological path!

14 Rou.ng Algorithm and Func.on Rou.ng algorithm: algorithm that computes a (set of) loop- free paths, such that given a des.na.on node s name, any node can forward messages toward any des.na.on node Rou.ng func.on f: t D (n D ), each node u V(G) determines adjacent node w, (u,w) E(G) along computed loop- free rou.ng path from u to v, p(u,w,...,v=t) so that incoming messages directed to t can reach that des.na.on s dest. t via u a u dest. t via a b x dest. t via w w t d dest. t via c c dest. t via u

15 Procedure vs Algorithm Procedural model: a procedural model refers to the formal descrip.on of the procedures Procedure: method to perform a given task/ac.on specified as a sequence of discrete steps (each step being a finite instruc.on or opera.on, finite meaning represented by a finite number of symbols) which have to be executed in a regular definite order in order to always obtain the same result under the same condi.ons. In context of rou.ng Rou.ng model refers to the procedural model together with its associated data model, state machine model, and the data communica.on model which characterizes the interac.ons and interfaces (i.e. messages, calls, events, etc.) between the elements of the model (i.e. procedures, data structures, state machines) Procedures are devised as computa.onal models of sequences of opera.ons that the rou.ng func.on is conjectured to perform as it processes rou.ng informa.on

16 Procedure vs Algorithm Algorithm: sequences of steps (opera.ons, instruc.ons, statements) for transforming inputs to outputs Input - > precondi.ons of the algorithm: descrip.on of the inputs, including their types as well as any rela.onships or proper.es that they must sa.sfy before execu.on Output - > post- condi.ons of the algorithm: descrip.on of the outputs, including all rela.onships and proper.es that must be sa.sfied aser execu.on) Algorithm provides the descrip.on of effec.ve computa.onal procedures composing the procedural model Note that an algorithmic scheme provides the descrip.on of class of effec.ve computa.onal procedures (that are based on the same "principles") composing the procedural model Termina.on and Correctness of the algorithm Termina.on: situa.on such that whenever the precondi.ons are sa.sfied, the algorithm will stop running aser a finite number of steps (e.g., no infinite loops) Correctness: situa.on such that whenever the pre- condi.on are sa.sfied before the algorithm executes, the post- condi.ons will be sa.sfied aser it executes. Note: correctness without termina.on is called par.al correctness whereas total correctness refers to par.al correctness with termina.on

17 Func.onal Dimensions Func.onal dimensions Distribu.on: by means of asynchronous messaging/processing (no coordina.on, no prior seq., etc.) Adap.vity: to topology dynamics, policy dynamics (possibly traffic dynamics) Addressing: rou.ng on locators (with node iden.fiers assigned independently of the topology) Specializa.on: take benefit of Internet topology proper.es Policy: enable each network administra.ve par..on to apply its own rou.ng policy without requiring explicit exchange of these policies neither mandate homogeneous policy rules Security

18 Distribu.on Distributed rou.ng func.on: rou.ng func.on f executed locally at each node u V(G) s dest. t via u a u dest. t via a b x dest. t via w w t d dest. t via c c dest. t via u Distributed rou.ng algorithm: each node u V(G) performs locally, asynchronously and independently of the other nodes the computa.on of the rou.ng paths used by the rou.ng func.on f

19 Distribu.on Source rou.ng Rou.ng path computa.on performed at source node only Each datagram carries in its header a complete descrip.on of the path along which datagram should be routed Local router does only need to maintain local rou.ng informa.on e.g. the address of its neighbors (next- hop) Drawback: datagram headers need to be of size (n) and s.ll be processed at wire speed Table rou.ng: each node stores a Rou.ng Table (RT) Distributed rou.ng func.on f executed at each node u V(G) Each node can perform an independent rou.ng decision (local RT include an entry for any des.na.on): the next- hop/link to which packets for that des.na.on should be forwarded Drawback: for shortest- path rou.ng, resul.ng RT size require to store Ω(n log(n)) bits of rou.ng informa.on where n is the number of nodes

20 Adap.ve Rou.ng Func.on Adap.vity: capacity of the rou.ng func.on to react autonomously in a.mely and cost- effec.ve manner when internal/external events occurs that affect its value delivery s Adapta.on can be dest. t via u a u dest. t via a Structural: adap.vity to topology changes due to network engineering (e.g. add/ remove link or node) or network failures Traffic: adap.vity to spa.o- temporal traffic varia.ons/dynamics leading to traffic engineering decisions Administra.ve: adap.vity to non- technical constraints and/or objec.ves driven by cost minimiza.on, profit/revenue maximiza.on, etc. (rou.ng policy dynamics) b dest. t via w x w t

21 Adap.vity Updatefull rou.ng: rou3ng in the light with non- local (.mely) knowledge about network topology Dynamics of rou.ng informa.on exchanges resul.ng from Network topology updates (dynamic reac.on to topological changes due to e.g. link/node failures) Rou.ng informa.on updates (impacts number of inter- domain rou.ng messages exchanged among BGP routers) Updates requiring RT recalcula.on can lead to convergence delay, instabili.es, and processing overhead Communica.on cost lower bound for scale- free graphs is at best linear (up to logarithmic factors) Updateless rou.ng: rou3ng in the dark without non- local (.mely) knowledge about network topology Do not require to exchange rou.ng updates Do not maintain non- local knowledge about observed network topology for rou.ng state to converge

22 Iden.fier vs. Locator Locator (func.on): iden.fies a loca.on in an internetwork Nodes and endpoints are assigned locators A node is assigned only one locator An endpoint can be assigned more than one locator so that a locator might appear in more than one loca.on of an internetwork. Locators iden.fy where the node is posi.oned in the network. Locators do not specify a path to the node A locator can take the form of a topology dependent label (flat and unstructured) topologically assigned address (structured) or a coordinate (structure determined by the geometric space) Iden.fier (func.on): iden.fies unambiguously a node Iden.fier value space is topology independent Names (or simply iden.fiers) Topologically independent address (structured)

23 Iden.fier vs. Locator Stricto sensu, rou.ng func.ons act on locators, i.e., these iden.fiers are not used in making rou.ng computa.on or decisions "name- independent" rou.ng (i.e., schemes that work with topology- independent iden.fiers) can be seen as name- dependent rou.ng (using locators) opera.ng underneath an iden.fier- to- locator resolu.on func.on Resolu.on func.on can operate Locally at each node (some.mes even by locally equa.ng the iden.fier to its associated locator) and is osen customized on per rou.ng scheme basis By means of addi.onal resolu3on system performing transla.on, conversion or mapping from a node iden.fier to its associated locator(s) Examples Current IP rou.ng do not differen.ate between IP addresses used as iden.fiers (Provider Independent addresses) or locators (Provider Allocated addresses) Host Iden.ty Protocol (HIP) IP addresses func.on as pure locators, and applica.ons use Host Iden.fiers to name peer hosts (instead of IP addresses) Geometric rou.ng: coordinates are locators, and applica.ons use Host Iden.fiers to name peer hosts Name- independent compact rou.ng: requires an iden.fier- to- locator resolu.on func.on distributed among nodes and performing on top of name- dependent compact rou.ng using locators

24 Iden.fier vs. Locator Topology- dependent (label- based) schemes Networking: node address or locator refers to topologically informa.ve iden.fier ( PA address) Name- independent schemes Networking: node iden.fier refer to topologically agnos.c address ( PI address) Name Name Iden.fier Resolu.on Resolu.on Provider independent (PI) IP Address Address Locator Address Provider allocated (PA) IP Address Rou.ng

25 Iden.fier vs. Locator - > Rou.ng scheme Topology- dependent (label- based) rou.ng scheme Node iden.fiers (or labels) assigned from topologically dependent name space: encode some topological informa.on (labels thus cannot be arbitrarily selected) Implica.ons: addressing (naming) scheme follows topology Label encodes topological informa.on useful for rou.ng Packet carries the chosen des.na.on label in its header Topology change Possible node label change (renaming) Name- independent rou.ng scheme Node iden.fiers assigned from topologically independent name space Implica.ons: addressing (naming) scheme does not follow topology and topology does not follow naming scheme Note: scalable name- independent schemes are highly desirable for Internet rou.ng (site mul.- homing, mobility, etc.)

26 Universality vs. Specializa.on Universal (rou.ng scheme works correctly and sa.sfies scaling bounds on all connected graphs) vs specialized (if it does so only on some specific graph classes) Internet topology shows proper.es* of scale- free graphs Node degree (k) distribu.on: power law P(k) ~ k - γ with scaling index γ ~ [2.1;2.2] Fewer nodes with large degree and large number of nodes with low degree Clustering coefficient (=0.4) characterizes the extent to which ver.ces adjacent to any vertex v are adjacent to each other) Strong clustering means large number of triangular sub- graphs Node degree correla.on: nega.ve correla.on between node s degree and its nearest- neighbors average degree (disassorta.ve mixing: high- degree nodes tend to connect with low- degree nodes and visa versa) Characteris.c path length (~4 (3.5)): median of the means of shortest path lengths connec.ng each node to all other nodes Average distance d between nodes grows propor.onally to log(n), where n is number of nodes * it does NOT mean we assume that the Internet topology is a scale-free graphs (or not) but it shows certains properties associated to scale-free graphs

27 Policy Dimensions Heterogeneous: rou.ng policies rules are specified locally per administra.ve par..on (no global coordina.on/explicit exchange or policies) Independence: rou.ng policies are specified independently of others administra.ve par..on policies (no incen.ve compa.bility) Distributed: rou.ng policies are enforced per administra.ve par..on (no central coordina.on) Implicit: no policy exchange between administra.ve par..on Internet context: each network administra.ve par..on applies its own rou.ng policy without requiring explicit exchange of these policies (or their exposure to a third party) neither mandate homogeneous policy rules for the rou.ng scheme to properly operate Open ques.on Is policy model independent of rou.ng model (coupling)? How to "prevent" detrimental effects?

28 Security To prevent falsifica.on, interference, overload, etc. security model must to ensure deployability: incremental deployment model that provides some benefit for par.cipants (e.g., routers, network par..ons) to ensure robustness: ability to maintain and return to a significantly converged state without reliance on external systems to prevent performance degrada.on: rou.ng scheme convergence speed, with a security system in opera.on, should deliver equivalent performance than the same rou.ng scheme running without security system in opera.on Each network administra.ve par..on to apply its own security rules (because various parts of the network may require different security rules) star.ng from a common baseline without manda.ng homogeneous security rules for the rou.ng scheme to properly operate Security mechanisms include Rou.ng path verifica.on (par.al or complete) Valida.on of rou.ng informa.on originator/sender Etc.

29 Performance Dimensions Performance dimensions Scalability: memory space consump.on by local RT Quality Stretch Stability Convergence Computa.onal complexity of the rou.ng algorithm (both in.me and space) Communica.on complexity/cost Rate x size of rou.ng update/informa.on messages required to maintain coherent and.mely non- local knowledge of network topology Fault- tolerance/maintanability

30 Scalability Defini.on: ability of a computa.onal system (hardware or sosware) to con.nue to func.on (without making changes to the system) under sa.sfactory and well specified bounds, i.e., without affec.ng its performance, when its input is changed in size or volume or in their rate of varia.on Scalability measured by rate x state x size of input that the system can sustain when running using a given number of resource units (for processing and storage) In distributed rou.ng, measured by 1. Memory space consumed to store the rou.ng informa.on 2. Memory space consumed to store the resul.ng rou.ng table entries 3. Sustainable rate of communica.on messages (that result in re- computa.on and/or replacement of the rou.ng table entries).

31 Scalability Scalability (#states x size) memory space consump.on by RT) RT size scaling "be er than" (n log n) sub- linear rou.ng table size scaling (preferably of order of log n)), where n is the number of (abstract) nodes Memory (size to store routing table entries) shortest-path routing (BGP): n log(n) bound above by n bound below by log(n) # nodes Examples Increasing number of nodes/as, increasing number of links Increasing number of hosts/prefixes

32 Rou.ng Path Quality Defini.on: quality of a rou.ng path as produced by the rou.ng algorithm (both in sta.onary and non- sta.onary condi.ons) is determined by their stretch, stability, and convergence proper.es Performance objec.ves: 1. Path cost/length (stretch): minimize the ra.o between the cost/length of the rou.ng path(s) as produced by the rou.ng scheme and the minimum path cost/length for the same source- des.na.on pair Note that resilient/fault- tolerant schemes may further deteriorate this ra.o 2. Stability: property of rou.ng paths to remain close to their ini.al state upon perturba.on/devia.on resul.ng from Explora.on of the rou.ng state space (compared to the BGP uninformed path explora.on intrinsic to path vector algorithm) Rou.ng policies interac.ons (compared to BGP rou.ng policy interac.ons that can lead to instabili.es) 3. Convergence

33 Rou.ng Path Quality (1): Stretch Mul.plica.ve stretch (of a rou.ng scheme) Defini.on: max.ra.o over all source- des.na.on pairs between the cost/ length of the rou.ng path(s) as produced by the rou.ng scheme and the minimum topological path cost/length for the same source- des.na.on pair Algorithm stretch: max. ra.o among all node pairs (source, dest.) in all graphs Intui.vely: provides a quality measure of increase of paths length (cost) produced by a rou.ng scheme compared to the minimum path length (cost) Examples Shortest path rou.ng algorithm either AS- path length based (path vector rou.ng) or cost- metric based (link- state rou.ng) are stretch- 1 Shortest path rou.ng is incompressible (lower = upper bound): Ω(n log n) bits required to store rou.ng informa.on in rou.ng table Compact rou.ng schemes that produce reduced rou.ng tables, are not always able to choose minimum cost/length path for a given des.na.on In general, rou.ng scheme should favor computa.on and/or selec.on of routes whose stretch remains closer to 1

34 Rou.ng Path Quality (1): Stretch Performance objec.ve: bound stretch of rou.ng paths as produced by the rou.ng scheme to a rela.vely small constant factor that does not grow with the network size Routing model stretch Cumulative Frequency Distr number of nodes stretch

35 Rou.ng Path Quality (2): Stability Characterized by its response (in terms of processing of rou.ng informa.on) to inputs of finite amplitude Inputs may be classified as follows Internal events Rou.ng protocol configura.on change Sosware changes/updates External events Topological changes Policy changes Both types of events lead to exchange of rou.ng updates that may result in rou.ng states changes Note: BGP does not differen.ate rou.ng updates with respect to their root cause, their iden.fica.on (origin), etc. during its selec.on process

36 Rou.ng Path Quality (3): Convergence Rou.ng Path (state) Convergence Upon occurrence of an "unreachability" event due to physical topology change, rou.ng topology change, etc., measures the number of opera.ons/execu.on steps (expressing the convergence.me) needed to reach a new rou.ng state Proper.es of new rou.ng state (resul.ng from local re- computa.on of new rou.ng path) Consistency (do not result in any forwarding loop due to this event) Globally stable (do not lead to any subsequent re- computa.on of rou.ng table entries due to this event) Rou.ng must provide means to converge to a new stable and consistent short- /long- live rou.ng state before the next event occurs

37 Computa.onal Complexity Defini.on: measures the computa.onal resources needed to solve computa.onal problem (rou.ng path re- computa.on) either Time: number of elementary computa.onal steps per second number of opera.ons/execu.on steps (expressing the computa.onal.me) needed to compute a (set of) rou.ng paths/rou.ng entries as a func.on of the input size Space: size of memory (usually measured in bits or bytes) amount/size of memory in bits or bytes needed to compute a (set of) rou.ng paths/rou.ng entries Note: computa.onal complexity of a rou.ng algorithm is measured by its complexity in.me and space Performance objec.ve: computa.onal complexity (both in.me and space) to compute a (set of) rou.ng paths should grow sublinearly with the input size (e.g. number of reachable nodes/prefixes) Note: Input size depends on the topology proper.es such as the number of nodes/links, the number of paths/prefixes, network diameter, etc.

38 Communica.on Cost / Complexity Defini.on: number/rate of (rou.ng and/or topology update) messages exchanged between nodes to maintain a coherent and.mely non- local knowledge about network topology and/or reachability such that each node can (re- )compute a consistent (set of) rou.ng table entries Can be complemented by Size of communica.on messages (rou.ng and/or topology updates) Sustainable rate of communica.on messages (rou.ng and/or topology update)

39 Maintanability (1) Maintainability: probability P m that a system or component will be retained in or restored to a specified condi.on within a given period of.me Improving rou.ng system availability implies thus to improve MTTR and more generally maintainability capabili.es of rou.ng system by means of resiliency/fault- tolerance techniques Performance objec.ves Maximize percentage of links (or nodes) that can be fully protected (for all des.na.ons) while minimizing recovery resources (protec.ng path length/cost) Maximize percentage of des.na.ons that can be protected for all link (or node) failures while minimizing recovery resources (protec.ng path length/cost) Maximize percentage of total poten.al failure cases (des.na.on x failures) that are protected while minimizing the recovery resources (protec.ng path length/ cost) Minimize difference between number of packet flowing through network towards their des.na.on before and aser failure occurrence, i.e., maximize percentage of packets passing through network that will con.nue to reach their des.na.on by using protec.ng paths

40 Maintanability (2) Measured by the MTTR (mean.me to repair) Mean Time To Repair of the rou.ng table entries and associated forwarding paths Maintanability criteria MTTR of forwarding paths from links/nodes failure must be short enough (while minimizing the mobiliza.on of protec.ng resources) so that difference between the number of packets flowing through the network towards their des.na.on before and aser failure occurrence is negligible Coverage should be op.mized against recovery resources mobilized Percentage of links/nodes that can be fully protected for all des.na.ons (Note: some percentage of the possible failures may be iden.fied as being un- protectable). The percentage of des.na.ons that can be protected for all link (or node) failures (Note: some percentage of des.na.ons may be iden.fied as being un- protectable)

41 Note: Repair Coverage Applies to fault- tolerant rou.ng schemes by means of repair paths pre- computed in an.cipa.on of topological failure and made available for invoca.on with minimal delay Provides a comparison metric for measuring and comparing fault tolerant rou.ng schemes Percentage of links (or nodes) that can be fully protected (i.e., for all des.na.ons). Note that some percentage of the possible failures may be iden.fied as being un- protectable Percentage of des.na.ons that can be protected for all link (or node) failures. Note that some percentage of des.na.ons may be iden.fied as being un- protectable Percentage of the total poten.al failure cases (des.na.on x failures) that are protected Percentage of packets normally passing through the network that will con.nue to reach their des.na.on by using the pre- computed repair paths

42 Rou.ng challenges (1) If rou.ng func.on shall meet fundamental proper.es i) Distribu.on: local computa.on of rou.ng table entries ii) Adap.vity: to short- term topology and policy dynamics, to longer- term topology evolu.on iii) Policing: decision process, rou.ng updates filtering, etc. Then most fundamental rou.ng challenges Adapta.on cost: communica.on and processing cost #messages (rou.ng informa.on) exchanged between nodes in order for their local rou.ng func.on to properly operate by maintaining coherent and.mely non- local knowledge of topology and/or distances together with subsequent processing cost required for upda.ng the corresponding rou.ng entries Convergence.me: upon occurrence of external/internal event,.me elapsing before reaching new stable and consistent state Memory space vs rou.ng path stretch

43 Rou.ng challenges (2) Sta.c rou.ng: memory space x stretch (x computa.onal complexity) for distributed rou.ng func.on Memory space (RT Size) Adapta.on Adapta.on to dynamics of topology, policy, traffic, etc. Stretch (rou.ng path length) Dynamic rou.ng: adapta.on cost Communica.on cost (distributed rou.ng algorithm) number of rou.ng updates per topology/policy change Processing cost: store rou.ng update process (compute and possibly add/remove, or replace RT entry) distribute rou.ng update

44 Rou.ng challenges (3) 1. Scalability: memory consump.on by local RT RT size scaling be er than Ω(n log n) preferably Ω(log n) where n is the number of abstract nodes 2. Stretch: ra.o between cost/length of rou.ng path - as produced by the rou.ng scheme- and minimum cost/length path Bound stretch of rou.ng paths as produced by rou.ng scheme to small constant factor that does not grow with network size 3. Reliability: fast rou.ng state convergence upon topology/policy changes Minimize communica.on cost (#rou.ng update messages and processing) to maintain coherent and.mely non- local knowledge of network topology 4. Name- independent rou.ng: routable addresses/labels assigned independently of the topology Otherwise need to split topology- dependent locator and topology- independent iden.fier parts in address space 5. Specializa.on: take benefit of Internet topology proper.es 6. Policy: allow each network administra.ve par..on to apply its own rou.ng policy without requiring either explicit exchange of policies or mandate homogeneous policy rules for rou.ng scheme to properly operate

45 Outline Introduc.on Part I: Fundamental dimensions of rou.ng models and algorithms Shortest path rou.ng (and variants) Part II: Alterna.ves Space and tradeoffs Compact rou.ng Part III: Recent advances Geometric rou.ng on hyperbolic spaces Concluding remarks

46 Outline Shortest Path Rou.ng Intra- domain rou.ng Sta.c rou.ng = non- adap.ve rou.ng (= rou.ng paths and rou.ng table entries sta.cally configured) Dynamic rou.ng (adap.ve and distributed rou.ng) Distance vector rou.ng (Bellman Ford algorithm) Link- state rou.ng (Dijkstra algorithm) Inter- domain rou.ng Path- vector rou.ng

47 Outline Shortest Path Rou.ng Intra- domain rou.ng Sta.c rou.ng = non- adap.ve rou.ng (= rou.ng paths and rou.ng table entries sta.cally configured) Dynamic rou.ng (adap.ve and distributed rou.ng) Distance vector rou.ng (Bellman Ford algorithm) Link- state rou.ng (Dijkstra algorithm) Inter- domain rou.ng Path- vector rou.ng

48 Outline Shortest Path Rou.ng Intra- domain rou.ng Sta.c rou.ng = non- adap.ve rou.ng (= rou.ng paths and rou.ng table entries sta.cally configured) Dynamic rou.ng (adap.ve and distributed rou.ng) Distance vector rou.ng (Bellman Ford algorithm) Link- state rou.ng (Dijkstra algorithm) Inter- domain rou.ng Path- vector rou.ng

49 Internet Rou.ng Interior Gateway Protocol (IGP): Intra- domain rou.ng (within AS) Allow routers to transmit IP packets towards their des.na.on along the best path = shortest- path (metrics: #hops, link cost) IGP rou.ng protocols: distance vector (RIPv2) or link state (OSPF) All routers exchange rou.ng informa.on: each domain router can obtain rou.ng informa.on for the whole domain ebgp ebgp IGP ebgp ibgp ebgp ebgp ebgp Exterior Gateway Protocol (EGP): Inter- domain rou.ng (between AS) Rou.ng policies based on business rela3onships No common metrics and limited coopera.on Policy- based, AS_path- vector rou.ng protocol: external/internal Border Gateway Protocol (ebgp/ibgp) 49

50 Intra- domain Rou.ng Goal Allow nodes (routers) to transmit IP datagrams along the best path towards their des.na.on Best usually means the shortest path à shortest path rou.ng Shortest measured in sum of link costs Shortest measured in terms of number of hops along the path Traffic engineering Best refers to the bandwidth x delay product along the path Allow to find alternate routes in case of failures (adap.ve) Behavior All routers exchange rou.ng informa.on Each domain router can obtain rou.ng informa.on for the whole domain The network operator or the rou.ng protocol selects the cost of each link

51 Intra- domain Rou.ng Protocols Dynamic (distributed and adap.ve) rou.ng Distance vector rou.ng Rou.ng Informa.on Protocol (RIPv2 - RFC2453) Ini.al RFC 1058 (Jul.1988) using Bellman- Ford algorithm (1956) Each neighbor periodically exchanges reachability informa.on to its neighbors S.ll used in small domains despite its limita.ons Link- state rou.ng Open Shortest Path First (OSPFv2 - RFC2328) Ini.al RFC 1247 (Dec.1991) using Dijkstra algorithm (1959) Each router periodically floods immediate reachability informa.on to other routers Developed to address needs of large, scalable internetworks that RIP could not Widely used in enterprise networks and ISPs Integrated Intermediate System- Intermediate System (IS- IS - RFC 1195) or Dual IS- IS Extended version of IS- IS (RFC 1142) that supports mul.ple rou.ng protocols including IP Widely used by ISPs

52 Single source shortest- path rou.ng algorithm Unweighted single- source shortest- path algorithm BFS DFS Etc. Weighted single- source shortest path algorithm Bellman- Ford algorithm Dijkstra algorithm

53 Shortest Path Problem (and Proper.es) Given a weighted graph G = (V,E,w) and two ver.ces u and v, find a path of minimum total weight (cost) between u and v Cost of a path is the sum of the weights of its edges u v Shortest path proper.es Property 1: a subpath of a shortest path is itself a shortest path Property 2: there is a tree of shortest paths from a start vertex to all the other ver.ces Weighted single- source shortest path problem Given a weighted graph G = (V,E,w) and a source node u, compute a path of minimum total weight (or cost) between u and all other nodes v V

54 Distance Vector Rou.ng Distance Vector rou.ng (Bellman- Ford algorithm) Each router maintains a vector with an entry for every des.na.on that contains Distance = cost to reach the des.na.on from this router Direc.on = direct link that is on that least cost path Each router, periodically sends its vector to his direct neighbors containing, for each known prefix the IP address prefix the distance between itself and the des.na.on Upon receiving a vector, a router updates the local vector based on the direct link s cost and the received vector Consequently Distant Vector (DV) rou.ng algorithm does not allow a router to know the exact topology of an internetwork Routers discover the "best path" to des.na.ons based on accumulated metrics from each neighbor

55 Bellman- Ford Algorithm Define at each node u V c(u,x) = cost for direct link from node u to neighbor node x d(u,v) = es.mate of least cost path from node u to v Node u maintains Cost of direct links from node u to neighbor x: c(u,x) Distance vector: d u = [d(u,v): v є V ] For each neighbor x, its neighbors distance vectors: d x = [d(x,v): v є V ] Opera.on Each node x periodically sends d x to its neighbors Neighbors update their own distance vectors For each node v V, node u performs "distance update" d(u,v) min x {c(u,x) + d(x,v)} (minimum over all neighbors x) Over.me, the distance vector d u converges 55

56 Bellman- Ford Algorithm Define distances at each node u V d(u,v) = cost of least- cost path from u to v Update distances d(u,v) based on neighbors distance vector d(x,v) (each node only has a next- hop- view ) d(u,v) = min{c(u,x) + d(x,v)} over all neighbors x u 3 2 x y w v s z 1 t Every node sends its vector to its directly connected neighbors" Upon receiving a vector, a router updates the local vector based on the direct link s cost and the received vector " After a few iterations, the routing table converges to a consistent state d(u,v) = min{c(u,x) + d(x,v), c(u,y) + d(y,v)} = min{6,9}

57 Bellman- Ford Algorithm Itera.ve, asynchronous: each local itera.on caused by Local link cost change Distance vector update message from neighbor Distributed Each node no.fies its neighbors only when its DV changes Neighbors then no.fy their own neighbors if necessary

58 Bellman- Ford Algorithm Initialization for all neighbors x do if x adjacent to u then d(u,x) = c(u,x) else d(u,x) = Loop wait (link cost update or update message) if (c(u,x) = c(u,x) + ω) for all destinations v through x do d(u,v) = d(u,v) + ω wait for (change in local link cost or message from neighbor) else if (update d(x,v) received from x) for all destinations v do if (destination v through x) then d(u,v) = d(u,x) + d(x,v) else d(u,v) = min{d(u,v),d(u,x)+d(x,v)) if (there is a new minimum for destination v) then send d(u,v) to all neighbors forever recompute estimates if distance to any destination has changed, notify neighbors

59 Distance Vector Rou.ng: Count- to- Infinity Rou.ng loops can occur when routers propagate reverse route (= route poin.ng back to the router from which packets were received) Count- to- infinity problem: loop between three or more routers = cycle in network topology graph B A-D link failure 1 1 A tells B and C that D is unreachable A 1 1 C B tells A that D is reachable via C with cost=3 (since route is through C, split horizon doesn t apply) A tells C that D is reachable through A (cost=4) D Etc Rule of thumb: with distance vectors good news travel quickly and bad news travel slowly (resul.ng in slow convergence)

60 Distance Vector Rou.ng: Count- to- Infinity b b a 50 c a 50 c Node B Node C D C N a 6 c a 4 b D C N a 5 b a 50 a D C N a 6 c a 60 b D C N a 5 b a 50 a D C N a 6 c a 60 b D C N a 6 b a 50 a Link cost changes: b maintains shortest distance to a through c, thus d(b,a) = 4 -> d(b,a) = 6 D C N a 7 c a 60 b D C N a 6 b a 50 a bad news travels slowly time

61 Distance Vector Rou.ng: Count- to- Infinity How to avoid the count- to- infinity problem? Define infinity as max.distance (16 is osen used in distance vector rou.ng protocols) to prevent rou.ng updates from looping endlessly Avoiding (two- hop) rou.ng loops using split horizon: technique for preven.ng reverse routes between two routers Simple Split Horizon Rule: do no send back vector informa.on in the direc.on where it came Split Horizon with Poisoned Reverse Rule: do send back vector informa.on with distance set to infinity Note: Split horizon does not solve count- to- infinity problem for loops (cycle) between three or more routers

62 Distance Vector Rou.ng: Count- to- Infinity Simple Split Horizon : when sending updates out of an interface, do not send networks that were learned from an update that came in on the same interface Split horizon: if a neighboring router sends a route to a router, the receiving router will not propagate this route back to the adver.sing router on the same interface

63 Distance Vector Rou.ng: Count- to- Infinity Split Horizon with Poisoned Reverse: when sending updates out a par.cular interface, mark any networks that were learned from an update that received on that interface as unreachable (set distance metric to infinity) Message triggers immediate remove of most looping routes before they can propagate through the network The router is said to have poisoned the network by sending 'false' (infinite) metric values to other routers sharing such updates With route poisoning When a router detects that one of its connected routes has failed The router will poison the route by assigning an infinite metric to it and adver.sing it to neighbors When a router adver.ses a poisoned route to its neighbors Its neighbors break the rule of split horizon and send back to the originator the same poisoned route (poison reverse) In order to give the router enough.me to propagate the poisoned route and to ensure that no rou.ng loops occur while propaga.on occurs, the routers implement a hold- down mechanism

64 Count- to- Infinity: split horizon with poisoned reverse 4 b 1 b 60 1 If c routes through b to get to a Then c tells b its (c s) distance to a is infinite (so b won t route to a via c) a 50 c a 50 c Note: still not satisfactory when more than 2 nodes are involved Node B D C N D C N D C N D C N D C N a c a c a c a 51 c a 51 c a 4 b a 60 b a 60 b a 60 b a 60 b D C N D C N D C N D C N D C N a 5 b a 5 b a 61 b a 61 b a b a 50 a a 50 a a 50 a a 50 a a 50 a Node C Link cost changes: b updates d(b,a) = 50 as c has advertised d(c, a) = Algorithm terminates

65 Link State Rou.ng Assump.ons: each router can discover the state of the link to its neighbors and the cost of each link Basic principle: If every router knows how to reach its directly connected neighbors, one can distribute the local knowledge of each router to all other routers so that every router can construct a weighted graph. With this knowledge, a node can always determine the shortest path to any other router Topology change in Link State Update R1! Process to update this routing table R2! Process to update this routing table A N1 N2 B R1! R2! R3! Routing table Routing table Routing table Topological Database Topological Database Topological Database LSDB LSDB LSDB R3! Process to update this routing table SPF SPF SPF Each router has its own topological database on which the SPF algorithm is run SPF Tree SPF Tree SPF Tree

66 Terminology (1) Link: interface on a router Interface: connec.on between a router and one of its a ached networks (an interface is referred to as a link) An interface has state informa.on associated with it, obtained from the underlying lower level protocols and the rou.ng protocol itself State: func.onal level of an interface that determines whether or not full adjacencies are allowed to form over the interface Link state (LS): descrip.on of router interface (= link) A single IP interface address and interface mask (unless the network is an unnumbered point- to- point network) Output cost(s): cost of sending data packet on the interface, expressed in the link state metric (adver.sed as the interface link cost). The cost of an interface must be greater than zero List of neighboring routers: other routers a ached through this link Flooding: mechanism used to reliably distribute local topology descrip.on so as keep routers Link State Database (LSDB) up to date

67 Terminology (2) Link State PDU Unit of data describing the local state of router's interfaces and adjacencies Each LS PDU is flooded throughout the rou.ng domain The collected LS adver.sements of all routers and networks forms the LSDB Link State Database (LSDB) Logically separated LSDB for each area the router is connected to Two routers interfacing the same area must have, for that area, iden.cal LSDBs LSDB collec.on of all LS PDUs (re- )originated from the area's routers Each router adver.ses directly connected networks via LS PDU Every router has it s own view of the network it builds a topologic database / /24 R1! R2! /24 Metric = 1 Metric = 1 Metric = 1 Metric = 1 R3! R4! /24 Metric = 1 Router! Destination! Next Hop! Cost! R1" /24" R2" 1" R1" /24" R3" 1" R1" /24" R2" 2" R1" /24" R2" 2" R2" /24" R1" 1" R2" /24" R3" 1" R2" /24" R4" 1" Router 1 is aware of 2 paths to /24 this provides redundancy should one of the routers fail

68 Terminology (3) Shortest Path computa.on: performed on the link state database in order to produce a router's rou.ng table Each router has an iden.cal LSDB, leading to an iden.cal representa.on of the network topology graph Each router generates its rou.ng table from this graph by compu.ng a tree of shortest paths with the local router as root of this tree Shortest Path Tree (SPT) Derived from the collected LS PDUs using the Dijkstra algorithm Shortest- path tree with local router as root, gives the shortest path to any IP dest. network or host (only the next hop to the des.na.on is used in the forwarding process) Rou.ng table Derived from the Shortest Path Tree Each entry of this table is indexed by a des.na.on, and contains the des.na.on's cost and a set of paths (described by its type and next hop) to use in forwarding packets to the des.na.on

69 Link State Protocol and SPT Algorithm R2! Link State PDU A N1 N2 B R1! R2! R3! R1! R4! Routing table Routing table Routing table Topological Database R3! Routing table Route Topological Database Topological Database Topological Database LSDB LSDB LSDB Dijsktra Dijkstra Dijkstra LSDB Dijkstra Algorithm SP Tree SP Tree SP Tree SP Tree Link-state protocol principle! Flood reliably routing information to all routers of the same routing domain " Each router knows the topology of the entire routing domain" Converge more quickly than distance vector protocols (link-state protocols are less prone to routing loops)

70 Link State Concept (1) Link-state PDUs (LS PDUs): PDU carrying routing information exchanged between routers " Topological database: collection of information gathered from LS PDUs " Shortest Path First (SPF) algorithm: performed on the database resulting in the SPF tree " Routing tables: A repository of the known paths and interfaces " 2. Building a topological DB Topological Database Entries 1. Flooding of link-state information R1! LSDB R2! R3! Link State PDU R4! 3. Dijkstra Algorithm 4. SP Tree 5. Routing Table Routing Table Route Routers send LS PDUs to their adjacent neighbors" LS PDUs are used to build a topological database" SPF algorithm computes the shortest path first tree in which the root is the individual router and then a routing table is created" Resulting routing entries populates the routing table"

71 Link State Concept (2) 1. Flooding of linkstate information 2. Building a topological DB Topological Database Entries R1! R2! Link State PDU R4! R3! 4. SP Tree 3. Dijkstra LSDB Algorithm 5. Routing Table Routing Table Route 1. Flooding of link- state informa.on Each node, router, on the network announces to other all other routers on the network its own piece of link- state informa.on (including who their neighboring routers are and the cost of the link between them) Example: Hi, I m Router1, and I can reach Router2 via a T1 link and I can reach Router3 via an Ethernet link. Each router sends these announcements to all of the routers in the network

72 Link State Concept (3) 1. Flooding of linkstate information 2. Building a topological DB Topological Database Entries R1! R2! Link State PDU R4! R3! 4. SP Tree 3. Dijkstra LSDB Algorithm 5. Routing Table Routing Table Route 2. Building a Topological Database (Link- State Database) Each router collects link- state informa.on from other routers into LSDB 3. Dijkstra Algorithm Using this informa.on, routers can recreate a network topology graph Path- selec.on model (to des.na.on prefix): minimum hop count or sum of link costs

73 Link State Concept (4) 1. Flooding of linkstate information 2. Building a topological DB Topological Database Entries R1! R2! Link State PDU R4! R3! 4. SP Tree 3. Dijkstra LSDB Algorithm 5. Routing Table Routing Table Route 4. Shortest Path Tree The SPF algorithm computes the SP tree, with the local router as the root of the tree and the other routers and links to other routers as the various branches of the tree 5. Rou.ng Table Using this informa.on, the router creates a rou.ng table populated by rou.ng entries

74 Link State Adver.sement Processing LSA! LSU! Is entry in LSDB?! Yes! Is seq. # the same?! Yes! Ignore LSA! No! No! A! Add to database! Send LS Ack! Is seq. #! higher?! No! Yes! Go! to A! Flood LSA! Run SPF to calculate! new routing table! Send LSU with newer! information to! source! End! End!

75 Shortest- Path Problem Given: network topology with link costs c(x,y) link cost from node x to node y c(x,y) set to infinity if x and y are not direct neighbors Compute: from a given source node (u) the least- cost path to all other nodes v V p(i): predecessor node along path from source to i A 3 2 F B E 5 4 C G 1 D I/f 1 A I/f F B E 5 4 C G 1 D 4 H 3 4 H 3 Shortest-path tree from u"

76 Shortest Path Tree: Example Shortest path tree (SPT) from node u v 2 y Rou.ng table at u Destination! Next-hop! Cost! u I/f 1 I/f x 4 1 z v" v" 3" w" w" 2" x" w" 3" y" v" 5" w 4 5 s 3 t z" v" 6" s" w" 6" t" w" 8" Forwarding table at u Destination! Interface! Next-hop! v" 1" v" w" 2" w" x" 2" w" y" 1" v" z" 1" v" s" 2" w" t" 2" w"

77 Dijkstra Algorithm The distance of a vertex v from a vertex u is the length of a shortest path between u and v The Dijkstra algorithm computes the distances of all the ver.ces from a given start vertex s Assump.ons the graph is connected the edges are undirected the edge weights are nonnega.ve Grow a set of ver.ces S (set of visited nodes) beginning with s (eventually covering all the ver.ces) Store with each vertex v a label d(v) represen.ng the distance of v from s in the subgraph consis.ng of S and its adjacent ver.ces At each step Add to S the vertex v not in S (i.e., in V \ S) with the smallest distance label d(v) Update the labels of the ver.ces adjacent to v

78 Edge Relaxa.on Principle Consider an edge (u,v) such that u is the vertex most recently added to S = {s,u,w} v not in S (v in V \ S) s d(u) = 50 u 10 d(v) = 75 v w The relaxa.on of edge (u,v) updates distance d(v) as follows: d(v) min{d(v),d(u) + c(u,v))} s d(u) = 50 u 10 d(v) = 60 v w

79 Dijsktra Algorithm (itera.ve algorithm) Notation! c(u,v): weight of the edge from node u to v (a.k.a. link cost)" " c(u,v) = infinity if u and v not direct neighbors" d(v): current value of cost of path from source to destination node v (label)" S: set of nodes whose least cost path are definitively known"! Initialization S = {s} " " "/* s is the source node labeled with distance 0" for all nodes v if v adjacent to node u then d(v) = c(u,v) "/* d(v) is the distance label for node v " else d(v) = " " "/* Put all nodes into priority queue Q, using the distances as labels repeat find node u not in S such that d(u) is a minimum add node u to S for all node v adjacent to node u and not in S " d(v) min(d(v),d(u)+c(u,v)) /* change key of v in Q to d(v)" until all nodes are in S! Note use of priority queue allows finished nodes to be found quickly (in O(log N) time)

80 Correctness (via contradic.on) Prove d(u) represents the shortest path to u (visited node) Assume u is the first vertex visited such that d(u) is not a shortest path (thus the true shortest path to u must pass through some unvisited vertex) Let x represent the first unvisited vertex on true shortest path to u Set S s x Unvisited set V \ S u d(x) must represent a shortest path to x and d(x) d shortest (u) However, Dijkstra algorithm always visits the vertex with the smallest distance next, so we can t possibly visit u before we visit x

81 Time Complexity of Dijkstra Algorithm Weighted Graph G=(V,E) Vertex set, V = n Edge set, E = m Adjacency matrix version Dijkstra finds shortest path from one vertex to all others in O( V 2 ).me If E is small compared to V 2, use a priority queue to organize the ver.ces in V \ S, where V is the set of all ver.ces and S is the set that has already been explored So total of E updates each at a cost of O(log V ) So total.me is O( E log V )

82 Distance Vector vs. Link State Distance vector Time complexity: O(m. n) m: number of links n: number of nodes Message complexity: O(d. n. k) d: node degree n: number of nodes k: number of rounds Convergence.me : O(k) k: number of rounds Link state Time complexity: O(m log(n)) m: number of links n: number of nodes Message complexity: O(m. n 2 ) m: number of links n: number of nodes Convergence.me : O(1)

83 Shortest Path Rou.ng Intra- domain rou.ng Sta.c rou.ng Outline Distributed and Adap.ve rou.ng Distance vector rou.ng (Bellman Ford algorithm) Link- state rou.ng (Dijkstra algorithm) Inter- domain rou.ng Path- vector rou.ng

84 Preliminaries: BGP Border Gateway Protocol (BGP) version 4 [RFC 4271] is an inter- domain rou.ng protocol Exchanges rou.ng informa.on between AS while guaranteeing loop- free path selec.on BGP protocol is similar to Distance Vector, but called Path Vector instead BGP router adver.ses in its vector only reachability informa.on and associated path amributes to each des.na.on (so, avoids loops), no costs or hop counts Unlike IGPs (such as RIPv2, and OSPFv2), BGP does not use metrics like hop count, link cost, or delay Instead, BGP performs its rou.ng decisions (best path selec.on) based on network policies and route selec.on rules applied in sequence to various path a ributes Supports classless inter- domain rou.ng (CIDR) and route aggrega.on THE inter- domain rou.ng protocol of the Internet 84

85 Preliminaries BGP router comprises 3 logical rou.ng informa.on bases Adj- RIBs- In: stores rou.ng informa.on learned through updates from all the peers Loc- RIB: local rou.ng data obtained aser the BGP selec.on process (protocol informa.on) used to populate the node rou.ng table Adj- RIBs- Out: contains routes that are adver.sed to peers Routing engine peer 1 peer j peer W BGP module Adj-RIB-In Route selection (rules) Loc-RIB Best routes Adj-RIB-Out peer x peer y Node Routing Table

86 Preliminaries Network topology: graph G = (V,E) Set V, V = n, each vertex represents the AS Set E, E = m, each edge represents rela.onships between AS pairs Route r i to dest. d at.me t: r i (t) {d,(v k = u, v k-1 = w,, v 0 = v), A} where, i [1,N], k > 0 j, k j > 0, {v j, v j 1 } E AS- path: (v k = u, v k-1 = w,, v 0 = v) where, v k- 1 = w ( neighbor of u) A : route a ribute set Path- vector route selec.on process P (u,v),d : set of paths p(u,v) to des.na.on d D where, each path p(u,v) {(v k = u, v k-1 = w,, v 0 = v), A} u V, select route r i per des.na.on d within P (u,v),d set and store in the local RIB whose size RT(u) = N Once selected, rou.ng update(s) may lead to AS- path (v k, v k-1,, v 0 ) change and/or change of other a ributes set A

87 Inter- domain rou.ng protocol limita.ons 1. BGP Implementa.on and configura.on: may be circumvented 2. BGP Rou.ng algorithm: shortest AS- path vector rou.ng Avoids AS- loops, eliminates distance- vector count- to- infinity BGP as any path- vector rou.ng experiences slow convergence due to uninformed path explora.on 3. BGP Protocol usage: policy- based rou.ng (without policy distribu.on) Intra- AS oscilla.ons: MED- induced oscilla.ons Inter- AS oscilla.ons: local preference over shortest AS- Path Conflic.ng policy interac.ons Unintended stable state (wedgies) Unintended unstable state (dispute wheels)

88 Inter- domain rou.ng protocol limita.ons 1. Implementa.on and configura.on: may be circumvented 2. Architecture: shortest AS- path vector rou.ng (avoids AS- loops, eliminates DV count- to- infinity) BUT subject to Path Explora.on: BGP slow convergence due to uninformed path explora.on Theory: upper bound ~ O(N!) and lower bound = Ω[(N- 3) x MRAI.mer] on state explored during BGP convergence (N = number of AS) Prac.ce: (Max_AS- Path - Min_AS- Path) x MRAI.mer 3. Protocol usage: Policy- based rou.ng (no policy distribu.on) Intra- AS oscilla.ons: MED- induced oscilla.ons Inter- AS oscilla.ons: local preference over shortest AS- Path Conflic.ng policy interac.ons Unintended stable state (wedgies) Unintended unstable state (dispute wheels)

89 BGP Rou.ng Scheme (1) 2. BGP slow convergence due to uninformed path explora.on Theore.cal: Upper bound ~ O(n!) - Lower bound = Ω[(n- 3) x MRAI] where n is number of AS, and MRAI is Minimum Route Adver.sement Interval Prac.ce: (Max_AS- Path - Min_AS- Path) x MRAI 4 3 A D 2 A:[3,2,D] A 4 3 W D 2 W:[3,2,D] W 4 3 D 2 A:[2,D] A W:[2,D] A: [4,3,2,D] W A:[1,2,D] 1 RT:[2,D] A:[1,3,2,D] 1 RT:[3,2,D] A:[1,4,3,2,D] 1 RT:[4,3,2,D] D D D 4 3 A 2 4 A 3 W 2 4 W 3 2 A:[2,D] A W:[2,D] A W A:[1,2,D] 1 RT:[2,D] A:[1,3,2,D] RT:[3,2,D] A:[1,4,3,2,D] 1 RT:[4,3,2,D] 5

90 Rela.onship to AS topology Meshed AS topology (average AS degree ~ 2.5-3) with high clustering coefficient (~ 0.4) BGP uninformed path explora.on BGP listens without understanding (local BGP route selec.on) BGP rou.ng updates are not coordinated in space and.me but rate limited (MRAI.mer) - > state coupling between topologically correlated BGP updates Cycle -> Exploration Cycle -> Exploration Cycle -> Exploration

91 BGP Rou.ng Scheme (2) Mi.ga.on (some examples) Path explora.on mi.ga.on [Chandrashekar05] Add forward edge sequence number to annotate AS paths with addi.onal path dependency informa.on (enhanced path vector algorithm) Reduces convergence.me in fail- down scenario but modest improvement in fail- over scenario Main drawbacks: large amount of extra informa.on stored at nodes and increase of messages size BGP with Root Cause No.fica.on (BGP- RCN) with failure loca.on [Pei05] Reduces convergence.me in fail- down scenario but modest improvement in fail- over scenario (on Internet topology compared to BGP) Shorten MRAI to fasten convergence [Griffin01] Decreasing MRAI below a certain threshold leads to adversary effects on convergence.me and number of BGP updates (coupling of rou.ng states induced by correlated BGP updates exacerbates path explora.on) Backup/Mul. AS- path Label adver.sed AS- Path (between BGP peers) to increase AS- Path diversity Main drawbacks: mul.plies number of rou.ng states

92 BGP Protocol Usage (1) 3. Conflic.ng policy interac.ons i) unintended stable state (wedgies) primary (pref.) 1 D backup (not pref.) 1 D 2 3 Configuration phase: traffic primary incoming interface at D is 1 traffic backup incoming interface at D is Failure occurrence at link (1,D): traffic incoming interface at D is 3 D 3 D 3 Failure recovery of link (1,D): traffic incoming interface at D is 3 AND 1

93 BGP Protocol Usage (3) 3. Conflic.ng policy interac.ons ii) unintended unstable state (dispute wheels) 1 [1,3,D] [1,D] 1 [1,3,D] [1,D] 1 [1,3,D] [1,D] [1,3,D] [3,2,D] [1,D] D D D 2 3 [2,D] [2,1,D] [2,D] [3,2,D] [3,D] 2 3 [2,1,D] [2,D] [3,2,D] [3,D] 2 3 [2,1,D] [2,D] [3,2,D] [3,D] 1 [1,3,D] [1,D] 1 [1,3,D] [1,D] 1 [1,3,D] [1,D] [3,D] [1,3,D] D D D 2 3 [2,1,D] [2,1,D] [2,D] [3,2,D] [3,D] 2 3 [2,1,D] [2,D] [3,2,D] [3,D] 2 3 [2,1,D] [2,D] [3,2,D] [3,D]

94 Impact on Rou.ng System (1) Over.me, techniques have permi ed to limit degrada.on of the Internet rou.ng system. Nevertheless, none of them Improve scaling proper.es of the Internet rou.ng system Eliminate the protocol limita.ons impac.ng rou.ng system stability and convergence Addi.onally Par.al adop.on/development by the system engineers of ad- hoc improvements Par.al deployment by network engineers - > increase the complexity of opera.on and maintenance In any case, many BGP improvements represent only short- term fixes addressing the symptoms instead of the root causes

95 Impact on Rou.ng System (2) Current trend in BGP rou.ng system: short- term incremental fixes to a enuate symptoms instead of addressing root causes This approach works un.l Network engineering can absorb execu.ons problems Opera.onal workarounds to resolve policy, monitoring, etc. System engineering can absorb protocol deficiencies Engineering workarounds bound Δ(#routing states) x Δ(routing state size) x Δ(update rate) Δ(cost) x Δ(complexity) Example: RT size growth rate (~25% year) impacts BGP convergence.me BGP convergence.me: limited by access speeds of DRAM (RT storage) DRAM capacity growth rate: ~4x every 3.3 years DRAM access speed growth rate: ~1.2x every 2 years BGP convergence.me degrada.on rate (es.ma.on): RT growth rate [1.25]_ ~ 10% per year DRAM Access speed growth rate [1.1]

96 Shortest- Path Rou.ng Protocols: Comparison Link State Distance Vector Path Vector Dissemina.on Flood reliably topology informa.on (link state PDU) to all routers within the rou.ng domain Update distances from neighbors distances Update paths based on neighbors paths Each router knows li le about network topology Algorithm Dijsktra s shortest path Best end- to- end paths are computed locally at each router (determine next hop) Bellman- Ford shortest path Best end- to- end paths result from composi.on of all next- hop choices Local policy to rank paths Route update include the en.re AS path informa.on to prevent count- to- infinity Condi.on Works only if policy is shared and uniform No.on of distance and direc.on Does not require any no.on of distance Does not require uniform policies at all routers Convergence Fast due to flooding Responds rapidly to topology changes Slow convergence (bouncing effect, count- to- infinity) Slow convergence due to path explora.on (path hun.ng) Protocols OSPFv2 (RFC 2328) IS- IS (RFC 1195) RIPv1 (RFC 1058) RIPv2 (RFC 2453) BGPv4 [RFC4271]

97 Outline Introduc.on Part I: Fundamental dimensions of rou.ng models and algorithms Limits of shortest path rou.ng (and variants) Part II: Alterna.ves Space and tradeoffs Compact rou.ng Part III: Recent advances Geometric rou.ng on hyperbolic spaces Concluding remarks

98 Space of Rou.ng Scheme Alterna.ves Compact Rou.ng Name dependent schemes: e.g. TZ scheme, BC scheme, etc. Name independent schemes: e.g. Abraham scheme! As of today computa.on based on "full- view" of the topology and no support of Internet topology dynamics - > Dynamic (and distributed) compact rou.ng Hybrid rou.ng protocols Combina.on of LS/PV: Hybrid Link- state Path- vector (HLP) Combina.on of LS/DV: LVA Geometric Rou.ng Hyperbolic space (plane): Embedding: Internet topology graph embedded into hyperbolic plane (requires full view of the topology) Mapping: graph constructed from hidden hyperbolic space yielding to scale- free topologies Observable topology (with transforma.on) Euclidean space Others Overlay rou.ng and variants: host- based: SHIM6, Host Iden.ty Protocol (HIP) router- based: Loc/ID split protocol (LISP), GSE 8+8, etc. Hierarchical rou.ng: on scale- free network topology, hierarchical, aggrega.on- based rou.ng is inefficient Stochas.c Rou.ng

99 Space of Rou.ng Scheme Alterna.ves Compact Rou.ng Name dependent schemes: e.g. TZ scheme, BC scheme, etc. Name independent schemes: e.g. Abraham scheme! As of today computa.on based on "full- view" of the topology and no support of Internet topology dynamics - > Dynamic (and distributed) compact rou.ng Hybrid rou.ng protocols Combina.on of LS/PV: Hybrid Link- state Path- vector (HLP) Combina.on of LS/DV: LVA Geometric Rou.ng Hyperbolic space (plane): Embedding: Internet topology graph embedded into hyperbolic plane (requires full view of the topology) Mapping: graph constructed from hidden hyperbolic space yielding to scale- free topologies Observable topology (with transforma.on) Euclidean space Others Overlay rou.ng and variants: host- based: SHIM6, Host Iden.ty Protocol (HIP) router- based: Loc/ID split protocol (LISP), GSE 8+8, etc. Hierarchical rou.ng: on scale- free network topology, hierarchical, aggrega.on- based rou.ng is inefficient Stochas.c Rou.ng

100 Network layer vs Overlay rou.ng 1. Either focus on technological limits (scalability, resiliency, stability, convergence, etc.) and opera.onal limits (policing) of exis.ng network rou.ng 2. Or build an infrastructure- based overlay on top of exis.ng IP network layer Addi.onal layer of indirec.on 2. Infrastructure-based overlay 1. Revisit network routing functions d In A C D B Out In a d c Edge b Out a c b

101 Network layer vs Overlay rou.ng Addi.onal layer of indirec.on adds benefits such as customiza.on, independence, and flexibility... but also detrimental effects Conflic.ng cross- layer interac.ons that impact overall network performance (amplified by selfish rou.ng where individual user/ overlay controls rou.ng of infinitesimal amount of traffic to op.mize its own performance without considering network- wide criteria) Scalability (rate x state) Resiliency (user states) and security (interac.on with user states) Genericity and evolvability Note: the looser the coupling the higher the flexibility, the stronger the coupling the higher the performance (pick one)!

102 Effects of indirec.ons Any problem in computer science can be solved with another layer of indirec.on. David Wheeler But that usually will create another problem. rest of the quote Indirec.on = (generic) infrastructure- based overlay rou.ng Overlay Traffic NOP Overlay control info Overlay fwd info Overlay control Multiple control mechanisms conflicting cross-layer interactions (due to diff. performance objectives & contention) Decapsulation Encapsulation Open i/f Open i/f RIB Routing engine FIB Packet in TC Lookup Packet out MF classifier Longest matching prefix

103 Locator/Iden.fier (Loc/ID) Separa.on (1) Mo.va.on: restore aggrega.bility of rou.ng states by "segmen.ng" the address space (hosts vs networks) and their respec.ve alloca.on policy Loc/ID split using different numbering spaces for end- point iden.fiers (EID) block alloca.on per organiza.on and Locators (RLOC) that are topology congruent and aggregatable Principles Segmenta.on between topology independent endpoint iden.fier (= user address space) and topology dependent locator (= network address space) Resolu.on via distributed database (= mapping database) including info necessary to translate hosts topology independent addresses (iden.fiers) to topology dependent addresses (locators) Traffic- driven at ingress "edge": forwarding entries preceded by ID- to- RLOC mapping entries (encapsula.on) populated per incoming traffic arrival Memory- less at egress "edge": do not keep track of source of ID- to- RLOC mapping requests (in case of mapping change, ini.al requestor not directly updated)

104 Locator/Iden.fier (Loc/ID) Separa.on (2) Host A (EID A) - > Host B (EID B) Host A Host B APP APP TCP Edge A Edge B TCP Network EID A Network Network EID B Network EID- to- RLOC lookup Map Request <?, EID B> Map Reply <RLOC B, EID B> EID- to- RLOC lookup Network LOC A Network LOC B Network Edge router (ITR): A - > B RLOC lookup Edge router (ETR): A - > B Edge router (ETR): B - > A Edge router (ITR): B - > A

105 Locator/Iden.fier (Loc/ID) Separa.on (3) Main challenges Responsiveness: to spa.o- temporal proper.es of incoming traffic (and varia.ons) Differen.al delay and/or drop of ini.al incoming packets - > effect on transport layer (e.g. conges.on and flow control) Port scanning (EID- to- RLOC cache updates) Churn: effect of changes for "in- use" EID- to- RLOC mappings Changes in EID reachability (at egress) - > effect on established flows Asymmetric traffic (dual edges) De- aggrega.on: EID block segmenta.on EID sub- blocks decomposi.on and alloca.on to mul.ple RLOCs (forwarding s.ll longest- match prefix based)

106 ...More fundamentally Locator ID Separa.on Protocol (LISP) is a form of name- independent rou.ng using topology- unaware flat addressing running on top of name- dependent rou.ng scheme In addi.on, to maintain and update EID- to- RLOC tables, the network maintains and updates a distributed database of EID- to- RLOC mappings ( indirec.on layer) Average scaling characteris.cs of name- independent rou.ng schemes cannot be be er than name- dependent ones Reason: name independent schemes are essen.ally name dependent schemes plus mapping tables and ID- to- RLOC name- resolu.on mechanism, which incur to both rou.ng table size increase and stretch Bo om- line: LISP can thus not directly result into a global rou.ng scalability improvement

107 Scaling Dependency on Topology (1) Internet topology not a tree or a grid but ~ scale- free graph Small diameter grows propor.onally to log(n) Average shortest- path length ~4 (AS- hops) Note: dis.nc.on between actual rou.ng path (as produced by BGP due policy prac.ces) and topological shortest path High clustering coefficient Proper.es of scale- free networks do not allow for efficient address aggrega.on like trees Scaling dependency on topology proper.es Effec.veness of hierarchical network par..oning and aggrega.on depends on either of profusion of nodes at long hop- distances from each other or on strong regularity of tree structure but none are present in scale- free graphs

108 Characteris.c Path Length Defini.on: characteris.c path length L (of a graph G=(V,E): average of path length d(u,v) over all pairs of ver.ces u, v V L = 1 n( n 1) u, v u v V d( u, v) Path length or distance d(u,v): number of edges of the shortest path between ver.ces i and j u d(i,j) = 2 v

109 Distance (1) Defini.on: distance distribu.on d(x) is the probability that a random pair of nodes u,v are at distance x of each other : P[d(u,v)]=x Divided by the total number of pairs n 2 (self- pairs included) Associated sta.s.cs with distance distribu.on of a graph Average distance d m Standard devia.on σ (a.k.a distance distribu.on width since distance distribu.ons in Internet graphs have a characteris.c Gaussian- like shape) Interpreta.on Distance distribu.on is important for rou.ng Distance- based locality- sensi.ve approach as root of most modern rou.ng algorithms: performance of rou.ng algorithms depend mostly on the distance distribu.on Short average distance and narrow distance distribu.on width break the efficiency of tradi.onal hierarchical rou.ng: root causes of inter- domain rou.ng scalability issues in the Internet Expansion metric: renormalized version of distance distribu.on d(x) Cri.cal metric for topology comparison analysis

110 Distance (2) Distance distribu.on (shortest path length) Performance parameters of rou.ng algorithms depend solely on distance distribu.on Internet: 86% of AS pairs are at distance 3 to 4 AS hops Average AS_Path Length PDF Source: Potaroo.net

111 Clustering (1) Quan.fies how close node s neighbors are to forming a clique (complete graph i.e. every pair of dis.nct ver.ces is connected by an edge) Defini.on: Local clustering coefficient c(i) of vertex i of degree k i (has k i neighbors) 1 ki 2 E( Γ( i)) c( i) = E( Γ( i)) = 2 ki( ki 1) where E Γ(i) is the number of edges in neighborhood of vertex i k i (degree of vertex i): the number of edges incident to the vertex i k i (k i - 1)/2 is the maximum possible number of edges between neighbors of vertex i (max. possible number of edges that could exist among the ver.ces within the neighbourhood of vertex i) 111

112 Clustering (2) If two neighbors of a node are connected, then these three nodes together form a triangle (3- cycle) Local clustering measure of average number of 3- cycles c=0 c=1 c=1/3 112

113 Clustering (3) Defini.on: clustering coefficient of graph G=(V,E) is the average of the local clustering coefficients of all the ver.ces V = n i= 1 Clustering coefficient : measure of the percentage of 3- cycles among all connected node triplets in the graph Interpreta.on Clustering is a measure of local robustness in the graph Implica.ons C = C 1 n n c( i) The higher the local clustering of a node, the more interconnected are its neighbors, thus increasing path diversity locally around the node Networks with strong clustering are likely to be chordal or of low chordality, 4 which makes certain rou.ng strategies perform be er Clustering used as litmus test for verifying the accuracy of a topology model or generator 113

114 Clustering (4) A graph is considered small- world if its clustering coefficient C is significantly higher than a random graph constructed on the same vertex set if the graph has approximately the same mean- shortest path length as its corresponding random graph Regular graph high clustering large diameter Small- world graph high clustering small diameter Random graph small clustering small diameter N = 1000 k =10 D = 100 L = C = 0.67 N =1000 k = 8-13 D = 14 L = 11.1 C = 0.63 N = 1000 (k =5-18) D = 5 L = 4.46 C =

115 Clustering (5) regular SW random C(p) = clustering coeff. L(p) = characteris.c path length L C p 115

116 Scaling Dependency on Topology (2) Consequence 1: efficient applica.on of hierarchical, aggrega.on- based rou.ng to Internet- like topologies is hopeless: logical hierarchies/tree- based structure tend to augment "distance" in power- law networks Distance: hierarchical rou.ng sa.sfactory for topologies where average distance d between nodes increases polynomially with network size n: d(n) ~ n α, α > 0 > < Internet average distance d growths at most logarithmically with network size (n): d(n) ~ log(n) Path length increase: criteria Routing path length (n) cte Hierarchical rou.ng: Topology rou.ng path distance length (n) increase >> topology distance increase; hence, ra.o

117 Scaling Dependency on Topology (3) Consequence 2: rou.ng protocols relying (explicitly or implicitly) on aggrega.on of topology- dependent locators (name- dependent rou.ng) can not improve RT size scaling on Internet topology (example Loc/ID split) because Such aggrega.on is impossible on scale- free topologies Even when aggressive aggrega.on is not used, scaling can not be improved Reason: in addi.on to maintaining and upda.ng RTs of topology- dependent locators, a distributed dic.onary of iden.fier- to- locator mappings (for iden.fier to- locator name- resolu.on) must also be maintained and updated

118 Outline Introduc.on Part I: Fundamental dimensions of rou.ng models and algorithms Limits of shortest path rou.ng (and variants) Part II: Alterna.ves Space and tradeoffs Compact rou.ng Part III: Recent advances Geometric rou.ng on hyperbolic spaces Concluding remarks

119 Space of Rou.ng Scheme Alterna.ves Compact Rou.ng Name dependent schemes: e.g. TZ scheme, BC scheme, etc. Name independent schemes: e.g. Abraham scheme! As of today computa.on based on "full- view" of the topology and no support of Internet topology dynamics - > Dynamic (and distributed) compact rou.ng Hybrid rou.ng protocols Combina.on of LS/PV: Hybrid Link- state Path- vector (HLP) Combina.on of LS/DV: LVA Geometric Rou.ng Hyperbolic space (plane): Embedding: Internet topology graph embedded into hyperbolic plane (requires full view of the topology) Mapping: graph constructed from hidden hyperbolic space yielding to scale- free topologies Observable topology (with transforma.on) Euclidean space Others Overlay rou.ng and variants: host- based: SHIM6, Host Iden.ty Protocol (HIP) router- based: Loc/ID split protocol (LISP), GSE 8+8, etc. Hierarchical rou.ng: on scale- free network topology, hierarchical, aggrega.on- based rou.ng is inefficient Stochas.c Rou.ng

120 Compact Rou.ng: Problem Two base / solu.ons to the rou.ng problem 1. Store a complete rou.ng table at each node of the network RT entries for any des.na.on next- hop/link to which packets for that des.na.on should be forwarded (shortest path) Drawback: requires each node to store Ω(n log(n)) bits of rou.ng informa.on 2. Source- explicit/source- directed rou.ng Source inserts for each packet carries in its header a complete descrip.on of the path along which it should be routed Drawback: packet headers may need to be of size (n) and s.ll processed at wire speed In either case, scaling problems: rou.ng schemes that require nodes to store a linear number of bits are not scalable

121 Compact Rou.ng: Problem To reduce memory space and incur rou.ng path lengths/costs propor.onal to actual distances, two parameters that rou.ng schemes aim at minimizing: stretch and memory Stretch: ra.o between rou.ng path length/cost and minimum cost/length path Memory: number of bits of rou.ng informa.on stored locally for the rou.ng scheme

122 Compact Rou.ng: Principle and Defini.on Principle: given coherent full view of the network topology build in polynomial.me rou.ng algorithm that balances efficiently fundamental (and unavoidable) trade- off between stretch of rou.ng path it produces and size of rou.ng table it produces Defini.on: A rou.ng scheme is said to be compact if Stretch bound by constant: does not grow with the network size growth Rou.ng table size (local memory space in terms of number of bits) scales sub- linearly: at most of the order of n bits of rou.ng informa.on stored per RT (per node) Logarithmic address and header sizes: node names/labels and header sizes scales (poly- )logarithmically Compact rou.ng algorithms make rou.ng table sizes compact by omi ng some network topology details such that resul.ng path length increase stays small (bounded)

123 Compact Rou.ng Scheme "Principle" Within local neighborhood B (vicinity ball): store (and use) shortest path rou.ng informa.on Outside local neighborhood B (vicinity ball): Store rou.ng informa.on to all landmarks Route through a des.na.on s closest landmark, and then use tree- rou.ng from landmark to des.na.on Routing algorithm: If v B(u) hen route u v (shortest path) else u l v v (landmark) Stretch bound follows from the triangle inequality: v Suppose d(l v,v) d(u,v) Then d(l v,v) + d(u,l v ) d(u,v) + d(u,l v ) and d(u,l v ) d(u,v) + d(v,l v ) 2 d(u,v) u Then d(u,l v ) + d(l v,v) d(u,v) + d(u,v) + d(v,l v ) 3 d(u,v) l v

124 Compact Rou.ng Scheme "Principle" Rou.ng table: shortest paths to nodes in vicinity ball and all landmarks RT includes original node ID, its closest landmark ID, the ID of the closest landmark s port lying on the shortest path from the landmark to the node B(u) B(w) Label(v): λ v = (v,l v,port(l v,v)) l v u w v u v Rou.ng from u to v (at w) If v belongs to local cluster of node u (v B L (u)) Then route directly using shortest path to v ( node w on the shortest path from u v, v B L (w)) If v does not belong to local cluster of node u (v B L (u)) Then route indirectly via landmark of node v (shortest path from u to l v, and then a shortest path from l v to v)

125 Compact Rou.ng: Main Steps L.Cowen: Compact routing with minimum stretch 1) Non- hierarchical scheme (no network partitioning required) 2) Fixed stretch of 3 for any topology of any size (universal) 3) Sublinear RT size upper bound of Õ(n 2/3 ) M.Thorup and U.Zwick: Compact routing schemes 1) Improves Cowen s RT size (memory space) upper bound to Õ(n 1/2 ) 2) Fixed stretch of 3 (nearly optimal) 3) Equal memory space upper and lower bounds (up to a polylog factor) Cowen, 1999 Thorup & Zwick, 2001 Main limitation of name- dependent scheme: when routing on topology- dependent labels, topology change implies label change (nodes needs to be relabeled) Name- independent scheme (routing on topology independent names) M.Arias, L.Cowen, K.A.Laing, R.Rajaraman, and O.Taka: Compact routing with name independence 1) Name- independent compact routing scheme 2) Memory space upper bound of Õ(n 1/2 ) 3) Fixed stretch of 5 I.Abraham, C.Gavoille, D.Malkhi, N.Nisan, and M.Thorup: Compact name- independent routing with minimum stretch 1) First generic nearly optimal name- independent compact routing scheme 2) Memory space upper bound of Õ(n 1/2 ) 3) Fixed stretch of 3 Arias, 2003 Abraham, 2004

126 Compact name- independent rou.ng with minimum stretch First op.mal compact name- independent rou.ng scheme for arbitrary undirected graphs Proper.es Stretch at most 3 O(log 2 n/log log n)- bit packet headers Õ(n 1/2 )- bits of memory required to store rou.ng informa.on per node Time complexity Õ(m.n) to construct rou.ng table informa.on When rou.ng along our stretch 3 paths, each rou.ng decision is performed in constant.me Important result: with Õ(n 1/2 )- bits of memory, node labeling does not improve the stretch factor

127 Compact name- independent rou.ng with minimum stretch Also referred to as "Abraham scheme" or AGMNT Main references I.Abraham, C.Gavoille, D.Malkhi, N.Nisan, and M.Thorup. Compact name- independent rou3ng with minimum stretch. ACM SPAA, 2004 I.Abraham, C.Gavoille, D.Malkhi, N.Nisan, and M.Thorup. Compact name- independent rou3ng with minimum stretch. ACM TALG, 2008 Steps and mechanisms toward stretch 3 scheme Vicinity balls Coloring Hashing names to colors Labeled rou.ng on trees Landmarks Par.al shortest path trees

128 Abraham Scheme (AGMNT): Rou.ng informa.on Every node u stores 1a: [Vicinity] For every node v B(u): name v, port name (u w), w being next hop along a minimum cost path (MCP) from u to v using label λ(t(v),u) 1b: [Landmarks] For every landmark l L: tree rou.ng informa.on µ(t(l),u) of the tree T(l) and label λ(t(l),l) of the tree T(l) rooted at l 1c: [Par.al Shortest Path Trees] For every node v B(u): tree rou.ng informa.on µ(t(v),u) of the tree T(v) rooted at v

129 Abraham Scheme (AGMNT): Rou.ng informa.on Every node u stores for every node v (such that c(u)=h(v)) either op.on 2a or 2b that produces MCP 2a. [non- con.guous balls] : informally "rou.ng via landmarks" Label {λ(t(l v ),l v ),λ(t(l v ),v)} where l v closest landmark node in B(v) Rou.ng path composed by u l v B(v) using λ(t(l v ),l v ) along the tree T(l v ) l v v using λ(t(l v ),v) along the same tree T(l v ) 1 l v 2 RT information stored at u {λ(t(l v ),l v ),λ(t(l v ),v)} u B(u) v B(v) Routing path 1. u l v B(v) using λ(t(l v ),l v ) along tree T(l v ) 2. l v v using λ(t(l v ),v) along the same tree T(l v )

130 Abraham Scheme (AGMNT): Rou.ng informa.on Every node u stores for every node v (such that c(u)=h(v)), either op.on 2a. or 2b. that produces MCP 2b. [con.guous balls] : informally "rou.ng via shortcuts" p(u,w,v): path from u to v composed of MCP from u to w and MCP from w to v if such paths exist with the following proper.es: u and edge (x,y) exists along the MCP from w to v such that x B(w) and y B(v) then choose the lowest cost path p(u,w,v) store labels {λ(t(u),w),x,(x y),λ(t(y),v)} w 1 2 u x B(u) 3 4 y v B(v) Routing path 1. u B(w) w on T(u) using λ(t(u),w) along Partial SPT 2. w x B(w) using vicinity routing 3. x y using stored port number (x y) 4. y B(v) v on T(y) using λ(t(y),v) along Partial SPT

131 If v B(u) or v L or c(u)=h(v) Abraham Scheme (AGMNT): Rou.ng algorithm Then node u (source) routes directly to v (des.na.on) using its locally stored rou.ng informa.on If v B(u) then vicinity rou.ng 1a: name v, port name (u w), where w next hop along a minimum cost path (MCP) from u to v using label λ(t(v),u) If v L (v is a landmark node, v = l) then tree rou.ng on T(l) 1b: µ(t(l),u) and λ(t(l),l) of tree T(l) If c(u)=h(v) then rou.ng either on 2a: {λ(t(l v ),l v ),λ(t(l v ),v)} /* non- con.guous balls 2b: {λ(t(u),w),x,(x y),λ(t(y),v)} /* con.guous balls Otherwise node u forwards packet to u' B(u) such that c(u')=h(v) From u' : 2a /* see next slide From u' : 2b /* see next slide

132 Abraham Scheme (AGMNT): Rou.ng algorithm Otherwise Node u forwards packet to u' B(u) such that c(u')=h(v) Then from u' the packet is forwarded to v using w rou.ng informa.on 2a: uses u' stored label {λ(t(l v ),l v ),λ(t(l v ),v)} where l v closest landmark node in B(v) WHEN on every MCP from u' to v, there is a node y y B(u) and y B(v) note: b(u') + b(v) d(u',v) u' 1 u B(u) 2 l v 3 v B(v) Routing path 1. u u' B(u) such that c(u')=h(v) using vicinity routing Then using u' locally stored labels {λ(t(l v ),l v ),λ(t(l v ),v)} 2. u' l v B(v) using λ(t(l v ),l v ) along tree T(l v ) 3. l v v using λ(t(l v ),v) along the same tree T(l v )

133 Abraham Scheme (AGMNT): Rou.ng algorithm Otherwise Node u forwards packet to u' B(u) such that c(u')=h(v) using vicinity rou.ng Then from u' the packet is forwarded to v using u' local rou.ng informa.on 2b: uses u' stored label {λ(t(u'),w),x,(x- >y),λ(t(y),v)} WHEN there exists a MCP in which every node is in B(u) B(v) u B(u) 1 w 2 3 u' x B(u') 4 5 y v B(v) Routing path 1. u u' B(u) such that c(u')=h(v) using vicinity routing 2. u' B(w) w on T(u') using λ(t(u'),w) along Partial SPT 3. w x B(w) using vicinity routing 4. x y using stored port number (x y) 5. y B(v) v on T(y) using λ(t(y),v) along Partial SPT

134 AGMNT Rou.ng Scheme Analysis Intra- Vicinity Ball (color independent) Intra- Color Inter- Vicinity Ball Inter- Color Table 1a entries (virtual ball routing) Table 1b entries (landmark routing) Table 1c entries (partial SPT) Table 2a entries (indirection via landmark) Table 2b entries ü (not all adjacent neighbors in vicinity ball) ü (not all adjacent neighbors in vicinity ball) ü (using table 1b routing entries) ü (using table 1c routing entries) used to redirect to a node w in B(u) such that c(w)=h(v) ü (but limited to routing up to the landmark l)

135 Compact Rou.ng Scheme: Design Space Name- independent rou.ng: for k=1,2,3,5 Stretch < 2k + 1 Memory space: Ω(n 1/k ) Name- dependent/labeled rou.ng: Stretch 4k 5, k 2 ( 2k 1 with handshaking) Memory space: Õ(n 1/k ) Note: for k=4, stretch lower bound is not known to be 2k 1 (Erdos conjecture proved only for k=1,2,3,5) Stretch k- 1 4k- 5 Routing Table Size Õ(n 1/2 ) Õ(n 1/3 ) Õ(n 1/3 ) Õ(n 1/k ) Õ(n 1/k ) Handshaking required? no yes no yes no

136 Compact Rou.ng Scheme: Design Space RT Size (memory space) ~ Ω(n) ~ Ω(n 1/2 ) shortest path routing Ω(n log n) For any stretch < 3 routing scheme: memory space lower bound stretch- 1 routing, Ω(n), ~ i.e., no generic stretch < 3 routing scheme can guarantee sub- linear RT sizes ~ Ω(n 1/3 ) Minimum value of maximum stretch allowing sub- linear RT sizes Lower bounds: Stretch < 3 requires Ω(n) bits per node [Gavoille & Gengler 01] Stretch < 5 requires Ω(n 1/2 ) bits per node [Thorup & Zwick 01] Stretch < 7 requires Ω(n 1/3 ) bits per node [Thorup & Zwick 01] Stretch 7

137 Specialized Compact Rou.ng (1) Universal compact rou.ng (for any connected graph): stretch- 1 with sub- linear RT size (memory space) does not exist Specialized compact rou.ng scheme: find "shortest path rou.ng" with sub- linear RT sizes on scale- free graphs Proper.es of scale- free networks Do not allow for efficient address aggrega.on like trees But do allow for extremely efficient sta3c compact rou.ng Expecta.on: take benefit of scale- free networks specifics to obtain "non- generic algorithms" specialized (op.mized) for Internet- like topologies

138 Specialized Compact Rou.ng (2) Universal (any connected graph) Specialized compact rou.ng schemes (scale- free graph) Average stretch on Internet- like graphs lower than 3 but how close can it be to 1? [Krioukov04] showed that average performance of op.mal stretch- 3 TZ scheme on Internet- like topologies is much be er than its worst case Upper bounds are: RT size comprising 2187 entries and stretch = 3 Results Average RT size on Internet topology around 50 entries Average stretch = 1.1 Up to 70% of all pairwise paths being stretch- 1 (shortest path) On scale- free graphs, both stretch and memory can be made extremely small simultaneously D.Krioukov, K.Fall, and X.Yang, Compact routing on Internet- like graphs, IEEE INFOCOM 2004.

139 Specialized Compact Rou.ng (3) Name- dependent vs independent compact rou.ng scheme Stretch Name dependent (labeled) Name independent 1 n log n n log n 3 Universal TZ scheme: n 1/2 log n Universal Abraham scheme: n 1/2 log n Note: same worst- case/upper- bound scaling as name- dependent scheme but name- independent scaling is worse on average Universal schemes on Internet- like scale- free graphs Name dependent (labeled) Shortest- path: n log n TZ scheme: shows an average stretch ~ 1.1 (~70% shortest path) and RT size is well below its upper bounds (52 vs for n=10,000 nodes) Name independent Shortest path: n log n Abraham scheme (same setting): shows an average stretch ~ 1.5 (first result) and RT size of 6000 entries (about 300kb) Specialized name- dependent schemes exploi.ng topological proper.es of scale- free graphs Example: BC scheme: logarithmic RT scaling O[(log 2 n) 2 ] and infinitesimally small stretch

140 Results with Abraham Scheme (1) Results obtained using DRMSim: rou.ng model simulator developed by the EULER project (hmp://drmsim.gforge.inria.fr/) on synthe.c topology produced by GLP [Bu2002] generator based on preferen.al a achment model Probability P of choosing node i given by [ ki ( t) β ] P =, where k i = degree of node i i ( t) N ( t) [ k ( t) β ] j= 1 j Parameters n = /* ~ Internet topology of 2002 m 0 = 6 /* start with m 0 nodes connected through m 0-1 edges p = /* add a new node with m new links with probability 1 p /* add m < m 0 new links with probability p (for each end of each link, node i is chosen with probability P(d i ) m = {1.15} /* ini.al degree of new nodes (15% of degree 2) β = /* tunable parameter indica.ng preference for a new node connec.ng to high degree nodes (smaller value of β indicates lesser preference to high degree nodes)

141 Results with Abraham Scheme (2) Value close to the theoric optimum: 580 entries Source: DCR Project

142 Results with Abraham Scheme (3) Multiplicative stretch = routing scheme path length / minimum path length (actual distance) for the same source-destination pair Source: DCR Project

143 Results with Abraham Scheme (4) Number of rou.ng entries independent of the node degree Variability of the number of rou.ng entries mainly determined by Rou.ng in vicinity ball (hence the volume/size of the ball) Rou.ng between con.guous vicinity balls (means a rela.ve high frac3on of nodes have con.guous vicinity balls and rela.vely low frac3on of nodes use landmark rou.ng)

144 Dynamic Compact Rou.ng (1) Compact rou.ng schemes assumes a coherent full view of the graph (represen.ng topology) at any given instant in.me Achieve coherent full view of the topology (or paths to all other network nodes) and support adapta.on to topology dynamics requires that each router 1) maintains consistent non- local knowledge about topological (resul.ng from failures, add/remove of routes and ASs, etc.) and policy changes 2).mely distributes to its own peers the rou.ng informa.on received from other peers: rou.ng updates Example: TZ scheme is not adapted for dynamic rou.ng case since it labels nodes with topology- dependent informa.on (as soon as the topology changes, nodes need to be re- labeled) Associated communica.on cost and processing cost Rou.ng updates lead to re- computa.on/re- selec.on of RT entries that in turn result in convergence delay and instabili.es

145 Implica.on of dynamic adapta.on Communica.on cost: messaging Upon topology /policy changes,.mely distribu.on of rou.ng informa.on exchanges between routers by means of rou.ng updates following specific criteria the rou.ng informa.on received from other peers Goal: each router reaches and maintains a consistent view of non- local network topology Computa.onal cost: processing of rou.ng updates for (re- )computa.on of RT entries requires to account for computa.onal complexity Time: number of cycles/opera.ons needed to recompute a RT entry for a given des.na.on Resource: amount of memory/cpu needed to recompute a RT entry for a given des.na.on

146 Dynamic Compact Rou.ng (2) Communica.on cost of rou.ng schemes cannot grow slower than linearly with network size (#nodes) on Internet- like topologies [Afek89]: communica.on ~ cost cannot scale be er than Ω(n) for universal rou.ng schemes Expecta.on: specialized rou.ng schemes for scale- free graphs might behave be er (Ω(n) bound a ained only on some marginal worst- case graphs)? [Korman06]: communica.on cost lower bound for scale- free graphs is ~ at best linear up to logarithmic factors: Ω(n)... but s.ll much be er than exponen.al- like communica.on cost of BGP

147 Dynamic Compact Rou.ng (3) Implica.ons Internet- like graphs belong to the class of worst- case graphs across all possible network topologies Dynamic compact rou.ng ~ schemes shall assume a full coherent view of the graph at any given instant in.me To achieve coherent full view and support network topology dynamics:.mely rou.ng updates and name- independence are required

148 Outline Introduc.on Part I: Fundamental dimensions of rou.ng models and algorithms Limits of shortest path rou.ng (and variants) Part II: Alterna.ves Space and tradeoffs Compact rou.ng Part III: Recent advances Geometric rou.ng on hyperbolic spaces Concluding remarks

149 Space of Rou.ng Scheme Alterna.ves Compact Rou.ng Name dependent schemes: e.g. TZ scheme, BC scheme, etc. Name independent schemes: e.g. Abraham scheme! As of today computa.on based on "full- view" of the topology and no support of Internet topology dynamics - > Dynamic (and distributed) compact rou.ng Hybrid rou.ng protocols Combina.on of LS/PV: Hybrid Link- state Path- vector (HLP) Combina.on of LS/DV: LVA Geometric Rou.ng Hyperbolic space (plane): Embedding: Internet topology graph embedded into hyperbolic plane (requires full view of the topology) Mapping: graph constructed from hidden hyperbolic space yielding to scale- free topologies Observable topology (with transforma.on) Euclidean space Others Overlay rou.ng and variants: host- based: SHIM6, Host Iden.ty Protocol (HIP) router- based: Loc/ID split protocol (LISP), GSE 8+8, etc. Hierarchical rou.ng: on scale- free network topology, hierarchical, aggrega.on- based rou.ng is inefficient Stochas.c Rou.ng

150 Outline Introduc.on Part I: Fundamental dimensions of rou.ng models and algorithms Limits of shortest path rou.ng (and variants) Part II: Alterna.ves Space and tradeoffs Compact rou.ng Part III: Recent advances Geometric rou.ng on hyperbolic spaces Concluding remarks

151 Geometric Rou.ng Geometric rou.ng: assigns to each node coordinates in a metric space (X,d) used as locators to perform point- to- point (distance decreasing) rou.ng Geometric Rou.ng Euclidean space: dim(v) ~ O(log n): too high- dimensional for many applica.ons Euclidean Space Hyperbolic Space Hyperbolic space: 2- dim are sufficient Observable topology Transf. observable topology Embedding Mapping Principle: builds a set of local rou.ng entries whose total memory space is propor.onal to the degree of each node Note: excludes memory space mobilized for storing results of intermediate opera.ons for coordinate assignment

152 Geometric Rou.ng Graph G=(V,E) Each node u V knows its own posi.on (coordinate) and posi.on of its neighbors N(u) Source node knows the posi.on of the des.na.on Rou.ng process Given distance func.on d G : V V R +, each node performs the following rou.ng decision (at each node): Given a des.na.on node t, a node u V route message to its neighbor v N(u) such that d G (v,t) = min x N(u) d G (x,t) Note: rou.ng process also referred to as greedy rou/ng: stateless rou.ng (computa.on of next- hop neighbor on per packet header informa.on basis)

153 Distance decreasing rou.ng func.on? d G (v,t) = min x N(u) d G (x,t) s selects v s v t

154 Geometric Rou.ng Geometric rou.ng: assigns to each node coordinates in a metric space (X,d) used as locators to perform point- to- point (distance decreasing) rou.ng Geometric Rou.ng Euclidean space: dim(v) ~ O(log n): too high- dimensional for many applica.ons Euclidean Space Hyperbolic Space Hyperbolic space: 2- dim are sufficient Observable topology Transf. observable topology Embedding Mapping Principle: builds a set of local rou.ng entries whose total memory space is propor.onal to the degree of each node Note: excludes memory space mobilized for storing results of intermediate opera.ons for coordinate assignment

155 Geometric Rou.ng Coordinate Every node is assigned a coordinate Coordinates reflect nodes loca.on in the network Ex: Hyperbolic plane H 2 with (r,θ) coordinates Distance metric A metric is defined that reflects distances between nodes Ex: Hyperbolic distance func.on where Poincaré disk model represents Hyperbolic plane H 2 as the interior surface of open unit disk D = {(x, y) R 2 x 2 + y 2 < 1} whose points lie inside the unit circle D ={(x, y) R 2 x 2 + y 2 < 1} (itself represen.ng the boundary of the unit disk at infinity) Geodesics as the arcs of circles orthogonal to the boundary of the unit disk D

156 Greedy Embedding and Rou.ng Embedding of undirected graph G = (V,E) metric space (X,d) One- to- one mapping func.on µ: V(G) X Distance preserving: s, t V(G), s t, d G (s,t) d X (µ(s),µ(t)) Greedy embedding of undirected graph G = (V,E) (X,d) One- to- one mapping func.on µ: V(G) X Property: s, t V(G), s t, u V(G) such that (s,u) E(G), d(µ(s),µ(t)) > d(µ(u),µ(t)) s, t V(G), s t, distance decreasing path p(s,t) Path (v 0 (=s),v 1,..., v m (=t)) is distance decreasing if d(v i- 1,v m ) > d(v i,v m ) i Theorem [Papadimitriou05]: embedding of G metric space (X,d) is greedy iff greedy rou.ng is always successful

157 Greedy Embedding and Rou.ng Theorem [Kleinberg07]: every finite, connected, undirected graph has a greedy embedding in two- dimensional hyperbolic space (hyperbolic plane H 2 ) embedding allowing greedy rou.ng for all source- dest. pairs General problem: given topology of G = (V,E), find its embedding in hyperbolic plane H 2 such that greedy rou.ng i) maximizes success rate (100%- successful) and ii) produces low stretch rou.ng paths

158 Greedy Embedding and Rou.ng Procedure (outline) Compute spanning tree (ST) of original graph G Determine node r of max. degree k ( ST root) Generate k- regular tree in X = H 2 and ST (in G) - > k- regular tree (in H 2 ) Star.ng from r, node u receives transforma.on coeff. μ u, and computes its virtual coordinate = μ u 1 in Poincare disk G contains shortcuts that greedy rou.ng can use Given s t: distance decreases on p(s,t): d(u,t) > d(v,t) s Spanning Tree T embedded in the hyperbolic plane t Source: Geometric routing in hyperbolic space, Kleinberg (2005)

159 Challenges Challenges in Greedy embedding and rou.ng 1. Find appropriate mapping func.on µ together with polynomial-.me algorithm to embed V(G) in X so as to produce low stretch greedy rou.ng paths using the metric d associated to that space 2. Rou.ng path stretch Procedure may result (worst case) to rou.ng path stretch linear in n instead of poly- logarithmic in n ( log(n)) 3. Adapta.on cost: upon topology update (node joining or leaving) requires O(n) opera.ons as greedy property of en.re embedding can be invalidated Current procedure requires knowledge of full graph topology in advance (a link must be aware that it is "long") Need to reduce communica.on cost and associated overhead without imposing drawbacks of centralized sta.c rou.ng scheme

160 Geometric Rou.ng Geometric rou.ng: assigns to each node coordinates in a metric space (X,d) used as locators to perform point- to- point (distance decreasing) rou.ng Geometric Rou.ng Euclidean space: dim(v) ~ O(log n): too high- dimensional for many applica.ons Euclidean Space Hyperbolic Space Hyperbolic space: 2- dim are sufficient Observable topology (κ,d) Transf. observable topology Embedding Mapping Principle: builds a set of local rou.ng entries whose total memory space is propor.onal to the degree of each node Note: excludes memory space mobilized for storing results of intermediate opera.ons for coordinate assignment

161 Preliminaries Metric space (X,d) is geodesic if x, y X, there is a con.nuous path of length d(x,y) joining x to y Con.nuous path geodesic path defined as mapping γ: [a,b] X γ(a) = x, γ(b) = y d(γ(s),γ(t)) = s- t, s,t [a,b]. In par.cular, d(γ(a),γ(b)) = a- b = d(x,y) Given ρ > 0, a metric space (X,d) is said to be ρ- geodesic if for x, y X with d(x,y) < ρ, there is a geodesic path joining x to y Geodesic triangle with ver.ces x, y, z X: union [x, y] [y, z] [z, x] of three geodesic segments connec.ng these ver.ces Remarks These defini.ons have equivalent in discrete structures (graphs) EULER FP7 Project has (further) confirmed that the graph G = (V,E) underlying the Internet network topology is nega.vely curved (hyperbolic) => Exploi.ng geodesic paths for informa.on rou.ng purposes provides founda.ons for geometric rou.ng (on the observable topology)

162 Curvature κ and CAT(κ) space CAT Cartan- Alexandrov- Toponogov A metric space X is said to be of curvature κ (bounded above by κ) if it is locally a CAT(κ) space, i.e., x X, ρ > 0 such that B(x,ρ x ), equipped with the induced metric, is a geodesic space all of whose geodesic triangles sa.sfy the CAT(κ) inequality d( x, y) d( x, y) Δ X 2 Δ E A geodesic space X is said to be a CAT(0) space if all geodesic triangles Δ in 2 X are not "fa er" (or "thicker") than their comparison triangles Δ E A geodesic space X is defined to be non- posi.vely curved (X has curvature 0) if every point of space X is locally a CAT(0) space A geodesic space X is said to be a CAT(- 1) space if all geodesic triangles Δ in X are not "fa er" (or "thicker") than their comparison triangles 2 Δ H A geodesic space X is defined to be nega.vely curved (X has curvature - 1) if every point of space X is locally a CAT(- 1) space

163 Cartan- Hadamard theorem For κ 0, a geodesic metric space sa.sfies the CAT(κ) inequality locally iff if it sa.sfies the CAT(κ) inequality globally Use local informa.on (microscopic level) to deduce global proper.es of the space under considera.on (macroscopic level) Local structures imply high probability of obtaining sub- spaces of posi.ve curvature (resul.ng from the heterogeneity of the Internet topology) => Use defini.on of nega.ve curvature at large scale? Theory of δ- hyperbolic spaces [Gromov87] Fundamentally different concept of nega.ve curvature, largely insensi.ve to local proper.es Provides robust condi.on that geodesic spaces shall sa.sfy in order to produce many of the global features associated with large- scale geometry of manifolds of nega.ve curvature Every CAT(κ < 0) space is δ- hyperbolic, where δ depends only on κ

164 δ- hyperbolicity A metric space (X, d) is δ- hyperbolic when it verifies the Four- point condi.on: Gromov product (x y) o = [d(o, x) + d(o, y) - d(x, y)]/2 for any two point x, y X wrt fixed reference point o X sa.sfies the inequality (x y) o min{(x z) o, (y z) o } - δ, for some δ 0, and any four points o, x, y, z X Following four- point condi.on: hyperbolicity of simply connected unweighted graph G = (V,E) equipped with metric d G (x, y) = min. δ 0 such that metric space D G = (V,d G ) is δ- hyperbolic Note Case δ = 0 coincides with family of metric trees (if o is the root of the tree, then (x y) o corresponds to the distance from o to the least common ancestor of x and y): trees are 0- hyperbolic

165 Equivalent defini.ons of δ- hyperbolicity Equivalent defini.ons of δ- hyperbolicity: space X is δ- hyperbolic if all geodesic triangles in X are δ- slim or δ- thin for some fixed δ 0 δ- slim triangles condi.on: δ 0 such that geodesic triangle in X and for any point w [x, y], d(w, [y, z] [z, x]) δ (and similarly for the other sides [y, z], [z, x] of the triangle) δ- thin triangles condi.on: δ 0 such that geodesic triangle in X and any pair of points v, w lying on its sides and equidistant from one of its ver.ces (e.g., v [x, z], w [x, y] and d(x,v) = d(x,w)), d(v,w) δ ) Despite their simplicity proving such condi.on holds globally results in a major computa.onal challenge (O(n 4 )) in par.cular, if we assume that topological informa.on is not globally available

166 Mesoscopic curvature Mesoscopic curvature: interpola.on between microscopically controlled geometry of a CAT(κ) space and macroscopic concept of hyperbolicity - > mesoscopic condi.on (not requiring) centralized procedure or globally coordinated procedure Theorem [Cartan- Hadamart]: a geodesic metric space (X,d) is CAT ρ (-1,ε) if all of the balls B(x,ρ) of radius ρ in that space X sa.sfy the CAT(-1) inequality condi.on with an error bounded by ε (moreover if X is simply- connected and ρ >> ε, then it is also hyperbolic) - - note: defini.on applies to κ < - 1 but renormaliza.on => Concept: combine finite mesoscopic scale rou.ng on nega.vely curved metric space with large scale rou.ng while minimizing the inter- dependence between these two levels

167 Node s: proac.ve knowledge about existence of geodesic path segment [w,t] neighbor's reachability discovery process s t w v t Geodesic path segments are known at w: they correspond to the subset of path segments determined during "ball" construc.on phase (no addi.onal search process)

168 Geometric Rou.ng Source s receives content locator t, t' Assume source s selects t as des.na.on Rou.ng between s B(u, ρ+ε) t B(v, ρ+ε) along geodesic path segments: s u x and y v t Geodesic segment ρ u s u x ε ρ v y' y v t ε Geodesic segment x' t' B (u,ρ u +ε) B (v,ρ v +ε)

169 Memory consump.on (#RT Entries) Path- vector (BGP) n RT entries per node (1 RT entry per reachable prefix) Aggrega.on factor α (typically ranging from 0.1 to 0.5): α Per node: Adj_RIB_In: O(d k (α n).n) Loc_RIB (protocol RT): O(α n.n) Geometric rou.ng Space par..oning: B nodes per par..on neighbor table ~ d k Per node: O(d k. b. B ) where b = total number of par..ons Approx: O(d k. n)

170 Memory consump.on (space) Geometric rou.ng - > succinctness of locator encoding O(log 2 (n)) bits per reachable des.na.on Space par..oning: B ~ n 1/2 nodes per par..on neighbor table ~ d k Per node (approxima.on): O(d k. n. log 2 (n))

171 Stretch increase Preliminaries δ- hyperbolicity: (informally) δ measures devia.on from tree likeness (for trees: δ=0) (addi.ve) stretch of a rou.ng scheme: max{rou.ng path length(u,v) topological path length(u,v)}, u,v V Stretch BGP (without policing): Addi.ve stretch = 0 Note: BGP policing increases path length by 2 AS hops (Δ(G)/2 which is also the upper bound value of δ) Geometric rou.ng : Stretch increase = 2 δ log(n)

172 Greedy Embedding and Rou.ng Embedding of undirected graph G = (V,E) into metric space X equipped with a distance func.on d: Mapping func.on f from V(G) X such that for any pair of dis.nct ver.ces s, t V(G), there exists a vertex u adjacent to s (neighbor) such that d(f(u),f(t)) < d(f(s),f(t)) Greedy embedding: for any pair of dis.nct ver.ces s, t V(G), there is a distance decreasing path beginning with s and ending with t A path (v 0 (=s), v 1,..., v m (=t)) is distance decreasing if d(v i,v m ) < d(v i- 1,v m ) for all i An embedding of G in (X,d) is greedy iff greedy rou.ng is always successful Theorem: every finite, connected, undirected graph has a greedy embedding in two- dimensional hyperbolic plane [Kleinberg07] embedding allowing greedy rou.ng for all source- des.na.on pairs

173 Updateful Greedy Rou.ng (1) Greedy embedding problem: given graph G = (V,E), compute one- to- one mapping func.on of V(G) - > X (metric space) with d (distance func.on) such that for any pair of nodes (s,t), there is always a distance decreasing path from s to t [Kleinberg07] every finite, connected, undirected graph has a greedy embedding in two- dimensional hyperbolic space (hyperbolic plane), that is, an embedding that allows greedy rou.ng for all source- des.na.on pairs Proposed embedding depends on topological property of the graph: the maximum degree of the chosen spanning tree T (that is greedily embedded in the hyperbolic plane): Hyperbolic plane as underlying metric space X Hyperbolic distance as distance func.on d General problem: given the topology of a graph G = (V,E), find its embedding in a hyperbolic space such that greedy rou.ng is 100%- successful

174 Updateful Greedy Rou.ng (2) Method for construc.ng greedy embedding of all graphs Take a spanning tree T of the original network Embed it into a d- regular tree Use the greedy embedding of that tree may result into linear not polylog stretch routes Graph contains shortcuts that greedy routing can use Given s t: distance decreases on s- t path - > d(v,t) < d(u,t) s Spanning Tree T embedded in the hyperbolic plane t Source: Geometric routing in hyperbolic space, Kleinberg (2005)

175 Updateful Greedy Rou.ng (3) Low- stretch routes - > requires that for any pair of nodes (s,t), s t, there is always a low stretch greedy path from s to t Greedy embeddings to obtain low- stretch routes (routes implied by the greedy paths are always not (much) longer than the original ones) [Maymounkov06]: no- stretch constraint (for tree networks) adds extra difficulty since logarithmic dimensions are necessary for embeddings to hyperbolic spaces Construct embedding requires knowledge of full graph topology in advance (a link must be aware that it is "long") Research topic: reduce communica.on cost and associated overhead without imposing drawbacks of centralized sta.c rou.ng scheme Note: greedy embedding of all graphs has a rela.vely simple distributed implementa.on (each neighbor exchange descrip.on of Mobius transforma.on)

176 Updateful Greedy Rou.ng (4) Robustness of greedy embedding property under dynamic condi.ons: once ini.al graph is embedded, its topology can change over.me Embedding of newly added nodes not always possible without changing coordinates of all network nodes - > Research topic: online/incremental construc.on of greedy embedding suppor.ng addi.on of arbitrary number of nodes with no changes to previously assigned node coordinates Connec.vity changes caused by node(s) leaving the network or failing link(s) can invalidate greedy property of en.re embedding - > Research topic: greedy rou.ng procedure that guarantees delivery even in presence of disturbances of the greedy embedding property caused by nodes and/or links failing unexpectedly or intermi ently

177 Updateless Greedy Rou.ng (1) [Kleinberg00] nodes in complex networks exist in hidden metric spaces underlying observed network topologies Link between two nodes exists with probability that depends on the distance between two nodes in hidden geometry Scale- free networks appear to be congruent with respect to hidden hyperbolic metric spaces Principle: Internet nodes (ASs or routers) exist in hidden metric spaces of nega.ve curvature (hyperbolic space) that are thus poten.ally good candidates for embeddings of the real Internet topology Founda.on of updateless greedy rou.ng Efficient rou.ng on topology modeled on hidden hyperbolic space Greedy paths follow shortest paths that approximately follow shortest hidden paths

178 Methodology Updateless Greedy Rou.ng (2) Step i) Build a hyperbolic space underlying the Internet topology: hyperbolic plane Step ii) Construct topology model where nodes mapped into this hyperbolic space reproduce main topological proper.es of the Internet (node degree distribu.on, node degree correla.ons, and clustering) Specify node distribu.on (node density) and node inter- connec.on probability as func.on of hyperbolic distance between nodes - > Hidden variable approach [Boguna03] Given a network size n, each node i is first assigned a hidden variable h i (node coordinates in a hidden hyperbolic space) drawn from some probability distribu.on e.g. uniform distribu.on Create a link between each pair of nodes (i,j) with a connec.on probability p(h i,h j ), func.on of the hidden variable values at the two nodes, that depends on the hyperbolic distance between them Step iii) Perform greedy rou.ng (distance- decreasing path)

179 Updateless Greedy Rou.ng (3) Only informa.on necessary for greedy rou.ng to operate on modeled network: coordinates of local node, coordinates of its neighbors, and message des.na.on Node s address hyperbolic coordinates Each node knows only : its own address, neighbors address, and the des.na.on address in incoming packet (to be forwarded) Rou.ng can be performed in the dark (i.e., no rou.ng update messages are exchanged) on topologies congruent with underlying hyperbolic spaces Underlying hyperbolic geometry gives the direc.on to the des.na.on without having to determine the route beforehand - > Greedy relies on hidden geometry to find the path to the des.na.on On such se ng, greedy rou.ng achieves near 100% of reachability and op.mal path length even under dynamic condi.ons (both slightly deteriorates with increasing power law index) [Boguna2009]

180 Updateless Greedy Rou.ng (4) Ac.ve research topics Develop technique to compute the AS/routers coordinates in the underlying hyperbolic space Each node shall be able to autonomously compute its hidden hyperbolic coordinates based on informa.on locally accessible Determine dependency of greedy rou.ng algorithms on topologies clustering coefficient Specify network models using more realis.c node distribu.ons in the hyperbolic plane and more credible node inter- connec.on probability Network model specifica.on currently limited to uniform node distribu.on in hyperbolic plane and node connec.on probability expressed as a func.on of hyperbolic distance between nodes

181 Conclusion

182 Trends and Alterna.ves (1) Evolution (same paradigm) Paradigm shift Exis.ng paradigm: focused on short- term incremental fixes (BGP++) to a enuate symptoms instead of addressing root causes Holly Grail: patch "a la CIDR"... but s.ll to be invented (ques.on: does it theore.cally exist?) Note: some form of name space segmenta.on may be required for PA migra.on Addi.onal level of indirec.on (on top of IP network layer): ICN/CCN New path(- vector) based rou.ng such pathlets, path segments, etc. Note: Loc/ID split protocol (LISP) no improvement possible on RT size scale from aggrega.on Manageability and opera.onal simplifica.on Example: self- adap.ve BGP x sta.s.cal machine learning (x data/ graph analysis and mining) Name- independent dynamic rou.ng that minimizes stretch bound for Internet- like graphs while requiring at most O(n) bits per RT Geometric rou.ng on hyperbolic plane Combina.on of new ingredients Shorter Term Longer Term

183 Trends and Alterna.ves (2) Open coupled research challenges (stretch x RT size scale x topology adapta.on/dynamics) for dynamic rou.ng schemes specialized for scale- free graphs In par.cular, how to cope with effects of topology adapta.on (in terms of processing and communica.on cost) Traffic- driven: spa.al characteris.cs, both unicast and mul.cast traffic, etc. U.lity- driven: usefulness of disseminated rou.ng updates (path backtracking, selec.ve rou.ng, reinforcement, etc.) Dependence on policy model: is policy model independent of rou.ng model (coupling)? Performance evalua.on of dynamic rou.ng schemes on Internet- like topologies is a challenge on its own (very large- scale simula.on)

184 Paradigm shis Trends and Alterna.ves (3) New rou.ng scheme with new "addressing"?????? New rou.ng scheme with current "addressing" Modify rou.ng system architecture Time Modify rou.ng system architecture component(s) How long??? Evolu.on Modify rou.ng protocol elements paradigm- shis path incremental path