Name Based Net Architectures


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Does the paper answer the question?
  • It does satisfy the requirement of their suitable IA
  • Lots of problems with what the Internet is tuned to do today DNS is rather static
  • WHAT, not WHERE! You don’t often know WHERE, but you always know WHAT you want!
  • One of the cornerstones of N21 is a new naming system. Intentional names --> express WHAT you want Names are descriptions; names are queries
  • What are some key features of the world I just described? - Lots of heterogeneity - Much higher levels of dynamism than today - Much more decentralized and needs much more robustness - allow for tetherless operation
  • Name Based Net Architectures

    1. 1. Network Architecture (R02) Name Based Nets? Jon Crowcroft, http://www. cl
    2. 2. Shoch’s Mnemonic Mantra <ul><li>Name - what it is </li></ul><ul><ul><li>Readable/semantics/organisation </li></ul></ul><ul><ul><li>Attributed…x.500 & INS & DNS Service Name </li></ul></ul><ul><li>Address - where “it” is </li></ul><ul><ul><li>Identity perhaps </li></ul></ul><ul><ul><li>Location hints perhaps </li></ul></ul><ul><li>Route - how to get to it </li></ul><ul><ul><li>Consult a map </li></ul></ul><ul><ul><li>(Build a map?) </li></ul></ul><ul><li>Name-address binding - resolvers </li></ul><ul><li>Address-route binding - forwarders </li></ul>
    3. 3. Addresses <ul><li>Pure location = last component in route </li></ul><ul><li>Hierarchy = loose source route </li></ul><ul><li>Identifier != address ( == name) </li></ul><ul><li>IP addresses are a mix </li></ul><ul><ul><li>Interface </li></ul></ul><ul><ul><li>Prefix matching - distributed hierarchy! </li></ul></ul>
    4. 4. Multicast/Anycast “addresses” <ul><li>Are really names </li></ul><ul><li>You can tell because you need to bind </li></ul><ul><li>Late binding… </li></ul>
    5. 5. Mobility & Address Re-Use <ul><li>If we run out of address space: </li></ul><ul><li>Look at usage in space & time </li></ul><ul><li>Re-use of addresses when hosts not active </li></ul><ul><li>Re-allocation of addresses to where more use </li></ul><ul><li>Can do by updating routing or… </li></ul><ul><li>Non global addresses +state </li></ul>
    6. 6. Where can we update things <ul><li>DNS Name -> </li></ul><ul><ul><li>Local addr + NAT + Dyn DNS </li></ul></ul><ul><li>IP Address -> </li></ul><ul><ul><li>See later (xxx) </li></ul></ul><ul><li>Lower layer label… </li></ul><ul><ul><li>Label switching </li></ul></ul><ul><li>All need state in the net somewhere </li></ul><ul><ul><li>NAT, router or switch, respectively) </li></ul></ul>
    7. 7. Bug in internet <ul><li>Transport uses IP address as part of “end” state - includes routing hint! </li></ul><ul><li>Many mobility (and multipath) hacks to hide this mistake! </li></ul>
    8. 8. Mobile => State Update <ul><li>Whether you do it with name/addr, route inject, or label, </li></ul><ul><li>If you move, then </li></ul><ul><ul><li>other end has to know, and </li></ul></ul><ul><ul><li>New peers have to know, or </li></ul></ul><ul><ul><li>Someone has to proxy for you in your old place -> triangular routing (bad) </li></ul></ul><ul><li>Big problem is update procedure </li></ul><ul><ul><li>Workload </li></ul></ul><ul><ul><li>Security! </li></ul></ul>
    9. 9. Cellular (GPRS, 3G etc) Data <ul><li>Is below IP for now </li></ul><ul><li>So you don’t see this, but </li></ul><ul><li>Does manage device location, and then either </li></ul><ul><ul><li>Routeable addr for active device </li></ul></ul><ul><ul><li>NAT </li></ul></ul><ul><ul><li>Re-do adress and rely on phone being only client (and HTTP level recovery - standard in most web 2.0 systems) </li></ul></ul><ul><ul><li>Big problems if you want to be “always on” for data. </li></ul></ul>
    10. 10. What breaks if we update our IP? <ul><li>See 8+8 and LISP </li></ul><ul><ul><li>Need to update routes </li></ul></ul><ul><ul><li>Need other end of live transport session to know </li></ul></ul><ul><ul><li>Need DNS entry to reflect this…so new peers can reach us at new place </li></ul></ul><ul><li>Both route update and DNS update might take time….so </li></ul><ul><ul><li>Need help during hysteresis (temporary triangle) </li></ul></ul><ul><ul><li>May be gap during which some new peers can’t reach us… </li></ul></ul><ul><ul><li>Both route&dns update may take time if securely done (e.g. if ID Is allocated via HIP) </li></ul></ul>
    11. 11. My crazy idea <ul><li>Address swapping </li></ul><ul><li>In a really big system, there are as many pople moving from A to B as from B to A over sufficient time scale (e.g on roads) </li></ul><ul><li>So why not swap addresses? </li></ul><ul><ul><li>And use the people you swapped addresses with as “care of” for temporary triangles during handover </li></ul></ul><ul><ul><li>While you tell the other end </li></ul></ul><ul><li>What happens when both ends do this? </li></ul>
    12. 12. For static systems sometimes need a transparent choice <ul><li>Load balancers or DDoS avoidance </li></ul><ul><ul><li>Replicated Services </li></ul></ul><ul><ul><li>Migrating Services </li></ul></ul><ul><li>Lots of the techniques give hint on how to do mobile, and how not to! </li></ul>
    13. 13. Global Server Load Balancing Dima Krioukov [ [email_address] .com] Alex Kit [ [email_address] .com] October 24, 2000
    14. 14. Purpose <ul><li>Existing methods </li></ul><ul><li>New technique </li></ul><ul><li>Analysis </li></ul><ul><li>Applicability considerations </li></ul>
    15. 15. Plan <ul><li>Introduction </li></ul><ul><ul><li>What are ASPs? </li></ul></ul><ul><ul><li>Requirements to IDCs </li></ul></ul><ul><li>LSLB </li></ul><ul><ul><li>Load Sharing NAT (LSNAT) </li></ul></ul><ul><ul><li>Direct Server Return (DSR) </li></ul></ul><ul><ul><li>Tunneling </li></ul></ul><ul><li>GSLB </li></ul><ul><ul><li>DNS Based </li></ul></ul><ul><ul><li>Host Route Injection (HRI) </li></ul></ul><ul><ul><li>Triangle Data Flow (TDF) </li></ul></ul><ul><ul><li>Latest Trends </li></ul></ul><ul><li>New Technique – Virtual Block Injection (VBI) </li></ul><ul><ul><li>Description </li></ul></ul><ul><ul><li>Testing </li></ul></ul><ul><ul><li>Analysis </li></ul></ul><ul><li>Applicability Considerations </li></ul><ul><li>Conclusions and References </li></ul>
    16. 16. Abbreviations <ul><li>LB = Load Balancing/Balancer </li></ul><ul><li>SLB = Server LB </li></ul><ul><li>LSLB = Local SLB </li></ul><ul><li>GSLB = Global SLB </li></ul><ul><li>HA = High Availability </li></ul><ul><li>RS = Real Server/Service </li></ul><ul><li>VS = Virtual Server/Service </li></ul><ul><li>VIP = VS IP address </li></ul><ul><li>LSNAT = Load Sharing NAT </li></ul><ul><li>DSR = Direct Server Return </li></ul><ul><li>PRP = Proximity Report Protocol </li></ul><ul><li>LRP = Load Report Protocol </li></ul><ul><li>LPRP = PRP + LRP </li></ul><ul><li>HRI = Host Route Injection </li></ul><ul><li>VBI = Virtual Block Injection </li></ul><ul><li>TDF = Triangle Data Flow </li></ul><ul><li>IDC = Internet Data Center </li></ul><ul><li>CDN = Content Delivery Network </li></ul><ul><li>ASP = Application Service Provider </li></ul><ul><li>CASP = Content/Collocation and Application Service Provider </li></ul><ul><li>AIP = Application Infrastructure Provider </li></ul><ul><li>xyP = ? </li></ul>
    17. 17. 1. Introduction <ul><li>Logic: GSLB  IDC  ASP  Hosting </li></ul>
    18. 18. Hosting Infrastructure Web User Content Owner IDC Owner ISP OSS
    19. 19. ASP Infrastructure End Customer ASP Applications Operations ISP/Backbone Access IDC
    20. 20. IDC IDC Core (Routing) Distribution (L3 Switching) Tier Tier Tier LB Tier Load Balancing (L4 Switching) Port Density (L2 Switching) Servers SAN
    21. 21. Requirements to IDCs <ul><li>Load Balancing (LB) </li></ul><ul><li>Local </li></ul><ul><li>Global </li></ul><ul><li>Local </li></ul><ul><li>Global </li></ul><ul><li>Proximity (“including” congestion) </li></ul><ul><li>Load </li></ul><ul><li>High Availability (HA) </li></ul>IDC1 IDC2 Client HA  LB
    22. 22. 2. Generic SLB and LSLB <ul><li>SLB = VS  RS </li></ul><ul><li>Health Checking </li></ul><ul><ul><li>Layer 2 </li></ul></ul><ul><ul><li>Layer 3 </li></ul></ul><ul><ul><li>Layer 4 </li></ul></ul><ul><ul><li>Layer 7 </li></ul></ul><ul><li>SLB Algorithm </li></ul><ul><ul><li>Round Robin </li></ul></ul><ul><ul><li>Least Connections </li></ul></ul><ul><ul><li>Server Response Time </li></ul></ul><ul><ul><li>Server Load </li></ul></ul><ul><ul><li>Hashing </li></ul></ul><ul><li>SLB Forwarding </li></ul><ul><ul><li>Session Tables </li></ul></ul><ul><ul><li>Timers </li></ul></ul>
    23. 23. LSLB Forwarding <ul><li>LSNAT </li></ul><ul><li>DSR </li></ul><ul><li>Tunneling </li></ul>
    24. 24. LSNAT Router LB S1 S2 S3 X Y src/ dst Layer Ingress Client_Port S1_Port dst Client_IP S1_IP dst LB_MAC S1_MAC dst Client_Port Virtual_Port dst Client_IP Virtual_IP dst dst Router_MAC Virtual_MAC Client_Port Client_IP LB_MAC Client_Port Client_IP Router_MAC S1_IP src L3 src src src src src Virtual_IP L3 S1_Port L4 Virtual_Port L4 S1_MAC L2 Y Virtual_MAC L2 X Egress Segment
    25. 25. LSNAT + Source NAT Router LB S1 S2 S3 X Y src/ dst Layer Ingress LB_V_Port S1_Port dst LB_V_IP S1_IP dst LB_V_MAC S1_MAC dst Client_Port Virtual_Port dst Client_IP Virtual_IP dst dst Router_MAC Virtual_MAC LB_V_Port LB_V_IP LB_V_MAC Client_Port Client_IP Router_MAC S1_IP src L3 src src src src src Virtual_IP L3 S1_Port L4 Virtual_Port L4 S1_MAC L2 Y Virtual_MAC L2 X Egress Segment
    26. 26. DSR Router LB S1 S2 S3 1 2 3 Virtual_Port Client_Port Virtual_IP Client_IP S1_MAC Virtual_MAC 2 Client_Port Virtual_Port Client_IP Virtual_IP Router_MAC S1_MAC 3 src/ dst Layer 1 Virtual_Port dst Virtual_IP dst dst Virtual_MAC Client_Port Client_IP Router_MAC src src src L3 L4 L2
    27. 27. Tunneling Router LB S1 S2 S3 1 2 3 Int: V_IP Int: C_IP V_Port C_Port Ext: S1_IP Ext: LB_IP S1_MAC LB_MAC 2 C_Port V_Port C_IP V_IP R_MAC S1_MAC 3 src/ dst Layer 1 V_Port dst V_IP dst dst V_MAC C_Port C_IP R_MAC src src src L3 L4 L2
    28. 28. 3. GSLB <ul><li>DNS Based </li></ul><ul><li>HRI </li></ul><ul><li>TDF </li></ul><ul><li>Latest Trends </li></ul>
    29. 29. 3.1 DNS Based <ul><li>GSLB = Name  VS (DNS+) </li></ul><ul><li>Smart DNS </li></ul><ul><ul><li>Load and availability awareness  Load Report Protocol (LRP) </li></ul></ul><ul><ul><li>Proximity and congestion awareness  Proximity Report Protocol (PRP) </li></ul></ul><ul><li>LB DNS Functionality </li></ul><ul><ul><li>DNS Server </li></ul></ul><ul><ul><li>DNS Proxy </li></ul></ul><ul><ul><ul><li>Caching </li></ul></ul></ul><ul><ul><li>DNS Traffic Intercept </li></ul></ul>
    30. 30. LPRP <ul><li>Transport </li></ul><ul><ul><li>UDP </li></ul></ul><ul><ul><li>TCP </li></ul></ul><ul><ul><li>HTTP </li></ul></ul><ul><li>Operation </li></ul><ul><ul><li>Periodic Updates </li></ul></ul><ul><ul><li>Periodic Requests </li></ul></ul><ul><ul><li>Triggered Updates </li></ul></ul>IDC1 LB IDC2 LB IDC3 LB
    31. 31. PRP <ul><li>RTT </li></ul><ul><li>Effective bandwidth </li></ul><ul><li>Number of hops </li></ul><ul><li>Number of AS hops </li></ul><ul><li>IGP metric </li></ul>Proximity to the client LDNS, not to the client
    32. 32. LRP <ul><li>VS Health </li></ul><ul><ul><li>Up </li></ul></ul><ul><ul><li>Down </li></ul></ul><ul><ul><li>Backup only </li></ul></ul><ul><li>VS Load </li></ul><ul><ul><li>Number of sessions </li></ul></ul><ul><ul><li>Response Time </li></ul></ul><ul><li>LB Load </li></ul><ul><ul><li>Number of sessions </li></ul></ul><ul><ul><li>Capacity threshold </li></ul></ul><ul><ul><li>CPU </li></ul></ul><ul><li>RS/Content Load </li></ul><ul><li>Network Load </li></ul><ul><ul><li>bps </li></ul></ul><ul><ul><li>pps </li></ul></ul><ul><li>QoS </li></ul><ul><li>Security </li></ul>
    33. 33. How it works IDC1 IDC2 LB IDC3 LB Customer LDNS ADNS Client RDNS 1 2 3 4 5 5 6 6 6
    34. 34. How it works IDC1 IDC2 LB IDC3 LB Customer LDNS ADNS Client RDNS 7 7 8 10 11 9
    35. 35. Analysis <ul><li>Pros </li></ul><ul><li>Accurate load info </li></ul><ul><li>Accurate proximity info </li></ul><ul><li>Perfect solution… in some cases and if certain conditions are met </li></ul><ul><li>Cons </li></ul><ul><li>DNS – wrong target </li></ul><ul><li>Proximity between client and its LDNS </li></ul><ul><li>Caching </li></ul><ul><ul><li>LB </li></ul></ul><ul><ul><li>LDNS </li></ul></ul><ul><ul><li>Application </li></ul></ul><ul><li>Complexity </li></ul><ul><li>Hard to find optimal values for various timers (TTL, cache timeouts, etc.) and prefix lengths </li></ul>
    36. 36. 3.2 HRI <ul><li>GSLB = Routing+ </li></ul><ul><li>To what? </li></ul><ul><ul><li>BGP </li></ul></ul><ul><ul><li>IGP </li></ul></ul><ul><li>By what? </li></ul><ul><ul><li>RS </li></ul></ul><ul><ul><li>Router </li></ul></ul><ul><ul><li>LB </li></ul></ul>
    37. 37. To what <ul><li>IGP? </li></ul><ul><li>BGP </li></ul><ul><ul><li>Route filtering (both ways) </li></ul></ul><ul><ul><li>No ECMP </li></ul></ul>Client Router IDC1 IDC2
    38. 38. By what <ul><li>RS </li></ul>IDC1 Router RS BGP IDC2 Router RS BGP
    39. 39. By what <ul><li>Router </li></ul>IDC1 Router RS IDC2 Router RS RS LB
    40. 40. By what <ul><li>LB </li></ul>IDC2 Router RS RS LB IDC1 Router RS RS LB BGP BGP
    41. 41. Analysis <ul><li>Pros </li></ul><ul><li>Simplicity </li></ul><ul><li>No new protocols are needed </li></ul><ul><li>Proximity is handled by routing </li></ul><ul><li>Load handling? </li></ul><ul><li>Cons </li></ul><ul><li>Single backbone* </li></ul><ul><ul><li>Its own </li></ul></ul><ul><ul><li>Single ISP </li></ul></ul><ul><li>Too many routes </li></ul><ul><li>Less accurate load and proximity info </li></ul><ul><ul><li>Only local load </li></ul></ul><ul><ul><li>Optimal routing? </li></ul></ul><ul><li>Route flapping* </li></ul>
    42. 42. 3.3 TDF <ul><li>GSLB = X + TDF </li></ul><ul><li>NAT Based </li></ul><ul><li>Tunneling </li></ul>Client IDC1, “ wrong” IDC2, “ right”
    43. 43. Why “wrong” IDC? <ul><li>Failure of, disabled or non-implemented LPRP </li></ul><ul><li>Cached DNS records </li></ul><ul><li>Other retardation effects (LPRP, BGP) </li></ul>
    44. 44. NAT Based Client IDC1, “ wrong” V1.1; V1.2 IDC2, “ right” V2.1; V2.2 3 2 1 1 V1.1 C C V2.2 dst V1.1 C src L3 3 2
    45. 45. “ Remote Servers” Client IDC1, “ wrong” V1.1 IDC2, “ right” V2.1 2 1 C V1.1 4 1 V1.1 C V1.1 V2.1 dst V2.1 V1.1 src L3 3 2 3 4
    46. 46. Tunneling <ul><li>Next section </li></ul>
    47. 47. Analysis <ul><li>Pros </li></ul><ul><li>Fixes errors optimally </li></ul><ul><li>Cons </li></ul><ul><li>ip verify reverse-path </li></ul>Client Router Router IDC1, “ wrong” IDC2, “ right”
    48. 48. Analysis <ul><li>Pros </li></ul><ul><li>Fixes errors optimally </li></ul><ul><li>Cons </li></ul><ul><li>ip verify reverse-path </li></ul>Client Router Router IDC1, “ wrong” IDC2, “ right”
    49. 49. 3.4 Latest Trends, Radicalism <ul><li>Internet infiltration </li></ul><ul><li>Going to the client edge </li></ul><ul><li>Going to the client </li></ul><ul><li>Modifying the client </li></ul><ul><li>LB presence in strategic locations (HydraGPS, Speedera) </li></ul><ul><li>LDNS modifications (Speedera) </li></ul><ul><li>Application modifications (SRV RRs) </li></ul>
    50. 50. Internet Infiltrations IDC2 LB IDC1 LB Customer LB LB LB Client LB LB LB
    51. 51. Internet Infiltrations IDC2 LB IDC1 LB Customer LB LB LB Client LB LB
    52. 52. LDNS modifications in CDNs IDC2 LB IDC1 LB Customer LDNS Client ASP Backbone
    53. 53. 4. Virtual Block Injection (VBI) <ul><li>Inject not VS host routes, but blocks of GSLB’ed VSs  IDC (LB) failures are handled by the routing protocol </li></ul><ul><li>Use tunneling TDF in case of individual VS failure </li></ul>
    54. 54. How it works AS1 AS2 V/20, AS3 V/20, AS3 Client ISP1 ISP2 IDC1, R1/20 IDC2, R2/20
    55. 55. How it works AS1 AS2 V/20, AS3 Client ISP1 ISP2 IDC1, R1/20 IDC2, R2/20
    56. 56. How it works AS1 AS2 V/20, AS3 V/20, AS3 Client ISP1 ISP2 IDC1, R1/20 IDC2, R2/20
    57. 57. Testing <ul><li>Needed </li></ul><ul><li>LB </li></ul><ul><li>BGP </li></ul><ul><li>Tunnels </li></ul><ul><li>Linux </li></ul><ul><li>Linux Virtual Server (LVS, Wensong Zhang, Julian Anastasov) </li></ul><ul><li>Zebra </li></ul><ul><li>Tunnels </li></ul>
    58. 58. Test Network
    59. 59. Analysis <ul><li>Pros </li></ul><ul><li>All of HRI, plus </li></ul><ul><li>No host route injection </li></ul><ul><li>Working TDF </li></ul><ul><li>Perfect VS health handling </li></ul><ul><li>VS load  LRP </li></ul><ul><li>Obvious simplifications in more “ideal” cases </li></ul><ul><li>Cons </li></ul><ul><li>LB load  stop advertisement? </li></ul><ul><li>BGP – proximity tool? </li></ul><ul><li>Discontinuous AS? </li></ul><ul><li>Route flapping! </li></ul>
    60. 60. Route Flapping AS1 AS2 V/20, AS3 V/20, AS3 Client Router ISP1 ISP2 IDC1, R1/20 IDC2, R2/20 UDP TCP
    61. 61. Solution for UDP <ul><li>Session table entry exchange for long sessions </li></ul>AS1 AS2 V/20, AS3 V/20, AS3 Client Router ISP1 ISP2 IDC1, R1/20 IDC2, R2/20
    62. 62. Solution for UDP <ul><li>Session table entry exchange for long sessions </li></ul>AS1 AS2 V/20, AS3 V/20, AS3 Client Router ISP1 ISP2 IDC1, R1/20 IDC2, R2/20
    63. 63. Solution for TCP <ul><li>If LB receives packet </li></ul><ul><li>Destined to a VS </li></ul><ul><li>No SYN </li></ul><ul><li>No session table entry </li></ul><ul><li>Not via the tunnels </li></ul><ul><li>Forward via all the tunnels </li></ul>AS1 AS2 V/20, AS3 V/20, AS3 Client Router ISP1 ISP2 IDC1, R1/20 IDC2, R2/20
    64. 64. 5. Applicability Considerations <ul><li>GSLB of </li></ul><ul><li>Small number of VSs (or RSs) </li></ul><ul><ul><li>by an ISP* </li></ul></ul><ul><ul><li>by its customer </li></ul></ul><ul><li>Big number of VSs (between IDCs) </li></ul><ul><ul><li>CASP  ISP </li></ul></ul><ul><ul><li>CASP  ISP </li></ul></ul><ul><ul><ul><li>CASP has its own backbone </li></ul></ul></ul><ul><ul><ul><ul><li>CASP does not have control over customer access </li></ul></ul></ul></ul><ul><ul><ul><ul><li>CASP has control over customer access** </li></ul></ul></ul></ul><ul><ul><ul><li>CASP does not have its own backbone </li></ul></ul></ul><ul><ul><ul><ul><li>CASP is multihomed to the same ISP </li></ul></ul></ul></ul><ul><ul><ul><ul><li>CASP is multihomed to different ISPs* </li></ul></ul></ul></ul>
    65. 65. 6. Conclusions <ul><li>No ideal GSLB method </li></ul><ul><li>For some “ideal” network scenarios, there are some “ideal” solutions </li></ul><ul><li>For realistic network scenarios, there are rapidly improving realistic solutions </li></ul><ul><li>Good competition </li></ul><ul><li>Lack of comparative testing in the production-like environment </li></ul>
    66. 66. References <ul><li>On ASPs: Nortel , ASP Industry Consortium , Network Magazine , IRG </li></ul><ul><li>Vendors: Alteon , ArrowPoint , Foundry , F5 , Cisco , Nortel , Radware , HydraWEB , Speedera , Resonate </li></ul><ul><li>RFCs: LSNAT , SRV , DNS for LB , SLB draft (work in progress) </li></ul><ul><li>Open Source: LVS, </li></ul><ul><li>VBI Testing: </li></ul>
    67. 67. IPNL: A NAT-Extended Internet Architecture Paul Francis Tahoe Network Remakrishna Gummadi UC Berkeley
    68. 68. About title <ul><li>Suitable IA </li></ul><ul><li>Improving IPv4’s </li></ul><ul><ul><li>scalability </li></ul></ul><ul><ul><li>size </li></ul></ul><ul><li>Keeping its property </li></ul><ul><ul><li>Long-lived addresses,Robustness-statelessness, Address independence, Packet hijacking resistance </li></ul></ul><ul><li>Extension of NAT </li></ul><ul><li>Modify only hosts and NAT boxes </li></ul>
    69. 69. Answer Question <ul><li>Some extension of NAT </li></ul><ul><li>Suitable Internet Architecture </li></ul><ul><li> </li></ul>?
    70. 70. Outline <ul><li>IPNL basics </li></ul><ul><li>Key attributes of IPNL </li></ul><ul><li>Review question </li></ul><ul><li>Other works </li></ul><ul><li>Comparison with IPv6 </li></ul><ul><li>Discussion </li></ul>
    71. 71. Basic(0)--NAT <ul><li>Network address translation </li></ul><ul><li>Advantages </li></ul><ul><ul><li>Connect private network </li></ul></ul><ul><ul><li>Isolate private network </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Unaddressable hosts </li></ul></ul>
    72. 72. Basics(1)--concepts <ul><li>Topology </li></ul><ul><li>Terminologies </li></ul><ul><li>FQDN, MRIP, RN, EHIP </li></ul><ul><li>Addresses </li></ul><ul><ul><li>FQDN, </li></ul></ul><ul><ul><li>IPNL address </li></ul></ul><ul><ul><ul><li>Local IP, Global IP(composed of MRIP, RN, EHIP) </li></ul></ul></ul><ul><li>IPNL Header next… </li></ul>internal nl-router Global private private frontdoor private EHIP RN MRIP
    73. 73. Terms <ul><li>FQDN </li></ul><ul><li>Realm Number </li></ul><ul><li>Middle Realm </li></ul><ul><li>End Host ID/IP </li></ul><ul><li>Fully qualified Domain Name - DNS </li></ul><ul><li>New thing (AS)? </li></ul><ul><li>Realm based IP? </li></ul><ul><li>Now Real specific (like non routeable Ips) </li></ul>
    74. 74. Basics(2)--routing IPNL Header Optional FQDN header (variable) Optional global header (16) Local header (24)
    75. 75. Basic(2)--routing <ul><li>Knowledge of IPNL host & routers </li></ul>HOST: (1)FQDN & EHIP (2)one or more nl-routers Internal nl-router: (1)its neighbors (2)FQDN, IP pair list (3)Routing information Frontdoor: Entry for all realms behind it
    76. 76. Example1: Routing by FQDN
    77. 77. Example2: Routing by IPNL addresses DestAddress: M3:R6:H3
    78. 78. Key attributes of IPNL <ul><li>Reuse existing infrastructure </li></ul><ul><li>Utilize FQDN </li></ul><ul><li>Extend IP address space </li></ul><ul><li>Isolate site addressing </li></ul><ul><ul><li>Separate local and global header </li></ul></ul><ul><ul><li>Realm number independence </li></ul></ul><ul><ul><li>In-flight IPNL address resolution </li></ul></ul><ul><ul><li>Location </li></ul></ul>MRIP RN EHIP
    79. 79. Experiment <ul><li>Testbed </li></ul><ul><ul><li>“ netperf” benchmark </li></ul></ul><ul><li>Result </li></ul><ul><ul><li>Good! No degradation of throughput at all </li></ul></ul><ul><ul><li>Latency associated with failure connection depends on routes refresh frequency </li></ul></ul>
    80. 80. Testbed
    81. 81. Review question <ul><li>Maintain characteristics of IPv4 </li></ul><ul><ul><li>Long-lived addresses </li></ul></ul><ul><ul><li>Robustness </li></ul></ul><ul><ul><li>Address independence </li></ul></ul><ul><ul><li>Packet hijacking resistance </li></ul></ul><ul><li>Solve </li></ul><ul><ul><li>Scalability </li></ul></ul><ul><ul><li>Address depletion </li></ul></ul>     
    82. 82. NICE
    83. 83. Other works <ul><li>AVES </li></ul><ul><ul><li>“ A waypoint service approach to connect heterogeneous internet address space” by Eugene Ng, Ion Stoica, Hui Zhang (CMU) </li></ul></ul><ul><li>TRIAD </li></ul><ul><ul><li>By D.R. Cheriton, M. Gritter(stanford) </li></ul></ul><ul><li>IPv6 </li></ul>
    84. 84. Comparisons with IPv6 <ul><li>IPNL </li></ul><ul><li>Completely isolate sites </li></ul><ul><li>Less expensive </li></ul><ul><li>Simpler transition </li></ul><ul><li>Easier security administration </li></ul><ul><li>IPv6pure </li></ul><ul><li>Less Header rewriting </li></ul><ul><li>Simpler auto-address configuration </li></ul>Advantages disappear in IPv6on4 env
    85. 85. Discussions <ul><li>EHIP 4 Byte? </li></ul><ul><li>Too long header? </li></ul><ul><li>Complexity analysis of IPNL? </li></ul><ul><ul><li>Routing algorithm </li></ul></ul><ul><li>Experiment convincing? </li></ul><ul><li>Does IPNL have a bright future? </li></ul><ul><li>Quality of the paper? </li></ul>
    86. 86. Resource Discovery Using an Intentional Naming System Hari Balakrishnan MIT Lab for Computer Science [email_address] With: William Adjie-Winoto, Elliot Schwartz, Jeremy Lilley, Anit Chakraborty
    87. 87. Application: Location-dependent wireless services <ul><li>Access, control services, communicate with them </li></ul><ul><li>Handle mobility & group communication </li></ul>App should be able to conveniently specify a resource and access it <ul><li>Spontaneous networking </li></ul><ul><li>Locate other useful services (e.g., nearest café) </li></ul>Where? <ul><li>Automatically obtain map of region & discover devices, services and people there </li></ul>
    88. 88. Challenges <ul><li>Configuration </li></ul><ul><li>Routing </li></ul><ul><li>Discovery </li></ul><ul><li>Adaptation </li></ul><ul><li>Security & privacy </li></ul>Dynamic, mobile environment with no pre-configured support for internetworking or service location
    89. 89. Today <ul><li>Mostly static topology & services </li></ul><ul><li>Deploying new services cumbersome </li></ul><ul><li>Applications cannot learn about network </li></ul><ul><li>Failures are common! </li></ul><ul><li>High management cost </li></ul>Routers Servers Clients DNS Hostname Address
    90. 90. Ad hoc configuration <ul><li>Static configuration impossible </li></ul><ul><li>DHCP-like configuration undesirable </li></ul><ul><ul><li>Over wireless, pre-configured subnetworks and broadcasts problematic </li></ul></ul><ul><li>Solution: Distributed, randomized address assignment </li></ul>addr = a r mask = m r addr = b r mask = m r addr = c r mask = n Coalesce? Route? [a r :m r ]
    91. 91. Resource discovery <ul><li>Why is this hard? </li></ul><ul><ul><li>Dynamic environment (mobility, performance changes, etc.) </li></ul></ul><ul><ul><li>No pre-configured support, no centralized servers </li></ul></ul><ul><ul><li>Must be easy to deploy (“ZERO” manual configuration) </li></ul></ul><ul><ul><li>Heterogeneous services & devices </li></ul></ul><ul><li>Approach: a new naming system & resolution architecture </li></ul>
    92. 92. Design goals <ul><li>Names must be descriptive, signifying application intent </li></ul>Responsiveness Name resolvers must track rapid changes Robustness System must overcome resolver and service failure Easy configuration Name resolvers must self-configure Expressiveness
    93. 93. Intentional Naming System (INS) principles <ul><li>Names are intentional , based on attributes </li></ul><ul><ul><li>Apps know WHAT they want, not WHERE </li></ul></ul><ul><li>INS integrates resolution and forwarding </li></ul><ul><ul><li>Late binding of names to nodes </li></ul></ul><ul><li>INS resolvers replicate and cooperate </li></ul><ul><ul><li>Soft-state name exchange protocol with periodic refreshes </li></ul></ul><ul><li>INS resolvers self-configure </li></ul><ul><ul><li>Form an application-level overlay network </li></ul></ul>
    94. 94. INS architecture overview <ul><li>Intentional Name Resolvers (INR) form a distributed overlay </li></ul>Integrate resolution and message routing image Lookup INR self-configuration <ul><li>[building = ne-43 </li></ul><ul><ul><li>[room = 510]] </li></ul></ul><ul><li>[entity = camera] </li></ul>Intentional name
    95. 95. How does it work? INR DSR Virtual space partitions Domain Space Resolvers Scaling? Application-level overlay network formed based on performance Inter-domain information via DSR protocol Exchange names as if they were routes
    96. 96. INS service model INR application Early binding Late binding query Intentional anycast Intentional multicast Application-level routing using intentional names Self-configuring app-level overlay network formed based on performance Soft-state name dissemination set of names
    97. 97. What’s in a name? <ul><li>Names are queries </li></ul><ul><ul><li>Attribute-value matches </li></ul></ul><ul><ul><li>Range queries </li></ul></ul><ul><ul><li>Wildcard matches </li></ul></ul><ul><li>Expressive name language (like XML) </li></ul><ul><li>Resolver architecture decoupled from language </li></ul><ul><li>[vspace = thermometer] </li></ul><ul><li>[building = ne-43 </li></ul><ul><ul><li>[room = *]] </li></ul></ul><ul><li>[temperature < 62 0 F] </li></ul>data [vspace = netgroup] [department = arch-lab [state = oregon [city = hillsboro]]] [rank = admin] data <ul><li>[vspace = camera] </li></ul><ul><li>[building = ne-43 </li></ul><ul><ul><li>[room = 504]] </li></ul></ul><ul><li>[resolution=800x600]] </li></ul><ul><li>[access = public] </li></ul><ul><li>[status = ready] </li></ul><ul><li>Names are descriptive </li></ul><ul><ul><li>Providers announce names </li></ul></ul>
    98. 98. Responsiveness: Late binding <ul><li>Mapping from name to location(s) can change rapidly </li></ul><ul><li>Integrate resolution and message routing to track change </li></ul><ul><ul><li>INR resolves name by lookup-and-forward, not by returning address </li></ul></ul><ul><ul><li>lookup(name) is a route </li></ul></ul><ul><ul><li>Forward along route </li></ul></ul><ul><li>A name can map to one location (“anycast”) or to many (“multicast”) </li></ul>
    99. 99. Late binding services <ul><li>Intentional anycast </li></ul><ul><ul><li>INR picks one of several possible locations </li></ul></ul><ul><ul><li>Choice based on service-controlled metric [contrast with IP anycast] </li></ul></ul><ul><ul><li>Overlay used to exchange name-routes </li></ul></ul><ul><li>Intentional multicast </li></ul><ul><ul><li>INR picks all overlay neighbors that “express interest” in name </li></ul></ul><ul><ul><li>Message flows along spanning tree </li></ul></ul><ul><ul><li>Overlay used to transfer data too </li></ul></ul>
    100. 100. Robustness: Names as soft-state <ul><li>Resolution via network of replicated resolvers </li></ul><ul><li>Names are weakly consistent, like network-layer routes </li></ul><ul><ul><li>Routing protocol to exchange names </li></ul></ul><ul><li>Fate sharing with services, not INRs </li></ul><ul><ul><li>Name unresolved only if service absent </li></ul></ul><ul><li>Soft-state with expiration is robust against service/client failure </li></ul><ul><ul><li>No need for explicit de-registration </li></ul></ul>
    101. 101. Self-configuring resolvers <ul><li>INRs configure using a distributed topology formation protocol </li></ul><ul><li>DSR (DNS++) maintains list of candidate and active INRs </li></ul><ul><li>INR-to-INR “ping” experiments for “link weights” </li></ul><ul><li>Current implementation forms (evolving) spanning tree </li></ul><ul><li>INRs self-terminate if load is low </li></ul>
    102. 102. Efficient name lookups <ul><li>Data structure </li></ul><ul><li>Lookup </li></ul><ul><ul><li>AND operations among orthogonal attributes </li></ul></ul><ul><ul><li>For values pick the value(s) satisfying the lookup </li></ul></ul><ul><li>Polynomial-time in worst case </li></ul>
    103. 103. Scaling issues <ul><li>Two potential problems </li></ul><ul><ul><li>Lookup overhead </li></ul></ul><ul><ul><li>Routing protocol overhead </li></ul></ul><ul><li>Load-balancing by spawning new INR handles lookup problem </li></ul><ul><li>Virtual space partitioning handles routing protocol problem </li></ul><ul><ul><li>Just spawning new INR is insufficient </li></ul></ul>
    104. 104. Virtual space partitioning vspace=camera vspace=5th-floor Routing updates for each vspace Delegate this to another INR
    105. 105. INR Implementation Overlay Manager Network Monitor Route Manager Client Manager Forwarder vspace neighbors NameTreeSet Communicator Mobility Sockets TCP/UDP lookup Intentional anycast, multicast Incoming message
    106. 106. Applications <ul><li>Wireless Networks of Devices (WIND) </li></ul><ul><ul><li>Location-dependent mobile applications </li></ul></ul><ul><ul><li>Floorplan: A navigation tool </li></ul></ul><ul><ul><li>Camera: An image/video service </li></ul></ul><ul><ul><li>Printer: A smart print spooler </li></ul></ul><ul><ul><li>TV & jukebox </li></ul></ul><ul><ul><li>Network-independent “instant messaging” </li></ul></ul><ul><ul><li>Location-support system for services and clients to learn location </li></ul></ul>
    107. 107. WIND
    108. 116. Status & performance <ul><li>Java implementation of INS & applications </li></ul><ul><li>PC-based resolver performance </li></ul><ul><ul><li>1 resolver: several thousand names @100-1000 lookups/s </li></ul></ul><ul><ul><li>Discovery time linear in hops </li></ul></ul><ul><li>Scalability </li></ul><ul><ul><li>Virtual space partitions for load-shedding </li></ul></ul><ul><ul><li>Wide-area design in progress </li></ul></ul><ul><li>Deployment </li></ul><ul><ul><li>Hook in wide-area architecture to DNS </li></ul></ul><ul><ul><li>Standardize virtual space names (like MIME) </li></ul></ul><ul><li>Paper at SOSP 17 ( </li></ul>
    109. 117. Related work <ul><li>Domain Name System </li></ul><ul><ul><li>Differences in expressiveness and architecture </li></ul></ul><ul><li>Service Location Protocol </li></ul><ul><ul><li>More centralized, less spontaneous </li></ul></ul><ul><li>Berkeley Service Discovery Service </li></ul><ul><ul><li>Authentication, fixed hierarchies for wide-area </li></ul></ul><ul><li>Jini: </li></ul><ul><ul><li>INS for self-configuring fault-tolerant discovery </li></ul></ul><ul><li>Universal Plug-and-Play & SSDP </li></ul><ul><ul><li>XML-based descriptions; INS fits well </li></ul></ul><ul><li>Intentional names in other contexts </li></ul><ul><ul><li>E.g., Discover query routing, DistributedDirector </li></ul></ul>
    110. 118. Application-Level Networks <ul><li>Increasing number of services that set up application-level overlay networks </li></ul><ul><li>Distributed Web caches </li></ul><ul><li>Replica management systems </li></ul><ul><li>Transcoders </li></ul><ul><li>Multi-party communication </li></ul><ul><li>Naming systems </li></ul><ul><li>Net news </li></ul>
    111. 119. What Do They Have in Common? <ul><li>Form an overlay over IP </li></ul><ul><li>Nodes exchange meta-data information </li></ul><ul><li>Nodes forward messages based on meta-data </li></ul><ul><li>Incorporate configuration machinery </li></ul><ul><li>Fault/crash recovery </li></ul><ul><li>Load balancing </li></ul>
    112. 120. Supporting Application-Level Networks <ul><li>General protocols for meta-data dissemination </li></ul><ul><li>Fault-tolerance primitives </li></ul><ul><li>Self-configuring overlays </li></ul><ul><ul><li>Bootstrap and placement </li></ul></ul><ul><ul><li>Neighbor formation </li></ul></ul><ul><ul><li>Load balancing </li></ul></ul><ul><li>Security and privacy primitives </li></ul>
    113. 121. Future Internet Architecture Flexible IP routers Scheduling, buffer mgmt Use each other to add value Resource management Traffic engineering Congestion Manager Middleware ... Cache & replica management Self-configuring overlays INS Media transcoders Performance discovery Service location Jini UPnP E-speak T-spaces Decentralized security
    114. 122. Conclusion <ul><li>Achieving self-organizing networks requires a flexible naming system for resource discovery </li></ul><ul><ul><li>INS works in dynamic, heterogeneous networks </li></ul></ul><ul><ul><li>Expressiveness: names convey intent </li></ul></ul><ul><ul><li>Responsiveness: late binding </li></ul></ul><ul><ul><li>Robustness: soft-state name dissemination </li></ul></ul><ul><ul><li>Configuration: Resolvers self-configure </li></ul></ul><ul><li>Application-level overlay networks are a good way to build flexible, self-organizing network applications </li></ul>
    115. 123. For next week (Tuesday 27th oct) <ul><li>I want each of you to read about location/identifier split proposals in the Internet community (e.g. LISP) </li></ul><ul><li>And come up with </li></ul><ul><ul><li>What do they solve </li></ul></ul><ul><ul><li>What do they not solve… </li></ul></ul><ul><ul><li>And email me 1 slide with that on! </li></ul></ul><ul><ul><li>Which YOU will present! </li></ul></ul><ul><li>And we will discuss how the desiderata (requirements) changed! </li></ul>