Dong, Shenzhen (CN) (73) Assignee: Huawei Technologies Co., Ltd. (CN) (*) Notice: Subject to any disclaimer, the term of this patent is extended or adjusted under 35 U.S.C. 154(b) by 1144 days. (21) Appl. No.: 10/336,156 (22) Filed: Jan. 3, 2003 (65) Prior Publication Data US 2004/OO37275A1 Feb. 26, 2004 (30) Foreign Application Priority Data Aug. 23, 2002 (CN) ................................ O2 129009 (51) Int. Cl. H04L 2/56 (2006.01) (52) U.S. Cl. ....................................... 370/392; 709/238 (58) Field of Classification Search ................. 370/392, 370/397,399, 395.32 See application file for complete search history. (56) References Cited U.S. PATENT DOCUMENTS 7,075.933 B2 * 7/2006 Aysan ................... 370,395.31 7,116,665 B2 * 10/2006 Balay et al. ................. 370,392 7,152,115 B2 * 12/2006 Ould Brahim et al. ...... TO9,238 7.340,519 B1* 3/2008 Golan et al. ................ 709,225 2003/0142674 A1* 7/2003 Casey ......................... 370,393 2003/0217132 A1* 11/2003 Batten et al. ................ 709,223 2003/0223406 A1* 12/2003 Balay et al. ................. 370,352 2004/0076165 A1 4/2004 Jean-Francois et al. ..... 370/400 2004/0223497 A1* 11/2004 Sanderson et al. ..... 370,395.52 2005/0190757 A1* 9/2005 Sajassi ....................... 370,389 2006/0215578 A1* 9/2006 Andrapalliyalet al. ...... 370,254 2006/0215579 A1* 9, 2006 Nadeau et al. .............. 370,254 2006/0274723 A1* 12/2006 Siyavudeen et al. ......... 370,352 SPE VRF default "-y MPE 3. s WRF default route Out 12 N UPE VPN1 WPN2 Site1 Site 1 2007/0086448 A1* 4/2007 Hu ............................. 370,389 2007/0140251 A1* 6/2007 Dong ......................... 370,392 2007/0226325 A1 9, 2007 Bawa et al. ................. 709,223 (Continued) FOREIGN PATENT DOCUMENTS EP 1 187405 3, 2002 (Continued) OTHER PUBLICATIONS Overview of MPLS Virtual Private Networks. (Continued) Primary Examiner Edan Orgad Assistant Examiner Salman Ahmed (74) Attorney, Agent, or Firm DLA Piper US LLP (57) ABSTRACT A 3-layer Virtual Private Network (VPN) is disclosed and includes P devices and PE devices in the backbone network, a plurality of sites and CE devices in subscribers VPNs, and Hierarchy of PE (HoPE) devices, the HoPE devices serve as edge routers in the backbone network and are connected to P devices in the backbone network as well as sites and CE devices in subscribers’ VPNs; the HoPE devices include understratum PEs (UPEs), Zero or more middle-level PEs (MPEs) and superior PEs (SPEs) connected with each other, and all of the PEs (UPEs, MPEs, and SPEs) take different roles and deliver the function of a central PE. For the SPEs, the routing and forwarding performance should be relatively higher; while for UPEs, the performance may be lower. The architecture can enhance the expandability in hierarchical BGP/MPLSVPNS. 8 Claims, 3 Drawing Sheets N default route WN1 WPN2 Site 3 Site 3 VPN VPN2 Site2 Site2 US 7.411.955 B2 Page 2 U.S. PATENT DOCUMENTS 2008/0089334 A1* 4/2008 Soja-Molloy et al. ....... 370,392 FOREIGN PATENT DOCUMENTS EP 1392033 * 2/2004 EP 17131.97 * 10/2006 EP 1768335 * 3/2007 OTHER PUBLICATIONS Quantitative analysis of multiprotocol label Switching (MPLS) in VPNs; Khan, M.A. Sir Syed University of Engineering and Technol ogy; This paper appears in: Students Conference, ISCON 02. Pro ceedings. IEEE Publication Date: Aug. 16- 17, 2002 vol. 1. On pp. 56-65 vol. 1. Overview on MPLS Virtual Private Networks; Journal Photonic Net work Communications Publisher Springer Netherlands ISSN 1387-974X (Print) 1572-8188 (Online)Issue vol. 4, No. 2 / May 2002 ck R. Callon et al., “A Framework for Provider Provisioned Virtual Private Networks', printout from Internet , retrieved on May 27, 2003, draft dated Jul. 19, 2001, 72 Pages. Eric C. Rosen, “BGP/MPLSVPNs”, printout from Internet , retrieved on May 27, 2003, draft dated Jul. 2002, 41 Pages. Bin Li et al., “Hiearchy of Provider Edge Device in BGP/MPLS VPN”, printout from Internet , retrieved on May 27, 2003, draft dated Nov. 6, 2002, 12 pages. M. Lasserre et al., “Virtual Private LAN Services over MPLS, Internet Draft, Jun. 2002, printout from Internet(URL: www.ietforg). * cited by examiner U.S. Patent Aug. 12, 2008 Sheet 1 of 3 US 7411,955 B2 WPN. Site 1 WPN2 Site 1 MPLS network VPN1 Site2 WPN2 Site2 Fig.1 WPN1 Site1 VPN Ste3 VPN2 Site1 WPN1 Ste2 WPN2 Ste3 layered PE Fig.2 U.S. Patent Aug. 12, 2008 Sheet 2 of 3 US 7411,955 B2 Fig.3 Fig.4 U.S. Patent Aug. 12, 2008 Sheet 3 of 3 US 7411,955 B2 WRF default 1Oute TOute WPN1 WPN2 Site3 Site3 VPN1 VPN2 WPN1 WPN2 Site Site Site2 Site2 Fig.5 US 7,411,955 B2 1. 3-LAYER VPN AND CONSTRUCTING METHOD THEREOF BACKGROUND OF THE INVENTION 1.Technical Field of the Invention The present invention relates to the architecture of a 3-layer Provider Provide VPN (PP VPN) and constructing method thereof. 2. Background There are different implementations of traditional PPVPN architecture in actual applications, such as BGP/MPLSVPN, VR VPN, and MPLS 12 VPN, etc. As for BGP/MPLS VPN (Multi Protocol Label Switch based on Switch Border Gate way Protocol), the PPVPN is a network that delivers IP VPN service in public networks with MPLS technology and BGP The BGP/MPLSVPNarchitecture mainly comprises a back bone network composed of P devices and PE devices pro vided by ISP as well as subscribers VPN that comprises a plurality of sites and CE devices. In said devices, P (Provider Router) devices are mainly responsible for forwarding MPLS. PE (Provider Edge Router) devices are the main body to realize MPLS/BGP VPN service, and they maintain independent lists of sites in subscribers’ VPNs, and detect VPN topologies and learn internal VPN routes through BGP CE (Custom Edge Router) devices are common routers, and they connect sites in Sub scribers’ VPNs to PEs, without supporting any MPLS or VPN signaling or protocol. In the BGP/MPLS VPN architecture, PE devices may be the bottleneck in large-scale deployments because they have to converge routes from a plurality of VPNs (especially in cases that capacity of PE devices is small). Furthermore, most traditional MPLSVPN models are planarones, wherevera PE device resides in the network, its performance should be the same as others. In Such an environment, more routes have to be maintained as PE expands towards edge because routers converge layer by layer. For a 3-layer model typical network employing a core-convergence- access architecture, the per formance of devices degrades as the network expands, which brings difficulty to the expansion of network towards the edge. To solve said problem, a Multi-VRF (VPN routing/ forwarding instance) scheme is proposed to enhance the capacity of CE devices to deliver VRF functionality. Such devices are called VCE devices. In networking, a plurality of VCE devices and PE devices are combined to form a distrib uted PE. Seen from FIG. 1, multiple VRFs are configured in VCE, and the VRFs correspond to multiple VPN sites. On each VRF there are some downward interfaces to connect to VCE devices and an upward interface to connect to PE devices. On PE devices, the same VRFs are configured cor respondingly, and each VRF has one or more interfaces, which connect with VCE devices. Thus, a Multi-VRF CE device simulates multiple CE devices actually, each virtual CE is isolated from each other to access multiple VPN sub scribers, but the PE devices don't "know' whether they are connected to multi CE devices or a VCE device. Therefore, any expansion is unnecessary. Though the scheme solves the problem of expandability of PE devices to some extent, the disadvantage is also obvious, i.e. a large amount of interfaces, Sub-interfaces are needed between PE and VCE devices, which consume limited inter faces and IP addresses resource: multiple VRFs have to be configured on PE and CE devices, which is a heavy-labor and repetitive work; 10 15 25 30 35 40 45 50 55 60 65 2 if a dynamic route protocol is used in exchange of routes between PE and VCE devices, PEs and VCEs need to run multiple instances; if static routes are used, the configuration is a heavy-labor work; if tunnel interfaces are used to connect PEs with VCEs instead of direct connection, each VRF will need a tunnel, resulting in heavy consumption of resource: if different VCEs are connected with each other to deliver VPN messages to reduce the burden on PE devices, each VRF needs an interface/sub-interface. SUMMARY We provide a 3-layer PPVPN comprising P devices and PE devices in the backbone network, sites and CE devices in the subscribers’ VPNs, and HoPE devices. Said HoPE (hierarchy of PE devices) serves as an edge router in the backbone network and is connected to P devices in the backbone and sites and CE devices in VPNs: said HoPE comprises understratum PEs (UPEs) and supe rior PEs (SPEs) which are connected with each other; therein the UPEs are responsible for maintaining the routes to VPN sites connected directly with them, and allocating internal labels for routes to the VPN sites, and issuing labels to SPEs through VPN routes; the SPEs are responsible for maintain ing all routes in VPNs where the sites are connected via UPEs, and issuing default VRF (VPN routing/forwarding instance) routes or converged VRF routes to UPEs, and carrying labels; said UPEs and SPEs as well as different UPEs are con nected with each other via interfaces or sub-interfaces, and the messages among them are forwarded with labels. Said HoPE also comprises some middle-level PEs (MPEs) between UPEs and SPEs: said MPEs are responsible for maintaining all routes in VPNs where the sites are connected via UPEs, issuing default VRF (VPN routing/forwarding instance) routes or converged routes to UPEs, and replacing the labels carried by default VRF routes issued from SPEs, and issuing them to UPEs: if a MPE has generated a default route for the VRF, it will gen erate an ILM On MPE. A constructing method for the 3-layer VPN comprises: deploy HoPE devices in the backbone network, and said HoPE devices serve as edge routers in the backbone network and are connected to P devices in the backbone network and sites and CE devices in subscribers VPNs; said HoPE com prises understratum PEs (UPEs) and superior PEs (SPEs) which are connected with each other; therein the UPEs are responsible for maintaining the routes to VPN sites connected directly with them, and allocating internal labels for routes to the VPN sites, and issuing labels to SPEs through VPN routes: the SPEs are responsible for maintaining all routes in VPNs where the sites are connected via UPEs, and issuing default VRF (VPN routing/forwarding instance) routes or converged VRF routes to UPEs, and carrying labels; said UPEs and SPEs are connected with each other via interfaces or Sub-interfaces, and the messages among them are forwarded with labels. Said HoPE also comprises some middle-level PEs (MPEs) between UPEs and SPEs, said MPEs are responsible for maintaining all routes in VPNs where the sites are connected via UPEs, issuing default VRF (VPN routing/forwarding instance) routes or converged routes to UPES, and replacing the labels carried by default VRF routes issued from SPEs, and issuing them to UPEs: if a MPE has generated a default route for the VRF, it will generate an ILM on MPE.