Method of determining transit costs across autonomous systems

FIELD OF THE INVENTION

0001The present invention generally relates to managing virtual private network (VPN) hosts that use Border Gateway Protocol (BGP). The invention relates more specifically to methods of determining transit costs for network links.

BACKGROUND

0002The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.

0003Enterprises that host or manage large networks, such as Internet service providers (ISPs), commonly deploy virtual private networks (VPNs) so that ISP customers can securely communicate private data across non-secure semi-public Internet nodes. An ISP network comprising provider edge (PE) routers, core network routers, and other elements may be termed an autonomous system (AS). Such systems commonly use Border Gateway Protocol (BGP), as defined in Request for Comments (RFC) 1771 of the Internet Engineering Task Force (IETF), for exchanging route information (“prefixes”) and reachability information with other systems.

0004Current practices provide no effective way for managers of BGP VPNs to determine or account for transit costs of traffic passing through a service provider. In addition, the transit cost between multiple autonomous systems also is not considered. Thus, current practices provide no effective way for any customer edge (CE) router to find the shortest path for a prefix with multiple paths traversing several autonomous systems within the same administrative domain.

0005For the purpose of illustrating one relevant problem, <figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of an example network configuration. A customer network <b>102</b> has a CE router <b>104</b> that is coupled by link <b>105</b> to a PE router <b>106</b> associated with an ISP core network <b>109</b>. PE router <b>106</b> is coupled by link <b>114</b> through ISP core network <b>109</b> to a second PE router <b>108</b>, which is linked to CE router <b>110</b> by link <b>116</b>. The second CE router <b>110</b> is associated with a separate customer network <b>112</b> of a different customer of the ISP. PE routers <b>106</b>, <b>108</b> and core network <b>109</b> are associated with one ISP <b>120</b>. Thus, in <figref idref="DRAWINGS">FIG. 1</figref> the first and second CE routers <b>104</b>, <b>110</b> are connected indirectly via a common ISP <b>120</b>. CE router <b>104</b> and PE router <b>106</b> could run either BGP (and either exterior BGP [EBGP] or interior BGP [IBGP]) or an interior gateway protocol (IGP) over link <b>105</b>. Similarly, PE routers <b>106</b>, <b>108</b> on link <b>114</b>, and PE router <b>108</b> and CE router <b>110</b> on link <b>116</b> could run any of IBGP and IGP.

0006In this scenario, for a route that is originated by CE router <b>104</b>, and reaches CE router <b>110</b> via PE routers <b>108</b>, <b>106</b>, CE router <b>110</b> currently has no way to calculate the total cost for it to reach CE router <b>104</b>. Generally, there is currently no way to calculate a total cost value that reflects cost values that are developed independently by different routing protocols, and there is no way to do so between EBGP and IGP in particular.

0007Having a way to compute total link cost or transit cost between different routing protocols would be particularly useful when there are different routing paths available via different routing protocols, or the same routing protocols, running under the same administrative domain. For example, a customer of multiple service providers may wish to select the shortest path for a given route automatically. Currently, no automatic selection mechanism exists, and path selection, in this case, is performed by manual configuration.

0008No other solutions that attempt to resolve this problem are known. One cost communication mechanism, which does not solve the problem identified herein, is described in Retana et al., in the document named “draft-retana-bgp-custom-decision-00.txt,” available at the IETF web site and Internet-draft archive sources. Retana et al. propose a mechanism for extending community attributes to carry a cost of a route within one BGP domain or autonomous system. When route information is communicated outside an AS, the cost value is lost. Thus, the mechanism of Retana et al. cannot be used to transport a cost of a route across the boundaries of autonomous systems.

BRIEF DESCRIPTION OF THE DRAWINGS

0009The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

0010<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram that illustrates an example network configuration of the prior art;

0011<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram that illustrates an example network configuration that may be used to implement an embodiment;

0012<figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram showing a high-level view of a process for determining a transit cost;

0013<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram showing an alternative process for determining a transit cost;

0014<figref idref="DRAWINGS">FIG. 5A</figref>, <figref idref="DRAWINGS">FIG. 5B</figref> are flow diagrams showing steps for determining and communicating cost metric values for EBGP and IGP deployments;

0015<figref idref="DRAWINGS">FIG. 6</figref> is a flow diagram showing steps for determining a best path using a transit cost value;

0016<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram that illustrates a computer system upon which an embodiment may be implemented.

DETAILED DESCRIPTION

0017A method and apparatus for determining transit costs across one or more autonomous systems is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

0018Embodiments are described herein according to the following outline: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0019"> 1.0 General Overview </li><li id="ul0002-0002" num="0020"> 2.0 Structural and Functional Overview </li><li id="ul0002-0003" num="0021"> 3.0 Determining Transit Costs Across Autonomous Systems That Use Various <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0022"> Protocols </li><li id="ul0003-0002" num="0023"> 3.1 Receive Routes From Originating CE Router </li><li id="ul0003-0003" num="0024"> 3.2 Announce Routes Within An Autonomous System Using BGP </li><li id="ul0003-0004" num="0025"> 3.3 Announce Routes Outside An Autonomous System Using BGP </li><li id="ul0003-0005" num="0026"> 3.4 CE Router Receiving Routes </li><li id="ul0003-0006" num="0027"> 3.5 Benefits And Conclusions </li></ul></li><li id="ul0002-0004" num="0028"> 4.0 Implementation Mechanisms-Hardware Overview </li><li id="ul0002-0005" num="0029"> 5.0 Extensions and Alternatives <br /> 1.0 General Overview </li></ul></li></ul>

0030The needs identified in the foregoing Background, and other needs and objects that will become apparent for the following description, are achieved in the present invention, which comprises, in one aspect, a method for determining a cumulative network layer reachability cost of traversing one or more autonomous network routing systems, the method comprising the computer-implemented steps of receiving first network route information from an originating customer edge router, wherein the first network route information identifies a route in a customer network; determining a transit cost from the provider edge router to an endpoint associated with the originating customer edge router based upon a metric value received in a cost community attribute; repeating the determining step for each of one or more autonomous systems that lie in a path from the originating customer edge router to a destination customer edge router, to result in determining an accumulated transit costs across one or more autonomous systems; and determining, based at least in part upon the accumulated transit cost, a best path from the provider edge router to the endpoint associated with the originating customer edge router. The one or more autonomous systems may be owned or operated by one or more Internet Service Providers.

0031In another aspect, the invention provides a method comprising the computer-implemented steps of receiving first network route information from an originating customer edge router, wherein the first network route information identifies a route in a customer network; determining a cost metric value for the route and storing the cost metric value in a Border Gateway Protocol (BGP) cost community attribute of a route update message; sending the route announcement message to an egress provider edge router, wherein the route announcement message includes the route identified in the first network route information and the cost community attribute; determining a transit cost from the egress provider edge router to an endpoint associated with the originating customer edge router based upon the metric value in the cost community attribute; determining, based at least in part upon the transit cost, a best path from the egress provider edge router to the endpoint associated with the originating customer edge router.

0032In one feature of this aspect, communications with the originating customer edge router use an interior gateway protocol (IGP), and a normalized IGP cost of the route is determined, as part of determining the cost metric value.

0033In another feature, communications with the originating customer edge router use BGP, the communications traverse a service provider network, and the service provider network uses a Route Reflector to reflect routes across an autonomous system in the service provider network. In one alternative, the Route Reflector performs reflecting the best path without modifying the cost community attribute.

0034In another feature, communications to the provider edge router use external border gateway protocol (EBGP), the provider edge router is outside an autonomous system, and the method further involves removing the cost community attribute; determining an IGP cost of a nexthop associated with the route based at least in part on the cost metric value; normalizing the IGP cost; determining a sum of a normalized IGP cost and the cost metric value; and sending the sum in a multi-exit discriminator (MED) attribute of an EGBP message to EGBP neighbor nodes of the provider edge router.

0035In yet another feature, the method includes removing the cost community attribute; determining an IGP cost of a nexthop associated with the route based at least in part on the cost metric value; normalizing the IGP cost; determining a sum of a normalized IGP cost and the cost metric value; converting the sum to an IGP metric value; and sending the route announcement message to a second customer edge router using IGP, wherein the route announcement message includes the IGP metric value.

0036In still another feature, the provider edge router communicates with a second customer edge router using a BGP, and the second customer edge router is multihomed, and the method further involves sending a second route announcement message, which includes the transit cost value, to a second customer edge router; at the second customer edge router, determining a bestpath to the originating customer edge router based on always comparing BGP MED values for a first autonomous system that includes the provider edge router and a second autonomous system that includes the customer edge router, and storing the bestpath in a router information base (RIB) of the customer edge router.

0037In a further feature, the provider edge router communicates with a second customer edge router using a BGP, the second customer edge router is not multihomed, and the method further involves sending a second route announcement message, which includes the transit cost value, to a second customer edge router; at the second customer edge router, determining a bestpath to the originating customer edge router based on comparing BGP MED values for a first autonomous system that includes the provider edge router and a second autonomous system that includes the customer edge router, and storing the bestpath in a router information base (RIB) of the customer edge router.

0038In another feature the provider edge router communicates with a second customer edge router using an IGP, the second customer edge router is multihomed, and the method further comprises sending a second route announcement message, which includes the transit cost value, to a second customer edge router; at the second customer edge router, determining a bestpath to the originating customer edge router based on IGP cost metric values, and storing the bestpath in a router information base (RIB) of the customer edge router. The steps may be performed by one or more provider edge routers that are within one or more autonomous systems that are owned or operated by one or more Internet Service Providers.

0039In other aspects, the invention encompasses a computer apparatus and a computer-readable medium configured to carry out the foregoing steps.

00002.0 Structural and Functional Overview

0040<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram that illustrates an example network configuration that may be used to implement an embodiment. <figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram showing a high-level view of a process for determining a transit cost.

0041Referring first to <figref idref="DRAWINGS">FIG. 2</figref>, as in <figref idref="DRAWINGS">FIG. 1</figref>, a customer network <b>102</b> has a CE router <b>104</b> that is coupled by link <b>105</b> to a PE router <b>106</b> associated with an ISP core network <b>109</b>. PE router <b>106</b> is coupled by link <b>114</b> through ISP core network <b>109</b> to a second PE router <b>108</b>, which is linked to CE router <b>110</b> by link <b>116</b>. The second CE router <b>110</b> is associated with a separate customer network <b>112</b> of a different customer of the ISP. PE routers <b>106</b>, <b>108</b> and core network <b>109</b> are associated with one ISP <b>120</b>. The first and second CE routers <b>104</b>, <b>110</b> are connected indirectly via a common ISP <b>120</b>. CE router <b>104</b> and PE router <b>106</b> may run BGP (EBGP or IBGP) or an IGP protocol over link <b>105</b>. Similarly, PE routers <b>106</b>, <b>108</b> on link <b>114</b>, and PE router <b>108</b> and CE router <b>110</b> on link <b>116</b> could run any of IBGP and IGP protocol.

0042CE router <b>110</b> hosts a BGP process <b>206</b> that includes or is associated with transit cost logic <b>202</b>, and can form one or more cost community attributes <b>204</b> for use in BGP messages to other nodes. The transit cost logic <b>202</b> comprises one more computer program instructions or other software elements that implement the functions described herein. The particular functions that are implemented as part of transit cost logic <b>202</b> may vary according to which protocols are used on links <b>105</b>, <b>114</b>, <b>116</b>. Transit cost logic <b>202</b> may implement all such functions and may provide an administrative interface for configuring or selecting particular protocols or functions. Transit cost logic <b>202</b> may form an integral part of a BGP process or agent, or may be integrated into an operating system that controls and supervises operations of a router, or may comprise an independent software element.

0043<figref idref="DRAWINGS">FIG. 3</figref> is now described with reference to <figref idref="DRAWINGS">FIG. 2</figref> as an example context. However, the approach of <figref idref="DRAWINGS">FIG. 3</figref> is broadly applicable to other network contexts. At step <b>302</b>, network route information is received from an originating CE router. For example, PE router <b>108</b> receives a route in a BGP UPDATE message from CE router <b>110</b>.

0044At step <b>304</b>, a transit cost from a PE router to an endpoint associated with the originating CE router is determined, based on a metric that is received in a cost community attribute. For example, the BGP UPDATE message received from CE router <b>110</b> includes a cost metric value in a BGP cost community attribute, as that attribute is defined by Retana et al. PE router <b>108</b> combines the cost metric in the cost community attribute with a known link cost associated with link <b>116</b> to arrive at a transit cost.

0045At step <b>306</b>, the process of step <b>304</b> is repeated for all links and nodes of all autonomous systems that are in a path from the originating CE router to a destination CE router, resulting in creating an accumulated transit cost. Particular techniques for accumulating a transit cost in the context of various protocols are described further below. In the context of <figref idref="DRAWINGS">FIG. 2</figref>, the pertinent path is from CE router <b>110</b> to CE router <b>104</b>.

0046At step <b>308</b>, a best path from a PE router to an endpoint is determined, based in part on the accumulated transit cost. Thus, PE router <b>108</b> can compute a value for a bestpath attribute of a BGP route table, for a path from the PE router to an endpoint in customer network <b>102</b>, based in part on the accumulated transit cost. In doing so, the PE router <b>108</b> can take into account multiple accumulated transit cost values that have been determined.

0047Generally, embodiments of the invention provide a mechanism within BGP to account for IGP metrics of links traversed within each AS, and to pass cost values represented by the metrics along with the path information. The approaches herein also provide for conversion or normalization of different metrics as used by different platforms and protocols. This allows remote CE routers, receiving multiple paths to prefixes originating from a CE router in a different AS but in the same administrative domain, to choose shortest paths to such prefixes. The following sections describe in depth processing as performed at an originating CE router and its ISP, processing among PE routers that use IBGP within an ISP, and processing for interactions of a PE router and a CE router (that is, from the ISP to a destination CE).

00003.0 Determining Transit Costs Across Autonomous Systems That Use Various Protocols

0048<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram showing an alternative process for determining a transit cost; <figref idref="DRAWINGS">FIG. 5A</figref>, <figref idref="DRAWINGS">FIG. 5B</figref> are flow diagrams showing steps for determining and communicating cost metric values for EBGP and IGP deployments; and <figref idref="DRAWINGS">FIG. 6</figref> is a flow diagram showing steps for determining a best path using a transit cost value. <figref idref="DRAWINGS">FIG. 4-6</figref> are now described with reference to particular techniques for accumulating a transit cost value across one or more autonomous systems, depending on which of several protocols are in use.

00493.1 Receive Routes From Originating CE Router

0050Referring now to <figref idref="DRAWINGS">FIG. 4</figref>, in step <b>402</b>, network route information is received from an originating CE router, and in step <b>404</b>, a cost metric for the route is received and the cost metric is stored in the BGP cost community attribute. Thus, whenever a BGP PE router (for example, PE routers <b>106</b>, <b>108</b> of <figref idref="DRAWINGS">FIG. 2</figref>) receives a route from a connecting BGP CE router (such as CE routers <b>104</b>, <b>110</b>), the PE router stores the received metric value using the BGP Cost Community attribute. The BGP Cost Community attribute can be created at the PE router and attached to a BGP update.

0051If the PE router and the CE router run an IGP, then the normalized IGP cost of the route is stored in the BGP Cost Community attribute when the PE router redistributes the route within an IBGP network. IGP costs are normalized using the following equation: <br />Cost=Integer(<i>A*A′*X</i>)+<i>B</i>&lt;=255 <br /> where A is chosen to fit a particular IGP based on the relation A=(255/IGP maximum metric); A′ and B Are chosen by the user to fit a particular application; and X is the IGP metric.

0052The purpose of normalization is to transform IGP cost values into an equivalent value within the range of values allowed for the BGP Cost Community attribute as defined by Retana et al. Thus, normalization as described herein enables an implementation to account for differences in how various protocols, and policies of service providers, format or express metrics or cost values. For example, one ISP may internally track cost values per link mile and another may define a cost metric as a cost per link kilometer. Normalization resolves these differences.

00533.2 Announce Routes Within an Autonomous System Using BGP

0054At step <b>406</b>, a route announcement message is sent to an egress PE router with the route and the cost community attribute. For example, whenever a PE router announces routes to its IBGP peers or to a Route Reflector node, the PE router passes the Cost Community attribute with the metric value stored in the attribute.

0055At step <b>408</b>, a transit cost from the egress PE router to an endpoint associated with the originating CE router is determined, based on the metric value in the Cost Community attribute. At step <b>410</b>, a best path from the PE router to the endpoint is determined based in part on the accumulated transit cost. Thus, both IBGP neighbor nodes and BGP Route Reflector nodes use the Cost Community metric for best path selection, according to the Cost Community rules of Retana et al.

0056Further, a BGP Route Reflector reflects the best path selected to its IBGP or BGP route reflection client nodes and to any EBGP neighbors. A BGP Route Reflector does not modify the Cost Community attribute during announcement of the best paths. A BGP Route Reflector also leaves the nexthop value unchanged whenever the Route Reflector reflects, thereby allowing peers to forward data directly to the BGP router that announced the route to the Route Reflector. With this approach, receiving IBGP routers can directly and dynamically calculate a complete transit cost to the ingress IBGP router that had announced the route to the BGP Route Reflector.

0057If the Route Reflector has the “nexthop-self” mechanism configured, the Route Reflector performs the following steps. First, the Route Reflector computes the IGP cost to the nexthop of the route, which will be the address of a PE router that is injecting the route in the AS, by performing a reverse path forwarding (RPF) route lookup and using the metric in the IGP route that is found. Second, the Route Reflector normalizes the computed IGP cost and adds the normalized cost to the metric value that was received in the Cost Community metric. The summation step yields the total metric for a route to its destination. IGP costs are normalized using the equation described above.

0058Third, the Route Reflector sends the newly computed metric as the cost value in BGP Cost Community attribute to all its IBGP neighbor nodes, and to the BGP Route Reflector client nodes. If the receiving routers are IBGP neighbor nodes, such routers will be calculating IGP cost and follow the rule sets specified in next section 3.3.

00593.3 Announce Routes Outside an Autonomous System Using BGP

0060Referring now to <figref idref="DRAWINGS">FIG. 5A</figref>, whenever BGP routes with the Cost Community attribute are sent out of an AS using EBGP PE routers that implement the present approach, the following steps are performed. At step <b>502</b>, the Cost Community attribute is removed from an UPDATE message and the metric value contained therein may be stored. At step <b>504</b>, the IGP cost to the next hop of the route, which is the address of a PE router that is injecting the route in the AS, is determined. In one embodiment, the IGP cost is determined by performing an RPF lookup and using the metric in the IGP route that is found.

0061At step <b>506</b>, the computed IGP cost is normalized, and added to the metric value received in the Cost Community metric at step <b>508</b>. The sum or result is the total metric for a route to its destination. The IGP cost may be normalized using the equation described above.

0062At step <b>510</b>, the newly computed metric is sent as a MED value for the routes to the EBGP neighbors. In a BGP implementation, the multi-exit discriminator (MED) or metric attribute generally is used as a suggestion to an external AS regarding the preferred route into the AS that is advertising the metric.

0063Referring now to <figref idref="DRAWINGS">FIG. 5B</figref>, whenever PE routers send routes with the Cost Community attribute to CE routers using an IGP, then the following steps are performed. At step <b>502</b>, the Cost Community attribute is removed from an UPDATE message and the metric value contained therein may be stored. At step <b>504</b>, the IGP cost to the next hop of the route, which is the address of a PE router that is injecting the route in the AS, is determined. In one embodiment, the IGP cost is determined by performing an RPF lookup and using the metric in the IGP route that is found.

0064At step <b>506</b>, the computed IGP cost is normalized, and added to the metric value received in the Cost Community metric at step <b>508</b>. The sum or result is the total metric for a route to its destination. The IGP cost may be normalized using the equation described above.

0065At step <b>512</b>, the resulting BGP Cost Community attribute metric value is converted to an IGP metric using the following relation: <br />IGP Metric=Integer(<i>A*A′*X</i>)+<i>B </i><br /> where A is chosen to fit a particular IGP based on the relation A=(255/IGP maximum metric), A′ and B are chosen by the user to fit a particular application, and X is the BGP Cost Community attribute metric value.

0066At step <b>514</b>, the newly computed metric is sent as an IGP cost value for routes to IGP neighbor nodes.

00673.4 CE Router Receiving Routes

0068<figref idref="DRAWINGS">FIG. 6</figref> illustrates steps involved when a CE router running an IGP or a BGP with the PE router receives a route from the PE router. For purposes of illustration, assume that after the preceding processes, at step <b>602</b> a second route announcement message is sent to a second CE router, with the transit cost value computed as given above. At step <b>604</b>, the second CE router determines the best path to the originating CE router based on comparing BGP MED values for a first AS and a second AS.

0069If the receiving CE router and the PE router are running BGP and if the CE router is multi-homed, a configuration option that causes the BGP process always to compare MED values may be set. For example, in an implementation with Cisco devices, the “bgp always_compare_med” configuration option may be enabled, particularly if the autonomous systems are under a single administrative domain. Comparing MED values resolves the shorter path as a best path for purposes of BGP, and that best path is installed in the routing information base (RIB).

0070If the CE router and the PE router are running BGP, and the CE router is not multi-homed, then MED values should resolve the shorter path as a best path, and that best path is installed in the RIB.

0071If the CE router and the PE router are running IGP, then IGP route metrics are compared, and the resulting best path is installed in the RIB.

00723.5 Benefits and Conclusions

0073The approaches herein provide a mechanism to calculate the cumulative network layer reachability cost of traversing a single autonomous system, or multiple autonomous systems, taking into account the internal cost of traversing each AS. For example, assume that an ISP has a network with routers located in Los Angeles, Chicago, and New York, and these routers are organized as a single autonomous system. Embodiments of the invention enable computation of cost metrics such that a path from Chicago to New York has a cost less than New York to Los Angeles. In past practice, the entire AS is viewed as a unit with a single cost for all paths.

0074The approaches herein also provide a method to normalize different IGP metrics to the value range allowed for the BGP Cost Community attribute.

0075The approaches herein can allow a customer of multiple service providers to select the shortest path for a given route automatically. The approaches herein may be implemented or deployed in any BGP network, but will typically interest service providers that are administering multiple autonomous systems, and MPLS VPN customers of such service providers.

0076The approaches herein also can be used to carry a customer IGP metric across the nodes that a service provider uses to implement a VPN, thus enabling the customer router equipment to calculate the best path among VPN and IGP paths that are available.

00004.0 Implementation Mechanisms—Hardware Overview

0077<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram that illustrates a computer system <b>700</b> upon which an embodiment of the invention may be implemented. The preferred embodiment is implemented using one or more computer programs running on a network element such as a router device. Thus, in this embodiment, the computer system <b>700</b> is a router.

0078Computer system <b>700</b> includes a bus <b>702</b> or other communication mechanism for communicating information, and a processor <b>704</b> coupled with bus <b>702</b> for processing information. Computer system <b>700</b> also includes a main memory <b>706</b>, such as a random access memory (RAM), flash memory, or other dynamic storage device, coupled to bus <b>702</b> for storing information and instructions to be executed by processor <b>704</b>. Main memory <b>706</b> also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor <b>704</b>. Computer system <b>700</b> further includes a read only memory (ROM) <b>708</b> or other static storage device coupled to bus <b>702</b> for storing static information and instructions for processor <b>704</b>. A storage device <b>710</b>, such as a magnetic disk, flash memory or optical disk, is provided and coupled to bus <b>702</b> for storing information and instructions.

0079A communication interface <b>718</b> may be coupled to bus <b>702</b> for communicating information and command selections to processor <b>704</b>. Interface <b>718</b> is a conventional serial interface such as an RS-232 or RS-422 interface. An external terminal <b>712</b> or other computer system connects to the computer system <b>700</b> and provides commands to it using the interface <b>714</b>. Firmware or software running in the computer system <b>700</b> provides a terminal interface or character-based command interface so that external commands can be given to the computer system.

0080A switching system <b>716</b> is coupled to bus <b>702</b> and has an input interface <b>714</b> and an output interface <b>719</b> to one or more external network elements. The external network elements may include a local network <b>722</b> coupled to one or more hosts <b>724</b>, or a global network such as Internet <b>728</b> having one or more servers <b>730</b>. The switching system <b>716</b> switches information traffic arriving on input interface <b>714</b> to output interface <b>719</b> according to pre-determined protocols and conventions that are well known. For example, switching system <b>716</b>, in cooperation with processor <b>704</b>, can determine a destination of a packet of data arriving on input interface <b>714</b> and send it to the correct destination using output interface <b>719</b>. The destinations may include host <b>724</b>, server <b>730</b>, other end stations, or other routing and switching devices in local network <b>722</b> or Internet <b>728</b>.

0081The invention is related to the use of computer system <b>700</b> for determining transit costs across one or more autonomous systems. According to one embodiment of the invention, determining transit costs across one or more autonomous systems is provided by computer system <b>700</b> in response to processor <b>704</b> executing one or more sequences of one or more instructions contained in main memory <b>706</b>. Such instructions may be read into main memory <b>706</b> from another computer-readable medium, such as storage device <b>710</b>. Execution of the sequences of instructions contained in main memory <b>706</b> causes processor <b>704</b> to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory <b>706</b>. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

0082The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor <b>704</b> for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device <b>710</b>. Volatile media includes dynamic memory, such as main memory <b>706</b>. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus <b>702</b>. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

0083Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

0084Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor <b>704</b> for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system <b>700</b> can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector coupled to bus <b>702</b> can receive the data carried in the infrared signal and place the data on bus <b>702</b>. Bus <b>702</b> carries the data to main memory <b>706</b>, from which processor <b>704</b> retrieves and executes the instructions. The instructions received by main memory <b>706</b> may optionally be stored on storage device <b>710</b> either before or after execution by processor <b>704</b>.

0085Communication interface <b>718</b> also provides a two-way data communication coupling to a network link <b>720</b> that is connected to a local network <b>722</b>. For example, communication interface <b>718</b> may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface <b>718</b> may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface <b>718</b> sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

0086Network link <b>720</b> typically provides data communication through one or more networks to other data devices. For example, network link <b>720</b> may provide a connection through local network <b>722</b> to a host computer <b>724</b> or to data equipment operated by an Internet Service Provider (ISP) <b>726</b>. ISP <b>726</b> in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” <b>728</b>. Local network <b>722</b> and Internet <b>728</b> both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link <b>720</b> and through communication interface <b>718</b>, which carry the digital data to and from computer system <b>700</b>, are exemplary forms of carrier waves transporting the information.

0087Computer system <b>700</b> can send messages and receive data, including program code, through the network(s), network link <b>720</b> and communication interface <b>718</b>. In the Internet example, a server <b>730</b> might transmit a requested code for an application program through Internet <b>728</b>, ISP <b>726</b>, local network <b>722</b> and communication interface <b>718</b>. In accordance with the invention, one such downloaded application provides for determining transit costs across autonomous systems as described herein.

0088The received code may be executed by processor <b>704</b> as it is received, and/or stored in storage device <b>710</b>, or other non-volatile storage for later execution. In this manner, computer system <b>700</b> may obtain application code in the form of a carrier wave.

00005.0 Extensions and Alternatives

0089In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.