TP/IX Working Group R. L. Ullmann Internet Draft Process Software Corporation June 30, 1993 Transit Policy Routing in TP/IX 1 Status of this Memo This memo discusses the requirements of transit policy routing, and methods of implementation using TP/IX-IPv7 and RAP. It is informational. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. (Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Ullmann DRAFT: expires December 29, 1993 [page 1] Internet draft Transit Policy Routing in TP/IX June 30, 1993 2 Contents 1 Status of this Memo . . . . . . . . . . . . . . . . 1 2 Contents . . . . . . . . . . . . . . . . . . . . . . 2 3 Introduction . . . . . . . . . . . . . . . . . . . . 3 4 Outline of requirements . . . . . . . . . . . . . . 3 4.1 Source selection . . . . . . . . . . . . . . . . . 4 4.2 USA legal requirement . . . . . . . . . . . . . . 4 5 Basic service offering scenario . . . . . . . . . . 5 5.1 Routes offered by IXCs . . . . . . . . . . . . . . 5 5.2 Cost-based selection . . . . . . . . . . . . . . . 5 5.3 Per-datagram route identification . . . . . . . . 6 6 Transit Network Identifier . . . . . . . . . . . . . 6 7 References . . . . . . . . . . . . . . . . . . . . . 7 8 Author's Address . . . . . . . . . . . . . . . . . . 7 Ullmann DRAFT: expires December 29, 1993 [page 2] Internet draft Transit Policy Routing in TP/IX June 30, 1993 3 Introduction The future Internet must support routing under a number of policy constraints, some of which will appear very arbitrary from a technical standpoint, being based on political regulations and such mundane issues as minimizing the monentary cost of specific traffic flows. One specific requirement is the ability of a traffic source to select the transit network(s) to be used for specific subsets of the offerred traffic. While this memo discusses the use of RAP as the routing protocol to provide the policy selection required, this is not exclusive: any routing protocol with the proper features may be used over TP/IX-IPv7 to meet the requirements. Note that while the problems and methods describe the relationship between commercial local-exchange and inter-exchange carriers and their customers, the discussion applies equally well to the cost management problems that occur within large organizations and within the network service providers themselves. 4 Outline of requirements The considerations for selection of IXCs (inter-exchange carriers, in terminology derived from USA usage) include cost, availability, local policies (such as contracts with IXCs), non-local policies (national rules on transit traffic), and the human desire to control what is controllable: e.g., management says we are to use carrier X for all EDI traffic. These considerations can vary rapidly, and multiple selection decisions may be in use simultaneously. A particular source may at the same time be routing some traffic via one carrier, and some via another; there may be dozens of carriers involved. Cost can vary in real time, and may also be affected by volume discount programs (known to the customer and the IXC, but not known to the local exchange). In particular, IXCs may offer pricing in real time, in response to network load or any other factor the IXC wants to take into account. Availability is subject to change: a major failure within one IXC will result in traffic being transferred to others. It is best if this is done by the customer selecting routes, not by "splashing." At the same time, this is going to trip overload event triggers in other IXCs as traffic is transferred, and the results of those trips (premium pricing, rate limitations) must be communicated to the users. A good description of some related problems can be found in [Perl92] pages 245 ff. Ullmann DRAFT: expires December 29, 1993 [page 3] Internet draft Transit Policy Routing in TP/IX June 30, 1993 4.1 Source selection In the following diagram A and B are traffic sources within a customer network, C is the "border" router within the customer's management, N is the first router within the local exchange. D-F is one transit network, and E-G is another. The destination of the traffic is X (possibly with its own set of local exchange and internal routers.) Each router may, of course, be a number of routers in some locally defined topology; they are abstracted here as one. A D ------ ... ------ F \ / \ \ / \ \ / \ C ------ N X / \ / / \ / / \ / B E ------ ... ------ G Router C must be able to acquire knowledge in real time of the availability and costs of the transit networks, and be able to select one for each datagram forwarded to router N. C must also be able to offer this same degree of flexibility in network selection to A and B. Likewise, router N must be able to determine which transit network to use for each datagram received from C, and be able to offer the routes to C. All of the decisions that may possibly be affected by policy must be made available to the customer's equipment. 4.2 USA legal requirement In particular, it is not only unacceptable, but actually illegal in the USA for a local provider to make a decision selecting an inter-exchange provider on behalf of the customer. The present providers of the Internet service in the USA avoid this by using lines leased from the local provider (regional Bell operating company (RBOC) or other local exchange company (LEC)); this effectively excludes the RBOCs and other LECs from the business of providing Internet service under the present (IPv4) routing paradigm. To meet the equal access requirements, the LECs must provide the ability to pre-subscribe a line (not difficult, even with IPv4, although it may cause troublesome interactions with IPv4 routing protocols). The LECs must also provide "per-call" transit network selection. In a connectionless network layer service, this means per-datagram selection. Ullmann DRAFT: expires December 29, 1993 [page 4] Internet draft Transit Policy Routing in TP/IX June 30, 1993 While this requirement is specific to the USA, other countries can be expected to establish similar requirements as they open their telecoms markets to direct competition. 5 Basic service offering scenario Given the complexity of the requirements, it is clear that no standardized structure for making decisions within the (provider) network on the basis of requests for grades of service is going to be adequate. Individual "calls", i.e. flow setups, can demand specific resources, but the general decision making must be offered to the customer equipment, where a decision of arbitrary complexity on an arbitrary set of constraints can be made. The method used in IPv7 and RAP to provide this level of service is described in the following sections. 5.1 Routes offered by IXCs Each IXC offers a set of routes via its interconnection points with the LECs. Each route describes a particular aggregation of destinations; by country, AD, whatever hierarchy may be established with an AD, or individual networks. In some cases, it may be for individual "hosts"; addresses of well-known service offerings, along the lines of (the USA) "800" numbers, which can be located anywhere, via any provider. There may also be routes offered for individual hosts that are roaming in the cellular/wireless service; this may ordinarily be via different interconnection points, and then aggregated into the general service. Each route carries a tag identifying the transit provider. It also carries descriptors of cost and other attributes of the path(s) offered. Some of the routes may carry the target attribute: i.e., the LEC is directed to offer the route only to one specific customer or aggregation. The LECs then offer these routes to their customers, subject to any local policies of the LEC or pre-subscription of the customer. The offered routes carry forward route identifiers assigned by the LEC router. 5.2 Cost-based selection The router at or near the traffic source can then make a decision to use one or more particular routes for a destination. This decision may be based on cost, as viewed by the policies of its owner. A pure monentary-cost based decision may result in very frequent changes of transit network selection, as the networks compete in real time for traffic. Some attention may need to be given to maintaining network stability in this case. Ullmann DRAFT: expires December 29, 1993 [page 5] Internet draft Transit Policy Routing in TP/IX June 30, 1993 5.3 Per-datagram route identification The router making a decision then identifies the route desired by copying the forward route identifier from RAP into the FrID field in the datagrams. For flow, or full connection-based circuit setup, the source router uses the FrID in the setup exchange, and then records the flow ID or circuit LCN (logical channel number) in the FrID field of the IPv7 datagram. If RAP is being used as the setup protocol, this reduces to the same operation. 6 Transit Network Identifier The Transit Network Identifier option of RAP (type 14, format 2, class any) tags a route as being offered by a particular transit network. This permits datagram source selection of route(s) traversing or not traversing the identified network. The data is a domain name, probably the name of the network, although it may be the name of the organization owning the network, particularily in the case of a commerical service offering. It may also be a domain name assigned specifically for this purpose within the naming domain of an organization. Ullmann DRAFT: expires December 29, 1993 [page 6] Internet draft Transit Policy Routing in TP/IX June 30, 1993 7 References [Perl92] Radia Perlman. Interconnections: Bridges and Routers. Addison-Wesley. Reading, Massachusetts. 1992. [RFC1475] Robert Ullmann. TP/IX: The Next Internet. Process Software Corporation. June, 1993. [RFC1476] Robert Ullmann. RAP: Internet Route Access Protocol. Process Software Corporation. June, 1993. 8 Author's Address Robert Ullmann Process Software Corporation 959 Concord Street Framingham, MA 01701 USA Phone: +1 508 879 6994 x226 Email: Ariel@Process.COM Ullmann DRAFT: expires December 29, 1993 [page 7]