Current Meeting Report
2.3.9 Multicast & Anycast Group Membership (magma)
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.
Last Modifield: 05/30/2002
Bill Fenner <email@example.com>
Brian Haberman <firstname.lastname@example.org>
Internet Area Director(s):
Thomas Narten <email@example.com>
Erik Nordmark <firstname.lastname@example.org>
Internet Area Advisor:
Erik Nordmark <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
In Body: subscribe
Description of Working Group:
Group management protocols are crucial to the operation of multicast
within the Internet, and there are some benefits in extending group
management protocols to also be able to support anycast. These
protocols allow hosts to inform routers of their membership status
within groups. This working group will be responsible for developing
the functionalities required for group membership reporting and other
related actions. This group will also address the initial
authentication and access control issues associated with anycast group
membership; this is likely to be limited to shared secrets and message
authentication codes (MACs) much like current routing protocol
security. Other aspects of Anycast, including architecture and
routing, are outside the groups scope.
The draft names listed below are the starting point for the work in the
MAGMA specifications will include:
- Core IGMPv3/MLDv2 specifications. These specifications will describe
the protocol used between hosts and routers to share group membership
information. IGMPv3 and MLDv2 build on IGMPv2 and MLDv1 by adding
two types of source-specific filtering; "include" (in which the
system tells the router exactly which sources it desires) and
"exclude" (in which the system tells the router that it does *not*
desire a list of sources).
- IGMPv3: The IDMR working group has submitted this for Proposed
MAGMA takes ownership after publication as RFC.
- MLDv2: draft-vida-mld-v2-00.txt
- Multicast Source Filtering API. This specification describes the API
used to interact with IGMPv3 and MLDv2 to indicate source filters.
- Host determination of network group membership. In a multicast
environment, systems may be interested in learning whether or not
there are any group members, in order to save the trouble of sending
data that nobody is listening to.
- Multicast Source Notification of Interest Protocol:
- Multicast forwarding in tree topologies using IGMP/MLD Proxying
- Create a single document from:
- Source-Specific Multicast (SSM) consideration document. This work
will describe the use of IGMPv3/MLDv2 in an SSM environment.
- Considerations for "IGMP snooping" switches (switches that watch IGMP
exchanges in order to determine multicast forwarding behavior)
- Multicast Router Discovery: The IDMR working group has submitted this
for Proposed Standard. MAGMA takes ownership after publication as
- Snooping Considerations: draft-ietf-idmr-snoop-00.txt
- Group management MIBs
- update RFC 2933 for IGMPv3
- update RFC 3019 for MLDv2
- Interaction between IGMP/MLD and routing protocols
- Extensions to MLD supporting anycast group memberships including
authentication and access control mechanisms
In addition, this working group will coordinate with other IETF working
groups where multicast and anycast group management protocols are
utilized as well as coordinating with the Multicast Security WG.
Goals and Milestones:
|AUG 01|| ||Submit SSM considerations for IGMPv3 specification as
Proposed Standard. |
|DEC 01|| ||Submit IGMPv3 Interactions with routing protocols document
as Informational. |
|DEC 01|| ||Submit MLDv2 specification as Proposed Standard. |
|DEC 01|| ||Submit IGMP Snooping Considerations document as
|DEC 01|| ||Submit Extensions to MLD for Anycast as Proposed Standard. |
|DEC 01|| ||Submit Mixed-version IGMP Proxying as Proposed Standard. |
|DEC 01|| ||Submit Multicast Source Filtering API as Informational |
|DEC 01|| ||Submit SSM considerations for MLD specification as Proposed
|MAR 02|| ||Submit IGMPv3 MIB as Proposed Standard. |
|MAR 02|| ||Submit MSNIP for IPv4 specification as Proposed Standard. |
|MAR 02|| ||Submit MLDv2 MIB as Proposed Standard. |
|MAR 02|| ||Submit MLD Snooping Considerations document as
|MAR 02|| ||Submit MSNIP for IPv6 specification as Proposed Standard. |
|MAR 02|| ||Submit MLDv2 Interactions with routing protocols document
as Informational. |
|MAR 02|| ||Submit MLD Proxying specification as Proposed Standard. |
Request For Comments:
|RFC3228||BCP||IANA Considerations for IGMP|
Current Meeting Report
Q = Question
A = Answer
C = Comment
Ready for last call: MLD version 2
Multicast source filtering API
...and will send out last call after the IETF meeting.
draft-ietf-magma-mrdssm-00.txt is out of charter, but published in this working
group anyway. Oops. Holdover from IDMR.
Reflect IGMPv3 source filtering changes (INCLUDE/EXCLUDE)
Source list table added
Filter mode object in Cache table added (INCLUDE/EXCLUDE)
IGMPv2 host and querier timers
Combine MLDv2 and IGMPv3 MIBs?
Toerless Eckert: MIB does not allow for explicit tracking of state. Proposed
including "explicit tracking" related objects as optional MIB variables.
Bill Fenner : Neither does the underlying IGMP spec, and IGMP spec does not
require explicit tracking.
Goals: Control multicast receivers and sources
Protection against DoS
Centralized policy tool
No mods to IGMP/MLD
No mods to core routers
Independent of multicast routing protocol
Strategy: MCOP-enabled first-hop multicast router applies policy based on MCA
(Multicast Control Agent) definition and management.
Dave Thaler Q: Clarify goals & requirements? What is the threat you're trying to
A: Protecting against DoS on the routed infrastructure, not on the local
C: Please reword goal to be more specific.
Q: Did not see anything that the host had to do. Is that right? If so, very
C: Yes, nothing like that required.
Q: If you have an MCA doesn't control a range, it's probably not useful to
protect against DoS attacks.
C: Would also like to see more detail on attacks to be protected against.
Q: Underlying assumption: is the full ACL too large or too dynamic to push down
into the router? Why use the MCA rather than putting it into the router
C: If that's assumption, please state as part of applicability domain.
C: Bursty source problem; can drop first or early packets in a burst while the
MCA response is created. Please state.
C: Easiest way to notify may be to respond to IGMP or MLD, but concur that end
nodes should be notified.
C: May be more appropriate for MSEC working group.
Eric Youngmark Q: Could use more detail about attacks the draft is trying to
A: If interest, yes can.
Bill Fenner Q: Have you thought about using Diameter instead of special
Q: Inter-domain or not? Multiple servers across different ASes?
A: Intra-domain focus, inside one AS. Can control local senders and receivers,
even if the groups are Internet-wide.
Q: You have to worry about same-subnet traffic.
A: Yes, need to use some other mechanism.
C: Talk to MSEC. Add more info on why not use more general management framework.
Toerless Eckert C: Would like to see stronger reasoning why some other
management protocol is not being used, as multicast-specific protocols are hard
C: IGMP snooping switches may also require such policy control.
Bill Fenner: C: Would like to see ability for source/receiver to discover that
Ketan Talaulikar: Q: Consider hierarchical MCA?
A: Did consider, but not easy, especially cross-domain.
C: Looks more like policy protocol.
IP Multicast Metrics
Needed for: designing multicast tree inside network
accounting for multicast service
controlling inter-domain service performance
Measure hop-by-hop delay, hop-to-hop sequence, end-to-end delay, loss, source to
listeners average delay.
Reporting of listener numbers.
SNMP Trap to setup measurement and to report on the fly.
Mark Olivier Q: Test packet is part of the same group?
A: Yes, but you can use any group you want.
Q: That means each element that needs to be part of the test, will need to
inspect each packet to see if it's part of the test?
A: It will not receive the packet if it has not joined the group.
C: This will probably have forwarding performance impact.
Q: How do you measure loss? Your test packet may not follow the same path
especially if it builds the tree.
A: Use a sequence number in the measurement packet, and set the number of times
to repeat the test packet.
C: Need to discuss this question in more detail offline.
Bill Fenner Q: Do you require synchronized clocks?
A: Yes, and that's doable.
C: Although there are a number of multicast experts in this group, it's probably
not the right group for multicast measurement.
Perhaps MBONED? Would encourage this work.
MAGMA Milestones Update
We've missed all our milestones so it's time to rewrite them!
Original thought was to finish the IPv4 stuff first, and then work on the IPv6
stuff later. However, some of the IPv6 stuff is creeping in already, so intent
is to require IPv4 and IPv6 applicability for each draft.
Are the requirements for IPv6 ASM going away?
Dave Thaler: should not remove IPv6 ASM from the charter, but it can be a very
low priority and the last work item.
Measuring the performance of multicast services
Multicast Control Protocol (MCOP)
GMP MIB Extensions
- Rami Lehtonen
- Jyrki Soini
- Heikki Vatiainen
- Juha Majalainen