WO1999048246A1 - Procede, appareil et support de retablissement par greffe/raccordement de multidiffusion en un temps reduit - Google Patents

Procede, appareil et support de retablissement par greffe/raccordement de multidiffusion en un temps reduit Download PDF

Info

Publication number
WO1999048246A1
WO1999048246A1 PCT/US1999/005731 US9905731W WO9948246A1 WO 1999048246 A1 WO1999048246 A1 WO 1999048246A1 US 9905731 W US9905731 W US 9905731W WO 9948246 A1 WO9948246 A1 WO 9948246A1
Authority
WO
WIPO (PCT)
Prior art keywords
network node
information
network
multicast
reconnect
Prior art date
Application number
PCT/US1999/005731
Other languages
English (en)
Inventor
Paul A. Stirpe
Original Assignee
Reuters America Incorporated
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Reuters America Incorporated filed Critical Reuters America Incorporated
Priority to JP2000537343A priority Critical patent/JP2002507857A/ja
Priority to EP99912580A priority patent/EP1062766A1/fr
Priority to AU30926/99A priority patent/AU3092699A/en
Publication of WO1999048246A1 publication Critical patent/WO1999048246A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports

Definitions

  • the invention generally relates to IP multicast technology. More particularly, the invention relates to re-establishing a link with minimal delay, between a user's local area network and a multicast content channel.
  • PTP point-to-point type protocols
  • An example of point-to-point protocol is TCP/IP.
  • PTP protocols to send data become increasingly inefficient in terms of bandwidth utilization as final destinations are located closer to each other. Packets traveling to similar destinations may traverse similar paths in a network, thus consuming extraneous bandwidth along the way.
  • IP multicasting this technology is a mechanism provided by a network that facilitates the transmission of a single packet to a plurality of destinations.
  • a network node Router or switch
  • the network node duplicates and transmits the packet down as many pathways as needed to forward the packet to all predetermined locations specified by the multicast communication channel.
  • IP multicast routing protocols The class of controlling protocols utilized by network nodes that build and maintain multicast communication channels (or routing trees) are referred to as IP multicast routing protocols.
  • the class of controlling protocols utilized between destination machines and their first hop network nodes are called Group Management Protocols, such as IGMP.
  • IGMP Group Management Protocol
  • the IGMP specification (identified as Internet Group Management Protocol, Version 2, Network Working Group of the Internet Engineering Task Force, November 1997), as is known in the art, is hereby incorporated by reference.
  • PIM dense mode is a multicast routing protocol that controls the maintenance of multicast communication channels utilized for transmissions to multicast groups which are densely distributed across a network.
  • Applicable networks include intranets, extranets and the Internet, and other equivalent networks.
  • PIM dense mode uses reverse path multicasting (RPM), also called reverse path forwarding (RPF), to establish and maintain routing trees.
  • RPM is a technique in which a multicast packet (or datagram) is forwarded if the receiving interface on a network node is the one used to forward unicast datagrams to the source of the multicast datagram.
  • the first step in establishing a routing tree according to the PIM dense mode specification is to broadcast the multicast datagram to all PIM DM enabled routers in the network, such that a routing tree is formed that provides a multicast communication channel on which datagrams are carried. This broadcast process is repeatedly performed every three minutes.
  • Figure 1 shows an example of setting up a routing tree in a PIM dense mode IP multicast system.
  • Network 101 includes a plurality of network nodes 102-107.
  • Figure 1 includes LAN 108 as attached to network node 105 and workstations 109 and 110.
  • the communication protocol between network node 105 and workstations 109 and 110 on LAN 108 may include the Internet Group Management Protocol, IGMP.
  • IGMP Internet Group Management Protocol
  • other communication protocols are available.
  • IGMP there are several version of IGMP, mainly version numbers 1, 2 and 3, the last of which is a draft proposal in the research community.
  • Other Management Protocols exist.
  • the Cisco Corporation has developed a protocol called CGMP (Cisco Group Management Protocol) which is similar to IGMP, described above.
  • IGMP is used to tell network node 105 (leaf node) that workstations 109 and 110 exist and continue to have interest in the particular multicast communication channel on which datagrams are forwarded to them.
  • network node 102 receives a datagram from sending host 102 A and transmits it to downstream network nodes 103, 104, and 107 as illustrated by transmission paths 1 1 1, 1 12, and 1 13. Having received the datagram, network nodes - 4 - 103, 104 and 107 retransmit the datagram to other network nodes to which they are connected, except to the router from which the datagram was received. In this case, network node 103 transmits the datagram to network node 104 via path 114 and to network node 105 via path 1 15. Network node 104 retransmits the datagram to network node 103 via path 1 18, network node 105 via path 120, network node 106 via path 121, and network node 107 via path 119.
  • Network node 107 retransmits the datagram to network node 104 via path 1 16 and network node 106 via path 122. Finally, depending on circumstances, for example, when the datagram was received by network node 106, it may retransmit the datagram to network node 107 via path 117.
  • the second step in establishing PIM DM routing trees includes pruning back all branches that lead to end stations that have not expressed interest in attaching to the multicast communication channel.
  • Figure 2 shows an example of the pruning process in action in accordance with the PLM dense mode. In Figure 2, it is assumed that either of workstations 109 or 110 have expressed an interest in attaching to the multicast communication channel (that is currently in the broadcast phase, as shown in Figure 1).
  • Router 105 sends prune message 203 to router 104, but does not send a prune message to router 103, because the RPF (the best reverse path to the source of the multicast data) interface on router 105 is the one on which router 103 is connected. Router 105 will not prune itself from the multicast channel in which it is interested. It is assumed, although not shown, that router 106 servers at least one end user workstation that has expressed interest in the multicast channel. As a result, router 106 does not prune its interface towards router 107, because the interface of - 5 - router 106 knows that router 107 is router 106's RPF to the sending host 102 A. Router 107, however, does send prune message 205 to router 104.
  • the RPF the best reverse path to the source of the multicast data
  • FIG 2 shows a mechanism used to establish routing trees
  • other techniques to establish routing trees are known in the art as related to other EP multicasting protocols including protocols PEM sparse mode, CBT, and MOSPF, for example.
  • PIM sparse mode is another applicable Multicast Routing Protocol (Protocol Independent Multicast-Sparse Mode: Protocol Specification, September 9, 1997), hereinafter incorporated by reference.
  • the resulting network as created by routing tables stored in the various network nodes is shown in Figure 3A
  • the resulting multicast channel is shown in Figure 3B.
  • Datagrams, originating from sending host 102 are transmitted from network node 102 to network nodes 103 and 107 via paths 301 and 302, respectively.
  • the datagrams are transmitted to network nodes 105 and 106, via paths 303 and 305, respectively.
  • the network node preferably has at least one destination end user attached to it and that the destination end user has expressed an interest in attaching to the multicast communication channel (via IGMP or some similar Group Management Protocol).
  • multicast routing communication channels terminate at network nodes
  • multicast communication channels terminate at end user workstations.
  • network node 104 may remain connected to receive a multicast channel so as to be available for quick connection to the multicast channel by another end user.
  • One feature of multicast systems includes the concept of groups. Groups are sets of destinations that participate in a multicast communication channel. The channel generally originates with a single content provider.
  • FIG. 4 shows network node 102 (of network 101, not shown for simplicity) receiving a multicast datagram from sending host 102 A and sending the datagram via path 301 to network node 103.
  • Network node 103 transmits the datagram to network nodes 403, 404, and 405.
  • All the network nodes including 102, 103, 403, 404, 405, and 105 participated in group G_, during the broadcast phase.
  • After the pruning phase only network nodes 102, 103, 403, 404, and 405, remain participating in G . (105 having pruned back the channel).
  • workstation 109 which is connected to network node 105, part of network 101, desires to join group G] 409, it sends a request via IGMP to network node 105 specifying that it wishes to join group Gi.
  • Network node 105 is considered to be a leaf node, in that it is directly connected via a LAN to end users that have expressed interest in the particular multicast channel, and there are no - 7 - further routers downstream of router 105 on the LAN.
  • Network node 105 interprets the request from workstation 109 as a command to attempt to join group Gi.
  • Network node 105 sends a Graft message with the payload Gi, Si to network node 103 via path 401.
  • network node 103 replies with a Graft acknowledge (Graft-Ack) signal to network node 105 via path 402.
  • Graft-Ack a Graft acknowledge
  • the system may have to wait between 0 and 3 minutes (the PIM dense mode broadcast phase cycle time) or for an average of 1.5 minutes until the multicast system enters the broadcast phase such that state is reestablished in network nodes and the channel can re-establish itself.
  • a difficulty here especially in environments with a need for minimal disconnect time, is that the delay associated with re-establishing a connection to network node 105, if it becomes separated from group Gi, may take an average of 1.5 minutes.
  • the cause of the separation may be due to a variety of reasons including transmission line failure, local router failure, and related problems.
  • This reconnect delay is the average time in which PIM dense mode enters the re-broadcasting phase as shown in Figure 1.
  • the delay associated with waiting until the overall multicast system re- establishes itself is unacceptable.
  • merely decreasing the multicast system's re- broadcast interval substantially increases the amount of non-usable broadcast information sent to all end network nodes, regardless of their interest in the particular communication channel.
  • This approach can be very costly in terms of inefficient use of network bandwidth. The result of this delay may be one reason that systems requiring a fast re-establishment time (high availability requirements) have not readily embraced multicast technology as a solution for efficient information transfer.
  • the dotted line to network node 105' in Figure 3 A indicates that while 105 and 105' are considered separate network nodes, as part of the PIM DM protocol, one of them (i.e., 105') has pruned itself from the multicast channel 101, leaving the remaining network node (105) as the "forwarder" as represented in Figure 3B.
  • the process to elect which network node is to be the forwarder to LAN 108 is called Assertion.
  • Routers 105 and 105' execute the Assert process, as specified in the P M dense mode specification, and only one of the network nodes becomes the forwarder, and the other network node(s) on the LAN that lose the assertion process prune themselves back, e.g. 105'.
  • network node 105' when network node 105' has pruned itself from the multicast channel, it needs to wait for the re-broadcast phase (see Figure 1 implemented every three minutes) before network node 105' can begin receiving new datagrams again (see Figure 3A). When this occurs, the assertion process is repeated and the network nodes that lose the assertion process prune themselves back.
  • the existence of two client side network nodes (leaf nodes in this case) 105 and 105' is to make LAN 108 more robust in being able to handle router or switch failures (network node). However, at most only one of the two network nodes 105 and 105' is active in receiving datagrams from network node 103 and forwarding them onto the LAN 108, at any given time, because the other node (e.g., 105') was pruned out of the multicast channel during the pruning phase. Note that during the assertion process, both network nodes 105 and 105' can be acting as forwarder to LAN 108, until one of the network nodes wins the election process and becomes the forwarder for the LAN 108.
  • network node 105 is the forwarded for the LAN 108, - 10 - and in the event that network node 105 becomes disabled, workstations 109 and/or 110 on LAN 108 will have to wait until the PIM DM re-broadcast phase initiates, so as to forward packets to network node 105' (an average of 1.5 minutes).
  • network node 105' will elect itself as the forwarder (since no other network node has challenged it and the assert election process is not triggered in this case) and being to forward packets to onto the LAN 108.
  • the hosts on LAN 108 may experience large gaps in messages, and general data loss.
  • the maximum waiting interval is, as above, 3 minutes, with an average waiting interval of 1.5 minutes.
  • the average waiting interval of 1.5 minutes is unacceptable as volumes of data may back up, resulting in excessive data loss, memory usage and delay in attempting to re-establish the data to the hosts on LAN 108.
  • users of real-time applications that require up-to-the-second information cannot tolerate even modest periods of disconnection from the service, e.g. instrument traders using a realtime financial application.
  • the present invention overcomes the above-described problems by providing a fast re-establishment of a lost connection to a multicast group.
  • the end user's system stores relevant connection information so that, when needed, it directs a network node to re-establish its connection to one or more multicast groups.
  • Each LAN end user on network 108 may elect a director for the LAN 108 that is responsible for coordinating the recovery of the one or more multicast channels to the LAN Alternatively, a director may not be elected and each end user may act independently and redundantly perform the operations that the director would handle.
  • Advantages of including a director include limiting the task of initiating re- establishment of the multicast channel to one designated entity, rather than several end user workstations
  • Advantages of not including a director include redundant processing so that if any portion of the LAN 108 fails, each workstation (109, 110) may be able to re-establish its connection with network 101.
  • the director when referencing the director, it will be understood that the director is intended to refer to any workstation performing the functions of the director, including but not limited to any end user's workstation redundantly performing the director's functions where LAN 108 has no director and each end user's workstation acts independently.
  • the director stores the group information as received from various sources. For example, the director may store this information in a source, group pair (also referred to as an S, G pair).
  • the director also monitors sender "liveness" regarding a monitored group. Liveness, for purposes herein, refers to the monitoring of information received from a source. By monitoring liveness information, the receiver (director or workstation) knows when to expect information from the source. That is, when the source is idle (has no data to send), liveness (heartbeat) messages are sent at predefined intervals or at decaying intervals to inform all end user systems that the channel is still alive
  • Various sender driven liveness messages are specified in - 12 - Holbrook et al.'s "Log-Based Receiver" (H. Holbrook, S.
  • the director determines that the connection to the source has been lost.
  • the director retrieves the previously stored information (the S, G pair), forms a Graft message, and transmits a Graft message to the all routers address (224.0.0.13) or to a specific leaf router address, if the target leaf router address is well known (configured or learned) by the director.
  • the all routers address is specified in the PIM DM specification.
  • the Graft message could be sent using any defined or reserved address that delivers the message to the LAN network nodes that can process the Graft and reestablish the multicast channel to the LAN.
  • the network node or network nodes receiving the Graft message acts accordingly to re-establish the connection to the group by immediately forwarding the Graft upstream on the Reverse Path Forwarding (RPF) interface, as specified in the PIM DM specification.
  • RPF Reverse Path Forwarding
  • the director is acting like a network node by forwarding a Graft to its leaf router(s).
  • the receiving network node does not distinguish between the director and another node, in this case, and processes the Graft as if it were received from a network node, as specified in the PIM dense mode specification.
  • the result is that the multicast channel is more rapidly re-established the LAN.
  • a director may quickly re-establish a connection to a group with minimal delay.
  • the Internet is used as an example of a network of computers which benefits from IP multicast technology.
  • the invention as described herein may be readily applied to internets, extranets, WANs and other networks which may benefit from multicasting.
  • PIM dense mode it is readily apparent that the advantages described herein are applicable to other IP multicasting protocols including PIM sparse mode, CBT, and MOSPF, and other equivalent EP multicasting protocols.
  • the reference to PEM dense mode is made by way of example only. For example, in PEM sparse mode, the director would send a Join message rather than a Graft, when the liveness information has not been received as expected. While PEM sparse mode is not a broadcast and prune protocol, as is PEM dense mode, the rapid recovery mechanisms described herein are applicable in achieving rapid multicast channel recovery.
  • Figure 1 is network diagram showing a broadcast phase of a conventional multicast system.
  • Figure 2 is network diagram showing a pruning phase of a conventional multicast system.
  • Figures 3 A and 3B are network diagrams showing a remaining network after a broadcast and pruning phases of a conventional multicast system.
  • Figure 4 is a network diagram showing a Graft in a conventional multicast system.
  • FIG. 5 is a network diagram of a Graft originating with an end user according to embodiments of the present invention.
  • Figure 6 is a packet format diagram of a multicast system as used in conjunction with embodiments of the present invention.
  • Figure 7 is a network diagram of the present invention including an embodiment of an end user's system according to embodiments of the present invention.
  • Figure 8 is a network diagram of the present invention showing Graft messages as contemplated by the present invention.
  • FIG. 5 shows an array of workstations 109 and 1 10 on network 108 (for example, a LAN) connected via network node 105 to network 101 (not shown for simplicity). While only two workstations are shown, it is understood that many - 15 - workstations may be connected to network 108.
  • One of the workstations, 109 or 110 may be elected as director for a particular S,G pair As the director officiates in numerous occasions, the director may be also referred to as a host of the network 108.
  • workstation 109 is the elected director.
  • workstation 1 10 is the designated assistant director.
  • the assistant director stores information similar to workstation 109 so as to replace workstation 109 in the event workstation 109 fails
  • the director is intended to refer to any workstation performing the functions of the director, including but not limited to any end user's workstation redundantly performing the director's functions where LAN 108 has no director and each end user's workstation acts independently.
  • Workstation 109 stores information 507 in internal memory. While not shown for simplicity, workstations 109 and 1 10 may contain various forms of internal memory including RAM, ROM, replaceable storage devices (for example, diskettes, hard drives, and CD-ROMs), and equivalents thereof.
  • Information 507 contains a list of which workstations are the director and assistant director (wrkl and wrk2 respectively) and a list of S, G pairs that list the source (for example, Si) of various groups (for example, G_, G 2 , through G n ). Workstation 1 10 may store a similar set of information 508
  • the director derives sender liveness information from information received in connection with the received liveness datagrams, the latter (liveness or heartbeat - 16 - mechanisms) being discussed in the Holbrook et al "Log-Based Receiver" From this sender liveness information, the director determines when to expect datagrams from a source S regarding group G Once the datagrams or liveness messages are not received as expected, the director transmits a Graft or Join message 501 in PEM DM or PEM SM, respectively, with the appropriate payload (for example, S n , Gi) to the all routers address (as found in the PIM DM specification). Alternatively, the director transmits the Graft message 501 to a specific leaf router, or any other all local routers address.
  • the director did not receive the liveness messages as expected, because the forwarder for the multicast channel, e g router 105, failed, then the other router, e.g. 105' (or routers) will receive the Graft message and forward it to network node 103 (or on their respective RPF interface), which will cause the quick re-establishment of the multicast channel to LAN 108.
  • Assistant director workstation 110 in addition to being able to perform tasks similar to that of director workstation 109, monitors director workstation 109 in its performance of its director duties. So, if and when director workstation 109 fails, workstation 1 10 may act as a backup.
  • a workstation and equivalent systems may be referred to as information handlers.
  • the director generates the S,G pair(s) by monitoring received datagrams for the respective multicast channel(s)
  • the header information in a received IP Multicast packet contains the sender's identity (here the identify of the source end user's - 17 - workstation, and the group address G, carried in the IP destination field of the IP header
  • the workstation stores the sender's information in conjunction with the group over which the datagram was received
  • the sender transmits the following a source address, a destination address, the source port, and the destination port
  • the source address is the EP address of the host sending the information out to receivers
  • this source address is the S of the S, G pair
  • the destination address is the EP address of the multicast communication channel referred to as a group
  • This group is the group G of the S, G pair
  • end user workstations can further refine that information that is passed to the end user application for a given G, by filtering those datagrams that are received on destination port numbers of which are interest
  • FIG. 6 shows an example of PIM packet formats for control messages as sent from workstation 109 and 1 10.
  • Bits 0-3 relate to the PIM version, bits 4-7 identify the type of control message, bits 8-15 are reserved, and bits 16-31 are checksum.
  • PIM message types The following list defines PIM message types:
  • Graft - Ack 8 Candidate-RP- Advertisement
  • the Graft control message as part of the present invention is initially formatted in workstation 109 or workstation 1 10 depending on which workstation(s) is attempting to re-establishing the link to group G.
  • the other control messages can be found in the PEM dense mode or PEM spare mode specification, referenced here in, etc.
  • Figure 7 shows an embodiment where more than one router is connected to LAN 108.
  • two routers 701 and 702 connect LAN 108 to router 105.
  • the - 19 - interaction between routers (network nodes) 701 and 702 and router (network node) 105 and workstations 109 and 1 10 is as described above.
  • workstation 109 may be the only workstation.
  • LAN 108 may be supporting a single workstation 109 in connection to network 101.
  • the term LAN may refer to a device which allows workstation to connect to both network nodes 701 and 702 simultaneously.
  • Figure 9 shows network node 105, network nodes 701 and 702, and LAN 108 as described with respect to Figure 7. Also included in the arrangement are network nodes 703 and 704 also connected to network node 105 and LAN 705. Next, both LANs 108 and 705 are connected to workstation 109. In this embodiment, both LANs 108 and 705 support a single (or multiple) workstations. By using this arrangement, workstation 109 (and other similarly connected workstations) is provided with multiple paths to connect to network node 105.
  • An example of when the arrangement Figure 9 may be used is in applications where redundant paths to the network 101 is required, so as to achieve higher availability of services provided by sources such as 706.
  • Figure 8 shows a network level diagram of network 801 as including a variety of sources S n and a variety of end user workstations 810-812.
  • Source Si transmits group Gi datagrams to receivers S 4 and S 5 (S 4 and S 5 are receivers with respect to group Gi, but are senders with respect to the groups they source) on multicast channel Si Gj.
  • the combination of receivers S 4 and S 5 comprise group Gi. - 20 -
  • source S 2 sends content on group Gj (on multicast channel S 2 Gi) as shown by the combined use of Gi from sources S ⁇ and S 2 .
  • the content of Gi may originate with Si and use S 2 as a backup for content.
  • Source Si also provides information to receiver S 3 .
  • receiver S 3 reformulates and retransmits the datagrams to receivers of network 809.
  • Network 809 may be a LAN or individual groups of receivers so long as they maybe collectively referred to as group G 5 .
  • receiver S 4 reformulates and retransmits received datagrams to network 808 as group G 3 .
  • receiver S 5 reformulates and retransmits received datagrams to network 807 as group G 4 .
  • receiver 810 When receiver 810 (for example, a workstation with the functionality of workstation 109 of Figure 5) from network 809 wishes to re-establish a connection to group G 5 , receiver 810 transmits a Graft message as described above to its leaf router containing the S 3 ,G 5 pair information.
  • the network node (not shown) in between S 3 and LAN 809 receives G (here, G 5 ) and sends receiver 810 the multicast channel corresponding to S 3 ,G 5 .
  • the Graft sent by the director specifically only re-establishes the specific S,G pair and not all *,G pairs, as is done with simply a IGMP join message from the host. Alternatively, all *,G pairs are re-established then unwanted ones dropped.
  • Figure 8 are relative to the datagrams originating with sources S t and S 2 .
  • a network receives information from alternative sources, for example, network 808 receiving group G n datagrams (not shown for simplicity) from source S 3 , the Graft S, G pair information from receiver 81 1 takes the form of (S 3 , G n ).
  • delay times in re-establishing a connection to a group may be minimized through sensing a fault in received (or not received) information, determining how to quickly reconnect, and reconnecting to a group through the use of information stored in a monitoring station.
  • the techniques of the present invention apply to any network including intranets and extranets.
  • the present invention may also be implemented in a peer-to-peer computing environment or in a multi-user host system having a mainframe or a minicomputer.
  • the computer network in which the invention is implemented - 22 - should be broadly construed to include any multicast computer network from which a client can retrieve a channel in a multicast environment.

Abstract

La présente invention concerne un procédé, un appareil et un support permettant le rétablissement rapide d'une connexion de multidiffusion perdue entre un utilisateur final et un groupe dans un environnement de multidiffusion. L'utilisateur final contrôle l'état actif des informations reçues et conserve une liste des canaux de communication multidiffusion nécessaires au rétablissement d'une connexion à un groupe. Par l'utilisation d'une greffe ou d'un raccordement provenant de l'utilisateur final basé sur la liste mémorisée d'identificateurs de canaux de communication multidiffusion (S, G), lorsque les informations reçues ne sont plus actives, un utilisateur final peut rejoindre rapidement un groupe multidiffusion avec un temps d'arrêt minimum.
PCT/US1999/005731 1998-03-16 1999-03-16 Procede, appareil et support de retablissement par greffe/raccordement de multidiffusion en un temps reduit WO1999048246A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2000537343A JP2002507857A (ja) 1998-03-16 1999-03-16 最小時間のマルチキャストグラフト・ジョイン復元の方法、装置および媒体
EP99912580A EP1062766A1 (fr) 1998-03-16 1999-03-16 Procede, appareil et support de retablissement par greffe/raccordement de multidiffusion en un temps reduit
AU30926/99A AU3092699A (en) 1998-03-16 1999-03-16 Method, apparatus, and medium for minimal time multicast graft/join restoration

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US3937598A 1998-03-16 1998-03-16
US09/039,375 1998-03-16

Publications (1)

Publication Number Publication Date
WO1999048246A1 true WO1999048246A1 (fr) 1999-09-23

Family

ID=21905126

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/005731 WO1999048246A1 (fr) 1998-03-16 1999-03-16 Procede, appareil et support de retablissement par greffe/raccordement de multidiffusion en un temps reduit

Country Status (4)

Country Link
EP (1) EP1062766A1 (fr)
JP (1) JP2002507857A (fr)
AU (1) AU3092699A (fr)
WO (1) WO1999048246A1 (fr)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001082548A2 (fr) * 2000-04-17 2001-11-01 Ladr It Corporation Procede et systeme, permettant de proteger des sites de l'internet contre des attaques debouchant sur un refus de prestation de services, utilisant une technique de saut d'adresses multidestinataires ip
WO2001091397A2 (fr) * 2000-05-22 2001-11-29 Ladr It Corporation Procede et systeme permettant la mise en oeuvre de fonctions de protection contre les attaques entrainant un refus de prestation de services et l'analyse du trafic dans le cadre des reseaux prives virtuels bases ip et distribution de donnees via l'utilisation d'une technique de saut d'adresses multicast ip
WO2002003704A1 (fr) * 2000-06-30 2002-01-10 Intel Corporation Systeme et procede de fractionnement d'un train de donnees insensible aux defaillances
US6651141B2 (en) 2000-12-29 2003-11-18 Intel Corporation System and method for populating cache servers with popular media contents
US6687846B1 (en) 2000-03-30 2004-02-03 Intel Corporation System and method for error handling and recovery
CN1324863C (zh) * 2003-03-28 2007-07-04 三星电子株式会社 针对基于cbt的层叠组播配置基于方向的基于核心的树
US7318107B1 (en) * 2000-06-30 2008-01-08 Intel Corporation System and method for automatic stream fail-over
WO2009106131A1 (fr) 2008-02-26 2009-09-03 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et appareil pour un service de diffusion/multidiffusion fiable
US8924466B2 (en) 2002-02-14 2014-12-30 Level 3 Communications, Llc Server handoff in content delivery network
US8930538B2 (en) 2008-04-04 2015-01-06 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)
CN104967974A (zh) * 2008-02-26 2015-10-07 艾利森电话股份有限公司 用于可靠的广播/组播服务的方法和设备
US9762692B2 (en) 2008-04-04 2017-09-12 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)
US10924573B2 (en) 2008-04-04 2021-02-16 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0688121A1 (fr) * 1994-06-15 1995-12-20 T.R.T. Telecommunications Radioelectriques Et Telephoniques Système d'interconnexion de réseaux locaux et équipement destiné à être utilisé dans un tel système

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0688121A1 (fr) * 1994-06-15 1995-12-20 T.R.T. Telecommunications Radioelectriques Et Telephoniques Système d'interconnexion de réseaux locaux et équipement destiné à être utilisé dans un tel système

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BILLHARTZ T ET AL: "PERFORMANCE AND RESOURCE COST COMPARISONS FOR THE CBT AND PIM MULTICAST ROUTING PROTOCOLS", IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, vol. 15, no. 3, 1 April 1997 (1997-04-01), pages 304 - 314, XP000683934, ISSN: 0733-8716 *
DEERING S ET AL: "AN ARCHITECTURE FOR WIDE-AREA MULTICAST ROUTING", COMPUTER COMMUNICATIONS REVIEW, vol. 24, no. 4, 1 October 1994 (1994-10-01), pages 126 - 135, XP000477046, ISSN: 0146-4833 *

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6687846B1 (en) 2000-03-30 2004-02-03 Intel Corporation System and method for error handling and recovery
WO2001082548A3 (fr) * 2000-04-17 2004-02-26 Ladr It Corp Procede et systeme, permettant de proteger des sites de l'internet contre des attaques debouchant sur un refus de prestation de services, utilisant une technique de saut d'adresses multidestinataires ip
WO2001082548A2 (fr) * 2000-04-17 2001-11-01 Ladr It Corporation Procede et systeme, permettant de proteger des sites de l'internet contre des attaques debouchant sur un refus de prestation de services, utilisant une technique de saut d'adresses multidestinataires ip
WO2001091397A2 (fr) * 2000-05-22 2001-11-29 Ladr It Corporation Procede et systeme permettant la mise en oeuvre de fonctions de protection contre les attaques entrainant un refus de prestation de services et l'analyse du trafic dans le cadre des reseaux prives virtuels bases ip et distribution de donnees via l'utilisation d'une technique de saut d'adresses multicast ip
WO2001091397A3 (fr) * 2000-05-22 2002-08-08 Ladr It Corp Procede et systeme permettant la mise en oeuvre de fonctions de protection contre les attaques entrainant un refus de prestation de services et l'analyse du trafic dans le cadre des reseaux prives virtuels bases ip et distribution de donnees via l'utilisation d'une technique de saut d'adresses multicast ip
US7318107B1 (en) * 2000-06-30 2008-01-08 Intel Corporation System and method for automatic stream fail-over
WO2002003704A1 (fr) * 2000-06-30 2002-01-10 Intel Corporation Systeme et procede de fractionnement d'un train de donnees insensible aux defaillances
GB2381428A (en) * 2000-06-30 2003-04-30 Intel Corp System and method for fault tolerant stream splitting
GB2381428B (en) * 2000-06-30 2004-06-23 Intel Corp System and method for fault tolerant stream splitting
US7020709B1 (en) 2000-06-30 2006-03-28 Intel Corporation System and method for fault tolerant stream splitting
US6651141B2 (en) 2000-12-29 2003-11-18 Intel Corporation System and method for populating cache servers with popular media contents
US9167036B2 (en) 2002-02-14 2015-10-20 Level 3 Communications, Llc Managed object replication and delivery
US9992279B2 (en) 2002-02-14 2018-06-05 Level 3 Communications, Llc Managed object replication and delivery
US10979499B2 (en) 2002-02-14 2021-04-13 Level 3 Communications, Llc Managed object replication and delivery
US8924466B2 (en) 2002-02-14 2014-12-30 Level 3 Communications, Llc Server handoff in content delivery network
CN1324863C (zh) * 2003-03-28 2007-07-04 三星电子株式会社 针对基于cbt的层叠组播配置基于方向的基于核心的树
US8611210B2 (en) 2008-02-26 2013-12-17 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for reliable broadcast/multicast service
CN104967974A (zh) * 2008-02-26 2015-10-07 艾利森电话股份有限公司 用于可靠的广播/组播服务的方法和设备
US9370027B2 (en) 2008-02-26 2016-06-14 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for reliable broadcast/multicast service
WO2009106131A1 (fr) 2008-02-26 2009-09-03 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et appareil pour un service de diffusion/multidiffusion fiable
CN104967974B (zh) * 2008-02-26 2019-07-30 艾利森电话股份有限公司 用于可靠的广播/组播服务的方法和设备
EP2566101A1 (fr) 2008-02-26 2013-03-06 Telefonaktiebolaget L M Ericsson AB (Publ) Procédé et dispositif pour un service de diffusion/multidiffusion fiable
US8930538B2 (en) 2008-04-04 2015-01-06 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)
US9762692B2 (en) 2008-04-04 2017-09-12 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)
US10218806B2 (en) 2008-04-04 2019-02-26 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)
US10924573B2 (en) 2008-04-04 2021-02-16 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)

Also Published As

Publication number Publication date
AU3092699A (en) 1999-10-11
JP2002507857A (ja) 2002-03-12
EP1062766A1 (fr) 2000-12-27

Similar Documents

Publication Publication Date Title
EP0980608B1 (fr) Procede et commutateur multidiffusion
US7944811B2 (en) Multiple multicast forwarder prevention during NSF recovery of control failures in a router
US8953604B2 (en) Root node redundancy for multipoint-to-multipoint transport trees
US9077551B2 (en) Selection of multicast router interfaces in an L2 switch connecting end hosts and routers, which is running IGMP and PIM snooping
Levine et al. Improving internet multicast with routing labels
US7860093B2 (en) Fast multicast convergence at secondary designated router or designated forwarder
US6654371B1 (en) Method and apparatus for forwarding multicast data by relaying IGMP group membership
US7768913B1 (en) Delivering and receiving multicast content across a unicast network
US20020143951A1 (en) Method and system for multicast to unicast bridging
US9106569B2 (en) System and method that routes flows via multicast flow transport for groups
US20060050643A1 (en) Router for multicast redundant routing and system for multicast redundancy
US8599851B2 (en) System and method that routes flows via multicast flow transport for groups
US20030193958A1 (en) Methods for providing rendezvous point router redundancy in sparse mode multicast networks
EP1804423A2 (fr) Procédé de recouvrement rapide de service multidiffusion et dispositif de réseau
US7660268B2 (en) Determining the presence of IP multicast routers
WO1999048246A1 (fr) Procede, appareil et support de retablissement par greffe/raccordement de multidiffusion en un temps reduit
JP3824906B2 (ja) ネットワーク間接続方法、その装置およびその装置を用いたネットワーク間接続システム
Ballardie et al. Core Based Tree (CBT) Multicast
Cisco Configuring IP Multicast Layer 3 Switching
CN114915588B (zh) 用于任播部署的上游多播跳umh扩展
Jia et al. Efficient internet multicast routing using anycast path selection
Xylomenos et al. IP multicasting for point-to-point local distribution
CN117978721A (zh) 用于任播部署的上游多播跳umh扩展
Nugraha et al. Multicast communication for video broadcasting service over IPv4 network using IP option

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase

Ref country code: KR

ENP Entry into the national phase

Ref country code: JP

Ref document number: 2000 537343

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 1999912580

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1999912580

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 1999912580

Country of ref document: EP