Routing Policy Specification Language: Difference between revisions
imported>Howard C. Berkowitz No edit summary |
imported>Howard C. Berkowitz No edit summary |
||
| Line 5: | Line 5: | ||
| author = C. Alaettinoglu ''et al.'' | date = June 1999}}</ref> | | author = C. Alaettinoglu ''et al.'' | date = June 1999}}</ref> | ||
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. | 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== | ==References== | ||
{{reflist}} | {{reflist}} | ||
Revision as of 04:28, 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)