POLICY ROUTING. Licentiate course seminar paper

Transcription

1 HELSINKI UNIVERSITY OF TECHNOLOGY Laboratory of Telecommunications Technology Licentiate course seminar, October 1996 Revised, December 1996 Mauri Pännäri POLICY ROUTING Licentiate course seminar paper

2 2(10) Abstract This paper deals an area in exterior routing called policy routing. Objectives of policy routing are introduced. Considering provider selection, the possibilities available, including tunneling in BGP, the IDR Protocol and the SDR Protocol, are covered. The most important features of each solution are described in more details. Finally the IDPR approach is introduced. Some conclusions are then presented about the situation now and about the possible progress. Table of contents Abstract...2 Table of contents Introduction Common Policy Routing Provider Selection Explaining the background Tunnelling Extensions Source Demand Routing The SDRP packet Other main SDRP facilities Inter Domain Policy Routing The Autonomous System- level Map Comparison to OSPF AS paths Packet routing in IDPR Conclusions...9 Acronyms...10 References...10

3 3(10) 1. Introduction 1.1 Common Internetworks are heterogeneous by nature. They are formed of component networks, entities, which are owned and operated by different organisations providing different services including access limitations and making use of different protocols for routing information internally and for distribution elsewhere. Co- operation is needed between these component networks to make inter-operation possible, and there is a few important inter- domain protocols, two of which have already been introduced in this series of courses, namely EGP and BGP, /1/. When this co- operation in routing is possible, there is also an apparent need to prevent or limit it in a controlled way. This is called policy routing. 1.2 Policy Routing Widely speaking policy routing means, that there are factors, that force routing to take some other chance than the shortest path. The two most important reasons for this are to create acceptable use- guides or provider selection. This requirement has appeared when internet has reached it's huge speed of commercialisation. There is also the background, that commercial users couldn't reach and make use of the public backbones existing for "academic" and other purposes possibly providing the shortest path. In other words policy routing was a fact to be taken into account and alternative routes must be found. The requirement for policies has then became more and more important. Maybe it is not enough any more to find a valid path, but also to be able to do time- related allocations for example to make use of the cheapest providers during a time period. One also may want to select the route or list of providers for a certain connection which can provide some technical properties that others may not be able to offer, for example throughput or delay. 2. Provider Selection Maybe the ability to select ones provider is the most important and wanted facility considering policy routing. BGP, /1/, offers simple policing properties in some degree, but these are tied to the situation, where the provider is directly connected to the regional domain. Then it is possible for instance to weight and prefer tariffs or services available. 2.1 Explaining the background As being commercial and free, a regional sub- network can let all the regional users have access. Typically it is operating in a limited and relative simple administration as such.

4 4(10) In several cases, however, it is typical, that a user wants to have access to services, which are located in servers outside the regional network an a transit through one ore more transit nodes is needed. In this case the charter drafted by the local operation is no more valid or sufficient. Also there is a requirement that the regional network doesn't give any privileges in a free competition situation considering a possible transit provider. This problem is explained with the following picture: U1 RO TP1 U2 TP2 DE Un TPn Picture 1: The provider selection problem It is assumed, that the Regional Operator (RO) has a monopoly in it's working area. The subscribers or Users (U1, U2, Un) have an unproblematic situation in the region for example to communicate with each other. They also all have a need to communicate with the same Destination (DE), this meaning, that there actually is n routes through several Transit Providers (TP) between RO and DE. Internet Protocol (IP) routing considers only the destination address. Here BGP can only do selecting or filtering the destinations. The transit networks can let through the customers they accept to serve. RO lets TP1, TP2... TPn to know, that all users U1, U2...Un are reachable by the specific RO Autonomous System (AS). In addition TP1 may let DE know, that U1 is reachable via TP1, RO. The same type of situation can hold for TP2...Tpn. However, RO must choose only one way to D. The situation is unsymmetrical. The traffic from DE to U1 goes via TP1, which was also selected by U1, but to the other direction it goes via a TP2 as a default TP defined by RO. This can be an acceptable situation to U1, but in a case that Quality of Service (QoS) requirements are needed by U1, the return route may prove to be insufficient. This is also against the basic principle, that the user should get and pay the resources it has contracted. 2.2 Tunnelling One solution to the problem described above could be achieved by using multiple router tables within the regional network making a route to be a function of both the destination and the address. However, users may for example have agreements with other providers for backup reasons, and the situation may for long be unmanageable for the operator with tools in use. In BGP there is a way, by which a solution, although not an ideal one, can be achieved. A virtual link can be established between the user and the destination using

5 5(10) IP in IP. We have an user domain user1 and a connected station U1x within it wanting to send a TCP- IP packet to in the domain D, as: U1x ----> Dx, tcp tcp header + data Picture 2: IP header This IP packet is carried to the border router in the domain user1, we can call it U1br. Normally this border router would carry the packet so that it eventually would be routed via TR2. But U1br can capsulate the the packet so that it goes to a certain place by giving a new header: U1br ---> T1br, ip-ip U1x ---> Dx, tcp tcp header + data Picture 3: IP headers 1 and 2 This new header is tied to the border router T1br meaning the gateway between RO and TP1 (see picture 1). The protocol is stated as IP in IP an this means that T1 border router will encapsulate the packet and carry it throuhg TP1 to DE. Actually a virtual link is created here. It shall have two main properties: it is available and it can route. This corresponds by some way to having a physical link between the domains user 1 and TE1 and is a step towards the policy routing possibilities considered in this paper, by using BGP. The solution here has its pitfalls. The capsulation enlarges the overhead considerably meaning more processing in the border nodes. This feature (decapsulation) conventionally is not especially fast in routers. Also the solution can cause additional failure modes when backup is needed and it proves to be essentially slower than the main tunnel. 2.3 Extensions The BGP tunnelling technique can be considered as a special case of policy routing. Users may want more choosing properties, for example to be able to select the whole path. The main arguments are again: provider selection and resource reservation / QoS. There is a special protocol which has been developed to fulfil this need better, called Source Demand Routing Protocol (SDRP). It has been developed in the Interment Engineering Task Force (IFTF). It has relations to Inter - Domain Routing Protocol (IDRP) coming from the OSI- world (Open Systems Interconnection). This has also a lot of similarities to BGP. In the following SDRP is described in more detail.

6 6(10) 3. Source Demand Routing 3.1 The SDRP packet The SDRP includes a mechanism to do route selection The SDRP- packet includes three main parts: Delivery (IP) header SDRP header SDRP payload Picture 4: SDRP packet The carried delivery header is a normal IP header including the "next hop" specification. The SDRP payload carries the the data to the end process. The SDRP header carries the route information. To understand the mechanism better, the SDRP header is shown: Ver D S P Hop Count SrcProto Type Payload Type Source Route Identifier Target Router Prefix Prefix length Notification SrcRouteLgth NexrHopPtr Source Route Picture 5: The SDRP header The IP header specifies the destination IP address normally. When the destination (router) gets the packet, it will progress this source route. IP destination field is replaced by the next element in the source- route specification including "next hop pointer"(incremented) and "SDRP hop count" (decremented), and carries the packet on. If the hop count is null, an error is indicated and the packet is not forwarded. If the next hop pointer is larger than or equal to the "source route length", the packet is not either forwarded because this measures the end of the source- initiated route. Then "payload type" is checked. If this is 1, this represents a normal complete IP packet and is handled on normally. This process then acts as an encapsulation mechanism between the border domains. 3.2 Other main SDRP facilities There is a need to provide eccicient error recovery, to define different categories of routes and to support the set- up of paths.

7 7(10) In SDRP, if an error happens during relaying a packet, the router which has noticed the error, sends back a specific report message. It includes the incoming IP header and the 8 first bytes of the content and is meant to the initial source router. The bytes 5-8 in the "Source Route Identifier" accurately identify the source route in question. In addition the "hop count" in the second byte assists the initial router to see what went wrong. There are three special flags in the first byte, namely S, D and B. The S bit is used to identify whether a "loose" (0) or a "strict"(1) source routing is in question and provides a means not to use another, maybe a "looser" route for example in a case of failure. The other two bits are used to differentiate data packets (D = 1) from control packets and to indicate the the source route is being "probed" (P = 1). The IETF working group around SDRP is still studying some new features to the protocol considering set-up (byte "Source Proto(col) Type"). This in not considered further. 4. Inter Domain Policy Routing IETF has worked on an policy approach called Inter Domain Policy Routing (IDPR), and is described in IETF Request For Comments (RFC)- papers RFC 1477, /2/ RFC 1478, /3/ and RFC 1479, /4/ A very short description can be found in /5/. It is said to be even more complex than OSPF. To day it is still not much used in internet. In the following only the main features are discussed. 4.1 The Autonomous System- level Map Internet can be considered to be composed of the interconnection of Autonomous Systems (AS). ASs present suitable blocks for a high- level linking map. Even at this level the amount of elementary blocks the corresponding database needed including all ASs and all links can be too big and maybe further aggregation is needed. This can be done by including only ASs that are in charge of transit relaying or provider services. It is the estimated, that "only" hundreds of ASs is then being left leaving outside several tens of thousands stub or multihomed ASs in the periphery of the model, /6/. The IDPR map contains objects. The two main objects are "domains" and "virtual gateways". AS is a domain. A set of "policy gatewys" (in practice several border routers) that link the ASs is a virtual gateway. By combining policy gateways for a virtual gateway faster access between ASs can be achieved and thus memory can be saved at the end databases. Also better stability can be achieved, because the virtual gateway will remain up when there is enough policy gateways left. A domain is identified by its AS number and a virtual gateway is identified by a pair of AS numbers and an additional "virtual gateway number". There is also two other objects in the model to identify the policy gateways and the route servers. These are identified by the combination of their AS numbers and local identifier assigned by the local domain administrator.

8 8(10) The database includes status of virtual gateways and configuration information about domains, this including a domains "transit policy" using "restrictions", "quality" and "cost" definitions. Additional information can also be included as "temporal specifications". 4.2 Comparison to OSPF Compared to OSPF, which also includes a flooding protocol to distribute the database to all servers, the time to live for information is expected to be essentially longer which means easier maintenance for the database. In OSPF all the routers are under the same authority making security aspects relatively simple by only suitable authentication. IDPR routers are located all over the Internet and it is essential, that the information flooded "in" is definitely correct. That is why time stamp and digital signature methods are used. In OSPF in one area all routers have synchronised copies of the database. This wouldn't work well in a system as big as the whole internet. IDPR solves the problem by using source specified routing, similiar to SDRP and this removes the need of consistency. 4.3 AS paths IDPR uses route servers either co- locating with the main policy servers or being separate agents. A request list in IDPR includes as "on demand", up to the profile requested, the source, the destination, QoS needed and cost factors. The following situation might exist in the database: A B C D E F Picture 6: AS paths The target could be a path connection between A and D. If a suitable link (for example bandwidth B) is not available between C-D, this is removed from the map. Also node E must be removed because of routing restrictions. Then a route A-B-C- F- D is the only satisfactory (in this case). The algorithm needed to build up is simple basing on links available meeting requirements. The shortest path first - principle remains valid. Multiple paths can be found (not in this example). 4.4 Packet routing in IDPR Policy routing using IDPR has three main points:

9 9(10) * the local domain route server gives a description of one of several policy routes as a result of a query from a source * The local path agent provides the possibility selected and asked by the source * When the path is ready, packets can be forwarded Actually the path set- up is a procedure to make a virtual circuit. A path is identified by concatenating the AS number of the source, the identifier of the originators policy gateway, and a 32 bits long local path identifier specified by the originator. The set-up request goes on hop- by - hop from policy gateway to another always checking the transit policies of the domain in question. The path is established when the setup message reaches the target domain. An acceptation message is then sent backwards signalling that the path is available. When the path is found, the list of virtual gateways is transformed into one specific list of policy gateways. In a failure situation maybe another policy gateway can then be found on the same gateway. 5. Conclusions A few policy routing procedures have been introduced. Maybe the IDPR- concept is the most advanced one trying to have a global macro- level study. As in all widespread or global systems there is the difficulty of common standardisation and acceptance making proceeding go slow. It is apparent, that policy routing is a desired and even an essential function in future Internet routing. The situation at the moment is, that only simple provider selection by tunnelling is used. SDRP and IDPR are in an experimental phase. SDRP specification is still under finalization, an IDPR has its problem being a complicated solution. Probably both protocols are needed together as a compromise.

10 10(10) Acronyms AS Autonomous System BGP Border Gateway Protocol DE Destination EGP Exterior Gateway Protocol IDPR Inter Domain Policy Routing IP Internet Protocol IRTF Internet Engineering Task Force OSPF Open Shortest Path First PR Policy Routing QoS Quality of Service RO Regional Operator SDR Source Demand Routing SDRP Source Demand Switching Protocol TCP Transmission Conrol Protocol TP Transit Provider References /1/ Philippe Rua: Licentiate course seminar presentation and paper on EGP and BGP, October 1996, presented in the 8 th of October /2/ Request For Comments 1477, IDRP as a Proposed Standard, M. Steenstrup, July 1993 /3/ Request For Comments 1478, an Architecture for Inter- Domain Policy Routing, M. Steenstrup, June 1993 /4/ Request For Comments 1479, Inter- Domain Policy Routing Protocol Specification, M Steestrup, July 1993 /5/ David M. Picitello & A. Lyman Chapin: Open systems Networking, Addison Wesley Publishing Company, /6/ Christian Huitema: Routing in the Internet, Prentice Hall PTR 1995,