Internet Draft                                           Seok J. Koh
   draft-sjkoh-dykim-ectp-00.txt          Kyungpook National University
   Expires: April 2006                                    Dae Young Kim
   October 2005                            Chungnam National University


   Enhanced Communications Transport Protocol for One-to-Many Multicast

              Applications with Unicast Reverse Data Channels

                      <draft-sjkoh-dykim-ectp-00.txt>


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.

   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.


Copyright Notice

   Copyright (C) The Internet Society (2005).













Koh and Kim              Expires: April 2006                 [Page 1]


                      ECTP for Duplex Multicast          October 2005


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.


Table of Contents

   1. Introduction...................................................3
   2. Terminology....................................................4
      2.1 Definitions................................................4
      2.2 Abbreviations..............................................5
      2.3 Conventions................................................5
   3. Protocol Overview..............................................6
   4. Design Considerations..........................................9
      4.1 Participants...............................................9
      4.2 Control Tree..............................................10
      4.3 Data Channels.............................................11
      4.4 Addressing................................................12
      4.5 Tokens....................................................13
   5. Packets.......................................................14
      5.1 Base Header...............................................14
      5.2 Extension Elements........................................16
      5.3 Packet Format.............................................18
   6. Procedures....................................................19
      6.1 Connection Creation.......................................19
      6.2 Late Join.................................................20
      6.3 Forward Data Transport....................................20
      6.4 Token Control.............................................26
      6.5 Backward Data Transport...................................27
      6.6 Connection Management.....................................27
   7. Timers and Parameters.........................................28
      7.1 Timers....................................................28
      7.2 Parameters................................................29
   Security Considerations..........................................30
   References.......................................................30
   Author's Addresses...............................................30
   Intellectual Property............................................31
   Copyright Statement..............................................31
   Disclaimer of Validity...........................................31




Koh and Kim              Expires: April 2006                 [Page 2]


                      ECTP for Duplex Multicast          October 2005


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.




Koh and Kim              Expires: April 2006                 [Page 3]


                      ECTP for Duplex Multicast          October 2005


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.






Koh and Kim              Expires: April 2006                 [Page 4]


                      ECTP for Duplex Multicast          October 2005


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).











Koh and Kim              Expires: April 2006                 [Page 5]


                      ECTP for Duplex Multicast          October 2005


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.









Koh and Kim              Expires: April 2006                 [Page 6]


                      ECTP for Duplex Multicast          October 2005


            /-----------------------------------\
            |                                   |
            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.

   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


Koh and Kim              Expires: April 2006                 [Page 7]


                      ECTP for Duplex Multicast          October 2005


   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
   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


Koh and Kim              Expires: April 2006                 [Page 8]


                      ECTP for Duplex Multicast          October 2005


   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.


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.



Koh and Kim              Expires: April 2006                 [Page 9]


                      ECTP for Duplex Multicast          October 2005


 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.



                             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.


Koh and Kim              Expires: April 2006                [Page 10]


                      ECTP for Duplex Multicast          October 2005



   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.

   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.








Koh and Kim              Expires: April 2006                [Page 11]


                      ECTP for Duplex Multicast          October 2005


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.

   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.



Koh and Kim              Expires: April 2006                [Page 12]


                      ECTP for Duplex Multicast          October 2005


   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.

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.




















Koh and Kim              Expires: April 2006                [Page 13]


                      ECTP for Duplex Multicast          October 2005


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)

   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.



Koh and Kim              Expires: April 2006                [Page 14]


                      ECTP for Duplex Multicast          October 2005


 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.

 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.


Koh and Kim              Expires: April 2006                [Page 15]


                      ECTP for Duplex Multicast          October 2005



   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Æ.

                 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     |
       +-------------------+---------+-----------------+



Koh and Kim              Expires: April 2006                [Page 16]


                      ECTP for Duplex Multicast          October 2005



   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

   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.




Koh and Kim              Expires: April 2006                [Page 17]


                      ECTP for Duplex Multicast          October 2005


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 |
   +----------------------------+-------+----------+-----------+---+
   |          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.


Koh and Kim              Expires: April 2006                [Page 18]


                      ECTP for Duplex Multicast          October 2005




   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.


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


Koh and Kim              Expires: April 2006                [Page 19]


                      ECTP for Duplex Multicast          October 2005


   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.

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)


Koh and Kim              Expires: April 2006                [Page 20]


                      ECTP for Duplex Multicast          October 2005



      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.

   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.


6.3.1 Multicast Data Transmission

   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.




Koh and Kim              Expires: April 2006                [Page 21]


                      ECTP for Duplex Multicast          October 2005


   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.

   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.3.2 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.




Koh and Kim              Expires: April 2006                [Page 22]


                      ECTP for Duplex Multicast          October 2005


   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.


 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.



Koh and Kim              Expires: April 2006                [Page 23]


                      ECTP for Duplex Multicast          October 2005


6.3.3 Reliability Control for Semi-Reliable Transport

   When the reliability option for the connection indicates <Semi-
   Reliable> (RO = 01), the error recovery against the data loss is
   limited to the DATA packets that the parent is at present containing
   in the buffer.  The other procedures are the same with those for the
   reliable data transport.

   To inform the children about which DATA packets can be recovered
   against loss event, the parent uses the periodic HB packet. The PSN
   value of the HB packet represents the lowest sequence number of the
   DATA packets that can be contained in the buffer of the parent.

   Each child node should construct its ACK bitmap based on the
   announced PSN value. The data packets with the sequence number lower
   than the PSN may be delivered to its upper layer application at the
   child side.

6.3.4 Reliability Control for Unreliable Transport

   When the reliability option for the connection indicates Unreliable
   (RO = 00), the error recovery is not performed; hence no RDATA
   packets of the parents are used. Accordingly, each TU will deliver
   the DATA packets to the application, as they are received, even when
   a data loss is detected.


6.3.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.


Koh and Kim              Expires: April 2006                [Page 24]


                      ECTP for Duplex Multicast          October 2005


      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.


6.3.5 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.ö




Koh and Kim              Expires: April 2006                [Page 25]


                      ECTP for Duplex Multicast          October 2005


   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.4 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.

6.4.1 Token Get

   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.

6.4.2 Token Return

   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


Koh and Kim              Expires: April 2006                [Page 26]


                      ECTP for Duplex Multicast          October 2005


   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.5 Backward Data Transport

   After getting a token from TO, an SU can transmit unicast DATA
   packets to TO.

6.5.1 Unicast Data Transmission

   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.

6.5.2 Reliability Control for Unicast Data Channel

   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
   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.

6.5.3 Congestion Control for Unicast Data Channel

   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.6 Connection Management

6.6.1 User Leave

   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


Koh and Kim              Expires: April 2006                [Page 27]


                      ECTP for Duplex Multicast          October 2005


   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.

6.6.2 Connection Pause and Termination

   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. Timers and Parameters

   This section summarizes the timers and variables used for ECTP-3 for
   information.

7.1 Timers

 CCT (Connection Creation Time)

   TO triggers the CCT timer when sending the CCR packet to the group.
   The TO will process only the CCC packets that arrive from the
   prospective TUs before the CCT timer.

   A specific value of CCT will be configured by the TO.

 LJT (Late Join Time)

   When a promising late-joining TU starts an ECTP connection, if it
   cannot receive any CCR message during the LJT time, it will try to
   join the ECTP connection as a late-joiner by sending an LJR message
   to the TO.

   A specific value of LJT will be configured by the TU.

 HGT (Heartbeat Generation Time)

   Each parent node transmits the HB packet to its children every HGT
   second. Each child will respond with the HBACK packet if the Child ID
   of the HB packet is equal to its Child ID. The SU also sends the HB
   packets every HGT interval. The TO will respond with the HBACK packet.
   The choice of HGT depends on the parent node and SU.



Koh and Kim              Expires: April 2006                [Page 28]


                      ECTP for Duplex Multicast          October 2005


 RXT (Retransmission Time)

   In ECTP, the RXT timer is used by the packet initiator to wait for
   the corresponding confirm packet. For example, a late joiner TU sends
   an LJR packet to TO and waits for the LJC packet until the RXT timer
   expires. When the timer expires and the confirm packet has not
   arrived until then, it may send the request packet again.
   The RXT timer can also be used by a parent node to back off the
   retransmission request from the children for the RDATA packets that
   have already been retransmitted.

   A specific value of RXT depends on the implementation.


7.2 Parameters

 ADN (Active Descendants Number)

   This represents the number of the active descendants on the tree.
   Each RA calculates the ADN value and delivers it via the ACK packet
   to the parent. In this way, the TO can be informed about the total
   number of active participants in the connection.

 AGN (ACK Generation Number)

   The AGN value will be informed to the TUs via the Connection
   Information element. This AGN value is referred to by each child node
   to realize when it should generate its ACK packet toward its parent.

 FDN (Failure Detection Number)

   The FDN number is used for a tree node to detect whether its parent
   or child node is still alive. In the tree maintenance, the parent may
   eject a child if the child has not been responding during the FDN
   consecutive times of HB packets.

 PSN (Packet Sequence Number)

   Each DATA packet has its own PSN value in the header. This is used
   for the receiving TU to check the packet loss event and to rearrange
   the DATA packet in the order transmitted.
   ISN (Initial Sequence Number) is the initial PSN of the data sender,
   whereas the LSN (Lowest Sequence Number) represents the lowest
   sequence number of the DATA packets contained in the buffer.







Koh and Kim              Expires: April 2006                [Page 29]


                      ECTP for Duplex Multicast          October 2005


Security Considerations

   TBD


References

   [1]ITU-T Recommendation X.601 (2000), Multi-Peer Communications
      Framework

   [2]ITU-T Recomendation 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 draft Recommendation X.607 | ISO/IEC CD 14476-3, Working in
      Progress, Information Technology ù Enhanced Communications
      Transport Protocol: Specification of Duplex Multicast Transport
      (ECTP-3), available from http://protocol.knu.ac.kr/pub/ECTP-3-WD-
      01.pdf, 2005


Author's Addresses

   Seok J. Koh
   Department of Computer Science, Kyungpook National University, KOREA
   sjkoh@knu.ac.kr

   Dae Young Kim
   Chungnam National University, KOREA
   Qiaobing.Xie@motorola.com









Koh and Kim              Expires: April 2006                [Page 30]


                      ECTP for Duplex Multicast          October 2005



Intellectual Property

   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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


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 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.









Koh and Kim              Expires: April 2006                [Page 31]