210 likes | 323 Views
NAT-Based Internet Connectivity for Multi-Homed On-Demand Ad Hoc Networks. Paal Engelstad and Geir Egeland University of Oslo (UniK) / Telenor R&D, 1331 Fornebu, Norway Presented by: Paal Engelstad http://www.unik.no/~paalee/PhD.htm. Motivation.
E N D
NAT-Based Internet Connectivity for Multi-Homed On-Demand Ad Hoc Networks Paal Engelstad and Geir Egeland University of Oslo (UniK) / Telenor R&D, 1331 Fornebu, NorwayPresented by: Paal Engelstad http://www.unik.no/~paalee/PhD.htm
Motivation • Ad hoc networks need to access the fixed Internet • Some nodes connected to external IP-networks may operate as gateways for other MANET nodes • Previously proposed solutions: • A gateway implementing Mobile IPv4 Foreign Agent (MIP-FA) • Internet draft by Belding-Royer et al. • MSc. Thesis on ”MIPMANET” by Alriksson and Jönsson, KTH, August 1999 • A gateway implementing a Network Address Translator (NAT) • Uppsala University’s implementaton of AODV • NAT-based solutions have yet been poorly documented in published material
Assume you know AODV... Short re-cap: • A Source Node discovers route to destination on demand • It floods an RREQ to find a route to a destination • The RREQ forms a return route on each node • The Destination node responds: • It unicasts an RREP along the reverse route • The RREP forms a forward route • Every node maintains its own destination sequence number • Incremented before the flooding • Ensures loop freedom • An intermediate node may reply to RREP on behalf of Destination node if it has a valid route to the destination • With multiple RREPs, the routing protocol prefers • RREPs with higher destination sequence numbers • Fewest hops between source and destination
Background (1): MIP-FA Home Agent External Host • Overview • A gateway with FA-support (MIP-FA) which understands AODV • A MANET node with MIPv4 support • The MANET registers the MIP-FA Gateway with its Home Agent • Drawbacks: • High complexity • MIP and AODV makes unsynchronized modifications to routing table • MIP requires global IPv4 addresses Internet Foreign Agent Source Node MANET
1 2 3 4 Background (2): NAT External Host • Overview • Drawbacks • The well-known drawbacks with the use of NATs • Dynamic change of gateways must be solved by MIPv4 • Advantages • Less complex, easy to implement and deploy • Does not rely on MIPv4 deployment and fixed IPv4 address Internet Network Address Translator Source Node MANET
F F F F Route Discovery with Proxy RREP External Host • Source Node (SN) broadcasts a RREQ to establish route to External Host (XH) • Gateway impersonates XH, by sending a RREPon behalf of XH. • Uses XHs IP address as Source IP Address in RREP • This is a “Proxy RREP” • SN forwards packets to XH using the route established by the Proxy RREP. • The gateway forwards the packet to XH • How about the destination sequence number in a ”Proxy RREP”? Internet Gateway Source Node MANET RREQ: Route RequestRREP: Route ReplyXH: External HostNAT: Network Address Translation
Destination Seqence numbers in Proxy RREP • MIP-FA Gateway (Belding-Royer et.al.): • Source Node normally sets RREQ with • Unknown Seqence Number bit = 1 • Destination Sequence Number = 0 • Gateway copies this into the ”Proxy RREP” (i.e. a zero destination sequence number) • AODV-UU NAT-solution: • Use Gateway’s own destination sequence number (a hack) • Require different IP address spaces • To distinguish internal from external nodes • Not acceptible or at least very limiting • We proposed a better NAT-solution with ”Proxy RREP”: • Implementing the MIP-FA policy (above) • Ensure that an Internal node never uses a zero destination sequence number • Hence, a real RREP from an internal MANET node always have preference over a Proxy RREP (i.e. no problem if gateway always send Proxy RREP...)
F F F F Proxy RREPs and Multi Homing External Host • The Source Node (SN) broadcasts a RREQ to establish route to the external Host (XH) • Both gateways send a Proxy RREP on behalf of the XH • The Source Node forwards packets to XH using the route established by one of the Proxy RREPs. • The “winning” gateway forwards the packet to the XH Internet NAT NAT Source Node MANET RREQ: Route RequestRREP: Route ReplyXH: External HostNAT: Network Address Translation
? F F F F F F Race Conditions - a route needs to be re-discovered External Host • The Source Node (SN) broadcasts a RREQ to establish route to the external Host (XH) • Both gateways send a Proxy RREP on behalf of the XH, GW1 wins • SN sends packets for XH via GW1. • After link break or route timeout, SN broadcasts a new RREQ to re-establish the route to XH • Both gateways send a Proxy RREP on behalf of XH, but this time GW2 “wins” • SN sends subsequent packets for XH via GW2, connection fails Internet GW1(NAT) GW2(NAT) Source Node MANET RREQ: Route RequestRREP: Route ReplyXH: External HostGW: Gateway
Demonstrating Race Conditions due to route re-discovery • Testbed experiment (i.e. lab implementation) • Fewer nodes, more static • Active Route Timeout (3 sec of AODV) triggers route re-discovery • Simulations • Many nodes, more mobility, etc... • Network dynamics (such as mobility) triggers route re-discovery • I will only go through the simulations if time permits...
Test bed experiment (1) External Host • AODV-implementation by Uppsala University • IEEE 802.11 • Linux • MAC-layer filtering • Packet Transmission Interval • 1 sec: • OK • 4 sec: (e.g. interactive traffic, Telnet, etc...) • Race conditions • Best performance: 11% probability of (Telnet-) session breakage due to race condition • Increased random max ”processing time” (Tmax): => prob. -> 50% Internet GW1(NAT) GW2(NAT) Intermediate Node MANET Source Node
Test bed experiment (2) Share of RREPs received 11 Tmax [ms]
Simulation setup • Glomosim, with AODV module • IEEE 802.11, Two-Ray channel model • Traffic pattern: Constant Bit Rate (CBR), 1024 byte packets • 50 nodes • Radio Range 50m, 200mx200m square • Radio Range 10m, 40mx40m square
Simulation #1 • Testing Race Conditions due to Route Timeout: • Static scenario, and varying Packet Transmission Interval (PTI): • Race Conditons have a dramatic impact on performance when PTI exceeds Active Route Timeout of AODV (of 3 sec.).
Simulation #2 • Network configurations/ topologies that leads to bad performance? • When gateways are an equal number of hops away from SN • (i.e. on right hand side of figure...)
Simulation #3 • Testing effects of terrain size (i.e. of node density or of ”strength” of connectivity): • Fully connected network: Probability of 50% • Attributed to the ”ideal” model of Glomosim • Problem decreases as terrain size increases, because probability that gateways are an equal number of hops away, decreases.
Simulation #4 • Testing Race Conditions due to link breaks, by adding mobility: • Random Way Point (with zero rest-time and variable max velocity) • PTI = 1 sec, i.e. safely below the Active Route Timeout of AODV • See that problem increases rapidly to unacceptably high levels, even for relatively low levels of mobility • Other non-deterministic effects (radio-fading, packet collisions, etc.) occuring in a MANET, and is not easily caught by a simulation model • This effecs will also accellerate the problems of Race Conditions
Summary of results - I • Our work shows that race conditions due to Proxy RREPs can be damaging in on-demand ad hoc networks • For smaller networks (testbed) • And for larger networks (simulations) • Race Conditions represents a non-negligible problem, especially for • Interactive applications where the packet transmission interval easily exceeds the Active Route Timeout of AODV (testbed and simulations) • Networks with certain level of dynamics and/or mobility (simulation)
Summary of results - II • In the paper we propose mechanisms to remove the race conditions with “Proxy RREPs”: • By making SNs aware of gateways • Breakdown: When 2 SNs communicate with same XH over different gateways • Although results are targeted at NAT-based gateways, they also have relevance to MIP-FA based solution • We proposed a way to avoid race conditions with Proxy RREPs • However, the problem remains due to ingress filtering • Conclusion: Using proxy RREPs is NOT the way to go! • At least not for NAT-based gateways
Proposed working solution External Host • SN discovers that XH is not present locally after unsuccessful route establishment on MANET • SN sets a “Gateway bit” in RREQ for XH • Gateways responds with a RREP establishing route to the GW (i.e. no race conditions will occur) • RREP contains extensions with • XH’s destination IP address • The functionality/capabilities of the gateway • SN tunnels traffic to selected GW • GW decapsulates and forwards to XH • GW tunnels return traffic from XH to SN • This is necessary due to specifics in the AODV specification Internet src=SNdst=XH IP-payload Inner IP-header GW2(NAT) GW1(NAT) src=SNdst=GW1 src=SNdst=XH IP-payload Intermediate Node Outer IP-header Inner IP-header MANET Source Node RREQ: Route RequestRREP: Route ReplyXH: External HostSN: Source Node