draft-ietf-mboned-sadp-01.txt		draft-ietf-mboned-sadp-02.txt
	Mboned Working Group Roger Kermode		Mboned Working Group Roger Kermode
	Internet Engineering Task Force Motorola		Internet Engineering Task Force Motorola
	INTERNET-DRAFT Dave Thaler		INTERNET-DRAFT Dave Thaler
	22 January 1999 Microsoft		5 September 2000 Microsoft
	Expires 22 July 1999		Expires 5 March 2001
	Scoped Address Discovery Protocol (SADP)		Scoped Address Discovery Protocol (SADP)
	<draft-ietf-mboned-sadp-01.txt>		<draft-ietf-mboned-sadp-02.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.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-		documents at any time. It is inappropriate to use Internet-
	Drafts as reference material or to cite them other than as		Drafts as reference material or to cite them other than as
	"work in progress."		"work in progress."
	To view the list Internet-Draft Shadow Directories, see		The list of current Internet-Drafts can be accessed at
			http://www.ietf.org/ietf/1id-abstracts.txt
			The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document defines an application-layer protocol, the Scoped		This document defines an application-layer protocol, the Scoped
	Address Discovery Protocol (SADP), for discovering the scoped		Address Discovery Protocol (SADP), for discovering the scoped
	multicast address(es) associated with a session at particular scopes		multicast address(es) associated with a session at particular scopes
	within a hierarchically nested set of multicast scopes. SADP is		within a hierarchically nested set of multicast scopes. SADP is
	designed to work within the context of Multicast Address Allocation		designed to work within the context of Multicast Address Allocation
	Architecture [MAAA]. It is intended that SADP will provide the		Architecture [MAAA]. It is intended that SADP will provide the
	necessary general services for reliable multicast and searching		necessary general services for reliable multicast and searching
	applications to use expanding-scope searches in lieu of the well		applications to use expanding-scope searches in lieu of the well
	known, but less efficient expanding-ring search.		known, but less efficient expanding-ring search.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (1999). All Rights Reserved.		Copyright (C) The Internet Society (2000). All Rights Reserved.
	Contents		Contents
	Abstract. . . . . . . . . . . . . . . . . . . . . . . . . 1		Abstract. . . . . . . . . . . . . . . . . . . . . . . . . 1
	1. Introduction. . . . . . . . . . . . . . . . . . . . . 3		1. Introduction. . . . . . . . . . . . . . . . . . . . . 3
	2. Overview. . . . . . . . . . . . . . . . . . . . . . . 4		2. Overview. . . . . . . . . . . . . . . . . . . . . . . 4
	3. Usage . . . . . . . . . . . . . . . . . . . . . . . . 6		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		4.3 SADP New Address. . . . . . . . . . . . . . . . . . 11
	5. Constants . . . . . . . . . . . . . . . . . . . . . . 11		5. Constants . . . . . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . 12
	7. Acknowledgements. . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements. . . . . . . . . . . . . . . . . . . 12
	8. References. . . . . . . . . . . . . . . . . . . . . . 11		8. References. . . . . . . . . . . . . . . . . . . . . . 12
	9. Author's Address. . . . . . . . . . . . . . . . . . . 12		9. Author's Address. . . . . . . . . . . . . . . . . . . 13
	10. Full Copyright Statement. . . . . . . . . . . . . . . 12		10. Full Copyright Statement. . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Administrative scoping [RFC2365] provides a useful means for limiting		Administrative scoping [RFC2365] provides a useful means for limiting
	the spread of IP multicast traffic across 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 Address Dynamic Client Allocation Protocol (MADCAP)		The Multicast Address Dynamic Client Allocation Protocol (MADCAP)
	[MADCAP] will provide applications with the means for discovering the		[RFC2730, NESTOPT] will provide applications with the means for
	various scopes that are locally visible at each point in the		discovering the various scopes that are locally visible at each point
	Internet. The determination of which scopes nest inside each other		in the Internet. The determination of which scopes nest inside each
	will be performed by the Multicast-Scope Zone Announcement Protocol		other will be performed by the Multicast-Scope Zone Announcement
	(MZAP) [MZAP]. MZAP's ability to provide this service will allow		Protocol (MZAP) [RFC2776]. MZAP's ability to provide this service
	scopes to be arranged into hierarchies so that applications can then		will allow scopes to be arranged into hierarchies so that
	use expanding scope searches instead of the less efficient and more		applications can then use expanding scope searches instead of the
	problematic expanding-ring (TTL) searches. One example of how		less efficient and more problematic expanding-ring (TTL) searches.
	expanding-scope searches provide increased localization can be found		One example of how expanding-scope searches provide increased
	in the Scoped Hybrid Automatic Repeat reQuest with Forward Error		localization can be found in the Scoped Hybrid Automatic Repeat
	Correction (SHARQFEC) reliable multicast protocol [SHARQFEC].		reQuest with Forward Error 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-scope searches involve changing the		increasing TTLs, expanding-scope searches involve changing the
	multicast addresses for each attempt at a different scope. For well-		multicast addresses for each attempt at a different scope. For well-
	known services, these addresses can be obtained by applying an IANA-		known services, these addresses can be obtained by applying an IANA-
	assigned offset from the top of the scope's address range.		assigned offset from the top of the scope's address range.
	Applications, on the other hand, generally require the use of		Applications, on the other hand, generally require the use of
	dynamically allocated addresses with offsets that will most likely		dynamically allocated addresses with offsets that will most likely
	vary from scope to scope.		vary from scope to scope.
	SADP builds upon the Multicast Address Allocation Architecture [MAAA]		SADP builds upon the Multicast Address Allocation Architecture [MAAA]
	by adding a new application-layer service that allows applications to		by adding a new application-layer service that allows applications to
	discover the relevant multicast address(es) associated with a session		discover the relevant multicast address(es) associated with a session
	at each level in a hierarchy of scopes.		at each level in a hierarchy of scopes.
	SADP does not provide the means to allocate an address should one not		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		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		application should take steps to obtain an address for that scope and
	then announce it to other application instances that join that scope		then announce it to other application instances that join that scope
	at a later time. One proposed mechanism for allocating addresses is		at a later time. One proposed mechanism for allocating addresses is
	the Multicast Address Dynamic Allocation Protocol (MADCAP) [MADCAP].		the Multicast Address Dynamic Allocation Protocol (MADCAP) [RFC2730].
	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. Ensuring consistency among boundary routers can be		outside the zone. Ensuring consistency among boundary routers can be
	a non-trivial task, and hence the Multicast Zone Announcement		a non-trivial task, and hence the Multicast Zone Announcement
	Protocol (MZAP) [MZAP], which is used to announce the existence of		Protocol (MZAP) [RFC2776], which is used to announce the existence of
	zones, also provides the mechanisms to 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 6, line 35		skipping to change at page 6, line 35
	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 scopes nest inside Local scopes which in		By definition Link Local scopes nest inside Local scopes which in
	turn nest inside the Global Scope. Other scopes may exist between the		turn nest inside the Global Scope. Other scopes may exist between the
	local and global scopes. These scopes are constructed by the union of		local and global scopes. These scopes are constructed by the union of
	the admin scope zones that correspond to two or more topologically		the admin scope zones that correspond to two or more topologically
	adjacent local scopes and are announced to routers within their		adjacent local scopes and are announced to routers within their
	confines using MZAP [MZAP].		confines using MZAP [RFC2776].
	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 scopes and addresses are involved in the hierarchy		determine which scopes and addresses are involved in the hierarchy
	for a particular session is as follows:		for a particular session is as follows:
	1) Determine largest scope, and address for the largest scope for		1) Determine largest scope, and address for the largest scope for
	the session. (this task is beyond the scope of this document,		the session. (this task is beyond the scope of this 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 SID 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, wait for some small amount of time, and then		heard, wait for some small amount of time, and then
	repeat the request at the same scope.		repeat the request at the same scope.
	4) If after a total of 3 attempts at a given scope, no response		4) If after a total of 2 attempts at a given scope, no response
	has been received, increase the scope to the next largest scope		has been received, increase the scope to the next largest scope
	and repeat steps 2 and 3. In cases where there are two		and repeat steps 2 and 3. In cases where there are two
	non-nesting scopes larger than the current, try one scope and		non-nesting scopes larger than the current, try one scope and
	then the other, should the first scope not result in a reply.		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		5) Continue steps 2), 3), and 4) until the largest scope has been
	queried or a response has been heard.		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. (e.g., via MADCAP [MADCAP]). Upon the successful		new ones. (e.g., via MADCAP [RFC2730]). Upon the successful
	allocation of a new address for use in the hierarchy, the new session		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		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		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		was allocated. This will cause the address to be cached by any SADP
	servers within the new address's scope.		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 from [SADP-RELATIVE-GROUP] at a		message from a new session member from [SADP-RELATIVE-GROUP] at a
	particular scope will issue an SADP Response (SADP_RESP) to the		particular scope will issue an SADP Response (SADP_RESP) to the
	[SADP-RELATIVE-GROUP] at the same scope after waiting for a random		[SADP-RELATIVE-GROUP] at the same scope after waiting for a random
	amount of time (T) that is calculated as follows:		amount of time (T) that is calculated as follows [HAND98]:
	Choose a random value X from a uniform random interval [0:1] Let		Choose a random value X from a uniform random interval [0:1] Let
	C = 256 Set		C = 256 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.3 SADP Server Operation		3.3 SADP Server Operation
	skipping to change at page 8, line 23		skipping to change at page 8, line 23
	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
	only expand the scope until a SADP server is found. This is a marked		only expand the scope until a SADP server is found. This is a marked
	improvement over the case where no SADP servers exist and the search		improvement over the case where no SADP servers exist and the search
	must continue until an existing session member is found.		must continue until an existing session member is found. An analysis
			of how the pressence of SADP Servers improve SADP protcol performance
			can be found in [KT99].
	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/ \_____________/
	:		:
	skipping to change at page 8, line 47		skipping to change at page 8, line 49
	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 | Num Scopes | Addr Family |		| Version | PTYPE | Num Scopes | Addr Family |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Largest Scope Group Address |		| Session ID Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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
	2: SADP New Address		2: SADP New Address
	Number of Scope Entries (Num Scopes) : 4 bits		Number of Scope Entries (Num Scopes) : 4 bits
	The number of scope entries present within a SADP_RESP		The number of scope entries present within a SADP_RESP
	message. This field should be set to zero for SADP_REQ messages.		message. This field should be set to zero for SADP_REQ messages.
	Address Family (AddrFam): 4 bits		Address Family (AddrFam): 4 bits
	This indicates the IANA-assigned address family number to be		This indicates the IANA-assigned address family number to be
	used for address contained in this message. Currently assigned		used for address contained in this message. Currently assigned
	values are listed in RFC 1700 [RFC1700]. The values for IP		values are listed in [RFC1700]. The values for IP
	addresses are:		addresses are:
	IPv4: 1		IPv4: 1
	IPv6: 2		IPv6: 2
	Session ID Address: 32 bits (IPv4) or 128 bits (IPv6)		Session ID Address: 32 bits (IPv4) or 128 bits (IPv6)
	The group address corresponding to the largest scope for this		The group address corresponding to the largest scope for this
	hierarchy of addresses.		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 a SADP Request Message is a session member or a
	session members that receive an SADP Response Message MUST		known SADP Server MAY ignore it, while new session members that
	ignore it. (The format of the authentication block is to be		receive a SADP Response Message MUST ignore it.
	decided)
			The authentication block consists of an MD5 digest that is
			constructed by applying the MD5 algorihtm [RFC1321] to these
			items in the following order:
			1) Session Identifer Address
			2) Address of the Session Member making the announcement
			3) The contents of any subsequent SADP Response or SADP New
			Address message data.
	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
	skipping to change at page 11, line 5		skipping to change at page 11, line 8
	Scope 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 scope. If a scope 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.
	Scope X Session Address : 32 bits (IPv4) or 128 bits (IPv6)		Scope X Session Address : 32 bits (IPv4) or 128 bits (IPv6)
	Address to be used for the named scope.		Address to be used for the named scope.
	4.2 SADP New Address		4.3 SADP New Address
	The SADP New Address (SADP_NEW_ADDR) Message has PTYPE=2. It is		The SADP New Address (SADP_NEW_ADDR) Message has PTYPE=2. It is
	transmitted by session members that have attempted to find an address		transmitted by session members that have attempted to find an address
	for a particular scope, failed, and have then subsequently allocated		for a particular scope, failed, and have then subsequently allocated
	a new address for use in the session at that scope. Its purpose is		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		to inform other members of the session of the existence of this newly
	allocated address and its availability for subsequent use.		allocated address and its availability for subsequent use.
	Should two members attempt to announce a new address to the same		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		scope at the same time, their SADP_NEW_ADDR messages will result in a
	skipping to change at page 12, line 32		skipping to change at page 12, line 36
	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 Authors would like to acknowledge Mark Handley for the helpful		The Authors would like to acknowledge Mark Handley for the helpful
	discussions and feedback which helped shape and refine this document.		discussions and feedback which helped shape and refine this document.
	8. References		8. References
	[MADCAP] Patel. B.V., Shah, M., Hanna, S.R., "Multicast Address
	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, draft-ietf-malloc-arch-**.txt, June 2000.
	[MZAP] Handley, M., Thaler, D., "Multicast-Scope Zone		[HAND98] Handley, M., "Session directories and scalable internet
	Announcement Protocol (MZAP)",		multicast address allocation for private internets",
	draft-ietf-mboned-mzap-02.txt, Internet-Draft, August,		In Proceedings of ACM SIGCOMM, pp 105-116, 1998.
	1998.
			[SHARQFEC] Kermode, R., "Scoped Hybrid Automatic Repeat reQuest with
			Forward Error Correction (SHARQFEC)", ACM SIGCOMM98,
			Vancouver Canada, September 1998.
			[NESTOPT] Kermode, R., "MADCAP Multicast Scope Nesting State
			Option", draft-ietf-malloc-madcap-nest-opt-05.txt,
			April, 2000.
			[KT99] Kermode, R., & Thaler, D., "Support for reliable Sessions
			with a Large Number of Members", First International
			Workshop on Networked Group Communication, Pisa Italy,
			November 1999
			[RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest
			Algorithm", RFC 1321, April 1992.
	[RFC1700] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700,		[RFC1700] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700,
	October 1994.		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.
	[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		[RFC2730] Patel. B.V., Shah, M., Hanna, S.R., "Multicast Address
	Forward Error Correction (SHARQFEC)", ACM SIGCOMM98,		Dynamic Client Allocation Protocol (MADCAP)",
	Vancouver Canada, September 1998.		RFC2730, December 1999.
			[RFC2776] Handley, M., Thaler, D., "Multicast-Scope Zone
			Announcement Protocol (MZAP)", RFC 2776, February 2000
	9. Authors' Addresses		9. Authors' Addresses
	Roger Kermode		Roger Kermode
	Motorola Australia Research Centre		Motorola Australia Research Centre
	12 Lord St.		12 Lord St.
	Botany, NSW 2091		Botany, NSW 2019
	Australia		Australia
	Email: Roger_Kermode@email.mot.com		Email: Roger.Kermode@motorola.com
	David Thaler		David Thaler
	Microsoft		Microsoft
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	USA		USA
	Email: dthaler@microsoft.com		Email: dthaler@microsoft.com
	10. Full Copyright Statement		10. Full Copyright Statement
	Copyright (C) The Internet Society (1999). All Rights Reserved.		Copyright (C) The Internet Society (2000). 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		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, 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		Internet organizations, except as needed for the purpose of
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/