the case of a (*,G), the target list is initialized to contain the
next-hop peer towards the nominal root of G, if it is an external
peer. If the peer is internal, the target list is initialized to
contain the M-IGP component owning the next-hop interface. If there
is no next-hop peer (because the nominal root of G is inside the
domain), then the target list is initialized to contain the next-hop
component. If an (S,G) entry exists for the same G for which the
(*,G) Join is being processed, and the next-hop peers toward S and
the nominal root of G are different, the BGMP router must first send
a (S,G) Prune message toward the source and clear the SPT bit on the
(S,G) entry, before activating the (*,G) entry.
When creating (S,G) state, if the source is internal to the BGMP
speaker’s domain, a "Poison-Reverse" bit (PR-bit) is set. This bit
indicates that the router may receive packets matching (S,G) anyway
due to the BGMP speaker being a member of a domain on the path
between S and the root domain. (Depending on the M-IGP protocol, it
may in fact receive such packets anyway only if it is the best exit
for the nominal root of G.)
The target from which the Join was received is then added to the
target list. The router then looks up S or the nominal root of G in
the Multicast RIB to find the next-hop EGP peer. If the target list,
not including the next-hop target towards G for a (*,G) entry,
becomes non-null as a result, the next-hop EGP peer must be notified
as follows:
a) If the next-hop peer towards the nominal root of G (for a (*,G)
entry) is an external peer, a BGMP (*,G) Join message is unicast
to the external peer. If the next-hop peer towards S (for an
(S,G) entry) is an external peer, and the router does NOT have any
active (*,G) state for that group address G, a BGMP (S,G) Join
message is unicast to the external peer. A BGMP (S,G) Join
message is never sent to an external peer by a router that also
contains active (*,G) state for the same group. If the next-hop
peer towards S (for an (S,G entry) is an external peer and the
router DOES have active (*,G) state for that group G, the SPT bit
is always set to False.
b) If the next-hop peer is an internal peer, a (*,G) or (S,G) Join
alert is sent to the M-IGP component owning the next-hop
interface.
c) If there is no next-hop peer, a (*,G) or (S,G) Join alert is sent
to the M-IGP component owning the next-hop interface.
Finally, if an (S,G) Join is received from an internal peer, the peer
should be stored with the M-IGP component target. If (S,G) state
exists with the PR-bit set, and the next-hop towards the nominal root
for G is through the M-IGP component, an (S,G) Poison-Reverse message
is immediately sent to the internal peer.
If an (S,G) Join is received from an external peer, and (S,G) state
exists with the PR-bit set, and the local BGMP speaker is the best
exit for the nominal root of G, and the next-hop towards the nominal
root for G is through the interface towards the external peer, an
(S,G) Poison-Reverse message is immediately sent to the external
peer.
4.3.2. Receiving Prune Notifications
When the BGMP component receives a (*,G) or (S,G) Prune alert from
another component, or a BGMP (*,G) or (S,G) Prune message from an
external peer, it searches the tree state table for a matching entry.
If no (S,G) entry was found for an (S,G) Prune, but (*,G) state
exists, an (S,G) entry is created, with the target list copied from
the (*,G) entry. If no matching entry exists, or if the component or
peer is not listed in the target list, no further actions are taken.
Otherwise, the component or peer is removed from the target list. If
the target list becomes null as a result, the next-hop peer towards
the nominal root of G (for a (*,G) entry), or towards S (for an (S,G)
entry if and only if the BGMP router does NOT have any corresponding
(*,G) entry), must be notified as follows.
a) If the peer is an external peer, a BGMP (*,G) or (S,G) Prune
message is unicast to it.
b) If the next-hop peer is an internal peer, a (*,G) or (S,G) Prune
alert is sent to the M-IGP component owning the next-hop
interface.
c) If there is no next-hop peer, a (*,G) or (S,G) Prune alert is sent
to the M-IGP component owning the next-hop interface.
4.3.3. Receiving Route Change Notifications
When a border router receives a route for a new prefix in the
multicast RIB, or a existing route for a prefix is withdrawn, a route
change notification for that prefix must be sent to the BGMP
component. In addition, when the next hop peer (according to the
multicast RIB) changes, a route change notification for that prefix
must be sent to the BGMP component.
In addition, in IPv4 (only), an internal route for each class-D
prefix associated with the domain (if any) MUST be injected into the
multicast RIB in the EGP by the domain’s border routers.
When a route for a new group prefix is learned, or an existing route
for a group prefix is withdrawn, or the next-hop peer for a group
prefix changes, a BGMP router updates all affected (*,G) target
lists. The router sends a (*,G) Join to the new next-hop target, and
a (*,G) Prune to the old next-hop target, as appropriate. In
addition, if any (S,G) state exists with the PR-bit set:
o If the BGMP speaker has just become the best exit for the nominal
root of G, an (S,G) Poison Reverse message with the PR-bit set is
sent as noted below.
o If the BGMP speaker was the best exit for the nominal root of G
and is no longer, an (S,G) Poison Reverse message with the PR-bit
clear is sent as noted below.
The (S,G) Poison-Reverse messages are sent to all external peers on
the next-hop interface towards the nominal root of G from which (S,G)
Joins have been received.
When an existing route for a source prefix is withdrawn, or the
next-hop peer for a source prefix changes, a BGMP router updates all
affected (S,G) target lists. The router sends a (S,G) Join to the
new next-hop target, and a (S,G) Prune to the old next-hop target, as
appropriate.
4.3.4. Receiving (S,G) Poison-Reverse messages
When a BGMP speaker receives an (S,G) Poison-Reverse message from a
peer, it sets the PR-bit on the (S,G) state to match the PR-bit in
the message, and looks up the next-hop towards the nominal root of G.
If the next-hop target is an M-IGP component, it forwards the (S,G)
Poison Reverse message to all internal peers of that component from
which it has received (S,G) Joins. If the next-hop target is an
external peer on a given interface, it forwards the (S,G) Poison
Reverse message to all external peers on that interface.
When a BGMP speaker receives an (S,G) Poison-Reverse message from an
external peer, with the PR-bit set, and the speaker has received no
(S,G) Joins from any other peers (e.g., only from the M-IGP, or has
(S,G) state due to encapsulation as described in 5.4.1), it knows
that its own (S,G) Join is unnecessary, and should send an (S,G)
Prune.
When a BGMP speaker receives an (S,G) Poison-Reverse message from an
internal peer, with the PR-bit set, and the speaker is the best exit
for the nominal root of G, and has (S,G) prune state, an (S,G) Join
message is sent to cancel the prune state and the state is deleted.
4.4. Interaction with M-IGP components
When an M-IGP component on a border router first learns that there
are internally-reached members for a group G (whose scope is larger
than that domain), a (*,G) Join alert is sent to the BGMP component.
Similarly, when an M-IGP component on a border router learns that
there are no longer internally-reached members for a group G (whose
scope is larger than a single domain), a (*,G) Prune alert is sent to
the BGMP component.
At any time, any M-IGP domain MAY decide to join a source-specific
branch for some external source S and group G. When the M-IGP
component in the border router that is the next-hop router for a
particular source S learns that a receiver wishes to receive data
from S on a source-specific path, an (S,G) Join alert is sent to the
BGMP component. When it is learned that such receivers no longer
exist, an (S,G) Prune alert is sent to the BGMP component. Recall
that the BGMP component will generate external source-specific Joins
only where the source-specific branch does not coincide with the
shared tree distribution tree for that group.
Finally, we will require that the border router that is the next-hop
internal peer for a particular address S or the nominal root of G be
able to forward data for a matching tree state table entry to all
members within the domain. This requirement has implications on
specific M-IGPs as follows.
4.4.1. Interaction with DVMRP and PIM-DM
DVMRP and PIM-DM are both "broadcast and prune" protocols in which
every data packet must pass an RPF check against the packet’s source
address, or be dropped. If the border router receiving packets from
an external source is the only BR to inject the route for the source
into the domain, then there are no problems. For example, this will
always be true for stub domains with a single border router (see
Figure 1). Otherwise, the border router receiving packets externally
is responsible for encapsulating the data to any other border routers
that must inject the data into the domain for RPF checks to succeed.
When an intended border router injector for a source receives
encapsulated packets from another border router in its domain, it
should create source-specific (S,G) BGMP state. Note that the border
router may be configured to do this on a data-rate triggered basis so
that the state is not created for very low data-rate/intermittent
sources. If source-specific state is created, then its incoming
interface points to the virtual encapsulation interface from the
border router that forwarded the packet, and it has an SPT flag that
is initialized to be False.
When the (S,G) BGMP state is created, the BGMP component will in turn
send a BGMP (S,G) Join message to the next-hop external peer towards
S if there is no (*,G) state for that same group, G. The (S,G) BGMP
state will have the SPT bit set to False if (*,G) BGMP state is
present.
When the first data packet from S arrives from the external peer and
matches on the BGMP (S,G) state, and IF there is no (*,G) state, the
router sets the SPT flag to True, resets the incoming interface to
point to the external peer, and sends a BGMP (S,G) Prune message to
the border router that was encapsulating the packets (e.g., in Figure
1, BR11 sends the (Src_A,G) Prune to BR12). When the border router
with (*,G) state receives the prune for (S,G), it then deletes that
border router from its list of targets.
If the decapsulator receives a (S,G) Poison Reverse message with the
PR-bit set, it will forward it to the encapsulator (which may again
forward it up the shared tree according to normal BGMP rules), and
both will delete their BGMP (S,G) state.
PIM-DM and DVMRP present an additional problem, i.e., no protocol
mechanism exists for joining and pruning entire groups; only joins
and prunes for individual sources are available. As a result, BGMP
does not currently support such protocols being used in a transit
domain.
4.4.2. Interaction with PIM-SM
Protocols such as PIM-SM build unidirectional shared and source-
specific trees. As with DVMRP and PIM-DM, every data packet must
pass an RPF check against some group-specific or source-specific
address.
The fewest encapsulations/decapsulations will be done when the
intra-domain tree is rooted at the next-hop internal peer (which
becomes the RP) towards the nominal root of G, since in general that
router will receive the most packets from external sources. To
achieve this, each BGMP border router to a PIM-SM domain should send
Candidate-RP-Advertisements within the domain for those groups for
which it is the shared-domain tree ingress router. When the border
router that is the RP for a group G receives an external data packet,
it forwards the packet according to the M-IGP (i.e., PIM-SM) shared-
tree outgoing interface list.
Other border routers will receive data packets from external sources
that are farther down the bidirectional tree of domains. When a
border router that is not the RP receives an external packet for
which it does not have a source-specific entry, the border router
treats it like a local source by creating (S,G) state with a Register
flag set, based on normal PIM-SM rules; the Border router then
encapsulates the data packets in PIM-SM Registers and unicasts them
to the RP for the group. As explained above, the RP for the inter-
domain group will be one of the other border routers of the domain.
If a source’s data rate is high enough, DRs within the PIM-SM domain
may switch to the shortest path tree. If the shortest path to an
external source is via the group’s ingress router for the shared
tree, the new (S,G) state in the BGMP border router will not cause
BGMP (S,G) Joins because that border router will already have (*,G)
state. If however, the shortest path to an external source is via
some other border router, that border router will create (S,G) BGMP
state in response to the M-IGP (S,G) Join alert. In this case,
because there is no local (*,G) state to suppress it, the border
router will send a BGMP (S,G) Join to the next-hop external peer
towards S, in order to pull the data down directly. (See BR11 in
Figure 1). As in normal PIM-SM operation, those PIM-SM routers that
have (*,G) and (S,G) state pointing to different incoming interfaces
will prune that source off the shared tree. Therefore, all internal
interfaces may be eventually pruned off the internal shared tree.
After the border router sends a BGMP (S,G) Join, if its (S,G) state
has the PR-bit clear, a (S,G) Poison-Reverse message (with the PR-bit
clear) is sent to the ingress router for G. The ingress router then
creates (S,G) if it does not already exist, and removes the next hop
towards the nominal root of G from the target list.
If the border router later receives an (S,G) Poison-Reverse message
with the PR-bit set, the Poison-Reverse message is forwarded to the
ingress router for G. The best-exit router then creates (S,G) state
if it does not already exist, and puts the next hop towards the
nominal root of G in the target list if not already present.
4.4.3. Interaction with CBT
CBT builds bidirectional shared trees but must address two points of
compatibility with BGMP. First, CBT can not accommodate more than
one border router injecting a packet. Therefore, if a CBT domain
does have multiple external connections, the M-IGP components of the
border routers are responsible for insuring that only one of them
will inject data from any given source.
Second, CBT cannot process source-specific Joins or Prunes. Two
options thus exist for each CBT domain:
Option A:
The CBT component interprets a (S,G) Join alert as if it were an
(*,G) Join alert, as described in [INTEROP]. That is, if it is
not already on the core-tree for G, then it sends a CBT (*,G)
JOIN-REQUEST message towards the core for G. Similarly, when the
CBT component receives an (S,G) Prune alert, and the child
interface list for a group is NULL, then it sends a (*,G)
QUIT_NOTIFICATION towards the core for G. This option has the
disadvantage of pulling all data for the group G down to the CBT
domain when no members exist.
Option B:
The CBT domain does not propagate any routes to their external
peers for the Multicast RIB unless it is known that no other path
exists to that prefix (e.g., routes for prefixes internal to the
domain or in a singly-homed customer’s domain may be propagated).
This insures that source-specific joins are never received unless
the source’s data already passes through the domain on the shared
tree, in which case the (S,G) Join need not be propagated anyway.
BGMP border routers will only send source-specific Joins or Prunes
to an external peer if that external peer advertises source-
prefixes in the EGP. If a BGMP-CBT border router does receive an
(S,G) Join or Prune, that border router should ignore the message.
To minimize en/de-capsulations, CBTv2 BR’s may follow the same scheme
as described under PIM-SM above, in which Candidate-Core
advertisements are sent for those groups for which it is the shared-
tree ingress router.
4.4.4. Interaction with MOSPF
As with CBTv2, MOSPF cannot process source-specific Joins or Prunes,
and the same two options are available. Therefore, an MOSPF domain
may either:
Option A:
send a Group-Membership-LSA for all of G in response to a (S,G)
Join alert, and "prematurely age" it out (when no other downstream
members exist) in response to an (S,G) Prune alert, OR
Option B:
not propagate any routes to their external peers for the Multicast
RIB unless it is known that no other path exists to that prefix
(e.g., routes for prefixes internal to the domain or in a singly-
homed customer’s domain may be propagated)
4.5. Operation over Multi-access Networks
Multiaccess links require special handling to prevent duplicates.
The following mechanism enables BGMP to operate over multiaccess
links which do not run an M-IGP. This avoids broadcast-and-prune
behavior and does not require (S,G) state.
To elect a designated forwarder per prefix, BGMP uses a FWDR_PREF
message to exchange "forwarder preference" values for each prefix.
The peer with the highest forwarder preference becomes the designated
forwarder, with ties broken by lowest BGMP Identifier. The
designated forwarder is the router responsible for forwarding packets
up the tree, and is the peer to which joins will be sent.
When BGMP first learns that a route exists in the multicast RIB whose
next-hop interface is NOT the multiaccess link, the BGMP router sends
a BGMP FWDR_PREF message for the prefix, to all BGMP peers on the
LAN. The FWDR_PREF message contains a "forwarder preference value"
for the local router, and the same value MUST be sent to all peers on
the LAN. Likewise, when the prefix is no longer reachable, a
FWDR_PREF of 0 is sent to all peers on the LAN.
Whenever a BGMP router calculates the next-hop peer towards a
particular address, and that peer is reached over a BGMP-owned
multiaccess LAN, the designated forwarder is used instead.
When a BGMP router receives a FWDR_PREF message from a peer, it looks
up the matching route in its multicast RIB, and calculates the new
designated forwarder. If the router has tree state entries whose
parent target was the old forwarder, it sends Joins to the new
forwarder and Prunes to the old forwarder.
When a BGMP router which is NOT the designated forwarder receives a
packet on the multiaccess link, it is silently dropped.
Finally, this mechanism prevents duplicates where full peering exists
on a "logical" link. Where full peering does not exist, steps must
be taken (outside of BGMP) to present separate logical interfaces to
BGMP, each of which is a link with full peering. This might entail,
for example, using different link-layer address mappings, doing
encapsulation, or changing the physical media.
4.6. Interaction between (S,G) state and G-routes
As discussed earlier, routers with (*,G) state will not propagate
(S,G) joins. However, a special case occurs when (S,G) state
coincides with the G-route (or route towards the nominal root of G).
When this occurs, care must be taken so that the data will reach the
root domain without causing duplicates or black holes. For this
reason, (S,G) state on the path between the source and the root
domain is annotated as being "poison-reversed". A PR-bit is kept for
this purpose, which is updated by (UN)POISON_REVERSE messages.
The PR-bit indicates to BGMP nodes whether they need to forward
packets up towards the root domain. For example, in a case where an
(S,G) branch exists, a transit domain may get packets along the (S,G)
branch, and needs to know whether to (also) forward them up towards
the root domain. If the domain in question is on the path between S
and the root domain, then the answer is yes (and the PR bit will be
set on the S,G state). If the domain in question is not on the path
between S and the root domain, then the answer is no (and the PR bit
will be clear on the S,G state).
5. Message Formats
This section describes message formats used by BGMP.
Messages are sent over a reliable transport protocol connection. A
message is processed only after it is entirely received. The maximum
message size is 4096 octets. All implementations are required to
support this maximum message size.
All fields labelled "Reserved" below must be transmitted as 0, and
ignored upon receipt.
5.1. Message Header Format
Each message has a fixed-size (4-byte) header. There may or may not
be a data portion following the header, depending on the message
type. The layout of these fields is shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length:
This 2-octet unsigned integer indicates the total length of the
message, including the header, in octets. Thus, e.g., it allows
one to locate in the transport-level stream the start of the next
message. The value of the Length field must always be at least 4
and no greater than 4096, and may be further constrained,
depending on the message type. No "padding" of extra data after
the message is allowed, so the Length field must have the smallest
value required given the rest of the message.
Type:
This 1-octet unsigned integer indicates the type code of the
message. The following type codes are defined:
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
5.2. OPEN Message Format
After a transport protocol connection is established, the first
message sent by each side is an OPEN message. If the OPEN message is
acceptable, a KEEPALIVE message confirming the OPEN is sent back.
Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION
messages may be exchanged.
In addition to the fixed-size BGMP header, the OPEN message contains
the following fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Rsvd| AddrFam | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGMP Identifier (variable length) |