Border Gateway Protocol
The Border Gateway Protocol (BGP), Version 4, is an exterior routing protocol. Most notably BGP is the only exterior routing protocol used in the public Internet for unicast destinations. It is among the central technologies in internet operations.
BGP is not limited to simply unicast TCP - the protocol supports multiple address families. The RFC for BGP speaks of "multiprotocol support", however the distinction is really among TCP/IP related address families such as IPv4 multicast, IPv6 (Uni-cast and Multi-cast), virtual private network address spaces, etc.
A network routed via BGP is divided up into sets of known Autonomous Systems (or an AS) with common rules, which may be implemented by different but cooperating organizations. An "AS" is a set of routers and addresses, under one or more administrations, which presents a common routing policy to the Internet  Each AS has an autonomous system number (ASN), currently 16 bit but being expanded to a 32 bit space.
Note that capitalized, "the Internet" is the public network. Lower-case internet, however, can be used to describe BGP-connected non-public networks, such as secure banking or military multi-AS networks.
Characteristics of an exterior routing protocol
BGP differs in several ways from interior routing protocols. First, it is a protocol that determines that a route exists to a destination, but not necessarily the best route in terms of bandwidth or other metrics. Instead, in makes a decision that the destination is reachable, from the sending point in a given autonomous system (AS), through a path of zero or more intermediate AS, to the destination AS, with the path complying with the policies of each AS along the way. Second, BGP gives policy control available from no other routing protocol.
A common, but often incorrect, definition is that BGP transmits policies rather than routes. In most cases, it actually carries the information on which policy information locally configured in a router execute policies; the only true policies carried use an advanced feature called outbound route filtering. It is often easier to understand the nature of policies by studying the Routing Policy Specification Language (RPSL), which provides abstractions of problems to be solved by BGP. 
BGP used to coordinate the routers of a single autonomous system is called interior BGP (iBGP), but is not intended to replace interior routing protocols such as Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (ISIS).
Errors in configuring BGP can go well beyond your AS, and affect the entire Internet. Typically, when an enterprise first uses it, its "upstream" Internet Service Provider, which gives it access to the global Internet, provides considerable guidance. See Border Gateway Protocol/Operations.
Internal and external BGP
When a router speaks BGP with a router in its own AS, it is speaking internal BGP (IBGP). If it is speaking to a router in another AS, it is speaking external BGP (EBGP).
eBGP routers can have different rules for advertising and accepting NLRI at the granularity of each neighbor AS, or indeed down to the granularity of routers or router interfaces.
Inside an AS, all BGP-speaking routers must have a common view of the exterior routing information. In small AS, this is achieved with a full mesh topology among the BGP speakers, but, in a large AS, the overhead of maintaining full mesh connectivity can be prohibitive. There are advanced techniques for making such AS more scalable, such as route reflectors and confederations. See Border Gateway Protocol/Advanced.
Principles of BGP advertising and acceptance
After creating a BGP session, pairs of BGP-speaking routers exchange network layer reachability information. When a router advertises a route in its NLRI, it offers connectivity to it, or at least to another AS closer to the destination. When a router withdraws a route, it will no longer forward to that destination.
Functions of individual BGP routers
A given BGP-speaking router may have one or more functions for Internet connectivity. virtual private network support, or both.  Minimally, the functions, for a given AS, break into edge and AS core functions.
BGP router functions in Internet connectivity: Provider-edge
A provider edge router is a router at the edge of a provider's network that speaks eBGP to a BGP speaker in another AS. The other speaker may belong to another provider, or to a customer. Especially if the router belongs to another provider, The traffic that transits this router may be destined to or may originate from non-adjacent autonomous systems. In particular, the MED values used in the Provider Edge Router would not be visible in the non-adjacent autonomous systems. Such a router will always speak eBGP, and will speak iBGP unless it is the only BGP speaker in the AS.
BGP router functions in Internet connectivity: Subscriber-oriented
A subscriber edge router is at the edge of the subscriber's network, and speaks eBGP to its provider's AS(s), or to the router of a peer AS. The router belongs to an end user organization that may be multihomed, and that carries traffic only to and from that end user AS (with the caveat that it might carry additional traffic if it is in a mutual backup relationship with a peer. Such a router will always speak eBGP and may speak iBGP.
This definition of an enterprise border router (which is what most Subscriber Edge Routers are) is practical rather than rigorous. It is meant to draw attention to the reality that many enterprises may need a BGP speaker that advertises their own routes and accepts either default alone or partial routes. Subscriber routers do not always need a full Internet routing table.
An core router is a provider router internal to the AS, speaking iBGP to other routers in that AS. It may also participate with other routers in the AS in speaking an interior routing protocol, If the AS is in the default-free zone (DFZ), it will carry full Internet routes, plus some number of additional routes local to the AS.
BGP/MPLS VPN routers
BGP is also used as a signaling protocol to carry arbitrary information that may have little to do with exterior routing. A major application for service provider BGP is carrying setup information for setting up Multiprotocol Label Switching (MPLS)-based virtual private networks (VPN). For such VPNs, a generalize PE routers need to carry all routes in all VPNs that traverse it. If the physical PE also provides public Internet traffic, it may need a full Internet routing table. The CE routers need to carry the routes of its own VPN. 
P routers in a VPN provider may only participate in the interior routing protocol and may not speak BGP of any sort.
There are limitations in today's BGP, due to the Internet evolving in unexpected ways, and the historical reality that the original Internet was a place of trust, without many security challenges.
Eventually, BGP will no longer meet the requirements of ever-growing global Internet routing. There is still much research on how the next generation of global Internet routing will actually work, but whatever that may be, it is far more likely that it will be introduced as a form of evolution, rather than of a revolutionary approach unrealistically requiring every Internet-connected router or computer to change.
There has been, however, an effort, in the Internet Research Task Force (IRTF), to collect a series of expert opinions on the requirements for the next generation. . By no means did this IRTF document identify all the problems, much less the solutions, but it is a place to start thinking about the next generation. Incidentally, Internet Protocol version 6 (IPv6) is not a panacea for global routing. In some ways, it probably will help. In other areas, it has created even more challenges, such as needing new paradigms for multihoming: the connection of a given network node to more than one service provider network, typically for increased fault tolerance.
- Rekhter (ed.), Y.; T. Li (ed.) & S. Hares (ed.) (January 2006), A Border Gateway Protocol 4 (BGP-4), Internet Engineering Task Force, RFC 4271
- Hawkinson, J. & T. Bates (July 1996), Guidelines for creation, selection, and registration of an Autonomous System (AS), Internet Engineering Task Force, RFC1930
- Vohra, Q. & E. Chen (May 2007), BGP Support for Four-octet AS Number Space, Internet Engineering Task Force, RFC4893
- Alaettinoglu, C.; C. Villamizar & E. Gerich et al. (June 1999), Routing Policy Specification Language (RPSL), Internet Engineering Task Force, RFC2622
- Meyers D. et al. (August 1999), Using RPSL in Practice, Internet Engineering Task Force, RFC2650
- Berkowitz, H.; E. Davies (ed). & S. Hares et al. (June 2005), Terminology for Benchmarking BGP Device Convergence in the Control Plane, Internet Engineering Task Force, RFC 4098
- Rosen, E. and Rekhter, Y. (February 2006), BGP/MPLS IP Virtual Private Networks (VPNs), Internet Engineering Task Force, RFC4364
- Murphy, S. (January 2007), BGP Security Vulnerabilities Analysis, Internet Engineering Task Force, RFC4272
- Davies, E & A Doria (2007), Analysis of IDR requirements and History, IETF, FDR