idnits 2.17.1 draft-ietf-rmt-buildingblocks-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. == 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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PSLM97' is mentioned on line 190, but not defined == Unused Reference: 'Kermode98' is defined on line 740, but no explicit reference was found in the text == Unused Reference: 'LDW98' is defined on line 744, but no explicit reference was found in the text == Unused Reference: 'LESZ97' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'OXB99' is defined on line 783, but no explicit reference was found in the text == Unused Reference: 'PSLB97' is defined on line 787, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BKKKLZ95' -- Possible downref: Non-RFC (?) normative reference: ref. 'BLMR98' -- Possible downref: Non-RFC (?) normative reference: ref. 'FJM95' -- Possible downref: Non-RFC (?) normative reference: ref. 'FLST98' -- Possible downref: Non-RFC (?) normative reference: ref. 'HFW99' ** Obsolete normative reference: RFC 2327 (ref. 'HJ98') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. 'HPW99' -- Possible downref: Non-RFC (?) normative reference: ref. 'HW99' -- Possible downref: Non-RFC (?) normative reference: ref. 'HWKFV99' -- Possible downref: Non-RFC (?) normative reference: ref. 'KCW98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kermode98' -- Possible downref: Non-RFC (?) normative reference: ref. 'LDW98' -- Possible downref: Non-RFC (?) normative reference: ref. 'LESZ97' -- Possible downref: Non-RFC (?) normative reference: ref. 'LG97' -- Possible downref: Non-RFC (?) normative reference: ref. 'LP96' -- Possible downref: Non-RFC (?) normative reference: ref. 'LMSSS97' -- Possible downref: Non-RFC (?) normative reference: ref. 'LVS99' -- Possible downref: Non-RFC (?) normative reference: ref. 'MA99' ** Downref: Normative reference to an Informational RFC: RFC 2357 (ref. 'MRBP98') -- Possible downref: Non-RFC (?) normative reference: ref. 'OXB99' -- Possible downref: Non-RFC (?) normative reference: ref. 'PSLB97' -- Possible downref: Non-RFC (?) normative reference: ref. 'RV97' -- Possible downref: Non-RFC (?) normative reference: ref. 'VRC98' -- Possible downref: Non-RFC (?) normative reference: ref. 'WBPM98' -- Possible downref: Non-RFC (?) normative reference: ref. 'WHA98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Whetten99' Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RMT Working Group B. Whetten/Talarian 2 Internet Engineering Task Force L. Vicisano/Cisco 3 INTERNET-DRAFT R.Kermode/Motorola 4 draft-ietf-rmt-buildingblocks-02.txt M.Handley/ACIRI 5 10 March 2000 S.Floyd/ACIRI 6 Expires 10 September 2000 M.Luby/Digital Fountain 8 Reliable Multicast Transport Building Blocks for One-to-Many 9 Bulk-Data Transfer 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are valid for a maximum of six months and may be 18 updated, replaced, or obsoleted by other documents at any time. It 19 is inappropriate to use Internet-Drafts as reference material or to 20 cite them other than as a "work in progress". 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes a framework for the standardization of bulk-data 31 reliable multicast transport. It builds upon the experience gained 32 during the deployment of several classes of contemporary reliable 33 multicast transport, and attempts to pull out the commonalities between 34 these classes of protocols into a number of building blocks. To that 35 end, this document recommends that certain components that are common to 36 multiple protocol classes be standardized as "building blocks." The 37 remaining parts of the protocols, consisting of highly protocol 38 specific, tightly intertwined functions, shall be designated as 39 "protocol cores." Thus, each protocol can then be constructed by 40 merging a "protocol core" with a number of "building blocks" which can 41 be re-used across multiple protocols. 43 Draft RMT Building Blocks 10 March 2000 45 Copyright Notice 47 Copyright (C) The Internet Society (1999, 2000). All Rights Reserved. 49 1. Introduction 51 RFC2357 lays out the requirements for reliable multicast protocols that 52 are to be considered for standardization by the IETF. They include: 54 o Congestion Control. The protocol must be safe to deploy in the 55 widespread Internet. Specifically, it must adhere to three mandates: 56 a) it must achieve good throughput (i.e. it must not consistently 57 overload links with excess data or repair traffic), b) it must 58 achieve good link utilization, and c) it must not starve competing 59 flows. 61 o Scalability. The protocol should be able to work under a variety of 62 conditions that include multiple network topologies, link speeds, and 63 the receiver set size. It is more important to have a good 64 understanding of how and when a protocol breaks than when it works. 66 o Security. The protocol must be analyzed to show what is necessary to 67 allow it to cope with security and privacy issues. This includes 68 understanding the role of the protocol in data confidentiality and 69 sender authentication, as well as how the protocol will provide 70 defenses against denial of service attacks. 72 These requirements are primarily directed towards making sure that any 73 standards will be safe for widespread Internet deployment. The 74 advancing maturity of current work on reliable multicast congestion 75 control (RMCC) [HFW99] in the IRTF Reliable Multicast Research Group 76 (RMRG) has been one of the events that has allowed the IETF to charter 77 the RMT working group. RMCC only addresses a subset of the design space 78 for reliable multicast. Fortuitously, the requirements it addresses are 79 also the most pressing application and market requirements. 81 A protocol's ability to meet the requirements of congestion control, 82 scalability, and security is affected by a number of secondary 83 requirements that are described in a separate document [HWKFV99]. In 84 summary, these are: 86 Draft RMT Building Blocks 10 March 2000 88 o Ordering Guarantees. A protocol must offer at least one of either 89 source ordered or unordered delivery guarantees. Support for total 90 ordering across multiple senders is not recommended, as it makes it 91 more difficult to scale the protocol, and can more easily be 92 implemented at a higher level. 94 o Receiver Scalability. A protocol should be able to support a "large" 95 number of simultaneous receivers per transport group. A typical 96 receiver set could be on the order of at least 1,000 - 10,000 97 simultaneous receivers per group, or could even eventually scale up 98 to millions of receivers in the large Internet. 100 o Real-Time Feedback. Some versions of RMCC may require soft real-time 101 feedback, so a protocol may provide some means for this information 102 to be measured and returned to the sender. While this does not 103 require that a protocol deliver data in soft real-time, it is an 104 important application requirement that can be provided easily given 105 real-time feedback. 107 o Delivery Guarantees. In many applications, a logically defined unit 108 or units of data is to be delivered to multiple clients, e.g., a file 109 or a set of files, a software package, a stock quote or package of 110 stock quotes, an event notification, a set of slides, a frame or 111 block from a video. An application data unit is defined to be a 112 logically separable unit of data that is useful to the application. 113 In some cases, an application data unit may be short enough to fit 114 into a single packet (e.g., an event notification or a stock quote), 115 whereas in other cases an application data unit may be much longer 116 than a packet (e.g., a software package). A protocol must provide 117 good throughput of application data units to receivers. This means 118 that most data that is delivered to receivers is useful in recovering 119 the application data unit that they are trying to receive. A 120 protocol may optionally provide delivery confirmation, i.e., a 121 mechanism for receivers to inform the sender when data has been 122 delivered. There are two types of confirmation, at the application 123 data unit level and at the packet level. Application data unit 124 confirmation is useful at the application level, e.g., to inform the 125 application about receiver progress and to decide when to stop 126 sending packets about a particular application data unit. Packet 127 confirmation is useful at the transport level, e.g., to inform the 128 transport level when it can release buffer space being used for 129 storing packets for which delivery has been confirmed. Packet level 130 confirmation may also aid in application data unit confirmation. 132 Draft RMT Building Blocks 10 March 2000 134 o Network Topologies. A protocol must not break the network when 135 deployed in the full Internet. However, we recognize that intranets 136 will be where the first wave of deployments happen, and so are also 137 very important to support. Thus, support for satellite networks 138 (including those with terrestrial return paths or no return paths at 139 all) is encouraged, but not required. 141 o Group Membership. The group membership algorithms must be scalable. 142 Membership can be anonymous (where the sender does not know the list 143 of receivers), or fully distributed (where the sender receives a 144 count of the number of receivers, and optionally a list of failures). 146 o Example Applications. Some of the applications that a RM protocol 147 could be designed to support include multimedia broadcasts, real time 148 financial market data distribution, multicast file transfer, and 149 server replication. 151 In the rest of this document the following terms will be used with a 152 specific connotation: "protocol family", "protocol component", "building 153 block", "protocol core", and "protocol instantiation". A "protocol 154 family" is a broad class of RM protocols which share a common 155 characteristic. In our classification, this characteristic is the 156 mechanism used to achieve reliability. A "protocol component" is a 157 logical part of the protocol that addresses a particular functionality. 158 A "building block" is a constituent of a protocol that implements one, 159 more than one or a part of a component. A "protocol core" is the set of 160 functionality required for the instantiation of a complete protocol, 161 that is not specified by any building block. Finally a "protocol 162 instantiation" is an actual RM protocol defined in term of building 163 blocks and a protocol core. 165 1.1. Protocol Families 167 The design-space document [HWKFV99] also provides a taxonomy of the most 168 popular approaches that have been proposed over the last ten years. 169 After congestion control, the primary challenge has been that of meeting 170 the requirement for ensuring good throughput in a way that scales to a 171 large number of receivers. For protocols that include a back-channel 172 for recovery of lost packets, the ability to take advantage of support 173 of elements in the network has been found to be very beneficial for 174 supporting good throughput for a large numbers of receivers. Other 175 protocols have found it very beneficial to transmit coded data to 176 achieve good throughput for large numbers of receivers. 178 Draft RMT Building Blocks 10 March 2000 180 This taxonomy breaks proposed protocols into four families. Some 181 protocols in the family provide packet level delivery confirmation that 182 may be useful to the transport level. All protocols in all families can 183 be supplemented with higher level protocols that provide delivery 184 confirmation of application data units. 186 1 NACK only. Protocols such as SRM [FJM95] and MDP2 [MA99] attempt to 187 limit traffic by only using NACKs for requesting packet 188 retransmission. They do not require network infrastructure. 190 2 Tree based ACK. Protocols such as RMTP [LP96, PSLM97], RMTP-II 191 [WBPM98] and TRAM [KCW98], use positive acknowledgments (ACKs). ACK 192 based protocols reduce the need for supplementary protocols that 193 provide delivery confirmation, as the ACKS can be used for this 194 purpose. In order to avoid ACK implosion in scaled up deployments, 195 the protocol can use servers placed in the network. 197 3 Open-Loop delivery. These protocols (examples include [RV97] and 198 [BLMR98]) use sender-based Forward Error Correction (FEC) methods 199 with no feedback from receivers or the network to ensure good 200 throughput. 202 4 Router assist. Like SRM, protocols such as PGM [FLST98] and [LG97] 203 also use negative acknowledgments for packet recovery. These 204 protocols take advantage of new router software to do constrained 205 negative acknowledgments and retransmissions. Router assist protocols 206 can also provide other functionality more efficiently than end to end 207 protocols. For example, [LVS99] shows how router assist can provide 208 fine grained congestion control to open-loop delivery protocols. 209 Router assist protocols can be designed to complement all protocol 210 families described above. 212 Note that the distinction in protocol families in not necessarily 213 precise and mutually exclusive. Actual protocols may use a combination 214 of the mechanisms belonging to different classes. For example, hybrid 215 NACK/ACK based protocols (such as [WBPM98]) are possible. Other 216 examples are protocols belonging to class 1 through 3 that take 217 advantage of router support. 219 2. Building Blocks Rationale 221 As specified in RFC2357 [MRBP98], no single reliable multicast protocol 222 will likely meet the needs of all applications. Therefore, the IETF 223 expects to standardize a number of protocols that are tailored to 224 application and network specific needs. This document concentrates on 225 Draft RMT Building Blocks 10 March 2000 227 the requirements for "one-to-many bulk-data transfer", but in the 228 future, additional protocols and building-blocks are expected that will 229 address the needs of other types of applications, including "many-to- 230 many" applications. Note that bulk-data transfer does not refer to the 231 timeliness of the data, rather it states that there is a large amount of 232 data to be transferred in a session. The scope and approach taken for 233 the development of protocols for these additional scenarios will depend 234 upon large part on the success of the "building-block" approach put 235 forward in this document. 237 2.1. Building Blocks Advantages 239 Building a large piece of software out of smaller modular components is 240 a well understood technique of software engineering. Some of the 241 advantages that can come from this include: 243 o Specification Reuse. Modules can be used in multiple protocols, 244 which reduces the amount of development time required. 246 o Reduced Complexity. To the extent that each module can be easily 247 defined with a simple API, breaking a large protocol in to smaller 248 pieces typically reduces the total complexity of the system. 250 o Reduced Verification and Debugging Time. Reduced complexity results 251 in reduced time to debug the modules. It is also usually faster to 252 verify a set of smaller modules than a single larger module. 254 o Easier Future Upgrades. There is still ongoing research in reliable 255 multicast, and we expect the state of the art to continue to evolve. 256 Building protocols with smaller modules allows them to be more easily 257 upgraded to reflect future research. 259 o Common Diagnostics. To the extent that multiple protocols share 260 common packet headers, packet analyzers and other diagnostic tools 261 can be built which work with multiple protocols. 263 o Reduces Effort for New Protocols. As new application requirements 264 drive the need for new standards, some existing modules may be reused 265 in these protocols. 267 o Parallelism of Development. If the APIs are defined clearly, the 268 development of each module can proceed in parallel. 270 Draft RMT Building Blocks 10 March 2000 272 2.2. Building Block Risks 274 Like most software specification, this technique of breaking down a 275 protocol in to smaller components also brings tradeoffs. After a 276 certain point, the disadvantages outweigh the advantages, and it is not 277 worthwhile to further subdivide a problem. These risks include: 279 o Delaying Development. Defining the API for how each two modules 280 inter-operate takes time and effort. As the number of modules 281 increases, the number of APIs can increase at more than a linear 282 rate. The more tightly coupled and complex a component is, the more 283 difficult it is to define a simple API, and the less opportunity 284 there is for reuse. In particular, the problem of how to build and 285 standardize fine grained building blocks for a transport protocol is 286 a difficult one, and in some cases requires fundamental research. 288 o Increased Complexity. If there are too many modules, the total 289 complexity of the system actually increases, due to the preponderance 290 of interfaces between modules. 292 o Reduced Performance. Each extra API adds some level of processing 293 overhead. If an API is inserted in to the "common case" of packet 294 processing, this risks degrading total protocol performance. 296 o Abandoning Prior Work. The development of robust transport protocols 297 is a long and time intensive process, which is heavily dependent on 298 feedback from real deployments. A great deal of work has been done 299 over the past five years on components of protocols such as RMTP-II, 300 SRM, and PGM. Attempting to dramatically re-engineer these 301 components risks losing the benefit of this prior work. 303 2.3. Building Block Requirements 305 Given these tradeoffs, we propose that a building block must meet the 306 following requirements: 308 o Wide Applicability. In order to have confidence that the component 309 can be reused, it should apply across multiple protocol families and 310 allow for the component's evolution. 312 o Simplicity. In order to have confidence that the specification of 313 the component APIs will not dramatically slow down the standards 314 process, APIs must be simple and straight forward to define. No new 316 Draft RMT Building Blocks 10 March 2000 318 fundamental research should be done in defining these APIs. 320 o Performance. To the extent possible, the building blocks should 321 attempt to avoid breaking up the "fast track", or common case packet 322 processing. 324 3. Protocol Components 326 This section proposes a functional decomposition of RM bulk-data 327 protocols from the perspective of the functional components provided to 328 an application by a transport protocol. It also covers some components 329 that while not necessarily part of the transport protocol, are directly 330 impacted by the specific requirements of a reliable multicast transport. 331 The next section then specifies recommended building blocks that can 332 implement these components. 334 Although this list tries to cover all the most common transport-related 335 needs of one-to-many bulk-data transfer applications, new application 336 requirements may arise during the process of standardization, hence this 337 list must not be interpreted as a statement of what the transport layer 338 should provide and what it should not. Nevertheless, it must be pointed 339 out that some functional components have been deliberately omitted since 340 they have been deemed irrelevant to the type of application considered 341 (i.e. one-to-many bulk-data transfer). Among these are advanced message 342 ordering (i.e. those which cannot be implemented through a simple 343 sequence number) and atomic delivery. 345 It is also worth mentioning that some of the functional components 346 listed below may be required by other functional components and not 347 directly by the application (e.g. membership knowledge is usually 348 required to implement ACK-based reliability). 350 The following list covers various transport functional components and 351 splits them in sub-components. 353 o Data Reliability (ensuring good throughput) | 354 | - Loss Detection/Notification 355 | - Loss Recovery 356 | - Loss Protection 358 o Congestion Control | 359 | - Congestion Feedback 361 Draft RMT Building Blocks 10 March 2000 363 | - Rate Regulation 364 | - Receiver Controls 366 o Security 368 o Group membership | 369 | - Membership Notification 370 | - Membership Management 372 o Session Management | 373 | - Group Membership Tracking 374 | - Session Advertisement 375 | - Session Start/Stop 376 | - Session Configuration/Monitoring 378 o Tree Configuration 380 Note that not all components are required by all protocols, depending 381 upon the fully defined service that is being provided by the protocol. 382 In particular, some minimal service models do not require many of these 383 functions, including loss notification, loss recovery, and group 384 membership. 386 3.1. Sub-Components Definition 388 Loss Detection/Notification. This includes how missing packets are 389 detected during transmission and how knowledge of these events are 390 propagated to one or more agents which are designated to recover from 391 the transmission error. This task raises major scalability issues and 392 can lead to feedback implosion and poor throughput if not properly 393 handled. Mechanisms based on TRACKs (tree-based positive 394 acknowledgements) or NACKs (negative acknowledgements) are the most 395 widely used to perform this function. Mechanisms based on a combination 396 of TRACKs and NACKs are also possible. 398 Loss Recovery. This function responds to loss notification events 399 through the transmission of additional packets, either in the form of 400 copies of those packets lost or in the form of FEC packets. The manner 401 in which this function is implemented can significantly affect the 402 scalability of a protocol. 404 Loss Protection. This function attempts to mask packet-losses so that 405 they don't become Loss Notification events. This function can be 406 realized through the pro-active transmission of FEC packets. Each FEC 407 Draft RMT Building Blocks 10 March 2000 409 packet is created from an entire application data unit [LMSSS97] or a 410 portion of an application data unit [RV97], [BKKKLZ95], a fact that 411 allows a receiver to recover from some packet loss without further 412 retransmissions. The number of losses that can be recovered from without 413 requiring retransmission depends on the amount of FEC packets sent in 414 the first place. Loss protection can also be pushed to the extreme when 415 good throughput is achieved without any Loss Detection/Notification and 416 Loss Recovery functionality, as in the open loop family of protocols 417 defined above. 419 Congestion Feedback. For sender driven congestion control protocols, 420 the receiver must provide some type of feedback on congestion to the 421 sender. This typically involves loss rate and round trip time 422 measurements. 424 Rate Regulation. Given the congestion feedback, the sender then must 425 adjust its rate in a way that is fair to the network. One proposal that 426 defines this notion of fairness and other congestion control 427 requirements is [Whetten99]. 429 Receiver Controls. In order to avoid allowing a receiver that has an 430 extremely slow connection to the sender to stop all progress within 431 single rate schemes, a congestion control algorithm will often reuire 432 receivers to leave groups. For multiple rate approaches, receivers of 433 all connection speeds can have data delivered to them according to the 434 rate of their connection without slowing down other receivers. 436 Security. Security for reliable multicast contains a number of complex 437 and tricky issues that stem in large part from the IP multicast service 438 model. In this service model, hosts do not send traffic to another 439 host, but instead elect to receive traffic from a multicast group. This 440 means that any host may join a group and receive its traffic. 441 Conversely, hosts may also leave a group at any time. Therefore, the 442 protocol must address how it impacts the following security issues: 444 o Sender Authentication (since any host can send to a group), 446 o Data Encryption (since any host can join a group) 448 o Transport Protection (denial of service attacks, through corruption 449 of transport state, or requests for unauthorized resources) 451 Draft RMT Building Blocks 10 March 2000 453 o Group Key Management (since hosts may join and leave a group at any 454 time) [WHA98] 456 In particular, a transport protocol needs to pay particular attention to 457 how it protects itself from denial of service attacks, through 458 mechanisms such as lightweight authentication of control packets. [HW99] 460 Sender Authentication, Data Encryption, and Group Key Management. While 461 these functions are not typically part of the transport layer per se, a 462 protocol needs to understand what ramifications it has on data security, 463 and may need to have special interfaces to the security layer in order 464 to accommodate these ramifications. 466 Transport Protection. The primary security task for a transport layer 467 is that of protecting the transport layer itself from attack. The most 468 important function for this is typically lightweight authentication of 469 control packets in order to prevent corruption of state and other denial 470 of service attacks. 472 Membership Notification. This is the function through which the data 473 source--or upper level agent in a possible hierarchical organization-- 474 learns about the identity and/or number of receivers or lower level 475 agents. To be scaleable, this typically will not provide total 476 knowledge of the identity of each receiver. 478 Membership Management. This implements the mechanisms for members to 479 join and leave the group, to accept/refuse new members, or to terminate 480 the membership of existing members. 482 Group Membership Tracking. As an optional feature, a protocol may 483 interface with a component which tracks the identity of each receiver in 484 a large group. If so, this feature will typically be implemented out of 485 band, and may be implemented by an upper level protocol. This may be 486 useful for services that require tracking of usage of the system, 487 billing, and usage reports. 489 Session Advertisement. This publishes the session name/contents and the 490 parameters needed for its reception. This function is usually performed 491 by an upper layer protocol (e.g. [HPW99] and [HJ98]). 493 Session Start/Stop. These functions determine the start/stop time of 494 sender and/or receivers. In many cases this is implicit or performed by 495 an upper level application or protocol. In some protocols, however, this 496 is a task best performed by the transport layer due to scalability 497 requirements. 499 Draft RMT Building Blocks 10 March 2000 501 Session Configuration/Monitoring. Due to the potentially far reaching 502 scope of a multicast session, it is particularly important for a 503 protocol to include tools for configuring and monitoring the protocol's 504 operation. 506 Tree Configuration. For protocols which include hierarchical elements 507 (such as PGM and RMTP-II), it is important to configure these elements 508 in a way that has approximate congruence with the multicast routing 509 topology. While tree configuration could be included as part of the 510 session configuration tools, it is clearly better if this configuration 511 can be made automatic. 513 4. Building Block Recommendations 515 The families of protocols introduced in section 1.1 generally use 516 different mechanisms to implement the protocol functional components 517 described in section 3. This section tries to group these mechanisms in 518 macro components that define protocol building blocks. 520 A building block is defined as 521 "a logical protocol component that results in explicit APIs for use 522 by other building blocks or by the protocol client." 524 Building blocks are generally specified in terms of the set of 525 algorithms and packet formats that implement protocol functional 526 components. A building block may also have API's through which it 527 communicates to applications and/or other building blocks. Most 528 building blocks should also have a management API, through which it 529 communicates to SNMP and/or other management protocols. 531 In the following section we will list a number of building blocks which, 532 at this stage, seem to cover most of the functional components needed to 533 implement the protocol families presented in section 1.1. Nevertheless 534 this list represents the "best current guess", and as such it is not 535 meant to be exhaustive. The actual building block decomposition, i.e. 536 the division of functional components into building blocks, may also 537 have to be revised in the future. 539 4.1. NACK-based Reliability 541 This building block defines NACK-based loss detection/notification and 542 recovery. The major issues it addresses are implosion prevention 543 (suppression) and NACK semantics (i.e. how packets to be retransmitted 544 should be specified, both in the case of selective and FEC loss repair). 546 Draft RMT Building Blocks 10 March 2000 548 Suppression mechanisms to be considered are: 550 o Multicast NACKs 551 o Unicast NACKs and Multicast confirmation 553 These suppression mechanisms primarily need to both minimize delay while 554 also minimizing redundant messages. They may also need to have special 555 weighting to work with Congestion Feedback. 557 4.2. FEC Repair 559 This building block is concerned with packet level FEC repair. It 560 specifies the FEC codec selection and the FEC packet naming (indexing) 561 for both on-demand FEC and pro-active FEC. 563 4.3. Congestion Control 565 There will likely be multiple versions of this building block, 566 corresponding to different design policies in addressing congestion 567 control. Two main approaches are considered for the time being: a 568 source-based rate regulation with a single rate provided to all the 569 receivers in the session, and a multiple rate receiver-driven approach 570 with different receivers receiving at different rates in the same 571 session. The multiple rate approach may use multiple layers of 572 multicast traffic [VRC98] or router filtering of a single layer [LVS99]. 574 Both approaches are still in the phase of study, however the first seems 575 to be mature enough [HFW99] to allow the standardization process to 576 begin. 578 At the time of writing this document, a third class of congestion 579 control algorithm based on router support is beginning to emerge in the 580 IRTF RMRG [LVS99]. This work may lead to the future standardization of 581 one or more additional building blocks for congestion control. 583 4.4. Generic Router Support 585 The task of designing RM protocols can be made much easier by the 586 presence of some specific support in routers. In some application- 587 specific cases, the increased benefits afforded by the addition of 588 special router support can justify the resulting additional complexity 589 Draft RMT Building Blocks 10 March 2000 591 and expense [FLST98]. 593 Functional components which can take advantage of router support include 594 feedback aggregation/suppression (both for loss notification and 595 congestion control) and constrained retransmission of repair packets. 596 Another component that can take advantage of router support is 597 intentional packet filtering to provide different rates of delivery of 598 packets to different receivers from the same multicast packet stream. 599 This could be most advantageous when combined with open-loop delivery 600 protocols [LVS99]. 602 The process of designing and deploying these mechanisms inside routers 603 can be much slower than the one required for end-host protocol 604 mechanisms. Therefore, it would be highly advantageous to define these 605 mechanisms in a generic way that multiple protocols can use if it is 606 available, but do not necessarily need to depend on. 608 This component has two halves, a signaling protocol and actual router 609 algorithms. The signaling protocol allows the transport protocol to 610 request from the router the functions that it wishes to perform, and the 611 router algorithms actually perform these functions. It is more urgent 612 to define the signaling protocol, since it will likely impact the common 613 case protocol headers. 615 An important component of the signaling protocol is some level of 616 commonality between the packet headers of multiple protocols, which 617 allows the router to recognize and interpret the headers. 619 4.5. Tree Configuration 621 It has been shown that the scalability of RM protocols can be greatly 622 enhanced by the insertion of some kind of retransmission or feedback 623 aggregation agents between the source and receivers. These agents are 624 then used to form a tree with the source at (or near) the root, the 625 receivers at the leaves of the tree, and the aggregation/local repair 626 nodes in the middle. The internal nodes can either be dedicated 627 software for this task, or they may be receivers that are performing 628 dual duty. 630 The effectiveness of these agents to assist in the delivery of data is 631 highly dependent upon how well the logical tree they use to communicate 632 matches the underlying routing topology. The purpose of this building 633 block would be to construct and manage the logical tree connecting the 634 agents. Ideally, this building block would perform these functions in a 635 Draft RMT Building Blocks 10 March 2000 637 manner that adapts to changes in session membership, routing topology, 638 and network availability. 640 4.6. Security 642 At the time of writing, the security issues are the subject of research 643 within the IRTF Secure Multicast Group (SMuG). Solutions for these 644 requirements will be standardized within the IETF when ready. 646 4.7. Common Headers 648 As pointed out in the generic router support section, it is important to 649 have some level of commonality across packet headers. It may also be 650 useful to have common data header formats for other reasons. This 651 building block would consist of recommendations on fields in their 652 packet headers that protocols should make common across themselves. 654 4.8. Protocol Cores 656 The above building blocks consist of the functional components listed in 657 section 3 that appear to meet the requirements for being implemented as 658 building blocks presented in section 2. 660 The other functions from section 3, which are not covered above, should 661 be implemented as part of "protocol cores", specific to each protocol 662 standardized. 664 5. Conclusions 666 In this document, we briefly described a number of building blocks that 667 may be used for the generation of reliable multicast protocols to be 668 used in the application space of one-to-many reliable bulk-data 669 transfer. The list of building blocks presented was derived from 670 considering the functions that a protocol in this space must perform and 671 how these functions should be grouped. This list is not intended to be 672 all-inclusive but instead to act as guide as to which building blocks 673 are considered during the standardization process within the Reliable 674 Multicast Transport WG. 676 Draft RMT Building Blocks 10 March 2000 678 6. Acknowledgements 680 This document represents an overview of a number of building blocks for 681 one to many bulk data transfer that may be ready for standardization 682 within the RMT working group. The ideas presented are not those of the 683 authors, rather they are a summarization of many years of research into 684 multicast transport combined with the varied presentations and 685 discussions in the IRTF Reliable Multicast Research Group. Although 686 they are too numerous to list here, we thank everyone who has 687 participated in these discussions for their contributions. 689 7. References 691 [BKKKLZ95] 692 J. Bloemer, M. Kalfane, M. Karpinski, R. Karp, M. Luby, D. 693 Zuckerman, ``An XOR-based Erasure Resilient Coding Scheme, ICSI 694 Technical Report No. TR-95-048, August 1995. 696 [BLMR98] 697 J. Byers, M. Luby, M. Mitzenmacher, A. Rege, ``A Digital Fountain 698 Approach to Reliable Distribution of Bulk Data, Proc ACM SIGCOMM 699 98. 701 [FJM95] 702 S. Floyd, V. Jacobson, S. McCanne, "A Reliable Multicast Framework 703 for Light-weight Sessions and Application Level Framing," Proc ACM 704 SIGCOMM 95, Aug 1995 pp. 342-356. 706 [FLST98] 707 D. Farinacci, S. Lin, T. Speakman, and A. Tweedly, "PGM reliable 708 transport protocol specification," Internet Draft, Internet 709 Engineering Task Force, Aug. 1998. Work in progress. 711 [HFW99] 712 M. Handley, S. Floyd, B. Whetten, "Strawman Specification for TCP 713 Friendly (Reliable) Multicast Congestion Control (TFMCC)," work in 714 progress. 716 [HJ98] 717 M. Handley, V. Jacobson, "SDP: Session Description Protocol," 718 RFC2327, April 1998. 720 [HPW99] 721 M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol," 722 Internet Draft, work in progress, June 1999. 724 Draft RMT Building Blocks 10 March 2000 726 [HW99] 727 T. Hardjorno, B. Whetten, "Security Requirements for RMTP-II," 728 Internet Draft, work in progress, June 1999. 730 [HWKFV99] 731 M. Handley, B.Whetten, R. Kermode, S.Floyd, and L. Vicisano, "The 732 Reliable Multicast Design Space for Bulk Data Transfer," Internet 733 Draft, Internet Engineering Task Force, June 1999. 735 [KCW98] 736 M. Kadansky, D. Chiu, and J. Wesley, `"Tree-based reliable 737 multicast (TRAM),'" Internet Draft, Internet Engineering Task 738 Force, Nov. 1998. Work in progress. 740 [Kermode98] 741 R. Kermode, "Scoped Hybrid Automatic Repeat Request with Forward 742 Error Correction," Proc ACM SIGCOMM 98, Sept 1998. 744 [LDW98] 745 M. Lucas, B. Dempsey, A. Weaver, "MESH: Distributed Error Recovery 746 for Multimedia Streams in Wide-Area Multicast Networks" 748 [LESZ97] 749 C-G. Liu, D. Estrin, S. Shenkar, L. Zhang, "Local Error Recovery in 750 SRM: Comparison of Two Approaches," USC Technical Report 97- 648, 751 Jan 1997. 753 [LG97] 754 B.N. Levine, J.J. Garcua-Luna-Aceves, "Improving Internet Multicast 755 Routing with Routing Labels," IEEE International Conference on 756 Network Protocols (ICNP-97), Oct 28-31, 1997, p.241-250. 758 [LP96] 759 K. Lin and S. Paul. "RMTP: A Reliable Multicast Transport 760 Protocol," IEEE INFOCOMM 1996, March 1996, pp. 1414-1424. 762 [LMSSS97] 763 M. Luby, M. Mitzenmacher, A. Shokrollahi, D. Spielman, V. Stemann, 764 ``Practical Loss-Resilient Codes, Proc ACM Symposium on Theory of 765 Computing, 1997. 767 [LVS99] 768 M. Luby, L. Vicisano, T. Speakman. ``Heterogeneous multicast 769 congestion control based on router packet filtering, RMT working 770 group, June 1999, Pisa, Italy. 772 Draft RMT Building Blocks 10 March 2000 774 [MA99] 775 J. Macker, B. Adamson. "Multicast Dissemination Protocol version 2 776 (MDPv2)," work in progress, http://manimac.itd.nrl.navy.mil/MDP. 778 [MRBP98] 779 A. Mankin, A. Romanow, S.Brander, V.Paxson, "IETF Criteria for 780 Evaluating Reliable Multicast Transport and Application Protocols," 781 RFC2357, June 1998. 783 [OXB99] 784 O. Ozkasap, Z. Xiao, K. Birman. "Scalability of Two Reliable 785 Multicast Protocols," Work in progress, May 1999. 787 [PSLB97] 788 "Reliable Multicast Transport Protocol (RMTP)," S. Paul, K. K. 789 Sabnani, J. C. Lin, and S. Bhattacharyya, IEEE Journal on Selected 790 Areas in Communications, Vol. 15, No. 3, April 1997. 792 [RV97] 793 L. Rizzo, L. Vicisano, "A Reliable Multicast Data Distribution 794 Protocol Based on Software FEC Techniques," Proc. of The Fourth 795 IEEE Workshop on the Architecture and Implementation of High 796 Performance Communication Systems (HPCS'97), Sani Beach, 797 Chalkidiki, Greece June 23-25, 1997. 799 [VRC98] 800 L. Vicisano, L. Rizzo, J. Crowcroft, "TCP-Like Congestion Control 801 for Layered Multicast Data Transfer", Proc. of IEEE Infocom'98, 802 March 1998. 804 [WBPM98] 805 B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, N. Rastogi, J. 806 Conlan, and T. Yeh, "THE RMTP-II PROTOCOL," Internet Draft, 807 Internet Engineering Task Force, Apr. 1998. Work in progress 809 [WHA98] 810 D. Wallner, E. Hardler, R. Agee, `"Key Management for Multicast: 811 Issues and Architectures," Internet Draft, work in progress, Sept 812 1998. 814 [Whetten99] 815 B. Whetten, "A Proposal for Reliable Multicast Congestion Control 816 Requirements," work in progress. http://www.talarian.com/rmtp- 817 ii/overview.htm 819 Draft RMT Building Blocks 10 March 2000 821 8. Authors' Addresses 823 Brian Whetten 824 Talarian Corporation, 825 333 Distel Circle, 826 Los Altos, CA 94022, USA 827 whetten@talarian.com 829 Lorenzo Vicisano 830 Cisco Systems, 831 170 West Tasman Dr. 832 San Jose, CA 95134, USA 833 lorenzo@cisco.com 835 Roger Kermode 836 Motorola Australian Research Centre 837 Level 3, 12 Lord St, 838 Botany NSW 2019, 839 Australia. 840 Roger.Kermode@motorola.com 842 Mark Handley, Sally Floyd 843 ATT Center for Internet Research at ICSI, 844 International Computer Science Institute, 845 1947 Center Street, Suite 600, 846 Berkeley, CA 94704, USA 847 mjh@aciri.org, floyd@aciri.org 849 Michael Luby 850 Digital Fountain, Inc. and ICSI 851 luby@dfountain.com, luby@icsi.berkeley.edu 853 9. Full Copyright Statement 855 Copyright (C) The Internet Society (1998). All Rights Reserved. 857 This document and translations of it may be copied and furnished to 858 others, and derivative works that comment on or otherwise explain it or 859 assist in its implementation may be prepared, copied, published and 860 distributed, in whole or in part, without restriction of any kind, 861 provided that the above copyright notice and this paragraph are included 862 on all such copies and derivative works. However, this document itself 863 may not be modified in any way, such as by removing the copyright notice 864 or references to the Internet Society or other Internet organizations, 865 Draft RMT Building Blocks 10 March 2000 867 except as needed for the purpose of developing Internet standards in 868 which case the procedures for copyrights defined in the Internet 869 languages other than English. 871 The limited permissions granted above are perpetual and will not be 872 revoked by the Internet Society or its successors or assigns. 874 This document and the information contained herein is provided on an "AS 875 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 876 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 877 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 878 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 879 FITNESS FOR A PARTICULAR PURPOSE." 881 Table of Contents 883 1 Introduction .................................................... 2 884 1.1 Protocol Families ............................................. 4 885 2 Building Blocks Rationale ....................................... 5 886 2.1 Building Blocks Advantages .................................... 6 887 2.2 Building Block Risks .......................................... 7 888 2.3 Building Block Requirements ................................... 7 889 3 Protocol Components ............................................. 8 890 3.1 Sub-Components Definition ..................................... 9 891 4 Building Block Recommendations .................................. 12 892 4.1 NACK-based Reliability ........................................ 12 893 4.2 FEC Repair .................................................... 13 894 4.3 Congestion Control ............................................ 13 895 4.4 Generic Router Support ........................................ 13 896 4.5 Tree Configuration ............................................ 14 897 Draft RMT Building Blocks 10 March 2000 899 4.6 Security ...................................................... 15 900 4.7 Common Headers ................................................ 15 901 4.8 Protocol Cores ................................................ 15 902 5 Conclusions ..................................................... 15 903 6 Acknowledgements ................................................ 16 904 7 References ...................................................... 16 905 8 Authors' Addresses .............................................. 19 906 9 Full Copyright Statement ........................................ 19