draft-ietf-mboned-routingarch-00.txt   draft-ietf-mboned-routingarch-01.txt 
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Obsoletes: April 25, 2005 Obsoletes: July 11, 2005
3913,2189,2201,1584,1585 (if 3913,2189,2201,1584,1585 (if
approved) approved)
Expires: October 27, 2005 Expires: January 12, 2006
Overview of the Internet Multicast Routing Architecture Overview of the Internet Multicast Routing Architecture
draft-ietf-mboned-routingarch-00.txt draft-ietf-mboned-routingarch-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The lack of up-to-date documentation on IP multicast routing The lack of up-to-date documentation on IP multicast routing
protocols and procedures has caused a great deal of confusion. To protocols and procedures has caused a great deal of confusion. To
clarify the situation, this memo describes the routing protocols and clarify the situation, this memo describes the routing protocols and
skipping to change at page 2, line 51 skipping to change at page 2, line 51
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1 Normative References . . . . . . . . . . . . . . . . . . . 14 6.1 Normative References . . . . . . . . . . . . . . . . . . . 14
6.2 Informative References . . . . . . . . . . . . . . . . . . 15 6.2 Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
A. Multicast Payload Transport Extensions . . . . . . . . . . . . 18 A. Multicast Payload Transport Extensions . . . . . . . . . . . . 18
A.1 Reliable Multicast . . . . . . . . . . . . . . . . . . . . 18 A.1 Reliable Multicast . . . . . . . . . . . . . . . . . . . . 18
A.2 Multicast Group Security . . . . . . . . . . . . . . . . . 18 A.2 Multicast Group Security . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 19
1. Introduction 1. Introduction
Good, up-to-date documentation of IP multicast is close to non- Good, up-to-date documentation of IP multicast is close to non-
existent. This issue is severely felt with multicast routing existent. This issue is severely felt with multicast routing
protocols and techniques. The consequence is that those who wish to 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 learn of IP multicast and how the routing works in the real world do
not know where to begin. not know where to begin.
The aim of this document is to provide a brief overview of multicast The aim of this document is to provide a brief overview of multicast
skipping to change at page 5, line 31 skipping to change at page 5, line 31
only. Lately, many networks have been transitioned away from sparse- only. Lately, many networks have been transitioned away from sparse-
dense to only sparse mode. dense to only sparse mode.
2.1.3 Bi-directional PIM 2.1.3 Bi-directional PIM
Bi-directional PIM [I-D.ietf-pim-bidir] aims to offer streamlined Bi-directional PIM [I-D.ietf-pim-bidir] aims to offer streamlined
PIM-SM operation, without data-driven events and data-encapsulation, 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 inside a PIM-SM domain. The usage of bi-dir PIM may be on the
increase especially inside sites leveraging multicast. increase especially inside sites leveraging multicast.
As of this writing, it cannot be applied in Inter-domain multicast or As of this writing, in IPv6 or inter-domain multicast there is no
for Embedded-RP. XXX: explain why not, someone send text? (one standards based mechanism for alerting routers that a group range is
paragraph please!). to be used for bi-directional PIM.
2.1.4 DVMRP 2.1.4 DVMRP
Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075]
[I-D.ietf-idmr-dvmrp-v3] [I-D.ietf-idmr-dvmrp-v3-as] was the first [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 protocol designed for multicasting, and to get around initial
deployment hurdles, it also included tunneling capabilities which deployment hurdles, it also included tunneling capabilities which
were part of its multicast topology functions. were part of its multicast topology functions.
Currently, DVMRP is used only very rarely in operator networks, Currently, DVMRP is used only very rarely in operator networks,
skipping to change at page 7, line 24 skipping to change at page 7, line 24
However, when PIM -- which by default built multicast topology based However, when PIM -- which by default built multicast topology based
on the unicast topology -- gained popularity, it became apparent that on the unicast topology -- gained popularity, it became apparent that
it would be necessary to be able to distribute also non-congruent it would be necessary to be able to distribute also non-congruent
multicast reachability information in the regular unicast protocols. multicast reachability information in the regular unicast protocols.
This was previously not an issue, because DVMRP built its own This was previously not an issue, because DVMRP built its own
reachability information. reachability information.
The topology information is needed to perform efficient distribution The topology information is needed to perform efficient distribution
of multicast transmissions and to prevent transmission loops by of multicast transmissions and to prevent transmission loops by
applying it to the Reverse Path Forwarding (RPF) check. XXX: does applying it to the Reverse Path Forwarding (RPF) check.
the use of RPF need to be expanded?
This subsection introduces these protocols. This subsection introduces these protocols.
2.2.1 Multi-protocol BGP 2.2.1 Multi-protocol BGP
Multiprotocol Extensions for BGP-4 [RFC2858] (often referred to as Multiprotocol Extensions for BGP-4 [RFC2858] (often referred to as
"MBGP"; however, it is worth noting that "MBGP" does *not* stand for "MBGP"; however, it is worth noting that "MBGP" does *not* stand for
"Multicast BGP") specifies a mechanism by which BGP can be used to "Multicast BGP") specifies a mechanism by which BGP can be used to
distribute different reachability information for unicast and distribute different reachability information for unicast and
multicast traffic (using SAFI=2 for multicast). Multiprotocol BGP multicast traffic (using SAFI=2 for multicast). Multiprotocol BGP
skipping to change at page 8, line 51 skipping to change at page 8, line 50
2.3 Learning (Active) Sources 2.3 Learning (Active) Sources
Typically, multicast routing protocols must either assume that the Typically, multicast routing protocols must either assume that the
receivers know the IP addresses of the (active) sources for a group a 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 priori, possibly using an out-of-band mechanism (SSM), or the sources
must be discovered by the network protocols automatically (ASM). must be discovered by the network protocols automatically (ASM).
Learning active sources is a relatively straightforward process with Learning active sources is a relatively straightforward process with
a single PIM-SM domain and with a single RP, but having a single 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 PIM-SM domain for the whole Internet is a completely unscalable
for many reasons (XXX: a reference would be nice). Therefore it is model for many reasons. Therefore it is required to be able to split
required to be able to split up the multicast routing infrastructures up the multicast routing infrastructures to smaller domains, and
to smaller domains, and there must be a way to share information there must be a way to share information about active sources using
about active sources using some mechanism if the ASM model is to be some mechanism if the ASM model is to be supported.
supported.
This section discusses the options. This section discusses the options.
2.3.1 SSM 2.3.1 SSM
Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also Source-specific Multicast [I-D.ietf-ssm-arch] (sometimes also
referred to as "single-source Multicast") does not count on learning referred to as "single-source Multicast") does not count on learning
active sources in the network; it is assumed that the recipients know 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) these using out of band mechanisms, and when subscribing to an (S,G)
channel indicate toward which source(s) the multicast routing channel indicate toward which source(s) the multicast routing
skipping to change at page 12, line 15 skipping to change at page 12, line 15
Section 2.4.3) to select another RP when the active one failed. Section 2.4.3) to select another RP when the active one failed.
However, the same functionality could be achieved using a shared- However, the same functionality could be achieved using a shared-
unicast RP address ("anycast RP without state sharing") without the unicast RP address ("anycast RP without state sharing") without the
complexity of a dynamic mechanism. Further, Anycast RP offers a complexity of a dynamic mechanism. Further, Anycast RP offers a
significantly more extensive failure mitigation strategy, so today significantly more extensive failure mitigation strategy, so today
there is actually very little need to use stateless failover there is actually very little need to use stateless failover
mechanisms, especially dynamic ones, for redundancy purposes. mechanisms, especially dynamic ones, for redundancy purposes.
2.5.3 Bi-directional PIM 2.5.3 Bi-directional PIM
Bi-directional PIM (see Section 2.1.3) was designed with faster Bi-directional PIM (see Section 2.1.3) uses less state than PIM-SM,
multicast convergence in mind, and if fast failover is required, it implying a better total convergence. On the other hand, PIM-SM or
may seem like an attractive solution. SSM may be faster especially in scenarios where bi-directional needs
to re-do the Designated Forwarder election.
XXX: someone want to send a bit more text about the convergence
differences wrt PIM-SM?
2.6 Interactions with Hosts 2.6 Interactions with Hosts
Previous sections have dealt with the components required by routers Previous sections have dealt with the components required by routers
to be able to do multicast routing. Obviously, the real users of to be able to do multicast routing. Obviously, the real users of
multicast are the hosts: either sending or receiving multicast. This multicast are the hosts: either sending or receiving multicast. This
section describes the required interactions with hosts. section describes the required interactions with hosts.
2.6.1 Hosts Sending Multicast 2.6.1 Hosts Sending Multicast
skipping to change at page 14, line 6 skipping to change at page 13, line 52
used with IGMP snooping. used with IGMP snooping.
3. Acknowledgements 3. Acknowledgements
Tutoring a couple multicast-related papers, the latest by Kaarle Tutoring a couple multicast-related papers, the latest by Kaarle
Ritvanen [RITVANEN] convinced the author that the up-to-date Ritvanen [RITVANEN] convinced the author that the up-to-date
multicast routing and address assignment/allocation documentation is multicast routing and address assignment/allocation documentation is
necessary. necessary.
Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer,
Stig Venaas, and Tom Pusateri provided good comments, helping in Stig Venaas, Tom Pusateri, Marshall Eubanks, and Dino Farinacci
improving this document. provided good comments, helping in improving this document.
4. IANA Considerations 4. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
5. Security Considerations 5. Security Considerations
This memo only describes different approaches to multicast routing, This memo only describes different approaches to multicast routing,
and this has no security considerations; the security analysis of the and this has no security considerations; the security analysis of the
mentioned protocols is out of scope of this memo. mentioned protocols is out of scope of this memo.
skipping to change at page 14, line 40 skipping to change at page 14, line 37
Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress), Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress),
December 2003. December 2003.
[I-D.ietf-idmr-dvmrp-v3-as] [I-D.ietf-idmr-dvmrp-v3-as]
Pusateri, T., "Distance Vector Multicast Routing Protocol Pusateri, T., "Distance Vector Multicast Routing Protocol
Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01 Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01
(work in progress), May 2004. (work in progress), May 2004.
[I-D.ietf-isis-wg-multi-topology] [I-D.ietf-isis-wg-multi-topology]
Przygienda, T., "M-ISIS: Multi Topology (MT)Routing in Przygienda, T., "M-ISIS: Multi Topology (MT)Routing in
IS-IS", draft-ietf-isis-wg-multi-topology-09 (work in IS-IS", draft-ietf-isis-wg-multi-topology-10 (work in
progress), March 2005. progress), May 2005.
[I-D.ietf-ospf-mt] [I-D.ietf-ospf-mt]
Psenak, P., "Multi-Topology (MT) Routing in OSPF", Psenak, P., "Multi-Topology (MT) Routing in OSPF",
draft-ietf-ospf-mt-04 (work in progress), April 2005. draft-ietf-ospf-mt-04 (work in progress), April 2005.
[I-D.ietf-pim-bidir] [I-D.ietf-pim-bidir]
Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bi-directional Protocol Independent Multicast (BIDIR- "Bi-directional Protocol Independent Multicast (BIDIR-
PIM)", draft-ietf-pim-bidir-07 (work in progress), PIM)", draft-ietf-pim-bidir-07 (work in progress),
March 2005. March 2005.
skipping to change at page 16, line 16 skipping to change at page 16, line 14
July 2004. July 2004.
[I-D.ietf-magma-igmp-proxy] [I-D.ietf-magma-igmp-proxy]
Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/ Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/
MLD-based Multicast Forwarding ('IGMP/MLD Proxying')", MLD-based Multicast Forwarding ('IGMP/MLD Proxying')",
draft-ietf-magma-igmp-proxy-06 (work in progress), draft-ietf-magma-igmp-proxy-06 (work in progress),
April 2004. April 2004.
[I-D.ietf-magma-mrdisc] [I-D.ietf-magma-mrdisc]
Haberman, B. and J. Martin, "Multicast Router Discovery", 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] [I-D.ietf-magma-snoop]
Christensen, M., Kimball, K., and F. Solensky, Christensen, M., Kimball, K., and F. Solensky,
"Considerations for IGMP and MLD Snooping Switches", "Considerations for IGMP and MLD Snooping Switches",
draft-ietf-magma-snoop-12 (work in progress), draft-ietf-magma-snoop-12 (work in progress),
February 2005. February 2005.
[I-D.ietf-mboned-ipv6-multicast-issues] [I-D.ietf-mboned-ipv6-multicast-issues]
Savola, P., "IPv6 Multicast Deployment Issues", Savola, P., "IPv6 Multicast Deployment Issues",
draft-ietf-mboned-ipv6-multicast-issues-02 (work in draft-ietf-mboned-ipv6-multicast-issues-02 (work in
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/