RFC 3913
Border Gateway Multicast Protocol (BGMP): Protocol Specification
RFC 3913 🎀 Border Gateway Multicast Protocol (BGMP): Protocol Specification
Okay bestie, let's get into it! 💖 This is RFC 3913, the BGMP spec, written by D. Thaler at Microsoft. It's Informational, which means it shares info for the Internet community and doesn't set an official standard. Its date is September 2004. It doesn't obsolete or update anything, since there's no Obsoletes or Updates line in its header. 🦋
Status of This Memo 🌸
Okay so, this memo is just here to give info to the Internet community. It is NOT a standard, not even a little bit. 💅 Anyone can share it freely, no cap.
Copyright Notice ✨
Copyright (C) The Internet Society (2004).
Boring legal stuff, but it's there. 🙈
Abstract 🔥
Okay this is the big picture. ✨ BGMP is a protocol for inter-domain multicast routing, which is basically how multicast traffic gets routed between different networks. BGMP builds shared trees for groups that are currently active, and it can optionally let receiver domains build source-specific, inter-domain distribution branches when they need them.
BGMP natively supports source-specific multicast (SSM). 💜 If you also want any-source multicast (ASM), BGMP requires that each multicast group has a single root, which BGMP calls the root domain. It also requires that different ranges of the multicast address space get associated with different domains (for example, with Unicast-Prefix-Based Multicast addressing). Each of those domains then becomes the root of the shared domain-trees for every group in its range. 🌈
The vibe is that multicast participants usually get better service when the session initiator's address allocator picks addresses from its own domain's part of the space. Then the root domain ends up local to at least one of the session participants. Main character energy for the root domain, honestly. 👑
Table of Contents 🧚
1. Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Design Rationale . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Interaction with the EGP . . . . . . . . . . . . . . . . 8
4.2. Multicast Data Packet Processing . . . . . . . . . . . . 9
4.3. BGMP processing of Join and Prune messages and
notifications. . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Receiving Joins. . . . . . . . . . . . . . . . . 10
4.3.2. Receiving Prune Notifications. . . . . . . . . . 11
4.3.3. Receiving Route Change Notifications . . . . . . 12
4.3.4. Receiving (S,G) Poison-Reverse messages. . . . . 12
4.4. Interaction with M-IGP components. . . . . . . . . . . . 13
4.4.1. Interaction with DVMRP and PIM-DM. . . . . . . . 14
4.4.2. Interaction with PIM-SM. . . . . . . . . . . . . 15
4.4.3. Interaction with CBT . . . . . . . . . . . . . . 16
4.4.4. Interaction with MOSPF . . . . . . . . . . . . . 17
4.5. Operation over Multi-access Networks . . . . . . . . . . 17
4.6. Interaction between (S,G) state and G-routes . . . . . . 18
5. Message Formats. . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Message Header Format. . . . . . . . . . . . . . . . . . 19
5.2. OPEN Message Format. . . . . . . . . . . . . . . . . . . 19
5.3. UPDATE Message Format. . . . . . . . . . . . . . . . . . 23
5.4. Encoding examples. . . . . . . . . . . . . . . . . . . . 27
5.5. KEEPALIVE Message Format . . . . . . . . . . . . . . . . 27
5.6. NOTIFICATION Message Format. . . . . . . . . . . . . . . 28
6. BGMP Error Handling. . . . . . . . . . . . . . . . . . . . . . 30
6.1. Message Header error handling. . . . . . . . . . . . . . 30
6.2. OPEN message error handling. . . . . . . . . . . . . . . 30
6.3. UPDATE message error handling. . . . . . . . . . . . . . 31
6.4. NOTIFICATION message error handling. . . . . . . . . . . 32
6.5. Hold Timer Expired error handling. . . . . . . . . . . . 32
6.6. Finite State Machine error handling. . . . . . . . . . . 32
6.7. Cease. . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.8. Connection collision detection . . . . . . . . . . . . . 32
7. BGMP Version Negotiation . . . . . . . . . . . . . . . . . . . 33
7.1. BGMP Capability Negotiation. . . . . . . . . . . . . . . 34
8. BGMP Finite State machine. . . . . . . . . . . . . . . . . . . 34
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 38
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 411. Purpose 💖
Okay so, there's this idea floating around that inter-domain "any-source" multicast works better with a rendezvous mechanism. That's where members receive sources' data packets without any kind of global broadcast. 😭 Right now, MSDP broadcasts source info, PIM-DM [PIMDM] and DVMRP [DVMRP] broadcast initial data packets, and MOSPF [MOSPF] broadcasts membership info. Meanwhile PIM-SM [PIMSM] and CBT [CBT] use a shared group-tree. Members join it and hear from all sources, and non-members don't join, so they hear from no sources at all. 🧚
So this document describes BGMP, the inter-domain multicast routing protocol. ✨ It natively supports source-specific multicast (SSM). To also support any-source multicast (ASM), BGMP builds shared trees for active multicast groups, and lets domains build source-specific, inter-domain distribution branches where needed. Borrowing ideas from PIM-SM and CBT, BGMP requires that each global multicast group be associated with a single root. The twist is that in BGMP, the root is an entire exchange or domain, not a single router. 🌸
For groups that aren't source-specific, BGMP assumes that ranges of the multicast address space have been associated with selected domains. This can happen with Unicast-Prefix-Based Multicast [V4PREFIX,V6PREFIX] addressing, for example. Each such domain then becomes the root of the shared domain-trees for every group in its range. 🦋 An address allocator will generally get better distribution trees if it takes multicast addresses from its own domain's part of the space, which makes the root domain local.
BGMP uses TCP as its transport protocol. 💅 That means it doesn't need to implement message fragmentation, retransmission, acknowledgement, or sequencing. Honestly, TCP handles all the messy stuff. BGMP uses TCP port 264 to set up its connections. This port is different from BGP's port, which gives protocol independence and makes BGMP easier to tell apart from other protocol packets. Packet classifiers and diagnostic utilities will thank you. 🫶
Here's how a session goes. Two BGMP peers open a TCP connection between each other, then trade messages to open and confirm the connection parameters. After that, they send incremental Join/Prune Updates whenever group memberships change. BGMP does not need periodic refresh of individual entries, which is very chill. 😌 KeepAlive messages get sent periodically to keep the connection alive, and Notification messages get sent when there are errors or special conditions. If a connection hits an error condition, a notification message goes out, and the connection gets closed if the error is fatal. 💀
2. Terminology 🍓
Okay, bestie, here are the key terms you need to know. 📚
Domain: A set of one or more contiguous links and zero or more routers surrounded by one or more multicast border routers. Note that this loose definition of domain also applies to an external link between two domains, as well as an exchange. 🌈
Root Domain: When constructing a shared tree of domains for some group, one domain will be the "root" of the tree. The root domain receives data from each sender to the group. It also works as a rendezvous domain, where member domains send inter-domain joins and sender domains send data. It's giving center of the universe. 👑
Multicast RIB: The Routing Information Base, or routing table, used to calculate the "next-hop" toward a particular address for multicast traffic. 🧚
Multicast IGP (M-IGP): A generic term for any multicast routing protocol used for tree construction within a domain. Typical examples of M-IGPs are PIM-SM, PIM-DM, DVMRP, MOSPF, and CBT. 💜
EGP: A generic term for the interdomain unicast routing protocol in use. Typically this is some version of BGP that can support a Multicast RIB, such as MBGP [MBGP], which contains both unicast and multicast address prefixes. 🦋
Component: The portion of a border router that's associated with, and logically inside, a particular domain that runs the multicast IGP (M-IGP) for that domain, if there is one. Each border router has zero or more components inside routing domains. 🌸 Also, each border router with external links that don't fall inside any routing domain will have an inter-domain component that runs BGMP.
External peer: A border router in another multicast AS (autonomous system, as used in BGP) that has a BGMP TCP connection open to it. If BGP is the EGP, a separate "eBGP" TCP connection will also be open to the same peer. 🫶
Internal peer: Another border router of the same multicast AS. If BGP is being used as the EGP, the border router either speaks iBGP ("internal" BGP) directly to internal peers in a full mesh, or indirectly through a route reflector [REFLECT]. ✨
Next-hop peer: The next-hop peer toward a given IP address is the next EGP router on the path to that address, according to multicast RIB routes in the EGP's routing table. For example, in MBGP, these are routes whose Subsequent Address Family Identifier field indicates the route is valid for multicast traffic. 🔥
target: Either an EGP peer or an M-IGP component. 🎀
Tree State Table: This is a table of (S-prefix,G) and (*,G-prefix) entries that a set of targets has explicitly joined. Each entry has, besides the source and group addresses and masks, a list of targets that have explicitly requested data, either on behalf of directly connected hosts or downstream routers. (S,G) entries also have an "SPT" bit. 🧠
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [RFC2119]. 💖
3. Protocol Overview 🧚
okay so BGMP keeps track of group-prefix state whenever it hears from its BGMP peers, and it also listens to notifications from M-IGP components 💅. Group-shared trees are rooted at the domain advertising the group prefix that covers those groups 🌸. When a receiver joins a specific group address, the border router towards the root domain generates a group-specific Join message. That message gets forwarded Border-Router-by-Border-Router towards the root domain (peep Figure 1 🦋). BGMP Join and Prune messages travel over TCP connections between BGMP peers, and BGMP protocol state gets refreshed by KEEPALIVE messages that are periodically sent over TCP 💖.
BGMP routers build group-specific bidirectional forwarding state as they process the BGMP Join messages. Bidirectional forwarding state means that packets received from any target get forwarded to all other targets in the target list, and there are no RPF checks involved 🔥. No group-specific state or traffic exists in parts of the network where there are no members of that group 🙈.
BGMP routers optionally build source-specific unidirectional forwarding state, but only where it's needed. This makes them compatible with source-specific trees (SPTs) used by some M-IGPs (e.g., DVMRP, PIM-DM, or PIM-SM), or helps them construct trees for source-specific groups 🌈. A domain that uses an SPT-based M-IGP may need to inject multicast packets from external sources via different border routers (so it's compatible with the M-IGP RPF checks). Those routers act as "surrogates" 🫶. For example, in the Transit_1 domain, data from Src_A arrives at BR12, but it must be injected by BR11. A surrogate router may create a source-specific BGMP branch if no shared tree state exists.
Note: stub domains with a single border router, such as Rcvr_Stub_7 in Figure 1, receive all multicast data packets through that router, which is where all RPF checks point. Therefore, stub domains never build source-specific state 💀.
Root_Domain
[BR91]--------------------------\
| |
[BR32] [BR41]
Transit_3 Transit_4
[BR31] [BR42] [BR43]
| | |
[BR22] [BR52] [BR53]
Transit_2 Transit_5
[BR21] [BR51]
| |
[BR12] [BR61]
Transit_1[BR11]----------[BR62]Stub_6
[BR13] (Src_A)
| (Rcvr_D)
-------------------
| |
[BR71] [BR81]
Rcvr_Stub_7 Src_only_Stub_8
(Rcvr_C) (Src_B)Figure 1: Example inter-domain topology. [BRxy] represents a BGMP border router. Transit_X is a transit domain network. *_Stub_X is a stub domain network.
Data packets are forwarded based on a combination of BGMP and M-IGP rules ✨. The router forwards to a set of targets according to a matching (S,G) BGMP tree state entry if one exists. If not found, the 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 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 was found, the packet is forwarded to all other targets in the target list. This is how BGMP trees forward data in a bidirectional manner 🦋. If a target is an M-IGP component, then forwarding is subject to the rules of that M-IGP protocol.
3.1. Design Rationale 🎀
Several other protocols, or protocol proposals, build shared trees within domains [PIMSM, CBT]. The design choices made for BGMP come from our focus on Inter-Domain multicast in particular. The design choices made by PIM-SM and CBT are better suited to the wide-area intra-domain case. There are three major differences between BGMP and other shared-tree protocols:
(1) Unidirectional vs. Bidirectional trees 💅
Bidirectional trees (using bidirectional forwarding state as described above) minimize third party dependence, which is essential in the inter-domain context. For example, in Figure 1, stub domains 7 and 8 would like to exchange multicast packets without being dependent on the quality of connectivity of the root domain. However, unidirectional shared trees (i.e., those using RPF checks) have more aggressive loop prevention, and they share the same processing rules as source-specific entries, which are inherently unidirectional.
The lack of third party dependence concerns in the INTRA domain case reduces the incentive to employ bidirectional trees. BGMP supports bidirectional trees because it has to, and because it can without excessive cost 🍓.
(2) Source-specific distribution trees/branches 🦋
In a departure from other shared tree protocols, source-specific BGMP state is built ONLY where (a) it is needed to pull the multicast traffic down to a BGMP router that has source-specific (S,G) state, (b) that router is NOT already on the shared tree (i.e., has no (*,G) state), and (c) that router does not want to receive packets via encapsulation from a router which is on the shared tree. BGMP provides source-specific branches because most M-IGP protocols in use today build source-specific trees 🌸. BGMP's source-specific branches eliminate the unnecessary overhead of encapsulations for high data rate sources, from the shared tree's ingress router to the surrogate injector (e.g., from BR12 to BR11 in Figure 1). Moreover, cases in which shared paths are significantly longer than SPT paths will also benefit 🫶.
However, except for source-specific group distribution trees, we do not build source-specific inter-domain trees in general, because (a) inter-domain connectivity is generally less rich than intra-domain connectivity, so shared distribution trees should have more acceptable path length and traffic concentration properties in the inter-domain context than in the intra-domain case, and (b) by having the shared tree state always take precedence over source-specific tree state, we avoid ambiguities that could otherwise arise 🧠.
In summary, BGMP trees are, in a sense, a hybrid between PIM-SM and CBT trees 💜.
(3) Method of choosing root of group shared tree 👑
The choice of a group's shared-tree-root has implications for performance and policy. In the intra-domain case, it is sometimes assumed that all potential shared-tree roots (RPs/Cores) within the domain are equally suited to be the root for a group that is initiated within that domain. In the INTER-domain case, there is far more opportunity for unacceptably poor locality, and for administrative control of a group's shared-tree root. Therefore, in the intra-domain case, other protocols sometimes treat all candidate roots (RPs or Cores) as equivalent and emphasize load sharing and stability to maximize performance. In the Inter-Domain case, all roots are not equivalent, so we adopt an approach whereby a group's root domain is not random but is subject to administrative control 🔒.
4. Protocol Details 💖
In this section, we describe the detailed protocol that border routers perform. We assume that each border router conforms to the component-based model described in [INTEROP], modulo one correction to section 3.2 ("BGMP" Dispatcher), as follows:
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 🧚.
4.1. Interaction with the EGP 🌈
The fundamental requirements imposed by BGMP are that:
- For a given source-specific group and source, BGMP must be able to look up the next-hop towards the source in the Multicast RIB, and
- For a given non-source-specific group, BGMP will map the group address to a nominal "root" address, and must be able to look up the next-hop towards that address in the Multicast RIB.
BGMP determines the nominal "root" address as follows. If the multicast address is a Unicast-Prefix-based Multicast address, then the nominal root address is the embedded unicast prefix, padded with a suffix of 0 bits to form a full address 🦋.
For example, if the IPv6 group address is ff2e:0100:1234:5678:9abc:def0::123, then the unicast prefix is 1234:5678:9abc:def0/64, and the nominal root address would be 1234:5678:9abc:def0::. (This address is in fact the subnet router anycast address [IPv6AA].) 🫶
Support for any-source-multicast using any address other than a Unicast-prefix-based Multicast Address is outside the scope of this document 🙈.
4.2. Multicast Data Packet Processing 💅
For BGMP rules to be applied, an incoming packet must first be "accepted":
- If the packet arrived on an interface owned by an M-IGP, the M-IGP component determines whether the packet should be accepted or dropped according to its rules. If the packet is accepted, the packet is forwarded (or not forwarded) out any other interfaces owned by the same component, as specified by the M-IGP.
- If the packet was received over a point-to-point interface owned by BGMP, the packet is accepted.
- If the packet arrived on a multiaccess network interface owned by BGMP, the packet is accepted if it is receiving data on a source-specific branch, if it is the designated forwarder for the longest matching route for S, or for the longest matching route for the nominal root of G.
If the packet is accepted, then the router checks the tree state table for a matching (S,G) entry. If one is found, but the packet was not received from the next hop target towards S (if the entry's SPT bit is True), or was not received from the next hop target towards G (if the entry's SPT bit is False), then the packet is dropped and no further actions are taken 💀. If no (S,G) entry was found, the router then checks for a matching (*,G) entry.
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. If a matching entry was found, the packet is forwarded to all other targets in the target list 🌸.
Forwarding to a target which is an M-IGP component means that the packet is forwarded out any interfaces owned by that component, according to that component's multicast forwarding rules ✨.
4.3. BGMP processing of Join and Prune messages and notifications 🌟
4.3.1. Receiving Joins ✨
okay so when the BGMP component gets a (,G) or (S,G) Join alert from 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 🔍. If it finds one and that peer is already on the target list, no further actions are taken. it's already got you, bestie 🫶
Otherwise, if no (,G) or (S,G) entry was found, one gets created 💅. For a (,G), the target list gets initialized to contain the next-hop peer towards the nominal root of G, but only if that peer is an external peer. If the peer is internal, the target list gets initialized to contain the M-IGP component owning the next-hop interface. If there is no next-hop peer (because the nominal root of G is inside the domain), the target list gets initialized to contain the next-hop component.
Now the tricky part 👀 If an (S,G) entry already exists for the same G that the (,G) Join is being processed for, and the next-hop peers toward S and the nominal root of G are different, the BGMP router must first send an (S,G) Prune message toward the source and clear the SPT bit on the (S,G) entry, *before activating the (*,G) entry. the order really matters here, no cap 🙈
When creating (S,G) state, if the source is internal to the BGMP speaker's domain, a "Poison-Reverse" bit (PR-bit) gets set 🧚. This bit basically says the router might receive packets matching (S,G) anyway, because the BGMP speaker is a member of a domain on the path between S and the root domain. (Depending on the M-IGP protocol, it may in fact receive such packets anyway only if it is the best exit for the nominal root of G.) main character energy for the PR-bit, ngl ✨
The target the Join came from then gets added to the target list. Next, the router looks up S or the nominal root of G in the Multicast RIB to find the next-hop EGP peer. If the target list (not counting the next-hop target towards G for a (*,G) entry) becomes non-null because of this, the next-hop EGP peer must be notified like so:
a) If the next-hop peer towards the nominal root of G (for a (,G) entry) is an external peer, a BGMP (,G) Join message is unicast to the external peer. If the next-hop peer towards S (for an (S,G) entry) is an external peer, and the router does NOT have any active (,G) state for that group address G, a BGMP (S,G) Join message is unicast to the external peer. A BGMP (S,G) Join message is never sent to an external peer by a router that also contains active (,G) state for the same group. If the next-hop peer towards S (for an (S,G) entry) is an external peer and the router DOES have active (*,G) state for that group G, the SPT bit is always set to False. 🫠 so many rules, but they're all giving organization
b) If the next-hop peer is an internal peer, a (*,G) or (S,G) Join alert is sent to the M-IGP component owning the next-hop interface.
c) If there is no next-hop peer, a (*,G) or (S,G) Join alert is sent to the M-IGP component owning the next-hop interface.
Last bit for this one 💖 If an (S,G) Join is received from an internal peer, the peer should be stored with the M-IGP component target. If (S,G) state exists with the PR-bit set, and the next-hop towards the nominal root for G is through the M-IGP component, an (S,G) Poison-Reverse message is immediately sent to the internal peer.
If an (S,G) Join is received from an external peer, and (S,G) state exists with the PR-bit set, and the local BGMP speaker is the best exit for the nominal root of G, and the next-hop towards the nominal root for G is through the interface towards the external peer, an (S,G) Poison-Reverse message is immediately sent to the external peer. the vibes are super specific, but that's the whole point 💅
4.3.2. Receiving Prune Notifications 🌸
okay next up, Prunes. When the BGMP component receives a (,G) or (S,G) Prune alert from another component, or a BGMP (,G) or (S,G) Prune message from an external peer, it searches the tree state table for a matching entry. If no (S,G) entry was found for an (S,G) Prune, but (,G) state exists, an (S,G) entry gets created, with the target list copied from the (,G) entry. If no matching entry exists, or if the component or peer isn't on the target list, no further actions are taken. ngl, the "nothing to do" branch is lowkey the most relatable one 🙈
Otherwise, the component or peer gets removed from the target list. If the target list becomes null as a result, the next-hop peer towards the nominal root of G (for a (,G) entry), or towards S (for an (S,G) entry if and only if the BGMP router does NOT have any corresponding (,G) entry), must be notified like so:
a) If the peer is an external peer, a BGMP (*,G) or (S,G) Prune message is unicast to it.
b) If the next-hop peer is an internal peer, a (*,G) or (S,G) Prune alert is sent to the M-IGP component owning the next-hop interface.
c) If there is no next-hop peer, a (*,G) or (S,G) Prune alert is sent to the M-IGP component owning the next-hop interface.
4.3.3. Receiving Route Change Notifications 🦋
when a border router receives a route for a new prefix in the multicast RIB, or an existing route for a prefix gets withdrawn, a route change notification for that prefix must be sent to the BGMP component. And when the next hop peer (according to the multicast RIB) changes, a route change notification for that prefix must be sent to the BGMP component too. it's like a group chat that always needs to know what's going on 📣
In addition, in IPv4 (only), an internal route for each class-D prefix associated with the domain (if any) MUST be injected into the multicast RIB in the EGP by the domain's border routers. this one is a hard rule, so no skipping it 🔥
When a route for a new group prefix is learned, or an existing route for a group prefix is withdrawn, or the next-hop peer for a group prefix changes, a BGMP router updates all affected (,G) target lists. The router sends a (,G) Join to the new next-hop target, and a (*,G) Prune to the old next-hop target, as appropriate. Also, if any (S,G) state exists with the PR-bit set:
- If the BGMP speaker has just become the best exit for the nominal root of G, an (S,G) Poison Reverse message with the PR-bit set is sent as noted below.
- If the BGMP speaker was the best exit for the nominal root of G and is no longer, an (S,G) Poison Reverse message with the PR-bit clear is sent as noted below.
The (S,G) Poison-Reverse messages are sent to all external peers on the next-hop interface towards the nominal root of G from which (S,G) Joins have been received.
When an existing route for a source prefix is withdrawn, or the next-hop peer for a source prefix changes, a BGMP router updates all affected (S,G) target lists. The router sends an (S,G) Join to the new next-hop target, and an (S,G) Prune to the old next-hop target, as appropriate. ✨
4.3.4. Receiving (S,G) Poison-Reverse messages 🍓
When a BGMP speaker receives an (S,G) Poison-Reverse message from a peer, it sets the PR-bit on the (S,G) state to match the PR-bit in the message, and looks up the next-hop towards the nominal root of G. If the next-hop target is an M-IGP component, it forwards the (S,G) Poison Reverse message to all internal peers of that component from which it has received (S,G) Joins. If the next-hop target is an external peer on a given interface, it forwards the (S,G) Poison Reverse message to all external peers on that interface. passing the message along, very team player 🫶
When a BGMP speaker receives an (S,G) Poison-Reverse message from an external peer, with the PR-bit set, and the speaker has received no (S,G) Joins from any other peers (e.g., only from the M-IGP, or has (S,G) state due to encapsulation as described in 5.4.1), it knows that its own (S,G) Join is unnecessary, and should send an (S,G) Prune. so it's like "bestie, you don't need to join, I got this" 💅
When a BGMP speaker receives an (S,G) Poison-Reverse message from an internal peer, with the PR-bit set, and the speaker is the best exit for the nominal root of G, and has (S,G) prune state, an (S,G) Join message is sent to cancel the prune state and the state is deleted. a full glow-up arc, honestly 🦋
4.4. Interaction with M-IGP components 🧚
When an M-IGP component on a border router first learns that there are internally-reached members for a group G (whose scope is larger than that domain), a (,G) Join alert is sent to the BGMP component. Similarly, when an M-IGP component on a border router learns that there are no longer internally-reached members for a group G (whose scope is larger than a single domain), a (,G) Prune alert is sent to the BGMP component.
At any time, any M-IGP domain MAY decide to join a source-specific branch for some external source S and group G. When the M-IGP component in the border router that is the next-hop router for a particular source S learns that a receiver wishes to receive data from S on a source-specific path, an (S,G) Join alert is sent to the BGMP component. When it is learned that such receivers no longer exist, an (S,G) Prune alert is sent to the BGMP component. Quick reminder: the BGMP component will only generate external source-specific Joins where the source-specific branch does not coincide with the shared tree distribution tree for that group 🌈
Finally, we will require that the border router that is the next-hop internal peer for a particular address S or the nominal root of G be able to forward data for a matching tree state table entry to all members within the domain. This requirement has implications on specific M-IGPs as follows:
4.4.1. Interaction with DVMRP and PIM-DM ✨
okay so DVMRP and PIM-DM are both "broadcast and prune" protocols, and they are super strict 💅. Every data packet must pass an RPF check against the packet's source address, or it gets dropped 🙅♀️. If the border router receiving packets from an external source is the only BR injecting the route for that source into the domain, then we're literally good 🌸. This is always true for stub domains with a single border router (see Figure 1). Otherwise, the border router receiving packets externally is responsible for encapsulating the data to any other border routers that must inject the data into the domain, so the RPF checks succeed 🫶.
When an intended border router injector for a source gets encapsulated packets from another border router in its domain, it should create source-specific (S,G) BGMP state 🦋. The border router may be configured to do this on a data-rate triggered basis, so the state isn't created for very low data-rate or intermittent sources. If source-specific state is created, its incoming interface points to the virtual encapsulation interface from the border router that forwarded the packet, and it has an SPT flag that is initialized to False.
When the (S,G) BGMP state gets created, the BGMP component will send a BGMP (S,G) Join message to the next-hop external peer towards S, but only if there is no (*,G) state for that same group, G. The (S,G) BGMP state will have the SPT bit set to False if (*,G) BGMP state is present 🎀.
When the first data packet from S arrives from the external peer and matches the BGMP (S,G) state, and IF there is no (*,G) state, the router sets the SPT flag to True, resets the incoming interface to point to the external peer, and sends a BGMP (S,G) Prune message to the border router that was encapsulating the packets. For example, in Figure 1, BR11 sends the (Src_A,G) Prune to BR12. When the border router with (*,G) state receives the prune for (S,G), it deletes that border router from its list of targets 💀.
If the decapsulator receives an (S,G) Poison Reverse message with the PR-bit set, it forwards it to the encapsulator (which may again forward it up the shared tree according to normal BGMP rules), and both delete their BGMP (S,G) state 🧚.
PIM-DM and DVMRP have one more problem, and it's a big one 😭. No protocol mechanism exists for joining and pruning entire groups. Only joins and prunes for individual sources are available. As a result, BGMP does not currently support these protocols being used in a transit domain 🚫.
4.4.2. Interaction with PIM-SM 🌈
Protocols such as PIM-SM build unidirectional shared and source-specific trees. Just like with DVMRP and PIM-DM, every data packet must pass an RPF check against some group-specific or source-specific address 💅.
The fewest encapsulations and decapsulations happen when the intra-domain tree is rooted at the next-hop internal peer (which becomes the RP) towards the nominal root of G, since that router will generally receive the most packets from external sources 👑. To make this work, each BGMP border router to a PIM-SM domain should send Candidate-RP-Advertisements within the domain for those groups where it is the shared-domain tree ingress router. When the border router that is the RP for a group G receives an external data packet, it forwards the packet according to the M-IGP (i.e., PIM-SM) shared-tree outgoing interface list.
Other border routers will receive data packets from external sources that are farther down the bidirectional tree of domains. When a border router that is not the RP receives an external packet for which it has no source-specific entry, it treats the packet like a local source by creating (S,G) state with a Register flag set, based on normal PIM-SM rules. The border router then encapsulates the data packets in PIM-SM Registers and unicasts them to the RP for the group. As explained above, the RP for the inter-domain group will be one of the other border routers of the domain 🦋.
If a source's data rate is high enough, DRs within the PIM-SM domain may switch to the shortest path tree. If the shortest path to an external source goes through the group's ingress router for the shared tree, the new (S,G) state in the BGMP border router will not cause BGMP (S,G) Joins, because that border router already has (*,G) state. If, however, the shortest path to an external source goes through some other border router, that border router creates (S,G) BGMP state in response to the M-IGP (S,G) Join alert. In this case, there is no local (*,G) state to suppress it, so the border router sends a BGMP (S,G) Join to the next-hop external peer towards S, in order to pull the data down directly (see BR11 in Figure 1). As in normal PIM-SM operation, those PIM-SM routers that have (*,G) and (S,G) state pointing to different incoming interfaces will prune that source off the shared tree. Therefore, all internal interfaces may eventually be pruned off the internal shared tree 🌸.
After the border router sends a BGMP (S,G) Join, if its (S,G) state has the PR-bit clear, an (S,G) Poison-Reverse message (with the PR-bit clear) is sent to the ingress router for G. The ingress router then creates (S,G) if it doesn't already exist, and removes the next hop towards the nominal root of G from the target list ✨.
If the border router later receives an (S,G) Poison-Reverse message with the PR-bit set, the Poison-Reverse message is forwarded to the ingress router for G. The best-exit router then creates (S,G) state if it doesn't already exist, and puts the next hop towards the nominal root of G in the target list if it isn't already there 🫶.
4.4.3. Interaction with CBT 🍓
CBT builds bidirectional shared trees, but it has to deal with two compatibility issues with BGMP 🙈. First, CBT can not accommodate more than one border router injecting a packet. So if a CBT domain has multiple external connections, the M-IGP components of the border routers are responsible for making sure that only one of them injects data from any given source.
Second, CBT cannot process source-specific Joins or Prunes. That means there are two options for each CBT domain:
Option A: The CBT component interprets an (S,G) Join alert as if it were a (*,G) Join alert, as described in [INTEROP]. That is, if it is not already on the core-tree for G, it sends a CBT (*,G) JOIN-REQUEST message towards the core for G. Similarly, when the CBT component receives an (S,G) Prune alert and the child interface list for a group is NULL, it sends a (*,G) QUIT_NOTIFICATION towards the core for G. This option has the disadvantage of pulling all data for the group G down to the CBT domain when no members exist 😬.
Option B: The CBT domain does not propagate any routes to its external peers for the Multicast RIB unless it is known that no other path exists to that prefix (e.g., routes for prefixes internal to the domain or in a singly-homed customer's domain may be propagated). This makes sure source-specific joins are never received unless the source's data already passes through the domain on the shared tree, in which case the (S,G) Join doesn't need to be propagated anyway 💜. BGMP border routers will only send source-specific Joins or Prunes to an external peer if that external peer advertises source-prefixes in the EGP. If a BGMP-CBT border router does receive an (S,G) Join or Prune, that border router should ignore the message.
To minimize en/de-capsulations, CBTv2 BR's may follow the same scheme as described under PIM-SM above, in which Candidate-Core advertisements are sent for those groups where it is the shared-tree ingress router 🎀.
4.4.4. Interaction with MOSPF 🦋
As with CBTv2, MOSPF cannot process source-specific Joins or Prunes, so the same two options are available. Therefore, an MOSPF domain may either:
Option A: send a Group-Membership-LSA for all of G in response to an (S,G) Join alert, and "prematurely age" it out (when no other downstream members exist) in response to an (S,G) Prune alert, OR
Option B: not propagate any routes to their external peers for the Multicast RIB unless it is known that no other path exists to that prefix (e.g., routes for prefixes internal to the domain or in a singly-homed customer's domain may be propagated) 🌈
4.5. Operation over Multi-access Networks 🫧
Multiaccess links need special handling to prevent duplicates 😤. The following mechanism lets BGMP operate over multiaccess links that don't run an M-IGP. It avoids broadcast-and-prune behavior and doesn't require (S,G) state 💖.
To elect a designated forwarder per prefix, BGMP uses a FWDR_PREF message to exchange "forwarder preference" values for each prefix. The peer with the highest forwarder preference becomes the designated forwarder, with ties broken by lowest BGMP Identifier. The designated forwarder is the router responsible for forwarding packets up the tree, and it's the peer that joins get sent to 👑.
When BGMP first learns that a route exists in the multicast RIB whose next-hop interface is NOT the multiaccess link, the BGMP router sends a BGMP FWDR_PREF message for the prefix to all BGMP peers on the LAN. The FWDR_PREF message contains a "forwarder preference value" for the local router, and the same value MUST be sent to all peers on the LAN. Likewise, when the prefix is no longer reachable, a FWDR_PREF of 0 is sent to all peers on the LAN 🍓.
Whenever a BGMP router calculates the next-hop peer towards a particular address, and that peer is reached over a BGMP-owned multiaccess LAN, the designated forwarder is used instead 🧚.
When a BGMP router receives a FWDR_PREF message from a peer, it looks up the matching route in its multicast RIB and calculates the new designated forwarder. If the router has tree state entries whose parent target was the old forwarder, it sends Joins to the new forwarder and Prunes to the old forwarder 🔥.
When a BGMP router which is NOT the designated forwarder receives a packet on the multiaccess link, the packet is silently dropped 🤫.
Finally, this mechanism prevents duplicates where full peering exists on a "logical" link. Where full peering doesn't exist, steps must be taken outside of BGMP to present separate logical interfaces to BGMP, each of which is a link with full peering. This might entail, for example, using different link-layer address mappings, doing encapsulation, or changing the physical media 🌸 that's a lot of moving parts, bestie.
4.6. Interaction between (S,G) state and G-routes ✨
Okay so, routers with (*,G) state won't pass along (S,G) joins, we already covered that 💅. But there's a special case that's lowkey tricky: when (S,G) state lines up with the G-route (or the route toward the nominal root of G) 😭. When that happens, you have to be careful so the data actually reaches the root domain without making duplicates or black holes 🕳️. So the (S,G) state sitting on the path between the source and the root domain gets marked as "poison-reversed" 🧪. There's a PR-bit kept for exactly this, and it's updated by (UN)POISON_REVERSE messages 🎀.
The PR-bit is how BGMP nodes figure out whether they need to forward packets up toward the root domain 🌸. Picture this: there's an (S,G) branch, and a transit domain gets packets along it. That domain needs to know whether it should also send them up toward the root domain 👀. If the domain is on the path between S and the root domain, the answer is yes, and the PR bit is set on that S,G state 💖. If it's not on that path, the answer is no, and the PR bit is clear on the S,G state 🙅♀️. It's giving precision, honestly 👑.
5. Message Formats 🎀
Okay, this section is where the actual message formats live, so bestie, read carefully 🫶. Everything here is BGMP's packet layout.
Messages go over a reliable transport protocol connection 🦋. A message only gets processed after it's been entirely received, so no half-finished messages 🙅♀️. The maximum message size is 4096 octets 📏. Every implementation is required to support that maximum message size, no exceptions 💅.
All fields labelled "Reserved" below must be transmitted as 0, and ignored upon receipt 🫧. Reserved fields are the quiet ones, but they matter 🤫.
5.1. Message Header Format 🌈
Every message has a fixed-size (4-byte) header ✨. There may or may not be a data portion after the header, depending on the message type 🧚. Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Length: This 2-octet unsigned integer is the total length of the message, header included, in octets 📦. That's how you find the start of the next message in the transport stream 🧭. The value of the Length field must always be at least 4 and no greater than 4096, and it may be further constrained depending on the message type 📐. No "padding" of extra data is allowed after the message, so the Length field must have the smallest value required for the rest of the message 🤏. No extra fluff, bestie 💀.
Type: This 1-octet unsigned integer is the type code of the message 🏷️. These type codes are defined:
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE5.2. OPEN Message Format 🍓
After a transport protocol connection is established, the first message each side sends is an OPEN message 🤝. If the OPEN is acceptable, the other side sends back a KEEPALIVE to confirm it 💜. Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages can be exchanged 💬.
Besides the fixed-size BGMP header, the OPEN message has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Rsvd| AddrFam | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGMP Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ (Optional Parameters) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version: This 1-octet unsigned integer is the protocol version number of the message 🔢. The current BGMP version number is 1 ✅.
AddrFam: The IANA-assigned address family number of the BGMP Identifier 🌍. These include (among others):
Number Description
------ -----------
1 IP (IP version 4)
2 IPv6 (IP version 6)Hold Time: This 2-octet unsigned integer is the number of seconds the sender proposes for the Hold Timer ⏱️. When an OPEN message comes in, a BGMP speaker MUST calculate the Hold Timer by using the smaller of its configured Hold Time and the Hold Time received in the OPEN message 🧮. The Hold Time MUST be either zero or at least three seconds 🙅♀️. An implementation may reject connections based on the Hold Time 🚪. The calculated value is the maximum number of seconds that may pass between receiving successive KEEPALIVE and/or UPDATE messages from the sender 🫠.
BGMP Identifier: This 4-octet (for IPv4) or 16-octet (IPv6) unsigned integer is the BGMP Identifier of the sender 🪪. Each BGMP speaker sets its BGMP Identifier to a globally-unique value assigned to that speaker (for example, an IPv4 address) 🌐. The value is decided on startup and stays the same for every BGMP session opened 🔒.
Optional Parameters: This field may hold a list of optional parameters, and each one is encoded as a <Parameter Length, Parameter Type, Parameter Value> triplet 🧩. The combined length of all optional parameters can be worked out from the Length field in the message header 🧠.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Parm. Type | Parm. Length | Parameter Value (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...Parameter Type is a one-octet field that uniquely identifies each parameter 🔑. Parameter Length is a one-octet field holding the length of the Parameter Value field in octets 📏. Parameter Value is a variable-length field, and how it's read depends on the Parameter Type 👀.
This document defines the following Optional Parameters 📚:
a) Authentication Information (Parameter Type 1): This optional parameter may be used to authenticate a BGMP peer 🔐. The Parameter Value field has a 1-octet Authentication Code followed by variable-length Authentication Data 🛡️.
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| Auth. Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Authentication Code: This 1-octet unsigned integer shows which authentication mechanism is in use 🗝️. Whenever an authentication mechanism is specified for use within BGMP, three things must be included in the specification:
- the value of the Authentication Code which indicates use of the mechanism, and
- the form and meaning of the Authentication Data.
Wait, that's only two bullets in the original, so I'll keep it honest. Note that a separate authentication mechanism may be used when establishing the transport level connection 🚀.
Authentication Data: The form and meaning of this field is a variable-length field whose form and meaning depend on the Authentication Code 🧾.
The minimum length of the OPEN message is 12 octets, header included 📉.
b) Capability Information (Parameter Type 2): This is an Optional Parameter that a BGMP speaker uses to tell its peer which capabilities it supports 💪. The parameter contains one or more triples <Capability Code, Capability Length, Capability Value>, and each triple is encoded like this 🧃:
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+Capability Code: A one-octet field that uniquely identifies individual capabilities 🆔.
Capability Length: A one-octet field holding the length of the Capability Value field in octets 📐.
Capability Value: A variable-length field, interpreted according to the value of the Capability Code field 🎁.
A particular capability, identified by its Capability Code, may show up more than once within the Optional Parameter 🔁.
This document reserves Capability Codes 128-255 for vendor-specific applications 🏭. This document also reserves value 0 🚧.
Capability Codes (other than those reserved for vendor-specific use) are assigned only through the IETF consensus process and IESG approval 🗳️. Not just anyone gets to pick a code, iykyk 👑.
5.3. UPDATE Message Format ✨
okay so UPDATE messages are how BGMP peers swap their Join/Prune/FwdrPref info 💌 every UPDATE always has the fixed-size BGMP header, plus one or more attributes (more on those below).
the layout is super compact for (*,G) Joins and Prunes, but it's also flexible enough for other updates, like (S,G) Joins and Prunes going towards sources and on the shared tree 🌳 below, an Encoded-Address-Prefix looks like this:
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
+-+-+-+-+-+-+-+-+
|EnTyp| AddrFam |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the EnTyp field has three flavours 🍓
EnTyp:
0 - All 1's Mask. The Mask field is 0 bytes long.
1 - Mask length included. The Mask field is 4 bytes long, and
contains the mask length, in bits.
2 - Full Mask included. The Mask field is the same length
as the Address field, and contains the full bitmask.AddrFamis the IANA-assigned address family number of the encoded prefix 🌍Addressis the address tied to the prefix being encoded. its length depends on the Address Family, so no guessing 🙃Maskis the mask tied to the prefix. whether it's there at all (or what shape it takes) is decided byEnTyp💅
every attribute looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+all attributes are 4-byte aligned 📐
Lengthis the length of the entire attribute, counting the length, type, and data fields. if other attributes are nested inside the data field, the length covers all of those nested attributes too 🪆Typeis where it gets spicy 🌶️ types 128-255 are reserved for "optional" attributes. if a required attribute is unrecognised, a NOTIFICATION will be sent, and the connection will be closed if the error is a fatal one. unrecognised optional attributes are simply ignored 🫶
the type codes are:
0 - JOIN
1 - PRUNE
2 - GROUP
3 - SOURCE
4 - FWDR_PREF
5 - POISON_REVERSEa) JOIN (Type Code 0)
the JOIN attribute says that all GROUP or SOURCE options nested right inside it should be joined 🤝
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+no JOIN, PRUNE, or FWDR_PREF attributes may be immediately nested within a JOIN attribute 🚫
b) PRUNE (Type Code 1)
the PRUNE attribute says that all GROUP or SOURCE attributes nested right inside it should be pruned ✂️
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+no JOIN, PRUNE, or FWDR_PREF attributes may be immediately nested within a PRUNE attribute 🙅♀️
c) GROUP (Type Code 2)
the GROUP attribute identifies a given group-prefix 🎯 any attributes nested right inside it also apply to that group-prefix 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Encoded-Address-Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Encoded-Address-Prefix: the multicast group prefix to be joined to or pruned, in the format described above 🧁Nested Attributes: no GROUP, SOURCE, or FWDR_PREF attributes may be immediately nested within a GROUP attribute 🙅
d) SOURCE (Type Code 3):
the SOURCE attribute identifies a given source-prefix 🔭 any attributes nested right inside it also apply to that source-prefix ✨
the SOURCE attribute looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| Encoded-Address-Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Encoded-Address-Prefix: the Source-prefix in the format described above 🌊Nested Attributes: no GROUP, SOURCE, or FWDR_PREF attributes may be immediately nested within a SOURCE attribute 🙅♀️
e) FWDR_PREF (Type Code 4)
the FWDR_PREF attribute gives a forwarder preference value for all GROUP or SOURCE attributes nested right inside it 👑 a BGMP speaker uses it to tell other BGMP speakers how much the originating speaker prefers a given group or source prefix. the details on using it are in 5.5 📖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Preference Value: a 32-bit non-negative integer 🔢Nested Attributes: no JOIN, PRUNE, or FWDR_PREF attributes may be immediately nested within a FWDR_PREF attribute 🚫
e) POISON_REVERSE (Type Code 5)
the POISON_REVERSE attribute carries a "poison-reverse" (PR-bit) value for all SOURCE attributes nested right inside it 🧪 a BGMP speaker uses it to tell other BGMP speakers it has received (S,G) Joins from that they are on the path of domains between the source and the root domain 🛤️
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type=1 | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P: the PR-bit value 🎀Nested Attributes: no attributes in the document other than SOURCE may be immediately nested within a POISON_REVERSE attribute 💅
5.4. Encoding examples 🧩
here are some bite-sized examples of how different updates get built with nested attributes. A ( B ) means attribute B is nested inside attribute A 🪆
(*,G-prefix) Join: JOIN ( GROUP )
(*,G-prefix) Prune: PRUNE ( GROUP )
(S,G) Join towards S : 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 root of G: GROUP ( PRUNE ( SOURCE ) )
Switch from (*,G) to (S,G): PRUNE ( GROUP ( JOIN ( SOURCE ) ) )
Switch from (S,G) to (*,G): JOIN ( GROUP )
Initial (*,G) Join with S pruned: JOIN ( GROUP ( PRUNE ( SOURCE ) ) )
Forwarder preference announcement for G-prefix: FWDR_PREF ( GROUP )
Forwarder preference announcement for S-prefix: FWDR_PREF ( SOURCE )5.5. KEEPALIVE Message Format 💜
BGMP doesn't use any transport protocol-based keep-alive mechanism to check if peers are reachable 🙅♀️ instead, KEEPALIVE messages get swapped often enough that the Hold Timer never expires ⏰ a reasonable maximum gap between the last KEEPALIVE or UPDATE message sent and the next KEEPALIVE is one third of the Hold Time interval 🧮 KEEPALIVE messages MUST NOT be sent more frequently than one per second 🛑 an implementation MAY adjust how often it sends KEEPALIVE messages based on the Hold Time interval 🔧
if the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent. 💀
and the KEEPALIVE message itself is just a message header, 4 octets long 🫶
5.6. NOTIFICATION Message Format 💌
okay so a NOTIFICATION message gets sent when something goes wrong 🚨 and if the problem is fatal, the BGMP connection gets closed right after it's sent. no cap, this is the "we are NOT ignoring this" message 💅
besides the fixed-size BGMP header, the NOTIFICATION message has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O| Error code | Error subcode | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+O-bit 🦋: the Open-bit. if it's clear, the connection gets closed. if it's set, it just means the error isn't fatal.
Error Code 🎀: this is a 1-octet unsigned integer that tells you what kind of NOTIFICATION it is. these are the codes that exist:
Error Code Symbolic Name Reference
1 Message Header Error Section 9.1
2 OPEN Message Error Section 9.2
3 UPDATE Message Error Section 9.3
4 Hold Timer Expired Section 9.5
5 Finite State Machine Error Section 9.6
6 Cease Section 9.7Error Subcode 🔍: also a 1-octet unsigned integer, and it gets more specific about what went wrong. each Error Code can have one or more subcodes. if there's no subcode that fits, you use zero (Unspecific) 🫶. the (MC) tag means the error is fatal and the O-bit has to be clear. the non-fatal subcodes SHOULD be sent with the O-bit set 🌸
Message Header Error subcodes:
2 - Bad Message Length (MC)
3 - Bad Message Type (MC)OPEN Message Error subcodes:
1 - Unsupported Version (MC)
4 - Unsupported Optional Parameter
5 - Authentication Failure (MC)
6 - Unacceptable Hold Time (MC)
7 - Unsupported Capability (MC)UPDATE Message Error subcodes:
1 - Malformed Attribute List (MC)
2 - Unrecognized Attribute Type
5 - Attribute Length Error (MC)
10 - Invalid Address
11 - Invalid Mask
13 - Unrecognized Address FamilyData 📦: this variable-length field helps diagnose why the NOTIFICATION was sent. what's in it depends on the Error Code and Error Subcode. check Section 7 below for the deets ✨
also, the length of the Data field can be figured out from the message Length field with this formula:
Message Length = 6 + Data Lengththe minimum length of a NOTIFICATION message is 6 octets (header included) 💜
6. BGMP Error Handling ✨
this section covers what to do when errors pop up while BGMP messages are being processed 🔥 it's kind of like BGP [BGP] honestly, so if you know that one, you're already halfway there 🧚
when any of these conditions get detected, a NOTIFICATION message goes out with the right Error Code, Error Subcode, and Data fields, and the BGMP connection gets closed if the error is fatal. if no Error Subcode is specified, you must use zero 💅
"the BGMP connection is closed" just means the transport protocol connection is closed AND all the resources for that BGMP connection have been freed up 🧹 the remote peer also gets removed from the target list of every tree state entry. bye bye 👋
unless it's specified explicitly, the Data field of a NOTIFICATION sent for an error is empty 🫧
6.1. Message Header error handling 📨
every error found while processing the Message Header gets reported by sending a NOTIFICATION with Error Code Message Header Error. the Error Subcode tells you exactly what kind of header problem it was 🔍
so here's the deal: if the Length field of the message header is less than 4 or greater than 4096, OR the Length field of an OPEN message is less than the minimum OPEN length, OR the Length field of an UPDATE message is less than the minimum UPDATE length, OR the Length field of a KEEPALIVE message isn't equal to 4, then the Error Subcode is Bad Message Length. the Data field holds the wrong Length field 🙈
if the Type field of the message header isn't recognized, the Error Subcode is Bad Message Type. the Data field holds the wrong Type field 💀
6.2. OPEN message error handling 🎀
every error found while processing the OPEN message gets reported by sending a NOTIFICATION with Error Code OPEN Message Error. again, the Error Subcode is what makes it specific ✨
if the version number in the Version field of the received OPEN message isn't supported, the Error Subcode is Unsupported Version Number. the Data field is a 2-octet unsigned integer, and it holds the largest locally supported version number that's still less than the version the remote BGMP peer bid (the one in the received OPEN message) 🦋
if the Hold Time field of the OPEN message is unacceptable, the Error Subcode MUST be set to Unacceptable Hold Time. an implementation MUST reject Hold Time values of one or two seconds 🙅♀️ an implementation MAY reject any proposed Hold Time. and an implementation that accepts a Hold Time MUST use the negotiated value for the Hold Time 🤝
if one of the Optional Parameters in the OPEN message isn't recognized, the Error Subcode is set to Unsupported Optional Parameters 🧩
if the OPEN message carries Authentication Information (as an Optional Parameter), the matching authentication procedure gets invoked. if that procedure fails (based on the Authentication Code and Authentication Data), the Error Subcode is Authentication Failure 🔐
if the OPEN message says the peer doesn't support a capability the receiver needs, the receiver may send a NOTIFICATION to the peer and terminate peering. the Error Subcode is Unsupported Capability. the Data field lists the set of capabilities that made the speaker send the message, and each one is encoded the same way it was in the received OPEN message 📋
6.3. UPDATE message error handling 🌈
every error found while processing the UPDATE message gets reported by sending a NOTIFICATION with Error Code UPDATE Message Error. the error subcode says what exactly went wrong 🔍
if any recognized attribute has an Attribute Length that conflicts with the expected length (based on the attribute type code), the Error Subcode is Attribute Length Error. the Data field holds the erroneous attribute (type, length and value) 📦
if the Encoded-Address-Prefix field in some attribute is syntactically incorrect, the Error Subcode is Invalid Prefix Field 🫠
if anything else is encountered while processing attributes (like invalid nestings), the Error Subcode is Malformed Attribute List, and the problematic attribute gets included in the data field 🧶
6.4. NOTIFICATION message error handling 🫣
okay this one is kinda sad 😭 if a peer sends a NOTIFICATION and there's an error IN that message, there's unfortunately no way to report that error with another NOTIFICATION. any error like that (an unrecognized Error Code or Error Subcode, for example) should be noticed, logged locally, and brought to the attention of the peer's administration. HOW you do that, though, is outside the scope of this document 🤷♀️
6.5. Hold Timer Expired error handling ⏰
if a system doesn't receive successive KEEPALIVE and/or UPDATE and/or NOTIFICATION messages within the period in the Hold Time field of the OPEN message, then a NOTIFICATION with the Hold Timer Expired Error Code must be sent and the BGMP connection closed 💤
6.6. Finite State Machine error handling 🌀
any error detected by the BGMP Finite State Machine (say, getting an unexpected event) gets reported by sending a NOTIFICATION with Error Code Finite State Machine Error 🎢
6.7. Cease 🌷
if there are no fatal errors (the ones covered in this section), a BGMP peer may decide at any time to close its BGMP connection by sending a NOTIFICATION with Error Code Cease. BUT the Cease NOTIFICATION must not be used when a fatal error from this section actually exists 🚫
6.8. Connection collision detection 💞
if a pair of BGMP speakers try to set up a TCP connection to each other at the same time, two parallel connections between them might end up getting formed. this is called connection collision 💥 and obviously one of those connections has to be closed.
so there's a convention based on the BGMP Identifier for figuring out which connection to keep when a collision happens. you compare the BGMP Identifiers of the peers involved and only keep the connection initiated by the speaker with the higher-valued BGMP Identifier 👑
when an OPEN message comes in, the local system has to look at all of its connections in the OpenConfirm state. a BGMP speaker may also check connections in an OpenSent state if it knows the peer's BGMP Identifier by some means outside the protocol. if one of those connections goes to a remote BGMP speaker whose BGMP Identifier equals the one in the OPEN message, the local system runs this collision resolution procedure:
- the local BGMP Identifier gets compared to the remote system's BGMP Identifier (as given in the OPEN message) 🔎
- if the local BGMP Identifier is less than the remote one, the local system closes the BGMP connection that already exists (the one already in the OpenConfirm state), and accepts the BGMP connection the remote system started 🫶
- otherwise, the local system closes the newly created BGMP connection (the one tied to the newly received OPEN message), and keeps using the existing one (the one already in the OpenConfirm state) 🙌
comparing BGMP Identifiers works by treating them as (4-octet long) unsigned integers 🔢
a connection collision with an existing BGMP connection that's in the Established state causes the newly created connection to get closed, no questions asked 🚪 and a connection collision can't be detected with connections that are in the Idle, Connect, or Active states, so don't even try 🙅♀️
closing the BGMP connection (as the result of the collision resolution procedure) is done by sending a NOTIFICATION with the Error Code Cease 💜
7. BGMP Version Negotiation ✨
okay so BGMP speakers can negotiate the version 💅 they try to open a connection, starting with the highest version number each one supports. if an open attempt fails with Error Code OPEN Message Error and Error Subcode Unsupported Version Number, the speaker now has the version it tried, the version its peer tried, the version the peer sent back in the NOTIFICATION message, and the versions it supports itself. if the two peers have one or more versions in common, this lets them figure out the highest common version super fast 🏃♀️💨. to make this work, future versions of BGMP have to keep the format of the OPEN and NOTIFICATION messages 🎀
7.1. BGMP Capability Negotiation
when a BGMP speaker sends an OPEN message to its BGMP peer, the message can include an Optional Parameter called Capabilities 🧚 this parameter lists the capabilities the speaker supports.
a BGMP speaker can use a particular capability with another speaker only if both speakers support it 🫶 a speaker figures out what its peer supports by looking at the list of capabilities in the Capabilities Optional Parameter that comes in the OPEN message it receives from that peer. it's giving fair play energy 💖
8. BGMP Finite State machine 🦋
okay this section is the big one 😭 it describes how BGMP behaves using a Finite State Machine (FSM). below is a quick recap of what BGMP does in each state, according to this FSM.
BGMP starts out in the Idle state.
Idle state:
in this state BGMP turns away every incoming BGMP connection 🙅♀️ no resources get allocated to the peer. when the Start event shows up (triggered by either the system or an operator), the local system sets up all of its BGMP resources, starts the ConnectRetry timer, and kicks off a transport connection to the other BGMP peer. while that's happening it also listens for a connection the remote BGMP peer might start, and then it switches to Connect. the exact value of the ConnectRetry timer is up to the local system 🌸 but it's supposed to be big enough to give TCP time to initialize.
if a BGMP speaker detects an error, it shuts the connection down and goes back to Idle. getting out of Idle takes a Start event. if that event gets generated automatically, persistent BGMP errors can cause persistent flapping 😵💫 to avoid that, it is recommended that Start events not be generated right away for a peer that was previously sent to Idle because of an error. for a peer like that, the time between consecutive Start events, if they're generated automatically, shall go up exponentially. the initial timer value shall be 60 seconds, and the time gets doubled for each consecutive retry 📈
any other event that shows up in the Idle state gets ignored 🙈
Connect state:
in this state BGMP is waiting for the transport protocol connection to finish ⏳
if the transport protocol connection succeeds, the local system clears the ConnectRetry timer, finishes its initialization, sends an OPEN message to its peer, and moves to OpenSent. if the transport protocol connect fails (for example, a retransmission timeout), the local system restarts the ConnectRetry timer, keeps listening for a connection the remote BGMP peer might start, and moves to the Active state 🌈
when the ConnectRetry timer expires, the local system restarts the ConnectRetry timer, starts a transport connection to the other BGMP peer, keeps listening for a connection the remote BGMP peer might start, and stays in Connect 💜
the Start event gets ignored in Connect 🙅♀️
for any other event (from the system or an operator), the local system releases all BGMP resources tied to this connection and goes back to Idle 💔
Active state:
in this state BGMP is trying to grab a peer by listening for an incoming transport protocol connection 👀
if the transport protocol connection succeeds, the local system clears the ConnectRetry timer, finishes initialization, sends an OPEN message to its peer, sets its Hold Timer to a large value, and moves to OpenSent. a Hold Timer value of 4 minutes is suggested ⭐
when the ConnectRetry timer expires, the local system restarts the ConnectRetry timer, starts a transport connection to the other BGMP peer, keeps listening for a connection the remote BGMP peer might start, and moves to Connect.
if the local system notices that a remote peer is trying to set up a BGMP connection, and that peer's IP address isn't an expected one, the local system restarts the ConnectRetry timer, rejects the attempted connection, keeps listening for a connection from the remote BGMP peer, and stays in Active 🚫
the Start event gets ignored in Active 🙈
for any other event (from either the system or an operator), the local system releases all BGMP resources tied to this connection and goes back to Idle 💔
OpenSent state:
in this state BGMP waits for an OPEN message from its peer 📬 when one arrives, every field gets checked for correctness. if the BGMP message header checking or the OPEN message checking finds an error (see Section 6.2), or if there's a connection collision (see Section 6.8), the local system sends a NOTIFICATION message and goes back to Idle 🚨
if there are no errors in the OPEN message, BGMP sends a KEEPALIVE message and sets a KeepAlive timer 💖 the Hold Timer, which was originally set to a large value (see above), gets replaced with the negotiated Hold Time value (see section 4.2). if the negotiated Hold Time value is zero, the Hold Time timer and the KeepAlive timer don't get started. if the configured remote Autonomous System value for this peering matches the local Autonomous System number, the connection is an "internal" connection 🏠 otherwise it's "external" ✈️ finally, the state changes to OpenConfirm 🎉
if a disconnect notification comes in from the underlying transport protocol, the local system closes the BGMP connection, restarts the ConnectRetry timer, keeps listening for a connection the remote BGMP peer might start, and goes into Active 💔
if the Hold Timer expires, the local system sends a NOTIFICATION message with the error code Hold Timer Expired and goes back to Idle ⏰
in response to the Stop event (from either the system or an operator), the local system sends a NOTIFICATION message with Error Code Cease and goes back to Idle 🛑
the Start event gets ignored in OpenSent 🙈
for any other event, the local system sends a NOTIFICATION message with Error Code Finite State Machine Error and goes back to Idle 😭
whenever BGMP changes its state from OpenSent to Idle, it closes the BGMP (and transport-level) connection and releases all resources tied to that connection 🧹
OpenConfirm state:
in this state BGMP waits for a KEEPALIVE or NOTIFICATION message 👂
if the local system receives a KEEPALIVE message, it changes its state to Established 🥳
if the Hold Timer expires before a KEEPALIVE message arrives, the local system sends a NOTIFICATION message with the error code Hold Timer Expired and goes back to Idle ⏰
if the local system receives a NOTIFICATION message, it changes its state to Idle.
if the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer 💓
if a disconnect notification comes in from the underlying transport protocol, the local system changes its state to Idle.
in response to the Stop event (from either the system or an operator), the local system sends a NOTIFICATION message with Error Code Cease and goes back to Idle 🛑
the Start event gets ignored in OpenConfirm 🙈
for any other event, the local system sends a NOTIFICATION message with Error Code Finite State Machine Error and goes back to Idle 😭
whenever BGMP changes its state from OpenConfirm to Idle, it closes the BGMP (and transport-level) connection and releases all resources tied to that connection 🧹
Established state:
in the Established state, BGMP can swap UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer 💬
if the local system receives an UPDATE or KEEPALIVE message, it restarts its Hold Timer, as long as the negotiated Hold Time value isn't zero 🔄
if the local system receives a NOTIFICATION message, it changes its state to Idle.
if the local system receives an UPDATE message and the UPDATE message error handling procedure (see Section 6.3) detects an error, the local system sends a NOTIFICATION message and changes its state to Idle 🚨
if a disconnect notification comes in from the underlying transport protocol, the local system changes its state to Idle.
if the Hold Timer expires, the local system sends a NOTIFICATION message with Error Code Hold Timer Expired and goes back to Idle ⏰
if the KeepAlive timer expires, the local system sends a KEEPALIVE message and restarts its KeepAlive timer 💓
every time the local system sends a KEEPALIVE or UPDATE message, it restarts its KeepAlive timer, unless the negotiated Hold Time value is zero ⏱️
in response to the Stop event (from either the system or an operator), the local system sends a NOTIFICATION message with Error Code Cease and goes back to Idle 🛑
the Start event gets ignored in Established 🙈
in response to any other event, the local system sends a NOTIFICATION message with Error Code Finite State Machine Error and goes back to Idle 😭
whenever BGMP changes its state from Established to Idle, it closes the BGMP (and transport-level) connection, releases all resources tied to that connection, and deletes all routes that came from that connection 🗑️💅
9. Security Considerations 🔐
okay bestie, this is the dramatic part 😭 if a BGMP speaker accepts messages that are unauthorized or altered, it can end up with denial of service. That shows up as excess bandwidth eating everything, or as losing multicast connectivity entirely 💀. Authentication of BGMP messages is what protects against this behavior 🛡️
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.
⚠️ bestie, read that last part twice. A mismatch on Keyed MD5 means the connection should not come up at all 🙅♀️
ngl this is a weak security mechanism 🥺 it's still possible to get denial of service through messages that get relayed by a trusted peer. BUT, and this is the lowkey iconic part, it's the exact same model as the security mechanism BGP already uses in practice 💅 the authors expect future work to bring in stronger mechanisms for these problems in routing protocols ✨
10. Acknowledgements 🫶
so many people helped design BGMP and I'm obsessed with this list 🌸 in addition to the editor, these folks contributed to the design: Cengiz Alaettinoglu, Tony Ballardie, Steve Casner, Steve Deering, Deborah Estrin, Dino Farinacci, Bill Fenner, Mark Handley, Ahmed Helmy, Van Jacobson, Dave Meyer, and Satish Kumar 👑
this document came out of the IETF BGMP Working Group, with Dave Thaler as editor 🧚
and Rusty Eddy, Isidor Kouvelas, and Pavlin Radoslavov also gave valuable feedback on it 💜
11. References 📚
11.1. Normative References
[INTEROP] Thaler, D., "Interoperability Rules for Multicast Routing
Protocols", RFC 2715, October 1999.
[RFC2385] Heffernan, A., "Protection of BGP sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2119] Bradner, S., "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", RFC 3306, August 2002.11.2. Informative References
[BGP] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-
4)", RFC 1771, March 1995.
[MBGP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[CBT] Ballardie, A., "Core Based Trees (CBT version 2) Multicast
Routing -- Protocol Specification", RFC 2189, September
1997.
[DVMRP] Pusateri, T., "Distance Vector Multicast Routing
Protocol", Work in Progress, October 2003.
[IPv6AA] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
1994.
[PIMDM] Adams, A., Nicholas, J. and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", Work in Progress, September
2003.
[PIMSM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification", RFC 2362, June 1998.
[REFLECT] Bates, T. and R. Chandra, "BGP Route Reflection: An
alternative to full mesh IBGP", RFC 1966, June 1996.
[V4PREFIX] Thaler, D., "Unicast-Prefix-based IPv4 Multicast
Addresses", Work in Progress, August 2004.Authors' Address 💌
Dave Thaler
Microsoft
One Microsoft Way
Redmond, WA 98052
EMail: dthaler@microsoft.comFull Copyright Statement 📜
the legal bits are important, so here's the copyright statement exactly as written ✨
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property 🧠
the IETF's IP stuff, kept complete 💅 the IETF doesn't take a position on the validity or scope of any Intellectual Property Rights that might be claimed for this technology, and it hasn't made any independent effort to find them either. Procedures for rights in IETF Documents are in BCP 78 and BCP 79.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.Acknowledgement ✨
last one, and it's a funding note 🎀 funding for the RFC Editor function is currently provided by the Internet Society 🌈
📦 where this page comes from
- ietf: rfc3913 2004-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms