< draft-liu-magma-igmpv3-mldv2-lite-01.txt		draft-liu-magma-igmpv3-mldv2-lite-02.txt >
	MAGMA Hui Liu
	Internet Draft wei cao
	Expires: December 2006 Huawei Technologies Co.,Ltd.
	June 26, 2006
	Simplifying Process for IGMPv3 and MLDv2 Protocols		MAGMA Working Group H. Liu
	draft-liu-magma-igmpv3-mldv2-lite-01.txt		Internet-Draft W. Cao
			Expires: April, 2007 Huawei Technologies Co., Ltd.
			H. Asaeda
			Keio University
			October 14, 2006
			Simplifying Process for IGMPv3 and MLDv2 Protocols
			<draft-liu-magma-igmpv3-mldv2-lite-02.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that		By submitting this Internet-Draft, each author represents that any
	any applicable patent or other IPR claims of which he or she is		applicable patent or other IPR claims of which he or she is aware
	aware have been or will be disclosed, and any of which he or she		have been or will be disclosed, and any of which he or she becomes
	becomes aware will be disclosed, in accordance with Section 6 of		aware will be disclosed, in accordance with Section 6 of BCP 79.
	BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that other
	other groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		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 list of Internet-Draft Shadow Directories can be accessed at		Copyright Notice
	http://www.ietf.org/shadow.html
	This Internet-Draft will expire on December 26, 2006.		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document suggests a simplifying implementation for IGMPv3 and		This document proposes simplified IGMPv3 and MLDv2 protocols, which
	MLDv2 protocols, which is called IGMPv3-lite or MLDv2-lite. The		are called IGMPv3-lite and MLDv2-lite. The interoperability with
	interoperability with other versions of IGMP and MLD is considered.		other versions of IGMP and MLD is also considered.
	Conventions used in this document		Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in		NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC-		this document are to be interpreted as described in RFC 2119
	2119[KEYWORDS].		[KEYWORDS].
	Table of Contents		Table of Contents
	1. Introduction................................................2		1. Introduction ................................................... 2
	2. Simplification Method overview...............................3		2. Simplification Method Overview ................................. 3
	2.1. Behavior of Group Members...............................4		2.1. Behavior of Group Members ................................. 3
	2.2. Behavior of Multicast Routers...........................4		2.2. Behavior of Multicast Routers ............................. 4
	3. IGMPv3-lite protocol for Group Members.......................5		3. IGMPv3-lite Protocol for Group Members ......................... 4
	3.1. Group Record Types......................................5		3.1. Action on Change of Interface State ....................... 5
	3.2. Action on Change of Interface State.....................5		3.2. Action on Reception of a Query ............................ 5
	4. IGMPv3-lite protocol for Multicast Routers...................5		3.3. Group Record Types ........................................ 6
	4.1. Group timers and source timers in lite version...........5		4. IGMPv3-lite Protocol for Multicast Routers ..................... 7
	4.2. Source-Specific Forwarding Rules........................6		4.1. Group Timers and Source Timers in the Lite Version ........ 8
	4.3. Reception of Current-State Records......................6		4.2. Source-Specific Forwarding Rules .......................... 9
	4.4. Reception of Source-List-Change and Filter-Mode-Change		4.3. Reception of Current-State Records ........................ 9
	Records.....................................................7		4.4. Reception of Source-List-Change and
	5. Interoperability............................................8		Filter-Mode-Change Records ............................... 10
	5.1. Interoperation with IGMPv1/IGMPv2.......................9		5. Interoperability .............................................. 11
	5.2. Interoperation with full IGMPv3.........................9		5.1. Interoperation with IGMPv1/IGMPv2 ........................ 11
	6. Affects to other protocols..................................10		5.2. Interoperation with the Full Version of IGMPv3 ........... 12
	7. Security Considerations.....................................10		6. Implementation Considerations ................................. 12
	8. References.................................................10		6.1. Implementation of Source-Specific Multicast .............. 12
	Author's Addressess...........................................10		6.2. Implementation of Multicast Source Filter (MSF) APIs ..... 13
	Intellectual Property Statement................................10		7. Security Considerations ....................................... 13
	Disclaimer of Validity........................................11		8. Normative References .......................................... 13
	Copyright Statement...........................................11		9. Informative References ........................................ 13
	Acknowledgment................................................11		Intellectual Property Statement .................................. 14
			Disclaimer of Validity ........................................... 14
			Copyright Statement .............................................. 15
			Acknowledgment ................................................... 15
	1. Introduction		1. Introduction
	The purpose of this draft is to suggest the simplification of IGMPv3		IGMPv3 [IGMPv3] and MLDv2 [MLDv2] implement source filtering
	[IGMPv3] and MLDv2 [MLDv2] protocols.		capability compared to their earlier versions IGMPv2 and MLDv1, i.e.,
			the end host not only tells which group it would like to join, but
	IGMPv3 and MLDv2 implement source filtering capability compared to		also specifies which sources it does or does not intend to receive
	their earlier versions IGMPv2 and MLDv1, i.e., the end host not only		multicast traffic from. Filter-modes are defined for the end hosts
	tells which group it would like to join, but also specifies which		and router parts of the protocols respectively.
	sources it does or does not intend to receive multicast traffic from.
	Filter-modes are defined for the end hosts and router parts of the
	protocols respectively.
	If a receiver on a host wants to receive from specific sources, it'll
	send an IGMPv3 or MLDv2 report with filter-mode set to INCLUDE. On
	the other hand if the host does not need to receive from some sources,
	the filter-mode of the report should be set to EXCLUDE. A source list
	for the given sources shall be included in the report message.
	Filter mode INCLUDE and EXCLUDE are also defined in the multicast		If a receiver host wants to receive from specific sources, it sends
	router to process the IGMPv3 or MLDv2 reports appropriately. And		an IGMPv3 or MLDv2 report with filter-mode set to INCLUDE. On the
	group timer and source timer are maintained. The multicast router		other hand if the host does not want to receive from some sources, it
	decides its filter-mode, type and value of the timers and forwarding		sends the report with filter-mode set to EXCLUDE. A source list for
	methods according to specific rules when group report arrives or		the given sources shall be included in the report message.
	timer expires, and the router has to switch its filter-mode under
	certain conditions. All above factors correlated with each other, the
	determination rule is relatively complex as the state changes.
	The introduction of filter-mode improves the expressing ability of		INCLUDE and EXCLUDE filter modes are also defined in a multicast
	the multicast receiver. And it is very useful in support of SSM		router to process the IGMPv3 or MLDv2 reports. Group timer and source
	(which making use of INCLUDE mode). But in practical applications,		timer are used to maintain forwarding state of desired group and
	EXCLUDE <S,G> mode(which means blocking some sources) is not used so		source. A multicast router decides its filter-mode, type, and value
	often, because the scenario is rare that a user is unwilling to		of the timers and forwarding methods according to the specific rules
	receive from some sources. Even if such application exists, it is		when a group report message arrives or timer expires. The router then
	possible that other users in the same shared network have interest in		has to switch its filter-mode under certain conditions. All above
	these sources. Then the multicast traffic has to be forwarded down		factors correlated with each other, while the determination rule is
	either. Then it can not be guaranteed that undesired traffic not		relatively complex as the receiving state could be frequently
	received. Thus in most applications, excluding specific sources does		changed.
	not seem a useful implementation.
	In many applications, it is enough to implement part of IGMPv3/MLDv2		The multicast filter-mode improves the expressing ability of the
	without EXCLUDE<S,G> mode. Considering the limited effects of EXCLUDE		multicast receiver. It is useful to support Source-Specific Multicast
	<S,G> filter-mode, and the complicacy of the operation introduced by		(SSM) [SSM] by specifying interesting source addresses with INCLUDE
	it, it is suggested in this draft that the function of EXCLUDE mode		mode. However, practical applications do not use EXCLUDE mode to
	is simplified. The protocol operation would be greatly reduced as a		block sources so often, because a user or application usually wants
	result.		to specify desired source addresses, not undesired source addresses
			to not receive from them. Even if a user wants to explicitly refuse
			traffic from some sources in a group, when other users in the same
			shared network have interest in these sources, the corresponding
			multicast traffic is forwarded to the network after all.
	The elimination of the EXCLUDE <S,G> mode does not only simplify the		This document aims to propose the simplified IGMPv3 and MLDv2
	process of IGMPv3/MLDv2 hosts and routers, but also reduces the		(referred to as IGMPv3-lite and MLDv2-lite) in which EXCLUDE filter
	complexity of related protocols realization on other equipments(e.g.,		mode that supports to exclude data come from specified sources is
	switches that perform IGMPv3/MLDv2 snooping).		eliminated. Not only IGMPv3-lite and MLDv2-lite are compatible with
			the standard IGMPv3 and MLDv2, but also the protocol operations made
			by data receiver hosts and routers or switches (performing
			IGMPv3/MLDv2 snooping) are simplified in the lite version protocol
			and complicated operations are hence effectively reduced. Since
			IGMPv3-lite and MLDv2-lite are fully compatible with the full version
			of these protocols (i.e. the standard IGMPv3 and MLDv2), hosts or
			routers that have implemented the full version do not need to
			implement or modify anything to cooperate with IGMPv3/MLDv2-lite
			hosts or routers.
	2. Simplification Method overview		2. Simplification Method Overview
	The simplifying principle is to simplify the host and router parts as		The principle is to simplify the host and router parts as much as
	much as possible to improve efficiency, while guaranteeing the		possible to improve efficiency, while guaranteeing the
	interoperability with full versions, and introducing no side effects		interoperability with full versions, and introducing no side effects
	on the applications.		on the applications.
	For convenience, we just mention IGMPv3, because the source filtering		For convenience, this document mainly discusses IGMPv3 since MLDv2
	mechanism is the same for the two protocols.		inherits the same source filtering mechanism, but additionally shows
			MLDv2's unique specifications when needed.
	2.1. Behavior of Group Members		2.1. Behavior of Group Members
			In the IGMPv3-lite, the same service interface model as that of
			IGMPv3 [IGMPv3] is inherited:
	In this method, we take the same service interface model as that of		IPMulticastListen ( socket, interface, multicast-address,
	IGMPv3 [IGMPv3]:		filter-mode, source-list )
	IPMulticastListen ( socket, interface, multicast-address,
	filter-mode, source-list)
	In the lite protocol, EXCLUDE mode on the host part is preserved for		In the lite version protocol, EXCLUDE mode on the host part is
	the expression of non-source-specific group join, which is		preserved only for EXCLUDE (*,G) join, which denotes non-source-
	equivalent to IGMPv2/IGMPv1/MLDv1 join. It is denoted as		specific group report (as known as (*,G) join) and is equivalent to
	EXCLUDE<NULL> in this draft. The detailed host operation of IGMPv3-		the group membership join triggered by IGMPv2/IGMPv1/MLDv1. The
	lite is described in section 3.		detailed host operation of IGMPv3/MLDv2-lite is described in section
			3.
	2.2. Behavior of Multicast Routers		2.2. Behavior of Multicast Routers
	According to [IGMPv3], the filter-mode of the router is defined to		According to [IGMPv3], the filter-mode of the router is defined to
	optimize the state description of a group. As a rule, once a member		optimize the state description of a group. As a rule, once a member
	report is in EXCLUDE mode, the router filter-mode for the group will		report is in EXCLUDE mode, the router filter-mode for the group will
	be set to EXCLUDE. Otherwise when all systems with a group record in		be set to EXCLUDE. Otherwise when all systems with a group record in
	EXCLUDE mode for that group cease reporting, the router's filter-mode		EXCLUDE mode for that group cease reporting, the router's filter-mode
	may transit back to INCLUDE mode. Group timer is used to identify		may transit back to INCLUDE mode. Group timer is used to identify
	such transition.		such transition.
	In IGMPv3-lite, member reports carry mainly the INCLUDE mode		In IGMPv3-lite, member reports carry mainly the INCLUDE mode
	information with only one exception for EXCLUDE<NULL>, which can be		information with only one exception for EXCLUDE (*,G), which means
	interpreted as including all sources as well. Without EXCLUDE mode		including all sources and can also be interpreted as INCLUDE mode.
	group information, it is unnecessary for the router to maintain the		Without EXCLUDE mode report information, it is unnecessary for the
	EXCLUDE filter-mode. With INLCUDE filter-mode as a default processing		router to maintain the EXCLUDE filter-mode, and the state model for
	mode, the state model for multicast router can be simplified as:		multicast router can be simplified as:
	(multicast address, group timer,(source records))		(multicast address, group timer, (source records))
	Here group timer is kept to represent ASM group. Its basic behavior		Here group timer is kept to represent (*,G) group join. Its basic
	is: when a router receives an ASM group join, it will set its group		behavior is: when a router receives a (*,G) group join, it will set
	timer, and the source list for the SSM group will be kept. As the		its group timer, and the source list for the source-specific group
	group timer expires, the router may change to the reception for the		will be kept. As the group timer expires, the router may change to
	listed sources.		the reception for the listed sources.
	The elimination of the filter-mode will greatly simplify the router		The elimination of the filter-mode will greatly simplify the router
	behavior, e.g. the action on reception of reports and the setting of		behavior, e.g. the action on reception of reports and the setting of
	the timers. The detailed operation of router operation is described		the timers. The detailed operation of router operation is described
	in section 4.		in section 4.
	3. IGMPv3-lite protocol for Group Members		3. IGMPv3-lite Protocol for Group Members
	3.1. Group Record Types		IGMPv3-lite uses two sets of messages, i.e., Query messages and
			Report messages the same as the full version protocols. Although
			most of these message types and corresponding group records are
			inherited from the full version protocols, an operation that triggers
			EXCLUDE (S,G) join is omitted and the corresponding record types of
			the Report are modified on the lite version protocols.
	There are three group record types defined in the full IGMPv3:		3.1. Action on Change of Interface State
	Current-State Record (taking value of NODE_IS_INCLUDE and
	NODE_IS_EXCLUDE), Filter-Mode-Change Record (CHANGE_TO_INCLUDE_MODE
	and CHANGE_TO_EXCLUDE_MODE) and Source-List-Change Record
	(ALLOW_NEW_SOURCES and BLOCK_OLD_SOURCES).
	Among these messages, CHANGE_TO_EXCLUDE_MODE is not used, for the		When an interface state of a group member host is changed, a State-
	process related to it is completely the same as that of		Change Report for that interface is immediately transmitted from that
	MODE_IS_EXCLUDE. The formats of other five messages are the same as		interface. The type and contents of the Group Record(s) in that
	that of full IGMPv3. MODE_IS_EXCLUDE is solely used for EXCLUDE<NULL>.		Report are determined by comparing the filter mode and source list
			for the affected multicast address before and after the change. While
			the requirements are the same as the full version for the
			computation, in the lite version host, the interface state change
			rules are simplified due to the reduction of message types. The
			contents of the new transmitted report are calculated as described in
			section 3.3.
	3.2. Action on Change of Interface State		To cover the possibility of the State-Change Report being missed by
			one or more multicast routers, it is retransmitted [Robustness
			Variable]-1 more times, at intervals chosen at random from the range
			(0, [Unsolicited Report Interval]). (These values are defined in
			[IGMPv3, MLDv2].)
	The interface state change rules are simplified as the elimination of		In the full version of IGMPv3, as was done with the first report, the
	EXCLUDE<S,G> mode, which can be expressed by:		interface state for the affected group before and after the latest
			change is compared, and the report records expressing the difference
			are built and merged with the contents of the pending report, to
			create the new State-Change report. However, it is optional that an
			IGMPv3-lite host merges with the contents of the pending report. If
			the IGMPv3-lite host does not merge with the contents of the pending
			report, it transmits each report sequentially. Doing so can greatly
			simplified the operation for scheduling the reports.
	Old State New State State-Change Record Sent		3.2. Action on Reception of a Query
	--------- --------- ------------------------		When a lite version host receives a Query, it does not respond
			immediately. Instead, it delays its response by a random amount of
			time, bounded by the Max Resp Time value derived from the Max Resp
			Code in the received Query message [IGMPv3, MLDv2]. The system may
			receive a variety of Queries on different interfaces and of different
			kinds (e.g., General Queries, Group-Specific Queries, and Group-and-
			Source-Specific Queries), each of which may require its own delayed
			response.
	INCLUDE (A) INCLUDE (B) ALLOW (B-A), BLOCK(A-B)		Before scheduling a response to a Query, the system must first
			consider previously scheduled pending responses and in many cases
			schedule a combined response. Therefore, the lite version host must
			be able to maintain the following state:
	INCLUDE (A) EXCLUDE (NULL) IS_EX(NULL)		o A timer per interface for scheduling responses to General Queries.
	EXCLUDE (NULL) INCLUDE (B) TO_IN(B)		o A per-group and interface timer for scheduling responses to Group-
			Specific and Group-and-Source-Specific Queries.
	4. IGMPv3-lite protocol for Multicast Routers		o A per-group and interface list of sources to be reported in the
			response to a Group-and-Source-Specific Query.
	4.1. Group timers and source timers in lite version		IGMPv3-lite inherits most of the rules that are used to determine if
			a Report needs to be scheduled from the full version. The different
			point is regarding the simplification of EXCLUDE filter-mode and the
			type of Report to schedule as detailed in section 3.3.
	As section 2.2 mentioned, it is possible for IGMPv3-lite to discard		On the other hand, while it is optional that an IGMPv3-lite host
	filter-mode denotation in the router. The group timer, which being		merges with the contents of the pending report for unsolicited report
	previously used as a mechanism for transitioning the router filter-		(i.e. State-Change report) as mentioned in the previous section, if
	mode from EXCLUDE to INCLUDE, now is redefined for the transitioning		the received Query is a Group-and-Source-Specific Query and there is
	between the ASM and SSM receiving state on the router. The role of		a pending response for this group with a non-empty source-list, then
	the group timer can be summarized as follows:		the group source list is augmented to contain the list of sources in
			the new Query and a single response is scheduled using the group
			timer as with the full version host. The new response is then
			scheduled to be sent at the earliest of the remaining time for the
			pending report and the selected delay.
	Group Timer Value Actions/Comments		3.3. Group Record Types
	------------------ -----------------		There are three Group Record Types defined in the full IGMPv3:
			Current-State Record noted by MODE_IS_INCLUDE (referred to as IS_IN)
			or MODE_IS_EXCLUDE (IS_EX), Filter-Mode-Change Record noted by
			CHANGE_TO_INCLUDE_MODE (TO_IN) or CHANGE_TO_EXCLUDE_MODE (TO_EX), and
			Source-List-Change Record noted by ALLOW_NEW_SOURCES (ALLOW) or
			BLOCK_OLD_SOURCES (BLOCK).
	G_Timer > 0 All members in this group.		Among these messages, several record types defined in the full IGMPv3
			are not used in IGMPv3-lite as some of the processes related to the
			filter mode change to the EXCLUDE mode are eliminated and some of the
			report messages are converged with a record having null source
			address list. All of the record types of report messages used by the
			full and lite version protocols are shown as follows:
	G_Timer == 0 No more listeners to this ASM group. If		Full ver. Lite ver. Comments
	all source timers have expired then
	delete group record. If there are still
	source record timers running, use those
	source records with running timers as
	the source record state.
	The operation related to the group and source timers is different		--------- --------- --------------------------------
	compared to the full IGMPv3. In the full version, if a source timer
	expires under the EXCLUDE router filter-mode, its corresponding
	source record is not deleted until the group timer expires. In lite
	version, if a source timer expires, its source record should be
	deleted immediately, not waiting for the time-out of the group timer.
	4.2. Source-Specific Forwarding Rules		IS_EX() IS_EX() Query response for (*,G) join
			IS_EX(x) N/A Query response for EX (x,G) join
	The forwarding rules depend on group and source timer values. Now		IS_IN(x) ALLOW(x) Query response for IN (x,G) join
	they can be expressed as follows:
	Group Timer Source Timer Action		ALLOW(x) ALLOW(x) IN (x,G) join
	----------- ------------------ ----------------------		BLOCK(x) BLOCK(x) IN (x,G) leave
	G_Timer == 0 S_TIMER > 0 Suggest to forward traffic		TO_IN(x) TO_IN(x) Change to IN (x,G) join
	from source
	G_Timer == 0 S_TIMER == 0 Suggest to stop forwarding		TO_IN() TO_IN() (*,G) leave
	traffic from source and
	remove source record. If
	there are no more source
	records for the group, delete
	group record.
	G_Timer == 0 No Source Elements Suggest not to forward		TO_EX(x) N/A Change to EX (x,G) join
	traffic from the source
	G_Timer > 0 S_TIMER >= 0 Suggest to forward traffic		TO_EX() IS_EX() (*,G) join
	from source
	G_Timer > 0 No Source Elements Suggest to forward traffic		where "x" represents non-null source address list and "()" represents
	from source		null source address list. For instance, IS_EX() means a report whose
			record type is IS_EX with null source address list. "N/A" represents
			not applicable (or no use) because the corresponding operation should
			not occur in the lite version protocols.
	4.3. Reception of Current-State Records		IGMPv3-lite does not use EXCLUDE filter-mode with non-null source
			address list. And a multicast router creates the same state when it
			receives a report message containing either of IS_EX or TO_EX record
			types. Therefore, IGMPv3-lite integrates the TO_EX operation to the
			IS_EX operation.
	When receiving Current-State Records, the IGMPv3-lite router needs		On the other hand, when an IGMPv3-lite version host needs to make a
	reset its group or source timers, and update its source list within		query response for the state of INCLUDE (x,G) join, the host makes
	the group. In SSM group (G_Timer==0), the source list includes		the response whose message type is expressed with ALLOW(x), instead
	sources to be forwarded by the router, while in ASM group (G_Timer >0)		of using IS_IN record type, for router's processing of the two
	the source list remembers the sources to be forwarded after switching		messages are completely the same, the IS_IN(x) type is eliminated for
	back to SSM mode.		simplification.
	Old Source new Source		An IGMPv3-lite version host does not use EXCLUDE mode, while TO_IN
			record is used with the following situation; the host firstly
			launches an application (AP1) that requests INCLUDE (x,G) join, and
			it sends ALLOW(x). Then the host launches another application (AP2)
			that joins (*,G), and it sends IS_EX(). In this condition, when AP2
			terminates but AP1 keeps working on the lite version host, the host
			sends a report with TO_IN(x) record type for [Robustness Variable]
			times.
	Group Timer list Report Rec'd list Actions		4. IGMPv3-lite Protocol for Multicast Routers
	----------- ------ ------------ ------- ---------		The major difference between the full and lite version protocol on
			the router is that filter-mode is discarded for the lite version, as
			section 2.2 mentioned. Then the IGMP state maintained by the router
			for each attached network can be simplified as:
	G_Timer==0 A IS_IN(B) A+B (B)=GMI		(multicast address, group timer, (source records))
	G_Timer==0 A IS_EX(NULL) A G_Timer= GMI		where the source record includes pairs of source address and its
			corresponding source timer. The reduction of filtering mode will
			change the meaning of the group timer and will simplify the router's
			processing.
	G_Timer >0 A IS_IN(B) A+B (B)=GMI		4.1. Group Timers and Source Timers in the Lite Version
	G_Timer >0 A IS_EX(NULL) A G_Timer = GMI		The source timer is kept for each source record and it is updated
			when the source is present in a received report. It indicates the
			validity of the sources and needs to be referred when the router
			takes its forwarding decision.
	And the above table could be further simplified for the processes		The group timer, which being used in full IGMPv3 as a mechanism for
	are completely the same for the two values of the G-Timer:		transitioning the router's filter-mode from EXCLUDE to INCLUDE, is
			now redefined for the identification of the non-source-specific
			receiving states. Once a group record of IS_EX() is received, the
			group timer is used to represent this (*,G) group join. The
			expiration of the group timer indicates that there are no listeners
			on the attached network for this (*,G) group. Then if at this moment
			there are unexpired sources (whose source timers are greater than
			zero), the router will change to receiving for those sources. The
			role of the group timer can be summarized as follows:
	Old Source new Source		Group Timer Value Actions/Comments
	list Report Rec'd list Actions		------------------ --------------------------------------
	------ ------------ ------- ---------		G_Timer > 0 All members in this group.
	A IS_IN(B) A+B (B)=GMI		G_Timer == 0 No more listeners to this (*,G) group.
			If all source timers have expired then
			delete group record. If there are
			still source record timers running,
			use those source records with running
			timers as the source record state.
	A IS_EX(NULL) A G_Timer= GMI		The operation related to the group and source timers has some
			difference compared with the full IGMPv3. In the full version, if a
			source timer expires under the EXCLUDE router filter-mode, its
			corresponding source record is not deleted until the group timer
			expires. They are kept for indicating undesired sources. In the lite
			version, since there is no need to keep such records for blocking
			specific sources, if a source timer expires, its source record should
			be deleted immediately, not waiting for the time-out of the group
			timer.
	4.4. Reception of Source-List-Change and Filter-Mode-Change Records		4.2. Source-Specific Forwarding Rules
	On receiving Source-List-Change Records, the IGMPv3-lite router needs		The forwarding suggestion made by igmpv3-lite to the routing
	reset its group and source timers, update its source list within the		protocols is as follows:
	group, or trigger group queries.
	Old Source new Source		Group Timer Source Timer Action
	Group Timer list Report Rec'd list Actions		------------ ------------------ -----------------------
	----------- ------ ------------ ------- ---------		G_Timer == 0 S_TIMER > 0 Suggest to forward
			traffic from source
	G_Timer==0 A ALLOW(B) A+B (B)=GMI		G_Timer == 0 S_TIMER == 0 Suggest to stop
			forwarding traffic from
			source and remove
			source record. If there
			are no more source
			records for the group,
			delete group record
	G_Timer==0 A BLOCK(B) A Send Q(G,A*B)		G_Timer == 0 No Source Elements Suggest not to forward
	G_Timer==0 A TO_IN(B) A+B (B)=GMI		traffic from the source
	Send Q(G,A-B)		G_Timer > 0 S_TIMER >= 0 Suggest to forward
			traffic from source
	G_Timer >0 A ALLOW(B) A+B (B)=GMI		G_Timer > 0 No Source Elements Suggest to forward
			traffic from source
	G_Timer >0 A BLOCK(B) A Send Q(G,A*B)		4.3. Reception of Current-State Records
	G_Timer >0 A TO_IN(B) A+B (B)=GMI		When receiving Current-State Records, the IGMPv3-lite router resets
			its group or source timers and updates its source list within the
			group. For source-specific group reception state(G_Timer==0), the
			source list includes sources to be forwarded by the router, while in
			non-source-specific group reception(G_Timer>0) the source list
			remembers the sources to be forwarded after toggling to source-
			specific reception state.
	SendQ(G,A-B)		Old New
	Send Q(G)		Source Source
			Group Timer List Report Rec'd List Actions
	The table could be further simplified by merging duplicate lines:		----------- ------ ------------ ------- -----------
			G_Timer == 0 A IS_IN(B) A+B (B)=GMI
	Old Source new Source		G_Timer == 0 A IS_EX() A G_Timer=GMI
	list Report Rec'd list Actions		G_Timer > 0 A IS_IN(B) A+B (B)=GMI
	------ ------------ ------- ---------		G_Timer > 0 A IS_EX() A G_Timer=GMI
	A ALLOW(B) A+B (B)=GMI		And the above table could be further simplified for the processes are
			completely the same for the two values of the G_Timer:
	A BLOCK(B) A Send Q(G,A*B)		Old New
			Source Source
			List Report Rec'd List Actions
	A TO_IN(B) A+B (B)=GMI		------ ------------ ------- ------------
	Send Q(G,A-B)		A IS_IN(B) A+B (B)=GMI
	If G_Timer>0 Send Q(G)		A IS_EX() A G_Timer=GMI
			4.4. Reception of Source-List-Change and Filter-Mode-Change Records
			On receiving Source-List-Change Records, the IGMPv3-lite router needs
			to reset its group and source timers, update its source list within
			the group, or trigger group queries.
			Old New
			Source Source
			Group Timer List Report Rec'd List Actions
			------------ ------ ------------ ------- -------------
			G_Timer == 0 A ALLOW(B) A+B (B)=GMI
			G_Timer == 0 A BLOCK(B) A Send Q(G,A*B)
			G_Timer == 0 A TO_IN(B) A+B (B)=GMI
			Send Q(G,A-B)
			G_Timer > 0 A ALLOW(B) A+B (B)=GMI
			G_Timer > 0 A BLOCK(B) A Send Q(G,A*B)
			G_Timer > 0 A TO_IN(B) A+B (B)=GMI
			SendQ(G,A-B)
			Send Q(G)
			The table could be further simplified by merging duplicate lines:
			Old New
			Source Source
			List Report Rec'd List Actions
			------ ------------ ------- ----------------------
			A ALLOW(B) A+B (B)=GMI
			A BLOCK(B) A Send Q(G,A*B)
			A TO_IN(B) A+B (B)=GMI
			Send Q(G,A-B)
			If G_Timer>0 Send Q(G)
	5. Interoperability		5. Interoperability
	IGMPv3-lite hosts and routers should interoperate gracefully with		IGMPv3-lite hosts and routers should interoperate gracefully with
	hosts and routers that running IGMPv1/IGMPv2/IGMPv3.		IGMPv3/MLDv2-lite hosts and routers should interoperate gracefully
			with hosts and routers that running IGMPv1/v2/v3 or MLDv1/v2.
	The simplification in IGMPv3-lite introduces no changes on the		The simplification in IGMPv3-lite introduces no changes on the
	message format of the group query and report. The member sends a		message format of the group query and report. The member sends a
	subset of IGMPv3 reports, which can be recognized by full IGMPv3		subset of IGMPv3 reports, which can be recognized by full IGMPv3
	protocols.		protocols.
	The discard of the filter-mode on the router just simplified the		The discard of the filter-mode on the router just simplified the
	processing inside the router, not influencing the outside behavior of		processing inside the router, not influencing the outside behavior of
	the protocol.		the protocol.
	From above discussion, IGMPv3-lite can be treated as a ''parallel		From above discussion, IGMPv3/MLDv2-lite can be treated as a
	version'' of full IGMPv3. Its interoperability method with lower		"parallel version" of the full IGMPv3/MLDv2. Its interoperability
	versions (i.e. IGMPv1 and IGMPv2) should be the same as that of the		method with lower versions (i.e. IGMPv1/v2 and MLDv1) should be the
	IGMPv3 and MLDv2.		same as that of the IGMPv3 and MLDv2.
	5.1. Interoperation with IGMPv1/IGMPv2		5.1. Interoperation with IGMPv1/IGMPv2
	IGMPv3-lite protocol adopts the same Host/Group Compatibility Mode		IGMPv3-lite protocol adopts the same Host/Group Compatibility Mode
	and keeps Querier Present timers for IGMPv1 and IGMPv2. Their		and keeps Querier Present timers for IGMPv1 and IGMPv2. Their
	definition and processing is just the same as [IGMPv3].		definition and processing is just the same as [IGMPv3].
	When Group Compatibility mode is IGMPv2 or IGMPv1, an IGMPv3-lite		When Group Compatibility mode is IGMPv2 or IGMPv1, an IGMPv3-lite
	router translates the following IGMPv2 or IGMPv1 messages for that		router translates the following IGMPv2 or IGMPv1 messages for that
	group to their IGMPv2 or IGMPv1 equivalents, as following:		group to their IGMPv2 or IGMPv1 equivalents, as following:
	IGMP Message IGMPv3 lite Equivalent		IGMP Message IGMPv3-lite Equivalent
			-------------- ----------------------
	-------------- -----------------
	v1 Report IS_EX(NULL)		v1 Report IS_EX()
	v2 Report IS_EX(NULL)		v2 Report IS_EX()
	v2 Leave TO_IN(NULL)		v2 Leave TO_IN()
	5.2. Interoperation with full IGMPv3		5.2. Interoperation with the Full Version of IGMPv3
	If an IGMPv3-lite router receives reports from the full IGMPv3 host,		If an IGMPv3-lite router receives reports from the full IGMPv3 host,
	it should treat the messages as follows:		it should treat the messages as follows:
	IGMPv3 Report IGMPv3-lite Equivalent		IGMPv3 Report IGMPv3-lite Equivalent
	-------------- -----------------		-------------- ----------------------
	IS_IN(x) IS_IN(x)		IS_IN(x) IS_IN(x)
	IS_EX(x) IS_EX(NULL)		IS_EX(x) IS_EX()
	TO_IN(x) TO_IN(x)		TO_IN(x) TO_IN(x)
	TO_EX(x) IS_EX(NULL)		TO_EX(x) IS_EX()
	ALLOW(x) ALLOW(x)		ALLOW(x) ALLOW(x)
	BLOCK(x) BLOCK(x)		BLOCK(x) BLOCK(x)
	6. Affects to other protocols		6. Implementation Considerations
	The simplified protocols put no additional burden on the		The simplified protocols put no additional burden on the
	implementation of other related protocols, e.g. IGMP/MLD snooping,		implementation of other related protocols, e.g. IGMP/MLD snooping,
	multicast routing protocol and operation of application sockets. On		multicast routing protocol and operation of application sockets. On
	the other hand, the processing load on the switches and routers that		the other hand, the processing loads on the switches and routers that
	running IGMPv3 (snooping) and multicast routing protocols will be		running IGMPv3 (snooping) and multicast routing protocols will be
	greatly decreased.		greatly decreased.
			In the following sections, the protocols related to the
			implementation of IGMPv3/MLDv2 are restated for the lite version.
			6.1. Implementation of Source-Specific Multicast
			RFC [IGMP-SSM] illustrates the requirements of implementation of
			Source-Specific Multicast on IGMPv3/MLDv2 hosts and routers. The lite
			protocol does not impose any bad influences on SSM application. The
			requirements of IGMPV3/MLDv2-lite for support of SSM are illustrated
			below.
			For an SSM-aware host, the application should not send a non-source-
			specific join, i.e. IS_EX(), and IGMPv2 Leave and MLDv1 Done messages
			for the SSM address. The reception of a non-source-specific join with
			an SSM group address should indicate an error to the application. The
			SSM-aware router will ignore IS_EX() reports with SSM addresses.
			Other types of Reports should be processed normally.
			6.2. Implementation of Multicast Source Filter (MSF) APIs
			Multicast Source Filter (MSF) APIs [MSF] defines (1) IPv4 Basic MSF
			API, (2) IPv4 Advanced MSF API, (3) Protocol-Independent Basic MSF
			API, and (4) Protocol-Independent Advanced MSF API.
			According to the MSF APIs definition, an IGMPv3-lite version host
			should implement IPv4 Basic MSF API and an MLDv2-lite version host
			should implement Protocol-Independent Basic MSF API. Other APIs, IPv4
			Advanced MSF API and Protocol-Independent Advanced MSF API, are
			optional to implement in IGMPv3/MLDv2-lite version host.
	7. Security Considerations		7. Security Considerations
	The security consideration is the same as that of the original		The security consideration is the same as that of the full version of
	IGMPv3/MLDv2.		IGMPv3/MLDv2.
	8. References		8 Normative References
	[IGMPv3] Cain, B.,"Internet Group Management Protocol, Version3",		[KEYWORDS] Bradner, S., "Key words for use in RFCs to indicate
	RFC3376, October 2002.		requirement levels," RFC 2119, March 1997.
			9 Informative References
			[SSM] Holbrook, H. and Cain, B., "Source-Specific Multicast for IP,"
			RFC 4607, August 2006.
			[IGMPv3] Cain, B.,"Internet Group Management Protocol, Version3," RFC
			3376, October 2002.
	[MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery Version		[MLDv2] Vida, R. and Costa, L., "Multicast Listener Discovery Version
	2 (MLDv2) for IPv6", RFC3810, June 2004.		2 (MLDv2) for IPv6," RFC 3810, June 2004.
			[IGMP-SSM] Holbrook, H., Cain, B., and Haberman, B., "Using Internet
			Group Management Protocol Version 3 (IGMPv3) and Multicast
			Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific
			Multicast," RFC 4604, August 2006.
			[MSF] Thaler, D., Fenner, B., and Quinn, B., "Socket Interface
			Extensions for Multicast Source Filters," RFC 3678, January 2004.
	Author's Addressess		Author's Addressess
	Hui Liu		Hui Liu
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
			Email: Liuhui47967@huawei.com
	Liuhui47967@huawei.com
	Wei Cao		Wei Cao
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
	Email: caowayne@huawei.com		Email: caowayne@huawei.com
			Hitoshi Asaeda
			Keio University
			Email: asaeda@wide.ad.jp
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 11, line 15 ¶		skipping to change at page 14, line 44 ¶
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		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		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at ietf
	ietf-ipr@ietf.org.		ipr@ietf.org.
	Disclaimer of Validity		Disclaimer of Validity
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
End of changes. 118 change blocks.
	259 lines changed or deleted		445 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/