📄 draft-ietf-idr-bgp4-22.txt
字号:
Network Working Group Y. RekhterINTERNET DRAFT Juniper Networks T. Li Procket Networks, Inc. S. Hares NextHop Technologies, Inc. Editors A Border Gateway Protocol 4 (BGP-4) <draft-ietf-idr-bgp4-22.txt>Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.Abstract The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol.Expiration Date April 2004 [Page 1]RFC DRAFT October 2003 The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity for this reachability from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy decisions that can (and can not) be enforced using BGP. BGP can support only the policies conforming to the destination-based forwarding paradigm. This specification covers only the exchange of IP version 4 network reachability information.Expiration Date April 2004 [Page 2]RFC DRAFT October 2003 Table of Contents 1. Definition of commonly used terms . . . . . . . . . . . . . . 5 2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 Specification of Requirements . . . . . . . . . . . . . . . . . . 8 3. Summary of Operation . . . . . . . . . . . . . . . . . . . . . 8 3.1 Routes: Advertisement and Storage . . . . . . . . . . . . . . 9 3.2 Routing Information Bases . . . . . . . . . . . . . . . . . . 10 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 4.1 Message Header Format . . . . . . . . . . . . . . . . . . . . 12 4.2 OPEN Message Format . . . . . . . . . . . . . . . . . . . . . 13 4.3 UPDATE Message Format . . . . . . . . . . . . . . . . . . . . 15 4.4 KEEPALIVE Message Format . . . . . . . . . . . . . . . . . . 22 4.5 NOTIFICATION Message Format . . . . . . . . . . . . . . . . . 22 5. Path Attributes . . . . . . . . . . . . . . . . . . . . . . . 24 5.1 Path Attribute Usage . . . . . . . . . . . . . . . . . . . . 26 5.1.1 ORIGIN . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1.2 AS_PATH . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1.3 NEXT_HOP . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.1.4 MULTI_EXIT_DISC . . . . . . . . . . . . . . . . . . . . . . 29 5.1.5 LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . 30 5.1.6 ATOMIC_AGGREGATE . . . . . . . . . . . . . . . . . . . . . 30 5.1.7 AGGREGATOR . . . . . . . . . . . . . . . . . . . . . . . . 31 6. BGP Error Handling . . . . . . . . . . . . . . . . . . . . . . 31 6.1 Message Header error handling . . . . . . . . . . . . . . . . 31 6.2 OPEN message error handling . . . . . . . . . . . . . . . . . 32 6.3 UPDATE message error handling . . . . . . . . . . . . . . . . 33 6.4 NOTIFICATION message error handling . . . . . . . . . . . . . 35 6.5 Hold Timer Expired error handling . . . . . . . . . . . . . . 35 6.6 Finite State Machine error handling . . . . . . . . . . . . . 35 6.7 Cease . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.8 BGP connection collision detection . . . . . . . . . . . . . 36 7. BGP Version Negotiation . . . . . . . . . . . . . . . . . . . 37 8. BGP Finite State machine . . . . . . . . . . . . . . . . . . . 38 8.1 Events for the BGP FSM . . . . . . . . . . . . . . . . . . . 39 8.1.1 Optional Events linked to Optional Session attributes . . . 39 8.1.2 Administrative Events . . . . . . . . . . . . . . . . . . 44 8.1.3 Timer Events . . . . . . . . . . . . . . . . . . . . . . . 47 8.1.4 TCP connection based Events . . . . . . . . . . . . . . . . 49 8.1.5 BGP Messages based Events . . . . . . . . . . . . . . . . . 51 8.2 Description of FSM . . . . . . . . . . . . . . . . . . . . . 53 8.2.1 FSM Definition . . . . . . . . . . . . . . . . . . . . . . 53 8.2.1.1 Terms "active" and "passive" . . . . . . . . . . . . . . 54 8.2.1.2 FSM and collision detection . . . . . . . . . . . . . . . 54 8.2.1.3 FSM and Optional Attributes . . . . . . . . . . . . . . 55 8.2.1.4 FSM Event numbers . . . . . . . . . . . . . . . . . . . . 55Expiration Date April 2004 [Page 3]RFC DRAFT October 2003 8.2.1.5 FSM actions that are implementation dependent . . . . . . 56 8.2.2 Finite State Machine . . . . . . . . . . . . . . . . . . . 56 9. UPDATE Message Handling . . . . . . . . . . . . . . . . . . . 72 9.1 Decision Process . . . . . . . . . . . . . . . . . . . . . . 73 9.1.1 Phase 1: Calculation of Degree of Preference . . . . . . . 74 9.1.2 Phase 2: Route Selection . . . . . . . . . . . . . . . . . 74 9.1.2.1 Route Resolvability Condition . . . . . . . . . . . . . . 76 9.1.2.2 Breaking Ties (Phase 2) . . . . . . . . . . . . . . . . . 77 9.1.3 Phase 3: Route Dissemination . . . . . . . . . . . . . . . 79 9.1.4 Overlapping Routes . . . . . . . . . . . . . . . . . . . . 80 9.2 Update-Send Process . . . . . . . . . . . . . . . . . . . . . 81 9.2.1 Controlling Routing Traffic Overhead . . . . . . . . . . . 82 9.2.1.1 Frequency of Route Advertisement . . . . . . . . . . . . 82 9.2.1.2 Frequency of Route Origination . . . . . . . . . . . . . 83 9.2.2 Efficient Organization of Routing Information . . . . . . . 83 9.2.2.1 Information Reduction . . . . . . . . . . . . . . . . . . 83 9.2.2.2 Aggregating Routing Information . . . . . . . . . . . . . 84 9.3 Route Selection Criteria . . . . . . . . . . . . . . . . . . 86 9.4 Originating BGP routes . . . . . . . . . . . . . . . . . . . 87 10. BGP Timers . . . . . . . . . . . . . . . . . . . . . . . . . 87 Appendix A. Comparison with RFC1771 . . . . . . . . . . . . . . . 88 Appendix B. Comparison with RFC1267 . . . . . . . . . . . . . . . 89 Appendix C. Comparison with RFC 1163 . . . . . . . . . . . . . . 90 Appendix D. Comparison with RFC 1105 . . . . . . . . . . . . . . 90 Appendix E. TCP options that may be used with BGP . . . . . . . . 91 Appendix F. Implementation Recommendations . . . . . . . . . . . 91 Appendix F.1 Multiple Networks Per Message . . . . . . . . . . . 91 Appendix F.2 Reducing route flapping . . . . . . . . . . . . . . 92 Appendix F.3 Path attribute ordering . . . . . . . . . . . . . . 92 Appendix F.4 AS_SET sorting . . . . . . . . . . . . . . . . . . . 92 Appendix F.5 Control over version negotiation . . . . . . . . . . 93 Appendix F.6 Complex AS_PATH aggregation . . . . . . . . . . . . 93 Security Considerations . . . . . . . . . . . . . . . . . . . . . 94 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 94 IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Full Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 95 Normative References . . . . . . . . . . . . . . . . . . . . . . 96 Non-normative References . . . . . . . . . . . . . . . . . . . . 96 Authors Information . . . . . . . . . . . . . . . . . . . . . . . 98Expiration Date April 2004 [Page 4]RFC DRAFT October 2003Abstract The Border Gateway Protocol (BGP) is an inter-Autonomous System rout- ing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reacha- bility information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This informa- tion is sufficient to construct a graph of AS connectivity for this reachability from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy deci- sions that can (and can not) be enforced using BGP. BGP can support only the policies conforming to the destination-based forwarding paradigm.1. Definition of commonly used terms This section provides definition for terms that have a specific mean- ing to the BGP protocol and that are used throughout the text. Adj-RIB-In The Adj-RIBs-In contain unprocessed routing information that has been advertised to the local BGP speaker by its peers. Adj-RIB-Out The Adj-RIBs-Out contains the routes for advertisement to specific peers by means of the local speaker's UPDATE messages. Autonomous System (AS) The classic definition of an Autonomous System is a set of routers under a single technical administration, using an interior gateway protocol (IGP) and common metrics to determine how to route pack- ets within the AS, and using an inter-AS routing protocol to determine how to route packets to other ASs. Since this classicExpiration Date April 2004 [Page 5]RFC DRAFT October 2003 definition was developed, it has become common for a single AS to use several IGPs and sometimes several sets of metrics within an AS. The use of the term Autonomous System here stresses the fact that, even when multiple IGPs and metrics are used, the adminis- tration of an AS appears to other ASs to have a single coherent interior routing plan and presents a consistent picture of what destinations are reachable through it. BGP Identifier A 4-octet unsigned integer indicating the BGP Identifier of the sender of BGP messages. A given BGP speaker sets the value of its BGP Identifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer. BGP speaker A router that implements BGP. EBGP External BGP (BGP connection between external peers). External peer Peer that is in a different Autonomous System than the local sys- tem. Feasible route An advertised route that is available for use by the recipient. IBGP Internal BGP (BGP connection between internal peers). Internal peer Peer that is in the same Autonomous System as the local system.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -