1 / 31

Part I: Core networking concepts

Part I: Core networking concepts. Naming & Addressing. Names and addresses. Names are identifiers Used by end users / applications to interact with your system system components to interact with each other Name operators compare, resolve, bind/un-bind

mina
Download Presentation

Part I: Core networking concepts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Part I: Core networking concepts Naming & Addressing

  2. Names and addresses • Names are identifiers • Used by • end users / applications to interact with your system • system components to interact with each other • Name operators • compare, resolve, bind/un-bind • Addresses: names that locate objects • Good names should be decoupled from addresses

  3. Names or addresses? • NYU ID • /home/jinyang/doc/lec2.ppt • www.nytimes.com • 199.239.137.245 • http://www.nytimes.com/world • 00:18:8B:06:DC:CB • BitTorrent: f22bd0823..c86a5

  4. Addresses

  5. Design considerations • Addresses are used by routers to forward packets to an endpoint • Should be uniquely allocated • Don’t have to be user-friendly • Should enable scalable routing

  6. IP address evolution • Original scheme: • 8-bit net (area) / 24-bit host (intra-area) • Why distinguishing net and host? • Why’s wrong with 8-bit net? • 256 is not enough nets • Most networks don’t have 16 million hosts

  7. Class-based IP address MIT18.*.*.* Apple 17.*.*.* NYU 128.122.*.* Microsoft 207.46.*.*

  8. Forwarding based on class-based address • Examine first 1/2/3 bits, • Perform a lookup according to net #

  9. Class-based --> CIDR • Why not class-based addresses? • Class A is wasteful! • Too many organizations are > C, but < B • Too many entries at routers • CIDR: classless inter-domain routing • Represent net size explicitly 216.239.32.0/19 61.135.0.0/16 • Allocate appropriate size • Allocate hierarchically

  10. Hierarchical allocation At&t 12.0.0.0/8 Sprint Another ISP ISP 12.4.0.0/16 12.4.240.0/20

  11. Forwarding w/ CIDR addresses • Longest prefix match • 12.4.225.69 matches 12.24.225.0/20 instead of 12.0.0.0/8 • Non-trivial • 10-100 millions pkts/sec • Memory latency 5-10 ns

  12. Still not enough IP address? • NAT (Network address Translator) • Maps external address/port pairs to internal address/port pairs • Rewrites src/dst addresses! • NAT breaks • global reachability • Protocols that identify host w/ IP addresses

  13. IPv6 • 128-bit addresses • Different classes of addresses • Hierarchically allocated addresses like CIDR • Lower 64-bits are interface ID • Simplified header format • 40 bytes as opposed to 20 in IPv4

  14. IPv6 deployment options • Embed v4 addresses in low bits of IPv6 • Tunnel IPv6 packets over IPv4 networks • Applications must be dual-stacked or use a v4-to-v6 translator

  15. IPv6 deployment status

  16. Names

  17. Design Considerations • Ensuring uniqueness • Central naming authority • Hierarchical delegation • Pseudo-randomly • Content hashes • Intended audience: humans or machines?

  18. DNS • Why domain names? • IP addresses are not user friendly • Need topology-independent names • Early 80s: hosts.txt file, maps host name  IP • DNS: distributed service, maps domain name  IP • Record types: A, NS, MX, CNAME, PTR …

  19. Deep hierarchy Hierarchical names enable delegation . flat .com .edu .gov .cn .uk .nyu .cs .news www

  20. Query: www.google.com Response: .com NS a.gtld-servers.nett Q: www.google.com R: google.com NS ns1.google.com Q: www.google.com R: www.google.com A 216.239.32.10 Resolving hierarchical names root name server .com name server application cs.nyu.edu DNS server Stub resolver .google.com name server • Root servers might become bottlenecks? • Long latency?

  21. Replicating servers for capacity/availability • Each sub-tree (zone) is kept at  2 name servers • 13 root servers • [A-M].root-servers.net • Geographically diverse: VA, CA, MD, Japan etc. • Another 13 name servers for .com, .net

  22. Query: www.google.com Response: .com NS a.gtld-servers.nett Q: www.google.com R: .google.com NS ns1.google.com Q: www.google.com R: www.google.com A 216.239.32.10 Caching root name server com name server Stub resolver cs.nyu.edu DNS server Stub resolver google name server .com NS .google.com NS www.google.com A Stub resolver • All record types are cached according to TTL • Caching NS records is effective at reducing latency

  23. Caching, continued • Cache negative response • 10-42% lookups result in a neg answer • Most neg answers are for reverse IP lookups • Setting low TTL for A records harmful? • Not really [Jung et. al. 2002] • Most DNS cache hits happen in short succession • Sharing DNS caches at multiple sites useful? • Not really • Names follow zipf distribution, misses are for rare names

  24. “Innovative uses” of DNSload balancing/server selection • DNS server returns different A records to different clients at different times • Short TTL: e.g. 60 sec for Akamai

  25. “Innovative” uses of DNSspam blacklisting • Is 125.191.168.35 a spam source? • Resolve name 35.168.191.125.bl.spamcop.net

  26. Problems with current naming/addressing

  27. A layered naming architecture “Almost every problem in computer science can be solved by another level of indirection” -- David Wheeler 70s

  28. LNA Proposal overview User level descriptor (ULD) e.g. email, search string Youtube -> (SID_a5f4) SID SID_a5f4 -> (EID_365a, TCP, port 80) EID EID_365a -> IP_12.4.224.3 IP

  29. Authors’ claim TCP breaks if hosts change IPs Difficult to initiate connection to mobile host How LNA solves it? Devil’s advocate Claimed Advantage #1: Host mobility

  30. Authors’ claim URL-based links break if domain name changes No name for replicated data How LNA solves it? Devil’s advocate Claimed Advantage #2: Service/data migration/replication

  31. Authors’ claim No explicit support for network-level middle boxes No explicit support for application-level middle boxes Devil’s advocate Claimed Advantage #3: Accommodating middle boxes

More Related