< draft-ietf-malloc-madcap-nest-opt-04.txt		draft-ietf-malloc-madcap-nest-opt-05.txt >
	Malloc Working Group Roger Kermode		Malloc Working Group Roger Kermode
	Internet Engineering Task Force Motorola		Internet Engineering Task Force Motorola
	INTERNET-DRAFT		INTERNET-DRAFT
	19 April 2000		19 April 2000
	Expires 19 October 2000		Expires 27 December 2000
	MADCAP Multicast Scope Nesting State Option		MADCAP Multicast Scope Nesting State Option
	<draft-ietf-malloc-madcap-nest-opt-04.txt>		<draft-ietf-malloc-madcap-nest-opt-05.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance		This document is an Internet-Draft and is in full conformance
	with all provisions of Section 10 of RFC2026.		with all provisions of Section 10 of RFC2026.
	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 groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	1.3 Terminology. . . . . . . . . . . . . . . . . . . 5		1.3 Terminology. . . . . . . . . . . . . . . . . . . 5
	2. Multicast Nested Scoping State. . . . . . . . . . . . 6		2. Multicast Nested Scoping State. . . . . . . . . . . . 6
	3. Multicast Scope Nesting State Option. . . . . . . . . 6		3. Multicast Scope Nesting State Option. . . . . . . . . 6
	3.1 Multicast Scope List Option . . . . . . . . . . 6		3.1 Multicast Scope List Option . . . . . . . . . . 6
	3.2 Representing the Multicast Scope Nesting State . 7		3.2 Representing the Multicast Scope Nesting State . 7
	3.3 Multicast Scope Nesting State Option Usage . . . 8		3.3 Multicast Scope Nesting State Option Usage . . . 8
	4. Managing Dynamic Nested Scopes. . . . . . . . . . . . 9		4. Managing Dynamic Nested Scopes. . . . . . . . . . . . 9
	4.1 Updating State for Dynamic Nested Scopes due to		4.1 MADCAP Server processing of MZAP messages. . . . 10
			4.2 Updating State for Dynamic Nested Scopes due to
	Timer Expiration . . . . . . . . . . . . . . 10		Timer Expiration . . . . . . . . . . . . . . 10
	4.2 MADCAP Server processing of MZAP messages. . . . 10
	5. Multicast Scope Nesting State Option Format . . . . . 11		5. Multicast Scope Nesting State Option Format . . . . . 11
	6. Constants . . . . . . . . . . . . . . . . . . . . . . 11		6. Constants . . . . . . . . . . . . . . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . 12
	9. Acknowledgements. . . . . . . . . . . . . . . . . . . 12		9. Acknowledgements. . . . . . . . . . . . . . . . . . . 12
	skipping to change at page 7, line 22 ¶		skipping to change at page 7, line 22 ¶
	o TTL:		o TTL:
	The TTL to be used when sending messages to this scope.		The TTL to be used when sending messages to this scope.
	o Name(s):		o Name(s):
	One or more language specific names for the scope.		One or more language specific names for the scope.
	3.2 Representing the Multicast Scope Nesting State		3.2 Representing the Multicast Scope Nesting State
	Given a Multicast Scope List containing descriptions for n scopes one		Given a Multicast Scope List containing descriptions for n scopes one
	can form n(n-1)/2 pairings. As was shown in section 2.1.1 each		can form n(n-1)/2 pairings. As was shown in section 2 each pairing
	pairing can take on one of four possible states. Thus, for a list of		can take on one of four possible states. Thus, for a list of n scopes
	n scopes there exists 2 pieces of information for each pairing for a		there exists 2 pieces of information for each pairing for a total of
	total of n(n-1) pieces of information regarding which scopes do and		n(n-1) pieces of information regarding which scopes do and do not
	do not nest inside each other. This information is most easily and		nest inside each other.
	efficiently conveyed in a compressed bit matrix as shown in section
	2.4.
	The Multicast Nesting State option must convey a total of n(n-1)
	pieces of state, where n is the number of scopes listed in the
	preceding Multicast Scope List Option. This information will be
	sparse, since at most only a few scopes will nest.
	There are several ways to represent this information using full		There are several ways to represent this state using full matrices,
	matrices, sparse-matrices, and using lists of variable length lists.		sparse-matrices, and using lists of variable length lists. In the
	In the interests of maximal efficiency and flexibility, the Multicast		interests of maximal efficiency and flexibility, the Multicast
	Nesting State Option uses a bit-packed matrix approach. In this		Nesting State Option uses a bit-packed matrix approach. In this
	approach a matrix is constructed using pieces of X/Y state where X is		approach a matrix is constructed using pieces of X/Y state where X is
	the row and Y is the column. A "1" in the matrix means that the		the row and Y is the column. A "1" in the matrix means that the
	relationship "row nests inside column" is true, while a "0" means		relationship "row nests inside column" is true, while a "0" means
	that this relationship is either false or indeterminate. The		that this relationship is either false or indeterminate. The
	diagonal of the matrix is removed, since this is the case where X is		diagonal of the matrix is removed, since this is the case where X is
	the same as Y, and each row is then zero-padded to the next byte		the same as Y, and each row is then zero-padded to the next byte
	boundary to give the final representation.		boundary to give the final representation.
	An example of how a matrix would be constructed for the following		An example of how a matrix would be constructed for the following
	skipping to change at page 8, line 44 ¶		skipping to change at page 8, line 44 ¶
	The "Multicast Scope Nesting State" option is dependent upon the		The "Multicast Scope Nesting State" option is dependent upon the
	"Multicast Scope List" option. This decision was made according to		"Multicast Scope List" option. This decision was made according to
	the following reasoning. The Multicast Nest State Option requires		the following reasoning. The Multicast Nest State Option requires
	that the scopes be identified along with their nesting properties.		that the scopes be identified along with their nesting properties.
	Since the information needed to describe a scope is contained in the		Since the information needed to describe a scope is contained in the
	Multicast Scope List option and this information can change, the		Multicast Scope List option and this information can change, the
	MADCAP messages that contain the Multicast Scope Nesting State option		MADCAP messages that contain the Multicast Scope Nesting State option
	must be atomic and therefore must include the "Multicast Scope List		must be atomic and therefore must include the "Multicast Scope List
	Option."		Option."
	Thus, the "Multicast Scope Nesting State" option MAY only be used in		Thus, the "Multicast Scope Nesting State" option MUST only be used in
	messages that carry the "Multicast Scope List" option, specifically:		messages that carry the "Multicast Scope List" option, specifically:
	ACK (in response to GETINFO)		ACK (in response to GETINFO)
	Since the Multicast Nest State option is dependent upon the Multicast		Since the Multicast Nest State option is dependent upon the Multicast
	Scope List option, it MUST NOT be included without the Multicast		Scope List option, it MUST NOT be included without the Multicast
	Scope List option.		Scope List option.
	Clients that need to explicitly learn the nesting relationships		Clients that need to explicitly learn the nesting relationships
	between scopes should therefore send a GETINFO message to the server		between scopes should therefore send a GETINFO message to the server
	with the "Multicast Scope List" AND "Multicast Scope Nesting State"		with the "Multicast Scope List" AND "Multicast Scope Nesting State"
	option codes listed in an Option Request option.		option codes listed in an Option Request option.
	4. Managing Dynamic Nested Scopes		4. Managing Dynamically Nested Scopes
	In the case where scopes are dynamically configured and hence the		Scopes can either be manually or automatically configured. When
	scope boundaries and nesting relationships may change, MADCAP servers		scopes are manually configured the relationships between them will
	MUST include a mechanism to allow for:		also be static, assuming that network does not partition due to
			router failure. Should the network partition or heal after a
			partition it is highly likely that the nesting relationships will
			change. Scope nesting relationships will also change as a network is
			brought up or when a change is deliberately made to a router either
			through manual reconfiguration or by some automatic means.
			To ensure that nesting relationships are correctly determined when
			scope boundaries undergo change MADCAP servers MUST include a
			mechanism that allow for:
	a) whether the nesting decision is still under consideration or		a) whether the nesting decision is still under consideration or
	can be considered definitive, and therefore be announced to		can be considered definitive, and therefore be announced to
	MADCAP clients.		MADCAP clients.
	b) whether one or both scopes for a particular nesting state entry		b) whether one or both scopes for a particular nesting state entry
	have been destroyed, and hence whether the nesting state should		have been destroyed, and hence whether the nesting state should
	therefore be discarded.		therefore be discarded.
	c) whether the scope boundaries have changed so that whereas scope		c) whether the scope boundaries have changed so that whereas scope
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	The NEST_NO_DECISION_TIMER timer will also be used to timeout X/Y =		The NEST_NO_DECISION_TIMER timer will also be used to timeout X/Y =
	"false" state to allow X/Y to be reset to true in the event that the		"false" state to allow X/Y to be reset to true in the event that the
	boundaries for zone X and zone Y change so that zone X now nests		boundaries for zone X and zone Y change so that zone X now nests
	inside zone Y.		inside zone Y.
	The second timer ZONES_EXIST_TIMER will be used to timeout the		The second timer ZONES_EXIST_TIMER will be used to timeout the
	internal state between two scopes in the event that one or both		internal state between two scopes in the event that one or both
	scopes are destroyed.		scopes are destroyed.
	4.1 Updating State for Dynamic Scopes due to timer expiration.		4.1 MADCAP Server processing of MZAP messages
			When MZAP is used to discover the nesting relationship between scopes
			MADCAP servers will eavesdrop into the MZAP messages that are
			periodically transmitted by the Zone Border Routers (ZBR) during the
			normal course of administrative scope boundary maintenance. In this
			way they will be able to learn which scopes exist (via Zone
			Announcement Messages, ZAMs) and which of these scopes do not nest
			(via Not Inside Messages, NIMs). This state must be cached within the
			MADCAP server.
			When a MADCAP server S receives a NIM from a ZBR containing
			information that scope X does not nest in scope Y, it MUST update its
			internal state in the following manner.
			1) S MUST update its internal X/Y state to "false".
			2) S MUST restart NEST_NO_DECISION_TIMER for the newly updated
			X/Y state.
			4.2 Updating State for Dynamic Scopes due to timer expiration.
	MADCAP servers will update X/Y nesting state upon the expiration of		MADCAP servers will update X/Y nesting state upon the expiration of
	timers in the following manner.		timers in the following manner.
	o If the NEST_NO_DECISION_TIMER expires for a state entry X/Y AND no		o If the NEST_NO_DECISION_TIMER expires for a state entry X/Y AND no
	messages have been received that indicate scope X does not nest		MADCAP messages have been received that indicate scope X does not
	inside scope Y, a MADCAP Server, S, MAY conclude that scope X		nest inside scope Y, a MADCAP Server, S, MUST conclude that scope
			X
	nests inside scope Y. As a result S will change X/Y from "false"		nests inside scope Y. As a result S will change X/Y from "false"
	to "true".		to "true".
	When a state change from "false" to "true" occurs for X/Y, S must		When a state change from "false" to "true" occurs for X/Y, S must
	also start the ZONES_EXIST_TIMER timer for X/Y. The		also start the ZONES_EXIST_TIMER timer for X/Y. The
	ZONES_EXIST_TIMER should only reset when a Zone Announcement		ZONES_EXIST_TIMER should only reset when a Zone Announcement
	Message		Message
	(ZAM) has been received for both zone X and zone Y since the		(ZAM) has been received for both zone X and zone Y since the
	last time it was restarted. This ensures that both zone X and		last time it was restarted. This ensures that both zone X and
	zone Y are known to still exist.		zone Y are known to still exist.
	o If the ZONES_EXIST_TIMER expires for a state entry X/Y, S		o If the ZONES_EXIST_TIMER expires for a state entry X/Y, S
	SHOULD conclude that either zone Y or zone X no longer exists and		SHOULD conclude that either zone Y or zone X no longer exists and
	hence that both X/Y and Y/X state should be destroyed.		hence that both X/Y and Y/X state should be destroyed.
	4.2 MADCAP Server processing of MZAP messages
	When MZAP is used to discover the nesting relationship between scopes
	MADCAP servers will eavesdrop into the MZAP messages that are
	periodically transmitted by the Zone Border Routers (ZBR) during the
	normal course of administrative scope boundary maintenance. In this
	way they will be able to learn which scopes exist (via Zone
	Announcement Messages, ZAMs) and which of these scopes do not nest
	(via Not Inside Messages, NIMs). This state must be cached within the
	MADCAP server.
	When a MADCAP server S receives a NIM from a ZBR containing
	information that scope X does not nest in scope Y, it MUST update its
	internal state in the following manner.
	1) S MUST update its internal X/Y state to "false".
	2) S MUST restart NEST_NO_DECISION_TIMER for the newly updated
	X/Y state.
	5. Multicast Scope Nesting State Option Format		5. Multicast Scope Nesting State Option Format
	Code Len Count Nest State Matrix		Code Len Count Nest State Matrix
	+-----+-----+-----+-----+-----+-----+-...-+-----+		+-----+-----+-----+-----+-----+-----+-...-+-----+
	| OPTID | p | m | N1 | | Nm |		| OPTID | p | m | N1 | | Nm |
	+-----+-----+-----+-----+-----+-----+-...-+-----+		+-----+-----+-----+-----+-----+-----+-...-+-----+
	Code: 16 bits		Code: 16 bits
	Option identifier (OPTID), to be assigned by IANA.		Option identifier (OPTID), to be assigned by IANA.
	Len: 16 bits		Len: 16 bits
	The length of the option in bytes.		The length of the option in bytes.
	Count: 8 bits		Count: 8 bits
	The number of zones present in the Nest State Matrix. This value		The number of zones present in the Nest State Matrix. This value
	MUST be identical to the Count field in the preceding Multicast		MUST be identical to the Count field in the preceding Multicast
	State List option.		State List option. If this is not the case the scope nesting
			state information MUST BE ignored.
	Nest State Matrix:		Nest State Matrix:
	The compressed bit-packed representation of the matrix, derived		The compressed bit-packed representation of the matrix, derived
	in the same manner as shown in Figure 4. Note for N scopes		in the same manner as shown in Figure 4. Note for N scopes
	the compressed matrix will be Nxceil((N-1)/8) bytes long. The		the compressed matrix will be N times ceil((N-1)/8) bytes long,
	scopes corresponding to the rows and columns of this matrix		where ceil() is the function that rounds up to the nearest
			integer.
			The scopes corresponding to the rows and columns of this matrix
	list in the same order as they appear in the Multicast Scope		list in the same order as they appear in the Multicast Scope
	List Option.		List Option.
	6. Constants		6. Constants
	[OPTID] The option identifier for the Multicast Scope Nesting State		[OPTID] The option identifier for the Multicast Scope Nesting State
	option, to be assigned by IANA.		option, to be assigned by IANA.
	[NEST_NO_DECISION_TIMER] The time after which a MADCAP server or		[NEST_NO_DECISION_TIMER] The time after which a MADCAP server or
	client can assume that a message announcing that two zones		client can assume that a message announcing that two zones
	do not nest will not be received. The length of this timer		do not nest should not be received. The length of this timer
	is dependent upon the zone announcement protocol used to		is dependent upon the zone announcement protocol used to
	inform the MADCAP router of which zones currently exist.		inform the MADCAP router of which zones currently exist.
	When MZAP [RFC2776] is used this value should be greater than		When MZAP [RFC2776] is used this value should be greater than
	the MZAP timeout value NIM-INTERVAL +30%. This corresponds		the MZAP timeout value NIM-INTERVAL +30%. This corresponds
	to a timeout value of 1800 + 30% = 2340 seconds (39 minutes).		to a timeout value of 1800 + 30% = 2340 seconds (39 minutes).
	[ZONES_EXIST_TIMER] The time after which a MADCAP server or client		[ZONES_EXIST_TIMER] The time after which a MADCAP server or client
	should assume that the zone in question does not exist when		should assume that the zone in question does not exist when
	zones are detected dynamically. The length of this timer is		zones are detected dynamically. The length of this timer is
	dependent upon the zone announcement protocol used to inform		dependent upon the zone announcement protocol used to inform
End of changes. 16 change blocks.
	51 lines changed or deleted		56 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/