[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 4604

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM               H. Holbrook
Expires May 3, 2003                                        Cisco Systems
                                                                 B. Cain
                                                         Cereva Networks
                                                             B. Haberman
                                                        Caspian Networks
                                                             Nov 3, 2002


          Using IGMPv3 and MLDv2 For Source-Specific Multicast
                <draft-holbrook-idmr-igmpv3-ssm-03.txt>


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.

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 [RFC 2119].















Holbrook/Cain/Haberman                                          [Page 1]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM                3 Nov 2002


Abstract

This document describes changes to the Internet Group Management
Protocol Version 3 (IGMPv3) [IGMPv3] and the Multicast Listener
Discovery Protocol Version 2 (MLDv2) [MLDv2] to support source-specific
multicast (SSM) [SSM].

1.  Overview and Rationale

The Internet Group Management Protocol (IGMP) [RFC1112,IGMPv2,IGMPv3],
is the standard mechanism for communicating IP multicast group
membership requests from a host to its locally attached routers in IPv4.
IGMP version 3 (IGMPv3) [IGMPv3] provides the ability for a host to
selectively request or filter traffic from individual sources within a
multicast group.

The Multicast Listener Discovery Protocol (MLD) [RFC2710, MLDv2] offers
similar functionality for IPv6.  Specifically, MLD version 2 (MLDv2)
performs the same functionality as IGMPv3.

Due to the commonality of function, the term "Group Management Protocol"
or "GMP" will be used to refer to both IGMP and MLD.  The term "Source
Filtering GMP", or "SFGMP" will be used to reference IGMPv3 and MLDv2
capable group management protocols.

The SFGMP algorithms and message processing rules require small changes
to support the source-specific multicast model.  This document defines
the modifications required to the host and router portions of IGMPv3 and
MLDv2 to support source-specific multicast.

2.  GMP Host Requirements for Source-Specific Multicast

This document does not strictly require the IP layer or GMP module of an
SFGMP-enabled host to treat SSM destination addresses specially.  To
ensure that the routers apply SSM semantics for SSM addresses, however,
a host application must

     - know the range of destination addresses that have SSM semantics

     - use ONLY source-specific APIs to request delivery of packets
       sent to SSM destination addresses

The 232/8 address range is currently allocated for SSM by IANA [IANA-
ALLOCATION] for IPv4.  In IPv6, the range is FF3x::/32 [RFC3306] (where
'x' is a valid IPv6 multicast scope value).  Hosts and routers may be
configured to apply SSM semantics to other addresses as well.

A GMP module on a host or router SHOULD have a configuration mechanism



Holbrook/Cain/Haberman                                          [Page 2]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM                3 Nov 2002


to set the SSM address range(s).  If this configuration option exists,
it MUST default to the IANA-allocated SSM range.  The mechanism for
setting this configuration option MUST at least allow for manual
configuration.  Protocol mechanisms to set this option may be defined in
the future.  If a host does not have this option, applications on that
host may be denied SSM service by other non-compliant applications on
the same host or by other non-compliant hosts on the same network, as
described below.


It is strongly recommended that the multicast source filtering (MSF)
APIs of [MSFAPI] be used to implement SSM.  If the host IP module
receives a non source-specific request for an SSM destination address,
it SHOULD return an error to the application.  If the host IP module is
not configured with the SSM address range, the non-source-specific (RFC
1112) APIs will not return an error when passed an SSM destination
addresses.  On these hosts, applications that mistakenly use the wrong
APIs (e.g., "join(G)", "IPMulticastListen(G,EXCLUDE(S1))" for IGMPv3, or
IPv6MulticastListen(G,EXCLUDE(S2))" for MLDv2) to request delivery of
packets sent to an SSM address will not receive the requested service,
as routers will refuse to process any such request, as per section 3.5
of this document.

This section documents the behavior of hosts with respect to sending and
receiving the following GMP message types:

     - IGMPv1/v2 and MLDv1 Reports
     - IGMPv3 and MLDv2 Reports
     - IGMPv1/v2 and MLDv1 Queries
     - IGMPv2 Leave and MLDv1 Done
     - IGMPv2 and MLDv1 Group Specific Query
     - IGMPv3 and MLDv2 Group Specific Query
     - IGMPv3 and MLDv2 Group-and-Source Specific Query


2.1.  IGMPv1/v2 and MLDv1 Reports

A host SHOULD NOT send IGMPv1, IGMPv2, or MLDv1  host reports for SSM
addresses.  If an SSM-unaware SFGMP-enabled host receives an IGMPv1,
IGMPv2, or MLDv1 host report for SSM destination address G, its GMP
module will revert to IGMPv1/v2 or MLDv1 compatibility mode for address
G.  This will prevent the host from sending source-specific joins, and
consequently the SSM service model will not be provided for destination
address G to hosts on that LAN.  Therefore, it is important that the SSM
address range be used only in conjunction with the SSM APIs.






Holbrook/Cain/Haberman                                          [Page 3]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM                3 Nov 2002


2.2.  IGMPv3 and MLDv2 Reports

Source-specific multicast destination-and-source pairs (channels) are
reported using IGMPv3 or MLDv2 with the SFGMP INCLUDE report.  A host
implementation MAY report either one or multiple channels in a single
report.

When source-specific channels are reported in an SFGMP Report, the
report may contain one or more group records of the following types:


    - MODE_IS_INCLUDE as part of a Current-State Record

    - ALLOW_NEW_SOURCES as part of a State-Change Record

    - BLOCK_OLD_SOURCES as part of a State-Change Record

The source list for any individual Group Record may be of length one or
more than one.  If a host implementation so chooses, it may report both
SSM destination addresses and RFC 1112 multicast (henceforth termed Any-
Source Multicast or ASM as in [SSM]) destination addresses in the same
message.

A host that is configured with the SSM address range would not normally
send either of the following record types for an SSM address.

    - MODE_IS_EXCLUDE as part of a Current-State Record

    - CHANGE_TO_INCLUDE_MODE as part of a Filter-Mode-Change Record

    - CHANGE_TO_EXCLUDE_MODE as part of a Filter-Mode-Change Record

EXCLUDE mode does not apply to SSM addresses, and the filter mode used
for an SSM address should never change to or from EXCLUDE mode under
correct application behavior.  If all applications on a host use SSM-
aware APIs to express interest in SSM addresses, then the host OS would
not normally send any of the above record types for addresses in the
source-specific range.


2.3.  IGMPv1/IGMPv2 and MLDv1 Queries

If an IGMPv1, IGMPv2, or MLDv1 query is received, the SFGMP protocol
specifications require the host to revert to the older (IGMPv1, IGMPv2,
or MLDv1) mode of operation for that destination address.  If this
occurs, the host will stop reporting source-specific subscriptions for
that destination address and start using IGMPv1, IGMPv2, or MLDv1 to
report interest in the SSM destination address, unqualified by a source



Holbrook/Cain/Haberman                                          [Page 4]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM                3 Nov 2002


address.  If this occurs, SSM semantics will no longer be applied to G
by the router.

A router compliant with this document would never generate an IGMPv1,
IGMPv2, or MLDv1 query for an address in the SSM range -- this situation
only occurs if either the router is not compliant with this document or
if the host and the router disagree about the SSM address range.

A host SHOULD log an error if this occurs.

In order to reduce this problem, it MUST be administratively assured
that all routers on a given shared-medium network are compliant with
this document and are in agreement about the SSM address range.


2.4.  IGMPv2 Leave and MLDv1 Done

IGMP Leave/Done messages are not processed by hosts.  IGMPv2 Leave and
MLDv1 Done messages are not sent for SSM addresses.


2.5.  IGMPv2 and MLDv1 Group Specific Query

If a host receives an IGMPv2 or MLDv1 Group Specific Query for an
address in any configured source-specific range, it SHOULD process the
query normally according to [IGMPv3][MLDv2], even if the group queried
is a source-specific destination address.  The transmission of such a
query indicates that the sending router is either not compliant with
this document or that is not configured with the same SSM address
range(s) as the receiving host.  A host SHOULD log an error in this
case.


2.6.  IGMPv3 and MLDv1 Group Specific Query

If a host receives an SFGMP Group-Specific Query in its configured
source-specific range, it MUST respond with a report if the group
matches the source-specific destination address of any of its subscribed
source-specific groups.

Although in the current IGMPv3 and MLDv2 protocol specifications,
routers would have no reason to send one, the semantics of such a query
are well-defined in this range and future implementations may have
reason to send such a query.  Be liberal in what you accept.







Holbrook/Cain/Haberman                                          [Page 5]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM                3 Nov 2002


2.7.  IGMPv3 and MLDv2 Group-and-Source Specific Query

An SFGMP router will query a source-specific channel that a host has
requested to leave (via a BLOCK_OLD_SOURCES record) with a group-and-
source specific query.  A host MUST respond to a group-and-source
specific query for which the group and source in the query match match
any channel for which the host has a subscription.

Hosts MUST be able to process a query with multiple sources listed per
group.


3.  Router Requirements for Support Source-Specific Multicast

Routers must be aware of the SSM address range.  The 232/8 and FF3x::/32
address ranges are currently allocated for SSM by IANA [IANA-
ALLOCATION][RFC3306].  However, an SSM router may have a configuration
option to apply SSM semantics to other addresses as well.  If this
configuration option exists, it MUST default to the IANA-allocated
range.

This section documents the behavior of routers with respect to the
following types of SFGMP messages for source-specific destination
addresses:

     - IGMPv3 and MLDv2 Reports
     - IGMPv3 and MLDv2 General Query
     - IGMPv3 and MLDv2 Group-Specific Query
     - IGMPv3 and MLDv2 Group-and-Source Specific Query
     - IGMPv1/v2 and MLDv1 Reports
     - IGMPv1/v2 and MLDv1 Queries
     - IGMPv2 Leave and MLDv1 Done



3.1.  IGMPv3 and MLDv2 Reports

SFGMP Reports are used to report source-specific subscriptions in the
SSM address range.  If a router receives an SFGMP report that contains a
group record for a destination address in  source-specific range that
matches one of the types listed below, then it MUST ignore that group
record, however, it MUST process other group records within that same
report.

        - Any Current-State Record with MODE_IS_EXCLUDE

        - A CHANGE_TO_EXCLUDE_MODE Filter-Mode-Change Record




Holbrook/Cain/Haberman                                          [Page 6]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM                3 Nov 2002


In order to be maximally tolerant of host implementations that are not
compliant with this specification, a router MUST process
CHANGE_TO_INCLUDE_MODE Filter-Mode-Change Group Records for groups in
the SSM range.

3.2.  IGMPv3 and MLDv2 General Queries

SFGMP General Queries are used to periodically build the total desired
membership state on a subnet.  These queries are used for the same
purpose in the source-specific address range -- no change in behavior is
required.  An SSM router sends periodic SFGMP General Queries as per the
IGMPv3 and MLDv2 specifications.


3.3.  IGMPv3 and MLDv2 Group Specific Queries

SFGMP routers that support source-specific multicast MAY send group-
specific queries for addresses in the source-specific range.  This
specification does not explicitly prohibit such a message, although, at
the time of writing, a router conformant to [IGMPv3][MLDv2] would never
send one.


3.4.  IGMPv3 and MLDv2 Group-and-Source Specific Queries

SFGMP Group-and-Source Specific Queries are used when a receiver has
indicated that it is no longer interested in receiving traffic from a
particular (S,G) pair to determine if there are any remaining directly-
attached hosts with interest in that (S,G) pair.  Group-and-Source
Specific Queries are used within the source-specific address range when
a router receives a BLOCK_OLD_SOURCES Record for one or more source-
specific groups.  These queries are sent normally, as per
[IGMPv3][MLDv2].


3.5.  IGMPv1/v2 and MLDv1 Reports

An IGMPv1/v2 or MLDv1 report for an address in the source-specific range
could be sent by a host that does not support the source-specific model.
A router MUST ignore all such reports in the source-specific address
range and specifically MUST NOT use them to establish IP forwarding
state.  A router MAY log an error if it receives such a report.


3.6.  IGMPv1/v2 and MLDv1 Queries

The GMP querier on a shared-medium network is elected to be the one with
lowest source IP address.  Therefore, an IGMPv3 or MLDv2 router will



Holbrook/Cain/Haberman                                          [Page 7]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM                3 Nov 2002


yield to an IGMPv1, IGMPv2, or MLDv1 querier with a lower IP address.
SFGMP routers that lose the querier election to a lower version router
MUST log an error, as per the IGMPv3 and MLDv2 specifications.  An SFGMP
router MAY have a configuration option that prevents it from reverting
to previous version compatibility mode for source-specific addresses.
When this configuration option is enabled, an SFGMP router that loses
the querier election to an older version querier SHOULD continue to
process source-specific reports in the source-specific address range.
This may be useful as a transition mechanism, when used in conjunction
with the host configuration option of Section 2.3.


3.7.  IGMPv2 Leave and MLDv1 Done

An IGMPv2 Leave or MLDv1 Done message may be received for a source-
specific address from a host that does not support the source-specific
model.  A router MUST ignore all such messages in the source-specific
address range.


4.  Notes

[To be removed before going to the IESG.]

4.1.  Major changes in this revision

There were two major changes in this revision (-03): the inclusion of
IPv6, and the removal of the explicit text stating that a host MAY
choose to ignore IGMPv1/v2 (MLDv1) queries in the SSM address range.
The document was internally inconsistent on this point (it said two
different things in two different sections), and the statement
conflicted with the existing IGMPv3 specifications.  This situation
indicates a serious configuration error and if the querying router has
already reverted to IGMPv2 mode for a group, then a host can not receive
proper SSM service for that group in any case.  Hence the authors
decided that it was better to remove this statement.

4.2.  A note on EXCLUDE mode

The IGMPv3 and MLDv2 protocol specifications explicitly state that a
host MUST NOT transition to EXCLUDE mode as a result of running out of
resources -- hence when a host runs out of resources, it will not fail
to provide SSM service.

5.  Acknowledgments

The authors would like to thank Vince Laviano, Nidhi Bhaskar, and Steve
Deering and for their input and careful review.



Holbrook/Cain/Haberman                                          [Page 8]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM                3 Nov 2002


6.  References

[IGMPv3] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group
Management Protocol, Version 3," RFC 3376, October 2002.

[RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112,
August 1989.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997.

[IANA-ALLOCATION] Internet Assigned Numbers Authority,
http://www.isi.edu/in-notes/iana/assignments/multicast-addresses.

[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2,"
RFC 2236, November 1997.

[MSFAPI] Thaler, D., Fenner, B., and Quinn, B.  "Socket Interface
Extensions for Multicast Source Filters."  Work in Progress.

[SSM] Holbrook, H., and Cain, B., "Source-Specific Multicast for IP",
Work in Progress.

[RFC2710] Deering, S., Fenner, B., and Haberman, B., "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.

[RFC3306] Haberman, B., and Thaler, D., "Unicast-prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.

[MLDv2] Vida, R., et. al., "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", Work in Progress.

7.  Author's Address

     Hugh Holbrook
     Cisco Systems
     170 W. Tasman Drive.
     San Jose, CA 95134
     holbrook@cisco.com


     Brad Cain
     Cereva Networks
     3 Network Drive
     Marlborough, MA 01752
     bcain99@yahoo.com





Holbrook/Cain/Haberman                                          [Page 9]

INTERNET-DRAFT            IGMPv3/MLDv2 for SSM                3 Nov 2002


     Brian Haberman
     Caspian Networks
     bkhabs@nc.rr.com

This document expires May 3, 2003.














































Holbrook/Cain/Haberman                                         [Page 10]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/