A Generic Resolution Architecture to Support Arbitrary Naming Schemes: A Focus on Mobility

1. A Generic Resolution Architecture to Support Arbitrary Naming Schemes: A Focus on Mobility Eunsang Cho, Jaeyoung Choi, Ted “Taekyoung” Kwon, Yanghee Choi MMLAB, Seoul National University, Korea AsiaFI 2011 Summer School (Aug. 9th, 2011)

2. Outline • Background • Idea • Resolution • Hierarchical Indirection Table (HIT) • Numerical Results • Conclusion MMLAB, SNU

3. Motivation (1/2) • Why a novel resolution architecture is required? • New services may need to name different kinds of entities. • Physical RFID Tag  Electronic product code (EPC) • Digital File  Digital object identifier (DOI) • Entity’s location can be changed. • We expect that future Internet applications and services will require diverse naming schemes for physical and digital entities that may dynamically move. MMLAB, SNU

4. Motivation (2/2) • Why a generic resolution architecture is required? • Since we cannot know what kinds of naming schemes will be used in the future, we propose a generic resolution infrastructure. • Specifically, we focus on how to locate mobile entities. • A digital file moving from one computer to another • A contact point of a moving user with a portable device • Taxis that are being tracked MMLAB, SNU

5. Prior Works • Domain name system (DNS) • Basically to locate quasi-static TCP/IP connectivity-configurable hosts • Prior mobility solutions (e.g. Mobile IP) • Most solutions provide mobility transparently to legacy hosts using an agent. • The agent relays all the traffic from/to the mobile host.  Traffic burden on the agent MMLAB, SNU

6. Idea (1/2) • Our standpoint is to make “an entity” aware of its mobility. • More precisely, a principal (or a purveyor) of the entity will be notified of the locator change, and it will inform a name-to-locator resolution system of the change. • The central notion of our architecture is to split the name of an entity and the locator of the host that holds the entity. • Applications and their developers do not need to know mobility at all. MMLAB, SNU

7. Idea (2/2) • How to resolve the current locator of a mobile entity from its name? • We propose a novel structure, a hierarchical indirection table (HIT), to keep track of the current locators of mobile entities. • We assume that relatively static entities are handled by a caching mechanism similar to the DNS, and instead focus on mobile entities. MMLAB, SNU

8. Resolution (1/2) • Route-by-name • A router should have the routing entry to forward packets by the entity's name. • If the names of entities are not aggregatable, the routers should have as many routing entries as the entities. • Since we aim to support arbitrary naming schemes in the future Internet, names may not be aggregated, and hence the route-by-name option has a huge scalability problem. MMLAB, SNU

9. Resolution (2/2) • Lookup-by-name • Names and their locators are split, and routers just need to forward packets by locators. • Typically locators are aggregatable to a certain degree. • This approach requires an additional resolution infrastructure. • If the name-locator mapping is almost static (like the DNS), the resolution overhead will be significantly mitigated by caching. • However, if the locators are changing due to the mobility of entities, it becomes a challenging issue, which is the main topic of this research. MMLAB, SNU

10. Mapping Structures • DNS • Flexible tree structure  Short round-trips • Load balancing issue • Distributed hash table (DHT) • Chord: an overlay ring structure with equal responsibility among nodes • No or little load balancing issue • ViAggre • Designed to reduce the routing entries in default-free routing zones (DFZs) • The entire IP address space is divided into a set of routers, each of which is responsible for a partition of the address space. MMLAB, SNU

11. Proposed Resolution • Considerations & assumptions • Diverse naming schemes • Hierarchical, flat, or attribute-value pairs • We use a hash function that maps a name into a fixed length value.  We call the hashed value as an identifier. • Lookup-by-name approach • Routers can forward packets by their locators without scalability issues. • Names are used only at application layer, and will be converted to a hashed value at the transport layer. MMLAB, SNU

12. Identifier-to-Locator (I2L) Steps Step 3: Router-level I2L (RI2L) server AS b • Two types of I2Ls • AS- and Router-level Step 2: Using AS-level I2L (AI2L) AS a Entity B Step 1: Mapping Query Step 4: Locator Step 5: Packet Router Border Router Mobile Entity Entity A (User/Host) Point of Attachment MMLAB, SNU

13. Hierarchical Indirection Table (HIT) • How can we construct the AI2L and RI2L structures? • As the RI2L structure is expected to have various structuring options, we tackle how to construct AI2L from globally distributed servers. • The design objectives of the AI2L structure • To reduce the response time of mapping queries while minimizing additional routing memory requirements • To expedite the query response, we make routers forward mapping query packets just like ordinary packets without any overlay or additional processing overhead. MMLAB, SNU

14. Router in HIT • Two router functions • Resolving: relaying mapping query packets to next hop routers by looking at identifiers • Forwarding: relaying ordinary packets to next hop routers by looking at locators • Thus, each router has two kinds of memories • Forwarding table • Resolving table MMLAB, SNU

15. Topology-aware Routing & Indirection • The routing scalability in the current Internet has already become a serious issue. • Due to site multi-homing and traffic engineering purposes • Since our design has the extra memory requirement of the resolving table, we seek to reduce the resolving table size. • To this end, we combine topology-aware routing and indirection among routers as follows. MMLAB, SNU

16. HIT (1/3) • There are T trees, and each root is responsible for the identifier space of (2L)/T . (L is bit length of hash value.) • The root nodes have no actual mapping entries. • They merely “resolve” incoming mapping query packets to the corresponding next hop nodes in its tree. • That is, servers are end systems that have the mapping entries between identifiers and their locators, while nodes in a virtual tree are routers that relay mapping query packets to the corresponding servers. MMLAB, SNU

17. HIT (2/3) • Leaf nodes in a tree correspond to the routers to which servers are connected. • Suppose L and T are 40 and 16 for the sake of exposition. • The 1st root node: 0x000000000 to 0x0FFFFFFFFF • The 2nd root node: 0x1000000000 to 0x1FFFFFFFFF • The last root node: 0xF000000000 to 0xFFFFFFFFFF • These root nodes advertise the prefixes of their assigned spaces throughout the Internet. • In this example, like CIDR, these root nodes will each announce their prefixes (i.e. the first four bits) 0b0000, 0b0001, and 0b1111, respectively. • Thus, each router needs T entries in the resolving table to relay a mapping query packet to its corresponding root node. MMLAB, SNU

18. HIT (3/3) • The number of child nodes of each node in a tree is W. • As there are W first level nodes for each root node, each first level node is in charge of (2L)/T/W. • Suppose W is 4 in the above tree example. • Then the four child (first level) nodes of the first root node will advertise 0b000000, 0b000001, 0b000010, and 0b000011 for K hops, respectively. • Likewise, the four child nodes of the second root node will advertise 0b000100, 0b000101, 0b000110, and 0b000111 for K hops, respectively. MMLAB, SNU

19. Resolving Table Size & Lookup Delay (1/2) • We impose a constraint that a parent node and its child node are located within K (router level) hops. • The design rationale behind this spatial constraint is to reduce the resolving table size as well as the lookup delay. • Thus, each first level node is within K hops from the root. • Likewise, each second level node will be reached within K hops from its parent (first level) node. • The depth of each tree D can then be found by the minimum value that satisfies T*WD≥S. • The expectation of the number of the hop count between N routers is given by logN. MMLAB, SNU

20. Resolving Table Size & Lookup Delay (2/2) • Thus, ignoring the delay between the soliciting host/server and its access router, the average query response in terms of the hop count is the sum of followings. • The leg between the soliciting host and the corresponding root (logN) • The worst case hop count from the root to the server that has the requested mapping entry (D*K) • The returning leg from the server to the soliciting node (logN) • Even though we assume K is decided a priori, the nodes may flexibly set K depending on the topological distribution of nodes. • If we assume that individual trees are not overlapping between one another, each router needs to keep up to T+D*W entries in its resolving table. Soliciting Host logN Corresponding Root D*K Server with Mapping Entriy logN MMLAB, SNU

21. Load of Mapping Query • The major concern of the HIT is the load of mapping query packets on roots. • In the worst case, each root should handle approximately 1/T of total mapping query packets. • However, the actual traffic load can be substantially mitigated by locating its child (and descendant) nodes as “the first line of defense.” • Figure illustrates an extreme case in which the root node receives no incoming mapping query packets since the packets encounter the root's child nodes (i.e. first level nodes) and are relayed to their descendant nodes. • The current top-notch routers can forward about a billion packets per second. • We believe the combination of sufficiently high T, placing descendant nodes closer to backbone links, and the ever increasing line speed of routers can solve the workload scalability issue of the HIT. MMLAB, SNU

22. Numerical Results • We asymptotically compare the HIT with other mapping structures in terms of: • number of resolution entries • lookup cost • workload on a mapping server • For the HIT, we set K, W, and T as 4, 8, and 256 respectively. • As for T, we consider that the DNS has more than two hundred machines for root servers in 2010. • However, we believe this number should be raised as the number of mobile entities increases. MMLAB, SNU

23. Number of Resolution Entries • The number of resolution entries represents how many routing entries need to be maintained in a resolution node to provide AI2L mapping services. (y-axis: log-scale) Averaged # of child nodes of .com and .net in 2010 Linearly increased (S) Logarithmically increased Chord: logS HIT: T+W*D MMLAB, SNU

24. Lookup Cost • The lookup cost in terms of the hop count as the number of routers N increases, where S is set to 105(x-axis: log-scale) Mapping query goes back and forthlogStimes. (logS*logN+logN) e.g. www.snu.ac.kr (2logN*5) Leaf node is not far from root (D*K+2logN) Shortest path (2logN) MMLAB, SNU

25. Worst-case Workload • The worst-case workload on a node for each generated mapping query as S increases. (y-axis: log-scale) High traffic load on root (1/T) Flat structures Chord: (logS)/S ViAggre: 1/S MMLAB, SNU

26. Conclusion • Diverse services can be well accommodated by making the future Internet capable of supporting their naming schemes naturally. • To this end, we suggest a generic resolution architecture in which a name at application layer is converted into its identifier at transport/network layer by a hash function. • Since applications may seek to name mobile entities (either physical or digital), we propose a hierarchical indirection table (HIT) to provide mapping from the identifier of an entity to the locator of the entity. • The central idea of the HIT is to construct virtual trees among routers to relay mapping query packets toward the corresponding mapping servers. • By imposing a spatial constraint that a parent node and its child node must be less than a preconfigured hop count away, the HIT can minimize the number of resolution entries while reducing the lookup delay. • We believe the traffic load on the root nodes of the trees can be mitigated by the combination of constructing a sufficient number of trees, placing descendant nodes closer to backbone links than ancestor nodes, and the ever increasing line speed of routers. MMLAB, SNU

27. Thank you MMLAB, SNU

28. Discussions (1/2) • Some critical concerns about the HIT can be raised, e.g. • Who will deploy and maintain so many servers • Once servers are deployed, how can we satisfy the spatial constraints • i.e. parent and child nodes should be within K hop count. • We argue that there are possible solutions. • For instance, the top internet naming agency (i.e. ICANN) or regional internet registries (RIRs) may deploy and maintain mapping servers in numerous Internet service providers (ISPs). • ISPs can provide the Internet connectivity for the servers in exchange for IP addresses and other number of resources assigned from ICANN and RIRs. • The maintenance fee can be levied on principals that register the identifiers of the names. • We believe it is also feasible to allow private companies (e.g. ISPs) to operate mapping servers with the same business model. • If ISPs deploy servers, they can easily satisfy the spatial constraint. • Due to the proliferation of content delivery networks (CDNs), leveraging the widely distributed infrastructures of CDN companies can be an attractive option.

29. Discussions (2/2) • Our resolution architecture takes a clean slate approach since it requires a novel router architecture and the advertisement of (identifier space) prefixes of resolution nodes. • However, we can think of an overlay version of the HIT, like a DHT, that need not modify legacy routers. • In the HIT overlay, a soliciting host (or its resolver) should know the IP addresses of T root nodes. • We believe that it is not a huge burden since the root nodes will be highly stable and available. • A mapping query packet is first sent to its corresponding root, and then relayed from the root to the corresponding mapping server along the virtual tree path by tunneling. • That is, the destination locator is set to be an IP address of the next resolution node for each tree link. • Therefore, we can deploy the HIT without any changes on routers. • However, the tunneling overhead in the root nodes will be a critical issue since tunneling a packet will take longer time than merely relaying a packet to the next hop router in the original HIT.