KR20070035502A - Methods and arrangements for connection determination in multi-domain virtual private network - Google Patents

Abstract

In a communication network having two or more interconnected domains, information about the VPN is collected in each domain by a push mechanism. The information about the VPN includes at least the domain ID of domains for which several VPNs are currently available. Domain VPN information is collected within each domain. This collection can be triggered by external events such as changes in VPN information. The provided domain VPN information is preferably spread to adjacent domains under the constraints of the SLA between domain operators. In a cascaded manner, the entire available domain VPN information is spread across all domains. Information gathered about the VPN is evaluated to find the appropriate connection path.

Communication network, virtual private network, domain, positive response message

Description

METHODS AND ARRANGEMENTS FOR CONNECTION DETERMINATION IN MULTI-DOMAIN VIRTUAL PRIVATE NETWORK}

FIELD OF THE INVENTION The present invention relates generally to virtual private networks in communication systems and, in particular, to the determination of appropriate connection paths to virtual private networks in multidomain communication systems.

The virtual private network (VPN) performs private communication using a public or private communication network. Typically, a company or other customer who wants to build a wide area network should have its own leased line between each node to provide connectivity. However, such a solution is generally expensive and inflexible. In the past few years, the concept of VPNs has evolved rapidly. VPNs provide a solution where communication networks are shared between many customers, but each customer's communication is virtually separated. VPN technology is often based on the idea of tunneling. Network tunneling involves establishing and maintaining a logical network connection. In this connection, the packet is encapsulated within some other base or carrier protocol. They are then transmitted between the VPN client and the server, ultimately decapsulating on the receiver side. Authentication and encryption help to provide security.

The number of network nodes forming a VPN is rapidly increasing, which tends to further complicate the network structure and topology. This is caused in part by increased traffic on the VPN and in part because the VPN is required to cover an ever-increasing geographic area. Today, a communication network is provided that provides a VPN with nodes across continents. However, the more nodes and the more traffic that can be transmitted, the more complicated the configuration of the VPN.

Typically, a VPN is created in accordance with an agreement between the network operator and the customer. The location, quality of service, and other conditions of the node are agreed, so that the programmer at the operator sets the configuration manually or by looking for a configuration aid tool. As communication networks become more complex, such configurations become more complex and time consuming. When configuring a connection across several domains, there are typically many optional connection paths. Information from several domains is then collected and compiled in an appropriate manner. Moreover, if the customer wants to modify his VPN, the whole procedure must be repeated.

Thus, a common problem with prior art solutions is that the communication network providing a virtual private network with wide geographic coverage and / or high traffic becomes very complex. Another problem is that the configuration of a new VPN or modification of an existing VPN is complicated and time consuming. A further problem is that communication resources of network operators covering narrower geographical areas are generally not available for wide area VPNs. Another problem is that time is consuming and complicated to collect and compile VPN information from different domains.

Accordingly, it is a general object of the present invention to provide a system and apparatus that not only improves the method of finding an appropriate connection path of a VPN, but also implements such a method. Another object of the present invention is to provide a method for finding a connection path to a VPN using one or more network domains. It is yet another object of the present invention to provide a method of finding a connection path for a VPN which is basically independent of the actual VPN technology used for the different domains. It is yet another object of the present invention to provide a method that enables optimal or near optimal configuration of a VPN.

This object is achieved by a method and an apparatus according to the appended claims. In general, information about a VPN within a communication network having two or more interconnected domains is collected in the first domain by a push mechanism. The information about the VPN includes at least the domain ID of domains for which different VPNs are currently available. Domain VPN information is collected for each domain. The preparation of the domain VPN information can be performed in various ways, for example centralized or distributed data collection, or by retrieving the stored data. The distributed VPN control node is, in certain embodiments, localized to the edge node of the domain. Domain VPN information is, in certain embodiments, collected from edge nodes of the domain. This can be done by manually extracting the broadcasted information from the edge node and requesting domain VPN information or a combination thereof from the edge node. This collection can be triggered by external events such as changes in VPN information. The provided domain VPN information is preferably spread to other domains under restrictions by SLAs between domain operators. In a preferred embodiment, domain VPN information is spread to neighboring domains, which modify their domain VPN information and also transmit the received VPN information to other neighboring domains. In this cascaded manner, the entire available domain VPN information is spread across all domains. Information gathered about the VPN is evaluated to find the appropriate connection path. In one embodiment, the evaluation according to the quality measurement is carried out so that the optimum connection path is selected accordingly. In a preferred embodiment, the evaluation is performed to configure all connection paths that exceed a predetermined threshold. Thereafter, a statistical assessment of the actual need can be performed after some initial operating time.

One important advantage according to the invention is to provide a simple and stable platform on which operators in different domains can cooperate. Domain VPN information is primarily useful for supporting VPN configurations for all domains of a multidomain system. The approach of the present invention provides a means by which an optimal or near optimal connection path can be reliably found according to the current domain state. The present invention is particularly well implemented in communication networks with relatively stable configurations and topologies.

The invention can be best understood with reference to the following description taken in conjunction with the accompanying drawings, together with other objects and advantages thereof.

1 is a schematic diagram of a multidomain communication network providing a virtual private network.

2A is a schematic diagram of VPN information collection according to an embodiment of the present invention.

2B-D is a schematic diagram of VPN information collection according to another embodiment of the present invention.

3A-D illustrate an embodiment of the invention of a VPN control node configuration in a domain.

4 is a schematic diagram of a VPN information transmission and connection request according to an embodiment of the present invention.

5 is a schematic diagram of an endless loop state when transmitting VPN information.

6A is a block diagram of one embodiment of a generic VPN control node in accordance with the present invention.

6B is a block diagram of another embodiment of a VPN control node in accordance with the present invention.

7 is a schematic diagram of a VPN configuration according to an embodiment of the present invention.

8 is a flow chart showing the main steps of an embodiment of the method according to the invention.

1 shows an embodiment of a generic VPN provider architecture 1. In this VPN provider structure, five VPN provider domains 10A-E are provided and attached to each other by interdomain data connections 12A-G. One operator may control one or more of these domains 10A-E, or all of these domains may be controlled by individual operators. The relationship between the domains 10A-E, that is, the control of the inter-domain data connections 12A-G, is typically adjusted in accordance with the accompanying operator agreement, eg, VPN Service Level Agreement (SLA). Each VPN provider domain 10A includes a VPN edge node 14 and a core node 16, which may or may not be aware of VPNs, but few of them have reference numbers. . The VPN edge node 14 is a node to which customer sites 20 of different customers are connected to different VPNs in the structure 1. VPN unaware node 16 is an intermediate node in the domain and is only used to transfer messages and data between VPN edge nodes 14. The customer does not know which VPN-aware node is used for communication. The only important issue is the initiation and termination of the VPN edge node 14. Thus, a VPN connected to a domain may be represented by a direct line between VPN edge nodes 14, although actual communication may take place through one or more VPN unrecognized nodes 16. In the remainder of this specification, the presence of a VPN-unaware node can generally be ignored, since the basic procedural steps according to the invention do not depend directly on the presence or absence of any VPN-aware node 16. Because it does not. However, in practical implementations, VPN-aware node 16 may be used to provide real connectivity.

The VPN provider domains 10A-E are connected to the data plane through the initiation and termination of the VPN border node 18, i.e., inter-domain data connections 12A-G in the VPN border node 18. VPN boundary node 18 may or may not also act as VPN edge node 14 at the same time. The customer site 20 is connected to one of the VPN edge nodes 14. At this time, the customer site 20 of the same customer may be connected by the VPN 22A-C through the VPN provider domain 10A-E. One customer may have a customer site 20 connected to multiple VPNs 22A-C. Also, although more than one customer site 20 may be connected to the same VPN edge node 14, not only will there be knowledge of the existence of other customer sites 20, but also the presence of a VPN to which other customer sites 20 are connected. .

In this embodiment, three VPNs 22A-C are shown. However, one of ordinary skill in the art will appreciate that the number of VPNs in an actual system is usually higher. The first VPN 22A, shown in broken lines, extends through three domains 10A, 10C, and 10D to connect the customer site 20 to all of these domains. The second VPN 22B shown in dashed lines extends through all domains 10A-E in this embodiment. Finally, the third VPN 22C shown in dashed dashed lines connects the customer site 20 only within the domain 10B. Each customer site 20 is unaware of the existence of any VPN as well as the presence of another customer's customer site 20, except that it is connected. In this way, the privacy character of the VPN is protected even though they all share the same basic communication resources. This is a scenario in which the present invention preferably works.

In this specification, various connections are discussed, namely interdomain connections, intradomain connections, user plane connections, control plane connections, overlay control connections, connections between nodes and user terminals, and the like. Throughout the description, it is assumed that these connections may be of some kind. The basic idea of the present invention is not related to the actual connection technology. This means that both wired and wireless technologies can be used for any of these connections. In particular, with regard to the use of a wireless connection, the user terminal may be a mobile to the edge node. Nodes in the domain can be mobile to other nodes. These domains may be mobile to one another.

Now consider that the new customer site 20 'is connected to the VPN edge node 14' in the domain 10E. If the customer site 20 'wants to connect to the VPN 22B, the procedure is probably relatively simple because the VPN 22B already exists in the domain 10E. The manual or automatic VPN reconfiguration procedure according to the prior art can be used, as well as mixing between them. However, if the new customer site 20 'wants to connect to the VPN 22A or 22C, the situation becomes more difficult. In the prior art, there is no general cross-domain VPN configuration procedure.

One basic idea of the present invention relates to the preparation of domain VPN information, including the VPN identity of VPNs available within each domain.

First, some examples illustrating how domain information can be collected are described. This is done in connection with Figures 2A-3D. At this time, the main idea of the present invention is as follows.

2A illustrates an embodiment of an initial phase of providing domain VPN information. Each VPN edge node 14 has stored information that reflects its current VPN configuration for at least any VPN with a customer site connected at a particular VPN edge node 14. In a particular embodiment, the VPN edge node 14 also has information about which customer is connected to the VPN edge node 14 and the associations between the current VPN and the customer site 20. In some embodiments, information such as VPN address space and address type (local or global), quality of VPN service class specified by requirements such as bandwidth, delay and jitter, and / or VPN settings, i.e., tunnel or filter Use is provided. In addition, information such as encryption characteristics, transparent layer characteristics, tunneling characteristics, and topology characteristics may be included. Moreover, the VPN border node 18 has stored information about the identity of the VPN provider domain to which it belongs.

According to one embodiment of the invention, domain VPN information stored in each VPN edge node 14 or at least a portion thereof is collected by each border node 18 in the same domain 10A-E. This is shown as an arrow in FIG. 2A, some of which are provided with reference numeral 24. In this way, collection domain node information for its domain is available at each VPN border node 18 of each domain 10A-E. One alternative to such communication is to use a communication protocol similar to Border Gateway Protocol (BGP) to spread all of the information across the domain without any specific knowledge that the information is needed. The border node can then pick up all the necessary information. This is an example of a push mechanism for distributing domain VPN information.

2B illustrates another embodiment for providing domain VPN information concentrated in one domain 10C. If the VPN border node 18 has stored information about which edge node 14 is provided to the same domain 10C, then the VPN border node 18 makes a simple request 23 to any VPN edge node 14. To return the domain node information 24 thereof. In the simplest form of requesting information, the request itself may be a query of which VPN the VPN edge node 14 is joined to, for example, not received by the domain interconnect 12F. In such a case, the acknowledgment message does not contain any information as such, but will implicitly convey the information of this particular VPN at that particular VPN edge node. This is an example of a push mechanism to distribute domain VPN information.

Domain VPN information can also be collected by different timings. One alternative is to collect such information continuously or at least regularly at the border node so that the information available is always updated. In such an embodiment, the information is preferably stored at the border node or any other node that can be retrieved from the border node, which is referenced in the embodiments described further below. Another alternative is that information collection is triggered by some event. This event may be, for example, a broadcast message from an edge node that has some kind of change or a request to find a particular VPN, as described above. If all edge nodes have knowledge of which border node is available in the domain, this information can also be sent directly to all border nodes when such a change occurs. If this information is retrieved to find a VPN when triggered by a request, the collected information may be limited to that VPN or may not necessarily need to be stored for later use.

2C illustrates an embodiment in which domain VPN information is collected in a centralized manner. A storage device 54 is provided for storing all domain VPN information 24 provided by the various edge nodes 14. Any functionality using such domain VPN information can retrieve this information from the central storage 54.

2D illustrates another embodiment based on centralized collection of domain VPN data. Here, the request 23 or other external signal can initiate the preparation of the VPN data 24 for the storage device 54. This request 23 does not necessarily have to emerge from the memory device 54 itself.

As an alternative to collecting domain VPN information among domain nodes, domain VPN information may instead be provided by retrieving data from data storage. This stored data may be provided, for example, as a result of a previous collection of data or from other cases according to the above procedure.

In the above-described embodiment, the preparation of data in the domain is performed by a plurality of border nodes or one node in direct combination with it. This situation is also illustrated in FIG. 3A. Here, one domain 10A in a multi-domain system is responsible for data traffic to and from other domains by data connections 12A and 12B. Perimeter node 18 includes means for collecting domain VPN information, in this particular embodiment, for example, in the form of software functionality within the processor of perimeter node 18. Domain VPN information may be stored in storage 54. Thus, the VPN control node 43, which collectively processes domain VPN information about the domain, is implemented in this particular embodiment as a distribution of local means 41 at all border nodes 18.

In FIG. 3B, another particular embodiment is shown. Here, the boundary node 18 includes the functional entity 41 included in the domain VPN information. However, the distributed VPN control node 43, in this particular embodiment, comprises means 41 for providing domain VPN information which is located in or associated with the boundary node 18 and the central database 54. do. In the central database 54, actual updated, preferably historical VPN information is stored.

In FIG. 3C, another particular embodiment is shown. The VPN control node 43 here comprises a centralized, means 41 for providing domain VPN information and a central database 54 provided at essentially the same location. In this particular embodiment, the boundary node 18 is used to handle only communication 45 between the VPN control node and the neighboring domains. The functionality within the boundary node 18 regarding the transmission of control signals related to the actual data traffic may be used to signal control messages about the VPN configuration in this way as well.

In FIG. 3D, an embodiment is shown having a VPN control node 43 that is virtually separated from the edge node in the system. In such an embodiment, the VPN control node 43 is connected to a VPN control node in another domain by a dedicated VPN control signal connection 47 that creates its high level network.

In certain embodiments of the invention, provided domain VPN information may be conveyed within this system, ie between different domains. This is shown in FIG. The first step is to prepare VPN information within each domain. This is done by the VPN control node 43 in each domain. However, the configuration of the VPN control node 43 may be different between different domains. In FIG. 4, domain 10A has a VPN control node 43 similar to the example shown in FIG. 3A, and domain 10C has a VPN control node 43 similar to the example shown in FIG. 3B, and the domain ( 10B, 10D and 10E are shown to have a VPN control node 43 similar to the example shown in FIG. 3C. According to each SLA that regulates traffic between different domains, at least some of the available domain VPN information in each VPN control node 43 is forwarded to a counteracting VPN control node in a neighboring domain in this embodiment. Arrows 28 indicate the transfer of information between these domains. The SLA may include an agreement about how much available information is made available to neighboring domains. In the general case, the VPN control node processes the available intradomain VPN information into compiled or processed VPN information, which is appropriate for sending to neighboring domains. If these domains are closely related, eg belong to the same operator, the SLA is entirely transparent when exchanging domain VPN information. In other cases, the processed information 28 passed between the VPN control nodes 43 may be compiled VPN information and represents only very basic facts about the individual domain VPNs. In this embodiment, the information that needs to be transmitted via the interdomain connections 12A-G includes at least the identity of the VPN available somewhere beyond the boundary node transmitting the information.

According to the invention, the information about the VPN includes at least the domain ID of the domain for which the VPN is currently available. Preferably, the information about the VPN also includes additional data such as the nature of the VPN, the link quality of the link currently used by the VPN, the link quality of the link available to extend the VPN, the node ID of the node where the VPN is available. And information about which domains the VPN should be relayed to reach available domains. Characteristics of the VPN may include, for example, quality of service characteristics, encryption characteristics, transparent layer characteristics, tunneling characteristics, and topology characteristics.

In FIG. 4, the information 28 transmitted on the interdomain connections 12A-G updates the overall VPN information situation available at the receiving VPN control node. This VPN control node now has information of any VPN, for example, available through inter-domain connections. If more thorough information is available, the VPN control node can also determine which of these different VPNs are available, such as edge node identity, VPN quality of service, and the like. The VPN information so obtained is a characteristic of the neighboring domain and, if allowed by the SLA, can be used for activity within that domain. The information stored in the storage device 54 of the VPN control node 43 is the same as the information received from the neighboring domain or its processed version of adding, removing or modifying the received information. For example, this information is labeled with an indication from any domain created.

This information distribution can continue in some cases in many successive steps of applying further modification of the information before being sent to another domain, similar to the first delivery. Ultimately, all VPN control nodes of the overall VPN provider structure have at least processed versions of all domain VPN information available within the system. At each VPN control node, the information can be processed according to the SLAs valid for the relevant inter-domain connections used.

The exchange of domain VPN information may be performed at different timings. One alternative is to exchange such information continuously or at least regularly so that the information available is always updated. In such an embodiment, the information is preferably stored in the VPN control node or any other node retrievable by the VPN control node. In other words, this alternative is a conventional push mechanism for data distribution.

Another alternative is that the information exchange is triggered by some event. This event is, for example, that some kind of change occurred within one domain.

In a preferred embodiment, the spread of VPN information is also associated with an acknowledgment procedure. When a domain receives VPN information from an adjacent domain, an acknowledgment message is returned to notify the domain that this information provides VPN information available within the domain. Preferably, the received acknowledgment associated with the transmitted VPN information is sent to the domain where the VPN information has reached the first place. In other words, the VPN information is sent in one direction and the corresponding acknowledgment message is sent in return.

Now consider the connection of the new customer site 20 'to the edge node 14' which is connected to a VPN. The control node 43 identifies that the new customer site 20 'is connected to determine which VPN is intended. According to the present invention, means are provided for finding information about the intended VPN according to a quality measure of finding an appropriate connection path.

When the VPN control node 43 initiates a VPN connection request, it compares the required VPN with the stored information about the VPNs available through the interdomain connection. Information about which domain the VPN resides in is available via any inter-domain connection that the VPN can reach. In FIG. 4, the required VPN is the VPN 22A of FIG. VPN control node 43 in domain 10E has information about VPN 22A available through border node 18: 1 along two different paths. One alternative to reaching the VPN 22A is through an interdomain connection 12D, a domain 10B and an interdomain connection 12A. VPN 22A then resides in domain 10A. Another alternative to reaching the VPN 22A is through an interdomain connection 12D, a domain 10B and an interdomain connection 12C. VPN 22A then resides in domain 10C. However, the VPN control node 43 of the domain 10E also has information about the VPN 22A via other border nodes 18. Here, the required VPN 22A is reachable via the interdomain connection 12E, because the VPN 22A is available in the domain 10C. Finally, the required VPN 22A is reachable via the interdomain connection 12G because the VPN 22A is also available in the domain 10D.

Information on how the different domains are connected to each other should be provided when analyzing possible connections. This information can be obtained in many different ways. Since the present invention operates most efficiently within a system with a relatively stable configuration, it is assumed that a "map" of multiple domains and inter-domain connections is spread across multiple domains.

Thus, the VPN control node 43 has all the necessary information to find the required VPN. The VPN control node 43 evaluates the available information about the requested VPN by determining a quality measure for each possible connection path. Such quality measures may include, for example, the number of new links established, the number of domains that pass through before reaching the required VPN, how centrally the nodes on which the VPN is reached are located within the required VPN, and the services of the established links. It may be based on the minimum quality of a characteristic. In this example, the route through the inter-domain connection 12E seems to be the simplest to use, but, for example, the level of quality of service available may change this decision.

The process of finding an appropriate connection path can be implemented according to several principles. One possibility is to have an acceptance threshold, and only access paths with quality measures that exceed this acceptance threshold will be considered. For the remaining appropriate connection paths, one can choose to have the highest quality measurement configured. It is also possible to select one or more connection paths to be constructed, in extreme cases all accepted connection candidates.

In the present invention, the provided domain VPN information is spread to all VPN control nodes 43 of the entire system 1. In this way, the request to find an appropriate VPN can be executed directly to the VPN control node 43 of the "home" domain. As discussed above, the preparation and exchange of VPN information can be continuous, executed regularly or triggered by the request itself.

This approach has the drawback that the entire system 1 must be updated at every single VPN control node 43. However, in a system where the structure of the domain and the VPN is considerably stable, the communication effort required to update the VPN control node 43 is relatively low.

In the process of spreading VPN information through the system, there is preferably a restriction on further transmission of the received information. In FIG. 5, a potentially dangerous condition is shown in an infinite loop of VPN information preparation. The communication network 1 includes five domains 10A-E. In domain 10E, VPN 22A is available. Now consider the state in which the VPN 22A changes in some way, such as how the intradomain connection is upgraded to support higher bandwidth. Domain 10E performs an internal update of the VPN information, sending the updated VPN information to its single adjacent domain. Domain 10A updates its own database to send VPN information to domain 10B.

In addition, in the domain 10B, information about the VPN 22A is updated. The update information is then sent to other adjacent domains 10C and 10D. This procedure is repeated in these domains so that another transfer of VPN information is performed. Domain 10C transmits this information to domain 10D, and domain 10D transmits the same information to domain 10C. This procedure continues, and an infinite loop of VPN information will cycle between domains 10B-D. In a preferred embodiment of the present invention, means are provided for preventing information requests from being sent in an infinite loop. Such means for prohibiting looping of information requests is preferably provided in connection with the transmission or reception of such information requests. That is, they are arranged to prohibit actual transmission to a new neighboring domain or to prohibit acceptance of a received information request. Several embodiments are possible that impose limits on transmission. Some of them are briefly described below.

In one embodiment of the loop inhibiting device, each VPN information message includes an identity. This identity can be, for example, a separate field with some unique identity number or based on the actual information it carries. If the individual identity of the VPN information message is used, then the received and accepted VPN information message is preferably stored in the storage device. When a new VPN information message arrives, a comparison is made with the stored data to indicate whether the information request has already been received before. In this case, this request is ignored. Otherwise, this request is accepted and the identity is added to the storage device.

This comparison is also performed in relation to the actual transmission of VPN information. In such a case, the message identity is stored in storage and the extra condition for sending this request is that there should not be two identical message identities in the database.

If the identity is based on the VPN information itself, the received VPN information is compared with the corresponding VPN information currently stored in the domain. If the VPN information does not make any changes, the received VPN information is regarded as a duplicate message and is rejected. In such a device, only a true update is sent.

Another embodiment for loop inhibition is based on information about the transmission path. By adding the information in the VPN information message about which domain is passed during the transmission process, the receiving domain can easily search for its identity among the information. If your identity exists, the information is ignored. Otherwise, his identity is added and information can be transmitted. Also, comparison can be made at the transmitting side. Before sending the VPN information message to the domain, the sending domain retrieves the transmission path information for the identity of the adjacent domain. In the case of a domain that already exists in the transmission path, the transmission is prohibited.

Another embodiment is based on lifetime. For example, by fixing the validity expiration time, a certain lifetime can be set when performing the original VPN information update. Upon receipt and / or transmission of such information, this validity expiration time is checked, for example against system time, and if this validity expires, no further transmission is performed. The variation in the lifetime concept is to set the remaining lifetime shortened on the connection for each transmission. When the remaining life expires, no further transmission is performed. This approach can then also be utilized utilizing the number of transmissions as a measure of "time". That is, the maximum number of transmissions is specified from the allowed initialization. For each transmission, the remaining number is reduced by one unit.

6A shows a block diagram of a particular embodiment of a relatively general VPN control node 43 in accordance with the present invention providing an access path determining apparatus. The VPN control node 43 includes means 52 for providing domain VPN information. This information may be provided by the connection 62 by other nodes in the domain. The main control communication interface 40 is provided for communication with other domains. This interface 40 may be disposed with an intradomain connection 62. An evaluation unit 49 is provided that checks whether the identity of the required VPN matches the domain VPN information. The evaluation unit 49 is further arranged to carry out the above-mentioned evaluation of the information about the required VPN according to the quality measurement for finding an appropriate connection path. The VPN request may be received from another node in its domain or may be initiated within the VPN control node. The external VPN processing portion 44 is responsible for handling the cross domain VPN configuration. External VPN processing portion 44 includes means 71 for spreading information about VPNs available in its domain to adjacent domains. External VPN processing portion 44 includes means 73 for receiving information about the VPN from adjacent domains, and means 72 for distributing information based on the received information about the VPN from adjacent domains to other adjacent domains. It includes more. The means 71-73, in particular the means 71-72, may preferably be arranged in an integrated manner, since there is the functionality of many common parts of the different means. However, in other embodiments, separate units may be provided. The internal VPN processing portion 41 has the functionality for configuring internal connections in its domain, and preferably means for collecting information about VPNs available in its domain, i.e. providing domain VPN information. And means 52.

6B is a block diagram of another particular embodiment of a VPN control node 43 in accordance with the present invention. Domain VPN information about its domain is provided by an internal VPN processing portion 41, which includes means 52 for collecting information about the VPN. In this particular embodiment, internal domain VPN information is stored in data memory 74. In this particular embodiment, as shown by arrow 62, this information is provided by communicating with other nodes in this domain. In other embodiments, this information may be obtained in other ways. Internal domain VPN information is also sent to the entire VPN information database 54 within the external VPN processing portion 44. The internal VPN processing portion 41 also includes an internal configuration machine 46 having the functionality to configure internal connections in its domain. The internal VPN processing portion 41 includes not only the internal domain VPN information, but also information from the database 54. Thus, communication regarding the internal domain problem is executed through the connection 42 between the internal VPN processing portion 41 and the external VPN processing portion 44.

The VPN control node 43 has a main control communication interface 40 with different domains through inter-domain connections. Domain VPN information from another domain is received by the interface 40, and the input processing unit 56 extracts useful information from the received data, and stores this external information in the input database 58. In this input database 58, additional information from any domain from which external data is received is also stored. In this embodiment, input processing unit 56 and input database 58 are included in means 73 for receiving information about the VPN from an adjacent domain. The input database 58 updates the entire VPN information database 54 as appropriate. The external VPN processing portion 44 also includes an external configuration machine 60 with the functionality that forms part of the inter-domain connection with respect to the domain. This functionality will be described in more detail below.

External VPN processing portion 44 also provides information to other domains. Domain VPN information associated with its domain and / or other domains is extracted from the database 54 and provided to the output data processing unit 50. The retrieved information is processed according to SLAs associated with different neighboring domains and stored in the output database 48. By this, the SLA determines what information is allowed to spread to different neighboring domains. Closely related domain operators may consider more transparent information exchange, while domains belonging to unrelated operators may use more restrictive information exchange. Information about the VPN is transmitted on the interface 40 when appropriate. In this embodiment, the database 54, the output data processing unit 50, and the output database 48 spread information about VPNs available in their domains, based on the received information about VPNs from adjacent domains. It is included in the common unit 71, 72 which distributes the information.

The example shown in FIG. 7 illustrates how the configuration of a cross-domain VPN can be automated. The new customer site 20 'in domain 10E is connected to VPN 22A. VPN tunnels are assumed to be used for VPN connections within and between domains. The following steps are taken.

The VPN control node in the domain 10E, in some way, obtains the request from the customer to connect to the VPN 22A. Since the VPN database of domain 10E indicates that VPN 22A is not present in domain 10E, the VPN control node of domain 10E is responsible for sending the customer site 20 'to VPN 22A in domain 10E. You cannot access directly. However, VPN information generated from other domains is available, indicating that a connection path to VPN 22A can be found at "nexthop" 10B, 10C and 10D.

The VPN control node of the domain 10E selects to establish a VPN only through the "nexthop" 10B according to the above-described evaluation of the quality measure. It is a VPN tunnel to the VPN 22A, from the edge node 14 'to which the customer site 20' is connected, to the border node 18: 1 connected to the domain 10B via the link 12D. (71) is set. The VPN control node in the domain 10E initiates communication with the VPN control node in the domain 10B and connects the VPN tunnel 72 to the VPN 22A via the link 12D to the edge node 18: 2. Set.

The VPN control node of domain 10B establishes a VPN through "nexthop" 10A. It is the VPN 22A from the boundary node 18: 2 connected to the domain 10B via the link 12D to the boundary node 18: 3 connected to the domain 10A via the link 12A. Establish a VPN relay tunnel 73 for. The VPN control node in the domain 10B initiates communication with the control node in the domain 10A and establishes a VPN tunnel 74 through the link 12A to the border node 18: 4. Since the VPN 22A exists in the domain 10A, the control node of the domain 10A is connected to the VPN 22A at the border node connected to the domain 10B via the link 12A. The inner tunnel 75 can be set up to: 5).

After each step, the updated VPN database will be available for the next round of collecting VPN information.

The basic steps of an embodiment of the method according to the invention are shown in FIG. 8. The procedure begins in step 200. In step 210, information about VPNs available in each domain is collected in each domain. In step 212, information about the VPN is spread to adjacent domains. In step 214, information about the VPN is received from an adjacent domain. With or without any intermediate processing, at step 216, information based on the received information about the VPN from the adjacent domain is distributed to other adjacent domains. From the overall information about the VPN, in step 218, an evaluation of the quality measure is made to find the appropriate connection path. This procedure ends at step 299.

The above-described embodiments can be understood as some illustrative examples of the invention. Those skilled in the art will appreciate that many modifications, combinations and variations of these embodiments can be made within the scope of the invention. In particular, the various parts of the solutions in the various embodiments can be combined in other configurations that are technically possible. However, the scope of the present invention is defined by the appended claims.

Claims (18)

A method for determining a connection path of a multidomain virtual private network (VPN) in a communication network having two or more interconnected domains between a first node in a first domain and a first multidomain virtual private network (VPN). In each domain, collecting information about VPNs available within each domain; Spreading information about the VPN to an adjacent domain; Receiving information about a VPN from an adjacent domain; Distributing information based on the received information about the VPN from the adjacent domain to other adjacent domains, wherein the information about the VPN includes at least a domain ID of a domain for which a VPN is currently available; Evaluating information about the first VPN according to a quality measure for finding an appropriate connection path between the first node and the first VPN in the first domain. The method of claim 1, Wherein said spreading step is executed toward all adjacent domains, and said distributing step is executed toward all adjacent domains except adjacent domains that provide received information about the VPN. The method according to claim 1 or 2, At least one of the spreading step and the spreading step is performed regularly. The method according to claim 1 or 2, At least one of the spreading step and the spreading step is executed when triggered by an event. The method of claim 4, wherein And the event is a change of information about VPNs available in each of the domains. The method of claim 4, wherein And the event is the reception of information about a VPN from an adjacent domain. The method according to any one of claims 1 to 6, Returning an acknowledgment message to an adjacent domain from which information about the VPN is obtained; Receiving an acknowledgment message from an adjacent domain; And sending a received acknowledgment message for distributed information based on the received information about the VPN from the adjacent domain to the adjacent domain where the information about the VPN has been received. . The method according to any one of claims 1 to 7, Inhibiting transmission of information about the VPN in an endless loop in the communication network. The method of claim 8, And said prohibiting step is performed before distributing information about VPN to adjacent domains. The method of claim 8, And said prohibiting step is performed before accepting received information about VPN from another domain. The method according to any one of claims 8 to 10, And said prohibiting step is based on a comparison between currently received information about the VPN and stored data representing information initially received about the VPN. The method according to any one of claims 8 to 10, And said prohibiting step is based on a comparison between the domain identity and the domain through which the received information about the VPN has passed and which is included in the information about the VPN. The method according to any one of claims 8 to 10, And said prohibiting step is based on the lifetime of the information about the VPN. The method according to any one of claims 1 to 13, The information about the VPN, A characteristic of the first VPN; Link quality of a link currently used by the first VPN; Link quality of a link available for extending the first VPN; A node ID of a node for which the VPN is available; And at least one of information about any domain that the VPN relays to reach an available domain. The method of claim 14, Characteristics of the first VPN, Quality of service characteristics; Encryption characteristics; Transparent layer properties; Tunneling characteristics; And at least one of the topological characteristics. A communication network domain device, comprising: Means for gathering information about a virtual private network (VPN) available in the domain of the communication network domain device; Means for spreading information about the VPN to adjacent domains in a communication network having two or more domains; Means for receiving information about a VPN from an adjacent domain in the communication network; Means for distributing information based on received information about the VPN from the adjacent domain to other adjacent domains, wherein the information about the first VPN includes at least a domain ID of a domain for which the VPN is currently available; And means for evaluating information about the VPN according to a quality measure for finding an appropriate connection path from a node of the domain to a first VPN. The method of claim 16, The spreading means is configured to spread the information about the VPN to all adjacent domains, and the distributing means is configured to distribute the received information about the VPN to all adjacent domains except the adjacent domain that provides the received information about the VPN. And a communication network domain device. The method according to claim 16 or 17, Means for returning an acknowledgment message to an adjacent domain from which information about the VPN is obtained; Means for receiving an acknowledgment message from an adjacent domain; And means for sending a received acknowledgment message for distributed information based on the received information about the VPN from the adjacent domain to the adjacent domain where the information about the VPN has been received.

Images