TOC 
mbonedT. Morin, Ed.
Internet-DraftFrance Telecom - Orange Labs
Intended status: ExperimentalB. Haberman
Expires: May 7, 2009The Johns Hopkins University,
 Applied Physics Laboratory
 November 03, 2008


IGMP/MLD Error Feedback
draft-morin-mboned-igmpmld-error-feedback-02

Status of this Memo

By submitting this Internet-Draft, each 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

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.

This Internet-Draft will expire on May 7, 2009.

Abstract

This document describes messages and procedures that can optionally be implemented in IGMP/MLD Queriers and Hosts, to provide information to multicast receivers on the reason why the IGMP/MLD Querier didn't take into account a Membership Report message.

Requirements Language

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].



Table of Contents

1.  Introduction
2.  Terminology
3.  History and problem statement
4.  Principle
5.  Procedures
    5.1.  Procedures on the IGMP/MLD Querier
    5.2.  Procedures on the IGMP/MLD Host
6.  Message encodings
    6.1.  Feedback message
    6.2.  Error codes
7.  Feedback to the application layer
8.  Impact on IGMP/MLD proxies and equipments doing IGMP/MLD snooping
    8.1.  IGMP/MLD Proxies
    8.2.  Equipments doing IGMP/MLD snooping
9.  IGMP/MLD Hosts stacks not implementing the Feedback mechanism
10.  IANA Considerations
11.  Security Considerations
12.  Acknowledgements
13.  References
    13.1.  Normative References
    13.2.  Informative References
Appendix A.  Protocol to carry error feedback messages
    A.1.  ICMP
    A.2.  IGMP/MLD
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

Requirements have been formulated for means to provide multicast receivers with error feedback when the IGMP/MLD Querier did not or could not process an IGMP/MLD Membership Report message ([I‑D.ietf‑mboned‑maccnt‑req] (He, H., “Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s),” October 2007.), section 4). Operator's experience with IPTV deployments show that introducing such a feedback in IGMP exchanges between multicast receivers and multicast routing equipments would help provide a better service (e.g. a liaison between the IETF mboned working group and the DSLForum was made in December 2005 to discuss this issue, but didn't lead to a standardized solution).

An examples case is when an IGMP Querier refuses to take into account an IGMP Membership Report because the number of multicast channels would surpass the allowed threshold for the service. Many other examples of the case where an IGMP error feedback channel would be useful are presented in Section 6.2 (Error codes).

This document describes new message encodings and the associated procedures, all of which being optional and preserving full backward and forward compatibility, and details the impact on the host API for multicast subscriptions.

This document doesn't state yet whether the messages should be carried over IGMP, ICMP or another protocol, but tries to document the pros and cons of the different alternatives, to guide the decision process.



 TOC 

2.  Terminology

The terminology in this document is the terminology used in [RFC3376] (Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” October 2002.) and [RFC3810] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.).

For readability, "Querier" and "Host(s)" will be used throughout this document, in place of "IGMP or MLD Querier" and "IGMP or MLD Host(s)".



 TOC 

3.  History and problem statement

The DSLForum expressed interest for such a feature, which was discussed (, “IETF Magma WG mailing-list archives,” December 2005.) [magma‑archive] in a liaison with the Magma IETF Working group. The specifications described in this document try to address the comments exchanged on the magma WG mailing-list.



 TOC 

4.  Principle

The procedures described in this memo are fully optional : their only intent is to carry informative data from the Querier to the Hosts.

Most specifically, the intent is that:

Last, these specifications are not meant to carry information about transient errors that the network is supposed to recover from, like network outages.



 TOC 

5.  Procedures



 TOC 

5.1.  Procedures on the IGMP/MLD Querier

The following procedures introduce a new type of message : the Feedback message. See section Section 6 (Message encodings) for details about message encodings.

Using these procedures a Querier can OPTIONALLY emmit a Feedback message after receiving an IGMP or MLD Membership Report message that it can not process (see Section 6.2 (Error codes) for example reasons on why a Querier would not process a Membership Report message).

The Feedback message carries error type/sub-type field, and information about the group to which the error pertains. Optionally, if IGMPv3/MLDv2 is used, and if the error message pertains to some specific sources, the addresses of the sources to which the error pertains are included in the message.

The address to which the Feedback message will be sent is determined as follows:

The source address MUST be the same address as the address used for Query messages, and the TTL MUST be set to 1.

If IGMPv2/MLDv1 is being used, not more than one Feedback message should be sent for a said Membership Report message.

If IGMPv3/MLDv2 is being used, not more than one Feedback message should be sent for each (S,G) pair present in the Membership Report message. Multiple feedback message MAY be sent if the group record in error contains multiple source addresses. Multiple feedback message SHOULD be sent if the relevant error codes are different for the sources/groups of the Report message.

In any case the amount of Feedback messages sent on a link MUST be rate-limited.



 TOC 

5.2.  Procedures on the IGMP/MLD Host

When a Host receives an Feedback message, it MAY process it.

Processing a Feedback message consists in :



 TOC 

6.  Message encodings



 TOC 

6.1.  Feedback message

The Feedback message is a subtype of IGMP message when used as a feedback to an IGMP message, and a subtype of ICMPv6 when used as a feedback to an MLD message. It contains an error code, the multicast group address in error (optional), and the source addresses in error (optional).

The encoding is common to the two types of messages (except the length of fields specifying addresses).

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = XXX    | Code          | Checksum                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Reserved            |  Number of Group Records (M)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                        Group Record [1]                       .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                        Group Record [2]                       .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
.                               .                               .
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                        Group Record [M]                       .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields:

Type:
Identifies this message as a Feedback message. Currently using:
  • in the case of IPv6/MLD: 0xYY (currently using value 200 as defined in RFC 4443 "private experimentation value", until another value is registered with IANA).
  • in the case of IPv4/IGMP: 0xZZ (currently using 0xF2, in the "Reserved for experimentation" range, until another value is registered with IANA)
Code:
One byte, gives additional information about the error that triggered the feedback message. The possible values are described in Section 6.2 (Error codes).
Checksum:
The standard IGMP checksum.
Reserved:
Reserved for future use. Set to zero on transmission; ignored upon receipt.
Number of Group Records:
Indicates the number of group records.

The Feedback message MUST at least include one group record.

It MUST NOT include more than one group record if the Feedback message is to be sent toward a multicast group address (see section Section 5 (Procedures)).

Group record encoding:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Multicast Group Address                    |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved                      |     Number of Sources (N)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address [1]                      |
~                                                               ~
+---                                                         ---+
|                       Source Address [2]                      |
~                                                               ~
+---                                                         ---+
.                               .                               .
.                               .                               .
~                                                               ~
+---                                                         ---+
|                       Source Address [N]                      |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fields:

Multicast Group Address:
IPv4 multicast group address of the group in error. Possibly set to all zeros. Contains an IPv4 address in the case of IPv4/IGMP, and an IPv6 address in the case of IPv6/MLD.
Reserved:
Reserved for future use. Set to zero on transmission; ignored upon receipt.
Number of Sources:
Indicates the number of sources in error. Possibly set to zero.
Source Address [1..n]:
Addresses of the multicast sources in error. In the case of IPv4/IGMP, all these fields are 32-bit fields containing IPv4 addresses. In the case of IPv6/MLD, all these fields are 128-bit fields containing IPv6 addresses.

The Multicast Group Address field MAY be set to all zeros (for instance, if the error is not specific to a said multicast group).

A group record MAY include zero Source Address (it can be the case, for instance, for a feedback that is not specific to particular sources, or that relates to an ASM subscription). It MUST NOT include any source in the following cases:



 TOC 

6.2.  Error codes

This section describes some proposed error codes:

0x01:
improper message : the Membership Report message is improper (the group address is not in the 224/0 or FF00::/8 range, or specified sources are improper addresses)
0x02:
The IGMP or MLD version of the Report message is not supported by querier
0x03:
wildcard on an SSM group : IGMPv2 or IGMPv3/MLDv2 with an Exclude source filter mode was used in the Report, but the group address is not in the SSM range of the Querier
0x04:
exclude source filter mode not supported by the Querier
0x05:
group administratively prohibited
0x06:
source(s) administratively prohibited
0x07:
a resource limit was reached
0x08:
multicast reception is disabled on the link
0x09:
multicast routing protocol issue

Remember that the Feedback message is NOT meant to carry information about transient errors that the network is supposed to recover from, like for instance network outages.



 TOC 

7.  Feedback to the application layer

This section gives an example of how the information from Feedback messages is supplied to applications subscribed to multicast streams, and which expect the reception of multicast datagrams on a socket, based on Linux extensions to the POSIX (ISO, “ISO/IEC 9945 Information technology, Portable Operating System Interface (POSIX), Part 1: Base Definitions,” 2003.) [posix] network socket API.

A first requirement is full backward compatibility with applications not supporting these specifications : an application not supporting these specifications must not be affected by a Feedback message. For instance, a wrong solution would be to return an error on a read() or recv() call.

A second requirement is to allow an application to keep receiving data on a socket, even if some error was reported through a Feedback message, for a group or channel joined on this socket. This is needed, for instance, in two cases : when a socket is used to join multiple distinct group or channels and only one of them is subject to an error ; when a socket is used to join only one multicast group, for which the Querier sends a Feedback message, but there are members for this group sending data on a directly connected link.

The proposed solution is to rely on the use of the MSG_ERRQUEUE flag of the recvmsg()/recvfrom() POSIX calls. This call allows the socket user to retrieve the network errors queued for the socket.

The MLD component receiving an MLD Feedback message containing error condition reports the error to the application via the MSG_ERRQUEUE flag in the recvmsg()/recvfrom() calls. The MSG_ERRQUEUE flag indicates the presence of a sock_extended_err data structure. When the sock_extended_err data structure is passed to the application, the ee_origin field is set to 3 (SO_EE_ORIGIN_ICMP6) in the case of an MLD Feedback message, and XX (SO_EE_ORIGIN_YYYY) in the case of an IGMP Feedback message [XX and YYY is to be determined in compliance with the relevant standard, 4 and SO_EE_ORIGIN_IGMP are proposed as interim values]. The Type and Code fields from the MLD Feedback message are copied into the ee_type and ee_code field of the sock_extended_err data structure.

The addresses of the multicast group and sources in error can be retrieved as follows:

If the Feedback contains multiple sources addresses, a sock_extended_err will be added to the message queue for each such sources.

An application receiving a sock_extended_err message from the MLD component MUST NOT terminate the multicast subscription to the group or source/group address in error, except possibly if it can be ascertained that the Feedback message comes from a legitimate Querier (e.g. thanks to a mechanism like SEND (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) [RFC3971]), and if multicast traffic for the said group or channel is not expected from any host attached to a directly-connected link.

( Another proposal would be to allow the setsockopt() and set(ipv4)sourcefilter() calls [RFC3678] (Thaler, D., Fenner, B., and B. Quinn, “Socket Interface Extensions for Multicast Source Filters,” January 2004.) to return an error. That would require the local network stack to wait for some time after sending a Membership Report message, before being able to return from the setsockopt()/set(ipv4)sourcefilter() call, and would not easily allow to carry detailed information about the specific group or channel in error. Consequently, this approach doesn't seem a viable one. )



 TOC 

8.  Impact on IGMP/MLD proxies and equipments doing IGMP/MLD snooping



 TOC 

8.1.  IGMP/MLD Proxies

To support this Feedback mechanism, an IGMP or MLD proxy (Fenner, B., He, H., Haberman, B., and H. Sandick, “Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying"),” August 2006.) [RFC4605] SHOULD send Feedback messages received on its Host side toward its Querier side(s) that have matching multicast memberships. The procedures for sending the Feedback messages are then the same as for a normal Querier, as specified in Section 5 (Procedures): in particular the IGMP/MLD proxy MUST use its own address as the source address of the Feedback message.

A new member of a multicast group already forwarded by the proxy on its Querier side, will have to wait for some time before having a chance to receive a Feedback message : timers will have to trigger before the Querier on the Host side of the proxy sends a Query, causing the proxy to send a Membership Report that may then cause the Querier on the Host side to send a Feedback message, and this Feedback message to be propagated to the new receiver.

To quickly provide Feedback messages to receivers on its Querier side, the proxy MAY cache the information in the Feedback messages that it receives on the Host side, so that it can later reuse this information to eventually send feedback to Membership Report messages received on its Querier side. When such Feedback information caching is used, the proxy MUST keep only one Feedback message per (S,G) entry or (*,G) entry. On reception of a Report message on its Querier side, it shall then lookup in its cache the most relevant feedback information. A Feedback information MUST be removed from the cache if no Feedback message containing it is received by the Querier on its Host side interface, <n> seconds after a corresponding Report was sent.

Last, an IGMP/MLD proxy MAY produce its own Feedback messages. In that case it MUST still respect procedures of Section 5 (Procedures).



 TOC 

8.2.  Equipments doing IGMP/MLD snooping

IGMP/MLD snooping equipments are expected to transparently interoperate with the procedures described in this document, given that RFC 4541 section 2.2.1(3) (Christensen, M., Kimball, K., and F. Solensky, “Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches,” May 2006.) [RFC4541] states that "[a] switch that supports IGMP snooping must flood all unrecognized IGMP messages to all other ports".



 TOC 

9.  IGMP/MLD Hosts stacks not implementing the Feedback mechanism

To allow applications running on an IGMP/MLD Host, whose networking stack or API does not implement the Feedback mechanism described in this spec, it is proposed that IGMP/MLD Querier implementing this specification can, when configured to do so, send each Feedback message twice : once with the encoding described in these specifications, and another time encapsulated in a UDP packet.

The UDP message uses port xxx [TBD], with a payload identical to the IGMP or MLD Feedback message, except that the checksum is set to zero (the UDP message having its own checksum). The message is sent to the welknown link local multicast group adress 224.0.0.z [TBD], so that reception by multiple applications running on a same host is possible. The TTL used MUST be one.



 TOC 

10.  IANA Considerations

Request to IANA for IGMP and ICMPv6 type allocation will be needed for the messages defined in this document.

Request to IANA for a UDP port and a link local multicast group address will be needed.

[Whether or not it is needed to define a registry for the error codes used in IGMP/MLD Feedback messages will be later determined.]

[Note to RFC Editor: this section may be removed on publication as an RFC.]



 TOC 

11.  Security Considerations

Given that the specifications in this document do not change nor the state machine of the IGMP/MDLD Querier and Host stack, nor the datagrams that will be received by an application, they are not expected to introduce security issues not already existing with IGMP/MLD or the protocol used to carry the Feedback message.

A possible issue would be to have wrong feedback sent toward multicast applications. Such an issue could arise if spoofed Feedback messages are sent and interpreted by multicast receiver hosts. This issue is mitigated by the fact that IGMP/MLD Hosts MUST check that the TTL of the Feedback messages is 1.

The case where such a verification does not protect from spoofing is the case of LANs. In that case, spoofing is typically hard to prevent and some level of trust in other hosts present on a LAN is required. Checking that the source IP of the Feedback message against a list of known Queriers can be minor an improvement in these contexts.

Another possible issue is denial of service of the Querier function, that would be due to having the IGMP/MLD Querier be overloaded by Feedback messages to send. This is mitigated by allowing the Querier to rate-limit the flow of Feedback messages. On a LAN, such a rate-limiting would possibly result in some receivers not receiving the feedback message that they would have, which is a form of denial of service, but only on the Feedback function by itself, with no impact on the rest of the multicast group membership control protocol infrastructure. This later type of denial of service might be mitigated by doing rate-limiting based on the source address of the receivers (the source address of the Membership Report triggering the Feedback message); but such mechanism may themselves be subject to weaknesses due to Membership Report spoofing.



 TOC 

12.  Acknowledgements

Acknowledgments go to DSLForum contributors who provided an initial proposal, to IETF participants that participated in the discussion on the magma WG list, from which guidance and inspiration was largely taken. Thank you to Bill Fenner for providing detailed information on issues related to ICMP errors in reaction to multicast datagrams.

Thanks to Toerless Eckert for his inputs and who offered a suggestion on how to handle application running on hosts not implementing the Feedback mechanism.

Message encodings are largely inspired from Report message encodings found in[RFC3376] (Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” October 2002.).



 TOC 

13.  References



 TOC 

13.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” RFC 3376, October 2002 (TXT).
[RFC3678] Thaler, D., Fenner, B., and B. Quinn, “Socket Interface Extensions for Multicast Source Filters,” RFC 3678, January 2004 (TXT).
[RFC3810] Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” RFC 3810, June 2004 (TXT).
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, “Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches,” RFC 4541, May 2006 (TXT).
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, “Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying"),” RFC 4605, August 2006 (TXT).


 TOC 

13.2. Informative References

[I-D.ietf-mboned-maccnt-req] He, H., “Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s),” draft-ietf-mboned-maccnt-req-05 (work in progress), October 2007 (TXT).
[RFC1122] Braden, R., “Requirements for Internet Hosts - Communication Layers,” STD 3, RFC 1122, October 1989 (TXT).
[RFC1812] Baker, F., “Requirements for IP Version 4 Routers,” RFC 1812, June 1995 (TXT).
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” RFC 3971, March 2005 (TXT).
[fenner-icmp-mcast] ICMP errors in response to multicast,” March 1999.
[magma-archive] IETF Magma WG mailing-list archives,” December 2005.
[posix] ISO, “ISO/IEC 9945 Information technology, Portable Operating System Interface (POSIX), Part 1: Base Definitions,” 2003.


 TOC 

Appendix A.  Protocol to carry error feedback messages

ICMP and IGMP/MLD were possible candidates for carrying the Feedback message. This section exposes the pros/cons of both alternatives, and ought to be removed once a decision is made on one of them.



 TOC 

A.1.  ICMP

The Feedback message could be an ICMP message that would use a new ICMP message type (or possibly reusing existing types and codes).

Pros:

Cons:



 TOC 

A.2.  IGMP/MLD

The Feedback message could be an IGMP or MLD message that would use new IGMP/MLD message types.

Pros:

Cons:



 TOC 

Authors' Addresses

  Thomas Morin (editor)
  France Telecom - Orange Labs
  2, avenue Pierre Marzin
  Lannion 22307
  France
Email:  thomas.morin@orange-ftgroup.com
  
  Brian Haberman
  The Johns Hopkins University, Applied Physics Laboratory
  11100 Johns Hopkins Road
  Laurel, MD 20723-6099
  US
Phone:  +1 443 778 1319
Email:  brian@innovationslab.net


 TOC 

Full Copyright Statement

Intellectual Property