Patent Description:
<NPL>, describes an OPNET simulation platform to study the key factors affect the clocks' accuracy of packet-based synchronization schemes, e.g., queuing disciplines, network traffic load, whether low-pass filter is used or not, and deployment of the PTP enabled router.

In order to be able to achieve synchronization throughout a network, it is known to transmit timing information between network nodes. One example of a situation where this applies is the case of a cellular communications network, where it is necessary to achieve synchronization between the access points in the respective cells. One method of transmitting the timing information uses the Precision Time Protocol (PTP), and requires a node to measure a time at which it receives a message, and to measure a time at which it forwards that message on to a destination. The elapsed time between the two times is referred to as a residence time. Information about this residence time is sent to a destination node, for use in calculating transmission delays over the network, and thus for use in achieving synchronization between the nodes of the network.

Multiprotocol Label Switching (MPLS) is a mechanism used for transporting data packets across networks, and the document "<NPL>, describes a system in which Residence Time Measurement information can be transmitted in a Generic Associated Channel (G-ACh) message. Specifically, this document describes a system in which a data packet includes information indicating the residence time spent in routers transited by the packet on its path from an ingress router to an egress router.

However, this system places certain requirements on the hardware, and it may not be possible to meet these requirements in all cases.

According to a first aspect of the invention, there is provided a method of operation of a.

Multiprotocol Label Switching network. An active node of the network is : receiving an event message for a synchronization protocol from a network node,wherein the active node is an egress Label Edge Router, and receiving a following message containing residence time information in a MPLS G-Ach format; forwarding a corresponding event message to a boundary clock node; measuring a residence time of the event message in the active node; extracting the received following message from the MPLS G-Ach format to generate a Precision Time Protocol, PTP, following message,and sending the PTP following message containing accumulated residence time information, including the residence time for the Label Edge Router.

According to a third aspect of the invention, there is provided a Multiprotocol Label Switching, MPLS, network node, being configured to: receive an event message for a synchronization protocol from a network node; receive a following message containing residence time information in a MPLS G-Ach format; forward a corresponding event message to a boundary clock node; measure a residence time of the event message in the active node; extract the received following message from the MPLS G-Ach format to generate a Precision Time Protocol, PTP, following message, and send the PTP following message containing accumulated residence time information, including the residence time for the Label Edge Router.

<FIG> shows a part of a network, as an example of a network implementing the method described herein. It will be appreciated that the form of the network may be different and, in any event, <FIG> only shows a small part of the network, sufficient for an understanding of the method.

Thus, <FIG> shows a Internet Protocol (IP) network <NUM>, in which the Precision Time Protocol (PTP) is used to distribute timing reference signals between network nodes. In the illustrated section of the network <NUM>, there are two boundary clock (BC) nodes <NUM>, <NUM>. The method described herein is also suitable for use in other methods for synchronization by two-way exchange of messages, such as the Network Time Protocol (NTP). References to a node being a clock includes the node comprising a clock of functioning as a clock.

One illustrated part <NUM> of the network <NUM> operates using Multiprotocol Label Switching (MPLS). In a traditional IP network, packets are transmitted with an IP header that includes a source and destination address. A packet has no predetermined path and is being forwarded from one node to another in a hop-by-hop way. In contrast, in an MPLS network, a path, referred as Label Switched Path (LSP), can be established beforehand to force the packet to follow the specific path through the set of Label Switching Routers (LSRs). The ingress Label switching Edge Router (LER) encapsulates the packet with the MPLS header and forwards it according to the predetermined path. The egress LER decapsulates the MPLS packet and processes it as required.

The illustrated MPLS network <NUM> includes two Label switching Edge Routers (LERs) <NUM>, <NUM>, and one other Label Switching Router (LSR) <NUM>.

In this illustrated example, the LERs <NUM>, <NUM> are connected to the boundary clock (BC) nodes <NUM>, <NUM>, respectively. However, in other cases, for example, the MPLS network <NUM> is connected to one or more transparent clock node, that is itself connected to a boundary clock node.

<FIG> illustrates the form of each of the network nodes <NUM>, <NUM>, <NUM>. Specifically, each node includes a communications module <NUM>, for communicating with other network nodes. Each node also includes a data processing and control unit <NUM>, including a processor <NUM> and a memory <NUM>. The memory <NUM> can contain data and can also contain a program, containing instructions for execution by the processor, to cause the processor to perform the methods described herein.

<FIG> illustrates a method in accordance with a first embodiment.

Specifically, in this illustrated embodiment, at least one node of the PTP network <NUM> shown in <FIG> is operating in a <NUM>-step mode. That is, a first boundary clock node, such as the boundary clock node <NUM> shown in <FIG>, transmits an event PTP message in the form of a Sync message <NUM>, and then sends a general PTP message, in the form of a Follow_up message <NUM>.

On receipt of the Follow_up message <NUM>, a second boundary clock node, such as the boundary clock node <NUM> shown in <FIG>, transmits an event PTP message in the form of a Delay_Req message <NUM>.

When it receives the Delay_Req message <NUM>, the first boundary clock node <NUM> returns a general PTP message, in the form of a Delay_Resp message <NUM>.

On receipt of the Delay_Resp message <NUM>, the second boundary clock node <NUM> is able to obtain the required information about the transmission delays across the network, and thereby achieve synchronization with the first boundary clock node <NUM>.

Thus, the method allows for synchronization by two-way exchange of packets carrying timing information.

In this embodiment, the Sync message <NUM>, Follow_up message <NUM>, Delay_Req message <NUM>, and Delay_Resp message <NUM> are transmitted across the MPLS network in an MPLS message format, as shown in <FIG>.

More specifically, in this embodiment, the data packets are transmitted across the MPLS network as a Generalized Associated Channel (G-Ach) message.

In the packet format shown in <FIG>, the Version field is set to <NUM>, as defined in RFC <NUM> [RFC4385]. The Reserved field is set to <NUM> on transmit and ignored on receipt. The RTM Channel field identifies the packet as such.

The Flags field has one bit, S, which acts as a step flag, indicating if the two-step clock procedure is in use, and therefore set to <NUM> if the boundary clocks <NUM>, <NUM> are operating in one-step mode, and set to <NUM> if they are operating in two-step mode. The PTPType field indicates the type of PTP packet carried in the TLV. One-step mode refers to no "follow_up" type message containing a transmission and/or receipt timestamp of an earlier event message for which time of transmission and/or receipt is directly used for synchronization. Two-step mode indicates there is a further message containing a transmission and/or receipt timestamp of an earlier event message for which time of transmission and/or receipt is directly used for synchronization.

Thus, for example, the PTPType field identifies whether the message is a Sync message, Follow_up message, Delay_Req message, or Delay_Resp message. The <NUM> octet long Port ID field contains the identity of the source port, that is, the specific PTP port of the boundary clock connected to the MPLS network. The Sequence ID is the sequence ID of the PTP message carried in the Value field of the message. Thus, a further packet, containing residence time information relating to an earlier packet, contains information identifying that earlier packet.

The Type field identifies the type of Value that the TLV carries, that is, the kind of field that the message represents. Thus, for example, the Type field can indicate that the message being carried is a message in the format described herein, that is able to carry residence time information. Different Type values may be used to indicate, for example, an authentication type of the carried PTP message. Thus, the type field may indicate that there is no payload, or may indicate that the payload is a PTPv2 message or an NTP message.

The Length field is number of octets of the Value field. The optional Value field may then be used to carry a packet of the time synchronization protocol being used. Thus, the Sync message, Follow_up message, Delay_Req message, or Delay_Resp message may be inserted in the Value field by the respective LER <NUM>, <NUM> that is connected to the boundary clock node <NUM>, <NUM> from which the relevant message is being sent.

The packet may be authenticated or encrypted and carried over the MPLS network edge to edge unchanged.

Thus, <FIG> shows the Sync message <NUM> being sent from the boundary clock node <NUM> to the MPLS ingress Label switching Edge Router (LER) <NUM>. The LER <NUM> puts the message into the MPLS G-Ach format as shown in <FIG>, and the resulting packet <NUM>, indicated in <FIG> as Sync*, is transmitted through one or more Label Switching Router (LSR) <NUM>, until it reaches the MPLS egress Label switching Edge Router (LER) <NUM>. The LER <NUM> extracts the message from the MPLS format, and the resulting packet <NUM>, corresponding to the original Sync message, is transmitted to the boundary clock node <NUM>.

<FIG> also shows the Follow_up message <NUM> being sent from the boundary clock node <NUM> to the MPLS ingress Label switching Edge Router (LER) <NUM>. Again, the LER <NUM> puts the message into the MPLS G-Ach format as shown in <FIG>, and the resulting packet <NUM>, indicated in <FIG> as Follow_up*, is transmitted through one or more Label Switching Router (LSR) <NUM>, until it reaches the MPLS egress Label switching Edge Router (LER) <NUM>.

However, in this case, each Label switching Edge Router (LER) <NUM>, <NUM>, and each Label Switching Router (LSR) <NUM>, makes use of the Scratch Pad field of the packet format shown in <FIG>, to include residence time information.

Specifically, the Scratch Pad field is <NUM> octets in length and, in the case of the Follow_up* message <NUM>, is used to accumulate the residence time spent in LERs LSRs transited by the Sync packet on its path from the ingress LSR <NUM> to the egress LSR <NUM>.

That is, when the ingress LER <NUM> transmits the Follow_up* message <NUM>, it includes in the Scratch Pad field a value indicating the residence time spent in the LER <NUM> by the Sync message. The residence time may be measured in any convenient manner, for example from the point in time at which the message starts to be received until the point in time at which the message starts to be transmitted.

The time is stored in IEEE double precision format, with units of nanoseconds.

Similarly, when the LSR <NUM> transmits the Follow_up* message <NUM>, it updates the Scratch Pad field by adding a value indicating the residence time spent in the LSR <NUM> by the Sync message.

This continues until the Follow_up* message <NUM> reaches the MPLS egress LER <NUM>, which extracts the message from the MPLS G-Ach format, and sends a conventional Follow_up message <NUM> to the boundary clock node <NUM>, containing information indicating the accumulated residence time of the Sync message across the nodes of the network transited by the message, including the egress LER <NUM> itself.

Each of the nodes <NUM>, <NUM>, <NUM> therefore receives a data packet containing the Sync message from a preceding, or source, node, and forwards it to a succeeding, or destination, node, and measures the residence time of the data packet in the respective node. Each of the nodes <NUM>, <NUM>, <NUM> subsequently sends a further data packet (i.e. the data packet containing the Follow-up message) to the succeeding, or destination, node, that includes residence time information derived from the measured residence time. The LER <NUM> is configured to generate the further data packet (follow-up*) in a two-step operation mode.

The further data packet comprises residence time information for the MPLS network and the received follow-up message from outside of the MPLS network <NUM>, e.g. from the node <NUM>. In this case, the sending of a further data packet containing the residence time information is achieved by forwarding a second message (second data packet) from the source to the destination, and including the residence time information in that forwarded second message. Thus, the further data packet sent is the second data packet. The second data packet was received from the previous node in the path, the residence time included, updated or modified to indicate the residence time in that node, and then the second data packet forwarded with the residence time information as the further data packet to the next node in the path.

Thus, each of the nodes <NUM>, <NUM>, <NUM> acts as a two-step transparent clock.

Thus, when considering the LER <NUM> as the active node, it receives the Sync message as a first packet from the boundary clock node <NUM> acting as a source node, and forwards the Sync message to a destination node, for example the LSR <NUM>. (Thus, the term "source node" refers to the node from which the active node receives packets, and the term "destination node" refer to the node to which the active node sends packets. These may not be the original source or the ultimate destination of the packets. ) The LER <NUM> then sends a further packet, namely the Follow_up* message <NUM> containing residence time information, to the destination node.

When considering the LSR <NUM> as the active node, it receives the Sync message as a first packet from a source node such as the LER <NUM>, and forwards the Sync message to a destination node, for example the LER <NUM>. It then sends a further packet, namely the Follow_up* message <NUM> containing residence time information, to the destination node.

The active node may be considered as the specific node that is performing the method steps, e.g. receiving and forwarding data packets, and for which a measurement of residence time in the node is made and included in a forwarded packet.

Similarly, when considering the LER <NUM> as the active node, it receives the Sync message as a first packet from a source node such as the LSR <NUM>, and forwards the Sync message to a destination node, for example the boundary clock node <NUM>. It then sends a further packet, namely the Follow_up message <NUM> containing residence time information, to the destination node. In some examples, the source node and/or destination node is a boundary clock or connected to a boundary clock, e.g. a transparent clock connected to a boundary clock.

When the boundary clock node <NUM>, which is operating in two-step mode, receives the Follow_up message <NUM>, it returns a Delay_Req message, as specified in IEEE <NUM>. Thus, <FIG> shows the Delay_Req message <NUM> being sent from the boundary clock node <NUM> to the MPLS Label switching Edge Router (LER) <NUM>. The LER <NUM> puts the message into the MPLS G-Ach format as shown in <FIG>, and the resulting packet <NUM>, indicated in <FIG> as Delay_Req*, is transmitted through one or more Label Switching Router (LSR) <NUM>, until it reaches the Label switching Edge Router (LER) <NUM>. The LER <NUM> extracts the message from the MPLS G-Ach format, and the resulting packet <NUM>, corresponding to the original Delay_Req message <NUM>, is transmitted to the boundary clock node <NUM>.

Again as specified in IEEE <NUM>, the boundary clock node <NUM>, operating in two-step mode, returns a Delay_Resp message <NUM> when it receives the Delay_Req message <NUM>. Thus, <FIG> shows the Delay_Resp message <NUM> being sent from the boundary clock node <NUM> to the Label switching Edge Router (LER) <NUM>. Again, the LER <NUM> puts the message into the MPLS G-Ach format as shown in <FIG>, and the resulting packet <NUM>, indicated in <FIG> as Delay_Resp*, is transmitted through one or more Label Switching Router (LSR) <NUM>, until it reaches the Label switching Edge Router (LER) <NUM>.

The Delay_Resp* packet <NUM> contains the Delay_Resp message <NUM> as its payload, but also makes use of the Scratch Pad field of the packet format shown in <FIG>, to include residence time information relating to the residence time of the respective Delay_Req message.

Each Label switching Edge Router (LER) <NUM>, <NUM>, and each Label Switching Router (LSR) <NUM> updates the Delay_Resp* packet <NUM> to include residence time information. In this case, the residence time information included in the Delay_Resp* packet <NUM> relates to the residence time spent in the LERs and LSRs by the Delay_Req message.

That is, in the case of the Delay_Resp* message <NUM>, the Scratch Pad field is used to accumulate the residence time spent in the LERs <NUM>, <NUM> and the LSR <NUM> by the Delay_Req packet on its path from the LER <NUM> to the LER <NUM>.

In more detail, when the LER <NUM> generates and transmits the Delay_Resp* message <NUM>, it includes in the Scratch Pad field a value indicating the residence time spent in the LER <NUM> by the respective Delay_Req message. As before, the residence time may be measured in any convenient manner, for example from the point in time at which the message starts to be received until the point in time at which the message starts to be transmitted.

Similarly, when the LSR <NUM> transmits the Delay_Resp* message <NUM>, it updates the Scratch Pad field by adding a value indicating the residence time spent in the LSR <NUM> by the previous, related, Delay_Req message.

This continues until the Delay_Resp* message <NUM> reaches the LER <NUM>, which extracts the message from the MPLS G-Ach format, and sends a conventional Delay_Resp message <NUM> to the boundary clock node <NUM>, containing information indicating the accumulated residence time of the Delay-Req message across the nodes of the network transited by the Delay-Req message, including the egress LER <NUM> itself.

Each of the nodes <NUM>, <NUM>, <NUM> therefore receives a data packet containing the Delay_Req message from a preceding, or source, node, and forwards it to a succeeding, or destination, node, and measures the residence time of the data packet in the respective node. Each of the nodes <NUM>, <NUM>, <NUM> subsequently sends a further data packet (i.e. the data packet containing the Delay_Resp message) to the preceding, or source, node, that includes residence time information derived from the measured residence time. In this case, the sending of a further data packet containing the residence time information is achieved by forwarding a second message (second data packet) from the destination to the source, and updating or including the residence time information in that forwarded second message. The forwarded message or packet may be modified by the node that has received and forwarded the message. For example, the modification may be an inclusion or updating of the residence time information, in particular, to include the residence time spent in that node.

Thus, when considering the LER <NUM> as the active node, it receives the Delay_Req message as a first packet from the boundary clock node <NUM> acting as a source node, and forwards the Delay_Req message to a destination node, for example the LSR <NUM>. (Thus, the term "source node" refers to the node from which the active node receives packets, and the term "destination node" refer to the node to which the active node sends packets. These may not be the original source or the ultimate destination of the packets. ) The LER <NUM> subsequently sends a further packet, namely the Delay_Resp message <NUM> containing residence time information, to the source node.

When considering the LSR <NUM> as the active node, it receives the Delay_Req* message as a first packet from a source node such as the LER <NUM>, and forwards the Delay_Req* message to a destination node, for example the LER <NUM>. It then sends a further packet, namely the Delay_Resp* message <NUM> containing residence time information, to the source node.

Similarly, when considering the LER <NUM> as the active node, it receives the Delay_Req* message as a first packet from a source node such as the LSR <NUM>, and forwards the Delay_Req message to a destination node, for example the boundary clock node <NUM>. It then sends a further packet, namely the Delay_Resp* message <NUM> containing residence time information, to the source node.

<FIG> illustrates a method in accordance with a second embodiment.

Specifically, in this illustrated embodiment, the PTP network <NUM> shown in <FIG> is operating in a <NUM>-step mode. That is, a first boundary clock node, such as the boundary clock node <NUM> shown in <FIG>, transmits an event PTP message in the form of a Sync message <NUM>, but without sending a Follow_up message.

On receipt of the Sync message <NUM>, a second boundary clock node, such as the boundary clock node <NUM> shown in <FIG>, transmits an event PTP message in the form of a Delay_Req message <NUM>.

The messages described with reference to <FIG> are transmitted across the MPLS network in an MPLS message format, as shown in <FIG>.

The Flags field has one bit, S, which acts as a step flag, indicating if the two-step clock procedure is in use, and therefore set to <NUM> if the boundary clocks <NUM>, <NUM> are operating in one-step mode, and set to <NUM> if they are operating in two-step mode. The PTPType field indicates the type of PTP packet carried in the TLV. Thus, for example, the PTPType field identifies whether the message is a Sync message, Follow_up message, Delay_Req message, or Delay_Resp message. The <NUM> octet long Port ID field contains the identity of the source port, that is, the specific PTP port of the boundary clock connected to the MPLS network. The Sequence ID is the sequence ID of the PTP message carried in the Value field of the message. Thus, a further packet, containing residence time information relating to an earlier packet, contains information identifying that earlier packet.

Thus, <FIG> shows the Sync message <NUM> being sent from the boundary clock node <NUM> to the MPLS ingress Label switching Edge Router (LER) <NUM>. The LER <NUM> puts the message into the MPLS G-Ach format as shown in <FIG>, and the resulting packet <NUM>, indicated in <FIG> as Sync*, is transmitted through one or more Label Switching Router (LSR) <NUM>, until it reaches the MPLS egress Label switching Edge Router (LER) <NUM>. The LER <NUM> extracts the message from the MPLS G-Ach format, and the resulting packet <NUM>, corresponding to the original Sync message, is transmitted to the boundary clock node <NUM>.

<FIG> also shows that, when the MPLS ingress Label switching Edge Router (LER) <NUM> receives the Sync message <NUM> from the boundary clock node <NUM>, it generates an additional message, RTM, <NUM>, for the purpose of carrying residence time information relating to the residence time spent by the Sync message in the various nodes. The LER <NUM> creates the RTM message <NUM> in the MPLS G-Ach format as shown in <FIG>, and the resulting packet is transmitted through one or more Label Switching Router (LSR) <NUM>, until it reaches the MPLS egress Label switching Edge Router (LER) <NUM>.

Thus, when the LER <NUM> is connected to a node <NUM> operating in a <NUM>-step mode (no follow up packet which contains timing information for the Sync* packet), the LER <NUM> generates an additional message to carry residence time information relating to the MPLS network.

Each Label switching Edge Router (LER) <NUM>, <NUM>, and each Label Switching Router (LSR) <NUM>, makes use of the Scratch Pad field of the packet format shown in <FIG>, to include residence time information.

Specifically, the Scratch Pad field is <NUM> octets in length and, in the case of the RTM message <NUM>, is used to accumulate the residence time spent in the LERs and LSRs transited by the Sync packet on its path from the ingress LSR <NUM> to the egress LSR <NUM>.

That is, when the ingress LER <NUM> transmits the RTM message <NUM>, it includes in the Scratch Pad field a value indicating the residence time spent in the LER <NUM> by the Sync message <NUM>. The residence time may be measured in any convenient manner, for example from the point in time at which the message starts to be received until the point in time at which the message starts to be transmitted.

Similarly, when the LSR <NUM> transmits the RTM message <NUM>, it updates the Scratch Pad field by adding a value indicating the residence time spent in the LSR <NUM> by the Sync* message <NUM>.

This continues until the RTM message <NUM> reaches the MPLS egress LER <NUM>, which extracts the message from the MPLS G-Ach format, and sends a conventional Follow_up message <NUM> to the boundary clock node <NUM>, containing information indicating the accumulated residence time of the Sync message across the nodes of the network transited by the message, including the egress LER <NUM> itself. The LER <NUM> will have previously set the <NUM>-step flag to <NUM> in the Sync message <NUM>, so that the boundary clock node <NUM> knows that it can expect the Follow_up message.

Each of the nodes <NUM>, <NUM>, <NUM> therefore receives a data packet containing the Sync message from a preceding, or source, node, and forwards it to a succeeding, or destination, node, and measures the residence time of the data packet in the respective node. Each of the nodes <NUM>, <NUM>, <NUM> subsequently sends a further, specially generated, data packet to the succeeding, or destination, node, that includes residence time information derived from the measured residence time.

Thus, the ingress LER achieves the sending of a further data packet containing the residence time information by creating a new (second) data packet, including the residence time information in the new data packet, and sending the new data packet to the destination node. The other nodes achieve the sending of a further data packet containing the residence time information by receiving the (second) data packet created by the ingress LER, including the residence time information in that (second) data packet, and forwarding the new (second) data packet to the destination node. The included residence time information corresponds to the residence time in that node. The including may comprise updating or modifying an existing time (e.g. by adding an additional residence time to a total), or the including may refer to including residence time information initially, where there is no previous residence time in the second data packet.

Thus, when considering the LER <NUM> as the active node, it receives the Sync message as a first packet from the boundary clock node <NUM> acting as a source node, and forwards the Sync message to a destination node, for example the LSR <NUM>. (Thus, the term "source node" refers to the node from which the active node receives packets, and the term "destination node" refer to the node to which the active node sends packets. These may not be the original source or the ultimate destination of the packets. ) The LER <NUM> then sends a further packet, namely the RTM message <NUM> containing residence time information, to the destination node.

When considering the LSR <NUM> as the active node, it receives the Sync message as a first packet from a source node such as the LER <NUM>, and forwards the Sync message to a destination node, for example the LER <NUM>. It then sends a further packet, namely the RTM message <NUM> containing residence time information, to the destination node.

Similarly, when considering the LER <NUM> as the active node, it receives the Sync message as a first packet from a source node such as the LSR <NUM>, and forwards the Sync message to a destination node, for example the boundary clock node <NUM>. It then sends a further packet, namely the Follow_up message <NUM> containing residence time information, to the destination node.

When the boundary clock node <NUM> receives the Follow_up message <NUM>, it returns a Delay_Req message, as specified in IEEE <NUM>. Thus, <FIG> shows the Delay_Req message <NUM> being sent from the boundary clock node <NUM> to the MPLS Label switching Edge Router (LER) <NUM>. The LER <NUM> puts the message into the MPLS G-Ach format as shown in <FIG>, and the resulting packet <NUM>, indicated in <FIG> as Delay_Req*, is transmitted through one or more Label Switching Router (LSR) <NUM>, until it reaches the Label switching Edge Router (LER) <NUM>. The LER <NUM> extracts the message from the MPLS G-Ach format, and the resulting packet <NUM>, corresponding to the original Delay_Req message <NUM>, is transmitted to the boundary clock node <NUM>.

Again as specified in IEEE <NUM>, the boundary clock node <NUM> returns a Delay_Resp message <NUM> when it receives the Delay_Req message <NUM>. Thus, <FIG> shows the Delay_Resp message <NUM> being sent from the boundary clock node <NUM> to the Label switching Edge Router (LER) <NUM>. Again, the LER <NUM> puts the message into the MPLS G-Ach format as shown in <FIG>, and the resulting packet <NUM>, indicated in <FIG> as Delay_Resp*, is transmitted through one or more Label Switching Router (LSR) <NUM>, until it reaches the Label switching Edge Router (LER) <NUM>.

The Delay_Resp* packet <NUM> contains the Delay_Resp message <NUM> as its payload, but also makes use of the Scratch Pad field of the packet format shown in <FIG>, to include residence time information of the related Delay_Req message.

Each Label switching Edge Router (LER) <NUM>, <NUM>, and each Label Switching Router (LSR) <NUM> updates the Delay_Resp* packet <NUM> to include residence time information. In this case, the residence time information included in the Delay_Resp* packet <NUM> relates to the residence time spent in the LERs and LSRs by the Delay_Req message <NUM>/<NUM>.

That is, in the case of the Delay_Resp* message <NUM>, the Scratch Pad field is used to accumulate the residence time spent in the LERs <NUM>, <NUM> and the LSR <NUM> by the related Delay_Req packet on its path from the LER <NUM> to the LER <NUM>.

In more detail, when the LER <NUM> generates and transmits the Delay_Resp* message <NUM>, it includes in the Scratch Pad field a value indicating the residence time spent in the LER <NUM> by the Delay_Req message. As before, the residence time may be measured in any convenient manner, for example from the point in time at which the message starts to be received until the point in time at which the message starts to be transmitted.

Each of the nodes <NUM>, <NUM>, <NUM> therefore receives a data packet containing the Delay_Req message from a preceding, or source, node, and forwards it to a succeeding, or destination, node, and measures the residence time of the data packet in the respective node. Each of the nodes <NUM>, <NUM>, <NUM> subsequently sends a further data packet (i.e. the data packet containing the Delay_Resp message) to the preceding, or source, node, that includes residence time information derived from the measured residence time. Thus, the sending of a further data packet containing the residence time information is achieved by forwarding a second message from the destination to the source, and including the residence time information in that forwarded second message. In this case, the first data packet is the Delay_Req message, and the second (further) data packet is the Delay_Resp message.

When considering the LSR <NUM> as the active node, it receives the Delay_Req* message as a first packet from a source node such as the LER <NUM>, and forwards the Delay_Req* message to a destination node, for example the LER <NUM>. It subsequently sends a further packet, namely the Delay_Resp* message <NUM> containing residence time information, to the source node.

Similarly, when considering the LER <NUM> as the active node, it receives the Delay_Req* message as a first packet from a source node such as the LSR <NUM>, and forwards the Delay_Req message to a destination node, for example the boundary clock node <NUM>. It subsequently sends a further packet, namely the Delay_Resp* message <NUM> containing residence time information, to the source node.

Claim 1:
A method of operation of a Multiprotocol Label Switching network, the method comprising, in an active node of the network:
receiving an event message for a synchronization protocol from a network node, wherein the active node is an egress Label Edge Router (<NUM>), and
receiving a following message containing residence time information in a MPLS G-Ach format;
forwarding a corresponding event message to a boundary clock node (<NUM>);
measuring a residence time of the event message in the active node;
extracting the received following message from the MPLS G-Ach format to generate a Precision Time Protocol, PTP, following message,
and
sending the PTP following message containing accumulated residence time information, including the residence time for the Label Edge Router (<NUM>).