ON THE EVOLUTION OF A NAMING & ADDRESSING
ARCHITECTURE IN VIEW OF DYNAMIC NETWORK
INTERCONNECTION
Christian Prehofer,
DoCoMo Euro-Labs, Munich, Germany, prehofer@docomolab-euro.com
Nick Papadoglou
Vodafone Group Services, UK, nick.papadoglou@vodafone.com
Martin Johnsson
Ericsson AB, SE-164 80 Stockholm, Sweden, martin.johnsson@ericsson.com
ABSTRACT
A key feature of future networking is the ability for networks
to cooperate by a composition. Composition is the concept
derived to describe the negotiation and construction of
‘dynamic interconnection agreements’ between networks.
The outcome of the composition procedure will e.g. lead to
resources in each network being shared by the other
network(s), or in one extreme that the networks merge into
one. This paper provides an analysis of the aspect of
composition and how it affects a naming & addressing
architecture for networks participating in this. It presents
the current state of namespaces, their association and the
way they are utilized today in the Internet and in the context
of Ambient Networks. We discuss name resolution and name
visibility for dynamic networks independent of a specific
naming layer and naming scheme. It describes the problem
statement of naming concepts from different networking
layers, concluding with the foreseeable solutions in the area
of naming and addressing in view of dynamic network
interconnections.
KEY WORDS
Ambient Networks, Dynamic internetworking, Composition,
Naming, Addressing, Address resolution
1. Introduction
THE integrated project “Ambient Networks” (AN) funded by
the EU, aims at an innovative, industrially exploitable new
network vision based on the dynamic composition of
networks to avoid adding to the growing patchwork of
extensions to existing architectures. Composition is our way
to simplify and automate cooperation between networks,
from the perspective of end users, service providers as well
as operators, thus enabling new business opportunities for
all parties [1].
This paper describes work undertaken in the context of the Ambient
Networks project which is part of, and partially funded by, the EU’s IST
programme.
Today, we have many naming concepts for “static” network
topologies, including mobile nodes. In the future, network
topologies will be more dynamic, e.g. moving networks.
While most research on moving networks focuses on
mobility management, we consider composing and de-
composing networks, including also the control and
management planes. In this paper, we focus on the impact of
name systems of such dynamic interworking.
Typically naming systems rely on hierarchical network
structures, address mappings and address resolution
infrastructure; consequently these aspects have to be adapted
in this context of composition so as to avoid any
configuration and performance (scalability) issues. This
affects naming on different levels such as the application,
SIP, telephony URI, DNS and IP.
We show several issues and approaches for more dynamic
and adaptive naming systems, resolved and optimized to
facilitate the concept of dynamic network interconnection
between networks in the future. Furthermore, we will
highlight that extended naming concepts and services are
essential for future ambient networking. These must be able
to cope with the highly dynamic networking environment
following the characteristics of ambient networking. And as
dynamic composition of networks creates new, convoluted
entities by combining networks in a dynamic way, the
naming concepts must also be flexible and adapted with
respect to this.
There is considerable research on mobility and routing
support for moving networks [7]. In these efforts,
reachability issues and hand-off is considered based on
existing naming and mobility solutions such as mobile IP. In
contrast, our work considers the problems from first
principles and is not bound to specific mobility solutions.
1.1. Composition and composition use cases
In order to support the cooperation of future heterogeneous
and moving networks, a generic solution of network
composition is developed in the Ambient Networks project
[1]. Composition is an umbrella concept that covers a
number of use cases where agreements between Ambient
Networks are negotiated and implemented dynamically. We
first give a high-level description of several composition use
cases. The intention is to illustrate the applicability of the
concept, as well as to provide use cases to illustrate the
thinking behind the architecture development.
Cell.
Hotspot
PAN PAN
Figure 1: Moving Personal Area Network (PAN)
Figure 1 illustrates the scenario of a hotspot network (e.g., a
WLAN) composing with a cellular network. The composed
AN can offer seamless mobility services to e.g. PAN users.
In addition, the composed AN can provide improved
offering of access alternatives with consistent QoS features.
An alternative scenario is depicted in Figure 2 where a PAN
AN composes with a moving network, e.g., an AN located
on a train. The PAN can share the resources of the moving
network, e.g., the connectivity with a cellular operator. This
facilitates the mobility management of the networks that
compose with the train network, since they can rely on the
mobility management of the train network.
Cell.
Cell .
Train
Train
PAN
PA
PAN
Figure 2: Scenario with two moving networks
Our general framework for composing networks is
illustrated in Figure 3, where two ambient networks, A and
B, are composed to form network C. A generic interface,
called Ambient Networks Interface (ANI) is used to
implement network composition, whereas the Ambient
Service Interface (ASI) provides the interface through which
applications can gain access to services collectively offered
by the interconnected Ambient Networks. After
composition, the two networks look and act like a new
network to the outside, here called AN C. Each network may
have internal entities, called Functional Areas (FAs), as well
as services like name resolution and directories. The
assembly of these internal entities forms the Ambient
Control Spaces (ACS) [1]. For composition, the problem is
how to combine these services and functions to a new
network in a smooth way. There are several levels of
composition [2][9] depending on which entities are visible
to the outside and how much control the networks are
sharing. We distinguish three main cases:
• Network Integration, i.e., one part takes over
control of the other, or they merge into a new AN
with a new identity.
• Control Sharing, i.e., responsibility is distributed
between two networks, as fixed in an agreement.
E.g. name resolution is done by one network only.
• Network Interworking, i.e., composition is limited
to basic data forwarding and control interaction is
reduced to a minimum.
For instance, in Figure 3, the composition creates a new
network AN_C, which consists of the two inner ANs. This
AN_C may provide external functions which are only
“virtual”, as they are mapped directly to the inner ANs. For
instance, AN_C may provide a specific discovery service by
mapping it to a service of network AN_B,
As a further extension, one network may be involved in
multiple compositions in parallel, e.g., the user’s PAN may
establish one or more parallel compositions with some
friends while maintaining the composition with the home
network. The establishment (or the rejection of an initiation
of a composition) is based on policies and rules that lead for
instance to different trust relationships within the individual
compositions [8].
ASI_C
Composed AN_C
FAc1 FAc2 FAc3 “Virtual FAs”
ASI_A
Naming service c ASI_B
Registry c
AN_A AN_B ANI_C
FAa1 FAa2 FAa3 FAb1 FAb2 FAb3
Naming service a
Naming service b
Registry a ANI
Registry b
Figure 3: Internal entities in a composed ACS
1.2. Naming concepts and related work
The current Internet basically consists of the following two
naming layers:
1) A hierarchical naming layer with explicit names on
resources, such as those managed by the DNS
2) A hierarchical set of addresses, suitable for routing,
e.g. IP addresses, used for the data transport in the
internetworking layer.
With the introduction of SIP, another layer of
addressing/naming will form an integral part of the Internet.
While the Internet does not distinguish between identity and
location, this is needed and already implemented in mobile
networks. This locator/identifier split is used in Mobile IP
(home vs. visiting address), cellular system (IMSI, TMSI) as
well as in a new approach now under discussion within
IETF. Here, a new naming layer called Host Identity
Protocol (HIP) [3] has been presented based on the use of
cryptographic identifiers. Those identifiers play a key role in
securing the access to different resources in the network, and
could also be used to facilitate mobility management
functions. There are currently several research efforts on
new naming solutions for mobile networks and the Internet
[4] [5] [6]. However, these approaches do not address the
issues of dynamic, moving networks.
Several other new approaches like TurfNet [11], FARA [12]
and Plutarch [13], introduce more radical naming concepts
for internetworking between autonomous and heterogeneous
network domains. For instance, FARA and TurfNet provide
address translation at network boundaries, which make the
composition of heterogeneous networks significantly
simpler. Turfnet also includes both vertical and horizontal
composition of networks. Vertical composition means
inclusion with respect to the data plane forwarding, while
horizontal is similar to peering and to our above notion of
composition. Plutarch employs similar translations that are
called interstil functions. While the above papers introduce
several powerful concepts that we can use as a basis, they do
not address our problems of name resolution and name
visibility as discussed below.
In the Ambient Networks project, we adopt a more generic
form of names, in order to accommodate different future
naming schemes. It shall be specifically noted that current
Internet lacks support for both security and mobility, which
are both key for future networking concepts.
To summarize, we consider the following layers
1) Application layer points of attachment, e.g. SIP
addresses, which are resolved via an application
specific infrastructure like SIP servers.
2) A hierarchical naming layer with explicit names,
such as DNS.
3) An identifier space, e.g. HIP or mobile IP home
address, of possibly non-hierarchical flat and non-
routable addresses. These addresses are used for
identification and possibly for mobility
management.
4) A possible hierarchical set of addresses, suitable for
routing, e.g. IP addresses, used for the data
transport.
Further assumptions have been made for name resolution
and bindings as follows:
1) SIP addresses need to be resolved into routable
addresses at the internetworking layer.
2) Named resources need to be resolved into routable
addresses at the internetworking layer.
a. This holds for both DNS and other
identifiers.
As we have up to four naming layers, the resolution of a
name may take several resolutions steps, each time querying
some infrastructure for a resolution into an address at
another (possibly lower) layer. Such a name resolution
infrastructure, like a DNS server, is typically a distributed
database. Hence often several servers have to be queried.
The layering is not strict which means that the name
resolutions do not strictly resolve to names in the layer
below. Hence the number of resolutions depends on the
setting and how addresses are used. For instance, SIP
addresses may map directly to locators or identifiers. Also,
cryptographic addresses like HIP addresses are possibly
negotiated between end hosts, hence no resolution is needed.
However, a binding between identifiers and locators is
established in this case in the nodes.
The focus of this paper is to discuss the problems of names
and their resolution in the context of network composition,
as discussed in the following section. The fact is that
network composition affects hierarchical name structures as
well as the name resolution mechanisms. We do not focus
on a specific naming system and keep our analysis generic
for different naming systems.
2. Naming concepts and Dynamic Networks
In this section, we discuss the effect of dynamic networks on
naming concepts. As network composition creates new
entities by combining networks in a dynamic way, the
naming concepts must be flexible with respect to this. After
dynamic composition of networks, new names are needed
for the internal entities of an AN to be addressed internally
and also externally through the ANI and possibly also the
ASI.
After composition new names are needed for the internal
entities of an AN to be addressed either internally as well as
externally through the ANI (or ASI). All of these entries and
mappings are kept in the registry of the new naming service
function as well as in the two or more composed networks.
Based on Figure 3, we can examine the effect of
composition. We can see that the new, composed AN has
conceptually new functions and common services. As
discussed in the previous section these functions do not need
to be physical but only logically residing at the entities of
the different networks control spaces. Alternatively, they
may be real components which are created for the composed
network and which have their own internal control logic and
data.
The main issues with respect to naming and composition
are:
• The new, composed AN has common services and
functions which are distinct from the inner ANs.
• Visibility of the inner ANs depends on the kind of
composition. In case of Network Integration, a fully
integrated, new ACS is created, and the inner
functions are not visible outside any more. They can
however be accessed via the new, virtual functions.
In other cases, which are the more typical cases, the
inner functions are still visible outside.
Several further questions arise and can be identified such as:
 • Scope of the name & address space (e.g. local V/S
global)
• The possibility of the need for re-naming of objects
and re-allocation of addresses.
• Name & address re-direction.
• The dynamic nature, i.e. not only composition but
also the possibility of de-composition.
• The implications and how they differ in different
network contexts, e.g. between a PAN and a home
area network, and between two network operators.
• System properties with respect to scalability,
robustness & resilience, and performance.
An important aspect during the composition negotiation
phase is that of internal naming and addressing allotment. In
particular, composition can lead to naming conflicts. Three
typical options have been identified as follows:
• Prohibit conflicts by design, usually in the case where
hierarchical namespaces are used
• Mapping, usually through a NAT or similar functions
at the network boundaries
• Re-naming of internal entities.
This naming and addressing negotiation phase is important
to facilitate the proper and efficient operation of the
networks during the composition phase and avoid any
conflicts. The latter two cases would require the use of
naming registry keeping state of the previous internal
addresses for the proper operation of the network after de-
composition.
2.1. Naming problems on different naming layers
We can analyze the following naming problems regarding
composition depending on the different naming layers:
1) Visibility of names and creation of new names
under composition, e.g. when a network is
integrated into another, composed network.
2) The name resolution infrastructure has to account
for the changes, in particular for hierarchical
names.
3) Efficient resolution of names, i.e. reduce number of
in-directions. Name & address spaces need to be
efficiently managed, for efficient routing and
efficient name-to-address resolution mechanisms.
4) Address mappings in nodes may be affected and
may have to be changed after composition.
Regarding the 1st case, visibility means that names may
disappear externally during composition – hidden inside
another network, and other names are created newly. This
affects the application layer names as well as the DNS
names. More precisely, visibility of the inner ANs depends
on the kind of composition. In case of Network Integration,
a fully integrated, new ACS is created, and the inner
functions are not visible outside any more. They can
however be accessed via the new, virtual functions. In other
cases, which are more typical, the inner functions are still
visible outside.
With the 2nd case, name resolution is done by dedicated
servers, which possibly exist locally for each network. As
resolution is often done hierarchically, this hierarchy
changes under composition and affects the resolution
process. Furthermore, composition via several address
resolution steps is often more flexible and also robust vs.
topology changes, but can be inefficient, based on the 3rd
case presented above. On the other hand, using direct
references to naming servers may lead to issues with
outdated or invisible references. Finally, the 4th case
explores the case where there is the need to update the
mappings, stored internally in many nodes, in case
something changes. For example, when a DNS name
changes, which is mapped to another address, this needs to
be updated in each node where it has been stored (cashed).
We need to distinguish that some naming layers are
organized in a hierarchical fashion, like DNS, while others
are not. For hierarchical systems, these can fit nicely with
the structure of network composition. In the following, we
will show how composition affects the above issues.
2.2. Hierarchical naming and name resolution for
dynamic networks
In the following, we show how name resolution can take
place, based on a hierarchical naming scheme. We assume a
generic naming schemes as discussed above and show how
additional mechanisms for name resolutions are suitable for
our scenario.
Based on the above requirements, we use qualified,
hierarchical names, which can be resolved in a flexible way
such that composition can take place in a transparent way
with respect to references. For instance, consider a message
to a function b1 of a network AN_B is addressed as
AN_B.b1. We consider resolving this name in a setting with
network composition, as illustrated in Figure 4 for the
composition case of network integration. As AN_B is now
part of the composed AN_C, the name is resolved by
contacting the composed AN, i.e. AN_C. The request (1) is
directed to the composed naming services (2), which may
redirect it to AN_B (3), since it keeps a mapping of the
internal addresses.
We assume that two ANs may use the identical names for
different entities. This affects both the control plane (ACS)
and also the user plane, which however is not the focus of
this paper. For the control plane, we assume that the naming
system and name resolution have to be hierarchical, which
means that addresses may only be valid locally and globally
and a prefix is needed for a fully valid address. In this way,
it is possible to address entities within ANs uniquely even
after composition. For instance, function a1 in AN A may be
addressable as AN_A.a1 or via the composition
AN_C.AN_A.a1. In this way, the new names are created at
composition. Furthermore, this implies that names cannot be
fully resolved at the sender, as the AN_B may not be visible
to the outside.
Let us now consider the cases of name resolution in a more
general setting. We assume a name registry (NR), which
serves as a repository for names, depicted in Figure 5. The
NR keeps all records of different network identities and acts
as a rendezvous point for networks that require
communicating or forming a new composition. While we
show this as a single entity, a real implementation would
very well be distributed for scalability reasons.
Composed AN_C
FAc1 FAc2 FAc3 “Virtual FAs”
Naming service c
2
Registry c
AN_A AN_B
3
FAa1 FAa2 FAa3 FAb1 FAb2 FAb3
Naming service a
Naming service b
Registry a ANI
Registry b
Figure 4: Name resolution in combined ACSs with network integration
The new virtual functions should also be able to direct a
request for composition from a network to one of the already
composed networks. If we consider the same composition
example as above, networks A and B resulting to a newly
composed network C, and a third network wants to compose
to one of the two (e.g., A) and not to the whole composed
network C which the ANI broadcasts then it should be able
to do so. When the new composed network forms, it needs
to register with the external NR in order to be able to be
found. In that entry, it should also note that through this
composition some other networks could be contacted
individually by traversing the request through this newly
composed network. The ANI_C will have the capabilities of
forwarding the request of another network (network D)
wanting to compose to network A (see Figure 5).
The communication is still over the ANI_C, which is
responsible to convey control information for the newly
composed networks. This procedure enables a network to
compose with another network (which might already be
composed) as long as it knows its identity (AN identifier).
Otherwise, during the discovery procedure it will only be
able to see network C (through ANI_C) and negotiate a
composition with that network. In this way, if network D
had previously composed with network A it can do the same
even though now network A has composed with other
networks.
Features like policies and security will be negotiated during
the new composition between network A and D without
affecting the virtual ACS of network C, since they are
independent. It is the responsibility of the network A naming
service now to resolve any naming or addressing issues that
may conflict with the composed network C and convey that
into the new composition process. Note that the policies and
security features of the composed network (AN_C) will only
be affected, be part of the composition negotiation between
AN-A and AN_D, if AN_D indicates that it wants to
compose to AN_C or wants to utilize some of the services
from this composition.
AN_C
Naming
AN_C Registry(NR)
FAa FAb FAc (local, global)
2
NamingService
ANI_C
Registry 1
AN_A AN_B
FAa FAb FAc FAa FAb FAc
1 NamingService NamingService
3 AN_D
Registry Registry
ANI_C FAa FAb FAc
4
NamingService
Registry
Figure 5: Identity lookup for a composed network (network integration)
In summary, our proposal is to use hierarchical naming for
hierarchical composition. We do however not fully hide the
internal networks, as they may still be able to compose with
other networks that have their internal identity. Such a case
can happen in the above example of Figure 1, if we add
multihoming. This means that the PAN composes with both
the train network and the cellular network individually, but
not with the composition of both.
2.3. Name resolution & performance issues
The dynamic nature of ambient networking puts challenges
on the design for suitable name resolution mechanisms. Not
only can a resource change its locator due to mobility, but
resources may also come and go in a highly dynamic way
due to mobility and network composition. It is likely that
current DNS as well as current routing protocols won’t be
able to address the new requirements stemming from
ambient networking, and need to be changed and/or
augmented. Here some issues and alternatives are sketched
to provide some insights into the problem space, but which
calls for further analysis and measurements.
Local V/S global locators
As networks can move and connect at different points of
attachment to an infrastructure, as well as operate on their
own, using locally assigned locators for those networks
seem feasible. Then on the other hand, routing must work on
a global scale, also incorporating moving networks; a global
routing overlay can be envisioned. The inter-operation of
ANs with locally assigned locators in combination with a
global name space must be addressed by the internetworking
architecture provided by the ACS. This must also include
proper correlation of user plane and control plane
operations, e.g. for mobility management.
Resource names and resolution to locators
As resources may come and go in a highly dynamic way, or
change to a new locator mapping, the resource & binding
updates shall preferably be localized, otherwise the overall
internetwork will be overwhelmed with name binding
updates. A filter and/or ‘resource marking’ mechanism can
also be envisioned to limit the frequency and/or the scope of
updates as a resource can come and go frequently.
Policy-based networking
Ambient networking neither is, nor can be just an open
space of implicitly trusted players. The propagation of
resource and address information will be bounded to policies
[10]. Re-iterating the fact that ambient networking is a
highly dynamic network environment, policies must be an
intrinsic part of the mechanisms and methods providing the
means for propagation of different types resource and
locator information. Identification and authorization &
scoping will be instrumental for the overall implementation
and performance of such mechanisms and methods. Thus,
the transparency as to which level and detail address
resolution will work across different networks, can be
afftected and controlled by policies.
It should be noted that the ambient network vision opts for
the possibility that also resources in PANs or home networks
can offer services to other networks, and possibly also do
that on commercial terms.
Flat V/S hierarchical name spaces
How different name spaces shall be structured is very much
an issue of how they shall and can be (efficiently) managed.
This is a discussion that has been specifically addressed in
the scope of Host Identities and the Host Identity Protocol,
but also in different peer-to-peer technologies, in which case
Dynamic Hash Tables has been in the focus for
administrating a flat name space. When setting up the
criteria to find a suitable architecture, trade-offs must be
searched for in areas of OPEX, scalability, extendibility,
flexibility, open-ness, and manageability.
3. Conclusion
We have identified the main issues of future naming
solutions for dynamic networking environment. We have
addressed several problems when networks compose in a
dynamic way and combine their internal resources. We
have shown name resolution and name visibility for dynamic
networks, independent of a specific naming layer and
naming scheme. Our approach can be implemented by
extending naming systems currently discussed in the
research community, based on hierarchical or flat naming
layers and name resolution. We have shown the different
issues of name visibility, name resolution and conflict
handling and presented first solutions for several basic
cases. Future work has to address performance issues in
order to evaluate the different solutions. We hope this
research addresses the needs of future mobile networks,
which can connect in more sophisticated ways and which
integrate their services.
References:
[1] N. Niebert, A. Schieder, H. Abramowicz, G. Malmgren, J.
Sachs, U. Horn, C. Prehofer, and H. Karl, “Ambient networks:
An architecture for communication networks beyond 3G,”
IEEE Wireless Communications, vol. 11, pp. 14-22, Apr.
2004.
[2] C. Kappler, P. Mendes, C. Prehofer, P. Pöyhönen, Di Zhou, A
Framework for Self-organized Network Composition, WAC
2004 (IFIP Workshop on Autonomic Communication), Berlin,
Germany
[3] Robert Moskowitz. Host Identity Protocol Architecture. draft-
moskowitz-hip-arch-06 (work in progress), June 2004.
[4] H. Balakrishnan et. al. A Layered Naming Architecture for the
Internet. In Proceedings of ACM SIGCOMM 2004, Portland,
Oregon, USA, August 30 - September 3, 2004.
[5] Clark, D., Braden, R., Falk, A., and Pingali, V., "FARA:
Reorganizing the Addressing Architecture". In Proceedings of
SIGCOMM Workshop on Future Directions in Network
Architecture (FDNA-03), Karlsruhe, Germany, August 27th,
2003.
[6] T.Okagawa et al, IP Packet Routing Mechanism Based on
Mobility Management in IP-based IMT Network Platform,
International Conference on Intelligence in Networks 2003,
[7] Eranga Perera, Vijay Sivaraman, Aruna Seneviratne, Survey
on network mobility support, , April 2004 ACM
SIGMOBILE Mobile Computing and Communications
Review, Volume 8 Issue 2
[8] Frank Pittmann (Ed.), D-1-8 Ambient Networking - Concepts
and Architecture, available at http://www.ambient-
networks.org/
[9] Jorge Andrés Colás,, (Ed.) D-3-2 Connecting Ambient
Networks – Architecture and Protocol Design and Technical
Annex, available at http://www.ambient-networks.org/
[10] Dinesh C. Verma , D. C. Verma, Policy-Based Networking:
Architecture and Algorithms, New Riders Publishing,
Thousand Oaks, CA, 2000
[11] Stefan Schmid, Lars Eggert, Marcus Brunner and Jürgen
Quittek. Towards Autonomous Network Domains. Proc. 8th
IEEE Global Internet Symposium, Miami, FL, USA, March
17-18, 200
[12] Dave Clark, Robert Braden, Aaron Falk and Venkata Pingali.
FARA: Reorganizing the Addressing Architecture. Proc.
ACM SIGCOMM Workshop on Future Directions in Network
Architecture (FDNA), Karlsruhe, Germany, August 2003, pp.
313-321.
[13] Jon Crowcroft, Steven Hand, Richard Mortier, Timothy
Roscoe and Andrew Warfield. Plutarch: An Argument for
Network Pluralism. Proc. ACM SIGCOMM Workshop on
Future Directions in Network Architecture (FDNA),
Karlsruhe, Germany, August 2003, pp. 258-266.
DISCLAIMER: This paper describes work undertaken in the
Ambient Networks project, which is part of the EU’s IST
programme. In total, 41 organizations from Europe, Canada,
Australia and Japan are involved in this project, which will
run from 2004-2005 in its first phase. The views and
conclusions contained herein are those of the authors and
should not be interpreted as necessarily representing the
Ambient Networks project.