Patent Description:
In order to protect ethernet pseudo-wire (PW) packets against wrong equal-cost-multi-path (ECMP) behavior, which may cause out-of-order delivery of payload ethernet frames, the use of PW CW has been recommended in the prior art.

However, service providers may have deployments where a conventional provider edge (PE) device is an old piece of equipment which is not capable of including a CW in Ethernet PW encapsulation. In this case, the CW is not used e.g. as defined in RFC <NUM>. There are situations where replacing the conventional PE with a new piece of equipment which supports CW for ethernet PW is not acceptable because of economical or operational (e.g. service disruption time) reasons.

<FIG> illustrates a situation in which a PW is setup between two PEs (being terminating provider edges (T-PEs), i.e. T-PE1 and T-PE2) where one of them is an old piece of equipment (i.e. the conventional PE) which is not capable of inserting a CW. In this case, e.g. according to the CW negotiation procedure defined in RFC <NUM>, the PW is setup without using the CW. Packets sent through this PW may be subject to undesired, e.g. wrong or incorrect ECMP behavior.

That is, the problem to be solved is to find a way to send ethernet PW packets with a CW through an MPLS network using ECMP to avoid the undesired ECMP behavior, when a conventional PE is used.

In the prior art it is suggested to replace the old piece of equipment (the conventional PE) with newer devices which are capable of inserting the CW. However, in many cases this solution may not be practical for both operational and economic reasons as explained before. That is, there is no prior-art solution to this problem and the need for a way to send ethernet PW packets with the CW through an MPLS network, when a PW terminates on a conventional PE.

<CIT> discloses techniques for improving efficiency of encapsulation for packets of a first set of one or more protocols on a packet-pseudowire over a tunnel in a Packet Switched Network (PSN).

<CIT> relates to Multi-Protocol Support Over Ethernet Packet-Switched Networks and discloses techniques for carrying packets through a multi-segment pseudo-wire.

In view of the above-mentioned problems and disadvantages, the present disclosure aims to improve the behavior of MPLS networks supporting PWs which terminates on conventional PEs. The present disclosure therefore has the object to provide a multiprotocol label switching, MPLS, node for sending an output packet including control information and payload data, respectively an MPLS, node for receiving an input packet including control information and payload data. The control information can in particular be the CW, but also other types of information can be processed, as it is described below.

An important aspect of the present disclosure is to add a CW in an intermediate switching node (i.e. the above MPLS node, also called switching provider edge, S-PE), to a PW packet transmitted by a first terminating node (e.g. a first terminating provider edge, T-PE1) to a second terminating node of a network (e.g. a second terminating provider edge, T-PE2), where the first terminating node is not able to generate a PW packet including a CW. In other words, the MPLS node generates a CW and adds the CW to the PW packet transmitted by T-PE1 when forwarding it to T-PE2. This can in particular be implemented by changing a forwarding procedure of a conventional MPLS node. The present disclosure also allows for the reverse procedure: for a PW packet received from T-PE2, which includes the CW, the MPLS node removes the CW from the PW packet before forwarding it to T-PE1.

The MPLS node can be placed with respect to the T-PE1 so that the PW packets generated by the T-PE1 are not subject to ECMP before being received by the MPLS node (also in the reverse direction): the added CW protects the PW packets forwarded by the MPLS node to the T-PE2 from incorrect ECMP behaviour (and also in reverse the direction). For instance, the MPLS node can be placed close, i.e. one hop away, at the MPLS layer (typically physically co-located), to the T-PE1. Alternatively, the MPLS node can be placed multiple hops away at the MPLS or PW layer, as long as no ECMP is not used within the MPLS network(s) forwarding the PW packets from the T-PE1 to the MPLS node.

The present disclosure is based on the observation that, for example in some conventional MPLS networks, T-PE1 operates in the same way, regardless of whether the PW is a single-segment (SS) PW or a MS-PW, as defined in RFC <NUM>: T-PE1 signals SS-PW with T-PE2 using targeted label distribution protocol (T-LDP), as defined in RFC <NUM>. T-PE1 can be configured to signal a PW segment with S-PE1, as if it were T-PE2 using T-LDP, following the procedures defined in RFC <NUM>. T-PE1 is capable of setting the PW time to live (PW-TTL) value (i.e. the time to live, TTL, value of the PW label stack entry (LSE)) for ethernet PW packets to a proper value that allows the ethernet frames to be forwarded on the attachment circuit (AC), as defined in RFC <NUM> (section <NUM>), on T-PE2 (e.g. with PW-TTL><NUM>): this can be done either via administrative configuration or though T-LDP information.

The Attachment Circuit may be a physical or virtual circuit attaching a provider edge to an end device, such as a Costumer Edge. The attachment Circuit may be, for example, a Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a PPP connection on a physical interface, a PPP session from an L2TP tunnel, or an MPLS LSP.

The concept of the present disclosure however can also be used if MS-PW dynamic signalling, as e.g. defined in RFC <NUM>, is used to setup an MS-PW by using the MPLS node, or if a static configuration is used, instead of T-LDP, on either one or two PW segments switched at the MPLS node.

In a further important aspect, the present disclosure allows for using virtual circuit connectivity verification (VCCV) packets, i.e., packets carrying VCCV messages as defined in RFC <NUM> (for instance in section <NUM>), to monitor the forwarding of the PW packets between the T-PE1 and the T-PE2. In this case, since the MPLS node modifies the format of the forwarded PW packets (by adding/removing the CW), also the format of the forwarded VCCV packets can be modified. For simplicity, the present disclosure will focus on the case where, when VCCV is used, control channel (CC) Type <NUM>, as defined in RFC <NUM> (section <NUM>. <NUM>), can be used on the PW segment with the CW. The present disclosure is however not limited to this particular configuration and it also allows for using other CC Types on the PW segment with the CW.

The CC type defines the format used to encapsulate VCCV messages into packets sent over a PW segment. Different CC types define different possible formats used to encapsulate VCCV messages. The packets may be labelled packets. A labelled packet is a packet including a payload and a label stack.

It is also observed that, for example in some conventional MPLS networks, if T-PE1 supports PW VCCV, it can support at least CC Type <NUM>, as defined in RFC <NUM> (section <NUM>. <NUM>), or CC.

Type <NUM>, as defined in RFC <NUM> (section <NUM>). If T-PE1 supports CC Type <NUM>, for instance, it can be capable of setting the PW-TTL value for the VCCV packets to a proper value that allows the VCCV packets to be recognized by T-PE2 by PW-TTL expiry (e.g. PW-TTL=<NUM>): this could be done either via administrative configuration or though T-LDP information.

S-PE can, for instance, be manually configured to switch between the two PW segments, following the procedure described in RFC <NUM>.

If T-PE2 supports VCCV, it can be configured to always advertise support for CC type <NUM>. This would allow simplifying the VCCV switching process since CC type <NUM> is always used on the PW segment with CW.

According to the present disclosure, variations are defined to cover also cases where some of the above observations are not satisfied:
If T-PE1 is not capable to properly set the PW-TTL value for both VCCV and user data packets, a PW TTL-bypass mode can be administratively configured at the S-PE. When this mode is enabled on a given MS-PW, S-PE1 does not decrement the PW-TTL of all the forwarded packets for that MS-PW (Ethernet PW and VCCV packets): in this way, all these packets can be still delivered to T-PE2 even if T-PE1 sets the PW-TTL value as if the MS-PW was a SS-PW.

If T-PE1 is not capable to properly set the PW-TTL value only for the OAM packets (in particular when using CC Type <NUM>), a VCCV TTL-bypass mode can be administratively configured at the S-PE. When this mode is enabled on a given MS-PW, the S-PE1 does not decrement the PW-TTL only of the VCCV packets for that MS-PW: In this way, VCCV packets can be delivered to T-PE2 even if T-PE1 sets the PW-TTL value to <NUM>.

If T-PE1 supports only CC Type <NUM>, as defined in RFC <NUM> (section <NUM>. <NUM>), a VCCV stitching for CC Type <NUM> can be administratively configured at the S-PE.

Although the application of the present disclosure is in particular suitable for ethernet PWs, the procedures are generally applicable to any PW for which the use of CW is optional.

The present disclosure has the object to provide a method for operating the above device, and a system comprising said device.

This object is achieved by the solution provided in the enclosed independent claims. Advantageous implementations of the present disclosure are further defined in the dependent claims.

A first aspect provides a multiprotocol label switching, MPLS, node according to claim <NUM>, for sending an output packet including control information and payload data, wherein the MPLS node is configured to receive an input packet including the payload data, from a first pseudo-wire segment; modify an encapsulation format of the payload data of the input packet to generate the output packet; and send the output packet to a second pseudo-wire segment.

By modifying the encapsulation format of the payload data of the input packet to generate the output packet, the MPLS node ensures that control information can be inserted in or removed from the output packet. VCCV packets can also be processed in the MPLS node.

The MPLS node can be deployed in the network one hop away, at the MPLS layer, from e.g..

T-PE1, which does not support control information.

In particular, the input/output packets can be data packets (carrying an ethernet frame) and control packets (e.g. VCCV packets, where the payload is an OAM frame); includes an associated channel header (ACH) of a control packet (in this case modification of the encapsulation is inserting the ACH).

Preferably, encapsulation is a network principle used to enclose a protocol and transport it in the form of a tunnel over another protocol.

The output packet can in particular be an output labeled packet, including a payload and one or more label stack entries, e.g. according to RFC <NUM>.

The input packet can in particular be an input labeled packet, including a payload and one or more label stack entries, e.g. according to RFC <NUM>.

In a labelled packet, the top of the label stack appears earliest in the packet, the bottom appears latest, and the payload immediately follows the bottom of the label stack, e.g. according to RFC <NUM>.

The control information can e.g. be an associated channel header (ACH), e.g. in case of VCCV control packets.

The payload data can e.g. be an ethernet frame in case of a data packet, or OAM data in case of a control packet.

The modification of the encapsulation of the input packet comprises generating the control information and adding at least the control information to the input packet to generate the output packet.

This ensure that control information can be generated by the MPLS node and included in the output packet.

Adding the control information to the input packet further includes adding the control information following the bottom of the label stack, immediately following the bottom of the label stack, of the input packet; wherein the control information includes an associated channel header, ACH.

The swapping operation to swap the pseudo-wire label from the input packet to the output packet can in particular be defined according to RFC6073 and RFC3031.

The bottom of the label stack in particular is a last label of the label stack, counting from top to bottom. In other words, the control information is added at an end of the label stack of the input packet.

In a further implementation form of the first aspect, the input packet is a VCCV packet, and the output packet is a VCCV packet.

This ensures that the MPLS node also can properly forward control packets, such as VCCV packets.

The VCCV packet can in particular be defined according to RFC5085.

Generating the output packet includes swapping a pseudo-wire label from the input packet to the output packet; removing a generic associated channel label, GAL, from the input packet, and setting the S-bit of the pseudo-wire label stack entry of the output packet; wherein the control information includes an associated channel header, ACH.

This ensures that the MPLS node is capable of VCCV stitching for CC type <NUM>.

More specifically, when the GAL is removed, the new bottom of the label stack becomes the PW label stack entry. This is the label stack entry at which the S-bit needs to be set.

The GAL is defined in RFC <NUM> as a special label value, i.e., value <NUM>, to indicate that an ACH immediately follows the bottom of the label stack and in the context of CC Type <NUM>, it is used at the bottom of the label stack to indicate that the packet is a VCCV packet, as described in RFC <NUM> (section <NUM>).

The S-bit of an MPLS label stack entry of the output packet can in particular be set, for instance to <NUM>, to indicate the label stack entry at the bottom of the label stack, as defined according to RFC3032.

A second aspect provides a multiprotocol label switching, MPLS, node according to claim <NUM>, for receiving an input packet including control information and payload data, wherein the MPLS node is configured to receive the input packet including the payload data from a second pseudo-wire segment; modify an encapsulation format of the payload data of the input packet to generate an output packet; and send the output packet to a first pseudo-wire segment.

The modification of the encapsulation of the input packet comprises removing at least the control information from the input packet to generate the output packet.

In a further implementation form of the second aspect, the input packet is a virtual circuit connectivity verification, VCCV, packet, and the output packet is a VCCV packet.

Removing the control information from the input packet further includes removing the control information following the bottom of the label stack of the input packet; wherein the control information includes an associated channel header, ACH.

Generating the output packet includes swapping a pseudo-wire label from the input packet to the output packet, adding a generic associated channel label, GAL, to the input packet, and clearing the S-bit of the pseudo-wire label stack entry of the input packet; and wherein the control information includes an associated channel header, ACH.

The MPLS node of the second aspect and its implementation forms include the same advantages as the MPLS node according to the first aspect and its implementation forms.

A third aspect provides a multiprotocol label switching, MPLS, system comprising a first pseudo-wire segment, a second pseudo-wire segment and an MPLS node according to the first aspect or any one of its implementation forms, or an MPLS node according to the second aspect or any one of its implementation forms.

The system of the third aspect and its implementation forms include the same advantages as the device according to the first aspect and its implementation forms.

A fourth aspect provides a method for sending an output packet including control information and payload data according to claim <NUM>, the method including the steps of receiving, by an multiprotocol label switching, MPLS, node, an input packet including the payload data, from an first pseudo-wire segment; modifying, by the MPLS node, an encapsulation format of the payload data of the input packet to generate the output packet; and sending, by the MPLS node, the output packet to a second pseudo-wire segment.

The modification of the encapsulation of the input packet comprises generating the control information; and adding at least the control information to the input packet to generate the output packet.

Generating the output packet further includes swapping a pseudo-wire label from the input packet to the output packet; and adding the control information to the input packet further includes adding the control information following the bottom of the label stack of the input packet; wherein the control information includes an associated channel header, ACH.

In a further implementation form of the fourth aspect, the input packet is a virtual circuit connectivity verification, VCCV packet, and the output packet is a VCCV packet.

Adding the control information to the input packet further includes adding the control information following the bottom of the label stack of the input packet; and wherein the control information includes an associated channel header, ACH.

The method of the fourth aspect and its implementation forms include the same advantages as the device according to the first aspect and its implementation forms.

A fifth aspect provides a method for receiving an input packet including control information and payload data according to claim <NUM>,.

the method including the steps of receiving, by a multiprotocol label switching, MPLS, node, the input packet including the payload data from a second pseudo-wire segment; modifying, by the MPLS node, an encapsulation format of the payload of the input packet to generate an output packet; and sending, by the MPLS node, the output packet (<NUM>) to a first pseudo-wire segment).

In a further implementation form of the fifth aspect, the input packet is a virtual circuit connectivity verification, VCCV, packet, and the output packet is a VCCV packet.

The method of the fifth aspect and its implementation forms include the same advantages as the device according to the first aspect and its implementation forms.

The above-described aspects and implementation forms of the present disclosure will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which.

<FIG> shows an MPLS node <NUM>. The MPLS node <NUM> is for sending an output packet <NUM> including control information <NUM> and payload data <NUM>. The MPLS node <NUM> is configured to receive an input packet <NUM> including at least the payload data <NUM>, from a first pseudo-wire segment <NUM>; modify an encapsulation format of the payload data <NUM> of the input packet <NUM> to generate the output packet <NUM>; and send the output packet <NUM> to a second pseudo-wire segment <NUM>.

As it is also illustrated in <FIG>, the first pseudo-wire segment <NUM> relates to a first terminating node T-PE1 <NUM> (that is, the first pseudo-wire segment <NUM> terminates on T-PE1 <NUM>), and the second pseudo-wire segment <NUM> relates to a second terminating node T-PE2 <NUM> (that is, the second pseudo-wire segment <NUM> terminates on T-PE2 <NUM>). T-PE1 can be a device which is not capable of including a CW in ethernet PW encapsulation, T-PE2 can be a device which is capable to use the CW for ethernet PW encapsulation. The MPLS node <NUM> can in particular be S-PE as defined above and may also be called S-PE1. The MPLS node <NUM> can be added to the network with minimum or no service disruption and PW redundancy, as defined in RFC <NUM> or RFC <NUM>, can be used to move the traffic from an old SS-PW without the CW to the new MS-PW with the CW on the PW segment that passes through the MPLS network.

In particular, the modification of the encapsulation of the input packet <NUM> comprises generating the control information <NUM> and adding at least the control information <NUM> to the input packet <NUM> to generate the output packet <NUM>.

Since the MPLS node <NUM> can operate in a forward and/or in a backward manner, the MPLS node <NUM> is additionally or alternatively for receiving an input packet <NUM> including control information <NUM> and payload data <NUM>. In this case, the MPLS node <NUM> is configured to receive the input packet <NUM> including the control information <NUM> and the payload data <NUM> from a second pseudo-wire segment <NUM>; modify an encapsulation format of the payload data <NUM> of the input packet <NUM> to generate an output packet <NUM>; and send the output packet <NUM> to a first pseudo-wire segment <NUM>. More specifically the modification of the encapsulation of the input packet <NUM> comprises removing at least the control information <NUM> from the input packet <NUM> to generate the output packet <NUM>.

The device <NUM> as shown in <FIG> includes all features and functionality of the device <NUM> as described in view of <FIG>. To this end, similar features are labelled with similar reference signs. All features that are additionally described in view of <FIG> and below are optional features.

<FIG> shows a schematic view of the MPLS node <NUM> according to an embodiment. In view of <FIG> it is now going to be described in detail, how the control information <NUM> is generated and added to the output packet <NUM>, in a case in which the control information is a CW. This procedure is also called CW stitching.

The CW stitching procedure is performed by the MPLS node <NUM> (i.e. S-PE1 <NUM>) on ethernet PW packets the node <NUM> is forwarding.

With a reference to <FIG>, the S-PE1 <NUM> performs the following operations, in the direction from T-PE1 <NUM> to T-PE2 <NUM>:.

In the opposite direction, S-PE1 <NUM> can perform the following operations:.

In view of <FIG>, optional exchange of signaling information between T-PE1 <NUM>, S-PE1 <NUM> and T-PE2 <NUM> for CW stitching is going to be described.

As it is shown in <FIG>, S-PE1 <NUM> negotiates CW capabilities with T-PE1 <NUM> and T-PE2 <NUM> following similar procedures as defined in RFC <NUM> and RFC <NUM>. An exception to the procedures defined in RFC <NUM> is that S-PE1 <NUM>, when signaling one PW segment, will always behave as if the CW is supported on the other PW segment.

This allows S-PE1 <NUM> to negotiate different CW capabilities on different PW segments as well as to enable CW towards any T-PE that supports CW insertion.

If the same CW capabilities are negotiated on both PW segments <NUM>, <NUM>, then S-PE1 <NUM> will behave as specified in RFC <NUM>. CW stitching, as defined according to the present disclosure, is enabled if and only if different CW capabilities are negotiated on the two PW segments <NUM>, <NUM>.

<FIG> in particular shows an example of how CW capabilities are negotiated. T-PE1 <NUM> will send a T-LDP Label Mapping message with c=<NUM> and T-PE2 <NUM> will send a T-LDP Label Mapping message with C=<NUM>, based on the procedures defined in section <NUM> of RFC <NUM>.

After S-PE1 <NUM> receives the T-LDP Label Mapping message (with c=<NUM>) from T-PE2 <NUM>, it can send a T-LDP Label Mapping message back to T-PE2 <NUM> (with c=<NUM>), following the procedures defined in section <NUM> of RFC <NUM>, and a T-LDP Label Mapping message to T-PE1 <NUM> (with c=<NUM>), following the procedures of RFC <NUM>.

After S-PE1 <NUM> receives the T-LDP Label Mapping message (with c=<NUM>) from T-PE1 <NUM>, it can send a T-LDP Label Mapping message to T-PE2 <NUM> (with c=<NUM>), as if it has received c=<NUM> from T-PE1 <NUM>. It can also send a T-LDP Label Mapping message back to T-PE1 <NUM> with c=<NUM>, following the procedures defined in section <NUM> of RFC <NUM>.

If S-PE1 <NUM> receives the T-LDP Label Mapping message (with c=<NUM>) from T-PE1 <NUM> after having sent a T-LDP Label Mapping message with c=<NUM> to T-PE1 <NUM>, a label withdraw message needs to be sent to T-PE1 <NUM> before sending another label mapping message with c=<NUM>, as specified in section <NUM> of RFC <NUM>.

When the MS-PW is completely setup, T-PE1 <NUM> is configured not to insert CW, T-PE2 <NUM> is configured to insert CW, and S-PE1 <NUM> is configured to stitch the CW between the two PW segments.

In view of <FIG>, VCCV stitching procedures are now going to be described.

When CW stitching is enabled, VCCV packets that are sent on the two PW segments would have different formats. In order to enable end-to-end OAM, S-PE1 <NUM> needs to be capable to perform VCCV stitching.

For simplicity and explanation purposes only, it is assumed a configuration where CC Type <NUM> is used on the PW segment that uses the CW. Clearly, the skilled person will understand that the present disclosure is not limited to this case only but has validity also if any other CC Type is used on the PW segment that uses the CW.

In the description of the configurations referred to in this disclosure CC of the types <NUM> to <NUM> are used on the PW segment that does not use the CW. Thus, different VCCV stitching procedures are defined in the present disclosure, depending on the CC Type supported by the T-PE not supporting the CW (e.g. T-PE1 <NUM>).

The VCCV stitching procedure is performed by S-PE1 <NUM> on the VCCV packets it is forwarding.

In the traffic direction from T-PE2 <NUM> and T-PE1 <NUM>, CC Type <NUM> is used: S-PE1 <NUM> can distinguish between VCCV and ethernet PW packets by looking at the first nibble immediately following the bottom of the label stack which identifies either an associated channel header, ACH or a CW:.

In the traffic direction from T-PE1 <NUM> and T-PE2 <NUM>, the rules used to distinguish VCCV packets from ethernet PW packets depend from the CC Type used on the PW segment without the CW.

In the following, VCCV stitching for CC Type <NUM> is going to be described, in particular in view of <FIG>.

In case CC Type <NUM> is used on the PW segment not using the CW, VCCV stitching needs to translate between CC Type <NUM> (without the CW) and CC Type <NUM>. It is to be noted that when CC Type <NUM> is used on PW segments not using the CW, only IP-based connectivity verification (CV) types can be supported.

In the context entire disclosure, CV types indicate which VCCV protocol is in use and whether the VCCV protocol encapsulation into a VCCV message is IP based or ACH based. These are defined in RFC <NUM>, section <NUM>. In other words, CV types represent the different type of VCCV protocols. IP-based CV types require the VCCV messages to be encapsulated into an IP packet before being encapsulated into a VCCV packet. ACH-based CV types requires the VCCV messages to be directly encapsulated into a VCCV packet which is using the ACH control channel without being encapsulated into an IP packet.

In the traffic direction from T-PE1 <NUM> and T-PE2 <NUM>, S-PE1 <NUM> can distinguish VCCV and ethernet PW packets by looking at the PW-TTL value:.

With a reference to <FIG>, S-PE1 <NUM> performs the following operations, in the direction from T-PE1 <NUM> to T-PE2 <NUM>:.

S-PE1 <NUM> can understand the IP version field of the encapsulated IP packet by looking at the first nibble immediately following the bottom of the label stack of the received packet <NUM>.

In the opposite direction, S-PE1 <NUM> performs the following operations:.

This capability needs to be administratively enabled on S-PE1 <NUM>, if and only if T-PE1 <NUM> is capable to support only CC Type <NUM> and therefore this is the only option to maintain VCCV support on the PW between T-PE1 <NUM> and T-PE2 <NUM>.

In the traffic direction from T-PE1 <NUM> and T-PE2 <NUM>, S-PE1 <NUM> can distinguish VCCV and Ethernet PW packets by looking at the router alter label, RAL, LSE right above the PW LSE:.

With a reference to <FIG>, S-PE1 <NUM> performs the following operations, in the direction from T-PE2 <NUM> to T-PE1 <NUM>:.

In case that CC Type <NUM> is used on the PW segment not using the CW, VCCV stitching needs to translate between CC Type <NUM> and CC Type <NUM>. It is to be noted that in this case both IP-based and ACH-based CV types can be supported.

In the traffic direction from T-PE1 <NUM> and T-PE2 <NUM>, S-PE1 <NUM> can distinguish VCCV and Ethernet PW packets by looking at GAL LSE right after the PW LSE:.

The above procedures regarding CC Type <NUM>, <NUM> and <NUM> are described under the assumption that a PW TTL-bypass mode and a VCCV TTL-bypass mode procedures are administratively disabled.

In the following, VCCV stitching signaling is going to be described, in particular with reference to <FIG>, <FIG> and <FIG>.

S-PE1 <NUM> negotiates VCCV capabilities with T-PE1 <NUM> and T-PE2 <NUM> following similar procedures as defined in RFC <NUM> and RFC <NUM>.

If the same CW capabilities are negotiated on both PW segments <NUM>, <NUM>, then S-PE1 <NUM> will behave as specified in RFC <NUM>. VCCV stitching, as defined according to the present disclosure, is enabled if and only if different CW capabilities are negotiated on the two PW segments <NUM>, <NUM>.

If S-PE1 <NUM> supports VCCV stitching for CC Type <NUM>, and it knows the PW-TTL distance to both T-PE1 <NUM> and T-PE2 <NUM> (cf.

If S-PE1 supports VCCV stitching for CC Type <NUM> (cf.

The above procedures regarding VCCV stitching signaling for CC Type <NUM> and <NUM> are described under the assumption that VCCV stitching procedures for CC Type <NUM> are administratively disabled.

If S-PE1 <NUM> supports VCCV stitching for CC Type <NUM>, and these procedures are administratively enabled e.g., because CC Type <NUM> is the only CC Type supported by T-PE1 (cf.

CV types are advertised based on S-PE1 <NUM> capabilities as per RFC <NUM> with the following additional rule:.

This rule ensures that only IP-based CV types are negotiated between T-PE1 <NUM>, T-PE2 <NUM> and S-PE1 <NUM> when VCCV stitching for CC Type <NUM> is used.

If T-PE1 <NUM> supports CC Type <NUM> and S-PE1 <NUM> supports VCCV stitching for CC Type <NUM>, then VCCV stitching for CC Type <NUM> is used and both IP-based and ACH-based CV capabilities can be negotiated depending on T-PE1 <NUM>, T-PE2 <NUM> and S-PE1 <NUM> CV capabilities.

If T-PE1 <NUM> does not support CC Type <NUM>, it will advertise support only for IP-based CV types and therefore only IP-based CV capabilities can be negotiated depending on T-PE1 <NUM>, T-PE2 <NUM> and S-PE1 <NUM> CV capabilities.

If S-PE1 <NUM> does not support VCCV stitching for CC Type <NUM>, it will advertise support only for IP-based CV types and therefore only IP-based CV capabilities can be negotiated depending on T-PE1 <NUM>, T-PE2 <NUM> and S-PE1 <NUM> CV capabilities.

S-PE1 <NUM> also supports a TTL-bypass mode, as it is going to be described in the following:
The CW stitching procedures are described under the assumption that PW TTL-bypass mode, VCCV TTL-bypass mode and VCCV stitching for CC Type <NUM> procedures are administratively disabled. These procedures work exactly in the same way as defined in the above when either the VCCV TTL-bypass mode or the VCCV stitching for CC Type <NUM> are enabled.

If PW TTL-bypass mode is enabled, S-PE1 <NUM> does not decrement the PW-TTL (for both OAM and data packets) in both directions. To open any forwarding loop, S-PE1 <NUM> instead decrements the LSP-TTL of the received Ethernet PW packets and copies the decremented LSP-TTL in the LSP LSE that it pushes on the forwarded Ethernet PW packets. Therefore, if this mode is configured, S-PE1 <NUM> also disables PHP on both the LSPs that it terminates (from T-PE1 <NUM> and T-PE2 <NUM>).

The VCCV stitching procedures are described under the assumption that PW TTL-bypass mode and the VCCV TTL-bypass mode are administratively disabled. If either the PW TTL-bypass mode or the VCCV TTL-bypass mode is enabled, S-PE1 <NUM> does not decrement the PW-TTL of the forwarded VCCV packets in both directions.

To open any forwarding loop, S-PE1 <NUM> instead decrements the LSP-TTL of the received VCCV packets and copies the decremented LSP-TTL in the LSP LSE that it pushes on the forwarded VCCV packets. Therefore, if either one of these modes is configured, S-PE1 <NUM> also disables PHP on both the LSPs it terminates (from T-PE1 <NUM> and T-PE2 <NUM>).

<FIG> also shows a system <NUM> according to an embodiment of the present disclosure. The figure in particular shows an MPLS system <NUM> comprising a first pseudo-wire segment <NUM> (which can be or can include the T-PE1 <NUM>), a second pseudo-wire segment <NUM> (which can be or can include the T-PE2 <NUM>) and an MPLS node <NUM> (being the S-PE1, or any of the shown S-PE*). The MPLS node <NUM> that is part of the system <NUM> can be configured in the forward operating mode and/or the backward operating mode as described above.

<FIG> and <FIG> also show a system according to an embodiment of the present disclosure, each. The solution of the present disclosure can be used in different deployment scenarios, in addition to the reference network outlined in <FIG>, without requiring any change to the behavior of the involved S-PE.

Another possible deployment scenario is shown in <FIG>, where both T-PEs are not capable of inserting the CW: In this scenario, two S-PEs are deployed: S-PE1 <NUM> in front of T-PE1 <NUM> and S-PE2 <NUM>' in front of T-PE2 <NUM>. S-PE1 <NUM> and S-PE2 <NUM>' operate as defined according to the present disclosure: these operation manners are the same even if one or both the PW segments switched by one S-PE are terminated at a T-PE or at another S-PE.

An even more generic deployment scenario is shown in <FIG>. In this case a MS-PW can be setup with some PW segments using the CW and others not using the CW. S-PE1 <NUM> and S-PE3 <NUM>" operate as defined in RFC <NUM> while S-PE2 <NUM>' and S-PE4 <NUM>‴ operate as defined according to the present disclosure: these operation manners are the same even if one or both of the PW segments switched by one S-PE are terminated at a T-PE or at another S-PE operating as defined in RFC <NUM> or at another S-PE operating as defined according to the present disclosure.

The operation manners are also the same if the PW segment not using the CW is setup over a link or over an MPLS network.

All operations according to the present disclosure also work if static configuration is used instead of T-LDP to setup some or all the PW segments. These operations also work if dynamic MS-PW signaling procedures, as defined in RFC7267, are used instead of static configuration of the S-PEs.

<FIG> shows a method <NUM> for operating the MPLS node <NUM>. The method <NUM> is for sending an output packet <NUM> including control information <NUM> and payload data <NUM>, and includes a first step of receiving <NUM>, by a multiprotocol label switching, MPLS, node <NUM>, an input packet <NUM> including the payload data <NUM>, from an first pseudo-wire segment <NUM>. The method <NUM> includes a second step of modifying, by the MPLS node <NUM>, an encapsulation format of the payload data <NUM> of the input packet <NUM> to generate the output packet <NUM>. The method includes a last step of sending, by the MPLS node <NUM>, the output packet <NUM> to a second pseudo-wire segment <NUM>.

Since the MPLS node <NUM> can be operated in a forward and/or backward operating mode, <FIG> shows a method <NUM> for operating the MPLS node <NUM> in the opposite operating direction compared to method <NUM>. The method <NUM> is for receiving an input packet <NUM> including control information <NUM> and payload data <NUM>. The method <NUM> includes a first steps of receiving <NUM>, by a multiprotocol label switching, MPLS, node <NUM>, the input packet <NUM> including the payload data <NUM> from a second pseudo-wire segment <NUM>. The method includes a second step of modifying <NUM>, by the MPLS node <NUM>, an encapsulation format of the payload <NUM> of the input packet <NUM> to generate an output packet <NUM>. The method <NUM> also includes a last step of sending <NUM>, by the MPLS node <NUM>, the output packet <NUM> to a first pseudo-wire segment <NUM>.

Claim 1:
A multiprotocol label switching, MPLS, node (<NUM>) for sending an output packet (<NUM>) including control information (<NUM>) and payload data (<NUM>), wherein the MPLS node (<NUM>) is configured to:
- receive an input packet (<NUM>) including the payload data (<NUM>) and a label stack comprising a pseudo-wire label (<NUM>), from a first pseudo-wire segment (<NUM>);
- modify an encapsulation format of the payload data (<NUM>) of the input packet (<NUM>) to generate the output packet (<NUM>); and
send the output packet (<NUM>) to a second pseudo-wire segment (<NUM>);
wherein the modification of the encapsulation of the input packet (<NUM>) comprises:
- generating the control information (<NUM>); and
- adding at least the control information (<NUM>) to the input packet (<NUM>) to generate the output packet (<NUM>);
wherein generating the output packet (<NUM>) further includes:
swapping the pseudo-wire label (<NUM>) from the input packet (<NUM>) to the output packet (<NUM>);
removing a generic associated channel label, GAL, from the input packet (<NUM>); and
setting the S-bit of the pseudo-wire label (<NUM>) of the output packet (<NUM>);
wherein adding the control information (<NUM>) to the input packet (<NUM>) further includes adding the control information (<NUM>) following the bottom of the label stack (<NUM>) of the input packet (<NUM>);
wherein the control information (<NUM>) includes an associated channel header, ACH.