draft-ietf-mboned-sadp-00.txt		draft-ietf-mboned-sadp-01.txt
	Malloc Working Group Roger Kermode		Mboned Working Group Roger Kermode
	Internet Engineering Task Force Motorola		Internet Engineering Task Force Motorola
	INTERNET-DRAFT		INTERNET-DRAFT Dave Thaler
	8 November 1998		22 January 1999 Microsoft
	Expires 8 May 1999		Expires 22 July 1999
	Scoped Address Discovery Protocol (SADP)		Scoped Address Discovery Protocol (SADP)
	<draft-ietf-mboned-sadp-00.txt>		<draft-ietf-mboned-sadp-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet Draft. Internet Drafts are working		This document is an Internet-Draft and is in full conformance
	documents of the Internet Engineering Task Force (IETF), its Areas,		with all provisions of Section 10 of RFC2026.
	and its Working Groups. Note that other groups may also distribute
	working documents as Internet Drafts.
	Internet Drafts are valid for a maximum of six months and may be		Internet-Drafts are working documents of the Internet Engineering
	updated, replaced, or obsoleted by other documents at any time. It		Task Force (IETF), its areas, and its working groups. Note that
	is inappropriate to use Internet Drafts as reference material or to		other groups may also distribute working documents as
	cite them other than as a "work in progress".		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."
			To view the list Internet-Draft Shadow Directories, see
			http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document defines a protocol, the Scoped Address Discovery		This document defines an application-layer protocol, the Scoped
	Protocol (SADP), for discovering the scoped multicast address(es)		Address Discovery Protocol (SADP), for discovering the scoped
	associated with a session at particular scopes within a		multicast address(es) associated with a session at particular scopes
	hierarchically nested set of multicast zones. SADP is designed to		within a hierarchically nested set of multicast scopes. SADP is
	work within the context of Multicast Address Allocation Architecture		designed to work within the context of Multicast Address Allocation
	[MAAA] consisting of the MZAP [MZAP], MASC [MASC], and AAP [AAP]		Architecture [MAAA]. It is intended that SADP will provide the
	protocols. It is intended that SADP will provide the necessary		necessary general services for reliable multicast and searching
	general services for reliable multicast and searching applications to		applications to use expanding-scope searches in lieu of the well
	use expanding-zone searches in lieu of the well known, but less		known, but less efficient expanding-ring search.
	efficient expanding-ring search.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (1998). All Rights Reserved.		Copyright (C) The Internet Society (1999). All Rights Reserved.
	Contents		Contents
	Abstract. . . . . . . . . . . . . . . . . . . . . . . . . 1		Abstract. . . . . . . . . . . . . . . . . . . . . . . . . 1
	1. Introduction. . . . . . . . . . . . . . . . . . . . . 3		1. Introduction. . . . . . . . . . . . . . . . . . . . . 3
	2. Overview. . . . . . . . . . . . . . . . . . . . . . . 4		2. Overview. . . . . . . . . . . . . . . . . . . . . . . 4
	3. Usage . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Usage . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1 Session Identifiers . . . . . . . . . . . . . . . . 6		3.1 Session Identifiers . . . . . . . . . . . . . . . . 6
	3.2 Session Member Operation. . . . . . . . . . . . . . 6		3.2 Session Member Operation. . . . . . . . . . . . . . 6
	3.3 SADP Server Operation . . . . . . . . . . . . . . . 7		3.3 SADP Server Operation . . . . . . . . . . . . . . . 7
	4. Packet Formats. . . . . . . . . . . . . . . . . . . . 8		4. Packet Formats. . . . . . . . . . . . . . . . . . . . 8
	4.1 SADP Request. . . . . . . . . . . . . . . . . . . . 10		4.1 SADP Request. . . . . . . . . . . . . . . . . . . . 10
	4.2 SADP Response . . . . . . . . . . . . . . . . . . . 10		4.2 SADP Response . . . . . . . . . . . . . . . . . . . 10
			4.2 SADP New Address. . . . . . . . . . . . . . . . . . 11
	5. Constants . . . . . . . . . . . . . . . . . . . . . . 11		5. Constants . . . . . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . 11
	7. Acknowledgements. . . . . . . . . . . . . . . . . . . 12		7. Acknowledgements. . . . . . . . . . . . . . . . . . . 11
	8. References. . . . . . . . . . . . . . . . . . . . . . 12		8. References. . . . . . . . . . . . . . . . . . . . . . 11
	9. Author's Address. . . . . . . . . . . . . . . . . . . 13		9. Author's Address. . . . . . . . . . . . . . . . . . . 12
	10. Full Copyright Statement. . . . . . . . . . . . . . . 13		10. Full Copyright Statement. . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	Administrative scoping [RFC2365] provide a useful means for limiting		Administrative scoping [RFC2365] provides a useful means for limiting
	the spread of IP multicast traffic acros the Internet. Unlike Time-		the spread of IP multicast traffic across the Internet. Unlike Time-
	To-Live (TTL) scoping, administrative scoping provides the means to		To-Live (TTL) scoping, administrative scoping provides the means to
	ensure that, for a given scope and ignoring packet loss, the same set		ensure that, for a given scope and ignoring packet loss, the same set
	of nodes will receive a message, regardless of which node sent the		of nodes will receive a message, regardless of which node sent the
	message. Thus, the use of administrative scoping greatly simplifies		message. Thus, the use of administrative scoping greatly simplifies
	the design of multicast protocols that require localization, since		the design of multicast protocols that require localization, since
	the non-reception of sent packets is solely due to loss and not		the non-reception of sent packets is solely due to loss and not
	design.		design.
	The Multicast Zone Announcement Protocol (MZAP) [MZAP] will provide		The Multicast Address Dynamic Client Allocation Protocol (MADCAP)
	applications with the means for discovering the various scopes that		[MADCAP] will provide applications with the means for discovering the
	are locally visible at each point in the Internet. In addition, MZAP		various scopes that are locally visible at each point in the
	will also provide the means for determining and announcing which		Internet. The determination of which scopes nest inside each other
	scope zones completely encapsulate others. This additional ability		will be performed by the Multicast-Scope Zone Announcement Protocol
	will allow scope zones to be arranged into hierarchies which		(MZAP) [MZAP]. MZAP's ability to provide this service will allow
	applications can then used expanding zone searches instead of less		scopes to be arranged into hierarchies so that applications can then
	efficient and more problematic expanding-ring (TTL) searches. One		use expanding scope searches instead of the less efficient and more
	example of how expanding-zone searches provide increased localization		problematic expanding-ring (TTL) searches. One example of how
	can be found in the Scoped Hybrid Automatic Repear reQuest with		expanding-scope searches provide increased localization can be found
	Forward Error Correction (SHARQFEC) reliable multicast protocol		in the Scoped Hybrid Automatic Repeat reQuest with Forward Error
	[SHARQFEC].		Correction (SHARQFEC) reliable multicast protocol [SHARQFEC].
	While expanding-ring searches use one multicast address and		While expanding-ring searches use one multicast address and
	increasing TTLs, expanding-zone searches involve changing the		increasing TTLs, expanding-scope searches involve changing the
	multicast addresses for each attempt at a different scope. SADP		multicast addresses for each attempt at a different scope. For well-
	builds upon the Multicast Address Allocation Architecture [MAAA] by		known services, these addresses can be obtained by applying an IANA-
	adding a new service that allows applications to discover the		assigned offset from the top of the scope's address range.
	relevant multicast address(es) associated with a session at each		Applications, on the other hand, generally require the use of
	level in a hierarchy of scope zones. SADP does not provide the means		dynamically allocated addresses with offsets that will most likely
	to allocate an address should one not be present for a session in a		vary from scope to scope.
	particular zone. In this case the application should use the Address
	Allocation Protocol (AAP) [AAP] to allocate a new address for the		SADP builds upon the Multicast Address Allocation Architecture [MAAA]
	scope, which can then be announced to other application instances		by adding a new application-layer service that allows applications to
	within the scope.		discover the relevant multicast address(es) associated with a session
			at each level in a hierarchy of scopes.
			SADP does not provide the means to allocate an address should one not
			be present for a session in a particular zone. In this case the
			application should take steps to obtain an address for that scope and
			then announce it to other application instances that join that scope
			at a later time. One proposed mechanism for allocating addresses is
			the Multicast Address Dynamic Allocation Protocol (MADCAP) [MADCAP].
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Overview		2. Overview
	Administrative scoping affords the ability to create network		Administrative scoping affords the ability to create network
	partitions or zones in which multicast traffic addressed to one of a		partitions or zones in which multicast traffic addressed to one of a
	block of addresses assigned to that zone will be limited to that		block of addresses assigned to that zone will be limited to that
	zone. The boundary of the zone is enforced by Zone Border Routers		zone. The boundary of the zone is enforced by Zone Border Routers
	(ZBRs) that reside at the edges of the zone. ZBRs must be carefully		(ZBRs) that reside at the edges of the zone. ZBRs must be carefully
	configured so that traffic addressed within the zone does not pass		configured so that traffic addressed within the zone does not pass
	outside the zone. This can be a non trivial task, and hence the		outside the zone. Ensuring consistency among boundary routers can be
	Multicast Zone Announcement Protocol (MZAP) [MZAP], which is used to		a non-trivial task, and hence the Multicast Zone Announcement
	announce the existence of zones, also provides the mechanisms to		Protocol (MZAP) [MZAP], which is used to announce the existence of
	detect ZBR misconfigurations.		zones, also provides the mechanisms to detect ZBR misconfigurations.
	. . . . . . . . . +B+------>		. . . . . . . . . +B+------>
	. . /		. . /
	. *		. *
	. <---+A*--------+C+--->		. <---+A*--------+C+--->
	. + .		. + .
	. / .		. / .
	. Zone X <--- .		. Zone X <--- .
	. . . . . . ...		. . . . . . ...
	skipping to change at page 4, line 42		skipping to change at page 4, line 46
	the services of zone announcement and fault detection, MZAP also		the services of zone announcement and fault detection, MZAP also
	provides mechanisms for determining and announcing the existence of		provides mechanisms for determining and announcing the existence of
	zones that nest inside others as shown in Figure 2.		zones that nest inside others as shown in Figure 2.
	+-----------+ +-----------+ +-------------+		+-----------+ +-----------+ +-------------+
	| zone a | | zone c | | zone e |		| zone a | | zone c | | zone e |
	| +------+| | +------+ | . . . . .|..		| +------+| | +------+ | . . . . .|..
	| |zone b|| | |zone d| | : zone f | :		| |zone b|| | |zone d| | : zone f | :
	| +------+| | | | | : | :		| +------+| | | | | : | :
	+-----------+ +----+------+ +-------------+ :		+-----------+ +----+------+ +-------------+ :
	:. . . . ..:		: . . . . . :
	(a) "Contained" (b) "Common Border" (c) "Overlap"		(a) "Contained" (b) "Common Border" (c) "Overlap"
	zone b nests zone d nests zones e and f		zone b nests zone d nests zones e and f
	inside zone a inside zone c do not nest		inside zone a inside zone c do not nest
	Figure 2: Zone nesting examples		Figure 2: Zone nesting examples
	This feature allows admin scope zones to be arranged in a hierarchy		This feature allows admin scope zones to be arranged in a hierarchy
	as shown in Figure 3. The ability to nest admin scope zones in		as shown in Figure 3. The ability to nest admin scope zones in
	hierarchies like that shown in Figure 3 is useful since it affords		hierarchies like that shown in Figure 3 is useful since it affords
	localization through expanding-zone searches. For example, consider a		localization through expanding-scope searches. For example, consider
	distributed application with session members distributed evenly		a distributed application with session members distributed evenly
	through out zone a. A session member in zone e, would perform a		through out zone a. A session member in scope e, would perform a
	search by multicasting a query within zone e, and if unsuccessful,		search by multicasting a query within scope e, and if unsuccessful,
	expand the scope to search in zone b, and eventually zone a if so		expand the scope to search in scope b, and eventually scope a if so
	needed.		needed.
	. . . . . . . . . . . . . . . . ..		. . . . . . . . . . . . . . . . ..
	. zone a . Zone Boundaries		. scope a . Scope Boundaries
	. . . = zone a		. . . = scope a
	. ______________ ______________ . - = zones b,c		. _______________ ________________ . - = scopes b,c
	. / zone b \ / zone c \ . # = zones d,e,f, & g		. / scope b \ / scope c \ . # = scopes d,e,f, & g
	.| | | |.		.| | | |.
	.| #### #### | | #### #### |.		.| ##### ##### | | ##### ##### |.
	.| #zone# #zone# | | #zone# #zone# |.		.| #scope# #scope#| | #scope# #scope# |.
	.\ # d # # e # | | # f # # g # /.		.\ # d # # e # | | # f # # g # /.
	.\ ### #### / \ #### #### /.		.\ #### #####/ #### #### /.
	.\___________/ \____________/.		.\____________/ _____________/.
	. . . . . . . . . . . . . . . . ..		. . . . . . . . . . . . . . . . .
	Figure 3 : Zone Nesting Hierarchy example		Figure 3 : Admin Scope Zone Nesting Hierarchy example
	In order for expanding-zone searches to be feasible, session members		In order for expanding-scope searches to be feasible, session members
	must be able to determine two things:		must be able to determine two things:
	o which zones are involved in the hierarchy for a particular session.		o which scopes are involved in the hierarchy for a particular
			session.
	o what address(es) are to be used for communicating with other		o what address(es) are to be used for communicating with other
	session members within the zones involved in the hierarchy.		session members within these scopes.
	SADP affords the ability to discover this information by using a		SADP affords the ability to discover this information by using a
	single multicast group at each scope [SADP-RELATIVE-GROUP] for		single multicast group inside each scope [SADP-RELATIVE-GROUP] for
	communication between SADP servers and the members of various		communication between SADP servers (see section 3.2) and the members
	sessions. New members to a session use the channels provided by the		of various sessions. New members to a session use the channels
	addresses to query existing SADP servers and session members as to		provided by the addresses to query existing SADP servers and session
	which specific zones are valid and which zones to use. Since there is		members as to which specific scopes are valid and which scopes to
	only one multicast address used per zone for this purpose, members of		use. Since there is only one multicast address used per admin scope
	a particular session will ignore traffic intended for members of		zone for this purpose, members of a particular session will ignore
	another session.		traffic intended for members of another session.
	3. Usage		3. Usage
	In this section we summarize how session members can use SADP to		In this section we summarize how session members can use SADP to
	determine which admin zones are used by the session's hierarchy and		determine which admin zones are used by the session's hierarchy and
	also the address(es) within these zones that are used by the current		also the address(es) within these zones that are used by the current
	session members should such addresses exist.		session members should such addresses exist.
	3.1 Session Identifiers		3.1 Session Identifiers
	Each session that uses admin scoping will use a Globally Unique		Each session that uses administrative scoping will be identified by a
	Session Identifier (GUSID) that will distinguish it from all other		Session Identifier (SID) that corresponds to the address of the group
	sessions. This GUSID will consists of a 128bit integer that is		used in the largest scope zone. Applications that require multiple
	allocated dynamically using the process described in [UUID]. The		addresses shall be decomposed into multiple individual sessions which
	GUSID will be allocated by the session creator and will be used to		will then be treated independently.
	associate traffic with a particular session regardless of which
	multicast scoped address the traffic is sent to.
	3.2 Session Member Operation		3.2 Session Member Operation
	Several predefined administrative scopes already exist [RFC2365]:		Several predefined administrative scopes already exist [RFC2365]:
	o Link Local: Traffic is only carried across one physical link.		o Link Local: Traffic is only carried across one physical link.
	o Local: Traffic is restricted to a specific network region.		o Local: Traffic is restricted to a specific network region.
	o Global: The entire multicast enabled network.		o Global: The entire multicast enabled network.
	By definition Link Local zones nest inside Local zone which in turn		By definition Link Local scopes nest inside Local scopes which in
	nests inside the Global zone. Other zones may exist between the local		turn nest inside the Global Scope. Other scopes may exist between the
	and global scopes. These zones are constructed by the union of two or		local and global scopes. These scopes are constructed by the union of
	more local zones and are announced to routers within their confines		the admin scope zones that correspond to two or more topologically
	using MZAP [MZAP].		adjacent local scopes and are announced to routers within their
			confines using MZAP [MZAP].
	The general algorithm that new members to a session should use to		The general algorithm that new members to a session should use to
	determine which zones and addresses are involved in the hierarchy for		determine which scopes and addresses are involved in the hierarchy
	a particular session is as follows:		for a particular session is as follows:
	1) Determine the GUSID, largest zone, and addresses for the largest		1) Determine largest scope, and address for the largest scope for
	zone for the session. (this task is beyond the scope of this		the session. (this task is beyond the scope of this document,
	document, but can be assumed to involve some kind of out-of-band		but can be assumed to involve some kind of out-of-band
	communication.)		communication.)
	2) Starting with the SADP group [SADP-RELATIVE-GROUP] for the		2) Starting with the SADP group [SADP-RELATIVE-GROUP] for the
	local scope, issue a SADP Request (SADP_REQ) message		local scope, issue a SADP Request (SADP_REQ) message
	containing the GUSID address.		containing the SID address.
	3) Wait for a response on the SADP [SADP-RELATIVE-GROUP] address		3) Wait for a response on the SADP [SADP-RELATIVE-GROUP] address
	for at least [SADP-REQ-TIMEOUT] seconds. If no response is		for at least [SADP-REQ-TIMEOUT] seconds. If no response is
	heard increase the scope to the next largest zone and repeat step		heard, wait for some small amount of time, and then
	2. In cases where there are two non-nesting zones larger than the		repeat the request at the same scope.
	current try one zone and then the other, should the first zone not
	result in a reply.
	4) Continue steps 2) and 3) until the largest zone has been queried		4) If after a total of 3 attempts at a given scope, no response
	or a response has been heard.		has been received, increase the scope to the next largest scope
			and repeat steps 2 and 3. In cases where there are two
			non-nesting scopes larger than the current, try one scope and
			then the other, should the first scope not result in a reply.
			5) Continue steps 2), 3), and 4) until the largest scope has been
			queried or a response has been heard.
	In cases where the scope must be increased in order to find a session		In cases where the scope must be increased in order to find a session
	member that can reply, the new session member MAY decide to add		member that can reply, the new session member MAY decide to add
	levels to the hierarchy in order to increase localization for future		levels to the hierarchy in order to increase localization for future
	session members. New session members that decide to take this step		session members. New session members that decide to take this step
	will use the existing addresses as discovered using SADP and request		will use the existing addresses as discovered using SADP and request
	new ones using AAP [AAP].		new ones. (e.g., via MADCAP [MADCAP]). Upon the successful
			allocation of a new address for use in the hierarchy, the new session
			member shall announce the new address via a SADP_NEW_ADDR message to
			the [SADP-RELATIVE-GROUP] address for the scope in which the address
			was allocated. This will cause the address to be cached by any SADP
			servers within the new address's scope.
	SADP servers and existing session members, upon hearing an SADP_REQ		SADP servers and existing session members, upon hearing an SADP_REQ
	message from a new session member will issue an SADP Response		message from a new session member from [SADP-RELATIVE-GROUP] at a
	(SADP_RESP) after waiting for a random amount of time (T) that is		particular scope will issue an SADP Response (SADP_RESP) to the
	calculated as follows:		[SADP-RELATIVE-GROUP] at the same scope after waiting for a random
			amount of time (T) that is calculated as follows:
	Choose a random value X from a uniform random interval [0:1]		Choose a random value X from a uniform random interval [0:1] Let
	Let C = 256		C = 256 Set
	Set T = [SADP-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C)		T = [SADP-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C)
	Should a member receive a SADP_RESP before its timer it expires it		Should a member receive a SADP_RESP before its timer it expires it
	SHALL suppress its own response. This method ensures that close to		SHALL suppress its own response. This method ensures that close to
	one session member will respond.		one session member will respond.
	3.2 SADP Server Operation		3.3 SADP Server Operation
	Were SADP to be deployed in a wide scale session with the members of		Were SADP to be deployed in a wide scale session with the members of
	various sessions to use SADP between each other it would quickly		various sessions to use SADP between each other it would quickly
	cause catastrophic congestion. The reason for this is that whenever a		cause catastrophic congestion. The reason for this is that whenever a
	new node joined a sparsely populated session with a large maximum		new node joined a sparsely populated session with a large maximum
	scope, it would inevitably end up sending SADP_REQs to every scope up		scope, it would inevitably end up sending SADP_REQs to every scope up
	until the largest scope. Thus the highly likely occurrence of having		until the largest scope. Thus the highly likely occurrence of having
	a global and continental scope zones combined with numerous sparse		a global and continental scopes combined with numerous sparse
	sessions (probably on the order of 10,000 to 100,000) would quickly		sessions (probably on the order of 10,000 to 100,000) would quickly
	cause SADP_REQ flooding at the continental scope.		cause SADP_REQ flooding at the continental scope.
	To address this shortcoming SADP allows, and in fact encourages, the		To address this shortcoming SADP allows, and in fact encourages, the
	deployment of SADP servers. These servers subscribe to the [SADP-		deployment of SADP servers. These servers subscribe to the [SADP-
	RELATIVE-GROUP] for each zone they are in and cache the SADP_RESP		RELATIVE-GROUP] for each scope they are in and cache the SADP_RESP
	messages they receive at each scope. Having cached and merged the		messages they receive at each scope. Having cached and merged the
	responses for sessions at various scopes, they can then respond to		responses for sessions at various scopes, they can then respond to
	SADP_REQs heard at lower scopes using the information heard at the		SADP_REQs heard at lower scopes using the information heard at the
	larger scope(s). Should a SADP server hear a SADP_REQ at some		larger scope(s). Should a SADP server hear a SADP_REQ at some
	intermediate scope it MUST NOT announce address information for		intermediate scope it MUST NOT announce address information for
	scopes smaller than one on which the SADP_REQ was received.		scopes smaller than one on which the SADP_REQ was received.
	The effect of allowing larger-scoped information to be announced at		The effect of allowing larger-scoped information to be announced at
	lower scopes by SADP servers significantly reduces the number of		lower scopes by SADP servers significantly reduces the number of
	scopes a new session will have to query. New session members now need		scopes a new session will have to query. New session members now need
	skipping to change at page 8, line 14		skipping to change at page 8, line 34
	Scope b Boundary		Scope b Boundary
	Scope a : Scope a and Scope b		Scope a : Scope a and Scope b
	_________ : ____________ _____________		_________ : ____________ _____________
	/ \ : / \ / \		/ \ : / \ / \
	|Source at| _____:___\ |SADP Server | /___________ | New Session |		|Source at| _____:___\ |SADP Server | /___________ | New Session |
	|Scope a | SADP_RESP/ | Scopes a,b | \ SADP_REQ | Member |		|Scope a | SADP_RESP/ | Scopes a,b | \ SADP_REQ | Member |
	\_________/ : \____________/ ___________\ | Scopes a,b |		\_________/ : \____________/ ___________\ | Scopes a,b |
	: SADP_RESP/ \_____________/		: SADP_RESP/ \_____________/
	:		:
	Figure 4 : SADP Server acting as proxy session member		Figure 4 : SADP Server acting as proxy session member
	4. Packet Formats		4. Packet Formats
	All SADP messages are sent over UDP, with a destination port of		All SADP messages are sent over UDP, with a destination port of
	[SADP-PORT]. THe common SADP message header (which follows the UDP		[SADP-PORT]. The common SADP message header (which follows the UDP
	header), is shown below,		header), is shown below,
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Version | PTYPE |NumScop|AddrFam| NameLen |		| Version | PTYPE | Num Scopes | Addr Family |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Origin |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Session ID (Hi) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Session ID (Mid Hi) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Session ID (Mid Lo) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Session ID (Lo) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Session Name |		| Largest Scope Group Address |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Padding (if needed) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Authentication Block		Authentication Block
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Version: 8 bits		Version: 8 bits
	The version defined in this document is version 0.		The version defined in this document is version 0.
	Packet Type (PTYPE): 8 bits		Packet Type (PTYPE): 8 bits
	The packet types defined in this document are:		The packet types defined in this document are:
	0: SADP Request		0: SADP Request
	1: SADP Response		1: SADP Response
	Number of Scope Entries (NumScop) : 4 bits		2: SADP New Address
	The number of scope entries present within a SADP_RESP message.
	This field should be set to zero for SADP_REQ messages.
	Address Family (AddrFam): 4 bits
	This indicates the format of the following packet. The following
	values are defined by this document:
	0: IPv4
	1: IPv6
	Message Origin: 32 bits (IPv4) or 128 bits (IPv6)
	This gives the IP address of the interface that originated the
	message.
	Session ID Address: 128 bits
	This 128 bit number uniquely identifies a session.
	Name Len:		Number of Scope Entries (Num Scopes) : 4 bits
	The length, in bytes, of the Session Name field.		The number of scope entries present within a SADP_RESP
			message. This field should be set to zero for SADP_REQ messages.
	Session Name: multiple of 8 bits		Address Family (AddrFam): 4 bits
	The Zone Name is an ISO 10646 character string in UTF-8 encoding		This indicates the IANA-assigned address family number to be
	[RFC2279] indicating the name given to the session (e.g.:		used for address contained in this message. Currently assigned
	``42ndIETF-Chicago''). It should be relatively short and MUST be		values are listed in RFC 1700 [RFC1700]. The values for IP
	less than 256 bytes in length. All the session members SHOULD be		addresses are:
	configured to give the same Session Name, or a zero length string		IPv4: 1
	MAY be given. A zero length string is taken to mean that another		IPv6: 2
	session member is expected to be configured with the session
	name. Having ALL the members of a session announce zero length
	names should be considered an error.
	Padding (if needed):		Session ID Address: 32 bits (IPv4) or 128 bits (IPv6)
	The SADP header is padded with null bytes until it is 4-byte		The group address corresponding to the largest scope for this
	aligned.		hierarchy of addresses.
	Authentication Block:		Authentication Block:
	The Authentication Block provides information which can be used		The Authentication Block provides information which can be used
	to confirm that the sender of the SADP message is a valid member		to confirm that the sender of the SADP message is a valid member
	of the session. Session Members that cannot confirm that the		of the session. Session Members that cannot confirm that the
	sender of an SADP Request Message MAY ignore it, while new		sender of an SADP Request Message MAY ignore it, while new
	session members that receiver an SADP Response Message MUST		session members that receive an SADP Response Message MUST
	ignore it. (the format of the authentication block is to be		ignore it. (The format of the authentication block is to be
	decided)		decided)
	4.1 SADP Request		4.1 SADP Request
	SADP Request (SADP_REQ) Messages have PTYPE=0, and are sent by new		SADP Request (SADP_REQ) Messages have PTYPE=0, and are sent by new
	session members that wish to learn which administrative scopes and		session members that wish to learn which administrative scopes and
	multicast addresses to use within a particular session. SADP_REQ		multicast addresses to use within a particular session. SADP_REQ
	Messages are sent according to the algorithm described in 3.2.		Messages are sent according to the algorithm described in 3.2.
	4.2 SADP Response		4.2 SADP Response
	The SADP Response (SADP_RESP) Message has PTYPE=1, and is sent in		The SADP Response (SADP_RESP) Message has PTYPE=1, and is sent in
	response to a SADP_REQ Message. It contains the list of address that		response to a SADP_REQ Message to the same scope from which the
	are to be used by a session within each scope. Session members that		SADP_REQ was received. It contains the address that is to be used by
	transmit SADP Response Messages MUST NOT include zone and address		an application instance within a session for each scope that nests
	information for scopes known to be smaller that of the address upon		within the scope to which the SADP_REQ was sent. (N.B. This includes
	which the triggering SADP Request Message was received.		the scope to which the SADP_REQ was sent) Session members that
			transmit SADP Response Messages MUST NOT include scope and address
			information for scopes that are known to overlap or be larger than
			that of the scope upon which the triggering SADP_REQ Message was
	The format for a SADP Response Message is shown below:		The format for a SADP Response Message is shown below:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	MSADP Header		SADP Header
	+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+		+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
	| MBZ | SCOP | NumSessAddr | MBZ |		| Scope Start Address 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone Start Address 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone Stop Address 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone 1 Session Address 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. . . . . . .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone 1 Session Address K |		| Scope 1 Session Address |
	+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+		+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
	| MBZ | SCOP | NumSessAddr | MBZ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone Start Address N |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone Stop Address N |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone N Session Address 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. . . . . . .		. . . . . . .
			+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
			| Scope Start Address N |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Zone N Session Address L |		| Scope N Session Address |
	+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+		+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
	SCOP : 4 bits
	The SCOP value associated with the zone as defined in RFC 1884
	[RFC1884] for IPv6 and RFC 2365 [RFC2365] for IPv4.
	NumSessAddr : 8 bits
	The number of session address per scope zone that are included.
	Addresses will be listed in ascending order. The correspondence
	between address and channel function is the responsibility of
	the session application.
	MBZ :
	Must Be Zero, these bits must be set to zero, but may be used
	for other functions later revision of the protocol.
	Zone X Start Address : 32 bits (IPv4) or 128 bits (IPv6)		Scope X Start Address : 32 bits (IPv4) or 128 bits (IPv6)
	The smallest address for the block of multicast addresses		The smallest address for the block of multicast addresses
	associated with a zone. If a zone X is valid for the range		associated with a scope. If a scope X is valid for the range
	239.128.0.0 to 239.128.255.255, this field will be set to		239.128.0.0 to 239.128.255.255, this field will be set to
	239.128.0.0.		239.128.0.0.
	Zone X Stop Address : 32 bits (IPv4) or 128 bits (IPv6)		Scope X Session Address : 32 bits (IPv4) or 128 bits (IPv6)
	The largest address for the block of multicast addresses		Address to be used for the named scope.
	associated with a zone. If a zone X is valid for the range
			4.2 SADP New Address
			The SADP New Address (SADP_NEW_ADDR) Message has PTYPE=2. It is
			transmitted by session members that have attempted to find an address
			for a particular scope, failed, and have then subsequently allocated
			a new address for use in the session at that scope. Its purpose is
			to inform other members of the session of the existence of this newly
			allocated address and its availability for subsequent use.
			Should two members attempt to announce a new address to the same
			scope at the same time, their SADP_NEW_ADDR messages will result in a
			collision. SADP_NEW_ADDR collisions are resolved by the session
			members picking the lower of the two addresses.
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			SADP Header
			+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
			| Scope Start Address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| New Scope Session Address |
			+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
			Scope Start Address : 32 bits (IPv4) or 128 bits (IPv6)
			The smallest address for the block of multicast addresses
			associated with a scope. If a scope X is valid for the range
	239.128.0.0 to 239.128.255.255, this field will be set to		239.128.0.0 to 239.128.255.255, this field will be set to
	239.128.255.255.		239.128.0.0.
	Zone X Session Address Y : 32 bits (IPv4) or 128 bits (IPv6)		New Scope Session Address : 32 bits (IPv4) or 128 bits (IPv6)
	Up to Y address may be included for a zone address entry, where		Address of the newly allocated group to be used for the
	Y is equal to the NumSessAddr value for entry X.		specified scope.
	5. Constants		5. Constants
	[SADP-RELATIVE-GROUP]: The relative group with each scope zone, to		[SADP-RELATIVE-GROUP]: The relative group with each scope, to which
	which session members send SADP Requests and Responses. All sessions		session members send SADP Requests and Responses. All application
	that use administratively scoped multicast MUST subscribe to this		instances that use SADP for constructing hierarchies of scopes MUST
	address.		subscribe to this address for each scope which nests within the
			session scope, in order to ensure that each application instance uses
			the hierarchy in the most efficient manner.
	[SADP-REQ-TIMEOUT]: The time after which a session member that sends		[SADP-REQ-TIMEOUT]: The time after which a session member that sends
	SADP Request should wait before concluding that no session members		SADP Request should wait before concluding that no session members
	are present at the current scope. Default value is 3 seconds.		are present at the current scope. Default value is 3 seconds.
	[SADP-SUPPRESSION-INTERVAL]: The interval over which a session member		[SADP-SUPPRESSION-INTERVAL]: The interval over which a session member
	chooses a random delay before responding to SADP Request. Default		chooses a random delay before responding to SADP Request. Default
	value 2 seconds.		value 2 seconds.
	6. Security Considerations		6. Security Considerations
	SADP employs distributed mechanisms to allow new session members to		SADP employs distributed mechanisms to allow new session members to
	learn of the existence of session-specific admin scoped multicast		learn of the existence of session-specific admin scoped multicast
	address. This fact lay SADP open to attack by malicious hosts that		address. This fact lays SADP open to attack by malicious hosts that
	could potentially mis-inform new session members of incorrect		could potentially mis-inform new session members of incorrect
	addresses, thereby affecting a man-in-the-middle attack.		addresses, thereby affecting a man-in-the-middle attack.
	To prevent attacks of this nature by non-session members from		To prevent attacks of this nature by non-session members from
	occurring all SADP messages are signed by the sender. However, this		occurring all SADP messages are signed by the sender. However, this
	measure does not prevent malicious hosts from joining a session and		measure does not prevent malicious hosts from joining a session and
	then performing the same attack. Hence, SADP's security depends upon		then performing the same attack. Hence, SADP's security depends upon
	a suitable gating process for new-member admittance combined with (as		a suitable gating process for new-member admittance combined with (as
	yet to be determined) mechanisms that allow spoofed SADP messages to		yet to be determined) mechanisms that allow spoofed SADP messages to
	be identified for removal before processing.		be identified for removal before processing.
	7. Acknowledgments		7. Acknowledgments
	The Author would like to acknowledge Mark Handley and Dave Thaler for		The Authors would like to acknowledge Mark Handley for the helpful
	the helpful discussions and feedback which helped shape and refine		discussions and feedback which helped shape and refine this document.
	this document.
	8. References		8. References
	[AAP] Handley, M., "The Address Allocation Protocol", Internet		[MADCAP] Patel. B.V., Shah, M., Hanna, S.R., "Multicast Address
	Draft, August 1998.		Dynamic Client Allocation Protocol (MADCAP)", Internet
			Draft, draft-ietf-malloc-madcap-03.txt, February 1999.
	[MAAA] Handley, M., Thaler, D., and D. Estrin, "The Internet		[MAAA] Handley, M., Thaler, D., and D. Estrin, "The Internet
	Multicast Address Allocation Architecture", Internet		Multicast Address Allocation Architecture", Internet
	Draft, December 1997.		Draft, December 1997.
	[MZAP] Handley, M., Thaler, D., "Multicast-Scope Zone		[MZAP] Handley, M., Thaler, D., "Multicast-Scope Zone
	Announcement Protocol (MZAP)",		Announcement Protocol (MZAP)",
	draft-ietf-mboned-mzap-02.txt, Internet-Draft, August,		draft-ietf-mboned-mzap-02.txt, Internet-Draft, August,
	1998.		1998.
			[RFC1700] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700,
			October 1994.
	[RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing		[RFC1884] Hinden, R., Deering, S., "IP Version 6 Addressing
	Architecture", RFC 1884, December 1995.		Architecture", RFC 1884, December 1995.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP, RFC 2119, March 1997.		Requirement Levels", BCP, RFC 2119, March 1997.
	[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", RFC 2279, January 1998.
	[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP,		[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP,
	RFC 2365, July 1998.		RFC 2365, July 1998.
	[SHARQFEC] Kermode, R., "Scoped Hybrid Automatic Repeat reQuest with		[SHARQFEC] Kermode, R., "Scoped Hybrid Automatic Repeat reQuest with
	Forward Error Correction (SHARQFEC)", ACM SIGCOMM98,		Forward Error Correction (SHARQFEC)", ACM SIGCOMM98,
	Vancouver Canada, September 1998.		Vancouver Canada, September 1998.
	[UUID] Leach, J., Salz, R., "UUIDs and GUIDs",		9. Authors' Addresses
	draft-leach-uuids-guids-01.txt, Internet-Draft, February,
	1998.
	9. Author's Address
	Roger Kermode		Roger Kermode
	Motorola		Motorola Australia Research Centre
	Chicago Corporate Research Laboratories		12 Lord St.
	1301 East Algonquiin Rd, MS IL02-2712		Botany, NSW 2091
	Schaumburg, IL 60196		Australia
			Email: Roger_Kermode@email.mot.com
	Phone: (847) 538 4587		David Thaler
	Email: ark008@email.mot.com		Microsoft
			One Microsoft Way
			Redmond, WA 98052
			USA
			Email: dthaler@microsoft.com
	10. Full Copyright Statement		10. Full Copyright Statement
	Copyright (C) The Internet Society (1998). All Rights Reserved.		Copyright (C) The Internet Society (1999). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it or		others, and derivative works that comment on or otherwise explain it
	assist in its implementation may be prepared, copied, published and		or assist in its implementation may be prepared, copied, published
	distributed, in whole or in part, without restriction of any kind,		and distributed, in whole or in part, without restriction of any
	provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of developing		Internet organizations, except as needed for the purpose of
	Internet standards in which case the procedures for copyrights defined		developing Internet standards in which case the procedures for
	in the Internet languages other than English.		copyrights defined in the Internet languages other than English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/