From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1105.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc1105.txt (limited to 'doc/rfc/rfc1105.txt') diff --git a/doc/rfc/rfc1105.txt b/doc/rfc/rfc1105.txt new file mode 100644 index 0000000..32434e1 --- /dev/null +++ b/doc/rfc/rfc1105.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group K. Lougheed +Request for Comments: 1105 cisco Systems + Y. Rekhter + T.J. Watson Research Center, IBM Corp. + June 1989 + + A Border Gateway Protocol (BGP) + +Status of this Memo + + This RFC outlines a specific approach for the exchange of network + reachability information between Autonomous Systems. + + At the time of this writing, the Border Gateway Protocol + implementations exist for cisco routers as well as for the NSFNET + Nodal Switching Systems. A public domain version for "gated" is + currently being implemented. + + Distribution of this memo is unlimited. + +1. Introduction + + The Border Gateway Protocol (BGP) is an inter-autonomous system + routing protocol. It is built on experience gained with EGP as + defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as + described in RFC 1092 [2] and RFC 1093 [3]. + + 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 autonomous + systems (AS's) that traffic must transit to reach these networks. + This information is sufficient to construct a graph of AS + connectivity from which routing loops may be pruned and policy + decisions at an AS level may be enforced. + + BGP runs over a reliable transport level protocol. This eliminates + the need to implement explicit update fragmentation, retransmission, + acknowledgement, and sequencing. Any authentication scheme used by + the transport protocol may be used in addition to BGP's own + authentication mechanisms. + + The initial BGP implementation is based on TCP [4], however any + reliable transport may be used. A message passing protocol such as + VMTP [5] might be more natural for BGP. TCP will be used, however, + since it is present in virtually all commercial routers and hosts. + In the following descriptions the phrase "transport protocol + connection" can be understood to refer to a TCP connection. BGP uses + TCP port 179 for establishing its connections. + + + +Lougheed & Rekhter [Page 1] + +RFC 1105 BGP June 1989 + + +2. Summary of Operation + + Two hosts form a transport protocol connection between one another. + They exchange messages to open and confirm the connection parameters. + The initial data flow is the entire BGP routing table. Incremental + updates are sent as the routing tables change. Keepalive messages + are sent periodically to ensure the liveness of the connection. + Notification messages are sent in response to errors or special + conditions. If a connection encounters an error condition, a + notification message is sent and the connection is optionally closed. + + The hosts executing the Border Gateway Protocol need not be routers. + A non-routing host could exchange routing information with routers + via EGP or even an interior routing protocol. That non-routing host + could then use BGP to exchange routing information with a border + gateway in another autonomous system. The implications and + applications of this architecture are for further study. + + If a particular AS has more than one BGP gateway, then all these + gateways should have a consistent view of routing. A consistent view + of the interior routes of the autonomous system is provided by the + intra-AS routing protocol. A consistent view of the routes exterior + to the AS may be provided in a variety of ways. One way is to use + the BGP protocol to exchange routing information between the BGP + gateways within a single AS. In this case, in order to maintain + consist routing information, these gateways MUST have direct BGP + sessions with each other (the BGP sessions should form a complete + graph). Note that this requirement does not imply that all BGP + gateways within a single AS must have direct links to each other; + other methods may be used to ensure consistent routing information. + +3. Message Formats + + This section describes message formats and actions to be taken when + errors are detected while processing these messages. + + Messages are sent over a reliable transport protocol connection. A + message is processed after it is entirely received. The maximum + message size is 1024 bytes. All implementations are required to + support this maximum message size. The smallest message that may be + sent consists of a BGP header without a data portion, or 8 bytes. + + The phrase "the BGP connection is closed" means that the transport + protocol connection has been closed and that all resources for that + BGP connection have been deallocated. Routing table entries + associated with the remote peer are marked as invalid. This + information is passed to other BGP peers before being deleted from + the system. + + + +Lougheed & Rekhter [Page 2] + +RFC 1105 BGP June 1989 + + +3.1 Message Header Format + + Each message has a fixed size header. There may or may not be a data + portion following the header, depending on the message type. The + layout of these fields is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Marker | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version | Type | Hold Time | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Marker: 16 bits + + The Marker field is 16 bits of all ones. This field is used to + mark the start of a message. If the first two bytes of a message + are not all ones then we have a synchronization error and the BGP + connection should be closed after sending a notification message + with opcode 5 (connection not synchronized). No notification data + is sent. + + Length: 16 bits + + The Length field is 16 bits. It is the total length of the + message, incluluding header, in bytes. If an illegal length is + encountered (more than 1024 bytes or less than 8 bytes), a + notification message with opcode 6 (bad message length) and two + data bytes of the bad length should be sent and the BGP connection + closed. + + Version: 8 bits + + The Version field is 8 bits of protocol version number. The + current BGP version number is 1. If a bad version number is + found, a notification message with opcode 8 (bad version number) + should be sent and the BGP connection closed. The bad version + number should be included in one byte of notification data. + + Type: 8 bits + + The Type field is 8 bits of message type code. The following type + codes are defined: + + + + + + + +Lougheed & Rekhter [Page 3] + +RFC 1105 BGP June 1989 + + + 1 - OPEN + 2 - UPDATE + 3 - NOTIFICATION + 4 - KEEPALIVE + 5 - OPEN CONFIRM + + If an unrecognized type value is found, a notification message + with opcode 7 (bad type code) and data consisting of the byte of + type field in question should be sent and the BGP connection + closed. + + Hold Timer: 16 bits. + + This field contains the number of seconds that may elapse since + receiving a BGP KEEPALIVE or BGP UPDATE message from our BGP peer + before we declare an error and close the BGP connection. + +3.2 OPEN Message Format + + After a transport protocol connection is established, the first + message sent by either side is an OPEN message. If the OPEN message + is acceptable, an OPEN CONFIRM message confirming the OPEN is sent + back. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and + NOTIFICATION messages may be exchanged. + + In addition to the fixed size BGP header, the OPEN message contains + the following fields. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | My Autonomous System | Link Type | Auth. Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Authentication Data | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + My Autonomous System: 16 bits + + This field is our 16 bit autonomous system number. If there is a + problem with this field, a notification message with opcode 9 + (invalid AS field) should be sent and the BGP connection closed. + No notification data is sent. + + Link Type: 8 bits + + The Link Type field is a single octet containing one of the + + + +Lougheed & Rekhter [Page 4] + +RFC 1105 BGP June 1989 + + + following codes defining our position in the AS graph relative to + our peer. + + 0 - INTERNAL + 1 - UP + 2 - DOWN + 3 - H-LINK + + UP indicates the peer is higher in the AS hierarchy, DOWN + indicates lower, and H-LINK indicates at the same level. INTERNAL + indicates that the peer is another BGP speaking host in our + autonomous system. INTERNAL links are used to keep AS routing + information consistent with an AS with multiple border gateways. + If the Link Type field is unacceptable, a notification message + with opcode 1 (link type error in open) and data consisting of the + expected link type should be sent and the BGP connection closed. + The acceptable values for the Link Type fields of two BGP peers + are discussed below. + + Authentication Code: 8 bits + + The Authentication Code field is an octet whose value describes + the authentication mechanism being used. A value of zero + indicates no BGP authentication. Note that a separate + authentication mechanism may be used in establishing the transport + level connection. If the authentication code is not recognized, a + notification message with opcode 2 (unknown authentication code) + and no data is sent and the BGP connection is closed. + + Authentication Data: variable length + + The Authentication Data field is a variable length field + containing authentication data. If the value of Authentication + Code field is zero, the Authentication Data field has zero length. + If authentication fails, a notification message with opcode 3 + (authentication failure) and no data is sent and the BGP + connection is closed. + +3.3 OPEN CONFIRM Message Format + + An OPEN CONFIRM message is sent after receiving an OPEN message. + This completes the BGP connection setup. UPDATE, NOTIFICATION, and + KEEPALIVE messages may now be exchanged. + + An OPEN CONFIRM message consists of a BGP header with an OPEN CONFIRM + type code. There is no data in an OPEN CONFIRM message. + + + + + +Lougheed & Rekhter [Page 5] + +RFC 1105 BGP June 1989 + + +3.4 UPDATE Message Format + + UPDATE messages are used to transfer routing information between BGP + peers. The information in the UPDATE packet can be used to construct + a graph describing the relationships of the various autonomous + systems. By applying rules to be discussed, routing information + loops and some other anomalies may be detected and removed from the + inter-AS routing. + + Whenever an error in a UPDATE message is detected, a notification + message is sent with opcode 4 (bad update), a two byte subcode + describing the nature of the problem, and a data field consisting of + as much of the UPDATE message data portion as possible. UPDATE + messages have the following format: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Gateway | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AS count | Direction | AS Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | repeat (Direction, AS Number) pairs AS count times | + / / + / / + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Net Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Metric | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | repeat (Network, Metric) pairs Net Count times | + / / + / / + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Gateway: 32 bits. + + The Gateway field is the address of a gateway that has routes to + the Internet networks listed in the rest of the UPDATE message. + This gateway MUST belong to the same AS as the BGP peer who + advertises it. If there is a problem with the gateway field, a + notification message with subcode 6 (invalid gateway field) is + sent. + + + + +Lougheed & Rekhter [Page 6] + +RFC 1105 BGP June 1989 + + + AS count: 8 bits. + + This field is the count of Direction and AS Number pairs in this + UPDATE message. If an incorrect AS count field is detected, + subcode 1 (invalid AS count) is specified in the notification + message. + + Direction: 8 bits + + The Direction field is an octet containing the direction taken by + the routing information when exiting the AS defined by the + succeeding AS Number field. The following values are defined. + + 1 - UP (went up a link in the graph) + 2 - DOWN (went down a link in the graph) + 3 - H_LINK (horizontal link in the graph) + 4 - EGP_LINK (EGP derived information) + 5 - INCOMPLETE (incomplete information) + + There is a special provision to pass exterior learned (non-BGP) + routes over BGP. If an EGP learned route is passed over BGP, then + the Direction field is set to EGP-LINK and the AS Number field is + set to the AS number of the EGP peer that advertised this route. + All other exterior-learned routes (non-BGP and non-EGP) may be + passed by setting AS Number field to zero and Direction field to + INCOMPLETE. If the direction code is not recognized, a + notification message with subcode 2 (invalid direction code) is + sent. + + AS Number: 16 bits + + This field is the AS number that transmitted the routing + information. If there is a problem with this AS number, a + notification message with subcode 3 (invalid autonomous system) is + sent. + + Net Count: 16 bits. + + The Net Count field is the number of Metric and Network field + pairs which follow this field. If there is a problem with this + field, a notification with subcode 7 (invalid net count field) is + sent. + + Network: 32 bits + + The Network field is four bytes of Internet network number. If + there is a problem with the network field, a notification message + with subcode 8 (invalid network field) is sent. + + + +Lougheed & Rekhter [Page 7] + +RFC 1105 BGP June 1989 + + + Metric: 16 bits + + The Metric field is 16 bits of an unspecified metric. BGP metrics + are comparable ONLY if routes have exactly the same AS path. A + metric of all ones indicates the network is unreachable. In all + other cases the metric field is MEANINGLESS and MUST BE IGNORED. + There are no illegal metric values. + +3.5 NOTIFICATION Message Format + + NOTIFICATION messages are sent when an error condition is detected. + The BGP connection is closed shortly after sending the notification + message. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Opcode | Data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Opcode: 16 bits + + The Opcode field describes the type of NOTIFICATION. The + following opcodes have been defined. + + 1 (*) - link type error in open. Data is one byte of proper + link type. + 2 (*) - unknown authentication code. No data. + 3 (*) - authentication failure. No data. + 4 - update error. See below for data description. + 5 (*) - connection out of sync. No data. + 6 (*) - invalid message length. Data is two bytes of + bad length. + 7 (*) - invalid message type. Data is one byte of bad + message type. + 8 (*) - invalid version number. Data is one byte of + bad version. + 9 (*) - invalid AS field in OPEN. No data. + 10 (*) - BGP Cease. No data. + + The starred opcodes in the list above are considered fatal errors + and cause transport connection termination. + + The update error (opcode 4) has as data 16 bits of subcode + followed by the last UPDATE message in question. After the + subcode comes as much of the data portion of the UPDATE in + + + +Lougheed & Rekhter [Page 8] + +RFC 1105 BGP June 1989 + + + question as possible. The following subcodes are defined: + + 1 - invalid AS count + 2 - invalid direction code + 3 - invalid autonomous system + 4 - EGP_LINK or INCOMPLETE_LINK link type at other than + the end of the AS path list + 5 - routing loop + 6 - invalid gateway field + 7 - invalid Net Count field + 8 - invalid network field + + Data: variable + + The Data field contains zero or more bytes of data to be used in + diagnosing the reason for the NOTIFICATION. The contents of the + Data field depend upon the opcode. See the opcode descriptions + above for more details. + +3.6 KEEPALIVE Message Format + + BGP does not use any transport protocol based keepalive mechanism to + determine if peers are reachable. Instead KEEPALIVE messages are + exchanged between peers often enough as not to cause the hold time + (as advertised in the BGP header) to expire. A reasonable minimum + frequency of KEEPALIVE exchange would be one third of the Hold Time + interval. + + As soon as the Hold Time associated with BGP peer has expired, the + BGP connection is closed and BGP deallocates all resources associated + with this peer. + + The KEEPALIVE message is a BGP header without any data. + +4. BGP Finite State machine. + + This section specifies BGP operation in terms of a Finite State + Machine (FSM). Following is a brief summary and overview of BGP + operations by state as determined by this FSM. A condensed version + of the BGP FSM is found in Appendix 1. + + Initially BGP is in the BGP_Idle state. + + BGP_Idle state: + + In this state BGP refuses all incoming BGP connections. No + resources are allocated to the BGP neighbor. In response to the + Start event (initiated by either system or operator) the local + + + +Lougheed & Rekhter [Page 9] + +RFC 1105 BGP June 1989 + + + system initializes all BGP resources and changes its state to + BGP_Active. + + BGP_Active state: + + In this state BGP is trying to acquire a BGP neighbor by opening a + transport protocol connection. If the transport protocol open + fails (for example, retransmission timeout), BGP stays in the + BGP_Active state. + + Otherwise, the local system sends an OPEN message to its peer, + and changes its state to BGP_OpenSent. Since the hold time of the + peer is still undetermined, the hold time is initialized to some + large value. + + In response to the Stop event (initiated by either system or + operator) the local system releases all BGP resources and changes + its state to BGP_Idle. + + BGP_OpenSent state: + + In this state BGP waits for an OPEN message from its peer. When + an OPEN message is received, all fields are checked for + correctness. If the initial BGP header checking detects an error, + BGP deallocates all resources associated with this peer and + returns to the BGP_Active state. Otherwise, the Link Type, + Authentication Code, and Authentication Data fields are checked + for correctness. + + If the link type is incorrect, a NOTIFICATION message with opcode + 1 (link type error in open) is sent. The following combination of + link type fields are correct; all other combinations are invalid. + + Our view Peer view + UP DOWN + DOWN UP + INTERNAL INTERNAL + H-LINK H-LINK + + If the link between two peers is INTERNAL, then AS number of both + peers must be the same. Otherwise, a NOTIFICATION message with + opcode 1 (link type error in open) is sent. + + If both peers have the same AS number and the link type between + these peers is not INTERNAL, then a NOTIFICATION message with + opcode 1 (link type error in open) is sent. + + If the value of the Authentication Code field is zero, any + + + +Lougheed & Rekhter [Page 10] + +RFC 1105 BGP June 1989 + + + information in the Authentication Data field (if present) is + ignored. If the Authentication Code field is non-zero it is + checked for known authentication codes. If authentication code is + unknown, then the BGP NOTIFICATION message with opcode 2 (unknown + authentication code) is sent. + + If the Authentication Code value is non-zero, then the + corresponding authentication procedure is invoked. The default + values are a zero Authentication Code and no Authentication Data. + + If any of the above tests detect an error, the local system closes + the BGP connection and changes its state to BGP_Idle. + + If there are no errors in the BGP OPEN message, BGP sends an OPEN + CONFIRM message and goes into the BGP_OpenConfirm state. At this + point the hold timer which was originally set to some arbitrary + large value (see above) is replaced with the value indicated in + the OPEN message. + + If disconnect notification is received from the underlying + transport protocol or if the hold time expires, the local system + closes the BGP connection and changes its state to BGP_Idle. + + BGP_OpenConfirm state: + + In this state BGP waits for an OPEN CONFIRM message. As soon as + this message is received, BGP changes its state to + BGP_Established. If the hold timer expires before an OPEN CONFIRM + message is received, the local system closes the BGP connection + and changes its state to BGP_Idle. + + BGP_Established state: + + In the BGP_Established state BGP can exchange UPDATE, + NOTIFICATION, and KEEPALIVE messages with its peer. + + If disconnect notification is received from the underlying + transport protocol or if the hold time expires, the local system + closes the BGP connection and changes its state to BGP_Idle. + + In response to the Stop event initiated by either the system or + operator, the local system sends a NOTIFICATION message with + opcode 10 (BGP Cease), closes the BGP connection, and changes its + state to BGP_Idle. + + + + + + + +Lougheed & Rekhter [Page 11] + +RFC 1105 BGP June 1989 + + +5. UPDATE Message Handling + + A BGP UPDATE message may be received only in the BGP_Established + state. When a BGP UPDATE message is received, each field is checked + for validity. When a NOTIFICATION message is sent regarding an + UPDATE, the opcode is always 4 (update error), the subcode depends on + the type of error, and the rest of the data field is as much as + possible of the data portion of the UPDATE that caused the error. + + If the Gateway field is incorrect, a BGP NOTIFICATION message is sent + with subcode 6 (invalid gateway field). All information in this + UPDATE message is discarded. + + If the AS Count field is less than or equal to zero, a BGP + NOTIFICATION is sent with subcode 1 (invalid AS count). Otherwise, + the complete AS path is extracted and checked as described below. + + If one of the Direction fields in the AS route list is not defined, a + BGP NOTIFICATION message is with subcode 2 (invalid direction code). + + If one of the AS Number fields in the AS route list is incorrect, a + BGP NOTIFICATION message is sent with subcode 3 (invalid autonomous + system). + + If either a EGP_LINK or a INCOMPLETE_LINK link type occurs at other + than the end of the AS path, a BGP NOTIFICATION message is sent with + subcode 4 (EGP_LINK or INCOMPLETE_LINK link type at other than the + end of the AS path list). + + If none of the above tests failed, the full AS route is checked for + AS loops. + + AS loop detection is done by scanning the full AS route and checking + that each AS in this route occurs only once. If an AS loop is + detected, a BGP NOTIFICATION message is sent with subcode 5 (routing + loop). + + If any of the above errors are detected, no further processing is + done. Otherwise, the complete AS path is correct and the rest of the + UPDATE message is processed. + + If the Net Count field is incorrect, a BGP NOTIFICATION message is + sent with subcode 7 (invalid Net Count field). + + Each network and metric pair listed in the BGP UPDATE message is + checked for a valid network number. If the Network field is + incorrect, a BGP Notification message is sent with subcode 8 (invalid + network field). No checking is done on the metric field. It is up + + + +Lougheed & Rekhter [Page 12] + +RFC 1105 BGP June 1989 + + + to a particular implementation to decide whether to continue + processing or terminate it upon the first incorrect network. + + If the network, its complete AS path, and the gateway are correct, + then the route is compared with other routes to the same network. If + the new route is better than the current one, then it is flooded to + other BGP peers as follows: + + - If the BGP UPDATE was received over the INTERNAL link, it is not + propagated over any other INTERNAL link. This restriction is + due to the fact that all BGP gateways within a single AS + form a completely connected graph (see above). + + - Before sending a BGP UPDATE message over the non-INTERNAL links, + check the AS path to insure that doing so would not cause a + routing loop. The BGP UPDATE message is then propagated (subject + to the local policy restrictions) over any of the non-INTERNAL + link of a routing loop would not result. + + - If the BGP UPDATE message is propagated over a non-INTERNAL link, + then the current AS number and link type of the link over which + it is going to be propagated is prepended to the full AS path + and the AS count field is incremented by 1. If the BGP UPDATE + message is propagated over an INTERNAL link, then the full AS + path passed unmodified and the AS count stays the same. The + Gateway field is replaced with the sender's own address. + +6. Acknowledgements + + We would like to express our thanks to Len Bosack (cisco Systems), + Jeff Honig (Cornell University) and all members of the IWG task force + for their contributions to this document. + + + + + + + + + + + + + + + + + + + +Lougheed & Rekhter [Page 13] + +RFC 1105 BGP June 1989 + + + Appendix 1 + +BGP FSM State Transitions and Actions. + + This Appendix discusses the transitions between states in the BGP FSM + in response to BGP events. The following is the list of these states + and events. + + BGP States: + + 1 - BGP_Idle + 2 - BGP_Active + 3 - BGP_OpenSent + 4 - BGP_OpenConfirm + 5 - BGP_Established + + BGP Events: + + 1 - BGP Start + 2 - BGP Transport connection open + 3 - BGP Transport connection closed + 4 - BGP Transport connection open failed + 5 - Receive OPEN message + 6 - Receive OPEN CONFIRM message + 7 - Receive KEEPALIVE message + 8 - Receive UPDATE messages + 9 - Receive NOTIFICATION message + 10 - Holdtime timer expired + 11 - KeepAlive timer expired + 12 - Receive CEASE message + 13 - BGP Stop + + The following table describes the state transitions of the BGP FSM + and the actions triggered by these transitions. + + + + + + + + + + + + + + + + + +Lougheed & Rekhter [Page 14] + +RFC 1105 BGP June 1989 + + + Event Actions Message Sent Next State + -------------------------------------------------------------------- + BGP_Idle (1) + 1 Initialize resources none 2 + BGP_Active (2) + 2 Initialize resources OPEN 3 + 4 none none 2 + 13 Release resources none 1 + + BGP_OpenSent(3) + 3 none none 1 + 5 Process OPEN is OK OPEN CONFIRM 4 + Process OPEN Message failed NOTIFICATION 1 + 11 Restart KeepAlive timer KEEPALIVE 3 + 13 Release resources none 1 + + BGP_OpenConfirm (4) + 6 Complete initialization none 5 + 3 none none 1 + 10 Close transport connection none 1 + 11 Restart KeepAlive timer KEEPALIVE 4 + 13 Release resources none 1 + + BGP_Established (5) + 7 Process KEEPALIVE none 5 + 8 Process UPDATE is OK UPDATE 5 + Process UPDATE failed NOTIFICATION 5 + 9 Process NOTIFICATION none 5 + 10 Close transport connection none 1 + 11 Restart KeepAlive timer KEEPALIVE 5 + 12 Close transport connection NOTIFICATION 1 + 13 Release resources none 1 + -------------------------------------------------------------------- + + All other state-event combinations are considered fatal errors and + cause the termination of the BGP transport connection (if necessary) + and a transition to the BGP_Idle state. + + + + + + + + + + + + + + +Lougheed & Rekhter [Page 15] + +RFC 1105 BGP June 1989 + + + The following is a condensed version of the above state transition + table. + + Events|BGP_Idle BGP_Active BGP_OpenSent BGP_OpenConfirm BGP_Estab + | (1) | (2) | (3) | (4) | (5) + |------------------------------------------------------------- + 1 | 2 | | | | + | | | | | + 2 | | 3 | | | + | | | | | + 3 | | | 1 | 1 | + | | | | | + 4 | | 2 | | | + | | | | | + 5 | | | 4 or 1 | | + | | | | | + 6 | | | | 5 | + | | | | | + 7 | | | | | 5 + | | | | | + 8 | | | | | 5 + | | | | | + 9 | | | | | 5 + | | | | | + 10 | | | | 1 | 1 + | | | | | + 11 | | | 3 | 4 | 5 + | | | | | + 12 | | | | | 1 + | | | | | + 13 | | 1 | 1 | 1 | 1 + | | | | | + -------------------------------------------------------------- + + + + + + + + + + + + + + + + + + +Lougheed & Rekhter [Page 16] + +RFC 1105 BGP June 1989 + + +References + + [1] Mills, D., "Exterior Gateway Protocol Formal Specification", RFC + 904, BBN, April 1984. + + [2] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET + Backbone", RFC 1092, T. J. Watson Research Center, February 1989. + + [3] Braun, H-W., "The NSFNET Routing Architecture", RFC 1093, + MERIT/NSFNET Project, February 1989. + + [4] Postel, J., "Transmission Control Protocol - DARPA Internet + Program Protocol Specification", RFC 793, DARPA, September 1981. + + [5] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC + 1045, Stanford University, February 1988. + +Authors' Addresses + + Kirk Lougheed + cisco Systems, Inc. + 1360 Willow Road, Suite 201 + Menlo Park, CA 94025 + + Phone: (415) 326-1941 + + Email: LOUGHEED@MATHOM.CISCO.COM + + + Jacob Rekhter + T.J. Watson Research Center + IBM Corporation + P.O. Box 218 + Yorktown Heights, NY 10598 + + Phone: (914) 945-3896 + + Email: YAKOV@IBM.COM + + + + + + + + + + + + + +Lougheed & Rekhter [Page 17] + \ No newline at end of file -- cgit v1.2.3