ISO/IEC 16512-2:2008
(Main)Information technology - Relayed multicast protocol: Specification for simplex group applications - Part 2:
Information technology - Relayed multicast protocol: Specification for simplex group applications - Part 2:
ISO/IEC 16512-2:2008 specifies the Relayed Multicast Protocol (RMCP) Part 2 (RMCP‑2), which is a control protocol that realizes and supports the relayed multicast data transport scheme for simplex group applications. ISO/IEC 16512-2:2008 describes RMCP topology, service scenarios, and the definition of the RMCP framework without any modification. The RMCP topology and service scenario specified in ISO/IEC 16512-2:2008 follow the definition of the RMCP framework without any modification. Among the group communication services specified in the RMCP framework, the RMCP for simplex group communications specified in ISO/IEC 16512-2:2008 focuses exclusively on one-to-many group services, such as Internet live broadcasting services and file dissemination services.
Technologies de l'information — Protocole de multidiffusion relayé: Spécification relative aux applications de groupe simplex — Partie 2:
L'ISO/CEI 16512-2:2008 spécifie le protocole de multidiffusion relayé (RMCP), Partie 2 (RMCP-2), qui est un protocole de commande qui réalise et supporte le canevas de transport de données de multidiffusion relayé pour les applications de groupe simplex. L'ISO/CEI 16512-2:2008 décrit la topologie RMCP, les scénarios de service et la définition du cadre RMCP sans aucune modification. La topologie RMCP et les scénarios de service spécifiés dans l'ISO 16512-2:2008 suivent la définition du cadre RMCP sans aucune modification. Parmi les services de communications de groupe spécifiés dans le cadre RMCP, le RMCP pour les communications de groupe simplex spécifiées dans l'ISO/CEI 16512-2:2008 se concentre exclusivement sur les services de groupe point à multipoint, tels que les services de diffusion générale en ligne et de diffusion de fichiers sur Internet.
General Information
Relations
Frequently Asked Questions
ISO/IEC 16512-2:2008 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information technology - Relayed multicast protocol: Specification for simplex group applications - Part 2:". This standard covers: ISO/IEC 16512-2:2008 specifies the Relayed Multicast Protocol (RMCP) Part 2 (RMCP‑2), which is a control protocol that realizes and supports the relayed multicast data transport scheme for simplex group applications. ISO/IEC 16512-2:2008 describes RMCP topology, service scenarios, and the definition of the RMCP framework without any modification. The RMCP topology and service scenario specified in ISO/IEC 16512-2:2008 follow the definition of the RMCP framework without any modification. Among the group communication services specified in the RMCP framework, the RMCP for simplex group communications specified in ISO/IEC 16512-2:2008 focuses exclusively on one-to-many group services, such as Internet live broadcasting services and file dissemination services.
ISO/IEC 16512-2:2008 specifies the Relayed Multicast Protocol (RMCP) Part 2 (RMCP‑2), which is a control protocol that realizes and supports the relayed multicast data transport scheme for simplex group applications. ISO/IEC 16512-2:2008 describes RMCP topology, service scenarios, and the definition of the RMCP framework without any modification. The RMCP topology and service scenario specified in ISO/IEC 16512-2:2008 follow the definition of the RMCP framework without any modification. Among the group communication services specified in the RMCP framework, the RMCP for simplex group communications specified in ISO/IEC 16512-2:2008 focuses exclusively on one-to-many group services, such as Internet live broadcasting services and file dissemination services.
ISO/IEC 16512-2:2008 is classified under the following ICS (International Classification for Standards) categories: 35.100.70 - Application layer. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO/IEC 16512-2:2008 has the following relationships with other standards: It is inter standard links to ISO/IEC 16512-2:2008/FDAmd 1, ISO/IEC 16512-2:2008/FDAmd 2, ISO/IEC 16512-2:2011; is excused to ISO/IEC 16512-2:2008/FDAmd 1. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO/IEC 16512-2:2008 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 16512-2
First edition
2008-05-15
Information technology — Relayed
multicast protocol: Specification for
simplex group applications
Technologies de l'information — Protocole de multidiffusion relayé:
Spécifications pour applications de groupe unidirectionnel
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 Normative references . 1
3 Definitions . 1
4 Abbreviations . 2
5 Overview. 2
5.1 RMCP-2 entities . 3
5.2 RMCP-2 protocol block . 4
5.3 Simplex delivery model of RMCP-2 . 5
5.4 Types of RMCP-2 messages. 5
6 Protocol operation . 6
6.1 SM's operation. 6
6.2 MA's operation . 8
7 RMCP-2 message format . 18
7.1 Common format of RMCP-2 message. 18
7.2 Control data format . 20
7.3 Messages. 21
8 Parameters . 44
8.1 Data forwarding profile . 44
8.2 Parameters used in RMCP-2. 45
8.3 Encoding rules to represent values used in RMCP-2. 46
Annex A – Tree configuration algorithm . 49
A.1 Bootstrapping rule. 49
A.2 Neighbour discovering rule . 50
A.3 HMA selection rule . 51
A.4 CMA acceptance rule. 51
A.5 Parent decision rule . 52
A.6 Tree improvement rule. 53
A.7 PMA's kicking-out rule . 53
Annex B – Real-time data delivery scheme . 54
B.1 Overview. 54
B.2 IP-IP tunnel mechanism for RMCP-2 real-time data delivery. 54
Annex C – Reliable data delivery scheme . 56
C.1 Overview. 56
C.2 Operation . 56
C.3 Data encapsulation format. 58
C.4 Data profile. 58
Annex D – RMCP-2 API. 59
D.1 Overview. 59
D.2 RMCP-2 API functions . 60
© 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 16512-2 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.603.1 (02/2007).
ISO/IEC 16512 consists of the following parts, under the general title Information technology — Relayed
multicast protocol:
⎯ Part 1: Framework
⎯ Part 2: Specification for simplex group applications
⎯ Part 3: Specification for N-plex group applications
iv © ISO/IEC 2008 – All rights reserved
Introduction
Relayed MultiCast Protocol Part 2 (RMCP-2) is an application-layer relayed multicast protocol for simplex group
applications. RMCP-2 can construct an optimized and robust one-to-many relayed multicast delivery path over a unicast
network with the help of RMCP entities defined by ITU-T Rec. X.603 | ISO/IEC 16512-1.
An RMCP-2 session consists of one SM and one or more MAs; SM initiates and terminates RMCP-2 session and
manages RMCP-2 session and participated MAs; MA configures an RMCP-2 tree to deliver group data by exchanging a
series of RMCP-2 control messages.
Along the relayed multicast delivery path, several types of data delivery channels can be constructed according to the
requirement of application services.
© ISO/IEC 2008 – All rights reserved v
INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
Information technology – Relayed multicast protocol:
Specification for simplex group applications
1 Scope
This Recommendation | International Standard describes the Relayed MultiCast Protocol (RMCP) Part 2, an
application-layer protocol, which constructs multicast tree for data delivery from a sender to multiple receivers over
Internet where IP multicast is not fully deployed. The specified relayed multicast protocol consists of multicast agent
and session manager. This Recommendation | International Standard specifies a series of functions and procedures of
multicast agent to construct one-to-many relayed data path and to relay simplex data. It also specifies the operations of
session manager to manage multicast sessions. This protocol can be used for applications that require one-to-many data
delivery services, such as multimedia streaming service, file dissemination service, etc.
2 Normative references
The following Recommendations and International Standards contain provisions which, through reference in this text,
constitute provisions of this Recommendation | International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
Recommendation | International Standard are encouraged to investigate the possibility of applying the most recent
edition of the Recommendations and Standards listed below. Members of IEC and ISO maintain registers of currently
valid International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of currently
valid ITU-T Recommendations.
– ITU-T Recommendation X.601 (2000), Multi-peer communications framework.
– ITU-T Recommendation X.603 (2004) | ISO/IEC 16512-1:2005, Information technology – Relayed
multicast protocol: Framework.
– ITU-T Recommendation X.605 (1998) | ISO/IEC 13252:1999, Information technology – Enhanced
communications transport service definition.
– ITU-T Recommendation X.606 (2001) | ISO/IEC 14476-1:2002, Information technology – Enhanced
communications transport protocol: Specification of simplex multicast transport.
– ITU-T Recommendation X.606.1 (2003) | ISO/IEC 14476-2:2003, Information technology – Enhanced
communications transport protocol: Specification of QoS management for simplex multicast transport.
3 Definitions
For the purposes of this Recommendation | International Standard, the following definitions apply:
3.1 multicast: A data delivery scheme where the same data unit is transmitted from a single source to multiple
destinations over a single invocation of service.
3.2 IP multicast: A multicast scheme in an IP network supported by multiple multicast-enabled IP routers.
3.3 relayed multicast: A multicast data delivery scheme that can be used in unicast environments; the scheme is
based on intermediate multicast agents that relay multicast data from a media server to media players over a tree
hierarchy.
3.4 relayed multicast protocol (RMCP): A protocol that supports and manages the relayed multicast data
transport.
3.5 RMCP-2 session: An MA set that uses the RMCP to configure the data delivery path.
3.6 multicast agent (MA): An intermediate data transport entity used to relay the multicast application data.
Depending on the deployment, an MA may be installed in the same system as a receiving client.
3.7 sender multicast agent (SMA): The MA attached to the sender in the same system or local network.
3.8 receiver multicast agent (RMA): The MA attached to the receiver in the same system or local network.
3.9 head multicast agent (HMA): A representative of the MA inside a local network where the multicast is
enabled.
ITU-T Rec. X.603.1 (02/2007) 1
3.10 session manager (SM): An RMCP entity that is responsible for the overall RMCP operations; it may be
located in the same system as the media server or located separately from the media server.
3.11 parent multicast agent (PMA): The next upstream MA in the RMCP-2 data delivery path.
3.12 child multicast agent (CMA): The next downstream MA in the RMCP-2 data delivery path.
4 Abbreviations
For the purposes of this Recommendation | International Standard, the following abbreviations apply:
AUTH Authentication
CMA Child Multicast Agent
DMA Dedicated Multicast Agent
HANNOUNCE HMA announce message
HB Heartbeat message
HLEAVE HMA leave message
HMA Head Multicast Agent
HSOLICIT HMA solicit message
IP-IP IP in IP
LEAVANS Leave answer message
LEAVREQ Leave request message
MA Multicast Agent
MAID Multicast Agent Identification
PMA Parent Multicast Agent
PPROBANS Parent probe answer message
PPROBREQ Parent probe request message
RELANS Relay answer message
RELREQ Relay request message
RMA Receiver Multicast Agent
RMCP Relayed MultiCast Protocol
SDP Session Description Protocol
SID RMCP-2 Session Identification
SMA Sender Multicast Agent
STANS Status report answer message
STCOLANS Status report collect answer message
STCOLREQ Status report collect request message
STREQ Status report request message
SUBSANS Subscription answer message
SUBSREQ Subscription request message
T/TCP TCP extensions to Transactions
TCP Transmission Control Protocol
TERMANS Ter mination answer message
TERMREQ Termination request message
UDP User Datagram Protocol
5 Overview
The RMCP-2 is an application-level protocol that uses multicast agents (MAs) and a session manager (SM) to support
and manage a relayed multicast data transport over a unicast-based Internet. With the help of the SM, the RMCP-2
2 ITU-T Rec. X.603.1 (02/2007)
begins by constructing a relayed multicast control tree that consists of MAs. Consequently with the preconfigured
control tree, each MA connects appropriate data channels with each other.
The RMCP-2 entities for a simplex delivery model are described in clause 5.1.
5.1 RMCP-2 entities
The RMCP-2 entities are the same as those described in RMCP Part 1. As shown in Figure 1, each RMCP-2 session
constructs a relayed multicast data delivery model with the following entities:
a) one SM;
b) one sender multicast agent (SMA) per sender application;
c) one or more receiver multicast agents (RMAs);
d) one or more sending or receiving group applications.
An SM, which can handle one or multiple sessions simultaneously, can be implemented separately or as a part of other
entities in an RMCP-2 session.
Sending
app.
SMA
Session
manager
RMAs
RMA RMA RMA
X.603.1(07)_F01
Receiving Receiving Receiving
app. app. app.
Figure 1 – RMCP-2 service topology
An SM can provide the following functionalities:
a) session initialization;
b) session release;
c) session membership management;
d) session status monitoring.
An MA, which refers to both the SMA and the RMA, constructs a relayed multicast delivery path from one sender to
many receivers and then forwards data along the constructed path, can provide the following functionalities:
a) session initialization;
b) session join;
c) session leave;
d) session maintenance;
e) session status reporting;
f) application data relay.
ITU-T Rec. X.603.1 (02/2007) 3
5.2 RMCP-2 protocol block
An SM should exchange control messages with other MAs to control and manage RMCP-2 session. The control
messages used by SM should be delivered reliably; otherwise, RMCP-2 session becomes unrecoverable. Figure 2 shows
a protocol stack of an SM.
Control module of RMCP-2 SM
TCP
IP (unicast)
Figure 2 – Protocol stack of SM
An MA, which refers to both the SMA and the RMA, constructs a relayed multicast delivery path from one sender to
many receivers and then forwards data along the constructed path. An MA consists of an RMCP-2 control module and a
data transport module. The control module establishes the relayed data delivery path. The data transport module sets up
a data channel along the path constructed by the control module and then relays data through the channel.
The MA's control module configures the control tree from the SMA to every leaf MAs by exchanging control messages
with other MAs. Also the control module is used for session control and management by SM. Figure 3 shows the
protocol stack of an MA's control module.
Control module of RMCP-2 MA
TCP
IP (unicast)
Figure 3 – Protocol stack of MA's control module
The MA's data module relays application data along the tree configured by the control module. Figure 4 shows the
protocol stack of RMCP-2 data module. Any kind of transport mechanism can be inserted, if needed, because RMCP-2
imposes no restrictions on the type of application data to be delivered.
To ensure that RMCP-2 can adopt any kind of data transport mechanism, two MAs (namely, the parent multicast agent
(PMA) and the child multicast agent (CMA)) construct a data delivery path on the control tree by exchanging the data
profiles described later.
Data module of RMCP-2 MA
TCP, UDP, IP-IP, SCTP, etc.
IP (unicast or multicast)
Figure 4 – Protocol stack of RMCP-2 data module
4 ITU-T Rec. X.603.1 (02/2007)
The topologies of the two paths for control and data delivery are usually the same, because a data delivery path is
constructed along the RMCP-2 control tree. Along the data delivery path, the application data from the SMA can be
delivered to each leaf MAs. For more information, Annexes B and C present two feasible real-time and reliable data
delivery schemes.
5.3 Simplex delivery model of RMCP-2
The target services of RMCP-2 are simplex broadcasting services, such as Internet live TV and software dissemination.
In those service models, building an optimal data delivery path from a sender to multiple receivers is important.
RMCP-2 can support a simplex data delivery model by using the MA's control and data module.
The data delivery path that RMCP-2 considers is a per-source relayed multicast tree. Along the per-source relayed
multicast path, a unidirectional real-time or reliable data channel can be constructed. Figure 5 shows one of the
possible relayed multicast trees configured by RMCP-2 for simplex real-time or reliable applications.
Sending
app.
Simplex relayed
multicast network
SMA
Reliable | Real-time
unicast
and unidirectional
RMA RMA
transport connection
Reliable | Real-time
multicast
and unidirectional
Receiving Receiving Receiving
transport connection
app. app. app.
X.603.1(07)_F05
Figure 5 – Relayed multicast tree configured by RMCP-2
5.4 Types of RMCP-2 messages
To construct and maintain a relayed multicast tree, several control messages are exchanged between RMCP-2 peers in a
request-and-answer manner. Table 1 lists the RMCP-2 control messages according to the appropriate functions.
Table 1 – RMCP-2 messages
Messages Descriptions RMCP operations
SUBSREQ Subscription request
Session initialization
SUBSANS Subscription answer
PPROBREQ Parent probe request
MAP discovery
PPROBANS Parent probe answer
HSOLICIT HMA solicit
HANNOUNCE HMA announce HMA election
HLEAVE HMA leave
RELREQ Relay request
Data delivery
RELANS Relay answer
STREQ Status report request
STANS Status report answer
Session monitoring
STCOLREQ Status collect request
STCOLANS Status collect answer
ITU-T Rec. X.603.1 (02/2007) 5
Table 1 – RMCP-2 messages
Messages Descriptions RMCP operations
LEAVREQ Leave request
Session leave
LEAVANS Leave answer
HB Heartbeat Session heartbeat
TERMREQ Termination request
Session termination
TERMANS Termination answer
6 Protocol operation
This clause describes the RMCP-2 protocol functions and their operations in details. All the components described in
this clause follow the definitions of ITU-T Rec. X.603 | ISO/IEC 16512-1.
6.1 SM's operation
6.1.1 Session initiation
To make the SM create a new session, a content provider (CP) should provide a session profile, which includes details
to create a session such as the session name, media characteristics, and the group address. To distinguish the sessions
from each other, the SM creates a globally unique session identification (SID). After a successful session creation, the
SM returns the SID to the CP. The CPs may announce the session creation by using a web server or email. But the way
of session announcement is out of scope this Specification.
After the successful session creation, the SM waits for a subscription request from the MAs. When the SM receives a
subscription request from an MA, the SM decides whether to accept the subscription request.
6.1.2 Admission control
On receiving MA's subscription request, firstly the SM checks the SID in the request message, and then determines
whether the request is acceptable according to the session policy. RMCP-2 session can be operated privately as well as
publicly with some extra information such as system information and authentication information.
When the SID in the MA's SUBSREQ is valid, then the SM checks proposed MAID and proposed data profile. If the
MAID proposed by MA has null or duplicated value, then the SM proposes a unique one; otherwise, the proposed
MAID will be used during the session. If the proposed data profile cannot be supported, the SM should reject the
request with a reason. Otherwise, the SM can negotiate for the most effective data profile and sends back with the
negotiated one.
When the MA's SUBSREQ is granted, then the SM responds with a confirmed MAID, NL and session dependent
information.
To kick out a specific MA, the SM starts the discard procedure by sending a leave request (LEAVREQ) with a reason
code Kicked-Out (KO) and then updates its session member list. Upon receiving SM's LEAVREQ message, MA leaves
the session promptly. Figure 6 illustrates the procedure, where the SM sends a LEAVREQ message with the reason
code KO and then the MA B leaves the session with notifying its PMA and CMAs of the expulsion.
SM MA A MA B MA C
LEAVREQ (You are KO)
LEAVANS (You are KO)
LEAVREQ (I am KO) LEAVREQ (I am KO)
LEAVANS (I am KO) LEAVANS (I am KO)
X.603.1(07)_F06
Figure 6 – When MA is kicked out by SM
6 ITU-T Rec. X.603.1 (02/2007)
6.1.3 Session monitoring
The SM can fetch status information of a specific MA by exchanging a status request and answer messages with any
specific MA. Upon receiving the status request message, the MA responds with a status answer message that contains
the requested information. Figure 7 shows how the SM monitors a specific MA.
SM SMA MA A MA B
STREQ
STANS
RP
timer
X.603.1(07)_F07
Figure 7 – Tree monitoring – Status report
SM can also collect status information of an entire or a part of a session. In this case, the SM sends a status collect
request message to the top MA of the part. Upon receiving the status collect request message, the MA should send a
status answer back to the SM with appropriate information on the MA and its children. When the session size is large,
the use of this mechanism for the entire session may cause overloading the network and system resources. To limit the
scope of the monitoring, the status collect message should contain an option for the depth.
6.1.4 Session termination
The SM's ongoing session may terminate due to one of the following two reasons:
1) administrative request; and
2) SMA's leave.
Figure 8 shows the SM's session termination procedure.
SM SMA MA A MA B
TERMREQ
TERMANS TERMREQ
TERMANS
TERMREQ
TERMANS
X.603.1(07)_F08
Figure 8 – Session termination issued by SM
Because a RMCP-2 session can continue only when the SMA is alive, the SMA must notify the SM when it leaves.
Having been notified SMA's leave, the SM should terminate the session promptly. The session termination caused by
SMA's leave is described in 6.2.4.4.
ITU-T Rec. X.603.1 (02/2007) 7
6.2 MA's operation
6.2.1 Session subscription
Subscription is the first stage for an MA to be enrolled in a RMCP-2 session. Each MA must subscribe to the session by
sending a subscription request (SUBSREQ) to the SM. Note that the SMA must have finished its subscription before the
other MAs and it should act as a root node in the tree hierarchy. At this stage, each MA needs to know details of the
session profile, such as the address of the SM and the policy.
Figure 9 shows the procedure of RMCP-2 session subscription procedure. After SMA's successful subscription,
RMCP-2 session can be initiated.
SM SMA MA A MA B
SUBSREQ
SUBSANS
X.603.1(07)_F09
Figure 9 – SMA's subscription
Figure 10 shows the procedure of an MA subscription (for MA A and MA B). To subscribe an RMCP-2 session, each
MA sends a SUBSREQ to the SM. Upon receiving SUBSREQ from the MA, the SM decides whether to accept the
subscription request. If the request is accepted, the SM responds with a SUBSANS and bootstrapping information such
as an NL. Otherwise, it responds with a SUBSANS with appropriate error reason code.
After receiving a successful SUBSANS from SM, the MAs (MA A and MA B) can complete the subscription phase.
SM SMA MA A MA B
SUBSREQ
SUBSANS
SUBSREQ
SUBSANS
X.603.1(07)_F10
Figure 10 – MA's subscription
6.2.2 Map discovery
Since all MAs are logically interconnected, it would be difficult for a MA to know the entire network condition.
However, by using map discovery procedures, each MA can explore the other MAs in the RMCP-2 network and
measure the distance between itself and the other MAs. The map discovery mechanism consists of two steps. One is
used in the multicast-enabled area, such as subnet LAN, and the other is used in the multicast-disabled area such as
WAN.
6.2.2.1 Inside multicast-enabled area
It is desirable to assign the nearest node to its PMA. The network distance in RMCP-2 depends on the delay jitter, the
hop count and the bandwidth.
Normally, an MA in the same network is closer than other MAs. Each MA looks for a candidate PMA in its local
network by multicasting a head multicast agent solicit (HSOLICIT) to a specific pre-assigned address (aka, broadcast)
at the beginning. If there is no answer, the MA becomes the HMA, which is a representative of the MA in the multicast-
enabled network.
Once an MA becomes a HMA, the HMA announces its existence to the multicast-enabled network by sending periodic
HANNOUNCE messages. The HMA sends a HANNOUNCE promptly on receiving HSOLICIT from the multicast-
enabled area.
8 ITU-T Rec. X.603.1 (02/2007)
Upon receiving the HANNOUNCE from the HMA, each MA considers that a HMA already exists in the same network
and then assumes the HMA as its primary PMA candidate. Figure 11 shows the HMA selection procedure.
MA A MA B MA C
HeadMA
HSOLICIT HSOLICIT
H_ANNOUNCE.time
HANNOUNCE
H_ANNOUNCE.time
HANNOUNCE
X.603.1(07)_F11
Figure 11 – HMA Solicit and its announcement
Figure 12 shows how an MA becomes a HMA. If there is no HANNOUNCE for a certain time
(H_SOLICIT.time × N_SOLICIT), an MA becomes a new HMA and broadcasts a periodic HANNOUNCE every
H_ANNOUNCE.time to the multicast-enabled area.
HeadMA MA A MA B MA C
HSOLICIT
H_SOLICIT.time
HSOLICIT
H_SOLICIT.time
HANNOUNCE
H_ANNOUNCE.time
HANNOUNCE
X.603.1(07)_F12
Figure 12 – An MA becomes a new HeadMA
Figure 13 shows how a HMA resumes. Once an MA becomes a HMA, it broadcasts a HANNOUNCE to the
multicast-enabled network every H_ANNOUNCE.time.
HeadMA MA A MA B MA C
HANNOUNCE
H_ANNOUNCE.time
HANNOUNCE
X.603.1(07)_F13
Figure 13 – Periodic head announce
Figure 14 shows how a new HMA is selected. If there is no HANNOUNCE for a certain time
(H_ANNOUNCE.time × N_ANNOUNCE), the HMA waits for a HANNOUNCE for a random back-off time. If there is
no HANNOUNCE, then the MA becomes the HMA of the multicast-enabled network. However, if there is a
HANNOUNCE, then the MA discards the back-off time and selects the HMA as its primary PMA candidate. If there
are more than two HANNOUNCE, the earliest HANNOUNCE sender becomes a HMA. If two or more HANNOUNCE
have collided, then the HMA should follow the duplication suppression algorithm.
ITU-T Rec. X.603.1 (02/2007) 9
MA A MA B MA C
HeadMA
H_ANNOUNCE.time
×
N_ANNOUNCE
Back-off
time
HANNOUNCE
Back-off
time
Back-off
time
X.603.1(07)_F14
Figure 14 – New HMA selection
Because each MA in a multicast-enabled network can be elected as a HMA, each MA should also perform the map
discovery mechanism for the outside network. The detailed procedure is discussed in the following subclause.
6.2.2.2 Outside multicast-enabled area
Each MA should start neighbour discovery procedure based on the initial bootstrapping information given by the SM.
As shown in Figure 15, each MA can gradually learn the RMCP-2 tree topology by exchanging the tree information of
each MA.
The basic map discovery mechanism is as follows: first, by using the PPROBREQ and PPROBANS, each MA can
exchange a certain number of NLs at every interval (PPROBE.time). Because of the finite system resource of each MA,
the maximum number of NLs to be exchanged should be bounded.
To prevent each MA suffered from PPROBREQ implosion, the maximum number of PPROBREQ messages for a
certain period should be limited as N_MAX_PROBE.
MA A MA B MA C MA D MA E
PPROBREQ
PPROBREQ
PPROBANS
PPROBANS
PPROBE.time
PPROBREQ
PPROBREQ
PPROBANS
PPROBE.time
PPROBANS
X.603.1(07)_F15
Figure 15 – Protocol sequence of map discovery
6.2.3 Tree join
Tree join procedure enables each MA to choose PMA inside a subscribed RMCP-2 session. Figure 16 shows how an
MA selects its PMA based on the NL given by the SM. The joining MA (MA E) sends a PPROBREQ to one or more
nodes listed in the NL (MA A, C, and D) and awaits a successful PPROBANS. Upon receiving a PPROBANS,
the MA E can select the nearest MA. In Figure 16, the joining MA (node E) considers that the MA D is the best and
then chooses the MA D as its PMA. After a PMA is selected, the joining MA (node E) will send to the MA D a
RELREQ, which contains a proposed data profile.
If the RELREQ is acceptable, the MA D responds with a successful RELANS, which includes the negotiated data
profile to be used. Otherwise, the MA D returns a reason code of the rejection.
Upon receiving a successful RELANS, data channel between the MA D and MA E is established according to the
negotiated data profile. Otherwise, the MA E should try the second optimal PMA candidate.
10 ITU-T Rec. X.603.1 (02/2007)
MA A MA B MA C MA D MA E
PPROBREQ
PPROBREQ
PPROBREQ
PPROBANS
PPROBANS
PPROBANS
RELREQ
RELANS
Data channel
X.603.1(07)_F16
Figure 16 – Protocol sequence of successful tree join
If no MA wants to relay data to the joining MA, the joining MA can retry tree join procedure after a certain period. The
retrial time can be set by the user, though this issue is beyond the scope of this Specification. Figure 17 shows when all
the MAs listed in the NL given by the SM rejected node E's relay request. However MA E already learned about the
existence of MA B during previous exchanges of PPROBREQ and PPROBANS, it can restart the joining procedure
from MA B.
Figure 17 – Sequence of unsuccessful tree join and retrial
6.2.4 Leave
An RMCP-2 MA may leave a session during the session lifetime. To make a RMCP-2 tree robust, each MA should
notify its departure to the PMA and CMAs. Upon receiving this notification, the PMA and each CMA should follow the
appropriate procedure.
The RMCP-2 considers four types of departure. The first one refers to an MA that leaves the session at the request of a
service user. The second one refers to an MA that leaves its PMA to switch parents. The third one refers to the
expulsion of an MA from its PMA or SM. The final one refers to the departure of an SMA from a session. The detailed
operations for the cases are described in the following subclauses.
ITU-T Rec. X.603.1 (02/2007) 11
6.2.4.1 When MA leaves a session
MAs may leave a session at any time during the session's lifetime. Before leaving, an MA must notify the PMA and
CMAs of its departure. The PMA deletes the node from its CMA list and reserves a space for a new CMA.
a) MA's leaving with multicast-disabled data delivery scheme
To leave a session, an MA sends a LEAVREQ to its CMAs. Each CMA who receives the LEAVREQ should promptly
start to connect to an alternative PMA by sending a RELREQ to the PMA candidate. If successful, each CMA sends its
old PMA a LEAVANS.
Figure 18 shows how the MA C acts when the HMA leaves a session during which the multicast data delivery scheme
is not used. MA C tries to leave the session by sending a LEAVREQ to MA D and MA E, which are the CMAs of
MA C. On receiving the LEAVREQ, MA D and MA E each sends a RELREQ to their own PMA candidate.
After each MA has successfully attached to a new PMA (MA A and MA B), each MA (MA D and MA E) sends a
LEAVANS to the current PMA (MA C). Upon receiving the LEAVANS from its CMAs, the MA C sends a LEAVREQ
to its PMA (MA B). The PMA subsequently frees the MA from its CMA list. Any departing MA without CMA simply
sends a LEAVREQ to its PMA.
MA A MA B MA C MA D MA E
LEAVREQ
LEAVREQ
HLEAVE
HANNOUNCE
RELREQ
RELANS (OK)
LEAVANS
RELREQ
RELANS (OK)
LEAVANS
LEAVREQ
LEAVANS
X.603.1(07)_F18
Inside same local multicast area
Figure 18 – HMA's leaving with multicast-disabled data delivery scheme
Figure 19 shows how a MA, which is not a HMA, leaves a session when a multicast-disabled data delivery scheme is
used. In this scenario, the procedures of leaving for a non-HMA and the HMA are the same, except the HMA follows
the HLEAVE exchanging sequence.
MA A MA B MA C MA D MA E
LEAVREQ
LEAVREQ
RELREQ
RELANS (OK)
LEAVANS
RELREQ
RELANS (OK)
LEAVANS
LEAVREQ
LEAVANS
X.603.1(07)_F19
Figure 19 – Normal MA's leaving with multicast-disabled data delivery scheme
12 ITU-T Rec. X.603.1 (02/2007)
b) MA's leaving with multicast-enabled data delivery scheme
There are two cases of MA's leaving within a multicast-enabled area. The first case is of HMA's leaving and the other is
of MA's leaving. Whenever the HMA of a multicast-enabled area wants to leave a session, it should notify its departure
to the CMAs inside the local network as well as to the CMAs and the PMA outside the network.
Figure 20 shows how the MA C, which acts as HMA, leaves a session where the multicast data delivery scheme is used.
The HMA (MA C) sends a LEAVREQ to its direct CMA (MA F) outside the local network. Upon receiving the
LEAVREQ, MA F starts to switch parents and responds to MA C with a LEAVANS as well as multicasts a HLEAVE
with an empty HMA candidate list to the local network. The HLEAVE message is used to announce the departure of
the HMA.
Upon receiving the HLEAVE from HMA, both MA D and MA E from Figure 20 wait for a certain back-off time before
multicasting the HANNOUNCE. The MA D sends the HANNOUNCE for the first time and becomes a new HMA. This
step occurs because the MA D has a shorter back-off time than any other MA. Because the leaving MA C is a point
which is connected to outside multicast-enabled network, the MA D should undertake the role of the MA C by
connecting to the PMA outside of the network. Figure 20 shows how the MA D selects for its parent the MA B, which
is the PMA of the MA C.
Figure 20 – MA's leaving with multicast-enabled data delivery scheme
Whenever any non-HMA of a multicast-enabled area wants to leave a session, it silently leaves the session. The MA D
or MA E from Figure 20 does not need to notify other MAs of its departure.
6.2.4.2 When MA leaves from its PMA – for parent switching
An MA that wants to switch its PMA may leave its current PMA. In this case, the MA does not need to send a
LEAVREQ to its CMAs. The CMAs do not need to know about the departure as long as they successfully receive data.
To switch PMA, the MA sends a RELREQ to the other PMA candidate. An old PMA that receives a LEAVREQ with
the reason code set to PS (parent switching) deletes the leaving MA from its CMA list but keeps the information of the
departing MA in its NL because the leaving MA is still alive in the session.
Figure 21 shows how an MA switches its parents. Note that an MA can switch parents only when it receives a HB to
keep tree unchanged. The HB mechanism is described in 6.2.5.1.
MA A MA B MA C MA D
HB
RELREQ
RELANS (OK)
HB (new RP)
LEAVREQ (PS)
LEAVANS (PS)
X.603.1(07)_F21
Figure 21 – MA's leaving for parent switching
ITU-T Rec. X.603.1 (02/2007) 13
6.2.4.3 When MA is kicked out
RMCP-2 has a mechanism for discarding certain MAs. For example, when a network manager wants the SM to discard
a specific MA; and when an MA expels a CMA after it was aware that it cannot support more CMAs.
a) Expulsion of an MA by its PMA
A PMA can expel one of its CMAs when the PMA suffers from depleted system resources and can no longer feed its
CMA, or when the PMA finds that one of its CMAs has depleted the system resources. An MA should find another
PMA candidate, which would allow for a new CMA.
Figure 22 shows an example of a message flow. First, a PMA, namely the MA C, sends a LEAVREQ with a reason KO
to expel MA D. The MA D searches other PMAs and sends a relay request. After switching parents, MA D transmits a
LEAVANS to its old PMA.
MA A MA B MA C MA D MA E
LEAVREQ
(You are KO)
RELREQ
RELANS (OK)
LEAVANS
X.603.1(07)_F22
(You are KO)
Figure 22 – When MA is kicked out by its PMA
b) Expulsion of an MA by the SM
The SM can discard any MA by sending a LEAVREQ with a reason kicked-out (KO). Upon receiving LEAVREQ from
SM, an MA must leave the session promptly. After the expulsion, the SM should update its session member list.
In the message flow shown in Figure 23, the SM tells MA B to leave by sending a LEAVREQ with a reason KO. MA B
must leave the session but, before leaving, MA B must notify its PMA and CMAs of its expulsion.
SM MA A MA B MA C
LEAVREQ (You are KO)
LEAVANS (You are KO)
LEAVREQ (I am KO) LEAVREQ (I am KO)
LEAVANS (I am KO) LEAVANS (I am KO)
X.603.1(07)_F23
Figure 23 – When MA is kicked out by SM
6.2.4.4 When SMA leaves the session
Because an RMCP-2 session cannot exist without an SMA, an SMA never leaves a session before the session is
terminated. In this case, when the SMA leaves the session, the session should be terminated.
Figure 24 shows the departure procedure of an SMA from a session. The SMA sends a LEAVREQ to the SM. Upon
receiving the LEAVREQ from the SMA, the SM removes the session information and then replies with LEAVANS.
Upon receiving the LEAVANS from the SM, the SMA sends a LEAVREQ with reason SMA leave to its direct CMAs.
The LEAVREQ with reason SMA leave should be relayed downward promptly to make RMCP-2 session terminated.
SM SMA MA A MA B
LEAVREQ (SMA)
LEAVANS (SMA)
LEAVREQ (SMA)
LEAVANS (SMA)
LEAVREQ (SMA)
LEAVANS (SMA)
X.603.1(07)_F24
Figure 24 – SMA's leaving
14 ITU-T Rec. X.603.1 (02/2007)
6.2.5 Maintenance
6.2.5.1 Heartbeat
The purpose of the heartbeat is to keep the constructed RMCP-2 tree robust. The heartbeat, which gives unified
synchronizing information to the session, helps each MA detect whether the session is currently alive. It also contains
useful information on the data delivery path, named ROOTPATH. The ROOTPATH includes a relayed data path which
follows the tree hierarchy.
Figure 25 shows the RMCP-2 heartbeat procedure. In this procedure, the SMA sends the HB, along the ROOTPATH, to
its descendants; each descendant then appends the hop information, which may include MAID, per-hop network
distance and system information such as in-and-out bandwidth, affordable number of CMA, etc. to the HB and forwards
the modified HB to its descendants. Finally, the ROOTPATH contains all the MAs visited along the tree.
SMA MA A MA B MA C MA D
HB
HB*
HB** HB**
HB.time
HB
HB*
HB** HB**
HB.time
X.603.1(07)_F25
Figure 25 – Heartbeat
6.2.5.2 Monitoring
RMCP-2 has two types of monitoring mechanisms. The first one, which is shown in Figure 26, monitors a specific MA.
The other one, which is shown in Figure 27, monitors a part of the tree through a specific MA.
Figure 26 shows how an SM monitors a specific MA. In this procedure, the SM sends an STREQ to MA B and requests
one or more specific types of status information from MA B. In response, MA B sends the SM a STANS with the
requested information.
SM SMA MA A MA B
STREQ
STANS
RP
timer
X.603.1(07)_F26
Figure 26 – Tree monitoring by status report
ITU-T Rec. X.603.1 (02/2007) 15
Figure 27 shows how the SM queries the scoped area of a tree. That is, the SM asks for merged information on the
scoped area of a tree by sending an STREQ to a specific MA (SMA and MA A each) to collect status information for
the scoped area.
SM SMA MA A MA B
STREQ
STCOLREQ
STCOLREQ
STCOLANS
STCOLANS
STANS
STREQ
STCOLREQ
STCOLANS
STANS
X.603.1(07)_F27
Figure 27 – Tree monitoring by collecting status report
6.2.5.3 Fault detection and recovery
This procedure is performed by each MA when each MA detects network faults and recovers from the problems to
make the RMCP-2 tree robust. Network faults such as looping or partitioning are often caused by MA's frequent and
careless movements. To detect and recover such network faults, RMCP-2 provides the following fault detection and
recovery mechanisms.
a) Loop detection and recovery
A loop can be detected by checking the ROOTPATH
...
NORME ISO/CEI
INTERNATIONALE 16512-2
Première édition
2008-05-15
Technologies de l'information —
Protocole de multidiffusion relayé:
Spécification relative aux applications de
groupe simplex
Information technology — Relayed multicast protocol: Specification for
simplex group applications
Numéro de référence
ISO/CEI 16512-2:2008(F)
©
ISO/CEI 2008
ISO/CEI 16512-2: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 16512-2:2008(F)
TABLE DES MATIÈRES
Page
1 Domaine d'application . 1
2 Références normatives. 1
3 Définitions . 1
4 Abréviations. 2
5 Vue d'ensemble. 3
5.1 Entités RMCP-2. 3
5.2 Bloc de protocole RMCP-2 . 4
5.3 Modèle d'acheminement simplex du protocole RMCP-2 . 5
5.4 Types de messages RMCP-2 . 6
6 Fonctionnement du protocole. 6
6.1 Fonctionnement du gestionnaire de session (SM) . 6
6.2 Fonctionnement de l'agent de multidiffusion (MA) . 8
7 Format des messages RMCP-2. 19
7.1 Format commun des messages RMCP-2. 19
7.2 Format des données de commande. 21
7.3 Messages. 22
8 Paramètres . 47
8.1 Profil de retransmission de données . 47
8.2 Paramètres utilisés dans le protocole RMCP-2 . 47
8.3 Règles de codage pour représenter les valeurs utilisées dans le protocole RMCP-2. 48
Annexe A – Algorithme de configuration de l'arborescence. 52
A.1 Règle d'amorçage. 52
A.2 Règle de découverte des voisins. 53
A.3 Règle de sélection de l'agent HMA . 54
A.4 Règle d'acceptation d'agent CMA. 54
A.5 Règle de décision concernant le parent . 55
A.6 Règle d'amélioration de l'arborescence . 56
A.7 Règle d'expulsion par l'agent PMA . 56
Annexe B – Mécanisme de fourniture de données en temps réel. 57
B.1 Aperçu. 57
B.2 Mécanisme de tunnellisation IP-IP pour la fourniture de données en temps réel RMCP-2. 57
Annexe C – Mécanisme de fourniture de données fiables. 59
C.1 Aperçu. 59
C.2 Fonctionnement . 59
C.3 Format d'encapsulation des données. 61
C.4 Profil de données . 61
Annexe D – Interfaces API RMCP-2 . 62
D.1 Aperçu. 62
D.2 Fonctions API RMCP-2 . 63
© ISO/CEI 2008 – Tous droits réservés iii
ISO/CEI 16512-2: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 16512-2 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.603.1 (02/2007).
L'ISO/CEI 16512-2 comprend les parties suivantes, présentées sous le titre général Technologies de
l'information — Protocole de multidiffusion relayé (RMCP):
⎯ Partie 1: Cadre général
⎯ Partie 2: Spécification relative aux applications de groupe simplex
⎯ Partie 3: Spécification relative aux applications de groupe N-plex
iv © ISO/CEI 2008 – Tous droits réservés
ISO/CEI 16512-2:2008(F)
Introduction
La partie 2 du protocole de multidiffusion relayé (RMCP-2) est un protocole de multidiffusion relayé de la couche
application destiné aux applications de groupe simplex. Le protocole RMCP-2 permet d'établir un trajet
d'acheminement en mode multidiffusion relayée point à multipoint, optimisé et robuste, sur un réseau de monodiffusion,
avec l'aide d'entités RMCP définies dans la Rec. UIT-T X.603 | ISO/CEI 16512-1.
Une session RMCP-2 est constituée d'un gestionnaire de session et d'un ou de plusieurs agents de multidiffusion; le
gestionnaire de session démarre et termine la session RMCP-2 et gère la session RMCP-2 ainsi que les agents de
multidiffusion participants. Le MA configure une arborescence RMCP-2 pour libérer des données de groupe en
échangeant une série de messages de commande RMCP-2.
Le long du trajet d'acheminement en mode multidiffusion relayée, plusieurs types de canaux d'acheminement de
données peuvent être mis en place conformément aux exigences des services d'application.
© ISO/CEI 2008 – Tous droits réservés v
ISO/CEI 16512-2:2008 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
Technologies de l'information – Protocole de multidiffusion relayé:
Spécification relative aux applications de groupe simplex
1 Domaine d'application
La présente Recommandation | Norme internationale décrit la partie 2 du protocole de multidiffusion relayé (RMCP),
protocole de la couche application qui permet de construire une arborescence de multidiffusion pour la fourniture de
données entre un expéditeur et plusieurs récepteurs sur l'Internet lorsque la multidiffusion IP n'est pas complètement
déployée. Le protocole de multidiffusion relayé qui est spécifié comprend un agent de multidiffusion et un gestionnaire
de session. La présente Recommandation | Norme internationale spécifie une série de fonctions et de procédures
permettant à un agent de multidiffusion de construire un trajet de données relayées point à multipoint et de relayer des
données simplex. Il spécifie également le fonctionnement du gestionnaire de session pour la gestion de sessions de
multidiffusion. Ce protocole peut être utilisé pour les applications nécessitant des services d'acheminement de données
point à multipoint tels que le service de transfert de flux continu multimédia, le service de diffusion de fichier, etc.
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.603 (2004) | ISO/CEI 16512-1:2005, Technologies de l'information –
Protocole de multidiffusion relayé: cadre général.
– Recommandation UIT-T X.605 (1998) | ISO/CEI 13252:1999, Technologies de l'information –
Définition du service de transport de communications amélioré.
– Recommandation UIT-T X.606 (2001) | ISO/CEI 14476-1:2002, Technologies de l'information –
Protocole de transport de communications amélioré: spécification du transport simplex en
multidiffusion.
– Recommandation UIT-T X.606.1 (2003) | ISO/CEI 14476-2:2003, Technologies de l'information –
Protocole de transport de communications amélioré: spécification de la gestion de la qualité de service
pour le transport simplex en multidiffusion.
3 Définitions
Pour les besoins de la présente Recommandation | Norme internationale, les définitions suivantes s'appliquent:
3.1 multidiffusion: système d'acheminement de données dans lequel la même unité de données est transmise à
partir d'une source unique vers des destinations multiples, au cours d'une seule et même invocation de service.
3.2 multidiffusion IP: système de multidiffusion sur le réseau IP, avec l'appui de plusieurs routeurs IP avec
multidiffusion activée.
3.3 multidiffusion relayée: système d'acheminement de données en mode multidiffusion qui peut être utilisé
dans des environnements de monodiffusion. Le système est fondé sur des agents de multidiffusion intermédiaires qui
relaient les données de multidiffusion entre un serveur média et des lecteurs médias sur une hiérarchie arborescente.
3.4 protocole de multidiffusion relayé (RMCP, relayed multicast protocol): protocole destiné à prendre en
charge et à gérer le transport de données de multidiffusion relayé.
3.5 session RMCP-2: ensemble d'agents de multidiffusion qui utilise le protocole RMCP pour configurer le trajet
d'acheminement des données.
Rec. UIT-T X.603.1 (02/2007) 1
ISO/CEI 16512-2:2008 (F)
3.6 agent de multidiffusion (MA): entité de transport de données intermédiaire utilisée pour relayer les données
d'application de multidiffusion. En fonction du déploiement, un agent MA peut être installé sur le même système en tant
que client de réception.
3.7 agent de multidiffusion expéditeur (SMA): agent de multidiffusion associé à un expéditeur dans le même
système ou dans le même réseau local.
3.8 agent de multidiffusion récepteur (RMA): agent de multidiffusion associé à un récepteur dans le même
système ou dans le même réseau local.
3.9 agent de multidiffusion principal (HMA): représentant de l'agent MA à l'intérieur d'un réseau local dans
lequel la multidiffusion est activée.
3.10 gestionnaire de session (SM): entité RMCP responsable du fonctionnement global du protocole RMCP; peut
être située dans le même système que le serveur média ou être située séparément de ce serveur.
3.11 agent de multidiffusion parent (PMA): agent de multidiffusion amont voisin sur le trajet d'acheminement
des données RMCP-2.
3.12 agent de multidiffusion enfant (CMA): agent de multidiffusion aval voisin sur le trajet d'acheminement des
données RMCP-2.
4 Abréviations
Pour les besoins de la présente Recommandation | Norme internationale, les abréviations suivantes s'appliquent:
AUTH authentification (authentication)
CMA agent de multidiffusion enfant (child multicast agent)
DMA agent de multidiffusion spécialisé (dedicated multicast agent)
HANNOUNCE message d'annonce HMA (HMA announce message)
HB message de pulsation (heartbeat message)
HLEAVE message de sortie HMA (HMA leave message)
HMA agent de multidiffusion principal (head multicast agent)
HSOLICIT message de sollicitation HMA (HMA solicit message)
IP-IP IP dans IP (IP in IP)
LEAVANS message de réponse de sortie (leave answer message)
LEAVREQ message de demande de sortie (leave request message)
MA agent de multidiffusion (multicast agent)
MAID identification d'agent de multidiffusion (multicast agent identification)
PMA agent de multidiffusion parent (parent multicast agent)
PPROBANS message de réponse de sondage de parent (parent probe answer message)
PPROBREQ message de demande de sondage de parent (parent probe request message)
RELANS message de réponse de relais (relay answer message)
RELREQ message de demande de relais (relay request message)
RMA agent de multidiffusion récepteur (receiver multicast agent)
RMCP protocole de multidiffusion relayé (relayed multicast protocol)
SDP protocole de description de session (session description protocol)
SID identification de session RMCP-2 (RMCP-2 session identification)
SMA agent de multidiffusion expéditeur (sender multicast agent)
STANS message de réponse de notification d'état (status report answer message)
STCOLANS message de réponse de collecte de notification d'état (status report collect answer message)
STCOLREQ message de demande de collecte de notification d'état (status report collect request message)
STREQ message de demande de notification d'état (status report request message)
SUBSANS message de réponse d'abonnement (subscription answer message)
SUBREQ message de demande d'abonnement (subscription request message)
2 Rec. UIT-T X.603.1 (02/2007)
ISO/CEI 16512-2:2008 (F)
T/TCP extensions TCP des transactions (TCP extensions to transactions)
TCP protocole de commande de transmission (transmission control protocol)
TERMANS message de réponse de terminaison (termination answer message)
TERMREQ message de demande de terminaison (termination request message)
UDP protocole datagramme d'utilisateur (user datagram protocol)
5 Vue d'ensemble
Le protocole RMCP-2 est un protocole au niveau application qui utilise des agents de multidiffusion (MA) et un
gestionnaire de session (SM) pour prendre en charge et gérer le transport de données de multidiffusion relayé sur un
réseau Internet fondé sur la monodiffusion. Avec l'aide du gestionnaire de session, le protocole RMCP-2 commence par
construire une arborescence de commande de multidiffusion relayée comprenant des agents MA. Compte tenu de
l'arborescence de commande préconfigurée, chaque agent MA connecte ensuite les canaux de données appropriés les
uns avec les autres.
Les entités RMCP-2 dans le cas d'un modèle d'acheminement simplex sont décrites au § 5.1.
5.1 Entités RMCP-2
Les entités RMCP-2 sont les mêmes que celles qui sont décrites dans la partie 1 du protocole RMCP. Comme indiqué
sur la Figure 1, chaque session RMCP-2 construit un modèle d'acheminement de données en mode multidiffusion relayé
à l'aide des entités suivantes:
a) Un gestionnaire de session.
b) Un agent de multidiffusion expéditeur (SMA) par application expéditeur.
c) Un ou plusieurs agents de multidiffusion récepteurs (RMA).
d) Une ou plusieurs applications de groupe expéditeur ou récepteur.
Un gestionnaire de session peut assurer simultanément le bon déroulement d'une ou de plusieurs sessions. Il peut être
implémenté séparément ou dans le cadre d'autres entités de session RMCP-2.
Figure 1 – Topologie de service RMCP-2
Un gestionnaire de session peut assurer les fonctions suivantes:
a) initialisation de la session;
b) libération de la session;
c) gestion des membres de la session;
d) suivi de l'état de la session.
Rec. UIT-T X.603.1 (02/2007) 3
ISO/CEI 16512-2:2008 (F)
Un agent de multidiffusion (MA), catégorie désignant à la fois l'agent SMA et l'agent RMA, établit un trajet
d'acheminement en mode multidiffusion relayée entre un expéditeur et de nombreux récepteurs puis transmet les
données le long du trajet établi. Il peut assurer les fonctions suivantes:
a) initialisation de la session;
b) entrée dans la session;
c) sortie de la session;
d) maintien de la session;
e) notification d'état de la session;
f) relais de données d'application.
5.2 Bloc de protocole RMCP-2
Un gestionnaire de session (SM) devrait échanger des messages de commande avec d'autres agents de multidiffusion
(MA) et gérer une session RMCP-2. Les messages de commande utilisés par le gestionnaire de session devraient être
acheminés de manière fiable, sans quoi la session RMCP-2 devient irrécupérable. La Figure 2 ci-après représente la pile
de protocoles d'un gestionnaire de session.
Module de commande du gestionnaire
de session RMCP-2
TCP
IP (monodiffusion)
Figure 2 – Pile de protocoles d'un gestionnaire de session
Un agent de multidiffusion (MA), catégorie désignant à la fois l'agent SMA et l'agent RMA, établit un trajet
d'acheminement en mode multidiffusion relayée entre un expéditeur et de nombreux récepteurs puis transmet les
données le long du trajet établi. Un agent de multidiffusion est constitué d'un module de commande et d'un module de
transport de données RMCP-2. Le module de commande établit le trajet d'acheminement de données relayées, tandis
que le module de transport de données établit un canal de données le long du trajet établi par le module de commande
puis relaie les données par le canal en question.
Le module de commande de l'agent de multidiffusion configure l'arborescence de commande depuis l'agent SMA vers
chaque agent MA feuille en échangeant des messages de commande avec d'autres agents MA. Par ailleurs, le module de
commande est utilisé pour la commande et la gestion de la session par le gestionnaire SM. La Figure 3 représente la pile
de protocoles du module de commande d'un agent MA.
Module de commande
de l'agent MA RMCP-2
TCP
IP (monodiffusion)
Figure 3 – Pile de protocoles du module de commande
d'un agent de multidiffusion (MA)
Le module de données de l'agent MA relaie les données de l'application le long de l'arborescence configurée par le
module de commande. La Figure 4 représente la pile de protocoles d'un module de données RMCP-2. Si c'est
nécessaire, on peut insérer tout type de mécanisme de transport, étant donné que le protocole RMCP-2 n'impose aucune
restriction quant au type de données d'application à transmettre.
4 Rec. UIT-T X.603.1 (02/2007)
ISO/CEI 16512-2:2008 (F)
Afin de veiller à ce que le protocole RMCP-2 puisse adopter tout type de mécanisme de transport de données, deux
agents MA (à savoir l'agent de multidiffusion parent (PMA) et l'agent de multidiffusion enfant (CMA)) établissent un
trajet d'acheminement des données sur l'arborescence de commande en échangeant les profils de données décrits
ultérieurement.
Module de données d'un agent
MA RMCP-2
TCP, UDP, IP-IP, SCTP, etc.
IP (monodiffusion ou multidiffusion)
Figure 4 – Pile de protocoles d'un module de données RMCP-2
En général, les topologies des deux trajets pour la commande et la transmission de données sont les mêmes, étant donné
qu'un trajet d'acheminement de données est établi le long de l'arborescence de commande RMCP-2. Le long du trajet
d'acheminement des données, les données d'application provenant de l'agent SMA peuvent être acheminées vers chaque
agent MA feuille. On trouvera davantage d'informations dans les Annexes B et C, qui présentent deux systèmes
d'acheminement de données fiables et en temps réel pouvant être mis en œuvre.
5.3 Modèle d'acheminement simplex du protocole RMCP-2
Les services auxquels est destiné le protocole RMCP-2 sont les services de radiodiffusion simplex tels que la télévision
Internet en direct et la diffusion de logiciels. Dans ces modèles de service, il est important d'établir un trajet
d'acheminement des données optimal depuis un expéditeur vers plusieurs récepteurs. Le protocole RMCP-2 prend en
charge un modèle d'acheminement des données simplex en utilisant le module de commande et le module de données
de l'agent MA.
Le trajet d'acheminement des données pris en compte par le protocole RMCP-2 est une arborescence de multidiffusion
relayée pour chaque source. Le long du trajet en mode multidiffusion relayée pour chaque source, il est possible
d'établir un canal de données unidirectionnel en temps réel ou fiable. La Figure 5 représente l'une des arborescences de
multidiffusion relayée susceptibles d'être configurées par le protocole RMCP-2 pour des applications simplex en temps
réel ou fiables.
Figure 5 – Arborescence de multidiffusion relayée configurée
par le protocole RMCP-2
Rec. UIT-T X.603.1 (02/2007) 5
ISO/CEI 16512-2:2008 (F)
5.4 Types de messages RMCP-2
Pour établir et maintenir une arborescence de multidiffusion relayée, plusieurs messages de commande sont échangés
entre homologues RMCP-2 en mode demande et réponse. Le Tableau 1 énumère les messages de commande RMCP-2
selon les fonctions appropriées.
Tableau 1 – RMCP-2 messages
Messages Descriptions Opérations RMCP
SUBSREQ Demande d'abonnement
Initialisation de la session
SUBSANS Réponse d'abonnement
PPROBREQ Demande de sondage de parent
Découverte de carte
PPROBANS Réponse de sondage de parent
HSOLICIT Sollicitation HMA
HANNOUNCE Annonce HMA Choix de l'agent HMA
HLEAVE Sortie HMA
RELREQ Demande de relais
Acheminement des données
RELANS Réponse de relais
STREQ Demande de notification d'état
STANS Réponse de notification d'état
Surveillance de la session
STCOLREQ Demande de collecte d'état
STCOLANS Réponse de collecte d'état
LEAVREQ Demande de sortie
Sortie de la session
LEAVANS Réponse de sortie
HB Pulsation Pulsation de session
TERMREQ Demande de terminaison
Terminaison de session
TERMANS Réponse de terminaison
6 Fonctionnement du protocole
Le présent paragraphe décrit d'une manière détaillée les fonctions du protocole RMCP-2 et leur fonctionnement. Tous
les composants présentés dans ce paragraphe sont conformes aux définitions de la Rec. UIT-T X.603 |
ISO/CEI 16512-1.
6.1 Fonctionnement du gestionnaire de session (SM)
6.1.1 Ouverture de la session
Pour que le gestionnaire de session crée une nouvelle session, un fournisseur de contenu (CP, content provider) doit
fournir un profil de session, qui donne des renseignements pour créer une session tels que le nom de la session, les
caractéristiques de média et l'adresse de groupe. Pour différencier les sessions les unes des autres, le gestionnaire de
session crée un identificateur de session (SID) unique. Après la création réussie d'une session, le gestionnaire de session
retourne l'identificateur SID au fournisseur de contenu (CP). Les fournisseurs CP peuvent annoncer la création d'une
session en utilisant un serveur web ou un système de messagerie électronique, mais les modalités d'annonce d'une
session sortent du cadre de la présente spécification.
Une fois la création de la session réussie, le gestionnaire de session attend qu'une demande d'abonnement soit formulée
par les agents MA. Lorsque le gestionnaire de session reçoit une demande d'abonnement d'un agent MA, il décide
d'accepter ou non cette demande.
6.1.2 Contrôle d'admission
Lorsqu'il reçoit une demande d'abonnement d'un agent MA, le gestionnaire de session commence par vérifier
l'identificateur SID dans le message de demande, puis il détermine si la demande est acceptable d'après la politique de la
session. La session RMCP-2 peut être gérée aussi bien d'une manière privée que d'une manière publique, moyennant
certains renseignements complémentaires tels que les informations sur le système et les informations d'authentification.
Lorsque l'identificateur SID se trouvant dans le message SUBSREQ de l'agent MA est valable, le gestionnaire de
session vérifie l'identificateur MAID proposé et le profil de données proposé. Si l'identificateur MAID proposé par
6 Rec. UIT-T X.603.1 (02/2007)
ISO/CEI 16512-2:2008 (F)
l'agent MA a une valeur nulle ou déjà utilisée, le gestionnaire de session propose une valeur unique, sinon
l'identificateur MAID proposé sera utilisé pendant la session. Si le profil de données proposé ne peut être pris en charge,
le gestionnaire de session devrait rejeter la demande en en fournissant les motifs. Dans le cas contraire, le gestionnaire
de session négocie le profil de données le plus efficace et retourne le profil négocié.
Lorsque le message SUBSREQ de l'agent MA est accepté, le gestionnaire de session répond avec un identificateur
MAID confirmé, une liste de voisins et des informations dépendant de la session.
Pour expulser un agent MA donné, le gestionnaire de session engage la procédure de rejet en envoyant une demande de
sortie (LEAVREQ) avec le code de motif expulsé (KO, kicked-out) puis met à jour la liste des membres de sa session.
Dès réception du message LEAVREQ du gestionnaire de session, l'agent MA quitte rapidement la session. La Figure 6
illustre cette procédure, dans laquelle le gestionnaire de session envoie un message LEAVREQ avec le code de motif
KO, puis l'agent MA B quitte la session en informant ses agents PMA et CMA de son expulsion.
Figure 6 – Cas dans lequel un agent MA est expulsé par le gestionnaire de session
6.1.3 Surveillance de session
Le gestionnaire de session peut rechercher des informations d'état concernant un agent MA donné en échangeant avec
lui des messages de demande et de réponse d'état. Dès qu'il reçoit le message de demande d'état, l'agent MA répond par
un message de réponse d'état contenant les informations demandées. La Figure 7 illustre la manière dont le gestionnaire
de session surveille un agent MA donné.
Figure 7 – Surveillance de l'arborescence – Notification d'état
Le gestionnaire de session peut également recueillir des informations d'état concernant la totalité ou une partie d'une
session. En pareils cas, il envoie un message de demande de collecte d'état à l'agent MA situé au sommet de la partie de
la session. Dès réception du message de demande de collecte d'état, l'agent MA devrait envoyer une réponse d'état au
gestionnaire de session, avec des informations appropriées sur l'agent MA et ses enfants. Lorsque la taille de la session
est importante, le recours à ce mécanisme pour la totalité de la session risque de causer une surcharge du réseau et des
ressources système. Pour limiter la portée de la surveillance, le message de collecte d'état devrait contenir une option
pour la profondeur.
6.1.4 Terminaison de la session
On peut mettre fin à la session en cours du gestionnaire de session pour deux raisons:
1) demande administrative; et
2) sortie de l'agent SMA.
Rec. UIT-T X.603.1 (02/2007) 7
ISO/CEI 16512-2:2008 (F)
La Figure 8 indique la procédure de terminaison de la session du gestionnaire de session.
Figure 8 – Terminaison de la session par le gestionnaire de session
Etant donné qu'une session RMCP-2 ne peut se poursuivre que lorsque l'agent SMA est actif, celui-ci doit notifier sa
sortie au gestionnaire de session. Une fois qu'il est informé de la sortie de l'agent SMA, le gestionnaire de session
devrait rapidement mettre fin à la session. La terminaison de la session engendrée par la sortie de l'agent SMA sera
décrite au § 6.2.4.4.
6.2 Fonctionnement de l'agent de multidiffusion (MA)
6.2.1 Abonnement à la session
L'abonnement constitue la première étape de l'inscription d'un agent MA à une session RMCP-2. Chaque agent MA doit
s'abonner à la session en envoyant une demande d'abonnement (SUBSREQ) au gestionnaire de session. Il convient de
noter que l'agent SMA doit avoir terminé son abonnement avant les autres agents MA et qu'il doit agir en tant que nœud
racine dans la hiérarchie arborescente. A ce stade, chaque agent MA doit connaître en détail le profil de la session, par
exemple l'adresse du gestionnaire de session et la politique.
La Figure 9 indique la procédure d'abonnement à la session RMCP-2. Une fois l'abonnement de l'agent SMA effectué,
la session RMCP-2 peut être ouverte.
Figure 9 – Abonnement de l'agent SMA
La Figure 10 illustre la procédure d'abonnement d'un agent MA (pour les agents MA A et MA B). Pour s'abonner à une
session RMCP-2, chaque agent MA envoie une demande SUBSREQ au gestionnaire de session. Dès réception de cette
demande, le gestionnaire de session décide s'il accepte ou non la demande d'abonnement. Si la demande est acceptée, le
gestionnaire de session répond en envoyant un message SUBSANS et des informations d'amorçage (par exemple une
liste de voisins). Dans le cas contraire, il répond en envoyant un message SUBSANS avec un code de motif d'erreur
approprié.
Après avoir reçu un message SUBSANS d'acceptation en provenance du gestionnaire de session, les agents MA (MA A
et MA B) peuvent achever la phase d'abonnement.
Figure 10 – Abonnement d'agent MA
8 Rec. UIT-T X.603.1 (02/2007)
ISO/CEI 16512-2:2008 (F)
6.2.2 Découverte de carte
Etant donné que les agents MA sont interconnectés de manière logique, ils éprouvent des difficultés à connaître l'état du
réseau dans son intégralité. Toutefois, en utilisant des procédures de découverte de carte, chaque agent MA peut
explorer d'autres agents MA dans le réseau RMCP-2 et mesurer la distance qui le sépare d'eux. Le mécanisme de
découverte de carte comprend deux étapes. La première est utilisée dans la zone avec multidiffusion activée (par
exemple un sous-réseau local) et la deuxième est utilisée à l'extérieur de cette zone (par exemple dans un réseau
étendu).
6.2.2.1 A l'intérieur de la zone avec multidiffusion activée
Il est souhaitable d'assigner le nœud le plus proche à son agent PMA. Dans le protocole RMCP-2, la distance dans le
réseau dépend de la gigue du temps de transmission, du décompte de sauts et de la largeur de bande.
En principe, un agent MA d'un même réseau est plus proche que les autres agents MA, chaque agent MA recherche un
agent PMA possible dans son réseau local en acheminant par multidiffusion une sollicitation d'agent de multidiffusion
principal (HSOLICIT) à une adresse spécifique assignée au préalable (radiodiffusion) dès le début. En l'absence de
réponse, l'agent MA devient l'agent HMA, qui est un représentant de l'agent MA dans le réseau avec multidiffusion
activée.
Une fois qu'un agent MA devient un agent HMA, celui-ci annonce son existence au réseau avec multidiffusion activée
en envoyant des messages périodiques HANNOUNCE. L'agent HMA envoie rapidement un message HANNOUNCE
dès réception d'un message HSOLICIT provenant de la zone avec multidiffusion activée.
Dès réception du message HANNOUNCE de l'agent HMA, chaque agent MA considère qu'un agent HMA existe déjà
dans le même réseau et considère ensuite que l'agent HMA est son agent PMA possible primaire. La Figure 11 illustre
la procédure de sélection de l'agent HMA.
Figure 11 – Sollicitation d'agent HMA et annonce
La Figure 12 indique comment un agent MA devient un agent HMA. En l'absence de message HANNOUNCE pendant
un certain temps (H_SOLICIT.time × N_SOLICIT), un agent MA devient le nouvel agent HMA et diffuse un message
périodique HANNOUNCE tous les H_ANNOUNCE.time à destination de la zone avec multidiffusion activée.
Figure 12 – Un agent MA devient le nouvel agent HMA
Rec. UIT-T X.603.1 (02/2007) 9
ISO/CEI 16512-2:2008 (F)
La Figure 13 montre comment un agent HMA reprend les activités. Une fois qu'un agent MA devient un agent HMA, il
transmet un message HANNOUNCE au réseau avec multidiffusion activée tous les H_ANNOUNCE.time.
Figure 13 – Message périodique HANNOUNCE
La Figure 14 montre comment un nouvel agent HMA est choisi. En l'absence de message HANNOUNCE pendant un
certain temps (H_ANNOUNCE.time × N_ANNOUNCE), l'agent HMA attend un message HANNOUNCE pendant un
délai d'attente aléatoire. En l'absence de message HANNOUNCE, l'agent MA devient l'agent HMA du réseau avec
multidiffusion activée. Cependant, s'il y a un message HANNOUNCE, l'agent MA rejette le délai d'attente et choisit
l'agent HMA comme son agent PMA possible primaire. S'il y a plus de deux messages HANNOUNCE, l'expéditeur du
message HANNOUNCE le plus précoce devient l'agent HMA. En cas de collision entre deux messages HANNOUNCE
ou plus, l'agent HMA doit suivre l'algorithme de suppression de duplication.
Figure 14 – Sélection d'un nouvel agent HMA
Etant donné que dans un réseau avec multidiffusion activée, chaque agent MA peut être choisi comme agent HMA,
chaque agent MA doit également mettre en œuvre le mécanisme de découverte de carte pour le réseau extérieur. La
procédure détaillée est décrite dans le paragraphe suivant.
6.2.2.2 A l'extérieur de la zone avec multidiffusion activée
Chaque agent MA doit engager une procédure de découverte des voisins sur la base des informations d'amorçage
initiales fournies par le gestionnaire de session. Comme indiqué sur la Figure 15, chaque agent MA peut
progressivement apprendre la topologie de l'arborescence RMCP-2 en échangeant les informations d'arborescence de
chaque agent MA.
Le mécanisme de découverte de carte de base est le suivant: en premier lieu, en utilisant les messages PPROBREQ et
PPROBANS, chaque agent MA peut échanger une liste contenant un certain nombre de voisins à chaque intervalle
(PPROBE.time). Etant donné que les ressources système de chaque agent MA sont limitées, le nombre maximal de
voisins dans la liste à échanger devrait être limité.
Pour éviter à chaque agent MA de subir les conséquences d'une explosion de message PPROBREQ, le nombre maximal
de messages PPROBREQ pendant une période donnée devrait être limité à N_MAX_PROBE.
10 Rec. UIT-T X.603.1 (02/2007)
ISO/CEI 16512-2:2008 (F)
Figure 15 – Procédure de découverte de carte
6.2.3 Entrée dans l'arborescence
La procédure d'entrée dans l'arborescence permet à chaque agent MA de choisir un agent PMA à l'intérieur d'une
session RMCP-2 à laquelle il s'est abonné. La Figure 16 montre comment un agent MA choisit son agent PMA sur la
base de la liste de voisins indiquée par le gestionnaire de session. L'agent MA entrant (agent MA E) envoie un message
PPROBREQ à un ou plusieurs nœuds indiqués dans la liste de voisins (agents MA A, C et D) et attend un message
PPROBANS d'acceptation. Dès qu'il reçoit un message PPROBANS, l'agent MA E peut choisir l'agent MA le plus
proche. Sur la Figure 16, l'agent MA entrant (nœud E) considère que l'agent MA D est le meilleur, puis choisit l'agent
MA D comme étant son agent PMA. Après sélection de l'agent PMA, l'agent MA entrant (nœud E) enverra à l'agent
MA D un message RELREQ, qui contient un profil de données proposé.
Si le message RELREQ est acceptable, l'agent MA D répond en envoyant un message RELANS d'acceptation, qui
comprend le profil de données négocié à utiliser, sinon il renvoie un code de motif du rejet.
Après réception d'un message RELANS d'acceptation, le canal de données entre les agents MA D et MA E est établi
conformément au profil de données négocié, sinon l'agent MA E doit essayer le deuxième meilleur agent PMA possible.
Figure 16 – Procédure d'entrée réussie dans l'arborescence
Si aucun agent MA ne veut relayer les données vers l'agent MA entrant, celui-ci peut recommencer la procédure
d'entrée dans l'arborescence après un certain délai. Le temps nécessaire à cette nouvelle tentative peut être déterminé
par l'utilisateur, encore que cette question sorte du cadre de la présente spécification. La Figure 17 indique quand tous
les agents MA énumérés dans la liste de voisins fournie par le gestionnaire de session ont rejeté la demande de relais du
nœud E. Toutefois, l'agent MA E connaissait déjà l'existence de l'agent MA B pendant les échanges précédents de
messages PPROBREQ et PPROBANS, de sorte qu'il peut recommencer la procédure d'entrée auprès de l'agent MA B.
Rec. UIT-T X.603.1 (02/2007) 11
ISO/CEI 16512-2:2008 (F)
Figure 17 – Echec de l'entrée dans l'arborescence et nouvelle tentative
6.2.4 Sortie
Un agent MA RMCP-2 peut sortir d'une session pendant la durée de vie de cette session. Pour rendre robuste une
arborescence RMCP-2, chaque agent MA doit informer de son départ l'agent PMA et les agents CMA. Lorsqu'ils
reçoivent cette notification, l'agent PMA et chaque agent CMA doivent se conformer à la procédure appropriée.
Le protocole RMCP-2 prend en compte quatre types de sortie. Le premier s'applique à un agent MA qui quitte la
session à la demande d'un utilisateur du service. Le deuxième s'applique à un agent MA qui quitte son agent PMA pour
changer de parent. Le troisième s'applique à l'expulsion d'un agent MA par son agent PMA ou le gestionnaire de
session. Le dernier s'applique à la sortie d'un agent SMA d'une session. Le fonctionnement détaillé de ces cas est décrit
dans les paragraphes qui suivent.
6.2.4.1 Un agent MA quitte une session
Les agents MA peuvent quitter une session à tout moment pendant la durée de vie de la session. Avant de sortir, un
agent MA doit informer l'agent PMA et les agents CMA de son départ. L'agent PMA supprime le nœud de la liste de ses
agents CMA et réserve un espace à un nouvel agent CMA.
a) Agent MA quittant la session dans le cas d'un système d'acheminement des données en mode sans
multidiffusion
Pour quitter une session, un agent MA envoie un message LEAVREQ à ses agents CMA. Chaque agent CMA recevant
le message LEAVREQ devrait rapidement commencer à se connecter à un agent PMA de remplacement, en envoyant
un message RELREQ à l'agent PMA possible. Si cette opération aboutit, chaque agent CMA envoie un message
LEAVANS à son ancien agent PMA.
La Figure 18 montre comment l'agent MA C se comporte lorsque l'agent HMA quitte une session pendant laquelle le
système d'acheminement de données en mode multidiffusion n'est pas utilisé. L'agent MA C essaye de quitter la session
en envoyant un message LEAVREQ aux agents MA D et MA E, qui sont les agents CMA de l'agent MA C. Dès
réception du message LEAVREQ, les agents MA D et MA E envoient chacun un message RELREQ à leur propre agent
PMA possible.
Une fois que chaque agent MA s'est rallié avec succès à un nouvel agent PMA (MA A et MA B), chaque agent MA
(MA D et MA E) envoie un message LEAVANS à l'agent PMA actuel (MA C). Dès réception du message LEAVANS
de ses agents CMA, l'agent MA C envoie un message LEAVREQ à son agent PMA (MA B). L'agent PMA retire
ensuite l'agent MA de sa liste d'agents CMA. Tout agent MA sortant qui n'a pas d'agent CMA se contente d'envoyer un
message LEAVREQ à son agent PMA.
12 Rec. UIT-T X.603.1 (02/2007)
ISO/CEI 16512-2:2008 (F)
Figure 18 – Agent HMA quittant la session dans le cas d'un système
d'acheminement des données en mode sans multidiffusion
La Figure 19 montre comment un agent MA, qui n'est pas un agent HMA, quitte une session lorsqu'un système
d'acheminement des données en mode sans multidiffusion est utilisé. Dans ce scénario, les procédures à suivre pour
quitter une session dans le cas d'un agent HMA et d'un agent non HMA sont les mêmes, à l'exception du fait que l'agent
HMA suit la séquence d'échange de message HLEAVE.
Figure 19 – Agent MA normal quittant la session dans le cas d'un système
d'acheminement des données en mode sans multidiffusion
b) Agent MA quittant la session dans le cas d'un système d'acheminement des données en mode multidiffusion
Il existe deux cas de figure lorsqu'un agent MA quitte une session à l'intérieur d'
...
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...