--- 1/draft-ietf-mboned-routingarch-02.txt 2006-03-03 22:12:42.000000000 +0100 +++ 2/draft-ietf-mboned-routingarch-03.txt 2006-03-03 22:12:42.000000000 +0100 @@ -1,20 +1,22 @@ Internet Engineering Task Force P. Savola Internet-Draft CSC/FUNET -Obsoletes: October 12, 2005 +Obsoletes: March 3, 2006 3913,2189,2201,1584,1585 (if approved) -Expires: April 15, 2006 +Intended status: Best Current +Practice +Expires: September 4, 2006 Overview of the Internet Multicast Routing Architecture - draft-ietf-mboned-routingarch-02.txt + draft-ietf-mboned-routingarch-03.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 @@ -25,25 +27,25 @@ 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, 2006. + This Internet-Draft will expire on September 4, 2006. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). Abstract The lack of up-to-date documentation on IP multicast routing protocols and procedures has caused a great deal of confusion. To clarify the situation, this memo describes the routing protocols and techniques currently (as of this writing) in use. Table of Contents @@ -83,22 +85,22 @@ 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 13 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Multicast Payload Transport Extensions . . . . . . . 18 A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 18 A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 18 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 - Intellectual Property and Copyright Statements . . . . . . . . . . 19 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 + Intellectual Property and Copyright Statements . . . . . . . . . . 20 1. Introduction Good, up-to-date documentation of IP multicast is close to non- existent. This issue is severely felt with multicast routing protocols and techniques. The consequence is that those who wish to learn of IP multicast and how the routing works in the real world do not know where to begin. The aim of this document is to provide a brief overview of multicast @@ -138,24 +140,23 @@ ASM Any Source Multicast BGMP Border Gateway Multicast Protocol BSR Bootstrap Router CBT Core Based Trees CGMP Cisco Group Management Protocol DR Designated Router DVMRP Distance Vector Multicast Routing Protocol GARP Group Address Resolution Protocol IGMP Internet Group Management Protocol + MBGP Multi-protocol BGP (*not* "Multicast BGP") MLD Multicast Listener Discovery - MSNIP Multicast Source Notification of Interest Protocol MOSPF Multicast OSPF - MBGP Multi-protocol BGP (*not* "Multicast BGP") 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) Sparse Mode RGMP (Cisco's) Router Group Management Protocol RP Rendezvous Point SSM Source-specific Multicast @@ -171,39 +172,39 @@ By far, the most common multicast routing protocol is PIM-SM [I-D.ietf-pim-sm-v2-new]. 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. 2.1.2. PIM-DM Whereas PIM-SM is designed to avoid unnecessary flooding of multicast - data, PIM-DM [I-D.ietf-pim-dm-new-v2] operates in a "dense" mode, - flooding the 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 traffic. + data, PIM-DM [RFC3973] operates in a "dense" mode, flooding the + 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 traffic. PIM-DM may be some fit in small and/or simple networks, where setting up an RP would be unnecessary, and possibly in cases where a large number of users is expected to be able to wish to receive the transmission so that the amount of state the network has to keep is minimal. Therefore PIM-DM has typically only been used in special deployments, never currently in, e.g., ISPs' networks. PIM-DM never really got popular due to its reliance of data plane and potential for loops, and the over-reliance of the complex Assert mechanism. Further, it was a non-starter with high-bandwidth streams. Many implementations also support so-called "sparse-dense" mode, - where Sparse mode is is used by default, but Dense is used for + 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 been transitioned away from sparse- dense to only sparse mode. 2.1.3. Bi-directional PIM Bi-directional PIM [I-D.ietf-pim-bidir] aims to offer streamlined PIM-SM operation, without data-driven events and data-encapsulation, inside a PIM-SM domain. The usage of bi-dir PIM may be on the increase especially inside sites leveraging multicast. @@ -238,22 +239,22 @@ 2.1.6. BGMP BGMP [RFC3913] did not get sufficient support within the service provider community to get adopted and moved forward in the IETF standards process. There were no reported production implementations and no production deployments. 2.1.7. CBT - CBT [RFC2201] was was an academic project that provided the basis for - PIM sparse mode shared trees. Once the shared tree functionality was + CBT [RFC2201] was an academic project that provided the basis for PIM + sparse mode shared trees. Once the shared tree functionality was incorporated into PIM implementations, there was no longer a need for a production CBT implemention. Therefore, CBT never saw production deployment. 2.1.8. Interactions and Summary It is worth noting that is it is possible to run different protocols with different groups ranges (e.g., treat some groups as dense mode in an other-wise PIM-SM network; this typically requires manual configuration of the groups) or interact between different protocols @@ -386,24 +387,24 @@ these using out of band mechanisms, and when subscribing to an (S,G) channel indicate toward which source(s) the multicast routing protocol should send the Join messages. As of this writing, there are attempts to analyze and/or define out- of-band source discovery functions which would help SSM in particular [I-D.lehtonen-mboned-dynssm-req]. 2.3.2. MSDP - Multicast Source Discovery Mechanism [RFC3618] was invented as a - stop-gap mechanism, when it became apparent that multiple PIM-SM - domains (and RPs) were needed in the network, and information about - the active sources needed to be propagated between the PIM-SM domains + Multicast Source Discovery Protocol [RFC3618] was invented as a stop- + gap mechanism, when it became apparent that multiple PIM-SM domains + (and RPs) were needed in the network, and information about the + active sources needed to be propagated between the PIM-SM domains using some other protocol. MSDP is also used to share the state about sources between multiple RPs in a single domain for, e.g., redundancy purposes [RFC3446]. There is also work in progress to achieve the same using PIM extensions [I-D.ietf-pim-anycast-rp]. See Section 2.5 for more. There is no intent to define MSDP for IPv6, but instead use only SSM and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues]. @@ -424,21 +425,21 @@ For PIM-SM, configuration mechanisms exist which are used to configure the RP addresses and which groups are to use those RPs in the routers. This section outlines the approaches. 2.4.1. Manual Configuration with an Anycast Address It is often easiest just to manually configure the RP information on the routers when PIM-SM is used. Originally, static RP mapping was considered suboptimal since it - required explicit configuration chages every time the RP address + required explicit configuration changes every time the RP address changed. However, with the advent of anycast RP addressing, the RP address is unlikely to ever change. Therefore, the administrative burden is generally limited to initial configuration. Since there is usually a fair amount of multicast configuration required on all routers anyway (eg, PIM on all interfaces), adding the RP address statically isn't really an issue. Further, static anycast RP mapping provides the benefits of RP load balancing and redundancy (see Section 2.5) without the complexity found in dynamic mechanisms like Auto-RP and Bootstrap Router (BSR). @@ -565,22 +566,23 @@ These options are discussed in this section. 2.7.1. Router-to-Router Flooding Reduction A proprietary solution, Cisco's RGMP [RFC3488] has been developed to reduce the amount of router-to-router flooding on a LAN. This is typically only considered a problem in some Ethernet-based Internet Exchange points. - There have been proposals to snoop PIM messages [I-D.tsenevir-pim-sm- - snoop][I-D.serbest-l2vpn-vpls-mcast] to achieve the same effect. + There have been proposals to snoop PIM messages + [I-D.tsenevir-pim-sm-snoop][I-D.serbest-l2vpn-vpls-mcast] to achieve + the same effect. 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. IPv6 is not supported. @@ -589,86 +591,79 @@ [GARP] as a link-layer method to perform the same functionality. The implementation status is unknown. IGMP snooping [I-D.ietf-magma-snoop] 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. To allow the snooping switches to identify at which ports the routers reside (and therefore where to flood the packets) instead of requiring manual configuration, - Multicast Router Discovery protocol is being specified [I-D.ietf- - magma-mrdisc]. IGMP proxying [I-D.ietf-magma-igmp-proxy] 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. + Multicast Router Discovery protocol is being specified [RFC4286]. + IGMP proxying [I-D.ietf-magma-igmp-proxy] 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. 3. Acknowledgements Tutoring a couple multicast-related papers, the latest by Kaarle Ritvanen [RITVANEN] convinced the author that the 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, and Dino Farinacci - provided good comments, helping in improving this document. + Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, and + Bharat Joshi provided good comments, helping in improving this + document. 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations This memo only describes different approaches to multicast routing, and this has no security considerations; the security analysis of the mentioned protocols is out of scope of this memo. However, there has been analysis of the security of multicast routing - infrastructures [I-D.ietf-mboned-mroutesec], IGMP/MLD [I-D.daley- - magma-smld-prob], and PIM last-hop issues [I-D.savola-pim-lasthop- - threats]. + infrastructures [I-D.ietf-mboned-mroutesec], IGMP/MLD + [I-D.daley-magma-smld-prob], and PIM last-hop issues + [I-D.savola-pim-lasthop-threats]. 6. References 6.1. Normative References [I-D.ietf-idmr-dvmrp-v3] Pusateri, T., "Distance Vector Multicast Routing Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress), December 2003. [I-D.ietf-idmr-dvmrp-v3-as] Pusateri, T., "Distance Vector Multicast Routing Protocol Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01 (work in progress), May 2004. [I-D.ietf-isis-wg-multi-topology] Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in - IS-IS", draft-ietf-isis-wg-multi-topology-10 (work in - progress), May 2005. + IS-IS", draft-ietf-isis-wg-multi-topology-11 (work in + progress), October 2005. [I-D.ietf-ospf-mt] Psenak, P., "Multi-Topology (MT) Routing in OSPF", - draft-ietf-ospf-mt-04 (work in progress), April 2005. + draft-ietf-ospf-mt-06 (work in progress), February 2006. [I-D.ietf-pim-bidir] - Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, - "Bi-directional Protocol Independent Multicast (BIDIR- - PIM)", draft-ietf-pim-bidir-07 (work in progress), - March 2005. - - [I-D.ietf-pim-dm-new-v2] - Adams, A., Nicholas, J., and W. Siadak, "Protocol - Independent Multicast - Dense Mode (PIM-DM): Protocol - Specification (Revised)", draft-ietf-pim-dm-new-v2-05 - (work in progress), June 2004. + Handley, M., "Bi-directional Protocol Independent + Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-08 (work in + progress), October 2005. [I-D.ietf-pim-sm-v2-new] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-11 (work in progress), October 2004. [I-D.ietf-ssm-arch] Holbrook, H. and B. Cain, "Source-Specific Multicast for @@ -688,75 +683,74 @@ [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. + [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol + Independent Multicast - Dense Mode (PIM-DM): Protocol + Specification (Revised)", RFC 3973, January 2005. + 6.2. Informative References [CGMP] "Cisco Group Management Protocol", . [GARP] Tobagi, F., Molinero-Fernandez, P., and M. Karam, "Study of IEEE 802.1p GARP/GMRP Timer Values", 1997. [I-D.daley-magma-smld-prob] Daley, G. and G. Kurup, "Trust Models and Security in Multicast Listener Discovery", draft-daley-magma-smld-prob-00 (work in progress), July 2004. [I-D.ietf-idr-rfc2858bis] Bates, T., "Multiprotocol Extensions for BGP-4", - draft-ietf-idr-rfc2858bis-07 (work in progress), - August 2005. + draft-ietf-idr-rfc2858bis-08 (work in progress), + January 2006. [I-D.ietf-magma-igmp-proxy] Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/ MLD-based Multicast Forwarding ('IGMP/MLD Proxying')", draft-ietf-magma-igmp-proxy-06 (work in progress), April 2004. - [I-D.ietf-magma-mrdisc] - Haberman, B. and J. Martin, "Multicast Router Discovery", - draft-ietf-magma-mrdisc-07 (work in progress), May 2005. - [I-D.ietf-magma-snoop] Christensen, M., Kimball, K., and F. Solensky, "Considerations for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 (work in progress), February 2005. [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-mboned-mroutesec] Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast Routing Security Issues and Enhancements", draft-ietf-mboned-mroutesec-04 (work in progress), October 2004. [I-D.ietf-pim-anycast-rp] Farinacci, D. and Y. Cai, "Anycast-RP using PIM", - draft-ietf-pim-anycast-rp-04 (work in progress), - August 2005. + draft-ietf-pim-anycast-rp-07 (work in progress), + February 2006. [I-D.ietf-pim-sm-bsr] Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", - draft-ietf-pim-sm-bsr-05 (work in progress), - February 2005. + draft-ietf-pim-sm-bsr-06 (work in progress), October 2005. [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. [I-D.savola-pim-lasthop-threats] Savola, P., "Last-hop Threats to Protocol Independent Multicast (PIM)", draft-savola-pim-lasthop-threats-01 (work in progress), January 2005. @@ -809,20 +803,23 @@ [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. + [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", + RFC 4286, December 2005. + [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. @@ -852,21 +849,21 @@ Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland Email: psavola@funet.fi Full Copyright Statement - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE @@ -892,12 +889,12 @@ http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment - Funding for the RFC Editor function is currently provided by the - Internet Society. + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA).