- 1 - Network Working Group Y. Rekhter INTERNET DRAFT T.J. Watson Research Center, IBM Corp. September 1993 Selecting an Indirect Provider Status of this Memo 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 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. 1 Introduction The Border Gateway Protocol (BGP) [1] and Inter-Domain Routing Protocol (IDRP) [2] are two similar protocols that can be used for inter-domain routing. It was asserted that not all routing policies can be supported with these protocols. Specifically, as stated in [1], "BGP does not enable one AS to send traffic to a neighboring AS intending that the traffic take a different route from that taken by traffic originating in the neighboring AS". In this document we describe a simple approach to remove this limitation from BGP and IDRP. The proposed scheme can be realised with the existing technology and off-the shelf components and doesn't require any new routing protocols. Expiration Date March 1994 [Page 1] - 2 - 2 Background The Internet is viewed as a set of arbitrary interconnected Autonomous Systems (Domains). An autonomous system that carries transit traffic is called a service provider (or just a provider). An autonomous system that uses other autonomous system(s) to carry locally originated traffic is called a service subscriber (or just a subscriber). A provider that has an external neighbor (in the BGP/IDRP sense) with one of the BGP/IDRP speakers within a subscriber is called the direct provider (with respect to the subscriber). All other providers are called indirect (with respect to the subscriber). Within the current model (see [1]) BGP/IDRP limits the choice of routes available to a subscriber to the routes selected by all of its direct providers. A route available to a direct provider, but not selected by the provider can't be made available to the subscriber. As an illustration of this limitation consider the following topology (the example is taken from [3]): D B \ / \ \ / \ \ / \ C A / \ / / \ / / \ / / \/ F E where A, B, C, D, E, and F are autonomous systems. C has to select between B and E as the next hop domain to destinations in A. Consequently C's subscribers, D and F, would be bounded by C's choices. If D would prefer to use route through B, and F would prefer to use route through E, then it was asserted that such policies could not be realised with BGP. Expiration Date March 1994 [Page 2] - 3 - 3 Solving the problem The problem of removing the limit of choices imposed on a subscriber by its direct providers can be decomposed into two orthogonal, but somewhat related subproblems: - how does a subscriber learn routes available through its indirect provider, if the direct provider doesn't select these routes - given that a subscriber acquires the routes available through its indirect provider and selects these routes, how does the subscriber ensure forwarding consistent with the selected routes. 3.1 How to acquire routes from an indirect provider Since BGP/IDRP operate over IP, it follows that if a subscriber has IP connectivity to any BGP/IDRP speaker in an indirect provider, then a BGP/IDRP speaker within the subscriber can establish a BGP/IDRP session with a BGP/IDRP speaker within the indirect provider. The only needed modification to BGP/IDRP is to remove the restriction that external neighbors should share a common subnet. Alternatively one may configure a tunnel (via encapsulation) between a BGP/IDRP speaker within a subscriber and a BGP/IDRP speaker within its indirect providers. Then BGP/IDRP routing information exchange would flow through this tunnel and from a conceptual point of view the two speakers would be viewed as connected by a point-to-point link and thus on a common subnet. That would avoid any changes to BGP/IDRP. For the purpose of route selection and route distribution policies routes acquired from a BGP/IDRP speaker in the indirect provider are indistinguishable from the routes acquired from a direct provider. 3.2 How to provide consistent forwarding Providing forwarding consistent with the routes acquired from an Expiration Date March 1994 [Page 3] - 4 - indirect provider requires an additional mechanism. This is because routes selected by a direct provider may not be consistent with the routes a subscriber selected from an indirect provider. The mechanism should allow to hide the actual destination address, and force the immediate provider to use instead the address of BGP/IDRP speaker in the indirect provider for forwarding. A possible way to provide this functionality is to use encapsulation, where the original packet is wrapped into an envelope, with the destination address in the outer IP header specifying the address of the BGP/IDRP speaker in the indirect provider. Any encapsulation can suit this purpose (e.g. [4], [5]). Alternatively one may consider using IP LSRR option. 3.3 Further refinements A BGP/IDRP speaker in the indirect provider may specify in the NEXT_HOP path attribute address of some other entity. This way, other than the speaker entity may support encapsulation and forwarding. The document constrains this entity to be within the same autonomous system as the speaker. A BGP/IDRP speaker within a subscriber may use BGP/IDRP information to ascertain the actual path to its BGP/IDRP peer in the indirect provider by using the AS_PATH/RD_PATH path attribute. This would allow the speaker to refine its route selection to take into account not only the available routes, but also the actual path to the indirect provider from which the routes are acquired. 3.4 An example of operations We illustrate how the proposed scheme operates using the topology described in Section 2. Assume that C prefers routes through B to destinations in A, but when connectivity to B fails, C would switch to routes through E. C advertises these routes to both F and D. The routes selected by C are consistent with D's route selection policies (path through B as a primary, path through E as a fallback), but are in conflict with F's route selection policies (path through E as a primary, path through B as a fallback). To satisfy F's route selection policies a BGP/IDRP speaker in F establishes direct peering with a BGP/IDRP in E (E is F's indirect provider). As a result, F Expiration Date March 1994 [Page 4] - 5 - would acquire routes to destinations in A through E (directly) and through B (acquired from C). This information is sufficient to satisfy F's route selection policies. If the BGP/IDRP speaker in F selects a route received from the BGP/IDRP speaker in E, then the forwarding table entry derived from the route should have the next hop set to the address carried in the NEXT_HOP path attribute; the entry should also indicate the need for encapsulation. To ensure forwarding consistent with the selected routes the BGP/IDRP speaker in F that peers with the BGP/IDRP speaker in E uses encapsulation when forwarding along the routes received from E. The destination address in the outer header is set to the IP address of the BGP/IDRP speaker in E. If the connection between C and E breaks, the BGP/IDRP speaker in F peering with the BGP/IDRP speaker in E would be able to detect this by examining the BGP/IDRP route to destinations in E (the new AS_PATH/RD_PATH will be (C, B, A, E)). Using this information the speaker in F would fall back on routes available through C (and B). 4 Limitations The proposed scheme doesn't work if a subscriber doesn't have IP connectivity to the indirect provider it wants to select. On the other hand, it isn't clear how much sense it would make trying to support the ability of a subscriber to select an indirect provider to which the subscriber has no IP connectivity. While the proposed solution may be suitable to solve other problems, such a discussion is outside the scope of this document. Specifically, suitability of the proposed solution to an arbitrary policy-based routing problem (a.k.a. "arbitrary internet" (AI) problem) is outside the scope of this document. 5 Conclusions This document describes how the existing routing protocols (with optional very minor modification) combined with encapsulation can be used to solve the problem of indirect provider selection. It provides the same dynamic rerouting capabilities as available with BGP/IDRP and requires no additional configuration (other than to Expiration Date March 1994 [Page 5] - 6 - optionally configure a single tunnel). The scheme doesn't require introduction of any new routing protocols and/or new network layer protocol - it is based on existing off-the-shelf components. The functionality provided by the scheme described in the document is quite similar to the "long-distance" provider selection available in today's telephony. The scheme may be used in similar circumstances to enable "long-distance" provider selection functionality in the Internet. While the scheme is described in terms of IP, it can be directly applicable to other existing connectionless network layer protocols, like CLNP. 6 Acknowledgements This proposal was largely stimulated by a discussion with Peter Ford (LANL). The author would like to express his deep thanks and appreciation to Dennis Ferguson (ANS), Dave Katz (cisco Systems), Tony Li (cisco Systems), and Curtis Villamizar (ANS) for their review and constructive comments. References [1] Rekhter, Y., Li, T., `A Border Gateway Protocol 4 (BGP-4)', Internet Draft, April 1993 [2] Hares, S., `IDRP for IP', Internet Draft, March 1993 [3] Estrin, D., Steenstrup, M., "Inter-Domain Policy Routing: Overview of Architecture and Protocols", ACM CCR Vol 21, No 1, January 1991 [4] Estrin, D., Zappala, D., Li, T., Rekhter, Y., "Source Demand Routing: Packet Format and Forwarding Specification (Version 1)" Internet Draft, September 1993 [5] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing Encapsulation (GRE)", Internet Draft, September 1993 Expiration Date March 1994 [Page 6] - 7 - Security Considerations Security issues are not discussed in this memo. Author's Addresses Yakov Rekhter T.J. Watson Research Center IBM Corporation P.O. Box 218 Yorktown Heights, NY 10598 Phone: (914) 945-3896 email: yakov@watson.ibm.com email: tli@cisco.com Expiration Date March 1994 [Page 7]