Routing Policy Specification Language: Difference between revisions
imported>Howard C. Berkowitz No edit summary |
imported>Howard C. Berkowitz No edit summary |
||
Line 8: | Line 8: | ||
*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 |
Revision as of 03:30, 28 March 2009
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.
Describing routes
References
- ↑ C. Alaettinoglu et al. (June 1999), Routing Policy Specification Language (RPSL)