A Subscription Management System (SMS)in Mobile Internet Services (MISER)

Mohammad Ali Shokri

TRITA-NA-E05004

NADA

Numerisk analys och datalogi Department of Numerical AnalysisKTH and Computer Science100 44 Stockholm Royal Institute of Technology

SE-100 44 Stockholm, Sweden

A Subscription Management System (SMS)in Mobile Internet Services (MISER)

Mohammad Ali Shokri

TRITA-NA-E05004

Master’s Thesis in Computer Science (20 credits)Single Subject Courses,

Stockholm University 2005Supervisor at Nada was Kai-Mikael Jää-Aro

Examiner was Lars Kjelldahl

Abstract

There are multiple ways to access the existing and being developed Internet application services that are growing in number every day. Due to this fact it becomes extremely difficult to provide similar services for each particular access. Therefore we need services which can be reused by different applications to support application services, thus adding “mobility support services” to them. Domain Name Service (DNS) is one example, which can be reused by different applications but mobility support requires many more services to cope with the issues of reachability, session handover, presence in the network, addressing of network entities (people, devices, services and content), etc.

Considering the above, a service architecture common across applications is needed to support various applications’ demands in mobility management. The aim of my Master’s thesis project, performed at Ericsson Research, was to design and build a Subscription Management System (SMS) in Mobile Internet SERvices (MISER) for a set of services organized in a modular way.

In order to activate service(s) for a user, SMS creates an account for the user. Creation of the account results in obtaining an identifier, for example ali@findplayer.com, which will be used later to manage the account and to perform various operations in MISER, like locating users, profiling users, system security, etc.

During the work a special protocol was designed that supports the exchange of information between SMS and different Internet applications in a byte stream format.

MISER should be considered as an open system that can be used by any Internet application system, which means allowing the addition and removal of other services into the infrastructure. To add a new service in MISER, SMS reads the new service’s specification file, which is about each service database (each service has a database in MISER) structure and default values and then adds the new service into the system.

The next problem was to have “ flexible subscriptions” . It means that the SMS provides the possibility to add, delete, enable, and disable service(s) for a user. For this functionality SMS looks for the user’s database (LDAP database) and updates the information.

I provided a web user interface to manage subscription requests. This web user interface takes subscription requests, sends them to SMS, gets back the answers and shows them to the user.

Ett abonnemangshanteringssystem (SMS) i mobila Internettjänster (MISER)

Sammanfatning

Det finns många sätt att komma åt de Internet tjänster som finns och är under utveckling och växer i antal för varje dag. På grund av de faktum är det mycket svårt att ordna samma tjänster för varje enskild åtkomst. Därför behöver vi tjänster som kan återanvändas av olika program för att stödja programmens tjänster. Sådana tjänster kan kallas för “ tjänster som stöder mobilitet” . Domain Name Service (DNS) är ett exempel som kan användas av olika program, men för mobil hantering behövs andra tjänster för att klara nåbarheten, sessionsöverlåtelse, närvaro i nätverk, adressera nätverksenheter (folk, verktyg, service, innehåll), etc.

Med hänsyn till detta behövs det en arkitektur av tjänster som krävs i mobil hantering för att stödja olika program. Målet för mitt examensarbete, utfört på Ericsson Research, var att designa och implementera ett abonnemangs hanterings system (SMS, Subscription Management System) i Mobile Internet SERvice (MISER) för en grupp av tjänster organiserade i modulär form.

För att aktivera en tjänst/tjänster för en användare, skapar SMS ett konto för varje användare. Att skapa ett konto resulterar i att en identifikation skapas för varje användare, till exempel ali@findplayer.com som senare ska användas för kontoadministration och olika operationer i MISER som att lokalisera användare, profilera användare, systemsäkerhet, etc.

Under projektets gång har vi designat ett specialprotokoll för informationsutbyte mellan SMS och olika Internetapplikationer i ”byte ström” -format.

MISER är ett öppet system som kan användas av alla Internetprogramsystem. Det betyder att tilläggning och borttagning av tjänster är möjligt i strukturen. För att lägga till en ny tjänst i MISER, läser SMS först en specifikation fil. Filen innehåller information om den nya tjänstens databas (varje tjänst har en databas i MISER) struktur och fördefinierade värden. Sedan lägger SMS till den nya tjänsten i MISER.

Nästa problem var att ha ”flexibelt abonnemang”. Det betyder att SMS ordnar möjligheten att lägga till, ta bort, slå på och av en tjänst/tjänster för en användare. För den här funktionen söker SMS efter användarnas databas (LDAP-databas) och uppdaterar informationen.

Jag gjorde ett webbgränssnitt för att hantera abonnemangsfrågor. Webbgränssnittet tar abonnemangsfrågor, skickar till SMS, får tillbaks svaret och visar det för användaren.

Preface This report is the documentation of my Master’s thesis project in Computer Science at NADA, Stockholm University. The work was carried out at Ericsson Research.

My advisor at Ericsson was Yuri Ismailov and at NADA my advisor was Kai-Mikael Jää-Aro.

I thank them for their help, enthusiasm, and energy.

Contents 1 INTRODUCTION ................................................................................................................................................... 1

1.1 PROBLEM ............................................................................................................................................................ 1 1.2 THESIS BACKGROUND ......................................................................................................................................... 1 1.3 PURPOSE AND DELIMITATION.............................................................................................................................. 2 1.4 OUTLINE OF THIS DOCUMENT.............................................................................................................................. 2

2 BACKGROUND ...................................................................................................................................................... 4

2.1 THREE-LAYER MODEL........................................................................................................................................ 4 2.2 INTERNET PROTOCOLS........................................................................................................................................ 6 2.3 IP SERVICES........................................................................................................................................................ 8 2.4 IPV6 ................................................................................................................................................................... 9

3 RELATED WORK ................................................................................................................................................ 11

3.1 PROBLEMS WITH MOBILE NETWORK ................................................................................................................ 11 3.2 EARLY SOLUTIONS............................................................................................................................................ 11 3.3 MOBILE IP......................................................................................................................................................... 12 3.4 MOBILE IPV6.................................................................................................................................................... 13 3.5 LINA .................................................................................................................................................................. 13 3.6 SERVICE LOCATION PROTOCOL ........................................................................................................................ 14 3.7 ADVANTAGES AND DISADVANTAGES................................................................................................................ 16

4 PROPOSED SOLUTION ..................................................................................................................................... 17

4.1 MOBILITY IMPLICATIONS FOR SERVICE ARCHITECTURE .................................................................................. 17 4.2 MOBILE INTERNET SERVICE (MISER) ARCHITECTURE................................................................................... 19

4.2.1 Architecture Overview ............................................................................................................................. 20 4.2.2 Location/Name Resolution Service ......................................................................................................... 20 4.2.3 Security Service ....................................................................................................................................... 21 4.2.4 User Profile Service................................................................................................................................. 21 4.2.5 Notification Service ................................................................................................................................. 21 4.2.6 Session Profile Service............................................................................................................................. 22

5 SMS......................................................................................................................................................................... 23

5.1 SPECIFICATION OF SMS SOFTWARE REQUIREMENT .......................................................................................... 23 5.2 SMS ARCHITECTURE ........................................................................................................................................ 24

5.2.1 Design method ......................................................................................................................................... 24 5.2.2 Decomposition description....................................................................................................................... 25 5.2.3 Usage Scenario......................................................................................................................................... 25 5.2.4 Architecture.............................................................................................................................................. 25

5.3 COMPONENT DESCRIPTION ............................................................................................................................... 26 5.3.1 The Main Module..................................................................................................................................... 26 5.3.2 The LDAP Module................................................................................................................................... 26 5.3.3 The Specification File Parser Module...................................................................................................... 27 5.3.4 The Services Interface Module................................................................................................................ 28 5.3.5 The Web Interface Module...................................................................................................................... 28 5.3.6 The Protocol Module................................................................................................................................ 28

6 EVALUATION AND CONCLUTION ............................................................................................................... 29

6.1 EVALUATION..................................................................................................................................................... 29 6.2 CONCLUTION..................................................................................................................................................... 30

REFERENCES.......................................................................................................................................................... 31

APPENDIX A: STRUCTURE OF LDAP AND SERVICE SPECIFICATION FILE ...................................... 33

A.1 LDAP............................................................................................................................................................... 33 A.2 SERVICE SPECIFICATION FILE .......................................................................................................................... 33

A.2.1 Protocol Format Description................................................................................................................... 35 A.3.2 Operation Code Description.................................................................................................................... 36 A.3.3 Sub Code Description.............................................................................................................................. 36 A.3.4 Data Field Description Bytes 8-9-…....................................................................................................... 36

APPENDIX B: MSC (MESSAGE SEQUENCE CHART)................................................................................... 37

B.1 GETTING INFORMATION FROM THE SPECIFICATION FILE .................................................................................. 37 B.2 LOGGING FOR DELETE AND UPDATE AN ACCOUNT .......................................................................................... 38 B.3 LOGGING FOR ADD, DELETE, ENABLE, DISABLE A SERVISE ............................................................................ 39 B.4 ACCOUNT CREATING........................................................................................................................................ 40 B.5 ACCOUNT DELETING........................................................................................................................................ 41 B.6 ACCOUNT UPDATING ....................................................................................................................................... 42 B.7 GETTING ACCOUNT INFORMATION .................................................................................................................. 43 B.8 DELETE SERVICE.............................................................................................................................................. 44 B.9 ADD SERVICE ................................................................................................................................................... 45 B.10 ENABLE SERVICE ........................................................................................................................................... 46 B.11 DISABLE SERVICE .......................................................................................................................................... 47

APPENDIX C: USER END WINDOWS................................................................................................................ 48

C.1 CREATE ACCOUNT ........................................................................................................................................... 48 C.2 CREATE ACCOUNT CONTINUE .......................................................................................................................... 49 C.3 DELETE ACCOUNT............................................................................................................................................ 50

1

1 Introduction

This document is about a system that supports mobile networks and my work was to design and implement a management system for user subscription. This chapter describes very briefly the problem, background, purpose and delimitation of my thesis.

1.1 Problem There are many new wireless devices to access the network. It becomes more and more common for people to perform work away from the office and many people have the opportunity and preference to work at home or during travel.

The movement of wireless network devices may possibly introduce a momentary pause in the operation, but it should not require reinitiating of network connections. The existing set of network protocols does not meet this requirement since they were designed with the assumption of a stationary network topology where hosts do not change their location over time.

Mobile end systems frequently change their point of attachment to the network. In such an environment, in order for mobile devices to run without disruption, an internetworking infrastructure is needed.

In addition we need an internetworking infrastructure that supports the reachability of people who connect to the network with difference wireless devices at same place or on movement.

1.2 Thesis Background There was a proposal in our project for a Mobile Internet SERvices (MISER) architecture, which allows dynamic mapping of various communication parameters to names assigned for network objects. The main idea behind the concept of the MISER infrastructure is to provide network services supporting various mobility aspects for applications. In addition the attempt is made to provide an open architecture, allowing easy insertion or deletion of other possible services into it.

MISER is a system built around the Domain Name System (DNS, see Reference 16) using globally unique identifiers for mobile devices and users. Identifiers can be of an arbitrary form but must contain DNS names (Fully Qualified Domain Name- FQDN) as a part of a MISER identifier (see section 4.2 and References 1 & 2). For such purposes email addresses are chosen as MISER identifiers. Global uniqueness is provided by the FQDN part of the email address, whereas uniqueness within the domain, provided by the user, is a specified part of the email address. It is the responsibility of the subscription management module in MISER to verify uniqueness within the domain.

MISER identifiers are “ long-lived” names and are not supposed to change often. Such an approach allows extending DNS with capabilities to resolve MISER identifiers into user/device specific information, which changes over time. Examples of such information are: currently assigned IP address, public certificate, device capabilities (screen size, audio/video/text, communication channel characteristics, etc.), user profile – current user preferences dependent on the context (work, home, etc.). Such information may be change quite often. In the MISER system it can be subsequently resolved through the MISER identifier into current, up to date communication characteristics.

2

Security is one of the most important characteristics of the MISER system. Write permissions are verified based on the MISER identifier and certificates, where public certificates stored in the MISER system and uniquely mapped to the MISER identifier. Private certificates are stored in a user’s device and available only for the user.

Read operations are controlled through user preferences and certificate identity verification.

Because MISER is a distributed system, administratively divided by DNS domains, it requires some trust model between administration domains. However, this is out of the scope of the current system design and will be addressed in the future work.

One of the key features of the MISER system is the capability of easy automatic insertion or deletion of services in the system. Therefore MISER can be used by different Internet application services. It means that for example a user of a chat system can find her friend even if the friend is somewhere else in the Internet and using another service provider’s Internet application service – we assume of course that both companies use MISER as their supporting system for mobile internet services.

1.3 Purpose and Delimitation My Master’s thesis project was to design and implement a management system for user subscription in the MISER. The Subscription Management System (SMS) has to fulfil the creation and management of an account and an identifier for any MISER users with the possibility for users to enable or disable network service(s) in her/his account. On the other hand SMS supports the updating of network services offered by any Internet application system that uses MISER. Consider the above example. How does a user disable the chat service for a while? In which way does the system support the user’s subscription? How does the service provider add a new service, like a new game with many players?

In my work I tried to design and implement a system to answer these questions. SMS creates an account for each user with a unique identifier. Later the user can update her/his account or delete it. By writing information in the service’s database, SMS creates the possibility for users to add or delete Internet application service(s) and enable or disable them for a while.

There were some limitations for the work. Because of a special user identifier (see section 4.2.4) that would be used by other network services in MISER (see section 4.2), I had to install and work with an LDAP database (see Appendix A.1) to create and manage such user identifiers. It was decided to use MySQL (see section 5.3.3) for different services databases.

1.4 Outline of this Document After this introduction, the second chapter is a background theory of my work and describes different layer models to organize the communication task, Internet Protocols, its services and the latest version of the Internet Protocol, IPv6.

In chapter three some related work such as Mobile IP, Lina and Service Location Protocol are explained and their advantages/disadvantages related to my work are discussed.

The fourth chapter is about the MISER architecture. The whole system description is required in order to understand the requirements for SMS. In this section the

3

implications of mobility on service architecture, the architecture of MISER and a set of new services required to support mobility are described.

Chapter five is about my Master’s thesis project and how I specified the different software requirements for SMS based on the MISER requirements for management of subscription, SMS Architecture and the implementation and details of each component in SMS. In this section I describe how SMS is broken down in components and how the physical model is defined.

Appendix A describes some technical words that are used in this document. Appendix B has a set of Message Sequence Charts (MSC) that shows the relation between different components in SMS and their integration.

MISER can be used by any system that has some network services and can provide a user interface. Appendix C describes one example of a user interface that can be used by such a system.

4

2 Background To understand this report, some familiarity with data communication and network in general and the Internet protocols in particular is beneficial. Most of the necessary concepts from network systems will be introduced in this chapter.

2.1 Three-Layer Model It is often impractical for two communicating devices to be directly, point-to-point connected. This is so for one (or both) of the following contingencies:

• The devices are very far apart. It would be inordinately expensive, for example, to string a dedicated link between two devices thousands of kilometres apart.

• There is a set of devices, each of which may require a link to many of the others at various times. Except for the case of a very few devices, it is impractical to provide a dedicated wire between each pair of devices.

The solution to this problem is to attach each device to a communication network.

In very general terms, communications can be said to involve three agents: applications, computer, and network. One example of an application is a file transfer operation. These applications execute on computers that can often support multiple simultaneous applications. Computers are connected to networks, and the data to be exchanged are transferred by the network from one computer to another.

With these concepts in mind, it appears natural to organize the communication task into three relatively independent layers:

• Network access layer

• Transport layer

• Application layer

The network access layer is concerned with the exchange of data between a computer and the network to which it is attached. The sending computer must provide the network with the address of the destination computer, so that the network may route the data to the appropriate destination. The specific software used at this layer depends on the type of network to be used. Thus, it makes sense to separate those function having to do with network access into a separate layer. By doing this, the remainder of the communications software, above the network access layer, need not be concerned about the specifics of the network to be used.

Regardless of the nature of the applications that are exchanging data, there is usually a requirement that data be exchanged reliably. That is, we would like to be assured that all of the data arrive at the destination application and that the data arrive in the same order in which they were sent. As we shall see, the mechanisms for providing reliability are essentially independent of the nature of the applications. Thus, it makes sense to collect those mechanisms in a common layer shared by all applications; this is referred to as the transpor t layer .

Finally, the application layer contains the logic needed to support the various user applications. For each different type of application, such as file transfer, a separate module is needed that is peculiar to that application.

5

Traditional “hardwired” Internet infrastructure supports distributed applications for client ⇔ server (e.g. FTP, WWW, Email, etc.), client ⇔ client (e.g. various text/voice chat tools), and client ⇔ server ⇔ client (e.g. conferencing tools) communication. All these applications are completely independent of the underlying network infrastructure, i.e. network access. What follows is a definition of basic network services, network services, and application services used in this document.

Application service is a service offered by an application and cannot be reused by other applications.

Network Service is a service making use of underlying network services and/or basic services, and providing communication functionality in the form of an Application Programming Interface (API), which can be used either by applications or other upper layer network services. This group of services represents so-called middleware, carrying mostly support functionality for applications rather than delivering information to an end user.

Basic network service is a service that provides network access and data transmission between communicating peers independent of communication medium. The basic service can be used either by applications and/or other network services implemented in the upper layers. Typical implementations of the basic network service are drivers for different communication networks.

It follows from the above definition that the service architecture may include multiple layers as long as other services and/or applications can reuse the services delivered by lower layers.

Seen from this perspective, the traditional “hardwired” Internet is depicted in Figure 1. Besides basic access service provided by core (backbone) network operators there is one more dominating service. Domain Name Service (DNS) is used by most of the Internet applications. The main feature of the DNS is that this service is provided independent of network access operators.

Figure 1 – Service Layered Structure of “Traditional” Internet.

Such service architecture follows out of the set of specific features within the “hardwired”-networking domain. Among these features are:

• Relatively high network capacity.

• All computers have permanent network identification – IP address.

• All computers have a permanent attachment to a network, i.e. cannot move neither within the same network nor between different IP networks.

• Communication media and protocols provide reliable data delivery.

BASIC ACCESS SERVICE

Domain Name Service

Applications

6

All above-mentioned features of traditional Internet can be summarized in one: absence of mobility of users, terminals, services and content. This concept will be discussed later.

2.2 Internet Protocols Two protocol architectures have served as the basis for the development of interoperable communications standards: the TCP/IP (see references 9, 19) protocol suite and the OSI reference model. The open system interconnection (OSI, see references 9, 19) model was developed as a model for a computer communications architecture, and as a framework for developing protocol standards. OSI1 has become the standard model for classifying communications functions.

An interconnected set of networks, from a user’s point of view, may appear simply as a larger network. However, if each of the constituent networks retains its identity and special mechanisms are needed for communicating across multiple networks, then the entire configuration is often referred to as an internet.

Each constituent network in an internet supports communication among the devices attached to that network; these devices are referred to as end systems (ESs). In addition, networks are connected by devices referred to in the ISO documents as intermediate systems (ISs). ISs provide a communications path and perform the necessary relaying and routing functions so that data can be exchanged between devices attached to different networks in the internet.

Two types of ISs of particular interest are bridges and routers. The differences between them have to do with the types of protocols used for the internetworking logic. In essence, a br idge operates at the Presentation layer of the open systems interconnection (OSI) seven-layer architecture and acts as a relay of frames between similar networks. A router operates at the Session layer of the OSI architecture and routes packets between potentially different networks. Both the bridge and the router assume that the same upper-layer protocols are in use.

TCP/IP is the most widely used interoperable architecture and consists of a large collection of protocols that have been issued as Internet standards. Based on the protocol standards that have been developed, we can organize the communication task for TCP/IP into five relatively independent layers:

1. Physical layer

2. Network Access Layer

3. Internet Layer

4. Host-to-host, or transpor t layer

5. Application layer

The physical layer covers the physical interface between a data transmission device (e.g., workstation, computer) and a transmission medium or network. This layer is concerned with specifying the characteristics of the transmission medium, the nature of the signals, the data rate, and related matters.

1 OSI consists of seven layers: 1. Application 2. Presentation that provides independence to the application processes from differences in data representation (syntax); 3. Session that provides the control structure for communication between application; establishes, manages, and terminates connections (sessions) between cooperating applications; 4. Transpor t 5. Network 6. Data L ink that provides for the reliable transfer of information across the physical link; sends blocks (frames) with the necessary synchronization, error control, and flow control; and 7. Physical.

7

The network access layer is concerned with access to and routing data across a network for two end systems attached to the same network. In those cases where two devices are attached to different networks, procedures are needed to allow data to traverse multiple interconnected networks. This is the function of the internet layer . The Internet Protocol (IP) is used at this layer to provide the routing function across multiple networks. This protocol is implemented not only in the end systems but also in routers. A router is a processor that connects two networks and whose primary function is to relay data from one network to other on its route from the source to the destination end system.

Figure 2 – Protocol Architecture Model.

Figure 2 shows how the TCP/IP protocols are implemented in end systems. Note that the physical and network access layers provide interaction between the end systems and the network, whereas the transport and application layers are what is known as end-to-end protocols; they support interaction between two end systems. The internet layer has the flavor of both. At this layer, the end system communicates routing information to the network but also must provide some common functions between the two end systems.

Application

TCP

IP

Network Access

Physical

Application

TCP

IP

Network Access

Physical

Network

8

2.3 IP Services The services to be provided across adjacent protocol layers (e.g., between IP and TCP) are expressed in terms of primitives and parameters. A primitive specifies the function to be performed, and the parameters are used to pass data and control information. The actual form of a primitive is implementation dependent. An example is a subroutine call.

IP provides two service primitives at the interface to the next higher layer (Figure 3). The Send primitive is used to request transmission of a data unit. The deliver primitive is used by IP to notify a user of the arrival of a data unit.

Send { Deliver { Source address Source address Destination address Destination address Protocol Protocol Type of service indicators Type of service indicators Identification Don’ t-fragment identifier Time to live Data length Data length Option data Option data Data Data } }

Figure 3 – IP Service Primitives and Parameters.

The parameters associated with the two primitives are as follows:

• Source address: Internet address of sending IP entity.

• Destination address: Internet address of destination IP entity.

• Protocol: Recipient protocol entity (an IP user, such as TCP).

• Type of service indicators: Used in combination with the source and destination addresses and user protocol to identify the unit uniquely. This parameter is needed for reassembly and error reporting.

• Do not fragment identifier : Indicates whether IP can fragment data to accomplish delivery.

• Time to live: measured in seconds.

• Data length: Length of data being transmitted.

• Option data: Options requested by the IP user.

• Data: User data to be transmitted.

9

2.4 IPV6 The internet protocol (IP) has been the foundation of the Internet and virtually all multi vendor private internet works. This protocol is reaching the end of its useful life and a new protocol, known as IPv6 (IP version 6), has been defined to ultimately replace IP.

The driving motivation for the adaptation of a new version of IP was the limitation imposed by the 32-bit address field in IPv4. With a 32-bit address field, it is possible in principle to assign 322 different addresses, which are over 9104× possible addresses. One might think that this number of addresses was more than adequate to meet addressing needs on the Internet. However, in the late 1980s it was perceived that there would be a problem, and this problem began to manifest itself in the early 1990s. Some of the reasons for the inadequacy of 32-bit addresses include the following:

• The two-level structure of the IP address (network number, host number) is convenient but wasteful of the address space. Once a network number is assigned to a network, all of the host-number addresses for that network number are assigned to that network. The address space for that network may be sparsely used, but as far as the effective IP address space is concerned, if a network number is used then all addresses within the network are used.

• The IP addressing model generally requires that a unique network number be assigned to each IP network whether or not it is actually connected to the Internet.

• Networks are proliferating rapidly. Most organizations boast multiple LANs, not just a single LAN system. Wireless networks have rapidly assumed a major role. The Internet itself has grown explosively for years.

• Growth of TCP/IP usage into new areas will result in a rapid growth in the demand for unique IP addresses (e.g., using TCP/IP to interconnect electronic point-of-sale terminals and for cable television receivers).

• Typically, a single IP address is assigned to each host. A more flexible arrangement is to allow multiple IP addresses per host. This of course increases the demand for IP addresses.

So the need for an increased address space dictated that a new version of IP was needed. In addition, IP is a very old protocol, and new requirements in the areas of address configuration, routing flexibility, and traffic support had been defined.

IPv6 includes the following enhancements over IPv4:

• Expanded address space: IPv6 uses 128-bit addresses instead of the 32-

bit addresses of IPv4. This is an increase of address space by a factor of 962 addresses. It has been pointed out that this allows on the order of 6× 2310 unique addresses per square meter of the surface of the earth. Even if addresses are very inefficiently allocated, this address space seems secure.

• Improved option mechanism: IPv6 options are placed in separate optional headers that are located between the IPv6 header and the transport-layer header. Most of these optional headers are not examined or processed by any router on the packet’s path. This simplifies and speeds up router

10

processing of IPv6 packets compared to IPv4 datagram. It also makes it easier to add additional options.

• Address auto configuration: this capability provides for dynamic assignment of IPv6 addresses.

• Increased addressing flexibility: IPv6 includes the concept of “an any cast address” , for which a packet is delivered to just one of a set of nodes. The scalability of multicast routing is improved by adding a scope field to multicast addresses.

• Suppor t for resource allocation: instead of the type-of-service field in IPv4, IPv6 enables the labeling of packets belonging to a particular traffic flow for which the sender requests special handling. This aids in the support of specialized traffic such as real-time video.

For more information about IPv6 see references 3 and 7.

11

3 Related Work The movement of wireless network devices may possibly introduce a momentary pause in the operation, but it should not require reinitiating of network connections. The existing set of network protocols does not meet this requirement since they were designed with the assumption of a stationary network topology where hosts do not change their location over time.

3.1 Problems with Mobile Network Mobile end systems frequently change their point of attachment to the network. In such an environment, in order for mobile devices to run without disruption, an internetworking infrastructure is needed.

In addition, mobile devices also need to communicate with the existing pool of information servers and file servers, which mean that internetworking solutions for connecting stationary and mobile systems are also required. Unfortunately, the Internet Protocol (IP), which forms the fabric of the current world-wide data communication network, falls short of meeting this demand. The current Internet suites of protocols (TCP/IP) were designed under the assumption that end systems are stationary.

If during an active network session one end of the connection moves, the network session breaks. Naturally, all networking services layered on top of TCP/IP are also disrupted when end systems become mobile.

In mobile networking, computing activities are not disrupted when the user changes the computer’s point of attachment to the Internet. Instead, all the needed reconnection occurs automatically and not interactively.

Mobility on the IP layer is slightly different from the notion of mobility in wireless networking environments. The difference is that IP mobility is not always dependent on the geographical i.e. physical mobility of a terminal or person using this terminal at the moment. The main reason causing “movement” of a terminal is the change of IP address. This happens not necessarily due to the geographical (physical) movement of the terminal2, but for example due to the change of the access network while staying at the same geographical location.

3.2 Early Solutions Over the last ten years several proposals have been made to address this problem (See References 12, 22). The scheme proposed by Ioannidis (See References 12, 13) relies on a group of cooperating Mobile Support Routers, which advertise reachability to the same (sub) net. Each mobile host, regardless of its location within a campus, is always reachable via one of the Mobile Support Routers (MSR). When a host sends a packet to a mobile host, it first gets delivered to the MSR closest to the source host. This MSR encapsulates the packet and delivers it to the target MSR which strips the encapsulation header and relays the original packet to the mobile

2 We consider a terminal as one of the mobile entities attached to the communication network. Generally, mobile entities comprise people, terminals, services, and content. Each of these mobile entities couples to the terminal address currently used by a user, service or content. We will use the terms “ terminal” and “mobile entity” interchangeably unless it is required to specifically distinguish between them.

12

host. This approach is optimized to work within a campus environment and cannot be easily extended to support wide area mobility.

In Sony’s proposal (See Reference 22), a mobile host is assigned a new temporary address when it is attached to a new network. The mapping between the home address and the temporary address of a mobile host is kept in an Address Mapping Table (AMT), which is maintained at the routers. Packets transmitted to the home address of the mobile host get intercepted by some router which holds an AMT entry for the mobile host. An address conversion is performed by the router before the packets are forwarded to the physical location of the mobile host. This method requires modifications to routers and host software and has problems inter-operating with the existing hosts unless so-called “conversion gateways” are used.

There are two approaches for solving the problem of mobile internetworking. One is to completely redesign internetworking protocols with the specific goal of supporting mobile end systems. The other approach is to provide additional services at the network layer which makes mobile internetworking possible. The first approach, though an interesting possibility from a research viewpoint, is unfeasible since it would require radical changes to the currently deployed networking infrastructure. It is the latter approach that was the focus of my project.

The newest approach is based on the use of an existing IP option and therefore, does not require any changes to the existing hosts and routers. The key idea is that each packet originating from a mobile host contains enough routing information that can be used by the remote host to send a reply back to the source along an optimal path. In the rest of this section, I first present an overview of this scheme and then describe other related work based on Mobile IP implementations.

3.3 Mobile IP To solve above mentioned problems, Mobile IP (See Reference 17), a standard proposed by a working group within the Internet Engineering Task Force (IETF), was designed by allowing the mobile node to use two IP addresses: a fixed home address and a care-of address that changes at each new point of attachment.

In Mobile IP, the home address is static and is used, for instance, to identify TCP connections. The care of address changes at each new point of attachment and can be thought of as the mobile node’s topologically significant address; it indicates the network number and thus identifies the mobile node’s point of attachment with respect to the network topology. The home address makes it appear that the mobile node is continually able to receive data on its home network3, where Mobile IP requires the existence of a network node known as the home agent4. Whenever the mobile node is not attached to its home network (and is therefore attached to what is termed a foreign network5), the home agent gets all the packets destined for the mobile node and arranges to deliver them to the mobile node's current point of attachment.

3 Home Network: The network at which the mobile node seems reachable, to the rest of the Internet, by virtue of its assigned IP address. 4 Home agent: A node on the home network that effectively causes the mobile node to be reachable at its home address even when the mobile node is not attached to its home network. 5 Foreign network: The network to which the mobile node is attached when it is not attached to its home network, and on which the care-of address is reachable from the rest of the Internet.

13

Whenever the mobile node moves, it registers its new care-of address with its home agent. To get a packet to a mobile node from its home network, the home agent delivers the packet from the home network to the care-of address. The further delivery requires that the packet be modified so that the care-of address appears as the destination IP address.

In Mobile IP the home agent redirects packets from the home network to the care-of address by constructing a new IP header that contains the mobile node’s care-of address as the destination IP address. This new header then shields or encapsulates the original packet, causing the mobile node's home address to have no effect on the encapsulated packet’s routing until it arrives at the care-of address.

Mobile IP, then, is best understood as the cooperation of three separable mechanisms:

• Discovering the care-of address.

• Registering the care-of address.

• Tunneling to the care-of address.

The most pressing outstanding problem facing Mobile IP is that of security, but other technical as well as practical obstacles to deployment exist. Work is also continuing to refine and extend the protocol within the academic and commercial communities

3.4 Mobile IPv6 Charles E. Perkins and David B. Johnson have designed protocol enhancements for IPv6, known as Mobile IPv6 (See Reference 18).

In Mobile IPv6, each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While away from its home IP subnet, a mobile node is also associated with a care-of address, which indicates the mobile node’s current location. Mobile IPv6 enables any IPv6 node to learn and cache the care-of address associated with a mobile node's home address, and then to send packets destined for the mobile node directly to it at this care-of address using an IPv6 Routing header.

The association between a mobile node’s home address and its care-of address, along with the remaining lifetime of that association, is known as a binding. The central data structure used in Mobile IPv6 is a cache of mobile node bindings, maintained by each IPv6 node, known as a Binding Cache.

In addition, Mobile IPv6 provides a mechanism for IPv6 correspondent nodes communicating with a mobile node, to dynamically learn the mobile node’s binding.

Since IPv6 is still being designed and there is no existing installed base of IPv6 nodes, we believe it is reasonable to require all IPv6 nodes to be capable of caching the binding of mobile nodes with which they are communicating.

3.5 Lina LINA (Location Independent Network Architecture) is a new network architecture which employs separation of identifier and locator to support node mobility (See Reference 15). There is also a new protocol called LIN6. LIN6 as an application of LINA to IPv6 provides mobility to IPv6 without impact on the current IPv6 infrastructure (that already exists) and maintains compatibility with traditional IPv6.

14

LINA introduces two new concepts that are node identifier and interface locator. The node identifier recognizes the identity of the node. The node identifier does not depend on its attachment point to the network interface. The interface locator denotes the current point of attachment to the network. It is assigned to the network interface of a node and is used to route packets to the network interface. The node identifier is immutable whereas the interface locator changes when the node moves.

LINA uses a Mapping Agent (MA) to map the node identifier to the interface locator. The relation between the node identifier and the interface locator is called a mapping. A node registers its mapping periodically with its mapping agents. It also registers a new mapping when the node changes its location on the network.

On sending, the LIN6 generalized identifier is transferred to the LIN6 address by using the following procedure: The identification sub layer performs extraction from the LIN6 generalized identifier to obtain the LIN6 ID and sends a query to MAs to obtain the mapping using the LIN6 ID as the key. Since it can derive the current locator (interface address) when it obtains the mapping, it performs the embedded procedure and derives the LIN6 address. The LIN6 address is used for packet delivery in the delivery sub layer.

On receiving, the delivery sub layer receives the packet and passes the packet to the identification sub layer. The identification sub layer performs the extraction procedure. The LIN6 ID performs the embedment procedure with a 64 bit fixed network prefix (LIN6 prefix) to obtain the LIN6 generalized identifier of the source node. Thus, the LIN6 address is transferred to the LIN6 generalized identifier.

3.6 Service Location Protocol The Service Location Protocol (SLP) (See Reference 21, 10) has been designed to meet the need for automatic resolution of service needs in the enterprise and in the mobile environment. In the enterprise environment, this process for automatic resolution is driven by the wealth of heterogeneous resources as well as by the expense of administration. In the mobile environment, the number of resources available to the mobile user may be less, but the need for reducing administration is much more important.

The Service Location Protocol defines User Agents, Service Agents, and Directory Agents, as well as the basic protocol messages used by them. A User Agent (UA) operates on behalf of an application (which is itself running on behalf of some user, presumably) to acquire the information needed by that application for connection to a network service. Each network service is itself represented by a Service Agent (SA). A UA discovers an SA for a service of a given service type by transmitting a Service Request. In response, the UA expects to get a Service Reply.

When there are multiple networks, a UA will often wish to make a connection to a service on another network. To avoid excessive multicast, and to provide a common handler for Service Requests from UA, SLP defines a Directory Agent (DA) that responds to such requests.

15

Figure 4 – Overview of the base Service Location Protocol.

Schematically, the operations just described are shown in figure 4. In the figure, an application and a service on a subnet can communicate without the need for any DA services from the rest of the Intranet, if they are so configured.

The figure also shows that user agents can contact the DA for access to services anywhere else within the Intranet. The SAs (Service Agents) on other networks register their services with the DA, and the UAs (User Agents) pick the services they need by using queries in a simple Boolean query language. For additional scalability, SLP has been defined to work with many Directory Agents, and protocol operations are available so that SAs can select one or more particular DAs to register their services.

For interactive use, there are protocol messages to enable a user to browse all the service types and service agents of each service type that happen to be available to the user. These browsing messages provide the same information whether or not they are multicast to nearby networks, or on the other hand if they are directed at a suitable DA.

From the point of view of the mobile and user, SLP gives a way to achieve effortless and even transparent utilization for the network services needed by applications. This drive towards zero administration characterizes quite a lot of recent protocol design within the Internet.

Subnet

Application Service Service

User Agent (UA)

Service Agent (SA)

Service Agent

Intranet User Agent

(UA)

Service Agent Service Agent

Directory Agent (DA)

16

3.7 Advantages and Disadvantages As we can see Mobile IP (and MobileIPv6) and Lina solve the problem of end systems mobility when mobile devices are changing their point of attachment to the network.

Mobile IP use two IP addresses: a fixed home address (home address) and a care-of address that changes at each new point of attachment. The care of address changes at each new point of attachment and can be thought of as the mobile node's topologically significant address. Whenever the mobile node moves, it registers its new care-of address with its home agent.

Lina separates identifier and locator to support node mobility. The node identifier recognizes the identity of the node and the interface locator denotes the current point of attachment to the network. LINA uses a Mapping Agent to map the node identifier to the interface locator. The relation between the node identifier and the interface locator is called a mapping.

Both use two types of addressing for an end system. The first type (home address, node identifier) is used to identify the end system and the second (care of address, interface locator) is used to detect the point of attachment. This functionality can be used when end system changes place and moves over the time.

However, for reachability purposes these approaches use FQDN and static mapping in DNS to home address. On the other hand, applications may try to reach a user (human) but not a device, e.g. conferencing applications. A user may use various devices at a time or various devices at different occasions. The DNS system is not capable of finding a user associated with some particular device. Moreover, due to different access characteristics and device capabilities there is a need to provide communication accordingly. Such information should be available depending on the current context of a user and used device. This fact emphasises the need for the extension of the DNS system with those capabilities.

Internet application services are growing in number every day. Due to this fact it becomes extremely difficult to provide similar services for each particular access. Therefore we need services to support application services, which can be reused by different applications thus adding “mobility support services” to them. Mobility support requires many more services to cope with the issues of reachability, session handover, presence in the network, addressing of network entities (people, devices, services and content), etc.

The Service Location Protocol (SLP) was designed to meet the need for automatic resolution of service needs in the enterprise and in the mobile environment. In the mobile environment, the need for reducing administration is very important. Therefore SLP’s idea can be used in a mobile environment but as I described in the above paragraph we need many more services for the mobility support.

17

4 Proposed Solution The aim of the Master’s thesis project was to design and build a Subscription Management System (SMS) in the Mobile Internet SERvice (MISER) presented in chapter 5. But what is MISER? What is the reason for providing the MISER?

Almost all network services are offered to the end users and operated by “giant” network access operators. It makes it extremely difficult for production companies to reach the “end user” market directly, thus limiting the number of potential customers. On the other hand, there are numerous network services existing and being developed, which can be and/or have to be separated from the basic network service provided today traditionally by network access operators (for more information about “network services” and “basic network services” see section 2.1). Another fact is that there are multiple ways to access the network and services, which means that it becomes extremely difficult to provide similar services for each particular access.

Besides that, consider network services for mobility support, which can be reused by different applications and application services. An example of such service in traditional data communication networks is Domain Name Service. DNS that resides in the network does not depend on the access technology and can be used by any type of networking application.

Due to the fact that mobility support requires many more services to cope with the issues of reachability, session handover, presence in the network, addressing of network entities (people, devices, services and content), etc. there is an obvious need to extend existing data communication services with those supporting different mobility issues.

By considering problems mentioned before (see sections 1.1, 1.2 and 3.7) the Mobile Internet SERvices (MISER) system is introduced. The main goal of the MISER infrastructure is to provide network services supporting mobility for applications.

In this chapter, we will first describe the mobility implications for service architecture and then we will have a short overview of the MISER architecture and different services.

4.1 Mobility Implications for Service Architecture Mobility management has to cope with two major problems to provide consistent and continuous communication between terminals:

• Session establishment, and

• Session continuity

The session establishment phase requires the means to find out the point of contact. Existing addresses today are IP addresses and telephone numbers6. Session continuity provides the means to keep track of ongoing sessions and to re-establish interrupted sessions if needed.

For the session establishment the traditional Internet uses static mapping between terminal name, terminal IP address and user(s) of the terminal(s). The central point here is the IP address, because telephone numbers are globally unique and permanently mapped to the terminal or subscriber in mobile telephony through the

6 There are many other types of addresses but they do not have anything to do with wireless Internet mobility management, thus are outside of this document’s scope.

18

SIM card. It is not possible to provide static mapping in the wireless Internet because IP addresses can be changed over time. Or, to be precise, a given terminal may change its IP address over time (See section 3.1 and References 9, 19).

However, the evolution of the mobile Internet with the possibility to use multiple access networks and multiple communication devices at a time, introduces new challenges in managing mobility within the Internet. An IP address can no longer be used as an identifier of the point of contact for mobile entities. The reason is that it is no longer static for terminals. This fact has a huge influence on the session establishment phase as compared to the traditional “hardwired” Internet.

The mobility is essentially an address translation problem and is best resolved at the network layer. We need identify the fundamental services that must be supported at the network layer to carry out the task of address translation.

For addressing and address manipulation of the mobile entities the following requirements can be specified:

• There must be a globally unique, static (or rarely changed) identifier for mobile entities in the Internet. The identifier must contain enough information to find out the point of presence7 of a mobile entity.

• There must be a defined point of presence for mobile entities in the Internet.

The solution of these requirements is adopted from “NAI” (RFC 2486, See reference 1). The Network Access Identifier (NAI) is the user ID submitted by the client during authentication and is of the form user@realm. The purpose of the NAI is to identify the user as well as to assist in the routing of the authentication request. Note that the NAI may not necessarily be the same as the user's e-mail address or the user ID submitted in an application layer authentication. The NAI syntax is quite flexible and covers existing identifiers for email addresses and various URI8 (uniform resource identifier) (See Reference 2) schemes9.

In this chapter we refer mainly to email addresses as identifiers, which is not contradictory to other solutions using URI or similar addressing approaches (RFC 2778, RFC 2543, See References 6, 11).

The main feature of such addressing schemes is that there is a globally unique part of the identifiers: domain name. This allows using the power of the DNS (Domain Name System). DNS (See Reference 16) is a translation mechanism that maps host names to addresses. DNS, as a decentralized naming mechanism, was deployed in Internet to accommodate a large, rapidly expanding set of names. DNS stores name to address mappings in a distributed data structure. Finding the address of the host is essentially a directory lookup operation.

7 By point of presence we mean a location in the Internet where the identifier can be resolved into the corresponding IP address and any other available information about the mobile entity can be obtained. 8 Uniform Resource Identifiers (URI) provide a simple and extensible means for identifying a resource. A URI can be further classified as a locator, a name, or both. The term “Uniform Resource Locator” (URL) refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network “ location”), rather than identifying the resource by name or by some other attribute(s) of that resource.

9 The URI scheme defines the namespace of the URI, and thus may further restrict the syntax and semantics of identifiers using that scheme. This specification defines those elements of the URI syntax that are either required of all URI schemes or are common to many URI schemes.

19

Using of the DNS for mapping information to email addresses as an identifier can make an unambiguous resolution. Because DNS by itself can provide only static mapping and does not have dynamic update capabilities (when user’s IP changes), the information it refers to is the actual resolution server address and port numbers, used to access a particular resolution server.

Besides this, it is important to mention that these solutions are applicable to various mobility management schemes such as Mobile IP (See Section 3.3 and References 4, 5, 17) to provide session establishment between mobile hosts.

According to the specified requirements and solutions, the point of presence of mobile entities is defined as an Internet Domain accessible through the global DNS system.

The above motivation shows the need for the new network service PRESENCE SERVICE, allowing retrieval of the necessary information for initiation of sessions between mobile entities.

The next section describes a proposed architecture of the generic presence service regardless of the protocols used for data delivery. The description focuses mostly on the functional aspects of the presence service architecture.

4.2 Mobile Internet SERvice (MISER) Architecture The main idea behind the concept of the MISER infrastructure is to provide network services supporting mobility for applications. The set of functional blocks included into the system comprehensively covers the needs of the presence service. However, the attempt is made to provide an open architecture, allowing easy insertion or deletion of other possible services into it. This explains the name given to the system: Mobile Internet SERvices (MISER). Below are the requirements set for the MISER system.

The architecture has a modular structure allowing easy adding or removing of services to/from the system.

All services are subscription based. This means that a user can manipulate services by adding, removing, temporarily enabling/disabling them, etc. Moreover, users have the possibility to change service settings and their profiles if applicable to the particular service.

There are five basic services: 1. location, 2. notification, 3. user profile, 4. security, and 5. session profiling services.

Service manipulation is performed through the subscription management system allowing creation of the system account, addition/deletion of services, and enabling/disabling of services.

As can be seen from the above requirements the entire presence service is divided into five sub services. The reason is that some of these services can be used as generic network functions.

The set of services included in the MISER architecture is not limited to the services presented in this chapter. MISER should be considered as an open system, which allows easy addition and removal of other services into the infrastructure provided by this specification. Below follows a description of each service included in the currently proposed MISER architecture.

20

MISER

Figure 5 – MISER Functional Structures.

4.2.1 Architecture Overview The functional structure of the MISER architecture is depicted in figure 5.

As can be seen from Figure 5, the architecture includes a number of functional blocks, all together comprising the presence service. However, some services or their combinations can be used regardless of presence. The following sections present each service and examples of their usage.

4.2.2 Location/Name Resolution Service The name resolution service is offered as an extension to the standard Internet DNS service. The service allows resolution of MISER identifiers, i.e. email addresses, into the corresponding IP addresses. The name resolution service provides the following capabilities10:

• Update of the mobile entity’s IP address.

• Setting of the mobile entity’s IP address into the “unreachable” state.

• MISER identifier – IP address resolution and delivery.

Client applications access this functionality through the Presence API described in detail in Reference 14.

10 Note that the capabilities of any service currently included into the MISER infrastructure are the subject of extension.

Isp. domain.name

HTML, X/HTML, XML, WML Client

Inter face

Presence API

Internet

Subscription Management

System (SMS)

User Profiling Service

Session Profile Service

Security Service Notification Service

Location Service

21

4.2.3 Security Service Security is an absolutely necessary attribute of any presence system and included in the MISER providing secure and authenticated access to the offered services. The service has to fulfil the following requirements:

• Generation of private and public keys/certificates for the mobile entities subscribing to the service.

• Automatic distribution of the private and public keys/certificates to the owners.

• Storage and retrieval of public keys/certificates upon request.

• Upload and storage of public keys/certificates generated by other authorized parties.

In the current version of the MISER system a mobile entity shall create an account in the system and, if it so wishes, subscribe to an arbitrary set of MISER services. This can be done later when creating a MISER account. Security service requires subscription as well. As a result of subscription to the security service, a mobile entity receives a pair of private and public keys, generated by the MISER system. The public key is stored in the MISER security service database and can be delivered to other mobile entities upon request.

4.2.4 User Profile Service The user profile service is deliberately separated from the session profile service. The main objective for the user profile service is to be able to set authorization policy for presence information access. Any mobile entity can define a named set of profiles. A naming convention for profiles does not have to be established and may be arbitrarily defined by the mobile entity. The difference from the corresponding list supported by the notification service is that the profile list allows usage of wildcards and regular expressions in MISER identifiers contained in the profile list. That means that a mobile entity can specify groups of authorised users depending on the profile chosen at the moment. A typical example of that can be:

PRESENTITY: ali@home.se

PROFILE NAME: ali@work

PROFILE LIST: *@work.se, mistress@*

Kid1@*, kid2@*

Another example could look like this:

PRESENTITY: ali@home.se

PROFILE NAME: ali@home

PROFILE LIST: friends@*, wife@*

4.2.5 Notification Service The notification Service provides a complement to the Name Resolution Service and enhances the presence service capabilities. The current specification of the notification service identifies three types of events. The name resolution server performs event generation. Among those events are:

22

• ONOFF. This event is generated when PRESENTITY changes an IP address in the name resolution database to LOGGED OFF state.

• OFFON. This event is generated when update of a previously stored IP address in the name resolution server takes place. The necessary condition is that the IP address in the database is in the LOGGED OFF state.

• ONON. This event is generated similarly to the OFFON event but the necessary condition is that the newly updated IP address is different from the one previously stored in the database.

After the notification server receives the event, it performs its database lookup for the list of WATCHERS11 that have to be notified. The list of WATCHERS is the list of their correspondent MISER identifiers in this or any other MISER system. The notification server performs WATCHERS IP address resolution using the Presence API and delivers notifications to the WATCHERS whose presence status is LOGGEDIN. Otherwise notification is omitted.

4.2.6 Session Profile Service The session profile service is needed by applications to obtain necessary information about session establishment. The service delivers the information about network capabilities, device capabilities and application capabilities. This is necessary especially for establishing multimedia communication. Having this information, an application – session initiator can make a decision about the way the session is going to be established in the optimal way. Access to the service from applications is performed through the presence API. Functional content is very much similar to the name resolution set of functions. However, semantically it is completely different because the name resolution provides means to find out the point of contact, whereas session profile service provides means to make a decision in which way the communicating peer may and should be contacted.

11 The ones who want to receive notification about changes of the PRESENTITY’s data. Any data can be changed: IP address, session capabilities, user profile, etc.

23

5 SMS The aim of my Master’s thesis project was to design and build a Subscription Management System (SMS) in the Mobile Internet SERvice (MISER). Creating, deleting, and updating an account are some of the functions in any SMS. But to design and build an SMS in MISER, more requirements have to be defined and described. Based on the MISER structure that is described in chapter 4, the MISER designer and I defined these requirements.

5.1 Specification of SMS Software Requirements • Any Subscription Management System must support the following operations:

- Create account

- Delete account

- Update account

- Get account information

These functions require submission of some personal data, user name, and password (see appendix B). Creation of account has to result in obtaining an identifier (for example, ali@findplayer.com) for the mobility support, which will be used by some services in the MISER. For the mobility support the most important service that uses this identifier is Location/Name Resolution Service. This service updates (in Location/Name Resolution Service’s database) the user’s IP address each time it changes and in this way allows resolution of identifiers into the corresponding IP addresses.

The obtained identifier has to be in the above format, because it is not only used to manage the account, but it will also be used by other services in MISER (see sections 4.2.2–4.2.6) that use this identifier to perform their operation.

• The mobility support requires many more services to cope with the issues of reachability, session handover, presence in the network, addressing of network entities (people, devices, services and content), etc. Besides this the MISER should be considered as an open system, which allows easy addition and removal of other services into the infrastructure. Therefore the SMS has to work in a modular way. It means that the SMS has to be able to support the adding/deleting of services in MISER.

To provide this kind of functionality, it is necessary to find a unified way of adding to/deleting from services in MISER

• Flexible Subscription. The SMS has to provide the possibility for users of MISER to add, delete, enable and disable services in her/his account. It is necessary for SMS to provide possibility for users to see all accessible services in MISER. Flexible Subscription means that the user has the possibility to add, delete, enable and disable services in her/his account anytime and change subscription of services again if needed. For more information see appendix B.

• To manage users’ subscription requirements, a web interface can be provided. This web interface will be just an example of what can be done in order to manage user’s subscription requirements. Any Internet application that will use MISER can provide its own web interface.

• The main idea behind the MISER was to provide network services support for different Internet applications with different terminals. To support the information

24

exchange between different Internet applications and SMS, a special protocol has to be designed in SMS. This protocol has to create the possibility for different Internet applications and different terminals to exchange information with the MISER in a way without sending and receiving defined types as Strings, Integers etc.

Because of this protocol, both in SMS and in the web interface, there has to exist a type of interpreter that changes the byte stream to understandable information or changes the information to this protocol format before exchanging of information.

5.2 SMS Architecture In order to provide SMS in the MISER infrastructure, I provided a modular structure. First we will have a short overview of the SMS architecture. After that, according to the specified SMS requirements (see section 5.1) each module in the SMS will be described.

5.2.1 Design Method The design of the SMS architecture is based on the SMS Software Requirements (see section 5.1). Choice of Operating System and Databases will be described later. To design different components in SMS, purposes and functions have been specified on a relatively abstract level. This type of Top-Down-Approach is continued in the implementation of each component.

Figure 6 – SMS Components Structure.

SMP

SMS

Web server

Internet

LDAP Module

Spec. File Parser

Module

Data Base

1

Data Base

2

Data Base

3

Data Base

n

Protocol Module

Data Base

Main Module

Services Interface Module

Spec.

File

Web Interface Module

25

5.2.2 Decomposition Description The structure of SMS is depicted in figure 6. As can be seen there is no direct hierarchical relation between components. Any module works independently in the system but all are connected to Main Module. The Main Module chooses the appropriate module according to incoming requests through SMP12 messages. Protocol Module reads analyses and creates SMP response messages. Manipulation of LDAP13 database is done by LDAP module (see section 5.3.2). Specification File Parser Module reads the information from a service specification file (see Appendix A.2) about service databases structure and default values, which is used by account creation operation. Each service in MISER has a database that contains information about the service and users that use this service. Each service can access its database. The Services Interface Module manipulates service databases (see figure 6) too.

5.2.3 Usage Scenario The most important aim of MISER was mobility support of different network services. Therefore each Internet application company can use MISER to support its services. In order to use MISER:

• Install MISER.

• Install new database(s) for company’s network service(s) in MISER.

• Write a specification file for each new service.

There is no more work to do. Just when a service will be deleted/added from/to the system, delete/add the service’s database and delete/write the specification file.

The second type of users are “End Users” the people who want to have an account and want to use the company’s network services. In my project any user can create an account but it depends on the company’s policy to decide if any user can create an account and use services or not.

A user connects to the MISER and sees windows like in Appendix C. After insertion of some personal data like Name, Username, Password etc she/he can choose service(s) for using. If the Username and Password are unique then SMS creates an account with an identifier for the user. Now the user can use the company’s services and get information about her/his account and/or delete, add, enable or disable service(s).

5.2.4 Architecture When SMS is started the Main Module calls the Specification File Parser Module that reads service specification files (see Appendix A.2). Afterwards the Main Module is waiting in a loop for user requests that come from Web Interface Module through SMP (see Appendix A.3) messages. This request is sent to Protocol Module for analysis and the result will be sent back to the Main Module.

12 Subscription Management Protocol is a specially designed protocol in SMS for information exchange between a Web server and SMS (see figure 3) that has to be in SMP format. Details of this protocol are described in Appendix A.3. 13LDAP stands for Lightweight Directory Access Protocol. LDAP is a directory access protocol that runs over TCP/IP. For more information see Appendix A.1.

26

The next step depends on the request type and the Main module chooses the appropriate module. If the request is account operation, it will be sent to LDAP Module and if it is for services, it will be sent to Service Interface Module. The result is sent back to Web Interface Module by the Main Module to be shown to the user.

5.3 Component Description The SMS has a modular structure that is depicted in figure 6. In this section, according to the specified SMS requirements (see section 5.1), each module in the SMS is described.

5.3.1 The Main Module The Main module gets service database information from The Specification File Parser Module (see section 5.3.3) and sends an incoming request to Protocol module for analysis and according to this request the appropriate module is chosen. The results of the operations are sent back to the user.

The Main module needs connection to Internet for getting/sending messages from/to the Web Interface module and works as a server. The Main module calls the modules:

• Specification File Parser

• Protocol

• LDAP

• Service Interface

The Main module calls the Specification File Parser module to get service databases information (see Appendix A.2 Service Specification File) and then waits for requests that come through SMP messages (see Appendix A.3). The Main module chooses the appropriate module according to the incoming request. If account operation is requested, the LDAP module is called and if services operation is requested, the Service Interface module is called. The Main module must get back the result of operation to user of SMS through SMP. For more information see appendix B.1.

5.3.2 The LDAP Module According to the first requirement (see section 5.1), we need to have a database to save and handle account information (personal data) for each user of MISER. Based on the services requirements on user identifiers that are described in chapter 4 (see sections 4.2.2–4.2.6), each user identifier in MISER has to be in a special format such as ali@home.se. Such an account could be created in a relational database, but the best choice is a Directory Database14 such as LDAP (Lightweight Directory Access Protocol). For more information see Appendix A.1.

14Directory Database: A directory is a specialized database optimised for reading, browsing and searching. Directories tend to contain descriptive, attribute-based information and support sophisticated filtering capabilities. Directories generally do not support complicated transaction or rollback schemes found in database management systems designed for handling high-volume complex updates. Directories are tuned to give quick response to high-volume lookup or search operations. They may have the ability to replicate information widely in order to increase availability and reliability, while reducing response time. When directory information is replicated, temporary inconsistencies between the replicas may be okay, as long as they get in sync eventually.

27

The first reason is that LDAP is a directory access protocol that runs over TCP/IP. The next reason for this choice is obviously dependent on an easy structure for the data (just account information) that has to be saved and handled in the database. For such data we don’ t need a relational database. Another reason is that a Directory Database is a specialized database optimised for reading, browsing and searching that nowadays is widely used to handle data with easier structure such as data accounts in email servers.

After design of entries15 (based on account data: Username, Password, Name, address and etc. See appendix A.1) and installation of LDAP was done, I chose Java to implement the LDAP module. Java is one of the programming languages–in additions to C and C++ – that support the LDAP database. The reason for this choice was that I know Java better than the other languages mentioned.

As can be seen in figure 6, LDAP Module manipulates the LDAP database. There is an Initial method in the LDAP module that connects to the LDAP database. The Add method creates an account by input information. The IsThere method is called before any other operation, to look for the existence of the account and then Modify method and Delete methods are called to update or delete an account. The Get method is called to get account information from the database. For more information see appendix B.2–B.7.

5.3.3 The Specification File Parser Module The most important problem in the SMS was to find a solution to support the adding/deleting of services in MISER that is described in sections 5.1. I have to explain first that each service in MISER has to have a database (MISER uses MySQL16 for each service’s database) and data in each database can be handled by its service. To solve this problem, I designed a simple format for a service specification file. In this specification file, each service designer writes the service’s database structure, different tables in the database and default values. Two examples of such files are in Appendix A.2. In each example you can see how first name and place of the database and then the username and password to the database are defined. After that each table in the database with different field and default values are described. With the help of this information the Services Interface Module (see next section) can connect and handle each service’s database.

Every time that SMS is started, Specification File Parser Module reads all service specification files. Information about each service databases structure and default values for each field are saved in a structured variable. This variable will be sent to Main module. The Main Module sends it first to the Protocol Module (see section 5.3.6) and gets back the information in a byte stream format. This stream will be sent to the Web Interface Module to show all available services in MISER to users. Then it will be send by the Main Module to the Service Interface Module too, to handle the service databases. For more information about the relations between different

15The LDAP information model is based on entries. An entry is a collection of attributes that has a globally unique Distinguished Name (DN). The DN is used to refer to the entry unambiguously. Each of the entry's attributes has a type and one or more values. For more information see Appendix A.1. 16MySQL is a relational database management system. A relational database stores data in separate tables. This adds speed and flexibility. The SQL part of MySQL stands for “Structured Query Language” which is the most common standardized language used to access databases. MySQL is a client/server system that consists of a multi threaded SQL server that supports different back ends, several different client programs and libraries, administrative tools, and several programming interfaces.

28

modules in SMS to get and send information about each service’s database see appendix B.1.

5.3.4 The Services Interface Module According to the requirements (see section 5.1), SMS has to create the possibility for a user to add, delete, enable and disable existence services in her/his account. To create ‘Flexible Subscription’ (see section 5.1) in the web interface is not a big problem. The question is how to create this possibility in the SMS and how the other services in MISER can get needed information about the user.

When a request for a service comes from a user, the Service Interface Module reads the information about different service databases that is sent by Main Module. Based on the incoming request, service database(s) will be accessed and the needed action will be done by this module. For example if the user wants to subscribe to a new service in MISER, a new record will be written in the service’s database. The first four fields in the service database table will be written by SMS. The first field, the username (ali), the second field, the user identity in the MISER (ali@home.se), the third, the user password, and finally the enabling or disabling of service for the user will be written. Other fields will be written as default values (see Appendix A.2). For more information about this module see appendix B.8–B.11.

5.3.5 The Web Interface Module According to the requirements (see section 5.1), Web Interface Module allows interaction between user and SMS. This module generates HTML pages to show information about existence services in MISER, get user information and user requests and sends requests to SMS through the SMP (see Appendix A.3). The Web Interface module is a PHP–script17. For more information see appendix C.

5.3.6 The Protocol Module As described in section 5.1, to support exchange information it is necessary to design a protocol to exchange information without sending and receiving defined types as Integer, String or etc. The solution seems to be a protocol with byte format. It means that just a buffer of bytes will be exchanged. The designer of MISER and I designed the Subscription Management Protocol (SMP) that is described in Appendix A.

Protocol module reads the components of the message that comes from Main module, analyses and saves information for later use by other modules. This module sends back an error message if the incoming message is not in SMP format. Finally any result is written to SMP format in this module. For more information see appendix B.2–B.11.

17 PHP is a tool that lets you create dynamic web pages. PHP-enabled web pages are treated just like regular HTML pages and you can create and edit them the same way you create regular HTML pages. PHP (recursive acronym for PHP: Hypertext Pre-processor) is an open-source server-side scripting language (freely downloadable from php.net and zend.com). The latest version of PHP is PHP 4. The intuitive interface allows programmers to embed PHP commands right in the HTML page. Unlike other scripting languages for Web page development, PHP offers excellent connectivity to most of the common databases (including Oracle, Sybase, MySQL, ODBC and many others).

29

6 Evaluation and Conclusion

6.1 Evaluation

Mobile end systems frequently change their point of attachment to the network. In such an environment, in order for mobile devices to run without disruption, an internetworking infrastructure is needed. In addition we need an internetworking infrastructure that supports the reachability of people who connect to the network with difference wireless devices at same place or on movement.

To supports the reachability of people who connect to the network, email addresses are chosen as MISER identifiers. It was the responsibility of the subscription management module in MISER to verify uniqueness within the domain.

The main idea behind the concept of the MISER infrastructure was to provide network services supporting various mobility aspects for applications. These services are five basic services: 1. location, 2. notification, 3. user profile, 4. security, and 5. session profiling services.

The task of the master’s thesis project was to design and build an SMS in MISER. Below requirements of SMS (Based on the MISER structure) and my implementation to provide needed functionality is described.

1. Create, delete and update account and get account information.

To provide this kind of functionality, I designed and build a LDAP database. Each record in this database is for one user and each user has a unique identifier that is used as MISER identifier.

2. SMS has to be able to support the adding/deleting of services in MISER.

Each service that will be added to/deleted from the MISER has a database. I designed a simple format for a service specification file. In this specification file, each service designer writes the service’s database structure, different tables in the database and default values. SMS reads this file and automatically service will be added to/ deleted from the MISER.

3. Flexible Subscription. Flexible Subscription means that the user has the possibility to add, delete, enable and disable services in her/his account anytime and change subscription of services again if needed.

The last entry ‘SupportedExtention’ in LDAP will be used for writing/reading the name of all services that the user was subscribed to. There is field in each service’s database structure to enable or disable the service for user.

4. Manage users’ subscription requirements.

A Web interface is provided. This Web interface is just an example of what can be done in order to manage user’s subscription requirements. Any Internet application that will use MISER can provide its own Web interface.

5. Support the information exchange between different Internet applications and SMS.

A special protocol is designed in SMS. This protocol creates the possibility for different Internet applications and different terminals to exchange information with the MISER in a way without sending and receiving defined types as Strings, Integers etc.

30

I implemented all necessary features specified in the Master’s thesis project in the Java programming language. Besides the database management part, I implemented the networking part too. The users themselves use a WWW client as an input to the system and query facility for managing user subscriptions. Various functions that can be accessed by the end-user through the web browser interface are: subscription creation, deletion, enables or disables service(s) and various queries about subscription status and. By providing careful design of the user-related data, and their distribution among databases, along with the design of the configuration file data format, I enabled easy managing of the databases environment.

6.2 Conclusion

The task of the Master’s thesis project was to design a front-end application for managing a number of databases containing various data, related to a user subscription for the set of services. An initial set of services and distribution of the data among databases, were given as input.

The main value added feature to the front-end application is the capability of managing an arbitrary number of databases without any changes in the application’s code. The idea is simply to be able to add new or remove existing services and corresponding user data to those services during the front-end’s runtime. This was achieved by introducing the special configuration file, which could be dynamically updated and re-read by the managing application, thus providing an easy way of adding/removing new databases. Another important issue for providing such flexibility was extremely careful design of the user data records, their types, and a set of common records across all databases, which are part of the current configuration but may be removed or added later.

In the thesis study it was found that the system should be able to handle and present as much predefined data as possible to simplify the support of the different services and to support the information exchange between different Internet applications and SMS.

There are some issues regarding further development of the system. Some new code in the Subscription Management Protocol (SMP) can be changed in/added to the protocol in the future - for example when a new service will be added to system. To support this you have to change/add the program code of the protocol module and define the new code. SMS had been thought as an automatically subscription management system and such changing/adding is not logical. A proposal solving of this problem is a protocol specification file that can be created and necessary protocol changing will be written in this file.

To support “Flexible Subscription” SMS handles with two databases: LDAP to add/delete a service and service’s database to enable/disable a service. To provide this functionality SMS can work with just one database. This implementation needs some changing of the LDAP database structure and service’s database. It means that SMS can add/delete or enable/disable a service in the system through the handle with the LDAP database. Of curse to support the other functions of SMS different databases are still needed.

It is necessary to include support for user charging. This requires implementation of a dynamically expandable set of events, which trigger different aspects of a charging mechanism. However, it was considered quite a big addition to the specified project and was left for future work.

31

References 1. B. Aboba, M. Beadles, The Network Access Identifier, RFC 2486, January 1999.

2. T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifiers (URI) Generic Syntax, RFC 2396, August 1998.

3. S. Bradner and A. Mankin, The Recommendation for the IP Next Generation Protocol, IETF RFC 1752, Jan. 1995.

4. P. Calhoun, C. Perkins, Diameter Mobile IP Extensions, April 2001.

5. P. Calhoun, C. Perkins, Mobile IP Network Access Identifier Extension for IPv4, RFC 2794, March 2000.

6. M. Day, J. Rosenberg, H. Sugano, A model for Presence and Instant messaging, RFC 2778, February 2000.

7. S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, IETF (1998).

8. Alan Demers, Karin Petersen, Mike Spreitzer, Douglas Terry, Marvin Theimer, Brent Welch, The Bayou Architecture: Support for Data Sharing among Mobile Users, Xerox Palo Alto Research Center, California 94304 U.S.A. 1995.

9. Kevin Downes, Merilee Ford, H. Kim Lew, Steve Spanier, Tim Stevenson, Internetworking Technologies Handbook, second edition, Macmillan Technical Publishing, 1998. ISBN: 1-57870-102-3.

10. E. Guttman, C. Perkins, J. Veizades, and M. Day, Service Location Protocol version 2, RFC 2165, Mar. 1998.

11. M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, SIP: Session Initiation Protocol, RFC 2543, March 1999.

12. John Ioannidis, Dan Duchamp, and Gerald Q. Maguire Jr, IP based Protocols for Mobile Internetworking, In Proceedings of ACM SIGCOMM, pages 235–245, 1991.

13. John Ioannidis and Gerald Q. Maguire, The Design and Implementation of a Mobile Internetworking Architecture, In Proceedings of Winter USENIX, Pages 491–502, San Diego, CA, Jan 1993.

14. Yuri Ismailov, Presence API: Developer Guide, Ericsson Report T/N-01: 63, April, 2001.

15. Mitsunobu Kunishi, Masahiro Ishiyama, Keisuke Uehara, Hiroshi Esaki, and Fumio Terakoa, Lin6: A New Approach to Mobility Support in IPv6, In Proceedings of the Third International Symposium on Wireless Personal Multimedia Communications, November 2000.

16. P. Mockapetris, Domain Names: Implementation and Specification, RFC 1035, November 1987.

17. C. Perkins, IP Mobility Support, RFC 2002, October 1996.

18. C. Perkins and D. Johnson, Mobility Support in IPv6, Internet-draft, IETF (2000).

19. William Stallings, Data and Computer Communications, fourth edition, Prentice Hall, 1998. ISBN 0-02-415441-5.

20. The Lightweight Directory Access Protocol (v3) LDAP RFC2251 (ftp://ftp.isi.edu/in-notes /rfc2251.txt)

32

21. J. Veizades, E. Guttman, C. Perkins, and S. Kaplan, Service Location Protocol, RFC 2165, July 1997.

22. Hiromi Wada, Takashi Yozawa, Tatsuya Ohnishi, and Yasunori Tanaka, Mobile Computing Environment Based on Internet Packet Forwarding, In proceedings of Winter USENIX, Pages 503–517, San Diego, CA, Jan 1993.

33

Appendix A: Structure of LDAP and Service Specification File

A.1 LDAP LDAP stands for Lightweight Directory Access Protocol. LDAP is a directory access protocol that runs over TCP/IP. For more information about the nitty-gritty details of LDAP see Reference 20. The LDAP information model is based on entries. An entry is a collection of attributes that has a globally unique Distinguished Name (DN). The DN is used to refer to the entry unambiguously. Each of the entries' attributes has a type and one or more values.

In LDAP, directory entries are arranged in a hierarchical tree-like structure. Traditionally, this structure reflected geographic and/or organizational boundaries. Entries representing countries appeared at the top of the tree. Below them are entries representing states and national organizations. Below them might be entries representing organizational units, people, printers, documents, or just about anything else you can think of. Environment variables for LDAP database in SMS that are defined in a separate file (Env.java) are described as an example in Appendix A.4.

The entries in the LDAP database that SMS uses are: Default Variable in LDAP Description

• Cn Common Name (User Name) • Sn Surname • GivenName First Name • UserPassword • Mail • Ou Company • PostalAddres • St Us State • PostalCode • TelephonNumber • FacsimileTelephonNumber • SupportedExtention User’s Services in MISER

These default variables will be used to create an account for a user. The last entry ‘SupportedExtention’ will be used for writing/reading the name of all services that the user was subscribed to.

A.2 Service Specification File To connect and manipulate service databases, SMS needs to read the information from the specification file on each service database structure and default values, which will be used by account creation operation. Two examples of service database specifications are below. The first four fields (uname, lxemail, passwd, enable) are compulsory in any service database table and will be written by SMS. It means that

34

when a user changes his/her subscription –adds, delete, disable or enable-in MISER, the SMS writes the record in the service’s database. Each service database name has a ‘db_’ prefix to show that it is a database name, and the name of database, as ‘ lx’ will be saved in the user’s account as a service that she /he can use. This name will be used by SMS to write the last entry in LDAP (see Appendix A.1 LDAP).

Example 1: db_lx.conf DBHOST local host DBNAME db_lx USERNAME root PASSWD TABLE custermcap (

Uname Lxemail Passwd Enable Termcap ‘String’

) TABLE custdynamic (

Uname Lxemail Passwd Enable

Ipaddr ‘0.0.0.0’ Pripaddr ‘0.0.0.0’ Prestatus 0 Pripub 1 Ttlsec 0 Tmptfn ‘String’ Tmpem ‘String’ Utime 4598645 Requests 984789 Updates 20000612 )

As can be seen the name of the database is db_lx. Database is on ‘ localhost’ and with the username ‘ root’ you can connect to the database. This database has two tables: ‘custermcap’ and ‘custdynamic’ . The first four fields in each table don’ t need default values and the other fields are defined by the service database and will be used by them; therefore the SMS does not need to know more about these fields.

Example 2: db_sx.conf DBHOST localhost DBNAME db_sx USERNAME root PASSWD mypass TABLE c_sxdynamic (

Uname Lxemail Passwd Enable

35

Ipaddr ‘0.0.0.0’ Pripaddr ‘0.0.0.0’ Prestatus 1 Pripub 1 Ttlsec 1 ) TABLE c_sxmcap (

Uname Lxemail Passwd Enable

Termcap ”String” Tmpem ”String”

Utime 873573 Requests 4909845

)

The designer of MISER and I designed the Subscription Management Protocol (SMP) for information exchange between a Web server and SMS–see figure 6. Each information exchange between them has to be in SMP format. The details of this protocol are described below.

Format of SMP

byte 1 byte 2 byte 3 byte 4 byte 5 byte 6 byte 7 … byte n

A.2.1 Protocol Format Description Number of byte Description

1 Protocol Number: Value 1 for Internet to SMS and value 100 (decimal) for SMS to Internet

2 Operation code 3-4 Sub code 5 Number of data fields 6-7 Number of bytes in this buffer after byte 7

‘Payload size’ Data Field

No. Data fields

Protocol Number

Operation

code Sub code Number of

bytes

36

A.3.2 Operation Code Description Value of byte 2 Description

1 Create Account 2 Delete Account 3 Service Operation in MySQL databases 4 Get user information from LDAP

A.3.3 Sub Code Description Value of bytes 3-4 Description

0 Add Service 1 Delete Service 2 Enable Service 3 Disable Service

A.3.4 Data Field Description Bytes 8-9-… Number of byte(s) Description

8-9 Type of data (Value 1: the first name, 4: the Username, 8: the address and etc)

10 Size of Data 11… Data

37

Appendix B: MSC (Message Sequence Chart) MSC is a trace language which in its graphical form admits a particularly intuitive representation of system runs in distributed systems while focusing on the message interchange between communicating entities and their environment. This Appendix describes how different components in SMS work together and how they communicate.

B.1 Getting Information from the Specification File

services databases

Get Services databases information

Services Databases Structure & default Values

Asked information

Services databases

information Information In SMP format Services Databases

Information In SMP format Services databases information

The Main Module

Protocol Module

Speci- fication

File

Service Interface Module

The Web Interface Module

Specification File Parser

Module

38

B.2 Logging for Delete and Update an Account

Username & Password

SMP for Logging Read & Analyse

SMP wrong Error SMP wrong Message SMP OK

Username & Password Check-up

Username (or/and) Password

Wrong

Wrong Wrong

SMP SMP

Username OK Error Message Confirm Confirm

SMP SMP New Asked Window

Web Interface Module

Main Module

Protocol Module

LDAP Module

LDAP DBMS

SMP OK?

False

True

OK? False True

39

B.3 Logging for Add, Delete, Enable, Disable a Service

Username & Password SMP for Logging Read & Analyse SMP wrong

Error SMP wrong Message SMP OK

Username & Password Check-up

Username (or/and)

Password

Wrong Wrong Wrong

Error Message SMP SMP Username OK Available Services Confirm & Available Services Confirm & Available Services SMP SMP New Asked Window for available services

Web Interface Module

Main Module

Protocol Module

LDAP Module

LDAP DBMS

SMP OK?

False

True

OK? False True

40

B.4 Account Creating

Information to Create an account SMP for Account creation Read & Analyse SMP wrong

Error SMP wrong Message

SMP OK Information to create an account

Check out

Username

Wrong Username Wrong Username

Wrong Username

SMP SMP Error Message Username OK Create an Account Confirm Confirm Confirm SMP Confirming of SMP Account creation

Web Interface Module

Main Module

Protocol Module

LDAP Module

LDAP DBMS

SMP OK?

False

True

User name OK? False True

41

B.5 Account Deleting

Delete Account SMP for

Account Deleting Read & Analyse SMP wrong

SMP Wrong Error Message SMP OK

Delete an account Is there Account?

Wrong

Wrong Wrong SMP SMP Error Message Confirm

Delete Account Confirm Confirm Confirm SMP SMP Confirming of Account Deleting

Web Interface Module

Main Module

Protocol Module

LDAP Module

LDAP DBMS

SMP OK?

False

True

Is There? False True

42

B.6 Account Updating

Updating Account SMP for Account Updating

Read & Analyse SMP wrong

SMP wrong Error Message SMP OK Update an account

Is there Account?

Wrong

Wrong Wrong

SMP SMP Error Message Confirm

Update Account

Confirm Confirm Confirm SMP

SMP Confirming of Account Updating

Web Interface Module

Main Module

Protocol Module

LDAP Module

LDAP DBMS

SMP OK?

False

True

Is There? False True

43

B.7 Getting Account Information

Get Account Information SMP for Getting Information

Read & Analyse SMP wrong

Error SMP wrong Message

SMP OK

Getting Account Information Is there Account?

Wrong

Wrong Wrong

SMP SMP Error Message Confirm

Get Information Account Information

Account Information Account Information

SMP SMP Account Information

Web Interface Module

Main Module

Protocol Module

LDAP Module

LDAP DBMS

SMP OK?

False

True

Is There? False True

44

B.8 Delete Service

Delete Service SMP for

Delete Service Read & Analyse

SMP wrong SMP wrong

Error Message SMP OK

Data Base Information Delete Service

Delete

Confirm Confirm

SMP

SMP Confirm

Web Interface Module

Main Module

Protocol Module

Service Interface Module

MySQL DBMS

SMP OK?

False

True

45

B.9 Add Service

Add Service SMP for

Adding Service Read & Analyse SMP wrong

Error SMP wrong Message

SMP OK

Data Base Information Add Service

Add Service

Confirm Confirm

Confirm SMP

SMP Confirm

Web Interface Module

Main Module

Protocol Module

Service Interface Module

MySQL DBMS

SMP OK?

False

True

46

B.10 Enable Service

Enable Service SMP for

Enabling Service Read & Analyse Wrong SMP

SMP wrong Error Message SMP OK

Data Base Information Enable Service Enable Service

Confirm Confirm Confirm SMP SMP Confirm

Web Interface Module

Main Module

Protocol Module

Service Interface Module

MySQL DBMS

SMP OK?

False

True

47

B.11 Disable Service

Disable Service SMP for Disabling Service Read & Analyse SMP wrong

SMP wrong Error SMP Message OK

Data Base Information Disable Service Disable Service

Confirm Confirm Confirm SMP SMP Confirm

Web Interface Module

Main Module

Protocol Module

Service Interface Module

MySQL DBMS

SMP OK?

False

True

48

Appendix C: User End Windows MISER can be used by any system that has some network services and can provide a user interface. Appendix C describes one example of the user interface that can be used by such a system.

The web Interface is a PHP–script. To have an account in MISER or change and update subscription of services, this interface generates HTML pages to show information about existing services in MISER, get user information and user requests and sends requests to SMS through the SMP (see Appendix A.3). C.1 is a picture of a window for creation of an account. C.2 picture shows the needed information (user name and password) to delete an account.

C.1 Create Account

49

C.2 Create Account Continue

50

C.3 Delete Account