ZNP: A Network Layer Protocol Based on

ID/Locator Split Considering Practical Operation

Sho Kanemaru
Graduate School of Schience and Technology
Keio University
3-14-1 Hiyoshi, Kohoku-ku,
Yokohama, 223-8522, Japan
Email: satsuma@tera.ics.keio.ac.jp
Fumio Teraoka
Faculty of Science and Technology
Keio University
3-14-1 Hiyoshi, Kohoku-ku,
Yokohama, 223-8522, Japan
Email: tera@ics.keio.ac.jp
AbstractTo support mobility, multihoming, routing scalabil-
ity, and security, there are a lot of proposals based on ID/Locator
split approach not only for the current Internet but also for the
future Internet. However, none of them meet the requirements
for practical operation such as (1) support of heterogeneity of
network layer protocols, (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 a network layer protocol called Z
Network Protocol (ZNP) for the future Internet based on clean
slate approach. ZNP supports heterogeneity of network layer
protocols by Internetworking with a Common ID Space. Its
mapping system meets the requirements (2)-(4) described above.
Z Control Message Protocol (ZCMP) is also designed. Currently,
implementation of ZNP and ZCMP is ongoing.
Index TermsID/Locator split, future Internet, clean slate
approach, ZNP
I. 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 increases
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/Identier Separation Protocol (LISP)[2],
Location Independent Networking for IPv6 (LIN6)[3],
Identier-Locator Network Protocol (ILNP)[4], and Host Iden-
tity Protocol (HIP)[5] target to improve the current Internet. A
Node Identity Internetworking Architecture (NodeID)[6], Het-
erogeneity 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 Identier 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 practi-
cal 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 satised. (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 difcult
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.
AKARI Project[10], one of the projects based on clean slate
approach to redesign the Internet, proposes a new network
architecture called Z Network Architecture (ZNA)[11]. One of
the features of ZNA is to employ ID/Locator split to support
L3 protocol heterogeneity, mobility, and multihoming. This
paper proposes the network layer protocol of ZNA called ZNP.
ZNP satises the all requirements described above. The design
of ZNP has been completed and its implementation is ongoing.
II. RELATED WORK
There are many proposals based on ID/Locator split ar-
chitecture. 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 which is made by
concatinating the Locator (L) and Identier (I), i.e., L:I. ILNP
does not introduce a new layer such as HIP and MILSA. Thus,
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings
978-1-61284-233-2/11/$26.00 2011 IEEE
this makes it easy to deploy ILNP in the current Internet.
The mappings between name and identier and the mappings
between identier 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
identier 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 dened. In addition, as
the HIT does not have a hierarchical structure, it is difcult 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 networks gateway (GW-HN) to foreign networks
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 nodes
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 map-
ping 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
TABLE I
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
IMS service is not dened.
MILSA introduces the Hierarchical URI-Like Identier
(HUI) as the identier. 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 I 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 adminis-
trative boundary. TABLE I shows that ZNP supports all of the
requirements though no other work meets the all requirements.
III. Z NETWORK PROTOCOL
A. 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 multi-
level tree structure. However, it is very difcult to manage
the network that has such structures. Although there will exist
such network structures during a transition period, we assume
that the nal structure of the future Internet converges upon the
structure shown in Fig. 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
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings
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 protocol conversion function.
B. 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 xed length
binary data. The format of the ID is shown in Fig. 2. The
ID is composed of three parts: the Registry Identier, the
Organization Identier, and the Node Identier. The Node
Identier is assigned by an organization (e.g., Keio Univ.)
to which the node belongs. The Organization Identier is
assigned by a registry (e.g., JPNIC and APNIC) by which the
organization is managed. The Registry Identier is assigned
by an authority such as ICANN in the current Internet.
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 identier of a node and unique to the whole
networks. The pID is a temporary identier negotiated by the
end nodes before data communication starts. The pID is unique
to the communicating end nodes. As the 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 the 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.
IV. 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).
Clobal unlversal neLwork
(backbone neLwork)
Clobal unlversal
neLworks
(edge neLworks)
rlvaLe unlversal
neLworks
(edge neLworks)
Local neLworks
(edge neLworks)
unlversal LocaLor Space Local LocaLor Space
proLocol converslon gaLeway locaLor converslon gaLeway rouLer
Fig. 1. Assumed network structure of the future Internet
Crganlzauon
ldenuer
node ldenuer
4 byLes 10 byLes
- 8eglonal lnLerneL 8eglsLry number
- nauonal lnLerneL 8eglsLry number
- eLc.
16 byLes
8eglsLry
ldenuer
2 byLes
Fig. 2. ID format
C. Header Format
ZNP has two header formats: Type-1 and Type-2. Type-1
is used when both end nodes exist in the ULoc-Space. Its
header format is shown in Fig. 3 (a). Type-2 is used when
packets are forwarded in the LLoc-Space. Its header format is
shown in Fig. 3 (b). In Type-2, the ZNP header is encapsulated
by a legacy L3 protocol header. Thus, the ZNP packets are
transparent to the routers in the LLoc-Space, which means the
routers in the LLoc-Space do not need to be modied.
IV. MAPPING SYSTEMS
A. Mapping System Structure
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 Fig. 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 a tree structure 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
src lu
nexL header Lramc class ow label
dsL lu
dsL Loc
src Loc
payload lengLh hop llmlL ver.
Lype
/ag
0 8 13 31
src lu
nexL header Lramc class ow label
dsL lu
Legacy L3 Peader
(e.g., src loc, dsL loc, nexL hdr, hop llmlL, lengLh)
ver.
Lype
/ag
payload lengLh hop llmlL
0 8 13 31
(a)1ype-1 (b)1ype-2
Fig. 3. ZNP header formats
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings
local/
prlvaLe
space
rooL nMA
nMA
uneL.
lMA
nMA lMA
L-nMA L-lMA
nMA lMA
. . . . . .
. . .
. . . . . .
global
space
sub1.uneL. sub2.uneL.
Fig. 4. An example of a tree structure of the Name Mapping Agents and
the ID Mapping Agents
IMS is based on the hierarchical structure of the ID shown in
Fig. 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.
Fig. 4 shows an example of a tree structure of the NMS and
IMS that manages a domain unet and its two subdomains
sub1.unet. and sub2.unet. Suppose that sub1.unet
uses the GU-Loc (i.e., the global scope ZNP locator) while
sub2.unet uses the PU-Loc (i.e., the private scope ZNP
locator). For sub2.unet, 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 unet and
sub2.unet because sub2.unet is a PU-Net. The global
IMA of sub2.unet holds the mappings between the rIDs of
the nodes in sub2.unet and the GU-Loc of the gateway. The
L-IMA of sub2.unet manages the mappings between the
rIDs of the nodes in sub2.unet and their private locators.
Thus, by employing a tree structure, ZNP achieves the
scalability of the mapping systems (requirement (2)) and inde-
pendence 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)).
B. ZCMP Message
ZCMP is a protocol that manipulates mapping systems.
ZCMP denes four types of 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 NMAs and
the end nodes. The Locator Request message requests the
locator 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 gateways and the end
nodes. The Locator Registration Request registers the rID-
to-Locator or pID-to-Locator mappings with the IMA and
8ooL nMA
nMA
([p)
nMA
(uneL1.[p)
node_x.uneL1.[p
3 4
node_?.uneL2.[p
1 3
9
7
14
nMA
(uneL2.[p)
lMA
(uneL2.[p)
0
lMA
(uneL1.[p)
2
lu 8equesL/8eply
Loc 8equesL/8eply
uaLa Communlcauon
Loc 8eg 8equesL/8eply
lMA
(AnlC)
lMA
(!nlC)
10 11
12
8, 13 0
6
Fig. 5. An example of ID and locator resolution: intra GU-Net
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. III-B. These messages
are processed between the end nodes.
C. Signaling Examples
1) Intra GU-Net: In this example, 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 Fig.
5. Before the communication, the end nodes register their
own rID-to-Locator mappings with their home domains
IMA (Fig. 5 (0)). First, Node X sends the ID Request
message that contains the correspondent nodes name
(Node_Y.unet2.jp) to NMA-unet1.jp (Fig. 5 (1)). If
NMA-unet1.jp does not have the information of Node Y, it
forwards the query to the root NMA and obtains Node Ys
rID from NMA-unet2.jp (Fig. 5 (2)-(4)). Obtaining Node Ys
rID, NMA-unet1.jp returns the ID Reply message to Node X
(Fig. 5 (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 Ys rID to IMA-unet2.jp and
obtains Node Ys locator (Fig. 5 (6)). Obtaining Node Ys
locator, Node X sends a data packet to Node Y (Fig.
5 (7)). When Node Y receives the packet, it sends the
Locator Request message to IMA-unet2.jp to conrm whether
the source rID-to-Locator mapping in the ZNP header is
trustworthy (Fig. 5 (8)). If IMA-unet2.jp does not have the
information of Node X, it forwards the query to the root
NMA and obtains Node Xs locator (Fig. 5 (9)-(12)), and
returns the Locator Reply message to Node Y (Fig. 5 (13)).
Obtaining the rID and the locator of Node X, Node Y returns
a data packet (Fig. 5 (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.
2) GU-Net to PU-Net: In this example, 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
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings
nMA
(uneL.[p)
node_x.uneL.[p
locaLor
converslon
gaLeway
L-lMA
(pneL.[p)
node_?.pneL.[p
1
2
9
4
3
mapplng_cache
7
lMA
(pneL.[p)
3
<u-neL (pneL.[p)> <Cu-neL (uneL.[p)>
Zn Peader (proc.3)
Src Loc : Cu-Loc_node_x
usL Loc : Cu-Loc_gw
Src lu : lu_node_x
usL lu : lu_node_?
Zn Peader (proc.3)
Src Loc : u-Loc_gw
usL Loc : u-Loc_node_?
Src lu : lu_node_x
usL lu : lu_node_?
lu 8equesL/8eply
Loc 8equesL/8eply
uaLa Communlcauon
6
lMA
(uneL.[p)
8
Fig. 6. An example of ID and locator resolution: GU-Net PU-Net
communication is via a NAT-like middle box). This signaling
procedure is shown in Fig. 6. First, Node X obtains Node Ys
rID by the same way described in Sec. IV-C1 (Fig. 6 (1)).
Second, Node X sends the Locator Request message to
IMA-pnet.jp that contains Node Ys rID, and obtains the
gateways GU-Loc, instead of Node Ys PU-Loc (Fig. 6
(2)). Obtaining Node Ys rID and the locator (i.e., the
GU-Loc of the gateway), Node X sends a data packet (Fig.
6 (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 Ys PU-Loc
(Fig. 6 (4)). Next, it rewrites the locator elds of the ZNP
header as shown in Fig. 6 and forwards the data packet to
Node Y (Fig. 6 (5)). When Node Y receives the data packet,
it sends the Locator Request message that contains Node Xs
rID to L-IMA-pnet.jp. Since L-IMA-pnet.jp knows that
Node Xs rID does not belong to its own domain, it returns
the gateways PU-Loc (Fig. 6 (6)). Obtaining the locator (i.e.,
the PU-Loc of the gateway), Node Y sends the data packet
(Fig. 6 (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 Xs GU-Loc (Fig. 6 (8)). Obtaining the
Node Xs GU-Loc, the gateway rewrites the locator elds of
the ZNP header and forwards the data packet to Node X (Fig.
6 (9)). In the GU-Net, the locator elds of the ZNP header
are lled with only the GU-Locs, and in the PU-Net, they
are lled with only the PU-Locs. Thus, Node Ys PU-Loc is
not known to the nodes in other domains. This achieves the
avoidance of locator leakage (requirement (4)).
3) GU-Net to L-Net: In this example, 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 Fig. 7.
Most of the procedure is the same as the procedure described
nMA
(uneL.[p)
node_x.uneL.[p
L-lMA
(lneL.[p)
node_?.lneL.[p
1
2
9
4
3
mapplng_cache
7
lMA
(lneL.[p)
lMA
(uneL.[p)
3
<L-neL (lneL.[p)> <Cu-neL (uneL.[p)>
Zn Peader (proc.3)
Src Loc : Cu-Loc_node_x
usL Loc : Cu-Loc_gw
Src lu : lu_node_x
usL lu : lu_node_?
lu 8equesL/8eply
Loc 8equesL/8eply
uaLa Communlcauon
8
6
Zn Peader (proc.3)
Src Loc : LLoc_gw
usL Loc : LLoc_node_?
Src lu : lu_node_x
usL lu : lu_node_?
Legacy L3
proLocol
header
proLocol
converslon
gaLeway
Fig. 7. An example of ID and locator resolution: GU-Net L-Net
in Sec. IV-C2, however, when the gateway forwards the data
packet from Node X, it converts the Type-1 ZNP header into
Type-2; the locator elds of the ZNP header are replaced
with the legacy L3 protocol header (Fig. 7 (5)). In this case,
the locator elds of the ZNP header are lled with only the
Local Locators (LLocs). Thus, Node Ys LLoc is not known
to the nodes in other domains.
D. 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 name-to-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 dynami-
cally 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
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.
V. IMPLEMENTATION
This section presents the implementation of ZNP and
ZCMP. The implementation is ongoing.
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings
nmad
znpd
lmad
llnkd
nMA / lMA
l_LCCAL sockeL
l_lnL1 sockeL
mapplng_cache
pllnkd
pznpd uznpd
u-neL
(L-neL)
llnkd
<Cu-neL>
gaLeway
gaLeway / mapplng_cache
Fig. 8. implementation modules
A. Modules
We are implementing ZNP and ZCMP in the user space of
CentOS 5.4. ZNP consists of several modules. The relationship
of modules is shown in Fig. 8.
1) linkd: this module emulates the link layer in the user
space on all ZNP nodes. The IP address of a node is treated
as the L2 address of the node. This module is not necessary
when ZNP is implemented in the kernel.
2) znpd: This module processes ZNP in all ZNP nodes. 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 elds of the ZNP header. This module
will be implemented in the kernel space in the future.
3) nmad / imad: They process ZCMP in the NMA or IMA
as daemons in the user space. 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.
4) 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.
B. Performance Estimation
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
+RTT) (n+1), where T
proc
is the query processing
time of the NMA or the IMA, RTT 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
+RTT)(n+2). If the requesting node has the cache,
T
id
= T
loc
= 0.
According to the performance evaluation of our preliminary
implementation, T
proc
is about 180 sec on a PC equipped
with Intel(R) Xeon(R) CPU, 2.33 GHz. T
proc
is negligible in
comparison with RTT 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.
VI. CONCLUSION
We proposed 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) indepen-
dence of mapping information management, and (4) avoidance
of locator leakage beyond the administrative boundary. We
also designed ZCMP. We will implement ZNP/ZCMP and
verify the basic function of them to prove that the ZNP can
be a practical protocol in the future network.
ACKNOWLEDGMENT
We appreciate valuable comments from members of the
AKARI architecture design team.
REFERENCES
[1] C. Vogt, Six/One Router: a Scalable and Backwards Compatible Solu-
tion for Provider-Independent Addressing, in Proceedings of MobiArch
08, Aug. 2008, pp. 1318.
[2] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, Locator/ID Separation
Protocol (LISP), Apr. 2010, internet Draft, work in progress, draft-ietf-
lisp-07.
[3] M. Ishiyama, M. Kunishi, K. Uehara, H. Esaki, and F. Teraoka, LINA:
A New Approach to Mobility Support in Wide Area Networks, IEICE
Transactions on Communications, vol. E84-B, no. 8, pp. 20762086,
Aug. 2001.
[4] R. Atkinson, S. Bhatti, and S. Hiles, ILNP: mobility, multi-homing,
localised addressing and security through naming, Telecommunication
Systems, vol. 42, no. 34, pp. 273291, Dec. 2009.
[5] P. Nikander, A. Gurtov, and T. R. Henderson, The Host Identity
Protocol (HIP): Connectivity, Mobility, Multi-Homing, Security, and
Privacy over IPv4 and IPv6 Networks, IEEE Communications Surveys
and Tutorials, vol. 12, no. 2, pp. 186204, Apr. 2010.
[6] S. Sch utz, H. Abrahamsson, B. Ahlgren, and M. Brunner, Design
and Implementation of the Node Identity Internetworking Architec-
ture, Computer Networks: The International Journal of Computer and
Telecommunications Networking, vol. 54, no. 7, pp. 11421154, May.
2010.
[7] V. P. Kae and M. Inoue, HIMALIS: Heterogeneity Inclusion and
Mobility Adaptation through Locator ID Separation in New Generation
Network, IEICE Transactions on Communications, vol. E93-B, no. 3,
pp. 478489, Mar. 2010.
[8] A. Feldmann, L. Cittadini, W. M uhlbauser, R. Bush, and O. Maennel,
HAIR: Hierarchical Architecture for Internet Routing, in Proceedings
of the 2009 workshop on Re-architecting the Internet, Dec. 2009, pp.
4348.
[9] J. Pan, S. Paul, R. Jain, and M. Bowman, MILSA: A Mobility
and Multihoming Supporting Identier Locator Split Architecture for
Naming in the Next Generation Internet, in Proceedings of IEEE
GLOBECOM 2008, Dec. 2008, pp. 16.
[10] AKARI Architecture Design Project for New Generation Network,
http://akari-project.nict.go.jp.
[11] F. Teraoka, Redesigning Layered Network Architecture for New Gener-
ation Networks, in Proceedings of 2nd IEEE Workshop on the Network
of the Future, Dec. 2009, pp. 16.
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2011 proceedings