Routing Policy Specification Language

Developed by the Internet Engineering Task Force, the Routing Policy Specification Language (RPSL) is a means of describing abstract routing policy among autonomous systems (AS), the basic building block of global Internet routing. It allows both the definition of policies for the carrying out of business or other goals, but it also has sufficiently fine detail to allow the automatic generation of router configuration language from RPSL descriptions.

While it is not a programming language, it can describe relationships among sets of AS, individual AS, and among routers inside an AS. It is object-oriented, and its major classes are:

• aut-num class: autonomous system
• inet-rtr class: router
• route class: ranges of Internet Protocol addresses
• route-set class: sets of routes
• as-set class: sets of autonomous systems

The fundamental relationship expressed in RPSL is that of peering, involving the advertising (i.e., exporting) and acceptance (i.e., importing) of routes. In practice, these functions will be carried out by the Border Gateway Protocol, although RPSL does not directly generate BGP protocol messages.

A minimal RPSL policy would specify an AS (e.g., AS1) and the directly peered AS (e.g., AS2 and AS3):

aut-num: AS1 
import: from AS2 accept ANY
        from AS3 accept ANY
export: to AS2 announce ANY
        to AS3 announce ANY

Administrative information

Real-world RPSL-defined policies, for the public Internet, are stored in routing registries, for the information of both peered and distant AS. The registry certainly needs to know, and control, who can maintain the entry. Other AS will need contact information for operational troubleshooting.

A very convenient feature is the ability to specify a role versus a person. "Maintainer" is a role that can be occupied by one or more persons.

Defining other AS

AS is a reserved word in the language, and it is quite common to refer to a single AS by its number. A significant amount of the power of the language, however, comes from the ability to express a policy by creating, recursively if desired, a set of other AS.

For example, consider the real-world example of a multilateral peering agreement at an Internet Exchange Point (IXP). One of the major goals of an IXP is to encourage direct peering, or mutual exchange of their customers' routes, with other Internet Service Provider (ISP) present at the same IXP. Assume, for example, that the creator of the policy is AS1, and the other peer ISPs present there are AS2, AS3, AS4, and AS5.

as-set: LOCAL-PEERS
members = AS2, AS3, AS4, AS5

Now, also present at that IXP are non-peer transit providers AS100, AS200, and AS300. Assume AS1 has paid the first two for transit services, but not the third. It will, therefore, have different policies toward the transit providers, in terms of which routes it will accept from them. It will still advertise its routes to all AS present. So, it is useful to be able to say,

as-set: LOCAL-TRANSIT
members = AS100, AS200

but also to be able to express all the cooperating AS at the IXP with a recursive definition:

as-set: IXP-WIDE
members = LOCAL-PEERS, LOCAL-TRANSIT, AS300

Describing routes

A route object is a set of IP addresses, which, when advertised by an AS, means the AS offers connectivity to them. In RPSL, a route (i.e., route object), is more than just an address range. It also contains an AS expression pertaining to which AS either originates the route, or possibly how the route reaches the local AS:

route: 172.20.0.0/16
origin: AS2

and

route: 172.20.0.0/16
origin: AS3

are two different route objects.

In the above examples, the /16 expresses an exact range of addresses (i.e., 172.20.0.0 through 172.20.255.255).

Range expressions

There are many cases in RPSL, however, where it is useful to talks of various subsets of that range, and RPSL has its own operators for range expressions. Alternatively, route-sets can be defined explicitly:

Assume, for example, that AS4444 is a customer of AS1, with two connections between which it wishes to multihome and load-balance. It will prefer to send half its address assignment, 172.16.2.0/23, over each connection, but, if either fail, all the traffic should go over the remaining link. It will, therefore, be necessary to create two route-objects to be advertised to AS1:

route-set: AS4444-point1
members: 172.16.2.0/24, 172.16.2.0/23
route-set: AS4444-point2 
members: 172.16.3.0/24, 172.16.2.0/23

RPSL range operators and effects on 172.16.0.0/16

Suffix	RPSL terminology	Usage
(no suffix)	Exact match	Allow only 172.16.0.0/16
^-	Exclusive more specifics	Allow all more specific subsets of 172.16.0.0/16, but not 172.16.0.0/16 itself
^+	Inclusive more specifics	Allow all more specific subsets of 172.16.0.0/16, and 172.16.0.0/16 itself
^n	All length n	Allow only those more specifics of length n; 172.16.0.0/16^24 includes 172.16.0.0/24, 172.16.1.0/24, etc.
^n-m	Permit all length n through m, but nothing more or less specific	Allow all more specific subsets of 172.16.0.0/16, and 172.16.0.0/16 itself

Route rules can differ at both ends

The policies need not be the same in both AS. AS1 can accept, at each of these points,

route: 172.16.2.0^23-24

because it will import any of the routes at either point. AS4444 has to know how to export selectively. These will go into a peering expression.

Peering expressions

At each end of a peering relationship, there can be different, not necessarily symmetrical, peering epressions. The general form of a peering expression, using import as an example assuming BGP as a slight simplification, is shown below. Terms in square brackets are optional; the vertical line means choice.

import: from <peering-expresion-1>
 [<router-expression-1>]
 [at <router-expression-A] |  <peering-set-name-1>
 ...
      from <peering-expresion-n>
 [<router-expression-n>]
 [at <router-expression-B] | <peering-set-name-n>