< draft-ietf-malloc-arch-03.txt		draft-ietf-malloc-arch-04.txt >
	MALLOC Working Group D. Thaler		MALLOC Working Group D. Thaler
	INTERNET-DRAFT Microsoft		INTERNET-DRAFT Microsoft
	October 20, 1999 M. Handley		January 13, 2000 M. Handley
	Expires April 2000 ACIRI		Expires July 2000 ACIRI
	Category: Informational D. Estrin		Category: Informational D. Estrin
	ISI		ISI
	The Internet Multicast Address Allocation Architecture		The Internet Multicast Address Allocation Architecture
	<draft-ietf-malloc-arch-03.txt>		<draft-ietf-malloc-arch-04.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		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 Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	progress."		progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (1999). All Rights Reserved.		Copyright (C) The Internet Society (2000). All Rights Reserved.
	Draft MALLOC Architecture October 1999		Draft MALLOC Architecture January 2000
	1. Abstract		1. Abstract
	This document proposes a multicast address allocation architecture		This document proposes a multicast address allocation architecture
	for the Internet. The architecture is modular with three layers,		for the Internet. The architecture is modular with three layers,
	comprising a host-server mechanism, an intra-domain server-server		comprising a host-server mechanism, an intra-domain server-server
	coordination mechanism, and an inter-domain mechanism.		coordination mechanism, and an inter-domain mechanism.
	2. Introduction		2. Introduction
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	3. Requirements		3. Requirements
	>From a design point of view, the important properties of multicast		>From a design point of view, the important properties of multicast
	allocation mechanisms are robustness, timeliness, low probability		allocation mechanisms are robustness, timeliness, low probability
	of clashing allocations, and good address space utilization in		of clashing allocations, and good address space utilization in
	situations where space is scare. Where this interacts with		situations where space is scare. Where this interacts with
	multicast routing, it is desirable for multicast addresses to be		multicast routing, it is desirable for multicast addresses to be
	allocated in a manner that aids aggregation of routing state.		allocated in a manner that aids aggregation of routing state.
	Draft MALLOC Architecture October 1999		Draft MALLOC Architecture January 2000
	o Robustness/Availability		o Robustness/Availability
	The robustness requirement is that an application requiring the		The robustness requirement is that an application requiring the
	allocation of an address should always be able to obtain one,		allocation of an address should always be able to obtain one,
	even in the presence of other network failures.		even in the presence of other network failures.
	o Timeliness		o Timeliness
	From a timeliness point of view, a short delay of up to a few		From a timeliness point of view, a short delay of up to a few
	seconds is probably acceptable before the client is given an		seconds is probably acceptable before the client is given an
	address with reasonable confidence in its uniqueness. If the		address with reasonable confidence in its uniqueness. If the
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	Since guaranteeing no clashes in a robust manner requires		Since guaranteeing no clashes in a robust manner requires
	partitioning the address space, providing a hard guarantee		partitioning the address space, providing a hard guarantee
	leads to inefficient address space usage. Hence, when address		leads to inefficient address space usage. Hence, when address
	space is scarce, it is difficult to achieve constant		space is scarce, it is difficult to achieve constant
	availability and timeliness, guarantee no clashes, and achieve		availability and timeliness, guarantee no clashes, and achieve
	good address space usage. As a result, we must prioritize		good address space usage. As a result, we must prioritize
	these properties. We believe that, when address space is		these properties. We believe that, when address space is
	scarce, achieving good address space packing and constant		scarce, achieving good address space packing and constant
	Draft MALLOC Architecture October 1999		Draft MALLOC Architecture January 2000
	availability are more important than guaranteeing that address		availability are more important than guaranteeing that address
	clashes never occur. What we aim for in these situations is a		clashes never occur. What we aim for in these situations is a
	very high probability that an address clash does not occur, but		very high probability that an address clash does not occur, but
	we accept that there is a finite probability of this happening.		we accept that there is a finite probability of this happening.
	Should a clash occur (or should an application start using an		Should a clash occur (or should an application start using an
	address it did not allocate, which may also lead to a clash),		address it did not allocate, which may also lead to a clash),
	either the clash can be detected and addresses changed, or		either the clash can be detected and addresses changed, or
	hosts receiving additional traffic can prune that traffic using		hosts receiving additional traffic can prune that traffic using
	source-specific prunes available in IGMP version 3, and so we		source-specific prunes available in IGMP version 3, and so we
	skipping to change at page 4, line 39 ¶		skipping to change at page 4, line 39 ¶
	guarantee no collisions among hosts that use this architecture.		guarantee no collisions among hosts that use this architecture.
	3.1. Address Dynamics		3.1. Address Dynamics
	Multicast addresses may be allocated in any of three ways:		Multicast addresses may be allocated in any of three ways:
	Static:		Static:
	Statically allocated addresses are allocated by IANA for		Statically allocated addresses are allocated by IANA for
	specific protocols that require well-known addresses to work.		specific protocols that require well-known addresses to work.
	Examples of static addresses are 224.0.1.1 which is used for		Examples of static addresses are 224.0.1.1 which is used for
	the Network Time Protocol and 224.2.127.255 which is used for		the Network Time Protocol [13] and 224.2.127.255 which is
	global scope multicast session announcements. Applications		used for global scope multicast session announcements.
	that use multicast for bootstrap purposes should not normally		Applications that use multicast for bootstrap purposes should
	be given their own static multicast address, but should		not normally be given their own static multicast address, but
	bootstrap themselves using a well-known service location		should bootstrap themselves using a well-known service
	address which can be used to announce the binding between		location address which can be used to announce the binding
	local services and multicast addresses.		between local services and multicast addresses.
	Static addresses typically have a permanent lifetime, and a		Static addresses typically have a permanent lifetime, and a
	scope defined by the scope range in which they reside. As		scope defined by the scope range in which they reside. As
	such, a static address is valid everywhere (although the set		such, a static address is valid everywhere (although the set
	of receivers may be different depending on location), and may		of receivers may be different depending on location), and may
	Draft MALLOC Architecture October 1999		Draft MALLOC Architecture January 2000
	be hard-coded into applications, devices, embedded systems,		be hard-coded into applications, devices, embedded systems,
	etc. Static addresses are also useful for devices which		etc. Static addresses are also useful for devices which
	support sending but not receiving multicast IP datagrams		support sending but not receiving multicast IP datagrams
	(Level 1 conformance as specified in RFC 1112 [7]), or even		(Level 1 conformance as specified in RFC 1112 [7]), or even
	are incapable of receiving any data at all, such as a		are incapable of receiving any data at all, such as a
	wireless broadcasting device.		wireless broadcasting device.
	Scope-relative:		Scope-relative:
	RFC 2365 [1] reserves the highest 256 addresses in every		RFC 2365 [1] reserves the highest 256 addresses in every
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	and such extensions will be granted when possible. When the		and such extensions will be granted when possible. When the
	address extension is not granted, the application is expected		address extension is not granted, the application is expected
	to request a new address to take over from the old address		to request a new address to take over from the old address
	when it expires, and to be able to cope with this situation		when it expires, and to be able to cope with this situation
	gracefully. As with unicast addresses, no guarantee of		gracefully. As with unicast addresses, no guarantee of
	reachability of an address is provided by the network once		reachability of an address is provided by the network once
	the lifetime expires.		the lifetime expires.
	These restrictions on address lifetime are necessary to allow		These restrictions on address lifetime are necessary to allow
	Draft MALLOC Architecture October 1999		Draft MALLOC Architecture January 2000
	the address allocation architecture to be organized around		the address allocation architecture to be organized around
	address usage patterns in a manner that ensures addresses are		address usage patterns in a manner that ensures addresses are
	aggregatable and multicast routing is reasonably close to		aggregatable and multicast routing is reasonably close to
	optimal. In contrast, statically allocated addresses may be		optimal. In contrast, statically allocated addresses may be
	given sub-optimal routing.		given sub-optimal routing.
	4. Overview of the Architecture		4. Overview of the Architecture
	The architecture is modular so that each layer may be used,		The architecture is modular so that each layer may be used,
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	| MAAS<---/ | +---> MAAS |		| MAAS<---/ | +---> MAAS |
	| ^ ^ v ^ |		| ^ ^ v ^ |
	| . . MAAS . |		| . . MAAS . |
	| . .Layer 1 ^ .Layer 1 |		| . .Layer 1 ^ .Layer 1 |
	| v v .Layer 1 v |		| v v .Layer 1 v |
	| Client Client v Client |		| Client Client v Client |
	| Client |		| Client |
	+-------------------------------------------------------------+		+-------------------------------------------------------------+
	Figure 1: An Overview of the Multicast Address Allocation Architecture		Figure 1: An Overview of the Multicast Address Allocation Architecture
	Draft MALLOC Architecture October 1999		Draft MALLOC Architecture January 2000
	Layer 1		Layer 1
	A protocol or mechanism that a multicast client uses to		A protocol or mechanism that a multicast client uses to
	request a multicast address from a multicast address		request a multicast address from a multicast address
	allocation server (MAAS). When the server grants an address,		allocation server (MAAS). When the server grants an address,
	it becomes the server's responsibility to ensure that this		it becomes the server's responsibility to ensure that this
	address is not then reused elsewhere within the address's		address is not then reused elsewhere within the address's
	scope during the lifetime granted.		scope during the lifetime granted.
	Examples of possible protocols or mechanisms at this layer		Examples of possible protocols or mechanisms at this layer
	skipping to change at page 8, line 5 ¶		skipping to change at page 8, line 5 ¶
	An inter-domain protocol or mechanism that allocates		An inter-domain protocol or mechanism that allocates
	multicast address ranges (with lifetimes) to Prefix		multicast address ranges (with lifetimes) to Prefix
	Coordinators. Individual addresses may then be allocated out		Coordinators. Individual addresses may then be allocated out
	of these ranges by MAAS's inside allocation domains as		of these ranges by MAAS's inside allocation domains as
	described above.		described above.
	Examples of protocols or mechanisms at this layer include		Examples of protocols or mechanisms at this layer include
	MASC [6] (in which Prefix Coordinators are typically routers		MASC [6] (in which Prefix Coordinators are typically routers
	without any stable storage requirement), and static		without any stable storage requirement), and static
	Draft MALLOC Architecture October 1999		Draft MALLOC Architecture January 2000
	allocations by AS number as described in [10] (in which		allocations by AS number as described in [10] (in which
	Prefix Coordinators are typically human administrators).		Prefix Coordinators are typically human administrators).
	Each of the three layers serves slightly different purposes and as		Each of the three layers serves slightly different purposes and as
	such, protocols or mechanisms at each layer may require different		such, protocols or mechanisms at each layer may require different
	design tradeoffs.		design tradeoffs.
	5. Scoping		5. Scoping
	skipping to change at page 8, line 30 ¶		skipping to change at page 8, line 30 ¶
	The first two tasks, learning the scopes in effect and the address		The first two tasks, learning the scopes in effect and the address
	range and name(s) of each scope, may be provided by static		range and name(s) of each scope, may be provided by static
	configuration or dynamically learned. For example, a MAAS may		configuration or dynamically learned. For example, a MAAS may
	simply passively listen to MZAP [9] messages to acquire this		simply passively listen to MZAP [9] messages to acquire this
	information.		information.
	To determine the subrange for dynamic allocation, there are two		To determine the subrange for dynamic allocation, there are two
	cases for each scope, corresponding to small "indivisible" scopes,		cases for each scope, corresponding to small "indivisible" scopes,
	and big "divisible" scopes. Note that MZAP identifies which		and big "divisible" scopes. Note that MZAP identifies which
	scopes are scopes are divisible and which are not.		scopes are divisible and which are not.
	(1) For small scopes, the allocation domain corresponds to the		(1) For small scopes, the allocation domain corresponds to the
	entire topology within the administrative scope. Hence,		entire topology within the administrative scope. Hence,
	all MAASs inside the scope may use the entire address range		all MAASs inside the scope may use the entire address range
	(minus the last 256 addresses reserved as scope-relative		(minus the last 256 addresses reserved as scope-relative
	addresses), and use the Layer 2 mechanism/protocol to		addresses), and use the Layer 2 mechanism/protocol to
	coordinate allocations. For small scopes, Prefix		coordinate allocations. For small scopes, Prefix
	Coordinators are not involved.		Coordinators are not involved.
	Hence, for small scopes, the effective "allocation domain"		Hence, for small scopes, the effective "allocation domain"
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 5 ¶
	small, indivisible scope could be larger or smaller than		small, indivisible scope could be larger or smaller than
	the Allocation Scope used for big scopes (see below).		the Allocation Scope used for big scopes (see below).
	(2) For big scopes (including the global scope), the area		(2) For big scopes (including the global scope), the area
	inside the scope may be large enough that simply using a		inside the scope may be large enough that simply using a
	Layer 2 mechanism/protocol may be inefficient or otherwise		Layer 2 mechanism/protocol may be inefficient or otherwise
	undesirable. In this case, the scope must span multiple		undesirable. In this case, the scope must span multiple
	allocation domains, and the Layer 3 mechanism/protocol must		allocation domains, and the Layer 3 mechanism/protocol must
	be used to divvy up the scoped address space among the		be used to divvy up the scoped address space among the
	Draft MALLOC Architecture October 1999		Draft MALLOC Architecture January 2000
	allocation domains. Hence, a MAAS may learn of the scope		allocation domains. Hence, a MAAS may learn of the scope
	via MZAP, but must acquire a subrange from which to		via MZAP, but must acquire a subrange from which to
	allocate from a Prefix Coordinator.		allocate from a Prefix Coordinator.
	For simplicity, the effective "allocation domain" area will		For simplicity, the effective "allocation domain" area will
	be the same for all big scopes, being the granularity at		be the same for all big scopes, being the granularity at
	which all big scopes are divided up. We define the		which all big scopes are divided up. We define the
	administrative scope at this granularity to be the		administrative scope at this granularity to be the
	"Allocation Scope".		"Allocation Scope".
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	coordinate allocation between its MAAS's (if any) and those of its		coordinate allocation between its MAAS's (if any) and those of its
	provider. An AS should probably take this course of action if:		provider. An AS should probably take this course of action if:
	o it is connected to a single provider,		o it is connected to a single provider,
	o it does not provide transit for another AS, and		o it does not provide transit for another AS, and
	o it needs fewer than (say) 256 multicast addresses of larger		o it needs fewer than (say) 256 multicast addresses of larger
	than AS scope allocated on average.		than AS scope allocated on average.
	Draft MALLOC Architecture October 1999		Draft MALLOC Architecture January 2000
	5.1.1. The IPv4 Allocation Scope -- 239.251.0.0/16		5.1.1. The IPv4 Allocation Scope -- 239.251.0.0/16
	The address space 239.251.0.0/16 is to be reserved for the		The address space 239.251.0.0/16 is to be reserved for the
	Allocation Scope. The ranges 239.248.0.0/16, 239.249.0.0/16 and		Allocation Scope. The ranges 239.248.0.0/16, 239.249.0.0/16 and
	239.250.0.0/16 are to be left unassigned and available for		239.250.0.0/16 are to be left unassigned and available for
	expansion of this space. These ranges should be left unassigned		expansion of this space. These ranges should be left unassigned
	until the 239.251.0.0/16 space is no longer sufficient.		until the 239.251.0.0/16 space is no longer sufficient.
	5.1.2. The IPv6 Allocation Scope -- SCOP 6		5.1.2. The IPv6 Allocation Scope -- SCOP 6
	The IPv6 "scop" value 6 is to be reserved for the Allocation		The IPv6 "scop" value 6 is to be reserved for the Allocation
	Scope.		Scope.
	6. Overview of the Allocation Process		6. Overview of the Allocation Process
	Once Layer 3 allocation has been performed for large, divisible		Once Layer 3 allocation has been performed for large, divisible
	scopes, and each Prefix Coordinator has acquired one or more		scopes, and each Prefix Coordinator has acquired one or more
	prefixes, then those prefixes are passed to all MAAS's within the		ranges, then those ranges are passed to all MAAS's within the
	Prefix Coordinator's domain via a Layer 2 mechanism/protocol.		Prefix Coordinator's domain via a Layer 2 mechanism/protocol.
	MAAS's within the domain receive these prefixes and store them as		MAAS's within the domain receive these ranges and store them as
	the currently allowable addresses for that domain. Each prefix is		the currently allowable addresses for that domain. Each range is
	valid for a given lifetime (also acquired via the Layer 3		valid for a given lifetime (also acquired via the Layer 3
	mechanism/protocol) and is not revoked before the lifetime has		mechanism/protocol) and is not revoked before the lifetime has
	expired. MAAS's also learn of small scopes (e.g., via MZAP) and		expired. MAAS's also learn of small scopes (e.g., via MZAP) and
	store the prefixes associated with them.		store the ranges associated with them.
	Using the Layer 2 mechanism/protocol, each MAAS ensures that it		Using the Layer 2 mechanism/protocol, each MAAS ensures that it
	will exclude any addresses which have been or will be allocated by		will exclude any addresses which have been or will be allocated by
	other MAAS's within its domain.		other MAAS's within its domain.
	When a client needs a multicast address, it first needs to decide		When a client needs a multicast address, it first needs to decide
	what the scope of the intended session should be, and locate a		what the scope of the intended session should be, and locate a
	MAAS capable of allocating addresses within that scope.		MAAS capable of allocating addresses within that scope.
	To pick a scope, the client will either simply choose a well-known		To pick a scope, the client will either simply choose a well-known
	scope, such as the global scope, or it will enumerate the		scope, such as the global scope, or it will enumerate the
	available scopes (e.g., by sending a MADCAP query, or by listening		available scopes (e.g., by sending a MADCAP query, or by listening
	to MZAP messages over time) and allow a user to select one.		to MZAP messages over time) and allow a user to select one.
	Locating a MAAS can be done via a variety of methods, including		Locating a MAAS can be done via a variety of methods, including
	manual configuration, using a service location protocol such as		manual configuration, using a service location protocol such as
	SLP [12], or via a mechanism provided by a Layer 1 protocol		SLP [12], or via a mechanism provided by a Layer 1 protocol
			Draft MALLOC Architecture January 2000
	Draft MALLOC Architecture October 1999
	itself. MADCAP, for instance, includes such a facility.		itself. MADCAP, for instance, includes such a facility.
	Once the client has chosen a scope and located a MAAS, it then		Once the client has chosen a scope and located a MAAS, it then
	requests an address in that scope from the MAAS located. Along		requests an address in that scope from the MAAS located. Along
	with the request it also passes the acceptable range for the		with the request it also passes the acceptable range for the
	lifetimes of the allocation it desires. For example, if the Layer		lifetimes of the allocation it desires. For example, if the Layer
	1 protocol in use is MADCAP, the client sends a MADCAP REQUEST		1 protocol in use is MADCAP, the client sends a MADCAP REQUEST
	message to the MAAS, and waits for a NAK message or an ACK message		message to the MAAS, and waits for a NAK message or an ACK message
	containing the allocated information.		containing the allocated information.
	Upon receiving a request from a client, the MAAS then chooses an		Upon receiving a request from a client, the MAAS then chooses an
	unused address in a prefix for the specified scope, with a		unused address in a range for the specified scope, with a lifetime
	lifetime which both satisfies the acceptable range specified by		which both satisfies the acceptable range specified by the client,
	the client, and is within the lifetime of the actual prefix.		and is within the lifetime of the actual range.
	The MAAS uses the Layer 2 mechanism/protocol to ensure that such		The MAAS uses the Layer 2 mechanism/protocol to ensure that such
	an address does not clash with any addresses allocated by other		an address does not clash with any addresses allocated by other
	MAASs. For example, if Layer 2 uses manual configuration of non-		MAASs. For example, if Layer 2 uses manual configuration of non-
	overlapping prefixes, then this simply consists of adhering to the		overlapping ranges, then this simply consists of adhering to the
	range configured in the local MAAS. If, on the other hand, AAP is		range configured in the local MAAS. If, on the other hand, AAP is
	used at Layer 2 to provide less address space fragmentation, the		used at Layer 2 to provide less address space fragmentation, the
	MAAS advertises the proposed allocation domain-wide using AAP. If		MAAS advertises the proposed allocation domain-wide using AAP. If
	no clashing AAP claim is received within a short time interval,		no clashing AAP claim is received within a short time interval,
	then the address is returned to the client via the Layer 1		then the address is returned to the client via the Layer 1
	protocol/mechanism. If a clashing claim is received by the MAAS,		protocol/mechanism. If a clashing claim is received by the MAAS,
	then it chooses a different address and tries again. AAP also		then it chooses a different address and tries again. AAP also
	allows each MAAS to pre-reserve a small "pool" of addresses for		allows each MAAS to pre-reserve a small "pool" of addresses for
	which it need not wait to detect clashes.		which it need not wait to detect clashes.
	skipping to change at page 12, line 4 ¶		skipping to change at page 12, line 4 ¶
	7. Security Considerations		7. Security Considerations
	The architecture described herein does not prevent an application		The architecture described herein does not prevent an application
	from just sending to or joining a multicast address without		from just sending to or joining a multicast address without
	allocating it (just as the same is true for unicast addresses		allocating it (just as the same is true for unicast addresses
	today). However, there is no guarantee that data for unallocated		today). However, there is no guarantee that data for unallocated
	addresses will be delivered by the network. That is, routers may		addresses will be delivered by the network. That is, routers may
	drop data for unallocated addresses if they have some way of		drop data for unallocated addresses if they have some way of
	checking whether a destination address has been allocated. For		checking whether a destination address has been allocated. For
	example, if the border routers of a domain participate in the		example, if the border routers of a domain participate in the
			Draft MALLOC Architecture January 2000
	Draft MALLOC Architecture October 1999
	Layer 2 protocol/mechanism and cache the set of allocated		Layer 2 protocol/mechanism and cache the set of allocated
	addresses, then data for unallocated addresses in a prefix		addresses, then data for unallocated addresses in a range
	allocated by that domain can be dropped by creating multicast		allocated by that domain can be dropped by creating multicast
	forwarding state with an empty outgoing interface list and/or		forwarding state with an empty outgoing interface list and/or
	pruning back the tree branches for those groups.		pruning back the tree branches for those groups.
	A malicious application may attempt a denial-of-service attack by		A malicious application may attempt a denial-of-service attack by
	attempting to allocate a large number of addresses, thus		attempting to allocate a large number of addresses, thus
	attempting to exhaust the supply of available addresses. Other		attempting to exhaust the supply of available addresses. Other
	attacks include releasing or modifying the allocation of another		attacks include releasing or modifying the allocation of another
	party. These attacks can be combatted through the use of		party. These attacks can be combatted through the use of
	authentication with policy restrictions (such as a maximum number		authentication with policy restrictions (such as a maximum number
	of addresses that can be allocated by a single party).		of addresses that can be allocated by a single party).
	Hence, protocols/mechanisms that implement layers of this		Hence, protocols/mechanisms that implement layers of this
	architecture should be deployable in a secure fashion. For		architecture should be deployable in a secure fashion. For
	example, one should support authentication with policy		example, one should support authentication with policy
	restrictions, and should not allow don't allow someone		restrictions, and should not allow someone unauthorized to release
	unauthorized to release or modify the allocation of another party.		or modify the allocation of another party.
	8. Acknowledgments		8. Acknowledgments
	Steve Hanna provided valuable feedback on this document. The		Steve Hanna provided valuable feedback on this document. The
	members of the MALLOC WG and the MBone community provided the		members of the MALLOC WG and the MBone community provided the
	motivation for this work.		motivation for this work.
	9. References		9. References
	[1] D. Meyer, "Administratively Scoped IP Multicast", BCP 23, RFC		[1] D. Meyer, "Administratively Scoped IP Multicast", BCP 23, RFC
	skipping to change at page 13, line 5 ¶		skipping to change at page 13, line 5 ¶
	Multimedia Conferencing Systems", University of London, 1997.		Multimedia Conferencing Systems", University of London, 1997.
	[3] Mark Handley, "An Analysis of Mbone Performance", Chapter 4		[3] Mark Handley, "An Analysis of Mbone Performance", Chapter 4
	of PhD Thesis entitled "On Scalable Multimedia Conferencing		of PhD Thesis entitled "On Scalable Multimedia Conferencing
	Systems", University of London, 1997.		Systems", University of London, 1997.
	[4] Hanna, S., Patel, B., and M. Shah, "Multicast Address Dynamic		[4] Hanna, S., Patel, B., and M. Shah, "Multicast Address Dynamic
	Client Allocation Protocol (MADCAP)", Work in progress,		Client Allocation Protocol (MADCAP)", Work in progress,
	draft-ietf-malloc-madcap-07.txt, September 1999.		draft-ietf-malloc-madcap-07.txt, September 1999.
	Draft MALLOC Architecture October 1999		Draft MALLOC Architecture January 2000
	[5] Handley, M., Hanna, S., "Multicast Address Allocation		[5] Handley, M., Hanna, S., "Multicast Address Allocation
	Protocol (AAP)", Work in progress, draft-ietf-malloc-		Protocol (AAP)", Work in progress, draft-ietf-malloc-
	aap-02.txt, October 1999.		aap-02.txt, October 1999.
	[6] Estrin, D., Govindan, R., Handley, M., Kumar, S., Radoslavov,		[6] Estrin, D., Govindan, R., Handley, M., Kumar, S., Radoslavov,
	P., and D. Thaler, "The Multicast Address-Set Claim (MASC)		P., and D. Thaler, "The Multicast Address-Set Claim (MASC)
	Protocol", Work in progress, draft-ietf-malloc-masc-03.txt,		Protocol", Work in progress, draft-ietf-malloc-masc-03.txt,
	July 1999.		July 1999.
	skipping to change at page 13, line 37 ¶		skipping to change at page 13, line 37 ¶
	Work in progress, draft-ietf-mboned-static-allocation-00.txt,		Work in progress, draft-ietf-mboned-static-allocation-00.txt,
	May 1999.		May 1999.
	[11] R. Finlayson, "Abstract API for Multicast Address		[11] R. Finlayson, "Abstract API for Multicast Address
	Allocation", Work in progress, draft-ietf-malloc-api-07.txt,		Allocation", Work in progress, draft-ietf-malloc-api-07.txt,
	August 1999.		August 1999.
	[12] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan,		[12] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan,
	"Service Location Protocol", RFC 2165, June 1997.		"Service Location Protocol", RFC 2165, June 1997.
			[13] D. Mills, "Network Time Protocol (Version 3) Specification,
			Implementation and Analysis", RFC 1305, March 1992.
	10. Authors' Addresses		10. Authors' Addresses
	Dave Thaler		Dave Thaler
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052-6399		Redmond, WA 98052-6399
	EMail: dthaler@microsoft.com		EMail: dthaler@microsoft.com
	Mark Handley		Mark Handley
	AT&T Center for Internet Research at ICSI		AT&T Center for Internet Research at ICSI
	1947 Center St, Suite 600		1947 Center St, Suite 600
			Draft MALLOC Architecture January 2000
	Berkeley, CA 94704		Berkeley, CA 94704
	EMail: mjh@aciri.org		EMail: mjh@aciri.org
	Draft MALLOC Architecture October 1999
	Deborah Estrin		Deborah Estrin
	Computer Science Dept/ISI		Computer Science Dept/ISI
	University of Southern Calif.		University of Southern Calif.
	Los Angeles, CA 90089		Los Angeles, CA 90089
	EMail: estrin@usc.edu		EMail: estrin@usc.edu
	11. Full Copyright Statement		11. 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		This document and translations of it may be copied and furnished
	to others, and derivative works that comment on or otherwise		to others, and derivative works that comment on or otherwise
	explain it or assist in its implementation may be prepared,		explain it or assist in its implementation may be prepared,
	copied, published and distributed, in whole or in part, without		copied, published and distributed, in whole or in part, without
	restriction of any kind, provided that the above copyright notice		restriction of any kind, provided that the above copyright notice
	and this paragraph are included on all such copies and derivative		and this paragraph are included on all such copies and derivative
	works. However, this document itself may not be modified in any		works. However, this document itself may not be modified in any
	way, such as by removing the copyright notice or references to the		way, such as by removing the copyright notice or references to the
	Internet Society or other Internet organizations, except as needed		Internet Society or other Internet organizations, except as needed
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 5 ¶
	The limited permissions granted above are perpetual and will not		The limited permissions granted above are perpetual and will not
	be revoked by the Internet Society or its successors or assigns.		be revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on		This document and the information contained herein is provided on
	an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET		an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR		ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Draft MALLOC Architecture October 1999		Draft MALLOC Architecture January 2000
	Table of Contents		Table of Contents
	1: Abstract ................................................. 2		1: Abstract ................................................. 2
	2: Introduction ............................................. 2		2: Introduction ............................................. 2
	3: Requirements ............................................. 2		3: Requirements ............................................. 2
	3.1: Address Dynamics ....................................... 4		3.1: Address Dynamics ....................................... 4
	4: Overview of the Architecture ............................. 6		4: Overview of the Architecture ............................. 6
	5: Scoping .................................................. 8		5: Scoping .................................................. 8
	5.1: Allocation Scope ....................................... 9		5.1: Allocation Scope ....................................... 9
End of changes. 29 change blocks.
	41 lines changed or deleted		43 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/