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 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 decomposing 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

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.

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.

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.

Cell. Hotspot 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.

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].

Com posed AN_C ASI_A FAc1 FAc2 FAc3 “Virtual FAs” Nam service c ing ASI_B Registry c AN_A FAa1 FAa2 FAa3 AN_B FAb1 FAb2 FAb3 Nam service b ing ANI Registry b ANI_C

Train Train PAN PA

Cell. Cell.


Nam service a ing Registry a

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: 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 nonroutable 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 decomposition. 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.
Com posed AN_C FAc1 FAc2 FAc3 “Virtual FAs” Nam service c ing 2 Registry c AN_A FAa1 FAa2 FAa3 Nam service a ing Registry a ANI 3 AN_B FAb1 FAb2 FAb3 Nam service b ing Registry b 1 ANI_C

compose to AN_C or wants to utilize some of the services from this composition.
A _C N A _C N
Fa A FA b Fc A 2 N ing am R egistry(N ) R (local, global)

N ingS am ervice

A _A N
Fa A FA b Fc A

R egistry

A I_C N A _B N
FA a Fb A Fc A


N ingS am ervice
R egistry

N ingS am ervice 3 4
R egistry

A _D N
Fa A Fb A Fc A

N ingS am ervice
R egistry

Figure 5: Identity lookup for a composed network (network integration) 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

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.

[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. draftmoskowitz-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.ambientnetworks.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.

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.

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.