CN103368842A

CN103368842A - Method and system for establishing MS-PW

Info

Publication number: CN103368842A
Application number: CN2012101033198A
Authority: CN
Inventors: 王其磊
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2012-04-10
Filing date: 2012-04-10
Publication date: 2013-10-23

Abstract

The invention discloses a method and system for establishing MS-PW. The method and system enable objects of an RSVP-TE to be extended and information which is needed to establish the MS-PW to be carried by the extended objects; and nodes which are passed by by the MS-PW completes the establishment of the end-to-end MS-PW according to the information which is needed to establish the MS-PW, carried in the extended objects. Compared with a currently applied LDP, in a technology for establishment of the MS-PW, the RSVP-TE has a traffic engineering advantage when a routing is established and better routing control can be provided so that establishment of an MS-PW routing can be supported by the RSVP-TE. Through extension of current objects of the RSVP-TE, the information which is needed to establish the MS-PW is carried so that the establishment of the end-to-end MS-PW is completed.

Description

Method and system for establishing multi-segment pseudo wire

Technical Field

The invention relates to the field of communication, in particular to a method and a system for establishing a multi-segment pseudo wire.

Background

Pseudo Wire Emulation Edge-to-Edge (Pseudo Wire Emulation Edge-to-Edge) is a mechanism for emulating the basic attributes of services such as ATM, frame relay, ethernet, etc., over a Packet Switched Network (PSN). Through the mechanism, an operator bears various different services on a single network technology, so that the operation cost can be reduced, and the income of the operator can be increased.

The IETF PWE3 working group describes the encapsulation, transport, control, management, interworking of various services over PSNs and the security of the services by emulating them using the signaling, routing mechanisms existing in IETF.

Pseudowires (PW) take two forms: single segment pseudowires (SS-PW) and multi-segment pseudowires (MS-PW). Pseudowires established directly between two operator edge node (PE) nodes are referred to as single-segment pseudowires, which typically exist in only one area. As networks evolve, operators desire to provide services that span multiple areas, in which case multi-segment pseudowires are present.

The existing method for establishing the pseudo wire is to establish the pseudo wire through an LDP (Label distribution protocol), still use the LDP to establish a single segment pseudo wire in a scene of a multi-segment pseudo wire, and then connect each segment of pseudo wire to form an end-to-end multi-segment pseudo wire. The method for establishing the multi-segment pseudo wire obviously has no traffic engineering advantages, but RSVP-TE (Resource reservation protocol) with the traffic engineering advantages cannot be applied to the establishment of the multi-segment pseudo wire at present.

Disclosure of Invention

In view of the above, the primary objective of the present invention is to provide a method and system for establishing multi-segment pseudowires, so that RSVP-TE with traffic engineering advantages can be applied to the establishment of multi-segment pseudowires.

In order to achieve the purpose, the technical scheme of the invention is realized as follows:

a method of establishing a multi-segment pseudowire, comprising:

expanding an object of a resource reservation protocol RSVP-TE, wherein the expanded object is applied to carry information required for establishing a multi-segment pseudo wire MS-PW; and the node through which the MS-PW passes completes the establishment of the end-to-end multi-segment pseudo wire according to the information carried in the extended object and required for establishing the MS-PW.

The extended objects include:

SESSION OBJECT, SENDER template OBJECT SENDER _ template _ HOP OBJECT, resource reservation protocol HOP OBJECT RSVP _ HOP OBJECT, FILTER description OBJECT FILTER _ SPEC OBJECT, tag REQUEST OBJECT LABEL _ REQUEST OBJECT.

The SESSION OBJECT is used for identifying the data flow of the pseudo wire;

the SENDER _ TEMPLATE OBJECT is used to identify SENDER information, i.e. information of the terminal operator edge node T-PE, in a PATH (PATH) message;

the RSVP _ HOP is used for carrying the address of the previous HOP of T-PE/exchange operator edge node S-PE in the PATH message and carrying the address of the next HOP of T-PE/S-PE in the reserved RESV message;

the FILTER _ SPEC has the same format as SENDER _ TEMPLATE and is used for carrying SENDER information in a RESV message;

the LABEL _ REQUEST is used for carrying tag REQUEST information.

When a pseudo wire is viewed as a layer network, the RSVP _ HOP also indicates a specific tunnel which is used by a transmission plane and bears the pseudo wire; when a pseudo wire is not seen as a layer network, determining that the RSVP _ HOP does not need to be associated with specific tunnel information;

the LABEL _ REQUEST is also used for indicating whether the PW is used as a layer network or not through information carried by the LABEL _ REQUEST.

The object further comprises at least one of:

the expanded notification Request NOTIFY Request is used for carrying node information of the T-PE/S-PE needing to NOTIFY the path failure and information needing to be notified;

the extended interface identifier ERROR description IF _ ID ERROR _ SPEC is used for identifying node information of the S-PE/T-PE with the fault and fault information;

the newly added Interface parameter is used for carrying Interface parameters;

a newly added PW group Grouping used for representing the grouped PW;

the expanded explicit routing object ERO is used for supporting carrying of T-PE/S-PE information passing through in the route building process;

and the expanded recording type route object RRO is used for supporting the recording of the information of the T-PE/S-PE passed in the route building process.

When the node through which the MS-PW passes is the first node, the first node fills a PATH PATH message by using the expanded object, uniquely identifies the establishment of a pseudo wire, and writes the address information of the sender node into the object of the previous hop node; the first node sends the PATH message after the message is constructed and prepares a tunnel for supporting the multi-segment pseudowire.

When the node where the MS-PW passes through is an intermediate node, the intermediate node receives the PATH message filled by the expanded object and sends the built new PATH message to the next hop node; the intermediate node also prepares a tunnel for supporting the multi-segment pseudowire.

When the node where the MS-PW passes through is a tail node, the tail node fills the RESV message by using the expanded object, reserves resources for supporting the multi-segment pseudo wires and uniquely identifies the establishment of one pseudo wire; the tail node also sends the encapsulated RESV message to the previous hop node.

A system for establishing a multi-segment pseudo wire comprises an object extension unit and an MS-PW establishing node; wherein,

the object expanding unit is used for expanding an object of RSVP-TE, and the expanded object is applied to carry information required for establishing MS-PW;

and the MS-PW establishing node is used for completing the establishment of the end-to-end multi-segment pseudo wire according to the information carried in the expanded object and required for establishing the MS-PW.

The extended objects include:

SESSION OBJECT、SENDER_TEMPLATE OBJECT、RSVP_HOP OBJECT、FILTER_SPEC OBJECT、LABEL_REQUEST OBJECT。

the SESSION OBJECT is used for identifying the data flow of the pseudo wire;

the SENDER _ TEMPLATE OBJECT is used for identifying SENDER information, namely information of a T-PE (transmission end) at a PATH (PATH) message;

the RSVP _ HOP is used for carrying the address of the previous HOP of T-PE/S-PE in the PATH message and carrying the address of the next HOP of T-PE/S-PE in the RESV message;

the LABEL _ REQUEST is used for carrying tag REQUEST information.

When a pseudowire is viewed as a layer network, the RSVP _ HOP is also used for indicating a specific tunnel which is used by a transport plane and bears the pseudowire; when a pseudo wire is not seen as a layer network, determining that the RSVP _ HOP does not need to be associated with specific tunnel information;

The object further comprises at least one of:

the expanded NOTIFY Request is used for carrying node information of the T-PE/S-PE needing to inform the path failure and information needing to be informed;

the extended IF _ ID ERROR _ SPEC is used for identifying node information of the S-PE/T-PE with the fault and fault information;

the newly added Interface parameter is used for carrying Interface parameters;

newly added PW Grouping used for representing grouped PWs;

the expanded ERO is used for supporting carrying of T-PE/S-PE information passing through in the route building process;

and the expanded RRO is used for supporting the recording of the information of the T-PE/S-PE passed by the route building process.

The MS-PW establishing node comprises a head node, is used for filling a PATH message by using the expanded object, uniquely identifies the establishment of a pseudo wire, and writes the address information of a sender node into a previous hop node object; the first node, after constructing the PATH message, is configured to send the message and prepare a tunnel to support the multi-segment pseudowire.

The MS-PW establishing node comprises an intermediate node and is used for receiving the PATH message filled by the expanded object and sending the new PATH message to the next hop node; the intermediate node is also configured to prepare a tunnel for supporting the multi-segment pseudowire.

The MS-PW establishment node comprises a tail node and is used for filling RESV information by using the expanded object, reserving resources for supporting the multi-segment pseudo wires and uniquely identifying the establishment of one pseudo wire; the tail node is also used for sending the encapsulated RESV message to the previous-hop node.

Compared with the LDP applied at present, the technology for establishing the multi-segment pseudo wire has the advantages of flow engineering when the RSVP-TE establishes the path, and can provide better path control, so that the RSVP-TE can support the establishment of the MS-PW path. The establishment of the end-to-end multi-segment pseudo wire is completed by expanding the existing object of RSVP-TE to carry the information required for establishing the MS-PW.

Drawings

FIG. 1 is a schematic diagram of a header format of an RSVP-TE object according to an embodiment of the present invention;

fig. 2 is an extended schematic diagram of a SESSION OBJECT according to an embodiment of the present invention;

fig. 3 is a schematic diagram illustrating a principle of an Extended Tunnel ID field in a SESSION OBJECT according to an embodiment of the present invention;

FIG. 4 is an expanded schematic diagram of a SENDER _ TEMPLATE object according to an embodiment of the invention;

fig. 5 is an extended schematic diagram of an RSVP _ HOP (resource reservation protocol HOP count) object according to an embodiment of the present invention;

fig. 6 is an extended schematic diagram of an IF _ ID RSVP _ HOP (interface identifier resource reservation protocol HOP count) object according to an embodiment of the present invention;

fig. 7 is a schematic diagram illustrating an expansion principle of ERO (EXPLICIT ROUTE Object) according to an embodiment of the present invention;

FIG. 8 is an expanded schematic diagram of an RRO (recorded routing) sub-object according to an embodiment of the present invention;

FIG. 9 is a schematic diagram illustrating an extended principle of an ERROR _ SPEC (ERROR description) object according to an embodiment of the present invention;

FIG. 10 is a schematic diagram illustrating an extended principle of an Interface parameter object according to an embodiment of the present invention;

fig. 11 is an extended schematic diagram of a Grouping ID (group identifier) object according to an embodiment of the present invention;

fig. 12 is a schematic diagram of a PW Grouping object according to an embodiment of the present invention;

fig. 13 is a schematic diagram illustrating a principle of a label _ request object when a PW is used as a layer network in the embodiment of the present invention;

fig. 14 is a schematic diagram illustrating a principle of a label _ request object when a PW is not a layer network according to an embodiment of the present invention;

FIG. 15 is a simplified flow chart for implementing multi-segment pseudowire establishment in accordance with an embodiment of the present invention;

fig. 16 is a system diagram for implementing multi-segment pseudowire establishment in accordance with an embodiment of the present invention.

Detailed Description

Compared with the LDP applied at present, the RSVP-TE has the advantages of flow engineering when establishing the path, and can provide better path control, so that the establishment of the MS-PW path can be supported by the RSVP-TE. The establishment of the end-to-end multi-segment pseudo wire is completed by expanding the existing object of RSVP-TE to carry the information required for establishing the MS-PW.

RSVP-TE is able to carry some of the traffic engineering attributes needed for road establishment, which is advantageous when building multi-segment pseudowires. In actual application, the SESSION OBJECT, SENDER _ TEMPLATE OBJECT, FILTER _ SPEC OBJECT, RSVP _ HOP OBJECT, ERO, RRO, NOTIFY REQUEST OBJECT, LABEL _ REQUEST OBJECT, IF _ ID ERROR _ SPEC OBJECT in the existing RSVP-TE may be extended; an Interfaceparameter object and a PW Grouping object can be newly defined, so that RSVP-TE can be used for establishing an end-to-end multi-segment pseudo wire, and the advantages of RSVP-TE in traffic engineering are exerted.

The objects extended in this invention are consistent with the functionality of the objects described in RFC3209/RFC 3473. The object for which extensions are made in the present invention, which relate to the extension of AII (connection identifier) addresses, is intended to facilitate the establishment of end-to-end multi-segment pseudowires using RSVP-TE.

RSVP-TE uses a Session OBJECT to identify a data flow, and can extend the SESSION OBJECT for identifying a data flow of a pseudowire. The SESSION OBJECT may be used in a Notify message, and when the Notify message is sent due to a failure, the SESSION OBJECT is used to identify the failed path.

The RSVP-TE uses the SENDER _ TEMPLATE object to identify the SENDER's information and thus can use the SENDER _ TEMPLATE object to identify the SENDER PE's information.

RSVP-TE uses a FILTER _ SPEC object in the RESV message, which has the same format as the SENDER _ TEMPLATE object and also needs to be extended.

The SENDER _ TEMPLATE object (or FILTER _ SPEC object) together with the session _ SPEC object will uniquely identify a pseudowire.

Because the T-PE (end operator edge node) and the T-PE, the T-PE and the S-PE (exchange operator edge node), and the S-PE are not in a physical neighbor relationship, when using the RSVP-TE as a signaling for establishing a pseudo wire, direct SESSIONs, i.e., Targeted RSVP-TE SESSION, need to be established between the T-PE and the T-PE, between the T-PE and the S-PE, and between the S-PE and the S-PE. In addition, since RSVP-TE is IP-based, a virtual Control Channel that can be an IP (CC) Control Channel can be established between T-PE and T-PE, T-PE and S-PE, and S-PE, and then all RSVP-TE messages related to PW are transmitted through the IPCC. When using IPCC, it needs to fill corresponding T-PE/S-PE information in RSVP _ HOP object, which is used to carry the address of the previous HOP of T-PE/S-PE in PATH message, and carry the address of the next HOP of T-PE/S-PE in RESV message. Therefore, some extensions need to be made to the RSVP _ HOP object to support carrying the address information of T-PE/S-PE. If the pseudowire is not seen as a layer network, only the extension in RFC2205 is used, that is, a tunnel used in a transport plane for carrying the pseudowire does not need to be pointed out, and a PW label does not need to be associated with a specific tunnel; IF the pseudowire is viewed as a layer network, the RSVP _ HOP needs to use the IF _ ID RSVP _ HOP object described in RFC3473, i.e., to specify the transport plane for the tunnel carrying the pseudowire, the PW label needs to be associated with the specific tunnel.

RSVP-TE supports the use of ERO to carry information of the nodes that the PATH message needs to pass through. When RSVP-TE is used to establish MS-PW, ERO needs to be expanded to support carrying T-PE/S-PE information passing through the route establishment process. For RRO, corresponding extensions are also needed to meet the above requirements.

And the RSVP-TE uses a NOTIFY Request object to identify the node needing to NOTIFY the PATH failure in the PATH message or the RESV message, and still extends the NOTIFY Request object to identify the T-PE/S-PE needing to NOTIFY the PATH failure in the process of establishing the MS-PW by using the RSVP-TE.

RSVP-TE uses the IF _ ID ERROR _ SPEC object in RFC3473 to identify the failed node. By extending the RSVP-TE IF _ ID ERROR _ SPEC object, the method is used for identifying the S-PE/T-PE with the fault.

According to RFC4447, it is necessary to use interface parameters carried in the signalling, such as Maximum Transmission Unit (MTU) information of the connection circuit. A new Interface parameter object may be defined in the object of RSVP-TE to carry the Interface parameters described above.

In RFC4447, a PW Grouping TLV (type/length/value, type-length-value) is defined to represent a group of PWs, where the PW Grouping TLV carries a PW Grouping ID, and the PW Grouping ID can identify the group of PWs, and is used to delete a plurality of established pseudowires through one signaling message. Using PW Grouping ID enables one node to send messages for label recovery while recovering labels distributed to multiple pseudowires. The PW Grouping object used to represent a grouped PW may be extended when RSVP-TE establishes a pseudowire.

Whether the PW is used as a layer network can be known according to information carried by the label _ request object. If the PW is not viewed as a layer network, the PW layer does not need to be endowed with independent exchange capability and coding type, but a mode similar to LDP for establishing MS-PW is adopted; if the PW is viewed as a layer network, the same way of establishing an LSP as in RSVP-TE described in RFC3473, a separate switching capability and coding type need to be given to the PW layer.

The expansion made in the invention is not limited to a specific expansion format, but some corresponding expansion is made according to the specific function information of the object in the prior RSVP-TE, and the expanded object carries the expansion information needed for establishing the multi-segment pseudo wire.

In actual application, each object has a 32-bit header with the same format as described in RFC2205, and the format of the header is shown in fig. 1.

Wherein the Length field identifies the total Length of the object; Class-Num (Class number) identifies each object, which is used to identify different objects such as SESSION, RSVP _ HOP, etc.; c-type (type of classification) is used to identify the specific subtype of each object, used in conjunction with Class-Num.

The extensions made to RSVP-TE are described in detail below in conjunction with the figures.

(1) Extension of SESSION OBJECT

Since RSVP-TE uses Session OBJECT to identify a data flow, the SESSION OBJECT can be extended to identify the SESSION of an end-to-end multi-segment pseudowire.

The format of the SESSION OBJECT after extension is shown in fig. 2.

Wherein the Length field, Class-Num field and C-type field are defined as the corresponding fields in the SESSION OBJECT defined in RFC3209, where a new C-type subtype (different from the type defined in RFC 3209) is defined to identify the S-PE/T-PE in the MS-PW. The other fields are defined as follows:

AGI TLV field: the AGI is defined as described in RFC4447, and the format is as defined in RFC 4447. With AGI (Attachment Group Identifier), a series of Forwarders can be treated as members of a Group. An AGI may be a VPN-id (virtual private network identifier) or a VLAN (virtual local area network) identifier. The AGI of both endpoints of a multi-segment pseudowire are the same.

Target Attachment Identifier (TAII) TLV field: to identify the destination PE. Here TAII may use the AII Type 2 Type as defined in RFC 5003.

Tunnel ID field: the Tunnel ID field is defined as described in RFC3209 to identify a session and is constant over the lifetime of the session.

Extended Tunnel ID field: a field used in the session object may be set to 0 and may also be used to identify the Source node connection identifier (Source AII) of the ingress PE, the AII format being shown in fig. 3. Here AII may use the AII Type 2 Type defined in RFC 5003.

In the MS-PW, the SAII (source node connection identifier) and TAII (destination node connection identifier) addresses use the address identifier defined in RFC 5003.

The Notify message needs to use the SESSION OBJECT, and when the Notify message is sent due to a failure, the SESSION OBJECT is used to identify the failed S-PE/T-PE.

(2) Extension of the SENDER _ TEMPLATE object

RSVP-TE identifies the SENDER's information using a SENDER _ TEMPLATE object, which in the present invention identifies the SENDER's PE's identification information; the data type in the PW payload (payload) is identified by using the extended identification bit, which may carry ethernet data, may also carry ATM data, and so on.

The expanded format of the SENDER TEMPLATE object is shown in fig. 4.

SAII TLV field: a source node connection identifier used to identify the ingress PE. Here SAII can use the AII Type 2 Type defined in RFC 5003.

PW ID field: a 16-bit identifier to identify a pseudowire.

(3) Extension of FILTER _ SPEC objects

The FILTER _ SPEC object has the same format as the SENDER _ TEMPLATE object, and is extended in the same format as in fig. 4.

(4) Extensions to RSVP _ HOP objects

Because the T-PE and the T-PE, the T-PE and the S-PE, and the S-PE are not in a physical neighbor relationship, when RSVP-TE is used as a signaling for establishing PW, direct SESSIONs, namely Targeted RSVP-TE SESSION, need to be established between the T-PE and the T-PE, between the T-PE and the S-PE, and between the S-PE and the S-PE. In addition, since RSVP-TE is IP-based, a virtual control channel that can be an IPCC can be established between T-PE and T-PE, T-PE and S-PE, S-PE and S-PE, and then all RSVP-TE messages for PW are transmitted through the IPCC. When using IPCC, RSVP _ HOP object needs to fill in corresponding T-PE/S-PE information. Here, some extensions need to be made to RSVP _ HOP object to carry address information of T-PE/S-PE.

If the pseudowire is not viewed as a layer network, only the extension of the RSVP _ HOP object in RFC2205 is used, i.e., there is no need to indicate the tunnel used in the transport plane to carry the pseudowire. The extended format of the RSVP _ HOP object is shown in fig. 5.

IF the pseudowire is viewed as a layer network, the IF _ IDRSVP _ HOP object described in RFC3473 needs to be used, i.e., a specific tunnel that indicates the pseudowire that the transport plane needs to use to carry. An extension of the IF _ IDRSVP _ HOP object is shown in fig. 6.

AII Next/Previous Hop Address field: and the address of the previous hop or the next hop T-PE/S-PE is identified in the PATH message or the RESV message. The AII address here may use an AII Type 2 Type defined in RFC 5003. For the AII type described in RFC5003, a certain T-PE/S-PE may be identified using the manner as described in the manuscript [ draft-ietf-pwe3-dynamic-ms-pw ]: if it is a T-PE, fields of Global ID (Global identifier), prefix (prefix), and AC ID (connection circuit identifier) in the AII Type 2 address need to be included to identify a specific connection circuit; if S-PE, only Global ID and prefix fields may be included.

Logical Interface Handle (Logical Interface identification) field: meaning the same as that described in RFC2205 for the corresponding fields.

TLVs field: since in GMPLS (generalized multi-protocol label switching) control plane, the control channels are separated from the transport plane channels, the transport plane channels need to be identified in the control plane signaling. The TLV format here is still as described in RFC 3471.

(5) Extension of ERO, RRO

RSVP-TE supports the use of ERO to carry node information that the PATH message needs to pass through during forwarding. When RSVP-TE is used for establishing MS-PW, ERO needs to be expanded to support carrying of T-PE/S-PE information passing through in the route establishment process.

The expansion of the sub-objects carried by the ERO is shown in fig. 7. The AII address in the object may be an AII Type 2 Type as defined in RFC 5003.

RSVP-TE uses RRO to record node information passing along the way. When using RSVP-TE to establish MS-PW, the RRO needs to be extended to support recording the information of T-PE/S-PE passed through during route establishment.

The sub-object extensions carried by RRO are shown in fig. 8. The AII address in the object may be an AII Type 2 Type as defined in RFC 5003.

(6) Extension of NOTIFY Request object

And the RSVP-TE uses the NOTIFY Request object in the PATH message or the RESV message to identify the node needing to NOTIFY the PATH failure, so that in the process of establishing the MS-PW by using the RSVP-TE, the NOTIFY Request object can be expanded to identify the T-PE/S-PE needing to NOTIFY the PATH failure.

An extension of the NOTIFY Request object is shown in FIG. 9.

The connection identifier in fig. 9 informs the node address as an AII address, which may use an AII Type 2 Type defined in RFC 5003. If the connection circuit is T-PE, fields of Global ID, prefix and AC ID in the AII Type 2 address are required to be contained for identifying a specific connection circuit; if S-PE, only Global ID and prefix fields may be included.

(7) Extension of IF _ ID ERROR _ SPEC objects

RSVP-TE uses the IF _ ID ERROR _ SPEC object in RFC3473 to identify the failed node. The RSVP-TE IF _ ID ERROR _ SPEC object may thus be extended to identify a failed S-PE/T-PE.

The expansion of the ERROR _ SPEC object is shown in fig. 10.

The definitions of Flags, Error Code, Error Value are as described in RFC 2205; the format of the TLV is shown in FIG. 6.

As described in RFC4447, section 7.2, extended Error codes have:

an illegal C bit;

an erroneous C bit;

incompatible bit rates;

error configuration of CEP-TDM;

unallocated/unidentified TAI.

(8) Extension of Interface parameter objects

According to RFC4447, interface parameters, such as Maximum Transmission Unit (MTU) information of the connection circuit, need to be carried during the use of the signaling. A new Interfaceparameter object may be defined in the object of RSVP-TE to carry the above interface parameters.

The extension of the Interface parameter object is shown in FIG. 11.

The meaning of each field defined in the Interface parameter object is as described in RFC 4447. The defined interface parameter types are described in section 3.3 of RFC 4446.

(9) Extension of PW Grouping objects

The extension of the PW Grouping object is shown in fig. 12.

The method of use of this object and the meaning of the fields are as described in RFC 4447.

(10) Extension of the label _ request object

When the PW is not viewed as a layer network, the format of the label _ request object is as shown in fig. 13. Wherein the meaning of each field is as follows:

PW Type: to identify the data type carried by the pseudowire;

c bit: indicating whether or not the control word needs to be carried.

When a PW is viewed as a layer network, the format of the label _ request object is as shown in fig. 14. Wherein the meaning of the LSP encoding type, switching type and load type fields are as described in RFC 3473.

In using RSVP-TE to control PW, both Downstream On Demand and Conservative Label Retention Mode are required.

The signaling flow of RSVP-TE for establishing MS-PW conforms to the signaling flow in RFC3473, and comprises the following operations:

(1) when an end-to-end multi-segment pseudo wire needs to be established, a PATH message is established by a first node, the first node inquires a local routing database according to a flow defined in RFC3473, finds out a corresponding IP address of a next HOP S-PE/T-PE, uses the IP address of the node and the IP address of the next HOP S-PE/T-PE to package a head source address and a destination address of an IP data packet, fills each field of the RSVP-TE PATH message by using an extended SESSIONOBJECT, a Sender _ template OBJECT, an RSVP _ HOP OBJECT, a label _ request OBJECT and the like in the invention, and uses the SESSION OBJECT and the Sender _ template OBJECT to uniquely identify the establishment of a pseudo wire in a Path; using RSVP _ HOP to identify the previous HOP node, when looking at the PW as a layer network, the label _ request object format is as shown in fig. 14, and the RSVP _ HOP object format is as shown in fig. 6, used to identify the information of the tunnel carrying the pseudowire, when looking at the PW not as a layer network, the label _ request object format is as shown in fig. 13, and the RSVP _ HOP object is as shown in fig. 5. If explicit paths need to be specified, ERO may be used to carry corresponding explicit path information.

(2) The first node sends the PATH message after the construction of the PATH message is completed, locally reserves the information carried in the data packet, and judges that the PATH message corresponds to a signaling for establishing the pseudo wire according to the type of the objects such as Session carried in the data packet. The first node firstly checks whether a tunnel between the S-PE/T-PE and the next hop is established locally, if not, firstly a tunnel meeting the requirements is established by using signaling; if so, the existing tunnel is utilized to carry the pseudowire.

(3) The nodes that receive the PATH message (the nodes other than the head-to-tail node may be referred to as intermediate nodes) compose a new PATH message and send it to the next-hop node. The specific signaling flow is consistent with the signaling flow in RFC3473, such as: when each node receives a data packet, the data packet is firstly processed locally, and then when a new PATH message is established, a local routing database needs to be firstly inquired, the IP address information of the next hop of S-PE/T-PE is inquired, and the information is used for filling a destination address field of the IP data packet.

(4) As described in (2), the node receiving the PATH message needs to check whether there is a suitable tunnel to carry the pseudowire with the next hop node.

(5) And (4) repeating the operations in (3) and (4) until the tail node receives the PATH message.

(6) The end node sends RESV information to the first node, the node needs to inquire a local routing database according to an address in the previous HOP RSVP _ HOP reserved by the node so as to inquire a corresponding IP address, and a destination address field of an IP head of the RESV information is packaged by the address; labels are also allocated and carried in the RESV message; filling each field of RSVP-TE RESV information by using the extended SESSION OBJECT, FILTER _ SPEC OBJECT, RSVP _ HOP OBJECT and the like, and uniquely identifying the establishment of a pseudo wire in RESV by using the SESSION OBJECT and the FILTER _ SPEC OBJECT; and then the node reserves the resources according to the resource reservation information such as the bandwidth information and the like stored in the local PATH message. The tail node also sends the encapsulated RESV message to the previous hop node.

(7) And (4) after receiving the RESV message sent by the next hop, the node repeats the resource reservation process in the step (6) to support the establishment of the multi-segment pseudo wire until the RESV message returns to the first node.

The above operations describe only the parts of the extended OBJECTs that must be used when using RSVP-TE to build an end-to-end multi-segment pseudowire, such as SESSION OBJECT, SENDER _ TEMPLATE, RSVP _ HOP, FILTER _ SPEC, LABEL _ REQUEST, etc.; other objects are optional, and the specific method of use is as described in the foregoing embodiments. If the corresponding function is needed when the end-to-end multi-segment pseudo wire is established, the corresponding object is carried in the PATH message or the Resv message.

In view of the above description, the operational idea of the present invention for establishing a multi-segment pseudowire can be represented by a flow shown in fig. 15, which comprises the following steps:

step 1501: and expanding an object of RSVP-TE, and applying the expanded object to carry information required for establishing the MS-PW.

Step 1502: and the node through which the MS-PW passes completes the establishment of the end-to-end multi-segment pseudo wire according to the information carried in the extended object and required for establishing the MS-PW.

In order to ensure that the technical description and the operation idea described above can be successfully implemented, an arrangement as shown in fig. 16 may be performed. Referring to fig. 16, fig. 16 is a system diagram for implementing multi-segment pseudowire establishment according to the embodiment of the present invention, where the system includes an object extension unit and an MS-PW establishment node that are connected; the MS-PW establishing node includes a first node, a middle node (one or more) and a tail node, which may be connected in sequence, and the object extension unit may be connected to at least one of the first node, the middle node and the tail node, as long as the node through which the MS-PW passes can smoothly know the condition of the object extension.

The object expanding unit can expand the object of RSVP-TE, and the expanded object is applied to carry the information needed for establishing MS-PW. The MS-PW establishing node can complete the establishment of the end-to-end multi-segment pseudo wire according to the information carried in the extended object and required for establishing the MS-PW.

In summary, in the method and system, compared with the currently applied LDP, the technique for establishing a multi-segment pseudowire of the present invention has the advantage of traffic engineering when establishing a path, and can provide better path control, so that RSVP-TE can support the establishment of an MS-PW path. The establishment of the end-to-end multi-segment pseudo wire is completed by expanding the existing object of RSVP-TE to carry the information required for establishing the MS-PW.

The above description is only a preferred embodiment of the present invention, and is not intended to limit the scope of the present invention.

Claims

1. A method of establishing a multi-segment pseudowire, the method comprising:

2. The method of claim 1, wherein the extended object comprises:

3. The method of claim 2,

the SESSION OBJECT is used for identifying the data flow of the pseudo wire;

the LABEL _ REQUEST is used for carrying tag REQUEST information.

4. The method of claim 3,

5. The method of claim 1, wherein the object further comprises at least one of

the newly added Interface parameter is used for carrying Interface parameters;

a newly added PW group Grouping used for representing the grouped PW;

6. The method according to any of claims 1 to 5, wherein, when the node through which the MS-PW passes is the head node, the head node fills the Path PATH message with the extended object and uniquely identifies the establishment of a pseudowire, and writes the sender node address information into the previous hop node object; the first node sends the PATH message after the message is constructed and prepares a tunnel for supporting the multi-segment pseudowire.

7. The method according to any of claims 1 to 5, wherein, when the node through which the MS-PW passes is an intermediate node, the intermediate node receives a PATH message populated with said objects extended and sends a new PATH message to the next hop node; the intermediate node also prepares a tunnel for supporting the multi-segment pseudowire.

8. The method according to any of claims 1 to 5, wherein when the node via which the MS-PW is passed is a tail node, the tail node fills a RESV message with the extended object and reserves resources for supporting the multi-segment pseudowire, and further uniquely identifies establishment of one pseudowire; the tail node also sends the encapsulated RESV message to the previous hop node.

9. A system for establishing a multi-segment pseudo wire is characterized by comprising an object extension unit and an MS-PW establishment node; wherein,

10. The system of claim 9, wherein the extended objects comprise:

11. the system of claim 10,

the SESSION OBJECT is used for identifying the data flow of the pseudo wire;

the LABEL _ REQUEST is used for carrying tag REQUEST information.

12. The system of claim 11,

13. The system of claim 9, wherein the object further comprises at least one of:

the newly added Interface parameter is used for carrying Interface parameters;

newly added PW Grouping used for representing grouped PWs;

14. The system according to any one of claims 9 to 13, wherein said MS-PW establishing node includes a head node for populating a PATH message with said expanded objects and uniquely identifying the establishment of a pseudowire, writing sender node address information in a previous hop node object; the first node, after constructing the PATH message, is configured to send the message and prepare a tunnel to support the multi-segment pseudowire.

15. The system according to any of claims 9 to 13, wherein said MS-PW establishing node comprises an intermediate node configured to receive a PATH message populated with said expanded objects and to send a new PATH message to a next hop node; the intermediate node is also configured to prepare a tunnel for supporting the multi-segment pseudowire.

16. The system according to any of claims 9 to 13, wherein the MS-PW establishment node includes a tail node for populating a RESV message with the extended object and reserving resources for supporting the multi-segment pseudowire, and further uniquely identifying establishment of a pseudowire; the tail node is also used for sending the encapsulated RESV message to the previous-hop node.