draft-ietf-bgmp-spec-02.txt   draft-ietf-bgmp-spec-03.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
November 22, 2000 USC/ISI Expires December 2002
Expires May 2001 D. Meyer
Cisco
Editors
Border Gateway Multicast Protocol (BGMP): Border Gateway Multicast Protocol (BGMP):
Protocol Specification Protocol Specification
<draft-ietf-bgmp-spec-02.txt> <draft-ietf-bgmp-spec-03.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 draft documents valid for a maximum of six months
updated, replaced, or obsoleted by other documents at any time. It is and may be updated, replaced, or obsoleted by other documents at any
inappropriate to use Internet Drafts as reference material or to cite time. It is inappropriate to use Internet-Drafts as reference material
them other than as a "work in progress". or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see The list of current Internet-Drafts can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
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, optionally allows receiver domains to build source-specific, inter-
distribution branches where needed. Building upon concepts from CBT and domain, distribution branches where needed. BGMP natively supports
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
assumes that at any point in time, different ranges of the class D space
are associated (e.g., with MASC [MASC]) with different domains. Each of "source-specific multicast" (SSM). To also support "any-source
these domains then becomes the root of the shared domain-trees for all multicast" (ASM), BGMP requires that each multicast group be associated
groups in its range. Multicast participants will generally receive with a single root (in BGMP it is referred to as the root domain). It
better multicast service if the session initiator's address allocator requires that different ranges of the class D space are associated
selects addresses from its own domain's part of the space, thereby (e.g., with Unicast-Prefix-Based Multicast addressing) with different
causing the root domain to be local to at least one of the session domains. Each of these domains then becomes the root of the shared
participants. domain-trees for all groups in its range. Multicast participants will
generally receive better multicast service if the session initiator's
address allocator selects addresses from its own domain's part of the
space, thereby causing the root domain to be local to at least one of
the session participants.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2002). 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, Deborah Estrin, Dino
Mark Handley, Ahmed Helmy, Van Jacobson, and Satish Kumar. Farinacci, Bill Fenner, Mark Handley, Ahmed Helmy, Van Jacobson, Dave
Meyer, and Satish Kumar.
This document is the product of the IETF BGMP Working Group with Dave This document is the product of the IETF BGMP Working Group with Dave
Thaler, Deborah Estrin, and David Meyer as editors. Thaler as editor.
Rusty Eddy, Isidor Kouvelas, and Pavlin Radoslavov also provided Rusty Eddy, Isidor Kouvelas, and Pavlin Radoslavov also provided
valuable feedback on this document. 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 "any-source" multicast is
with a rendezvous mechanism whereby members receive source's data better supported with a rendezvous mechanism whereby members receive
packets without any sort of global broadcast (e.g., DVMRP and PIM-DM source's data packets without any sort of global broadcast (e.g.,
broadcast initial data packets and MOSPF broadcasts membership MSDP broadcasts source information, PIM-DM and DVMRP broadcast
information). CBT [CBT] and PIM-SM [PIMSM] use a shared group-tree, initial data packets, and MOSPF broadcasts membership information).
to which all members join and thereby hear from all sources (and to PIM-SM [PIMSM] and CBT [CBT] use a shared group-tree, to which all
which non-members do not join and thereby hear from no sources). members join and thereby hear from all sources (and to 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 natively supports "source-specific multicast" (SSM).
allows domains to build source-specific, inter-domain, distribution
branches where needed. Building upon concepts from CBT and PIM-SM, To also support "any-source multicast" (ASM), BGMP builds shared
BGMP requires that each global multicast group be associated with a trees for active multicast groups, and allows domains to build
single root. However, in BGMP, the root is an entire exchange or source-specific, inter-domain, distribution branches where needed.
domain, rather than a single router. Building upon concepts from PIM-SM and CBT, BGMP requires that each
global multicast group be associated with a single root. However, in
BGMP, the root is an entire exchange or domain, rather than a single
router.
For non-source-specific groups, BGMP assumes that ranges of the class For non-source-specific groups, BGMP assumes that ranges of the class
D space have been associated (e.g., with MASC [MASC]) with selected D space have been associated (e.g., with Unicast-Prefix-Based
domains. Each such domain then becomes the root of the shared Multicast [V4PREFIX,V6PREFIX] addressing) with selected domains.
domain-trees for all groups in its range. An address allocator will Each such domain then becomes the root of the shared domain-trees for
generally achieve better distribution trees if it takes its multicast all groups in its range. An address allocator will generally achieve
addresses from its own domain's part of the space, thereby causing better distribution trees if it takes its multicast addresses from
the root domain to be local. its own domain's part of the space, thereby causing 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.
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 if the error is a fatal one. is closed if the error is a fatal one.
3. Terminology 3. Revision History
29 June 2002 draft-01
(1) Removed all references to MASC and G-RIB. The current spec only
covers BGMP operation for source-specific groups, and any-source-
multicast using unicast prefix-based multicast addresses (for
both IPv4 and IPv6). No new routes of any type are needed in the
routing table.
(2) Removed section on transitioning away from using DVMRP as the
backbone to an AS-based multicast routing system with MBGP, as
this has already happened.
4. 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.
Root Domain: Root Domain:
skipping to change at page 4, line 11 skipping to change at page 4, line 32
data from each sender to the group, and functions as a rendezvous data from each sender to the group, and functions as a rendezvous
domain toward which member domains can send inter-domain joins, and domain toward which member domains can send inter-domain joins, and
to which sender domains can send data. to which sender domains can send data.
Multicast RIB: Multicast RIB:
The Routing Information Base, or routing table, used to calculate The Routing Information Base, or routing table, used to calculate
the "next-hop" towards a particular address for multicast traffic. the "next-hop" towards a particular address for multicast traffic.
Multicast IGP (M-IGP): Multicast IGP (M-IGP):
A generic term for any multicast routing protocol used for tree A generic term for any multicast routing protocol used for tree
construction within a domain. Typical examples of M-IGPs are: construction within a domain. Typical examples of M-IGPs are: PIM-
DVMRP, PIM-DM, PIM-SM, CBT, and MOSPF. SM, PIM-DM, DVMRP, MOSPF, and CBT.
EGP: A generic term for the interdomain unicast routing protocol in use. EGP: A generic term for the interdomain unicast routing protocol in use.
Typically, this will be some version of BGP which can support a Typically, this will be some version of BGP which can support a
Multicast RIB, such as MBGP [MBGP], containing both unicast and Multicast RIB, such as MBGP [MBGP], containing both unicast and
multicast address prefixes. multicast address prefixes.
Component: Component:
The portion of a border router associated with (and logically The portion of a border router associated with (and logically
inside) a particular domain that runs the multicast IGP (M-IGP) for inside) a particular domain that runs the multicast IGP (M-IGP) for
that domain, if any. Each border router thus has zero or more that domain, if any. Each border router thus has zero or more
components inside routing domains. In addition, each border router components inside routing domains. In addition, each border router
with external links that do not fall inside any routing domain will with external links that do not fall inside any routing domain will
have an inter-domain component that runs BGMP. have an inter-domain component that runs BGMP.
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. If BGP is being
being used, a separate "eBGP" TCP-connection will also be open to used as the EGP, a separate "eBGP" TCP-connection will also be open
the same peer. to 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. If BGP is being
either speaks iBGP ("internal" BGP) directly to internal peers in a used as the EGP, the border router either speaks iBGP ("internal"
full mesh, or indirectly through a route reflector [REFLECT]. BGP) directly to internal peers in a full mesh, or indirectly
through a route reflector [REFLECT].
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.
Tree State Table: Tree State Table:
This is a table of (S-prefix,G-prefix) entries (including (*,G- This is a table of (S-prefix,G) and (*,G-prefix) entries that have
prefix) entries) that have been explicitly joined by a set of been explicitly joined by a set of targets. Each entry has, in
targets. Each entry has, in addition to the source and group addition to the source and group addresses and masks, a list of
addresses and masks, a list of targets that have explicitly targets that have explicitly requested data (on behalf of directly
requested data (on behalf of directly connected hosts or downstream connected hosts or downstream routers). (S,G) entries also have an
routers). (S,G) entries also have an "SPT" bit. "SPT" bit.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
this document are to be interpreted as described in [RFC2119]. this document are to be interpreted as described in [RFC2119].
4. Protocol Overview 5. Protocol Overview
BGMP maintains group-prefix state in response to messages from BGMP BGMP maintains group-prefix state in response to messages from BGMP
peers and notifications from M-IGP components. Group-shared trees peers and notifications from M-IGP components. Group-shared trees
are rooted at the domain advertising the group prefix covering those are rooted at the domain advertising the group prefix covering those
groups. When a receiver joins a specific group address, the border groups. When a receiver joins a specific group address, the border
router towards the root domain generates a group-specific Join router towards the root domain generates a group-specific Join
message, which is then forwarded Border-Router-by-Border-Router message, which is then forwarded Border-Router-by-Border-Router
towards the root domain (see Figure 1). BGMP Join and Prune messages towards the root domain (see Figure 1). BGMP Join and Prune messages
are sent over TCP connections between BGMP peers, and BGMP protocol are sent over TCP connections between BGMP peers, and BGMP protocol
state is refreshed by KEEPALIVE messages periodically sent over TCP. state is refreshed by KEEPALIVE messages periodically sent over TCP.
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 optionally build source-specific unidirectional
only where needed, to be compatible with source-specific trees (SPTs) forwarding state, only where needed, to be compatible with source-
used by some M-IGPs (e.g., DVMRP, PIM-DM, or PIM-SM), or to construct specific trees (SPTs) used by some M-IGPs (e.g., DVMRP, PIM-DM, or
trees for source-specific groups. A domain that uses an SPT-based M- PIM-SM), or to construct trees for source-specific groups. A domain
IGP may need to inject multicast packets from external sources via that uses an SPT-based M-IGP may need to inject multicast packets
different border routers (to be compatible with the M-IGP RPF checks) from external sources via different border routers (to be compatible
which thus act as "surrogates". For example, in the Transit_1 with the M-IGP RPF checks) which thus act as "surrogates". For
domain, data from Src_A arrives at BR12, but must be injected by example, in the Transit_1 domain, data from Src_A arrives at BR12,
BR11. A surrogate router may create a source-specific BGMP branch if but must be injected by BR11. A surrogate router may create a
no shared tree state exists. Note: stub domains with a single border source-specific BGMP branch if no shared tree state exists. Note:
router, such as Rcvr_Stub_7 in Figure 1, receive all multicast data stub domains with a single border router, such as Rcvr_Stub_7 in
packets through that router, to which all RPF checks point. Figure 1, receive all multicast data packets through that router, to
Therefore, stub domains never build source-specific state. 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 6, line 40 skipping to change at page 7, line 19
matching (S,G) BGMP tree state entry if it exists. If not found, the matching (S,G) BGMP tree state entry if it exists. If not found, the
router checks for a matching (*,G) BGMP tree state entry. If neither router checks for a matching (*,G) BGMP tree state entry. If neither
is found, then the packet is sent natively to the next-hop EGP peer is found, then the packet is sent natively to the next-hop EGP peer
for G, according to the Multicast RIB (for example, in the case of a for G, according to the Multicast RIB (for example, in the case of a
non-member sender such as Src_B in Figure 1). If a matching entry non-member sender such as Src_B in Figure 1). If a matching entry
was found, the packet is forwarded to all other targets in the target was found, the packet is forwarded to all other targets in the target
list. In this way BGMP trees forward data in a bidirectional manner. list. In this way BGMP trees forward data in a bidirectional manner.
If a target is an M-IGP component then forwarding is subject to the If a target is an M-IGP component then forwarding is subject to the
rules of that M-IGP protocol. rules of that M-IGP protocol.
4.1. Design Rationale 5.1. Design Rationale
Several other protocols, or protocol proposals, build shared trees Several other protocols, or protocol proposals, build shared trees
within domains [CBT, HPIM, PIM-SM]. The design choices made for BGMP within domains [PIM-SM, CBT]. The design choices made for BGMP
result from our focus on Inter-Domain multicast in particular. The result from our focus on Inter-Domain multicast in particular. The
design choices made by CBT and PIM-SM are better suited to the wide- design choices made by PIM-SM and CBT are better suited to the wide-
area intra-domain case. There are three major differences between area intra-domain case. There are three major differences between
BGMP and other shared-tree protocols: BGMP and other shared-tree protocols:
(1) Unidirectional vs. Bidirectional trees (1) Unidirectional vs. Bidirectional trees
Bidirectional trees (using bidirectional forwarding state as Bidirectional trees (using bidirectional forwarding state as
described above) minimize third party dependence which is essential described above) minimize third party dependence which is essential
in the inter-domain context. For example, in Figure 1, stub domains in the inter-domain context. For example, in Figure 1, stub domains
7 and 8 would like to exchange multicast packets without being 7 and 8 would like to exchange multicast packets without being
dependent on the quality of connectivity of the root domain. dependent on the quality of connectivity of the root domain.
skipping to change at page 7, line 47 skipping to change at page 8, line 26
However, except for source-specific group distribution trees, we do However, except for source-specific group distribution trees, we do
not build source-specific inter-domain trees in general because (a) not build source-specific inter-domain trees in general because (a)
inter-domain connectivity is generally less rich than intra-domain inter-domain connectivity is generally less rich than intra-domain
connectivity, so shared distribution trees should have more connectivity, so shared distribution trees should have more
acceptible path length and traffic concentration properties in the acceptible path length and traffic concentration properties in the
inter-domain context, than in the intra-domain case, and (b) by inter-domain context, than in the intra-domain case, and (b) by
having the shared tree state always take precedence over source- 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 PIM-SM and
SM trees. CBT 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 is sometimes
that all potential shared-tree roots (RPs/Cores) within the domain assumed that all potential shared-tree roots (RPs/Cores) within the
are equally suited to be the root for a group that is initiated domain are equally suited to be the root for a group that is
within that domain. In the INTER-domain case, there is far more initiated within that domain. In the INTER-domain case, there is far
opportunity for unacceptably poor locality, and administrative more 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 sometimes treat all candidate roots (RPs or
equivalent and emphasize load sharing and stability to maximize Cores) as equivalent and emphasize load sharing and stability to
performance. In the Inter-Domain case, all roots are not equivalent, maximize performance. In the Inter-Domain case, all roots are not
and we adopt an approach whereby a group's root domain is not random equivalent, and we adopt an approach whereby a group's root domain is
but is subject to administrative and performance input. not random but is subject to administrative control.
5. Protocol Details 6. 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], modulo one correction
to section 3.2 ("BGMP" Dispatcher), as follows:
5.1. Interaction with the EGP The iif owner of a (*,G) entry is the component owning the next-hop
interface towards the nominal root of G, in the multicast RIB.
6.1. Interaction with the EGP
The fundamental requirements imposed by BGMP are that: The fundamental requirements imposed by BGMP are that:
(1) For a given source-specific group and source, BGMP must be able (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, to look up the next-hop towards the source in the Multicast RIB,
and and
(2) For a given non-source-specific group, BGMP will map the group (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 address to a nominal "root" address, and must be able to look up
the next-hop towards that address in the Multicast RIB. the next-hop towards that address in the Multicast RIB.
BGMP determines the nominal "root" address as follows. In IPv4, the BGMP determines the nominal "root" address as follows. If the multicast
nominal root address is the group address itself. As a result, a address is a Unicast-Prefix-based Multicast address (for either IPv4 or
fundamental requirement for IPv4 imposed by BGMP on the design of an EGP IPv6), then the nominal root address is the embedded unicast prefix,
is that it be able to carry multicast prefixes. For example, a multi- padded with a suffix of 0 bits to form a full address.
protocol BGP (MBGP) must be able to carry a multicast prefix in the
Unicast Network Layer Reachability Information (NLRI) field of the
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 required
by BGMP in the implementation of bi-directional trees; BGMP 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 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 the
optional transitive attributes Multiprotocol Reachable NLRI
(MP_REACH_NLRI) and Multiprotocol Unreachable (MP_UNREACH_NRLI) to 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 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 For example, if the IPv6 group address is
ff2e:0100:1234:5678:9abc:def0::123, then the unicast prefix 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/64, and the nominal root address would be
1234:5678:9abc:def0::. 1234:5678:9abc:def0::. (This address is in fact the subnet routers
anycast address [IPv6AA].)
To handle non-prefix-based group addresses, multicast routes would still As an IPv4 example, if the IPv4 group address were 225.1.2.3, then the
be needed. However, supporting such addresses may not be a requirement. nominal root address would be 1.2.3.0.
5.2. Multicast Data Packet Processing Support for any-source-multicast using any address other than a Unicast-
prefix-based Multicast Address is outside the scope of this document.
6.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.
skipping to change at page 10, line 37 skipping to change at page 10, line 33
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 the nominal root of G, according to the Multicast RIB. hop peer for the nominal root of G, according to the Multicast RIB.
If a matching entry was found, the packet is forwarded to all other If a matching entry was found, the packet is forwarded to all other
targets in the target 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 6.3. BGMP processing of Join and Prune messages and notifications
5.3.1. Receiving Joins 6.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 the nominal root of G, if it is an external next-hop peer towards the nominal root of G, if it is an external
skipping to change at page 12, line 18 skipping to change at page 12, line 15
nominal root for G is through the M-IGP component, an (S,G) nominal root for G is through the M-IGP component, an (S,G)
Poison-Reverse message is 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 the nominal root of G, and the next-hop towards the best exit for the nominal root of G, and the next-hop towards
the nominal root for G is through the interface towards the the nominal root for G is through the interface towards the
external peer, an (S,G) Poison-Reverse message is immediately sent external peer, an (S,G) Poison-Reverse message is immediately sent
to the external peer. to the external peer.
5.3.2. Receiving Prune Notifications 6.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
skipping to change at page 13, line 5 skipping to change at page 12, line 41
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 6.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, in IPv4 (only), an internal route for each class-D In addition, in IPv4 (only), an internal route for each class-D
prefix associated with the domain (if any) MUST be injected into the prefix associated with the domain (if any) MUST be injected into the
skipping to change at page 13, line 42 skipping to change at page 13, line 36
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 the nominal root of G from which (S,G) the next-hop interface towards the nominal root of G from which (S,G)
Joins have been 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 6.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 the nominal root of G. the message, and looks up the next-hop towards the nominal root of G.
If the next-hop target is an M-IGP component, it forwards the (S,G) 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 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 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 external peer on a given interface, it forwards the (S,G) Poison
Reverse message to all external peers on that interface. Reverse message to all external peers on that interface.
skipping to change at page 14, line 20 skipping to change at page 14, line 15
(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 the nominal root of G, and has (S,G) prune state, an (S,G) Join for the nominal root of G, and has (S,G) prune state, an (S,G) Join
message is sent to cancel the prune state and the state is deleted. message is sent to cancel the prune state and the state is deleted.
5.4. Interaction with M-IGP components 6.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.
At any time, any M-IGP domain MAY decide to join a source-specific At any time, any M-IGP domain MAY decide to join a source-specific
skipping to change at page 15, line 5 skipping to change at page 14, line 42
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 the nominal root of G be internal peer for a particular address S or the nominal root of G be
able to forward data for a matching tree state table entry to all able to forward data for a matching tree state table entry to all
members within the domain. This requirement has implications on members within the domain. This requirement has implications on
specific M-IGPs as follows. specific M-IGPs as follows.
5.4.1. Interaction with DVMRP and PIM-DM 6.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
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.
skipping to change at page 15, line 49 skipping to change at page 15, line 43
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 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 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 forward it up the shared tree according to normal BGMP rules), and
both will delete their BGMP (S,G) state. 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. If any such domain
require that some form of Domain-Wide Reports (DWRs) [DWR] are desires to be able to serve as a transit domain, we require that some
available within such domains. Such messages provide the ability to form of Domain-Wide Reports (DWRs) [DWR] are available within such
join and prune an entire group across the domain. One simple domains. Such messages provide the ability to join and prune an
heuristic to approximate DWRs is to assume that if there are any entire group across the domain. One simple heuristic to approximate
internally-reached members, then at least one of them is a sender. DWRs is to assume that if there are any internally-reached members,
With this heuristic, the presense of any M-IGP (S,G) state for then at least one of them is a sender. With this heuristic, the
internally-reached sources can be used instead. Sending a data presense of any M-IGP (S,G) state for internally-reached sources can
packet to a group is then equivalent to sending a DWR for the group. be used instead. Sending a data packet to a group is then equivalent
to sending a DWR for the group.
5.4.2. Interaction with PIM-SM 6.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 (which becomes domain tree is rooted at the next-hop internal peer (which becomes
the RP) towards the nominal root of G, since in general that router the RP) towards the nominal root of G, since in general that router
will receive the most packets from external sources. To achieve will receive the most packets from external sources. To achieve
skipping to change at page 17, line 26 skipping to change at page 17, line 22
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 the nominal root of 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 the if it does not already exist, and puts the next hop towards the
nominal root of G in the target list if not already present. nominal root of G in the target list if not already present.
5.4.3. Interaction with CBT 6.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.
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:
skipping to change at page 18, line 24 skipping to change at page 18, line 20
only send source-specific Joins or Prunes to an external peer if only send source-specific Joins or Prunes to an external peer if
that external peer advertises source-prefixes in the EGP. If a that external peer advertises source-prefixes in the EGP. If a
BGMP-CBT border router does receive an (S,G) Join or Prune, that BGMP-CBT border router does receive an (S,G) Join or Prune, that
border router should ignore the message. border router should ignore the message.
To minimize en/de-capsulations, CBTv2 BR's may follow the same To minimize en/de-capsulations, CBTv2 BR's may follow the same
scheme as described under PIM-SM above, in which Candidate-Core scheme as described under PIM-SM above, in which Candidate-Core
advertisements are sent for those groups for which it is the advertisements are sent for those groups for which it is the
shared-tree ingress router. shared-tree ingress router.
5.4.4. Interaction with MOSPF 6.4.4. Interaction with MOSPF
As with CBTv2, MOSPF cannot process source-specific Joins or Prunes, As with CBTv2, MOSPF cannot process source-specific Joins or Prunes,
and the same two options are available. Therefore, an MOSPF domain and the same two options are available. Therefore, an MOSPF domain
may either: may either:
Option A: Option A:
send a Group-Membership-LSA for all of G in response to a (S,G) send a Group-Membership-LSA for all of G in response to a (S,G)
Join alert, and "prematurely age" it out (when no other downstream Join alert, and "prematurely age" it out (when no other downstream
members exist) in response to an (S,G) Prune alert, OR members exist) in response to an (S,G) Prune alert, OR
Option B: Option B:
not propagate any source routes (i.e., non-class D routes) to their not propagate any source routes (i.e., non-class D routes) to their
external peers for the Multicast RIB unless it is known that no external peers for the Multicast RIB unless it is known that no
other path exists to that prefix (e.g., routes for prefixes other path exists to that prefix (e.g., routes for prefixes
internal to the domain or in a singly-homed customer's domain may internal to the domain or in a singly-homed customer's domain may
be propagated) be propagated)
5.5. Operation over Multi-access Networks 6.5. Operation over Multi-access Networks
Multiaccess links require special handling to prevent duplicates. Multiaccess links require special handling to prevent duplicates.
The following mechanism enables BGMP to operate over multiaccess The following mechanism enables BGMP to operate over multiaccess
links which do not run an M-IGP. This avoids broadcast-and-prune links which do not run an M-IGP. This avoids broadcast-and-prune
behavior and does not require (S,G) state. behavior and does not require (S,G) state.
To elect a designated forwarder per prefix, BGMP uses a FWDR_PREF To elect a designated forwarder per prefix, BGMP uses a FWDR_PREF
message to exchange "forwarder preference" values for each prefix. message to exchange "forwarder preference" values for each prefix.
The peer with the highest forwarder preference becomes the designated The peer with the highest forwarder preference becomes the designated
forwarder, with ties broken by lowest BGMP Identifier. The forwarder, with ties broken by lowest BGMP Identifier. The
designated forwarder is the router responsible for forwarding packets designated forwarder is the router responsible for forwarding packets
up the tree, and is the peer to which joins will be sent. up the tree, and is the peer to which joins will be sent.
When BGMP first learns that a route exists in the multicast RIB whose When BGMP first learns that a route exists in the multicast RIB whose
next-hop interface is NOT the multiaccess link, the BGMP router sends next-hop interface is NOT the multiaccess link, the BGMP router sends
a BGMP FWDR_PREF message for the prefix, to all BGMP peers on the a BGMP FWDR_PREF message for the prefix, to all BGMP peers on the
LAN. The FWDR_PREF message contains a "forwarder preference value" LAN. The FWDR_PREF message contains a "forwarder preference value"
for the local router, and the same value MUST be sent to all peers on for the local router, and the same value MUST be sent to all peers on
skipping to change at page 19, line 40 skipping to change at page 19, line 38
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 6.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 (or route towards the nominal root of G). When this occurs, the G-route (or route towards the nominal root of G). When this occurs,
care must be taken so that the data will reach the root domain without 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 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 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 "poison-reversed". A PR-bit is kept for this purpose, which is updated
by (UN)POISON_REVERSE messages. by (UN)POISON_REVERSE messages.
6. Interaction with address allocation 7. Message Formats
6.1. Requirements for BGMP components
For IPv4 (only), 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-IGP component resides, so that it can inject
routes for them into the routing table.
7. Transition Strategy
There have been significant barriers to multicast deployment in
Internet backbones. While many of the problems with the current
DVMRP backbone (MBONE) have been documented in [ISSUES], most of
these problems require longer term engineering solutions. However,
there is much that can be done with existing technologies to enable
deployment and put in place an architecture that will enable a smooth
transition to the next generation of inter-domain multicast routing
protocols (i.e., BGMP). This section proposes a near-term transition
strategy and architecture that is designed to be simple, risk-
neutral, and provide a smooth, incremental transition path to BGMP.
In addition, the transition architecture provides for improved
convergence properties, some initial policy control, and the
opportunity for providers to run either native or tunneled multicast
backbones and exchanges.
The transition strategy proposed here is to initially use MBGP [MBGP]
to provide the desired convergence and policy control properties, and
PIM-DM for multicast data forwarding. Once this architecture is in
place, backbones and exchanges can incrementally transition to BGMP
and domains running other M-IGPs may be incorporated more fully.
Since the current MBone uses a broadcast-and-prune backbone running
DVMRP, BGMP may view the entire MBone as a single multi-homed stub
domain (with a new AS number). The members-are-senders heuristic can
then be used initially to provide membership notifications within
this stub domain.
A BGMP backbone can then be formed by designating one or more neutral
PIM-DM domains (say, exchanges) as initial BGMP backbones. Each
exchange is then associated with a group prefix which is injected
into the Multicast RIB by all MBGP/BGMP border routers on that
exchange.
Any domain which meets the following constraints may then transition
from a normal MBone-connected domain to one running BGMP:
(1) Must peer with another BGMP domain and participate in M-BGP to
propagate routes in the Multicast RIB.
(2) Must establish an internal (to the MBone AS) EGP (e.g., iBGP)
peer relationship with other border routers of the MBone "stub"
domain, as is done with unicast routing. We expect this to
eventually involve the use of one or more route reflectors
[REFLECT] inside the MBone domain.
(3) If the transition will partition the MBone "stub" domain, then it
must be insured that the MBone domain will be administratively
split into multiple domains, each with a different multicast AS
number.
7.1. Preventing transit through the MBone stub
We desire that two AS's which are mutually reachable through BGMP use
paths which do not pass through the MBone stub domain. This is
illustrated in Figure 2, where the MBone stub is AS 5, which is
multi-homed to both AS 3 and AS 4. Paths between sources and
destinations which have already transitioned to MBGP/BGMP should not
use AS 5 as transit unless no other path exists.
----------------------\ /----------------------------
| |
DVMRP /----\ | | /----\ IGP/iBGP
..............| BR |+++++++++| BR |-----------
\----/ | E | \----/
+ | B | + AS 3
MBone + | G | +
+ | P \-----+----------------------
AS 5 iBGP + | + eBGP
+ | /-----+----------------------
+ | | +
+ | | +
DVMRP /----\ | | /----\ IGP/iBGP
..............| BR |+++++++++| BR |-----------
\----/ | | \----/
| | AS 4
| |
----------------------/ \----------------------------
Figure 2: Preventing Transit through MBone Stub
This requirement is easily solved using standard BGP policy
mechanisms. The MBone border routers should prefer EGP routes to
DVMRP routes, since DVMRP cannot tag routes as being external. Thus,
external routes may appear in the DVMRP routing table, but will not
be imported into the EGP since they will be overridden by iBGP
routes.
Other EGP routers should prefer routes whose ASpath does not contain
the well-known MBone AS number. This will insure that the route
through the MBone stub is not used unless no other path exists. For
safety, routes whose ASpath begins with the MBone AS should receive
the worst preference.
8. Message Formats
This section describes message formats used by BGMP. This section describes message formats used by BGMP.
Messages are sent over a reliable transport protocol connection. A Messages are sent over a reliable transport protocol connection. A
message is processed only after it is entirely received. The maximum message is processed only after it is entirely received. The maximum
message size is 4096 octets. All implementations are required to message size is 4096 octets. All implementations are required to
support this maximum message size. support this maximum message size.
All fields labelled "Reserved" below must be transmitted as 0, and All fields labelled "Reserved" below must be transmitted as 0, and
ignored upon receipt. ignored upon receipt.
8.1. Message Header Format 7.1. Message Header Format
Each message has a fixed-size (4-byte) header. There may or may not Each message has a fixed-size (4-byte) header. There may or may not
be a data portion following the header, depending on the message be a data portion following the header, depending on the message
type. The layout of these fields is shown below: type. The layout of these fields is shown below:
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 | Reserved | | Length | Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 5 skipping to change at page 21, line 5
Type: Type:
This 1-octet unsigned integer indicates the type code of the This 1-octet unsigned integer indicates the type code of the
message. The following type codes are defined: message. The following type codes are defined:
1 - OPEN 1 - OPEN
2 - UPDATE 2 - UPDATE
3 - NOTIFICATION 3 - NOTIFICATION
4 - KEEPALIVE 4 - KEEPALIVE
8.2. OPEN Message Format 7.2. OPEN Message Format
After a transport protocol connection is established, the first After a transport protocol connection is established, the first
message sent by each side is an OPEN message. If the OPEN message is message sent by each side is an OPEN message. If the OPEN message is
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:
skipping to change at page 27, line 29 skipping to change at page 24, line 29
occur more than once within the Optional Parameter. occur more than once within the Optional Parameter.
This document reserves Capability Codes 128-255 for vendor-specific This document reserves Capability Codes 128-255 for vendor-specific
applications. applications.
This document reserves value 0. This document reserves value 0.
Capability Codes (other than those reserved for vendor specific use) Capability Codes (other than those reserved for vendor specific use)
are assigned only by the IETF consensus process and IESG approval. are assigned only by the IETF consensus process and IESG approval.
8.3. UPDATE Message Format 7.3. UPDATE Message Format
UPDATE messages are used to transfer Join/Prune/FwdrPref information UPDATE messages are used to transfer Join/Prune/FwdrPref information
between BGMP peers. The UPDATE message always includes the fixed- between BGMP peers. The UPDATE message always includes the fixed-
size BGMP header, and one or more attributes as described below. size BGMP header, and one or more attributes as described below.
The message format below allows compact encoding of (*,G) Joins and The message format below allows compact encoding of (*,G) Joins and
Prunes, while allowing the flexibility needed to do other updates Prunes, while allowing the flexibility needed to do other updates
such as (S,G) Joins and Prunes towards sources as well as on the such as (S,G) Joins and Prunes towards sources as well as on the
shared tree. In the discussion below, an Encoded-Address-Prefix is shared tree. In the discussion below, an Encoded-Address-Prefix is
of the form: of the form:
skipping to change at page 32, line 5 skipping to change at page 29, line 5
| Length | Type=1 | Reserved |P| | Length | Type=1 | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ... | Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P The PR-bit value. P The PR-bit value.
Nested Attributes No attribues in the document other than SOURCE Nested Attributes No attribues in the document other than SOURCE
may be immediately nested within a may be immediately nested within a
POISON_REVERSE POISON_REVERSE
attribute. attribute.
8.4. Encoding examples 7.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 root of 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 root of 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 7.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
exchanged between peers often enough as not to cause the Hold Timer exchanged between peers often enough as not to cause the Hold Timer
to expire. A reasonable maximum time between the last KEEPALIVE or to expire. A reasonable maximum time between the last KEEPALIVE or
UPDATE message sent, and the time at which a KEEPALIVE message is UPDATE message sent, and the time at which a KEEPALIVE message is
sent, would be one third of the Hold Time interval. KEEPALIVE sent, would be one third of the Hold Time interval. KEEPALIVE
messages MUST NOT be sent more frequently than one per second. An messages MUST NOT be sent more frequently than one per second. An
implementation MAY adjust the rate at which it sends KEEPALIVE implementation MAY adjust the rate at which it sends KEEPALIVE
messages as a function of the Hold Time interval. messages as a function of the Hold Time interval.
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 7.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 if the The BGMP connection is closed immediately after sending it if the
error is a fatal one. 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
skipping to change at page 35, line 5 skipping to change at page 32, line 5
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
The minimum length of the NOTIFICATION message is 6 octets The minimum length of the NOTIFICATION message is 6 octets
(including message header). (including message header).
9. BGMP Error Handling 8. 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 the and Data fields is sent, and the BGMP connection is closed if the
error is a fatal one. If no Error Subcode is specified, then a zero error is a fatal one. If no Error Subcode is specified, then a zero
must be used. 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 8.1. Message Header error handling
All errors detected while processing the Message Header are indicated All errors detected while processing the Message Header are indicated
by sending the NOTIFICATION message with Error Code Message Header by sending the NOTIFICATION message with Error Code Message Header
Error. The Error Subcode elaborates on the specific nature of the Error. The Error Subcode elaborates on the specific nature of the
error. error.
If the Length field of the message header is less than 4 or greater If the Length field of the message header is less than 4 or greater
than 4096, or if the Length field of an OPEN message is less than than 4096, or if the Length field of an OPEN message is less than
the minimum length of the OPEN message, or if the Length field of an the minimum length of the OPEN message, or if the Length field of an
UPDATE message is less than the minimum length of the UPDATE message, UPDATE message is less than the minimum length of the UPDATE message,
or if the Length field of a KEEPALIVE message is not equal to 4, then or if the Length field of a KEEPALIVE message is not equal to 4, then
the Error Subcode is set to Bad Message Length. The Data field the Error Subcode is set to Bad Message Length. The Data field
contains the erroneous Length field. contains the erroneous Length field.
If the Type field of the message header is not recognized, then the If the Type field of the message header is not recognized, then the
Error Subcode is set to Bad Message Type. The Data field contains Error Subcode is set to Bad Message Type. The Data field contains
the erroneous Type field. the erroneous Type field.
9.2. OPEN message error handling 8.2. OPEN message error handling
All errors detected while processing the OPEN message are indicated All errors detected while processing the OPEN message are indicated
by sending the NOTIFICATION message with Error Code OPEN Message by sending the NOTIFICATION message with Error Code OPEN Message
Error. The Error Subcode elaborates on the specific nature of the Error. The Error Subcode elaborates on the specific nature of the
error. error.
If the version number contained in the Version field of the received If the version number contained in the Version field of the received
OPEN message is not supported, then the Error Subcode is set to OPEN message is not supported, then the Error Subcode is set to
Unsupported Version Number. The Data field is a 2-octet unsigned Unsupported Version Number. The Data field is a 2-octet unsigned
integer, which indicates the largest locally supported version number integer, which indicates the largest locally supported version number
skipping to change at page 36, line 39 skipping to change at page 33, line 39
Authentication Failure. Authentication Failure.
If the OPEN message indicates that the peer does not support a If the OPEN message indicates that the peer does not support a
capability which the receiver requires, the receiver may send a capability which the receiver requires, the receiver may send a
NOTIFICATION message to the peer, and terminate peering. The Error NOTIFICATION message to the peer, and terminate peering. The Error
Subcode in the message is set to Unsupported Capability. The Data Subcode in the message is set to Unsupported Capability. The Data
field in the NOTIFICATION message lists the set of capabilities that field in the NOTIFICATION message lists the set of capabilities that
cause the speaker to send the message. Each such capability is cause the speaker to send the message. Each such capability is
encoded the same way as it was encoded in the received OPEN message. encoded the same way as it was encoded in the received OPEN message.
9.3. UPDATE message error handling 8.3. UPDATE message error handling
All errors detected while processing the UPDATE message are indicated All errors detected while processing the UPDATE message are indicated
by sending the NOTIFICATION message with Error Code UPDATE Message by sending the NOTIFICATION message with Error Code UPDATE Message
Error. The error subcode elaborates on the specific nature of the Error. The error subcode elaborates on the specific nature of the
error. error.
If any recognized attribute has Attribute Length that conflicts with If any recognized attribute has Attribute Length that conflicts with
the expected length (based on the attribute type code), then the the expected length (based on the attribute type code), then the
Error Subcode is set to Attribute Length Error. The Data field Error Subcode is set to Attribute Length Error. The Data field
contains the erroneous attribute (type, length and value). contains the erroneous attribute (type, length and value).
If the Encoded-Address-Prefix field in some attribute is If the Encoded-Address-Prefix field in some attribute is
syntactically incorrect, then the Error Subcode is set to Invalid syntactically incorrect, then the Error Subcode is set to Invalid
Prefix Field. Prefix Field.
If any other is encountered when processing attributes (such as If any other is encountered when processing attributes (such as
invalid nestings), then the Error Subcode is set to Malformed invalid nestings), then the Error Subcode is set to Malformed
Attribute List, and the problematic attribute is included in the data Attribute List, and the problematic attribute is included in the data
field. field.
9.4. NOTIFICATION message error handling 8.4. NOTIFICATION message error handling
If a peer sends a NOTIFICATION message, and there is an error in that If a peer sends a NOTIFICATION message, and there is an error in that
message, there is unfortunately no means of reporting this error via message, there is unfortunately no means of reporting this error via
a subsequent NOTIFICATION message. Any such error, such as an a subsequent NOTIFICATION message. Any such error, such as an
unrecognized Error Code or Error Subcode, should be noticed, logged unrecognized Error Code or Error Subcode, should be noticed, logged
locally, and brought to the attention of the administration of the locally, and brought to the attention of the administration of the
peer. The means to do this, however, lies outside the scope of this peer. The means to do this, however, lies outside the scope of this
document. document.
9.5. Hold Timer Expired error handling 8.5. Hold Timer Expired error handling
If a system does not receive successive KEEPALIVE and/or UPDATE If a system does not receive successive KEEPALIVE and/or UPDATE
and/or NOTIFICATION messages within the period specified in the Hold and/or NOTIFICATION messages within the period specified in the Hold
Time field of the OPEN message, then the NOTIFICATION message with Time field of the OPEN message, then the NOTIFICATION message with
Hold Timer Expired Error Code must be sent and the BGMP connection Hold Timer Expired Error Code must be sent and the BGMP connection
closed. closed.
9.6. Finite State Machine error handling 8.6. Finite State Machine error handling
Any error detected by the BGMP Finite State Machine (e.g., receipt of Any error detected by the BGMP Finite State Machine (e.g., receipt of
an unexpected event) is indicated by sending the NOTIFICATION message an unexpected event) is indicated by sending the NOTIFICATION message
with Error Code Finite State Machine Error. with Error Code Finite State Machine Error.
9.7. Cease 8.7. Cease
In absence of any fatal errors (that are indicated in this section), In absence of any fatal errors (that are indicated in this section),
a BGMP peer may choose at any given time to close its BGMP connection a BGMP peer may choose at any given time to close its BGMP connection
by sending the NOTIFICATION message with Error Code Cease. However, by sending the NOTIFICATION message with Error Code Cease. However,
the Cease NOTIFICATION message must not be used when a fatal error the Cease NOTIFICATION message must not be used when a fatal error
indicated by this section does exist. indicated by this section does exist.
9.8. Connection collision detection 8.8. Connection collision detection
If a pair of BGMP speakers try simultaneously to establish a TCP If a pair of BGMP speakers try simultaneously to establish a TCP
connection to each other, then two parallel connections between this connection to each other, then two parallel connections between this
pair of speakers might well be formed. We refer to this situation as pair of speakers might well be formed. We refer to this situation as
connection collision. Clearly, one of these connections must be connection collision. Clearly, one of these connections must be
closed. closed.
Based on the value of the BGMP Identifier a convention is established Based on the value of the BGMP Identifier a convention is established
for detecting which BGMP connection is to be preserved when a for detecting which BGMP connection is to be preserved when a
collision does occur. The convention is to compare the BGMP collision does occur. The convention is to compare the BGMP
skipping to change at page 39, line 17 skipping to change at page 36, line 17
A connection collision with an existing BGMP connection that is in A connection collision with an existing BGMP connection that is in
Established states causes unconditional closing of the newly created Established states causes unconditional closing of the newly created
connection. Note that a connection collision cannot be detected with connection. Note that a connection collision cannot be detected with
connections that are in Idle, or Connect, or Active states. connections that are in Idle, or Connect, or Active states.
Closing the BGMP connection (that results from the collision Closing the BGMP connection (that results from the collision
resolution procedure) is accomplished by sending the NOTIFICATION resolution procedure) is accomplished by sending the NOTIFICATION
message with the Error Code Cease. message with the Error Code Cease.
10. BGMP Version Negotiation 9. BGMP Version Negotiation
BGMP speakers may negotiate the version of the protocol by making BGMP speakers may negotiate the version of the protocol by making
multiple attempts to open a BGMP connection, starting with the multiple attempts to open a BGMP connection, starting with the
highest version number each supports. If an open attempt fails with highest version number each supports. If an open attempt fails with
an Error Code OPEN Message Error, and an Error Subcode Unsupported an Error Code OPEN Message Error, and an Error Subcode Unsupported
Version Number, then the BGMP speaker has available the version Version Number, then the BGMP speaker has available the version
number it tried, the version number its peer tried, the version number it tried, the version number its peer tried, the version
number passed by its peer in the NOTIFICATION message, and the number passed by its peer in the NOTIFICATION message, and the
version numbers that it supports. If the two peers do support one or version numbers that it supports. If the two peers do support one or
more common versions, then this will allow them to rapidly determine more common versions, then this will allow them to rapidly determine
the highest common version. In order to support BGMP version the highest common version. In order to support BGMP version
negotiation, future versions of BGMP must retain the format of the negotiation, future versions of BGMP must retain the format of the
OPEN and NOTIFICATION messages. OPEN and NOTIFICATION messages.
10.1. BGMP Capability Negotiation 9.1. BGMP Capability Negotiation
When a BGMP speaker sends an OPEN message to its BGMP peer, the When a BGMP speaker sends an OPEN message to its BGMP peer, the
message may include an Optional Parameter, called Capabilities. The message may include an Optional Parameter, called Capabilities. The
parameter lists the capabilities supported by the speaker. parameter lists the capabilities supported by the speaker.
A BGMP speaker may use a particular capability when peering with A BGMP speaker may use a particular capability when peering with
another speaker only if both speakers support that capability. A another speaker only if both speakers support that capability. A
BGMP speaker determines the capabilities supported by its peer by BGMP speaker determines the capabilities supported by its peer by
examining the list of capabilities present in the Capabilities examining the list of capabilities present in the Capabilities
Optional Parameter carried by the OPEN message that the speaker Optional Parameter carried by the OPEN message that the speaker
receives from the peer. receives from the peer.
11. BGMP Finite State machine 10. BGMP Finite State machine
This section specifies BGMP operation in terms of a Finite State This section specifies BGMP operation in terms of a Finite State
Machine (FSM). Following is a brief summary and overview of BGMP Machine (FSM). Following is a brief summary and overview of BGMP
operations by state as determined by this FSM. operations by state as determined by this FSM.
Initially BGMP is in the Idle state. Initially BGMP is in the Idle state.
Idle state: Idle state:
In this state BGMP refuses all incoming BGMP connections. No In this state BGMP refuses all incoming BGMP connections. No
skipping to change at page 44, line 37 skipping to change at page 41, line 37
In response to any other event, the local system sends In response to any other event, the local system sends
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 11. Security Considerations
BGMP uses TCP sessions for all network communication between peers. TCP BGMP uses TCP sessions for all network communication between peers. TCP
sessions may be secured through the use of IPsec [IPSEC]. sessions may be secured through the use of IPsec [IPSEC].
13. Authors' Addresses 12. Authors' Addresses
Dave Thaler Dave Thaler
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
Deborah Estrin 13. Normative References
Computer Science Dept./ISI
University of Southern California
Los Angeles, CA 90089
EMail: estrin@usc.edu
David Meyer [INTEROP]
Cisco Systems Thaler, D., "Interoperability Rules for Multicast Routing
San Jose, CA Protocols", RFC 2715, October 1999.
EMail: dmm@cisco.com
14. References [IPSEC]
Kent, S., and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[RFC2119]
S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[V4PREFIX]
D. Thaler, "Unicast-Prefix-based IPv4 Multicast Addresses", draft-
thaler-ipv4-uni-based-mcast-00.txt, Work in progress, November
2001.
[V6PREFIX]
Haberman, B., and D. Thaler, "Unicast-Prefix-based IPv6 Multicast
Addresses", draft-ietf-ipngwg-uni-based-mcast-03.txt, Work in
progress, October 2001.
14. Non-normative References
[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., "Core Based Trees (CBT version 2) Multicast Ballardie, A., "Core Based Trees (CBT version 2) Multicast
Routing", RFC 2189, September 1997. Routing", RFC 2189, September 1997.
[DVMRP] [DVMRP]
Pusateri, T., "Distance Vector Multicast Routing Protocol", draft- Pusateri, T., "Distance Vector Multicast Routing Protocol", draft-
ietf-idmr-dvmrp-v3-09.txt, March 2000. ietf-idmr-dvmrp-v3-10.txt, Work in progress, August 2000.
[DWR] [DWR]
Fenner, W., "Domain-Wide Reports", draft-ietf-idmr-membership- Fenner, W., "Domain-Wide Reports", draft-ietf-idmr-membership-
reports-04.txt, August 1999. reports-04.txt, Work in progress, August 1999.
[INTEROP]
Thaler, D., "Interoperability Rules for Multicast Routing
Protocols", RFC 2715, October 1999.
[IPSEC]
Kent, S., and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[IPv6AA] [IPv6AA]
Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture",
RFC 2373, July 1998. RFC 2373, July 1998.
[ISSUES]
Meyer, D., "Some Issues for an Inter-domain Multicast Routing
Protocol", draft-ietf-mboned-imrp-some-issues-02.txt, June 1997.
[MASC]
Estrin, D., Handley, M, and D. Thaler, "Multicast-Address-Set
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- Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent
DM): Protocol Specification", draft-ietf-idmr-pim-dm-spec-05.txt, Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)",
May 1997. draft-ietf-pim-dm-new-v2-01.txt, Work in progress, February 2002.
[PIMSM] [PIMSM]
Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM-
SM): Protocol Specification", RFC 2362, June 1998. 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]
S. J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700, October
1994.
[RFC2119]
S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[V6PREFIX]
Haberman, B., and D. Thaler, "Unicast-Prefix-based IPv6 Multicast
Addresses", 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 (2002). 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
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
skipping to change at page 47, line 33 skipping to change at page 44, line 19
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents Table of Contents
1 Acknowledgements ................................................ 2 xp t
2 Purpose ......................................................... 2
3 Terminology ..................................................... 3
4 Protocol Overview ............................................... 5
4.1 Design Rationale .............................................. 6
5 Protocol Details ................................................ 8
5.1 Interaction with the EGP ...................................... 8
5.2 Multicast Data Packet Processing .............................. 9
5.3 BGMP processing of Join and Prune messages and notifications
.............................................................. 10
5.3.1 Receiving Joins ............................................. 10
5.3.2 Receiving Prune Notifications ............................... 12
5.3.3 Receiving Route Change Notifications ........................ 13
5.3.4 Receiving (S,G) Poison-Reverse messages ..................... 13
5.4 Interaction with M-IGP components ............................. 14
5.4.1 Interaction with DVMRP and PIM-DM ........................... 15
5.4.2 Interaction with PIM-SM ..................................... 16
5.4.3 Interaction with CBT ........................................ 17
5.4.4 Interaction with MOSPF ...................................... 18
5.5 Operation over Multi-access Networks .......................... 18
5.6 Interaction between (S,G) state and G-routes .................. 19
6 Interaction with address allocation ............................. 20
6.1 Requirements for BGMP components .............................. 20
7 Transition Strategy ............................................. 20
7.1 Preventing transit through the MBone stub ..................... 22
8 Message Formats ................................................. 23
8.1 Message Header Format ......................................... 23
8.2 OPEN Message Format ........................................... 24
8.3 UPDATE Message Format ......................................... 27
8.4 Encoding examples ............................................. 32
8.5 KEEPALIVE Message Format ...................................... 32
8.6 NOTIFICATION Message Format ................................... 32
9 BGMP Error Handling ............................................. 35
9.1 Message Header error handling ................................. 35
9.2 OPEN message error handling ................................... 35
9.3 UPDATE message error handling ................................. 36
9.4 NOTIFICATION message error handling ........................... 37
9.5 Hold Timer Expired error handling ............................. 37
9.6 Finite State Machine error handling ........................... 37
9.7 Cease ......................................................... 38
9.8 Connection collision detection ................................ 38
10 BGMP Version Negotiation ....................................... 39
10.1 BGMP Capability Negotiation .................................. 39
11 BGMP Finite State machine ...................................... 40
12 Security Considerations ........................................ 44
13 Authors' Addresses ............................................. 44
14 References ..................................................... 45
15 Full Copyright Statement ....................................... 47
 End of changes. 79 change blocks. 
331 lines changed or deleted 206 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/