details.
Note that the length of the Data field can be determined from the
message Length field by the formula:
Message Length = 6 + Data Length
The minimum length of the NOTIFICATION message is 6 octets
(including message header).
6. BGMP Error Handling
This section describes actions to be taken when errors are detected
while processing BGMP messages. BGMP Error Handling is similar to
that of BGP [BGP].
When any of the conditions described here are detected, a
NOTIFICATION message with the indicated Error Code, Error Subcode,
and Data fields is sent, and the BGMP connection is closed if the
error is a fatal one. If no Error Subcode is specified, then a zero
must be used.
The phrase "the BGMP connection is closed" means that the transport
protocol connection has been closed and that all resources for that
BGMP connection have been deallocated. The remote peer is removed
from the target list of all tree state entries.
Unless specified explicitly, the Data field of the NOTIFICATION
message that is sent to indicate an error is empty.
6.1. Message Header error handling
All errors detected while processing the Message Header are indicated
by sending the NOTIFICATION message with Error Code Message Header
Error. The Error Subcode elaborates on the specific nature of the
error.
If the Length field of the message header is less than 4 or greater
than 4096, or if the Length field of an OPEN message is less than
the minimum length of the OPEN message, or if the Length field of an
UPDATE message is less than the minimum length of the UPDATE message,
or if the Length field of a KEEPALIVE message is not equal to 4, then
the Error Subcode is set to Bad Message Length. The Data field
contains the erroneous Length field.
If the Type field of the message header is not recognized, then the
Error Subcode is set to Bad Message Type. The Data field contains
the erroneous Type field.
6.2. OPEN message error handling
All errors detected while processing the OPEN message are indicated
by sending the NOTIFICATION message with Error Code OPEN Message
Error. The Error Subcode elaborates on the specific nature of the
error.
If the version number contained in the Version field of the received
OPEN message is not supported, then the Error Subcode is set to
Unsupported Version Number. The Data field is a 2-octet unsigned
integer, which indicates the largest locally supported version number
less than the version the remote BGMP peer bid (as indicated in the
received OPEN message).
If the Hold Time field of the OPEN message is unacceptable, then the
Error Subcode MUST be set to Unacceptable Hold Time. An
implementation MUST reject Hold Time values of one or two seconds.
An implementation MAY reject any proposed Hold Time. An
implementation which accepts a Hold Time MUST use the negotiated
value for the Hold Time.
If one of the Optional Parameters in the OPEN message is not
recognized, then the Error Subcode is set to Unsupported Optional
Parameters.
If the OPEN message carries Authentication Information (as an
Optional Parameter), then the corresponding authentication procedure
is invoked. If the authentication procedure (based on Authentication
Code and Authentication Data) fails, then the Error Subcode is set to
Authentication Failure.
If the OPEN message indicates that the peer does not support a
capability which the receiver requires, the receiver may send a
NOTIFICATION message to the peer, and terminate peering. The Error
Subcode in the message is set to Unsupported Capability. The Data
field in the NOTIFICATION message lists the set of capabilities that
cause the speaker to send the message. Each such capability is
encoded the same way as it was encoded in the received OPEN message.
6.3. UPDATE message error handling
All errors detected while processing the UPDATE message are indicated
by sending the NOTIFICATION message with Error Code UPDATE Message
Error. The error subcode elaborates on the specific nature of the
error.
If any recognized attribute has Attribute Length that conflicts with
the expected length (based on the attribute type code), then the
Error Subcode is set to Attribute Length Error. The Data field
contains the erroneous attribute (type, length and value).
If the Encoded-Address-Prefix field in some attribute is
syntactically incorrect, then the Error Subcode is set to Invalid
Prefix Field.
If any other is encountered when processing attributes (such as
invalid nestings), then the Error Subcode is set to Malformed
Attribute List, and the problematic attribute is included in the data
field.
6.4. NOTIFICATION message error handling
If a peer sends a NOTIFICATION message, and there is an error in that
message, there is unfortunately no means of reporting this error via
a subsequent NOTIFICATION message. Any such error, such as an
unrecognized Error Code or Error Subcode, should be noticed, logged
locally, and brought to the attention of the administration of the
peer. The means to do this, however, lies outside the scope of this
document.
6.5. Hold Timer Expired error handling
If a system does not receive successive KEEPALIVE and/or UPDATE
and/or NOTIFICATION messages within the period specified in the Hold
Time field of the OPEN message, then the NOTIFICATION message with
Hold Timer Expired Error Code must be sent and the BGMP connection
closed.
6.6. Finite State Machine error handling
Any error detected by the BGMP Finite State Machine (e.g., receipt of
an unexpected event) is indicated by sending the NOTIFICATION message
with Error Code Finite State Machine Error.
6.7. Cease
In absence of any fatal errors (that are indicated in this section),
a BGMP peer may choose at any given time to close its BGMP connection
by sending the NOTIFICATION message with Error Code Cease. However,
the Cease NOTIFICATION message must not be used when a fatal error
indicated by this section does exist.
6.8. Connection collision detection
If a pair of BGMP speakers try simultaneously to establish a TCP
connection to each other, then two parallel connections between this
pair of speakers might well be formed. We refer to this situation as
connection collision. Clearly, one of these connections must be
closed.
Based on the value of the BGMP Identifier a convention is established
for detecting which BGMP connection is to be preserved when a
collision does occur. The convention is to compare the BGMP
Identifiers of the peers involved in the collision and to retain only
the connection initiated by the BGMP speaker with the higher-valued
BGMP Identifier.
Upon receipt of an OPEN message, the local system must examine all of
its connections that are in the OpenConfirm state. A BGMP speaker
may also examine connections in an OpenSent state if it knows the
BGMP Identifier of the peer by means outside of the protocol. If
among these connections there is a connection to a remote BGMP
speaker whose BGMP Identifier equals the one in the OPEN message,
then the local system performs the following collision resolution
procedure:
1. The BGMP Identifier of the local system is compared to the BGMP
Identifier of the remote system (as specified in the OPEN
message).
2. If the value of the local BGMP Identifier is less than the remote
one, the local system closes BGMP connection that already exists
(the one that is already in the OpenConfirm state), and accepts
BGMP connection initiated by the remote system.
3. Otherwise, the local system closes newly created BGMP connection
(the one associated with the newly received OPEN message), and
continues to use the existing one (the one that is already in the
OpenConfirm state).
Comparing BGMP Identifiers is done by treating them as (4-octet long)
unsigned integers.
A connection collision with an existing BGMP connection that is in
Established states causes unconditional closing of the newly created
connection. Note that a connection collision cannot be detected with
connections that are in Idle, or Connect, or Active states.
Closing the BGMP connection (that results from the collision
resolution procedure) is accomplished by sending the NOTIFICATION
message with the Error Code Cease.
7. BGMP Version Negotiation
BGMP speakers may negotiate the version of the protocol by making
multiple attempts to open a BGMP connection, starting with the
highest version number each supports. If an open attempt fails with
an Error Code OPEN Message Error, and an Error Subcode Unsupported
Version Number, then the BGMP speaker has available the version
number it tried, the version number its peer tried, the version
number passed by its peer in the NOTIFICATION message, and the
version numbers that it supports. If the two peers do support one or
more common versions, then this will allow them to rapidly determine
the highest common version. In order to support BGMP version
negotiation, future versions of BGMP must retain the format of the
OPEN and NOTIFICATION messages.
7.1. BGMP Capability Negotiation
When a BGMP speaker sends an OPEN message to its BGMP peer, the
message may include an Optional Parameter, called Capabilities. The
parameter lists the capabilities supported by the speaker.
A BGMP speaker may use a particular capability when peering with
another speaker only if both speakers support that capability. A
BGMP speaker determines the capabilities supported by its peer by
examining the list of capabilities present in the Capabilities
Optional Parameter carried by the OPEN message that the speaker
receives from the peer.
8. BGMP Finite State machine
This section specifies BGMP operation in terms of a Finite State
Machine (FSM). Following is a brief summary and overview of BGMP
operations by state as determined by this FSM.
Initially BGMP is in the Idle state.
Idle state:
In this state BGMP refuses all incoming BGMP connections. No
resources are allocated to the peer. In response to the Start
event (initiated by either system or operator) the local system
initializes all BGMP resources, starts the ConnectRetry timer,
initiates a transport connection to the other BGMP peer, while
listening for a connection that may be initiated by the remote
BGMP peer, and changes its state to Connect. The exact value of
the ConnectRetry timer is a local matter, but should be
sufficiently large to allow TCP initialization.
If a BGMP speaker detects an error, it shuts down the connection
and changes its state to Idle. Getting out of the Idle state
requires generation of the Start event. If such an event is
generated automatically, then persistent BGMP errors may result in
persistent flapping of the speaker. To avoid such a condition it
is recommended that Start events should not be generated
immediately for a peer that was previously transitioned to Idle
due to an error. For a peer that was previously transitioned to
Idle due to an error, the time between consecutive generation of
Start events, if such events are generated automatically, shall
exponentially increase. The value of the initial timer shall be
60 seconds. The time shall be doubled for each consecutive retry.
Any other event received in the Idle state is ignored.
Connect state:
In this state BGMP is waiting for the transport protocol
connection to be completed.
If the transport protocol connection succeeds, the local system
clears the ConnectRetry timer, completes initialization, sends an
OPEN message to its peer, and changes its state to OpenSent. If
the transport protocol connect fails (e.g., retransmission
timeout), the local system restarts the ConnectRetry timer,
continues to listen for a connection that may be initiated by the
remote BGMP peer, and changes its state to Active state.
In response to the ConnectRetry timer expired event, the local
system restarts the ConnectRetry timer, initiates a transport
connection to the other BGMP peer, continues to listen for a
connection that may be initiated by the remote BGMP peer, and
stays in the Connect state.
The Start event is ignored in the Connect state.
In response to any other event (initiated by either system or
operator), the local system releases all BGMP resources associated
with this connection and changes its state to Idle.
Active state:
In this state BGMP is trying to acquire a peer by listening for an
incoming transport protocol connection.
If the transport protocol connection succeeds, the local system
clears the ConnectRetry timer, completes initialization, sends an
OPEN message to its peer, sets its Hold Timer to a large value,
and changes its state to OpenSent. A Hold Timer value of 4
minutes is suggested.
In response to the ConnectRetry timer expired event, the local
system restarts the ConnectRetry timer, initiates a transport
connection to other BGMP peer, continues to listen for a
connection that may be initiated by the remote BGMP peer, and
changes its state to Connect.
If the local system detects that a remote peer is trying to
establish BGMP connection to it, and the IP address of the remote
peer is not an expected one, the local system restarts the
ConnectRetry timer, rejects the attempted connection, continues to
listen for a connection that may be initiated by the remote BGMP
peer, and stays in the Active state.
The Start event is ignored in the Active state.
In response to any other event (initiated by either system or
operator), the local system releases all BGMP resources associated
with this connection and changes its state to Idle.
OpenSent state:
In this state BGMP waits for an OPEN message from its peer. When
an OPEN message is received, all fields are checked for
correctness. If the BGMP message header checking or OPEN message
checking detects an error (see Section 6.2), or a connection
collision (see Section 6.8) the local system sends a NOTIFICATION
message and changes its state to Idle.
If there are no errors in the OPEN message, BGMP sends a KEEPALIVE
message and sets a KeepAlive timer. The Hold Timer, which was
originally set to a large value (see above), is replaced with the
negotiated Hold Time value (see section 4.2). If the negotiated
Hold Time value is zero, then the Hold Time timer and KeepAlive
timers are not started. If the configured remote Autonomous
System value for this peering is the same as the local Autonomous
System number, then the connection is an "internal" connection;
otherwise, it is "external". Finally, the state is changed to
OpenConfirm.
If a disconnect notification is received from the underlying
transport protocol, the local system closes the BGMP connection,
restarts the ConnectRetry timer, while continue listening for
connection that may be initiated by the remote BGMP peer, and goes
into the Active state.
If the Hold Timer expires, the local system sends NOTIFICATION
message with error code Hold Timer Expired and changes its state
to Idle.
In response to the Stop event (initiated by either system or
operator) the local system sends NOTIFICATION message with Error
Code Cease and changes its state to Idle.
The Start event is ignored in the OpenSent state.
In response to any other event the local system sends NOTIFICATION
message with Error Code Finite State Machine Error and changes its
state to Idle.
Whenever BGMP changes its state from OpenSent to Idle, it closes
the BGMP (and transport-level) connection and releases all
resources associated with that connection.
OpenConfirm state:
In this state BGMP waits for a KEEPALIVE or NOTIFICATION message.
If the local system receives a KEEPALIVE message, it changes its
state to Established.
If the Hold Timer expires before a KEEPALIVE message is received,
the local system sends NOTIFICATION message with error code Hold
Timer Expired and changes its state to Idle.
If the local system receives a NOTIFICATION message, it changes
its state to Idle.
If the KeepAlive timer expires, the local system sends a KEEPALIVE
message and restarts its KeepAlive timer.
If a disconnect notification is received from the underlying
transport protocol, the local system changes its state to Idle.
In response to the Stop event (initiated by either system or
operator) the local system sends NOTIFICATION message with Error
Code Cease and changes its state to Idle.
The Start event is ignored in the OpenConfirm state.
In response to any other event the local system sends NOTIFICATION
message with Error Code Finite State Machine Error and changes its
state to Idle.
Whenever BGMP changes its state from OpenConfirm to Idle, it
closes the BGMP (and transport-level) connection and releases all
resources associated with that connection.
Established state:
In the Established state BGMP can exchange UPDATE, NOTIFICATION,
and KEEPALIVE messages with its peer.
If the local system receives an UPDATE or KEEPALIVE message, it
restarts its Hold Timer, if the negotiated Hold Time value is
non-zero.
If the local system receives a NOTIFICATION message, it changes
its state to Idle.
If the local system receives an UPDATE message and the UPDATE
message error handling procedure (see Section 6.3) detects an
error, the local system sends a NOTIFICATION message and changes
its state to Idle.
If a disconnect notification is received from the underlying
transport protocol, the local system changes its state to Idle.
If the Hold Timer expires, the local system sends a NOTIFICATION
message with Error Code Hold Timer Expired and changes its state
to Idle.
If the KeepAlive timer expires, the local system sends a KEEPALIVE
message and restarts its KeepAlive timer.
Each time the local system sends a KEEPALIVE or UPDATE message, it
restarts its KeepAlive timer, unless the negotiated Hold Time
value is zero.
In response to the Stop event (initiated by either system or
operator), the local system sends a NOTIFICATION message with
Error Code Cease and changes its state to Idle.
The Start event is ignored in the Established state.
In response to any other event, the local system sends
NOTIFICATION message with Error Code Finite State Machine Error
and changes its state to Idle.
Whenever BGMP changes its state from Established to Idle, it
closes the BGMP (and transport-level) connection, releases all
resources associated with that connection, and deletes all routes
derived from that connection.
9. Security Considerations
If a BGMP speaker accepts unauthorized or altered BGMP messages,
denial of service due to excess bandwidth consumption or lack of
multicast connectivity can result. Authentication of BGMP messages
can protect against this behavior.
A BGMP implementation MUST implement Keyed MD5 [RFC2385] to secure
control messages, and MUST be capable of interoperating with peers
that do not support it. However, if one side of the connection is
configured with Keyed MD5 and the other side is not, the connection
SHOULD NOT be established.
This provides a weak security mechanism, as it is still possible for
denial of service to occur as a result of messages relayed through a
trusted peer. However, this model is the same as the currently
practiced security mechanism for BGP. It is anticipated that future
work will provide different stronger mechanisms for dealing with
these issues in routing protocols.
10. Acknowledgements
In addition to the editor, the following individuals have contributed
to the design of BGMP: Cengiz Alaettinoglu, Tony Ballardie, Steve
Casner, Steve Deering, Deborah Estrin, Dino Farinacci, Bill Fenner,
Mark Handley, Ahmed Helmy, Van Jacobson, Dave Meyer, and Satish
Kumar.
This document is the product of the IETF BGMP Working Group with Dave
Thaler as editor.
Rusty Eddy, Isidor Kouvelas, and Pavlin Radoslavov also provided
valuable feedback on this document.
11. References
11.1. Normative References
[INTEROP] Thaler, D., "Interoperability Rules for Multicast Routing
Protocols", RFC 2715, October 1999.
[RFC2385] Heffernan, A., "Protection of BGP sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[V6PREFIX] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
11.2. Informative References
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-
4)", RFC 1771, March 1995.
[MBGP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[CBT] Ballardie, A., "Core Based Trees (CBT version 2) Multicast
Routing -- Protocol Specification", RFC 2189, September
1997.
[DVMRP] Pusateri, T., "Distance Vector Multicast Routing
Protocol", Work in Progress, October 2003.
[IPv6AA] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
1994.
[PIMDM] Adams, A., Nicholas, J. and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", Work in Progress, September
2003.
[PIMSM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification", RFC 2362, June 1998.
[REFLECT] Bates, T. and R. Chandra, "BGP Route Reflection: An
alternative to full mesh IBGP", RFC 1966, June 1996.
[V4PREFIX] Thaler, D., "Unicast-Prefix-based IPv4 Multicast
Addresses", Work in Progress, August 2004.
Authors’ Address
Dave Thaler
Microsoft
One Microsoft Way
Redmond, WA 98052
EMail: dthaler@microsoft.com
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE