rfc1786.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,943 行 · 第 1/5 页
TXT
1,943 行
Network Working Group T. Bates
Request for Comments: 1786 MCI Telecommunications Corporation
Category: Informational E. Gerich
Merit, Inc.
L. Joncheray
Merit, Inc.
J-M. Jouanigot
CERN
D. Karrenberg
RIPE NCC
M. Terpstra
Bay Networks, Inc.
J. Yu
Merit, Inc.
March 1995
Representation of IP Routing Policies
in a Routing Registry
(ripe-81++)
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document was originally published as a RIPE document known as
ripe-181 but is also being published as an Informational RFC to reach
a larger audience than its original scope. It has received community
wide interest and acknowledgment throughout the Internet service
provider community and will be used as the basic starting point for
future work on Internet Routing Registries and routing policy
representation. It can also be referred to as ripe-81++. This
document is an update to the original `ripe-81'[1] proposal for
representing and storing routing polices within the RIPE database. It
incorporates several extensions proposed by Merit Inc.[2] and gives
details of a generalized IP routing policy representation to be used
by all Internet routing registries. It acts as both tutorial and
provides details of database objects and attributes that use and make
up a routing registry.
Bates, et al. [Page 1]
RFC 1786 Representing IP Routing Policies in a RR March 1995
Table of Contents
1. Introduction ................................................ 3
2. Organization of this Document ............................... 3
3. General Representation of Policy Information ............... 5
4. The Routing Registry and the RIPE Database .................. 11
5. The Route Object ............................................ 16
6. The Autonomous System Object ................................ 26
7. AS Macros ................................................... 36
8. The Community Object ........................................ 38
9. Representation of Routing Policies .......................... 41
10. Future Extensions .......................................... 50
11. References ................................................. 51
12. Security Considerations .................................... 52
13. Authors' Addresses ......................................... 53
Appendix A - Syntax for the "aut-num" object ................... 55
Appendix B - Syntax for the "community" object ................. 68
Appendix C - Syntax for the "as-macro" object .................. 72
Appendix D - Syntax for the "route" object ..................... 76
Appendix E - List of reserved words ............................ 80
Appendix F - Motivations for RIPE-81++ ......................... 81
Appendix G - Transition strategy ............................... 83
Bates, et al. [Page 2]
RFC 1786 Representing IP Routing Policies in a RR March 1995
1. Introduction
This document is a much revised version of the RIPE routing registry
document known as ripe-81 [1]. Since its inception in February, 1993
and the establishment of the RIPE routing registry, several additions
and clarifications have come to light which can be better presented
in a single updated document rather than separate addenda.
Some of the text remains the same the as the original ripe-81
document keeping its tutorial style mixed with details of the RIPE
database objects relating to routing policy representation. However
this document does not repeat the background and historical remarks
in ripe-81. For these please refer to the original document. It
should be noted that whilst this document specifically references the
RIPE database and the RIPE routing registry one can easily read
"Regional routing registry" in place of RIPE as this representation
is certainly general and flexible enough to be used outside of the
RIPE community incorporating many ideas and features from other
routing registries in this update.
This document was originally published as a RIPE document known as
ripe-181 but is also being published as an Informational RFC to reach
a larger audience than its original scope. It has received large
interest and acknowledgment within the Internet service provider
community and will be used as the basic starting point for future
work on Internet Routing Registries and routing policy
representation. It but can also be referred to as ripe-81++.
We would like to acknowledge many people for help with this document.
Specifically, Peter Lothberg who was a co-author of the original
ripe-81 document for his many ideas as well as Gilles Farrache,
Harvard Eidnes, Dale Johnson, Kannan Varadhan and Cengiz Alaettinoglu
who all provided valuable input. We would also like to thank the
RIPE routing working group for their review and comment. Finally, we
like to thank Merit Inc. for many constructive comments and ideas and
making the routing registry a worldwide Internet service. We would
also like to acknowledge the funding provided by the PRIDE project
run in conjunction with the RARE Technical Program, RIPE and the RIPE
NCC without which this paper would not have been possible.
2. Organization of this Document
This document acts as both a basic tutorial for understanding routing
policy and provides details of objects and attributes used within an
Internet routing registry to store routing policies. Section 3
describes general issues about IP routing policies and their
representation in routing registries. Experienced readers may wish to
skip this section. Section 4 provides an overview of the RIPE
Bates, et al. [Page 3]
RFC 1786 Representing IP Routing Policies in a RR March 1995
database, its basic concepts, schema and objects which make up the
database itself. It highlights the way in which the RIPE database
splits routing information from allocation information. Sections 5,
6, 7 and 8 detail all the objects associated with routing policy
representation. Section 9 gives a fairly extensive "walk through" of
how these objects are used for expressing routing policy and the
general principles behind their use. Section 10 provides a list of
references used throughout this document. Appendix A, B, C and D
document the formal syntax for the database objects and attributes.
Appendix F details the main changes from ripe-81 and motivations for
these changes. Appendix G tackles the issues of transition from
ripe-81 to ripe-81++.
Bates, et al. [Page 4]
RFC 1786 Representing IP Routing Policies in a RR March 1995
3. General Representation of Policy Information
Networks, Network Operators and Autonomous Systems
Throughout this document an effort is made to be consistent with
terms so as not to confuse the reader.
When we talk about "networks" we mean physical networks which have a
unique classless IP network number: Layer 3 entities. We do not mean
organizations.
We call the organizations operating networks "network operators".
For the sake of the examples we divide network operators into two
categories: "service providers" and "customers". A "service provider"
is a network operator who operates a network to provide Internet
services to different organizations, its "customers". The
distinction between service providers and customers is not clear cut.
A national research networking organization frequently acts as a
service provider to Universities and other academic organizations,
but in most cases it buys international connectivity from another
service provider. A University networking department is a customer of
the research networking organization but in turn may regard
University departments as its customers.
An Autonomous System (AS) is a group of IP networks having a single
clearly defined routing policy which is run by one or more network
operators. Inside ASes IP packets are routed using one or more
Interior Routing Protocols (IGPs). In most cases interior routing
decisions are based on metrics derived from technical parameters like
topology, link speeds and load. The entity we refer to as an AS is
frequently and more generally called a routing domain with the AS
just being an implementation vehicle. We have decided to use the term
AS exclusively because it relates more directly with the database
objects and routing tools. By using only one term we hope to reduce
the number of concepts and to avoid confusion. The academically
inclined reader may forgive us.
ASes exchange routing information with other ASes using Exterior
Routing Protocols (EGPs). Exterior routing decisions are frequently
based on policy based rules rather than purely on technical
parameters. Tools are needed to configure complex policies and to
communicate those policies between ASes while still ensuring proper
operation of the Internet as a whole. Some EGPs like BGP-3 [8] and
BGP-4 [9] provide tools to filter routing information according to
policy rules and more. None of them provides a mechanism to publish
or communicate the policies themselves. Yet this is critical for
operational coordination and fault isolation among network operators
and thus for the operation of the global Internet as a whole. This
Bates, et al. [Page 5]
RFC 1786 Representing IP Routing Policies in a RR March 1995
document describes a "Routing Registry" providing this functionality.
Routing Policies
The exchange of routing information between ASes is subject to
routing policies. Consider the case of two ASes, X and Y exchanging
routing information:
NET1 ...... ASX <---> ASY ....... NET2
ASX knows how to reach a network called NET1. It does not matter
whether NET1 is belonging to ASX or some other AS which exchanges
routing information with ASX either directly or indirectly; we just
assume that ASX knows how to direct packets towards NET1. Likewise
ASY knows how to reach NET2.
In order for traffic from NET2 to NET1 to flow between ASX and ASY,
ASX has to announce NET1 to ASY using an external routing protocol.
This states that ASX is willing to accept traffic directed to NET1
from ASY. Policy thus comes into play first in the decision of ASX to
announce NET1 to ASY.
In addition ASY has to accept this routing information and use it.
It is ASY's privilege to either use or disregard the information that
ASX is willing to accept traffic for NET1. ASY might decide not to
use this information if it does not want to send traffic to NET1 at
all or if it considers another route more appropriate to reach NET1.
So in order for traffic in the direction of NET1 to flow between ASX
and ASY, ASX must announce it to ASY and ASY must accept it from ASX:
Bates, et al. [Page 6]
RFC 1786 Representing IP Routing Policies in a RR March 1995
resulting packet flow towards NET1
<<===================================
|
|
announce NET1 | accept NET1
--------------> + ------------->
|
AS X | AS Y
|
<------------- + <--------------
accept NET2 | announce NET2
|
|
resulting packet flow towards NET2
===================================>>
Ideally, and seldom practically, the announcement and acceptance
policies of ASX and ASY are identical.
In order for traffic towards NET2 to flow, announcement and
acceptance of NET2 must be in place the other way round. For almost
all applications connectivity in just one direction is not useful at
all.
Usually policies are not configured for each network separately but
for groups of networks. In practise these groups are almost always
defined by the networks forming one or more ASes.
Routing Policy limitations
It is important to realize that with current destination based
forwarding technology routing policies must eventually be expressed
in these terms. It is relatively easy to formulate reasonable
policies in very general terms which CANNOT be expressed in terms of
announcing and accepting networks. With current technology such
policies are almost always impossible to implement.
The generic example of a reasonable but un-implementable routing is a
split of already joined packet streams based on something other than
destination address. Once traffic for the same destination network
passes the same router, or the same AS at our level of abstraction,
it will take exactly the same route to the destination (disregarding
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?