BGP-based Routing Control Platform (RCP)
The Routing Control Platform (RCP) is a centralized forwarding solution enabling the collection of a network topology map, running an algorithm and selecting preferred BGP route for each router in an Autonomous System (AS). It does this by peering both IGP and iBGP to neighboring routers and communicates the preferred routes using unmodified iBGP. It acts similar to that of an enhanced route reflector and does not sit in the data path. It is a control plane device, separate from the IP forwarding plane. The RCP exhibits the accuracy of a full mesh iBGP design and scalability enhancements of route reflection without sacrificing route selection correctness. A potential issue with route reflection is that AS exit best path selection (hot potato routing) is performed by route reflectors from their IGP reference point, which in turn gets propagated to all RR clients scattered throughout the network. The best path selected may not be optimal for many RR clients as it really depends on where the RR client is logically placed in the network. You may also encounter MED-induced route oscillations. The Routing Control Platform aims to solve this problem.
There are proposed enhancements to RCP by replacing iBGP with the OpenFlow protocol, providing additional capabilities beyond next-hop forwarding. This may be useful when looking for a BGP-free edge core and will be addressed in later posts. The following discusses the original Routing Control Platform proposed by Princeton University and AT&T Labs-Research.
iBGP and eBGP
Routers within an AS exchange routes to external destinations using internal BGP (iBGP) and routers peering external to their AS use external BGP (eBGP). In order to propagate external destinations, all BGP speakers within a single AS must be a fully mesh. For loop prevention, the original BGP design states reachability information learned from an iBGP router can not be forwarded to another iBGP router inside the full-mesh. eBGP designs use AS-PATH for loop prevention. All routing protocols, not just BGP, require some mechanism to prevent loops.
With iBGP, the maximum number of iBGP hops an update can traverse is 1.
To combat the scalability concerns with an iBGP full mesh design, in 1996, a number of alternatives, such as route reflection and confederations were proposed. Both of these enable hierarchies within the topology. However, there are some drawbacks to route reflection as it may result in path diversity and network performance side effects. There is a trade-off between routing correctness and scalability. With iBGP full mesh designs, if one BGP router fails it will have limited impact. An update travels only one i-BGP hop. However, if a route reflector fails it has a large network impact. All iBGP peers peering with the route reflector are affected.
With a route reflection design, an update message may traverse more than one route reflector before reaching the desired i-BGP router. This may have adverse effects such as prolonged routing convergence. Probably one of the most important adverse effects of route reflection is reduced path diversity. A high path diversity can increase resilience while low path diversity will decrease resilience. Since a route reflector only passes its best route, all clients peering with that route reflector use the same best path for that given destination. Proper route reflector placement and design can eliminate some of these drawbacks. We now have path diversity mechanisms such as the ADD Path capability and parallel peerings for better route reflection design. These were not available during the original RCP proposal.
Routing Control Platform (RCP)
The RCP consists of a number of components, 1) Route Control Server ( RCS), 2) BGP Engine, and 3) IGP viewer. It has similar characteristic to the newer BGP SDN platform proposed by Petr Lapukhov but has an additional IGP viewer function. Petr’s BGP SDN solution proposes a single Layer 3 protocol with BGP – pure Layer 3 data centre. The RCP platform has two types of peerings both IGP and iBGP. It obtains IGP information by peering with IGP and learns BGP routes by peering with iBGP. The RCS component then analyzes the information from the IGP and BGP viewer to compute the best path and send back via iBGP. In the diagram below, notice how the IGP Viewer only needs one peering into each partition.
Since link state protocol uses reliable LSA flooding, the IGP viewer has a complete up-to-date view of the topology. In order to keep the IGP viewer out of the data plane, higher costs are configured on the links to the controller. As discussed, the BGP engine creates iBGP session to other BGP speakers that are directly reachable or via the IGP. From combining both these elements, the RCS has full BGP and IGP topology information and is able to make routing decisions for routers in a particular partition. It’s important the RCP has complete visibility, otherwise it could assign routes that create black holes, forwarding loops or other issues that could prevent packets reaching their destinations.
RPC uses a centralized controller to extract the topology and make routing decisions. These decisions are then pushed down to the data plane nodes, to carry out data packet forwarding. It aims to offer the correctness of full mesh iBGP designs and scalability of route reflector designs. It uses iBGP sessions to peer with BGP speakers, learn topology information and send routing decisions for destination prefixes. Previously discussed, a route reflector design only sends its best path to clients, which limit path diversity. However, the RCP platform overcomes this route reflector limitation and sends each router a route it would have selected in an iBGP full mesh design.