RFC 2201
Core Based Trees (CBT) Multicast Routing Architecture
Core Based Trees (CBT) Multicast Routing Architecture 🎀
okay bestie, this is RFC 2201 💖 It was written by A. Ballardie (a consultant) and published in September 1997. It's filed as Experimental, so it's an experiment, not an Internet standard 🧪 It doesn't list anything it obsoletes or updates, so it's a fresh start ✨
Status of This Memo 🌸
this memo defines an Experimental Protocol for the Internet community. it does not specify an Internet standard of any kind. discussion and suggestions for improvement are requested. distribution of this memo is unlimited 💅
Abstract 🦋
okay so CBT is a multicast routing architecture that builds one delivery tree per group, and every sender and receiver in that group shares it 🌳 most multicast algorithms do it differently. they build one multicast tree per sender (subnetwork), rooted at that sender's subnetwork. the big win for the shared tree approach is that it usually scales way better than all the other multicast algorithms 📈 literally iconic
the CBT protocol [1] is a network layer multicast routing protocol. it builds and maintains a shared delivery tree for a multicast group 🧚 hosts on a subnetwork sending and receiving multicast data follow the traditional IP multicast service model [2] 💜
CBT is going through the IDMR working group of the IETF 👑 the CBT protocol is described in an accompanying document [1]. for this one and all the other IDMR-related docs, check http://www.cs.ucl.ac.uk/ietf/idmr 🔗
Table of Contents 🍓
1. Background................................................... 2
2. Introduction................................................. 2
3. Source Based Tree Algorithms................................. 3
3.1 Distance-Vector Multicast Algorithm...................... 4
3.2 Link State Multicast Algorithm........................... 5
3.3 The Motivation for Shared Trees.......................... 5
4. CBT - The New Architecture................................... 7
4.1 Design Requirements...................................... 7
4.2 Components & Functions................................... 8
4.2.1 CBT Control Message Retransmission Strategy........ 10
4.2.2 Non-Member Sending................................. 11
5. Interoperability with Other Multicast Routing Protocols ..... 11
6. Core Router Discovery........................................ 11
6.1 Bootstrap Mechanism Overview............................. 12
7. Summary ..................................................... 13
8. Security Considerations...................................... 13
Acknowledgements ............................................... 14
References ..................................................... 14
Author Information.............................................. 151. Background 🕰️
okay so shared trees were first described by Wall, who was looking into low-delay approaches to broadcast and selective broadcast [3] ✨ Wall concluded that the delay won't be minimal like it is with shortest-path trees, but it can be kept within bounds that might be acceptable 🤏
back then nobody fully got what multicast was for, and it wasn't until much later that the IP multicast address space got defined (class D space [4]) 🙈 Deering's work [2] in the late 1980's was seriously pioneering. he defined the IP multicast service model and invented algorithms that let hosts arbitrarily join and leave a multicast group 👑 all of Deering's multicast algorithms build source-rooted delivery trees, with one delivery tree per sender subnetwork. they're all documented in [2] 📚
after several years of real-world multicast experience, we see a whole diversity of multicast applications and, to match, a wide variety of multicast application requirements 🌈 for example, distributed interactive simulation (DIS) applications have strict requirements for join latency, group membership dynamics, and group sender populations. they're way beyond what a lot of other multicast applications need 😭
the multicast-capable part of the Internet, the MBONE, keeps growing fast 🚀 the obvious popularity and growth of multicast means we can't overlook the scaling aspects of wide-area multicasting. some predictions say there could be thousands of groups present at any one time on the Internet 💀
we judge scalability by network state maintenance, bandwidth efficiency, and protocol overhead. other factors that can change these parameters include sender set size and how widely the group members are spread across the wide area 🦋
2. Introduction 🧚
multicasting on the local subnetwork doesn't need a multicast router or a multicast routing algorithm 🫶 on most shared media (e.g. Ethernet), a host (which doesn't have to be a group member!) just sends a multicast data packet, and every member host connected to the same medium receives it 📡
for multicasts to reach past the local subnetwork, the subnet needs a multicast-capable router attached. that router is attached (possibly "virtually") to another multicast-capable router, and so on 🔗 the collection of these (virtually) connected multicast routers forms the Internet's MBONE 🌸
all multicast routing protocols use IGMP [5], which operates between hosts and the multicast router(s) on the same subnetwork 🧠 IGMP lets the subnet's multicast router(s) monitor group membership on its directly attached links. that way, when multicast data shows up, the router knows which of its links to copy the packet onto 💅
so far we've been assuming that every multicast router on the MBONE runs the same multicast routing protocol. plot twist: that's not the case 😳 the MBONE is a collection of autonomously administered multicast regions, and each region is defined by one or more multicast-capable border routers. each region independently picks whichever multicast routing protocol best suits its needs ✨ the regions connect through the "backbone region", which currently runs the Distance Vector Multicast Routing Protocol (DVMRP) [6]. which means a region's border router(s) have to interoperate with DVMRP 🤝
different algorithms use different techniques to set up a distribution tree. if we sort these algorithms into source-based tree algorithms and shared tree algorithms, the classes have really different scaling characteristics. the resulting trees differ too, for example in average delay 📊 let's look at source-based tree algorithms first 👀
3. Source-Based Tree Algorithms 🌊
the strategy we'll use to motivate (CBT) shared tree multicast is partly based on explaining the characteristics of source-based tree multicast, especially its scalability 🎯
most source-based tree multicast algorithms are often called "dense-mode" algorithms. they assume the receiver population densely fills the domain of operation, so the overhead (in state, bandwidth usage, and/or processing costs) is justified 💪 that might be true in a local environment, but wide-area group membership tends to be sparsely spread across the Internet 🌍 there can be "pockets" of denseness, but if you look at the global picture, wide-area groups are sparse 🫠
source-based multicast trees get built either by a distance-vector style algorithm (which might run separately from the unicast routing algorithm, like with DVMRP), or by using the information already in the underlying unicast routing table (like with PIM-DM [7]). the other algorithm for building source-based trees is the link-state algorithm (M-OSPF [8] is one protocol instance of it) 🧩
3.1. Distance-Vector Multicast Algorithm ✨
the distance-vector multicast algorithm builds a multicast delivery tree using a variant of the Reverse-Path Forwarding technique [9] 🔁 here's the basic idea: when a multicast router gets a multicast data packet, if the packet arrives on the interface used to reach the packet's source, it gets forwarded out every outgoing interface, except leaf subnets with no members attached 🙌 a "leaf" subnet is one that no router would use to reach the source of a multicast packet. if the data packet doesn't arrive over the link that would be used to reach the source, it gets thrown away 🗑️
this is the "broadcast & prune" approach to multicast tree construction 🌳✂️ when a data packet reaches a leaf router and that router has no membership registered on any of its directly attached subnetworks, the router sends a prune message one hop back toward the source. the receiving router then checks its leaf subnets for group membership, and checks whether it has received a prune from all of its downstream routers (downstream with respect to the source). if it has, the router itself can send a prune upstream over the interface leading to the source 💅
the sender and receiver of a prune message have to cache the <source, group> pair being reported, for a "lifetime" measured in minutes ⏳ unless a router's prune information gets refreshed by a new prune for <source, group> before its "lifetime" runs out, that information gets removed, and data can flow over that branch again 🌊 state that expires this way is called "soft state" 🫧
here's the awkward part: routers that don't lead to any group members still take on the state overhead created by prune messages 😬 for wide-area multicasting, which might need to support many thousands of active groups (each one possibly sparsely spread out), this technique clearly doesn't scale 📉
3.2. Link-State Multicast Algorithm 🕸️
routers running a link-state algorithm periodically collect reachability information about their directly attached neighbours, then flood it throughout the routing domain in so-called link state update packets 📣 Deering extended the link-state algorithm for multicasting by having a router also detect group membership changes on its incident links before flooding that information in link state packets 🧠
so each router ends up with a complete, up-to-date picture of the domain's topology and group membership 🗺️ when a router gets a multicast data packet, it uses its membership and topology information to calculate a shortest-path tree rooted at the sender's subnetwork. as long as the calculating router falls within the computed tree, it forwards the data packet over the interfaces its calculation defines 🎯 that means multicast data packets only ever cross routers leading to members, either directly attached or further downstream. so the delivery tree is a true multicast tree right from the start 🎀
but flooding (reliable broadcasting) of group membership information is the main thing stopping the link-state multicast algorithm from working over the wide-area 🚧 the other limiting factor is the processing cost of the Dijkstra calculation needed to compute the shortest-path tree for each active source 🥵
part 1 down, bestie 🫶 there's more where this came from ✨
3.3. The Motivation for Shared Trees ✨
okay so after all that, it's giving "we NEED something more scalable" 😭 CBT was literally designed to be the scalability queen 👑 A shared tree beats source trees on scalability by a factor of the number of active sources (where "source" is usually a subnetwork aggregate) 💅 Source trees scale O(S * G) because a distinct delivery tree gets built for every active source 💀 Shared trees get rid of that S factor. Every source uses the same shared tree, so a shared tree scales O(G) 🦋 So apps with tons of active senders, like distributed interactive simulation and distributed video-gaming (where most receivers are also senders), have way less impact on underlying multicast routing if they use shared trees 🎮✨
Here's the back-of-the-envelope table where we compare the state CBT and DVMRP need for different group sizes and different numbers of active sources 🍓
|--------------|---------------------------------------------------|
| Number of | | | |
| groups | 10 | 100 | 1000 |
====================================================================
| Group size | | | |
| (# members) | 20 | 40 | 60 |
-------------------------------------------------------------------|
| No. of srcs | | | | | | | | | |
| per group |10% | 50% |100% |10% | 50% |100% |10% | 50% | 100% |
--------------------------------------------------------------------
| No. of DVMRP | | | | | | | | | |
| router | | | | | | | | | |
| entries | 20 | 100 | 200 |400 | 2K | 4K | 6K | 30K | 60K |
--------------------------------------------------------------------
| No. of CBT | | | |
| router | | | |
| entries | 10 | 100 | 1000 |
|------------------------------------------------------------------|Figure 1: Comparison of DVMRP and CBT Router State
Shared trees also save a lot of bandwidth and state compared with source trees 🌸 First, the tree only spans a group's receivers (including the links and routers leading to receivers), so there's no cost to routers or links in other parts of the network 🙈 Second, routers between a non-member sender and the delivery tree don't incur any multicast cost, and they don't even need to be multicast-capable 🫶 Packets from non-member senders get encapsulated and unicast to a core on the tree 📦
The figure below shows a core based tree 🌳
b b b-----b
\ | |
\ | |
b---b b------b
/ \ / KEY....
/ \/
/ X---b-----b X = Core
/ \ b = on-tree router
/ \
/ \
b b------b
/ \ |
/ \ |
b b bFigure 2: CBT Tree
4. CBT - The New Architecture 🧚
4.1. Design Requirements
The CBT shared tree design was geared towards several design objectives 💖
- scalability - the CBT designers decided not to sacrifice CBT's O(G) scaling characteristic to optimize delay using SPTs, the way PIM does 👑 This was an important design decision, and we think it was made with foresight, because once multicasting becomes ubiquitous, router state maintenance will be a predominant scaling factor 🔥 It's possible in some circumstances to improve or optimize the delay of shared trees by other means ✨ For example, a broadcast-type lecture with a single sender (or a limited set of infrequently changing senders) could have its core placed in the locality of the sender, letting CBT emulate a shortest-path tree (SPT) while still keeping its O(G) scaling characteristic 🦋 More generally, because CBT doesn't incur source-specific state, it's especially suited to many-sender applications 💅
- robustness - source-based tree algorithms are clearly robust 💪 A sender just sends its data, and the intervening routers "conspire" to get the data where it needs to go, creating state along the way 🧚 This is the so-called "data driven" approach, so there's no set-up protocol involved 🌈
It's not as easy to get the same degree of robustness in shared tree algorithms 😭 A shared tree's core router maintains connectivity between all group members, which makes it a single point of failure 💀 Protocol mechanisms must be present that ensure a core failure is detected quickly, and that the tree is reconnected quickly using a replacement core router 🫶
- simplicity - the CBT protocol is relatively simple compared to most other multicast routing protocols 🎀 This simplicity can lead to enhanced performance compared to other protocols 🍓
- interoperability - from a multicast perspective, the Internet is a collection of heterogeneous multicast regions 🌍 The protocol interconnecting these multicast regions is currently DVMRP [6] 🔗 Any regions not running DVMRP connect to the DVMRP "backbone" as stub regions 🧸 CBT has well-defined interoperability mechanisms with DVMRP [15] 🫶✨
4.2. CBT Components & Functions ✨
okay so the CBT protocol is built to make a shared multicast distribution tree that only stretches across the networks and links leading to interested receivers 🌸 no wasted branches, bestie!
so how does a host say "I'm in"? it multicasts an IGMP host membership report [5] across its attached link 🎀. when a local CBT aware router gets that report, it kicks off the tree joining process (unless it already did 💅) by generating a JOIN_REQUEST message and sending it to the next hop on the path toward the group's core router. (how the local router figures out which core to join is covered in section 6 🧚.) this join message has to be explicitly acknowledged with a JOIN_ACK, either by the core router itself or by another router on the unicast path between the sender and the core that has already successfully joined the tree 🦋.
the join message sets up transient join state in the routers it passes through, and that state is <group, incoming interface, outgoing interface>. "incoming interface" and "outgoing interface" can be "previous hop" and "next hop" instead, if the corresponding links don't support multicast transmission 🌈. "previous hop" comes from the incoming control packet's IP source address, and "next hop" is pulled from the routing table (the next hop to the specified core address). this transient state eventually times out unless it gets "confirmed" by a JOIN_ACK from upstream 💀. the JOIN_ACK travels the reverse path of the join message, which is possible because the transient join state is sitting right there 🫶. once the ack reaches the router that started the join, the new receiver can finally get traffic sent to the group 😭🔥
loops can't be created in a CBT tree because a) there's only one active core per group, and b) tree building and maintenance scenarios that could lead to tree loops are avoided 🙅♀️. for example, if a router's upstream neighbour becomes unreachable, the router immediately "flushes" all of its downstream branches, so they can individually rejoin if they need to 🍓. transient unicast loops aren't a threat either, because a new join message that loops back on itself will never get acknowledged, so it eventually times out 👑.
the state created in routers by sending or receiving a JOIN_ACK is bi-directional. data can flow either way along a tree "branch" 🦋, and the state is group specific. it consists of the group address and a list of local interfaces over which join messages for the group have previously been acknowledged. there's no concept of "incoming" or "outgoing" interfaces here, but it's still necessary to tell the upstream interface apart from any downstream ones. in CBT, these are called the "parent" and "child" interfaces 💜.
with regards to the information in the multicast forwarding cache: on link types that don't support native multicast transmission, an on-tree router has to store the address of a parent and any children 🌸. on links that do support multicast, parent and child information is represented with local interface addresses (or similar identifying info, like an interface "index") over which the parent or child is reachable ✨.
when a multicast data packet arrives at a router, the router uses the group address as an index into the multicast forwarding cache. a copy of the incoming multicast data packet gets forwarded over each interface (or to each address) listed in that entry, except the incoming interface 🎀.
every router in a CBT multicast tree, except the core router, is responsible for maintaining its upstream link, as long as it has interested downstream receivers. in other words, its child interface list isn't NULL 🙈. a child interface is one that has a member host directly attached, or one that has a downstream on-tree router attached 🧚. this "tree maintenance" happens because each downstream router periodically sends a "keepalive" message (ECHO_REQUEST) to its upstream neighbour, i.e. its parent router on the tree 💖. one keepalive gets sent to represent all entries with the same parent, which keeps things scalable on links shared by lots of groups 🌈. on multicast capable links, the keepalive is multicast to the "all-cbt-routers" group (IANA assigned as 224.0.0.15), and that has a suppressing effect on any other router for which the link is its parent link 🫶. if a parent link doesn't support multicast transmission, keepalives get unicast instead 🦋.
receiving a keepalive over a valid child interface immediately triggers a response (ECHO_REPLY), which is either unicast or multicast, depending on what's appropriate 💅.
the ECHO_REQUEST doesn't contain any group information, but the ECHO_REPLY does, just not every time 👀. to keep parent and child on the same page, the parent periodically reports, in an ECHO_REPLY, all the groups it has state for, over each of its child interfaces for those groups. this group-carrying echo reply isn't explicitly prompted by receiving an echo request message 🌸. a child gets told when to expect the next echo reply with group information, in an echo reply prompted by the child's echo request ✨. and the frequency of parent group reporting is at the granularity of minutes ⏰.
it can't be assumed that all the routers on a multi-access link have a uniform view of unicast routing 😬. this is especially true when a multi-access link spans two or more unicast routing domains. it could lead to multiple upstream tree branches forming (an error condition!) unless steps are taken so all routers on the link agree on which router is upstream for a particular group 🚨. CBT routers on a multi-access link go through an explicit election mechanism that picks a single router, the designated router (DR), as the link's upstream router for all groups 👑. because the DR might not be the link's best next hop for a particular core router, a join message can end up being redirected back across the multi-access link. when that happens, the DR unicasts the redirected join message across the link to the best next hop, which prevents a loop 🔁. this redirection only ever applies to join messages. it's suboptimal for joins, but joins are generated infrequently, and multicast data never crosses a link more than once (either natively, or encapsulated) 🎀.
outside of that exception case, all CBT control messages are multicast over multicast supporting links to the "all-cbt-routers" group, with IP TTL 1 📡. when a CBT control message is sent over a non-multicast supporting link, it's explicitly addressed to the appropriate next hop 🧚.
4.2.1. CBT Control Message Retransmission Strategy 🔄
certain CBT control messages elicit a response of some sort. a lack of response could be due to an upstream router crashing, the loss of the original message, or the loss of its response 😱. to detect these events, CBT retransmits those control messages that expect a response, if that response doesn't show up within the retransmission-interval. the interval varies depending on the type of message involved ⏳. there's an upper bound (typically 3) on the number of retransmissions of the original message before an exception condition is raised 🚫.
for example, the exception procedure for lack of response to an ECHO_REQUEST is to send a QUIT_NOTIFICATION upstream and a FLUSH_TREE message downstream for the group 💀. if this router has group members attached, it restarts the joining process to the group's core 🔁✨.
4.2.2. Non-Member Sending 📮
if a non-member sender's local router is already on-tree for the group being sent to, the subnet's upstream router simply forwards the data packet over all outgoing interfaces that match that group's forwarding cache entry 🌊. this is different from PIM-SM [18], which has to encapsulate data from a non-member sender no matter whether the local router has joined the tree. that's because PIM's state is uni-directional 🙃.
if the sender's subnet isn't attached to the group tree, the local DR has to encapsulate the data packet and unicast it to the group's core router. there it gets decapsulated and disseminated over all tree interfaces, as specified by the core's forwarding cache entry for the group 🎁. the encapsulation method is IP-in-IP [14] 🧁.
routers between a non-member sender and the group's core don't need to know anything about the multicast group, and they may even be multicast-unaware 🙈. this makes CBT particularly attractive for applications with non-member senders 💖.
5. Interoperability with Other Multicast Routing Protocols 🤝
see "interoperability" in section 4.1 💅.
the interoperability mechanisms for interfacing CBT with DVMRP are defined in [15] 🌈.
6. Core Router Discovery 🕵️♀️
core router discovery is by far the most controversial and difficult part of shared tree multicast architectures, especially in the context of inter-domain multicast routing (IDMR) 😤. there have been a lot of proposals over the past three years or so, including advertising core addresses in a multicast session directory like "sdr" [11], manual placement, and the HPIM [12] approach. HPIM strictly divides the multicast address space into many "hierarchical scopes" and uses explicit advertising of core routers between scope levels 🧩.
there are currently two options for CBTv2 [1] core discovery: the "bootstrap" mechanism, and manual placement 🎀. the bootstrap mechanism (as currently specified with the PIM sparse mode protocol [18]) only applies to intra-domain core discovery. it allows for "plug & play" style operation with minimal configuration 🔌. the downside is that it's much harder to affect the shape, and thus the optimality, of the resulting distribution tree 😩. it also has to be implemented by all CBT routers within a domain 🫠.
manual configuration of leaf routers with <core, group> mappings is the other option (note: leaf routers only) 📝. this comes with a degree of administrative burden, since the mapping for a particular group has to be coordinated across all leaf routers to keep things consistent 😮💨. so this method doesn't scale particularly well. however, "better" trees are likely to result from this method, and it's also the only option currently available for inter-domain core discovery 🌟.
6.1. Bootstrap Mechanism Overview 🌸
okay so it's unlikely at this stage that the bootstrap mechanism gets bolted onto a well-known network layer protocol like IGMP [5] or ICMP [13] 🙈 which would be super convenient for getting it running everywhere inside a domain, ngl. So each multicast routing protocol that needs bootstrap has to build it right into itself 💅
Here's the quick version ✨ It's assumed that all routers within the domain implement the "bootstrap" protocol, or at least forward bootstrap protocol messages.
Some routers in the domain are set up as CBT candidate core routers. Each candidate core router periodically (default every 60 secs) advertises itself to the domain's Bootstrap Router (BSR) using "Core Advertisement" messages. The BSR isn't a fixed job, it's elected dynamically from all (or participating) routers in the domain 👑 The elected BSR collects those "Core Advertisement" messages and periodically advertises a candidate core set (CC-set) to each other router in the domain, using traditional hop-by-hop unicast forwarding. The BSR uses "Bootstrap Messages" to advertise the CC-set. Together, "Core Advertisements" and "Bootstrap Messages" make up the "bootstrap" protocol 🦋
When a router gets an IGMP host membership report from one of its directly attached hosts, the local router runs a hash function on the reported group address. The result is used as an index into the CC-set, and that's how local routers figure out which core to use for a particular group 🧚
Now the hash function is specially tailored so that a small number of consecutive groups always hash to the same core 💜 Bootstrap messages can also carry a "group mask", which can limit a CC-set to a particular range of groups. This can help take some of the traffic pressure off the core 🌈
If a BSR detects that a particular core is unreachable (it hasn't announced its availability within some period), it deletes that core from the CC-set it sends in its next bootstrap message 💀 This is how a local router finds out a group's core is unreachable. The router has to re-hash for each affected group and join the new core after removing the old state. The removal of the "old" state follows the sending of a QUIT_NOTIFICATION upstream, and a FLUSH_TREE message downstream.
7. Summary ✨
okay, the big wrap-up 💖 This document presents an architecture for intra- and inter-domain multicast routing. We motivated the architecture by describing how an inter-domain multicast routing algorithm has to scale to the large numbers of groups present in the internetwork, and we discussed why most other existing algorithms are less suited to inter-domain multicast routing. After that, we described the features and components of the architecture, showing off its simplicity and scalability 🎀
8. Security Considerations 🔐
okay this part is SERIOUS bestie 😭 Security considerations are not addressed in this memo.
Whilst multicast security is still a topic of ongoing research, multicast applications (users) can still take advantage of security services like encryption and/or authentication, as long as the applications themselves support those services 🫶
RFCs 1949 and 2093/2094 discuss different ways of distributing multicast key material, which can result in network layer access control being provided to a multicast distribution tree 🔑
[19] gives a synopsis of multicast security threats and proposes some possible counter measures 👀
Beyond these, there's honestly not much published work on multicast security. Like, it's a bit of a wasteland out there 💀
Acknowledgements 🍓
Special thanks go to Paul Francis, NTT Japan, for the original brainstorming sessions that brought this work about 🫶
Clay Shields' work on OCBT [17] identified various failure scenarios with a multi-core architecture, which led to the specification of a single core architecture 🙌
Others who contributed to the progress of CBT include Ken Carlberg, Eric Crawley, Jon Crowcroft, Mark Handley, Ahmed Helmy, Nitin Jain, Alan O'Neill, Steven Ostrowsksi, Radia Perlman, Scott Reeve, Benny Rodrig, Martin Tatham, Dave Thaler, Sue Thompson, Paul White, and other participants of the IETF IDMR working group 🌟
Thanks also to 3Com Corporation and British Telecom Plc for funding this work 💜
References 📚
[1] Ballardie, A., "Core Based Trees (CBT version 2) Multicast Routing: Protocol Specification", RFC 2189, September 1997.
[2] Multicast Routing in a Datagram Internetwork; S. Deering, PhD Thesis, 1991; ftp://gregorio.stanford.edu/vmtp/sd-thesis.ps.
[3] Mechanisms for Broadcast and Selective Broadcast; D. Wall; PhD thesis, Stanford University, June 1980. Technical Report #90.
[4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[5] Internet Group Management Protocol, version 2 (IGMPv2); W. Fenner; Work In Progress.
[6] Distance Vector Multicast Routing Protocol (DVMRP); T. Pusateri; Work In Progress.
[7] Protocol Independent Multicast (PIM) Dense Mode Specification; D. Estrin et al; ftp://netweb.usc.edu/pim, Work In Progress.
[8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[9] Reverse path forwarding of broadcast packets; Y.K. Dalal and R.M. Metcalfe; Communications of the ACM, 21(12):1040--1048, 1978.
[10] Some Issues for an Inter-Domain Multicast Routing Protocol; D. Meyer; Work In Progress.
[11] SDP: Session Description Protocol; M. Handley and V. Jacobson; Work In Progress.
[12] Hierarchical Protocol Independent Multicast; M. Handley, J. Crowcroft, I. Wakeman. Available from: http://www.cs.ucl.ac.uk/staff/M.Handley/hpim.ps and ftp://cs.ucl.ac.uk/darpa/IDMR/hpim.ps. Work done 1995.
[13] Postel, J., "Internet Control Message Protocol (ICMP)", STD 5, RFC 792, September 1981.
[14] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[15] CBT - Dense Mode Multicast Interoperability; A. Ballardie; Work In Progress.
[16] Performance and Resource Cost Comparisons of Multicast Routing Algorithms for Distributed Interactive Simulation Applications; T. Billhartz, J. Bibb Cain, E. Farrey-Goudreau, and D. Feig. Available from: http://www.epm.ornl.gov/~sgb/pubs.html; July 1995.
[17] The Ordered Core Based Tree Protocol; C. Shields and J.J. Garcia-Luna-Aceves; In Proceedings of IEEE Infocom'97, Kobe, Japan, April 1997; http://www.cse.ucsc.edu/research/ccrg/publications/infocomm97ocbt.ps.gz
[18] Estrin, D., et. al., "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2117, June 1997.
[19] Multicast-Specific Security Threats and Counter-Measures; A. Ballardie and J. Crowcroft; In Proceedings "Symposium on Network and Distributed System Security", February 1995, pp.2-16.
Author Information 🎀
Tony Ballardie, Research Consultant
EMail: ABallardie@acm.org
📦 where this page comes from
- ietf: rfc2201 1997-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms