draft-ietf-bgmp-spec-01.txt   draft-ietf-bgmp-spec-02.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
March 10, 2000 USC/ISI November 22, 2000 USC/ISI
Expires September 2000 D. Meyer Expires May 2001 D. Meyer
Cisco Cisco
Editors Editors
Border Gateway Multicast Protocol (BGMP): Border Gateway Multicast Protocol (BGMP):
Protocol Specification Protocol Specification
<draft-ietf-bgmp-spec-01.txt> <draft-ietf-bgmp-spec-02.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.
Internet Drafts are valid for a maximum of six months and may be Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet Drafts as reference material or to cite inappropriate to use Internet Drafts as reference material or to cite
them other than as a "work in progress". them other than as a "work in progress".
The list of current Internet-Drafts can be accessed at To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes BGMP, a protocol for inter-domain multicast This document describes BGMP, a protocol for inter-domain multicast
routing. BGMP builds shared trees for active multicast groups, and routing. BGMP builds shared trees for active multicast groups, and
allows receiver domains to build source-specific, inter-domain, allows receiver domains to build source-specific, inter-domain,
distribution branches where needed. Building upon concepts from CBT and distribution branches where needed. Building upon concepts from CBT and
PIM-SM, BGMP requires that each multicast group be associated with a PIM-SM, BGMP requires that each multicast group be associated with a
single root (in BGMP it is referred to as the root domain). BGMP single root (in BGMP it is referred to as the root domain). BGMP
skipping to change at page 3, line 5 skipping to change at page 3, line 5
which non-members do not join and thereby hear from no sources). which non-members do not join and thereby hear from no sources).
This document describes BGMP, a protocol for inter-domain multicast This document describes BGMP, a protocol for inter-domain multicast
routing. BGMP builds shared trees for active multicast groups, and routing. BGMP builds shared trees for active multicast groups, and
allows domains to build source-specific, inter-domain, distribution allows domains to build source-specific, inter-domain, distribution
branches where needed. Building upon concepts from CBT and PIM-SM, branches where needed. Building upon concepts from CBT and PIM-SM,
BGMP requires that each global multicast group be associated with a BGMP requires that each global multicast group be associated with a
single root. However, in BGMP, the root is an entire exchange or single root. However, in BGMP, the root is an entire exchange or
domain, rather than a single router. domain, rather than a single router.
BGMP assumes that ranges of the class D space have been associated For non-source-specific groups, BGMP assumes that ranges of the class
(e.g., with MASC [MASC]) with selected domains. Each such domain D space have been associated (e.g., with MASC [MASC]) with selected
then becomes the root of the shared domain-trees for all groups in domains. Each such domain then becomes the root of the shared
its range. An address allocator will generally achieve better domain-trees for all groups in its range. An address allocator will
distribution trees if it takes its multicast addresses from its own generally achieve better distribution trees if it takes its multicast
domain's part of the space, thereby causing the root domain to be addresses from its own domain's part of the space, thereby causing
local. the root domain to be local.
BGMP uses TCP as its transport protocol. This eliminates the need to BGMP uses TCP as its transport protocol. This eliminates the need to
implement message fragmentation, retransmission, acknowledgement, and implement message fragmentation, retransmission, acknowledgement, and
sequencing. BGMP uses TCP port 264 for establishing its connections. sequencing. BGMP uses TCP port 264 for establishing its connections.
This port is distinct from BGP's port to provide protocol This port is distinct from BGP's port to provide protocol
independence, and to facilitate distinguishing between protocol independence, and to facilitate distinguishing between protocol
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.
skipping to change at page 5, line 34 skipping to change at page 5, line 34
BGMP routers build group-specific bidirectional forwarding state as BGMP routers build group-specific bidirectional forwarding state as
they process the BGMP Join messages. Bidirectional forwarding state they process the BGMP Join messages. Bidirectional forwarding state
means that packets received from any target are forwarded to all means that packets received from any target are forwarded to all
other targets in the target list without any RPF checks. No group- other targets in the target list without any RPF checks. No group-
specific state or traffic exists in parts of the network where there specific state or traffic exists in parts of the network where there
are no members of that group. are no members of that group.
BGMP routers build source-specific unidirectional forwarding state, BGMP routers build source-specific unidirectional forwarding state,
only where needed, to be compatible with source-specific trees (SPTs) only where needed, to be compatible with source-specific trees (SPTs)
used by some M-IGPs (e.g., DVMRP, PIM-DM, or PIM-SM). A domain that used by some M-IGPs (e.g., DVMRP, PIM-DM, or PIM-SM), or to construct
uses an SPT-based M-IGP may need to inject multicast packets from trees for source-specific groups. A domain that uses an SPT-based M-
external sources via different border routers (to be compatible with IGP may need to inject multicast packets from external sources via
the M-IGP RPF checks) which thus act as "surrogates". For example, different border routers (to be compatible with the M-IGP RPF checks)
in the Transit_1 domain, data from Src_A arrives at BR12, but must be which thus act as "surrogates". For example, in the Transit_1
injected by BR11. A surrogate router may create a source-specific domain, data from Src_A arrives at BR12, but must be injected by
BGMP branch if no shared tree state exists. Note: stub domains with BR11. A surrogate router may create a source-specific BGMP branch if
a single border router, such as Rcvr_Stub_7 in Figure 1, receive all no shared tree state exists. Note: stub domains with a single border
multicast data packets through that router, to which all RPF checks router, such as Rcvr_Stub_7 in Figure 1, receive all multicast data
point. Therefore, stub domains never build source-specific state. packets through that router, to which all RPF checks point.
Therefore, stub domains never build source-specific state.
Root_Domain Root_Domain
[BR91]--------------------------\ [BR91]--------------------------\
| | | |
[BR32] [BR41] [BR32] [BR41]
Transit_3 Transit_4 Transit_3 Transit_4
[BR31] [BR42] [BR43] [BR31] [BR42] [BR43]
| | | | | |
[BR22] [BR52] [BR53] [BR22] [BR52] [BR53]
Transit_2 Transit_5 Transit_2 Transit_5
skipping to change at page 7, line 28 skipping to change at page 7, line 29
bidirectional trees because it has to, and because it can without bidirectional trees because it has to, and because it can without
excessive cost. excessive cost.
(2) Source-specific distribution trees/branches (2) Source-specific distribution trees/branches
In a departure from other shared tree protocols, source-specific BGMP In a departure from other shared tree protocols, source-specific BGMP
state is built ONLY where (a) it is needed to pull the multicast state is built ONLY where (a) it is needed to pull the multicast
traffic down to a BGMP router that has source-specific (S,G) state, traffic down to a BGMP router that has source-specific (S,G) state,
and (b) that router is NOT already on the shared tree (i.e., has no and (b) that router is NOT already on the shared tree (i.e., has no
(*,G) state), and (c) that router does not want to receive packets (*,G) state), and (c) that router does not want to receive packets
via encapsulation from from a router which is on the shared tree. via encapsulation from a router which is on the shared tree. BGMP
BGMP provides source-specific branches because most M-IGP protocols provides source-specific branches because most M-IGP protocols in use
in use today build source-specific trees. BGMP's source-specific today build source-specific trees. BGMP's source-specific branches
branches eliminate the unnecessary overhead of encapsulations for eliminate the unnecessary overhead of encapsulations for high data
high data rate sources from the shared tree's ingress router to the rate sources from the shared tree's ingress router to the surrogate
surrogate injector (e.g. from BR12 to BR11 in Figure 1). Moreover, injector (e.g. from BR12 to BR11 in Figure 1). Moreover, cases in
cases in which shared paths are significantly longer than SPT paths which shared paths are significantly longer than SPT paths will also
will also benefit. benefit.
However, we do not build source-specific inter-domain trees in However, except for source-specific group distribution trees, we do
general because (a) inter-domain connectivity is generally less rich not build source-specific inter-domain trees in general because (a)
than intra-domain connectivity, so shared distribution trees should inter-domain connectivity is generally less rich than intra-domain
have more acceptible path length and traffic concentration properties connectivity, so shared distribution trees should have more
in the inter-domain context, than in the intra-domain case, and (b) acceptible path length and traffic concentration properties in the
by having the shared tree state always take precedence over source- inter-domain context, than in the intra-domain case, and (b) by
having the shared tree state always take precedence over source-
specific tree state, we avoid ambiguities that can otherwise arise. specific tree state, we avoid ambiguities that can otherwise arise.
In summary, BGMP trees are, in a sense, a hybrid between CBT and PIM- In summary, BGMP trees are, in a sense, a hybrid between CBT and PIM-
SM trees. SM trees.
(3) Method of choosing root of group shared tree (3) Method of choosing root of group shared tree
The choice of a group's shared-tree-root has implications for The choice of a group's shared-tree-root has implications for
performance and policy. In the intra-domain case it can be assumed performance and policy. In the intra-domain case it can be assumed
that all potential shared-tree roots (RPs/Cores) within the domain that all potential shared-tree roots (RPs/Cores) within the domain
are equally suited to be the root for a group that is initiated are equally suited to be the root for a group that is initiated
within that domain. In the INTER-domain case, there is far more within that domain. In the INTER-domain case, there is far more
opportunity for unacceptably poor locality, and administrative opportunity for unacceptably poor locality, and administrative
control of a group's shared-tree root. Therefore in the intra-domain control of a group's shared-tree root. Therefore in the intra-domain
case, other protocols treat all candidate roots (RPs or Cores) as case, other protocols treat all candidate roots (RPs or Cores) as
equivalent and emphasize load sharing and stability to maximize equivalent and emphasize load sharing and stability to maximize
performance. In the Inter-Domain case, all roots are not equivalent, performance. In the Inter-Domain case, all roots are not equivalent,
skipping to change at page 8, line 25 skipping to change at page 8, line 28
but is subject to administrative and performance input. but is subject to administrative and performance input.
5. Protocol Details 5. Protocol Details
In this section, we describe the detailed protocol that border In this section, we describe the detailed protocol that border
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 The fundamental requirements imposed by BGMP are that:
that it be able to carry multicast prefixes. For example, a multi-
(1) For a given source-specific group and source, BGMP must be able
to look up the next-hop towards the source in the Multicast RIB,
and
(2) For a given non-source-specific group, BGMP will map the group
address to a nominal "root" address, and must be able to look up
the next-hop towards that address in the Multicast RIB.
BGMP determines the nominal "root" address as follows. In IPv4, the
nominal root address is the group address itself. As a result, a
fundamental requirement for IPv4 imposed by BGMP on the design of an EGP
is 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 [IPv6AA]). This capability is with high-order octet equal to FF [IPv6AA]). This capability is required
required by BGMP in the implementation of bi-directional trees; BGMP by BGMP in the implementation of bi-directional trees; BGMP must be able
must be able to forward data and control packets to the next hop to forward data and control packets to the next hop towards either a
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 [BGP]
have the same semantics whether they are accompany unicast or
multicast NLRI.
MBGP [MBGP] satisfies the requirement described above. MBGP defines unicast source S or a multicast group G (see section 5.2). It is also
the optional transitive attributes Multiprotocol Reachable NLRI required that the path attributes defined in [BGP] have the same
(MP_REACH_NLRI) and Multiprotocol Unreachable (MP_UNREACH_NRLI) to semantics whether they are accompany unicast or multicast NLRI.
carry sets of reachable or unreachable destinations, and the
appropriate next hop in the case of MP_REACH_NLRI. These attributes
contain an Address Family Information field [RFC1700] which indicates
the type of NLRI carried in the attribute. In addition, the attribute
carries another field, the Subsequent Address Family Identifier, or
SAFI, which can be used to provide additional information about the
type of NLRI. For example, SAFI value two indicates that the NLRI is
valid for multicast forwarding. BGMP's requirement can be satisfied
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.
Finally, while not required for correct BGMP operation, the design of MBGP [MBGP] satisfies the requirement described above. MBGP defines the
an EGP should also provide a mechanism that allows discrimination optional transitive attributes Multiprotocol Reachable NLRI
between NLRI that is to be used for unicast forwarding and NLRI to be (MP_REACH_NLRI) and Multiprotocol Unreachable (MP_UNREACH_NRLI) to carry
used for multicast forwarding. This property is required to support sets of reachable or unreachable destinations, and the appropriate next
multicast-specific policy. As mentioned above, MBGP has this hop in the case of MP_REACH_NLRI. These attributes contain an Address
capability. Family Information field [RFC1700] which indicates the type of NLRI
carried in the attribute. In addition, the attribute carries another
field, the Subsequent Address Family Identifier, or SAFI, which can be
used to provide additional information about the type of NLRI. For
example, SAFI value two indicates that the NLRI is valid for multicast
forwarding. BGMP's requirement can be satisfied 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.
Finally, while not required for correct BGMP operation, the design of an
EGP should also provide a mechanism that allows discrimination between
NLRI that is to be used for unicast forwarding and NLRI to be used for
multicast forwarding. This property is required to support multicast-
specific policy. As mentioned above, MBGP has this capability.
For IPv6, this requirement can be avoided if unicast prefix-based group
addresses [V6PREFIX] are used. In this case, the nominal root address
is the subnet routers anycast address, using the prefix embedded in the
group address. Since this is a unicast address, no additional routes
are needed in the EGP for IPv6.
For example, if the IPv6 group address is
ff2e:0100:1234:5678:9abc:def0::123, then the unicast prefix is
1234:5678:9abc:def0/64, and the nominal root address would be
1234:5678:9abc:def0::.
To handle non-prefix-based group addresses, multicast routes would still
be needed. However, supporting such addresses may not be a requirement.
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
packet is forwarded (or not forwarded) out any other interfaces packet is forwarded (or not forwarded) out any other interfaces
owned by the same component, as specified by the M-IGP. owned by the same component, as specified by the M-IGP.
o If the packet was received over a point-to-point interface owned o If the packet was received over a point-to-point interface owned
by BGMP, the packet is accepted. by BGMP, the packet is accepted.
o If the packet arrived on a multiaccess network interface owned by o If the packet arrived on a multiaccess network interface owned by
BGMP, the packet is accepted if it is the designated forwarder for BGMP, the packet is accepted if it is receiving data on a source-
longest matching route for S, if it is receiving data on a source- specific branch, if it is the designated forwarder for the longest
specific branch, or for the longest matching route for G. matching route for S, or for the longest matching route for the
nominal root of G.
If the packet is accepted, then the router checks the tree state If the packet is accepted, then the router checks the tree state
table for a matching (S,G) entry. If one is found, but the packet table for a matching (S,G) entry. If one is found, but the packet
was not received from the next hop target towards S (if the entry's was not received from the next hop target towards S (if the entry's
SPT bit is True), or was not received from the next hop target SPT bit is True), or was not received from the next hop target
towards G (if the entry's SPT bit is False) then the packet is towards G (if the entry's SPT bit is False) then the packet is
dropped and no further actions are taken. If no (S,G) entry was dropped and no further actions are taken. If no (S,G) entry was
found, the router then checks for a matching (*,G) entry. found, the router then checks for a matching (*,G) entry.
If neither is found, then the packet is forwarded towards the next- If neither is found, then the packet is forwarded towards the next-
hop peer for G, according to the Multicast RIB. If a matching entry hop peer for the nominal root of G, according to the Multicast RIB.
was found, the packet is forwarded to all other targets in the target If a matching entry was found, the packet is forwarded to all other
list. targets in the target list.
Forwarding to a target which is an M-IGP component means that the Forwarding to a target which is an M-IGP component means that the
packet is forwarded out any interfaces owned by that component packet is forwarded out any interfaces owned by that component
according to that component's multicast forwarding rules. according to that component's multicast forwarding rules.
5.3. BGMP processing of Join and Prune messages and notifications 5.3. BGMP processing of Join and Prune messages and notifications
5.3.1. Receiving Joins 5.3.1. Receiving Joins
When the BGMP component receives a (*,G) or (S,G) Join alert from When the BGMP component receives a (*,G) or (S,G) Join alert from
another component, or a BGMP (S,G) or (*,G) Join message from an another component, or a BGMP (S,G) or (*,G) Join 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 an entry is found, and that peer is already listed in the target If an entry is found, and that peer is already listed in the target
list, then no further actions are taken. list, then no further actions are taken.
Otherwise, if no (*,G) or (S,G) entry was found, one is created. In Otherwise, if no (*,G) or (S,G) entry was found, one is created. In
the case of a (*,G), the target list is initialized to contain the the case of a (*,G), the target list is initialized to contain the
next-hop peer towards G, if it is an external peer. If the peer is next-hop peer towards the nominal root of G, if it is an external
internal, the target list is initialized to contain the M-IGP peer. If the peer is internal, the target list is initialized to
component owning the next-hop interface. If there is no next-hop contain the M-IGP component owning the next-hop interface. If there
peer (because G is inside the domain), then the target list is is no next-hop peer (because the nominal root of G is inside the
initialized to contain the next-hop component. If an (S,G) entry domain), then the target list is initialized to contain the next-hop
exists for the same G for which the (*,G) Join is being processed, component. If an (S,G) entry exists for the same G for which the
and the next-hop peers toward S and G are different, the BGMP router (*,G) Join is being processed, and the next-hop peers toward S and
must first send a (S,G) Prune message toward the source and clear the the nominal root of G are different, the BGMP router must first send
SPT bit on the (S,G) entry, before activating the (*,G) entry. 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 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 speaker's domain, a "Poison-Reverse" bit (PR-bit) is set. This bit
indicates that the router may receive packets matching (S,G) anyway 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 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 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 may in fact receive such packets anyway only if it is the best exit
for G.) for the nominal root of 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 the nominal root of G in
find the next-hop EGP peer. If the target list, not including the the Multicast RIB to find the next-hop EGP peer. If the target list,
next-hop target towards G for a (*,G) entry, becomes non-null as a not including the next-hop target towards G for a (*,G) entry,
result, the next-hop EGP peer must be notified as follows: becomes non-null as a 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 the nominal root of G (for a (*,G)
peer, a BGMP (*,G) Join message is unicast to the external peer. entry) is an external peer, a BGMP (*,G) Join message is unicast
If the next-hop peer towards S (for an (S,G) entry) is an external to the external peer. If the next-hop peer towards S (for an
peer, and the router does NOT have any active (*,G) state for that (S,G) entry) is an external peer, and the router does NOT have any
group address G, a BGMP (S,G) Join message is unicast to the active (*,G) state for that group address G, a BGMP (S,G) Join
external peer. A BGMP (S,G) Join message is never sent to an message is unicast to the external peer. A BGMP (S,G) Join
external peer by a router that also contains active (*,G) state message is never sent to an external peer by a router that also
for the same group. If the next-hop peer towards S (for an (S,G contains active (*,G) state for the same group. If the next-hop
entry) is an external peer and the router DOES have active (*,G) peer towards S (for an (S,G entry) is an external peer and the
state for that group G, the SPT bit is always set to False. 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 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 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) 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 state exists with the PR-bit set, and the next-hop towards the
through the M-IGP component, an (S,G) Poison-Reverse message is nominal root for G is through the M-IGP component, an (S,G)
immediately sent to the internal peer. Poison-Reverse message is immediately sent to the internal peer.
If an (S,G) Join is received from an external peer, and (S,G) 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 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 the best exit for the nominal root of G, and the next-hop towards
interface towards the external peer, an (S,G) Poison-Reverse the nominal root for G is through the interface towards the
message is immediately sent to the external peer. 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.
Otherwise, the component or peer is removed from the target list. If 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 G the target list becomes null as a result, the next-hop peer towards
(for a (*,G) entry), or towards S (for an (S,G) entry if and only if the nominal root of G (for a (*,G) entry), or towards S (for an (S,G)
the BGMP router does NOT have any corresponding (*,G) entry), must be entry if and only if the BGMP router does NOT have any corresponding
notified as follows. (*,G) entry), must be notified as follows.
a) If the peer is an external peer, a BGMP (*,G) or (S,G) Prune a) If the peer is an external peer, a BGMP (*,G) or (S,G) Prune
message is unicast to it. message is unicast to it.
b) If the next-hop peer is an internal peer, a (*,G) or (S,G) Prune 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 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) Prune alert is sent 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. to the M-IGP component owning the next-hop interface.
5.3.3. Receiving Route Change Notifications 5.3.3. Receiving Route Change Notifications
When a border router receives a route for a new prefix in the 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 multicast RIB, or a existing route for a prefix is withdrawn, a route
change notification for that prefix must be sent to the BGMP change notification for that prefix must be sent to the BGMP
component. In addition, when the next hop peer (according to the component. In addition, when the next hop peer (according to the
multicast RIB) changes, a route change notification for that prefix multicast RIB) changes, a route change notification for that prefix
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, in IPv4 (only), an internal route for each class-D
with the domain (if any) MUST be injected into the multicast RIB in prefix associated with the domain (if any) MUST be injected into the
the EGP by the domain's border routers. 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 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. In a (*,G) Prune to the old next-hop target, as appropriate. In
addition, if any (S,G) state exists with the PR-bit set: 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) o If the BGMP speaker has just become the best exit for the nominal
Poison Reverse message with the PR-bit set is sent as noted below. 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 G and is no longer, an o If the BGMP speaker was the best exit for the nominal root of G
(S,G) Poison Reverse message with the PR-bit clear is sent as and is no longer, an (S,G) Poison Reverse message with the PR-bit
noted below. clear is sent as noted below.
The (S,G) Poison-Reverse messages are sent to all external peers on 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 the next-hop interface towards the nominal root of G from which (S,G)
received. 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 5.3.4. Receiving (S,G) Poison-Reverse messages
When a BGMP speaker receives an (S,G) Poison-Reverse message from a 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 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 the message, and looks up the next-hop towards the nominal root of G.
target is an M-IGP component, it forwards the (S,G) Poison Reverse If the next-hop target is an M-IGP component, it forwards the (S,G)
message to all internal peers of that component from which it has Poison Reverse message to all internal peers of that component from
received (S,G) Joins. If the next-hop target is an external peer on which it has received (S,G) Joins. If the next-hop target is an
a given interface, it forwards the (S,G) Poison Reverse message to external peer on a given interface, it forwards the (S,G) Poison
all external peers on that interface. Reverse message to all external peers on that interface.
When a BGMP speaker receives an (S,G) Poison-Reverse message from an 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 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) 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 (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) that its own (S,G) Join is unnecessary, and should send an (S,G)
Prune. Prune.
When a BGMP speaker receives an (S,G) Poison-Reverse message from an 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 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 for the nominal root of G, and has (S,G) prune state, an (S,G) Join
cancel the prune state and the state is deleted. 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 14, line 9 skipping to change at page 14, line 42
component in the border router that is the next-hop router for a component in the border router that is the next-hop router for a
particular source S learns that a receiver wishes to receive data 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 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 BGMP component. When it is learned that such receivers no longer
exist, an (S,G) Prune alert is sent to the BGMP component. Recall exist, an (S,G) Prune alert is sent to the BGMP component. Recall
that the BGMP component will generate external source-specific Joins that the BGMP component will generate external source-specific Joins
only where the source-specific branch does not coincide with the only where the source-specific branch does not coincide with the
shared tree distribution tree for that group. shared tree distribution tree for that group.
Finally, we will require that the border router that is the next-hop Finally, we will require that the border router that is the next-hop
internal peer for a particular address S or G be able to forward data internal peer for a particular address S or the nominal root of G be
for a matching tree state table entry to all members within the able to forward data for a matching tree state table entry to all
domain. This requirement has implications on specific M-IGPs as members within the domain. This requirement has implications on
follows. specific M-IGPs as follows.
5.4.1. Interaction with DVMRP and PIM-DM 5.4.1. Interaction with DVMRP and PIM-DM
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
skipping to change at page 15, line 32 skipping to change at page 16, line 21
packet to a group is then equivalent to sending a DWR for the group. packet to a group is then equivalent to sending a DWR for the group.
5.4.2. Interaction with PIM-SM 5.4.2. Interaction with PIM-SM
Protocols such as PIM-SM build unidirectional shared and source- Protocols such as PIM-SM build unidirectional shared and source-
specific trees. As with DVMRP and PIM-DM, every data packet must specific trees. As with DVMRP and PIM-DM, every data packet must
pass an RPF check against some group-specific or source-specific pass an RPF check against some group-specific or source-specific
address. address.
The fewest encapsulations/decapsulations will be done when the intra- The fewest encapsulations/decapsulations will be done when the intra-
domain tree is rooted at the next-hop internal peer towards G (which domain tree is rooted at the next-hop internal peer (which becomes
becomes the RP), since in general that router will receive the most the RP) towards the nominal root of G, since in general that router
packets from external sources. To achieve this, each BGMP border will receive the most packets from external sources. To achieve
router to a PIM-SM domain should send Candidate-RP-Advertisements this, each BGMP border router to a PIM-SM domain should send
within the domain for those groups for which it is the shared-domain Candidate-RP-Advertisements within the domain for those groups for
tree ingress router. When the border router that is the RP for a which it is the shared-domain tree ingress router. When the border
group G receives an external data packet, it forwards the packet router that is the RP for a group G receives an external data packet,
according to the M-IGP (i.e., PIM-SM) shared-tree outgoing interface it forwards the packet according to the M-IGP (i.e., PIM-SM) shared-
list. tree outgoing interface list.
Other border routers will receive data packets from external sources Other border routers will receive data packets from external sources
that are farther down the bidirectional tree of domains. When a that are farther down the bidirectional tree of domains. When a
border router that is not the RP receives an external packet for border router that is not the RP receives an external packet for
which it does not have a source-specific entry, the border router 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 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 flag set, based on normal PIM-SM rules; the Border router then
encapsulates the data packets in PIM-SM Registers and unicasts them 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- 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. domain group will be one of the other border routers of the domain.
skipping to change at page 16, line 29 skipping to change at page 17, line 18
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 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 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 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 creates (S,G) if it does not already exist, and removes the next hop
towards G from the target list. towards the nominal root of G from the target list.
If the border router later receives an (S,G) Poison-Reverse message 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 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 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 if it does not already exist, and puts the next hop towards the
target list if not already present. nominal root of 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. will inject data from any given source.
skipping to change at page 19, line 10 skipping to change at page 19, line 44
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 5.6. Interaction between (S,G) state and G-routes
As discussed earlier, routers with (*,G) state will not propagate (S,G) As discussed earlier, routers with (*,G) state will not propagate (S,G)
joins. However, a special case occurs when (S,G) state coincides with 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 the G-route (or route towards the nominal root of G). When this occurs,
reach the root domain without causing duplicates or black holes. For care must be taken so that the data will reach the root domain without
this reason, (S,G) state on the path between the source and the root causing duplicates or black holes. For this reason, (S,G) state on the
domain is annotated as being "poison-reversed". A PR-bit is kept for path between the source and the root domain is annotated as being
this purpose, which is updated by (UN)POISON_REVERSE messages. "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]) For IPv4 (only), each border router must be able to determine (e.g.,
which class-D prefixes (if any) belong to each domain in which an M- from MASC [MASC]) which class-D prefixes (if any) belong to each
IGP component resides, so that it can inject routes for them into the domain in which an M-IGP component resides, so that it can inject
routing table. routes for them into the routing table.
7. Transition Strategy 7. Transition Strategy
There have been significant barriers to multicast deployment in There have been significant barriers to multicast deployment in
Internet backbones. While many of the problems with the current Internet backbones. While many of the problems with the current
DVMRP backbone (MBONE) have been documented in [ISSUES], most of DVMRP backbone (MBONE) have been documented in [ISSUES], most of
these problems require longer term engineering solutions. However, these problems require longer term engineering solutions. However,
there is much that can be done with existing technologies to enable there is much that can be done with existing technologies to enable
deployment and put in place an architecture that will enable a smooth deployment and put in place an architecture that will enable a smooth
transition to the next generation of inter-domain multicast routing transition to the next generation of inter-domain multicast routing
skipping to change at page 31, line 13 skipping to change at page 32, line 13
attribute. 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 root of G: GROUP ( JOIN ( SOURCE ) )
(S,G) Prune towards S: GROUP ( PRUNE ( SOURCE ) ) (S,G) Prune towards S: GROUP ( PRUNE ( SOURCE ) )
(S,G) Prune towards G: 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 (*,G) to (S,G): PRUNE ( GROUP ( JOIN ( SOURCE ) ) )
Switch from (S,G) to (*,G): JOIN ( GROUP ) Switch from (S,G) to (*,G): JOIN ( GROUP )
Initial (*,G) Join with S pruned: JOIN ( GROUP ( PRUNE ( SOURCE ) ) ) Initial (*,G) Join with S pruned: JOIN ( GROUP ( PRUNE ( SOURCE ) ) )
Forwarder preference announcement for G-prefix: FWDR_PREF ( GROUP ) Forwarder preference announcement for G-prefix: FWDR_PREF ( GROUP )
Forwarder preference announcement for S-prefix: FWDR_PREF ( SOURCE ) Forwarder preference announcement for S-prefix: FWDR_PREF ( SOURCE )
8.5. KEEPALIVE Message Format 8.5. KEEPALIVE Message Format
BGMP does not use any transport protocol-based keep-alive mechanism BGMP does not use any transport protocol-based keep-alive mechanism
to determine if peers are reachable. Instead, KEEPALIVE messages are to determine if peers are reachable. Instead, KEEPALIVE messages are
skipping to change at page 46, line 5 skipping to change at page 46, line 44
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.
[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.
[V6PREFIX]
Haberman, B., and D. Thaler, "Unicast-Prefix-based IPv6 Multicast
Addresses", draft-ietf-ipngwg-uni-based-mcast-00.txt, August 2000.
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
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
skipping to change at page 46, line 44 skipping to change at page 47, line 44
2 Purpose ......................................................... 2 2 Purpose ......................................................... 2
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 ............................... 12
5.3.3 Receiving Route Change Notifications ........................ 12 5.3.3 Receiving Route Change Notifications ........................ 13
5.3.4 Receiving (S,G) Poison-Reverse messages ..................... 13 5.3.4 Receiving (S,G) Poison-Reverse messages ..................... 13
5.4 Interaction with M-IGP components ............................. 13 5.4 Interaction with M-IGP components ............................. 14
5.4.1 Interaction with DVMRP and PIM-DM ........................... 14 5.4.1 Interaction with DVMRP and PIM-DM ........................... 15
5.4.2 Interaction with PIM-SM ..................................... 15 5.4.2 Interaction with PIM-SM ..................................... 16
5.4.3 Interaction with CBT ........................................ 16 5.4.3 Interaction with CBT ........................................ 17
5.4.4 Interaction with MOSPF ...................................... 17 5.4.4 Interaction with MOSPF ...................................... 18
5.5 Operation over Multi-access Networks .......................... 18 5.5 Operation over Multi-access Networks .......................... 18
5.6 Interaction between (S,G) state and G-routes .................. 19 5.6 Interaction between (S,G) state and G-routes .................. 19
6 Interaction with address allocation ............................. 19 6 Interaction with address allocation ............................. 20
6.1 Requirements for BGMP components .............................. 19 6.1 Requirements for BGMP components .............................. 20
7 Transition Strategy ............................................. 19 7 Transition Strategy ............................................. 20
7.1 Preventing transit through the MBone stub ..................... 21 7.1 Preventing transit through the MBone stub ..................... 22
8 Message Formats ................................................. 22 8 Message Formats ................................................. 23
8.1 Message Header Format ......................................... 22 8.1 Message Header Format ......................................... 23
8.2 OPEN Message Format ........................................... 23 8.2 OPEN Message Format ........................................... 24
8.3 UPDATE Message Format ......................................... 26 8.3 UPDATE Message Format ......................................... 27
8.4 Encoding examples ............................................. 31 8.4 Encoding examples ............................................. 32
8.5 KEEPALIVE Message Format ...................................... 31 8.5 KEEPALIVE Message Format ...................................... 32
8.6 NOTIFICATION Message Format ................................... 31 8.6 NOTIFICATION Message Format ................................... 32
9 BGMP Error Handling ............................................. 34 9 BGMP Error Handling ............................................. 35
9.1 Message Header error handling ................................. 34 9.1 Message Header error handling ................................. 35
9.2 OPEN message error handling ................................... 34 9.2 OPEN message error handling ................................... 35
9.3 UPDATE message error handling ................................. 35 9.3 UPDATE message error handling ................................. 36
9.4 NOTIFICATION message error handling ........................... 36 9.4 NOTIFICATION message error handling ........................... 37
9.5 Hold Timer Expired error handling ............................. 36 9.5 Hold Timer Expired error handling ............................. 37
9.6 Finite State Machine error handling ........................... 36 9.6 Finite State Machine error handling ........................... 37
9.7 Cease ......................................................... 37 9.7 Cease ......................................................... 38
9.8 Connection collision detection ................................ 37 9.8 Connection collision detection ................................ 38
10 BGMP Version Negotiation ....................................... 38 10 BGMP Version Negotiation ....................................... 39
10.1 BGMP Capability Negotiation .................................. 38 10.1 BGMP Capability Negotiation .................................. 39
11 BGMP Finite State machine ...................................... 39 11 BGMP Finite State machine ...................................... 40
12 Security Considerations ........................................ 43 12 Security Considerations ........................................ 44
13 Authors' Addresses ............................................. 43 13 Authors' Addresses ............................................. 44
14 References ..................................................... 44 14 References ..................................................... 45
15 Full Copyright Statement ....................................... 46 15 Full Copyright Statement ....................................... 47
 End of changes. 41 change blocks. 
158 lines changed or deleted 196 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/