Progress in standardization of BGP/MPLS VPN

In March 1999, the Internet Task Force (IETF) published a RFC2547 by Cisco, describing a way for operators to provide virtual private network (VPN) services to users through an IP backbone network. This method uses an extended BGP (Boundary routing protocol) to distribute VPN routing information through the carrier backbone network, and uses Multiprotocol token switching (MPLS) to forward VPN traffic between the VPN user sites. The main purpose of this method is to provide enterprise network outsourcing service for operators. This approach to the enterprise is very simple, while the operator is scalable and flexible, providing IP services while providing VPN business, thereby increasing revenue.
Ppvpn (Provider provisioned VPN) refers to the VPN,IETF Ppvpn Working Group, which is engaged in the management and implementation of the operator, to work on this research, including the following three ways of VPNs: RFC2547 based Bgp/mpls VPN ( Rfc2547bis, the RFC2547 will be abolished, virtual routers (VR) and Port based VPNs (such as operators providing atm/fr/ethernet on IP two-tier interfaces). In addition, the workgroup is studying the interconnection of VPN across self-made domain (as) or across carriers.
Compared with RFC2547, the main change of Rfc2547bis (draft as of July 2002) lies in perfecting the instructions of distributing VPN routes through BGP, increasing the maintenance of proper route isolation, operator operators, trans-operator, VPN management, Internet access and so on. This article will focus on several issues that users are most concerned about: how to cross the autonomous system, how to access the Internet, security, scalability.
First, the structural model
Bgp/mpls VPN is a network based VPN, operators provide users with three-tier IP routing services, applicable to the following scenarios.
For customers:
Customers do not want to manage routing backbone networks. Customers may use routing within its site, but they want to outsource routing between sites to operators.
The customer wants the carrier to build the backbone, and its routing is completely transparent to the user route. If a customer has a routing infrastructure within its site, he does not want its site routing algorithm to know any part of the carrier backbone, unless it is a PE router that is connected to the site. In particular, the client does not want its routers to understand the structure of the carrier backbone, or the tunnel topology that is used to traverse the carrier backbone network.
Customers want to send IP packets within their fully dedicated VPN.
For operators:
Operators have IP backbone networks, which may be MPLS-enabled.
Operators want to provide a business that meets the requirements of the customer.
Operators do not want to maintain a completely different tunnel overlay topology for each VPN user.
1. CE Equipment
Assume that each user site has one or more customer edge (CE) devices. With some form of data link (such as PPP, ATM, Ethernet, FR, and GRE), each CE device is connected to one or more carrier Edge (PE) routers. The device that does not associate with CE in the operator network is called "P router".
The CE router only establishes a routing equivalence relationship with the PE directly attached to it and propagates the VPN routing information to each other. Ce does not establish routing adjacency relationship with CE routers in other sites, nor does it exchange routing information directly.
If a site has only one host, then the host can be a CE device. If a site has only one subnet, then the CE device can be a switch. Generally speaking, it can be considered that CE is a router, which can establish adjacency relationship with PE router which is directly connected with it. After establishing the adjacency relationship, CE notices the routing information of the VPN local site to PE, and learns the routing information of the other VPN site from PE.
2. PE Router
PE router and CE equipment connection, the end of the connection is PE interface or sub-interface (PVC, VLAN, GRE tunnel, etc.), the other end is CE equipment. Each PE maintains a virtual route forwarding (VRF) for each site that is directly connected to it, and maps each client's connection to a specific VRF. When a PE maintenance path is made up of information, it is only necessary to maintain the routing of the VPN directly connected to it. When PE receives a package from CE because it knows the interface or sub-interface that the packet arrives at, it is possible to determine which VRF should be used to process the package.
The mode of exchanging routing information between PE router and CE router can be static route, RIPV2, OSPF or EBGP, etc. After learning from the CE router to the local VPN route, the PE router uses internal BGP (IBGP) to exchange VPN routing information with other PE routers. Deploying a routing reflector can enhance the scalability of the model.
3. P Router
The P router is any router in the operator's network that is not connected to a CE device. When forwarding VPN data traffic between the PE routers, the p router acts as an MPLS transfer LSR. Because forwarding traffic over an MPLS backbone uses a level two tag stack, the P router only needs to maintain the route to the carrier's PE router and does not need to maintain specific VPN routing information for each client site.
Two, across the different operators
Because of the vast territory of our country, the current national IP backbone network is often divided into multiple autonomous systems (AS). As is a group of routers under the same technology management that shares a set of routers that share the same routing policy.
When two sites of a VPN are connected to different as, the PE routers that are connected to the VPN cannot maintain IBGP connections between each other (or through a common route reflector) and therefore need to use external BGP (EBGP) to distribute Vpn-ipv4 addresses in some way. Rfc2547bis proposed the following three options, the scalability of which increased in turn. Based on our understanding and testing, most device manufacturers are already able to support option 2.
1. VRF-TO-VRF connections on the AS boundary router
In this scheme, a PE router in as is directly connected to a PE in another as. The two PE routers will be connected through multiple sub-interfaces, requiring at least one sub-interface for each VPN routed between as. Each PE is considered to be a CE router. That is, PE associates the Seed interface with a VRF and uses EBGP to distribute unmarked IPV4 addresses to each other. The advantage of this scheme is that it does not require that the two-as border routers support MPLS, but the scalability is not good, because each PE needs to be loaded into the other PE in the route, PE is a heavy burden.
2. Vpn-ipv4 routing using EBGP distribution tags between adjacent as
In this way, the PE router uses IBGP to redistribute the tagged Vpn-ipv4 route to an as border router (ASBR) or to a routing reflector (at which point ASBR is a client). The ASBR then uses EBGP to redistribute these tagged routes to the ASBR in another as, which then distributes the routes it receives to the PE router in the as or to another ASBR, in which case another ASBR continues to distribute the routes.
The process requires an LSP to exist between the entry PE of a package and its export PE. Therefore, there must be a trust relationship between the as groups along this path. Similarly, a contract must be signed between this group of operators to specify which routing destination (RT) route the router should receive.