ISO/IEC 14476-5:2008
(Main)Information technology — Enhanced communications transport protocol: Specification of N-plex multicast transport — Part 5:
Information technology — Enhanced communications transport protocol: Specification of N-plex multicast transport — Part 5:
ISO/IEC 14476-5:2008 defines a protocol for N-plex multicast transport over the Internet where IP multicast is supported. It provides the mechanisms of session control and error control. For session control, one participant is designated to manage creation/termination of a connection; join/leave of a participant; and tokens which allow the specific participants to send data. For error control, it provides the mechanisms of tree-based loss recovery; control tree construction with two-layer logical tree; and logical tree adaptation with packet delivery status. ISO/IEC 14476-5:2008 specifies the protocol details such as packet format, procedures, and parameter values. This protocol can be used for the applications which require many-to-many reliable data delivery service.
Technologies de l'information — Protocole de transport de communications amélioré: Spécification du transport multidiffusé N-plex — Partie 5:
L'ISO/CEI 14476-5:2008 définit le protocole de transport multidiffusé n-plex visant à prendre en charge les applications multidiffusion IP internet. Pour la session de contrôle, un participant est désigné pour gérer la création/terminaison de la connexion; arrivée/départ d'un participant; et des prises permettant aux participants d'envoyer des données. Pour la protection contre les erreurs, elle fournit les mécanismes d'une récupération de perte basée sur une arborescence; construction d'une arborescence de contrôle avec une arborescence logique à deux couches et une adaptation d'arborescence logique avec l'état de transmission du paquet. L'ISO/CEI 14476‑5:2008 spécifie les détails de protocole tels que format de paquet, modes opératoires et valeurs de paramètre. Ce protocole peut être utilisé pour les applications qui nécessitent un service de livraison fiable multiple de données.
General Information
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 14476-5
First edition
2008-04-15
Information technology — Enhanced
communications transport protocol:
Specification of N-plex multicast
transport
Technologies de l'information — Protocole de transport de
communications amélioré: Spécification pour le transport N-plex 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 copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2008 – All rights reserved
CONTENTS
Page
1 Scope. 1
2 References . 1
2.1 Normative references. 1
2.2 Informative references . 1
3 Definitions . 1
4 Abbreviations . 2
5 Conventions . 3
6 Overview. 3
7 Considerations . 5
7.1 Participants. 5
7.2 Data channel and addressing . 6
7.3 Control channel and tree. 6
7.4 Tokens. 8
7.5 Logical tree adaptation. 8
8 Packets. 10
8.1 Base header. 10
8.2 Extension elements. 12
8.3 Packet format . 17
9 Procedures . 35
9.1 Connection management . 35
9.2 Logical tree management. 37
9.3 Multicast data transport . 42
9.4 Token control. 45
9.5 RTT measurement. 47
10 System parameters. 47
Annex A – Application programming interfaces. 49
A.1 Overview. 49
A.2 ECTP-5 API functions . 49
Annex B – State transition diagrams . 54
Annex C – An example of system parameters values in ECTP-5 . 56
© 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-5 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.608 (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
ECTP is designed to support tightly controlled multicast connections in simplex, duplex and N-plex applications. This
part of ECTP (Part 5: ITU-T Rec. X.608 | ISO/IEC 14476-5) specifies the protocol mechanisms for the N-plex multicast
data transport.
In the N-plex multicast connection, the participants include one TC-Owner and many TS-users. TC-Owner will be
designated among the TS-users before the connection begins. TC-Owner is at the heart of multicast group
communications. It is responsible for overall connection management by governing the connection creation and
termination, multicast data transport, and the late join and leave operations.
In the N-plex multicast connection, the multicast data transmissions are allowed by TS-users as well as TC-Owner.
Each TS-user is allowed to send multicast data to the group only if it gets a token from the TC-Owner. That is, the
multicast data transmissions of TS-users are controlled by TC-Owner.
The N-plex multicast connection specified in this Recommendation | International Standard targets the many-to-many
multicast applications in which many participants (TS-users) may want to transmit the multicast data to all the other
TS-users. Typical examples of such applications include 'teleconferencing' and 'multi-users on-line game', etc. In the
teleconferencing application, TC-Owner may act as a 'conferencing server', and all the other participants (TS-users)
may send multicast data, such as voice, text and image, to the other participants.
© ISO/IEC 2008 – All rights reserved v
INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
Information technology – Enhanced communications transport protocol:
Specification of N-plex multicast transport
1 Scope
This Recommendation | International Standard specifies the N-plex multicast transport connection in which all
participants are TS-users and one of them is TC-Owner. The N-plex multicast transport connection allows TS-users to
send the multicast data to all the group members. It is noted that a TS-user is allowed to send the multicast data to the
group, only if it gets a token from TC-Owner.
This Specification describes the protocol for supporting the N-plex multicast transport, which includes the connection
management (establishment, termination, user join and leave) and the reliability control mechanisms for the multicast
data transport.
2 References
2.1 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 Recommendation 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.
– ITU-T Recommendation X.607 (2007) | ISO/IEC 14476-3:2008, Information technology – Enhanced
communications transport protocol: Specification of duplex multicast transport.
2.2 Informative references
– ITU-T Recommendation X.607.1 (draft) | ISO/IEC 14476-4, Information technology – Enhanced
communications transport protocol: Specification of QoS management for duplex 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.
ITU-T Rec. X.608 (02/2007) 1
This Recommendation | International Standard redefines the following definitions specified in Enhanced
Communications Transport Service (ITU-T Rec. X.605 | ISO/IEC 13252).
a) TC-owner (TCN): TCN manages overall operations of an N-plex multicast connection.
b) transport service user (TS-user): TS-users can send and receive multicast data in the N-plex multicast
connection.
c) sending TS-user (SU): A TS-user who gets a token from TCN. Only the SU is allowed to send multicast
data to the group. In other words, before sending multicast data, each TS-user must request a token to
TCN.
This Recommendation | International Standard redefines the following terminologies specified in Enhanced
Communications Transport Protocol: part 1 (ITU-T Rec. X.606 | ISO/IEC 14476-1) to accommodate to N-plex
multicast connection.
a) local group: A set of nodes in vicinity which has network-layer correlation in terms of packet loss and
delay.
b) local owner (LO): LO is a representative node of a local group and designated statically. It is
responsible for maintaining an intra-group tree of the group and control trees for all SUs in its local
group. Each LO is also connected to the other LOs along inter-group trees. It also generates test traffic
periodically for logical tree adaptation.
c) multicast data channel: TCN or SU can send multicast data to all the other group members over
IP multicast address.
This Recommendation | International Standard newly defines the following terminologies:
a) logical tree: A tree that spans all TS-users and one or more control trees are derived from it.
b) inter-group tree: A per-source logical tree of the LOs.
c) intra-group tree: A shared logical tree of each local group.
d) control tree: A tree along which control packets for error control are traversed.
e) token: It represents the right for a TS-user to transmit multicast data. The TS-user who has a token is
called SU. The tokens are managed by TCN.
4 Abbreviations
The following acronyms for ECTP protocols are used in this Recommendation | International Standard:
ECTP-1 ECTP part 1 (ITU-T Rec. X.606 | ISO/IEC 14476-1)
ECTP-2 ECTP part 2 (ITU-T Rec. X.606.1 | ISO/IEC 14476-2)
ECTP-3 ECTP part 3 (ITU-T Rec. X.607 | ISO/IEC 14476-3)
ECTP-4 ECTP part 4 (ITU-T Rec. X.607.1 | ISO/IEC 14476-4)
ECTP-5 ECTP part 5 (ITU-T Rec. X.608 | ISO/IEC 14476-5)
ECTP-6 ECTP part 6 (ITU-T Rec. X.608.1 | ISO/IEC 14476-6)
The following acronyms for ECTP-5 packets are used in this Recommendation | International Standard:
ACK Acknowledgment
CC Connection Creation Confirm
CCC Control Tree Change Confirm
CCR Control Tree Change Request
CR Connection Creation Request
CT Connection Termination Request
DT Data
JC Late Join Confirm
JR Late Join Request
LR User Leave Request
NACK Negative Acknowledgement
PB Probe
2 ITU-T Rec. X.608 (02/2007)
PBACK Probe Acknowledgment
RD Retransmission Data
TC Tree Join Confirm
TCC Tree Change Confirm
TCR Tree Change Request
TDC Tree Delegation Confirm
TDR Tree Delegation Request
TGC Token Get Confirm
TGR Token Get Request
TJ Tree Join Request
TLC Tree Leave Confirm
TLR Tree Leave Request
TNC Tree Change Notification Confirm
TNR Tree Change Notification Request
TRC Token Return Confirm
TRR Token Return Request
TSR Token Status Report
TSRR Token Status Report Request
5 Conventions
In this Recommendation | International Standard, packets of ECTP-5 are represented as words with all capital characters
(e.g., CR for Connection Creation Request packet), and system parameters are represented as words with all italic
capital characters (e.g., TD_PACKET_INT for test data packet interval).
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 5 (ECTP-5) for the
N-plex multicast connection. The N-plex multicast connection is used for supporting multicast data transport between
the participants (TS-users). In the N-plex multicast connection, TS-users can send multicast data packets to the group
over multicast data channel. A TS-user who is sending multicast data in the N-plex multicast connection is called SU
(Sending TS-user). Any SU must have a token for multicast data transmission. In other words, the TS-user who gets a
token from TCN is called an SU.
Figure 2 illustrates the multicast data transport channel in the N-plex multicast connection. As shown in the figure, TCN
and SU can transmit multicast data to the other session members over IP multicast (group) address.
ITU-T Rec. X.608 (02/2007) 3
Figure 2 – Multicast data transport in N-plex multicast connection
To establish an N-plex multicast connection, TCN should be activated to manage session information and tokens.
If the TCN is informed of a participant list by out-of-band signalling prior to starting the connection, it should start a
connection creation phase by transmitting a CR packet to the group. The CR packet contains the connection information
including general characteristics of the connection. Each TS-user who is contained in the participant list should respond
to the TCN with a CC packet. The connection creation operation will be completed when the TCN receives CC packets
from all of the TS-users in the participant list, and the data transmission phase starts. If there is no predetermined
participant prior to starting the session, TCN starts the data transmission phase without connection creation operations.
In the middle of data transmission phase, the prospective TS-users should join the connection as late-joiners. The
late-joining TS-user participates in the connection by sending a Late Join Request (JR) message to TCN. In response to
the JR message, TCN sends a Late Join Confirm (JC) message to the TS-user. After a TS-user is confirmed to join the
session, it should join a logical tree by exchanging the Tree Join Request (TJ) and Tree Join Confirm (TC) messages
with an appropriate LO. The logical tree is used for error control.
An N-plex multicast connection builds a two-layer logical tree, which consists of intra-group shared trees and
inter-group per-source trees, as shown in Figure 3.
Figure 3 – A two-layer tree for N-plex multicast connection
At the bottom layer, each LE in a local group joins an LO-rooted shared logical tree (intra-group tree). At the top layer,
LOs constitute logical trees for each SU (inter-group tree). It is noted that the control tree for each SU is derived by
grafting these inter-group and intra-group trees.
4 ITU-T Rec. X.608 (02/2007)
In N-plex multicast connection, intra-group trees can be organized differently depending on the roles of LEs, which is
determined by TCO (Tree Configuration Option). One option of TCO is that all LEs are direct children of LOs and do
not participate in the repair process and ACK aggregations. Thus, intra-group trees will be an LO-rooted one-level tree
in this option. The other option is that LEs can be children of other LEs. In this option, LEs are responsible for
reliability support of its children LEs and intra-group trees can be multi-level trees. For the sake of efficiency of
reliability support, the multi-level intra-group trees should be as close as possible to underlying multicast routing tree.
The N-plex multicast connection adopts logical tree adaptation mechanism for this option. For this, error bitmaps of
TS-users are used. An error bitmap represents packet delivery status, which indicates the loss pattern of multicast
packets. Each TS-user sends its error bitmap to its parent with respect to multicast data from the root node of its intra-
group tree with periodic ACK messages. By comparing error bitmaps of itself and those of its children, a node decides
whether each child is likely to be its actual child in the underlying multicast routing tree or not. If the child node is
determined not to be its actual child, a node changes the logical tree by delegating the child node to its parent or one of
its other children. After recursive tree changes, the intra-group tree will converge to a multi-level tree that is closer to
underlying multicast routing tree.
The error control will be performed based on the ECTP control tree which is constructed as described above. If packet
loss is detected by a gap of the packet sequence numbers, a child node sends a NACK packet to its parent immediately
via unicast. The parent LO or SU, that receives the NACK packet, will retransmit data packet (RD) to the requestor via
unicast. Each child generates an ACK packet every ACK_GENERATION_NUM (AGN) data packets.
In the multicast data transmission, TCN and SUs can begin the multicast data transmission to the group by using the
IP multicast address and group port number. The TS-users will deliver the received DT packets to the upper-layer
application in the order transmitted by SU or TCN.
For the multicast data transport, a TS-user in the connection may get a token from TCN by sending a TGR message.
The TCN will then respond to the TS-user with the TGC message that contains a Token ID. Accordingly, the total
number of tokens in the connection is controlled by TCN. The TS-user who has a token is called Sending TS-user (SU).
In a certain case, the TCN can first request a TS-user to be an SU by sending the TGR message to the promising SU,
which is called Token Give.
After completing the multicast data transmission, the SU will return the token to the TCN by sending a TRR message.
TCN will respond to the SU with a TRC message. In a certain case, the TCN first requests the SU to return the token,
which is called Token Withdrawal. TCN announces the overall status of the Token IDs valid in the connection to the
group by sending the TSR packets.
TCN manages the connection for user leave. In the User Leave operation, a participating TS-user may leave the
connection by sending an LR message to the parent. In a certain case, the TCN may enforce a specific TS-user to leave
the connection by sending the LR message, which is called the troublemaker ejection.
TCN may terminate the N-plex connection by sending a CT message to the group.
7 Considerations
7.1 Participants
All participants to an N-plex multicast connection are TS-users and one of them is TCN (TC-Owner).
TCN (TC-Owner):
An N-plex multicast connection has a single TCN. The TCN is responsible for connection management
including connection creation/termination, late join, connection maintenance, and token management.
For example, in the teleconferencing applications, the TCN may act as the 'conference server', which may be
used for control of the conferencing without sending multicast data. In the example of 'multi-users on-line
game' application, the TCN may act as the 'game-control server'.
TS-user (Transport Service User):
An N-plex multicast connection has one or more TS-users. Each of them sends and receives multicast data in
the connection.
A TS-user can become LO or LE depending on its role.
LO (Local Owner):
LO is a representative node of a local group and designated statically. It is responsible for maintaining an
intra-group tree of the group and control trees for all SUs in its local group. Each LO is also connected to the
other LOs with inter-group trees. It also generates test traffic periodically for logical tree adaptation.
ITU-T Rec. X.608 (02/2007) 5
LE (Leaf Entity):
LE is a member of a local group whose representative is an LO. It should join an intra-group tree of the group
and is responsible for exchanging control packets with its parent or child LEs along the control tree.
A TS-user can become SU when it obtains a token from TCN.
SU (Sending TS-user):
An SU is a TS-user who can send multicast data to the group. In an N-plex multicast connection, a TS-user
becomes an SU when it has a token and it can thus transmit multicast data to the group.
7.2 Data channel and addressing
In N-plex multicast connection, SU or TCN can send multicast data packets to the session members as shown in
Figure 4.
Figure 4 – Multicast data addressing in N-plex multicast connection
In an N-plex multicast connection, the multicast data packets (DTs) use the IP multicast address and the group port
number as the destination address. The source address of the multicast data IP packets is the IP address of the sender of
the packet. In contrast, the retransmission data packets (RDs) in response to the repair requests (NACKs) are delivered
by LO or SU over control channel using unicast with the IP address of the repair requester as the destination.
7.3 Control channel and tree
In an N-plex multicast connection, there are control channels for error recovery. All members participate in one or more
control trees. These trees are used as control channels for exchanging control messages among participants. A parent
node acts as an agent who helps child nodes to recover from packet loss. It also aggregates the acknowledgement
information from its descendant nodes. All control packets such as RD, NACK, and ACK are delivered via control
channel using unicast.
An N-plex multicast connection is divided into multiple local groups of the participants for error control. Based on this
group approach, participants construct and maintain control trees along which all the error control packets are
exchanged. Control trees are constructed from two layers of logical trees. At the bottom layer, members in a local group
join an LO-rooted shared logical tree (intra-group tree). At the top layer, the LOs of the groups constitute per-source
logical trees (inter-group tree). That is, every LE joins a local group and it grafts onto LO-rooted logical tree of the
group as a child (or descendents) of the LO. Every LO grafts onto logical tree of the LOs, of which root is the LO of the
group that the SU belongs to. A control tree for each source is constructed by connecting the inter-group trees and
intra-group trees.
Inter-group trees are generated and maintained exactly as required. Any inter-group tree rooted by an LO who has no
more SU children should be removed.
Intra-group trees can evolve to multi-level trees that reflect actual multicast routing paths by logical tree adaptation
mechanism, which is described in 7.5.
By traversing logical trees starting from an SU, we can get an SU-rooted tree that is the control tree for the SU.
If an SU belongs to another local group, a part of the control tree generated for current local group is the intra-group
tree of the group. Control trees for the SUs belonging to the same local group are slightly different from the intra-group
tree, because the intermediate nodes between LO and the SU have reversed parent-child relationships.
6 ITU-T Rec. X.608 (02/2007)
Assuming that the logical trees of the participants are constructed as in Figure 5, the control tree for source SU1 will be
constructed as in Figure 6.
Figure 5 – Two layers of logical trees
Figure 6 – Control tree when sender is SU1
ITU-T Rec. X.608 (02/2007) 7
In the same way, Figure 7 shows the control tree whose source is SU2.
SU2
LE7
LO2
LE6 LO1 LO3
LE2 SU1 LE4 LE5
LE3 LE1
X.608(07)_F07
Figure 7 – Control tree when sender is SU2
Control trees are maintained by information obtained through the exchange of NACK and ACK packets. The parent can
detect a child's failure by comparing its own LSN and received child's LSN. Children can detect their parent's failure if
there is no response from parent for several consecutive repair requests. Then the child finds another parent by
contacting LO.
7.4 Tokens
In N-plex multicast connection, a token represents the right for a TS-user to send multicast data to TCN. Before
transmitting data, each TS-user must get a token from the TCN, as per the Token Control procedures of N-plex
multicast connection. By this procedure, TCN can authorize a TS-user to become a sender so that TS-users can
effectively filter out multicast data sent by unauthorized users. However, note that use of token does not provide any
protection for IP multicast.
Each token is represented as a 1-byte non-negative integer. Such a token number (or Token ID) will be assigned by
TCN 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 TCN. At the receiver side, the Token ID can be used to authorize who can send the multicast data.
7.5 Logical tree adaptation
In N-plex multicast connection, intra-group trees may evolve to multi-level trees close to underlying multicast routing
trees when TCO is '10'. Loss pattern comparison is used to estimate the underlying multicast routing trees. The
estimation is made feasible because if a loss occurs at a parent node of a multicast routing tree, all of its children also
experience the same loss. The root of an intra-group tree does not change by the logical tree adaptation process.
For this, each receiver in a multicast session maintains packet delivery status called error bitmap, which indicates the
loss pattern of multicast packets. An error bitmap consists of two parts: sequence number (Ns) and an actual bitmap (B).
Ns is the sequence number of the first packet in a sequence of packets represented in the bitmap. One bit of B indicates
the reception status of the corresponding packet; '1' means a successful packet delivery to a receiver without error
recovery and '0' otherwise. The bitmap includes loss patterns of multicast packets. For example, if Ns = 5 and
B = 11010, the receiver has successfully received packets 5, 6, and 8. Even packets 7 and 9 have been recovered via
retransmissions, these bits are recorded as '0's. Each receiver periodically feeds the error bitmap information to its
parent in the tree. If a logical tree matches a multicast routing tree and a bit in the error bitmap at a node is set to 1, the
corresponding bit in the error bitmap of its parent is very likely to be '1'. Note that the error bitmap of a source always
consists of all '1's.
8 ITU-T Rec. X.608 (02/2007)
Every node that has child nodes compares the error bitmaps of itself and its children to check whether the relationships
between the node and its child nodes reflect the underlying multicast routing tree closely. A parent node can infer that
some child nodes need to change their locations in the logical tree. The child node would be a child of other child node.
Or it would not be a descendant of the parent node.
For instance, Figure 8 shows an example of a multicast routing tree and error bitmaps of each node.
Figure 8 – An example of multicast routing tree
Figures 9 and 10 briefly describe how a logical tree close to a multicast routing tree is constructed by the error bitmap
information.
First, it is assumed that a root LO is a strategically deployed server that is usually located nearby the egress point of
Internet service provider. Boxes represent routers and numbers below nodes are error bitmaps of each node.
Figure 9 – Logical tree adaptation (LE2 adopts LE3)
The left side of Figure 9 shows an initial one-level intra-group tree of nodes in Figure 8. When LO becomes aware of
error bitmaps of its children, it finds out that LE3 is likely to be a child or descendant of LE2 since a set of received
packets of LE3 is a subset of that of LE2. Thus, it delegates LE3 to LE2 by sending a TDR (Tree Delegation Request)
message. Receiving the message, LE2 judges that LE3 is its child and sends a TCR message (Tree Change Request) to
LE3. Receiving the TCR message, LE3 joins as a child of LE2 by sending TJ to LE2 and leaves its previous parent, LO,
by sending TLR. Note that a node receiving a TCR message is attached to the new parent before leaving its previous
parent. The result is a tree on the right side of Figure 9.
ITU-T Rec. X.608 (02/2007) 9
Figure 10 shows another example of the logical tree adaptation.
Figure 10 – Logical tree adaptation (LO adopts LE3; LE2 adopts LE3)
On the left side of Figure 10, LE3 has become a child of LE1 by previous tree adaptation mistakenly. However, a
current error bitmap of LE3 indicates that LE3 is not a child of LE1 since it received a packet that is not received by
LE1. In this case, LE1 delegates LE3 to its parent, LO, to find the proper position of LE3 by sending a TDR message.
LO receives the TDR message from LE1 about LE3 and compares error bitmap of LE3 with its children LE1 and LE2.
The LO finds out that LE3 is likely to be a child of LE2. Finally, the logical tree converges to the tree on the right side
of Figure 10.
In this way, intra-group trees can evolve to multi-level trees that approximate underlying multicast routing trees.
Control trees built from these intra-group trees will also be very close to the multicast routing trees.
For this, LO sends test DATA packets when it detects change of the intra-group tree. Then the LEs in the local group
construct error bitmap information and send it via ACK packet. The test DATA packets are not destined to any
application, and should be sent every TD_PACKET_INT and in TD_PACKET_NUM times.
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 (DTs) do not include any extension elements. The generic packet format of ECTP-5 is illustrated in
Figure 11:
bytes 0 . 15 16 . . PL-1
Base header Extension elements or user data
PL Packet Length
Figure 11 – Packet format of ECTP-5
8.1 Base header
The 16-byte base header contains common information helpful to all the protocol operations, in particular for the data
packets. Figure 12 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 12 – Base header (ECTP over IP)
10 ITU-T Rec. X.608 (02/2007)
The base header contains the following information:
Next element (4 bits)
This specifies the type of the extension element immediately following the base header. The encoding values
of the extension elements will be described later. The extension element value of '0000' means that there is no
more following extension element after this element.
Version (2 bits)
This defines the version of the protocol for this Recommendation | International Standard. Its current version
is encoded as '00'.
CT (Connection Type) (2 bits)
This specifies the type of the ECTP connection. The encoding value is as follows:
01 – simplex multicast connection (for ECTP-1 and ECTP-2);
10 – duplex multicast connection (for ECTP-3 and ECTP-4);
11 – N-plex multicast connection (for ECTP-5 and ECTP-6).
In this Recommendation | International Standard, the CT must be set as '11'.
Packet type (8 bits)
It indicates the type of the packet.
Checksum (16 bits)
This is used to check the validity of the packet that includes the base header, extension header and/or user
data. The checksum is calculated by using the conventional one's complement arithmetic operation, as done in
TCP and UDP.
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 over IP.
When ECTP operates over UDP, these fields are used to represent the connection identifier, as described later.
PSN (32 bits)
For the DT packets, this field is a 32-bit unsigned number that starts with the initial sequence number and
increases by '1' for every packet, and wraps back around to '1' after reaching '2 – 1'.
For the ACK packets, this field is the LSN of an SU with Token ID.
For the RD packets, this field is the PSN of the data packet, which is requested to be retransmitted.
For the TJ, TLR, JR, TGR, TRR, TCR, TDR, TNR and CCR, this field is the sequence number of control
packets from a node. It should be unique within the same packet type sent by the node.
For the TC, TLC, JC, TGC, TRC, TCC, TDC, TNC, and CCC, this field is copied from the PSN field of the
corresponding request packet.
For the other packets, this field should be ignored.
Payload length (16 bits)
This value indicates the total length of the extension headers or user data in byte, following the base header.
F (1 bit)
It is a flag bit. The use of this flag depends on the packet types:
For the JC, TC, TGC, TCC, TDC, TRC and TLC packets, the F = 1 indicates that each of the corresponding
join request is accepted. F is set to 0, otherwise.
For the TJ and TLR, the F is set to '1' for inter-group tree join or leave, or set to '0' for the intra-group tree join
or leave respectively.
For the LR packet, F is set to '1' for the user-invoked leave, or set to '0' for the troublemaker ejection.
For the CT packet, F is set to '1' for an abnormal termination, or set to '0' for the normal termination after all
the data have been transmitted.
For the token control operations, TGR and TRR request messages use this flag so as to indicate whether this is
the TCN-initiated or TS-user-initiated token control.
For the TSR packet, the F = 1 indicates that the overall token status is changed by adding a new token or
deleting an existing token. On the other hand, the F = 0 means that this TSR packet is for the information.
For the TNR, the F is set to '1' for tree join, or F is set to '0' for tree leave.
ITU-T Rec. X.608 (02/2007) 11
For DT packet, F is set to '1' for test DT from LO for logical tree adaptation, or set to '0' for the DT from
normal applications.
For RD packet, F is set to '1' if the sender has no data to repair, otherwise '0'.
For the other packets, this field will be ignored.
Reserved (7 bits)
Token ID (8 bits)
The Token ID is valid only for DT and RD packets. This represents the source of the data packets. The Token
ID value is ranged between 0 and 255. Each SU receives a Token ID from TCN via the token get and give
procedure and sets this field to be the number assigned by TCN.
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.
The base header format for ECTP over UDP is as shown in Figure 13:
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 13 – 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 TCN to the other participants via
the CR or JC packets. All the other packets in this Recommendation | International Standard must set this field to be the
value announced by TCN.
8.2 Extension elements
The ECTP control packets 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. The last extension element of a packet must set its Next Header
field to '0000' (No Element).
Table 1 – Extension elements
Encoding value in next
Length of extension
Extension element element of the preceding
element (bytes)
element (4 bits)
No Element 0000 0
Connection 0001 4
Error Bitmap 0010 Varied
Timestamp 0100 12
Token 0110 Varied
LO Information 0111 Varied
Negative Acknowledgement 1000 8
Tree Change Information 1001 8
12 ITU-T Rec. X.608 (02/2007)
8.2.1 Connection element
The connection extension element contains overall information on the 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 14, 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 Reserved AGN Maximum segment size (MSS)
Figure 14 – Connection extension element
Each field is specified as follows:
Next element (4 bits)
This indicates the type of the next extension element, as indicated in Table 1.
TCO (Tree Configuration Option) (2 bits)
This specifies the tree configuration option used in ECTP-5 as follows:
00 – Reserved for future use.
01 – 1-level intra-group tree without logical tree adaptation.
10 – Multiple-level intra-group tree with tree adaptation.
11 – Reserved for future use.
The default value of TCO is '10' in N-plex multicast connection.
Reserved (2 bits)
AGN (ACK Generation Number) (8 bits)
This is a positive integer ranged from 1 to 255 (ACK_GENERATION_NUM). The AGN is used by a child
TS-user to generate and transmit an ACK packet to the parent.
MSS (16 bits)
This specifies the maximum size (in byte) of the user data segment (MAX_SEGMENT_SIZE) that can be
contained in the DT packet. The default value is '1024'.
8.2.2 Error bitmap element
This extension element provides information on the status of the packet reception at a child node. This extension header
is attached to ACK packet in response to LO's test traffic for logical tree adaptation as described in 7.5. 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 Error Bitmap, as depicted in Figure 15:
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
Error bitmap
Figure 15 – Error bitmap extension element
Each field is specified as follows:
Next elem
...
NORME ISO/CEI
INTERNATIONALE 14476-5
Première édition
2008-04-15
Technologies de l'information —
Protocole de transport de
communications amélioré: Spécification
du transport multidiffusé N-plex
Information technology — Enhanced communications transport
protocol: Specification of N-plex multicast transport
Numéro de référence
ISO/CEI 14476-5:2008(F)
©
ISO/CEI 2008
ISO/CEI 14476-5: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 copyright@iso.org
Web www.iso.org
Publié en Suisse
ii © ISO/CEI 2008 – Tous droits réservés
ISO/CEI 14476-5:2008(F)
TABLE DES MATIÈRES
Page
1 Domaine d'application . 1
2 Références . 1
2.1 Références normatives . 1
2.2 Références informatives . 1
3 Définitions . 1
4 Abréviations. 2
5 Conventions . 3
6 Aperçu général. 3
7 Considérations . 6
7.1 Participants. 6
7.2 Voie de transmission de données et adressage. 6
7.3 Voie et arborescence de gestion . 7
7.4 Jetons . 9
7.5 Adaptation des arborescences logiques. 9
8 Paquets. 11
8.1 En-tête de base . 11
8.2 Eléments d'extension . 14
8.3 Format de paquet . 18
9 Procédures . 39
9.1 Gestion de connexion. 39
9.2 Gestion d'arborescence logique. 41
9.3 Transport de données multidiffusées . 46
9.4 Gestion des jetons . 49
9.5 Mesure du temps RTT. 52
10 Paramètres du système. 52
Annexe A – Interfaces de programmation d'application . 53
A.1 Aperçu général . 53
A.2 Fonctions API du protocole ECTP-5 . 53
Annexe B – Diagrammes de transition d'état. 59
Annexe C – Exemple de valeurs de paramètres système dans le protocole ECTP-5 . 61
© ISO/CEI 2008 – Tous droits réservés iii
ISO/CEI 14476-5: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-5 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.608 (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: Protocole de transport de communications amélioré: Spécification du transport multidiffusé
N-plex
iv © ISO/CEI 2008 – Tous droits réservés
ISO/CEI 14476-5:2008(F)
Introduction
Le protocole de transport de communications amélioré (ECTP, enhanced communications transport protocol) a pour
objet de prendre en charge les connexions multidiffusion étroitement gérées dans des applications simplex, duplex et
n-plex. La présente partie du protocole ECTP (partie 5: UIT-T X.608 | ISO/CEI 14476-5) définit les mécanismes
protocolaires relatifs au transport de données multidiffusées n-plex.
Dans la connexion multidiffusée n-plex, les participants sont le propriétaire de la connexion TC et de nombreux
utilisateurs du service de transport (TS). Le propriétaire de la connexion TC sera choisi parmi les utilisateurs du service
TS avant le début de la connexion. Il 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, le transport de données
multidiffusées et les opérations de participation tardive ou de sortie.
Dans la connexion multidiffusée n-plex, les transmissions de données multidiffusées sont autorisées par les utilisateurs
du service TS et par le propriétaire de la connexion TC. Chacun des utilisateurs du service TS est autorisé à envoyer des
données multidiffusées au groupe uniquement s'il obtient un jeton du propriétaire de la connexion TC. Autrement dit,
les transmissions de données multidiffusées des utilisateurs du service TS sont gérées par le propriétaire de la
connexion TC.
La connexion multidiffusée n-plex définie dans la présente Recommandation | Norme internationale vise les
applications multidiffusion "de beaucoup à beaucoup" dans lesquelles de nombreux participants (utilisateurs du
service TS) souhaitent transmettre des données multidiffusées à tous les autres utilisateurs du service TS. Des exemples
types de ces applications sont les "téléconférences", les "jeux en ligne à multiples utilisateurs", etc. Dans les
applications de téléconférences, le propriétaire de la connexion TC peut agir en qualité de "serveur de conférence" et
tous les autres participants (utilisateurs du service TS) peuvent envoyer aux autres participants des données
multidiffusées, telles que voix, textes et images.
© ISO/CEI 2008 – Tous droits réservés v
ISO/CEI 14476-5:2008 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
Technologies de l'information – Protocole de transport de communications amélioré:
spécification du transport multidiffusé n-plex
1 Domaine d'application
La présente Recommandation | Norme internationale définit la connexion de transport multidiffusé n-plex dans laquelle
tous les participants sont des utilisateurs du service TS et l'un d'entre eux le propriétaire de la connexion TC. La
connexion de transport multidiffusé n-plex permet aux utilisateurs du service TS d'envoyer des données multidiffusées à
tous les membres du groupe. Il convient de noter qu'un utilisateur du service TS est autorisé à envoyer des données
multidiffusées au groupe 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é n-plex, qui comprend la
gestion de la connexion (établissement, fin, participation et sortie d'un utilisateur) et les mécanismes de gestion de la
fiabilité concernant le transport des données multidiffusées.
2 Références
2.1 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 valides 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 16511: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.
– Recommandation UIT-T X.607 (2007) | ISO/CEI 14476-3:2007, Technologies de l'information –
Protocole de transport de communications amélioré: spécification du transport multidiffusé duplex.
2.2 Références informatives
– Projet de Recommandation UIT-T X.607.1 | ISO/CEI 14476-4, Technologies de l'information –
Protocole de transport de communications amélioré: spécification de la gestion de la qualité de service
pour le transport multidiffusé duplex.
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.
Rec. UIT-T X.608 (02/2007) 1
ISO/CEI 14476-5:2008 (F)
La présente Recommandation | Norme internationale redéfinit les expressions suivantes utilisées dans la
Rec. UIT-T X.605 | ISO/CEI 13252 (service de transport de communications amélioré).
a) propriétaire de la connexion TC (TCN, TC-owner): le propriétaire de la connexion TC (TCN) gère les
opérations globales d'une connexion multidiffusée n-plex;
b) utilisateur du service TS (utilisateur du service de transport): les utilisateurs du service TS peuvent
envoyer et recevoir les données multidiffusées dans la connexion multidiffusée n-plex;
c) utilisateur expéditeur du service TS (SU, sending TS-user): utilisateur du service TS qui obtient un
jeton auprès du propriétaire de la connexion TC. Seul l'utilisateur expéditeur SU est autorisé à envoyer
des données multidiffusées au groupe. Autrement dit, avant d'envoyer les données multidiffusées, chaque
utilisateur du service TS doit demander un jeton au propriétaire de la connexion TC.
La présente Recommandation | Norme internationale redéfinit les termes ci-après utilisés dans la Rec. UIT-T X.606 |
ISO/CEI 14476-1 (Protocole de transport de communications amélioré: partie 1) afin de prendre en compte la
connexion multidiffusée n-plex.
a) groupe local: ensemble de nœuds proches ayant une corrélation de couche de réseau en termes de perte
de paquets et de retard;
b) propriétaire local (LO, local owner): le propriétaire local est un nœud représentatif d'un groupe local
désigné de manière statique. Il est chargé de mettre à jour une arborescence intra-groupe du groupe et des
arborescences de gestion pour tous les utilisateurs SU du groupe local. Chaque propriétaire local est aussi
connecté aux autres propriétaires locaux le long d'arborescences inter-groupes. Périodiquement, il crée
aussi un trafic de test pour l'adaptation des arborescences logiques;
c) voie de transmission des données multidiffusées: le propriétaire de la connexion TC (TCN) ou
l'utilisateur expéditeur SU peut envoyer des données multidiffusées à tous les autres membres du groupe
à une adresse IP multidiffusion.
La présente Recommandation | Norme internationale donne une nouvelle définition des termes ci-après:
a) arborescence logique: arborescence qui englobe tous les utilisateurs du service TS et dont découlent une
ou plusieurs arborescences de gestion;
b) arborescence inter-groupes: arborescence logique, par source, des propriétaires locaux;
c) arborescence intra-groupe: arborescence logique partagée par chaque groupe local;
d) arborescence de gestion: arborescence parcourue par les paquets de gestion en vue de la protection
contre les erreurs;
e) jeton: représente le droit d'un utilisateur du service TS de transmettre des données multidiffusées.
L'utilisateur du service TS détenteur d'un jeton est un utilisateur expéditeur SU. Les jetons sont gérés par
le propriétaire de la connexion TC.
4 Abréviations
Les acronymes suivants sont employés dans la présente Recommandation | Norme internationale pour les
protocoles ECTP:
ECTP-1 Protocole ECTP, partie 1 (UIT-T X.606 | ISO/CEI 14476-1)
ECTP-2 Protocole ECTP, partie 2 (UIT-T X.606.1 | ISO/CEI 14476-2)
ECTP-3 Protocole ECTP, partie 3 (UIT-T X.607 | ISO/CEI 14476-3)
ECTP-4 Protocole ECTP, partie 4 (UIT-T X.607.1 | ISO/CEI 14476-4)
ECTP-5 Protocole ECTP, partie 5 (UIT-T X.608 | ISO/CEI 14476-5)
ECTP-6 Protocole ECTP, partie 6 (UIT-T X.608.1 | ISO/CEI 14476-6)
Les acronymes suivants sont employés dans la présente Recommandation | Norme internationale pour les
paquets ECTP-5:
ACK accusé de réception (acknowledgment)
CC confirmation de création de connexion (connection creation confirm)
CCC confirmation de changement d'arborescence de gestion (control tree change confirm)
CCR demande de changement d'arborescence de gestion (control tree change request)
CR demande de création de connexion (connection creation request)
CT demande de fin de connexion (connection termination request)
2 Rec. UIT-T X.608 (02/2007)
ISO/CEI 14476-5:2008 (F)
DT données (data)
JC confirmation de participation tardive (late join confirm)
JR demande de participation tardive (late loin request)
LR demande de sortie d'un utilisateur (user leave request)
NACK accusé de réception négatif (negative acknowledgement)
PB sonde (probe)
PBACK accusé de réception de sonde (probe acknowledgment)
RD données de retransmission (retransmission data)
TC confirmation de participation à l'arborescence (tree join confirm)
TCC confirmation de changement d'arborescence (tree change confirm)
TCR demande de changement d'arborescence (tree change request)
TDC confirmation de délégation d'arborescence (tree delegation confirm)
TDR demande de délégation d'arborescence (tree delegation request)
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)
TLC confirmation de sortie d'arborescence (tree leave confirm)
TLR demande de sortie d'arborescence (tree leave request)
TNC confirmation de notification de changement d'arborescence (tree change notification confirm)
TNR demande de notification de changement d'arborescence (tree change notification request)
TRC confirmation de restitution de jeton (token return confirm)
TRR demande de restitution de jeton (token return request)
TSR rapport sur l'état des jetons (token status report)
TSRR demande de rapport sur l'état des jetons (token status report request)
5 Conventions
Dans la présente Recommandation | Norme internationale, les paquets ECTP-5 sont représentés par des mots en
majuscules (par exemple CR pour le paquet de demande de création de connexion) et les paramètres système par des
mots en majuscules et en italique (par exemple TD_PACKET_INT pour l'intervalle entre les paquets de données de test).
6 Aperçu général
Le protocole de transport de communications amélioré (ECTP, enhanced communications transport protocol) est un
protocole de transport visant à prendre en charge les applications multidiffusion Internet. Il fonctionne sur les réseaux
IPv4/IPv6 dotés de la capacité de transmission multidiffusion IP au moyen des protocoles de routage IGMP et IP,
comme l'indique 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
Rec. UIT-T X.608 (02/2007) 3
ISO/CEI 14476-5:2008 (F)
La présente Recommandation | Norme internationale décrit la spécification de protocole de la partie 5 du protocole
ECTP (ECTP-5) en ce qui concerne la connexion multidiffusée n-plex, en vue de la prise en charge du transport de
données multidiffusées entre les participants (utilisateurs du service TS). Dans la connexion multidiffusée n-plex, les
utilisateurs du service TS peuvent envoyer des paquets de données multidiffusées au groupe sur la voie de transmission
des données multidiffusées. Un utilisateur du service TS qui envoie des données multidiffusées dans la connexion
multidiffusée n-plex est un utilisateur expéditeur SU (utilisateur du service TS expéditeur). Tout utilisateur expéditeur
SU doit disposer d'un jeton pour la transmission de données multidiffusées. Autrement dit, l'utilisateur du service TS
qui obtient un jeton auprès du propriétaire de la connexion TC (TCN) est un utilisateur expéditeur SU.
La Figure 2 indique la voie de transport de données multidiffusées dans la connexion multidiffusée n-plex. Comme le
montre la figure, le propriétaire de la connexion TC et l'utilisateur expéditeur SU peuvent transmettre des données
multidiffusées aux autres membres de la session à une adresse IP multidiffusion (de groupe).
TCN
Utilisateur
du service TS
SU
Utilisateur
du service TS
X.608(07)_F02
transmission de données multidiffusées
voie de transmission de données multidiffusées
Figure 2 – Transport de données multidiffusées dans une connexion multidiffusée n-plex
Pour établir une connexion multidiffusée n-plex, le propriétaire de la connexion TCN devrait être activé pour gérer les
informations de session et les jetons.
Si le propriétaire de la connexion TCN est informé d'une liste de participants par une signalisation hors bande avant le
début de la connexion, il devrait lancer une phase de création de connexion en transmettant un paquet CR au groupe. Le
paquet CR contient les informations de connexion, y compris les caractéristiques générales de la connexion. Chaque
utilisateur du service TS qui figure dans la liste de participants devrait répondre au propriétaire de la connexion TCN
par un paquet CC. L'opération de création de connexion s'achève lorsque le propriétaire de la connexion TCN reçoit des
paquets CC de tous les utilisateurs du service TS figurant dans la liste des participants, et la phase de transmission de
données commence. S'il n'y a aucun participant prédéterminé avant le début de la session, le propriétaire de la
connexion TCN lance la phase de transmission de données sans opération de création de connexion.
Au milieu de la phase de transmission de données, les utilisateurs potentiels du service TS devraient se joindre à 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 de la connexion TC un message de demande de participation tardive (JR, late joint request).
En réponse au message JR, le propriétaire de la connexion TC envoie un message de confirmation de participation
tardive (JC, late joint confirm) à l'utilisateur du service TS. Une fois confirmée la participation d'un utilisateur du
service TS à la session, celui-ci devrait se joindre à une arborescence logique en échangeant avec un propriétaire local
(LO) approprié les messages de demande de participation à une arborescence (TJ, tree join request) et de confirmation
de participation à une arborescence (TC, tree join confirm). L'arborescence logique est utilisée pour la protection contre
les erreurs.
Une connexion multidiffusée n-plex crée une arborescence logique à deux couches, qui comprend des arborescences
intra-groupe partagées et des arborescences inter-groupes par source, comme le montre la Figure 3.
4 Rec. UIT-T X.608 (02/2007)
ISO/CEI 14476-5:2008 (F)
Figure 3 – Arborescence à deux couches pour la connexion multidiffusée n-plex
Dans la couche inférieure, chaque entité feuille (LE) d'un groupe local participe à une arborescence logique partagée
dont la racine est un propriétaire local (LO) (arborescence intra-groupe). Dans la couche supérieure, les propriétaires
locaux constituent des arborescences logiques pour chaque utilisateur expéditeur SU (arborescence inter-groupes). Il
convient de noter que l'on obtient l'arborescence de gestion de chaque utilisateur expéditeur SU en associant ces
arborescences inter-groupes et intra-groupe.
Dans une connexion multidiffusée n-plex, les arborescences intra-groupe peuvent être organisées différemment selon le
rôle des entités feuilles (LE), qui est déterminé par l'option de configuration d'arborescence (TCO, tree configuration
option). Une option est que toutes les entités feuilles sont les enfants directs de propriétaires locaux et ne participent pas
au processus de réparation et aux regroupements de paquets ACK. Ainsi, dans cette option, l'arborescence intra-groupe
sera une arborescence d'un niveau, dont la racine est le propriétaire local (LO). L'autre option est que les entités feuilles
sont les enfants d'autres entités feuilles. Dans cette option, les entités feuilles sont chargées d'assurer la fiabilité de leurs
enfants et les arborescences intra-groupe peuvent être des arborescences à plusieurs niveaux. Pour que la prise en
charge de la fiabilité soit efficace, les arborescences intra-groupe à plusieurs niveaux devraient être aussi proches que
possible de l'arborescence de routage multidiffusion sous-jacente. La connexion multidiffusée n-plex applique le
mécanisme d'adaptation d'arborescence logique pour cette option. A cet effet, il est fait usage des suites binaires
d'erreurs des utilisateurs du service TS. Une suite binaire d'erreurs représente l'état de transmission des paquets, lequel
indique la configuration de perte des paquets multidiffusés. Chaque utilisateur du service TS envoie sa suite binaire
d'erreurs à son parent concernant les données multidiffusées à partir du nœud racine de son arborescence intra-groupe
au moyen de messages ACK périodiques. En comparant ses propres suites binaires d'erreurs et ceux de ses enfants, un
nœud décide si chaque enfant est susceptible d'être ou non son enfant effectif dans l'arborescence de routage
multidiffusion sous-jacente. S'il est établi que le nœud enfant n'est pas son enfant effectif, le nœud change
l'arborescence logique en déléguant le nœud enfant à son parent ou à un de ses autres enfants. Après des changements
d'arborescence récurrents, l'arborescence intra-groupe convergera vers une arborescence à plusieurs niveaux qui est plus
proche de l'arborescence de routage multidiffusion sous-jacente.
La protection contre les erreurs sera assurée selon l'arborescence de gestion du protocole ECTP qui est créée ainsi qu'il
est décrit plus haut. Si la perte de paquets est détectée par un écart entre les numéros de séquence des paquets, un nœud
enfant envoie immédiatement un paquet NACK à son parent en mode unidiffusion. Le propriétaire local parent ou
l'utilisateur expéditeur SU qui reçoit le paquet NACK retransmettra le paquet de données (RD) au demandeur en mode
unidiffusion. Chaque enfant crée un paquet ACK selon la fréquence de création de paquets ACK
(ACK_GENERATION_NUM (AGN)).
Dans la transmission de données multidiffusées, le propriétaire de la connexion TC et les utilisateurs SU peuvent
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 utilisateurs du service TS livreront les paquets DT reçus à l'application de couche supérieure
dans l'ordre indiqué par l'utilisateur expéditeur SU ou le propriétaire de la connexion TC.
Pour le transport de données multidiffusées, un utilisateur du service TS de la connexion peut obtenir un jeton auprès du
propriétaire de la connexion TC en envoyant un message TGR. Le propriétaire de la connexion TC répondra alors à
l'utilisateur du service TS par le message TGC qui contient un ID de jeton. En conséquence, le nombre total de jetons de
la connexion est géré par le propriétaire de la connexion TC. L'utilisateur du service TS qui a un jeton est l'utilisateur du
service TS expéditeur (SU). Dans certains cas, le propriétaire de la connexion TC peut d'abord demander à un utilisateur
Rec. UIT-T X.608 (02/2007) 5
ISO/CEI 14476-5:2008 (F)
du service TS d'être un utilisateur expéditeur SU en envoyant le message TGR à l'utilisateur expéditeur SU concerné
(cession de jeton).
Une fois la transmission de données multidiffusées terminée, l'utilisateur expéditeur SU restituera le jeton au
propriétaire de la connexion TC en envoyant un message TRR. Le propriétaire de la connexion TC répondra à
l'utilisateur expéditeur SU par un message TRC. Dans certains cas, le propriétaire de la connexion TC demande d'abord
à l'utilisateur expéditeur SU de restituer le jeton (retrait de jeton). Le propriétaire de la connexion TC annonce au
groupe la situation globale des ID de jetons valides dans la connexion en envoyant les paquets TSR.
Le propriétaire de la connexion TC gère la connexion en ce qui concerne la sortie des utilisateurs. Dans cette opération,
un utilisateur du service TS participant peut quitter la connexion en envoyant un message LR au parent. Dans certains
cas, le propriétaire de la connexion TC peut obliger un utilisateur du service TS à quitter la connexion en envoyant le
message LR (éjection des éléments perturbateurs).
Le propriétaire de la connexion TC peut mettre fin à la connexion n-plex en envoyant un message CT au groupe.
7 Considérations
7.1 Participants
Tous les participants à une connexion multidiffusée n-plex sont des utilisateurs du service TS, l'un d'entre eux étant le
propriétaire de la connexion TC (TCN).
Propriétaire de la connexion TC (TCN, TC-owner):
Une connexion multidiffusée n-plex a un seul propriétaire TCN, qui est chargé de la gestion de la connexion,
notamment de la création et de la fin de la connexion, de la mise à jour de la connexion et de la gestion des
jetons.
Ainsi, dans les applications de téléconférence, le propriétaire de la connexion TC peut agir en qualité de
"serveur de conférence", serveur qui peut être utilisé pour la gestion de la conférence sans envoi de données
multidiffusées. Dans l'exemple des "jeux en ligne à multiples utilisateurs", le propriétaire de la connexion TC
peut agir en tant que "serveur de gestion de jeux".
Utilisateur du service TS (utilisateur du service de transport):
Une connexion multidiffusée n-plex comprend un ou plusieurs utilisateurs du service TS, chacun d'entre eux
envoyant et recevant des données multidiffusées dans la connexion.
Un utilisateur du service TS peut devenir un propriétaire local (LO) ou une entité feuille (LE) selon le rôle qu'il assume.
Propriétaire local (LO, local owner):
Un propriétaire local est un nœud représentatif d'un groupe local désigné de manière statique. Il est chargé de
mettre à jour une arborescence intra-groupe du groupe et les arborescences de gestion pour tous les
utilisateurs SU de son groupe local. Chaque propriétaire local est aussi connecté aux autres propriétaires
locaux au moyen d'arborescences inter-groupes. Périodiquement, il crée aussi un trafic d'essai pour
l'adaptation des arborescences logiques.
Entité feuille (LE, leaf entity):
Une entité feuille est un membre d'un groupe local dont les représentants sont un propriétaire local (LO). Elle
devrait participer à une arborescence intra-groupe du groupe et elle est chargée d'échanger des paquets de
gestion avec les entités feuilles parents ou enfants le long de l'arborescence de gestion.
Un utilisateur du service TS peut devenir un utilisateur expéditeur SU lorsqu'il obtient un jeton du propriétaire de la
connexion TCN.
Utilisateur expéditeur du service TS (SU, sending TS-user):
Un utilisateur expéditeur SU est un utilisateur du service TS qui peut envoyer des données multidiffusées au
groupe. Dans une connexion multidiffusée n-plex, un utilisateur du service TS devient un utilisateur
expéditeur SU lorsqu'il a un jeton et qu'il peut donc transmettre des données multidiffusées au groupe.
7.2 Voie de transmission de données et adressage
Dans une connexion multidiffusée n-plex, l'utilisateur expéditeur SU ou le propriétaire de la connexion TC peut envoyer
des paquets de données multidiffusées aux membres de la session comme l'indique la Figure 4.
6 Rec. UIT-T X.608 (02/2007)
ISO/CEI 14476-5:2008 (F)
SU, TCN
Paquets de données multidiffusées
Source Destination
Adresse IP de groupe
Adresse IP locale (SU, TO)
Port de groupe
Utilisateur
Utilisateur
du service TS
du service TS
X.608(07)_F04
Figure 4 – Adressage des données multidiffusées dans une connexion multidiffusée n-plex
Dans une connexion multidiffusée n-plex, les paquets de données multidiffusées (DT) utilisent l'adresse IP
multidiffusion et le numéro de port de groupe comme adresse de destination. L'adresse source des paquets de données
multidiffusées IP est l'adresse IP de l'expéditeur du paquet. Par contre, les paquets de données de retransmission (RD)
envoyés en réponse aux délégations de réparations (NACK) sont livrés par le propriétaire local ou l'utilisateur
expéditeur SU sur la voie de gestion unidiffusion, l'adresse IP du demandeur de la réparation étant la destination.
7.3 Voie et arborescence de gestion
Dans une connexion multidiffusée n-plex, des voies de gestion sont consacrées aux reprises après incident. Tous les
membres participent à une ou plusieurs arborescences de gestion. Celles-ci servent de voies de gestion pour l'échange
de messages de gestion entre participants. Un nœud parent agit en tant qu'agent pour aider les nœuds enfants dans les
reprises après perte de paquets. Il regroupe aussi les informations d'accusé de réception provenant des nœuds
descendants. Tous les paquets de gestion tels que les paquets RD, NACK et ACK sont transmis au moyen de la voie de
gestion unidiffusion.
Une connexion multidiffusée n-plex est divisée en plusieurs groupes locaux de participants aux fins de la protection
contre les erreurs. Selon cette approche de groupe, les participants créent et mettent à jour des arborescences de gestion
le long desquelles tous les paquets de protection contre les erreurs sont échangés. Les arborescences de gestion sont
construites à partir de deux couches d'arborescences logiques. Dans la couche inférieure, les membres d'un groupe local
participent à une arborescence logique partagée dont la racine est un propriétaire local (LO) (arborescence
intra-groupe). Dans la couche supérieure, les propriétaires locaux des groupes constituent des arborescences logiques
par source (arborescence inter-groupes). Autrement dit, chaque entité feuille (LE) participe à un groupe local et elle se
greffe sur l'arborescence logique du groupe dont la racine est un propriétaire local (LO), en tant qu'enfant (ou
descendant) du propriétaire local. Chaque propriétaire local se greffe sur l'arborescence logique des propriétaires
locaux, dont la racine est le propriétaire local du groupe auquel l'utilisateur expéditeur SU appartient. Une arborescence
de gestion pour chaque source est créée en connectant les arborescences inter-groupes et les arborescences intra-groupe.
Autant d'arborescences inter-groupes sont créées et mises à jour qu'il est nécessaire. Toute arborescence inter-groupes
plus importante dont la racine est un propriétaire local qui n'a pas d'utilisateur expéditeur SU comme enfant devrait être
supprimée.
Les arborescences intra-groupe peuvent devenir des arborescences à plusieurs niveaux qui prennent en compte les
chemins de routage multidiffusion effectifs grâce au mécanisme d'adaptation des arborescences logiques décrit au § 7.5.
En traversant les arborescences logiques à partir d'un utilisateur expéditeur SU, on peut obtenir une arborescence dont la
racine est l'utilisateur expéditeur SU et qui est l'arborescence de gestion de cet utilisateur.
Si un utilisateur expéditeur SU appartient à un autre groupe local, une partie de l'arborescence de gestion créée pour le
groupe local existant est l'arborescence intra-groupe du groupe. Les arborescences de gestion des utilisateurs SU
appartenant au même groupe local sont légèrement différentes de l'arborescence intra-groupe, car les nœuds
intermédiaires entre le propriétaire local et l'utilisateur expéditeur SU ont inversé la relation parent-enfant.
Si les arborescences logiques des participants sont construites selon la Figure 5, l'arborescence de gestion de la source
SU1 le sera comme l'indique la Figure 6.
Rec. UIT-T X.608 (02/2007) 7
ISO/CEI 14476-5:2008 (F)
Figure 5 – Deux couches d'arborescences logiques
Figure 6 – Arborescence de gestion avec l'expéditeur SU1
8 Rec. UIT-T X.608 (02/2007)
ISO/CEI 14476-5:2008 (F)
De même, la Figure 7 représente l'arborescence de gestion dont la source est SU2.
SU2
LE7
LO2
LE6 LO1 LO3
LE2 SU1 LE4 LE5
LE3 LE1
X.608(07)_F07
Figure 7 – Arborescence de gestion avec l'expéditeur SU2
Les arborescences de gestion sont mises à jour au moyen des informations obtenues grâce à l'échange de paquets
NACK et ACK. Le parent peut détecter la défaillance d'un enfant en comparant son numéro de séquence le plus bas
(LSN) à celui reçu de l'enfant. Les enfants peuvent détecter la défaillance de leur parent en l'absence de réponse du
parent à plusieurs demandes de réparation consécutives. L'enfant trouve ensuite un autre parent en contactant le
propriétaire local (LO).
7.4 Jetons
Dans une connexion multidiffusée n-plex, un jeton représente le droit d'un utilisateur du service TS d'envoyer des
données multidiffusées au propriétaire de la connexion TC. Avant de transmettre des données, chaque utilisateur du
service TS doit obtenir un jeton auprès du propriétaire de la connexion TC, selon les procédures de gestion de jetons
utilisées dans la connexion multidiffusée n-plex. Ainsi, le propriétaire de la connexion TC peut autoriser un utilisateur
du service TS à devenir un expéditeur, de sorte que les utilisateurs du service TS peuvent effectivement filtrer et écarter
les données multidiffusées envoyées par des utilisateurs non autorisés. Cela étant, il convient de noter que l'utilisation
de jetons n'offre aucune protection pour la multidiffusion IP.
Chaque jeton est représenté par un entier non négatif de 1 octet. Ce numéro de jeton (ou ID de jeton) sera attribué par le
propriétaire de la connexion TC lorsqu'un utilisateur du service TS demande un jeton dans la connexion. L'ID de jeton a
une valeur comprise entre 1 et 255, la valeur '0' étant réservée à l'usage du propriétaire de la connexion TC. Du côté du
destinataire, l'ID de jeton peut servir à déterminer les entités qui peuvent envoyer des données multidiffusées.
7.5 Adaptation des arborescences logiques
Dans une connexion multidiffusée n-plex, les arborescences intra-groupe peuvent devenir des arborescences à plusieurs
niveaux proches des arborescences de routage multidiffusion sous-jacentes lorsque l'option de configuration
d'arborescence TCO a la valeur '10'. La comparaison des configurations de perte permet d'estimer les arborescences de
routage multidiffusion sous-jacentes. L'estimation est réalisable étant donné que si une perte survient à un nœud parent
d'une arborescence de routage multidiffusion, tous ses enfants subissent la même perte. La racine d'une arborescence
intra-groupe ne change pas suite au processus d'adaptation des arborescences logiques.
Dans ce processus, chaque destinataire d'une session multidiffusion tient à jour l'état de transmission des paquets,
appelé suite binaire d'erreurs, qui indique la configuration de perte des paquets multidiffusés. Une telle suite binaire
comprend deux parties, le numéro de séquence (Ns) et la suite binaire elle-même (B). Ns est le numéro de séquence du
premier paquet d'une séquence de paquets représentés dans la suite binaire. Un bit de B indique l'état de réception du
paquet correspondant, '1' signifiant que les paquets ont pu être transmis à un destinataire sans reprise après incident
Rec. UIT-T X.608 (02/2007) 9
ISO/CEI 14476-5:2008 (F)
et '0' signifiant une défaillance. La suite binaire comprend les configurations de perte des paquets multidiffusés. Ainsi,
si Ns = 5 et B = 11010, le destinataire a bien reçu les paquets 5, 6 et 8. Si les paquets 7 et 9 ont été récupérés grâce aux
retransmissions, ces bits sont à '0'. Chaque destinataire envoie périodiquement la suite binaire d'erreurs à son parent
dans l'arborescence. Si une arborescence logique correspond à une arborescence de routage multidiffusion et si un bit de
la suite binaire à un nœud a la valeur '1', le bit correspondant de la suite binaire de son parent sera probablement à '1'. Il
convient de noter que tous les éléments de la suite binaire d'erreurs d'une source ont toujours la valeur '1'.
Chaque nœud qui a des nœuds enfants compare sa propre suite binaire d'erreurs et celle de ses enfants pour vérifier si la
relation entre lui et ses enfants correspond étroitement à l'arborescence de routage multidiffusion sous-jacente. Un nœud
parent peut déduire que certains nœuds enfants doivent changer d'emplacement dans l'arborescence logique. Le nœud
enfant est un enfant d'un autre nœud enfant, sinon il n'est pas un descendant du nœud parent.
Par exemple, la Figure 8 donne un exemple d'arborescence de routage multidiffusion et de suite binaire d'erreurs de
chaque nœud.
Figure 8 – Exemple d'arborescence de routage multidiffusion
On trouvera aux Figures 9 et 10 une description succincte de la façon dont une arborescence logique proche d'une
arborescence de routage multidiffusion est construite selon les informations données par la suite binaire d'erreurs.
Premièrement, on suppose qu'un propriétaire local racine est un serveur déployé de façon stratégique qui est
habituellement situé près du point de sortie d'un fournisseur de services Internet. Les carrés représentent les routeurs et
les numéros figurant au-dessous des nœuds sont les suites binaires d'erreurs de chaque nœud.
Figure 9 – Adaptation des arborescences logiques (LE2 adopte LE3)
La partie gauche de la Figure 9 représente une arborescence intra-groupe de nœuds à un niveau initiale, qui est
reproduite à la Figure 8. Lorsque le propriétaire local prend connaissance des suites binaires d'erreurs de ses enfants, il
découvre que l'entité LE3 est probablement un enfant ou un descendant de l'entité LE2 puisqu'un ensemble de paquets
reçus de l'entité LE3 est un sous-ensemble de celui de l'entité LE2. Ainsi, il délègue l'entité LE3 à l'entité LE2 en
envoyant un message TDR (demande de délégation d'arborescence). A réception du message, l'entité LE2 estime que
l'entité LE3 est son enfant et envoie un message TCR (demande de changement d'arborescence) à l'entité LE3. À
réception du messag
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.