Network system, packet transmission device, packet transmission method, and information processing program
8 claims: 4 independent, 4 dependent
- 1マルチキャストルーティングを行う ことでマルチキャストパケットを送受信する 複数 の通 信装置と、 前記複数 の通 信装置間を接続し、マルチキャストパケットを受信ポート以外のポートから転送する複数の パケット伝送 装置と、を含むネットワークシステムであって、 前記複数の パケット伝送 装置のそれぞれは、 前記複数の通信装置のうち マルチキャスト配信ツリーのランデブーポイントとな る通 信装置のアドレスを記憶する第2の記憶部と、 前記複数の通信装置のうちのいずれかから送信されるマルチキャストグループへの参加要求を転送できるよう、 前記参加要求を転送するポートを、自装置が有するポートのうちの前記ランデブーポイントが存在する側のポートのみに決定する判定部と、 転送のため前記参加要求を受信した受信ポートを該マルチキャストグループのマルチキャストパケットの転送ポートとして記憶する第1の記憶部と、 前記マルチキャストグループのマルチキャストパケットを、自装置が有するポートのうちの前記転送ポートから転送する転送部と、 を備え、 前記 パケット伝送 装置の前記判定部は、 前記複数 の通 信装置のうちのいずれかから、マルチキャストグループからの脱退要求を受信した場合に は 、前記脱退要求を 転送できるよう、前記脱退要求を 転送するポートを、自装置が有するポートのうちの前記ランデブーポイントが存在する側のポートのみに決定し、前記脱退要求 を 受信 した ポート以外に、前記第1の記憶部に、該脱退要求 の対象である マルチキャストグループ への参加要求に対応してマルチキャストパケット の転送ポートが記憶されている場合には、 当該参加要求を送信した通信装置がマルチキャストパケットを受信できるよう 該マルチキャストグループへの参加要求の作成及び送信を決定する、ネットワークシステム。
- 2前記 パケット伝送 装置は、 前記複数の パケット伝送 装置間で所定のプロトコルにより構築される論理的なツリー構造についての情報を記憶する第3の記憶部と、 自装置が前記参加要求を受信した場合に、前記ツリー構造におけるルートとなる パケット伝送 装置に、前記参加要求の受信ポートを通知し、 自装置が前記ルートである場合に、前記第3の記憶部に記憶される前記ツリー構造についての情報に基づいて、前記参加要求の経路を特定し、該経路上の前記 パケット伝送 装置の前記参加要求の受信ポートを、前記マルチキャストグループの転送ポートとして、前記複数の パケット伝送 装置のそれぞれに通知する、通知部と、をさらに備える請求項1に記載のネットワークシステム。
- 3前記通知部は、前記経路外のポートを、前記マルチキャストグループのパケットを転送しない破棄ポートとして通知する、請求項2に記載のネットワークシステム。
- 4前記通知部は、 前記参加要求の受信ポートの通知を所定周期で行い、 前記第1の記憶部に格納される転送ポートについて、前記参加要求の受信ポートの通知が所定時間受信されない場合には、前記マルチキャストグループについて、全ポートを破棄ポートとして前記複数の パケット伝送 装置のそれぞれに通知する、請求項3に記載のネットワークシステム。
- 5前記 パケット伝送 装置は、 前記参加要求の受信ポートを前記マルチキャストグループの転送ポートとして前記第1の記憶部に記憶し、前記第1の記憶部に記憶される転送ポートについて、前記参加要求が所定時間受信されない場合に、該転送ポートとして記憶されるポートを前記マルチキャストグループのパケットを転送しない破棄ポートに変更する管理部を、さらに備える請求項1に記載のネットワークシステム。
- 6マルチキャストルーティングを行う ことでマルチキャストパケットを送受信する 複数 の通 信装置間を接続し、マルチキャストパケットを受信ポート以外のポートから転送するパケット伝送装置であって、 前記複数の通信装置のうち マルチキャスト配信ツリーのランデブーポイントとな る通 信装置のアドレスを記憶する第2の記憶部と、 前記複数の通信装置のうちのいずれかから送信されるマルチキャストグループへの参加要求を転送できるよう、 前記参加要求を転送するポートを、自装置が有するポートのうちの前記ランデブーポイントが存在する側のポートのみに決定する判定部と、 前記参加要求を転送できるよう、前記参加要求を受信した受信ポートを該マルチキャストグループのマルチキャストパケットの転送ポートとして記憶する第1の記憶部と、 前記マルチキャストグループのマルチキャストパケットを、前記パケット伝送装置が有するポートのうちの前記転送ポートから転送する転送部と、 を備え、 前記判定部は、 前記複数 の通 信装置のうちのいずれかから、マルチキャストグループからの脱退要求を受信した場合に は 、前記脱退要求を 転送できるよう、前記脱退要求を 転送するポートを、自装置が有するポートのうちの前記ランデブーポイントが存在する側のポートのみに決定し、 前記脱退要求 を 受信 した ポート以外に、前記第1の記憶部に、該脱退要求 の対象である マルチキャストグループ への参加要求に対応してマルチキャストパケット の転送ポートが記憶されている場合には、 当該参加要求を送信した通信装置がマルチキャストパケットを受信できるよう 該マルチキャストグループへの参加要求の作成及び送信を決定する、パケット伝送装置。
- 7マルチキャストルーティングを行う ことでマルチキャストパケットを送受信する 複数 の通 信装置間を接続し、マルチキャストパケットを受信ポート以外のポートから転送するパケット伝送装置が、 前記複数の通信装置のうち マルチキャスト配信ツリーのランデブーポイントとな る通 信装置のアドレスを第2の記憶部に記憶し、 前記複数の通信装置のうちのいずれかから送信されるマルチキャストグループへの参加要求を転送できるよう、 前記参加要求を転送するポートを、自装置が有するポートのうちの前記ランデブーポイントが存在する側のポートのみに決定し、 転送のため前記参加要求を受信した受信ポートを該マルチキャストグループのマルチキャストパケットの転送ポートとして第1の記憶部に記憶し、 前記マルチキャストグループのマルチキャストパケットを、前記パケット伝送装置が有するポートのうちの前記転送ポートから転送し、 前記複数 の通 信装置のうちのいずれかから、マルチキャストグループからの脱退要求を受信した場合に は 、前記脱退要求を 転送できるよう、前記脱退要求を 転送するポートを、自装置が有するポートのうちの前記ランデブーポイントが存在する側のポートのみに決定し、前記脱退要求 を 受信 した ポート以外に、前記第1の記憶部に、該脱退要求 の対象である マルチキャストグループ への参加要求に対応してマルチキャストパケット の転送ポートが記憶されている場合には、 当該参加要求を送信した通信装置がマルチキャストパケットを受信できるよう 該マルチキャストグループへの参加要求の作成及び送信を決定する、パケット伝送方法。
- 8マルチキャストルーティングを行う ことでマルチキャストパケットを送受信する 複数 の通 信装置間を接続し、マルチキャストパケットを受信ポート以外のポートから転送するパケット伝送装置に、 前記複数の通信装置のうち マルチキャスト配信ツリーのランデブーポイントとな る通 信装置のアドレスを第2の記憶部に記憶させ、 前記複数の通信装置のうちのいずれかから送信されるマルチキャストグループへの参加要求を転送できるよう、 前記参加要求を転送するポートを、自装置が有するポートのうちの前記ランデブーポイントが存在する側のポートのみに決定させ、 転送のため前記参加要求を受信した受信ポートを該マルチキャストグループのマルチキャストパケットの転送ポートとして第1の記憶部に記憶させ、 前記複数 の通 信装置のうちのいずれかから、マルチキャストグループからの脱退要求を受信した場合に は 、前記脱退要求を 転送できるよう、前記脱退要求を 転送するポートを、自装置が有するポートのうちの前記ランデブーポイントが存在する側のポートのみに決定させ、前記脱退要求 を 受信 した ポート以外に、前記第1の記憶部に、該脱退要求 の対象である マルチキャストグループ への参加要求に対応してマルチキャストパケット の転送ポートが記憶されている場合には、 当該参加要求を送信した通信装置がマルチキャストパケットを受信できるよう 該マルチキャストグループへの参加要求の作成及び送信を決定させる、ための情報処理プログラム。
Independent claims8
162 paragraphs, as filed
The present invention relates to a network system, a packet transmission device, a packet transmission method, and an information processing program.
When a layer 2 switch (hereinafter, L2SW) receives a multicast packet, it normally forwards the multicast packet from all ports other than the receiving port belonging to the same VLAN (Virtual Local Area Network). Forwarding a packet from all ports in the same VLAN other than the receiving port is called flooding.
<p><patcit num="1"><text>Japanese Unexamined Patent Publication No. 2007-174489</text></patcit><patcit num="2"><text>Japanese Patent Application Laid-Open No. 2005-253026</text></patcit><patcit num="3"><text>Japanese Unexamined Patent Publication No. 2008-153766</text></patcit><patcit num="4"><text>Japanese Unexamined Patent Publication No. 2008-177968</text></patcit></p>
<p> However, due to the flooding of L2SW, the multicast packet is also forwarded from the port to which the device that does not want the multicast packet is connected, so that the bandwidth of the line may be compressed.</p><p> According to one aspect, the present invention aims to suppress flooding of multicast packets.</p>
<p> In one embodiment, a plurality of first communication devices that perform multicast routing and a plurality of second communication devices that connect between the plurality of first communication devices and forward multicast packets from ports other than the receiving port. , Which is a network system including, each of the plurality of second communication devices has a receiving port for a request to join a multicast group transmitted from any of the plurality of first communication devices. A network system including a first storage unit that stores a multicast packet of the multicast group as a forwarding port, and a forwarding unit that forwards the multicast packet of the multicast group from the forwarding port among the ports of its own device. is there.</p><p> Further, in one aspect, it is a packet transmission device as a second communication device in the network system described above. In one aspect, it is a packet transmission method in which the second communication device in the network system described above executes the processing described above. Also, in one embodiment, a program that causes the computer to function as the second communication device described above, and a computer-readable and non-temporary recording medium that records the program can be included. A recording medium that can be read from a computer or the like by storing information such as data and programs by electrical, magnetic, optical, mechanical, or chemical action in a non-temporary recording medium that can be read by a computer or the like. To say.</p>
<p> As one aspect, flooding of multicast packets can be suppressed.</p>
<figref num="1">It is a figure which shows an example of the processing flow concerning participation in a multicast group and delivery of a multicast packet.</figref><figref num="2">It is a figure which shows an example of the processing flow when the receiving device under L3SW # 8 newly joins a multicast group.</figref><figref num="3">It is a figure which shows an example of the processing flow when the receiving device under L3SW # 5 leaves a multicast group.</figref><figref num="4">It is a figure which shows an example of the processing flow which concerns on participation in a multicast group and delivery of a multicast packet which concerns on 1st Embodiment.</figref><figref num="5">It is a figure which shows an example of the processing flow after receiving the multicast reception request message of L2SW # 1 which is a root SW.</figref><figref num="6">It is a figure which shows an example of the processing flow when the receiving device under L3SW # 8 newly joins a multicast group.</figref><figref num="7">It is a figure which shows an example of the processing flow when the receiving device under L3SW # 5 leaves a multicast group.</figref><figref num="8">It is a figure which shows an example of the processing of L2SW related to the operation of a multicast network.</figref><figref num="9">It is a figure which shows an example of the hardware configuration of L2SW.</figref><figref num="10">It is a figure which shows an example of the functional structure of L2SW.</figref><figref num="11">This is an example of a multicast forwarding judgment table.</figref><figref num="12">It is a figure which shows an example of the information contained in a multicast reception request message.</figref><figref num="13">It is a figure which shows an example of the information contained in a multicast reception setting message.</figref><figref num="14">It is a figure which shows the configuration of a network assumed in a specific example, and the physical connection relationship between L2SWs in a network.</figref><figref num="15A">It is a figure which shows an example of the multicast reception request message when the participation request (IGMP report) to a multicast group is transmitted from the receiving device in the network shown in FIG.</figref><figref num="15B">It is a figure which shows an example of the multicast reception setting message for the multicast reception request message shown in FIG. 15A.</figref><figref num="16A">This is an example of a flowchart of processing of the control unit when a packet is input to the control unit.</figref><figref num="16B">This is an example of a flowchart of processing when a Join message is input to the control unit.</figref><figref num="16C">This is an example of a flowchart of processing when a Prune message is input to the control unit.</figref><figref num="16D">This is an example of a flowchart of processing when a multicast reception request message addressed to the own device is input to the control unit.</figref><figref num="17">This is an example of a flowchart of the processing of the SW part when a multicast packet is received.</figref><figref num="18">It is a figure which shows an example of the processing flow which concerns on the delivery of the multicast packet in the multicast network which concerns on 2nd Embodiment.</figref><figref num="19">In the second embodiment, it is an example of a flowchart of processing of the control unit when a packet is input to the control unit.</figref>
Hereinafter, embodiments of the present invention will be described with reference to the drawings. The configurations of the following embodiments are examples, and the present invention is not limited to the configurations of the embodiments.
<Multicast network> Fig. 1, Fig. 2, and Fig. 3 are diagrams showing an example of the processing flow related to the distribution of multicast packets in the multicast network. The same network is shown in Figure 1, Figure 2, and Figure 3. In the networks shown in FIGS. 1, 2 and 3, it is assumed that the L2SWs are connected by an optical line and the L2SWs and the L3SWs are connected by a metal line. In addition, the multicast packet transmitter exists under L3SW # 1. Also, it is assumed that each port of each L2SW belongs to the same VLAN. Hereinafter, it is assumed that the same multicast group is described with respect to FIGS. 1, 2, and 3.
For example, PIM-SM (Protocol Independent Multicast-Sparse Mode), which is a multicast routing protocol, is enabled between L3SWs, and route information and the like of multicast packets are exchanged. In the examples shown in FIGS. 1, 2, and 3, the rendezvous point (RP) of the multicast distribution tree is L3SW # 1.
For example, IGMP (Internet Group Management Protocol) is enabled between the L3SW and the host (receiver and transmitter), and information such as joining or leaving the multicast group of the host is exchanged.
Between L2SW, for example, TRILL, a protocol for route redundancy in the L2SW topology, is enabled. In TRILL, after unicast routing is completed, a multicast distribution tree is formed between L2SWs, apart from the multicast routing protocol that is valid between L3SWs. In TRILL, when the L2SW receives a multicast packet, it is once forwarded to the root SW, and the root SW delivers the multicast packet downstream of the multicast distribution tree. In the examples shown in FIGS. 1, 2, and 3, the root SW of TRILL's multicast distribution tree is L2SW # 1.
FIG. 1 is a diagram showing an example of a processing flow related to participation in a multicast group and distribution of multicast packets. (1) The receiving device under L3SW # 5 sends an IGMP report, which is a request to join the multicast group, in order to join the multicast group.
(2) When L3SW # 5 receives an IGMP report from a subordinate receiving device, it registers the receiving device as a delivery destination of the multicast packet of the multicast group specified by the IGMP report. At the same time, L3SW # 5 sends a PIM Join message, which is a request to join the multicast group, in order to join the multicast group. The Join message is sent by Hop-by-Hop and delivered to the RP L3SW.
Since the Join message is a multicast packet destined for the multicast IP address 224.0.0.13, each L2SW forwards the Join message to the root SW using TRILL's multicast distribution tree. At this time, each L2SW transfers the Join message while flooding. Therefore, the Join message sent from L3SW # 5 reaches neither the RP of the relevant multicast group nor the L3SW # 2 to # 4 and # 6 to # 8 to which the receiving device of the relevant multicast group is not connected.
When the Join message reaches L3SW # 1, which is the RP, the delivery of the multicast packet to L3SW # 5 is registered in the RP, and the multicast packet is delivered to L3SW # 5. After that, L3SW # 5 sends a Join message at a predetermined cycle. The RP continues the delivery of the multicast packet while receiving the Join message, and stops the delivery of the multicast packet of the multicast group when the Join message is not received for a predetermined time. The transmission cycle of the Join message is, for example, 60 seconds. Further, the predetermined time for not receiving the Join message until the RP determines that the delivery of the multicast packet is stopped is, for example, 3 minutes.
(3) When the transmitting device sends a multicast packet, L3SW # 1, which is the RP, sends the multicast packet according to the multicast distribution tree of the corresponding multicast group. Since L2SW # 1, which first receives the multicast packet transmitted from L3SW # 1, is the root SW, forwards the multicast packet downstream of TRILL's multicast distribution tree. Each L2SW on the downstream side relays the multicast packet further downstream while flooding it. Therefore, the multicast packet also reaches L3SW # 2 to # 4 and # 6 to # 8 which are not connected to the receiving device of the corresponding multicast group.
FIG. 2 is a diagram showing an example of a processing flow when a receiving device under L3SW # 8 newly joins a multicast group. (4) An IGMP report is sent from the receiving device under L3SW # 8 that newly joins the multicast group. (5) When L3SW # 8 receives the IGMP report, it registers the new receiving device as the delivery destination of the corresponding multicast packet. However, since L3SW # 8 has already received the multicast packet of the corresponding multicast group, it does not send a new Join message. Therefore, L3SW # 8 does not send a Join message at a predetermined cycle.
FIG. 3 is a diagram showing an example of the processing flow when the receiving device under L3SW # 5 leaves the multicast group. (6) The receiving device under L3SW # 5 transmits an IGMP leave request for withdrawal from the multicast group.
(7) When L3SW # 5 receives the IGMP leave, the receiving device of the corresponding multicast group disappears under it, so the delivery of the multicast packet to the subordinate is stopped. Further, since L3SW # 5 does not need to receive the multicast packet of the corresponding multicast group any more, it transmits a PIM Prune message which is a request for withdrawal from the multicast group.
The Prune message is also a multicast packet sent to the same multicast IP address 224.0.0.13 as the Join message. Therefore, each L2SW relays the Prune message to the RP L3SW # 1 while flooding. Therefore, the Prune message sent from L3SW # 5 also reaches L3SW # 1 ~ # 4 and # 6 ~ # 8.
If the RP L3SW # 1 does not receive the Join message within 3 seconds after receiving the Prune message, it stops the delivery of the multicast packet of the corresponding multicast group (RFC2362 specification). However, L3SW # 8 is connected to the receiving device of the corresponding multicast group under its control. Therefore, (8) L3SW # 8 sends a Join message when the Prune message is received in order to have L3SW # 1, which is an RP, continue to deliver the multicast packet. As a result, the RP L3SW # 1 will receive the Join message within 3 seconds after receiving the Prune message, and will continue to deliver the multicast packet.
At this time, the Join message sent from L3SW # 8 will reach L3SW # 1 to # 7 due to the flooding of each L2SW.
In the processing shown in FIGS. 1 to 3, Join messages, Prune messages, and multicast packets also flow to L3SW # 2 to # 4, # 6, and # 7, which are not related to the distribution of multicast packets. In the first embodiment, the L2SW operates so as not to send unnecessary packets to a device that is not involved in the delivery of multicast packets.
<First Embodiment> FIGS. 4, 5, 6, 7, and 8 are diagrams showing an example of a processing flow related to the distribution of multicast packets in the multicast network according to the first embodiment. The network configuration shown in FIGS. 4 to 8 is similar to the network configuration shown in FIGS. 1 to 3.
FIG. 4 is a diagram showing an example of a processing flow related to participation in a multicast group and distribution of multicast packets according to the first embodiment. (1) The receiving device under L3SW # 5 sends an IGMP report to join the multicast group.
(2) When L3SW # 5 receives an IGMP report from a subordinate receiving device, it registers the receiving device in the delivery destination of the corresponding multicast packet and sends a Join message. (3) L2SW # 5, which has received the Join message, sends a multicast reception request message to the root SW, and then forwards the Join message. The multicast reception request message is a message for requesting the root SW to forward a multicast packet.
In the first embodiment, each L2SW forwards the Join message and the Prune message from the port to which the RP is connected, and does not forward the Join message and the Prune message from the other ports. This suppresses the transfer of Join and Prune messages to devices that are not involved in the transfer of multicast packets.
In Fig. 4, the Join message is also flowing from L2SW # 1 to L2SW # 8, which are the root SWs. This is because the connection between L2SW is an optical line and is due to the characteristics of the optical line. When the connection between L2SWs is a metal line, in the first embodiment, the Join message is not sent to the root SWs L2SW # 1 to L2SW # 8.
Regarding the multicast reception request message, L2SW # 5, which receives the Join message from L3SW # 5, may create and transmit the multicast reception request message, and transfer the other L2SW without creating it. Alternatively, in addition to L2SW # 5, each of L2SW # 2 to # 4 may create and transmit a multicast reception request message when relaying the Join message. In the first embodiment, the L2SW that receives the Join message from the L3SW creates and transmits the multicast reception request message, and the other L2SWs transfer the multicast reception request message (the former).
Further, the multicast reception request message may be transmitted by unicast with the route SW as the destination, or may be transmitted by multicast using a multicast packet such as BPDU (Bridge Protocol Data Unit), for example. When the multicast reception request message is delivered by multicast, register in advance to forward the packet of the IP address used for the multicast reception request message from the port to which another L2SW is connected, and from the other ports. You may not transfer it. In the first embodiment, the multicast reception request message is transmitted by unicast with the route SW as the destination.
FIG. 5 is a diagram showing an example of the processing flow after receiving the multicast reception request message of the route SW L2SW # 1. (4) L2SW # 1, which is the root SW, maintains the connection relationship between L2SWs in TRILL's multicast distribution tree, and identifies the route of the Join message based on the received multicast reception request message. L2SW # 1, which is the root SW, creates and sends a multicast reception setting message that specifies the forwarding port and discard port of the multicast packet of the corresponding multicast group to each L2SW in the multicast distribution tree.
The port specified as the forwarding port by the multicast reception setting message is used for forwarding the multicast packet of the corresponding multicast group. For the forwarding port, for example, the port that received the Join message for the corresponding multicast group of each L2SW on the route of the Join message is specified.
Multicast packets of the corresponding multicast group are not forwarded from the port specified as the discard port by the multicast reception setting message. As the discard port, a port outside the path of the Join message of each L2SW is specified.
The multicast reception setting message may be transmitted unicast to each L2SW or may be transmitted as a multicast packet. When the multicast reception setting message is delivered by multicast, register the MAC address used for the multicast reception setting message to be forwarded from the port to which another L2SW is connected in advance, and do not forward it from other ports. It may be. When the multicast reception setting message is delivered by multicast, the information of all L2SWs in the multicast delivery tree may be included. Further, the multicast reception setting message may be unicast when the multicast reception request message is unicast, and may be multicast when the multicast reception request message is multicast. In the first embodiment, the multicast reception setting message is transmitted by unicast.
(5) When the transmitting device sends a multicast packet, L3SW # 1 sends the multicast packet according to the multicast distribution tree of the corresponding multicast group. Multicast packets transmitted from L3SW # 1 are forwarded by each L2SW from the forwarding port of the corresponding multicast group, and are not forwarded from other ports. This makes it possible to suppress flooding of multicast packets to undesired devices.
In addition, the multicast packet will be forwarded on the route opposite to the route of the Join message. That is, in the first embodiment, the route SW that grasps the whole picture of TRILL's multicast distribution tree is made to specify the route of the Join message by using the multicast reception request message. In addition, the multicast reception setting message notifies each L2SW of the route in the direction opposite to the route of the Join message, and causes each L2SW to forward the multicast packet by the route in the direction opposite to the Join message. Thereby, in the first embodiment, the flooding of the multicast packet is suppressed.
FIG. 6 is a diagram showing an example of a processing flow when a receiving device under L3SW # 8 newly joins a multicast group. (6) An IGMP report is sent from the receiving device under L3SW # 8 that newly joins the multicast group.
(7) Since the Join message and the multicast packet of the corresponding multicast group are not delivered to L3SW # 8, L3SW # 8 is not in a state where it can receive the multicast packet of the corresponding multicast group. Therefore, when L3SW # 8 receives the IGMP report, it registers the new receiving device as the delivery destination of the multicast packet and sends a Join message to request the forwarding of the multicast packet to its own device.
(8) When the L2SW # 8 receives the Join message transmitted from the L3SW # 8, the L2SW # 8 sends the multicast reception request message to the root SW L2SW # 1. After that, L2SW # 8 forwards the Join message from the port to which the RP is connected. The Join message is delivered to the RP L3SW # 1 via L2SW # 1.
(9) When L2SW # 1 receives the multicast reception request message from L2SW # 8, since L2SW # 1 is the root SW, it sends a multicast reception setting message that specifies the forwarding port and the discard port. By receiving this multicast reception setting message, L2SW # 8 will forward the multicast packet to L3SW # 8.
FIG. 7 is a diagram showing an example of the processing flow when the receiving device under L3SW # 5 leaves the multicast group. (10) The receiving device under L3SW # 5 transmits an IGMP leave request for withdrawal from the multicast group.
(11) L3SW # 5 sends a Prune message when it receives an IGMP leave. The Prune message, like the Join message, is forwarded from the port to which the RP is connected in the first embodiment. In the network shown in FIG. 7, since the L2SWs are connected by an optical line, the Prune message also flows to the L2SWs # 6 to # 8.
When a Prune message is received, the RP L3SW # 1 stops delivering the multicast packet if it does not receive the Join message within 3 seconds. On the other hand, a receiving device that continuously desires a multicast packet is connected to L3SW # 8. Therefore, it is preferable that L3SW # 8 sends a Join message in order to have L3SW # 1, which is an RP, continue to deliver the multicast packet.
However, although the Prune message reaches L2SW # 8, it is blocked by L2SW # 8 from being forwarded to L3SW # 8 that connects to a port that is not the port that connects the RP. Therefore, L3SW # 8 cannot know that the Prune message was sent from another L3SW. That is, as shown in FIG. 3, L3SW # 8 cannot send a Join message when it receives a Prune message from another L3SW.
(12) In the first embodiment, when the L2SW # 8 receives the Prune message, the L2SW # 8 creates and sends a Join message instead of the L3SW # 8. This allows the RP L3SW # 1 to continue delivering multicast packets.
FIG. 8 is a diagram showing an example of L2SW processing related to the operation of the multicast network. The network shown in FIG. 8 is the network after the processing of FIG. 7 is completed.
L3SW # 8, which connects the receiving device under its control, transmits a Join message at a predetermined cycle (for example, 60 seconds), and L2SW # 8 transmits a multicast reception request message accordingly. That is, L2SW # 8 transmits a multicast reception request message at the same cycle as the Join message.
L2SW # 1, which is the root SW, monitors the reception of multicast reception request messages for each port, and if it does not receive the multicast reception request message for a specified time, multicast reception with all ports set as discard ports from the corresponding port. Send a configuration message. The multicast reception setting message at this time is transmitted to the L2SW located downstream of the port that does not receive the multicast reception request message for a predetermined time. The predetermined time is, for example, 210 seconds. This stops the forwarding of multicast packets to the L2SW # 5 side.
As described above, in the first embodiment, the L2SW uses the port that received the Join message as the forwarding port of the corresponding multicast group, and does not forward the multicast packet of the corresponding multicast group from other than the forwarding port. In addition, Join and Prune messages are not forwarded from ports other than the port to which the RP of L2SW is connected. This makes it possible to suppress flooding of multicast packets by L2SW.
<L2SW Configuration> FIG. 9 is a diagram showing an example of the hardware configuration of L2SW 1. The L2SW 1 includes a SW unit 102 that relays packets between a plurality of interface (IF) units 103, an IF unit 104, an IF unit 103, and an IF unit 104, and a control unit 101 that corresponds to the control plane of the L2SW 1.
The IF unit 103 is, for example, an interface for connecting a metal line. The IF unit 103 performs baseband processing on the electric signal input from the metal line, converts it into a predetermined data format, and outputs it to the SW unit 102. The IF unit 103 performs the reverse processing on the data input from the SW unit 102, converts it into an electric signal, and outputs it to the metal line.
The IF unit 104 is, for example, an interface for connecting an optical line. The IF unit 104 converts an optical signal input from an optical line into an electric signal, converts the electric signal into a predetermined data format, and outputs the electric signal to the SW unit 102. The IF unit 104 performs the reverse processing on the data input from the SW unit 102, converts it into an electric signal, further converts it into an optical signal, and outputs it to an optical line. Although the IF unit 103 and the IF unit 104 are shown one by one in FIG. 9, a plurality of each may be provided.
The SW section 102 is a circuit such as an FPGA (field-programmable gate array) that relays packets between the IF section 103 and the IF section 104. Further, the SW unit 102 includes a memory 102B. The memory 102B is, for example, RAM (Random Access Memory). For example, an access list is stored in the memory 102B, and the SW unit 102 forwards a packet matching the access list to the control unit 101. The access list stores, for example, an IP address or a MAC address used in a Join message, a Prune message, a multicast reception request message, a multicast reception setting message, or the like.
The control unit 101 includes a CPU (Central Processing Unit) 101A and a memory 101B. The memory 101B includes RAM and ROM (Read Only Memory). For example, an OS (Operating System), a multicast forwarding program, and the like are stored in the memory 101B. The CPU 101A performs the processing described in FIGS. 4 to 8, for example, by executing the multicast forwarding program.
The hardware configuration of L2SW shown in FIG. 9 is an example, and can be changed as appropriate. For example, the L2SW does not have to include either the IF unit 103 for connecting the metal line or the IF unit 104 for connecting the optical line.
FIG. 10 is a diagram showing an example of the functional configuration of L2SW 1. L2SW 1 includes packet receiving unit 11, packet determination unit 12, first transfer port determination unit 13, packet transmission unit 14, second transfer port determination unit 15, table management unit 16, message creation unit 17, and multicast transfer determination table 21. , Tree topology information 22, VLAN management table 23, RP information 24.
The packet reception unit 11, the packet determination unit 12, the first transfer port determination unit 13, the packet transmission unit 14, the multicast transfer determination table 21, and the VLAN management table 23 have functional configurations corresponding to the SW unit 102. The packet receiving unit 11 and the packet transmitting unit 14 are interfaces with the IF units 103 and 104.
The packet determination unit 12 determines the packet as a first transfer port determination unit 13 and a second transfer port determination unit.<u style="single">15</u>Sort to. For example, the packet determination unit 12 uses the access list stored in the memory 102B in the SW unit 102, and transfers a packet whose destination IP or MAC address matches the access list to the second transfer port determination unit 15. In the access list, for example, the multicast IP address used for Join and Prune messages, its own IP or MAC address is registered. Packets that do not match the access list are forwarded to the first forwarding port determination unit 13.
Hereinafter, in the first embodiment, the Join message, the Prune message, the multicast reception request message, and the multicast reception setting message are output to the second transfer port determination unit 15. Further, the multicast packet of the predetermined multicast group is output to the first forwarding port determination unit 13. In the first embodiment, the multicast reception request message and the multicast reception setting message addressed to the other L2SW 1 are output to the first transfer port determination unit 13 as unicast packets.
The first transfer port determination unit 13 determines the transfer port of the packet input from the packet determination unit 12, and outputs the transfer port to the packet transmission unit 14. For example, the first forwarding port determination unit 13 determines the forwarding port of the unicast packet according to the unicast routing table (not shown). For example, the first forwarding port determination unit 13 determines the forwarding port of the multicast packet according to the multicast forwarding determination table 21 described later. The first transfer port determination unit 13 is an example of the transfer unit.
The multicast forwarding determination table 21 and the VLAN management table 23 are stored in the memory 102B of the SW unit 102. The multicast forwarding determination table 21 is a table that holds the forwarding port of the multicast group. Details of the multicast forwarding determination table 21 will be described later. The VLAN management table 23 is, for example, a table in which the VLAN existing in L2SW 1 and the information of the port belonging to each VLAN are stored.
The second transfer port determination unit 15, the table management unit 16, and the message creation unit 17 are functional configurations realized by the CPU 101A of the control unit 101 executing the multicast transfer program stored in the memory 101B. The tree topology information 22 and the RP information 24 are stored in the memory 101B of the control unit 101.
Tree topology information 22 is information about TRILL's multicast distribution tree. For example, the MAC address of the root SW of TRILL's multicast distribution tree is held in the tree topology information. Tree topology information 22 is acquired by exchanging TRILL messages with other L2SW 1.
When L2SW 1 is the root SW, the tree topology information 22 stores the connection relationships of all L2SW 1s participating in TRILL's multicast distribution tree. More specifically, the root SW tree topology information 22 stores the IP addresses and MAC addresses of all L2SW 1, port numbers, information on the connection devices of each port, and the like. The tree topology information is an example of the information stored in the "third storage unit".
The RP information 24 is information on the IP address of the L3SW, which is the RP of each multicast group, and the port to which the L3SW, which is the RP, is connected. The IP address of the RP is obtained from, for example, a Join message. Further, the port to which the RP is connected is acquired as, for example, the receiving port of the PIM Hello message in which the IP address of the L3SW which is the RP is the source IP address. A PIM Hello message is a message sent at a predetermined cycle (eg, 30 seconds) by all PIM-enabled L3SWs. Hereinafter, the port to which the RP is connected will be referred to as an RP connection port. The RP information 24 is an example of information stored in the second storage unit.
A packet addressed to the Join message, Prune message, L2SW 1's own IP address or MAC address is input from the packet determination unit 12 to the second transfer port determination unit 15. In the first embodiment, the multicast reception request message and the multicast reception setting message are transmitted by unicast. Therefore, in the first embodiment, the packet addressed to the IP address or MAC address of L2SW 1 itself is a multicast reception request message or a multicast reception setting message.
When the Join and Prune messages are input, the second transfer port determination unit 15 determines the RP connection port as the transfer port for the Join and Prune messages, and outputs the RP connection port to the packet transmission unit 14. When the Join message is input from the L3SW, the second forwarding port determination unit 15 instructs the message creation unit 17 to create a multicast reception request message. Whether or not the Join message is input from the L3SW can be determined by determining whether or not the receiving port of the Join message is the port to which the L3SW is connected.
When a Prune message is input, the second transfer port determination unit 15 determines whether or not a predetermined condition is satisfied, and if the predetermined condition is satisfied, creates a Join message on behalf of the user. Instruct the message creation unit 17. The predetermined condition is that, for example, there is a port registered as a forwarding port of the corresponding multicast address in the multicast forwarding determination table 21 other than the receiving port of the Prune message.
When a multicast reception request message addressed to L2SW 1 itself is input, the second forwarding port determination unit 15 instructs the message creation unit 17 to create a multicast reception setting message. When a multicast reception setting message addressed to L2SW 1 itself is input, the second forwarding port determination unit 15 instructs the table management unit 16 to update the multicast forwarding determination table 21 based on the multicast reception setting message. The second transfer port determination unit 15 is an example of the determination unit.
The table management unit 16 updates the multicast transfer determination table 21 according to the instruction of the second transfer port determination unit 15. In addition, the table management unit 16 monitors the reception of the multicast reception request message at each forwarding port. If there is a forwarding port that does not receive the multicast reception request message for a predetermined time, the table management unit 16 instructs the message creation unit 17 to create a multicast reception setting message in which all ports are designated as discard ports. The predetermined time is, for example, 210 seconds. The table management unit 16 is an example of the management unit.
The message creation unit 17 creates a multicast reception request message, a multicast reception setting message, and a join message according to the instruction of the second transfer port determination unit 15 or the table management unit 16, and outputs the multicast reception request message, the multicast reception setting message, and the join message to the packet transmission unit 14. The message creation unit 17 is an example of a notification unit.
When creating a multicast reception setting message, the message creation unit 17 identifies the route of the Join message of the corresponding multicast group based on the multicast reception request message and the tree topology information 22. The message creation unit 17 creates a multicast reception setting message for each L2SW 1 by setting the port on the route as the forwarding port and the port outside the route as the discard port. When creating a multicast reception setting message, since L2SW 1 is the root SW, the tree topology information 22 holds information on all L2SW 1s of TRILL's multicast distribution tree.
FIG. 11 is an example of the multicast transfer determination table 21. The multicast forwarding determination table 21 stores the correspondence between the multicast address, the forwarding port, and the aging timer as an entry. The forwarding port of the multicast forwarding judgment table 21 is the port specified as the forwarding port of the corresponding multicast address by the multicast reception setting message.
An entry in the multicast forwarding determination table 21 is created for each combination of a multicast address and a forwarding port. Therefore, in FIG. 11, for the multicast address "231.0.0.10", there are two entries, an entry whose forwarding port is "port 1" and an entry whose forwarding port is "port 5".
The entries in the multicast forwarding determination table 21 are registered according to the contents of the multicast reception setting message when the multicast reception setting message is received. When the forwarding port of the multicast forwarding judgment table 21 is specified as the discard port by the multicast reception setting message, "discard" is stored in the "forwarding port" of the corresponding entry.
The aging timer of the multicast forwarding determination table 21 is set to the initial value by the table management unit 16 every time a multicast reception request message arrives at the forwarding port of the corresponding entry. The aging timer is a countdown timer. When L2SW 1 is the root SW, when the aging timer reaches 0, a multicast reception setting message that specifies all ports as discard ports is sent from the forwarding port of the corresponding entry to the multicast group of the corresponding entry. The initial value of the aging timer is, for example, 210 seconds. The multicast transfer determination table 21 is an example of the first storage unit.
<Message structure> FIG. 12 is a diagram showing an example of information included in the multicast reception request message. For the multicast reception request message, for example, a BPDU may be used, or a uniquely defined packet may be used. Multicast receive request messages include, for example, receive request nodes, multicast addresses, receive port numbers, and VLANs.
The "reception request node" in the multicast reception request message is the address of L2SW 1 that received the join message. In the first embodiment, since it is assumed that the L2SW that has received the Join message from the L3SW creates and sends the multicast reception request message, the "reception request node" is the source of the multicast reception request message. The IP address or MAC address of L2SW 1 itself is stored.
The "multicast address" in the multicast reception request message is the multicast address of the multicast group for which L2SW 1, which is the source of the multicast reception request message, requests the forwarding of the multicast packet. In the "multicast address" in the multicast reception request message, the multicast address of the multicast group included in the join message that triggers the creation of the multicast reception request message is stored.
The number of the port that received the Join message is stored in the "received port number" in the multicast reception request message. The "VLAN" in the multicast reception request message stores the VLAN information requesting the forwarding of the multicast packet of the corresponding multicast group. In the "VLAN", for example, the VLAN ID set in the receiving port of the Join message is stored.
FIG. 13 is a diagram showing an example of information included in the multicast reception setting message. For the multicast reception setting message, for example, a BPDU may be used, or a uniquely defined packet may be used. The multicast receive configuration message includes, for example, a multicast address, a VLAN, a forwarding port number, and a discard port number.
In the "multicast address" and "VLAN" of the multicast reception setting message, the values of the "multicast address" and "VLAN" in the multicast reception request message that trigger the creation of the multicast reception setting message are stored.
In the "forwarding port number" and "discarding port number" of the multicast reception setting message, the forwarding port and discarding port numbers of the multicast packet of the corresponding multicast group are stored, respectively. The forwarding port and the discard port are determined by the message creation unit 17.
The multicast receive configuration message is created when L2SW 1 is the root SW. When L2SW 1 is the root SW, the tree topology information 22 stores the topology of the entire TRILL multicast distribution tree. Therefore, the root SW L2SW 1 can identify the route of the Join message in TRILL's multicast distribution tree if the L2SW that received the Join message from the L3SW can be identified by using the tree topology information 22. Since the multicast packet usually flows in one direction from the transmitting device side to the receiving device side, the port on the downstream side (receiving device side) on the specified route is determined as the forwarding port. The port on the downstream side (receiver side) outside the specified route is determined as the discard port.
In the first embodiment, it is assumed that the multicast reception setting message is transmitted by unicast, but the present invention is not limited to this. The multicast reception setting message may be transmitted by multicast. When the multicast reception setting message is transmitted by multicast, the identification information of the target L2SW 1 may be included in the multicast reception setting message in addition to the information shown in FIG. In addition, when the multicast reception setting message is transmitted by multicast, the information of all L2SW 1s in TRILL's multicast distribution tree may be included.
<Specific example> FIG. 14 is a diagram showing a network configuration assumed in the specific example and a physical connection relationship between L2SWs in the network. The root SW of TRILL's multicast distribution tree is L2SW # 1. The RP of the target multicast group is L3SW connected to L2SW # 1. The transmitter exists on the port 1 side of L2SW # 1. The receiving device exists on the port 1 side of L2SW # 5.
FIG. 15A is a diagram showing an example of a multicast reception request message when a request to join a multicast group (IGMP report) is transmitted from the receiving device in the network shown in FIG. Figure 15A shows the logical connection between L2SWs in TRILL's multicast distribution tree for the network shown in Figure 14.
In FIG. 15A, it is assumed that port 1 of L2SW # 5 in which the receiving device exists belongs to VLAN100. It is assumed that the transmitting device uses the multicast IP address 230.0.0.1. Further, in the network shown in FIG. 15A, it is assumed that there is no receiving device that participates in the multicast group using the multicast IP address 230.0.0.1.
When the receiving device sends an IGMP report for a multicast group using the multicast IP address 230.0.0.1, L2SW # 5 receives a Join message from L3SW on port 1. Since L2SW # 5 has received the Join message, it creates and sends a multicast reception request message to the root SW.
The contents of the created multicast reception request message are as follows. -Receive request node: L2SW # 5-Multicast address: 230.0.0.1-Receive port: Port 1-VLAN: 100
FIG. 15B is a diagram showing an example of a multicast reception setting message for the multicast reception request message shown in FIG. 15A. The network shown in Figure 15B is the same as in Figure 15A.
When the root SW, L2SW # 1, receives the multicast reception request message, it identifies the route of the Join message. L2SW # 1, which is the root SW, receives the multicast reception request message shown in FIG. 15A, and acquires that the reception port of the Join message is port 1 of L2SW # 5. From the receiving port of the Join message, the multicast address, and the topology of the entire multicast distribution tree of the tree topology information 22, L2SW # 1, which is the root SW, acquires the route of the Join message.
In the case of the example shown in Figure 15B, the route of the join message is port 1 of L2SW # 5 port 3 of L2SW # 4 port 3 of L2SW # 3 port 3 of L2SW # 2 port of L2SW # 1. 2 RP L3SW. The route is shown in the order of the receiving port of the Join message of each L2SW. L2SW # 1, which is the root SW, uses a port on the route as a forwarding port and a port outside the route as a discard port. Therefore, the root SW, L2SW # 1, creates the following multicast reception setting message.
The following multicast reception setting messages are sent to L2SW # 2 to # 4. -Multicast address: 230.0.0.1-VLAN: 100-Forward port number: Port 3-Discard port: Port 2
The following multicast reception setting message is sent to L2SW # 5. -Multicast address: 230.0.0.1-VLAN: 100-Forward port number: Port 1-Discard port: Port 3
The following multicast reception setting messages are sent to L2SW # 6 to # 8. -Multicast address: 230.0.0.1-VLAN: 100-Transfer port number: None-Discard port: Ports 2 and 3 Note that the multicast transfer judgment table 21 of L2SW # 6 to # 8 that received the above multicast reception setting message shows An entry is created with the multicast address "230.0.0.1" and the forwarding port "discard".
Although not shown in FIG. 15B, the root SW L2SW # 1 also transmits a multicast reception setting message to itself by using, for example, a loopback address. The contents of the reception setting message sent to the root SW L2SW # 1 are as follows. -Multicast address: 230.0.0.1-VLAN: 100-Forward port number: Port 2-Discard port: Port 3
When the L2SWs are connected by a metal line, if a packet is sent from one L2SW to the optical line as in the case of being connected by an optical line, it will not reach the other L2SWs. Further, in the above multicast reception setting message, port 3 of L2SW # 1 is a discard port, and a multicast packet having a multicast address of 230.0.0.1 does not flow from port 3 of L2SW # 1. Therefore, L2SW # 1 does not have to send the multicast reception setting message to L2SW # 6 to # 8 which are not on the route of the Join message.
<Processing Flow> FIGS. 16A, 16B, 16C, and 16D are examples of a flowchart of processing of the control unit 101 when a packet is input to the control unit 101. The processing shown in FIGS. 16A to 16D is started when a packet is input to the control unit 101. In the first embodiment, the SW unit 102 inputs a Join message, a Prune message, a multicast reception request message addressed to the own device, and a multicast reception setting message addressed to the own device to the control unit 101.
The processing of FIGS. 16A to 16D is performed by executing the multicast transfer program stored in the memory 101B by the CPU 101A of the control unit 101. The main body of the processing shown in FIGS. 16A to 16D is the CPU 101A of the control unit 101, but in the following description, the second transfer port determination unit 15, the table management unit 16, and the message creation, which are the functional configurations of the control unit 101. Part 17 will be mainly explained.
In OP1, the second transfer port determination unit 15 determines whether or not the packet input from the packet determination unit 12 is a Join message. This determination is, for example, that the destination IP address (224.0.0.13), the value of the type field is "3" indicating a Join and Prune message, and the field (Encoded-) that stores the address of the device requesting participation. It is determined by the fact that the address is stored in the Joined Source Address field).
If the input packet is a Join message (OP1: YES), the process proceeds to OP11 in FIG. 16B. If the input packet is not a Join message (OP1: NO), processing proceeds to OP2.
In OP2, the second transfer port determination unit 15 determines whether or not the packet input from the packet determination unit 12 is a Prune message. This determination is, for example, that the destination IP address (224.0.0.13), the value of the type field is "3" indicating a Join and Prune message, and the field (Encoded-) that stores the address of the device requesting withdrawal. It is determined by the fact that the address is stored in the Pruned Source Address field).
If the input packet is a Prune message (OP2: YES), processing proceeds to OP21 in Figure 16C. If the input packet is not a Prune message (OP2: NO), processing proceeds to OP3.
In OP3, the second forwarding port determination unit 15 determines whether or not the input packet is a multicast reception request message addressed to its own device. In the first embodiment, the multicast reception request message is unicastly transmitted to the root SW. Therefore, if the destination IP address of the multicast reception request message is the own device, it is determined that the packet is addressed to the own device. Further, whether or not the message is a multicast reception request message can be determined by whether or not the packet format or the like complies with the multicast reception request message.
If the input packet is a multicast reception request message addressed to the own device (OP3: YES), the process proceeds to OP31 in FIG. 16D. If the input packet is not a multicast reception request message (OP3: NO), processing proceeds to OP4.
In OP4, the second forwarding port determination unit 15 determines whether or not the input packet is a multicast reception setting message addressed to the own device. In the first embodiment, the multicast reception setting message is transmitted by unicast to each L2SW. Therefore, if the destination IP address of the multicast reception setting message is the own device, it is determined that the packet is addressed to the own device. Further, whether or not the message is a multicast reception setting message can be determined by whether or not the packet format or the like complies with the multicast reception setting message.
If the input packet is a multicast reception setting message addressed to the own device (OP4: YES), the process proceeds to OP5. Input packet receives multicast<u style="single">Setting</u>If it is not a message (OP4: NO), the process shown in Figure 16A ends.
In OP5, the table management unit 16 updates the multicast forwarding determination table 21 based on the input multicast reception setting message. After that, the process shown in FIG. 16A ends.
FIG. 16B is an example of a flowchart of processing when a Join message is input to the control unit 101. In OP11, the second transfer port determination unit 15 determines whether or not the Join message has been received at the port to which the L3SW is connected. If the Join message is received on the port to which the L3SW is connected (OP11: YES), the process proceeds to OP12. If the Join message is received on a port other than the port to which the L3SW is connected (OP11: NO), the process proceeds to OP14.
In OP12, the second forwarding port determination unit 15 instructs the message creation unit 17 to create a multicast reception request message, and the message creation unit 17 creates a multicast reception request message. Then the process proceeds to OP13.
In OP13, the message creation unit 17 outputs the created multicast reception request message to the SW unit 102. Since the multicast reception request message is unicastly transmitted to the root SW, the SW unit 102 determines the forwarding port and sends the message. Then the process proceeds to OP14.
In OP14, the second transfer port determination unit 15 determines the transfer port of the Join message as the RP connection port and outputs it to the SW unit 102. Join messages are forwarded from the RP connection port. After that, the process shown in FIG. 16B ends.
In the first embodiment, it is assumed that the L2SW that has received the Join message from the L3SW creates and transmits a multicast reception request message. When each L2SW that relays the Join message also creates and sends a multicast reception request message, OP11 is not judged.
FIG. 16C is an example of a flowchart of processing when a Prune message is input to the control unit 101. In OP21, the second transfer port determination unit 15 determines the transfer port of the Prune message as the RP connection port and outputs it to the SW unit 102. Prune messages are forwarded from the RP connection port. Then the process proceeds to OP22.
In OP22, the second forwarding port determination unit 15 determines whether or not the multicast forwarding determination table 21 has a forwarding port of the corresponding multicast group other than the receiving port of the Prune message. If the multicast forwarding judgment table 21 has a forwarding port of the multicast group other than the receiving port of the Prune message (OP22: YES), the process proceeds to OP23. If there is no forwarding port for the multicast group other than the receiving port for the Prune message in the multicast forwarding judgment table 21 (OP22: NO), the process shown in FIG. 16C ends.
In OP23, the second transfer port determination unit 15 instructs the message creation unit 17 to create a Join message. The message creation unit 17 creates a Join message for the multicast group indicated by the Prune message. The created Join message is created, for example, with the same contents as the Join message received on the forwarding port other than the receiving port of the Prune message in the multicast forwarding determination table 21. Then the process proceeds to OP24.
In OP24, the message creation unit 17 determines the transfer port of the created Join message as the RP connection port and outputs it to the SW unit 102. The created Join message is forwarded from the RP connection port. After that, the process shown in FIG. 16C ends.
FIG. 16D is an example of a flowchart of processing when a multicast reception request message addressed to the own device is input to the control unit 101. In OP31, the second transfer port determination unit 15 determines whether or not the own device is the root SW.
If the local device is not the root SW (OP31: NO), in the first embodiment, the second forwarding port determination unit 15 discards the multicast reception request message addressed to the local device, and the process shown in FIG. 16D ends. .. In the first embodiment, since the multicast reception request message is unicasted to the route SW, the multicast reception request message is processed by the first forwarding port determination unit 13 without being input to the control unit 101. Because it is transferred.
When the multicast reception request message is transmitted by multicast, the multicast reception request message is input to the control unit 101, and if the local node is not the root SW, the process proceeds to OP34. In OP34, the second forwarding port determination unit 15 outputs the multicast reception request message to the SW unit 102, and the SW unit 102 transfers the multicast reception request message from the port on the upstream side of TRILL's multicast distribution tree. After that, the process shown in FIG. 16D ends.
If the own device is the root SW (OP31: YES), the process proceeds to OP32. In OP32, the second forwarding port determination unit 15 instructs the message creation unit 17 to create a multicast reception setting message. The message creation unit 17 identifies the route of the join message from the multicast reception request message and the tree topology information 22, identifies the forwarding port and the discard port of each L2SW 1, and sets the multicast reception for each L2SW 1. Compose a message. Then the process proceeds to OP33.
In OP33, the message creation unit 17 receives the created multicast.<u style="single">Setting</u>Output the message to SW section 102. Multicast reception<u style="single">Setting</u>The message is forwarded by the SW unit 102 from the port on the downstream side of TRILL's multicast distribution tree.
The creation of the multicast reception setting message in OP32 and the transmission of the multicast reception setting message in OP33 are performed for the number of L2SW 1 in the multicast distribution tree of TRILL, including the own device which is the root SW. Then the process proceeds to OP35.
In OP36, the table management unit 16 sets the receiving port of the input multicast reception request message and the aging timer of the multicast forwarding determination table 21 corresponding to the corresponding multicast group to the initial values. After that, the process shown in FIG. 16D ends.
The execution order of some of the processes shown in FIGS. 16A to 16D may be changed. For example, the execution order of the determination processes of OP1 to OP4 in FIG. 16A may be any. For example, the transfer process of the Join message of OP14 in FIG. 16B may be executed before the process of OP11.
FIG. 17 is an example of a flowchart of processing of the SW unit 102 when a multicast packet is received. The process shown in FIG. 17 is started when a multicast packet is input to the SW unit 102. The main body of the processing shown in FIG. 17 is the SW unit 102, but in the following description, the first transfer port determination unit 13, which is the functional configuration of the SW unit 102, will be mainly described.
In OP41, the first forwarding port determination unit 13 acquires the same VLAN information as the VLAN to which the multicast packet belongs from the VLAN management table 23. When the multicast packet is received from the L3SW, the VLAN to which the multicast packet belongs is acquired from, for example, the VLAN to which the receiving port belongs. When the multicast packet is received from another L2SW 1, the VLAN to which the multicast packet belongs is acquired from, for example, the VLAN tag attached to the multicast packet. Then the process proceeds to OP42.
In OP42, the first forwarding port determination unit 13 determines whether or not there is a port other than the receiving port that belongs to the same VLAN as the multicast packet. If there is no port other than the receiving port that belongs to the same VLAN as the multicast packet (OP42: NO), the process proceeds to OP46. In OP46, the first forwarding port determination unit 13 discards the multicast packet. After that, the process shown in FIG. 17 ends.
If there is a port other than the receiving port that belongs to the same VLAN as the multicast packet (OP42: YES), the process proceeds to OP43. In OP43, the first forwarding port determination unit 13 acquires the entry corresponding to the multicast address of the corresponding multicast packet from the multicast forwarding determination table 21. Then the process proceeds to OP44.
In OP44, the first forwarding port determination unit 13 determines whether or not the forwarding port is registered in the entry of the acquired multicast forwarding determination table 21. If the forwarding port is registered in the acquired entry (OP44: YES), the process proceeds to OP45. In OP45, the first forwarding port determination unit 13 determines the forwarding port of the multicast packet as the forwarding port registered in the entry, and outputs the multicast packet to the port transmitting section 14. Multicast packets are forwarded from the forwarding port. After that, the process shown in FIG. 17 ends.
If "discard" is registered in the "forwarding port" of the acquired entry (OP44: NO), the process proceeds to OP46. In OP46, the first forwarding port determination unit 13 discards the multicast packet. After that, the process shown in FIG. 17 ends.
<Operation and effect of the first embodiment> In the first embodiment, the route of the Join message is specified by the root SW by using the multicast reception request message and the multicast reception setting message, and the reception port of the Join message of each L2SW 1 is used. Is specified as the forwarding port. Each L2SW 1 does not forward the multicast packet of the corresponding multicast group from other than the specified forwarding port. This makes it possible to suppress flooding of multicast packets by L2SW. By suppressing the flooding of multicast packets, it is possible to reduce the bandwidth pressure on the line.
Further, in the first embodiment, each L2SW 1 does not forward the Join message and the Prune message from a port other than the RP connection port. As a result, it is possible to suppress the flooding of Join messages and Prune messages by L2SW.
When L2SW 1 which is the root SW is connected to L3SW which is the RP, the Prune message reception process (FIG. 7, FIG. 16C, etc.) is performed instead of the configuration described in the first embodiment. It is also possible to configure L2SW 1 as follows. The root SW knows the whole picture of the multicast distribution tree, and can also grasp the L2SW 1 to which the L3SW requesting the forwarding of multicast packets is connected. Therefore, when the root SW receives the Prune message, it determines whether or not the L3SW requesting the forwarding of the multicast packet of the corresponding multicast group exists other than the L3SW that is the source of the Prune message.
If the L3SW requesting the forwarding of the multicast packet of the corresponding multicast group exists other than the L3SW that is the source of the Prune message, the root SW does not forward the Prune message to the L3SW that is the RP. As a result, the Prune message does not reach the L3SW, which is the RP, so that the L3SW, which is the RP, can continue to forward the multicast packet.
In the first embodiment, the route of the Join message is specified by using the multicast distribution tree by TRILL between L2SW 1, but the route is not limited to this. The technique described in the first embodiment can also be applied to the L2SW network using a protocol for logically constructing a tree structure between L2SWs.
<Second Embodiment> In the second embodiment, L2SW 1 specifies the route of the multicast packet for each of the multicast reception request message and the multicast reception setting message.
FIG. 18 is a diagram showing an example of a processing flow related to the distribution of multicast packets in the multicast network according to the second embodiment. The network configuration shown in FIG. 18 is similar to the network configuration shown in FIGS. 1 to 3.
(1) The receiving device under L3SW # 5 sends an IGMP report to join the multicast group.
(2) When L3SW # 5 receives an IGMP report from a subordinate receiving device, it registers the receiving device at the delivery destination of the corresponding multicast packet and sends a PIM Join message. Each L2SW forwards the Join message and the Prune message to the RP connection port in the second embodiment as in the first embodiment, and does not forward the Join message and the Prune message from the other ports.
In the second embodiment, when each L2SW receives a Join message, the port receiving the Join message is set as the forwarding port of the corresponding multicast group. Since the Join message is delivered to the RP, the reverse direction of the route is the route of the multicast packet. Therefore, L2SW can identify the receiving port of the Join message as the forwarding port of the multicast packet.
(3) When a multicast packet is transmitted from the transmitting device, each L2SW forwards the multicast packet from the forwarding port of the corresponding multicast group, and does not forward the multicast packet from the other ports. In the second embodiment, the flooding of the multicast packet is suppressed as described above.
In the second embodiment, when the Prune message is received, the L2SW determines that the receiving port of the Prune message is the discard port. However, if there is a forwarding port other than the receiving port of the Prune message, the Join message is transmitted as a proxy to prevent the RP from stopping the forwarding of the multicast packet, as in the first embodiment.
In the second embodiment, the hardware configuration and the functional configuration of the L2SW 1 are the same as those in the first embodiment. Hereinafter, the points different from the first embodiment will be described.
In the second embodiment, the packet determination unit 12 inputs a Join message and a Prune message to the second transfer port determination unit 15. When the second transfer port determination unit 15 receives the Join message and the Prune message, the second transfer port determination unit 15 instructs the table management unit 16 to update the multicast transfer determination table 21. Further, the second forwarding port determination unit 15 instructs the message creation unit 17 to create a Join message when there is a forwarding port of the corresponding multicast group other than the receiving port of the Prune message.
The table management unit 16 updates the multicast transfer determination table 21 according to the instruction of the second transfer port determination unit 15. Further, in the second embodiment, the table management unit 16 monitors the reception of the Join message at each forwarding port. When the Join message is received, the table management unit 16 sets the aging timer of the entry of the multicast forwarding determination table 21 corresponding to the Join message to the initial value.
When the aging timer becomes 0, the table management unit 16 sets "discard" in the "forwarding port" of the entry of the corresponding multicast forwarding determination table 21.
FIG. 19 is an example of a flowchart of processing of the control unit 101 when a packet is input to the control unit 101 in the second embodiment. The process shown in FIG. 19 is started when a packet is input to the control unit 101. In the second embodiment, a Join message and a Prune message are input to the control unit 101 by the SW unit 102.
The processing shown in FIG. 19 is performed by the CPU 101A of the control unit 101 executing the multicast transfer program stored in the memory 101B. The main body of the processing shown in FIG. 19 is the CPU 101A of the control unit 101, but in the following description, the second transfer port determination unit 15, the table management unit 16, and the message creation unit 17, which are the functional configurations of the control unit 101, are referred to. Explain as the subject.
In OP51, the second transfer port determination unit 15 determines whether or not the packet input from the packet determination unit 12 is a Join message. If the packet input from the packet determination unit 12 is a Join message (OP51: YES), the process proceeds to OP52.
OP52 and OP53 are processes when a Join message is input. In OP52, the second transfer port determination unit 15 instructs the table management unit 16 to update the multicast transfer determination table 21.
The table management unit 16 registers a new entry when the combination of the multicast address and the receiving port of the Join message is not registered in the multicast forwarding determination table 21. When the combination of the multicast address and the receiving port of the Join message is registered in the multicast forwarding judgment table 21, the aging timer of the corresponding entry is set to the initial value. Then the process proceeds to OP53.
In OP53, the second transfer port determination unit 15 determines the RP connection port as the transfer port of the Join message and outputs it to the packet transmission unit 14. Join messages are forwarded from the RP connection port. After that, the process shown in FIG. 19 ends.
If the packet input from the packet determination unit 12 is not a Join message (OP51: NO), the process proceeds to OP54. In OP54, the second transfer port determination unit 15 determines whether or not the packet input from the packet determination unit 12 is a Prune message. If the packet input from the packet determination unit 12 is a Prune message (OP54: YES), the process proceeds to OP55. If the packet input from the packet determination unit 12 is not a Prune message (OP54: NO), the process shown in FIG. 19 ends.
In OP55, the second transfer port determination unit 15 instructs the table management unit 16 to update the multicast transfer determination table 21. The table management unit 16 sets "discard" in the "forwarding port" of the entry of the multicast forwarding judgment table 21 that matches the combination of the multicast address and the receiving port of the Prune message.
After that, the process shown in FIG. 16C is executed. That is, the Prune message is forwarded from the RP connection port, and if there is a forwarding port other than the receiving port of the Prune message, the message creation unit 17 creates and sends a Join message. After that, the process shown in FIG. 19 ends.
The process when the multicast packet is received is the same as the process shown in FIG. 17 described in the first embodiment.
<Operation and effect of the second embodiment> In the second embodiment, each L2SW sets the receiving port of the Join message as the forwarding port of the corresponding multicast group, and does not forward the multicast packet from other than the forwarding port. As a result, flooding of multicast packets can be suppressed.
Further, in the second embodiment, since the multicast reception request message and the multicast reception setting message are not used, the number of packets used for suppressing the flooding of multicast can be reduced.
1 L2SW11 Packet reception unit 12 Packet judgment unit 13 1st transfer port judgment unit 14 Packet transmission unit 15 2nd transfer port judgment unit 16 Table management unit 17 Message creation unit 21 Multicast transfer judgment table 22 Tree topology information 23 VLAN management table 24 RP Information 101 Control 101A CPU101B Memory 102 SW 103 IF 104 IF
23 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23
Every citation, both waysCites: the store holds 5 of 6
| Document | Relation | Office |
|---|---|---|
| WO2012130357A1 | Cites | World Intellectual Property Organization (WIPO) |
| JP2011124709A | Cites | Japan |
| JP2009246845A | Cites | Japan |
| JP2004179811A | Cites | Japan |
| JP2000349818A | Cites | Japan |
| Cisco IOS Software Configuration Guide,Release 12.2SX,Cisco,2013年11月17日 | Non-patent | – |
| IPv6 Topics IPv6を取り巻く技術・標準化動向(3)-IPマルチキャスト-」,BUSINESS COMINUCATION、第42巻,第1号,2005年1月1日,pp.155-157 | Non-patent | – |
4 members in 2 offices
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 2014069627 | Japan | A | |
| JP20140069627 | – | – | – |
Members4
| Document | Office | Kind | |
|---|---|---|---|
| US2015280932A1 | United States of America | A1 | |
| JP2015192391A | Japan | A | |
| US9948474B2 | United States of America | B2 | |
| JP6729845B2This record | Japan | B2 |
12 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Re-examination (zenchi) completed and case transferred to appeal boardAppealJAPANESE INTERMEDIATE CODE: A912A912 | A912 | |
| Transfer to examiner for re-examination before appeal (zenchi)AppealJAPANESE INTERMEDIATE CODE: A911A911 | A911 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Decision of refusalJAPANESE INTERMEDIATE CODE: A02A02 | A02 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 6729845
- Publication, DOCDB
- 6729845
- Publication, EPODOC
- JP6729845B
- Application
- 69627
- Application, DOCDB
- 2014069627
- Application, EPODOC
- JP20140069627
Titles2
- Japanese
- ネットワークシステム、パケット伝送装置、パケット伝送方法、及び情報処理プログラム
- English
- Network system, packet transmission device, packet transmission method, and information processing program
Classification
- CPC, 2
- H04L12/1886
- H04L45/16
- IPC, 2
- H04L45 16
- H04L12 761
