draft-ietf-bgmp-spec-00.txt   draft-ietf-bgmp-spec-01.txt 
BGMP Working Group D. Thaler BGMP Working Group D. Thaler
Internet Engineering Task Force Microsoft Internet Engineering Task Force Microsoft
INTERNET-DRAFT D. Estrin INTERNET-DRAFT D. Estrin
January 10, 2000 USC/ISI March 10, 2000 USC/ISI
Expires July 2000 D. Meyer Expires September 2000 D. Meyer
Cisco Cisco
Editors Editors
Border Gateway Multicast Protocol (BGMP): Border Gateway Multicast Protocol (BGMP):
Protocol Specification Protocol Specification
<draft-ietf-bgmp-spec-00.txt> <draft-ietf-bgmp-spec-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
1. Acknowledgements 1. Acknowledgements
In addition to the editors, the following individuals have In addition to the editors, the following individuals have
contributed to the design of BGMP: Cengiz Alaettinoglu, Tony contributed to the design of BGMP: Cengiz Alaettinoglu, Tony
Ballardie, Steve Casner, Steve Deering, Dino Farinacci, Bill Fenner, Ballardie, Steve Casner, Steve Deering, Dino Farinacci, Bill Fenner,
Mark Handley, Ahmed Helmy, Van Jacobson, and Satish Kumar. Mark Handley, Ahmed Helmy, Van Jacobson, and Satish Kumar.
This document is the product of the IETF IDMR Working Group with Dave This document is the product of the IETF BGMP Working Group with Dave
Thaler, Deborah Estrin, and David Meyer as editors. Thaler, Deborah Estrin, and David Meyer as editors.
Rusty Eddy also provided valuable feedback on this document. Rusty Eddy, Isidor Kouvelas, and Pavlin Radoslavov also provided
valuable feedback on this document.
2. Purpose 2. Purpose
It has been suggested that inter-domain multicast is better supported It has been suggested that inter-domain multicast is better supported
with a rendezvous mechanism whereby members receive source's data with a rendezvous mechanism whereby members receive source's data
packets without any sort of global broadcast (e.g., DVMRP and PIM-DM packets without any sort of global broadcast (e.g., DVMRP and PIM-DM
broadcast initial data packets and MOSPF broadcasts membership broadcast initial data packets and MOSPF broadcasts membership
information). CBT [CBT] and PIM-SM [PIMSM] use a shared group-tree, information). CBT [CBT] and PIM-SM [PIMSM] use a shared group-tree,
to which all members join and thereby hear from all sources (and to to which all members join and thereby hear from all sources (and to
which non-members do not join and thereby hear from no sources). which non-members do not join and thereby hear from no sources).
skipping to change at page 3, line 26 skipping to change at page 3, line 28
packets (e.g., by packet classifiers, diagnostic utilities, etc.) packets (e.g., by packet classifiers, diagnostic utilities, etc.)
Two BGMP peers form a TCP connection between one another, and Two BGMP peers form a TCP connection between one another, and
exchange messages to open and confirm the connection parameters. exchange messages to open and confirm the connection parameters.
They then send incremental Join/Prune Updates as group memberships They then send incremental Join/Prune Updates as group memberships
change. BGMP does not require periodic refresh of individual change. BGMP does not require periodic refresh of individual
entries. KeepAlive messages are sent periodically to ensure the entries. KeepAlive messages are sent periodically to ensure the
liveness of the connection. Notification messages are sent in liveness of the connection. Notification messages are sent in
response to errors or special conditions. If a connection encounters response to errors or special conditions. If a connection encounters
an error condition, a notification message is sent and the connection an error condition, a notification message is sent and the connection
is closed. is closed if the error is a fatal one.
3. Terminology 3. Terminology
This document uses the following technical terms: This document uses the following technical terms:
Domain: Domain:
A set of one or more contiguous links and zero or more routers A set of one or more contiguous links and zero or more routers
surrounded by one or more multicast border routers. Note that this surrounded by one or more multicast border routers. Note that this
loose definition of domain also applies to an external link between loose definition of domain also applies to an external link between
two domains, as well as an exchange. two domains, as well as an exchange.
skipping to change at page 4, line 36 skipping to change at page 4, line 36
External peer: External peer:
A border router in another multicast AS (autonomous system, as used A border router in another multicast AS (autonomous system, as used
in BGP), to which a BGMP TCP-connection is open. Assuming MBGP is in BGP), to which a BGMP TCP-connection is open. Assuming MBGP is
being used, a separate "eBGP" TCP-connection will also be open to being used, a separate "eBGP" TCP-connection will also be open to
the same peer. the same peer.
Internal peer: Internal peer:
Another border router of the same multicast AS. A border router Another border router of the same multicast AS. A border router
either speaks iBGP ("internal" BGP) directly to internal peers in a either speaks iBGP ("internal" BGP) directly to internal peers in a
full mesh, or indirectly through a route reflector [REFLECT]. A full mesh, or indirectly through a route reflector [REFLECT].
border router is only required to establish a BGMP TCP-connection
to an internal peer when one border router acts as as a data
injector for another.
Next-hop peer: Next-hop peer:
The next-hop peer towards a given IP address is the next EGP router The next-hop peer towards a given IP address is the next EGP router
on the path to the given address, according to multicast RIB routes on the path to the given address, according to multicast RIB routes
in the EGP's routing table (e.g., in MBGP, routes whose Subsequent in the EGP's routing table (e.g., in MBGP, routes whose Subsequent
Address Family Identifier field indicates that the route is valid Address Family Identifier field indicates that the route is valid
for multicast traffic). for multicast traffic).
target: target:
Either an EGP peer, or an M-IGP component. Either an EGP peer, or an M-IGP component.
skipping to change at page 8, line 33 skipping to change at page 8, line 30
routers perform. We assume that each border router conforms to the routers perform. We assume that each border router conforms to the
component-based model described in [INTEROP]. component-based model described in [INTEROP].
5.1. Interaction with the EGP 5.1. Interaction with the EGP
A fundamental requirement imposed by BGMP on the design of an EGP is A fundamental requirement imposed by BGMP on the design of an EGP is
that it be able to carry multicast prefixes. For example, a multi- that it be able to carry multicast prefixes. For example, a multi-
protocol BGP (MBGP) must be able to carry a multicast prefix in the protocol BGP (MBGP) must be able to carry a multicast prefix in the
Unicast Network Layer Reachability Information (NLRI) field of the Unicast Network Layer Reachability Information (NLRI) field of the
UPDATE message (i.e., either an IPv4 class D prefix or an IPv6 prefix UPDATE message (i.e., either an IPv4 class D prefix or an IPv6 prefix
with high-order octet equal to FF [IPv6MAA]). This capability is with high-order octet equal to FF [IPv6AA]). This capability is
required by BGMP in the implementation of bi-directional trees; BGMP required by BGMP in the implementation of bi-directional trees; BGMP
must be able to forward data and control packets to the next hop must be able to forward data and control packets to the next hop
towards either a unicast source S or a multicast group G (see section towards either a unicast source S or a multicast group G (see section
5.2). It is also required that the path attributes defined in 5.2). It is also required that the path attributes defined in [BGP]
[RFC1771] have the same semantics whether they are accompany unicast have the same semantics whether they are accompany unicast or
or multicast NLRI. multicast NLRI.
MBGP [MBGP] satisfies the requirement described above. [MBGP] defines MBGP [MBGP] satisfies the requirement described above. MBGP defines
the optional transitive attributes Multiprotocol Reachable NLRI the optional transitive attributes Multiprotocol Reachable NLRI
(MP_REACH_NLRI) and Multiprotocol Unreachable (MP_UNREACH_NRLI) to (MP_REACH_NLRI) and Multiprotocol Unreachable (MP_UNREACH_NRLI) to
carry sets of reachable or unreachable destinations, and the carry sets of reachable or unreachable destinations, and the
appropriate next hop in the case of MP_REACH_NLRI. These attributes appropriate next hop in the case of MP_REACH_NLRI. These attributes
contain an Address Family Information field [RFC1700] which indicates contain an Address Family Information field [RFC1700] which indicates
the type of NLRI carried in the attribute. In addition, the attribute the type of NLRI carried in the attribute. In addition, the attribute
carries another field, the Subsequent Address Family Identifier, or carries another field, the Subsequent Address Family Identifier, or
SAFI, which can be used to provide additional information about the SAFI, which can be used to provide additional information about the
type of NLRI. For example, SAFI value two indicates that the NLRI is type of NLRI. For example, SAFI value two indicates that the NLRI is
valid for multicast forwarding. BGMP's requirement can be satisfied valid for multicast forwarding. BGMP's requirement can be satisfied
by allowing the NLRI field of the MP_REACH_NLRI (or MP_UNREACH_NLRI) by allowing the NLRI field of the MP_REACH_NLRI (or MP_UNREACH_NLRI)
to carry a multicast prefix in the Prefix field of the NLRI encoding. to carry a multicast prefix in the Prefix field of the NLRI encoding.
Finally, while not required for correct BGMP operation, the design of Finally, while not required for correct BGMP operation, the design of
an EGP should also provide a mechanism that allows discrimination an EGP should also provide a mechanism that allows discrimination
between NLRI that is to be used for unicast forwarding and NLRI to be between NLRI that is to be used for unicast forwarding and NLRI to be
used for multicast forwarding. This property is required to support used for multicast forwarding. This property is required to support
multicast-specific policy. As mentioned above, MBGP [MBGP] has this multicast-specific policy. As mentioned above, MBGP has this
capability. capability.
5.2. Multicast Data Packet Processing 5.2. Multicast Data Packet Processing
For BGMP rules to be applied, an incoming packet must first be For BGMP rules to be applied, an incoming packet must first be
"accepted": "accepted":
o If the packet arrived on an interface owned by an M-IGP, the M-IGP o If the packet arrived on an interface owned by an M-IGP, the M-IGP
component determines whether the packet should be accepted or component determines whether the packet should be accepted or
dropped according to its rules. If the packet is accepted, the dropped according to its rules. If the packet is accepted, the
skipping to change at page 10, line 32 skipping to change at page 10, line 31
next-hop peer towards G, if it is an external peer. If the peer is next-hop peer towards G, if it is an external peer. If the peer is
internal, the target list is initialized to contain the M-IGP internal, the target list is initialized to contain the M-IGP
component owning the next-hop interface. If there is no next-hop component owning the next-hop interface. If there is no next-hop
peer (because G is inside the domain), then the target list is peer (because G is inside the domain), then the target list is
initialized to contain the next-hop component. If an (S,G) entry 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, exists for the same G for which the (*,G) Join is being processed,
and the next-hop peers toward S and G are different, the BGMP router and the next-hop peers toward S and G are different, the BGMP router
must first send a (S,G) Prune message toward the source and clear the 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. 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 G.)
The target from which the Join was received is then added to the The target from which the Join was received is then added to the
target list. The router then looks up S or G in the Multicast RIB to target list. The router then looks up S or G in the Multicast RIB to
find the next-hop EGP peer. If the target list, not including the 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 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: result, the next-hop EGP peer must be notified as follows:
a) If the next-hop peer towards G (for a (*,G) entry) is an external a) If the next-hop peer towards G (for a (*,G) entry) is an external
peer, a BGMP (*,G) Join message is unicast to the external peer. 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 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 peer, and the router does NOT have any active (*,G) state for that
skipping to change at page 11, line 12 skipping to change at page 11, line 18
entry) is an external peer and the router DOES have active (*,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. 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 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 alert is sent to the M-IGP component owning the next-hop
interface. interface.
c) If there is no next-hop peer, a (*,G) or (S,G) Join alert is sent 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. 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 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 G, and the next-hop towards G is through the
interface towards the external peer, an (S,G) Poison-Reverse
message is immediately sent to the external peer.
5.3.2. Receiving Prune Notifications 5.3.2. Receiving Prune Notifications
When the BGMP component receives a (*,G) or (S,G) Prune alert from 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 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. 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 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 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 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. peer is not listed in the target list, no further actions are taken.
skipping to change at page 12, line 13 skipping to change at page 12, line 32
must be sent to the BGMP component. must be sent to the BGMP component.
In addition, an internal route for each class-D prefix associated In addition, an internal route for each class-D prefix associated
with the domain (if any) MUST be injected into the multicast RIB in with the domain (if any) MUST be injected into the multicast RIB in
the EGP by the domain's border routers. the EGP by the domain's border routers.
When a route for a new group prefix is learned, or an existing route 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 for a group prefix is withdrawn, or the next-hop peer for a group
prefix changes, a BGMP router updates all affected (*,G) target prefix changes, a BGMP router updates all affected (*,G) target
lists. The router sends a (*,G) Join to the new next-hop target, and 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. 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 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 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 G from which (S,G) Joins have been
received.
When an existing route for a source prefix is withdrawn, or the next- 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 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 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 new next-hop target, and a (S,G) Prune to the old next-hop target, as
appropriate. appropriate.
5.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 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 G, and has (S,G) prune state, an (S,G) Join message is sent to
cancel the prune state and the state is deleted.
5.4. Interaction with M-IGP components 5.4. Interaction with M-IGP components
When an M-IGP component on a border router first learns that there 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 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. 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 Similarly, when an M-IGP component on a border router learns that
there are no longer internally-reached members for a group G (whose 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 scope is larger than a single domain), a (*,G) Prune alert is sent to
the BGMP component. the BGMP component.
skipping to change at page 13, line 16 skipping to change at page 14, line 25
DVMRP and PIM-DM are both "broadcast and prune" protocols in which 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 every data packet must pass an RPF check against the packet's source
address, or be dropped. If the border router receiving packets from 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 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 into the domain, then there are no problems. For example, this will
always be true for stub domains with a single border router (see always be true for stub domains with a single border router (see
Figure 1). Otherwise, the border router receiving packets externally Figure 1). Otherwise, the border router receiving packets externally
is responsible for encapsulating the data to any other border routers is responsible for encapsulating the data to any other border routers
that must inject the data into the domain for RPF checks to succeed. that must inject the data into the domain for RPF checks to succeed.
Although peering sessions to internal peers are normally not
required, in this situation, BGMP TCP-connections must exist between
such internal peers, and the "virtual" interfaces used for
encapsulation are owned by BGMP.
When an intended border router injector for a source receives When an intended border router injector for a source receives
encapsulated packets from another border router in its domain, it encapsulated packets from another border router in its domain, it
should create source-specific (S,G) BGMP state. Note that the border 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 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 that the state is not created for very low data-rate/intermittent
sources. If source-specific state is created, then its incoming sources. If source-specific state is created, then its incoming
interface points to the virtual encapsulation interface from the interface points to the virtual encapsulation interface from the
border router that forwarded the packet, and it has an SPT flag that border router that forwarded the packet, and it has an SPT flag that
is initialized to be False. is initialized to be False.
skipping to change at page 13, line 46 skipping to change at page 15, line 7
When the first data packet from S arrives from the external peer and 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 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 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 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 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 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 with (*,G) state receives the prune for (S,G), it then deletes that
border router from its list of targets. 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 PIM-DM and DVMRP present an additional problem, i.e., no protocol
mechanism exists for joining and pruning entire groups; only joins mechanism exists for joining and pruning entire groups; only joins
and prunes for individual sources are available. We therefore and prunes for individual sources are available. We therefore
require that some form of Domain-Wide Reports (DWRs) [DWR] are require that some form of Domain-Wide Reports (DWRs) [DWR] are
available within such domains. Such messages provide the ability to available within such domains. Such messages provide the ability to
join and prune an entire group across the domain. One simple join and prune an entire group across the domain. One simple
heuristic to approximate DWRs is to assume that if there are any heuristic to approximate DWRs is to assume that if there are any
internally-reached members, then at least one of them is a sender. internally-reached members, then at least one of them is a sender.
With this heuristic, the presense of any M-IGP (S,G) state for With this heuristic, the presense of any M-IGP (S,G) state for
internally-reached sources can be used instead. Sending a data internally-reached sources can be used instead. Sending a data
skipping to change at page 15, line 13 skipping to change at page 16, line 25
some other border router, that border router will create (S,G) BGMP 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, state in response to the M-IGP (S,G) Join alert. In this case,
because there is no local (*,G) state to supress it, the border because there is no local (*,G) state to supress it, the border
router will send a BGMP (S,G) Join to the next-hop external peer 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 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 Figure 1.) As in normal PIM-SM operation, those PIM-SM routers that
have (*,G) and (S,G) state pointing to different incoming interfaces have (*,G) and (S,G) state pointing to different incoming interfaces
will prune that source off the shared tree. Therefore, all internal will prune that source off the shared tree. Therefore, all internal
interfaces may be eventually pruned off the internal shared tree. 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 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 G in the
target list if not already present.
5.4.3. Interaction with CBT 5.4.3. Interaction with CBT
CBT builds bidirectional shared trees but must address two points of CBT builds bidirectional shared trees but must address two points of
compatibility with BGMP. First, CBT can not accommodate more than compatibility with BGMP. First, CBT can not accommodate more than
one border router injecting a packet. Therefore, if a CBT domain one border router injecting a packet. Therefore, if a CBT domain
does have multiple external connections, the M-IGP components of the does have multiple external connections, the M-IGP components of the
border routers are responsible for insuring that only one of them border routers are responsible for insuring that only one of them
will inject data from any given source. This mechanism is provided will inject data from any given source.
in [CBTDM].
Second, CBT cannot process source-specific Joins or Prunes. Two Second, CBT cannot process source-specific Joins or Prunes. Two
options thus exist for each CBT domain: options thus exist for each CBT domain:
Option A: Option A:
The CBT component interprets a (S,G) Join alert as if it were an 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 (*,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- 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 REQUEST message towards the core for G. Similarly, when the CBT
component receives an (S,G) Prune alert, and the child interface component receives an (S,G) Prune alert, and the child interface
skipping to change at page 17, line 29 skipping to change at page 19, line 6
When a BGMP router which is NOT the designated forwarder receives a When a BGMP router which is NOT the designated forwarder receives a
packet on the multiaccess link, it is silently dropped. packet on the multiaccess link, it is silently dropped.
Finally, this mechanism prevents duplicates where full peering exists Finally, this mechanism prevents duplicates where full peering exists
on a "logical" link. Where full peering does not exist, steps must on a "logical" link. Where full peering does not exist, steps must
be taken (outside of BGMP) to present separate logical interfaces to be taken (outside of BGMP) to present separate logical interfaces to
BGMP, each of which is a link with full peering. This might entail, BGMP, each of which is a link with full peering. This might entail,
for example, using different link-layer address mappings, doing for example, using different link-layer address mappings, doing
encapsulation, or changing the physical media. encapsulation, or changing the physical media.
5.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. 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.
6. Interaction with address allocation 6. Interaction with address allocation
6.1. Requirements for BGMP components 6.1. Requirements for BGMP components
Each border router must be able to determine (e.g., from MASC [MASC]) Each border router must be able to determine (e.g., from MASC [MASC])
which class-D prefixes (if any) belong to each domain in which an M- which class-D prefixes (if any) belong to each domain in which an M-
IGP component resides, so that it can inject routes for them into the IGP component resides, so that it can inject routes for them into the
routing table. routing table.
7. Transition Strategy 7. Transition Strategy
skipping to change at page 21, line 19 skipping to change at page 23, line 19
acceptable, a KEEPALIVE message confirming the OPEN is sent back. acceptable, a KEEPALIVE message confirming the OPEN is sent back.
Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION
messages may be exchanged. messages may be exchanged.
In addition to the fixed-size BGMP header, the OPEN message contains In addition to the fixed-size BGMP header, the OPEN message contains
the following fields: the following fields:
0 1 2 3 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 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 | Reserved | Hold Time | | Version | Rsvd| AddrFam | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGMP Identifier | | BGMP Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ (Optional Parameters) | + (Optional Parameters) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: Version:
This 1-octet unsigned integer indicates the protocol version number This 1-octet unsigned integer indicates the protocol version number
of the message. The current BGMP version number is 1. 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: Hold Time:
This 2-octet unsigned integer indicates the number of seconds that This 2-octet unsigned integer indicates the number of seconds that
the sender proposes for the value of the Hold Timer. Upon receipt 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 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 Timer by using the smaller of its configured Hold Time and the
Hold Time received in the OPEN message. The Hold Time MUST be Hold Time received in the OPEN message. The Hold Time MUST be
either zero or at least three seconds. An implementation may either zero or at least three seconds. An implementation may
reject connections on the basis of the Hold Time. The calculated reject connections on the basis of the Hold Time. The calculated
value indicates the maximum number of seconds that may elapse value indicates the maximum number of seconds that may elapse
between the receipt of successive KEEPALIVE, and/or UPDATE messages between the receipt of successive KEEPALIVE, and/or UPDATE messages
by the sender. by the sender.
BGMP Identifier: BGMP Identifier:
This 4-octet unsigned integer indicates the BGMP Identifier of the This 4-octet (for IPv4) or 16-octet (IPv6) unsigned integer
sender. A given BGMP speaker sets the value of its BGMP Identifier indicates the BGMP Identifier of the sender. A given BGMP speaker
to a globally-unique value assigned to that BGMP speaker (e.g., an sets the value of its BGMP Identifier to a globally-unique value
IPv4 address). The value of the BGMP Identifier is determined on assigned to that BGMP speaker (e.g., an IPv4 address). The value
startup and is the same for every BGMP session opened. of the BGMP Identifier is determined on startup and is the same for
every BGMP session opened.
Optional Parameters: Optional Parameters:
This field may contain a list of optional parameters, where each This field may contain a list of optional parameters, where each
parameter is encoded as a <Parameter Length, Parameter Type, parameter is encoded as a <Parameter Length, Parameter Type,
Parameter Value> triplet. The combined length of all optional Parameter Value> triplet. The combined length of all optional
parameters can be derived from the Length field in the message parameters can be derived from the Length field in the message
header. header.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
skipping to change at page 23, line 8 skipping to change at page 25, line 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication Code: Authentication Code:
This 1-octet unsigned integer indicates the authentication This 1-octet unsigned integer indicates the authentication
mechanism being used. Whenever an authentication mechanism is mechanism being used. Whenever an authentication mechanism is
specified for use within BGMP, three things must be included in specified for use within BGMP, three things must be included in
the specification: the specification:
- the value of the Authentication Code which indicates use of the - the value of the Authentication Code which indicates use of the
mechanism, - the form and meaning of the Authentication Data, and mechanism, and - the form and meaning of the Authentication Data.
- the algorithm for computing values of Marker fields.
Note that a separate authentication mechanism may be used in Note that a separate authentication mechanism may be used in
establishing the transport level connection. establishing the transport level connection.
Authentication Data: Authentication Data:
The form and meaning of this field is a variable-length field The form and meaning of this field is a variable-length field
depend on the Authentication Code. depend on the Authentication Code.
The minimum length of the OPEN message is 12 octets (including The minimum length of the OPEN message is 12 octets (including
skipping to change at page 25, line 5 skipping to change at page 27, line 16
EnTyp: EnTyp:
0 - All 1's Mask. The Mask field is 0 bytes long. 0 - All 1's Mask. The Mask field is 0 bytes long.
1 - Mask length included. The Mask field is 4 bytes long, and 1 - Mask length included. The Mask field is 4 bytes long, and
contains the mask length, in bits. contains the mask length, in bits.
2 - Full Mask included. The Mask field is the same length 2 - Full Mask included. The Mask field is the same length
as the Address field, and contains the full bitmask. as the Address field, and contains the full bitmask.
AddrFam: AddrFam:
The IANA-assigned address family number of the encoded prefix. The IANA-assigned address family number of the encoded prefix.
These include (among others):
Number Description
------ -----------
1 IP (IP version 4)
2 IPv6 (IP version 6)
Address: Address:
The address associated with the given prefix to be encoded. The The address associated with the given prefix to be encoded. The
length is determined based on the Address Family. length is determined based on the Address Family.
Mask: Mask:
The mask associated with the given prefix. The format (or absence) The mask associated with the given prefix. The format (or absence)
of this field is determined by the EnTyp field. of this field is determined by the EnTyp field.
Each attribute is of the form: Each attribute is of the form:
skipping to change at page 25, line 39 skipping to change at page 27, line 43
Length: Length:
The Length is the length of the entire attribute, including the The Length is the length of the entire attribute, including the
length, type, and data fields. If other attributes are nested length, type, and data fields. If other attributes are nested
within the data field, the length includes the size of all such within the data field, the length includes the size of all such
nested attributes. nested attributes.
Type: Type:
Types 128-255 are reserved for "optional" attributes. If a Types 128-255 are reserved for "optional" attributes. If a
required attribute is unrecognized, a NOTIFICATION will be sent and required attribute is unrecognized, a NOTIFICATION will be sent and
the connection will be closed. Unrecognized optional attributes the connection will be closed if the error is a fatal one.
are simply ignored. Unrecognized optional attributes are simply ignored.
0 - JOIN 0 - JOIN
1 - PRUNE 1 - PRUNE
2 - GROUP 2 - GROUP
3 - SOURCE 3 - SOURCE
4 - FWDR_PREF 4 - FWDR_PREF
5 - POISON_REVERSE
a) JOIN (Type Code 0) a) JOIN (Type Code 0)
The JOIN attribute indicates that all GROUP or SOURCE options The JOIN attribute indicates that all GROUP or SOURCE options
nested immediately within the JOIN option should be joined. nested immediately within the JOIN option should be joined.
0 1 2 3 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 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 | | Length | Type=0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 28, line 19 skipping to change at page 30, line 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Value | | Preference Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ... | Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preference Value A 32-bit non-negative integer. Preference Value A 32-bit non-negative integer.
Nested Attributes No JOIN, PRUNE, or FWDR_PREF attributes may be Nested Attributes No JOIN, PRUNE, or FWDR_PREF attributes may be
immediately nested within a FWDR_PREF immediately nested within a FWDR_PREF
attribute. 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 attribues in the document other than SOURCE
may be immediately nested within a
POISON_REVERSE
attribute.
8.4. Encoding examples 8.4. Encoding examples
Below are enumerated examples of how various updates are built using Below are enumerated examples of how various updates are built using
nested attributes, where A ( B ) denotes that attribute B is nested nested attributes, where A ( B ) denotes that attribute B is nested
within attribute A. within attribute A.
(*,G-prefix) Join: JOIN ( GROUP ) (*,G-prefix) Join: JOIN ( GROUP )
(*,G-prefix) Prune: PRUNE ( GROUP ) (*,G-prefix) Prune: PRUNE ( GROUP )
(S,G) Join towards S : GROUP ( JOIN ( SOURCE ) ) (S,G) Join towards S : GROUP ( JOIN ( SOURCE ) )
(S,G) Join cancelling prune towards G: GROUP ( JOIN ( SOURCE ) ) (S,G) Join cancelling prune towards G: GROUP ( JOIN ( SOURCE ) )
(S,G) Prune towards S: GROUP ( PRUNE ( SOURCE ) ) (S,G) Prune towards S: GROUP ( PRUNE ( SOURCE ) )
skipping to change at page 29, line 14 skipping to change at page 31, line 43
If the negotiated Hold Time interval is zero, then periodic KEEPALIVE If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
messages MUST NOT be sent. messages MUST NOT be sent.
A KEEPALIVE message consists of only a message header, and has a A KEEPALIVE message consists of only a message header, and has a
length of 4 octets. length of 4 octets.
8.6. NOTIFICATION Message Format 8.6. NOTIFICATION Message Format
A NOTIFICATION message is sent when an error condition is detected. A NOTIFICATION message is sent when an error condition is detected.
The BGMP connection is closed immediately after sending it. 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 In addition to the fixed-size BGMP header, the NOTIFICATION message
contains the following fields: contains the following fields:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error code | Error subcode | Data | |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: Error Code:
This 1-octet unsigned integer indicates the type of This 1-octet unsigned integer indicates the type of
NOTIFICATION. The following Error Codes have been defined: NOTIFICATION. The following Error Codes have been defined:
Error Code Symbolic Name Reference Error Code Symbolic Name Reference
1 Message Header Error Section 9.1 1 Message Header Error Section 9.1
2 OPEN Message Error Section 9.2 2 OPEN Message Error Section 9.2
skipping to change at page 30, line 8 skipping to change at page 32, line 44
6 Cease Section 9.7 6 Cease Section 9.7
Error subcode: Error subcode:
This 1-octet unsigned integer provides more specific This 1-octet unsigned integer provides more specific
information about the nature of the reported error. Each information about the nature of the reported error. Each
Error Error
Code may have one or more Error Subcodes associated with it. Code may have one or more Error Subcodes associated with it.
If no appropriate Error Subcode is defined, then a zero If no appropriate Error Subcode is defined, then a zero
(Unspecific) value is used for the Error Subcode field. (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: Message Header Error subcodes:
2 - Bad Message Length. 2 - Bad Message Length
3 - Bad Message Type. (MC)
3 - Bad Message Type
(MC)
OPEN Message Error subcodes: OPEN Message Error subcodes:
1 - Unsupported Version Number 1 - Unsupported Version
(MC)
4 - Unsupported Optional Parameter 4 - Unsupported Optional Parameter
5 - Authentication Failure 5 - Authentication Failure
(MC)
6 - Unacceptable Hold Time 6 - Unacceptable Hold Time
(MC)
7 - Unsupported Capability 7 - Unsupported Capability
(MC)
UPDATE Message Error subcodes: UPDATE Message Error subcodes:
1 - Malformed Attribute List 1 - Malformed Attribute List
2 - Unrecognized Well-known Attribute (MC)
2 - Unrecognized Attribute Type
5 - Attribute Length Error 5 - Attribute Length Error
10 - Invalid Prefix Field (MC)
10 - Invalid Address
11 - Invalid Mask
13 - Unrecognized Address Family
Data: Data:
This variable-length field is used to diagnose the reason for the This variable-length field is used to diagnose the reason for the
NOTIFICATION. The contents of the Data field depend upon the NOTIFICATION. The contents of the Data field depend upon the
Error Code and Error Subcode. See Section 9 below for more Error Code and Error Subcode. See Section 9 below for more
details. details.
Note that the length of the Data field can be determined from the Note that the length of the Data field can be determined from the
message Length field by the formula: message Length field by the formula:
Message Length = 6 + Data Length Message Length = 6 + Data Length
skipping to change at page 31, line 7 skipping to change at page 34, line 13
(including message header). (including message header).
9. BGMP Error Handling 9. BGMP Error Handling
This section describes actions to be taken when errors are detected This section describes actions to be taken when errors are detected
while processing BGMP messages. BGMP Error Handling is similar to while processing BGMP messages. BGMP Error Handling is similar to
that of BGP [BGP]. that of BGP [BGP].
When any of the conditions described here are detected, a When any of the conditions described here are detected, a
NOTIFICATION message with the indicated Error Code, Error Subcode, NOTIFICATION message with the indicated Error Code, Error Subcode,
and Data fields is sent, and the BGMP connection is closed. If no and Data fields is sent, and the BGMP connection is closed if the
Error Subcode is specified, then a zero must be used. 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 The phrase "the BGMP connection is closed" means that the transport
protocol connection has been closed and that all resources for that protocol connection has been closed and that all resources for that
BGMP connection have been deallocated. The remote peer is removed BGMP connection have been deallocated. The remote peer is removed
from the target list of all tree state entries. from the target list of all tree state entries.
Unless specified explicitly, the Data field of the NOTIFICATION Unless specified explicitly, the Data field of the NOTIFICATION
message that is sent to indicate an error is empty. message that is sent to indicate an error is empty.
9.1. Message Header error handling 9.1. Message Header error handling
skipping to change at page 37, line 11 skipping to change at page 40, line 21
stays in the Connect state. stays in the Connect state.
The Start event is ignored in the Connect state. The Start event is ignored in the Connect state.
In response to any other event (initiated by either system or In response to any other event (initiated by either system or
operator), the local system releases all BGMP resources associated operator), the local system releases all BGMP resources associated
with this connection and changes its state to Idle. with this connection and changes its state to Idle.
Active state: Active state:
In this state BGMP is trying to acquire a peer by initiating a In this state BGMP is trying to acquire a peer by listening for an
transport protocol connection. incoming transport protocol connection.
If the transport protocol connection succeeds, the local system If the transport protocol connection succeeds, the local system
clears the ConnectRetry timer, completes initialization, sends an clears the ConnectRetry timer, completes initialization, sends an
OPEN message to its peer, sets its Hold Timer to a large value, 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 and changes its state to OpenSent. A Hold Timer value of 4
minutes is suggested. minutes is suggested.
In response to the ConnectRetry timer expired event, the local In response to the ConnectRetry timer expired event, the local
system restarts the ConnectRetry timer, initiates a transport system restarts the ConnectRetry timer, initiates a transport
connection to other BGMP peer, continues to listen for a connection to other BGMP peer, continues to listen for a
skipping to change at page 40, line 27 skipping to change at page 43, line 39
NOTIFICATION message with Error Code Finite State Machine Error NOTIFICATION message with Error Code Finite State Machine Error
and changes its state to Idle. and changes its state to Idle.
Whenever BGMP changes its state from Established to Idle, it Whenever BGMP changes its state from Established to Idle, it
closes the BGMP (and transport-level) connection, releases all closes the BGMP (and transport-level) connection, releases all
resources associated with that connection, and deletes all routes resources associated with that connection, and deletes all routes
derived from that connection. derived from that connection.
12. Security Considerations 12. Security Considerations
Security issues are not discussed in this memo. BGMP uses TCP sessions for all network communication between peers. TCP
sessions may be secured through the use of IPsec [IPSEC].
13. Authors' Addresses 13. Authors' Addresses
Dave Thaler Dave Thaler
Department of Electrical Engineering and Computer Science Department of Electrical Engineering and Computer Science
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: dthaler@microsoft.com EMail: dthaler@microsoft.com
skipping to change at page 41, line 18 skipping to change at page 44, line 31
[BGP] [BGP]
Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
1771, March 1995. 1771, March 1995.
[MBGP] [MBGP]
Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol
Extensions for BGP-4", RFC 2283, February 1998. Extensions for BGP-4", RFC 2283, February 1998.
[CBT] [CBT]
Ballardie, A. J., "Core Based Trees (CBT) Multicast: Architectural Ballardie, A., "Core Based Trees (CBT version 2) Multicast
Overview and Specification", University College London, November Routing", RFC 2189, September 1997.
1994.
[CBTDM]
Ballardie, A., "Core Based Tree (CBT) Multicast Border Router
Specification" draft-ietf-idmr-cbt-br-spec-00.txt, October 1997.
[DVMRP] [DVMRP]
Pusateri, T., "Distance Vector Multicast Routing Protocol", draft- Pusateri, T., "Distance Vector Multicast Routing Protocol", draft-
ietf-idmr-dvmrp-v3-05.txt, October 1997. ietf-idmr-dvmrp-v3-09.txt, March 2000.
[DWR] [DWR]
Fenner, W., "Domain-Wide Reports", Work in progress. Fenner, W., "Domain-Wide Reports", draft-ietf-idmr-membership-
reports-04.txt, August 1999.
[INTEROP] [INTEROP]
Thaler, D., "Interoperability Rules for Multicast Routing Thaler, D., "Interoperability Rules for Multicast Routing
Protocols", draft-thaler-multicast-interop-01.txt, March 1997. Protocols", RFC 2715, October 1999.
[IPv6MAA] [IPSEC]
R. Hinden, S. Deering, "IPv6 Multicast Address Assignments", draft- Kent, S., and R. Atkinson, "Security Architecture for the Internet
ietf-ipngwg-multicast-assgn-04.txt, July 1997. Protocol", RFC 2401, November 1998.
[IPv6AA]
Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture",
RFC 2373, July 1998.
[ISSUES] [ISSUES]
Meyer, D., "Some Issues for an Inter-domain Multicast Routing Meyer, D., "Some Issues for an Inter-domain Multicast Routing
Protocol", draft-ietf-mboned-imrp-some-issues-02.txt, June 1997. Protocol", draft-ietf-mboned-imrp-some-issues-02.txt, June 1997.
[MASC] [MASC]
Estrin, D., Handley, M, and D. Thaler, "Multicast-Address-Set Estrin, D., Handley, M, and D. Thaler, "Multicast-Address-Set
advertisement and Claim mechanism", Work in Progress, June 1997. advertisement and Claim mechanism", draft-ietf-malloc-masc-05.txt,
July 2000.
[MOSPF] [MOSPF]
Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, March Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, March
1994. 1994.
[PIMDM] [PIMDM]
Estrin, et al., "Protocol Independent Multicast-Dense Mode (PIM- Estrin, et al., "Protocol Independent Multicast-Dense Mode (PIM-
DM): Protocol Specification", draft-ietf-idmr-pim-dm-spec-05.txt, DM): Protocol Specification", draft-ietf-idmr-pim-dm-spec-05.txt,
May 1997. May 1997.
[PIMSM] [PIMSM]
Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM-
SM): Protocol Specification", RFC 2117, June 1997. SM): Protocol Specification", RFC 2362, June 1998.
[REFLECT] [REFLECT]
Bates, T., and R. Chandra, "BGP Route Reflection: An alternative to Bates, T., and R. Chandra, "BGP Route Reflection: An alternative to
full mesh IBGP", RFC 1966, June 1996. full mesh IBGP", RFC 1966, June 1996.
[RFC1700] [RFC1700]
S. J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700, October S. J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700, October
1994. 1994.
[RFC1771]
Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771,
March 1995.
[RFC2119] [RFC2119]
S. Bradner, "Key words for use in RFCs to Indicate Requirement S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
15. Full Copyright Statement 15. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
skipping to change at page 43, line 31 skipping to change at page 46, line 45
3 Terminology ..................................................... 3 3 Terminology ..................................................... 3
4 Protocol Overview ............................................... 5 4 Protocol Overview ............................................... 5
4.1 Design Rationale .............................................. 6 4.1 Design Rationale .............................................. 6
5 Protocol Details ................................................ 8 5 Protocol Details ................................................ 8
5.1 Interaction with the EGP ...................................... 8 5.1 Interaction with the EGP ...................................... 8
5.2 Multicast Data Packet Processing .............................. 9 5.2 Multicast Data Packet Processing .............................. 9
5.3 BGMP processing of Join and Prune messages and notifications 5.3 BGMP processing of Join and Prune messages and notifications
.............................................................. 10 .............................................................. 10
5.3.1 Receiving Joins ............................................. 10 5.3.1 Receiving Joins ............................................. 10
5.3.2 Receiving Prune Notifications ............................... 11 5.3.2 Receiving Prune Notifications ............................... 11
5.3.3 Receiving Route Change Notifications ........................ 11 5.3.3 Receiving Route Change Notifications ........................ 12
5.4 Interaction with M-IGP components ............................. 12 5.3.4 Receiving (S,G) Poison-Reverse messages ..................... 13
5.4.1 Interaction with DVMRP and PIM-DM ........................... 13 5.4 Interaction with M-IGP components ............................. 13
5.4.2 Interaction with PIM-SM ..................................... 14 5.4.1 Interaction with DVMRP and PIM-DM ........................... 14
5.4.3 Interaction with CBT ........................................ 15
5.4.4 Interaction with MOSPF ...................................... 16
5.5 Operation over Multi-access Networks .......................... 16
6 Interaction with address allocation ............................. 17
6.1 Requirements for BGMP components .............................. 17
7 Transition Strategy ............................................. 17
7.1 Preventing transit through the MBone stub ..................... 19
8 Message Formats ................................................. 20
8.1 Message Header Format ......................................... 20
8.2 OPEN Message Format ........................................... 21
8.3 UPDATE Message Format ......................................... 24
8.4 Encoding examples ............................................. 28
8.5 KEEPALIVE Message Format ...................................... 28
8.6 NOTIFICATION Message Format ................................... 29
9 BGMP Error Handling ............................................. 30 5.4.2 Interaction with PIM-SM ..................................... 15
9.1 Message Header error handling ................................. 31 5.4.3 Interaction with CBT ........................................ 16
9.2 OPEN message error handling ................................... 31 5.4.4 Interaction with MOSPF ...................................... 17
9.3 UPDATE message error handling ................................. 32 5.5 Operation over Multi-access Networks .......................... 18
9.4 NOTIFICATION message error handling ........................... 33 5.6 Interaction between (S,G) state and G-routes .................. 19
9.5 Hold Timer Expired error handling ............................. 33 6 Interaction with address allocation ............................. 19
9.6 Finite State Machine error handling ........................... 33 6.1 Requirements for BGMP components .............................. 19
9.7 Cease ......................................................... 33 7 Transition Strategy ............................................. 19
9.8 Connection collision detection ................................ 34 7.1 Preventing transit through the MBone stub ..................... 21
10 BGMP Version Negotiation ....................................... 35 8 Message Formats ................................................. 22
10.1 BGMP Capability Negotiation .................................. 35 8.1 Message Header Format ......................................... 22
11 BGMP Finite State machine ...................................... 35 8.2 OPEN Message Format ........................................... 23
12 Security Considerations ........................................ 40 8.3 UPDATE Message Format ......................................... 26
13 Authors' Addresses ............................................. 40 8.4 Encoding examples ............................................. 31
14 References ..................................................... 41 8.5 KEEPALIVE Message Format ...................................... 31
15 Full Copyright Statement ....................................... 42 8.6 NOTIFICATION Message Format ................................... 31
9 BGMP Error Handling ............................................. 34
9.1 Message Header error handling ................................. 34
9.2 OPEN message error handling ................................... 34
9.3 UPDATE message error handling ................................. 35
9.4 NOTIFICATION message error handling ........................... 36
9.5 Hold Timer Expired error handling ............................. 36
9.6 Finite State Machine error handling ........................... 36
9.7 Cease ......................................................... 37
9.8 Connection collision detection ................................ 37
10 BGMP Version Negotiation ....................................... 38
10.1 BGMP Capability Negotiation .................................. 38
11 BGMP Finite State machine ...................................... 39
12 Security Considerations ........................................ 43
13 Authors' Addresses ............................................. 43
14 References ..................................................... 44
15 Full Copyright Statement ....................................... 46
 End of changes. 53 change blocks. 
90 lines changed or deleted 194 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/