This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Before it describes how a user discovers a failure-free route, it first defines a few terms. It refers to a provider that does not purchase transit service from other providers as a tier-1 provider. The project defines the region of the Internet where tier-1 providers interconnect as the Core of the Internet. It discusses a more general definition about the Core.
To formulate a valid route, a user needs to know which routes it can use and whether they are failure free. The project design provides a basic mechanism for users to discover routes and route failures, and allows users to use any general mechanism to enhance the basic mechanisms. To allow practical payment schemes, the project design exposes to a user the region of the network that consists of his providers, his providers' providers, and so on until the providers in the Core. In addition, the region also includes the peering connections of the providers outside the Core. This region of the network is the user's "access network" to the rest of the Internet. It refers to this region as a user's "up-graph." Fig. 1.3 shows a sample network, where the dark lines depict the user Bob's up-graph, In the abstract each domain as having one router and the multiple links between two domains as one domain-level link. Without specific mentioning, the term link in this paper refers to a domain-level link. More realistic situations are considered in.
To design a topology information propagation protocol (TIPP) to let a user discover his up-graph. TIPP has two components: a path-vector component to distribute the set of provider-level routes in a user's up-graph, and a policy-based link state component to inform a user of the dynamic network conditions. The path-vector component informs a user of his direct and indirect providers and the transit routes formed by those providers. A tier-1 provider advertises itself to its customers, and the customers append themselves and further advertise the routes to their customers. Different from a path-vector routing protocol such as BGP, the path-vector component of TIPP does not select paths. In the example of Fig. 1.3, a user Bob learns from TIPP that he can use two routes to reach the Core: N1 ƒ R1 ƒ B1 and N1 ƒ R2 ƒ B1. Each domain on the route is his direct or indirect provider. The link-state component of TIPP informs a user of the dynamics of the network. Unlike a global link-state routing protocol, TIPP's link-state messages can be configured to propagate within a provider hierarchy, instead of globally.
A domain can control the scope within which a link state message is propagated (scope enforcement) as well as to which neighbor to expose an adjacent domain-level link (information hiding). With this policy, a user Bob only learns the domain-level links on his up-graph, which includes N1 ƒ R1, N1 ƒ R2, R1 ƒ B1, R2 ƒ B1, and R2 ƒ R3. This flexibility allows the design to be efficient and to be readily used by resource-constrained devices such as PDAs or aged PCs. However, if in the future, efficiency (memory, bandwidth, and computation power) is not a concern even for small or low-end devices, the link-state component of TIPP can be configured to propagate link-state messages globally. A user with a more complete network topology can avoid more dynamic failures in the network.
In NIRA, a sender can obtain an end-to-end route to a destination by combining routes in his up-graph and those in the destination's up-graph in reverse order. A typical domain-level route is said to be "valley-free". That is, a route has an "uphill" segment consisting of a sequence of the sender's providers, and a "downhill" segment consisting of a sequence of the receiver's providers. A sender's up-graph contains the uphill segment of a route, and the destination's up-graph contains the downhill part. A sender learns an uphill segment from TIPP, and may obtain the destination half of a route from a lookup service, the name-to-route lookup service (NRLS).
Fig 1.3 Diagrams for Route Discovery .
Dark lines draw the user Bob's up-graph. In this and all other figures, an arrowed line represents a provider-customer connection, with the arrow ends at the provider. A dashed line represents a peering connection.
Efficient Route Representation
Once a sender formulates an end-to-end route, it needs to encode it in a packet header. The project expects that a source route will be encoded with a uniform global format. This is to ensure global communication. There are several candidates for route encoding. For instance, one encoding scheme is to use a sequence of addresses or domain identifiers such as AS numbers. The advantage of this scheme is its flexibility. It can express any route. The drawback is the variable-length header overhead.
In NIRA, it uses a provider-rooted hierarchical address to encode a route segment that connects a user to a Core provider. This scheme has a number of advantages. First, it is efficient in the common case. With this scheme, a user can use a source and a destination address to compactly represent a valley-free route, and switch routes by switching addresses. Meanwhile, with this representation scheme, both the source address and the destination address are used for forwarding. This effectively limits source address spoofing, because a router may not find a forwarding entry for a packet with an arbitrary source address, and will instead drop the packet.
In the provider-rooted hierarchical addressing scheme, a provider in the Core obtains a globally unique address prefix. The provider then allocates non overlapping subdivisions of the address prefix to each of its customers. Each customer will recursively allocate non overlapping subdivisions of the address prefix to any customer it might have.
The hierarchical addressing scheme requires that an address be long enough to encode the provider hierarchy. This requirement could be met either with a fixed-length address with a large address space, or with a variable length address. For the sake of concreteness, it uses IPv6 address, which is 128-bit long. Using IPv6 addresses has the benefit that NIRA's packet header could be the same as the IPv6 header. It uses the first 96-bit of an address as an inter-domain address prefix that is hierarchically allocated from a provider to a customer; the remaining 32-bit is an intra- domain address that identifies a network location inside a domain. If allocated prudently, 96 bits could address up to domains. In any foreseeable future, the number of domains in the Internet is unlikely to be anywhere close to that number. So that an IPv6 address is a reasonable choice. This design choice also allows NIRA to reuse the deployment effort of IPv6.
The project notes that the choice of route encoding is independent of other design modules of NIRA. Alternatively, it can use a sequence of IPv4 addresses to represent a domain-level route. This will make NIRA compatible with the current IPv4 architecture. It chooses to use IPv6 addresses because the project considers it advantageous to use a source and a destination address to represent a common type of route. Even if IPv6 does not completely replace IPv4 in the future, NIRA can be adapted to use a sequence of IPv4 addresses to represent the routes in the part of the network that uses IPv4 addresses. Users can still learn those routes from TIPP.
Fig. 1.4 shows an example of NIRA's address scheme. In this and all other examples, it represent an address and an address prefix using the IPv6 notation as described in, where "::" represents a variable number of continuous zeros, and ":" is a separator that separates every 16-bit piece. An address prefix is represented in the format address/prefix length. In this example, the tier-1 providers B1 obtains a globally unique address prefix 1::/16. Non-overlapping subdivisions of the prefix are allocated downwards the provider-tree rooted at B1. B1's customer R1, R2, and R3 each gets a subdivision of 1::/16: 1:1::/32, 1:2::/32, 1:3::/32, and recursively allocate the subdivisions of the prefixes to their customers: N1, N2, and N3. A user in N1, Bob, gets two hierarchical addresses allocated from the tier-1 providers: 1:1:1::1000 and 1:2:1::1000.
Fig 1.4 Example of the strict provider-rooted hierarchical addressing.
The project further extends the provider-rooted hierarchical address allocation mechanism and assigns a noncore-visible address space to a domain-level peering link outside the Core. Each peer obtains an address prefix from the noncore-visible address space. A provider that has a peering address prefix will also recursively allocate the subdivisions of the address prefix to its customers. The peering address is noncore-visible in the sense that they are not propagated into the Core.
For instance, in Fig. 1.4, a noncore-visible peering prefixes FFFF::/16 is allocated to the peering link between R2 and R3. R2 gets the address prefix FFFF:1::/32, and R3 gets the address prefix FFFF:2::/32. Recursively, R2 and R3 allocate subdivisions of the address prefixes to their customers N1, N2 and N3. Domain N1 gets a prefix FFFF:1:1::/48, and the user Bob in domain N1 gets a noncore-visible peering address FFFF:1:1::1000.
With this addressing scheme, a user can use a source and a destination address to represent a valley-free route. The sequence of the providers that allocate the source address maps to the uphill route segment; similarly, the sequence of the providers that allocate the destination address maps to the downhill segment. A user Bob may use the source address 1:1:1::1000 and the destination address 1:3:1::2000 to represent the route N1 ƒ R1 ƒ B1 ƒ R3 ƒ N3.
With the hierarchical address allocation scheme, one can infer the provider-customer relationship from the address prefixes a domain has. The project does not think it will become a deployment obstacle because this relationship can be largely inferred today.
Bootstrap a Communication
To bootstrap a communication, a user also needs to know what routes a destination is allowed to use. Similar to bootstrapping a communication in today's Internet, in which a user obtains the IP address of a destination, a user can obtain this information via multiple approaches, e.g., a directory lookup, a web search, or out of band communication. In our design, it proposes an infrastructure service, the NRLS to map the name of a destination to the route segments the destination is allowed to use. NRLS is a separate design module. The project design does not constrain the form of the name space or the implementation of the NRLS service. The namespace can be hierarchical like the domain name service (DNS), or flat as proposed in, or take any other form that is used in the future Internet. Similarly, the implementation can either be hierarchical, or flat, or a mixture.
If an end system wants to be reached by other hosts, it stores its route segments together with its preference at an NRLS server. With the encoding scheme described in Section 1.5.3, the routes a destination can use are encoded as addresses. When a user intends to communicate with a destination, the user queries the NRLS to retrieve the route information of the destination, similar to querying a DNS server in today's Internet. Combining his route information with that of the destination, a user is able to choose a source and a destination address to reach the destination. Two users may exchange subsequent packets to negotiate a better route.
If the domain-level topology changes, a user's provider-level routes may change. TIPP will notify a user of these changes. When a server's provider-level routes or its route preference changes, it needs to update its NRLS record. This process is similar to dynamic DNS updates or other directory service updates. NRLS can use any mechanism that secures DNS updates (or other directory service updates) to provide security to NRLS updates. We do not think NRLS updates would cause any scaling problem for two reasons. First, the Internet topology (at the domain level) changes at a low frequency. Only those changes would affect a user's route segments. Second, static topology changes (excluding temporary failures) are caused by the changes in business relationships. These changes happen in a controlled manner. Network administrators and users can deploy creative scheduling algorithms to reduce the service disruption and the NRLS server update overhead. A grace period may be granted before a provider terminates its service so that a user has sufficient time to update his route information. Randomized algorithms may be used to prevent users from simultaneously updating their route information, and standard load-balancing techniques can be used to shed load from one NRLS server to multiple machines.
Like DNS or any other directory service, an NRLS resolver needs to be hard-coded with the route segments of the root NRLS servers. When the route segments of the root servers change, the hard-coded information need to be updated. The process of updating root server information can be inconvenient. One approach to alleviate this problem is to place the root NRLS servers at the tier-1 providers. A server inside a tier-1 provider only has one route segment that consists of the tier-1 provider. The likelihood that the route would change is significantly reduced.
Handling Route Failures
The route a user chooses to use may suffer dynamic failures. The basic mechanism we provide for route failure discovery is a combination of proactive and reactive notification. TIPP proactively notifies a user of the working conditions of routes in the user's up-graph. As TIPP messages may not propagate globally, a user in general does not know the working conditions of routes on a destination's up-graph. A user relies on reactive mechanisms, such as a timeout or a router feedback, to discover route failures.
The project design requires that if a router detects that a route specified in a packet header is unavailable, the router try its best to send a rate-limited ICMP message to inform the original sender. Such an ICMP message may include reasons why the route is unusable. In cases where a router is unable to send a failure notification, e.g., a router is overloaded, users should use timeout to detect route failures. When a user receives a reactive notification, as he knows his addresses, his up-graph, and the addresses of the destination, he could switch to an alternative route. The fail-over time is on the order of a round trip time in the case of a router feedback, and depends on the timeout parameters in the case of a timeout.
The combination of proactive and reactive notification reduces the amount of dynamic routing information a user needs to maintain. However, reactive notification may increase the connection setup time when user selected routes suffer from failures. Users should cache recently used routes and avoid using unavailable routes for a new connection. The project expects that the amortized connection set up time will be reduced with such caching. Later provides an analytic model to estimate the average connection set up time in the presence of failures.
In the project design, failures that trigger reactive notifications are those that result in inter-domain disconnections. Intra-domain failures should always be recovered using local repair mechanisms for rapid fail-over. For inter-domain failures, it is best for the user to decide on an alternative route, because a user has expressed his domain-level route choice in a packet header, and a router does not know the user's route preference. The dynamics of route selection may not be high since the domain-level routes may not be so fragile to single link failures.
In addition to the combination of TIPP messages, router notifications, and timeouts, users may use any general mechanism to discover route failures. For instance, a local provider may offer a route monitoring service to its users. The provider may run a server that actively probes the dynamic attributes of popular routes and provides timely information on route conditions to its customers. In addition, popular servers may choose to include dynamic topology information in their NRLS records and update the information at a rate they could afford. When a user retrieves a server's route information, he may already know which addresses of the server are unreachable, thereby saving the connection setup time.
How Users May Choose Routes
After a user is equipped with the ability to discover routes and to handle route failures, he is able to choose routes. We present a concrete example to illustrate how a user may choose routes. Suppose a user Bob in Fig. 1.4 wants to communicate with Alice. The following steps may happen.
1. Bob learns his addresses: 1:1:1::1000, 1:2:1::1000, FFFF:1:1::1000, his up-graph, and the dynamic failure information on his up-graph from TIPP. Note that the up-graph tells Bob the provider-level routes his addresses map.
2. Bob queries NRLS servers to obtain Alice's addresses: 2:1:1::2000, 1:3:1::2000, and FFFF:2:1::2000, and Alice's preference over these addresses.
3. Combining his addresses and Alice's addresses, Bob knows that he has five routes to reach Alice. Four of them come from the combination of his global addresses and Alice's global addresses. One of them comes from the combination of the noncore-visible peering addresses.
4. Suppose Alice prefers the peering address FFFF:2:1::2000 to other global addresses. From his up-graph, Bob knows that he has an address FFFF:1:1::1000 allocated from the same peering link, and the route segment in his up-graph N1 ƒ R2 ƒ R3 is in good condition. Bob then sends a packet to Alice using a source address FFFF:1:1::1000 and a destination address FFFF:2:1::2000.
5. After the packet reaches Alice, Bob, and Alice may exchange subsequent packets to negotiate a better route. If Bob detects a failure from a router feedback or a timeout, he can switch to an alternative route by switching addresses.
The default usage model of NIRA is that a software agent running on a user's computer selects routes based on the user's preference. The agent can either learn a user's preference from static configured policies, or from an adaptive learning approach by observing a user's behavior, as described in . For instance, if an ISP offers a voice over IP expedited forwarding service, a user may configure the agent to choose the ISP when he runs voice over IP applications.
In addition, NIRA supports multiple usage models. Choice is not restricted to be made only by end users. In situations where a domain does not want to give route choice to its users, for instance, a company network might not want its employees to select routes according to their preferences, the domain does not need to propagate TIPP messages to those users. Instead, the domain could have a route server to select routes for its users. If a domain uses a NAT box to isolate hosts in the domain from the rest of the Internet, the NAT box will select routes on behalf of the hosts in the domain. Alternatively, a domain could have its border routers act as name-to-route translation boxes, as described in the IPNL architecture. A user sends all his packets with the destination's domain name. A border router selects routes on behalf of users. When a border router receives the first packet to a destination from a user, the router does an NRLS query, caches the results, selects a route for the user, attaches the route representation to the packet, and sends the packet. For subsequent packets, the router can translate the destination name into a previously selected route representation using cached results.
In NIRA, a packet is first forwarded along the sequence of domains that allocate the source address, and then forwarded along the sequence of domains that allocate the destination address. The path the packet takes from the top-level provider that allocates the source address to the one that allocates the destination address is chosen by the top-level providers inside the Core.
For instance, in Fig. 1.4, if a user Bob chooses a source address 1:1:1::1000 (allocated from B1 ƒ R1 ƒ N1) and a destination address 2:1:1::2000 (allocated from B2 ƒ R3 ƒ N3) to send a packet, the packet will be forwarded along the route N1 ƒ R1 ƒ B1 - B2 ƒ R3 ƒ N3, where the symbol denotes that the top-level providers in the Core decide how to forward the packet from B1 to B2.
Routers must have correct forwarding state in order to forward packets along the specified routes. In NIRA, domains run TIPP to establish the forwarding state within a provider hierarchy, and top-level providers may run an inter-domain routing protocol such as BGP to determine the forwarding state inside the Core. For instance, TIPP informs a router in N1 that the address prefix 1:1:1::/48 is allocated from R1. Thus, packets with a source address 1:1:1::1000 will be forwarded to R1.
The project made the design choice that the path a packet takes within the Core is chosen by providers in the Core for two practical reasons. First, this will facilitate the deployment of NIRA, because in the present Internet, routes are chosen by ISPs running BGP, instead of by users. The project expects that the migration from the present routing architecture to NIRA gradually happens from the edge towards the center. Local providers and regional providers can incrementally deploy NIRA to let users choose the backbone providers. Second, letting a user choose routes in the Core may not bring much flexibility in choice, but will expose to the user the dense topology of the Core. For instance, tier-1 ISPs of the Internet form a clique, with any tier-1 provider having a peering agreement with all other tier-1 providers, but only the direct peering connection is the policy-allowed route between any two tier-1 providers. Thus, the project made the design choice not to let users choose routes inside the Core.
The project notes that the strict provider-rooted hierarchical address allocation scheme makes the Core a scalable routing region. With this addressing scheme, inside the Core, a provider in the Core only needs to announce one aggregated address prefix to other providers in the Core. The number of routing table entries in the Core scales with the number of providers in the Core. Because the ISP market is a high-barrier market, financial factors will limit the market entries. Therefore, routing in the Core is unlikely to run into the scaling problems faced by today's Internet.
Definition of the Core
The concept of the Core in NIRA is more general than in today's Internet. At the minimum, the Core in NIRA will include the tier-1 providers that do not purchase transit service from other providers. A nontier-1 ISP can decide whether to join the Core or not. To join the Core, it needs to obtain a globally unique address prefix, connect to those providers with globally unique address prefixes, and convince those providers to announce its own prefix into the Core. To not join the Core, the ISP accepts address allocations from the providers it connects to.
The project expects that the Core will be a dynamic structure that is shaped by the market force as NIRA deploys. If users welcome route choice, then a nontier-1 provider has the incentive to stay outside the Core and to let users choose among the providers it connects to. Otherwise, the provider may choose to stay inside the Core. For instance, in Fig. 1.4, if users welcome choice, then the provider R3 may decide to stay outside the Core, letting users choose between B1 and B2. ISPs could make their decisions based on the cost to obtain a globally unique address prefix, the cost to get that prefix announced to other providers in the Core, and the benefits and drawbacks of doing so. It is worth noting that even in the worse case, where every provider has decided to join the Core, with NIRA, a multi homed edge domain will not poke a hole in the global routing tables. Thus, the growth of the global routing state is still limited by the growth of the Core, instead of the growth of the Internet. The project thinks this rate of growth will scale well.
1.2. EXISING SYSTEM:
The default routing path chosen by BGP may not be the best in terms of performance, reliability, or cost. End hosts on an overlay network often find alternative Internet paths with lower latencies, lower losses, or higher reliability than the default routes chosen by BGP. For instance, Detour found that for almost 80% of the default paths, an alternative route offers a lower loss rate. Similarly, recent studies also show that multi homed sites can improve path quality and reduce monetary cost by intelligently choosing their upstream providers.