Information-Centric Networks Section # 6.2: Evolved Naming & Resolution Instructor: George Xylomenos...

Click here to load reader

  • date post

    19-Jan-2016
  • Category

    Documents

  • view

    219
  • download

    1

Embed Size (px)

Transcript of Information-Centric Networks Section # 6.2: Evolved Naming & Resolution Instructor: George Xylomenos...

Information-Centric NetworksSection # 6.2: Evolved Naming & ResolutionInstructor: George XylomenosDepartment: Informatics

1FundingThese educational materials have been developed as part of the instructors educational tasks.The Athens University of Economics and Business Open Courses project only funded the reformatting of these educational materials. The project is being implemented as part of the Operational Program Instruction and Lifelong Learning and is co-financed by the European Union (European Social Fund) and national funds.

2LicencingThese educational materials are subject to a Creative Commons License.

3Information-Centric Networks06b-4Week 6 / Paper 2A layered naming architecture for the InternetHari Balakrishnan, Karthik Lakshminarayanan, Sylvia Ratnasamy, Scott Shenker, Ion Stoica and Michael WalfishACM SIGCOMM 2004Main pointThere is one step of name resolution today: DNS to IPThere should instead be threeUser name to service identifierService identifier to endpoint identifierEndpoint identifier to IP addressThis would make data and services equal to hostsIt would also accommodate mobility and multihomingAnd properly integrate middleboxes into the Internet4IntroductionThere are two namespaces on the Internet: DNS and IPDNS is tied to administrative structure, IP to network topologyData and services are only named indirectlyWe name the host where data and services resideThey are thus tied to administrative structure and network topologyMiddleboxes violate even this simple modelNATs/NAPTs modify the IP addressesIdeally they should be explicitly delegated to do their jobWhat should naming be like?We really need four layers of namingHuman names, service IDs, endpoint IDs and IP addressesNaming is relatively easier to modify than IP itselfBut it cannot solve problems that are due to IP limitationsInformation-Centric Networks06b-5Design principlesNames should bind protocols as little as possibleIf you need a service (or some data) why involve a host name?Service identifier (SID): persistently identifies a serviceProduced from human friendly names by a mapping serviceTransport protocols should not be aware of network addressesEndpoint identifier (EID): topologically independent (unlike IP)Human friendly->SID->EID->IPFirst locate the SID and start a session (application)Resolve the SID to one or more EIDs (transport)Resolve one or more EIDs to IP addresses (network)Host mobility: update EID to IP mappingService mobility: update SID to EID mappingInformation-Centric Networks06b-6Design principlesPersistent names should not restrict referred to elementsDNS names for data and services are ephemeralData/services not necessarily bound to a specific organizationDNS prohibits data/service mobilityOne solution is to partition the namespace to genresAnother one is to use flat namesNames should be possible to resolve to delegatesAn endpoint may want to only receive data via a delegateNAT/NAPT, firewall, whateverThe architecture should handle middleboxesDestinations should be generalized to sequencesAllow both sender and receiver to use middleboxesThe sender indicates them, the receiver relies on resolutionInformation-Centric Networks06b-7EIDs and SIDsULD resolution: maps human friendly names to SIDsBeyond the scope of the paperSID resolution: maps SIDs to EIDsApplication sends a SID to the resolution serviceThe service returns one or more (EID, transport, port) triplesFor data additional data may be returned (e.g. pathnames)The transport layer uses the triple to initiate a connectionSIDs are included in application data unitsExample: HTTP headers, SMTP headersEID resolution: maps EIDs to IP addressesThe transport layer sends packets to the EID resolverThe EID resolver may pick one of the returned IP addressesEIDs are included in network packetsInformation-Centric Networks06b-8Delegated bindingsDelegation at the EID or SID layer (stateful)EID: The endpoint advertises the IP address of a delegateThe delegate needs to know where to forward packetsSID: Same as above, but at a the application levelDelegation via identifier stacking (stateless)Sequences of SIDs or EIDs can be returned by the resolverSimilar sequences can be indicated by the senderThe path consists then of the concatenation of the sequencesExamples of explicit delegationEID level: NAT/NAPT, firewalls, VPNsSID level: virus scanners, spam detectorsWorks even for individual e-mail addressesInformation-Centric Networks06b-9Coping with flat namesFlat name resolutionDNS achieves scalability through hierarchyDHTs can handle flat names in a scalable mannerAssume managed DHT substrates with low churnEnsuring flat names are unique is trickyDHT resolution time needs to be reducedCaching and replication can helpAn economic and trust model is neededWhy would I buy a server to store other peoples names?Why I should trust you to resolve somebody elses names?Mapping from human friendly namesUsers need to trust services that map names to SIDsCryptographic techniques can help users trust SIDsInformation-Centric Networks06b-10End of Section # 6.2Course: Information-Centric Networks, Section # 6.2: Evolved Naming & ResolutionInstructor: George Xylomenos, Department: Informatics

11