Routing Policy Specification Language

Template:TOC-right 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