KR20040001206A - Method for setting up or releasing a multicast tree between two CE on MPLS VPN and method for providing multicasting service - Google Patents

Abstract

The present invention provides a multicasting service providing method in a MPLS VPN network including a plurality of CEs included in a subscriber network, a plurality of PEs belonging to a service provider network, and a plurality of service providers. A first step of receiving an MPLS VPN packet at a first PE; Determining, in the first PE, a reception path by determining whether header information of the received packet is IP information or label information; A third step of determining whether the received packet is for multicast or unicast using the IP information or label information determined in the second step in the first PE; In the first PE, if the received packet is for multicast, multicasting VRF storing information on whether a source of the received packet and a multicasting tree are set in a network device connected to the first PE. A fourth step of determining whether multiple or single destinations to which the packet is to be transmitted are determined by using; And a fifth step of, in the first PE, replicating the packet as many destinations as the number of destinations to be transmitted, and then transmitting the packet to a path of the corresponding destination. This can significantly reduce the traffic load on the provider's network.

Description

Method for setting up or releasing a multicast tree between two CE on MPLS VPN and method for providing multicasting service}

The present invention relates to a Multiprotocol Label Switching Virtual Private Network (MPLS VPN). In particular, the present invention provides multicasting in an MPLS VPN that enables a multicasting service to be provided in a service provider network. It is about a method.

In general, multicasting (muticasting) means that one user transmits the same data of a certain size to a plurality of users having a certain size.

Such multicasting is commonly used in the Internet, PSTN networks, and LANs.

However, since the conventional MPLS VPN supports only unicasting, which allows the MPLS packet transmitted from the subscriber's terminal device to be transmitted to a single destination, each packet generated by the subscriber terminal device to the multiple destinations is generated for multicasting. It uses multiple unicasting methods to send to multiple destinations later.

Accordingly, the conventional MPLS VPN network using the multiple unicasting scheme has a problem in that a traffic load increases when a multicasting service is provided, and delays packet delivery.

Disclosure of Invention The present invention aims to solve the above-mentioned conventional problem, and to provide a multicasting method in an MPLS VPN which can reduce the load of traffic.

1 is a structural diagram of an MPLS VPN network according to an embodiment of the present invention.

2 is a flow chart illustrating a process of establishing and canceling a multicast tree according to an embodiment of the present invention.

3 is a flowchart illustrating a multicasting providing method in an MPLS VPN according to an embodiment of the present invention.

According to an aspect of the present invention, there is provided a plurality of CEs included in a subscriber network, a plurality of PEs belonging to a service provider network, and a plurality of service providers in an MPLS VPN network. A method of providing a casting service, comprising: a first step of receiving an MPLS VPN packet at a first PE of one of the plurality of PEs; Determining, in the first PE, a reception path by determining whether header information of the received packet is IP information or label information; A third step of determining whether the received packet is for multicast or unicast using the IP information or label information determined in the second step in the first PE; In the first PE, if the received packet is for multicast, multicasting VRF storing information on whether a source of the received packet and a multicasting tree are set in a network device connected to the first PE. A fourth step of determining whether multiple or single destinations to which the packet is to be transmitted are determined by using; And in the first PE, if there are a plurality of destinations to be transmitted, replicating the packet by the number of destinations to be transmitted, and then transmitting the packet to a path of the corresponding destination.

In addition, the present invention according to another aspect for achieving the above technical problem, in the MPLS VPN network including a plurality of CE included in the subscriber network, a plurality of PE belonging to the service provider network and a plurality of service providers A method for establishing / cancelling a multicast tree, comprising: receiving, at a second PE connected to the second CE, a receiver registration / cancellation request requesting registration / cancellation from a first PE connected to the first CE to be a recipient of a multicast group; Receiving receiver request step; In the second PE, determining whether the signal received from the first PE is a signal for multicast, and registering / canceling the first CE as a receiver of a multicast group; A recipient registration response step of notifying registration / cancellation from the second PE to the first PE; A receiver request step of receiving, at the second PE, a sender registration / release request signal requesting to be registered / cancelled from the third CE as a sender of a multicast group; In the second PE, registering / canceling the third CE as a sender of a multicast group and setting up / terminating a multicast tree between the third CE and the first CE; And a sender registration response step of notifying the fact of registration / cancellation from the second PE to the third CE.

Hereinafter, a multicasting providing method in an MPLS VPN according to an embodiment of the present invention will be described with reference to the accompanying drawings.

1 is a structural diagram of an MPLS VPN network according to an embodiment of the present invention.

As shown in FIG. 1, an MPLS VPN according to an embodiment of the present invention is composed of subscriber networks N1, N2, N3, and N4, and a service provider network N5. , N4 is composed of subscriber stations (1, 2, 3, 4), visitor edges corresponding to the subscriber terminals (CE1, CE2, CE3, CE4), and the service provider network (N5) is each visitor edge. Each service edge (PE1, PE2, PE3) connected to (CE1, CE2, CE3, CE4), and service provider devices (P1, P2, P3) connected to each visitor edge (PE1, PE2, PE3, PE4). It includes.

The subscriber network and the service edge and service provider devices of the service provider network are generally much larger than those shown in FIG. 1, but only some of them are shown for purposes of explanation of the invention.

In this case, the CE connects to the subscriber station 1 and makes a header of the packet received from the subscriber station into an MPLS VPN packet including its address and the address of the destination host to which the packet is transmitted. send.

The PE stores a forwarding label table that records the label information of each PE, CE, and next hop on the LSP (Label Switching Path) to which it is connected, and the VPN Routing and Forwarding instance for multicasting. ) And VRF for unicasting.

Here, the unicasting VRF records a prefix address of a CE connected to its own PE and routing information between the CE and the PE (information about whether the direct connection is indirect through a PE having an IP). Therefore, the PE knows which path to send the received packet to using the unicasting VRF.

The multicasting VRF includes the information of the above-mentioned unicasting VRF. However, the unicasting VRF designates the packet transmission to one LSP, whereas the multicasting VRF designates the packet transmission to a plurality of LSPs. In other words, in the VRF for multicasting, LSPs to a plurality of CEs to transmit packets are set.

Therefore, the PE checks the IP destination address area of the received packet and, if the packet is for multicasting, transmits the packet to the LSP paths set by referring to the multicasting VRF, and each of the CEs at the end point of the transmitted LSP receives the same packet. If it is a packet for unicasting, the unicasting VRF is referred to, so that the packet is delivered to one destination CE included in the packet.

Herein, the connection setup between a packet sender and a packet receiver for a multicasting service is called a multicast tree setup, and the multicast tree setup is performed only when the packet sender and the packet receiver request a multicast service from each other. When the multicast tree is set in this way, the contents of the multicast team VRF are changed to match the set multicast tree.

Meanwhile, the present invention configured as shown in FIG. 1 is a MPLS VPN structure based on BGP-E (Broader Gateway Protocol-Extention), and data exchange between PEs is performed based on BGP-E. In the BGP-E-based routing, as described above, routing is performed for packets having the same IP address of different groups, and routing is performed through a separate VPN VRF table for each VPN user so as to be distinguished from the existing IP routing. This is not a detailed description since it is already a publicly available technology.

Hereinafter, a process of setting up and canceling a multicast tree will be described with reference to FIG. 2.

FIG. 2 is a flowchart illustrating a multicast tree setup and termination procedure according to an embodiment of the present invention, in which a subscriber network N1 is used as a transmitting side and a subscriber network N2 is used as a receiving side.

As shown in FIG. 2, CE2 of the receiving network N2 forwards a join_des_req message to CE1 requesting that it be registered as a multicast receiver.

Accordingly, the join_des_req message transmitted from CE2 is received by PE2 (S211), PE2 reads the received message to determine the destination CE (CE1), and join_req message to MP-BGP (MutiProtocol-Broader Gateway Protocol) multicast extension ( extension) is delivered to the PE (PE1) connected to the destination CE through routing (S212).

Here, delivering the join_req message from the PE2 to the PE1 through the MP-BGP multicast extension routing confirms the PE1 as a destination address included in the header of the join-req message using the VRF stored in the PE2, and join-req message. This means that a tag or a corresponding data (hereinafter, referred to as a "use value") included in the multicast is transmitted to PE1.

When the join_req message delivered by PE2 is received in PE1, PE1 determines that the message received from the usage value included in the join_req message is for multicasting, and thus registers the receiver information included in the join_req message in the VRF for multicasting. do.

Then, PE1 transmits a join_conf message, which is a response message indicating that it is registered as a receiver in a multicast group, to PE2 through MP-BGP multicast extension routing (S213).

Accordingly, PE2 transmits a join_des_conf message to CE2 indicating that the multicast group is registered as a receiver according to the received join_conf message (S214).

Here, when CE2 registers to the multicasting VRF of PE1 as a multicast receiver, if one of the CEs connected to PE1 registers as a multicast sender, CE2 registered as a multicast sender and a predetermined CE registered as a multicast receiver In between, a multicasting tree is established.

However, when CE2 registers to the multicasting VRF of PE1 as a multicast receiver, if none of the CEs connected to PE1 have registered as a multicast sender, the multicasting tree for CE2 is not yet set.

If the multicasting tree is not configured, CE1 connected to PE2 transmits a join_sou_req message requesting to be registered as a multicast service sender to PE1, and the join_sou_req message is received at PE1 (S215).

Here, the join_sou_req message includes a usage value indicating that the message is for multicasting.

PE1 then reads the sender's information for multicasting from the join_sou_req message received from CE1 and registers the sender's information in its multicasting VRF. PE1 transmits a join_sou_conf message, which is a response message indicating that CE1 is registered as a sender of the multicast group, to CE1 (S216).

Accordingly, as CE1 is registered as a multicast sender and CE2 is registered as a multicast receiver in the VRF for multicasting stored in PE1, a multicast tree is established between CE1 and CE2 (S217).

When the multicast tree is established between PE1 and PE2 as described above, the multicast data transmitted from CE1 (that is, MPLS VPN packet for multicasting) is transmitted to CE2 along with other CEs registered as multicast recipients.

As described above, when a multicast tree is set between PE1 and PE2, if a self-registered as a sender of a multicast group is released from CE1 as a transmitting side, a release_sou_req message corresponding thereto is generated and transmitted to PE1 (S218). .

In this case, the release_sou_req message includes a usage value indicating that the message is for multicasting.

Therefore, PE1 reads the header of the received release_sou_req message to confirm that the received message is a message for multicasting, and checks the sender's information. Accordingly, the PE1 is a sender of the multicast group in the contents of the stored multicast VRF. Delete the registered record.

Then, PE1 transmits a release_sou_conf message to CE1 indicating that the multicast group has been released (S219).

As described above, when CE1 is canceled at the sender of the multicast group, the multicast tree between CE1 and CE2 is temporarily canceled. When CE1 is canceled at the sender of the multicast group, no multicast packet is transmitted at CE1, and even if a multicast packet is generated at CE1, other CEs that have a multicast tree configured at CE1 can receive the multicast packet. There will be no.

In this state, when a registered release-des-req message requesting that the self-registered as a receiver of a multicast group from CE2 to PE2 is delivered (S220), PE2 reads the received release_des_req message to read destination information and source information and It determines that the signal is for the broadcast, and accordingly transmits a release_req message requesting the cancellation of the multicast tree to the PE1 (S221).

When PE1 receives the release-req message from PE2, it reads the header information of the release_req signal, releases the subscriber registered in the stored multicast VRF at the receiver of the multicast group, and delivers the response message release_con to PE2. (S222).

Accordingly, PE2 generates a release_des_con message and transmits it to CE2 (S224).

As described above, when giving up the role of the sender in CE1 and the role of the receiver in CE2, information about this is recorded in the multicasting VRF stored in the PE1, and thus the multicast tree between CE1 and CE2 is terminated. (S224).

Therefore, when the multicast tree between CE1 and CE2 is released as described above, even if CE1 is registered as a sender of the multicast group, CE2 cannot receive the multicast packet transmitted by CE1. In addition, as described above, when both the CE1 and the CE2 terminate the multicast tree, no multicast service is provided between the two CEs.

As described above, it can be seen that the present invention depends on the multicast tree setup between the two CEs and the information of the multicasting VRF stored in the PE connected to the sender CE of the multicast aggregation. That is, it can be seen that it depends on the information recorded whether the LSP between the two CEs is connected or terminated to the multicasting VRF.

In the above description with reference to FIG. 2, the receiving side requests the multicast service before the transmitting side. However, this is only one embodiment. In fact, the order of requesting the multicast service is arbitrary. And, the termination of the multicast service is also in random order.

Hereinafter, a multicasting providing method in an MPLS VPN according to an embodiment of the present invention will be described with reference to FIG. 3.

3 is a flowchart illustrating a multicasting providing method in an MPLS VPN according to an embodiment of the present invention.

First, all PEs have VRFs for multicasting and VRFs for unicasting, and can receive packets from the CE or receive packets from other PEs through the service provider device (P1, P2, P3). .

Here, it demonstrates based on PE1.

When the PE1 receives an MPLS VPN packet from an adjacent network device (i.e., CE1 or P1) (S310), examines the header of the packet (S311). If the information of the header consists of an IP address, the PE1 transmits the information from the CE1. It is determined that the packet is a packet, and if the header information is label information, it is determined that the packet is transmitted by P1.

Typically, in MPLS VPN, the header of a packet sent from CE to PE contains the prefix IP address for the CE and the prefix IP address of the destination CE, and the packets sent from P to PE are labeled with the label for the source PE. This is because the label of the next hop is recorded.

When the IP address is checked from the header of the packet, the PE1 determines that it is transmitted from the CE1, and accordingly, determines whether the destination IP address is recorded in the multicasting area or the unicasting area (S312).

If the destination IP address is recorded in the unicasting area in the determination (S312), the PE1 refers to the unicasting VRF stored therein (S313), checks the PE to which the packet is transmitted, and then sends it to the PE to be transmitted. The corresponding label and the label of the next hop are obtained using the stored forwarding label table and then included in the header of the packet and transmitted to P1 (S314 and S320).

However, if the destination IP address is recorded in the multicasting area in the determination (S312), the PE1 refers to the multicasting VRF stored in its own storage (S315) to determine whether there are a plurality of single destinations or single packets. do. In other words, it is determined whether the multicast tree set in the source included in the packet is single or multiple (S316).

In the determination (S316), if the multicast tree is single, PE1 transmits the packet to a single multicast tree by attaching a label of a destination and a next hop to the header of the packet as in the case of the aforementioned unicast (S317, S320). ).

However, if the multicast tree is a large number in the determination (S316), PE1 replicates the packet by the number of multicast trees (S318), and the label corresponding to each destination and the label of the next hop in the header of each duplicated packet. The packet is transmitted to each multicast tree (S319 and S320).

Therefore, the packet transmitted from PE1 can be transmitted to the corresponding destination (S320).

On the other hand, in the packet inspection (S311), if the label recorded in the header of the packet is a label, PE1 checks the label to determine whether the label is a label for multicasting or unicasting (S321).

In the determination S321, if the label is a label for multicasting, it is determined that the packet is received from the service supply device P1, and accordingly, the label is removed (S322) and the multicasting VRF is stored. In step S323, the number of CEs and CEs that set the source and the multicast tree included in the header of the received packet is determined (S324).

In step S324, the number of multicasts is single and a packet is transmitted to the corresponding CE (S328).

However, if the determined number of multicasts is large, PE1 replicates the received packets by the determined number and transmits the packets to the respective CEs (S325 and S328).

On the other hand, if the label checked in the label check (S321) is a label for unicasting, PE1 removes the label included in the header of the packet (S326), and then refers to the unicasting VRF stored in the packet to the destination CE. The packet is transmitted (S328).

The technical spirit of the present invention has been described above with reference to the accompanying drawings, but this is by way of example only and not intended to limit the present invention. In addition, it is obvious that any person skilled in the art can make various modifications and imitations without departing from the scope of the technical idea of the present invention.

The present invention has the effect of significantly reducing the traffic load on the service provider's network compared to the conventional unicast scheme by supporting the multicasting service in the service provider network in the MPLS VPN.

In addition, the present invention can reduce the traffic load generated through multiple unicasting in the service user internal network, and through the multicasting provided by the service provider without having to install software or hardware that provides a separate multiple unicasting function. There is an effect that can provide a secure multicasting service.

Claims (8)

A method of providing a multicasting service in an MPLS VPN network including a plurality of CEs included in a subscriber network, a plurality of PEs belonging to a service provider network, and a plurality of service providers. Receiving a MPLS VPN packet at a first PE of the plurality of PEs; Determining, in the first PE, a reception path by determining whether header information of the received packet is IP information or label information; A third step of determining whether the received packet is for multicast or unicast using the IP information or label information determined in the second step in the first PE; In the first PE, if the received packet is for multicast, multicasting VRF storing information on whether a source of the received packet and a multicasting tree are set in a network device connected to the first PE. A fourth step of determining whether multiple or single destinations to which the packet is to be transmitted are determined by using; And In the first PE, if there are a plurality of destinations to be transmitted, the multi-casting providing method in the MPLS VPN network comprising the step of transmitting the packet to the path of the destination after replicating the number of destinations to be transmitted. The method of claim 1, In the third step, if the received packet is for unicast, transmitting the packet to a corresponding destination using a unicasting VRF in which other network devices and path information connected to the first PE are recorded. Multicasting providing method in the MPLS VPN network comprising a. The method of claim 1, The third step, If the header information is IP information, it is determined whether the received packet is for multicasting or unicasting by checking whether the IP information is recorded in a multicasting region or a unicasting region. If the header information is label information, it is determined whether the received packet is for multicast or unicast by checking whether the label is a label for multicasting or a label for unicasting. How to Provide. The method of claim 1, The multicasting VRF, The content is changed by the first PE, and the time when the content is changed is a first time when any CE registers as a sender of a multicasting group, a second time when any CE registers as a receiver of a multicasting group, and A third time at which the CE revokes its role as a sender of the multicasting population, and a fourth time at which a particular CE revokes its role as a receiver of the multicasting population, When the first time and the second time are satisfied, a multicast tree is established between two CEs so that data can be exchanged. In the MPLS VPN network including a plurality of CEs included in the subscriber network, a plurality of PEs belonging to the service provider network and a plurality of service providers. At a second PE connected to the second CE, a receiver request step of receiving a receiver registration / cancellation request signal to be registered / cancelled from a first PE connected to the first CE as a receiver of a multicast group; In the second PE, determining whether the signal received from the first PE is a signal for multicast, and registering / canceling the first CE as a receiver of a multicast group; A recipient registration response step of notifying registration / cancellation from the second PE to the first PE; A receiver request step of receiving, at the second PE, a sender registration / release request signal requesting to be registered / cancelled from the third CE as a sender of a multicast group; At the second PE, registering / canceling the third CE as a sender of a multicast group and establishing / canceling a multicast tree between the third CE and the first CE; And And a sender registration response step of notifying registration / cancellation facts from the second PE to the third CE. The method of claim 5, The signal exchanged between the first PE and the second PE and the second PE and the third PE, The method for setting / canceling a multicast tree in an MPLS VPN network, wherein the header includes data indicating that the multicasting service is for multicast. On your computer, Receiving a MPLS VPN packet at a first PE of the plurality of PEs; Determining, in the first PE, a reception path by determining whether header information of the received packet is IP information or label information; A third step of determining whether the received packet is for multicast or unicast using the IP information or label information determined in the second step in the first PE; In the first PE, if the received packet is for multicast, multicasting VRF storing information on whether a source of the received packet and a multicasting tree are set in a network device connected to the first PE. A fourth step of determining whether multiple or single destinations to which the packet is to be transmitted are determined using; And In the first PE, a program for providing a multicast service in an MPLS VPN network comprising a fifth step of duplicating the packet as many destinations to be transmitted if there are a plurality of destinations and then transmitting the packet to a path of a corresponding destination. A computer-readable recording medium that stores data. On your computer, At a second PE connected to the second CE, a receiver request step of receiving a receiver registration / cancellation request signal to be registered / cancelled from a first PE connected to the first CE as a receiver of a multicast group; In the second PE, determining whether the signal received from the first PE is a signal for multicast, and registering / canceling the first CE as a receiver of a multicast group; A recipient registration response step of notifying registration / cancellation from the second PE to the first PE; A receiver request step of receiving, at the second PE, a sender registration / release request signal requesting to be registered / cancelled from the third CE as a sender of a multicast group; In the second PE, registering / canceling the third CE as a sender of a multicast group and setting up / terminating a multicast tree between the third CE and the first CE; And A multicast tree is established / terminated between the multicast service provider and the multicast receiver in the MPLS VPN network, including a sender registration response step of notifying registration / cancellation from the second PE to the third CE. Computer-readable recording media that store programs that