idnits 2.17.1 draft-dykim-ectp-00.txt: -(342): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(535): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(580): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(604): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(748): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(972): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1038): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1125): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1126): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1156): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1178): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1247): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1251): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1255): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1260): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.3 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1284. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1297. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 26 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 31 longer pages, the longest (page 1) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 444 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the IETF Trust 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: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1235, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 1240, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1243, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1246, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1250, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1254, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Dae Young Kim 3 Intended status: Informational Chungnam National University 4 Expires: October 2007 Seok Joo Koh 5 April 18, 2007 Kyungpook National University 7 Enhanced Communications Transport Protocol for One-to-Many Multicast 8 Applications with Unicast Reverse Data Channels 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 This document may not be modified, and derivative works of it may not 20 be created, except to publish it as an RFC and to translate it into 21 languages other than English. 23 This document may only be posted in an Internet-Draft. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on October 18, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 This document is a part of the ITU-T Recommendation and ISO/IEC 49 International Standard, named the Enhanced Communications Transport 50 Protocol (ECTP), which is a multicast transport protocol designed to 51 support Internet multicast applications. This third part of ECTP 52 (ECTP-3) describes the protocol specification for the duplex 53 multicast transport. In a duplex connection, a single multicast 54 sender, named TC-Owner (TO), transmits multicast data to the other 55 group members, while some of the participating TS-users may send 56 unicast data to the TO over the reverse data channel. 58 Table of Contents 60 1. Introduction................................................4 61 2. Terminology.................................................5 62 2.1. Definitions............................................5 63 2.2. Abbreviations..........................................6 64 2.3. Conventions............................................6 65 3. Protocol Overview...........................................7 66 4. Design Considerations.......................................11 67 4.1. Participants..........................................11 68 4.2. Control Tree..........................................11 69 4.3. Data Channels.........................................12 70 4.4. Addressing............................................13 71 4.5. Tokens................................................15 72 5. Packets....................................................15 73 5.1. Base Header...........................................15 74 5.2. Extension Elements.....................................17 75 5.3. Packet Format.........................................19 76 6. Procedures.................................................21 77 6.1. Connection Creation....................................21 78 6.2. Late Join.............................................22 79 6.3. Forward Data Transport.................................22 80 6.4. Reliability Control for Reliable Transport.............24 81 6.5. Control Tree Maintenance...............................26 82 6.6. Congestion Control for Forward Data Channel............27 83 6.7. Token Control.........................................27 84 6.8. Backward Data Transport................................28 85 6.9. Connection Management..................................29 86 7. Security Considerations.....................................29 87 8. IANA Considerations........................................29 88 9. Acknowledgments............................................29 89 10. References................................................30 90 10.1. Normative References..................................30 91 10.2. Informative References................................30 92 Author's Addresses............................................30 93 Intellectual Property Statement................................30 94 Disclaimer of Validity........................................30 96 1. Introduction 98 This document (Recommendation | International Standard) specifies the 99 Enhanced Communications Transport Protocol (ECTP), which is a 100 transport protocol designed to support Internet multicast 101 applications running over multicast-capable networks. ECTP shall be 102 provisioned over UDP. 104 ECTP is designed to support tightly controlled multicast connections 105 in simplex, duplex and N-plex applications. This part of ECTP (part 106 3: ITU-T X.607 | ISO/IEC 14476-3) specifies the protocol mechanisms 107 for reliability control in the duplex case. 109 In the ECTP-3 duplex multicast connection, the participants are 110 classified into one TC-Owner and many TS-users. TC-Owner will be 111 designated among the TS-users before the connection begins. In the 112 duplex multicast connection, the two types of data transports are 113 supported: multicast data transport from TC-Owner to all the other 114 TS-users and unicast data transport from TS-users to TC-Owner. After 115 the connection is created, TC-Owner can transmit multicast data to 116 the group, whereas each TS-user is allowed to send unicast data to 117 TC-Owner just after it gets a token from the TC-Owner. 119 In ECTP, TC-Owner is at the heart of multicast group communications. 120 It is responsible for overall connection management by governing the 121 connection creation and termination, connection pause and resumption 122 and the late join and leave operations. 124 The duplex multicast connection specified in ECTP-3 is targeted to 125 the multicast applications in which the TC-Owner (a single multicast 126 sender) transmits the data information to all the other TS-users, and 127 some of the TS-users respond to the multicast sender with the unicast 128 feedback data. Basically, the duplex multicast transport will be well 129 suited to the one-to-many multicast applications that need the 130 unicast feedback channels from some TS-users (e.g., remote education, 131 Internet broadcasting, etc). For example, in a remote education 132 application, the multicast sender (lecturer) transmits the data such 133 as voice, text and image to the student group, whereas some of the 134 students may respond to the lecturer with the unicast data like 135 questions for confirmation. 137 It is noted that this duplex multicast connection can also be used 138 for the �some-to-many� multicast applications (e.g., a panel 139 conferencing) in which a few of TS-users want to send multicast data 140 to the group. In this scenario, the multicast data from the TS-users 141 may first be delivered to the TC-Owner by unicast, and then TC-Owner 142 will transmit the received unicast data to the group by multicast. 144 2. Terminology 146 2.1. Definitions 148 This document also applies the following definitions: 150 TO (TC-Owner) 152 TO can only transmit multicast data to the other TS-users, and it 153 manages overall operations of ECTP-3; 155 TU (TS-User) 157 TU can receive multicast data sent by TO; 159 SU (Sending TU) 161 A TU who gets a token from TO. Only the SU is allowed to send 162 unicast data to TO. In other words, before sending unicast data, 163 each TU must request a token to TO; 165 RA (Repair Agent) 167 It is located on the control tree of ECTP-3. One or more RAs 168 could be designated for scalable error recovery and status 169 monitoring in ECTP-3. An RA is also a TU, that is, it receives 170 multicast data from TO. RAs will be configured as a parent of the 171 local groups through the control tree configuration in ECTP-3; 173 Token 175 It represents the right for a TU to transmit data. The TU who has 176 a token is called SU. The tokens are managed by TC-Owner; 178 Forward Data Channel 180 It represents the multicast data channel from TO to the TUs. TO 181 sends multicast data to all the other group members over IP 182 multicast address. 184 Backward Data Channel 186 It represents the unicast data channel from a TU (SU) to TO. An 187 SU who has a token can send unicast data to TO over IP unicast 188 address. 190 2.2. Abbreviations 192 The following acronyms for ECTP protocols are used in this document: 194 ECTP-1 ECTP part 1 (ITU-T X.606 | ISO/IEC 14476-1) 195 ECTP-2 ECTP part 2 (ITU-T X.606.1 | ISO/IEC 14476-2) 196 ECTP-3 ECTP part 3 (ITU-T X.607 | ISO/IEC 14476-3) 197 ECTP-4 ECTP part 4 (ITU-T X.607.1 | ISO/IEC 14476-4) 198 ECTP-5 ECTP part 5 (ITU-T X.608 | ISO/IEC 14476-5) 199 ECTP-6 ECTP part 6 (ITU-T X.608.1 | ISO/IEC 14476-6) 201 The following acronyms for ECTP-3 packets are used in this document: 203 CCR Connection Creation Request 204 CCC Connection Creation Confirm 205 TJR Tree Join Request 206 TJC Tree Join Confirm 207 DATA Data 208 NDATA Null Data 209 RDATA Retransmission Data 210 ACK Acknowledgment 211 HB Heartbeat 212 HBACK Heartbeat Acknowledgment 213 LJR Late Join Request 214 LJC Late Join Confirm 215 ULR User Leave Request 216 CTR Connection Termination Request 217 TGR Token Get Request 218 TGC Token Get Confirm 219 TRR Token Return Request 220 TRC Token Return Confirm 222 2.3. Conventions 224 In this document, the capital characters are used to represent a 225 packet of ECTP-3 (e.g., CCR for Connection Creation Request packet), 226 and the capital and italic characters are used for timers or 227 variables used in ECTP-3 (e.g., CCT for Connection Creation Timer, 228 and AGN for ACK Generation Number). 230 3. Protocol Overview 232 The Enhanced Communications Transport Protocol (ECTP) is a transport 233 protocol designed to support Internet multicast applications. ECTP 234 operates over IPv4/IPv6 networks that have the IP multicast 235 forwarding capability with the help of IGMP and IP multicast routing 236 protocols. 238 As shown in Figure 1, the ECTP shall be provisioned over UDP. 240 +-------------------------+ 241 | Multicast Applications | 242 +-------------------------+ 243 | ECTP | 244 +-------------------------+ 245 | UDP | 246 +-------------------------+ 247 | IP | 248 +-------------------------+ 250 Figure 1. ECTP Protocol Model 252 Figure 1 illustrates an example of the use of mobile SCTP for 253 seamless handover in IPv4 networks. Based on this figure, the 254 handover procedures are described in the succeeding sections. 256 This document describes the protocol specification of the ECTP part 3 257 (ECTP-3) for the duplex multicast connection. The duplex multicast 258 connection is used for supporting multicast data transport between 259 the participants that are classified into a single TC-Owner (TO) and 260 many TS-users. A duplex multicast connection supports the two types 261 of data channels between the participants: multicast data channel 262 (sent by TO toward all the other TS-users) and unicast data channel 263 (sent by a TS-user to TO). Such a TS-user is called Sending User (SU). 265 Figure 2 illustrates these two types of data transport channels used 266 in the duplex multicast connection. As shown in the figure, TO can 267 transmit multicast data to the other TS-users over IP multicast 268 (group) address. Some SUs may send unicast data to TO. The SU must 269 first get a token from the TO before sending the unicast data. 271 /-----------------------------------\ 272 | | 273 v /=============> TU (SU) 274 | 275 TO ==============================> TU 276 | 277 ^ \=============> TU (SU) 278 | | 279 \-----------------------------------/ 281 Figure 2. Data Flows in ECTP Duplex Connection 283 To establish a duplex multicast connection, TO transmits a CCR packet 284 to the group. The CCR packet contains the connection information 285 including general characteristics of the connection. In particular, 286 the CCR packet must indicate that the connection type is the duplex 287 multicast transport. Each TU who wants to participate in the 288 connection will respond to the TO with a CCC packet. The connection 289 creation operation will be completed when a pre-determined CCT timer 290 expires. 292 During the connection creation phase, a logical control tree is 293 configured between TO and TUs, or between TUs for providing the 294 scalable reliability control. With the root of the TO, the control 295 tree defines a parent-child relationship between any pair of two TUs. 296 The parent TU is called Repair Agent (RA). Based on the control tree, 297 the error recovery will be performed. To configure a control tree, 298 each TU sends a TJR message to a candidate parent node that has 299 already been connected to the tree. The parent node will respond to 300 the promising child TU with the TJC message. In this way, the control 301 tree will gradually be expanded from the root toward the leaf nodes. 303 Some of the prospective TUs may join the connection as late-joiners. 304 The late-joining TU participates in the connection by sending an LJR 305 message to TO. In response to the LJR message, TO sends an LJC 306 message to the TU. The late-joiner TU will also join the control tree 307 by using the TJR and TJC messages. For this purpose, the LJC message 308 of TO may include the information about the prospective parent RA 309 node for the late-joiner. The late-joining TU may try to connect to 310 the prospective RA node so as to configure the control tree. 312 After the connection is established, the data transmission phase 313 starts. ECTP-3 protocol supports two types of data channels: the 314 forward multicast channel from TO to the group and the backward 315 unicast channel from the TU to TO. 317 ECTP-3 also provides three kinds of reliability options: reliable 318 (error recovery), semi-reliable (partial error recovery), and 319 unreliable (no error recovery). In the reliable option, all the DATA 320 packets will be recovered by the parent on the tree. In the semi- 321 reliable option, the retransmissions of the lost packets are limited 322 by the buffer status of the parent node. That is, the parent node 323 will retransmit only the DATA packets that are at present being 324 contained in the buffer. In the unreliable option, the RDATA packets 325 are not used. It is also noted that each ACK packet does not mean any 326 retransmission request to the parent. The ACK packets are instead 327 used for monitor the receiving status of the receivers. 329 In the forward multicast data transmission, TO can begin the 330 multicast data transmission to the group by using the IP multicast 331 address and group port number. The multicast data packets sent by TO 332 will be sequentially segmented and transmitted by DATA packets to the 333 receiving TUs. The TS-users will deliver the received DATA packets to 334 the upper-layer application in the order transmitted by TO. 336 For the forward multicast data channel of TO, the error control will 337 be performed based on the local group defined by the ECTP control 338 tree. If a child TU detects a data loss, it sends a retransmission 339 request to its parent via ACK packets. Each child generates an ACK 340 packet every ACK Generation Number (AGN) data packets. That is, an 341 ACK packet is generated for the AGN data packets of TO. An ACK 342 message contains a �Bitmap� to indicate which data packets have been 343 received or not. In response to an ACK packet, each parent RA may 344 retransmit the RDATA packets to its children. 346 In the forward multicast data transport, the HB and HBACK packets are 347 used between a parent and children for the control tree maintenance. 348 A parent transmits HB packets to the children every HB Generation 349 Time (HGT). The HB contains which child must respond to this HB 350 packet with the HBACK packet. The corresponding child will send a 351 HBACK packet to the parent. The HB packet may also be used by the 352 parent to calculate the local RTT for the group. For this purpose, 353 the HB and HBACK packets contain a timestamp. The TO uses this RTT 354 information for the rate-based congestion control that is based on 355 the well-known TCP-Friendly Multicast Congestion Control (TFMCC) 356 equation. The transmission rate of TO will be adjusted based on the 357 RTT and the packet loss rate. 359 For the backward unicast data transport, a certain TU in the 360 connection may get a token from TO by sending a TGR message. The TO 361 will then respond to the TU with the TGC message that contains a 362 Token ID. Accordingly, the total number of tokens in the connection 363 is controlled by TO. The Token ID is used to identify the sender of 364 the unicast DATA packets at the TO side. The TU who has a token is 365 called Sending TU (SU). 367 The SU can send unicast DATA packets to TO. For the error recovery 368 and congestion control, the HB and HBACK packets are exchanged 369 between SU and TO. The SU sends an HB message to TO. The TO then 370 responds with the HBACK packet that contains the acknowledgement 371 information, as done in ACK packets in the forward multicast channel. 372 It is noted that the HBACK is used for retransmission request in the 373 backward channel. The SU performs the rate-based congestion control, 374 as done in the forward data channel, which is based on the RTT and 375 packet loss rate. 377 After completing the unicast data transmission, the SU will return 378 the token to the TO by sending a TRR message. TO will respond to the 379 SU with a TRC message. 381 The connection management operations are taken in the connection; 382 user leave, the connection pause and resumption, and connection 383 termination. In the User Leave operation, a participating TU may 384 leave the connection by sending a ULR message to the parent. In a 385 certain case, the parent may enforce a specific child TU to leave the 386 connection by sending the ULR message, which is called the 387 troublemaker ejection. The TO may temporarily pause and resume the 388 connection. In the connection pause period, the TO will send NDATA 389 packets to the group. 391 After the TO has completed the data transport, it may terminate the 392 duplex connection by sending a CTR message to the group. 394 4. Design Considerations 396 This section describes some considerations for the design of ECTP-3. 398 4.1. Participants 400 The participants to an ECTP-3 connection can be classified into one 401 of the following nodes: 403 TO (TC-Owner) 405 ECTP-3 connection has a single TO. The TO is responsible for the 406 overall operations required for connection management including 407 connection creation and termination, control tree creation, late join, 408 and connection maintenance. TO is also a single sender of the forward 409 multicast data channel. Only the TO is allowed for sending the 410 original multicast data to the other participants. 412 TU (TS-User) 414 An ECTP-3 connection has one or more TUs. Each of them receives 415 multicast data from TO. 417 RA (Repair Agent) 419 In the ECTP-3 connection, an RA is a TU who is responsible for error 420 recovery to the local group by retransmission of data. On the control 421 tree hierarchy of ECTP-3, an RA is a parent node and has its children 422 nodes. Note that an RA is also a TU. That is, an RA also receives 423 multicast data from TO. In ECTP-3, a TU may act as an RA in the 424 connection, or some designated RAs may be used for the error recovery 425 in the connection. It depends on the deployment of ECTP-3. 427 SU (Sending TS-User) 429 An SU is a TU who can send unicast data to TO. In ECTP-3 connection, 430 a TU becomes an SU when it has a token and it can thus transmit 431 unicast data to TO. 433 4.2. Control Tree 435 An ECTP-3 connection may configure a control tree for scalable 436 reliability control as follows. 438 TO 439 ^^^ 440 / | \ 441 ACKs / | \ 442 / | \ 443 / | \ 444 / | \ 445 / | \ 446 RA RA RA 447 ^^ ^^^ ^^ 448 / | / | \ | \ 449 / | / | \ | \ 450 / | / | \ | \ 451 TU TU TU TU TU TU TU 453 Figure 3. ECTP-3 Control Tree 455 In the ECTP-3 control tree, TO is on the top of the tree, which is in 456 the Tree Level 0. RA is a parent node on the tree and has one or more 457 children. The TU nodes, not designated as RA, cannot have its 458 children. Such a control tree will be configured in the connection 459 creation phase. 461 Error recovery in ECTP-3 will be performed within each local group 462 defined by the control tree. A child can request retransmission to 463 its parent RA. In response to the request, the parent RA will 464 retransmit the data packets to the children, if it has them in the 465 buffer. An RA is also a TU, and it thus receives the multicast data 466 from the TO. The control tree is applied only for forward multicast 467 data channel. The control tree does not apply to the backward unicast 468 data channel. 470 4.3. Data Channels 472 In ECTP-3, the two types of data channels are used: forward and 473 backward data channels. 475 Forward Data Channel 477 The forward data channel is used for TO to send multicast data to the 478 other TUs. The forward data channel can also be used for an RA to 479 send Retransmission Data to its children TUs. 481 The forward data channel address consists of the group (multicast) IP 482 address and the group port. TO sends multicast data via DATA packets 483 by using the forward data channel address. TO and RAs can also 484 retransmit multicast data via RDATA packets by using the forward data 485 channel address. 487 The following figure illustrates the use of the forward multicast 488 data channels in ECTP-3. 490 Backward Data Channel 492 The backward data channel is used by an SU to send unicast datat to 493 TO. The backward channel address consists of the IP address of TO and 494 the �group� port. 495 The following figure illustrates the use of the backward unicast data 496 channels in ECTP-3. 498 Each SU must send unicast data via DATA and RDATA packets to TO by 499 using this backward data channel address as the destination address. 500 On the other hand, TO must bind its backward data channel address to 501 receive the unicast data from any SU in the connection. 503 4.4. Addressing 505 In ECTP-3, each packet uses the following types of IP addresses and 506 port number for its source and destination address: 508 - Group IP address and Local IP address; 509 - Group port and Local port. 511 Group and Local IP Addresses 513 The group IP address is the IP multicast address (e.g., Class D 514 address for IPv4), whereas a local IP address represents the unicast 515 IP address for each of the ECTP participants: TO, RAs and TUs. 516 The group IP address is used as the destination address of the 517 packets that need to be multicast by TO and RAs. For example, the CCR 518 and DATA packets of TO will use the group IP address as the 519 destination address of the associated IP packets. Each RA also uses 520 the group IP address as the destination address of the RDATA and HB 521 packets. 523 The local IP address of each participant is used as the source and 524 destination IP address for the unicast packets, and also the source 525 address for the multicast packets. 527 It is noted that the group IP address and the local IP address of TO 528 must be announced to all the prospective participants via an out-of- 529 band signaling such as Web announcement. 531 Group and Local Ports 533 The group port represents the port number that has been announced to 534 all of the ECTP-3 participants before the connection. In ECTP-3, the 535 group port will typically be used as the �destination port� of the 536 ECTP-3 multicast packets transmitted by TO or RAs, such as CCR and 537 DATA. That is, each TU should bind to the group IP address and port 538 so as to receive the relevant ECTP-3 multicast packets. 540 The group port number is also used by SU to send unicast data to TO. 541 That is, TO will bind to the local port with its local IP address so 542 as to receive the unicast data from any SU. In particular, the group 543 port is also used as the destination port of the packet that requests 544 a certain action, such as LJR. 546 On the other hand, in the other cases that are not described above, 547 the ECTP-3 packet will use the local port number as source and/or 548 destination ports. For example, in response to the Late Join Request 549 from a TU, the TO will respond with the Late Join Confirm message 550 that use the local port of the TU as the destination port. 551 The detailed use of the local IP address and port will be specified 552 for each of the ECTP-3 packets in the later section. 554 Addresses of Data Channels 556 In ECTP-3, all the data packets use the group port number as the 557 destination port. Accordingly, before the connection creation, the 558 following information must be announced to all of the ECTP-3 559 participants via an out-of-band signaling such as Web announcement. 561 - Group IP address and Group port; 562 - Local IP address of TO. 564 The following figure describes the use of IP address and port for the 565 forward and backward data channels. The forward multicast data 566 packets use the group IP address and port number as the destination 567 address of the data packets, whereas the backward data packets use 568 the local IP address of TO and the group port number as the 569 destination address. 571 4.5. Tokens 573 In ECTP-3, a token represents the right for a TU to send a unicast 574 data to TO. Before transmitting the data, each TS-user must get a 575 token from the TO, as per the Token Control procedures of ECTP-3. 577 Each token is represented as a 1-byte non-negative integer in ECTP-3. 578 Such a token number (or Token ID) will be assigned by TO when a TU 579 requests a token in the connection. Token ID is ranged between 1 and 580 255. The Token ID of �0� is reserved for use of TO. At the TO side, 581 the Token ID can be used to identify who is sending the unicast data. 583 5. Packets 585 An ECTP packet contains a 16-byte base header together with either 586 extension elements or user data. It is noted that the data packets do 587 not include any extension elements. 589 In this section, we give a brief sketch of the ECTP-3 packet format. 590 More detailed description on the packet format is given in [6]. 592 5.1. Base Header 594 The 16-byte base header contains the information helpful to all the 595 protocol operations, in particular for the data packets. 597 The base header contains the following information: 599 Next Element (4 bits) 601 This specifies the type of the extension element immediately 602 following the base header. The encoding values of the extension 603 elements will be described later. The extension element value of 604 �0000� means that the next part of this packet contains the user data, 605 if any. 607 Version (2 bits) 609 This defines the version of the ECTP-3 protocol. Its current version 610 is encoded as �00�. 612 CT (Connection Type): (2 bits) 613 This specifies the type of the ECTP connection. The encoding value 614 for the connection type is as follows: 616 01 � simplex multicast connection (for ECTP-1 and ECTP-2); 617 10 � duplex multicast connection (for ECTP-3 and ECTP-4); 618 11 � N-lex multicast connection (for ECTP-5 and ECTP-6); 620 The value 00 is reserved for future use. In this ECTP-3 specification, 621 the CT must be set as 10. It is noted that this definition is 622 compatible with the specifications of ECTP-1 and ECTP-2. 624 Packet Type (8 bits) 626 It indicates the type of this ECTP-3 packet. The encoding values of 627 the ECTP-3 packets will be described later. 629 Checksum (16 bits) 631 This is used to check the validity of the ECTP-3 packet that includes 632 the base header, extension header and/or user data. The ECTP-3 633 checksum is calculated by using the conventional complement 634 arithmetic operation, as done in TCP and UDP. 636 Connection ID (32 bits) 638 The Connection ID is used to identify an ECTP connection by the ECTP 639 host. It may also be used to verify the connection. In the connection 640 setup phase, this information must first be informed by TO to the 641 other participants via the CCR or LJC packets. All the otherECTP-3 642 packets must set this field to be the value announced by TO. 644 PSN (32 bits) 646 This value represents the sequence number of the data packet for the 647 ECTP-3 DATA or RDATA packets. For some control packets such as NDATA 648 or HB packets, this value has a different semantic, which will be 649 described later. For the other control packets, it is ignored. This 650 sequence number is a 32-bit unsigned number that starts with the 651 initial sequence number and increases by 1, and wraps back around to 652 1 after reaching 232-1. 654 Payload Length (16 bits) 656 This value indicates the total length of the extension headers or 657 user data in byte, following the base header. 659 F (1 bit) 661 It is a flag bit. The use of this flag depends on the packet types: 663 For the LJC (Late Join Confirm), TJC (Tree Join Confirm), Token 664 Get Confirm (TGC), Token Return Confirm (TRC) packets, the F = 1 665 indicates that each of the corresponding join request is accepted. 666 F is set to 0, otherwise; 668 For the ULR (User Leave Request) packet, F is set to 1 for the 669 user-invoked leave, or set to 0 for the troublemaker ejection; 670 For the CTR (Connection Termination Request) packet, F is set to 671 1 for an abnormal termination, or set to 0 for the normal 672 termination after all the data have been transmitted; 674 For the token control operations, TGR and TRR request messages 675 use this flag so as to indicate whether this is the TO-initiated 676 or TU-initiated token control. 678 For the other packets, the detailed description is given in the 679 protocol procedure section. Otherwise, if any usage is not specified, 680 this field will be ignored. 682 Reserved (7 bit) 684 This field is reserved for future use. 686 Token ID (8 bit) 688 The Token ID is valid only for data packets: DATA and RDATA packets. 689 This represents who is the source of the data packets. The Token ID 690 value is ranged between 0 and 255. Each SU receives a Token ID from 691 TO via the token get procedure and sets this field to be the number 692 assigned by TO. The forward multicast data packets of TO set this 693 field to be �0�. 695 5.2. Extension Elements 697 The ECTP packets used for control may contain one or more extension 698 elements along with the base header. The based header and each 699 extension element has the field of Next Element that points to the 700 immediately succeeding extension element, if any. 702 The Next Element field is encoded as shown in the following table. It 703 is noted that the 0000 means No Element. Accordingly, the last 704 extension element of an ECTP packet must set its Next Element field 705 to �0000�. 707 Table 1. Extension Elements 709 +-------------------+---------+-----------------+ 710 | Extension Element | Encoding| Length (bytes) | 711 +-------------------+---------+-----------------+ 712 | End of Element | 0000 | 0 | 713 +-------------------+---------+-----------------+ 714 | Connection | 0001 | 4 | 715 +-------------------+---------+-----------------+ 716 | Acknowledgement | 0010 | Variable | 717 +-------------------+---------+-----------------+ 718 | Membership | 0011 | 4 | 719 +-------------------+---------+-----------------+ 720 | Timestamp Report | 0100 | 12 | 721 +-------------------+---------+-----------------+ 722 | IP Address | 0101 | 8 or 20 | 723 +-------------------+---------+-----------------+ 725 It is noted that all the extension elements other than Address 726 element have already been defined in ECTP-1 and ECTP-2. Accordingly, 727 the encoding values of those extension elements will be reused in 728 ECTP-3. It is noted that the encoding value of 0101 is reserved for 729 the QoS extension element, which is not used in ECTP-3, and may be 730 defined for the QoS management in ECTP-4. 732 All the extension elements described in the table will be defined in 733 this section by encompassing the requirements for the ECTP-3 protocol. 735 Connection Element 737 The connection extension element contains overall information on the 738 ECTP-3 transport connection. It is encoded as 0001 in the Next 739 Element field of the preceding element or based header. This 740 extension element must be included in the CCR, LJC and TGR packets. 742 Acknowledgement Element 744 This extension element provides information on the status of the 745 packet reception at the child node, which will be referred to by the 746 parent node for the error, flow and congestion control. This 747 extension header is attached to the ACK packet. It is encoded as 748 �0010� in the Next Element field of the preceding element or based 749 header. 751 Membership Element 752 This 4-byte extension element contains information on the tree 753 membership. It is encoded as 0011 in the Next Element field of the 754 preceding element or based header. 756 Timestamp Element 758 The Timestamp element is encoded as 0100 in the Next Element field of 759 the preceding element or based header. The ECTP-3 uses the 8-byte 760 timestamp so as to calculate Round Trip Time (RTT). 762 Address Element 764 The Address extension element is encoded as 0110 in the Next Element 765 field of the preceding element or based header. This element is 766 attached to the packet when the protocol needs to specify the IPv4 or 767 IPv6 address of the participant concerned. For example, the LJC 768 packet of TO may include this element so as to inform a late-joining 769 TU about the IP address of the promising RA that the TU may connect. 771 5.3. Packet Format 773 ECTP-3 defines the total 18 packet types: 3 types of data packets and 774 15 types of control packets. The following table summarizes the 775 packets used in ECTP-3. 777 Table 2. ECTP-3 Packets 779 +----------------------------+-------+----------+-----------+---+ 780 | Full Name |Acronym| From | To |M/U| 781 +----------------------------+-------+----------+-----------+---+ 782 |Connection Creation Request | CCR | TO | TUs | M | 783 +----------------------------+-------+----------+-----------+---+ 784 |Connection Creation Confirm | CCC | TU | TO | U | 785 +----------------------------+-------+----------+-----------+---+ 786 | Tree Join Request | TJR | Child | Parent | U | 787 +----------------------------+-------+----------+-----------+---+ 788 | Tree Join Confirm | TJC | Parent | Child | U | 789 +----------------------------+-------+----------+-----------+---+ 790 | Data | DATA | TO/SU | TUs/TO |M/U| 791 +----------------------------+-------+----------+-----------+---+ 792 | Null Data | NDATA | TO | TUs | M | 793 +----------------------------+-------+----------+-----------+---+ 794 | Retransmission Data | RDATA |Parent/SU |Children/TO|M/U| 795 +----------------------------+-------+----------+-----------+---+ 796 | Acknowledgement | ACK | Child | Parent | U | 797 +----------------------------+-------+----------+-----------+---+ 798 | Heartbeat | HB |Parent/SU |Children/TO|M/U| 799 +----------------------------+-------+----------+-----------+---+ 800 | Heartbeat ACK | HBACK | Child/TO | Parent/SU | U | 801 +----------------------------+-------+----------+-----------+---+ 802 | Late Join Request | LJR | TU | TO | U | 803 +----------------------------+-------+----------+-----------+---+ 804 | Late Join Confirm | LJC | TO | TU | U | 805 +----------------------------+-------+----------+-----------+---+ 806 | User Leave Request | ULR |Child/Par.|Par./Child | U | 807 +----------------------------+-------+----------+-----------+---+ 808 | Connection Term. Request | CTR | TO | TUs | M | 809 +----------------------------+-------+----------+-----------+---+ 810 | Token Get Request | TGR | SU | TO | U | 811 +----------------------------+-------+----------+-----------+---+ 812 | Token Get Confirm | TGC | TO | SU | U | 813 +----------------------------+-------+----------+-----------+---+ 814 | Token Return Request | TRR | SU | TO | U | 815 +----------------------------+-------+----------+-----------+---+ 816 | Token Return Confirm | TRC | TO | SU | U | 817 +----------------------------+-------+----------+-----------+---+ 819 (*) In the table, M/U means Multicast and Unicast. 821 In the table, the parent node represents TO or RA, and the packets 822 used for token control can be initiated by SU as well as TO. As also 823 shown in the table, all of the ECTP-3 packets are exchanged between 824 the participants in the request-and-conform manner. For example, the 825 CCR request expects to receive the corresponding CCC confirm message. 826 The ACK messages will be used to confirm the DATA and RDATA messages. 827 On the other hand, ULR and CTR messages do not require any responding 828 confirm messages. 830 6. Procedures 832 This section describes the protocol procedures of ECTP-3. Before an 833 ECTP-3 connection is created, the following address information 834 should be announced to the prospective participants: TU and RA. 836 - Multicast IP address of the group 837 - Group port number 838 - IP address of TO 840 This information may be announced to the prospective participants via 841 an out-of-band signaling mechanism such as Web announcement. 842 Accordingly, the prospective TU should be able to bind the group IP 843 address and port so as to receive the CCR packet from the TO. A 844 prospective late-joiner TU should also send a LJR packet to the TO. 846 6.1. Connection Creation 848 An ECTP-3 connection will begin when TO sends the first ECTP-packet, 849 CCR, to the group over the multicast group IP address and port. An 850 ECTP-3 control tree is also configured in the connection creation 851 phase. 853 TO begins the connection creation operation by sending the CCR packet 854 to the group. The CCR packet contains the generic information on the 855 connection element such as TCO (Tree Configuration Option), RO 856 (Reliability Option), and MSS (Maximum Segment Size). 858 After sending the CCR packet, TO starts the CCT (Connection Creation 859 Timer). Only the CCC packets will be allowed during the CCT timer. 860 Each TU should join the control tree before responding with a CCC 861 packet. In the connection creation phase, each TU can join only the 862 TO as the parent. 864 To join the control tree, each TU sends a TJR packet to TO. TO then 865 responds to the TU with the TJC packet. The TJC packet should 866 indicate whether the tree join request is accepted or not by using 867 the F flag of the base header. 869 The TJC packet should also contain the Child ID and Tree Level in the 870 membership element. The TJC packet may optionally contain the address 871 element to represent a promising parent RA for the TU. It needs to 872 ensure that the parent RA has already been on the tree. 874 6.2. Late Join 876 Some of the prospective participants may join the ECTP-3 connection 877 as a late joiner. In particular, any TU is allowed to join the 878 connection as a late joiner, after the CCT timer expires. 880 The late joiner TU sends an LJR packet to TO. In response to the LJR 881 packet, the TO sends an LJC packet to the TU, which should indicate 882 that the request is accepted or not by using the F flag of the base 883 header. 885 The LJC packet should contain the connection element. It may also 886 contain the address element so as to recommend the promising parent 887 RA for the TU. If no address element is indicated the TU may try to 888 join the TO in the control tree configuration. 890 If the LJC packet does not arrive within the RXT (Retransmission 891 Timeout), the late joiner may try to send the LJR packet again. 893 To join the control tree, the TU should send a TJR packet to the 894 promising parent RA, as indicated by TO via the LJC packet, or to the 895 parent TO. The TO then responds with the TJC packet to the TU. 896 If the TJC packet does not arrive within the RXT, the late joiner may 897 try to send the TJR packet again. 899 In this way, the ECTP-3 control tree will be configured in the 900 hierarchical manner. 902 6.3. Forward Data Transport 904 In the ECTP-3 forward data channel, the TO sends multicast DATA 905 packets to the group. When a data packet loss is detected by the 906 receiving TU, the retransmission for error recovery will be performed 907 within a local group that is defined by the control tree. 909 On the other hand, ECTP-3 provides three kinds of Reliability Option 910 (RO) for error control operations: reliable, semi-reliable, and 911 unreliable. The semantics of the RO are as follows: 913 1) Reliable Transport (error recovery) 915 In the reliable option, all the DATA packets will be recovered by 916 the parent on the tree. Each child requests the retransmission 917 via ACK packet, and the parent sends the corresponding RDATA 918 packet over the multicast address. 920 2) Semi-reliable Transport (partial error recovery) 922 In the semi-reliable option, the retransmissions of the lost 923 packets are limited by the buffer status of the parent node. That 924 is, the parent node will retransmit only the DATA packets that 925 are at present being contained in the buffer. It is noted that 926 the parent node need not keep all the DATA packets in the buffer. 927 The parent will rather delete the old DATA packets from the 928 buffer, which have not been acknowledged by the children. 930 It is noted in the semi-reliable option that the parent should 931 announce its children about which DATA packets could be recovered 932 in the error recovery. For this purpose, the parent node will use 933 the periodic HB packets. Specifically, the PSN filed of the base 934 header of the HB packet will indicate the lowest sequence number 935 of DATA packets that are contained in the buffer. 937 3) Unreliable Transport (no error recovery) 939 In the unreliable option, the RDATA packets are not used. It is 940 also noted that each ACK packet does not mean any retransmission 941 request to the parent. The ACK packets are instead used by the 942 parent to monitor the status of the connection such as ADN. 944 After the connection creation, the TO can send multicast DATA packets 945 to the group members. 947 TO will generate DATA packets by the segmentation procedure. To do 948 this, TO splits a multicast data stream of application into multiple 949 DATA packets. Each DATA packet has its own sequence number. When TO 950 has no data to transmit, TO may transmit the periodic NDATA packets 951 in the connection pause period. 953 Each TU delivers all the data packets received to the application in 954 the order sent by TO. Each receiver reassembles the received packets. 955 Corrupted and lost packets are detected by using a checksum and 956 sequence number. A corrupted packet is also considered as a loss. The 957 lost DATA packets are recovered in the error control function. 959 ECTP-3 uses the flow control based on a fixed-size window. The window 960 size represents the number of unacknowledged data packets in the 961 sending buffer. TO can maximally transmit the window size of data 962 packets at the configured data transmission rate. In ECTP-3, the 963 transmission rate of multicast data is controlled by the rate-based 964 congestion control mechanisms. 966 A new DATA packet is sequentially numbered by TO. The sequence number 967 of the DATA packet starts from Initial PSN and increases by 1. The 968 sequence number is used to detect lost data packets by receivers. The 969 Initial PSN is randomly generated other than 0. The sequence number 970 of 0 is reserved. The packet sequence number is increased for each 971 new DATA packet. Modulo 232 arithmetic is used and the sequence 972 number wraps back around to 1 after reaching <232 � 1>. The Initial 973 PSN number will be informed to the TUs by way of CCR or LJC packet. 975 6.4. Reliability Control for Reliable Transport 977 When the reliability option for the connection indicates Reliable (RO 978 = 10), all the DATA packets should be recovered in the error recovery 979 operations. 981 Error Detection 983 The checksum field of the base header is used for detection of packet 984 corruption, and the PSN field is for detection of a packet loss. When 985 a data packet is received, each receiver examines the checksum. If 986 the checksum field is invalid, the packet is regarded as a corruption 987 and shall be discarded. A corruption is treated as a loss. The loss 988 can be detected as a gap of two consecutive sequence numbers for DATA 989 packets. The loss information is recorded into the ACK bitmap, which 990 is attached to the subsequent ACK packets. 992 ACK packets are used for the retransmission requests. When a receiver 993 detects a gap in the sequence numbers of received packets, it sets to 994 zero the bit of the ACK bitmap that corresponds to the lost DATA 995 packet. The ACK bitmap is included into the acknowledgement element, 996 which is attached to the subsequent ACK packet and delivered to the 997 parent by the ACK generation mechanisms. 999 For a local group, a parent and its children maintain the Lowest 1000 Sequence Number (LSN) variables to determine the status of DATA 1001 packets. For a child, the LSN represents the sequence number of the 1002 lowest numbered DATA packet that the child has not received. For a 1003 parent, the LSN represents the sequence number of the lowest numbered 1004 DT packet that has not been acknowledged by its children. 1006 To request the retransmissions of lost data, each child makes an 1007 acknowledgement element containing the LSN, Valid Bitmap Length and 1008 ACK Bitmap. The ACK Bitmap specifies a success or a failure of a 1009 packet delivery for each DATA packet; 1 for success and 0 for failure. 1010 Suppose Bitmap = 01101111, LSN = 15. Then the DATA packets with the 1011 sequence number 15 and 18 are lost. 1013 Retransmission Request by ACK Generation 1015 Each child generates an ACK packet by ACK Generation Number (AGN). 1016 Each child sends an ACK packet to its parent every AGN number of 1017 packets. To do this, a child receives a Child ID from its parent in 1018 tree configuration, which is contained in the tree membership element 1019 of the TJC packet. 1021 Each child sends an ACK packet to its parent, if the PSN number of a 1022 DATA packet modulo AGN equals Child ID modulo AGN, i.e., if 1024 PSN % AGN = Child ID % AGN. 1026 Suppose AGN = 8 and Child ID = 2. The child generates an ACK packet 1027 for the DT packets whose sequence numbers are 2, 10, 18, 26, etc. 1028 This ACK generation rule is applied when the corresponding DT packet 1029 is received or detected as a loss by the child. 1031 Retransmissions and ACK Aggregation by RA 1033 Each parent uses ACK packets to gather status information for the 1034 error recovery. Each time a parent receives an ACK packet from any of 1035 its children, it records and updates the status information on which 1036 packets have been successfully received by its children. 1038 A DATA packet is defined as a �stable� packet if all of the children 1039 have received it. The stable DATA packets are released out of the 1040 buffer memory of the parent. When a parent receives an ACK packet 1041 from one of its children, if one or more packet losses are indicated, 1042 the parent transmits the corresponding RDATA packets to all of its 1043 children over its multicast control address. 1045 After a parent retransmits an RDATA packet, it will ignore any 1046 subsequent retransmission requests for the same packet during the RXT 1047 period. 1049 An ACK packet contains information on the number of active 1050 descendants (ADN). The parent aggregates the ADN variables for all of 1051 its children, and sends the aggregated information to its parent 1052 (when it sends an ACK to the parent. 1054 6.5. Control Tree Maintenance 1056 The ECTP-3 control tree is maintained using the HB and HBACK packets. 1057 Each parent RA advertises periodic HB packets using Heartbeat 1058 Generation Time (HGT), after it becomes an on-tree node. The default 1059 HGT is 3 second. The HB packet contains the information (Child ID of 1060 the membership element) about which child should respond to this HB 1061 packet. The corresponding child should respond with the HBACK packet. 1063 In ECTP-3, the exchange of HB and HBACK packets between a parent and 1064 children is done with the following three purposes: 1066 1) Check whether the tree node is still alive 1068 A child detects the failure of its parent, if it cannot receive 1069 any packets such as HB and RDATA packets from the parent during 1070 the time interval of FDN (Failure Detection Number) x Heartbeat 1071 Generation Time (HGT). Then the child begins to find an alternate 1072 parent. The default FDN is 3. 1074 A parent detects the failure of a child, if it cannot hear any 1075 HBACK packets from the child for the FDN consecutive HB packets. 1076 If a child is detected as a failure, the parent sends an ULR 1077 packet (for troublemaker ejection) to the failed child, and 1078 clears the child out of its children list. 1080 2) Information on DATA packets that can be recovered 1082 The HB packet of the parent contains the information in the PSN 1083 field of the header, which represents the lowest sequence number 1084 of DATA packet that is contained in the buffer. This information 1085 will be referred to by the children in the ACK generation. 1087 3) Calculation of local RTT 1089 On the other hand, the HB and HBACK can also be used for 1090 calculate the Round Trip Time (RTT) for a local group. A parent 1091 RA sends a HB packet containing a timestamp element to its 1092 children every HGT interval. The corresponding child will also 1093 contain the timestamp element as it is in the HBACK packet. 1095 Receiving an HBACK packet from a child, the parent RA calculates 1096 the RTT by subtracting Timestamp from the current time. The RTT 1097 is recorded into the children list. The parent determines the 1098 Local RTT by the maxim RTT value for its children. 1100 6.6. Congestion Control for Forward Data Channel 1102 For the forward multicast data transport, the congestion control will 1103 be done by TO to adjust the data transmission rate. The adjustment of 1104 transmission rate of TO is controlled based on the packet loss rate 1105 and the RTT for the local group. The RTT for the local group may be 1106 calculated using the HB and HBACK packets. 1108 The congestion control algorithm (i.e., the algorithm for 1109 transmission rate adjustment of TO) follows the well-known TCP- 1110 Friendly Multicast Congestion Control (TFMCC) algorithm, which has 1111 been developed in the IETF RMT WG. The TFMCC algorithm is featured 1112 by: 1114 �TFMCC is a congestion control mechanism for multicast 1115 transmissions in a best-effort Internet environment. It is a 1116 single-rate congestion control scheme, where the sending rate is 1117 adapted to the receiver experiencing the worst network conditions. 1118 TFMCC is reasonably fair when competing for bandwidth with TCP 1119 flows and has a relatively low variation of throughput over time, 1120 making it suitable for applications such as streaming media where a 1121 relatively smooth sending rate is of importance.� 1123 In ECTP-3, the TO will calculate the sending rate X, which is based 1124 on the s (MSS), R (local RTT), and p (packet loss rate). It is noted 1125 that the packet loss rate will be determined by TO as �the number of 1126 loss events as a fraction of the number of packets transmitted.� The 1127 RTT will also be calculated in the Control Tree Maintenance operation. 1128 TO will take the maximum value of the RTTs and packet loss rate that 1129 have been reported from its children. 1131 6.7. Token Control 1133 In ECTP-3, a token represents the right to send a data to the TO in 1134 the backward unicast data channel. Each TU who wants to transmit a 1135 data to TO must get a token from the TO. The TU will be an SU after 1136 getting a token from TO. In this way, TO can control the maximum 1137 number of tokens simultaneously active for the connection. 1139 An SU returns the token after completing the unicast data 1140 transmission to TO. 1142 The TU can get a token from TO. In this Token Get operation, the TU 1143 first requests a token to TO. The following figure shows the 1144 operations for Token Get. 1146 To get a token in the Token Get operation, a TU sends a TGR message 1147 to TO, and then waits for the corresponding TGC message. In response 1148 to the TGR packet, the TO should send a TGC message to the TU. The 1149 TGC message should indicate whether the request is accepted or not by 1150 using the F flag of the base header. In case of the acceptance, the 1151 message will also contain a valid Token ID and Initial PSN in the 1152 base header. If the responding TGC message has not arrived until the 1153 RTO timer expires, the TU may send the TGR message again. 1155 The TU (i.e., SU) should respond with the TGC message that sets the F 1156 flag to �0� (acceptance). If the responding TGC message has not 1157 arrived from the SU until the RTO timer expires, the TO may send the 1158 TGR message to SU again. 1160 When completing data transmission, the SU may return the token to TO. 1161 The SU can return its token to TO. In this Token Return operation, 1162 the TU sends the TRR packet to TO. 1164 In the Token Return case, the SU sends a TRR message to TO. The TO 1165 then responds with the TRC message. On the other hand, in the Token 1166 Withdrawal case, the TO may enforce the concerned SU to return the 1167 token by sending a TRR message. If the responding TRC message has not 1168 arrived until the RTO timer expires, the TRR message may be sent 1169 again. 1171 6.8. Backward Data Transport 1173 After getting a token from TO, an SU can transmit unicast DATA 1174 packets to TO. 1175 In the backward unicast data channel, the initial sequence number 1176 (ISN) of SU is indicated in the PSN field of the header of the TGR 1177 (in the Token Get case) or TGC (in the Token Give case). The ISN is 1178 randomly generated other than �0�, as done in the forward data 1179 channel. 1181 The DATA packets transmitted by SU must indicate the Token ID that is 1182 allocated by TO. 1184 The reliability control for the unicast data channel will be done 1185 between SU and TO. In the data transmission phase, the SU sends a HB 1186 packet to the TO every HGT time interval. The TO should respond with 1187 the HBACK packet to the SU. The HBACK packet may indicate the 1188 retransmission request in the Acknowledgement element. In this case, 1189 the SU sends the corresponding RDATA packet. 1191 The HB and HBACK packet will also be used to calculate the RTT 1192 between SU and TO. 1194 The congestion control (sending rate adjustment) of SU is performed, 1195 as done in the forward data channel. Based on the packet loss rate 1196 and RTT, the SU calculate the transmission rate. 1198 6.9. Connection Management 1200 In the User Leave case, the child node will send a ULR message to its 1201 parent (RA or TO). In the Troublemaker Ejection case, the parent will 1202 request the concerned child to leave the connection. In both cases, 1203 the ULR message does not require the corresponding confirm message. 1204 It is noted that the User Leave operation is performed between a 1205 parent and a child over the control tree, rather than between TO and 1206 TU. The troublemaker ejection may be applied to the child that has 1207 not been responding during a certain time interval in the HB and 1208 HBACK operation for tree maintenance. It is not recommended to apply 1209 the troublemaker ejection to an RA node that has one or more children. 1211 In ECTP-3, the TO may pause the connection temporarily for a certain 1212 reason. For example, when it has no user data to transmit, the TO may 1213 pause the connection. The connection may also resume. During the 1214 connection pause period, the TO may send NDATA packet. The TO may 1215 also terminate the connection when it has completed the data 1216 transmission. The TO performs the connection termination by sending a 1217 CTR message to the group. 1219 7. Security Considerations 1221 TBD 1223 8. IANA Considerations 1225 TBD 1227 9. Acknowledgments 1229 This document was prepared using 2-Word-v2.0.template.dot. 1231 10. References 1233 10.1. Normative References 1235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1236 Requirement Levels", BCP 14, RFC 2119, March 1997. 1238 10.2. Informative References 1240 [1] ITU-T Recommendation X.601 (2000), Multi-Peer Communications 1241 Framework 1243 [2] ITU-T Recommendation X.602 (2004) | ISO/IEC 16511: 2005, 1244 Information Technology � Group Management Protocol (GMP) 1246 [3] ITU-T Recommendation X.605 (1998) | ISO/IEC 13252: 1999, 1247 Information Technology � Enhanced Communications Transport 1248 Service Definition 1250 [4] ITU-T Recommendation X.606 (2001) | ISO/IEC 14476-1: 2002, 1251 Information Technology � Enhanced Communications Transport 1252 Protocol: Specification of simplex multicast transport (ECTP-1) 1254 [5] ITU-T Recommendation X.606.1 (2002) | ISO/IEC 14476-2: 2003, 1255 Information Technology � Enhanced Communications Transport 1256 Protocol: Specification of QoS Management for Simplex Multicast 1257 Transport (ECTP-2) 1259 [6] ITU-T Recommendation X.607 (2007) | ISO/IEC 14476-3:2007, 1260 Information Technology � Enhanced Communications Transport 1261 Protocol: Specification of Duplex Multicast Transport (ECTP-3) 1263 Author's Addresses 1265 Seok Joo Koh 1266 Kyungpook National University, KOREA 1268 sjkoh@knu.ac.kr 1270 Dae Young Kim 1271 Chungnam National University, KOREA 1273 dykim@cnu.ac.kr 1275 Intellectual Property Statement 1277 The IETF takes no position regarding the validity or scope of any 1278 Intellectual Property Rights or other rights that might be claimed to 1279 pertain to the implementation or use of the technology described in 1280 this document or the extent to which any license under such rights 1281 might or might not be available; nor does it represent that it has 1282 made any independent effort to identify any such rights. Information 1283 on the procedures with respect to rights in RFC documents can be 1284 found in BCP 78 and BCP 79. 1286 Copies of IPR disclosures made to the IETF Secretariat and any 1287 assurances of licenses to be made available, or the result of an 1288 attempt made to obtain a general license or permission for the use of 1289 such proprietary rights by implementers or users of this 1290 specification can be obtained from the IETF on-line IPR repository at 1291 http://www.ietf.org/ipr. 1293 The IETF invites any interested party to bring to its attention any 1294 copyrights, patents or patent applications, or other proprietary 1295 rights that may cover technology that may be required to implement 1296 this standard. Please address the information to the IETF at 1297 ietf-ipr@ietf.org. 1299 Disclaimer of Validity 1301 This document and the information contained herein are provided on an 1302 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1303 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1304 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1305 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1306 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1307 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1309 Copyright Statement 1311 Copyright (C) The IETF Trust (2007). 1313 This document is subject to the rights, licenses and restrictions 1314 contained in BCP 78, and except as set forth therein, the authors 1315 retain all their rights. 1317 Acknowledgment 1319 Funding for the RFC Editor function is currently provided by the 1320 Internet Society.