KR20030090174A - Method for VPN Group Route Information Collecting in BGP MPLS VPN Network - Google Patents

Abstract

PURPOSE: A method for collecting VPN(Virtual Private Network) group path information in a BGP(Border Gateway Protocol) MPLS(Multi Protocol Label Switching) VPN network is provided to prevent an unnecessary transmission of VPN group path information between PE(Provider Edge) units and shorten the time of processing a BGP packet by demanding and receiving the path information of a specific VPN group only in case that the path information of the specific VPN group is required. CONSTITUTION: Each PE attempts TCP(Transmission Control Procedure) connection setup for iBGP session setup with the other PE(S100). If the TCP connection setup attempt is successful, each PE adds a VPN route request capability advertisement notification option parameter to the BGP capability advertisement notification option parameter of an open message and transmits the open message to the other PE(S105-S115). Each PE receives the open message from the other side and confirms whether its own BGP supports all the functions that the BGP of the other PE supports(S120,S125). If it is judged that its own BGP supports all the functions that the BGP of the other PE supports, each PE transmits a KEEPALIVE message to the other PE and confirms whether a response message is received from the other side(S135).

Description

Method for VPN Group Route Information Collecting in BGP MPLS VPN Network}

The present invention relates to a method for collecting VPN group path information of a Border Gateway Protocol (BGP) Multi Protocol Label Switching (MPLS) Virtual Private Network (VPN) network, and more particularly, to request and collect only path information of a specific VPN group. The present invention relates to a method for collecting VPN group path information of an MPLS VPN network.

In general, the BGP MPLS VPN network is a network providing VPN services to users connected to the public network using the BGP technology and the MPLS technology. FIG. 1 is a diagram illustrating a configuration of a general BGP MPLS VPN network.

The router directly connected to the subscriber network in the BGP MPLS VPN network of FIG. 1 is called a provider edge (PE) router (PE1, PE2), and the router connected to the PE routers (PE1, PE2) in the subscriber network for a VPN service is CE. (Customer Edge) Routers (CE1, CE2, CE3, CE4).

In order to perform packet transmission in the BGP MPLS VPN network, first, each PE router end (PE1, PE2) establishes an iBGP (internal border gateway protocol) session with the other PE router end (PE2, PE1), and then sends a BGP message. It exchanges route information about the VPN group they serve.

Here, the BGP of each PE router end (PE1, PE2) supports the capability advertisement function (Capability Advertisement) that informs the other PE router end (PE2, PE1) the functions that can be supported in each PE router end, each PE router In the end, the multiprotocol extension function, route refresh message, and BGP extended community unit attribute processing should be performed.

Hereinafter, the operation of the conventional BGP MPLS VPN network will be described with reference to FIGS. 1 to 6.

First, when a TCP (Transmission Control Protocol) connection for establishing an iBGP session between PE terminals PE1 and PE2 is completed through an operator's input, an iBGP session is established through an open message exchange as shown in FIG. Each PE stage adds code, length, and value for each function supported by the local station to the option parameter of the open message, so that BGP such as multiprotocol extension function or path update function can be transmitted. Inform the other PE of the functions that can be processed.

On the other hand, when the open message is received from the other end of the PE through an open message exchange, the option parameter of the received open message is checked to determine whether all the functions included in the option parameter of the open message are supported.

If the determination result does not support all the functions included in the option parameter of the received open message, a notification message indicating that there is an unsupported function is transmitted to the other PE, and the iBGP session setup is stopped.

On the other hand, if all of the functions included in the option parameter of the open message received as a result of the determination results in sending a keep-alive (KEEPALIVE) message to the peer PE side.

Then, when receiving the keep-alive (KEEPALIVE) message from the other end of the PE, if the iBGP session setup with the other end of the PE is normally completed, each PE is through the update message for all VPN groups serviced by each PE. Exchange route information with the other end of PE.

Here, as shown in FIG. 1, the VPN distinguishes using route distingusher (RD) values to distinguish route information from a site from route information of a public IP network.

As described above, each PE exchanged the route information for the VPN group through the update message is a VPN Routing and Forwarding (VRF) used for packet transmission to each VPN group based on the route information for the exchanged VPN group. In creating and managing the table, the VRF table is configured separately from the general IP routing table as shown in FIG. 3 and managed only in the PE serving the VPN group.

For example, since the PE02 group is not serviced by PE2 before CE4 is generated in PE2 in FIG. 1, the VRF02 table is not managed in PE2.

In addition, in the VRF table used for packet transmission to the VPN group, RT (Route Target) values are set to select and store / transmit only path information of a specific VPN group. That is, each VRF table has an Import RT and an Export RT value. When transmitting the VPN route information through an iBGP session, as shown in FIG. 4, the Export RT value in the update message is shown. Add the output.

On the contrary, when the route information is received from the other party's PE, it is determined whether the RT value included in the update message is the same as the import RT value of the VRF, and if so, the received route information is recorded in the VRF.

Separately, the VPN route information transmitted in the Network Layer Reachability Information (NLRI) field of the update message is delivered in the form of a combination of an 8-byte RD value and an IP address prefix value to distinguish the public IP address.

As described above, after exchanging all the BGP route information through the update message, only the changed route information is exchanged through the route refresh message, and the route refresh message is collected to collect the VPN group route information. 5 and transmit the path information of all the VRFs managed by the other party through the update message.

For example, assuming that CE4 is newly added to PE2 in the BGP MPLS VPN network as shown in FIG. 1 to request a new VPN group (VPN02) service, PE2 does not have a CE in the VPN02 group. Therefore, it does not have the VRF02 table necessary for packet routing and forwarding from the VPN02 group subscribers.

Therefore, PE2 needs to collect route information for the newly added VPN02 group in order to create the VRF02 table. Route information for CE4, the regional site, can be entered by Routing Information Protocol (RIP), External BGP (EBGP), or operator's input. The route information for the remote site CE2 belonging to the VPN group such as CE4 is collected by route update message and update message.

That is, PE2 constructs a BGP route update message and transmits it to PE1 as shown in FIG. 5 in order to collect route information about the remote site CE2 belonging to a VPN group such as CE4.

As described above, the PE1 receiving the path update message from the PE2 transmits the path information of all VPN groups managed by the PE2 in the BGP update message to the PE2.

Since the PE1 having subscribers of the VPN01 group and the VPN02 group manages the VRF01 table and the VRF02 table, as shown in FIG. 4, all path information of the VRF01 and the VRF02 is transmitted to the PE2 using an update message. .

On the other hand, PE2 receiving the update message transmitted from PE1 updates the VRF01 table by selecting only the path information of the update message having 100: 3 as the RT value, and uses the imported RT value of the VRF02 table 100: 4 to configure the VRF02 table. Selects only the path information of the update message having the RT value and adds it to the VRF02 table.

As described above, in the BGP MPLS VPN network, a subscriber of a specific VPN group may be newly created or deleted during operation. In the conventional BGP MPLS VPN network, the path information of the newly created or deleted specific VPN group may be generated. Although only need is needed, the PE side receiving the route update message transmits route information for all VPN groups. Therefore, there is a problem that a large amount of unnecessary data is transmitted through the network.

In addition, the PE stage requesting data by transmitting a path update message affects CPU processing time due to unnecessary path information processing, which affects processing of other tasks.

The present invention has been made to solve the above-described problem, when the operation requires the path information of a specific VPN group, during operation, only by requesting the path information of a specific VPN group to receive only the path information of a specific VPN group, The purpose of the present invention is to provide a VPN group path information collection method of a BGP MPLS VPN network to prevent unnecessary VPN group path information transmission and to improve network scalability by reducing BGP packet processing time.

1 is a diagram showing the configuration of a typical BGP MPLS VPN network by way of example.

Figure 2 is a diagram showing the configuration of a typical open message.

3 is a diagram illustrating the configuration of a general IP routing table and a VRF table.

4 is a diagram showing the configuration of a general update message.

5 is a diagram showing the configuration of a general path update message.

6 to 8 are flowcharts illustrating a method for collecting VPN group path information of a BGP MPLS VPN network according to the present invention.

9 is a view showing the configuration of an open message applied to the present invention.

10 is a diagram showing the configuration of a general notification message.

11 is a view showing the configuration of a path update message to be applied to the present invention.

According to an aspect of the present invention, there is provided a method for collecting VPN group path information of a BGP MPLS VPN network. The method may further include requesting a VPN path request function to a peer PE end that attempts to establish an iBGP session using a BGP function notification option parameter of a BGP open message. A VPN route request function notification process indicating whether support is present; After exchanging the route information of the VPN group with the counterpart PE, if the route information of the specific VPN group is needed, request the route information of the specific VPN group to the counterpart PE, and the route information from the counterpart PE. A VPN route information transmission process of transmitting only the route information of a specific VPN group as a BGP update message according to a request; When the BGP update message is received from the peer PE, path information of the VRF table having an import RT value corresponding to the RT value included in the received BGP update message is added to the path information included in the received BGP update message. It includes a VRF table update process to update based on.

Here, the VPN path request function notification process supports the VPN path request function in the BGP function notification option parameter of the BGP open message when establishing an iBGP session with the counterpart PE end in the PE end of the VPN path request function enabled. Adding a VPN route request function notification option parameter informing that it is present; Transmitting a BGP open message including the VPN path request function notification option parameter to the counterpart PE; Checking a BGP function notification option parameter of the received BGP open message when receiving the BGP open message from the counterpart PE, and determining whether there is a function not supported by the BGP of the local station; Transmitting a KEEPALIVE message to the counterpart PE if there is no function not supported by the BGP of the own station; Receiving a response message to the BGP open message from the counterpart PE end; Determining whether the received response message is a connection maintenance message; If the received response message is a connection maintenance message, the determination result comprises establishing an iBGP session establishment with the peer PE in a state where the VPN path update function is enabled. And if the received response message is a notification message, determining whether the error subcode value is a code value indicating a VPN path request function by checking an error subcode of the received notification message; If the error subcode value is not a code value indicating a VPN path request function, stopping the iBGP session establishment with the peer PE; If the error subcode value is a code value indicating a VPN path request function as a result of the determination, the iBGP session establishment with the counterpart PE end is stopped, and the VPN path request function supported by the own station is disabled and and retrying the iBGP session establishment.

In the VPN route information transmission process, a VPN route request option field recording the RTRT values of the VRF table for a specific VPN group requiring collection of route information is added to a BGP route update message and transmitted to the counterpart PE to transmit the specific VPN group. Requesting route information for; Determining whether a VPN path request option field is included in the received BGP path update message at the counterpart PE terminal receiving the BGP path update message; When the received BGP route update message includes the VPN route request option field as a result of the determination, the export RT value of the VRF table managed by the home station is searched using the RT value recorded in the VPN route request option field. Steps; Determining whether a VRF table having an export RT value matching the RT value included in the VPN path request option field exists in the search result; If there is a VRF table having an export RT value that matches the RT value included in the VPN route request option field, transmitting only the path information of the retrieved VRF table through a BGP update message. It is done. Here, whether the received BGP route update message includes a VPN route request option field is determined based on a length value included in the BGP message header field of the received BGP route update message. do.

The VRF table update process may include: receiving a BGP update message from the counterpart PE end; Determining whether the RT value included in the received BGP update message and the RT value recorded in the VPN route request option field added to the BGP route update message are the same; If the RT value included in the received BGP update message and the RT value recorded in the VPN route request option field added to the BGP route update message are the same, the route information included in the received BGP update message is determined. Adding to the VRF table having an export RT value that matches the RT value; If the RT value included in the received BGP update message and the RT value recorded in the VPN route request option field added to the BGP route update message are not the same as the result of the determination, the import RT of another VRF table managed by the home country is not identical. Retrieving a value to determine whether a VRF table with an imported RT value that matches the RT value included in the received BGP update message exists; If there is a VRF table having an import RT value corresponding to the RT included in the received BGP update message as a result of the determination, the path of the VRF table searched based on the path information included in the received BGP update message And updating the information.

Hereinafter, a VPN group path information collection method of a BGP MPLS VPN network according to a preferred embodiment of the present invention will be described in detail with reference to the accompanying drawings.

First, since the configuration of the BGP MPLS VPN network to which the VPN group path information collection method according to the present invention is applied is the same as the conventional method, the VPN group path information collection method according to the present invention will be described below with reference to FIG. 1.

6 to 8 are flowcharts illustrating a method for collecting VPN group path information of a BGP MPLS VPN network according to the present invention.

In the BGP MPLS VPN network, in order to perform packet transmission with the other PE end, a predetermined PE end with the VPN path request function enabled is required to first establish an iBGP session between the PE ends. Likewise, an attempt is made to establish a TCP (Transmission Control Procedure) connection for establishing an iBGP session between PE terminals PE1 and PE2 through an operator's input (S100).

As a result of the TCP connection establishment attempt of the process S100, when the TCP connection is successfully established, each PE terminal PE1 and PE2 informs the other party of the functions supported by the local station as shown in FIG. Similarly, the VPN Route Request Capability Advertisement notification option parameter is added to the open message's BGP capability notification option parameter (since the station supports the VPN route request function), and the VPN route request capability notification option parameter is added. The open message is sent to the counterpart PE end PE2, PE1 to exchange the open message with each other (S105, S110, S115).

As shown in FIG. 9, the open message transmitted by each PE terminal PE1 and PE2 to the counterpart PE terminal PE2 and PE1 in the step S115 includes the BGP function notification option parameter. BGP of open messages sent to PE2, the peer PE, in case PE1 supports VPN Route Request Capability in addition to Multiprotocol Extension Capability and Route Refresh Capability In addition to the code, length, and value for the multiprotocol extension and the path update function, the function notification option parameter includes the code, length, and value for the VPN path request function.

Here, since the code value for the VPN route request function has not been officially assigned yet, use a private assignment code value (128 to 255) or use a value assigned from the Internet Assigned Number Authority (IANA) when standardized. . Since the value is not needed, the length is '0'.

On the other hand, when the open message transmitted from the other party's PE terminal PE2 is received through the open message exchange in step S115, the BGP function notification option parameter included in the open message received from the other party's PE PE2 is retrieved. After checking the functions supported by the BGP of the other party's PE (PE2), it is determined whether the BGP of the local station PE (PE1) supports all the functions supported by the BGP of the other party's PE (PE2) (S120 and S125).

If the BGP of the local station PE (PE1) supports all of the functions supported by the BGP of the other party's PE (PE2), the mobile station sends a KEEPALIVE message to the other party's PE (PE2). It waits for a KEEPALIVE message or a notification message, which is a response message to the open message, from the PE PE2 (S135).

On the other hand, if the determination in step S125 described above does not support all of the functions supported by the BGP of the local station PE (PE1), the function does not support the error subcode of the notification message shown in FIG. The code value is inserted and transmitted to the other party's PE (PE2) to inform the other party's PE (PE2) of what the function does not support and stops setting up an iBGP session with the other party's PE (PE2) (S130).

At this time, the peer PE (PE2) that has received the open message sent in step S115 may also search for the BGP function notification option parameter included in the received open message, so that the BGP of the local station supports all the functions supported by the BGP of the peer PE. After determining whether to support, a notification message or a keep-alive message is transmitted according to the determination result.

Meanwhile, in step S135, the PE PE1 which transmits the connection maintenance message to the other party PE PE2 and waits for the response message for the open message to be received receives the notification message or the connection maintenance message from the other party PE PE2. In response to receiving the connection maintenance message from the other party PE (PE2), the iBGP session establishment with the other party PE (PE2) is established with the VPN path update function enabled, and a notification message from the other party PE (PE2). When receiving the, check the error subcode of the received notification message to determine whether the error subcode value is a code value indicating the VPN path request function (S140, S145, S150).

If the error subcode value is not a code value indicating the VPN path request function as a result of the determination in step S150, the iBGP session establishment with the peer PE (PE2) end is stopped (S155).

On the other hand, if the error subcode value is a code value indicating the VPN path request function as a result of the determination in step S150, after setting the iBGP session with the peer PE (PE2), the VPN path request function is disabled and the peer PE end is disabled. The iBGP session establishment with the PE2 is attempted again (S160 and S165).

The reason for disabling the VPN path request function in step S165 and attempting to establish an iBGP session with the peer PE end PE2 again is that the VPN path request function is an optional function belonging to the path update function. That is, if the PE side that supports VPN route request function attempts to establish an iBGP session, the PE side that does not support VPN route request function does not need to perform packet communication with the other PE side without using VPN route request function. In this case, after disabling the VPN route request function, try to establish an iBGP session with the peer PE again.

As described above, if iBGP session establishment between the PE stages supporting the VPN route request function is normally established, each PE stage exchanges route information about all VPN groups serviced by each PE stage with the other PE side through an update message. .

After exchanging route information about all VPN groups serviced by each PE side through the update message with the other PE side, if route setting policy is changed or VPN group is added, route information is exchanged to construct a new VRF table. In this case, only route information of a specific VPN group is exchanged through a route refresh message and an update message.

In the BGP MPLS VPN network as shown in FIG. 1, when a new site is added or an existing site needs route information of a new VPN group, the operator requests a VPN group addition to the PE connected to the site requiring the addition of the VPN group. As shown in FIG. 7, since the PE group that is requested to add a new VPN group from the operator (S200) does not have a VRF table necessary for packet routing and forwarding from subscribers of the additional requested VPN group, To generate a VRF table for the additional requested VPN group, we need to collect route information for the newly added VPN group.

The route information for the VPN group includes route information for the local site and route information for the remote site. The route information for the local site is obtained by RIP, EBGP, or operator input. Collect via update message and update message.

As described above, the PE end that is requested to add a VPN group to collect route information from a remote site of the additional requested VPN group collects route information in a route update message as shown in FIG. 11 according to the VPN route request function. The VPN route request option field, which records the import RT values of the VRF table for the required VPN group, is added and transmitted to the counterpart PE in which the iBGP session is established (S205).

As shown in Fig. 11, the path update message applied to the present invention includes a VPN path request option field. The VPN path request option field includes an option length of 1 byte and N RT values. Therefore, the length of the path update message is the number of bytes including the VPN path request option field.

Here, when the PE side to collect the route information does not support the VPN route request function, as in the related art, a general route update message as shown in FIG. 5 is transmitted.

In addition, even when the PE stage to collect route information wants to collect route information of the entire VPN group, the general route update message as shown in FIG. 5 is transmitted.

On the other hand, in the other end PE stage that receives the route update message sent in the above step S205, when receiving the route update message, as shown in Figure 8, the received route update message includes a VPN route request option field It is determined whether there is (S300, S305).

If the AFI (Address Family Identifier) of the path update message received in step S300 is 1 and the Subsequent Address Family Identifier (SAFI) is 128, the received path update message is a path update message requesting VPN path information.

Whether or not the VPN route request option field is included in the route update message received in step S300 may be determined by the length value included in the BGP message header field of the received route update message. Is 23, the route update message does not include the VPN route request option field. If the length is greater than 23, the route update message includes the VPN route request option field.

If the VPN route request option field is not added to the received route update message as a result of the determination of step S305, the PE stage requesting the route information determines that the route information of all the VPN groups is requested, and the PE stage requests the route information. In step S310, route information of all VPN groups is transmitted.

In step S310, the path information of each VPN group is transmitted through a separate update message. For example, assuming that the PE01 which is requested to transmit the route information is serving the VPN01 group and the VPN02 group, the PE stage receiving the route update message without the VPN route request option field added as shown in FIG. 4. Similarly, the update message of the VPN01 group and the update message of the VPN02 group are separately configured to transmit the route information to the requested PE.

On the other hand, if the VPN route request option field is added to the received route update message as a result of the determination of step S305, the VRF managed by the local station is an RT value included in the VPN route request option field of the received route update message. The export RT value of the table is searched to determine whether a VRF table having an export RT value equal to the RT value included in the VPN route request option field of the route update message exists (S315 and S320).

If the VRF table having the export RT value having the same value as the RT value included in the VPN route request option field of the route update message does not exist, the route update message received at the process S300 is determined. Finish the processing (S325).

Meanwhile, when the VRF table having the export RT value having the same value as the RT value included in the VPN route request option field of the route update message as the determination result of step S320 is present, only the route information of the corresponding VRF table is transmitted. Only the update message is sent to the PE requesting the path information (S330).

For example, if the PE requesting route information adds an import RT value of 100: 4 of VRF02 to the VPN route request option field of the route update message and sends it to the peer PE side with an iBGP session, the route update message is sent. The received PE side checks the RT value 100: 4 in the VPN route request option field of the received route update message and exports the same value as the RT value 100: 4 in the VPN route request option field of the received route update message. Only the update message for transmitting the route information of the VRF02 table having the RT value is transmitted to the PE which requested the route information.

On the other hand, the PE stage that has transmitted the path update message in step S205 waits for the reception of the update message, which is a response message to the path update message. As shown in FIG. It is determined whether the RT value included in the update message is the same as the RT value added to the VPN route request option field of the route update message in step S205 (S215).

When the RT value included in the update message received as a result of the determination of step S215 and the RT value added to the VPN path request option field of the path update message in step S205 are the same, the RT value included in the received update message is included. The route information is added to the VRF table having the export RT value that matches the RT value included in the update message (S220).

On the other hand, if the RT value included in the update message received as a result of the determination in step S215 and the RT value added in the VPN route request option field of the route update message in step S205 are not the same, the local station manages the same. The import RT value of the other VRF table is searched to determine whether a VRF table having an import RT value that matches the RT value included in the received update message exists (S225, S230).

If there is a VRF table having an import RT value that matches the RT included in the update message received as a result of the determination in step S230, the path of the VRF table is based on the path information included in the received update message. The information is updated (S235).

On the other hand, if there is no VRF table having an import RT value that matches the RT included in the update message received as a result of the determination in step S230, the processing of the update message received in step S210 is completed (S240). ).

The VPN group path information collection method of the BGP MPLS VPN network of the present invention is not limited to the above-described embodiments, and can be modified in various ways within the scope of the technical idea of the present invention.

According to the method for collecting VPN group path information of the BGP MPLS VPN network of the present invention as described above, when the path information of a specific VPN group is needed during the operation of the BGP MPLS VPN network, a specific VPN requiring route information to each PE is required. By receiving only the path information of a specific VPN group by requesting only the path information of the group, it is possible to prevent unnecessary VPN group path information transmission between PEs and to reduce the BGP packet processing time, thereby improving network scalability.

Claims (6)

A VPN route request function notification process of notifying whether or not the VPN route request function is supported to the peer PE end that attempted to establish an iBGP session using the BGP function notification option parameter of the BGP open message; After exchanging the route information of the VPN group with the counterpart PE, if the route information of the specific VPN group is needed, request the route information of the specific VPN group to the counterpart PE, and the route information from the counterpart PE. A VPN route information transmission process of transmitting only the route information of a specific VPN group as a BGP update message according to a request; When the BGP update message is received from the peer PE, path information of the VRF table having an import RT value corresponding to the RT value included in the received BGP update message is added to the path information included in the received BGP update message. Method for collecting VP group path information of BPMP VMP network including VRF table update process to update based on the VF network. The method of claim 1, wherein the VPN path request function notification process, When the iBGP session with the other party's PE is established in the PE terminal with the VPN path request function enabled, the VPN path request function notification option parameter indicating that the VPN path request function is supported in the BGP function notification option parameter of the BGP open message is set. Adding; Transmitting a BGP open message including the VPN path request function notification option parameter to the counterpart PE; Checking a BGP function notification option parameter of the received BGP open message when receiving the BGP open message from the counterpart PE, and determining whether there is a function not supported by the BGP of the local station; Transmitting a KEEPALIVE message to the counterpart PE if there is no function not supported by the BGP of the own station; Receiving a response message to the BGP open message from the counterpart PE end; Determining whether the received response message is a connection maintenance message; And if the received response message is a connection maintenance message, establishing an iBGP session establishment with the peer PE in a state where the VPN path update function is enabled. How to collect VIP group route information of LS VPI network. The method of claim 2, wherein the determination result indicates that the received response message is a notification message. Checking an error subcode of the received notification message to determine whether the error subcode value is a code value indicating a VPN path request function; If the error subcode value is not a code value indicating a VPN path request function, stopping the iBGP session establishment with the peer PE; If the error subcode value is a code value indicating a VPN path request function as a result of the determination, the iBGP session establishment with the counterpart PE end is stopped, and the VPN path request function supported by the own station is disabled and and retrying the iBGP session establishment. The method of collecting VPI group path information of a BMP VP network. The method of claim 1, wherein the VPN path information transmission process is performed. Requesting route information for a specific VPN group by adding a VPN route request option field that records import RT values of a VRF table for a specific VPN group requiring collection of route information to a BGP route update message; Determining whether a VPN path request option field is included in the received BGP path update message at the counterpart PE terminal receiving the BGP path update message; When the received BGP route update message includes the VPN route request option field as a result of the determination, the export RT value of the VRF table managed by the home station is searched using the RT value recorded in the VPN route request option field. Steps; Determining whether a VRF table having an export RT value matching the RT value included in the VPN path request option field exists in the search result; If there is a VRF table having an export RT value that matches the RT value included in the VPN route request option field, transmitting only the path information of the retrieved VRF table through a BGP update message. Method for collecting VP group path information of BPMP VPS network. The method of claim 4, wherein whether the received BGP route update message includes a VPN route request option field includes: And a method for collecting VPI group path information in a BMP MPV network based on a length value included in a BGP message header field of the received BGP path update message. The method of claim 1, wherein the VRF table update process, Receiving a BGP update message from the counterpart PE end; Determining whether the RT value included in the received BGP update message and the RT value recorded in the VPN route request option field added to the BGP route update message are the same; If the RT value included in the received BGP update message and the RT value recorded in the VPN route request option field added to the BGP route update message are the same, the route information included in the received BGP update message is determined. Adding to the VRF table having an export RT value that matches the RT value; If the RT value included in the received BGP update message and the RT value recorded in the VPN route request option field added to the BGP route update message are not the same as the result of the determination, the import RT of another VRF table managed by the home country is not identical. Retrieving a value to determine whether a VRF table with an imported RT value that matches the RT value included in the received BGP update message exists; If there is a VRF table having an import RT value corresponding to the RT included in the received BGP update message as a result of the determination, the path of the VRF table searched based on the path information included in the received BGP update message The VMP group path information collection method of the VPMP VPS network, characterized in that the step of updating the information.