📄 rfc1786.txt
字号:
Network Working Group T. BatesRequest for Comments: 1786 MCI Telecommunications CorporationCategory: 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 ............................... 83Bates, et al. [Page 2] RFC 1786 Representing IP Routing Policies in a RR March 19951. 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 RIPEBates, 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 19953. 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. ThisBates, 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 special cases like "type of service" routing, load sharing andBates, et al. [Page 7] RFC 1786 Representing IP Routing Policies in a RR March 1995 routing instabilities). In a concrete example AS Z might be connected to the outside world by two links. AS Z wishes to reserve these links for different kinds of traffic, let's call them black and white traffic. For this purpose the management of AS Z keeps two lists of ASes, the black and the⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -