Autodiscovery for virtual networks

The present invention facilitates automatic discovery of VPN-related information, which relates to the existence or association of VPNs as supported by provider edge devices in a core network. In particular, the Border Gateway Protocol (BGP) is used to facilitate the automatic discovery, and the provider edge devices are capable of subsequently and automatically triggering Label Distribution Protocol (LDP) processes to facilitate signaling over LDP sessions within the core network.

FIELD OF THE INVENTION

The present invention relates to communications, and in particular to automatically discovering the capabilities of elements supporting virtual private networks and information related thereto.

BACKGROUND OF THE INVENTION

With the advent of the Internet and other public networks, local area networks (LANs) can communicate with other LANs over these public networks to support communications involving data, voice, audio, or video. In an effort to minimize the complexity for devices on a LAN to communicate with devices on another LAN, the communications between the LANs are often supported by emulating the switching techniques employed by the LAN. In other words, the connections supported over the public network are configured to emulate a direct connection to the LAN. These emulated connections are generally referred to as Virtual Private Networks (VPNs), and may support various levels of security to ensure that only authorized users can access the network and that data being transferred cannot be intercepted.

The public network through which the LANs are connected will have numerous routers and switching devices that must be configured to support VPNs. As the network grows and the number of VPNs increases, the difficulty associated with properly updating the network elements to support the VPN grows exponentially. At this time, much of the configuration and provisioning of the network elements is done manually, wherein the network elements are individually provisioned using a command line interface to implement changes in the network or the VPNs that the network supports. As such, there is a need for an efficient and automatic way to update and configure the network elements to support the addition and extension of VPNs, as well as support network growth.

SUMMARY OF THE INVENTION

The present invention facilitates automatic discovery of VPN information, which relates to the existence or association of VPNs as supported by provider edge devices in a core network. In particular, the Border Gateway Protocol (BGP) is used to facilitate the subsequent and automatic discovery, and the provider edge devices are capable of automatically triggering Label Distribution Protocol (LDP) processes to facilitate signaling over LDP sessions within the core network. The VPN information may correspond to the creation of a virtual switching interface (VSI) at a remote provider edge device, and will include an identification for the corresponding VPN, as well as information needed by the receiving provider edge device to use LDP for signaling therebetween, directly or via a route reflector. BGP may also be used to allow the provider edge devices within the core network to negotiate capabilities.

Accordingly, BGP is used for automatically discovering the existence and associations of VPNs across the core network, wherein LDP processes may be automatically triggered as necessary upon completion of the automatic discovery or may be manually provisioned between each peer in a full mesh. The present invention greatly reduces the amount of manual entry of VPN information throughout the mesh formed for the VPN in the core network.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention provides a technique for allowing network devices to automatically configure themselves to support the creation, expansion, and deletion of Virtual Private Networks (VPNs). According to the communication environment10illustrated inFIG. 1, a core network12supports label-switched communications. At the edges of the core network12, provider edge devices (PE)16facilitate an interface to any number of other network entities or networks through customer edge devices (CE)14. In one embodiment, label-switched communications are provided between the provider edge devices16via numerous provider network devices (PN)18. In operation, the provider edge devices16provide an interface between the label-switched communications provided within the core network12and another communication technology supported by the customer edge devices14, such as Ethernet technology.

In one embodiment, the provider edge devices16and the provider network devices18cooperate to enable a Virtual Private Local Area Network (LAN) Switching (VPLS) network, which is capable of supporting VPN services among the various customer edge devices14. For each VPN supported by the core network12, a corresponding virtual switch interface (VSI) is implemented in the provider edge devices16, such that the VSI has a label-switched interface to support communications via the core network12and has another interface, such as an Ethernet interface, to facilitate communications with the customer edge devices14.

With reference toFIG. 2, a portion of the communication environment10is illustrated wherein there are two provider edge devices16(A and B), each having three VSIs supporting three different VPNs (A, B, and C) for corresponding customer edge devices14. In this configuration, the respective VSIs will be administered via a Label Distribution Protocol (LDP) session for VPN services (A, B, and C).

In one embodiment, the core network12provides a multi-protocol label-switching (MPLS) architecture, wherein the provider edge devices16may be label edge routers (LERs), and the provider network devices18within the core network12may be label switch routers (LSRs). In an MPLS architecture, labels are appended to data packets being transferred from one edge of the network to another. When packets enter an MPLS architecture, the LERs look at the destination of the packet and any other packet attributes and assign the packet a label. The LERs then assign the data packet to a corresponding label switch path (LSP)19by appending labels, and it is sent to a first LSR in the assigned LSP19. Each LSR along the LSP19will forward the data packet along the LSP19based on the topmost label, until the packet reaches a destination LER, which will remove the top label and route the packet to the appropriate customer edge device14or other appropriate endpoint based on an inner label format.

As the packets travel along the LSP19, the LSRs may simply monitor the label and forward the packet and labels untouched, or may replace the label with a new label to facilitate routing or switching along the LSP19. Each LSR will have routing tables based on the labels. Thus, LSPs19extend between LERs, which are identified by labels. The LERs assign, add, and remove labels as traffic enters or exits the MPLS architecture. The MPLS architecture allows the establishment of LSPs19to support numerous communication sessions among the customer edge devices14. Those skilled in the art will be familiar with the concepts of establishing LSPs19in an MPLS architecture, and in particular to using an LDP to assist in this process.

For supporting VPNs, each VPN will be associated with a VSI established at each of the provider edge devices16that is a party to the VPN. Between each of these provider edge devices16, LSPs19, or a mechanism to provide tunneling between the two provider edge devices16must be formed and VPN sessions may take place along these connections. Notably, multiple VPN advertisements may take place within any one LDP session. Any time a VPN is created to include a customer edge device14, the supporting provider edge devices16must be appropriately configured. Configuration includes the creation of a corresponding VSI in each provider edge device16that is a party to the VPN, and each provider edge device16must be made aware of all of the other provider edge devices16that are parties to the VPN. For example, each provider edge device16needs to be able to identify traffic associated with the VPN, as well as where to send traffic in the core network12for the associated VPN. Those skilled in the art will recognize how the sessions between the provider edge devices16are established using the LDP. The present invention relates to arming each of the provider edge devices16with the appropriate information to allow the establishment of the various sessions for VPNs using LDP in an automatic fashion, without requiring manual configuration of the provider edge devices16with all the necessary information associated with the VPNs or the VSIs used to support the VPNs.

The present invention uses the border gateway protocol (BGP) to communicate the presence and any necessary information to support the VPN to the affected provider edge devices16in an automatic fashion. Accordingly, when a VPN is created or extended, the present invention uses BGP to automatically distribute to the pertinent provider edge devices16the information necessary for LDP to establish LDP sessions. The information will generally include an identifier for the VPN, which can be associated with the appropriate VSI, as well as any next-hop information necessary for routing packets along an LSP19associated with the VPN, among other information deemed desirable. Further, various provider edge devices16may negotiate their respective capabilities prior to or during this configuration process. Each of the provider edge devices16will be configured to automatically trigger LDP operations after receiving the appropriate VPN information via the BGP sessions. The present invention is also applicable when a VPN is reduced or removed from the system.

The communication flow ofFIGS. 3A and 3Billustrates one embodiment wherein BGP is used to discover the capabilities and membership information for a VPN supported by the core network12in an automatic fashion, and wherein LDP sessions or other LDP processes are initiated automatically upon such discovery. In this embodiment, assume that each of the provider edge devices16initially negotiates its capabilities, such that each of the provider edge devices16knows how to best communicate with the other provider edge devices16. Notably, the capabilities of the various provider edge devices16as well as the provider network devices18may vary, and the respective sessions therebetween will vary accordingly. Initially, assume that provider edge devices16B,16C, and16D are already aware of each other and their respective capabilities. When a new provider edge device16A is associated with provider edge devices16(B, C, and D), an OPEN message is sent to each of the provider edge devices16(B, C, and D) from provider edge device16A to initiate the negotiation of their respective capabilities (steps100,102, and104). Each of provider edge devices16(B, C, and D) will respond appropriately (steps106,108, and110). This negotiation may require multiple communications back and forth between the various devices to fully negotiate the capabilities of each of the provider edge devices16. At the end of negotiations, each of the provider edge devices16will know the abilities of the other provider edge devices16and know how to best communicate with them. These negotiations take place using BGP, and the messages used to negotiate these capabilities may be sent directly between the provider edge devices16or to a route reflector, which will facilitate the communications between the provider edge devices16, as is understood in the art.

Once the capabilities are negotiated, assume that a VSI is created on provider edge device16A to support a VPN having ID=A (step112). The VSI will also be associated with information needed by other provider edge devices16to build LDP sessions for signaling, and information indicating where to route packets for such signaling. The information may include the next-hop addresses, and is generally referred to as a route target, which may be encoded using a version of the Internet Protocol (IP), such as versions4and5. When a VSI is created for a VPN, provider edge device16A will send VSI announcements to all the provider edge devices16(B, C, and D) that provider edge device16A is aware of, or to a select provider edge device16B known to support the VPN (or VSI). In the illustrated embodiment, the VSI announcements are sent to each of provider edge devices16(B, C, and D) using BGP, without knowledge of whether or not these provider edge devices16(B, C, and D) support the VPN associated with the newly created VSI (steps114,116, and118). Upon receipt of the VSI announcements, each of provider edge devices16(B, C, and D) will analyze an internal database to determine whether it has a matching VSI for the corresponding VPN (steps120,122, and124). In this case, there are no matches, as none of provider edge devices16(B, C, and D) has a VSI associated with VPN ID=A.

Next, assume that provider edge device16B creates a VSI for a VPN having ID=A, which is the same as the VSI created in provider edge device16A (step126). At this point, provider edge device16B will send VSI announcements to provider edge devices16A,16C, and16D (steps128,130, and132) using BGP. Provider edge device16A will analyze the VSI announcement and recognize that the VSI being created on provider edge device16B is the same as that previously created based on the VPN ID (VPN ID=A) (step134). As such, provider edge device16A will trigger LDP operation. In the meantime, provider edge devices16C and16D will analyze the VSI announcements and recognize that there are no matches for the VSI being created at provider edge device16B (steps136and138).

With reference back to provider edge device16A, a determination is first made to see if an LDP session with provider edge device16B has been created (step not shown). Assuming the LDP session has not been created, provider edge device16A will send a message to provider edge device16B to create an LDP session (step140), which will be acknowledged by provider edge device16B (step142). Notably, each provider edge device16will include a state machine, which will recognize the end of the automatic discovery session using BGP, and will trigger an LDP process. The LDP process may entail establishing an LDP session for use, if one does not already exist, or selecting an existing LDP session for use during label matching and further LDP processing.

At this point, an LDP session is established between provider edge devices16A and16B (step144), wherein signaling to facilitate packet communications between provider edge devices16A and16B using the VSIs associated with VPN ID=A is facilitated. Upon creation of the LDP session, provider edge device16B will send label mapping information to provider edge device16A (step146), which will in turn provide label mapping information to provider edge device16B (step148). The label mapping information will effectively provide labels to use when routing packets to the respective provider edge devices16during a communication session involving the VPN (VPN ID=A). The label mapping messages are provided using LDP in extended mode fashion. Notably, triggering of the LDP sessions in light of the VSI announcements is provided in an automatic fashion to facilitate the automatic transition from the discovery process provided using BGP.

At this point, assume that provider edge device16C creates a VSI for the VPN ID=A (step150) to indicate the customer edge device14associated with provider edge device16C is joining the VPN. As such, provider edge device16C will send VSI announcements indicating the creation of a VSI to provider edge devices16A,16B, and16D (steps152,154, and156) using BGP. Provider edge device16A will analyze the VSI announcement and recognize that the VSI created at provider edge device16C matches one already created, and thus, trigger the LDP process (step158). Assume that LDP sessions to support the LDP process are already in existence between provider edge devices16A and16C, as well as between provider edge devices16B and16C. According to the LDP process, a label mapping message is then provided to provider edge device16C (step160), which will respond by sending a label mapping message back to provider edge device16A (step162) using LDP. Thus, provider edge devices16A and16C have the respective label information for sending packets therebetween.

Similarly, provider edge device16B will recognize that it has a VSI corresponding to that created at provider edge device16C and will trigger the LDP process (step164). Provider edge devices16B and16C will then send corresponding label mapping messages back and forth to provide the respective labels for communicating between provider edge devices16B and16C (steps166and168). Provider edge device16D will analyze the VSI announcement and recognize that there is no VSI match (step170). At this point, LDP sessions exist among provider edge devices16A,16B, and16C, and call signaling for label-switched communications may take place in extended mode fashion using a mesh of virtual connections throughout the core network12.

Accordingly, the autodiscovery technique of the present invention uses BGP to provide the various provider edge devices16, as well as the provider network devices18, all the necessary information to keep track of the network topology, their respective capabilities, and the existence of VPNs or associated VSIs to allow LDP sessions to be established. With the use of the BGP sessions for automatic discovery of network changes associated with VPNs and the VSIs that support them, and the automatic triggering of LDP processes, there is no need to manually configure the affected provider edge devices16and provider network devices18. For BGP to facilitate the present invention, additional Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) will be defined to indicate that information pertaining to the creation of VSIs, their respective VPNs, or other VPLS information is present in the BGP message.

Turning now toFIG. 4, a provider edge device16, which may be implemented as a label edge router, is illustrated according to one embodiment of the present invention. The provider edge device16will include a control system20having memory22with sufficient software24to provide the functionality above. The control system20will cooperate with one or more core network interfaces26as well as local network interfaces28to allow communications over the core network12and to the customer edge devices14, respectively.