1 Naming for Internet MMLAB, Seongil Han
-2- Contents Overview A layered Naming Architecture for the Internet Intentional Naming System (INS) Problems Conclusion
-3- Overview What is naming?? Name a word or words by which an individual person, place or thing is identified and referred to For what? Data, object, service, and so on In Internet DNS, IP
-4- Contents Overview A layered Naming Architecture for the Internet Intentional Naming System (INS) Problems Conclusion
-5- Current naming (DNS) 2 reference You should communicate that host with among several service providing hosts And in *.* network DNS I want to use the search engine of google Application Transport Network Data link Physical Application Network
-6- New Architecture Design principle #1 Names should bind protocols only to the relevant aspects of the underlying structure; binding protocols to irrelevant details unnecessarily limits flexibility and functionality DNS system is violated
-7- New Architecture Decouple I The name of data or service The endpoint hosting the data or service Decouple II The endpoint that I communicate with Its network location (IP address)
-8- New Architecture Service identifier Only represents the service or data (not host / endpoint) Application Transport Network Data link Physical SID EID Endpoint identifier Only represents the host (or endpoint) (not its location) Two resolution SID → (EID,transport,port) EID → IP addresses
The Naming Layers User-level descriptors (e.g., search) App session App-specific search/lookup returns SID Transport Resolves SID to EID Opens transport conns IP Resolves EID to IP Bind to EID Use SID as handle IP hdrEIDTCPSID… IP Transport App session Application
-10- New Namespace Design principle #2 Names, if they are to be persistent, should not impose arbitrary restrictions on the elements to which they refer DNS, IP are violated 2 approaches Genre (e.g. URN) Flat namespace
-11- Flat namespace How implement?? DHT O(log n) resolution time → problem Various solutions The disadvantage Not pay-for-your-own model Why trust cf) RSP
-12- Contents Overview A layered Naming Architecture for the Internet Intentional Naming System (INS) Problems Conclusion
-13- INS is.. Intentional Naming System Resource discovery and service location system for dynamic and mobile networks of devices and computers Key features Focus on ‘what’, not ‘where’ Early, late binding Application-controlled metric support Easy deployment on current internet
-14- service client New Architecture INR networks (Intentional Naming Router) INR Early binding Intentional name network location DATA
-15- service client New Architecture INR Intentional anycast Intentional name + data data
-16- service client New Architecture INR Intentional multicast Intentional name + data
-17- service client New Architecture INR Discovering Intentional name query names Announcing an intentional name
-18- New naming Intentional name Name-specifiers : attribute-value pair Wild-card (*) Range matching Example [city=washington [building=whitehouse [wing=west]]] [service=camera [data-type=picture [format=jpg]] [resolution=640x480]]
-19- Name tree root accessibility public service camera resolution 640X480 data-type picture city washington building whitehouse wing west Orthogonal attributes Name-record
-20- Problems New architecture Development and deployment is too difficult Scalability and transition should be significantly considered New namespace Flat namespace Ultimate destination, but serious and many challenges Security
-21- Conclusion New paradigm is prepared and appeared by many humans or organizations nowadays In internet, the change and challenge about naming are needed Ubiquitous computing, mobility support, security, and so on We need to consider this sufficiently