Active multicast information protocol

BACKGROUND

0001In packet-switched networks, a router is a device or, in some cases, software in a computer, that determines the next network point to which a data packet should be forwarded toward its destination. The router is typically coupled to at least two routers and decides which way to send each data packet based on its current understanding of the state of the network to which it is connected. A router may create or maintain a table (hereinafter a “routing table”) of the available routes and their conditions and use this information along with distance and cost algorithms to determine the best route for a given data packet. Typically, a data packet may travel through a number of routers before arriving at its destination. Routing is a function associated with the network layer (i.e., layer 3) in the standard model of network programming, the Open Systems Interconnection (OSI) model.

0002Unicast, broadcast, and multicast are three well known techniques for transmitting data packets (e.g., audio and video data packets) from a source (e.g., a server) to one or more receivers (e.g., a desktop computer system) via packet-switched networks. Unicast is a point-to-point communication technique in which data packets are transmitted between a single source and a single receiver. Broadcast communication enables one source to transmit data packets to all receivers in a broadcast domain. Multicasting allows a source or several sources to transmit data packets simultaneously to select receivers, i.e., those receivers in a multicast group. During multicast transmission, multicast data packets are replicated by multicast enabled routers at the point where communication paths diverge to separate receivers of a multicast group. In this fashion, the multicast protocol delivers data to multiple receivers without burdening the source or consuming excessive network bandwidth.

0003There are several different multicast protocols, including but limited to Sparse Mode (SM) and Source Specific Mode (SSM). The SM protocol may be defined in Internet Engineering Task Force (IETF) Request For Comments (RFC) 2362 entitled “Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification,” published in June 1998, and hereby incorporated by reference in its entirety, or in revisions thereof. The SSM protocol may be defined RFC 3569 entitled “An Overview of Source-Specific Multicast (SSM),” published in July 2003, and hereby incorporated by reference in its entirety, or in revisions thereof.

0004<figref idref="DRAWINGS">FIG. 1</figref> illustrates relevant components of a packet-switched network <b>10</b> that can employ either SM or SSM protocols. More particularly, <figref idref="DRAWINGS">FIG. 1</figref> shows sources <b>12</b> coupled to receivers <b>14</b> (or potential receivers) via a series of routers <b>16</b> and data communication links <b>20</b>. In SM networks, the various multicast enabled routers establish a default multicast distribution tree, referred to as a “shared tree,” for each multicast group. The shared tree is rooted at a rendezvous point (RP) router that acts as the distribution point for multicast data transmitted to receivers of a multicast group. Before a source can begin transmitting data to receivers of a multicast group, the RP router must discover or learn about that source. The RP router learns of the source when the source first registers with the RP router. Moreover, for a receiver to join a multicast group, the receiver must join towards the RP router. Once a receiver joins a multicast group, the RP router establishes a communication path between one or more sources and the newly joined receiver.

0005To further illustrate, presume that router <b>16</b><i>d </i>is configured in network <b>10</b> as the RP router for a multicast group G₁consisting of receivers <b>14</b><i>a </i>and <b>14</b><i>b</i>. Further, presume that device <b>14</b><i>c </i>seeks to join multicast group G₁as a receiver. Device <b>14</b><i>c </i>can join the multicast group by first generating a membership report in compliance with Internet Management Group Protocol version 1 (IGMPv1) or Internet Management Group Protocol version 2 (IGMPv2). The address G₁of the multicast group is included in the membership report along with the address (e.g., an Internet address) of device <b>14</b><i>c</i>. It is noted that IGMP is the terminology used in IPv4. In IPv6, IGMP is referred to as Multicast Listener Discovery (MLD). Thus, MLDv1 is the same as IGMPv2 and MLDv2 is the same as IGMPv3.

0006The IGMP membership report is transmitted by device <b>14</b><i>c </i>to edge router <b>16</b><i>h </i>via data communication link <b>20</b><i>k</i>. Edge router <b>16</b><i>h</i>, in response to receiving the IGMP report from device <b>14</b><i>c</i>, generates a request to join multicast group G₁. In SM networks, this request is designated PIM (*, G₁) JOIN, and its sent hop by hop towards RP router <b>16</b><i>d</i>. The “*” within the request indicates that the device (e.g., device <b>14</b><i>c</i>) seeking to join multicast group G₁should receive data from all sources providing data to the multicast group G₁. Thus, if sources <b>12</b><i>a </i>and <b>12</b><i>b </i>are providing data to receivers within the multicast group G₁, device <b>14</b><i>c </i>will receive data from both sources <b>12</b><i>a </i>and <b>12</b><i>b </i>once device <b>14</b><i>c </i>joins multicast group G₁as a receiver. For purposes of explanation, it will be presumed that device <b>12</b><i>a </i>is the only source providing data to multicast group G₁.

0007The PIM (*, G₁) JOIN is transmitted by edge router <b>16</b><i>h </i>to RP router <b>16</b><i>d</i>. RP router <b>16</b><i>d</i>, in response to receiving PIM (*, G₁) JOIN, accesses at table to learn the identity (e.g., addresses) of sources transmitting data to multicast group G₁. Once the source identities are known, RP router <b>16</b><i>d </i>creates a communication path between the sources and device <b>14</b><i>c</i>. For purposes of explanation, it will be presumed that the table in RP router <b>16</b><i>d </i>indicates that only source <b>12</b><i>a </i>is transmitting data to multicast group G₁. Accordingly, RP router <b>16</b><i>d </i>creates a communication path between source <b>12</b><i>a </i>and device <b>14</b><i>c </i>that includes RP router <b>16</b><i>d</i>. Device <b>14</b><i>c </i>receives data packets from source <b>12</b> once this communication path is established.

0008After the communication path is established between source device <b>12</b><i>a </i>and receiver <b>14</b><i>c</i>, edge router <b>16</b><i>h </i>may trigger a routine to create a faster and/or more efficient communication path between source <b>12</b><i>a </i>and receiver <b>14</b><i>c </i>that may not include RP router <b>16</b><i>d</i>. The new and more efficient communication path between source <b>12</b><i>a </i>and receiver <b>14</b><i>c </i>is often referred to as a source specific multicast tree. Once the new and more efficient communication path is established, the original communication path though RP router <b>16</b><i>d </i>is pruned away. Unfortunately, the creation of a new and more efficient source specific multicast tree and the subsequent pruning of the original communication path, adds complexity to the overall operation of network <b>10</b>.

0009As noted above, network <b>10</b> may also operate according to the SSM protocol. Unlike an SM network, an SSM network does not employ an RP router. In SSM protocol networks, when a device seeks to join a multicast group as a receiver, the device will know in advance the identity of the source or sources from which it seeks to receive multicast data. This enables a new receiver to directly join a multicast group on the shortest path tree towards the source or sources (i.e., without first going through an RP router). When more than one source is transmitting data packets to a multicast group, SSM networks enable multicast group receivers to select one or more the sources from which to receive data. Compared to the SM protocol, the SSM protocol is more efficient.

0010To illustrate operational aspects of SSM protocol, presume that network <b>10</b> operates according to the SSM protocol, and that devices <b>14</b><i>a </i>and <b>14</b><i>b </i>are receiver members of a multicast group G₂that receive data from source <b>12</b><i>a</i>. Further, presume that device <b>14</b><i>c </i>seeks to join multicast group G₂as a new receiver. Typically, before device <b>14</b><i>c </i>can join multicast group G₂, device <b>14</b><i>b </i>must generate a membership report using IGMP version 3 (IGMPv3) protocol. It is noted that device <b>14</b><i>c </i>can join multicast group G₂as a receiver even though device <b>14</b><i>c </i>executes only IGMPv1 or IGMPv2 if device <b>14</b><i>c </i>and/or edge router <b>16</b><i>h </i>implement the method described in U.S. patent application Ser. No. 10/208,977 entitled “Source Specific Multicast Group to Source Mapping,” filed on Jul. 31, 2002; Attorney Docket Number CIS0174US. The foregoing patent application is incorporated herein by reference in its entirety. However, for purposes of explanation, it will be presumed that device <b>14</b><i>c </i>operates according to IGMPv3 only.

0011The IGMPv3 membership report identifies both the source device <b>12</b><i>a </i>and the multicast group that device <b>14</b><i>c </i>wishes to join. In contrast, the IGMPv1 or IGMPv2 membership report generated for the SM protocol does not identify the source from which data is sought. The IGMPv3 report generated by device <b>14</b><i>c </i>is transmitted to edge router <b>16</b><i>h</i>. Thereafter edge router <b>16</b><i>h </i>establishes a fast and efficient communication path between source device <b>12</b><i>a </i>and device <b>14</b><i>c </i>which does not include router <b>16</b><i>d</i>, but which may include routers <b>16</b><i>a</i>, <b>16</b><i>b</i>, <b>16</b><i>f</i>, <b>16</b><i>g</i>, and <b>16</b><i>h</i>. With this communication path established, source device <b>12</b><i>a </i>transmits data to receiver device <b>14</b><i>c </i>while also transmitting data to the other receivers in multicast group G₂.

0012As noted, traditional SM networks require an RP router for source discovery. However, for some SM networks, the existence of an RP router is not desired. A mobile network in which routers are mobile and in data communication with each other via wireless communication network, is one example where the existence of an RP router is not desired. One reason an RP routers is not desired in a mobile network is that it is not known in advance which routers in the network will be active. In order to guarantee operation in a mobile network that employs SM protocol, each router must be able to operate as an RP router. This may also lead to the added difficulty that it is not known which router will act as the active RP at a given point in time. This causes operational problems in the field, since network operators want the network to be predictable. Accordingly, a need exists for an invention that enables communication in an SM network that lacks an RP router.

BRIEF DESCRIPTION OF THE DRAWINGS

0013The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.

0014<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating relevant components of a packet-switched

0015network;

0016<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram illustrating relevant components of a packet switched network employing one embodiment of the present invention;

0017<figref idref="DRAWINGS">FIG. 3</figref> illustrates relevant operational aspects performed by an edge router in the network of <figref idref="DRAWINGS">FIG. 2</figref> in response to receiving data packets from an active source;

0018<figref idref="DRAWINGS">FIG. 4</figref> illustrates relevant operational aspects performed by an edge router in the network of <figref idref="DRAWINGS">FIG. 2</figref> in response to receiving an active source message;

0019<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram representation of a typical active source look-up table;

0020<figref idref="DRAWINGS">FIG. 6</figref> illustrates relevant operational aspects performed by an edge router in the network of <figref idref="DRAWINGS">FIG. 2</figref> in response to receiving an IGMP membership report from a device coupled to the edge router;

0021<figref idref="DRAWINGS">FIG. 7</figref> illustrates relevant operational aspects performed by an edge router coupled to an active source;

0022<figref idref="DRAWINGS">FIG. 8</figref> illustrates relevant operational aspects performed by an edge router in the network of <figref idref="DRAWINGS">FIG. 2</figref> in maintaining its local active source look-up table;

0023<figref idref="DRAWINGS">FIG. 9</figref> illustrates relevant components of a router.

0024The use of the same reference symbols in different drawings indicates similar or identical items.

DETAILED DESCRIPTION

0025The present invention is directed to a method, apparatus, or instructions that when executed by one or more processors, enables a device to join a multicast group as a receiver in an SM protocol network that lacks an RP router. The present invention can be employed in a network operating under any one of several distinct versions of Internet Protocol (IP) including IP versions <b>4</b> or <b>6</b>. The present invention will be described with reference to an SM network <b>30</b> shown in <figref idref="DRAWINGS">FIG. 2</figref>. It is noted that the present invention can be employed in a network other than that described and shown in <figref idref="DRAWINGS">FIG. 2</figref>

0026Network <b>30</b> includes sources <b>32</b> coupled to devices <b>34</b> via a series of routers <b>36</b> and data communication links <b>40</b>. For purposes of explanation, devices <b>34</b> are receiver members of a multicast group, or devices which seek to join a multicast group as a receiver. All, some, or none of communication links <b>40</b> may be wireless communication links. Network <b>30</b> does not include an RP router or a router that is configured to operate as an RP router. Network <b>30</b> does include three edge routers <b>36</b><i>a</i>, <b>36</b><i>e</i>, and <b>36</b><i>h</i>. An edge router is a router that interfaces a source or a receiver. In other words, edge routers are coupled to a source and/or receiver (or a device seeking to join a multicast group as a receiver) without an intervening router. For example, router <b>36</b><i>a </i>is an edge router because there is no other router connected between it and source <b>32</b><i>a</i>. Network <b>30</b> also includes core routers <b>36</b><i>b</i>-<b>36</b><i>c</i>, <b>36</b><i>f</i>, and <b>36</b><i>g</i>. A core router is a router that has no sources or receivers coupled directly to it, it only acts as transit for other routers. Each of the routers <b>36</b><i>a</i>-<b>36</b><i>h </i>includes one or more processors which can execute instructions stored within memory (not shown). Additionally, each of the routers <b>36</b><i>a</i>-<b>36</b><i>h </i>includes memory with information identifying the router as an edge router or a core router.

0027Some or all of the edge routers of <figref idref="DRAWINGS">FIG. 2</figref> are configured to discover active sources coupled thereto in accordance with one embodiment of the present invention. For purposes of explanation, an active source is a source which is actively transmitting multicast data packets to one or more receivers of a multicast group. For purposes of explanation only, the present invention will be described with reference to source <b>32</b><i>a </i>transmitting data packets to receivers of a multicast group G₁. Accordingly, source <b>32</b><i>a </i>is an active source. Because edge routers of <figref idref="DRAWINGS">FIG. 2</figref> can discover active sources as will be more fully described below, the active sources of network <b>30</b> need not register with an RP router.

0028Edge routers, such as edge router <b>36</b><i>a</i>, discover active sources, such as source <b>32</b><i>a</i>, by analyzing data packets transmitted therefrom. Once discovered, edge router <b>36</b><i>a </i>alerts other edge routers about the existence of the active source. In one embodiment, edge router <b>36</b><i>a </i>can alert the other edge routers by flooding network <b>30</b> with active source messages. These active source messages contain information (e.g., addresses of active source <b>32</b><i>a </i>and/or the multicast group G₁to which the active source is transmitting data packets) unique to the active source. Eventually other edge routers receive the active source message, and store information such as the source and multicast group addresses contained within the active source messages into entries of an active source look-up table. The active source look-up tables enable edge routers to establish a source specific tree between sources and devices seeking to join multicast groups.

0029When a device seeks to join a multicast group as a receiver, the device can transmit an IGMP membership report to an edge router coupled thereto. The IGMP membership report generated by the device contains the address of the multicast group to be joined, but lacks the address of the source that transmits data packets to the multicast group. The edge router accesses its active source look-up table using the address of the multicast group contained within the IGMP membership report. The active source look-up table in turn returns the address of the source that provides data packets to the multicast group. Because the edge router that receives the IGMP membership report has the addresses of the multicast group and the source which provides data packets to this multicast group, the edge router can initiate the creation of a communication tree between the source and the device seeking to join the multicast group as a receiver without having to go through an RP router. In one embodiment, the edge router can initiate the creation of the communication path or tree using a PIM request to join which includes both the address of the multicast group contained within the IGMP membership report and the corresponding source address returned from the active source look-up table. A more detailed discussion is provided below.

0030Edge routers discover or confirm the continued existence of active sources when the edge routers receive multicast data packets from the active sources. <figref idref="DRAWINGS">FIG. 3</figref> illustrates operational aspects of a method for discovering or confirming the continued existence of an active source according to one embodiment of the present invention. The method of <figref idref="DRAWINGS">FIG. 3</figref> will be described with reference to edge router <b>36</b><i>a </i>coupled to active source <b>32</b><i>a</i>. More particularly, edge router <b>36</b><i>a </i>receives from active source <b>32</b><i>a </i>a data packet destined for a multicast group G₁, as shown in step <b>50</b>. Edge router <b>36</b><i>a </i>then accesses a routing table (not shown) to identify one or more routers of network <b>30</b> to which the data packet should be forwarded to reach the existing receivers of multicast group G₁. Edge router <b>36</b><i>a </i>forwards or routes the data packet received from active source <b>32</b><i>a </i>to one or more routers coupled thereto in accordance with information from the routing table as shown in step <b>52</b>. Given that core router <b>36</b><i>b </i>is the only router coupled to edge router <b>36</b><i>a </i>in the illustrated example, edge router <b>36</b><i>a </i>routes the data packet to only core router <b>36</b><i>b </i>in the illustrated example. Keep in mind here that edge router <b>36</b><i>a </i>may also not forward the data packet at all. If this is the first packet that the source sends, edge router <b>36</b><i>a </i>will only send out the active source message. Then depending if other edge routers join this source a forwarding tree will be established and subsequent packets will be forwarded to one or more other routers.

0031Also in response to receiving the data packet from active source <b>32</b><i>a</i>, edge router <b>36</b><i>a </i>generates an active source message. The active source message generated in step <b>54</b> may be one of several active source messages generated by edge router <b>36</b><i>a </i>after source <b>32</b><i>a </i>begins transmitting data packets to multicast group G₁. The active source message generated in step <b>54</b> includes the address identifying active source <b>32</b><i>a </i>and/or the address identifying multicast group G₁to which active source <b>32</b><i>a </i>is transmitting data packets. The active source message may also include additional information which will be more fully described below. The active source message, as shown in step <b>56</b>, is transmitted to all routers coupled to edge router <b>36</b><i>a</i>. Given that core router <b>36</b><i>b </i>is the only router coupled to edge router <b>36</b><i>a</i>, it follows that edge router <b>36</b><i>a </i>transmits the active source message only to core router <b>36</b> in this exemplary embodiment.

0032Since router <b>36</b><i>b </i>is designated a core router, core router <b>36</b><i>b </i>RPF floods network <b>30</b> with the active source message it receives. In RPF flooding, core routers forward a copy of the active source message to each router coupled thereto, except for the router from which the active source message was received. Accordingly, in the illustrated example, core router <b>36</b><i>b </i>forwards the active source message generated in step <b>54</b> to only core routers <b>36</b><i>f </i>and <b>36</b><i>c. </i>

0033Eventually, through RPF flooding, edge routers <b>36</b><i>b </i>and <b>36</b><i>h </i>receive a copy of the active source message initially generated by edge router <b>36</b><i>a </i>in step <b>54</b> of <figref idref="DRAWINGS">FIG. 3</figref>. Edge routers, in response to receiving an active source message, may update their active source look-up tables with the source and multicast group addresses contained in the received active source message. To illustrate, <figref idref="DRAWINGS">FIG. 4</figref> shows operational aspects of a method performed by edge router <b>36</b><i>h </i>in response to receiving the active source message generated in step <b>54</b> of <figref idref="DRAWINGS">FIG. 3</figref>. It is noted that edge router <b>36</b><i>e </i>may also implement the method shown within <figref idref="DRAWINGS">FIG. 4</figref>. Edge router <b>36</b><i>h</i>, in step <b>62</b>, accesses its active source look-up table in response to receiving the active source message directly or indirectly from edge router <b>36</b><i>a</i>. <figref idref="DRAWINGS">FIG. 5</figref> illustrates an exemplary active source look-up table <b>64</b> accessible by edge router <b>36</b><i>a</i>. As can be seen, active source look-up table includes multiple entries, each one of which contains a validity bit and corresponding source and multicast addresses. The validity bit is set to logical <b>1</b> if the entry is considered valid. Otherwise, the entry is considered invalid.

0034The edge router <b>36</b><i>h </i>accesses its active source look-up table to determine whether it contains a valid entry containing the source and multicast group addresses of the active source message received in step <b>60</b>. If it is determined in step <b>66</b> that the active source look-up table does not contain a valid entry having the source/multicast group addresses, then edge router <b>36</b><i>h </i>creates a new valid entry having the source/multicast group address pair of the active source message received in step <b>60</b>. It is noted that a new valid entry can be created in the active source look-up table simply by validating an otherwise invalid entry in the look-up table that contains the source/multicast address pair. If edge router <b>36</b><i>a </i>determines in step <b>66</b> that its look-up table contains a valid entry having the source/multicast address pair, the process of <figref idref="DRAWINGS">FIG. 4</figref> ends.

0035Active source look-up tables within edge routers enable the creation of a communication path in an SM network between a source and a device seeking to join a multicast group to which the source transmits data, notwithstanding the lack of an RP router within the SM network. To illustrate, presume that device <b>34</b><i>c </i>in <figref idref="DRAWINGS">FIG. 2</figref> seeks to join the multicast group G₁as a receiver. <figref idref="DRAWINGS">FIG. 6</figref> illustrates relevant operational aspects of a method performed by edge routers, such as edge router <b>36</b><i>h</i>, in response to receiving an IGMP membership report or other request to join a multicast group such as multicast group G₁. As noted in step <b>80</b> of <figref idref="DRAWINGS">FIG. 6</figref>, edge router <b>36</b><i>h </i>receives an IGMP membership report or other request from device <b>34</b><i>c</i>. This membership report includes the address (e.g., GA₁) of the multicast group G₁that device <b>34</b><i>c </i>seeks to join as a receiver. In response, edge router <b>36</b><i>h </i>accesses its local active source look-up table using the multicast group address GA₁of the IGMP membership. All of the edge routers of network <b>30</b> should contain or have access to its own active source look-up table. The contents of the various active source look-up tables should be identical.

0036In step <b>84</b>, the active source look-up table returns a corresponding source address (e.g. SA₁) of the source <b>32</b><i>a </i>that transmits data to group G₁. In step <b>86</b>, edge router <b>36</b><i>h </i>generates a PIM request to join the multicast group G₁. This PIM request to join includes the address GA₁of the multicast group and the address SA₁returned from the active source look-up table. Edge router <b>36</b><i>h </i>transmits the PIM request to join, which in turn, initiates the creation of the communication path from source <b>32</b><i>a </i>and device <b>34</b><i>c. </i>

0037Employing the principles set forth in <figref idref="DRAWINGS">FIG. 3-6</figref>, the basic principles of PIM sparse mode operations can occur within an SM network lacking an RP router. Further, employing the principles of the invention described with reference to <figref idref="DRAWINGS">FIGS. 2-6</figref>, no shared trees need be used when a device seeks to join a multicast group as a receiver. Only edge routers must maintain the list of active sources in the network. Core routers can choose only to flood the active source messages originating from the edge routers coupled to active sources. Using the invention, there is no single router within network <b>30</b> which can be a point of failure, nor is there a single router (e.g., an RP router) which must carry the load of identifying all the active sources.

0038The active source look-up tables (e.g., look-up table <b>64</b> of <figref idref="DRAWINGS">FIG. 5</figref>) are used to maintain a listing of active sources within network <b>30</b>. When a source deactivates (i.e., terminates the sending of packets to a multicast group of receivers), all active source look-up tables should be updated accordingly. In other words, entries in the active source look-up tables should be removed or otherwise invalidated when corresponding sources stop transmitting data packets to their respective multicast group receivers. There are several methods for maintaining the active source look-up tables. In one method, an active source message generated by edge router <b>36</b><i>a </i>during the process of <figref idref="DRAWINGS">FIG. 3</figref> may include a hold of time value. The hold time value defines a length of time the source will transmit data packets to its multicast receivers. Thus, the hold time defines the length of time the source/multicast group address pair of the message should be stored in a valid entry of an active look-up table. The edge router that receives the active source message and subsequently creates an entry in its active source look-up tables, will maintain the entry as valid until expiration of the hold time value.

0039<figref idref="DRAWINGS">FIGS. 7 and 8</figref> illustrate an alternative method of maintaining the active source look-up tables. The alternative method of <figref idref="DRAWINGS">FIG. 7</figref> will be described with reference to edge routers <b>36</b><i>a</i>, it being understood that other edge routers can function similarly. This alternative method does not require additional information such as the hold time value described above, to be included within active source messages. In steps <b>90</b> and <b>92</b> of <figref idref="DRAWINGS">FIG. 7</figref>, edge router <b>36</b><i>a </i>operates in a wait mode until it receives a new data packet from source <b>32</b><i>a </i>for multicast group G₁, thus indicating initial or continued transmission of data packets to the multicast group of receivers. Once a new data packet is received from source <b>32</b><i>a</i>, edge router forwards the newly received data packet to one or more routers in accordance with a routing table. Thereafter, edge router <b>36</b><i>a </i>determines whether a predetermined amount of time Ts has passed since edge router <b>36</b><i>a </i>last transmitted an active source message that contains address SA₁of source <b>32</b><i>a </i>and address GA₁of the multicast group G₁to which source <b>32</b><i>a </i>is transmitting data. If the predetermined amount of time Ts has passed, the process proceeds to step <b>100</b>, and edge router <b>36</b><i>a </i>generates a new active source message containing addresses SA₁and GA₁. The active source message generated in step <b>100</b> is transmitted through out network <b>30</b> using RPF flooding. If, however, it is determined in step <b>96</b> that a predetermined amount of time Ts has not passed since edge router <b>36</b><i>a </i>transmitted an active source message, then edge router <b>36</b><i>a </i>reenters the wait mode of steps <b>90</b> and <b>92</b>.

0040<figref idref="DRAWINGS">FIG. 8</figref> illustrates relevant operational aspects of a method implemented by the edge routers to maintain their active source look-up tables. The alternative method of <figref idref="DRAWINGS">FIG. 8</figref> will be described with reference to edge routers <b>36</b><i>h</i>, it being understood that other edge routers can function similarly. The process in <figref idref="DRAWINGS">FIG. 8</figref> begins with step <b>110</b> when edge router <b>36</b><i>h </i>receives an active source message from edge router <b>36</b><i>a</i>. Again, this active source message includes the addresses SA₁and GA₁of active source <b>32</b><i>a </i>and multicast group G₁, respectively. In response to receiving the active source message, edge router <b>36</b><i>h </i>in step <b>112</b> sets a timer t to zero. Timer t advances in time just after it is set to zero. Thereafter in step <b>114</b> edge router <b>36</b><i>h </i>accesses its local active source look-up table to determine whether it has a valid entry containing addresses SA₁and GA₁for the source and multicast group, respectively, identified in the message received in step <b>110</b>. Presuming that no such valid entry is contained within the look-up table, edge router <b>36</b><i>h </i>creates a new valid entry containing the addresses SA₁and GA₁. Edge router <b>36</b><i>h </i>then enters a wait mode for the next active source message from edge router <b>36</b><i>a </i>that contains addresses SA₁and GA₁.

0041During the wait mode of steps <b>120</b>-<b>124</b>, edge router <b>36</b><i>h </i>frequently compares timer t with T_max, a predetermined amount of time. In step <b>124</b>, if timer t is greater in time than T_max, <b>116</b> edge router <b>36</b><i>h </i>invalidates or removes the look-up table entry created in step <b>116</b> under the presumption that source <b>32</b><i>a </i>is no longer active. However, during the wait mode, if edge router receives a new active source message from edge router <b>36</b><i>a </i>before timer t exceeds the value of T_max, then the process returns to step <b>112</b> whereby timer t is reset to 0. As a result of the process shown in <figref idref="DRAWINGS">FIG. 8</figref>, edge router <b>36</b><i>h </i>invalidates or removes entries within the active source look-up table after a source deactivates.

0042It is noted that the processes in <figref idref="DRAWINGS">FIGS. 7 and 8</figref> are paired and correspond to one active source (i.e., source <b>32</b><i>a</i>). However, the same processes can be used to maintain each entry of the active look-up tables. Thus several instances of the process shown in <figref idref="DRAWINGS">FIG. 7</figref> can be running at any given point in time on edge router <b>36</b><i>a</i>, where each of the individual processes correspond to a distinct active source coupled to edge router <b>36</b><i>a</i>. Further, several instances of the process shown in <figref idref="DRAWINGS">FIG. 8</figref> can be running at any given point in time on edge router <b>36</b><i>h</i>, where each of these individual processes correspond to a distinct entry within the active source look-up table that is local to edge router <b>36</b><i>a. </i>

0043As noted above, additional information can be added to the active source message other than hold time values, active source addresses, or multicast group addresses. For example, the active source messages generated by edge router <b>36</b><i>a </i>may include a bandwidth value identifying the bandwidth needed to transmit data packets from an active source. Intermediate routers may decide not to flood this message if they know that the bandwidth contained within the active source message is not available on the data communication links between it and, for example, an edge router coupled thereto. The bandwidth value may also be used by the resource reservation protocol (RSVP) to set up a traffic engineered communication path to the corresponding active source. In addition to a bandwidth value, the active source message may also include a table distinguisher. Routers within the network may have several distinct routing tables to use when making a packet routing decision. Routers joining to the corresponding active source can use the table distinguisher to select one of a plurality of routing tables for reverse path forwarding (RSP). The active source message may also include a public key identifier that is needed to decrypt data contained within packets or to provide user level access control.

0044<figref idref="DRAWINGS">FIG. 9</figref> is a block diagram illustrating relevant components of an exemplary router <b>200</b> that can implement one or more of the methods described above. Router <b>200</b> includes two or more line cards <b>202</b> that are communicatively coupled to a forwarding engine <b>210</b> and a processor <b>220</b> via a data bus <b>230</b> and a result bus <b>240</b>. Although not shown, router <b>200</b> may include a memory for storing the active source look-up table Each of line cards <b>202</b> may include one or more port processors <b>250</b> which are controlled by port processor controllers <b>260</b>. It will also be noted that forwarding engine <b>210</b> and processor <b>220</b> are not only coupled to one another via data bus <b>230</b> and result bus <b>240</b>, but are also communicatively coupled to one another by a communications link <b>270</b>.

0045When a packet is received by a line card <b>202</b>, the packet may be identified and analyzed in the following manner. The packet (or some or all of its control information) is sent from the receiving port processor <b>250</b> to one or more devices coupled to data bus <b>230</b> (e.g., another port processor, forwarding engine <b>210</b> and/or processor <b>220</b>). Handling of the received packet can be determined by forwarding engine <b>210</b>. For example, forwarding engine <b>210</b> may determine that the received packet should be forwarded to one or more of port processors <b>250</b>. This can be accomplished by indicating to corresponding one or more port processor controllers <b>260</b> that a copy of the received packet should be forwarded to one or more appropriate port processors <b>250</b>.

0046In the foregoing process, network security information can be included in a frame sourced by router <b>200</b> in a number of ways. For example, forwarding engine <b>210</b> can be used to detect the need for the inclusion of network security information in the packet, and processor <b>220</b> can be called into service to provide the requisite network security information. This network security information can be included in the packet during the transfer of the packet's contents from one port processor <b>250</b> to another port processor <b>250</b>, by processor <b>220</b> providing the requisite information directly, or via forwarding engine <b>210</b>, for example. The assembled packet can thus be made to contain the requisite network security information.

0047In addition, or alternatively, once a packet has been identified for processing according to the present invention, forwarding engine <b>210</b>, processor <b>220</b> or the like can be used to process the packet in some manner or add packet security information, in order to secure the packet. On a node sourcing such a packet, this processing can include, for example, encryption of some or all of the packet's information, the addition of a digital signature or some other information or processing capable of securing the packet. On a node receiving such a processed packet, the corresponding process is performed to recover or validate the packet's information that has been thusly protected.

0048Although the present invention has been described in connection with several embodiments, the invention is not intended to be limited to the specific forms set forth herein. On the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the scope of the invention as defined by the appended claims.