draft-ietf-bgmp-spec-05.txt   draft-ietf-bgmp-spec-06.txt 
BGMP Working Group D. Thaler BGMP Working Group D. Thaler
Internet Engineering Task Force Microsoft Internet Engineering Task Force Microsoft
Expires November 2003
Border Gateway Multicast Protocol (BGMP): Border Gateway Multicast Protocol (BGMP):
Protocol Specification Protocol Specification
<draft-ietf-bgmp-spec-05.txt> <draft-ietf-bgmp-spec-06.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
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
optionally allows receiver domains to build source-specific, inter- optionally allows receiver domains to build source-specific, inter-
domain, distribution branches where needed. BGMP natively supports domain, distribution branches where needed. BGMP natively supports
"source-specific multicast" (SSM). To also support "any-source "source-specific multicast" (SSM). To also support "any-source
multicast" (ASM), BGMP requires that each multicast group be associated multicast" (ASM), BGMP requires that each multicast group be associated
with a single root (in BGMP it is referred to as the root domain). It with a single root (in BGMP it is referred to as the root domain). It
requires that different ranges of the class D space are associated requires that different ranges of the multicast address space are
(e.g., with Unicast-Prefix-Based Multicast addressing) with different associated (e.g., with Unicast-Prefix-Based Multicast addressing) with
domains. Each of these domains then becomes the root of the shared different domains. Each of these domains then becomes the root of the
domain-trees for all groups in its range. Multicast participants will shared domain-trees for all groups in its range. Multicast participants
generally receive better multicast service if the session initiator's will generally receive better multicast service if the session
address allocator selects addresses from its own domain's part of the initiator's address allocator selects addresses from its own domain's
space, thereby causing the root domain to be local to at least one of part of the space, thereby causing the root domain to be local to at
the session participants. least one of the session participants.
NOTE:
This specification is published for the general information of the
Internet technical community and as an archival record of the work
done. The operational community generally agrees that this protocol
is not deployable in its current form; it is being published in the
hopes that it may provide a useful starting point for future work.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). 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, Deborah Estrin, Dino Ballardie, Steve Casner, Steve Deering, Deborah Estrin, Dino
Farinacci, Bill Fenner, Mark Handley, Ahmed Helmy, Van Jacobson, Dave Farinacci, Bill Fenner, Mark Handley, Ahmed Helmy, Van Jacobson, Dave
Meyer, and Satish Kumar. 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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
routing. BGMP natively supports "source-specific multicast" (SSM). routing. BGMP natively supports "source-specific multicast" (SSM).
To also support "any-source multicast" (ASM), BGMP builds shared To also support "any-source multicast" (ASM), BGMP builds shared
trees for active multicast groups, and allows domains to build trees for active multicast groups, and allows domains to build
source-specific, inter-domain, distribution branches where needed. source-specific, inter-domain, distribution branches where needed.
Building upon concepts from PIM-SM and CBT, BGMP requires that each Building upon concepts from PIM-SM and CBT, BGMP requires that each
global multicast group be associated with a single root. However, in global multicast group be associated with a single root. However, in
BGMP, the root is an entire exchange or domain, rather than a single BGMP, the root is an entire exchange or domain, rather than a single
router. router.
For non-source-specific groups, BGMP assumes that ranges of the multicast For non-source-specific groups, BGMP assumes that ranges of the
address space have been associated (e.g., with Unicast-Prefix-Based multicast address space have been associated (e.g., with Unicast-
Multicast [V4PREFIX,V6PREFIX] addressing) with selected domains. Prefix-Based Multicast [V4PREFIX,V6PREFIX] addressing) with selected
Each such domain then becomes the root of the shared domain-trees for domains. Each such domain then becomes the root of the shared
all groups in its range. An address allocator will generally achieve domain-trees for all groups in its range. An address allocator will
better distribution trees if it takes its multicast addresses from generally achieve better distribution trees if it takes its multicast
its own domain's part of the space, thereby causing the root domain addresses from its own domain's part of the space, thereby causing
to be local. the root domain to be local.
BGMP uses TCP as its transport protocol. This eliminates the need to BGMP uses TCP as its transport protocol. This eliminates the need to
implement message fragmentation, retransmission, acknowledgement, and implement message fragmentation, retransmission, acknowledgement, and
sequencing. BGMP uses TCP port 264 for establishing its connections. sequencing. BGMP uses TCP port 264 for establishing its connections.
This port is distinct from BGP's port to provide protocol This port is distinct from BGP's port to provide protocol
independence, and to facilitate distinguishing between protocol independence, and to facilitate distinguishing between protocol
packets (e.g., by packet classifiers, diagnostic utilities, etc.) packets (e.g., by packet classifiers, diagnostic utilities, etc.)
Two BGMP peers form a TCP connection between one another, and Two BGMP peers form a TCP connection between one another, and
exchange messages to open and confirm the connection parameters. exchange messages to open and confirm the connection parameters.
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. Revision History 3. Revision History
29 June 2003 draft-01 This section should be removed by the RFC editor before publication.
19 January 2004 draft-06
(1) Removed NOTE from abstract per mailing list discussion about it
being obsolete.
Replaced "class D" terminology with non-IPv4-specific
terminology.
Added security considerations, with language similar to that in
RFC 3618.
Removed mention of Domain-Wide Reports since draft no longer
exists, and there is no current demand for using dense-mode
protocols as transit domains between sparse-mode domains.
Updated references.
Moved [V4PREFIX] from normative to informative, since the
protocol can be implemented without it (but without it, the ASM
model will only work in IPv6).
29 June 2002 draft-01
(1) Removed all references to MASC and G-RIB. The current spec only (1) Removed all references to MASC and G-RIB. The current spec only
covers BGMP operation for source-specific groups, and any-source- covers BGMP operation for source-specific groups, and any-source-
multicast using unicast prefix-based multicast addresses (for multicast using unicast prefix-based multicast addresses (for
both IPv4 and IPv6). No new routes of any type are needed in the both IPv4 and IPv6). No new routes of any type are needed in the
routing table. routing table.
(2) Removed section on transitioning away from using DVMRP as the (2) Removed section on transitioning away from using DVMRP as the
backbone to an AS-based multicast routing system with MBGP, as backbone to an AS-based multicast routing system with MBGP, as
this has already happened. this has already happened.
skipping to change at page 9, line 23 skipping to change at page 9, line 46
(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. If the multicast BGMP determines the nominal "root" address as follows. If the multicast
address is a Unicast-Prefix-based Multicast address (for either IPv4 or address is a Unicast-Prefix-based Multicast address, then the nominal
IPv6), then the nominal root address is the embedded unicast prefix, root address is the embedded unicast prefix, padded with a suffix of 0
padded with a suffix of 0 bits to form a full address.
bits to form a full address.
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::. (This address is in fact the subnet routers 1234:5678:9abc:def0::. (This address is in fact the subnet router
anycast address [IPv6AA].) anycast address [IPv6AA].)
As an IPv4 example, if the IPv4 group address were 225.1.2.3, then the
nominal root address would be 1.2.3.0.
Support for any-source-multicast using any address other than a Unicast- Support for any-source-multicast using any address other than a Unicast-
prefix-based Multicast Address is outside the scope of this document. prefix-based Multicast Address is outside the scope of this document.
6.2. Multicast Data Packet Processing 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
skipping to change at page 15, line 43 skipping to change at page 16, line 17
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. If any such domain and prunes for individual sources are available. As a result, BGMP
desires to be able to serve as a transit domain, we require that some does not currently support such protocols being used in a transit
form of Domain-Wide Reports (DWRs) [DWR] are available within such domain.
domains. Such messages provide the ability to join and prune an
entire group across the domain. One simple heuristic to approximate
DWRs is to assume that if there are any internally-reached members,
then at least one of them is a sender. With this heuristic, the
presense of any M-IGP (S,G) state for internally-reached sources can
be used instead. Sending a data packet to a group is then equivalent
to sending a DWR for the group.
6.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
skipping to change at page 17, line 46 skipping to change at page 18, line 14
(*,G) Join alert, as described in [INTEROP]. That is, if it is not (*,G) Join alert, as described in [INTEROP]. That is, if it is not
already on the core-tree for G, then it sends a CBT (*,G) JOIN- already on the core-tree for G, then it sends a CBT (*,G) JOIN-
REQUEST message towards the core for G. Similarly, when the CBT REQUEST message towards the core for G. Similarly, when the CBT
component receives an (S,G) Prune alert, and the child interface component receives an (S,G) Prune alert, and the child interface
list for a group is NULL, then it sends a (*,G) QUIT_NOTIFICATION list for a group is NULL, then it sends a (*,G) QUIT_NOTIFICATION
towards the core for G. This option has the disadvantage of towards the core for G. This option has the disadvantage of
pulling all data for the group G down to the CBT domain when no pulling all data for the group G down to the CBT domain when no
members exist. members exist.
Option B: Option B:
The CBT domain does not propagate any source routes (i.e., non- The CBT domain does not propagate any routes to their external
class D routes) to their external peers for the Multicast RIB peers for the Multicast RIB unless it is known that no other path
unless it is known that no other path exists to that prefix (e.g., exists to that prefix (e.g., routes for prefixes internal to the
routes for prefixes internal to the domain or in a singly-homed domain or in a singly-homed customer's domain may be propagated).
customer's domain may be propagated). This insures that source- This insures that source-specific joins are never received unless
specific joins are never received unless the source's data already the source's data already passes through the domain on the shared
passes through the domain on the shared tree, in which case the tree, in which case the (S,G) Join need not be propagated anyway.
(S,G) Join need not be propagated anyway. BGMP border routers will BGMP border routers will only send source-specific Joins or Prunes
only send source-specific Joins or Prunes to an external peer if to an external peer if that external peer advertises source-
that external peer advertises source-prefixes in the EGP. If a prefixes in the EGP. If a BGMP-CBT border router does receive an
BGMP-CBT border router does receive an (S,G) Join or Prune, that (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.
6.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 routes to their external peers for the Multicast
external peers for the Multicast RIB unless it is known that no RIB unless it is known that no other path exists to that prefix
other path exists to that prefix (e.g., routes for prefixes (e.g., routes for prefixes internal to the domain or in a singly-
internal to the domain or in a singly-homed customer's domain may homed customer's domain may be propagated)
be propagated)
6.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.
skipping to change at page 19, line 49 skipping to change at page 20, line 16
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.
The PR-bit indicates to BGMP nodes whether The PR-bit indicates to BGMP nodes whether they need to forward packets
they need to forward packets up towards the root domain. up towards the root domain. For example, in a case where an (S,G)
For example, in a case where an (S,G) branch exists, branch exists, a transit domain may get packets along the (S,G) branch,
a transit domain may get packets along the (S,G) branch, and needs to know whether to (also) forward them up towards the root
and needs to know whether to (also) forward them up domain. If the domain in question is on the path between S and the root
towards the root domain. If the domain in question domain, then the answer is yes (and the PR bit will be set on the S,G
is on the path between S and the root domain, then state). If the domain in question is not on the path between S and the
the answer is yes (and the PR bit will be set on the root domain, then the answer is no (and the PR bit will be clear on the
S,G state). If the domain in question is not on the S,G state).
path between S and the root domain, then the answer
is no (and the PR bit will be clear on the S,G state).
7. Message Formats 7. 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.
skipping to change at page 41, line 39 skipping to change at page 41, line 39
NOTIFICATION message with Error Code Finite State Machine Error NOTIFICATION message with Error Code Finite State Machine Error
and changes its state to Idle. and changes its state to Idle.
Whenever BGMP changes its state from Established to Idle, it Whenever BGMP changes its state from Established to Idle, it
closes the BGMP (and transport-level) connection, releases all closes the BGMP (and transport-level) connection, releases all
resources associated with that connection, and deletes all routes resources associated with that connection, and deletes all routes
derived from that connection. derived from that connection.
11. Security Considerations 11. Security Considerations
BGMP uses TCP sessions for all network communication between peers. TCP If a BGMP speaker accepts unauthorized or altered BGMP messages, denial
sessions may be secured through the use of IPsec [IPSEC]. of service due to excess bandwidth consumption or lack of multicast
connectivity can result. Authentication of BGMP messages can protect
against this behavior.
12. Authors' Addresses A BGMP implementation MUST implement Keyed MD5 [RFC2385] to secure
control messages, and MUST be capable of interoperating with peers that
do not support it. However, if one side of the connection is configured
with Keyed MD5 and the other side is not, the connection SHOULD NOT be
established.
This provides a weak security mechanism, as it is still possible for
denial of service to occur as a result of messages relayed through a
trusted peer. However, this model is the same as the currently
practiced security mechanism for BGP. It is anticipated that future
work will provide different stronger mechanisms for dealing with these
issues in routing protocols.
12. Authors' Address
Dave Thaler Dave Thaler
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
EMail: dthaler@microsoft.com EMail: dthaler@microsoft.com
13. Normative References 13. Normative References
[INTEROP] [INTEROP]
Thaler, D., "Interoperability Rules for Multicast Routing Thaler, D., "Interoperability Rules for Multicast Routing
Protocols", RFC 2715, October 1999. Protocols", RFC 2715, October 1999.
[IPSEC] [IPSEC]
Kent, S., and R. Atkinson, "Security Architecture for the Internet Kent, S. and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998. Protocol", RFC 2401, November 1998.
[RFC2119] [RFC2119]
S. Bradner, "Key words for use in RFCs to Indicate Requirement S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[V4PREFIX]
D. Thaler, "Unicast-Prefix-based IPv4 Multicast Addresses", draft-
ietf-mboned-ipv4-uni-based-mcast-00.txt, Work in progress, June
2002.
[V6PREFIX] [V6PREFIX]
Haberman, B., and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast
Addresses", RFC 3306, August 2002. Addresses", RFC 3306, August 2002.
14. Non-normative References 14. Informative 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 2858, June 2000. 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-10.txt, Work in progress, August 2000. ietf-idmr-dvmrp-v3-11.txt, Work in progress, October 2003.
[DWR]
Fenner, W., "Domain-Wide Reports", draft-ietf-idmr-membership-
reports-04.txt, Work in progress, August 1999.
[IPv6AA] [IPv6AA]
Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture",
RFC 3513, April 2003. RFC 2373, July 1998.
[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]
Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Adams, A., Nicholas, J. and W. Siadak, "Protocol Independent
Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)",
draft-ietf-pim-dm-new-v2-01.txt, Work in progress, February 2002. draft-ietf-pim-dm-new-v2-04.txt, Work in progress, September 2003.
[PIMSM] [PIMSM]
Fenner, et al., "Protocol Independent Multicast-Sparse Mode (PIM- Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM-
SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-07.txt, SM): Protocol Specification", RFC 2362, June 1998.
March 2003.
[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.
[V4PREFIX]
D. Thaler, "Unicast-Prefix-based IPv4 Multicast Addresses", draft-
thaler-ipv4-uni-based-mcast-00.txt, Work in progress, November
2001.
15. Full Copyright Statement 15. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). 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 44, line 19 skipping to change at page 44, line 29
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
xp t 1 Acknowledgements ................................................ 2
2 Purpose ......................................................... 2
3 Revision History ................................................ 3
4 Terminology ..................................................... 4
5 Protocol Overview ............................................... 6
5.1 Design Rationale .............................................. 7
6 Protocol Details ................................................ 9
6.1 Interaction with the EGP ...................................... 9
6.2 Multicast Data Packet Processing .............................. 10
6.3 BGMP processing of Join and Prune messages and notifications
.............................................................. 11
6.3.1 Receiving Joins ............................................. 11
6.3.2 Receiving Prune Notifications ............................... 12
6.3.3 Receiving Route Change Notifications ........................ 13
6.3.4 Receiving (S,G) Poison-Reverse messages ..................... 14
6.4 Interaction with M-IGP components ............................. 14
6.4.1 Interaction with DVMRP and PIM-DM ........................... 15
6.4.2 Interaction with PIM-SM ..................................... 16
6.4.3 Interaction with CBT ........................................ 17
6.4.4 Interaction with MOSPF ...................................... 18
6.5 Operation over Multi-access Networks .......................... 19
6.6 Interaction between (S,G) state and G-routes .................. 20
7 Message Formats ................................................. 20
7.1 Message Header Format ......................................... 20
7.2 OPEN Message Format ........................................... 21
7.3 UPDATE Message Format ......................................... 25
7.4 Encoding examples ............................................. 29
7.5 KEEPALIVE Message Format ...................................... 29
7.6 NOTIFICATION Message Format ................................... 30
8 BGMP Error Handling ............................................. 32
8.1 Message Header error handling ................................. 32
8.2 OPEN message error handling ................................... 33
8.3 UPDATE message error handling ................................. 33
8.4 NOTIFICATION message error handling ........................... 34
8.5 Hold Timer Expired error handling ............................. 34
8.6 Finite State Machine error handling ........................... 34
8.7 Cease ......................................................... 35
8.8 Connection collision detection ................................ 35
9 BGMP Version Negotiation ........................................ 36
9.1 BGMP Capability Negotiation ................................... 36
10 BGMP Finite State machine ...................................... 37
11 Security Considerations ........................................ 41
12 Authors' Address ............................................... 42
13 Normative References ........................................... 42
14 Informative References ......................................... 42
15 Full Copyright Statement ....................................... 43
 End of changes. 30 change blocks. 
102 lines changed or deleted 113 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/