idnits 2.17.1 draft-ietf-grow-bmp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2012) is 4203 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Scudder 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track R. Fernando 5 Expires: April 25, 2013 Cisco Systems 6 S. Stuart 7 Google 8 October 22, 2012 10 BGP Monitoring Protocol 11 draft-ietf-grow-bmp-07 13 Abstract 15 This document defines a protocol, BMP, which can be used to monitor 16 BGP sessions. BMP is intended to provide a more convenient interface 17 for obtaining route views for research purpose than the screen- 18 scraping approach in common use today. The design goals are to keep 19 BMP simple, useful, easily implemented, and minimally service- 20 affecting. BMP is not suitable for use as a routing protocol. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 25, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 70 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Overview of BMP Operation . . . . . . . . . . . . . . . . . . 4 72 3.1. BMP Messages . . . . . . . . . . . . . . . . . . . . . . . 4 73 3.2. Connection Establishment and Termination . . . . . . . . . 5 74 3.3. Lifecycle of a BMP Session . . . . . . . . . . . . . . . . 6 75 4. BMP Message Format . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 7 77 4.2. Per-Peer Header . . . . . . . . . . . . . . . . . . . . . 7 78 4.3. Initiation Message . . . . . . . . . . . . . . . . . . . . 9 79 4.4. Termination Message . . . . . . . . . . . . . . . . . . . 10 80 4.5. Route Monitoring . . . . . . . . . . . . . . . . . . . . . 11 81 4.6. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 11 82 4.7. Peer Down Notification . . . . . . . . . . . . . . . . . . 13 83 4.8. Peer Up Notification . . . . . . . . . . . . . . . . . . . 14 84 5. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . . 15 85 6. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 7. Other Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 8. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 89 9.1. BMP Message Types . . . . . . . . . . . . . . . . . . . . 18 90 9.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . . 18 91 9.3. BMP Initiation Message TLVs . . . . . . . . . . . . . . . 18 92 9.4. BMP Termination Message TLVs . . . . . . . . . . . . . . . 19 93 9.5. BMP Termination Message Reason Codes . . . . . . . . . . . 19 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 95 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 98 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 99 Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 21 100 Appendix B. Changes Between BMP Versions 2 and 3 . . . . . . . . 21 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 103 1. Introduction 105 Many researchers wish to have access to the contents of routers' BGP 106 RIBs as well as a view of protocol updates that the router is 107 receiving. This monitoring task cannot be realized by standard 108 protocol mechanisms. Prior to introduction of BMP, this data could 109 only be obtained through screen-scraping. 111 The BMP protocol provides access to the Adj-RIB-In of a peer on an 112 ongoing basis and a periodic dump of certain statistics that the 113 monitoring station can use for further analysis. From a high level, 114 BMP can be thought of as the result of multiplexing together the 115 messages received on the various monitored BGP sessions. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 2. Definitions 125 o Adj-RIB-In: As defined in [RFC4271], "The Adj-RIBs-In contains 126 unprocessed routing information that has been advertised to the 127 local BGP speaker by its peers." This is also referred to as the 128 pre-policy Adj-RIB-In in this document. 130 o Post-Policy Adj-RIB-In: The result of applying inbound policy to 131 an Adj-RIB-In, but prior to the application of route selection to 132 form the Loc-RIB. 134 3. Overview of BMP Operation 136 3.1. BMP Messages 138 The following are the messages provided by BMP. 140 o Route Monitoring (RM): An initial dump of all routes received from 141 a peer as well as an ongoing mechanism that sends the incremental 142 routes advertised and withdrawn by a peer to the monitoring 143 station. 145 o Peer Down Notification (PD): A message sent to indicate that a 146 peering session has gone down with information indicating the 147 reason for the session disconnect. 149 o Stats Reports (SR): An ongoing dump of statistics that can be used 150 by the monitoring station as a high level indication of the 151 activity going on in the router. 153 o Peer Up Notification (PU): A message sent to indicate that a 154 peering session has come up. The message includes information 155 regarding the data exchanged between the peers in their OPEN 156 messages as well as information about the peering TCP session 157 itself. In addition to being sent whenever a peer transitions to 158 ESTABLISHED state, a Peer Up Notification is sent for each peer 159 that is in ESTABLISHED state when the BMP session itself comes up. 161 o Initiation: A means for the monitored router to inform the 162 monitoring station of its vendor, software version, and so on. 164 o Termination: A means for the monitored router to inform the 165 monitoring station of why it is closing a BMP session. 167 3.2. Connection Establishment and Termination 169 BMP operates over TCP. All options are controlled by configuration 170 on the monitored router. No message is ever sent from the monitoring 171 station to the monitored router. The monitored router MAY take steps 172 to prevent the monitoring station from sending data (for example by 173 half-closing the TCP session or setting its window size to zero) or 174 it MAY silently discard any data sent by the monitoring station. 176 The router may be monitored by one or more monitoring stations. With 177 respect to each (router, monitoring station) pair, one party is 178 active with respect to TCP session establishment, and the other party 179 is passive. Which party is active and which is passive is controlled 180 by configuration. 182 The passive party is configured to listen on a particular TCP port 183 and the active party is configured to establish a connection to that 184 port. If the active party is unable to connect to the passive party, 185 it periodically retries the connection. Retries MUST be subject to 186 some variety of backoff. Exponential backoff with a default initial 187 backoff of 30 seconds and a maximum of 720 seconds is suggested. 189 The router MAY restrict the set of IP addresses from which it will 190 accept connections. It SHOULD restrict the number of simultaneous 191 connections it will permit from a given IP address. The default 192 value for this restriction SHOULD be 1, though an implementation MAY 193 permit this restriction to be disabled in configuration. The router 194 MUST also restrict the rate at which sessions may be established. A 195 suggested default is an establishment rate of 2 sessions per minute. 197 A router (or management station) MAY implement logic to detect 198 redundant connections, as might occur if both parties are configured 199 to be active, and MAY elect to terminate redundant connections. A 200 Termination reason code is defined for this purpose. 202 Once a connection is established, the router sends messages over it. 203 There is no initialization or handshaking phase, messages are simply 204 sent as soon as the connection is established. 206 If the monitoring station intends to restart BMP processing, it 207 simply drops the connection, optionally with a Termination message. 209 3.3. Lifecycle of a BMP Session 211 A router is configured to speak BMP with one more monitoring 212 stations. It MAY be configured to send monitoring information for 213 only a subset of its BGP peers. Otherwise, all BGP peers are assumed 214 to be monitored. 216 A BMP session begins when the active party (either router or 217 management station, as determined by configuration) successfully 218 opens a TCP session (the "BMP session"). Once the session is up, the 219 router begins to send BMP messages. It MUST begin by sending an 220 Initiation message. It subsequently sends a Peer Up message over the 221 BMP session for each of its monitored BGP peers which are in 222 Established state. It follows by sending the contents of its Adj- 223 RIBs-In (pre-policy, post-policy or both, see Section 5) encapsulated 224 in Route Monitoring messages. Once it has sent all the routes for a 225 given peer, it sends an End-of-RIB message for that peer; when End- 226 of-RIB has been sent for each monitored peer, the initial table dump 227 has completed. (A monitoring station that wishes only to gather a 228 table dump could close the connection once it has gathered an End-of- 229 RIB or Peer Down message corresponding to each Peer Up message.) 231 Following the initial table dump, the router sends incremental 232 updates encapsulated in Route Monitoring messages. It MAY 233 periodically send Stats Reports or even new Initiation messages, 234 according to configuration. If any new monitored BGP peers become 235 Established, corresponding Peer Up messages are sent. If any BGP 236 peers for which Peer Up messages were sent transition out of the 237 Established state, corresponding Peer Down messages are sent. 239 A BMP session ends when the TCP session that carries it is closed for 240 any reason. The router MAY send a Termination message prior to 241 closing the session. 243 4. BMP Message Format 245 4.1. Common Header 247 The following common header appears in all BMP messages. The rest of 248 the data in a BMP message is dependent on the "Message Type" field in 249 the common header. 251 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 252 +-+-+-+-+-+-+-+-+ 253 | Version | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Message Length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Msg. Type | 258 +---------------+ 260 o Version (1 byte): Indicates the BMP version. This is set to '3' 261 for all messages defined in this specification. Version 0 is 262 reserved and MUST NOT be sent. 264 o Message Length (4 bytes): Length of the message in bytes 265 (including headers, data and encapsulated messages, if any). 267 o Message Type (1 byte): This identifies the type of the BMP 268 message. A BMP implementation MUST ignore unrecognized message 269 types upon receipt. 271 * Type = 0: Route Monitoring 272 * Type = 1: Statistics Report 273 * Type = 2: Peer Down Notification 274 * Type = 3: Peer Up Notification 275 * Type = 4: Initiation Message 276 * Type = 5: Termination Message 278 4.2. Per-Peer Header 280 The per-peer header follows the common header for most BMP messages. 281 The rest of the data in a BMP message is dependent on the "Message 282 Type" field in the common header. 284 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Peer Type | Peer Flags | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Peer Distinguisher (present based on peer type) | 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Peer Address (16 bytes) | 292 ~ ~ 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Peer AS | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Peer BGP ID | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Timestamp (seconds) | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Timestamp (microseconds) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 o Peer Type (1 byte): These bits identify the type of the peer. 304 Currently only two types of peers are identified, 306 * Peer Type = 0: Global Instance Peer 307 * Peer Type = 1: L3 VPN Instance Peer 309 o Peer Flags (1 byte): These flags provide more information about 310 the peer. The flags are defined as follows. 312 0 1 2 3 4 5 6 7 8 313 +-+-+-+-+-+-+-+-+ 314 |V|L| Reserved | 315 +-+-+-+-+-+-+-+-+ 317 * The V flag indicates the the Peer address is an IPv6 address. 318 For IPv4 peers this is set to 0. 319 * The L flag, if set to 1, indicates that the message reflects 320 the post-policy Adj-RIB-In (i.e., it reflects the application 321 of inbound policy). It is set to 0 if the message reflects the 322 pre-policy Adj-RIB-In. See Section 5 for further detail. 323 * The remaining bits are reserved for future use. 325 o Peer Distinguisher (8 bytes): Routers today can have multiple 326 instances (example L3VPNs). This field is present to distinguish 327 peers that belong to one address domain from the other. 329 If the peer is a "Global Instance Peer", this field is zero 330 filled. If the peer is a "L3VPN Instance Peer", it is set to the 331 route distinguisher of the particular L3VPN instance that the peer 332 belongs to. 334 o Peer Address: The remote IP address associated with the TCP 335 session over which the encapsulated PDU was received. It is 4 336 bytes long if an IPv4 address is carried in this field (with most 337 significant bytes zero filled) and 16 bytes long if an IPv6 338 address is carried in this field. 340 o Peer AS: The Autonomous System number of the peer from which the 341 encapsulated PDU was received. If a 16 bit AS number is stored in 342 this field [RFC4893], it should be padded with zeroes in the most 343 significant bits. 345 o Peer BGP ID: The BGP Identifier of the peer from which the 346 encapsulated PDU was received. 348 o Timestamp: The time when the encapsulated routes were received 349 (one may also think of this as the time when they were installed 350 in the Adj-RIB-In), expressed in seconds and microseconds since 351 midnight (zero hour), January 1, 1970 (UTC). If zero, the time is 352 unavailable. Precision of the timestamp is implementation- 353 dependent. 355 4.3. Initiation Message 357 The initiation message provides a means for the monitored router to 358 inform the monitoring station of its vendor, software version, and so 359 on. An initiation message MUST be sent as the first message after 360 the TCP session comes up. An initiation message MAY be sent at any 361 point thereafter, if warranted by a change on the monitored router. 363 The initiation message consists of the common BMP header followed by 364 two or more TLVs containing information about the monitored router, 365 as follows: 367 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Information Type | Information Length | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Information (variable) | 372 ~ ~ 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 o Information Type (2 bytes): Type of information provided. Defined 376 types are: 378 * Type = 0: String. The Information field contains a free-form 379 UTF-8 string whose length is given by the "Information Length" 380 field. The value is administratively assigned. Inclusion of 381 this TLV is optional. Multiple String TLVs MAY be included in 382 the message. 384 * Type = 1: sysDescr. The Information field contains an ASCII 385 string whose value MUST be set to be equal to the value of the 386 sysDescr MIB-II [RFC1213] object. Inclusion of this TLV is 387 mandatory. 389 * Type = 2: sysName. The Information field contains a ASCII 390 string whose value MUST be set to be equal to the value of the 391 sysName MIB-II [RFC1213] object. Inclusion of this TLV is 392 mandatory. 394 o Information Length (2 bytes): The length of the following 395 Information field, in bytes. 397 o Information (variable): Information about the monitored router, 398 according to the type. 400 4.4. Termination Message 402 The termination message provides a way for a monitored router to 403 indicate why it is terminating a session. Although use of this 404 message is RECOMMENDED, a monitoring station must always be prepared 405 for the session to terminate with no message. Once the router has 406 sent a termination message, it MUST close the TCP session without 407 sending any further messages. Likewise, the monitoring station MUST 408 close the TCP session after receiving a termination message. 410 The termination message consists of the common BMP header followed by 411 one or more TLVs containing information about the reason for the 412 termination, as follows: 414 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Information Type | Information Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Information (variable) | 419 ~ ~ 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 o Information Type (2 bytes): Type of information provided. Defined 423 types are: 425 * Type = 0: String. The Information field contains a free-form 426 UTF-8 string whose length is given by the "Information Length" 427 field. Inclusion of this TLV is optional. It MAY be used to 428 provide further detail for any of the defined reasons. 429 Multiple String TLVs MAY be included in the message. 431 * Type = 1: Reason. The Information field contains a two-byte 432 code indicating the reason the connection was terminated. Some 433 reasons may have further TLVs associated with them. Inclusion 434 of this TLV is not optional. Defined reasons are: 436 + Reason = 0: Session administratively closed. 438 + Reason = 1: Unspecified reason. 440 + Reason = 2: Out of resources. The router has exhausted 441 resources available for the BMP session. 443 + Reason = 3: Redundant connection. The router has determined 444 that this connection is redundant with another one. 446 o Information Length (2 bytes): The length of the following 447 Information field, in bytes. 449 o Information (variable): Information about the monitored router, 450 according to the type. 452 4.5. Route Monitoring 454 Route Monitoring messages are used for initial synchronization of 455 ADJ-RIBs-In. They are also used for ongoing monitoring of received 456 advertisements and withdraws. This is discussed in more detail in 457 Section 5. 459 Following the common BMP header and per-peer header is a BGP Update 460 PDU. 462 4.6. Stats Reports 464 These messages contain information that could be used by the 465 monitoring station to observe interesting events that occur on the 466 router. 468 Transmission of SR messages could be timer triggered or event driven 469 (for example, when a significant event occurs or a threshold is 470 reached). This specification does not impose any timing restrictions 471 on when and on what event these reports have to be transmitted. It 472 is left to the implementation to determine transmission timings -- 473 however, configuration control should be provided of the timer and/or 474 threshold values. This document only specifies the form and content 475 of SR messages. 477 Following the common BMP header and per-peer header is a 4-byte field 478 that indicates the number of counters in the stats message where each 479 counter is encoded as a TLV. 481 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Stats Count | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Each counter is encoded as follows, 488 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Stat Type | Stat Len | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Stat Data | 493 ~ ~ 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 o Stat Type (2 bytes): Defines the type of the statistic carried in 497 the "Stat Data" field. 499 o Stat Len (2 bytes): Defines the length of the "Stat Data" Field. 501 This specification defines the following statistics. A BMP 502 implementation MUST ignore unrecognized stat types on receipt, and 503 likewise MUST ignore unexpected data in the Stat Data field. 505 Stats are either counters or gauges, defined as follows after the 506 examples of [RFC1155] Section 3.2.3.3 and [RFC2856] Section 4 507 respectively: 509 32-bit Counter: A non-negative integer which monotonically increases 510 until it reaches a maximum value, when it wraps around and starts 511 increasing again from zero. It has a maximum value of 2^32-1 512 (4294967295 decimal). 514 64-bit Gauge: non-negative integer, which may increase or decrease, 515 but shall never exceed a maximum value, nor fall below a minimum 516 value. The maximum value can not be greater than 2^64-1 517 (18446744073709551615 decimal), and the minimum value can not be 518 smaller than 0. The value has its maximum value whenever the 519 information being modeled is greater than or equal to its maximum 520 value, and has its minimum value whenever the information being 521 modeled is smaller than or equal to its minimum value. If the 522 information being modeled subsequently decreases below (increases 523 above) the maximum (minimum) value, the 64-bit Gauge also decreases 524 (increases). 526 o Stat Type = 0: (32-bit Counter) Number of prefixes rejected by 527 inbound policy. 529 o Stat Type = 1: (32-bit Counter) Number of (known) duplicate prefix 530 advertisements. 532 o Stat Type = 2: (32-bit Counter) Number of (known) duplicate 533 withdraws. 535 o Stat Type = 3: (32-bit Counter) Number of updates invalidated due 536 to CLUSTER_LIST loop. 538 o Stat Type = 4: (32-bit Counter) Number of updates invalidated due 539 to AS_PATH loop. 541 o Stat Type = 5: (32-bit Counter) Number of updates invalidated due 542 to ORIGINATOR_ID. 544 o Stat Type = 6: (32-bit Counter) Number of updates invalidated due 545 to AS_CONFED loop. 547 o Stat Type = 7: (64-bit Gauge) Number of routes in Adj-RIBs-In. 549 o Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB. 551 Note that although the current specification only specifies 4-byte 552 counters and 8-byte gauges as "Stat Data", this does not preclude 553 future versions from incorporating more complex TLV-type "Stat Data" 554 (for example, one which can carry prefix specific data). SR messages 555 are optional. However if an SR message is transmitted, at least one 556 statistic MUST be carried in it. 558 4.7. Peer Down Notification 560 This message is used to indicate that a peering session was 561 terminated. 563 0 1 2 3 4 5 6 7 8 564 +-+-+-+-+-+-+-+-+ 565 | Reason | 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Data (present if Reason = 1, 2 or 3) | 568 ~ ~ 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Reason indicates why the session was closed. Defined values are: 573 o Reason 1: The local system closed the session. Following the 574 Reason is a BGP PDU containing a BGP NOTIFICATION message that 575 would have been sent to the peer. 577 o Reason 2: The local system closed the session. No notification 578 message was sent. Following the reason code is a two-byte field 579 containing the code corresponding to the FSM Event which caused 580 the system to close the session (see Section 8.1 of [RFC4271]). 581 Two bytes both set to zero are used to indicate that no relevant 582 Event code is defined. 584 o Reason 3: The remote system closed the session with a notification 585 message. Following the Reason is a BGP PDU containing the BGP 586 NOTIFICATION message as received from the peer. 588 o Reason 4: The remote system closed the session without a 589 notification message. 591 A Peer Down message implicitly withdraws all routes that had been 592 associated with the peer in question. A BMP implementation MAY omit 593 sending explicit withdraws for such routes. 595 4.8. Peer Up Notification 597 The Peer Up message is used to indicate that a peering session has 598 come up (i.e., has transitioned into ESTABLISHED state). Following 599 the common BMP header and per-peer header is the following: 601 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Local Address (16 bytes) | 604 ~ ~ 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Local Port | Remote Port | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Sent OPEN Message | 609 ~ ~ 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Received OPEN Message | 612 ~ ~ 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 o Local Address: The local IP address associated with the peering 616 TCP session. It is 4 bytes long if an IPv4 address is carried in 617 this field, as determined by the V flag (with most significant 618 bytes zero filled) and 16 bytes long if an IPv6 address is carried 619 in this field. 621 o Local Port: The local port number associated with the peering TCP 622 session. 624 o Remote Port: The remote port number associated with the peering 625 TCP session. (Note that the remote address can be found in the 626 Peer Address field of the fixed header.) 628 o Sent OPEN Message: The full OPEN message transmitted by the 629 monitored router to its peer. 631 o Received OPEN Message: The full OPEN message received by the 632 monitored router from its peer. 634 5. Route Monitoring 636 After the BMP session is up, Route Monitoring messages are used to 637 provide a snapshot of the Adj-RIB-In of each monitored peer. This is 638 done by sending all routes stored in the Adj-RIB-In of those peers 639 using standard BGP Update messages, encapsulated in Route Monitoring 640 messages. There is no requirement on the ordering of messages in the 641 peer dumps. When the initial dump is completed for a given peer, 642 this MUST be indicated by sending an End-of-RIB marker for that peer 643 (as specified in Section 2 of [RFC4724], plus the BMP encapsulation 644 header). See also Section 8. 646 A BMP speaker may send pre-policy routes, post-policy routes, or 647 both. The selection may be due to implementation constraints (it is 648 possible that a BGP implementation may not store, for example, routes 649 which have been filtered out by policy). Pre-policy routes MUST have 650 their L flag clear in the BMP header (see Section 4), post-policy 651 routes MUST have their L flag set. When an implementation chooses to 652 send both pre- and post-policy routes, it is effectively multiplexing 653 two update streams onto the BMP session. The streams are 654 distinguished by their L flags. 656 If the implementation is able to provide information about when 657 routes were received, it MAY provide such information in the BMP 658 timestamp field. Otherwise, the BMP timestamp field MUST be set to 659 zero, indicating that time is not available. 661 AS Numbers in the BMP UPDATE message MUST be sent as 4-octet 662 quantities, as described in [RFC4893]. This affects the AS_PATH and 663 AGGREGATOR path attributes. AS4_PATH or AS4_AGGREGATOR path 664 attributes MUST NOT be sent in a BMP UPDATE message, as it makes no 665 sense to do so. 667 Ongoing monitoring is accomplished by propagating route changes in 668 BGP Update PDUs and forwarding those PDUs to the monitoring station, 669 again using RM messages. When a change occurs to a route, such as an 670 attribute change, the router must update the monitor with the new 671 attribute. As discussed above, it MAY generate either an update with 672 the L flag clear, with it set, or two updates, one with the L flag 673 clear and the other with the L flag set. When a route is withdrawn 674 by a peer, a corresponding withdraw is sent to the monitor. The 675 withdraw MUST have its L flag set to correspond to that of any 676 previous announcement; if the route in question was previously 677 announced with L flag both clear and set, the withdraw MUST similarly 678 be sent twice, with L flag clear and set. Multiple changed routes 679 MAY be grouped into a single BGP UPDATE PDU when feasible, exactly as 680 in the standard BGP protocol. 682 It's important to note that RM messages are not real time replicated 683 messages received from a peer. While the router should attempt to 684 generate updates as soon as they are received there is a finite time 685 that could elapse between reception of an update and the generation 686 an RM message and its transmission to the monitoring station. If 687 there are state changes in the interim for that prefix, it is 688 acceptable that the router generate the final state of that prefix to 689 the monitoring station. The actual PDU generated and transmitted to 690 the station might also differ from the exact PDU received from the 691 peer, for example due to differences between how different 692 implementations format path attributes. 694 6. Stat Reports 696 As outlined above, SR messages are used to monitor specific events 697 and counters on the monitored router. One type of monitoring could 698 be to find out if there are an undue number of route advertisements 699 and withdraws happening (churn) on the monitored router. Another 700 metric is to evaluate the number of looped AS-Paths on the router. 702 While this document proposes a small set of counters to begin with, 703 the authors envision this list may grow in the future with new 704 applications that require BMP style monitoring. 706 7. Other Considerations 708 Some routers may support multiple instances of the BGP protocol, for 709 example as "logical routers" or through some other facility. The BMP 710 protocol relates to a single instance of BGP; thus, if a router 711 supports multiple BGP instances it should also support multiple BMP 712 instances (one per BGP instance). 714 8. Using BMP 716 Once the BMP session is established route monitoring starts dumping 717 the current snapshot as well as incremental changes simultaneously. 719 It is fine to have these operations occur concurrently. If the 720 initial dump visits a route and subsequently a withdraw is received, 721 this will be forwarded to the monitoring station which would have to 722 correlate and reflect the deletion of that route in its internal 723 state. This is an operation a monitoring station would need to 724 support regardless. 726 If the router receives a withdraw for a prefix even before the peer 727 dump procedure visits that prefix, then the router would clean up 728 that route from its internal state and will not forward it to the 729 monitoring station. In this case, the monitoring station may receive 730 a bogus withdraw which it can safely ignore. 732 9. IANA Considerations 734 IANA is requested to create the following registries. 736 9.1. BMP Message Types 738 This document defines five message types for transferring BGP 739 messages between cooperating systems (Section 4): 741 o Type 0: Route Monitor 742 o Type 1: Statistics Report 743 o Type 2: Peer Down Notification 744 o Type 3: Peer Up Notification 745 o Type 4: Initiation 746 o Type 5: Termination 748 Type values 6 through 128 MUST be assigned using the "Standards 749 Action" policy, and values 129 through 255 using the "Specification 750 Required" policy defined in [RFC5226]. 752 9.2. BMP Statistics Types 754 This document defines nine statistics types for statistics reporting 755 (Section 4.6): 757 o Stat Type = 0: Number of prefixes rejected by inbound policy. 758 o Stat Type = 1: Number of (known) duplicate prefix advertisements. 759 o Stat Type = 2: Number of (known) duplicate withdraws. 760 o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST 761 loop. 762 o Stat Type = 4: Number of updates invalidated due to AS_PATH loop. 763 o Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID. 764 o Stat Type = 6: Number of updates invalidated due to a loop found 765 in AS_CONFED_SEQUENCE or AS_CONFED_SET. 766 o Stat Type = 7: Number of routes in Adj-RIBs-In. 767 o Stat Type = 8: Number of routes in Loc-RIB. 769 Stat Type values 9 through 32767 MUST be assigned using the 770 "Standards Action" policy, and values 32768 through 65535 using the 771 "Specification Required" policy, defined in [RFC5226]. 773 9.3. BMP Initiation Message TLVs 775 This document defines three types for information carried in the 776 Initiation message (Section 4.3): 778 o Type = 0: String. 779 o Type = 1: sysDescr. 780 o Type = 2: sysName. 782 Information type values 3 through 32767 MUST be assigned using the 783 "Standards Action" policy, and values 32768 through 65535 using the 784 "Specification Required" policy, defined in [RFC5226]. 786 9.4. BMP Termination Message TLVs 788 This document defines two types for information carried in the 789 Termination message (Section 4.4): 791 o Type = 0: String. 792 o Type = 1: Reason. 794 Information type values 2 through 32767 MUST be assigned using the 795 "Standards Action" policy, and values 32768 through 65535 using the 796 "Specification Required" policy, defined in [RFC5226]. 798 9.5. BMP Termination Message Reason Codes 800 This document defines four types for information carried in the 801 Termination message (Section 4.4) Reason code,: 803 o Type = 0: Administratively closed. 804 o Type = 1: Unspecified reason. 805 o Type = 2: Out of resources. 806 o Type = 3: Redundant connection. 808 Information type values 4 through 32767 MUST be assigned using the 809 "Standards Action" policy, and values 32768 through 65535 using the 810 "Specification Required" policy, defined in [RFC5226]. 812 10. Security Considerations 814 This document defines a mechanism to obtain a full dump or provide 815 continuous monitoring of a BGP speaker's local BGP table, including 816 received BGP messages. This capability could allow an outside party 817 to obtain information not otherwise obtainable. 819 Implementations of this protocol MUST require manual configuration of 820 the monitored and monitoring devices. 822 Users of this protocol MAY use some type of secure transport 823 mechanism, such as IPSec [RFC4303] or TCP-AO [RFC5925], in order to 824 provide mutual authentication, data integrity and transport 825 protection. 827 Unless a transport that provides mutual authentication is used, an 828 attacker could masquerade as the monitored router and trick a 829 monitoring station into accepting false information. 831 11. Acknowledgements 833 Thanks to Tim Evens, John ji Ioannidis, Mack McBride, Danny 834 McPherson, Dimitri Papadimitriou, Erik Romijn, and the members of the 835 GROW working group for their comments. 837 12. References 839 12.1. Normative References 841 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 842 for Network Management of TCP/IP-based internets:MIB-II", 843 STD 17, RFC 1213, March 1991. 845 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 846 Requirement Levels", BCP 14, RFC 2119, March 1997. 848 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 849 Protocol 4 (BGP-4)", RFC 4271, January 2006. 851 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 852 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 853 January 2007. 855 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 856 Number Space", RFC 4893, May 2007. 858 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 859 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 860 May 2008. 862 12.2. Informative References 864 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification 865 of management information for TCP/IP-based internets", 866 STD 16, RFC 1155, May 1990. 868 [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual 869 Conventions for Additional High Capacity Data Types", 870 RFC 2856, June 2000. 872 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 873 RFC 4303, December 2005. 875 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 876 Authentication Option", RFC 5925, June 2010. 878 Appendix A. Changes Between BMP Versions 1 and 2 880 o Added Peer Up Message 881 o Added L flag 882 o Editorial changes 884 Appendix B. Changes Between BMP Versions 2 and 3 886 o Added a 32-bit length field to the fixed header. 887 o Clarified error handling. 888 o Added new stat types: 5 (number of updates invalidated due to 889 ORIGINATOR_ID), 6 (number of updates invalidated due to 890 AS_CONFED_SEQUENCE/AS_CONFED_SET), 7 (number of routes in 891 Adj-RIB-In) and 8 (number of routes in Loc-RIB). 892 o Defined counters and gauges for use with stat types. 893 o For peer down messages, the relevant FSM event is to be sent in 894 type 2 messages. 895 o Added local address and local and remote ports to the peer up 896 message. 897 o Require End-of-RIB marker after initial dump. 898 o Added Initiation message with string content. 899 o Permit multiplexing pre- and post-policy feeds onto a single BMP 900 session. 901 o Changed assignment policy for IANA registries. 902 o Changed "Loc-RIB" references to refer to "Post-Policy Adj-RIB-In", 903 plus other editorial changes. 904 o Introduced option for monitoring station to be active party in 905 initiating connection. 906 o Introduced Termination message. 908 Authors' Addresses 910 John Scudder 911 Juniper Networks 912 1194 N. Mathilda Ave 913 Sunnyvale, CA 94089 914 USA 916 Email: jgs@juniper.net 917 Rex Fernando 918 Cisco Systems 919 170 W. Tasman Dr. 920 San Jose, CA 95134 921 USA 923 Email: rex@cisco.com 925 Stephen Stuart 926 Google 927 1600 Amphitheatre Parkway 928 Mountain View, CA 94043 929 USA 931 Email: sstuart@google.com