Design and Implementation of Mapping Systems for an ID/Locator Split Protocol for New Generation Network

Transcription

1 Design and Implementation of Mapping Systems for an ID/Locator Split Protocol for New Generation Network Sho Kanemaru Graduate School of Science and Technology, Keio University Hiyoshi, Kohoku-ku, Yokohama, , Japan Kazuma Yonemura Graduate School of Science and Technology, Keio University Hiyoshi, Kohoku-ku, Yokohama, , Japan Fumio Teraoka Faculty of Science and Technology, Keio University Hiyoshi, Kohoku-ku, Yokohama, , Japan ABSTRACT We are proposing Z Network Protocol (ZNP) as a network layer protocol based on ID/Locator split approach in the future Internet. ZNP is designed to satisfy the following requirements in terms of practical operation: (1) support of L3 protocol heterogeneity, (2) scalability of ID/Locator mapping system, (3) independence of mapping information management, and (4) avoidance of locator leakage beyond the administrative boundary. This paper proposes the mapping systems of ZNP; the Name Mapping System (NMS) and the ID Mapping System (IMS). To satisfy (1), the IMS is designed to be able to manipulate variable types of locators. To satisfy (2) and (3), the NMS and the IMS compose tree structure and the mapping information of a node is managed by the mapping agents in the domain to which the node belongs. To satisfy (4), ZNP introduces the localized mapping agents. To manipulate our proposing mapping systems, we designed and implemented Z Control Message Protocol (ZCMP) as an application layer protocol. The measured signaling overhead shows that the proposing mapping systems are practical for the future Internet. Categories and Subject Descriptors C.2.2 [Network Protocols]: Protocol architecture General Terms Design, Implementation Keywords ID/Locator Split, Future Internet, Z Network Protocol 1. INTRODUCTION More than 40 years have passed since the basic principles of the original Internet architecture were designed. These principles were suitable for static and well-managed networks, but as the Internet has become widespread and anyone can use the Internet, the requirements for the current Internet increase such as mobility, multihoming, security, and scalability. To meet these requirements, a lot of protocols based on ID/Locator split architecture have been proposed. Six/One Router[1], Locator/Identifier Separation Protocol (LISP)[2], Location Independent Networking for IPv6 (LIN6)[3], Identifier- Locator Network Protocol (ILNP)[4], and Host Identity Protocol (HIP)[5] target to improve the current Internet. A Node Identity Internetworking Architecture (NodeID)[6], Heterogeneity Inclusion and Mobility Adaptation through Locator ID Separation in New Generation Network (HIMALIS)[7], Hierarchical Architecture for Internet Routing (HAIR)[8], and a Mobility and Multihoming Supporting Identifier Locator Split Architecture for Naming in the Next Generation Internet (MILSA)[9] target to the future network. On the other hand, a new protocol for the future network must satisfy the following requirements in terms of practical operation: (1) support of L3 protocol heterogeneity, (2) scalability of ID/Locator mapping system, (3) independence of mapping information management, and (4) avoidance of locator leakage beyond the administrative boundary. In the future network, several L3 protocols such as the proposed L3 protocol in this paper, IPv4, IPv6, and other protocols will coexist while the current Internet uses only IPv4 and/or IPv6. Therefore, (1) must be satisfied. (2) is obvious. A protocol based on ID/Locator split must have a ID/Locator mapping mechanism. To support a huge number of nodes, the mapping system must be scalable. (3) and (4) are related to administration viewpoint. (3) means that the mapping information of a node must be managed in the administrative domain to which the node belongs (the home domain) in terms of authentication of mapping information when the node is temporally connected to a foreign domain. If the mapping information is managed in administrative domains other than the home domain, it is very difficult to authenticate the mapping information. (4) means that the locator information in an administrative domain must not be registered with the mapping system in other administrative domains. This avoids leakage of the topology information of an administrative domain to the outside. We are proposing an ID/Locator Split protocol for the New Generation Network called Z Network Protocol (ZNP)[10]. ZNP is designed to satisfy the all requirements described above. This paper proposes the mapping systems of ZNP; the Name Mapping System (NMS) and the ID Mapping System (IMS). The NMS manages the name-to-id mappings and it consists of the Name Mapping Agents (NMAs). The IMS manages the ID-to-Locator mappings and it consists of the ID Mapping Agents (IMAs). These mapping systems are also designed to satisfy the all requirements described above. To satisfy (1), the IMS is designed to be able to ma-

2 nipulate the variable types of locators. To satisfy (2) and (3), the NMS and the IMS compose tree structures similar to the Domain Name System (DNS) and the mapping information of a node is managed by the NMA and the IMA in the administrative domain to which the node belongs. To satisfy (4), we introduce the Local NMA and the Local IMA. The mapping information managed by the Local NMA or Local IMA is available only inside of the domain in which these mapping agents exist, i.e., this mapping information is not available from outside of the domain. (4) is satisfied with introducing the Local NMA/IMA in addition to the global NMA/IMA. This paper designs and implements the protocol to manipulate the mapping system called Z Control Message Protocol (ZCMP). To verify the performance of the proposing mapping system, this paper measures the signaling overhead when the node resolves the mapping entry. The rest of this paper is structured as follows. Section 2 discusses related research based on ID/Locator split architecture. Section 3 describes an overview of ZNP. Section 4 describes the proposed architecture of the NMS and the IMS. Section 5 shows the implementation and performance estimation. Finally, Section 6 concludes this paper. 2. RELATED WORK There are many proposals based on ID/Locator split architecture. Six/One router, LISP, LIN6, ILNP, and HIP are targeting to improve the current Internet and they do not address the issues of the future network. Six/One Router and LISP intend to reduce the size of the routing table in the backbone network, but they do not consider mobility. LIN6 is designed to support mobility, multihoming, and security, but it does not consider L3 protocol heterogeneity. ILNP introduces the ILNP address made by concatinating the Locator (L) and Identifier (I), i.e., L:I. ILNP does not introduce a new layer such as HIP and MILSA. Thus, this makes it easy to deploy ILNP in the current Internet. The mappings between name and identifier and the mappings between identifier and locator are managed by Dynamic DNS. However, ILNP does not consider L3 protocol heterogeneity. HIP provides secure end-to-end connectivity and supports mobility and multihoming management by introducing a new host ID space. HIP uses the Host Identity Tag (HIT) as the identifier and uses the IP address as the locator. HIP can use IPv4/IPv6 as the locator, which means that it achieves L3 protocol heterogeneity. Mappings between the HIT and the IP address are stored in the Rendezvous server (RVS), but the detail way of distributing RVSs is not defined. In addition, as the HIT does not have a hierarchical structure, it is difficult to know which RVS is responsible for a HIT. Thus, its mapping system does not scale. NodeID, HIMALIS, HAIR and MILSA are based on clean slate approach that targets to redesign the Internet. NodeID uses the Node Identitity (NID) as the ID. NodeID introduces the locator domains (LDs) and the node identity routers (NRs). Each LD can have a different routing scheme, so NodeID can support heterogeneous locators. The LDs are interconnected by the NRs and they construct a tree structure. The root LD of the tree is called the core LD. Each NR has NID-Locator mappings of nodes which exist in the lower LDs. Each NR resolves the locator from the NID and forwards packets using the NID routing table. If the NR cannot resolve the locator, it forwards packets to the core LD. The deeper the tree structure becomes, the more the information that the core LD and the NRs must store. Thus, its mapping system does not scale. HIMALIS can also manipulate heterogeneous locators. It introduces a new mapping system called the ID registry (IDR). The IDR stores and distributes the mappings between the host IDs and the locators of all active nodes. However, this mechanism is so complex that it does not scale and administrative independence of its mapping mechanism is not achieved. For example, when a node moves from the home network to another edge network (foreign network), the IDR forwards the mapping between the host ID and the locator from home network s gateway (GW-HN ) to foreign network s one (GW-FN ). In HIMALIS, since the scope of the locator is not protected, the locator information may leak to the outside of the domain. For example, when a node communicates with a correspondent node, it can know the correspondent node s locator even if the correspondent node exists in another locator domain. HAIR introduces the CORE, INTERMEDIATE, and EDGE networks. HAIR generates a locator by concatinating the locators of each network. So the deeper the network hierarchy becomes, the larger the header overhead becomes. The mapping system of HAIR consists of the global directory service provided by the CORE and the Intermediate Network Mapping Service (IMS). The global directory service stores a pointer to the IMS that currently holds the mapping, and each IMS stores the mappings between the ID and the locator. As the global directory service works in the CORE network, this mechanism seems to burden the CORE network. The way of implementing IMS service is not defined. MILSA introduces the Hierarchical URI-Like Identifier (HUI) as the identifier. The mappings between the HUI and the locator(s) are managed by the Realm-Zone Bridging Server (RZBS). In this architecture, RZBSs construct a tree structure. Thus, the mapping system of MILSA seems scalable. MILSA supports mobility and multihoming, but it does not support L3 protocol heterogeneity. In addition, the HUI is variable length, which makes the header format complicated. Table 1 compares the features of the related work in terms of the requirements for practical operation. As described above, Req.(1): support of heterogeneity of network layer protocols, Req.(2): scalability of ID/Locator mapping system, Req.(3): independence of maping information management, and Req.(4): avoidance of locator leakage beyond the administrative boundary. Table 1 shows that ZNP supports all of the requirements though no other work meets the all requirements. 3. Z NETWORK PROTOCOL 3.1 Assumed Network Structure The current Internet is composed of the backbone (i.e., a set of network providers) and a large number of subscriber networks. Some proposals assume that the future Internet has the following structures; There are a lot of domains each of which may use a different locator type; These domains are interconnected and compose a random structure or a multilevel tree structure. However, it is very difficult to manage the network that has such structures. Although there will exist such network structures during a transition period, we assume that the final structure of the future Internet con-

3 Table 1: Comparison of ID/Locator Split Architectures in terms of practical operation Req.(1) Req.(2) Req.(3) Req.(4) Six/One Router no yes yes LISP yes no yes yes LIN6 no yes yes ILNP no yes yes HIP yes no yes no NodeID yes no no yes HIMALIS yes yes no no HAIR yes no no yes MILSA no yes yes ZNP yes yes yes yes verges upon the structure shown in Figure 1. Similar to the current Internet, there is the backbone network composed of several providers and a large number of edge (subscriber) networks. The backbone network uses ZNP and the edge networks may use ZNP or other L3 protocols. From locator type viewpoint, the future Internet is divided into two spaces: the Universal Locator Space (ULoc-Space) in which the locator of ZNP is used and the Local Locator Space (LLoc-Space) in which legacy L3 protocols such as IPv4/v6 are used. From locator scope viewpoint, the ULoc-Space is further divided into two kinds of networks: the Global Universal Network (GU-Net) in which the scope of the universal locator is the whole future Internet and the Private Universal Network (PU-Net) in which the scope of the universal locator is the inside of the network. Some edge networks belong to the GU-Net while some edge networks belong to the PU-Net similar to the current subscriber networks that connect to the Internet backbone via NAT-like devices. We assume that NAT-like devices still remain in the future network because there can be administrators who do not want to disclose the network topology to the outside. It is important to design a L3 protocol that permits existence of NAT-like devices, not to prohibit existence of them. A network belonging to the LLoc-Space is called the L-Net. A L-Net is connected to the GU-Net via the gateways that have a protocol conversion function. 3.2 Internetworking with a Common ID Space In ZNP, the node name is a human readable character string and its syntax is the same as that of the FQDN in the current Internet such as node_x.keio.jp. The ID is fixed length binary data. The format of the ID is shown in Figure 2. The ID is composed of three parts: the Registry Identifier, the Organization Identifier, and the Node Identifier. The Node Identifier is assigned by an organization (e.g., Keio Univ.) to which the node belongs. The Organization Identifier is assigned by a registry (e.g., JPNIC and APNIC) with which the organization is registered. The Registry Identifier is assigned by an authority such as ICANN in the current Internet. The examples of ID prefix are shown in Figure 3. ZNP introduces two kinds of IDs: the real ID (rid) and the pseudo ID (pid), both of which have the same format. The rid is the real identifier of a node and unique to the whole networks. The pid is a temporary identifier negotiated by the end nodes before data communication starts. The pid is unique to the communicating end nodes. As the Figure 1: Assumed network structure of the future Internet Figure 2: ID format pid changes session by session or when the node moves, using pid in the packet header keeps the identity of the end nodes anonymous against eavesdroppers. A node is assigned a locator by the network to which the node is connected. For example, if a node is connected to the ULoc-Space, the node is assigned a universal locator (i.e., a ZNP locator) while if it is connected to the LLoc- Space, it is assigned a local locator such as an IPv4 address. To support L3 protocol heterogeneity, ZNP introduces the protocol conversion function on the gateways that connects the ULoc-Space and the LLoc-Space. ZNP has two kinds of mapping systems described in Sec. 4. One is the Name Mapping System that maps the name to the rid. Another is the ID Mapping System that maps the rid or pid to the locator. Thus, ZNP achieves Internetworking with a Common ID Space. A node can communicate with another node as long as it knows the ID of the target node even when the target node moves (node mobility), the network to which the target node is connected moves (network mobility), the target node has multiple interfaces (multihoming), or various L3 protocols coexist (L3 protocol heterogeneity). 4. MAPPING SYSTEMS 4.1 Mapping System Structure Figure 3: ID Prefix Examples

4 Table 2: Resource Records Record Type Label Resource Data rid host name rid pid host name pid NMA domain name rid of NMA IMA ID rid of IMA LOC ID Locator PTR ID host name Figure 4: An example of tree structures of the Name Mapping Agents and the ID Mapping Agents The Name Mapping System (NMS) maps the node name to the corresponding rid. The ID Mapping System (IMS) maps the rid or pid of the node to the corresponding locator. The NMS is composed of the Name Mapping Agents (NMAs) and the IMS is composed of the ID Mapping Agents (IMAs) as shown in Figure 4. In addition, there are cache servers in the mapping systems, called the mapping caches. They work on the gateways. The mapping cache stores the hostname-to-id mappings and the ID-to-Locator mappings. The NMA and the IMA compose tree structures rooted by the root NMA. Similar to the current DNS, the hierarchy of the NMS is based on the hierarchical structure of the name. The hierarchy of the IMS is based on the hierarchical structure of the ID shown in Figure 2. A NMA holds the locators of the lower level NMAs and an IMA holds the locators of the lower level IMAs. In addition, the NMA of a domain holds the locator of the IMA that manages the same domain. Figure 4 shows an example of tree structures of the NMS and IMS that manage a domain jp and its two subdomains unet.jp and pnet.jp. Suppose that unet.jp uses the GU- Loc (i.e., the global scope ZNP locator) while pnet.jp uses the PU-Loc (i.e., the private scope ZNP locator). For pnet.jp, there are two kinds of NMAs and IMAs: the global NMA/IMA and the local NMA/IMA (L-NMA/L-IMA). The global NMA and IMA are located in the GU-Net for the queries sent from the GU-Net. The L-NMA and the L-IMA are located in the PU-Net for the queries sent within the PU-Net. In this example, there are one or more NAT-like gateways at the boundary of jp and pnet.jp because pnet.jp is a PU-Net. The global IMA of pnet.jp holds the mappings between the rids of the nodes in pnet.jp and the GU-Loc of the gateway. The L-IMA of pnet.jp manages the mappings between the rids of the nodes in pnet.jp and their private locators. Thus, by employing tree structures, ZNP achieves the scalability of the mapping systems (requirement (2)) and independence of mapping information management (requirement (3)). In addition, by introducing the L-NMA and the L-IMA, ZNP avoids leakage of private or local locators beyond the administrative boundary (requirement (4)). 4.2 Data Structure Resource Records In the proposed mapping systems, the mapping data is expressed as the Resource Records. The Resource Records are composed of the Label, the Record Type, and the Resource Data. The Record Type designates the structure of the Resource Records. The list of the Record Types is shown in Figure 5: A Sample Network Table 2. The rid and pid record types express the name-to- ID mappings, and the LOC record type expresses the ID-to- Locator mappings. The NMA record type maps the domain name to the rid of NMA responsible for the domain expressed by the label. The IMA record type maps the ID to the rid of IMA responsible for the ID expressed by the label. The PTR record type expresses the ID-to-name mappings Zone File Examples The Resource Records are described in the zone file, which is the configuration file of the mapping agents. We assume a sample network shown in Figure 5. In this network, there are two domains, unet.jp and its subdomain sub.unet.jp. In the domain unet.jp, the ID prefix 101:100:: and the locator prefix 2001:db8::/48 are assigned and there are two mapping agents, NMA-unet.jp and IMA-unet.jp. The zone file of NMA-unet.jp is shown in Figure 6 and the zone file of IMA-unet.jp is shown in Figure 7. In the domain sub.unet.jp, the ID prefix 101:100:1:: and the locator prefix 2001:db8:1::/64 are assigned and there are two mapping agents, NMA-sub.unet.jp and IMA-sub.unet.jp. The NMA record type in Figure 6 designates the rid of NMA that manages the mapping information in domain sub.unet.jp. The IMA record type in Figure 6 designates the rid of IMA that manages the mapping information whose ID prefix is 101:100::, and the IMA record type in Figure 7 designates the rid of IMA that manages the mapping information whose ID prefix is 101:100:1::. 4.3 Message Format ZCMP Header ZCMP is the protocol that manipulates the proposed mapping systems. The header of the ZCMP message is shown in Figure 8. The Type field shows the type of the ZCMP message. In this field, one of the values shown in Table 3 is set. The Code field is used in the reply message, and it expresses the status of the mapping resolution procedure. ZCMP defines five types of the code values shown in Ta-

5 <Label> <Record Type> <Resource Data> Node_A rid 101:100::3 Node_B rid 101:100::4 sub NMA 101:100:1::5 101:100:: IMA 101:100::2 101:100::2 LOC 2001:db8::2 101:100:1::5 LOC 2001:db8:1::5 Table 4: Code values in ZCMP Header Code of ZCMP Header value ZCMP_CODE_SUCCESS 0x00 ZCMP_CODE_FORWARD 0x01 ZCMP_CODE_NO_HOST_FOUND 0x02 ZCMP_CODE_NO_DOMAIN_FOUND 0x03 ZCMP_CODE_FORMAT_ERROR 0x04 Figure 6: An Example of zone file for NMA-unet.jp <Label> <Record Type> <Resource Data> 101:100::3 LOC 2001:db8::3 101:100::4 LOC 2001:db8::4 101:100:1:: IMA 101:100:1::6 101:100:1::6 LOC 2001:db8:1::6 Table 5: Record Type values in Query/Answer Field Type of Query/Answer Field value ZCMP_TYPE_NAME 0x01 ZCMP_TYPE_RID 0x02 ZCMP_TYPE_PID 0x03 ZCMP_TYPE_NMA 0x04 ZCMP_TYPE_IMA 0x05 ZCMP_TYPE_LOC 0x06 ZCMP_TYPE_PTR 0x07 Figure 7: An Example of zone file for IMA-unet.jp ble 4. ZCMP_CODE_SUCCESS means that the mapping resolution procedure finished successfuly. ZCMP_CODE_FORWARD means that the client needs to forward the request message to the server which specified in the reply message (i.e., the query is halfway through the hierarchy of NMS or IMS). ZCMP_CODE_NO_HOST_FOUND means that the node specified in the request message is not found. ZCMP_CODE_NO_DOMAIN_FOUND means that the domain specified in the request message is not found. ZCMP_CODE_FORMAT_ERROR means that there is some format error in the request message. The Number of query field shows the number of query fields. The Number of answer field shows the number of answer fields. As the answer field only exists in the reply message, zero is set in the request message. The Sequence number field is used for matching of the request and the reply ZCMP Message ZCMP defines eight types of the messages: the ID Request/Reply message, the Locator Request/Reply message, the Locator Registration Request/Reply message, and the Communication Request/Reply message. The ID Request message requests the rid that corresponds to the name and the ID Reply message is its reply. These messages are processed by the root NMA, NMAs, mapping caches and the end nodes. The Locator Request message requests the lo- Table 3: Type values in ZCMP Header Type of ZCMP Header value ZCMP_ID_REQUEST 0x01 ZCMP_ID_REPLY 0x02 ZCMP_LOC_REQUEST 0x03 ZCMP_LOC_REPLY 0x04 ZCMP_LOC_REG_REQUEST 0x05 ZCMP_LOC_REG_REPLY 0x06 ZCMP_COM_REQUEST 0x07 ZCMP_COM_REPLY 0x08 cator that corresponds to the rid or pid and the Locator Reply message is its reply. These messages are processed by the root NMA, the IMAs, the mapping caches, and the end nodes. The Locator Registration Request registers the ridto-locator or pid-to-locator mappings with the IMA and the Locator Registration Reply messege is its reply. These messages are processed by the IMAs and the end nodes. The Communication Registration Request/Reply messages are used in the pid negotiation described in Sec These messages are processed between the end nodes. An example of ID Request/Reply message is shown in Figure 9. The ID Request message is composed of ZCMP header and the query field. The query field is composed of Type, Length, and Value. In the query field of the ID Request message, ZCMP_TYPE_NAME is set to the Type field, the length of the node name is set in the Length field, and the correspondent node s name is set to the Value field (Figure 9 (a)). Note that the value set in the Type field corresponds to the Resource Types shown in Table 5. The ID Reply message is created by appending the answer fields to the ID Request message. The answer field is also composed of Type, Length, and Value. Two kinds of ID Reply message are shown in Figure 9: ZCMP_CODE_SUCCESS is set to the Code field in the ZCMP header (Figure 9 (b)), and ZCMP_CODE_FORWARD is set to the Code field in the ZCMP header (Figure 9 (c)). When ZCMP_CODE_SUCCESS is set in the Code field, the answer field is composed of the rid of the correspondent node, rid of the IMA that manages the ID-to-Locator mappings of the rid, and its locator. (i.e., ZCMP_TYPE_RID, ZCMP_TYPE_IMA, and ZCMP_TYPE_LOC are set to the Type field in each answer field). When ZCMP_CODE_FORWARD is set in the Code field, the answer field is composed of the rid of the NMA responsible for the subdomain and its loca- Figure 8: ZCMP Header

6 Figure 9: ID Request/ID Reply Message Figure 10: An example of ID and locator resolution: intra GU-Net tor (i.e., ZCMP_TYPE_NMA and ZCMP_TYPE_LOC are set to the Type field in each answer field). 4.4 Signaling Examples Intra GU-Net Suppose that the node Node_X.unet1.jp (Node X) wants to communicate with the node Node_Y.unet2.jp (Node Y). Both end nodes exist in the GU-Net (i.e., both end nodes use the universal ZNP locator). This procedure is shown in Figure 10. Before the communication, the end nodes register their own rid-to-locator mappings with their home domain s IMA (Figure 10 (0)). First, Node X sends the ID Request message that contains the correspondent node s name (Node_Y.unet2.jp) to NMA-unet1.jp (Figure 10 (1)). If NMA-unet1.jp does not have the information of Node Y, it forwards the query to the root NMA and obtains Node Y s rid from NMA-unet2.jp (Figure 10 (2)-(4)). Obtaining Node Y s rid, NMA-unet1.jp returns the ID Reply message to Node X (Figure 10 (5)). This ID Reply message contains the rid and the locator of IMA-unet2.jp. Node X sends the Locator Request message that contains Node Y s rid to IMA-unet2.jp and obtains Node Y s locator (Figure 10 (6)). Obtaining Node Y s locator, Node X sends a data packet to Node Y (Figure 10 (7)). When Node Y receives the packet, it sends the Locator Request message to IMA-unet2.jp to confirm whether the source rid-to-locator mapping in the ZNP header is trustworthy (Figure 10 (8)). If IMA-unet2.jp does not have the information of Node X, it forwards the query to the root NMA and obtains Node X s locator (Figure 10 (9)- (12)), and returns the Locator Reply message to Node Y (Figure 10 (13)). Obtaining the rid and the locator of Node X, Node Y returns a data packet (Figure 10 (14)). Note that after this procedure, since the end nodes as well as the NMAs and the IMAs cache the mapping information, end nodes can send data packets without the signaling. If Node X wants to make its identity anonymous against eavesdroppers, it can execute the pid negotiation procedure before the data communication GU-Net to PU-Net Suppose that Node X (Node_X.unet.jp) exists in the GU- Net while Node Y (Node_Y.pnet.jp) exists in the PU-Net (i.e., the communication is via a NAT-like middle box). This signaling procedure is shown in Figure 11. First, Node X obtains Node Y s rid by the same way described in Sec (Figure 11 (1)). Second, Node X sends the Locator Request message to IMA-pnet.jp that contains Node Y s rid, and obtains the gateway s GU-Loc, instead of Node Y s PU-Loc (Figure 11 (2)). Obtaining Node Y s rid and the locator (i.e., the GU-Loc of the gateway), Node X sends a data packet (Figure 11 (3)). When the gateway receives the data packet, if it does not have the rid-to-locator mapping of Node Y, the mapping cache on the gateway sends the Locator Request message to L-IMA-pnet.jp and obtains the Node Y s PU-Loc (Figure 11 (4)). Next, it rewrites the locator fields of the ZNP header as shown in Figure 11 and forwards the data packet to Node Y (Figure 11 (5)). When Node Y receives the data packet, it sends the Locator Request message that contains Node X s rid to L-IMA-pnet.jp. Since L-IMA-pnet.jp knows that Node X s rid does not belong to its own domain, it returns the gateway s PU-Loc (Figure 11 (6)). Obtaining the locator (i.e., the PU-Loc of the gateway), Node Y sends the data packet (Figure 11 (7)). If the gateway does not have the rid-to-locator mapping of Node X, the mapping cache on the gateway sends the Locator Request message to IMA-unet.jp and obtains the Node X s GU-Loc (Figure 11 (8)). Obtaining the Node X s GU-Loc, the gateway rewrites the locator fields of the ZNP header and forwards the data packet to Node X (Figure 11 (9)). In the GU-Net, the locator fields of the ZNP header are filled with only the GU-Locs, and in the PU-Net, they are filled with only the PU-Locs. Thus, Node Y s PU-Loc is not known to the nodes in other domains. This achieves the avoidance of locator leakage (requirement (4)) GU-Net to L-Net Suppose that Node X (Node_X.unet.jp) exists in the GU- Net and Node Y (Node_Y.lnet.jp) exists in the L-Net (i.e., the communication is via the gateway that bridges different locator spaces). This signaling procedure is shown in Figure 12. Most of the procedure is the same as the procedure described in Sec , however, when the gateway forwards the data packet from Node X, it converts the ZNP header as follows: the locator fields of the ZNP header are replaced with the legacy L3 protocol header (Figure 12 (5)). In this case, the locator fields of the ZNP header are filled with

7 Figure 11: An example of ID and locator resolution: GU-Net PU-Net Figure 12: An example of ID and locator resolution: GU-Net L-Net only the Local Locators (LLocs). Thus, Node Y s LLoc is not known to the nodes in other domains. 4.5 Security of Mapping Registration The mapping between the node name and the node ID (name-to-id mapping) must be securely registered with the NMA and the mapping between the node ID and the locator (ID-to-Locator mapping) must be securely registered with the IMA to avoid impersonation and communication hijack. Since the name-to-id mapping is basically static, it can be assumed that the administrator of the domain to which the node belongs manually registers the name-to-id mapping with the NMA. A protocol to dynamically update the nameto-id mapping is not necessary. Thus, there is no security issue upon the registration of name-to-id mapping. On the other hand, the ID-to-Locator mapping is dynamically updated when a node changes its point of attachment to the network. The IMA must authenticate the node that requests to update the ID-to-Locator mapping. In ZNP, the Figure 13: implementation modules ID-to-Locator mapping of a node is always managed by the IMA in the domain to which the node belongs. Therefore, it can be assumed that the node and the IMA that manages the ID-to-Locator mapping of the node can share a secret key in advance. Since the node and its IMA share a secret key, they can establish a secure channel such as IPsec in the current Internet by using the secret key when necessary. Thus, registration of a malicious ID-to-Locator mapping can be avoided. 5. IMPLEMENTATION This section presents an implementation of ZCMP. The implementation is ongoing. 5.1 Modules ZNP and ZCMP are implemented in the user space of CentOS 5.5. ZNP and ZCMP consists of several modules. The relationship of modules is shown in Figure znpd This module is running on all nodes and processes ZNP. It provides the routing and fowarding functions. In the gateway, two znpd modules are running and they exchange packets through the PF_LOCAL sockets, which enable the gateway to rewrite the locator fields of the ZNP header. This module will be implemented in the kernel space in the future nmad / imad Nmad and imad are running as a daemon in the user space on the NMA and the IMA, respectively. Nmad provides the function of the NMA and imad provides the function of the IMA. They exchange the packet with znpd throuth the PF_LOCAL sockets. When the znpd module is implemented in the kernel, the normal sockets are used mapping_cache This module processes ZCMP on the gateway and caches mappings. It exchanges the packets with the znpd throuth the PF_LOCAL sockets. When the znpd module is implemented in the kernel, the normal sockets are used. 5.2 Experiment Network To verify the basic function of ZNP/ZCMP, we are using an experiment network shown in Figure 14. This network is composed of 16 virtual machines. In the L-Net, the IPv4 address is used as the locator. Note that the node_8 in Figure 14 is a locator conversion gateway, (i.e., it exists between the GU-Net and the PU-Net) and the node_13 in Figure 14 is a protocol conversion gateway, (i.e., it exists between the

8 Figure 14: An Experiment Network GU-Net and the L-Net). On these node, mapping cache is running. 5.3 Performance Evaluation In ZNP, since the data packet travels on the optimal route, there is no routing overhead in data communication. There are two kinds of overheads before the communication starts; one is the time for resolving the node ID from the node name (the ID resolving time) and another is the time for resolving the locator from the node ID (the locator resolving time). The ID resolving time would be the same as the time for resolving the IP address by DNS in the current Internet because the tree structure of the NMS in ZNP is similar to that of DNS. The ID resolving time (T id ) can be represented as T id = (T proc + RT T ) (n + 1), where T proc is the query processing time of the NMA or the IMA, RT T is the round trip time, and n is the number of hierarchy levels of the node name. The locator resolving time (T loc ) can be represented as T loc = (T proc + RT T ) (n + 2). If the requesting node has the cache, T id = T loc = 0. We measured the T proc and it became about µsec on a PC equipped with Intel R Xeon R CPU, 2.33 GHz. T proc is negligible in comparison with RT T which is in msec order. Thus, the ID resolving time and the locator resolving time mainly depend on the RTT if the requesting node does not have cache. 6. CONCLUSION This paper proposed the mapping systems of ZNP, a network layer protocol based on ID/Locator split approach in the future Internet. ZNP is designed to satisfy the following requirements in terms of practical operation: (1) support of L3 protocol heterogeneity, (2) scalability of ID/Locator mapping system, (3) independence of mapping information management, and (4) avoidance of locator leakage beyond the administrative boundary. The proposed mapping systems are also designed to satisfy these requirements. They are composed of the NMS, which manages the name-to-id mappings and the IMS, which manages the ID-to-Locator mappings. To satisfy (1), the IMS is designed to be able to manipulate the variable types of locators. To satisfy (2) and (3), the NMS and the IMS compose tree structures and the node s mapping information is managed by the mapping agents in the domain to which the node belongs. To satisfy (4), the Local NMA and the Local IMA are introduced. ZCMP was designed and implemented as an application layer protocol to manipulate the mapping systems. Measuring the signaling overhead, it was confirmed that the proposed mapping systems are practical for the future Internet. 7. REFERENCES [1] Christian Vogt. Six/One Router: a Scalable and Backwards Compatible Solution for Provider-Independent Addressing. In Proceedings of MobiArch 08, pages 13 18, Aug [2] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis. Locator/ID Separation Protocol (LISP), Apr Internet Draft, work in progress, draft-ietf-lisp-07. [3] Masahiro Ishiyama, Mitsunobu Kunishi, Keisuke Uehara, Hiroshi Esaki, and Fumio Teraoka. LINA: A New Approach to Mobility Support in Wide Area Networks. IEICE Transactions on Communications, E84-B(8): , Aug [4] Randall Atkinson, Saleem Bhatti, and Stephen Hiles. ILNP: mobility, multi-homing, localised addressing and security through naming. Telecommunication Systems, 42(3 4): , Dec [5] Pekka Nikander, Andrei Gurtov, and Thomas R. Henderson. The Host Identity Protocol (HIP): Connectivity, Mobility, Multi-Homing, Security, and Privacy over IPv4 and IPv6 Networks. IEEE Communications Surveys and Tutorials, 12(2): , Apr [6] S Schütz, Henrik Abrahamsson, Bengt Ahlgren, and Marcus Brunner. Design and Implementation of the Node Identity Internetworking Architecture. Computer Networks: The International Journal of Computer and Telecommunications Networking, 54(7): , May [7] V. P. Kafle and M. Inoue. HIMALIS: Heterogeneity Inclusion and Mobility Adaptation through Locator ID Separation in New Generation Network. IEICE Transactions on Communications, E93-B(3): , Mar [8] Anja Feldmann, Luca Cittadini, Wolfgang Mühlbauser, Randy Bush, and Olaf Maennel. HAIR: Hierarchical Architecture for Internet Routing. In Proceedings of the 2009 workshop on Re-architecting the Internet, pages 43 48, Dec [9] Jianli Pan, Subharthi Paul, Raj Jain, and Mic Bowman. MILSA: A Mobility and Multihoming Supporting Identifier Locator Split Architecture for Naming in the Next Generation Internet. In Proceedings of IEEE GLOBECOM 2008, pages 1 6, Dec [10] Sho Kanemaru and Fumio Teraoka. ZNP: A Network Layer Protocol Based on ID/Locator Split Considering Practical Operation. In Proceedings of IEEE International Conference on Communications 2011 (ICC2011), 6 pages, Jun