Internet Draft Dae Young Kim Intended status: Informational Chungnam National University Expires: October 2007 Seok Joo Koh April 18, 2007 Kyungpook National University Enhanced Communications Transport Protocol for One-to-Many Multicast Applications with Unicast Reverse Data Channels Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may only be posted in an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October 18, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Kim and Koh Expires October 18, 2007 [Page 1] Internet-Draft ECTP for Duplex Multicast Transport April 2007 Abstract This document is a part of the ITU-T Recommendation and ISO/IEC International Standard, named the Enhanced Communications Transport Protocol (ECTP), which is a multicast transport protocol designed to support Internet multicast applications. This third part of ECTP (ECTP-3) describes the protocol specification for the duplex multicast transport. In a duplex connection, a single multicast sender, named TC-Owner (TO), transmits multicast data to the other group members, while some of the participating TS-users may send unicast data to the TO over the reverse data channel. Kim and Koh Expires October 18, 2007 [Page 2] Internet-Draft ECTP for Duplex Multicast Transport April 2007 Table of Contents 1. Introduction................................................4 2. Terminology.................................................5 2.1. Definitions............................................5 2.2. Abbreviations..........................................6 2.3. Conventions............................................6 3. Protocol Overview...........................................7 4. Design Considerations.......................................11 4.1. Participants..........................................11 4.2. Control Tree..........................................11 4.3. Data Channels.........................................12 4.4. Addressing............................................13 4.5. Tokens................................................15 5. Packets....................................................15 5.1. Base Header...........................................15 5.2. Extension Elements.....................................17 5.3. Packet Format.........................................19 6. Procedures.................................................21 6.1. Connection Creation....................................21 6.2. Late Join.............................................22 6.3. Forward Data Transport.................................22 6.4. Reliability Control for Reliable Transport.............24 6.5. Control Tree Maintenance...............................26 6.6. Congestion Control for Forward Data Channel............27 6.7. Token Control.........................................27 6.8. Backward Data Transport................................28 6.9. Connection Management..................................29 7. Security Considerations.....................................29 8. IANA Considerations........................................29 9. Acknowledgments............................................29 10. References................................................30 10.1. Normative References..................................30 10.2. Informative References................................30 Author's Addresses............................................30 Intellectual Property Statement................................30 Disclaimer of Validity........................................30 Kim and Koh Expires October 18, 2007 [Page 3] Internet-Draft ECTP for Duplex Multicast Transport April 2007 1. Introduction This document (Recommendation | International Standard) specifies the Enhanced Communications Transport Protocol (ECTP), which is a transport protocol designed to support Internet multicast applications running over multicast-capable networks. ECTP shall be provisioned over UDP. ECTP is designed to support tightly controlled multicast connections in simplex, duplex and N-plex applications. This part of ECTP (part 3: ITU-T X.607 | ISO/IEC 14476-3) specifies the protocol mechanisms for reliability control in the duplex case. In the ECTP-3 duplex multicast connection, the participants are classified into one TC-Owner and many TS-users. TC-Owner will be designated among the TS-users before the connection begins. In the duplex multicast connection, the two types of data transports are supported: multicast data transport from TC-Owner to all the other TS-users and unicast data transport from TS-users to TC-Owner. After the connection is created, TC-Owner can transmit multicast data to the group, whereas each TS-user is allowed to send unicast data to TC-Owner just after it gets a token from the TC-Owner. In ECTP, TC-Owner is at the heart of multicast group communications. It is responsible for overall connection management by governing the connection creation and termination, connection pause and resumption and the late join and leave operations. The duplex multicast connection specified in ECTP-3 is targeted to the multicast applications in which the TC-Owner (a single multicast sender) transmits the data information to all the other TS-users, and some of the TS-users respond to the multicast sender with the unicast feedback data. Basically, the duplex multicast transport will be well suited to the one-to-many multicast applications that need the unicast feedback channels from some TS-users (e.g., remote education, Internet broadcasting, etc). For example, in a remote education application, the multicast sender (lecturer) transmits the data such as voice, text and image to the student group, whereas some of the students may respond to the lecturer with the unicast data like questions for confirmation. It is noted that this duplex multicast connection can also be used for the ‘some-to-many’ multicast applications (e.g., a panel conferencing) in which a few of TS-users want to send multicast data to the group. In this scenario, the multicast data from the TS-users may first be delivered to the TC-Owner by unicast, and then TC-Owner will transmit the received unicast data to the group by multicast. Kim and Koh Expires October 18, 2007 [Page 4] Internet-Draft ECTP for Duplex Multicast Transport April 2007 2. Terminology 2.1. Definitions This document also applies the following definitions: TO (TC-Owner) TO can only transmit multicast data to the other TS-users, and it manages overall operations of ECTP-3; TU (TS-User) TU can receive multicast data sent by TO; SU (Sending TU) A TU who gets a token from TO. Only the SU is allowed to send unicast data to TO. In other words, before sending unicast data, each TU must request a token to TO; RA (Repair Agent) It is located on the control tree of ECTP-3. One or more RAs could be designated for scalable error recovery and status monitoring in ECTP-3. An RA is also a TU, that is, it receives multicast data from TO. RAs will be configured as a parent of the local groups through the control tree configuration in ECTP-3; Token It represents the right for a TU to transmit data. The TU who has a token is called SU. The tokens are managed by TC-Owner; Forward Data Channel It represents the multicast data channel from TO to the TUs. TO sends multicast data to all the other group members over IP multicast address. Backward Data Channel It represents the unicast data channel from a TU (SU) to TO. An SU who has a token can send unicast data to TO over IP unicast address. Kim and Koh Expires October 18, 2007 [Page 5] Internet-Draft ECTP for Duplex Multicast Transport April 2007 2.2. Abbreviations The following acronyms for ECTP protocols are used in this document: ECTP-1 ECTP part 1 (ITU-T X.606 | ISO/IEC 14476-1) ECTP-2 ECTP part 2 (ITU-T X.606.1 | ISO/IEC 14476-2) ECTP-3 ECTP part 3 (ITU-T X.607 | ISO/IEC 14476-3) ECTP-4 ECTP part 4 (ITU-T X.607.1 | ISO/IEC 14476-4) ECTP-5 ECTP part 5 (ITU-T X.608 | ISO/IEC 14476-5) ECTP-6 ECTP part 6 (ITU-T X.608.1 | ISO/IEC 14476-6) The following acronyms for ECTP-3 packets are used in this document: CCR Connection Creation Request CCC Connection Creation Confirm TJR Tree Join Request TJC Tree Join Confirm DATA Data NDATA Null Data RDATA Retransmission Data ACK Acknowledgment HB Heartbeat HBACK Heartbeat Acknowledgment LJR Late Join Request LJC Late Join Confirm ULR User Leave Request CTR Connection Termination Request TGR Token Get Request TGC Token Get Confirm TRR Token Return Request TRC Token Return Confirm 2.3. Conventions In this document, the capital characters are used to represent a packet of ECTP-3 (e.g., CCR for Connection Creation Request packet), and the capital and italic characters are used for timers or variables used in ECTP-3 (e.g., CCT for Connection Creation Timer, and AGN for ACK Generation Number). Kim and Koh Expires October 18, 2007 [Page 6] Internet-Draft ECTP for Duplex Multicast Transport April 2007 3. Protocol Overview The Enhanced Communications Transport Protocol (ECTP) is a transport protocol designed to support Internet multicast applications. ECTP operates over IPv4/IPv6 networks that have the IP multicast forwarding capability with the help of IGMP and IP multicast routing protocols. As shown in Figure 1, the ECTP shall be provisioned over UDP. +-------------------------+ | Multicast Applications | +-------------------------+ | ECTP | +-------------------------+ | UDP | +-------------------------+ | IP | +-------------------------+ Figure 1. ECTP Protocol Model Figure 1 illustrates an example of the use of mobile SCTP for seamless handover in IPv4 networks. Based on this figure, the handover procedures are described in the succeeding sections. This document describes the protocol specification of the ECTP part 3 (ECTP-3) for the duplex multicast connection. The duplex multicast connection is used for supporting multicast data transport between the participants that are classified into a single TC-Owner (TO) and many TS-users. A duplex multicast connection supports the two types of data channels between the participants: multicast data channel (sent by TO toward all the other TS-users) and unicast data channel (sent by a TS-user to TO). Such a TS-user is called Sending User (SU). Figure 2 illustrates these two types of data transport channels used in the duplex multicast connection. As shown in the figure, TO can transmit multicast data to the other TS-users over IP multicast (group) address. Some SUs may send unicast data to TO. The SU must first get a token from the TO before sending the unicast data. Kim and Koh Expires October 18, 2007 [Page 7] Internet-Draft ECTP for Duplex Multicast Transport April 2007 /-----------------------------------\ | | v /=============> TU (SU) | TO ==============================> TU | ^ \=============> TU (SU) | | \-----------------------------------/ Figure 2. Data Flows in ECTP Duplex Connection To establish a duplex multicast connection, TO transmits a CCR packet to the group. The CCR packet contains the connection information including general characteristics of the connection. In particular, the CCR packet must indicate that the connection type is the duplex multicast transport. Each TU who wants to participate in the connection will respond to the TO with a CCC packet. The connection creation operation will be completed when a pre-determined CCT timer expires. During the connection creation phase, a logical control tree is configured between TO and TUs, or between TUs for providing the scalable reliability control. With the root of the TO, the control tree defines a parent-child relationship between any pair of two TUs. The parent TU is called Repair Agent (RA). Based on the control tree, the error recovery will be performed. To configure a control tree, each TU sends a TJR message to a candidate parent node that has already been connected to the tree. The parent node will respond to the promising child TU with the TJC message. In this way, the control tree will gradually be expanded from the root toward the leaf nodes. Some of the prospective TUs may join the connection as late-joiners. The late-joining TU participates in the connection by sending an LJR message to TO. In response to the LJR message, TO sends an LJC message to the TU. The late-joiner TU will also join the control tree by using the TJR and TJC messages. For this purpose, the LJC message of TO may include the information about the prospective parent RA node for the late-joiner. The late-joining TU may try to connect to the prospective RA node so as to configure the control tree. After the connection is established, the data transmission phase starts. ECTP-3 protocol supports two types of data channels: the forward multicast channel from TO to the group and the backward unicast channel from the TU to TO. Kim and Koh Expires October 18, 2007 [Page 8] Internet-Draft ECTP for Duplex Multicast Transport April 2007 ECTP-3 also provides three kinds of reliability options: reliable (error recovery), semi-reliable (partial error recovery), and unreliable (no error recovery). In the reliable option, all the DATA packets will be recovered by the parent on the tree. In the semi- reliable option, the retransmissions of the lost packets are limited by the buffer status of the parent node. That is, the parent node will retransmit only the DATA packets that are at present being contained in the buffer. In the unreliable option, the RDATA packets are not used. It is also noted that each ACK packet does not mean any retransmission request to the parent. The ACK packets are instead used for monitor the receiving status of the receivers. In the forward multicast data transmission, TO can begin the multicast data transmission to the group by using the IP multicast address and group port number. The multicast data packets sent by TO will be sequentially segmented and transmitted by DATA packets to the receiving TUs. The TS-users will deliver the received DATA packets to the upper-layer application in the order transmitted by TO. For the forward multicast data channel of TO, the error control will be performed based on the local group defined by the ECTP control tree. If a child TU detects a data loss, it sends a retransmission request to its parent via ACK packets. Each child generates an ACK packet every ACK Generation Number (AGN) data packets. That is, an ACK packet is generated for the AGN data packets of TO. An ACK message contains a ‘Bitmap’ to indicate which data packets have been received or not. In response to an ACK packet, each parent RA may retransmit the RDATA packets to its children. In the forward multicast data transport, the HB and HBACK packets are used between a parent and children for the control tree maintenance. A parent transmits HB packets to the children every HB Generation Time (HGT). The HB contains which child must respond to this HB packet with the HBACK packet. The corresponding child will send a HBACK packet to the parent. The HB packet may also be used by the parent to calculate the local RTT for the group. For this purpose, the HB and HBACK packets contain a timestamp. The TO uses this RTT information for the rate-based congestion control that is based on the well-known TCP-Friendly Multicast Congestion Control (TFMCC) equation. The transmission rate of TO will be adjusted based on the RTT and the packet loss rate. For the backward unicast data transport, a certain TU in the connection may get a token from TO by sending a TGR message. The TO will then respond to the TU with the TGC message that contains a Token ID. Accordingly, the total number of tokens in the connection Kim and Koh Expires October 18, 2007 [Page 9] Internet-Draft ECTP for Duplex Multicast Transport April 2007 is controlled by TO. The Token ID is used to identify the sender of the unicast DATA packets at the TO side. The TU who has a token is called Sending TU (SU). The SU can send unicast DATA packets to TO. For the error recovery and congestion control, the HB and HBACK packets are exchanged between SU and TO. The SU sends an HB message to TO. The TO then responds with the HBACK packet that contains the acknowledgement information, as done in ACK packets in the forward multicast channel. It is noted that the HBACK is used for retransmission request in the backward channel. The SU performs the rate-based congestion control, as done in the forward data channel, which is based on the RTT and packet loss rate. After completing the unicast data transmission, the SU will return the token to the TO by sending a TRR message. TO will respond to the SU with a TRC message. The connection management operations are taken in the connection; user leave, the connection pause and resumption, and connection termination. In the User Leave operation, a participating TU may leave the connection by sending a ULR message to the parent. In a certain case, the parent may enforce a specific child TU to leave the connection by sending the ULR message, which is called the troublemaker ejection. The TO may temporarily pause and resume the connection. In the connection pause period, the TO will send NDATA packets to the group. After the TO has completed the data transport, it may terminate the duplex connection by sending a CTR message to the group. Kim and Koh Expires October 18, 2007 [Page 10] Internet-Draft ECTP for Duplex Multicast Transport April 2007 4. Design Considerations This section describes some considerations for the design of ECTP-3. 4.1. Participants The participants to an ECTP-3 connection can be classified into one of the following nodes: TO (TC-Owner) ECTP-3 connection has a single TO. The TO is responsible for the overall operations required for connection management including connection creation and termination, control tree creation, late join, and connection maintenance. TO is also a single sender of the forward multicast data channel. Only the TO is allowed for sending the original multicast data to the other participants. TU (TS-User) An ECTP-3 connection has one or more TUs. Each of them receives multicast data from TO. RA (Repair Agent) In the ECTP-3 connection, an RA is a TU who is responsible for error recovery to the local group by retransmission of data. On the control tree hierarchy of ECTP-3, an RA is a parent node and has its children nodes. Note that an RA is also a TU. That is, an RA also receives multicast data from TO. In ECTP-3, a TU may act as an RA in the connection, or some designated RAs may be used for the error recovery in the connection. It depends on the deployment of ECTP-3. SU (Sending TS-User) An SU is a TU who can send unicast data to TO. In ECTP-3 connection, a TU becomes an SU when it has a token and it can thus transmit unicast data to TO. 4.2. Control Tree An ECTP-3 connection may configure a control tree for scalable reliability control as follows. Kim and Koh Expires October 18, 2007 [Page 11] Internet-Draft ECTP for Duplex Multicast Transport April 2007 TO ^^^ / | \ ACKs / | \ / | \ / | \ / | \ / | \ RA RA RA ^^ ^^^ ^^ / | / | \ | \ / | / | \ | \ / | / | \ | \ TU TU TU TU TU TU TU Figure 3. ECTP-3 Control Tree In the ECTP-3 control tree, TO is on the top of the tree, which is in the Tree Level 0. RA is a parent node on the tree and has one or more children. The TU nodes, not designated as RA, cannot have its children. Such a control tree will be configured in the connection creation phase. Error recovery in ECTP-3 will be performed within each local group defined by the control tree. A child can request retransmission to its parent RA. In response to the request, the parent RA will retransmit the data packets to the children, if it has them in the buffer. An RA is also a TU, and it thus receives the multicast data from the TO. The control tree is applied only for forward multicast data channel. The control tree does not apply to the backward unicast data channel. 4.3. Data Channels In ECTP-3, the two types of data channels are used: forward and backward data channels. Forward Data Channel The forward data channel is used for TO to send multicast data to the other TUs. The forward data channel can also be used for an RA to send Retransmission Data to its children TUs. Kim and Koh Expires October 18, 2007 [Page 12] Internet-Draft ECTP for Duplex Multicast Transport April 2007 The forward data channel address consists of the group (multicast) IP address and the group port. TO sends multicast data via DATA packets by using the forward data channel address. TO and RAs can also retransmit multicast data via RDATA packets by using the forward data channel address. The following figure illustrates the use of the forward multicast data channels in ECTP-3. Backward Data Channel The backward data channel is used by an SU to send unicast datat to TO. The backward channel address consists of the IP address of TO and the ‘group’ port. The following figure illustrates the use of the backward unicast data channels in ECTP-3. Each SU must send unicast data via DATA and RDATA packets to TO by using this backward data channel address as the destination address. On the other hand, TO must bind its backward data channel address to receive the unicast data from any SU in the connection. 4.4. Addressing In ECTP-3, each packet uses the following types of IP addresses and port number for its source and destination address: - Group IP address and Local IP address; - Group port and Local port. Group and Local IP Addresses The group IP address is the IP multicast address (e.g., Class D address for IPv4), whereas a local IP address represents the unicast IP address for each of the ECTP participants: TO, RAs and TUs. The group IP address is used as the destination address of the packets that need to be multicast by TO and RAs. For example, the CCR and DATA packets of TO will use the group IP address as the destination address of the associated IP packets. Each RA also uses the group IP address as the destination address of the RDATA and HB packets. The local IP address of each participant is used as the source and destination IP address for the unicast packets, and also the source address for the multicast packets. Kim and Koh Expires October 18, 2007 [Page 13] Internet-Draft ECTP for Duplex Multicast Transport April 2007 It is noted that the group IP address and the local IP address of TO must be announced to all the prospective participants via an out-of- band signaling such as Web announcement. Group and Local Ports The group port represents the port number that has been announced to all of the ECTP-3 participants before the connection. In ECTP-3, the group port will typically be used as the ‘destination port’ of the ECTP-3 multicast packets transmitted by TO or RAs, such as CCR and DATA. That is, each TU should bind to the group IP address and port so as to receive the relevant ECTP-3 multicast packets. The group port number is also used by SU to send unicast data to TO. That is, TO will bind to the local port with its local IP address so as to receive the unicast data from any SU. In particular, the group port is also used as the destination port of the packet that requests a certain action, such as LJR. On the other hand, in the other cases that are not described above, the ECTP-3 packet will use the local port number as source and/or destination ports. For example, in response to the Late Join Request from a TU, the TO will respond with the Late Join Confirm message that use the local port of the TU as the destination port. The detailed use of the local IP address and port will be specified for each of the ECTP-3 packets in the later section. Addresses of Data Channels In ECTP-3, all the data packets use the group port number as the destination port. Accordingly, before the connection creation, the following information must be announced to all of the ECTP-3 participants via an out-of-band signaling such as Web announcement. - Group IP address and Group port; - Local IP address of TO. The following figure describes the use of IP address and port for the forward and backward data channels. The forward multicast data packets use the group IP address and port number as the destination address of the data packets, whereas the backward data packets use the local IP address of TO and the group port number as the destination address. Kim and Koh Expires October 18, 2007 [Page 14] Internet-Draft ECTP for Duplex Multicast Transport April 2007 4.5. Tokens In ECTP-3, a token represents the right for a TU to send a unicast data to TO. Before transmitting the data, each TS-user must get a token from the TO, as per the Token Control procedures of ECTP-3. Each token is represented as a 1-byte non-negative integer in ECTP-3. Such a token number (or Token ID) will be assigned by TO when a TU requests a token in the connection. Token ID is ranged between 1 and 255. The Token ID of ‘0’ is reserved for use of TO. At the TO side, the Token ID can be used to identify who is sending the unicast data. 5. Packets An ECTP packet contains a 16-byte base header together with either extension elements or user data. It is noted that the data packets do not include any extension elements. In this section, we give a brief sketch of the ECTP-3 packet format. More detailed description on the packet format is given in [6]. 5.1. Base Header The 16-byte base header contains the information helpful to all the protocol operations, in particular for the data packets. The base header contains the following information: Next Element (4 bits) This specifies the type of the extension element immediately following the base header. The encoding values of the extension elements will be described later. The extension element value of ‘0000’ means that the next part of this packet contains the user data, if any. Version (2 bits) This defines the version of the ECTP-3 protocol. Its current version is encoded as ‘00’. CT (Connection Type): (2 bits) Kim and Koh Expires October 18, 2007 [Page 15] Internet-Draft ECTP for Duplex Multicast Transport April 2007 This specifies the type of the ECTP connection. The encoding value for the connection type is as follows: 01 – simplex multicast connection (for ECTP-1 and ECTP-2); 10 – duplex multicast connection (for ECTP-3 and ECTP-4); 11 – N-lex multicast connection (for ECTP-5 and ECTP-6); The value 00 is reserved for future use. In this ECTP-3 specification, the CT must be set as 10. It is noted that this definition is compatible with the specifications of ECTP-1 and ECTP-2. Packet Type (8 bits) It indicates the type of this ECTP-3 packet. The encoding values of the ECTP-3 packets will be described later. Checksum (16 bits) This is used to check the validity of the ECTP-3 packet that includes the base header, extension header and/or user data. The ECTP-3 checksum is calculated by using the conventional complement arithmetic operation, as done in TCP and UDP. Connection ID (32 bits) The Connection ID is used to identify an ECTP connection by the ECTP host. It may also be used to verify the connection. In the connection setup phase, this information must first be informed by TO to the other participants via the CCR or LJC packets. All the otherECTP-3 packets must set this field to be the value announced by TO. PSN (32 bits) This value represents the sequence number of the data packet for the ECTP-3 DATA or RDATA packets. For some control packets such as NDATA or HB packets, this value has a different semantic, which will be described later. For the other control packets, it is ignored. This sequence number is a 32-bit unsigned number that starts with the initial sequence number and increases by 1, and wraps back around to 1 after reaching 232-1. Payload Length (16 bits) This value indicates the total length of the extension headers or user data in byte, following the base header. Kim and Koh Expires October 18, 2007 [Page 16] Internet-Draft ECTP for Duplex Multicast Transport April 2007 F (1 bit) It is a flag bit. The use of this flag depends on the packet types: For the LJC (Late Join Confirm), TJC (Tree Join Confirm), Token Get Confirm (TGC), Token Return Confirm (TRC) packets, the F = 1 indicates that each of the corresponding join request is accepted. F is set to 0, otherwise; For the ULR (User Leave Request) packet, F is set to 1 for the user-invoked leave, or set to 0 for the troublemaker ejection; For the CTR (Connection Termination Request) packet, F is set to 1 for an abnormal termination, or set to 0 for the normal termination after all the data have been transmitted; For the token control operations, TGR and TRR request messages use this flag so as to indicate whether this is the TO-initiated or TU-initiated token control. For the other packets, the detailed description is given in the protocol procedure section. Otherwise, if any usage is not specified, this field will be ignored. Reserved (7 bit) This field is reserved for future use. Token ID (8 bit) The Token ID is valid only for data packets: DATA and RDATA packets. This represents who is the source of the data packets. The Token ID value is ranged between 0 and 255. Each SU receives a Token ID from TO via the token get procedure and sets this field to be the number assigned by TO. The forward multicast data packets of TO set this field to be ‘0’. 5.2. Extension Elements The ECTP packets used for control may contain one or more extension elements along with the base header. The based header and each extension element has the field of Next Element that points to the immediately succeeding extension element, if any. The Next Element field is encoded as shown in the following table. It is noted that the 0000 means No Element. Accordingly, the last extension element of an ECTP packet must set its Next Element field to ‘0000’. Kim and Koh Expires October 18, 2007 [Page 17] Internet-Draft ECTP for Duplex Multicast Transport April 2007 Table 1. Extension Elements +-------------------+---------+-----------------+ | Extension Element | Encoding| Length (bytes) | +-------------------+---------+-----------------+ | End of Element | 0000 | 0 | +-------------------+---------+-----------------+ | Connection | 0001 | 4 | +-------------------+---------+-----------------+ | Acknowledgement | 0010 | Variable | +-------------------+---------+-----------------+ | Membership | 0011 | 4 | +-------------------+---------+-----------------+ | Timestamp Report | 0100 | 12 | +-------------------+---------+-----------------+ | IP Address | 0101 | 8 or 20 | +-------------------+---------+-----------------+ It is noted that all the extension elements other than Address element have already been defined in ECTP-1 and ECTP-2. Accordingly, the encoding values of those extension elements will be reused in ECTP-3. It is noted that the encoding value of 0101 is reserved for the QoS extension element, which is not used in ECTP-3, and may be defined for the QoS management in ECTP-4. All the extension elements described in the table will be defined in this section by encompassing the requirements for the ECTP-3 protocol. Connection Element The connection extension element contains overall information on the ECTP-3 transport connection. It is encoded as 0001 in the Next Element field of the preceding element or based header. This extension element must be included in the CCR, LJC and TGR packets. Acknowledgement Element This extension element provides information on the status of the packet reception at the child node, which will be referred to by the parent node for the error, flow and congestion control. This extension header is attached to the ACK packet. It is encoded as ‘0010’ in the Next Element field of the preceding element or based header. Membership Element Kim and Koh Expires October 18, 2007 [Page 18] Internet-Draft ECTP for Duplex Multicast Transport April 2007 This 4-byte extension element contains information on the tree membership. It is encoded as 0011 in the Next Element field of the preceding element or based header. Timestamp Element The Timestamp element is encoded as 0100 in the Next Element field of the preceding element or based header. The ECTP-3 uses the 8-byte timestamp so as to calculate Round Trip Time (RTT). Address Element The Address extension element is encoded as 0110 in the Next Element field of the preceding element or based header. This element is attached to the packet when the protocol needs to specify the IPv4 or IPv6 address of the participant concerned. For example, the LJC packet of TO may include this element so as to inform a late-joining TU about the IP address of the promising RA that the TU may connect. 5.3. Packet Format ECTP-3 defines the total 18 packet types: 3 types of data packets and 15 types of control packets. The following table summarizes the packets used in ECTP-3. Table 2. ECTP-3 Packets +----------------------------+-------+----------+-----------+---+ | Full Name |Acronym| From | To |M/U| +----------------------------+-------+----------+-----------+---+ |Connection Creation Request | CCR | TO | TUs | M | +----------------------------+-------+----------+-----------+---+ |Connection Creation Confirm | CCC | TU | TO | U | +----------------------------+-------+----------+-----------+---+ | Tree Join Request | TJR | Child | Parent | U | +----------------------------+-------+----------+-----------+---+ | Tree Join Confirm | TJC | Parent | Child | U | +----------------------------+-------+----------+-----------+---+ | Data | DATA | TO/SU | TUs/TO |M/U| +----------------------------+-------+----------+-----------+---+ | Null Data | NDATA | TO | TUs | M | +----------------------------+-------+----------+-----------+---+ | Retransmission Data | RDATA |Parent/SU |Children/TO|M/U| +----------------------------+-------+----------+-----------+---+ | Acknowledgement | ACK | Child | Parent | U | +----------------------------+-------+----------+-----------+---+ Kim and Koh Expires October 18, 2007 [Page 19] Internet-Draft ECTP for Duplex Multicast Transport April 2007 | Heartbeat | HB |Parent/SU |Children/TO|M/U| +----------------------------+-------+----------+-----------+---+ | Heartbeat ACK | HBACK | Child/TO | Parent/SU | U | +----------------------------+-------+----------+-----------+---+ | Late Join Request | LJR | TU | TO | U | +----------------------------+-------+----------+-----------+---+ | Late Join Confirm | LJC | TO | TU | U | +----------------------------+-------+----------+-----------+---+ | User Leave Request | ULR |Child/Par.|Par./Child | U | +----------------------------+-------+----------+-----------+---+ | Connection Term. Request | CTR | TO | TUs | M | +----------------------------+-------+----------+-----------+---+ | Token Get Request | TGR | SU | TO | U | +----------------------------+-------+----------+-----------+---+ | Token Get Confirm | TGC | TO | SU | U | +----------------------------+-------+----------+-----------+---+ | Token Return Request | TRR | SU | TO | U | +----------------------------+-------+----------+-----------+---+ | Token Return Confirm | TRC | TO | SU | U | +----------------------------+-------+----------+-----------+---+ (*) In the table, M/U means Multicast and Unicast. In the table, the parent node represents TO or RA, and the packets used for token control can be initiated by SU as well as TO. As also shown in the table, all of the ECTP-3 packets are exchanged between the participants in the request-and-conform manner. For example, the CCR request expects to receive the corresponding CCC confirm message. The ACK messages will be used to confirm the DATA and RDATA messages. On the other hand, ULR and CTR messages do not require any responding confirm messages. Kim and Koh Expires October 18, 2007 [Page 20] Internet-Draft ECTP for Duplex Multicast Transport April 2007 6. Procedures This section describes the protocol procedures of ECTP-3. Before an ECTP-3 connection is created, the following address information should be announced to the prospective participants: TU and RA. - Multicast IP address of the group - Group port number - IP address of TO This information may be announced to the prospective participants via an out-of-band signaling mechanism such as Web announcement. Accordingly, the prospective TU should be able to bind the group IP address and port so as to receive the CCR packet from the TO. A prospective late-joiner TU should also send a LJR packet to the TO. 6.1. Connection Creation An ECTP-3 connection will begin when TO sends the first ECTP-packet, CCR, to the group over the multicast group IP address and port. An ECTP-3 control tree is also configured in the connection creation phase. TO begins the connection creation operation by sending the CCR packet to the group. The CCR packet contains the generic information on the connection element such as TCO (Tree Configuration Option), RO (Reliability Option), and MSS (Maximum Segment Size). After sending the CCR packet, TO starts the CCT (Connection Creation Timer). Only the CCC packets will be allowed during the CCT timer. Each TU should join the control tree before responding with a CCC packet. In the connection creation phase, each TU can join only the TO as the parent. To join the control tree, each TU sends a TJR packet to TO. TO then responds to the TU with the TJC packet. The TJC packet should indicate whether the tree join request is accepted or not by using the F flag of the base header. The TJC packet should also contain the Child ID and Tree Level in the membership element. The TJC packet may optionally contain the address element to represent a promising parent RA for the TU. It needs to ensure that the parent RA has already been on the tree. Kim and Koh Expires October 18, 2007 [Page 21] Internet-Draft ECTP for Duplex Multicast Transport April 2007 6.2. Late Join Some of the prospective participants may join the ECTP-3 connection as a late joiner. In particular, any TU is allowed to join the connection as a late joiner, after the CCT timer expires. The late joiner TU sends an LJR packet to TO. In response to the LJR packet, the TO sends an LJC packet to the TU, which should indicate that the request is accepted or not by using the F flag of the base header. The LJC packet should contain the connection element. It may also contain the address element so as to recommend the promising parent RA for the TU. If no address element is indicated the TU may try to join the TO in the control tree configuration. If the LJC packet does not arrive within the RXT (Retransmission Timeout), the late joiner may try to send the LJR packet again. To join the control tree, the TU should send a TJR packet to the promising parent RA, as indicated by TO via the LJC packet, or to the parent TO. The TO then responds with the TJC packet to the TU. If the TJC packet does not arrive within the RXT, the late joiner may try to send the TJR packet again. In this way, the ECTP-3 control tree will be configured in the hierarchical manner. 6.3. Forward Data Transport In the ECTP-3 forward data channel, the TO sends multicast DATA packets to the group. When a data packet loss is detected by the receiving TU, the retransmission for error recovery will be performed within a local group that is defined by the control tree. On the other hand, ECTP-3 provides three kinds of Reliability Option (RO) for error control operations: reliable, semi-reliable, and unreliable. The semantics of the RO are as follows: 1) Reliable Transport (error recovery) In the reliable option, all the DATA packets will be recovered by the parent on the tree. Each child requests the retransmission via ACK packet, and the parent sends the corresponding RDATA packet over the multicast address. Kim and Koh Expires October 18, 2007 [Page 22] Internet-Draft ECTP for Duplex Multicast Transport April 2007 2) Semi-reliable Transport (partial error recovery) In the semi-reliable option, the retransmissions of the lost packets are limited by the buffer status of the parent node. That is, the parent node will retransmit only the DATA packets that are at present being contained in the buffer. It is noted that the parent node need not keep all the DATA packets in the buffer. The parent will rather delete the old DATA packets from the buffer, which have not been acknowledged by the children. It is noted in the semi-reliable option that the parent should announce its children about which DATA packets could be recovered in the error recovery. For this purpose, the parent node will use the periodic HB packets. Specifically, the PSN filed of the base header of the HB packet will indicate the lowest sequence number of DATA packets that are contained in the buffer. 3) Unreliable Transport (no error recovery) In the unreliable option, the RDATA packets are not used. It is also noted that each ACK packet does not mean any retransmission request to the parent. The ACK packets are instead used by the parent to monitor the status of the connection such as ADN. After the connection creation, the TO can send multicast DATA packets to the group members. TO will generate DATA packets by the segmentation procedure. To do this, TO splits a multicast data stream of application into multiple DATA packets. Each DATA packet has its own sequence number. When TO has no data to transmit, TO may transmit the periodic NDATA packets in the connection pause period. Each TU delivers all the data packets received to the application in the order sent by TO. Each receiver reassembles the received packets. Corrupted and lost packets are detected by using a checksum and sequence number. A corrupted packet is also considered as a loss. The lost DATA packets are recovered in the error control function. ECTP-3 uses the flow control based on a fixed-size window. The window size represents the number of unacknowledged data packets in the sending buffer. TO can maximally transmit the window size of data packets at the configured data transmission rate. In ECTP-3, the transmission rate of multicast data is controlled by the rate-based congestion control mechanisms. Kim and Koh Expires October 18, 2007 [Page 23] Internet-Draft ECTP for Duplex Multicast Transport April 2007 A new DATA packet is sequentially numbered by TO. The sequence number of the DATA packet starts from Initial PSN and increases by 1. The sequence number is used to detect lost data packets by receivers. The Initial PSN is randomly generated other than 0. The sequence number of 0 is reserved. The packet sequence number is increased for each new DATA packet. Modulo 232 arithmetic is used and the sequence number wraps back around to 1 after reaching <232 – 1>. The Initial PSN number will be informed to the TUs by way of CCR or LJC packet. 6.4. Reliability Control for Reliable Transport When the reliability option for the connection indicates Reliable (RO = 10), all the DATA packets should be recovered in the error recovery operations. Error Detection The checksum field of the base header is used for detection of packet corruption, and the PSN field is for detection of a packet loss. When a data packet is received, each receiver examines the checksum. If the checksum field is invalid, the packet is regarded as a corruption and shall be discarded. A corruption is treated as a loss. The loss can be detected as a gap of two consecutive sequence numbers for DATA packets. The loss information is recorded into the ACK bitmap, which is attached to the subsequent ACK packets. ACK packets are used for the retransmission requests. When a receiver detects a gap in the sequence numbers of received packets, it sets to zero the bit of the ACK bitmap that corresponds to the lost DATA packet. The ACK bitmap is included into the acknowledgement element, which is attached to the subsequent ACK packet and delivered to the parent by the ACK generation mechanisms. For a local group, a parent and its children maintain the Lowest Sequence Number (LSN) variables to determine the status of DATA packets. For a child, the LSN represents the sequence number of the lowest numbered DATA packet that the child has not received. For a parent, the LSN represents the sequence number of the lowest numbered DT packet that has not been acknowledged by its children. To request the retransmissions of lost data, each child makes an acknowledgement element containing the LSN, Valid Bitmap Length and ACK Bitmap. The ACK Bitmap specifies a success or a failure of a packet delivery for each DATA packet; 1 for success and 0 for failure. Suppose Bitmap = 01101111, LSN = 15. Then the DATA packets with the sequence number 15 and 18 are lost. Kim and Koh Expires October 18, 2007 [Page 24] Internet-Draft ECTP for Duplex Multicast Transport April 2007 Retransmission Request by ACK Generation Each child generates an ACK packet by ACK Generation Number (AGN). Each child sends an ACK packet to its parent every AGN number of packets. To do this, a child receives a Child ID from its parent in tree configuration, which is contained in the tree membership element of the TJC packet. Each child sends an ACK packet to its parent, if the PSN number of a DATA packet modulo AGN equals Child ID modulo AGN, i.e., if PSN % AGN = Child ID % AGN. Suppose AGN = 8 and Child ID = 2. The child generates an ACK packet for the DT packets whose sequence numbers are 2, 10, 18, 26, etc. This ACK generation rule is applied when the corresponding DT packet is received or detected as a loss by the child. Retransmissions and ACK Aggregation by RA Each parent uses ACK packets to gather status information for the error recovery. Each time a parent receives an ACK packet from any of its children, it records and updates the status information on which packets have been successfully received by its children. A DATA packet is defined as a ‘stable’ packet if all of the children have received it. The stable DATA packets are released out of the buffer memory of the parent. When a parent receives an ACK packet from one of its children, if one or more packet losses are indicated, the parent transmits the corresponding RDATA packets to all of its children over its multicast control address. After a parent retransmits an RDATA packet, it will ignore any subsequent retransmission requests for the same packet during the RXT period. An ACK packet contains information on the number of active descendants (ADN). The parent aggregates the ADN variables for all of its children, and sends the aggregated information to its parent (when it sends an ACK to the parent. Kim and Koh Expires October 18, 2007 [Page 25] Internet-Draft ECTP for Duplex Multicast Transport April 2007 6.5. Control Tree Maintenance The ECTP-3 control tree is maintained using the HB and HBACK packets. Each parent RA advertises periodic HB packets using Heartbeat Generation Time (HGT), after it becomes an on-tree node. The default HGT is 3 second. The HB packet contains the information (Child ID of the membership element) about which child should respond to this HB packet. The corresponding child should respond with the HBACK packet. In ECTP-3, the exchange of HB and HBACK packets between a parent and children is done with the following three purposes: 1) Check whether the tree node is still alive A child detects the failure of its parent, if it cannot receive any packets such as HB and RDATA packets from the parent during the time interval of FDN (Failure Detection Number) x Heartbeat Generation Time (HGT). Then the child begins to find an alternate parent. The default FDN is 3. A parent detects the failure of a child, if it cannot hear any HBACK packets from the child for the FDN consecutive HB packets. If a child is detected as a failure, the parent sends an ULR packet (for troublemaker ejection) to the failed child, and clears the child out of its children list. 2) Information on DATA packets that can be recovered The HB packet of the parent contains the information in the PSN field of the header, which represents the lowest sequence number of DATA packet that is contained in the buffer. This information will be referred to by the children in the ACK generation. 3) Calculation of local RTT On the other hand, the HB and HBACK can also be used for calculate the Round Trip Time (RTT) for a local group. A parent RA sends a HB packet containing a timestamp element to its children every HGT interval. The corresponding child will also contain the timestamp element as it is in the HBACK packet. Receiving an HBACK packet from a child, the parent RA calculates the RTT by subtracting Timestamp from the current time. The RTT is recorded into the children list. The parent determines the Local RTT by the maxim RTT value for its children. Kim and Koh Expires October 18, 2007 [Page 26] Internet-Draft ECTP for Duplex Multicast Transport April 2007 6.6. Congestion Control for Forward Data Channel For the forward multicast data transport, the congestion control will be done by TO to adjust the data transmission rate. The adjustment of transmission rate of TO is controlled based on the packet loss rate and the RTT for the local group. The RTT for the local group may be calculated using the HB and HBACK packets. The congestion control algorithm (i.e., the algorithm for transmission rate adjustment of TO) follows the well-known TCP- Friendly Multicast Congestion Control (TFMCC) algorithm, which has been developed in the IETF RMT WG. The TFMCC algorithm is featured by: “TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions. TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications such as streaming media where a relatively smooth sending rate is of importance.” In ECTP-3, the TO will calculate the sending rate X, which is based on the s (MSS), R (local RTT), and p (packet loss rate). It is noted that the packet loss rate will be determined by TO as ‘the number of loss events as a fraction of the number of packets transmitted.’ The RTT will also be calculated in the Control Tree Maintenance operation. TO will take the maximum value of the RTTs and packet loss rate that have been reported from its children. 6.7. Token Control In ECTP-3, a token represents the right to send a data to the TO in the backward unicast data channel. Each TU who wants to transmit a data to TO must get a token from the TO. The TU will be an SU after getting a token from TO. In this way, TO can control the maximum number of tokens simultaneously active for the connection. An SU returns the token after completing the unicast data transmission to TO. Kim and Koh Expires October 18, 2007 [Page 27] Internet-Draft ECTP for Duplex Multicast Transport April 2007 The TU can get a token from TO. In this Token Get operation, the TU first requests a token to TO. The following figure shows the operations for Token Get. To get a token in the Token Get operation, a TU sends a TGR message to TO, and then waits for the corresponding TGC message. In response to the TGR packet, the TO should send a TGC message to the TU. The TGC message should indicate whether the request is accepted or not by using the F flag of the base header. In case of the acceptance, the message will also contain a valid Token ID and Initial PSN in the base header. If the responding TGC message has not arrived until the RTO timer expires, the TU may send the TGR message again. The TU (i.e., SU) should respond with the TGC message that sets the F flag to ‘0’ (acceptance). If the responding TGC message has not arrived from the SU until the RTO timer expires, the TO may send the TGR message to SU again. When completing data transmission, the SU may return the token to TO. The SU can return its token to TO. In this Token Return operation, the TU sends the TRR packet to TO. In the Token Return case, the SU sends a TRR message to TO. The TO then responds with the TRC message. On the other hand, in the Token Withdrawal case, the TO may enforce the concerned SU to return the token by sending a TRR message. If the responding TRC message has not arrived until the RTO timer expires, the TRR message may be sent again. 6.8. Backward Data Transport After getting a token from TO, an SU can transmit unicast DATA packets to TO. In the backward unicast data channel, the initial sequence number (ISN) of SU is indicated in the PSN field of the header of the TGR (in the Token Get case) or TGC (in the Token Give case). The ISN is randomly generated other than ‘0’, as done in the forward data channel. The DATA packets transmitted by SU must indicate the Token ID that is allocated by TO. The reliability control for the unicast data channel will be done between SU and TO. In the data transmission phase, the SU sends a HB packet to the TO every HGT time interval. The TO should respond with the HBACK packet to the SU. The HBACK packet may indicate the Kim and Koh Expires October 18, 2007 [Page 28] Internet-Draft ECTP for Duplex Multicast Transport April 2007 retransmission request in the Acknowledgement element. In this case, the SU sends the corresponding RDATA packet. The HB and HBACK packet will also be used to calculate the RTT between SU and TO. The congestion control (sending rate adjustment) of SU is performed, as done in the forward data channel. Based on the packet loss rate and RTT, the SU calculate the transmission rate. 6.9. Connection Management In the User Leave case, the child node will send a ULR message to its parent (RA or TO). In the Troublemaker Ejection case, the parent will request the concerned child to leave the connection. In both cases, the ULR message does not require the corresponding confirm message. It is noted that the User Leave operation is performed between a parent and a child over the control tree, rather than between TO and TU. The troublemaker ejection may be applied to the child that has not been responding during a certain time interval in the HB and HBACK operation for tree maintenance. It is not recommended to apply the troublemaker ejection to an RA node that has one or more children. In ECTP-3, the TO may pause the connection temporarily for a certain reason. For example, when it has no user data to transmit, the TO may pause the connection. The connection may also resume. During the connection pause period, the TO may send NDATA packet. The TO may also terminate the connection when it has completed the data transmission. The TO performs the connection termination by sending a CTR message to the group. 7. Security Considerations TBD 8. IANA Considerations TBD 9. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Kim and Koh Expires October 18, 2007 [Page 29] Internet-Draft ECTP for Duplex Multicast Transport April 2007 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [1] ITU-T Recommendation X.601 (2000), Multi-Peer Communications Framework [2] ITU-T Recommendation X.602 (2004) | ISO/IEC 16511: 2005, Information Technology – Group Management Protocol (GMP) [3] ITU-T Recommendation X.605 (1998) | ISO/IEC 13252: 1999, Information Technology – Enhanced Communications Transport Service Definition [4] ITU-T Recommendation X.606 (2001) | ISO/IEC 14476-1: 2002, Information Technology — Enhanced Communications Transport Protocol: Specification of simplex multicast transport (ECTP-1) [5] ITU-T Recommendation X.606.1 (2002) | ISO/IEC 14476-2: 2003, Information Technology — Enhanced Communications Transport Protocol: Specification of QoS Management for Simplex Multicast Transport (ECTP-2) [6] ITU-T Recommendation X.607 (2007) | ISO/IEC 14476-3:2007, Information Technology — Enhanced Communications Transport Protocol: Specification of Duplex Multicast Transport (ECTP-3) Author's Addresses Seok Joo Koh Kyungpook National University, KOREA sjkoh@knu.ac.kr Dae Young Kim Chungnam National University, KOREA dykim@cnu.ac.kr Kim and Koh Expires October 18, 2007 [Page 30] Internet-Draft ECTP for Duplex Multicast Transport April 2007 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kim and Koh Expires October 18, 2007 [Page 31]