WO2007030988A1 - A method for implementing bi-directional traffic engineering tunnel and the system as well as the router thereof - Google Patents

Abstract

A method for implementing bi-directional traffic engineering tunnel includes: when two routers establish traffic engineering TE unidirectional tunnels destined for the opposite side respectively, the binding object is configured; both sides send the configured binding object information to the opposite side respectively; the router binds the unidirectional tunnels destined for the opposite side which is established respectively by both sides to bi-directional tunnel according to the received binding object information. The present invention also provides a system and a router for implementing bi-directional traffic engineering tunnel. The bi-directional tunnel of the present invention could not only support all the original service application of RSVP-TE, but also provide layer 3 virtual private network VPN service easily like general route encapsulation GRE tunnel, wherein the VPN has bandwidth guarantee and TE attribute.

Description

 TECHNICAL FIELD The present invention relates to the field of communications, and in particular, to a method, system, and router for implementing a bidirectional traffic engineering tunnel.

Background technique

The RSVP-TE (Resource Reservation Protocol-Traffic Engineering) protocol is an extension of the traditional RSVP protocol for MPLS/IP (Multi-Protocol Label Switch/Internet Protocol). Protocol) Traffic engineering is implemented in the network. As a label distribution protocol, RSVP-TE can establish a tunnel based on constraint routing and reserve bandwidth for the tunnel. In addition, the RSVP-TE FRR (Fast Renewedly Route) mechanism and the LSP (Label Switching Path, Label Switching Path) backup mechanism ensure the reliability of the TE tunnel.

 However, since the tunnel established by RSVP-TE is unidirectional, it is not possible to build an L3 VPN by policy routing or virtual router technology just like a GRE tunnel. It must also be combined with RFC 2547bis MPLS / BGP VPN (Multiprotoco Label Switching/ Border Gateway). Protocol VPN, Multi-Protocol Label Switching/Border Gateway Protocol (VPN) technology combines to provide bandwidth-guaranteed VPN services. Therefore, the implementation and configuration are more complicated, and the routing devices at both ends of the tunnel need to support MP-BGP (Multi-Protocol BGP) to exchange VPN routes, labels, and other VPN attributes, and compare the requirements of PE (Provider Edge router) devices. high.

Summary of the invention

 The main purpose of the present invention is to provide a method for implementing a bidirectional traffic engineering tunnel, which overcomes the shortcomings of the prior art that only one-way tunnel can be established through RSVP-TE, so that the VPN service with bandwidth guarantee is complicated to implement. Effectively provide L3 VPN services with bandwidth guarantees.

 Another object of the present invention is to provide a system for implementing a bidirectional traffic engineering tunnel to establish a bidirectional TE tunnel to provide L3 VPN services with bandwidth guarantee.

Another object of the present invention is to provide a router for implementing a bidirectional traffic engineering tunnel, To support the establishment of a bidirectional TE tunnel with other routers to provide service quality assurance for L3 VPN services.

 To this end, the present invention provides the following technical solutions:

 A method for implementing a bidirectional traffic engineering tunnel includes:

 A. When two routers establish a TE one-way tunnel whose destination is the other party, configure the binding object.

 B. Each party sends the configured binding object information to the other party;

 C. The router binds the TE unidirectional tunnel whose destination is established to each other to the bidirectional tunnel according to the received binding object information.

 The step B specifically includes:

 Extend the RSVP-TE protocol to increase the binding object information;

 The local router sends the configured binding object information to the peer router through the path message of the RS VP-TE protocol.

 Optionally, the step C includes:

 Cl, the peer router binds the tunnel established by the local router to the tunnel established by the local router according to the binding object information in the received path message;

 After the binding is successful, the Resv message is sent to the local router, and the binding object information constructed by the Resv message is carried in the Resv message;

 C3. The local router binds the tunnel established by the peer router to the tunnel established by the peer router according to the binding object information in the received Resv message.

 The step C1 includes:

 After receiving the path message, the peer router checks whether the binding object information in the path message meets the condition;

 If the condition is met, the tunnel established by the local router is bound to the tunnel of the local router as a Han tunnel, and the binding is considered successful.

 If the condition is not met, the binding is considered to have failed.

The step C further includes: If the peer router fails to bind the tunnel, the Resv message is sent to the local router, and the binding object information is not carried in the Resv message.

 The binding object information includes: a name of the peer TE tunnel to be bound, a destination address of the session object, and a source address.

 The step of checking whether the binding object information in the path message satisfies a condition includes:

 The peer router checks whether the name of the peer TE tunnel to be bound in the binding object is consistent with the name of the locally established TE tunnel, if it is consistent; whether the destination address of the session object is a locally established TE tunnel Source address of the session object; whether the source address of the session object is the destination address of the locally established TE tunnel;

 If the name of the peer TE tunnel to be bound is the same as the name of the locally established TE tunnel, and the destination address of the session object is the source address of the locally established TE tunnel, and the source address of the session object is local. The destination address of the established TE tunnel determines that the binding object information satisfies the condition.

 The binding element further includes: a binding flag.

 In the step C2, after the binding is successful, when the Resv message is sent to the local router, the binding flag in the binding object information in the Resv message is set as a confirmation flag, and the distribution label is set to Ordinary label.

 The step C3 includes:

 After receiving the Resv message, the local router checks whether the binding object information in the Resv message satisfies the condition;

 If the condition is met, the tunnel established by the peer router is bound to the tunnel of the peer router as a bidirectional tunnel, and the bidirectional tunnel is successfully bound; if the condition is not met, the connection is considered to be tied. Definitely failed.

 The step of the local router checking whether the binding object information in the Resv message satisfies the condition includes:

The local router checks whether the name of the peer TE tunnel to be bound in the binding object is the name of the tunnel established by the peer; and checks whether the binding flag in the binding object is an acknowledged flag. Optionally, the step C includes:

 The peer router binds the tunnel established by the local router to the tunnel established by the local router according to the binding object information in the received path message;

 After the binding is successful, the Resv message is sent to the local router; otherwise, the local router responds with an error alarm message.

 A system for implementing a two-way traffic engineering tunnel includes: a carrier edge router and a core router connected through an IP network, and routing and forwarding by a core router, and a TE one-way tunnel is established between edge routers of different operators according to the RVSP-TE protocol, where The carrier edge router includes:

 a TE tunnel establishing module, configured to establish a TE unidirectional tunnel according to the RVSP-TE protocol, and a binding object configuration module, connected to the TE tunnel establishing module, configured to establish, according to the TE tunnel, a TE unidirectional tunnel information Configure the local carrier edge router bidirectional tunnel binding object.

 The tunnel binding module is connected to the TE tunnel establishment module, and is configured to: according to the binding object information of the peer carrier edge router received by the local carrier edge router, the local carrier edge router and the peer carrier edge The unidirectional tunnels established by the routers to each other are bound to be two-way tunnels.

 Preferably, the carrier edge router further includes:

 The binding object checking module is respectively connected to the TE tunnel establishing module and the tunnel binding module, and is configured to check, according to the information of the TE unidirectional tunnel established by the TE tunnel establishing module, the pair received by the operator edge router. Whether the binding object information of the edge carrier edge router satisfies the condition, and sends the check result to the tunnel binding module.

 The local carrier edge router sends the configured local carrier edge router bidirectional tunnel binding object information to the peer carrier edge router through the path message in the extended RVSP-TE protocol.

All core routers between the local carrier edge router and the peer carrier edge router transmit the binding object information transmitted between the local carrier edge router and the peer carrier edge router as they are. After the two-way tunnel is successfully bound, the local carrier edge router sends the binding success information to the peer carrier edge router through the Resv message in the extended RVSP-TE protocol.

 A router for implementing a bidirectional traffic engineering tunnel, configured to establish a bidirectional TE tunnel with a peer router, where the router includes:

 a TE tunnel establishing module, configured to establish a TE unidirectional tunnel according to the RVSP-TE protocol, and a binding object configuration module, connected to the TE tunnel establishing module, configured to establish, according to the TE tunnel, a TE unidirectional tunnel information Configure a bidirectional tunnel binding object.

 The tunnel binding module is connected to the TE tunnel establishment module, and is configured to bind the unidirectional tunnel that is established by the local router and the peer router to each other according to the binding object information of the peer router received by the router. Set as a two-way tunnel.

 Preferably, the router further includes:

 The binding object checking module is respectively connected to the TE tunnel establishing module and the tunnel binding module, and is configured to check, according to the information of the TE unidirectional tunnel established by the TE tunnel establishing module, the peer router received by the router. Whether the binding object information satisfies the condition, and sends the check result to the tunnel binding module.

 According to the technical solution provided by the present invention, in the present invention, when the two routers configure the RSVP-TE protocol on the unidirectional tunnel where the destination is the peer, the RSVP-TE extension is bound. The object is bound, and the unidirectional tunnel whose destination is established by the two parties is bound. The bidirectional tunnel established in the present invention can not only support all the original service applications of RSVP-TE, but also provide L3 VPN services with bandwidth guarantee through virtual router technology or policy routing technology.

BRIEF DESCRIPTION OF DRAWINGS FIG. 1 is a flowchart of an implementation of a method for implementing a bidirectional traffic engineering tunnel according to the present invention;

 2 is a flowchart of implementing tunnel binding by a router according to binding object information in the method of the present invention;

 3 is a schematic diagram of a virtual router implemented by a RSVP-TE bidirectional tunnel; FIG. 4 is a schematic block diagram of a first embodiment of a router according to the present invention;

 5 is a schematic block diagram of a second embodiment of a router according to the present invention;

Figure 6 is a schematic block diagram of the system of the present invention. The core of the present invention is to refer to the GRE bidirectional tunnel implementation mechanism, and configure a binding object when each of the two routers establishes a traffic engineering TE one-way tunnel destined for the other party, and then each of the two parties will configure the binding object. The information is sent to the other party; the router ^^ receives the binding object information and binds the unidirectional tunnel whose destination is established by the Hanfang to the other party as a two-way tunnel.

 In order to enable each of the routers to learn the TE tunnel to be bound, the present invention extends the existing RSVP-TE protocol. Add a new binding object (Binding Object), define ^ under:

 Class = TBD (not yet defined), C_ Type = TBD (not yet defined)

 0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+

I Reserved | flag | Name Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+ II

II Session Name (NULL padded display string) II

I I

 +-4—+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+ where,

 Reserved: 16-bit reserved field, must be 0.

 Flag: 8-bit flag field, currently defined as follows:

 0x1 requires a binding flag, valid only in the Path message;

 0x2 Binding successful acknowledgement, valid only in Resv messages.

 Name Length: The length of the Session name.

 Session Name: Name of the peer RSVP tunnel to be bound.

 Of course, the definition of the binding object is not limited to the above format, and can also be set in the actual application.

After the extended RSVP-TE protocol is used, after the local router establishes the traffic engineering TE unidirectional tunnel, the binding information of the RSVP-TE protocol is sent to the peer router through the path message of the RSVP-TE protocol. The end router binds the tunnel established by the local router to the tunnel established by the local router as a bidirectional tunnel according to the binding object information, thereby implementing a bidirectional TE tunnel. In order to make those skilled in the art better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

 Figure 1 shows the implementation flow of the method of the present invention, including the following steps:

 Step 101: When two routers respectively establish a traffic engineering TE one-way tunnel whose destination is the other party, configure a binding object.

 Assume that the local router is R1 and the peer router is R2.

 After the RSVP configuration of Tunnel A is configured on R1, the binding object is configured, and the binding elements in the binding object are configured. The binding element includes the name of the remote RSVP-TE tunnel to be bound. The destination address and the source address are three types of information. In this case, the name of the peer TE tunnel to be bound is Tunnel B. The source address of the Session Object carried in the RSVP packet is Tunnel A. Address, destination address is the address of Tunnel B. Of course, the binding elements are not limited to the above triples.

 At the same time, the peer R2 needs to be configured similarly, that is, the name of the peer TE tunnel to be bound is Tunnel A. The source address of the session object is the address of Tunnel B, and the destination address is the address of Tunnel A.

 According to 102, the two parties respectively send the configured binding object information to the other party.

 After R1 completes the existing RSVP configuration and binding object configuration of Tunnel A, it sends a Path message to the peer R2. The message carries the newly extended Binding Object. The Session Name of the Object is the corresponding TE of the peer router. The name of the tunnel, the length is the length of the Name; the binding flag of the flag field in the Bindding Object is set to 1.

 Step 103: The router binds the unidirectional tunnel that is established by the two parties to each other as a bidirectional tunnel according to the received binding object information.

 The following takes R1 as the RSVP packet to R2 as an example. The process of binding Tunnel A to Tunnel B established on the R2 is described in detail.

 Referring to FIG. 2, the process of tunnel binding performed by the router according to the binding object information in the method of the present invention includes the following steps:

 Step 201: Router R1 sends a path message to router R2, where the message carries the binding object information configured by R1.

Step 202: After R2 connects to the path message sent by JRJL, check the binding object in the message. Whether each element in -8- satisfies the condition. If all of the conditions are satisfied, the process proceeds to step 203; otherwise, the process proceeds to step 204.

 Step 203: Bind the tunnel established by the peer end to the tunnel established by itself, and construct a Resv message, and then respond to R1.

 Step 204: Respond to the Resv message to R1, and do not carry the binding object in the Resv message. After R2 receives the path message sent by R1, according to the Session Object and the Binding Object in the message, check whether the following conditions are all met: the destination address and the source address are taken as an example. The process of checking whether each binding element in the path message satisfies the condition is as follows:

 Whether the name of the RSVP tunnel to be bound in the binding object in the R2 check message is the same as the name of the RSVP tunnel established locally. If the value is the same, the condition is met; otherwise, the condition is not met.

 R2 checks whether the destination address of the Session Object in the binding object in the path message is the source address of the RSVP tunnel established locally, and if yes, the condition is met; otherwise, the condition is not met;

R2 checks whether the source address of the Session Object in the binding object in the path message is the destination address of the locally established RSVP tunnel. If yes, the condition is met; otherwise, the condition is not met.

 If all of the above conditions are met, R2 considers that the received TunnelA message is required to bind TunnelA and TunnelB to a bidirectional tunnel. The tunnel established by the peer is bound to the tunnel established by itself and is as follows. Construct a Resv message:

 Setting a binding object in the Resv message, and setting the name of the peer TE tunnel to be bound in the binding object to the name of the unidirectional tunnel established by R2, and setting the binding flag of the flag field as the confirmation flag; Moreover, the IMPLICIT NULL label that requires the penultimate hop to pop up is no longer distributed, and the distribution label is set to the normal label.

 The Resv message after the above configuration is returned to R1.

 If one of the above conditions is not met, R2 ignores the binding object and responds to the Resv message to R1. The Resv message does not carry the binding object.

Step 205: After receiving the Resv message, the R1 confirms that the peer R2 has successfully bound the tunnel established by the local end. If the confirmation is successful, proceed to step 206; otherwise, 6 000962

—— 9 one

Return to step 201.

 After receiving the Resv message, the R1 analyzes the message. If the message is not carried, the device confirms that the bidirectional tunnel is not bound successfully. Otherwise, check the binding object to be bound in the binding object carried in the message. Whether the name of the peer TE tunnel is the name of the tunnel established by the peer, and whether the binding flag in the binding object carried in the message is a confirmation flag. If both conditions are met, it is confirmed that the bidirectional tunnel binding is successful; otherwise, the Han tunnel is considered to be unbound successfully.

 Step 206, the process ends.

 The remote R2 sends an RSVP packet to R1. The process of binding the tunnel B to the local device R1 is similar to the local R1.

 When both R1 and R2 are successfully bound and confirmed by the peer, the entire bound RSVP tunnel is established.

 In the above process, the Resv message may not be extended, that is, it does not carry the binding object information of R2. If R2 successfully binds the tunnel established by the peer to the tunnel established by itself, it responds to the Resv message to R1; otherwise, it responds to R1 with an error alarm.

If

 It can be seen from the above specific embodiment of the present invention that after RSVP-TE is extended by the protocol, RSVP-TE integrates the bidirectional tunnels of GRE and IPsec based on the existing advantages of QoS, TE and reliability. The advantages.

 The RSVP-TE bidirectional tunneling technology provided by the present invention can support all the service applications supported by the GRE tunnel in addition to the original RSVP-TE service application, for example, the virtual router function and the outer tunnel as the MPLS VPN. , and interconnecting two separate routing domains through tunnels, and so on. L3 VPN services can be easily provided through virtual routers or policy routing. This L3VPN technology combines RSVP-TE QoS (Quality of Service) guarantee, TE and reliability advantages, and GRE bidirectional tunnels to facilitate the establishment of VPNs.

 The following uses the virtual router function as an example to briefly explain how to use the RSVP-TE bidirectional tunnel.

The principle of realizing the virtual router by using the RSVP-TE bidirectional TE tunnel technology is shown in Figure 3. Two virtual router instances VRF Red and VRF are established on the routers PE-1 and PE-2 respectively. Blue. PE-1 and PE-2 are connected to the CE (Customer Edge) device CE-1 and CE-2 interfaces to the virtual router instances VRF Red and VRF Blue. Bind the two-way TE tunnels, Tunnel 1 and Tunnel 2, between PE-1 and PE-2, and bind the virtual router instances VRF Red and VRF Blue respectively. Configure static routes or dynamic routes on the virtual router instance to access the two. The CE devices of the same virtual router instance on the PE devices can access each other.

 Referring to FIG. 4, FIG. 4 is a schematic block diagram of a first embodiment of a router according to the present invention. The router SO is configured to establish a bidirectional TE tunnel with the peer router, including: a TE tunnel establishment module S1, a binding object configuration module S2, and a tunnel binding. Set module S3. The TE tunnel establishment module S1 is configured to establish a TE unidirectional tunnel according to the RVSP-TE protocol. The binding object configuration module S2 is connected to the TE tunnel establishment module S1, and is used to establish the TE unidirectional tunnel information established by the module S1 according to the TE tunnel. The bidirectional tunnel binding object is configured. The tunnel binding module S3 is connected to the TE tunnel establishment module S1, and is configured to establish a destination of the local router SO and the peer router according to the binding object information of the peer router received by the router SO. The unidirectional tunnel of the other party is bound as a bidirectional tunnel.

 When the router S0 establishes the TE unidirectional tunnel, the binding object configuration module S2 configures the binding object, and the router S0 sends the binding object to the peer through the path message in the extended RVSP-TE protocol. The router carries the binding object information in the path message.

 Similarly, when the peer router establishes the TE unidirectional tunnel destined for the local router S0, it also needs to configure the binding object, and send the configured binding object to the local router through the path message in the extended RVSP-TE protocol. .

 In this way, after the local router so receives the path message of the peer router, the tunnel binding module S3 can establish the destination established by the local router S0 and the peer router according to the binding object information carried in the path message. The unidirectional tunnel is bound as a two-way tunnel.

 Similarly, after the peer router receives the path message of the local router S0, the processing procedure is the same as that described above, and details are not described herein again.

In order to ensure the accuracy of the bidirectional tunnel bound by the router, the binding object checking module S4 can also be set in the router S0. Referring to FIG. 5, the block diagram of the second embodiment of the router of the present invention is provided. The binding object checking module S4 is connected to the TE tunnel establishing module S1 and the tunnel binding module S3, and is configured to check the binding object of the peer router received by the router SO according to the information of the TE unidirectional tunnel established by the TE tunnel establishing module S1. Whether the information satisfies the condition, and sends the check result to the tunnel binding module S3.

 After the router SO receives the path message of the peer router, the binding object checking module S4 checks whether the binding object information carried by the path message satisfies the condition. The specific checking process is as follows: Check the binding object in the binding message to be tied. Whether the name of the remote RSVP tunnel is the same as the name of the locally established RSVP tunnel. Check whether the destination address of the Session Object in the binding object is the source address of the locally established RSVP tunnel. Check the binding object in the path message. Whether the source address of the object is the destination address of the locally established RSVP tunnel.

 If the name of the remote RSVP tunnel to be bound is the same as the name of the locally established RSVP tunnel, and the destination address of the Session Object is the source address of the locally established RSVP tunnel, and the source address of the Session Object is the locally established RSVP tunnel. The destination address is considered to satisfy the condition, and the tunnel module is notified to bind the tunnel established by the peer router to the tunnel established by itself to be a bidirectional tunnel.

 After the tunnel is successfully bound, the local router can send the binding success flag to the peer router through the extended Resv message. Of course, the Resv message can be extended. After the tunnel is successfully bound, the Resv message is sent directly to the peer router. After the failure, the binding failure message is sent to the peer router. For a specific process, reference may be made to the previous description of the method of the present invention, and details are not described herein again.

 Referring to Figure 6, Figure 6 shows a block diagram of the system of the present invention:

 The system includes: a carrier edge router PE1, a PE2, and a core router RT connected through an IP network. The routers of the edge routers PE1 and PE2 establish a TE unidirectional tunnel according to the RVSP-TE protocol.

 The structure of the operator edge router is the same as that described above for the router of the present invention, and details are not described herein again.

When a bidirectional TE tunnel needs to be established between PE1 and PE2, PE1 and PE2 are respectively configured to establish a tunnel unidirectional tunnel with the destination address being the peer address according to the RVSP-TE protocol. For example, the tunnel established by PE1 is Tunnel 1 and the tunnel established by PE2. For Tunnel 2. Completed in the TE one-way tunnel Then, PE2 and PE2 are configured with their respective binding objects. The binding object includes: the name of the peer TE tunnel to be bound, the destination address and source address of the session object. For example, in the configuration, the binding object information of PE1 is: The name of the peer TE tunnel to be bound is Tunnel 2, the destination address of the session object is the source address of Tunnel 2, and the source address is the destination address of Tunnel 2. The binding object information of PE2 is: The name of the peer TE tunnel to be bound is Tunnel 1, the destination address of the session object is the source address of Tunnel 1, and the source address is the destination address of Tunnel 1.

 Then, the PE1 sends the configured binding object information to the PE2 through the path message in the extended RVSP-TE protocol, where the binding object carries the binding object information. Similarly, PE2 needs to send the configured binding object information to PE1 through the path message in the extended RVSP-TE protocol. When the path message is sent, the core router RT between PE1 and PE2 transmits the binding object information as it is.

 In this way, after receiving the path message of the PE2, PE1 can bind Tunnel 2 and Tunnel 1 as a bidirectional tunnel according to the binding object information carried in the path message. Similarly, after receiving the path information of PE1, PE2 can bind Tunnel 1 and Tunnel 2 as a bidirectional tunnel according to the binding object information carried in the path message. After the tunnel is successfully bound to the tunnel, the Resv message can be returned to the peer router to notify the peer router that the bidirectional tunnel binding is successful.

 It can be seen that with the system of the present invention, it is convenient to provide an L3 VPN that combines the QoS guarantee of RSVP-TE, the TE and reliability advantages, and the bidirectional tunnel to facilitate the establishment of a VPN advantage.

 The foregoing is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. For example, the binding element of the present invention is not limited to the tunnel name, the source address, and the destination address triplet. The practice of binding two unidirectional tunnels into two-way tunnels through other binding elements is any change or replacement that can be easily conceived by those skilled in the art within the scope of the technology disclosed by the present invention. Within the scope of protection of the invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

Rights request  A method for implementing a bidirectional traffic engineering tunnel, comprising:  A. When two routers establish a TE one-way tunnel whose destination is the other party, configure the binding object.  B. Each party sends the configured binding object information to the other party;  C. The router binds the TE unidirectional tunnel whose destination is established to each other to the bidirectional tunnel according to the received binding object information.  The method for implementing the bidirectional traffic engineering tunnel according to claim 1, wherein the step B specifically includes:  Extend the RSVP-TE protocol to increase the binding object information;  The local router sends the configured binding object information to the peer router through the path message of the RSVP-TE protocol.  The method of implementing a traffic engineering tunnel according to claim 2, wherein the step C comprises:  Cl, the peer router binds the tunnel established by the local router to the tunnel established by the local router according to the binding object information in the received path message;  After the binding is successful, the Resv message is sent to the local router, and the binding object information constructed by the Resv message is carried in the Resv message;  C3. The local router binds the tunnel established by the peer router to the tunnel established by the peer router according to the binding object information in the received Resv message.  The method for implementing a bidirectional traffic engineering tunnel according to claim 3, wherein the step C1 comprises:  After receiving the path message, the peer router checks whether the binding object information in the path message meets the condition;  If the condition is met, the tunnel established by the local router is bound to the tunnel of the local router as a bidirectional tunnel, and the binding is considered successful; If the condition is not met, the binding is considered to have failed. The method for implementing a bidirectional traffic engineering tunnel according to claim 4, wherein the step C further comprises:  If the peer router fails to bind to the tunnel, the Resv message is sent to the local router, and the binding object information is not carried in the Resv message.  The method for implementing a bidirectional traffic engineering tunnel according to claim 4, wherein the binding object information comprises:  Name of the peer TE tunnel to be bound, the destination address of the session object, and the source address.  The method for implementing the bidirectional traffic engineering tunnel according to claim 6, wherein the step of checking whether the binding object information in the path message satisfies the condition comprises: the peer router checking the binding Whether the name of the peer TE tunnel to be bound in the fixed object is consistent with the name of the locally established TE tunnel, if it is consistent; whether the destination address of the session object is the source address of the locally established TE tunnel; the source address of the session object Whether it is the destination address of the locally established TE tunnel;  If the name of the peer TE tunnel to be bound is the same as the name of the locally established TE tunnel, and the destination address of the session object is the source address of the locally established TE tunnel, and the source address of the session object is local. The destination address of the established TE tunnel determines that the binding object information satisfies the condition.  The method for implementing a bidirectional traffic engineering tunnel according to claim 6, wherein the binding element further comprises: a binding flag.  The method for implementing the bidirectional traffic engineering tunnel according to claim 8, wherein in the step C2, after the binding is successful, when the Resv message is sent to the local router, the Resv message will be in the Resv message. The binding flag in the carried binding object information is set as a confirmation flag, and the distribution label is set to a normal label.  The method for implementing a bidirectional traffic engineering tunnel according to claim 3, wherein the step C3 comprises:  After receiving the Resv message, the local router checks whether the binding object information in the Resv message satisfies the condition; If the condition is met, the tunnel established by the peer router is bound to the tunnel of the peer router as a bidirectional tunnel, and the Han tunnel is successfully bound. If the condition is not met, the binding is considered to have failed.  The method for implementing the bidirectional traffic engineering tunnel according to claim 10, wherein the step of the local router checking whether the binding object information in the Resv message satisfies the condition comprises:  The local router checks whether the name of the peer TE tunnel to be bound in the binding object is the name of the tunnel established by the peer; and checks whether the binding flag in the binding object is an acknowledged flag.  The method for implementing a Han-directional traffic engineering tunnel according to claim 2, wherein the step C comprises:  The peer router binds the tunnel established by the local router to the tunnel established by the local router according to the binding object information in the received path message;  After the binding is successful, the Resv message is sent to the local router; otherwise, the local router responds with an error alarm message.  13. A system for implementing a bidirectional traffic engineering tunnel, comprising: a carrier edge router and a core router connected through an IP network, and routing and forwarding through a core router, and establishing a TE unidirectional tunnel according to the RVSP-TE protocol between different operator edge routers The carrier edge router includes:  a TE tunnel establishing module, configured to establish a TE unidirectional tunnel according to the RVSP-TE protocol, and a binding object configuration module, connected to the TE tunnel establishing module, configured to establish, according to the TE tunnel, a TE unidirectional tunnel information Configure the local carrier edge router bidirectional tunnel binding object.  The tunnel binding module is connected to the TE tunnel establishment module, and is configured to: according to the binding object information of the peer carrier edge router received by the local carrier edge router, the local carrier edge router and the peer carrier edge The unidirectional tunnels established by the routers to each other are bound to be two-way tunnels.  The system for implementing a bidirectional traffic engineering tunnel according to claim 13, wherein the carrier edge router further comprises: a binding object checking module, respectively, the TE tunnel establishing module and the tunnel binding module The block is connected to check whether the binding object information of the peer carrier edge router received by the operator edge router meets the condition according to the information of the TE unidirectional tunnel established by the TE tunnel establishment module, and sends the check result to the check result. The tunnel binding module.  The system for implementing a bidirectional traffic engineering tunnel according to claim 13, wherein the local carrier edge router binds the configured local carrier edge router to the tunnel through the path message in the extended RVSP-TE protocol. The information is sent to the peer carrier edge router.  16. The system for implementing a bidirectional traffic engineering tunnel according to claim 15, wherein all core routers between the local carrier edge router and the peer carrier edge router are paired with the local carrier edge router and the peer carrier. The binding object information transmitted between the edge routers is transmitted as it is.  The system for implementing the bidirectional traffic engineering tunnel according to claim 13, wherein after the bidirectional tunnel is successfully bound, the local operator edge router determines the binding success information by using the Resv message in the extended RVSP-TE protocol. Send to the peer carrier edge router.  A router for implementing a bidirectional traffic engineering tunnel, configured to establish a Han tunnel with the peer router, wherein the router includes:  a TE tunnel establishing module, configured to establish a TE unidirectional tunnel according to the RVSP-TE protocol, and a binding object configuration module, connected to the TE tunnel establishing module, configured to establish, according to the TE tunnel, a TE unidirectional tunnel information Configure a bidirectional tunnel binding object.  The tunnel binding module is connected to the TE tunnel establishment module, and is configured to bind the unidirectional tunnel that is established by the local router and the peer router to each other according to the binding object information of the peer router received by the router. Set as a two-way tunnel.  The router for implementing a bidirectional traffic engineering tunnel according to claim 18, wherein the router further comprises:  The binding object checking module is respectively connected to the TE tunnel establishing module and the tunnel binding module, and is configured to check, according to the information of the TE unidirectional tunnel established by the TE tunnel establishing module, the peer router received by the router. Whether the binding object information satisfies the condition, and sends the check result to the tunnel binding module.