draft-ietf-mboned-ipv6-multicast-issues-01.txt   draft-ietf-mboned-ipv6-multicast-issues-02.txt 
MBONE Deployment WG P. Savola MBONE Deployment WG P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Expires: March 3, 2005 September 2, 2004 Expires: August 19, 2005 February 15, 2005
IPv6 Multicast Deployment Issues IPv6 Multicast Deployment Issues
draft-ietf-mboned-ipv6-multicast-issues-01.txt draft-ietf-mboned-ipv6-multicast-issues-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 March 3, 2005. This Internet-Draft will expire on August 19, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This memo describes known issues with IPv6 multicast, and provides This memo describes known issues with IPv6 multicast, and provides
historical reference of how some earlier problems have been resolved. historical reference of how some earlier problems have been resolved.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Multicast-related Abbreviations . . . . . . . . . . . . . 3 1.1 Multicast-related Abbreviations . . . . . . . . . . . . . 3
2. Justification for IPv6 Inter-domain ASM . . . . . . . . . . . 3 2. Justification for IPv6 Inter-domain ASM . . . . . . . . . . . 3
2.1 SSM Deployment Issues . . . . . . . . . . . . . . . . . . 3 2.1 Groups of Different Non-global Scopes . . . . . . . . . . 3
2.2 Groups of Different Non-global Scope . . . . . . . . . . . 4 3. Different Solutions to Inter-domain Multicast . . . . . . . . 4
3. Different Solutions to Inter-domain Multicast . . . . . . . . 5 3.1 Changing the Multicast Usage Model . . . . . . . . . . . . 4
3.1 Changing the Multicast Usage Model . . . . . . . . . . . . 5 3.2 Implementing MSDP for IPv6 . . . . . . . . . . . . . . . . 5
3.2 Implementing MSDP for IPv6 . . . . . . . . . . . . . . . . 6 3.3 Implementing Another Multicast Routing Protocol . . . . . 5
3.3 Implementing Another Multicast Routing Protocol . . . . . 6
3.4 Embedding the RP Address in an IPv6 Multicast Address . . 6 3.4 Embedding the RP Address in an IPv6 Multicast Address . . 6
4. Issues with IPv6 Multicast . . . . . . . . . . . . . . . . . . 7 4. Issues with IPv6 Multicast . . . . . . . . . . . . . . . . . . 6
4.1 Issues with Embedded RP . . . . . . . . . . . . . . . . . 7 4.1 Issues with Embedded RP . . . . . . . . . . . . . . . . . 6
4.1.1 RP Failover with Embedded RP . . . . . . . . . . . . . 7 4.1.1 RP Failover with Embedded RP . . . . . . . . . . . . . 6
4.1.2 Embedded RP and Control Mechanisms . . . . . . . . . . 7 4.1.2 Embedded RP and Control Mechanisms . . . . . . . . . . 7
4.2 Neighbor Discovery Using Multicast . . . . . . . . . . . . 8 4.2 Neighbor Discovery Using Multicast . . . . . . . . . . . . 7
4.3 Functionality Like MLD Snooping . . . . . . . . . . . . . 8 4.3 Functionality Like MLD Snooping . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8
7.2 Informative References . . . . . . . . . . . . . . . . . . . 10 7.2 Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
A. SSM Deployment Issues . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 12
1. Introduction 1. Introduction
There are many issues concerning the deployment and implementation, There are many issues concerning the deployment and implementation,
and to a lesser degree, specification of IPv6 multicast. This memo and to a lesser degree, specification of IPv6 multicast. This memo
describes known problems to raise awareness, and documents how describes known problems to raise awareness, and documents how
previous problems have been resolved. previous problems have been resolved.
Section 2 describes the justifications for providing an inter-domain Section 2 describes the justifications for providing an inter-domain
multicast solution using Any Source Multicast (ASM) with IPv6. multicast solution using Any Source Multicast (ASM) with IPv6.
Section 3 in turn describes which options were considered for filling Section 3 in turn describes which options were considered for filling
those the requirements for the IPv6 inter-domain multicast solutions. the requirements for the IPv6 inter-domain multicast solutions.
These sections are provided for historical reference of the These sections are provided for historical reference of the
discussion and consensus in the IETF MBONED working group. discussion and consensus in the IETF MBONED working group.
Section 4 lists issues that have come up with IPv6 multicast but have Section 4 lists issues that have come up with IPv6 multicast but have
not yet been at least fully resolved, and may require raised not yet been at least fully resolved, and may require raised
awareness. awareness.
1.1 Multicast-related Abbreviations 1.1 Multicast-related Abbreviations
ASM Any Source Multicast ASM Any Source Multicast
skipping to change at page 3, line 40 skipping to change at page 3, line 40
MLD Multicast Listener Discovery MLD Multicast Listener Discovery
MSDP Multicast Source Discovery Protocol MSDP Multicast Source Discovery Protocol
PIM Protocol Independent Multicast PIM Protocol Independent Multicast
PIM-SM Protocol Independent Multicast - Sparse Mode PIM-SM Protocol Independent Multicast - Sparse Mode
RP Rendezvous Point RP Rendezvous Point
SSM Source-specific Multicast SSM Source-specific Multicast
2. Justification for IPv6 Inter-domain ASM 2. Justification for IPv6 Inter-domain ASM
This section documents the reasons and the discussion which led to This section documents the reasons and the discussion which led to
the agreement why a solution to IPv6 inter-domain ASM was necessary. the agreement that solution to IPv6 inter-domain ASM was necessary.
The main reason was that SSM [I-D.ietf-ssm-arch] was not considered
to solve all the relevant problems (e.g., many-to-many applications,
source discovery), and that SSM was not sufficiently widely deployed
and used.
2.1 SSM Deployment Issues
To be deployed, SSM requires changes to:
1. routers
2. IGMP/MLD-snooping Ethernet switches
3. hosts
4. application programming interfaces (APIs)
5. multicast usage models
Introducing SSM support in the routers has been straightforward as
PIM-SSM is a subset of PIM-SM [I-D.ietf-pim-sm-v2-new].
IGMP-snooping Ethernet switches have been a more difficult issue
[SSMSNOOP]; some which perform IGMPv2 snooping discard IGMPv3 reports
or queries, or multicast transmissions associated to them. If MLDv1
snooping had been implemented (or is implemented in a similar
manner), this would likely have affected that as well.
Host systems require MLDv2 [RFC3810] support. The situation has
improved with respect to MLDv2 support for end systems, and
interoperability has increased after the publication of the RFC due
to the stabilization of the ICMP types used.
The multicast source filtering API specification has also been
completed [RFC3678]; its deployment is likely roughly equal (or
slightly worse) than MLDv2. The API is required for creating
(cross-platform) SSM applications.
The most difficult issue, multicast usage models, remains a problem The main reason was that SSM [RFC3569] was not considered to solve
as of this writing. SSM is an excellent fit for one-to-many all the relevant problems (e.g., many-to-many applications, source
distribution topologies, and porting such applications to use SSM discovery), and that SSM was not sufficiently widely deployed and
would likely be rather simple. However, a significant number of used. As these issues are more generic than just IPv6, they are
current applications are many-to-many (e.g., conferencing described in Appendix A.
applications) which cannot be converted to SSM without significant
effort, including, for example, out-of-band source discovery. For
such applications to be usable for IPv6 at least in a short to medium
term, ASM -like techniques seem to be required.
2.2 Groups of Different Non-global Scope 2.1 Groups of Different Non-global Scopes
Many ASM applications are used with a smaller scope than global; some Many ASM applications are used with a smaller scope than global; some
of these have a wider scope than others. However, groups of smaller of these have a wider scope than others. However, groups of smaller
scope typically need to be in their own PIM-SM domains to prevent scope typically need to be in their own PIM-SM domains to prevent
inappropriate data leakage. Therefore if a site has groups of inappropriate data leakage.
different scopes, having multiple PIM domain borders becomes a
requirement unless inter-domain multicast is used instead; further,
configuring such nesting scopes would likely be an operational
challenge. In consequence, if these applications of non-global scope
need to be used, inter-domain multicast support is practically
required.
In consequence, especially if multicast with different non-global Therefore if a site has groups of different scopes, it is important
scopes is used, there will be a need for inter-domain multicast to have multiple PIM domain borders. However, this need can be
solutions. As many applications are relying on ASM characteristics, obviated by using globally-scoped multicast addresses instead. It is
this further increases a need for an inter-domain ASM solution. easier to set scoping using globally scoped addresses, rather than
having to configure (nesting) local multicast scopes.
In consequence there will be a need for inter-domain multicast
solutions, as a means to simplify and obviate the need for
operational hassles with local scoping. As many applications are
relying on ASM characteristics, this further increases the need for
an inter-domain ASM solution.
3. Different Solutions to Inter-domain Multicast 3. Different Solutions to Inter-domain Multicast
When ASM is used, the Internet must be divided to multiple PIM-SM for When ASM is used, the Internet must be divided into multiple PIM-SM
both administrative and technical reasons, which means there will be domains for both administrative and technical reasons, which means
multiple PIM-SM RPs which need to communicate the information of there will be multiple PIM-SM RPs which need to share the source IP
sources between themselves. addresses between themselves.
On the other hand, SSM does not require RPs and also works in the On the other hand, SSM does not require RPs and also works in the
inter-domain without such communication. Section 2 describes the inter-domain without such communication. Section 2 describes the
justification why Inter-domain ASM was still considered to be justification why Inter-domain ASM was still considered to be
required. This section describes different solutions which were required. This section describes different solutions which were
discussed to providing inter-domain multicast for IPv6. discussed to providing inter-domain multicast for IPv6.
For inter-domain multicast, there is consensus to continue using SSM, For inter-domain multicast, MBONED WG came to consensus to continue
and also use Embedded-RP as appropriate. using SSM, and also use Embedded-RP for ASM as appropriate.
This section provides historical reference of the discussion and This section provides historical reference of the discussion and
decisions. decisions.
3.1 Changing the Multicast Usage Model 3.1 Changing the Multicast Usage Model
As ASM model has been found to be complex and a bit problematic, some As ASM model has been found to be complex and a bit problematic, some
felt that this is a good incentive to move to SSM for good (at least felt that this is a good incentive to move to SSM for good (at least
for most cases). Below two paragraphs are adapted from for most cases). Below two paragraphs are adapted from
[I-D.bhattach-diot-pimso]: [I-D.bhattach-diot-pimso]:
skipping to change at page 6, line 5 skipping to change at page 5, line 13
few-to-few (e.g. private chat rooms, whiteboards), few-to-many few-to-few (e.g. private chat rooms, whiteboards), few-to-many
(e.g., video conferencing, distance learning) and many-to-many (e.g., video conferencing, distance learning) and many-to-many
(e.g., large chat rooms, multi-user games). The first two classes (e.g., large chat rooms, multi-user games). The first two classes
can be easily handled using a few one-to-many source-based trees. can be easily handled using a few one-to-many source-based trees.
The issue of many-to-many multicasting service on top of a SSM The issue of many-to-many multicasting service on top of a SSM
architecture is an open issue at this point. However, some feel architecture is an open issue at this point. However, some feel
that even many-to-many applications should be handled with that even many-to-many applications should be handled with
multiple one- to-many instead of shared trees. multiple one- to-many instead of shared trees.
In any case, even though SSM would avoid the problems of ASM, it was In any case, even though SSM would be preferable in many cases, SSM
felt that SSM is not sufficiently widely available to completely was not sufficiently widely available to completely replace ASM (see
replace ASM (see Section 2.1), and that the IETF should not try to Appendix A), and that the IETF should not try to force the
force the application writers to change their multicast usage models. application writers to change their multicast usage models.
3.2 Implementing MSDP for IPv6 3.2 Implementing MSDP for IPv6
In IPv4, notification of multicast sources between these PIM-SM RPs In IPv4, notification of multicast sources between these PIM-SM RPs
is done with Multicast Source Discovery Protocol (MSDP) [RFC3618]. is done with Multicast Source Discovery Protocol (MSDP) [RFC3618].
The protocol is widely considered a sub-optimal solution and even The protocol is widely considered a sub-optimal solution and even
dangerous to deploy; when it was specified, it was only meant as a dangerous to deploy; when it was specified, it was only meant as a
"stop-gap" measure. "stop-gap" measure.
The easiest stop-gap solution (to a stop-gap solution) would have The easiest stop-gap solution (to a stop-gap solution) would have
skipping to change at page 6, line 32 skipping to change at page 5, line 40
There is and has been resistance to this, as MSDP was not supposed to There is and has been resistance to this, as MSDP was not supposed to
last this long in the first place; there is clear consensus that last this long in the first place; there is clear consensus that
there should be no further work on it [I-D.ietf-mboned-msdp-deploy]. there should be no further work on it [I-D.ietf-mboned-msdp-deploy].
3.3 Implementing Another Multicast Routing Protocol 3.3 Implementing Another Multicast Routing Protocol
One possibility might have been to specify and/or implement a One possibility might have been to specify and/or implement a
different multicast routing protocol. different multicast routing protocol.
In fact, Border Gateway Multicast Protocol (BGMP) In fact, Border Gateway Multicast Protocol (BGMP) [RFC3913] has been
[I-D.ietf-bgmp-spec] has been specified; however, it is widely held specified; however, it is quite complex and there have been no
to be quite complex and there have been no implementations, nor will implementations nor desire to write any. Lacking deployment
to make any. Lacking deployment experience and specification experience and specification analysis, it is difficult to say which
analysis, it is difficult to say which problems it might solve (and problems BGMP might solve (and possibly, which new ones BGMP might
possibly, which new ones to introduce). One probable reason why BGMP introduce). One probable reason why BGMP failed to attract
failed to attract continuing interest was it's dependance on continuing interest was it's dependance on similarly heavy-weight
similarly heavy-weight multicast address allocation/assignment multicast address allocation/assignment protocols.
protocols.
As of this writing, no other inter-domain protocols have been As of this writing, no other inter-domain protocols have been
specified, and BGMP is not considered a realistic option. specified, and BGMP is not considered a realistic option.
3.4 Embedding the RP Address in an IPv6 Multicast Address 3.4 Embedding the RP Address in an IPv6 Multicast Address
One way to work around these problems was to allocate and assign One way to work around these problems was to allocate and assign
multicast addresses in such a fashion that the address of the RP multicast addresses in such a fashion that the address of the RP
could be automatically calculated from the IPv6 multicast address. could be automatically calculated from the IPv6 multicast address.
Making some assumptions about how the RPs would configure Interface Making some assumptions about how the RPs would configure Interface
Identifiers, this is can achieved as described in Identifiers, this is can achieved as described in [RFC3956]; PIM-SM
[I-D.ietf-mboned-embeddedrp]; PIM-SM implementations need to implementations need to implement the Embedded RP group-to-RP mapping
implement the Embedded RP group-to-RP mapping mechanism which mechanism which processes this encoding.
processes this encoding.
To completely replace the need for MSDP for IPv6, a different way to To completely replace the need for MSDP for IPv6, a different way to
implement "Anycast RP" [RFC3446] -technique, for sharing the state implement "Anycast RP" [RFC3446] is also needed. One such approach
information between different RP's in one PIM-SM domain, is also is described in [I-D.ietf-pim-anycast-rp].
needed. One such approach is described in [I-D.ietf-pim-anycast-rp].
4. Issues with IPv6 Multicast 4. Issues with IPv6 Multicast
This section describes issues that have come up with IPv6 multicast This section describes issues that have come up with IPv6 multicast
but have not yet been at least fully resolved. but have not yet been at least fully resolved.
4.1 Issues with Embedded RP 4.1 Issues with Embedded RP
4.1.1 RP Failover with Embedded RP 4.1.1 RP Failover with Embedded RP
skipping to change at page 8, line 5 skipping to change at page 7, line 12
place. However, the multicast state stored in the RP would be lost, place. However, the multicast state stored in the RP would be lost,
unless it is synchronized by some out-of-band mechanism. unless it is synchronized by some out-of-band mechanism.
4.1.2 Embedded RP and Control Mechanisms 4.1.2 Embedded RP and Control Mechanisms
With ASM and MSDP deployment, the ISPs can better control who is With ASM and MSDP deployment, the ISPs can better control who is
using their RPs. using their RPs.
With Embedded RP, anyone could use a third-party RP to host their With Embedded RP, anyone could use a third-party RP to host their
groups unless some mechanisms, for example access-lists, are in place groups unless some mechanisms, for example access-lists, are in place
to control the use of the RP [I-D.ietf-mboned-embeddedrp]. to control the use of the RP [RFC3956].
Such abuse is of questionable benefit, though, as anyone with a /64 Such abuse is of questionable benefit, though, as anyone with a /64
could form an RP of its own. could form an RP of its own.
Whether this is a sufficiently serious problem worth designing a Whether this is a sufficiently serious problem worth designing a
(potentially complex) solution for is still under debate, as of this (potentially complex) solution for is still under debate, as of this
writing. writing.
4.2 Neighbor Discovery Using Multicast 4.2 Neighbor Discovery Using Multicast
Neighbor Discovery [RFC2461] uses link-local multicast in Ethernet Neighbor Discovery [RFC2461] uses link-local multicast in Ethernet
media, not broadcast as ARP does with IPv4. This has been seen to media, not broadcast as ARP does with IPv4. This has been seen to
cause operational problems with some equipment. cause operational problems with some equipment. This section
documents these as "lessons (hopefully) learned" so that other
vendors could better avoid them.
The author has seen one brand of managed Ethernet switches, and heard There are equipment which do not forward (IPv6) multicast frames
reports of a few unmanaged switches, that do not forward IPv6 appropriately; these could be considered "bugs", but are sufficiently
link-local multicast packets to other ports at all. In essence, commonplace so that the behaviour is worth mentioning.
native IPv6 is impossible with this equipment. These problems have
likely been fixed in later revisions of the equipment, but this does
not fix the equipment on the field, and it is likely that similar
problems will surface again.
It seems likely that this may be a problem with some switches that In particular, many WLAN IEEE 802.11b access points, working in the
build multicast forwarding state based on Layer 3 information (and do bridged mode, do not forward IPv6 Ethernet multicast frames across
not support IPv6); state using Layer 2 information would work just the bridge. When procuring WLAN equipment, it is probably a good
fine [I-D.ietf-magma-snoop]. Therefore the snooping swich developers idea to check out this functionality explicitly.
In some Ethernet switches, IPv6 frames are likewise not forwarded.
The problem has likely been with building multicast forwarding state
based on Layer 3 information (which the vendor does support with
IPv6); state using Layer 2 information would work just fine
[I-D.ietf-magma-snoop]. Therefore the snooping swich developers
should be aware of the tradeoff of using Layer 2 vs Layer 3 should be aware of the tradeoff of using Layer 2 vs Layer 3
information on multicast data forwarding, especially if IPv6 snooping information on multicast data forwarding, especially if IPv6 snooping
is not supported. is not supported.
For the deployment of IPv6, it would be important to find out how There are no good workarounds for these problems, except
this can be fixed (e.g., how exactly this breaks specifications) and disseminating information about them (e.g., at http://www.v6fix.net)
how one can identify which equipment could cause problems like these and complaining to the vendor.
(and whether there are workarounds).
One workaround might be to implement a toggle in the nodes that would
use link-layer broadcast instead of multicast as a fallback solution.
However, this would have to be used in all the systems on the same
link, otherwise local communication is impaired.
4.3 Functionality Like MLD Snooping 4.3 Functionality Like MLD Snooping
On Ethernet, multicast frames are forwarded to every port, even On Ethernet, multicast frames are forwarded to every port, even
without subscribers (or IPv6 support). without subscribers (or IPv6 support).
Especially if multicast traffic is relatively heavy (e.g., video Especially if multicast traffic is relatively heavy (e.g., video
streaming), it becomes particularly important to have some feature streaming), it becomes particularly important to have some feature
like Multicast Listener Discovery (MLD) snooping implemented, to like Multicast Listener Discovery (MLD) snooping implemented, to
reduce the amount of flooding [I-D.ietf-magma-snoop]. reduce the amount of flooding [I-D.ietf-magma-snoop].
In addition, some vendors have not realized which multicast addresses
(in particular, link-local addresses) MLD reports -- utilized in the
snooping -- should be generated for. The introduction of MLD
snooping could cause hosts which do not send MLD reports
appropriately to be blocked out. As specified in [RFC2461], an MLD
report must be generated for every group except all-nodes (ff02::1 --
which is forwarded to all ports); this also includes all the other
link-local groups.
Looking at the actual problem from a higher view, it is not clear Looking at the actual problem from a higher view, it is not clear
that MLD snooping is the right long-term solution. It makes the that MLD snooping is the right long-term solution. It makes the
switches complex, requires the processing of datagrams above the switches complex, requires the processing of datagrams above the
link-layer, and should be discouraged link-layer, and should be discouraged
[I-D.ietf-mboned-iesg-gap-analysis]: the whole idea of L2-only [I-D.ietf-mboned-iesg-gap-analysis]: the whole idea of L2-only
devices having to peek into L3 datagrams seems like a severe layering devices having to peek into L3 datagrams seems like a severe layering
violation -- and often the devices aren't upgradeable (if there are violation -- and often the devices aren't upgradeable (if there are
bugs or missing features, which could be fixed later) in any way. bugs or missing features, which could be fixed later) in any way.
Better mechanisms could be having routers tell switches which Better mechanisms could be having routers tell switches which
multicasts to forward where (e.g., [CGMP]) or by using some other multicasts to forward where (e.g., [CGMP]) or by using some other
skipping to change at page 9, line 50 skipping to change at page 8, line 48
comments along the way. "Itojun" Hagino brought up the need for MLD comments along the way. "Itojun" Hagino brought up the need for MLD
snooping in a presentation. Bill Nickless pointed out issues in the snooping in a presentation. Bill Nickless pointed out issues in the
gap analysis and provided a pointer to GARP/GMRP; Havard Eidnes made gap analysis and provided a pointer to GARP/GMRP; Havard Eidnes made
a case for a protocol like CGMP. Leonard Giuliano pointed out a more a case for a protocol like CGMP. Leonard Giuliano pointed out a more
complete analysis of SSM with different kind of applications. complete analysis of SSM with different kind of applications.
7. References 7. References
7.1 Normative References 7.1 Normative References
[I-D.ietf-bgmp-spec]
Thaler, D., "Border Gateway Multicast Protocol (BGMP):
Protocol Specification", draft-ietf-bgmp-spec-06 (work in
progress), January 2004.
[I-D.ietf-mboned-embeddedrp]
Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
draft-ietf-mboned-embeddedrp-07 (work in progress), July
2004.
[I-D.ietf-mboned-msdp-deploy] [I-D.ietf-mboned-msdp-deploy]
McBride, M., "Multicast Source Discovery Protocol (MSDP) McBride, M., "Multicast Source Discovery Protocol (MSDP)
Deployment Scenarios", draft-ietf-mboned-msdp-deploy-06 Deployment Scenarios",
(work in progress), March 2004. Internet-Draft draft-ietf-mboned-msdp-deploy-06, March
2004.
[I-D.ietf-pim-anycast-rp] [I-D.ietf-pim-anycast-rp]
Farinacci, D., "Anycast-RP using PIM", Farinacci, D., "Anycast-RP using PIM",
draft-ietf-pim-anycast-rp-02 (work in progress), June Internet-Draft draft-ietf-pim-anycast-rp-02, June 2004.
2004.
[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-10 (work in progress), July 2004. Internet-Draft draft-ietf-pim-sm-v2-new-11, October 2004.
[I-D.ietf-ssm-arch]
Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", draft-ietf-ssm-arch-05 (work in progress), July 2004.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998. 1998.
[RFC3446] Kim, D., Meyer, D., Kilmer, H. and D. Farinacci, "Anycast [RFC3446] Kim, D., Meyer, D., Kilmer, H. and D. Farinacci, "Anycast
Rendevous Point (RP) mechanism using Protocol Independent Rendevous Point (RP) mechanism using Protocol Independent
Multicast (PIM) and Multicast Source Discovery Protocol Multicast (PIM) and Multicast Source Discovery Protocol
(MSDP)", RFC 3446, January 2003. (MSDP)", RFC 3446, January 2003.
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
[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.
[RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP):
Protocol Specification", RFC 3913, September 2004.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004.
7.2 Informative References 7.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 of [GARP] Tobagi, F., Molinero-Fernandez, P. and M. Karam, "Study of
IEEE 802.1p GARP/GMRP Timer Values", 1997. IEEE 802.1p GARP/GMRP Timer Values", 1997.
[I-D.bhattach-diot-pimso] [I-D.bhattach-diot-pimso]
Bhattacharyya, S., Diot, C., Giuliano, L. and R. Rockell, Bhattacharyya, S., Diot, C., Giuliano, L. and R. Rockell,
"Deployment of PIM-SO at Sprint (PIM-SO)", March 2000. "Deployment of PIM-SO at Sprint (PIM-SO)", March 2000.
[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-11 (work in progress), May 2004. Internet-Draft draft-ietf-magma-snoop-11, May 2004.
[I-D.ietf-mboned-iesg-gap-analysis] [I-D.ietf-mboned-iesg-gap-analysis]
Meyer, D. and B. Nickless, "Internet Multicast Gap Meyer, D. and B. Nickless, "Internet Multicast Gap
Analysis from the MBONED Working Group for the IESG", Analysis from the MBONED Working Group for the IESG",
draft-ietf-mboned-iesg-gap-analysis-00 (work in progress), Internet-Draft draft-ietf-mboned-iesg-gap-analysis-00,
July 2002. July 2002.
[I-D.ietf-pim-sm-bsr] [I-D.ietf-pim-sm-bsr]
Fenner, B., "Bootstrap Router (BSR) Mechanism for PIM", Fenner, B., "Bootstrap Router (BSR) Mechanism for PIM",
draft-ietf-pim-sm-bsr-04 (work in progress), July 2004. Internet-Draft draft-ietf-pim-sm-bsr-04, July 2004.
[RFC3678] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface [RFC3678] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", RFC 3678, Extensions for Multicast Source Filters", RFC 3678,
January 2004. January 2004.
[SSMSNOOP] [SSMSNOOP]
"Operational Problems with IGMP snooping switches", March "Operational Problems with IGMP snooping switches", March
2003, <http://www.ietf.org/proceedings/03mar/148.htm>. 2003, <http://www.ietf.org/proceedings/03mar/148.htm>.
Author's Address Author's Address
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo Espoo
Finland Finland
EMail: psavola@funet.fi Email: psavola@funet.fi
Appendix A. SSM Deployment Issues
To be deployed, SSM requires changes to:
1. routers
2. IGMP/MLD-snooping Ethernet switches
3. hosts
4. application programming interfaces (APIs)
5. multicast usage models
Introducing SSM support in the routers has been straightforward as
PIM-SSM is a subset of PIM-SM [I-D.ietf-pim-sm-v2-new].
IGMP-snooping Ethernet switches have been a more difficult issue
[SSMSNOOP]; some which perform IGMPv2 snooping discard IGMPv3 reports
or queries, or multicast transmissions associated to them. If MLDv1
snooping had been implemented (or is implemented in a similar
manner), this would likely have affected that as well.
Host systems require MLDv2 [RFC3810] support. The situation has
improved with respect to MLDv2 support for end systems, and
interoperability has increased after the publication of the RFC due
to the stabilization of the ICMP types used.
The multicast source filtering API specification has also been
completed [RFC3678]; its deployment is likely roughly equal (or
slightly worse) than MLDv2. The API is required for creating
(cross-platform) SSM applications.
The most difficult issue, multicast usage models, remains a problem
as of this writing as described below. SSM is an excellent fit for
one-to-many distribution topologies, and porting such applications to
use SSM would likely be rather simple. However, a significant number
of current applications are many-to-many (e.g., conferencing
applications) which cannot be converted to SSM without significant
effort, including, for example, out-of-band source discovery. For
such applications to be usable for IPv6 at least in a short to medium
term, ASM -like techniques seem to be required.
Intellectual Property Statement Intellectual Property Statement
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
skipping to change at page 12, line 41 skipping to change at page 12, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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. 

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