XML does matter for next generation of "Plug &, Play" Electronic Commerce		Table of contents		Indexes		Managing the Intellectual Property Lifecycle

XML-based Agent Communication: VPN Provisioning as a Case Study

Bart Bauwens

Research Engineer

Alcatel Corporate Research Center Francis Wellisplein 1
Antwerp Belgium 2018
Phone: +32 3 2408427
Fax: +32 3 2408485
Email: Bart.Bauwens@alcatel.be Web: www.alcatel.com

Biographical notice:

Bart Bauwens received a Master Degree in Electrical Engineering from the Rijksuniversiteit Gent (RUG) in 1990. He joined the Katholieke Universiteit Leuven (KUL) in 1992 as a researcher and participated in a number of European projects (TIDE framework), which investigated the accessibility problems for visually impaired people. He gained experience in standards for electronic documentation, such as SGML and others. In 1996 he joined the on-line services group at the Research Centre of Alcatel Bell, where he is currently leading a group of people investigating software agent technology in the telecom industry and involved in two ACTS projects, FACTS and MIAMI.

ABSTRACT:

agents

service deployment
telecom

The telecom industry is currently facing a lot of challenges. Business models need to be adapted, taking into account the liberalisation of the telecom market, the advent of new types of players and business interactions. In this very dynamic and technology-driven environment, control and automation of all those interactions has become more important than ever. Also, interoperability issues between heterogeneous networks, different service platforms, or different terminal types need to be solved. Fast delivery of new services to the customer is not sufficient anymore and service providers need to think about personalisation and user mobility.

In this paper we will show how software agents using XML languages offer an attractive way of solving many of these issues. RDF, the Resource Description Framework, has been chosen for the communication between telecom agents. As a case study a set of RDF schemas has been developed for use in scenarios dealing with the provisioning of Virtual Private Networks.

Introduction

In today's landscape of open telecom markets, telecom operators have started to play new roles. At the same time completely new players are appearing on the market. The business interactions between those roles have become much more complicated than before. The liberalisation process has also resulted in a mixture of heterogeneous systems, networks and terminals. On the other hand, telecom companies still want to meet the high expectations of their customers, asking for on-demand, robust and personalised services.

Before we can argue why software agents can elegantly solve the above challenges, we need to say a few words about what we mean with 'software agents'. A lot of discussion material already exists on this topic, resulting in quite different definitions of agents (see for example ). For example, 'an agent should speak an agent communication language', or 'an agent has beliefs, desires and intentions'. Clearly, the chosen definition depends on the background of the author. For the sake of this discussion, we will use a rather broad definition and define agents as being 'autonomous pieces of software, which behave in the interest of their users'.

intelligent agents

mobile agents

Software Agents in Telecom

Traditionally, one distinguishes between 'intelligent' and 'mobile' agents. Intelligent agents originate from the DAI (Distributed Artificial Intelligence) community. Inside, they usually apply AI technologies such as inference engines or rule-based systems, while -on the outside- they typically communicate using knowledge representation languages such as KIF or Cycl . Intelligent agents may be able to actually change the behaviour of other agents by sending small 'code' fragments. On the other hand, mobile agents move their data and code to a remote site and execute locally. Mobile agents can also be used to modify or introduce new behaviour, but in a less 'granular' way. However, the border between communicative and mobile agents is not very sharp. The XMLAgents initiative for example shows how to exchange messages, encapsulating both data and behaviour, using a combination of scripts and the DOM.

Intelligent and mobile agent technology bring appealing solutions in telecom service deployment, as agents can be used to customise or personalise services during their service lifetime. By the exchange of ASCII messages (information, scripts,...), binary code (compiled code, objects, ...), or a combination of both, the interfaces between end-user and service provider can be dynamically changed to optimise the interactions. In this paper we will only concentrate on agents exchanging text-based messages. For this purpose, we introduced a third category of agents: communicative agents, which exchange messages with common predefined semantics, allowing for a more flexible approach compared to traditional software APIs.

Communicative agents are very attractive as they can take over the burden of the complex interaction mechanisms between different telecom players, such as negotiations or charging. Agents can easily represent one of the business roles such as backbone operator, access provider or end-user, and act on their behalf, based on established policies or user profiles.

Towards Standard Agent Languages

Key success factor of software agents is the development of standard communication languages. The most relevant standard body for communicative agents is FIPA, the Foundation for Intelligent and Physical Agents , an international association of companies, producing specifications which will ensure agent and agent-platform interoperability.

ACL, Agent Communication Language

FIPA

FIPA's Agent Communication Language (ACL)

The most important output of FIPA today is its Agent Communication Language (ACL), which is based on speech-act theory . A FIPA ACL message consists of a header, the 'communicative act', followed by the subject of this act, referred to as the 'content'. FIPA ACL acts, such as 'inform', 'request', 'propose' or 'cfp', can then be used to change the mental attitude of the agents (their belief, desire or intention). In addition to this, a set of predefined agent interaction protocols is defined, such as the iterated-contract-net protocol, useful for negotiation. It is clear that standardising on an Agent Communication Language alone is not sufficient to achieve interoperability. Of equal importance is the standardisation of the vocabularies or ontologies and the content language used to express the concepts of the vocabulary.

FIPA Content Languages

FIPA does not mandate the usage of one particular content language, but instead allows applications choosing an 'appropriate' one. There is however one important requirement: the language should be able to express 'actions', 'statements' and 'objects'. Languages such as KIF have built-in support for expressing those concepts, but are only popular in closed academic circles. When using XML as content language, the meaning of the elements is usually specified in the documentation of the DTD. As XML has no built-in support to represent propositions, actions, etc., one solution may be to let the DTD designer specify how the different element types can be mapped into those concepts. This mapping can also be formalised using mechanisms such as architectural forms. Anyway, establishing such a mapping for an existing DTD is not straightforward (if possible anyway).

FIPA Communication Layers

FigureBAU-006 clarifies the relationships between the different involved communication layers. Currently, alternative solutions are being suggested to FIPA for content, ACL message and message transport layers.

Agents using RDF Schemas

From DTDs to Schemas

It is well known that XML DTDs only define templates for structuring the information, allowing for strict syntax validation. They do not provide any semantics at all: the actual meaning of the elements and attributes is normally agreed upon in advance. In some situations the usage of rigid tree structures imposed by DTDs does not offer enough flexibility.

On the other hand, schemas aim to provide a first level of semantics to the underlying concepts. For example, most practical applications have a need to express quantities such as lengths, bandwidth, prices, etc. Most of the existing DTDs have currently defined those in their own way. Schemas however provide us with 'standard' data types (and user-defined). Schema languages also need to take into account common OO programming concepts such as inheritance, allowing for reusability of element types and easy mapping into software class diagrams.

Typically, schemas can be exchanged using the same syntax as their instances. This may result in very flexible systems allowing for fine-grained modifications or enhancements to the schemas. In combination with scripting technology, schema technology comes very close to what agents are all about: introducing new behaviour or customise existing behaviour without any prior agreements.

RDF and Agent Communication

The Resource Description Framework (RDF) defines a mechanism for describing (Web) resources, 'to enable automated processing of these resources'. It provides both a model for representing these meta-data and proposes XML as serialisation syntax. Using RDF Schema a meta-model of the RDF data model can be defined. The combination of RDF and RDFS allow the description and modelling of different concepts with entity-relationship graphs and are clearly well suited as software agent languages.

RDF as FIPA content language

In this section, we will establish a mapping between the current RDF concepts and concepts required for FIPA content languages. First of all, FIPA Objects can be easily mapped to RDF resources. This implies that we can use RDF resource identifiers and references as ACL object identifiers and references, and can use FIPA's primitive act 'query-ref' to resolve an RDF reference.

For modelling propositions, we have two options: the simplest solution just assumes that each description expresses at the same time a belief. However, in many cases, it is useful to model the propositions more explicitly. As an example we will encode "the proposition _February 2000 has a total number of 28 days_ is false" as follows:

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3c.org/TR/WD-rdf-syntax#"

xmlns:fipa=http://www.fipa.org /schemas#">
<fipa:Proposition>
<rdf:subject>Feb_2000</rdf:subject>
<rdf:predicate resource="http://www.y2000.org/schema#totalNumberOfDays"/>
<rdf:object>28</rdf:object/>
<rdf:type resource="http://www.w3c.org/TR/WD-rdf-syntax#statement"/>
<fipa:belief>false</fipa:belief>
</fipa:Proposition>
</rdf:RDF>

Similarly, as RDF has no built-in notion of actions, we defined RDF schemas to allow explicit encoding of:

Actions, including the actor and the argument of the action.
Results of those actions.
State information on the action, such as 'done', 'refused', 'ongoing', 'interrupted', etc.

Other RDF-based efforts in this direction are OML and the more powerful CKML . However, we feel that the complexity of the latter efforts may endanger their success as Web language.

Telecom Agents using RDF

Telecom vocabularies based on XML/RDF

In this context, the eXtensible Markup Language (XML) , offers significant advantages. First of all, the Web is definitely a very attractive 'place-to-be' for making real business of agent technology today. Currently a variety of Web vocabularies are emerging in very different domains such as e-commerce, finance, software deployment, mathematics, chemistry, etc. Also in the telecommunication domain, XML specifications are starting to emerge, such as for example the 'Composite Capabilities and Preferences and Profiles' . These telecom vocabularies may result in de-facto standards for exchanging service, user and terminal profiles or 'intelligent' application protocols. Combined with style-sheet languages such as XSL, agent messages can be represented in common Web pages. Also, its linking capabilities allow splitting up services into constituting components, potentially offered by different providers. Moreover, a wide variety of XML supporting tools exist to allow a fast application development.

VPN Provisioning through XML-based communication

Roles and Agent Types

As a case study, we applied the agent paradigm to the provisioning process of Virtual Private Networks (VPN). First, the roles of end-user, customer, VPN service and network provider were mapped to different types of software agents.

The most important agent types are listed below:

A Personal Communication Agent (PCA) will represent the interests of its end-user as good as possible. It will therefore have access to the user's profile. The end-user will run one or more applications on top of the VPN which can be controlled each by a different type of Application Agent (see further on).

VPN Service Provider Agent (VPN SPA) is a special type of Service Provider, able to act as a broker between PCA and NPAs.
A Network Provider Agent (NPA) represents a Network Provider who manages its own network domain. Federation between different NPAs is also possible.

In the next section, we will go into more detail on the functionality offered by those agents. On the other hand, a few additional agents will be considered, which are useful to integrate with the user applications.

VPN Provisioning Scenarios

The VPN Provisioning scenarios can be split up in multiple consecutive scenario stages, deemed necessary for co-ordinating and provisioning a multi-user application across a multimedia VPN. The distinctive stages in this scenario are:

Meeting Scheduling: The PCAs negotiate about a mutually convenient time for the conference.

Service Provision Negotiation: The initiating PCA will contact one or more SPAs requesting the required services. Negotiation will be based on parameters such as duration, price, security, quality of service, ...

Network Provision Negotiation: Each SPA must negotiate with one or more NPAs to arrange the provision of the required VPN. The negotiation parameters are similar as in the previous stage.
Commission VPN: The SPA requests the NPAs to set up the network connections.
Manage VPN: Management information is exchanged between agents, possibly resulting in a new configuration of the established VPN.
Decommission VPN: The SPA controls the decommissioning of the VPN.
Service Charging: NPAs will bill the SPA for the use of their network. The SPA can add charges for additional services and will propagate this bill to the PCA.

Only the Meeting Scheduling and Service and Network Provisioning are further expanded here.

Meeting Scheduling Scenario Stage

In the Meeting Scheduling scenario stage (FigureBAU-016 ), the PCAs act as personal organisers for the users, arranging a mutually convenient time for the multimedia application to be started. In this negotiation there is also interaction between the PCA and the Application Agents. These Application Agents manage specific types of end-user applications (in our case a Video Conferencing and a Calendar Management tool), and interact with the Application Wrapper Agents which represent the actual application. Note that all agents in figure 2 interact via FIPA ACL messages.

Service Provisioning Scenario Stage

When the Meeting Scheduling stage is finished, the Service Provisioning stage (FigureBAU-017 ) starts. One of the PCAs will communicate the details of the required service to a selection of SPAs. Each SPA must then negotiate with a set of NPAs to arrange the provision of the required VPN connection. This results in the selection of an NPA, which meets best the requirements of the SPA. Finally the SPAs which were contacted by the PCA will send their service offer to the PCA, which will then select the SPA which offer matches the service requirements best.

VPN Ontologies

Ontology Requirements

The VPN Provisioning scenarios described above resulted in the identification of the many different concepts which need to be expressed. The following modules can be distinguished:

Service Transactions: these are the service requests, offers, service triggers, charges, etc.
Generic Service properties: a price, a start-time, a duration, etc.
Specific Service properties: applicable to services such as VPN, e-commerce, etc.
Quality of Service for connections: for example bandwidth, latency, jitter, availability, packetloss, etc.
Security Information: security methods and requirements (authentication, confidentiality, integrity)

For the videoconference and calendar manager applications, vocabularies will be needed to express:

Videoconference Profile Information: parameters, such as frames per second, audio/video, colors etc.
Event scheduling protocols: for updating calendar information, negotiating meetings etc.

In addition to those, we defined some general-purpose vocabularies for describing:

Quantities: special types of quantities are bandwidth, price, duration, etc.
Events: type, start and end of events.

RDF Schemas for VPN Provisioning

Alcatel developed a set of RDF schemas that model most of above concepts. An agent platform will be developed that uses those RDF-based vocabularies in a set of pan-European trials.

As an example, the following message illustrates how a FIPA 'Request' message can be issued to start a VPN service, using RDF as content language (note that the corresponding schemas are not included here).

(request
:sender PCA
:receiver SPA
:content
(  <?xml version="1.0"?>
<rdf:RDF xmlns="http://www.fipa.org/schemas#">
<startVPNService rdf:ID="startact1">
<actor>SPA</actor>
<argument rdf:resource="#VPNservice1"/>
</startVPNService>
</rdf:RDF>)
:language RDF)

The SPA agent could now reply for example that starting the VPN service has failed because the PCA tried to start the reserved service ('VPNservice1') too early.

(failure
:sender SPA
:receiver PCA
:content
(  <?xml version="1.0"?>
<rdf:RDF xmlns="http://www.fipa.org/schemas#">
<startVPNService rdf:about="startact1">
<done>false<done>
</startVPNService> )
<Reason>Reservation does not match: too early to start</Reason>
</rdf:RDF>)
:language RDF)

The above examples show that it would be useful to replace the current LISP-alike ACL syntax proposed by FIPA with an XML or RDF equivalent. Therefore, we developed alternative XML DTDs for expressing ACL agent messages and agent management related content (for example agent and service registration).

Conclusions and future work

We aimed to demonstrate a number of VPN provisioning scenarios in an open telecommunication environment. Agents can easily represent the different players, communicating in the FIPA Agent Communication Language. To ensure interoperability between different systems, services and applications, standard content languages are needed as well. We argued that the RDF technology suits very well to agent technology and have shown how to use it for the defining a set of schemas in the area of service provisioning, with an emphasis on VPNs.

We believe these efforts are certainly a first step forward towards service negotiation and interoperability. However, still many questions remain unanswered so far, such as how does RDF compare with other schema initiatives, such as XSchema , the Document Content Description , the Document Description Markup Language or the XML Metadata Interchange specification . A good trade-off between power and complexity will be essential for the success of those languages.

Telecom companies have now understood the benefits of XML technology and are starting to work on common interchange formats, describing information and services, user profiles and preferences, expressing terminal capabilities or even defining new high-level application protocols. This is obviously a long and tedious process and our RDF efforts are just one step forward. In this process we should avoid as much as possible to duplicate existing specifications. Even if XML becomes the 'de-facto' way of communication, translation modules will continue to exist forever. As an example, an XML version of iCalendar was developed by IETF. Although this may become very useful, it is important that their expressiveness remains limited to what already exists in the corresponding established standard, in order to allow a one-to-one mapping. Also, a framework for classification of telecom services is needed, to allow the combination of similar efforts for defining telecom ontologies and achieve inter-working between different services. Ultimately, the application of XML technology in telecom companies should allow merging both the success of Web services with the power of future telecommunication infrastructures.

Acknowledgments

The author acknowledges that part of this work is being funded by the European Commission (ACTS Programme Domain 5/Project FACTS).

Bibliography

CCPP: Composite Capability/Preference Profiles (CC/PP), W3C Note, 30 November 1998, on-line at http://www.w3.org/TR/1998/NOTE-CCPP-19981130/
CyC: The Cyc( Technology, on-line at http://www.cyc.com/tech.html#cycl"/>
Daw: F. Dawson, iCalendar DTD, Internet Draft (IETF), Network Working Group, November 16, 1998, online at http://www.imc.org/draft-dawson-ical-xml-dtd
DCD: Document Content Description, W3C Submission, 31 July 1998, on-line at http://www.w3.org/TR/NOTE-dcd
DDML: Document Description Markup Language, January 1999, on-line at http://www.w3.org/TR/NOTE-ddml
DOM: Document Object Model, on-line at http://www.w3.org/DOM/
FIPA: FIPA, the Foundation of Intelligent and Physical Agents, home-page at http://www.fipa.org
Gen: Genesereth, M. R., Knowledge Interchange Format Specification, working draft for an American National Standard, March 1995, on-line at http://logic.stanford.edu/kif/specification.html"/>
Green: Green S., Somers F., Software Agents: a review, May 1997, on-line at http://www.cs.tcd.ie/research_groups/aig/iag/toplevel2.html"/>
Kent1: Kent, R., Ontology Markup Language, on-line at http://asimov.eecs.wsu.edu/WAVE/Ontologies/OML/OML-DTD.html
Kent2: Kent, R., Conceptual Knowledge Markup Language, on-line at http://asimov.eecs.wsu.edu/WAVE/Ontologies/CKML/CKML-DTD.html"/>
Morg: Morgenthal, J., P., The XML Agents (XML-A) Initiative, July 1998, on-line at http://www.jxml.com/xmlagent.html
RDF: Resource Description Framework (RDF), Data Model and Syntax, W3C Working Draft, October 1998, on-line at http://www.w3.org/TR/WD-rdf-syntax
RDFS: RDF Schema (RDF), W3C Working Draft, October 1998, on-line at http://www.w3.org/TR/WD-rdf-schema"/>
Searle: Searle J.R., Speech Acts, Cambridge University Press, 1969.
XMI: XML Metadata Interchange, OMG, January 1999, on-line at ftp://ftp.omg.org/pub/docs/ad/98-07-01.pdf"/>
XML: Extensible Markup Language (XML), W3C Recommendation, February 1998, on-line at http://www.w3.org/TR/1998/REC-xml-19980210
XSchema: XSchema v1.0 specification, on-line at http://www.simonstl.com/xschema


XML does matter for next generation of "Plug &, Play" Electronic Commerce		Table of contents		Indexes		Managing the Intellectual Property Lifecycle