ISO/IEC 14476-1:2002
(Main)Information technology — Enhanced communications transport protocol: Specification of simplex multicast transport — Part 1:
Information technology — Enhanced communications transport protocol: Specification of simplex multicast transport — Part 1:
This Recommendation | International Standard specifies the Enhanced Communications Transport Protocol (ECTP), which is a transport protocol designed to support Internet multicast applications over multicast-capable IP networks. This Recommendation | International Standard specifies the ECTP for the simplex multicast transport connection that consists of one sender and many receivers. This Recommendation | International Standard specifies the protocol procedures for the following protocol operations: a) connection creation with tree creation; b) multicast data transmission; c) tree-based reliability control with error detection, retransmission request and retransmission; d) late join and leave; e) tree membership maintenance; and f) connection termination.
Technologies de l'information — Protocole de transport de communications amélioré: Spécification pour le transport simplex en multidiffusion — Partie 1:
Technologies de l'information ? Protocole de transport de communications amélioré: spécification du transport simplex en multidiffusion La présente Recommandation | Norme internationale définit le protocole de transport de communications amélioré (ECTP), qui est un protocole de transport visant à prendre en charge les applications multidiffusion Internet fonctionnant sur les réseaux IP pouvant assurer la multidiffusion. Elle définit le protocole ECTP destiné à la connexion de transport multidiffusion simplex, qui comprend un expéditeur et de nombreux destinataires. Elle spécifie les procédures du protocole pour les opérations suivantes: a) création d'une connexion avec création d'une arborescence; b) transmission de données en multidiffusion; c) gestion de la fiabilité de type arborescent avec détection d'erreur, demande de retransmission et retransmission; d) participation tardive et sortie; e) mise à jour de la composition de l'arborescence; f) fin de la connexion.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 14476-1
First edition
2002-06-15
Information technology — Enhanced
communications transport protocol:
Specification of simplex multicast
transport
Technologies de l'information — Protocole de transport de
communication amélioré: Spécifications pour le transport «simplex
multicast»
Reference number
©
ISO/IEC 2002
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 2002
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 copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 2002 – All rights reserved
CONTENTS
Page
1 Scope . 1
2 Normative references. 1
3 Definitions . 1
3.1 Terms defined in ITU-T Rec. X.601 . 1
3.2 Terms defined in ITU-T Rec. X.605 | ISO/IEC 13252. 1
3.3 Terms defined in this Recommendation | International Standard. 2
4 Abbreviations. 2
4.1 Packet types. 2
4.2 Miscellaneous. 3
5 Conventions. 3
6 Overview . 3
7 Protocol components . 5
7.1 Nodes. 5
7.2 Control tree. 6
7.3 Addressing. 7
7.4 Packets. 7
8 Protocol procedures . 8
8.1 Operations before the connection creation . 8
8.2 Connection creation. 9
8.3 Data transmission . 12
8.4 Error recovery. 13
8.5 Connection pause and resume . 14
8.6 Late join. 14
8.7 Leave . 15
8.8 Tree membership maintenance. 15
8.9 Connection termination . 16
9 Packet formats . 16
9.1 Fixed header . 17
9.2 Extension elements. 18
9.3 Packet structure . 21
10 Timers and variables. 24
10.1 Timers . 24
10.2 Operation variables. 24
Annex A – Network considerations . 25
Annex B – Tree configuration mechanisms considered in IETF RMT WG . 26
Bibliography . 27
© ISO/IEC 2002 – 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 3.
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 part of ISO/IEC 14476 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-1 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.606.
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 4: Specification of QoS management for duplex multicast transport
— Part 5: Specification of n-plex multicast transport
— Part 6: Specification of QoS management for n-plex multicast transport
Annexes A and B of this part of ISO/IEC 14476 are for information only.
iv © ISO/IEC 2002 – 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, as shown in Figure 1. ECTP could possibly be provisioned over UDP.
Internet Multicast Applications
Enhanced Communications Transport Protocol
UDP
IP Multicast
Figure 1 – ECTP Model
ECTP is designed to support tightly controlled multicast connections in simplex, duplex and N-plex applications. This
Part of ECTP specifies the protocol mechanisms for reliability control in the simplex case. ECTP also provides QoS
management functions for stable management of the QoS of the connection users. Such QoS management functionality
can be achieved with QoS negotiation, monitoring and maintenance operations. The protocol procedures for QoS
management of the simplex case will be defined in the simplex QoS management specification (ITU-T Rec. X.606.1 |
ISO/IEC 14476-2), which forms an integral part of this Recommendation | International Standard. Further specifications
will define control procedures and associated QoS management functions for the duplex case (ITU-T Rec. X.607 |
ISO/IEC 14476-3 and ITU-T Rec. X.607.1 | ISO/IEC 14476-4) and for the N-plex case (ITU-T Rec. X.608 |
ISO/IEC 14476-5 and ITU-T Rec. X.608.1 | ISO/IEC 14476-6).
In ECTP, all prospective members are enrolled into a multicast group, before a connection or session is created. Those
members define an enrolled group. Each receiver in the enrolled group is referred to as an enrolled receiver. In the
enrolment process, each member will be authenticated. The group information, including group key and IP multicast
addresses and port numbers, will be distributed to the enrolled members during the enrolment process. An ECTP
connection is created for these enrolled group members.
ECTP is targeted for tightly controlled multicast services. The sender is at the heart of multicast group communications.
A single sender in the simplex multicast connection is assigned the role of the connection owner, designated as top
owner (TO) in this Specification. The connection owner is responsible for overall connection management by governing
connection creation and termination, connection pause and resumption, and join and leave operations.
The sender triggers the connection creation process. Some or all of the enrolled receivers will participate in the
connection, becoming designated "active receivers". Any enrolled receiver that is not active may participate in the
connection as a late-joiner. An active receiver can leave the connection. After the connection is created, the sender
begins to transmit multicast data. If network problems (such as severe congestion) are indicated by the ECTP QoS
management functions (defined in ECTP part 2), the sender suspends multicast data transmission temporarily, invoking
the connection pause operation. After a pre-specified time, the sender resumes data transmission. If all of the multicast
data have been transmitted, the sender terminates the connection.
ECTP provides the reliability control mechanisms for multicast data transport. ECTP mechanisms are designed to keep
congruency with those being proposed in the IETF. To address reliability control with scalability, the IETF has proposed
three approaches: Tree based ACK (TRACK), Forward Error Correction (FEC), and Negative ACK Oriented Reliable
Multicast (NORM). Each approach has its own pros and cons, and each service provider may take a different approach
toward implementing reliability control. ECTP adopts the TRACK approach, because it is more similar to the existing
TCP mechanisms and more adaptive to the ECTP framework.
For tree-based reliability control, a hierarchical tree is configured during connection creation. The sender is the root of
the control tree. The control tree can define a parent-child relationship between any pair of tree nodes. This tree-based
structure can result in local owners (parents) occurring at lower levels in the tree hierarchy as the control structure
extends. Each local owner created becomes the root of its own local control tree. The connection owner will then be the
root of the overall control tree. Error control is performed for each local group defined by a control tree. Each parent
retransmits lost data, in response to retransmission requests from its children.
© ISO/IEC 2002 – All rights reserved v
INTERNATIONAL STANDARD ISO/IEC 14476-1
ITU-T RECOMMENDATION X.606
Information technology – Enhanced communications transport protocol:
Specification of simplex multicast transport
1 Scope
This Recommendation | International Standard specifies the Enhanced Communications Transport Protocol (ECTP),
which is a transport protocol designed to support Internet multicast applications over multicast-capable IP networks.
This Recommendation | International Standard specifies the ECTP for the simplex multicast transport connection that
consists of one sender and many receivers. This Recommendation | International Standard specifies the protocol
procedures for the following protocol operations:
a) connection creation with tree creation;
b) multicast data transmission;
c) tree-based reliability control with error detection, retransmission request and retransmission;
d) late join and leave;
e) tree membership maintenance; and
f) connection termination.
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 the
currently valid ITU-T Recommendations.
– ITU-T Recommendation X.601 (2000), Multi-peer communications framework.
– ITU-T Recommendation X.605 (1998) | ISO/IEC 13252:1999, Information technology –
Enhanced Communications Transport Service Definition.
3 Definitions
3.1 Terms defined in ITU-T Rec. X.601
This Recommendation | International Standard is based on the definitions of the multicast groups developed in Multi-
Peer Communications Framework (ITU-T Rec. X.601).
a) Enrolled group; and
b) Active group.
3.2 Terms defined in ITU-T Rec. X.605 | ISO/IEC 13252
This Recommendation | International Standard is based on the concepts developed in Enhanced Communications
Transport Service (ITU-T Rec. X.605 | ISO/IEC 13252).
a) Transport connection; and
b) Simplex.
ITU-T Rec. X.606 (10/2001) 1
3.3 Terms defined in this Recommendation | International Standard
For the purposes of this Recommendation | International Standard, the following definitions apply:
3.3.1 application: Represents an Internet multicast application in this Specification. It corresponds to a transport
service user in the OSI mode. It exchanges transport service primitives with the corresponding transport protocol entity.
In the Internet, it communicates with the transport protocol entity via a socket interface.
3.3.2 packet: Represents a unit of transport data, which is equivalent to a segment in TCP/IP and a transport
protocol data unit (TPDU) in OSI model. A transport entity communicates with another transport entity by transmitting
packets. A transport protocol entity creates a packet, which is encapsulated into an IP datagram and then delivered to the
destination entity over networks.
3.3.3 sender: Represents a transport protocol entity that sends the multicast data to the receivers.
3.3.4 receiver: Represents a transport protocol entity that receives the multicast data.
3.3.5 tree: Is a hierarchical logical tree employed for providing scalable reliability control. A tree defines a parent-
child relationship between a pair of tree nodes. Sender and receivers are organized into a tree. In the tree hierarchy, a tree
node is designated as TO (Top Owner), LO (Local Owner) or LE (Leaf Entity). TO is a single ECTP sender. All the
receivers are designated as LOs or LEs.
3.3.6 TO (top owner): Is a single sender in the ECTP simplex multicast connection. TO is the root of the tree and
manages the overall protocol operations for the connection.
3.3.7 LO (local owner): Is a receiver that manages a local group. An LO is responsible for the overall protocol
operations for its local group defined by the control tree. For error recovery, it retransmits the multicast data that have
been lost by its children. For flow and congestion control, it aggregates the control information for all of its children and
then delivers the aggregated information toward TO. In terms of the reliability control operations, TO is also an LO.
3.3.8 LE (leaf entity): Is a receiver that has not been designated as an LO. An LE cannot have any children. It is
located as a leaf node on the tree.
3.3.9 local group: Consists of a parent and its children in the tree hierarchy.
3.3.10 parent: Is a parent node for a local group. TO or an LO can be a parent.
3.3.11 child: Is a child node for a local group. An LO or LE can be a child.
4 Abbreviations
For the purposes of this Recommendation | International Standard, the following abbreviations apply:
4.1 Packet types
ACK Acknowledgment
CC Connection Creation Confirm
CR Connection Creation Request
CT Connection Termination
DT Data
HB Heartbeat
JC Late Join Confirm
JR Late Join Request
LR Leave Request
ND Null Data
RD Retransmission Data
TC Tree Join Confirm
TJ Tree Join Request
2 ITU-T Rec. X.606 (10/2001)
4.2 Miscellaneous
ECTP Enhanced Communications Transport Protocol
ECTS Enhanced Communications Transport Service
IETF Internet Engineering Task Force
IGMP Internet Group Management Protocol
IP Internet protocol
QoS Quality of Service
RFC Request for Comments
RMT Reliable Multicast Transport
SAP Session Announcement Protocol
SDP Session Description Protocol
TCP Transmission Control Protocol
UDP User Datagram Protocol
5 Conventions
In this Recommendation | International Standard, the key words "MUST", "REQUIRED", "SHALL", "MUST NOT",
"SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" are to be interpreted as described in IETF
RFC 2119, and indicate requirement levels for compliant ECTP implementations. Those key words are case-sensitive.
6 Overview
The ECTP is a transport protocol designed to support Internet multicast applications. ECTP operates over IPv4/IPv6
networks that have IP multicast forwarding capability.
This Specification describes the ECTP protocol for the simplex multicast transport connection that consists of one sender
and many receivers. ECTP supports the connection management functions, which are based on ITU-T Rec. X.605 |
ISO/IEC 13252. The connection management functions include connection creation and termination, connection pause
and resumption, and late join and leave. For reliable delivery of multicast data, ECTP also provides the protocol
mechanisms for error, flow and congestion controls. To allow scalability to large-scale multicast groups, tree-based
reliability control mechanisms are employed which are congruent with those being proposed in the IETF RMT WG.
Figure 2 shows an overview of the ECTP operations.
As shown in the figure, the QoS management operations such as QoS negotiation, monitoring and maintenance will be
specified in ITU-T Rec. X.606.1 | ISO/IEC 14476-2. In particular, QoS maintenance includes the operations for
connection pause and resume, and the flow and congestion controls.
Before an ECTP transport connection is created, the prospective receivers are enrolled into the multicast group. Such a
group is called an enrolled group (see 8.1). During enrolment, authentication processes may be performed together with
group key distribution. The IP multicast addresses and port numbers must be announced to the receivers. These
enrolment operations may rely on the well-known SAP/SDP, HTTP (Web Page announcement) and SMTP (E-mail)
protocols. The specific enrolment mechanisms are outside the scope of this Specification.
An enrolled receiver will be connected to the multicast-capable network with the help of the IGMP and IP multicast
routing protocols. Those IGMP and multicast routing protocols will refer to the announced multicast addresses. An
ECTP transport connection is created for the enrolled receivers.
ECTP is targeted to support tightly controlled multicast connections. The ECTP sender is at the heart of the multicast
group communication. The sender, designated as connection owner (TO), is responsible for the overall management of
the connection by governing connection creation and termination, connection pause and resumption, and the late join and
leave operations.
The ECTP sender triggers the connection creation process by sending a connection creation message. Some or all of the
enrolled receivers may respond with confirmation messages to the sender. The connection creation is completed when
the sender receives the confirmation messages from all of the active receivers, or when a pre-specified timer expires
(see 8.2).
ITU-T Rec. X.606 (10/2001) 3
Connection Creation
Control Tree Creation
QoS Negotiation
Multicast Data Transfer
Tree-based Reliability Control
ECTP
Connection
Lifetime
Tree Membership Maintenance
Late Join and Leave
QoS Monitoring
QoS Maintenance
Connection Termination
T0733820-01
Figure 2 – ECTP Protocol Operations
Throughout the connection creation, some or all of the enrolled group receivers will join the connection. The receivers
that have joined the connection are called active receivers. An enrolled receiver that is not active can participate in the
connection as a late-joiner (see 8.6). The late-joiner sends a join request to the sender. In response to the join request, the
sender transmits a join confirm message, which indicates whether the join request is accepted or not. An active receiver
can leave the connection by sending a leaving request to the sender. A trouble-making receiver, who cannot keep pace
with the current data transmission rate, may be ejected (see 8.7).
After a connection is created, the sender begins to transmit multicast data (see 8.3). For data transmission, an application
data stream is sequentially segmented and transmitted by means of data packets to the receivers. The receivers will
deliver the received data packets to the applications in the order they were transmitted by the sender.
To make the protocol scalable to large multicast groups, ECTP employs the tree-based reliability control mechanisms. A
hierarchical tree is configured during connection creation. A control tree defines a parent-child relationship between any
pair of tree nodes. The sender is the root of the control tree. In the tree hierarchy, a set of local groups are defined. A
local group consists of a parent and zero or more children. The error, flow and congestion controls are performed for
each local group defined by the control tree.
Figure 3 illustrates a control tree hierarchy for reliability control, in which a parent-child relationship is configured
between a sender (S) and a receiver (R), or between a parent receiver (R) and its child receiver (R).
ECTP specifies the protocol procedures for tree creation. In the tree creation, a control tree is gradually expanded from
the sender to the receivers (see 8.2.2). This is called a top-down configuration. On the other hand, the IETF RMT WG
has proposed a bottom-up approach, where the receivers initiate a tree configuration (see Annex B). Those schemes may
be incorporated into the ECTP as candidate tree creation options in the future.
Tree-membership is maintained during the connection. A late-joiner is allowed to join the control tree. The late-joiner
listens to the heartbeat messages from one or more on-tree parents, and then joins the best parent. When a child leaves
the connection, the parent removes the departing child from the children-list. Node failures are detected by using periodic
control messages such as null data, heartbeat and acknowledgement. The sender transmits periodic null data messages to
indicate that it is alive, even if it has no data to transmit. Each parent periodically sends heartbeat messages to its
children. On the other hand, each child transmits periodic acknowledgement messages to its parent (see 8.8).
4 ITU-T Rec. X.606 (10/2001)
S
RR R
RRRRRRR RR
T0733830-01
Figure 3 – Control Tree Hierarchy for Reliability Control
In ECTP, error control is performed for each local group defined by a control tree (see 8.4). If a child detects a data loss,
it sends a retransmission request to its parent via ACK packets.
An ACK message contains the information that identifies the data packets which have been successfully received. Each
child can send an ACK message to its parent using one of two ACK generation rules: ACK number and ACK timer. If
data traffic is high, an ACK is generated for the ACK number of data packets. If the traffic is low, an ACK message will
be transmitted after the ACK timer expires.
After retransmission of data, the parent activates a retransmission back-off timer. During the time interval,
retransmission request(s) for the same data will be ignored. Each parent can remove the data out of its buffer memory, if
those have been acknowledged by all of its children.
The flow and congestion control information is delivered from the receivers to the sender, along the control tree. The
detailed description of flow and congestion control will be given in ITU-T Rec. X.606.1 | ISO/IEC 14476-2, the QoS
management specification for the simplex multicast transport. Based on the monitored flow and congestion control
information, the sender will adjust the transmission rate.
During the data transmission, if network problems (for example, severe congestion) are indicated by the QoS
management functions specified in ITU-T Rec. X.606.1 | ISO/IEC 14476-2, the sender suspends the multicast data
transmission temporarily. In this period, no new data is delivered, while the sender transmits periodic null data messages
to indicate that the sender is alive. After a pre-specified time has elapsed, the sender resumes the multicast data
transmission (see 8.5).
The sender terminates the connection by sending a termination message to all the receivers, after all the multicast data
are transmitted. The connection may also terminate due to a fatal protocol error such as a connection failure (see 8.9)
7 Protocol components
7.1 Nodes
ECTP protocol mechanisms are based on a logical control tree, which defines a parent-child relationship between any
pair of tree nodes. Each node on the tree is classified into one of three node types: TO (top owner), LO (local owner) and
LE (leaf entity).
a) Top Owner (TO)
TO is the root of the control tree and also a single sender in the simplex multicast connection. TO
manages the overall connection management functions including the connection creation and termination.
In the connection creation phase, a control tree is configured by interactions between the sender and
receivers. After the connection is created, TO sends multicast data to the receivers. TO can temporarily
suspend and resume the connection. TO can admit or reject the group members who want to join the
existing connection. After all the data is transmitted, TO terminates the multicast transport connection.
ITU-T Rec. X.606 (10/2001) 5
b) Local Owner (LO)
In the ECTP connection, some of the receivers may be designated as LOs. Each LO has its children that
consist of other LOs and/or LEs. LOs are thus located as interior nodes on the tree. Each LO retransmits
the multicast data that have been lost by its children. It also aggregates the information on the flow and
congestion control from its children, and forwards the aggregated information toward TO. TO is also an
LO in terms of the reliability control operations.
c) Leaf Entity (LE)
A receiver, which has not been designated as LO, is referred to as an LE. An LE cannot have any children.
It is thus located as a leaf node on the control tree.
TO is a single sender. LOs and LEs are receivers. In the tree hierarchy, a local group consists of a parent and its children.
TO or an LO can be a parent, and an LO or LE can be a child.
In the tree hierarchy, an LO retransmits lost multicast data to its children (error recovery) and forwards the flow and
congestion control information to TO. Moreover, each LO has authority to eject a trouble-making child to maintain the
stability of the connection. It is thus expected that LOs are given more processing power and responsibility than LEs.
In ECTP, it is presumed that some of receivers have been designated as LOs before the connection is created. This
Specification does not consider the selection of LOs among flat receivers during the connection. That is, before the
connection creation (or in the enrolment phase), each receiver MUST know whether it is an LO or LE. In a very small-
sized group or asynchronous networks such as satellite or mobile networks, no LO may be designated. In those
environments, all the receivers will be LEs.
An LO may be an end host or a dedicated server. In privately controlled networks, it is probable that dedicated servers
function as LOs. In public networks, end hosts may be employed as LOs. In either case, an LO is a receiver and performs
the reliability control operations for its local group as a parent.
7.2 Control tree
After a connection is created, TO transmits data to all the receivers by multicast. Each child sends status information on
data reception to its parent. The information will thus be delivered to TO along the control tree. The multicast data
streams flow from TO to LOs and LEs in the downward direction, while the control information is transferred from LEs
to TO via LOs in the upward direction along the control tree.
Figure 4 shows a general structure of an ECTP control tree.
TO Level 0
Level 1
LO LO LO
Level 2
LE LO LE LE LE LO LE LE LO
Level 3
LE LE LE LE LE LE LE
T0733840-01
Figure 4 – An ECTP Control Tree
6 ITU-T Rec. X.606 (10/2001)
A control tree defines the parent-child relationship between any pair of nodes. The control tree provides each tree node
with the following information:
– Who is my parent node ? (at LOs and LEs);
– Who are my children nodes ? (at TO and LOs).
Based on the information described above, a tree node may keep its parent and/or children list. In the list, each element is
identified by its transport address, and all the elements are arranged in the order of a pre-specified rule such as IP address
or hop distance, etc. The parent list may have one or more elements, some of which will be used as backup parent nodes
against a failure of the current parent node.
ECTP provides three options for tree configuration (see 8.2.2). The other options may additionally be defined in the
future according to the requirements of multicast applications (see Annex B).
7.3 Addressing
7.3.1 Port
ECTP uses a set of ports to identify different applications in an IP end host. The port number is inserted in each packet
header. In general, an IP host can support a number of ports, and each port number is unique within the host. The binding
of ports to processes is handled independently by each host.
For a multicast transport connection, at least two ports are used. If implementations use the socket interface, it will be
bound to at least two ports. One of them is a port used for multicast data transmission and reception, which MUST be
announced to the group members before the connection is created. Another is a port assigned locally within a system,
which will be referred to as a destination port number for transmission of unicast control messages.
When a transport connection is released, it is necessary to prevent the current port from being reused by another new
connection, because the packets associated with the current port may still exist in the network and flow into the port even
after the connection is terminated. It is thus recommended that the relevant port be set to be in a frozen state, if the
connection is released. The port being in the frozen state MUST NOT be reused by any other connection for a specific
time.
7.3.2 Transport addresses
A transport address is defined as a pair of an IP address and a port number. The multicast transport address consists of an
IP multicast address and a port number. TO sends multicast data by setting the multicast transport address as the
destination transport address. Each receiver receives the multicast data from TO over the multicast transport address.
Such a multicast transport address for data transmission MUST be announced to all the group members in the enrolment
phase.
A unicast transport address is identified with a pair of an IP unicast address and a local port number. When TO sends
multicast data, it sets the corresponding source transport address to its unicast transport address. The unicast transport
address is also used when a node transmits a unicast control message to another node.
7.3.3 Multicast data and control addresses
In ECTP, TO sends data to all receivers by multicast, while LOs send retransmission data and control messages to its
local group by multicast.
Depending on the multicast deployment in the network, TO and LOs may share a single IP multicast address or use
different IP multicast addresses. For example, the source specific multicast (SSM) routing protocol defines a multicast
channel by a pair of an IP multicast address and a unicast address of the source. In SSM, a multicast channel is unique to
the sender (see Annex A for more in detail).
In the networks where TO and LOs use different multicast addresses or channels, all of the multicast addresses employed
MUST be announced to the group members, before the connection is created. In this case, one of them is used for the
multicast data transmission by TO, and the others are for the multicast control by LOs such as the multicast data
retransmission and the multicast transmission of control messages.
7.4 Packets
ECTP packets are classified into data and control packets. Data (DT) and Retransmission Data (RD) are the data packets.
All the other packets are used for control purposes. Table 1 summarizes the packets used in ECTP. In the table, the
transport type 'multicast' represents global multicast using a multicast data address, while the 'local multicast' does local
multicast using a multicast control address. The RD and HB control packets are delivered from an LO to its local group
(i.e. its children) by local multicast.
ITU-T Rec. X.606 (10/2001) 7
Table 1 – ECTP Packets
Packet Acronym Transport Type From To
Creation Request CR Multicast Sender Receivers
Creation Confirm CC Unicast Child Parent
Tree Join Request TJ Unicast Child Parent
Tree Join Confirm TC Unicast Parent Child
Data DT Multicast Sender Receivers
Null Data ND Multicast Sender Receivers
Retransmission Data RD (Local) Multicast Parent Children
Acknowledgement ACK Unicast Child Parent
Heartbeat HB (Local) Multicast Parent Children
Late Join Request JR Unicast Receiver Sender
Late Join Confirm JC Unicast Sender Receiver
Leave Request LR Unicast Parent/Child Child/Parent
Connection Termination CT Multicast Sender Receivers
NOTE 1 – Sender is TO, and Receivers are LOs and LEs.
NOTE 2 – Parent is TO or an LO, and Child is an LO or LE.
NOTE 3 – See Table 3 in 9.3 for the detailed packet structure.
8 Protocol procedures
8.1 Operations before the connection creation
Before an ECTP connection is created, every prospective group member has been enrolled to the multicast group. Such a
member is called an enrolled group member (see ITU-T Rec. X.601). Some or all of the enrolled group users will
participate in the ECTP connection.
Before an enrolled group member joins the multicast connection, it MUST be attached to the network interface with the
help of the IGMP and IP multicast routing protocols. This ensures that the enrolled member listens to the multicast data
and control packets from TO and LOs.
An enrolled user gets information on the multicast session, including IP addresses and port numbers, via SDP/SAP,
HTTP (Web page) or E-mail. The detailed enrolment mechanisms are outside the scope of the ECTP specification.
To ensure that an enrolled user participates in the ECTP connection, the following transport addresses MUST be
announced to the enrolled group, together with the session-specific information:
1) Multicast group (data) transport address: an IP multicast address and a port number:
The IP multicast address and port number combination MUST be unique to an ECTP connection, and it
will be used by TO to transmit the multicast data to the receivers.
2) Unicast transport address of TO: an IP unicast address and a port number:
The IP address and the port number correspond to the source IP address and the port number for the
multicast data packets, respectively. They will also be referred to as the destination IP address and the port
number for the control packets flowing from receivers to TO.
3) Unicast transport address of LO: an IP unicast address and a port number:
This unicast transport address corresponds to the source IP address and port number for the multicast
control packets such as TJ and ACK packets. It is also referred to as the destination address and port
number for the control packets from the children to LO.
8 ITU-T Rec. X.606 (10/2001)
4) Multicast control transport address of an LO: an IP multicast address and a port number:
If TO and LOs use different multicast addresses, each LO also announces its multicast address and port
numbers. The IP address and the port number will be used by LO to transmit the multicast control packets
such as HB and RD packets to the children.
Using multicast addresses, each enrolled member MUST have been attached to the network, via the IGMP and IP
multicast routing protocols, before the connection is created. The member listens to the multicast control and data control
messages from TO and LOs.
8.2 Connection creation
8.2.1 Procedures for connection creation
TO triggers the connection creation by sending a CR packet to the enrolled receivers. Some or all of the enrolled
receivers will respond with their respective CC packets. TO completes the connection creation by aggregating those CC
packets. The receivers that have participated in the connection are called 'active receivers.'
If one or more LOs are employed for the tree creation, each LE sends its CC packet to its parent LO. The parent LO
aggregates the CC packets from its children, and then sends an aggregated CC packet to its parent.
The connection creation procedures are summarized as follows:
1) TO transmits a CR packet to all the receivers by multicast.
TO then activates the Connection Creation Time (CCT) timer.
2) When a receiver receives the CR packet, it begins to configure the control tree (see 8.2.2).
3) After each receiver joins the tree, it sends a CC packet to its parent by unicast, and then waits for multicast
data from TO. Each on-tree parent LO aggregates the CC packets from all of the children and then sends
an aggregated CC to its parent.
4) TO aggregates CC packets from its children while the CCT timer is valid. If the CCT timer expires, TO
completes the connection creation for the receivers that have sent CC packets until then.
Figure 5 depicts the generic procedures for connection creation.
CR
Control Tree Creation
CCT
CC
CC (aggregate)
T0733850-01
TO
LO LE
Figure 5 – Connection Creation Procedures
In the figure, the detailed tree creation procedures are described in 8.2.2.
After the connection creation is completed, TO transmits multicast data. The receivers that have not participated in the
connection may join the connection as late-joiners (see 8.6).
All the group members, a sender and receivers, activate Inactivity Time (IAT) timers, when connection creation is
indicated. The IAT timer is used to protect against abnormal protocol operations. The IAT timer is reset each time a new
packet arrives. If IAT timer expires without reception of any packet, the corresponding node determines that the
connection has failed.
ITU-T Rec. X.606 (10/2001) 9
8.2.2 Control tree creation
In the connection creation, ECTP configures a hierarchical control tree connecting TO and LEs via zero or more LOs.
ECTP provides three options for the tree creation:
a) Option 1: Level 1 Configuration, in which no LO is employed;
b) Option 2: Level 2 Configuration, in which all LOs are connected to TO;
c) Option 3: General Configuration, in which more than two tree levels may be configured.
One of these three options MUST be specified in the connection information element (see 9.2.1). Depending on the
network infrastructure, the other options may be defined for the tree creation in the future, which includes the schemes
proposed by the IETF RMT WG. The brief sketches for those options are given in Annex B.
The tree creation algorithm automatically constructs a control tree. To ensure the 'no loop configuration' in the tree, the
top-d
...
NORME ISO/CEI
INTERNATIONALE 14476-1
Première édition
2002-06-15
Technologies de l'information —
Protocole de transport de
communications amélioré: Spécification
pour le transport simplex en
multidiffusion
Information technology — Enhanced communications transport
protocol: Specification of simplex multicast transport
Numéro de référence
ISO/CEI 14476-1:2002(F)
©
ISO/CEI 2002
ISO/CEI 14476-1:2002(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.
© ISO/CEI 2002
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 copyright@iso.ch
Web www.iso.ch
Imprimé en Suisse
ii © ISO/CEI 2002 – Tous droits réservés
ISO/CEI 14476-1:2002(F)
TABLE DES MATIÈRES
Page
1 Domaine d'application . 1
2 Références normatives. 1
3 Définitions . 1
3.1 Termes définis dans la Rec. UIT-T X.601. 1
3.2 Termes définis dans la Rec. UIT-T X.605 | ISO/CEI 13252 . 1
3.3 Termes définis dans la présente Recommandation | Norme internationale . 2
4 Abréviations. 2
4.1 Types de paquet. 2
4.2 Divers . 3
5 Conventions . 3
6 Aperçu général. 3
7 Eléments du protocole . 6
7.1 Nœuds. 6
7.2 Arborescence de gestion. 7
7.3 Adressage . 8
7.4 Paquets . 9
8 Procédures du protocole . 9
8.1 Opérations antérieures à la création de la connexion. 9
8.2 Création de la connexion . 10
8.3 Transmission de données. 14
8.4 Reprise après incident. 15
8.5 Pause et reprise de connexion. 17
8.6 Participation tardive. 17
8.7 Sortie . 18
8.8 Mise à jour de la composition de l'arborescence . 19
8.9 Fin de la connexion . 19
9 Format de paquet . 20
9.1 En-tête fixe . 20
9.2 Eléments d'extension . 21
9.3 Structure de paquet. 25
10 Temporisateurs et variables . 28
10.1 Temporisateurs . 28
10.2 Variables de fonctionnement. 28
Annexe A – Considérations relatives aux réseaux . 30
Annexe B – Mécanismes de configuration d'arborescence examinés au sein du Groupe
de travail RMT de l'IETF. 31
Bibliographie . 32
© ISO/CEI 2002 – Tous droits réservés iii
ISO/CEI 14476-1:2002(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 3.
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 de la présente partie de l'ISO/CEI 14476 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-1 a été élaborée 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.606.
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 gestion QoS pour le transport simplex en multidiffusion
— Partie 3: Spécification pour le transport duplex en multidiffusion
— Partie 4: Spécification de gestion QoS pour le transport duplex en multidiffusion
— Partie 5: Spécification pour le transport n-plex en multidiffusion
— Partie 6: Spécification de gestion QoS pour le transport n-plex en multidiffusion
Les annexes A et B de la présente partie de l'ISO/CEI 14476 sont données uniquement à titre d'information.
iv © ISO/CEI 2002 – Tous droits réservés
ISO/CEI 14476-1:2002(F)
Introduction
La présente Recommandation | Norme internationale définit le protocole de transport de communications amélioré
(ECTP), qui est un protocole de transport visant à prendre en charge les applications 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, comme indiqué
à la Figure 1. Le protocole ECTP peut être configuré en mode UDP.
Applications multidiffusion Internet
Protocole de transport de communications amélioré
Protocole UDP
Multidiffusion IP
Figure 1 – Modèle ECTP
Le protocole ECTP est destiné à prendre en charge des connexions multidiffusion étroitement contrôlées dans des
applications simplex, duplex et N-plex. Cette partie du protocole définit les mécanismes du protocole qui assure la
gestion de la fiabilité en mode simplex. Le protocole ECTP offre aussi des fonctions de gestion de la qualité de service
(QS) en vue d'une gestion stable de la qualité de service pour les utilisateurs de la connexion. Cette fonction de gestion
QS peut être assurée avec les opérations de négociation, de surveillance et de maintien de la qualité de service. Les
procédures de gestion QS en mode simplex seront définies dans la spécification relative à la gestion de la qualité de
service en mode simplex (Rec. UIT-T X.606.1 | ISO/CEI 14476-2), qui fait partie intégrante de la présente
Recommandation | Norme internationale. D'autres spécifications définiront les procédures de gestion et les fonctions de
gestion QS connexes en mode duplex (Rec. UIT-T X.607 | ISO/CEI 14476-3 et Rec. UIT-T X.607.1 | ISO/CEI 14476-4)
et en mode N-plex (Rec. UIT-T X.608 | ISO/CEI 14476-5 et Rec. UIT-T X.608.1 | ISO/CEI 14476-6).
En mode ECTP, tous les membres potentiels sont enrôlés dans un groupe multidiffusé avant la création d'une connexion
ou d'une session. Ces membres définissent un groupe enrôlé. Chaque destinataire du groupe enrôlé est dénommé
destinataire enrôlé. Pendant le processus d'enrôlement, chaque membre sera authentifié. Les informations de groupe, y
compris la clé de groupe, les adresses multidiffusion IP et les numéros de ports, seront distribuées aux membres enrôlés
pendant le processus d'enrôlement. Une connexion ECTP est créée pour ces membres du groupe enrôlé.
Le protocole ECTP vise les services multidiffusion étroitement contrôlés. L'expéditeur est au centre des communications
du groupe multidiffusé. Dans la connexion multidiffusion simplex, le rôle de propriétaire de la connexion est attribué à
un seul expéditeur, désigné comme propriétaire principal (TO, top owner) dans la présente Spécification. Le propriétaire
de la connexion est responsable de la gestion globale de la connexion en ce sens qu'il gère les opérations de création et de
fin de connexion, de pause et de reprise de connexion, de participation à une connexion et de sortie.
L'expéditeur déclenche le processus de création de connexion. Une partie ou la totalité des destinataires enrôlés
participeront à la connexion et seront désignés comme "destinataires actifs". Tout destinataire enrôlé qui n'est pas actif
peut participer à la connexion en tant que participant tardif. Un destinataire actif peut quitter la connexion. Une fois la
connexion créée, l'expéditeur commence à transmettre les données multidiffusées. Si des problèmes de réseau (par
exemple un important encombrement) sont signalés par les fonctions de gestion de la qualité de service du protocole
ECTP (définies dans la partie 2 du protocole ECTP), l'expéditeur suspend temporairement la transmission des données en
multidiffusion en demandant une pause de la connexion. Après un délai défini à l'avance, l'expéditeur reprend la
transmission des données. Si toutes les données multidiffusées ont été transmises, l'expéditeur met fin à la connexion.
Le protocole ECTP offre des mécanismes de gestion de la fiabilité pour le transport de données en multidiffusion. Ces
mécanismes sont conçus de manière à être compatibles avec ceux qui sont proposés dans le cadre de l'IETF. Pour assurer
la gestion de la fiabilité avec échelonnabilité, l'IETF a proposé trois méthodes: accusé de réception de type arborescent
(TRACK, tree based ACK), correction d'erreur directe (FEC, forward error correction) et multidiffusion fiable axé sur
un accusé de réception négatif (NORM, negative ACK oriented reliable multicast). Chaque méthode a ses avantages et
ses inconvénients et chaque prestataire de services peut adopter une méthode différente pour l'implémentation de la
gestion de la fiabilité. Le protocole ECTP adopte la méthode TRACK car elle est plus proche des mécanismes TCP
existants et plus adaptable au cadre du protocole ECTP.
© ISO/CEI 2002 – Tous droits réservés v
ISO/CEI 14476-1:2002(F)
Pour la gestion de la fiabilité de type arborescent, une arborescence hiérarchique est configurée pendant la création de la
connexion. L'expéditeur est la racine de l'arborescence de gestion, qui peut définir une relation parent-enfant entre toute
paire des nœuds de l'arborescence. Cette structure arborescente peut entraîner l'apparition de propriétaires locaux
(parents) aux niveaux inférieurs de l'arborescence à mesure que la structure de gestion s'étend. Chaque propriétaire local
créé devient la racine de sa propre arborescence de gestion locale. Le propriétaire de la connexion sera donc la racine de
l'arborescence de gestion globale. Une correction d'erreur est assurée pour chaque groupe local défini par une
arborescence de gestion. Chaque parent retransmet les données perdues en réponse aux demandes de retransmission de
ses enfants.
vi © ISO/CEI 2002 – Tous droits réservés
ISO/CEI 14476-1:2002 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
Technologies de l'information – Protocole de transport de communications amélioré:
spécification du transport simplex en multidiffusion
1 Domaine d'application
La présente Recommandation | Norme internationale définit le protocole de transport de communications amélioré
(ECTP), qui est un protocole de transport visant à prendre en charge les applications multidiffusion Internet fonctionnant
sur les réseaux IP pouvant assurer la multidiffusion.
Elle définit le protocole ECTP destiné à la connexion de transport multidiffusion simplex, qui comprend un expéditeur et
de nombreux destinataires. Elle spécifie les procédures du protocole pour les opérations suivantes:
a) création d'une connexion avec création d'une arborescence;
b) transmission de données en multidiffusion;
c) gestion de la fiabilité de type arborescent avec détection d'erreur, demande de retransmission et
retransmission;
d) participation tardive et sortie;
e) mise à jour de la composition de l'arborescence;
f) fin de la connexion.
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.605 (1998) | ISO/CEI 13252:1999, Technologies de l'information – Définition du
service de transport de communications amélioré.
3 Définitions
3.1 Termes définis dans la Rec. UIT-T X.601
La présente Recommandation | Norme internationale est fondée sur les définitions des groupes multidiffusées indiquées
dans la Rec. UIT-T X.601, Cadre général des communications entre homologues multiples.
a) Groupe enrôlé;
b) Groupe actif.
3.2 Termes définis dans la Rec. UIT-T X.605 | ISO/CEI 13252
La présente Recommandation | Norme internationale est fondée sur les concepts élaborés dans la Rec. UIT-T X.605 |
ISO/CEI 13252, Définition du service de transport de communications amélioré.
a) Connexion de transport;
b) Simplex.
Rec. UIT-T X.606 (10/2001) 1
ISO/CEI 14476-1:2002 (F)
3.3 Termes définis dans la présente Recommandation | Norme internationale
Aux fins de la présente Recommandation | Norme internationale, les définitions suivantes sont applicables :
3.3.1 application: représente une application multidiffusion Internet dans la présente spécification. Elle correspond à
un utilisateur du service de transport dans le mode OSI. Elle échange des primitives de service de transport avec l'entité
de protocole de transport correspondante. Sur Internet, elle communique avec l'entité de protocole de transport par le
biais d'une interface de connexion.
3.3.2 paquet: représente une unité de données de transport, équivalente à un segment dans le protocole TCP/IP et à
une unité de données protocolaire de transport (TPDU, transport protocol data unit) dans le modèle OSI. Une entité de
transport communique avec une autre entité de transport en transmettant des paquets. Une entité de protocole de
transport crée un paquet, qui est encapsulé dans un datagramme IP, puis remis à l'entité de destination sur le réseau.
3.3.3 expéditeur: représente une entité de protocole de transport qui envoie les données multidiffusées aux
destinataires.
3.3.4 destinataire: représente une entité de protocole de transport qui reçoit les données multidiffusées.
3.3.5 arborescence: arborescence logique hiérarchique utilisée pour offrir une gestion échelonnable de la fiabilité.
Une arborescence définit une relation parent-enfant entre une paire de nœuds de l'arborescence. L'expéditeur et les
destinataires sont organisés en arborescence. Dans la hiérarchie arborescente, un nœud d'arborescence est désigné
comme propriétaire principal (TO, top owner), propriétaire local (LO, local owner) ou entité feuille (LE, leaf entity). Le
propriétaire principal est l'unique expéditeur dans le protocole ECTP. Tous les destinataires sont désignés comme
propriétaires locaux ou entités feuilles.
3.3.6 propriétaire principal (TO, top owner): expéditeur unique dans la connexion multidiffusion simplex ECTP.
Le propriétaire principal est la racine de l'arborescence et gère les opérations globales du protocole relatives à la
connexion.
3.3.7 propriétaire local (LO, local owner): destinataire qui gère un groupe local. Un propriétaire local est
responsable des opérations globales du protocole relatives à son groupe local défini par l'arborescence de gestion. Pour la
reprise après incident, il retransmet les données multidiffusées qui ont été perdues par ses enfants. Pour le contrôle de
flux et la gestion des encombrements, il regroupe les informations de gestion concernant tous ses enfants, puis transmet
l'ensemble des informations au propriétaire principal (TO). Au niveau des opérations de gestion de la fiabilité, un
propriétaire principal est aussi un propriétaire local.
3.3.8 entité feuille (LE, leaf entity): destinataire qui n'a pas été désigné comme propriétaire local (LO). Une entité
feuille ne peut pas avoir d'enfants. Elle occupe une place de nœud feuille sur l'arborescence.
3.3.9 groupe local: comprend un parent et ses enfants dans la hiérarchie arborescente.
3.3.10 parent: nœud parent d'un groupe local. Un propriétaire principal (TO) ou un propriétaire local (LO) peut être
un parent.
3.3.11 enfant: nœud enfant d'un groupe local. Un propriétaire local (LO) ou une entité feuille (LE) peut être un
enfant.
4 Abréviations
Pour les besoins de la présente Recommandation Norme Internationales les abréviations suivantes sont utilisées:
4.1 Types de paquet
ACK Accusé de réception (acknowledgment)
CC Confirmation de création de connexion
CR Demande de création de connexion (connection creation request)
CT Fin de connexion (connection termination)
DT Données (data)
HB Pulsation (heartbeat)
JC Confirmation de participation tardive (late join confirm)
2 R ec. UIT-T X.606 (10/2001)
ISO/CEI 14476-1:2002 (F)
JR Demande de participation tardive (late join request)
LR Demande de sortie (leave request)
ND Données nulles (null data)
RD Données de retransmission (retransmission data)
TC Confirmation de participation à l'arborescence (tree join confirm)
TJ Demande de participation à l'arborescence (tree join request)
4.2 Divers
ECTP Protocole de transport de communications amélioré (enhanced communications transport protocol)
ECTS Service de transport de communications amélioré (enhanced communications transport service)
IETF Groupe de travail d'ingénierie Internet (Internet engineering task force)
IGMP Protocole de gestion de groupe Internet (Internet group management protocol)
IP Protocole Internet (Internet protocol)
QS Qualité de service
RFC Demande de commentaires (request for comments)
RMT Transport multidiffusion fiable (reliable multicast transport)
SAP Protocole d'annonce de session (session announcement protocol)
SDP Protocole de description de session (session description protocol)
TCP Protocole de commande de transmission (transmission control protocol)
UDP Protocole datagramme d'utilisateur (user datagram protocol)
5 Conventions
Dans la présente Recommandation | Norme internationale, les mots clés "DOIT", "REQUIS", "NE DOIT PAS",
"DEVRAIT", "NE DEVRAIT PAS", "PEUT" et "FACULTATIF" doivent être interprétés ainsi qu'il est décrit dans le
document IETF RFC 2119 et indiquent le degré auquel une prescription est contraignante pour l'implémentation du
protocole ECTP. Les majuscules et les minuscules sont différenciées pour ces mots clés.
6 Aperçu général
Le protocole ECTP est un protocole de transport destiné à prendre en charge les applications multidiffusion Internet. Il
fonctionne sur les réseaux IPv4/IPv6 ayant une capacité de transmission multidiffusion IP.
La présente Spécification décrit le protocole ECTP destiné à la connexion de transport multidiffusion simplex, qui
comprend un expéditeur et de nombreux destinataires. Le protocole ECTP assure les fonctions de gestion de connexion,
qui sont fondées sur la Rec. UIT-T X.605 | ISO/CEI 13252. Ces fonctions comprennent les opérations de création et de
fin de connexion, de pause et de reprise de connexion, de participation à une connexion et de sortie. Pour un transfert
fiable des données multidiffusées, le protocole ECTP offre également des mécanismes assurant la protection contre les
erreurs, le contrôle de flux et la gestion des encombrements. Pour permettre l'échelonnabilité par rapport à des groupes
multidiffusées de grande taille, on utilise des mécanismes de gestion de la fiabilité de type arborescent qui sont
compatibles avec ceux proposés par le Groupe de travail RMT de l'IETF.
Rec. UIT-T X.606 (10/2001) 3
ISO/CEI 14476-1:2002 (F)
La Figure 2 donne un aperçu des opérations du protocole ECTP.
Création de la connexion
Création de l'arborescence
de gestion
Négociation de la QS
Transfert de données
en multidiffusion
Gestion de la fiabilité
de type arborescent
Durée de
la connexion
Mise à jour de la composition
ECTP
de l'arborescence
Participation tardive et sortie
Surveillance de la QS
Maintien de la QS
Fin de la connexion
T0733820-01
Figure 2 – Opérations du protocole ECTP
Comme indiqué sur la figure, les opérations de gestion de la qualité de service telles que la négociation, la surveillance et
le maintien de la qualité de service seront spécifiées dans la Rec. UIT-T X.606.1 | ISO/CEI 14476-2. En particulier, le
maintien de la qualité de service comprend les opérations de pause et de reprise de connexion et les opérations de
contrôle de flux et de gestion des encombrements.
Avant la création d'une connexion de transport ECTP, les destinataires potentiels sont enrôlés dans le groupe
multidiffusé, qui est dénommé groupe enrôlé (voir le § 8.1). Pendant l'enrôlement, les processus d'authentification
peuvent être effectués conjointement avec la distribution des clés de groupes. Les adresses multidiffusion IP et les
numéros de port doivent être annoncés aux destinataires. Ces opérations d'enrôlement peuvent être fondées sur les
protocoles bien connus SAP/SDP, HTTP (annonce de pages Web) et SMTP (messagerie électronique). Ces mécanismes
d'enrôlement spécifiques ne relèvent pas du cadre de la présente Spécification.
Un destinataire enrôlé sera connecté au réseau pouvant assurer la multidiffusion au moyen des protocoles de routage
multidiffusion IP et IGMP, qui utiliseront les adresses multidiffusion annoncées. Une connexion de transport ECTP est
créée pour les destinataires enrôlés.
Le protocole ECTP est destiné à prendre en charge des connexions multidiffusion étroitement contrôlées. L'expéditeur
ECTP est au centre des communications du groupe multidiffusé. Désigné comme propriétaire de la connexion (TO), il
est responsable de la gestion globale de la connexion en ce sens qu'il gère les opérations de création et de fin de
connexion, de pause et de reprise de connexion, de participation tardive à une connexion et de sortie.
L'expéditeur ECTP déclenche le processus de création de connexion en envoyant un message de création de connexion.
Une partie ou la totalité des destinataires enrôlés peuvent répondre en adressant des messages de confirmation à
l'expéditeur. La création de la connexion est achevée lorsque l'expéditeur reçoit les messages de confirmation de tous les
destinataires actifs ou à l'expiration d'une temporisation prédéfinie (voir le § 8.2).
4 R ec. UIT-T X.606 (10/2001)
ISO/CEI 14476-1:2002 (F)
Pendant la création de la connexion, une partie ou la totalité des destinataires du groupe enrôlé se joindront à la
connexion. Les destinataires qui se sont joints à la connexion sont dénommés destinataires actifs. Un destinataire enrôlé
qui n'est pas actif peut se joindre à la connexion en tant que participant tardif (voir le § 8.6). Celui-ci envoie une
demande de participation à l'expéditeur. En réponse à cette demande, l'expéditeur transmet un message de confirmation
de participation qui indique si la demande de participation est acceptée ou non. Un destinataire actif peut quitter la
connexion en envoyant une demande de sortie à l'expéditeur. Un destinataire qui cause des perturbations car il ne peut
pas soutenir le débit de transmission de données peut être éjecté (voir le § 8.7).
Après la création d'une connexion, l'expéditeur commence à transmettre les données multidiffusées (voir le § 8.3). Pour
la transmission de données, un flux de données d'application est segmenté de manière séquentielle et transmis par
paquets de données aux destinataires. Ces derniers transmettront les paquets de données reçus aux applications dans
l'ordre selon lequel ils ont été transmis par l'expéditeur.
Pour que le protocole soit échelonnable à des groupes multidiffusées de grande taille, le protocole ECTP utilise des
mécanismes de gestion de la fiabilité de type arborescent. Une arborescence hiérarchique est configurée pendant la
création de la connexion. Une arborescence de gestion définit une relation parent-enfant entre toute paire de nœuds de
l'arborescence. L'expéditeur est la racine de l'arborescence de gestion. Dans la hiérarchie arborescente, un ensemble de
groupes locaux est défini. Un groupe local comprend un parent et aucun ou plusieurs enfants. La protection contre les
erreurs, le contrôle de flux et la gestion des encombrements sont assurés pour chaque groupe local défini par
l'arborescence de gestion.
La Figure 3 représente une hiérarchie de gestion arborescente pour la gestion de la fiabilité, dans laquelle une relation
parent-enfant est configurée entre un expéditeur (S, sender) et un destinataire (R, receiver), ou entre un parent
destinataire (R) et son enfant destinataire (R).
S
RR R
RRRRRRR RR
T0733830-01
Figure 3 – Hiérarchie de gestion arborescente pour la gestion de la fiabilité
Le protocole ECTP définit les procédures du protocole visant la création d'une arborescence. Pendant cette opération,
une arborescence de gestion est progressivement étendue de l'expéditeur aux destinataires (voir le § 8.2.2). Il s'agit d'une
configuration descendante. Par ailleurs, le Groupe de travail RMT de l'IETF a proposé une approche ascendante dans
laquelle ce sont les destinataires qui configurent l'arborescence (voir l'Annexe B). A l'avenir, ces systèmes pourront être
incorporés dans le protocole ECTP en tant qu'options potentielles pour la création d'arborescences.
La composition de l'arborescence est mise à jour pendant la connexion. Un participant tardif peut se joindre à
l'arborescence de gestion. Le participant tardif écoute les messages de pulsation émanant d'un ou de plusieurs parents
situés sur l'arborescence puis se joint au parent qui convient le mieux. Lorsqu'un enfant quitte la connexion, le parent le
supprime de la liste des enfants. Les défaillances de nœuds sont détectées au moyen de messages de gestion périodiques
tels que messages de données nulles, messages de pulsation et messages d'accusé de réception. L'expéditeur transmet des
messages de données nulles périodiques pour indiquer qu'il existe toujours, même s'il n'a pas de données à transmettre.
Chaque parent envoie périodiquement des messages de pulsation à ses enfants. De son côté, chaque enfant transmet des
messages d'accusé de réception périodiques à son parent (voir le § 8.8).
Dans le protocole ECTP, la correction d'erreur est assurée pour chaque groupe local défini par une arborescence de
gestion (voir le § 8.4). Si un enfant détecte une perte de données, il envoie une demande de retransmission à son parent
au moyen de paquets ACK.
Rec. UIT-T X.606 (10/2001) 5
ISO/CEI 14476-1:2002 (F)
Un message ACK contient les informations qui identifient les paquets de données qui ont été effectivement reçus.
Chaque enfant peut envoyer un message ACK à son parent en appliquant l'un des deux critères de création d'accusés de
réception: fréquence de création de paquets ACK et temporisateur ACK. Si le trafic de données est important, un accusé
de réception est généré pour le nombre ACK de paquets de données. Si le trafic est faible, un message ACK sera
transmis après l'expiration du temporisateur ACK.
Après la retransmission des données, le parent active un temporisateur d'attente de retransmission. Pendant l'intervalle de
temps, la ou les demandes de retransmission concernant les mêmes données ne seront pas prises en compte. Chaque
parent peut effacer les données de sa mémoire tampon si tous ses enfants en ont accusé réception.
Les informations de contrôle de flux et de gestion des encombrements sont transmises des destinataires à l'expéditeur, le
long de l'arborescence de gestion. Ce processus de gestion sera décrit en détail dans la Rec. UIT-T X.606.1 | ISO/CEI
14476-2, qui définit la gestion de la qualité de service pour le transport multidiffusion simplex. L'expéditeur ajustera le
débit de transmission en fonction des informations de contrôle de flux et de gestion des encombrements.
Pendant la transmission de données, si des problèmes de réseau (par exemple un important encombrement) sont signalés
par les fonctions de gestion de la qualité de service définies dans la Rec. UIT-T X.606.1 | ISO/CEI 14476-2, l'expéditeur
suspend temporairement la transmission en multidiffusion. Pendant cette période, aucune nouvelle donnée n'est
transmise, tandis que l'expéditeur transmet des messages de données nulles périodiques pour indiquer qu'il existe
toujours. Après l'écoulement d'un délai prédéfini, l'expéditeur reprend la transmission de données en multidiffusion (voir
le § 8.5).
L'expéditeur met fin à la connexion en envoyant un message de fin à tous les destinataires, une fois toutes les données
multidiffusées transmises. La connexion peut aussi prendre fin à cause d'une erreur fatale de protocole comme un échec
de la connexion (voir le § 8.9).
7 Eléments du protocole
7.1 Nœuds
Les mécanismes du protocole ECTP sont fondés sur une arborescence de gestion logique, qui définit une relation parent-
enfant entre toute paire de nœuds de l'arborescence. Chaque nœud de l'arborescence relève de l'un des trois types de
nœud suivants: propriétaire principal (TO), propriétaire local (LO) et entité feuille (LE).
a) Propriétaire principal (TO, top owner)
Le propriétaire principal est la racine de l'arborescence de gestion ainsi que l'unique expéditeur de la
connexion multidiffusion simplex. Il gère les fonctions globales de gestion de connexion, y compris la
création et la fin de la connexion. Pendant la phase de création de la connexion, une arborescence de
gestion est configurée par des interactions entre l'expéditeur et les destinataires. Une fois la connexion
créée, le propriétaire principal envoie les données multidiffusées aux destinataires. Il peut suspendre
provisoirement la connexion, puis la reprendre. Il peut admettre ou rejeter les membres du groupe qui
souhaitent se joindre à la connexion existante. Une fois toutes les données transmises, le propriétaire
principal met fin à la connexion de transport multidiffusion.
b) Propriétaire local (LO, local owner)
Dans la connexion ECTP, certains destinataires peuvent être désignés comme propriétaire local. Chaque
propriétaire local a des enfants qui sont d'autres propriétaires locaux ou des entités feuilles. Les
propriétaires locaux sont donc des nœuds intérieurs de l'arborescence. Chaque propriétaire local
retransmet les données multidiffusées qui ont été perdues par ses enfants. Il regroupe aussi les
informations de contrôle de flux et de gestion des encombrements émanant de ses enfants et transmet les
informations regroupées au propriétaire principal. Ce dernier est aussi un propriétaire local en ce qui
concerne les opérations de gestion de la fiabilité.
c) Entité feuille (LE, leaf entity)
On appelle entité feuille un destinataire qui n'a pas été désigné comme propriétaire local. Une entité
feuille ne peut pas avoir d'enfants. Elle occupe donc une position de nœud feuille sur l'arborescence de
gestion.
Le propriétaire principal est l'unique expéditeur. Les propriétaires locaux et les entités feuilles sont des destinataires.
Dans la hiérarchie arborescente, un groupe local est constitué d'un parent et de ses enfants. Le propriétaire principal ou
un propriétaire local peut être un parent, et un propriétaire local ou une entité feuille peut être un enfant.
6 R ec. UIT-T X.606 (10/2001)
ISO/CEI 14476-1:2002 (F)
Dans la hiérarchie arborescente, un propriétaire local retransmet les données multidiffusées perdues à ses enfants (reprise
après incident) et transmet les informations de contrôle de flux et de gestion des encombrements au propriétaire
principal. En outre, chaque propriétaire local est habilité à éjecter un enfant perturbateur pour maintenir la stabilité de la
connexion. Il est donc prévu que les propriétaires locaux ont davantage de pouvoirs et de responsabilités que les entités
feuilles en matière de traitement.
Dans le protocole ECTP, il est présumé que certains des destinataires ont été désignés comme propriétaires locaux avant
la création de la connexion. La présente spécification ne vise pas le choix des propriétaires locaux parmi les destinataires
pendant la connexion. Autrement dit, avant la création de la connexion (ou pendant la phase d'enrôlement), chaque
destinataire DOIT savoir s'il est un propriétaire local ou une entité feuille. Dans un groupe de très petite taille ou sur des
réseaux asynchrones tels que des réseaux satellitaires ou mobiles, aucun propriétaire local ne peut être désigné. Dans ces
environnements, tous les destinataires seront des entités feuilles.
Un propriétaire local peut être un hôte d'extrémité ou un serveur spécialisé. Sur les réseaux à gestion privée, les serveurs
spécialisés fonctionnent probablement comme propriétaires locaux. Sur les réseaux publics, les hôtes d'extrémité peuvent
être utilisés comme propriétaires locaux. Dans chaque cas, un propriétaire local est un destinataire et effectue, en tant que
parent, les opérations de gestion de la fiabilité pour son groupe local.
7.2 Arborescence de gestion
Après la création d'une connexion, le propriétaire principal transmet les données à tous les destinataires en mode
multidiffusion. Chaque enfant envoie à son parent des informations d'état concernant la réception des données. Les
informations seront ainsi transmises au propriétaire principal le long de l'arborescence de gestion. Les flux de données
multidiffusées sont transmis du propriétaire principal (TO) aux propriétaires locaux (LO) et aux entités feuilles (LE) dans
le sens descendant, tandis que les informations de gestion sont transmises des entités feuilles au propriétaire principal par
le biais des propriétaires locaux, dans le sens ascendant, le long de l'arborescence de gestion.
La Figure 4 représente la structure générale d'une arborescence de gestion ECTP.
TO Niveau 0
Niveau 1
LO LO LO
Niveau 2
LE LO LE LE LE LO LE LE LO
Niveau 3
LE LE LE LE LE LE LE
T0733840-01
Figure 4 – Arborescence de gestion ECTP
Une arborescence de gestion définit la relation parent-enfant entre toute paire de nœuds. L'arborescence de gestion
communique à chaque nœud d'arborescence les informations suivantes:
− qui est mon nœud parent ? (propriétaires locaux et entités feuilles);
− qui sont mes nœuds enfants ? (propriétaire principal et propriétaires locaux).
Rec. UIT-T X.606 (10/2001) 7
ISO/CEI 14476-1:2002 (F)
A partir des informations décrites ci-dessus, un nœud de l'arborescence peut tenir à jour la liste de ses parents et/ou de
ses enfants. Dans la liste, chaque élément est identifié par son adresse de transport et tous les éléments sont disposés
selon l'ordre d'une règle prédéfinie telle qu'une adresse IP ou une distance de bond, etc. La liste des parents peut
comprendre un ou plusieurs éléments, dont certains seront utilisés comme nœuds parents de secours en cas de défaillance
du nœud parent existant.
Le protocole ECTP offre trois options de configuration de l'arborescence (voir le § 8.2.2). D'autres options additionnelles
pourront être définies à l'avenir selon les prescriptions des applications multidiffusion (voir l'Annexe B).
7.3 Adressage
7.3.1 Port
Le protocole ECTP se sert d'une série de ports pour identifier les différentes applications dans un hôte d'extrémité IP. Le
numéro de port est inséré dans chaque en-tête de paquet. En général, un hôte IP peut prendre en charge un certain
nombre de ports, et chaque numéro de port est unique pour l'hôte. La liaison des ports aux processus est gérée de manière
indépendante par chaque hôte.
Pour une connexion de transport multidiffusion, au moins deux ports sont utilisés. Si l'interface de connexion est utilisée
pour l'implémentation, elle sera reliée à au moins deux ports. L'un de ces derniers est un port utilisé pour la transmission
et la réception de données en multidiffusion, qui DOIT être annoncé aux membres du groupe avant la création de la
connexion. L'autre port est un port attribué localement dans un système et sera appelé numéro de port de destination pour
la transmission des messages de gestion unidiffusés.
A la libération d'une connexion de transport, il est nécessaire d'empêcher le port existant d'être réutilisé par une autre
nouvelle connexion car les paquets associés à ce port peuvent encore exister sur le réseau et arriver à destination même
après la fin de la connexion. Il est donc recommandé de geler le port concerné si la connexion est libérée. Le port gelé
NE DOIT PAS être réutilisé par une autre connexion pendant un laps de temps déterminé.
7.3.2 Adresses de transport
Une adresse de transport est définie comme étant une paire constituée d'une adresse IP et d'un numéro de port. L'adresse
de transport multidiffusion comprend une adresse multidiffusion IP et un numéro de port. Le propriétaire principal (TO)
envoie des données multidiffusées en définissant l'adresse de transport multidiffusion comme adresse de transport de
destination. Chaque destinataire reçoit les données multidiffusées du propriétaire principal à l'adresse de transport
multidiffusion. Cette adresse de transport multidiffusion destinée à la transmission de données DOIT être annoncée à
tous les membres du groupe pendant la phase d'enrôlement.
Une adresse de transport unidiffusion est identifiée par une paire constituée d'une adresse unidiffusion IP et d'un numéro
de port local. Lorsque le propriétaire principal envoie des données multidiffusées, il définit comme adresse de transport
source correspondante son adresse de transport unidiffusion. Celle-ci est aussi utilisée lorsqu'un nœud transmet un
message de gestion unidiffusion à un autre nœud.
7.3.3 Données multidiffusées et adresses de gestion
En mode ECTP, le propriétaire principal (TO) envoie des données à tous les destinataires en mode multidiffusion, alors
que les propriétaires locaux (LO) envoient des données de retransmission et des messages de gestion à leur groupe
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...