idnits 2.17.1 draft-talpade-ion-multiplemcs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 102 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 26, 1996) is 9983 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BK95' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'LM93' is defined on line 311, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'BK95' ** Obsolete normative reference: RFC 1577 (ref. 'LM93') (Obsoleted by RFC 2225) == Outdated reference: A later version (-04) exists of draft-ietf-ion-scsp-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ion-marsmcs (ref. 'TA96') -- Possible downref: Non-RFC (?) normative reference: ref. 'TA96a' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Talpade and Ammar 3 INTERNET-DRAFT Georgia Institute of Technology 4 December 26, 1996 6 Expires: June, 1997 8 9 Multiple MCS support using an enhanced 10 version of the MARS server. 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working documents 15 of the Internet Engineering Task Force (IETF), its areas, and its working 16 groups. Note that other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months and 20 may be updated, replaced, or obsoleted by other documents at any time. It 21 is inappropriate to use Internet- Drafts as reference material or to cite 22 them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 26 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 27 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 29 Abstract 31 The basic Multicast Server architecture for layer 3 multicast over ATM has 32 been described in draft-ietf-ion-marsmcs-01.txt. It includes a mechanism 33 for fault tolerance using multiple MCSs. However no support for sharing 34 senders/receivers of a group across multiple MCSs has been provided. This 35 document aims to satisfy this need by involving an enhanced version of the 36 MARS in the load sharing and fault tolerance mechanism. This approach is 37 an improvement over the previous one as it subverts the need for any 38 inter-MCS synchronization mechanisms. 40 1 Introduction 42 A solution to the problem of mapping layer 3 multicast service over the 43 connection-oriented ATM service provided by UNI 3.0/3.1, has been presented 44 in [GA96]. A Multicast Address Resolution Server (MARS) is used to 45 maintain a mapping of layer 3 group addresses to ATM addresses in that 46 architecture. Two possible approaches exist for a source to multicast data 47 to group members (receivers). It can either get the list of ATM addresses 48 constituting the group from the MARS, set up a point-to-multipoint virtual 49 circuit (VC) with the receivers as leaves, and then proceed to send data 50 out on it (the VC Mesh approach). Alternatively, the source can make use 51 of a proxy Multicast Server (MCS). The source transmits data to such an 52 MCS, which in turn uses a point-to-multipoint VC to get the data to the 53 group members (the MCS approach). 55 The MCS approach has been briefly introduced in [GA96]. The basic MCS 56 architecture, along with MARS-MCS interactions, has been described in 57 [TA96]. An inter-MCS synchronization protocol based on HELLO messages 58 ([LA96]) is used to support multiple MCSs for fault tolerance. However no 59 support is provided for using the multiple MCSs for sharing the 60 senders/receivers of a group. [TA96] thus allows atmost one MCS to be 61 active per group, with one or more MCSs designated as backups. 63 The possibility of load sharing is an important advantage of using multiple 64 MCSs. Experiments ([TA96a] have demonstrated the bottleneck effect that a 65 single MCS can have on data traffic, which motivates the need for sharing 66 the senders of a group. At the same time it is crucial to minimize the 67 synchronization mechanisms that would be necessary to achieve this goal. 68 One common feature of mechanisms that offer load sharing is the existence 69 of an entity which handles allocation of senders/receivers to the 70 individual MCSs that support a group. The MARS is a repository of all 71 relevant information about the cluster (e.g. senders/receivers of all 72 groups, MCSs in the cluster, groups supported by each MCS, etc). It has 73 access to all the information that an allocation entity might require, and 74 thus blends naturally into the role. Using the MARS in this way also 75 removes the need for any inter-MCS synchronization. This is because the 76 allocation and consequent load sharing can take place transparent to the 77 MCSs supporting a group. This document provides a means for supporting the 78 use of multiple MCSs per layer 3 group by involving the MARS in the 79 allocation mechanism. 81 The document currently provides an outline of the proposed mechanism, and 82 does not include a description of the details. Familiarity of the reader 83 with the MARS approach as described in [GA96], and the MCS architecture 84 described in [TA96] is expected. The main difference between the approach 85 described in [TA96] and this document is that [TA96] uses an inter-MCS 86 synchronization mechanism to offer fault tolerance, whereas this document 87 offers fault tolerance as well as load sharing using the MARS as the 88 allocation mechanism and does not need any additional inter-MCS protocol. 90 2 Nonoptimality of using the SCSP approach for multiple MCS support 92 The Server Cache Synchronization Protocol (SCSP) has recently been proposed 93 ([LA96]) for supporting the use of multiple ATMARP, MARS, NHRP servers. 94 SCSP essentially provides a means for synchronizing the caches (databases) 95 of the involved servers. Thus any one of multiple servers can be used 96 transparently by clients. The functionality provided by SCSP may lead to 97 arguments being made in favour of its use for supporting multiple MCSs 98 also, and not involve the MARS in the multiple MCS mechanism. However this 99 is not an optimal approach, as shall be pointed out in the following 100 discussion. 102 The primary function of the MCS is to be a forwarding entity of data 103 traffic, and not a repository of control information that can be accessed 104 by clients. The opposite is true for the ATMARP, MARS and NHRP servers. 105 The MCS gets the information it needs from the MARS and not directly from 106 the clients. This is another major difference between the MCS and the 107 other servers. So an instance of the other servers can receive some 108 information from client A, with another instance receiving different 109 information from client B but not from client A. This can lead to 110 inconsistent caches between the two server instances, which necessitates 111 the use of SCSP to synchronize their caches. This is not true for MCSs. 112 All of them use the MARS for obtaining requisite information, thus getting 113 it from a consistent source(1). So there is no need to further synchronize 114 the MCS caches, thus obviating the need for SCSP. 116 Even if the MCSs were synchronized using SCSP, an additional entity would 117 be needed to allocate new senders/receivers. This allocation entity would 118 probably be one of the multiple MCSs. An additional mechanism will thus be 119 needed to ensure fault tolerance, as the allocation MCS is now a single 120 point of failure (possibly the Designated Server mechanism described in 121 [LA96]). As opposed to this, the MARS is a repository of all the 122 information that may be needed by an allocation entity. So it can make the 123 necessary decisions without needing any additional entity or mechanisms. 125 Also, using an inter-MCS synchronization protocol like SCSP would mean that 126 all senders would continue to transmit data to all MCSs, even when the 127 senders are being shared. The MCSs would forward data received from 128 senders supported by it, dropping data received from other senders. This 129 is highly inefficient in terms of bandwidth usage and processing. Using 130 the MARS server avoids this problem, as the MARS can selectively inform 131 each sender about the MCS supporting it, thus making the sender transmit 132 ---------------------------- 134 1)this is true even for multiple MARS, as is discussed in section 3.3 135 data to one MCS only. Thus using the MARS is more efficient that using 136 SCSP for supporting multiple MCSs. 138 3 Overview of the multiple MCS approach 140 This section provides an overview of the proposed approach. We do not 141 describe the details in this version of the draft, but provide a conceptual 142 introduction to the approach. 144 3.1 Design goals 146 * An important consideration of the approach is to keep the clients and 147 the MCSs ignorant of the existence of the allocation mechanism. This 148 simplifies their design and implementation. It also facilitates 149 interoperability between different versions of the clients and MCSs. 151 * The MCS should receive and forward data from senders supported by it 152 only. It should not receive, and then have to drop, data from 153 unsupported senders. 155 * Another design goal is to minimize the complexity and fallibility of 156 the allocation mechanism. Both the above goals are achieved by using 157 the MARS for the allocation mechanism. 159 * The decision to share senders or receivers (not both) shall be made 160 offline, and can be made on a per group basis. 162 3.2 Architecture 164 3.2.1 Additional functionality needed in the MARS 166 The MARS server as defined in [GA96] does not have the capability for 167 supporting multiple MCSs. Additional functionality is needed for it to 168 perform as the allocation mechanism. This functionality is in terms of 169 additional processing, and does not involve any new control messages. 171 * The MARS should be able to allocate existing senders/receivers to the 172 MCSs supporting a group which is transitioning from being VC Mesh based 173 to being MCS based. This allocation should be made such that 174 load-sharing is achieved across the MCSs. 176 Thus when sharing receivers, the MCSs should be informed of the subset 177 of receivers they support in the MARSMULTI messages that the MARS 178 sends in response to MARSREQUEST. So each MCS will only be made aware 179 of a part of the receiver set, and shall add only those receivers to 180 its outgoing point-to-multipoint data VC. 182 When sharing senders, the MARS should allocate the senders such that 183 each MCS supports a distinct subset of the sender set. This can be 184 done by having the MARS selectively indicate the MCS that a sender 185 should use (possibly by round-robin) in the MARSMULTI message that the 186 sender gets in response to a MARSREQUEST. 188 * The MARS should maintain information about the current allocation map, 189 i.e., information about which sender/receiver has been allocated to 190 which MCS. The MARS should ensure that each sender/receiver is 191 allocated to one and only one MCS and that all the senders/receivers 192 have been allocated. 194 * When sharing receivers, the MARS should allocate new receivers to one 195 and only one MCS. This involves selectively forwarding MARSSJOINs to 196 an MCS, using the point-to-point control VC that exists between each 197 MCS and the MARS instead of the ServerControlVC. Similarly, the MARS 198 should deallocate a receiver that leaves the group by forwarding the 199 MARSSLEAVE on the relevant point-to-point VC only. 201 * When sharing senders, the MARS should inform a new sender about exactly 202 one MCS. No specific action is needed if an existing sender stops 203 transmitting to a group. An interesting point here is that there is no 204 obvious way for the MARS to know about senders that have stopped 205 transmitting to a group. This has implications for maintaining the 206 accuracy of the allocation map. The MARS maintains load sharing across 207 the MCSs by basing its allocation decisions on the map. Hence an 208 incorrect map may lead to improper load sharing. This problem does not 209 exist when sharing receivers as they are explicitly registered (using 210 MARSJOIN/MARSLEAVE) with the MARS. We explain possible solutions in 211 section 3.2.2. 213 3.2.2 Balancing the load when sharing senders 215 The MARS can learn about a new sender when it receives a MARSREQUEST 216 message from it. However, senders do not explicitly deregister from the 217 MARS when they stop transmitting to the group. So the MARS cannot update 218 its allocation map which may cause it to make incorrect allocation 219 decisions. Thus load balancing may not be achieved. 221 A simplistic solution is to ignore the need for deregistration by the 222 senders. This simplicity is ofcourse at the expense of the possibility of 223 improper load balancing. However, assuming that all senders have a similar 224 lifetime, the rate of addition and deletion of senders to an MCSs' set (set 225 of senders currently supported by an MCS) will remain approximately the 226 same for all MCSs. 228 Another solution to the problem is to have the senders explicitly 229 register/deregister with the MARS. The MARSREQUEST message that a sender 230 transmits to the MARS can be used for registration, while a new message 231 (MARSSNDR-LEAVE) can be used for deregistration from the MARS. The MARS can 232 thus be kept aware of the existing senders. This solution however involves 233 changing the client behavior. So [GA96] based clients will not be 234 considered by the MARS for load sharing decisions. Also, compatibility 235 issues that arise due to existence of different versions of clients will 236 have to be resolved. 238 One can avoid changing the client behavior by making the MCS responsible 239 for deregistering senders. The MCS terminates a VC from each sender to the 240 group (or atleast the senders being supported by it). It is aware of the 241 state of each of these VCs, and so knows when such a VC is released. 242 Release of such a VC can be viewed as the sender terminating transmission 243 to the group. The MCS can then inform the MARS of this event using a new 244 message (MARSSNDR-LEAVE), causing the MARS to update its allocation map. 246 It remains to be seen as to which of the above is a better approach for 247 solving the problem. 249 3.2.3 Interactions between the MARS and MCSs 251 As was indicated in section 3.1, an important goal of this approach is to 252 not involve the MCSs in the allocation mechanism. An MCS must remain 253 oblivious of the existence of other MCSs supporting the same group. Thus 254 each MCS is made aware of only the receivers supported by it, when sharing 255 receivers. So the MARS-MCS interactions do not change at all from those 256 described in [TA96]. 258 The only consideration needed in the MCS design is that an MCS should 259 accept MARSSJOIN and MARS-SLEAVE from the MARS on either the 260 ServerControlVC or the point-to-point VC. This is because the MARS informs 261 an MCS of new/leaving group member only if it allocates/has allocated that 262 member to that MCS. 264 3.2.4 Interactions between the MARS and clients 266 The interactions between the MARS and the clients also remain the same. 267 The only exception in this case is if the explicit deregistration mechanism 268 explained in section 3.2.2 is adopted for senders. In that case the 269 clients will have to send a new message (MARSSNDR-LEAVE) when a group's 270 outgoing point-to-multipoint data VC is closed. Closing the VC indicates 271 that the client is no longer sending to that group, and hence the MARS can 272 update its allocation map. 274 3.3 Using multiple MCSs with multiple MARS 276 The SCSP approach provides a mechanism for supporting multiple MARS in a 277 cluster. The multiple MCS mechanism that we have outlined above will work 278 with multiple MARS also. In this case, the Designated Server (DS) protocol 279 described in [LA96] can be used to elect one of the MARS as the allocation 280 mechanism. This DS will ensure consistency of the allocation map amongst 281 the MARS, and allocates senders/receivers amongst the multiple MCSs. The 282 DS mechanism also has a recovery mechanism that can be used to elect a new 283 MARS to function as the DS, in case of failure of the existing one. 285 4 Summary 287 We propose a scheme for supporting multiple MCSs per group using the MARS 288 as the allocation mechanism. This scheme subverts the need for an 289 inter-MCS synchronization protocol. It requires enhancement to the current 290 MARS server architecture as described in [GA96]. We aim to minimize the 291 changes required to the client or MCS architecture in this scheme, thus 292 maintaining interoperability between different versions of clients and 293 MCSs. 295 Author's address 297 Rajesh Talpade - taddy@cc.gatech.edu - (404)-894-6737 298 Mostafa H. Ammar - ammar@cc.gatech.edu - (404)-894-3292 300 College of Computing 301 Georgia Institute of Technology 302 Atlanta, GA 30332-0280 303 References 305 [GA96] Armitage, G.J., "Support for Multicast over UNI 3.0/3.1 based ATM 306 networks", RFC 2022, November 1996. 308 [BK95] Birman, A., Kandlur, D., Rubas, J., "An extension to the MARS 309 model", Internet Draft, draft-kandlur-ipatm-mars-directvc-00.txt, 310 November 1995. 311 [LM93] Laubach, M., "Classical IP and ARP over ATM", RFC1577, 312 Hewlett-Packard Laboratories, December 1993. 314 [LA96] Luciani, J., G. Armitage, and J. Halpern, "Server Cache 315 Synchronization Protocol (SCSP)", Internet Draft, 316 draft-ietf-ion-scsp-00.txt, December 1996. 318 [TA96] Talpade, R., and Ammar, M.H., "Multicast Server Architectures for 319 UNI 3.0/3.1 based ATM networks", Internet Draft, 320 draft-ietf-ion-marsmcs-01.txt, November 1996. 321 [TA96a] Talpade, R., G. Armitage, M. Ammar, "Experience with Architectures 322 for Supporting IP Multicast over ATM" , submitted to IEEE ATM '96 323 Workshop, San Francisco, August 1996.