idnits 2.17.1 draft-bestler-transactional-subset-multicast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2014) is 3517 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'A' is mentioned on line 499, but not defined == Missing Reference: 'B' is mentioned on line 499, but not defined == Missing Reference: 'C' is mentioned on line 498, but not defined == Missing Reference: 'D' is mentioned on line 499, but not defined == Missing Reference: 'M4' is mentioned on line 719, but not defined == Missing Reference: 'M5' is mentioned on line 719, but not defined == Missing Reference: 'M19' is mentioned on line 719, but not defined == Unused Reference: 'IEEE.802.1Qau-2011' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'IEEE.802.1Qaz-2011' is defined on line 1060, but no explicit reference was found in the text == Unused Reference: 'RFC6325' is defined on line 1098, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5661 (Obsoleted by RFC 8881) Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG C. Bestler, Ed. 3 Internet-Draft R. Novak 4 Intended status: Experimental Nexenta 5 Expires: March 14, 2015 September 10, 2014 7 Creation of Transactional Subset Multicast Groups 8 draft-bestler-transactional-subset-multicast-00 10 Abstract 12 This memo presents techniques for controlling the membership of 13 multicast groups which are constrained to be a subset of a pre- 14 existing multicast group, where such subset groups are only used for 15 short duration transactions which are multicast to a subset of the 16 larger multicast group. 18 Editor's Note 20 The proper working group for this draft has not yet been determined. 21 Alternate working groups include PIM and INT. 23 Nexenta has been developing a multicast based transport/storage 24 protocol for Object Clusters at Nexenta. This applies multicast 25 datagrams to creation and replication of Objects such as those 26 supported by the Amazon Simple Storage Service ("S3") protocol or the 27 OpenStack Object Storage service ("Swift"). Creating replicas of 28 object payload on multiple servers is an inherent part of any storage 29 cluster, which makes multicast addressing very inviting. There are 30 issues of congestion control and reliability to settle, but new Layer 31 2 capabilities such as DCB (Data Center Bridging) make this doable. 33 However, we found that the existing protocols for controlling 34 multicast group membership (IGMP and MLD) are not suitable for our 35 storage application. The Authors doubt this is unique to a single 36 application. It should apply to many clusters that have a need to 37 distribute transactional messages to dynamically selected subsets of 38 a group within a cluster to multiple known recipients. 40 Computational clusters using MPI are also potential users of 41 transactional multicasting. Inter-server replication in a pNFS 42 cluster is another. 44 These are just examples of synchronizing cluster data where the 45 synchronization does not replicate all of the shared data with the 46 entire cluster. But these are merely initial hunches, working group 47 feedback is expected to refine characterization of the applicability 48 of transactional subset multicast groups. 50 This submission, and ensuing discussion of this draft and its 51 successors will make reference to specific applications, including 52 the Nexenta Replicast protocol for multicast replication in Nexenta's 53 Cloud Copy-on-Write (CCOW) Object Cluster used in the NexentaEdge 54 product. Such examples are merely for illustrative purposes. Any 55 IETF standardization of the Replicast storage protocols would be done 56 via the Storm or NFS groups, and would require adoption of a 57 definition of Object Storage as a service before standardizing any 58 specific protocol for providing Object Storage services. 60 At this stage in drafting message formats have not yet been set for 61 the standardized version of the protocol. The pre-standard version 62 was limited to a single L2 physical network, which would be an 63 inappropriate limitation for an IETF standard. Working Group 64 feedback on the format of these messages will be sought during the 65 consensus building process. 67 Status of This Memo 69 This Internet-Draft is submitted in full conformance with the 70 provisions of BCP 78 and BCP 79. 72 Internet-Drafts are working documents of the Internet Engineering 73 Task Force (IETF). Note that other groups may also distribute 74 working documents as Internet-Drafts. The list of current Internet- 75 Drafts is at http://datatracker.ietf.org/drafts/current/. 77 Internet-Drafts are draft documents valid for a maximum of six months 78 and may be updated, replaced, or obsoleted by other documents at any 79 time. It is inappropriate to use Internet-Drafts as reference 80 material or to cite them other than as "work in progress." 82 This Internet-Draft will expire on March 14, 2015. 84 Copyright Notice 86 Copyright (c) 2014 IETF Trust and the persons identified as the 87 document authors. All rights reserved. 89 This document is subject to BCP 78 and the IETF Trust's Legal 90 Provisions Relating to IETF Documents 91 (http://trustee.ietf.org/license-info) in effect on the date of 92 publication of this document. Please review these documents 93 carefully, as they describe your rights and restrictions with respect 94 to this document. Code Components extracted from this document must 95 include Simplified BSD License text as described in Section 4.e of 96 the Trust Legal Provisions and are provided without warranty as 97 described in the Simplified BSD License. 99 Table of Contents 101 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 102 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 103 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 104 3. An Example Application . . . . . . . . . . . . . . . . . . . 5 105 4. Generalized Usage of Transactional Subset Multicast Groups . 6 106 5. Transactional Subset Multicast Groups . . . . . . . . . . . . 6 107 5.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 6 108 5.1.1. Dynamic Specification versus Dynamic Selection . . . 7 109 5.1.2. Push vs. Join . . . . . . . . . . . . . . . . . . . . 7 110 5.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 111 5.2.1. How is the Group Selected? . . . . . . . . . . . . . 8 112 5.2.2. What are the endpoints that receive the messages? . . 9 113 5.2.3. What is the duration of the group? . . . . . . . . . 9 114 5.2.4. Who are the members of the group? . . . . . . . . . . 11 115 5.2.5. How much latency does the application tolerate? . . . 11 116 5.2.6. What must be done to maintain the Group? . . . . . . 12 117 6. Forwarding Control Agent . . . . . . . . . . . . . . . . . . 12 118 6.1. Network Topology . . . . . . . . . . . . . . . . . . . . 13 119 6.2. Isolated VLANs Strategy . . . . . . . . . . . . . . . . . 13 120 7. Forwarding Control Agent Methods . . . . . . . . . . . . . . 14 121 7.1. Dynamically Pushed Subset Groups . . . . . . . . . . . . 14 122 7.2. Persistent Transactional Subset Groups . . . . . . . . . 15 123 8. Relationship to Existing Multicast Membership Protocols . . . 16 124 9. Control Protocol . . . . . . . . . . . . . . . . . . . . . . 17 125 10. Forwarding Control Agent Methods . . . . . . . . . . . . . . 17 126 10.1. Create Transactional Multicast Address Block . . . . . . 17 127 10.2. Release Transactional Multicast Address Block . . . . . 18 128 10.3. Set Dynamic Transactional Multicast Group Membership 129 IPV6 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 130 10.4. Set Dynamic Transactional Multicast Group Membership 131 IPV4 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 132 10.5. Set Persistent Transactional Multicast Groups IPv6 . . . 19 133 10.6. Set Persistent Transactional Multicast Groups IPv4 . . . 20 134 10.7. Refresh Persistent Transactional Multicast Group . . . . 21 135 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 136 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 137 13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 138 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 139 14.1. Informative References . . . . . . . . . . . . . . . . . 23 140 14.2. Normative References . . . . . . . . . . . . . . . . . . 24 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 143 1. Introduction 145 Existing standards for controlling the membership of multicast groups 146 can be characterized as being Join-driven. These include 147 [RFC3376],[RFC3810], [RFC4541] and [RFC4604]. Due to their inherent 148 latency these techniques prove to be unsuitable for maintaining large 149 sets of related multiast groups. This memo details a new method of 150 maintaining such large sets of related multicast groups when they are 151 all subsets of a single master reference group. This is not a 152 restriction for most cluster-oriented applications which could use 153 transactional multicasting. 155 Transactional Subset Multicasting defines techniques that extends 156 existing control of a reference multicast group to a potentially 157 large set of multicast addresses used with a VLAN within each local 158 subnet that the reference multicast group reaches. 160 This specification makes no modifications to the forwarding of 161 multicast packets nor to the communications between mrouters. New 162 methods are defined to set Layer 2 multicast forwarding rules on 163 switches within each of the relevant Layer 2 subnets. 165 1.1. Requirements Notation 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 2. Motivation 173 Transactional Subset Multicast groups are maintained within each 174 VLAN. A 'Forwarding Control Agent' is defined within each VLAN that 175 is responsible for applying the forwarding information known for a 176 reference multicast group to efficiently set layer 2 multicast 177 forwarding rules within each local network. 179 The functionality of the Forwarding Control Agent is best understood 180 as extending the functionality of IGMP/MLD Snooping (See [RFC4541]). 182 An IGMP/MLD snooper interprets IGMP (see [RFC3376]) or MLD (see 183 [RFC3810]) messages to translate their Layer 3 objectives into Layer 184 2 multicast forwarding rules. 186 A Forwarding Control Agent interprets new messages defined in this 187 specification for a newly defined class of transactional subset 188 multicast groups into the same Layer 2 multicast forwarding rules. 189 Strategies for implementing Forwarding Control Agents would include 190 extending IGMP/MLD snooping implementations or building the 191 Forwarding Control Agent external to the existing L2 switch software. 193 The per transaction costs of using such groups are far lower than 194 with the existing methods. The ongoing maintenance work for 195 multicast forwarding elements is limited to the reference multicast 196 group, it is not replicated for each of the subset transactional 197 multicast groups. 199 3. An Example Application 201 The Replicast (see [Replicast]) usage of transactional subset 202 multicasting involves: 204 o Taking a Cryptographic Hash of each chunk to be stored. This 205 "hash id" is used with a distributed hash table to determine a 206 conventional multicast group which will be used to negotiate 207 placement of the chunk. This is the reference multicast group. 208 Replicast refers to it as a "Negotiating Group". 210 o Multicasting a request to put the chunk to the reference multicast 211 group. Receiving storage nodes will respond with a bid on when 212 they could store that chunk, or an indication that they already 213 have that chunk stored. Each of the storage nodes is offering a 214 provisional reservation of its input capacity for a specific time 215 window. 217 o Assuming that the chunk is not already stored, selecting the best 218 responses to make a transactional subset group. Determination of 219 'best' typically is driven by the earliest possible completion of 220 the transaction, but may factor the current available storage 221 capacity on each of the storage nodes as well. 223 o Form or select a "rendezvous group" which will be used to transfer 224 the chunk. When the core network is non-blocking, the transfer 225 will be able to proceed at close to full wire speed at the 226 reserved time because each of the selected storage nodes has 227 reserved its input capacity for bulk payload exclusively. A 228 multicast message to the reference group informs both those 229 selected and those not selected for the rendezvous transfer. 230 Those not selected will release the provisional reservation. 232 o At the designated time, multicast the chunk payload to the 233 transactional subset multicast group. 235 o Each recipient validates the cryptographic hash of the received 236 data, and unicasts a positive or negative acknowledgement to the 237 sender. 239 o If sufficient valid copies have been positively acknowledge, the 240 transaction is complete. Otherwise it is retried. 242 4. Generalized Usage of Transactional Subset Multicast Groups 244 Beyond a specific application, the generalized potential for dramatic 245 savings is that transactional messaging within a cluster is a 246 radically different use-case from traditional multicast. The set of 247 factors that differentiates this class of applications can be 248 examined through a series of questions: 250 o How is the group Selected? Section 5.2.1 252 o What are the endpoints that receive the messages? Section 5.2.2 254 o What is the duration of the group?Section 5.2.3 256 o Who are the potential members of the group? Section 5.2.4 258 o How much latency does the application tolerate? Section 5.2.5 260 o What must be done to maintain the group? Section 5.2.6 262 5. Transactional Subset Multicast Groups 264 5.1. Definition 266 A Transactions Subset Multicast Group is a multicast group which: 268 o Is derived from a pre-existing multicast group created by means 269 independent of this standard. The membership of this derived 270 group is a subset of the reference existing multicast group. 272 o Has a multicast group address which is part of a block allocated 273 for transactional multicast groups. 275 o Will only be used for the duration of a transaction. A network 276 failure or re-configuration during the transaction will require an 277 upper layer retry of the transaction. Transactional Subset 278 Multicast groups are not suitable for streaming of content. 279 Transactional subset multicast groups may be persistent, in that 280 the same group continues to exist and be used for a series of 281 transactions. But each message sent to the group is part of a 282 single short duration transaction. 284 5.1.1. Dynamic Specification versus Dynamic Selection 286 There are two basic strategies for managing the membership of subset 287 multicast groups: 289 o Dynamic Specification: The selected members join a group that had 290 been pre-selected for the transaction. 292 o Dynamic Selection: A pre-existing group is selected to match the 293 subset desired. That group is allocated for this purpose and used 294 for the transaction. 296 These two strategies can also be combined to form a hybrid strategy. 297 If there is a pre-existing group for the desired membership list it 298 is allocated and used, otherwise an available group is allocated and 299 re-configured to have the required membership. 301 5.1.2. Push vs. Join 303 Existing methods for managing membership of a multicast group can be 304 characterized as Join protocols. The receivers may join the group, 305 or subscribe to a specific source within a group, but the receivers 306 of multicast messages control their reception of multicast messages. 308 This model is well suited for multimedia transmission where the 309 sender does not necessarily know the full set of endpoints receiving 310 its multicast content. In many cluster application the sender has 311 determined the set of receivers. Requiring the sender to communicate 312 with the recipients so that they can Join the group adds latency to 313 the entire transaction. 315 However, there would be a serious security concern if transactional 316 multicasting is not limited to transactional subset multicasting. 317 Requiring that every member of a subset multicast group already be a 318 member of a reference multicast group ensures that no new method of 319 sending traffic is being created. Without this guarantee a denial- 320 of-service attacker could simply push a multicast group membership 321 listing 1000 members, then flood that multicast group. The amount of 322 traffic delivered to the aggregate destinations would be multiplied 323 by a factor of 1000. 325 Transactional subset multicasting is defined to eliminate the latency 326 required for Join-directed multicast group membership, while avoiding 327 creating a new attack vector for denial-of-service flooding. 329 5.2. Applicability 331 Transactional Subset Multicast Groups are applicable for applications 332 that want to reduce overall latency by reducing the number of round- 333 trips required for their transactions when identical content must be 334 delivered to multiple cluster members, but the selected members are a 335 subset of a larger group that must be dynamically selected. 337 Parallel processing of payload and/or storage of payload are the 338 primary examples of such a pattern of communications. 340 Examples of such applications include: 342 o Computational Clusters, particularly those using MPI (see [MPI]) 344 o Storage applications, including: 346 * pNFS (See [RFC5661]). 348 * Amazon Simple Storage Service (S3) (See [AmazonS3]). 350 * OpenStack Object Storage (Swift) (See [Swift]). 352 Dynamic selection of subsets ultimately enables multiple concurrent 353 transfers to occur, which would not have been possible if the message 354 had been sent to the entire reference multicast group. Applications 355 with relatively small payload to be multicast may find it easier to 356 use simple multicast and slightly over-deliver the message. 358 5.2.1. How is the Group Selected? 360 In Join-directed multicasting the membership of a multicast group is 361 controlled by the listeners joining and leaving the group. The 362 sender does not control or even know the recipients. This matches 363 the multicast streaming use-case very well. However it does not 364 match a cluster that needs to distribute a transactional message to a 365 subset of a known cluster. 367 The target group is also assumed to be stable for a long sequence of 368 packets, such as streaming a video. The targeted applications direct 369 transactions to a subset of a stable group. 371 One example of the need to distribute a transactional message to a 372 subset of a known cluster is replication of data within an object 373 cluster. A set of targets has been selected through an higher layer 374 protocol. Joi-directed group setup here adds excessive latency to 375 the process. The targets must be informed of their selection, they 376 must execute IGMP joins and confirm their joining to the source 377 before the multicast delivery can begin. Only replication of large 378 storage assets can tolerate this setup penalty. 380 A distributed computation may similarly have data that is relevant to 381 a specific set of recipients within the cluster. Performing the 382 distribution serially to each target over unicast point-to-point 383 connections uses excessive bandwidth and increases the transactions' 384 latency. It is also undesirable to incur the latency of Join-driven 385 multicast group setup. 387 This specification creates two methods for a sender to form or select 388 a multicast group for transactional purposes. With these methods no 389 further transmissions are required from the selected targets until 390 the full transfer is complete. 392 The restriction that the targeted group must be a subset of an 393 existing multicast group is necessary to prevent a denial-of-service 394 flooding attack. Transactional multicast groups that were not 395 restricted to being a subset of an existing multicast group could be 396 used to flood a large number of targets that were unprepared to 397 process incoming multicast datagrams. 399 5.2.2. What are the endpoints that receive the messages? 401 The endpoints of the transactional messages may be higher layer 402 entities, where each network endpoint supports multiples instances of 403 the higher layer entities. For example, a storage application may 404 have IP addresses associated with specific virtual drives, as opposed 405 to an IP address associated with a server that hosted multiple 406 virtual drives. 408 Having an IP address for each drive makes migrating control over that 409 drive to a new server easier, and allows the servers to direct 410 incoming payload to the correct drive. 412 5.2.3. What is the duration of the group? 414 Join-directed multicasting is designed primarily for the multicast 415 streaming use-case. A group has an indefinite lifespan, and members 416 come and go at any time during this lifespan, which might be measured 417 in minutes, hours or days. 419 Transaction multicasting is designed to support applications where a 420 transaction lasts for microseconds or milliseconds (possibly even 421 seconds). Transactional multicasting seeks to identify a multicast 422 group for the duration of sending a set of multicast datagrams 423 related to a specific transaction. Recipients either receive the 424 entire set of datagrams or they do not. Multicast streaming 425 typically is transmitting error tolerant content, such as MPEG 426 encoded material. Transaction multicasting will typically transmit 427 data with some form of validating signature and transaction 428 identifier that allows each recipient to confirm full reception of 429 the transaction. 431 This obviously needs to be combined with applicable congestion 432 control strategies being deployed by the upper layer protocols. The 433 Nexenta Replicast protocol only does bulk transfers against reserved 434 bandwidth, but there are probably as many solutions for this problem 435 as there are applications. Replicast relies upon IEEE I802.1 436 Datacenter Bridging (DCB) protocols such as Priority Flow Control and 437 Congestion Notification to provide no-drop service. The DCB 438 protocols deal with the fine timing of congestion avoidance, but 439 require higher layer transport or application protocols to keep the 440 sustained traffic rates below the sustained capacity. Creating 441 explicit reservations for bulk transfers is the main method for 442 accomplishing this. 444 The relevant DCB protocols include: 446 o Congestion Notification:[IEEE.802.1Qau-2011] 448 o Enhanced Transmission Selection:[IEEE.802.1Qaz-2011] 450 o Priority Flow Control[IEEE.802.1Qbb-2011] 452 The important distinction between Replicast and conventional 453 multicast applications is that there is no need to dynamically adjust 454 multicast forwarding tables during the lifespan of a transaction, 455 while IGMP and MLD are designed to allow the addition and deletion of 456 members while a multicast group is in use. This distinction is not 457 unique to any single storage application. Transactional replication 458 is a common element in cluster protocol design. 460 The limited duration of a transactional multicast group implies that 461 there is no need for the multicast forwarding element to rebuild its 462 forwarding tables after it restarts. Any transaction in progress 463 will have failed, and been retried by the higher-layer protocol. 464 Merely limiting the rate at which it fails and restarts is all that 465 is required of each forwarding element. 467 Another implication is that there is no need for the forwarding 468 elements to rebuild the membership list of a transactional multicast 469 group after the forwarding element has been reset. The transactions 470 using the forwarding element will all fail, and be retried by a 471 higher layer transport or application protocol. Assuming that 472 forwarding elements do not reset multiple times a minute this will 473 have very limited impact on overall application throughput. 475 The duration of a transaction is application specific, but inherently 476 limited. A failed transaction will be retried at the application 477 layer, so obviously it has a duration measured in seconds at the 478 longest. 480 5.2.4. Who are the members of the group? 482 Join-directed multicasting allows any number of recipients to join or 483 leave a group at will. 485 Transactional multicast requires that the group be identified as a 486 small subset of a pre-existing multicast group. 488 Building forwarding rules that are a subset of forwarding rules for 489 an existing multicast group can be done substantially faster than 490 creating forwarding rules to arbitrary and potentially previously 491 unknown destinations. 493 Some applications, including Object Clusters, benefit considering the 494 members to be higher layer entities (such as virtual drives) rather 495 than simply being the base IP address of the servers that host the 496 higher layer entities. Doing so allows groups to be defined for each 497 set of logical endpoints, not merely sets of physical endpoints. An 498 Object Cluster, for example, could have two different groups ([A,B,C] 499 vs [A,B,D]) even when the destinations are the same Layer 2 MAC 500 address (i.e., C and D are hosted by the same server). This allows 501 the server hosting both C and D to distinguish which entity is 502 addressed using the Destination IP Address. 504 5.2.5. How much latency does the application tolerate? 506 While no application likes latency, multicast streaming is very 507 tolerant of setup latency. If the end application is viewing or 508 listening to media, how many msecs are required to subscribe to the 509 group will not have a measurable impact to the end user. 511 For transactions in a cluster, however, every msec is delaying 512 forward progress. The time it takes to do an IGMP join would be a 513 significant addition to the latency of storing an object in an object 514 cluster using a relatively fast storage technology (such as SSD, 515 Flash or Memristor). 517 5.2.6. What must be done to maintain the Group? 519 The Join-directed multicast protocols specify methods for the 520 required maintenance of multicast groups.mMulticast forwarders, 521 switches or mrouters, must deal with new routes and new locations for 522 endpoints. 524 The reference multicast group will still be maintained by the 525 existing Join-directed multicast group protocols. The existing IGMP/ 526 MLD snooping procedures will keep the L2 multicasting forwarding 527 rules updated as changes in the network topology are detected. 528 Nothing in this specification changes the handling of the reference 529 multicast group. 531 Transactional subset multicast groups are defined to be used only for 532 short transactions, allowing them to piggy-back on the maintenance of 533 the reference multicast group. 535 6. Forwarding Control Agent 537 The Forwarding Control Agent is responsible for translating 538 forwarding control messages as defined in Section 7 into Layer 2 539 multicast forwarding for one or more subnets associated with a single 540 physical layer 2 subnet. 542 Each Forwarding Control Agent can be though of as extending the IGMP/ 543 MLD snooping capabilities of an L2 forwarding element. It is 544 translating the forwarding control agent messages into configuration 545 of L2 multicast forwarding just as an IGMP/MLD snooper translates 546 IGMP/MLD messages into configuration of Layer 2 multicast forwarding. 547 This MAY be done external to the existing implementation, or it may 548 be integrated with the IGMP/MLD snooper implementation. 550 Each Forwarding Control Agent: 552 o MUST Accept authenticated forwarding control agent messages 553 controlling the creation and membership of Transactional Subset 554 Multicast Groups within the context of a specified VLAN. 556 o MUST support at least one VLAN. 558 o MAY support multiple VLANs. 560 o MUST update the controlled Layer 2 forwarding element's multicast 561 forwarding rules to reflect the subset specified for the group. 563 o MUST Update the controlled L2 forwarding elements multicast 564 forwarding rules to reflect changes in the mapping of IP addresses 565 to L2 MAC addresses between transactions for persistent 566 transactional suset multicast groups when informed of a prior 567 transactional failure with a Refresh Membership message (see 568 Figure 7). 570 o MAY refresh the Layer 2 multicast forwarding rules at any time. 572 6.1. Network Topology 574 Forwarding Control Agents are applicable for networks which consist 575 of one or more local subnets which have direct links with each other. 577 6.2. Isolated VLANs Strategy 579 Transactional Subset Multicast groups define a very large number of 580 multicast addresses which must be delivered within a closed set of IP 581 subnets without having to dynamically co-ordinate allocation of these 582 multicast addresses with a wider network. 584 This MAY be accomplished using a "Isolated VLANs Strategy" where the 585 reference multicast group and all transactional multicast groups 586 derived from it are used strictly inside of a single VLAN or a set of 587 interconnected VLANs which route these multicast groups solely within 588 this closed set. 590 Specifically, an implementation using the Isolated VLANs Strategy: 592 o MUST include only a pre-defined set of subnets,each enforced with 593 a VLAN. 595 o MUST provide for routing or forwarding of all packets using the 596 reference multicast group and all transactional subset multicast 597 groups derived from it amongst these subnets. 599 o MUST NOT allow any packet using the reference multicast group or 600 any transactional subset multicast groups derived from it to be 601 routed to any subnet that is not part of the identified Isolated 602 VLAN set. 604 o MAY/SHOULD guard the confidentiality of multicast packets routed 605 between subnets that transit subnets that are not part of the 606 Isolated VLAN set. 608 Applications MAY use the Isolated VLAN Strategy. Virtually all 609 applications will elect to do so because allocating a very large 610 block of adjacent multicast addresses would be very difficult. 611 Confining usage of these addresses to a single VLAN is highly 612 desirable. 614 Direct connections between the VLANs hosting Forwarding Control 615 Agents is required because the Transactional Subset Multicast Groups 616 are not known to any intermediate multicast routers that would 617 implement indirect links. Co-locating Forwarding Control Agents with 618 RBridges [[RFC6325]] MAY be a solution. 620 7. Forwarding Control Agent Methods 622 7.1. Dynamically Pushed Subset Groups 624 Each Pushed Subset Membership commands MUST contain the following: 626 o Subset Transactional Multicast Group: Group multicast address that 627 is to have its multicast forwarding rules updated. This address 628 must be within a block of Transactional Multicast Groups 629 previously created using the Create Transactional Multicast 630 Address Block command (Section 10.1). 632 o Target List: List of IP Addresses which are to be the targets of 633 this group. These addresses are intended to be members of the 634 reference group. When formulating the list, non-members MUST NOT 635 be included. However there is no transaction lock placed upon the 636 group, and therefor there may be changes in the group membership 637 before the message is received. Therefore the Forwarding Control 638 Agent MUST ignored any listed target that is not a member of the 639 reference group. 641 This sets the multicast forwarding rules for pre-existing multicast 642 forwarding address X to be the subset of the forwarding rules for 643 existing group Y required to reach a specified member list. 645 This is done by communicating the same instruction (above) to each 646 multicast forwarding network element. This can be done by unicast 647 addressing with each of them, or by multicasting the instructions. 649 Each multicast forwarder will modify its multicast forwarding port 650 set to be the union of the unicast forwarding it has for the listed 651 members, but result must be a subset of the forwarding ports for the 652 parent group. 654 For example, consider an instruction is to modify a transaction 655 multicast group I which is a subset of multicast group J to reach 656 addresses A,B and C. 658 Addresses A and B are attached directly to multicast forwarder X, 659 while C is attached to multicast forwarder Y. 661 On forwarder X the forwarding rule for new group I contains: 663 o The forwarding port for A. 665 o The forwarding port for B. The forwarding port to forwarder Y (a 666 hub link). This eventually leads to C. 668 While on forwarder Y the forwarding rule for the new group I will 669 contain: 671 The forwarding port for forwarder X (a hub link). This eventually 672 leads to A and B. 674 The forwarding port for C. 676 This assumes that the Forwarding Control Agent can perform a two-step 677 translation: first from IP Address to MAC Address, and then from MAC 678 Address to forwarding port. For typical applications of 679 Transactional Subset Multicasting, all of the referenced IP Addresses 680 will have been involved in recent messaging, and therefore will 681 frequently already be cached. 683 Many ethernet switches already support command line and/or SNMP 684 methods of setting these multicast forwarding rules, but it is 685 challenging for an application to reliably apply the same changes 686 using multiple vendor specific methods. Having a standardized method 687 of pushing the membership of a multicast group from the sender would 688 be desirable. 690 A Forwarding Control Agent MAY accept a request where the Target List 691 is expressed as a list of destination L2 MAC addresses. 693 7.2. Persistent Transactional Subset Groups 695 There is a large group of pre-configured multicast groups which are 696 an enumeration of the possible subsets of a master group. This will 697 be a specific subset, such as all combinations of 3 members for 698 multicast group X. These groups are enumerated and assuaged 699 successive multicast addresses within a block. 701 The sender first obtains exclusive permission to utilize a portion of 702 the reception capacity of each desire target, and then selects the 703 multicast address that will reach that group. 705 In a straightforward enumeration of 3 members out of a group of 20, 706 there are 20*19*18/3*2 or 1040 possible groups. Typically the higher 707 layer protocol will have negotiated the right to send the transaction 708 with the member prior to selecting the multicast group. In making 709 the final selection, the actual multicast group is selected and some 710 offered targets are declined. 712 Those 1040 possible groups can be enumerated in order (starting with 713 M1, M2 and M3 and ending with M18, M19 and M20) and assigned 714 multicast addresses from N to N+1039. 716 When the transaction requires reaching M4, M5 and M19, you simply 717 select that group. Because exclusive rights to use multicasting to 718 M4, M5 and M19 have already been obtained through the higher layer 719 protocol the group [M4,M5,M19] is already exclusively claimed. 721 These 1040 groups may be set up through any of the following means: 723 o Traditional IGMP/MLD joining/leaving. 725 o Setting static forwarding rules using SNMP MIBs and/or switch- 726 specific command line interfaces. Note that the wide-spread 727 existence of command line interfaces to custom set multicast 728 forwarding rules is an indicator that there are existing 729 applications that find the exising IGMP/MLD protocols to be 730 inadequate to fulfill their needs. 732 o The Dynamically Pushed Multicast Group method. See Section 7.1 734 8. Relationship to Existing Multicast Membership Protocols 736 TBD: briefly describe and cite IGMP, MLD and PIM. 738 Transactional Subset Multicast Groups are not a replacement for Join- 739 based management of Multicast Groups. Rather it extends the group 740 maintenance performed by the Join-based multicast control protocols 741 from the reference group to any entire set of multicast addresses 742 that are subsets of it. 744 This extension requires no modification to the existing data-plane 745 multicast forwarding protocols or implementations. Transactional 746 Subset Multicast groups may be implemented solely in the sender, 747 receivers and the Forwarding Control Agents associated with each 748 multicast forwarder supporting the reference group. 750 The maintenance work of the Join-based multicast protocols performed 751 on the reference multicast group is leveraged to allow maintenance of 752 a potentially large number of derived Transactional Multicast groups. 753 This allows identification of a large number of subsets of the 754 reference group, without requiring a matching increase in the 755 maintenance traffic which would have been required had the derived 756 groups been formed with a Join-based protocol. 758 9. Control Protocol 760 Note: the pre-standard protocol relies on multicasting of commands 761 within a single secure VLAN. More general usage of these techniques 762 will require transmitting Forwarding Control Agent instructions 763 between subnets where they may be subject to interception and even 764 alteration. Therefore a more secure method of delivering Forwarding 765 Control Agent instructions is required. 767 The methods standardized by the KARP (Key Authentication for Router 768 Protocols) are, in the Authors' opinion, fully applicable to this 769 protocol. See [RFC6518]. Working Group feedback is sought as to how 770 to expand this section, whether to split the Control Protocol to a 771 separate document, or other methods of dealing with the control 772 protocol. 774 The following requirements apply to any Control Protocol used: 776 o Each request MUST be uniquely identified. This identification 777 MUST include the source IP address of the requester. 779 o The message MUST be authenticated. 781 o WG discussion is needed to reach a consensus as to whether the 782 message contents need to be kept confidential, or whether 783 preventing alteration is sufficient. 785 o The sender MUST NOT be required to transmit the command more than 786 once other than as required for retries. For example, requiring 787 SSH connections with each Forwarding Control Agent is not 788 acceptable. 790 o Barring network errors, the message MUST be delivered to all 791 Forwarding Control Agents that can receive the reference master 792 group. 794 10. Forwarding Control Agent Methods 796 10.1. Create Transactional Multicast Address Block 798 TBD:This section will define the fields required for the command to 799 create a block of transactional subset multicast addresses within a 800 specific VLAN. The command defined here is delivered within a 801 control protocol. 803 0 1 2 3 804 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Opcode=CreateTransactionalMulticast | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Base Multicast Group Number | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 810 | Number of Addresses required in Block | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_-+--+-+ 813 Figure 1: Create Transcaction Multicast Address Block Message 815 The Multicast Group Number is the 24-bit L2 Multicast MAC address. 816 This matches both the IPV4 and IPV6 addresses which map to it. A 817 given UDP datagram is sent using either an IPV4 or an IPV6 address, 818 so the membership of a Multicast Group is either IPV4 endpoints or 819 IPV6 endpoints at any given instant. 821 This command does not allow creating numerically scattered group of 822 addresses. Doing so would have made the job of each Forwarding 823 Control Agent more complex, and would be of no benefit in the 824 recommended Isolated VLANs strategy (See Section 6.2). 826 note: add IANA language here 828 10.2. Release Transactional Multicast Address Block 830 0 1 2 3 831 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Opcode=ReleaseTransactionalMulticast | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Base Multicast Group Number | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 838 Figure 2: Release Transcactin Multicast Address Block Message 840 note: add IANA language here 842 10.3. Set Dynamic Transactional Multicast Group Membership IPV6 843 0 1 2 3 844 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Opcode=PushTransactionalMulticastMembershipIPV6 | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | # members | Multicast Group Number | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | | 851 | IPV6 Address of 1st Member | 852 | | 853 | | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 ... 857 Figure 3: Set Dynamic Transactional Multicast Group Membership 858 Message 860 Members: 8 bit unsigned number of IPV6 addresses that are to be the 861 target of this specified Multicast Group Number. 863 note: add IANA language here 865 10.4. Set Dynamic Transactional Multicast Group Membership IPV4 867 0 1 2 3 868 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Opcode=PushTransactionalMulticastMembershipIPV4 | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | # members | Multicast Group Number | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | IPV4 Address of 1st member | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 ... 878 Figure 4: Set Dynamic Transactional Multicast Group Membership 879 Message 881 Members: 8 bit unsigned number of IPV6 addresses that are to be the 882 target of this specified Multicast Group Number. 884 note: add IANA language here 886 10.5. Set Persistent Transactional Multicast Groups IPv6 887 0 1 2 3 888 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Opcode=PushPersistentMulticastMembershipIPV6 | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | select N | Base Multicast Group Number to be | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | # members | Reference Multicast Group Num | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | IPV6 Address of 1st Member | 897 | | 898 | | 899 | | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 ... 903 Figure 5: Set Persistent Transactional Multicast Groups Message IPV6 905 Members: 8 bit unsigned number of Members that are to be included in 906 each Transactional Subset Group set by this command. 908 Base Multicast Group Number to be set. 910 # Members in the following list of IPV6 addresses. These must all be 911 members of the Reference Multicast Group. 913 Reference Multicast Group Num: 24 bit L2 Multicast Group Number. 915 The motivation for supplying the list of IP addresses is to avoid 916 race conditions where an IGMP or MLD join is in progress. If there 917 were a method to refer to a specific generation of a multicast group 918 membership then it would be possible to omit this list. Working 919 Group suggestions are encouraged on this topic. 921 note: add IANA language here 923 10.6. Set Persistent Transactional Multicast Groups IPv4 924 0 1 2 3 925 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Opcode=PushPersistentMulticastMembershipIPV6 | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | select N | Base Multicast Group Number to be | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | # members | Reference Multicast Group Num | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | IPV4 Address of 1st Member | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 ... 937 Figure 6: Set Persistent Transactional Multicast Groups Message IPv4 939 Members: 8 bit unsigned number of Members that are to be included in 940 each Transactional Subset Group set by this command. 942 Base Multicast Group Number to be set. 944 # Members in the following list of IPV6 addresses. These must all be 945 members of the Reference Multicast Group. 947 Reference Multicast Group Num: 24 bit L2 Multicast Group Number. 949 note: add IANA language here 951 10.7. Refresh Persistent Transactional Multicast Group 953 0 1 2 3 954 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Opcode=RefreshMulticastMembership | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | reserve | Multicast Group Number to be Refreshed | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | reserved | Reference Multicast Group Num | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 Figure 7: Refresh Persistent Transactional Multicast Groups Message 965 The existing Join-directed multicast group control protocols maintain 966 delivery of a multicast group to the subscribers independent of 967 network topology changes either at Layer 2 or layer 3. If a unicast 968 IP datagram to a member would be delivered, then the multicast 969 forwarding can be expected to also be current. 971 Transactional subset multicast groups do not require the same effort 972 for maintenance. For a given transaction the entire set of datagrams 973 is either delivered or it is not. There is no benefit to the 974 application that the Forwarding Control Agent can achieve by promptly 975 updating the L2 multicast forwarding tables after a network topology 976 change. The current transaction will miss at least one datagram, and 977 therefore does not care if it misses multiple datagrams. 979 However, a Persistent Transactional Subset Mutlicast Group is used 980 for a sequence of transactions targeting the same group. The upper 981 layer protocol sender must have obtained exclusive rights to use the 982 group for the period of time that it will be sending the transaction. 984 One method that it MAY use is to obtain the exclusive right to send 985 the specific type of transaction to each of the members of the 986 targeted group during negotiations conducted prior to use of the 987 transactional group. For example, a reservation on inbound bandwidth 988 may have been granted. 990 The Forwarding Control Agent MAY refresh its mapping from member IP 991 addresses to L2 MAC address and then to L2 forwarding port at any 992 time. However it MUST do so after receipt of a Refresh Transactional 993 Subset Multicast Group for the group. 995 The sender of a transaction SHOULD send a Refresh Transactional 996 Subset Multicast Group message after it fails to receive 997 acknowledgement of an attempted transaction. 999 11. Security Considerations 1001 The methods described here enable no sender to multicast messages to 1002 any destination that was not already addressable by it. Therefore no 1003 new security vulnerabilities are enabled by these techniques. 1005 Because authentication of subset commands is kept lightweight there 1006 is an implicit trust within the application that transactional subset 1007 groups will be formed or selected in accordance with application 1008 layer expectations. The transport layer lacks sufficient information 1009 to enforce application layer expectations. If a malicious actor 1010 deliberately creates a transactional subset multicast group with an 1011 incorrect group it may adversely impact the operation of the specific 1012 upper layer application. However in no case can it be used to launch 1013 a denial of service attack on targets that have not already 1014 voluntarily joined the reference group 1016 The protocol does not currently provide any mechanism to guard 1017 against selecting an existing but unrelated multicast group as a 1018 reference multicast group. Explicitly enabling use of an existing 1019 multicast group to be a reference group would not solve the problem 1020 that the existing management of multicast groups is not aware of the 1021 need to explicitly forbid creation of derived multicast groups based 1022 upon a multicast group that it creates. 1024 12. IANA Considerations 1026 To be completed. 1028 13. Summary 1030 The proposal provides for two new methods to manage multicast group 1031 membership, Thee are simple techniques, but provide a cohesive 1032 cluster-wide approach to providing transactional multicasting. These 1033 techniques are better suited for transactional multicasting that the 1034 existing methods, IGMP and MLD, which are oriented to streaming use- 1035 cases. 1037 14. References 1039 14.1. Informative References 1041 [Replicast] 1042 Bestler, C., "White Paper: Nexenta Replicast 1043 http://info.nexenta.com/rs/nexenta/images/ 1044 Nexenta_Replicast_White_Paper.pdf", November 2013. 1046 [MPI] MPI Forum, "Message Passing Inteface", 2012. 1048 [AmazonS3] 1049 Amazon, "Amazon Simple Storage Service (S3) 1050 http://aws.amazon.com/s3/", 2014. 1052 [Swift] Openstack, "OpenStack Object Service (Swift) 1053 http://docs.openstack.org/developer/swift/", 2014. 1055 [IEEE.802.1Qau-2011] 1056 IEEE, "IEEE Standard for Local and Metropolitan Area 1057 Networks: Virtual Bridged Local Area Networks - Amendment 1058 10: Congestion Notification", IEEE Std 802.1Qau, 2011. 1060 [IEEE.802.1Qaz-2011] 1061 IEEE, "IEEE Standard for Local and Metropolitan Area 1062 Networks: Virtual Bridged Local Area Networks - Amendment 1063 18: Enhanced Transmission Selection.", IEEE Std 802.1Qaz, 1064 2011. 1066 [IEEE.802.1Qbb-2011] 1067 IEEE, "IEEE Standard for Local and Metropolitan Area 1068 Networks: Virtual Bridged Local Area Networks - Amendment 1069 17: Priority-based Flow Control.", IEEE Std 802.1Qbb, 1070 2011. 1072 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 1073 System (NFS) Version 4 Minor Version 1 Protocol", RFC 1074 5661, January 2010. 1076 14.2. Normative References 1078 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1079 Requirement Levels", BCP 14, RFC 2119, March 1997. 1081 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1082 Thyagarajan, "Internet Group Management Protocol, Version 1083 3", RFC 3376, October 2002. 1085 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1086 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1088 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 1089 "Considerations for Internet Group Management Protocol 1090 (IGMP) and Multicast Listener Discovery (MLD) Snooping 1091 Switches", RFC 4541, May 2006. 1093 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1094 Group Management Protocol Version 3 (IGMPv3) and Multicast 1095 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1096 Specific Multicast", RFC 4604, August 2006. 1098 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 1099 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1100 Specification", RFC 6325, July 2011. 1102 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 1103 Routing Protocols (KARP) Design Guidelines", RFC 6518, 1104 February 2012. 1106 Authors' Addresses 1107 Caitlin Bestler (editor) 1108 Nexenta Systems 1109 455 El Camino Real 1110 Santa Clara, CA 1111 US 1113 Email: caitlin.bestler@nexenta.com,cait@asomi.com 1115 Robert Novak 1116 Nexenta Systems 1117 455 El Camino Real 1118 Santa Clara, CA 1119 US 1121 Email: robert.novak@nexenta.com