RIPE Routing Working Group
Jean-Michel Jouanigot
Antonio Blasco Bonito
Francis Dupont
Stefan Fassbender
Anders Hillbo
Ferdinand Hommes
Lothar Klein
Willi Porten
Don Stikvoort
Marten Terpstra
Ruediger Volk
Author's address:
Jean-Michel Jouanigot, [email protected]
1. Introduction
RIPE, Reseaux IP Europeens, is a collaboration
between Regional networks. RIPE is not a network in
itself, and has therefore no Network Operation Center.
One of the most important issues in such a collaboration
is the inter-regional routing between the networks colla-
borating within RIPE.
In order to achieve global connectivity, all organiza-
tions have to collaborate with each other, and create a
"coordinated routing core". This coordinated routing core
exists de facto for more than one year now, but the
current setups have been built on case by case basis, and
have never been published.
At the very beginning, the routing between the interna-
tional routers where mainly built on dynamic routing
algorithms, using interior or exterior routing protocols.
However it is believed that this "open routing" organiza-
tion has reached its limits and another structure has to be
used.
- 1 -
Policy based routing within RIPE May 1992
2. Interior vs Exterior routing protocols
Whilst a single interior routing protocol would be easier
to manage, this approach is currently unrealistic,
mainly because:
* An interior routing protocol between international
routers would mean that an European Backbone exists, with
shared lines and routers, and with a common routing
policy for all the routers and the lines in this backbone.
* If such a backbone would exist, a central entity should
take care of it, and organize the interior routing protocol
within the backbone, as well as the Exterior routing
protocols between this backbone and the National and
disciplinary networks connected to it. This organization
would obviously manage the routers within this backbone,
as well as the lines connecting these routers.
As there is no such "global" backbone, and no such
network operation center, this approach is not applicable.
[1]
The current collaboration is built on a set of lines
and routers, managed by different organizations,
without real general supervision. The RIPE internetwork is
built on a set of Administrative Domains, (every RIPE member
organization has its own) which can have multiple Routing
Domains internally. Therefore, at the borders, the only
applicable routing scheme is to use External Routing proto-
cols between the different Administrative Domains (using
different Autonomous systems numbers), each Administrative
Domain applying its own routing policy.
3. Current routing structure
A routing core member mainly collaborates with
its "neighbors", using an Exterior routing protocol
(or an interior routing protocol used as an Exterior one
in some cases). Unless a router applies a set of res-
trictions, it routes all the European networks, using
the shortest path algorithm. Most of the routers
filter the routes on one criteria: all the networks
they propagate should be registered in the RIPE
database, with a "non LOCAL" flag in the connected field
[R1,R2]. A few others use filters according to peer to
_________________________
[1] The EBONE initiative, which goal is to im-
plement a central common backbone, will not in-
clude all the international infrastructures.
- 2 -
Policy based routing within RIPE May 1992
peer agreements between two routers, applying therefore a
routing policy.
Even if the current network infrastructure is quite sim-
ple, with very few backdoors, and very few backup agree-
ments, care must be taken to avoid routing loops and
unpredictable routing paths. This is avoided on a case by
case basis, using routing announcement filtering.
Finally, a general default route mechanism is being used
to access the US backbones. Most of the routers point
to a default router (or a default network) in Europe or in
the US. This does not prevent European traffic to cross
the Atlantic twice, even if this is avoided as much as pos-
sible [R1].
The current number of European networks routed within RIPE
is more than 1200.
4. Policy based routing
Every router within RIPE is applying a routing policy, even
if it has never been published. These routing policies
were implemented in order to:
* Protect a private line from carrying unwanted traffic,
* Enforce a certain path to a network,
* Avoid incorrect network announcements.
These routing policies have been implemented for politi-
cal and/or technical reasons, and many of them have
never been documented and are still evolving.
Policy based routing is currently under study in
the networking community, and several documents have
already been published [R3,4,5,6,7,8]. All these proposals
try to resolve the issue of expressing policies, and
implementing them. Even if some "simple" models have proved
their efficiency, it is believed that these studies are
not yet finalized, and that a lot of work need to be done.
A good starting point would be to publish, for all the rout-
ing core routers, their routing policies, using for exam-
ple the description proposed in [R3]. However, these policy
statements would require a precise definition of the
Administrative Domains they refer to, the definition of
the User Class Identifiers... It would be more con-
venient to start with a description of the routing policies
in English, collect all this information and define the
Administrative Domains later on.
- 3 -
Policy based routing within RIPE May 1992
All the RIPE members are asked to produce the routing poli-
cies their routers apply. These routing policies will be
collected by the RIPE routing-WG, and published as soon as
possible.
5. Implementation of the Policy based routing
Lots of theoretical solutions exist in order to imple-
ment routing policies between IP networks. Some of them
resolve the problem in general, and others only a few
aspects of it. The main issue is to find an imple-
mented mechanism which is able to deal with the problem we
want to solve.
Proposals like [R3] imply developments of servers, routers
and sometimes modification of the end-nodes, which is
impossible in the near future. The routers we have
today all share a common specification:
* Only one routing space,
* Routing on destination address.
Therefore, only two solutions exist to implement routing
policies [R5]:
* Policy based distribution of routing information
* Policy based packet filtering/forwarding.
The second solution cannot be seriously used, because of
its impact on the performance of the routers. Policy
based distribution of routing information is the only
solution in our environment right now. In some cases
however, packet filtering can be used to enforce a particu-
lar routing policy.
Policy based distribution of routing information does
not solve the problem of routing loops, illegal announce-
ments, and security issues. However, if we can concentrate
in one place all the routing information, it is expected
that we can avoid most of these drawbacks.
6. Autonomous systems organization
One way to implement this policy based distribution of
routing information is to use the well-known concept of
Autonomous System and protocols such as BGP[R6]. Because it
is expected that we can use such a protocol, a BGP
pilot project has been proposed within RIPE, and is
currently progressing.
- 4 -
Policy based routing within RIPE May 1992
For many reasons Autonomous System numbers have not been
used in the RIPE community to distinguish different
Administrative Domains with their own lines, routers and
policies. Many routers within RIPE do not really use
Autonomous Systems for routing. They are rather used only
at the AD border to implement some routing filtering.
Therefore, for the time being, the Autonomous systems
organization is not currently suitable for routing
purposes.
Once the Autonomous systems have been reorganized in Europe,
the Autonomous Systems Numbers and BGP could be used to
implement routing policies. However, BGP is unable to avoid
incorrect and illegal routing announcements. There-
fore, the routing-wg proposes to use policy based distri-
bution of routing information using route announcement
filtering.
The issue is therefore to obtain reliable network lists.
This would require administrative tasks to be performed in
all the routing centers. These tasks would be greatly sim-
plified by using a common database.
7. The RIPE database
The RIPE database already contains a set of use-
ful informations on networks. These informations are
described in [R2]. An example of information one can find
about networks is:
*in: 192.16.184.0
*na: CWI-ETHER
*de: CWI Ethernet (Classical)
*de: Amsterdam
*de: Netherlands
*tc: Piet Beertema
*tc: Daniel Karrenberg
*co: RIPE Internet NSFnet
*de: CWI, Amsterdam
*ch: [email protected] 900802
*so: RIPE
The current definition for the "co" field is:
The definition of this is arbitrary and should
be replaced by something more rational as e.g. AS's
that may be traversed or some such. Suggestions wel-
come.
- 5 -
Policy based routing within RIPE May 1992
LOCAL local only This means routing updates will be blocked in RIPE routers.
RIPE European. This means RIPE routers will distribute routes for this net.
NSF NSFnet. This means the net is in the NSFnet database
ICS Internet Connected Status
EU member of InterEUnet
NORDU member of NORDUnet
BLOCK for local purposes (not in RIPE database)
It is proposed to add a new field named 'rout-pr'
(rp), similar the actual 'co' field. The new field indi-
cates the privileges as granted by a certain networking
organization. The value of the field is a mnemonic specified
by the networking organization.
- 6 -
Policy based routing within RIPE May 1992
Possible values of this field can be:
LOCAL local only (This means routing updates will be
blocked in RIPE routers.)
EUNET member of InterEUnet
NORDUNET member of NORDUnet
HEPNET member of HEPNET
GARR member of GARR
EASINET member of EASINET
NSFNET This network has the NSFNET connected status.
The complete list of these attributes will be defined later
on, as well as the organizations/persons that can grant a
privilege . Procedures to collect attributes and to
authorize the use of attributes with the
organization/person when networks are added to the RIPE
database, are being defined by the NIC coordination
working-group.
These connectivity flags can only be set if agreed by
the organizations that can grant them. This field can
contain several tags.
EXAMPLES:
rp: HEPNET EASINET NSFNET
rp: GARR NSFNET
In addition to this field, a new field 'bdry-gw' (bg)
should indicate the origin of the announcement for this
network in the international routing core. This
'bdry-gw' field indicates the site name which is
allowed to announce this network. Should this field contain
more than one value, this means that the network described
has more than one connection point to the international
infrastructure (for backup purposes for example). This
field should contain "routing center names" and not
router's names in order to limit the number of possible
values for this field. Possible values can be :[2]
_________________________
[2] The complete list of these attributes is to be
defined later on
- 7 -
Policy based routing within RIPE May 1992
CEA
CERN
CIEMAT
CNAF
CNUCE
CNUSC
EUNET/Amsterdam
DESY
DFNGATE
DIST
EASIGATE
FORTH
GMD
ILAN
IN2P3
INRIA
IRIS
JKU
KTH
LEUVEN
NIKHEF
SARA
SWITCH
UKC
ULCC
UNIDO
VIENNA
8. Database object definition
8.1. rout-pr definition
_______________________________________________________________________________________________________________
|| ||
|| rout-pr [flag] [mandatory]||
|| descr [text] [multiple] [mandatory]||
|| authority [text] [mandatory]||
|| guardian [email-address] [mandatory]||
|| admin-c [person] [multiple] [mandatory]||
|| tech-c [person] [multiple] [optional] ||
|| changed [text] [mandatory]||
|| source RIPE [mandatory]||
||||_______________________________________________________________________________________________________________||||
rout-pr:
The name of the flag, that can be a value in the con-
nectivity field of a network entry.
- 8 -
Policy based routing within RIPE May 1992
Format : one textual flag
Example: rout-pr: WCW
status : mandatory
descr:A short description of what the rout-pr is.
Format : text, multiple.
Example: description: Wetenschappelijk Centrum Water-
graafsmeer (WCW)
status: one line mandatory, multiple lines optional
authority:
Formal authority for this rout-pr. This can be an
institute, committee etc.
Format : text
Example: authority: WCW LAN committee
status: mandatory
guardian:
Email address of the guardian authorizing requests for
this rout-pr. It is expected that this email address is
present in the returning authorization message.
Format : one email address
Example: guardian: [email protected]
status: mandatory
admin-c:
Person administratively responsible for this rout-pr.
Format: person, multiple
Example: admin-c: John Doe
status: mandatory
tech-c:
person technically responsible for this rout-pr.
Format: person, multiple
Example: tech-c: Jon Doe
status: optional
changed:
Field containing the person (email) who made the change
and the date of last change.
Format : mailbox yymmdd
Example: changed: [email protected] 910129
status: mandatory
source:
Source of this information. This will normally be RIPE.
Format : text
Example: source: RIPE
status: mandatory
- 9 -
Policy based routing within RIPE May 1992
8.2. bdry-gw definition
_______________________________________________________________________________________________________________
|| ||
|| bdry-gw [flag] [mandatory]||
|| descr [text] [multiple] [mandatory]||
|| location [text] [multiple] [mandatory]||
|| authority [text] [mandatory]||
|| guardian [email-address] [mandatory]||
|| admin-c [person] [multiple] [mandatory]||
|| tech-c [person] [multiple] [mandatory]||
|| changed [text] [mandatory]||
|| source RIPE [mandatory]||
||||_______________________________________________________________________________________________________________||||
bdry-gw:
Name of the boundary gateway. This is not the name of
the actual physical router since that may change.
Format: one textual flag
Example: bdry-gw: NIKHEF
Status: mandatory
descr:Short textual description of the bdry-gw.
Format: text, multiple
Example: description: IP over IXI links
Status: one line mandatory, multiple lines optional
location:
Short textual description of the location of the brdy-
gw.
Format: text, multiple
Example: location: Wetenschappelijk Centrum Water-
graafsmeer (WCW)
Status: one line mandatory, multiple lines optional
admin-c:
Person administratively responsible for this bdry-gw.
Format: person, multiple
Example: admin-c: Marten Terpstra
Status: one line mandatory, multiple lines optional
tech-c:
Person technically responsible for this bdry-gw.
Format: person, multiple
Example: tech-c:Marten Terpstra
Status: one line mandatory, multiple lines optional
authority:
Formal owner of this bdry-gw.
Format: text
- 10 -
Policy based routing within RIPE May 1992
Example: authority: NIKHEF
status: mandatory
guardian:
Mailbox of the guardian of the bdry-gw. Usage as in the
rout-pr object.
Format: mailbox
Example: guardian: [email protected]
Status: mandatory
changed:
Field containing last change date and person who made
the change.
Format : mailbox yymmdd
Example: changed: [email protected] 910129
status: mandatory
source:
Source of this information. This will normally be RIPE.
Format : text
Example: source: RIPE
status: mandatory
8.3. Objects Examples
Please note that these are examples, they may not represent
the real values for these objects.
rout-pr: NIKHEF-IXI
descr: IP over IXI to NIKHEF
authority: NIKHEF
guardian: [email protected]
admin-c: Rob Blokzijl
tech-c: Marten Terpstra
changed: 911001 [email protected]
source: RIPE
bdry-gw: NIKHEF
descr: IP over IXI gateway
location: NIKHEF
location: Wetenscappelijk Centrum Watergraafsmeer (WCW)
location: Amsterdam
authority: NIKHEF
guardian: [email protected]
admin-c: Rob Blokzijl
tech-c: Marten Terpstra
change: 911001 [email protected]
source: RIPE
rout-pr: HEPNET
descr: High Energy Physics Network
authority: HEPnet Technical Committee IP (HTC-IP)
- 11 -
Policy based routing within RIPE May 1992
guardian: [email protected]
admin-c: HTC-IP Chairman
tech-c: HTC-IP Chairman
change: 911001 [email protected]
source: RIPE
9. Implementation of the routing policies
9.1. Principle
The routing policies are implemented in each routing center
using the information contained in the database. The routing
announcements are filtered according to local rules that are
widely published.
As an example, we will consider a routing center composed of
3 routers, and connecting 5 international lines. The lines
1,2,3,4,5 are international connections to other routing
centers, whereas A,B,C are "intra-domain" connections
between routers inside the routing center. The routing
announcements on A,B,C cannot generally be described using
the the information found in the database.
Each network in the database is tagged with a set of flags
(i.e. rout-pr, bdry-gw, cy ...) which could be used by the
routing center to accept or refuse network announcements
comming from other routing centers on the international
lines 1,2,3,4,5 according to the local routing policy. The
database does not describe any "global" routing policy for a
network. Examples :
on line (1) accept any network with cy=PL
on line (2) accept any network with cy=IT except those with rp=EUNET
on line (3) accept any network with cy=IT and rp=EUNET [3]
9.2. Practical examples
one can easily implement the (non published) routing
policy on the GARR-CERN line by:
at CERN: Accept any network from INFN with the follow-
ing statement: cy = IT && rp = GARR
Routing policy for the EUnet/Amsterdam-Dortmund line:
at EUnet/Amsterdam: Accept any network from Dortmund with
_________________________
[3] line (3) is supposed to be an EUNET line to Italy
- 12 -
Policy based routing within RIPE May 1992
the following statement: cy = DE && rp = EUNET
Routing policy for the IN2P3-CERN line:
at CERN: Accept any network from IN2P3 with the follow-
ing statement: cy = FR && bg = IN2P3
9.3. Rules Compiler
The policy based routing statements should be listed in a
common format. A 'Rules Compiler' [4] processes these rules
and extracts, from the database, the lists of networks that
have to be downloaded in the routers to implement the rout-
ing policy.
10. References
R1 Bernhard Stochman, "8th RIPE meeting minutes",
(ripe-m-8), March 1991
R2 R.Blokzijl, "RIPE Databases (ripe-13)", RIPE, 28
August, 1990
R3 D. Clark, "Policy Routing in Internet Protocols", RFC
1102, M.I.T., May 1989
R4 J. Rekhter, "EGP and Policy Based Routing in the New
NSFNet backbone", RFC 1092, February 1989
R5 H-W. Braun, "Models of Policy Based Routing", RFC
1104, Merit/NSFNET, June 1989
R6 J. Honig & all, "Application of the Border Gateway
Protocol in the Internet", RFC 1164, Merit/NSFNet, June
1990
R7 B. Leiner, "Policy Issues in Interconnecting Net-
works", RFC 1124, RIACS, September 1989
R8 D Estrin, "Policy Requirements for Inter Adminis-
trative Domain Routing", RFC 1125, U.S.C. Computer
Science Dpt., November 1989
R9 H-W. Braun, "The NSFNET routing architecture", RFC
1093, Merit, February 1989
_________________________
[4] A Beta test version of this compiler written at
CERN is currently "field tested" at the CERN Routing
Center.
- 13 -
Policy based routing within RIPE May 1992
R10 K. Lougheed, "A border gateway protocol", RFC 1163,
Cisco Systems, June 1990
R11 Scott Brim, "IP routing Between U.S. Government
Agency Backbones and Other Networks", Internet
Draft, Cornell University, January 1990
R12 M. Lepp and M. Steenstrup, "An Architecture
for Inter-Domain Policy Routing", Internet
Draft, BBN Communication Corporation, February 1990