--- 1/draft-ietf-mboned-routingarch-00.txt 2006-02-05 00:20:55.000000000 +0100 +++ 2/draft-ietf-mboned-routingarch-01.txt 2006-02-05 00:20:55.000000000 +0100 @@ -1,20 +1,20 @@ Internet Engineering Task Force P. Savola Internet-Draft CSC/FUNET -Obsoletes: April 25, 2005 +Obsoletes: July 11, 2005 3913,2189,2201,1584,1585 (if approved) -Expires: October 27, 2005 +Expires: January 12, 2006 Overview of the Internet Multicast Routing Architecture - draft-ietf-mboned-routingarch-00.txt + draft-ietf-mboned-routingarch-01.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,21 +25,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 October 27, 2005. + This Internet-Draft will expire on January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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 @@ -84,21 +84,21 @@ 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1 Normative References . . . . . . . . . . . . . . . . . . . 14 6.2 Informative References . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 A. Multicast Payload Transport Extensions . . . . . . . . . . . . 18 A.1 Reliable Multicast . . . . . . . . . . . . . . . . . . . . 18 A.2 Multicast Group Security . . . . . . . . . . . . . . . . . 18 - Intellectual Property and Copyright Statements . . . . . . . . 20 + Intellectual Property and Copyright Statements . . . . . . . . 19 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 @@ -201,23 +201,23 @@ 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. - As of this writing, it cannot be applied in Inter-domain multicast or - for Embedded-RP. XXX: explain why not, someone send text? (one - paragraph please!). + As of this writing, in IPv6 or inter-domain multicast there is no + standards based mechanism for alerting routers that a group range is + to be used for 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, and to get around initial deployment hurdles, it also included tunneling capabilities which were part of its multicast topology functions. Currently, DVMRP is used only very rarely in operator networks, @@ -288,22 +288,21 @@ However, when PIM -- which by default built multicast topology based on the unicast topology -- gained popularity, it became apparent that it would be necessary to be able to distribute also non-congruent multicast reachability information in the regular unicast protocols. This was previously not an issue, because DVMRP built its own reachability information. The topology information is needed to perform efficient distribution of multicast transmissions and to prevent transmission loops by - applying it to the Reverse Path Forwarding (RPF) check. XXX: does - the use of RPF need to be expanded? + applying it to the Reverse Path Forwarding (RPF) check. This subsection introduces these protocols. 2.2.1 Multi-protocol BGP Multiprotocol Extensions for BGP-4 [RFC2858] (often referred to as "MBGP"; however, it is worth noting that "MBGP" does *not* stand for "Multicast BGP") specifies a mechanism by which BGP can be used to distribute different reachability information for unicast and multicast traffic (using SAFI=2 for multicast). Multiprotocol BGP @@ -363,26 +362,25 @@ 2.3 Learning (Active) Sources Typically, multicast routing protocols must either assume that the receivers know the IP addresses of the (active) sources for a group a priori, possibly using an out-of-band mechanism (SSM), or the sources must be discovered by the network protocols automatically (ASM). 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 Internetis a completely unscalable model - for many reasons (XXX: a reference would be nice). 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. + 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. This section discusses the options. 2.3.1 SSM Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also referred to as "single-source Multicast") does not count on learning active sources in the network; it is assumed that the recipients know these using out of band mechanisms, and when subscribing to an (S,G) channel indicate toward which source(s) the multicast routing @@ -519,26 +517,24 @@ Section 2.4.3) to select another RP when the active one failed. However, the same functionality could be achieved using a shared- unicast RP address ("anycast RP without state sharing") without the complexity of a dynamic mechanism. Further, Anycast RP offers a significantly more extensive failure mitigation strategy, so today there is actually very little need to use stateless failover mechanisms, especially dynamic ones, for redundancy purposes. 2.5.3 Bi-directional PIM - Bi-directional PIM (see Section 2.1.3) was designed with faster - multicast convergence in mind, and if fast failover is required, it - may seem like an attractive solution. - - XXX: someone want to send a bit more text about the convergence - differences wrt PIM-SM? + Bi-directional PIM (see Section 2.1.3) uses less state than PIM-SM, + implying a better total convergence. On the other hand, PIM-SM or + SSM may be faster especially in scenarios where bi-directional needs + to re-do the Designated Forwarder election. 2.6 Interactions with Hosts Previous sections have dealt with the components required by routers to be able to do multicast routing. Obviously, the real users of multicast are the hosts: either sending or receiving multicast. This section describes the required interactions with hosts. 2.6.1 Hosts Sending Multicast @@ -606,22 +602,22 @@ 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, and Tom Pusateri provided good comments, helping in - improving this document. + Stig Venaas, Tom Pusateri, Marshall Eubanks, and Dino Farinacci + 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. @@ -640,22 +636,22 @@ 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-09 (work in - progress), March 2005. + IS-IS", draft-ietf-isis-wg-multi-topology-10 (work in + progress), May 2005. [I-D.ietf-ospf-mt] Psenak, P., "Multi-Topology (MT) Routing in OSPF", draft-ietf-ospf-mt-04 (work in progress), April 2005. [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. @@ -713,21 +709,21 @@ July 2004. [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-05 (work in progress), April 2005. + 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