ISO/IEC 16512-2:2008/FDAmd 2

Information technology — Relayed multicast protocol: Specification for simplex group applications — Part 2: — Amendment 2: Messages and code values

Technologies de l'information — Protocole de multidiffusion relayé: Spécification relative aux applications de groupe simplex — Partie 2: — Amendement 2: Messages et valeurs de code

General Information

• Status: Withdrawn
• ICS: 35.100.70 - Application layer
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6/WG 7 - Network, transport and future network
• Current Stage: 5098 - Project deleted
• Completion Date: 01-Nov-2011

Relations

• Revised: ISO/IEC 16512-2:2011 - Information technology — Relayed multicast protocol: Specification for simplex group applications — Part 2:
• Effective Date: 27-Aug-2011
• Amends: ISO/IEC 16512-2:2008 - Information technology — Relayed multicast protocol: Specification for simplex group applications — Part 2:
• Effective Date: 14-Jul-2018

Standards Content (Sample)

FINAL ISO/IEC
AMENDMENT
DRAFT 16512-2
FDAM 2
ISO/IEC JTC 1
Information technology — Relayed
Secretariat: ANSI
multicast protocol: Specification for
Voting begins on:
simplex group applications
2010-12-01
Voting terminates on:
AMENDMENT 2: Messages and code values
2011-02-01

Technologies de l'information — Protocole de multidiffusion relayé:
Spécification relative aux applications de groupe simplex
AMENDEMENT 2: Messages et valeurs de code


Please see the administrative notes on page iii

RECIPIENTS OF THIS DRAFT ARE INVITED TO
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPORT-
ING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
Reference number
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/IEC 16512-2:2008/FDAM 2:2010(E)
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN-
DARDS TO WHICH REFERENCE MAY BE MADE IN
©
NATIONAL REGULATIONS. ISO/IEC 2010

---------------------- Page: 1 ----------------------
ISO/IEC 16512-2/FDAM 2:2010(E)
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.


Copyright notice
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as permitted
under the applicable laws of the user's country, neither this ISO draft nor any extract from it may be
reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic,
photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to either ISO at the address below or ISO's
member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.

ii © ISO/IEC 2010 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 16512-2/FDAM 2:2010(E)
In accordance with the provisions of Council Resolution 21/1986, this document is circulated in the
English language only.


© ISO/IEC 2010 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC 16512-2/FDAM 2:2010(E)
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.
Amendment 2 to 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 (2007)/Amd.2 (03/2010).


iv © ISO/IEC 2010 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC 16512-2/FDAM 2:2010(E)

INFORMATION TECHNOLOGY – Relayed multicast protocol: Specification for simplex group
applications
AMENDMENT 2
Messages and code values


1 Clause 2. Normative references
Delete the following references:
– ITU-T Recommendation X.601 (2000), Multi-peer communications framework.
– ITU-T Recommendation X.605 (1998) | ISO/IEC 13252:1999, Information technology – Enhanced
communications transport service definition.
– 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.

2 Clause 3. Definitions
Add the following definitions:
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.

3 Clause 4. Abbreviations
Delete the following abbreviation
‘AUTH Authentication’

4 Sub-clause 6.1.2
At the end of the first paragraph, delete the following: ‘and authentication information’

5 Sub-clause 7.3.
Replace 7.3 with the following text:
7.3 Messages
This sub-clause defines each message used in RMCP-2. The message types and corresponding values for the messages
are listed in Table 23.
1
Rec. ITU-T X.603.1 (2007)/Amd.2 (03/2010)

---------------------- Page: 5 ----------------------
ISO/IEC 16512-2/FDAM 2:2010(E)
7.3.1 SUBSREQ message
7.3.1.1 General
The SUBSREQ message is used to subscribe to a RMCP-2 session.
0 4 8 16 31
NT Message type
Ver (0x2) Length (variable)
(SMA|MA) (SUBSREQ)
Session ID (64)
MAID (MAID proposed by the subscriber)

Control data (variable length)

Figure 40 – SUBSREQ message
7.3.1.2 SUBSREQ message format
The format of the SUBSREQ message is shown in Figure 40. The description of each field is as follows:
a) Ver – This field denotes the current version of RMCP. Its value shall be set to 0x2.
b) NT – This field denotes the message issuer's node type. Its value shall be set to one of SMA or MA coded
as in Table 22.
c) Message type – This field denotes the SUBSREQ message. Its value shall be set to 0x01 (see Table 23).
d) Length – This field shall be set to the total length in bytes of the SUBSREQ message including the
control data.
e) Session ID – This field shall be set to the 64-bit value of Session ID as defined in 7.1.1.
f) MAID – This field denotes the MAID proposed by the subscriber. Its value shall be formatted as defined
in 7.1.2.
g) Control data – The control types that may be used in SUBSREQ message, and their status, are shown in
Table 2.
Table 2 – Control types for the SUBSREQ message
Control type Meaning Status Reference
SYSINFO A description of the system information of MA. Optional See 7.3.1.3
DATAPROFILE A description of the requirements for forwarding data. Optional See 7.3.1.4

7.3.1.3 SYSINFO control
The SYSINFO control in the SUBSREQ message is used to convey system information about the subscribing MA in its
SYSINFO sub-controls.

0 8 16 31
Control type
Length (0x02)
(SYSINFO)
Sub-control data (variable length)
Rec. ITU-T X.603.1 (2007)/Amd.2 (03/2010)
2

---------------------- Page: 6 ----------------------
ISO/IEC 16512-2/FDAM 2:2010(E)

Figure 41 – SYSINFO control
The format of the SYSINFO control is shown in Figure 41. The description of each field is as follows:
a) Control type – This field denotes the SYSINFO control. Its value shall be set to 0x08 (see Table 24).
b) Length – This field denotes the length (2 bytes) of the SYSINFO control. Its value shall be set to 0x02.
c) Sub-control data – The SYSINFO sub-control types that may be used in the SUBSREQ message are
listed in Table 3. If more than one SYSINFO sub-control is required, each sub-control shall be preceded
by a two-byte SYSINFO control.
Table 3 – SYSINFO sub-control types for the SUBSREQ message
Sub-control type Meaning Status Reference
The number of CMA places that an MA has allocated and the
SI_ROOM_CMA Optional See 7.3.11.4.3
total number that it is able to support.
SI_POSS_BW The possible forwarding bandwidth that the MA can afford. Optional See 7.3.11.4.5
NOTE – The additional SYSINFO controls defined for other RMCP-2 messages are not relevant for the session subscription as
they relate to the position once the MA has joined the RMCP-2 tree.

7.3.1.4 DATAPROFILE control
The DATAPROFILE control is used to describe the proposed data profile of the subscribing MA.

0 8 16 31
Control type
Length (variable)
(DATAPROFILE)
Data profile (variable length)
  Padding
Figure 42 – DATAPROFILE control
The format of the DATAPROFILE control is shown in Figure 42. The description of each field is as follows:
a) Control type – This field denotes the DATAPROFILE control. Its value shall be set to 0x03 (see Table
24).
b) Length – This field denotes the length in bytes of the DATAPROFILE control. Its value shall be a
multiple of four bytes (see item d) in this list) and it shall not exceed 0xFC.
c) Data profile – This field shall contain the data profile for the MA formatted in text mode. It follows an
SDL-like encoding scheme. An example is shown in Figure 87.
d) Padding – If the total length of the control type, length and data profile fields is not a multiple of 4 bytes,
the padding field shall be filled with zeros to ensure that the length of the DATAPROFILE control is a
multiple of 4 bytes.

7.3.2 SUBSANS message
7.3.2.1 General
The SUBSANS message is used by SM to provide the results of subscription request and bootstrapping information for
the session.
0 4 8 16 31
Ver (0x2) NT (SM) Length (variable)
Message type
Rec. ITU-T X.603.1 (2007)/Amd.2 (03/2010)
3

---------------------- Page: 7 ----------------------
ISO/IEC 16512-2/FDAM 2:2010(E)
(SUBSANS)
Session ID (64)
MAID (MAID allocated by the SM)

Control data (variable length)

Figure 43 – SUBSANS message
7.3.2.2 SUBSANS message format
The format of the SUBSANS message is shown in Figure 43. The description of each field is as follows:
a) Ver – This field denotes the current version of RMCP. Its value shall be set to 0x2.
b) NT – This field denotes the message issuer's node type. Its value shall be set to the code value for SM in
Table 22.
c) Message type – This field denotes the SUBSANS message. Its value shall be set to 0x02 (see Table 23).
d) Length – This field shall be set to the total length in bytes of the SUBSANS message including control
data.
e) Session ID – This field shall be set to the 64-bit value of Session ID as defined in 7.1.1.
f) MAID – This field shall be set to the MAID of the subscriber as allocated by the SM. Its value shall be
formatted as defined in 7.1.2.
NOTE – This may not be identical to the MAID proposed by the subscriber (see 6.1.2).
g) Control data – The control types that may be used in SUBSANS message, and their status, are shown in
Table 4.
Table 4 – Control types for the SUBSANS message
Control type Meaning Status Reference
RESULT The result of the subscription request. Mandatory See 7.3.2.3
NEIGHBORLIST A list of MAIDs for performing the map discovery. See Condition 1 See 7.3.2.5
DATAPROFILE A description of the requirements for forwarding data. Optional See 7.3.2.4
Table 4. Condition 1: If the RESULT is successful, the NEIGHBORLIST is mandatory. If not, the NEIGHBORLIST
shall not be included.

7.3.2.3 RESULT control
The RESULT control in a SUBSANS message is used to convey whether or not the MA's subscription request is
successful. If successful, it returns an OK result code. If not, it returns an appropriate error code.

0 8 16 31
Control type
Length (0x04) Result code
(RESULT)
Figure 44 – RESULT control
The format of RESULT control is shown in Figure 44. The description of each field is as follows:
4
Rec. ITU-T X.603.1 (2007)/Amd.2 (03/2010)

---------------------- Page: 8 ----------------------
ISO/IEC 16512-2/FDAM 2:2010(E)
a) Control type – This field denotes the RESULT control. Its value shall be set to 0x06 (see Table 24).
b) Length – This field denotes the length (4 bytes) of the RESULT control. Its value shall be set to 0x04.
c) Result code – This field denotes the result of the request. It shall be set to one of the result codes listed in
Table 25.
7.3.2.4 DATAPROFILE control
The DATAPROFILE control is used by the SM to confirm data profile proposed by the subscriber, or to provide extra
data forwarding information to the subscriber.
The content and format of the DATAPROFILE control are specified in 7.3.1.4, Figure 42 and Figure 87.
7.3.2.5 NEIGHBORLIST control
The NEIGHBORLIST control in a SUBSANS message to a successful subscriber is used to convey a list of active MAs
that may be used for bootstrapping purpose.
0 8 24 31
Control type
Reserved Number of MAIDs
(NEIGHBORLIST)
MAID 1
MAID 2
…
MAID n
Figure 45 – NEIGHBORLIST control
The format of NEIGHBORLIST control is shown in Figure 45. The description of each field is as follows:
a) Control type – This field denotes the NEIGHBORLIST control. Its value shall be set to 0x04 (see Table
24).
b) Reserved – This field is reserved for the future use. Its value shall be set to zero. It is ignored by the
receiver.
c) Number of MAIDs – This field shall be set to the number of MAIDs listed in NEIGHBORLIST control.
d) MAID(s) – These fields MAID 1 to MAID n shall contain a list of MAIDs up to 255 active neighbors.

7.3.3 PPROBREQ message
7.3.3.1 General
The PPROBREQ message is used in the Map discovery procedure to explore network conditions and to identify
potential near neighbor. It is also used to check whether the neighboring MA is still active.
0 4 8 16 31
Message type
Ver (0x2) NT (MA) Length (variable)
(PPROBREQ)
Session ID (64)
MAID (MAID of PPROBREQ message sender)
5
Rec. ITU-T X.603.1 (2007)/Amd.2 (03/2010)

---------------------- Page: 9 ----------------------
ISO/IEC 16512-2/FDAM 2:2010(E)

Control data (variable length)

Figure 46 – PPROBREQ message
7.3.3.2 PPROBREQ message format
The format of the PPROBREQ message is shown in Figure 46. The description of each field is as follows:
a) Ver – This field denotes the current version of RMCP. Its value shall be set to 0x2.
b) NT – This field denotes the message issuer's node type. Its value shall be set to the code value for MA in
Table 22.
c) Message type – This field denotes the PPROBREQ message. Its value shall be set to 0x03 (see Table 23).
d) Length – This field shall be set to the total length in bytes of the PPROBREQ message including control
data.
e) Session ID – This field shall be set to the 64-bit value of Session ID as defined in 7.1.1.
f) MAID – This field shall be set to the MAID of the PPROBREQ message sender. Its value shall be
formatted as defined in 7.1.2.
g) Control data – The control types that may be used in PPROBREQ message, and their status, are shown
in Table 5.
Table 5 – Control types for the PPROBREQ message
Control type Meaning Status Reference
A measure of transmission time between sending and
TIMESTAMP Mandatory See 7.3.3.3
receiving MAs.
NEIGHBORLIST A list of MAIDs for performing the map discovery. Optional See 7.3.3.4
ROOTPATH A description of the path from the SMA. Optional See 7.3.3.5
SYSINFO A description of the system information of MA. Optional See 7.3.3.6
DATAPROFILE A description of the requirements for forwarding data. Optional See 7.3.3.7

7.3.3.3 TIMESTAMP control
The TIMESTAMP control is used to measure transmission time between the sending MA and the receiving MA.
0 8 16 31
Control type
Length (0x10) Reserved
(TIMESTAMP)
Time 1 (when the sender starts to send)
Time 2 (when the packet appears to receiver)
Time 3 (when the receiver starts to reply)
Figure 47 – TIMESTAMP control
The format of the TIMESTAMP control is shown in Figure 47. The description of each field is as follows:
a) Control type – This field denotes the TIMESTAMP control. Its value shall be set to 0x09 (see Table 24).
b) Length – This field denotes the length (16 bytes) of the TIMESTAMP control. Its value shall be set to
0x10.
6
Rec. ITU-T X.603.1 (2007)/Amd.2 (03/2010)

---------------------- Page: 10 ----------------------
ROOT
PATH
ISO/IEC 16512-2/FDAM 2:2010(E)
c) Reserved – This field is reserved for the future use. Its value shall be set to zero. It is ignored by the
receiver.
d) Time 1 – This field shall be set to the time when the request message is started to be sent to its recipient.
e) Time 2 – This field shall be set to the time when the request message appears to the recipient. When this
field is included in a request message, its value shall be set to zero.
f) Time 3 – This field shall be set to the time when the answer message is started to be sent to the requestor.
When this field is included in a request message, its value shall be set to zero.
7.3.3.4 NEIGHBORLIST control
The NEIGHBORLIST control in a PPROBREQ message is used to convey neighbor list information held by the
probing MA.
The content and format of the NEIGHBORLIST control are specified in 7.3.2.5 and Figure 45.
7.3.3.5 ROOTPATH control
The ROOTPATH control is used to convey the rootpath from the SMA to message sender. It may used for network
diagnosis and loop detection.
NOTE – This control cannot be used before an MA has joined the RMCP-2 tree as it will not yet have a rootpath.

0 8 16 31
Control type
Length (0x02)
(ROOTPATH)
Sub-control data

Figure 48 – ROOTPATH control
The format of the ROOTPATH control is shown in Figure 48. The description of each field is as follows:
a) Control type – This field denotes the ROOTPATH control. Its value shall be set to 0x07 (see Table 24).
b) Length – This field denotes the length (2 bytes) of the ROOTPATH control. Its value shall be set to
0x02.
c) Sub-control data – The RP_XXX sub-control that shall be used in the ROOTPATH control is shown in
Table 6.
Table 6 – RP_XXX sub-control type for the ROOTPATH control
Sub-control type Meaning Status Reference
RP_XXX Specification of rootpath elements to be used. Mandatory See 7.3.3.5.1

7.3.3.5.1 RP_XXX sub-control
Figure 49 shows the general format of the RP_XXX sub-control preceded by a ROOTPATH control. RP_XXX stands
for one of the ROOTPATH types listed in Table 26 (see note). These RP_XXX sub-control represents different
combinations of fields for MAIDs, bandwidth and delay. If the RP_XXX sub-control indicates that any of the MAIDs,
bandwidth or delay fields are not needed, these fields shall not be present in the RP_XXX sub-control. The length of the
rootpath element, in bytes, for each of the RP_XXX sub-control is indicated in Table 26.

0 8 16 24 31

Control type Sub-control type Number of
Length (0x02)
(ROOTPATH) (RP_XXX) ROOTPATH elements
MAID of SMA
Bandwidth for SMA (0x00)
7
Rec. ITU-T X.603.1 (2007)/Amd.2 (03/2010)

---------------------- Page: 11 ----------------------
ROOTPATH ROOTPATH
element element
ISO/IEC 16512-2/FDAM 2:2010(E)
Delay for SMA (0x00)
MAID of MA 1
Bandwidth for MA 1 (Mbps)
Delay for MA 1 (seconds)

…

MAID of MA n
Bandwidth for MA n (Mbps)
Delay for MA n (seconds)
Figure 49 – General format for RP_XXX sub-control

The format of an RP_XXX sub-control preceded by a ROOTPATH control is shown in Figure 49. The description of
each field of the RP_XXX sub-control is as follows:
a) Sub-control type – This field denotes the RP_XXX sub-control. Its value shall be set to one of the code
values in Table 26.
b) Number of ROOTPATH elements – This field shall be set to the number of ROOTPATH elements in the
RP_XXX sub-control.
c) MAID – This field shall be set to that of the MAID corresponding to that element, if present. This field is
for each element in the rootpath, listed in order from the SMA.
d) Bandwidth – This field shall be set to the bandwidth, in Mbps, between the MA and its parent, as
perceived by the MA for each element in the rootpath, listed in order from the SMA, if present. In the
case of the SMA element, the value for the bandwidth shall be set to zero.
e) Delay – This field shall be set to the delay in seconds from the SMA as perceived by the MA for each
element in the rootpath, listed in order from the SMA, if present. In the case of the SMA element, the
value for the bandwidth shall be set to zero.
NOTE – The values for the perceived bandwidth and delay for the SMA elements are set to zero as the ROOTPATH
is assumed to start at the SMA.

7.3.3.6 SYSINFO control
The SYSINFO control in the PPROBREQ message is used to convey system information about the MA in its sub-
controls.
The content and format of the SYSINFO control are specified in 7.3.1.3 and Figure 41. The SYSINFO sub-controls that
may be used in PPROBREQ message, together with their status and reference to their content and specification, are
listed in Table 7.
Table 7 – SYSINFO sub-control types for the PPROBREQ and PPROBANS messages
Sub-control type Meaning Status Reference
The elapsed time in seconds since the node joined the
SI_UPTIME Optional See 7.3.11.4.1
RMCP-2 session.
The delay in seconds from the SMA, as perceived by the
SI_DELAY Optional See 7.3.11.4.2
MA.
The number of CMA places that an MA has allocated and
SI_ROOM_CMA Optional See 7.3.11.4.3
the total number that it is able to support.
8
Rec. ITU-T X.603.1 (2007)/Amd.2 (03/2010)

---------------------- Page: 12 ----------------------
ISO/IEC 16512-2/FDAM 2:2010(E)
The maximum incoming and outgoing bandwidths in Mbps
SI_PROV_BW Optional See 7.3.11.4.4
of the network interface card.
SI_POSS_BW The possible forwarding bandwidth that the MA can afford. Optional See 7.3.11.4.5
The total bandwidth in Mbps consumed by the MA to serve
SI_SND_BW Optional See 7.3.11.4.6
its CMAs.
SI_SND_PACKET The total number of packets sent by the MA from startup. Optional See 7.3.11.4.7
SI_SND_BYTES The total number of bytes sent by the MA from startup. Optional See 7.3.11.4.8
SI_RCV_BW The bandwidth in Mbps perceived by the MA. Optional See 7.3.11.4.9
SI_RCV_PACKET The number of packets received by the MA from startup. Optional See 7.3.11.4.10
SI_RCV_BYTES The number of bytes received by the MA from startup. Optional See 7.3.11.4.11
A list of PMA and CMAs directly attached to the sending
SI_TREE_CONN Optional See 7.3.11.4.12
MA.
A set of MAs defined by the use of a TREEEXPLOR
SI_TREE_MEM Optional See 7.3.11.4.13
control.

7.3.3.7 DATAPROFILE control
The DATAPROFILE control in the PPROBREQ message contains data profile proposed by probing MA.
The content and format of the DATAPROFILE control are specified in 7.3.1.4, Figure 42 and Figure 87.
7.3.4 PPROBANS message
7.3.4.1 General
The PPROBANS message provides a response to the PPROBREQ message in the map discovery procedure and
confirms that the probed MA is still active. It contains information about the network condition, and a list of its
neighbor information.
0 4 8 16 31
NT Message type
Ver (0x2) Length (variable)
(SMA|MA) (PPROBANS)
Session ID (64)
MAID (MAID of PPROBANS message sender)

Control data (variable length)

Figure 50 – PPROBANS message
7.3.4.2 PPROBANS message format
The format of the PPROBANS message is shown in Figure 50. The description of each field is as follows:
a) Ver – This field denotes the current version of RMCP. Its value shall be set to 0x2.
b) NT – This field denotes the message issuer's node type. Its value shall be set to one of SMA or MA coded
as in Table 22.
c) Message type – This field denotes the PPROBANS message. Its value shall be set to 0x04 (see Table 23).
Rec. ITU-T X.603.1 (2007)/Amd.2 (03/2010)
9

---------------------- Page: 13 ----------------------
ISO/IEC 16512-2/FDAM 2:2010(E)
d) Length – This field shall be set to the total length in bytes of PPROBANS message including control
data.
e) Session ID – This field shall be set to the 64-bit value of Session ID as defined in 7.1.1.
f) MAID – This field shall be set to the MAID of the PPROBANS message sender. Its value shall be
formatted as defined in 7.1.2.
g) Control data – The control types that may be used in PPROBANS message, and their status, are shown
in Table 8.
Table 8 – Control types for the PPROBANS message
Control type Meaning Status Reference
A measure of transmission time between sending and
TIMESTAMP Mandatory See 7.3.4.3
receiving MAs.
NEIGHBORLIST A list of MAs for performing the map discovery. Mandatory See 7.3.4.4
ROOTPATH A description of the path from the SMA. Mandatory See 7.3.4.5
SYSINFO A description of the system information of the MA. Mandatory See 7.3.4.6
DATAPROFILE A description of the requirements for forwarding data. Optional See 7.3.4.7

7.3.4.3 TIMESTAMP control
This TIMESTAMP control is used to measure transmission time between the sending MA and the receiving MA.
The content and format of the TIMESTAMP control are specified in 7.3.3.3 and Figure 47.

7.3.4.4 NEIGHBORLIST control
The NEIGHBORLIST control in a PPROBANS message is used to convey neighbor list information held by the probed
MA.
The content and format of the NEIGHBORLIST control are specified in 7.3.2.5 and Figure 45.

7.3.4.5 ROOTPATH control
The ROOTPATH control is used to describe the path from the SMA to the message sender.
The content and format of the ROOTPATH control are specified in 7.3.3.5, 7.3.3.5.1 and in Figures 48 and 49.

7.3.4.6 SYSINFO control
The SYSINFO control in the PPROBANS message is used to convey system information about the probed MA for use
in the map discovery procedure in its sub-controls.
The content and format of the SYSINFO control are specified in 7.3.1.3 and Figure 41. The SYSINFO sub-controls that
may be used in PPROBANS message, together with their status and reference to their content and specification, are
listed in Table 7.

7.3.4.7 DATAPROFILE control
The DATAPROFILE control in the PPROBANS message indicates whether the probed MA can afford the data profile
proposed by the probing MA.
The content and format of the DATAPROFILE control are specified in 7.3.1.4, Figure 42 and Figure 87.

7.3.5 HSOLICIT message
7.3.5.1 General
The HSOLICIT message is used to find the HMA inside its local network.
10
Rec. ITU-T X.603.1 (2007)/Amd.2 (03/2010)

---------------------- Page: 14 ----------------------
ISO/IEC 16512-2/FDAM 2:2010(E)
0 4 8 16 31
Ver NT Message type
Length (0x14)
(0x2) (MA) (HSOLICIT)
Session ID (64)
MAID (MAID of HSOLICIT message sender)
Figure 51 – HSOLICIT message
7.3.5.2 HSOLICIT message format
The format of the HSOLICIT message is shown in Figure 51. The description of each field is as follows:
a) Ver – This field denotes the current version of RMCP. Its value shall be set to 0x2.
b) NT – This field denotes the message issuer's node type. Its value shall be set to the code value for MA in
Table 22.
c) Message type – This field denotes the HSOLICIT message. Its value shall be set to 0x05 (see Table 23).
d) Length – This field shall be set to the total length (20 bytes) of HSOLICIT message. Its value shall be set
to 0x14.
e) Session ID – This field shall be set to the 64-bit value of Session ID as defined in 7.1.1.
f) MAID – This field shall be set to the MAID of the HSOLICIT message sender. Its value shall be
formatted as defined in 7.1.2.
NOTE – There is no control data associated with the HSOLICIT message.

7.3.6 HANNOUNCE message
7.3.6.1 General
The HANNOUNCE message is sent by HMA as a reply to HSOLICIT message in order to announce the HMA's
existence in a local network.
0 4 8 16 31
NT Message type
Ver (0x2) Length (variable)
(MA) (HANNOUNCE)
Session ID (64)
MAID (MAID of HANNOUNCE message sender)

Control data (variable length)

Figure 52 – HANNOUNCE message
7.3.6.2 HANNOUNCE message format
The format of the HANNOUNCE message is shown in Figure 52. The description of each field is as follows:
a) Ver – This field denotes the current version of RMCP. Its value shall be set to 0x2.
11
Rec. ITU-T X.603.1 (2007)/Amd.2 (03/2010)

---------------------- Page: 15 ----------------------
ISO/IEC 16512-2/FDAM 2:2010(E)
b) NT – This field denotes the message issuer's node type. Its value shall be set to the code value for MA in
Table 22.
c) Message type – This field denotes the HANNOUNCE message. Its value shall be set to 0x06 (see Table
23).
d) Length – This field shall be set to the total length in bytes of HA
...