Why BGP Uses TCP and IGPs Don't
Recently there was an engaging question posed over on networking-forum.com: Why does BGP use TCP, while interior routing protocols like OSPF and EIGRP do not? There were a number of astute observations made in the thread which followed, and I thought it might be worthwhile to catalog them here.
Convenience
Arguably the most obvious motivation to design BGP to run over TCP is simple convenience. Remember that BGP is essentially just another application layer protocol to the TCP/IP stack; at the time of BGP's creation TCP was already out there and working, so why not take advantage of it? From RFC 4271:
BGP uses TCP as its transport protocol. This eliminates the need to implement explicit update fragmentation, retransmission, acknowledgement, and sequencing.
Security
Unlike other IPv4 routing protocols, BGP does not provide its own security mechanism. Sure, you can secure neighbor adjacencies using MD5 digests, but these aren't actually carried within the BGP header. Rather, security is facilitated by a TCP option defined in RFC 2385, the TCP Authentication Option (kind 19).
This TCP option was originally created specifically to secure BGP adjacencies (which typically have quite long lifetimes), and for a decade or so has worked quite well. However, as MD5 is beginning to show its age, a new RFC (5925) was published just this month to provide a more resilient alternative.
No Need for Neighbor Discovery
Unlike interior routing protocols, BGP has no requirement for dynamic neighbor discovery. As BGP adjacencies are (or more accurately, should be) very carefully weighed design considerations, BGP neighbors must be configured statically at both ends. This is in contrast to a protocol like OSPF, which uses hello packets to automatically discover and form adjacencies with neighbors.
Adjacency Traffic is Always Point-to-Point
A corollary of our last point, we know that BGP unicasts advertisements to each of its adjacent neighbors separately. This is in contrast to interior routing protocols, which typically employ multicast transmissions to more efficiently communicate with one or more other neighbors on a multiaccess segment.
About the Author
Jeremy Stretch is a freelance networking engineer, instructor, and the maintainer of PacketLife.net. He currently lives in Fairfax, Virginia, on the edge of the Washington, DC metro area. Although primarily an R&S guy, he likes to get into everything, and runs a free network training lab out of his basement for fun. You can contact him by email or follow him on Twitter.
Comments
There was also a Google Tech Talk in 2007 about BGP protocol design. Those who don't know it, should really take the time and watch it. The talk is very interesting and entertaining.
To add to Ivan's comment...
Since it is Peer peer basis, there is no need to add multicast into the loop, let alone flooding it on the internet.
TCP pretty much covers when it comes to maintaining connections, so why reinvent the wheel...
Awesome Article!!
I must say I always had this question from the day one I learned that BGP uses TCP 179.
Now I'm much more clear..
Thanks Stretch!!
Well, the primary reason was definitely convenience, sometimes expressed as "don't reinvent the wheel" or (coming from a marketing person) "doing more with less". It makes no sense to reinvent a transport-layer protocol if all you need is reliable transport of data between two IP hosts.
LDP is very similar: it uses UDP multicasts to discover adjacent MPLS-enabled routers, then switches to (unicast) TCP to exchange labels.