Functional decomposition of a router to support virtual private network (VPN) services

FIELD OF INVENTION

[0001] The present invention relates to virtual private network (VPN) services. More specifically, the present invention relates to routers for providing connectivity for customer sites subscribing to VPN services.

DESCRIPTION OF THE BACKGROUND ART

[0002] Two common approaches used to implement a service provider (SP) based IP-Virtual Private Network (IP-VPN) are Multi-Protocol Label Switching (MPLS) and “virtual routers” (VR). The MPLS approach is articulated in an Internet protocol proposal Request for Comment 2547 (RFC 2547) entitled “BGP/MPLS VPN'S”, E. Rosen and Y. Rekhter (and its 2nd version, RFC2547bis), which is rapidly gaining acceptance in the industry.

[0003] A basic requirement for a VPN service is that each IP VPN subscriber must be able to use its own private IP addressing scheme. Therefore, each service provider router (i.e.,“provider edge (PE)” router) needs to be able to route IP packets differently for different incoming data streams. This may require a different decision process for each data stream. Under the RFC 2547 architecture a single routing/forwarding table with “context” is created for each VPN site.

[0004] Routing tables are stored within each PE router and routes learned from an attached customer network router (i.e.,“customer edge (CE)” router) are populated in a VPN Routing Forwarding (VRF) table. All customer sites that share the same routing information and connected to the same location may be placed in a common VRF table, which is identified by a Route Distinguisher (RD). However, such sites are automatically able to communicate with other. RD assignment is the responsibility of the SP, and creating such VRF tables manually is cost prohibitive and not scaleable.

[0005] Further, assigning two sites with the same routing characteristics to the same VRF table may not be desirable in some instances. Specifically, if the two sites having the same characteristics are assigned to the same routing table, the two sites will automatically send packets to each other, which may be undesirable in some VPN configurations. To overcome the automatic sending of packets to sites assigned the same VRF table, a different VRF table may be assigned to each site. However, to do so would require more resources, which increases the operational costs and reduces the efficiency of the network.

SUMMARY OF THE INVENTION

[0006] The disadvantages heretofore associated with the prior art are overcome by a novel method and apparatus for generating ingress VPN Routing Forwarding (VRF) tables based on routing targets (RTs), as opposed to route distinguisher (RD) assignments, as provided under the RFC 2547 specification. As such, in instances where two sites are assigned to the same VRF table, the packets are no longer automatically sent between the sites, unless their respective import RTs match.

[0007] In particular, for each VPN at a customer site, the associated PE router is made up of hardware and/or software access modules that connect between a customer site and the PE router. The access modules are automatically generated at each PE router for each VPN. Specifically, customer sites associated with a particular VPN having an identical export route target (RT) values and import RT values are connected to a common access module, while customer sites associated with the PE router that do not have identical export and import RT values are coupled to their own respective access modules at the PE router. The PE routers advertise their RT values from their respective export RT lists to their peer routers.

[0008] Each access module has an associated ingress-forwarding table, which identifies other customer sites associated with the VPN, such that packets may be transported between the sites. That is, from a customer edge (CE) router at a local customer site to its local peer PE router, and then to either another customer site also connected to the same local PE router, or to a customer site that is coupled to a remote PE router.

[0009] In one embodiment where packets are sent to other PE routers, the advertised RT values from the peer PE routers are compared to an export RT list associated with the access module. In an instance where any RT values in the route advertisement of the peer PE routers having an identical RT values associated with the export RT list of the access module, an entry is created in the ingress-forwarding table of the access module.

[0010] In particular, the PE router will compare the import RT list and the export RT lists of an access module. If there is a common value between the two lists, locations connecting to the access module can send packets to each other. If there is no commonality of values between the two lists, the access module will not allow communications between the customer sites connecting to the access module, thereby overcoming the problem of two sites automatically sending packets to each other when both are assigned to the same VRF table.

[0011] In a second embodiment, packets may be sent from a first access module in a local PE router to a second access module in the same PE router. Specifically, the PE router compares the export RT lists of one access module with the import RT list of another access module (and vice versa) to determine whether one access module can forward packets to another access module in the same PE router.

[0012] In a third embodiment, packets may be sent to another customer site connected to the same access module. Specifically, the PE router compares the import and export lists of the common access module to determine whether packets can be forwarded to another from one customer site to another customer site connected to the common access module in the PE router. In any of the embodiments described above, the PE router advantageously generates the route distinguisher (RD) parameter, thereby relieving the user of the burden of assigning it to each customer location.

[0013] In accordance with an aspect of the invention, the same protocol for exchanging VPN information (BGP-MP), and the same encapsulation scheme for user data packets (double MPLS labels) as is used in RFC 2547, may be employed. Advantageously, doing so will ensure interoperability with existing RFC 2547 compliant routers. This is accomplished by using. In a network consisting entirely of routers using this invention, other functional equivalent protocol and encapsulation techniques may be used.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The teachings of the present invention can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:

[0015]
FIG. 1 depicts a high-level block diagram of an exemplary virtual private network (VPN) network suitable for implementing the present invention;

[0016]
FIG. 2 depicts a schematic diagram for transferring packets across the VPN network of FIG. 1;

[0017]
FIG. 3 depicts a schematic diagram of an exemplary VPN network 300 of the present invention;

[0018]
FIG. 4 depicts a block diagram of an exemplary router of the present invention suitable for use in the exemplary network of FIG. 3;

[0019]
FIG. 5 depicts a schematic diagram of an exemplary VPN network having two full VPN components;

[0020]
FIG. 6 depicts a schematic diagram illustrating physical connectivity of the network of FIG. 5;

[0021]
FIG. 7 depicts a high-level block diagram illustrating asset module allocation to support the VPN network of FIGS. 5 and 6;

[0022]
FIGS. 8A and 8b depict a schematic diagram of an exemplary hub-and-spoke network 800 and connectivity under the present invention;

[0023]
FIG. 9 depicts a schematic diagram of a second embodiment of a VPN network;

[0024]
FIG. 10 depicts a schematic diagram illustrating physical connectivity of the network of FIG. 9;

[0025]
FIG. 11 depicts a high-level block diagram illustrating asset module allocation to support the VPN network of FIGS. 9 and 10;

[0026]
FIG. 12 depicts a flow diagram of a method 1200 of implementing the VPN of the present invention; and

[0027]
FIGS. 13A and 13 B together depict a flow diagram of a method 1200 of modifying sites in a VPN network.

To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.

DETAILED DESCRIPTION OF THE INVENTION

[0028] The present invention provides a method for implementing capabilities such as those contemplated by RFC 2547 within a router. RFC 2547 provides a method by which a Service Provider with an IP backbone may provide VPNs (Virtual Private Networks) for its customers. MPLS (Multiprotocol Label Switching) is used for forwarding packets over the backbone, and BGP (Border Gateway Protocol) is used for distributing routes over the backbone. The RFC 2547 and 2547bis (2nd version) documents are hereby incorporated by reference herein in their entireties.

[0029]
FIG. 1 depicts a high-level block diagram of an exemplary network 100 suitable for implementing the present invention. The network 100 comprises a service provider network 102 and a plurality of customer networks 1201 through 120p (collectively customer networks 120). The service provider network 102 comprises a core network 105 formed by a plurality of core routers and switches 1061 through 106n (collectively core routers 106), and an edge network 104 formed by a plurality of “provider edge” (PE) routers 1081 through 108m (collectively PE routers 108). The PE routers 108 are connected to the core routers 106. Further, it is noted that subscripts “m”, “n”, and “p” are integers greater than one.

[0030] The customer networks 120 may be intranet and/or extranet types of networks, each having a “customer edge” (CE) router 122, which is connected to the provider edge routers 108. For example, in FIG. 1 the CE router 122, is connected to the PE router 1081, CE router 1222 is connected to PE router 1082, and so forth. It is noted that multiple CE routers 122 belonging to the same or different VPNs may be connected to a single PE router 108.

[0031] Under the RFC 2547 (i.e., MPLS-based techniques) architecture, as well as the present invention, all VPN functions are implemented in the PE routers 108. The core routers (i.e., P-routers) 106 are operable to forward MPLS “packets,” but they are not aware that the packets belong to a VPN. Similarly the CE routers 122 behave as if they are connected to ordinary routers, and are not aware that the PE routers 108 are RFC 2547 compliant.

[0032] Furthermore, a customer site is connected to a PE router 108 through a CE router 122 and the connection (access method) is identified via a layer 1 or a layer 2 identifier, which may represent a physical interface ID; a virtual path/virtual circuit identifier of an Asynchronous Transfer Mode (ATM) interface; a data link connection identifier (DLCI) of a frame relay interface; a virtual local area network identifier of an Ethernet serial link interface; and/or the MPLS label of a MPLS interface.

[0033] Two sites have IP connectivity over a common backbone (core network) 102 only if there is some VPN that contains them both. If two sites do not belong to a common VPN, then there is no connectivity over that backbone between the sites. In an instance where all the sites in a VPN are owned by the same enterprise, the VPN is a corporate “intranet.” Alternatively, if the various sites in a VPN are owned by different enterprises, the VPN is an “extranet.” A site may be included in more than one VPN, for example, in an intranet and several extranets. Both intranets and extranets are regarded as VPNs, and the term VPN is not used herein to distinguish between intranets and extranets.

[0034] The backbone (i.e., core network and PE routers) is typically owned and operated by one or more Service Providers (SPs), and the owners of the sites are typically the “customers” of the SPs. The policies that determine whether a particular collection of sites form a VPN are those dictated by the customers.

[0035] Various techniques discussed herein allow the implementation of a wide range of policies. For example, within a given VPN, every site may have a direct route to every other site ( “full mesh”), or certain pairs of sites may be restricted from having direct routes to each other ( “partial mesh”).

[0036]
FIG. 2 depicts a schematic diagram illustrating transferring packets across the VPN network of FIG. 1. FIG. 2 is an exploded view of a portion of FIG. 1 illustratively depicting the CE router 1221 connected to the PE router 1081, as well as the CE router 1223 connected to the PE router 1083 via the core routers 106 of the core network 105. IP packets 210 from the customers are transferred over the network 102 encapsulated in MPLS frames 202 comprising an exterior label 212 and interior label 214. The exterior label 212 is used to route a packet 210 from the ingress PE (e.g., PE 1081) to the egress PE (e.g., PE 1083) across the network 102. The exterior label 212 is examined by all of the routers, hop by hop, across the network 102. The egress router (e.g., PE 1083) uses the interior label 214 to determine the egress interface (e.g., destination customer edge (CE) device).

[0037] One reason for the encapsulation of IP packet 210 within MPLS is that each VPN uses its own IP address space. The IP address assignments may potentially conflict with each other, as well the service provider's own IP address assignment. The exterior MPLS label 212 serves as an insulator between the customer's IP address space and service provider IP addressing space for the routing of the packet across the SP's network. The exterior label 212 is determined when the MPLS Label Switched Paths (LSP) are set up between the PE routers 108. The interior label 214 is specified by the egress PE, one for each interface, in the route advertisement to other PE routers.

[0038]
FIG. 3 depicts a schematic diagram of an exemplary VPN network of the present invention. In particular, the VPN network 300 comprises a plurality of provider edge (PE) routers 3081 through 308m (collectively PE routers 308) coupled to a core network 302. The core network 102 comprises a plurality of core routers and switches (not shown) that provide connectivity between the PE routers 308. Further, each PE router 308 is coupled to one or more customer edge (CE) devices 3221 through 322p (collectively CE devices 322) respectively at various customer sites 3201 through 320p (collectively sites 320). The core network 308 may be a public network, such as the Internet, while the customers may be corporate or enterprise entities having a multitude of end users at various sites utilizing the VPN-IP network 302.

[0039] More specifically, at each site, there are one or more Customer Edge (CE) devices 322, each of which is attached via a data link (e.g., PPP, ATM, Ethernet, Frame Relay, GRE tunnel, etc.) to one or more Provider Edge (PE) routers 308. If a particular site has a single host, that host may be the CE device. If a particular site has a single subnet, that the CE device may be a switch. Typically, the CE device 322 is a router, which is commonly termed a CE router. A CE device 322 is always regarded as being in a single logical site 320 (although a physical customer site may consist of multiple “virtual logical sites”). However, a site 320 may belong to multiple VPNs.

[0040] A PE router 308 is attached to a particular VPN if it is attached to a CE device 322 that is in that VPN. Similarly, a PE router 308 is attached to a particular site if it is attached to a CE device 322 that is in that site. When the CE device 322 is a router, it is a routing peer of the PE(s) to which it is attached, but is not a routing peer to CE routers 322 at other sites 320. CE routers 322 at different sites 320 do not directly exchange routing information with each other. In fact, they do not even need to know of each other at all (except in the case where this is necessary for security purposes). As a consequence, very large VPNs (i.e., VPNs with a very large number of sites) are easily supported, such that the routing strategy for each individual site is greatly simplified.

[0041] Referring to FIG. 3, each PE router 308 (i.e., physical router) comprises at least one access module 330 and an aggregation module 340. For example, PE router 308, illustratively comprises access modules 33011 and 33012 and aggregation module 3401. PE router 3082 illustratively comprises access modules 33021 and 33022 and aggregation module 3402, and so forth. It is noted that the number of access modules 330 provided in any given router 308 is dependent on the network topology of the VPN, as discussed below in further detail. However, each physical router 308 comprises only a single aggregation module 340.

[0042] The access modules 330 are assigned to one or more VPNs and are connected to customer routers at the customer sites. Each access module 330 is dedicated to a single VPN, however a single VPN may include multiple access modules 330. Each access module can support a plurality of customer sites of the same VPN. All the access modules 330 in each router 308 are connected to the respective aggregation module 340. Each aggregation module 340 is connected to other aggregation modules 340 residing in other routers 308 through the core network 302 via MPLS label switched paths (LSPs).

[0043] In particular, the aggregation modules 340 are directly connected to each other via LSP links. Each pair of aggregation modules (e.g., 3401 and 3402 of FIG. 3) may be connected via multiple LSPs, where each LSP offers a different grade of service. Each aggregation module 340 is assigned an IP address from the service provider's IP address space.

[0044]
FIG. 4 depicts a block diagram of an exemplary router of the present invention suitable for use in the exemplary network of FIG. 3. The router 308 illustratively comprises a plurality of access modules 330 supporting three VPNs: VPN 1, VPN 2, and VPN 3. Access modules 3301, 3302, and 3303 are dedicated to support VPN 1. Similarly, access modules 3304 and 3305 are dedicated to support VPN 2, while access modules 3306 and 3307 are dedicated to support VPN 3. Customer sites from VPN 1, VPN 2, and VPN 3 are connected to these access modules 330 from their respective customer edge routers (not shown) at the customer sites. The seven illustrative access modules 3301 through 3307 are all connected to the aggregation module 340, which is coupled to other aggregation modules 340 via the P-routers (not shown) of the core network 302.

[0045] The PE routers 308 are fully connected through a core network via MPLS tunnels as specified in the 2547 specification, although other tunneling technologies may also be utilized, such as IP security, IP-over-IP, and the like. The PE routers 308 converse with each other, exchanging information regarding the VPNs using Border Gateway protocol with Multi-Protocol extensions (MP-BGP), as specified under RFC 2858 by the IETF (Internet Engineering Task Force), which is incorporated by reference herein, in its entirety.

[0046] Specifically, through the routing protocol (MP-BGP), a PE 308 advertises its routes to other PEs with many other parameters, one of which is the Route Target (RT). The RT is used to describe the VPN (or VPN component) that the route is applicable to. Since a customer site may belong to multiple VPNs or VPN components, multiple RTs can be associated with a single route. Once a PE router 308 receives route advertisements from its peers, the receiving PE router 308 determines whether the route should be added to the VPN routing-forwarding (VRF) table based on the RTs. If the PE 308 is authorized to transmit for that particular RT, then the route is added to the VRF table.

[0047] Under RFC 2547, a service provider administrator separately and manually assigns the RDs and RT import and export statements. The service provider administrator needs to ensure consistent assignment to thereby ensure proper operation. For a better understanding of assigning RT statements, the reader is directed to patent application serial number 10/252,815, filed Sep. 24, 2002, entitled “Methods and Devices for Configuring Virtual Private Networks”, by Chu et al. of Lucent Technologies Inc. of Murray Hill, N.J., which is incorporated by reference herein in its entirety.

[0048] By contrast, and as discussed below in further detail, the access modules 330 of the present embodiment are determined automatically by the RTs import and export statements of the sites 320. This simplifies operations and also guarantees consistency. In other words, under the architecture of the present invention, an access module 330 is a generalized version of the VRF table under RFC 2547, and the RDs are utilized secondary to RTs. Furthermore, the access modules (routing tables) 330 are constructed based on RTs, as opposed to the routing tables being constructed by the RDs as provided under the RFC 2547 specification.

[0049] The router 308 further comprises a controller 350, which is suitable for use in the implementation of the present invention. Specifically, the controller 350 comprises a processor 352 as well as memory 356 for storing various control programs 358. The processor 352 cooperates with conventional support circuitry 354 such as power supplies, clock circuits, cache memory and the like as well as circuits that assist in executing the software routines stored in the memory 356. As such, it is contemplated that some of the process steps discussed herein as software processes may be implemented within hardware, for example as circuitry that cooperates with the processor 352 to perform various steps.

[0050] Although the controller 350 of FIG. 2 is depicted as a general-purpose computer that is programmed to perform various control functions in accordance with the present invention, the invention can be implemented in hardware as; for example, an application specific integrated circuit (ASIC). As such, it is intended that the processes described herein, be broadly interpreted as being equivalently performed by software, hardware, or a combination thereof.

[0051]
FIG. 5 depicts a schematic diagram of an exemplary VPN network 500 having two full VPN components. In particular, an exemplary customer VPN 502 including thirteen (13) sites (A to M) 520 comprises two full mesh VPN components 5041 and 5042. VPN component 15041 includes sites A through H, while VPN component 25042 includes of sites F through M. It is noted that sites F, G, and H are in both VPN components 5041 and 5042. Each site illustratively has an associated CE router (not shown).

[0052] Sites in VPN component 15041 can converse with each other, and similarly sites in VPN component 25042 can converse with each other. Further, sites F, G, and H can converse with all other sites by virtue of being members of both VPN components 5041 and 5042. On the other hand, sites A-E, which are only in VPN component 15041 cannot send or receive packets from any of the sites I-K, which are only in VPN component 25042, and vise versa.

[0053]
FIG. 6 depicts a schematic diagram illustrating physical connectivity of the network of FIG. 5. In particular, PE routers 5081 and 5082 are interconnected via a core network of core routers (not shown) in the service provider network 502. Sites A, B, F, G, and I-K are illustratively connected to PE router 5081, while sites C-E, H, L, and M are illustratively connected to PE router 5082. As all the sites belong to the same VPN, they all use the same IP address space. The IP address associated with site A is subnet A, the IP address associated with site B is subnet B, while the IP address associated with site C is subnet C, and so forth.

[0054] A first rule for implementing the present invention provides that customer sites that import and export the same route target (RT) are connected to the same access modules (RD). Accordingly, the number of access modules required at a PE router may be determined.

[0055] For the exemplary network shown in FIGS. 5 and 6, two RTs are required. A first RT, illustratively having an assigned number RT510, is utilized for sites A through H in VPN 1, which import and export this same RT. A second RT, illustratively having an assigned number RT520, is utilized for sites F through M in VPN 2, which import and export this RT. It is further noted that sites F through H are in both VPN components 5041 and 5042 and import and export to both RTs, RT510 an RT520.

[0056]
FIG. 7 depicts a high-level block diagram illustrating asset module allocation to support the VPN network 502 of FIGS. 5 and 6. Specifically, the first and second PE routers 5081 and 5082 each comprises an aggregation module 5401 and 5402 and a plurality of access modules 5301x and 5302y, where x and y are integers greater than 1. The first PE router 5081 is coupled to second PE router 5082 by their respective aggregation modules 5401 and 5402 via the service provider network 502, in a similar manner as discussed above with respect to FIGS. 3 and 4.

[0057] For the illustrative RT assignment discussed above with respect to FIGS. 5 and 6, both routers 5081 and 5082 only need to allocate three access modules to support this VPN 504. For the first PE router 5081, access module 5301, is utilized to provide connectivity to customer sites A and B (those that import and export RT510); access module 53012 is utilized to provide connectivity to customer sites I, J and K (those that import and export RT520); and access module 53013 is utilized to provide connectivity to customer sites F and G (those that import and export both RT510 and RT520).

[0058] Similarly, for the second PE router 5082, access module 53021 is utilized to provide connectivity to customer sites C through E (those that import and export RT510); access module 53022 is utilized to provide connectivity to customer sites L and M (those that import and export RT520); and access module 53023 is utilized to provide connectivity to customer site H (those that import and export both RT510 and RT520).

[0059] As such, the customer sites that import the same RTs and export the same RTs are connected to the same access modules 530. This relationship allows the PE routers to determine the number of access modules required, as well as how the customer sites are connected to the access modules. It is noted that the import list and export list may be different, depending on the VPN network topology.

[0060] The RD assignment can be automatically generated. The rule according to one embodiment is as follows: for each access module, compare its import RT list with its export RT list. If they match, all the sites in that access module can be assigned the same RD. Otherwise, all the sites have different RDs.

[0061] In this example, all the access modules in each PE router each have matching import and export RT lists. Therefore, all the sites belonging to the same access module have the same RD. Accordingly, a total of three RDs are required per PE router, since there are three access modules.

[0062] Associated with each access module is a forwarding table for ingress packets, called an “ingress-forwarding table”. The ingress-forwarding table is constructed based on an RT that may be exported by the access module, which is compared to the imported RTs from the peer-to-peer router advertisements.

[0063] A second rule for implementing the present invention provides that only advertised routes with matching RTs will create entries in the ingress-forwarding table. This rule applies to routes to other routers, to other access modules within the same router, and to other interfaces (customer site) within the same access modules. Routes from other routers are acquired through the MP-BGP route advertisements for VPN. Routes from the access modules within the same router are part of the configuration information of the VPN.

[0064] In the example discussed with respect to FIGS. 5-7, the second PE router 5082 will advertise the following routes to the first PE router 5081 as shown below in Table 1:

1TABLE 1IP addressInteriorof RouteAssociated RTsMPLS labelSubnet CRT510610Subnet DRT510620Subnet ERT510630Subnet HRT510, RT520640Subnet LRT520650Subnet MRT520660

[0065] As discussed above, access module 53011, of router 5081 can only import RT510. Therefore, access module 53011 will incorporate only advertised routes from subnets C, D, E, and H from PE router 5082 into the ingress routing table. Thus, routes from sites L and M are excluded, since they are assigned RTs RT520. Further, router 5081 also determines from its VPN configuration information that it can send packets to access modules 53011, and 53013, as both modules export RT510. Therefore, the router 5081 will also add routes for sites A, B, F, and G to the ingress-forwarding table of access module 53011. The resulting ingress-forwarding table is illustrated below in Table 2.

2TABLE 2IP address ofDestinationInterior MPLSRouteInterface TypeAddress/IDLabelSubnet ASelfInterface to site AN/ASubnet BSelfInterface to site BN/ASubnet CExternalIP address of610Subnet Daggregation620Subnet Emodule of router6305082Subnet FInternalInterface to site FN/AAccess moduleSubnet G53013Interface to site GN/ASubnet HExternalIP address of640aggregationmodule of router5082

[0066] Conceptually, the ingress-forwarding table shown above corresponds to the VRF table in RFC 2547, but includes improvements that will be described in further detail below. It is noted that the interior MPLS labels shown in Tables 1 and 2 have exemplary interior MPLS label identifiers 610-640, which are provided for forwarding the packets to the egress PE router. It is further noted that a similar analysis may be performed for the routs advertised by the first PE router 5081 to the second PE router 5082.

[0067] A third rule for implementing the present invention highlights a difference between the ingress-forwarding table of the present invention and the VRF instance of RFC 2547, and further illustrates that the present invention is more efficient than the current architecture under RFC 2547. In particular, rule 3 of the present invention provides that the ingress-forwarding table is constructed based solely on comparing the export RT of the access modules with the import RT of the advertisements. Therefore, in the case of locations (customer sites) connecting to the same access module, connectivity between these sites are determined by comparing the import and export list of the access module. If there is no commonality between the two lists, the access module will not allow communications between the locations connecting to the access module.

[0068] This third rule distinguishes the present invention from RFC 2547. In RFC 2547, each site is assigned a VPN Routing/Forwarding (VRF) table through the RD assignments. If two sites are assigned to the same VRF table, they automatically can send packets to each. However, this may be undesirable in some VPN configuration. Under the RFC 2547 architecture, this is handled by assigning a different VRF to each site, thereby requiring more resources, which is less efficient. The difference between the RFC 2547 architecture and the architecture of the present invention is illustrated below with respect to FIG. 8.

[0069]
FIGS. 8A and 8B depict a schematic diagram of an exemplary hub-and-spoke network 800 and connectivity under the present invention. The network 800 comprises a hub site 802, and 100 branch sites 8001 through 8100. The hub 802 can converse with all the branches and vice versa. However, the branches can only converse with each other through the hub 802. Under the RFC 2547 environment, an efficient RT assignment for this network requires two RTs. The hub 802 will illustratively import RT “810” and illustratively export RT “820”, while the branches would import RT 820 and export RT 810. It is noted that the branches and hub are assigned different import and export RTs so that the branches do not communicate with each other. By contrast, if all of the branches and the hub were assigned the same import and export RT values (e.g., RT810), then the branches would be able to communicate with each other as a mesh network illustratively discussed above, rather than a hub-and-spoke network.

[0070] As the branches cannot communicate with each other directly, all branches need to have their own individual VRF table (and its own RD). The hub 802, being different from the branches, also requires its own VRF table (and RD). It is noted that in the case where all the sites are connected to a single router, such router would need to support 101 VRF tables.

[0071] Under the present invention, all the branches import and export the same RTs. FIG. 8B illustratively shows all of the branches connected to the same access module (e.g., access module 8301), and the hub 802 is connected to a different access module (e.g., access module 8302) of the PE router 808, as provided by rule 1. Further, the access modules 830, and 8302 are coupled to a single aggregation module 840, as discussed above.

[0072] The ingress-forwarding table of access module 830, is constructed using rule 2, which allows all of the branches to send to the hub 802, while rule 3 prevents a branch from sending packets to another branch. Therefore, only two ingress-forwarding tables are required, one for the branches and one for the hub. Thus, the present invention is more efficient than the architecture as specified in RFC 2547, since only two tables are required, as opposed to 101 under RFC 2547. Therefore, less resources are required. Moreover, the third rule provides that an access module may be connected to sites with different RDs, since it is the RTs that serve as the defining element. Referring to FIG. 8, all the branches in a hub-and-spoke network have different RDs.

[0073]
FIG. 9 depicts a schematic diagram of a second embodiment of a VPN network 900. In particular, FIG. 9 depicts a VPN network 900 comprising a fully meshed component as well as hub-and-spoke components. Specifically, the exemplary network 900 may be considered as consisting of five components. A first component comprises a core network including four (4) hub locations 100, 200, 300, and 400. The hub locations are fully connected (full mesh topology).

[0074] Connecting to hub 100 are four branches 101, 102, 103 and 104, forming a tree (or hub-and-spoke) network. Similarly, connecting to hub 200 are four branches 201, 202, 203 and 204, forming a tree (or hub-and-spoke) network. Connecting to hub 300 are four branches 301, 302, 303 and 304, forming a tree (or hub-and-spoke) network. Finally, connecting to hub 400 are four branches 401, 402, 403 and 404, forming a tree (or hub-and-spoke) network.

[0075]
FIG. 10 depicts a schematic diagram illustrating physical connectivity of the network 900 of FIG. 9. On the physical level, sites (i.e., the CE routers at these sites) 10x and 20x are connected to PE router 9081 in a service provider's network, while sites 30x and 40x are connected to PE router 9082 PE router 9081 and PE router 9082 are coupled via the service provider network 902 in a similar manner as discussed above with respect to FIGS. 5-7.

[0076] For the network topology of FIGS. 9 and 10, all the sites 10x, 20x, 30x, and 40x are assigned their own RD, resulting in twenty (20) RD assignments. In particular, all the hubs 100, 200, 300, and 400 are different as they communicate with different respective branches 10x, 20x, 30x, and 40x. Therefore, the hubs 100, 200, 300, and 400 all have different virtual routing/forwarding (VRF) tables (and thus different RDs).

[0077] The branches also require different RD assignments. According to the RFC 2547 specification, if the branches have the same RD, the branches would be able to communicate with each other directly when connected to the same PE. However, the illustrative hub-and-spoke network topology shown in FIGS. 9 and 10 specifically prohibits this, since the branches (10x, 20x, 30x, and 40x) cannot communicate with each other. Therefore, a different RD is needed for each branch, and accordingly, a different RD is required for each site. For a detailed understanding for optimal RD (and RT) assignment, the reader is directed to patent application serial number 10/252,796, filed Sep. 24, 2002, entitled “Method and Systems for Efficiently Configuring IP Based Virtual Private Networks “by, Chu et al. of Lucent Technologies, Inc., which is incorporated by reference herein in its entirety.

[0078] Additionally, a total of nine (9) RTs are required for the network 900. A first RT is required for the full mesh network component between the hubs. This first RT is illustratively assigned a value “RT960”. For each of the four (4) tree network components (hub-and-spoke sub-networks), two (2) RTs are required, one for the upstream direction and one for downstream direction. For example, RT identifier “RT910” is assigned for the upstream direction of the 10x tree network, while RT identifier “RT911” is assigned for the downstream direction of the same tree network. It is noted that the term “upstream” denotes traffic from the branches to the hub, while the term “downstream” denotes traffic from the hub to the branches.

[0079] Similarly, RT identifier RT920 is assigned for the upstream direction of the 20x tree network, while RT identifier RT921 is assigned for the downstream direction of the same tree network. Likewise, RT identifier RT630 is assigned for the upstream direction of the 30x tree network, while RT identifier RT631 is assigned for the downstream direction of the same tree network. Finally, RT identifier RT940 is assigned for the upstream direction of the 40x tree network, while RT identifier RT941 is assigned for the downstream direction of the same tree network. The RT import and export statement for the sites at the PE routers are summarized below in Table 3.

3TABLE 3SiteRTs importedRTs exported100960, 910960, 911200960, 920960, 921300960, 930960, 931400960, 940960, 941101, 102, 103, 104911910201, 202, 203, 204921920301, 302, 303, 304931930401, 402, 403, 404941940

[0080]
FIG. 11 depicts a high-level block diagram illustrating asset module allocation to support the VPN network of FIGS. 9 and 10. FIG. 11 is similar to the exemplary block diagram of FIG. 7, except the number of access modules and sites connected to these access modules differ due to the network topology differences therebetween. According to rule 1 (i.e., customer sites that import and export the same route target (RT) are connected to the same access modules (RD)), a total of 8 access modules are required. Sites 100, 200, 300, and 400 are each connected to a respective access module. Sites 101, 102, 103, and 104 can be connected to the same access module. Similarly, sites 201, 202, 203, and 204 can be connected to same access module. Further, sites 301, 302, 303, and 304 can be connected to same access module, while sites 401, 402, 403, and 404 can be connected to same access module.

[0081] Referring to FIG. 11, PE router 9081 comprises access modules 11301 through 113014, where location 100 is connected to access module 113011, sites 101 through 104 are connected to access module 113012, location 200 is connected to access module 113013, and locations 201 through 204 are connected to access module 113014.

[0082] Similarly, PE router 9082 comprises access modules 113021 through 113024, where location 300 is connected to access module 113021, locations 301 through 304 are connected to access module 113032, location 400 is connected to access module 113023, and locations 401 through 404 are connected to access module 113024.

[0083] The access modules 113011 through 113014 of the PE router 9081 are each coupled to an aggregation module 11401, while the access modules 113021 through 113024 of the PE router 9082 are each coupled to an aggregation module 11402. The aggregation modules 11401, and 11402 of the PE routers 9081 and 9082 are coupled to each other via label switched paths across the service provider network 902 as discussed above.

[0084] Each access module 1130 has a single ingress routing/forwarding table (i.e., a total of 8 routing/forwarding tables). This represents a saving of 60% in the number of routing-forwarding tables as compared to the RFC 2547 architecture, which would have required 20 VRF tables (i.e., one for each RD).

[0085] As per rule 1, the router determines the number of the access modules required, as well as how customer sites are connected to the access modules. Further, rule 2 describes how the forwarding table for ingress packets (those from customer sites) is constructed for each access module.

[0086] In particular, according to rule 2 of the present invention, associated with each access module is a forwarding table for ingress packets. Only routes with matching RTs will create entries in the table. This rule applies to routes to other routers, to other access modules within the same router, and to other interfaces (customer site) within the same access modules. Routes from other routers are acquired through the MP-BGP route advertisements for VPN. Routes from the access modules within the same router are part of the configuration information of the VPN.

[0087] In the example shown in FIGS. 9-11, consider access module 113011 in PE router 9081. Let the IP address of site 100 be A100, site 200 be A200, and so forth. Router 9082, which is the peer of router 9081, will advertise the following routes to router 9081, as illustratively shown below in Table 4.

4TABLE 4IP addressAssociated RTsInteriorof RouteMPLS labelSubnet A3009609001Subnet A4009609002Subnet A301,9319311Subnet A302,9319312Subnet A3039319313Subnet A3049319314Subnet A4019419411Subnet A4029419412Subnet A4039419413Subnet A4049419414

[0088] Recall that per rule 3 of the present invention, the ingress-forwarding table is constructed solely based on the import RT of the access modules. In the example shown in FIGS. 9-11, access module 113011 at PE router 9081 can only import RT 960 and 910. Therefore, it will only incorporate routes from subnets A300 and A400 into the ingress-forwarding table, since these two subnets have RT 960 associated with them. The rest of the routes are ignored, as the RTs associated with them do not match with the import list. Effectively, this permits sites connected to access module to send to the hub sites 300 and 400 but none of the 30x and 40x branches.

[0089] Internally, router 9081 also determines from its VPN configuration information that it may send packets to access modules 113012 and 113013. Packets may be sent to module 113012 because the module 113011 exports RT 911, the same of which is imported by access module 113012. Similarly, packets may be sent to module 113013 because module 113011 exports RT 960, the same of which is imported by access module 113013 . Therefore, the router 9081 will add routes to sites that are attached to both modules (113012 and 113013 ) to the ingress-forwarding table of access module 113011. Note that access module 113011 cannot send packets to access module 113014, since module 113014 only imports RT921, which is not exported by access module 113011. However, access module 113013 can send packets to access module 113014 , since access module 113013 exports RT921, which is also imported by access module 113014 . The resulting ingress-forwarding table is illustratively shown below in Table 5.

5TABLE 5IP address ofDestinationInterior MPLSRouteInterface TypeAddress/IDLabelSubnet A100SelfInterface to site AN/ASubnet A300ExternalIP address of9001Subnet A400aggregation9002module of router9082Subnet A101InternalInterface to accessN/AAccess modulemodule 113012Subnet A102113012Interface to siteN/Aaccess module113012Subnet A102Interface to siteN/Aaccess module113012Subnet A102Interface to siteN/Aaccess module113012Subnet A200InternalIP address ofN/AAccess moduleaggregation113013module 113013

[0090] Conceptually, the ingress-forwarding table (Table 5) is similar to the VRF table in RFC 2547. However, a reduced number of entries are required in the above example, as there are less access modules 1130 than RDs as demonstrated per rule 1. It is noted that a similar analysis may be performed for the instance where the first router 9081 advertises the peer-to-peer information to the second router 9082. It is further noted that an MPLS label or other identifier can be used to indicate the egress interface, such as exemplary interior MPLS labels 9001 for subnet A300, 9002 for subnet A400, and the like as illustratively shown in Table 4.

[0091] As packets are transferred within the PE router (e.g., access module 113011 to access modules 113012 or 113013) and between the other PE routers, one aspect of the present invention is to ensure a router implementing the present invention will appear to other routers as a RFC 2547 compliant router in every respect. Accordingly, rule 4 provides that for an ingress packet from a customer site, if the ingress-forwarding table indicates that the packet should be,forwarded to another device, the access module passes the packet to the aggregation module, together with the following information: (a) the IP address of the destination aggregation module and (2) the interior MPLS label to be used.

[0092] Based on the IP address of the destination aggregation module and the grade of service of the particular VPN, the local aggregation module selects the appropriate MPLS Label Switched Path (LSP) to use. The aggregation module formats the resulting MPLS frame in a similar manner as provided under RFC 2547, and then sends the formatted MPLS frame to the destination aggregation module using an exterior label.

[0093] Logically, the aggregation modules maintain an MPLS-LSP forwarding table as shown in Table 6.

6TABLE 6DestinationExteriorIP AddressGrade of ServiceLSP LabelSubnet AGold2000Silver2001Copper2002Subnet BGold2003Silver2003Copper2004Subnet X......

[0094] Table 6 identifies various grades of service for each destination IP address. The grades of service are quality of service (QoS) levels, which illustratively include constant bit rate (CBR), variable bit rate (VBR), real-time variable bit rate (VBR-rt), controlled load, guarantee service, best effort services, among other services known in the industry. Each grade of service for each destination IP address is provided with an exterior LSP label. In lieu of the exterior LSP, other tunneling technology such as IP sec can be used. Upon receipt of a MPLS frame from a peer ingress PE router, the egress PE router examines the interior MPLS label to determine the egress interface.

[0095] The purpose of the aggregation module is to process all the functions that are related to the transfer (forwarding) of packets across the network and within the router for all the access modules. The access modules and aggregation module in each PE router are illustratively shown as being logically independent modules. However, a person skilled in the art will appreciate that in an alternate embodiment of the invention, the aggregation functionality may be incorporated into each access module. This avoids an additional module (i.e., aggregation module) in the PE router, but at the expense that each access module would be more complex. It is further noted that variations of these two embodiments are possible.

[0096] Specifically, during normal operation, each interface to a customer site is assigned a unique interior label. However, it is also possible to associate an egress-forwarding table with the interior MPLS label. For example, the interior MPLS label may point to an access module. The destination IP address of the incoming packet is used to determine the egress interface.

[0097] One benefit of the present invention is that the ingress-forwarding table can be common to more than a single customer site. This reduces the number of forwarding tables, thereby improving the performance and reducing the cost of the router. Another benefit is that the determination of the access modules is automated based on RT assignments, as opposed to 2547 specifications, where the RD and RT are assigned manually and separately. Accordingly, by decomposing the PE routers into various software modules, the PE routers are able to support RFC 2547 features in a more efficient manner by reducing the number of routing tables with in the router.

[0098] Thus far, the present invention has been described at the router level, i.e. the necessary logic at a PE router. However, the present invention also operates at the network level.

[0099]
FIG. 12 depicts a flow diagram of a method 1200 of implementing the VPN of the present invention. The method 1200 starts at step 1201, and proceeds to step 1202, where a service provider deploys a number of core and PE routers. The service provider connects all the PE routers pairwise through MPLS label switched paths (LSP). Separate LSPs are required for each class of the service that the service provider would like to provide. Multiple LSPs may be set up to support the same class of service to provide additional functions, such as diverse routing. It is noted that other tunneling technologies, such as IPsec (IP with Security) may be used in lieu of MPLS. For each PE router, the service provider inputs a list of its peer PE routers via a network manager or other external means. Through this list, a PE router may subsequently establish BGP associations with its peers to exchange VPN information, such as route advertisement.

[0100] At step 1204, the PE routers establish logical connectivity with each other, and construct a logical network. Thus, steps 1202 and 1203 are used to construct a physical network.

[0101] At step 1206, the customer sites associated with the VPNs are connected to a particular PE router. Specifically, a customer subscribing to the VPN service, informs the service provider of all the customer sites (locations) in the VPN as well as the desired logical topology. Such topology may be a full mesh, partial mesh, hub-and-spoke, star, and the like, or a combination thereof. The SP determines for each location, the PE router that the location should connect to, based on locality of the customer sites.

[0102] The following steps 1208 through 1218 add locations (i.e., customer sites) to the VPNs. In particular, at step 1208 the customer and the SP then specify, for each location, the access method (e.g. frame relay, ATM, PPP) used. The routing protocol between the CE and PE router (e.g. BGP, RIP, static, etc.) for the location is also specified. As such, the PE router is able to learn about the routes.

[0103] At step 1210, the SP assigns the import and export RT lists for each location, based on the desired network topology, and at step 1212 the SP specifies at the PE routers, for each site, the access interface, the routing protocol, and the RT import and export lists.

[0104] At step 1214, the PE routers advertise the routes of the VPN to its peers based on the import RT lists. It is noted that the PE router automatically assigns an interior MPLS label, which is associated with a route.

[0105] At step 1216 the PE router constructs access modules based on the RT export lists of the locations as described above. That is, all locations with the same RT import and RT export lists are mapped to the same access modules. Customer sites are also connected to the appropriate access modules.

[0106] At step 1218 for each access module, the PE router constructs an ingress-forwarding table based on the RT values of the route advertisement, as well as the export RT list of the access modules. Once the ingress-forwarding table is constructed for all the access modules of a VPN, the VPN is established and capable of transferring information. The method 1200 then proceeds to step 1299, where the method 1200 ends.

[0107] During the life cycle of a VPN, the VPN may need to be modified. Accordingly, the present invention provides a technique for modifying a VPN network.

[0108]
FIGS. 13A and 13B together depict a flow diagram of a method 1300 of modifying sites in a VPN network. In particular, method 1300 provides a process for adding, removing, and/or moving customer sites in a VPN network. The method 1300 starts at step 1301 and proceeds to step 1302, where a determination is made to modify the sites in the VPN network. If at step 1302, a site is to be removed, then at step 1304, the site to be removed is deleted from the respective access module and the method 1300 ends at step 1399.

[0109] If at step 1302, a site is not to be removed from the VPN network, then the method 1300 proceeds to step 1306, where a determination is made whether a new site is to be added to the VPN network. If a new site is not to be added to the VPN network, the method 1300 ends at step 1399. Otherwise, the method proceeds to step 1308.

[0110] At step 1308, the method determines the import and export RT list for the new site. The RT is assigned based on the desired connectivity of the site.

[0111] At step 1310, the router compares the import and export RT lists of the site to the RT lists of all existing access modules. Specifically, all sites connected to the same access modules will have the same import and export RTs lists (by rule 1 discussed above). These two lists are referred as the RT-list of the access module. If at step 1312, there is a match, then the method 1300 proceeds to step 1318, where the new site is added as a member of the matching access modules. The method then proceeds to step 1320, which is discussed below in further detail.

[0112] If at step 1312 there is not a match, then the method 1300 proceeds to step 1314. At step 1314, the router creates a new access module, and at step 1316, the new site is assigned to the newly created access module. The method 1300 then proceeds to step 1320.

[0113] At step 1320, the import RT list is compared with the export list of the new site. If at step 1322, the import RT list does not match with the export list of the new site, then at step 1324, the new site will be assigned a new unique RD. The method 1300 then proceeds to step 1399, where the method 1300 ends. If at step 1322, the import RT list matches with the export list of the new site, then at step 1326, the new site would be assigned the same RD as the other sites belonging to the same access modules. The method 1300 then proceeds to step 1299, where the method 1200 ends.

[0114] It is noted that there may be instances where it is desirable to move a site. In particular, if the topology of the VPN changes, the affected locations may have new RT import and exports. In such instances, method 1300 may be implemented by first removing a site from the VPN, as discussed above with respect to steps 1302 and 1304, and then modifying the RT import and export lists of the site. The new site is then added into the VPN, as discussed above with respect to steps 1306 through 1326.

[0115] It is further noted that optimal RD assignment is automatic when implementing the present invention. The service provider just needs to determine the import and export RT lists of a site. RD assignment (whether an old RD can be used or a new one is needed) is automatic. Conversely, under RFC 2547, the service provider has to determine both the RT import and export lists, as well as the RD assignment. Therefore, saving in operations is realized.

[0116] Although various embodiments that incorporate the teachings of the present invention have been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incorporate these teachings.

Functional decomposition of a router to support virtual private network (VPN) services

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

US Classifications

International Classifications

Abstract

Description

Claims