idnits 2.17.1 draft-koh-rmt-bb-tsm-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 60 lines 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. ** There are 14 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Depending on application services, some of the actions described above MAY NOT be enabled. For example, for a certain multicast session, the sender MAY NOT perform Troublemaker Ejection. -- 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) == Unused Reference: 'RFC2026' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'RMT-DS' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RMT-BB' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'SAP' is defined on line 612, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2887 (ref. 'RMT-DS') ** Downref: Normative reference to an Informational RFC: RFC 3048 (ref. 'RMT-BB') -- No information found for draft-ietf-rmt-author-guidelines - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RMT-Author' ** Downref: Normative reference to an Experimental RFC: RFC 2974 (ref. 'SAP') -- Possible downref: Non-RFC (?) normative reference: ref. 'TRACK' -- Possible downref: Non-RFC (?) normative reference: ref. 'TREE' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECTS' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECTP' Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Seok Joo Koh, ETRI/KOREA 3 Document: draft-koh-rmt-bb-tsm-00.txt Shin Gak Kang, ETRI/KOREA 4 February 2001 Juyoung Park, ETRI/KOREA 5 Expires August 2001 Eunsook Kim, ETRI/KOREA 7 Reliable Multicast Transport Building Blocks: 8 Transport Session Management 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This document is the result of the joint development work on Enhanced 31 Communications Transport Protocol (ECTP) which is being undertaken by 32 ISO/IEC JTC 1/SC 6 and ITU-T/SG 7. Transmission to the IETF was 33 endorsed at the joint ITU-T/SG 7 and by ISO/IEC JTC 1/SC 6 meeting on 34 31th Jan. 2001. 36 Abstract 38 This document provides a framework of Transport Session Management 39 (TSM) mechanisms, which has been designed to support desirable 40 management of end-to-end multicast sessions, according to the 41 application's requirements that are represented as a set of TSM 42 parameters including throughput and packet loss rate. TSM operations 43 include Session Join, Session Monitoring and Session Maintenance. In 44 Session Join, the sender informs authorized receivers about the 45 target values of TSM parameters. In Session Monitoring, each 46 receiver continues to measure the parameter values that have been 47 experienced and to report the status of each parameter value to the 48 sender. Based on the status information monitored and the target 49 values of TSM parameters, the sender takes Session Maintenance 50 actions necessary to maintain the session status desirable. Those 51 actions include adjustment of data transmission rate, troublemaker 52 ejection, session pause/resume, and session termination. TSM 53 mechanisms can be implemented into an API and easily adopted by any 54 RMT PIs that wish to tightly control multicast sessions. 56 1. Introduction 58 A multicast transport protocol instantiation may include various 59 protocol components such as error recovery, flow and congestion 60 control, membership management, and session management [RMT-DS, RMT- 61 BB]. 63 This document provides a framework of Transport Session Management 64 (TSM) mechanisms, which has been designed to support desirable 65 management of end-to-end multicast sessions, according to the 66 application's requirements that are represented as a set of TSM 67 parameters including throughput and packet loss rate. TSM operations 68 include Session Join, Session Monitoring and Session Maintenance. In 69 Session Join, the sender informs authorized receivers about the 70 target values of TSM parameters. In Session Monitoring, each 71 receiver continues to measure the parameter values that have been 72 experienced and to report the status of each parameter value to the 73 sender. Based on the status information monitored and the target 74 values of TSM parameters, the sender takes Session Maintenance 75 actions necessary to maintain the session status desirable. Those 76 actions include adjustment of data transmission rate, troublemaker 77 ejection, session pause/resume, and session termination. 79 The key feature of TSM is to provide the senders with information on 80 membership tracking and current session status in terms of TSM 81 parameters. Membership information is crucial for design of 82 billing/charging model. Session status needs to be monitored to 83 maintain the session desirable. 85 TSM is a coarsely grained functionality for end-to-end multicast 86 transport, and thus can be considered as a Building Block of RMT. 87 TSM mechanisms can be implemented into an API and easily adopted by 88 any RMT PIs that wish to tightly control multicast sessions. 90 1.1 Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 Transport Session 98 Transport Session refers to a session for multicast data delivery. 99 In a one-to-many multicast session, there are a single sender and 100 many receivers. 102 Transport Session Management (TSM) 104 TSM functionality is provided to maintain a multicast session 105 desirable, according to application's requirements. TSM mechanisms 106 can be implemented into an API that a multicast transport protocol 107 adopts easily. 109 TSM Parameters 111 A TSM parameter is a performance metric that represents session 112 status and Quality of Services for the multicast data delivery. 113 Typical examples of TSM parameters include throughput and packet loss 114 rate. According to application's requirements, the sender may 115 configure a set of target values of each TSM parameter for desirable 116 display of application data. For Session Monitoring, each receiver 117 reports the experienced status for each TSM parameter to the sender. 119 1.2 Motivations for TSM 121 Some multicast applications have a crucial need to guarantee a 122 desired Quality of Service (QoS) in the delivery of multicast data. 123 In principal, the QoS for data delivery can be supported with help of 124 network-layer resource reservation mechanisms such as RSVP or 125 Diffserv. However, in the end-to-end transport level, the sender 126 needs to monitor and manage how much desirably the QoS for a 127 multicast session is being supported [ECTS, ECTP]. 129 TSM functionality is designed to support a tight control of multicast 130 sessions. TSM mechanisms can be used to maintain the transport 131 session desirable according to the application's requirements, and 132 also to protect the session status from being degraded more severely. 134 1.3 Rationale of TSM BB 136 Per the guidelines of RMT BB draft [RMT-Author], this section will be 137 filled. 139 TBD 141 1.4 Applicability Statement 143 Per the guidelines of RMT BB draft [RMT-Author], this section will be 144 filled. 146 TBD 148 1.5 Relationship with the other BBs and PIs 150 TSM BB does not impose any requirements and modifications on existing 151 RMT BBs and PIs. The TSM functionality and its mechanisms can be 152 easily adopted by any RMT PIs that wish a tight control of multicast 153 session. 155 We note that TSM BB is a good-match with TRACK BB and PI, in the 156 viewpoint of scalability enhancement of feedback messages from 157 receivers to sender. For the sessions concerned with the 158 scalability, it is likely that TSM BB is employed along with TRACK BB 159 or its underlying mechanisms. 161 For the other PIs such as NORM and ALC, TSM can also be employed with 162 provisioning of a suitable feedback mechanism. 164 2. TSM Overview 166 Transport Session Management (TSM) is designed to support a tight 167 control of multicast sessions. TSM functionality is accomplished by 168 interactions between the sender and receivers. In TSM, the sender is 169 responsible for overall TSM operations. 171 Figure 1 illustrates an overall TSM functionality during a multicast 172 session. 174 TSM functionality is achieved by the following operations: 175 (a) Session Join 176 (b) Session Monitoring 177 (c) Session Maintenance 179 In Session Join, the following two events occur: 180 - Join Request by a receiver 181 - Join Confirm by the sender 183 Each receiver who wants to participate in the session sends a Join 184 Request message to the sender. The sender may make a decision 185 whether the join request should be accepted or not, possibly along 186 with an authentication process. When the join request is accepted, 187 the sender will sends a Join Confirm message that contains 188 information on the target values of TSM parameters such as throughput 189 and packet loss rate. 191 +--------------------------------------------------------------+ 192 | | 193 | +-------------+ +--------------+ | 194 | | Data Rate | +-------------+ | Session | | 195 | | Adjustment |<--- | Session | ---> | Pause/Resume | | 196 | +-------------+ | Monitoring | +--------------+ | 197 | | with | | 198 | +-------------+ | Membership | +--------------+ | 199 | |Troublemaker |<--- | Tracking | ---> | Session | | 200 | | Ejection | +-------------+ | Termination | | 201 | +-------------+ ^ +--------------+ | 202 | | | 203 +------------------------------+-------------------------------+ 204 ^ | ^ 205 | | | 206 -----------+---------------------+-------------------+-------------- 207 | | | TSM API 208 v | v 209 +---------+ | +-----------+ 210 | | | | | 211 | Sender |============================>| Receivers | 212 | | Multicast Data | | 213 +---------+ +-----------+ 215 Figure 1. TSM Overview 217 Session Monitoring is used for sender to diagnose current session 218 status for multicast data delivery. Session Monitoring also performs 219 'Membership Tracking', by which the sender keeps track of the list of 220 active receivers. 222 For Session Monitoring, each receiver is required to measure a status 223 value for each TSM parameter that has been experienced for the 224 received multicast data streams. If a status value indicates an 225 abnormal status, the receiver reports the status value to the sender 226 via a TSM Response message. 228 TSM Response messages are also generated in response to the periodic 229 TSM Request messages of the sender. Through these interactions with 230 receivers, the sender can perform the membership tracking. 232 Session Maintenance is performed based on the reported status values 233 and the target values for TSM parameters. Sender continues to 234 aggregate the status values that have been reported from the 235 receivers. Based on the aggregated information, the sender will take 236 one or more of the following Session Maintenance actions: 237 - Adjustment of data transmission rate 238 - Troublemaker ejection 239 - Session pause/resume 240 - Session termination 242 TSM Request messages are also used to indicate a current session 243 status, which is classified into one of the following: 244 - Session Creation 245 - Data Transmission 246 - Session Pause 247 - Session Termination 249 3. TSM Components 251 3.1 Sender 253 Sender transmits multicast data to the receivers in the session. It 254 is responsible for the overall TSM operations. 256 3.2 Receiver 258 A receiver receives multicast data from the sender. TSM is based on 259 interaction between sender and receivers. 261 3.3 TSM Parameters 263 TSM parameters are used to diagnose a current session status. This 264 document specifies two TSM parameters: throughput and packet loss 265 rate. In the future, more TSM parameters may be added, if necessary. 267 Throughput (THRUPUT) can be represented in units of bytes per second. 268 THRUPUT can be interpreted as data transmission rate at the sender 269 side and also data reception rate at receiver side. Packet loss rate 270 (PLR) is defined as the ratio of lost packets over totally 271 transmitted packets. PLR may be represented as an integer number 272 ranged from 0 to 100. The sequence numbers of data packets can be 273 used to measure the packet loss rate. 275 In Session Join, the sender announces the authorized receiver about 276 the pre-configured target values for each TSM parameter such as 277 - MIN: a minimum value 278 - ALLOWED_LOW: an allowed low value 279 - ALLOWED_HIGH: an allowed high value 280 - MAX: a maximum value 282 These target values MAY be determined by considering application's 283 requirements. Among those values, the following inequalities are 284 enforced: 286 MIN <= ALLOWED_LOW <= ALLOWED_HIGH <= MAX 288 For THRUPUT parameter, the following variables can be defined: 289 - MIN_THRUPUT 290 - ALLOWED_LOW_THRUPUT 291 - ALLOWED_HIGH_THRUPUT 292 - MAX_THRUPUT 294 For PLR parameter, the following variables can be defined: 295 - MIN_PLR 296 - ALLOWED_LOW_PLR 297 - ALLOWED_HIGH_PLR 298 - MAX_PLR 300 In Session Monitoring, each receiver is required to measure the 301 parameter values experienced for the received multicast data. By 302 comparing the measured values and the target values, the receiver 303 sets each of THRUPUT_STATUS and PLR_STATUS to an integer of '0 304 through 4' as follows: 306 0, if ALLOWED_LOW <= measured value <= ALLOWED_HIGH 307 1, if MIN <= measured value <= ALLOWED_LOW 308 2, if ALLOWED_HIGH <= measured value <= MAX 309 3, if measured value <= MIN 310 4, if MAX <= measured value 312 The STATUS value of '0' represents a normal status, while the non- 313 zero values mean that the session possibly goes into abnormal status 314 (1 or 2), or is currently being in an abnormal status (3 or 4). 316 In Session Monitoring, receivers report those STATUS values to the 317 sender via TSM Response messages. 319 3.4 TSM Messages 321 The following control messages are used for TSM: 322 - Join Request 323 - Join Confirm 324 - Ejection 325 - TSM Request 326 - TSM Response 328 Table 1 summarizes the detailed use of those TSM messages. 330 Table 1. TSM messages 332 +--------------+------+-----+-----------+---------------------+ 333 | Message | From | To | Unicast/ | TSM Operation | 334 | Types | | | Multicast | Concerned | 335 +--------------+------+-----+-----------+---------------------+ 336 | Join Request | R | S | Unicast | Session Join | 337 +--------------+------+-----+-----------+---------------------+ 338 | Join Confirm | S | R | Unicast | Session Join | 339 +--------------+------+-----+-----------+---------------------+ 340 | Ejection | S | R | Unicast | Session Maintenance | 341 +--------------+------+-----+-----------+---------------------+ 342 | TSM Request | S | Rs | Multicast | Session Monitoring | 343 +--------------+------+-----+-----------+---------------------+ 344 | TSM Response | R | S | Unicast | Session Monitoring | 345 +--------------+------+-----+-----------+---------------------+ 346 S: Sender, R : Receiver 348 3.4.1 Join Request 350 A receiver that wishes to join the session sends a Join Request to 351 the sender. 353 3.4.2 Join Confirm 355 The sender responds with a Join Confirm message to the Join Request. 356 The Join Confirm message contains the following information: 357 - Whether a Join Request is accepted or not 358 - Target values for TSM parameters: MIN, ALLOWED_LOW, ALLOWED_MAX, 359 MAX 360 - Receiver ID for the corresponding receiver 362 The receiver ID can be used for membership tracking, and also used in 363 generation of a TSM Response message (see Section 5). 365 3.4.3 Ejection 367 In Session Maintenance, the sender MAY eject the trouble-making 368 receiver by sending an Ejection message. 370 3.4.4 TSM Request 372 The sender transmits periodic TSM Request messages to the receivers. 374 The length of periodic time interval MAY vary depending on 375 implementations. 377 Each TSM Request message triggers the corresponding TSM Response 378 messages from some or all of the receivers. The TSM Request message 379 contains an integer value to indicate the current session status. To 380 do this, the current session status is classified into one of the 381 following phases, with an integer value: 382 - Session Creation (0) 383 - Data Transmission (1) 384 - Session Pause (2) 385 - Session Termination (3) 387 When a session starts, the sender indicates 'Session Creation'. If 388 TSM BB is used in TRACK PI, 'Session Creation' state can be used as 389 an indication signal for an initial tree configuration [TREE]. After 390 a session is created, the TSM Request messages will indicate 'Data 391 Transmission'. 'Session Pause' will be indicated if a sender 392 realizes that the session potentially goes into an abnormal status. 393 In Session Pause period, the sender is not allowed to send any new 394 multicast data. When the session status is perceived to go back to a 395 normal status, the sender will again indicate 'Data Transmission', 396 and then resumes the multicast data transmission. 'Session 397 Termination' is indicated after the sender transmits all the 398 multicast data, or if the session is detected to be in the severe 399 abnormal status. 401 3.4.5 TSM Response 403 A TSM Response messages contain the following information: 404 - Receiver ID 405 - THRUPUT_STATUS (ranged from 0 - 4) 406 - PLR_STATUS (ranged from 0 - 4) 408 Each receiver generates a TSM message if its measured THRUPUT_STATUS 409 or PLR_STATUS is a non-zero value. TSM messages can also be 410 generated in response to a periodic TSM Request message. 412 4. TSM Procedures 414 4.1 Session Join 416 A receiver who wants to join a session sends a Join Request message 417 to the sender. When the sender receives a Join Request message, it 418 MAY check whether the receiver is an authorized user or not. 420 In response to a Join Request, the sender transmits a Join Confirm 421 message to the receiver. The Join Confirm message contains 422 information on Receiver ID and whether the Join Request is accepted 423 or not. The Join Confirm message also contains the pre-configured 424 target values of TSM parameters: MIN, ALLOWED_LOW, ALLOWED_HIGH, and 425 MAX (see 3.3). 427 In the networks that support resource reservation mechanisms such as 428 RSVP and Diffserv, the receiver SHALL initiate the reservation of the 429 required network resources. Then the target parameter values MAY be 430 referred to in the reservation process. 432 4.2 Session Monitoring 434 In Session Monitoring, the sender monitors how well the session 435 operates and also which receivers are participating in the session. 436 To do this, each receiver is required to measure the THRUPUT and PLR 437 values experienced for the received multicast data. Those measured 438 THRUPUT and PLR values are compared with the target values for 439 THRUPUT and PLR announced in Session Join, and then the receiver 440 determines THRUPUT_STATUS and PLR_STATUS values as 0, 1, 2, 3 or 4 441 (see 3.3). 443 If the STATUS value is a non-zero value, the receiver generates a TSM 444 Response message. For the STATUS value of '0', the receiver does not 445 need to generate a TSM Response message. In other words, the sender 446 will realize that a receiver is in the normal status, if it does not 447 send any TSM Response messages indicating an abnormal status, where 448 an abnormal status indicates that the STATUS value is non-zero. 450 TSM Response message is also generated responsively to a periodic TSM 451 Request message. This feedback mechanism is designed to support 452 Membership Tracking and an overall identification of the current 453 session status. 455 In response to the periodic TSM Request message, some or all of 456 receivers send TSM Response messages to the sender. To reduce the 457 number of simultaneous TSM Response messages from the receivers, a 458 specific rule MAY be employed. An example is given in Section 5. 460 During a session, the sender aggregates the reported THRUPUT_STATUS 461 and PLR_STATUS values from the receivers. In the aggregation, the 462 following considerations will be taken: 463 - Which receivers are in the abnormal status ? 464 - How many receivers in a given session are in the abnormal status ? 466 Based on this aggregated information, the sender takes one or more 467 Session Maintenance actions. 469 4.3. Session Maintenance 471 Session Maintenance is purposed to maintain the session status 472 desirable, and to prevent the session status from being degraded more 473 severely. 475 Based on the THRUPUT_STATUS and PLR_STATUS values reported from the 476 receivers, the sender takes one or more of the following Session 477 Maintenance actions: 478 - Adjustment of data transmission rate 479 - Ejection of Troublemaker 480 - Session Pause and Resume 481 - Session Termination 483 Depending on application services, some of the actions described 484 above MAY NOT be enabled. For example, for a certain multicast 485 session, the sender MAY NOT perform Troublemaker Ejection. 487 4.3.1 Adjustment of data transmission rate 489 If this option is enabled, the sender will adjust data transmission 490 rate based on the monitored STATUS values of the TSM parameters. The 491 data transmission rate is bounded as follows: 493 MIN_THRUPUT <= Data Transmission Rate <= MAX_THRUPUT 495 Specific rules to increase or decrease the data transmission rate are 496 for further study, which MAY depend on the Congestion Control 497 algorithm that will be developed in the RMT WG. 499 4.3.2 Ejection of Troublemaker 501 To determine whether a receiver is a troublemaker or not, the sender 502 MUST configure a rule to trigger a Troublemaker Ejection. The 503 specific rule is an implementation issue. For an example, a receiver 504 can be regarded as a troublemaker if the STATUS values for TSM 505 parameters have been consecutively in abnormal status more than the 506 pre-configured threshold times. 508 Once a troublemaker is detected, the sender sends an Ejection message 509 to the concerned receiver. 511 4.3.3 Session Pause and Resume 513 Session Pause is used to suspend the data transmission of the sender 514 temporarily and thus to prevent the session from being more severely 515 degraded. 517 The sender announces 'Session Pause' to all the receivers via TSM 518 Request message, which has the session status value of '2' (see 519 3.4.4). In the Session Pause period, the sender SHALL NOT send any 520 new multicast data. 522 The specific rule to trigger Session Pause can be configured based on 523 the STATUS values reported from the receivers. For an example, if 524 the number of receivers reporting an abnormal status is greater than 525 a pre-configured number, then the sender MAY trigger Session Pause. 527 After Session Pause is indicated, Session Resume will be activated if 528 the session status is perceived to come back into the normal state. 529 The specific rule to trigger Session Resume is an implementation 530 issue. A simple rule to trigger the Session Resume is to use a 531 timer. In this case, if the timer expires after Session Pause is 532 indicated, then the sender will automatically resume the session by 533 sending a TSM Request message with an indication of 'Data 534 Transmission' (see 3.4.4). 536 4.3.4 Session Termination 538 The natural option for Session Termination is to terminate a session 539 when all the multicast data have been transmitted. Session 540 Termination is also triggered if the session is detected to be in the 541 severe abnormal state. When Session Termination is indicated, the 542 sender terminates the session and sends a TSM Request message with 543 indication of Session Termination. 545 The activation of Session Termination can be performed in various 546 ways. One simple way is to trigger Session Termination if the 547 Session Pause/Resume operations have been consecutively repeated more 548 than a pre-configured times. 550 5. Scalability Enhancement for Feedback Implosions of TSM Response 551 Messages 553 Session Monitoring is based on the 'TSM Response' feedback messages 554 from the receivers. For the session that consists of a large number 555 of receivers, simultaneous responses of TSM Response messages may 556 induce an implosion of feedback messages. This is referred to as the 557 scalability problem. 559 If a hierarchical control tree [TREE] is employed along with TSM BB, 560 it is clear that we reduce the number of simultaneously generated TSM 561 Response messages. We also propose an alternate scheme to improve 562 the feedback implosion, which has benefited from TRACK BB [TRACK]. 564 For this purpose, we define the following two new variables: 565 - TSM Sequence Number (TSN) 566 - Response Generation Number (RGN) 568 TSN is an integer number sequentially assigned to each periodic TSM 569 Request massage. RGN is a scaling factor used to limit the number of 570 the simultaneously responding receivers. These variables will be 571 contained in the periodic TSM Request message, if they are enabled 572 for scalability enhancement. 574 For a TSM Request message, each receiver responds with a TSM Response 575 message, if the following condition holds true: 577 (TSN % RGN) == (Receiver ID % RGN), 579 where % represents "modulo" operator. 581 For an example, suppose there are receivers with Receiver ID = 582 1,..,20. In response to a TSM Request message with TSN = 3 and RGN = 583 5, the receivers with Receiver ID = 3, 8, 13, 18 will transmit the 584 corresponding TSM Response message. 586 6. Security Considerations 588 The Join Confirm messages MAY be used to deliver the group key 589 information to the receivers for security purposes, if necessary. In 590 this case, an initial group key will be distributed via the Join 591 Confirm message, and the changed group key information via the 592 subsequent TSM Request messages. 594 7. References 596 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997 599 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 600 BCP 9, RFC 2026, October 1996. 602 [RMT-DS] M. Handley, et al., "The Reliable Multicast Design Space for 603 Bulk Data Transfer", RFC 2887, August 2000. 605 [RMT-BB] B. Whetton, et al., "Reliable Multicast Transport Building 606 Blocks for One-to-Many Bulk Data Transfer", RFC 3048, January 2001. 608 [RMT-Author] R. Kermode and L. Vicisano, "Author Guidelines for RMT 609 Building Blocks and Protocol Instantiation documents", draft-ietf- 610 rmt-author-guidelines-00.txt, June 2000. 612 [SAP] M. Handley, et al., "Session Announcement Protocol", RFC 2974, 613 October 2000. 615 [TRACK] B. Whetton, et al., "Reliable Multicast Transport Building 616 Block for TRACK", Feb. 2001. 618 [TREE] M. Kadansky, et al.,"Reliable Multicast Transport Building 619 Block: Tree Auto-Configuration", November 2000. 621 [ECTS] ITU-T Recommendation X.605 and ISO/IEC 13252, "Enhanced 622 Communication Transport Services", 1999. 624 [ECTP] ITU-T Draft Recommendation X.ectp and ISO/IEC JTC1/SC6 CD 625 14476, "Enhanced Communications Transport Protocol", Work in 626 Progress, Feb. 2001. 628 8. Acknowledgments 630 We would like to give special thanks to the following individuals. 631 Jim Long, UK 632 Jack Houldsworth, UK 633 Dae Young Kim, KOREA 634 Hyun Kook Kahng, KOREA 636 9. Author's Addresses 638 Seok Joo Koh 639 sjkoh@pec.etri.re.kr 640 Shin Gak Kang 641 sgkang@etri.re.kr 642 Juyoung Park 643 jypark@ccl.cnu.ac.kr 644 Eun Sook Kim 645 eunsook@cs.sookmyung.ac.kr 647 Protocol Engineering Center 648 Electronics Telecommunications Research Institute 649 Kajong-Dong, Yusung-Gu, Taejon, 305-350, Korea 651 Full Copyright Statement 653 "Copyright (C) The Internet Society (2000). All Rights Reserved. This 654 document and translations of it may be copied and furnished to others, and 655 derivative works that comment on or otherwise explain it or assist in its 656 implementation may be prepared, copied, published and distributed, in whole 657 or in part, without restriction of any kind, provided that the above 658 copyright notice and this paragraph are included on all such copies and 659 derivative works. However, this document itself may not be modified in any 660 way, such as by removing the copyright notice or references to the Internet 661 Society or other Internet organizations, except as needed for the purpose of 662 developing Internet standards in which case the procedures for copyrights 663 defined in the Internet Standards process must be followed, or as required 664 to translate it into languages other than English. 666 The limited permissions granted above are perpetual and will not be 667 revoked by the Internet Society or its successors or assigns. 669 This document and the information contained herein is provided on an "AS IS" 670 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 671 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 672 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 673 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 674 PARTICULAR PURPOSE."