ISO/IEC 16512-2:2011

INTERNATIONAL ISO/IEC
STANDARD 16512-2
Second edition
2011-12-01
Information technology — Relayed
multicast protocol: Specification for
simplex group applications
Technologies de l'information — Protocole de multidiffusion relayé:
Spécification relative aux applications de groupe simplex

Reference number
©
ISO/IEC 2011
©  ISO/IEC 2011
All rights reserved. Unless otherwise specif ied, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocop ying and microfilm, w ithout 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 2011 – All rights reserved

CONTENTS
Page
1 Scope . 1
2 Normative references . 1
2.1 Identical Recommendations | International Standards . 1

2.2 Additional references . 1
3 Definitions . 2

4 Abbreviations . 3
5 Overview . 4
5.1 RMCP-2 entities . 4
5.2 RMCP-2 protocol block . 5
5.3 Simplex delivery model of RMCP-2 . 6
5.4 Types of RMCP-2 messages . 6
6 Protocol operation . 7
6.1 SM's operation . 7
6.2 MA's operation . 9
7 RMCP-2 message format . 19
7.1 Common format of RMCP-2 message . 19
7.2 Control data format . 20
7.3 Messages . 21
8 Parameters . 52
8.1 Data forwarding profile . 52
8.2 Parameters used in RMCP-2 . 53
8.3 Encoding rules to represent values used in RMCP-2 . 54
9 Overview of secure RMCP-2 . 57
9.1 Conventions . 57
9.2 Secure RMCP-2 entities . 58
9.3 Protocol blocks . 60
9.4 Types of secure RMCP-2 protocol messages . 61
9.5 Structure of regional security management . 62
10 Protocol operation . 63
10.1 SM operation . 63
10.2 MA operation . 67
11 Format of secure RMCP-2 messages . 73
11.1 Common format for secure RMCP-2 messages . 73
11.2 Secure RMCP-2 messages . 73
12 Parameters . 86
12.1 Secure RMCP-2 node types and code values . 86
12.2 Secure RMCP-2 message types and code values . 86
12.3 Secure RMCP-2 control types and code values . 87
12.4 Code values related to the RMCP-2 security policy . 88
12.5 Miscellaneous code values . 89
Annex A – Tree configuration algorithm . 91
A.1 Bootstrapping rule . 91
A.2 Neighbour discovering rule . 92
A.3 HMA selection rule . 93
A.4 CMA acceptance rule . 93
A.5 Parent decision rule . 94
A.6 Tree improvement rule . 95
A.7 PMA's kicking-out rule . 95
Annex B – Real-time data delivery scheme . 96
B.1 Overview . 96
© ISO/IEC 2011 – All rights reserved iii

Page
B.2 IP-IP tunnel mechanism for RMCP-2 real-time data delivery . 96
Annex C – Reliable data delivery scheme . 98
C.1 Overview . 98
C.2 Operation . 98
C.3 Data encapsulation format . 100

C.4 Data profile . 100
Annex D – RMCP-2 API . 101
D.1 Overview . 101
D.2 RMCP-2 API functions . 102
Annex E – Membership authentication mechanism . 105
E.1 Overview . 105
E.2 Authentication procedure . 105
Annex F – Bibliography . 107
F.1 Informative references . 107

iv © ISO/IEC 2011 – All rights reserved

Foreword
ISO (the Internation al Organization for Standardizati on) and IEC (the Internationa l Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC parti cipate in the d evelopment 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 t he 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 Te chnical 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 (03/2010).
This second edition cancels and replaces the first edition (ISO/IEC 16512-2:2008), which has been technically
revised.
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

© ISO/IEC 2011 – All rights reserved v

Introduction
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 Rec. ITU-T 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.

vi © ISO/IEC 2011 – All rights reserved

INTERNATIONAL STANDARD
RECOMMENDATION ITU-T
Information technology – Relayed multicast protocol:
Specification for simplex group applications
1 Scope
This Recommendation | International Standard specifies the Relayed MultiCast Protocol for simplex group applications
(RMCP-2), an application-layer protocol, which constructs a multicast tree for data delivery from one sender to multiple
receivers over the Internet where IP multicast is not fully deployed.
Clauses 5-8 define a basic RMCP-2 protocol without security features, and clauses 9-12 define a secure RMCP-2
protocol that adds security features to the basic protocol. Both protocols specify a series of functions and procedures for
multicast agents to construct a one-to-many relayed data path and to relay simplex data. They also specify the
operations of the session manager to manage multicast sessions.
These protocols can be used for applications that require one-to-many data delivery services, such as multimedia
streaming services or file dissemination services.
Annex E defines a membership authentication procedure for use with the secure RMCP-2 protocol. Annexes A-D
provide informative material related to these protocols. Annex F contains an informative bibliography.
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.
2.1 Identical Recommendations | International Standards
– Recommendation ITU-T X.603 (2004) | ISO/IEC 16512-1:2005, Information technology – Relayed
multicast protocol: Framework.
2.2 Additional references
– ISO/IEC 9797-2:2002, Information technology – Security techniques – Message Authentication Codes
(MACs) – Part 2: Mechanisms using a dedicated hash-function.
– ISO/IEC 9798-3:1998, Information technology – Security techniques – Entity authentication –
Part 3: Mechanisms using digital signature techniques.
– ISO/IEC 18033-2:2006, Information technology – Security techniques – Encryption algorithms – Part 2:
Asymmetric ciphers.
– ISO/IEC 18033-3:2010, Information technology – Security techniques – Encryption algorithms – Part 3:
Block ciphers.
– ISO/IEC 18033-4:2005, Information technology – Security techniques – Encryption algorithms – Part 4:
Stream ciphers.
– IETF RFC 2094 (1997), Group Key Management Protocol (GKMP) Architecture.
– IETF RFC 3546 (2003), Transport Layer Security (TLS) Extensions.
– IETF RFC 3830 (2004), MIKEY: Multimedia Internet KEYing.
– IETF RFC 4279 (2005), Pre-Shared Key Ciphersuites for Transport Layer Security (TLS).
– IETF RFC 4346 (2006), The Transport Layer Security (TLS) Protocol Version 1.1.
– IETF RFC 4535 (2006), GSAKMP: Group Secure Association Key Management Protocol.
Rec. ITU-T X.603.1 (03/2010) 1

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.
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.
3.13 RMCP-2 protocol: A relayed multicast protocol for simplex group applications.
3.14 basic RMCP-2 protocol: The relayed multicast protocol for simplex group application defined in clauses 5-8.
3.15 secure RMCP-2 protocol: The relayed multicast protocol supporting security features for simplex group
applications defined in clauses 9-12.
3.16 dedicated multicast agent (DMA): An intermediate MA pre-deployed as a trust server by the Session
Manager (SM) in an RMCP session.
3.17 security policy: The set of criteria for the provision of security services, together with the set of values for
these criteria, resulting from agreement of the security mechanisms defined in 10.1.4.
3.18 TLS_CERT mode: A mode of the TLS defined in IETF RFC 4346 for the authentication of MAs using a
certificate.
3.19 TLS_PSK mode: A mode of the TLS defined in IETF RFC 4279 for the authentication of MAs using a pre-
shared key for the TLS key exchange.
3.20 relayed multicast region; RM region: A management zone defined by the use of the session key Ks.
3.21 member multicast region; MM region: A management zone defined by the use of one or more group
keys Kg.
3.22 member multicast group; MM group:
1) (in a multicast disabled area) a group consisting of one DMA and multiple RMAs sharing the same
group key Kg.
2) (in a multicast enabled area) a group consisting of one HMA, multiple RMAs together with one or more
candidate HMAs sharing the same group key Kg.
3.23 candidate HMA: A DMA that is able to assume the role of an HMA, should the original HMA leave or be
terminated from a multicast-enabled MM group.
3.24 group attribute (GP_ATTRIBUTE): An attribute that defines whether or not the Content Provider controls
the admission of RMAs to the secure RMCP-2 session.
3.25 closed group: An MM group in which all the RMAs have been allocated a service user identifier from the
Content Provider before subscribing to the secure RMCP-2 session.
2 Rec. ITU-T X.603.1 (03/2010)

3.26 open group: An MM group in which none of the RMAs require a service user identifier before subscribing to
the secure RMCP-2 session.
3.27 regular HB message: An HB message that is relayed without interruption along the path of the RMCP-2 tree
from the SMA to the receiver of the message. The originator of a regular HB message is the SMA.
3.28 pseudo-HB message: An HB message that indicates a fault in the delivery path of the RMCP-2 tree. The
originator of a pseudo-HB message is the MA that discovers this fault.
4 Abbreviations
For the purposes of this Recommendation | International Standard, the following abbreviations apply:
ACL  Access Control List
AUTH  Authentication
CEK  Contents Encryption Key
CMA  Child Multicast Agent
CP   Content Provider
DMA  Dedicated Multicast Agent
HANNOUNCE HMA announce message
HB   Heartbeat message
HLEAVE  HMA leave message
HMA  Head Multicast Agent
HRSANS  Head Required Security Answer
HRSREQ  Head Required Security Request
HSOLICIT  HMA solicit message
IP-IP  IP in IP
KEYDELIVER Key Delivery
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
SECAGANS  SECurity AGreement ANSwer
SECAGREQ  SECurity AGreement REQuest
SECALGREQ  SECurity ALgorithms REQuest
SECLIST  Selected sECurity LIST
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
Rec. ITU-T X.603.1 (03/2010) 3

SUBSANS  Subscription answer message
SUBSREQ  Subscription request message
T/TCP  TCP extensions to Transactions
TCP   Transmission Control Protocol
TERMANS  Termination answer message
TERMREQ  Termination request message
TLS   Transport Layer Security
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
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.
4 Rec. ITU-T X.603.1 (03/2010)

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.
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.
Rec. ITU-T X.603.1 (03/2010) 5

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
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
6 Rec. ITU-T X.603.1 (03/2010)

Table 1 – RMCP-2 messages
Messages Descriptions RMCP operations
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
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 Rec. ITU-T 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.
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.
Rec. ITU-T X.603.1 (03/2010) 7

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.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.
8 Rec. ITU-T X.603.1 (03/2010)

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.
Rec. ITU-T X.603.1 (03/2010) 9

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.
10 Rec. ITU-T X.603.1 (03/2010)

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.
Rec. ITU-T X.603.1 (03/2010) 11

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.
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.
12 Rec. ITU-T X.603.1 (03/2010)

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
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
Rec. ITU-T X.603.1 (03/201
...