From owner-malloc@catarina.usc.edu Wed Sep 20 14:47:57 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00389 for ; Wed, 20 Sep 2000 14:47:57 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA72323 for malloc-list; Wed, 20 Sep 2000 11:22:26 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA72318 for ; Wed, 20 Sep 2000 11:22:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA23090 for ; Wed, 20 Sep 2000 11:22:16 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28566; Wed, 20 Sep 2000 12:22:07 -0600 (MDT) Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA08643; Wed, 20 Sep 2000 14:22:05 -0400 (EDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id OAA21206; Wed, 20 Sep 2000 14:22:04 -0400 (EDT) Message-ID: <39C8FFF4.7A41D68@sun.com> Date: Wed, 20 Sep 2000 14:20:36 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: malloc@catarina.usc.edu Subject: Re: AAP: Chattiness of protocol References: <200008212008.QAA12200@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thomas Narten wrote: > This protocol seems fairly "chatty" to me, and I wonder how well it > will scale in practice. AAP is a soft-state protocol and a particularly chatty one, as you note. The primary reason to provide such frequent state updates was to allow new MAASs to quickly learn the state of the network. With AIU messages sent every 30 seconds [REPEAT-INTERVAL], a new MAAS is required to wait at least 150 seconds [STARTUP-WAIT] before allocating or preallocating addresses. This ensures that a few dropped packets won't cause the server to allocate addresses that are already in use. Increasing [REPEAT-INTERVAL] would require a corresponding increase in [STARTUP-WAIT], increasing startup time for MAASs. I wrote a scaling analysis for draft-ietf-malloc-aap-03.txt, which I have attached. The conclusion of this analysis was that because of the chatty nature of AAP, each allocation scope should have no more than 10 or 20 MAASs (to keep bandwidth usage to 50-110Kbps). Also, AAP should not be used over expensive or bandwidth-constrained links. In such a case, it is better to subdivide the allocation domain and use an interdomain protocol such as MASC (or manual allocation) across the expensive link. We were not able to reach working group consensus on this scaling analysis, so it was removed from draft-ietf-malloc-aap-04.txt. However, we did include a statement in section 3.1 saying: Any host that does not support a client-server protocol such as MADCAP SHOULD NOT operate as a MAAS for a given scope if a MADCAP server is available serving that scope. For scopes larger than Local scope, a host that does not support a client-server protocol such as MADCAP SHOULD NOT operate as a MAAS even if there is no MADCAP server available serving that scope. These behaviors may be overridden by configuration. As for encouraging preallocation, section 2.2 says you SHOULD preallocate enough addresses to span a network partition. Perhaps we need to add a section highlighting the scaling issues related to AAP. And beef up the SHOULDs listed above to be MUSTs. Alternative suggestions are certainly welcome. Thanks, Steve > > Things to note: > > 0) All MAAS messages are multicast to a multicast group, so they are > transmitted throughout a administrative network. > > 1) All MAASes send periodic multicast AIU messages every 30 > seconds. This is to cover the entire state of the Allocation > Record (I believe). > > 2) Whenever a MAAS allocates an address (e.g., from its preallocated > set), it immediately sends out an AIU for those addresses, > following up with retransmissions for reliability. > > 3) For non-preallocated addresses, a MAAS sends sequence of ACLM > messages (including retransmissions for reliability) when a request > to allocate an address is made. > > Result: for a moderately large site, it seems like the protocol could > generate quite a lot of traffic. This especially true if a large > number of addresses are allocated. I have concerns as to how large an > environment this will scale to. > > Given the time scales involved (shouldn't addresses be allocated for > relatively long periods of time?), it seems like the protocol could > relax some of its timing constraints, especially with regards to > periodic multicast. Or to delay sending out AIU for pre-allocated > addresses in order to batch them up. > > It also seems like the model could do more to encourage > pre-allocation, so that becomes the normal way to assign > addresses. Right now, I don't read the spec as suggesting this is > required. > > Finally, what size of environment is this protocol expected to scale > to? Is their consensus that the protocol will do so? > > Thomas From owner-malloc@catarina.usc.edu Wed Sep 20 14:58:42 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02120 for ; Wed, 20 Sep 2000 14:58:41 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA72442 for malloc-list; Wed, 20 Sep 2000 11:34:38 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id LAA72437 for ; Wed, 20 Sep 2000 11:34:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id LAA09511 for ; Wed, 20 Sep 2000 11:34:33 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05667; Wed, 20 Sep 2000 12:34:25 -0600 (MDT) Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA11337; Wed, 20 Sep 2000 14:34:24 -0400 (EDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id OAA22326; Wed, 20 Sep 2000 14:34:22 -0400 (EDT) Message-ID: <39C902D7.B216FF12@sun.com> Date: Wed, 20 Sep 2000 14:32:55 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten , malloc@catarina.usc.edu Subject: Re: AAP: Chattiness of protocol References: <200008212008.QAA12200@rotala.raleigh.ibm.com> <39C8FFF4.7A41D68@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit I forgot to include the scaling analysis from draft-ietf-malloc-aap-03.txt. Here it is: 6 Scaling Analysis Because AAP is a peer-to-peer multicast protocol, it is especially important to analyze its behavior with a large number of participants. Normally, only one Prefix Coordinator is active. So the primary concern is large numbers of MAAS's. Unless otherwise specified, calculations in this section will assume that there are m MAAS's, communicating across a network with a typical round-trip time of 200ms. We will also assume that each AAP packet is 100 bytes long. These are pessimistic assumptions, but not outrageously so. This analysis only examines traffic for a single scope. Results for multiple scopes should scale in a linear fashion. However, it should be noted that if several scopes share an allocation domain, all AAP traffic for those scopes will be sent on a single scope-relative multicast address (the AAP address for that domain). This may cause some MAAS's to receive traffic that they are not interested in, if they are not interested in all scopes sharing that domain. These packets will be dropped, but may have a performance impact. 6.1 Steady-State Traffic First, let's look at steady-state traffic. A MAAS that has not allocated or preallocated any addresses does not normally send any packets (except for defending the claims of others and ANA and ASRP packets, all of which are rare). However, let's make a worst-case assumption that all MAAS's have allocated and preallocated some addresses. In that case, the traffic caused by steady-state AIU and AITU messages will be: 2*m ----------------- packets per second [REPEAT-INTERVAL] Handley and Hanna [Page 31] Internet Draft draft-ietf-malloc-aap-03.txt March 2000 and 2*m*8*100 ----------------- bits per second [REPEAT-INTERVAL] With m=10 and the recommended value for [REPEAT-INTERVAL], this is about m=1000, it is 67 packets per second and 56000 bits per second. 6.2 Peak Traffic Peak traffic depends on many variables. However, we might assume a worst-case scenario where all MAAS's begin to allocate addresses simultaneously. This might be caused by some externally synchronized special event, such as a news event or an advertising campaign. It should not be caused by a power failure and subsequent synchronized power restoration, since the MAAS's must all have stable storage that maintains their allocations across power losses. In addition, it should be noted that the MAAS's should have some addresses preallocated to handle surges in demand. So this is a somewhat unlikely scenario. But let's look at the worst case. All MAAS's will begin with an initial delay between [STARTUP-WAIT] and [STARTUP-WAIT]*1.3. After this delay, the MAAS's will select the addresses that they want to allocate (or preallocate) and each MAAS will send an ACLM message, resending this message after [RESEND- WAIT], then [RESEND-WAIT]*2, and so on until the Claim Timer expires, [ANNOUNCE-WAIT] after the initial message was sent (unless a collision occurs). With recommended values for the timers (assuming no collisions occur), the total traffic sent during this burst of announcements will be 4*m packets composed of 4*m*8*100 bits. This traffic will be probably be spread out over an interval of [STARTUP-WAIT]*.3, providing an average bit rate of: 4*m ----------------- packets per second [STARTUP-WAIT]*.3 and 4*m*8*100 ----------------- bits per second [STARTUP-WAIT]*.3 With m=10 and the recommended value for [STARTUP-WAIT], this is about m=1000, it is 80 packets per second and 64,000 bits per second. Handley and Hanna [Page 32] Internet Draft draft-ietf-malloc-aap-03.txt March 2000 Of course, this is just the average rate. There is a reasonable probability that several MAAS's will choose similar values for their Startup Timers and end up sending their ACLM messages very close together. And it could even happen that all MAAS's would send their ACLM messages simultaneously. But that is exceedingly unlikely. 6.3 Probability of Collision One interesting statistic to examine is the probability of collision (two MAAS's allocating the same address). Unless MAAS's are unstable, the network is partitioned for a significant period of time, or the recommendations of section 2.2 are not followed, the only chance for a collision should be excessive packet loss. When allocating an address with the recommended timers, a MAAS will send out four (4) ACLM messages over an interval of ten (10) seconds before it considers the address allocated. If another MAAS chooses the same address at the same time, it should receive one of these ACLM messages before its Claim Timer expires. If the probability of packet loss is p, the probability of losing all four of these messages is p^4. With 10% packet loss, this indicates only one collision in 10,000 instances of simultaneously allocating the same address. Of course, a higher rate of packet loss would cause a higher probability of collision. But the chances of two MAAS's simultaneously allocating the same address should be slim unless there are very few free addresses. 6.4 Claim Defense Traffic When a MAAS sends an ACLM or AITU message with an address that has already beeen allocated by someone else, this causes other MAAS's to set an Allocation Defense timer. If the MAAS that allocated the address is present, it will set its timer to 0 and immediately send an AIU message to defend its allocation and it will follow this up with several more AIU messages at increasing intervals. The other MAAS's will observe these AIU messages and reset their Allocation Defense timers to higher values. This avoids storms of packets defending the address. However, if the MAAS that allocated the address is not present, the MAAS's that have set timers are at substantial risk of causing a storm. This is why the Allocation Defense timer is randomized. MAAS's that choose a large timer value will see AIU messages from others first and suppress their own AIU messages. Handley and Hanna [Page 33] Internet Draft draft-ietf-malloc-aap-03.txt March 2000 However, if several MAAS's choose similar small timer values, multiple AIU messages will be sent. The probability that a MAAS will choose a timer less than 1/2 RTT after the lowest timer value chosen is: RTT/2 p1 = 1 - (1 - (---------------))^(m-2) [RESEND-WAIT]*6 With m=10, RTT=200ms, and [RESEND-WAIT] = 1 second (the recommended value), p1 is .13. With m=100, p1 is .81. And with m=1000, p1 is very close to 1. In fact, with m=100 there is a 10% chance that 12 AIU messages will be sent before they are suppressed (all during a 100ms period). There is even a 1% chance that 23 AIU messages will be sent during this period. This storm could overwhelm network resources or hosts listening to the AAP group. One way to solve this problem would be to use an exponential distribution for the random timers. But even this will not provide a complete solution and it adds complexity to AAP implementations. A simpler solution is to adopt recommendations to ensure that no more than 10 or at most 20 MAAS's participate in AAP protocol exchanges for a given scope. With m=20, there is less than a .5% chance that 5 or more AIU messages will be sent before suppression kicks in and a 1 in 200,000 chance that 10 or more messages will be sent. And under no circumstances would more than 19 messages be sent! 6.5 Conclusion Clearly, it is important to minimize the number of MAAS's speaking AAP within an allocation domain. A limit of ten servers is reasonable in most cases. That is why section 3.1 requires that only MADCAP servers can operate as a MAAS if a MADCAP server is available and also requires that only MADCAP servers operate as MAAS's for scopes larger than Local scope. Since AAP is a somewhat "chatty" protocol, it is not recommended for use across when the network connecting the MAAS's is expensive or bandwidth-constrained. In such scenarios, it may be better to subdivide the allocation domain, using an interdomain protocol or mechanism to communicate between the domains. From owner-malloc@catarina.usc.edu Thu Sep 21 17:52:39 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15015 for ; Thu, 21 Sep 2000 17:52:37 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA86067 for malloc-list; Thu, 21 Sep 2000 14:25:56 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA86062 for ; Thu, 21 Sep 2000 14:25:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id OAA14483 for ; Thu, 21 Sep 2000 14:25:54 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA10900; Thu, 21 Sep 2000 15:25:26 -0600 (MDT) Received: from sunlabs.East.Sun.COM (sunlabs-74.East.Sun.COM [129.148.74.250]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA05234; Thu, 21 Sep 2000 17:25:14 -0400 (EDT) Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id RAA11583; Thu, 21 Sep 2000 17:25:13 -0400 (EDT) Message-ID: <39CA7C60.DD9461D8@sun.com> Date: Thu, 21 Sep 2000 17:23:44 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: malloc@catarina.usc.edu Subject: Re: AAP: Rebroadcasting second-hand information References: <200008212009.QAA12211@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit This is a very good point. To ease debugging and solve the well-known problems associated with using source IP address as an identifier, I suggest that we add an Allocator ID field to the AIU message. Each MAAS should store the allocator ID for each allocation in its allocation record. And if it ends up defending somebody else's allocation, it should use their allocator ID in the AIU message it sends. A followup question is "what should we use for the allocator ID?" I'm reluctant to use one of the sender's IP addresses, since this won't work well across NATs and with renumbering in IPv6. Maybe we should use a variable length field with a type byte, like the IPsec DOI for ISAKMP. Or we could just have each MAAS choose a long (16 byte) random number when they start up and use that. -Steve Thomas Narten wrote: > > This protocol has the characteristic that a node that receives > information (e.g., address X is allocated) will in some circumstances > resend that information. For example, in the case of a network > partition, one wants a MAAS with knowledge of an allocation made by > another MAAS (one that is currently unreachable due to network > partitioning) to resend that information in some cases so that > duplicate allocations are avoided. Likewise, the document explicitely > says a Prefix Coordinator doesn't have to maintain stable storage, and > can "relearn" information that it was the original source for because > other MAASes will continue advertising that information in its > absence. > > I worry that this particular model will lead to serious debugging and > operational problems. For example, if bogus information gets into the > system (either through misconfiguration, bad implemenations, data > corruption, etc.) it will be quite difficult to stamp it out. If you > kill it in one place, it will pop up again from some other > source. Likewise, the way the protocol is currently defined, it will > be very difficult to determine the source of the bad information. This > is because the messages don't include information about the original > source of information, rather, it includes only the minimal > information needed to determine that an address is allocated. > > Here are some things that I think should be thought about: > > 1) for AIU messages, it might make sense for an address that is marked > in-use to include information indicating who (i.e., which MAAS) has > it in-use. That way, if MAAS A is simply repeating information that > MAAS B has address X in use, the AIU message A sends outs will say > "A is using X". Note that the current protocol sends out messages > of the form "someone (but it might not be me) is using address X". > > 2) I'm concerned that the rules regarding which messages supercede > which previous messages are complex and may not handle all the > cases properly. From a protocol perspective, it would be much > cleaner if a MAAS could look at a message, determine the original > sender of that message (in the case where the information is > actually a resending of sorts), and then do a simple check to > determine whether that information is older or newer than something > it already has. For example, if an AIU record for address X > included the owning MAAS (say A) and a timestamp indicating when A > sent out the AIU for X, it would be easy for a receiver to determine > whether to accept or reject a particular message. > > The analogy I have is to routing protocols, where the change from > "old arpanet" to "new arpanent" algorithms went to a model in which > raw data was propogated unchanged so as to be sure that all > receivers acted on the same and most-up-to-date information. > > As an example of a specific concern I have, Section 3.2.8 includes > some rules for handling partitioned networks, reductions in the > expiration time, etc.: > > > Note that if some MAAS's are partitioned from the network during the > > time when this deletion is being announced, they may defend the > > earlier allocation when they are later reconnected. In this case, the > > MAAS that deleted the allocation SHOULD advertise the allocation > > again with the correct end time (now in the past) so that it is > > deleted from the Allocation Records of the MAAS's that were > > partitioned. > > The above seem quite complex, and I'm not sure its even > correct. How does the MAAS that deleted the allocation earlier even > know that the current allocation actually refers to the allocation > it made earlier? It *could* be an entirely new allocation made by > some other node, in which case the above advertisement would be > incorrect. I think this sort of thing can be easily addressed by > making it more clear who actually is owning an address > allocation. That way, the owner herself can always step in and say > "hey, that's old, here is the correct information". > > Thomas From owner-malloc@catarina.usc.edu Thu Sep 21 17:58:47 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15092 for ; Thu, 21 Sep 2000 17:58:47 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA86140 for malloc-list; Thu, 21 Sep 2000 14:35:26 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA86135 for ; Thu, 21 Sep 2000 14:35:25 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id OAA99596 for malloc@catarina.usc.edu; Thu, 21 Sep 2000 14:35:25 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA83596 for ; Thu, 21 Sep 2000 09:54:38 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA14627 for ; Thu, 21 Sep 2000 09:54:37 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA11774; Thu, 21 Sep 2000 09:51:17 -0700 (PDT) Message-Id: <200009211651.JAA11774@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2907 on MADCAP Multicast Scope Nesting State Option Cc: rfc-ed@isi.edu, malloc@catarina.usc.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 21 Sep 2000 09:51:17 -0700 From: RFC Editor Sender: owner-malloc@catarina.usc.edu Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2907 Title: MADCAP Multicast Scope Nesting State Option Author(s): R. Kermode Status: Standards Track Date: September 2000 Mailbox: Roger.Kermode@motorola.com Pages: 13 Characters: 27572 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-malloc-madcap-nest-opt-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2907.txt This document defines a new option to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) to support nested scoping. The new option's purpose is to allow clients to learn which scopes nest inside each other, and hence it may be used for expanding scope searches or hierarchical multicast transport. This document is a product of the Multicast-Address Allocation Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000921094833.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2907 --OtherAccess Content-Type: Message/External-body; name="rfc2907.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000921094833.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Thu Sep 21 17:58:49 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15093 for ; Thu, 21 Sep 2000 17:58:47 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA86172 for malloc-list; Thu, 21 Sep 2000 14:35:57 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA86167 for ; Thu, 21 Sep 2000 14:35:57 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id OAA99604 for malloc@catarina.usc.edu; Thu, 21 Sep 2000 14:35:57 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA83670 for ; Thu, 21 Sep 2000 10:02:15 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA23919 for ; Thu, 21 Sep 2000 10:02:14 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA13080; Thu, 21 Sep 2000 09:58:55 -0700 (PDT) Message-Id: <200009211658.JAA13080@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2909 on The MASC Protocol Cc: rfc-ed@isi.edu, malloc@catarina.usc.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 21 Sep 2000 09:58:55 -0700 From: RFC Editor Sender: owner-malloc@catarina.usc.edu Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2909 Title: The Multicast Address-Set Claim (MASC) Protocol Author(s): P. Radoslavov, D. Estrin, R. Govindan, M. Handley, S. Kumar, D. Thaler Status: Experimental Date: September 2000 Mailbox: pavlin@catarina.usc.edu, estrin@isi.edu, govindan@isi.edu, mjh@aciri.org, kkumar@usc.edu, dthaler@microsoft.com Pages: 56 Characters: 127278 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-malloc-masc-06.txt URL: ftp://ftp.isi.edu/in-notes/rfc2909.txt This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. MASC is used by a node (typically a router) to claim and allocate one or more address prefixes to that node's domain. While a domain does not necessarily need to allocate an address set for hosts in that domain to be able to allocate group addresses, allocating an address set to the domain does ensure that inter-domain group-specific distribution trees will be locally-rooted, and that traffic will be sent outside the domain only when and where external receivers exist. This document is a product of the Multicast-Address Allocation Working Group of the IETF. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000921095707.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2909 --OtherAccess Content-Type: Message/External-body; name="rfc2909.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000921095707.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Thu Sep 21 18:00:32 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15130 for ; Thu, 21 Sep 2000 18:00:32 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA86162 for malloc-list; Thu, 21 Sep 2000 14:35:42 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA86157 for ; Thu, 21 Sep 2000 14:35:41 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id OAA99600 for malloc@catarina.usc.edu; Thu, 21 Sep 2000 14:35:41 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA83634 for ; Thu, 21 Sep 2000 09:58:39 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id JAA19576 for ; Thu, 21 Sep 2000 09:58:28 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA12164; Thu, 21 Sep 2000 09:55:05 -0700 (PDT) Message-Id: <200009211655.JAA12164@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2908 on MALLOC Architecture Cc: rfc-ed@isi.edu, malloc@catarina.usc.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 21 Sep 2000 09:55:05 -0700 From: RFC Editor Sender: owner-malloc@catarina.usc.edu Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2908 Title: The Internet Multicast Address Allocation Architecture Author(s): D. Thaler, M. Handley, D. Estrin Status: Informational Date: September 2000 Mailbox: dthaler@microsoft.com, mjh@aciri.org, estrin@usc.edu Pages: 13 Characters: 30515 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-malloc-arch-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2908.txt This document proposes a multicast address allocation architecture (MALLOC) for the Internet. The architecture is modular with three layers, comprising a host-server mechanism, an intra-domain server-server coordination mechanism, and an inter-domain mechanism. This document is a product of the Multicast-Address Allocation Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000921095303.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2908 --OtherAccess Content-Type: Message/External-body; name="rfc2908.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000921095303.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart--