--- 1/draft-ietf-mboned-routingarch-11.txt 2007-10-17 09:12:06.000000000 +0200 +++ 2/draft-ietf-mboned-routingarch-12.txt 2007-10-17 09:12:06.000000000 +0200 @@ -1,21 +1,19 @@ Internet Engineering Task Force P. Savola Internet-Draft CSC/FUNET -Obsoletes: 3913,2189,2201,1584 October 13, 2007 -(if approved) -Intended status: Best Current +Intended status: Best Current October 17, 2007 Practice -Expires: April 15, 2008 +Expires: April 19, 2008 Overview of the Internet Multicast Routing Architecture - draft-ietf-mboned-routingarch-11.txt + draft-ietf-mboned-routingarch-12.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 @@ -26,21 +24,21 @@ 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 April 15, 2008. + This Internet-Draft will expire on April 19, 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. @@ -92,21 +90,21 @@ 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 17 2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 19 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . 25 + A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 24 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 @@ -259,27 +257,26 @@ protocol. PIM-DM is no longer in widespread use. Many implementations also support so-called "sparse-dense" configuration, where Sparse mode is used by default, but Dense is used for configured multicast group ranges (such as Auto-RP in Section 2.4.3) only. Lately, many networks have transitioned away from sparse-dense to only sparse mode. 2.1.3. Bi-directional PIM - Bi-directional PIM [I-D.ietf-pim-bidir] is a multicast forwarding - protocol that establishes a common shared-path for all sources with a - single root. It can be used as an alternative to PIM-SM inside a - single domain. It doesn't have data-driven events or data- - encapsulation. As it doesn't keep source-specific state, it may be - an appealing approach especially in sites with a large number of - sources. + Bi-directional PIM [RFC5015] is a multicast forwarding protocol that + establishes a common shared-path for all sources with a single root. + It can be used as an alternative to PIM-SM inside a single domain. + It doesn't have data-driven events or data-encapsulation. As it + doesn't keep source-specific state, it may be an appealing approach + especially in sites with a large number of sources. As of this writing, there is no inter-domain solution to configure a group range to use bi-directional PIM. 2.1.4. DVMRP Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] [I-D.ietf-idmr-dvmrp-v3] [I-D.ietf-idmr-dvmrp-v3-as] was the first protocol designed for multicasting. To get around initial deployment hurdles, it also included tunneling capabilities which were part of @@ -833,23 +830,23 @@ 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 - Chisholm, John Zwiebel, Dan Romascanu, Thomas Morin, Ron Bonica, and - Prashant Jhingran provided good comments, helping in improving this - document. + Chisholm, John Zwiebel, Dan Romascanu, Thomas Morin, Ron Bonica, + Prashant Jhingran, and Tim Polk provided good comments, helping in + improving this document. 4. IANA Considerations IANA is requested to update the following registries by adding a reference to this document: o OSPFv2 Option registry: MC-bit o OSPFv2 Link state type: Group-membership-LSA @@ -872,25 +869,20 @@ mentioned protocols is out of scope of this memo. However, there has been analysis of the security of multicast routing infrastructures [RFC4609], IGMP/MLD [I-D.daley-magma-smld-prob], and PIM last-hop issues [I-D.ietf-pim-lasthop-threats]. 6. References 6.1. Normative References - [I-D.ietf-pim-bidir] - Handley, M., "Bi-directional Protocol Independent - Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-09 (work in - progress), February 2007. - [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. @@ -909,20 +901,24 @@ IP", RFC 4607, August 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007. + [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, + "Bidirectional Protocol Independent Multicast (BIDIR- + PIM)", RFC 5015, October 2007. + 6.2. Informative References [802.1ak] "IEEE 802.1ak - Multiple Registration Protocol", . [CGMP] "Cisco Group Management Protocol", . [GMRP] "GARP Multicast Registration Protocol", . @@ -1029,24 +1025,20 @@ [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 @@ -1068,41 +1060,40 @@ [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006. [RITVANEN] Ritvanen, K., "Multicast Routing and Addressing", HUT Report, Seminar on Internetworking, May 2004, . Appendix A. Multicast Payload Transport Extensions - A couple of mechanisms have been, and are being specified, to improve - the characteristics of the data that can be transported over - multicast. + A couple of mechanisms have been 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. + We describe those mechanisms that have impact on the multicast + routing infrastructure, e.g., require or specify router assistance or + involvement in some form. Purely end-to-end or host-based protocols + are out of scope. A.1. Reliable Multicast - 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. + There has been some work on reliable multicast delivery so that + applications with reliability requirements could use multicast + instead of simple unreliable UDP. - 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. 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. + Most of the mechanisms are host-based and as such out of scope of + this document, but one relevant from multicast routing perspective is + Pragmatic Generic Multicast (PGM) [RFC3208]. It 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. 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