Multihoming | Remote Access

One important detail affecting the design of access servers (which, for example, may contain the LAC function) is that their routers are typically located at the borders of enterprise or ISP networks. The servers then act as gateways to their respective networks. Three applications —remote dial-in, VPN, and IP telephony—deal with the IP packets that can traverse more than one network. For this reason, the remote access products that support the VPN service and IP telephony gateways benefit from the implementation of Border Gateway Protocol (BGP) version 4 (RFC 1771).

Although the subject of routing algorithms is outside of the scope, a short discussion of BGP is warranted. You may notice that some issues (such as policing) inherent in BGP are very similar to—and, in some cases, even the same as—those pertinent to the QoS standards addressed. BGP is the means of realizing multihoming (that is, maintenance of connections to multiple ISPs or enterprise networks). Thus, BGP is of considerable importance to dial-in access and VPN applications. The IETF has paid much attention to the BGP development, which dates back to ARPANET and then was pursued in the Inter-Domain Routing (idr) working group (www.ietf.org/html.charters/idr-charter.html ) over several years. Four versions of BGP have been released. In the latest series of RFCs, RFCs 1771 and 1772 have achieved the status of Draft Standards. Informational RFCs 1773 and 1774, respectively, document experiences with BGP-4 and provide an analysis.

RFC 1771 defines an autonomous system (AS) as “a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASs.” ISPs and enterprise networks are two typical examples of ASs.

Whereas interior nodes are concerned with making the best effort at delivering IP packets, exterior nodes have to deal with many other tasks. One task is to decide whether certain packets should be admitted to the AS; the other is to maintain the appearance of a coherent interior routing plan (which is not necessarily the case in practice). As RFC 1771 says: “The use of the term Autonomous System here stresses the fact that, even when multiple IGPs and metrics are used, the administration of an AS appears to other ASs to have a single coherent interior routing plan and presents a consistent picture of what destinations are reachable through it.”

There are two aspects to packet admission: Some packets may actually be destined to terminate in the AS, whereas others should be allowed to traverse it in order to get to other ASs.

In the world of the exterior nodes, which is significantly cozier than the world of all routers—if only because it is much smaller—the ASs are somewhat selfishly viewed as the means of connecting the exterior nodes. As far as transit through ASs is concerned, BGP provides the following taxonomy (illustrated in Figure 1):

§  Stub AS. An AS that has only a single connection to one other AS. Naturally, a stub AS only carries local traffic.

§  Multihomed AS. An AS that has connections to more than one other AS, but refuses to carry transit traffic.

§  Transit AS. An AS that has connections to more than one other AS and is designed (under certain policy restrictions) to carry both transit and local traffic.

Figure 1: The AS classification.

Stub and multihomed ASs do not need to employ BGP at their border nodes, but transit ASs do. The responsibilities of the border gateways involve, among other things, policing the incoming traffic.

This situation is strikingly similar to what used to happen at the borders of the Iron Curtain countries in Europe before the fall of the Curtain. In particular, the German Democratic Republic—the former East Germany—which had a piece of the free world (West Berlin) within its territory, was well equipped for dealing with transit traffic at its borders, where the cars queued up amid many uniformed men and women with automatic rifles and barking dogs. Unless all present in a car were citizens of East Germany or had prearranged visas for visiting specific places in the country, they were issued—for a fee—time-stamped transit visas that indicated a particular border point at which the car had to exit the country. The choice of destination border point belonged to the driver, but could not be changed once it was written in the visa. Furthermore, the car was supposed to reach its destination border point by (1) always staying on the East German highway network, (2) following the shortest path through this network, and (3) obeying all the laws of the country, which in this case were of course effectively reduced to the traffic laws. With that, the car was virtually tunneled through the country, its passengers seeing not much more than other cars and trucks—including many police cars—and vast fields on both sides of the highway. At the destination border checkpoint, more armed men and women with dogs were waiting. One of the many checks they performed was that of the initial time stamp. If the elapsed time indicated that the car had clearly spent more time in the country than it would have had it taken the shortest path, some specific policies applied, with the actual consequences (fines? imprisonment?) fortunately unknown to these authors. Another—and, alas, often unexpected—effect of time-stamping was discovered by those drivers whose traveling time was too short for the distance, which was a clear proof of speeding. The offense was punished by a large on-the-spot fine to be paid in cash and in hard currency. The latter policy example, however, is more illustrative of QoS rather than border gateway policies.

Policy-based routing is an essential job of the routers that serve as border gateways. Policy specification is a job of network administrators rather than of the protocol itself, but BGP routers do make routing decisions based on these policies.

In a deviation from other Internet routing protocols, BGP uses TCP (instead of a link layer protocol) as a reliable data transport for routing messages. The actual routing algorithm belongs to the so-called distance vector routing family, which operates by maintaining within each router a table of distances (costs) to all reachable routers and exchanging this information with other routers. The most lamented deficiency of the distance vector routing is that the “bad news,” (that is, loss of a link between two routers or router flop) propagates through the network extremely slowly. BGP differs from other distance vector routing protocols in that the routers maintain—and share with one another—full paths to the nodes reachable from them. That fixes the problem of spreading the bad news, because the routers notice all the nodes disappearing from neighbors’ paths as soon as they get the change information. Note that being reachable is not simply a matter of connectivity but also of active policies.

In an example of RFC 1772, a multihomed AS may actually act as a transit AS for some ASs by advertising to them paths to foreign gateways; on the other hand, a transit AS may restrict access to some ASs by never advertising paths to them (that is, declaring them unreachable). In the example of Figure 2, AS D is reachable to AS A through AS C, but AS B is not.

Figure 2: Access restriction.

Initially, a BGP router sends its whole routing table to its neighbors, which are supposed to keep it until the connection is closed because from now on they will receive only incremental updates. Even though TCP is used for transport, BGP still uses its own KeepAlive messages to ensure that the connection is open. The connection is closed whenever an error condition (such as nonreception of KeepAlive messages) is encountered. In addition to incremental updates, BGP-4 has added the concept of route aggregation so that information about groups of networks may be represented as a single entity.

BGP-4 has also addressed the problems of (1) the exhaustion of class B address space and (2) threatening growth of the routing tables. In listing the differences between BGP-4 and previous versions of BGP, RFC 1771 notes: “BGP-4 is capable of operating in an environment where a set of reachable destinations may be expressed via a single IP prefix. The concept of network classes, or subnetting, is foreign to BGP-4. . . . New text has been added to define semantics associated with IP prefixes.”