Multi-level Distributed Name Resolution System ...

Multi-level Distributed Name Resolution System based on Flat Identifiers (*) Luis Loyola SkillupJapan Tokyo, Japan [email protected]

Paulo Mendes INESC Porto Porto, Portugal [email protected]

Abstract— The current Internet architecture does not properly handle multi-homed hosts, since each interface of a multi-connected end-host terminal generally appears as a completely different node. The lack of transparency about the multi-homing degree of end-hosts brings even more problems when those hosts are mobile. On the one hand, in our view the combined use of local hierarchical locators and global flat identifiers for both end hosts and networks is important to reach an efficient control of multi-homing and mobility. On the other hand, when planning to use flat global identifiers for networks we must consider an increased number of access autonomous systems. To target that scenario, this paper presents a novel addressing scheme and a global lookup system based on multi-level flat identifiers, which operate between the Internet domain naming service and its routing system. The proposed mechanism allows Internet access providers to deploy networks that may not be physically adjacent to each other, without having to reveal their topological location. This is done by grouping access networks of the same organization in the same virtual organizational zone. Virtual zones aim to hide the control of multihoming and mobility from the Internet core. The second major goal of employing virtual zones is to bring closer to the end-host the decision about the most suitable access network and terminal interface to be used. This allows the exploitation of end-hosts interface diversity and local path diversity in a more efficient way.

I. INTRODUCTION Today’s Internet architecture allows users to lookup a reduced number of devices: mostly web and e-mail servers. However, with the increase popularity of social networking tools, it is reasonable to assume that in the future a high number of personal end-hosts will need to be globally identifiable by a name. In addiction, we are facing a steadily accelerating use of the remaining number of Autonomous Systems (ASes) [1], which seems to imply that more access networks are being created. These two factors stress the Internet architecture to support the lookup of a high number of globally named end-hosts in a topology encompassing a high number of edge ASes. Additionally, a significant number of globally named endhosts will, most likely, be mobile and have multiple network interfaces. Currently, common mobility control solutions rely on proxies to bind a fix locator to a set of valid ones, since routable locators may not be valid during the lifetime of a communication session. The analysis of current re-direction methods raises some questions about the most efficient method to bind globally-unique names to the topological locators of endhosts. This question is also posed due to privacy issues, since current binding approaches expose the topological location of end-hosts.

Francisco Romero and Monica Jimenez Telefonica Investigacion y Desarrollo Madrid, Spain {frb, monicaj}@tid.es

The importance of having an efficient name-locator binding mechanism increases with the present of devices with multiple interfaces. The reason is that each interface of a multi-connected end-host is generally seen as a completely different node, which is not efficient for routing and mobility purposes. Although there are proposals to hide the number of host interfaces from the application level, they do not allow a local control of the connectivity diversity at the access network level. Thus, in general, multiple locators used by a single receiver are still visible to senders, who must select one of them with no knowledge about the characteristics of the different access networks on the receiver side. Another limitation of current identifier-locator split proposals is that such separation occurs only on the end-hosts. We claim, however, that future Internet architectures may need to split identifiers and locators on any discontinuity network point, such as an interface between two heterogeneous networks. Such measure would make the inter-connection of heterogeneous networks easier and more efficient in terms of locator privacy, mobility, security, and multi-homing control. In this paper we present a new addressing scheme and a global lookup system based on the concept of organizational zones that we introduced in [15]. Our proposal aims to control mobility of devices identified by global-unique names, and to make senders agnostic of the connectivity diversity of receivers, as well as their topological location. This goal is to be achieved in a scenario in which network access operators may want to keep a uniform view over the set of their access ASes, which can be located in different parts of the global topology. Moreover, the proposed lookup system supports the dissociation of the role of Internet access provider and mobility service provider, allowing the elaboration of flexible future Internet architectures. II. RELATED WORK A. Internet namepaces and resolution system The Internet encompasses two major name spaces: domain names and IP addresses. The former provides hierarchically assigned names for network devices (mostly server and not endhost) and services. Well known services that explicitly use domain name spaces are HTTP, e-mail and SIP. On the other hand, IP addresses identify network interfaces. The translation from the domain name space to the IP address space is provided by the Domain Name System (DNS). Name resolvers communicate usually with a single name server, relying

(*) This study was carried out while the author was with Docomo Euro Labs (Munich, Germany)

on a recursive process among name servers to perform the name resolution. The IP address that results from this global and hierarchical resolution is returned to the initial resolver. One limitation is that with the current set of Internet name spaces it is difficult to manage dynamic readdressing. Second, after the name resolution is done at the sender, IP destination numbers gain global meaning, which brings limitations for the local control of the multi-homing characteristics of devices. B. Separation of Identifiers and Locators In the current IP stack, an IP address identifies a topological location in the Internet, thereby acting as a routing locator. At the same time, IP addresses name network interfaces, thereby acting as host names. With the Host Identity Protocol (HIP) [2], the host name and locators are separated from each other. IP addresses continue to act as locators, and identifier labels take the role of identifying the host. It is important to stress that a host identity can be simultaneously reachable through several interfaces (each having a different locator). Although HIP hides multi-homing from the application, multiple locators of a receiver are still visible to any sender. HI3 [3] is a combination of Secure-I3 [4] and HIP. SecureI3 is derived from I3 [5] and provides more robust protection against Denial-of-Service (DoS) attacks, by hiding IP addresses of end-hosts from the other users of the network. Nevertheless HI3 has the same limitation of HIP in confining the control of multi-homing characteristics of receivers to their access networks. The Locator/ID Separation Protocol (LISP) [6] describes a network-based protocol to implement separation of Internet addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). As in HIP, where session state is associated with a persistent host EID, LISP aims at allowing a host (or a collection of hosts) to move to a different point in the network topology (either changing providers or physically moving) without disrupting on-going sessions. LISP aims to complement host-based mechanisms such as HIP when traffic engineering functionality is desired. There are four variants of LISP, from using identifiers that are routable through the locator topology to using non-routable identifiers. In the latter case, identifiers are used as lookup keys for a new identifier-locator mapping database, which can be implemented based on Distributed Hash Tables (DHTs). The current LISP draft describes a mapping protocol for routable identifiers. The organizational zones architecture briefly described in this paper – and with more detail in [15] - follows the latter approach mentioned in the LISP draft, providing a transparent control of mobility and multi-homing by means of a separation between the lookup and routing systems. C. Lookup mechanisms A major disadvantage of the lookup mechanisms proposed for the Internet, such as MIP [7] and SIP [8], is the global exposition of multi-homing diversity of end-hosts. This means that entities (senders or mobility proxies) that may be far away from the receivers have to decide about which of the receiver’s interface to use. In most cases, this decision is not made based

on precise information about the quality of the last number of hops towards each interface of the receiver, since network access providers do not disseminate information about the status of their network. This decision may end up in a very poorquality end-to-end path towards the receiver. Moreover, the use of a single redirection point, the home agent in case of MIP or the proxy server in SIP, represents a scalability problem. Finally these approaches do not distinguish between network access providers and mobility service providers, limiting the flexibility of future Internet architectures. To overtake the scalability problems of using a single redirection server, future solutions may rely on distributed architectures (e.g., DHTs) as re-direction systems. This is a basic design aspect of this study. Mislove et al. present in [9] a multiring protocol to configure structured peer-to-peer (p2p) overlay networks into a hierarchy that reflects organizational domains and respects connectivity constrains. However, Mislove et al. do not consider the separation of identifiers and locators but data being forwarded based on names, which means that the optimal route is severely affected by DHT lookup delays of O(log N), where N is the number of nodes participating in the DHT. III. ADDRESSING SCHEME AND LOOKUP SYSTEM The proposed addressing scheme and global lookup system try to overcome the disadvantages of the related work in the following internetworking scenario: • High number of access networks • Most of the access networks have small size (may be due to the existence of micro-operators) • Some access networks, mostly from micro-operators at the edges of the Internet core, may work together in a cooperative way To address this scenario, our proposal introduces the notion of organizational zones. Each zone encompasses a set of access networks, which from now on we denote as Locator Domains (LDs). A LD is a network with a consistent internal addressing and routing system where any two end-hosts can communicate at any time with no restrictions. Hence, a zone can be considered a consistent agglomeration of LDs identified as a single network associated to a particular organization. Based on the notion of zones, lookups are done in three stages. First, a globally unique name (of an end-host), commonly referred in the literature as fully qualified domain name (FQDN), is translated into a lookup hint encompassing two flat selfgenerated cryptographic identifiers: the anchor zone identifier and the end-host identifier. The anchor zone represents the contact zone by default of a given node. The concept of anchor zone is described in detail in section II.B. The resolution is done similarly to the translation of names into IP addresses by the Domain Name System (DNS). A major difference is that the lookup hint tells us to which anchor zone an end-host is associated to, while DNS gives us the exact topological location of the end-host. In the second stage, the anchor zone identifier is resolved into the locator (e.g., IP v4/v6 address) of an ingress gateway of the anchor zone. Finally, in the third stage, the node identifier is resolved into a locator inside the anchor zone or a pointer to a different zone.

1st stage) paul@organization_A.com (FQDN) 2nd stage) Anchor_Zone_ID

3rd stage) Node_ID

Name Resolution System

{Node_ID, Anchor_Zone_ID}

Core ID Resolution System

IP_address of Core Gateway of the Anchor Zone

Zone ID Resolution System

Locator of the Node inside the Zone or pointer to Another Zone

• •

Internet (see section II.C), will be able to map zone identifiers to locators of zone ingress gateways. Allows the switch of gateways without changing the lookup information kept by senders and their home networks. Allows keeping local mobility (inside a zone) of endhosts invisible from the core network and from the source zone. This is a similar process as the usage of mobility anchor points in HMIP [10], but with a wider range (useful to create a uniform control over the, possible distributed, network of an organization).

Figure 1. Stages of the proposed Name and ID resolution system

The three-stage lookup process summarized in Figure 1 is convenient for a transparent control of multi-homed end-hosts. This is because the decision of which interface from a receiver to use is done at the ingress point of the end-host's anchor zone. The interface selection is done taking into account: i) the information stored in the lookup system about the locator domains and physical interfaces of the receiver, and ii) the capability of available internal paths in the receiver zone towards the locator domains of the receiver host (assuming that this information is provided by the routing system). This means that senders are agnostic of the connectivity diversity of receivers, as well as of its topological location inside a zone, which may span over different locator domains. A) Identification system The three-stage lookup process relies on an identification system divided in three levels: globally unique name, lookup hint and routing hint. As in SIP, the proposed solution addresses users at hosts by using a Uniform Resource Locator (URL) of a format similar to a mailto or telnet URL, i.e., user@domain. In the proposed architecture, the user part is a user name or an identification number. The domain part is either a domain name or a numeric network address from a network administrated by a certain organization. The resolution from a name to a lookup hint is described in section III.C. As an extension of HIP, our proposal allows the separation of name and locators. However, such separation is done, not only for end-hosts but also for networks. The usage of the proposed lookup hint is similar to start using AS names and host identifiers as indirections to lookup end-hosts. This is, the lookup hint is a two-tuple formed by the anchor zone identifier and the end-host identifier. The following two paragraphs describe in detail the advantages of performing the first two look up stages mentioned in Figure 1. The first lookup indirection occurs in the core network based on the zone identifier. The advantages of using zone identifiers are: • Each zone can use a locator space of their choice (e.g. IPv4 or IPv6) since only the zone identifier is used in the core to select a destination zone. • Zones do not reveal any aspect of their internal topology. Only an authorized third entity, operating in the core

The second lookup indirection occurs inside a zone based on the end-host identifier. The advantages of using end-host identifiers are: • Hide the multi-homing diversity of recipients from senders and from the network core. • Allows a local control of the set of interfaces of each receiver. The control mechanism takes into account the quality level supported by the host access wireless link and the quality level supported by the multiple paths from the zone ingress gateway to the selected interface. Host identifiers and zone identifiers correspond to 128-bit hash of self-generated cryptographic public keys. Each endhost or zone has only one identifier, which is globally unique. This differs from HIP, in the sense that the latter only consider identifiers for end-hosts. Identifiers can be public (e.g. accessed via the DNS). In our proposal, both end-host and zone identifiers are public accessible via the DNS, while the LD identifiers are only used inside their zones. Since identifiers are public keys, they can be used for authentication in security protocols like IPsec. The need to have public keys to identify LDs rises from the fact that a single zone can be geographically disperse, which means that the communication between two of its LDs may cross un-trusted networks. As proposed by HIP, the identifiers may be stored in a new resource record type (to be defined), similar to IPSECKEY RR [11]. Alternatively, or in addition, identifiers may be stored in a separated Public Key Infrastructure (PKI). B) Node Registration To be accessible a node has to register, in the lookup system of its anchor zone, the identifiers of its current LDs. The lookup system of the anchor zone may be implemented using a DHT when the number of entries is reasonably large. The notion of an anchor zone is needed since multi-homed end-hosts can be connected to LDs from different zones. Thus, an anchor zone is contacted by default during any communication session setup. A host selects its initial anchor zone based on user preferences, e.g. its favorite Internet access provider. The DHT of a anchor zone keeps also information about IP addresses of ingress gateways from other zones to which an endhost is connected. The gateways that participate in the DHT are carefully selected taking into account bandwidth, traffic load and Internet connectivity. For instance, a gateway that belongs to a moving LD is never allowed to become a zone gateway or be part of the zone lookup system.

When registering in a zone DHT, an end-host may indicate which are the preferable local LDs, and zone identifiers for certain types of traffic. The information about preferred zones is only available in the DHT of the anchor zone. The state stored in the zone DHTs is deleted if not refreshed in a given period of time. This avoids spending memory resources in keeping state of end-hosts that lost their connection(s) to the zone. The anchor zone can get information about gateways from other zones to which an end-host is connected as follows: whenever an end-host connects to a new LD it gets the zone identifier as well as the IP addresses of the zone gateways. After this, the end-host registers in the DHT of its anchor zone: i) the identifiers of the LDs to which it is connected at the moment; ii) the zone identifiers and the IP address of their gateways; iii) the associated preferences. For instance, the end user may decide to receive video and voice traffic through different zones. Thus, any incoming packets may be forwarded differently by the anchor zone depending on their traffic class. Additionally to the registrations that need to be done in the anchor zone, the end-host also has to register the identifier of its anchor zone in a zone service provider (described in section II.C). Bindings in a zone service provider are quasi-static, since changes of the anchor zone are very rare, occurring normally in two situations: i) by user intervention, when the user changes its preferred network access provider; ii) automatically due to, for instance, a long standing detachment of the end-host from the current anchor zone. C) Name to Identifier Resolution A zone service provider is a virtual provider that manages the position of the end-host at the zone level (a kind of mobility service provider independent from any Internet access provider). For instance a certain company A may operate as a zone service provider by managing a zone resolution system and providing users with a ubiquitous identification such as [email protected]. This means that Bill’s multi-homed end-host is globally identified by [email protected] independently of its current anchor zone or the locator domains to which it is connected at any time. The zone service provider offers a translation from [email protected] to a global lookup hint described by the tuple {NID, anchor-zone_ID}. The storage of the zone service provider's entries in the DNS would require the usage of a new DNS resource record, similar to the Server Record (SRV) [12]. D) Identifier to Locator Resolution The resolution of a lookup hint to a routing hint encompasses two phases. In the first phase the identifier of the anchor zone is resolved into the IP address of a suitable ingress gateway of the anchor zone for the needed type of traffic. This resolution is performed based on the zone identifier-to-locator resolution mechanism located in the core IP network. The nodes that participate in the core network's lookup DHT system are the ingress gateways of each zone. Each record or entry in the core DHT encompasses the following information about each zone: Zone_ID, IP_addresses of available ingress gateways, and a list of Service Level Specification (SLS) types that each ingress gateway handles for incoming traffic.

In the second phase, the destination host/node identifier (NID) is resolved into the identifiers of suitable LDs inside the anchor zone, or inside any other suitable zone to which the node is attached to. An anchor zone is responsible to decide via which zone a specific session (with specific traffic QoS requirements) should reach a multi-homed end-host. This resolution is carried out based on the resolution mechanism located within each zone. The zone DHT is formed by gateways of LDs and encompasses the following information about each end-host: NID, identifiers of a set of LDs and the list of SLS types handled by each LD. In this process, the identifiers of LDs can be flat labels or represented by the IP address of the LD gateway. It all depends on the type of routing system implemented inside the zone. The output of the lookup mechanism is a routing hint, based on which a capability-aware path selection can be done. The routing hint can have two formats depending upon the state kept in the ingress gateways of the zones: • If no state is kept (stateless approach), senders use a routing hint of the type .

•

If state is kept (stateful approach), senders use a shorter routing hint of the type .

In the stateful case, the egress gateway of the source zone keeps information about the IP address of the most suitable ingress gateways in the destination zone, for the indicated type of traffic. In the same line of thought, the ingress gateways in the destination zone keep information about the LDs to which the end-host is connected. The ingress gateway selected in the destination zone should be the one closer (in number of LD hops) to the selected LD. This distance information must be retrieved from the underlying routing system. With MIP and SIP the redirection points (home agent and SIP proxy, respectively) do not change, which may increase the lookup delay proportionally to the distance between the end-host and its home network. In our approach the anchor zone of an end-host can handover the connection control to a different zone, decreasing the end-to-end latency. E) Impact on the Routing System Our proposal can take advantage of any future QoS extensions to BGP (or similar approaches) that enable the control of multiple paths in the Internet core. Furthermore, it is expected that an increase in the number of end-hosts and access zones will not impact BGP, since zones only announce the IP addresses of their gateways. Inside a zone, our approach takes advantage of any QoSaware proposal that controls multiple paths between LDs (BGP can be used to route between LDs, although that does not seem the best approach in the presence of moving LDs). Moreover, the proposed solution considers flat identifiers for LDs, allowing its use with any form of future flat intra-zone routing system. To see a detailed diagram of the message exchanges and packet forwarding process in our proposed system we kindly refer the reader to [15].

A platform encompassing a MySQL Server and a Javalanguage network simulator were used to evaluate the performance of the proposed lookup system. The dynamics of the simulated system come from three factors: i) end-hosts start sessions at uniformly-distributed random times; ii) sessions have exponentially-distributed durations for different types of traffic; iii) the set of LDs to which a end-host is connected (including the appearance and disappearance of LDs) varies along the time at a rate which depends on the mobility degree of the node. Additionally, three different mobility degrees have been considered (low, medium and high) in which mobile end-hosts have been evenly distributed. As for the multi-homing degree of end-hosts, we have assumed a uniformly-distributed number of interfaces per and-host with a minimum of one and a maximum of four. Table I shows a summary of the most relevant parameters used in our simulations. Table I. Simulation parameters Parameter

Value Range

Number of zones Number of LDs per zone Static LDs (%) Low mobility LDs (%) High mobility LDs (%) Number of NIDs per zone Number of NIRs per LD Multihoming degree Number of SLS classes Number of supported SLS classes per LD Cache entries lifetime [sec] Session duration time's average [sec] Interface selection delay's average [msec] Intra-zone one-way latency's average [msec] Core network one-way latency's average [msec] Static node mobility [changes / min] Low node mobility [changes / min] Medium node mobility [changes / min] High node mobility [changes / min]

[10, 100] [10, 1000] [0, 100] [0, 100] [0, 100] [1000, 100000] [3, 5] [1, 4] 12 [4, 12] 30 180 15 24 100 0.01 0.05 0.2 0.5

As it is shown in [13] the average lookup latency in a DHT can be approximated by an infinite geometric series, whose sum quickly converges to three times the one-way delay distribution of the nodes when appropriate proximity neighbor selection (PNS) techniques are used. As the study of such techniques is out of the scope of this paper, we have assumed that a PNS scheme is available for the proposed architecture and thus the lookup latency in the DHT can be bounded, irrespective of the number of nodes participating in the DHT. Figure 2 shows the reconnection latency for the stateful and stateless cases as well as the end-to-end delay for both schemes in function of the average number of end-hosts/nodes inside a zone. For the computation of this result we use a mean one-way latency inside a zone ranging from 30 to 150 msec depending on the number of nodes inside the zone, and a mean one-way latency in the core network of 100 msec. The underlying assumption is that organizations dimension their networks according to the number of clients. For the sake of simplicity, the probability distribution of both core and zone latencies have been assumed exponential. Another latency factor considered in the simulations is the interface selection delay which takes place when the LD currently used for a communication session

disappear from the set of LDs (for instance due to a mobility event). 1400 1200 1000 Latency [msec]

III. EVALUATION

One-w ay End-to-End Delay

800

Stateles s Rec onnection Latency Stateful Reconnec tion Latenc y

600 400 200 0 0

20000

40000

60000

80000

100000

120000

Num be r of Node s pe r Zone

Figure 2. Communication and reconnection latency As shown in Figure 2 the reconnection latency for the stateful scheme is much smaller than for the stateless case, since it is given only by the reconnection time inside either the source or destination zones. This is because in the stateful approach the ingress gateway of the destination zone acts like a proxy for the destination end-host buffering all its packets until the communication has been reestablished. In contrast, for the stateless case the reconnection of the failed communication has a latency equivalent to a complete communication set-up process plus the interface selection delay. From Figure 2 we can see that the use of stateless mechanisms in highly mobile networks is unfeasible for most real-time applications since the latency incurred for a reconnection after a session failure may be unacceptable. Proportion of Failed Sessions [%] 60 Failed Sessions

50

Dropped Sessions Repaired Sessions

40 30 20 10 0 25

33

50

66

75

100

Proportion of High Mobility Nodes [%]

Figure 3. Proportion of failed, dropped and repaired sessions Figure 3 shows the proportion of failed communications (either dropped or reconnected) in function of the mobility degree of end-hosts for the stateful resolution mechanism. To vary the mobility degree of the network, the percentage of highmobility end-hosts was increased from 25% to 100% while the proportion of end-hosts with no and low mobility were kept evenly distributed. Communication sessions fail due to either mobility events or LD connectivity drops. A failed session ends up as either repaired or dropped, depending on whether there is another LD or interface which is able to fulfill the required SLS and can take over the failed session. As shown in Figure 3 the proportion of repaired sessions in stateful mode is considerably larger than the ratio of dropped sessions even for very high-

mobility scenarios, which is a promising feature of the proposed architecture. This result also shows the worthiness of having multiple interfaces for LD-connection diversity. 7000 Ingress Router State Size

Ingress Router State Size [Kbytes]

6000 5000 4000 3000 2000 1000 0 0

20000

40000

60000

80000

100000

120000

Num be r of Node s pe r Zone

Figure 4. State size for intra-zone naming resolution system Figure 4 shows the size of the state stored in the intra-zone name resolution system for the stateful approach in function of the number of end-hosts in the zone. As expected, the size of the state tends to increase linearly with the number of nodes per zone. Each entry has the format , which correspond to: i) the identifier of each end-host present in the zone; ii) the LDs to which the end-host is currently connected; iii) the set of SLSs supported by each of the LDs. The hash of all self-generated cryptographic identifier labels (NID, LD_ID, Zone_ID) have been set to 128 bits while for the SLS a label of six bits is used, following the specifications of the Differentiated Service field for IP packets [14]. From figures 2 and 4 we can conclude that the stateful mechanism is more suitable since the amount of state stored in the ingress routers is reasonably low and is compensated by a significant reduction of latency with respect to the stateless mechanism. 4000

Ingress Router State Size [Kbyte]

3500 3000 2500 2000 State Size

1500 1000 500 0 0

50

100 Minute s

150

200

Figure 5. State size for intra-zone naming resolution system for a zone with 50,000 nodes and evenly distributed mobility

Figure 5 shows the state stored in the intra-zone name resolution system along the time for a zone with 50,000 endhosts and evenly distributed mobility among the three mobility classes. As we can see, the buffer state does not vary significantly and thus a storage capacity of 4 Mbytes would be enough to keep all the state required at any point of time. We need to emphasize, however, that the traffic conditions assumed in this study may be too optimistic and thus more analysis of the required capacity is needed. In a generic way, we can state that the variance of the storage capacity will be mainly a function of

the session lifetime, the mobility degree of the end-hosts, the session initiation frequency, and the database updating frequency (referring especially to deletion of entries corresponding to dropped or finished sessions). From the results we can conclude that the stateful approach provides much better overall performance than the stateless one. When the size of the zone increases, the amount of state attains reasonable values while dramatically reducing the reconnection latency, which is a key feature in mobile scenarios, especially for real-time applications. Likewise, in the name resolution system of the core network, the state tends to increase linearly with the number of zones, reaching approximately a total state of 100 Mbytes for ten zones with an average size of 100,000 end-hosts each. We have not included this figure due to a lack of space. V. CONCLUSIONS In this paper a novel addressing scheme and a global lookup system based on self-generated cryptographic identifiers have been proposed. The name resolution system hides end-hosts mobility and multi-homing from both the core network and source nodes. The simulation results indicate that the proposed lookup system scales well, provides low reconnection latency and features a good reconnection vs. session drop ratio. It can also be harmonized with the routing system, and performs considerably well even in case of highly mobile scenarios. REFERENCES [1] BGP Routing Table Analysis Results, http://www.potaroo.net/tools/asn32/ [2] R. Moskowitz, P. Nikander, “Host Identity Protocol (HIP) Architecture”, RFC 4423, IETF, May 2006. [3] Nikander, P., Arkko, J., and B. Ohlman, "Host Identity Indirection Infrastructure (Hi3)", IETF Draft, November 2004. [4] Adkins, D., Lakshminarayanan, K., Perrig, A. and I. Stoica, "Towards a More Functional and Secure Network Infrastructure", Technical report UCB/CSD-03-1242, 2003. [5] Stoica, I., Adkins, D., Zhuang, S., Shenker, S. and S. Surana, "Internet Indirection Infrastructure", in Proceedings of ACM SIGCOMM 2002, Aug 2002. [6] D.Farinucci, V.Fuller and D.Oran, “Locator/ID Separation Protocol (LISP)”, IETF draft, January 2007. [7] C. Perkins, P. Calhoun, J. Bharatia, “Mobile IPv4 Challenge/Response Extensions”, RFC 4721, IETF, January 2007 [8] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, “SIP: Session Initiation Protocol”, RFC 3261, Internet Engineering Task Force, June 2002 [9] A. Mislove et al., “Providing Administrative Control and Autonomy in Structured Peer-to-Peer Overlays”, in 3rd International Workshop on Peer-toPeer Systems, San Diego, CA, Feb. 2004. [10] H. Soliman, C. Catelluccia, K. El Malki, L. Bellver, Hierarchical Mobile IPv6 mobility management (HMIPv6)”, IETF Draft, December 2004 [11] M. Richardson, “A Method for Storing IPsec Keying Material in DNS”, IETF Draft, February 2004 [12] A. Gulbrandsen , P. Vixie , L. Esibov, “A DNS RR for specifying the location of services (DNS SRV)”, RFC 2782, IETF, February 2000 [13] F. Dabek et. al. Designing a DHT for low latency and high throughput. In Proceedings of the First ACM/Usenix Symposium on Networked Systems Design and Implementation (NSDI), San Francisco, California, March 2004. [14] K. Nichols, S. Blake, F. Baker, D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, IETF, December 1998. [15] L.Loyola, P.Mendes, M.Jimenez, “Organizational Virtual Zones: Exploiting Regional co-Location for Multi-radio, Multi-homing and Mobility Control on Next-Generation Internet”, Elsevier Journal on Computer Communications, July 2008