ISO/IEC 14476-3:2008

Information technology — Enhanced communications transport protocol: Specification of duplex multicast transport — Part 3:

ISO/IEC 14476-3:2008 defines a protocol for duplex multicast transport over the Internet where IP multicast is supported. A control tree mechanism for scalability and an error control mechanism for reliable multicast data delivery are specified. Protocol details such as packet format, parameter values and procedures are specified. This protocol can be used for applications that require one-to-many as well as many-to-one data delivery services.

Technologies de l'information — Protocole de transport de communications amélioré: Spécification du transport multidiffusé duplex — Partie 3:

L'ISO/CEI 14476-3:2008 décrit un protocole de transport multidiffusé duplex sur Internet lorsque la multidiffusion IP est prise en charge. Elle définit le mécanisme d'arborescence de gestion en vue de l'échelonnabilité et le mécanisme de protection contre les erreurs en vue d'une transmission fiable de données multidiffusées. Elle décrit les détails du protocole, notamment le format des paquets, les valeurs des paramètres et les procédures. Le protocole peut être utilisé pour les applications qui nécessitent des services de transmission de données "de un à beaucoup" ("one-to-many") et "de beaucoup à un" ("many-to-one").

General Information

• Status: Published
• Publication Date: 31-Mar-2008
• ICS: 35.100.40 - Transport layer
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6/WG 7 - Network, transport and future network
• Current Stage: 9020 - International Standard under periodical review
• Start Date: 15-Oct-2025
• Completion Date: 15-Oct-2025

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 14476-3
First edition
2008-04-15
Information technology — Enhanced
communications transport protocol:
Specification of duplex multicast
transport
Technologies de l'information — Protocole de transport de
communications amélioré: Spécification pour le transport duplex en
multidiffusion
Reference number
©
ISO/IEC 2008
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2008
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2008 – All rights reserved

CONTENTS
Page
1 Scope. 1

2 Normative references . 1
3 Definitions . 1

4 Abbreviations . 2

5 Conventions . 3

6 Overview. 3
7 Design considerations. 5

7.1 Participants. 5
7.2 Control tree. 5

7.3 Data channels. 6

7.4 Addressing. 7
7.5 Tokens. 8

8 Packets. 8
8.1 Base header. 8

8.2 Extension elements. 10
8.3 Packet format . 13

9 Procedures . 25

9.1 Connection creation. 25
9.2 Late join. 25

9.3 Forward data transport . 26
9.4 Token control. 27

9.5 Backward data transport . 29
9.6 Reliability control . 29

9.7 Connection management . 31

Annex A – Timers and parameters. 32
A.1 Timers . 32

A.2 Parameters. 32
Annex B – State transition diagrams . 34

Annex C – Application programming interfaces. 36

© ISO/IEC 2008 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 14476-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 6, Telecommunications and information exchange between systems, in collaboration with
ITU-T. The identical text is published as ITU-T Rec. X.607 (02/2007).
ISO/IEC 14476 consists of the following parts, under the general title Information technology — Enhanced
communications transport protocol:
⎯ Part 1: Specification of simplex multicast transport
⎯ Part 2: Specification of QoS management for simplex multicast transport
⎯ Part 3: Specification of duplex multicast transport
⎯ Part 5: Specification of N-plex multicast transport

iv © ISO/IEC 2008 – All rights reserved

Introduction
This 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 operates over IPv4/IPv6 networks that have the IP multicast forwarding capability with the help of

IGMP and IP multicast routing protocols. ECTP could possibly be provisioned over UDP.
ECTP is designed to support tightly controlled multicast connections in simplex, duplex and N-plex applications. This

third part of ECTP (ITU-T Rec. X.607 | ISO/IEC 14476-3) specifies the protocol mechanisms for reliability control in
the duplex case. ECTP also provides QoS management functions for stable management of the QoS of the connection

users. The procedures for QoS management of the duplex case will be defined in the duplex QoS management
specification (ITU-T Rec. X.607.1 | ISO/IEC 14476-4).
In the 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. For example, in the panel conferencing, some of the TS-users may act
as a panel and transmit multicast data via TC-Owner (the conference convener) to the listener group. The detailed use of
the duplex multicast connection depends on the applications of this duplex multicast transport protocol.
© ISO/IEC 2008 – All rights reserved v

INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
Information technology – Enhanced communications transport protocol:
Specification of duplex multicast transport
1 Scope
This Recommendation | International Standard specifies the Enhanced Communications Transport Protocol (ECTP),
which is a transport protocol to support Internet multicast applications over the multicast-capable IP networks.
This Recommendation | International Standard specifies the ECTP part 3 (ECTP-3) for the duplex multicast transport
connection in which the participants are classified into one TC-Owner and many TS-users. The duplex multicast
transport connection supports two kinds of data transport: the multicast data transport from TC-owner to all the other
TS-users and the unicast data transport from TS-users to TC-Owner. A TS-user is allowed to send unicast data to
TC-Owner, only if it gets a token from TC-Owner.
This Specification describes the protocol for supporting the duplex multicast transport, which includes the connection
management (establishment, termination, pause, resumption, user join and leave) and the reliability control mechanisms
for the multicast and unicast data transport. In particular, the protocol operations for the multicast data transport from
TC-Owner to the TS-users will be designed with the congruency of the simplex multicast transport protocol (ECTP-1),
as specified in ITU-T Rec. X.606 | ISO/IEC 14476-1.
2 Normative references
The following Recommendations and International Standards contain provisions which, through reference in this text,
constitute provisions of this Recommendation | International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent
edition of the Recommendations and Standards listed below. Members of IEC and ISO maintain registers of currently
valid International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of currently
valid ITU-T Recommendations.
– ITU-T Recommendation X.601 (2000), Multi-peer communications framework.
– ITU-T Recomendation X.602 (2004) | ISO/IEC 16513:2005, Information technology – Group
management protocol.
– ITU-T Recommendation X.605 (1998) | ISO/IEC 13252:1999, Information technology – Enhanced
communications transport service definition.
– ITU-T Recommendation X.606 (2001) | ISO/IEC 14476-1:2002, Information technology – Enhanced
communications transport protocol: Specification of simplex multicast transport.
– ITU-T Recommendation X.606.1 (2003) | ISO/IEC 14476-2:2003, Information technology – Enhanced
communications transport protocol: Specification of QoS management for simplex multicast transport.
3 Definitions
This Recommendation | International Standard is based on the following definitions, which were specified in Enhanced
Communications Transport Service (ITU-T Rec. X.605 | ISO/IEC 13252).
a) Transport connection: Simplex, duplex and N-plex;
b) TC-Owner and TS-users.
This Recommendation | International Standard uses the following terminologies specified in Enhanced Communications
Transport Protocol: part 1 (ITU-T Rec. X.606 | ISO/IEC 14476-1).
a) control tree;
b) parent and children;
ITU-T Rec. X.607 (02/2007) 1
c) TO (Top Owner):
TO is a single sender of multicast data packets, which can transmit multicast data to the other TS-users,
and it manages overall operations of ECTP-3. The TO will be designated among the TS-users before the
connection begins, and the TO will do the functions of TC-Owner;
d) LO (Local Owner):
An LO is located on the control tree of ECTP-3. One or more LOs could be designated for scalable error
recovery and status monitoring in ECTP-3. An LO is also a TS-user, which can also receive the multicast
data from TO. LOs will be configured as a parent of the local groups through the control tree
configuration in ECTP-3; and
e) LE (Leaf Entity):
An LE is a leaf node on the ECTP-3 control tree. It is a TS-user in the ECTP-3 connection, and it can
receive multicast data sent by TO.
This Recommendation | International Standard also applies the following definitions:
a) SU (Sending TS-user):
Some of the ECTP-3 TS-users can send unicast data to the TO. A sending TS-user (SU) is a TS-user 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 user must request a token to TO.
b) Token:
It represents the right for a TS-user to transmit data. The TS-user who has a token is called a Sending TS-
user (SU). The tokens are managed by TO.
c) Forward data channel:
It represents the multicast data channel from TO to the group members. TO sends multicast data to all the
other group members over IP multicast address.
d) Backward data channel:
It represents the unicast data channel, in which the data packets flow from an SU to TO. An SU can send
unicast data to TO over IP unicast address.
4 Abbreviations
For the purposes of this Recommendation | International Standard, the following abbreviations apply, which includes
the ECTP-3 packets:
ACK Acknowledgment
CC Connection Creation Confirm
CR Connection Creation Request
CT Connection Termination Request
DT Data
HB Heartbeat
HBACK Heartbeat Acknowledgment
JC Late Join Confirm
JR Late Join Request
LE Leaf Entity
LO Local Owner
LR User Leave Request
ND Null Data
RD Retransmission Data
SU Sending TS-user
TC Tree Join Confirm
TGC Token Get Confirm
TGR Token Get Request
2 ITU-T Rec. X.607 (02/2007)
TJ Tree Join Request
TO Top Owner
TRC Token Return Confirm
TRR Token Return Request
TS Transport Services
5 Conventions
In this Recommendation | International Standard, the capital characters are used to represent a 'packet' of ECTP-3 (e.g.,
CR 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).
6 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. ECTP could possibly be provisioned over
UDP.
Internet multicast applications
Enhanced communications transport protocol
UDP
IP (Unicast/Multicast)
Figure 1 – ECTP model
This Recommendation | International Standard 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 the other 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 group members) and unicast data channel (sent by a TS-user to TO). Such a TS-user is called Sending TS-user
(SU) in the ECTP-3.
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.

Figure 2 – Data transport in ECTP-3
ITU-T Rec. X.607 (02/2007) 3
To establish a duplex multicast connection, TO transmits a Connection Creation Request (CR) packet to the group. The
CR packet contains the connection information including general characteristics of the connection. In particular, the
CR packet must indicate that the connection type is the duplex multicast transport. Each TS-user who wants to
participate in the connection will respond to the TO with a Connection Creation Confirm (CC) packet. The connection
creation operation will be completed when a predetermined CCT timer expires.
During the connection creation phase, a logical control tree is configured between TO and TS-users, or between
TS-users 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 TS-users. The parent TS-user is called Local Owner (LO). Based on the control
tree, the error recovery will be performed. To configure a control tree, each TS-user sends a Tree Join Request (TJ)
message to a candidate parent node that has already been connected to the tree. The parent node will respond to the
promising child TS-user with the Tree Join Confirm (TC) message. In this way, the control tree will gradually be
expanded from the root toward the leaf nodes.
Some of the prospective TS-users may join the connection as late-joiners. The late-joining TS-user participates in the
connection by sending a Late Join Request (JR) message to TO. In response to the JR message, TO sends a Late Join
Confirm (JC) message to the TS-user. The late-joiner TS-user will also join the control tree by using the TJ and
TC messages. For this purpose, the JC message of TO may include the information about the prospective parent
LO node for the late-joiner. The late-joining TS-user may try to connect to the prospective LO 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 TS-user to
TO. ECTP-3 provides the reliable data transport with error recovery, in which all the Data (DT) packets will be
recovered by the parent on the tree.
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 DT packets to the receiving TS-users. The TS-users will deliver the received DT 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 node 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 LO may retransmit the RD packets to its
children.
In the forward multicast data transport, the Heartbeat (HB) and Heartbeat ACK (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 Round Trip Time (RTT) for the group. For this purpose, the HB and HBACK packets contain a
timestamp.
For the backward unicast data transport, a certain TS-user in the connection may get a token from TO by sending a
Token Get Request (TGR) message. The TO will then respond to the TS-user with the Token Get Confirm (TGC)
message that contains a Token ID. Accordingly, the total number of tokens in the connection is controlled by TO. Token
ID is used to identify the sender of the unicast DT packets at the TO side. The TS-user who has a token is called
Sending TS-user (SU).
The SU can send unicast DT 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.
After completing the unicast data transmission, the SU will return the token to the TO by sending a Token Return
Request (TRR) message. TO will respond to the SU with a Token Return Confirm (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 TS-user may leave the connection by sending a
User Leave Request (LR) message to the parent. In a certain case, the parent may enforce a specific child node to leave
the connection by sending the LR 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 Null Data (ND) packets to the group. After
the TO has completed the data transport, it may terminate the duplex connection by sending a Connection Termination
Request (CT) message to the group.
4 ITU-T Rec. X.607 (02/2007)
7 Design considerations
In this clause, some considerations for ECTP-3 are described.
7.1 Participants
All participants to a duplex multicast connection are TS-users and one of them functions as TC-Owner.
TC-Owner:
In a duplex multicast connection the TC-owner is responsible for connection management including
connection creation/termination, late join, connection maintenance, and token management.
TS-user (Transport Service User):
A duplex multicast connection has one or more TS-users who can receive the multicast data from the
TC-Owner. Some of the TS-users can send unicast data to the TC-Owner.
A TS-user can become TO, LO or LE, depending on its role.
TO (Top Owner):
A duplex multicast connection has a single TO, which corresponds to the TC-Owner. 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.
LO (Local Owner):
In the duplex multicast connection, an LO is a TS-user who is responsible for error recovery to the local group
by retransmission of data. On the control tree hierarchy of ECTP-3, an LO is a parent node and has its
children nodes. Note that an LO is also a TS-user. That is, an LO also receives multicast data from the TO. In
ECTP-3, a TS-user may act as an LO in the connection, or some designated LOs may be used for the error
recovery in the connection. It depends on the deployment of ECTP-3.
LE (Leaf Entity):
In the duplex multicast connection, an LE represents a leaf node on the control tree. Each LE is a TS-user that
receives the multicast data from the TO.
A TS-user can become SU when it obtains a token from TC-Owner.
SU (Sending TS-user):
An SU is a TS-user who can send unicast data to TO. In the duplex multicast connection, a TS-user becomes
an SU when it has a token and it can thus transmit unicast data to TO.
7.2 Control tree
A duplex multicast connection may configure a control tree for scalable reliability control as shown in Figure 3:

Figure 3 – Control tree in ECTP-3
ITU-T Rec. X.607 (02/2007) 5
In the ECTP-3 control tree, TO is on the top of the tree, which is in the Tree Level 0. An LO is a parent node on the tree
and has one or more children. A TS-user, not designated as LO, is called a Leaf Entity (LE), which 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 LO. In response to the request, the parent LO will retransmit the data packets to the children,
if it has them in the buffer. An LO is also a TS-user, 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.
7.3 Data channels
In ECTP-3, the two types of data channels are used: forward and backward data channels.
7.3.1 Forward data channel
The forward data channel is used for TO to send multicast data to the other members. The forward multicast data
channel can also be used for an LO to send Retransmission Data to its children users.
The forward data channel address consists of the group (multicast) IP address and the group port. TO sends multicast
data via DT packets by using the forward data channel address. TO and LOs can also retransmit multicast data via RD
packets by using the forward data channel address.
Figure 4 illustrates the use of the forward multicast data channels in ECTP-3.

Figure 4 – Forward data channels and control tree in ECTP-3
7.3.2 Backward data channel
The backward data channel is used by a Sending TS-user (SU) to send unicast data to TO. The backward channel
address consists of the IP address of TO and the 'group' port.
Figure 5 illustrates the use of the backward unicast data channels in ECTP-3.

Figure 5 – Backward data channels in ECTP-3
6 ITU-T Rec. X.607 (02/2007)
Each SU must send unicast data via DT and RD 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.
7.4 Addressing
In ECTP-3, each packet uses the following types of IP addresses and port number for its source and destination address:
a) group IP address and local IP address;
b) group port and local port.
7.4.1 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, LOs and LEs.
The group IP address is used as the destination address of the packets that need to be multicast by TO and LOs. For
example, the CR and DT packets of TO will use the group IP address as the destination address of the associated
IP packets. Each LO also uses the group IP address as the destination address of the RD 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 signalling such as Web announcement.
7.4.2 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 LOs, such as CR and DT. That is, each TS-user 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 Late Join.
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 (JR) from a TS-user, the TO will
respond with the Late Join Confirm (JC) message that use the local port of the TS-user as the destination port.
The detailed use of the local IP address and port is specified below for each of the ECTP-3 packets.
7.4.3 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 signalling
such as Web announcement.
a) group IP address and group port;
b) local IP address of TO.
Figure 6 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.
The detailed use of the group and local addresses for the other packets will be specified later.
ITU-T Rec. X.607 (02/2007) 7
Figure 6 – Data channel addressing in ECTP-3
7.5 Tokens
In ECTP-3, a token represents the right for a TS-user 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 TS-user 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.
8 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. The ECTP-3 packet format is illustrated in Figure 7:

bytes 0 . 15 16 . . PL-1
Base header Extension elements or user data

PL Packet Length
Figure 7 – ECTP-3 packet format
8.1 Base header
The 16-byte base header contains the information helpful to all the protocol operations, in particular for the data
packets. Figure 8 shows the structure of the base header, when ECTP operates over IP.

0    1    2    3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Next element Version CT Packet type Checksum
Source port Destination port
Packet sequence number (PSN)
Payload length F Reserved Token ID
Figure 8 – Base header (ECTP over IP)
The base header contains the following information:
a) 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.
8 ITU-T Rec. X.607 (02/2007)
b) Version (2 bits)
This defines the version of the ECTP-3 protocol. Its current version is encoded as '00'.
c) CT (Connection type): (2 bits)
This specifies the type of the ECTP connection. The encoding value for the connection type is as
follows:
1) 01 – simplex multicast connection (for ECTP-1 and ECTP-2);
2) 10 – duplex multicast connection (for ECTP-3 and ECTP-4);
3) 11 – N-plex 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.
d) 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.
e) 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 one's complement
arithmetic operation, as done in TCP and UDP.
f) Source port (16 bits) and destination port (16 bits)
These port numbers are used to identify the sending and receiving applications for the case of ECTP-3
over IP. When ECTP-3 operates over UDP, these fields are used to represent the connection identifier, as
described later.
g) PSN (32 bits)
This value represents the sequence number of the data packet for the ECTP-3 DT or RD packets. For
some control packets such as ND 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 '2 – 1'.
h) Payload length (16 bits)
This value indicates the total length of the extension headers or user data in byte, following the base
header.
i) F (1 bit)
It is a flag bit. The use of this flag depends on the packet types:
1) For the JC (Late Join Confirm), TJ (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;
2) For the LR (User Leave Request) packet, F is set to '1' for the user-invoked leave, or set to '0' for the
troublemaker ejection;
3) For the CT (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 other packets, the detailed description is given in the protocol procedure clause. Otherwise, if any
usage is not specified, this field will be ignored.
j) Reserved (7 bits)
This field is reserved for future use.
k) Token ID (8 bits)
The Token ID is valid only for data packets: DT and RD 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 will set this field to '0'.
On the other hand, when ECTP operates over UDP, the packet header does not need to specify the source and
destination ports, which will be referred to from the UDP header. In this case, the 32-bit field for the source and
destination ports will be filled with 'Connection ID'. By default, it may be set to be the IPv4 group address.
ITU-T Rec. X.607 (02/2007) 9
The base header format for ECTP over UDP is as shown in Figure 9:

0    1    2    3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Next element Version CT Packet type Checksum
Connection ID
Packet sequence number
Payload length F Reserved Token ID
Figure 9 – Base header (ECTP over UDP)
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 CR or JC packets. All the other ECTP-3 packets must set this field to be the value announced by TO.
8.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 have the field of 'Next element' that points to the immediately succeeding extension
element, if any.
The Next element field is encoded as shown in Table 1. 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
Encoding value in next element
Length of extension element
Extension element
of the preceding element
(bytes)
(4 bits)
No element 0000 0
Connection 0001 4
Acknowledgment 0010 Varied
Membership 0011 4
Timestamp 0100 12
Address 0110 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 subclause by encompassing the requirements for
the ECTP-3 protocol.
8.2.1 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 CR, JC and TGR packets. The element structure is shown in Figure 10, which has the length of '4' bytes:

0    1    2    3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Next element TCO R AGN Maximum segment size (MSS)
Figure 10 – Connection extension element
10 ITU-T Rec. X.607 (02/2007)
Each field is specified as follows:
a) Next element (4 bits)
This indicates the type of the next extension element, as indicated in Table 1.
b) TCO (Tree Configuration Option): (2 bits)
This specifies the tree configuration option used in this ECTP-3 connection as follows:
1) 00 – Level 1 configuration:
No LO is used in the connection. Thus all TS-users must be connected to the TO as their parent on
the control tree.
2) 01 – Level 2 configuration:
A control tree with the tree level of 2 is configured: TO Ù LO Ù LE. Each LE may be connected
to an LO or directly to TO. The LEs are all connected to TO on the tree.
3) 10 – General configuration:
In this option, a control tree with more than two tree-levels may be configured.
4) 11 – Reserved for future use.
c) R (Reserved): (2 bits)
Reserved for future use.
d) AGN (ACK Generation Number): (8 bits)
This is a positive integer ranged from 1 to 255 that represents the ACK Generation Number. The AGN is
used to generate and transmit an ACK packet by a child user in the ECTP-3 protocol.
e) MSS (16 bits)
This specifies the maximum size of the user data segment that can be contained in an ECTP-3 DT packet
in byte. An ECTP-3 DT packet can maximally contain '65535' bytes of user data. The default value is
'1024'.
8.2.2 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.
This element consists of the fixed 4-bytes and the variable size of ACK Bitmap, as depicted in Figure 11.

0    1    2    3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Next element Bitmap length Valid bitmap length Reserved

ACK bitmap
Figure 11 – Acknowledgement extension element
Each field is specified as follows:
a) Next element (4 bits)
This indicates the type of the next extension element, as indicated in Table 1.
b) Bitmap length (4 bits)
This specifies the total size of the variable ACK Bitmap in unit of word (4 bytes), which excludes the
fixed 8 bytes. It is noted that the maximum value of Bitmap Length is '8' (words).
c) Valid bitmap length (8 bits)
This represents the length of the actually valid portion in 'bit' for the ACK Bitmap.
ITU-T Rec. X.607 (02/2007) 11
d) Reserved (16 bits)
This is reserved for future use. In particular, some information on QoS management may be specified in
this field by ECTP-4.
e) ACK bitmap (variable)
This represents information by using '0' or '1' about which data packets have been received (1) or lost (0)
at the receiver side. In the ACK Bitmap, the bitmap information starts with the LSN sequence number,
which represents the sequence number of the lowest numbered DT packet that has not been received yet
at the receiver side. The LSN will be specified in the PSN field of the base header. The ACK Bitmap
contains the total bitmap inf
...

NORME ISO/CEI
INTERNATIONALE 14476-3
Première édition
2008-04-15
Technologies de l'information —
Protocole de transport de
communications amélioré: Spécification
du transport multidiffusé duplex
Information technology — Enhanced communications transport
protocol: Specification of duplex multicast transport

Numéro de référence
ISO/CEI 14476-3:2008(F)
©
ISO/CEI 2008
ISO/CEI 14476-3:2008(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier
peut être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence
autorisant l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées
acceptent de fait la responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute
responsabilité en la matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info
du fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir
l'exploitation de ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation,
veuillez en informer le Secrétariat central à l'adresse donnée ci-dessous.

DOCUMENT PROTÉGÉ PAR COPYRIGHT

©  ISO/CEI 2008
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous
quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Publié en Suisse
ii © ISO/CEI 2008 – Tous droits réservés

ISO/CEI 14476-3:2008(F)
TABLE DES MATIÈRES
Page
1 Champ d'application. 1
2 Références normatives. 1

3 Définitions . 1
4 Abréviations. 2
5 Conventions . 3
6 Généralités. 3
7 Considérations en matière de conception. 5
7.1 Participants. 5
7.2 Arborescence de gestion. 6
7.3 Voies de transmission de données. 7
7.4 Adressage. 8
7.5 Jetons . 9
8 Paquets. 9
8.1 En-tête de base . 9
8.2 Eléments d'extension . 11
8.3 Format de paquet . 15
9 Procédures . 26
9.1 Création de connexion. 27
9.2 Participation tardive. 27
9.3 Transport de données vers l'avant . 28
9.4 Gestion des jetons . 30
9.5 Transport de données vers l'arrière. 31
9.6 Gestion de la fiabilité. 31
9.7 Gestion de la connexion . 33
Annexe A – Temporisateurs et paramètres . 35
A.1 Temporisateurs. 35
A.2 Paramètres. 35
Annexe B – Diagrammes de transition d'état. 37
Annexe C – Interfaces de programmation d'application . 39

© ISO/CEI 2008 – Tous droits réservés iii

ISO/CEI 14476-3:2008(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) et la CEI (Commission électrotechnique internationale)
forment le système spécialisé de la normalisation mondiale. Les organismes nationaux membres de l'ISO ou
de la CEI participent au développement de Normes internationales par l'intermédiaire des comités techniques
créés par l'organisation concernée afin de s'occuper des domaines particuliers de l'activité technique. Les
comités techniques de l'ISO et de la CEI collaborent dans des domaines d'intérêt commun. D'autres
organisations internationales, gouvernementales et non gouvernementales, en liaison avec l'ISO et la CEI
participent également aux travaux. Dans le domaine des technologies de l'information, l'ISO et la CEI ont créé
un comité technique mixte, l'ISO/CEI JTC 1.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale du comité technique mixte est d'élaborer les Normes internationales. Les projets de
Normes internationales adoptés par le comité technique mixte sont soumis aux organismes nationaux pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des
organismes nationaux votants.
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO et la CEI ne sauraient être tenues pour
responsables de ne pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO/CEI 14476-3 a été élaboré par le comité technique mixte ISO/CEI JTC 1, Technologies de l'information,
sous-comité SC 6, Téléinformatique, en collaboration avec l'UIT-T. Le texte identique est publié en tant que
Rec. UIT-T X.607 (02/2007).
L'ISO/CEI 14476 comprend les parties suivantes, présentées sous le titre général Technologies de
l'information — Protocole de transport de communications amélioré:
⎯ Partie 1: Spécification pour le transport simplex en multidiffusion
⎯ Partie 2: Spécification de la gestion de la qualité de service pour le transport simplex en multidiffusion
⎯ Partie 3: Spécification du transport multidiffusé duplex
⎯ Partie 5: Spécification du transport multidiffusé N-plex

iv © ISO/CEI 2008 – Tous droits réservés

ISO/CEI 14476-3:2008(F)
Introduction
La présente Recommandation | Norme internationale définit le protocole de transport de communications amélioré
(ECTP, enhanced communications transport protocol), qui est un protocole de transport visant à prendre en charge les
ap plications multidiffusion Internet fonctionnant sur les réseaux pouvant assurer la multidiffusion. Le protocole ECTP
fonctionne sur les réseaux IPv4/IPv6 ayant une capacité de transmission multidiffusion IP au moyen de protocoles de
routage multidiffusion IP et IGMP. Le protocole ECTP peut être configuré en mode UDP.

Le protocole ECTP a pour objet de prendre en charge les connexions multidiffusion étroitement gérées dans des
applications simplex, duplex et N-plex. La troisième partie du protocole ECTP (Rec. UIT-T X.607 | ISO/CEI 14476-3)
définit les mécanismes protocolaires visant à assurer la gestion de la fiabilité en mode duplex. Le protocole ECTP
définit aussi les fonctions de gestion de la qualité de service (QS) en vue d'une gestion QS stable pour les utilisateurs de
la connexion. Les procédures de gestion QS pour les transmissions seront définies dans la spécification relative à la
gestion de la qualité de service en mode duplex (Rec. UIT-T X.607.1 | ISO/IEC 14476-4).
Dans la connexion multidiffusée duplex, les participants sont le propriétaire de la connexion TC (TC-owner) et de
nombreux utilisateurs du service de transport TS (TS-user). Le propriétaire de la connexion TC sera choisi parmi les
utilisateurs du service TS avant le début de la connexion. Dans la connexion multidiffusée duplex, deux types de
transport de données sont pris en charge: le transport de données multidiffusées du propriétaire de la connexion TC vers
tous les autres utilisateurs du service TS et le transport de données unidiffusées des utilisateurs du service TS vers le
propriétaire de la connexion TC. Après la création de la connexion, le propriétaire de la connexion TC peut transmettre
des données multidiffusées au groupe, tandis que chaque utilisateur du service TS est autorisé à envoyer des données
unidiffusées au propriétaire de la connexion TC juste après avoir obtenu un jeton de ce dernier.
Dans le protocole ECTP, le propriétaire de la connexion TC est au centre des communications multidiffusées de groupe.
Il est chargé de la gestion globale de la connexion et, pour ce faire, il gère la création et la fin de la connexion, les
pauses et les reprises, ainsi que les opérations de participation tardive ou de sortie.
La connexion multidiffusée duplex définie dans le protocole ECTP-3 vise les applications multidiffusion dans
lesquelles le propriétaire de la connexion TC (un expéditeur multidiffusion unique) transmet des données à tous les
autres utilisateurs du service TS et dans lesquelles certains des utilisateurs du service TS répondent à l'expéditeur
multidiffusion au moyen des données de réaction multidiffusées. En général, le transport multidiffusé duplex convient
bien pour les applications multidiffusion "de un à beaucoup" qui nécessitent les voies de réaction unidiffusion
provenant de certains utilisateurs du service TS (par exemple, l'enseignement à distance, la radiodiffusion Internet, etc.).
Ainsi, dans une application d'enseignement à distance, l'expéditeur multidiffusion (l'enseignant) transmet des données
telles que la voix, du texte et des images à un groupe d'étudiants, alors que certains des étudiants peuvent répondre à
l'enseignant par des données unidiffusées comme des questions pour confirmation.
Il convient de noter que cette connexion multidiffusée duplex peut aussi être utilisée pour des applications
multidiffusion "de plusieurs à beaucoup" (some-to-many) (notamment dans une conférence de groupe) dans lesquelles
quelques utilisateurs du service TS veulent envoyer des données multidiffusées au groupe. Dans ce cas de figure, les
données multidiffusées émanant des utilisateurs du service TS peuvent d'abord être transmises au propriétaire de la
connexion TC en mode unidiffusion, puis le propriétaire de la connexion transmettra les données unidiffusées reçues au
groupe en mode multidiffusion. Par exemple, dans la conférence de groupe, certains des utilisateurs du service TS
peuvent agir en tant que groupe et transmettre les données multidiffusées au groupe d'auditeurs par l'intermédiaire du
propriétaire de la connexion TC (l'organisateur de la conférence). L'utilisation détaillée de la connexion multidiffusée
duplex dépend des applications du protocole de transport multidiffusé duplex.

© ISO/CEI 2008 – Tous droits réservés v

ISO/CEI 14476-3:2008 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
Technologies de l'information – Protocole de transport de communications amélioré –
Spécification du transport multidiffusé duplex
1 Champ d'application
La présente Recommandation | Norme internationale définit le protocole de transport de communications amélioré
(ECTP, enhanced communications transport protocol), qui est un protocole de transport visant à prendre en charge les
applications multidiffusion Internet fonctionnant sur les réseaux pouvant assurer la multidiffusion.
La présente Recommandation | Norme internationale définit la partie 3 du protocole ECTP (ECTP-3) pour la connexion
de transport multidiffusé duplex dans laquelle les participants sont un propriétaire de la connexion TC et de nombreux
utilisateurs du service TS. La connexion de transport multidiffusé duplex prend en charge deux types de transport de
données: le transport de données multidiffusées du propriétaire de la connexion TC vers tous les autres utilisateurs du
service TS et le transport de données unidiffusées des utilisateurs du service TS vers le propriétaire de la connexion TC.
Un utilisateur du service TS est autorisé à envoyer des données unidiffusées au propriétaire de la connexion TC
uniquement s'il obtient un jeton du propriétaire de la connexion TC.
La présente spécification décrit le protocole de prise en charge du transport multidiffusé duplex, qui comprend le
mécanisme de gestion de la connexion (établissement, fin, pause, reprise, participation et sortie des utilisateurs) et le
mécanisme de gestion de la fiabilité en vue du transport de données multidiffusées et unidiffusées. En particulier, les
opérations protocolaires concernant le transport de données multidiffusées du propriétaire de la connexion TC vers les
utilisateurs du service TS seront conçues conformément au protocole de transport multidiffusé simplex (ECTP-1),
comme indiqué dans la Rec. UIT-T X.606 | ISO/CEI 14476-1.
2 Références normatives
Les Recommandations et Normes internationales suivantes contiennent des dispositions qui, par suite de la référence
qui y est faite, constituent des dispositions valables pour la présente Recommandation | Norme internationale. Au
moment de la publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes sont sujettes à
révision et les parties prenantes aux accords fondés sur la présente Recommandation | Norme internationale sont
invitées à rechercher la possibilité d'appliquer les éditions les plus récentes des Recommandations et Normes indiquées
ci-après. Les membres de la CEI et de l'ISO possèdent le registre des Normes internationales en vigueur. Le Bureau de
la normalisation des télécommunications de l'UIT tient à jour une liste des Recommandations de l'UIT-T en vigueur.
– Recommandation UIT-T X.601 (2000), Cadre général des communications entre homologues multiples.
– Recommandation UIT-T X.602 (2004) | ISO/CEI 16513:2005, Technologies de l'information – Protocole
de gestion de groupe.
– Recommandation UIT-T X.605 (1998) | ISO/CEI 13252:1999, Technologies de l'information –
Définition du service de transport de communications amélioré.
– Recommandation UIT-T X.606 (2001) | ISO/CEI 14476-1:2002, Technologies de l'information –
Protocole de transport de communications amélioré: spécification du transport simplex en
multidiffusion.
– Recommandation UIT-T X.606.1 (2003) | ISO/CEI 14476-2:2003, Technologies de l'information –
Protocole de transport de communications amélioré: spécification de la gestion de la qualité de service
pour le transport simplex en multidiffusion.
3 Définitions
La présente Recommandation | Norme internationale est fondée sur les définitions ci-après, qui sont indiquées dans la
Rec. UIT-T X.605 | ISO/CEI 13252 (service de transport de communications amélioré).
a) Connexion de transport: simplex, duplex et N-plex.
b) Propriétaire de la connexion TC et utilisateurs du service TS.
Rec. UIT-T X.607 (02/2007) 1
ISO/CEI 14476-3:2008 (F)
La présente Recommandation | Norme internationale utilise les termes suivants, qui sont définis dans la
Rec. UIT-T X.606 | ISO/CEI 14476-1 (protocole de transport de communications amélioré: partie 1).
a) Arborescence de gestion.
b) Parent et enfants.
c) Propriétaire principal (TO, top owner):
Le propriétaire principal est l'unique expéditeur de paquets de données multidiffusées qui peut
transmettre des données multidiffusées aux autres utilisateurs du service TS et il gère les opérations
globales du protocole ECTP-3. Il sera choisi entre les utilisateurs du service TS avant le début de la
connexion et assurera les fonctions du propriétaire de la connexion TC.
d) Propriétaire local (LO, local owner):
Un propriétaire local est situé sur l'arborescence de gestion ECTP-3. Un ou plusieurs propriétaires locaux
peuvent être désignés en vue d'une reprise après erreur échelonnable et d'un contrôle d'état dans le
protocole ECTP-3. C'est aussi un utilisateur du service TS qui peut recevoir les données multidiffusées
en provenance du propriétaire principal (TO). Les propriétaires locaux peuvent être configurés en tant
que parents des groupes locaux dans le cadre de la configuration de l'arborescence de gestion ECTP-3; et
e) Entité feuille (LE, leaf entity):
Une entité feuille est un nœud feuille sur l'arborescence de gestion ECTP-3. C'est un utilisateur du
service TS dans la connexion ECTP-3 et il peut recevoir les données multidiffusées envoyées par le
propriétaire principal.
La présente Recommandation | Norme internationale applique aussi les définitions suivantes:
a) Utilisateur du service TS expéditeur (SU, sending TS-user):
Dans le protocole ECTP-3, certains des utilisateurs du service TS peuvent envoyer des données
unidiffusées au propriétaire principal. Un utilisateur du service TS expéditeur (SU) est un utilisateur du
service TS qui obtient un jeton auprès du propriétaire principal. Seul l'utilisateur expéditeur SU est
autorisé à envoyer des données unidiffusées au propriétaire principal. Autrement dit, avant d'envoyer des
données unidiffusées, chaque utilisateur doit demander un jeton au propriétaire principal.
b) Jeton:
Représente le droit pour un utilisateur du service TS de transmettre des données. L'utilisateur du service
TS qui a un jeton est l'utilisateur du service TS expéditeur (SU). Les jetons sont gérés par le propriétaire
principal.
c) Voie de transmission de données vers l'avant:
Représente la voie de transmission des données multidiffusées du propriétaire principal vers les membres
du groupe. Le propriétaire principal envoie des données multidiffusées à tous les membres du groupe à
l'adresse IP multidiffusion.
d) Voie de transmission de données vers l'arrière:
Représente la voie de transmission des données multidiffusées dans laquelle les paquets de données
circulent d'un utilisateur expéditeur SU vers le propriétaire principal. Un utilisateur expéditeur SU peut
envoyer des données unidiffusées au propriétaire principal à une adresse IP unidiffusion.
4 Abréviations
Pour les besoins de la présente Recommandation | Norme internationale, les abréviations suivantes s'appliquent et visent
les paquets utilisés dans le protocole ECTP-3.
ACK accusé de réception (acknowledgment)
CC confirmation de création de connexion (connection creation confirm)
CR demande de création de connexion (connection creation request)
CT demande de fin de connexion (connection termination request)
DT données (data)
HB pulsation (heartbeat)
HBACK accusé de réception de pulsation (heartbeat acknowledgment)
JC confirmation de participation tardive (late join confirm)
JR demande de participation tardive (late join request)
2 Rec. UIT-T X.607 (02/2007)
ISO/CEI 14476-3:2008 (F)
LE entité feuille (leaf entity)
LO propriétaire local (local owner)
LR demande de sortie d'un utilisateur (user leave request)
ND données nulles (null data)
RD données de retransmission (retransmission data)
SU utilisateur du service TS expéditeur (sending TS-user)
TC confirmation de participation à l'arborescence (tree join confirm)
TGC confirmation d'obtention de jeton (token get confirm)
TGR demande d'obtention de jeton (token get request)
TJ demande de participation à une arborescence (tree join request)
TO propriétaire principal (top owner)
TRC confirmation de restitution de jeton (token return confirm)
TRR demande de restitution de jeton (token return request)
TS services de transport (transport services)
5 Conventions
Dans la présente Recommandation | Norme internationale, les caractères en majuscules représentent un "paquet" du
protocole ECTP-3 (par exemple, CR pour le paquet de demande de création de connexion) et les caractères en
majuscules et en italiques les "temporisateurs" ou "variables" utilisés dans le protocole ECTP-3 (par exemple, CCT pour
le temporisateur de création de connexion et AGN pour la fréquence de création de paquets ACK).
6 Généralités
Le protocole de transport de communications amélioré (ECTP) est un protocole de transport visant à prendre en charge
les applications multidiffusion Internet fonctionnant sur les réseaux pouvant assurer la multidiffusion. Il fonctionne sur
les réseaux IPv4/IPv6 ayant une capacité de transmission multidiffusion IP au moyen de protocoles de routage
multidiffusion IP et IGMP, comme indiqué à la Figure 1. Le protocole ECTP peut être configuré en mode UDP.

Applications multidiffusion Internet
Protocole de transport de communications amélioré
UDP
IP (unidiffusion/multidiffusion)
Figure 1 – Modèle de protocole ECTP
La présente Recommandation | Norme internationale décrit la spécification du protocole ECTP, partie 3 (ECTP-3) pour
la connexion multidiffusée duplex, qui permet de prendre en charge le transport de données multidiffusées entre des
participants qui comprennent un seul propriétaire de la connexion TC (propriétaire principal (TO)) et les autres
utilisateurs du service TS. Une connexion multidiffusée duplex prend en charge deux types de voies de données entre
les participants: la voie de transmission de données multidiffusées (envoyée par le propriétaire principal à tous les autres
membres du groupe) et la voie de transmission de données unidiffusées (envoyée par un utilisateur du service TS au
propriétaire principal). Cet utilisateur du service TS est l'utilisateur du service TS expéditeur (SU) dans le protocole
ECTP-3.
La Figure 2 montre les deux types de voies de transport de données utilisées dans la connexion multidiffusée duplex.
Comme l'indique la figure, le propriétaire principal peut transmettre des données multidiffusées aux autres utilisateurs
du service TS à l'adresse IP multidiffusion (de groupe). Certains utilisateurs expéditeurs SU peuvent envoyer des
données unidiffusées au propriétaire principal. L'utilisateur expéditeur SU doit d'abord obtenir un jeton auprès du
propriétaire principal avant d'envoyer les données unidiffusées.
Rec. UIT-T X.607 (02/2007) 3
ISO/CEI 14476-3:2008 (F)
Figure 2 – Transport de données dans le protocole ECTP-3
Pour établir une connexion multidiffusée duplex, le propriétaire principal transmet au groupe un paquet de demande de
création de connexion (CR, connection creation request). Le paquet CR contient les informations de connexion, y
compris les caractéristiques générales de la connexion. En particulier, le paquet CR doit indiquer que le type de
connexion est le transport multidiffusé duplex. Chaque utilisateur du service TS désireux de participer à la connexion
répondra au propriétaire principal par un paquet de confirmation de création de connexion (CC, connection creation
confirm). L'opération de création de connexion s'achèvera à l'expiration d'un temporisateur CCT prédéterminé.
Pendant la phase de création de connexion, une arborescence de gestion logique est configurée entre le propriétaire
principal et les utilisateurs du service TS, ou entre les utilisateurs du service TS, pour assurer la gestion échelonnable de
la fiabilité. La racine étant le propriétaire principal, l'arborescence de gestion définit une relation parent-enfant par paire
d'utilisateurs du service TS. L'utilisateur du service TS parent est le propriétaire local (LO). La reprise après erreur aura
lieu selon l'arborescence de gestion. Pour configurer une arborescence de gestion, chaque utilisateur du service TS
envoie un message de demande de participation à une arborescence (TJ, tree join request) à un nœud parent candidat
qui a déjà été connecté à l'arborescence. Le nœud parent répondra à l'utilisateur du service TS enfant potentiel par le
message de confirmation de participation à une arborescence (TC, tree join confirm). Ainsi, l'arborescence de gestion se
développera progressivement de la racine vers les nœuds feuilles.
Certains des utilisateurs du service TS potentiels peuvent participer à la connexion en tant que participants tardifs.
L'utilisateur du service TS qui est un participant tardif se joint à la connexion en envoyant au propriétaire principal un
message de demande de participation tardive (JR, late join request). En réponse au message JR, le propriétaire principal
envoie à l'utilisateur du service TS un message de confirmation de participation tardive (JC, late join confirm).
L'utilisateur du service TS qui est un participant tardif se joindra aussi à l'arborescence de gestion au moyen des
messages TJ et TC. A cette fin, le message JC du propriétaire principal peut comprendre des informations sur le nœud
LO parent potentiel à l'intention du participant tardif. L'utilisateur du service TS qui est un participant tardif peut
essayer de se connecter au nœud LO potentiel pour configurer l'arborescence de gestion.
Une fois la connexion établie, la phase de transmission de données commence. Le protocole ECTP-3 prend en charge
les deux types de voies de données, à savoir la voie multidiffusion vers l'avant, du propriétaire principal vers le groupe,
et la voie multidiffusion vers l'arrière, de l'utilisateur du service TS vers le propriétaire principal. Il assure le transport
fiable de données avec reprise après erreur, dans lequel tous les paquets de données (DT) seront récupérés par le parent
sur l'arborescence.
Dans la transmission de données multidiffusées vers l'avant, le propriétaire principal peut commencer à transmettre des
données multidiffusées au groupe au moyen de l'adresse IP multidiffusion et du numéro de port de groupe. Les paquets
de données multidiffusées envoyés par le propriétaire principal seront segmentés séquentiellement et transmis par
paquets DT aux utilisateurs du service TS destinataires. Les utilisateurs du service TS transmettront les paquets DT
reçus à l'application de couche supérieure dans l'ordre de transmission appliqué par le propriétaire principal.
Pour la voie de transmission vers l'avant de données multidiffusées provenant du propriétaire principal, la protection
contre les erreurs sera assurée sur la base du groupe local défini par l'arborescence de gestion ECTP. Si un nœud enfant
détecte une perte de données, il envoie une demande de retransmission à son parent au moyen de paquets ACK. Chaque
enfant crée un paquet ACK selon la fréquence de création des paquets ACK (AGN, ACK generation number).
Autrement dit, un paquet ACK est créé pour un nombre de paquets de données du propriétaire principal égal à la valeur
d'AGN. Un message ACK message contient une "suite binaire" indiquant quels paquets de données ont été reçus ou
non. En réponse au paquet ACK, chaque propriétaire local (LO) parent peut retransmettre les paquets RD à ses enfants.
4 Rec. UIT-T X.607 (02/2007)
ISO/CEI 14476-3:2008 (F)
Dans le transport de données multidiffusées vers l'avant, les paquets de pulsation (HB, heartbeat) et d'accusé de
réception de pulsation (HBACK, heartbeat ACK) sont utilisés entre un parent et ses enfants pour la mise à jour de
l'arborescence de gestion. Un parent transmet des paquets HB à ses enfants après chaque délai de création de paquets
HB (HGT, HB generation time). Le paquet HB indique quel enfant doit lui répondre au moyen du paquet HBACK.
L'enfant correspondant enverra un paquet HBACK au parent. Le paquet HB peut aussi être utilisé par le parent pour
calculer le temps de transmission aller retour (RTT, round trip time) pour le groupe. A cette fin, les paquets HB et
HBACK contiennent un horodateur.
Pour le transport de données unidiffusées vers l'arrière, un utilisateur du service TS dans la connexion peut obtenir un
jeton auprès du propriétaire principal (TO) en envoyant un message de demande d'obtention de jeton (TGR, token get
request). Le propriétaire principal répondra alors à l'utilisateur du service TS par le message de confirmation d'obtention
de jeton (TGC, token get confirm) qui contient un ID de jeton. En conséquence, le nombre total de jetons de la
connexion est géré par le propriétaire principal. L'ID de jeton permet d'identifier l'expéditeur des paquets DT
unidiffusés du côté du propriétaire principal. L'utilisateur du service TS qui a un jeton est l'utilisateur du service TS
expéditeur (SU).
L'utilisateur expéditeur SU peut envoyer des paquets DT unidiffusés au propriétaire principal. Pour la reprise après
erreur et la gestion des encombrements, les paquets HB et HBACK sont échangés entre l'utilisateur expéditeur SU et le
propriétaire principal. L'utilisateur expéditeur SU envoie un message HB au propriétaire principal. Le propriétaire
principal répond ensuite par le paquet HBACK qui contient des informations d'accusé de réception, comme c'est le cas
des paquets ACK dans la voie multidiffusion vers l'avant. Il convient de noter que le paquet HBACK est utilisé pour la
demande de retransmission sur la voie vers l'arrière.
Après avoir achevé la transmission des données unidiffusées, l'utilisateur expéditeur SU restituera le jeton au
propriétaire principal en envoyant un message de demande de restitution de jeton (TRR, token return request). Le
propriétaire principal répondra à l'utilisateur expéditeur SU par un message de confirmation de restitution de jeton
(TRC, token return confirm).
Les opérations de gestion de connexion font partie de la connexion (sortie des utilisateurs, pause et reprise de la
connexion, fin). Dans l'opération de sortie d'un utilisateur, un utilisateur du service TS participant peut quitter la
connexion en envoyant au parent un message de demande de sortie d'un utilisateur (LR, user leave request). Dans
certains cas, le parent peut forcer un nœud enfant déterminé à quitter la connexion en envoyant le message LR (éjection
des éléments perturbateurs). Le propriétaire principal peut temporairement effectuer une pause puis reprendre la
connexion. Pendant la période de pause, le propriétaire principal enverra au groupe des paquets de données nulles (ND,
null data). Lorsque le propriétaire principal a achevé le transport de données, il peut mettre fin à la connexion duplex en
envoyant au groupe un message de demande de fin de connexion (CT, connection termination request).
7 Considérations en matière de conception
On trouvera dans le présent paragraphe quelques considérations concernant le protocole ECTP-3.
7.1 Participants
Tous les participants à une connexion multidiffusée duplex sont des utilisateurs du service TS et l'un d'entre eux agit en
tant que propriétaire de la connexion TC.
Propriétaire de la connexion TC
Dans une connexion multidiffusée duplex, le propriétaire de la connexion TC est responsable de la gestion de
la connexion, y compris de la création/fin de la connexion, des participations tardives, de la mise à jour de la
connexion et de la gestion des jetons.
Utilisateur du service TS (utilisateur du service de transport)
Une connexion multidiffusée duplex comporte un ou plusieurs utilisateurs du service TS qui peuvent recevoir
des données multidiffusées en provenance du propriétaire de la connexion TC. Quelques utilisateurs du
service TS peuvent envoyer des données unidiffusées au propriétaire de la connexion TC.
Un utilisateur du service TS peut devenir le propriétaire principal (TO), un propriétaire local (LO) ou une entité feuille
(LE), selon le rôle qu'il assume.
Propriétaire principal (TO, top owner)
Une connexion multidiffusée duplex a un seul propriétaire principal, qui correspond au propriétaire de la
connexion TC. Le propriétaire principal est responsable des opérations globales requises pour la gestion de la
connexion, y compris la création et la fin de la connexion, la création de l'arborescence de gestion, les
participations tardives et la mise à jour de la connexion. C'est aussi le seul expéditeur sur la voie de
Rec. UIT-T X.607 (02/2007) 5
ISO/CEI 14476-3:2008 (F)
transmission de données multidiffusées vers l'avant. Lui seul est autorisé à envoyer les données multidiffusées
initiales aux autres participants.
Propriétaire local (LO, local owner)
Dans la connexion multidiffusée duplex, un propriétaire local est un utilisateur du service TS qui est
responsable de la reprise après erreur à l'égard du groupe local au moyen de la retransmission de données.
Selon la hiérarchie de l'arborescence de gestion ECTP-3, un propriétaire local est un nœud parent, qui a des
nœuds enfants. Il est à noter qu'un propriétaire local est aussi un utilisateur du service TS. Autrement dit, il
reçoit aussi des données multidiffusées du propriétaire principal. Dans le protocole ECTP-3, un utilisateur du
service TS peut agir en tant que propriétaire local dans la connexion, ou certains propriétaires locaux désignés
peuvent être utilisés pour la reprise après erreur dans la connexion. Cela dépend de la mise en œuvre du
protocole ECTP-3.
Entité feuille (LE, leaf entity)
Dans la connexion multidiffusée duplex, une entité feuille représente un nœud feuille sur l'arborescence de
gestion. Chaque entité feuille est un utilisateur du service TS qui reçoit les données multidiffusées en
provenance du propriétaire principal.
Un utilisateur du service TS peut devenir un utilisateur expéditeur SU lorsqu'il obtient un jeton du propriétaire de la
connexion TC.
Utilisateur du service TS expéditeur (SU, sending TS-user)
Un utilisateur expéditeur SU est un utilisateur du service TS qui peut envoyer des données unidiffusées au
propriétaire principal. Dans la connexion multidiffusée duplex, un utilisateur du service TS devient un
utilisateur expéditeur SU lorsqu'il a un jeton et il peut alors transmettre des données unidiffusées au
propriétaire principal.
7.2 Arborescence de gestion
Une connexion multidiffusée duplex peut configurer une arborescence de gestion en vue d'une gestion échelonnable de
la fiabilité de la manière suivante.

Figure 3 – Arborescence de gestion du protocole ECTP-3
Dans l'arborescence de gestion ECTP-3, le propriétaire principal représente le sommet de l'arborescence, qui est au
niveau d'arborescence 0. Un propriétaire local est un nœud parent de l'arborescence et a un ou plusieurs enfants. Un
utilisateur du service TS qui n'est pas choisi comme propriétaire local est une entité feuille (LE) et ne peut pas avoir
d'enfants. Une telle arborescence de gestion sera configurée pendant la phase de création de connexion.
Dans le protocole ECTP-3, la reprise après erreur s'effectuera au sein de chaque groupe local défini par l'arborescence
de gestion. Un enfant peut demander une retransmission au propriétaire local (LO) qui est son parent. En réponse à la
demande, le propriétaire local parent retransmettra les paquets de données aux enfants, s'il les a dans la mémoire
tampon. Un propriétaire local est aussi un utilisateur du service TS et reçoit donc les données multidiffusées provenant
du propriétaire principal. L'arborescence de gestion est utilisée uniquement pour la voie de transmission de données
multidiffusées vers l'avant et non pour la voie de transmission des données unidiffusées vers l'arrière.
6 Rec. UIT-T X.607 (02/2007)
ISO/CEI 14476-3:2008 (F)
7.3 Voies de transmission de données
Dans le protocole ECTP-3, les deux types de voies de transmission de données sont utilisés, à savoir la voie de
transmission de données vers l'avant et la voie de transmission de données vers l'arrière.
7.3.1 Voie de transmission de données vers l'avant
La voie de transmission de données vers l'avant est utilisée pour permettre au propriétaire principal (TO) d'envoyer des
données multidiffusées aux autres membres. La voie de transmission de données multidiffusées vers l'avant peut aussi
être utilisée par un propriétaire local (LO) pour envoyer des données de retransmission aux utilisateurs qui sont ses
enfants.
L'adresse de la voie de transmission de données vers l'avant comprend l'adresse IP (multidiffusion) de groupe et le port
de groupe. Le propriétaire principal envoie des données multidiffusées au moyen de paquets DT à l'adresse de la voie de
transmission de données vers l'avant. Le propriétaire principal et les propriétaires locaux peuvent aussi retransmettre des
données multidiffusées au moyen de paquets RD à l'adresse de la voie de transmission de données vers l'avant.
La Figure 4 représente l'utilisation des voies de transmission de données multidiffusées vers l'avant dans le protocole
ECTP-3.
Figure 4 – Voies de transmission de données vers l'avant et arborescence
de gestion dans le protocole ECTP-3
7.3.2 Voie de transmission de données vers l'arrière
La voie de transmission de données vers l'arrière est utilisée par un utilisateur du service TS expéditeur (SU) pour
envoyer des données unidiffusées au propriétaire principal. L'adresse de la voie vers l'arrière comprend l'adresse IP du
propriétaire principal (TO) et le port de "groupe".
La Figure 5 représente l'utilisation des voies de transmission de données unidiffusées vers l'arrière dans le protocole
ECTP-3.
Figure 5 – Voies de transmission de données vers l'arrière
dans le protocole ECTP-3
Rec. UIT-T X.607 (02/2007) 7
ISO/CEI 14476-3:2008 (F)
Chaque utilisateur expéditeur SU peut envoyer au propriétaire principal des données unidiffusées au moyen de paquets
DT et RD en utilisant l'adresse de cette voie de transmission de données vers l'arrière comme adresse de destination. Par
contre, le propriétaire principal doit associer l'adresse de sa voie de transmission de données vers l'arrière pour recevoir
les données unidiffusées de tout utilisateur expéditeur SU dans la connexion.
7.4 Adressage
Dans le protocole ECTP-3, chaque paquet utilise les types suivants d'adresse IP et de numéro de port pour ses adresses
source et de destination:
a) Adresse IP de groupe et adresse IP locale.
b) Port de groupe et port local.
7.4.1 Adresse IP de groupe et adresse IP locale
L'adresse IP de groupe est l'adresse IP multidiffusion (par exemple, l'adresse de classe D pour le système IPv4), alors
qu'une adresse IP locale représente l'adresse IP unidiffusion pour chacun des participants ECTP: le propriétaire
principal, les propriétaires locaux et les entités feuilles.
L'adresse IP de groupe est utilisée comme adresse de destination des paquets qui doivent être multidiffusés par le
propriétaire principal et les propriétaires locaux. Par exemple, les paquets CR et DT du propriétaire principal utiliseront
l'adresse IP de groupe comme adresse de destination des paquets IP associés. Chaque propriétaire local utilise aussi
l'adresse IP de groupe comme adresse de destination des paquets RD et HB.
L'adresse IP locale de chaque participant est utilisée comme adresses IP source et de destination pour les paquets
unidiffusés, ainsi que comme adresse source pour les paquets multidiffusés.
Notons que l'adresse IP de groupe et l'adresse IP locale du propriétaire principal doivent être annoncées à tous les
participants potentiels au moyen d'une signalisation hors bande telle qu'une annonce sur le web.
7.4.2 Port de groupe et port local
Le port de groupe représente le numéro de port qui a été annoncé à tous les participants ECTP-3 avant la connexion.
Dans le protocole ECTP-3, le port de groupe sera généralement utilisé comme "port de destination" des paquets
multidiffusés ECTP-3 transmis par le propriétaire principal ou les propriétaires locaux, par exemple les paquets CR et
DT. Autrement dit, chaque utilisateur du service TS devrait associer au groupe l'adresse et le port IP pour recevoir les
paquets multidiffusés ECTP-3 appropriés.
Le numéro de port de groupe est aussi utilisé par l'utilisateur expéditeur SU pour envoyer des données unidiffusées au
propriétaire principal. Autrement dit, le propriétaire principal associera le port local à son adresse IP locale pour
recevoir les données unidiffusées de tout utilisateur expéditeur SU. En particulier, le port de groupe est aussi utilisé
comme port de destination du paquet qui demande une certaine action, par exemple une participation tardive.
Par contre, dans les autres cas non décrits ci-dessus, le paquet ECTP-3 utilisera le numéro de port local comme ports
source et/ou de destination. Par exemple, en réponse à une demande de participation tardive (JR, late join request) d'un
utilisateur du service TS, le propriétaire principal répondra par un message de confirmation de participation tardive (JC,
late join confirm) qui utilise le port local de l'utilisateur du service TS comme port de destination.
L'utilisation détaillée de l'adresse et du port IP locaux est spécifiée pour chacun des paquets ECTP-3 dans les
paragraphes suivants.
7.4.3 Adresses des voies de transmission de données
Dans le protocole ECTP-3, tous les paquets de données utilisent le numéro de port de groupe comme port de
destination. En conséquence, avant la création de la connexion, les informations suivantes doivent être annoncées à tous
les participants ECTP-3 au moyen d'une signalisation hors bande telle qu'une annonce sur le web.
a) Adresse IP de groupe et port de groupe.
b) Adresse IP locale du propriétaire principal.
La Figure 6 décrit l'utilisation de l'adresse IP et du port pour les voies de transmission de données vers l'avant et
l'arrière. Les paquets de données multidiffusées vers l'avant utilisent l'adresse IP et le numéro de port de groupe comme
adresse de destination des paquets de données, tandis que les paquets de données vers l'arrière utilisent l'adresse IP
locale du propriétaire principal et le numéro de port de groupe comme adresse de destination.
8 Rec. UIT-T X.607 (02/2007)
ISO/CEI 14476-3:2008 (F)
L'utilisation détaillée des adresses de groupe et locales pour les autres paquets sera spécifiée ultérieurement.
TO
Paquets de données vers l'arrière
Source Destination
Paquets de données vers l'avant
Adresse IP locale Adresse IP du TO
Source Port de groupe
Destination Port local
Adresse IP locale (TO) Adresse IP de groupe
Po
...