--- 1/draft-ietf-mboned-routingarch-10.txt 2007-10-13 14:12:07.000000000 +0200 +++ 2/draft-ietf-mboned-routingarch-11.txt 2007-10-13 14:12:07.000000000 +0200 @@ -1,22 +1,21 @@ Internet Engineering Task Force P. Savola Internet-Draft CSC/FUNET -Obsoletes: September 25, 2007 -3913,2189,2201,1584,1585 +Obsoletes: 3913,2189,2201,1584 October 13, 2007 (if approved) Intended status: Best Current Practice -Expires: March 28, 2008 +Expires: April 15, 2008 Overview of the Internet Multicast Routing Architecture - draft-ietf-mboned-routingarch-10.txt + draft-ietf-mboned-routingarch-11.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -27,89 +26,89 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 28, 2008. + This Internet-Draft will expire on April 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications. - This memo also obsoletes and reclassifies to Historic several older - RFCs. These RFCs describe multicast routing protocols that were - never widely deployed or have fallen into disuse. + This memo also reclassifies to Historic several older RFCs. These + RFCs describe multicast routing protocols that were never widely + deployed or have fallen into disuse. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5 2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6 2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 7 2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 7 - 2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 7 - 2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 8 - 2.2. Distributing Topology Information . . . . . . . . . . . . 8 + 2.2. Distributing Topology Information . . . . . . . . . . . . 9 2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 9 - 2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 9 + 2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 10 2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 10 2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 11 - 2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 12 2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12 - 2.4. Configuring and Distributing PIM RP Information . . . . . 12 - 2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 12 + 2.4. Configuring and Distributing PIM RP Information . . . . . 13 + 2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 13 2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13 - 2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 13 + 2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 14 2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14 - 2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 14 - 2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 14 + 2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 15 + 2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 15 2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 15 2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 15 2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15 - 2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 15 - 2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15 + 2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 16 + 2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 16 2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 16 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 16 - 2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16 + 2.7. Restricting Multicast Flooding in the Link Layer . . . . . 17 2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 17 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 17 - 2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 18 - 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 + 2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 19 + 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 6.1. Normative References . . . . . . . . . . . . . . . . . . . 19 - 6.2. Informative References . . . . . . . . . . . . . . . . . . 20 - Appendix A. Multicast Payload Transport Extensions . . . . . . . 23 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Appendix A. Multicast Payload Transport Extensions . . . . . . . 24 A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 24 - A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 24 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 - Intellectual Property and Copyright Statements . . . . . . . . . . 25 + A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 25 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 + Intellectual Property and Copyright Statements . . . . . . . . . . 26 1. Introduction This document provides a brief overview of multicast routing architectures that are currently deployed on the Internet and how those protocols fit together. It also describes those multicast routing protocols that were never widely deployed or have fallen into disuse. A companion document [I-D.ietf-mboned-addrarch] describes multicast addressing architectures. @@ -128,28 +127,27 @@ o interacting with hosts (Section 2.6), and o restricting the multicast flooding in the link layer (Section 2.7). Section 2 starts by describing a simplistic example how these classes of mechanisms fit together. Some multicast data transport issues are also introduced in Appendix A. - This memo obsoletes and re-classifies to Historic [RFC2026] the - following RFCs: + This memo re-classifies to Historic [RFC2026] the following RFCs: o Border Gateway Multicast Protocol (BGMP) [RFC3913], o Core Based Trees (CBT) [RFC2189] [RFC2201], - o Multicast OSPF (MOSPF) [RFC1584] and [RFC1585]. + o Multicast OSPF (MOSPF) [RFC1584]. For the most part, these protocols have fallen into disuse. There may be legacy deployments of some of these protocols, which are not affected by this reclassification. See Section 2.1 for more on each protocol. Further historical perspective may be found in, for example, [RFC1458], [IMRP-ISSUES], and [IM-GAPS]. 1.1. Multicast-related Abbreviations @@ -170,20 +168,21 @@ MMRP (IEEE 802.1ak) Multicast Multiple Registration Proto. MOSPF Multicast OSPF MSDP Multicast Source Discovery Protocol PGM Pragmatic General Multicast PIM Protocol Independent Multicast PIM-DM PIM - Dense Mode PIM-SM PIM - Sparse Mode PIM-SSM PIM - Source-Specific Multicast RGMP (Cisco's) Router Group Management Protocol RP Rendezvous Point + RPF Reverse Path Forwarding SAFI Subsequent Address Family Identifier SDP Session Description Protocol SSM Source-specific Multicast 2. Multicast Routing In order to give a simplified summary how each of these class of mechanisms fits together, consider the following multicast receiver scenario. @@ -205,31 +203,44 @@ hop-by-hop multicast forwarding state (Section 2.1) to the source (in SSM) or first through the RP (in ASM). Routers use an RP to find out all the sources for a group (Section 2.3). When multicast transmission arrives at the receiver's LAN, it is flooded to every Ethernet switch port unless flooding reduction such as IGMP snooping is employed (Section 2.7). 2.1. Setting up Multicast Forwarding State The most important part of multicast routing is setting up the - multicast forwarding state. This section describes the protocols - commonly used for this purpose. + multicast forwarding state. State maintenance requires periodic + messaging because forwarding state has a timeout. This section + describes the protocols commonly used for this purpose. 2.1.1. PIM-SM By far, the most common multicast routing protocol is PIM-SM [RFC4601]. The PIM-SM protocol includes both Any Source Multicast - (ASM) and Source-Specific Multicast (SSM) functionality; PIM-SSM is a - subset of PIM-SM. Most current routing platforms support PIM-SM. It - builds a unidirectional, group-specific distribution tree consisting - of the interested receivers of a group. + (ASM) and Source-Specific Multicast (SSM) functionality. PIM-SSM is + a subset of PIM-SM that does not use the RPs but instead requires + that receivers know the (source,group) pair and signal that + explicitly. Most current routing platforms support PIM-SM. + + PIM routers elect a designated router on each LAN and the DR is + responsible for PIM messaging and source registration on behalf of + the hosts. The DR encapsulates multicast packets sourced from the + LAN in a unicast tunnel to the RP. PIM-SM builds a unidirectional, + group-specific distribution tree consisting of the interested + receivers of a group. Initially the multicast distribution tree is + rooted at the RP but later the DRs have the option of optimizing the + delivery by building (source,group)-specific trees. + + A more lengthy introduction to PIM-SM can be found in Section 3 of + [RFC4601]. 2.1.2. PIM-DM Whereas PIM-SM has been designed to avoid unnecessary flooding of multicast data, PIM-DM [RFC3973] assumed that almost every subnet at a site had at least one receiver for a group. PIM-DM floods multicast transmissions throughout the network ("flood and prune") unless the leaf parts of the network periodically indicate that they are not interested in that particular group. @@ -428,46 +439,58 @@ A congruent topology can be deployed using unicast routing protocols that provide no support for a separate multicast topology. In intra- domain that approach is often adequate. However, it is recommended that if interdomain routing uses BGP, multicast-enabled sites should use MP-BGP SAFI=2 for multicast and SAFI=1 for unicast even if the topology was congruent to explicitly signal "yes, we use multicast". The following table summarizes the approaches that can be used to distribute multicast topology information. - +-------------+---------------+ + +----------------+---------------+ | Interdomain | Intradomain | - +--------------------- +--------------+--------------+ - | MP-BGP SAFI=2 | Recommended | Yes | + +--------------------- +----------------+--------------+ + | MP-BGP SAFI=2 | Yes | Yes | | MP-BGP SAFI=3 | Doesn't work | Doesn't work | - | IS-IS multi-topology | No | Yes | - | OSPF multi-topology | No | Few implem. | - +----------------------+--------------+--------------+ + | IS-IS multi-topology | Not applicable | Yes | + | OSPF multi-topology | Not applicable | Few implem. | + +----------------------+----------------+--------------+ + + "Not applicable" refers to the fact that IGP protocols can't be used + in interdomain routing. "Doesn't work" means that while MP-BGP + SAFI=3 was defined and could apply, that part of the specification + has not been implemented and can't be used in practice. "Yes" lists + the mechanisms which are generally applicable and known to work. + "Few implem." means that the approach could work but is not commonly + available. 2.3. Learning (Active) Sources To build a multicast distribution tree, the routing protocol needs to find out where the sources for the group are. In case of SSM, the user specifies the source IP address or it is otherwise learned out - of band. In ASM, RPs are used to find out the sources (which in turn - requires a mechanism to find the RPs as discussed in Section 2.4). + of band. - Learning active sources is a relatively straightforward process with - a single PIM-SM domain and with a single RP, but having a single - PIM-SM domain for the whole Internet is a completely unscalable model - for many reasons. Therefore it is required to be able to split up - the multicast routing infrastructures to smaller domains, and there - must be a way to share information about active sources using some - mechanism if the ASM model is to be supported. + In ASM, the RPs know about all the active sources in a local PIM + domain. As a result, when PIM-SM or bi-dir PIM is used in intra- + domain the sources are learned as a feature of the protocol itself. - This section discusses the options. + Having a single PIM-SM domain for the whole Internet is an + insufficient model for many reasons, including scalability, + administrative boundaries and different technical tradeoffs. + Therefore it is required to be able to split up the multicast routing + infrastructures to smaller domains, and there must be a way to share + information about active sources using some mechanism if the ASM + model is to be supported. + + This section discusses the options of learning active sources that + apply in an inter-domain environment. 2.3.1. SSM Source-specific Multicast [RFC4607] (sometimes also referred to as "single-source Multicast") does not count on learning active sources in the network. Recipients need to know the source IP addresses using an out of band mechanism which are used to subscribe to the (source, group) channel. The multicast routing uses the source address to set up the state and no further source discovery is needed. @@ -691,27 +714,27 @@ still commonplace, but are also often used in new deployments. Some vendors also support SSM mapping techniques for receivers which use an older IGMP/MLD version where the router maps the join request to an SSM channel based on various, usually complex means of configuration. 2.6.3. Summary The following table summarizes the techniques host interaction. - +-------+------+----------------------+ + +-------+------+----------------------------+ | IPv4 | IPv6 | Notes | - +--------------------+-------+------+----------------------+ + +--------------------+-------+------+----------------------------+ | Host sending | Yes | Yes | No support needed | | Host receiving ASM | IGMP | MLD | Any IGMP/MLD version | - | Host receiving SSM | IGMPv3| MLDv2| Also SSM-mapping | - +--------------------+-------+------+----------------------+ + | Host receiving SSM | IGMPv3| MLDv2| Any version w/ SSM-mapping | + +--------------------+-------+------+----------------------------+ 2.7. Restricting Multicast Flooding in the Link Layer Multicast transmission in the link layer, for example Ethernet, typically includes some form of flooding the packets through a LAN. This causes unnecessary bandwidth usage and discarding unwanted frames on those nodes which did not want to receive the multicast transmission. Therefore a number of techniques have been developed, to be used in @@ -740,76 +763,80 @@ messages [I-D.ietf-l2vpn-vpls-pim-snooping]. 2.7.2. Host/Router Flooding Reduction There are a number of techniques to help reduce flooding both from a router to hosts, and from a host to the routers (and other hosts). Cisco's proprietary CGMP [CGMP] provides a solution where the routers notify the switches, but also allows the switches to snoop IGMP packets to enable faster notification of hosts no longer wishing to - receive a group. Fast leave behaviour support for IGMPv3 hasn't been - implemented. Due to IGMP report suppression in IGMPv1 and IGMPv2, - multicast is still flooded to ports which were once members of a - group as long as there is at least one receiver on the link. + receive a group. Implementations of CGMP do not support fast leave + behaviour with IGMPv3. Due to IGMP report suppression in IGMPv1 and + IGMPv2, multicast is still flooded to ports which were once members + of a group as long as there is at least one receiver on the link. Flooding restrictions are done based on multicast MAC addresses. - IPv6 is not supported. + Implementations of CGMP do not support IPv6. IEEE 802.1D-2004 specification describes Generic Attribute Registration Protocol (GARP), and GARP Multicast Registration Protocol (GMRP) [GMRP] is a link-layer multicast group application of GARP that notifies switches about MAC multicast group memberships. If GMRP is used in conjunction with IP multicast, then the GMRP registration function would become associated with an IGMP "join." However, this GMRP-IGMP association is beyond the scope of GMRP. GMRP requires support at the host stack and it has not been widely implemented. Further, IEEE 802.1 considers GARP and GMRP obsolete being replaced by Multiple Registration Protocol (MRP) and Multicast Multiple Registration Protocol (MMRP) that are being specified in IEEE 802.1ak [802.1ak]. MMRP is expected to be mainly used between bridges. Some further information about GARP/GMRP is also available in Appendix B of [RFC3488]. IGMP snooping [RFC4541] appears to be the most widely implemented technique. IGMP snooping requires that the switches implement a significant amount of IP-level packet inspection; this appears to be something that is difficult to get right, and often the upgrades are - also a challenge. + also a challenge. Snooping support is commonplace for IGMPv1 and + IGMPv2, but fewer switches support IGMPv3 or MLD (any version) + snooping. In the worst case, enabling IGMP snooping on a switch that + does not support IGMPv3 snooping breaks multicast capabilities of + nodes using IGMPv3. Snooping switches also need to identify the ports where routers reside and therefore where to flood the packets. This can be accomplished using Multicast Router Discovery protocol [RFC4286], looking at certain IGMP queries [RFC4541], looking at PIM Hello and possibly other messages, or by manual configuration. An issue with PIM snooping at LANs is that PIM messages can't be turned off or encrypted, leading to security issues [I-D.ietf-pim-lasthop-threats]. IGMP proxying [RFC4605] is sometimes used either as a replacement of a multicast routing protocol on a small router, or to aggregate IGMP/ MLD reports when used with IGMP snooping. 2.7.3. Summary The following table summarizes the techniques for multicast flooding reduction inside a single link for router-to-router and last-hop LANs. - +--------+-----+---------------------------+ + +--------+-----+----------------------------+ | R-to-R | LAN | Notes | - +-----------------------+--------+-----+---------------------------+ + +-----------------------+--------+-----+----------------------------+ | Cisco's RGMP | Yes | No | Replaced by PIM snooping | | PIM snooping | Yes | No | Security issues in LANs | - | IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD bad | + | IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD rare | | Multicast Router Disc | No | Yes | Few if any implem. yet | | IEEE GMRP and MMRP | No | No | No host/router deployment | | Cisco's CGMP | No | Yes | Replaced by other snooping| - +-----------------------+--------+-----+---------------------------+ + +-----------------------+--------+-----+----------------------------+ 3. Acknowledgements Tutoring a couple multicast-related papers, the latest by Kaarle Ritvanen [RITVANEN] convinced the author that up-to-date multicast routing and address assignment/allocation documentation is necessary. Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon @@ -931,24 +957,24 @@ Savola, P., "Overview of the Internet Multicast Addressing Architecture", draft-ietf-mboned-addrarch-05 (work in progress), October 2006. [I-D.ietf-mboned-ipv6-multicast-issues] Savola, P., "IPv6 Multicast Deployment Issues", draft-ietf-mboned-ipv6-multicast-issues-02 (work in progress), February 2005. [I-D.ietf-pim-lasthop-threats] - Savola, P. and J. Lingard, "Last-hop Threats to Protocol + Savola, P. and J. Lingard, "Host Threats to Protocol Independent Multicast (PIM)", - draft-ietf-pim-lasthop-threats-01 (work in progress), - June 2007. + draft-ietf-pim-lasthop-threats-03 (work in progress), + October 2007. [I-D.ietf-pim-sm-bsr] Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", draft-ietf-pim-sm-bsr-12 (work in progress), August 2007. [I-D.lehtonen-mboned-dynssm-req] Lehtonen, R., "Requirements for discovery of dynamic SSM sources", draft-lehtonen-mboned-dynssm-req-00 (work in progress), February 2005. @@ -969,23 +995,20 @@ [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast Protocols", RFC 1458, May 1993. [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994. - [RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585, - March 1994. - [RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --", RFC 2189, September 1997. [RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997. [RFC2715] Thaler, D., "Interoperability Rules for Multicast Routing Protocols", RFC 2715, October 1999. @@ -1006,20 +1029,24 @@ [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group Management Protocol (RGMP)", RFC 3488, February 2003. [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004. [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): Protocol Specification", RFC 3913, September 2004. + [RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, + "Negative-acknowledgment (NACK)-Oriented Reliable + Multicast (NORM) Protocol", RFC 3940, November 2004. + [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005. [RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping @@ -1050,29 +1077,32 @@ A couple of mechanisms have been, and are being specified, to improve the characteristics of the data that can be transported over multicast. These go beyond the scope of multicast routing, but as reliable multicast has some relevance, these are briefly mentioned. A.1. Reliable Multicast - Reliable Multicast Working Group has been working on experimental - specifications so that applications requiring reliable delivery - characteristics, instead of simple unreliable UDP, could use + Reliable Multicast Working Group has been working on mostly + experimental specifications so that applications requiring reliable + delivery characteristics, instead of simple unreliable UDP, could use multicast as a distribution mechanism. One such mechanism is Pragmatic Generic Multicast (PGM) [RFC3208]. This does not require support from the routers, bur PGM-aware routers may act in router assistance role in the initial delivery and - potential retransmission of missing data. + potential retransmission of missing data. Another mechanism is + Negative-acknowledgment (NACK)-Oriented Reliable Multicast Protocol + (NORM) [RFC3940] where routers may as an optional feature provide a + more efficient repair functionality. A.2. Multicast Group Security Multicast Security Working Group has been working on methods how the integrity, confidentiality, and authentication of data sent to multicast groups can be ensured using cryptographic techniques [RFC3740]. Author's Address