Co-existing static and dynamic IP multicast
Claim Score by NHIP
Abstract
A system and method are provided for providing both static and dynamic IP multicasting. The concept of a multicast Static-Range is introduced which allows the coexistence of static and dynamic IP multicast. The multicast Static-Range is a set of Class D IP addresses which is reserved for static multicasting, and is configured at all routers. When a router receives a PIM message or an IGMP message, the router determines whether the group specified in the message is within the multicast Static-Range. If the group pertains to a static multicasting group, the router does not propagate the message to upstream routers using PIM-SM or PIM-SSM protocols, and only connects or disconnects interfaces internal to the router. If the multicast group address in the message is not within the multicast Static-Range, the router recognizes that the message pertains to a dynamic multicasting group and implements PIM or IGMP protocols as usual. If the invention is used for broadcasting TV, the low end of TB channels or commonly used channels can be created as static IP multicast. This way, a user can access or leave such channels without an entire shortest path tree being created or torn down, improving access time and channel surfing for a user. Also, pay-per-view, digital or less frequently used channels can be created using dynamic IP multicast with traditional PIM-SSM protocol, in order to make efficient use of router resources.

Term
Projected expiry 22 May 2030.
- Priority and filed
- Published
- Today
- Projected expiry
4 claims: 3 independent, 1 dependent
- 1Broadest claimClaim Score 58, broad(NHIP)A method of implementing Internet (IP) Multicasting in a communication network, the method comprising:defining a multicast Static-Range, being a set of at least one Class D IP address;reserving each IP address within the multicast Static-Range for static IP multicasting;establishing in the network at least one dynamic IP multicasting group, each dynamic multicasting group having a respective IP address lying outside the multicast Static-Range;and establishing in the network at least one static multicasting group for which PIM-SMM messaging and PIM-SM messaging is ignored, each static multicasting group having a respective IP address lying within the multicast Static-Range.
- 2A method of supporting coexistence of static IP multicasting and dynamic IP multicasting at a router in a communication network, comprising:storing a multicast Static-Range in memory, the multicast Static-Range being a set of at least one Class D IP address reserved for static IP multicasting;upon receipt of a PIM message or an IGMP message, determining whether the message pertains to a static multicasting group;if the message does not pertain to a static multicasting group, processing the message in accordance with dynamic IP multicast;if the message pertains to a static multicasting group and the message is a PIM message, discarding the message;if the message pertains to a static multicasting group and the message is an IGMP JOIN message specifying a source, establishing a connection within the router and identifiable by the source and the group without forwarding a PIM message to an upstream router;and if the message pertains to a static multicasting group and the message is an IGMP LEAVE message specifying a source, removing a connection within the router and identifiable by the source and the group without forwarding a PIM message to an upstream router.
- 3A router for use in a communication network, comprising:a memory for storing a multicast Static-Range, being a set of at least one Class D IP address, each IP address within the multicast Static-Range being reserved for static multicasting;means for, upon receipt of a PIM message, determining whether the message pertains to a static multicast group;means for ignoring a received PIM message in the event that the message pertains to a static multicast group;means for processing a received PIM message in accordance with PIM protocol in the event that the message does not pertain to a static multicast group;means for, upon receipt of an IGMP message, determining whether the message pertains to a static multicast group;means for, upon receipt of an IGMP JOIN message specifying a source, establishing a connection within the router without forwarding a corresponding PIM message to an upstream router in the event that the IGMP JOIN message pertains to a static multicast group;means for, upon receipt of an IGMP LEAVE message specifying a source, removing a connection within the router without forwarding a corresponding PIM message to an upstream router in the event that the IGMP LEAVE message pertains to a static multicast group;and means for processing a received IGMP message in accordance with dynamic IP multicast in the event that the message does not pertain to a static multicast group.
Independent claims3
40 paragraphs in 5 sections, as filed
FIELD OF THE INVENTION
0001The invention relates to IP multicasting in communication networks, and more particularly to IP address ranges for use in creation of IP multicast distribution trees.
BACKGROUND OF THE INVENTION
0002To establish a multicast tree from a source which provides multicast content to several hosts which desire to receive the traffic, two general approaches are Dynamic IP Multicast and Static IP Multicast. In dynamic multicast, a multicast protocol such as Protocol Independent Multicast-Sparse Mode (PIM-SM) or Protocol Independent Multicast-Source Specific Mode (PIM-SMM) is used to create and propagate the multicast tree from multicast hosts to a multicast source. In static multicast, the multicast protocol is not responsible for establishing and propagating the multicast tree. Rather, establishment of the multicast tree is effected by other means such as network management or through configuration.
0003In PIM-SM, a shortest path tree (SPT) can not be established directly between the source and hosts because the hosts are unaware of the identification of the source. The hosts can only identify the content as belonging to a multicast group. Rendezvous Points (RPs) are routers used as temporary waypoints in order to assist in creation of the SPT. AU routers have access to an identical mapping between multicast groups and RPs, one RP being associated with each group. When a router receives an IGMP-JOIN(*,G) or a PIM-JOIN(*,G) message, the router establishes a route towards the RP associated with the group. As numerous routers establish routes to the RP, an RP tree (RPT) is established. The router connected to the source (the source router) has the same mapping between RPs and groups. When the source begins transmitting IP packets for a group, the source router starts registration of the packets with the RP by encapsulating the IP packets and forwarding them to the RP. As the routers within the RPT connected to the hosts receive the IP packets via the RPT, they learn the identification of the source, create SPT routes to the source, and tear down the routes to the RP. The RTP is thereby converted into a SPT.
0004In PIM-SMM, the hosts are aware of the source of the multicast content for a given group. In an example of PIM-SMM being used for broadcasting TB channels, when a user selects a channel to watch, a set top box (STB) determines the multicast group G and a source S for the channel and sends an IGMP JOIN(S,G) message to a host router. The multicast group is defined by a Class D IP address within the range 224/4. The host router first establishes internal connections between an outgoing interface (OIF) to the STB and an incoming interface (IIF) to the next router. The host router then determines the next router through which the source can be reached, and forwards a PIM JOIN(S,G) message to the next upstream router. The next router creates its own internal connections and forwards the PIM JOIN(S,G) message to an upstream router towards the source S. This is repeated until a PIM JOIN(S,G) message reaches either the router attached to the source or reaches a router which already has (S,G) state.
0005If any router receives a PIM JOIN(S,G) message and the multicast distribution tree is already supported for (S,G) at the router because a PIM JOIN(S,G) or an IGMP JOIN(S,G) for the same source and group have already been received from a different router or another host, then the router simply establishes the internal connection between the OIF through which the newly arrived PIM JOIN(S,G) message arrived and the IIF which leads to the source.
0006In PIM-SM, if a host no longer wishes access to the group, the host sends an IGMP LEAVE(*,G) message to the host router. The host router first removes the connection between the OIF of the host and the IIF leading to the RP. If no other hosts are currently willing to receive traffic for the same group, then the host router then sends a PIM PRUNE(*,G) message to the upstream router towards the RP. This is repeated by the upstream routers until either the RP or a router supporting more than one host for the group is reached, at which point the internal connection to the OIF is removed and the PIM PRUNE(*,G) message is not forwarded.
0007In PIM-SMM, if a host no longer wishes access to the group, the host sends an IGMP LEAVE(S,G) message to the host router. The host router first removes the connection between the OIF of the host and the IIF leading to the next upstream router. If no other hosts are currently willing to receive traffic for the same group and from the same source then the host router then sends a PIM PRUNE(S,G) message to the upstream router. This is repeated by the upstream routers until either the source router or a router supporting more than one host for the group and source is reached, at which point the internal connection to the OIF is removed and the PIM PRUNE(S,G) message is not forwarded.
0008In both flavors of PIM protocol, a shortest path tree between multiple hosts and a source is eventually generated and maintained as hosts request access to or leave the group and the source. Dynamic multicast results in efficient use of interfaces, since each IIF in each router is generally shared by each downstream host, and each OIF in each router is generally shared by each downstream host of a downstream router. However, in applications in which hosts leave and join groups frequently, users may experience undesirable delay as RPTs and SPTs are established, torn down, or altered. An example of such an application is TV broadcasting.
0009In TV broadcasting applications of IP multicasting, users may frequently switch the channel being watched as they scan channels for content or switch between channels during commercials. When a user switches between a first channel and a second channel, the STB first sends an IGMP LEAVE(S<sub>1</sub>,G<sub>1</sub>) message to the host router which may then send a PIM PRUNE(S<sub>1</sub>,G<sub>1</sub>) message upstream. The STB then sends an IGMP JOIN(S<sub>2</sub>,G<sub>2</sub>) message to the host router which may then send a PIM JOIN(S<sub>2</sub>,G<sub>2</sub>) message upstream. Each time a user switches channels, a portion of the shortest path tree is torn down and a new shortest path tree or portion of a shortest path tree is created. This consumes processing power at the routers, and more importantly (for the customer) can result in unacceptable delay in channel surfing because the PIM-SMM messages are transmitted around the network to tear down the old multicast tree and rebuild a new one.
0010Static multicasting provides a solution to this problem. The multicast distribution tree is established once for each multicast group (or channel) from end-user hosts to multicast source without using any multicast protocol. To setup a static multicast tree from a host for group G to a multicast source S, the multicast connections should be created on each router from the host router to the multicast source, similar to the PIM-SMM protocol. However, static multicast lacks the flexibility offered by dynamic multicast in automatic creation and maintenance of SPT trees as groups are added. Static multicast also requires that OIFs and IIFs be reserved for SPT trees, even if there are no hosts currently receiving multicast content over the SPT tree.
0011A system which allowed the coexistence of static multicast and dynamic multicast without conflict would allow the advantages of each multicast method to be realized. Such a system must allow PIM-SM and PIM-SSM protocols to run in a network in which static multicast states are provisioned, without resulting in tearing down or corruption of the static multicast SPTs. Such a system should allow addition or removal of dynamic multicast states and static multicast states independently of each other. In this way, more commonly used groups may be established using static multicast and paths of less commonly used groups may be accessed only as needed using the dynamic multicast. This would provide less delay to users as they switch between commonly used groups while maintaining efficient use of router resources.
SUMMARY OF THE INVENTION
0012In accordance with one aspect of the invention, a method is provided for implementing IP multicasting in a communication network. A multicast Static-Range is defined, being a set of at least one Class D IP address. Each IP address within the multicast Static-Range is reserved for static IP multicasting. At least one dynamic IP multicasting group is established in the network, each such dynamic IP multicasting group having a respective IP address lying outside the multicast Static-Range. At least one static IP multicasting group is established in the network, each such static IP multicasting group having a respective IP address lying within the multicast Static-Range, and PIM-SMM messaging and PIM-SM messaging is ignored for such groups.
0013In accordance with another aspect of the invention, a method is provided for supporting coexistence of static IP multicasting and dynamic IP multicasting at a router in a communication network. A multicast Static-Range is stored in memory, the multicast Static-Range being a set of at least one Class D IP address reserved for static IP multicasting. Upon receipt of a PIM message or an IGMP message, it is determined whether the message pertains to a static multicasting group. If the message does not pertain to a static multicasting group, the message is processed in accordance with dynamic IP multicast. If the message does pertain to a static multicasting group and the message is a PIM message, the message is discarded. If the message pertains to a static multicasting group and the message is an IGMP JOIN message specifying a source, a connection identifiable by the source and the group is established within the router without forwarding a PIM message to an upstream router. If the message pertains to a static multicasting group and the message is an IGMP LEAVE message specifying a source, a connection within the router and identifiable by the source and the group is removed, without forwarding a PIM message to an upstream router.
0014In accordance with another aspect of the invention, a router is provided for use in a communication network. The router includes a memory for storing a multicast Static-Range, the multicast Static-Range being a set of at least one Class D IP address, each IP address within the multicast Static-Range being reserved for static multicasting. The router includes means for determining, upon receipt of a message, whether the message pertains to a static multicast group. The router includes means for ignoring a received PIM message in the event that the message pertains to a static multicast group. The router includes means for processing a received PIM message in accordance with PIM protocol in the event that the message does not pertain to a static multicast group. The router includes means for, upon receipt of an IGMP message, determining whether the message pertains to a static multicast group. The router includes means for, upon receipt of an IGMP JOIN message specifying a source, establishing a connection within the router without forwarding a corresponding PIM message to an upstream router in the event that the IGMP JOIN message pertains to a static multicast group. The router includes means for, upon receipt of an IGMP LEAVE message specifying a source, removing a connection within the router without forwarding a corresponding PIM message to an upstream router in the event that the IGMP LEAVE message pertains to a static multicast group. The router includes means for processing a received IGMP message in accordance with dynamic IP multicast in the event that the message does not pertain to a static multicast group.
0015The methods of the invention may be stored on computer-readable media as instructions executable by a processor.
0016The methods and apparatus of the present invention allow both dynamic and static IP multicast to coexist and allow the states created by both multicast methods to be maintained independently. By providing a range of Class D IP addresses which is defined and reserved for static IP multicast, network routers can distinguish static multicast groups from dynamic multicast groups and can apply a new rule set to PIM JOIN/PRUNE and IGMP JOIN/LEAVE messages. Static channels can thereby be added or removed at the routers without triggering any dynamic multicast. The methods and the apparatus of the invention may find particular use in TV broadcasting, where commonly accessed TV channels may be configured using static multicast while less commonly accessed TV channels or specialty channels (such as pay-per-view channels) may be configured using dynamic multicast.
BRIEF DESCRIPTION OF THE DRAWINGS
0017The features and advantages of the invention will become more apparent from the following detailed description of the preferred embodiment(s) with reference to the attached figures, wherein:
0018<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of a portion of an example communication network;
0019<figref idref="DRAWINGS">FIG. 2</figref> is a diagram of Class D IP address allocation according to one embodiment of the invention;
0020<figref idref="DRAWINGS">FIG. 3</figref> is a flowchart of a router of <figref idref="DRAWINGS">FIG. 1</figref> processes PIM and IGMP messages according to one embodiment of the invention;
0021<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram of the network of <figref idref="DRAWINGS">FIG. 1</figref> in which an example static IP multicasting group is configured according to one embodiment of the invention; and
0022<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram of the network of <figref idref="DRAWINGS">FIG. 1</figref> in which a second example static IP multicasting group is configured according to one embodiment of the invention.
0023It will be noted that in the attached figures, like features bear similar labels.
DETAILED DESCRIPTION OF THE EMBODIMENTS
0024Referring to <figref idref="DRAWINGS">FIG. 1</figref>, a block diagram of a portion of an example communication network is shown. A host <b>10</b>, operated by a user, is connected to the network through a host router <b>12</b>. The host <b>10</b> may be any device capable of requesting and receiving IP multicast traffic, such as a set top box (STB). A multicast source <b>14</b> is connected to the network through a source router <b>16</b>, and offers IP multicast content for multicast group G<sub>1</sub>. The host router <b>12</b> and the source router <b>16</b> communicate through an intermediate router <b>18</b>. The layout of <figref idref="DRAWINGS">FIG. 1</figref> is for example purposes only, and more generally there may be a plurality of hosts, a plurality of host routers, a plurality of sources, a plurality of source routers, and a plurality of intermediate routers between host routers and source routers. The source typically offers content in more than one multicast group.
0025Referring to <figref idref="DRAWINGS">FIG. 2</figref>, a diagram of Class D IP addresses is shown. Class D IP addresses are reserved for IP multicasting, and include IP addresses from 224.0.0.0 to 239.255.255.255. A range of IP addresses within Class D is already reserved for PIM-SSM, from 232.0.0.0 to 238.255.255.255 (238/8). This range is known as SSM-Range, and is defined by IETF (Meyer et al., “Source-Specific Protocol Independent Multicast in 232/8”, IETF Draft, March 2004). According to one embodiment of the invention a range of IP addresses, referred to herein as the multicast Static-Range, within Class D is reserved for static multicasting. Although shown in <figref idref="DRAWINGS">FIG. 2</figref> as lying below the range of PIM-SSM addresses, the range of static multicasting IP addresses may be a set of any Class D IP addresses which do not overlap the SSM-Range.
0026Broadly, in operation any router which receives an IGMP or a PIM message determines the group G defined within the message. If the group G lies within the multicast Static-Range, the router does not use the PIM protocol. Otherwise, the router uses the PIM protocol. In this way, IP multicasting groups can be defined as static by assigning them an IP address lying within the Static-Range. When a host joins a static IP multicasting group by sending an IGMP JOIN(S,G) message, the host router builds an internal connection between OIF and IIF but does not propagate any PIM-JOIN(S,G) message to upstream routers. When a host leaves a static multicasting group by sending an IGMP LEAVE(S,G) message, the host router tears down the internal connections between OIF and IIF but does not propagate any PIM-PRUNE(S,G) message to upstream routers. If a host joins or leaves a dynamic multicasting group, that is, a group whose IP address does not lie within the multicast Static-Range, the routers employ either the PIM-SM or PIM-SSM protocol to build and tear down shortest path trees or the RP trees, or to register a multicast source with an RP in the case of PIM-SM.
0027Referring to <figref idref="DRAWINGS">FIG. 3</figref>, a flowchart of a method implemented by a router in a communication network according to one embodiment of the invention is shown. At step <b>30</b> the router receives either a PIM message or an IGMP message. The multicast Static-Range is configured in memory within the router. The router determines the group G in the message, and at step <b>32</b> the router determines whether the group G lies within the multicast Static-Range. If the group G does not lie within the multicast Static-Range, the router processes the message using conventional dynamic IP multicast.
0028If the group G does lie within the multicast Static-Range, the router determines at step <b>36</b> whether the message is an IGMP JOIN(S,G) message. If the message is an IGMP JOIN(S,G) message, then at step <b>38</b> the router establishes a connection between the downstream outgoing interface (OIF) through which the message arrived and the upstream incoming interface (IIF) leading to the source S specified by the message.
0029If the message is not an IGMP JOIN(S,G) message, then at step <b>40</b> the router determines whether the message is an IGMP LEAVE(S,G) message. If the message is an IGMP LEAVE(S,G) message, then at step <b>42</b> the router removes the connection between the OIF through which the message arrived and the IIF leading to the source S specified by the message.
0030If the message is not an IGMP LEAVE(S,G) message, then at step <b>42</b> the router ignores the message. Any such message will be either a PIM JOIN(S,G) message, a PIM JOIN(*,G) message, a PIM PRUNE(S,G) message, a PIM PRUNE(*,G) message, a PIM REGISTER message, an IGMP JOIN(*, G) message, or an IGMP LEAVE(*, G) message, none of which are to be processed for group addresses which lie within the multicast Static-Range.
0031Referring to <figref idref="DRAWINGS">FIG. 4</figref>, the example communication network of <figref idref="DRAWINGS">FIG. 1</figref> is shown following establishment of a Static IP Multicast connection according to one embodiment of the invention. The source <b>14</b> offers IP multicasting for a group G<sub>1 </sub>appropriate for Static Multicasting, such as a television channel which will requested and dropped frequently by users. The group G<sub>1 </sub>is a multicast IP address lying within the multicast Static-Range and is configured on each router. Since there is no dynamic protocol running in the network for this group (since it lies within the multicast Static-Range), the connection between the downstream OIFs and the upstream IIFs leading to the source at each router (except the host router <b>12</b>) must be established by configuration or by an automated method. To establish the multicast tree at the source router <b>16</b>, the source router <b>16</b> is provided, either manually or by an automated method, with an IGMP JOIN(S,G<sub>1</sub>) message at an OIF leading to the downstream intermediate router <b>18</b>. As described above with reference to step <b>38</b> of <figref idref="DRAWINGS">FIG. 3</figref>, the source router <b>16</b> establishes a connection <b>50</b> between the IIF leading to the source <b>14</b> and the OIF leading to the intermediate router. Similarly, the intermediate router <b>18</b> is provided with an IGMP JOIN(S,G<sub>1</sub>) message at an OIF leading to the downstream host router <b>12</b>, which causes the intermediate router <b>18</b> to establish a connection <b>52</b> between the OIF leading to the host router and the IIF leading to the source <b>14</b>. The intermediate router <b>18</b> does not propagate a PIM JOIN(S,G<sub>1</sub>) message to the upstream source router <b>16</b>, as the intermediate router recognizes that the IP address of the Group G<sub>1 </sub>lies within the multicast Static-Range.
0032Other OIFs at the source router <b>16</b> and the intermediate router <b>18</b> may similarly be provided with IGMP JOIN(S,G<sub>1</sub>) messages, if these OIFs lead towards other routers that may be interested in receiving traffic for the group G<sub>1</sub>. For example, a connection <b>54</b> may be established between the same IIF as connection <b>52</b> and an OIF leading to a second host router (not shown in <figref idref="DRAWINGS">FIG. 4</figref>).
0033When the host <b>10</b> wishes to receive multicast traffic for the group G<sub>1</sub>, the host sends an IGMP JOIN(S,G<sub>1</sub>) message to an OIF of the host router <b>12</b>, and the host router <b>12</b> establishes a connection <b>56</b> between the OIF leading to the host and an IIF leading to the source. The host router <b>12</b> recognizes that the IP address of the group G<sub>1 </sub>lies within the multicast Static-Range and, contrary to normal PIM-SMM behavior, does not then send a PIM JOIN(S,G<sub>1</sub>) message to the upstream intermediate router <b>18</b>. This is because the multicast connections on all upstream routers towards the source <b>14</b> have already been established separately ahead of time for group G<sub>1</sub>. Because most of the path leading to the source <b>14</b> already exists, the host <b>10</b> has access to the group G<sub>1 </sub>much more quickly than if Dynamic IP Multicasting was being used and some or all of the shortest path tree had to be established.
0034Similarly, as described above with reference to <figref idref="DRAWINGS">FIG. 3</figref>, if the host <b>10</b> leaves the channel, such as by switching to another channel, the host router <b>12</b> removes the connection <b>56</b> but does not send a PIM PRUNE(S,G<sub>1</sub>) message to the intermediate router <b>18</b>.
0035If the host <b>10</b> wishes to join a different multicast tree defined for a group G<sub>2</sub>, the host <b>10</b> sends an IGMP(S, G<sub>2</sub>) message to the host router <b>12</b>. If the group G<sub>2 </sub>does not lie within the configured Static-Range (as described above with reference to step <b>32</b> of <figref idref="DRAWINGS">FIG. 3</figref>), the host router <b>12</b> processes the IGMP JOIN(S,G<sub>2</sub>) message as a dynamic IP multicast. As a result, the PIM-SSM protocol establishes a connection between the OIF over which the IGMP JOIN(S,G<sub>2</sub>) message was received and an IIF leading towards the specified source S, and then sends a PIM-JOIN(S,G<sub>2</sub>) to the appropriate upstream router. The upstream routers establish internal connections and propagate PIM-JOIN(S,G<sub>2</sub>) messages upstream, in accordance with usual PIM-SSM behavior, since the IP address of group G<sub>2 </sub>is not within the multicast Static-Range.
0036Similarly, if the host <b>10</b> wishes to join a multicast tree (*,G<sub>3</sub>), the host sends an IGMP JOIN(*,G<sub>3</sub>) message to the host router <b>12</b>. Being a sparse mode multicast, the group G<sub>3 </sub>should not lie within the Static-Range. The host router <b>12</b> determines that the IP address of the group G<sub>3 </sub>does not lie within the multicast Static-Range (as described above with reference to step <b>32</b> of <figref idref="DRAWINGS">FIG. 3</figref>), and processes the IGMP JOIN(*,G<sub>3</sub>) message as a dynamic IP multicast. Internal router connections are established and PIM-JOIN(*,G<sub>3</sub>) messages are propagated upstream towards the RP in accordance with usual PIM-SM behavior.
0037The invention provides flexibility in configuring additional static multicasting trees or removing existing multicast trees. In other words, a static multicast tree can be added or removed without interrupting either static or dynamic networks. Referring to <figref idref="DRAWINGS">FIG. 5</figref>, the example communication network of <figref idref="DRAWINGS">FIG. 4</figref> is shown following establishment of a second static multicasting tree according to one embodiment of the invention. Group G<sub>1 </sub>remains configured in the form of connections <b>50</b>, <b>52</b>, and <b>54</b> between respective OIFs and IIFs. A second group G<sub>4</sub>, having an IP address lying within the multicast Static-Range, is offered by a second source <b>70</b> S<sub>2 </sub>is configured similarly as is described above for configuration of group G<sub>1 </sub>with reference to <figref idref="DRAWINGS">FIG. 4</figref>. An IGMP-JOIN(S<sub>2</sub>, G<sub>4</sub>) message is provided to an OIF on a second source router <b>72</b> which leads to the intermediate router <b>18</b>. The second source router <b>72</b> determines that the IP address of the group G<sub>4 </sub>lies within the multicast Static-Range, and establishes a connection between the OIF and the IIF leading to the second source. An IGMP-JOIN(S<sub>2</sub>,G<sub>4</sub>) message is provided to the OIF on the intermediate router which leads towards the host router <b>12</b>, and in response thereto the intermediate router <b>18</b> establishes a connection between the OIF and an IIF leading towards the source router <b>72</b>. It can be seen that in establishing the internal connections, the existing static multicasting group G<sub>1 </sub>(originating at source <b>14</b>) and any dynamic multicasting groups currently in effect are not affected by configuration of the second static multicasting group G<sub>4</sub>.
0038The method by which the routers process the PIM control messages, described above with reference to <figref idref="DRAWINGS">FIG. 3</figref>, is preferably carried out in the form of software instructions within one or more processors, but may more generally be stored and accessed as instructions in the form of any combination of software and hardware, including hardware within an integrated circuit. If in the form of software instructions, the software instructions may be stored on a computer-readable medium.
0039The invention has been described with reference to a range of Class D IP addresses reserved for use in static IP multicasting, referred to as the multicast Static-Range. Alternatively, the IP addresses reserved for static IP multicasting need not be contiguous. The invention can be easily understood to be more generally operational with a multicast Static-Range defined as a set of IP addresses reserved for use in static IP multicasting being not necessarily contiguous. However, using a set of IP addresses defined as a contiguous range simplifies implementation of the invention as it is easier to determine whether the IP address of a multicast group identified in a PIM or IGMP message is within a contiguous set specified by upper and lower values.
0040The embodiments presented are exemplary only and persons skilled in the art would appreciate that variations to the embodiments described above may be made without departing from the spirit of the invention. Methods that are logically equivalent or similar to the method described above with reference to <figref idref="DRAWINGS">FIG. 3</figref> may be used to implement the methods of the invention. The scope of the invention is solely defined by the appended claims.
Contents5
6 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US7936702B2 | Cited by | United States of America | Search report |
| US8340095B2 | Cited by | United States of America | Applicant |
| US2010111084A1 | Cited by | United States of America | Pre-grant |
| US8310973B2 | Cited by | United States of America | Search report |
| WO2008138236A1 | Cited by | World Intellectual Property Organization (WIPO) | Applicant |
| US8086716B2 | Cited by | United States of America | Applicant |
| US2007127473A1 | Cited by | United States of America | Pre-grant |
| US2009016253A1 | Cited by | United States of America | Pre-grant |
| US7911977B2 | Cited by | United States of America | Search report |
| US2010054247A1 | Cited by | United States of America | Pre-grant |
| US8644310B2 | Cited by | United States of America | Applicant |
| US2014195691A1 | Cited by | United States of America | Pre-grant |
| US8189584B2 | Cited by | United States of America | Applicant |
| US2011058551A1 | Cited by | United States of America | Pre-grant |
| US7808993B2 | Cited by | United States of America | Search report |
| WO2009000306A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US2007091891A1 | Cited by | United States of America | Pre-grant |
| US2018343133A1 | Cited by | United States of America | Search report |
| US2011058548A1 | Cited by | United States of America | Pre-grant |
| US2015124810A1 | Cited by | United States of America | Pre-grant |
| US9240893B2 | Cited by | United States of America | Applicant |
| WO2009000306A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| CN118041846A | Cited by | China | Search report |
| US2011149960A1 | Cited by | United States of America | Pre-grant |
| EP2276198A1 | Cited by | European Patent Office (EPO) | Search report |
| US2010172351A1 | Cited by | United States of America | Pre-grant |
| US2007086458A1 | Cited by | United States of America | Pre-grant |
| US2010183008A1 | Cited by | United States of America | Pre-grant |
| US2011010441A1 | Cited by | United States of America | Pre-grant |
| CN112887115A | Cited by | China | Search report |
| US8094602B2 | Cited by | United States of America | Applicant |
| US2010054248A1 | Cited by | United States of America | Pre-grant |
| EP2093932A1 | Cited by | European Patent Office (EPO) | Search report |
| US2018253742A1 | Cited by | United States of America | Search report |
| US8068493B2 | Cited by | United States of America | Search report |
| US10735214B2 | Cited by | United States of America | Search report |
| US2010061368A1 | Cited by | United States of America | Pre-grant |
| US2009310609A1 | Cited by | United States of America | Pre-grant |
| US2010046516A1 | Cited by | United States of America | Pre-grant |
| WO2010072611A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US2014036916A1 | Cited by | United States of America | Pre-grant |
| US2010254383A1 | Cited by | United States of America | Pre-grant |
| CN104683769A | Cited by | China | Search report |
| US10489801B2 | Cited by | United States of America | Search report |
| EP2293493A1 | Cited by | European Patent Office (EPO) | Search report |
| US2010014519A1 | Cited by | United States of America | Pre-grant |
| EP2293493A1 | Cited by | European Patent Office (EPO) | Search report |
| US11038970B2 | Cited by | United States of America | Applicant |
| US9031068B2 | Cited by | United States of America | Applicant |
| US8571028B2 | Cited by | United States of America | Search report |
| US8064449B2 | Cited by | United States of America | Search report |
| US9647959B2 | Cited by | United States of America | Search report |
| US2010172352A1 | Cited by | United States of America | Pre-grant |
| US2006268869A1 | Cited by | United States of America | Pre-grant |
| JP2010531586A | Cited by | Japan | Search report |
| WO2010072611A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US7921198B2 | Cited by | United States of America | Applicant |
| US2009245255A1 | Cited by | United States of America | Pre-grant |
| US2011211578A1 | Cited by | United States of America | Pre-grant |
| EP2093932A4 | Cited by | European Patent Office (EPO) | Search report |
| US2010232334A1 | Cited by | United States of America | Pre-grant |
| US8184630B2 | Cited by | United States of America | Search report |
| US8422499B2 | Cited by | United States of America | Search report |
| US2010172353A1 | Cited by | United States of America | Pre-grant |
| US2006176804A1 | Cited by | United States of America | Pre-grant |
| US8565140B2 | Cited by | United States of America | Applicant |
| US7701937B2 | Cited by | United States of America | Search report |
| US8582572B2 | Cited by | United States of America | Search report |
| US2011019673A1 | Cited by | United States of America | Pre-grant |
| US8379623B2 | Cited by | United States of America | Applicant |
| EP2276198A1 | Cited by | European Patent Office (EPO) | Search report |
| US2004071098A1 | Cites | United States of America | Pre-grant |
| US2004132448A1 | Cites | United States of America | Pre-grant |
| US2006015928A1 | Cites | United States of America | Pre-grant |
| US2006164984A1 | Cites | United States of America | Pre-grant |
| US2006274720A1 | Cites | United States of America | Pre-grant |
| US6151696A | Cites | United States of America | Pre-grant |
| US6331983B1 | Cites | United States of America | Pre-grant |
| US6721318B1 | Cites | United States of America | Pre-grant |
| US6785294B1 | Cites | United States of America | Pre-grant |
| US7107606B2 | Cites | United States of America | Pre-grant |
| US7301914B2 | Cites | United States of America | Pre-grant |
12 members in 7 offices; this record represents the family
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 13017105 | United States of America | A | |
| US20050130171 | – | – | – |
Members12
| Document | Office | Kind | |
|---|---|---|---|
| US2006262792A1 | United States of America | A1 | |
| WO2007004064A1 | World Intellectual Property Organization (WIPO) | A1 | |
| CN1913491A | China | A | |
| EP1884064A1 | European Patent Office (EPO) | A1 | |
| KR20080021666A | Republic of Korea | A | |
| EP1884064B1 | European Patent Office (EPO) | B1 | |
| AT413743T | Austria | T | |
| ATE413743T1 | Austria | T1 | |
| DE602006003551D1 | Germany | D1 | |
| CN1913491B | China | B | |
| KR101168369B1 | Republic of Korea | B1 | |
| US8675653B2 | United States of America | B2 |
93 transactions on the USPTO file
Allowed after 3 non-final rejections, 3 final rejections, 2 RCEs and 2 appeals.
- Non-final rejections
- 3
- Final rejections
- 3
- RCEs
- 2
- Appeals
- 2
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Expire PatentEXP. | EXP. | |
| Maintenance Fee Reminder MailedREM. | REM. | |
| Payment of Maintenance Fee, 4th Year, Large EntityM1551 | M1551 | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Examiner's Amendment CommunicationEX.A | EX.A | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Mail BPAI Decision on Appeal - AffirmedMAPDA | MAPDA | |
| BPAI Decision - Examiner AffirmedAPDA | APDA | |
| Docketing Notice Mailed to AppellantAP_DK_M | AP_DK_M | |
| Assignment of Appeal NumberAPAS | APAS | |
| Appeal Awaiting BPAI DocketingAPWD | APWD | |
| Mail Reply Brief Noted by ExaminerMRBNE | MRBNE | |
| Reply Brief Noted by ExaminerRBNE | RBNE | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Reply Brief FiledAPRB | APRB | |
| Exam. Ans. Review CompletePACC | PACC | |
| Mail Examiner's AnswerMAPEA | MAPEA | |
| Examiner's Answer to Appeal BriefAPEA | APEA | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Appeal Brief Review CompleteAPBR | APBR | |
| Appeal Brief FiledAP.B | AP.B | |
| Mail Appeals conf. Proceed to BPAIMAPCP | MAPCP | |
| Pre-Appeals Conference Decision - Proceed to BPAIAPCP | APCP | |
| Request for Pre-Appeal Conference FiledAP.C | AP.C | |
| Notice of Appeal FiledN/AP | N/AP | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Examiner Interview Summary Record (PTOL - 413)EXIN | EXIN | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Mail Appeals conf. Reopen Prosec.MAPCR | MAPCR | |
| Pre-Appeals Conference Decision - Reopen ProsecutionAPCR | APCR | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Request for Pre-Appeal Conference FiledAP.C | AP.C | |
| Notice of Appeal FiledN/AP | N/AP | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Examiner Interview Summary Record (PTOL - 413)EXIN | EXIN | |
| Letter Requesting Interview with ExaminerM865 | M865 | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Miscellaneous Incoming LetterLET. | LET. | |
| Miscellaneous Incoming LetterLET. | LET. | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| IFW TSS Processing by Tech Center CompleteTSSCOMP | TSSCOMP | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Application Is Now CompleteCOMP | COMP | |
| Application Return from OIPEWROIPE | WROIPE | |
| Application Return TO OIPEROIPE | ROIPE | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Application Is Now CompleteCOMP | COMP | |
| Cleared by OIPE CSRL194 | L194 | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| Initial Exam Team nnIEXX | IEXX |
11 recorded assignments at the USPTO, latest first
- Now
Now: Held by
RPX CORP - 2021-12-28
Assignment of assignors interest.
Ownership change- From
- PROVENANCE ASSET GROUP LLC
- To
- RPX CORPORATION
Recorded 2021-12-28, Signed 2021-11-29
- 2021-11-30
Release by secured party.
Release- From
- NOKIA US HOLDINGS INC.
- To
- PROVENANCE ASSET GROUP HOLDINGS LLCPROVENANCE ASSET GROUP LLC
Recorded 2021-11-30, Signed 2021-11-29
- 2021-11-30
Release by secured party.
Release- From
- CORTLAND CAPITAL MARKETS SERVICES LLC
- To
- PROVENANCE ASSET GROUP HOLDINGS LLCPROVENANCE ASSET GROUP LLC
Recorded 2021-11-30, Signed 2021-11-01
- 2019-02-14
Assignment and assumption agreement
- From
- NOKIA USA INC.
- To
- NOKIA US HOLDINGS INC.
Recorded 2019-02-14, Signed 2018-12-20
- 2017-09-13
Assignment of assignors interest.
- From
- ALCATEL LUCENT SASNOKIA SOLUTIONS AND NETWORKS BVNOKIA TECHNOLOGIES OY
- To
- PROVENANCE ASSET GROUP LLC
Recorded 2017-09-13, Signed 2017-09-12
- 2017-09-13
Security interest.
Security interest- From
- PROVENANCE ASSET GROUP HOLDINGS LLCPROVENANCE ASSET GROUP LLC
- To
- NOKIA USA INC
Recorded 2017-09-13, Signed 2017-09-13
- 2017-09-13
Security interest.
Security interest- From
- PROVENANCE ASSET GROUP HOLDINGS LLCPROVENANCE ASSET GROUP LLC
- To
- CORTLAND CAPITAL MARKET SERVICES LLC
Recorded 2017-09-13, Signed 2017-09-13
- 2014-09-30
Release by secured party.
Release- From
- CREDIT SUISSE AG
- To
- ALCATEL LUCENT
Recorded 2014-09-30, Signed 2014-08-19
- 2013-12-13
Change of name.
- From
- ALCATEL
- To
- ALCATEL LUCENT
Recorded 2013-12-13, Signed 2006-11-30
- 2013-01-30
Security agreement
Security interest- From
- ALCATEL LUCENT
- To
- CREDIT SUISSE AG
Recorded 2013-01-30, Signed 2013-01-30
- 2005-05-17
Assignment of assignors interest.
Ownership change- From
- ROKUI REZA MOHAMMAD
- To
- ALCATEL
Recorded 2005-05-17, Signed 2005-05-17
26 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Lapsed due to failure to pay maintenance feeLapsedFP | FP | |
| Lapse for failure to pay maintenance feesLapsedPATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYLAPS | LAPS | |
| Information on status: patent discontinuationPATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362STCH | STCH | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| Fee payment procedureMAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYFEPP | FEPP | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| Maintenance fee paymentMAFP | MAFP | |
| AssignmentAS | AS | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| AssignmentAS | AS | |
| Fee payment procedurePAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYFEPP | FEPP | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS |
Numbers
- Publication
- 20060262792
- Publication, DOCDB
- 2006262792
- Publication, EPODOC
- US2006262792
- Application
- 11130171
- Application, DOCDB
- 13017105
- Application, EPODOC
- US20050130171
Titles
- English
- Co-existing static and dynamic IP multicast
Patent term adjustment
- A delay
- +1,635 daysthe office missed an examination deadline
- B delay
- +204 dayspendency past three years
- Applicant delay
- −8 days
- Net adjustment
- 1,831 days
Classification
- CPC, 8
- H04L12/185
- H04W4/08
- H04L45/16
- H04L45/48
- H04L61/5069
- H04L45/484
- H04L12/28
- H04L45/02
- IPC, 2
- H04L12 56
- H04J3 26
- USPC, 2
- 370390000
- 370432000