+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version:
This 1-octet unsigned integer indicates the protocol version
number of the message. The current BGMP version number is 1.
AddrFam:
The IANA-assigned address family number of the BGMP Identifier.
These include (among others):
Number Description
------ -----------
1 IP (IP version 4)
2 IPv6 (IP version 6)
Hold Time:
This 2-octet unsigned integer indicates the number of seconds that
the sender proposes for the value of the Hold Timer. Upon receipt
of an OPEN message, a BGMP speaker MUST calculate the value of the
Hold Timer by using the smaller of its configured Hold Time and
the Hold Time received in the OPEN message. The Hold Time MUST be
either zero or at least three seconds. An implementation may
reject connections on the basis of the Hold Time. The calculated
value indicates the maximum number of seconds that may elapse
between the receipt of successive KEEPALIVE, and/or UPDATE
messages by the sender.
BGMP Identifier:
This 4-octet (for IPv4) or 16-octet (IPv6) unsigned integer
indicates the BGMP Identifier of the sender. A given BGMP speaker
sets the value of its BGMP Identifier to a globally-unique value
assigned to that BGMP speaker (e.g., an IPv4 address). The value
of the BGMP Identifier is determined on startup and is the same
for every BGMP session opened.
Optional Parameters:
This field may contain a list of optional parameters, where each
parameter is encoded as a <Parameter Length, Parameter Type,
Parameter Value> triplet. The combined length of all optional
parameters can be derived from the Length field in the message
header.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. Type | Parm. Length | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Parameter Type is a one octet field that unambiguously identifies
individual parameters. Parameter Length is a one octet field that
contains the length of the Parameter Value field in octets.
Parameter Value is a variable length field that is interpreted
according to the value of the Parameter Type field.
This document defines the following Optional Parameters:
a) Authentication Information (Parameter Type 1): This optional
parameter may be used to authenticate a BGMP peer. The Parameter
Value field contains a 1-octet Authentication Code followed by a
variable length Authentication Data.
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| Auth. Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication Code:
This 1-octet unsigned integer indicates the authentication
mechanism being used. Whenever an authentication mechanism is
specified for use within BGMP, three things must be included in
the specification:
- the value of the Authentication Code which indicates use of the
mechanism, and - the form and meaning of the Authentication Data.
Note that a separate authentication mechanism may be used in
establishing the transport level connection.
Authentication Data:
The form and meaning of this field is a variable-length field
depend on the Authentication Code.
The minimum length of the OPEN message is 12 octets (including
message header).
b) Capability Information (Parameter Type 2): This is an Optional
Parameter that is used by a BGMP-speaker to convey to its peer the
list of capabilities supported by the speaker. The parameter
contains one or more triples <Capability Code, Capability Length,
Capability Value>, where each triple is encoded as shown below:
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
Capability Code:
Capability Code is a one octet field that unambiguously identifies
individual capabilities.
Capability Length:
Capability Length is a one octet field that contains the length of
the Capability Value field in octets.
Capability Value:
Capability Value is a variable length field that is interpreted
according to the value of the Capability Code field.
A particular capability, as identified by its Capability Code, may
occur more than once within the Optional Parameter.
This document reserves Capability Codes 128-255 for vendor-specific
applications.
This document reserves value 0.
Capability Codes (other than those reserved for vendor specific use)
are assigned only by the IETF consensus process and IESG approval.
5.3. UPDATE Message Format
UPDATE messages are used to transfer Join/Prune/FwdrPref information
between BGMP peers. The UPDATE message always includes the fixed-
size BGMP header, and one or more attributes as described below.
The message format below allows compact encoding of (*,G) Joins and
Prunes, while allowing the flexibility needed to do other updates
such as (S,G) Joins and Prunes towards sources as well as on the
shared tree. In the discussion below, an Encoded-Address-Prefix is
of the form:
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
+-+-+-+-+-+-+-+-+
|EnTyp| AddrFam |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EnTyp:
0 - All 1’s Mask. The Mask field is 0 bytes long.
1 - Mask length included. The Mask field is 4 bytes long, and
contains the mask length, in bits.
2 - Full Mask included. The Mask field is the same length
as the Address field, and contains the full bitmask.
AddrFam:
The IANA-assigned address family number of the encoded prefix.
Address:
The address associated with the given prefix to be encoded. The
length is determined based on the Address Family.
Mask:
The mask associated with the given prefix. The format (or absence)
of this field is determined by the EnTyp field.
Each attribute is of the form:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All attributes are 4-byte aligned.
Length:
The Length is the length of the entire attribute, including the
length, type, and data fields. If other attributes are nested
within the data field, the length includes the size of all such
nested attributes.
Type:
Types 128-255 are reserved for "optional" attributes. If a
required attribute is unrecognized, a NOTIFICATION will be sent and
the connection will be closed if the error is a fatal one.
Unrecognized optional attributes are simply ignored.
0 - JOIN
1 - PRUNE
2 - GROUP
3 - SOURCE
4 - FWDR_PREF
5 - POISON_REVERSE
a) JOIN (Type Code 0)
The JOIN attribute indicates that all GROUP or SOURCE options
nested immediately within the JOIN option should be joined.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
No JOIN, PRUNE, or FWDR_PREF attributes may be immediately nested
within a JOIN attribute.
b) PRUNE (Type Code 1)
The PRUNE attribute indicates that all GROUP or SOURCE attributes
nested immediately within the PRUNE attribute should be pruned.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
No JOIN, PRUNE, or FWDR_PREF attributes may be immediately nested
within a PRUNE attribute.
c) GROUP (Type Code 2)
The GROUP attribute identifies a given group-prefix. In addition,
any attributes nested immediately within the GROUP attribute also
apply to the given group-prefix.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Encoded-Address-Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoded-Address-Prefix The multicast group prefix to be joined to
pruned, in the format described above.
Nested Attributes No GROUP, SOURCE, or FWDR_PREF attributes may
be immediately nested within a GROUP
attribute.
d) SOURCE (Type Code 3):
The SOURCE attribute identifies a given source-prefix. In
addition, any attributes nested immediately within the SOURCE
attribute also apply to the given source-prefix.
The SOURCE attribute has 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Encoded-Address-Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoded-Address-Prefix The Source-prefix in the format described
above.
Nested Attributes No GROUP, SOURCE, or FWDR_PREF attributes may
be immediately nested within a SOURCE
attribute.
e) FWDR_PREF (Type Code 4)
The FWDR_PREF attribute provides a forwarder preference value for
all GROUP or SOURCE attributes nested immediately within the
FWDR_PREF attribute. It is used by a BGMP speaker to inform other
BGMP speakers of the originating speaker’s degree of preference for
a given group or source prefix. Usage of this attribute is
described in 5.5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preference Value A 32-bit non-negative integer.
Nested Attributes No JOIN, PRUNE, or FWDR_PREF attributes may be
immediately nested within a FWDR_PREF attribute.
e) POISON_REVERSE (Type Code 5)
The POISON_REVERSE attribute provides a "poison-reverse" (PR-bit)
value for all SOURCE attributes nested immediately within the
POISON_REVERSE attribute. It is used by a BGMP speaker to inform
other BGMP speakers from which it has received (S,G) Joins that
they are on the path of domains between the source and the root
domain.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P The PR-bit value.
Nested Attributes No attributes in the document other than SOURCE
may be immediately nested within a POISON_REVERSE
attribute.
5.4. Encoding examples
Below are enumerated examples of how various updates are built using
nested attributes, where A ( B ) denotes that attribute B is nested
within attribute A.
(*,G-prefix) Join: JOIN ( GROUP )
(*,G-prefix) Prune: PRUNE ( GROUP )
(S,G) Join towards S : GROUP ( JOIN ( SOURCE ) )
(S,G) Join cancelling prune towards root of G: GROUP ( JOIN ( SOURCE ) )
(S,G) Prune towards S: GROUP ( PRUNE ( SOURCE ) )
(S,G) Prune towards root of G: GROUP ( PRUNE ( SOURCE ) )
Switch from (*,G) to (S,G): PRUNE ( GROUP ( JOIN ( SOURCE ) ) )
Switch from (S,G) to (*,G): JOIN ( GROUP )
Initial (*,G) Join with S pruned: JOIN ( GROUP ( PRUNE ( SOURCE ) ) )
Forwarder preference announcement for G-prefix: FWDR_PREF ( GROUP )
Forwarder preference announcement for S-prefix: FWDR_PREF ( SOURCE )
5.5. KEEPALIVE Message Format
BGMP does not use any transport protocol-based keep-alive mechanism
to determine if peers are reachable. Instead, KEEPALIVE messages are
exchanged between peers often enough as not to cause the Hold Timer
to expire. A reasonable maximum time between the last KEEPALIVE or
UPDATE message sent, and the time at which a KEEPALIVE message is
sent, would be one third of the Hold Time interval. KEEPALIVE
messages MUST NOT be sent more frequently than one per second. An
implementation MAY adjust the rate at which it sends KEEPALIVE
messages as a function of the Hold Time interval.
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
messages MUST NOT be sent.
A KEEPALIVE message consists of only a message header, and has a
length of 4 octets.
5.6. NOTIFICATION Message Format
A NOTIFICATION message is sent when an error condition is detected.
The BGMP connection is closed immediately after sending it if the
error is a fatal one.
In addition to the fixed-size BGMP header, the NOTIFICATION 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O| Error code | Error subcode | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
O-bit:
Open-bit. If clear, the connection will be closed. If set,
indicates the error is not fatal.
Error Code:
This 1-octet unsigned integer indicates the type of NOTIFICATION.
The following Error Codes have been defined:
Error Code Symbolic Name Reference
1 Message Header Error Section 9.1
2 OPEN Message Error Section 9.2
3 UPDATE Message Error Section 9.3
4 Hold Timer Expired Section 9.5
5 Finite State Machine Error Section 9.6
6 Cease Section 9.7
Error subcode:
This 1-octet unsigned integer provides more specific information
about the nature of the reported error. Each Error Code may have
one or more Error Subcodes associated with it. If no appropriate
Error Subcode is defined, then a zero (Unspecific) value is used
for the Error Subcode field. The notation (MC) below indicates
the error is a fatal one and the O-bit must be clear. Non-fatal
subcodes SHOULD be sent with the O-bit set.
Message Header Error subcodes:
2 - Bad Message Length (MC)
3 - Bad Message Type (MC)
OPEN Message Error subcodes:
1 - Unsupported Version (MC)
4 - Unsupported Optional Parameter
5 - Authentication Failure (MC)
6 - Unacceptable Hold Time (MC)
7 - Unsupported Capability (MC)
UPDATE Message Error subcodes:
1 - Malformed Attribute List (MC)
2 - Unrecognized Attribute Type
5 - Attribute Length Error (MC)
10 - Invalid Address
11 - Invalid Mask
13 - Unrecognized Address Family
Data:
This variable-length field is used to diagnose the reason for the
NOTIFICATION. The contents of the Data field depend upon the
Error Code and Error Subcode. See Section 7 below for more