10 20 08
play

10/20/08 Today P561: Network Systems Internet routing (BGP) Week - PDF document

10/20/08 Today P561: Network Systems Internet routing (BGP) Week 4: Internetworking II Tunneling and MPLS Wireless routing Wireless handoffs Tom Anderson Ratul Mahajan TA: Colin Dixon 2 Internet today Key goals for Internet routing


  1. 10/20/08
 Today P561: Network Systems Internet routing (BGP) Week 4: Internetworking II Tunneling and MPLS Wireless routing Wireless handoffs Tom Anderson Ratul Mahajan TA: Colin Dixon 2 Internet today Key goals for Internet routing Scalability Support arbitrary policies • Finding “optimal” paths was less important (Supporting arbitrary topologies) 3 4 Internet routing overview Path vector routing Two-level hierarchy for scalability Similar to distance vector routing info includes entire paths • Intra-domain: within an ISP (OSPF, MPLS) • Inter-domain: across ISPs (BGP) Path vector protocol between Ases • Can support many policies • Fewer messages in response to small changes 192.4.23, [3, 7] • Only impacted routers are informed 192.4.23, [7] 5 6 1


  2. 10/20/08
 Policy knobs Path vector vs. link state vis-à-vis policy 1. Selecting one of the multiple offered paths 1 192.168.1.3/24, [2, 4] AS 2 D 0 AS3 preferences 3 [31o] AS 1 AS 4 [320] 2 192.168.1.3/24, [3, 4] AS 3 [3210] [3120] 2. Deciding who to offer paths With path vector, implementing the policy above requires only local knowledge at AS3 192.168.1.3/24, [4, 1] AS 2 With link state, AS3 would need to know the AS 4 AS 1 policies of other ASes as well AS 3 192.168.1.3/24, [4, 1] 7 8 Typical routing policies BGP at router level Driven by business considerations Two common types of relationships between ASes Customer-provider: customer pays provider • Peering: no monetary exchange • When selecting routes: customer > peer > provider When exporting routes: do not export provider or peer routes to other Peer or Peer or providers and peers provider provider X Customer Customer Prefer routes with shorter AS paths 9 10 BGP limitations Path quality with BGP Path quality Combination of local policies may not be globally good Scale • Longer paths, asymmetric paths Convergence • Shorter “detours” are often available Security Example: A hot potato routing B 11 12 2


  3. 10/20/08
 Scaling pressures on BGP BGP convergence (1/4) Too many prefixes (currently ~280K) 1 Major factors behind growth: multi-homing and D 0 3 traffic engineering 192.168.0.0/16 192.168.0.0/17 2 192.168.0.0/16 Provider 1 Provider Customer Customer Temporary loops during path exploration Provider 2 192.168.0.0/16 Differentiating between failure and policy-based 192.168.128.0/17 retraction can help but not completely 13 14 BGP convergence (2/4) BGP convergence (3/4) Several other issues have been uncovered 0 1 • Interaction with intra-domain routing To get to D, X prefers • Interaction with traffic engineering extensions [X, (X+1) mod 3] D [X] • Interaction with scalability extensions Others 2 Persistent loops can also form in BGP Fundamentally, the combination of local policies may not have a unique global solution 15 16 BGP convergence (4/4) BGP security Q: What saves us in practice? Extreme vulnerability to attacks and misconfigurations An AS can announce reachability to any prefix • A: Policy! (No guarantees, however) An AS can announce connectivity to other Ases • Many known incidents 1 0 1 AS7007 brought down the whole internet in 1997 • 75% of new route adverts are due to misconfigs [SIGCOMM 2002] • D 0 3 D Commonly used for spamming • Policy reduces the Policy makes some Technical solutions exist but none even close to deployment number of valid paths 2 preferences rare 2 Incentives and deployability (Week 10) • 17 18 3


  4. 10/20/08
 Tunneling Tunneling is broadly useful technique Encapsulating one protocol within another Used widely today • Secure access to remote networks (VPNs) • Your laptop to corporate networks Tun Tun Src Dst Src Dst • Between different sites of a company • MPLS • 6to4 • GRE The blue sources, destinations, networks are • SSH tunnels oblivious to tunneling • …. The yellow network does not care if it carries blue (or green) packets Think of it as a generalization of traditional layering 19 20 MPLS Benefits of MPLS (1/3) LSRs do not understand or maintain state for IP LER • Can yield higher performance • Without n 2 pair-wise tunnels LSR LER LSR LER LSR LER LSR LSR LSR LER LSR LSR LER LSR LER LSR LER 21 22 Benefits of MPLS (2/3) Benefits of MPLS (3/3) Traffic engineering (load balancing) Separation of traffic for security or for QoS LER LER LSR LSR LSR LSR LER LER LSR LER LSR LSR LER LSR LSR LSR LER LER 23 24 4


  5. 10/20/08
 Downsides of MPLS MPLS adoption Unnecessary overhead Pretty widespread If all you want is IP forwarding • • Almost all tier-1 ISPs have deployed MPLS If link state routing can provide effective traffic engineering • Robustness to failures It offers tools that network admins badly need Setting up a complete virtual circuit takes time • • Practical concerns trumped purist views Fast reroute works only for a handful for failures • Opacity Traditional diagnosis tools do not work • Complexity Requires more configuration at routers • 25 26 Why is wireless routing different? First generation of protocols Mobility and fast changing conditions Focus on mobility and changing conditions • Used hop count as the quality metric • Reactive route computation was more popular Packet losses • To avoid unnecessary topology maintenance overhead Interference Examples: DSR, AODV 27 28 All links are not the same Hop count limitations It minimizes the number of hops and thus prefers longer links But longer links tend to have more loss • Need more retransmissions for successful reception Retransmissions can consume more spectrum resources than using shorter hops • Need to balance hops and losses MIT’s indoor testbed 29 5


  6. 10/20/08
 Link qualities in Roofnet Delivery probabilities in Roofnet Broadcast packet delivery probability 70-100% Delivery Probability Broadcast Packet 30-70% 1-30% > two-thirds of links deliver less than 90% 1 kilometer Node Pair 31 32 ETX: Expected transmissions ETX avoids low-throughput paths Estimate number of times a packet has to be retransmitted on each hop 1 Use probes to calculate forward and reverse loss rate to • each neighbor 0.8 Cumulative Fraction ETX 0.6 HOP 0.4 Select the path with least total ETX 0.2 Takes longer paths only when they are better • 0 0 2000 4000 6000 8000 10000 Throughput (Kbps) Results on MSR testbed (courtesy Jitu Padhye) 33 34 ETX shortcomings ETX paths are generally longer Assumes that all transmissions are equal 8 • In reality, different transmissions use different 7 Path Length with HOP amount of spectrum 6 5 Assumes a simplistic interference model 4 3 • Cross-flow interference not directly accounted 2 • Worst-cast self-interference 1 0 Ignores the broadcast nature of wireless 0 1 2 3 4 5 6 7 8 Path Length with ETX 35 36 6


  7. 10/20/08
 ETT performance ETT: Expected transmission time Generalizes ETX to the case of multiple bit rates 1800 Throughput (Kbps) Directly measures spectrum resources used 1600 1400 On a link with loss rate p, bitrate B, packet size S 1200 1000 800 600 400 200 0 ETT ETX HOP 12 Mbps 48 Mbps 10% loss 20% loss [Routing in Multi-radio, Multi-hop Wireless Mesh Network, MOBICOM 2004] 37 38 Unpredictable wireless performance Is one path better than the other? Bad Good Source Relay Sink Good Bad Source Relay Sink Bad Good Source Relay Sink UDP throughput (Kbps) UDP throughput (Kbps) bad-good Good Bad Source Relay Sink bad-good good-bad 2x Hint: ETT (or ETX) of both is same good-bad Loss rate on the bad link Source rate (Kbps) 39 40 Measurements Predictable performance optimization Measure the RF profile Measure the RF profile of the network of the network One or two nodes broadcast at a time Constraints on sending rate Constraints on sending rate Yields information on loss and loss rate of each link and loss rate of each link and deferral probabilities Find compliant source rates Find compliant source rates that meet the objective that meet the objective [Predictable performance optimization for wireless networks, SIGCOMM 2008] 41 42 7


Recommend


More recommend