1 Scope
Across the world, numerous telecommunications service providers combine service elements from different network providers in order to provide a single service to end customers. The ultimate goal of all parties involved is to find the best solutions available in terms of quality of service and cost. The increasing demand for on-line customer configurable services and on-line provisioning of services requires systems and networks that are capable of co-operating on different levels and that transcend conventional business and national boundaries.
The dynamic Virtual Public Network (VPN) service is a telecommunications service provided to users that want to set up a multimedia connection with several other users. The provisioning of a dynamic VPN service is an example of how service providers and network providers will have to co-operate in order to provide this to the end-customer.
Traditional network management frameworks (for example, TMN or SNMP-based solutions) are based upon fixed management functionality and fixed interaction interfaces that cannot easily satisfy the flexibility and complexity that the dynamic multimedia VPN service demands. Agent technology is promising in this domain since it facilitates automatic negotiation of service contracts and subsequent configuration of those services, thus enhancing the provisioning process for the users and administrators of dynamic multimedia VPN services.
FIPA agents, which can interact using ACL, have significant advantages in this context. In summary FIPA agents can:
· Support effective negotiations that will be complex,
· Support dynamic service and service condition configuration via knowledge exchange,
· Reduce the dependency on the network reliability and availability by encapsulating the negotiation functionalities in ACL messages,
· Provide friendly and enhanced customer support via agency, and,
· Support personalization of the service resource configuration and utilisation using more detailed knowledge about users and providers and their preferences.
2 General Analysis
The VPN service provides a virtual private network over which multimedia applications can be executed. This specification does not specify the multimedia services or applications but they might be, for example, a virtual meeting, a shared workspace or a video conference. The VPN service is constructed, maintained and delivered using specialised co-operating and negotiating agents. This specification presents a scenario that is complex and realistic enough to exercise the feasibility of multi-agent technologies being proposed in FIPA; this document explores functional requirements and proposes a functional specification.
For actually provisioning the multimedia VPN service, three types of agents are used that represent the interests of the different parties involved (see Figure 1):
· Personal Communications Agent (PCA)
This agent represents the interests of the human users.
· Service Provider Agent (SPA)
This agent represents the interests of the service provider.
· Network Provider Agent (NPA)
This agent represents the interests of the network provider.
Figure 1: Virtual Public Network Multimedia Service Reference Model
For each type of network that will be used for the VPN service, it is necessary to provide a specialist agent that is able to translate requirements from the SPA to the appropriate network configuration settings.
The VPN service is established by the user who requests the service from their PCA, stating their requirements including the desired quality of service, cost constraints and duration. The initiating PCA negotiates with other PCAs to arrange preliminary conditions such as a time to start the service and terminal details; these initial communications will occur prior to the establishment of the VPN service using traditional network resources, such as the Internet. The initiating PCA will then negotiate with available SPAs to obtain the best service offer available and the SPA will in turn negotiate with NPAs to obtain the optimal solution and to configure the service at the network level. Both SPAs and NPAs communicate with underlying service and network management systems to configure the networks for the service.
2.1 Functional Requirements
These requirements describe the high-level implementation-independent requirements for the dynamic VPN service. which are independent from the notion of an agent.
The following parties are involved in the provisioning of the dynamic VPN service and use their own negotiation strategies to meet their internal goals (neither of which will necessarily be publicly known):
· User
The initiating user will negotiate with a service provider about the terms and conditions of the service to be provided at minimum cost. The receiving user will get a notification from the network provider that his participation is required in the VPN service when it has been established.
· Service Provider
The service provider will negotiate with the user about terms and conditions as stated above. The service provider will also negotiate with its network provider in order to find the optimal solution for the provisioning of the service to the customer since the service provider has an interest in maximising its profit.
· Network Provider
The network provider will negotiate with the service provider about terms and conditions as stated above and will also negotiate with other network providers for parts of the connection it cannot deliver itself or that can be offered more cheaply than the network provider can deliver since the network provider has an interest in maximising its profit. The network provider will notify the receiving customers that their participation is required once the VPN service has been established.
· Third-Parties
Third-party network providers negotiate with the network provider to provide services. They will also notify the receiving customers once the VPN service has been established.
2.1.1 Initiating User Requirements
The dynamic VPN service is mainly aimed at the market segment represented by the executive traveller who is thought to be flexible, efficient and cost-effective. Further, the executive traveller expects a reliable, flexible service without being confronted with the technical implementation details.
The initiating user is responsible for the set up of the VPN service. When applying for provisioning of a dynamic VPN service, they must issue a request to the service provider in order to start the provisioning of the service. The requirements of the initiating user state what characteristics they will expect from the service.
Their requirements can be summarised as:
· Broadband Connection to Other Users (Mandatory)
The VPN service shall support the provisioning of broadband connections to one or more other users. The underlying bearer network should make it possible to set up multimedia connections upon a user’s request. For example, the user may request a semi-permanent ATM PVC connection.
· Anytime, Anyplace Connection (Mandatory)
The VPN service shall have no restrictions for time and locality. The user can issue a request anywhere in the network at any time and the users to be connected can be located anywhere in the network. For example, the user may request the VPN service at 2am from a moving taxi using his GSM terminal to contact a local AP that resides in the base station of the mobile telephony operator.
· Dynamic Configuration (Mandatory)
The service parameters (for example, quality of service, price, user list, bandwidth) and the number of participating users can be changed dynamically during the life-time of the VPN service. For example, the user may wish to change the bandwidth to allow video conferencing any time when the VPN service is active.
· Reliability (Mandatory)
The VPN service shall be reliable in the sense that the agreed quality of service is met and that the risk of unexpected termination of the service is minimised. For example, all parties jointly providing the service have measures in place to guarantee 99% availability of the VPN service.
· Fault Tolerance (Mandatory)
The VPN service should be robust in the sense that it can recover from most exceptions. For example, when a link that is part of the connection can no longer be provided because of a hardware fault, an alternative link is automatically invoked to keep the connection alive.
· Security Levels (Mandatory)
The VPN service shall support different levels of security (authentication, non-repudiation, integrity, trust and confidentiality). For example, an unauthorised user who wants to use an established VPN service should be informed that they are not a valid member of the user list.
· Online Billing (Optional)
The VPN service should be able to make billing information available on-line in real-time. For example, the user decides to change bandwidth and is informed that this cannot be done within their current budget.
· Intelligent and Flexible Customer Care (Optional)
The VPN service should provide enhanced customer support such as delivering intelligent responses on requests about the provisioned service. For example, the user wants to know how much it will cost to add more participants to the service.
2.1.2 Receiving User requirements
The requirements of the receiving user can be summarised as:
· User Notification for Receiving Calls (Mandatory)
The VPN service shall notify the user whenever a call is received for participation. For example, a user is requested to join the VPN.
· User Notification for Terminating Calls (Mandatory)
The VPN service shall notify the user whenever the VPN service is terminated upon request of the initiating user. For example, the video meeting draws to a close.
· User Notification for Exceptions (Mandatory)
The VPN service shall notify the user whenever an exception occurs that hampers the VPN service. For example, a hardware fault prevents a user from continuing participation.
2.1.3 Service Provider Requirements
During the life-time of the VPN service, service providers will be able to renegotiate contracts with network providers in order to further optimise the service that is delivered to the user. The dynamic renegotiation and reconfiguration should be invisible to the user.
· Profit Maximisation (Mandatory)
The VPN service will allow the service provider to maximise their profit which means that the service provider has a negotiation strategy that maximises revenue and minimises cost for the deployment of the service. Negotiations will be undertaken within the constraints of required quality of service and cost as they are specified by the user.
· Negotiate Position with a User (Mandatory)
The VPN service will allow the service provider to effectively negotiate about terms and conditions and the cost of the service with the user which results in a contractual agreement between the service provider and the user.
· Negotiate Position with a Network Provider (Mandatory)
The VPN service will allow the service provider to effectively negotiate about terms and conditions and the cost of the service with the network provider which will results in a contractual agreement between the service provider and the network provider.
· User Satisfaction (Mandatory)
The VPN service will allow the service provider to be able to satisfy the requirements of the user during the entire life-time of the service. This requirement implies that the VPN service allows the service provider to dynamically change their network providers.
2.1.4 Third-Party Requirements
The requirements of third-party network providers can be summarised as:
· Profit Maximisation (Mandatory)
The VPN service will allow the network provider to maximise their profit which means that the network provider has a negotiation strategy that maximises revenue and minimises cost for the deployment of the service. Negotiations will be undertaken within the constraints of required quality of service and cost as they are specified by the service provider.
· Negotiate Position with a Network Provider (Mandatory)
The VPN service will allow the network provider to effectively negotiate about terms and conditions and the cost of the service with the service provider which will results in a contractual agreement between the network provider and the service provider.
2.2 Benefits
Current VPN services have been implemented in different application contexts and with different technologies. The agent-based approach advocated by this specification, has a number of advantages over existing technologies for the provisioning of dynamic VPN services.
2.2.1 Satisfying Dynamic Virtual Public Network Provisioning
The major high-level requirements of the roles and actors in the VPN service are the capabilities to negotiate about service conditions and configurations and to notify (or be notified) accordingly. Service negotiation in this context will have the following objectives:
· The satisfaction of the requirements from users/customers, and,
· The optimisation of the service conditions and configurations, for example, minimal costs, maximum profits, etc.
With traditional negotiation mechanisms, for example, CMIP/SNMP-based service subscriptions, a user can only select the service features offered by the service provider. The interface between the negotiation partners is fixed by, for example, GDMO, IDL or ODL specifications. A user can only modify the service parameters if such modifications are allowed in the interface specification and thus the possibility of dynamically optimising the service conditions and configurations is limited.
FIPA agents, using ACL as the agent communication language, can significantly enhance the possibility of dynamic negotiation and optimisation. For example:
1. The service provider can change the knowledge (or inform such changes) of the user (for example, the customer care component at the user site) about the service provisioning. In this way, the service provider can dynamically change the form of the service features or even the service itself in response to new user or service provider requirements.
2. The user can express their wishes and preferences, inform the provider about new requirements and request new service features. With such information, the service provider can infer user characteristics and offer appropriate support.
3. Service negotiation can have several phases following a contract net protocol in order to reach the optimal agreement between the involved parties.
4. The involved parties can modify their negotiation strategy dynamically, depending on the intermediate negotiation results.
Therefore, FIPA agents provide a highly flexible, robust and user-friendly framework for service negotiations.
2.2.2 Satisfying the User Requirements
· Broadband Connection to Other Users
Provisioning of connections can be affected by many quality of service parameters and FIPA agents can provide enhanced support for negotiating such parameters, resulting in a very flexible and user-oriented provisioning.
· Anytime, Anyplace Connection
With FIPA agents, the requests and preferences of the users can be coded in ACL messages which can be sent to the responsible service provider. Large grain messages in this context can direct and determine the service features to be provisioned. The user can send the message from anywhere in the network and can even disconnect itself from the network after sending the message.
· Dynamic Configuration
ACL communication between agents enables the reconfiguration of and agent’s knowledge about service configuration and the corresponding functionalities and, therefore, the dynamic configuration of the service resources.
· Reliability and Fault Tolerance
Negotiation that is based on ACL can treat exceptional situations more intelligently and support negotiations that are more robust. Using composite messages, like mobile agents, the encapsulation of the negotiation steps or management actions within the messages can be achieved. With such encapsulation, the number of messages transmitted over the network can be reduced and the dependency of VPN provisioning on the underlying remote network for management traffic can thus be lessened. This can further increase the reliability and fault tolerance of the provisioned service.
· On line Billing
Via ACL-based service negotiations, the user can request and determine the specific billing features and ask the service provider to make the data available at requested schedules and patterns.
· Security Levels
The user can negotiate with the service provider about the levels of the security for all the management operations.
· Intelligent and Flexible Customer Care
This will be the most important feature supported by the FIPA agents.
2.2.3 Satisfying Receiving User Requirements
The receiving users will be notified of VPN service-related events via ACL messages.
2.2.4 Satisfying Service Provider Requirements
· Profit Maximisation
This entails the optimisation of the resource usage based on the knowledge about user preferences and requirements. Such optimisation requires intelligent planning within the service provider by reasoning about the knowledge concerning the users. Sophisticated negotiation using ACL will be necessary to obtain such knowledge.
· Negotiate Position with a User
This will be supported by ACL messages and the corresponding contract net protocol.
· Negotiate Position with a Network Provider
Similar to the previous point.
· User Satisfaction
The FIPA agent-based approach allows the provider to dynamically configure the service features to meet the user requirements.
2.2.5 Satisfying Third-Party Requirements
This is similar to section 2.2.4, Satisfying Service Provider Requirements.
2.3 Actors, Roles and Domains
2.3.1 Generic Model
The Personal Communication Agent (PCA) acts as a Personal Assistant (PA) to the user and will typically reside on a PDA or a portable computer. Since the assumption is that the user is mobile, the PCA will have to register with an AP in order to obtain access to the Message Transport Service (see [FIPA00067]) in this new environment.
In order to obtain the VPN service, the PCA will negotiate with one or more Service Provider Agents (SPAs). Each SPA can be seen as the front-end of a network provider. In order to obtain relevant customer data, the SPAs might access existing Customer Care Systems (CCS).
Each SPA will now start to negotiate deals with different Network Provider Agents (NPAs) that each represent telecommunications networks or parts of them. The NPAs translate the high-level PCA requests into low-level technical requirements. In order to find out whether it can deliver the required service, each NPA will contact existing Network Management Systems (NMS) which are also represented by agents.
Some termination points of the requested VPN service might lie outside the network of the first network provider. If this is the case, then the NPA will contact peer NPAs with a request to supply the missing connections in order to configure the service. NPAs that provide connections to end users will contact the appropriate SPAs in order to negotiate over the delivery conditions.
2.3.2 Personal Communication Agent
The PCA represents the customer in its dealings with service providers and must elicit user requirements for a request for service. For example, a user wishes to set up an on-demand VPN service to a set of company executives so that an interactive meeting can take place. These company executives are located around the globe and so the VPN service will span a number of different networks and network types. It is assumed that information about user requirements already resides within the PCA. The PCA must maintain this information so that the user could be offered alternatives in the event that no ideal service offering is available.
To obtain the desired service with the stated constraints and preferences, the PCA must find and interact with SPAs. The negotiation between the PCA and the SPA can be thought of as iterated bargaining, where the PCS will employ a strategy for bargaining with SPAs so that it can realise its preferences.
In order to communicate with other agents, the PCA must register with an AP which provides directory facilities and, if necessary, gives access to additional resources such as video screens, etc.
If an SPA offers a service which is acceptable to the PCA, then it will accept the service. This acceptance will mean that the PCA will commit the necessary resources of it the user's company to provision the service. Similarly, the SPA will commit necessary resources that it needs, possibly by bargaining with other agents. Activation of the agree service follows and the PCA will terminate its bargaining with other SPAs for that particular service.
2.3.3 Service Provider Agent
The SPA represents the interests of the service provider and supports the provisioning of telecommunication services to users. It adopts two distinct roles:
1. As a client of network services offered by an NPA, and,
2. As a provider of a variety of telecommunication services to users via their PCA.
It is possible that this agent performs other management activities such as billing. At present, the SPA does not interact with other SPAs and as such does not act as a third-party provider.
The key functions performed by the SPA during service provisioning are as follows:
· Capture customer requirements and identify the service
The SPA receives a service request from a PCA. The identification of customer service requirements might require iteration between SPA and PCA and negotiation over service characteristics. The SPA maps the PCA requirements onto an existing service portfolio.
· Determine component software and network service requirements
The SPA decomposes the service request into its component services and software.
· Negotiate terms with the user as a provider
The SPA interacts with the PCA in order to agree the terms and conditions of the delivery of the service.
· Identify secure NPAs for component services
The SPA queries the DF for information on available NPAs for the delivery of component services.
· Negotiate with NPAs for component network services as a client
The SPA has an understanding of the component services it requires and it also has a representation of the meta-knowledge concerning the negotiation, such as a negotiation strategy, a definition of acceptable terms defined as a dedicated ontology, a knowledge of the negotiating protocol and access external management systems.
In order for the SPA to provision a service to the PCA it requires access to a number of existing service management systems, for example, a customer entry system, a billing system, a customer credit check system, security management, etc. These might be non-agent systems with their own proprietary interfaces.
2.3.4 Network Provider Agent
The NPA represents a network domain. Its major responsibility is in the provisioning of network connectivity upon requests from the SPA. For this purpose, the NPA has to interact with the SPA representing the user, the network management system representing the local network domain and with other NPAs representing other network domains in the global environment.
To obtain a network connection from the NPA, the SPA will first negotiate with the associated NPA and inform it of the requirements on the connection. This negotiation can consider an already existing long-term contract between the two parties, but it has to support the specific requirements of the current session. The knowledge needed by the NPA in this interaction includes the service description knowledge and the in-service requirements.
To provide the requested connection, the NPA has to first breakdown the task into local connection segment reservations and external connection segments, based on some service strategy and knowledge about the global network environment. The NPA will then try to reserve connection segments in its local domain and segments through other NPAs to connect the terminating points.
For the task breakdown and for creating connection segment requests, the NPA will need a resource model for both the underlying network management system it represents and for the resource model of other network domains represented by the other NPAs. The NPA will also select the other NPAs based on an acquaintance model established via exchanging information among NPAs and DFs.
In its role as a third-party provider, the NPA must be able to negotiate with other NPAs over the requested sub-network connections.
2.3.5 Customer Care System
A Customer Care System (CCS) is a collective name for the facilities of the service provider supporting the provisioning of the service to the users. This can include a customer entry system, a billing system, a customer credit check system, etc. These are typically non-agent systems with their own proprietary interfaces which must be integrated with guidance from [FIPA00079].
2.3.6 Network Management System
A Network Management System (NMS) is the conventional (non-agent) network management software of the network domain. The NMS maintains a dynamic view of the network and is able to establish connections at the request of an NPA. Each NMS will be represented by exactly one NPA and these must be integrated with guidance from [FIPA00079].
2.3.7 Certification Server
A Certification Server is a trusted third-party that stores public keys for registered agents. These keys can be requested by any party wishing to validate the identity of such an agent.
2.4 System Requirements
2.4.1 Requirements for All Agents
These are the basic requirements that are relevant for the provisioning of the dynamic VPN service by the PCA, the SPAs and the NPAs:
· Negotiate Position
The PCA, the SPAs and the NPAs shall be able to effectively negotiate about quality of service and cost. This means that they shall have sufficient information and intelligence to find an optimal solution within these constraints. For example, during the set up phase, the PCA requests a particular quality of the service from the SPA. The SPA cannot deliver this quality and the PCA suggests a lower quality for a lower price that still meets the quality requirements of the user.
· Traceability
For the purpose of dynamic testing, the PCA, the SPAs and the NPAs shall be able to keep track of all their activities which involves timestamps, logs and reports about their activities upon request. For example, each agent keeps track of all its negotiation activities and sends the information to its HAP where a log is kept for later investigation.
· Reliability
The PCA, the SPAs and the NPAs shall be reliable in the sense that the risk of unexpected failure of the services offered by an agent is minimised. For example, a PCA should be capable of reconnecting itself with the MTS after the connection has been temporarily disabled.
· Fault Tolerance
The VPN service should be robust in the sense that it can recover from most exceptions. For example, when a link that is part of the connection can no longer be provided because of a hardware fault in the switch, an alternative link is automatically installed to keep the connection established. An NPA will re-provision the link or acquire the link via a third-party NPA or report failure back to the SPA which will then try to re-provision the VPN using alternative network providers.
· Security Levels
The PCA, the SPAs and the NPAs shall support different levels of security (authentication, non-repudiation, integrity and confidentiality). For example, when an agent that has not been authenticated tries to contact the SPA, it should be informed that it cannot have access to the services of the SPA.
2.4.2 Initiating PCA Requirements
· Interaction with SPAs
The PCA shall be able to interact with an SPA in order to request the VPN service.
· Low User Complexity
The PCA shall be able to establish and maintain the service without complicated interaction with the user. This implies that the PCA shall have enough intelligence to deal with unexpected situations or events as described in previous sections on reliability and fault tolerance. For example, during the life-time of the service, a link in the connection is no longer available. Without consulting the user, the PCA, in collaboration with SPAs and NPAs, should try to find an alternative link.
· Lowest Price Negotiation (Optional)
The PCA may strive for the lowest possible price to be paid for the entire service. For example, during the set up of the VPN service, the PCA deals with various third-party providers and selects the cheapest solution without compromising the quality of the service as specified by the user.
· Optimum Performance Negotiation (Optional)
The PCA may strive for the best possible performance for the entire service. For example, during the set up of the VPN service, the PCA deals with various third-party providers and selects the solution that offers highest quality without overspending the available budget.
2.4.3 Receiving PCA Requirements
· Reception of Call (Optional)
The PCA may be able to receive and accept a call on behalf of its user. For example, if the PCA receives a message that involvement in a video conference is requested, then it will acknowledge the message and initiate the procedure to notify the user and to prepare the equipment.
· Interaction with Terminal Equipment (Optional)
The PCA may be able to interact with terminal equipment such as a PC application that has video conferencing capabilities.
2.4.4 Requirements for the SPA
· Interaction with PCA
The SPA shall be able to interact with a PCA, using a negotiation strategy that maximises its goals (e.g. maximum profit, maximum customer satisfaction).
· Interaction with NPA
The SPA shall be able to interact with an NPA in order to inquire about the possibilities of supplying the service requested by the PCA, and in case of a successful bid, to establish the service. This implies that the SPA is capable of finding its default NPA that can provide the network service.
· Interface to Customer Care Systems
The SPA shall be able to interface with the customer care systems in order to obtain information essential for its negotiation with the PCA. For example, the SPA is able to collect information about the requesting user for purposes of billing.
· Availability of Service Management Information (Optional)
The SPA may be able to request and handle on-line and real-time service management information made available by the CCS of the service provider to support the fault tolerance aspects of the agents. For example, the SPA is able to produce information about the current status of the service upon request from a PCA.
· Online Billing (Optional)
The SPA may be able to request and handle on-line and real-time billing information made available by the Service Provider. For example, the SPA is able to produce information about the running cost of the service upon request from a PCA.
2.4.5 Requirements for the NPA
· Interface to Third-Party NPAs
The NPA shall be able to interface with third-party NPAs in order to establish the service that has been agreed upon with the SPA. This implies that the NPA is capable of finding third-party NPAs that can provide the network service in case the NPA cannot provide the network service itself. For example, an NPA is able to set up a connection between terminating points in the network using third-party network services.
· Interface to Network Management Systems
The NPA shall be able to interface with the NMS of the network provider in order to establish and maintain the network service that has been agreed upon with the SPA. For example, an NPA is able to set up a connection between terminating points in the network.
· Ability to Handle NPA Requests
The NPA shall be able to handle a request from another NPA to establish a connection to a termination point in its network.
3 Scenarios
This section explores the scenarios of the dynamic VPN service provisioning, using a use case approach. Figure 2 illustrates the agents in the system and the key scenarios involved in the dynamic VPN provisioning application. The following sections illustrate the required interactions of the agents in each of these scenarios (each scenario draws on the FIPA-VPN-Provisioning ontology from section 5, Virtual Public Network Provisioning Ontology)
Unless otherwise stated, the cardinality of an agent in the scenario is considered to be one. If the scenario suggests that potentially many agents of a particular type should take part in the dialogue, it is envisaged that the initiating agent composes separate ACL messages for each of the required destination agents.
Figure 2: Multimedia VPN Service Provisioning Use Case Diagram
3.1 Subscribe Scenario
This scenario illustrates how the initiating PCA negotiates with one or more SPAs with an aim to establish a VPN service which best meets its requirements (see Figure 3).
Figure 3: Service Subscription Collaboration
1. The initiating PCA sends a request service message to one or more SPAs:
(cfp
:sender
(agent-identifier
:name InitPCA@foo.com
:addresses (sequence iiop://foo.com/acc))
:receiver (set
(agent-identifier
:name SPA1@bar.com
:addresses (sequence iiop://bar.com/acc)))
:ontology FIPA-VPN-Provisioning
:protocol FIPA-Iterated-Contract-Net
:language FIPA-SL0
:content
((action
(agent-identifier
:name SPA1@bar.com
:addresses (sequence (iiop://bar.com/acc))
(establish
(service-description
:service-id Service1
:service-type VideoOnDemand
:user-ids (set User1 User2 User3)
:respond-by ...)))
true))
2. Each SPAs sends a service proposal message to the initiating PCA:
(propose
:sender
(agent-identifier
:name SPA1@bar.com
:addresses (sequence iiop://bar.com/acc))
:receiver (set
(agent-identifier
:name InitPCA@foo.com
:addresses (sequence iiop://foo.com/acc)))
:ontology FIPA-VPN-Provisioning
:protocol FIPA-Iterated-Contract-Net
:language FIPA-SL0
:content
((action
(agent-identifier
:name SPA1@bar.com
:addresses (sequence (iiop://bar.com/acc))
(establish
(service-description
:service-id Service1
:service-type VideoOnDemand
:user-ids (set User1 User2 User3)
:respond-by ...))
(establish
(service-description
:service-id Service1
:service-type VideoOnDemand
:user-ids (set User1 User2 User3)))
:reply-with ServiceOffer1)
3. The initiating PCA sends accept or reject proposal message to the SPAs: