WO2007048185A1

WO2007048185A1 - A method and system for facilitating the formation of a networked collaborative environment

Info

Publication number: WO2007048185A1
Application number: PCT/AU2006/001585
Authority: WO
Inventors: Jonathan Chan-Lon Chan; Peter Glynn Rogers; Darwin Agahari
Original assignee: Commonwealth Scientific and Industrial Research Organization CSIRO
Current assignee: Commonwealth Scientific and Industrial Research Organization CSIRO
Priority date: 2005-10-26
Filing date: 2006-10-26
Publication date: 2007-05-03
Anticipated expiration: 2008-04-26

Abstract

The present invention relates to a system and method for facilitating the formation of a Networked Collaborative Environment between a number of participants. People in companies often wish to form relationships, so as to participate in virtual enterprise, for example, which may require each participant to have access to a limited amount of each others resources. The present invention provides a system which enables participants to form a Networked Collaborative Environment, via a network infrastructure, in which each participant allocates resources (such as computing resources) to the collaborative environment. The system includes a device for receiving collaboration data from each of the participants, the collaboration data including data on the resources that they are allocating (including URLs, for example). The collaboration data is utilised by an engine which takes the data and configures a network to implement the supporting network functionality for the collaborative environment, including the resources contributed by the participants.

Description

A METHOD AND SYSTEM FOR FACILITATING THE FORMATION OF A NETWORKED COLLABORATIVE ENVIRONMENT

Field of the Invention

The present invention relates to a system and method for facilitating the formation of a Networked Collaborative Environment between a plurality of participants, and, more particularly, but not exclusively, to a system and method for implementing network functionality supporting Collaborative Contexts between participants in a virtual enterprise.

Background of the Invention

With more and more companies nowadays wishing to form relationships which may require companies to have access to at least a limited amount of each other's resources, there is an increasing requirement for the provision of network connections, such as extranets, which enable companies access to each other resources e.g. on a business to business basis. Organisations may wish to engage in a "virtual enterprise" where they may share resources for a particular project. A particular organisation may be involved at any one time in a number of different virtual enterprises with a number of different organisations (this is particularly so for large corporations) . The various virtual enterprises are distinct from each other and, where it is necessary for the participants to share resources to implement the virtual enterprises, it is important that the resources shared in a particular virtual enterprise are shielded or concealed from other virtual enterprises. At present, in order to implement any physical network connections supporting collaboration between enterprises, via a network infrastructure, requires active participation of a network provider. Each of the participants in a collaboration will discuss with each other and the network provider what features they wish to include in the supporting network functionality for the collaboration, such as a Virtual Private Network (VPN) and policy engine, and the provider must then configure the network infrastructure appropriately. Discussions between the participants and network provider tend to be ad hoc and as such can lead to an unsatisfactory outcome. A lot of administrative time and administrative contact is required to implement VPNs to support a collaboration, and this is clearly unsatisfactory.

There are a number of extranet products designed for business-to-business communications but these are generally application-specific, and require substantial support, such as proxies/agents and service templates that operate at the session level or above. Furthermore these extranet products appear to be aimed at quite specific scenarios where external clients or partners are brought into a defined corporate intranet and are allowed only limited visibility of the services on that intranet. Consequently these extra intranet products require considerable configuration particularly of the end host, which constitutes a significant maintenance overhead. Moreover, without the support of carrier grade network services (e.g. provider-provisioned virtual private network) these extranet products operate over the public Internet and are therefore vulnerable to well-known networking issues (i.e. security, latency, congestion and outages) . These products are therefore deemed unsuitable for mission critical dealings in the business-to-business environment. In any case, utilising such a product will still require ad hoc negotiation between participants and significant system knowledge to enable implementation. The evolving VPN technology in the Internet Engineering Taskforce (IETF) provides the basis for supporting extranets using carrier grade network services (e.g. based on recommendations RFC 2547 or the Virtual Router) . These recommendations, however, are still based on a provider-provisioned model, so that to implement a VPN would require significant network administrator intervention.

There is a need for an arrangement to ease the burden on participants and network providers in relation to setting up the network functionality to support user negotiated collaborations.

Summary of the Invention

In accordance with a first aspect, the present invention provides a device for facilitating the formation of a networked collaborative environment between a plurality of participants, via a network infrastructure, the device including a collaboration data receiving means arranged to be accessible by each of the participants to enable each participant to provide collaboration data to the collaboration data receiving means, the collaboration data representing a contribution to the networked collaborative environment by the respective participant, the collaboration data receiving means being arranged to provide the collaboration data to a networking configuration means which is arranged to utilise the collaboration data to configure the network infrastructure to support the networked collaborative environment, including the contributions by the participants.

A "networked collaborative environment" is defined to be an environment which supports collaboration between a plurality of participants, such as, for example, collaboration in a virtual enterprise.

The networked collaborative environment is supported by networking functionality (in one embodiment extranet functionality) . The device of the present invention advantageously facilitates the formation of the networked collaborative environment by enabling participants to "negotiate" resources to provide to the networked collaborative environment, and when the negotiation is complete, a network connecting those resources is implemented from the collaboration data which has been provided by the participants.

In one embodiment the device of the present invention supports the concept of (and enables implementation of) a "Collaborative Context" as a framework for defining service constructs, based on virtualisation techniques, within a virtual networking environment, to enable collaborating participants belonging to different competitive companies, to have collective provisioning capabilities for the purpose of contributing and negotiating selective resources (e.g. CPU, storage, data, computing machinery, end user) to create a virtual private enterprise for some mutual benefit. A Collaborative Context remains quite distinct from other Collaborative Contexts that a company may be involved in. In one embodiment, the collaboration data includes user resource data representing the resources that the participants intend to contribute to the networked collaborative environment. These may include computing devices, applications, and in one embodiment may also include users who may be associated with a participant organisation.

In one embodiment, resources may be designated at application granularity.

In one embodiment, the collaboration data receiving means is available on-line to computing systems of the participants. The collaboration data receiving means may be implemented by appropriate software and/or hardware which is arranged to interact with the participants and with the network. For interaction with the participants the collaboration data receiving means includes an electronic document which is presented to the participants. The document may be Web-based. In one embodiment, the formation of the networked collaborative environment involves the participants providing collaboration data to the collaboration data receiving means and each of the participants negotiating the collaboration data receiving means until agreement is reached. The agreed collaboration data receiving means is then utilised to implement networking functionality (e.g. an extranet) in the network infrastructure, supporting the networked collaborative environment.

This embodiment therefore has the advantage that participants are provided with a process by way of which they may make contributions to a collaboration and which does not require substantial (or, indeed, any) intervention by the network provider. The collaboration data receiving means is completed by the participants and then utilised by the networking configuration means to implement the supporting network.

In one embodiment, the participants do not need to have any knowledge of the underlying network infrastructure. The collaboration data is in terminology which is "high level" and does not require any skill or knowledge in network infrastructure . The high level terminology includes terminology enabling participants to designate resources to be allocated to the networked collaborative environment. In one embodiment, the terminology includes Universal Resource Identifiers (URIs) designating user resources such as computing systems, applications, processors and users. As the collaboration data receiving means is accessible by all participants, each of the participants may add and negotiate the various resources they are willing to contribute, utilising the collaboration data receiving means (which, as discussed above, in one embodiment is an electronic document) . Once all participants are satisfied with the resources being contributed, then they can ^wsign off" . Implementation of the network supporting the collaboration is then carried out without requiring any participant input.

An advantage of at least one embodiment is that a single collaboration data receiving means implements the corresponding networked collaborative environment. If the participants wish to enter other networked collaborative environments with other participants, then they will utilise other collaboration data receiving means, and therefore the networked collaborative environments will be isolated from each other. Even where a participant is involved in a number of networked collaborative environments, therefore, other participants will not know which particular environments they are involved in and which resources are allocated to those environments.

A further advantage of each participant having access to the collaboration data receiving means is that the networked collaborative environment is managed by the participants in a decentralised collective manner rather than being centrally managed (e.g. by network service providers) .

In one embodiment, amendments can be made to the collaboration data receiving means by one or more of the participants, and the amendments then implemented in the network infrastructure. Again, in this embodiment, this does not require the intervention of a network provider.

In one embodiment, the collaboration data is such as to be understandable by users who do not have any particular skills in configuring a network infrastructure. That is, the collaboration data provides a level of "abstraction" of network concepts. This enables end users without skill or knowledge of network infrastructure (e.g. they may not be network administrators) to be able to implement the networked collaborative environment. In this embodiment, the networking configuration means includes conversion means arranged to utilise the abstract collaboration data to provide network parameter values for implementation of the supporting network functionality.

In one embodiment_/ the network parameter values may include binding of each resource to a customer resource specification (e.g. host address information, etc) and network requirements (e.g. QoS descriptors, security parameters, routing attributes, start time, etc) .

In one embodiment, the system is arranged such that only participants of the networked collaborative environment are able to contribute collaboration data to the collaboration data receiving means. That is, no contributions are able to be made by other parties, such as the network provider. In this sense, the collaboration data receiving means is "controlled" by the participants of the networked collaborative environment. In one embodiment, the device of the present invention may be hosted by a network provider.

In one embodiment, the supporting network functionality is implemented via a network infrastructure, having an architecture comprising Provider Edge (PE) devices connected by Customer Edge (CE) devices. Such a network infrastructure may be implemented via a carrier grade network. In this embodiment, the networking configuration means is implemented by appropriate software/hardware in the PE device. Similarly, the collaboration data receiving means may be implemented by the PE device. Processes in the PE device are configured to implement the supporting network functionality.

In one embodiment, an end user may be specified as a resource contributed to the networked collaborative environment. In this embodiment, the supporting network may be implemented to enable the end user to enter a collaboration via a computing device which is not necessarily specified as a resource to the collaboration. In this embodiment, the computing device is "dynamically bound" to the collaboration, by virtue of the user being specified as a resource. The user may move from one machine to another without needing to renegotiate inclusion of any new machine in the networked collaborative environment.

Utilising the present invention, therefore, at least in one embodiment, participants can "on demand" negotiate resources to be contributed to a collaboration through "virtualisation functions" . Virtualisation functions introduce a level of abstraction among participants involved in a collaboration and between the participants and the underlying network infrastructure over which a collaboration operates. End resources therefore only need to relate to a virtual networking environment . A clean separation is therefore maintained between service provisioning and the network operations. The device can be used to implement any networked collaborative environment, and in particular can be used to support Collaborative Contexts for Virtual Enterprises .

In accordance with a second aspect, the present invention provides a system for facilitating the formation of a networked collaborative environment between a plurality of participants, the system including a device in accordance with the first aspect, and a networking configuration means which is arranged to utilise the collaboration data to configure a network infrastructure to implement the supporting network functionality for the networked collaborative environment, including the contributions by the participants.

In accordance with a third aspect, the present invention provides a method of forming a networked collaborative environment between a plurality of participants, via a network infrastructure, the method comprising the steps of each of the participants negotiating contributions of resources they each wish to make to the networked collaborative environment, by providing collaboration data representing their proposed contributions, to a device including a collaboration data receiving means which is accessible by each of the participants, and implementing the supporting network functionality for the networked collaborative environment, by configuring the network infrastructure, including the contributions by the participants.

In accordance with a fourth aspect, the present invention provides a method of facilitating formation of a networked collaborative environment between a plurality of participants, via a network infrastructure, including the steps of utilising a virtual networking environment including virtualisation functions that the participants can use to negotiate contributions that they will each make to the networked collaborative environment, the virtualisation functions being usable to configure a network infrastructure to implement the supporting network functionality for the networked collaborative environment, including the contributions by the participants. In one embodiment, the collaboration includes resources the participants wish to contribute to the networked collaborative environment, and the virtualisation functions include means arranged to designate the resources. The virtualisation functions may include a device in accordance with the first aspect of the present invention.

In accordance with a fifth aspect, the present invention provides an arrangement for facilitating formation of a networked collaborative environment between a plurality of participants, via a network infrastructure, the arrangement including virtualisation functions that the participants can utilise to negotiate contributions they will each make to the networked collaborative environment, the virtualisation functions being usable to configure a network infrastructure to implement supporting network functionality for the networked collaborative environment, including the contributions by the participants.

In accordance with a sixth aspect, the present invention provides a computer programme including instructions for controlling a computing system to implement a device in accordance with the first aspect of the present invention. In accordance with a seventh aspect, the present invention provides a computer readable medium providing a computer programme in accordance with the sixth aspect of the present invention. In accordance with an eighth aspect, the present invention provides a computer programme including instructions for controlling a computing system to implement a system in accordance with the second aspect of the present invention. In accordance with a ninth 'aspect, the present invention provides a computer readable medium providing a computer programme in accordance with the eighth aspect .

In accordance with a tenth aspect, the present invention provides a computer programme including instructions for controlling a computer system to implement an arrangement in accordance with the fifth aspect of the present invention.

In accordance with an eleventh aspect, the present invention provides a computer readable medium providing a computer programme in accordance with the tenth aspect of the present invention.

Brief Description of the Drawings

Features and advantages of the present invention will become apparent from the following description of embodiments thereof, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 is a schematic diagram of a network arranged to implement a system in accordance with an embodiment of the present invention; Figure 2 is a schematic diagram illustrating an architecture of a system in accordance with an embodiment of the present invention;

Figures 3 to 8 are schematic diagrams showing various stages in negotiation of an implementation of a networked collaborative environment in accordance with an embodiment of the present invention;

Figure 9 shows a schematic diagram of a implementation of the present invention where participants to the networked collaborative environment also have prior connectivity via an alternative network;

Figure 10 is a diagram illustrating a packet walk-through for an implementation of supporting network functionality for a networked collaborative environment, in accordance with an embodiment of the present invention; and

Figure 11 illustrates a process of "dynamic binding" of a further participant resource into the networked collaborative environment.

Detailed Description of Preferred Embodiments

The following description describes an embodiment of the present invention which is a system and process for implementing a networked collaborative environment between a plurality of participants who may be involved in a virtual enterprise, for example, and wish to operate in a Collaborative Context and contribute resources, e.g. computing resources, to the collaboration. It will be appreciated, however, that the invention is not limited to implementing a Collaborative Context, but is able to facilitate implementation of any networked collaborative environment which may require supporting communication network functionality.

The system of the present invention will be termed in the following description "VPXS" (Virtual Private extranet Service) . It will be understood that this is merely terminology and is not limiting to the invention.

In accordance with an embodiment of the present invention, a system for facilitating formation of a networked collaborative environment between a number of participants includes a collaboration data receiving means, which in this embodiment includes an electronic document, termed an "e-contract". The e-contract is hosted by a network provider, who, in this embodiment, is responsible for a carrier grade network. The e-contract is utilised by each of the participants to the networked collaborative environment to "negotiate" a Collaborative Context, by contributing resources which are entered into the e-contract. Once the e-contract is agreed by each of the parties, a networking configuration means, which in this embodiment is implemented by appropriate software and/or hardware in Provider Edge. (PE) devices, implements a supporting VPN and policy engine by configuring the carrier network appropriately.

An embodiment will now be described in more detail .

Network Reference Model

VPXS is embodied as a virtual network provisioning framework that in this embodiment operates over carrier grade networks. We refer to the owner of a carrier network as a network provider (i.e. similar to a Telco) . The VPXS architecture has adopted a notion from the IETF Layer 3 VPN reference model, namely, Provider Edge (PE) devices. It is assumed that a PE can serve multiple participants. Each participant may be a company and each company intranet connects to an identifiable interface of a PE via a customer edge (CE) device (see Figure 1) . The CE may be a layer 2 or 3 networking device, and company resources may connect directly to the CE or via some other layer 2 or 3 networking devices .

Depending on the demand for a Collaborative Context, the peering PEs instruct the underlying carrier network to establish traffic aggregates, known as PE tunnels.

Furthermore, multiple Collaborative Contexts share the same PE tunnel if they happen to go to the same peering PE. These PE tunnels may be realised as an MPLS label switched path (LSP) , a GMPLS tunnel, an IP-in-IP tunnel, a Virtual LAN (VLAN), etc.

Framework for Collaborative Context Provisioning

Referring to Figure 2, Collaborative Contexts in this embodiment shall be user-provisioned. The ability of this embodiment to enable end users to provision a Collaborative Context is a significant advantage. In this embodiment, participants don't require any particular skill or knowledge in networking but can still implement a Collaborative Context on-demand, the Collaborative Context incorporating the resources that the participants wish to contribute .

In this embodiment, a web application is utilised to provide the electronic document which forms the e-contract, to enable participants to specify, negotiate and provision the Collaborative Context. The virtualisation functions, which include the electronic document which forms the e-contract and which also include the networking configuration means which is arranged to implement the e-contract have a distributed design (implemented by software/hardware in each PE device) and therefore certain information needs to be exchanged between PE devices before a Collaborative Context is established.

At the top level, company public-information (e.g. company name, specialty, and contact details) is shared among all PEs, and therefore all companies have visibility of this information. This information is distributed by a service discovery process (e.g. peer-to-peer, yellow pages, etc) , so that the initiator of a collaboration can choose which companies should be invited into the Collaborative Context (see #1 in Figure 2) .

To create a Collaborative Context an initiator, (a) selects the companies to be involved and (b) nominates the identity of the end-user and application-resource (i.e. a type of Universal Resource Identifier - URI) within his own company to be used in the collaboration. The URI defines a finer granularity of forwarding operations for the Collaborative Context where the URIs form the basis of an e-contract. The e-contract is distributed to all peering PEs in the collaboration for the consideration of the other nominated participants (see #2 in Figure 2) .

Similarly, each collaborating company will also add collaboration data by nominating, exchanging and committing their URIs to be used in the collaboration. Since a URI is a representation of a company' s internal resource, it was not revealed during the prior exchange of company public-information (see #1 in Figure 2) , but it is nominated at this point by each collaborating participant from their own private-information repository. During the lifetime of a Collaborative Context, a URI may be dynamically added to or removed from the collaboration. This constitutes a change in the e-contract which is subsequently disseminated among all peering PEs for the approval of the other participants.

On the e-contract being 'approved' by all participants and subsequently reaching the ^λpre-active' status each peering PE translates its own URIs into (a) customer resource specification (e.g. host address, web services addressing information, etc.) and (b) generates required network parameters for the underlying extranet service (e.g. QoS descriptors, security parameters, routing attributes, start time, etc.) . Collectively, in this embodiment, this translated information forms part of the collaboration data, which also includes the data including the URIs which is entered into the e-contract during the negotiation phase.

The virtualisation functions facilitate the exchange and negotiation of collaboration data using a standardised protocol, for instance web services (#2 in Figure 2) . The virtualisation functions are a distributed set of software/hardware components that reside in each PE. The framework shown in Figure 2 has a number of key advantages for the deployment of new services that use the concept of Collaborative Contexts:

• The introduction of virtualisation functions to facilitate the exchange, negotiation and logging of those entities that define a specific business agreement . • A clean separation is maintained between service provisioning and the network operations . • New services may be introduced without needing to be concerned about the underlying network infrastructure .

• Web services standards may be used to provide the flexibility and extensibility required to support the introduction of new services. Without the benefits of the framework articulated above, the provisioning of extranet services would, based on current technologies, need to be embedded within some network level routing protocol such as BGP.

Referring to #3 of Figure 2, if not already created for any existing Collaborative Contexts, PE tunnels are constructed using a path setup protocol (e.g. RSVP-TE to establish an MPLS label switched path) . Since the establishment of a PE tunnel is instigated on-demand, by the virtualisation functions, a pre-configured full mesh topology between all PEs can be avoided.

Referring to #4 of Figure 2, the exchanged collaboration data is used by the PE for: • Invocation of exclusive forwarding operations on a per customer resource basis. Examples are, populating entries in (1) a policy routing mechanism with source/destination addresses or (2) a web switch with web services addressing information.

• Configuration of a VPN based on standardised technologies (e.g. RFC 2547, Carrier's Carrier, Virtual Router, etc.) .

The following is a detailed description of a preferred embodiment, for creating the VPN over which

Collaborative Context operates. The VPN technology is based on the IETF RFC2547 recommendation (BGP/MPLS VPNs) . Before the companies (^λb', and ^XC), shown in Figure 3, can form a Collaborative Context, company public-information (e.g. company name, specialty and contact details) must be made visible to other potential collaborators through a distributed service discovery process (e.g. peer-to-peer, yellow pages, etc) .

Referring to Figure 4, to create a Collaborative Context, an e-contract needs to be set up by the collaborating parties. The following procedures explain how this occurs :

#1. An initiator, say company ^xb' , needs to select other companies, in this case only ^λc', to join a collaboration. Based on company b's private-information, the initiator nominates the URIs within its own company to be used in the collaboration (e.g. the identity of the end-user, Bob@companyB.com, and the application resource, pcl.companyB.com). This constitutes the basis of a ^λ draft' status e-contract. It is assumed that each company's private-information is maintained by a PE prior to a Collaborative Context being set up. A person skilled in the art will appreciate how to populate the PE with this information. #2. Using the public-information provided by each company, PEl forwards the e-contract to all peering PEs of the collaboration (only PE2 in this case) . It is assumed that all invitees (only company ^λc' in this case) will know about the existence of the e-contract by means

(e.g. email, phone call, etc.) that are outside the scope of this invention. #3. All invitees who accept the invitation shall also nominate the URIs to be used in the collaboration (for company ^Λc', the identity of the end-user, Cath@companyC.com and the application resources, pc2.companyC.com and pc3. companyC . com) .

#4. The updates to the e-contract, by each invitee, are made visible to all the other invitees. If all invitees agree to join a Collaborative Context, the collective status of the e-contract changes from ^xdraft' to ^λ approved' . Before the 'approved' status is finalised, there may be several rounds of negotiation among all participants. This is necessary, for example, because during say the first round of negotiation, one invitee may choose to opt out, which gives the opportunity to other participants to reassess whether or not they wish to remain in or opt out of the collaboration, as influenced, for example, by changes in participants/resources (who is in/out and/or what resources are nominated/withdrawn) . All these negotiations are handled automatically by the virtualisation functions.

#5. On reaching the 'approved' status, the e-contract is committed for deployment by a nominated party (e.g. the initiator company) . At this point the status of the e-contract changes to 'pre-active' . This means that the

Collaborative Context is now ready to be deployed but the configuration of the underlying network is not yet invoked. #6. The ^λpre-active' status e-contract is sent to all the other participating PEs. #7. On receipt of a ^λpre-active' status e-contract, each participating PE (a) translates the URIs of their customers within the e-contract into customer resource specifications (for company B: pcl.companyB.com becomes IP address bl, etc.) and (b) generates required network parameters for the underlying VPN service (the route target attribute of RFC 2547 for this

Collaborative Context is ^xred' , etc.) . This information is added to the e-contract which is automatically updated and exchanged among all participating PEs. All company participants within a Collaborative Context have visibility of the ^λpre-active' status e-contract. A Collaborative Context is scheduled to commence either immediately or at a specified time in the future. Just prior to activation of the e-contract, the underlying network will be configured in accordance with the specifications of the Collaborative Context. Upon configuration of the network, the e-contract status is promoted from ^λpre-active' to ^active' . The following description explains how the underlying network is configured.

Referring to Figure 5, if not already created, for any existing Collaborative Contexts, PE tunnels are constructed as required using a standardised protocol (e.g. RSVP-TE) to establish MPLS label switched paths. Figure 5 shows new entries being populated in the MPLS forwarding table, held in the PEs, after two uni-directional MPLS label switched paths have been set up between PEl and PE2. Note that PE tunnels are intended to be shared among many Collaborative Contexts if they happen to go to the same peering PE. Furthermore, establishment of PE tunnels is a prerequisite for setting up a Layer 3 VPN over which a Collaborative Context operates. Referring to Figure 6, a BGP/MPLS VPN is configured for the Collaborative Context. The VPN is configured in accordance with the network requirements of the ^λpre-active' status e-contract. PEl creates, on a per Collaborative Context basis, a VPN Routing and Forwarding (VRF) table with certain attributes (for the VRF attributes in PEl: routing input interface = if_3 , route target and route distinguisher = red) that are used to control the population of routing information for the VPN. The VRF ^λred' table subsequently learns local customer routing information (for company B: subnet ^λbx' is cached and an inner label of 1001 is assigned to this interface) via an inter-gateway protocol such as OSPF. The MPLS forwarding table is also updated with label entry 1001. For the case shown in Figure 7, the Multi-Protocol Inter-Border Gateway Protocol (MP-IBGP) is used to import remote routing information into the PE's VRF ^λred' table from other peering PEs .

To enable a finer granularity of forwarding operation, as required for Collaborative Contexts, it is necessary to employ a 'policy engine' that applies policy routing and/or content switching functionality to steer customer inbound traffic to the appropriate VRF. Referring to Figure 8, the policy engine in PEl ensures that only packets from company ^λb' (via if_3 say) with source address bl and destination addresses cl2 or c21 go to the VRF red table. Note that inspection of both source and destination addresses is necessary because a customer resource may be involved in several collaborations at the same time. Namely, if a customer is involved in two concurrent collaborations the source address is the same but the destination addresses will be different, therefore the traffic of each collaboration will be steered to their own VRF.

A Collaborative Context's traffic is only routed among intranets via the PE tunnels. Consequently, this traffic must be directed by participating intranets to the associated PEs, which they achieve by learning remote intranet routing information. This requirement however, may impose some additional look-ups on the routers in the participating intranets. And as such consequential routing issues may arise, within these intranets, the complexity of which depends on the topology, connectivity and local administrative policies of the intranets. It is understood that various PE-intranet scenarios may exist in real life situations, but in general, matters peculiar to an intranet are outside the control of the VPXS service provider therefore routing issues which may arise in different PE-intranet scenarios will be implemented in accordance with the skilled addressee's skill and knowledge. We show below a few of the more likely PE-intranet scenarios.

Case 1 : Perhaps the simplest case is that no remote routing information for a VPN needs to be learned by an intranet. This means that all outbound intranet traffic goes via its associated PE. A policy engine in the PE classifies which traffic forwards into the PE tunnels and which traffic forwards into other connections (e.g. the Internet) . Case 2 : For this case it is assumed that prior to the introduction of VPXS, different company intranets have no connectivity (i.e. their subnet addresses are unreachable by each other) . Now VPXS is introduced into the network. In this case the remote subnet address of a destination intranet is learned by a local intranet through a standard routing protocol (e.g. OSPF) . As a consequence of this all outbound traffic with the destination intranet subnet address will be directed by the local intranet to its associated PE. However, only that portion of the traffic which fits a VPXS policy profile, held by the policy engine, will jbe admitted into a PB tunnel, and all out-of-profile traffic will be discarded by the PE. This practice of handling out-of-profile traffic by the PE is deemed acceptable because in a business-to-business environment, intranets of different companies have no access to each other's network. Therefore remote subnet addresses of other intranets are unreachable by local intranets and consequently any traffic with an unreachable address will be discarded upstream. This situation is no different from a local PE discarding out-of-profile traffic.

Case 3: For this case it is assumed that, before the introduction of VPXS, a remote intranet's subnet address is already reachable by a local intranet (e.g. company ^λJb' and ^λc' have prior connectivity via another network such as the Internet, see Figure 9) . Now with the introduction of VPXS, Collaborative Context traffic, between these already reachable intranets, needs to be directed from the intranets , into the PEs instead of some pre-existing connection. To achieve this, remote per host routing information needs to be learned by the local intranet's CE device and default gateway through a standard routing protocol (e.g. OSPF) . Preferably the CE device is the intranet's default gateway to avoid propagation of per host routing information throughout the intranet (see Figure 11) .

To summarise, Figure 10 shows a packet walk-through from a customer resource in company ^λc' to a customer resource in company ^xb' (i.e. from c21 to bl) , which invokes the functionality of, the policy engine in PE2 , the VRF table in PE2 and the MPLS forwarding in PEl. In addition, Figure 11 shows the dynamic binding of a customer resource into a Collaborative Context. This occurs when a previously nominated user registers from an end host to the associated PE (i.e. Cath in company ^λc' logs in from c22) . In the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express language or necessary implication, the word "comprise" or variations such as "comprises" or "comprising" is used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention. It will be appreciated by persons skilled in the art that numerous variations and/or modifications- may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1. A device for facilitating the formation of a networked collaborative environment between a plurality of participants, via a network infrastructure, the device comprising a collaboration data receiving means arranged to be accessible by each of the participants to enable each participant to provide collaboration data to the collaboration data receiving means, the collaboration data representing a contribution to the networked collaborative environment by the respective participant, the collaboration data receiving means being arranged to provide the collaboration data to a networking configuration means which is arranged to utilise the collaboration data to configure the network infrastructure to implement the supporting networking functionality for the networked collaborative environment, including the contributions by the participants.

2. A device in accordance with Claim 1, wherein the collaboration data comprises user resource data representing resources that the participants intend to contribute to the networked collaborative environment.

3. A device in accordance with Claim 2, wherein the user resource data is able to designate resources at host granularity.

4. A device in accordance with Claim 3 , wherein the user resource data is able to designate resources at application granularity.

5. A device in accordance with any one of the preceding claims, wherein the collaboration data receiving means includes an electronic document .

6. A device in accordance with Claim 5, wherein the electronic document is available on-line to computing systems of the participants.

7. A device in accordance with Claim 5, wherein the electronic document is Web based.

8. A device in accordance with any one of the preceding claims, wherein the collaboration data receiving means may be amended by one or more of the participants, any amendments being implemented in the network infrastructure .

9. A device in accordance with any one of the preceding claims, wherein the collaboration data may specify a user as a resource to be contributed to the networked collaborative environment.

10. A device in accordance with claim 9, wherein, when the networked collaborative environment has been implemented, any computing device that a user specified as a resource is using is automatically bound to the networked collaborative environment without the computing device necessarily having been previously designated as a resource in the collaboration data.

11. A device in accordance with any one of the preceding claims, wherein the collaboration data provides a level of abstraction which enables the participants to relate to a virtual networking environment .

12. A device in accordance with Claim 11, wherein the level of abstraction is such that the participants require no particular skill or knowledge of networking.

13. A device in accordance with any one of the preceding claims, wherein the collaboration data receiving means is arranged to receive collaboration data only from the participants .

14. A device in accordance with any one of the preceding claims, wherein the network infrastructure has an architecture comprising Provider Edge (PE) devices, and the collaboration data is arranged to provide instructions for the PE devices to configure the networked collaborative environment.

15. A device in accordance with any one of the preceding claims, wherein the collaboration data is arranged to provide a customer resource specification and network requirements for resources contributed to the networked collaborative environment by the participants.

16. A system for facilitating the formation of a networked collaborative environment between a plurality of participants, the system comprising a device in accordance with any one of Claims 1 to 15, and a networking configuration means which is arranged to utilise the collaboration data to configure a network infrastructure to implement the supporting networking functionality for the networked collaborative environment, including the contributions by the participants.

17, A system in accordance with Claim 16, wherein the networking configuration means comprises a conversion means arranged to utilise the collaboration data to provide network parameter values for implementation of the supporting networking functionality.

18. A system in accordance with Claim 16 or Claim 17, wherein the networking configuration means is arranged to provide customer resource specifications and network parameters for resources contributed to the networked collaborative environment by the participants, from the collaboration data.

19. A system in accordance with any one of Claims 16 to

18, wherein the network infrastructure has an architecture comprising Provider Edge (PE) devices, and the networking configuration means is implemented within the PE devices.

20. A system in accordance with any one of Claims 16 to

19, wherein the collaboration data may specify a user as a resource to be contributed to the networked collaborative environment, and the networking configuration means enables the user to access the collaboration regardless of the computing device they may be utilising.

21. A system in accordance with any one of Claims 16 to 20, wherein the networked collaborative environment enables communication between resources of host and application granularity, and the networking configuration means directs a policy engine which constrains network communications to the resources at host and application granularity.

22. A system in accordance with any one of Claims 16 to 21, wherein the network infrastructure is a carrier grade network and the networking configuration means directs the PE device to implement PE tunnels for support of VPNs.

23. A system in accordance with any one of Claims 16 to 22, the system being hosted by a provider of the network infrastructure .

24. A method of forming a networked collaborative environment between a plurality of participants, via a network infrastructure, the method comprising the steps of each of the participants negotiating contributions of resources they each wish to make to the networked collaborative environment, by providing collaboration data representing their proposed contributions, to a device including a collaboration data receiving means which is accessible by each of the participants, and implementing the supporting networking functionality for the networked collaborative environment, by configuring the network infrastructure, including the contributions by the participants.

25. A method in accordance with Claim 24, wherein the step of negotiating contributions comprises the steps of each of the participants adding their contributions to the collaboration data receiving means, and all of the participants confirming the collaboration data receiving means for implementation.

26. A method in accordance with Claim 24 or Claim 25, including the further step of one or more participants making an amendment to contributions to the collaboration data receiving means, the amendment subsequently being implemented by configuration of the network infrastructure .

27. A method in accordance with Claim 26, comprising the further step of requiring approval of the amendment by each of the parties, prior to implementation.

28. A method of facilitating formation of a networked collaborative environment between a plurality of participants, via a network infrastructure, comprising the steps of utilising a virtual networking environment including virtualisation functions that the participants can use to negotiate contributions they will each make to the networked collaborative environment, the virtualisation functions being usable to configure a network infrastructure to implement supporting networking functionality for the networked collaborative environment, including the contributions by the participants.

29. A method in accordance with Claim 28, wherein the contributions comprise resources the participants wish to contribute to the networked collaborative environment, and the virtualisation functions comprise means arranged to designate the resources.

30. A method in accordance with Claim 29, wherein the means comprise Universal Resource Identifiers (URI) .

31. A method in accordance with any one of Claims 28 to 30, wherein the virtualisation functions comprise a device in accordance with any one of Claims 1 to 15.

32. An arrangement for facilitating formation of a networked collaborative environment between a plurality of participants, via a network infrastructure, the arrangement comprising a virtual networking environment comprising virtualisation functions that the participants can utilise to negotiate contributions they will each make to the networked collaborative environment, the virtualisation functions being usable to configure a network infrastructure to implement the supporting networking functionality for the networked collaborative environment, including the contributions by the participants

33. An arrangement in accordance with Claim 32, wherein the contributions comprise resources the participants wish to contribute to the networked collaborative environment, and the virtualisation functions include means arranged to designate the resources .

34. An arrangement in accordance with Claim 33, wherein the means comprise Universal Resource Identifiers (URIs) .

35. An arrangement in accordance with any one of Claims 32 to 34, wherein the virtualisation functions comprise a device in accordance with any one of Claims 1 to 15.

36. A computer programme comprising instructions for controlling a computing system to implement a device in accordance with any one of Claims 1 to 15.

37. A computer readable medium providing a computer programme in accordance with Claim 36.

38. A computer programme comprising instructions for controlling a computer to implement a system in accordance with any one of Claims 16 to 23.

39. A computer readable medium providing a computer programme in accordance with Claim 38.

40. A computer program, comprising instructions for controlling a computer to implement an arrangement in accordance with any one of Claims 32 to 35.

41. A computer readable medium providing a computer program in accordance with Claim 40.