draft-ietf-mboned-routingarch-01.txt   draft-ietf-mboned-routingarch-02.txt 
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Obsoletes: July 11, 2005 Obsoletes: October 12, 2005
3913,2189,2201,1584,1585 (if 3913,2189,2201,1584,1585 (if
approved) approved)
Expires: January 12, 2006 Expires: April 15, 2006
Overview of the Internet Multicast Routing Architecture Overview of the Internet Multicast Routing Architecture
draft-ietf-mboned-routingarch-01.txt draft-ietf-mboned-routingarch-02.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 January 12, 2006. This Internet-Draft will expire on April 15, 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
techniques currently (as of this writing) in use. techniques currently (as of this writing) in use.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Multicast-related Abbreviations . . . . . . . . . . . . . 4 1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 4
2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 4 2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Setting up Multicast Forwarding State . . . . . . . . . . 4 2.1. Setting up Multicast Forwarding State . . . . . . . . . . 4
2.1.1 PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.3 Bi-directional PIM . . . . . . . . . . . . . . . . . . 5 2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 5
2.1.4 DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.5 MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.6 BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.7 CBT . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.8 Interactions and Summary . . . . . . . . . . . . . . . 6 2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 6
2.2 Distributing Topology Information . . . . . . . . . . . . 7 2.2. Distributing Topology Information . . . . . . . . . . . . 7
2.2.1 Multi-protocol BGP . . . . . . . . . . . . . . . . . . 7 2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 7
2.2.2 OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 7 2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 7
2.2.3 Issue: Overlapping Unicast/multicast Topology . . . . 8 2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 8
2.3 Learning (Active) Sources . . . . . . . . . . . . . . . . 8 2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 8
2.3.1 SSM . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Embedded-RP . . . . . . . . . . . . . . . . . . . . . 9 2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 9
2.4 Configuring and Distributing PIM-SM RP Information . . . . 10 2.4. Configuring and Distributing PIM-SM RP Information . . . . 10
2.4.1 Manual Configuration with an Anycast Address . . . . . 10 2.4.1. Manual Configuration with an Anycast Address . . . . . 10
2.4.2 Embedded-RP . . . . . . . . . . . . . . . . . . . . . 10 2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 10
2.4.3 BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 11 2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 11
2.5 Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 11 2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 11
2.5.1 Anycast RP . . . . . . . . . . . . . . . . . . . . . . 11 2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 11
2.5.2 Stateless RP Failover . . . . . . . . . . . . . . . . 11 2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 11
2.5.3 Bi-directional PIM . . . . . . . . . . . . . . . . . . 12 2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 12
2.6 Interactions with Hosts . . . . . . . . . . . . . . . . . 12 2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 12
2.6.1 Hosts Sending Multicast . . . . . . . . . . . . . . . 12 2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 12
2.6.2 Hosts Receiving Multicast . . . . . . . . . . . . . . 12 2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 12
2.7 Restricting Multicast Flooding in the Link Layer . . . . . 12 2.7. Restricting Multicast Flooding in the Link Layer . . . . . 12
2.7.1 Router-to-Router Flooding Reduction . . . . . . . . . 13 2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 13
2.7.2 Host/Router Flooding Reduction . . . . . . . . . . . . 13 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 13
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 Appendix 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 19 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 4, line 5 skipping to change at page 4, line 5
This memo obsoletes and re-classifies to Historic [RFC2026] Border This memo obsoletes and re-classifies to Historic [RFC2026] Border
Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast
OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and
[RFC1585]. The purpose of the re-classification is to give the [RFC1585]. The purpose of the re-classification is to give the
readers (both implementors and deployers) an idea what the status of readers (both implementors and deployers) an idea what the status of
a protocol is; there may or may not be legacy deployments of these a protocol is; there may or may not be legacy deployments of these
protocols, which are not affected by this reclassification. See protocols, which are not affected by this reclassification. See
Section 2.1 for more on each protocol. Section 2.1 for more on each protocol.
1.1 Multicast-related Abbreviations 1.1. Multicast-related Abbreviations
ASM Any Source Multicast ASM Any Source Multicast
BGMP Border Gateway Multicast Protocol BGMP Border Gateway Multicast Protocol
BSR Bootstrap Router BSR Bootstrap Router
CBT Core Based Trees CBT Core Based Trees
CGMP Cisco Group Management Protocol CGMP Cisco Group Management Protocol
DR Designated Router DR Designated Router
DVMRP Distance Vector Multicast Routing Protocol DVMRP Distance Vector Multicast Routing Protocol
GARP Group Address Resolution Protocol GARP Group Address Resolution Protocol
IGMP Internet Group Management Protocol IGMP Internet Group Management Protocol
skipping to change at page 4, line 32 skipping to change at page 4, line 32
PIM Protocol Independent Multicast PIM Protocol Independent Multicast
PIM-DM PIM - Dense Mode PIM-DM PIM - Dense Mode
PIM-SM PIM - Sparse Mode PIM-SM PIM - Sparse Mode
PIM-SSM PIM - (Source-specific) Sparse Mode PIM-SSM PIM - (Source-specific) Sparse Mode
RGMP (Cisco's) Router Group Management Protocol RGMP (Cisco's) Router Group Management Protocol
RP Rendezvous Point RP Rendezvous Point
SSM Source-specific Multicast SSM Source-specific Multicast
2. Multicast Routing 2. Multicast Routing
2.1 Setting up Multicast Forwarding State 2.1. Setting up Multicast Forwarding State
The most important part of multicast routing is setting up the The most important part of multicast routing is setting up the
multicast forwarding state. This section describes the protocols multicast forwarding state. This section describes the protocols
commonly used for this purpose. commonly used for this purpose.
2.1.1 PIM-SM 2.1.1. PIM-SM
By far, the most common multicast routing protocol is PIM-SM 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 [I-D.ietf-pim-sm-v2-new]. The PIM-SM protocol includes both Any
Source Multicast (ASM) and Source-Specific Multicast (SSM) Source Multicast (ASM) and Source-Specific Multicast (SSM)
functionality; PIM-SSM is a subset of PIM-SM. Most current routing functionality; PIM-SSM is a subset of PIM-SM. Most current routing
platforms support PIM-SM. platforms support PIM-SM.
2.1.2 PIM-DM 2.1.2. PIM-DM
Whereas PIM-SM is designed to avoid unnecessary flooding of multicast 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, data, PIM-DM [I-D.ietf-pim-dm-new-v2] operates in a "dense" mode,
flooding the multicast transmissions throughout the network ("flood flooding the multicast transmissions throughout the network ("flood
and prune") unless the leaf parts of the network periodically and prune") unless the leaf parts of the network periodically
indicate that they are not interested in that particular traffic. indicate that they are not interested in that particular traffic.
PIM-DM may be some fit in small and/or simple networks, where setting 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 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 number of users is expected to be able to wish to receive the
skipping to change at page 5, line 24 skipping to change at page 5, line 24
potential for loops, and the over-reliance of the complex Assert potential for loops, and the over-reliance of the complex Assert
mechanism. Further, it was a non-starter with high-bandwidth mechanism. Further, it was a non-starter with high-bandwidth
streams. streams.
Many implementations also support so-called "sparse-dense" mode, 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 is used by default, but Dense is used for
configured multicast group ranges (such as Auto-RP in Section 2.4.3) configured multicast group ranges (such as Auto-RP in Section 2.4.3)
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, in IPv6 or inter-domain multicast there is no As of this writing, in IPv6 or inter-domain multicast there is no
standards based mechanism for alerting routers that a group range is standards based mechanism for alerting routers that a group range is
to be used for bi-directional PIM. 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,
having been replaced with PIM-SM. The most typical deployment of having been replaced with PIM-SM. The most typical deployment of
DVMRP is at a leaf network, to run from a legacy firewall only DVMRP is at a leaf network, to run from a legacy firewall only
supporting DVMRP to the internal network. However, GRE tunneling supporting DVMRP to the internal network. However, GRE tunneling
[RFC2784] seems to have overtaken DVMRP in this functionality, and [RFC2784] seems to have overtaken DVMRP in this functionality, and
there is relatively little use for DVMRP except in legacy there is relatively little use for DVMRP except in legacy
deployments. deployments.
2.1.5 MOSPF 2.1.5. MOSPF
MOSPF [RFC1584] was implemented by several vendors and has seen some MOSPF [RFC1584] was implemented by several vendors and has seen some
deployment in intra-domain networks. However, since it does not deployment in intra-domain networks. However, since it does not
scale to the inter-domain case, operators have found it is easier to scale to the inter-domain case, operators have found it is easier to
deploy a single protocol for use in both intra-domain and inter- deploy a single protocol for use in both intra-domain and inter-
domain networks and so it is no longer being actively deployed. domain networks and so it is no longer being actively deployed.
2.1.6 BGMP 2.1.6. BGMP
BGMP [RFC3913] did not get sufficient support within the service BGMP [RFC3913] did not get sufficient support within the service
provider community to get adopted and moved forward in the IETF provider community to get adopted and moved forward in the IETF
standards process. There were no reported production implementations standards process. There were no reported production implementations
and no production deployments. and no production deployments.
2.1.7 CBT 2.1.7. CBT
CBT [RFC2201] was was an academic project that provided the basis for CBT [RFC2201] was was an academic project that provided the basis for
PIM sparse mode shared trees. Once the shared tree functionality was PIM sparse mode shared trees. Once the shared tree functionality was
incorporated into PIM implementations, there was no longer a need for incorporated into PIM implementations, there was no longer a need for
a production CBT implemention. Therefore, CBT never saw production a production CBT implemention. Therefore, CBT never saw production
deployment. deployment.
2.1.8 Interactions and Summary 2.1.8. Interactions and Summary
It is worth noting that is it is possible to run different protocols 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 with different groups ranges (e.g., treat some groups as dense mode
in an other-wise PIM-SM network; this typically requires manual in an other-wise PIM-SM network; this typically requires manual
configuration of the groups) or interact between different protocols configuration of the groups) or interact between different protocols
(e.g., use DVMRP in the leaf network, but PIM-SM upstream). The (e.g., use DVMRP in the leaf network, but PIM-SM upstream). The
basics for interactions among different protocols have been outlined basics for interactions among different protocols have been outlined
in [RFC2715]. in [RFC2715].
The following figure gives a concise summary of the deployment status The following figure gives a concise summary of the deployment status
skipping to change at page 7, line 8 skipping to change at page 7, line 8
| Bi-dir PIM | No | Yes | Wait & see | | Bi-dir PIM | No | Yes | Wait & see |
| DVMRP | Not anymore | Stub only | Going out | | DVMRP | Not anymore | Stub only | Going out |
| MOSF | No | Not anymore | Inactive | | MOSF | No | Not anymore | Inactive |
| CBT | No | No | Never deployed | | CBT | No | No | Never deployed |
| BGMP | No | No | Never deployed | | BGMP | No | No | Never deployed |
+------------+-------------+-------------+----------------+ +------------+-------------+-------------+----------------+
From this table, it is clear that PIM-Sparse Mode is the only From this table, it is clear that PIM-Sparse Mode is the only
multicast routing protocol that is deployed inter-domain and, multicast routing protocol that is deployed inter-domain and,
therefore, is most frequently used within multicast domains as well. therefore, is most frequently used within multicast domains as well.
2.2 Distributing Topology Information 2.2. Distributing Topology Information
When unicast and multicast topologies are the same ("congruent"), When unicast and multicast topologies are the same ("congruent"),
i.e., use the same routing tables (routing information base, RIB), it i.e., use the same routing tables (routing information base, RIB), it
has been considered sufficient just to distribute one set of has been considered sufficient just to distribute one set of
reachability information. reachability information.
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. applying it to the Reverse Path Forwarding (RPF) check.
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
has been widely deployed for years, and is also needed to route IPv6. has been widely deployed for years, and is also needed to route IPv6.
Note that SAFI=3 was originally specified for "both unicast and
multicast" but has been deprecated [I-D.ietf-idr-rfc2858bis].
These extensions are in widespread use wherever BGP is used to These extensions are in widespread use wherever BGP is used to
distribute unicast topology information. Those having multicast distribute unicast topology information. Those having multicast
infrastructure and using BGP should use Multiprotocol BGP to infrastructure and using BGP should use Multiprotocol BGP to
distribute multicast reachability information explicitly even if the distribute multicast reachability information explicitly even if the
topologies are congruent (using SAFI=3). A number of significant topologies are congruent. A number of significant multicast transit
multicast transit providers even require this, by doing the RPF providers even require this, by doing the RPF lookups solely based on
lookups solely based on explicitly advertised multicast address explicitly advertised multicast address family.
family.
2.2.2 OSPF/IS-IS Multi-topology Extensions 2.2.2. OSPF/IS-IS Multi-topology Extensions
Similar to BGP, some IGPs also provide the capability for signalling Similar to BGP, some IGPs also provide the capability for signalling
a differing multicast topology, for example IS-IS multi-topology a differing multicast topology, for example IS-IS multi-topology
extensions [I-D.ietf-isis-wg-multi-topology]. Similar work exists extensions [I-D.ietf-isis-wg-multi-topology]. Similar work exists
for OSPF [I-D.ietf-ospf-mt]. for OSPF [I-D.ietf-ospf-mt].
It is worth noting that interdomain incongruence and intradomain It is worth noting that interdomain incongruence and intradomain
incongruence are orthogonal, so one doesn't require the other. incongruence are orthogonal, so one doesn't require the other.
Specifically, interdomain incongruence is quite common, while Specifically, interdomain incongruence is quite common, while
intradomain incongruence isn't, so you see much more deployments of intradomain incongruence isn't, so you see much more deployments of
MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well
without protocols handling intradomain incongruence. However, the without protocols handling intradomain incongruence. However, the
availability of multi-topology mechanisms may in part replace the availability of multi-topology mechanisms may in part replace the
typically used workarounds such as tunnels. typically used workarounds such as tunnels.
2.2.3 Issue: Overlapping Unicast/multicast Topology 2.2.3. Issue: Overlapping Unicast/multicast Topology
An interesting case occurs when some routers do not distribute An interesting case occurs when some routers do not distribute
multicast topology information explicitly while others do. In multicast topology information explicitly while others do. In
particular, this happens when some multicast sites in the Internet particular, this happens when some multicast sites in the Internet
are using plain BGP while some use MBGP. are using plain BGP while some use MBGP.
Different implementations deal with this using different means. Different implementations deal with this using different means.
Sometimes, multicast RPF mechanisms first look up the multicast Sometimes, multicast RPF mechanisms first look up the multicast
routing table, or RIB ("topology database") with a longest prefix routing table, or RIB ("topology database") with a longest prefix
match algorithm, and if they find any entry (including a default match algorithm, and if they find any entry (including a default
skipping to change at page 8, line 41 skipping to change at page 8, line 42
routing table. The important point to remember here, though, is to routing table. The important point to remember here, though, is to
not override the multicast-only routes; if the longest prefix match not override the multicast-only routes; if the longest prefix match
would find both a (copied) unicast route and a multicast-only route, would find both a (copied) unicast route and a multicast-only route,
the latter should be treated as preferable. the latter should be treated as preferable.
One implemented approach is to just look up the information in the One implemented approach is to just look up the information in the
unicast routing table, and provide the user capabilities to change unicast routing table, and provide the user capabilities to change
that as appropriate, using for example copying functions discussed that as appropriate, using for example copying functions discussed
above. above.
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 Internet is a completely unscalable PIM-SM domain for the whole Internet is a completely unscalable model
model for many reasons. Therefore it is required to be able to split for many reasons. Therefore it is required to be able to split up
up the multicast routing infrastructures to smaller domains, and the multicast routing infrastructures to smaller domains, and there
there must be a way to share information about active sources using must be a way to share information about active sources using some
some mechanism if the ASM model is to be supported. mechanism if the ASM model is to be 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
protocol should send the Join messages. protocol should send the Join messages.
As of this writing, there are attempts to analyze and/or define out- As of this writing, there are attempts to analyze and/or define out-
of-band source discovery functions which would help SSM in particular of-band source discovery functions which would help SSM in particular
[I-D.lehtonen-mboned-dynssm-req]. [I-D.lehtonen-mboned-dynssm-req].
2.3.2 MSDP 2.3.2. MSDP
Multicast Source Discovery Mechanism [RFC3618] was invented as a Multicast Source Discovery Mechanism [RFC3618] was invented as a
stop-gap mechanism, when it became apparent that multiple PIM-SM stop-gap mechanism, when it became apparent that multiple PIM-SM
domains (and RPs) were needed in the network, and information about domains (and RPs) were needed in the network, and information about
the active sources needed to be propagated between the PIM-SM domains the active sources needed to be propagated between the PIM-SM domains
using some other protocol. using some other protocol.
MSDP is also used to share the state about sources between multiple MSDP is also used to share the state about sources between multiple
RPs in a single domain for, e.g., redundancy purposes [RFC3446]. RPs in a single domain for, e.g., redundancy purposes [RFC3446].
There is also work in progress to achieve the same using PIM 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. 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 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]. and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues].
2.3.3 Embedded-RP 2.3.3. Embedded-RP
Embedded-RP [RFC3956] is an IPv6-only technique to map the address of Embedded-RP [RFC3956] is an IPv6-only technique to map the address of
the RP to the multicast group address. Using this method, it is the RP to the multicast group address. Using this method, it is
possible to avoid the use of MSDP while still allowing multiple possible to avoid the use of MSDP while still allowing multiple
multicast domains (in the traditional sense). multicast domains (in the traditional sense).
The model works by defining a single RP for a particular group for The model works by defining a single RP for a particular group for
all of the Internet, so there is no need to share state about that all of the Internet, so there is no need to share state about that
with any other RPs (except, possibly, for redundancy purposes with with any other RPs (except, possibly, for redundancy purposes with
Anycast-RP using PIM). Anycast-RP using PIM).
2.4 Configuring and Distributing PIM-SM RP Information 2.4. Configuring and Distributing PIM-SM RP Information
For PIM-SM, configuration mechanisms exist which are used to For PIM-SM, configuration mechanisms exist which are used to
configure the RP addresses and which groups are to use those RPs in configure the RP addresses and which groups are to use those RPs in
the routers. This section outlines the approaches. the routers. This section outlines the approaches.
2.4.1 Manual Configuration with an Anycast Address 2.4.1. Manual Configuration with an Anycast Address
It is often easiest just to manually configure the RP information on It is often easiest just to manually configure the RP information on
the routers when PIM-SM is used. the routers when PIM-SM is used.
Originally, static RP mapping was considered suboptimal since it Originally, static RP mapping was considered suboptimal since it
required explicit configuration chages every time the RP address required explicit configuration chages every time the RP address
changed. However, with the advent of anycast RP addressing, the RP changed. However, with the advent of anycast RP addressing, the RP
address is unlikely to ever change. Therefore, the administrative address is unlikely to ever change. Therefore, the administrative
burden is generally limited to initial configuration. Since there is burden is generally limited to initial configuration. Since there is
usually a fair amount of multicast configuration required on all usually a fair amount of multicast configuration required on all
skipping to change at page 10, line 35 skipping to change at page 10, line 35
Section 2.5) without the complexity found in dynamic mechanisms like Section 2.5) without the complexity found in dynamic mechanisms like
Auto-RP and Bootstrap Router (BSR). Auto-RP and Bootstrap Router (BSR).
With such design, an anycast RP uses a "portable" address, which is With such design, an anycast RP uses a "portable" address, which is
configured on a loopback interfaces of the routers currently acting configured on a loopback interfaces of the routers currently acting
as RPs, as described in [RFC3446]. as RPs, as described in [RFC3446].
Using this technique, each router might only need to be configured Using this technique, each router might only need to be configured
with one, portable RP address. with one, portable RP address.
2.4.2 Embedded-RP 2.4.2. Embedded-RP
Embedded-RP provides the information about the RP's address in the Embedded-RP provides the information about the RP's address in the
group addresses which are delegated to those who use the RP, so group addresses which are delegated to those who use the RP, so
unless no other ASM than Embedded-RP is used, one only needs to unless no other ASM than Embedded-RP is used, one only needs to
configure the RP routers themselves. configure the RP routers themselves.
While Embedded-RP in many cases is sufficient for IPv6, other methods While Embedded-RP in many cases is sufficient for IPv6, other methods
of RP configuration are needed if one needs to provide ASM service of RP configuration are needed if one needs to provide ASM service
for other than Embedded-RP group addresses. In particular, service for other than Embedded-RP group addresses. In particular, service
discovery type of applications may need hard-coded addresses that are discovery type of applications may need hard-coded addresses that are
not dependent on local RP addresses. not dependent on local RP addresses.
As the RP's address is exposed to the users and applications, it is As the RP's address is exposed to the users and applications, it is
very important to ensure it does not change often, e.g., by using very important to ensure it does not change often, e.g., by using
manual configuration of an anycast address. manual configuration of an anycast address.
2.4.3 BSR and Auto-RP 2.4.3. BSR and Auto-RP
BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP
address for groups. It may no longer be in as wide use with IPv4 as address for groups. It may no longer be in as wide use with IPv4 as
it was ealier, and for IPv6, Embedded-RP will in many cases be it was ealier, and for IPv6, Embedded-RP will in many cases be
sufficient. sufficient.
Cisco's Auto-RP is an older, proprietary method for distributing Cisco's Auto-RP is an older, proprietary method for distributing
group to RP mappings, similar to BSR. Auto-RP has little use today. group to RP mappings, similar to BSR. Auto-RP has little use today.
Both Auto-RP and BSR require some form of control at the routers to Both Auto-RP and BSR require some form of control at the routers to
skipping to change at page 11, line 30 skipping to change at page 11, line 30
using, for example if a router (maybe in customer's control) is using, for example if a router (maybe in customer's control) is
advertising itself inappropriately. All in all, while BSR and advertising itself inappropriately. All in all, while BSR and
Auto-RP provide easy configuration, they also provide very Auto-RP provide easy configuration, they also provide very
significant configuration and management complexity. significant configuration and management complexity.
It is worth noting that both Auto-RP and BSR were deployed before the It is worth noting that both Auto-RP and BSR were deployed before the
use of a manually configured anycast-RP address became relatively use of a manually configured anycast-RP address became relatively
commonplace, and there is actually relatively little use for them commonplace, and there is actually relatively little use for them
today. today.
2.5 Mechanisms for Enhanced Redundancy 2.5. Mechanisms for Enhanced Redundancy
A couple of mechanisms, already described in this document, have been A couple of mechanisms, already described in this document, have been
used as a means to enhance redundancy, resilience against failures, used as a means to enhance redundancy, resilience against failures,
and to recover from failures quickly. This section summarizes these and to recover from failures quickly. This section summarizes these
techniques explicitly. techniques explicitly.
2.5.1 Anycast RP 2.5.1. Anycast RP
As mentioned in Section 2.3.2, MSDP is also used to share the state As mentioned in Section 2.3.2, MSDP is also used to share the state
about sources between multiple RPs in a single domain for, e.g., about sources between multiple RPs in a single domain for, e.g.,
redundancy purposes [RFC3446]. The purpose of MSDP in this context redundancy purposes [RFC3446]. The purpose of MSDP in this context
is to share the same state information on multiple RPs for the same is to share the same state information on multiple RPs for the same
groups to enhance the robustness of the service. groups to enhance the robustness of the service.
There is also work in progress to achieve the same using PIM There is also work in progress to achieve the same using PIM
extensions [I-D.ietf-pim-anycast-rp]. This is a required method to extensions [I-D.ietf-pim-anycast-rp]. This is a required method to
be able to use Anycast RP with IPv6. be able to use Anycast RP with IPv6.
2.5.2 Stateless RP Failover 2.5.2. Stateless RP Failover
It is also possible to use some mechanisms for smaller amount of It is also possible to use some mechanisms for smaller amount of
redundancy as Anycast RP, without sharing state between the RPs. A redundancy as Anycast RP, without sharing state between the RPs. A
traditional mechanism has been to use Auto-RP or BSR (see traditional mechanism has been to use Auto-RP or BSR (see
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) uses less state than 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 implying a better total convergence. On the other hand, PIM-SM or
SSM may be faster especially in scenarios where bi-directional needs SSM may be faster especially in scenarios where bi-directional needs
to re-do the Designated Forwarder election. to re-do the Designated Forwarder election.
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
Hosts don't need to do any signalling prior to sending multicast to a Hosts don't need to do any signalling prior to sending multicast to a
group; they just send the packets to the link-layer multicast group; they just send the packets to the link-layer multicast
address, and the designated router will receive all the multicast address, and the designated router will receive all the multicast
packets and start forwarding them as appropriate. packets and start forwarding them as appropriate.
2.6.2 Hosts Receiving Multicast 2.6.2. Hosts Receiving Multicast
Hosts signal their interest in receiving a multicast group or channel Hosts signal their interest in receiving a multicast group or channel
by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are
also commonplace, but most new deployments support the latest also commonplace, but most new deployments support the latest
specifications. specifications.
2.7 Restricting Multicast Flooding in the Link Layer 2.7. Restricting Multicast Flooding in the Link Layer
Multicast transmission in the link layer, for example Ethernet, Multicast transmission in the link layer, for example Ethernet,
typically includes some form of flooding the packets through a LAN. typically includes some form of flooding the packets through a LAN.
This causes unnecessary bandwidth usage and discarding unwanted This causes unnecessary bandwidth usage and discarding unwanted
frames on those nodes which did not want to receive the multicast frames on those nodes which did not want to receive the multicast
transmission. transmission.
Therefore a number of techniques have been developed, to be used in Therefore a number of techniques have been developed, to be used in
Ethernet switches between routers, or between routers and hosts, to Ethernet switches between routers, or between routers and hosts, to
limit the flooding. limit the flooding.
These options are discussed in this section. These options are discussed in this section.
2.7.1 Router-to-Router Flooding Reduction 2.7.1. Router-to-Router Flooding Reduction
A proprietary solution, Cisco's RGMP [RFC3488] has been developed to A proprietary solution, Cisco's RGMP [RFC3488] has been developed to
reduce the amount of router-to-router flooding on a LAN. This is reduce the amount of router-to-router flooding on a LAN. This is
typically only considered a problem in some Ethernet-based Internet typically only considered a problem in some Ethernet-based Internet
Exchange points. Exchange points.
There have been proposals to snoop PIM messages [I-D.tsenevir-pim-sm- 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. snoop][I-D.serbest-l2vpn-vpls-mcast] to achieve the same effect.
2.7.2 Host/Router Flooding Reduction 2.7.2. Host/Router Flooding Reduction
There are a number of techniques to help reduce flooding both from a 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). router to hosts, and from a host to the routers (and other hosts).
Cisco's proprietary CGMP [CGMP] provides a solution where the routers Cisco's proprietary CGMP [CGMP] provides a solution where the routers
notify the switches, but also allows the switches to snoop IGMP notify the switches, but also allows the switches to snoop IGMP
packets to enable faster notification of hosts no longer wishing to packets to enable faster notification of hosts no longer wishing to
receive a group. IPv6 is not supported. receive a group. IPv6 is not supported.
IEEE specifications mention Group Address Resolution Protocol (GARP) IEEE specifications mention Group Address Resolution Protocol (GARP)
skipping to change at page 14, line 23 skipping to change at page 14, line 24
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.
However, there has been analysis of the security of multicast routing However, there has been analysis of the security of multicast routing
infrastructures [I-D.ietf-mboned-mroutesec], IGMP/MLD [I-D.daley- infrastructures [I-D.ietf-mboned-mroutesec], IGMP/MLD [I-D.daley-
magma-smld-prob], and PIM last-hop issues [I-D.savola-pim-lasthop- magma-smld-prob], and PIM last-hop issues [I-D.savola-pim-lasthop-
threats]. threats].
6. References 6. References
6.1 Normative References 6.1. Normative References
[I-D.ietf-idmr-dvmrp-v3] [I-D.ietf-idmr-dvmrp-v3]
Pusateri, T., "Distance Vector Multicast Routing Pusateri, T., "Distance Vector Multicast Routing
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.
skipping to change at page 15, line 17 skipping to change at page 15, line 21
[I-D.ietf-pim-sm-v2-new] [I-D.ietf-pim-sm-v2-new]
Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode PIM-SM): "Protocol Independent Multicast - Sparse Mode PIM-SM):
Protocol Specification (Revised)", Protocol Specification (Revised)",
draft-ietf-pim-sm-v2-new-11 (work in progress), draft-ietf-pim-sm-v2-new-11 (work in progress),
October 2004. October 2004.
[I-D.ietf-ssm-arch] [I-D.ietf-ssm-arch]
Holbrook, H. and B. Cain, "Source-Specific Multicast for Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", draft-ietf-ssm-arch-06 (work in progress), IP", draft-ietf-ssm-arch-07 (work in progress),
September 2004. October 2005.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
skipping to change at page 15, line 40 skipping to change at page 15, line 44
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003. Protocol (MSDP)", RFC 3618, October 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004. RFC 3956, November 2004.
6.2 Informative References 6.2. Informative References
[CGMP] "Cisco Group Management Protocol", [CGMP] "Cisco Group Management Protocol",
<http://www.javvin.com/protocolCGMP.html>. <http://www.javvin.com/protocolCGMP.html>.
[GARP] Tobagi, F., Molinero-Fernandez, P., and M. Karam, "Study [GARP] Tobagi, F., Molinero-Fernandez, P., and M. Karam, "Study
of IEEE 802.1p GARP/GMRP Timer Values", 1997. of IEEE 802.1p GARP/GMRP Timer Values", 1997.
[I-D.daley-magma-smld-prob] [I-D.daley-magma-smld-prob]
Daley, G. and G. Kurup, "Trust Models and Security in Daley, G. and G. Kurup, "Trust Models and Security in
Multicast Listener Discovery", Multicast Listener Discovery",
draft-daley-magma-smld-prob-00 (work in progress), draft-daley-magma-smld-prob-00 (work in progress),
July 2004. July 2004.
[I-D.ietf-idr-rfc2858bis]
Bates, T., "Multiprotocol Extensions for BGP-4",
draft-ietf-idr-rfc2858bis-07 (work in progress),
August 2005.
[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-07 (work in progress), May 2005. draft-ietf-magma-mrdisc-07 (work in progress), May 2005.
skipping to change at page 16, line 34 skipping to change at page 16, line 44
draft-ietf-mboned-ipv6-multicast-issues-02 (work in draft-ietf-mboned-ipv6-multicast-issues-02 (work in
progress), February 2005. progress), February 2005.
[I-D.ietf-mboned-mroutesec] [I-D.ietf-mboned-mroutesec]
Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast
Routing Security Issues and Enhancements", Routing Security Issues and Enhancements",
draft-ietf-mboned-mroutesec-04 (work in progress), draft-ietf-mboned-mroutesec-04 (work in progress),
October 2004. October 2004.
[I-D.ietf-pim-anycast-rp] [I-D.ietf-pim-anycast-rp]
Farinacci, D., "Anycast-RP using PIM", Farinacci, D. and Y. Cai, "Anycast-RP using PIM",
draft-ietf-pim-anycast-rp-03 (work in progress), draft-ietf-pim-anycast-rp-04 (work in progress),
April 2005. August 2005.
[I-D.ietf-pim-sm-bsr] [I-D.ietf-pim-sm-bsr]
Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM",
draft-ietf-pim-sm-bsr-05 (work in progress), draft-ietf-pim-sm-bsr-05 (work in progress),
February 2005. February 2005.
[I-D.lehtonen-mboned-dynssm-req] [I-D.lehtonen-mboned-dynssm-req]
Lehtonen, R., "Requirements for discovery of dynamic SSM Lehtonen, R., "Requirements for discovery of dynamic SSM
sources", draft-lehtonen-mboned-dynssm-req-00 (work in sources", draft-lehtonen-mboned-dynssm-req-00 (work in
progress), February 2005. progress), February 2005.
[I-D.savola-pim-lasthop-threats] [I-D.savola-pim-lasthop-threats]
Savola, P., "Last-hop Threats to Protocol Independent Savola, P., "Last-hop Threats to Protocol Independent
Multicast (PIM)", draft-savola-pim-lasthop-threats-01 Multicast (PIM)", draft-savola-pim-lasthop-threats-01
(work in progress), January 2005. (work in progress), January 2005.
[I-D.serbest-l2vpn-vpls-mcast] [I-D.serbest-l2vpn-vpls-mcast]
Serbest, Y., "Supporting IP Multicast over VPLS", Serbest, Y., "Supporting IP Multicast over VPLS",
draft-serbest-l2vpn-vpls-mcast-02 (work in progress), draft-serbest-l2vpn-vpls-mcast-03 (work in progress),
February 2005. July 2005.
[I-D.tsenevir-pim-sm-snoop] [I-D.tsenevir-pim-sm-snoop]
Senevirathne, T. and S. Vallepali, "Protocol Independent Senevirathne, T. and S. Vallepali, "Protocol Independent
Multicast-Sparse Mode (PIM-SM) Snooping", Multicast-Sparse Mode (PIM-SM) Snooping",
draft-tsenevir-pim-sm-snoop-00 (work in progress), draft-tsenevir-pim-sm-snoop-00 (work in progress),
April 2002. April 2002.
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
Vector Multicast Routing Protocol", RFC 1075, Vector Multicast Routing Protocol", RFC 1075,
November 1988. November 1988.
skipping to change at page 18, line 16 skipping to change at page 18, line 26
Architecture", RFC 3740, March 2004. Architecture", RFC 3740, March 2004.
[RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP):
Protocol Specification", RFC 3913, September 2004. Protocol Specification", RFC 3913, September 2004.
[RITVANEN] [RITVANEN]
Ritvanen, K., "Multicast Routing and Addressing", HUT Ritvanen, K., "Multicast Routing and Addressing", HUT
Report, Seminar on Internetworking, May 2004, Report, Seminar on Internetworking, May 2004,
<http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>. <http://www.tml.hut.fi/Studies/T-110.551/2004/papers/>.
Author's Address
Pekka Savola
CSC - Scientific Computing Ltd.
Espoo
Finland
Email: psavola@funet.fi
Appendix A. Multicast Payload Transport Extensions Appendix A. Multicast Payload Transport Extensions
A couple of mechanisms have been, and are being specified, to improve A couple of mechanisms have been, and are being specified, to improve
the characteristics of the data that can be transported over the characteristics of the data that can be transported over
multicast. multicast.
These go beyond the scope of multicast routing, but as reliable These go beyond the scope of multicast routing, but as reliable
multicast has some relevance, these are briefly mentioned. multicast has some relevance, these are briefly mentioned.
A.1 Reliable Multicast A.1. Reliable Multicast
Reliable Multicast Working Group has been working on experimental Reliable Multicast Working Group has been working on experimental
specifications so that applications requiring reliable delivery specifications so that applications requiring reliable delivery
characteristics, instead of simple unreliable UDP, could use characteristics, instead of simple unreliable UDP, could use
multicast as a distribution mechanism. multicast as a distribution mechanism.
One such mechanism is Pragmatic Generic Multicast (PGM) [RFC3208]. One such mechanism is Pragmatic Generic Multicast (PGM) [RFC3208].
This does not require support from the routers, bur PGM-aware routers This does not require support from the routers, bur PGM-aware routers
may act as helpers delivering missing data. may act as helpers delivering missing data.
A.2 Multicast Group Security A.2. Multicast Group Security
Multicast Security Working Group has been working on methods how the Multicast Security Working Group has been working on methods how the
integrity, confidentiality, and authentication of data sent to integrity, confidentiality, and authentication of data sent to
multicast groups can be ensured using cryptographic techniques multicast groups can be ensured using cryptographic techniques
[RFC3740]. [RFC3740].
Intellectual Property Statement Author's Address
Pekka Savola
CSC - Scientific Computing Ltd.
Espoo
Finland
Email: psavola@funet.fi
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 19, line 29 skipping to change at page 20, line 11
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 53 change blocks. 
121 lines changed or deleted 127 lines changed or added

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