TD 521 (GEN/11) STUDY GROUP 11. English only Original: English TELECOMMUNICATION STANDARDIZATION SECTOR. Question(s): 15/11 Geneva, 10 September 2010

Transcription

1 INTERNATIONAL TELECOMMUNICATION UNION STUDY GROUP 11 TELECOMMUNICATION STANDARDIZATION SECTOR STUDY PERIOD English only Original: English Question(s): 15/11 Geneva, 10 September 2010 Source: Title: Editors TEMPORARY DOCUMENT Draft Recommendation ITU-T X.603.2, RMCP - Specification for N-plex group applications (for Content) [Editor s Note] This document contains output text of Draft Recommendation X.603.2, which is considered for AAP consent in the SG 11 WP3 plenary meeting in Geneva, 10 September Contact: Contact: Shin-Gak Kang ETRI Korea Sung Hei Kim ETRI Korea Tel: Fax: sgkang@etri.re.kr Tel: Fax: shkim@etri.re.kr Attention: This is not a publication made available to the public, but an internal ITU-T Document intended only for use by the Member States of ITU, by ITU-T Sector Members and Associates, and their respective staff and collaborators in their ITU related work. It shall not be made available to, and used by, any other persons or entities without the prior written consent of ITU-T.

2 - 2 - INTERNATIONAL STANDARD RECOMMENDATION ITU-T X Information technology Relayed multicast protocol: Specification for N-plex group applications Summary This Recommendation International Standard describes the Relayed Multicast Protocol part 3 (RMCP-3) which is an application-layer relayed multicast protocol that operates over the IP-based network where the IP multicast is not fully deployed. The RMCP-3 constructs a relayed multicast tree for delivering user data from multiple senders to multiple receivers. The relayed multicast tree consists of Multicast Agent and Session Manager. The Multicast Agent relays many-to-many multicast data along the relayed multicast tree, whereas the Session Manager manages the RMCP-3 session. This Recommendation International Standard specifies the functions and the procedures of the Multicast Agent and Session Manager. The RMCP-3 can support applications requiring capability of many-to-many multicast data delivery. Examples of such applications are multimedia conference, panel discussion, and network gaming. Keywords Relayed Multicast Protocol, N-plex group communication, IP multicasting, Overlay multicasting Foreword ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) established 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 the technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations -- be they government or non-government -- also take part in the work in liaison with ISO and IEC. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.

3 - 3 - CONTENTS Page 1 Scope Normative references Definitions Terms defined elsewhere Terms defined within this Recommendation International Standard Abbreviations Abbreviations of RMCP-3 messages Abbreviations of non-messages Conventions Overview RMCP-3 service RMCP-3 entities Protocol modules of RMCP RMCP-3 control model N-plex data delivery model of RMCP Types of RMCP-3 messages Protocol operation SM s operation Session initiation Session subscription Session monitoring Failure check and handling Member expulsion Horizontal Heartbeat Session termination CoreMA s operation Initiation Support for RMCP-3 join of EdgeMA Maintenance Session termination Fault detection in the core domain EdgeMA s operation Session initiation Session subscription Neighbor discovery Session join Leave the subscribed session Edge-tree reconstruction Maintenance Session termination Fault detection and recovery RMCP-3 message Common RMCP-3 message format Control and sub-control format Common control format Common sub-control format... 40

4 Formatting multiple controls RMCP-3 messages SUBSREQ message SUBSANS message PPROBREQ message PPROBANS message HSOLICIT message HANNOUNCE message HLEAVE message RELREQ message RELANS message STREQ message STANS message LEAVREQ message LEAVANS message TERMREQ message TERMANS message HHB message VHB message FAILCHECK message RMCP-3 controls and sub-controls RP_COMMAND control SI_COMMAND control CTRLCHANNEL control DATAPROFILE control NEIGHBORLIST control PSEUDO_HB control REASON control RESULT control ROOTPATH control SYSINFO control TIMESTAMP control Parameters Identifications used in RMCP Session ID (SID) Multicast Agent ID (MAID) Parameters used in RMCP Message types Node types Control types Sub-control types Codes for reasons and results Reason code Result code Timer related parameters Parameters for neighbor discovery Parameters for heartbeat Parameters for report Parameters for HMA related operation Parameters for maintenance of Edge-tree Parameters for session leave Data profile Annex A N-plex real-time data delivery schemes A.1 Overview A.2 IP in IP encapsulation scheme A.3 RMCP-3 header scheme Annex B N-plex reliable data delivery schemes B.1 Reliable data delivery - Data profile-based transmission scheme... 74

5 - 5 - B.1.1 Issues for data profile-based transmission scheme B.1.2 Data profile-based transmission scheme B.1.3 Service data unit (SDU) format B.1.4 Data Profile in data profile-based transmission scheme B.2 Reliable data delivery CoreMA buffering scheme B.2.1 Procedure of CoreMA buffering scheme B.2.2 Datagram flow to preserve original IP packet B.2.3 Data profile using CoreMA buffering scheme... 84

6 - 6 - Introduction This Recommendation International Standard specifies the Relayed Multicast Protocol part 3 (RMCP-3). The RMCP-3 is an application-layer relayed multicast protocol that supports many-to-many multicast data delivery. The RMCP-3 constructs a relayed multicast tree to support many-to-many group services. Through the realization of the RMCP-3, it is possible to support capability of many-to-many data delivery in the IP-based network environment without full deployment of the IP multicast. RMCP-3 provides many-to-many multicast-based service in both unicast and multicast network environment.

7 - 7 - INTERNATIONAL STANDARD RECOMMENDATION ITU-T Information technology Relayed multicast protocol: Specification for N-plex group applications 1 Scope This Recommendation International Standard specifies the Relayed Multicast Protocol part 3 (RMCP-3). The RMCP-3 is an application-layer multicast protocol that supports capability of many-to-many multicast data delivery. The RMCP- 3 constructs a relayed multicast tree used to deliver data from many-to-many multicast-based services. Through the realization of the RMCP-3, it is possible to support capability of many-to-many multicast data delivery in both IP-based unicast and multicast network environment. This Recommendation International Standard specifies the followings: a) Describe the entities, control, and data delivery models of RMCP-3; b) Describe the protocol operation of RMCP-3 for many-to-many multicast data delivery; and c) Define messages and parameters of RMCP-3. 2 Normative references The following ITU-T 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; users of this Recommendation International Standard are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations International Standards and other references listed below. Members of IEC and ISO maintain registers of currently valid International Standards. The Telecommunication Standardization Bureau of the ITU-T maintains a list of currently valid ITU-T Recommendations. Recommendation ITU-T X.603 (2004) ISO/IEC : 2005, Information technology Relayed Multicast Protocol: Framework Recommendation ITU-T X (2007) ISO/IEC : 2008, Information technology Relayed Multicast Protocol Part 2: Specification for simplex group applications IETF RFC 793 (1981), Transmission Control Protocol IETF RFC 768 (1980), User Datagram Protocol IETF RFC 4960 (2007), Stream Control Transmission Protocol IETF RFC 2003 (1996), IP Encapsulation within IP 3 Definitions 3.1 Terms defined elsewhere This Recommendation International Standard uses the following terms defined in Rec. ITU-T 603 ISO/IEC : IP multicast: Realizes a multicast scheme in the IP network with the help of multiple several multicastenabled IP routers Multicast: A data delivery scheme where the same data unit is transmitted from a single source to multiple destinations in a single invocation of service Multicast Agent (MA): Intermediate node which relays group application data N-plex: Wherein anyone can send something, and, if someone does so, all others may receive it Parent multicast agent (PMA): Next upstream MA in the RMCP data delivery path.

8 RMCP session: A set of MAs which configures the data delivery path using RMCP. This Recommendation International Standard uses the following terms defined in Rec. ITU-T ISO/IEC : Child multicast agent (CMA): Next downstream MA in the RMCP data delivery path Relayed multicast: A multicast data delivery scheme that can be used in unicast environments, which is based on the intermediate MAs to relay multicast data from the media server to media players over a tree hierarchy Relayed Multicast Protocol (RMCP): A control protocol that supports and manages the relayed multicast data transport 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.2 Terms defined within this Recommendation International Standard For the purposes of this Recommendation International Standard, the following definitions apply Core domain: The top-level domain consisting of group of Core multicast agents and the Session Manager Core multicast agent (CoreMA): A dedicated MA that configures the RMCP-3 core domain Core-ring: A ring topology consisting of CoreMAs and the Session Manager in the core domain Edge domain: The bottom-level domain consisting of a group of EdgeMAs Edge multicast agent (EdgeMA): An MA that configures the RMCP-3 edge domain Edge-tree: A tree topology consisting of zero or more Edge multicast agents and a single Core multicast agent with the Core multicast agent being the root node Head multicast agent (HMA): The head of the Multicast Agents in a local multicast network which relays multicast data to its local multicast network Hybrid-tree: A mixed topology with the Core-ring and Edge-trees Rootpath: The RMCP-3 control path starting from the Core multicast agent to pertaining Multicast Agent in Edge-tree or from first Core multicast agent adjacent to the Session Manager to pertaining Core multicast agent in Corering. 4 Abbreviations For the purposes of this Recommendation International Standard, the following abbreviations apply. 4.1 Abbreviations of RMCP-3 messages FAILCHECK Failure check request HANNOUNCE Head Multicast Agent announce HHB Horizontal heartbeat HLEAVE Head Multicast Agent leave HSOLICIT Head Multicast Agent solicit LEAVANS Head Multicast Agent answer LEAVREQ Leave request PPROBANS Parent probe answer PPROBREQ Parent probe request RELANS Relay answer RELREQ Relay request

9 - 9 - STANS STREQ SUBSANS SUBSREQ TERMANS TERMREQ VHB Status report answer Status report request Subscription answer Subscription request Termination answer Termination request Vertical heartbeat 4.2 Abbreviations of non-messages CoreMA Core-ring CMA EdgeMA Edge-tree HMA MA MAID PMA RMCP SCTP SDL SID SM TCP UDP 5 Conventions Core Multicast Agent RMCP-3 Core Ring Child Multicast Agent Edge Multicast Agent RMCP-3 Edge Tree Head Multicast Agent Multicast Agent Multicast Agent Identification Parent Multicast Agent Relayed Multicast Protocol Stream Control Transmission Protocol Specification and Description Language Session Identification Session Manager Transmission Control Protocol User Datagram Protocol Code values for message parameters in Clause 8 (RMCP-3 messages) and Clause 9 (Parameters) are expressed in hexadecimal notation, e.g. 0x14 for 20 in decimal notation. 6 Overview The Relayed Multicast Protocol part 3 (RMCP-3) is an application-layer multicast transport protocol for providing efficient N-plex (many-to-many) group communication services over IP-network environment which does not have full IP multicast deployment. This clause gives an overview of the RMCP-3 service, entities, protocol and control modules, N-plex data delivery model, and messages. 6.1 RMCP-3 service The RMCP-3 is an application-layer multicast protocol that supports various N-plex group communication services in IP networks without full IP multicast deployment. In N-plex group communication services, user data may be delivered from multiple senders to multiple recipients. To support the N-plex group communication, the RMCP-3 uses the relayed multicast mechanism. The RMCP-3 entities configure data delivery path for N-plex group communications. The RMCP-3 entities relay multicast data to other RMCP-3 entities along the constructed data delivery path. The RMCP-3 can support various application services that require N-plex group communications such as video conference, network gaming, whiteboard, and panel discussion. There can be two types of N-plex group communications, one such type would be the video conference service in which every participant can send and receive multicast data, simultaneously. The other type would be the panel discussion service in which only few participants are able to send multicast data and the rest of the participant can only receive multicast data. The RMCP-3 can support both types of N-plex group communications.

10 Figure 1 shows a typical service model of the RMCP-3 for supporting N-plex group communications services in both unicast and multicast network. In RMCP-3, the local network where IP multicast capability is deployed is called a multicast network. One such example of multicast network is a campus network with IP multicast capability deployed. For multicast network, the RMCP-3 constructs multicast bi-directional transport connection. The network without IP multicast capability is called a unicast network. For unicast network, the RMCP-3 constructs unicast bi-directional transport connection between MAs. Thus, it is possible for RMCP-3 to deliver multicast data to applications in both unicast network and multicast network. Figure 1 RMCP-3 service model The entities of the RMCP-3 are session manager (SM) and multicast agent (MA). The SM manages the group membership and RMCP-3 session by providing information to MA to construct N-plex relayed multicast network and by monitoring the RMCP-3 session. The MA is an intermediate node that delivers multicast data. The following features of the RMCP-3 support the N-plex group communications. a) The RMCP-3 constructs a logical control path for each session by using one or more MAs. b) The control path is basis of the data delivery path, which supports the delivery of multicast data in a reliable or real-time manner. c) The control path consists of logical links between MAs. d) The RMCP-3 has the capability of selecting optimal peers to configure logical links. The selection of optimal peers may be based on various metrics. Example of such metrics includes hop count, delay, and/or bandwidth. e) The RMCP-3 supports IP multicast. f) The RMCP-3 allows participants to join or leave at any time during the RMCP-3 session. g) The RMCP-3 manages the participants of RMCP-3 session by using membership monitoring and expulsion. h) The RMCP-3 provides auto-configuration mechanism in constructing the data delivery path for the N- plex group communication. i) The RMCP-3 provides network fault detection and service recovery. 6.2 RMCP-3 entities This clause provides description of RMCP-3 entities, which are SM and MA. The RMCP-3 entities follow the same definition as defined in [ITU-T X.603]. SM manages group membership and RMCP-3 sessions. MA constructs multicast data delivery path between senders and receivers and relays the multicast data along the constructed path. MA

11 is required to support capabilities in both sending and receiving of the multicast data. MA can be implemented as an end-system, server, or hardware set-top box. The method of implementation of the MA are out of scope of this Recommendation International Standard. RMCP-3 configures the data delivery path for N-plex group communications using the following configuration: a) One SM; b) One or more MAs; c) One or more sending and receiving applications. SM supports the following functions: a) Session initiation; b) Session termination; c) Membership management; d) Session management. MA supports the following functions: a) Session subscription; b) Session join; c) Session leave; d) RMCP-3 Edge-tree construction and maintenance; e) Data delivery. 6.3 Protocol modules of RMCP-3 The entities in the RMCP-3 use two different types of module, i.e., control module and data module. The control module is used to control RMCP-3 session. The data module is used to deliver multicast data to the data module. SM controls the RMCP-3 sessions and does not participate in data delivery. Therefore, SM has only the control module. MA constructs path for control and data delivery, so, MA has both modules i.e., control module and data module. Figure 2 shows the three types of path and interfaces that are used in RMCP-3. Control path between control modules of SM and MA and between control modules of MAs; Data path between data modules of MA; Internal interface between control module and data module within MA. Figure 2 Three types of interfaces in RMCP-3

12 Figure 3 shows the protocol stack for SM. SM exchanges messages with MAs to control and manage the RMCP-3 session. The messages used by SM need to be delivered in reliable manner to provide stable RMCP-3 session. For reliable delivery, SM uses TCP [IETF RFC 793] for transport protocol. Figure 3 Protocol stack of SM Figure 4 shows the protocol stack for MA with control module and data module. The control module of MA configures the RMCP-3 control path through exchanges of messages with SM and other MAs. The MA s control module uses TCP in the unicast network and UDP [IETF RFC 768] in the multicast network. The data module of MA relays the multicast data along the constructed data delivery path. The characteristics of the data delivery channel may vary depending on the application. For example, real-time data delivery channel is needed for real-time application services, and reliable data delivery channel is needed for reliable application services. Thus, RMCP-3 is independent of the transport protocols for delivering user data to support various types of applications. The multicast application of MA can send and receive multicast data from data module. 6.4 RMCP-3 control model Figure 4 Protocol stack of MA The RMCP-3 configures a Hybrid-tree for control connection that is based on the RMCP-2[ITU-T X.603.1] one-tomany tree. The RMCP-2 tree is suitable for multicast data delivery and is robust to network fault with autoconfiguration and self-improvement capability. The RMCP-2 tree can be extended and be used in the Hybrid-tree. The Hybrid-tree uses multiple RMCP-2 one-to-many trees for N-plex group communications. The Hybrid-tree has two-level hierarchy. The bottom level is a one-to-many tree, which is called the Edge-tree. This is similar tree used in the RMCP-2. The Edge-tree consists of edge multicast agent (EdgeMA) and core multicast agent (CoreMA). The CoreMA is the root of the Edge-tree. The top level of the Hybrid-tree is a Core-ring, which consists of CoreMA and SM. The SM constructs the Core-ring. The two-level hierarchy corresponds to the two RMCP-3 domains, which are the core domain and the edge domain. The core domain is a top-level network of Core-ring. The edge domain is the bottom level of Edge-trees.

13 The Hybrid-tree is controlled by SM. The SM can configure, control, and monitor the Hybrid-tree. The SM has the complete list and the connection status of the CoreMA of the RMCP-3 session. Figure 5 shows a control connection in the core domain. SM C C C CoreMA SM Session Manager C C Ring control connection C CoreMA control connection Figure 5 Control connection in the core domain The followings are the control connections in the core domain: Ring control connection from SM to one or more CoreMAs; CoreMA control connections between SM and each CoreMAs. The Edge-tree consists of multiple EdgeMAs with CoreMA as a root node. The SM can directly monitor and control Edge-trees by controlling each MA in the Edge-tree Figure 6 shows the control connection in the Edge-tree. SM SM Session Manager E E C E E E E E C EdgeMA CoreMA Tree control connection CoreMA control connection Session control connection Figure 6 Control connection in the edge domain The Edge-tree consists of CoreMA and zero or more EdgeMAs. The following are the control connections for the edge domain: Tree control connections between MAs forming Edge-tree; Session control connection between SM and MAs. SM and CoreMAs are fixed and dedicated devices that are initially installed by the RMCP-3 service operator. These entities provide control and data delivery path for applications serviced by EdgeMA. The EdgeMA is a dynamic entity that can join and leave RMCP-3 session. Thus, the SM and CoreMAs are configured before the initiation of the RMCP- 3 service. Note, however, that this specification does not specify how the CoreMAs are installed, because, it is implementation and design issues that should be defined by the RMCP-3 service operator at the beginning of the RMCP-3 service. The RMCP-3 service operator needs to assign adequate number of CoreMAs according to the anticipated size of multicast-

14 based services and position the CoreMAs in a suitable part of the network. The method of constructing RMCP-3 core domain is strictly dependent on the service provided and is out of scope of this document. 6.5 N-plex data delivery model of RMCP-3 The top-level topology for N-plex data delivery can be different from the topology for RMCP-3 control connection. The top-level topology for RMCP-3 control connection is in form of a ring, i.e., Core-ring. However, the top-level topology of N-plex data delivery may be of any structure, such as a mesh as shown in Figure 7 or as a ring as shown in Figure 8. The reason for having different top-level topology is that RMCP-3 is used to construct RMCP-3 control connection. Therefore, the topology for N-plex data delivery does not have to be equivalent with the topology for RMCP-3 control connection. For Edge-tree, the control path and the data path is equivalent since it is difficult to construct different topology for data delivery for Edge-tree, which can be contently changing during the RMCP-3 session. The n-plex data delivery model can vary with the type of application used. Thus, this Recommendation International Standard does not define any data delivery model. The informative Annexes A and B gives examples of n-plex data flow mechanisms that can be used with the RMCP-3. The basic RMCP-3 data delivery model is shown in Figure 7 and Figure 8. The EdgeMA is the sender and a receiver of n-plex group communication. If an EdgeMA wants to send multicast data, it sends the multicast data directly to its CoreMA and to its Child MAs (CMAs). The CoreMA relays the multicast data to EdgeMAs in its Edge-tree and to other CoreMAs along the data delivery path, which can have mesh or ring topology in the core domain. The receiving CoreMA relays the multicast data to its EdgeMA in the Edge-tree. Figure 7 shows a data delivery model where CoreMAs form the full mesh topology. In this case, the CoreMA only relays the multicast data originated from its own edge domain. Figure 7 shows data delivery flows for the multicast data from EdgeMA E1, which is shown in solid line, and EdgeMA E2, which is shown in dotted line. Figure 7 RMCP-3 data delivery model with mesh-linked core-domain Figure 8 shows a data delivery model based on the Core-ring. Each CoreMA relays the multicast data to both directions of the Core-ring, except for the last CoreMA, which is connected to the SM. The last CoreMA does not relay the data to SM, since, the SM does not receive or relay multicast data. Figure 8 shows data delivery flows for the multicast data from EdgeMA E1, which is shown in solid line, and EdgeMA E2, which is shown in dotted line.

15 Figure 8 RMCP-3 data delivery model with ring-linked core-domain This Recommendation International Standard assumes the use of RMCP-3 data delivery model with ring-linked coredomain to simplify the description of the RMCP-3 operations. 6.6 Types of RMCP-3 messages Table 1 lists the RMCP-3 messages with its meaning and the operation that is used. Table 1 RMCP-3 messages Messages Meaning Operation SUBSREQ SUBSANS PPROBREQ PPROBANS HSOLICIT HANNOUNCE HLEAVE RELREQ RELANS STREQ STANS Subscription request Subscription answer Parent probe request Parent probe answer HMA solicit HMA announce HMA leave Relay request Relay answer Status report request Status report answer Session subscription Neighbor discovery Management for multicast enabled network Data channel control Session monitoring LEAVREQ Leave request Session leave/ LEAVANS Leave answer Session tree reconstruction TERMREQ TERMANS Termination request Termination answer Session termination HHB Horizontal heartbeat Core-ring maintenance VHB Vertical heartbeat Edge-tree maintenance FAILCHECK Failure check request Failure check request

16 7 Protocol operation This clause gives detailed description of the protocol operation of RMCP-3 entities, which are SM, CoreMA, and EdgeMA. The three entities form a Hybrid-tree to provide multicast capability in non-multicast IP-based network. Figure 9 shows an example RMCP-3 Hybrid-tree that is used in clause 7 to assist the readers in understanding the protocol operation of the RMCP-3. Figure 9 Example RMCP-3 Hybrid-tree Example RMCP-3 Hybrid-tree consists of four CoreMAs with each forming its own Edge-tree. The CoreMA A is the root of Edge-tree A with two EdgeMAs connected in a row. The CoreMA B is the root of Edge-tree B with five EdgeMAs. Four of the five EdgeMAs forms a local multicast network with EdgeMA B-2 being the Head Multicast Agent (HMA). The CoreMA C is the root of the Edge-tree C with four EdgeMAs forming a binary tree. CoreMA D is the root of the Edge-tree D with five EdgeMAs positioned in a row. The example RMCP-3 Hybrid-tree is used in this clause to assist in understanding the operation of the RMCP SM s operation SM (Session Manager) manages and controls service sessions through functions of session initiation, session monitoring, membership control, and session termination Session initiation The SM supports the creation of a new RMCP-3 session Normal procedure The SM supports the creation of a new session upon reception of the SUBSREQ message with proposed session identification (SID) from an EdgeMA. The format and detailed description of SID are in If the proposed SID is unique, SM creates a service session with the proposed SID and answers using a SUBSANS message with the SID and MAID of the requesting EdgeMA.

17 Handling SID duplication The SID includes multicast address used in multicast applications. However, the proposed SID can be in use by other on-going RMCP-3 session. Use of duplicate multicast address can cause problem in multicast-based service, since the receiving entity will be receiving unwanted multicast data. If the proposed SID is already used by other session, the SM should reject the subscription request and notify the EdgeMA that the SID is already used. SM creates a unique SID with new multicast address and returns the response (SUBSANS message) with a proposed SID that can be used in the new SUBSREQ message Session subscription The SM supports EdgeMA to join the RMCP-3 session. Figure 10 shows the flow of the RMCP-3 session subscription. To subscribe to the RMCP-3 session, EdgeMA sends a SUBSREQ message to the SM. SM makes decision whether or not to accept the EdgeMA s request. If the request is accepted, SM responds with SUBSANS message containing RE_OK result code (see 9.3.2) and information for RMCP-3 session join. If not, it returns a SUBSANS message with an adequate result code MAID allocation Figure 10 RMCP-3 session subscription To be identified in the RMCP-3 session, each MA, which are EdgeMA and CoreMA, needs to have a unique MAID. The MAID is proposed by MA and be confirmed by SM. If the proposed MAID is null or is already in-used by other EdgeMA, SM creates a unique MAID and sends the response message with the created MAID. The MAID can be generated from the IP address and port number of the requesting MA. The format and detailed description of MAID are in Content of successful SUBSANS message If SM decides to accept the MA subscription, it responds with SUBSANS message containing RE_OK result code, confirmed MAID, and neighbor list. For the neighbor list, SM can provide a complete list of CoreMAs or partial list of CoreMAs that are adequate for the subscribing EdgeMA Session monitoring The SM supports monitoring of CoreMA and EdgeMA, which are participating in the RMCP-3 session. SM can acquire status information for each MA. If the SM needs status information of a specific MA, it issues an STREQ message to the pertaining MA. The MA responds with an STANS message containing the requested information. Figure 11 shows procedure of monitoring a specific MA. The T_REPORT is the maximum waiting time for STANS message. The T_REPORT is defined in If the STANS message does not arrive within the T_REPORT time, SM considers that the pertaining MA has left the RMCP-3 session.

18 Failure check and handling Figure 11 MA monitoring (status report) The SM supports the failure check of MAs. SM maintains a list of active MAs in the RMCP-3 session. If MA fails, neighboring MA can detect the failure and reports to SM through a FAILCHECK message. SM sends a STREQ message to the reported MA. If the MA fails, it cannot send a STANS message to SM. After T_REPORT timeout, SM deletes the failed MA from the active MA list. Figure 12 shows the procedure of MA failure check. Figure 12 MA failure check If more than two MAs report of failure for the same MA, SM takes action on the first report and ignores the rest Member expulsion The SM supports the membership control of EdgeMAs to increase manageability of the RMCP-3 service. The membership control is supported through session monitoring as described in and membership control of EdgeMAs through expulsion. SM can expel a specific EdgeMA for administrative purpose. SM expels a specific EdgeMA by sending a LEAVREQ message with the reason code of SM_KICKOUT (see 9.3.1). The EdgeMA replies with a LEAVANS message and notifies its connected PMA (Parent Multicast Agent) and CMAs before leaving the session. This notification procedure is needed for Edge-tree reconstructions. The detailed procedure for EdgeMA leave is described in The message flow of SM s expulsion of EdgeMA A-1 is shown in Figure 13, which is based on Edge-tree A from Figure 9.

19 Horizontal Heartbeat Figure 13 SM s expulsion of EdgeMA A-1 SM checks the status of the Hybrid-tree by periodically sending a message through the Hybrid-tree. This message is called a heartbeat message. The heartbeat procedure ensures service continuity in RMCP-3 by assisting MAs to synchronize information of the rootpath. Since, the Hybrid-tree is in the form of combined structure, there are two types of heartbeat message. First type is a HHB (horizontal heartbeat) message, which is a heartbeat message used in the Core-ring. The second type is a VHB (vertical heartbeat) message, which is used in the Edge-tree. The vertical heartbeat is described in The HHB message is used to check the link status of the Core-ring. The HHB message is used for followings: Check the activeness of CoreMA; List the CoreMAs making up the Core-ring. The horizontal heartbeat procedure starts with SM transmitting an HHB message to the adjacent CoreMA of the Corering in one direction. The CoreMA propagates the HHB message to its adjacent CoreMA along the Core-ring. Eventually, the SM will receive the HHB message sent by the last CoreMA, and it will know the status of each CoreMA along the Core-ring. If the SM fails to receive the HHB message, it knows that the Core-ring has failed. Normal horizontal heartbeat procedure is shown in Figure 14, which is based on the Core-ring from Figure 9. The SM sends HHB message to the adjacent CoreMA, which is CoreMA A. The CoreMA A appends its information to the received HHB message and forwards the modified HHB message to the next CoreMA, which is CoreMA B. The HHB message is relayed along the Core-ring and is returned to the SM within the heartbeat message interval (i.e., T_HB). The T_HB is defined in Session termination Figure 14 Normal horizontal heartbeat The SM can terminate the on-going RMCP-3 session for administrative reasons. Figure 15 shows the detailed procedure of the RMCP-3 session termination, which is based on the Hybrid-tree in Figure 9. To terminate the RMCP-3 session,

20 SM sends TERMREQ message to each of the CoreMAs in the Edge-tree. The details of session termination process by each CoreMA are described in CoreMA s operation Figure 15 Session termination CoreMA (Core Multicast Agent) is a dedicated MA that realizes the N-plex multicast-based service. The dedicated feature of the CoreMA enables the RMCP-3 service to be scalable and robust. The MAs join and leave the RMCP-3 session anytime. Since MA can be developed in the end-system, such method can cause network faults such as loop and network partitioning. To overcome such problem, RMCP-3 defines a reliable and manageable CoreMA. The followings summarize the role of CoreMA in RMCP-3. Provide scalability of the RMCP-3 session; Provide distributed management by acting as the root node of Edge-tree; Provide bidirectional data delivery. The CoreMA has CoreMA-only functions and PMA function. CoreMA can be a PMA to EdgeMAs and needs to provide equivalent functions of PMA to its CMAs. The functions of PMA will be described in 7.3. This clause describes the detailed operations of CoreMA-only functions Initiation The SM and CoreMAs in the Core-ring are static entity and do not change during the RMCP-3 session. However, it is possible for the CoreMA to be terminated during the RMCP-3 session for administrative purpose. Since the CoreMAs are static entities, SM has the complete list of CoreMAs in the RMCP-3 session. SM monitors and controls Core-ring through control of each CoreMA Support for RMCP-3 join of EdgeMA The CoreMA supports EdgeMA to join the RMCP-3 session. After the EdgeMA subscribes to a session, it needs to select an appropriate CoreMA to join. The EdgeMA sends a PPROBREQ message to each CoreMAs in the list given by SM. The CoreMA returns a PPROBANS message with a list of EdgeMAs in its Edge-tree for the requested session along with other information to be used in joining the Edge-tree. With the received information from CoreMA, EdgeMA can continue with the neighbor discovery procedure described in

21 7.2.3 Maintenance The RMCP-3 has scalability using CoreMAs. The Hybrid-tree of RMCP-3 combines multiple Edge-trees with a CoreMA being the root of an Edge-tree. To provide stable RMCP-3 service, Hybrid-tree is required to guarantee integrity. RMCP-3 provides the following functions to guarantee stable RMCP-3 service: Function to check the activeness of each logical link that constitutes the Core-ring; Function of monitoring the status of each CoreMA; Function of notifying SM of the status of Core-ring Two level heartbeat The heartbeat procedure is initiated by SM as described in The CoreMA propagates the received HHB message to its adjacent CoreMA in the Core-ring. Figure 16 Two-level heartbeat flow As the CoreMA propagates the HHB message to its neighboring CoreMA, it also initiates the vertical heartbeat procedure. The CoreMA sends the vertical heartbeat (VHB) message to its CMA, which are EdgeMA(s). The VHB message is propagated along the Edge-tree. This is the two-level heartbeat scheme. The heartbeat flow for Edge-tree A is shown in Figure 16. As shown in Figure 17, HHB message are propagated along the Core-ring, while the VHB message are propagated along the Edge-tree. The receiver of the HHB or VHB message must attach its information in the ROOTPATH control before propagating the message in the regular heartbeat message Fault handling procedure Figure 17 Two-level heartbeat path If one of the CoreMA or the link between the CoreMAs has faults, the periodic HHB message will not be returned to the SM within T_HB. If a CoreMA fails to receive HHB message within T_HB, it needs to initiate fault handing procedure.

22 Figure 18 Fault handling procedure Figure 18 assumes that the network fault has occurred between CoreMA A and CoreMA B from Figure 9. As a routine procedure, SM sends an HHB message to CoreMA A. The CoreMA A propagates the HHB message to CoreMA B. Since the connectivity between the CoreMA A and CoreMA B is lost, the CoreMA B will fail to receive the HHB message. After heartbeat message timeout, CoreMA B will recognize fault and starts fault handling procedure. The heartbeat message timeout is defined in The fault handling procedure involves two steps: (1) reporting fault to SM, and; (2) propagating fault report to the adjacent CoreMAs. To report fault to SM, CoreMA B sends FAILCHECK message to SM indicating problem of CoreMA A. CoreMA B sends pseudo HHB message (shown as HHB* in Figure 18) to the subsequent CoreMA to notify faults. The pseudo HHB message is an HHB message with PSEUDO_HB control Preventing fault report chain effect When a CoreMA tries to handle network partition, other CoreMAs in Core-ring may start fault handling procedure, since every CoreMAs has equivalent T_HB, which is defined in This causes SM to be imploded with the several reports sent by subsequent CoreMAs in the Core-ring for the same failure. Therefore, CoreMA needs to prevent fault report chain effect by setting longer T_HB compared to the preceding CoreMA. Figure 19 shows how the T_HB is set for each CoreMA based on the sequential order in the Core-ring Session termination Figure 19 T_HB setting in the Core-ring The session termination is a subsequent procedure to Figure 15 shows the procedure for session termination. The CoreMA receives TERMREQ message from SM. It responds with TERMANS message and subsequently forwards the TERMREQ message to its EdgeMA in the Edge-tree. The details of session termination in the Edge-tree are described in

23 7.2.5 Fault detection in the core domain CoreMA and SM can have fault. To provide robust service, RMCP-3 should handle such failure. For SM failure, CoreMA that is directly connected to SM can detect SM failure, since it will fail to receive the periodic HHB message from the SM. If SM fails, RMCP-3 session must be terminated. It is impossible to provide robust RMCP- 3 service with a failed SM. The termination process is equivalent to session termination described in The CoreMA fault can be detected with the horizontal heartbeat procedure described in Although the recovery procedure is very important in maintaining the resilience and efficiency of the Core-ring, this specification does not describe the details of the Core-ring recovery procedure. The reason is that CoreMAs are fixed entities and needs to be configured by the RMCP-3 service operator. Thus, if fault occurs in the core domain, SM will need to terminate the RMCP-3 service. 7.3 EdgeMA s operation A user is provided with the N-plex multicast-based service through EdgeMA (Edge Multicast Agent). Unlike CoreMA, EdgeMA can dynamically join or leave the RMCP-3 session. The following summarizes the capabilities of EdgeMA in the RMCP-3. Session subscription; Dynamic joins and leaves of RMCP-3 session; Auto-configuration to form Edge-tree; Bidirectional data relay; Fault detection and recovery in Edge-tree. Some functions of EdgeMA should also be provided by CoreMA. The functions that also pertain to the capability of CoreMA will be indicated in the description Session initiation Since the RMCP-3 provides the N-plex group communication, each EdgeMA can be a sender or a receiver of the subscribed session. However, one EdgeMA should initiate the RMCP-3 session. Figure 20 Session initiation duplicated SID EdgeMA initiates new session by sending a SUBSREQ message with a proposed SID, which is defined in In Figure 20, the first attempt is failed since the proposed SID is already used by other session. Thus, SM sends a SUBSANS message with indication of session initiation failure and includes a modified SID, which can be used in the new session. The EdgeMA retransmits the SUBSREQ message with different SID. Different SID can be the modified SID proposed by SM. Upon receiving the SUBSREQ message, SM may decide to accept the request and creates a new session. After session creation, SM sends a SUBSANS message including session related information e.g. confirmed SID of the session. After the successful RMCP-3 session initiation, the user of the EdgeMA announces the RMCP-3

24 session along with the confirmed SID through web page, , etc. Then, other EdgeMAs can subscribe to a newly established session Session subscription The EdgeMA needs to subscribe to the RMCP-3 session. The EdgeMA can get the RMCP-3 session information through various methods, such as web page, , etc. The EdgeMA sends a SUBSREQ message with proposed MAID to SM to subscribe to the RMCP-3 session as shown in Figure 21. SM decides to accept or deny the session subscription request by the EdgeMA. The SM checks the MAID proposed by EdgeMA to prevent duplication use of MAID. Once the SM decides to accept the subscription, bootstrapping information is given to the EdgeMA through the SUBSANS message, which contains the result of the subscription, confirmed MAID, and a list of CoreMAs. On receiving successful SUBSANS message, EdgeMA initiates the neighbor discovery to find an appropriate MA to join. If the SM decides not to accept the EdgeMA s session subscription, it also returns the SUBSANS message containing the reason for denial Neighbor discovery Figure 21 EdgeMA s subscription The neighbor discovery procedure enables the EdgeMA to discover the most appropriate neighbor to join. The EdgeMA can exist either in unicast network or in multicast network. The neighbor discovery procedure differs according to the network type, which is described in the following sub-clauses. In the multicast network, the only one EdgeMA needs to join the session tree. The node that joins the session tree in the multicast network is called Head Multicast Agent (HMA). An example of a local multicast network is LAN multicast network, a small-sized network where IP multicast is enabled. In the unicast network, the EdgeMA needs to perform RMCP-3 operations to represent itself in the RMCP-3 network. Examples of the such network includes LAN and WAN where IP multicast is disabled Neighbor discovery in the local multicast network This capability enables the EdgeMA to find the neighboring EdgeMAs inside local multicast network. RMCP-3 makes efficient use of the IP multicast. Therefore, finding neighbors in the local multicast network is conducted before finding neighbors in the unicast network Role of HMA In the multicast network, only one EdgeMA, which is defined as HMA, participates in the RMCP-3 session. The HMA relays the multicast data to the local multicast network. Non-HMAs in the multicast network does not need to perform RMCP-3 operations, since it will be receiving multicast data from the HMA. However, those EdgeMAs need to be aware of the operational status of the HMA, since it is possible for the HMA to leave the RMCP-3 session. Multicast data generated outside of the local multicast network is received by the HMA. HMA relays the multicast data to the local multicast network. Multicast data generated inside the local multicast network will be relayed by the HMA to other MAs in the RMCP-3 session HMA discovery A new EdgeMA in the local multicast network needs to find the HMA of the multicast network. The HMA solicitation and announcement enables the EdgeMA to discover the HMA in the local multicast network.

25 The procedure of HMA solicitation and announcement for EdgeMA B-5, a new subscriber, is shown in Figure 22. The EdgeMA B-5 multicasts the HSOLICIT message using a predefined multicast address. The predefined multicast address is used inside the local multicast network to exchange HSOLICIT, HANNOUNCE, and HLEAVE messages. It is included in the CTRLCHANNEL control of the SUBSANS message. If HMA exists, the HMA multicasts the HANNOUNCE message as a response to the local multicast network. Upon receiving the HANNOUNCE message, EdgeMA B-5 will stop neighbor discovery and acknowledges the existence of the HMA HMA election Figure 22 HMA solicitation and announcement The new HMA election can occur when there is no HMA in the local multicast network. There are two occasions for HMA election, first occasion is when single EdgeMA exists in the local multicast network and second occasion is when HMA leaves the RMCP-3 session. Initially, the local multicast network does not have any HMA. If new EdgeMA joins the RMCP-3 session, it goes through the HMA election procedure. HMA election is initiated by multicasting HSOLICIT message to the local multicast network. Since the EdgeMA is the only node in the local multicast network, it will fail to receive any HANNOUNCE message within the HANNOUNCE message timeout. The HANNOUNCE message timeout is defined in If a single EdgeMA exists in the local multicast network, EdgeMA does not perform the HMA functions. The reason is that no other EdgeMA needs to receive the multicast data in the local multicast network. The EdgeMA functions as the EdgeMA in the unicast network. However, if new EdgeMA in the same multicast network joins the RMCP-3 session, the original EdgeMA becomes the HMA by answering to the HSOLICIT message sent from the new EdgeMA. Another occasion for HMA election is when an HMA decides to leave the RMCP-3 session. The remaining EdgeMAs compete in the HMA election. Figure 23 shows how the EdgeMA B-2 becomes a new HMA in a local multicast network. Each EdgeMA has its own HSOLICIT message retransmission interval (T_HSOLICIT), which is T_HSOLICIT plus a criteria factor, to prevent flooding of the HSOLICIT message. The criteria factor can be derived from various factors such as the distance from CoreMA, IP address, etc.

26 Figure 23 HMA election As shown in Figure 23, the EdgeMA B-2 has the shortest T_HSOLICIT. The EdgeMA B-2 multicasts the HSOLICIT message to the local multicast network after the expiration of its T_HSOLICIT timer. Other EdgeMAs (i.e., EdgeMA B-3, EdgeMA B-4, and EdgeMA B-5) will be receiving the HSOLICIT message and suppress sending the HSOLICIT message and restart their T_HSOLICIT timer. The EdgeMA B-2 will wait for the HANNOUNCE message for T_HANNOUNCE time. Since there is no answer, EdgeMA B-2 sends the HSOLICIT message, again, for N_HSOLICIT times. The EdgeMA B-2 will know that there is no HMA in the multicast network. It becomes the HMA by multicasting the HANNOUNCE message to the local multicast network. NOTE T_HSOLICIT, N_HSOLICIT, and T_HANNOUNCE are defined in Handling HANNOUNCE message contention An EdgeMA that has already sent an HANNOUNCE message can receive HANNOUNCE message from other EdgeMA. This can occur when two or more EdgeMAs multicast HANNOUNCE message, almost simultaneously. In such case, one EdgeMA has to be selected as the HMA. Figure 24 shows HMA contention with both EdgeMA B-2 and EdgeMA B-4 having the same T_HANNOUNCE, which results in HMA contention. To resolve this, second criteria is defined for HMA election, which is the use of MAID. EdgeMA B-2 and EdgeMA B-4 have different MAID with EdgeMA B-2 having smaller MAID than EdgeMA B-4. Since EdgeMA B-2 and EdgeMA B-4 have the same T_HANNOUNCE, both EdgeMAs issue HANNOUNCE message after sending HSOLICIT message for N_HSOLICIT times. Upon receiving the HANNOUNCE message from other EdgeMAs, each EdgeMAs make decision on HMA selection according to the second criteria, which is MAID. As a result, EdgeMA B-2 will be selected as the new HMA.