Internet Engineering Task Force R. Perlman INTERNET DRAFT Sun Microsystems October 1999 C-Y Lee Nortel Networks A. Ballardie Research Consultant J. Crowcroft UCL Z. Wang Lucent Technologies T. Maufer 3Com Corporation C. Diot Sprint J. Thoo Nortel Networks M. Green @Home Networks Simple Multicast: A Design for Simple, Low-Overhead Multicast Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Expires April 2000 [Page 1] Internet Draft Simple Multicast October 1999 Abstract This paper describes a design for multicast that is simple to understand and low enough overhead for routers that a single scheme can work both within and between domains. It also eliminates the need for coordinated multicast address allocation across the Internet. It is not very different from the tree-based schemes CBT, PIM-SM, and BGMP. Essentially all of the mechanisms to support this have already been implemented in the other designs. The contribution of this protocol is in what is NOT required to be implemented. The main idea for simplifying multicast is to consider the identity of a group to be the 8-byte combination of a "core node" C, and the multicast address M. The identity of the group is carried in join messages and data messages. M no longer has to be unique across the Internet. It only has to be unique per C. The other idea, which is independent of the first, it to build a bi-directional tree (as is done in CBT and BGMP) instead of building per-source trees from each sender. This reduces the state necessary in routers to support multicast. Changes from revision 1 - use a Simple Multicast (SM) header instead of a new IP option - modified branch creation and deletion to avoid loops - added tree splicing mechanism - added multicast scoping - allow both IGMP and host SM Join - added sender only joins - third party independence - layer 2 filtering - host API and kernel changes Expires April 2000 [Page 2] Internet Draft Simple Multicast October 1999 1.0 Introduction IP Multicast has been around for over a decade, and several multicast protocols have been developed over the years. However, the solutions are either difficult to understand or expensive to deploy or both. In particular, we believe that multicast address allocation protocols are too complex and BGMP in combination with MASC will not scale easily. In this paper, we present a design we call Simple Multicast that reduces the complexity and overhead of multicast. It is not really "yet another multicast protocol". Instead, it is more like a subset of other protocols, with one variation; to have the identifier of a group consist of both C (the core) and M (the multicast address). This eliminates the need to have unique multicast addresses and coordinate multicast addresses across the Internet. 1.1 Previous Work DVMRP is the first multicast routing protocol proposed. It uses a simple mechanism of flooding and pruning. The scalability issues with DVMRP led to the development of CBT. In CBT, a multicast group is formed by choosing a distinguished node, the "core", and having all members join by sending special join messages towards the core. The routers along the path keep state about which ports are in the group. If a router along the path of the join already has state about that group the join does not proceed further. Instead the router just "grafts" the new limb onto the tree. The result is a tree of shortest paths from the core, with only the routers along the path knowing anything about that group. In PIM-SM, each node could independently decide whether the volume of traffic from a particular source is worth switching from a shared tree to a per-source tree. Thus, there are two possible trees for traffic from a particular source for group M; the shared tree and the source tree. To prevent loops, the shared tree had to be unidirectional, i.e., to send to the shared tree, the data has to be encapsulated and unicast to the core. The other issue that makes current protocols complex is the necessity for routers to be able to figure out the location of the core based solely on the multicast address M. In PIM-SM, this resulted in a protocol whereby "core-capable" routers are being continuously advertised. All routers keep track of the current set of live core- capable routers, and there is a hashing function to map a multicast address to one of the set of core-capable routers. This advertisement protocol is confined to within a domain because it was recognized Expires April 2000 [Page 3] Internet Draft Simple Multicast October 1999 that this mechanism would not scale to the entire Internet. For inter-domain multicast, a set of new protocols has been proposed. The MASC protocol deals with hierarchical block allocation of Class D address space. Essentially, it creates a prefix structure in multicast address space in a way similar to unicast address space. Because of the limited multicast address space, the allocation has to be dynamic. MASC contains mechanisms for collision detection and de-allocation. Once a block of multicast addresses is allocated, and no collision is detected for a period of time, the address block is then given to MAAS servers for actual assignment to multicast groups. The address block has to be propagated through BGP+ so that routers throughout the Internet can know the mapping of multicast addresses to cores, even in other domains. BGMP then uses this information to know the direction in which a join to multicast address M should be sent. 1.2 Overview of Simple Multicast The Simple Multicast proposal tries to reduce or eliminate some of the complexity and overhead of multicast by taking a slightly different approach. The basic idea in Simple Multicast is that a multicast group is created by generating: - a distinguished node C known as the "core" - a multicast address M The multicast group is then identified by the pair (C,M) rather than just M as in conventional IP multicast. Note that the address M does not have to be unique across the Internet now. Instead, only the pair (C,M) has to be unique. That means that every node C in the Internet can assign the full 28 bits worth of multicast addresses. In Simple Multicast, multicast address allocation and core placement (i.e., choosing a multicast address M and a core C for a multicast group) are taken out of the basic multicast protocol. End systems may find out about the multicast address M and the core C for a group through one of several possible mechanisms including email announcement, web advertising, SDR, DNS lookup etc. Both SM-aware endnodes and SM-aware routers must recognize the combination of (C,M) as the identity of the group. Once the end systems have M and C, they then join the group by sending a special join message towards the core C, creating state in the routers along the path until the join packet hits the core or a router that is already on the tree for this multicast group. This creates a branch in the bi-directional distribution tree for the Expires April 2000 [Page 4] Internet Draft Simple Multicast October 1999 group. The current IGMP mechanism for joining groups is fine, provided that both C and M appear in the IGMP reply. Until IGMP is modified to support this, the join message itself can be sent from the end system. If both C and M appear in the join message, then the first hop router can initiate the join. To enable incremental deployment of Simple Multicast, we provide a mechanism for the join message traverses non-SM aware routers. (See Joining a Group). The multicast tree formed is bi-directional, meaning that traffic can be injected from any point. The core is just another node in the tree. The data packet contains both C and M, and routers look up the group based on the combination (C,M). Data packets would need to carry both C and M. There has been a few suggestions on how this may be done: 1) Define a new IP option and specify both C and M in it. 2) Define a new protocol and specify the new protocol in the 'protocol' field of the IPv4 header. Encapsulate the payload inside this new protocol. This new protocol header will contain both C and M. 3) Map (C,M) to a unique class-D address on the data-link. The destination address of the data packet would be re-written to a unique class-D address before being forwarded on that data-link. Although option processing in general is more expensive, in this case the option processing is merely, forwarding packets by looking at an extra IP address in the option field. In contrast, other IP options such as LSR, SSR and Router Alert are more involved. Hence, from a purely technical point of view, the first and second approach can be implemented in hardware and there is no significant difference between these two approaches. However, due to current hardware implementation convention, option processing is more likely done in software. As a result, we have opted to use the SM header instead. The third approach does not require data packets or join messages to carry the core address. SM nodes obtain the unique class-D address which maps to a group (C,M) from a special node(s) on the data-link. This approach is appealing because it allows SM applications to join a group by joining a class-D address just like conventional IP multicast. On the other hand, it also introduces concerns not unlike label switching, e.g. vulnerability to loops, ensuring the uniqueness of addresses at all times, ensuring all nodes on the LAN use the same address for a group at all times and address recycling, among others. In this approach, if a unique address on the data-link is not available for use, data cannot be forwarded. In contrast, if a packet cannot be label switched, it can be routed. We are investigating the feasibility of this approach. Expires April 2000 [Page 5] Internet Draft Simple Multicast October 1999 The SM header will carry both C and M. The reason for carrying both C and M in the option instead of carrying at least one of them in the destination address is to allow SM aware routers to co-exist with non-SM aware routers. The destination address in the IP packet is set to a reserved multicast address, the ALL-SM-NODES, when sending to networks with SM aware routers. This ensures that non-SM routers will not forward SM multicast data packets. When the packet must hop over non-SM routers, the IP destination address is set to the next SM-aware router in the path. A nice feature of Simple Multicast is that, since both C and M are in the SM header, the destination address in the IP packet can be replaced with the tunnel endpoint address, and packets can be 'tunneled' with very little work. Instead of having to add and delete IP headers (if the packet is encapsulated IPIP), the only work is to write the tunnel endpoint address into the destination address of the IP header.. 1.3 Why Simple Multicast We now discuss some of the advantages of Simple Multicast. - One protocol is all that is needed. Currently, we need to deal with two sets of multicast protocols in order to support multicast in the Internet: DVMRP, PIM-DM, PIM-SM and CBT etc for intra-domain multicast and MASC, MAAS and BGMP for inter-domain support. The beauty of the Simple Multicast proposal is only one multicast protocol is needed for both intra-domain and inter-domain. This is possible because Simple Multicast is designed to be scalable. - Scalability. Simple Multicast is scalable to the global Internet. This scalability is achieved by using a trivial multicast address allocation scheme, decoupling core selection and discovery from the multicast protocol and using bi-directional trees. If core discovery is decoupled from multicast routing protocols such as PIM-SM or CBT, these protocols would not have to use the bootstrap mechanism to discover and select cores, a mechanism generally considered to be not scalable. - Trivial multicast address allocation. IP Multicast address allocation is still an unresolved problem. Dynamically allocating addresses such that addresses are allocated in aggregatable blocks, while ensuring low probability of address collision (non-uniqueness) is non-trivial. In Simple Multicast, since (C,M) is the identifier for a multicast group, address assignment becomes totally trivial, since addresses only have to be unique per core. Each core can have the full 28 bit space (over 200 million address) so we have virtually unlimited multicast addresses. Each core can allocate these addresses Expires April 2000 [Page 6] Internet Draft Simple Multicast October 1999 independently without Internet-wide coordination. - Cost effective and efficient delivery trees. It takes less state in routers to support a group with n senders with a single shared tree than with n per-sender trees. A bi-directional shared tree is as cost effective for delivery of traffic from source S,even if S is not the core, as a per-source tree rooted at S. The bi-directional shared tree is much more efficient for delivery of traffic from non-core source S than a unidirectional tree where the data from S must be tunneled to the core before being multicast. Bi-directional trees are more robust. In a unidirectional tree, the core is needed for relaying packets from all senders. If the core is down, the tree is gone. For a bi-directional tree, the core does not hold any particular significance. The core is just another node in the tree. If the core is down, the tree is merely partitioned and may still be used for traffic delivery if the application chooses to do so. - Incremental deployment. Simple Multicast routers may be deployed along side unicast routers and other multicast routers. Traffic is effectively tunneled (although the actual mechanism used is more efficient than tunnels) through routers which do not support Simple Multicast. Therefore a network manager may incrementally add Simple Multicast routers as multicast users spread in the network. 2.0 The Design In this section, we describe the design of Simple Multicast and its basic operations in detail. 2.1 Creating a Multicast Group To create a group, one needs to select a core address and a multicast address. Typically most applications consist of a single high-volume source. For those applications, the core should be the source. For others, any node close to any member of the group would be a logical choice for core. Because the tree-building strategy (like BGMP) uses a single exit point from a domain or any region separated from the rest of the Internet through expensive links, the traffic pattern resembles individual trees within domains hooked together with inter-domain paths. In other words, if S is in your domain, then you will receive traffic from S through a path internal to your domain even if the core of the group is outside the domain. Therefore, even if most of the members of the group are in Europe, and one member of the group is in Australia, and the Australian is chosen as the core, Expires April 2000 [Page 7] Internet Draft Simple Multicast October 1999 the tree will still be a very good tree. Traffic between the Europeans would be multicast through the tree confined within Europe, even though the core was in Australia. As the multicast addresses only need to be unique per core, each core has over 200 million multicast addresses for allocation. Once the core is chosen, some very simple mechanisms can be used to generate the multicast address for the chosen core, for example, querying the core for an address or random generation as it is done in SDR (the collision rate will be significantly lower). Some permanent mapping of "well-known" addresses for popular groups is also feasible. 2.2 Joining a Group To join a group, one first has to find the core address C and multicast address M. It is appropriate to have a variety of mechanisms. A web page advertising a "singles chat group" might advertise its (C,M) on its web page. Or a provider of some other sort of service, like stock quotes, might advertise on a web page. Ideally, clicking on the web page would cause M and C to be downloaded to the client machine, which would then join the group. Another mechanism, for instance when arranging a private conference, might be to be told about M and C via the telephone, or via email. Yet another mechanism is to have the group (together with a name or a description) advertised in a directory such as SDR. If IGMP is extended to support SM, the host sends a membership report for group (C,M). The SM DR is responsible for forwarding the join off the LAN. This message is sent towards the core, creating state in the routers along the path, so that each router knows which ports are in the group (C,M). If there are no SM routers on the LAN, a host may send an SM Join itself. The destination IP address of the join message is set to the core IP address. If a non-SM router on the LAN receives the join message, it will forward it to the core. Data will be tunneled to this endnode by an upstream SM router. As there could be potentially multiple tunnels to the LAN, host SM Join should only be used when there is no local SM support as may be the case during initial deployment or when there are very few local members to justify a network upgrade. If the next hop towards the core on the LAN is an SM router, and if it is not an SM DR itself, it will redirect the join to the SM DR. In this case, if data is tunneled from upstream, it will be tunneled to the SM router that forwards the join off the LAN, instead of the endnode. [Note: This approach provides a migration path whereby as more SM routers are deployed on the LAN, less tunnels are used. It also allows the co-existence of IGMP (with or without SM support) and host SM Join during the migration Expires April 2000 [Page 8] Internet Draft Simple Multicast October 1999 process.] If a router receives a join formulticast address (C,M), and it already has state for (C,M), then it merely adds that port to its set of ports for (C,M) and does not forward the join further. The result is a tree of shortest paths from the core to each member. Each router on the tree has a database of (C,M, {ports}) that tells it, for group (C,M), the ports that data should be forwarded to. The join message is sent with the Router Alert option. Since the join message has C as the destination address, if an intermediate router is not SM aware, it will just forward the join towards the core. When the join message reaches an SM-aware router R2, it looks at the IP source address of the join message, say R1. If R1 is a neighbor, R2 adds the port from which the join was received to its list of ports for (C,M). If R1 is not a neighbor, R2 will add a join-ack to R1. If R2 is not a neighbor, R1 adds the 'tunnel port' to R2 as its 'parent port' for (C,M). If R2 is a neighbor, R1 just adds the port as its parent port for (C,M), since the packet will not need to be tunneled to get to R2. A non-member sender may join the group as a sender-only (cf uni- directional join in CBT). The sender will be on-tree and thus will be sending keep-alives and receiving heartbeat messages, and hence will be aware about core liveliness. Data will not be forwarded to a sender-only branch. 2.3 Transmitting to multicast group (C,M) A sender who is a member of the group, sends an IP packet with C and M in the SM header. The destination IP address is set to ALL-SM- NODES. This ensures non-SM aware nodes will ignore the packet. Only SM aware routers will forward the packet. A router that receives an SM packet looks up (C,M) in its forwarding table. If it knows about (C,M), it checks if the port it received the packet on is in its database. If not, it drops the packet. If so, it forwards the packet onto all the other ports listed in its database for (C,M). If the outgoing port is a tunnel port, the destination address of the IP header is replaced by the tunnel endpoint, and will therefore travel across routers that are not SM-aware. At the other end of the tunnel, the SM-aware router will replace the destination address with ALL-SM-NODES, or with another tunnel endpoint's address, depending on whether the packet is being forwarded on a "real port" or a "tunnel port. If you are not a member of the group but want to transmit to the Expires April 2000 [Page 9] Internet Draft Simple Multicast October 1999 group, you place C into the IP destination address, and put C and M in the SM header. The packet might travel all the way to the core, but if it instead hits an SM-aware router R with state about (C,M) before it gets to the core, R will inject the packet into the tree. A sender-only member may transmit like a member, but will not be receiving any packets for this group. 2.4 Inter-domain Multicast Simple Multicast works both for intra-domain and inter-domain multicast. Because the join message of Simple Multicast carries the core IP address, and unicast routing already knows how to reach any IP address, the join message will be delivered based on the unicast forwarding table. 2.4.1 Incongruent unicast and multicast topologies Where the unicast and multicast topologies are incongruent, BGP-4+ [MBGP] allows a network provider to specify the path it would accept multicast traffic independent of the path unicast traffic would traverse. In the figure below, AS1 may have a peering agreement with AS2 to forward its unicast traffic, but a peering agreement with AS3 to forward multicast traffic. A join from AS1 towards any cores in AS4 would be sent via AS3. A finer granularity of policy may specify certain network or core ranges that AS3 would carry traffic for. AS2 * * * * AS1 AS4 * * * * AS3 The join message to C should be routed towards the exit router specified by BGP4+, for delivery of multicast traffic outside of the domain. 2.4.2 "3rd Party" Independence For the case in which SM is used both within and between domains, joins from different parts of the domain might only converge (merge) outside the domain. It is not desirable for a domain to depend on another, "3rd party", domain for the distribution of internally sourced traffic to other internal receivers. It is therefore necessary to ensure that joins from different internal receivers merge at a common point inside the domain. Expires April 2000 [Page 10] Internet Draft Simple Multicast October 1999 BGP-4 operates on border routers (BRs) of transit domains, and ensures that all BRs know which of them acts as egress for a particular unicast prefix. Some transit domains (the elected egress router) inject external route information internally, and therefore, internal routers know in which direction to forward packets destined to a particular unicast prefix. In other cases, and in stub domains, external route information is not injected inside the domain. Nevertheless, the BRs of these domains know for which unicast prefix(es) each of them is acting as egress. Thus, domain BR routing knowledge ensures that joins originated inside a domain converge at a common point inside the domain. This principle can be applied recursively across a multiple levels of routing hierarchy. 2.5 Failure Recovery The situations to detect are: - branch unused - loop - path to core broken or changed - core dead or unreachable Any of the tree building schemes (CBT, PIM-SM, BGMP) need to solve these problems, and there is no need to do anything radically new. The only extra mechanism we've introduced is for loop detection. Since packets can quickly proliferate in a multicast loop, it is desirable to detect a loop as soon as it is formed forms. Since SM uses an SM header, we can make use of a flag that will enable us to detect a loop on a data packet. The other mechanisms we specify are similar to those already in place for PIM, CBT, and BGMP. 2.5.1 Unused Branch A branch must be kept alive with a "keep-alive" message. If R receives at least one keep-alive message from a child in tree (C,M), R sends a keep-alive to its parent port for (C,M). If no keep-alive is received for some amount of time (at least a few keep-alive intervals) from some child port for (C,M), that port is removed from the list of ports. If there are no more child ports, then R stops sending keep-alives, or as an optimization "unjoins" from its parent. Expires April 2000 [Page 11] Internet Draft Simple Multicast October 1999 2.5.2 Loop It would be easy to detect a loop if we could assume that any data packet for which TTL became zero implied there was a loop. Unfortunately, some applications do an "expanding ring search" or a traceroute in which packets are launched with very small TTLs. It would be wrong to conclude there was a loop when the TTL on those packets expired. We use a flag in the SM header to indicate a packet that would indicate a loop if its TTL reached 0. An application launching a packet with a low TTL would not set that flag. SM routers do not need to look at the flag except on packets for which TTL expires. Loops can also be detected on keep-alive and heartbeat messages (which are sent outwards from the core...see next section). The keep-alive message indicates "hops from furthest leaf". A router collects keep-alives from its child ports and transmits a keep-alive that is one hop more than the maximum "hops" it receives in any keep alive from a child. The heartbeat is like a keep-alive, but from the parent. Likewise it carries a "distance from the core". In either case (heartbeat or keep-alive) if the distance gets too great a loop is suspected and the port is removed from the tree and the child rejoins to the core. 2.5.3 Path to core broken or changed A parent transmits a "heartbeat" message to its children at regular intervals. The heartbeat indicates whether the core is known to be alive. A parent continues sending heartbeat messages even if it stops receiving "core-alive" heartbeats from its parent. In this way a subtree will continue functioning even if the core is dead. And if the core is not dead, the parent can simply rejoin without causing disruption to the nodes below it in the tree, where feasible. If unicast routing indicates the path to the core has changed, R rejoins to the core, again, without disrupting the subtree below it, where feasible. To avoid loops from forming, the parent would rejoin the core using a special join to splice the sub-trees. This splice message must be forwarded all the way to the core, creating state where there is no existing state. The core will acknowledge the splice message. If the splice message hits a downstream router, it will be forwarded until it reaches the router that originated this splice message. At Expires April 2000 [Page 12] Internet Draft Simple Multicast October 1999 this point, the router would realize that it cannot splice the sub- trees without causing loops. Depending on application requirement which is conveyed to routers from core via heartbeat messages, the router could either flush the sub-tree and let leaf routers or hosts rejoin, or if the application desire, allow the sub-trees to continue functioning separately, but attempts to splice the sub-trees again when unicast route to the core changes. The latter makes more sense when there is a network partition, and the core is not reachable. /* MODIFIED */ The decision to flush the sub-tree or rejoin the core can be based on information such as the depth of the sub-tree and distance to core. This information may be obtain from the keep-alive and heartbeat messages. Since the heartbeat message is generated at regular intervals even if a heartbeat is not received from the parent, a very long tree does not suffer from delay variance that might cause nodes very far from the core to incorrectly assume the tree was broken. 2.5.4 Core dead or unreachable When the core transmits a heartbeat message it sets the "core alive" flag. If a router has received a heartbeat message from its parent with the "core alive" flag set recently enough (3 heartbeat intervals), then it sets the "core alive" flag in its heartbeat messages to its children. If it stops receiving heartbeats with "core alive", it prunes itself from the old parent and rejoin (by sending a splice message) the core. The only purpose of knowing whether the core is alive or not is for applications to decide, if there are multiple trees for a group, which tree they should transmit on. (see next section) 2.5.5 Multiple Trees for Reliability The core should be selected to be a node that is reliable. However, if a group will be long-lived and there is the worry that the core might die, a simple mechanism is to create multiple trees (C1, M1) and (C2, M2) for this group. All members join both groups. They can transmit on either group. If "core alive" heartbeat is only received on group (C1, M1) that is the group that should be transmitted to. For applications for which instantaneous switchover is more important than overhead, senders should transmit on both trees. Expires April 2000 [Page 13] Internet Draft Simple Multicast October 1999 2.6 Access Control We accomplish access control by allowing the core for the group to be configured with the set of allowed senders. The core can put the access rules into the heartbeat message. The heartbeat message contains a list of address prefixes of authorized senders and unauthorized senders. If the rules do not fit into the heartbeat, or the core for privacy reasons does not want to advertise in advance all the allowed senders, it can specify that no senders other than It is allowed. In that case, all senders must tunnel packets to the core and the core will forward them. Once a sender gets permission to send, and is known to have data to send, the core can add that sender's address to the heartbeat message. For example, if there is some sort of authentication that must be done in order to get permission, the core initially disallows all senders, but then when S1 gets permission, it gets added to the list in the heartbeat message. Since the heartbeat message gives the access rules, all SM routers will refuse to forward a packet from a sender disallowed by the access rules. Border/Access routers may also have an additional Access Control List locally. For instance, it may have a list of sender prefixes/addresses allowed to transmit multicast data. All multicast traffic with source address matching these prefixes/ addresses will not be filtered. The Include/Exclude Senders List from the core will prevent these senders from sending to a group that they are not permitted to. 2.7 Dynamically forming more trees In some cases dynamically formed auxiliary trees make sense, especially in the inter-domain, where policy might prohibit packets from A to D to transit domain B. With a core in domain B, or just due to the shared tree that happened to get formed, packets from senders in A to receivers in D might traverse domain B. One simple method of solving the problem is to have A unicast to the core, and have the core send the multicast. B is still acting as a transit domain between A and D, but it doesn't know it. Another solution takes inspiration from the PIM-SM concept of using the shared tree to find out about per-source trees. The way it works is that the sender in domain A, say X, sends a message to the core C telling it that it would like to create a "spin-off" group, (X,M'). Then the core C, in the heartbeat messages for group (C,M) advertises the spin-off trees that members of (C,M) should also join. The spin- Expires April 2000 [Page 14] Internet Draft Simple Multicast October 1999 off tree would, like the original tree, be kept robust through keep- alives. Although this does allow creation of multiple trees to support a single group, this is less expensive than the PIM-SM scheme because it does not always create a tree for every sender. It only does it when necessary, and does not need a totally separate tree for each sender. It only needs one per domain in which there are sources (and only when the shared tree doesn't work because of transit policy problems). 2.8 Multicast Scoping A multicast group address can be scoped such that packets matching the group address are not forwarded outside the defined region. Two commonly used scopes are the link-local scope and the global scope and they do not require configuration. Routers merely do not forward the statically assigned link-local scope address (224.0.0.0/24). The third type of scoping requires network administrators to configure the perimeter (boundary routers) of the scoped region. This is called administratively scoped or local scope. At present, this is achieved by configuring multicast border routers (M-BRs) on a scope boundary with a boundary scope address range - so-called Administratively Scoped address range. Multicast traffic flows which are to be confined within a range must use a class-D address which is within the range. M-BRs are an impermeable boundary to any multicast packet with a class-D destination address that falls within any of its configured Administratively Scoped address ranges. It is perfectly feasible for SM to use exactly the same mechanism for achieving multicast scoping. However, multicast scoping as it is currently defined requires a significant amount of configuration, as well as co-ordination of the address space for defining scope boundary ranges. Any mis-configurations can lead to multicast packets "leaking" across boundaries they should not. Multicast scope boundary configurations must conform to certain rules, such as the rule that boundaries must be completely contained within one another (the term "nesting", or "convex", are often used). The MZAP protocol [MZAP] is implemented on M-BRs to detect inconsistent administratively scoped boundary configurations. As such it is essentially a network management tool, it does not correct mis-configurations. In SM, the group address (C,M) is scoped according to the unicast core address C. The advantage of this compared to Administratively Scoped IP Multicast [RFC2365] is there is no requirement for these Expires April 2000 [Page 15] Internet Draft Simple Multicast October 1999 scoped addresses to be dynamically assigned (via AAP or MAAS) or announced in the scoped regions (MZAP). 2.8.1 Multicast Scoping using unicast boundaries and scope mask SM has the unique ability to take advantage of the unicast routing system boundaries (e.g. subnet, area, AS, AS-Confederation etc.) and use these as "natural" boundaries for multicast traffic, obviating the need for the configuration of explicit multicast boundaries. Furthermore, one group identifier (C, M) can be used with multiple scopes. It works as follows: assume a (C, M) group identifier is to be used for scopes A and B, with A nested inside B. A and B are natural unicast routing boundaries, e.g. area, and AS. A unicast routing system boundary is implicitly identified by a router aggregating routing information before propagating it over outgoing interfaces; this is achieved by shortening a prefix mask. For example, routing information inside boundary A has an associated mask of 24 bits. The boundary router between A and B reduces this is to 16 bits before propagating inside B. Now, if a SM data packet carried a "scope mask(len)" in the SM header, the data packet would not pass beyond any unicast routing system boundary that itself propagates a shorter mask in unicast route updates it sends. The general rule is: a SM data packet carrying a "scope mask(len)" is only forwarded over those interfaces that aggregate unicast routing information using a mask which is equal length or longer than that specified in the SM data packet header. | (c) /16 | (d) /12 | --------+------- (a) /8 | (b) /20 | | The figure above illustrates a router with 4 interfaces, a, b, c, d, each which is aggregating routes with the respective prefix. If a SM data packet arrives on interface (b) carrying a "scope mask(len)" of 12, it is forwarded only over interface (c) and (d). 2.8.2 Multicast Scoping using private network boundaries A multicast session can be scoped within a private network if the core address belongs to the private address space and is not Expires April 2000 [Page 16] Internet Draft Simple Multicast October 1999 translated to any global address. In this case the boundary routers can be the filtering or NAT devices at the edge of the network. Since NAT devices can scope the addresses, the SM data packet itself does not have to carry the scope mask in the SM header. Note that for administrative scoping purposes, the function in the NAT device which is of interest here is the filtering and address space separation function, not the address translation function. An public node will not be able to join n private core if the private core address is not mapped to any global address. As a result, no data packets for this scoped core will be forwarded out of the NAT device. If the boundary routers are NAT devices, there is no requirement for the NAT devices to be SM-enabled (i.e. it knows how to translate SM specific packets) for the purpose of scoping SM groups. If the NAT is not SM-enabled, the join message will be filtered according to the core (IP destination) address and hence forwarding states for (C,G) will only be created in the defined scope. If the NAT device is SM- enabled, data packets can be filtered based on the core address C or the source address. In the case of SM dense mode, C=255.255.255.255. If the NAT device is not SM-enabled, since the IP destination address=255.255.255.255, the packets will be filtered. Hence SM dense-mode traffic is scoped by default, i.e. no dense-mode data packets will be forwarded across any boundary. If the NAT device is SM-enabled, a dense-mode data packet is scoped according to its IP source address. Source address is scoped in the same manner as core address. If two scoped regions intersect topologically, then the address space in the overlapped region cannot be used by the outer scope, as stated in RFC2365. This applies here as well, i.e. a scoped group address cannot have its core address in the address space of the overlapped region, to avoid the problem of the same (C,M) belonging to different scopes at the intersecting boundary. This implies a core address C, scoped within scope X, where scope X is inside scope Y, should be unique within scopes X and Y; and no core within scope Y should have that same address C. Further, any other addresses scoped within X should not be visible to scope Y; all addresses scoped within Y is visible to scope X. This address separation is already maintained by NAT devices. 2.8.3 Multicast Scoping in IPv6 In IPv6, if a core address is a site-local scope address, then the corresponding (C,*) will be site-local scope as well, Expires April 2000 [Page 17] Internet Draft Simple Multicast October 1999 2.9 Additional Features We are investigating the following additional features, which are not available in other multicast protocols: - the ability to select dense-mode. Currently there are routers that implement dense mode and routers that implement sparse mode, and typically a domain will implement either sparse or dense mode. There is no way to choose, per application, which type of tree is more appropriate. There are cases in which dense mode makes more sense for an application. For example, dense mode is more appropriate if the number of receivers is so dense that there is very little optimization gained by creating a tree. Dense mode is also appropriate when the volume of data is sufficiently low that optimizing its delivery is not worth the overhead of creating and maintaining a tree. With SM we use the convention of core=FF:FF:FF:FF to indicate the packet should be sent via dense-mode. For such packets no tree is formed and routers merely forward the packet using reverse path forwarding. As in DVMRP, states (S,M), where S is the source IP address, are created for dense mode groups. Routers find out whether their neighbors support SM, and other characteristics of their neighbors, through Hello messages. A dense mode SM-packet should only be sent to SM-aware neighbors. As with DVMRP, tunnels can be configured between SM-aware nodes to enable a wider range for delivery of dense-mode SM packets. - the ability to join a set of groups. The join message contains (C, M, mask). That facilitates having content parameterized by M. For instance, if the set of groups (C,*) is for stock information, certain bits in M can encode industry, country, etc. To receive information about all stocks, join (C,*). To receive some subset, join a more specific (M, mask) for core C. 2.10 SM Issues 2.10.1 Host API and Kernel Changes The SM architecture require changes to the host Application Programming Interface (API) and kernel. Host may join a group using either SM Join - where hosts send joins similarly to an SM router or IGMP extended to carry the core address as well as a class-D address. As noted before, host SM Join should only be used where appropriate Expires April 2000 [Page 18] Internet Draft Simple Multicast October 1999 e.g. when there is no local SM support. Taking the BSD Sockets API as an example, joining a group is achieved using a system call; the data structure passed with the system call as an argument only supports the specification of a class-D address and interface (IP) address. For SM this data structure needs modifying to include a core address element, which can be concatenated with the class-D address to form SM's 8 byte group identifier. The kernel SM software, or IGMP software, can then make use of this information to generate a SM join message, or IGMP Report, respectively. Similarly, when data is sent to a group, the data structure passed to the send system call must include a core address. The kernel SM software can then place this core address in the SM header. When an SM packet (identified by the IP protocol field) is received, the kernel SM software is invoked and the SM header is decapsulated before being send to the upper layer. 2.10.1.1 Extending IGMP While not necessary, we propose using TLV in IGMP Membership Report messages. It is anticipated that IGMP will be extended for various purposes in future. The use of TLV will facilitate that. In addition to the class-D address, a field called the extended address field, for lack of a better term, is defined to carry the additional address require in IGMPv3, Express, SM and Distributed Core Multicast (DCM). The IGMP Membership Report message is encoded as follow: Type Value Classic: S,G (if IGMPv3 with source specific joins) Express: S,E Simple: C,M DCM: (S),G where S is a list of channels Hence the extended address field carries: i) the source address for classical IP multicast (IGMPv3 with source specific joins) ii) the source address for Express iii) the core address for SM iv) the pointer to a list of channels for DCM. Extending IGMP is perfectly feasible - it has been done before in upgrading from IGMPv1 to IGMPv2, and changes will be required for IGMPv3 if it gains wider acceptance. The kernel modifications required to support SM are mainly to handle the additional address field. The host API change itself require only the addition of two parameters. We do not, therefore, consider host changes as barriers to SM deployment. Expires April 2000 [Page 19] Internet Draft Simple Multicast October 1999 2.10.2 Layer 2 Filtering In conventional IP multicast, each class D could be mapped to a distinct MAC address if 28 bits were available at the MAC layer for mapping. However, since only 23 bits of the MAC address is used for mapping, 32 IP multicast address could potentially be mapped to one MAC layer address. Hence higher layer filtering of multicast packets is required. If the low-order 4 bytes of the SM group identifier - the class-D address, is similarly mapped, there is the potential for each of a subnet's hosts to join different SM groups, with their group-ids differing only in the core address portion of the group-id. In this worst-case scenario the transmission of packets to one group will be received by hosts belonging to all other SM groups on the subnet; a group's packets only become distinguishable at the hosts' network layers. In a more realistic case we might reasonably expect only a small percentage of a subnet's hosts to receive packets unnecessarily. One possible way to reduce the amount of filtering at the network layer, would be to statically map the core address to a multicast layer 2 address if we assume groups associated with a core are likely to be related. This would still potentially incur higher layer filtering of undesired groups, but only those hosts subscribed to group(s) associated with a particular core would be affected. The problem of mapping a larger-than-usual network identifier to a layer 2 address is not unique to SM - the problem manifests itself in IPv6 and EXPRESS. One possible way of guaranteeing layer-2 multicast destination address uniqueness would have special node(s) map unique layer 2 address to the group-id. Before a node could send, receive or forward data, it has to obtain the layer 2 address. IGMP can be extended for this purpose. Another possible solution is to have hardware filter based on a group address at a specific offset and of a specific length. The NIC would be snooping the IP header, but software should be able to program it to filter addresses at the desired offset. Expires April 2000 [Page 20] Internet Draft Simple Multicast October 1999 3.0 Packet formats This section describes all the packet formats. Simple Multicast could be implemented as very small modifications to PIM, CBT, or BGMP. The packet types are: - data packet - join-request - join-ack - keep-alive (sent by child to parent) - heartbeat (sent by parent to child) - flush-tree (sent by parent to child after a loop is detected, to clear out state from looped tree as quickly as possible and cause subtree to be reformed) For all control packets (JOIN-REQUEST, JOIN-ACK, KEEP-ALIVE, HEARTBEAT, FLUSH- TREE), the "Protocol" field in the IPv4 header is set to SM (a new protocol field). 3.1 SM-'tunnels' Upstream (towards the core) or downstream SM routers may not be immediate neighbors, if there are non-SM routers on the path between them. In a traditional tunnel between R1 and R2, R1 must add an extra IP header, and R2 must delete the header. SM gets the same functionality without adding and deleting headers. Instead all that is needed is to overwrite the destination address in the IP header to the address of the "tunnel" endpoint. The reason this can be done is that the information necessary for SM-routers to route the packet (namely C and M) are contained in the SM header. JOIN-REQUESTs and JOIN-ACKs allow tunnel-endpoints to learn of each other. The state for a "tunnel" consists of the IP address of the endpoint, and the number of actual IP hops in the tunnel. The purpose of keeping the count of the tunnel's hops is because SM counts the length of the tree, so that senders can know what to set as the TTL in data packets. Expires April 2000 [Page 21] Internet Draft Simple Multicast October 1999 3.2 Data Packet Header IP Header 0 1 2 3^M 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^M +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^M |Version| IHL |Type of Service| Total Length |^M +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^M | Identification |Flags| Fragment Offset |^M +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^M | Time to Live | Protocol = | Header Checksum |^M | | IPPROTO_SM | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^M | Source Address |^M +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^M | Destination Address |^M +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^M SM Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^M | Core Address |^M +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^M | Multicast Address |^M +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^M |Protocol=egUDP| Core Mask | |L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^M This SM header includes C, M, loop detect flag, where C=FF:FF:FF:FF ^M indicates packet should be delivered dense-mode.^M The 'L' bit in Flag, if set, indicates the TTL for this packet should never reach 0 (See Loops).^M ^M The IP Destination address is ALL-SM-NODES except in the following cases:^M ^M - when a non-member sender transmits the packet, the destination is set to the core address. The purpose of this is to enable the packet^M to be unicasted until it hits a node that is SM-aware, at which point the packet is multicast along the tree from the point at which it entered the tree. Note that if the non-member sender has joined the group as a 'sender-only' (c.f. uni-directional join in CBT), then the destination address in the data packet is either ALL-SM-NODES or the tunnel endpoint (as described below). Expires April 2000 [Page 22] Internet Draft Simple Multicast October 1999 - when the packet is transmitted on a tunnel port, in which case the^M destination address is set to the IP address of the tunnel endpoint.^M Note that at Layer 2, the MAC address is mapped to the Multicast Address M of the group (C,M), not to ALL-SM-NODES.^M Expires April 2000 [Page 23] Internet Draft Simple Multicast October 1999 3.2 JOIN-REQUEST The following control packet header fields are as defined in CBT: addr_len, checksum, Payload Length and # of options. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vers |type=1 | addr len | checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Payload Length | # of options | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Join Originating Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | core address C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast address M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast address mask m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option type | option len | option value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The destination IP address in the IP header is the Core Address. The JOIN-REQUEST is sent with the Router Alert Option. The Multicast address and corresponding mask (M,m) may appear multiple times. The total length of these fields is specified in the "addr_len" field of the common control header. The JOIN-REQUEST may contain the following option: - Originating TTL. This field is set to the TTL in the IP header of this JOIN- REQUEST packet. The receiving SM router ignores this option unless the control packet is from a SM router who is not an immediate neighbor. The value in this field is used to calculate the number of hops in a 'tunnel' = Originating TTL - TTL in the IP header for this packet. The value derived is placed in "# of hops in tunnel from you to me" in the JOIN-ACK message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | Originating TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Sender-Only The join would only be successful if the sender is on the Include Expires April 2000 [Page 24] Internet Draft Simple Multicast October 1999 Senders List or NOT in the Exclude Senders List. The sender is attached to the tree as per uni-directional Join in CBT. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 2 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires April 2000 [Page 25] Internet Draft Simple Multicast October 1999 3.3 JOIN-ACK 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vers |type=2 | addr len | checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Payload Length | # of options | # of hops in 'tunnel' | | | | from you to me | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Join Originating Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | core address C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast address M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast address mask m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option type | option len | option value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The destination IP address in the IP header is the downstream IP source address of the JOIN-REQUEST. The JOIN_ACK is sent with the Router Alert Option. The Multicast address and corresponding mask (M,m) may appear multiple times. The total length of these fields is specified in the "addr_len" field. The field "# of hops in tunnel from you to me" is ignored unless the control packet is from a SM router who is not an immediate neighbor. The value in this field is saved as state for this tunnel port. The options from the JOIN-REQUEST are copied into the JOIN-ACK, with the exception of the "Originating TTL" option. The Originating TTL is set to the TTL in the IP header of this JOIN-ACK packet. Expires April 2000 [Page 26] Internet Draft Simple Multicast October 1999 3.4 KEEP-ALIVE 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vers | type=3| addr len | checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Payload Length | # of options | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KEEP-ALIVE Originating Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | core address C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast address M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast address mask m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option type | option len | option value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The keep-alive message is sent from a child to a parent (towards core), and is sent only if a keep-alive has been received recently from a child. The destination IP address in the IP header is ALL-SM- NODES or the tunnel endpoint address. A single keep-alive can serve as many groups as fit into the list in the packet. (M,m) may appear multiple times. The total length of these fields is specified in the "addr_len" field. The KEEP-ALIVE may contain the following options: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 10 |I| reserved flag bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include/Exclude Sender Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include/Exclude Sender Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Include/Exclude Senders List that upstream routers should filter. This option may appear multiple times. The 'I' bit is set if this is an include sender list, and is zero if this is an exclude sender list. Expires April 2000 [Page 27] Internet Draft Simple Multicast October 1999 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 10 | hop count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prune Time | # of hops in 'tunnel' | | | from you to me | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - KEEP-ALIVE Option. This option should appear the same number of times as the address set (C,M,mask). It corresponds and is applicable to the address set (C,M,mask). The fields in this option are: - Number of hops to furthest leaf for (C,M,mask), hop count. The hop count is incremented at every SM hop. In addition, when the KEEP-ALIVE is received from a tunnel port, hop count = hop count + number of hops in 'tunnel'. - Prune Time for (C,M,mask), time after which, if no KEEP-ALIVE is received for group (C1, M, mask), the parent should prune off this branch. - 'Originating TTL'. This is as described in JOIN-REQUEST. Expires April 2000 [Page 28] Internet Draft Simple Multicast October 1999 3.5 HEARTBEAT 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vers | type=4| addr len | checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Payload Length | # of options | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HEARTBEAT Originating Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | core address C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast address M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast address mask m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option type | option len | option value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The heartbeat is sent by a parent to a child. It is sent periodically regardless of whether heartbeat is received from its parent. The destination IP address is set to ALL-SM-NODES or the tunnel endpoint address. Expires April 2000 [Page 29] Internet Draft Simple Multicast October 1999 The HEARTBEAT may contain the following additional options: - Include/Exclude Senders List. This is the list of allowed/prohibited senders to the group. The format of this option is the same the KEEP-ALIVE Include/Exclude Senders List, although it serves as a different purpose here. - spin-off groups (Ci,Mi). One or more spin-off groups (Ci,Mi) may be specified. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | #Groupsx8 | reserved flag bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Core Address Ci | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address Mi | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - HEARTBEAT Option. This option should appear the same number of times as the address set (C,M,mask). It corresponds and is applicable to the address set (C,M,mask). The fields in this option are: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 6 | core distance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time To Shutdown | # of hops in 'tunnel' | | | from you to me | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - distance from core. Number of hops to core (C,M,mask), core distance. The core distance is incremented at every SM hop. In addition, when the KEEP-ALIVE is received from a tunnel port, core distance = core distance + number of hops in 'tunnel' - Time left before group should be closed down. (all 'ones' indicates group should not be torn down) - The 'A' bit if set indicates the core is alive or reachable - 'Originating TTL'. This is as described in JOIN-ACK. Expires April 2000 [Page 30] Internet Draft Simple Multicast October 1999 3.6 FLUSH-TREE 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vers | type=5| addr len | checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Payload Length | # of options | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HEARTBEAT Originating Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | core address C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast address M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast address mask m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option type | option len | option value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The destination IP address is set to ALL-SM-NODES or the tunnel endpoint address. The Multicast address and corresponding mask (M,m) may appear multiple times. The total length of these fields is specified in the "addr_len" field of the common control header. No options are currently defined. 4 Acknowledgments Many people have contributed ideas to this proposal, including Harald Alvastrand, Joel Halpern and Fred Baker. The fact that SM is based on previous work in IP Multicast implies that the authors are grateful to everyone who has contributed to the development of IP Multicast. We would like to thank all members of IDMR, in particular Dino Farinacci, Mark Handley, Brad Cain, Dave Thaler Russ White and Ken Carlberg whose helpful comments have improved this proposal. Others that have provided helpful technical information include Matthew Yuen, Patrick Lee. References DNS Based RP Placement scheme Dino Farinacci's presentation in the MBONED WG, 40th IETF Meeting Static Multicast, Internet-Draft, March 1998 Expires April 2000 [Page 31] Internet Draft Simple Multicast October 1999 M. Ohta, J. Crowcroft Express IDMR Mailing List discussion CBT, Core Based Tree Multicast Routing, Internet-Draft, March 1998 Ballardie, Cain, Zhang PIM-SM, Protocol independent multicast-sparse mode Specification, RFC-2117, June 1997 Estrin, Farinacci, Helmy, Thaler, Deering, Handley, Jacobson, Liu, Sharma, and Wei. BGMP, Border Gateway Multicast Protocol Specification, Internet-Draft, March 1998 Thaler, Estrin, Meyers MASC, Multicast Address Set Claim Protocol, Internet-Draft, November 1997 Estrin, Handley, Kumar, Thaler IGMP, Internet Group Management Protocol, Version 3, Internet-Draft, November 1998 Cain, Deering, Thyagarajan "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter & T. Li, RFC1771, March 1995 "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998. Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "The IP Network Address Translator (NAT)" RFC 1631, May 1994. RFC1631 Egevang, K., Francis, P., "Administratively Scoped IP Multicast", RFC 2365, July 1998. Meyer, D., Distributed Core Multicast, L. Blazevic, J-Y. Boudec OGMP ftp://cs.ucl.ac.uk/darpa/ogmp.ps.gz Expires April 2000 [Page 32] Internet Draft Simple Multicast October 1999 Authors' Addresses Radia Perlman Sun Microsystems Laboratories 2 Elizabeth Drive Chelmsford, MA 01824 Radia.Perlman@sun.com Cheng-Yin Lee Nortel Networks PO Box 3511, Station C Ottawa, ON K1Y 4H7, Canada leecy@nortel.com Tony Ballardie Research Consultant aballardie@acm.org Jon Crowcroft Department of Computer Science University College London Gower Street London, WC1E 6BT, UK J.Crowcroft@cs.ucl.ac.uk Zheng Wang Bell Labs Lucent Technologies 101 Crawfords Corner Road Holmdel NJ 07733 zhwang@bell-labs.com Thomas Maufer 3Com Corporation 5400 Bayfront Plaza Santa Clara, CA 95052 maufer@3com.com Christophe Diot Sprint ATL 1 Adrian Court Burlingame CA 94010 USA cdiot@sprintlabs.com Joseph Thoo Nortel Networks PO Box 3511, Station C Ottawa, ON K1Y 4H7, Canada Expires April 2000 [Page 33] Internet Draft Simple Multicast October 1999 jthoo@nortel.com Mark Green @Home Networks markg@corp.home.net Expires April 2000 [Page 34]