Olev Kartau, HUT

October 1998

Abstract

This article explains what policy-based routing is. The first part describes RFC 1102, and the second part describes Cisco white paper about policy routing.

Policy routing is a mechanism for routing packets, based on policies or rules set by the network manager. Policy routing is used in situations where it is desirable for certain packets to be routed some way other than the obvious shortest path, such as to provide equal access, protocol-sensitive routing, source-sensitive routing, routing based on interactive versus batch traffic, or routing based on dedicated links.

The Type of Service (TOS) octet in the IP header was originally meant for something like policy-based routing. It comprises three fields: precedence (bits 0 to 2), TOS (bits 3 to 6) and MBZ (bit 7). The precedence field is intended to denote the importance or priority of the datagram, but is not commonly used. The MBZ field should always be zero (0) and is unused. The TOS field denotes the type of service required and is used by the network to make tradeoffs between throughput, delay, reliability and cost. The TOS field is treated as an integer value between 0 and 15. RFC 1349 defines the semantics of five specific TOS values:

Table: TOS values defined by RFC 1349

Although the semantics of the other values are undefined, they are still legal TOS values and network devices must not prevent the use of such values in any way.

If more than one route is found with a finite metric, the TOS values of the selected routes can be used to refine the selection. A route with a TOS value identical to the TOS value in the IP packet will be used in preference to a route with the default TOS value (0).

In the real world, the TOS field in IP packets is not set or used by many IP implementations.

One well-known case of policy routing is the routing management in the Internet backbone. The Policy-Based Routing Database (PRDB) of NSFNET was used for managing routing in the backbone. The database was shut down, and the backbone converted to use more advanced Global Routing Registry (GRR) in December 1994. See one of meeting memos for some more details at [Memo1994]

RFC 1102 by D.Clark, MIT, May 1989

(discussion only)

RFC 1102 describes some basic ideas about Policy Routing.

RFC 1102 noted that a number of routing protocols is used in the Internet, sharing the original idea about route selection to minimize some measure, such as delay. Some newer considerations about resource allocation( resource policies) are poorly enforced by the existing technology in the Internet.

Back in 1989, the closest mechanism to policy routing was EGP, the Exterior Gateway Protocol (RFC 904 from 1984), being an interdomain reachability protocol, now replaced by BGP (Border Gateway Protocol).

In the following, the main ideas of RFC 1102 are briefly explained.

Notation:

AR=Administrative Region

PR=Policy Route

AS=Autonomous System

Route Synthesis

RFC 1102 proposed that Policy Routes should be synthesized at the end point, be attached to packets, and only verified in Policy Gateways. It was compared to policy selection in phone system, where it is the customer of the phone system who selects which of the long distance carriers to use, whether to purchase a fixed price service or pay incrementally for usage, and so on.

Route Verification

The packet should contain an abstract Policy Route: a series of AR identifiers. To validate this route, each Policy Gateway could store the complete selection of acceptable policy routes, and require that an incoming packet have a Policy Route that exactly matched one of the stored entries. It was noted that this degree of constraint probably overspecifies the situation, and may cause an information explosion.

Routing Conditions

Routing conditions could be quite arbitrary. The important constraint was that any condition imposed by the Policy Gateway must be understood by the end points. Policies should not be based on highly dynamic phenomenon.

Ownership of Policy Gateways

Although all the resources of the network were described as being partitioned among the ARs, the Policy Gateways were considered as exception, being on the boundary between ARs.

Policy Terms

RFC 1102 gave examples of policy terms , expressed in the format

((Hs,ARs,ARent),(Hd,ARd,ARexit),UCI,Cg)

where:

Hs is the source host address,

ARs is the source AR,

ARent is the entry AR,

It was noted that in general, the problem of expressing policy terms in compact form is the same as the problem of constructing compact access control lists.

Stateless gateways

D. Clark was worried about Gateways requiring state:

For this to work it is necessary that gateways not be stateless. If each Policy Gateway maintains a cache f recently computed Policy Routes, in particular remembering the result of computing the gateway for each abstract route, then by simply determining whether or not the forward direction or the reverse direction is allowed to constrain the gateway across this boundary, both policies can be enforced. But this requires building gateways with state, which has not been culturally acceptable in the Internet. I therefore consider as a separate topic the virtues of state in Policy Gateways. I believe that fairly simple algorithms exist to set up the required bindings in the Policy Gateways, but that problem is a matter for later study.

Security

Security was discussed in Chapter 10, and three options for abuse were mentioned together with protection schemes:

• false the (user identification) information in the PR
• misuse of a valid PR
• reading out a valid charge code from a PR and then make additional charges against it

Ahead of time

The RFC 1102 itself admitted that several Internet components were not (yet?) present at that time:

• Policy Route IP option
• Policy Gateways
• Policy Servers
• support protocols such as

• global AS up-down protocol
• local (to the AS) Policy Gateway up-down protocol.

Migration to Policy-based routing

RFC 1102 proposed an "Experimental Program -- Migration to Policy Routing " (in three phases)

Phase I

Policy Server is created, able to mimic the function of the missing host and gateway support. Two policy servers start to fool one current gateway.

Phase II

Certain of the current gateways are augmented with the Policy Gateway functions. At the same time, some of the hosts are modified to insert the IP PR option into the packet at the source.

Phase III

The PR design is proposed for general implementation.

This chapter is based on a white paper from Cisco [Cisco-Policy-Routing]

Starting with Cisco Internetwork Operating System (Cisco IOSTM) Software Release 11.0 (introduced Sep 1995), it is possible to implement policies that selectively cause packets to take different paths.

Instead of routing by the destination address, routing policies can be based on the following:

• Identity of a particular end system
• Application
• Protocol
• Size of packets

Policy-based routing also provides a mechanism to mark packets for differentiated, preferential service via queuing techniques in IOS software.

Traffic originating from different sets of users through different Internet connections across the policy routers.

Quality of Service

Differentiated traffic by setting the precedence or type of service (TOS) values in the IP packet headers at the periphery of the network and leveraging queuing mechanisms to prioritize traffic in the core or backbone of the network.

Load Sharing

Distributing traffic among multiple paths based on the traffic characteristics.

Tagging Network Traffic

Cisco's policy-based routing allows the network administrator to classify traffic using access control lists (ACLs) and then set the IP precedence or TOS values, thereby tagging the packets with the defined classification.

Classification of traffic through policy-based routing allows the network administrator to identify traffic for different classes of service at the perimeter of the network and then implement QOS defined for each class of service in the core of the network using priority, custom, or weighted fair queuing techniques. According to Cisco, this process provides savings in comparison to classification of the traffic explicitly at each WAN interface in the core/backbone network.

All incoming packets received on an interface with policy-based routing enabled are considered for policy-based routing and processed according to route maps. Each entry in a route map contains a combination of match and set clauses. The match clauses define the criteria for whether appropriate packets meet the particular policy (that is, the conditions to be met). The set clauses explain how the packets should be routed once they have met the match criteria. The route map statements can also be marked as permit or deny.

If a packet does not meet any of the defined match criteria, then it is routed through the normal destination-based routing process.

Packet forwarding based on configured policies will override normal packet forwarding.

Cisco advises that because the added flexibility may make the environment more difficult to manage and might cause routing loops, policies should be defined in a deterministic manner to keep the environment simple and manageable.

Figure 1.

Organization X has directed that traffic from address range A go through Internet Service Provider ISP1and traffic from address range B go through ISP2.

An organization can direct the bulk traffic associated with a specific activity to use a higher bandwidth, high-cost link for a short time, and continue basic connectivity over a lower bandwidth, low-cost link for interactive traffic.

Figure 2.

A dial-on-demand Integrated Services Digital Network (ISDN) line brought up in response to traffic to the finance server for file transfers selected by policy routing.

References

[RFC-1102] D. Clark "Policy Routing in Internet Protocols"