2. cnp3-ebook
3. protocols/bgp
4. English
5. Zen

4 ../../protocols/bgp.rst:17
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Transit and stub domains 24/10000 · 24
5 ../../protocols/bgp.rst:19
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The stub domains can be further classified by considering whether they mainly send or receive packets. An `access-rich` stub domain is a domain that contains hosts that mainly receive packets. Typical examples include small ADSL- or cable modem-based Internet Service Providers or enterprise networks. On the other hand, a `content-rich` stub domain is a domain that mainly produces packets. Examples of `content-rich` stub domains include google_, yahoo_, microsoft_, facebook_ or content distribution networks such as akamai_ or limelight_. For the last few years, we have seen a rapid growth of these `content-rich` stub domains. Recent measurements [ATLAS2009]_ indicate that a growing fraction of all the packets exchanged on the Internet are produced in the data centers managed by these content providers. 812/10000 · 812
6 ../../protocols/bgp.rst:21
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Domains need to be interconnected to allow a host inside a domain to exchange IP packets with hosts located in other domains. From a physical perspective, domains can be interconnected in two different ways. The first solution is to directly connect a router belonging to the first domain with a router inside the second domain. Such links between domains are called private interdomain links or `private peering links`. In practice, for redundancy or performance reasons, distinct physical links are usually established between different routers in the two domains that are interconnected. 590/10000 · 590
7 ../../protocols/bgp.rst:27
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Interconnection of two domains via a private peering link 57/10000 · 57
8 ../../protocols/bgp.rst:33
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Such `private peering links` are useful when, for example, an enterprise or university network needs to be connected to its Internet Service Provider. However, some domains are connected to hundreds of other domains [#fasrank]_ . For some of these domains, using only private peering links would be too costly. A better solution to allow many domains to cheaply interconnect are the `Internet eXchange Points` (:term:`IXP`). An :term:`IXP` is usually some space in a data center that hosts routers belonging to different domains. A domain willing to exchange packets with other domains present at the :term:`IXP` installs one of its routers on the :term:`IXP` and connects it to other routers inside its own network. The IXP contains a Local Area Network to which all the participating routers are connected. When two domains that are present at the IXP wish [#fwish]_ to exchange packets, they simply use the Local Area Network. IXPs are very popular in Europe and many Internet Service Providers and Content providers are present in these IXPs. 1046/10000 · 1046
9 ../../protocols/bgp.rst:39
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Interconnection of two domains at an Internet eXchange Point 60/10000 · 60
10 ../../protocols/bgp.rst:41
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the early days of the Internet, domains would simply exchange all the routes they know to allow a host inside one domain to reach any host in the global Internet. However, in today's highly commercial Internet, this is no longer true as interdomain routing mainly needs to take into account the economical relationships between the domains. Furthermore, while intradomain routing usually prefers some routes over others based on their technical merits (e.g. prefer route with the minimum number of hops, prefer route with the minimum delay, prefer high bandwidth routes over low bandwidth ones, etc) interdomain routing mainly deals with economical issues. For interdomain routing, the cost of using a route is often more important than the quality of the route measured by its delay or bandwidth. 800/10000 · 800
11 ../../protocols/bgp.rst:43
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — There are different types of economical relationships that can exist between domains. Interdomain routing converts these relationships into peering relationships between domains that are connected via peering links. 215/10000 · 215
12 ../../protocols/bgp.rst:47
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first category of peering relationship is the `customer->provider` relationship. Such a relationship is used when a customer domain pays an Internet Service Provider to be able to exchange packets with the global Internet over an interdomain link. A similar relationship is used when a small Internet Service Provider pays a larger Internet Service Provider to exchange packets with the global Internet. 407/10000 · 407
13 ../../protocols/bgp.rst:53
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A simple Internet with peering relationships 44/10000 · 44
14 ../../protocols/bgp.rst:55
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To understand the `customer->provider` relationship, let us consider the simple internetwork shown in the figure above. In this internetwork, `AS7` is a stub domain that is connected to one provider : `AS4`. The contract between `AS4` and `AS7` allows a host inside `AS7` to exchange packets with any host in the internetwork. To enable this exchange of packets, `AS7` must know a route towards any domain and all the domains of the internetwork must know a route via `AS4` that allows them to reach hosts inside `AS7`. From a routing perspective, the commercial contract between `AS7` and `AS4` leads to the following routes being exchanged : 643/10000 · 643
15 ../../protocols/bgp.rst:57
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — over a `customer->provider` relationship, the `customer` domain advertises to its `provider` its own prefixes and all the routes that it has learned from its own customers. 173/10000 · 173
16 ../../protocols/bgp.rst:58
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — over a `provider->customer` relationship, the `provider` advertises all the routes that it knows to its `customer`. 115/10000 · 115
17 ../../protocols/bgp.rst:60
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second rule ensures that the customer domain receives a route towards all destinations that are reachable via its provider. The first rule allows the prefixes of the customer domain to be distributed throughout the Internet. 228/10000 · 228
18 ../../protocols/bgp.rst:62
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Coming back to the figure above, `AS4` advertises to its two providers `AS1` and `AS2` its own prefixes and the routes learned from its customer, `AS7`. On the other hand, `AS4` advertises to `AS7` all the routes that it knows. 227/10000 · 227
19 ../../protocols/bgp.rst:66
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second type of peering relationship is the `shared-cost` peering relationship. Such a relationship usually does not involve a payment from one domain to the other in contrast with the `customer->provider` relationship. A `shared-cost` peering relationship is usually established between domains having a similar size and geographic coverage. For example, consider the figure above. If `AS3` and `AS4` exchange many packets via `AS1`, they both need to pay `AS1`. A cheaper alternative for `AS3` and `AS4` would be to establish a `shared-cost` peering. Such a peering can be established at IXPs where both `AS3` and `AS4` are present or by using private peering links. This `shared-cost` peering should be used to exchange packets between hosts inside `AS3` and hosts inside `AS4`. However, `AS3` does not want to receive on the `AS3-AS4` `shared-cost` peering links packets whose destination belongs to `AS1` as `AS3` would have to pay to send these packets to `AS1`. 971/10000 · 971
20 ../../protocols/bgp.rst:68
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — From a routing perspective, over a `shared-cost` peering relationship a domain only advertises its internal routes/prefixes and the routes that it has learned from its customers. This restriction ensures that only packets destined to the local domain or one of its customers is received over the `shared-cost` peering relationship. This implies that the routes that have been learned from a provider or from another `shared-cost` peer is not advertised over a `shared-cost` peering relationship. This is motivated by economical reasons. If a domain were to advertise the routes that it learned from a provider over a `shared-cost` peering relationship that does not bring revenue, it would have allowed its `shared-cost` peer to use the link with its provider without any payment. If a domain were to advertise the routes it learned over a `shared cost` peering over another `shared-cost` peering relationship, it would have allowed these `shared-cost` peers to use its own network (which may span one or more continents) freely to exchange packets. 1049/10000 · 1049
21 ../../protocols/bgp.rst:72
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Finally, the last type of peering relationship is the `sibling`. Such a relationship is used when two domains exchange all their routes in both directions. In practice, such a relationship is only used between domains that belong to the same company. 250/10000 · 250
22 ../../protocols/bgp.rst:76
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — These different types of relationships are implemented in the `interdomain routing policies` defined by each domain. The `interdomain routing policy` of a domain is composed of three main parts : 195/10000 · 195
23 ../../protocols/bgp.rst:78
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `import filter` that specifies, for each peering relationship, the routes that can be accepted from the neighboring domain (the non-acceptable routes are ignored and the domain never uses them to forward packets) 216/10000 · 216