Network Working Group Li Bin Internet Draft Dong Weisi Expires: November 2003 Huawei Technologies Chen Yunqing China Telecom Beijing Research Institute Li Defeng Huawei Technologies MAY 27, 2003 Hierarchy of Provider Edge Device in BGP/MPLS VPN Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In the deployment of BGP/MPLS VPN,the PE(Provider Edge)Device should maintain all the VPN routes of the VPNs which it belong to.If there are many VPNs attaches to a PE,and the capacity of PE is somewhat limited,then the bottleneck will be encountered.Another problem is that the current BGP/MPLS VPN model is something of a "Plane Modle" where the demand of the performance of the PE device are all the same no matter which layer the PE device is belongs to.However,the typical network is "Core-Convergence-Access(Edge)" layered model,and the performance of the device is high in Core Layer and low in Access Layer,and the scale of network is large in Access Layer and small in Core Layer,the routes are converged in every layer,so in current "Plane Modle",when PE device extend to the edge layer,it has to maintain more VPN routes,which makes it difficult to extend the PE device to edge layer.This document defines an model of Hierarchy of Provider Edge Device in BGP/MPLS VPN,where Hierarchy of Provider Edge Device can be composed of several PE and each PE plays the different part,partake the function of the normal RFC 2547 PE,we call this model "Hierarchy Model",In this model,the demand of performance in Routing and Switching is strict to the PE device in higher layer,loose to the PE device in edge layer. One HoPE can be composed of an SPE and UPES connected with the SPE, or be composed of a high-level SPE and HoPEs connected and build up a new HoPE.This build is called nesting of HoPE,and this kind of nesting can be done for many times.Thus the former HoPE connects with the high-level SPE act as a role of UPE,and the new HoPE can connect a single UPE too. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 1] Draft November 2002 Table of Contents 1. Introduction ...................................................3 2. Working Principle ..............................................4 2.1 VPN routes ....................................................4 2.2 Control Flow(Route Advertising and Label Distribution).........5 2.3 Data Flow(Label Operation and Packet Forwarding) ..............6 3. Interface between UPE and SPE...................................7 4. Nesting of HoPE.................................................7 5. Multi-Homing UPE................................................9 6. Backdoor link between UPEs......................................9 7. UPE/CE routing protocol ........................................9 7.1 Sham-link in HoPE..............................................9 8. The Forwarding Procedure in Some Special Cases..................9 9. Layered BGP/MPLS VPN with HoPE.................................10 10. Interoperability..............................................11 11. Security Consideration........................................11 12. Updation from last version....................................11 10. Acknowledge...................................................12 11. References....................................................12 12. Authors' Addresses............................................12 Full Copyright Statement .........................................12 Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 2] Draft November 2002 1. Introduction This document defines an model of Hierarchy of Provider Edge Device in BGP/MPLS VPN,where Hierarchy of Provider Edge Device can be composed of several PE device and every PE play the different part,partake the function of the normal concentrative PE,we call this model "Hierarchy Model",In this model the demand of performance in Routing and Switching is strict to the PE device in higher layer,loose to the PE device in edge layer. PE device can connect with not only the Customer Edge(CE) device,but also a PE device,or even more generally an IP/MPLS VPN network,and the connected PE devices formed the "Hierarchy of PE",and the PE device which replace the former position of CE device in "Plane Model" is called Under-layer PE(UPE),and the PE device which UPE is connected with is called Superstratum PE(SPE),this architiecture is called Hierarchy of PE(HoPE).and the architecture figure is as follows(figure 1): +----------+ +----+ +---+ |VPN1 Site1|--| |---------------| | +----------+ | | +----------+ | | +-------+ +----------+ |UPE1| |VPN1 Site4|--| | | | +--+ +----------+ |VPN2 Site1|--| | +----------+ | | | |--|PE|--|VPN1 Site3| +----------+ +----+ +----------+ | |-| MPLS | +--+ +----------+ |VPN1 Site4|--|SPE| |NETWORK| +----------+ +----+ +----------+ | | | | +--+ +----------+ |VPN1 Site2|--| | +-------+ | | | |--|PE|--|VPN2 Site3| +----------+ | |--| MPLS |----| | | | +--+ +----------+ +----------+ |UPE2| |NETWORK| | | +-------+ |VPN2 Site2|--| | +-------+ +---+ +----------+ +----+ figure 1: Hierarchy of PE Architecture Several UPE and SPE formed the Hierarchy of PE,which provide the conventional function of PE in "Plane Model"(rfc 2547),and their respective functions are as follows: UPE maintains only the routes of the VPN sites which is directly connected with UPE,it doesn't maintain the specific routes of the remote VPN sites or only maintain the aggregate routes,SPE maintains the routes of all the VPNs attached to the SPE or the UPEs connected with the SPE.UPE distributes the inner MPLS labels for the routes in the sites directly connected with it,and advertise the labels concomitant with the VPN routes through MP-BGP to SPE ,SPE doesn't advertise the routes in the remote VPN sites to UPE,it only advertises the VRF default route or aggregate routes to UPE,and the routes is concomitant with the MPLS labels. MP-IBGP or MP-EBGP can be applied between UPE and SPE,while MP-IBGP is applied,SPE should act as the Route Reflector(RR) for all the UPEs collected to it,and UPE plays the role of Client of this RR,but SPE doesn't act as the RR for other PEs. If MP-EBGP is applied between MP-EBGP,the AS number of the UPEs should be the private AS number(64512~65535).In fact,the Hierarchy of PE can be handles with the rules of Confederation,in which case every confederation AS is composed of only one BGP Speaker, that is the UPE collected with the SPE. The packet forwarding between SPE and UPE is based on the labels,so only one interface is needed between them,this interface can be a physical interface,or sub-interface,such as VLAN,PVC,tunnel such as GRE or LSP.When tunnel is applied between UPE and SPE,an IP/MPLS network can be deployed between them. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 3] Draft November 2002 Hierarchy of PE plays all the functions of the normal PE, there is no difference between them when looked outside,so this "special" PE can coexist with other PEs in the MPLS network to build BGP/MPLS VPN. 2. Working Principle This section specifies the working principle of HoPE including the maintaining and advertising of VPN routes,distribution of MPLS labels,and packet forwarding. 2.1 VPN routes SPE can establish MP-BGP neighborship with UPE,if they are administered by the same service provider(SP),they can be MP-IBGP neighborship,otherwise should establish the MP-EBGP neighorship. In the MP-IBGP case,if there exists several UPEs collected with an SPE belong to the same VPN,SPE acts as the Route Reflector for the connected UPEs,otherwise SPE act as the convergent PE for all the UPEs collected with it.Route-Target lists are used to select the right VPN routes from other PEs as the normal "Plane Modle" BGP/MPLS VPN(RFC 2547bis),while only SPE will exchange the route information with other PEs,UPE should send the import route target list to SPE,SPE converges the route target lists and derives the HoPE-wide import route target list,with this HoPE-wide import route target,SPE can select the right VPN routes which belong to the VPNs which have the sites attached to the SPE directly or through UPE. This HoPE-wide import route target list can be configured manually or derived dynamically between SPE and UPEs.The dynamic mechanism is as follows: UPE advertises the ORF(Outbound Route Filter)[BGP-ORF] to SPE through Route Refresh(RFC 2918) message,and an extended community list is included in the ORF item,the content of the extended community list is the aggregation of the import route target lists of all the VRFs in the UPE,and SPE converges all the import route target lists received from the UPEs connected with SPE and derive the HoPE-wide import route target list. In MP-EBGP case,SPE should derive the HoPE-wide import route target list all the same with the mechanism as above.In general,UPE should adopt the private AS number in VPN routes advertised to SPE.When SPE advertised the routes to other PEs,it should omit the private AS. The scheme in which SPE connected with part of UPEs through MP-IBGP, and to the other part UPEs through MP-EBGP is permitted,then SPE acts as RR and convergent PE at the same time. UPE selects its own VPN routes by match its own import route target list with the export route target list attached with VPN routes respectively. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 4] Draft November 2002 SPE advertises the VRF default route or aggregate routes(according to which UPE transfers the VPN packet to SPE) to UPE,this default VRF route can be formed dynamically or configured manually.When formed dynamically,it can be filtered by the ORF mechanism mentioned above. 2.2 Control Flow(Route Advertising and Label Distribution) This section specifies the mechanism the network distributing the labels for the routes in the VPN sites.The following figure (Figure 2) signifies the control flow between VPN1 site1 and VPN1 SITE2,the control flows(route and label distribution) in the two directions are different,there are four steps in every direction, labeled (1) through (4) in the direction from VPN1 SITE2 to VPN1 site1,and labeled (5) through (8) in the direction from VPN1 site1 to VPN1 SITE2. | (4) | (3) | (2) | (1) | |<-------|<------|<--------------|<-----| v v v v v +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ |VPN1 Site1|-|CE1|---|UPE |---|SPE|---| P |---|PE|--|CE2|-|VPN1 SITE2| +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ ^ ^ ^ ^ ^ | (5) | (6) | (7) | (8 ) | |------->|------>|-------------->|----->| Figure 2: The control flow(route and label distribution) In Figure 2,the meanings of (1) through (8) are as follows: Label (1) through (4) specifies the procedure in the direction from VPN1 SITE2 to VPN1 Site1: (1) CE2 advertises a route in the VPN1 SITE2 to PE; (2) PE distributes an inner MPLS label for this route;PE advertises this route concomitant with the inner label to SPE through MP-BGP , and the relevant export route target list attached with the route; (3.a) SPE matches the export route target list in the received route with the HoPE-wide import route target list to decide whether or not import the VPN route,in this case,they can be matched,then SPE will import the received VPN route. (3.b)At the same time SPE will match the export route target list in the received route with the import route target list advertised by VRF in UPEs connected with SPE,in this case, the import route target list of the VRF in UPE corresponding to VPN1 Site1(called VRF1) will match,then SPE will advertise the default VRF1 route to UPE,with the inner MPLS label distributed by PE attached; (4) UPE advertise this route to CE1 through the route protocol(RIP, OSPF,BGP,or default route) between CE1 and UPE. Label (5) through (8) specifies the procedure in the direction from VPN1 SITE2 to VPN1 Site1: (5) CE1 advertises a route in the VPN1 site1 to UPE; Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 5] Draft November 2002 (6) UPE distributes an inner label for this route;UPE advertises this route to SPE through MP-BGP with the inner label; (7) SPE replaces the inner label distributed by UPE with another inner label distributed by SPE,then advertises this route to PE through MP-BGP with the new inner label attached; (8) PE distributes the route to CE2 with no label attached. Of course,the LSP should be established between SPE and PE in two directions respectively,This mechanism is the same as RFC 2547bis. The procedure of forwarding VPN packet with the two labels detailed in section 2.3. 2.3 Data Flow(Label Operation and Packet Forwarding) This section specifies the mechanism of forwarding the VPN packets in the network with the route and label information derived by section 2.2. The following figure(Figure 3) signifies the data flows between VPN1 site1 and VPN1 SITE2,the data flows(Label Operation and Packet Forwarding) in the two directions are different,there are five steps in every direction,labeled (1) through (5) in the direction from VPN1 SITE2 to VPN1 site1,and labeled (6) through (10) in the direction from VPN1 site1 to VPN1 SITE2. | (10) | (9) | (8) | (7) | (6) | |<-------|<------|<--------|<-----|<-----| v v v v v v +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ |VPN1 Site1|-|CE1|---|UPE |--|SPE|---| P |---|PE|--|CE2|-|VPN1 SITE2| +----------+ +---+ +----+ +---+ +---+ +--+ +---+ +----------+ ^ ^ ^ ^ ^ ^ | (1) | (2) | (3) | (4) | (5) | |------->|------>|--------|----->|----->| Figure 3: Data Flow(Label Operation and Packet Forwarding) In Figure 3,the meanings of (1) through (10) are as follows: Label (1) through (5) specifies the forwarding procedure in the direction of VPN1 Site1 visit VPN1 SITE2: (1) When the VPN packet of VPN1 Site1 visit VPN1 SITE2 arrived to CE1,CE1 forward the packet to UPE based on the default route or the route derive from dynamic route protocol between CE1 and UPE specified in the (4) of section 2.2. (2) UPE push the inner label based on the default VRF route,forward the VPN packet to SPE,the inner label and the default VRF route are specified in the (3) of section 2.2. (3) SPE POP the inner label pushed by UPE specified in (2) above,and look up the VRF route,push the new inner label which distributed by PE specified by (2) of section 2.2,then push the outer label distributed by P and forward the VPN packet to P,in backbone network, all the P router in the path of LSP from SPE to PE swap the outer label and forward the VPN packet through this LSP until the packet arrived to PE,or optionally the P router pen-ultimate-hop pop the label. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 6] Draft November 2002 (4) The P router pen-ultimate hop to PE POP the outer label,forward the VPN packet to PE. (5) PE POPs the inner label,and forwards the VPN packet to CE2,then CE2 forwards the VPN packet to the VPN1 SITE2. Label (6) through (10) specifies the forwarding procedure in the direction of VPN1 SITE2 visit VPN1 Site1: (6) When the VPN packet of VPN1 SITE2 visiting VPN1 Site1 arrives to CE2, CE2 forwards the packet to PE based on the default route or the route derived from dynamic route protocol between CE2 and PE specified in the (8) of section 2.2. (7) PE PUSHes the inner label distributed by SPE specified in (7) of section 2.2 based on the VRF route,then PUSHes the outer label distributed by P and forwards the VPN packet to P,in backbone network,all the P router in the path of LSP from PE to SPE swaps the outer label and forwards the VPN packet through this LSP until the P router pen-ultimate hop to SPE. (8) The P router optioanlly pen-ultimate hop to SPE POP the outer label,forward the VPN packet to SPE. (9) SPE swaps the inner label in the VPN packet with the inner label distributed by SPE with the new inner label distributed by UPE specified in (6) of section 2.2,then forward the VPN packet to UPE. (10) UPE POPs the new inner label,forwards the VPN packet to CE1,then CE1 forwards the VPN packet to the VPN1 Site1. 3. Interface between UPE and SPE UPE can connect with SPE with any type of interface and sub-interface,even with tunnel interface,in this case,UPE can connect with SPE through an IP/MPLS network,and because SPE and UPE are MP-BGP peers,the routes can be advertised directly through TCP connection.In MP-EBGP case,UPE and SPE can set up EBGP peers across the IP network or MPLS network by Multi-hop EBGP,when UPE or SPE forwarding the VPN packets with the label,they must pass a tunnel, if the tunnel is GRE,MPLS encapsulation must be supported;If the tunnel is LSP,the network between UPE ang SPE must be MPLS network, LDP/CR-LDP or RSVP-TE must be supported in UPE and SPE. 4. Nesting of HoPE One HoPE can be composed of a SPE and UPEs connected with the SPE, or be composed of a high-level SPE and HoPEs connected with it and build up a new HoPE.This build is called nesting of HoPE,and this kind of nesting can be done for many times.Thus the former HoPE connect with the high-level SPE acts as a role of UPE,and the new HoPE can connect with a single UPE too.Figure 4 in the following signifies a three-layer HoPE,and call the PE in the middle layer as MPE(Middle-level PE). Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 7] Draft November 2002 +----------+ +----+ +---+ |VPN1 Site1|--| |---------------| | +----------+ | | +----------+ | | +-------+ +----------+ |UPE1| |VPN1 Site4|--| | | | +--+ +----------+ |VPN2 Site1|--| | +----------+ | | | |--|PE|--|VPN1 Site3| +----------+ +----+ +----------+ | |-| MPLS | +--+ +----------+ |VPN1 Site4|--|SPE| |NETWORK| +----------+ +----+ +----------+ | | | | +--+ +----------+ |VPN1 Site2|--| | +-------+ | | | |--|PE|--|VPN2 Site3| +----------+ | |--| MPLS |----| | | | +--+ +----------+ +----------+ |UPE2| |NETWORK| | | +-------+ |VPN2 Site2|--| | +-------+ | | +----------+ +----+ | | | | +----------+ +----+ +----+ | | |VPN1 Site4|--|UPE3|--|MPE |------| | +----------+ +----+ +----+ +---+ (Nesting of HoPE) figure 4: Nesting of HoPE Between SPE and MPE,and between MPE and UPE run MP-BGP,if run MP-IBGP,then SPE worked as the route reflector for all the MPEs,and MPEs worked as the route reflector for all the UPEs which connected with it,and MP-BGP advertises all the VPN routes of the underlayer PEs to the upperlayer PE,and advertise the default VRF route or the aggregate route of the upperlayer to the underlayer PE. So SPE maintains all the VPN routes of VPNs attached to the whole HoPE,and the MPE maintains the VPN routes of UPEs connected with this MPE.UPE maintains the VPN routes of sites connected with this UPE. SPE advertises the default VRF routes with the label attached to MPE,MPE replaces this label with the new label,and advertises this route with the new label attached to UPE. The upperlayer PE should create a HoPE-wide global import route target list,filter the VPN routes that don't belong to the VPNs connected with this upperlayer PE.MPE converge all the import route target lists of the UPEs connected with this MPE,and SPE converge all the converged import route target lists of the MPEs connected with this SPE.And this convergence can be configured statically or derived dynamically,in the latter case,MPE should forward the import route target list of MPE to SPE through ORF. When the VPN packet from the local site of HoPE is forwarded to UPE, UPE look up the relevant default VRF route,push the label and forward the packet to MPE,MPE POP the label,look up the default VRF route or aggregate route to SPE,PUSH a new label forward the packet to SPE,SPE POP this label,look up the VRF forwarding table,PUSH the inner label,and the outer label the P router distribute for this route,then follow the RFC 2547bis forwarding procedure. Because MPE has distributes the inner label for the destination address of the VPN packet from the remote site,when the remote VPN packet is forwarded to SPE through the MPLS network following the RFC 2547bis forwarding procedure. SPE swap the inner label,forward this packet to MPE following the similar procedure,MPE swaps the inner label and forwards this packet to UPE,then UPE POP the inner label and forwards this packet to the local site. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 8] Draft November 2002 5. Multi-Homing UPE One UPE can connects with several SPEs,in this case UPE is called Multi-Homing UPE,all the SPEs advertise the default VRF routes to this UPE,and UPE selects the best one or treat them as ECMP(Equal Cost Multi-Path) and share the load among them.UPE advertised the VPN routes to all the SPEs,it can advertise all the VPN routes to all the SPEs,or it can advertise one part of VPN routes to one SPE, the other part to the other and share the load among the SPEs. 6. Backdoor link between UPEs A kind of backdoor link can be setup between UPEs,so that the sites connected with these two UPEs can communicate with each other directly without passing through the SPE.And these UPEs can be those connect to the same SPE,or can be those connect with the different SPE,these UPEs advertise the VPN routes to each other through MP-BGP,The control flow and data flow are the same with RFC 2547bis Procedures,and even they can cross a ip/mpls network,and the packet can pass through a tunnel such as GRE or LSP. 7. UPE/CE routing protocol As specified in RFC 2547bis,RIP/OSPF/ISIS/EBGP can be routing protocol between UPE/CE.If RIP/OSPF/ISIS runs between UPE and CEs, UPE should run each routing instance for every site.Especially,if OSPF/ISIS runs between UPE/CE,the procedure following [VPN-OSPF] except that the sham-link end-point is different. 7.1 Sham-link in HoPE If OSPF/ISIS runs between UPE and CE,and the backdoor link exists between a VPN site attached to HoPE and a VPN site attached to the remote PE,and OSPF runs on the backdoor link,the above mentioned two sites belong to the same OSPF area,then Sham Link shoud be created between the UPE in the HoPE and the remote PE.The site attached to HoPE can access the routes in the remote sites without traverse the SP backbone,if it can only get the default routes or aggregated routes through UPE,the routes through the backdoor link is preferred to the routes through UPE,and at most time it is not desirable.To address the problem,you can select one of the following two alternatives: --Aggregate the routes throught the backdoor at the same granularity,and make the CE-UPE link to be preferred by configuring the metric. --Remote PE distribute the routes in the remote sites to UPE through sham-link,and configure the larger metric to the backdoor link,then the CE-UPE link will be preferred. 8. The Forwarding Procedure in Some Special Cases In one case that SPE connects with two UPEs called UPE1 and UPE2,and these two UPEs connect with two sites called site1 and site2 respectively,and site1 and site2 belong to the same VPN and visit to each other through SPE.The forwarding procedure is as follows:When Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 9] Draft November 2002 the packet sent from site1 arrived to UPE,UPE pushes the label based on the default route and forwards it to SPE,SPE POPs this label,then looks up the VRF route table,PUSHes the label distributed by UPE2 and forwards it to UPE2,and UPE2 POPs the label,forwards it to site2,and in the opposite direction,vice versa. In another case that SPE connects with one UPE and one CE,CE connect with site1,UPE connect with site2,site1 and site2 belong to the same VPN.The forwarding procedure is as follows: (1)When the packet with no label sent from site1 arrives to SPE through CE, SPE looks up VRF route table,and pushes the label distributed by UPE,forwards it to UPE,UPE POPs this label,forwards it to Site2. (2)When the packet originated from Site2 arrives to UPE,UPE forwards the packet to SPE on the basis of default or aggregate route,SPE then looks up the VRF route table,POPs the label,forwards it to Site1 as an IP packet. 9. Layered BGP/MPLS VPN with HoPE In [2547bis],all the PEs of the whole BGP/MPLS VPN is in the same layer(though in the Route Reflector situation,the VPN structure is somewhat layered,but it is hierarchy of RR and PE,not that of PEs), which is a plane structure.This VPN structure is difficult to attach to the VPN customer in the different layer of network,If a customer would like to access the existing VPN with a large amount of VPN routes,his CE router must be attached to the PE which can accomodate the whole VPN routes,if this customer is situated in the lowest layer of network,where is faraway from the nearest PE,then maybe the only way to attach this customer to PE is laying the long leased line between the CE and PE.If there are many different customer who want to access this VPN,then such long leased line to connect the CEs and the PEs,not to speak the expensive cost,these long leased lines make the network structure more complicated and scalability difficult. In investigation of the BGP/MPLS VPN deployment situation,the desire of the lower layer network customer to access in the BGP/MPLS VPN is universal,such as subbranch offices of the different Government department of nationwide corporation.To address this problem,it is desirable to organize the whole VPN with the different sub-VPN at different domain or different layer,the PEs in the different sub-VPN only maintain the VPN routes of that sub-VPN,with the exception in the PE connects to the higher layer sub-VPN,by which PE the lower layer sub-VPN connect to the higher layer sub-VPN with the aggregated routes and advertise the default VRF routes to the higher layer sub-VPN,and the higher layer sub-VPN gets to the lower layer sub-VPN with such default VRF routes.Then the different sub-VPN can attach the customer at different network layer to the nearest PE which only needs to maintain the VPN routes of that sub-VPN,and only one of such PEs connect to the higher layer sub-VPN with aggregated routes,and this particular PE takes on the part of Route Reflector for the whole PEs in the sub-VPN it belongs to.This can be illustrated as following figure(Figure 5). Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 10] Draft November 2002 ____ ___ ____ _/ \___/ \ _/ \__ / \__/ \_ / \ / BGP/MPLS VPN (core Network) | \ suv-VPN / \ ___ ___ __ _/ \_/ \____/ \___/ \____/ |PE| |PE| |__| |__| ________ \ \ ________ _/ \__ _\_ \____/ \__ /suv-VPN \_|PE|(RR for sub-VPN) |PE| suv-VPN \____ / |__| |__| \ /BGP/MPLS VPN \\ ^||/(Convergence Layer)| \(Convergence Layer)|\ Aggregated |||\ BGP/MPLS VPN __/ \ ___ ____/ \ routes ||| \ ___ _/ \_/ \____/ \ ||| \_/ \____/ \__ |||Default VRF route ________|PE| __|V ______ _/ |__| |PE| _/ \__ / \__ |__|/ \ / suv-VPN \ / suv-VPN \ /(Access Layer) | /(Access Layer) | \ BGP/MPLS VPN __/ \ BGP/MPLS VPN __/ \ ___ _/ \ ___ _/ \_/ \____/ \_/ \____/ Figure 5. Layered BGP/MPLS VPN with nesting of HoPE The requirement of performance and capacity for the PEs belong to the core network sub-VPN can be different from that for the PEs belong to the convergence layer sub-VPN and that for the PEs belong to the access layer sub-VPN,so this solution can address the bottleneck of scalability of BGP/MPLS VPN in the lower layer network,and this problem is not touched at all in [2547BIS]. The work principle of control plane and data plane between sub-VPNs follows the procedure detailed in section 2 through section 8,with the nesting of HoPE involved. 10. Interoperability This solution doesn't introduce any backward compatibility problem with [2547BIS],the only difference in the label processing in SPE is that when it receive the labeled packet from UPE or MPE(in nesting of HoPE situation),SPE will swap the outer label with the label the remote PE advertised to it,so the solution can operate with [2547BIS] without any difficulty.You can deploy some PEs of the whole BGP/MPLS VPN with HoPE,and the other PEs with [2547BIS]. This deployment is verified as efficiently in the Service Provider. 11. Security Consideration The level of security provided by this architecture is identical to that provided by the RFC 2547bis,there is no security problem introduced by HoPE. 12. Updation from last version a. Add the interoperability statement of HoPE and [2547bis]; b. Add the section to resolve the scalability of BGP/MPLS VPN in access the customer in the lower layer network. c. Correct some typo error. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 11] Draft November 2002 13. Acknowledgements The authors would like to thank Li Hejun, Cao Xuegui,Chang Wenjun, We are very appreciated for their support 14. References [RFC2026] Bradner, S., "The Internet Standards Process--Revision 3", BCP 9, RFC 2026, October 1996. [BGP-ORF] Enke Chen,Yakov Rekhter,"Cooperative Route Filtering Capability for BGP-4",draft-ietf-idr-route-filter-06.txt. [BGP-RR] Chen, E., "Route Refresh Capability for BGP-4", RFC2918, September 2000 [RFC2547] E. Rosen, Y. Rekhter, BGP/MPLS VPNs, RFC 2547,March 1999. [2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", work in progress. [VPN-OSPF] Rosen, Psenak and Pillay-Esnault, "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", February 2003, draft-rosen-vpns-ospf-bgp- mpls-06.txt 15. Author's Address Li Bin D201 ,HuaWei Bld. No3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : l.b@huawei.com Dong Weisi C401 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : dongws@huawei.com Chen Yunqing China Telecom Beijing Research Institute No.52,Hua Yuan North Road, Haidian District,Beijing,100083,China Tel:+86-10-62304554 Fax:+86-10-62304157 E-mail:chenyunqing@vip.sina.com Li Defeng D201 ,HuaWei Bld. No.3 Xinxi Rd. Shang-Di Information Industry Base, Hai-Dian District BeiJing P.R.China Zip : 100085 Email : lidefeng@huawei.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 12] Draft November 2002 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Libin, et al. Hierarchy of PE Device in BGP/MPLS VPN [Page 13]