Embed Size (px)
Citation preview
Tampere University of Technology
Department of Information Technology
Joona Hartman
Implementing a Service Discovery Mechanism for Mobile IPv6
Environments
Master of Science Thesis
Subject approved by the department council on 18.8.2004
Supervisors: Bilhanan Silverajan
Hannu-Matti Järvinen
Jarmo Harju
Foreword
This Master of Science Thesis was written during summer 2004 at the Institute of Com-
munications Engineering at Tampere University of Technology. I want to thank professor
Hannu-Matti Järvinen, professor Jarmo Harju and MSc. Bilhanan Silverajan for the support
and guidance given during the writing of this thesis. I also want to thank Nokia Networks
for giving some work hours to finish the thesis, and Anna Tuusa for giving invaluable advice
on the English language.
This thesis was typeset with LaTeX typesetting system.
Tampere, August 31, 2004
Joona Hartman
Opiskelijankatu 4 E 278
33720 Tampere
FINLAND
i
Abstract
TAMPERE UNIVERSITY OF TECHNOLOGY
Department of Information Technology
Institute of Software Systems
HARTMAN, JOONA: Implementing a Service Discovery Mechanism for Mobile IPv6
Environments
Master of Science thesis: 60 pages, 10 enclosure pages
Examiners: Prof. Hannu-Matti Järvinen, prof. Jarmo Harju and MSc. Bilhanan Silverajan
August 2004
The rapid development of computer technology is making it possible to connect more and
more varied devices to communications networks. To utilise the services offered by hosts in
the network, hosts must be able to locate the services dynamically without having to man-
ually configure every instance of every utilised service. Service Location Protocol version
2 (SLPv2) enables hosts to discover services offered in the network without manual inter-
ference from the user. Mobile IPv6 technology enables hosts to move between networks
without reconfiguring the host or losing transport level connections established while the
host was in another network. Mobility brings additional requirements for service discov-
ery mechanisms. Unanticipated movement may cause problems in service discovery and
provision.
This thesis designs and implements a method for utilising SLPv2 from mobile terminals.
By extending a standardised protocol with two new components, it is possible for mobile
terminals to interoperate with existing implementations that are utilised in fixed nodes and
use the services offered in the network. The main focus in design was interoperability be-
tween the new components and the standard SLPv2 implementations. The design also adds
some new features to SLPv2, which aim at empowering the user to take more advantage of
the network.
The prototype implementation was done using the DOORS (Distributed Object Operations)
framework. DOORS is an application development framework which can be used in devel-
oping communications software and protocols. DOORS is object-oriented and event-driven
ii
by design and the implementation followed the conventions used in most DOORS applica-
tions. Tests performed with the prototype implementation were successful and showed that
the design was feasible. Some improvement ideas and enhancements to the new compo-
nents have been considered for future development.
iii
Tiivistelmä
TAMPEREEN TEKNILLINEN YLIOPISTO
Tietotekniikan osasto
Ohjelmistotekniikka
HARTMAN, JOONA: Implementing a Service Discovery Mechanism for Mobile IPv6
Environments
Diplomityö: 60 s., 10 liites.
Tarkastajat: Prof. Hannu-Matti Järvinen, prof. Jarmo Harju ja DI Bilhanan Silverajan
Elokuu 2004
Tietokoneiden ja muiden tietoverkkoihin liittyvien laitteiden on kyettävä käyttämään
hyväkseen verkossa tarjolla olevia palveluja. Käyttääkseen tiettyä verkossa olevaa palvelua
tietokoneen täytyy tietää, mitkä koneet tarjoavat kyseistä palvelua ja miten sitä voidaan
käyttää. Tavallisesti tämä tieto välitetään tietokoneen ohjelmille käyttäjän kirjoittamis-
sa alustustiedostoissa. SLP-protokollalla (Service Location Protocol) on mahdollista dy-
naamisesti etsiä palveluja tietoverkosta, jolloin käyttäjän ei itse tarvitse tietää, missä palve-
lut sijaitsevat ja miten niihin saa yhteyden. Tämä vähentää ylläpitotyötä palvelujen tarjoa-
jien vaihtuessa ja uusien käyttäjien liittyessä verkkoon. Erityisesti tästä on hyötyä vieraile-
vien käyttäjien liittyessä verkkoon.
Mobile IPv6-teknologia mahdollistaa tietokoneiden liikkumisen tietoverkossa siten, et-
tä tietokone säilyttää avaamansa kuljetuskerroksen yhteydet ja on tavoitettavissa yh-
den IPv6-osoitteen kautta. Tässä diplomityössä yhdistettiin Mobile-IPv6-teknologian tuo-
mat mahdollisuudet liikkua tietoverkossa sekä palveluiden etsiminen SLP-protokollaa
käyttäen. SLP-protokollaa laajennettiin kahdella komponentilla, jotka mahdollistavat sen
käytön mobiileissa laitteissa. Yhtenä päätavoitteena oli säilyttää yhteensopivuus SLP-
standardiin. Tämä mahdollistaa muiden SLP-toteutusten käytön verkkoon kiinteästi liit-
tyneissä tietokoneissa. Komponentit tarjoavat käyttäjälle myös lisätoimintoja, joita käyt-
tämällä voi automatisoida liikkumiseen liittyviä rutiinitoimenpiteitä, kuten palvelutietojen
päivittämistä.
iv
Komponentit suunniteltiin DOORS-ympäristössä (Distributed Object Operations), jossa
tehtiin myös prototyyppitoteutus. DOORS on oliopohjainen ohjelmistokehitysympäristö,
joka tarjoaa työkaluja tietoliikenneprotokollien ja tilakoneiden suunnitteluun ja toteutuk-
seen. Toteutus tehtiin oliopohjaisella mallilla ja se noudatti DOORS-ympäristössä yleis-
esti käytettyjä toteutustapoja. Prototyypin testaus toteutettiin tietoliikennetekniikan laitok-
sen verkossa. Testauksessa todettiin malli hyvin toimivaksi, vaikka joitain parannusajatuk-
sia nousi esiin testauksen aikana. Jatkokehityksessä tullaan kiinnittämään huomiota mallin
toiminnallisuuden laajentamiseen.
v
Table of Contents
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Tiivistelmä . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Service Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1 Scenario: Dynamic Office . . . . . . . . . . . . . . . . . . . . . . . 42.2 Dynamic Service Discovery . . . . . . . . . . . . . . . . . . . . . . 52.3 Using Static Configuration . . . . . . . . . . . . . . . . . . . . . . . 72.4 Discovering Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Directory Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6 Rendezvous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.7 UPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.8 Service Location Protocol . . . . . . . . . . . . . . . . . . . . . . . 10
2.8.1 Service: URLs . . . . . . . . . . . . . . . . . . . . . . . . . 112.8.2 Service Location Protocol Messages . . . . . . . . . . . . . . 122.8.3 SLP in IPv6 Networks . . . . . . . . . . . . . . . . . . . . . 14
3 Mobility in IP Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1 Wireless Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 Issues With Service Discovery . . . . . . . . . . . . . . . . . . . . . 19
4 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.1 Design Aims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1 Automatic Rediscovery of Services . . . . . . . . . . . . . . 224.1.2 Providing Services From a Mobile Node . . . . . . . . . . . . 22
4.2 New Agents to Extend SLPv2 . . . . . . . . . . . . . . . . . . . . . 234.3 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4 The Access Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.1 Access Agent Advertisement . . . . . . . . . . . . . . . . . . 264.4.2 User Agent Proxying . . . . . . . . . . . . . . . . . . . . . . 274.4.3 Service Registration Cache . . . . . . . . . . . . . . . . . . . 284.4.4 Logical Composition of the Access Agent . . . . . . . . . . . 29
4.5 The Visiting Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.5.1 Transient and Persistent Services in a Mobile Node . . . . . . 304.5.2 Automatic Rediscovery of Services . . . . . . . . . . . . . . 314.5.3 Communicating With Directory and Access Agents . . . . . . 324.5.4 Logical Composition of the Visiting Agent . . . . . . . . . . 33
vi
4.5.5 The Entity Task . . . . . . . . . . . . . . . . . . . . . . . . . 344.5.6 Service Request Connection Task . . . . . . . . . . . . . . . 364.5.7 Service Provision Connection Task . . . . . . . . . . . . . . 374.5.8 Agent Connection Task . . . . . . . . . . . . . . . . . . . . . 38
5 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.1 The DOORS Framework . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1.1 DOORS Scheduling and IO-handling . . . . . . . . . . . . . 425.1.2 Protocol Implementation with DOORS . . . . . . . . . . . . 425.1.3 The XML Code Generators And the Protocol Tool-Box . . . . 435.1.4 Multiple Connection Handling . . . . . . . . . . . . . . . . . 445.1.5 The Movement Notification Module . . . . . . . . . . . . . . 45
5.2 Service: URL Parser . . . . . . . . . . . . . . . . . . . . . . . . . . 465.3 The Access Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.1 User Agent Proxy . . . . . . . . . . . . . . . . . . . . . . . . 475.3.2 Service Caching . . . . . . . . . . . . . . . . . . . . . . . . 49
5.4 The Visiting Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.4.1 VAEntity Task Implementation . . . . . . . . . . . . . . . . . 505.4.2 VUAConn Task Implementation . . . . . . . . . . . . . . . . 515.4.3 SAReg Task Implementation . . . . . . . . . . . . . . . . . . 525.4.4 AgentConnection Task Implementation . . . . . . . . . . . . 53
6 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.2 Test Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.3 Mobile Node Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.4 Service Provision In Visiting Agent . . . . . . . . . . . . . . . . . . 566.5 Service Discovery In Visiting Agent . . . . . . . . . . . . . . . . . . 566.6 Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Appendices
A XML State MachineDefinitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B Screenshots from Ethereal Network Protocol Analyzer . . . . . . . . . . 70
vii
List of Acronyms
AA Access Agent
API Application Programming Interface
BNF Backus-Naur Form
BU Binding Update
CN Correspondent Node
DA Directory Agent
DHCP Dynamic Host Configuration Protocol
DNS Domain Name Service
DOORS Distributed Object Operations
dsmg Doors State Machine Generator
GNU GNU’s Not Unix
HA Home Agent
HTTP Hypertext Transport Protocol
ICMPv6 Internet Control Message Protocol for IPv6
IETF Internet Engineering Task Force
IP Internet Protocol
IPv4 Internet Protocol, version 4
IPv6 Internet Protocol, version 6
IPX Internet Packet Exhange
LAN Local Area Network
LDAP Light-weight Directory Access Protocol
mDNS multicast DNS
MIPL Mobile IPv6 for Linux
viii
MN Mobile Node
MTU Maximum Transmission Unit
OSI Open Systems Interconnection
PDA Personal Digital Assistant
PDU Protocol Data Unit
PTB Protocol Tool-Box
RFC Request For Comments
SA Service Agent
SAP Service Access Point
SLP Service Location Protocol
SLPv2 Service Location Protocol, version 2
SSDP Simple Service Discovery Protocol
SSH Secure Shell
TCP Transmission Control protocol
TTL Time To Live
VoIP Voice over IP
UA User Agent
UDP Unreliable Datagram Protocol
URI Uniform Resource Identifier
URL Uniform Resource Locator
UPnP Universal Plug’n’Play
VA Visiting Agent
WLAN Wireless Local Area Network
XCG XML Code Generators
XML Extensible Markup Language
ix
1 Introduction
The rapid development of computers and communications technology is allowing more
and more devices to interact with each other. The devices that can now be connected to the
Internet range from traditional desktops to laptops, PDAs (Personal Digital Assistant) and
mobile phones. The development of wireless technologies has enabled users to connect to
traditional networks over wireless links, without much trouble and with high speeds. As a
more diverse group of devices can be reached over the Internet, the dilemma of being able
to locate them becomes manifold. A user wishing to utilise the whole range of services
offered in a network has to perform a multitude of configuration tasks to let the user’s
computer know where all the separate services are located. In the present age of powerful
computing, it seems odd to be forced to perform such a rudimentary job manually.
Service Location Protocol (SLP) can be used to couple users and network services, so
that the user does not have to know where the specific instance of the requested service is
located. SLP is meant to be utilised in enterprise level networks, where multicasting tech-
niques can effectively be used. SLP can be utilised in a dynamic fashion, where service
providers and users can enter the network and locate each other without necessary negotia-
tors. Up-to-date information is always available through multicast technology, where the
service providers themselves have the possibility to answer to service requests. In larger
networks, optional caching agents can be set up to provide robustness and optimal perfor-
mance. The need for manual configuration and administration is notably lessened.
The new version of the standard Internet communications protocol, IPv6, enables an im-
1
mense amount of devices to be hooked up to the Internet, with great ease. Automatic
configuration of IPv6 addresses performed with the help of routers lets any device connect
to the network without the help of an administrator. Together with service discovery tech-
nologies, the devices can be utilised without any detailed knowledge of the network itself.
Protocols enabling all these are fast, effective and simple enough to be used even in the
smallest of devices.
The wireless technologies that are nowadays common everywhere enable users to move
freely inside the coverage area of the network. However, persistent connections are lost
if the user moves out of the network block where the host is connected in. Mobile IPv6
technology resolves this issue, enabling users to visit other networks while preserving the
transport-level connections already established earlier. The particulars of the movement
procedures are hidden from the users and the applications. This works well for point to
point connections where the end points are only concerned about preserving the connection,
not where the end points at any one time are situated. Applications that take into account
the location of peers based on the IPv6 address of the peer, might fail to recognise that
the mobile host is not in its home network. Movement information can be obtained from
the Mobile IPv6 module through an extension, which notifies interested applications of
movement events.
Service discovery with mobile hosts brings forth a range of problems, but also many pos-
sibilities. Location aware or dependent services suffer from host movement between net-
works. Instead of hiding the movement of the mobile host from the applications and the
user, it can be partially exposed to the application layers to enable varied policies to be set
regarding different situations. Automatic procedures can be executed when the mobile host
leaves a network and enters another one. Interaction with static members of the network
using standard protocols enables mobile hosts utilise all services available in the network.
This work aims at designing and implementing extensions proposed to SLP version 2 to
enable service discovery and provision from mobile hosts. The extensions enable a mobile
user discover local network services seamlessly in a foreign network and also allows ser-
vices hosted on the user’s mobile terminal be discovered from fixed hosts both in home and
foreign networks using standard SLP procedures. This thesis focuses on the possibilities
introduced by the use of Mobile IPv6 technology in hosts.
2
Chapters 2 and 3 explain the background of service discovery and mobility, respectively.
The scope of this thesis is, as the title implies, fixed and wireless IPv6 networks. Any termi-
nal supporting IPv6 and Mobile IPv6 can potentially utilise the methods. No consideration
is given to other kinds of mobile technologies or wireless networks, such as 3G networks
and devices.
Chapter 4 describes a design for extensions to the SLPv2 protocol which enable service
discovery in mobile hosts. Both service discovery and service provision are covered. The
design is meant to be simple, effective, and extensible for future development.
Chapter 5 describes a prototype implementation of the design. The prototype implemen-
tation aims at proving that the methods described in this thesis are feasible using available
technology.
Chapter 6 demonstrates some results and explains some of the issues discovered during the
course of design and implementation. Some future improvement ideas are also given for
enhancing the design.
3
2 Service Discovery
This chapter presents background information highlighting the problem domain of service
discovery. First section discusses a scenario where service discovery can be deployed prof-
itably to give a motivation for deployment of service discovery mechanisms. Later sections
present the general problem of discovering services in a computer network and some of the
available existing methods.
2.1 Scenario: Dynamic Office
The concept of a dynamic office is a scenario which might very well be used in industry,
and with great benefit to the company. In contrast to a normal office, where every worker is
allocated a room or a desk where to sit every day during working hours, in a dynamic office
one would allocate a working space (such as a desk or a cubicle) to the person upon entering
the office to come to work. Considering that hardly ever all the employees are at the office
at the same time, it would save money for the company to allocate a smaller amount of
office space to its workers’ disposal. This scheme would naturally require the worker to
have all of his or her equipment portable (either bringing them from home or having them
waiting by the reception) when entering the office. A laptop would meet the requirements
well, for example. As almost every office has nowadays a computer network to which all
the computers in the office are connected, one must be able to connect to it from every desk
just as if the worker never left his or her own desk. As an employee might have to work in
different parts of the building on different floors, the adaptability of the computer network to
4
accommodate the ever changing situation becomes critical. It must be possible to configure
network services, such as email, news, web cache, file access, printing, fax, and VoIP,
without manual interference or the help of an administrator. Every minute spent configuring
services manually expends productive working time, thus costing the company money. Here
a scalable service discovery mechanism becomes priceless. When the computer starts up,
it first activates the wireless network interface, which connects to the company’s network
using DHCP or some other suitable method, and then the service discovery mechanism
automatically resolves the services chosen in the user’s configuration, and perhaps lists
available service types in the network, from which the employee can choose whatever he
or she desires to use (e.g. an internet radio station). Furthermore, this framework could be
utilised when having meetings with clients or with other project members. The terminals
would work seamlessly anywhere inside the company’s network, be it a traditional wired or
a wireless network.
The idea of the ’virtual’ office was introduced in [1].
2.2 Dynamic Service Discovery
Service discovery in this context can be defined as finding services in a computer network
without manual help or interference by a human. In order to use a given service, the user (or
the user’s host computer) must know the network address of the host providing the service,
the port number to connect to, and the protocol used to access the service. Thus it is this
information that the service discovery mechanism must try to resolve. Discovery must be
performed automatically without knowledge or help from the other hosts in the network, so
that a terminal joining the network can instantly employ service discovery procedures. This
allows any user without explicit knowledge of the network or the technology involved to
use the services provided in the network. The aim of dynamic service discovery is to have a
robust way of distributing the information needed to use network services, preferably doing
so without the need for intermediary negotiators. Of course, some level of configuration or
boot-strapping is needed to attain this goal. At the minimum, the mechanism must know
the type of service it is supposed to look for.
A service discovery scheme effectively provides a mapping between the type of service
5
requested (and possibly some constraints set by the user), and a list of instances of the
given service type, along with necessary information needed to utilise the service. Service
discovery schemes are usually meant to be used in enterprise level (or smaller) networks
containing shared resources that are under a single management entity. Resources and
services that can be utilised this way include printers, directory services, and internet radios.
Several different kinds of service discovery mechanisms of varying levels of sophistication
have been designed and implemented. The most basic form of service discovery is merely to
provide a way to retrieve information from the network - for example a Universal Resource
Indicator (URI) - which is enough to allow the user to access the service. A URI specifies
such things as the host address and the port number of the server, along with the name of
the protocol used to access the service (e.g. "ipp://example.com:10000/path/to/resource"
would be an example of a URI). This allows the user to contact the service, but the mecha-
nism does not provide a way to utilise the service itself. The service discovery mechanism
could also provide a list of different types of services available, from which the user can
select the type of service he/she is looking for. This mode of operation is known as service
browsing.
Some service discovery schemes provide more than just the information needed to con-
tact to service. For example the Salutation Architecture [2] offers, not just service location
methods, but also device interaction and access technologies. A user can utilise services
without implementing many separate protocols needed to utilise all the different types of
services. This approach has its pros and cons. On one hand, the idea of having just one
unified method of using all available services is certainly appealing. On the other hand, it is
easy to see that designing an interaction method that suites all possible service types is ex-
tremely difficult. Just considering the differences between a printing service and an internet
radio shows that such a scheme has to be very complex: a printing service requires error
free data transfer where latency is not so important, whereas an internet radio would rather
compromise in data coherency and data loss but consider minimal latency very important.
6
2.3 Using Static Configuration
Using static configuration is not really a form of service discovery, but it can be consid-
ered as a starting point for more sophisticated schemes. When using static configuration,
all the users of services (such as the Domain Name Service (DNS) or printing services)
have configuration files that describe the necessary information needed to contact the ser-
vices. This method requires a lot of manual work, because the configuration information
has to be updated whenever the services are reconfigured or new services are added to the
network. Manual help is also needed when a new terminal is set up in the network and
wants to utilise the services present. In homogeneous networks, configuration files can be
distributed with automated tools, which eases administration. In heterogeneous networks
with several different operating systems and setups, the administration cannot be eased even
with automated tools. All service discovery schemes attempt to get rid of the need for static
configuration.
2.4 Discovering Attributes
In addition to just finding a service from the network, the user might have some further
requirements for the service he or she is looking for. If the user is looking for a printing
service, for example, he or she might want to access one that can print in colour, or has a
resolution of a desired grade. These qualities can be described as attributes of the service.
The user can filter offered service instances based on the attributes that they have. The
attributes can either be presented in a standard form, so the service discovery mechanism
can filter them, or then they must be presented to the user in human readable form so that
the user can select the appropriate service instance manually. The latter method is suitable
if the amount of services offered is small, or if the attributes have values that are difficult to
parse and classify with a computer (e.g. the type of music an internet radio station streams).
Thus it would be best if the user could choose between these two methods according to his
or her needs. It would also be desirable to be able to retrieve all the attributes associated
with a service, as the user might not know which attributes are specified for which service
or service type.
7
2.5 Directory Services
A more sophisticated approach to service discovery is to centralise all the information to
a common entity, which is then accessed by all clients to query for service information
using a standard protocol. This reduces the amount of manual configuration and makes
updating and adding services much easier. Also, the information can be presented in a
platform independent form and then adapted to whatever form the platform supports at the
client’s side (e.g. in Windows as registry entries, and in Linux as textual configuration
files). However, this approach also has several weak points. The biggest disadvantage is
the vulnerable nature of centralised information. If the directory service is inaccessible
due to network or host failure, all the clients using the server will become crippled. The
risk can be lessened by using replica servers that can take over during failures and also
provide load balancing during high loads, but still serious problems can occur. Networks,
such as home networks and ad-hoc networks, that cannot have several servers dedicated to
directory services are especially problematic. In any case, the client needs to know where
the directory service is and how it can be accessed.
Another problem is the maintenance needed to upkeep the directory. Especially in a wire-
less environment, where hosts enter and leave the network dynamically, it is impossible
to have the directory up to date all the time. Directory servers, such as Light-weight Di-
rectory Access Protocol (LDAP) servers, are usually designed to be updated seldom but
accessed often, and to update an LDAP server constantly could bring too much burden to
it. For example, a printer service might, in its attributes, display information regarding its
current queue. This would bring too much burden to the directory server, and overhead to
the protocol, because some updates might not even be seen by a user before another update
is committed.
2.6 Rendezvous
Rendezvous [3] is Apple’s open source protocol for service discovery and zero configu-
ration networking in IPv4 networks. Zero configuration networking means that computers
in a network can automatically configure themselves, so that there is no need for manual
8
configuration of such parameters as IP-addresses, DNS (Domain Name Service) servers,
and URLs of services. Requirements for zero configuration networking in IP networks are
defined in [4]. These requirements, in short, are automatic IP interface configuration, au-
tomatic translation between host names and IP addresses, IP multicast address allocation,
and automatic service discovery.
The basic idea in Rendezvous is to first configure the host with a link-local address, then
choose a local unique DNS name for the host, to use Multicast DNS (mDNS) to locate other
hosts in the local network, and then use extended DNS records to discover services in other
hosts using mDNS. The name for the host is chosen by the user, and the mDNS system
proceeds to probe the network to see if the name is free. In case the name is already in use,
the host must, by some means, choose another name and try again. If two hosts are probing
for the same name simultaneously, a tie-breaker algorithm is employed to determine the
"winner" of the name.
The mDNS uses local DNS address space to separate queries meant for local host discov-
ery from the ones destined to the global DNS system. The mDNS draft [5] states that ”Any
DNS query for a name ending with ".local." MUST be sent to the mDNS multicast address
(224.0.0.251 or its IPv6 equivalent FF02::FB).” This means that the user must always ap-
pend the ".local." string to the host the user is looking for. This is far from intuitive. IP
address resolver in the user’s host can, of course, direct all queries that do not elicit answers
from the global DNS system to the mDNS resolver, but this delays the operation and brings
unnecessary load to the network.
Rendezvous is available for Mac OS X, Linux, FreeBSD, and Solaris. A version for Win-
dows is also in development. A Java implementation is also freely available. High avail-
ability and extensive operational qualities make Rendezvous an attractive solution to the
service discovery problem.
2.7 UPnP
UPnP (Universal Plug’n’Play) [6] is another commercial effort attempting to solve some
of the problems stated earlier. In contrast to other schemes introduced above, UPnP is an
9
extensive framework building on top of such Internet technologies as IP, TCP, HTTP, XML,
and many others. The UPnP Forum has a very large number of companies involved in it,
so it is likely to be used extensively in the future. For service discovery, uPnP uses SSDP
(Simple Service Discovery Protocol) [7]. SSDP uses multicasting to transmit queries to
the network, and it is rather simple in operation. SSDP does not employ caching agents
in the network, and it does not feature attribute requests or any kind of filtering based on
attributes. As transport layer protocol, SSDP uses XML over HTTP over UDP (which is
sent to a multicast address). This aims at using the protocols and technologies likely to be
already implemented in the terminal that uses UPnP. These design decisions make SSDP
more suitable to small networks rather than large enterprise level networks. Although UPnP
uses quite sophisticated technologies, it is meant rather for hand-held devices and other
resource and bandwidth scarce appliances than for desktop computers and servers.
2.8 Service Location Protocol
RFC 2608 [8] defines the second version of a protocol for automatic discovery of services
in IPv4 networks called the Service Location Protocol version 2 (SLPv2, or later just SLP).
The protocol uses UDP as the underlying protocol with retransmissions in case of packet
loss to ensure adequate reliability. Packets can either be sent to a well-known multicast
address allocated to SLP, or by using unicast directly to other SLP peers, if their addresses
are already known. SLP is a fairly light-weight protocol which does not require much
computational power, yet it provides an extensive set of operations allowing most kinds of
tasks to be performed. It also does not require much bandwidth to operate, so it is a good
solution even in bandwidth scarce environments.
The operation of SLP is based on agents that perform tasks on behalf of the user applica-
tions. At the minimum, two types of agents are needed for SLP to operate: user agents
(UA) send service queries in order to find services in the network, and service agents (SA)
take services registrations from user applications, listen for service queries, and answer to
them on behalf of the users.
To ensure robust operation under heavy usage, SLP introduces directory agents (DA), which
act as caches for service advertisements, and allow users to perform queries using unicast
10
transmissions. Hosts, therefore, do not need to multicast their every query several times
in order to be sure to reach all SAs. Instead, the query is sent directly to the DA, which
replies with a message that contains all the valid results. This is very beneficial once the
network has been established and stabilised, so that all agents in the network are aware
of the presence of the DA or DAs. DAs are optional agents that may be run on any host
in the network. The use of DAs suffers from the same problems as the use of directory
servers for information centralisation. SAs must send updates to DAs, in order to keep
the information up to date whenever the service advertisement is altered. The use of DAs
should be considered depending on the nature of services being offered in the network, and
the type of the network.
SLP in IPv4 networks limits the area it operates in by using the Time-to-Live (TTL) param-
eter in the IP header, limiting the distance the packet may travel in the network. TTL value
sets the number of routers that can pass the packet forward to another network. With each
hop, the TTL is decreased by one. When the TTL value reaches zero, the packet is deleted.
SLP refers to this procedure as scoping. This way the SLP messages can be restricted from
travelling out of a specified network.
2.8.1 Service: URLs
SLP stores and advertises services as service: URLs. The syntax for service: URLs used in
SLP is defined in RFC 2609 [9]. A simple service: URL might be for example: "ser-
vice:printing:ipp://printer.example.com:10000". The name, "service: URL", is derived
from the obligatory prefix "service:", which is prefixed in all service: URLs. A service:
URL represents a unique identifier for an instance of a service. It consists of a type defi-
nition (printing:ipp), a service access point (printer.example.com) identifier, which defines
how the service can be accessed, and an optional set of attributes. The type definition may
consist of two fields. The first of these describes the service with an abstract name (print-
ing) and the second gives the concrete type, usually a well known protocol name (ipp),
which describes how to communicate with the service access point. At the minimum, a
concrete type definition is required if the service is described sufficiently by it. The abstract
type definition may be omitted (e.g. service:ftp://ftp.example.com). However, it is recom-
mended to use both definitions for clarity (e.g. service:drivers:ftp://ftp.example.com). The
11
format of the access point string depends on the type definition and the type of network
in which the service is being offered. In IP networks this would usually be an IP address
possibly followed by a path (e.g. /pub/linux/kernel). The address part can also be an IPX
address (which consists of a network, node and a socket number), or an AppleTalk address
(which consists of object, type and zone identifiers). In case of an IP address, it can be
presented as a DNS name or a numerical address. The service: URL can also include a
list of service attributes embedded in it. Attributes are defined in a list separated from each
other by commas at the end of the service: URL. An attribute can be either just a name of
an attribute (denoting a presence of an attribute) or a name followed by ’=’-character and a
value (service:music:rtp://music.com,bitrate=44000,stereo).
2.8.2 Service Location Protocol Messages
SLP messages (or PDUs) are specified in detail in RFC 2608, but will be briefly described
here, because they are referred to several times later in this thesis. RFC 2608 specifies
six messages which must be supported in all implementations of SLP, and some optional
messages which may be supported if so desired. Optional messages include e.g. service
type and attribute requests. The RFC also defines authentication blocks that may be ap-
pended to certain SLP messages to verify the integrity of the message and that they have
been transmitted by an authorized agent.
All SLP messages include a uniform header in the beginning of the PDU. The header con-
tains common information that is needed in all messages. The different fields are sum-
marised in the following list.
� Version number (1 byte), which must have value 2 for SLPv2 messages.� Function identifier (1 byte), which indicates the type of the message. The different
ID values are shown in Table 2.1.� Transaction identifier (XID, 2 bytes), which is used to link replies with requests, and
to identify retransmissions. Unsolicited DA and SA advertisements have an XID
value of zero.� Length field (2 bytes), which specifies the amount of bytes in the message, SLP header
included (but not including UDP and IP headers).
12
� Language tag length (2 bytes), is the length of the language tag.� Language tag (variable length), which indicates what language the service must sup-
port (for example: "en" or "fi").
Most fields in SLP PDUs are either integers, strings, or lists of strings. Integers are logically
represented as an array of bytes arranged in the network byte-order. Strings are represented
as a variable length character array without a terminating null-character. The length is
encoded preceding the character array as a 16 bit unsigned integer. Lists of strings are
presented in a similar form, strings encoded separately along with their lengths. Before the
list, the number of items in the list is presented as a 16 bit unsigned integer. Empty strings
and lists are also permitted, in which case the only data is the length field.
SLP messages are listed in Table 2.1 Service request and service-type request also carry
Message Type Abbreviation Function-ID
Service Request SrvRqst 1
Service Reply SrvRply 2
Service Registration SrvReg 3
Service Deregister SrvDeReg 4
Service Acknowledge SrvAck 5
Attribute Request AttrRqst 6
Attribute Reply AttrRply 7
DA Advertisement DAAdvert 8
Service Type Request SrvTypeRqst 9
Service Type Reply SrvTypeRply 10
SA Advertisement SAAdvert 11
Table 2.1: SLP messages, their abbreviations and IDs.
a previous responders list (PR-list for short) to let the other agents know who has already
responded to the query. This way the responding agents do not have to keep a list of requests
that they have responded to. An agent that finds its address in the PR-list of any request
shall silently discard the message.
13
Scope Value Name
1 Node local
2 Link local
5 Site local
8 Organisation
E Global
Table 2.2: Different scopes used in IPv6 multicast.
2.8.3 SLP in IPv6 Networks
RFC 3111 [10] defines modifications to the SLPv2 protocol making it suitable for IPv6 de-
ployment. The modifications mostly arise from the way multicast addresses are represented
in IPv6. All multicast addresses in IPv6 are prefixed with ff (that is, the first bits are 1111
1111). Four flag bits and four scope bits follow after the prefix. ff05::111 is an example of
an IPv6 multicast address with a scope value of 5. The scope value defines how far multi-
cast packets are delivered. Restricting the area, where multicast packets travel this way is
easier than using the TTL value. Possible scope values are shown in Table 2.2. Only those
values shown in the table can be used, others are reserved for future use.
When a node wants to receive multicast packets, it joins a multicast group. A multicast
group is a group of hosts communicating through the same multicast address. It should be
noted, that the scope value is part of the multicast address, meaning that a host belonging
to group ff02::111 does not receive packets sent to the address ff05::111.
A new multicast address allocation scheme was taken into use in SLP for IPv6. In contrast
to SLP in IPv4, the new scheme enables the SLP agents to receive only the messages that
they are concerned with. Service requests are sent to multicast addresses based on the
service type of the given request. SAs join only the groups from which they can receive
service requests. The multicast address for a service type is calculated from the service
type string (e.g. "service:printing:ipp") using a hash algorithm defined in RFC 3111. The
service types map to multicast addresses ranging from ff0x::1:1000 to ff0x::1:13ff, which
gives 1024 possible addresses. Agents have to join all multicast groups in scopes lower
than and equal to the scope that the agent has been configured to operate in. This ensures
that agents receive requests and advertisements also from agents that are operating in a
14
lower scope. Each service type is therefore solicited from a different multicast address.
Theoretically there, is an infinite amount of service: URLs that use the same multicast
group, but only a small portion of them will ever be used. The only groups that all the
nodes must join are the directory service group (SVRLOC-DA: ff0x::123) and the service
location group (SVRLOC: ff0x::116), which is used for service type requests.
15
3 Mobility in IP Networks
In this section, some of the background theory concerning mobility in IP networks is pre-
sented. First, issues with wireless IP networking and mobility in wireless IP networks are
discussed, then mobility in general in IPv6 networks is covered, and lastly some issues
regarding service discovery in mobile networks are discussed.
3.1 Wireless Mobility
Mobility is associated easiest with wireless devices. Radio frequencies are used to com-
municate and exchange information between two or more devices. If one of these devices
is attached via a cable to the Internet, it becomes possible for the other devices to connect
to the Internet via this special device (called an access point). Wireless LAN (or WLAN)
technology enables devices to have high speed connections to IP networks without using
a cable to do so. Nowadays Wireless LAN is used extensively in many offices, trains, and
airports to enable users access the Internet with their laptops and PDAs (Personal Digital
Assistant). The IP technology, however, remains the same. The IP address of the host is
(partly) determined by the network to which the host is connected. Similarly, the packets
addressed to a host’s IP address are routed to the network indicated by the network prefix
part of the destination address. If the host wants to change its point of attachment to a new
network, it will have to acquire a new IP address likewise.
Wireless access points can form a coverage area, where a host using WLAN can change
16
the access point it is using, without losing its connectivity to the Internet or changing its IP
address. In that case, all the access points must be connected to the same subnet. As subnets
have a limit on the number of hosts they can have (due to bandwidth limits and address space
allocation), large wireless networks cannot be employed solely by these means.
Another way to change the user’s location is to negotiate a new IP address at the new
point of attachment. Hardly any current application would allow seamless renegotiation of
connections, without the user losing all session information (e.g. if an SSH connection is
lost, all processes belonging to the terminal attached to the SSH session at the server are
terminated).
3.2 Mobile IPv6
The development of a new IP version, IPv6, also lead to a step forward in the world of
mobile IP communications. RFC 3775 [11] defines support for host mobility in IPv6
networks. The standard defines a protocol that allows a terminal (mobile node, or MN)
to remain reachable through its own native IP address (home address) while the MN is
attached to another network (foreign network). The home address is determined by the
node’s initial point of attachment. A home agent (HA) has to be present in the node’s home
network, and the HA is responsible for acting as a negotiator between the MN and the peers
the MN is communicating with.
When the MN is roaming in another subnet, the HA intercepts packets sent to the MN’s
home address and tunnels them to the MN in its current point of attachment (care-of address,
or COA). The MN informs the HA of its movements by sending Binding Updates (BUs),
which inform the HA of the MN’s current COA. The MN also sends BUs to the hosts with
which it is interacting with (correspondent nodes, or CNs), so that they can use the care-
of address instead of the home address to avoid unnecessary tunneling. As the IP layer
itself is not connection aware, it is sometimes difficult to determine to which peers BUs
should be sent. It is easy to determine that BUs must be sent to all TCP connection end
points. UDP protocol is not, on the other hand, connection oriented, and it is much more
difficult to determine whether subsequent communication will take place. Mobile IPv6
specification gives only guidelines on the matter, so different implementations may exhibit
17
differing behaviour. CNs have to be Mobile IPv6 aware also, in order to understand binding
updates. Otherwise communication is performed through the HA to ensure compatibility
with peers that do not employ Mobile IPv6. A simple diagram illustrating the operation of
Mobile IPv6 is shown in Figure 3.1.
Network Z
Network X
HA
MN
CN
Network Y
1. PDU to MN’shome address
3. PDU forwardedthrough the tunnel
2. PDU interceptedby the HA 4. BU packet
to CN
5. PDU to MN’sCOA
Figure 3.1: The principal operation of forwarding packets sent to the MN’s home address to the MN’s care-of
address by the home agent. Subsequent communication would take place directly between the CN and the
MN, without the use of the HA, assuming that also CN was Mobile IPv6 enabled.
Mobile IPv6 was designed as an integral part of the IPv6 protocol itself, whereas Mobile
IPv4 was designed as an add-on between the IP layer (the network layer) and the transport
layer. Use of Mobile IPv4 requires a more complex topology of agents in the network
which relay packets from peer hosts to the MN, while it is away from its home network (the
network to which the MN’s home address belongs).
18
3.3 Issues With Service Discovery
The aspect of host mobility brings extra problems to the process of service discovery. As
the idea of Mobile IPv6 is to provide a transparent mobility service, the application layer is
unaware of the movement. The service discovery mechanism might be fooled into thinking
that nothing special is happening, when the MN moves around in the network. However,
many important aspects of service discovery change when terminal movement is introduced
as an extra factor. First of all, the scopes that define how far a domain of services expands,
can change when a node enters a new network. If a terminal still remains in the old scope
(or scopes), it might not be able to find any services responding to its queries, although
several might be present nearby. For example if service scopes would be divided according
to different floors in an office to avoid mixing services between floors, and one would visit
another floor for a meeting, the user would be unable to find services in the new network,
because of the wrong scope. The service discovery mechanism must be able to detect
movement and employ procedures to resolve the issues arising from the movement.
When the MN provides services to other nodes in the network, it must have knowledge of
its current IP address. As this is hidden by design from the applications and the user by
Mobile IPv6, when the MN is in a foreign network, the service discovery mechanism must
provide a way to accommodate this situation.
Another problem arises from the way multicast is handled in the IPv6-protocol. As most
discovery schemes developed for IP networks utilise multicasting, problems in multicasting
have wide impact. Normally the host sends an ICMPv6 (Internet Control Message Protocol)
packet to the router specifying which multicast groups it wants to receive. This registration
is refreshed at some interval as long as the host wants to receive the multicast packets. The
sender of the multicast stream and all the routers on the path to the receiver knows that
the packets must be forwarded towards the receiver. But when the host moves to another
network, a problem arises. It has not been established, how multicast traffic should reach the
MN in the foreign network. Two possible solutions have been proposed. One specifies that
the MN joins the multicast groups automatically at the foreign network with the multicast
router local to the foreign network, just like it would normally do in its home network. The
other solution is to tunnel the multicast packets from the home network, via the home agent,
19
to the MN. The problem is that the host does not know and has no way to find out which of
these methods is in use.
20
4 Design
This chapter describes a design for new agents to SLP that enable a MN to operate with
existing SLP agents while in a foreign network. The functionality of the new agents will
be similar to the standard SLP agents, but some improvements are added to enable the user
to have extra functionality in addition to the standard SLP operations. To begin with, some
examples are given to highlight the design requirements for the new agents, giving ratio-
nale for the operational additions. Later in this chapter, the designs that implement the new
agents are outlined. The specifications consist mainly of logical composition and function-
ality descriptions of the agents, state machine definitions, and communication procedures
between the agents.
4.1 Design Aims
In this section situations are described where it would be beneficial to have additional func-
tionality to interact with the standard SLPv2 agents. These situations not only justify for
their part the development of new agents, but also introduce some of the features of the
agents specified later in this chapter.
21
4.1.1 Automatic Rediscovery of Services
Automatic rediscovery of services means that the agent software automatically initiates
discovery operation of services when the MN enters a new network. This aims at keeping
the information presented to the user up-to-date with the current network configuration. The
information can be a list of current service types (e.g. "service:printing, service:drivers:ftp,
service:ntp") available at the network, or a list of instances (individual service: URLs) of a
certain service type. This can be useful if the user does not have or does not want to have
knowledge of the details concerning the current point of attachment to the network. The
user may not want explicitly to refresh the list of local services in the network, even if he or
she is interested where the MN is currently connected to. For example, a user connected to
a WLAN and driving a car through a city might constantly be switching into a new foreign
network in the city wide wireless network. The driver might want to have a list of nearby
services visible and up-to-date at all times, in case there is something interesting available.
The computer system in the car itself might also be interested in services that provide,
for example, information on traffic conditions. This way there is no need to initiate new
queries to refresh the user’s information regarding nearby services. Another good example
of such service would be an internet radio, which has several proxies located in several
subnetworks. It would be beneficial to both the user and the provider of the service to have
the user connected to the nearest proxy.
Another possible scenario is a user waiting for a flight at an airport. An airport might have
several subnetworks in which the shops and companies operating at the airport could offer
services online to the visitors. Walking through the airport would allow the user to browse
the services nearby. Other customers at the airport could also offer their services on their
MNs to be used while they remain at the airport.
4.1.2 Providing Services From a Mobile Node
A standard SLPv2 SA takes a service: URL and handles advertising the service to other
peers in the network. The service: URL usually includes a fully-qualified DNS name of the
host where the service is located. For a fixed network service, the service: URL does not
change. If the services remain fairly fixed, it can be assumed that service advertisements
22
and SLP agents remain persistent. This means that the DA can cache registrations and serve
requests without much effort.
With MNs and ad-hoc networks, DNS records cannot be updated flexibly enough to allow
this sort of operation. Furthermore, in IPv6 networks it cannot be assumed that the user
could provide or even know the numerical address of the user’s autoconfigured terminal.
When Mobile IPv6 is used, the user might not even know the COA. Although it would be
easy to build a user interface on top of the standard SLPv2 implementation which would
take care of such details, it would be desirable to have this functionality inside the service
discovery mechanism itself. In many situations, it would be desirable if the user could
define the behaviour of the underlying system, so that automatic address assignment could
be used, or alternatively a DNS name could be provided.
It is impossible to predict when a MN changes to another subnetwork. The MN gets no
warning announcing imminent transition to another network so that cleanup operations
could be performed. Therefore the MN has to be able to act once it has established a
connection in the new network. Once this has taken place, the MN’s SLP agent has to re-
move stale registrations in the previous subnet, and establish new ones in the new subnet.
Leaving stale registrations behind to timeout would be bad behaviour, as it would result in
having incoherent information in the DAs. One solution is to use the home address as the
host address in the service: URL and rely on Mobile IPv6 to inform the CNs of the new
COA. This is not, however, desirable if the MN prefers the CNs to use its COA instead of
its home address (e.g. in some location aware applications).
4.2 New Agents to Extend SLPv2
SLP is already an IPv6 enabled, powerful, and complete service discovery mechanism. For
this reason, it was sensible to take it as the basis for a service discovery scheme suitable
for Mobile IPv6 environments. To make maximum use of the already specified and well
established protocol that SLP is, the decision was to extend it rather than to alter it. This
brings the benefit of compatibility to the existing implementations. The aim is to have a
design, where both normal SLP agents and the new agents can interoperate beneficially.
Standard implementations can still be used in fixed nodes in the network alongside hosts
23
that are using the new agents. This is especially important if some vendors have proprietary
implementations of SLP that cannot be substituted with other implementations (e.g. inside
their operating system libraries).
Two new agents are introduced to solve the problems presented earlier in this thesis. These
agents are used to enable the MN to operate in foreign networks with the SLP agents that
are natively operating in those networks. One agent will be operating in a fixed node in the
foreign network to which the MN will enter to, and one will be operating in the MN itself.
Together these agents will enable the MN to discover and provide services just as if the
MN was a normal, static member of that network. The agent native to the foreign subnet is
called an access agent (AA) and the other agent a visiting agent (VA). The original design
for the AA can be found in [12].
The AA will be a normal member of the fixed network where it is attached to. The purpose
of the AA is to help the VA execute service requests and provide services on its behalf,
even if the VA does not have full multicasting functionality in its use. The AA will function
mainly as a relay for the VA, converting unicast requests to multicast packets and vice versa
for replies. If a DA is present in the network, the AA will also convey the DA’s location to
the VA so that the VA can operate also through the DA. As explained in 3.3, a visiting MN
might not be able to perform multicasting in other than the link-local scope. This might, in
many situations, make discovering the site-local DA impossible for the VA. An illustration
of such a situation is shown in Figure 4.1.
The AA is found by soliciting for AA advertisements via multicast or by receiving a period-
ically sent unsolicited AA advertisement. The solicitation procedure is illustrated in Figure
4.2. AA is solicited for by sending a service request PDU to the multicast group ff02::1:259
(which is calculated using the hash algorithm introduced in the SLPv2 specification) for the
service type "service:access-agent". AA answers to the solicitation by sending an adver-
tisement packet to the same link-local multicast group. As the packet is sent to a link-local
group, it will not create any overhead traffic whatsoever, even if only one VA is receiving
it, as only one packet is needed to reach the whole link, just as with unicast (in contrast to
site-local or greater scope multicast where the packet would be relayed to several subnets
creating unnecessary traffic).
24
DA
AA
AA
AA
VA
.x.y
.z
ff05::123
Figure 4.1: An example network layout where DA is unreachable to VA via link-local multicast.
4.3 Naming Conventions
The DOORS (Distributed Object Operations) framework [13], in which the prototype im-
plementation of the new agents was done, and for which this design was largely based,
has some general conventions and methodology on naming and structuring different com-
ponents in an implementation. The framework will be presented in more detail in section
5.1. A protocol implementation inside the DOORS framework consists of individual tasks
which interact with each other by sending messages. A task consists of several classes, that
together implement the functionality designed for the protocol. Multiple connections in a
protocol are handled by creating individual tasks that are specific to each connection. The
tasks are known as connection tasks. The task responsible for creating connection tasks is
called an entity task. The entity task is also responsible for acting as a central point of con-
nection to the user and to the peer. The user utilises the protocol stack by sending messages
through the protocol’s Service Access Point (SAP).
25
1. 2.
VA AAff02::1:259
Figure 4.2: VA solicits the AA with a multicast request, to which AA responds by sending a multicast adver-
tisement.
4.4 The Access Agent
The design of the AA aims at building an agent that can act on behalf of the VA to the
extent that the VA would not have to know anything about the network it is visiting. This
requires the AA to advertise services on behalf of the VA and also search for services on
behalf of the VA. Therefore the AA must be able to perform the basic functionality present
in the DA, the SA, and the UA.
Another function of the AA is to aid the VA detect when it has moved. A VA can do this by
comparing the addresses of consecutive AA advertisements. AAs send their advertisements
in the link-local scope so that VAs are guaranteed to receive them. It also means that a
VA receiving an AA advertisement is in the same subnet with the AA. If the AA address
changes, the VA can proceed to verify if it has entered into a new network. This requires
that there is only one AA present in the subnet. Figure 4.3 illustrates this method.
4.4.1 Access Agent Advertisement
An AA advertisement is used to advertise the presence of an AA in a subnet. The adver-
tisement takes a form similar to the DA advertisement specified in RFC 2608. Its function
ID has the value 12 to distinguish it from the other messages. The advertisement contains
the service: URL for the AA and optionally the service: URL for a DA, if one is present in
the network. The AA advertisement PDU is shown in Table 4.1.
26
AA 2
AA 1
VA
AA advert: address 2001:708:310:52::19
VA
AA advert: address 2001:708:310:16::123
The VA moves to network 2001:708:310:16
Figure 4.3: When the VA moves to a new network and receives an AA advertisement from a new AA, it can
go on to verify that it has moved to a new network.
The service: URLs are presented as strings in the usual way. If the DA service: URL is
omitted, only a zero byte is encoded in its place to indicate an empty string. Attribute list
and authentication blocks may also be of zero length.
4.4.2 User Agent Proxying
When a VA needs to search for services in a foreign network, it may choose to use the AA as
a negotiator to perform the query on its behalf. The VA sends a service request PDU which
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = AAAdvert = 12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of AA-URL | AA-URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of DA-URL | DA-URL (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <attr-list> | <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Auth Blocks | Authentication block (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 4.1: How the AA Advertisement PDU is composed
27
it has crafted according to the query parameters, as a unicast packet to the AA’s address.
The VA may send several queries consecutively and have them pending at the same time,
each carrying a unique XID value to distinguish the requests from each other. The AA only
forwards requests to the network which carry the AA’s address as the destination address.
This way requests that are received via multicast are not proxied.
Once the AA receives a service request from a VA, the AA behaves in the manner of a
normal UA and sends the query forth as it would be its own request. The AA uses a DA if
one is available. Otherwise, it multicasts the request packet to the scope it was configured
to operate in. Multicast requests are sent as specified in [8], until either no more results are
obtained, the maximum waiting time is reached, or until the PR-list and the request do not
fit into one datagram (the size of the PDU is larger than the MTU of the link). Replies are
forwarded back to the VA as they are received by the AA. There is no message to let the
VA know that no more replies will be coming, or that no replies were received in the first
place.
4.4.3 Service Registration Cache
The other responsibility of the AA is to advertise services available in the VA to the other
hosts in the foreign network. This way the VA does not have to listen to multicast requests
coming in from the network in order to advertise its services to others. The AA does not
forward the registrations sent by the VA to a potential DA, the VA has to do that by itself.
Upon receiving a service registration, the AA first proceeds to verify that the service: URL
is legal by passing it through a parser. Then the service: URL is cross-referenced to the list
of registrations inside the AA. If the registration is not found in the list, it is added there.
Finally, an acknowledgement is sent to the VA with the corresponding XID.
Each registration is associated with a lifetime value. The lifetime value indicates how long
the AA should hold the registration. Every time the registration is refreshed, the lifetime
counter is reset. If the lifetime expires, the registration is removed from the cache.
28
4.4.4 Logical Composition of the Access Agent
The AA has one entity task which handles sending out advertisements to the network, and
acts as a central point of operation. The entity task maintains peer and user side SAP points,
and preprocesses SLP messages coming from the other agents. The entity task also handles
creating connection tasks that take care of service discovery requests received from the
VAs. The entity task checks whether the service request message was sent via unicast to
determine that it was from a VA and meant as a proxy request. The entity task then creates
a connection task to handle the request. The connection task starts the query procedure and
acts as a normal UA would act. A diagram illustrating the design of the AA is shown in
Figure 4.4.
Figure 4.4: A high-level architectural design of the AA.
Service registrations are maintained in a list inside the entity task. When service requests
or service type requests are received, the list is iterated in order to reply to the request.
29
4.5 The Visiting Agent
As explained earlier, VA is a new agent that will operate in the MN. It is a combination
of UA and SA functionality coupled with features to enable seamless operation with other
SLP agents in the network. VA should be able to act as both a UA and a SA in a normal
static node without any problems. VA can therefore be thought of as a sort of a unified
super-agent.
The service discovery functionality of the VA is similar to the standard SLP UA function-
ality. Service requests are either multicast or unicast, depending whether a DA or an AA
is available in the network. If a DA is present in the network, it is preferred above other
methods for discovering services. If no DA is present, an AA (if one is present) is utilised
when searching services. The last method for searching services in a foreign network is to
use link-local multicast. If the VA is in the home network and configuration so permits,
global or site-local multicast will be used instead of the link-local scope. Discovery with
multicast is performed according to the multicast convergence algorithm described in [8].
SA functionality has been extended so that full use of movement detection can be utilised
and details can be omitted from the user. The aim is to allow the user to set the most suitable
policies for a given service and let the VA act accordingly so that the user does not have
to interfere with the functionality. The extended functionality is described in the following
sections.
Services are registered to the VA by sending the VA a message containing a service: URL
and the desired behavioural policies. The service: URL can have a list of attributes as
a comma separated list at the end of the URL string, but attributes can also be added,
removed, or modified later without removing the service: URL in between.
4.5.1 Transient and Persistent Services in a Mobile Node
The MN can offer a varied set of services to other users on the network. For example, it can
have SSH services, printing, file-sharing, and many other, possibly location aware services.
Some of these services can be seen as persistent in the sense that they do not depend on or
30
even care where the VA is currently situated. This is evident when considering e.g. SSH -
it does not really matter whether the connection is established using the COA or the home
address. But when it comes to services like file sharing, location tracking, or even device
services (such as iSCSI disks), it may be crucial to know where the MN is situated. Whether
it is the case of finding the closest peer to download files from, or tracking the location of
the MN, it makes sense to be able to distinguish where the MN is at the moment.
To accomplish this behaviour, the idea of transient (and persistent) services is introduced.
When registering a service to the VA, the user can specify that the VA should always auto-
matically replace the current COA as the host part of the service: URL. This is implemented
by adding an extension to the service: URL grammar. The grammar is extended so that the
service: URL would be illegal for a normal SLPv2 implementation. VA parses the service:
URL, detects that it uses the extension, and then expands the service: URL automatically
to include the COA. This way the property can be embedded inside the service: URL in-
stead of extending the API of the protocol, which would break compatibility with other
implementations.
To define a service: URL as being transient, one defines the IPv6 address of the service
URL: to be “[coa]”. An address enclosed in ’[’ and ’]’ characters would normally be
interpreted as a numerical IPv6 address. As the string “coa” is not a legal numerical IPv6
address, the service: URL parser can substitute it with the current COA.
4.5.2 Automatic Rediscovery of Services
To aid the user to find services without intervention when entering a new network, automatic
rediscovery of services is introduced. This aims to keep the user up-to-date and aware of
the services available in the network. The user can specify a type of service that he wants
to rediscover upon entering a new network or then he can have the service type request exe-
cuted automatically. This requires an extension to the API of the SLPv2 protocol. An extra
boolean flag is added which indicates, whether the user wants to use automatic rediscovery
with the service request.
When a service request or a service type request, with this flag set, is given to the VA,
it first performs the query returning results as normal. After the query finishes, the VA
31
stores the request for later use. When the VA detects that the MN has moved, the request is
reinitiated with the current situation taken into account. Rediscovery should not be initiated
until sufficient time has been used to solicitate for AAs and DAs.
4.5.3 Communicating With Directory and Access Agents
We assume that the VA interacts only at most with one DA and one AA at a time. This
simplifies the functionality of the VA, because dynamic structures to keep track of several
agents are not needed. Also handling timeouts and detecting unreachable DAs and AAs are
simplified greatly. Since there should not be more than one AA in one particular subnet so
that VAs can detect movement from AA advertisements, and there is seldom need for more
than one DA, the assumption is sensible.
In order to find out if any DAs or AAs are present in the network, a solicitation procedure
is performed individually for both agent types. If the VA is in a foreign network, it uses the
link-local multicast groups to solicit for AAs and DAs. The basic idea of AA solicitations
was illustrated earlier in Figure 4.2. Solicitation is performed until a reply is elicited or
until the maximum number of solicitation messages has been sent. DAs are solicited in the
same manner, but using the SVRLOC-DA multicast group. A DA solicitation results in a
unicast reply from all the DAs.
AAs and DAs also send periodic advertisements (which can be recognised from the fact
that the XID value of the message is zero) from which they can be detected. This is needed
to keep track of live AAs and DAs. An AA or a DA that has not sent out an advertisement
for a certain amount of time, is removed from the list of agents and will not be used until it
has been rediscovered.
As stated earlier, DAs are used to gather service information to a single entity, from where
it can be retrieved by anyone using simple unicast transmissions. As the functionality of
DA is not altered in anyway in this design, the rules established in [8] regarding DA usage
apply also to VAs. VAs must register their service: URLs with the DA in the network by
sending an SrvReg PDU to it. The DA will then reply by sending an SrvAck PDU back
to the VA, with the corresponding XID value set. If the SrvReg message does not elicit
response from the DA, the VA will retransmit its registration until a reply is received, or
32
the maximum number of retransmissions have been sent. When the VA wants to remove
the service advertisement, it sends a service deregistration PDU to the DA, and proceeds
again to wait for an acknowledgement, sending retransmissions until a reply is elicited, or
the maximum number of retries has been reached.
A DA should also be used for finding services from the network. A request for service
discovery is done by sending an SrvRqst PDU to the DA using unicast transmission. The
DA will process the request and send a reply to the VA as an SrvRply PDU using also
unicast transmission. The reply contains the service: URLs that satisfy the request, if any
were found. If no satisfying services were found, an empty response is sent to indicate a
negative acknowledgement. The VA will continue to retransmit its query according to the
rules specified in RFC 2608, until a response is elicited or the maximum number of packets
have been sent.
AAs are used by VAs to perform the same services as DAs perform. However, as no other
agents know the existence of AAs, they cannot register services with them. Therefore, AAs
have to use multicast discovery in order to search for services on behalf of VAs. The packets
sent between the VA and the AA are standard SLP packets and the same methods are used
as with DAs.
4.5.4 Logical Composition of the Visiting Agent
The design of the VA implementation is divided into components, that together comprise
the logical and functional composition of the VA. The different components, their respon-
sibilities, and how they interact to form the complete VA are described in the following
sections.
The requirements for the functionality of the VA reflect also into the design. The imple-
mentation, designed in this chapter and described in more detail in the next chapter, consists
of one entity task and three different types of connection tasks. One set of connection tasks
handle individual service requests initiated by the user. The other two, acting together, han-
dle service registrations received from the user, performing necessary registrations with a
DA and an AA, if they are present in the network. The service registration handlers also
answer to service requests received from the network. The entity task connects the other
33
tasks into the network and acts as a general manager in the VA. The entity task also handles
some things needed by all tasks, such as opening network connections, joining the multicast
groups for DA and AA advertisements, and determining the reachability of DAs and AAs.
A principle layout of the VA’s architecture is shown in Figure 4.5.
Connection Task 3
Entity Task
Service Discovery Service Provision
Network Services
Dynamically created handlers
Request Handler 1Request Handler 1
Connection Task 1Service Provider 1
Service Provider 1Connection Task 2
Connection Task 3Connection Task 3
Figure 4.5: A diagram illustrating the high level composition of the VA. Service discovery and service provi-
sion components comprise of dynamic handlers that take care of individual functions.
The tasks consist of state machines, that receive inputs from the other tasks, from the user,
and from the network. The inputs set off activities that produce more inputs to other tasks,
create new tasks, and send data to the network. New tasks are created as consequences of,
for example, service request messages and service registrations.
4.5.5 The Entity Task
The Entity Task is the main point of connection to the upper layer and to the network. All
messages from the user and the network are first processed by the Entity Task, which then
decides what operations should take place in order to respond to the message. The Entity
Task also detects movement of the VA and is responsible for determining whether a DA
34
Entity Task’s States
Alone No AA or DA present
AAPresent AA present, no DA present
DAPresent DA present, no AA present
BothPresent AA and DA present
Table 4.2: States of The VA’s Entity Component
or an AA is available in the network. The Entity Task then forwards this information to
the other tasks in the VA, whenever it is needed by other tasks. For example, movement
notification information is propagated to the other tasks, so that they can handle procedures
with respect to movement. The Entity Task also handles service-type requests. Because
replies to service-type requests should be fitted into one packet, it is the best to handle it in
one task.
The Entity Task’s state machine has four states, which represent the availability of the DA
and the AA. These states are summarised in Table 4.2. The Entity Task also handles com-
munications with regards to finding the agents. When started up, the Entity Task sends
solicitations to the network searching for an AA and a DA. Solicitations are sent until the
agents respond or it can be determined that they are unreachable. Solicitation procedure
is performed individually for both agents, although operation is simultaneous. The time
that the VA spends soliciting the other agents can be set in the configuration. When agents
are found, timers are started, which represent the availability of an agent. When an ad-
vertisement is later received, the timer is reset for the respective agent. No solicitations
are transmitted while the agent is alive. If the timer fires without an advertisement being
received, it is determined that the agent has become unreachable, and the appropriate state
is entered according to the state machine definition. A state machine diagram is illustrated
in Figure 4.6. AAAdvert and DAAdvert inputs represent the advertisements received from
the AA and the DA. Respective timeouts represent the expirations of the advertisements. It
should be noted, that although an AA advertisement may contain a piggy-backed DA ad-
vertisement, for clarity this is not included in the diagram. An actual implementation would
likely skip the AAPresent state and enter the BothPresent state immediately.
The Entity Task sends updates to the other tasks regarding events in the network. Three
35
Alone
AAPresent DAPresent
BothPresent
AAAdvert
DAAdvert
DAAdvert
AAAdvert
DA Timeout
DA TimeoutAA Timeout
AA Timeout
Figure 4.6: The Entity Task’s state machine diagram.
special messages are used to signal the connection tasks about these events. The messages
are listed in the following:
� Movement: VA is in a new network,� DAUpdate: The DA that should be used, has changed,� AAUpdate: The AA that should be used, has changed.
4.5.6 Service Request Connection Task
The job of searching services based on the user’s requests is put upon connection tasks.
These tasks are created dynamically by the Entity Task when a service request message is
received from the user. The connection task then handles sending out PDUs and receiving
and processing replies as well as indicating the user of results. It also terminates the query
process according to the algorithm specified in RFC 2608. Figure 4.7 illustrates a query set
by the user and handled by a connection task, but it does not illustrate the way the PDUs
are sent to the network (or to a DA).
The algorithm used in multicast queries is called multicast convergence algorithm. The
algorithm works in the following way:
1. A PDU containing the request is sent to the network.
2. Replies are received and addresses of the responders are added to the PR-list. A
36
certain time is awaited to receive all replies. The time is extended after each retrans-
mission.
3. If no replies are received and the maximum time to retransmit has been reached, the
algorithm is stopped.
4. Otherwise the algorithm continues from step 1.
The algorithm used to query services from a DA is slightly more straight-forward. The
PDU request is sent by unicast to the DA’s address. If a reply is received, then no more
packets will be sent. If no reply is received, retransmissions are performed until a reply is
received, or a time limit is reached. Retransmissions are made with increasing intervals.
If a DA is available in the network, it is always used for service discovery instead of the
multicast convergence algorithm.
4.5.7 Service Provision Connection Task
The user registers services with the VA by sending service registration messages to the SLP
layer. The entity task receives the registrations from the user SAP and creates connection
tasks to handle the registrations (registration tasks). The role of the registration tasks is
to answer to service requests coming from the network and to handle registering with a
possible DA and AA in the network. The process of registering a service: URL with a
DA or an AA is handled by yet another connection task, named the agent connection task,
which is described in section 4.5.8. The registration procedure has been separated to the
agent connection task to keep the implementation of the registration task simple. Handling
several separate connections with one state machine would make the state machine overly
complicated. Each registration task uses at most two agent connection tasks, one for a DA
and one for an AA. Agent connection tasks are created when a service: URL needs to be
registered in a DA or an AA.
Movement does not cause any actions in the registration task itself. However, movement
notifications are propagated to the agent connection tasks.
The state machine of the registration task is trivial. It consists of one state, namely the
"Ready" state. The state is entered immediately after the task has been created.
37
4.5.8 Agent Connection Task
Agent connection tasks are used to handle service registration procedures with DAs and
AAs. An agent connection task registers a given service: URL to a given agent according to
the procedure described in 4.5.3. The agent connection task also has to be able to unregister
from an agent. Unregistration is performed using the SrvDeReg PDU.
The agent connection task must be able to handle movement events at any point of time.
Especially it must be able to handle situations where movement occurs in the middle of
registration procedure, so that no inconsistent data will remain in the corresponding agents.
Upon receiving a notification of movement, the agent connection task performs unregistra-
tion from the current DA or AA. Upon the discovery of a new agent, registration procedure
is performed. If movement occurs during unregistration procedure, the agent connection
task needs not take any actions.
The state machine of the Agent Connection Task consists of four states. The initial state of
the Agent Connection Task is "Idle". The task waits for an acknowledgement for the regis-
tration in "wfRegAck" state and for an acknowledgement for the unregistration in "wfUnre-
gAck" state. After successful registration, the task will remain in the "RegDone" state. After
successful unregistration, the task returns to the "Idle" state. Figure 4.8 shows an illustra-
tion of the task’s state machine. The state machine is identical in the case of an AA. Only
the DAUpdate message changes to an AAUpdate message. Input definitions are simplified
in the diagram in order to maintain readability.
As can be seen from the state machine diagram, unregistration to the old agent is done be-
fore registration is performed with the new agent. This simplifies the state machine and the
handling of the acknowledgements. It also ensures that the service: URL is only registered
in one AA (and DA) at a time.
38
UA Connection
NetworkUser VA Entity Task
MSC Untitled
Timer
(Timeout)
SRVRQST PDU
(XID, service type, PR list)
Timer
(Timeout)
SRVRQST PDU
(XID, service type)
Service Reply
( SLP Handle,Service URLs)
Service Request
(SLP Handle, service type)
SRVRPLY
(XID, Service URLs)
Service Request
(service type)
(create)
Figure 4.7: Activation diagram showing a service request initiated by the user. Detailed PDU timings and
transmissions have been omitted for clarity.
39
Idle
wfRegAck wfUnregAck
RegDone
Timeout && maxretransmissions reached
SrvAck / Set timeoutclose to service: URL lifetime
DAUpdate
Timeout
Movement or DAUpdate
Movement or DAUpdate
SrvAck && new DA waiting
(SrvAck or (Timeout && maxretransmission reached)) && Nonew DA waiting
Figure 4.8: The state machine of the agent connection task for handling a connection to a DA.
40
5 Implementation
This chapter describes a prototype implementation of the new SLP agents described in
Chapter 4. Only the most important implementation decisions and rationale is introduced.
The first section describes the DOORS framework with which the implementation was done
and which dictated many implementation decisions. The rest of the sections describe the
various parts of the implementation highlighting the important components of the software.
5.1 The DOORS Framework
The DOORS framework [13] is an extensible object-oriented framework for network en-
abled application development. It is not just a set of helper libraries, which can be utilised
to implement interconnectivity, but also a complete application development environment
featuring advanced scheduling, IO-handling, and automatic code generation.
DOORS is mainly focused on distributed systems and features emerging trends in datacom-
munications development. Several readily available protocol implementations have been
included inside DOORS. DOORS is inherently event-driven making it suitable for protocol
and datacommunications development.
DOORS implements events as messages sent between the tasks and the system. Messages
are first saved into a queue from which they are consumed by the task when scheduler
schedules the task. The whole DOORS application runs inside one process rendering it
41
vulnerable to programming errors, but making the system relatively simple and efficient.
The scheduler itself is also a task making it possible to implement a hierarchical structure
of schedulers (with possibly different scheduling policies) inside one application.
A DOORS application consists of the core components of DOORS and a set of tasks im-
plemented by the user. A task in DOORS is a C++-class, which is inherited from one of
the base task classes of DOORS. The most important DOORS base task classes are the
EventTask and the PTask. The EventTask is a basic task which accepts messages from other
tasks and the system itself.
5.1.1 DOORS Scheduling and IO-handling
The scheduler works by calling the execute function of the task in turn with the message
to be consumed as the parameter. The execute function is defined in the EventTask, and is
implemented in the derived classes. The biggest drawback of running the whole application
in one process is that the scheduler cannot limit the execution time of tasks or interrupt a
task when it is executing. If the task locks for some reason or other, the whole application
effectively hangs.
5.1.2 Protocol Implementation with DOORS
DOORS adopts the OSI architecture in protocol design. A protocol is seen as a layer in a
stack, where different protocols relay data across the different layers. A protocol is used
via its Service Access Point (SAP) and the protocol also passes data back via the same
SAP. Only layers next to each other can pass information between them. The protocol layer
abstracts its equivalent correspondent as a peer, although the data is always passed to the
layer below. The peer abstraction allows the protocol instance to pass PDUs through the
interfaces without explicitly encoding and decoding PDUs of the other layers. Figure 5.1
clarifies the OSI layer model.
42
Layer n+1
Layer n
Layer n-1
Layer n+1
Layer n
Layer n-1
Figure 5.1: The OSI layer model.
5.1.3 The XML Code Generators And the Protocol Tool-Box
In addition to a set of ready-to-use protocols, DOORS includes tools to help in protocol
implementation. DOORS includes a package called the Protocol Tool-Box (PTB) and a
set of command-line tools called the XML Code Generators (XCG). The PTB includes
classes that form basis for an implementation of a protocol. Included are classes abstracting
the protocol layer via SAPs for both the provider side and the user side, a base class to
implement a state machine, and a base class to represent the peer abstraction. XCG can be
used to generate compilation ready C++ code from a set of definition files written in XML.
These files describe the protocol behaviour by specifying the state machine, the structure of
the PDU’s and the service access points of the protocol. The user then implements encoding
and decoding functions that complete the peer abstraction, and the functions that are called
from the state machine. An overview of the structure used when implementing a protocol
is shown in Figure 5.2.
The state machine generator (dsmg) does not actually produce a complete state machine.
Nor can the XML language of dsmg be used to describe a full finite state machine. The
dsmg is only used to specify the state and input sets, and the actions (corresponding to the
output) that are taken when a certain input is received in a certain state. However, state
transitions have to be implemented manually inside the function calls initiated by the state
43
<<EventTask>>
PTask
+execute(t:EventType,msg:Message*): bool
StateMachine
+transit(t:EventType,msg:Message*,h:PTask*): bool
<<Iface, Otask>>
Peer
+putMessage(msg:Message*): bool
+getMessage(msg:Message*): bool
Protocol X
<<Iface>>
ReqIface
<<Iface>>
IndIface
Upper layer user sends messages
through IndIface object
ReqIface uses Peer-class to
encode and decode PDUs
PDUs are further passed to lower
layer protocol instances (or the
operating system itself at the
lowest layer)
Every protocol instance
is associated with a state
machine which defines what
methods are executed by the
PTask
Figure 5.2: An illustration of the principle class composition of a protocol implementation in DOORS. Only
the most important classes are shown.
machine code. A state transition is done by altering the value of the state variable in the
PTask class. The state machine output is implemented using a two-dimensional function
pointer table, where the first dimension specifies the state and the second specifies the input.
The value of the table entry points to the function in the task object to be executed. It should
be noted that usually only one state machine object is used at run time although several
instances of the protocol task could be executing in parallel. The state machine object is
usually instantiated by the user of the protocol itself. A reference to the state machine is
then given as a parameter to the constructor of the protocol task class.
5.1.4 Multiple Connection Handling
Usually a protocol is designed so that it is possible to have several simultaneous connections
open to any number of peers. This is called multiple connection handling. In some trivial
protocols, it might be possible to include the behaviour of several connections in one state
44
machine. However, with any non-trivial protocol, it is far too complex to simulate several
simultaneous connections in one state machine. With an arbitrary number of connections,
this is not even possible. Several instances executing the same state machine are required.
This brings up several issues in design and implementation. The DOORS introduces a
notion of connection tasks which are used to handle one connection per task. Connection
tasks are created by the entity task, which serves as a mutual connection point to the lower
and the upper layer. In some contexts, connection tasks are known as data managers and
the entity tasks as connection managers.
In implementation, the entity task contains the SAP of the protocol and connects also to the
lower layer. Connection tasks hold references to the peer and the up ports and use them
instead of relaying everything through the entity task. The entity task is connected to the
connection tasks through a port multiplexer (the PortMux class). The multiplexer has a user
side and a provider side (just like a protocol would have). Messages are sent through the
user side and received at the provider side. The entity task and all the connection tasks are
connected to the multiplexer component through ports. The multiplexer uses an acceptor
function, which is supplied by the entity task, to route messages to correct connection tasks.
The acceptor function could, e.g., check the transaction identifier of the received PDU and
compare it to the connection tasks identifier. The way routing is performed is naturally
dependent on the protocol definition and therefore has to be implemented specifically for
each protocol. It is also possible to create messages that are meant for all the connection
tasks. These messages are set with the multiple targets flag. (The reason for needing special
handling for messages meant for several recipients is that the DOORS subsystem must
know when the message can be deleted, which can only be done after the last task has
processed the message).
5.1.5 The Movement Notification Module
The DOORS framework has a component, which can be used to notify tasks about move-
ment events in the MN. The component has a SAP (MovementSAP) through which a
DOORS task can register itself to receive movement event notifications. The message used
to notify of movement information is called the Movement message. The message contains
the home address and the current COA of the MN. When these addresses are identical, the
45
MN is in its home network.
The DOORS movement notification component uses a library called libmobapi, which
extracts movement information from the Mobile IPv6 module and propagates it to regis-
tered applications. The library is an implementation of [14]. The library implements a call
through which an application can get notifications of MN movement. The function is called
mip_notify_movement. The function can be called either in blocking or non-blocking mode.
When used in non-blocking mode, the caller supplies a callback function which is executed
when a Mobile IPv6 specific event occurs. The movement notifications are translated into
DOORS messages inside the callback function and inserted into the queues of the registered
tasks.
5.2 Service: URL Parser
A crucial part of operation in the SLPv2 protocol is the component which parses the ser-
vice: URLs into parts and also validates the syntax. The syntax for service: URLs is de-
fined in RFC 2609 [9] in Augmented BNF [15]. The BNF syntax definition allows for
quite easy conversion to a grammar description for the yacc parser generator. The tool
used to compile the parser was bison, the GNU equivalent of yacc. The bison program
generates a C-code program which parses the language described by the grammar defini-
tion. The generated program is used by calling a function named yyparse. This function
in turn uses a function named yylex to extract tokens from the data stream which is to
be parsed. yylex returns the next token extracted from the input stream. In this imple-
mentation, yylex was written manually to extract the parts of the service: URL, due to
the simple form of the service: URL. This parser was then embedded into a class named
DOORS_ServiceURL_Parser_Class. As the functions yyparse and yylex are defined in
global scope, there can only be one instance of this parser used at any one time. This
makes it clear that the DOORS_ServiceURL_Parser_Class must be used with only one ser-
vice: URL string at a time. This is not, however, enforced in any way. The user of the
convenience class is responsible for serialising the calls. First, the string to be parsed is set
via setURL method and after that parseURL method is called, which will result in parsing
the given string.
46
The service: URL is stored inside a ServiceURL object. The parts of the service:
URL are stored in member variables for easy access. The parser is invoked from the
constructor of the ServiceURL. Inside the body of the yyparse function, the members
of the DOORS_ServiceURL_Parser_Class are populated with the corresponding values
while parsing the service: URL string. These values are extracted through methods in
DOORS_ServiceURL_Parser_Class’s interface. In addition to storing the various parts of
the service: URL, ServiceURL also has methods for copying, and comparing service: URLs
and service-types. This makes handling service: URLs easy.
5.3 The Access Agent
The AA designed in 4.4.4 is implemented as a DOORS component. The AA implementa-
tion consists of an AAEntity class, which implements the entity task functionality, and of
a UAProxy class, which is used to create objects to act as connection tasks. The AAEntity
class is associated with a state machine class named AAEntitySM, and the UAProxy objects
are associated with a state machine class named UAProxySM. The class composition of the
AA is shown in Figure 5.3.
The entity task is connected to the connection tasks through a port multiplexer. The port
multiplexer links messages to connection tasks based on the XID values that the message
and the connection task has.
5.3.1 User Agent Proxy
The UAProxy task is used as a connection task to handle proxy service requests received
from a VA. It is created when a unicast service request is received from a VA. It is easy
to determine that a request came from a VA, because only VAs will send unicast requests
to AAs. The normal procedure of searching for a service is then performed, following the
steps described earlier in this thesis.
47
<<PTask>>
AAEntity
-uaproxyMux: PortMux
-Services: std::vector<ServiceURL>
<<StateMachine>>
AAEntitySM
<<StateMachine>>
UAProxySM<<PTask>>
UAProxy
*
1
1 *
1 *
Figure 5.3: The class composition of the AA.
The state machine definition for the UAProxySM class is shown below:
<SM Name="UAProxySM" PTask="UAProxy" CIncludeFiles="uaproxy.h">
<Peer-File Name="slppdu.pdu"/> <From SLPPeer="peer"/>
<State Name="Ready" Default="ready_default">
<Interface Name="peer">
<Input Name="SRVRQST">ready_srvRqst</Input>
</Interface>
</State>
<State Name="wfSrvRply" Default="wfSrvRply_default">
<Interface Name="peer">
<Input Name="SRVRPLY">wfSrvRply_srvRply</Input>
</Interface>
<Timer>wfSrvRply_timeout</Timer>
</State>
<State Name="wfSrvTypeRply" Default="wfSrvRply_default">
<Interface Name="peer">
<Input Name="SRVRPLY">wfSrvTypeRply_srvTypeRply</Input>
</Interface>
<Timer>wfSrvTypeRply_timeout</Timer>
</State>
</SM>
48
5.3.2 Service Caching
The other main functionality of the AA is to cache VA’s services and send replies when
someone queries for those services. The services are stored in a simple vector container
which is iterated through when a request is received. The vector structure allows for search
performance of order O(n), which is not suitable for very large amounts of registrations.
On the other hand, addition to a vector can be done in O(1) time. The ease of using a vector
container justifies the use of it as the container for service registrations. As the amount of
services offered by the VAs in any subnet is likely to be small, the use of more advanced
data structures, such as a red-black binary tree, is not necessary.
This implementation does fail to take into account the lifetime of registered service: URLs.
It would be easy to add a time stamp to the URL registration, but it has been left out in this
prototype implementation. However, it is not a big handicap as deregistration messages are
implemented and used by the VA.
5.4 The Visiting Agent
As described in section 4.5.4, the VA is comprised of several tasks that interact with each
other. The entity task described in section 4.5.5 is implemented in the VAEntity class. The
service request handler is implemented in the VUAConn class and the ServiceReg class can
be used to handle registrations. Agent connection handling is implemented in the Agent-
Connection class. The classes implement respective tasks. Each of the tasks is associated
with a state machine. The state machine classes are: VAEntitySM, VUAConnSM, and Ser-
viceRegSM. A simple diagram illustrating the composition of VA is shown in Figure 5.4.
The VAEntity task is created when the application is started. The main() function also
creates an instance of the DOORS UDP helper task, the Udp6Task. The Udp6Task opens
a socket through which UDP packets are sent and received. The Udp6Task is also used to
join to multicast groups. The VAEntity task creates new connection tasks during runtime
as needed. The state machine classes for all the tasks are instantiated into objects in the
beginning of execution. A reference to the respective state machine object is passed to
created connection task objects.
49
Network Services
PortMuxPortMux
<<PTask>>
ServiceReg<<PTask>>
VUAConn
<<PTask>>
VAEntity
<<PTask>>
AgentConnection
<<SAP>>
MobilitySAP
Figure 5.4: The VA’s implementation shown in principle. Details are omitted for clarity.
As mentioned in 4.5.5, the VAEntity object also accepts one SLPv2 packet type, the service-
type request. The VAEntity task maintains a list of pointers to all the ServiceReg tasks. This
list is iterated when the VAEntity task receives a service-type request from the network. The
VAEntity task formulates a reply based on the list of ServiceReg task, checking that there
are no duplicate types in the reply. It should be noted, that a reply can only hold as many
service-types that can be fitted into a PDU of size smaller than the Maximum Transmission
Unit (MTU). However, the MTU size is usually quite large, allowing at least for 50-100
service-types to be included in one packet. It is unlikely to have more unique service-types
in one VA. (A MTU of size 1400, where SLPv2 header of 24 bytes is included, would allow
for 65 service-type strings length of 20 bytes each to be included along with separating
commas.)
5.4.1 VAEntity Task Implementation
The VAEntity task forms the bulk of the VA implementation. The VAEntity task receives
all incoming messages and forwards them to the connection tasks, creating new connec-
tion tasks when needed. The VAEntity task also registers to the MovementSAP to receive
movement notifications. These movement notifications are also forwarded to the connec-
50
tion tasks. As explained in 4.4, movement can also be detected from the AA advertisements.
In case the MovementSAP is not available, the VAEntity is responsible for checking the AA
advertisements to detect movement. If it detects movement, the VAEntity task creates a
movement message by itself and sends it to the connection tasks.
Connection tasks are connected to the VAEntity task via two port multiplexers. One multi-
plexer is used to connect VUAConn tasks and the other to connect ServiceReg tasks to the
VAEntity task. Both these multiplexers have corresponding acceptor functions, which are
used to route the messages to correct connection tasks.
Configuration information for the VA is retrieved via a VAConfigurator object. The VA-
Configurator class is implemented according to the singleton pattern. The object reads the
configuration file and parses it accordingly. The configuration parameters can then be read
through the public variables in the VAConfigurator object. The VAEntity task holds a pointer
to the VAConfigurator object and retrieves configuration parameters during initialisation of
the VAEntity task.
The VAEntity task is also responsible for handling the lifetime of the AgentConnection
tasks. The ServiceReg tasks can request for new AgentConnection tasks from the VAEntity,
which creates them as necessary. Upon deregistration of service: URLs and the termination
of ServiceReg objects, AgentConnection tasks are not deleted, but inserted into a pool of
free AgentConnection tasks.
The state machine specified in 4.5.5 was implemented using the dsmg tool. The state ma-
chine can receive messages from several entities, namely the user SAP, the peer entity, and
the MobilitySAP. These all are included inside the VAEntity task as individual ports. The
XML specification is included in Appendix A.
5.4.2 VUAConn Task Implementation
The role of VUAConn tasks was outlined in 4.5.6. The class that implements the connec-
tion task is the VUAConn class coupled with the state machine class VUAConnSM. The
VUAConnSM was implemented using the dsmg tool. The XML specification is included in
Appendix A.
51
To keep the implementation fairly simple, once a request has been initiated the mode of
operation will not change during the discovery process. This means that if an AA or a
DA becomes available during the multicast convergence algorithm, the query will not be
moved to unicast. The same is also the case, if the MN moves to another network during
the query process. In that case, the validity of received results is compromised. However,
these situations are not common.
As connection tasks are freed after requests have timed out, they are pooled for later use.
When the user initiates new requests, the pool is first searched for free connection tasks,
and only if no free tasks are available, a new one is instantiated. This aims at better per-
formance by minimising the need of allocating memory every time requests are sent by the
user and freeing resources when the requests terminate. The long hierarchy of inheritance
(OTask->ETask->PTask->VUAConn) in the VUAConn class makes allocating and freeing
it quite expensive.
5.4.3 SAReg Task Implementation
The second connection task in the VA is the ServiceReg task. The service: URLs registered
by the user are stored in ServiceReg tasks. The functionality of the ServiceReg task was
described in section 4.5.7.
The ServiceReg task holds two ports which connect to AgentConnection tasks. One port is
for an AgentConnection task handling a DA and one is for the task handling an AA. If either
agent is absent, the respective port remains unused until such time that the agent is discov-
ered. As was mentioned earlier, the ServiceReg task requests for new AgentConnection
tasks from the VAEntity task when there it needs one.
The ServiceReg task does not by itself initiate any messages to the AgentConnection tasks.
Messages coming from the VAEntity task are forwarded to the connection tasks, if neces-
sary. As the AgentConnection tasks are concerned with sending registrations to the AAs
and DAs, they do not need to know about service requests. The messages forwarded to the
connection tasks are: DAUpdate, AAUpdate, and Movement. The DAUpdate message is
sent only to the connection task handling the DA, and the AAUpdate message is sent to the
other AgentConnection task. Movement messages are relayed to both connection tasks.
52
5.4.4 AgentConnection Task Implementation
The AgentConnection task is implemented in the AgentConnection class. The job of this
task is to keep the registration associated with the ServiceReg task alive in the AA or DA. A
registration-acknowledgement type procedure is performed each time the registration needs
to be refreshed. The expiration time is set by the user in the registration. The implementa-
tion will calculate a suitable reregistration interval so that in case of network failures, there
is some time to proceed with retransmissions without the registration being invalidated in
the agent.
The state machine described in section 4.5.8 was implemented using the dsmg tool. The
XML specification is included in Appendix A.
The functionality of the AgentConnection task is independent of the type of agent it is com-
municating with. A boolean flag inside the AgentConnection task indicates which agent it
is communicating with. The flag is used only for error detection to ensure that AgentCon-
nection task handling a DA is not mixed with the one handling an AA.
If a new agent is assigned to an AgentConnection task while it is unregistering from an old
agent, the new address is stored inside the AgentConnection task in the nextAgent variable.
The registration procedure with the new agent is started once the unregistration procedure
with the old agent is finished.
53
6 Results
In this chapter some results obtained from tests performed with the new SLP agents are
presented. Comprehensive testing and formal verification of the software is out of the scope
of this thesis, but some indication is given of the functionality of the agents. Interoperability
with other implementations could not be tested as other implementations of SLPv2 for IPv6
do not exist at the moment (or at least are not publicly available). Although performance
issues are out of the scope of this thesis, the results presented in this chapter do give some
indication of performance factors.
6.1 Limitations
Three machines were dedicated to these tests, one acting as a MN, one as a DA, and one
as an AA. Due to the fact, that IPv6 implementations are far from complete in all operating
systems, and only one has support for movement notifications, Linux with kernel 2.4.22
with MIPL 1.0 was used on all machines. During tests, it was also noted that only this par-
ticular Linux kernel supported IPv6 multicasting reliably with all scopes. Some problems
with multicasting were also found in other operating systems, but these problems are not
presented in this thesis.
Results were only taken from the MN’s point of view. The biggest delay in MN handover is
the time taken to receive a router advertisement in the new network. This time depends on
the router advertisement interval, which can be altered to make transitions smoother. The
54
router advertisement interval was not, however, altered in these tests, as the focus of the
tests was to verify correct interaction between the agents.
6.2 Test Network
The system was tested in production networks at the Institute of Communications Engineer-
ing at Tampere University of Technology. The networks host a number of other computers
and a normal amount of varied traffic is present. The subnet 2001:708:310:52 was used as
the home network, because it had a computer functioning as a Mobile IPv6 HA connected
to it. All the subnets used have IPv6 with stateless autoconfiguration enabled and multi-
casting working in them. Figure 6.1 shows the principal layout of the networks used in
testing.
2001:708:310:52/64 (home network)
2001:708:310:708/64
DA
AA
2001:708:310:16/64
Figure 6.1: Layout of the environment used to test the components.
6.3 Mobile Node Setup
As stated above, the MN was installed with Debian Linux distribution with Linux kernel
2.4.22. The kernel was patched with the MIPL patch version 1.0 and the mobility API
patch to allow movement notifications from the IP layer to upper layer applications. The
mobile terminal had one PC Ethernet card, through which IP connections were established.
55
Ethereal network analyser software [16] was used to listen to the traffic in the network.
Movement was simulated by physically moving the Ethernet cable of the MN’s fixed con-
nection from one Ethernet hub to another. In all cases the VA running in the MN was using
the MovementSAP to obtain the new COA in foreign networks.
6.4 Service Provision In Visiting Agent
Service provision was tested using one registered service in the VA. The test network was
set up as already shown in Figure 6.1. The VA was given a service (service:foo:bar//[coa])
which was registered with the DA. Then the VA moved to the foreign network, where it
found an AA. After unregistering with the DA, it registered the service: URL with the AA.
After moving back to the home network, successful unregistration and reregistration was
again performed. A message sequence chart in Figure 6.2 shows the messages sent during
this test. Some messages have been omitted to save space and to keep the figure readable.
The message sequence chart does not contain time information and the spacing between
messages are not in any way related to actual timings. Figures with accurate timings and all
messages sent during the test can be found in Appendix B. The listings in Appendix B show
a few PDUs that were sent but which should not have been transmitted according to the
design of the VA. This is not a major flaw in the implementation as the basic functionality
was anyway fulfilled.
6.5 Service Discovery In Visiting Agent
The same network was used to test service discovery in an MN running a VA. The VA was
given a service request for "service:foo:bar". The service request was set to be automatically
rediscovered after movement. The VA sent the request to the DA which replied with an
empty SrvRply PDU. When the MN moved to the 2001:708:310:708/64 network, the VA
first discovered the AA in the network and then sent the SrvRqst packet to it. The AA started
the multicast query procedure sending the SrvRqst to the network. Because no results were
received, no reply packets were sent to VA and the service request in both agents timed
out. When moving to the 2001:708:310:16/64 network, the multicast query procedure was
56
performed for AA discovery. Because of the absence of other SLP agents, no results were
obtained. The VA remained in the "Alone" state and performed link-local multicast service
discovery.
6.6 Findings
During implementation and testing, some enhancement possibilities were discovered. The
signalling performed between the VA and the AA need not be performed with standard SLP
PDUs. Instead of acting as a simple proxy, the AA could provide some extra services to the
VA. The VA could notify the AA that it has entered the subnet, and the AA could inform the
VA of the multicasting capabilities of the network. Proxy service discovery requests could
include some additional parameters such as the maximum time to be used in the multicast
convergence algorithm. The VA might also want to be notified of any SAs entering the
network, as the VA might not receive the SA advertisements itself. The VA could also use
the AA to test whether the VA’s site-local or higher scope multicasting is working by asking
the AA to transmit test packets on the requested scope.
One interesting aspect in combining SLP, IPv6, and Mobile IPv6 was to study how multicas-
ting works when all these technologies are combined. There is no accurate documentation
to explain how this should be implemented or should it even work. An application normally
binds a socket to the well-known IPv6 address of the host. If the MN uses its home address
to bind the socket, the Mobile IPv6 stack will tunnel all link-local multicast traffic to the
HA. However, multicast packets from the home network are not forwarded by the HA to
the MN. On the other hand, the MN receives link-local multicast packets from the foreign
network. This is not the desirable behaviour for SLP and does not conform to the scoping
rule for service discovery. If the VA uses the special IPv6 address in6addr_any (defined
in [17]) to bind the socket, the kernel chooses the best outgoing IPv6 address by itself. In
the foreign network, the COA is used instead of the home address. This way link-local
multicast packets from the MN are not tunneled to its home network.
57
ff02::123ff02::1:259
Directory AgentVisiting AgentAccess Agent
VA starts in.52 network
DA is in .52 network
AA is in .54 network
MSC
Access AgentAdvertisemet
(explicit multicast reply to request )
Service Reply
(unicast)
Service Request
(service:directory−agent)
Service Request
(service:directory−agent)
Service Acknowledgement
Service Registration
(service:foo:bar)
Service Registration
(service:foo:bar)
Service Request
(service:directory−agent)
Access AgentAdvertisement
(Periodicadversisement)
Service Request
(service:access−agent)
Service Acknowledgement
Service Request
(service:directory−agent)
Service Acknowledgement
Service Deregister
Movement Notification
( VA moves toforeign network)
User registersservice:foo:bar
Figure 6.2: A message sequence chart showing the principle messages sent when testing service provision in
the VA.
58
7 Conclusions
This thesis studied how service discovery could be implemented in the context of Mobile
IPv6 technology. It showed that combining mobility with service discovery is possible by
extending the functionality of SLP. This thesis also demonstrated that existing technologies
can successfully be combined to form a practical solution. The service discovery mecha-
nism was able to use either Mobile IPv6 level or application level movement detection.
The design for the extensions to SLP was feasible and it enabled a mobile node to dis-
cover and provide services while moving across networks. The prototype implementation
was successfully constructed according to the design. It was also shown that the DOORS
framework could provide the tools needed to implement a Mobile IPv6 aware application
that took advantage of movement information obtained from the Mobile IPv6 layer.
The design for the agents was simple yet effective and allows for extending and tuning the
functionality further. The design itself does not set any limitations for further development.
Two enhancement features which utilised movement information were designed to help the
user automate service discovery and provision. The enhanced functionality designed was
effective and no interoperability issues were found while using them with standard SLPv2
agents.
The state of IPv6 and Mobile IPv6 implementations in different operating systems was
found to be varying. Only one operating system was found to provide all the necessary
functionality to implement the components. IPv6 was supported in all examined platforms
but only Linux supported Mobile IPv6 together with an implementation of a movement
59
notification API. In the future more platforms will certainly provide the features that the
extensions require.
Further work will be conducted to extend the functionality of the components. Some de-
velopment ideas presented in this thesis will be implemented later on. More testing and
performance evaluation is needed to ascertain that all the ideas are feasible and beneficial
in practice.
60
References
[1] The Salutation Consortium, "Where the Action Is", A Salutation scenario,http://www.salutation.org/scenario/scenario8.htm, URL referenced 31.8.2004.
[2] The Salutation Consortium, "The Salutation Architecture",http://www.salutation.org/, URL referenced 31.8.2004.
[3] Apple Computer, Inc., "Rendezvous", http://developer.apple.com/macosx/rendezvous/,URL referenced 31.8.2004.
[4] Zeroconf Working Group, "Requirements for Automatic Configuration ofIP Hosts", Internet-Draft draft-ietf-zeroconf-reqts, work in progress,http://files.zeroconf.org/draft-ietf-zeroconf-reqts-12.txt, URL referenced 31.8.2004.
[5] Zero Configuration Networking Group and DNS Extensions Networking Group,"Multicast DNS", Internet-Draft draft-cheshire-dnsext-multicastdns, work inprogress, http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt, URLreferenced 31.8.2004.
[6] The UPnP Forum, "Universal Plug’n’Play", http://www.upnp.org, URL referenced31.8.2004.
[7] Yaron Y. Goland, et al., "Simple Service Discovery Protocol",Internet-Draft dfart-cai-ssdp-v1, work in progress, October 1999,http://www.upnp.org/download/draft_cai_ssdp_v1_03.txt, URL referenced31.8.2004.
[8] Service Location Protocol Working Group, "Service Location Protocol, Version 2",RFC 2608, June 1999.
[9] Service Location Protocol Working Group, "Service Templates and service:Schemes", RFC 2609, June 1999.
[10] Service Location Protocol Working Group, "Service Location Protocol Modifica-tions for IPv6", RFC 3111, May 2001.
[11] IETF Network Working Group, "Mobility Support in IPv6", RFC 3775, June 2004.
[12] Bilhanan Silverajan, Jaakko Kalliosalo, Jarmo Harju, "A Service Discovery Modelfor Wireless and Mobile Terminals in IPv6", Proceedings of IFIP-TC6 8th Interna-tional Conference on Personal Wireless Communications PWC 2003, ISBN 3-540-20123-8.
[13] B. Silverajan, I. Karvinen, J. Makihonka, J. Harju, "The Design of a Flexibly Inter-working Distributed Messsage-Based Framework", Proceedings of EUNICE 2000Summerschool, Enschede, The Netherlands, September 2000.
61
[14] Alper E. Yegin, Muhammad M. Tariq, Aki Yokote, Mobile IP API,http://www.mwborst.com/mobapi/draft-yokote-mobileip-api-02.txt, URL refer-enced 31.8.2004.
[15] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF",RFC 2234, November 1997.
[16] Ethereal Network Protocol Analyzer, http://www.ethereal.com/, URL referenced31.8.2004.
[17] Network Working Group, "Basic Socket Interface Extensions for IPv6", RFC 2133,April 1997.
62
Appendix A: XML State MachineDefinitions
<SM Name="AgentConnSM" PTask="AgentConn"HIncludeFiles="agentconn.h,doors/slppdu.h">
<SAP-File Name="vasap.sap"/><Peer-File Name="slppdu.pdu"/>
<From SLPPeer="peer"/> <From ServiceRegSAP="servicereg"/><From MobilitySAP="mobapi"/>
<State Name="Idle" Default="idle_default">
<Interface Name="servicereg"><Input Name="AAUpdate">idle_agentupdate</Input><Input Name="DAUpdate">idle_agentupdate</Input><Input Name="Release">idle_release</Input>
</Interface></State>
<State Name="wfRegAck" Default="wfregack_default">
<Interface Name="mobapi"><Input Name="Movement">wfregack_movement</Input>
</Interface>
<Interface Name="servicereg"><Input Name="AAUpdate">wfregack_agentupdate</Input><Input Name="DAUpdate">wfregack_agentupdate</Input><Input Name="Release">wfregack_release</Input>
</Interface>
<Interface Name="peer">
63
<Input Name="SRVACK">wfregack_srvack</Input></Interface>
<Timer>wfack_timeout</Timer>
</State>
<State Name="RegDone" Default="regdone_default">
<Interface Name="mobapi"><Input Name="Movement">regdone_movement</Input>
</Interface>
<Interface Name="servicereg"><Input Name="AAUpdate">regdone_agentupdate</Input><Input Name="DAUpdate">regdone_agentupdate</Input><Input Name="Release">regdone_release</Input>
</Interface>
<Timer>regdone_timeout</Timer>
</State>
<State Name="wfUnregAck" Default="wfunregack_default">
<Interface Name="mobapi"><Input Name="Movement">wfunregack_movement</Input>
</Interface>
<Interface Name="servicereg"><Input Name="AAUpdate">wfunregack_agentupdate</Input><Input Name="DAUpdate">wfunregack_agentupdate</Input><Input Name="Release">wfunregack_release</Input>
</Interface>
<Interface Name="peer"><Input Name="SRVACK">wfunregack_srvack</Input>
</Interface>
<Timer>wfack_timeout</Timer>
</State>
</SM>
<SM Name="ServiceRegSM" PTask="ServiceReg"HIncludeFiles="servicereg.h,doors/slppdu.h">
<SAP-File Name="vasap.sap"/><Peer-File Name="slppdu.pdu"/>
64
<From SLPPeer="peer"/> <From VASAP="up"/><From MobilitySAP="mobapi"/> <From ServiceRegSAP="entity"/>
<State Name="Ready" Default="ready_default">
<Interface Name="up"><Input Name="addAttributes">ready_addattributes</Input><Input Name="deleteAttributes">ready_deleteattributes</Input><Input Name="registerService">ready_registerservice</Input><Input Name="deregisterService">ready_deregisterservice</Input>
</Interface>
<Interface Name="entity"><Input Name="AAUpdate">ready_aaupdate</Input><Input Name="DAUpdate">ready_daupdate</Input>
</Interface>
<Interface Name="peer"><Input Name="SRVRQST">ready_srvrqst</Input><Input Name="SRVACK">ready_srvack</Input><Input Name="ATTRRQST">ready_attrrqst</Input>
</Interface>
<Interface Name="mobapi"><Input Name="Movement">ready_movement</Input>
</Interface>
</State>
</SM>
<SM Name="VAEntitySM" PTask="VAEntity"CIncludeFiles="vaent.h,doors/slptypes.h">
<SAP-File Name="vasap.sap"/><Peer-File Name="slppdu.pdu"/>
<From SLPPeer="peer"/><From VASAP="up"/><From MobilitySAP="mobapi"/>
<State Name="AAPresent" Default="aapresent_default">
<Interface Name="up"><Input Name="SLPOpen">allstates_SLPOpen</Input><Input Name="Srv_req">allstates_Srv_req</Input><Input Name="Srvtype_req">allstates_Srvtype_req</Input><Input Name="Attr_req">allstates_Attr_req</Input>
65
<Input Name="registerService">allstates_registerService</Input><Input Name="deregisterService">allstates_deregisterService</Input><Input Name="addAttributes">allstates_addAttributes</Input><Input Name="deleteAttributes">allstates_deleteAttributes</Input>
</Interface>
<Interface Name="peer"><Input Name="AAADVERT">aapresent_aaadvert</Input><Input Name="DAADVERT">aapresent_daadvert</Input><Input Name="SRVRPLY">allstates_SrvRply</Input><Input Name="SRVACK">allstates_srvack</Input><Input Name="ATTRRPLY">allstates_AttrRply</Input><Input Name="SRVTYPERPLY">allstates_SrvtypeRply</Input><Input Name="ATTRRQST">allstates_PeerRqst</Input><Input Name="SRVTYPERPLY">allstates_PeerRqst</Input><Input Name="SRVTYPERQST">allstates_SrvtypeRqst</Input>
</Interface>
<Interface Name="mobapi"><Input Name="Movement">aapresent_movement</Input>
</Interface>
<Timer>aapresent_timeout</Timer>
</State>
<State Name="DAPresent" Default="dapresent_default"><Interface Name="up">
<Input Name="SLPOpen">allstates_SLPOpen</Input><Input Name="Srv_req">allstates_Srv_req</Input><Input Name="Srvtype_req">allstates_Srvtype_req</Input><Input Name="Attr_req">allstates_Attr_req</Input>
<Input Name="registerService">allstates_registerService</Input><Input Name="deregisterService">allstates_deregisterService</Input><Input Name="addAttributes">allstates_addAttributes</Input><Input Name="deleteAttributes">allstates_deleteAttributes</Input>
</Interface>
<Interface Name="peer"><Input Name="AAADVERT">dapresent_aaadvert</Input><Input Name="DAADVERT">dapresent_daadvert</Input><Input Name="SRVRPLY">allstates_SrvRply</Input><Input Name="SRVACK">allstates_srvack</Input><Input Name="ATTRRPLY">allstates_AttrRply</Input><Input Name="SRVTYPERPLY">allstates_SrvtypeRply</Input><Input Name="ATTRRQST">allstates_PeerRqst</Input><Input Name="SRVTYPERPLY">allstates_PeerRqst</Input><Input Name="SRVTYPERQST">allstates_SrvtypeRqst</Input>
</Interface>
<Interface Name="mobapi">
66
<Input Name="Movement">dapresent_movement</Input></Interface>
<Timer>dapresent_timeout</Timer>
</State>
<State Name="BothPresent" Default="bothpresent_default"><Interface Name="up">
<Input Name="SLPOpen">allstates_SLPOpen</Input><Input Name="Srv_req">allstates_Srv_req</Input><Input Name="Srvtype_req">allstates_Srvtype_req</Input><Input Name="Attr_req">allstates_Attr_req</Input>
<Input Name="registerService">allstates_registerService</Input><Input Name="deregisterService">allstates_deregisterService</Input><Input Name="addAttributes">allstates_addAttributes</Input><Input Name="deleteAttributes">allstates_deleteAttributes</Input>
</Interface>
<Interface Name="peer"><Input Name="AAADVERT">bothpresent_aaadvert</Input><Input Name="DAADVERT">bothpresent_daadvert</Input><Input Name="SRVRPLY">allstates_SrvRply</Input><Input Name="SRVACK">allstates_srvack</Input><Input Name="ATTRRPLY">allstates_AttrRply</Input><Input Name="SRVTYPERPLY">allstates_SrvtypeRply</Input><Input Name="ATTRRQST">allstates_PeerRqst</Input><Input Name="SRVTYPERPLY">allstates_PeerRqst</Input><Input Name="SRVTYPERQST">allstates_SrvtypeRqst</Input>
</Interface>
<Interface Name="mobapi"><Input Name="Movement">bothpresent_movement</Input>
</Interface>
<Timer>bothpresent_timeout</Timer>
</State>
<State Name="Alone" Default="alone_default"><Interface Name="up">
<Input Name="SLPOpen">allstates_SLPOpen</Input><Input Name="Srv_req">allstates_Srv_req</Input><Input Name="Srvtype_req">allstates_Srvtype_req</Input><Input Name="Attr_req">allstates_Attr_req</Input>
<Input Name="registerService">allstates_registerService</Input><Input Name="deregisterService">allstates_deregisterService</Input><Input Name="addAttributes">allstates_addAttributes</Input><Input Name="deleteAttributes">allstates_deleteAttributes</Input>
</Interface>
67
<Interface Name="peer"><Input Name="AAADVERT">alone_aaadvert</Input><Input Name="DAADVERT">alone_daadvert</Input><Input Name="SRVRPLY">allstates_SrvRply</Input><Input Name="SRVRQST">allstates_PeerRqst</Input><Input Name="ATTRRPLY">allstates_AttrRply</Input><Input Name="ATTRRQST">allstates_PeerRqst</Input><Input Name="SRVTYPERPLY">allstates_SrvtypeRply</Input><Input Name="SRVTYPERQST">allstates_SrvtypeRqst</Input><Input Name="SRVACK">allstates_srvack</Input>
</Interface>
<Interface Name="mobapi"><Input Name="Movement">alone_movement</Input>
</Interface>
<Timer>alone_timeout</Timer>
</State>
</SM>
<SM Name="VUAConnSM" PTask="VUAConn" CIncludeFiles="vuaconn.h">
<SAP-File Name="vasap.sap"/><Peer-File Name="slppdu.pdu"/>
<From VASAP="up"/> <From SLPPeer="peer"/><From MobilitySAP="mobapi"/>
<State Name="Idle" Default="idle_Default"><Interface Name="up">
<Input Name="Srv_req">idle_Srv_req</Input><Input Name="Srvtype_req">idle_Srvtype_req</Input><Input Name="Attr_req">idle_Attr_req</Input>
</Interface><Interface Name="mobapi">
<Input Name="Movement">idle_movement</Input></Interface>
</State>
<State Name="mcWaitReply" Default="mcWaitReply_Default"><Interface Name="peer">
<Input Name="SRVRPLY">mcWaitReply_SrvRply</Input><Input Name="SRVTYPERPLY">mcWaitReply_SrvtypeRply</Input><Input Name="ATTRRPLY">mcWaitReply_AttrRply</Input>
</Interface><Interface Name="mobapi">
<Input Name="Movement">mcWaitReply_movement</Input>
68
</Interface>
<Timer>mcWaitReply_Timeout</Timer></State>
<State Name="agentWaitReply" Default="agentWaitReply_Default"><Interface Name="peer">
<Input Name="SRVRPLY">agentWaitReply_SrvRply</Input><Input Name="SRVTYPERPLY">agentWaitReply_SrvtypeRply</Input><Input Name="ATTRRPLY">agentWaitReply_AttrRply</Input>
</Interface><Interface Name="mobapi">
<Input Name="Movement">agentWaitReply_movement</Input></Interface>
<Timer>agentWaitReply_Timeout</Timer></State>
<State Name="AutoRestartWait" Default="autoRestartWait_Default"><Timer>autoRestartWait_Timeout</Timer>
</State>
</SM>
69
Appendix B: Screenshots from EtherealNetwork Protocol Analyzer
70
