4
Network Working Group J. Scudder
5
Internet-Draft R. Fernando
6
Intended status: Standards Track Juniper Networks
7
Expires: May 21, 2009 S. Stuart
12
BGP Monitoring Protocol
17
By submitting this Internet-Draft, each author represents that any
18
applicable patent or other IPR claims of which he or she is aware
19
have been or will be disclosed, and any of which he or she becomes
20
aware will be disclosed, in accordance with Section 6 of BCP 79.
22
Internet-Drafts are working documents of the Internet Engineering
23
Task Force (IETF), its areas, and its working groups. Note that
24
other groups may also distribute working documents as Internet-
27
Internet-Drafts are draft documents valid for a maximum of six months
28
and may be updated, replaced, or obsoleted by other documents at any
29
time. It is inappropriate to use Internet-Drafts as reference
30
material or to cite them other than as "work in progress."
32
The list of current Internet-Drafts can be accessed at
33
http://www.ietf.org/ietf/1id-abstracts.txt.
35
The list of Internet-Draft Shadow Directories can be accessed at
36
http://www.ietf.org/shadow.html.
38
This Internet-Draft will expire on May 21, 2009.
42
This document proposes a simple protocol, BMP, which can be used to
43
monitor BGP sessions. BMP is intended to provide a more convenient
44
interface for obtaining route views for research purpose than the
45
screen-scraping approach in common use today. The design goals are
46
to keep BMP simple, useful, easily implemented, and minimally
47
service-affecting. BMP is not suitable for use as a routing
55
Scudder, et al. Expires May 21, 2009 [Page 1]
57
Internet-Draft BGP Monitoring Protocol November 2008
62
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
63
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
64
2. BMP Message Format . . . . . . . . . . . . . . . . . . . . . . 4
65
2.1. Route Monitoring . . . . . . . . . . . . . . . . . . . . . 5
66
2.2. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 6
67
2.3. Peer Down Notification . . . . . . . . . . . . . . . . . . 7
68
3. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . . 8
69
4. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . . 8
70
5. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
71
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
72
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
73
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
74
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
75
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
77
Intellectual Property and Copyright Statements . . . . . . . . . . 12
111
Scudder, et al. Expires May 21, 2009 [Page 2]
113
Internet-Draft BGP Monitoring Protocol November 2008
118
Many researchers wish to have access to the contents of routers' BGP
119
RIBs as well as a view of protocol updates that the router is
120
receiving. This monitoring task cannot be realized by standard
121
protocol mechanisms. At present, this data can only be obtained
122
through screen-scraping.
124
The BMP protocol provides access to the Adj-RIB-In of a peer on an
125
ongoing basis and a periodic dump of certain statistics that the
126
monitoring station can use for further analysis. The following are
127
the messages provided by BMP.
129
o Route Monitoring (RM): An initial dump of all routes received from
130
a peer as well as an ongoing mechanism that sends the incremental
131
routes advertised and withdrawn by a peer to the monitoring
134
o Peer Down Notification (PD): A message sent to indicate that a
135
peering session has gone down with information indicating the
136
reason for the session disconnect.
138
o Stats Reports (SR): This is an ongoing dump of statistics that can
139
be used by the monitoring station as a high level indication of
140
the activity going on in the router.
142
BMP operates over TCP. All options are controlled by configuration
143
on the monitored router. Communication is unidirectional, from the
144
monitored router to the monitoring station.
146
The monitoring station is configured to listen on a particular TCP
147
port and the router is configured to establish an active connection
148
to that port and to send messages on that TCP connection. There is
149
no initialization or handshaking phase, messages are simply sent as
150
soon as the connection is established.
152
If the monitoring station intends to restart BMP processing, it
153
simply drops the connection. The router then re-establishes the
154
connection and resends the messages.
156
1.1. Requirements Language
158
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
159
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
160
document are to be interpreted as described in RFC 2119 [RFC2119].
167
Scudder, et al. Expires May 21, 2009 [Page 3]
169
Internet-Draft BGP Monitoring Protocol November 2008
172
2. BMP Message Format
174
The following common header appears in all BMP messages. The rest of
175
the data in a BMP message is dependent on the "Message Type" field in
178
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
179
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
180
| Version | Msg. Type | Peer Type | Peer Flags |
181
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
182
| Peer Distinguisher (present based on peer type) |
184
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
185
| Peer Address (16 bytes) |
187
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
189
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
191
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
192
| Timestamp (seconds) |
193
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
194
| Timestamp (microseconds) |
195
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
197
o Version (1 byte): Indicates the BMP version. This is set to '1'
198
for all messages defined in this specification.
200
o Message Type (1 byte): This identifies the type of the BMP
203
* Type = 1: Route Monitoring
204
* Type = 2: Statistics Report
205
* Type = 3: Peer Down Notification
207
o Peer Type (1 byte): These bits identify the type of the peer.
208
Currently only two types of peers are identified,
210
* Peer Type = 0: Global Instance Peer
211
* Peer Type = 1: L3 VPN Instance Peer
213
o Peer Flags (1 byte): These flags provide more information about
214
the peer. The flags are defined as follows.
223
Scudder, et al. Expires May 21, 2009 [Page 4]
225
Internet-Draft BGP Monitoring Protocol November 2008
231
* The V flag indicates the the Peer address is an IPv6 address.
232
For IPv4 peers this is set to 0.
233
* The remaining bits are reserved for future use.
235
o Peer Distinguisher (8 bytes): Routers today can have multiple
236
instances (example L3VPNs). This field is present to distinguish
237
peers that belong to one address domain from the other.
239
If the peer is a "Global Instance Peer", this field is zero
240
filled. If the peer is a "L3VPN Instance Peer", it is set to the
241
route distinguisher of the particular L3VPN instance that the peer
244
o Peer Address: The remote IP address associated with the TCP
245
session over which the encapsulated PDU was received. It is 4
246
bytes long if an IPv4 address is carried in this field (with most
247
significant bytes zero filled) and 16 bytes long if an IPv6
248
address is carried in this field.
250
o Peer AS: The Autonomous System number of the peer from which the
251
encapsulated PDU was received. If a 16 bit AS number is stored in
252
this field [RFC4893], it should be padded with zeroes in the most
255
o Peer BGP ID: The BGP Identifier of the peer from which the
256
encapsulated PDU was received.
258
o Timestamp: The time when the encapsulated PDU was received,
259
expressed in seconds and microseconds since midnight (zero hour),
260
January 1, 1970 (UTC). If zero, the time is unavailable.
262
2.1. Route Monitoring
264
Route Monitoring messages are used for initial synchronization of
265
ADJ-RIB-In. They are also used for ongoing monitoring of received
266
advertisements and withdraws. This is discussed in more detail in
269
Following the common BMP header is a BGP PDU. The length of the PDU
270
can be determined by parsing it in the normal fashion as specified in
279
Scudder, et al. Expires May 21, 2009 [Page 5]
281
Internet-Draft BGP Monitoring Protocol November 2008
286
These messages contain information that could be used by the
287
monitoring station to observe interesting events that occur on the
288
router. 'Stats Report' messages have a message type of '3'.
290
The transmission of the SR messages could be timer triggered or event
291
driven (for example, when a significant event occurs or a threshold
292
is reached). This specification does not impose any timing
293
restrictions on when and on what event these reports have to be
294
transmitted. It is left to the implementation to determine
295
transmission timings. This document only specifies the form and
296
content of SR messages.
298
Following the common BMP header is a 4-byte field that indicates the
299
number of counters in the stats message where each counter is encoded
303
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
304
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
306
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
308
Each counter is encoded as follows,
311
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
312
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
313
| Stat Type | Stat Len |
314
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
317
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
319
o Stat Type (2 bytes): Defines the type of the statistic carried in
320
the "Stat Data" field.
322
o Stat Len (2 bytes): Defines the length of the "Stat Data" Field.
324
This specification defines the following statistics. All statistics
325
are 4-byte quantities and the stats data are counters.
327
o Stat Type = 1: Number of prefixes rejected by inbound policy.
329
o Stat Type = 2: Number of (known) duplicate prefix advertisements.
335
Scudder, et al. Expires May 21, 2009 [Page 6]
337
Internet-Draft BGP Monitoring Protocol November 2008
340
o Stat Type = 3: Number of (known) duplicate withdraws.
342
o Stat Type = 4: Number of updates invalidated due to CLUSTER_LIST
345
o Stat Type = 5: Number of updates invalidated due to AS_PATH loop.
347
Note that the current specification only specifies 4-byte counters as
348
"Stat Data". This does not preclude future versions from
349
incorporating more complex TLV-type "Stat Data" (for example, one
350
which can carry prefix specific data). SR messages are optional.
351
However if an SR message is transmitted, this specification requires
352
at least one statistic to be carried in it.
354
2.3. Peer Down Notification
356
This message is used to indicate that a peering session was
357
terminated. The type of this message is 4.
361
| 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
362
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
363
| Notification Message (present if Reason = 1 or 3) |
365
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
367
Reason indicates why the session was closed. Defined values are:
369
o Reason 1: The local system closed the session. Following the
370
Reason is a BGP PDU containing a BGP NOTIFICATION message that
371
would have been sent to the peer. The length of the PDU can be
372
determined by parsing it in the normal fashion as specified in
375
o Reason 2: The local system closed the session. No notification
378
o Reason 3: The remote system closed the session with a notification
379
message. Following the Reason is a BGP PDU containing the BGP
380
NOTIFICATION message as received from the peer. The length of the
381
PDU can be determined by parsing it in the normal fashion as
382
specified in [RFC4271].
384
o Reason 4: The remote system closed the session without a
385
notification message.
391
Scudder, et al. Expires May 21, 2009 [Page 7]
393
Internet-Draft BGP Monitoring Protocol November 2008
398
After the BMP session is up, Route Monitoring messages are used to
399
provide a snapshot of the Adj-RIB-In of a particular peer. It does
400
so by sending all routes stored in the Adj-RIB-In of that peer using
401
standard BGP Update messages. There is no requirement on the
402
ordering of messages in the peer dump.
404
Depending on the implementation or configuration, it may only be
405
possible to send the Loc-RIB (post-policy routes) instead of the Adj-
406
RIB-In. This is because it is possible that a BGP implementation may
407
not store, for example, routes which have been filtered out by
408
policy. If this is the case, the implementation may send the Loc-RIB
409
path that pertains to a particular peer in the route monitor message.
411
If the implementation is able to provide information about when
412
routes were received, it MAY provide such information in the BMP
413
timestamp field. Otherwise, the BMP timestamp field MUST be set to
414
zero, indicating that time is not available.
416
Ongoing monitoring is accomplished by propagating route changes in
417
BGP UPDATE PDUs and forwarding those PDUs to the monitoring station,
418
again using RM messages. When a change occurs to a route, such as an
419
attribute change, the router must update the monitor with the new
420
attribute. When a route is withdrawn by a peer, a corresponding
421
withdraw is sent to the monitor. Multiple changed routes MAY be
422
grouped into a single BGP UPDATE PDU when feasible, exactly as in the
423
standard BGP protocol.
425
It's important to note that RM messages are not real time replicated
426
messages received from a peer. While the router should attempt to
427
generate updates as soon as they are received there is a finite time
428
that could elapse between reception of an update and the generation
429
an RM message and its transmission to the monitoring station. If
430
there are state changes in the interim for that prefix, it is
431
acceptable that the router generate the final state of that prefix to
432
the monitoring station. The actual PDU generated and transmitted to
433
the station might also differ from the exact PDU received from the
434
peer, for example due to differences between how different
435
implementations format path attributes.
440
As outlined above, SR messages are used to monitor specific events
441
and counters on the monitored router. One type of monitoring could
442
be to find out if there are an undue number of route advertisements
443
and withdraws happening (churn) on the monitored router. Another
447
Scudder, et al. Expires May 21, 2009 [Page 8]
449
Internet-Draft BGP Monitoring Protocol November 2008
452
metric is to evaluate the number of looped AS-Paths on the router.
454
While this document proposes a small set of counters to begin with,
455
the authors envision this list may grow in the future with new
456
applications that require BMP style monitoring.
461
Once the BMP session is established route monitoring starts dumping
462
the current snapshot as well as incremental changes simultaneously.
464
It is fine to have these operations occur concurrently. If the
465
initial dump visits a route and subsequently a withdraw is received,
466
this will be forwarded to the monitoring station which would have to
467
correlate and reflect the deletion of that route in its internal
468
state. This is an operation a monitoring station would need to
471
If the router receives a withdraw for a prefix even before the peer
472
dump procedure visits that prefix, then the router would clean up
473
that route from its internal state and will not forward it to the
474
monitoring station. In this case, the monitoring station may receive
475
a bogus withdraw which it can safely ignore.
478
6. IANA Considerations
480
This document defines three message types for transferring BGP
481
messages between cooperating systems (Section 2):
483
o Type 1: Route Monitor
484
o Type 2: Statistics Report
485
o Type 3: Peer Down Notification
487
Type values 4 through 255 MUST be assigned using the "IETF Consensus"
488
policy defined in [RFC5226].
490
This document defines five statistics types for statistics reporting
493
o Stat Type = 1: Number of prefixes rejected by inbound policy.
494
o Stat Type = 2: Number of (known) duplicate prefix advertisements.
495
o Stat Type = 3: Number of (known) duplicate withdraws.
496
o Stat Type = 4: Number of updates invalidated due to CLUSTER_LIST
503
Scudder, et al. Expires May 21, 2009 [Page 9]
505
Internet-Draft BGP Monitoring Protocol November 2008
508
o Stat Type = 5: Number of updates invalidated due to AS_PATH loop.
510
Stat Type values 6 through 32767 MUST be assigned using the "IETF
511
Consensus" policy, and values 32768 through 65535 using the "First
512
Come First Served" policy, defined in [RFC5226].
515
7. Security Considerations
517
This document defines a mechanism to obtain a full dump or provide
518
continuous monitoring of a BGP speaker's local BGP table, including
519
received BGP messages. This capability could allow an outside party
520
to obtain information not otherwise obtainable.
522
Implementations of this protocol MUST require manual configuration of
523
the monitored and monitoring devices.
525
Users of this protocol MAY use some type of secure transmission
526
mechanism, such as IPSec [RFC4303], to transmit this data.
531
8.1. Normative References
533
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
534
Requirement Levels", BCP 14, RFC 2119, March 1997.
536
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
537
Protocol 4 (BGP-4)", RFC 4271, January 2006.
539
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
540
Number Space", RFC 4893, May 2007.
542
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
543
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
546
8.2. Informative References
548
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
549
RFC 4303, December 2005.
559
Scudder, et al. Expires May 21, 2009 [Page 10]
561
Internet-Draft BGP Monitoring Protocol November 2008
572
Email: jgs@juniper.net
581
Email: rex@juniper.net
586
1600 Amphitheatre Parkway
587
Mountain View, CA 94043
590
Email: sstuart@google.com
615
Scudder, et al. Expires May 21, 2009 [Page 11]
617
Internet-Draft BGP Monitoring Protocol November 2008
620
Full Copyright Statement
622
Copyright (C) The IETF Trust (2008).
624
This document is subject to the rights, licenses and restrictions
625
contained in BCP 78, and except as set forth therein, the authors
626
retain all their rights.
628
This document and the information contained herein are provided on an
629
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
630
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
631
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
632
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
633
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
634
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
637
Intellectual Property
639
The IETF takes no position regarding the validity or scope of any
640
Intellectual Property Rights or other rights that might be claimed to
641
pertain to the implementation or use of the technology described in
642
this document or the extent to which any license under such rights
643
might or might not be available; nor does it represent that it has
644
made any independent effort to identify any such rights. Information
645
on the procedures with respect to rights in RFC documents can be
646
found in BCP 78 and BCP 79.
648
Copies of IPR disclosures made to the IETF Secretariat and any
649
assurances of licenses to be made available, or the result of an
650
attempt made to obtain a general license or permission for the use of
651
such proprietary rights by implementers or users of this
652
specification can be obtained from the IETF on-line IPR repository at
653
http://www.ietf.org/ipr.
655
The IETF invites any interested party to bring to its attention any
656
copyrights, patents or patent applications, or other proprietary
657
rights that may cover technology that may be required to implement
658
this standard. Please address the information to the IETF at
671
Scudder, et al. Expires May 21, 2009 [Page 12]
added
removed
dev/RFC/draft-scudder-bmp-01.txt
