Patent Application
20070165632
This application relates generally to multicasting over data communication networks. In an example embodiment, a method and system is described for providing a rendezvous point (RP) facility in sparse mode protocol independent multicast (PIM) communications over a communication network.
A multicast network which uses sparse mode PIM requires a RP to build and to manage a shared tree, and to communicate with host computer systems needing to send or receive multicast data packets. The RP is assigned to one or more routers. RP redundancy is desirable for continuing functioning of the multicast network when the router serving as RP fails or otherwise becomes inoperative.
Current redundancy solutions include assigning the same IP (Internet Protocol) address associated with the RP (further referred to as the RP address) to a plurality of routers, forming a so-called PIM Anycast RP. This arrangement has some advantages, but may require use of MSDP (Multi Source Discovery Protocol) to keep the routing tables of the routers synchronised. Another solution comprises changing the RP address when the RP fails, so that the new RP address corresponds to that of a different router. However, the new RP address has to be communicated to other routers in the network. A further solution includes changing the IP address of a newly designated router to the RP address, but this change is relatively slow.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of an embodiment of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.
In
The network 100 is a multicast network which uses sparse mode PIM. It will be appreciated by a person skilled in the art that sparse mode PIM uses a pull model to send multicast traffic, so that only hosts 122-126 which have explicitly requested to receive multicast traffic will receive it. This can be distinguished from dense mode PIM that uses a push model in which every host 122-126 will be sent multicast traffic until that host explicitly requests not to receive multicast traffic.
In a sparse mode PIM system, information about hosts 122-126 which send multicast data (e.g., multicast sources) is communicated by forwarding data packets on a shared tree. Because sparse mode PIM uses a shared tree (at least initially), the use of a RP, which forms the root of the shared tree, is required. A source, for example host 122, therefore, in use, sends data packets to a designated router 114 on the sub-network of the host 122. The designated router 114 in turn encapsulates and sends data packets to the RP, which forwards the data packets down the shared tree to a multicast group. All routers 112, 114 in a path from the source to the RP set a (S, G) flag which indicates that a source 122 in their path is sending multicast data.
Receivers, for example hosts 124, 126 similarly indicate that they wish to receive multicast data by sending join messages to designated routers, for example routers 116, 120 respectively, on the sub-network of the hosts 124, 126. The designated routers 116, 120 in turn encapsulate and send join messages to the RP. All routers 116-120 in a path from the respective receivers 124, 126 to the RP set a (*, G) flag, which indicates that multicast data is to be sent from the RP along their path. The flag (*, G) is used to create the shared tree.
The shared tree in sparse mode PIM is unidirectional, which means that multicast data is forwarded to the root of the shared tree (e.g., the RP), from which the data is forwarded down the shared tree. In bidirectional PIM, multicast data is forwarded both up and down the shared tree. The shared tree still needs a root and is rooted at the RP, but the RP need not be a router 104-110 and can merely be an IP address reachable on the network 100.
A sparse mode PIM network 100 therefore requires a RP, and it further requires that the RP be associated with a physical router 104-110. In accordance with an embodiment, the RP is provided by one of the routers 104-110 in the sub-network 102. Each router 104-110 in the sub-network 102 has a respective individual primary IP address assigned to it. In conventional format, each IP address comprises, in decimal format, four fields separated by periods. The first three fields of each of the routers' IP addresses are identical, due to the routers' forming part of the same sub-network 102. The final field of the respective primary IP addresses, however, are different. In this example, the IP address of the sub-network 102 may be 10.1.1.0, the IP addresses of the routers 104-110 being 10.1.1.1, 10.1.1.2, 10.1.1.3, and 10.1.1.4 respectively. In this example, the first 24 bits (which represent the first three fields in the dotted syntax given above) of the IP addresses are used to identify the sub-network 102, so that the sub-network 102 in this example is a /24 sub-network. It is to be appreciated, however, that the method and system are applicable to sub-networks having IP configurations ranging from /2 to /30.
An IP address assigned to the RP (further referred to as the RP address) also corresponds to the IP address of the sub-network 102, in that the first three fields are identical, but the RP address is different from the primary IP addresses of the respective routers 104-110. The IP address of the RP is, in this example, 10.1.1.250.
Each router 104-110 within the sub-network 102 has stored thereon a computer program comprising a set of computer readable instructions which are executable to direct the operation of the routers 104-110. The computer readable instructions include designation rules to select one of the routers 104-110 as the DR (Designated Router). In this example, the rule is that the router 104-110 which has the highest IP address and which is operative is selected as the DR. It is to be appreciated, however, that other rules can be selected and that, for example, the IP addresses, the routing speeds, the capacities, and/or the physical locations of the routers 104-110 can be taken into account in selection of the DR.
The example router 106 includes a processor 302 (e.g., a central processing unit (CPU)), a main memory 304 and a static memory 306, which communicate with each other via a bus 308. The router 106 may further include a display device 310 (e.g., a liquid crystal display (LCD), a cathode ray tube (CRT), or a cluster of light emitting diodes (LEDs)). The router 106 may also include a disk drive unit 316, and a network interface device 320.
The disk drive unit 316 includes a machine-readable medium 322 on which is stored one or more sets of instructions and data structures (e.g., software 324) embodying or utilized by any one or more of the methodologies or functions described herein. The software 324 may also reside, completely or at least partially, within the main memory 304 and/or within the processor 302 during execution thereof by the router 106, the main memory 304 and the processor 302 also constituting machine-readable media.
The software 324 may further be transmitted or received over a network 326 via the network interface device 320 utilizing any one of a number of well-known transfer protocols (e.g., HTTP).
While the machine-readable medium 322 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such a set of instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
The processor 302, when executing the instructions 324, in co-operation with hardware of the router 106, provides, inter alia, an address arrangement 328, an activation component 330, an RP module 332, a monitoring module 334, and a selection component 336.
The address arrangement 328 includes at least an individual IP address assigned specifically to the router 106, and preferably an additional IP address corresponding with the RP address.
The activation component 330 is operable to modify the address arrangement 328 in the event of designation of the router 106 as DR., modification of the address arrangement 328 comprising activation of the additional IP address, so that both the individual IP address of the router 106 and the RP address are active. More specifically, the activation component 330 is operable to deactivate the RP address on each of the other routers on the sub-network 102 by sending an address resolution communication to the other routers.
The RP module 332 is operable to perform RP processing when the RP address has been activated as an additional address, so that the router 106 performs RP processing on the sub-network 102.
The monitoring module 334 is operable intermittently to communicate the status of the router 106 to a plurality of other routers on a shared sub-network and to receive similar status communications from the other routers, to monitor the status of at least a designated router (DR) which performs RP processing on the sub-network 102.
The selection component 336 is operable to select, in co-operation with the other routers on the sub-network 102, one of the routers as new DR in the event of a failure event associated with the DR. The selection component 336 includes designation rules for automatically selecting a new DR upon failure of the DR.
In use, and referring now also to
When a particular router has been selected as the DR, the selected router (e.g., router 110) then takes over the DR functionality which, in an example embodiment, includes installing a secondary IP address on that subnet interface (see block 208). It will be appreciated that other routers on the network are unaffected by the designation of the DR by the sub-network 102. Once the router has been designated as the DR, the DR 110 has an active secondary IP address which corresponds to the RP address.
Thus, in an example embodiment, the DR 110 now has two IP addresses: a primary IP address and secondary IP address which is the RP address. The sub-network 102 thus provides an RP facility for multicasting in sparse mode PIM, all data packets being sent to the RP address being forwarded to the DR 110 for processing to perform rendezvous point processing in the usual fashion.
At block 210 the designated router is monitored to determine if it operative and functional. As shown at decision block 212, if the designated router remains operative there is no need to designate another router as the DR and the RP functionality continues to be performed by the DR (see branch 212.1).
If, however, the DR (e.g., the router 110) becomes inoperative, one of the other routers 104-108 must be designated as the new DR. In the given example, the router with the next highest IP address is selected as the DR (e.g., router 108 with IP address 10.1.1.3). Accordingly, as shown by branch 212.2, a new DR is identified and selected, at block 206, as the new DR.
In the given example the DR 108 now has two IP addresses: a primary IP address and a secondary IP address which is the RP address. The sub-network 102 thus still has a RP which is reachable at the same RP address which was used previously, even though RP processing is now done by the new DR 108.
The routers 112-120 and hosts 122-126 outside the sub-network 102 continue to communicate in sparse mode PIM with the RP in conventional fashion, and are oblivious to a change in the DR. The RP, regardless of which router 104-110 is acting as the RP, may also communicate with the routers 112-120 and hosts 122-126 outside the sub-network 102 in conventional fashion.
Thus, in an embodiment, RP redundancy may be provided by providing a secondary IP address without a need to change the IP address of the RP. Associating the RP with a new router 104-110 should the DR become inoperative is relatively quick, as no IP addresses need to be changed. In the example embodiments described above, the operative DR with the highest address is selected as the RP. It will be appreciated that the different rules may be used in other embodiments to select the RP. Further, the configuration of the router may be a static configuration, a BSR configuration, or an auto RP configuration.
Unlike a conventional system where the RP corresponds with a physical device and a host may route the RP to different physical locations on a network, in example embodiments of the present application, the RP address is not fixed to a physical device. Rather, the DR that is on the same subnet as the RP address becomes responsible for performing the RP functionality. RP functionality may thus be associated with a “phantom” RIP. In an example embodiment, by replacing an interface field in announce and candidate-RP configuration commands with a specific IP address, auto-RP and BSR can be used to distribute the Phantom RP.
In an embodiment, PIM RP distribution may remain as defined in the RFC 2362 using, for example, BSR, Auto-RP, and Static RPs. The phantom RP may be located as a virtual system on a subnet at the core of the network. This virtual system for Bidirectional PIM does not require any interaction with the rest of the routers in the PIM domain because PIM joins are sent toward this IP address and not to this IP address. Each router along the forwarding path must be able to process these PIM control messages.
The sparse mode PIM RFC requires the RP first to process PIM register packets, and secondly to trigger (S, G) joins toward the source listed in the PIM register if (*, G) state already exists. The PIM RIP may be identified by an IP address. PIM registers are sent to the PIM RP and processed only by the RP. Therefore the phantom RP methodology described herein may require delegation of these functions to a RP that is located on the same sub-network as the virtual router. For example, the IP address of the PIM RP might be 10.1.1.1/24 (the IP address is located on the subnet 10.1.1.0) so some system (router or switch) that is on this subnet (called the RP subnet) must perform the RP function. Each subnet within a PIM domain (networks configured to run PIM may select a DR (designated router) according to the PIM specifications. The DR may be the router which will be designated as the phantom RP (or proxy RP).
In an example embodiment, the phantom RP may install an additional IP address on its interface which is connected to the RP subnet, which means that PIM register messages will be sent to the phantom RP for processing which will occur as specified in the RFC.
Although an embodiment of the present invention has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
