WO2006049448A1

WO2006049448A1 - Method and apparatus for configuring and managing a robust overlay multicast tree

Info

Publication number: WO2006049448A1
Application number: PCT/KR2005/003708
Authority: WO
Inventors: Ju Young Park; Eun Sook Kim; Ei Yeon Kwon; Shin Gak Kang; Ok Jo Jeong
Original assignee: Electronics And Telecommunications Research Institute
Priority date: 2004-11-06
Filing date: 2005-11-04
Publication date: 2006-05-11

Abstract

Provided is a method and apparatus for configuring and managing an overlay multicast data delivery tree in a transmission network having a SM (session manager) and at least one MA (multicast agent). The method includes the steps of at the MA intending to joining a session, obtaining an active neighbor MA list from the SM; detecting information on QoS infoimation of each neighbor MA in the active neighbor MA list, selecting a MA having the most optimized QoS as a parent MA based on the QoS information of each Neighbor MA in the active neighbor MA list, joining an overlay multicast data communication session through the selected parent MA, periodically receiving HB (heart beat) information having information on a path from a root to the MA and determining whether to perform a parent -switching based on the HB information and parent-switching from the current parent MA to a MA having a better QoS when it is determined to perform the parent-switching

Description

[DESCRIPTION]

[Invention TitIe]

MtIlIOD AND PPARATUS FOR CONFIGURING AND MANAGING A ROBUSl O\FRLA\ MULTICAST TREE

[Technical 1 ield]

The present imention relates to a method and apparatus Tor effecti\el\ configuring and managing a 1 N data delivery tree in an cneilaj multicast cmironraent and more particularly to a method and apparatus for effectivoh confirming and managing a I N overla\ multicast data delivery tree through an end host or server to provide a service of 1 N group data transmission

[Background Art]

Internet transmission methods may be classified into a unicast method in which one sender transmits data to another receiver a broadcast mechanism in which one sender transmits data to all receivers on the same sub network and a multicast mechanism m which at least one sender each transmits data to at least one specific recei\er m the light of a sender and a receiver taking pai t in transmission

In the multicast mechanism all resources and bandwidths of a node can be effectπoly used when the sender simultaneously transmits the same dati to a pluralitN of receivers The multicast mechanism is a mechanism suiLablc foi transmitting application data in gioup communications but until now a multicast technology (or IP multicast) in an Internet environment can be partially employed only in a test bed or some of an intra network a school network or a Lest network The reason why the multicast technology is not completely supported can be exemplified as a problem regarding a cost taken to replace all routers currently pro\ided on an Internet network with multicast enabled routers an address assignment problem and a technical problem regarding a multicast routing protocol and a hardware state management mechanism

As an example of a problematic load of an IP multicast router heaw load is applied to a current IP multicast backbone router in managing a routing table foi members frequentIj subscribing to/leaving from a group However unlike a unicast fixed IP network an actual IP multicast network is a dynamic network frequently varying depending on initiation and termination of an application That is in the IP multicast network an application program subscribes to a known session (a group address a port number and contents) thereby creating a data communication path

\ocordingly in recent vears an overlaλ multicast mechanism has been proposed where multicast is possible using application la\er programs without changing existing Internet equipments The overlay multicast mechanism refers to a kind of a technology of overlay multicast transmission whcie several agents are installed at a present unicast-based Internet and the related sender/receiver and agents are configured in a tree structure so that the sender can tiansmit multicast data to a group of receivers using the agent relaj, function In the overlap multicast transmission mechanism connection is made bv tunneling through a virtual multicast router in a non multicast area where a multicast router is directly not connected to T multicast backbone, therebλ allowing IP multicast between the sender and the receπer

Korean Patent Ko zO0_!-68477 entitled "Method for configuring and managing Internet based

multicast tree discloses a method for configuring the σverlay multicast tree in a unieast environment using an end host or server

However the overlap multicast method has a disadvantage in that because each element is comprised of application programs at end hosts not netwoik equipments it is \cr> difficult to build an overlay multicast emironment similar with the topology of a phvsieal network In an ovei la\ multicast network inter-node distances or network status can be measured onlj through a dispersion method and a link is generated between end hosts not a routei as the network equipment and therefore a network topolog> can be fiequenth changed as a new node frequentl> subscribe/leave In other words there is a drawback in that a ph>sical network emironment cannot be considered upon establishment of the transmission path in the overlap multicast environment therebv causing ineffectiveness and frequent subscription/leaving of end nodes (hosts) mav cause frequent error

[Disclosure]

[Icchnical Problem]

The present invention is directed to a method and apparatus for effectively configuring and managing a multicast data dehverv tree in an ovei la\ multicast environment

The present invention is also directed to a method and apparatus foi configuimg continuously managing and improving a multicast data deliveiλ tree in an overlav multicast environment and when an error occurs detecting and itunering immediateh

[Technical Solution]

One aspect of the present invention is to provide a method for configuring and managing an overlay multicast data delivery tree in a tiansmission network having a SM (session manager) and at least one MA (multicast agent) ihe method comprises the steps of at the MA intending to joining a session (a) obtaining an active neighbor MA list from the SM (b) detecting information on QoS information of each neighbor Ml in the active neighbor MA list (c) selecting a Ml having the most optimized QoS as a parent MA based on the QoS information of each neighbor MA in the active neighbor MA list (d) joining an o\erlav multicast data communication session through the selected parent M\ (e) peiiodically receiving HB (heart beat) information having information on a path from a root to the MA and determining whether to perform a parent switching based on the HB information and (f) parent- switchint; from the current parent MA to a MA having a better QoS when it is determined to perform the parent-switching

*\nothei aspect of the present invention is to provide a method for coril igLii ing and managing an overlay multicast data delivery tree in a transmission network having a session manager (SM) and at least one multicast agent (MA) the method may include the steps of at the SM storing a list of active MAs having joined a session managed bj the SM and being currentIv in a normal operation and a list of read) MAs not vet confirmed whether to normalIv operate in the session receiving a subscription request message from a MA intending to joining the session determining whether to permit subscription of the MA m response to the received subscription request message when it is determined that session subscription is permitted extracting a portion of the active MA list and transmitting a subscription answer message having the extracted portion of the active MA list to the MA when it is determined that the session subscription is rejected transmitting a subscription answer message having a rejection reason to the MA and adding the MA information to the readv MA list

Anothei aspect of the present invention is to provide a multicast agent apparatus including means for obtaining an active neighbor MA list from a SM means for detecting QoS information of each neighbor MA in the active neighbor MA list means for selecting a MA having the most optimized QoS as a parent MA based on the QoS information of each the neighbor MA and joining an overlav multicast data communication session through the selected parent MA means for periodicalIv receiving HB information having information on a path fiom a root to the MA and determining whether to perfoim a parent switching based on the received HB information and means for pirent- switching from the current parent MA to a MA having a better QoS when it is determined to perform the parent-switching

Another aspect of the present invention is to provide a session managei apparatus comprising means for storing a list ot active MAs having joined a session managed bv itself and being currentIv in a normal opeiation and i list of reach MAs not vet confirmed whether normalh opeiatmg in tht session and periodically updating the lists means for receiving i subscription request message from a MA intending to joining the session and determining whether permitting subscription of the MA in response to the subscription request message means for extracting a portion of the active MA list and transmitting to the MA a subscription answer message having the extracted portion of the active MA list, when it is determined to permit session subscription, and transmitting to the MA a subscription answer message having a reiection reason when it is determined to reject the session subscription and means for adding the MA information to the readv M\ list

[Advantageous Effects]

<\s described above according to the present invention, it is possible to establish a robust and effective data transmission path depending on ph\sκal network topologies b> establishing the overlay multicast data transmission path (tiee) through the bootstrapping process of the initial MA and the map discovery process of searching tor information on the neighbor MAs in the o\erla\ multicast cm ironment and then performing the parent switching continuous tree management and error recovery processes

According to the present invention if is possible to provide moie effective service and higher qualitj of service in various group communications recent1\ attiacting attention onlv bv installing software in a personal coinputei without am change of a current Internet infrastructure In particular it is possible to build a data transmission infrastructure irrespective of the number of simultaneous users even in the current Internet network environment by simph installing the program without change of i network environment

While the invention has been shown and described with reference to certain cxemplatv embodiments thereof it will be understood by those skilled in the ait that various changes in form and details may be made therein withouL departing from the spirit and scope of the invention as defined by the appended claims

[Description of Drawings]

FIGS IA and IB illustrate overlay multicast network environments according to the present invention

PIG I IS a block diagram schematical1\ illustrating mam steps in a method for configuring and managing a multicast data deli\er\ tree according to an embodiment of the present invention

I IG \ is a flowchart illustrating a bootstrapping process of a multicast agent (MA) according to a preferred embodiment of the present invention, FIG 4 IS a flowchart illustrating a bootstrapping process of a session manager (SM) according to an embodiment of the present invention FIG. 5 is a structure of a multicast agent (MA) list database (DB) which a SVl maintains for membership management according to an embodiment of the present invention;

FIG. 6 illustrates a structure of a database (DB) which a MA maintains for membership management according to an embodiment of the present invention;

FIG. 7 is a flowchart illustrating a map discovery process according to an embodiment of the present invention^;

FIG. 8 is a flowchart illustrating a parent switching (PS) process according to an embodiment of the present invention;

FIG. 9 is a flowchart in more detail illustrating a PS decision Step 840 of

FIG. 8;

FIG. 10 is a flowchart in more detail illustrating a PS execution step 860 of

FIG. 8;

FIG. 11 is an outline diagram illustrating a tree management operation of a

SM according to an embodiment of the present invention;

FIG. 12 is an outline diagram illustrating a tree management operation of a

MA according to an embodiment of the present invention;

FIG. 13 is an outline diagram illustrating a loop error recovery operation according to an embodiment of the present invention;

FIG. 14 is a flowchart in detail illustrating a loop recovery operation according to an embodiment of the present invention;

FIG. 15 is an outline diagram illustrating a network partitioning error recovery operation according to an embodiment of the present invention; and

FIG. 16 is a flowchart in detail illustrating a network partitioning error recovery operation according to an embodiment of the present invention.

[Mode for Invention]

Hereinafter, an exemplary embodiment of the present invention will be described in detail. However, the present invention is not limited to the embodiments disclosed below, but can be implemented in various types. Therefore, the present embodiment is provided for complete disclosure of the present invention and to fully inform the scope of the present invention to those ordinarily skilled in the art.

FIGS. IA and IB illustrate overlay multicast network environments according to the present invention. Specifically, FIG. IA is a network environment for transmitting real-time multicast data, and FIG. IB is a network environment for transmitting multicast data having a reliable characteristic such as stock data.

As shown in FIGS. IA and IB, the inventive overlay multicast network includes multicast agents (MAs) 120a, 130a, 120b, and 130b for performing relay transmission of the multicast data: and session managers (SMs) HOa and 110b for managing session information and processing a session subscription request from the multicast agent.

The multicast agent (MA) is present in each local subnet which users (nodes) desiring to communicate a specific group data belong to, and serves to transmit the multicast data. The multicast agent may be embodied as software, hardware, or a combination thereof in a personal computer, a server, or other types of data processing systems. In FIGS. IA and IB, the sender-side multicast agents (SMAs) 120a and 120b relay the multicast data, which is generated from a specific node of a subnet to which the SMAs belong, to the receiver-side multicast agents (EAs) 130a and 130b. Channels connecting between the SMAs 120a and 120b and the MAs 130a and 130b can be comprised of real-time/reliable unicast hop-by-hop channels 140a and 140b depending on a characteristic of data.

The session managers HO and HOb manage session information for group communication, and upon receipt of the session subscription request from the multicast agent, determines whether to permit subscription, and upon permitting for the subscription, informs the corresponding multicast agent of a portion of an Active Multicast agent List (MIL). In one embodiment, the session managers HOa and HOb can be embodied as software, hardware, or a combination thereof in an end host or a separate system.

FIG. 2 is a block diagram schematically illustrating main steps in a method for configuring and managing a multicast data delivery tree according to an embodiment of the present invention

\s shown in FIG 2 the present imention begins with a bootstrapping step 210 for allowing the multicast agent (MO to join a session of an σverlav network In the bootstrapping step 210 the MA transmits a session subscription request message to the session manager (SM) and the SM which rceones it from the ¥A determines whether to permit subscription of the MA and upon permitting of the subscription transmits a portion of the active M\ list to the MA The active M\ list is a list of the MAs participating in the session and actively performing communication The active Ms in the list increase m number as the session increases in size Accordingh when the session is large in size the SM cannot provide its entire active MA list to the MAs Thus when the session is large in size the SM extracts onlv a predetermined number of M\s from its entire active MA list and transmits tht extracted M\ list to a new MA The SM can extract from its M<\ list based on the criteiia 1) a high performance server 2) a MA having a high transfer rate and 3) a new MA in this order

The MA joining the session performs a map discover} step 220 to obtain information on neighbor MAs The map distovery step 220 includes a M measuring step 222 for diagnosing a QOS (qualiU of service) such as a transmission delay to the neighbor MAs and a bandwidth and a MA searching step 221 for searching for the neighbor MAs

Next the MA selects the most optimized neighbor WK as its paient M<\ in i parent decision step 230 and it requests the parent MA for data relay in a tree attachment step 240 resulting in an in_tree state n which communication is possible m Step 260 Thereafter when a MA being capable of ιiipro\ing a cuirent state is found the current parent MA may be switched to such a new parent MA m a parent-switching step 250 Ihe MA in the m_trec state continuously repeats the map discovery step 220 and the parent decision step 230 therebλ continuously improving the o\erlay network In Step 270 tree information may be periodically managed and in Step 280 tree management may be performed to recover an error generated in the data delivery tree. Each of the steps will be now described in greater detail. <-n> 44. Bootstrapping (Step 210)

-4-v In the bootstrapping process, the EIs newly joining the session initially obtains information on the overlay multicast network. Hereinafter, the bootstrapping is separately described as the bootstrapping process of the multicast agent (EA) and the bootstrapping process of the session manager (SM).

<46> FIG. 3 is a flowchart illustrating the bootstrapping process of the multicast agent (MA) according to a preferred embodiment of the present invention. The bootstrapping of the MA begins with transmission of a subscription request message (SUBSREQ) to the session manager (SM) in Step 310. Λ subscription answer message (SUBSΛNS) is received from the SM in response to the subscription request message in Step 320. Based on the subscription answer message, it is determined whether session subscription of the MA is permitted or rejected in Step 330. If the SM is determined to reject the subscription, the MA cannot join the session in Step 360. If the SM is determined to permit the subscription, the SM transmits the subscription answer message (SUBSΛNS) having a list of active neighbor MAs, which have been already joined the session, to the MA. The MA extracts and stores the active neighbor MA list in its local storage unit in Step 340, and terminates the bootstrapping in Step 350.

-P_' FIG. 4 is a flowchart illustrating the bootstrapping process of the session manager (SM) according to an embodiment of the present invention. The bootstrapping of the SM begins with receipt of a subscription request message from a new EA in Step 410. Through a control of reception, it is determined whether to permit or reject the subscription in Step 420. If it is determined to permit the subscription of the MA, the SM should inform the MS of bootstrapping information. To this end, the SM extracts some MAs from the Active Multicast agent List (AML) in its multicast agent database (MA_DB) in Step 430. Thereafter, the SM adds the extracted MA information to the subscription answer message (SUBSANS) and informs the MA of the subscription permission in Step 440

4s If it is determined to reject the subscription of the new MA a lejection ieason of rejecting the subscription is prepared in Step 450 and the subscription answer message (SUBSANS) having the rejection reason is transmitted to the MA in Step 460

4⁾ The SM adds the newly joining MA information to a readγ_MA_list (RML) of the MA_DB in Step 470 and prepares to receive a request trom the newIv joining MA in Step 480

M) FIG 5 is a structure of a multicast agent list database (MAJB) which is managed by the session manager (SM) for membeiship management according to an embodiment of the present invention Ihe MΛ_DB 500 consists of two M\ lists one is an active MA list (AMI) 510 of MAs which have joined the session and piobed for ahvcncss bv the SM and a readv MA list (RML) 520 of M\s which have requested for the subscription but have not been probed for aliveness bv the SM

^■> The SM periodically probes the MA lists tor data integrity of the MAJ)B The SM updates information on the IML at every predetermined pei iod In one embodiment the SM raav also arrange the order of MAs in the AMI to provide better bootstrapping information to the MAs Kirthei the SM updates information on the readj_¥A list (RML) at every predetermined period This updating piocess includes steps of confirming whether the MA joining the session actually operates m the session and transiting the MA information from the readv_MA_list (RML) to the active_MA_list (AML) in order to deliver the bootstrapping information to the new MAs

^■> FIG 6 illustrates a structure of a database (DB) maintained b> the MA for membership management according to an embodiment of the present invention Like the SM the MAs manage a Neighbor MA List DB (NLDB) 600 in order to keep information on its neighbor MAs Ihe NLDB 600 mav include root path information 610 for storing a path from a root to itself in its belonging tree a direct node list 620 for storing the information of a parent and children nodes in the tree a probed neighbor MA list (ProbedNL) 630 where QoS thereof is probed and a non probed MA list (NonPtobedNL) 640 where QoS thereof is not vet probed

Ϊ4 MAP Discovery (Step 220)

^■>^■> In the map discovery process the MA discovers the

multicast environment Through the map discovery process the MA obtains the information on the neighbor Ms in the overlay network envπonment

M FIG 7 is a flowchart illustrating the map

process according to an embodiment of the present indention In one embodiment the MAs perform the map

at every certain period The reason of performing the map is that the neighbor MAs that a certain MA recognizes in the overlay network environment are just only parts of the MAs participating in an entire session The MA expands its neighbor MA list thereby selecting a better parent MA in the overlay network For this the MA exchanges its neighbor WK list information with the neighbor MAs thereby performing a M\ searching process i^> The map discoveπ process is initiated from Step 710 in which the MA perfoiming the map discovery selects a to be-probed MA from its neighbor MA list DB (MDB) The selected MA is a MA in the non-probed MA list stored m the NlDB The MA prepares a probe request message (ProbeReq) to be tiansmitted to the selected MA in Step 720 The probe request messαgi includes its neighbor MA information At this time The neighbor information ma> include not onlj the probed M\ information but also the non-probed MA information

^ The MA transmits the probe request message (ProbeReq) to the selected MA in Step 730 and receives a probe answer message (ProbeAns) in response to the probe request message (ProbeReq) in Step 740 The probe answer message ma\ include the selected MVs neighbor MA list, as well as the status information of a tiee to which the selected MΛ currentlv belongs The status information of the tree refers to information on the path from the root to the selected MA and information on its parent node and its children node.

*>> The MA receives the probe answer message (ProbeΛns), and updates its KLDB in Step 750. In other words, the MA stores the information of the selected MA, which has transmitted the probe answer message (ProbeAns), in the probed neighbor MA list (ProbedNL), and adds information on a MA not. included in its probed neighbor MA list (ProbedNL), among the neighbor EA list included in the probe answer message (ProbeAns), to its non-probed neighbor MA list (NonProbedKL), thereby performing the update.

60

(■I> Parent decision (Step 230)

^fO_' After the map discovery process is completed in Step 220, the MA selects the parent MA from the MAs included in the probed neighbor MA list (ProbedNL), performs the tree attachment process of transmitting a data relay request message (RelayRequesl) to the selected parent MA, and receives a relaj- request answer message from the parent MA, thereby getting to be in an in_tree state in which the communication is possible. The selection of a parent MA can be accomplished by ordering the MAs included in Lhc probed NL depending on a predetermined session policy, and selecting most optimized MA as the parent MA from the probed NL.

'.4 Parent switching (PS) (Step 250)

•<o> According to the present invention, if there is a parent MA better than the current parent MA, the MA can perform parent-switching (PS) operation to improve the tree. However, if two more MAs at the same edge simultaneously perform the PS operation, the structure of a tree may be broken. Therefore, when the MA performs the PS operation, atomicity should be guaranteed.

M> FlG. 8 is a flowchart illustrating a parent switching (PS) process according to an embodiment of the present invention. As shown in FIG. 8, the PS process begins with the receipt of a periodical heart beat (HB) sent from the root in Step 810. The HB includes information on a path from the root to the MA receiving the HB. The MA updates its possible QoS information (e.g., delay, bandwidth, etc., ) using the HB in Step 820. A method for updating the QoS information is as follows:

- Delay information: at every node that a HB message passes through, delay information is updated by adding a delay value from the root to the upper node, which is provided by the upper node, to a delay value between the upper node and itself.

- Bandwidth information: at every node that a HB message passes through, available bandwidth information is updated by selecting a small bandwidth from the minimal bandwidth from the root to the upper node, which is provided by the upper node, and an available bandwidth between the upper node and itself.

The information will be used to decide a parent MA having a better condition, depending on the session policy. The MA receiving the HB message notifies that it can perform the parent switching in Step 830. Next, the \1A determines how much the updated possible QoS information is better than the QoS of its current parent MA (that is, greater than a predetermined threshold value), thereby deciding whether to perform the parent switching (PS) in Step 840. The deciding of whether to perform the PS operation will be later described in a little more detail with reference to FIG. 9. In Step 850, it is determined whether it is decided to perform the PS operation in the PS decision step in Step 840. If it is determined to perform the PS operation, the MA performs the PS operation in Step 860. A detailed operation of the PS will be later described with reference to FIG. 10.

If it is determined not to perform the PS operation, the MA updates the root path information and the direct NL information stored in its NLDB, using the received HB message in Step 870, and forwards the updated information to its children MA (CMAj in Step 880.

FIG. 9 is a flowchart in more detail illustrating the PS decision step 840 of FIG. 8. As shown in FIG. 9. the decision whether to perform the PS begins with Step 910 of searching for the MA having the better QoS than the current PMA in its probed NL (ProbedNL). If the MA having better QoS is not detected as the search result, the current PMA is selected as a wanting parent MA (wanting_PMA) in Step 920, and an indication that there is no need for PS operation is displayed in Step 930.

If a more efficient MA is detected, it is determined whether the detected MA is excellent over a threshold value (PsJfflRESHOLD) in Step 940. If it is determined not to be excellent, Step 920 is performed. If the MA is detected to be excellent more than the threshold value, the detected MA is selected as the wanting_PMA in Step 950. and indication that there is a need for the PS is displayed in Step 960. It is determined whether there is a better MA to update the wanting_PMA in Step 970. If there is the better MA, Steps 910 to 970 are repeatedly performed.

FIG. 10 is a flowchart illustrating the Parent Switching step 860 of FIG. 8 in more detail. The MA selects a wanting parent MA (wanting_PMA) determined to have the most optimized condition from its probed neighbor MA list (ProbedNL) in Step 1010. Rather than simply selecting the MA having the minimum hop distance, the MA can select a PMA having the most optimized condition under a certain service requirement. For example, in the case of a service sensitive to transmission delay, the hop distance is calculated considering accumulated transmission delay from the root, and in the case of a service sensitive to a bandwidth, the distance between the hops is calculated considering the bandwidth from the root. The MA selecting the wanting_PMA transmits a relay request message (RelayRequcst) to the \vanting_PMA to request the wanting_PMA to operate as its PEA in Step 1020. Next, the MA receives a relay answer message in response to the relay request message from the want ingJ'MA in Step 1030. The wanting_PMA decides whether to permit data relay in consideration of a data relay possibility and a session policy, and transmits the decision result using the relay answer message (RelayAns). It- is determined whether the PS succeeds or fails based on the relay answer message received from the wanting_PMA in Step 1040. If it is determined to be a success, the PS operation is completed in Step 1050, and otherwise (i.e., if the wanting_PMA rejects the data relay), a failure of the PS is returned in Step 1060.

⁷<i> Periodical management of tree information

Ti' Once an overlay multicast session is initiated, it is necessary to manage session status, periodically or upon demand, tor session service and membership management. The tree may be managed in a different fashion depending on a session manager (SM) and a multicast agent (MA).

^"7K FIG. 11 is an outline diagram illustrating the tree management operation of the SM according to an embodiment of the present invention. In one embodiment, tree management by an SM may be performed mainly where session status should be measured in response to a user's request in Step 1110, where a MA list (AML) in operation should be updated (i.e., when a predetermined time-out for updating the AML arrives) in Step 1150, and where a readyJlA list (RML) should be updated (i.e., when a predetermined time-out for updating the RML arrives) in Step 1160.

7'b When the SM receives a message requesting to manage the tree status from the user in Step 1110, it transmits a report request message requesting desired information to a selected MA in Step 1120, receives a report answer message (ReportΛnswer) from the corresponding MA in Step 1130, and forwards the received report information to the user in Step 1140. By doing so, the user (CP, manager) can obtain information on the session state. o FIG. 12 is an outline diagram illustrating the tree management operation of the multicast agent (MA) according to an embodiment of the present invention. In one embodiment, tree management by the MA may be divided as a process of maintaining the tree and a process of appropriately answering a status report request from the SM or the PMA. For continuous management of the tree, at every relay time-out of Step 1210, the MA performs a relay refreshing process of sending a relay request message (RelayRequest) to its PMA and receiving a relay answer message (RelayAnswer) from the PMA in Step 1220. When the MA receives a report request message (ReportRequest) from the PMA or the SM in Step 1230 it returns a status report answer message to the corresponding PMA or SM in Step 1240

Error recovery

Application layer relayed multicast mechanism which uses end hosts as real nodes should keep relayed multicast tree robust in case ot error has ocelli red The multicast data delivers tree comprised of the MΛs should be robust against a variety of errors in light of frequent initiation and termination of personal computer applications and an overlay tree which is different from the topology of a physical network In the overlay multicast environment there are two most critical errors which mav collapse relascd multicast tree The one is a loop problem and the other is a network- paititioning problem

FIG 13 is an outline diagram illustrating a loop error reco\erv operation according to an embodiment of the present invention The loop erior can be detected using the HB that is periodically received from the root As shown in FIG 13 the MA receπes the HB from the root in Step 1310 and the MA determines whethei the MA or its CMA is included in a root path i e , a path from the root to the MA in Step 1310 If so it is determined that there is a loop and a loop recovety process is performed in Step 1.Η0 Otherwise the QoS information is updated based on the information contained m the HB in Step IMO The QoS information is updated by calculating and reflecting the distance from the root

FIG 14 is a flowchart in detail illustrating the loop recovers operation atcoiding to an embodiment of the present invention The loop recovers process begins with Step 1410 of leaving from the PM to disconnect the loop Next the PS operation is performed to switch to a new PMA in Step 1420 It is determined whether the PS succeeds or fails in Step 1430 If it fails which indicates that the loop recovery process fails a new MAP discoveiy process is performed in Step 1440 and the PS operation is again performed in Step 1450

FIG 15 is an outline diagram illustrating a network-partitioning recoven operation according to an embodiment of the present invention When the periodical HB is not received within a predefined time (HB expectation time out) it is determined that the network partitioning error occurs m i>t<p 1510 If the HB is not received within the HB expectation time out K llBjriMEOUT increases one at a time and it is determined whether I\_HB_TIMEOUT is greater than MAλJffiJTIMEOUT in Step 1520 If so the netwoik partitioning error recovery operation is performed in Step 1530 MG 16 is a flowchart in detail illustrating the network-partitioning recoven operation according to an embodiment of the present invention In order to confirm whether only an upstream is disconnected the MA determines whethei its child MA (CMI) operates in Step 1610 When the LMΛ is also disconnected the MA determines that only the M<\ exists alone in the netwoik in Step 1620 If it is determined that the CM operates the M confirms whether anv of the next upper parent MAs (PMAs) is alive through its root path in Step 1630 If any of the next upper PMAs does not operate the M\ determines that the session is terminated in Step 16-10 transmits a leave request message (I eaveRequest) to its CMAs in Step 1650, and leaves the session in Step 1660 If am of the next upper PMΛs operates the PS operation is pei formed in Step 1670

The bootstrapping, MP discovery parent switching periodical tree management and error recovery processes required to configure and manage the multicast tree according to the preferred embodiment of the present imention have been described b> function with reference to the system block diagrams and the flowcharts The present invention is capable of effectively configuring and managing the overlav multicast tree through the method and/or the system including a possible combination of the above processes As understood by those skilled in the art the method the s>stem or the computer readable recording media can be provided as embodiments of the present invention Accordingly the present invention can be entireh embodied by hardware, software, or a combination thereof. Further, the present invention may be a computer readable recording media (including a disk storage unit, a CD-ROM, and an optic storage unit, to which the present invention is not limited) having a built-in computer accessible program code, available to a computer.

Claims

[CLAIMS] [Claim 1] ^ς'i' A method for configuring and managing an overlay multicast data delivery tree in a transmission network including a session manager (SM) and at least one multicast agent (MA), the method comprising the steps of: '» at the MA intending to joining a session, ■')_'» (a) obtaining an active neighbor MA list from the SM; ^l>4 (b) detecting information on QoS information of each neighbor EA in the active neighbor MA list; ^ (c) selecting a MA having the most optimized QoS as a parent MA based on the QoS information of each neighbor MA in the active neighbor MA list; %_^ (d) joining an overlay multicast data communication session through the selected parent MA;

⁽)7> (e) periodically receiving HB(heart beat) information having information on a path from a root to the MA, and determining whether to perform a parent-switching based on the HB information; and

^ (f) parent-switching from the current parent MA to a MA having a better QoS when it is determined to perform the parent-switching.

[Claim 2] ^ The method according to claim 1, wherein said step (a) comprises the sub-steps of: '()« (al) transmitting a subscription request message to the SM by the MA intending to joining an overlay multicast data transmission session: and mi (a2) receiving a subscription answer message containing the active neighbor MA list from the SM.

[Claim 3]

UP> The method according to claim 1, wherein the MA stores root path information on a path from the root to the MA in its belonging overlay multicast data deliverj tree; parent MA and child MA information in the tree; a probed neighbor MA list storing at least one probed MA; and a non-probed neighbor MA list storing at least one non-probed MA. [Claim 4] nπ- The method according to claim 3, wherein said step (b) comprises the sub-steps of: 104 (bl) storing the active neighbor MA list in its non-probed neighbor MA list; i"^ς (b2) selecting a to-be-probed HA from its non-probed neighbor MA list; i»<» (b3) transmitting a probe request message containing its neighbor MA list, to the Lo-bc-probed MAl K)^' (b4) receiving a probe answer message containing neighbor M list of the to-be-probed MA, from the to-be-probed MA; ins (b5) adding the to-be-probed MA information to its probed neighbor MA list; and ιi)^ι) (b6) adding MA information, which is included in the neighbor MA list of the to-be-probed MA, but not included in its probed neighbor MA list, to its non-probed MA list. [Claim 5] no- The method according to claim 3, wherein said step (b) is periodicalh performed. [Claim 6] in- The method according to claim 1, wherein in said step (c), the VIA having the most optimized QoS information is decided depending on a specific service requirement.

[Claim 7] ιi:-> The method according to claim 1, wherein said step (d) comprises the sub-steps of: ιn> (di) transmitting a data relay request message to the parent MA; MI- (d2) receiving a data relay answer message having data relay permission or rejection, from the parent MA; and ii^ (d3) determining the data relay permission or rejection based on the data relay answer message. ii6 wherein when the data relay answer message represents the data relay rejection, a MA having next better QoS is selected as the parent MA and the sub-steps of (di) to (d3) are repeated.

[Claim 8] M⁷- The method according to claim 1, wherein said step (e) comprises the sub-steps of: is, (el) calculating possible QoS information using the HB information; >ii^l»» (e2) comparing the possible QoS information with QoS information of the current parent MA, and determining whether the possible QoS is better than that of the current parent MA and is over a predetermined threshold: ι.(b (e3) when it is determined that the possible QoS is better than that of the current parent MA and is over the predetermined threshold, deciding that the parent-switching is needed: and 121- (e4) otherwise, deciding that the parent-switching is not needed.

[Claim 9] -12: The method according to claim 1, wherein said step (f) comprises the sub-steps of: U' (fl) selecting a MA having the most optimized QoS as a parent MA, among the neighbor MAs: i--^ (f2) transmitting a data relay request message to the parent MA; !:^■>-. (f3) receiving a data relay answer message having data relay permission or rejection, from the parent MA; -i2f, (f4) determining the data relay permission or rejection, based on the data relay answer message; and

1:⁷-- (f5) when the data relay answer message represents the data relay rejection, selecting a MA having next optimized QoS, and repeating the sub- steps of (f.2) to (f.5).

[Claim 10]

12s The method according to claim 1, further comprising the steps of, at the MA, transmitting a relay request message to the parent MA, at regular intervals, and receiving a relay answer message from the parent MA. [Claim 11] 12'⁾- The method according to claim 1, further comprising the step of determining that a loop error occurs in the session, when the MA redundantly exists or a child MA of the MA exists in the path from the root to the MA, which is included in the periodically received HB information. [Claim 12] ιw The method according to claim 11, further comprising the step of perform the parent-switching, when the loop error occurs. [Claim 131 i">i-> The method according to claim 1, further comprising the step of determining that a network-partitioning error occurs, when the periodical h received HB information is not received within a predetermined time. [Claim 14] r-,1 The method according to claim 13, further comprising the steps of, when the network partitioning error occurs,

Ii' i) checking whether a child MA is alive or notI

H4 ii) when it is checked that the child MAs is not alive, determining that disconnection occurs in the network; and πs> iii) when it is checked that the child MA is alive, ιv» checking if a next upper parent MA is alive or not, i'"> when lhe next upper parent MA is alive, perform the parent-switching to the next upper parent MA, and i^ when the next upper parent MA is not alive, determining that the session is terminated, transmitting a leave request message to the child MA, and leaving the session. [Claim 15] π^y A method for configuring and managing an overlay multicast data deliver} tree in a transmission network having a session manager (SM) and at least one multicast agent (M), the method comprising the steps of: at the SM. i4<ι> storing a list of active MAs having joined a session managed by the SM and being currently in a normal operation, and a list of ready MAs not yet confirmed whether to normal1> operate in the session; ι-tι> receiving a subscription request message from a MA intending to joining the session: 142 determining whether to permit subscription of the MA, in response to the received subscription request message; i-J^"*' when it is determined that session subscription is permitted, extracting a portion of the active MA list, and transmitting a subscription answer message having the extracted portion of the active MA list to the MA; |44> when it is determined that the session subscription is rejected, transmitting a subscription answer message having a rejection reason to the

MA; and Ui-. adding the MA information to the ready MA list.

[Claim 16] 4(.> The method according to claim 15. further comprising the step of, at the SM, checking session status in response to a user-Il request.

[Claim 17] i4^"-> The method according to claim 16, wherein the step of checking the session status comprises the sub-steps of: at the SM, us receiving from the user a message of asking the status of a specific

MA;

U"-. transmitting a status report request message to the specific MA; iMw receiving a report answer message from the specific MA; and lϊi> forwarding the received report answer message to the user.

[Claim 18] 1¹^ The method according to claim 15, further comprising the steps of: at the SM,

^> periodically updating the active MA list at first periods; and ¹M periodically updating the ready MA list at second periods.

[Claim 19] i" A computer readable recording media recording a computer program for performing a method for configuring and managing an overlay multicast data delivery tree according to any one of claims 1 to 18.

[Claim 20] ιv> A multicast agent apparatus comprising: I^s"- means for obtaining an active neighbor MΛ list from a SM; ι^> means for detecting QoS information of each neighbor M in the active neighbor MA list; i^ means for selecting a MA having the most optimized QoS as a parent MA based on the QoS information of each the neighbor MA, and joining an overlay multicast data communication session through the selected parent MA; IM>> means for periodically receiving HB information having information on a path from a root to the MA, and determining whether to perform a parent switching based on the received HB information; and i'ii means for parent-switching from the current parent MA to a MA having a better QoS when it is determined to perform the parent-switching.

[Claim 21]

162- A session manager apparatus comprising: itn means for storing a list of active MAs having joined a session managed by itself and being currently in a normal operation, and a list of ready MAs not yet confirmed whether normally operating in the session, and periodical 1> updating the 1ists: 164. means for receiving a subscription request message from a MA intending to joining the session, and determining whether permitting subscription of the MA in response to the subscription request message; ifi^ means for extracting a portion of the active MA list and transmitting to the MA a subscription answer message having the extracted portion of the active MA list, when it is determined to permit session subscription, and transmitting to the MA a subscription answer message having a rejection reason, when it is determined to reject the session subscription; and 166- means for adding the MA information to the ready MA list.