[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00
Internet Draft Editors: D. Meyer
Sprint
Document: B. Nickless
draft-ietf-mboned-iesg-gap-analysis-00.txt Argonne National
Laboratory
Expires: July 2002
January 2003
Internet Multicast Gap Analysis
from the MBONED Working Group
for the IESG
1. Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
An overview of IP multicast as deployed in the Internet today, from
the perspective of the MBONED working group. Existing
infrastructure is examined critically. Suggestions for possible
improvement of the overall architecture are presented for the IESG.
3. Table of Contents
1. Status of this Memo.............................................1
2. Abstract........................................................1
4. Overview and Background.........................................2
5. Conventions used in this document...............................2
6. RFC 1112........................................................3
7. Source-Specific Multicast.......................................3
8. Host Extensions for IP Multicast................................3
Meyer,
Nickless (Editors) Informational - Expires January 2002 1
Internet Multicast Gap Analysis July 2002
9. Mapping of Multicast Group Addresses to Ethernet MAC Addresses..4
10. Local Subnet Receiver Interest Protocol (IGMP).................4
11. Collision-Sense Media Access Sender Model......................4
12. Multicast Gateways.............................................5
13. Dense Mode Internet Multicast Routing..........................5
14. Reachability Protocol Independent Multicast Routing............6
15. Sparse Mode Internet Multicast Routing.........................7
16. Mixed Dense/Sparse Mode Internet Multicast Routing.............7
17. Bursty Sources vs. Sparse Mode Forwarding State Maintenance....8
18. Co-mingled Source Knowledge and Packet Forwarding..............8
19. Co-mingled IP and Ethernet Routing.............................9
20. Inter-Domain IP Multicast Exchange Points......................9
21. IP Multicast Architectural Gaps...............................11
22. Recommendations from MBONED to IESG...........................11
23. Acknowledgements..............................................13
24. Security Considerations.......................................13
25. References....................................................14
26. EditorsÆ Addresses............................................14
4. Overview and Background
At the IETF-54 meeting, the MBONED working group recommended that
the MSDP working group publish their current work as an
Informational RFC and shut down. Some participants in the MBONED
and MSDP working groups believed that the recurring discussions
about the operation of MSDP were proxy arguments about the IP
Multicast service model, and how that model can be supported in the
Internet. Participants came to rough consensus that the best place
for these overall service model and deployment questions is the
MBONED working group.
A two phase approach was adopted. The short-term objective is to
document existing MSDP implementations and deployments. A longer-
term objective for the MBONED working group is to perform a ôgap
analysisö of the existing IP multicast service model, protocols, and
deployment.
This document represents that ôgap analysis,ö and is intended as
advice to IESG. The MBONED participants hope the IESG will consider
this advice in the context of IESG guidance for further IP multicast
protocol development and deployment work.
5. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
Meyer,
Nickless (Editors) Informational - Expires January 2002 2
Internet Multicast Gap Analysis July 2002
6. RFC 1112
The seminal specification for IP Multicast is RFC 1112. It
describes five elements required for IP Multicast on a local subnet:
extensions to host software, an IPv4 address range reserved for
group addresses, a method for mapping multicast group addresses to
Ethernet Media Access Control (MAC) addresses, a protocol to
discover receivers interested in packets addressed to a group
(Internet Group Management Protocol), and a collision-sense multiple
access (CSMA) method for multicast packet senders.
This model was inspired by Ethernet. The IEEE 802.3 Ethernet
specification includes a bit in the MAC address format that
indicates the frame may be intended for multiple receivers.
Ethernet interfaces can be programmed to receive these multicast MAC
addresses and forward them to the host for processing. On a
traditional 10Base5 Ethernet, any station can put a frame on the
wire, with the only requirement being to sense collisions and
retransmit if necessary.
RFC 1112 also suggests that gateways may exist for moving IP
multicast datagrams to other subnets with interested receivers.
The RFC 1112 service model has since become known as Any Source
Multicast (ASM). When a receiver registers interest in a group, it
will be delivered datagrams from any source that transmits datagrams
addressed to that group.
7. Source-Specific Multicast
Just as early Ethernet controllers were programmable to only receive
frames with certain MAC addresses, RFC 1112 and IGMP Version 2 only
allowed IP Multicast receivers to elect to receive datagrams
addressed to specific group addresses. Receivers could not select
the sources participating in a group from which they would receive.
Later Ethernet controllers allowed more sophisticated filtering,
including the capability of choosing from which senders the host
wished to accept frames. Similarly, Source-Specific Multicast (SSM)
is an extension to the basic IP multicast model that allows
receivers to select the source addresses from which to receive
datagrams. IGMP Version 3 implements this service model extension
for IPv4, and the Multicast Listener Discovery (MLD) protocol
Version 2 implements this service model extension for IPv6.
8. Host Extensions for IP Multicast
Ultimately, user applications originate and accept IP multicast
datagrams. RFC 1112 describes the extensions to various host
software modules to support applications sending and receiving
Meyer,
Nickless (Editors) Informational - Expires January 2002 3
Internet Multicast Gap Analysis July 2002
datagrams. It also describes the operations a user application can
perform to transmit and receive multicast datagrams.
9. Mapping of Multicast Group Addresses to Ethernet MAC Addresses
When preparing an IP datagram for transmission on an Ethernet, it is
necessary for the host to specify the destination MAC address. (The
source MAC address is typically constant, based on the IEEE-
controlled address hard-wired into the Ethernet controller.) Before
sending unicast datagrams, the Address Resolution Protocol (ARP) is
generally used by a host to learn the destination MAC address for a
given destination IPv4 address. RFC 2461 describes the equivalent
Neighbor Discovery protocol procedure used for IPv6.
IPv4 multicast datagrams are not addressed to specific host
addresses; instead, they are addressed to group addresses in the
224.0.0.0/4 range. Likewise, IPv6 multicast datagrams are addressed
to group addresses in the FF00::/8 range.
RFC 1112 specifies a static 32:1 mapping from IPv4 multicast group
addresses to Ethernet MAC addresses. One reason to define the 32:1
mapping was financial; to reserve enough Ethernet MAC addresses from
the IEEE for a 1:1 mapping would have cost USD$16,000 in 1988. The
32:1 mapping reduced that cost to USD$1,000.
RFC 2464 (section 7) specifies a static 2^96:1 (that is,
79,228,162,514,264,337,593,543,950,336:1) mapping from IPv6
multicast group addresses to Ethernet MAC addresses. Note that it
is impossible to determine the RFC 2375 scope directly from the
Ethernet 802.3 MAC address, as the RFC 2464 mapping does not include
the scope octet.
10. Local Subnet Receiver Interest Protocol (IGMP)
RFCs 1112 and 2236 define the Internet Group Management Protocol
(IGMP) Version 2. IGMPv2 notifies the network of the interest of a
host for datagrams addressed to a given group address. Again, this
is analogous to a host notifying an Ethernet controller to accept
frames with a given MAC address.
The IPv6 equivalent of IGMP is the Multicast Listener Discovery
Protocol (MLD), originally defined in RFC 2710.
11. Collision-Sense Media Access Sender Model
Any host connected to a 10Base5 Ethernet can choose to transmit a
frame at any time, subject only to the operation of the collision-
sense media access (CSMA) protocol.
Meyer,
Nickless (Editors) Informational - Expires January 2002 4
Internet Multicast Gap Analysis July 2002
Given the static mapping of IPv4 group addresses to Ethernet MAC
addresses, RFC 1112 specifies that an IPv4 datagram, addressed to a
multicast group, can be transmitted by a host at any time.
Similarly, RFC 2464 implies that an IPv6 datagram addressed to a
multicast group can be transmitted by a host at any time.
12. Multicast Gateways
RFC 1112 suggested that gateways might exist to pass multicast
traffic between networks. Through the operation of the local subnet
receiver interest protocol IGMP, these gateways can learn of the
interest of receivers in multicast group datagrams.
As the technology for internetwork routing was unknown at the time
of publication, RFC 1112 does not specify how that routing is to
take place.
13. Dense Mode Internet Multicast Routing
Following the Ethernet broadcast model, the first scheme for routing
IP multicast datagrams between Ethernets was for a multi-homed
gateway to flood all multicast datagrams on each Ethernet to all
other Ethernets. In other words, gateways become the IP multicast
equivalent of Ethernet repeaters.
Ethernet bridges generally run the Spanning Tree Protocol (IEEE
Specification 802.1d) to eliminate forwarding loops. Forwarding
loops can also happen when there is more than one multi-homed
gateway in an internetwork. The Distance Vector Multicast Routing
Protocol (DVMRP) [RFC 1075] operates to eliminate forwarding loops.
DVMRP, operating on a gateway, keeps track of the Reverse Path
Forwarding (RPF) interface from which a multicast datagram with a
given source address should arrive. If such multicast datagrams
arrive on the appropriate RPF interfaces, they are replicated and
flooded to all other interfaces by the gateway.
The effect of this procedure is to replicate all IP multicast
datagrams transmitted by any host to all subnets. This limits the
available bandwidth for all multicast traffic in the internetwork to
that bandwidth available on the slowest link.
One optimization to this procedure is for gateways to use a receiver
interest protocol such as IGMP to limit traffic flooded out an
interface. Only if there are receivers interested in a group, on a
network attached to a given interface, will the gateway flood
datagrams addressed to that group out that interface. Of course,
gateways are generally assumed by fellow gateways to be interested
in all groups, so this optimization does not apply to networks with
more than one gateway.
Meyer,
Nickless (Editors) Informational - Expires January 2002 5
Internet Multicast Gap Analysis July 2002
A second optimization further limits flooding. Consider a situation
where a gateway has no interested receivers on all attached networks
for a given group, yet receives an IP multicast datagram addressed
to that group. DVMRP provides for gateways to send Prune messages
out the appropriate RPF interface to notify fellow gateways that
they have no interested receivers.
A third optimization provides for this limiting process to continue
recursively. Once a gateway receives Prune messages from all other
gateways on a network, and has no interested hosts, it stops
forwarding messages out the attached interface. If all interfaces
have such stoppages for a given group, it can generate its own Prune
towards out the appropriate RPF interface to notify upstream
gateways to stop sending datagrams addressed to a given group.
Through repeated application of this procedure, the distribution of
multicast datagrams is limited only to the networks that have
attached interested receivers, and to intermediate networks between
sources and interested receivers. Multicast datagrams are
distributed down a tree rooted at the source. Vertexes of the tree
are the gateways, and the edges of the tree are the networks
connecting gateways.
This general strategy is known as ôdense modeö multicast routing.
As the number of multicast sources and receivers increase, the core
of the multicast-enabled internetwork becomes more and more heavily
loaded. Fewer opportunities for pruning occur.
As dense mode routing was experimentally deployed, a meta-stable
failure mode was discovered. A gateway (or its attached network)
can be overwhelmed with multicast traffic. Even though the gateway
may have no interested receivers, it can fail to generate the
required number of Prune messages. Unfortunately this failure mode
can spread, because upstream gateways (closer to the sources) assume
that packet replication and transmission is required, adding to
their own load. Eventually the whole multicast internet collapses
under the weight of un-Pruned traffic.
14. Reachability Protocol Independent Multicast Routing
In addition to controlling whether forwarding occurs (based on
receiver interest), DVMRP maintains the topology of the forwarding
trees from source to receivers. As its name implies, a distance-
vector procedure similar to RIP is used.
Experience has shown that a distance-vector reachability protocol
does not scale for large internets. Link-state protocols such as
IS-IS and OSPF are generally used within administrative domains, and
the Border Gateway Protocol is generally used between administrative
domains. Convergence speed, policy flexibility, and other
considerations motivate this diversity of reachability protocol use.
Meyer,
Nickless (Editors) Informational - Expires January 2002 6
Internet Multicast Gap Analysis July 2002
The Protocol Independent Multicast (PIM) multicast routing protocol
takes its name from the fact that it can take its reachability
information from any underlying reachability protocol. PIM
concentrates on maintaining and controlling the multicast forwarding
tree along the topology provided by whatever underlying reachability
protocol(s) is/are used.
15. Sparse Mode Internet Multicast Routing
One way to eliminate the dense mode meta-stable failure mode is by
adjusting the inter-gateway forwarding procedure to require
downstream gateways to explicitly request datagrams for a given
group based on receiver interest.
In this regime, the forwarding tree is built from the interested
receivers towards the source. Datagrams from the source are
distributed back down the tree to the interested receivers.
Through IGMPv3 (or any similar SSM-style receiver interest discovery
protocol) the receivers provide both pieces of information necessary
for the internetwork to create and maintain the source-rooted
forwarding tree: the IP addresses of the source and multicast group.
16. Mixed Dense/Sparse Mode Internet Multicast Routing
A straightforward sparse mode forwarding protocol alone cannot
support the RFC 1112 Any Source Multicast service model. Although
the receivers supply the group address for which theyÆre interested
in receiving datagrams, the internetwork is responsible for
identifying active sources so the source-rooted forwarding trees can
be created.
The hybrid approach taken in RFC 2362 (PIM Sparse Mode Version 2)
and MSDP is to flood the initial datagrams from any sender,
typically under strict rate controls. When a gateway receives one
of these flooded datagrams from a given sender, whose group address
matches that of an attached interested receiver, the gateway grafts
itself to the source-rooted forwarding tree for that sender.
So long as the source continues to transmit packets, the forwarding
tree associated with the source is preserved. After a period of
quiescence the forwarding tree is torn down.
The result is a dual-plane routing architecture. A dense-mode,
rate-limited, flooding plane distributes datagrams from newly active
sources. A sparse-mode, source-rooted tree based forwarding plane
distributes and replicates datagrams from established sources.
Meyer,
Nickless (Editors) Informational - Expires January 2002 7
Internet Multicast Gap Analysis July 2002
17. Bursty Sources vs. Sparse Mode Forwarding State Maintenance
Prior to the development of the client-server-based World Wide Web,
a session announcement protocol (SAP) was developed to allow
interested parties to discover and participate in multilateral
multimedia conference. Periodically a multicast datagram would be
generated and sourced, providing the multicast group addresses,
media formats, and other such information needed for interested
parties to join the conference.
As in any real-world application protocol, two factors required an
engineering trade-off: the bandwidth consumed by the announcements
vs. the frequency of announcements. Recall that early internetwork
multicast routing used a dense mode approach; datagrams were flooded
everywhere unless they were explicitly known to be unwanted. Given
the propensity of the entire internetwork multicast infrastructure
to collapse under load, great emphasis was placed on limiting the
total bandwidth consumed by the announcements. Thus, the SAP
announcement frequency was often measured in tens of minutes.
As sparse-mode multicast routing became more widely deployed, this
tens-of-minutes frequency of SAP announcements became a problem.
Each time an SAP announcement was sourced, the sparse-mode source-
based distribution tree would be created towards interested
receivers. But due to the low frequency of each independent
announcement, the distribution tree would have been deemed quiescent
and would be torn down.
The resulting ôbursty sourceö traffic would often follow only the
dense-mode, rate-limited flooding routing plane. The sparse-mode,
higher-performance forwarding plane would assume the source has gone
quiescent long before the next ôburstö.
18. Co-mingled Source Knowledge and Packet Forwarding
ThereÆs a chicken-and-egg problem at the heart of internetwork
multicast routing. On the one hand, experience has shown that a
source-based distribution tree is the most efficient way to forward
datagrams from a source to all interested listeners. On the other
hand, such a source-based distribution tree cannot be created until
the source is known, and RFC 1112 decrees that sources be able to
transmit at any time without warning.
In other words, RFC 1112 defines an active source as a source that
has placed a datagram on the wire. But by the time the datagram has
been placed on the wire, itÆs too late to create a source-based
distribution tree to all interested receivers.
There have been several approaches taken to resolve this problem.
The first was to not use source-based distribution trees at all.
Unfortunately this approach resulted in an internetwork that would
collapse under load.
Meyer,
Nickless (Editors) Informational - Expires January 2002 8
Internet Multicast Gap Analysis July 2002
The second approach has been to create dual routing planes: a dense-
mode plane to forward the initial datagrams from a source, and as a
side effect create a source-based distribution tree in the sparse-
mode plane. Unfortunately these dual routing planes lead to a great
deal of complexity.
The third approach has been SSM: put the burden of spreading the
knowledge of active sources on the application rather than the
network. This approach has two major drawbacks: first, it requires
the replacement or upgrade of edge IEEE 802.x devices to support
IGMPv3 snooping, along with a wholesale upgrade to host operating
systems. Second, it requires applications to develop their own
rendezvous mechanisms.
19. Co-mingled IP and Ethernet Routing
For primarily historical reasons, the IETF has pushed vendors of
nominally IEEE 802.x compliant equipment to also become IPv4-aware
enough to understand the IGMP Version 2 protocol.
IEEE has responded with the GARP/GMRP protocol suite, which are
intended to allow 802.x hosts to control MAC-layer multicast
replication and filtering. However, the IETF has continued work on
IGMP and MLD while ignoring media-specific protocols like GARP/GMRP.
Arguably, this has marginalized IP multicast deployment, especially
IPv6 multicast deployment. Only the very high-end IEEE 802.x
devices have the sophistication to interpret IPv4/IGMP and IPv6/MLD
datagrams.
20. Inter-Domain IP Multicast Exchange Points
Autonomous Systems often wish to exchange traffic. Exchange points
have been developed to meet this demand. One popular type of
exchange point is realized in an 802.x Ethernet switch. Each
participating Autonomous System is provided an 802.x Ethernet port
and an IP address on the exchange point network, to which the
Autonomous System connects a router. Bilateral BGP sessions are
then established between Autonomous Systems across the 802.x network
fabric.
When an Autonomous System router wishes to deliver a unicast
datagram to another Autonomous System router participating at such
an exchange point, it follows this procedure:
- The datagramÆs IP Destination Address is compared to the
Forwarding Information Base (FIB). The FIB returns a so-called
ônext-hopö IP address. This next-hop address is generally
assigned to another Autonomous SystemÆs router at the exchange
point.
Meyer,
Nickless (Editors) Informational - Expires January 2002 9
Internet Multicast Gap Analysis July 2002
- Through the operation of the Address Resolution Protocol (ARP),
the 802.x Ethernet MAC address associated with the next-hop IP
address is determined.
- An Ethernet frame is assembled with the destination MAC address
set to the MAC address determined through ARP, and is transmitted
to the Exchange Point 802.x Ethernet switch.
- The exchange point 802.x Ethernet switch examines the destination
MAC address of the Ethernet frame. Based on that address, the
exchange point switch delivers the Ethernet frame to the
destination Autonomous SystemÆs router.
Consider an analogous procedure for multicast routing. The object
is to graft the Autonomous SystemÆs router onto a source-rooted
distribution tree across the exchange point. Here is one procedure
that a downstream router can follow:
- The downstream router compares the source address to its Multicast
Reachability Information Base (M-RIB). The M-RIB returns the IP
address of an ôupstreamö router across the exchange point.
- Through the operation of the PIM Sparse Mode Protocol, the
downstream router registers interest in that source and group
addresses to the upstream router across the exchange point.
- Upon receipt of a matching datagram for the downstream router, the
upstream router assembles an Ethernet frame and transmits it to
the exchange point 802.x Ethernet switch. As per RFC 1112 or RFC
2464, the destination MAC address of the frame is statically
derived from the destination group address of the datagram.
- The exchange point 802.x Ethernet switch examines the destination
MAC address. As this MAC address is a multicast address, the
802.x Ethernet switch replicates this frame and sends it to all
output ports.
This presents three problems:
First, the multicast traffic is needlessly replicated to all
participants in the exchange point. In the unicast case above, the
802.x Ethernet exchange point switch could use the Ethernet
destination MAC address to uniquely identify which port should
receive a given frame. The static mapping of destination multicast
group address to Ethernet MAC addresses makes that determination
impossible.
Second, the needlessly replicated multicast traffic can trigger the
PIM Assert process, as per RFC 2362 Section 2.9. The PIM Assert
process has been observed to override the policy decisions of
downstream routers in exchange points.
Meyer,
Nickless (Editors) Informational - Expires January 2002 10
Internet Multicast Gap Analysis July 2002
Third, it is impossible for multicast traffic to pass through an
exchange point more than once. Any given exchange point participant
may not have a peering agreement with all other participants,
requiring an intermediate hop through a transit Autonomous System
participant. Due to the operation of ARP this is not a problem for
unicast traffic, but due to the static mapping of multicast groups
to (e.g.) Ethernet MAC addresses, this cannot work.
In summary, it is impossible to support IP multicast at an exchange
point, when that exchange point is based on IEEE 802.3 Ethernet.
21. IP Multicast Architectural Gaps
In general, the IETF focus is on Internet protocols. IGMP snooping
places the requirement of IPv4-awareness on IEEE-standardized 802.x
Ethernet switches. The current drafts for IPv6 MLD seek to extend
that requirement to include IPv6. The IESG would rightfully refuse
to allow IETF working groups to impose such requirements on devices
standardized by organizations outside the IETF (such as IEEE), but
somehow has excepted the IP multicast work from this discipline.
The Internet is more complex than a simple CSMA-style Ethernet
segment, where sources can transmit at any time. Experience clearly
indicates that internetwork multicast datagram forwarding is most
efficiently done by source-rooted distribution trees. Experience
compels revisitation of the assumption that sources should be able
to transmit at any time, yet receive the same level of service as
that provided by a fully instantiated source-rooted distribution
tree.
Registration of soon-to-be-active sources (along the lines of the
unicast Address Resolution Protocol [ARP]) should be seriously
considered.
Part of the registration of soon-to-be-active sources could include
allocation of link-local media-specific multicast addresses, rather
than relying solely on the static mappings defined in RFC 1112 and
RFC 2464.
The static mapping of IP multicast group addresses to media-specific
multicast addresses (in particular, Ethernet) cannot operate
properly at exchange points.
22. Recommendations from MBONED to IESG
The IESG should direct the MAGMA working group to develop a
successor to IGMP/MLD.
- The successor should perform the receiver interest discovery
functions of existing versions of IGMP/MLD, but in addition
should support the registration of active sources.
Meyer,
Nickless (Editors) Informational - Expires January 2002 11
Internet Multicast Gap Analysis July 2002
- At least three modes of operation should be supported. As in
IGMPv2/MLDv1, sources and receivers should be able to transmit
to and receive from group addresses without respect to the
identities of sources. In a second mode, analogous to
IGMPv3/MLDv2, receivers should be able to select the sources
from which they want to receive traffic for a particular group.
A third mode should permit receivers to select the source
address, group address, and upstream gateway from which to
receive traffic.
- The successor should be media-agnostic. Media-specific
multicast addresses should be treated as opaque handles.
Examples of media-specific multicast addresses might include
802.x MAC addresses, ATM Forum NSAP point-to-multipoint
addresses, etc.
- Adaptation layers for this successor protocol should be
developed to use media-specific mechanisms for multicast
transport and replication. For example, the IEEE 802.1p
GARP/GMRP protocol should be used on Ethernet. ATM Forum UNI
point-to-multipoint signaling should be used on ATM networks
(c.f. RFC 2022).
- This successor protocol would provide for the dynamic assignment
of media-specific addresses. As necessary, the media address
assignment mechanism might control the creation and maintenance
of media-specific intra-subnet distribution mechanisms, such as
ATM point-to-multipoint switched virtual circuits. When in
operation on an IEEE 802.3 Ethernet, this mechanism would
supercede RFC 1112 Section 6.4 and RFC 2464 Section 7.
- The first application for this successor protocol would be at
public internetwork exchange points. The third mode of
operation (allowing receivers to select the source address,
group address, and upstream gateway) would allow participants at
exchange points to select their upstream neighbor towards a
source based on explicit policy, rather than the vagaries of the
PIM Assert mechanisms.
- This successor protocol may not be applicable for IP datagrams
with TTL=1, so as to preserve semantics for link-local
rendezvous (e.g. OSPF). Likewise, it may not be applicable for
IPv6 RFC 2375 scopes 0, 1, and 2.
The IESG should encourage the development of a protocol to spread
the knowledge of active sources to interested gateways. Given a
successor to IGMP that supports the registration of active sources,
this spreading of knowledge can happen independently of actual
multicast datagram forwarding.
The IESG should discourage any further work on IGMP or MLD snooping,
as implemented by otherwise nominally IEEE 802 compliant equipment.
Meyer,
Nickless (Editors) Informational - Expires January 2002 12
Internet Multicast Gap Analysis July 2002
Instead, the IESG should encourage the use of GARP/GMRP on IEEE 802
networks.
The IESG should guide protocols that use IP multicast to maintain a
minimum frequency of datagram transmission, so as to preserve
source-based forwarding trees.
23. Acknowledgements
This work was supported by the Mathematical, Information, and
Computational Sciences Division subprogram of the Office of Advanced
Scientific Computing Research, U.S. Department of Energy, under
Contract W-31-109-Eng-38.
24. Security Considerations
Security considerations are not yet discussed in this draft memo.
Meyer,
Nickless (Editors) Informational - Expires January 2002 13
Internet Multicast Gap Analysis July 2002
25. References
Most of the references are called out in-line. This section will be
completed more fully before final publication.
1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
26. EditorsÆ Addresses
David Meyer Email: dmm@sprint.net
Bill Nickless
Argonne National Laboratory
9700 South Cass Avenue #221 Phone: +1 630 252 7390
Argonne, IL 60439 Email: nickless@mcs.anl.gov
Meyer,
Nickless (Editors) Informational - Expires January 2002 14
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/