DEVICE, METHOD AND SYSTEM FOR SENDING OR RECEIVING PACKETS INCLUDING CONTROL INFORMATION

Abstract

A multiprotocol label switching (MPLS) node sends an output packet including control information and payload data. 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. The MPLS node can also be configured to support the opposite operating direction, that is an MPLS, node may be configured to receive an 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.

Description

FIELD

The present disclosure relates to the field of multi-segment (MS) pseudo-wire (PW) switching, and provides a device, method and system for sending and receiving control information.

BACKGROUND

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 (control word) has been recommended.

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 4448. There are situations where replacing the conventional PE with a new piece of equipment that supports CW for ethernet PW is not acceptable because of economical or operational (e.g. service disruption time) reasons.

FIG. 15 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) that is not capable of inserting a CW. In this case, e.g. according to the CW negotiation procedure defined in RFC 4447, 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 a multiprotocol label switching (MPLS) network using ECMP to avoid the undesired ECMP behavior, when a conventional PE is used.

It has been 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.

SUMMARY

In view of the above-mentioned problems and disadvantages, the present disclosure improves the behavior of MPLS networks supporting PWs that terminate on conventional PEs. The present disclosure provides 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.

Accordingly, an aspect of the present disclosure provides a device, which also may be called an MPLS node, or switching provider edge (S-PE), and a related method and system, that enhances the S-PE definition, capabilities, and functions as e.g. defined in RFC 6073, with the capability to switch an ethernet pseudo-wire (PW) segment that uses a PW control word (CW) (as e.g. defined in RFC 4385) with an ethernet PW segment that does not use the CW.

An 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 6073: T-PE1 signals SS-PW with T-PE2 using targeted label distribution protocol (T-LDP), as defined in RFC 4447. 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 6073. 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 3985 (section 1.4), on T-PE2 (e.g. with PW-TTL>2): 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 customer edge. The attachment circuit may be, for example, a frame relay DLCI (data link connection identifier), an ATM (asynchronous transfer mode) VPI/VCI (virtual path identifier/virtual circuit identifier), an Ethernet port, a VLAN (virtual local area network), a PPP (pont-to-point protocol) connection on a physical interface, a PPP session from an L2TP (layer 2 tunneling protocol) 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 7267, 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 aspect, the present disclosure allows for using virtual circuit connectivity verification (VCCV) packets, i.e., packets carrying VCCV messages as defined in RFC 5085 (for instance in section 3), 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 1, as defined in RFC 5085 (section 5.1.1), 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.

The different CC Types may be:

• • CC type 1: in this case the VCCV packet includes the VCCV message, a control information (ACH) immediately following the bottom of the label stack and the label stack itself, which is the same that is used to send PW packets over the PW segment;
  • CC type 2: in this case the VCCV packet includes at least the VCCV message and a router alert label-label stack entry (RAL LSE) is inserted above the PW LSE of the label stack that is used to send PW packets over the PW segment;
  • CC type 3: in this case the VCCV packet includes at least the VCCV message and the label stack itself, which is the same that is used to send PW packets over the PW segment with the PW-TTL set to a proper value such that it expires at the terminating node (T-PE) the VCCV packet is targeted to;
  • CC type 4: in this case the VCCV packet includes the VCCV message, a control information (ACH) immediately following the bottom of the label stack and a Generic associated channel label (GAL) LSE is inserted at the bottom of the label stack that is used to send PW packets over the PW segment.

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 3, as defined in RFC 5085 (section 5.1.3), or CC Type 4, as defined in RFC 7708 (section 3). If T-PE1 supports CC Type 3, 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=2): 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 6073.

If T-PE2 supports VCCV, it can be configured to always advertise support for CC type 1. This would allow simplifying the VCCV switching process since CC type 1 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 3), 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 1.

If T-PE1 supports only CC Type 2, as defined in RFC 5085 (section 5.1.2), a VCCV stitching for CC Type 2 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 provides a method for operating the above device, and a system comprising the device.

A first aspect of the present disclosure, provides a multiprotocol label switching, MPLS, node 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, e.g. a control word can be inserted in or removed from the output packet. VCCV packets can also be processed in the MPLS node. Another advantage is that network operators are given an option to deploy the MPLS node, located one hop away at the MPLS layer from the conventional PE (which can be the T-PE1, and can be typically physically co-located), which can add the CW to the ethernet PW packets received from the T-PE1, before sending them through an MPLS network. This MPLS node according to the first aspect in particular can behave as a switching PE (S-PE) as defined in RFC 6073 that is however further capable of switching an ethernet PW segment that uses the CW with an ethernet PW segment that does not use the CW.

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 CW for ethernet PW encapsulation according to RFC 4448. In this way, all the ethernet PW packets sent though the MPLS network will have the CW and are protected against undesired ECMP behavior.

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.

In particular, the control information can be the CW in the case of the data packets (in this case the MPLS node modifies the encapsulation by including the CW into the packet), or the control information can be 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 3032.

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 3032.

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 3032.

The control information can e.g. be or can include a CW. This can in particular be the case, when the input packet and/or output packet is a data packet.

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.

In an implementation form of the first aspect, 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 ensures that control information can be generated by the MPLS node and included in the output packet, thereby enabling the MPLS node for sending output packets which e.g. include a CW each (in the control information).

In a further implementation form of the first aspect, 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, for instance immediately following the bottom of the label stack, of the input packet; wherein the control information includes a control word.

This ensures that the MPLS node is capable of adding a control word to an input packet, to generate an output packet.

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.

In a further implementation form of the first aspect, generating the output packet includes swapping a pseudo-wire label from the input packet to the output 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.

This ensures that the MPLS node is capable of VCCV stitching for CC type 3.

In a further implementation form of the first aspect, generating the output packet further includes removing a router alert label, RAL, from the input packet.

The RAL is defined in RFC 3032 as a special label value, i.e., value 1, and in the context of CC Type 2, it is used above the PW LSE to indicate that the packet is a VCCV packet, as described in RFC 5085 (section 5.1.2).

This ensures that the MPLS node is capable of VCCV stitching for CC type 2.

In a further implementation form of the first aspect, 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 4.

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 5586 as a special label value, i.e., value 13, to indicate that an ACH immediately follows the bottom of the label stack and in the context of CC Type 4, it is used at the bottom of the label stack to indicate that the packet is a VCCV packet, as described in RFC 7708 (section 3).

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

In a further implementation form of the first aspect, generating the output packet includes maintaining a time to live, TTL, value of a pseudo-wire label stack entry of the input packet.

This ensures that a TTL-bypass mode can be provided to either or both PW and VCCV packets.

In order to receive the TTL value of the label switched path (LSP) label stack entry, penultimate hop popping (PHP), as defined in RFC 3032, can be disabled.

In a further implementation form of the first aspect, generating the output packet further includes decrementing a time to live, TTL, value of a LSP label stack entry of the input packet.

In an implementation, in order to receive the TTL value of the LSP label stack entry, PHP, as defined in RFC 3032, is disabled.

A second aspect provides a multiprotocol label switching, MPLS, node 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.

In an implementation form of the second aspect, 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, generating the output packet further includes swapping a pseudo-wire label from the input packet to the output packet and 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 a control word.

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.

In a further implementation form of the second aspect, generating the output packet includes swapping a pseudo-wire label from the input packet to the output 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.

In a further implementation form of the second aspect, generating the output packet includes adding a router alert label, RAL, to the input packet.

In a further implementation form of the second aspect, 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.

In a further implementation form of the second aspect, generating the output packet includes maintaining a time to live, TTL, value of a pseudo-wire label stack entry of the input packet.

In a further implementation form of the second aspect, generating the output packet further includes decrementing a time to live, TTL, value of a label switch path, LSP, label stack entry of the input packet.

Again in a further implementation, in order to receive the TTL value of the LSP label stack entry, PHP, as defined in RFC 3032, is disabled.

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, 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.

In an implementation form of the fourth aspect, 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.

In a further implementation form of the fourth aspect, 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 a control word.

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.

In a further implementation form of the fourth aspect, generating the output packet includes swapping a pseudo-wire label from the input packet to the output 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.

In a further implementation form of the fourth aspect, generating the output packet further includes removing a router alert label, RAL, from the input packet.

In a further implementation form of the fourth aspect, 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.

In a further implementation form of the fourth aspect, generating the output packet includes maintaining a time to live, TTL, value of a pseudo-wire label stack entry of the input packet.

In a further implementation form of the fourth aspect, generating the output packet further includes decrementing a time to live, TTL, value of a label switch path, LSP, label stack entry of the input packet.

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, 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 (104) to a first pseudo-wire segment).

In an implementation form of the fifth aspect, 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 fifth aspect, generating the output packet further includes swapping a pseudo-wire label from the input packet to the output packet and 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 a control word.

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.

In a further implementation form of the fifth aspect, generating the output packet includes swapping a pseudo-wire label from the input packet to the output 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.

In a further implementation form of the fifth aspect, generating the output packet includes adding a router alert label, RAL, to the input packet.

In a further implementation form of the fifth aspect, 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.

In a further implementation form of the fifth aspect, generating the output packet includes maintaining a time to live, TTL, value of a pseudo-wire label stack entry of the input packet.

In a further implementation form of the fifth aspect, generating the output packet further includes decrementing a time to live, TTL, value of a label switch path, LSP, label stack entry of the input 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.

A sixth aspect provides a computer program product comprising a program code for controlling a multiprotocol label switching, 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, or for performing, when running on a computer, the method according to the fourth aspect or any one of its implementation forms, or the method according to the fifth aspect or any one of its implementation forms.

The computer program product of the sixth aspect includes the same advantages as the device according to the first aspect and its implementation forms.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of exemplary embodiments, a example functionality or step to be performed by external entities is not reflected in the description of a example detailed element of that entity that performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

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

FIG. 1 shows a schematic view of a device according to an embodiment;

FIG. 2 shows another schematic view of a device according to an embodiment;

FIG. 3 shows a schematic view of a device according to an embodiment in more detail;

FIG. 4 shows a schematic view of a device according to an embodiment in more detail;

FIG. 5 shows a schematic view of a device according to an embodiment in more detail;

FIG. 6 shows a schematic view of a device according to an embodiment in more detail;

FIG. 7 shows a schematic view of a device according to an embodiment in more detail;

FIG. 8 shows a schematic view of a device according to an embodiment in more detail;

FIG. 9 shows a schematic view of a device according to an embodiment in more detail;

FIG. 10 shows a schematic view of a device according to an embodiment in more detail;

FIG. 11 shows a schematic view of a system according to an embodiment;

FIG. 12 shows a schematic view of another system according to an embodiment;

FIG. 13 shows a schematic view of a method according to an embodiment;

FIG. 14 shows a schematic view of a method according to an embodiment; and

FIG. 15 shows a schematic view of an MPLS network.

DETAILED DESCRIPTION

FIG. 1 shows an MPLS node 100. The MPLS node 100 is for sending an output packet 101 including control information 102 and payload data 103. The MPLS node 100 is configured to receive an input packet 104 including at least the payload data 103, from a first pseudo-wire segment 105; modify an encapsulation format of the payload data 103 of the input packet 104 to generate the output packet 101; and send the output packet 101 to a second pseudo-wire segment 106.

As it is also illustrated in FIG. 2, the first pseudo-wire segment 105 relates to a first terminating node T-PE1 107 (that is, the first pseudo-wire segment 105 terminates on T-PE1 107), and the second pseudo-wire segment 106 relates to a second terminating node T-PE2 108 (that is, the second pseudo-wire segment 106 terminates on T-PE2 108). T-PE1 can be a device that is not capable of including a CW in ethernet PW encapsulation, T-PE2 can be a device that is capable to use the CW for ethernet PW encapsulation. The MPLS node 100 can, in particular, be S-PE as defined above and may also be called S-PE1. The MPLS node 100 can be added to the network with minimum or no service disruption and PW redundancy, as defined in RFC 6718 or RFC 7771, 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 104 comprises generating the control information 102 and adding at least the control information 102 to the input packet 104 to generate the output packet 101.

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

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

FIG. 3 shows a schematic view of the MPLS node 100 according to an embodiment. In view of FIG. 3, it is now going to be described in detail, how the control information 102 is generated and added to the output packet 101, 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 100 (i.e. S-PE1 100) on ethernet PW packets the node 100 is forwarding.

With a reference to FIG. 3, the S-PE1 100 performs the following operations, in the direction from T-PE1 105 to T-PE2 106:

• • 1. S-PE1 100 pops the MPLS label stack entry (LSE) of the LSP from T-PE1 105 to S-PE1 100, if not PHP-ed by the penultimate LSR.
  • 2. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL).
  • 3. S-PE1 100 adds the CW 102 immediately following the bottom of the label stack 202.
  • 4. S-PE1 100 pushes the MPLS LSE for the LSP to T-PE2 106, unless this LSP is a single-hop PHP-ed LSP.

In the opposite direction, S-PE1 100 can perform the following operations:

• • 1. S-PE1 100 pops the MPLS LSE for the LSP from T-PE2 106 to S-PE1 100, if not PHP-ed by the penultimate LSR.
  • 2. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL).
  • 3. S-PE1 100 removes the CW 102, which is located immediately following the bottom of the label stack 202.
  • 4. S-PE1 100 pushes the MPLS LSE for the LSP to T-PE2 106, unless this LSP is a single-hop PHP-ed LSP.

In view of FIG. 4, optional exchange of signaling information between T-PE1 105, S-PE1 100 and T-PE2 106 for CW stitching is going to be described.

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

This allows S-PE1 100 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 105, 106, then S-PE1 100 will behave as specified in RFC 6073. 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 105, 106.

FIG. 4 in particular shows an example of how CW capabilities are negotiated in the reference network scenario of FIG. 1. T-PE1 105 will send a T-LDP Label Mapping message with c=0 and T-PE2 106 will send a T-LDP Label Mapping message with C=1, based on the procedures defined in section 6.2 of RFC 4447.

After S-PE1 100 receives the T-LDP Label Mapping message (with c=1) from T-PE2 106, it can send a T-LDP Label Mapping message back to T-PE2 106 (with c=1), following the procedures defined in section 6.2 of RFC 4447, and a T-LDP Label Mapping message to T-PE1 105 (with c=1), following the procedures of RFC 6073.

After S-PE1 100 receives the T-LDP Label Mapping message (with c=0) from T-PE1 105, it can send a T-LDP Label Mapping message to T-PE2 106 (with c=1), as if it has received c=1 from T-PE1 105. It can also send a T-LDP Label Mapping message back to T-PE1 105 with c=0, following the procedures defined in section 6.2 of RFC 4447.

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

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

In view of FIGS. 5 to 10, 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 100 needs to be capable to perform VCCV stitching.

For simplicity and explanation purposes only, it is assumed a configuration where CC Type 1 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 2 to 4 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 105).

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

In the traffic direction from T-PE2 106 and T-PE1 105, CC Type 1 is used: S-PE1 100 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:

• • Ethernet PW packets are received with the CW: these packets need to be forwarded following the rules defined above, in particular in view of FIGS. 1 to 4.
  • VCCV packets targeted at S-PE1 100 are received with the ACH and the PW-TTL=1: these packets should be processed by S-PE1 100 and not forwarded.
  • Other VCCV packets are received with the ACH and with a PW-TTL value greater than 1: these packets need to be forwarded following the rules defined in the following sections.

In the traffic direction from T-PE1 105 and T-PE2 106, 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 3 is going to be described, in particular in view of FIG. 5.

In case CC Type 3 is used on the PW segment not using the CW, VCCV stitching needs to translate between CC Type 3 (without the CW) and CC Type 1. It is to be noted that when CC Type 3 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 5085, section 4. 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 105 and T-PE2 106, S-PE1 100 can distinguish VCCV and ethernet PW packets by looking at the PW-TTL value:

• • Ethernet PW packets are received with a PW-TTL value exceeding the PW-TTL distance from S-PE1 100 to T-PE2 106 (e.g. TTL>2): these packets need to be forwarded following the rules defined above, in particular in view of FIGS. 1 to 4.
  • VCCV packets targeted at S-PE1 100 are received with PW-TTL=1: these packets should be processed by S-PE1 100 and not forwarded.
  • Other VCCV packets are received with a PW-TTL value greater than 1 and not exceeding the PW-TTL distance to T-PE2 106 (e.g. TTL=2): these packets need to be forwarded following the rules defined in this section, i.e. described in view of FIG. 5.

With a reference to FIG. 5, S-PE1 100 performs the following operations, in the direction from T-PE1 105 to T-PE2 106:

• • 1. S-PE1 100 pops the MPLS LSE of the LSP from T-PE1 105 to S-PE1 106, if not PHP-ed by the penultimate LSR.
  • 2. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL).
  • 3. S-PE1 100 adds the ACH 102 immediately following the bottom of the label stack (setting the ACH Channel Type based on the IP version field of the encapsulated IP packet).
  • 4. S-PE1 100 pushes the MPLS LSE for the LSP to T-PE2 106, unless this LSP is a single-hop PHP-ed LSP.

S-PE1 100 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 104.

In the opposite direction, S-PE1 100 performs the following operations:

• • 1. S-PE1 100 pops the MPLS LSE for the LSP from T-PE2 106 to S-PE1 100, if not PHP-ed by the penultimate LSR.
  • 2. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL).
  • 3. S-PE1 100 removes the ACH 102, which is located immediately following the bottom of the label stack.
  • 4. S-PE1 100 pushes the MPLS LSE for the LSP to T-PE1 105, unless this LSP is a single-hop PHP-ed LSP.

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

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

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

• • Ethernet PW packets are received without a RAL LSE: these packets need to be forwarded following the procedures defined above (in particular in view of FIGS. 1 to 4).
  • VCCV packets targeted at S-PE1 100 are received with the RAL LSE and with the PW-TTL=1: these packets should be processed by S-PE1 100 and not be forwarded.
  • Other VCCV packets are received with the RAL LSE and with the PW-TTL>1: these packets need to be forwarded following the rules defined in this section, i.e. in view of FIG. 7.

With a reference to FIG. 7, S-PE1 100 performs the following operations, in the direction from T-PE1 105 to T-PE2 106:

• • 1. S-PE1 100 pops the MPLS LSE of the LSP from T-PE1 105 to S-PE1 100, if not PHP-ed by the penultimate LSR.
  • 2. S-PE1 100 removes the RAL right above the PW LSE 201.
  • 3. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL).
  • 4. S-PE1 100 adds the ACH 102 immediately following the bottom of the label stack 202 (setting the ACH Channel Type based on the IP version field of the encapsulated IP packet).
  • 5. S-PE1 100 pushes the MPLS LSE for the LSP to T-PE2 106, unless this LSP is a single-hop PHP-ed LSP.

With a reference to FIG. 7, S-PE1 100 performs the following operations, in the direction from T-PE2 106 to T-PE1 105:

• • 1. S-PE1 100 pops the MPLS LSE of the LSP from T-PE2 106 to S-PE1 100, if not PHP-ed by the penultimate LSR.
  • 2. S-PE1 100 removes the ACH 102 immediately following the bottom of the label stack.
  • 3. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL).
  • 4. S-PE1 100 pushes the RAL LSE right above the PW LSE 201.
  • 5. S-PE1 100 pushes the MPLS LSE for the LSP to T-PE1 105, unless this LSP is a single-hop PHP-ed LSP.

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

In case that CC Type 4 is used on the PW segment not using the CW, VCCV stitching needs to translate between CC Type 4 and CC Type 1. 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 105 and T-PE2 106, S-PE1 100 can distinguish VCCV and Ethernet PW packets by looking at GAL LSE right after the PW LSE:

• • Ethernet PW packets are received without a GAL LSE: these packets need to be forwarded following the rules defined above, in particular in view of FIGS. 1 to 4.
  • VCCV packets targeted at S-PE1 100 are received with the GAL LSE and with the PW-TTL=1: these packets should be processed by S-PE1 100 and not be forwarded.
  • Other VCCV packets are received with the GAL LSE and with a PW-TTL value greater than 1: these packets need to be forwarded following the rules defined in this section i.e. in view of FIG. 9.

With a reference to FIG. 9, S-PE1 100 performs the following operations, in the direction from T-PE1 105 to T-PE2 106:

• • 1. S-PE1 100 pops the MPLS LSE of the LSP from T-PE1 105 to S-PE1 100, if not PHP-ed by the penultimate LSR.
  • 2. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL).
  • 3. S-PE1 100 removes the GAL LSE at the bottom of the label stack 202.
  • 4. S-PE1 100 sets the S-bit of the PW LSE 201 since the PW LSE 201 becomes the new bottom of the label stack 202.
  • 5. S-PE1 100 pushes the MPLS LSE for the LSP to T-PE2 106, unless this LSP is a single-hop PHP-ed LSP.

In the opposite direction, S-PE1 100 performs the following operations:

• • 1. S-PE1 100 pops the MPLS label stack entry (LSE) for the LSP from T-PE2 106 to S-PE1 100, if not PHP-ed by the penultimate LSR.
  • 2. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL).
  • 3. S-PE1 100 inserts the GAL LSE at the bottom of the label stack.
  • 4. S-PE1 100 clears the S-bit of the PW LSE 201 since the PW LSE is no longer at the bottom of the label stack 202.
  • 5. S-PE1 100 pushes the MPLS LSE for the LSP to T-PE2 106, unless this LSP is a single-hop PHP-ed LSP.

The above procedures regarding CC Type 2, 3 and 4 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 FIGS. 6, 8 and 10.

S-PE1 100 negotiates VCCV capabilities with T-PE1 105 and T-PE2 106 following similar procedures as defined in RFC 5085 and RFC 6073.

If the same CW capabilities are negotiated on both PW segments 105, 106, then S-PE1 100 will behave as specified in RFC 6073. 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 105, 106.

If S-PE1 100 supports VCCV stitching for CC Type 3, and it knows the PW-TTL distance to both T-PE1 105 and T-PE2 106 (cf. FIG. 6):

• • If T-PE1 105 advertises support for CC Type 3, S-PE1 100 advertises support for CC Type 1 to T-PE2 106.
  • If T-PE2 106 advertises support for CC Type 1, S-PE1 100 behaves toward T-PE1 105 as if it supports CC Type 3 and T-PE2 106 has advertised support for CC Type 3, following the procedure defined in RFC 6073.

If S-PE1 supports VCCV stitching for CC Type 4 (cf. FIG. 10):

• • If T-PE1 105 advertises support for CC Type 4, S-PE1 100 advertises support for CC Type 1 to T-PE2 106.
  • If T-PE2 106 advertises support for CC Type 1, S-PE1 100 behaves toward T-PE1 105 as if it supports CC Type 4 and T-PE2 106 has advertised support for CC Type 4, following the procedure defined in RFC 6073.

The above procedures regarding VCCV stitching signaling for CC Type 3 and 4 are described under the assumption that VCCV stitching procedures for CC Type 2 are administratively disabled.

If S-PE1 100 supports VCCV stitching for CC Type 2, and these procedures are administratively enabled e.g., because CC Type 2 is the only CC Type supported by T-PE1 (cf. FIG. 8):

• • If T-PE1 105 advertises support for CC Type 2, S-PE1 100 advertises support for CC Type 1 to T-PE2 106.
  • If T-PE2 106 advertises support for CC Type 1, S-PE1 100 advertises at least support for CC Type 2 to T-PE1 105.

CV types are advertised based on S-PE1 100 capabilities as per RFC 6073 with the following additional rule:

• • S-PE1 100 can advertise support for ACH-based CV types if and only if it supports VCCV stitching for CC Type 4.

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

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

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

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

S-PE1 100 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 2 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 2 are enabled.

If PW TTL-bypass mode is enabled, S-PE1 100 does not decrement the PW-TTL (for both OAM and data packets) in both directions. To open any forwarding loop, S-PE1 100 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 100 also disables PHP on both the LSPs that it terminates (from T-PE1 105 and T-PE2 106).

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 100 does not decrement the PW-TTL of the forwarded VCCV packets in both directions.

To open any forwarding loop, S-PE1 100 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 100 also disables PHP on both the LSPs it terminates (from T-PE1 105 and T-PE2 106).

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

FIGS. 11 and 12 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. 1, without requiring any change to the behavior of the involved S-PE.

Another possible deployment scenario is shown in FIG. 11, where both T-PEs are not capable of inserting the CW: In this scenario, two S-PEs are deployed: S-PE1 100 in front of T-PE1 105 and S-PE2 100′ in front of T-PE2 106. S-PE1 100 and S-PE2 100′ 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. 12. In this case a MS-PW can be setup with some PW segments using the CW and others not using the CW. S-PE1 100 and S-PE3 100″ operate as defined in RFC 6073 while S-PE2 100′ and S-PE4 100′″ 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 6073 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. 13 shows a method 1300 for operating the MPLS node 100. The method 1300 is for sending an output packet 101 including control information 102 and payload data 103, and includes a first step of receiving 1301, by a multiprotocol label switching, MPLS, node 100, an input packet 104 including the payload data 103, from an first pseudo-wire segment 105. The method 1300 includes a second step of modifying, by the MPLS node 100, an encapsulation format of the payload data 103 of the input packet 104 to generate the output packet 101. The method includes a last step of sending, by the MPLS node 100, the output packet 101 to a second pseudo-wire segment 106.

Since the MPLS node 100 can be operated in a forward and/or backward operating mode, FIG. 14 shows a method 1400 for operating the MPLS node 100 in the opposite operating direction compared to method 1300. The method 1400 is for receiving an input packet 101 including control information 102 and payload data 103. The method 1400 includes a first steps of receiving 1401, by a multiprotocol label switching, MPLS, node 100, the input packet 101 including the payload data 103 from a second pseudo-wire segment 106. The method includes a second step of modifying 1402, by the MPLS node 100, an encapsulation format of the payload 103 of the input packet 101 to generate an output packet 104. The method 1400 also includes a last step of sending 1403, by the MPLS node 100, the output packet 104 to a first pseudo-wire segment 105.

The present disclosure also provides a computer program product comprising a program code for controlling a multiprotocol label switching, MPLS, node 100 according to FIGS. 1 to 10 or for performing, when running on a computer, the method (1300, 1400) according to FIG. 13 or 14. The computer program product includes any kind of computer accessible data, including e.g. any kind of storage, or information that is transmitted via a communication network.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed disclosure, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. A multiprotocol label switching (MPLS) node for sending an output packet comprising control information and payload data, the MPLS node being 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; andsend the output packet to a second pseudo-wire segment.

2. The MPLS node (according to claim 1, wherein the modification of the encapsulation of the input packet comprises: generating the control information; andadding at least the control information to the input packet to generate the output packet.

3. The MPLS node according to claim 1, wherein generating the output packet further comprises swapping a pseudo-wire label from the input packet to the output packet; andwherein the modification of the encapsulation of the input packet comprises adding the control information to the input packet, which comprises adding the control information following a bottom of a label stack of the input packet; andwherein the control information comprises a control word.

4. The MPLS node according to claim 1, wherein the input packet is a virtual circuit connectivity verification (VCCV) packet, and the output packet is a VCCV packet.

5. The MPLS node according to claim 1, wherein generating the output packet comprises swapping a pseudo-wire label from the input packet to the output packet;wherein the modification of the encapsulation of the input packet comprises adding the control information to the input packet, which comprises adding the control information following a bottom of a label stack of the input packet; andwherein the control information comprises an associated channel header (ACH).

6. The MPLS node according to claim 5, wherein generating the output packet further comprises removing a router alert label (RAL) from the input packet.

7. The MPLS node according to claim 1, wherein generating the output packet comprises: swapping a pseudo-wire label from the input packet to the output packet; andremoving a generic associated channel label (GAL) from the input packet, and setting an S-bit of a pseudo-wire label stack entry of the output packet;wherein the control information comprises an associated channel header (ACH).

8. The MPLS node according to claim 1, wherein generating the output packet comprises maintaining a time to live (TTL) value of a pseudo-wire label stack entry of the input packet.

9. The MPLS node according to claim 1, wherein generating the output packet further comprises decrementing a time to live (TTL) value of a label switch path (LSP) label stack entry of the input packet.

10. A multiprotocol label switching (MPS) node for receiving an input packet comprising control information and payload data, the MPLS node being configured to: receive the input packet comprising 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; andsend the output packet to a first pseudo-wire segment.

11. The MPLS node according to claim 10, wherein 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.

12. The MPLS node according to claim 10, wherein generating the output packet further comprises swapping a pseudo-wire label from the input packet to the output packet; andwherein modifying the encapsulation format of the input packet comprises removing the control information from the input packet, which comprises removing the control information following a bottom of a label stack of the input packet; andwherein the control information comprises a control word.

13. The MPLS node according to claim 10, wherein the input packet is a virtual circuit connectivity verification (VCCV) packet, and the output packet is a VCCV packet.

14. The MPLS node according to claim 10, wherein generating the output packet comprises swapping a pseudo-wire label from the input packet to the output packet; wherein modifying the encapsulation format of the input packet comprises removing the control information from the input packet, which comprises removing the control information following a bottom of the label stack of the input packet; wherein the control information comprises an associated channel header (ACH).

15. The MPLS node according to claim 14, wherein generating the output packet comprises adding a router alert label (RAL) to the input packet.

16. The MPLS node according to claim 10, wherein generating the output packet comprises: 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 an S-bit of a pseudo-wire label stack entry of the input packet; and wherein the control information comprises an associated channel header, ACH.

17. The MPLS node according to claim 10, wherein generating the output packet comprises maintaining a time to live (TTL) value of a pseudo-wire label stack entry of the input packet.

18. The MPLS node according to claim 10, wherein generating the output packet further comprises decrementing a time to live (TTL) value of a label switch path (LSP) label stack entry of the input packet.

19. A multiprotocol label switching (MPLS) system comprising a first pseudo-wire segment, a second pseudo-wire segment and the MPLS node according to claim 1.