Routing Policy Specification Language: Difference between revisions
imported>Howard C. Berkowitz No edit summary |
mNo edit summary |
||
(7 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
{{subpages}} | {{subpages}} | ||
{{TOC|right}} | |||
Developed by the [[Internet Engineering Task Force]], the '''Routing Policy Specification Language (RPSL)''' is a means of describing abstract [[routing policy|routing policy]] among [[autonomous system]]s (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. <ref name=RFC2622>{{citation | Developed by the [[Internet Engineering Task Force]], the '''Routing Policy Specification Language (RPSL)''' is a means of describing abstract [[routing policy|routing policy]] among [[autonomous system]]s (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. <ref name=RFC2622>{{citation | ||
| url = http://www.ietf.org/rfc/rfc2622.txt | | url = http://www.ietf.org/rfc/rfc2622.txt | ||
Line 8: | Line 9: | ||
*aut-num class: autonomous system | *aut-num class: autonomous system | ||
*inet-rtr class: router | *inet-rtr class: router | ||
*route class: ranges of [[Internet Protocol | *route class: ranges of [[Internet Protocol]] addresses | ||
*route-set class: sets of routes | *route-set class: sets of routes | ||
*as-set class: sets of autonomous systems | *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 | 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): | A minimal RPSL policy would specify an AS (e.g., AS1) and the directly peered AS (e.g., AS2 and AS3): | ||
Line 24: | Line 25: | ||
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. | 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== | ==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 | |||
{| class="wikitable" | |||
<center>'''RPSL range operators and effects on 172.16.0.0/16'''</center> | |||
|- | |||
! 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> | |||
==Representative policy expression== | |||
==References== | ==References== | ||
{{reflist}} | {{reflist}}[[Category:Suggestion Bot Tag]] |
Latest revision as of 17:00, 13 October 2024
![](http://s9.addthis.com/button1-share.gif)
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. [1]
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
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>
Representative policy expression
References
- ↑ C. Alaettinoglu et al. (June 1999), Routing Policy Specification Language (RPSL)