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.

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; and send 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; and adding 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; and 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; and wherein 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; and wherein 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; and removing 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; and send 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; and 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 a label stack of the input packet; and wherein 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.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0100] 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0115] FIG. 15 shows a schematic view of an MPLS network.

DETAILED DESCRIPTION

[0116] 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.

[0117] 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.

[0118] 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.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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: [0124] 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. [0125] 2. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL). [0126] 3. S-PE1 100 adds the CW 102 immediately following the bottom of the label stack 202. [0127] 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.

[0128] In the opposite direction, S-PE1 100 can perform the following operations: [0129] 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. [0130] 2. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL). [0131] 3. S-PE1 100 removes the CW 102, which is located immediately following the bottom of the label stack 202. [0132] 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.

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] 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.

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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.

[0142] In view of FIGS. 5 to 10, VCCV stitching procedures are now going to be described.

[0143] 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.

[0144] 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.

[0145] 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).

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

[0147] 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: [0148] 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. [0149] 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. [0150] 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.

[0151] 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.

[0152] In the following, VCCV stitching for CC Type 3 is going to be described, in particular in view of FIG. 5.

[0153] 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.

[0154] 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.

[0155] 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: [0156] 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. [0157] 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. [0158] 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.

[0159] With a reference to FIG. 5, S-PE1 100 performs the following operations, in the direction from T-PE1 105 to T-PE2 106: [0160] 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. [0161] 2. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL). [0162] 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). [0163] 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.

[0164] 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.

[0165] In the opposite direction, S-PE1 100 performs the following operations: [0166] 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. [0167] 2. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL). [0168] 3. S-PE1 100 removes the ACH 102, which is located immediately following the bottom of the label stack. [0169] 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.

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

[0171] 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.

[0172] 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: [0173] 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). [0174] 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. [0175] 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.

[0176] With a reference to FIG. 7, S-PE1 100 performs the following operations, in the direction from T-PE1 105 to T-PE2 106: [0177] 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. [0178] 2. S-PE1 100 removes the RAL right above the PW LSE 201. [0179] 3. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL). [0180] 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). [0181] 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.

[0182] With a reference to FIG. 7, S-PE1 100 performs the following operations, in the direction from T-PE2 106 to T-PE1 105: [0183] 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. [0184] 2. S-PE1 100 removes the ACH 102 immediately following the bottom of the label stack. [0185] 3. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL). [0186] 4. S-PE1 100 pushes the RAL LSE right above the PW LSE 201. [0187] 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.

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

[0189] 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.

[0190] 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: [0191] 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. [0192] 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. [0193] 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.

[0194] With a reference to FIG. 9, S-PE1 100 performs the following operations, in the direction from T-PE1 105 to T-PE2 106: [0195] 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. [0196] 2. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL). [0197] 3. S-PE1 100 removes the GAL LSE at the bottom of the label stack 202. [0198] 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. [0199] 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.

[0200] In the opposite direction, S-PE1 100 performs the following operations: [0201] 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. [0202] 2. S-PE1 100 swaps the PW label 201 (and decrements the PW-TTL). [0203] 3. S-PE1 100 inserts the GAL LSE at the bottom of the label stack. [0204] 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. [0205] 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.

[0206] 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.

[0207] In the following, VCCV stitching signaling is going to be described, in particular with reference to FIGS. 6, 8 and 10.

[0208] 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.

[0209] 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.

[0210] 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): [0211] If T-PE1 105 advertises support for CC Type 3, S-PE1 100 advertises support for CC Type 1 to T-PE2 106. [0212] 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.

[0213] If S-PE1 supports VCCV stitching for CC Type 4 (cf. FIG. 10): [0214] If T-PE1 105 advertises support for CC Type 4, S-PE1 100 advertises support for CC Type 1 to T-PE2 106. [0215] 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.

[0216] 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.

[0217] 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): [0218] If T-PE1 105 advertises support for CC Type 2, S-PE1 100 advertises support for CC Type 1 to T-PE2 106. [0219] 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.

[0220] CV types are advertised based on S-PE1 100 capabilities as per RFC 6073 with the following additional rule: [0221] S-PE1 100 can advertise support for ACH-based CV types if and only if it supports VCCV stitching for CC Type 4.

[0222] 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.

[0223] 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.

[0224] 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.

[0225] 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.

[0226] S-PE1 100 also supports a TTL-bypass mode, as it is going to be described in the following:

[0227] 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.

[0228] 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).

[0229] 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.

[0230] 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).

[0231] 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.

[0232] 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.

[0233] 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.

[0234] 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.

[0235] 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.

[0236] 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.

[0237] 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.

[0238] 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.

[0239] 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.

[0240] 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.