idnits 2.17.1 draft-ietf-rmt-buildingblocks-00.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 111 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages 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.) -- The document date (15 December 1999) is 8899 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PSLM97' is mentioned on line 154, but not defined == Unused Reference: 'PSLB97' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'RV97' is defined on line 720, but no explicit reference was found in the text -- 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. '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. 'WBPM98' -- Possible downref: Non-RFC (?) normative reference: ref. 'WHA98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Whetten99' Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 21 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-00.txt M.Handley, ACIRI 5 15 June 1999 S.Floyd, ACIRI 6 Expires 15 December 1999 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 working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 vInternet-Drafts are valid for a maximum of six months and may be 23 updated, replaced, or obsoleted by other documents at any time. It 24 is inappropriate to use Internet-Drafts as reference material or to 25 cite them other than as a "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes a framework for the standardization of bulk-data 36 reliable multicast transport. It builds upon the experience gained 37 during the deployment of several classes of contemporary reliable 38 multicast transport, and attempts to pull out the commonalties between 39 these classes of protocols into a number of building blocks. To that 40 end, this document recommends that certain components that are common to 41 multiple protocol classes be standardized as "building blocks." The 42 remaining parts of the protocols, consisting of highly protocol specific 43 tightly intertwined functions shall be designated as "protocol cores." 44 Thus, each protocol can then be constructed by merging a "protocol core" 45 with a number of "building blocks" which can be re-used across multiple 46 protocols. 48 Draft RMT Building Blocks 15 June 1999 50 Copyright Notice Copyright (C) The Internet Society (1999). All Rights 51 Reserved. 53 1. Introduction 55 RFC2357 lays out the requirements for reliable multicast protocols that 56 are to be considered for standardization by the IETF. They include: 58 o Congestion Control. The protocol must be safe to deploy in the 59 widespread Internet. Specifically, it must adhere to three mandates: 60 a) it must achieve good throughput (i.e. it must not consistently 61 overload links with excess data or repair traffic), b) it must 62 achieve good link utilization, and c) it must not starve competing 63 flows. 65 o Scalability. The protocol should be able to work under a variety of 66 conditions that include multiple network topologies, link speeds, and 67 the receiver set size. It is more important to have a good 68 understanding of how and when a protocol breaks than when it works. 70 o Security. The protocol must be analyzed to show what is necessary to 71 allow it to cope with security and privacy issues. This includes 72 understanding the role of the protocol in data confidentiality and 73 sender authentication, as well as how the protocol will provide 74 defenses against denial of service attacks. 76 These requirements are primarily directed towards making sure that any 77 standards will be safe for widespread Internet deployment. The 78 advancing maturity of current work on reliable multicast congestion 79 control (TFMCC) [HFW99] in the IRTF Reliable Multicast Research Group 80 (RMRG) has been one of the events that has allowed the IETF to charter 81 the RMT working group. RMCC only addresses a subset of the design space 82 for reliable multicast. Fortuitously, the requirements it addresses are 83 also the most pressing application and market requirements. 85 A protocol's ability to meet the requirements of congestion control, 86 scalability, and security is affected by a number of factors that are 87 described in a separate document [HWKFV99]. In summary, these are: 89 Draft RMT Building Blocks 15 June 1999 91 o Ordering Guarantees. A protocol must offer at least one of either 92 source ordered or unordered delivery guarantees. Support for total 93 ordering across multiple senders is not recommended, as it makes it 94 more difficult to scale the protocol, and can more easily be 95 implemented at a higher level. 97 o Receiver Scalability. A protocol should be able to support a "large" 98 number of simultaneous receivers per transport group. A typical 99 receiver set should be on the order of 1,000 - 10,000 simultaneous 100 receivers per group. However, this number may be larger or smaller 101 depending upon the factors that follow. 103 o Real-Time Feedback. RMCC requires soft real-time feedback, so a 104 protocol must provide some means for this information to be measured 105 and returned to the sender. While this does not require that a 106 protocol deliver data in soft real-time, it is an important 107 application requirement that can be provided easily given real-time 108 feedback. 110 o Delivery Guarantees. A protocol must provide at least statistically 111 reliable delivery (it must be able to guarantee delivery of a minimum 112 percentage of the data to a minimum percentage of the receiver set). 113 It may optionally provide message stability (TCP level delivery 114 guarantees), and/or time bounded reliability (attempt repairs for a 115 specific amount of time before giving up). 117 o Network Topologies. A protocol must not break the network when 118 deployed in the full Internet. However, we recognize that intranets 119 will be where the first wave of deployments happen, and so are also 120 very important to support. Thus, support for satellite networks 121 (including those with terrestrial return paths or no return paths at 122 all) is encouraged, but not required. 124 o Group Membership. The group membership algorithms must be scaleable. 125 Membership can be anonymous (where the sender does not know the list 126 of receivers), or fully distributed (where the sender receives a 127 count of the number of receivers, and optionally a list of failures). 129 o Example Applications. Some of the applications that a RM protocol 130 could be designed to support include multimedia broadcasts, real time 131 financial market data distribution, multicast file transfer, and 132 server replication. 134 Draft RMT Building Blocks 15 June 1999 136 1.1. Protocol Families 138 The design-space document [HWKFV99] also provides a taxonomy of the most 139 popular approaches that have been proposed over the last ten years. 140 After congestion control, the primary challenge has been that of meeting 141 the requirement for receiver scalability. For protocols that include a 142 back-channel for recovery of lost packets, the ability to take advantage 143 of support of elements in the network has been found to be very 144 beneficial for supporting large numbers of receivers. ,lp This taxonomy 145 breaks proposed protocols in to four families. 147 1 No network assist. Protocols such as SRM [FJM95] and MDP2 [MA99] 148 attempt to limit traffic by only using NACKs for requesting packet 149 retransmission. These protocols provide statistical reliability, but 150 do not provide known message stability. They do not require network 151 infrastructure, but this introduces some questions about how well the 152 protocols will scale [LESZ97, Kermode98, LDW98, OXB99]. 154 2 Server assist. Protocols such as RMTP [LP96, PSLM97], RMTP-II 155 [WBPM98] and TRAM [KCW98], use positive acknowledgements (ACKs) to 156 achieve stronger delivery guarantees. These ACKs also make it easier 157 to implement RMCC. However, in order to avoid ACK implosion in 158 scaled up deployments, the protocol requires that servers be placed 159 in the network. 161 3 Router assist. Like SRM, protocols such as PGM [FLST98] and [LG97] 162 also use negative acknowledgements for packet recovery, and therefore 163 do not provide message stability. These protocols take advantage of 164 new router software to do constrained negative acknowledgements and 165 retransmissions. 167 4 Open-Loop delivery. For some applications, lower reliability 168 guarantees can be accepted. Thus, one can deploy a protocol built 169 using sender-based Forward Error Correction (FEC) methods with no 170 feedback from the receivers or the network. Such protocols are 171 particularly well suited for highly-asymmetric networks (e.g. 172 satellite). 174 2. Building Blocks Rationale 176 As specified in RFC2357 [MRBP98], no single reliable multicast protocol 177 can meet the needs of all applications. Therefore, the IETF expects to 178 standardize a number of protocols that are tailored to application and 179 network specific needs. This document concentrates on the requirements 180 for "one-to-many bulk-data transfer", but in the future, additional 182 Draft RMT Building Blocks 15 June 1999 184 protocols and building-blocks are expected that will address the needs 185 of other types of applications, including "many-to-many" applications. 186 Note that bulk-data transfer does not refer to the timeliness of the 187 data, rather it states that there is a large amount of data transferred 188 in a session. The scope and approach taken for the development of 189 protocols for these additional scenarios will depend upon large part on 190 the success of the "building-block" approach put forward in this 191 document. 193 2.1. Building Blocks Advantages 195 Building a large piece of software out of smaller modular components is 196 a well understood technique of software engineering. Some of the 197 advantages that can come from this include: 199 o Software Reuse. Modules can be used in multiple protocols, which 200 reduces the amount of development time required. 202 o Reduced Complexity. To the extent that each module can be easily 203 defined with a simple API, breaking a large protocol in to smaller 204 pieces typically reduces the total complexity of the system. 206 o Reduced Verification and Debugging Time. Reduced complexity results 207 in reduced time to debug the modules. It is also usually faster to 208 verify a set of smaller modules than a single larger module. 210 o Easier Future Upgrades. There is still ongoing research in reliable 211 multicast, and we expect the state of the art to continue to evolve. 212 Building protocols with smaller modules allows them to be more easily 213 upgraded to reflect future research. 215 o Common Diagnostics. To the extent that multiple protocols share 216 common packet headers, packet analyzers and other diagnostic tools 217 can be built which work with multiple protocols. 219 o Reduces Effort for New Protocols. As new application requirements 220 drive the need for new standards, some existing modules may be reused 221 in these protocols. 223 o Parallelism of Development. If the APIs are defined clearly, the 224 development of each module can proceed in parallel. 226 Draft RMT Building Blocks 15 June 1999 228 2.2. Building Block Risks 230 Like most software engineering, this technique of breaking down a 231 protocol in to smaller components also brings tradeoffs. After a 232 certain point, the disadvantages outweigh the advantages, and it is not 233 worthwhile to further subdivide a problem. These risks include: 235 o Delaying Development. Defining the API for how each two modules 236 inter-operate takes time and effort. As the number of modules 237 increases, the number of APIs can increase at more than a linear 238 rate. The more tightly coupled and complex a component is, the more 239 difficult it is to define a simple API, and the less opportunity 240 there is for reuse. In particular, the problem of how to build and 241 standardize fine grained building blocks for a transport protocol is 242 a difficult one, and in some cases requires fundamental research. 244 o Increased Complexity. If there are too many modules, the total 245 complexity of the system actually increases, due to the preponderance 246 of interfaces between modules. 248 o Reduced Performance. Each extra API adds some level of processing 249 overhead. If an API is inserted in to the "common case" of packet 250 processing, this risks degrading total protocol performance. 252 o Abandoning Prior Work. The development of robust transport protocols 253 is a long and time intensive process, which is heavily dependent on 254 feedback from real deployments. A great deal of work has been done 255 over the past five years on components of protocols such as RMTP-II, 256 SRM, and PGM. Attempting to dramatically re-engineer these 257 components risks losing the benefit of this prior work. 259 2.3. Building Block Requirements 261 Given these tradeoffs, we propose that a building block must meet the 262 following requirements: 264 o Wide Applicability. In order to have confidence that the component 265 can be reused, it must be clear that the component can apply across 266 the majority of the protocol classes. We note that the fourth class 267 (with no back-channel) is fundamentally different than the first 268 three, and so may be less amenable to building blocks. 270 Draft RMT Building Blocks 15 June 1999 272 o Simplicity. In order to have confidence that the specification of 273 the component APIs will not dramatically slow down the standards 274 process, APIs must be simple and straight forward to define. No new 275 fundamental research should be done in defining these APIs. 277 o Performance. To the extent possible, the building blocks should 278 attempt to avoid breaking up the "fast track", or common case packet 279 processing. 281 3. Protocol Components 283 This section proposes a functional decomposition of RM bulk-data 284 protocols from the perspective of the functional components provided to 285 an application by a transport protocol. It also covers some components 286 that while not necessarily part of the transport protocol, are directly 287 impacted by the specific requirements of a reliable multicast transport. 288 The next section then specifies recommended building blocks that can 289 implement these components. 291 Although this list tries to cover all the most common transport-related 292 needs of one-to-many bulk-data transfer applications, new application 293 requirements may arise during the process of standardization, hence this 294 list must not be interpreted as a statement of what the transport layer 295 should provide and what it should not. Nevertheless, it must be pointed 296 out that some functional components have been deliberately omitted since 297 they have been deemed irrelevant to the type of application considered 298 (i.e. one-to-many bulk-data transfer). Among these are advanced message 299 ordering (i.e. those which cannot be implemented through a simple 300 sequence number) and atomic delivery. 302 It is also worth mentioning that some of the functional components 303 listed below may be required by other functional components and not 304 directly by the application (e.g. membership knowledge is usually 305 required to implement ACK-based reliability). 307 The following list covers various transport functional components and 308 splits them in sub-components. 310 o Data Reliability | 311 | - Loss Detection/Notification 312 | - Loss Recovery 313 | - Loss Protection 315 Draft RMT Building Blocks 15 June 1999 317 o Congestion Control | 318 | - Congestion Feedback 319 | - Rate Regulation 320 | - Receiver Controls 322 o Security 324 o Group membership | 325 | - Membership Notification 326 | - Membership Management 328 o Session Management | 329 | - Group Membership Tracking 330 | - Session Advertisement 331 | - Session Start/Stop 332 | - Session Configuration/Monitoring 334 o Tree Configuration 336 Note that not all components are required by all protocols. In 337 particular, the fourth class of protocols defined above does not require 338 many of these functions, including loss notification, loss recovery, and 339 group membership. 341 3.1. Sub-Components Definition 343 Loss Detection/Notification. This includes how missing packets are 344 detected during transmission and how knowledge of these events are 345 propagated to one or more agents which are designated to recover from 346 the transmission error. This task raises major scalability issues and 347 can led to feedback implosion if not properly handled. Mechanisms based 348 on HACKs (hierarchical positive acknowledgements) or NAKs (negative 349 acknowledgements) are the most widely used to perform this function. 350 Mechanisms based on a combination of HACKs and NAKs are also possible. 352 Loss Recovery. This function responds to loss notification events 353 through the transmission of additional packets, either in the form of 354 copies of those packets lost or in the form of FEC parity packets. The 355 manner in which this function is implemented can significantly affect 356 the scalability of a protocol. 358 Loss Protection. This function attempts to eliminate packet-losses so 359 that they don't become Loss Notification events. This function can be 360 realized through the pro-active transmission of additional FEC packets. 362 Draft RMT Building Blocks 15 June 1999 364 Each additional FEC packet is redundantly constructed from multiple data 365 packets, a fact that allows a receiver to recover from some packet loss 366 without further retransmissions. The number of losses that can be 367 recovered from without requiring retransmission depends on the amount of 368 FEC provided in the first place. Loss protection can also be pushed to 369 the extreme when reliability is achieved without any Loss 370 Detection/Notification and Loss Recovery functionality, as in the fourth 371 class of open loop protocols defined above. 373 Congestion Feedback. For sender driven congestion control protocols, 374 the receiver must provide some type of feedback on congestion to the 375 sender. This typically involves loss rate and round trip time 376 measurements. 378 Rate Regulation. Given the congestion feedback, the sender then must 379 adjust its rate in a way that is fair to the network. One proposal that 380 defines this notion of fairness and other congestion control 381 requirements is [Whetten99]. 383 Receiver Controls. In order to avoid allowing an extremely slow 384 receiver to stop all progress, a congestion control algorithm will often 385 involve having receivers leave groups in this case. For multi-layered 386 schemes, the receivers may choose which layers of data they subscribe 387 to. 389 Security. Security for reliable Multicast contains a number of complex 390 and tricky issues that stem in large part from the IP multicast service 391 model. In this service model, hosts do not send traffic to another 392 host, but instead elect to receive traffic from a multicast group. This 393 means that any host may join a group and receive its traffic. 394 Conversely, hosts may also leave a group at any time. Therefore, the 395 protocol must address how it impacts the following security issues: 397 o sender authentication (since any host can send to a group), 399 o data encryption (since any host can join a group) 401 o denial of service attacks (through corruption of transport state, or 402 requests for unauthorized resources) 404 o group key management (since hosts may join and leave a group at any 405 time) [WHA98] 407 Draft RMT Building Blocks 15 June 1999 409 In particular, a transport protocol needs to pay particular attention to 410 how it protects itself from denial of service attacks, through 411 mechanisms such as lightweight authentication of control packets. [HW99] 413 Data Authentication and Encryption. While data authentication and 414 encryption is not typically part of the transport layer per se, a 415 protocol needs to understand what ramifications it has on data security, 416 and may need to have special interfaces to the security layer in order 417 to accommodate these ramifications. 419 Transport Protection. The primary security task for a transport layer 420 is that of protecting the transport layer itself from attack. The most 421 important function for this is typically lightweight authentication of 422 control packets in order to prevent corruption of state and other denial 423 of service attacks. 425 Membership Notification. This is the function through which the data 426 source--or upper level agent in a possible hierarchical organization-- 427 learns about the identity and/or number of receivers or lower level 428 agents. To be scaleable, this typically will not provide total 429 knowledge of the identity of each receiver. 431 Membership Management. This implements the mechanisms for members to 432 join and leave the group, to accept/refuse new members, or to terminate 433 the membership of existing members. 435 Group Membership Tracking. As an optional feature, a protocol may 436 interface with a component which tracks the identity of each receiver in 437 a large group. If so, this feature will typically be implemented out of 438 band, and may be implemented by an upper level protocol. 440 Session Advertisement. This publishes the session name/contents and the 441 parameters needed for its reception. This function is usually performed 442 by an upper layer protocol (e.g. [HPW99] and [HJ98]). 444 Session Start/Stop. These functions determine the start/stop time of 445 sender and/or receivers. In many cases this is implicit or performed by 446 an upper level application or protocol. In some protocols, however, this 447 is a task best performed by the transport layer due to scalability 448 requirements. As an example, in the case of the "data fountain" 449 approach, where receivers can complete their reception by tuning in 450 asynchronously and leaving the group when done, the source must be 451 notified when it can stop transmitting because there are no receivers 452 tuned. 454 Draft RMT Building Blocks 15 June 1999 456 Session Configuration/Monitoring. Due to the potentially far reaching 457 scope of a multicast session, it is particularly important for a 458 protocol to include tools for configuring and monitoring the protocols 459 operation. 461 Tree Configuration. For protocols which include hierarchical elements 462 (such as PGM and RMTP-II), it is important to configure these elements 463 in a way that has approximate congruence with the multicast routing 464 topology. While tree configuration could be included as part of the 465 session configuration tools, it is clearly better if this configuration 466 can be made automatic. 468 4. Building Block Recommendations 470 The families of protocols introduced in section 1.1 generally use 471 different mechanisms to implement the protocol functional components 472 described in section 3. This section tries to group these mechanisms in 473 macro components that define protocol building blocks. 475 A building block is defined as 476 "a logical protocol component that results in explicit APIs for use 477 by other building blocks or by the protocol client." 479 Building blocks are generally specified in terms of the set of 480 algorithms and packet formats that implement protocol functional 481 components. A building block may also have API's through which it 482 communicates to applications and/or other building blocks. Most 483 building blocks should also have a management API, through which it 484 communicates to SNMP and/or other management protocols. 486 In the following section we will list a number of building blocks which, 487 at this stage, seem to cover most of the functional components needed to 488 implement the protocol families presented in section 1.1. Nevertheless 489 this list represent the "best current guess", and as such it is not 490 meant to be exhaustive. The actual building block decomposition, i.e. 491 the division of functional components into building blocks, may also 492 have to be revised in the future. 494 4.1. NAK-based Reliability 496 This building block defines NAK-based loss detection/notification and 497 recovery. The major issues it addresses are implosion prevention 498 (suppression) and NAK semantics (i.e. how packets to be retransmitted 499 should be specified, both in the case of selective and FEC loss repair). 501 Draft RMT Building Blocks 15 June 1999 503 Suppression mechanisms to be considered are: 505 o Multicast NAKs 506 o Unicast NAKs and Multicast confirmation 508 These suppression mechanisms primarily need to both minimize delay while 509 also minimizing redundant messages. They may also need to have special 510 weighting to work with Congestion Feedback. 512 4.2. FEC Repair 514 This building block is concerned with packet level FEC repair. It 515 specifies the FEC codec selection and the FEC packet naming (indexing) 516 for both on-demand FEC and pro-active FEC. 518 4.3. Congestion Control 520 There will likely be multiple versions of this building block, 521 corresponding to different design policies in addressing congestion 522 control. Two main approaches are considered for the time being: a 523 source-based rate regulation with a single rate provided to all the 524 receivers in the session, and a multiple rate receiver-driven approach 525 based on layered transmission. 527 Both approaches are still in the phase of study, however the first seems 528 to be mature enough [HFW99] to allow the standardization process to 529 begin. 531 At the time of writing this document, a third class of congestion 532 control algorithm based on router support is beginning to emerge in the 533 IRTF RMRG. This work may lead to the future standardization of one or 534 more additional building blocks for congestion control. 536 4.4. Generic Router Support 538 The task of designing RM protocols can be made much easier by the 539 presence of some specific support in routers. In some application- 540 specific cases, the increased benefits afforded by the addition of 541 special router support can justify the resulting additional complexity 542 and expense [FLST98]. 544 Draft RMT Building Blocks 15 June 1999 546 Functional components which can take advantage of router support include 547 feedback aggregation/suppression (both for loss notification and 548 congestion control) and constrained retransmission of repair packets. 550 The process of designing and deploying these mechanisms inside router 551 can be much slower than the one required for end-host protocol 552 mechanisms. Therefore, it would be highly advantageous to define these 553 mechanisms in a generic way that multiple protocols can use if it is 554 available, but do not necessarily need to depend on. 556 This component has two halves, a signaling protocol and actual router 557 algorithms. The signaling protocol allows the transport protocol to 558 request from the router the functions that it wishes to perform, and the 559 router algorithms actually perform these functions. It is more urgent 560 to define the signaling protocol, since it will likely impact the common 561 case protocol headers. 563 An important component of the signaling protocol is some level of 564 commonality between the packet headers of multiple protocols, which 565 allows the router to recognize and interpret the headers. 567 4.5. Tree Configuration 569 It has been shown that the scalability of RM protocols can be greatly 570 enhanced by the insertion of some kind of retransmission or feedback 571 aggregation agents between the source and receivers. These agents are 572 then used to form a tree with the source at (or near) the root, the 573 receivers at the leaves of the tree, and the aggregation/local repair 574 nodes in the middle. The internal nodes can either be dedicated 575 software for this task, or they may be receivers that are performing 576 dual duty. 578 The effectiveness of these agents to assist in the delivery of data is 579 highly dependent upon on how well the logical tree they use to 580 communicate matches the underlying routing topology. The purpose of 581 this building block would be to construct and manage the logical tree 582 connecting the agents. Ideally, this building block would perform these 583 functions in a manner that adapts to changes in session membership, 584 routing topology, and network availability. 586 Draft RMT Building Blocks 15 June 1999 588 4.6. Security 590 At the time of writing, the security issues are the subject of research 591 within the IRTF Secure Multicast Group (SMuG). Solutions for these 592 requirements will be standardized within the IETF when ready. 594 4.7. Common Headers 596 As pointed out in the generic router support section, it is important to 597 have some level of commonality across packet headers. It may also be 598 useful to have common data header formats for other reasons. This 599 building block would consist of recommendations on fields in their 600 packet headers that protocols should make common across themselves. 602 4.8. Protocol Cores 604 The above building blocks consist of the functional components listed in 605 section 3 that appear to meet the requirements for being implemented as 606 building blocks presented in section 2. 608 The other functions from section 3, which are not covered above, should 609 be implemented as part of "protocol cores", specific to each protocol 610 standardized. 612 5. Conclusions 614 In this document, we briefly described a number of building blocks that 615 may be used for the generation of reliable multicast protocols to be 616 used in the application space of one-to-many reliable bulk-data 617 transfer. The list of building blocks presented was derived from 618 considering the functions that a protocol in this space must perform and 619 how these functions should be grouped. This list is not intended to be 620 all-inclusive but instead to act as guide as to which building blocks 621 are considered during the standardization process within the Reliable 622 Multicast Transport WG. 624 Draft RMT Building Blocks 15 June 1999 626 6. Acknowledgements 628 This document represents an overview of a number of building blocks for 629 one to many bulk data transfer that may be ready for standardization 630 within the RMT working group. The ideas presented are not those of the 631 authors, they are a summarization of many years of research into 632 multicast transport combined with the varied presentations and 633 discussions in the IRTF Reliable Multicast Research Group. Although 634 they are too numerous to list here, we thank everyone who has 635 participated in these discussions for their contributions. 637 7. References 639 [FJM95] 640 S. Floyd, V. Jacobson, S. McCanne, "A Reliable Multicast Framework 641 for Light-weight Sessions and Application Level Framing," Proc ACM 642 SIGCOMM 95, Aug 1995 pp. 342-356. 644 [FLST98] 645 D. Farinacci, A. Lin, T. Speakman, and A. Tweedly, "PGM reliable 646 transport protocol specification," Internet Draft, Internet 647 Engineering Task Force, Aug. 1998. Work in progress. 649 [HFW99] 650 M. Handley, S. Floyd, B. Whetten, "Strawman Specification for TCP 651 Friendly (Reliable) Multicast Congestion Control (TFMCC)," work in 652 progress. 654 [HJ98] 655 M. Handley, V. Jacobson, "SDP: Session Description Protocol," 656 RFC2327, April 1998. 658 [HPW99] 659 M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol," 660 Internet Draft, work in progress, June 1999. 662 [HW99] 663 T. Hardjorno, B. Whetten, "Security Requirements for RMTP-II," 664 Internet Draft, work in progress, June 1999. 666 [HWKFV99] 667 M. Handley, B.Whetten, R. Kermode, S.Floyd, and L. Vicisano, "The 668 Reliable Multicast Design Space for Bulk Data Transfer," Internet 669 Draft, Internet Engineering Task Force, June 1999. 671 Draft RMT Building Blocks 15 June 1999 673 [KCW98] 674 M. Kadansky, D. Chiu, and J. Wesley, `"Tree-based reliable 675 multicast (TRAM),'" Internet Draft, Internet Engineering Task 676 Force, Nov. 1998. Work in progress. 678 [Kermode98] 679 R. Kermode, "Scoped Hybrid Automatic Repeat Request with Forward 680 Error Correction," Proc ACM SIGCOMM 98, Sept 1998. 682 [LDW98] 683 M. Lucas, B. Dempsey, A. Weaver, "MESH: Distributed Error Recovery 684 for Multimedia Streams in Wide-Area Multicast Networks" 686 [LESZ97] 687 C-G. Liu, D. Estrin, S. Shenkar, L. Zhang, "Local Error Recovery in 688 SRM: Comparison of Two Approaches," USC Technical Report 97- 648, 689 Jan 1997. 691 [LG97] 692 B.N. Levine, J.J. Garcua-Luna-Aceves, "Improving Internet Multicast 693 Routing with Routing Labels," IEEE International Conference on 694 Network Protocols (ICNP-97), Oct 28-31, 1997, p.241-250. 696 [LP96] 697 K. Lin and S. Paul. "RMTP: A Reliable Multicast Transport 698 Protocol," IEEE INFOCOMM 1996, March 1996, pp. 1414-1424. 700 [MA99] 701 J. Macker, B. Adamson. "Multicast Dissemination Protocol version 2 702 (MDPv2)," work in progress, http://manimac.itd.nrl.navy.mil/MDP. 704 [MRBP98] 705 A. Mankin, A. Romanow, S.Brander, V.Paxson, "IETF Criteria for 706 Evaluating Reliable Multicast Transport and Application Protocols," 707 RFC2357, June 1998. 709 [OXB99] 710 O. Ozkasap, Z. Xiao, K. Birman. "Scalability of Two Reliable 711 Multicast Protocols," Work in progress, May 1999. 713 [PSLB97] 714 "Reliable Multicast Transport Protocol (RMTP)," S. Paul, K. K. 715 Sabnani, J. C. Lin, and S. Bhattacharyya, IEEE Journal on Selected 716 Areas in Communications, Vol. 15, No. 3, April 1997. 718 Draft RMT Building Blocks 15 June 1999 720 [RV97] 721 L. Rizzo, L. Vicisano, "A Reliable Multicast Data Distribution 722 Protocol Based on Software FEC Techniques," Proc. of The Fourth 723 IEEE Workshop on the Architecture and Implementation of High 724 Performance Communication Systems (HPCS'97), Sani Beach, 725 Chalkidiki, Greece June 23-25, 1997. 727 [WBPM98] 728 B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, N. Rastogi, J. 729 Conlan, and T. Yeh, "THE RMTP-II PROTOCOL," Internet Draft, 730 Internet Engineering Task Force, Apr. 1998. Work in progress 732 [WHA98] 733 D. Wallner, E. Hardler, R. Agee, `"Key Management for Multicast: 734 Issues and Architectures," Internet Draft, work in progress, Sept 735 1998. 737 [Whetten99] 738 B. Whetten, "A Proposal for Reliable Multicast Congestion Control 739 Requirements," work in progress. http://www.talarian.com/rmtp- 740 ii/overview.htm 742 8. Authors' Addresses 744 Brian Whetten 745 Talarian Corporation, 746 333 Distel Circle, 747 Los Altos, CA 94022, USA 748 whetten@talarian.com 750 Lorenzo Vicisano 751 Cisco Systems, 752 170 West Tasman Dr. 753 San Jose, CA 95134, USA 754 lorenzo@cisco.com 756 Roger Kermode 757 Motorola Australian Research Centre 758 Level 3, 12 Lord St, 759 Botany NSW 2019, 760 Australia. 761 Roger.Kermode@motorola.com 763 Draft RMT Building Blocks 15 June 1999 765 Mark Handley, Sally Floyd 766 ATT Center for Internet Research at ICSI, 767 International Computer Science Institute, 768 1947 Center Street, Suite 600, 769 Berkeley, CA 94704, USA 770 mjh@aciri.org, floyd@aciri.org 772 9. Full Copyright Statement 774 Copyright (C) The Internet Society (1998). All Rights Reserved. 776 This document and translations of it may be copied and furnished to 777 others, and derivative works that comment on or otherwise explain it or 778 assist in its implementation may be prepared, copied, published and 779 distributed, in whole or in part, without restriction of any kind, 780 provided that the above copyright notice and this paragraph are included 781 on all such copies and derivative works. However, this document itself 782 may not be modified in any way, such as by removing the copyright notice 783 or references to the Internet Society or other Internet organizations, 784 except as needed for the purpose of developing Internet standards in 785 which case the procedures for copyrights defined in the Internet 786 languages other than English. 788 The limited permissions granted above are perpetual and will not be 789 revoked by the Internet Society or its successors or assigns. 791 This document and the information contained herein is provided on an "AS 792 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 793 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 794 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 795 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 796 FITNESS FOR A PARTICULAR PURPOSE." 798 Draft RMT Building Blocks 15 June 1999 800 Table of Contents 802 1 Introduction .................................................... 2 803 1.1 Protocol Families ............................................. 4 804 2 Building Blocks Rationale ....................................... 4 805 2.1 Building Blocks Advantages .................................... 5 806 2.2 Building Block Risks .......................................... 6 807 2.3 Building Block Requirements ................................... 6 808 3 Protocol Components ............................................. 7 809 3.1 Sub-Components Definition ..................................... 8 810 4 Building Block Recommendations .................................. 11 811 4.1 NAK-based Reliability ......................................... 11 812 4.2 FEC Repair .................................................... 12 813 4.3 Congestion Control ............................................ 12 814 4.4 Generic Router Support ........................................ 12 815 4.5 Tree Configuration ............................................ 13 816 4.6 Security ...................................................... 14 817 4.7 Common Headers ................................................ 14 818 4.8 Protocol Cores ................................................ 14 819 5 Conclusions ..................................................... 14 820 6 Acknowledgements ................................................ 15 821 7 References ...................................................... 15 822 8 Authors' Addresses .............................................. 17 823 9 Full Copyright Statement ........................................ 18