|Publication number||US6847638 B1|
|Application number||US 09/688,895|
|Publication date||Jan 25, 2005|
|Filing date||Oct 16, 2000|
|Priority date||Oct 16, 2000|
|Also published as||US7385977, US20050157741|
|Publication number||09688895, 688895, US 6847638 B1, US 6847638B1, US-B1-6847638, US6847638 B1, US6847638B1|
|Inventors||Ishan Wu, Nagarani Chandika, Ramana Mellacheruva, Yiqun Cai|
|Original Assignee||Cisco Technology, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (10), Non-Patent Citations (7), Referenced by (85), Classifications (4), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
This invention relates to multicast groups in a computer network, and more particularly to transmission of multicast groups from a router through a layer 2 switch to another router, which then distributes the packets to further downstream routers or to end stations.
2. Background Information
A network exchange point is often designed with a Layer 2 switch interconnecting a plurality of fast routers. The Layer 2 switch has a plurality of ports, and usually one router is connected to one port of the Layer 2 switch. Also, an end station may be directly connected to the Layer 2 switch.
An end node is spoken of as “desiring” to receive multicast packets of a particular multicast group, for example, in response to a user (person) executing a command to begin receiving the multicast group packets. An end node desiring to receive multicast group packets sends a relatively simple packet, referred to as an Internet Group Management Packet (IGMP) packet, to the first upstream router in order to execute a relatively simple multicast group join procedure. A router, in response to receiving an IGMP join packet, sends a Protocol Independent Multicast (PIM) join packet to other routers in order to execute a relatively complex multicast join procedure referred to as a “PIM join”. The PIM join packet informs other routers that the new router requests multicast group traffic from a particular group. The IGMP protocol is described in RFC 1112 and RFC 2236, and the PIM protocol is described in RFC 2117 and RFC 2362, where an RFC is a Request for Comments published by the Internet Engineering Task Force, and all disclosures of these RFCs are incorporated herein by reference. A copy of an RFC may be downloaded from the IETF Web Site located at URL www.ietf.org.
In the event that a layer 2 switch interconnects the routers, a PIM join packet transmitted by a router and reaching the layer 2 switch is forwarded to each of the ports of the layer 2 switch connected to a multicast router. The PIM join packet is then ordinarily transmitted by the port to the multicast router. Routers receiving the PIM join packet respond in accordance with the PIM protocol to set up the multicast group distribution tree. A layer 2 switch forwards all multicast packets to all ports connected to a router, except it does not forward the multicast packet through the port from which the multicast packet arrived.
Multicast data traffic may arrive at the Layer 2 switch from any one of the multicast routers connected to it. The Layer 2 switch then transmits all multicast data packets through each port connected to a multicast router. That is, the Layer 2 switch does not discriminate between different multicast groups and the routers which need to receive packets of a particular group. The Layer 2 switch simply transmits all multicast group packets to all multicast routers by transmitting multicast packets through the ports connected to the multicast routers.
Accordingly, each of the routers receives multicast group packets which it does not need. This redundant traffic is unwanted.
In the event that an end station is connected to a layer 2 switch, the IGMP packet which the end station sends to a router passes through the layer 2 switch. The layer 2 switch, if enabled, may use “IGMP snooping” to examine the contents of an IGMP packet. In examining the contents of an IGMP packet, the layer 2 switch reads the group address, and in response, forwards only multicast traffic of the group requested to the end station.
There is needed a method to have a Layer 2 switch transmit multicast group traffic to only those routers which need packets of a particular multicast group.
The invention gets rid of the unnecessary multicast group traffic forwarded to multicast routers by a layer 2 switch, by configuring the Layer 2 switch forwarding table to list only the routers which need packets of a particular group.
The invention is a method of a router informing a Layer 2 switch by use of packets of a new router port group management protocol (RGMP) that the layer 2 switch is to forward multicast packets of a specified group to the router. First the router transmits a RGMP HELLO packet to the layer 2 switch to inform the switch that the router is a multicast router implementing the invention. Then, in the event that the router receives an IGMP packet from an end station requesting multicast packets of a particular group, in response the router sends an RGMP JOIN packet to the layer 2 switch. The RGMP JOIN packet requests that the layer 2 switch forward only multicast group packets, of the group whose group number is written into a field of the RGMP JOIN packet, to the router. Also, the router sends a prior art PIM JOIN packet to other multicast routers in order to be placed on the multicast distribution tree for that group.
In response to receiving the RGMP JOIN packet, the Layer 2 switch creates an entry in its Forwarding Table. Then when a data packet arrives with a multicast group address, the Layer 2 switch interprets the group address, and looks in the forwarding table for that group address. Corresponding to that group address in the forwarding table, the Layer 2 switch finds a list of only those routers which have sent a RGMP JOIN packet to the Layer 2 switch for that particular group. The layer 2 switch, in response to the entries in its forwarding table, then forwards to a router, those multicast packets of the groups requested by the router.
The RGMP join packet is identical in format to the prior art IGMP join packet, but has a different “type” number in the “type” field. This choice of format makes implementation in layer 2 switches easier because a layer 2 switch implementing “IGMP snooping” already has the capability to interpret an IGMP packet. The router is configured by a person such as a “router administrator” to “know” that a Layer 2 switch is RGMP capable.
A multicast router may transmit a RGMP LEAVE message to a layer 2 switch in order to terminate transmission of multicast packets of a particular group G by the layer 2 switch to the multicast router.
A multicast router may transmit a RGMP BYE message to a layer 2 switch in order to terminate the RGMP protocol between the router and the layer 2 switch, in which event the layer 2 switch then transmits all multicast traffic to the router as though the router were a legacy multicast router not implementing the invention.
Turning now to the drawings, in which like numerals represent like parts in the several views:
EMBODIMENT Computer network 100 is shown in FIG. 1. Computer network 100 has a Layer 2 switch 102 which switches packets using Layer 2 protocol.
Various ports of switch 102 are connected to routers. For example, Layer 2 switch 102 connects to legacy router 104. Legacy router 104 does not implement the invention, as will be explained in greater detail herein below.
Also connected to Layer 2 switch 102 are routers which implement the invention, including router 106, router 108, router 110, and router 112. Also, a host computer 114 is shown connected to a port of Layer 2 switch 102.
Source computer end station 120 transmits packets belonging to a multicast group. The multicast group packets are transported, for example, through network cloud 122, to router 124. Router 124 in turn connects to router 110, and router 110, connects to a port of Layer 2, switch 102. The multicast packets transmitted by source end station 120 contain a multicast destination address in their Layer 2 address, that is the MAC destination address. Layer 2, switch 102 recognizes the multicast address in the Layer 2 destination address field of the multicast packet, and transmits that packet to all multicast enabled routers connected to Layer 2, switch 102, in accordance with the prior art, and as shown in FIG. 14.
In accordance with the invention, Layer 2 switch 102 contains a forwarding table keyed to the group address carried in the multicast packet, where the forwarding table is for forwarding multicast group packets through ports connected to routers implementing the invention, as described further hereinbelow. The Layer 2 switch 102 reads the group address, in response to discovering a multicast address in the Layer 2 destination address field, and does a table look-up based on the group address, and finds in its forwarding table a list of ports to which the multicast group packet should be transmitted. Accordingly Layer 2, switch 102 transmits only those multicast group packets to a multicast enabled router, where that particular router has downstream receiving host computers desiring to receive packets from that particular group of multicast packets.
Turning now to
A commonly used topology for an Internet backbone hub is shown in network 200. Terminology is introduced describing routers as “downstream” from a port of hub 202, or more particularly downstream from a Layer 2 switch 102A performing the switching for hub 202.
The first down stream router, for example, in network 210 is backbone router 230. The first down stream router in network 212 is backbone router 232. The first down stream router in network 214 is backbone router 234. The first down stream router for network 216 is backbone router 236. The first down stream router for in network 218 is backbone router 238. The first down stream router for in network 220 is backbone router 240, etc.
Network 100 of
A Layer 2 switch, in the prior art, forwards all multicast packets for all groups to all downstream routers which are enabled as multicast routers. In a busy Internet backbone interconnect hub 202 the various down stream routers are overloaded when all multicast packets are forwarded for all groups to every down stream router enabled for multicast. It is much more desirable to have the Layer 2 interconnect switch 102A in the interconnect hub 202 forward only packets belonging to a selected group to a router, where the router has a need to further route the packets of that selected group to further downstream end stations.
Turning now to
MAC destination addresses used for IP multicast are in the range, in hexadecimal notation: 0100 5E00 0000; to 0100 5E7F FFFF.
The MAC source address of a packet is the address of the last layer 3 device transmitting the packet. For example, a packet transmitted by source end station 120 into network cloud 122 carries the MAC source address of end station 120. When the packet reaches router 124, the MAC source address is that of the last router routing the packet. When router 124 routes the packet to router 110 the MAC source address is that of router 124, etc.
The Layer 3 header 304 contains the Layer 3 fields of the protocol utilized. For example, Layer 3 header fields may be the Internet protocol (IP) version 4 fields, or as another example the Layer 3 header fields 304 may be the IP version 6 header fields, etc. Layer 4 fields 306 contain a layer 4 header and the data fields. The end fields 310 contain fields such as the cyclic redundancy check field, etc.
As shown by breakout lines 320, 322, the Layer 3 Header 304 contains the Layer 3 Destination address field 324 (L3 DA), the Layer 3 Source Address field 326 (L3 SA), and other Layer 3 fields 328. For a multicast data packet, the source end station is determined by reading the Layer 3 Source Address field 326, and the multicast group number is determined by reading the Layer 3 Destination Address field 324.
Turning now to
The IGMP message was designed to carry to a router the group number which an end station wishes to receive, for the router to use in a PIM JOIN message which it transmits to other routers. The PIM JOIN message is used by the receiving routers to set up a multicast distribution tree for the group of multicast packets requested. The requesting router then becomes part of the multicast distribution tree for that group of multicast packets. A multicast distribution tree from a source station to all receiver stations can be constructed based upon IGMP JOIN messages and the corresponding PIM JOIN messages. Further, a multicast distribution tree may be torn down by use of IGMP LEAVE messages from receivers to routers, and PIM PRUNE messages transmitted by a router to other routers.
When a router intervenes between an end station and a layer 2 switch, the IGMP message does not reach the layer 2 switch. However, in the event that an end station is connected to a port of the layer 2 switch, the IGMP message enters the layer 2 switch. The IGMP message carries a multicast address in its MAC destination address, and the layer 2 switch forwards the IGMP message through all of its multicast ports. The routers then figure out what to do with the IGMP message. Additionally, some layer 2 switches are designed to implement a protocol known as “IGMP snooping”, wherein the layer 2 switch reads the group number from the IGMP message. The layer 2 switch uses this group number to forward only those multicast group packets to the end station connected to the port of the layer 2 switch. No other groups of multicast packets are forwarded through the port connected to the end station. IGMP snooping is particularly useful in a layer 2 switch when it is used to switch packets to a plurality of end stations, for example, when the layer 2 switch is used in a wiring closet of a building.
Turning now to
The protocol of the fields of the RGMP messages, as shown in
Field 504 is reserved for future use. Field 506 is a checksum used to check the integrity of the RGMP message.
In the present invention, the IGMP protocol using PIM JOIN messages is used by a router to set up the multicast distribution tree. The end station transmits a IGMP JOIN message to a router, and the router transmits PIM JOIN messages to other routers. In the present invention, after the PIM JOIN has been used to set up a multicast distribution tree, the router sends the new inventive Router Group Multicast Protocol message (a RGMP message). In an exemplary embodiment of the invention, the RGMP message is addressed with the MAC SA and IP SA addresses of the sending router, a MAC DA multicast address, and an IP DA reserved address indicating a “router to switch communication”.
In a preferred embodiment of the invention, the RGMP message is addressed as follows: The MAC SA and IP SA fields in the RGMP messages carry the MAC and IP addresses of the router where the messages are originated; the MAC DA field in RGMP messages is set to hex 0100.5E00.0019, a multicast layer 2 address; and, the IP DA field in RGMP messages is set to hex E0.0.0. 19 (in decimal 18.104.22.168), a reserved address for “router to switch” communications.
In response to the multicast MAC DA a layer 2 switch multicasts the RGMP message to all ports connected to routers or other layer 2 switches.
A layer 2 switch, through which the RGMP message is forwarded, reads the RGMP message using IGMP snooping. The layer 2 switch then responds to information which it reads from the RGMP message.
In response to receiving and reading a RGMP HELLO message, the Layer 2 switch ceases to send multicast traffic to the router. When the router desires to receive multicast traffic from a particular group, the router sends a RGMP JOIN message containing the group number to a router. Any layer 2 switch through which the RGMP JOIN message passes reads the group field, again using IGMP snooping. In response to reading the fields of the RGMP JOIN message, the layer 2 switch then begins sending multicast traffic for that particular group to the router. Details of the RGMP protocol are further described hereinbelow.
The RGMP protocol is driven by the PIM protocol machinery. When a PIM HELLO is sent from a router to its neighboring PIM routers, an RGMP HELLO message is sent to the PIM routers in order to inform any intermediate layer 2 switches, if they exist, the RGMP capability of the transmitting router. In response to receiving the RGMP HELLO message, the layer 2 switch ceases to send all multicast traffic to the router. Instead, it only forwards multicast traffic to the port where an RGMP HELLO is seen if one of the following conditions is met:
1. If the MAC destination address of a packet corresponds to an IP address in the range of: 22.214.171.124 to; 126.96.36.199. These are reserved addresses and are supposed to be seen by all routers on a multi-access media.
2. If the MAC destination address corresponds to the IP address of either 188.8.131.52 or 184.108.40.206. These are reserved addresses for the Auto-RP functionality and are supposed to be seen by all multicast routers on a multi-access media.
3. If the MAC destination address matches an entry in the Forwarding Table. In this case, the entry in the forwarding table will also include a list of ports where RGMP HELLO and RGMP JOIN messages for the corresponding multicast group addresses were received. Multicast packets matching the conditions will then be forwarded to all of the matching ports.
RGMP HELLO messages are sent periodically in order to permit status of devices to change, and other devices to keep abreast of the changes. Likewise, PIM HELLO messages are sent periodically.
In the present invention, when a PIM JOIN message is sent from a router to a neighboring router to set up a segment of the multicast distribution tree for a group address, an RGMP JOIN message of the present invention is also sent to inform a layer 2 switch to add the port where the RGMP JOIN message is seen to the forwarding table in the layer 2 switch for the group address. The PIM JOIN message is meant to construct a segment of the multicast distribution tree between the sending router and the receiving router. The RGMP JOIN message is meant to set up the forwarding table in the layer 2 switches for more efficient multicast data forwarding.
In accordance with the prior art, for example, if a legacy router such as router 104, received an IGMP JOIN message from a host end station connected thereto, then the router receiving the IGMP JOIN sends a PIM JOIN message to other multicast routers. The legacy router 104 does not send an RGMP HELLO message to the layer 2 switch, and so the layer 2 switch forwards all multicast group packets to the legacy routers.
Turning now to
At time 602 the router is enabled for multicast routing with the PIM protocol, so it transmits a PIM HELLO message for its PIM enabled neighbors to see.
At time 604 host computer 116 transmits an IGMP JOIN message specifying a particular multicast group “G1” to its local router, for example router 108.
At time 606 router 108 transmits a PIM JOIN message to router 110. The purpose of the PIM JOIN message is to construct a segment of the multicast distribution tree between router 108 and another router toward the source of the data.
At time 608 Layer 2 switch 102 replicates the PIM JOIN message and transmits it to all ports, since PIM JOIN is sent to 220.127.116.11.
At time 610 router 108 transmits an RGMP HELLO message to Layer 2 switch since RGMP is just enabled by a network administrator. Immediately thereafter, at time 612, router 108 transmits a periodically re-transmitted PIM HELLO to inform its PIM neighbors of its continued presence. In response to receiving the RGMP HELLO message from router 108, Layer 2 switch 102 ceases to transmit multicast packets to router 108.
At time 614, router 108 transmits an RGMP JOIN message specifying the desired group “G1”, to the Layer 2 switch, in order to begin transmission by the Layer 2 switch of multicast packets of group G1.
Immediately thereafter, at time 616, router 108 re-transmits the PIM JOIN message to router 110.
At time 618 Layer 2 switch 102 receives a multicast packet of the group G1 requested by router 108 through its RGMP JOIN message.
In response to receiving the multicast packet of the desired group at time 618, Layer 2 switch 102 replicates and transmits the desired group packet to router r108, and to any other router which has requested packets of that group by transmitting a RGMP HELLO and RGMP JOIN message to Layer 2 switch 102.
At some later time, for example, time 620, host end station 116 transmits an IGMP LEAVE message to router 108. In response to receipt of that RGMP LEAVE message, router 108 transmits a PIM PRUNE message to router 110.
Immediately thereafter, router 108 sends an RGMP LEAVE message to Layer 2 switch 102. In response to receiving the RGMP LEAVE message, Layer 2 switch ceases to transmit packets of group G1 to router 108.
Turning now to
When type field 502 contains the value 0XFF the RGMP message is a “HELLO” message, as shown in entry 702. A HELLO message is transmitted by a router that has been enabled to practice the present invention, referred to hereinafter as an RGMP router, to have Layer 2 switch 102 add its designation to the switches forwarding table. The HELLO message is sent out when the RGMP feature is enabled on the router. HELLO packets have a 0.0.0.0. in the group address field of the RGMP packets. Thus the HELLO message does not request traffic from any group. Also, HELLO messages are sent periodically in order to maintain the Layer 2 switch 102 forwarding table in a current status.
When type field 502 contains the value 0xFE, the RGMP message is a “BYE” message. RGMP BYE messages are sent only when the router wishes to disable the RGMP feature. A BYE message has 0.0.0.0 in the group address field, and so does not apply to any specific group. Upon receipt of a BYE message, Layer 2 switch 102 then sends all multicast data traffic to the router, treating the router as a legacy router. All multicast data traffic is sent to the router because the router is known to be a multicast enabled router, however, the BYE message indicates that the RGMP feature is disabled on that router. These multicast data packets have 0.0.0.0 in the group address field.
When type field 502 contains the value 0xFD the RGMP message is a “JOIN” message for a specific multicast group G. The group “G” group address is contained in field 508. In response to receipt of the RGMP JOIN message, the Layer 2 switch 102 transmits multicast data traffic for the group G to the router transmitting the JOIN message.
When type field 502 contains the value 0xFC, the RGMP message is a “LEAVE”n message. The RGMP LEAVE message contains the group address in the group address field 508. In response to receiving the RGMP LEAVE message the Layer 2 switch 102 ceases to send data traffic for Group “G” to the router transmitting the RGMP LEAVE message.
Turning now to
As shown in block 806, the group address field in RGMP HELLO and BYE messages is 0.0.0.0. As shown in block 808, RGMP JOIN and LEAVE messages contain the group address for which the RGMP JOIN or LEAVE message is being sent, and the group address is carried in the group address field 508.
IGMP snooping is a feature introduced into routers by various manufacturers. At present, there is no well defined standard method for IGMP snooping.
IGMP snooping is the name for the process by which a Layer 2 switch reads higher layer fields of packets, rather than simply forward based upon the contents of Layer 2 fields. For example, when IGMP Snooping is activated, the Layer 2 switch reads the Layer 3 fields, and when the switch finds an IGMP packet, based on the values mentioned above for the MAC DA and the IP DA fields, the switch reads the Layer 4 fields. In reading the Layer 4 fields 306, the switch reads the fields 400 of the IGMP messages, and depending upon the value found in “type” field 402, reads the fields of RGMP messages 500. By reading the Group Address field 508 and the “Type” field 502, the Layer 2 switch determines whether the RGMP message is a HELLO, JOIN, BYE or LEAVE message, and the multicast group “G” to which the message applies.
RGMP Snooping permits the Layer 2 switch to detect the ports on which the multicast data traffic for a given group G needs to be sent. It also detects all the router ports to which the multicast group traffic must be sent by listening to various multicast routine protocol packets. Hence, RGMP Snooping is used to create an entry in the Layer 2 forwarding table of the Layer 2 switch 102, and is also used by the Layer 2 switch to learn the router ports to which the group traffic is to be transmitted.
RGMP Snooping ordinarily ages out source only entries in the Layer 2-switch forwarding table every few minutes, typically every five minutes. However the Layer 2 switch will not age out the RGMP Snooping entries because the RGMP enabled router transmits periodic RGMP HELLO messages.
Turning now to
If block 904 answers “No”, the process goes to block 906 where a new router port entry is created in the router port table. From block 906 the process goes along path 908 to block 910.
If the test at block 904 answers “Yes”, the router port is present in the table, the process goes to block 912. At block 912 a check is done to determine if this is the first RGMP HELLO message for this router port. In the event that the answer is yes, the process goes to block 910.
At block 910 the process updates the router port table entry for this router port to indicate that it is an RGMP port. Also at block 910 the process creates an RGMP Hello timer for this router port.
In the event that the answer at block 912 is “No”, then the process goes to block 914. At block 914 the process starts the RGMP Hello timer for this port. From 914 the process goes to block 950 and ends.
Upon completion of block 910, the process goes to block 916. At block 916 the process removes all entries learned by the L2 switch on that interface for multicast transmission. After completion of block 916 the process goes to block 918.
At block 918 the process checks to determine if all of the router ports on this virtual local area network are RGMP capable. In the event that the check answers “Yes”, the process goes to block 920. At block 920 the process forwards an RGMP Hello message on all ports on that virtual local area network. After completion of block 920, the process goes to 950 and ends.
In the event that the check in block 918 answers “No”, the process goes to 950 and ends. Turning now to
At block 10,004 the process checks to determine if an L2 entry for the group G carried in the RGMP group address field 508 is present in the MAC Logic table. The MAC Logic table is a table used to make forwarding decisions based on the L2 MAC address.
In the event that the check answers “No”, the process goes to block 10,500, and it ends. In the event that the answer in block 10, 004 is “Yes”, the process goes to block 10,006.
At block 10,006 the process adds this router port to the list of ports for this L2 entry. Logic gates are set to inform the line cards as to which ports should accept a given packet, and which ports should drop the packet. The logic gates resides in linecards 15,002-15,008, etc. In an exemplary embodiment of the invention, the logic gates are set by CPU control engine 15,030. Upon completion of block 10,006 the process goes to block 10,008.
At block 10,008 the process forwards RGMP JOIN messages on all the RGMP router ports. Upon completion of block 10,008, the process goes to block 10,500 and ends.
Turning now to
In the event that the test answers “No”, the process goes on path 11,006 to block 11,500 where the process ends. In the event that the answer at block 11,004 is “Yes”, the process goes to block 11,008.
At block 11,008 the process clears this RTR port entry from the “port masks” associated with this group G in the L2 entry. Upon completion of block 11,008, the process then goes to block 11,010.
At block 11,010 a check is done to see if the union of all port masks are all L3 groups for this L2 entry contain this RTR port. In the event that the answer is “Yes”, the process goes to path 11,006 to block 11,500 where the process ends. In the event that the answer in block 11,010 is “No”, the process goes to block 11,012.
At block 11,012 the process clears this RTR port from the all the logic gate entities for this L2 entry. Upon completion of block 11,012, the process goes to block 5 11,014.
At block 11,014 the process forwards an RGMP LEAVE on all the RTR ports, only if there is no other outstanding RGMP JOIN for this group from some other “RTR” port on this switch. Upon completion of block 11,004, the process goes to block 11,500 and ends.
Turning now to
In the event that the answer at block 12,004 is yes, the process goes to block 12,008.
At block 12,008 the process checks to determine if this RTR port was an RGMP RTR port. In the event that the question at block 12,008 is answered no, the process goes to path 12,006 where it goes to block 12,500 and the process ends. In the event that the answer at block 12,008 is yes, the process goes to block 12,010. At block 12,010 all of the L2 entries learned on that interface are added to this RTR report. The process then goes to block 12,012.
At block 12,012 the process updates the RTR port table entry for this RTR port to indicate that it is “not” an RGMP RTR port. Upon completion of block 12,012 the process goes to 12,014. At block 014 the process removes the RGMP Hello timer for this RTR port. Upon completion of block 12,014 the process goes to block 12,016.
At block 12,016 the process forwards an RGMP BYE message on all of the RTR ports. Upon completion of block 12,016 the process goes to block 12,500 where the process ends.
Turning now to
Turning now to
Turning now to
When the network device 15,000 is a layer 3 switch, that is a router, it routes packets based upon reading the layer 3 fields of the packet.
Each linecard 15,002, 15,004, . . . 15,008 supports a port. For example, linecard 15,002 has port 15,002A; linecard 15,004 has port 15,004A; linecard 15,006 has port 15,006A, . . . and linecard 15,008 has port 15,008A, etc. Each linecard has a memory unit. For example, linecard 15,002 has memory unit 15,002M, linecard 15,004 has memory unit 15,004M, linecard 15,006 has memory unit 15,006M . . . and linecard 15,008 has memory unit 15,008M, etc. Each line card has a processor P, indicated by blocks 15,002P, 15,004P, 15,006P, . . . 15,008P, etc. The various linecards are interconnected by switch fabric 15,010. Switch fabric 15,010 may be, for example, a crossbar type switch fabric, an ATM based switch fabric, or may be simply a computer bus. A central processor unit forwarding engine 15,012 also attaches to switch fabric 15,010. In operation, a packet arrives at a port of a linecard and is transferred by switch fabric 15,010 to memory units in the required linecards. Ports 604, 606, 608, 610, 612, 614, 618, etc. are implemented on linecards 15,002, through 15,008 etc.
Further, CPU control engine 15,030 attaches to switch fabric 15,010. CPU control engine 15,030 is used to execute various control protocols for the network device. For example, CPU control engine 15,030 may be used to execute the Spanning Tree Protocol, the Link State Routing Protocol, the IGMP snooping protocol, RGMP protocol, etc. Execution of a process in a CPU is often referred to as “running” the process. Data read from various fields of a received packets are transferred to CPU control engine 15,030. Then CPU control engine exercises control of the network device through switch fabric 15,010, through control lines not shown in
For example, in the event that a packet is received from an external connection at port 15,002A, the packet arrives at port 15,002A, is stored in memory unit 15,002M, and is simultaneously transmitted on switch fabric 15,010 to all of the other linecards, where the packet is stored in the memory unit of each of the other linecards. The memory 15,002M in the receiving linecard is necessary as a buffer in the event that switch fabric 15,010 is busy at the time that the packet arrives at port 15,002A. Processors 15,002P, 15,004P, 15,006P, . . . 15,008P, etc. on each linecard receive information from circuits on the linecard interpreting fields of the packets as the packet is being received.
In an exemplary embodiment of the invention, processors 15,002P, 15,004P, 15,006P, . . . 15,008P, etc. on the individual linecards act as forwarding engines and make decisions concerning the ports through which the packet is to be transmitted.
In an alternative exemplary embodiment of a network device, as the packet is being transferred on switch fabric 15,010 to all of the other linecards, fields of the packet are interpreted by circuitry in the receiving linecard, information is transferred to CPU forwarding engine 15,012, and CPU 15,012 makes decisions concerning which ports the packet is to be transmitted out through. Once CPU 15,012 makes a decision as to which ports the packet should be forwarded through, CPU 15,012 asserts control lines (not shown in
In an alternative embodiment of the invention, a linecard may support a plurality of ports rather than only one port as is shown in FIG. 15. Three dots 15,009 indicate that a large number of linecards may be supported by the network device.
The exemplary internal architecture of a typical network device as shown in block diagram 15,000 permits line speed transfer of an incoming packet to one or more outgoing ports, simultaneously with receipt of the packet. Only a small delay is encountered, depending upon factors, for example, the state of switch fabric 15,010 as the packet is received at its incoming port, and the delay imposed by ordinary switch fabric transfer processes along switch fabric 15,010.
In an alternative exemplary design of a network device, a linecard may transfer an incoming packet to global memory unit 15,020. CPU 15,012 reads fields of the packet and decides which linecards must transmit the packet. After the packet is received into global memory 15,020, the packet is read by each linecard which must transmit the packet, and then the packet is transmitted by the linecards. In either event, the hardware reads the fields of the appropriate Layer, and responds by making the appropriate decision.
It is to be understood that the above-described embodiments are simply illustrative of the principles of the invention, and various other modifications and changes may be made by those skilled in the art which embody the principles of the invention and fall within the spirit and scope thereof.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5917820||Jun 10, 1996||Jun 29, 1999||Cisco Technology, Inc.||Efficient packet forwarding arrangement for routing packets in an internetwork|
|US5959989||Jun 25, 1997||Sep 28, 1999||Cisco Technology, Inc.||System for efficient multicast distribution in a virtual local area network environment|
|US6055364||Jul 31, 1997||Apr 25, 2000||Cisco Technology, Inc.||Content-based filtering of multicast information|
|US6078590||Jul 14, 1997||Jun 20, 2000||Cisco Technology, Inc.||Hierarchical routing knowledge for multicast packet routing|
|US6147993 *||Oct 14, 1997||Nov 14, 2000||Cisco Technology, Inc.||Method and apparatus for implementing forwarding decision shortcuts at a network switch|
|US6182147||Jul 31, 1998||Jan 30, 2001||Cisco Technology, Inc.||Multicast group routing using unidirectional links|
|US6212182||Jun 27, 1996||Apr 3, 2001||Cisco Technology, Inc.||Combined unicast and multicast scheduling|
|US6262988 *||May 12, 2000||Jul 17, 2001||Cisco Technology, Inc.||Method and system for subnetting in a switched IP network|
|US6370142 *||Apr 2, 1997||Apr 9, 2002||Nortel Networks Limited||Method and apparatus for performing per-port IP multicast pruning|
|US6469987 *||Jan 13, 1998||Oct 22, 2002||Enterasys Networks, Inc.||Virtual local area network with trunk stations|
|1||D. Estrin et al., Protocol Independent Mulitcast-Sparse Mode (PIM-SIM) : Protocol Specification, Request for Comments 2362, Network Working Group, Internet Engineering Task Force, 1998, pp. 1-66.|
|2||D. Estrin et al., Protocol Independent Multicast-Sparse Mode (PIM-SIM) : Protocol Specification, Request for Comments 2117, Network Working Group, Internet Engineering Task Force, 1997, pp. 1-66.|
|3||*||F. Ansari et al, IP switching over fast ATM cell transport (IPSOFACTO): IP multicast over wireless ATM, Oct. 5-9 1998, IEEE ICUPC '98, vol.: 1, pp. 621-626.*|
|4||S. Deering, Host Extensions for IP Multicasting, Request for Comments 1112, Network Working Group, Internet Engineering Task Force, 1989, pp. 1-17.|
|5||W. Fenner, Internet Group Management Protocol, Version 2, Request for Comments 2236, Network Working Group, Internet Engineering Task Force, 1997, pp. 1-24.|
|6||*||Wanjiun Liao et al, Receiver-initiated group membership protocol (RGMP): A new group management protocol for IP multicasting, Oct. 3 1-Nov. 3, 1999, Network Protocols (ICNP '99) Proceedings, Seventh Conference, pp. 51-58.*|
|7||*||Won-Tae Kim et al, Scalable QoS-based IP multicast over label switching wireless ATM networks, Sep.-Oct. 2000, IEEE, vol.: 14, Issue 5, pp. 26-31.*|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7325074||Nov 15, 2005||Jan 29, 2008||Cisco Technology, Inc.||Incremental compilation of packet classifications using fragmented tables|
|US7359939 *||Dec 6, 2002||Apr 15, 2008||Alcatel Canada, Inc.||Fast service restoration for lost IGMP leave requests|
|US7385977 *||Sep 10, 2004||Jun 10, 2008||Cisco Technology, Inc.||Multicast system for forwarding desired multicast packets in a computer network|
|US7389359 *||Oct 19, 2001||Jun 17, 2008||Foundry Networks, Inc.||Method and system for intelligently forwarding multicast packets|
|US7417990 *||Jul 12, 2005||Aug 26, 2008||Hitachi Communication Technologies, Ltd.||Layer 2 switch|
|US7512124 *||Nov 14, 2003||Mar 31, 2009||Alcatel Lucent||Multicast optimization in a VLAN tagged network|
|US7512146||May 10, 2006||Mar 31, 2009||Garrettcom, Inc.||Method and apparatus for layer 2 multicast traffic management|
|US7519662 *||Jan 26, 2007||Apr 14, 2009||Alcatel-Lucent Canada Inc.||System and method for converting requests between different multicast protocols in a communication network|
|US7590115 *||Aug 26, 2005||Sep 15, 2009||Juniper Networks, Inc.||Exchange of control information for virtual private local area network (LAN) service multicast|
|US7646771||Jan 12, 2010||Cisco Technology, Inc.||Compilation of access control lists|
|US7729482||Feb 27, 2006||Jun 1, 2010||Cisco Technology, Inc.||Method and system for providing communication protocol interoperability|
|US7822027||Oct 26, 2010||Cisco Technology, Inc.||Network routing to the socket|
|US7827304 *||May 28, 2002||Nov 2, 2010||Zooinnet||Method and system for virtual multicast networking|
|US7830825 *||Mar 24, 2005||Nov 9, 2010||Huawei Technologies Co., Ltd.||Method for realizing the multicast service|
|US7877508||May 14, 2008||Jan 25, 2011||Foundry Networks, Llc||Method and system for intelligently forwarding multicast packets|
|US7911977 *||Mar 22, 2011||Cisco Technology, Inc.||Designated router assignment per multicast group address/range|
|US7969980 *||Jun 28, 2011||Cisco Technology, Inc.||Internet protocol multicast distribution in Ethernet networks|
|US8040884 *||Oct 18, 2011||Cisco Technology, Inc.||Constraining multicast traffic between a layer 2 network device and a router|
|US8064440||Aug 4, 2006||Nov 22, 2011||Cisco Technology, Inc.||Technique for avoiding IP lookup with multipoint-to-multipoint label switched paths|
|US8099516 *||Feb 23, 2004||Jan 17, 2012||Avaya Inc.||Protocol independent multicast designated router enhancements for supporting internet group management protocol in a multi-access network|
|US8116310 *||Nov 24, 2007||Feb 14, 2012||Cisco Technology, Inc.||Reducing packet flooding by a packet switch|
|US8208463||Oct 24, 2006||Jun 26, 2012||Cisco Technology, Inc.||Subnet scoped multicast / broadcast packet distribution mechanism over a routed network|
|US8259612||Jun 9, 2006||Sep 4, 2012||Cisco Technologies, Inc.||Method of routing multicast traffic|
|US8406125||Oct 27, 2010||Mar 26, 2013||Brocade Communications Systems, Inc.||Synchronization of multicast information using incremental updates|
|US8443103||Oct 20, 2010||May 14, 2013||Foundry Networks, Llc||Method and system for intelligently forwarding multicast packets|
|US8495418||Jul 23, 2010||Jul 23, 2013||Brocade Communications Systems, Inc.||Achieving ultra-high availability using a single CPU|
|US8503289||Oct 27, 2010||Aug 6, 2013||Brocade Communications Systems, Inc.||Synchronizing multicast information for linecards|
|US8576703 *||Oct 27, 2010||Nov 5, 2013||Brocade Communications Systems, Inc.||Synchronization of multicast information using bicasting|
|US8599685 *||Sep 26, 2006||Dec 3, 2013||Cisco Technology, Inc.||Snooping of on-path IP reservation protocols for layer 2 nodes|
|US8611252||Jul 25, 2012||Dec 17, 2013||Cisco Technology, Inc.||Method of routing multicast traffic|
|US8611346||Jun 18, 2010||Dec 17, 2013||Cisco Technology, Inc.||Multicast sparse-mode source redundancy|
|US8638787||May 20, 2010||Jan 28, 2014||Cisco Technology, Inc.||Multicast hello on demand|
|US8705528||Apr 25, 2012||Apr 22, 2014||Cisco Technology, Inc.||Subnet scoped multicast/broadcast packet distribution mechanism over a routed network|
|US8769155||Jun 24, 2010||Jul 1, 2014||Brocade Communications Systems, Inc.||Techniques for synchronizing application object instances|
|US8935333 *||Aug 9, 2001||Jan 13, 2015||International Business Machines Corporation||Implementing multicast on a system area network channel adapter|
|US9026848||Jun 24, 2013||May 5, 2015||Brocade Communications Systems, Inc.||Achieving ultra-high availability using a single CPU|
|US9059943||Nov 26, 2013||Jun 16, 2015||Cisco Technology, Inc.||Method of routing multicast traffic|
|US9065669 *||Aug 24, 2004||Jun 23, 2015||Avaya Inc.||Method and apparatus for authorizing multicast forwarding states|
|US9094221||Jun 24, 2013||Jul 28, 2015||Brocade Communications Systems, Inc.||Synchronizing multicast information for linecards|
|US9104619||Jul 23, 2010||Aug 11, 2015||Brocade Communications Systems, Inc.||Persisting data across warm boots|
|US9112715 *||Apr 22, 2010||Aug 18, 2015||Foundry Networks, Llc||Method and system for intelligently forwarding multicast packets|
|US9143335||Sep 15, 2012||Sep 22, 2015||Brocade Communications Systems, Inc.||Multicast route cache system|
|US9203690||Mar 14, 2013||Dec 1, 2015||Brocade Communications Systems, Inc.||Role based multicast messaging infrastructure|
|US9274851||Nov 25, 2009||Mar 1, 2016||Brocade Communications Systems, Inc.||Core-trunking across cores on physically separated processors allocated to a virtual machine based on configuration information including context information for virtual machines|
|US9276756||Feb 19, 2013||Mar 1, 2016||Brocade Communications Systems, Inc.||Synchronization of multicast information using incremental updates|
|US9288066||Nov 10, 2011||Mar 15, 2016||Cisco Technology, Inc.||Dynamic multicast mode selection in a communication network|
|US20020150094 *||Oct 26, 2001||Oct 17, 2002||Matthew Cheng||Hierarchical level-based internet protocol multicasting|
|US20030033426 *||Aug 9, 2001||Feb 13, 2003||International Business Machines Corporation||Apparatus and method for implementing multicast on a system area network channel adapter|
|US20030079040 *||Oct 19, 2001||Apr 24, 2003||Nitin Jain||Method and system for intelligently forwarding multicast packets|
|US20040111470 *||Dec 6, 2002||Jun 10, 2004||Alcatel Canada Inc.||Fast service restoration for lost IGMP leave requests|
|US20040125803 *||Nov 14, 2003||Jul 1, 2004||Sangroniz Robert Leon||Multicast optimization in a VLAN tagged network|
|US20050076207 *||May 28, 2002||Apr 7, 2005||Hyunje Park||Method and system for virtual multicast networking|
|US20050111474 *||Dec 30, 2004||May 26, 2005||Fujitsu Limited||IP multicast communication system|
|US20050157741 *||Sep 10, 2004||Jul 21, 2005||Ishan Wu||Multicast system for forwarding desired multicast packets in a computer network|
|US20060045085 *||Aug 24, 2004||Mar 2, 2006||Haixiang He||Method and apparatus for authorizing multicast forwarding states|
|US20060072572 *||Jul 12, 2005||Apr 6, 2006||Koji Ikeda||Layer 2 switch|
|US20060268869 *||May 31, 2005||Nov 30, 2006||Arjen Boers||Designated router assginment per multicast group address/range|
|US20070030817 *||Aug 8, 2005||Feb 8, 2007||Senthil Arunachalam||Constraining multicast traffic between a layer 2 network device and a router|
|US20070036161 *||Jul 13, 2006||Feb 15, 2007||Mahamuni Atul B||System and method of routing Ethernet MAC frames using Layer-2 MAC addresses|
|US20070112794 *||Nov 15, 2005||May 17, 2007||Mcrae Andrew||Incremental compilation of packet classifications using fragmented tables|
|US20070124454 *||Jan 26, 2007||May 31, 2007||Watkinson David A||System and method for converting requests between different multicast protocols in a communication network|
|US20070201449 *||Feb 27, 2006||Aug 30, 2007||Cisco Technology, Inc.||Method and system for providing communication protocol interoperability|
|US20070253409 *||Mar 24, 2005||Nov 1, 2007||Huawei Technologies Co., Ltd.||Method for Realizing the Multicast Service|
|US20070286093 *||Jun 9, 2006||Dec 13, 2007||Yiqun Cai||Method of routing multicast traffic|
|US20080075089 *||Sep 26, 2006||Mar 27, 2008||Cisco Technology, Inc.||Snooping of on-path ip reservation protocols for layer 2 nodes|
|US20080084888 *||Oct 5, 2006||Apr 10, 2008||Cisco Technology, Inc.||Network Routing to the Socket|
|US20080095160 *||Oct 24, 2006||Apr 24, 2008||Cisco Technology, Inc.||Subnet Scoped Multicast / Broadcast Packet Distribution Mechanism Over a Routed Network|
|US20080123650 *||Aug 4, 2006||May 29, 2008||Nidhi Bhaskar||Technique for avoiding IP lookup with multipoint-to-multipoint label switched paths|
|US20090135722 *||Nov 24, 2007||May 28, 2009||Cisco Technology, Inc.||Reducing packet flooding by a packet switch|
|US20090225660 *||Mar 3, 2009||Sep 10, 2009||Akira Sakurai||Communication device and operation management method|
|US20100135298 *||Dec 1, 2009||Jun 3, 2010||Electronics And Telecommunications Research Institute||Method and system for providing source specific multicast service on ethernet network|
|US20100238927 *||Sep 23, 2010||Brocade Communications Systems, Inc.||Method and system for intelligently forwarding multicast packets|
|US20110064078 *||Oct 20, 2010||Mar 17, 2011||Brocade Communications Systems, Inc.||Method and system for intelligently forwarding multicast packets|
|US20110126196 *||Nov 25, 2009||May 26, 2011||Brocade Communications Systems, Inc.||Core-based visualization|
|US20110228771 *||Sep 22, 2011||Brocade Communications Systems, Inc.||Synchronization of multicast information using bicasting|
|US20110231578 *||Sep 22, 2011||Brocade Communications Systems, Inc.||Techniques for synchronizing application object instances|
|US20130089094 *||Jul 1, 2010||Apr 11, 2013||Telefonaktiebolaget L M Ericsson (Publ)||Method and Apparatus for Dissemination of Information Between Routers|
|US20130201988 *||Sep 30, 2011||Aug 8, 2013||Hangzhou H3C Technologies Co., Ltd.||Method for pruning a multicast branch, protocol independent multicast router, and layer-2 exchange|
|US20140219156 *||Feb 1, 2013||Aug 7, 2014||Thomson Licensing||Optimizing wireless local area network communications|
|CN100463447C||Aug 31, 2005||Feb 18, 2009||杭州华三通信技术有限公司||Switchnig equipment and method for controlling multicasting data forwarding|
|EP2099180A1 *||Mar 2, 2009||Sep 9, 2009||Nec Corporation||Switching device and method for Layer-2 forwarding of OAM frames with multicast Layer-3 addresses|
|EP2192719A1 *||Dec 1, 2009||Jun 2, 2010||Electronics and Telecommunications Research Institute||Method and system for providing source specific multicast service on Ethernet network|
|WO2007106219A3 *||Jan 19, 2007||Dec 27, 2007||Cisco Tech Inc||Method and system for providing communication protocol interoperability|
|WO2007142705A1 *||Jan 31, 2007||Dec 13, 2007||Cisco Technology, Inc.||Routing multicast traffic|
|WO2009095041A1 *||Apr 16, 2008||Aug 6, 2009||Soporte Multivendor S.L.||Method for managing multicast traffic through a switch operating in the layer 2 of the osi model, and router and switch involved in said method|
|Oct 16, 2000||AS||Assignment|
Owner name: CISCO TECHNOLOGY, INC,, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WU, ISHAN;CHANDIKA, NAGARANI;MELLACHERUVA, RAMANA;AND OTHERS;REEL/FRAME:011236/0960
Effective date: 20001013
|Jun 19, 2008||FPAY||Fee payment|
Year of fee payment: 4
|Jul 25, 2012||FPAY||Fee payment|
Year of fee payment: 8