One document matched: draft-morin-mboned-igmpmld-error-feedback-00.txt
mboned T. Morin
Internet-Draft France Telecom - Orange Labs
Intended status: Experimental November 12, 2007
Expires: May 15, 2008
IGMP/MLD Error Feedback
draft-morin-mboned-igmpmld-error-feedback-00
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 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes messages and procedures that can optionnaly
be implemented in IGMP/MLD Queriers and Hosts, to provide information
to terminals 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",
Morin Expires May 15, 2008 [Page 1]
Internet-Draft IGMP/MLD Error Feedback November 2007
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. History and problem statement . . . . . . . . . . . . . . . . 3
4. Principle . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Procedures on the IGMP/MLD Querier . . . . . . . . . . . . 4
5.2. Procedures on the IGMP/MLD Host . . . . . . . . . . . . . 5
6. Message encoding . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Base encoding . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Protocol to carry error feedback messages . . . . . . . . 6
6.2.1. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2.2. IGMP/MLD . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Error codes . . . . . . . . . . . . . . . . . . . . . . . 7
7. Feedback to the application layer . . . . . . . . . . . . . . 8
8. Impact on IGMP/MLD proxies and equipments doing IGMP/MLD
snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. IGMP/MLD Proxies . . . . . . . . . . . . . . . . . . . . . 9
8.2. Equipments doing IGMP/MLD snooping . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Morin Expires May 15, 2008 [Page 2]
Internet-Draft IGMP/MLD Error Feedback November 2007
1. Introduction
Requirements have been formulated for means to provide mutticast
terminals 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], section 4). Operator's experience
with IPTV deployments show that introducing such a feedback in IGMP
exhanges between terminals and multicast access 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 outpass 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.3.
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.
2. Terminology
The terminology in this document is the terminology used in [RFC3376]
and [RFC3810].
For readability, "Querier" and "Host(s)" will be used thoughout this
document, in place of "IGMP or MLD Querier" and "IGMP or MLD
Host(s)".
3. History and problem statement
The DSLForum expressed interest for such a feature, which was
discussed [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.
Morin Expires May 15, 2008 [Page 3]
Internet-Draft IGMP/MLD Error Feedback November 2007
4. Principle
The procedures described in this memo are fully optionnal : their
only intent is to carry informative data from the IGMP/MLD Querier to
the IGMP/MLD Hosts.
Most specifically, the intent is that:
o the procedures don't change the state machine of the IGMP Querier
or IGMP Host, the information carried is only meant to provide
information to the application subscribed to multicast data
o an IGMP Host implementing these specifications will behave
correctly in the absence of these informations.
o the behavior of an IGMP Querier implementing these specifications
is unchanged whether or not the hosts implement these specs.
Last, these specifications are not meant to carry information about
transient errors that the network is supposed to recover from, like
network outages.
5. Procedures
5.1. Procedures on the IGMP/MLD Querier
The following procedures introduce a new type of message : the
Feedback message. See section xxx for details about message
encodings.
Using these procedures a Querier can optionally emmit a Feedback
message after receiving a Membership Report message that it can not
process (see Section 6.3 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:
o if IGMPv3/MLDv2 is used and if the sender IP address is not
0.0.0.0 or 0000::/32, the address of sender of the IGMP Membership
Report is used
Morin Expires May 15, 2008 [Page 4]
Internet-Draft IGMP/MLD Error Feedback November 2007
o else, the group address that was mentioned in the Membership
Report message is used
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, only one feedback message should be
sent for a said Membership Report message.
If IGMPv3/MLDv2 is being used, only one feedback message should be
sent for each (S,G) in the Membership Report message.
In any case the amount of Feedback messages sent on a link MUST be
rate-limited,
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 :
o MANDATORY checking that the TTL is set to 1
o OPTIONALLY checking that the message source address is the address
of a known Querier
o parsing the Feedback message
o determining the network sockets for which the Feedback message is
relevant (G is the group address of the Feedback message)
* if no source address is included in the Feedback message, the
sockets are the sockets that have some active forwarding state
related to G (subscribed to G with a non-null include list)
* if some source addresses are indicated in the Feedback message,
the sockets are the sockets to which traffic from at least one
of these sources, and toward G, would be forwarded
o notifying these sockets of the error (see Section 7)
o OPTIONALLY logging the error and/or doing any local action
depending on policy
Morin Expires May 15, 2008 [Page 5]
Internet-Draft IGMP/MLD Error Feedback November 2007
6. Message encoding
This document currently only proposes a base encoding for the
Feedback message. Discussion is left open on the protocol on which
these messages should be piggybacked on, though ICMP and IGMP/MLD are
natural candidates. The definitive choice and exact detailed
encodings will be detailed in a later revision.
6.1. Base encoding
Encoding of the error feedback message type, is as follows:
o error type (1 byte)
o error sub-type (1 bytes)
o group address (field length depends on IP protocol revision used)
o number of sources in error (possibly zero), followed by the source
addresses in error (possibly none, field length depends on IP
protocol revision used and number of sources)
[ nice ASCII-art might be considered for future revisions ]
6.2. Protocol to carry error feedback messages
ICMP and IGMP/MLD are candidates for carrying the error 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.
6.2.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:
o ICMP is already used to carry error messages between routers and
hosts (e.g.. port unreachable message)
o ICMP has an extensible format which could easily be reused for the
Feedback function described in this memo
o Implementations of network socket APIs already take into account
ICMP messages
Cons:
Morin Expires May 15, 2008 [Page 6]
Internet-Draft IGMP/MLD Error Feedback November 2007
o ICMP has currently nothing to do with multicast today
o some RFC explicitly forbid the sending of ICMP in reaction to
receiving multicast packets, and IGMP/MLD Membership Reports are
multicast packets ([RFC1122] section 7.2 and 3.2.2, [RFC1812]
section 4.3.2.7) (see [fenner-icmp-mcast]).
o ICMP messages are (currently) never sent toward multicast
addresses, whereas that would be required to send Feedback
messages to IGMPv2/MLDv1 hosts
6.2.2. IGMP/MLD
The Feedback message could be an IGMP or MLD message that would use
new IGMP/MLD message types.
Pros:
o IGMP and MLD are the protocols used for all operations related to
multicast subscription
Cons:
o possibly more work to define the encodings
o a new IANA registry might be needed to manage Feedback error codes
o definition of how the network socket API will be used to carry the
information to the applications has to be defined
6.3. Error codes
This section describes some proposed based error types:
o 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)
o IGMP version not supported by querier
o wildcard on an SSM group : IGMPv2 or IGMPv3/MLDv2 with Exclude
source filter mode was asked, but the group address is not in the
SSM range of the Querier
o exclude source filter mode not supported by the Querier
o group administratively prohibited
Morin Expires May 15, 2008 [Page 7]
Internet-Draft IGMP/MLD Error Feedback November 2007
o source(s) administratively prohibited
o resource limit reached
o multicast reception is disabled on the link
[ This section will later be completed to include error type numbers
]
Remind 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.
An IANA registry may be required to manage these and future error
codes, and provide third party with the ability to define error codes
for IGMP/MLD error feedback.
7. Feedback to the application layer
[ TBC : working group guidance is sought on how to link these
specifications with possibly needed evolution of the POSIX [posix]
network socket API ]
This section describes how the information from Feedback messages is
supplied to applications subscribed to multicast stream, and
expecting the reception of multicast datagrams on a socket.
A requirement is fully 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.
A proposal 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. Further work
is required to fully describe how information from the Feedback
message would be mapped in the sock_extended_err structure.
Morin Expires May 15, 2008 [Page 8]
Internet-Draft IGMP/MLD Error Feedback November 2007
Another proposal would be to allow the setsockopt() and
set(ipv4)sourcefilter() calls [RFC3678] 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.
8. Impact on IGMP/MLD proxies and equipments doing IGMP/MLD snooping
8.1. IGMP/MLD Proxies
To support this Feedback mechanism, an IGMP or MLD proxy [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: 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 Feedback messages that it receives on
the Host side to later match them with Membership Report messages
received on its Querier side, and send relevant Feedback messages in
reaction to these. If doing Feedback message caching, the proxy MUST
keep only one Feedback message per (S,G) entry or (*,G) entry. It
MUST also remove a Feedback message from its cache, if a same
Feedback message hasn't been sent in the last <> seconds by the
Querier on its Host side.
Last, an IGMP/MLD proxy MAY produce its own Feedback messages. In
that case it MUST still respect procedures of Section 5.
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) [RFC4541] states that "[a] switch that
Morin Expires May 15, 2008 [Page 9]
Internet-Draft IGMP/MLD Error Feedback November 2007
supports IGMP snooping must flood all unrecognized IGMP messages to
all other ports".
9. IANA Considerations
Request to IANA for ICMP or IGMP code point allocation would
expectedly be requested in the future for the messages defined in
this document.
[Note to RFC Editor: this section may be removed on publication as an
RFC.]
10. 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, and MAY also check
the source IP of the Feedback message against a list of known
Queriers.
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.
11. Acknowledgements
Acknowledgments go to DSLForum contributors who provided an initial
Morin Expires May 15, 2008 [Page 10]
Internet-Draft IGMP/MLD Error Feedback November 2007
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.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", RFC 3678,
January 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[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.
[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.
12.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.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
Morin Expires May 15, 2008 [Page 11]
Internet-Draft IGMP/MLD Error Feedback November 2007
[fenner-icmp-mcast]
"ICMP errors in response to multicast", March 1999,
<http://www.icir.org/fenner/mcast/icmp.html>.
[magma-archive]
"IETF Magma WG mailing-list archives", December 2005, <htt
p://www1.ietf.org/mail-archive/web/magma/current/
msg00815.html>.
[posix] "ISO/IEC 9945 Information technology, Portable Operating
System Interface (POSIX), Part 1: Base Definitions", 2003.
Author's Address
Thomas Morin
France Telecom - Orange Labs
2, avenue Pierre Marzin
Lannion 22307
France
Email: thomas.morin@orange-ftgroup.com
Morin Expires May 15, 2008 [Page 12]
Internet-Draft IGMP/MLD Error Feedback November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Morin Expires May 15, 2008 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 04:30:10 |